From dholmes at openjdk.org  Mon Dec  1 04:21:52 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 1 Dec 2025 04:21:52 GMT
Subject: RFR: 8372615: Many container tests fail when running rootless on
 cgroup v1
In-Reply-To: <vMiWENH7dMmRw5miQHPYNnETLlwMgklDZyGxk_JCPu4=.a98f9e35-3bb4-4aaf-b89b-a2547c4e6f29@github.com>
References: <vMiWENH7dMmRw5miQHPYNnETLlwMgklDZyGxk_JCPu4=.a98f9e35-3bb4-4aaf-b89b-a2547c4e6f29@github.com>
Message-ID: <5wBcMRj8jDv-vnUNYD8CdotWx9x1UjUhboVdPE-zox4=.eb8d1086-de7b-4a0e-b61e-1cca3c768571@github.com>

On Fri, 28 Nov 2025 15:03:25 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> Many container tests verify that various resource limits work as expected. However, when running containers in rootless mode on both Docker and Podman with cgroup v1, resource limits are not supported. This causes tests to fail with error messages like: `Resource limits are not supported and ignored on cgroups V1 rootless systems`.
> 
> To address this, we should skip these tests when running on configurations that don't support resource limits, similar to how we already handle other unsupported configurations (e.g., missing container engine or incompatibility with a specific cgroup version or container runtime).
> 
> To check for this, we now need to use `Metrics.systemMetrics().getProvider()` from `jdk.internal.platform.Metrics` to detect cgroup v1. I've added this functionality to `DockerTestUtils`, which is already used by all container tests. As a result, all container tests now need to include the `java.base/jdk.internal.platform` module, even if they don't directly test resource limits.
> 
> Testing:
> * Oracle tiers 1-5
> * Local testing:
>   - `hotspot/jtreg/containers/` 
>   - `jdk/jdk/internal/platform/docker/`
> on cgroup v1/v2 with Podman and Docker in both rootful and rootless configurations

test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java line 142:

> 140:      *
> 141:      * @return true if resource limits are supported in the current configuration
> 142:      * @throws Exception

I don't like this pattern of making a function seem like it is a query by declaring it returns a boolean when in reality it either returns true of throws. These should just be void functions with names like `check_canUseResourceLimits`, and we can elide the fake `if` conditions with unreachable `return` statements in the callers.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28557#discussion_r2575563949

From qamai at openjdk.org  Mon Dec  1 06:28:04 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 1 Dec 2025 06:28:04 GMT
Subject: RFR: 8372779: C2: Disambiguate Node::adr_type for the IR graph
Message-ID: <dEidZLl1MkM6TbAxS2FsitU70AYAahwzK9cun61wwV8=.ccdad883-5d8f-403e-a19f-40aef0f53b11@github.com>

Hi,

Currently, `Node::adr_type` is ambiguous. For some, it refers to the memory the node consumes, while for the others, it refer to the memory the node produces. This PR removes that ambiguity by introducing `Node::in_adr_type` and `Node::out_adr_type` that refer to those properties, respectively. It also introduces a local verification of the memory graph during compilation. These additions uncover some issues:

- Sometimes, the memory is wired incorrectly, such as in `LibraryCall::extend_setCurrentThread`, the `Phi` collect the `StoreNode`s instead of the whole memory state. I think these issues do not result in crashes or miscompilation, though.
- `AryEqNode` reports `adr_type` being `TypeAryPtr::BYTES` (it inherits this from `StrIntrinsicNode`). This is incorrect, however, as it can accept `char[]` inputs, too.
- For nodes such as `StrInflatedCopyNode`, as it consumes more than it produces, during scheduling, we need to compute anti-dependencies. This is not the case, so I fixed it by making it kill all the memory it consumes.
- `GraphKit::set_output_for_allocation` uses a raw `ProjNode` as the base for a `MergeMem`, this is really suspicious. I didn't fix it, as it seems to not result in any symptom at the moment.

In the end, the execution of the compiler is strictly more restricted than before, and there is less room for ambiguity.

Please take a look and leave your reviews, thanks a lot.

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

Commit messages:
 - Disambiguate Node::adr_type

Changes: https://git.openjdk.org/jdk/pull/28570/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28570&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372779
  Stats: 629 lines in 36 files changed: 403 ins; 72 del; 154 mod
  Patch: https://git.openjdk.org/jdk/pull/28570.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28570/head:pull/28570

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

From aboldtch at openjdk.org  Mon Dec  1 06:54:03 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 1 Dec 2025 06:54:03 GMT
Subject: RFR: 8372528: Unify atomic exchange and compare exchange [v4]
In-Reply-To: <qusxeSajDqRGivzu0rJ57eFQXyBD9uFcgSvx-x51Gv0=.c41b1f75-474c-4e9f-96e0-5384e3dcf4d9@github.com>
References: <lgcq8OzUuxq4mK07k_tQd8DZa8UGMCFeUrdrxexapQQ=.41bf9663-5d1d-4887-abcc-0cb90b56884e@github.com>
 <qusxeSajDqRGivzu0rJ57eFQXyBD9uFcgSvx-x51Gv0=.c41b1f75-474c-4e9f-96e0-5384e3dcf4d9@github.com>
Message-ID: <9ezKp1C-T_UoVEV0Ds2X-SZMDlXlHHXK4g3Xszs9yJM=.5163a011-b789-4c68-bd78-152fcc677293@github.com>

On Fri, 28 Nov 2025 15:33:19 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> AtomicAccess::xchg is only required to support `4` bytes and `sizeof(intptr_t)` size.
>> This restriction added a lot of extra logic to the Atomic implementation because
>> we have a set of features we must support (including compare exchange) for `1`, `4` and `8` byte atomics on all platforms. We have some checks for unsupported `8` byte compare exchange (`VM_Version::supports_cx8()`), but the Atomic class does not try to handle these for generating its supported functions. On such a platform we would more than likely get a linking error.
>> 
>> I propose we change requirement for exchange to `1`, `4` and `8` bytes to achieve parity with compare exchange. Initially by implementing exchange via the `AtomicAccess::XchgUsingCmpxch`. And have follow up RFEs for each applicable platform where we specialize `AtomicAccess::PlatformXchg<1>`.
>> 
>> This enhancement both simplifies the Atomic implementation and provides exchange capabilities for types like `bool` and enums represented by a byte.
>> 
>> _It is a little unclear how we deal with `VM_Version::supports_cx8()`. Its existence makes it impossible to use `compare_exchange` on `int64_t` in general code. Currently the `Atomic` implementation assumes that `exchange` can always be used on `8` byte integers (at least going by the gtest). Even though `AtomicAccess` only specifies `4` bytes and the platform size. This PR changes this to `1`, `4` and `8` bytes. But not sure if the previous behaviour / implicit requirements is an oversight a similar property to `VM_Version::supports_cx8()` should apply here for `exchange`._
>> 
>> * Testing
>>   * Extended gtest / (no other users of Atomic byte with exchange exists.
>>   * GHA
>>   * Running Tier 1-5 on Oracle supported platforms
>
> Axel Boldt-Christmas has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update test/hotspot/gtest/runtime/test_atomicAccess.cpp
>    
>    Co-authored-by: Stefan Karlsson <stefan.karlsson at oracle.com>
>  - Update test/hotspot/gtest/runtime/test_atomic.cpp
>    
>    Co-authored-by: Stefan Karlsson <stefan.karlsson at oracle.com>

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/28498#issuecomment-3594838349

From aboldtch at openjdk.org  Mon Dec  1 06:54:04 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 1 Dec 2025 06:54:04 GMT
Subject: Integrated: 8372528: Unify atomic exchange and compare exchange
In-Reply-To: <lgcq8OzUuxq4mK07k_tQd8DZa8UGMCFeUrdrxexapQQ=.41bf9663-5d1d-4887-abcc-0cb90b56884e@github.com>
References: <lgcq8OzUuxq4mK07k_tQd8DZa8UGMCFeUrdrxexapQQ=.41bf9663-5d1d-4887-abcc-0cb90b56884e@github.com>
Message-ID: <ngkn7aDb_q8ABPkR0IRndjVaiHT2DrQUqY2P0hcVzzA=.a47a4e72-4cd6-406f-b637-2e740b6f811a@github.com>

On Tue, 25 Nov 2025 18:28:19 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> AtomicAccess::xchg is only required to support `4` bytes and `sizeof(intptr_t)` size.
> This restriction added a lot of extra logic to the Atomic implementation because
> we have a set of features we must support (including compare exchange) for `1`, `4` and `8` byte atomics on all platforms. We have some checks for unsupported `8` byte compare exchange (`VM_Version::supports_cx8()`), but the Atomic class does not try to handle these for generating its supported functions. On such a platform we would more than likely get a linking error.
> 
> I propose we change requirement for exchange to `1`, `4` and `8` bytes to achieve parity with compare exchange. Initially by implementing exchange via the `AtomicAccess::XchgUsingCmpxch`. And have follow up RFEs for each applicable platform where we specialize `AtomicAccess::PlatformXchg<1>`.
> 
> This enhancement both simplifies the Atomic implementation and provides exchange capabilities for types like `bool` and enums represented by a byte.
> 
> _It is a little unclear how we deal with `VM_Version::supports_cx8()`. Its existence makes it impossible to use `compare_exchange` on `int64_t` in general code. Currently the `Atomic` implementation assumes that `exchange` can always be used on `8` byte integers (at least going by the gtest). Even though `AtomicAccess` only specifies `4` bytes and the platform size. This PR changes this to `1`, `4` and `8` bytes. But not sure if the previous behaviour / implicit requirements is an oversight a similar property to `VM_Version::supports_cx8()` should apply here for `exchange`._
> 
> * Testing
>   * Extended gtest / (no other users of Atomic byte with exchange exists.
>   * GHA
>   * Running Tier 1-5 on Oracle supported platforms

This pull request has now been integrated.

Changeset: ca96366c
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ca96366c03b89fa90a015e6c2d5912a9f2554c92
Stats:     255 lines in 16 files changed: 108 ins; 118 del; 29 mod

8372528: Unify atomic exchange and compare exchange

Reviewed-by: kbarrett, stefank

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

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

From aboldtch at openjdk.org  Mon Dec  1 06:55:35 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 1 Dec 2025 06:55:35 GMT
Subject: RFR: 8372241: Add GTestCheckers [v3]
In-Reply-To: <JD1Zp8q0PaUuSEmeB04BpwJqYj8Hv3691RikemjROgc=.7d9d1ed6-4890-4ea3-9e63-b4fc9a2d6d42@github.com>
References: <JD1Zp8q0PaUuSEmeB04BpwJqYj8Hv3691RikemjROgc=.7d9d1ed6-4890-4ea3-9e63-b4fc9a2d6d42@github.com>
Message-ID: <ApuaqeCgj5UEpHnRANrjUriiLVRQzr_t506EhIhTeTk=.94ef7235-aa45-4c60-9fd2-29b2550262ef@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 three additional commits since the last revision:

 - 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/83042978..d2b18730

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

  Stats: 46483 lines in 617 files changed: 32896 ins; 9618 del; 3969 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  Mon Dec  1 06:55:52 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 1 Dec 2025 06:55:52 GMT
Subject: RFR: 8371346: ZGC: Flexible heap base selection [v3]
In-Reply-To: <g2sXoLZ6-rQ8TeHjA_C2Gi_gmrAW_uA-mQpe867xG-M=.5f135781-364a-4929-b6cb-79f2488b415c@github.com>
References: <g2sXoLZ6-rQ8TeHjA_C2Gi_gmrAW_uA-mQpe867xG-M=.5f135781-364a-4929-b6cb-79f2488b415c@github.com>
Message-ID: <FZoWxQzy9kTDDjzbCrPo9ma8EDvMzelJ1-M4QpVSv7g=.0da5adcf-eee7-4f54-9fd4-939be79b5490@github.com>

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

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

 - 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
 - Log reserved size correctly when multi-partition fails
 - ... and 2 more: https://git.openjdk.org/jdk/compare/847fbab7...4603db33

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

Changes: https://git.openjdk.org/jdk/pull/28161/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28161&range=02
  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 aartemov at openjdk.org  Mon Dec  1 08:43:49 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Mon, 1 Dec 2025 08:43:49 GMT
Subject: RFR: 8366671: Refactor Thread::SpinAcquire and Thread::SpinRelease
 [v10]
In-Reply-To: <NtY8E8fBeSokCAQYP3OQEwfnppSugtTJ8uAtQtD0zvg=.88f2988d-47fd-4b8a-af89-488ed6b37870@github.com>
References: <NtY8E8fBeSokCAQYP3OQEwfnppSugtTJ8uAtQtD0zvg=.88f2988d-47fd-4b8a-af89-488ed6b37870@github.com>
Message-ID: <vgxN4MFz9DVY9fe1H01-IZxYa_upcewcB4nQ4Ii5pV4=.a05ac7a4-aafc-4144-9d91-19f0feecd777@github.com>

> Hi, 
> 
> please consider the following changes:
> 
> In this PR `Thread::SpinAcquire()` and `Thread::SpinRelease()` methods are refactored into a utility class `SpinCriticalSection`. The motivation is to make it easier for developers to use this lightweight synchronization mechanism in the codebase. The two aforementioned methods were used in JFR to create short critical sections with a helper class, but that was not the case for the object monitor code. 
> 
> Tested in tiers 1 - 5.

Anton Artemov 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:

 - Merge remote-tracking branch 'origin/master' into JDK-8366671-refactor-spin-acquire-spin-release
 - 8366671: Addressed reviewer's comments.
 - 8366671: Addressed reviewers' comments.
 - 8366671: Addressed reviewer's comments
 - 8366671: Removed redundant include.
 - 8366671: Removed the file mistakenly checked in.
 - 8366671: Fixed build problem.
 - 8366671: Addressed reviewer's comments.
 - Merge remote-tracking branch 'origin/master' into JDK-8366671-refactor-spin-acquire-spin-release
 - Merge remote-tracking branch 'origin/master' into JDK-8366671-refactor-spin-acquire-spin-release
 - ... and 4 more: https://git.openjdk.org/jdk/compare/77430bb9...b2483bf6

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28264/files
  - new: https://git.openjdk.org/jdk/pull/28264/files/4952da2c..b2483bf6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28264&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28264&range=08-09

  Stats: 80250 lines in 1334 files changed: 53885 ins; 17646 del; 8719 mod
  Patch: https://git.openjdk.org/jdk/pull/28264.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28264/head:pull/28264

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

From shade at openjdk.org  Mon Dec  1 09:09:23 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 1 Dec 2025 09:09:23 GMT
Subject: RFR: 8357258: x86: Improve receiver type profiling reliability
 [v5]
In-Reply-To: <EP839aKDLW1U15z7MWw6GHKXZKBcIiZvxrBvqtG8qOU=.11c7abac-3672-478d-b3c9-98991836ce20@github.com>
References: <X9RJoDWqk67MlK7P4ACCbzROxLkfEqvU0zDid3zymnc=.7c0086a3-f514-4b0d-8bc0-592bf4a05bba@github.com>
 <ABBZBklt6TsANDYgiL2rSq7tZk7OahMhRsrh0CIrNnI=.72cf3c77-1884-426e-90f5-0297a2fdc986@github.com>
 <EP839aKDLW1U15z7MWw6GHKXZKBcIiZvxrBvqtG8qOU=.11c7abac-3672-478d-b3c9-98991836ce20@github.com>
Message-ID: <_o4EmLJi9oI38vVDE69u9u8dC-Ad8501si7GW_bIi9M=.ec2c10fb-40fd-4c8e-95af-ae8f59806da6@github.com>

On Fri, 28 Nov 2025 15:21:47 GMT, Andrew Haley <aph at openjdk.org> wrote:

> I'm seeing minor performance regressions in `InterfaceCalls.test2ndInt5Types`, before and after this PR:

Reproduced locally too:


Benchmark                                                (randomized)  Mode  Cnt    Score   Error      Units

# Baseline
InterfaceCalls.test2ndInt5Types                                 false  avgt   12   16.945 ?  0.079      ns/op
InterfaceCalls.test2ndInt5Types:L1-dcache-load-misses           false  avgt    3    0.076 ?  2.187       #/op
InterfaceCalls.test2ndInt5Types:L1-dcache-loads                 false  avgt    3   88.738 ?  0.416       #/op
InterfaceCalls.test2ndInt5Types:branch-misses                   false  avgt    3    0.007 ?  0.003       #/op
InterfaceCalls.test2ndInt5Types:branches                        false  avgt    3   49.122 ?  0.353       #/op
InterfaceCalls.test2ndInt5Types:cycles                          false  avgt    3   57.147 ?  1.698       #/op
InterfaceCalls.test2ndInt5Types:instructions                    false  avgt    3  247.443 ?  1.531       #/op


# Current PR
InterfaceCalls.test2ndInt5Types                                 false  avgt   12   22.513 ?  0.208      ns/op
InterfaceCalls.test2ndInt5Types:L1-dcache-load-misses           false  avgt    3    0.012 ?  0.072       #/op
InterfaceCalls.test2ndInt5Types:L1-dcache-loads                 false  avgt    3  108.446 ? 13.975       #/op  ; +20 loads
InterfaceCalls.test2ndInt5Types:branch-misses                   false  avgt    3    0.407 ?  0.010       #/op
InterfaceCalls.test2ndInt5Types:branches                        false  avgt    3   54.102 ?  0.403       #/op  ; +5 branches
InterfaceCalls.test2ndInt5Types:cycles                          false  avgt    3   75.938 ?  5.043       #/op
InterfaceCalls.test2ndInt5Types:instructions                    false  avgt    3  280.194 ?  5.758       #/op  ; +32 instructions


Looked at perfasm, and there are no gross problems there. I also think reliability trumps this minor performance bump. But I also suspect this is caused by second loop re-walking the table looking for (empty) slots, this is where extra loads are coming from. I believe it can reasonably track the first non-null slot and start the walk from there. Let me see if it is simple to do without complicating the code all too much.

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

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

From david.holmes at oracle.com  Mon Dec  1 09:21:04 2025
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 1 Dec 2025 19:21:04 +1000
Subject: Any reason why +PrintFlagsFinal requires unlocking experimental
 and diagnostic flags to print their default values?
In-Reply-To: <CAA-vtUw=7=NQvzV1bP6AsCKsJruKZ4KvQaSimczD8NY-44X_=w@mail.gmail.com>
References: <849ebf93-c3fb-45c9-92c8-21a49b3e9946@redhat.com>
 <5ff2a0a5-9d61-466d-9ada-5ba911185815@oracle.com>
 <CAA-vtUw=7=NQvzV1bP6AsCKsJruKZ4KvQaSimczD8NY-44X_=w@mail.gmail.com>
Message-ID: <75d56d4d-6d4d-48c1-8d9d-86d92249346d@oracle.com>

Okay I have filed:

JDK-8372802: PrintFlagsFinal should also print locked flags

but note there is no commitment for anyone to actually perform the work.

David

On 28/11/2025 3:19 pm, Thomas St?fe wrote:
> I am very much in favor of printing all flags, for the reasons Frederic 
> has given. When one supports many different releases, it is a huge 
> timesaver not to have to look up flags but see them right there in the 
> customer logs. The ability of PrintFlagsFinal to give me all flags, 
> including default values, after they are resolved to their final values, 
> is also very useful during development.
> 
> For simplicity, I would prefer just to change the behavior of 
> PrintFlagsFinal to do that, but I could live with a new PrintAllFlagsFinal.
> 
> Number of normal flags: 513, incl. diagnostic: 777, incl. 
> experimental&diagnostic: 933. (Jdk 25). So, it's?a bit more. I am not 
> bothered by this, since this list never fits onto a single screen 
> anyway. People grep. But if others prefer an extra flag, sure, 
> let's?have one.
> 
> 
> On Thu, Nov 27, 2025 at 3:05?AM David Holmes <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>> wrote:
> 
>     On 27/11/2025 12:53 am, Frederic Thevenet wrote:
>      > Hi,
>      >
>      > Currently, using +PrintFlagsFinal prints out all JVM flags and their
>      > values, even if they were not modified from their default, except
>     for
>      > 'locked' flags, i.e. Experimental and Diagnotic flags. In order
>     to have
>      > those printed out as well, one must first 'unlock' them (with
>      > +UnlockExperimentalVMOptions, for instance).
> 
>     I think this was simply a pragmatic decision to avoid overwhelming the
>     user with information that should not be relevant.
>      > Now, is their a strong reason for not always displaying the default
>      > values for those in scenarios were there is no concerns that the
>     output
>      > might be too large (that is when calling upon
>     'JVMFlag::printFlags' with
>      > 'skipDefaults' set to false, like PrintFlagsFinal does)?
>      >
>      > The reason for this question is that when chasing a bug in scenarios
>      > where one can only rely on logs or output provided by tools that
>     uses
>      > +PrintFlagsFinal, getting the default values *in the conditions that
>      > those logs where produced* can be tricky as it depends on the exact
>      > version of the JDK that was running, and some values can be
>     changed by
>      > ergonomics.
> 
>     Ouch. I think that would be a poor design choice for diagnostic, and
>     especially experimental flags!
> 
> 
> Not every experimental/diagnostic flag is a boolean that defaults to 
> false and controls an opt-in feature. We have non-boolean experimental 
> flags and boolean flags that default to true. It is not unthinkable that 
> those are changed during VM start.
> 
> 
>      > If you need to know the default for experimental flags -- which
>     given
>      > their nature can and do change often -- your choices are to
>     either ask
>      > for these logs to be generated again using
>     +UnlockExperimentalVMOptions
>      > (even if there is no intention of changing an experimental flag)
>     or to
>      > go on a time consuming deep dive into the code base for the exact
>      > version of the JDK that was used. Neither is ideal.
> 
>     True, but for experimental flags in particular, unless you are deep
>     diving into the code how can you know whether a particular flag and its
>     value are relevant to your debugging in the first place?
> 
> 
> I think the point here is reducing analyst strain. It's?not that it is 
> impossible to get the information otherwise, but that it's?convenient 
> and stress-reducing to have one sure way to look up all resolved 
> flag?values for a customer's JVM run. Folks who have to work with many 
> cases involving different JVM versions would value this.
> 
> BTW, we do print default values for non-experimental non-diagnostic 
> flags, too. The same reasoning applies here: if its?not changed, you 
> could look up the default value.
> 
> 
>     That said, I don't see any harm in providing a way to print all flags,
>     though whether by default or by a new -XX:PrintAllFlagsFinal flag, I'm
>     not sure.
> 
> 
> Wonderful, let's?do that then.
> 
> Cheers, Thomas


From clanger at openjdk.org  Mon Dec  1 09:21:09 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Mon, 1 Dec 2025 09:21:09 GMT
Subject: RFR: 8351842: Windows specific issues in combination of JEP 493
 and --with-external-symbols-in-bundles=public [v5]
In-Reply-To: <R-zg2t6gMm9oZgSijkRxJ0ErqtvoFeqPyfUGbhZRkEQ=.17b0ed93-ea7b-4a37-8471-12624c937a71@github.com>
References: <R-zg2t6gMm9oZgSijkRxJ0ErqtvoFeqPyfUGbhZRkEQ=.17b0ed93-ea7b-4a37-8471-12624c937a71@github.com>
Message-ID: <CiNE3eeM7k4dZbd6OVhNBaZMpXs-s4DQ3spQgRpAMFI=.812042ff-df41-4ed1-a666-4a894e813af2@github.com>

> This PR addresses an issue that can be observed when building on Windows with configure options `--enable-linkable-runtime` and `--with-external-symbols-in-bundles=public`.
> 
> The problem is that with this special build configuration, we build two sets of .pdb files for the binaries. The first set is the standard debug symbols files named <binary-name>.pdb. The second set consists of stripped debug symbols file called <binary-name>.stripped.pdb which have less information but enough to present line numbers in hs-err files.
> 
> During build we use the *.stripped.pdb files for compiling the jmods and also the bundle files. However, in the images folder, both sets of .pdb files exist. The tests for runtime linking will now, in the absence of jmod files, pick up the .pdb files (without *stripped*) from images, but in the runtime the hashes of the *stripped* files are stored.
> 
> With this change, the standard .pdb files in the `--with-external-symbols-in-bundles=public` configuration are now the stripped files and we create a set of full pdb files named *.full.pdb. Jmods and Bundles still contain the stripped pdb files and we also fix the issue that the debug symbols bundle also contained stripped pdb files so far. With this fix, it will contain the full pdb files and extracting these over a JDK runtime will replace stripped pdbs with full pdbs.

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

  Revert to build of stripped pdbs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24012/files
  - new: https://git.openjdk.org/jdk/pull/24012/files/7a409863..96aef215

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

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

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

From clanger at openjdk.org  Mon Dec  1 09:31:58 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Mon, 1 Dec 2025 09:31:58 GMT
Subject: RFR: 8351842: Windows specific issues in combination of JEP 493
 and --with-external-symbols-in-bundles=public [v6]
In-Reply-To: <R-zg2t6gMm9oZgSijkRxJ0ErqtvoFeqPyfUGbhZRkEQ=.17b0ed93-ea7b-4a37-8471-12624c937a71@github.com>
References: <R-zg2t6gMm9oZgSijkRxJ0ErqtvoFeqPyfUGbhZRkEQ=.17b0ed93-ea7b-4a37-8471-12624c937a71@github.com>
Message-ID: <7xjbY7Wkdo7ImiFeTdjUWgYkB-7155QLLxtZ13M3-Io=.d86b647e-6335-43ea-bf1c-ccd2113e74dd@github.com>

> This PR addresses an issue that can be observed when building on Windows with configure options `--enable-linkable-runtime` and `--with-external-symbols-in-bundles=public`.
> 
> The problem is that with this special build configuration, we build two sets of .pdb files for the binaries. The first set is the standard debug symbols files named <binary-name>.pdb. The second set consists of stripped debug symbols file called <binary-name>.stripped.pdb which have less information but enough to present line numbers in hs-err files.
> 
> During build we use the *.stripped.pdb files for compiling the jmods and also the bundle files. However, in the images folder, both sets of .pdb files exist. The tests for runtime linking will now, in the absence of jmod files, pick up the .pdb files (without *stripped*) from images, but in the runtime the hashes of the *stripped* files are stored.
> 
> With this change, the standard .pdb files in the `--with-external-symbols-in-bundles=public` configuration are now the stripped files and we create a set of full pdb files named *.full.pdb. Jmods and Bundles still contain the stripped pdb files and we also fix the issue that the debug symbols bundle also contained stripped pdb files so far. With this fix, it will contain the full pdb files and extracting these over a JDK runtime will replace stripped pdbs with full pdbs.

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

 - Cleanup comment
 - Fix pdb filtering for JMODs build

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24012/files
  - new: https://git.openjdk.org/jdk/pull/24012/files/96aef215..ca92b6a1

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

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

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

From fthevene at redhat.com  Mon Dec  1 09:41:41 2025
From: fthevene at redhat.com (Frederic Thevenet)
Date: Mon, 1 Dec 2025 10:41:41 +0100
Subject: Any reason why +PrintFlagsFinal requires unlocking experimental
 and diagnostic flags to print their default values?
In-Reply-To: <75d56d4d-6d4d-48c1-8d9d-86d92249346d@oracle.com>
References: <849ebf93-c3fb-45c9-92c8-21a49b3e9946@redhat.com>
 <5ff2a0a5-9d61-466d-9ada-5ba911185815@oracle.com>
 <CAA-vtUw=7=NQvzV1bP6AsCKsJruKZ4KvQaSimczD8NY-44X_=w@mail.gmail.com>
 <75d56d4d-6d4d-48c1-8d9d-86d92249346d@oracle.com>
Message-ID: <e03864c5-1dc9-492a-89b5-146706cd2c4c@redhat.com>

Thanks for filling the bug, David; I've assigned it to myself and will 
propose a PR for this shortly.

Before I do, there's one point I feel might be worth clarifying in this 
discussion first.
In the current implementation, PrintFlagsFinal and PrintFlagsRanges are 
quite tightly intertwined, as one acts as an "upgrade" to the other 
(i.e. setting PrintFlagsRanges will override PrintFlagsFinal).
To me, it makes sense to change the behaviour for PrintFlagsRanges to 
also print all flags if we do it for PrintFlagsFinal, but I wanted to 
first ask if anyone sees a reason not to do this?

Cheers
Frederic

On 12/1/25 10:21, David Holmes wrote:
> Okay I have filed:
>
> JDK-8372802: PrintFlagsFinal should also print locked flags
>
> but note there is no commitment for anyone to actually perform the work.
>
> David
>
> On 28/11/2025 3:19 pm, Thomas St?fe wrote:
>> I am very much in favor of printing all flags, for the reasons 
>> Frederic has given. When one supports many different releases, it is 
>> a huge timesaver not to have to look up flags but see them right 
>> there in the customer logs. The ability of PrintFlagsFinal to give me 
>> all flags, including default values, after they are resolved to their 
>> final values, is also very useful during development.
>>
>> For simplicity, I would prefer just to change the behavior of 
>> PrintFlagsFinal to do that, but I could live with a new 
>> PrintAllFlagsFinal.
>>
>> Number of normal flags: 513, incl. diagnostic: 777, incl. 
>> experimental&diagnostic: 933. (Jdk 25). So, it's?a bit more. I am not 
>> bothered by this, since this list never fits onto a single screen 
>> anyway. People grep. But if others prefer an extra flag, sure, 
>> let's?have one.
>>
>>
>> On Thu, Nov 27, 2025 at 3:05?AM David Holmes <david.holmes at oracle.com 
>> <mailto:david.holmes at oracle.com>> wrote:
>>
>> ??? On 27/11/2025 12:53 am, Frederic Thevenet wrote:
>> ???? > Hi,
>> ???? >
>> ???? > Currently, using +PrintFlagsFinal prints out all JVM flags and 
>> their
>> ???? > values, even if they were not modified from their default, except
>> ??? for
>> ???? > 'locked' flags, i.e. Experimental and Diagnotic flags. In order
>> ??? to have
>> ???? > those printed out as well, one must first 'unlock' them (with
>> ???? > +UnlockExperimentalVMOptions, for instance).
>>
>> ??? I think this was simply a pragmatic decision to avoid 
>> overwhelming the
>> ??? user with information that should not be relevant.
>> ???? > Now, is their a strong reason for not always displaying the 
>> default
>> ???? > values for those in scenarios were there is no concerns that the
>> ??? output
>> ???? > might be too large (that is when calling upon
>> ??? 'JVMFlag::printFlags' with
>> ???? > 'skipDefaults' set to false, like PrintFlagsFinal does)?
>> ???? >
>> ???? > The reason for this question is that when chasing a bug in 
>> scenarios
>> ???? > where one can only rely on logs or output provided by tools that
>> ??? uses
>> ???? > +PrintFlagsFinal, getting the default values *in the 
>> conditions that
>> ???? > those logs where produced* can be tricky as it depends on the 
>> exact
>> ???? > version of the JDK that was running, and some values can be
>> ??? changed by
>> ???? > ergonomics.
>>
>> ??? Ouch. I think that would be a poor design choice for diagnostic, and
>> ??? especially experimental flags!
>>
>>
>> Not every experimental/diagnostic flag is a boolean that defaults to 
>> false and controls an opt-in feature. We have non-boolean 
>> experimental flags and boolean flags that default to true. It is not 
>> unthinkable that those are changed during VM start.
>>
>>
>> ???? > If you need to know the default for experimental flags -- which
>> ??? given
>> ???? > their nature can and do change often -- your choices are to
>> ??? either ask
>> ???? > for these logs to be generated again using
>> ??? +UnlockExperimentalVMOptions
>> ???? > (even if there is no intention of changing an experimental flag)
>> ??? or to
>> ???? > go on a time consuming deep dive into the code base for the exact
>> ???? > version of the JDK that was used. Neither is ideal.
>>
>> ??? True, but for experimental flags in particular, unless you are deep
>> ??? diving into the code how can you know whether a particular flag 
>> and its
>> ??? value are relevant to your debugging in the first place?
>>
>>
>> I think the point here is reducing analyst strain. It's?not that it 
>> is impossible to get the information otherwise, but that 
>> it's?convenient and stress-reducing to have one sure way to look up 
>> all resolved flag?values for a customer's JVM run. Folks who have to 
>> work with many cases involving different JVM versions would value this.
>>
>> BTW, we do print default values for non-experimental non-diagnostic 
>> flags, too. The same reasoning applies here: if its?not changed, you 
>> could look up the default value.
>>
>>
>> ??? That said, I don't see any harm in providing a way to print all 
>> flags,
>> ??? though whether by default or by a new -XX:PrintAllFlagsFinal 
>> flag, I'm
>> ??? not sure.
>>
>>
>> Wonderful, let's?do that then.
>>
>> Cheers, Thomas
>

-- 
Frederic Thevenet
Senior Software Engineer - OpenJDK
Red Hat France <https://www.redhat.com>
BAF5 C2D2 0BE0 1715 5EE1 0815 2065 AD47 B326 EB92



From thomas.stuefe at gmail.com  Mon Dec  1 09:55:35 2025
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 1 Dec 2025 10:55:35 +0100
Subject: Any reason why +PrintFlagsFinal requires unlocking experimental
 and diagnostic flags to print their default values?
In-Reply-To: <e03864c5-1dc9-492a-89b5-146706cd2c4c@redhat.com>
References: <849ebf93-c3fb-45c9-92c8-21a49b3e9946@redhat.com>
 <5ff2a0a5-9d61-466d-9ada-5ba911185815@oracle.com>
 <CAA-vtUw=7=NQvzV1bP6AsCKsJruKZ4KvQaSimczD8NY-44X_=w@mail.gmail.com>
 <75d56d4d-6d4d-48c1-8d9d-86d92249346d@oracle.com>
 <e03864c5-1dc9-492a-89b5-146706cd2c4c@redhat.com>
Message-ID: <CAA-vtUyVoG6nn7NPTx7Yse2xmVvgVDg_dRqVRhP+TfMRq72ndw@mail.gmail.com>

Yes, they should behave the same.

Cheers, Thomas

On Mon, Dec 1, 2025 at 10:41?AM Frederic Thevenet <fthevene at redhat.com>
wrote:

> Thanks for filling the bug, David; I've assigned it to myself and will
> propose a PR for this shortly.
>
> Before I do, there's one point I feel might be worth clarifying in this
> discussion first.
> In the current implementation, PrintFlagsFinal and PrintFlagsRanges are
> quite tightly intertwined, as one acts as an "upgrade" to the other
> (i.e. setting PrintFlagsRanges will override PrintFlagsFinal).
> To me, it makes sense to change the behaviour for PrintFlagsRanges to
> also print all flags if we do it for PrintFlagsFinal, but I wanted to
> first ask if anyone sees a reason not to do this?
>
> Cheers
> Frederic
>
> On 12/1/25 10:21, David Holmes wrote:
> > Okay I have filed:
> >
> > JDK-8372802: PrintFlagsFinal should also print locked flags
> >
> > but note there is no commitment for anyone to actually perform the work.
> >
> > David
> >
> > On 28/11/2025 3:19 pm, Thomas St?fe wrote:
> >> I am very much in favor of printing all flags, for the reasons
> >> Frederic has given. When one supports many different releases, it is
> >> a huge timesaver not to have to look up flags but see them right
> >> there in the customer logs. The ability of PrintFlagsFinal to give me
> >> all flags, including default values, after they are resolved to their
> >> final values, is also very useful during development.
> >>
> >> For simplicity, I would prefer just to change the behavior of
> >> PrintFlagsFinal to do that, but I could live with a new
> >> PrintAllFlagsFinal.
> >>
> >> Number of normal flags: 513, incl. diagnostic: 777, incl.
> >> experimental&diagnostic: 933. (Jdk 25). So, it's a bit more. I am not
> >> bothered by this, since this list never fits onto a single screen
> >> anyway. People grep. But if others prefer an extra flag, sure,
> >> let's have one.
> >>
> >>
> >> On Thu, Nov 27, 2025 at 3:05?AM David Holmes <david.holmes at oracle.com
> >> <mailto:david.holmes at oracle.com>> wrote:
> >>
> >>     On 27/11/2025 12:53 am, Frederic Thevenet wrote:
> >>      > Hi,
> >>      >
> >>      > Currently, using +PrintFlagsFinal prints out all JVM flags and
> >> their
> >>      > values, even if they were not modified from their default, except
> >>     for
> >>      > 'locked' flags, i.e. Experimental and Diagnotic flags. In order
> >>     to have
> >>      > those printed out as well, one must first 'unlock' them (with
> >>      > +UnlockExperimentalVMOptions, for instance).
> >>
> >>     I think this was simply a pragmatic decision to avoid
> >> overwhelming the
> >>     user with information that should not be relevant.
> >>      > Now, is their a strong reason for not always displaying the
> >> default
> >>      > values for those in scenarios were there is no concerns that the
> >>     output
> >>      > might be too large (that is when calling upon
> >>     'JVMFlag::printFlags' with
> >>      > 'skipDefaults' set to false, like PrintFlagsFinal does)?
> >>      >
> >>      > The reason for this question is that when chasing a bug in
> >> scenarios
> >>      > where one can only rely on logs or output provided by tools that
> >>     uses
> >>      > +PrintFlagsFinal, getting the default values *in the
> >> conditions that
> >>      > those logs where produced* can be tricky as it depends on the
> >> exact
> >>      > version of the JDK that was running, and some values can be
> >>     changed by
> >>      > ergonomics.
> >>
> >>     Ouch. I think that would be a poor design choice for diagnostic, and
> >>     especially experimental flags!
> >>
> >>
> >> Not every experimental/diagnostic flag is a boolean that defaults to
> >> false and controls an opt-in feature. We have non-boolean
> >> experimental flags and boolean flags that default to true. It is not
> >> unthinkable that those are changed during VM start.
> >>
> >>
> >>      > If you need to know the default for experimental flags -- which
> >>     given
> >>      > their nature can and do change often -- your choices are to
> >>     either ask
> >>      > for these logs to be generated again using
> >>     +UnlockExperimentalVMOptions
> >>      > (even if there is no intention of changing an experimental flag)
> >>     or to
> >>      > go on a time consuming deep dive into the code base for the exact
> >>      > version of the JDK that was used. Neither is ideal.
> >>
> >>     True, but for experimental flags in particular, unless you are deep
> >>     diving into the code how can you know whether a particular flag
> >> and its
> >>     value are relevant to your debugging in the first place?
> >>
> >>
> >> I think the point here is reducing analyst strain. It's not that it
> >> is impossible to get the information otherwise, but that
> >> it's convenient and stress-reducing to have one sure way to look up
> >> all resolved flag values for a customer's JVM run. Folks who have to
> >> work with many cases involving different JVM versions would value this.
> >>
> >> BTW, we do print default values for non-experimental non-diagnostic
> >> flags, too. The same reasoning applies here: if its not changed, you
> >> could look up the default value.
> >>
> >>
> >>     That said, I don't see any harm in providing a way to print all
> >> flags,
> >>     though whether by default or by a new -XX:PrintAllFlagsFinal
> >> flag, I'm
> >>     not sure.
> >>
> >>
> >> Wonderful, let's do that then.
> >>
> >> Cheers, Thomas
> >
>
> --
> Frederic Thevenet
> Senior Software Engineer - OpenJDK
> Red Hat France <https://www.redhat.com>
> BAF5 C2D2 0BE0 1715 5EE1 0815 2065 AD47 B326 EB92
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20251201/0dd16aae/attachment-0001.htm>

From david.holmes at oracle.com  Mon Dec  1 09:59:41 2025
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 1 Dec 2025 19:59:41 +1000
Subject: Any reason why +PrintFlagsFinal requires unlocking experimental
 and diagnostic flags to print their default values?
In-Reply-To: <e03864c5-1dc9-492a-89b5-146706cd2c4c@redhat.com>
References: <849ebf93-c3fb-45c9-92c8-21a49b3e9946@redhat.com>
 <5ff2a0a5-9d61-466d-9ada-5ba911185815@oracle.com>
 <CAA-vtUw=7=NQvzV1bP6AsCKsJruKZ4KvQaSimczD8NY-44X_=w@mail.gmail.com>
 <75d56d4d-6d4d-48c1-8d9d-86d92249346d@oracle.com>
 <e03864c5-1dc9-492a-89b5-146706cd2c4c@redhat.com>
Message-ID: <40274532-c875-4339-81cf-00b4c0776536@oracle.com>

On 1/12/2025 7:41 pm, Frederic Thevenet wrote:
> Thanks for filling the bug, David; I've assigned it to myself and will 
> propose a PR for this shortly.
> 
> Before I do, there's one point I feel might be worth clarifying in this 
> discussion first.
> In the current implementation, PrintFlagsFinal and PrintFlagsRanges are 
> quite tightly intertwined, as one acts as an "upgrade" to the other 
> (i.e. setting PrintFlagsRanges will override PrintFlagsFinal).
> To me, it makes sense to change the behaviour for PrintFlagsRanges to 
> also print all flags if we do it for PrintFlagsFinal, but I wanted to 
> first ask if anyone sees a reason not to do this?

I think that makes sense. Though you can then extend the same logic to 
PrintFlagsInitial and even PrintFlagsWithComments, so the scope expands. 
If you just want to restrict the change to PrintFlagsFinal then I think 
the simplest thing is to just expand:

void JVMFlag::printFlags(outputStream* out, bool withComments, bool 
printRanges, bool skipDefaults) {

to

void JVMFlag::printFlags(outputStream* out, bool withComments, bool 
printRanges, bool skipDefaults, bool printLocked) {

and then have

   // All the flags that get adjusted by VM_Version_init and os::init_2
   // have been set so dump the flags now.
   if (PrintFlagsFinal || PrintFlagsRanges) {
     JVMFlag::printFlags(tty, false, PrintFlagsRanges, false, 
PrintFlagsFinal);
   }

David
> Cheers
> Frederic
> 
> On 12/1/25 10:21, David Holmes wrote:
>> Okay I have filed:
>>
>> JDK-8372802: PrintFlagsFinal should also print locked flags
>>
>> but note there is no commitment for anyone to actually perform the work.
>>
>> David
>>
>> On 28/11/2025 3:19 pm, Thomas St?fe wrote:
>>> I am very much in favor of printing all flags, for the reasons 
>>> Frederic has given. When one supports many different releases, it is 
>>> a huge timesaver not to have to look up flags but see them right 
>>> there in the customer logs. The ability of PrintFlagsFinal to give me 
>>> all flags, including default values, after they are resolved to their 
>>> final values, is also very useful during development.
>>>
>>> For simplicity, I would prefer just to change the behavior of 
>>> PrintFlagsFinal to do that, but I could live with a new 
>>> PrintAllFlagsFinal.
>>>
>>> Number of normal flags: 513, incl. diagnostic: 777, incl. 
>>> experimental&diagnostic: 933. (Jdk 25). So, it's?a bit more. I am not 
>>> bothered by this, since this list never fits onto a single screen 
>>> anyway. People grep. But if others prefer an extra flag, sure, 
>>> let's?have one.
>>>
>>>
>>> On Thu, Nov 27, 2025 at 3:05?AM David Holmes <david.holmes at oracle.com 
>>> <mailto:david.holmes at oracle.com>> wrote:
>>>
>>> ??? On 27/11/2025 12:53 am, Frederic Thevenet wrote:
>>> ???? > Hi,
>>> ???? >
>>> ???? > Currently, using +PrintFlagsFinal prints out all JVM flags and 
>>> their
>>> ???? > values, even if they were not modified from their default, except
>>> ??? for
>>> ???? > 'locked' flags, i.e. Experimental and Diagnotic flags. In order
>>> ??? to have
>>> ???? > those printed out as well, one must first 'unlock' them (with
>>> ???? > +UnlockExperimentalVMOptions, for instance).
>>>
>>> ??? I think this was simply a pragmatic decision to avoid 
>>> overwhelming the
>>> ??? user with information that should not be relevant.
>>> ???? > Now, is their a strong reason for not always displaying the 
>>> default
>>> ???? > values for those in scenarios were there is no concerns that the
>>> ??? output
>>> ???? > might be too large (that is when calling upon
>>> ??? 'JVMFlag::printFlags' with
>>> ???? > 'skipDefaults' set to false, like PrintFlagsFinal does)?
>>> ???? >
>>> ???? > The reason for this question is that when chasing a bug in 
>>> scenarios
>>> ???? > where one can only rely on logs or output provided by tools that
>>> ??? uses
>>> ???? > +PrintFlagsFinal, getting the default values *in the 
>>> conditions that
>>> ???? > those logs where produced* can be tricky as it depends on the 
>>> exact
>>> ???? > version of the JDK that was running, and some values can be
>>> ??? changed by
>>> ???? > ergonomics.
>>>
>>> ??? Ouch. I think that would be a poor design choice for diagnostic, and
>>> ??? especially experimental flags!
>>>
>>>
>>> Not every experimental/diagnostic flag is a boolean that defaults to 
>>> false and controls an opt-in feature. We have non-boolean 
>>> experimental flags and boolean flags that default to true. It is not 
>>> unthinkable that those are changed during VM start.
>>>
>>>
>>> ???? > If you need to know the default for experimental flags -- which
>>> ??? given
>>> ???? > their nature can and do change often -- your choices are to
>>> ??? either ask
>>> ???? > for these logs to be generated again using
>>> ??? +UnlockExperimentalVMOptions
>>> ???? > (even if there is no intention of changing an experimental flag)
>>> ??? or to
>>> ???? > go on a time consuming deep dive into the code base for the exact
>>> ???? > version of the JDK that was used. Neither is ideal.
>>>
>>> ??? True, but for experimental flags in particular, unless you are deep
>>> ??? diving into the code how can you know whether a particular flag 
>>> and its
>>> ??? value are relevant to your debugging in the first place?
>>>
>>>
>>> I think the point here is reducing analyst strain. It's?not that it 
>>> is impossible to get the information otherwise, but that 
>>> it's?convenient and stress-reducing to have one sure way to look up 
>>> all resolved flag?values for a customer's JVM run. Folks who have to 
>>> work with many cases involving different JVM versions would value this.
>>>
>>> BTW, we do print default values for non-experimental non-diagnostic 
>>> flags, too. The same reasoning applies here: if its?not changed, you 
>>> could look up the default value.
>>>
>>>
>>> ??? That said, I don't see any harm in providing a way to print all 
>>> flags,
>>> ??? though whether by default or by a new -XX:PrintAllFlagsFinal 
>>> flag, I'm
>>> ??? not sure.
>>>
>>>
>>> Wonderful, let's?do that then.
>>>
>>> Cheers, Thomas
>>
> 


From fthevene at redhat.com  Mon Dec  1 10:10:25 2025
From: fthevene at redhat.com (Frederic Thevenet)
Date: Mon, 1 Dec 2025 11:10:25 +0100
Subject: Any reason why +PrintFlagsFinal requires unlocking experimental
 and diagnostic flags to print their default values?
In-Reply-To: <40274532-c875-4339-81cf-00b4c0776536@oracle.com>
References: <849ebf93-c3fb-45c9-92c8-21a49b3e9946@redhat.com>
 <5ff2a0a5-9d61-466d-9ada-5ba911185815@oracle.com>
 <CAA-vtUw=7=NQvzV1bP6AsCKsJruKZ4KvQaSimczD8NY-44X_=w@mail.gmail.com>
 <75d56d4d-6d4d-48c1-8d9d-86d92249346d@oracle.com>
 <e03864c5-1dc9-492a-89b5-146706cd2c4c@redhat.com>
 <40274532-c875-4339-81cf-00b4c0776536@oracle.com>
Message-ID: <75941750-84ae-4ce7-8748-3dcac82d4628@redhat.com>



On 12/1/25 10:59, David Holmes wrote:
> On 1/12/2025 7:41 pm, Frederic Thevenet wrote:
>> Thanks for filling the bug, David; I've assigned it to myself and 
>> will propose a PR for this shortly.
>>
>> Before I do, there's one point I feel might be worth clarifying in 
>> this discussion first.
>> In the current implementation, PrintFlagsFinal and PrintFlagsRanges 
>> are quite tightly intertwined, as one acts as an "upgrade" to the 
>> other (i.e. setting PrintFlagsRanges will override PrintFlagsFinal).
>> To me, it makes sense to change the behaviour for PrintFlagsRanges to 
>> also print all flags if we do it for PrintFlagsFinal, but I wanted to 
>> first ask if anyone sees a reason not to do this?
>
> I think that makes sense. Though you can then extend the same logic to 
> PrintFlagsInitial and even PrintFlagsWithComments, so the scope 
> expands. If you just want to restrict the change to PrintFlagsFinal 
> then I think the simplest thing is to just expand:
>
> void JVMFlag::printFlags(outputStream* out, bool withComments, bool 
> printRanges, bool skipDefaults) {
>
> to
>
> void JVMFlag::printFlags(outputStream* out, bool withComments, bool 
> printRanges, bool skipDefaults, bool printLocked) {
>
> and then have
>
> ? // All the flags that get adjusted by VM_Version_init and os::init_2
> ? // have been set so dump the flags now.
> ? if (PrintFlagsFinal || PrintFlagsRanges) {
> ??? JVMFlag::printFlags(tty, false, PrintFlagsRanges, false, 
> PrintFlagsFinal);
> ? }

With regard to PrintFlagsInitial or PrintFlagsWithComments, it wasn't my 
primary goal to change these but I can certainly look into it while I'm 
at it if there is a consensus that it is in fact a good idea.
Anyone care to? comment?

>
> David
>> Cheers
>> Frederic
>>
>> On 12/1/25 10:21, David Holmes wrote:
>>> Okay I have filed:
>>>
>>> JDK-8372802: PrintFlagsFinal should also print locked flags
>>>
>>> but note there is no commitment for anyone to actually perform the 
>>> work.
>>>
>>> David
>>>
>>> On 28/11/2025 3:19 pm, Thomas St?fe wrote:
>>>> I am very much in favor of printing all flags, for the reasons 
>>>> Frederic has given. When one supports many different releases, it 
>>>> is a huge timesaver not to have to look up flags but see them right 
>>>> there in the customer logs. The ability of PrintFlagsFinal to give 
>>>> me all flags, including default values, after they are resolved to 
>>>> their final values, is also very useful during development.
>>>>
>>>> For simplicity, I would prefer just to change the behavior of 
>>>> PrintFlagsFinal to do that, but I could live with a new 
>>>> PrintAllFlagsFinal.
>>>>
>>>> Number of normal flags: 513, incl. diagnostic: 777, incl. 
>>>> experimental&diagnostic: 933. (Jdk 25). So, it's?a bit more. I am 
>>>> not bothered by this, since this list never fits onto a single 
>>>> screen anyway. People grep. But if others prefer an extra flag, 
>>>> sure, let's?have one.
>>>>
>>>>
>>>> On Thu, Nov 27, 2025 at 3:05?AM David Holmes 
>>>> <david.holmes at oracle.com <mailto:david.holmes at oracle.com>> wrote:
>>>>
>>>> ??? On 27/11/2025 12:53 am, Frederic Thevenet wrote:
>>>> ???? > Hi,
>>>> ???? >
>>>> ???? > Currently, using +PrintFlagsFinal prints out all JVM flags 
>>>> and their
>>>> ???? > values, even if they were not modified from their default, 
>>>> except
>>>> ??? for
>>>> ???? > 'locked' flags, i.e. Experimental and Diagnotic flags. In order
>>>> ??? to have
>>>> ???? > those printed out as well, one must first 'unlock' them (with
>>>> ???? > +UnlockExperimentalVMOptions, for instance).
>>>>
>>>> ??? I think this was simply a pragmatic decision to avoid 
>>>> overwhelming the
>>>> ??? user with information that should not be relevant.
>>>> ???? > Now, is their a strong reason for not always displaying the 
>>>> default
>>>> ???? > values for those in scenarios were there is no concerns that 
>>>> the
>>>> ??? output
>>>> ???? > might be too large (that is when calling upon
>>>> ??? 'JVMFlag::printFlags' with
>>>> ???? > 'skipDefaults' set to false, like PrintFlagsFinal does)?
>>>> ???? >
>>>> ???? > The reason for this question is that when chasing a bug in 
>>>> scenarios
>>>> ???? > where one can only rely on logs or output provided by tools 
>>>> that
>>>> ??? uses
>>>> ???? > +PrintFlagsFinal, getting the default values *in the 
>>>> conditions that
>>>> ???? > those logs where produced* can be tricky as it depends on 
>>>> the exact
>>>> ???? > version of the JDK that was running, and some values can be
>>>> ??? changed by
>>>> ???? > ergonomics.
>>>>
>>>> ??? Ouch. I think that would be a poor design choice for 
>>>> diagnostic, and
>>>> ??? especially experimental flags!
>>>>
>>>>
>>>> Not every experimental/diagnostic flag is a boolean that defaults 
>>>> to false and controls an opt-in feature. We have non-boolean 
>>>> experimental flags and boolean flags that default to true. It is 
>>>> not unthinkable that those are changed during VM start.
>>>>
>>>>
>>>> ???? > If you need to know the default for experimental flags -- which
>>>> ??? given
>>>> ???? > their nature can and do change often -- your choices are to
>>>> ??? either ask
>>>> ???? > for these logs to be generated again using
>>>> ??? +UnlockExperimentalVMOptions
>>>> ???? > (even if there is no intention of changing an experimental 
>>>> flag)
>>>> ??? or to
>>>> ???? > go on a time consuming deep dive into the code base for the 
>>>> exact
>>>> ???? > version of the JDK that was used. Neither is ideal.
>>>>
>>>> ??? True, but for experimental flags in particular, unless you are 
>>>> deep
>>>> ??? diving into the code how can you know whether a particular flag 
>>>> and its
>>>> ??? value are relevant to your debugging in the first place?
>>>>
>>>>
>>>> I think the point here is reducing analyst strain. It's?not that it 
>>>> is impossible to get the information otherwise, but that 
>>>> it's?convenient and stress-reducing to have one sure way to look up 
>>>> all resolved flag?values for a customer's JVM run. Folks who have 
>>>> to work with many cases involving different JVM versions would 
>>>> value this.
>>>>
>>>> BTW, we do print default values for non-experimental non-diagnostic 
>>>> flags, too. The same reasoning applies here: if its?not changed, 
>>>> you could look up the default value.
>>>>
>>>>
>>>> ??? That said, I don't see any harm in providing a way to print all 
>>>> flags,
>>>> ??? though whether by default or by a new -XX:PrintAllFlagsFinal 
>>>> flag, I'm
>>>> ??? not sure.
>>>>
>>>>
>>>> Wonderful, let's?do that then.
>>>>
>>>> Cheers, Thomas
>>>
>>
>

-- 
Frederic Thevenet
Senior Software Engineer - OpenJDK
Red Hat France <https://www.redhat.com>
BAF5 C2D2 0BE0 1715 5EE1 0815 2065 AD47 B326 EB92



From david.holmes at oracle.com  Mon Dec  1 10:17:14 2025
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 1 Dec 2025 20:17:14 +1000
Subject: Any reason why +PrintFlagsFinal requires unlocking experimental
 and diagnostic flags to print their default values?
In-Reply-To: <75941750-84ae-4ce7-8748-3dcac82d4628@redhat.com>
References: <849ebf93-c3fb-45c9-92c8-21a49b3e9946@redhat.com>
 <5ff2a0a5-9d61-466d-9ada-5ba911185815@oracle.com>
 <CAA-vtUw=7=NQvzV1bP6AsCKsJruKZ4KvQaSimczD8NY-44X_=w@mail.gmail.com>
 <75d56d4d-6d4d-48c1-8d9d-86d92249346d@oracle.com>
 <e03864c5-1dc9-492a-89b5-146706cd2c4c@redhat.com>
 <40274532-c875-4339-81cf-00b4c0776536@oracle.com>
 <75941750-84ae-4ce7-8748-3dcac82d4628@redhat.com>
Message-ID: <8cd2493e-6fdf-4399-934a-e74db442265f@oracle.com>

On 1/12/2025 8:10 pm, Frederic Thevenet wrote:
> 
> 
> On 12/1/25 10:59, David Holmes wrote:
>> On 1/12/2025 7:41 pm, Frederic Thevenet wrote:
>>> Thanks for filling the bug, David; I've assigned it to myself and 
>>> will propose a PR for this shortly.
>>>
>>> Before I do, there's one point I feel might be worth clarifying in 
>>> this discussion first.
>>> In the current implementation, PrintFlagsFinal and PrintFlagsRanges 
>>> are quite tightly intertwined, as one acts as an "upgrade" to the 
>>> other (i.e. setting PrintFlagsRanges will override PrintFlagsFinal).
>>> To me, it makes sense to change the behaviour for PrintFlagsRanges to 
>>> also print all flags if we do it for PrintFlagsFinal, but I wanted to 
>>> first ask if anyone sees a reason not to do this?
>>
>> I think that makes sense. Though you can then extend the same logic to 
>> PrintFlagsInitial and even PrintFlagsWithComments, so the scope 
>> expands. If you just want to restrict the change to PrintFlagsFinal 
>> then I think the simplest thing is to just expand:
>>
>> void JVMFlag::printFlags(outputStream* out, bool withComments, bool 
>> printRanges, bool skipDefaults) {
>>
>> to
>>
>> void JVMFlag::printFlags(outputStream* out, bool withComments, bool 
>> printRanges, bool skipDefaults, bool printLocked) {
>>
>> and then have
>>
>> ? // All the flags that get adjusted by VM_Version_init and os::init_2
>> ? // have been set so dump the flags now.
>> ? if (PrintFlagsFinal || PrintFlagsRanges) {
>> ??? JVMFlag::printFlags(tty, false, PrintFlagsRanges, false, 
>> PrintFlagsFinal);
>> ? }
> 
> With regard to PrintFlagsInitial or PrintFlagsWithComments, it wasn't my 
> primary goal to change these but I can certainly look into it while I'm 
> at it if there is a consensus that it is in fact a good idea.
> Anyone care to? comment?

Well there is no obvious reason that these flags should differ in what 
kind of flags they print - they only differ in what data gets printed 
for each flag.

Maybe it is simpler and more consistent to just delete the

  flagTable[i].is_unlocked()

check.

David
>>
>> David
>>> Cheers
>>> Frederic
>>>
>>> On 12/1/25 10:21, David Holmes wrote:
>>>> Okay I have filed:
>>>>
>>>> JDK-8372802: PrintFlagsFinal should also print locked flags
>>>>
>>>> but note there is no commitment for anyone to actually perform the 
>>>> work.
>>>>
>>>> David
>>>>
>>>> On 28/11/2025 3:19 pm, Thomas St?fe wrote:
>>>>> I am very much in favor of printing all flags, for the reasons 
>>>>> Frederic has given. When one supports many different releases, it 
>>>>> is a huge timesaver not to have to look up flags but see them right 
>>>>> there in the customer logs. The ability of PrintFlagsFinal to give 
>>>>> me all flags, including default values, after they are resolved to 
>>>>> their final values, is also very useful during development.
>>>>>
>>>>> For simplicity, I would prefer just to change the behavior of 
>>>>> PrintFlagsFinal to do that, but I could live with a new 
>>>>> PrintAllFlagsFinal.
>>>>>
>>>>> Number of normal flags: 513, incl. diagnostic: 777, incl. 
>>>>> experimental&diagnostic: 933. (Jdk 25). So, it's?a bit more. I am 
>>>>> not bothered by this, since this list never fits onto a single 
>>>>> screen anyway. People grep. But if others prefer an extra flag, 
>>>>> sure, let's?have one.
>>>>>
>>>>>
>>>>> On Thu, Nov 27, 2025 at 3:05?AM David Holmes 
>>>>> <david.holmes at oracle.com <mailto:david.holmes at oracle.com>> wrote:
>>>>>
>>>>> ??? On 27/11/2025 12:53 am, Frederic Thevenet wrote:
>>>>> ???? > Hi,
>>>>> ???? >
>>>>> ???? > Currently, using +PrintFlagsFinal prints out all JVM flags 
>>>>> and their
>>>>> ???? > values, even if they were not modified from their default, 
>>>>> except
>>>>> ??? for
>>>>> ???? > 'locked' flags, i.e. Experimental and Diagnotic flags. In order
>>>>> ??? to have
>>>>> ???? > those printed out as well, one must first 'unlock' them (with
>>>>> ???? > +UnlockExperimentalVMOptions, for instance).
>>>>>
>>>>> ??? I think this was simply a pragmatic decision to avoid 
>>>>> overwhelming the
>>>>> ??? user with information that should not be relevant.
>>>>> ???? > Now, is their a strong reason for not always displaying the 
>>>>> default
>>>>> ???? > values for those in scenarios were there is no concerns that 
>>>>> the
>>>>> ??? output
>>>>> ???? > might be too large (that is when calling upon
>>>>> ??? 'JVMFlag::printFlags' with
>>>>> ???? > 'skipDefaults' set to false, like PrintFlagsFinal does)?
>>>>> ???? >
>>>>> ???? > The reason for this question is that when chasing a bug in 
>>>>> scenarios
>>>>> ???? > where one can only rely on logs or output provided by tools 
>>>>> that
>>>>> ??? uses
>>>>> ???? > +PrintFlagsFinal, getting the default values *in the 
>>>>> conditions that
>>>>> ???? > those logs where produced* can be tricky as it depends on 
>>>>> the exact
>>>>> ???? > version of the JDK that was running, and some values can be
>>>>> ??? changed by
>>>>> ???? > ergonomics.
>>>>>
>>>>> ??? Ouch. I think that would be a poor design choice for 
>>>>> diagnostic, and
>>>>> ??? especially experimental flags!
>>>>>
>>>>>
>>>>> Not every experimental/diagnostic flag is a boolean that defaults 
>>>>> to false and controls an opt-in feature. We have non-boolean 
>>>>> experimental flags and boolean flags that default to true. It is 
>>>>> not unthinkable that those are changed during VM start.
>>>>>
>>>>>
>>>>> ???? > If you need to know the default for experimental flags -- which
>>>>> ??? given
>>>>> ???? > their nature can and do change often -- your choices are to
>>>>> ??? either ask
>>>>> ???? > for these logs to be generated again using
>>>>> ??? +UnlockExperimentalVMOptions
>>>>> ???? > (even if there is no intention of changing an experimental 
>>>>> flag)
>>>>> ??? or to
>>>>> ???? > go on a time consuming deep dive into the code base for the 
>>>>> exact
>>>>> ???? > version of the JDK that was used. Neither is ideal.
>>>>>
>>>>> ??? True, but for experimental flags in particular, unless you are 
>>>>> deep
>>>>> ??? diving into the code how can you know whether a particular flag 
>>>>> and its
>>>>> ??? value are relevant to your debugging in the first place?
>>>>>
>>>>>
>>>>> I think the point here is reducing analyst strain. It's?not that it 
>>>>> is impossible to get the information otherwise, but that 
>>>>> it's?convenient and stress-reducing to have one sure way to look up 
>>>>> all resolved flag?values for a customer's JVM run. Folks who have 
>>>>> to work with many cases involving different JVM versions would 
>>>>> value this.
>>>>>
>>>>> BTW, we do print default values for non-experimental non-diagnostic 
>>>>> flags, too. The same reasoning applies here: if its?not changed, 
>>>>> you could look up the default value.
>>>>>
>>>>>
>>>>> ??? That said, I don't see any harm in providing a way to print all 
>>>>> flags,
>>>>> ??? though whether by default or by a new -XX:PrintAllFlagsFinal 
>>>>> flag, I'm
>>>>> ??? not sure.
>>>>>
>>>>>
>>>>> Wonderful, let's?do that then.
>>>>>
>>>>> Cheers, Thomas
>>>>
>>>
>>
> 


From aartemov at openjdk.org  Mon Dec  1 10:18:49 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Mon, 1 Dec 2025 10:18:49 GMT
Subject: RFR: 8366671: Refactor Thread::SpinAcquire and Thread::SpinRelease
 [v9]
In-Reply-To: <8aNv20VZljWCq6M_lZKe6dhlahN0nHoH91JDHEeIo8Y=.3d917870-0e49-4e40-95e2-df9dcaa3fe4d@github.com>
References: <NtY8E8fBeSokCAQYP3OQEwfnppSugtTJ8uAtQtD0zvg=.88f2988d-47fd-4b8a-af89-488ed6b37870@github.com>
 <3bBZzigernOcTkARE9am0ZmHR9NWsmp3xa0ksSLYiE8=.981d0f10-5b41-40c8-a35c-f953b0d1df08@github.com>
 <8aNv20VZljWCq6M_lZKe6dhlahN0nHoH91JDHEeIo8Y=.3d917870-0e49-4e40-95e2-df9dcaa3fe4d@github.com>
Message-ID: <svlyDLeLPwYpnzHM6cP8UPc7pkMninSM-3xd2FUesQY=.027d3aa9-1e6d-433a-ac74-4e1d682c751f@github.com>

On Tue, 25 Nov 2025 08:14:14 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> I think this looks good, but we should add a `NoSafepointVerifier` to this `SpinCriticalSection` RAII object. Polling for a safepoint inside a SpinLock should never be allowed.

Adding a `NoSafepointVerifier` before `spin_acquire()` breaks creation of the main thread. The problem is in `ParkEvent::Allocate(this)`. And there is a comment in park.cpp: "Caveat: Allocate() and Release() may be called from threads other than the thread associated with the Event!". So it breaks the assert in `Thread::current()`. Any other way how to ensure no polling for safepoint?

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

PR Comment: https://git.openjdk.org/jdk/pull/28264#issuecomment-3595724880

From aartemov at openjdk.org  Mon Dec  1 10:26:11 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Mon, 1 Dec 2025 10:26:11 GMT
Subject: RFR: 8366671: Refactor Thread::SpinAcquire and Thread::SpinRelease
 [v11]
In-Reply-To: <NtY8E8fBeSokCAQYP3OQEwfnppSugtTJ8uAtQtD0zvg=.88f2988d-47fd-4b8a-af89-488ed6b37870@github.com>
References: <NtY8E8fBeSokCAQYP3OQEwfnppSugtTJ8uAtQtD0zvg=.88f2988d-47fd-4b8a-af89-488ed6b37870@github.com>
Message-ID: <HXl-QIjv4k5gmBBna_64ZrLlEHQG-FJBmJNRmZoXU4g=.3ab00c25-74a1-49d7-8300-5f7ed3a906a6@github.com>

> Hi, 
> 
> please consider the following changes:
> 
> In this PR `Thread::SpinAcquire()` and `Thread::SpinRelease()` methods are refactored into a utility class `SpinCriticalSection`. The motivation is to make it easier for developers to use this lightweight synchronization mechanism in the codebase. The two aforementioned methods were used in JFR to create short critical sections with a helper class, but that was not the case for the object monitor code. 
> 
> Tested in tiers 1 - 5.

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

  8366671: Modified the comment.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28264/files
  - new: https://git.openjdk.org/jdk/pull/28264/files/b2483bf6..a418211f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28264&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28264&range=09-10

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

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

From aartemov at openjdk.org  Mon Dec  1 10:26:13 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Mon, 1 Dec 2025 10:26:13 GMT
Subject: RFR: 8366671: Refactor Thread::SpinAcquire and Thread::SpinRelease
 [v9]
In-Reply-To: <56YOm7QzXMRjq9Whk6uOWUSWDBd7mqNMWsLVdXuDW6s=.f476cd41-5725-474d-920b-0a43f880828c@github.com>
References: <NtY8E8fBeSokCAQYP3OQEwfnppSugtTJ8uAtQtD0zvg=.88f2988d-47fd-4b8a-af89-488ed6b37870@github.com>
 <3bBZzigernOcTkARE9am0ZmHR9NWsmp3xa0ksSLYiE8=.981d0f10-5b41-40c8-a35c-f953b0d1df08@github.com>
 <56YOm7QzXMRjq9Whk6uOWUSWDBd7mqNMWsLVdXuDW6s=.f476cd41-5725-474d-920b-0a43f880828c@github.com>
Message-ID: <xLobo0BGfdPkJUrV0Q4KNedjTaMwlIVEeUm4PJwTo1A=.16c47a5e-ed40-4af4-9d42-a372aad5a312@github.com>

On Mon, 24 Nov 2025 01:34:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8366671: Addressed reviewer's comments.
>
> src/hotspot/share/utilities/spinCriticalSection.hpp line 37:
> 
>> 35: // we're concerned about native mutex_t or HotSpot Mutex:: latency.
>> 36: // The class uses low-level leaf-lock primitives to implement
>> 37: // synchronization. Not for general synchronization use.
> 
> Suggestion:
> 
> // This class uses low-level leaf-lock primitives to implement
> // synchronization and is not for general synchronization use.

Addressed in the latest commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28264#discussion_r2576496110

From clanger at openjdk.org  Mon Dec  1 10:42:56 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Mon, 1 Dec 2025 10:42:56 GMT
Subject: RFR: 8351842: Windows specific issues in combination of JEP 493
 and --with-external-symbols-in-bundles=public [v3]
In-Reply-To: <zAVY_tvrzdlYTxPmO3R4Gs0AZS2l6_6gEeLh5j7s2-w=.0883fa0f-4eb2-4e82-85bf-2147c1caf4b4@github.com>
References: <R-zg2t6gMm9oZgSijkRxJ0ErqtvoFeqPyfUGbhZRkEQ=.17b0ed93-ea7b-4a37-8471-12624c937a71@github.com>
 <SJkKq0lzVvG-ph0aM7DJEF6kqlhvM0AJA2Jq66X07Lc=.d660277d-051b-4603-b226-dc68fc0efde7@github.com>
 <cPyMs_VS1tVak3YoEwvph_yYnNzv4mFcqWBDjflTM9E=.e26078b2-328e-424b-9d19-f29ed09a629e@github.com>
 <zAVY_tvrzdlYTxPmO3R4Gs0AZS2l6_6gEeLh5j7s2-w=.0883fa0f-4eb2-4e82-85bf-2147c1caf4b4@github.com>
Message-ID: <bSlfMWvaChBXXN1DKLcudgWsFqqcweuZ2N7-QrcAbNE=.2d618bda-6d00-4a02-a784-2ded0f7e99aa@github.com>

On Wed, 22 Oct 2025 22:47:34 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> OK, I believe I understand what you're saying. Do you know where the place is where the JDK_IMAGE_DIR is created and renaming/filtering of the pdb files would need to happen?
>
>> OK, I believe I understand what you're saying. Do you know where the place is where the JDK_IMAGE_DIR is created and renaming/filtering of the pdb files would need to happen?
> 
> So the change would be to _not_ copy debug symbols to the `JDK_IMAGE_DIR` when `--with-external-symbols-in-bundles=public` is set. I think this would be the line you need to put conditions around: https://github.com/openjdk/jdk/blob/be18e7ecfd2e89a0abb168e0d9a5b69598e2199f/make/Images.gmk#L307

OK, finally I have updated my PR to implement the suggestions of @erikj79. Now the exploded image during the build will only contain the full pdb files and in the actual JDK and JRE images, we'll have the stripped pdb files (as well as in the jmods), if the option is set. And this also propagates to bundles. The debug image/debug bundle will of course only have the full symbol files.

I also update the test test/hotspot/jtreg/runtime/NMT/CheckForProperDetailStackTrace.java to expect debug symbols in case configure option `--with-external-symbols-in-bundles` is non-empty. This also contains some updates to the Whitebox functionality for checking which kind of debug symbols should be delivered and cleanup of test test/hotspot/jtreg/runtime/NMT/CheckForProperDetailStackTrace.java which was modified already with [JDK-8370064](https://bugs.openjdk.org/browse/JDK-8370064).

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

PR Comment: https://git.openjdk.org/jdk/pull/24012#issuecomment-3595830306

From qamai at openjdk.org  Mon Dec  1 10:53:48 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 1 Dec 2025 10:53:48 GMT
Subject: RFR: 8372779: C2: Disambiguate Node::adr_type for the IR graph
 [v2]
In-Reply-To: <dEidZLl1MkM6TbAxS2FsitU70AYAahwzK9cun61wwV8=.ccdad883-5d8f-403e-a19f-40aef0f53b11@github.com>
References: <dEidZLl1MkM6TbAxS2FsitU70AYAahwzK9cun61wwV8=.ccdad883-5d8f-403e-a19f-40aef0f53b11@github.com>
Message-ID: <qs3vbSxq7fVTebFQj3VRBgRzBfLyEDfqlxUKy-cvrF4=.001f5d80-b24b-4626-84ba-32f47f2019ed@github.com>

> Hi,
> 
> Currently, `Node::adr_type` is ambiguous. For some, it refers to the memory the node consumes, while for the others, it refer to the memory the node produces. This PR removes that ambiguity by introducing `Node::in_adr_type` and `Node::out_adr_type` that refer to those properties, respectively. It also introduces a local verification of the memory graph during compilation. These additions uncover some issues:
> 
> - Sometimes, the memory is wired incorrectly, such as in `LibraryCall::extend_setCurrentThread`, the `Phi` collect the `StoreNode`s instead of the whole memory state. I think these issues do not result in crashes or miscompilation, though.
> - `AryEqNode` reports `adr_type` being `TypeAryPtr::BYTES` (it inherits this from `StrIntrinsicNode`). This is incorrect, however, as it can accept `char[]` inputs, too.
> - For nodes such as `StrInflatedCopyNode`, as it consumes more than it produces, during scheduling, we need to compute anti-dependencies. This is not the case, so I fixed it by making it kill all the memory it consumes.
> - `GraphKit::set_output_for_allocation` uses a raw `ProjNode` as the base for a `MergeMem`, this is really suspicious. I didn't fix it, as it seems to not result in any symptom at the moment.
> 
> In the end, the execution of the compiler is strictly more restricted than before, and there is less room for ambiguity.
> 
> Please take a look and leave your reviews, thanks a lot.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  store_to_memory does not emit MemBars

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28570/files
  - new: https://git.openjdk.org/jdk/pull/28570/files/10c0303f..b39029a3

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

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

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

From fthevene at redhat.com  Mon Dec  1 10:59:50 2025
From: fthevene at redhat.com (Frederic Thevenet)
Date: Mon, 1 Dec 2025 11:59:50 +0100
Subject: Any reason why +PrintFlagsFinal requires unlocking experimental
 and diagnostic flags to print their default values?
In-Reply-To: <8cd2493e-6fdf-4399-934a-e74db442265f@oracle.com>
References: <849ebf93-c3fb-45c9-92c8-21a49b3e9946@redhat.com>
 <5ff2a0a5-9d61-466d-9ada-5ba911185815@oracle.com>
 <CAA-vtUw=7=NQvzV1bP6AsCKsJruKZ4KvQaSimczD8NY-44X_=w@mail.gmail.com>
 <75d56d4d-6d4d-48c1-8d9d-86d92249346d@oracle.com>
 <e03864c5-1dc9-492a-89b5-146706cd2c4c@redhat.com>
 <40274532-c875-4339-81cf-00b4c0776536@oracle.com>
 <75941750-84ae-4ce7-8748-3dcac82d4628@redhat.com>
 <8cd2493e-6fdf-4399-934a-e74db442265f@oracle.com>
Message-ID: <022ed95d-1aaf-492c-a874-a69544a2627a@redhat.com>



On 12/1/25 11:17, David Holmes wrote:
> On 1/12/2025 8:10 pm, Frederic Thevenet wrote:
>>
>>
>> On 12/1/25 10:59, David Holmes wrote:
>>> On 1/12/2025 7:41 pm, Frederic Thevenet wrote:
>>>> Thanks for filling the bug, David; I've assigned it to myself and 
>>>> will propose a PR for this shortly.
>>>>
>>>> Before I do, there's one point I feel might be worth clarifying in 
>>>> this discussion first.
>>>> In the current implementation, PrintFlagsFinal and PrintFlagsRanges 
>>>> are quite tightly intertwined, as one acts as an "upgrade" to the 
>>>> other (i.e. setting PrintFlagsRanges will override PrintFlagsFinal).
>>>> To me, it makes sense to change the behaviour for PrintFlagsRanges 
>>>> to also print all flags if we do it for PrintFlagsFinal, but I 
>>>> wanted to first ask if anyone sees a reason not to do this?
>>>
>>> I think that makes sense. Though you can then extend the same logic 
>>> to PrintFlagsInitial and even PrintFlagsWithComments, so the scope 
>>> expands. If you just want to restrict the change to PrintFlagsFinal 
>>> then I think the simplest thing is to just expand:
>>>
>>> void JVMFlag::printFlags(outputStream* out, bool withComments, bool 
>>> printRanges, bool skipDefaults) {
>>>
>>> to
>>>
>>> void JVMFlag::printFlags(outputStream* out, bool withComments, bool 
>>> printRanges, bool skipDefaults, bool printLocked) {
>>>
>>> and then have
>>>
>>> ? // All the flags that get adjusted by VM_Version_init and os::init_2
>>> ? // have been set so dump the flags now.
>>> ? if (PrintFlagsFinal || PrintFlagsRanges) {
>>> ??? JVMFlag::printFlags(tty, false, PrintFlagsRanges, false, 
>>> PrintFlagsFinal);
>>> ? }
>>
>> With regard to PrintFlagsInitial or PrintFlagsWithComments, it wasn't 
>> my primary goal to change these but I can certainly look into it 
>> while I'm at it if there is a consensus that it is in fact a good idea.
>> Anyone care to? comment?
>
> Well there is no obvious reason that these flags should differ in what 
> kind of flags they print - they only differ in what data gets printed 
> for each flag.
>
> Maybe it is simpler and more consistent to just delete the
>
> ?flagTable[i].is_unlocked()
>
> check.

Well yes indeed, but then aren't we right back at my initial proposal, 
which we were worried might be too far-reaching? (Or maybe it was just 
me who misunderstood your first answer?)

Right now I can list 6 call sites for the underlying JVMFlag::printFlags 
methods:
- For handling PrintFlagsFinal and? PrintFlagsRanges in init.cpp [0]
- For -XprintFlags in arguments.cpp [1]
- For PrintFlagsInitial? in arguments.cpp [2]
- For PrintFlagsWithComments in arguments.cpp [3]
- For printing flags in hs_err reports in vmError.cpp [4]
- For handling PrintVMFlagsDCmd in diagnosticCommand.cpp [5]

As per our current discussion, we probably want the first fourto exhibit 
the same behaviour, for the sake of coherency.
Then, as mentioned before, I believe calling? JVMFlag::printFlags with 
skipDefaults to true would not be affected by removing the unlocked 
check at all (so printing flags in hs_err would not change).
Finally, when it comes to the implementation of the PrintVMFlagsDCmd 
diagnostic command, it already offers two modes controlled by the 
consumer, one for only showing set flags and one for showing "all" 
flags: I feel that also showing locked flags in this case would not be a 
bad thing.

[0] 
https://github.com/openjdk/jdk/blob/5bd7db034aaf8aa6780945e02a7f9a35e16b036e/src/hotspot/share/runtime/init.cpp#L210 

[1] 
https://github.com/openjdk/jdk/blob/5bd7db034aaf8aa6780945e02a7f9a35e16b036e/src/hotspot/share/runtime/arguments.cpp#L2528C18-L2528C19 

[2] 
https://github.com/openjdk/jdk/blob/5bd7db034aaf8aa6780945e02a7f9a35e16b036e/src/hotspot/share/runtime/arguments.cpp#L3467 

[3] 
https://github.com/openjdk/jdk/blob/5bd7db034aaf8aa6780945e02a7f9a35e16b036e/src/hotspot/share/runtime/arguments.cpp#L3473 

[4] 
https://github.com/openjdk/jdk/blob/5bd7db034aaf8aa6780945e02a7f9a35e16b036e/src/hotspot/share/utilities/vmError.cpp#L1277 

[5] 
https://github.com/openjdk/jdk/blob/5bd7db034aaf8aa6780945e02a7f9a35e16b036e/src/hotspot/share/services/diagnosticCommand.cpp#L256

>
> David
>>>
>>> David
>>>> Cheers
>>>> Frederic
>>>>
>>>> On 12/1/25 10:21, David Holmes wrote:
>>>>> Okay I have filed:
>>>>>
>>>>> JDK-8372802: PrintFlagsFinal should also print locked flags
>>>>>
>>>>> but note there is no commitment for anyone to actually perform the 
>>>>> work.
>>>>>
>>>>> David
>>>>>
>>>>> On 28/11/2025 3:19 pm, Thomas St?fe wrote:
>>>>>> I am very much in favor of printing all flags, for the reasons 
>>>>>> Frederic has given. When one supports many different releases, it 
>>>>>> is a huge timesaver not to have to look up flags but see them 
>>>>>> right there in the customer logs. The ability of PrintFlagsFinal 
>>>>>> to give me all flags, including default values, after they are 
>>>>>> resolved to their final values, is also very useful during 
>>>>>> development.
>>>>>>
>>>>>> For simplicity, I would prefer just to change the behavior of 
>>>>>> PrintFlagsFinal to do that, but I could live with a new 
>>>>>> PrintAllFlagsFinal.
>>>>>>
>>>>>> Number of normal flags: 513, incl. diagnostic: 777, incl. 
>>>>>> experimental&diagnostic: 933. (Jdk 25). So, it's?a bit more. I am 
>>>>>> not bothered by this, since this list never fits onto a single 
>>>>>> screen anyway. People grep. But if others prefer an extra flag, 
>>>>>> sure, let's?have one.
>>>>>>
>>>>>>
>>>>>> On Thu, Nov 27, 2025 at 3:05?AM David Holmes 
>>>>>> <david.holmes at oracle.com <mailto:david.holmes at oracle.com>> wrote:
>>>>>>
>>>>>> ??? On 27/11/2025 12:53 am, Frederic Thevenet wrote:
>>>>>> ???? > Hi,
>>>>>> ???? >
>>>>>> ???? > Currently, using +PrintFlagsFinal prints out all JVM flags 
>>>>>> and their
>>>>>> ???? > values, even if they were not modified from their default, 
>>>>>> except
>>>>>> ??? for
>>>>>> ???? > 'locked' flags, i.e. Experimental and Diagnotic flags. In 
>>>>>> order
>>>>>> ??? to have
>>>>>> ???? > those printed out as well, one must first 'unlock' them (with
>>>>>> ???? > +UnlockExperimentalVMOptions, for instance).
>>>>>>
>>>>>> ??? I think this was simply a pragmatic decision to avoid 
>>>>>> overwhelming the
>>>>>> ??? user with information that should not be relevant.
>>>>>> ???? > Now, is their a strong reason for not always displaying 
>>>>>> the default
>>>>>> ???? > values for those in scenarios were there is no concerns 
>>>>>> that the
>>>>>> ??? output
>>>>>> ???? > might be too large (that is when calling upon
>>>>>> ??? 'JVMFlag::printFlags' with
>>>>>> ???? > 'skipDefaults' set to false, like PrintFlagsFinal does)?
>>>>>> ???? >
>>>>>> ???? > The reason for this question is that when chasing a bug in 
>>>>>> scenarios
>>>>>> ???? > where one can only rely on logs or output provided by 
>>>>>> tools that
>>>>>> ??? uses
>>>>>> ???? > +PrintFlagsFinal, getting the default values *in the 
>>>>>> conditions that
>>>>>> ???? > those logs where produced* can be tricky as it depends on 
>>>>>> the exact
>>>>>> ???? > version of the JDK that was running, and some values can be
>>>>>> ??? changed by
>>>>>> ???? > ergonomics.
>>>>>>
>>>>>> ??? Ouch. I think that would be a poor design choice for 
>>>>>> diagnostic, and
>>>>>> ??? especially experimental flags!
>>>>>>
>>>>>>
>>>>>> Not every experimental/diagnostic flag is a boolean that defaults 
>>>>>> to false and controls an opt-in feature. We have non-boolean 
>>>>>> experimental flags and boolean flags that default to true. It is 
>>>>>> not unthinkable that those are changed during VM start.
>>>>>>
>>>>>>
>>>>>> ???? > If you need to know the default for experimental flags -- 
>>>>>> which
>>>>>> ??? given
>>>>>> ???? > their nature can and do change often -- your choices are to
>>>>>> ??? either ask
>>>>>> ???? > for these logs to be generated again using
>>>>>> ??? +UnlockExperimentalVMOptions
>>>>>> ???? > (even if there is no intention of changing an experimental 
>>>>>> flag)
>>>>>> ??? or to
>>>>>> ???? > go on a time consuming deep dive into the code base for 
>>>>>> the exact
>>>>>> ???? > version of the JDK that was used. Neither is ideal.
>>>>>>
>>>>>> ??? True, but for experimental flags in particular, unless you 
>>>>>> are deep
>>>>>> ??? diving into the code how can you know whether a particular 
>>>>>> flag and its
>>>>>> ??? value are relevant to your debugging in the first place?
>>>>>>
>>>>>>
>>>>>> I think the point here is reducing analyst strain. It's?not that 
>>>>>> it is impossible to get the information otherwise, but that 
>>>>>> it's?convenient and stress-reducing to have one sure way to look 
>>>>>> up all resolved flag?values for a customer's JVM run. Folks who 
>>>>>> have to work with many cases involving different JVM versions 
>>>>>> would value this.
>>>>>>
>>>>>> BTW, we do print default values for non-experimental 
>>>>>> non-diagnostic flags, too. The same reasoning applies here: if 
>>>>>> its?not changed, you could look up the default value.
>>>>>>
>>>>>>
>>>>>> ??? That said, I don't see any harm in providing a way to print 
>>>>>> all flags,
>>>>>> ??? though whether by default or by a new -XX:PrintAllFlagsFinal 
>>>>>> flag, I'm
>>>>>> ??? not sure.
>>>>>>
>>>>>>
>>>>>> Wonderful, let's?do that then.
>>>>>>
>>>>>> Cheers, Thomas
>>>>>
>>>>
>>>
>>
>

-- 
Frederic Thevenet
Senior Software Engineer - OpenJDK
Red Hat France <https://www.redhat.com>
BAF5 C2D2 0BE0 1715 5EE1 0815 2065 AD47 B326 EB92



From fthevene at redhat.com  Mon Dec  1 11:12:40 2025
From: fthevene at redhat.com (Frederic Thevenet)
Date: Mon, 1 Dec 2025 12:12:40 +0100
Subject: Any reason why +PrintFlagsFinal requires unlocking experimental
 and diagnostic flags to print their default values?
In-Reply-To: <022ed95d-1aaf-492c-a874-a69544a2627a@redhat.com>
References: <849ebf93-c3fb-45c9-92c8-21a49b3e9946@redhat.com>
 <5ff2a0a5-9d61-466d-9ada-5ba911185815@oracle.com>
 <CAA-vtUw=7=NQvzV1bP6AsCKsJruKZ4KvQaSimczD8NY-44X_=w@mail.gmail.com>
 <75d56d4d-6d4d-48c1-8d9d-86d92249346d@oracle.com>
 <e03864c5-1dc9-492a-89b5-146706cd2c4c@redhat.com>
 <40274532-c875-4339-81cf-00b4c0776536@oracle.com>
 <75941750-84ae-4ce7-8748-3dcac82d4628@redhat.com>
 <8cd2493e-6fdf-4399-934a-e74db442265f@oracle.com>
 <022ed95d-1aaf-492c-a874-a69544a2627a@redhat.com>
Message-ID: <93ed9b47-f149-4d9f-8474-0956e5d39a1c@redhat.com>

PS: All that to say that, yes I think simply removing the 
`flagTable[i].is_unlocked()` check is quite possibly the way to go (I 
hit send too soon, sorry).

On 12/1/25 11:59, Frederic Thevenet wrote:
>
>
> On 12/1/25 11:17, David Holmes wrote:
>> On 1/12/2025 8:10 pm, Frederic Thevenet wrote:
>>>
>>>
>>> On 12/1/25 10:59, David Holmes wrote:
>>>> On 1/12/2025 7:41 pm, Frederic Thevenet wrote:
>>>>> Thanks for filling the bug, David; I've assigned it to myself and 
>>>>> will propose a PR for this shortly.
>>>>>
>>>>> Before I do, there's one point I feel might be worth clarifying in 
>>>>> this discussion first.
>>>>> In the current implementation, PrintFlagsFinal and 
>>>>> PrintFlagsRanges are quite tightly intertwined, as one acts as an 
>>>>> "upgrade" to the other (i.e. setting PrintFlagsRanges will 
>>>>> override PrintFlagsFinal).
>>>>> To me, it makes sense to change the behaviour for PrintFlagsRanges 
>>>>> to also print all flags if we do it for PrintFlagsFinal, but I 
>>>>> wanted to first ask if anyone sees a reason not to do this?
>>>>
>>>> I think that makes sense. Though you can then extend the same logic 
>>>> to PrintFlagsInitial and even PrintFlagsWithComments, so the scope 
>>>> expands. If you just want to restrict the change to PrintFlagsFinal 
>>>> then I think the simplest thing is to just expand:
>>>>
>>>> void JVMFlag::printFlags(outputStream* out, bool withComments, bool 
>>>> printRanges, bool skipDefaults) {
>>>>
>>>> to
>>>>
>>>> void JVMFlag::printFlags(outputStream* out, bool withComments, bool 
>>>> printRanges, bool skipDefaults, bool printLocked) {
>>>>
>>>> and then have
>>>>
>>>> ? // All the flags that get adjusted by VM_Version_init and os::init_2
>>>> ? // have been set so dump the flags now.
>>>> ? if (PrintFlagsFinal || PrintFlagsRanges) {
>>>> ??? JVMFlag::printFlags(tty, false, PrintFlagsRanges, false, 
>>>> PrintFlagsFinal);
>>>> ? }
>>>
>>> With regard to PrintFlagsInitial or PrintFlagsWithComments, it 
>>> wasn't my primary goal to change these but I can certainly look into 
>>> it while I'm at it if there is a consensus that it is in fact a good 
>>> idea.
>>> Anyone care to? comment?
>>
>> Well there is no obvious reason that these flags should differ in 
>> what kind of flags they print - they only differ in what data gets 
>> printed for each flag.
>>
>> Maybe it is simpler and more consistent to just delete the
>>
>> ?flagTable[i].is_unlocked()
>>
>> check.
>
> Well yes indeed, but then aren't we right back at my initial proposal, 
> which we were worried might be too far-reaching? (Or maybe it was just 
> me who misunderstood your first answer?)
>
> Right now I can list 6 call sites for the underlying 
> JVMFlag::printFlags methods:
> - For handling PrintFlagsFinal and? PrintFlagsRanges in init.cpp [0]
> - For -XprintFlags in arguments.cpp [1]
> - For PrintFlagsInitial? in arguments.cpp [2]
> - For PrintFlagsWithComments in arguments.cpp [3]
> - For printing flags in hs_err reports in vmError.cpp [4]
> - For handling PrintVMFlagsDCmd in diagnosticCommand.cpp [5]
>
> As per our current discussion, we probably want the first fourto 
> exhibit the same behaviour, for the sake of coherency.
> Then, as mentioned before, I believe calling? JVMFlag::printFlags with 
> skipDefaults to true would not be affected by removing the unlocked 
> check at all (so printing flags in hs_err would not change).
> Finally, when it comes to the implementation of the PrintVMFlagsDCmd 
> diagnostic command, it already offers two modes controlled by the 
> consumer, one for only showing set flags and one for showing "all" 
> flags: I feel that also showing locked flags in this case would not be 
> a bad thing.
>
> [0] 
> https://github.com/openjdk/jdk/blob/5bd7db034aaf8aa6780945e02a7f9a35e16b036e/src/hotspot/share/runtime/init.cpp#L210 
>
> [1] 
> https://github.com/openjdk/jdk/blob/5bd7db034aaf8aa6780945e02a7f9a35e16b036e/src/hotspot/share/runtime/arguments.cpp#L2528C18-L2528C19 
>
> [2] 
> https://github.com/openjdk/jdk/blob/5bd7db034aaf8aa6780945e02a7f9a35e16b036e/src/hotspot/share/runtime/arguments.cpp#L3467 
>
> [3] 
> https://github.com/openjdk/jdk/blob/5bd7db034aaf8aa6780945e02a7f9a35e16b036e/src/hotspot/share/runtime/arguments.cpp#L3473 
>
> [4] 
> https://github.com/openjdk/jdk/blob/5bd7db034aaf8aa6780945e02a7f9a35e16b036e/src/hotspot/share/utilities/vmError.cpp#L1277 
>
> [5] 
> https://github.com/openjdk/jdk/blob/5bd7db034aaf8aa6780945e02a7f9a35e16b036e/src/hotspot/share/services/diagnosticCommand.cpp#L256
>
>>
>> David
>>>>
>>>> David
>>>>> Cheers
>>>>> Frederic
>>>>>
>>>>> On 12/1/25 10:21, David Holmes wrote:
>>>>>> Okay I have filed:
>>>>>>
>>>>>> JDK-8372802: PrintFlagsFinal should also print locked flags
>>>>>>
>>>>>> but note there is no commitment for anyone to actually perform 
>>>>>> the work.
>>>>>>
>>>>>> David
>>>>>>
>>>>>> On 28/11/2025 3:19 pm, Thomas St?fe wrote:
>>>>>>> I am very much in favor of printing all flags, for the reasons 
>>>>>>> Frederic has given. When one supports many different releases, 
>>>>>>> it is a huge timesaver not to have to look up flags but see them 
>>>>>>> right there in the customer logs. The ability of PrintFlagsFinal 
>>>>>>> to give me all flags, including default values, after they are 
>>>>>>> resolved to their final values, is also very useful during 
>>>>>>> development.
>>>>>>>
>>>>>>> For simplicity, I would prefer just to change the behavior of 
>>>>>>> PrintFlagsFinal to do that, but I could live with a new 
>>>>>>> PrintAllFlagsFinal.
>>>>>>>
>>>>>>> Number of normal flags: 513, incl. diagnostic: 777, incl. 
>>>>>>> experimental&diagnostic: 933. (Jdk 25). So, it's?a bit more. I 
>>>>>>> am not bothered by this, since this list never fits onto a 
>>>>>>> single screen anyway. People grep. But if others prefer an extra 
>>>>>>> flag, sure, let's?have one.
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Nov 27, 2025 at 3:05?AM David Holmes 
>>>>>>> <david.holmes at oracle.com <mailto:david.holmes at oracle.com>> wrote:
>>>>>>>
>>>>>>> ??? On 27/11/2025 12:53 am, Frederic Thevenet wrote:
>>>>>>> ???? > Hi,
>>>>>>> ???? >
>>>>>>> ???? > Currently, using +PrintFlagsFinal prints out all JVM 
>>>>>>> flags and their
>>>>>>> ???? > values, even if they were not modified from their 
>>>>>>> default, except
>>>>>>> ??? for
>>>>>>> ???? > 'locked' flags, i.e. Experimental and Diagnotic flags. In 
>>>>>>> order
>>>>>>> ??? to have
>>>>>>> ???? > those printed out as well, one must first 'unlock' them 
>>>>>>> (with
>>>>>>> ???? > +UnlockExperimentalVMOptions, for instance).
>>>>>>>
>>>>>>> ??? I think this was simply a pragmatic decision to avoid 
>>>>>>> overwhelming the
>>>>>>> ??? user with information that should not be relevant.
>>>>>>> ???? > Now, is their a strong reason for not always displaying 
>>>>>>> the default
>>>>>>> ???? > values for those in scenarios were there is no concerns 
>>>>>>> that the
>>>>>>> ??? output
>>>>>>> ???? > might be too large (that is when calling upon
>>>>>>> ??? 'JVMFlag::printFlags' with
>>>>>>> ???? > 'skipDefaults' set to false, like PrintFlagsFinal does)?
>>>>>>> ???? >
>>>>>>> ???? > The reason for this question is that when chasing a bug 
>>>>>>> in scenarios
>>>>>>> ???? > where one can only rely on logs or output provided by 
>>>>>>> tools that
>>>>>>> ??? uses
>>>>>>> ???? > +PrintFlagsFinal, getting the default values *in the 
>>>>>>> conditions that
>>>>>>> ???? > those logs where produced* can be tricky as it depends on 
>>>>>>> the exact
>>>>>>> ???? > version of the JDK that was running, and some values can be
>>>>>>> ??? changed by
>>>>>>> ???? > ergonomics.
>>>>>>>
>>>>>>> ??? Ouch. I think that would be a poor design choice for 
>>>>>>> diagnostic, and
>>>>>>> ??? especially experimental flags!
>>>>>>>
>>>>>>>
>>>>>>> Not every experimental/diagnostic flag is a boolean that 
>>>>>>> defaults to false and controls an opt-in feature. We have 
>>>>>>> non-boolean experimental flags and boolean flags that default to 
>>>>>>> true. It is not unthinkable that those are changed during VM start.
>>>>>>>
>>>>>>>
>>>>>>> ???? > If you need to know the default for experimental flags -- 
>>>>>>> which
>>>>>>> ??? given
>>>>>>> ???? > their nature can and do change often -- your choices are to
>>>>>>> ??? either ask
>>>>>>> ???? > for these logs to be generated again using
>>>>>>> ??? +UnlockExperimentalVMOptions
>>>>>>> ???? > (even if there is no intention of changing an 
>>>>>>> experimental flag)
>>>>>>> ??? or to
>>>>>>> ???? > go on a time consuming deep dive into the code base for 
>>>>>>> the exact
>>>>>>> ???? > version of the JDK that was used. Neither is ideal.
>>>>>>>
>>>>>>> ??? True, but for experimental flags in particular, unless you 
>>>>>>> are deep
>>>>>>> ??? diving into the code how can you know whether a particular 
>>>>>>> flag and its
>>>>>>> ??? value are relevant to your debugging in the first place?
>>>>>>>
>>>>>>>
>>>>>>> I think the point here is reducing analyst strain. It's?not that 
>>>>>>> it is impossible to get the information otherwise, but that 
>>>>>>> it's?convenient and stress-reducing to have one sure way to look 
>>>>>>> up all resolved flag?values for a customer's JVM run. Folks who 
>>>>>>> have to work with many cases involving different JVM versions 
>>>>>>> would value this.
>>>>>>>
>>>>>>> BTW, we do print default values for non-experimental 
>>>>>>> non-diagnostic flags, too. The same reasoning applies here: if 
>>>>>>> its?not changed, you could look up the default value.
>>>>>>>
>>>>>>>
>>>>>>> ??? That said, I don't see any harm in providing a way to print 
>>>>>>> all flags,
>>>>>>> ??? though whether by default or by a new -XX:PrintAllFlagsFinal 
>>>>>>> flag, I'm
>>>>>>> ??? not sure.
>>>>>>>
>>>>>>>
>>>>>>> Wonderful, let's?do that then.
>>>>>>>
>>>>>>> Cheers, Thomas
>>>>>>
>>>>>
>>>>
>>>
>>
>

-- 
Frederic Thevenet
Senior Software Engineer - OpenJDK
Red Hat France <https://www.redhat.com>
BAF5 C2D2 0BE0 1715 5EE1 0815 2065 AD47 B326 EB92



From cnorrbin at openjdk.org  Mon Dec  1 12:45:06 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Mon, 1 Dec 2025 12:45:06 GMT
Subject: RFR: 8372615: Many container tests fail when running rootless on
 cgroup v1 [v2]
In-Reply-To: <vMiWENH7dMmRw5miQHPYNnETLlwMgklDZyGxk_JCPu4=.a98f9e35-3bb4-4aaf-b89b-a2547c4e6f29@github.com>
References: <vMiWENH7dMmRw5miQHPYNnETLlwMgklDZyGxk_JCPu4=.a98f9e35-3bb4-4aaf-b89b-a2547c4e6f29@github.com>
Message-ID: <pEceZpCbgMCqwPQoKiGcLgFlv-UpLg5Rv4PcHclFRKQ=.822a2343-fe24-4384-9214-f88c80a103a0@github.com>

> Hi everyone,
> 
> Many container tests verify that various resource limits work as expected. However, when running containers in rootless mode on both Docker and Podman with cgroup v1, resource limits are not supported. This causes tests to fail with error messages like: `Resource limits are not supported and ignored on cgroups V1 rootless systems`.
> 
> To address this, we should skip these tests when running on configurations that don't support resource limits, similar to how we already handle other unsupported configurations (e.g., missing container engine or incompatibility with a specific cgroup version or container runtime).
> 
> To check for this, we now need to use `Metrics.systemMetrics().getProvider()` from `jdk.internal.platform.Metrics` to detect cgroup v1. I've added this functionality to `DockerTestUtils`, which is already used by all container tests. As a result, all container tests now need to include the `java.base/jdk.internal.platform` module, even if they don't directly test resource limits.
> 
> Testing:
> * Oracle tiers 1-5
> * Local testing:
>   - `hotspot/jtreg/containers/` 
>   - `jdk/jdk/internal/platform/docker/`
> on cgroup v1/v2 with Podman and Docker in both rootful and rootless configurations

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

  reworked check docker/resourcelimit functions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28557/files
  - new: https://git.openjdk.org/jdk/pull/28557/files/e9297412..986b3923

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

  Stats: 112 lines in 27 files changed: 0 ins; 69 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/28557.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28557/head:pull/28557

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

From cnorrbin at openjdk.org  Mon Dec  1 12:52:48 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Mon, 1 Dec 2025 12:52:48 GMT
Subject: RFR: 8372615: Many container tests fail when running rootless on
 cgroup v1 [v2]
In-Reply-To: <5wBcMRj8jDv-vnUNYD8CdotWx9x1UjUhboVdPE-zox4=.eb8d1086-de7b-4a0e-b61e-1cca3c768571@github.com>
References: <vMiWENH7dMmRw5miQHPYNnETLlwMgklDZyGxk_JCPu4=.a98f9e35-3bb4-4aaf-b89b-a2547c4e6f29@github.com>
 <5wBcMRj8jDv-vnUNYD8CdotWx9x1UjUhboVdPE-zox4=.eb8d1086-de7b-4a0e-b61e-1cca3c768571@github.com>
Message-ID: <4wL0GNT4iNlJ95Dt43mwpRYI82DIXa6mFfLGvaVpH0w=.a8643ade-7687-41e8-b378-d3faae4084b2@github.com>

On Mon, 1 Dec 2025 04:18:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reworked check docker/resourcelimit functions
>
> test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java line 142:
> 
>> 140:      *
>> 141:      * @return true if resource limits are supported in the current configuration
>> 142:      * @throws Exception
> 
> I don't like this pattern of making a function seem like it is a query by declaring it returns a boolean when in reality it either returns true or else throws. These should just be void functions with names like `checkCanUseResourceLimits`, and we can elide the fake `if` conditions with unreachable `return` statements in the callers.

I agree that it could be made clearer.

I reworked both `canUseResourceLimits()` and `canTestDocker()` into `void` functions that only throw. So 

```c++
if (!DockerTestUtils.canTestDocker() || !DockerTestUtils.canUseResourceLimits()) {
    return;
}


Instead becomes:

```c++
DockerTestUtils.checkCanTestDocker();
DockerTestUtils.checkCanUseResourceLimits();

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28557#discussion_r2576955639

From shade at openjdk.org  Mon Dec  1 13:04:08 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 1 Dec 2025 13:04:08 GMT
Subject: RFR: 8357258: x86: Improve receiver type profiling reliability
 [v6]
In-Reply-To: <X9RJoDWqk67MlK7P4ACCbzROxLkfEqvU0zDid3zymnc=.7c0086a3-f514-4b0d-8bc0-592bf4a05bba@github.com>
References: <X9RJoDWqk67MlK7P4ACCbzROxLkfEqvU0zDid3zymnc=.7c0086a3-f514-4b0d-8bc0-592bf4a05bba@github.com>
Message-ID: <2ifEaoGuZU4duyckWchgOnnqfH6AgAcrqsiqBZH1Nx4=.1df7af8d-41ac-43a1-90ab-964eb80f155b@github.com>

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

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

 - 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

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25305/files
  - new: https://git.openjdk.org/jdk/pull/25305/files/c441209a..f3e0fa4d

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

  Stats: 157 lines in 1 file changed: 85 ins; 52 del; 20 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 shade at openjdk.org  Mon Dec  1 13:04:10 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 1 Dec 2025 13:04:10 GMT
Subject: RFR: 8357258: x86: Improve receiver type profiling reliability
 [v5]
In-Reply-To: <ABBZBklt6TsANDYgiL2rSq7tZk7OahMhRsrh0CIrNnI=.72cf3c77-1884-426e-90f5-0297a2fdc986@github.com>
References: <X9RJoDWqk67MlK7P4ACCbzROxLkfEqvU0zDid3zymnc=.7c0086a3-f514-4b0d-8bc0-592bf4a05bba@github.com>
 <ABBZBklt6TsANDYgiL2rSq7tZk7OahMhRsrh0CIrNnI=.72cf3c77-1884-426e-90f5-0297a2fdc986@github.com>
Message-ID: <w0rubSDceEtWRu9WX64Orb_2tH4vK8hjYkh7fI0psu8=.944c51bb-5ec9-4d60-b5e4-3ee8709ec581@github.com>

On Wed, 26 Nov 2025 15:55:38 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the bug for discussion what issues current machinery has. 
>> 
>> This PR executes the plan outlined in the bug:
>>  1. Common the receiver type profiling code in interpreter and C1
>>  2. Rewrite receiver type profiling code to only do atomic receiver slot installations
>>  3. Trim `C1OptimizeVirtualCallProfiling` to only claim slots when receiver is installed 
>> 
>> This PR does _not_ do atomic counter updates themselves, as it may have much wider performance implications, including regressions. This PR should be at least performance neutral.
>> 
>> Additional testing:
>>   - [x] Linux x86_64 server fastdebug, `compiler/`
>>   - [x] Linux x86_64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Merge branch 'master' into JDK-8357258-x86-c1-optimize-virt-calls
>  - Tighten up some more
>  - Offset is always rscratch1, no need to save it
>  - Grossly simplify register shuffling
>  - More asserts
>  - More comment touchups
>  - Inline code comments
>  - Mention the updater in ReceiverTypeData
>  - type_profile -> profile_receiver_type
>  - Stylistic: remove redundant assert
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/c028369d...c441209a

Oh, all right! This made me realize we actually have a secondary "fast" case: receiver is not found, but profile is full. This is pretty frequent with `TypeProfileWidth=2`. In that case, we are doing way too much stuff, anticipating receiver slot installation that would never actually come. Specializing for that case costs significantly fewer loads, and gets the code much more pipelined; I suspect that because tight loops that _do not_ have CAS-es in them are uop-cached more readily.

We now lose "only" 0.5ns in this test:


Benchmark                                                (randomized)  Mode  Cnt    Score   Error      Units

# Baseline
InterfaceCalls.test2ndInt5Types                                 false  avgt   12   16.945 ?  0.079      ns/op
InterfaceCalls.test2ndInt5Types:L1-dcache-load-misses           false  avgt    3    0.076 ?  2.187       #/op
InterfaceCalls.test2ndInt5Types:L1-dcache-loads                 false  avgt    3   88.738 ?  0.416       #/op
InterfaceCalls.test2ndInt5Types:branch-misses                   false  avgt    3    0.007 ?  0.003       #/op
InterfaceCalls.test2ndInt5Types:branches                        false  avgt    3   49.122 ?  0.353       #/op
InterfaceCalls.test2ndInt5Types:cycles                          false  avgt    3   57.147 ?  1.698       #/op
InterfaceCalls.test2ndInt5Types:instructions                    false  avgt    3  247.443 ?  1.531       #/op

# Old PR version
InterfaceCalls.test2ndInt5Types                                 false  avgt   12   22.513 ?  0.208      ns/op
InterfaceCalls.test2ndInt5Types:L1-dcache-load-misses           false  avgt    3    0.012 ?  0.072       #/op
InterfaceCalls.test2ndInt5Types:L1-dcache-loads                 false  avgt    3  108.446 ? 13.975       #/op  ; +20 loads
InterfaceCalls.test2ndInt5Types:branch-misses                   false  avgt    3    0.407 ?  0.010       #/op
InterfaceCalls.test2ndInt5Types:branches                        false  avgt    3   54.102 ?  0.403       #/op  ; +5 branches
InterfaceCalls.test2ndInt5Types:cycles                          false  avgt    3   75.938 ?  5.043       #/op  ; +19 cycles
InterfaceCalls.test2ndInt5Types:instructions                    false  avgt    3  280.194 ?  5.758       #/op  ; +32 instructions

# New PR version
InterfaceCalls.test2ndInt5Types                                 false  avgt   12   17.441 ?  0.287      ns/op
InterfaceCalls.test2ndInt5Types:L1-dcache-load-misses           false  avgt    3    0.009 ?  0.072       #/op
InterfaceCalls.test2ndInt5Types:L1-dcache-loads                 false  avgt    3   88.803 ?  1.401       #/op
InterfaceCalls.test2ndInt5Types:branch-misses                   false  avgt    3    0.009 ?  0.062       #/op
InterfaceCalls.test2ndInt5Types:branches                        false  avgt    3   52.945 ?  0.752       #/op  ; +4 branches
InterfaceCalls.test2ndInt5Types:cycles                          false  avgt    3   58.866 ? 15.379       #/op  ; +2 cycles
InterfaceCalls.test2ndInt5Types:instructions                    false  avgt    3  272.838 ?  1.665       #/op  ; +28 instructions


The code is in new commits, passes `hotspot:tier1`, running more tests now.

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

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

From aboldtch at openjdk.org  Mon Dec  1 13:20:49 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 1 Dec 2025 13:20:49 GMT
Subject: RFR: 8366671: Refactor Thread::SpinAcquire and Thread::SpinRelease
 [v9]
In-Reply-To: <svlyDLeLPwYpnzHM6cP8UPc7pkMninSM-3xd2FUesQY=.027d3aa9-1e6d-433a-ac74-4e1d682c751f@github.com>
References: <NtY8E8fBeSokCAQYP3OQEwfnppSugtTJ8uAtQtD0zvg=.88f2988d-47fd-4b8a-af89-488ed6b37870@github.com>
 <3bBZzigernOcTkARE9am0ZmHR9NWsmp3xa0ksSLYiE8=.981d0f10-5b41-40c8-a35c-f953b0d1df08@github.com>
 <8aNv20VZljWCq6M_lZKe6dhlahN0nHoH91JDHEeIo8Y=.3d917870-0e49-4e40-95e2-df9dcaa3fe4d@github.com>
 <svlyDLeLPwYpnzHM6cP8UPc7pkMninSM-3xd2FUesQY=.027d3aa9-1e6d-433a-ac74-4e1d682c751f@github.com>
Message-ID: <qy9C3kZOZc7-RzO3SUUV8SMdWywQC92m3jSr-n_e15U=.2e8b1a41-7945-46e7-bcb5-807f62f0e3e0@github.com>

On Mon, 1 Dec 2025 10:16:29 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

> Adding a `NoSafepointVerifier` before `spin_acquire()` breaks creation of the main thread. The problem is in `ParkEvent::Allocate(this)`. And there is a comment in park.cpp: "Caveat: Allocate() and Release() may be called from threads other than the thread associated with the Event!". So it breaks the assert in `Thread::current()`. Any other way how to ensure no polling for safepoint?

I see. Yeah, do not think we have a construction that does exactly this right now. But we can easily extend the NSV to only call `Thread::current()` if it is not active. Something like:


diff --git a/src/hotspot/share/runtime/safepointVerifiers.cpp b/src/hotspot/share/runtime/safepointVerifiers.cpp
index 6eb61efe0ca..0c6f2e9add3 100644
--- a/src/hotspot/share/runtime/safepointVerifiers.cpp
+++ b/src/hotspot/share/runtime/safepointVerifiers.cpp
@@ -30,7 +30,9 @@
 
 #ifdef ASSERT
 
-NoSafepointVerifier::NoSafepointVerifier(bool active) : _thread(Thread::current()), _active(active) {
+NoSafepointVerifier::NoSafepointVerifier(bool active)
+  : _thread(active ? Thread::current() : nullptr),
+    _active(active) {
   if (!_active) {
     return;
   }
diff --git a/src/hotspot/share/utilities/spinCriticalSection.hpp b/src/hotspot/share/utilities/spinCriticalSection.hpp
index 487edc01b06..c4ccfd7d295 100644
--- a/src/hotspot/share/utilities/spinCriticalSection.hpp
+++ b/src/hotspot/share/utilities/spinCriticalSection.hpp
@@ -26,6 +26,9 @@
 #define SHARE_UTILITIES_SPINCRITICALSECTION_HPP
 
 #include "runtime/javaThread.hpp"
+#include "runtime/safepointVerifiers.hpp"
+#include "runtime/thread.hpp"
+#include "utilities/macros.hpp"
 
 // Ad-hoc mutual exclusion primitive: spin critical section,
 // which employs a spin lock.
@@ -40,12 +43,15 @@ class SpinCriticalSection {
   // We use int type as 32-bit atomic operation is the most performant
   // compared to  smaller/larger types.
   volatile int* const _lock;
+  DEBUG_ONLY(NoSafepointVerifier _nsv;)
 
   static void spin_acquire(volatile int* Lock);
   static void spin_release(volatile int* Lock);
 public:
   NONCOPYABLE(SpinCriticalSection);
-  SpinCriticalSection(volatile int* lock) : _lock(lock) {
+  SpinCriticalSection(volatile int* lock)
+    : _lock(lock)
+      DEBUG_ONLY(COMMA _nsv(Thread::current_or_null_safe() != nullptr)) {
     spin_acquire(_lock);
   }
   ~SpinCriticalSection() {

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

PR Comment: https://git.openjdk.org/jdk/pull/28264#issuecomment-3596509884

From coleenp at openjdk.org  Mon Dec  1 15:02:50 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 1 Dec 2025 15:02:50 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v5]
In-Reply-To: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
Message-ID: <r4etVDZnERk-bUlx-6uMtxP03xvMa0a51MnBlA7eIz0=.4e16178f-517a-400e-a7bf-0a890664aa2c@github.com>

> ArrayKlass doesn't set AccessFlags so don't look for them there.  See CR for details.
> Fixed SA and jvmci.  @iwanowww Can you check that I changed C2 correctly (we talked about this in August).
> Tested with tier1-4.  5-7 in progress.

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

  Added a comment for checking interface guard after array guard.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28371/files
  - new: https://git.openjdk.org/jdk/pull/28371/files/06d6a186..7f234078

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

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

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

From mli at openjdk.org  Mon Dec  1 15:13:13 2025
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 1 Dec 2025 15:13:13 GMT
Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization [v7]
In-Reply-To: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com>
References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com>
Message-ID: <4-PqNRUxM-80k4mQdYNzc0HrirtkTCjfVAzgRewW08M=.d2fe4512-16cd-4abf-8a7f-e91341c37110@github.com>

> Hi,
> 
> This pr add CMoveF/D on riscv, which enable vectorization of statement like: `op_1 bop op_2 ? res_f_d_1 : res_f_d_2 in a loop`.
> 
> This pr is also a preparation for further vectorization in https://github.com/openjdk/jdk/pull/28231.
> 
> Previously it's https://github.com/openjdk/jdk/pull/25341, but at that time, C2 SLP has some issue with unsigned comparison, which is now fixed, so it's good to continue the work.
> 
> # Test
> ## Jtreg
> 
> in progress...
> 
> ## Performance
> 
> Column names meanings:
> * p: with patch
> * p+v: with patch, `-XX:+UseVectorCmov -XX:+UseCMoveUnconditionally` turned on
> * m: without patch
> * m+v: without patch, `-XX:+UseVectorCmov -XX:+UseCMoveUnconditionally` turned on
> 
> #### Average improvement
> 
> NOTE: With only this PR, it brings performance benefit in case of `CMoveF+CmpF`, `CMoveD+ComD`, `CMoveF+CmpI`, `CMoveD+CmpL`. The data below is based on fullly implmenting the vectorization of `CMoveI/L/F/D+CmpI/L/F/D`, which will be achieved by https://github.com/openjdk/jdk/pull/28231.
> 
> For details, check the performance data in https://github.com/openjdk/jdk/pull/25341 on riscv.
> <google-sheets-html-origin style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
> Opt (m/p) | Opt (m+v/p+v) | Opt (p/p+v) | Opt (m/p+v)
> -- | -- | -- | --
> 1.022782609 | 2.198717391 | 2.162673913 | 2.199
> 
> </google-sheets-html-origin>

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

 - remove log_warning
 - add test cases: BoolTest::ge/gt in enc_cmove_fp_cmp_fp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28309/files
  - new: https://git.openjdk.org/jdk/pull/28309/files/46b32186..077dc35c

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

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

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

From mli at openjdk.org  Mon Dec  1 15:13:15 2025
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 1 Dec 2025 15:13:15 GMT
Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization [v6]
In-Reply-To: <NBWP0MpNLdz0fSedC4LUB6XhNehDPZXoSW1EXORwJ5s=.c7b9ac6e-fb76-499f-bad1-574560bb436f@github.com>
References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com>
 <7kh5C9nj7bf6432cG35kDDvV6zhnKEspe8AcYetJ1do=.e1d9ebd3-d80d-4621-8c1e-c77dc721d0df@github.com>
 <UP9CeREEzOP9VnGnDOB26dIj_YiKAd5fpMG86s5SULI=.9f48cf4f-4c72-425e-a3fa-0e1e762632f4@github.com>
 <NBWP0MpNLdz0fSedC4LUB6XhNehDPZXoSW1EXORwJ5s=.c7b9ac6e-fb76-499f-bad1-574560bb436f@github.com>
Message-ID: <XfrYO7JxaZa2zikDz6B3yC8R2wYBFLMZvk44vhYklLg=.b500dba1-1f05-45ce-b419-2d29e779ef0d@github.com>

On Tue, 25 Nov 2025 09:39:26 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp line 2141:
>> 
>>> 2139:     case BoolTest::gt:
>>> 2140:       cmov_fp_cmp_fp_gt(op1, op2, dst, src, cmp_single, cmov_single);
>>> 2141:       log_warning(jit)("Float/Double BoolTest::gt path is not tested well, please report the test case!");
>> 
>> My local tests show this does happen. Try this:
>> `$ make test TEST="./test/jdk/javax/sound/midi/Gervill/SoftFilter/TestProcessAudio.java" TEST_VM_OPTS="-XX:-TieredCompilation"`
>> 
>> I think this could be a good reference if you want to add some extra tests for the two cases here.
>
> Thanks, I'll check it later.

Sorry for the delayed response.
I've added the test case to cover all the code paths.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28309#discussion_r2577477492

From shade at openjdk.org  Mon Dec  1 15:23:25 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 1 Dec 2025 15:23:25 GMT
Subject: RFR: 8372652: Re-enable LocalRandom clinit after monitor pinning
 improvements
In-Reply-To: <IBk5-edc3PLSPqI5HZ4pDOthGiFBlj2MDMKs_A0kLEk=.3b7097c9-afe9-4441-a0b1-bdd20eb1468f@github.com>
References: <IgEuelEzPt9Atv8KQR1Sa80QaKGllGNR-nWRF-sdm3Y=.72ccb838-8723-4fb8-9547-ed20e51b00f1@github.com>
 <IBk5-edc3PLSPqI5HZ4pDOthGiFBlj2MDMKs_A0kLEk=.3b7097c9-afe9-4441-a0b1-bdd20eb1468f@github.com>
Message-ID: <YiOD-Uhl8zzAYb-uLYLs9itATGW4GQjH7iPKMRtdARE=.3cebae80-b55e-4a60-b92e-593e579d4931@github.com>

On Fri, 28 Nov 2025 20:27:52 GMT, Leonid Mesnik <lmesnik at openjdk.org> 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?

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

PR Comment: https://git.openjdk.org/jdk/pull/28547#issuecomment-3597142545

From sgehwolf at openjdk.org  Mon Dec  1 15:33:10 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 1 Dec 2025 15:33:10 GMT
Subject: RFR: 8372615: Many container tests fail when running rootless on
 cgroup v1 [v2]
In-Reply-To: <pEceZpCbgMCqwPQoKiGcLgFlv-UpLg5Rv4PcHclFRKQ=.822a2343-fe24-4384-9214-f88c80a103a0@github.com>
References: <vMiWENH7dMmRw5miQHPYNnETLlwMgklDZyGxk_JCPu4=.a98f9e35-3bb4-4aaf-b89b-a2547c4e6f29@github.com>
 <pEceZpCbgMCqwPQoKiGcLgFlv-UpLg5Rv4PcHclFRKQ=.822a2343-fe24-4384-9214-f88c80a103a0@github.com>
Message-ID: <aVaxH7Z4k27ox0WJk6YzZGzGWmv1PDjwRMAdMkAe7_Y=.a4bd212d-d40f-4155-9d15-4587335a417f@github.com>

On Mon, 1 Dec 2025 12:45:06 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> Many container tests verify that various resource limits work as expected. However, when running containers in rootless mode on both Docker and Podman with cgroup v1, resource limits are not supported. This causes tests to fail with error messages like: `Resource limits are not supported and ignored on cgroups V1 rootless systems`.
>> 
>> To address this, we should skip these tests when running on configurations that don't support resource limits, similar to how we already handle other unsupported configurations (e.g., missing container engine or incompatibility with a specific cgroup version or container runtime).
>> 
>> To check for this, we now need to use `Metrics.systemMetrics().getProvider()` from `jdk.internal.platform.Metrics` to detect cgroup v1. I've added this functionality to `DockerTestUtils`, which is already used by all container tests. As a result, all container tests now need to include the `java.base/jdk.internal.platform` module, even if they don't directly test resource limits.
>> 
>> Testing:
>> * Oracle tiers 1-5
>> * Local testing:
>>   - `hotspot/jtreg/containers/` 
>>   - `jdk/jdk/internal/platform/docker/`
>> on cgroup v1/v2 with Podman and Docker in both rootful and rootless configurations
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reworked check docker/resourcelimit functions

This adds a dependency on `Metrics` for all the Hotspot container tests. I guess this is considered OK?

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

PR Review: https://git.openjdk.org/jdk/pull/28557#pullrequestreview-3525625824

From liach at openjdk.org  Mon Dec  1 15:40:40 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 1 Dec 2025 15:40:40 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting [v3]
In-Reply-To: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
Message-ID: <aoJzukx9MSHs9r0SBGTWoQYb51HlSW9ABP3ZiNqVqpo=.d6c930cc-58cb-4235-bfa5-f2b81a75d88b@github.com>

> 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:

  Doc tweaks

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28540/files
  - new: https://git.openjdk.org/jdk/pull/28540/files/712dbf1c..7a1cfa4a

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

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

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

From cnorrbin at openjdk.org  Mon Dec  1 15:44:31 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Mon, 1 Dec 2025 15:44:31 GMT
Subject: RFR: 8372615: Many container tests fail when running rootless on
 cgroup v1 [v2]
In-Reply-To: <aVaxH7Z4k27ox0WJk6YzZGzGWmv1PDjwRMAdMkAe7_Y=.a4bd212d-d40f-4155-9d15-4587335a417f@github.com>
References: <vMiWENH7dMmRw5miQHPYNnETLlwMgklDZyGxk_JCPu4=.a98f9e35-3bb4-4aaf-b89b-a2547c4e6f29@github.com>
 <pEceZpCbgMCqwPQoKiGcLgFlv-UpLg5Rv4PcHclFRKQ=.822a2343-fe24-4384-9214-f88c80a103a0@github.com>
 <aVaxH7Z4k27ox0WJk6YzZGzGWmv1PDjwRMAdMkAe7_Y=.a4bd212d-d40f-4155-9d15-4587335a417f@github.com>
Message-ID: <FpOD6g0pXtPaH7KZ-mJFSJp68HPJBSuj1AHf-1DyPJE=.d751cd3c-d565-459e-848b-e9390370d001@github.com>

On Mon, 1 Dec 2025 15:30:04 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> This adds a dependency on `Metrics` for all the Hotspot container tests. I guess this is considered OK?

I believe it's an acceptable trade-off. Many tests would need the dependancy anyway in addition to the full check for resource limits. I would rather abstract that away in a utility function, at the cost of a few other tests also requiring the module.

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

PR Comment: https://git.openjdk.org/jdk/pull/28557#issuecomment-3597274354

From roland at openjdk.org  Mon Dec  1 15:50:41 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Mon, 1 Dec 2025 15:50:41 GMT
Subject: RFR: 8370519: C2: Hit MemLimit when running with
 +VerifyLoopOptimizations
Message-ID: <W7EnT28-84mtwppISdr_ydCV9HSaXk72y7fyd29z4wQ=.7331c81d-c36f-4a1c-b949-e7045f524d07@github.com>

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    160032         0         0         0         0         0         0         0         0         0         0         0
        regAllocSplit               4189544     32728   4156816         0         0         0         0         0         0         0         0         0         0
        postAllocCopyRemoval          65456         0     65456         0         0         0         0         0         0         0         0         0         0
        fixupSpills                   32728         0     32728         0         0         0         0         0         0         0         0         0         0
        chaitinCoalesce1            1505808    262144   1243664         0         0         0         0         0         0         0         0         0         0
        output                    138300376 138300376         0         0         0         0         0         0         0         0         0         0         0
        shorten branches             360008    196368    163640         0         0         0         0         0         0         0         0         0         0


The noticeable line is:


        idealLoop                 918189632         0  38687056 872824784    392776         0         0         0         0         0   6285016         0         0


A lot of memory (almost 1 GB) gets allocated in the `comp` arena
during `idealLoop`. So even though the compilation goes over the limit
in `Compile::Code_Gen()`, the root cause is what happens earlier,
during `idealLoop`.

`_loop_or_ctrl` and `_body` are both allocated in the `comp`
arena. Accumulated over several loop opts pass, they should not use
that much memory but the test is run with `+VerifyLoopOptimizations`:
calls to `PhaseIdealLoop::verify()` cause new `PhaseIdealLoop` objects
to be allocated and more memory to be used in the `comp` arena. The
fix I propose is to allocate `_loop_or_ctrl` and `_body` in a
dedicated `ResourceArea` so memory can be reclaimed when a pass of
loop opts is over.

With that change:


Total Usage: 227682272 
    --- Arena Usage by Arena Type and compilation phase, at arena usage peak of 227682272 ---
        idealLoop                  52278416         0  38687056   6913568         0    392776         0         0         0         0         0   6285016         0         0


that is ~50MB total for `idealLoop` instead of almost 1GB. Total usage
peaks around 200MB.

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

Commit messages:
 - whitespaces
 - more
 - test case
 - more
 - clean up
 - fix

Changes: https://git.openjdk.org/jdk/pull/28581/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28581&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370519
  Stats: 345 lines in 6 files changed: 341 ins; 1 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 coleenp at openjdk.org  Mon Dec  1 15:57:10 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 1 Dec 2025 15:57:10 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting [v3]
In-Reply-To: <aoJzukx9MSHs9r0SBGTWoQYb51HlSW9ABP3ZiNqVqpo=.d6c930cc-58cb-4235-bfa5-f2b81a75d88b@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
 <aoJzukx9MSHs9r0SBGTWoQYb51HlSW9ABP3ZiNqVqpo=.d6c930cc-58cb-4235-bfa5-f2b81a75d88b@github.com>
Message-ID: <379iBIu0uk_Af-5_RZUQBFNkGyFM7iYpe4B_hg93tn8=.95e6e771-31f5-4b89-8172-aa3d0837de25@github.com>

On Mon, 1 Dec 2025 15:40:40 GMT, Chen Liang <liach at openjdk.org> 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:
> 
>   Doc tweaks

With one small change, the runtime part of this change looks good.

src/hotspot/share/ci/ciField.cpp line 220:

> 218:     return false;
> 219:   // Explicit opt-in from system classes
> 220:   if (holder->trust_final_fields())

This is missing { } so not sure where it ends, especially that it encloses an if statement, and other code.

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

Changes requested by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28540#pullrequestreview-3525748039
PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2577662841

From sgehwolf at openjdk.org  Mon Dec  1 16:05:51 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 1 Dec 2025 16:05:51 GMT
Subject: RFR: 8372615: Many container tests fail when running rootless on
 cgroup v1 [v2]
In-Reply-To: <pEceZpCbgMCqwPQoKiGcLgFlv-UpLg5Rv4PcHclFRKQ=.822a2343-fe24-4384-9214-f88c80a103a0@github.com>
References: <vMiWENH7dMmRw5miQHPYNnETLlwMgklDZyGxk_JCPu4=.a98f9e35-3bb4-4aaf-b89b-a2547c4e6f29@github.com>
 <pEceZpCbgMCqwPQoKiGcLgFlv-UpLg5Rv4PcHclFRKQ=.822a2343-fe24-4384-9214-f88c80a103a0@github.com>
Message-ID: <nPcGPmWbKt_fzUNGhwXppzCIunbqKn857JjfDvXOUEY=.23be77a4-2ee8-4baa-aaf6-753d1187713a@github.com>

On Mon, 1 Dec 2025 12:45:06 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> Many container tests verify that various resource limits work as expected. However, when running containers in rootless mode on both Docker and Podman with cgroup v1, resource limits are not supported. This causes tests to fail with error messages like: `Resource limits are not supported and ignored on cgroups V1 rootless systems`.
>> 
>> To address this, we should skip these tests when running on configurations that don't support resource limits, similar to how we already handle other unsupported configurations (e.g., missing container engine or incompatibility with a specific cgroup version or container runtime).
>> 
>> To check for this, we now need to use `Metrics.systemMetrics().getProvider()` from `jdk.internal.platform.Metrics` to detect cgroup v1. I've added this functionality to `DockerTestUtils`, which is already used by all container tests. As a result, all container tests now need to include the `java.base/jdk.internal.platform` module, even if they don't directly test resource limits.
>> 
>> Testing:
>> * Oracle tiers 1-5
>> * Local testing:
>>   - `hotspot/jtreg/containers/` 
>>   - `jdk/jdk/internal/platform/docker/`
>> on cgroup v1/v2 with Podman and Docker in both rootful and rootless configurations
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reworked check docker/resourcelimit functions

OK

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

Marked as reviewed by sgehwolf (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28557#pullrequestreview-3525791884

From mhaessig at openjdk.org  Mon Dec  1 16:12:36 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Mon, 1 Dec 2025 16:12:36 GMT
Subject: RFR: 8370519: C2: Hit MemLimit when running with
 +VerifyLoopOptimizations
In-Reply-To: <W7EnT28-84mtwppISdr_ydCV9HSaXk72y7fyd29z4wQ=.7331c81d-c36f-4a1c-b949-e7045f524d07@github.com>
References: <W7EnT28-84mtwppISdr_ydCV9HSaXk72y7fyd29z4wQ=.7331c81d-c36f-4a1c-b949-e7045f524d07@github.com>
Message-ID: <VzJzmssTnqDXP9C_T26tywRbtm8VbtFcdLXAtQLJM1o=.ebce4fa8-8cf7-4cd3-b5e0-135c4f3b06dd@github.com>

On Mon, 1 Dec 2025 15:40:00 GMT, Roland Westrelin <roland at openjdk.org> 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
>         ctorChaitin                  160032    ...

Thank you for fixing this, @rwestrel. Your fix looks good to me. I merely have two nitpicky suggestions.
I will kick off a run of testing and report back with the results.

src/hotspot/share/opto/compile.hpp line 374:

> 372:   // Compilation environment.
> 373:   Arena                 _comp_arena;            // Arena with lifetime equivalent to Compile
> 374:   ResourceArea          _idealloop_arena;       // For data whose lifetime is a pass of loop optimizations

Suggestion:

  ResourceArea          _idealloop_arena;       // For data whose lifetime is a single pass of loop optimizations
``` 
Nit: This makes it abundantly clear that the data is freed after one pass.

test/hotspot/jtreg/compiler/c2/TestVerifyLoopOptimizationsHighMemUsage.java line 27:

> 25:  * @test
> 26:  * @bug 8370519
> 27:  * @summary C2: Hit MemLimit when running with +VerifyLoopOptimizations

Unsure, but would this test qualify for `@key stress`?

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

PR Review: https://git.openjdk.org/jdk/pull/28581#pullrequestreview-3525793585
PR Review Comment: https://git.openjdk.org/jdk/pull/28581#discussion_r2577699466
PR Review Comment: https://git.openjdk.org/jdk/pull/28581#discussion_r2577714828

From qamai at openjdk.org  Mon Dec  1 16:19:23 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 1 Dec 2025 16:19:23 GMT
Subject: RFR: 8370519: C2: Hit MemLimit when running with
 +VerifyLoopOptimizations
In-Reply-To: <W7EnT28-84mtwppISdr_ydCV9HSaXk72y7fyd29z4wQ=.7331c81d-c36f-4a1c-b949-e7045f524d07@github.com>
References: <W7EnT28-84mtwppISdr_ydCV9HSaXk72y7fyd29z4wQ=.7331c81d-c36f-4a1c-b949-e7045f524d07@github.com>
Message-ID: <hO3unoRVT77Lg_o4eUNywrDezfGt2_8uZ2DPbfo0XdM=.9514b0e0-b5cd-4a9d-b595-65327fbf0fee@github.com>

On Mon, 1 Dec 2025 15:40:00 GMT, Roland Westrelin <roland at openjdk.org> 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
>         ctorChaitin                  160032    ...

src/hotspot/share/opto/compile.hpp line 810:

> 808:   // Compilation environment.
> 809:   Arena*      comp_arena()           { return &_comp_arena; }
> 810:   ResourceArea* idealloop_arena()    { return &_idealloop_arena; }

Should we make it more idiomatic C++ by having the `ResourceArea` allocated and deallocated together with the `PhaseIdealLoop` instead of attaching it to the `Compile` object?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28581#discussion_r2577746393

From bmaillard at openjdk.org  Mon Dec  1 16:55:09 2025
From: bmaillard at openjdk.org (=?UTF-8?B?QmVub8OudA==?= Maillard)
Date: Mon, 1 Dec 2025 16:55:09 GMT
Subject: RFR: 8370519: C2: Hit MemLimit when running with
 +VerifyLoopOptimizations
In-Reply-To: <W7EnT28-84mtwppISdr_ydCV9HSaXk72y7fyd29z4wQ=.7331c81d-c36f-4a1c-b949-e7045f524d07@github.com>
References: <W7EnT28-84mtwppISdr_ydCV9HSaXk72y7fyd29z4wQ=.7331c81d-c36f-4a1c-b949-e7045f524d07@github.com>
Message-ID: <rFGy_mZFS29oe2Ie23rRCqFQigWHLghMgum7heKDZcw=.8447fff4-e59d-4ea0-9005-9e5f71930489@github.com>

On Mon, 1 Dec 2025 15:40:00 GMT, Roland Westrelin <roland at openjdk.org> 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
>         ctorChaitin                  160032    ...

Thanks for fixing this @rwestrel, I agree with the fix. I noticed that this could be a problem while working on [JDK-8366990](https://bugs.openjdk.org/browse/JDK-8366990), but there was no reproducer at the time.

src/hotspot/share/opto/compile.cpp line 656:

> 654:       _stress_seed(0),
> 655:       _comp_arena(mtCompiler, Arena::Tag::tag_comp),
> 656:       _idealloop_arena(mtCompiler, Arena::Tag::tag_idealloop),

To keep the naming consistent with other mentions of `IdealLoop` in variable/field names (such as `_phase_verify_ideal_loop`), I would name this `_ideal_loop_arena`. This will make it easier to find in a code editor. Feel free to ignore if you disagree

test/hotspot/jtreg/compiler/c2/TestVerifyLoopOptimizationsHighMemUsage.java line 28:

> 26:  * @bug 8370519
> 27:  * @summary C2: Hit MemLimit when running with +VerifyLoopOptimizations
> 28:  * @run main/othervm -XX:CompileCommand=compileonly,*TestVerifyLoopOptimizationsHighMemUsage*::* -XX:-TieredCompilation -Xbatch

Out of curiosity, have you try reducing the test with `creduce`? I fixed a similar issue in [JDK-8366990](https://bugs.openjdk.org/browse/JDK-8366990), and initially reviewers were concerned about the long compilation time. I was able to get decent results with `creduce` by using  `-XX:CompileCommand=memlimit`. Not sure if it's worth doing here though.

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

PR Review: https://git.openjdk.org/jdk/pull/28581#pullrequestreview-3525878832
PR Review Comment: https://git.openjdk.org/jdk/pull/28581#discussion_r2577760668
PR Review Comment: https://git.openjdk.org/jdk/pull/28581#discussion_r2577804805

From liach at openjdk.org  Mon Dec  1 18:27:34 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 1 Dec 2025 18:27:34 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting [v4]
In-Reply-To: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
Message-ID: <ZAwzDRCIo_TqIYbErunjdBZkeKJDKFe_kgiS1dIhPrE=.fea109a5-f78d-4d6f-9344-d8afd8d3ffa9@github.com>

> 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:

  bracket styles

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28540/files
  - new: https://git.openjdk.org/jdk/pull/28540/files/7a1cfa4a..d353bdbe

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

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

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

From heidinga at openjdk.org  Mon Dec  1 18:55:09 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Mon, 1 Dec 2025 18:55:09 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting [v4]
In-Reply-To: <ZAwzDRCIo_TqIYbErunjdBZkeKJDKFe_kgiS1dIhPrE=.fea109a5-f78d-4d6f-9344-d8afd8d3ffa9@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
 <ZAwzDRCIo_TqIYbErunjdBZkeKJDKFe_kgiS1dIhPrE=.fea109a5-f78d-4d6f-9344-d8afd8d3ffa9@github.com>
Message-ID: <-9yglNAoD81NuGyLSS0ehpkPZmqK66Qyd7h4UFcztGA=.56a84f5e-a29a-4fc0-b0d7-ce20cac37851@github.com>

On Mon, 1 Dec 2025 18:27:34 GMT, Chen Liang <liach at openjdk.org> 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:
> 
>   bracket styles

A bit of meta-question about this PR and JEP 500: does this trust need to be rescinded if the user explicitly adds `--enable-final-field-mutation=` for the modules that contain these classes marked with the annotation?

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

PR Comment: https://git.openjdk.org/jdk/pull/28540#issuecomment-3598347264

From coleenp at openjdk.org  Mon Dec  1 19:16:58 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 1 Dec 2025 19:16:58 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v9]
In-Reply-To: <kETUsDmqtkS5KD5Mqw0DWHtkT3QNXgyusThNkiJeDmY=.653bd243-ef55-4d9c-81f5-4fc9828f28a3@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <kETUsDmqtkS5KD5Mqw0DWHtkT3QNXgyusThNkiJeDmY=.653bd243-ef55-4d9c-81f5-4fc9828f28a3@github.com>
Message-ID: <oGJrVUbL532qrlifsR6L1R6uzRbLJvrxDAUc3mAAtcE=.d19191b1-2c02-4406-a524-89d837108924@github.com>

On Wed, 26 Nov 2025 22:44:17 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> 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 incrementally with one additional commit since the last revision:
> 
>   missing to initialize _is_disabler_at_start

Excellent work. Thank you for answering my questions.  There's one click suggested change.

src/hotspot/share/opto/library_call.cpp line 3052:

> 3050: //
> 3051: // java_lang_Thread::set_is_in_VTMS_transition(vthread, true);
> 3052: // carrier->set_is_in_VTMS_transition(true);

Suggestion:

// java_lang_Thread::set_is_in_vthread_transition(vthread, true);
// carrier->set_is_in_vthread_transition(true);

src/hotspot/share/opto/library_call.cpp line 3058:

> 3056: // if (disable_requests > 0) {
> 3057: //   slow path: runtime call
> 3058: // }

The comment is helpful, thanks.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28361#pullrequestreview-3526451726
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2578205190
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2578206636

From coleenp at openjdk.org  Mon Dec  1 19:16:59 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 1 Dec 2025 19:16:59 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v7]
In-Reply-To: <nkiv-uD161ABXR446aJmfavXlgpGUkSoUn7ciurOUL4=.a7b1d499-b363-4ae2-ab7d-77507b890a0f@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <TrGjnbnsryaOcjBTDsAaFD5fZFjMNN0hoX0ARhwz-ME=.210bff76-1605-4e9a-8007-1861b5571894@github.com>
 <0e65HV5RscFZN_q4JGzXA7k5jlT7gw7klerMqbfz4GU=.598cedb2-fd53-458b-9047-4d712661cbe4@github.com>
 <nkiv-uD161ABXR446aJmfavXlgpGUkSoUn7ciurOUL4=.a7b1d499-b363-4ae2-ab7d-77507b890a0f@github.com>
Message-ID: <cfwM4cW61LUM-Uu7MpSH6tUh2nEGDdFp51zm8br0jQo=.42356c39-13be-4059-b762-c406b66fb019@github.com>

On Wed, 26 Nov 2025 22:46:37 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/prims/jvm.cpp line 3671:
>> 
>>> 3669: 
>>> 3670: JVM_ENTRY(void, JVM_VirtualThreadStartFinalTransition(JNIEnv* env, jobject vthread))
>>> 3671:   oop vt = JNIHandles::resolve_external_guard(vthread);
>> 
>> Why do the opto runtime versions set is_in_VTMTS_transition in both the java.lang.Thread and JavaThread and these don't?
>
> Because we set them in the intrinsic when trying to start the transition. Method `MountUnmountDisabler::start_transition` expects them to be false so we need to clear them in the opto versions.

Not sure what I was looking at when I made this comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2578213839

From coleenp at openjdk.org  Mon Dec  1 19:17:01 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 1 Dec 2025 19:17:01 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v9]
In-Reply-To: <9R5lVpD1GBtUw9g9Bc5X7wSEI2a-oFM2Q29HUmyqSmc=.5fb087cf-4305-4bf1-b730-8a3bda7fbe9a@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <TrGjnbnsryaOcjBTDsAaFD5fZFjMNN0hoX0ARhwz-ME=.210bff76-1605-4e9a-8007-1861b5571894@github.com>
 <0e65HV5RscFZN_q4JGzXA7k5jlT7gw7klerMqbfz4GU=.598cedb2-fd53-458b-9047-4d712661cbe4@github.com>
 <9R5lVpD1GBtUw9g9Bc5X7wSEI2a-oFM2Q29HUmyqSmc=.5fb087cf-4305-4bf1-b730-8a3bda7fbe9a@github.com>
Message-ID: <nOCP2N0syvhqm5y7RjeZ0KpW1_OOBCn2zZ0xSi4I08U=.a5408d06-5e36-49b7-ab48-7e0ecca43a5f@github.com>

On Wed, 26 Nov 2025 22:47:25 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1772:
>> 
>>> 1770: 
>>> 1771:   assert(java_thread != nullptr, "sanity check");
>>> 1772:   assert(!java_thread->is_in_VTMS_transition(), "sanity check");
>> 
>> Why don't you need these asserts anymore?
>
> We can?t assert this because it could be temporarily set by the target while trying to transition. Previously we had two fields in JavaThread, `_VTMS_transition_mark` and `_is_in_VTMS_transition`. `_VTMS_transition_mark` was set first (checked by the disabler), and if transitions were disabled we waited. Once the transition could start we set `_is_in_VTMS_transition`. 
> Going over the changes I see I removed one assert in `JvmtiEnvBase::get_vthread_jvf` that should be okay to keep, so I restored it. Also added an assert in `JavaThread::is_in_VTMS_transition()` (now `is_in_vthread_transition`) to verify that if it?s accessed from another thread then it has to be done from a safe context where the value will not change?right after checking.

okay.  seems like a better place for it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2578224144

From coleenp at openjdk.org  Mon Dec  1 19:17:03 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 1 Dec 2025 19:17:03 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v7]
In-Reply-To: <r3l9SBPtgjuunDBP1ao1yUkNBZw2kfca5Nrn3QjiVHY=.2542c262-3bdf-471e-9dab-838b91c18590@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <TrGjnbnsryaOcjBTDsAaFD5fZFjMNN0hoX0ARhwz-ME=.210bff76-1605-4e9a-8007-1861b5571894@github.com>
 <0e65HV5RscFZN_q4JGzXA7k5jlT7gw7klerMqbfz4GU=.598cedb2-fd53-458b-9047-4d712661cbe4@github.com>
 <zc0-WUDsL6ALYMT-NQD9hMHFy4ZRH6fq7Tr2sD2sK5g=.d15dc9c7-ed0d-4c2f-95c2-7ca0758fde0a@github.com>
 <r3l9SBPtgjuunDBP1ao1yUkNBZw2kfca5Nrn3QjiVHY=.2542c262-3bdf-471e-9dab-838b91c18590@github.com>
Message-ID: <6tlPVcUVZe08HkhCK5LeJ48-wmHb5YjA-Yf4H2NtQf8=.348b2255-44c9-4d43-8045-384b17b3a7d3@github.com>

On Wed, 26 Nov 2025 22:48:01 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Why is there the same flag with the same name in both the Java class and C++ JavaThread?  Might be an efficient cache, so something should say that (if true).
>
> The one in `JavaThread` is needed for the `disable_transition_for_all` case. Processing each vthread is not viable, so we instead process all `JavaThreads`. If no `JavaThread` is in a transition then it implies no vthread is in a transition.

So why do you need one in java_lang_Thread then?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2578256282

From coleenp at openjdk.org  Mon Dec  1 19:17:04 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 1 Dec 2025 19:17:04 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v4]
In-Reply-To: <G8Y1SK9ja-KTRTf8ZjkrTpP9-BuGT3EE_XR_gNKOgmo=.2fbf4064-83a8-4466-963e-0638e4953b76@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <vhTZAlugNRnwLQ1m96RLTUp7VJJcIVGA3Z7I6BV2s3A=.9d218187-19a1-49c9-b2de-5014d5a5930f@github.com>
 <6WDKeD8iQTXDPhR0ohPvA6KVufW0uXHBmyZ5oOWfYWI=.44d63e7f-fbdb-47b6-8b36-f0d0cb35fb91@github.com>
 <G8Y1SK9ja-KTRTf8ZjkrTpP9-BuGT3EE_XR_gNKOgmo=.2fbf4064-83a8-4466-963e-0638e4953b76@github.com>
Message-ID: <Nz_gL9kCqf3GKbdB4T4T_UoE8J45NLTji0LwNNwkZqM=.4de33567-671c-4dd5-9475-a1d9448bfcea@github.com>

On Tue, 25 Nov 2025 23:49:29 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/runtime/mountUnmountDisabler.cpp line 126:
>> 
>>> 124:          || global_start_transition_disable_count() > base_disable_count
>>> 125:          JVMTI_ONLY(|| (JvmtiVTSuspender::is_vthread_suspended(java_lang_Thread::thread_id(vthread)) || thread->is_suspended()));
>>> 126: }
>> 
>> I like this approach with the JVMTIStartTransition and JVMTIEndTransition helper classes. It is a nice way to decouple the JVMTI part of the protocol. Introducing the `is_start_transition_disabled()` function was also long desired. Also, I like the functions `start_transition()` and `end_transition()` became pretty simple and clean!
>
> This is the function that needs a comment why you're testing all these things (and why base_disable_count is one for JVMTI). It's nice as a function that tests all the different values.

Looks good.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2578310137

From coleenp at openjdk.org  Mon Dec  1 19:17:06 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 1 Dec 2025 19:17:06 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v4]
In-Reply-To: <dILqkj4lXJ4BFqiA_1bQoNKzH2HGfJkhCgpvrioOI2o=.d1cc45e7-e881-46f1-8174-ce5a4758e3e9@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <vhTZAlugNRnwLQ1m96RLTUp7VJJcIVGA3Z7I6BV2s3A=.9d218187-19a1-49c9-b2de-5014d5a5930f@github.com>
 <wBmoDBE-uYTn5O-_DiDaru-MJcVNxroeRUQuy-wgQ2k=.f288a304-1406-4427-b396-e1f20bf77edb@github.com>
 <WGM9jKBLVj7jzMHIx6DlWSJLBnRd8-AmaVYSf4AbPpM=.c992b90b-8a1b-4d4f-b2bd-9682a9ad3025@github.com>
 <6kxaoFZTU2CYGKZpONDliyxGikpxbLMaxUtuqENnlq4=.4e48b44a-522f-4568-b4da-96b0184e5afc@github.com>
 <dILqkj4lXJ4BFqiA_1bQoNKzH2HGfJkhCgpvrioOI2o=.d1cc45e7-e881-46f1-8174-ce5a4758e3e9@github.com>
Message-ID: <Vyw5XV3F-IDMcsHikh30-Dfg63fGhv_svd314qvzZw4=.926af9b2-41ec-4117-b76d-aeee5555063e@github.com>

On Wed, 26 Nov 2025 07:33:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This could be a simple cleanup of all these occurrences later.
>
> Yes this is terribly obscure (doing the assignment in the loop condition check - surprised that is even allowed) and also violates the style-guide in relation to implicit booleans. But frankly it is an awful use of a for-loop in my opinion.

Filed https://bugs.openjdk.org/browse/JDK-8372840 as a cleanup task.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2578305847

From vlivanov at openjdk.org  Mon Dec  1 19:31:58 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Mon, 1 Dec 2025 19:31:58 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v5]
In-Reply-To: <r4etVDZnERk-bUlx-6uMtxP03xvMa0a51MnBlA7eIz0=.4e16178f-517a-400e-a7bf-0a890664aa2c@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
 <r4etVDZnERk-bUlx-6uMtxP03xvMa0a51MnBlA7eIz0=.4e16178f-517a-400e-a7bf-0a890664aa2c@github.com>
Message-ID: <RNTZqITub3JNnExn66B6WObEnfMzmxCqweKFNktAKo8=.e711597d-210a-497d-a27b-9c1f40ce4552@github.com>

On Mon, 1 Dec 2025 15:02:50 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> ArrayKlass doesn't set AccessFlags so don't look for them there.  See CR for details.
>> Fixed SA and jvmci.  @iwanowww Can you check that I changed C2 correctly (we talked about this in August).
>> Tested with tier1-4.  5-7 in progress.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added a comment for checking interface guard after array guard.

Looks good.

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

Marked as reviewed by vlivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28371#pullrequestreview-3526629937

From erikj at openjdk.org  Mon Dec  1 19:35:52 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 1 Dec 2025 19:35:52 GMT
Subject: RFR: 8351842: Windows specific issues in combination of JEP 493
 and --with-external-symbols-in-bundles=public [v6]
In-Reply-To: <7xjbY7Wkdo7ImiFeTdjUWgYkB-7155QLLxtZ13M3-Io=.d86b647e-6335-43ea-bf1c-ccd2113e74dd@github.com>
References: <R-zg2t6gMm9oZgSijkRxJ0ErqtvoFeqPyfUGbhZRkEQ=.17b0ed93-ea7b-4a37-8471-12624c937a71@github.com>
 <7xjbY7Wkdo7ImiFeTdjUWgYkB-7155QLLxtZ13M3-Io=.d86b647e-6335-43ea-bf1c-ccd2113e74dd@github.com>
Message-ID: <huhCl0rPGZES4M2bmzw3UNOSr9o3ZZJeMxKJ32-4aiY=.56837106-54a9-489d-a66c-b301ed27f53b@github.com>

On Mon, 1 Dec 2025 09:31:58 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> This PR addresses an issue that can be observed when building on Windows with configure options `--enable-linkable-runtime` and `--with-external-symbols-in-bundles=public`.
>> 
>> The problem is that with this special build configuration, we build two sets of .pdb files for the binaries. The first set is the standard debug symbols files named <binary-name>.pdb. The second set consists of stripped debug symbols file called <binary-name>.stripped.pdb which have less information but enough to present line numbers in hs-err files.
>> 
>> During build we use the *.stripped.pdb files for compiling the jmods and also the bundle files. However, in the images folder, both sets of .pdb files exist. The tests for runtime linking will now, in the absence of jmod files, pick up the .pdb files (without *stripped*) from images, but in the runtime the hashes of the *stripped* files are stored.
>> 
>> With this change, the standard .pdb files in the `--with-external-symbols-in-bundles=public` configuration are now the stripped files and we create a set of full pdb files named *.full.pdb. Jmods and Bundles still contain the stripped pdb files and we also fix the issue that the debug symbols bundle also contained stripped pdb files so far. With this fix, it will contain the full pdb files and extracting these over a JDK runtime will replace stripped pdbs with full pdbs.
>
> Christoph Langer has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Cleanup comment
>  - Fix pdb filtering for JMODs build

> OK, finally I have updated my PR to implement the suggestions of @erikj79. Now the exploded image during the build will only contain the full pdb files and in the actual JDK and JRE images, we'll have the stripped pdb files (as well as in the jmods), if the option is set. And this also propagates to bundles. The debug image/debug bundle will of course only have the full symbol files.

>From what I can tell, this is also removing the full debug symbols from the actual JDK/JRE images in all cases and all platforms, so they actually match the bundles. I think that's ok, but it needs to be clearly stated somewhere, at least in the bug, for future reference of when that happened.

make/CreateJmods.gmk line 72:

> 70:         DEST := $(LIBS_DIR_FILTERED), \
> 71:         FILES := $(FILES_LIBS), \
> 72:         NAME_MACRO := rename_stripped \

These trailing commas were deliberate and are part of the [Code Conventions for the Build System](https://openjdk.org/groups/build/doc/code-conventions.html) (17, though it's not very clearly stated).

make/Images.gmk line 313:

> 311:   $(call SetupCopyStrippedDebuginfo,JDK)
> 312:   $(call SetupCopyStrippedDebuginfo,JRE)
> 313: endif

I might be missing something, but why is this needed? Shouldn't the public pdbs already be part of the jmods in this case and so would get linked into the image by jlink?

make/Images.gmk line 322:

> 320:       $(eval DBGFILES := $(if $(filter true+public,$(call isTargetOs,windows)+$(SHIP_DEBUG_SYMBOLS)), \
> 321:         $(filter-out %.stripped.pdb,$(DBGFILES)),$(DBGFILES)) \
> 322:       ) \

I think I would use lower case for `DBGFILES` to signify a local variable and reduce risk of clashing with any other variable in the current context.

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

PR Review: https://git.openjdk.org/jdk/pull/24012#pullrequestreview-3525547958
PR Review Comment: https://git.openjdk.org/jdk/pull/24012#discussion_r2577512768
PR Review Comment: https://git.openjdk.org/jdk/pull/24012#discussion_r2578323956
PR Review Comment: https://git.openjdk.org/jdk/pull/24012#discussion_r2578344932

From alanb at openjdk.org  Mon Dec  1 19:48:57 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 1 Dec 2025 19:48:57 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v9]
In-Reply-To: <nW9xOi2sq3K_3ZpNyvvgzUf2p0roZU8hkKxcEtvK1nI=.03abf855-5f7b-4055-972c-8cff69df3816@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <FPqDAUXw_1ZtwQLFHIgv1HAANXJn4kCHtofPMhG_gmw=.c05ba258-723f-4abc-b35a-ca29f02a4df5@github.com>
 <jFNO_Y3Ag0QIDP4INNnPUNDYjcoGHFZ83C3mebo7o9U=.dc183f1f-5f99-479f-832c-8af9c4fcf72a@github.com>
 <nW9xOi2sq3K_3ZpNyvvgzUf2p0roZU8hkKxcEtvK1nI=.03abf855-5f7b-4055-972c-8cff69df3816@github.com>
Message-ID: <jw0XiQQN7uLuurYCvcroRUTtpvzKYgKXpU1_lKcRWMo=.d06cff86-674b-4f54-951e-c83867e79f43@github.com>

On Thu, 20 Nov 2025 23:05:26 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> How about removing these methods and just have an extra boolean parameter in `start/endTransition`?
>> https://github.com/pchilano/jdk/compare/JDK-8364343...pchilano:jdk:startEndTransitionsOnly
>
> I renamed the methods as suggested. I remembered that we separated ThreadStart/ThreadEnd in 8306028 for future improvements related to JVMTI. Not sure if that?s still relevant but in any case probably better to leave that discussion for a separate bug.

Given the comment block to define the terms "mount transition" and "unmount transition" then we could go a bit further and make it 6 methods: start/endMountTransition, start/endUnmountTransition, endFirstMountTransition and  startLastUnmountTransition. We don't have to do it now, but it would make the use-sites clearer I think.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2578388614

From david.holmes at oracle.com  Mon Dec  1 20:19:53 2025
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 2 Dec 2025 06:19:53 +1000
Subject: Any reason why +PrintFlagsFinal requires unlocking experimental
 and diagnostic flags to print their default values?
In-Reply-To: <93ed9b47-f149-4d9f-8474-0956e5d39a1c@redhat.com>
References: <849ebf93-c3fb-45c9-92c8-21a49b3e9946@redhat.com>
 <5ff2a0a5-9d61-466d-9ada-5ba911185815@oracle.com>
 <CAA-vtUw=7=NQvzV1bP6AsCKsJruKZ4KvQaSimczD8NY-44X_=w@mail.gmail.com>
 <75d56d4d-6d4d-48c1-8d9d-86d92249346d@oracle.com>
 <e03864c5-1dc9-492a-89b5-146706cd2c4c@redhat.com>
 <40274532-c875-4339-81cf-00b4c0776536@oracle.com>
 <75941750-84ae-4ce7-8748-3dcac82d4628@redhat.com>
 <8cd2493e-6fdf-4399-934a-e74db442265f@oracle.com>
 <022ed95d-1aaf-492c-a874-a69544a2627a@redhat.com>
 <93ed9b47-f149-4d9f-8474-0956e5d39a1c@redhat.com>
Message-ID: <9b3db1fb-1d87-47fa-b6d6-d456a817146d@oracle.com>

On 1/12/2025 9:12 pm, Frederic Thevenet wrote:
> PS: All that to say that, yes I think simply removing the 
> `flagTable[i].is_unlocked()` check is quite possibly the way to go (I 
> hit send too soon, sorry).

Sorry, I was overlooking all the other usecases. You are quite right 
that I have reservations about changing some of those. So I stand by:

 > Well there is no obvious reason that these flags should differ in 
what kind of flags they print

but withdraw the actual suggested fix.

David
-----
> On 12/1/25 11:59, Frederic Thevenet wrote:
>>
>>
>> On 12/1/25 11:17, David Holmes wrote:
>>> On 1/12/2025 8:10 pm, Frederic Thevenet wrote:
>>>>
>>>>
>>>> On 12/1/25 10:59, David Holmes wrote:
>>>>> On 1/12/2025 7:41 pm, Frederic Thevenet wrote:
>>>>>> Thanks for filling the bug, David; I've assigned it to myself and 
>>>>>> will propose a PR for this shortly.
>>>>>>
>>>>>> Before I do, there's one point I feel might be worth clarifying in 
>>>>>> this discussion first.
>>>>>> In the current implementation, PrintFlagsFinal and 
>>>>>> PrintFlagsRanges are quite tightly intertwined, as one acts as an 
>>>>>> "upgrade" to the other (i.e. setting PrintFlagsRanges will 
>>>>>> override PrintFlagsFinal).
>>>>>> To me, it makes sense to change the behaviour for PrintFlagsRanges 
>>>>>> to also print all flags if we do it for PrintFlagsFinal, but I 
>>>>>> wanted to first ask if anyone sees a reason not to do this?
>>>>>
>>>>> I think that makes sense. Though you can then extend the same logic 
>>>>> to PrintFlagsInitial and even PrintFlagsWithComments, so the scope 
>>>>> expands. If you just want to restrict the change to PrintFlagsFinal 
>>>>> then I think the simplest thing is to just expand:
>>>>>
>>>>> void JVMFlag::printFlags(outputStream* out, bool withComments, bool 
>>>>> printRanges, bool skipDefaults) {
>>>>>
>>>>> to
>>>>>
>>>>> void JVMFlag::printFlags(outputStream* out, bool withComments, bool 
>>>>> printRanges, bool skipDefaults, bool printLocked) {
>>>>>
>>>>> and then have
>>>>>
>>>>> ? // All the flags that get adjusted by VM_Version_init and os::init_2
>>>>> ? // have been set so dump the flags now.
>>>>> ? if (PrintFlagsFinal || PrintFlagsRanges) {
>>>>> ??? JVMFlag::printFlags(tty, false, PrintFlagsRanges, false, 
>>>>> PrintFlagsFinal);
>>>>> ? }
>>>>
>>>> With regard to PrintFlagsInitial or PrintFlagsWithComments, it 
>>>> wasn't my primary goal to change these but I can certainly look into 
>>>> it while I'm at it if there is a consensus that it is in fact a good 
>>>> idea.
>>>> Anyone care to? comment?
>>>
>>> Well there is no obvious reason that these flags should differ in 
>>> what kind of flags they print - they only differ in what data gets 
>>> printed for each flag.
>>>
>>> Maybe it is simpler and more consistent to just delete the
>>>
>>> ?flagTable[i].is_unlocked()
>>>
>>> check.
>>
>> Well yes indeed, but then aren't we right back at my initial proposal, 
>> which we were worried might be too far-reaching? (Or maybe it was just 
>> me who misunderstood your first answer?)
>>
>> Right now I can list 6 call sites for the underlying 
>> JVMFlag::printFlags methods:
>> - For handling PrintFlagsFinal and? PrintFlagsRanges in init.cpp [0]
>> - For -XprintFlags in arguments.cpp [1]
>> - For PrintFlagsInitial? in arguments.cpp [2]
>> - For PrintFlagsWithComments in arguments.cpp [3]
>> - For printing flags in hs_err reports in vmError.cpp [4]
>> - For handling PrintVMFlagsDCmd in diagnosticCommand.cpp [5]
>>
>> As per our current discussion, we probably want the first fourto 
>> exhibit the same behaviour, for the sake of coherency.
>> Then, as mentioned before, I believe calling? JVMFlag::printFlags with 
>> skipDefaults to true would not be affected by removing the unlocked 
>> check at all (so printing flags in hs_err would not change).
>> Finally, when it comes to the implementation of the PrintVMFlagsDCmd 
>> diagnostic command, it already offers two modes controlled by the 
>> consumer, one for only showing set flags and one for showing "all" 
>> flags: I feel that also showing locked flags in this case would not be 
>> a bad thing.
>>
>> [0] https://github.com/openjdk/jdk/ 
>> blob/5bd7db034aaf8aa6780945e02a7f9a35e16b036e/src/hotspot/share/ 
>> runtime/init.cpp#L210
>> [1] https://github.com/openjdk/jdk/ 
>> blob/5bd7db034aaf8aa6780945e02a7f9a35e16b036e/src/hotspot/share/ 
>> runtime/arguments.cpp#L2528C18-L2528C19
>> [2] https://github.com/openjdk/jdk/ 
>> blob/5bd7db034aaf8aa6780945e02a7f9a35e16b036e/src/hotspot/share/ 
>> runtime/arguments.cpp#L3467
>> [3] https://github.com/openjdk/jdk/ 
>> blob/5bd7db034aaf8aa6780945e02a7f9a35e16b036e/src/hotspot/share/ 
>> runtime/arguments.cpp#L3473
>> [4] https://github.com/openjdk/jdk/ 
>> blob/5bd7db034aaf8aa6780945e02a7f9a35e16b036e/src/hotspot/share/ 
>> utilities/vmError.cpp#L1277
>> [5] https://github.com/openjdk/jdk/ 
>> blob/5bd7db034aaf8aa6780945e02a7f9a35e16b036e/src/hotspot/share/ 
>> services/diagnosticCommand.cpp#L256
>>
>>>
>>> David
>>>>>
>>>>> David
>>>>>> Cheers
>>>>>> Frederic
>>>>>>
>>>>>> On 12/1/25 10:21, David Holmes wrote:
>>>>>>> Okay I have filed:
>>>>>>>
>>>>>>> JDK-8372802: PrintFlagsFinal should also print locked flags
>>>>>>>
>>>>>>> but note there is no commitment for anyone to actually perform 
>>>>>>> the work.
>>>>>>>
>>>>>>> David
>>>>>>>
>>>>>>> On 28/11/2025 3:19 pm, Thomas St?fe wrote:
>>>>>>>> I am very much in favor of printing all flags, for the reasons 
>>>>>>>> Frederic has given. When one supports many different releases, 
>>>>>>>> it is a huge timesaver not to have to look up flags but see them 
>>>>>>>> right there in the customer logs. The ability of PrintFlagsFinal 
>>>>>>>> to give me all flags, including default values, after they are 
>>>>>>>> resolved to their final values, is also very useful during 
>>>>>>>> development.
>>>>>>>>
>>>>>>>> For simplicity, I would prefer just to change the behavior of 
>>>>>>>> PrintFlagsFinal to do that, but I could live with a new 
>>>>>>>> PrintAllFlagsFinal.
>>>>>>>>
>>>>>>>> Number of normal flags: 513, incl. diagnostic: 777, incl. 
>>>>>>>> experimental&diagnostic: 933. (Jdk 25). So, it's?a bit more. I 
>>>>>>>> am not bothered by this, since this list never fits onto a 
>>>>>>>> single screen anyway. People grep. But if others prefer an extra 
>>>>>>>> flag, sure, let's?have one.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Nov 27, 2025 at 3:05?AM David Holmes 
>>>>>>>> <david.holmes at oracle.com <mailto:david.holmes at oracle.com>> wrote:
>>>>>>>>
>>>>>>>> ??? On 27/11/2025 12:53 am, Frederic Thevenet wrote:
>>>>>>>> ???? > Hi,
>>>>>>>> ???? >
>>>>>>>> ???? > Currently, using +PrintFlagsFinal prints out all JVM 
>>>>>>>> flags and their
>>>>>>>> ???? > values, even if they were not modified from their 
>>>>>>>> default, except
>>>>>>>> ??? for
>>>>>>>> ???? > 'locked' flags, i.e. Experimental and Diagnotic flags. In 
>>>>>>>> order
>>>>>>>> ??? to have
>>>>>>>> ???? > those printed out as well, one must first 'unlock' them 
>>>>>>>> (with
>>>>>>>> ???? > +UnlockExperimentalVMOptions, for instance).
>>>>>>>>
>>>>>>>> ??? I think this was simply a pragmatic decision to avoid 
>>>>>>>> overwhelming the
>>>>>>>> ??? user with information that should not be relevant.
>>>>>>>> ???? > Now, is their a strong reason for not always displaying 
>>>>>>>> the default
>>>>>>>> ???? > values for those in scenarios were there is no concerns 
>>>>>>>> that the
>>>>>>>> ??? output
>>>>>>>> ???? > might be too large (that is when calling upon
>>>>>>>> ??? 'JVMFlag::printFlags' with
>>>>>>>> ???? > 'skipDefaults' set to false, like PrintFlagsFinal does)?
>>>>>>>> ???? >
>>>>>>>> ???? > The reason for this question is that when chasing a bug 
>>>>>>>> in scenarios
>>>>>>>> ???? > where one can only rely on logs or output provided by 
>>>>>>>> tools that
>>>>>>>> ??? uses
>>>>>>>> ???? > +PrintFlagsFinal, getting the default values *in the 
>>>>>>>> conditions that
>>>>>>>> ???? > those logs where produced* can be tricky as it depends on 
>>>>>>>> the exact
>>>>>>>> ???? > version of the JDK that was running, and some values can be
>>>>>>>> ??? changed by
>>>>>>>> ???? > ergonomics.
>>>>>>>>
>>>>>>>> ??? Ouch. I think that would be a poor design choice for 
>>>>>>>> diagnostic, and
>>>>>>>> ??? especially experimental flags!
>>>>>>>>
>>>>>>>>
>>>>>>>> Not every experimental/diagnostic flag is a boolean that 
>>>>>>>> defaults to false and controls an opt-in feature. We have non- 
>>>>>>>> boolean experimental flags and boolean flags that default to 
>>>>>>>> true. It is not unthinkable that those are changed during VM start.
>>>>>>>>
>>>>>>>>
>>>>>>>> ???? > If you need to know the default for experimental flags -- 
>>>>>>>> which
>>>>>>>> ??? given
>>>>>>>> ???? > their nature can and do change often -- your choices are to
>>>>>>>> ??? either ask
>>>>>>>> ???? > for these logs to be generated again using
>>>>>>>> ??? +UnlockExperimentalVMOptions
>>>>>>>> ???? > (even if there is no intention of changing an 
>>>>>>>> experimental flag)
>>>>>>>> ??? or to
>>>>>>>> ???? > go on a time consuming deep dive into the code base for 
>>>>>>>> the exact
>>>>>>>> ???? > version of the JDK that was used. Neither is ideal.
>>>>>>>>
>>>>>>>> ??? True, but for experimental flags in particular, unless you 
>>>>>>>> are deep
>>>>>>>> ??? diving into the code how can you know whether a particular 
>>>>>>>> flag and its
>>>>>>>> ??? value are relevant to your debugging in the first place?
>>>>>>>>
>>>>>>>>
>>>>>>>> I think the point here is reducing analyst strain. It's?not that 
>>>>>>>> it is impossible to get the information otherwise, but that 
>>>>>>>> it's?convenient and stress-reducing to have one sure way to look 
>>>>>>>> up all resolved flag?values for a customer's JVM run. Folks who 
>>>>>>>> have to work with many cases involving different JVM versions 
>>>>>>>> would value this.
>>>>>>>>
>>>>>>>> BTW, we do print default values for non-experimental non- 
>>>>>>>> diagnostic flags, too. The same reasoning applies here: if 
>>>>>>>> its?not changed, you could look up the default value.
>>>>>>>>
>>>>>>>>
>>>>>>>> ??? That said, I don't see any harm in providing a way to print 
>>>>>>>> all flags,
>>>>>>>> ??? though whether by default or by a new -XX:PrintAllFlagsFinal 
>>>>>>>> flag, I'm
>>>>>>>> ??? not sure.
>>>>>>>>
>>>>>>>>
>>>>>>>> Wonderful, let's?do that then.
>>>>>>>>
>>>>>>>> Cheers, Thomas
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
> 


From liach at openjdk.org  Mon Dec  1 20:23:49 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 1 Dec 2025 20:23:49 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting [v4]
In-Reply-To: <ZAwzDRCIo_TqIYbErunjdBZkeKJDKFe_kgiS1dIhPrE=.fea109a5-f78d-4d6f-9344-d8afd8d3ffa9@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
 <ZAwzDRCIo_TqIYbErunjdBZkeKJDKFe_kgiS1dIhPrE=.fea109a5-f78d-4d6f-9344-d8afd8d3ffa9@github.com>
Message-ID: <ALPzzBRT4GNXoT9UlR_qMPN9sARRF5F9V1JgzL1b6Ys=.41c2a088-a860-4a24-a97f-88d7955b053d@github.com>

On Mon, 1 Dec 2025 18:27:34 GMT, Chen Liang <liach at openjdk.org> 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:
> 
>   bracket styles

This PR currently does not interact with JEP 500. However, as specified in `Field.set`, the result of setting a final field may be ignored, as Alan [commented](https://github.com/openjdk/jdk/pull/28540#discussion_r2573494589). So I don't think we need to rescind the current trusting even if users enable mutations.

In addition, @DanHeidinga I made the same fault as you when I first saw `--enable-final-field-mutation=` - this actually represents the callers, instead of the target, of `Field.set`. The target of mutation is specified via `--add-opens`, if the target field is not public.

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

PR Comment: https://git.openjdk.org/jdk/pull/28540#issuecomment-3598676839

From liach at openjdk.org  Mon Dec  1 20:27:07 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 1 Dec 2025 20:27:07 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required
Message-ID: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>

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`)

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

Commit messages:
 - 8160821

Changes: https://git.openjdk.org/jdk/pull/28585/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28585&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8160821
  Stats: 135 lines in 7 files changed: 104 ins; 20 del; 11 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 liach at openjdk.org  Mon Dec  1 20:27:07 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 1 Dec 2025 20:27:07 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required
In-Reply-To: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
Message-ID: <Y9nEyi1mR5W8gbsQnXDNuX6bM0oXlBzecnVHvvIS30c=.066681bb-4493-45a1-8806-c2529c4fc49b@github.com>

On Mon, 1 Dec 2025 20:09:38 GMT, Chen Liang <liach at openjdk.org> 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`)

java.lang.invoke tests all pass. New benchmark results for `VarHandleExact`:

Benchmark                                 Mode  Cnt  Score   Error  Units
VarHandleExact.exact_exactInvocation      avgt   30  0.380 ? 0.007  ns/op
VarHandleExact.generic_exactInvocation    avgt   30  0.389 ? 0.008  ns/op
VarHandleExact.generic_genericInvocation  avgt   30  0.384 ? 0.008  ns/op

Submitting internal CI runs.

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

PR Comment: https://git.openjdk.org/jdk/pull/28585#issuecomment-3598661038

From liach at openjdk.org  Mon Dec  1 20:34:31 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 1 Dec 2025 20:34:31 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v2]
In-Reply-To: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
Message-ID: <alimS3dIZm3pu0_-XF9JhpGUr0ToN6W_E3xU9AG6jRA=.1d35e8a3-a73a-43e0-87c3-153344afd8da@github.com>

> 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:

  Logical fallacy

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28585/files
  - new: https://git.openjdk.org/jdk/pull/28585/files/522cbe9d..886d3918

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

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 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 bperez at openjdk.org  Mon Dec  1 21:30:24 2025
From: bperez at openjdk.org (Ben Perez)
Date: Mon, 1 Dec 2025 21:30:24 GMT
Subject: RFR: 8355216: Accelerate P-256 arithmetic on aarch64
Message-ID: <EiLAVdcIX_OKisbKoR6H6ADweL9LSuLfIRQgRYYNw7o=.8c823874-0af8-4c54-8e61-a2c43243b2e0@github.com>

An aarch64 implementation of the `MontgomeryIntegerPolynomial256.mult()` method

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

Commit messages:
 - Replaced scalar multiplication with neon regs, added vector by element variant of umullv
 - Removed  use, streamlined mask calculation, changed arrangement specifier for ORR
 - Added stubroutine code
 - aarch64 intrinsics for MontgomeryIntegerPolynomialP256.mult()

Changes: https://git.openjdk.org/jdk/pull/27946/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27946&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355216
  Stats: 446 lines in 4 files changed: 445 ins; 0 del; 1 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 Dec  1 21:30:28 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 1 Dec 2025 21:30:28 GMT
Subject: RFR: 8355216: Accelerate P-256 arithmetic on aarch64
In-Reply-To: <EiLAVdcIX_OKisbKoR6H6ADweL9LSuLfIRQgRYYNw7o=.8c823874-0af8-4c54-8e61-a2c43243b2e0@github.com>
References: <EiLAVdcIX_OKisbKoR6H6ADweL9LSuLfIRQgRYYNw7o=.8c823874-0af8-4c54-8e61-a2c43243b2e0@github.com>
Message-ID: <opKn1GSXP55kVVKqbbVljAneMYSaYYbjYehCmNlQvSY=.ba551dd2-d89d-451b-8d3a-66531f1c344f@github.com>

On Thu, 23 Oct 2025 01:39:02 GMT, Ben Perez <bperez at openjdk.org> wrote:

> An aarch64 implementation of the `MontgomeryIntegerPolynomial256.mult()` method

On 29/10/2025 20:18, Ben Perez wrote:
> Is there by any chance documentation for `RegSet` that I can reference while making these changes?

No, but it's all there in the source.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 7144:

> 7142: 
> 7143:   address generate_intpoly_montgomeryMult_P256() {
> 7144: 

As a general point, it would help everyone if you provided pseudocode for the whole thing.

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 7160:

> 7158:     };
> 7159: 
> 7160:     Register c_ptr = r9;

`rscratch1` and `rscratch2` are used freely by macros, so aliasing them is always rather sketchy. As far as I can tell the arg registers aren't used here, so it makes sense to use `r3`...

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 7169:

> 7167:     Register mul_tmp = r14;
> 7168:     Register n = r15;
> 7169: 

Here, you could do something like


    RegSet scratch = RegSet::range(r3, r28) - rscratch1 - rscratch2;

    {
      auto r_it = scratch.begin();
      Register
        c_ptr = *r_it++,
        a_i = *r_it++,
        c_idx = *r_it++, //c_idx is not used at the same time as a_i
        limb_mask_scalar = *r_it++,
        b_j = *r_it++,
        mod_j = *r_it++,
        mod_ptr = *r_it++,
        mul_tmp = *r_it++,
        n = *r_it++;
       ...
    }



Note that a RegSet iterator doesn't affect the RegSet it was created from, so once this block has ended you can allocate again from the set of scratch registers.

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 7201:

> 7199:     __ mov(limb_mask_scalar, 1);
> 7200:     __ neg(limb_mask_scalar, limb_mask_scalar);
> 7201:     __ lsr(limb_mask_scalar, limb_mask_scalar, 12);

Suggestion:

    __ mov(limb_mask_scalar, -UCONST64(1) >> (64 - BITS_PER_LIMB));

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 7229:

> 7227:       __ shl(high_01, __ T2D, high_01, shift1);
> 7228:       __ ushr(tmp, __ T2D, low_01, shift2);
> 7229:       __ orr(high_01, __ T2D, high_01, tmp);

Suggestion:

      __ orr(high_01, __ T16B, high_01, tmp);

everywhere.

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 7403:

> 7401:     // c3 &= LIMB_MASK;
> 7402: 
> 7403:     __ ldr(mod_j, __ post(mod_ptr, 8));

Best not to use post-increment if you can avoid it.

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 7440:

> 7438: 
> 7439:     Register res_0 = r9;
> 7440:     Register res_1 = r10;

Aliasing the same register with different names is very dangerous, and has cause hard-to-find failures in production code in the past. You can confine the `Register` instances to block scope. You can also suffix or prefix the local names with canonical register names.

Best of all is to get rid of the manual register allocation altogether, by  creating a `RegSet`, then adding and removing registers that you need, as you go along. That way the need to manually check register usage goes away altogether.

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

PR Comment: https://git.openjdk.org/jdk/pull/27946#issuecomment-3466766156
PR Review Comment: https://git.openjdk.org/jdk/pull/27946#discussion_r2460515105
PR Review Comment: https://git.openjdk.org/jdk/pull/27946#discussion_r2460510697
PR Review Comment: https://git.openjdk.org/jdk/pull/27946#discussion_r2461123587
PR Review Comment: https://git.openjdk.org/jdk/pull/27946#discussion_r2460582673
PR Review Comment: https://git.openjdk.org/jdk/pull/27946#discussion_r2461125143
PR Review Comment: https://git.openjdk.org/jdk/pull/27946#discussion_r2460621762
PR Review Comment: https://git.openjdk.org/jdk/pull/27946#discussion_r2460612964

From bperez at openjdk.org  Mon Dec  1 21:30:28 2025
From: bperez at openjdk.org (Ben Perez)
Date: Mon, 1 Dec 2025 21:30:28 GMT
Subject: RFR: 8355216: Accelerate P-256 arithmetic on aarch64
In-Reply-To: <opKn1GSXP55kVVKqbbVljAneMYSaYYbjYehCmNlQvSY=.ba551dd2-d89d-451b-8d3a-66531f1c344f@github.com>
References: <EiLAVdcIX_OKisbKoR6H6ADweL9LSuLfIRQgRYYNw7o=.8c823874-0af8-4c54-8e61-a2c43243b2e0@github.com>
 <opKn1GSXP55kVVKqbbVljAneMYSaYYbjYehCmNlQvSY=.ba551dd2-d89d-451b-8d3a-66531f1c344f@github.com>
Message-ID: <l48FZMwpVg-gJbowobeog1zHjklRJO4khHGvRiEaQ4s=.448c6c83-95df-4bbd-88c5-0a000f91c548@github.com>

On Fri, 24 Oct 2025 13:36:52 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> An aarch64 implementation of the `MontgomeryIntegerPolynomial256.mult()` method
>
> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 7144:
> 
>> 7142: 
>> 7143:   address generate_intpoly_montgomeryMult_P256() {
>> 7144: 
> 
> As a general point, it would help everyone if you provided pseudocode for the whole thing.

Happy to add pseudocode but it will be quite long and almost identical to what is already in `MontgomeryIntegerPolynomial256.mult()` except mine uses a loop instead of unrolling the whole thing

> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 7160:
> 
>> 7158:     };
>> 7159: 
>> 7160:     Register c_ptr = r9;
> 
> `rscratch1` and `rscratch2` are used freely by macros, so aliasing them is always rather sketchy. As far as I can tell the arg registers aren't used here, so it makes sense to use `r3`...

Is there a reason hotspot doesn't leave `r9` open for use as a caller saved local variable like in the ARM docs https://developer.arm.com/documentation/102374/0103/Procedure-Call-Standard. Either way will fix.

> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 7169:
> 
>> 7167:     Register mul_tmp = r14;
>> 7168:     Register n = r15;
>> 7169: 
> 
> Here, you could do something like
> 
> 
>     RegSet scratch = RegSet::range(r3, r28) - rscratch1 - rscratch2;
> 
>     {
>       auto r_it = scratch.begin();
>       Register
>         c_ptr = *r_it++,
>         a_i = *r_it++,
>         c_idx = *r_it++, //c_idx is not used at the same time as a_i
>         limb_mask_scalar = *r_it++,
>         b_j = *r_it++,
>         mod_j = *r_it++,
>         mod_ptr = *r_it++,
>         mul_tmp = *r_it++,
>         n = *r_it++;
>        ...
>     }
> 
> 
> 
> Note that a RegSet iterator doesn't affect the RegSet it was created from, so once this block has ended you can allocate again from the set of scratch registers.

Is there by any chance documentation for `RegSet` that I can reference while making these changes?

> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 7229:
> 
>> 7227:       __ shl(high_01, __ T2D, high_01, shift1);
>> 7228:       __ ushr(tmp, __ T2D, low_01, shift2);
>> 7229:       __ orr(high_01, __ T2D, high_01, tmp);
> 
> Suggestion:
> 
>       __ orr(high_01, __ T16B, high_01, tmp);
> 
> everywhere.

thanks for the suggestion! Does using `T16B` improve performance? Similarly, should this be applied to `EOR` as well?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27946#discussion_r2475133382
PR Review Comment: https://git.openjdk.org/jdk/pull/27946#discussion_r2539340501
PR Review Comment: https://git.openjdk.org/jdk/pull/27946#discussion_r2475267081
PR Review Comment: https://git.openjdk.org/jdk/pull/27946#discussion_r2474686235

From aph at openjdk.org  Mon Dec  1 21:30:28 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 1 Dec 2025 21:30:28 GMT
Subject: RFR: 8355216: Accelerate P-256 arithmetic on aarch64
In-Reply-To: <l48FZMwpVg-gJbowobeog1zHjklRJO4khHGvRiEaQ4s=.448c6c83-95df-4bbd-88c5-0a000f91c548@github.com>
References: <EiLAVdcIX_OKisbKoR6H6ADweL9LSuLfIRQgRYYNw7o=.8c823874-0af8-4c54-8e61-a2c43243b2e0@github.com>
 <opKn1GSXP55kVVKqbbVljAneMYSaYYbjYehCmNlQvSY=.ba551dd2-d89d-451b-8d3a-66531f1c344f@github.com>
 <l48FZMwpVg-gJbowobeog1zHjklRJO4khHGvRiEaQ4s=.448c6c83-95df-4bbd-88c5-0a000f91c548@github.com>
Message-ID: <Q3VleKPv_j0CQFYhlsJ8ZWE1FPoDViSxl67pdB61c_0=.f4db1766-3e12-41bd-af19-bf43b2b9e3c6@github.com>

On Tue, 18 Nov 2025 19:00:21 GMT, Ben Perez <bperez at openjdk.org> wrote:

> Is there a reason hotspot doesn't leave `r9` open for use as a caller saved local variable like in the ARM docs https://developer.arm.com/documentation/102374/0103/Procedure-Call-Standard. Either way will fix.

Yes, because a ton of convenience macros in `MacroAssembler` use it. HotSpot internally doesn't use the APCS.

>> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 7169:
>> 
>>> 7167:     Register mul_tmp = r14;
>>> 7168:     Register n = r15;
>>> 7169: 
>> 
>> Here, you could do something like
>> 
>> 
>>     RegSet scratch = RegSet::range(r3, r28) - rscratch1 - rscratch2;
>> 
>>     {
>>       auto r_it = scratch.begin();
>>       Register
>>         c_ptr = *r_it++,
>>         a_i = *r_it++,
>>         c_idx = *r_it++, //c_idx is not used at the same time as a_i
>>         limb_mask_scalar = *r_it++,
>>         b_j = *r_it++,
>>         mod_j = *r_it++,
>>         mod_ptr = *r_it++,
>>         mul_tmp = *r_it++,
>>         n = *r_it++;
>>        ...
>>     }
>> 
>> 
>> 
>> Note that a RegSet iterator doesn't affect the RegSet it was created from, so once this block has ended you can allocate again from the set of scratch registers.
>
> Is there by any chance documentation for `RegSet` that I can reference while making these changes?

I could talk you through it, or give you a few more examples. It's easy to use once you get used to it.

> thanks for the suggestion! Does using `T16B` improve performance? Similarly, should this be applied to `EOR` as well?

Yes. According to the ARM, only 8B and 16B forms are the official names.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27946#discussion_r2541919496
PR Review Comment: https://git.openjdk.org/jdk/pull/27946#discussion_r2477261216
PR Review Comment: https://git.openjdk.org/jdk/pull/27946#discussion_r2476966812

From aph at openjdk.org  Mon Dec  1 21:30:29 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 1 Dec 2025 21:30:29 GMT
Subject: RFR: 8355216: Accelerate P-256 arithmetic on aarch64
In-Reply-To: <opKn1GSXP55kVVKqbbVljAneMYSaYYbjYehCmNlQvSY=.ba551dd2-d89d-451b-8d3a-66531f1c344f@github.com>
References: <EiLAVdcIX_OKisbKoR6H6ADweL9LSuLfIRQgRYYNw7o=.8c823874-0af8-4c54-8e61-a2c43243b2e0@github.com>
 <opKn1GSXP55kVVKqbbVljAneMYSaYYbjYehCmNlQvSY=.ba551dd2-d89d-451b-8d3a-66531f1c344f@github.com>
Message-ID: <-XQj1n1myEUztrPjw8lc7_-AxeCmRAiFAoBq4k6qmfU=.0f9f4eda-58c8-489f-95a1-5cb994d88031@github.com>

On Fri, 24 Oct 2025 13:57:30 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> An aarch64 implementation of the `MontgomeryIntegerPolynomial256.mult()` method
>
> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 7403:
> 
>> 7401:     // c3 &= LIMB_MASK;
>> 7402: 
>> 7403:     __ ldr(mod_j, __ post(mod_ptr, 8));
> 
> Best not to use post-increment if you can avoid it.

It adds a dependency chain between each use.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27946#discussion_r2460624122

From dlong at openjdk.org  Mon Dec  1 21:50:54 2025
From: dlong at openjdk.org (Dean Long)
Date: Mon, 1 Dec 2025 21:50:54 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v5]
In-Reply-To: <r4etVDZnERk-bUlx-6uMtxP03xvMa0a51MnBlA7eIz0=.4e16178f-517a-400e-a7bf-0a890664aa2c@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
 <r4etVDZnERk-bUlx-6uMtxP03xvMa0a51MnBlA7eIz0=.4e16178f-517a-400e-a7bf-0a890664aa2c@github.com>
Message-ID: <9COxlPt9xc7_2hrMumCuZ1wVuSvLPJCHn16RKEFoPu0=.cb81a68a-c100-44a4-8542-b2121c544f96@github.com>

On Mon, 1 Dec 2025 15:02:50 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> ArrayKlass doesn't set AccessFlags so don't look for them there.  See CR for details.
>> Fixed SA and jvmci.  @iwanowww Can you check that I changed C2 correctly (we talked about this in August).
>> Tested with tier1-4.  5-7 in progress.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added a comment for checking interface guard after array guard.

src/hotspot/share/oops/instanceKlass.hpp line 237:

> 235: 
> 236:   // State is set either at parse time or while executing, atomically to not disturb other state
> 237:   InstanceKlassFlags _misc_flags;

It looks like the size of these 3 fields, _reference_type, _access_flags, and _misc_flags, will take 8 bytes because of alignment/padding, but if _reference_type was moved to the end of InstanceKlassFlags and the order reversed, it could be reduced to 6 bytes, leaving 2 for future expansion:

InstanceKlassFlags _misc_flags; // contains _reference_type
AccessFlags        _access_flags;
char _reserved[2];

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28371#discussion_r2578843984

From dlong at openjdk.org  Mon Dec  1 22:12:52 2025
From: dlong at openjdk.org (Dean Long)
Date: Mon, 1 Dec 2025 22:12:52 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v5]
In-Reply-To: <r4etVDZnERk-bUlx-6uMtxP03xvMa0a51MnBlA7eIz0=.4e16178f-517a-400e-a7bf-0a890664aa2c@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
 <r4etVDZnERk-bUlx-6uMtxP03xvMa0a51MnBlA7eIz0=.4e16178f-517a-400e-a7bf-0a890664aa2c@github.com>
Message-ID: <TJz-eWoBprBpWz3VatBM8plPWPDaEaFG46ymLDw9onM=.b638c178-a224-41c0-9861-beb403e7660f@github.com>

On Mon, 1 Dec 2025 15:02:50 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> ArrayKlass doesn't set AccessFlags so don't look for them there.  See CR for details.
>> Fixed SA and jvmci.  @iwanowww Can you check that I changed C2 correctly (we talked about this in August).
>> Tested with tier1-4.  5-7 in progress.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added a comment for checking interface guard after array guard.

Looks good.

src/hotspot/share/opto/library_call.cpp line 4104:

> 4102:       phi->add_req(makecon(TypeInstPtr::make(env()->Object_klass()->java_mirror())));
> 4103:     }
> 4104:     // Check for interface after array since this checks AccessFlags offset into InstanceKlass.

In other words, we are accessing subtype-specific information, so we need to determine the subtype first.

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

Marked as reviewed by dlong (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28371#pullrequestreview-3527269001
PR Review Comment: https://git.openjdk.org/jdk/pull/28371#discussion_r2578897794

From bperez at openjdk.org  Mon Dec  1 22:19:09 2025
From: bperez at openjdk.org (Ben Perez)
Date: Mon, 1 Dec 2025 22:19:09 GMT
Subject: RFR: 8355216: Accelerate P-256 arithmetic on aarch64 [v2]
In-Reply-To: <EiLAVdcIX_OKisbKoR6H6ADweL9LSuLfIRQgRYYNw7o=.8c823874-0af8-4c54-8e61-a2c43243b2e0@github.com>
References: <EiLAVdcIX_OKisbKoR6H6ADweL9LSuLfIRQgRYYNw7o=.8c823874-0af8-4c54-8e61-a2c43243b2e0@github.com>
Message-ID: <nSkGY6VVBNf0vfbCIxMvDcURh7YgrECg7O2h8Dei3Lo=.ed9973ea-fb2e-45c1-92fb-e9f74d34d337@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:

  Fixed typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27946/files
  - new: https://git.openjdk.org/jdk/pull/27946/files/6d6786a0..293ad948

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 pchilanomate at openjdk.org  Mon Dec  1 22:33:47 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 1 Dec 2025 22:33:47 GMT
Subject: RFR: 8372652: Re-enable LocalRandom clinit after monitor pinning
 improvements
In-Reply-To: <IgEuelEzPt9Atv8KQR1Sa80QaKGllGNR-nWRF-sdm3Y=.72ccb838-8723-4fb8-9547-ed20e51b00f1@github.com>
References: <IgEuelEzPt9Atv8KQR1Sa80QaKGllGNR-nWRF-sdm3Y=.72ccb838-8723-4fb8-9547-ed20e51b00f1@github.com>
Message-ID: <AiWd6BJ3b5QODw8jxq5x8v2Sddaf5xl3XC_BpBJyjww=.b416f22f-15bf-49f8-b0f4-cdf327fbc22c@github.com>

On Thu, 27 Nov 2025 23:33:56 GMT, Vishal Chand <duke at openjdk.org> wrote:

> This PR re-enables LocalRandom clinit after monitor pinning improvements.
> Enabling this one would start printing random seeds, which is useful for test debugging.

Some comments on this. I think the TODO was inaccurate because JEP491 doesn't help prevent deadlock scenarios involving class initializers. If anything, it introduced additional unmount points,?making them more likely. Although this issue has now been mostly fixed with JDK-8369238, there are still some initialization paths where a thread waiting for a class to be initialized might remain pinned (besides the thread executing the class initializer which can never be unmounted). So if we want to be certain that calling `Utils.getRandomInstance` will not lead to a deadlock we need to check for possible unmount points.
The unmount points in [1] and [2] are fine because we implemented a timed-park mechanism for pinned vthreads when there are unmounted vthreads ahead in the monitor queue. This ensures that even if an unmounted vthread is selected as the successor and we run out of carriers, we will not deadlock. So the real problem is with unmount points inside the critical section, since in that case the owner of the monitor could be unmounted and might be unable to run again. For [1] I don't see any, but for [2] I see that we call `Locale.getDefault(Locale.Category.FORMAT)` which calls synchronized method `getFormatLocale()` if `defaultFormatLocale` is not initialized (which I see it's not initialized at startup so we do end up calling it at the `PrintStream.format` call).
We'll probably never encounter this issue in our testing, especially now that 8369238 has been integrated, but I thought it was worth mentioning.

[1] https://github.com/openjdk/jdk/blob/a1cc8f4e4107e361f64cf51ff73985e471cdde03/test/lib/jdk/test/lib/Utils.java#L515
[2] https://github.com/openjdk/jdk/blob/a1cc8f4e4107e361f64cf51ff73985e471cdde03/src/java.base/share/classes/java/io/PrintStream.java#L1159

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

PR Comment: https://git.openjdk.org/jdk/pull/28547#issuecomment-3599239977

From lmesnik at openjdk.org  Mon Dec  1 22:40:46 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 1 Dec 2025 22:40:46 GMT
Subject: RFR: 8372652: Re-enable LocalRandom clinit after monitor pinning
 improvements
In-Reply-To: <YiOD-Uhl8zzAYb-uLYLs9itATGW4GQjH7iPKMRtdARE=.3cebae80-b55e-4a60-b92e-593e579d4931@github.com>
References: <IgEuelEzPt9Atv8KQR1Sa80QaKGllGNR-nWRF-sdm3Y=.72ccb838-8723-4fb8-9547-ed20e51b00f1@github.com>
 <IBk5-edc3PLSPqI5HZ4pDOthGiFBlj2MDMKs_A0kLEk=.3b7097c9-afe9-4441-a0b1-bdd20eb1468f@github.com>
 <YiOD-Uhl8zzAYb-uLYLs9itATGW4GQjH7iPKMRtdARE=.3cebae80-b55e-4a60-b92e-593e579d4931@github.com>
Message-ID: <0BI-aekYlNzNe8szo_NjO14MRbrV_NjjQN6IYB_AT40=.5c548a70-d6fa-4eb9-b7cc-3c44f84ea833@github.com>

On Mon, 1 Dec 2025 15:20:27 GMT, Aleksey Shipilev <shade at openjdk.org> 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.

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

PR Comment: https://git.openjdk.org/jdk/pull/28547#issuecomment-3599260298

From coleenp at openjdk.org  Mon Dec  1 22:50:50 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 1 Dec 2025 22:50:50 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v5]
In-Reply-To: <9COxlPt9xc7_2hrMumCuZ1wVuSvLPJCHn16RKEFoPu0=.cb81a68a-c100-44a4-8542-b2121c544f96@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
 <r4etVDZnERk-bUlx-6uMtxP03xvMa0a51MnBlA7eIz0=.4e16178f-517a-400e-a7bf-0a890664aa2c@github.com>
 <9COxlPt9xc7_2hrMumCuZ1wVuSvLPJCHn16RKEFoPu0=.cb81a68a-c100-44a4-8542-b2121c544f96@github.com>
Message-ID: <tV6l3dprgBtqwSlAYCnAa6TDSh6gR6I3W79Qu2ULyWE=.08fb705d-d380-4523-9b52-96cad877e8b8@github.com>

On Mon, 1 Dec 2025 21:48:06 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added a comment for checking interface guard after array guard.
>
> src/hotspot/share/oops/instanceKlass.hpp line 237:
> 
>> 235: 
>> 236:   // State is set either at parse time or while executing, atomically to not disturb other state
>> 237:   InstanceKlassFlags _misc_flags;
> 
> It looks like the size of these 3 fields, _reference_type, _access_flags, and _misc_flags, will take 8 bytes because of alignment/padding, but if _reference_type was moved to the end of InstanceKlassFlags and the order reversed, it could be reduced to 6 bytes, leaving 2 for future expansion:
> 
> InstanceKlassFlags _misc_flags; // contains _reference_type
> AccessFlags        _access_flags;
> char _reserved[2];

ClassState is a u1 so that fills the u2 gap with reference_type.  So I don't think moving reference type will help.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28371#discussion_r2578975466

From coleenp at openjdk.org  Mon Dec  1 22:55:52 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 1 Dec 2025 22:55:52 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v5]
In-Reply-To: <TJz-eWoBprBpWz3VatBM8plPWPDaEaFG46ymLDw9onM=.b638c178-a224-41c0-9861-beb403e7660f@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
 <r4etVDZnERk-bUlx-6uMtxP03xvMa0a51MnBlA7eIz0=.4e16178f-517a-400e-a7bf-0a890664aa2c@github.com>
 <TJz-eWoBprBpWz3VatBM8plPWPDaEaFG46ymLDw9onM=.b638c178-a224-41c0-9861-beb403e7660f@github.com>
Message-ID: <a8nKroSMQd0Yd1Ct5tziN8kHUCP7MLU-66zv7qEhHXU=.65f6307b-7384-4c61-9454-c40f558bdc6e@github.com>

On Mon, 1 Dec 2025 22:09:27 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added a comment for checking interface guard after array guard.
>
> src/hotspot/share/opto/library_call.cpp line 4104:
> 
>> 4102:       phi->add_req(makecon(TypeInstPtr::make(env()->Object_klass()->java_mirror())));
>> 4103:     }
>> 4104:     // Check for interface after array since this checks AccessFlags offset into InstanceKlass.
> 
> In other words, we are accessing subtype-specific information, so we need to determine the subtype first.

I can add this to the comment if you think it's helpful.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28371#discussion_r2578992154

From pchilanomate at openjdk.org  Mon Dec  1 23:00:16 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 1 Dec 2025 23:00:16 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v10]
In-Reply-To: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
Message-ID: <T8jvz_3r2GJ8W55gqHXsRkNhMPRy3hLGF7ClwP84CM0=.c69c727e-6628-4aa2-92ca-e596542cf0e0@github.com>

> 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 terms of mount and un...

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  Fix comment in inline_native_vthread_start_transition

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28361/files
  - new: https://git.openjdk.org/jdk/pull/28361/files/7aa02a46..44af0ca9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28361&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28361&range=08-09

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

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

From pchilanomate at openjdk.org  Mon Dec  1 23:00:17 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 1 Dec 2025 23:00:17 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v9]
In-Reply-To: <oGJrVUbL532qrlifsR6L1R6uzRbLJvrxDAUc3mAAtcE=.d19191b1-2c02-4406-a524-89d837108924@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <kETUsDmqtkS5KD5Mqw0DWHtkT3QNXgyusThNkiJeDmY=.653bd243-ef55-4d9c-81f5-4fc9828f28a3@github.com>
 <oGJrVUbL532qrlifsR6L1R6uzRbLJvrxDAUc3mAAtcE=.d19191b1-2c02-4406-a524-89d837108924@github.com>
Message-ID: <m4Z0iFmXIWLMtsC9BlF0439QGNXcM3Sjrvs2e4tSRQc=.40557be4-a262-4708-90cd-1be9f80f5614@github.com>

On Mon, 1 Dec 2025 19:14:37 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Excellent work. Thank you for answering my questions. There's one click suggested change.
>
Thanks for the review Coleen!

> src/hotspot/share/opto/library_call.cpp line 3052:
> 
>> 3050: //
>> 3051: // java_lang_Thread::set_is_in_VTMS_transition(vthread, true);
>> 3052: // carrier->set_is_in_VTMS_transition(true);
> 
> Suggestion:
> 
> // java_lang_Thread::set_is_in_vthread_transition(vthread, true);
> // carrier->set_is_in_vthread_transition(true);

Fixed. Also fixed the comment above: the other caller is `startFinalTransition`.

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

PR Comment: https://git.openjdk.org/jdk/pull/28361#issuecomment-3599315673
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2578999900

From pchilanomate at openjdk.org  Mon Dec  1 23:00:18 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 1 Dec 2025 23:00:18 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v7]
In-Reply-To: <6tlPVcUVZe08HkhCK5LeJ48-wmHb5YjA-Yf4H2NtQf8=.348b2255-44c9-4d43-8045-384b17b3a7d3@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <TrGjnbnsryaOcjBTDsAaFD5fZFjMNN0hoX0ARhwz-ME=.210bff76-1605-4e9a-8007-1861b5571894@github.com>
 <0e65HV5RscFZN_q4JGzXA7k5jlT7gw7klerMqbfz4GU=.598cedb2-fd53-458b-9047-4d712661cbe4@github.com>
 <zc0-WUDsL6ALYMT-NQD9hMHFy4ZRH6fq7Tr2sD2sK5g=.d15dc9c7-ed0d-4c2f-95c2-7ca0758fde0a@github.com>
 <r3l9SBPtgjuunDBP1ao1yUkNBZw2kfca5Nrn3QjiVHY=.2542c262-3bdf-471e-9dab-838b91c18590@github.com>
 <6tlPVcUVZe08HkhCK5LeJ48-wmHb5YjA-Yf4H2NtQf8=.348b2255-44c9-4d43-8045-384b17b3a7d3@github.com>
Message-ID: <JnAk8zCDMAcaBHJLI-TjP-BNUm36jvfOLOSujnac76A=.7e7d5000-db35-401a-b722-179945803027@github.com>

On Mon, 1 Dec 2025 18:52:37 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The one in `JavaThread` is needed for the `disable_transition_for_all` case. Processing each vthread is not viable, so we instead process all `JavaThreads`. If no `JavaThread` is in a transition then it implies no vthread is in a transition.
>
> So why do you need one in java_lang_Thread then?

It's needed for the `disable_transition_for_one` case. We only want to disable transitions for that particular vthread (yes, we could also disable transitions for all JavaThreads but that would be unnecessary).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2579002237

From vlivanov at openjdk.org  Mon Dec  1 23:29:03 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Mon, 1 Dec 2025 23:29:03 GMT
Subject: RFR: 8357258: x86: Improve receiver type profiling reliability
 [v6]
In-Reply-To: <2ifEaoGuZU4duyckWchgOnnqfH6AgAcrqsiqBZH1Nx4=.1df7af8d-41ac-43a1-90ab-964eb80f155b@github.com>
References: <X9RJoDWqk67MlK7P4ACCbzROxLkfEqvU0zDid3zymnc=.7c0086a3-f514-4b0d-8bc0-592bf4a05bba@github.com>
 <2ifEaoGuZU4duyckWchgOnnqfH6AgAcrqsiqBZH1Nx4=.1df7af8d-41ac-43a1-90ab-964eb80f155b@github.com>
Message-ID: <WiEfav8PY6QJYrVTlycVUzfyj_Vih8fzRAYwzXFKc1k=.41e6c7ab-f450-456d-a399-43e761e2b54a@github.com>

On Mon, 1 Dec 2025 13:04:08 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

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

src/hotspot/cpu/x86/macroAssembler_x86.cpp line 4826:

> 4824:   // and never duplicate the receivers in the list.
> 4825:   //
> 4826:   // It is tempting to combine these cases into a single loop, and claim the first

Can you elaborate, please, why it is the case? Is it a result of class unloading or something else?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25305#discussion_r2579069740

From liach at openjdk.org  Mon Dec  1 23:41:04 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 1 Dec 2025 23:41:04 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v3]
In-Reply-To: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
Message-ID: <eXO79ZBlZUltqddmReHLTSFSr3x8PiH0a5s740GHrfk=.5cf01f8f-7ac5-4def-b17d-dfd6f10e9614@github.com>

> 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:

  Tweak VH usage in some classes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28585/files
  - new: https://git.openjdk.org/jdk/pull/28585/files/886d3918..7bcdcbf3

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

  Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 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 liach at openjdk.org  Mon Dec  1 23:53:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 1 Dec 2025 23:53:46 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v3]
In-Reply-To: <eXO79ZBlZUltqddmReHLTSFSr3x8PiH0a5s740GHrfk=.5cf01f8f-7ac5-4def-b17d-dfd6f10e9614@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <eXO79ZBlZUltqddmReHLTSFSr3x8PiH0a5s740GHrfk=.5cf01f8f-7ac5-4def-b17d-dfd6f10e9614@github.com>
Message-ID: <Tnum5wwb64QCPnObV2Q6piqNRkTDHzWPrSGOp1MEsGE=.fcca1f2f-9fef-4039-ae0f-a6eb08a91685@github.com>

On Mon, 1 Dec 2025 23:41:04 GMT, Chen Liang <liach at openjdk.org> 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:
> 
>   Tweak VH usage in some classes

Since I removed the return type dropping VarHandle bypass, TestGetAndAdd became affected because it can no longer access the x86 assembly. Updated the Java calling convention to fix it.

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

PR Comment: https://git.openjdk.org/jdk/pull/28585#issuecomment-3599477724

From coleenp at openjdk.org  Tue Dec  2 00:10:26 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 2 Dec 2025 00:10:26 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v6]
In-Reply-To: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
Message-ID: <-KbUyaoVA5lXRBZmFQGTgeU9wtgLF4_qvR7vLHNkPzg=.e851e0f7-4b95-4a12-a5ce-a1d269ceafa5@github.com>

> ArrayKlass doesn't set AccessFlags so don't look for them there.  See CR for details.
> Fixed SA and jvmci.  @iwanowww Can you check that I changed C2 correctly (we talked about this in August).
> Tested with tier1-4.  5-7 in progress.

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

  Additional comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28371/files
  - new: https://git.openjdk.org/jdk/pull/28371/files/7f234078..8861381f

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

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

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

From vlivanov at openjdk.org  Tue Dec  2 00:25:49 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 2 Dec 2025 00:25:49 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v3]
In-Reply-To: <eXO79ZBlZUltqddmReHLTSFSr3x8PiH0a5s740GHrfk=.5cf01f8f-7ac5-4def-b17d-dfd6f10e9614@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <eXO79ZBlZUltqddmReHLTSFSr3x8PiH0a5s740GHrfk=.5cf01f8f-7ac5-4def-b17d-dfd6f10e9614@github.com>
Message-ID: <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com>

On Mon, 1 Dec 2025 23:41:04 GMT, Chen Liang <liach at openjdk.org> 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:
> 
>   Tweak VH usage in some classes

src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2033:

> 2031: 
> 2032:         @ForceInline
> 2033:         MethodHandle adaptedMethodHandle(VarHandle vh) {

Can you elaborate, please, how this method is intended to behave?

test/hotspot/jtreg/compiler/c2/irTests/TestGetAndAdd.java line 78:

> 76:     @IR(counts = {IRNode.X86_LOCK_XADDB, "3"}, phase = CompilePhase.FINAL_CODE)
> 77:     public static void addB() {
> 78:         var _ = (byte) B.getAndAdd(b2);

> Since I removed the return type dropping VarHandle bypass, TestGetAndAdd became affected because it can no longer access the x86 assembly. 

It has performance implications for user code, doesn't it?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2579149358
PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2579150006

From david.holmes at oracle.com  Tue Dec  2 00:37:45 2025
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 2 Dec 2025 10:37:45 +1000
Subject: Any reason why +PrintFlagsFinal requires unlocking experimental
 and diagnostic flags to print their default values?
In-Reply-To: <9b3db1fb-1d87-47fa-b6d6-d456a817146d@oracle.com>
References: <849ebf93-c3fb-45c9-92c8-21a49b3e9946@redhat.com>
 <5ff2a0a5-9d61-466d-9ada-5ba911185815@oracle.com>
 <CAA-vtUw=7=NQvzV1bP6AsCKsJruKZ4KvQaSimczD8NY-44X_=w@mail.gmail.com>
 <75d56d4d-6d4d-48c1-8d9d-86d92249346d@oracle.com>
 <e03864c5-1dc9-492a-89b5-146706cd2c4c@redhat.com>
 <40274532-c875-4339-81cf-00b4c0776536@oracle.com>
 <75941750-84ae-4ce7-8748-3dcac82d4628@redhat.com>
 <8cd2493e-6fdf-4399-934a-e74db442265f@oracle.com>
 <022ed95d-1aaf-492c-a874-a69544a2627a@redhat.com>
 <93ed9b47-f149-4d9f-8474-0956e5d39a1c@redhat.com>
 <9b3db1fb-1d87-47fa-b6d6-d456a817146d@oracle.com>
Message-ID: <081e6778-a809-4764-9806-3510c5635148@oracle.com>

On 2/12/2025 6:19 am, David Holmes wrote:
> On 1/12/2025 9:12 pm, Frederic Thevenet wrote:
>> PS: All that to say that, yes I think simply removing the 
>> `flagTable[i].is_unlocked()` check is quite possibly the way to go (I 
>> hit send too soon, sorry).
> 
> Sorry, I was overlooking all the other usecases. You are quite right 
> that I have reservations about changing some of those. So I stand by:
> 
>  > Well there is no obvious reason that these flags should differ in 
> what kind of flags they print
> 
> but withdraw the actual suggested fix.

But now I see the PR it seems not so bad after all.

David
> David
> -----
>> On 12/1/25 11:59, Frederic Thevenet wrote:
>>>
>>>
>>> On 12/1/25 11:17, David Holmes wrote:
>>>> On 1/12/2025 8:10 pm, Frederic Thevenet wrote:
>>>>>
>>>>>
>>>>> On 12/1/25 10:59, David Holmes wrote:
>>>>>> On 1/12/2025 7:41 pm, Frederic Thevenet wrote:
>>>>>>> Thanks for filling the bug, David; I've assigned it to myself and 
>>>>>>> will propose a PR for this shortly.
>>>>>>>
>>>>>>> Before I do, there's one point I feel might be worth clarifying 
>>>>>>> in this discussion first.
>>>>>>> In the current implementation, PrintFlagsFinal and 
>>>>>>> PrintFlagsRanges are quite tightly intertwined, as one acts as an 
>>>>>>> "upgrade" to the other (i.e. setting PrintFlagsRanges will 
>>>>>>> override PrintFlagsFinal).
>>>>>>> To me, it makes sense to change the behaviour for 
>>>>>>> PrintFlagsRanges to also print all flags if we do it for 
>>>>>>> PrintFlagsFinal, but I wanted to first ask if anyone sees a 
>>>>>>> reason not to do this?
>>>>>>
>>>>>> I think that makes sense. Though you can then extend the same 
>>>>>> logic to PrintFlagsInitial and even PrintFlagsWithComments, so the 
>>>>>> scope expands. If you just want to restrict the change to 
>>>>>> PrintFlagsFinal then I think the simplest thing is to just expand:
>>>>>>
>>>>>> void JVMFlag::printFlags(outputStream* out, bool withComments, 
>>>>>> bool printRanges, bool skipDefaults) {
>>>>>>
>>>>>> to
>>>>>>
>>>>>> void JVMFlag::printFlags(outputStream* out, bool withComments, 
>>>>>> bool printRanges, bool skipDefaults, bool printLocked) {
>>>>>>
>>>>>> and then have
>>>>>>
>>>>>> ? // All the flags that get adjusted by VM_Version_init and 
>>>>>> os::init_2
>>>>>> ? // have been set so dump the flags now.
>>>>>> ? if (PrintFlagsFinal || PrintFlagsRanges) {
>>>>>> ??? JVMFlag::printFlags(tty, false, PrintFlagsRanges, false, 
>>>>>> PrintFlagsFinal);
>>>>>> ? }
>>>>>
>>>>> With regard to PrintFlagsInitial or PrintFlagsWithComments, it 
>>>>> wasn't my primary goal to change these but I can certainly look 
>>>>> into it while I'm at it if there is a consensus that it is in fact 
>>>>> a good idea.
>>>>> Anyone care to? comment?
>>>>
>>>> Well there is no obvious reason that these flags should differ in 
>>>> what kind of flags they print - they only differ in what data gets 
>>>> printed for each flag.
>>>>
>>>> Maybe it is simpler and more consistent to just delete the
>>>>
>>>> ?flagTable[i].is_unlocked()
>>>>
>>>> check.
>>>
>>> Well yes indeed, but then aren't we right back at my initial 
>>> proposal, which we were worried might be too far-reaching? (Or maybe 
>>> it was just me who misunderstood your first answer?)
>>>
>>> Right now I can list 6 call sites for the underlying 
>>> JVMFlag::printFlags methods:
>>> - For handling PrintFlagsFinal and? PrintFlagsRanges in init.cpp [0]
>>> - For -XprintFlags in arguments.cpp [1]
>>> - For PrintFlagsInitial? in arguments.cpp [2]
>>> - For PrintFlagsWithComments in arguments.cpp [3]
>>> - For printing flags in hs_err reports in vmError.cpp [4]
>>> - For handling PrintVMFlagsDCmd in diagnosticCommand.cpp [5]
>>>
>>> As per our current discussion, we probably want the first fourto 
>>> exhibit the same behaviour, for the sake of coherency.
>>> Then, as mentioned before, I believe calling? JVMFlag::printFlags 
>>> with skipDefaults to true would not be affected by removing the 
>>> unlocked check at all (so printing flags in hs_err would not change).
>>> Finally, when it comes to the implementation of the PrintVMFlagsDCmd 
>>> diagnostic command, it already offers two modes controlled by the 
>>> consumer, one for only showing set flags and one for showing "all" 
>>> flags: I feel that also showing locked flags in this case would not 
>>> be a bad thing.
>>>
>>> [0] https://github.com/openjdk/jdk/ 
>>> blob/5bd7db034aaf8aa6780945e02a7f9a35e16b036e/src/hotspot/share/ 
>>> runtime/init.cpp#L210
>>> [1] https://github.com/openjdk/jdk/ 
>>> blob/5bd7db034aaf8aa6780945e02a7f9a35e16b036e/src/hotspot/share/ 
>>> runtime/arguments.cpp#L2528C18-L2528C19
>>> [2] https://github.com/openjdk/jdk/ 
>>> blob/5bd7db034aaf8aa6780945e02a7f9a35e16b036e/src/hotspot/share/ 
>>> runtime/arguments.cpp#L3467
>>> [3] https://github.com/openjdk/jdk/ 
>>> blob/5bd7db034aaf8aa6780945e02a7f9a35e16b036e/src/hotspot/share/ 
>>> runtime/arguments.cpp#L3473
>>> [4] https://github.com/openjdk/jdk/ 
>>> blob/5bd7db034aaf8aa6780945e02a7f9a35e16b036e/src/hotspot/share/ 
>>> utilities/vmError.cpp#L1277
>>> [5] https://github.com/openjdk/jdk/ 
>>> blob/5bd7db034aaf8aa6780945e02a7f9a35e16b036e/src/hotspot/share/ 
>>> services/diagnosticCommand.cpp#L256
>>>
>>>>
>>>> David
>>>>>>
>>>>>> David
>>>>>>> Cheers
>>>>>>> Frederic
>>>>>>>
>>>>>>> On 12/1/25 10:21, David Holmes wrote:
>>>>>>>> Okay I have filed:
>>>>>>>>
>>>>>>>> JDK-8372802: PrintFlagsFinal should also print locked flags
>>>>>>>>
>>>>>>>> but note there is no commitment for anyone to actually perform 
>>>>>>>> the work.
>>>>>>>>
>>>>>>>> David
>>>>>>>>
>>>>>>>> On 28/11/2025 3:19 pm, Thomas St?fe wrote:
>>>>>>>>> I am very much in favor of printing all flags, for the reasons 
>>>>>>>>> Frederic has given. When one supports many different releases, 
>>>>>>>>> it is a huge timesaver not to have to look up flags but see 
>>>>>>>>> them right there in the customer logs. The ability of 
>>>>>>>>> PrintFlagsFinal to give me all flags, including default values, 
>>>>>>>>> after they are resolved to their final values, is also very 
>>>>>>>>> useful during development.
>>>>>>>>>
>>>>>>>>> For simplicity, I would prefer just to change the behavior of 
>>>>>>>>> PrintFlagsFinal to do that, but I could live with a new 
>>>>>>>>> PrintAllFlagsFinal.
>>>>>>>>>
>>>>>>>>> Number of normal flags: 513, incl. diagnostic: 777, incl. 
>>>>>>>>> experimental&diagnostic: 933. (Jdk 25). So, it's?a bit more. I 
>>>>>>>>> am not bothered by this, since this list never fits onto a 
>>>>>>>>> single screen anyway. People grep. But if others prefer an 
>>>>>>>>> extra flag, sure, let's?have one.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Nov 27, 2025 at 3:05?AM David Holmes 
>>>>>>>>> <david.holmes at oracle.com <mailto:david.holmes at oracle.com>> wrote:
>>>>>>>>>
>>>>>>>>> ??? On 27/11/2025 12:53 am, Frederic Thevenet wrote:
>>>>>>>>> ???? > Hi,
>>>>>>>>> ???? >
>>>>>>>>> ???? > Currently, using +PrintFlagsFinal prints out all JVM 
>>>>>>>>> flags and their
>>>>>>>>> ???? > values, even if they were not modified from their 
>>>>>>>>> default, except
>>>>>>>>> ??? for
>>>>>>>>> ???? > 'locked' flags, i.e. Experimental and Diagnotic flags. 
>>>>>>>>> In order
>>>>>>>>> ??? to have
>>>>>>>>> ???? > those printed out as well, one must first 'unlock' them 
>>>>>>>>> (with
>>>>>>>>> ???? > +UnlockExperimentalVMOptions, for instance).
>>>>>>>>>
>>>>>>>>> ??? I think this was simply a pragmatic decision to avoid 
>>>>>>>>> overwhelming the
>>>>>>>>> ??? user with information that should not be relevant.
>>>>>>>>> ???? > Now, is their a strong reason for not always displaying 
>>>>>>>>> the default
>>>>>>>>> ???? > values for those in scenarios were there is no concerns 
>>>>>>>>> that the
>>>>>>>>> ??? output
>>>>>>>>> ???? > might be too large (that is when calling upon
>>>>>>>>> ??? 'JVMFlag::printFlags' with
>>>>>>>>> ???? > 'skipDefaults' set to false, like PrintFlagsFinal does)?
>>>>>>>>> ???? >
>>>>>>>>> ???? > The reason for this question is that when chasing a bug 
>>>>>>>>> in scenarios
>>>>>>>>> ???? > where one can only rely on logs or output provided by 
>>>>>>>>> tools that
>>>>>>>>> ??? uses
>>>>>>>>> ???? > +PrintFlagsFinal, getting the default values *in the 
>>>>>>>>> conditions that
>>>>>>>>> ???? > those logs where produced* can be tricky as it depends 
>>>>>>>>> on the exact
>>>>>>>>> ???? > version of the JDK that was running, and some values can be
>>>>>>>>> ??? changed by
>>>>>>>>> ???? > ergonomics.
>>>>>>>>>
>>>>>>>>> ??? Ouch. I think that would be a poor design choice for 
>>>>>>>>> diagnostic, and
>>>>>>>>> ??? especially experimental flags!
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Not every experimental/diagnostic flag is a boolean that 
>>>>>>>>> defaults to false and controls an opt-in feature. We have non- 
>>>>>>>>> boolean experimental flags and boolean flags that default to 
>>>>>>>>> true. It is not unthinkable that those are changed during VM 
>>>>>>>>> start.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ???? > If you need to know the default for experimental flags 
>>>>>>>>> -- which
>>>>>>>>> ??? given
>>>>>>>>> ???? > their nature can and do change often -- your choices are to
>>>>>>>>> ??? either ask
>>>>>>>>> ???? > for these logs to be generated again using
>>>>>>>>> ??? +UnlockExperimentalVMOptions
>>>>>>>>> ???? > (even if there is no intention of changing an 
>>>>>>>>> experimental flag)
>>>>>>>>> ??? or to
>>>>>>>>> ???? > go on a time consuming deep dive into the code base for 
>>>>>>>>> the exact
>>>>>>>>> ???? > version of the JDK that was used. Neither is ideal.
>>>>>>>>>
>>>>>>>>> ??? True, but for experimental flags in particular, unless you 
>>>>>>>>> are deep
>>>>>>>>> ??? diving into the code how can you know whether a particular 
>>>>>>>>> flag and its
>>>>>>>>> ??? value are relevant to your debugging in the first place?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I think the point here is reducing analyst strain. It's?not 
>>>>>>>>> that it is impossible to get the information otherwise, but 
>>>>>>>>> that it's?convenient and stress-reducing to have one sure way 
>>>>>>>>> to look up all resolved flag?values for a customer's JVM run. 
>>>>>>>>> Folks who have to work with many cases involving different JVM 
>>>>>>>>> versions would value this.
>>>>>>>>>
>>>>>>>>> BTW, we do print default values for non-experimental non- 
>>>>>>>>> diagnostic flags, too. The same reasoning applies here: if 
>>>>>>>>> its?not changed, you could look up the default value.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ??? That said, I don't see any harm in providing a way to print 
>>>>>>>>> all flags,
>>>>>>>>> ??? though whether by default or by a new - 
>>>>>>>>> XX:PrintAllFlagsFinal flag, I'm
>>>>>>>>> ??? not sure.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Wonderful, let's?do that then.
>>>>>>>>>
>>>>>>>>> Cheers, Thomas
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
> 


From liach at openjdk.org  Tue Dec  2 01:12:48 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 2 Dec 2025 01:12:48 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v3]
In-Reply-To: <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <eXO79ZBlZUltqddmReHLTSFSr3x8PiH0a5s740GHrfk=.5cf01f8f-7ac5-4def-b17d-dfd6f10e9614@github.com>
 <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com>
Message-ID: <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com>

On Tue, 2 Dec 2025 00:20:21 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Tweak VH usage in some classes
>
> src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2033:
> 
>> 2031: 
>> 2032:         @ForceInline
>> 2033:         MethodHandle adaptedMethodHandle(VarHandle vh) {
> 
> Can you elaborate, please, how this method is intended to behave?

When this is compiled, `constant` will become either `1` for constant VH and `2` for non-constant VH. So for constant VH, this becomes a stable read. For a non-constant VH, this becomes `getMethodHandle(mode).asType(...)`, equivalent to before.

> test/hotspot/jtreg/compiler/c2/irTests/TestGetAndAdd.java line 78:
> 
>> 76:     @IR(counts = {IRNode.X86_LOCK_XADDB, "3"}, phase = CompilePhase.FINAL_CODE)
>> 77:     public static void addB() {
>> 78:         var _ = (byte) B.getAndAdd(b2);
> 
>> Since I removed the return type dropping VarHandle bypass, TestGetAndAdd became affected because it can no longer access the x86 assembly. 
> 
> It has performance implications for user code, doesn't it?

The performance is measured by the existing `org.openjdk.bench.java.lang.invoke.VarHandleExact` benchmark, which originally expects  `generic_genericInvocation` to be much slower. Now it instead has a performance on par with the exact invocations.

The constant folding ability is verified with the new `VarHandleMismatchedTypeFold` IR test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2579218324
PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2579221253

From vlivanov at openjdk.org  Tue Dec  2 01:45:49 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 2 Dec 2025 01:45:49 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v3]
In-Reply-To: <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <eXO79ZBlZUltqddmReHLTSFSr3x8PiH0a5s740GHrfk=.5cf01f8f-7ac5-4def-b17d-dfd6f10e9614@github.com>
 <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com>
 <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com>
Message-ID: <M5yxETmdJBlueGf6KC7P8oSAZIEeiSu8rOHAoIxu0sc=.4bc347cb-40d5-4432-bc94-38a59730183d@github.com>

On Tue, 2 Dec 2025 01:08:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2033:
>> 
>>> 2031: 
>>> 2032:         @ForceInline
>>> 2033:         MethodHandle adaptedMethodHandle(VarHandle vh) {
>> 
>> Can you elaborate, please, how this method is intended to behave?
>
> When this is compiled, `constant` will become either `1` for constant VH and `2` for non-constant VH. So for constant VH, this becomes a stable read. For a non-constant VH, this becomes `getMethodHandle(mode).asType(...)`, equivalent to before.

What's the purpose of `constant == MethodHandleImpl.CONSTANT_YES ` and `constant != MethodHandleImpl.CONSTANT_NO` checks then?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2579287707

From liach at openjdk.org  Tue Dec  2 01:51:47 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 2 Dec 2025 01:51:47 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v3]
In-Reply-To: <M5yxETmdJBlueGf6KC7P8oSAZIEeiSu8rOHAoIxu0sc=.4bc347cb-40d5-4432-bc94-38a59730183d@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <eXO79ZBlZUltqddmReHLTSFSr3x8PiH0a5s740GHrfk=.5cf01f8f-7ac5-4def-b17d-dfd6f10e9614@github.com>
 <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com>
 <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com>
 <M5yxETmdJBlueGf6KC7P8oSAZIEeiSu8rOHAoIxu0sc=.4bc347cb-40d5-4432-bc94-38a59730183d@github.com>
Message-ID: <3OE37qXGHhLAhnRQM188hhygrLYBtI3FLBMK0tGVH30=.5d1b4406-3bb3-4788-8059-e78260b79ec1@github.com>

On Tue, 2 Dec 2025 01:42:50 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> When this is compiled, `constant` will become either `1` for constant VH and `2` for non-constant VH. So for constant VH, this becomes a stable read. For a non-constant VH, this becomes `getMethodHandle(mode).asType(...)`, equivalent to before.
>
> What's the purpose of `constant == MethodHandleImpl.CONSTANT_YES ` and `constant != MethodHandleImpl.CONSTANT_NO` checks then?

Indeed, I should move the adaptedMh read into `constant == MethodHandleImpl.CONSTANT_YES` block.

`constant != MethodHandleImpl.CONSTANT_NO` prevents capturing any further if the VH is known non-constant; we keep this branch in constant case in case the adapted MH is not ready when we know the VH is constant.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2579302480

From vlivanov at openjdk.org  Tue Dec  2 01:51:49 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 2 Dec 2025 01:51:49 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v3]
In-Reply-To: <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <eXO79ZBlZUltqddmReHLTSFSr3x8PiH0a5s740GHrfk=.5cf01f8f-7ac5-4def-b17d-dfd6f10e9614@github.com>
 <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com>
 <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com>
Message-ID: <md8aW5dsCzPJxZ760eXVV94a_7qCUaxg30cdSL1NXwc=.5c50d230-8e28-4cd5-99ea-0535125b69a9@github.com>

On Tue, 2 Dec 2025 01:09:59 GMT, Chen Liang <liach at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/c2/irTests/TestGetAndAdd.java line 78:
>> 
>>> 76:     @IR(counts = {IRNode.X86_LOCK_XADDB, "3"}, phase = CompilePhase.FINAL_CODE)
>>> 77:     public static void addB() {
>>> 78:         var _ = (byte) B.getAndAdd(b2);
>> 
>>> Since I removed the return type dropping VarHandle bypass, TestGetAndAdd became affected because it can no longer access the x86 assembly. 
>> 
>> It has performance implications for user code, doesn't it?
>
> The performance is measured by the existing `org.openjdk.bench.java.lang.invoke.VarHandleExact` benchmark, which originally expects  `generic_genericInvocation` to be much slower. Now it instead has a performance on par with the exact invocations.
> 
> The constant folding ability is verified with the new `VarHandleMismatchedTypeFold` IR test.

If I understand the IR test logic correctly, C2 was able to compile `(void) B.getAndAdd(b2)` call down to the desired instruction sequence. Is it still the case after the fix? What happens if you keep `TestGetAndAdd.java
` intact?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2579300293

From liach at openjdk.org  Tue Dec  2 01:54:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 2 Dec 2025 01:54:46 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v3]
In-Reply-To: <md8aW5dsCzPJxZ760eXVV94a_7qCUaxg30cdSL1NXwc=.5c50d230-8e28-4cd5-99ea-0535125b69a9@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <eXO79ZBlZUltqddmReHLTSFSr3x8PiH0a5s740GHrfk=.5cf01f8f-7ac5-4def-b17d-dfd6f10e9614@github.com>
 <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com>
 <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com>
 <md8aW5dsCzPJxZ760eXVV94a_7qCUaxg30cdSL1NXwc=.5c50d230-8e28-4cd5-99ea-0535125b69a9@github.com>
Message-ID: <fgtoQGIfonJ2W5J-7ogIne6Jw-RPmayKrvhAaxG4ngs=.60d371bd-e309-465b-89a4-4724e80295f8@github.com>

On Tue, 2 Dec 2025 01:48:13 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> The performance is measured by the existing `org.openjdk.bench.java.lang.invoke.VarHandleExact` benchmark, which originally expects  `generic_genericInvocation` to be much slower. Now it instead has a performance on par with the exact invocations.
>> 
>> The constant folding ability is verified with the new `VarHandleMismatchedTypeFold` IR test.
>
> If I understand the IR test logic correctly, C2 was able to compile `(void) B.getAndAdd(b2)` call down to the desired instruction sequence. Is it still the case after the fix? What happens if you keep `TestGetAndAdd.java
> ` intact?

No. The old code worked because it implicitly depended on the backdoor path present in the now removed `GUARD_METHOD_TEMPLATE_V` in `VarHandleGuardMethodGenerator`. If this test is intact, now its IR compiles to doing something in adaptedMethodHandle and calling a MethodHandle.  Not sure why it doesn't inline through that MethodHandle.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2579310315

From vlivanov at openjdk.org  Tue Dec  2 02:02:46 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 2 Dec 2025 02:02:46 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v3]
In-Reply-To: <3OE37qXGHhLAhnRQM188hhygrLYBtI3FLBMK0tGVH30=.5d1b4406-3bb3-4788-8059-e78260b79ec1@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <eXO79ZBlZUltqddmReHLTSFSr3x8PiH0a5s740GHrfk=.5cf01f8f-7ac5-4def-b17d-dfd6f10e9614@github.com>
 <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com>
 <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com>
 <M5yxETmdJBlueGf6KC7P8oSAZIEeiSu8rOHAoIxu0sc=.4bc347cb-40d5-4432-bc94-38a59730183d@github.com>
 <3OE37qXGHhLAhnRQM188hhygrLYBtI3FLBMK0tGVH30=.5d1b4406-3bb3-4788-8059-e78260b79ec1@github.com>
Message-ID: <kZDurlwNJsrYZRbeHLXVTKqUQcW2QGFGLE-WNN-vz4o=.44bc4d21-cc9d-4d94-b40c-4b6ad9ab11aa@github.com>

On Tue, 2 Dec 2025 01:49:04 GMT, Chen Liang <liach at openjdk.org> wrote:

>> What's the purpose of `constant == MethodHandleImpl.CONSTANT_YES ` and `constant != MethodHandleImpl.CONSTANT_NO` checks then?
>
> Indeed, I should move the adaptedMh read into `constant == MethodHandleImpl.CONSTANT_YES` block.
> 
> `constant != MethodHandleImpl.CONSTANT_NO` prevents capturing any further if the VH is known non-constant; we keep this branch in constant case in case the adapted MH is not ready when we know the VH is constant.

I still have a hard time reasoning about state transitions of the cache.

1) Why do you limit successful cache read (`cache != null`) to constant `vh` case (`constant == MethodHandleImpl.CONSTANT_YES`)?

2) Why do you avoid cache update in non-constant case (`constant != MethodHandleImpl.CONSTANT_NO`)? What happens if it runs compiled `adaptedMethodHandle` method?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2579329673

From vlivanov at openjdk.org  Tue Dec  2 02:08:44 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 2 Dec 2025 02:08:44 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v3]
In-Reply-To: <fgtoQGIfonJ2W5J-7ogIne6Jw-RPmayKrvhAaxG4ngs=.60d371bd-e309-465b-89a4-4724e80295f8@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <eXO79ZBlZUltqddmReHLTSFSr3x8PiH0a5s740GHrfk=.5cf01f8f-7ac5-4def-b17d-dfd6f10e9614@github.com>
 <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com>
 <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com>
 <md8aW5dsCzPJxZ760eXVV94a_7qCUaxg30cdSL1NXwc=.5c50d230-8e28-4cd5-99ea-0535125b69a9@github.com>
 <fgtoQGIfonJ2W5J-7ogIne6Jw-RPmayKrvhAaxG4ngs=.60d371bd-e309-465b-89a4-4724e80295f8@github.com>
Message-ID: <53uGo7JI87pm-cZmvxBiHniURB_bKryyfrWpewgZLP8=.bb97af75-8a6d-4aa8-8a90-e8c4cbc77ec8@github.com>

On Tue, 2 Dec 2025 01:52:04 GMT, Chen Liang <liach at openjdk.org> wrote:

>> If I understand the IR test logic correctly, C2 was able to compile `(void) B.getAndAdd(b2)` call down to the desired instruction sequence. Is it still the case after the fix? What happens if you keep `TestGetAndAdd.java
>> ` intact?
>
> No. The old code worked because it implicitly depended on the backdoor path present in the now removed `GUARD_METHOD_TEMPLATE_V` in `VarHandleGuardMethodGenerator`. If this test is intact, now its IR compiles to doing something in adaptedMethodHandle and calling a MethodHandle.  Not sure why it doesn't inline through that MethodHandle.

Ok, so you eliminated a fast-path check for void-return case and now JIT can't fully optimize it anymore. Do I get it right? Since this particular bytecode shape is exposed through public API, I don't see why user code can't step on it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2579341027

From liach at openjdk.org  Tue Dec  2 02:16:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 2 Dec 2025 02:16:52 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v3]
In-Reply-To: <kZDurlwNJsrYZRbeHLXVTKqUQcW2QGFGLE-WNN-vz4o=.44bc4d21-cc9d-4d94-b40c-4b6ad9ab11aa@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <eXO79ZBlZUltqddmReHLTSFSr3x8PiH0a5s740GHrfk=.5cf01f8f-7ac5-4def-b17d-dfd6f10e9614@github.com>
 <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com>
 <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com>
 <M5yxETmdJBlueGf6KC7P8oSAZIEeiSu8rOHAoIxu0sc=.4bc347cb-40d5-4432-bc94-38a59730183d@github.com>
 <3OE37qXGHhLAhnRQM188hhygrLYBtI3FLBMK0tGVH30=.5d1b4406-3bb3-4788-8059-e78260b79ec1@github.com>
 <kZDurlwNJsrYZRbeHLXVTKqUQcW2QGFGLE-WNN-vz4o=.44bc4d21-cc9d-4d94-b40c-4b6ad9ab11aa@github.com>
Message-ID: <7WF8DlorrU_B2__G2wr43w1PZwJh8mEhD5dY10YDIOo=.ec416c38-1aff-4dd6-8792-d6a0e01f91ce@github.com>

On Tue, 2 Dec 2025 02:00:08 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Indeed, I should move the adaptedMh read into `constant == MethodHandleImpl.CONSTANT_YES` block.
>> 
>> `constant != MethodHandleImpl.CONSTANT_NO` prevents capturing any further if the VH is known non-constant; we keep this branch in constant case in case the adapted MH is not ready when we know the VH is constant.
>
> I still have a hard time reasoning about state transitions of the cache.
> 
> 1) Why do you limit successful cache read (`cache != null`) to constant `vh` case (`constant == MethodHandleImpl.CONSTANT_YES`)?
> 
> 2) Why do you avoid cache update in non-constant case (`constant != MethodHandleImpl.CONSTANT_NO`)? What happens if it runs compiled `adaptedMethodHandle` method?

So an `AccessDescriptor` is created for each sigpoly VH site in the source code. Usually it is `VH.operation()`, but it is legal to use a non-constant VarHandle variable and call an operation on that. If `constant == MethodHandleImpl.CONSTANT_NO`, we are sure that we have the non-constant case, so we cannot trust that cached method handle, and there is no point further caching. We can only read that previous MH conversion cache if `constant == MethodHandleImpl.CONSTANT_YES` because this means our cache is always correct.

>> No. The old code worked because it implicitly depended on the backdoor path present in the now removed `GUARD_METHOD_TEMPLATE_V` in `VarHandleGuardMethodGenerator`. If this test is intact, now its IR compiles to doing something in adaptedMethodHandle and calling a MethodHandle.  Not sure why it doesn't inline through that MethodHandle.
>
> Ok, so you eliminated a fast-path check for void-return case and now JIT can't fully optimize it anymore. Do I get it right? Since this particular bytecode shape is exposed through public API, I don't see why user code can't step on it.

JIT can fully optimize it in JMH benchmarks. I don't know why the IR in this test can't optimize it - I couldn't reproduce this CI failure locally on my linux-x64-debug profile, but this modified test passes on CI.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2579352226
PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2579353722

From sspitsyn at openjdk.org  Tue Dec  2 02:17:51 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 2 Dec 2025 02:17:51 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v6]
In-Reply-To: <-KbUyaoVA5lXRBZmFQGTgeU9wtgLF4_qvR7vLHNkPzg=.e851e0f7-4b95-4a12-a5ce-a1d269ceafa5@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
 <-KbUyaoVA5lXRBZmFQGTgeU9wtgLF4_qvR7vLHNkPzg=.e851e0f7-4b95-4a12-a5ce-a1d269ceafa5@github.com>
Message-ID: <UJPTQn81pxsRiN-CA5K5paBh3VYdVppLFzuLDcHC0KU=.5a89e212-d9fc-4341-8f21-df6703e03881@github.com>

On Tue, 2 Dec 2025 00:10:26 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> ArrayKlass doesn't set AccessFlags so don't look for them there.  See CR for details.
>> Fixed SA and jvmci.  @iwanowww Can you check that I changed C2 correctly (we talked about this in August).
>> Tested with tier1-4.  5-7 in progress.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional comment

Looks good. Posted one nit comment though.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java line 67:

> 65:   public long     getAccessFlags()      { return            accessFlags.getValue(this);  }
> 66:   // Convenience routine
> 67:   public AccessFlags getAccessFlagsObj(){ return new AccessFlags(getAccessFlags());      }

Nit: The `getAccessFlags`, `getAccessFlagsObj` definitions and `accessFlags` initialization at line 101 are not aligned with other definitions/initializations. Also, there are unneeded spaces in definitions of `getAccessFlags`, `getAccessFlagsObj`.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28371#pullrequestreview-3527876434
PR Review Comment: https://git.openjdk.org/jdk/pull/28371#discussion_r2579353928

From vlivanov at openjdk.org  Tue Dec  2 02:32:47 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 2 Dec 2025 02:32:47 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v3]
In-Reply-To: <7WF8DlorrU_B2__G2wr43w1PZwJh8mEhD5dY10YDIOo=.ec416c38-1aff-4dd6-8792-d6a0e01f91ce@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <eXO79ZBlZUltqddmReHLTSFSr3x8PiH0a5s740GHrfk=.5cf01f8f-7ac5-4def-b17d-dfd6f10e9614@github.com>
 <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com>
 <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com>
 <M5yxETmdJBlueGf6KC7P8oSAZIEeiSu8rOHAoIxu0sc=.4bc347cb-40d5-4432-bc94-38a59730183d@github.com>
 <3OE37qXGHhLAhnRQM188hhygrLYBtI3FLBMK0tGVH30=.5d1b4406-3bb3-4788-8059-e78260b79ec1@github.com>
 <kZDurlwNJsrYZRbeHLXVTKqUQcW2QGFGLE-WNN-vz4o=.44bc4d21-cc9d-4d94-b40c-4b6ad9ab11aa@github.com>
 <7WF8DlorrU_B2__G2wr43w1PZwJh8mEhD5dY10YDIOo=.ec416c38-1aff-4dd6-8792-d6a0e01f91ce@github.com>
Message-ID: <E7Lwc7nwEvsmQhLMYT5Ruj5j7BhVDcfyBRUfhinUyzQ=.3293c6f1-6ce4-47d8-aa48-ba9c69ba60eb@github.com>

On Tue, 2 Dec 2025 02:13:15 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I still have a hard time reasoning about state transitions of the cache.
>> 
>> 1) Why do you limit successful cache read (`cache != null`) to constant `vh` case (`constant == MethodHandleImpl.CONSTANT_YES`)?
>> 
>> 2) Why do you avoid cache update in non-constant case (`constant != MethodHandleImpl.CONSTANT_NO`)? What happens if it runs compiled `adaptedMethodHandle` method?
>
> So an `AccessDescriptor` is created for each sigpoly VH site in the source code. Usually it is `VH.operation()`, but it is legal to use a non-constant VarHandle variable and call an operation on that. If `constant == MethodHandleImpl.CONSTANT_NO`, we are sure that we have the non-constant case, so we cannot trust that cached method handle, and there is no point further caching. We can only read that previous MH conversion cache if `constant == MethodHandleImpl.CONSTANT_YES` because this means our cache is always correct.

So, it seems like what you are trying to achieve is a 1-1 mapping from `AccessDescriptor` to `vh` through `adaptedMh`. So, once `cache != null` you can trust that it corresponds to the `vh` instance passed as a constant. But cache pollution can easily break the invariant, so you try to eliminate the pollution by avoiding cache updates when vh is not constant. Do I get it right?

>> Ok, so you eliminated a fast-path check for void-return case and now JIT can't fully optimize it anymore. Do I get it right? Since this particular bytecode shape is exposed through public API, I don't see why user code can't step on it.
>
> JIT can fully optimize it in JMH benchmarks. I don't know why the IR in this test can't optimize it - I couldn't reproduce this CI failure locally on my linux-x64-debug profile, but this modified test passes on CI.

I'd say it's a bad sign. Intermittent bugs manifest exactly in such a way.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2579374286
PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2579375565

From liach at openjdk.org  Tue Dec  2 02:54:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 2 Dec 2025 02:54:46 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v3]
In-Reply-To: <E7Lwc7nwEvsmQhLMYT5Ruj5j7BhVDcfyBRUfhinUyzQ=.3293c6f1-6ce4-47d8-aa48-ba9c69ba60eb@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <eXO79ZBlZUltqddmReHLTSFSr3x8PiH0a5s740GHrfk=.5cf01f8f-7ac5-4def-b17d-dfd6f10e9614@github.com>
 <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com>
 <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com>
 <M5yxETmdJBlueGf6KC7P8oSAZIEeiSu8rOHAoIxu0sc=.4bc347cb-40d5-4432-bc94-38a59730183d@github.com>
 <3OE37qXGHhLAhnRQM188hhygrLYBtI3FLBMK0tGVH30=.5d1b4406-3bb3-4788-8059-e78260b79ec1@github.com>
 <kZDurlwNJsrYZRbeHLXVTKqUQcW2QGFGLE-WNN-vz4o=.44bc4d21-cc9d-4d94-b40c-4b6ad9ab11aa@github.com>
 <7WF8DlorrU_B2__G2wr43w1PZwJh8mEhD5dY10YDIOo=.ec416c38-1aff-4dd6-8792-d6a0e01f91ce@github.com>
 <E7Lwc7nwEvsmQhLMYT5Ruj5j7BhVDcfyBRUfhinUyzQ=.3293c6f1-6ce4-47d8-aa48-ba9c69ba60eb@github.com>
Message-ID: <ogD0Gl3QSb1pLJUqOn877wI6asY5TW0MV7mPFlNXM5A=.8af15b77-010a-4d34-901b-928c4a3fe425@github.com>

On Tue, 2 Dec 2025 02:29:28 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> So an `AccessDescriptor` is created for each sigpoly VH site in the source code. Usually it is `VH.operation()`, but it is legal to use a non-constant VarHandle variable and call an operation on that. If `constant == MethodHandleImpl.CONSTANT_NO`, we are sure that we have the non-constant case, so we cannot trust that cached method handle, and there is no point further caching. We can only read that previous MH conversion cache if `constant == MethodHandleImpl.CONSTANT_YES` because this means our cache is always correct.
>
> So, it seems like what you are trying to achieve is a 1-1 mapping from `AccessDescriptor` to `vh` through `adaptedMh`. So, once `cache != null` you can trust that it corresponds to the `vh` instance passed as a constant. But cache pollution can easily break the invariant, so you try to eliminate the pollution by avoiding cache updates when vh is not constant. Do I get it right?

No. The avoidance of cache update simply trims down the generated code by throwing away the meaningless cache update.

The access to cache is already safeguarded by `constant == MethodHandleImpl.CONSTANT_YES`. I should have moved `var cache = adaptedMh;` into the if block of `constant == CONSTANT_YES`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2579405388

From dlong at openjdk.org  Tue Dec  2 04:47:51 2025
From: dlong at openjdk.org (Dean Long)
Date: Tue, 2 Dec 2025 04:47:51 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v5]
In-Reply-To: <a8nKroSMQd0Yd1Ct5tziN8kHUCP7MLU-66zv7qEhHXU=.65f6307b-7384-4c61-9454-c40f558bdc6e@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
 <r4etVDZnERk-bUlx-6uMtxP03xvMa0a51MnBlA7eIz0=.4e16178f-517a-400e-a7bf-0a890664aa2c@github.com>
 <TJz-eWoBprBpWz3VatBM8plPWPDaEaFG46ymLDw9onM=.b638c178-a224-41c0-9861-beb403e7660f@github.com>
 <a8nKroSMQd0Yd1Ct5tziN8kHUCP7MLU-66zv7qEhHXU=.65f6307b-7384-4c61-9454-c40f558bdc6e@github.com>
Message-ID: <EwZ9R5afHHB6NGVbKNQqUwu4VQR2SphDB9hZXYrMigI=.dcc5b892-dcb4-4c34-a17d-0c30802c4dff@github.com>

On Mon, 1 Dec 2025 22:53:36 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/opto/library_call.cpp line 4104:
>> 
>>> 4102:       phi->add_req(makecon(TypeInstPtr::make(env()->Object_klass()->java_mirror())));
>>> 4103:     }
>>> 4104:     // Check for interface after array since this checks AccessFlags offset into InstanceKlass.
>> 
>> In other words, we are accessing subtype-specific information, so we need to determine the subtype first.
>
> I can add this to the comment if you think it's helpful.

Yes, please.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28371#discussion_r2579562880

From dlong at openjdk.org  Tue Dec  2 04:55:50 2025
From: dlong at openjdk.org (Dean Long)
Date: Tue, 2 Dec 2025 04:55:50 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v5]
In-Reply-To: <tV6l3dprgBtqwSlAYCnAa6TDSh6gR6I3W79Qu2ULyWE=.08fb705d-d380-4523-9b52-96cad877e8b8@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
 <r4etVDZnERk-bUlx-6uMtxP03xvMa0a51MnBlA7eIz0=.4e16178f-517a-400e-a7bf-0a890664aa2c@github.com>
 <9COxlPt9xc7_2hrMumCuZ1wVuSvLPJCHn16RKEFoPu0=.cb81a68a-c100-44a4-8542-b2121c544f96@github.com>
 <tV6l3dprgBtqwSlAYCnAa6TDSh6gR6I3W79Qu2ULyWE=.08fb705d-d380-4523-9b52-96cad877e8b8@github.com>
Message-ID: <41lDi_gRckFIB_TJ2FJb6HdB_vc2_0Jj0WKsLfTyLGY=.e8ed7a8f-df9a-48c1-abba-e25fdcb3c333@github.com>

On Mon, 1 Dec 2025 22:48:05 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/oops/instanceKlass.hpp line 237:
>> 
>>> 235: 
>>> 236:   // State is set either at parse time or while executing, atomically to not disturb other state
>>> 237:   InstanceKlassFlags _misc_flags;
>> 
>> It looks like the size of these 3 fields, _reference_type, _access_flags, and _misc_flags, will take 8 bytes because of alignment/padding, but if _reference_type was moved to the end of InstanceKlassFlags and the order reversed, it could be reduced to 6 bytes, leaving 2 for future expansion:
>> 
>> InstanceKlassFlags _misc_flags; // contains _reference_type
>> AccessFlags        _access_flags;
>> char _reserved[2];
>
> ClassState is a u1 so that fills the u2 gap with reference_type.  So I don't think moving reference type will help.

You're right, I missed that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28371#discussion_r2579576187

From dlong at openjdk.org  Tue Dec  2 05:35:50 2025
From: dlong at openjdk.org (Dean Long)
Date: Tue, 2 Dec 2025 05:35:50 GMT
Subject: RFR: 8347396: Efficient TypeFunc creations [v2]
In-Reply-To: <EhBN8Seh-3zZYlkNrzfhU4Kp1TgljHiRQU_SQwWLtAs=.8a8945e0-7554-4aa4-b85e-ed2ad4dac1de@github.com>
References: <VQs3SMtk1y6xTi8nCvTeWsTFfCQlTJtDdCGnfWQmRmw=.f3b33ba1-3efe-477b-b6d2-b43faae9ee2b@github.com>
 <EhBN8Seh-3zZYlkNrzfhU4Kp1TgljHiRQU_SQwWLtAs=.8a8945e0-7554-4aa4-b85e-ed2ad4dac1de@github.com>
Message-ID: <MPIV8FA7KhDVrZliHRl7gGlqb1JiP_2BsqBszRaLaqU=.8058e027-8a06-4e60-82d9-6516768d40c2@github.com>

On Mon, 27 Oct 2025 05:11:47 GMT, Harshit470250 <duke at openjdk.org> 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 with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge master
>  - update make_barrier_type
>  - Merge branch 'openjdk:master' into new_pr
>  - Merge branch 'openjdk:master' into new_pr
>  - My chages

Yes, bring it over, as it's an improvement.  However, I was wondering if there was a way we can get rid of the remaining `#if INCLUDE_SHENANDOAHGC` in shared c2 code.  The first idea that I came up with is for the GC init to reference a callback function for C2, but I'm not sure if the complexity is worth it.

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

PR Comment: https://git.openjdk.org/jdk/pull/27279#issuecomment-3600260250

From dholmes at openjdk.org  Tue Dec  2 06:24:07 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 2 Dec 2025 06:24:07 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v10]
In-Reply-To: <T8jvz_3r2GJ8W55gqHXsRkNhMPRy3hLGF7ClwP84CM0=.c69c727e-6628-4aa2-92ca-e596542cf0e0@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <T8jvz_3r2GJ8W55gqHXsRkNhMPRy3hLGF7ClwP84CM0=.c69c727e-6628-4aa2-92ca-e596542cf0e0@github.com>
Message-ID: <U0XMaJ4ujyejqeQTvz4l7ZwUf2IWRPWKZj3ptQMSOBs=.5ec74fa7-bff5-4220-9916-02209c34dbc9@github.com>

On Mon, 1 Dec 2025 23:00:16 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> 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 incrementally with one additional commit since the last revision:
> 
>   Fix comment in inline_native_vthread_start_transition

Nothing further from me. Again a great piece of work!

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28361#pullrequestreview-3528335950

From hgreule at openjdk.org  Tue Dec  2 07:54:01 2025
From: hgreule at openjdk.org (Hannes Greule)
Date: Tue, 2 Dec 2025 07:54:01 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v3]
In-Reply-To: <E7Lwc7nwEvsmQhLMYT5Ruj5j7BhVDcfyBRUfhinUyzQ=.3293c6f1-6ce4-47d8-aa48-ba9c69ba60eb@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <eXO79ZBlZUltqddmReHLTSFSr3x8PiH0a5s740GHrfk=.5cf01f8f-7ac5-4def-b17d-dfd6f10e9614@github.com>
 <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com>
 <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com>
 <M5yxETmdJBlueGf6KC7P8oSAZIEeiSu8rOHAoIxu0sc=.4bc347cb-40d5-4432-bc94-38a59730183d@github.com>
 <3OE37qXGHhLAhnRQM188hhygrLYBtI3FLBMK0tGVH30=.5d1b4406-3bb3-4788-8059-e78260b79ec1@github.com>
 <kZDurlwNJsrYZRbeHLXVTKqUQcW2QGFGLE-WNN-vz4o=.44bc4d21-cc9d-4d94-b40c-4b6ad9ab11aa@github.com>
 <7WF8DlorrU_B2__G2wr43w1PZwJh8mEhD5dY10YDIOo=.ec416c38-1aff-4dd6-8792-d6a0e01f91ce@github.com>
 <E7Lwc7nwEvsmQhLMYT5Ruj5j7BhVDcfyBRUfhinUyzQ=.3293c6f1-6ce4-47d8-aa48-ba9c69ba60eb@github.com>
Message-ID: <h9TWgUQYIzCPvUMlvtKqQk_PpS_rAbHzWWdZWgS9q94=.65e2745e-3a6f-4364-81db-21e7acfe1615@github.com>

On Tue, 2 Dec 2025 02:30:28 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> JIT can fully optimize it in JMH benchmarks. I don't know why the IR in this test can't optimize it - I couldn't reproduce this CI failure locally on my linux-x64-debug profile, but this modified test passes on CI.
>
> I'd say it's a bad sign. Intermittent bugs manifest exactly in such a way.

> The performance is measured by the existing `org.openjdk.bench.java.lang.invoke.VarHandleExact` benchmark, which originally expects `generic_genericInvocation` to be much slower. Now it instead has a performance on par with the exact invocations.
> 
> The constant folding ability is verified with the new `VarHandleMismatchedTypeFold` IR test.

The benchmark doesn't consider such inexact getAndAdd calls (with a void return type), I think it should cover that too. This is a very common pattern that really must not regress.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2580041626

From sspitsyn at openjdk.org  Tue Dec  2 08:21:57 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 2 Dec 2025 08:21:57 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v10]
In-Reply-To: <T8jvz_3r2GJ8W55gqHXsRkNhMPRy3hLGF7ClwP84CM0=.c69c727e-6628-4aa2-92ca-e596542cf0e0@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <T8jvz_3r2GJ8W55gqHXsRkNhMPRy3hLGF7ClwP84CM0=.c69c727e-6628-4aa2-92ca-e596542cf0e0@github.com>
Message-ID: <P9Too5Wi39kpbuKEdC6zi1AaV_gEdwV769JRMtd2Fz8=.10605426-19ce-45cc-a9de-47aaea2b118e@github.com>

On Mon, 1 Dec 2025 23:00:16 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> 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 incrementally with one additional commit since the last revision:
> 
>   Fix comment in inline_native_vthread_start_transition

src/hotspot/share/runtime/mountUnmountDisabler.cpp line 88:

> 86:         // We rebinded on start_transition but the mount/unmount operation
> 87:         // failed so now we need to rebind to the original state.
> 88:         _current->rebind_to_jvmti_thread_state_of(_is_mount ? _vthread() : _current->threadObj());

Q: Not sure I fully understand this comment. We have done a rebind at the line 67 for an unmount transition only. But this comment tells that it was done for mount transition as well. Also, before this update, we used to do a rebind of `JvmtiThreadState` to a vthread in the `JvmtiVTMSTransitionDisabler::VTMS_mount_end()` for the normal (not failed) case. Please, could you explain a little bit more? It feels like this comment needs a correction.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2580118016

From shade at openjdk.org  Tue Dec  2 08:47:02 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 2 Dec 2025 08:47:02 GMT
Subject: RFR: 8357258: x86: Improve receiver type profiling reliability
 [v6]
In-Reply-To: <WiEfav8PY6QJYrVTlycVUzfyj_Vih8fzRAYwzXFKc1k=.41e6c7ab-f450-456d-a399-43e761e2b54a@github.com>
References: <X9RJoDWqk67MlK7P4ACCbzROxLkfEqvU0zDid3zymnc=.7c0086a3-f514-4b0d-8bc0-592bf4a05bba@github.com>
 <2ifEaoGuZU4duyckWchgOnnqfH6AgAcrqsiqBZH1Nx4=.1df7af8d-41ac-43a1-90ab-964eb80f155b@github.com>
 <WiEfav8PY6QJYrVTlycVUzfyj_Vih8fzRAYwzXFKc1k=.41e6c7ab-f450-456d-a399-43e761e2b54a@github.com>
Message-ID: <GyWbLm8LrKYchz3nz5mYAsoPen3gbiVxnOBjjWammmc=.661fb033-5a5b-46cb-91f2-ae473a6ba27b@github.com>

On Mon, 1 Dec 2025 23:25:42 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - 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
>
> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 4826:
> 
>> 4824:   // and never duplicate the receivers in the list.
>> 4825:   //
>> 4826:   // It is tempting to combine these cases into a single loop, and claim the first
> 
> Can you elaborate, please, why it is the case? Is it a result of class unloading or something else?

Yes, we are clearing MDOs for unloaded classes. 

I initially thought this kind of cleanup happens only during `ciReceiverTypeData::translate_receiver_data_from` translation to `ciReceiverTypeData`. If that was the only path, we would probably not care about this; although I would, for defensive programming reasons. *But* it looks like the cleanup happens during "normal" GC class unloading, which also makes sense: you do not want to have unloaded classes referenced from any runtime datastructure, including MDO.

The path I saw was:


ReceiverTypeData::clear_row
ReceiverTypeData::clean_weak_klass_links
MethodData::clean_method_data
InstanceKlass::clean_method_data
InstanceKlass::clean_weak_instanceklass_links
Klass::clean_weak_instanceklass_links
KlassCleaningTask::work 
<this is GC class unloading work>

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25305#discussion_r2580205471

From mhaessig at openjdk.org  Tue Dec  2 08:52:45 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Tue, 2 Dec 2025 08:52:45 GMT
Subject: RFR: 8370519: C2: Hit MemLimit when running with
 +VerifyLoopOptimizations
In-Reply-To: <W7EnT28-84mtwppISdr_ydCV9HSaXk72y7fyd29z4wQ=.7331c81d-c36f-4a1c-b949-e7045f524d07@github.com>
References: <W7EnT28-84mtwppISdr_ydCV9HSaXk72y7fyd29z4wQ=.7331c81d-c36f-4a1c-b949-e7045f524d07@github.com>
Message-ID: <yNRU-YI2kiZzLMZNNzWusAgr0bHUmTppP8T73gBojd0=.73b7e37a-2966-43f2-baea-e38a9596667e@github.com>

On Mon, 1 Dec 2025 15:40:00 GMT, Roland Westrelin <roland at openjdk.org> 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
>         ctorChaitin                  160032    ...

Fwiw, testing passed up to tier3 on linux-x64, linux-aarch64, macosx-aarch64, mac-x64, windows-x64.

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

PR Comment: https://git.openjdk.org/jdk/pull/28581#issuecomment-3600902694

From pminborg at openjdk.org  Tue Dec  2 09:04:53 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 2 Dec 2025 09:04:53 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v3]
In-Reply-To: <eXO79ZBlZUltqddmReHLTSFSr3x8PiH0a5s740GHrfk=.5cf01f8f-7ac5-4def-b17d-dfd6f10e9614@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <eXO79ZBlZUltqddmReHLTSFSr3x8PiH0a5s740GHrfk=.5cf01f8f-7ac5-4def-b17d-dfd6f10e9614@github.com>
Message-ID: <q-iSEfoPEYziWA2ga6FAG5g3H8vYn_tTPHKSCJDnsf8=.c7af744c-e435-402b-8ba2-221b351c0444@github.com>

On Mon, 1 Dec 2025 23:41:04 GMT, Chen Liang <liach at openjdk.org> 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:
> 
>   Tweak VH usage in some classes

src/hotspot/share/opto/library_call.cpp line 8926:

> 8924: bool LibraryCallKit::inline_isCompileConstant() {
> 8925:   Node* n = argument(0);
> 8926:   set_result(n->is_Con() ? intcon(1) : intcon(2));

Can we get constants for these magic numbers on the C side as well?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2580266341

From roland at openjdk.org  Tue Dec  2 09:20:41 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Tue, 2 Dec 2025 09:20:41 GMT
Subject: RFR: 8354282: C2: more crashes in compiled code because of
 dependency on removed range check CastIIs [v8]
In-Reply-To: <qos-VYvgreqGsB7ke35RmM3L9uHnnM6nUsm2QONKXc4=.9c902d61-5f45-41f5-8276-ac28830c2bf5@github.com>
References: <qos-VYvgreqGsB7ke35RmM3L9uHnnM6nUsm2QONKXc4=.9c902d61-5f45-41f5-8276-ac28830c2bf5@github.com>
Message-ID: <qab0P8PMsV9UzIT8JqUuAixFJbzNkpjd_FCSDnVB49U=.f52c826c-480f-4330-ba68-01b22f21b044@github.com>

> This is a variant of 8332827. In 8332827, an array access becomes
> dependent on a range check `CastII` for another array access. When,
> after loop opts are over, that RC `CastII` was removed, the array
> access could float and an out of bound access happened. With the fix
> for 8332827, RC `CastII`s are no longer removed.
> 
> With this one what happens is that some transformations applied after
> loop opts are over widen the type of the RC `CastII`. As a result, the
> type of the RC `CastII` is no longer narrower than that of its input,
> the `CastII` is removed and the dependency is lost.
> 
> There are 2 transformations that cause this to happen:
> 
> - after loop opts are over, the type of the `CastII` nodes are widen
>   so nodes that have the same inputs but a slightly different type can
>   common.
>   
> - When pushing a `CastII` through an `Add`, if of the type both inputs
>   of the `Add`s are non constant, then we end up widening the type
>   (the resulting `Add` has a type that's wider than that of the
>   initial `CastII`).
>   
> There are already 3 types of `Cast` nodes depending on the
> optimizations that are allowed. Either the `Cast` is floating
> (`depends_only_test()` returns `true`) or pinned. Either the `Cast`
> can be removed if it no longer narrows the type of its input or
> not. We already have variants of the `CastII`:
> 
> - if the Cast can float and be removed when it doesn't narrow the type
> of its input.
> 
> - if the Cast is pinned and be removed when it doesn't narrow the type
> of its input.
> 
> - if the Cast is pinned and can't be removed when it doesn't narrow
> the type of its input.
> 
> What we need here, I think, is the 4th combination:
> 
> - if the Cast can float and can't be removed when it doesn't narrow
> the type of its input.
> 
> Anyway, things are becoming confusing with all these different
> variants named in ways that don't always help figure out what
> constraints one of them operate under. So I refactored this and that's
> the biggest part of this change. The fix consists in marking `Cast`
> nodes when their type is widen in a way that prevents them from being
> optimized out.
> 
> Tobias ran performance testing with a slightly different version of
> this change and there was no regression.

Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:

 - Merge branch 'master' into JDK-8354282
 - whitespace
 - review
 - review
 - Update src/hotspot/share/opto/castnode.cpp
   
   Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
 - Update src/hotspot/share/opto/castnode.cpp
   
   Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
 - Update src/hotspot/share/opto/castnode.cpp
   
   Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
 - Update test/hotspot/jtreg/compiler/c2/irTests/TestPushAddThruCast.java
   
   Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
 - review
 - review
 - ... and 7 more: https://git.openjdk.org/jdk/compare/ef5e744a...93b8b0c5

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

Changes: https://git.openjdk.org/jdk/pull/24575/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24575&range=07
  Stats: 365 lines in 13 files changed: 264 ins; 27 del; 74 mod
  Patch: https://git.openjdk.org/jdk/pull/24575.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24575/head:pull/24575

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

From pminborg at openjdk.org  Tue Dec  2 09:31:03 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 2 Dec 2025 09:31:03 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v3]
In-Reply-To: <eXO79ZBlZUltqddmReHLTSFSr3x8PiH0a5s740GHrfk=.5cf01f8f-7ac5-4def-b17d-dfd6f10e9614@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <eXO79ZBlZUltqddmReHLTSFSr3x8PiH0a5s740GHrfk=.5cf01f8f-7ac5-4def-b17d-dfd6f10e9614@github.com>
Message-ID: <hzq42574wKnkKeZcBGJ-aOSY5hVrpoUKM8t25GMibxg=.b7728079-a9f7-4b35-8150-a94110d8e698@github.com>

On Mon, 1 Dec 2025 23:41:04 GMT, Chen Liang <liach at openjdk.org> 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:
> 
>   Tweak VH usage in some classes

src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2036:

> 2034:             var constant = MethodHandleImpl.isCompileConstant(vh);
> 2035:             var cache = adaptedMh;
> 2036:             if (constant == MethodHandleImpl.CONSTANT_YES && cache != null) {

Rookie question: Is there multi-thread considerations here? How about visibility across threads?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2580353068

From dholmes at openjdk.org  Tue Dec  2 09:34:14 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 2 Dec 2025 09:34:14 GMT
Subject: RFR: 8372615: Many container tests fail when running rootless on
 cgroup v1 [v2]
In-Reply-To: <pEceZpCbgMCqwPQoKiGcLgFlv-UpLg5Rv4PcHclFRKQ=.822a2343-fe24-4384-9214-f88c80a103a0@github.com>
References: <vMiWENH7dMmRw5miQHPYNnETLlwMgklDZyGxk_JCPu4=.a98f9e35-3bb4-4aaf-b89b-a2547c4e6f29@github.com>
 <pEceZpCbgMCqwPQoKiGcLgFlv-UpLg5Rv4PcHclFRKQ=.822a2343-fe24-4384-9214-f88c80a103a0@github.com>
Message-ID: <SvNSsJ64K8NIilNRs9MS6IWcc4ExSDtM6QJzJ37MzF4=.f08fd1b8-d844-48ec-9426-13c8b08e1dc8@github.com>

On Mon, 1 Dec 2025 12:45:06 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> Many container tests verify that various resource limits work as expected. However, when running containers in rootless mode on both Docker and Podman with cgroup v1, resource limits are not supported. This causes tests to fail with error messages like: `Resource limits are not supported and ignored on cgroups V1 rootless systems`.
>> 
>> To address this, we should skip these tests when running on configurations that don't support resource limits, similar to how we already handle other unsupported configurations (e.g., missing container engine or incompatibility with a specific cgroup version or container runtime).
>> 
>> To check for this, we now need to use `Metrics.systemMetrics().getProvider()` from `jdk.internal.platform.Metrics` to detect cgroup v1. I've added this functionality to `DockerTestUtils`, which is already used by all container tests. As a result, all container tests now need to include the `java.base/jdk.internal.platform` module, even if they don't directly test resource limits.
>> 
>> Testing:
>> * Oracle tiers 1-5
>> * Local testing:
>>   - `hotspot/jtreg/containers/` 
>>   - `jdk/jdk/internal/platform/docker/`
>> on cgroup v1/v2 with Podman and Docker in both rootful and rootless configurations
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reworked check docker/resourcelimit functions

Thanks for the updates. Seems reasonable.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28557#pullrequestreview-3529119616

From shade at openjdk.org  Tue Dec  2 09:43:17 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 2 Dec 2025 09:43:17 GMT
Subject: RFR: 8357258: x86: Improve receiver type profiling reliability
 [v7]
In-Reply-To: <X9RJoDWqk67MlK7P4ACCbzROxLkfEqvU0zDid3zymnc=.7c0086a3-f514-4b0d-8bc0-592bf4a05bba@github.com>
References: <X9RJoDWqk67MlK7P4ACCbzROxLkfEqvU0zDid3zymnc=.7c0086a3-f514-4b0d-8bc0-592bf4a05bba@github.com>
Message-ID: <egxL_-YRpg7Quvs6lMTOyafAqXEAUa78NV9Oc1F1zAY=.42c8a1d7-bdfb-438f-aaa3-bd2f5867e334@github.com>

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

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

 - More comments
 - Tighten up the comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25305/files
  - new: https://git.openjdk.org/jdk/pull/25305/files/f3e0fa4d..39cc4dfe

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

  Stats: 13 lines in 1 file changed: 2 ins; 0 del; 11 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 shade at openjdk.org  Tue Dec  2 09:43:19 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 2 Dec 2025 09:43:19 GMT
Subject: RFR: 8357258: x86: Improve receiver type profiling reliability
 [v6]
In-Reply-To: <GyWbLm8LrKYchz3nz5mYAsoPen3gbiVxnOBjjWammmc=.661fb033-5a5b-46cb-91f2-ae473a6ba27b@github.com>
References: <X9RJoDWqk67MlK7P4ACCbzROxLkfEqvU0zDid3zymnc=.7c0086a3-f514-4b0d-8bc0-592bf4a05bba@github.com>
 <2ifEaoGuZU4duyckWchgOnnqfH6AgAcrqsiqBZH1Nx4=.1df7af8d-41ac-43a1-90ab-964eb80f155b@github.com>
 <WiEfav8PY6QJYrVTlycVUzfyj_Vih8fzRAYwzXFKc1k=.41e6c7ab-f450-456d-a399-43e761e2b54a@github.com>
 <GyWbLm8LrKYchz3nz5mYAsoPen3gbiVxnOBjjWammmc=.661fb033-5a5b-46cb-91f2-ae473a6ba27b@github.com>
Message-ID: <xJ1WIQ3aC0FhC-Fcy3QOebNj3TIRZAmdDky9PdtONEo=.43c41b1f-e123-4e62-bbab-b52a47a74dbc@github.com>

On Tue, 2 Dec 2025 08:44:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 4826:
>> 
>>> 4824:   // and never duplicate the receivers in the list.
>>> 4825:   //
>>> 4826:   // It is tempting to combine these cases into a single loop, and claim the first
>> 
>> Can you elaborate, please, why it is the case? Is it a result of class unloading or something else?
>
> Yes, we are clearing MDOs for unloaded classes. 
> 
> I initially thought this kind of cleanup happens only during `ciReceiverTypeData::translate_receiver_data_from` translation to `ciReceiverTypeData`. If that was the only path, we would probably not care about this; although I would, for defensive programming reasons. *But* it looks like the cleanup happens during "normal" GC class unloading, which also makes sense: you do not want to have unloaded classes referenced from any runtime datastructure, including MDO. So this forces our hand to deal with empty slots. Old code also did this, AFAICS: it scanned everything at least once.
> 
> The path to receiver cleanup I saw in the code was:
> 
> 
> ReceiverTypeData::clear_row
> ReceiverTypeData::clean_weak_klass_links
> MethodData::clean_method_data
> InstanceKlass::clean_method_data
> InstanceKlass::clean_weak_instanceklass_links
> Klass::clean_weak_instanceklass_links
> KlassCleaningTask::work 
> <this is GC class unloading work>

I tightened up the comments a bit to mention that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25305#discussion_r2580384110

From roland at openjdk.org  Tue Dec  2 09:49:29 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Tue, 2 Dec 2025 09:49:29 GMT
Subject: RFR: 8351889: C2 crash: assertion failed:  Base pointers must
 match (addp 344) [v4]
In-Reply-To: <IKOYjLXrS8q1GMjbaL2HOBNH8Oa_16k4WBa2NaMngS8=.c6fd7fbb-4758-48b2-a992-3702b2718e59@github.com>
References: <IKOYjLXrS8q1GMjbaL2HOBNH8Oa_16k4WBa2NaMngS8=.c6fd7fbb-4758-48b2-a992-3702b2718e59@github.com>
Message-ID: <w-yCuouqlwsCiBjv5stRarSJwFeRhqRrfKT9zC0lUuk=.f782fb00-4c68-4305-ae38-1a1b1cf62108@github.com>

> The test case has an out of loop `Store` with an `AddP` address
> expression that has other uses and is in the loop body. Schematically,
> only showing the address subgraph and the bases for the `AddP`s:
> 
> 
> Store#195 -> AddP#133 -> AddP#134 -> CastPP#110
>                      -> CastPP#110
> 
> 
> Both `AddP`s have the same base, a `CastPP` that's also in the loop
> body.
> 
> That loop is a counted loop and only has 3 iterations so is fully
> unrolled. First, one iteration is peeled:
> 
> 
>                                 /-> CastPP#110
> Store#195 -> Phi#360 -> AddP#133 -> AddP#134 -> CastPP#110
>                     -> AddP#277 -> AddP#278 -> CastPP#283
>                                 -> CastPP#283
> 
> 
> 
> The `AddP`s and `CastPP` are cloned (because in the loop body). As
> part of peeling, `PhaseIdealLoop::peeled_dom_test_elim()` is
> called. It finds the test that guards `CastPP#283` in the peeled
> iteration dominates and replaces the test that guards `CastPP#110`
> (the test in the peeled iteration is the clone of the test in the
> loop). That causes `CastPP#110`'s control to be updated to that of the
> test in the peeled iteration and to be yanked from the loop. So now
> `CastPP#283` and `CastPP#110` have the same inputs.
> 
> Next unrolling happens:
> 
> 
>                                            /-> CastPP#110
>                                /-> AddP#400 -> AddP#401 -> CastPP#110
> Store#195 -> Phi#360 -> Phi#477 -> AddP#133 -> AddP#134 -> CastPP#110
>                   \                        -> CastPP#110
>                    -> AddP#277 -> AddP#278 -> CastPP#283
>                                -> CastPP#283
> 
> 
> 
> `AddP`s are cloned once more but not the `CastPP`s because they are
> both in the peeled iteration now. A new `Phi` is added.
> 
> Next igvn runs. It's going to push the `AddP`s through the `Phi`s.
> 
> Through `Phi#477`:
> 
> 
> 
>                                 /-> CastPP#110
> Store#195 -> Phi#360 -> AddP#510 -> Phi#509 -> AddP#401 -> CastPP#110
>                   \                        -> AddP#134 -> CastPP#110
>                    -> AddP#277 -> AddP#278 -> CastPP#283
>                                -> CastPP#283
> 
> 
> 
> Through `Phi#360`:
> 
> 
>                                            /-> AddP#134 -> CastPP#110
>                                 /-> Phi#509 -> AddP#401 -> CastPP#110
> Store#195 -> AddP#516 -> Phi#515 -> AddP#278 -> CastPP#283
>                      -> Phi#514 -> CastPP#283
>                                 -> CastP#110
> 
> 
> Then `Phi#514` which has 2 `CastPP`s as input with identical inputs is
> transformed into anot...

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 14 additional commits since the last revision:

 - more
 - review
 - Merge branch 'master' into JDK-8351889
 - exp
 - Merge branch 'master' into JDK-8351889
 - verif
 - Merge branch 'master' into JDK-8351889
 - test seed
 - more
 - Merge branch 'master' into JDK-8351889
 - ... and 4 more: https://git.openjdk.org/jdk/compare/0419511c...15c17bb1

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25386/files
  - new: https://git.openjdk.org/jdk/pull/25386/files/d52f2ded..15c17bb1

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

  Stats: 19726 lines in 577 files changed: 12800 ins; 3715 del; 3211 mod
  Patch: https://git.openjdk.org/jdk/pull/25386.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25386/head:pull/25386

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

From roland at openjdk.org  Tue Dec  2 09:49:37 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Tue, 2 Dec 2025 09:49:37 GMT
Subject: RFR: 8351889: C2 crash: assertion failed:  Base pointers must
 match (addp 344) [v3]
In-Reply-To: <ypRdomeJ0LQEaKDzdHWTd5q8yiYXACmZg5JZFx2qppc=.bcf175ca-8f1c-4e6b-b6d2-b161e219b4f9@github.com>
References: <IKOYjLXrS8q1GMjbaL2HOBNH8Oa_16k4WBa2NaMngS8=.c6fd7fbb-4758-48b2-a992-3702b2718e59@github.com>
 <ONE3vyWC8GljgqXTIbv_TemwWjzn9DTxLjAvkqStoLo=.9dda8b80-111f-45b3-b5ca-b95b4006ec40@github.com>
 <ypRdomeJ0LQEaKDzdHWTd5q8yiYXACmZg5JZFx2qppc=.bcf175ca-8f1c-4e6b-b6d2-b161e219b4f9@github.com>
Message-ID: <NMucu_GC8vtOE1MuRuOTc7O4XvT7zd2BZd6aUtsiWKc=.9ea42b69-88d4-4c98-8744-2e50a48c953c@github.com>

On Mon, 24 Nov 2025 11:53:16 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8351889
>>  - verif
>>  - Merge branch 'master' into JDK-8351889
>>  - test seed
>>  - more
>>  - Merge branch 'master' into JDK-8351889
>>  - Merge branch 'master' into JDK-8351889
>>  - more
>>  - test
>>  - fix
>
> src/hotspot/share/opto/phaseX.cpp line 2085:
> 
>> 2083:   }
>> 2084:   return false;
>> 2085: }
> 
> Why not call it `verify_node_invariants_for`?
> 
> You should also assert immediately. @benoitmaillard Is about to make that change for everything: https://github.com/openjdk/jdk/pull/28295

That one is not integrated. Shouldn't I do that change only if it/when integrates?

> src/hotspot/share/opto/phaseX.hpp line 623:
> 
>> 621:     // '-XX:VerifyIterativeGVN=10000'
>> 622:     return ((VerifyIterativeGVN % 100000) / 10000) == 1;
>> 623:   }
> 
> You will need to add extra documentation to the flag. And also there is a test that uses the flag. You should adjust it to enable this bit as well.

Done in new commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25386#discussion_r2580416861
PR Review Comment: https://git.openjdk.org/jdk/pull/25386#discussion_r2580411292

From roland at openjdk.org  Tue Dec  2 09:58:18 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Tue, 2 Dec 2025 09:58:18 GMT
Subject: RFR: 8351889: C2 crash: assertion failed:  Base pointers must
 match (addp 344) [v2]
In-Reply-To: <VFVDxw6dDCH4DoBJ2LK4YOj9nZCpLlsQymqie-bBSzw=.df80f887-337f-4e08-ae82-9aeb40ed2f72@github.com>
References: <IKOYjLXrS8q1GMjbaL2HOBNH8Oa_16k4WBa2NaMngS8=.c6fd7fbb-4758-48b2-a992-3702b2718e59@github.com>
 <yTXik4qj-ATkbr-xboirhZpRKH_MAmTmeNmDfJ9Q_RQ=.9a750626-b8e4-4142-b034-008424d2eeef@github.com>
 <Bhla13OznDGq-IiiVXHGO6bdh4s4-oNou9I13IcYprc=.d50b2219-4a78-4169-abbf-5f6b06398e52@github.com>
 <IiLkwXIy60uM4PnpIwfNWNK1XkGuUuqk23YBOkiPN9k=.8fc1596d-0d51-42ec-8ff3-18340821d4ad@github.com>
 <ZxfQOyO7uTyDiAFK7lLYEIDR6Q8ZW6V7sx5WdRXITi4=.8004e862-fde3-471d-bafc-53b68ecffd93@github.com>
 <Mm7eO_nEnwtMNF560_EsYUtTx2PrcAKxqxbcEZK53nA=.95a8d2d9-fbab-4b77-a020-428c770bea33@github.com>
 <VFVDxw6dDCH4DoBJ2LK4YOj9nZCpLlsQymqie-bBSzw=.df80f887-337f-4e08-ae82-9aeb40ed2f72@github.com>
Message-ID: <BgMUHM59I09dEMtPodSY1yerYXUQ0Dj3bwIyJ56Zeio=.2970ee1e-ca04-44f2-8ba6-8527ddfb2769@github.com>

On Mon, 24 Nov 2025 09:46:31 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> > The duplication comes from loop body cloning so I'm not sure how we could prevent the duplication. We could try to common the CastPP nodes once PhaseIdealLoop::peeled_dom_test_elim() is called.
> 
> Right, that could be an option. Do you think that is worth it?

`IfNode::Ideal` looks for a dominating `If` that can replace the current `If`. It's not clear to me that that transformation can't trigger a similar failure which is why I think a fix during igvn is more robust.

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

PR Comment: https://git.openjdk.org/jdk/pull/25386#issuecomment-3601177439

From roland at openjdk.org  Tue Dec  2 10:06:57 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Tue, 2 Dec 2025 10:06:57 GMT
Subject: RFR: 8370519: C2: Hit MemLimit when running with
 +VerifyLoopOptimizations [v2]
In-Reply-To: <W7EnT28-84mtwppISdr_ydCV9HSaXk72y7fyd29z4wQ=.7331c81d-c36f-4a1c-b949-e7045f524d07@github.com>
References: <W7EnT28-84mtwppISdr_ydCV9HSaXk72y7fyd29z4wQ=.7331c81d-c36f-4a1c-b949-e7045f524d07@github.com>
Message-ID: <X46Hug3XBE36k0pATdj4LlgKp5kZISLp38f3zEx9qK4=.676249b4-794a-45cc-bf4c-23b844622476@github.com>

> 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 one additional commit since the last revision:

  Update src/hotspot/share/opto/compile.hpp
  
  Co-authored-by: Manuel H?ssig <manuel at haessig.org>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28581/files
  - new: https://git.openjdk.org/jdk/pull/28581/files/27524015..eb7bd9ac

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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  Tue Dec  2 10:06:59 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Tue, 2 Dec 2025 10:06:59 GMT
Subject: RFR: 8370519: C2: Hit MemLimit when running with
 +VerifyLoopOptimizations [v2]
In-Reply-To: <VzJzmssTnqDXP9C_T26tywRbtm8VbtFcdLXAtQLJM1o=.ebce4fa8-8cf7-4cd3-b5e0-135c4f3b06dd@github.com>
References: <W7EnT28-84mtwppISdr_ydCV9HSaXk72y7fyd29z4wQ=.7331c81d-c36f-4a1c-b949-e7045f524d07@github.com>
 <VzJzmssTnqDXP9C_T26tywRbtm8VbtFcdLXAtQLJM1o=.ebce4fa8-8cf7-4cd3-b5e0-135c4f3b06dd@github.com>
Message-ID: <vYFmeHJtQkPozEebjnn8fgLI_mpc_OMeWugbEUW9ILI=.6cc23448-b867-4b55-8650-8f2c9d24b5d5@github.com>

On Mon, 1 Dec 2025 16:07:47 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/hotspot/share/opto/compile.hpp
>>   
>>   Co-authored-by: Manuel H?ssig <manuel at haessig.org>
>
> test/hotspot/jtreg/compiler/c2/TestVerifyLoopOptimizationsHighMemUsage.java line 27:
> 
>> 25:  * @test
>> 26:  * @bug 8370519
>> 27:  * @summary C2: Hit MemLimit when running with +VerifyLoopOptimizations
> 
> Unsure, but would this test qualify for `@key stress`?

I'm not sure either what does.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28581#discussion_r2580480945

From aph at openjdk.org  Tue Dec  2 10:07:41 2025
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 2 Dec 2025 10:07:41 GMT
Subject: RFR: 8355216: Accelerate P-256 arithmetic on aarch64 [v2]
In-Reply-To: <nSkGY6VVBNf0vfbCIxMvDcURh7YgrECg7O2h8Dei3Lo=.ed9973ea-fb2e-45c1-92fb-e9f74d34d337@github.com>
References: <EiLAVdcIX_OKisbKoR6H6ADweL9LSuLfIRQgRYYNw7o=.8c823874-0af8-4c54-8e61-a2c43243b2e0@github.com>
 <nSkGY6VVBNf0vfbCIxMvDcURh7YgrECg7O2h8Dei3Lo=.ed9973ea-fb2e-45c1-92fb-e9f74d34d337@github.com>
Message-ID: <i6wrfDh3bM4iKL6PTIBvBt09nNJS6Za9Pqv1nOl7AuE=.b2136597-38ef-41a6-8ff1-517a5790cebe@github.com>

On Mon, 1 Dec 2025 22:19:09 GMT, Ben Perez <bperez at openjdk.org> wrote:

>> An aarch64 implementation of the `MontgomeryIntegerPolynomial256.mult()` method
>
> Ben Perez has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed typo

src/hotspot/cpu/aarch64/assembler_aarch64.hpp line 3162:

> 3160:     int l = (size == 0b01) ? ((lane >> 1) & 1) : (lane & 1);
> 3161:     int m = lane & 1;
> 3162:     assert((size == 0b10 ? lane < 4 : lane < 7));

Why `lane < 7`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27946#discussion_r2580486240

From vklang at openjdk.org  Tue Dec  2 10:08:39 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 2 Dec 2025 10:08:39 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v3]
In-Reply-To: <eXO79ZBlZUltqddmReHLTSFSr3x8PiH0a5s740GHrfk=.5cf01f8f-7ac5-4def-b17d-dfd6f10e9614@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <eXO79ZBlZUltqddmReHLTSFSr3x8PiH0a5s740GHrfk=.5cf01f8f-7ac5-4def-b17d-dfd6f10e9614@github.com>
Message-ID: <8tnePBnWu5w86zsXUOVMd7R_oHsTVl_Gjug0QP7N_vw=.5ce0106a-a7bf-40a2-b6a4-76e5d816150e@github.com>

On Mon, 1 Dec 2025 23:41:04 GMT, Chen Liang <liach at openjdk.org> 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:
> 
>   Tweak VH usage in some classes

src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 632:

> 630:     @Hidden
> 631:     @jdk.internal.vm.annotation.IntrinsicCandidate
> 632:     static int isCompileConstant(Object obj) {

nit: an "is"-question tends to indicate a yes/no answer, but in this case it is more of a compileConstantStatus.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2580489368

From aph at openjdk.org  Tue Dec  2 10:10:32 2025
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 2 Dec 2025 10:10:32 GMT
Subject: RFR: 8355216: Accelerate P-256 arithmetic on aarch64 [v2]
In-Reply-To: <nSkGY6VVBNf0vfbCIxMvDcURh7YgrECg7O2h8Dei3Lo=.ed9973ea-fb2e-45c1-92fb-e9f74d34d337@github.com>
References: <EiLAVdcIX_OKisbKoR6H6ADweL9LSuLfIRQgRYYNw7o=.8c823874-0af8-4c54-8e61-a2c43243b2e0@github.com>
 <nSkGY6VVBNf0vfbCIxMvDcURh7YgrECg7O2h8Dei3Lo=.ed9973ea-fb2e-45c1-92fb-e9f74d34d337@github.com>
Message-ID: <XL_0hfh1uns2bWswH6Nxi_Mz9cz423Bxe4DKHkgUon4=.70c3d22d-e00e-4c7f-8d31-14f9a1fbcc5f@github.com>

On Mon, 1 Dec 2025 22:19:09 GMT, Ben Perez <bperez at openjdk.org> wrote:

>> An aarch64 implementation of the `MontgomeryIntegerPolynomial256.mult()` method
>
> Ben Perez has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed typo

src/hotspot/cpu/aarch64/assembler_aarch64.hpp line 3194:

> 3192:     _umullv(Vd, Ta, Vn, Tb, Vm, Ts, lane);
> 3193:   }
> 3194: 

These seem to be essentially identical except for one assertion.

Suggestion: as elsewhere in class Assembler,` #define INSN` for the common pattern, then use it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27946#discussion_r2580496108

From mhaessig at openjdk.org  Tue Dec  2 10:29:29 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Tue, 2 Dec 2025 10:29:29 GMT
Subject: RFR: 8370519: C2: Hit MemLimit when running with
 +VerifyLoopOptimizations [v2]
In-Reply-To: <vYFmeHJtQkPozEebjnn8fgLI_mpc_OMeWugbEUW9ILI=.6cc23448-b867-4b55-8650-8f2c9d24b5d5@github.com>
References: <W7EnT28-84mtwppISdr_ydCV9HSaXk72y7fyd29z4wQ=.7331c81d-c36f-4a1c-b949-e7045f524d07@github.com>
 <VzJzmssTnqDXP9C_T26tywRbtm8VbtFcdLXAtQLJM1o=.ebce4fa8-8cf7-4cd3-b5e0-135c4f3b06dd@github.com>
 <vYFmeHJtQkPozEebjnn8fgLI_mpc_OMeWugbEUW9ILI=.6cc23448-b867-4b55-8650-8f2c9d24b5d5@github.com>
Message-ID: <m_9sKXJaG5Z3vZ2KlZv4Ca2QVDN0KTvX9fYsQWLKwvc=.56681b53-aec3-4e18-b77b-0fa1757f118f@github.com>

On Tue, 2 Dec 2025 10:03:52 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/c2/TestVerifyLoopOptimizationsHighMemUsage.java line 27:
>> 
>>> 25:  * @test
>>> 26:  * @bug 8370519
>>> 27:  * @summary C2: Hit MemLimit when running with +VerifyLoopOptimizations
>> 
>> Unsure, but would this test qualify for `@key stress`?
>
> I'm not sure either what does.

It is a marker to filter resource intensive tests.

https://github.com/openjdk/jdk/blob/7278d2e8e5835f090672f7625d391a1b4c1a6626/test/hotspot/jtreg/TEST.ROOT#L29-L30

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28581#discussion_r2580570634

From shade at openjdk.org  Tue Dec  2 10:31:22 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 2 Dec 2025 10:31:22 GMT
Subject: RFR: 8357258: x86: Improve receiver type profiling reliability
 [v8]
In-Reply-To: <X9RJoDWqk67MlK7P4ACCbzROxLkfEqvU0zDid3zymnc=.7c0086a3-f514-4b0d-8bc0-592bf4a05bba@github.com>
References: <X9RJoDWqk67MlK7P4ACCbzROxLkfEqvU0zDid3zymnc=.7c0086a3-f514-4b0d-8bc0-592bf4a05bba@github.com>
Message-ID: <avqNAcH5MpUoM31mrtm0Z6qnPqpgbpGszW01AtFbYXk=.359b8088-c0b5-4a01-aefc-fe3c02bdd60a@github.com>

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

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

 - 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
 - Offset is always rscratch1, no need to save it
 - Grossly simplify register shuffling
 - ... and 11 more: https://git.openjdk.org/jdk/compare/7278d2e8...3c5019d9

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

Changes: https://git.openjdk.org/jdk/pull/25305/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25305&range=07
  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 roland at openjdk.org  Tue Dec  2 11:21:05 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Tue, 2 Dec 2025 11:21:05 GMT
Subject: RFR: 8370519: C2: Hit MemLimit when running with
 +VerifyLoopOptimizations [v3]
In-Reply-To: <W7EnT28-84mtwppISdr_ydCV9HSaXk72y7fyd29z4wQ=.7331c81d-c36f-4a1c-b949-e7045f524d07@github.com>
References: <W7EnT28-84mtwppISdr_ydCV9HSaXk72y7fyd29z4wQ=.7331c81d-c36f-4a1c-b949-e7045f524d07@github.com>
Message-ID: <FkXbOvbukpCfSEBmYIOsn1IUaRnPZhEYv3yfz3Dz-QQ=.da549428-ed90-424e-8a77-dac3a745ed67@github.com>

> 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 two additional commits since the last revision:

 - review
 - review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28581/files
  - new: https://git.openjdk.org/jdk/pull/28581/files/eb7bd9ac..36fb3a6f

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

  Stats: 49 lines in 5 files changed: 22 ins; 24 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 roland at openjdk.org  Tue Dec  2 11:21:05 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Tue, 2 Dec 2025 11:21:05 GMT
Subject: RFR: 8370519: C2: Hit MemLimit when running with
 +VerifyLoopOptimizations [v3]
In-Reply-To: <hO3unoRVT77Lg_o4eUNywrDezfGt2_8uZ2DPbfo0XdM=.9514b0e0-b5cd-4a9d-b595-65327fbf0fee@github.com>
References: <W7EnT28-84mtwppISdr_ydCV9HSaXk72y7fyd29z4wQ=.7331c81d-c36f-4a1c-b949-e7045f524d07@github.com>
 <hO3unoRVT77Lg_o4eUNywrDezfGt2_8uZ2DPbfo0XdM=.9514b0e0-b5cd-4a9d-b595-65327fbf0fee@github.com>
Message-ID: <MIJZNFTxtR2NUripitNF3BQc8k_qw-WHcYX2RmELNeE=.ae9205cc-5b27-4d42-8af3-0ebf5ad90c2b@github.com>

On Mon, 1 Dec 2025 16:17:03 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - review
>>  - review
>
> src/hotspot/share/opto/compile.hpp line 810:
> 
>> 808:   // Compilation environment.
>> 809:   Arena*      comp_arena()           { return &_comp_arena; }
>> 810:   ResourceArea* idealloop_arena()    { return &_idealloop_arena; }
> 
> Should we make it more idiomatic C++ by having the `ResourceArea` allocated and deallocated together with the `PhaseIdealLoop` instead of attaching it to the `Compile` object?

Right, that makes sense. Done in new commits.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28581#discussion_r2580735137

From roland at openjdk.org  Tue Dec  2 11:21:06 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Tue, 2 Dec 2025 11:21:06 GMT
Subject: RFR: 8370519: C2: Hit MemLimit when running with
 +VerifyLoopOptimizations [v3]
In-Reply-To: <m_9sKXJaG5Z3vZ2KlZv4Ca2QVDN0KTvX9fYsQWLKwvc=.56681b53-aec3-4e18-b77b-0fa1757f118f@github.com>
References: <W7EnT28-84mtwppISdr_ydCV9HSaXk72y7fyd29z4wQ=.7331c81d-c36f-4a1c-b949-e7045f524d07@github.com>
 <VzJzmssTnqDXP9C_T26tywRbtm8VbtFcdLXAtQLJM1o=.ebce4fa8-8cf7-4cd3-b5e0-135c4f3b06dd@github.com>
 <vYFmeHJtQkPozEebjnn8fgLI_mpc_OMeWugbEUW9ILI=.6cc23448-b867-4b55-8650-8f2c9d24b5d5@github.com>
 <m_9sKXJaG5Z3vZ2KlZv4Ca2QVDN0KTvX9fYsQWLKwvc=.56681b53-aec3-4e18-b77b-0fa1757f118f@github.com>
Message-ID: <C2i5SfyfA3eBMv8A7R-C0_I-6zJc51Pt1YG96wOzVQI=.68daf5d0-056e-459f-ad21-09faf13462a8@github.com>

On Tue, 2 Dec 2025 10:26:22 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

>> I'm not sure either what does.
>
> It is a marker to filter resource intensive tests.
> 
> https://github.com/openjdk/jdk/blob/7278d2e8e5835f090672f7625d391a1b4c1a6626/test/hotspot/jtreg/TEST.ROOT#L29-L30

I added it in the new commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28581#discussion_r2580735997

From roland at openjdk.org  Tue Dec  2 11:21:08 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Tue, 2 Dec 2025 11:21:08 GMT
Subject: RFR: 8370519: C2: Hit MemLimit when running with
 +VerifyLoopOptimizations [v3]
In-Reply-To: <rFGy_mZFS29oe2Ie23rRCqFQigWHLghMgum7heKDZcw=.8447fff4-e59d-4ea0-9005-9e5f71930489@github.com>
References: <W7EnT28-84mtwppISdr_ydCV9HSaXk72y7fyd29z4wQ=.7331c81d-c36f-4a1c-b949-e7045f524d07@github.com>
 <rFGy_mZFS29oe2Ie23rRCqFQigWHLghMgum7heKDZcw=.8447fff4-e59d-4ea0-9005-9e5f71930489@github.com>
Message-ID: <_HueHgU8Ha0yoG9cckWMGfms8D0WC6zGWKykIQkCeZM=.3f929996-99ee-4535-8973-b23ccf6b291e@github.com>

On Mon, 1 Dec 2025 16:33:20 GMT, Beno?t Maillard <bmaillard at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - review
>>  - review
>
> test/hotspot/jtreg/compiler/c2/TestVerifyLoopOptimizationsHighMemUsage.java line 28:
> 
>> 26:  * @bug 8370519
>> 27:  * @summary C2: Hit MemLimit when running with +VerifyLoopOptimizations
>> 28:  * @run main/othervm -XX:CompileCommand=compileonly,*TestVerifyLoopOptimizationsHighMemUsage*::* -XX:-TieredCompilation -Xbatch
> 
> Out of curiosity, have you try reducing the test with `creduce`? I fixed a similar issue in [JDK-8366990](https://bugs.openjdk.org/browse/JDK-8366990), and initially reviewers were concerned about the long compilation time. I was able to get decent results with `creduce` by using  `-XX:CompileCommand=memlimit`. Not sure if it's worth doing here though.

I don't have `creduce` set up. I tried minimizing the test case by hand but it was fairly time consuming. It currently runs in 30s on a fairly fast machine.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28581#discussion_r2580733874

From duke at openjdk.org  Tue Dec  2 11:33:47 2025
From: duke at openjdk.org (Vishal Chand)
Date: Tue, 2 Dec 2025 11:33:47 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: <IgEuelEzPt9Atv8KQR1Sa80QaKGllGNR-nWRF-sdm3Y=.72ccb838-8723-4fb8-9547-ed20e51b00f1@github.com>
 <IBk5-edc3PLSPqI5HZ4pDOthGiFBlj2MDMKs_A0kLEk=.3b7097c9-afe9-4441-a0b1-bdd20eb1468f@github.com>
 <YiOD-Uhl8zzAYb-uLYLs9itATGW4GQjH7iPKMRtdARE=.3cebae80-b55e-4a60-b92e-593e579d4931@github.com>
 <0BI-aekYlNzNe8szo_NjO14MRbrV_NjjQN6IYB_AT40=.5c548a70-d6fa-4eb9-b7cc-3c44f84ea833@github.com>
Message-ID: <IRe-FNArDnXQ9iv9oZEZRlJz9FcNbv-GnoK3FU1-g1I=.c13295ad-20c2-4d2e-a601-2d5410ae71a0@github.com>

On Mon, 1 Dec 2025 22:38:29 GMT, Leonid Mesnik <lmesnik at openjdk.org> 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 There are failures with `make test TEST=vmTestbase/ JTREG=TEST_THREAD_FACTORY=Virtual` even without the change. And it is worse as the tests are flaky, so it is hard to compare with and without the change. 

Below are the test results `without` the change for 3 runs:


                   TEST                           TOTAL   PASS   FAIL   ERROR    SKIP   
jtreg:test/hotspot/jtreg/vmTestbase                3056   2990    17     4        45 
jtreg:test/hotspot/jtreg/vmTestbase                3059   2991    18     6        44
jtreg:test/hotspot/jtreg/vmTestbase                3062   2996    17     4        45

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

PR Comment: https://git.openjdk.org/jdk/pull/28547#issuecomment-3601574459

From thartmann at openjdk.org  Tue Dec  2 12:37:46 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 2 Dec 2025 12:37:46 GMT
Subject: RFR: 8371306: JDK-8367002 behavior might not match existing
 HotSpot behavior.
In-Reply-To: <6Rlv3LqIljnMFAoDX1kgGT1hWCVGgU-UNS-UOYIpNrU=.760472eb-f9ab-415f-8618-e596b0d50c7b@github.com>
References: <6Rlv3LqIljnMFAoDX1kgGT1hWCVGgU-UNS-UOYIpNrU=.760472eb-f9ab-415f-8618-e596b0d50c7b@github.com>
Message-ID: <5975FvnIp_w-TSIVgdYCwMXCQKrjZY8VEZvJnV89LdY=.32729efa-aa64-4b2a-b321-aedc3fd5720c@github.com>

On Tue, 25 Nov 2025 18:24:42 GMT, Dean Long <dlong at openjdk.org> wrote:

> When deoptimizing to the interpreter, we need to restore the thrown exception to the original, otherwise it might be caught by the wrong handler.  In the test case, that means restoring the original ArithmeticException instead of keeping the new/recursive IllegalAccessError.

Looks good to me but I'm not an expert in this area.

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

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28497#pullrequestreview-3529857530

From jsikstro at openjdk.org  Tue Dec  2 12:41:05 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 2 Dec 2025 12:41:05 GMT
Subject: RFR: 8371986: Remove the default value of InitialRAMPercentage
In-Reply-To: <2usjgAiZCq5KUDw_wRjOcj2PkJX7S-Vx0fl0Dq3I_Xk=.41abf7d5-2662-4ae9-ad8b-d6f46b7ce1d4@github.com>
References: <JUiaXpa21jOriWoJ5Lu_EqJI6YlM6SlduCj_nXq2zrM=.ab677e9e-1b30-404a-a28d-93127588a0b4@github.com>
 <2usjgAiZCq5KUDw_wRjOcj2PkJX7S-Vx0fl0Dq3I_Xk=.41abf7d5-2662-4ae9-ad8b-d6f46b7ce1d4@github.com>
Message-ID: <IlgCKU0vfwtU-L7oMh6KuYArzNRA9IcapU0jk9EpPe4=.c29984db-f0a7-4987-b91a-83b883a6bae4@github.com>

On Thu, 27 Nov 2025 13:27:00 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Hello,
>> 
>> This RFE changes the default of `InitialRAMPercentage` to 0, effectively removing its default value. Please see the CSR for specific details on this change.
>> 
>> Changing the default value to 0 results in the behavior that the initial heap size (InitialHeapSize) is set to the minimum heap size (MinHeapSize). This is because of the following lines in `Arguments::set_heap_size()`, which takes the MAX value of MinHeapSize as well:
>> 
>> uint64_t initial_memory = (uint64_t)(((double)MaxRAM * InitialRAMPercentage) / 100);
>> ...
>> 
>> reasonable_initial = MAX3(reasonable_initial, reasonable_minimum, MinHeapSize);
>> reasonable_initial = MIN2(reasonable_initial, MaxHeapSize);
>> 
>> 
>> This change improves startup performance for all GCs, but affects the time-to-peak performance in some out-of-the-box configurations for some GCs. This is mainly visible in ParallelGC.
>
> Marked as reviewed by shade (Reviewer).

Thank you for the reviews! @shipilev @xmas92

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

PR Comment: https://git.openjdk.org/jdk/pull/28530#issuecomment-3601818460

From jsikstro at openjdk.org  Tue Dec  2 12:41:07 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 2 Dec 2025 12:41:07 GMT
Subject: Integrated: 8371986: Remove the default value of InitialRAMPercentage
In-Reply-To: <JUiaXpa21jOriWoJ5Lu_EqJI6YlM6SlduCj_nXq2zrM=.ab677e9e-1b30-404a-a28d-93127588a0b4@github.com>
References: <JUiaXpa21jOriWoJ5Lu_EqJI6YlM6SlduCj_nXq2zrM=.ab677e9e-1b30-404a-a28d-93127588a0b4@github.com>
Message-ID: <8cjcrYgzTpdvFhk0Zt2zbb-d6dAESaDlOn5lR76RUoM=.759227f8-646d-467d-b653-ad4f36eaa218@github.com>

On Thu, 27 Nov 2025 09:53:56 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> This RFE changes the default of `InitialRAMPercentage` to 0, effectively removing its default value. Please see the CSR for specific details on this change.
> 
> Changing the default value to 0 results in the behavior that the initial heap size (InitialHeapSize) is set to the minimum heap size (MinHeapSize). This is because of the following lines in `Arguments::set_heap_size()`, which takes the MAX value of MinHeapSize as well:
> 
> uint64_t initial_memory = (uint64_t)(((double)MaxRAM * InitialRAMPercentage) / 100);
> ...
> 
> reasonable_initial = MAX3(reasonable_initial, reasonable_minimum, MinHeapSize);
> reasonable_initial = MIN2(reasonable_initial, MaxHeapSize);
> 
> 
> This change improves startup performance for all GCs, but affects the time-to-peak performance in some out-of-the-box configurations for some GCs. This is mainly visible in ParallelGC.

This pull request has now been integrated.

Changeset: 6abf7b6f
Author:    Joel Sikstr?m <jsikstro at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6abf7b6f226adb580718a314dc218d87289c80ac
Stats:     4 lines in 3 files changed: 0 ins; 1 del; 3 mod

8371986: Remove the default value of InitialRAMPercentage

Reviewed-by: shade, aboldtch

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

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

From alanb at openjdk.org  Tue Dec  2 12:51:47 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 2 Dec 2025 12:51:47 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: <IgEuelEzPt9Atv8KQR1Sa80QaKGllGNR-nWRF-sdm3Y=.72ccb838-8723-4fb8-9547-ed20e51b00f1@github.com>
 <IBk5-edc3PLSPqI5HZ4pDOthGiFBlj2MDMKs_A0kLEk=.3b7097c9-afe9-4441-a0b1-bdd20eb1468f@github.com>
 <YiOD-Uhl8zzAYb-uLYLs9itATGW4GQjH7iPKMRtdARE=.3cebae80-b55e-4a60-b92e-593e579d4931@github.com>
 <0BI-aekYlNzNe8szo_NjO14MRbrV_NjjQN6IYB_AT40=.5c548a70-d6fa-4eb9-b7cc-3c44f84ea833@github.com>
Message-ID: <NKJ_sFkC5imJ92NeWmi47PWtmC3JHpQAyRqmiJtfQO4=.61690dab-0237-467a-b65c-9e57c9167b13@github.com>

On Mon, 1 Dec 2025 22:38:29 GMT, Leonid Mesnik <lmesnik at openjdk.org> 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 There are failures with `make test TEST=vmTestbase/ JTREG=TEST_THREAD_FACTORY=Virtual` even without the change. 

Does running with JTREG_EXTRA_PROBLEM_LISTS=ProblemList-Virtual.txt improve this?

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

PR Comment: https://git.openjdk.org/jdk/pull/28547#issuecomment-3601866457

From coleenp at openjdk.org  Tue Dec  2 13:24:54 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 2 Dec 2025 13:24:54 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v7]
In-Reply-To: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
Message-ID: <lyWK2X4EtG3Rq45neyn16-wytK0CVi82blyrj2JGsd4=.28c7a6b0-bcac-4259-a58e-7f721a545a26@github.com>

> ArrayKlass doesn't set AccessFlags so don't look for them there.  See CR for details.
> Fixed SA and jvmci.  @iwanowww Can you check that I changed C2 correctly (we talked about this in August).
> Tested with tier1-4.  5-7 in progress.

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

  Fixed indentation.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28371/files
  - new: https://git.openjdk.org/jdk/pull/28371/files/8861381f..c7247c00

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

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

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

From coleenp at openjdk.org  Tue Dec  2 13:24:55 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 2 Dec 2025 13:24:55 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v6]
In-Reply-To: <UJPTQn81pxsRiN-CA5K5paBh3VYdVppLFzuLDcHC0KU=.5a89e212-d9fc-4341-8f21-df6703e03881@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
 <-KbUyaoVA5lXRBZmFQGTgeU9wtgLF4_qvR7vLHNkPzg=.e851e0f7-4b95-4a12-a5ce-a1d269ceafa5@github.com>
 <UJPTQn81pxsRiN-CA5K5paBh3VYdVppLFzuLDcHC0KU=.5a89e212-d9fc-4341-8f21-df6703e03881@github.com>
Message-ID: <DgOSKymKP3gcLF_nI96qtCq2CFXBiaS6aQn4kehVdYA=.d1bf8b4e-36aa-43cf-97cd-c8d605f1bd94@github.com>

On Tue, 2 Dec 2025 02:14:39 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Additional comment
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java line 67:
> 
>> 65:   public long     getAccessFlags()      { return            accessFlags.getValue(this);  }
>> 66:   // Convenience routine
>> 67:   public AccessFlags getAccessFlagsObj(){ return new AccessFlags(getAccessFlags());      }
> 
> Nit: The `getAccessFlags`, `getAccessFlagsObj` definitions and `accessFlags` initialization at line 101 are not aligned with other definitions/initializations. Also, there are unneeded spaces in definitions of `getAccessFlags`, `getAccessFlagsObj`.

Thanks for noticing this. Did look messy.  I fixed it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28371#discussion_r2581151367

From fgao at openjdk.org  Tue Dec  2 13:54:01 2025
From: fgao at openjdk.org (Fei Gao)
Date: Tue, 2 Dec 2025 13:54:01 GMT
Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() [v3]
In-Reply-To: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com>
References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com>
Message-ID: <SIYhGsf5_2F6gUNHFuGT_mOGFR2QO5E-ZntNCqFqDqM=.0d56c710-10eb-4f39-b2fc-664cc4e0cce1@github.com>

> 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 six additional commits since the last revision:

 - 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
 - 8363620: AArch64: reimplement emit_static_call_stub()
   
   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 bytes 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

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26638/files
  - new: https://git.openjdk.org/jdk/pull/26638/files/f5a83e30..6d3669c1

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

  Stats: 4590 lines in 177 files changed: 3733 ins; 423 del; 434 mod
  Patch: https://git.openjdk.org/jdk/pull/26638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26638/head:pull/26638

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

From chagedorn at openjdk.org  Tue Dec  2 13:54:26 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 2 Dec 2025 13:54:26 GMT
Subject: RFR: 8354282: C2: more crashes in compiled code because of
 dependency on removed range check CastIIs [v8]
In-Reply-To: <qab0P8PMsV9UzIT8JqUuAixFJbzNkpjd_FCSDnVB49U=.f52c826c-480f-4330-ba68-01b22f21b044@github.com>
References: <qos-VYvgreqGsB7ke35RmM3L9uHnnM6nUsm2QONKXc4=.9c902d61-5f45-41f5-8276-ac28830c2bf5@github.com>
 <qab0P8PMsV9UzIT8JqUuAixFJbzNkpjd_FCSDnVB49U=.f52c826c-480f-4330-ba68-01b22f21b044@github.com>
Message-ID: <2xxjKX6hMeKDfS9SGBEvll8yadDthCoUjCIRpaE8ObA=.b567ec00-7dad-4b57-82a4-db1149fc8942@github.com>

On Tue, 2 Dec 2025 09:20:41 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> This is a variant of 8332827. In 8332827, an array access becomes
>> dependent on a range check `CastII` for another array access. When,
>> after loop opts are over, that RC `CastII` was removed, the array
>> access could float and an out of bound access happened. With the fix
>> for 8332827, RC `CastII`s are no longer removed.
>> 
>> With this one what happens is that some transformations applied after
>> loop opts are over widen the type of the RC `CastII`. As a result, the
>> type of the RC `CastII` is no longer narrower than that of its input,
>> the `CastII` is removed and the dependency is lost.
>> 
>> There are 2 transformations that cause this to happen:
>> 
>> - after loop opts are over, the type of the `CastII` nodes are widen
>>   so nodes that have the same inputs but a slightly different type can
>>   common.
>>   
>> - When pushing a `CastII` through an `Add`, if of the type both inputs
>>   of the `Add`s are non constant, then we end up widening the type
>>   (the resulting `Add` has a type that's wider than that of the
>>   initial `CastII`).
>>   
>> There are already 3 types of `Cast` nodes depending on the
>> optimizations that are allowed. Either the `Cast` is floating
>> (`depends_only_test()` returns `true`) or pinned. Either the `Cast`
>> can be removed if it no longer narrows the type of its input or
>> not. We already have variants of the `CastII`:
>> 
>> - if the Cast can float and be removed when it doesn't narrow the type
>> of its input.
>> 
>> - if the Cast is pinned and be removed when it doesn't narrow the type
>> of its input.
>> 
>> - if the Cast is pinned and can't be removed when it doesn't narrow
>> the type of its input.
>> 
>> What we need here, I think, is the 4th combination:
>> 
>> - if the Cast can float and can't be removed when it doesn't narrow
>> the type of its input.
>> 
>> Anyway, things are becoming confusing with all these different
>> variants named in ways that don't always help figure out what
>> constraints one of them operate under. So I refactored this and that's
>> the biggest part of this change. The fix consists in marking `Cast`
>> nodes when their type is widen in a way that prevents them from being
>> optimized out.
>> 
>> Tobias ran performance testing with a slightly different version of
>> this change and there was no regression.
>
> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - Merge branch 'master' into JDK-8354282
>  - whitespace
>  - review
>  - review
>  - Update src/hotspot/share/opto/castnode.cpp
>    
>    Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>  - Update src/hotspot/share/opto/castnode.cpp
>    
>    Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>  - Update src/hotspot/share/opto/castnode.cpp
>    
>    Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>  - Update test/hotspot/jtreg/compiler/c2/irTests/TestPushAddThruCast.java
>    
>    Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>  - review
>  - review
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/ef5e744a...93b8b0c5

Thanks for the update, it looks good to me! If @eme64 also agrees with the latest patch, we can submit some testing and then hopefully get it in right before the fork.

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

Marked as reviewed by chagedorn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24575#pullrequestreview-3530251375

From chagedorn at openjdk.org  Tue Dec  2 13:54:29 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 2 Dec 2025 13:54:29 GMT
Subject: RFR: 8354282: C2: more crashes in compiled code because of
 dependency on removed range check CastIIs [v4]
In-Reply-To: <ZBaHnvt0boK4Vbg6uwGvTMEvcRSjaftz1WYSRSTnqQw=.9e0eae89-42c1-4ba0-adf8-75f596c1ea0e@github.com>
References: <qos-VYvgreqGsB7ke35RmM3L9uHnnM6nUsm2QONKXc4=.9c902d61-5f45-41f5-8276-ac28830c2bf5@github.com>
 <6qShqR-Ohv7vamoJ_B4Ev-poU8SB96eTBo4HFJrylcI=.dac5a26f-c9f0-445b-8f1c-a7c719fa27ae@github.com>
 <4QQp7C7iIVfVs1MoUMC56KCgVGpXu5ziTHfZ-f2pk6o=.4ca7e1a8-3f31-44d3-aaec-30429ed7e2b0@github.com>
 <ZBaHnvt0boK4Vbg6uwGvTMEvcRSjaftz1WYSRSTnqQw=.9e0eae89-42c1-4ba0-adf8-75f596c1ea0e@github.com>
Message-ID: <dfxTBaKZjtdzGIEXSVGuLC-JxBtlD5jM0yOSWd7ZpDg=.8e077dc9-633c-4127-9f87-a53d7791b52f@github.com>

On Thu, 27 Nov 2025 12:29:10 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> src/hotspot/share/opto/castnode.hpp line 101:
>> 
>>> 99:       }
>>> 100:       return NonFloatingNonNarrowing;
>>> 101:     }
>> 
>> Just a side note: We seem to mix the terms "(non-)pinned" with "(non-)floating" freely. Should we stick to just one? But maybe it's justified to use both depending on the situation/code context.
>
> The patch as it is now adds some extra uses of "pinned" and "floating". What could make sense, I suppose, would be to try to use "floating"/"non floating" instead but there are so many uses of "pinned" in the code base already, and I don't see us getting rid of them, that I wonder if it would make a difference. So, I'm not too sure what to do.

Yes, that's true. I was also unsure about whether we should stick with one or just allow both interchangeably. I guess since there are so many uses, we can just move forward with what you have now and still come back to clean it up if necessary - we can always do that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24575#discussion_r2581285955

From chagedorn at openjdk.org  Tue Dec  2 13:54:34 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 2 Dec 2025 13:54:34 GMT
Subject: RFR: 8354282: C2: more crashes in compiled code because of
 dependency on removed range check CastIIs [v4]
In-Reply-To: <4QQp7C7iIVfVs1MoUMC56KCgVGpXu5ziTHfZ-f2pk6o=.4ca7e1a8-3f31-44d3-aaec-30429ed7e2b0@github.com>
References: <qos-VYvgreqGsB7ke35RmM3L9uHnnM6nUsm2QONKXc4=.9c902d61-5f45-41f5-8276-ac28830c2bf5@github.com>
 <6qShqR-Ohv7vamoJ_B4Ev-poU8SB96eTBo4HFJrylcI=.dac5a26f-c9f0-445b-8f1c-a7c719fa27ae@github.com>
 <4QQp7C7iIVfVs1MoUMC56KCgVGpXu5ziTHfZ-f2pk6o=.4ca7e1a8-3f31-44d3-aaec-30429ed7e2b0@github.com>
Message-ID: <Hlm2AFbWIxCpvctSkrvAVmYt3IMAizm0LNOfnTHn0Js=.58dac1e4-c57b-479b-85e2-9d28c467b12c@github.com>

On Wed, 26 Nov 2025 13:24:05 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
>> 
>>  - review
>>  - review
>>  - Merge branch 'master' into JDK-8354282
>>  - review
>>  - infinite loop in gvn fix
>>  - renaming
>>  - merge
>>  - Merge branch 'master' into JDK-8354282
>>  - fix & test
>
> src/hotspot/share/opto/castnode.hpp line 120:
> 
>> 118:     // be removed in any case otherwise the sunk node floats back into the loop.
>> 119:     static const DependencyType NonFloatingNonNarrowing;
>> 120: 
> 
> I needed a moment to completely understand all these combinations. I rewrote the definitions in this process a little bit. Feel free to take some of it over:
> 
> 
>     // All the possible combinations of floating/narrowing with example use cases:
> 
>     // Use case example: Range Check CastII
>     // Floating: The Cast is only dependent on the single range check.
>     // Narrowing: The Cast narrows the type to a positive index. If the input to the Cast is narrower, we can safely
>     //            remove the cast because the array access will be safe.
>     static const DependencyType FloatingNarrowing;
> 
>     // Use case example: Widening Cast nodes' types after loop opts: We want to common Casts with slightly different types.
>     // Floating: These Casts only depend on the single control.
>     // NonNarrowing: Even when the input type is narrower, we are not removing the Cast. Otherwise, the dependency
>     //               to the single control is lost, and an array access could float above its range check because we
>     //               just removed the dependency to the range check by removing the Cast. This could lead to an
>     //               out-of-bounds access.
>     static const DependencyType FloatingNonNarrowing;
> 
>     // Use case example: An array accesses that is no longer dependent on a single range check (e.g. range check smearing).
>     // NonFloating: The array access must be pinned below all the checks it depends on. If the check it directly depends
>     //              on with a control input is hoisted, we do hoist the Cast as well. If we allowed the Cast to float,
>     //              we risk that the array access ends up above another check it depends on (we cannot model two control
>     //              dependencies for a node in the IR). This could lead to an out-of-bounds access.
>     // Narrowing: If the Cast does not narrow the input type, then it's safe to remove the cast because the array access
>     //            will be safe.
>     static const DependencyType NonFloatingNarrowing;
> 
>     // Use case example: Sinking nodes out of a loop
>     // Non-Floating & Non-Narrowing: We don't want the Cast that forces the node to be out of loop to be removed in any
>     //                               case. Otherwise, the sunk node could float back into the l...

Thanks for taking it over :-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24575#discussion_r2581287358

From fgao at openjdk.org  Tue Dec  2 13:57:45 2025
From: fgao at openjdk.org (Fei Gao)
Date: Tue, 2 Dec 2025 13:57:45 GMT
Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() [v2]
In-Reply-To: <NPLsGrduyq6Fhus--wGRh8tOnbsowKm5gPHVdtL5mmg=.04048300-319a-4d1b-a1a7-109caf078ff8@github.com>
References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com>
 <NumjnPu4G4oJGGBCW6Q-nue3fl57GMeZCR1Whga6PiQ=.c4ebcd4d-e3c1-4bb9-9f46-5088dda819ac@github.com>
 <NPLsGrduyq6Fhus--wGRh8tOnbsowKm5gPHVdtL5mmg=.04048300-319a-4d1b-a1a7-109caf078ff8@github.com>
Message-ID: <SmKES8LRhZc9UV-ZcIyfk28jOptb8g4BPLvAXjWtLK4=.a47fa7d2-d11d-43fb-bd04-5a9403a120ad@github.com>

On Sun, 30 Nov 2025 17:08:22 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Your benchmark doesn't work. Please fix it.

Thanks for pointing that out!

I tested using `java -jar benchmark.jar `and didn?t realize that using `make test TEST= `would fail. I?ve pushed a fix in the new commit, along with your suggested change. Thanks again!

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

PR Comment: https://git.openjdk.org/jdk/pull/26638#issuecomment-3602196652

From kbarrett at openjdk.org  Tue Dec  2 14:14:03 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 2 Dec 2025 14:14:03 GMT
Subject: RFR: 8372938: Fix reference to DeferredStatic<T> in HotSpot Style
 Guide
Message-ID: <re4DxMiOgwBWbPKHqXTXzJZeGWG0TYs-Bdyzqe_RE14=.fe7a761c-2fc6-44d2-a196-f4ccba2868b0@github.com>

Please review this trivial editorial fix to the HotSpot Style Guide.
JDK-8360458 changed the name of the utility class `Deferred<T>` to
`DeferredStatic<T>`, but forgot to update the reference to that class in the
Style Guide.

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

Commit messages:
 - fix reference

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

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

From stefank at openjdk.org  Tue Dec  2 14:24:21 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 2 Dec 2025 14:24:21 GMT
Subject: RFR: 8372938: Fix reference to DeferredStatic<T> in HotSpot Style
 Guide
In-Reply-To: <re4DxMiOgwBWbPKHqXTXzJZeGWG0TYs-Bdyzqe_RE14=.fe7a761c-2fc6-44d2-a196-f4ccba2868b0@github.com>
References: <re4DxMiOgwBWbPKHqXTXzJZeGWG0TYs-Bdyzqe_RE14=.fe7a761c-2fc6-44d2-a196-f4ccba2868b0@github.com>
Message-ID: <U3JAGHbJ5Cf61IKK3X6J4tMCwF_XfO3OYFh_7Z5outw=.880ba930-972a-4637-a708-08459d38c05f@github.com>

On Tue, 2 Dec 2025 14:05:01 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this trivial editorial fix to the HotSpot Style Guide.
> JDK-8360458 changed the name of the utility class `Deferred<T>` to
> `DeferredStatic<T>`, but forgot to update the reference to that class in the
> Style Guide.

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28602#pullrequestreview-3530393273

From epeter at openjdk.org  Tue Dec  2 15:32:58 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 2 Dec 2025 15:32:58 GMT
Subject: RFR: 8354282: C2: more crashes in compiled code because of
 dependency on removed range check CastIIs [v8]
In-Reply-To: <_rBmTvf064PXyVEAX4zqk43DNgVr0gQDPzPcdQ4XI1A=.660e7e89-0a49-47e0-9639-972cbfbac5f0@github.com>
References: <qos-VYvgreqGsB7ke35RmM3L9uHnnM6nUsm2QONKXc4=.9c902d61-5f45-41f5-8276-ac28830c2bf5@github.com>
 <qab0P8PMsV9UzIT8JqUuAixFJbzNkpjd_FCSDnVB49U=.f52c826c-480f-4330-ba68-01b22f21b044@github.com>
 <eVM0N3eEULNEo24IpZAZJVQRaTsYvigY4arq-FQkrL0=.f17e309a-430d-4daf-a397-da383c463347@github.com>
 <0An6wz0QZZxtVg-lP4IyqWTekcYkSmvosrVWkI7cH70=.86c07374-2127-4892-a369-ceefa82dd0b7@github.com>
 <_rBmTvf064PXyVEAX4zqk43DNgVr0gQDPzPcdQ4XI1A=.660e7e89-0a49-47e0-9639-972cbfbac5f0@github.com>
Message-ID: <4qc5jJ1KA09yko5rWioBGstpuuRNxOiNWXRdRdh9h_E=.17c8ace8-c672-4451-bd15-247d66d92cef@github.com>

On Tue, 2 Dec 2025 15:19:26 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Actually, I'm wondering if the term `hoistable` and `non-hoistable` would not be better terms...
>
> At least we could say that it is allowed to hoist the RangeCheck,  and the CastII could float up to where the RC is hoisted.

Suggestion:

    // Use case example: Range Check CastII
    // Floating: The Cast is only dependent on the single range check. If the range check was ever to be hoisted
    //              is would be safe to let the the Cast float to where the range check is hoisted up to.
    // Narrowing: The Cast narrows the type to a positive index. If the input to the Cast is narrower, we can safely
    //            remove the cast because the array access will be safe.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24575#discussion_r2581692285

From epeter at openjdk.org  Tue Dec  2 15:32:57 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 2 Dec 2025 15:32:57 GMT
Subject: RFR: 8354282: C2: more crashes in compiled code because of
 dependency on removed range check CastIIs [v8]
In-Reply-To: <0An6wz0QZZxtVg-lP4IyqWTekcYkSmvosrVWkI7cH70=.86c07374-2127-4892-a369-ceefa82dd0b7@github.com>
References: <qos-VYvgreqGsB7ke35RmM3L9uHnnM6nUsm2QONKXc4=.9c902d61-5f45-41f5-8276-ac28830c2bf5@github.com>
 <qab0P8PMsV9UzIT8JqUuAixFJbzNkpjd_FCSDnVB49U=.f52c826c-480f-4330-ba68-01b22f21b044@github.com>
 <eVM0N3eEULNEo24IpZAZJVQRaTsYvigY4arq-FQkrL0=.f17e309a-430d-4daf-a397-da383c463347@github.com>
 <0An6wz0QZZxtVg-lP4IyqWTekcYkSmvosrVWkI7cH70=.86c07374-2127-4892-a369-ceefa82dd0b7@github.com>
Message-ID: <_rBmTvf064PXyVEAX4zqk43DNgVr0gQDPzPcdQ4XI1A=.660e7e89-0a49-47e0-9639-972cbfbac5f0@github.com>

On Tue, 2 Dec 2025 15:17:38 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> src/hotspot/share/opto/castnode.hpp line 108:
>> 
>>> 106:     // Floating: The Cast is only dependent on the single range check.
>>> 107:     // Narrowing: The Cast narrows the type to a positive index. If the input to the Cast is narrower, we can safely
>>> 108:     //            remove the cast because the array access will be safe.
>> 
>> The "Floating" part is a bit counter intuitive here, because the ctrl of the CastII is the RangeCheck, right?
>> So is it not therefore already pinned?
>> 
>> Maybe we can add some detail about what the "floating" explicitly means here. Is it that we can later move the CastII up in an optimization?
>
> Actually, I'm wondering if the term `hoistable` and `non-hoistable` would not be better terms...

At least we could say that it is allowed to hoist the RangeCheck,  and the CastII could float up to where the RC is hoisted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24575#discussion_r2581649395

From epeter at openjdk.org  Tue Dec  2 15:32:55 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 2 Dec 2025 15:32:55 GMT
Subject: RFR: 8354282: C2: more crashes in compiled code because of
 dependency on removed range check CastIIs [v8]
In-Reply-To: <qab0P8PMsV9UzIT8JqUuAixFJbzNkpjd_FCSDnVB49U=.f52c826c-480f-4330-ba68-01b22f21b044@github.com>
References: <qos-VYvgreqGsB7ke35RmM3L9uHnnM6nUsm2QONKXc4=.9c902d61-5f45-41f5-8276-ac28830c2bf5@github.com>
 <qab0P8PMsV9UzIT8JqUuAixFJbzNkpjd_FCSDnVB49U=.f52c826c-480f-4330-ba68-01b22f21b044@github.com>
Message-ID: <eVM0N3eEULNEo24IpZAZJVQRaTsYvigY4arq-FQkrL0=.f17e309a-430d-4daf-a397-da383c463347@github.com>

On Tue, 2 Dec 2025 09:20:41 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> This is a variant of 8332827. In 8332827, an array access becomes
>> dependent on a range check `CastII` for another array access. When,
>> after loop opts are over, that RC `CastII` was removed, the array
>> access could float and an out of bound access happened. With the fix
>> for 8332827, RC `CastII`s are no longer removed.
>> 
>> With this one what happens is that some transformations applied after
>> loop opts are over widen the type of the RC `CastII`. As a result, the
>> type of the RC `CastII` is no longer narrower than that of its input,
>> the `CastII` is removed and the dependency is lost.
>> 
>> There are 2 transformations that cause this to happen:
>> 
>> - after loop opts are over, the type of the `CastII` nodes are widen
>>   so nodes that have the same inputs but a slightly different type can
>>   common.
>>   
>> - When pushing a `CastII` through an `Add`, if of the type both inputs
>>   of the `Add`s are non constant, then we end up widening the type
>>   (the resulting `Add` has a type that's wider than that of the
>>   initial `CastII`).
>>   
>> There are already 3 types of `Cast` nodes depending on the
>> optimizations that are allowed. Either the `Cast` is floating
>> (`depends_only_test()` returns `true`) or pinned. Either the `Cast`
>> can be removed if it no longer narrows the type of its input or
>> not. We already have variants of the `CastII`:
>> 
>> - if the Cast can float and be removed when it doesn't narrow the type
>> of its input.
>> 
>> - if the Cast is pinned and be removed when it doesn't narrow the type
>> of its input.
>> 
>> - if the Cast is pinned and can't be removed when it doesn't narrow
>> the type of its input.
>> 
>> What we need here, I think, is the 4th combination:
>> 
>> - if the Cast can float and can't be removed when it doesn't narrow
>> the type of its input.
>> 
>> Anyway, things are becoming confusing with all these different
>> variants named in ways that don't always help figure out what
>> constraints one of them operate under. So I refactored this and that's
>> the biggest part of this change. The fix consists in marking `Cast`
>> nodes when their type is widen in a way that prevents them from being
>> optimized out.
>> 
>> Tobias ran performance testing with a slightly different version of
>> this change and there was no regression.
>
> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - Merge branch 'master' into JDK-8354282
>  - whitespace
>  - review
>  - review
>  - Update src/hotspot/share/opto/castnode.cpp
>    
>    Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>  - Update src/hotspot/share/opto/castnode.cpp
>    
>    Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>  - Update src/hotspot/share/opto/castnode.cpp
>    
>    Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>  - Update test/hotspot/jtreg/compiler/c2/irTests/TestPushAddThruCast.java
>    
>    Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>  - review
>  - review
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/ef5e744a...93b8b0c5

src/hotspot/share/opto/castnode.hpp line 108:

> 106:     // Floating: The Cast is only dependent on the single range check.
> 107:     // Narrowing: The Cast narrows the type to a positive index. If the input to the Cast is narrower, we can safely
> 108:     //            remove the cast because the array access will be safe.

The "Floating" part is a bit counter intuitive here, because the ctrl of the CastII is the RangeCheck, right?
So is it not therefore already pinned?

Maybe we can add some detail about what the "floating" explicitly means here. Is it that we can later move the CastII up in an optimization?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24575#discussion_r2581630546

From epeter at openjdk.org  Tue Dec  2 15:32:56 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 2 Dec 2025 15:32:56 GMT
Subject: RFR: 8354282: C2: more crashes in compiled code because of
 dependency on removed range check CastIIs [v8]
In-Reply-To: <eVM0N3eEULNEo24IpZAZJVQRaTsYvigY4arq-FQkrL0=.f17e309a-430d-4daf-a397-da383c463347@github.com>
References: <qos-VYvgreqGsB7ke35RmM3L9uHnnM6nUsm2QONKXc4=.9c902d61-5f45-41f5-8276-ac28830c2bf5@github.com>
 <qab0P8PMsV9UzIT8JqUuAixFJbzNkpjd_FCSDnVB49U=.f52c826c-480f-4330-ba68-01b22f21b044@github.com>
 <eVM0N3eEULNEo24IpZAZJVQRaTsYvigY4arq-FQkrL0=.f17e309a-430d-4daf-a397-da383c463347@github.com>
Message-ID: <0An6wz0QZZxtVg-lP4IyqWTekcYkSmvosrVWkI7cH70=.86c07374-2127-4892-a369-ceefa82dd0b7@github.com>

On Tue, 2 Dec 2025 15:14:28 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
>> 
>>  - Merge branch 'master' into JDK-8354282
>>  - whitespace
>>  - review
>>  - review
>>  - Update src/hotspot/share/opto/castnode.cpp
>>    
>>    Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>>  - Update src/hotspot/share/opto/castnode.cpp
>>    
>>    Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>>  - Update src/hotspot/share/opto/castnode.cpp
>>    
>>    Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>>  - Update test/hotspot/jtreg/compiler/c2/irTests/TestPushAddThruCast.java
>>    
>>    Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>>  - review
>>  - review
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/ef5e744a...93b8b0c5
>
> src/hotspot/share/opto/castnode.hpp line 108:
> 
>> 106:     // Floating: The Cast is only dependent on the single range check.
>> 107:     // Narrowing: The Cast narrows the type to a positive index. If the input to the Cast is narrower, we can safely
>> 108:     //            remove the cast because the array access will be safe.
> 
> The "Floating" part is a bit counter intuitive here, because the ctrl of the CastII is the RangeCheck, right?
> So is it not therefore already pinned?
> 
> Maybe we can add some detail about what the "floating" explicitly means here. Is it that we can later move the CastII up in an optimization?

Actually, I'm wondering if the term `hoistable` and `non-hoistable` would not be better terms...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24575#discussion_r2581642290

From duke at openjdk.org  Tue Dec  2 15:40:49 2025
From: duke at openjdk.org (duke)
Date: Tue, 2 Dec 2025 15:40:49 GMT
Subject: Withdrawn: 8303762: Optimize vector slice operation with constant
 index using VPALIGNR instruction
In-Reply-To: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
Message-ID: <l5PQAgFY6BmG_nfiQMKIq5SUNU6vXmOmQQQZ1_u3gsQ=.0e3bb12d-fc44-4cd6-a7b1-9b71e7f557af@github.com>

On Tue, 18 Mar 2025 20:51:46 GMT, Jatin Bhateja <jbhateja at openjdk.org> 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
> VectorSliceBenchmark.shortVectorSliceWithVariableIndex     1024 ...

This pull request has been closed without being integrated.

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

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

From amitkumar at openjdk.org  Tue Dec  2 16:09:15 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Tue, 2 Dec 2025 16:09:15 GMT
Subject: RFR: 8371188: [s390x] Un-ProblemList TestUnreachableInnerLoop.java
In-Reply-To: <EfrE8Xz_4aPFgSHN2xGXPb9SJA8xrTOME9Fw8BpqWTA=.710094cc-d196-4eb8-ab53-8fdf497eb976@github.com>
References: <EfrE8Xz_4aPFgSHN2xGXPb9SJA8xrTOME9Fw8BpqWTA=.710094cc-d196-4eb8-ab53-8fdf497eb976@github.com>
Message-ID: <lOC66FAaQW2YPS2llvqZ4OXRvavH8uUSqDBOpDEJR2o=.6e6da489-2ad5-4e81-b04a-6741eda8ac16@github.com>

On Tue, 4 Nov 2025 05:10:04 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> Trivial change,
> After [JDK-8288981](https://bugs.openjdk.org/browse/JDK-8288981) delivery test is now passing on s390x. So It can be removed from the problemlist.

Owww, I forget to merge this one :(

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

PR Comment: https://git.openjdk.org/jdk/pull/28122#issuecomment-3602803880

From amitkumar at openjdk.org  Tue Dec  2 16:12:59 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Tue, 2 Dec 2025 16:12:59 GMT
Subject: Integrated: 8371188: [s390x] Un-ProblemList
 TestUnreachableInnerLoop.java
In-Reply-To: <EfrE8Xz_4aPFgSHN2xGXPb9SJA8xrTOME9Fw8BpqWTA=.710094cc-d196-4eb8-ab53-8fdf497eb976@github.com>
References: <EfrE8Xz_4aPFgSHN2xGXPb9SJA8xrTOME9Fw8BpqWTA=.710094cc-d196-4eb8-ab53-8fdf497eb976@github.com>
Message-ID: <OrpHxTLsVelcaKR24mpy7g80gvUFB9bWGmglgHR4MGc=.e2d7dfab-73c6-4fb6-95e6-7569f66e9652@github.com>

On Tue, 4 Nov 2025 05:10:04 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> Trivial change,
> After [JDK-8288981](https://bugs.openjdk.org/browse/JDK-8288981) delivery test is now passing on s390x. So It can be removed from the problemlist.

This pull request has now been integrated.

Changeset: 8d5a37b0
Author:    Amit Kumar <amitkumar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8d5a37b060dd0ecf31f71dfe82ca4a565bc7f6d9
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8371188: [s390x] Un-ProblemList TestUnreachableInnerLoop.java

Reviewed-by: aph, phubner

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

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

From epeter at openjdk.org  Tue Dec  2 16:52:30 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 2 Dec 2025 16:52:30 GMT
Subject: RFR: 8354282: C2: more crashes in compiled code because of
 dependency on removed range check CastIIs [v8]
In-Reply-To: <qab0P8PMsV9UzIT8JqUuAixFJbzNkpjd_FCSDnVB49U=.f52c826c-480f-4330-ba68-01b22f21b044@github.com>
References: <qos-VYvgreqGsB7ke35RmM3L9uHnnM6nUsm2QONKXc4=.9c902d61-5f45-41f5-8276-ac28830c2bf5@github.com>
 <qab0P8PMsV9UzIT8JqUuAixFJbzNkpjd_FCSDnVB49U=.f52c826c-480f-4330-ba68-01b22f21b044@github.com>
Message-ID: <9zey9SqquL1zLlFLuyKV_18OiZs2UQSokhREx9ln0l0=.edc15ede-e798-4d88-b61a-d2ed086d99da@github.com>

On Tue, 2 Dec 2025 09:20:41 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> This is a variant of 8332827. In 8332827, an array access becomes
>> dependent on a range check `CastII` for another array access. When,
>> after loop opts are over, that RC `CastII` was removed, the array
>> access could float and an out of bound access happened. With the fix
>> for 8332827, RC `CastII`s are no longer removed.
>> 
>> With this one what happens is that some transformations applied after
>> loop opts are over widen the type of the RC `CastII`. As a result, the
>> type of the RC `CastII` is no longer narrower than that of its input,
>> the `CastII` is removed and the dependency is lost.
>> 
>> There are 2 transformations that cause this to happen:
>> 
>> - after loop opts are over, the type of the `CastII` nodes are widen
>>   so nodes that have the same inputs but a slightly different type can
>>   common.
>>   
>> - When pushing a `CastII` through an `Add`, if of the type both inputs
>>   of the `Add`s are non constant, then we end up widening the type
>>   (the resulting `Add` has a type that's wider than that of the
>>   initial `CastII`).
>>   
>> There are already 3 types of `Cast` nodes depending on the
>> optimizations that are allowed. Either the `Cast` is floating
>> (`depends_only_test()` returns `true`) or pinned. Either the `Cast`
>> can be removed if it no longer narrows the type of its input or
>> not. We already have variants of the `CastII`:
>> 
>> - if the Cast can float and be removed when it doesn't narrow the type
>> of its input.
>> 
>> - if the Cast is pinned and be removed when it doesn't narrow the type
>> of its input.
>> 
>> - if the Cast is pinned and can't be removed when it doesn't narrow
>> the type of its input.
>> 
>> What we need here, I think, is the 4th combination:
>> 
>> - if the Cast can float and can't be removed when it doesn't narrow
>> the type of its input.
>> 
>> Anyway, things are becoming confusing with all these different
>> variants named in ways that don't always help figure out what
>> constraints one of them operate under. So I refactored this and that's
>> the biggest part of this change. The fix consists in marking `Cast`
>> nodes when their type is widen in a way that prevents them from being
>> optimized out.
>> 
>> Tobias ran performance testing with a slightly different version of
>> this change and there was no regression.
>
> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - Merge branch 'master' into JDK-8354282
>  - whitespace
>  - review
>  - review
>  - Update src/hotspot/share/opto/castnode.cpp
>    
>    Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>  - Update src/hotspot/share/opto/castnode.cpp
>    
>    Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>  - Update src/hotspot/share/opto/castnode.cpp
>    
>    Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>  - Update test/hotspot/jtreg/compiler/c2/irTests/TestPushAddThruCast.java
>    
>    Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>  - review
>  - review
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/ef5e744a...93b8b0c5

@rwestrel Nice work! We not just only fixed the bug but made the concepts much clearer. This makes me very happy ?

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

Marked as reviewed by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24575#pullrequestreview-3531172652

From epeter at openjdk.org  Tue Dec  2 16:52:32 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 2 Dec 2025 16:52:32 GMT
Subject: RFR: 8354282: C2: more crashes in compiled code because of
 dependency on removed range check CastIIs [v8]
In-Reply-To: <4qc5jJ1KA09yko5rWioBGstpuuRNxOiNWXRdRdh9h_E=.17c8ace8-c672-4451-bd15-247d66d92cef@github.com>
References: <qos-VYvgreqGsB7ke35RmM3L9uHnnM6nUsm2QONKXc4=.9c902d61-5f45-41f5-8276-ac28830c2bf5@github.com>
 <qab0P8PMsV9UzIT8JqUuAixFJbzNkpjd_FCSDnVB49U=.f52c826c-480f-4330-ba68-01b22f21b044@github.com>
 <eVM0N3eEULNEo24IpZAZJVQRaTsYvigY4arq-FQkrL0=.f17e309a-430d-4daf-a397-da383c463347@github.com>
 <0An6wz0QZZxtVg-lP4IyqWTekcYkSmvosrVWkI7cH70=.86c07374-2127-4892-a369-ceefa82dd0b7@github.com>
 <_rBmTvf064PXyVEAX4zqk43DNgVr0gQDPzPcdQ4XI1A=.660e7e89-0a49-47e0-9639-972cbfbac5f0@github.com>
 <4qc5jJ1KA09yko5rWioBGstpuuRNxOiNWXRdRdh9h_E=.17c8ace8-c672-4451-bd15-247d66d92cef@github.com>
Message-ID: <TFNSHF-AKiqE5cWd2FcbyW0akq0NNYzqYS8hLIRfXo4=.5ada81f6-b099-45d2-adf8-cbce720f0a8a@github.com>

On Tue, 2 Dec 2025 15:29:42 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> At least we could say that it is allowed to hoist the RangeCheck,  and the CastII could float up to where the RC is hoisted.
>
> Suggestion:
> 
>     // Use case example: Range Check CastII
>     // Floating: The Cast is only dependent on the single range check. If the range check was ever to be hoisted
>     //              is would be safe to let the the Cast float to where the range check is hoisted up to.
>     // Narrowing: The Cast narrows the type to a positive index. If the input to the Cast is narrower, we can safely
>     //            remove the cast because the array access will be safe.

Ok, I now read the PR from the top, and not just recent changes. If one were to start reading from the top, it would be clear without my suggestions here. But I think it could still be good to apply something about letting the Cast float to where we would hoist the RC.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24575#discussion_r2582034834

From jsjolen at openjdk.org  Tue Dec  2 16:53:33 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 2 Dec 2025 16:53:33 GMT
Subject: RFR: 8372938: Fix reference to DeferredStatic<T> in HotSpot Style
 Guide
In-Reply-To: <re4DxMiOgwBWbPKHqXTXzJZeGWG0TYs-Bdyzqe_RE14=.fe7a761c-2fc6-44d2-a196-f4ccba2868b0@github.com>
References: <re4DxMiOgwBWbPKHqXTXzJZeGWG0TYs-Bdyzqe_RE14=.fe7a761c-2fc6-44d2-a196-f4ccba2868b0@github.com>
Message-ID: <7gkQ-kKU65EJKOZFPTS2rFhYyVmFwPITfVotM90xlh8=.fcb6522c-bcee-4033-9472-4def3ffa46f7@github.com>

On Tue, 2 Dec 2025 14:05:01 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this trivial editorial fix to the HotSpot Style Guide.
> JDK-8360458 changed the name of the utility class `Deferred<T>` to
> `DeferredStatic<T>`, but forgot to update the reference to that class in the
> Style Guide.

Marked as reviewed by jsjolen (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28602#pullrequestreview-3531177588

From liach at openjdk.org  Tue Dec  2 17:17:44 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 2 Dec 2025 17:17:44 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v5]
In-Reply-To: <r4etVDZnERk-bUlx-6uMtxP03xvMa0a51MnBlA7eIz0=.4e16178f-517a-400e-a7bf-0a890664aa2c@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
 <r4etVDZnERk-bUlx-6uMtxP03xvMa0a51MnBlA7eIz0=.4e16178f-517a-400e-a7bf-0a890664aa2c@github.com>
Message-ID: <jWgxAVYx6nsm4W7dxhRb7zwV-a5oKYyjRUUnvWbU99A=.887e5b6e-4123-4cf7-b5b3-917ccbfe5d91@github.com>

On Mon, 1 Dec 2025 15:02:50 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> ArrayKlass doesn't set AccessFlags so don't look for them there.  See CR for details.
>> Fixed SA and jvmci.  @iwanowww Can you check that I changed C2 correctly (we talked about this in August).
>> Tested with tier1-4.  5-7 in progress.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added a comment for checking interface guard after array guard.

src/hotspot/share/classfile/javaClasses.cpp line 1096:

> 1094:   // Set the raw access_flags, this is used by reflection instead of modifier flags.
> 1095:   // The Java code for array classes gets the access flags from the element type.
> 1096:   set_raw_access_flags(mirror(), k->is_array_klass() ? 0 : InstanceKlass::cast(k)->access_flags().as_unsigned_short());

Should we merge this is_array_klass() query with the main if-else block below? We can probably skip setting raw access flags for array classes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28371#discussion_r2578581321

From liach at openjdk.org  Tue Dec  2 17:27:43 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 2 Dec 2025 17:27:43 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v3]
In-Reply-To: <hzq42574wKnkKeZcBGJ-aOSY5hVrpoUKM8t25GMibxg=.b7728079-a9f7-4b35-8150-a94110d8e698@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <eXO79ZBlZUltqddmReHLTSFSr3x8PiH0a5s740GHrfk=.5cf01f8f-7ac5-4def-b17d-dfd6f10e9614@github.com>
 <hzq42574wKnkKeZcBGJ-aOSY5hVrpoUKM8t25GMibxg=.b7728079-a9f7-4b35-8150-a94110d8e698@github.com>
Message-ID: <kOkb_9GWTlrv8dTymEXOvlbPw9fuoemDMn9dAZWNrOE=.0affa2da-5dd2-495d-a4ec-d348a00c7f92@github.com>

On Tue, 2 Dec 2025 09:28:03 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Tweak VH usage in some classes
>
> src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2036:
> 
>> 2034:             var constant = MethodHandleImpl.isCompileConstant(vh);
>> 2035:             var cache = adaptedMh;
>> 2036:             if (constant == MethodHandleImpl.CONSTANT_YES && cache != null) {
> 
> Rookie question: Is there multi-thread considerations here? How about visibility across threads?

MethodHandle is immutable and can be safely published. So this is ok.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2582166754

From kvn at openjdk.org  Tue Dec  2 17:34:58 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 2 Dec 2025 17:34:58 GMT
Subject: RFR: 8371046: Segfault in
 compiler/whitebox/StressNMethodRelocation.java with -XX:+UseZGC
In-Reply-To: <k0-Cr7yor3F4OKDiZdT3lIrFiSgI_YRCR8_FphgQmlk=.4f60b60e-127d-413e-ab8f-26d6c4911142@github.com>
References: <k0-Cr7yor3F4OKDiZdT3lIrFiSgI_YRCR8_FphgQmlk=.4f60b60e-127d-413e-ab8f-26d6c4911142@github.com>
Message-ID: <Wp26yu5-XzxQu263XG8F_ulOdo052Z1ljoN8kQVhkAk=.5ad009c7-570b-4c26-aa25-27ef6a3ac3a9@github.com>

On Tue, 11 Nov 2025 17:32:22 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

> [JDK-8371046](https://bugs.openjdk.org/browse/JDK-8371046)
> 
> This pull request fixes two crashes (see below) and adds `InvalidationReason::RELOCATED` to better describe why an nmethod is marked not entrant during relocation.
> 
> ---
> 
> #### 1. Test Bug
> 
> It?s possible for an `nmethod` to be unloaded without its `_state` being explicitly set to `not_entrant`. Checking only `is_in_use()` isn?t sufficient, since the `nmethod` may already be in the process of unloading and therefore may not have a lock (as with ZGC, where `nmethods` are locked individually).
> 
> The fix adds an additional `is_unloading()` check in WhiteBox before acquiring the lock.
> 
> This issue was reproducible fairly consistently (every few runs) by executing `compiler/whitebox/StressNMethodRelocation.java` with  `-XX:+UseZGC -XX:ReservedCodeCacheSize=32m`
> 
> 
> After applying this patch, the original crash stopped occurring, though a more infrequent crash was still observed.
> 
> ---
> 
> #### 2. Implementation Bug
> 
> `nmethod::relocate` works by copying the instructions of an `nmethod` and then adjusting the call sites to account for new PC-relative offsets.
> 
> Previously, this fix-up happened *after* calling `post_init()`, which registers the `nmethod` and makes it visible to the GC. This introduced a race condition where the GC might attempt to resolve a call site before it had been fixed.
> 
> The fix ensures that all call sites are patched **before** the `nmethod` is registered.
> 
> In testing, the crash previously occurred roughly 60 times in 5,000 runs (~1.2%). With this patch, no crashes were observed in the same number of runs.

>> May be we should change the assert to guarantee in Relocation::pd_set_call_destination() to make sure we catch incorrect patching it product VM.

> I'm not opposed to changing this. Is this the main concern?

Yes, my main concern is that new encoding of address in cloned nmethod may not fit into existing instructions set.
At least with guarantee we can catch such case if it happened.

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

PR Comment: https://git.openjdk.org/jdk/pull/28241#issuecomment-3603204728

From epeter at openjdk.org  Tue Dec  2 17:38:59 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 2 Dec 2025 17:38:59 GMT
Subject: RFR: 8351889: C2 crash: assertion failed:  Base pointers must
 match (addp 344) [v3]
In-Reply-To: <NMucu_GC8vtOE1MuRuOTc7O4XvT7zd2BZd6aUtsiWKc=.9ea42b69-88d4-4c98-8744-2e50a48c953c@github.com>
References: <IKOYjLXrS8q1GMjbaL2HOBNH8Oa_16k4WBa2NaMngS8=.c6fd7fbb-4758-48b2-a992-3702b2718e59@github.com>
 <ONE3vyWC8GljgqXTIbv_TemwWjzn9DTxLjAvkqStoLo=.9dda8b80-111f-45b3-b5ca-b95b4006ec40@github.com>
 <ypRdomeJ0LQEaKDzdHWTd5q8yiYXACmZg5JZFx2qppc=.bcf175ca-8f1c-4e6b-b6d2-b161e219b4f9@github.com>
 <NMucu_GC8vtOE1MuRuOTc7O4XvT7zd2BZd6aUtsiWKc=.9ea42b69-88d4-4c98-8744-2e50a48c953c@github.com>
Message-ID: <sWDzICwDw6TZ76nd1s2BBfdzJGLr6JvvvC13fzJky1o=.2f31ca1c-ed17-43cf-a0b2-a012e5e00af9@github.com>

On Tue, 2 Dec 2025 09:46:05 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> src/hotspot/share/opto/phaseX.cpp line 2085:
>> 
>>> 2083:   }
>>> 2084:   return false;
>>> 2085: }
>> 
>> Why not call it `verify_node_invariants_for`?
>> 
>> You should also assert immediately. @benoitmaillard Is about to make that change for everything: https://github.com/openjdk/jdk/pull/28295
>
> That one is not integrated. Shouldn't I do that change only if it/when integrates?

Right, keep it, just be informed, it may get integrated soon :)

Renaming would still be good ;)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25386#discussion_r2582199486

From qamai at openjdk.org  Tue Dec  2 17:48:43 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 2 Dec 2025 17:48:43 GMT
Subject: RFR: 8354282: C2: more crashes in compiled code because of
 dependency on removed range check CastIIs [v8]
In-Reply-To: <qab0P8PMsV9UzIT8JqUuAixFJbzNkpjd_FCSDnVB49U=.f52c826c-480f-4330-ba68-01b22f21b044@github.com>
References: <qos-VYvgreqGsB7ke35RmM3L9uHnnM6nUsm2QONKXc4=.9c902d61-5f45-41f5-8276-ac28830c2bf5@github.com>
 <qab0P8PMsV9UzIT8JqUuAixFJbzNkpjd_FCSDnVB49U=.f52c826c-480f-4330-ba68-01b22f21b044@github.com>
Message-ID: <m1ysk4e8E_cBjRPbnGy9d4UxXjG8SDh2JICWwd2zVRI=.cefc4dd5-ef0a-42ae-9e62-45295ab4bebc@github.com>

On Tue, 2 Dec 2025 09:20:41 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> This is a variant of 8332827. In 8332827, an array access becomes
>> dependent on a range check `CastII` for another array access. When,
>> after loop opts are over, that RC `CastII` was removed, the array
>> access could float and an out of bound access happened. With the fix
>> for 8332827, RC `CastII`s are no longer removed.
>> 
>> With this one what happens is that some transformations applied after
>> loop opts are over widen the type of the RC `CastII`. As a result, the
>> type of the RC `CastII` is no longer narrower than that of its input,
>> the `CastII` is removed and the dependency is lost.
>> 
>> There are 2 transformations that cause this to happen:
>> 
>> - after loop opts are over, the type of the `CastII` nodes are widen
>>   so nodes that have the same inputs but a slightly different type can
>>   common.
>>   
>> - When pushing a `CastII` through an `Add`, if of the type both inputs
>>   of the `Add`s are non constant, then we end up widening the type
>>   (the resulting `Add` has a type that's wider than that of the
>>   initial `CastII`).
>>   
>> There are already 3 types of `Cast` nodes depending on the
>> optimizations that are allowed. Either the `Cast` is floating
>> (`depends_only_test()` returns `true`) or pinned. Either the `Cast`
>> can be removed if it no longer narrows the type of its input or
>> not. We already have variants of the `CastII`:
>> 
>> - if the Cast can float and be removed when it doesn't narrow the type
>> of its input.
>> 
>> - if the Cast is pinned and be removed when it doesn't narrow the type
>> of its input.
>> 
>> - if the Cast is pinned and can't be removed when it doesn't narrow
>> the type of its input.
>> 
>> What we need here, I think, is the 4th combination:
>> 
>> - if the Cast can float and can't be removed when it doesn't narrow
>> the type of its input.
>> 
>> Anyway, things are becoming confusing with all these different
>> variants named in ways that don't always help figure out what
>> constraints one of them operate under. So I refactored this and that's
>> the biggest part of this change. The fix consists in marking `Cast`
>> nodes when their type is widen in a way that prevents them from being
>> optimized out.
>> 
>> Tobias ran performance testing with a slightly different version of
>> this change and there was no regression.
>
> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - Merge branch 'master' into JDK-8354282
>  - whitespace
>  - review
>  - review
>  - Update src/hotspot/share/opto/castnode.cpp
>    
>    Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>  - Update src/hotspot/share/opto/castnode.cpp
>    
>    Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>  - Update src/hotspot/share/opto/castnode.cpp
>    
>    Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>  - Update test/hotspot/jtreg/compiler/c2/irTests/TestPushAddThruCast.java
>    
>    Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>  - review
>  - review
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/ef5e744a...93b8b0c5

src/hotspot/share/opto/castnode.hpp line 105:

> 103:     // All the possible combinations of floating/narrowing with example use cases:
> 104: 
> 105:     // Use case example: Range Check CastII

I believe this is incorrect, a range check should be floating non-narrowing. It is only narrowing if the length of the array is a constant. It is because this cast encodes the dependency on the condition `index u< length`. This condition cannot be expressed in terms of `Type` unless `length` is a constant.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24575#discussion_r2582188782

From qamai at openjdk.org  Tue Dec  2 17:48:44 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 2 Dec 2025 17:48:44 GMT
Subject: RFR: 8354282: C2: more crashes in compiled code because of
 dependency on removed range check CastIIs [v8]
In-Reply-To: <TFNSHF-AKiqE5cWd2FcbyW0akq0NNYzqYS8hLIRfXo4=.5ada81f6-b099-45d2-adf8-cbce720f0a8a@github.com>
References: <qos-VYvgreqGsB7ke35RmM3L9uHnnM6nUsm2QONKXc4=.9c902d61-5f45-41f5-8276-ac28830c2bf5@github.com>
 <qab0P8PMsV9UzIT8JqUuAixFJbzNkpjd_FCSDnVB49U=.f52c826c-480f-4330-ba68-01b22f21b044@github.com>
 <eVM0N3eEULNEo24IpZAZJVQRaTsYvigY4arq-FQkrL0=.f17e309a-430d-4daf-a397-da383c463347@github.com>
 <0An6wz0QZZxtVg-lP4IyqWTekcYkSmvosrVWkI7cH70=.86c07374-2127-4892-a369-ceefa82dd0b7@github.com>
 <_rBmTvf064PXyVEAX4zqk43DNgVr0gQDPzPcdQ4XI1A=.660e7e89-0a49-47e0-9639-972cbfbac5f0@github.com>
 <4qc5jJ1KA09yko5rWioBGstpuuRNxOiNWXRdRdh9h_E=.17c8ace8-c672-4451-bd15-247d66d92cef@github.com>
 <TFNSHF-AKiqE5cWd2FcbyW0akq0NNYzqYS8hLIRfXo4=.5ada81f6-b099-45d2-adf8-cbce720f0a8a@github.com>
Message-ID: <Cc4kPMFfdFtp_BbY0vKneM2Vfk0R6MWSPDHr7IPTXbk=.3bfa561b-cfee-43e2-a7c0-3111a4fbd0db@github.com>

On Tue, 2 Dec 2025 16:48:55 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Suggestion:
>> 
>>     // Use case example: Range Check CastII
>>     // Floating: The Cast is only dependent on the single range check. If the range check was ever to be hoisted
>>     //           it would be safe to let the the Cast float to where the range check is hoisted up to.
>>     // Narrowing: The Cast narrows the type to a positive index. If the input to the Cast is narrower, we can safely
>>     //            remove the cast because the array access will be safe.
>
> Ok, I now read the PR from the top, and not just recent changes. If one were to start reading from the top, it would be clear without my suggestions here. But I think it could still be good to apply something about letting the Cast float to where we would hoist the RC.

Naming is hard, but it is worth pointing out in the comment that floating here refers to `depends_only_on_test`. In other words, a cast is considered floating if it is legal to change the control input of a cast from an `IfTrue` or `IfFalse` to an `IfTrue` and `IfFalse` that dominates the current control input, and the corresponding conditions of the `If`s are the same. In contrast, we cannot do that for a pinned cast, and if the control is folded away, the control input of the pinned cast is changed to the control predecessor of the folded node.

It is also worth noting that we have `Node::pinned` which means the node is pinned AT the control input while pinned here means that it is pinned UNDER the control input. Very confusing!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24575#discussion_r2582215477

From dlong at openjdk.org  Tue Dec  2 18:17:03 2025
From: dlong at openjdk.org (Dean Long)
Date: Tue, 2 Dec 2025 18:17:03 GMT
Subject: RFR: 8371306: JDK-8367002 behavior might not match existing
 HotSpot behavior.
In-Reply-To: <5975FvnIp_w-TSIVgdYCwMXCQKrjZY8VEZvJnV89LdY=.32729efa-aa64-4b2a-b321-aedc3fd5720c@github.com>
References: <6Rlv3LqIljnMFAoDX1kgGT1hWCVGgU-UNS-UOYIpNrU=.760472eb-f9ab-415f-8618-e596b0d50c7b@github.com>
 <5975FvnIp_w-TSIVgdYCwMXCQKrjZY8VEZvJnV89LdY=.32729efa-aa64-4b2a-b321-aedc3fd5720c@github.com>
Message-ID: <M_VXR7HRi0ZrSfgQZqVvNkx7K-N-WZ20cB5QRAn6g0o=.8ed2353f-38a6-45e4-b17b-820ca335a9a6@github.com>

On Tue, 2 Dec 2025 12:34:49 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> When deoptimizing to the interpreter, we need to restore the thrown exception to the original, otherwise it might be caught by the wrong handler.  In the test case, that means restoring the original ArithmeticException instead of keeping the new/recursive IllegalAccessError.
>
> Looks good to me but I'm not an expert in this area.

Thanks @TobiHartmann .

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

PR Comment: https://git.openjdk.org/jdk/pull/28497#issuecomment-3603349515

From dlong at openjdk.org  Tue Dec  2 18:17:05 2025
From: dlong at openjdk.org (Dean Long)
Date: Tue, 2 Dec 2025 18:17:05 GMT
Subject: RFR: 8371306: JDK-8367002 behavior might not match existing
 HotSpot behavior.
In-Reply-To: <6Rlv3LqIljnMFAoDX1kgGT1hWCVGgU-UNS-UOYIpNrU=.760472eb-f9ab-415f-8618-e596b0d50c7b@github.com>
References: <6Rlv3LqIljnMFAoDX1kgGT1hWCVGgU-UNS-UOYIpNrU=.760472eb-f9ab-415f-8618-e596b0d50c7b@github.com>
Message-ID: <NjYt1DQ9AU6DHMB4RFkv1Y28n2H4ADiR5DuYQ4YEDWw=.85bb49b5-0fe4-43b0-81a4-e661c43ec93f@github.com>

On Tue, 25 Nov 2025 18:24:42 GMT, Dean Long <dlong at openjdk.org> wrote:

> When deoptimizing to the interpreter, we need to restore the thrown exception to the original, otherwise it might be caught by the wrong handler.  In the test case, that means restoring the original ArithmeticException instead of keeping the new/recursive IllegalAccessError.

Any volunteers for a 2nd review?

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

PR Comment: https://git.openjdk.org/jdk/pull/28497#issuecomment-3603358306

From sspitsyn at openjdk.org  Tue Dec  2 19:23:36 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 2 Dec 2025 19:23:36 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v7]
In-Reply-To: <lyWK2X4EtG3Rq45neyn16-wytK0CVi82blyrj2JGsd4=.28c7a6b0-bcac-4259-a58e-7f721a545a26@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
 <lyWK2X4EtG3Rq45neyn16-wytK0CVi82blyrj2JGsd4=.28c7a6b0-bcac-4259-a58e-7f721a545a26@github.com>
Message-ID: <jIkEaDMteTFFqiLzQZf0oYVca3qbQINS-ajPn_Zb500=.288bc4d3-e0ad-4d65-882f-1ed3fe6968e8@github.com>

On Tue, 2 Dec 2025 13:24:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> ArrayKlass doesn't set AccessFlags so don't look for them there.  See CR for details.
>> Fixed SA and jvmci.  @iwanowww Can you check that I changed C2 correctly (we talked about this in August).
>> Tested with tier1-4.  5-7 in progress.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed indentation.

Marked as reviewed by sspitsyn (Reviewer).

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java line 101:

> 99:     }
> 100:     headerSize           = type.getSize();
> 101:     accessFlags  = new CIntField(type.getCIntegerField("_access_flags"), 0);

Nit: Not a big deal but this line also does not have proper indent. You can ignore this comment though. :)

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

PR Review: https://git.openjdk.org/jdk/pull/28371#pullrequestreview-3531778810
PR Review Comment: https://git.openjdk.org/jdk/pull/28371#discussion_r2582521355

From serb at openjdk.org  Tue Dec  2 20:09:57 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 2 Dec 2025 20:09:57 GMT
Subject: RFR: 8371893: [macOS] use dead_strip linker option to reduce
 binary size [v5]
In-Reply-To: <AGacEUKglaOEHAh2He4z3f3sXfJjimF8q-2yzLRnlhM=.c14c4fce-8f81-4eb0-8be3-c87caab5f74a@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
 <AGacEUKglaOEHAh2He4z3f3sXfJjimF8q-2yzLRnlhM=.c14c4fce-8f81-4eb0-8be3-c87caab5f74a@github.com>
Message-ID: <_m-3bjxRDcMxOBa8umyAmvqWzz7VZYMZ8RKVwtaoWPU=.91da4b9b-84b0-47ff-9bf3-93c07dcfd79d@github.com>

On Tue, 25 Nov 2025 13:12:06 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols.
>> Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) :
>> (before -> after setting the option)
>> 
>> 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib
>> 264K -> 248K images/jdk/lib/libjavajpeg.dylib
>> 152K -> 132K images/jdk/lib/libjli.dylib
>> 388K -> 296K images/jdk/lib/liblcms.dylib
>> 164K -> 128K images/jdk/lib/libzip.dylib
>> 
>> 
>> and libjvm :
>> 
>> 20M -> 18M images/jdk/lib/server/libjvm.dylib
>> 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use dead_strip on macOS arrch64 AND x86_64

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28319#pullrequestreview-3531919314

From mbaesken at openjdk.org  Tue Dec  2 20:09:59 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 2 Dec 2025 20:09:59 GMT
Subject: RFR: 8371893: [macOS] use dead_strip linker option to reduce
 binary size [v5]
In-Reply-To: <kfLZ6HfvR5BCrqUZ9UwU4fa9ty3oFTh8Lk1DqtLtqJI=.d2b1a347-0806-497a-92a5-a3ce154d1df9@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
 <AGacEUKglaOEHAh2He4z3f3sXfJjimF8q-2yzLRnlhM=.c14c4fce-8f81-4eb0-8be3-c87caab5f74a@github.com>
 <5xGU22WgiZiCJGUU3G3e1-SAty0aXnjzEbj3nx30y5c=.337ef8d2-e79e-477f-916c-a344079370a9@github.com>
 <kfLZ6HfvR5BCrqUZ9UwU4fa9ty3oFTh8Lk1DqtLtqJI=.d2b1a347-0806-497a-92a5-a3ce154d1df9@github.com>
Message-ID: <LQWUU4Wzs1jdDOtDwk3sa7jCYVtrCsbYYi7C6Hn0Nag=.f3270d75-b27c-4098-aa97-27ff1229e8d1@github.com>

On Wed, 26 Nov 2025 11:17:59 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> I'll run UI the tests for this.

Are there some (hopefully good) results from your runs ? 
Would prefer to get some feedback from you before integrating.

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

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3596355336

From serb at openjdk.org  Tue Dec  2 20:10:00 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 2 Dec 2025 20:10:00 GMT
Subject: RFR: 8371893: [macOS] use dead_strip linker option to reduce
 binary size [v5]
In-Reply-To: <LQWUU4Wzs1jdDOtDwk3sa7jCYVtrCsbYYi7C6Hn0Nag=.f3270d75-b27c-4098-aa97-27ff1229e8d1@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
 <AGacEUKglaOEHAh2He4z3f3sXfJjimF8q-2yzLRnlhM=.c14c4fce-8f81-4eb0-8be3-c87caab5f74a@github.com>
 <5xGU22WgiZiCJGUU3G3e1-SAty0aXnjzEbj3nx30y5c=.337ef8d2-e79e-477f-916c-a344079370a9@github.com>
 <kfLZ6HfvR5BCrqUZ9UwU4fa9ty3oFTh8Lk1DqtLtqJI=.d2b1a347-0806-497a-92a5-a3ce154d1df9@github.com>
 <LQWUU4Wzs1jdDOtDwk3sa7jCYVtrCsbYYi7C6Hn0Nag=.f3270d75-b27c-4098-aa97-27ff1229e8d1@github.com>
Message-ID: <ingxF5gHqbgOHmv9Va3Kbmcalz9CluE5PhVqv2lhFdM=.8c93a7de-9f05-422f-b218-954c9d2ab603@github.com>

On Mon, 1 Dec 2025 12:39:58 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Are there some (hopefully good) results from your runs ? Would prefer to get some feedback from you before integrating.

I did not find any issues in the jtreg desktop tests (headful/headless).

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

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3603763411

From pchilanomate at openjdk.org  Tue Dec  2 20:12:47 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 2 Dec 2025 20:12:47 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v11]
In-Reply-To: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
Message-ID: <URdOE6ZdBSqYc7LrGrVReCSpFh-KVt0IuuC8TIyfsJw=.b98e6ea7-1b29-487d-bf93-0aaf7259cc3c@github.com>

> 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 terms of mount and un...

Patricio Chilano Mateo 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:

 - 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
 - David's comments
 - Rename VM methods for endFirstTransition/startFinalTransition
 - ... and 3 more: https://git.openjdk.org/jdk/compare/836ae793...1f1cd594

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28361/files
  - new: https://git.openjdk.org/jdk/pull/28361/files/44af0ca9..1f1cd594

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28361&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28361&range=09-10

  Stats: 84290 lines in 1350 files changed: 54871 ins; 20868 del; 8551 mod
  Patch: https://git.openjdk.org/jdk/pull/28361.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28361/head:pull/28361

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

From pchilanomate at openjdk.org  Tue Dec  2 20:12:49 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 2 Dec 2025 20:12:49 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v10]
In-Reply-To: <U0XMaJ4ujyejqeQTvz4l7ZwUf2IWRPWKZj3ptQMSOBs=.5ec74fa7-bff5-4220-9916-02209c34dbc9@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <T8jvz_3r2GJ8W55gqHXsRkNhMPRy3hLGF7ClwP84CM0=.c69c727e-6628-4aa2-92ca-e596542cf0e0@github.com>
 <U0XMaJ4ujyejqeQTvz4l7ZwUf2IWRPWKZj3ptQMSOBs=.5ec74fa7-bff5-4220-9916-02209c34dbc9@github.com>
Message-ID: <PP54KIhtKoCuuWU8YMqeEzY-p2NK8sI_6cUuGfE7-II=.2aa2a463-aba8-460b-b1eb-97d179e69ec7@github.com>

On Tue, 2 Dec 2025 06:20:44 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Nothing further from me. Again a great piece of work!
> 
> Thanks
>
Thanks for the review David!

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

PR Comment: https://git.openjdk.org/jdk/pull/28361#issuecomment-3603774217

From pchilanomate at openjdk.org  Tue Dec  2 20:20:32 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 2 Dec 2025 20:20:32 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v11]
In-Reply-To: <jw0XiQQN7uLuurYCvcroRUTtpvzKYgKXpU1_lKcRWMo=.d06cff86-674b-4f54-951e-c83867e79f43@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <FPqDAUXw_1ZtwQLFHIgv1HAANXJn4kCHtofPMhG_gmw=.c05ba258-723f-4abc-b35a-ca29f02a4df5@github.com>
 <jFNO_Y3Ag0QIDP4INNnPUNDYjcoGHFZ83C3mebo7o9U=.dc183f1f-5f99-479f-832c-8af9c4fcf72a@github.com>
 <nW9xOi2sq3K_3ZpNyvvgzUf2p0roZU8hkKxcEtvK1nI=.03abf855-5f7b-4055-972c-8cff69df3816@github.com>
 <jw0XiQQN7uLuurYCvcroRUTtpvzKYgKXpU1_lKcRWMo=.d06cff86-674b-4f54-951e-c83867e79f43@github.com>
Message-ID: <X2XiyWz5DzOg4pXBxrYeCA_f2V3WNM2Rn58dZRhUOuw=.43b6aa7c-6533-49ce-adc6-93c6e397ed8f@github.com>

On Mon, 1 Dec 2025 19:46:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I renamed the methods as suggested. I remembered that we separated ThreadStart/ThreadEnd in 8306028 for future improvements related to JVMTI. Not sure if that?s still relevant but in any case probably better to leave that discussion for a separate bug.
>
> Given the comment block to define the terms "mount transition" and "unmount transition" then we could go a bit further and make it 6 methods: start/endMountTransition, start/endUnmountTransition, endFirstMountTransition and  startLastUnmountTransition. We don't have to do it now, but it would make the use-sites clearer I think.

Sounds good, filed https://bugs.openjdk.org/browse/JDK-8372953.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2582659743

From pchilanomate at openjdk.org  Tue Dec  2 20:20:30 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 2 Dec 2025 20:20:30 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v10]
In-Reply-To: <P9Too5Wi39kpbuKEdC6zi1AaV_gEdwV769JRMtd2Fz8=.10605426-19ce-45cc-a9de-47aaea2b118e@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <T8jvz_3r2GJ8W55gqHXsRkNhMPRy3hLGF7ClwP84CM0=.c69c727e-6628-4aa2-92ca-e596542cf0e0@github.com>
 <P9Too5Wi39kpbuKEdC6zi1AaV_gEdwV769JRMtd2Fz8=.10605426-19ce-45cc-a9de-47aaea2b118e@github.com>
Message-ID: <5iEOi2ZO_ZVQbanlfWXhjIyGMQvZ4rt09LIK9YP-bgg=.5d15e13d-81cc-4843-bdb2-244841949808@github.com>

On Tue, 2 Dec 2025 08:15:53 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix comment in inline_native_vthread_start_transition
>
> src/hotspot/share/runtime/mountUnmountDisabler.cpp line 88:
> 
>> 86:         // We rebinded on start_transition but the mount/unmount operation
>> 87:         // failed so now we need to rebind to the original state.
>> 88:         _current->rebind_to_jvmti_thread_state_of(_is_mount ? _vthread() : _current->threadObj());
> 
> Q: Not sure I fully understand this comment. We have done a rebind at the line 67 for an unmount transition only. But this comment tells that it was done for mount transition as well. Also, before this update, we used to do a rebind of `JvmtiThreadState` to a vthread in the `JvmtiVTMSTransitionDisabler::VTMS_mount_end()` for the normal (not failed) case. Please, could you explain a little bit more? It feels like this comment needs a correction.

Yes, well spotted. I changed it to rebind the state only for the mount case, as in current code. This already handles a successful mount or a failed unmount. I also added and assert to verify we rebinded to the correct identity.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2582654454

From vlivanov at openjdk.org  Tue Dec  2 20:21:29 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 2 Dec 2025 20:21:29 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v3]
In-Reply-To: <ogD0Gl3QSb1pLJUqOn877wI6asY5TW0MV7mPFlNXM5A=.8af15b77-010a-4d34-901b-928c4a3fe425@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <eXO79ZBlZUltqddmReHLTSFSr3x8PiH0a5s740GHrfk=.5cf01f8f-7ac5-4def-b17d-dfd6f10e9614@github.com>
 <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com>
 <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com>
 <M5yxETmdJBlueGf6KC7P8oSAZIEeiSu8rOHAoIxu0sc=.4bc347cb-40d5-4432-bc94-38a59730183d@github.com>
 <3OE37qXGHhLAhnRQM188hhygrLYBtI3FLBMK0tGVH30=.5d1b4406-3bb3-4788-8059-e78260b79ec1@github.com>
 <kZDurlwNJsrYZRbeHLXVTKqUQcW2QGFGLE-WNN-vz4o=.44bc4d21-cc9d-4d94-b40c-4b6ad9ab11aa@github.com>
 <7WF8DlorrU_B2__G2wr43w1PZwJh8mEhD5dY10YDIOo=.ec416c38-1aff-4dd6-8792-d6a0e01f91ce@github.com>
 <E7Lwc7nwEvsmQhLMYT5Ruj5j7BhVDcfyBRUfhinUyzQ=.3293c6f1-6ce4-47d8-aa48-ba9c69ba60eb@github.com>
 <ogD0Gl3QSb1pLJUqOn877wI6asY5TW0MV7mPFlNXM5A=.8af15b77-010a-4d34-901b-928c4a3fe425@github.com>
Message-ID: <_Z6KpxCYH2n3sHuT6-kRP4cSTAN3-s5UA0rbfrJSIgA=.e9d4089c-8329-406b-9a0a-167a24311c13@github.com>

On Tue, 2 Dec 2025 02:51:57 GMT, Chen Liang <liach at openjdk.org> wrote:

>> So, it seems like what you are trying to achieve is a 1-1 mapping from `AccessDescriptor` to `vh` through `adaptedMh`. So, once `cache != null` you can trust that it corresponds to the `vh` instance passed as a constant. But cache pollution can easily break the invariant, so you try to eliminate the pollution by avoiding cache updates when vh is not constant. Do I get it right?
>
> No. The avoidance of cache update simply trims down the generated code by throwing away the meaningless cache update.
> 
> The access to cache is already safeguarded by `constant == MethodHandleImpl.CONSTANT_YES`. I should have moved `var cache = adaptedMh;` into the if block of `constant == CONSTANT_YES`.

I still find it confusing, especially tri-state logic part.

For background, `isCompileConstant` was introduced as part of LF sharing effort to get rid of Java-level profiling in optimized code. The pattern is was designed for was:

  if (isCompileConstant(...)) {
    return ...;
  } else {
    ... // do some extra work (either in interpreter, C1, or not-fully-optimized version in C2) 
  }


In this patch, you don't follow that pattern and aadd new state (`CONSTANT_PENDING`) to distinguish interpreter/C1 from C2. What's the motivation? Why do you want to avoid cache updates coming from C2-generated code?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2582647097

From vlivanov at openjdk.org  Tue Dec  2 20:21:33 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 2 Dec 2025 20:21:33 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v3]
In-Reply-To: <eXO79ZBlZUltqddmReHLTSFSr3x8PiH0a5s740GHrfk=.5cf01f8f-7ac5-4def-b17d-dfd6f10e9614@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <eXO79ZBlZUltqddmReHLTSFSr3x8PiH0a5s740GHrfk=.5cf01f8f-7ac5-4def-b17d-dfd6f10e9614@github.com>
Message-ID: <WB3aHVk-aSxkuKL1H7QacVuQDMhbeiSdmXBMH_-6hKE=.f108b496-55dc-4a7d-97e4-31893fef2c7e@github.com>

On Mon, 1 Dec 2025 23:41:04 GMT, Chen Liang <liach at openjdk.org> 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:
> 
>   Tweak VH usage in some classes

src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2042:

> 2040:             // This is still a hot path if vh is not constant - in this case,
> 2041:             // asType is the bottleneck for constant folding, unfortunately
> 2042:             var result = vh.getMethodHandle(mode).asType(symbolicMethodTypeInvoker);

`mode` and `symbolicMethodTypeInvoker` are part of `AccessDescriptor` while `vh` comes as an argument. What guarantees that a cached adapter is compatible with `vh` observed during subsequent calls? It means that `vh` shape stays exactly the same shape. Is it correct? Would be good to have it validated with asserts.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2582661917

From sspitsyn at openjdk.org  Tue Dec  2 20:31:30 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 2 Dec 2025 20:31:30 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v11]
In-Reply-To: <URdOE6ZdBSqYc7LrGrVReCSpFh-KVt0IuuC8TIyfsJw=.b98e6ea7-1b29-487d-bf93-0aaf7259cc3c@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <URdOE6ZdBSqYc7LrGrVReCSpFh-KVt0IuuC8TIyfsJw=.b98e6ea7-1b29-487d-bf93-0aaf7259cc3c@github.com>
Message-ID: <JMq7LxVJ7_B1ypy-DDaeTJMKGO_9VPvQiWqb2JUkLAY=.3eea6f9e-723a-42c2-aa1b-6d6dab0f3279@github.com>

On Tue, 2 Dec 2025 20:12:47 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> 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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
> 
>  - 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
>  - David's comments
>  - Rename VM methods for endFirstTransition/startFinalTransition
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/4b22489c...1f1cd594

Marked as reviewed by sspitsyn (Reviewer).

Yes, this is a great work!

src/hotspot/share/runtime/mountUnmountDisabler.cpp line 87:

> 85:       }
> 86:       DEBUG_ONLY(bool is_virtual = java_lang_VirtualThread::is_instance(_current->jvmti_vthread()));
> 87:       assert((_is_mount && is_virtual) || (!_is_mount && !is_virtual), "wrong identity");

Nit: Thank you for update! This check can be simplified with:

      assert(_is_mount == is_virtual), "wrong identity");

But it becomes more obscure though. Feel free to ignore this comment.

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

PR Review: https://git.openjdk.org/jdk/pull/28361#pullrequestreview-3531985682
PR Comment: https://git.openjdk.org/jdk/pull/28361#issuecomment-3603842122
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2582681780

From cjplummer at openjdk.org  Tue Dec  2 20:32:20 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 2 Dec 2025 20:32:20 GMT
Subject: RFR: 8372552: unhandled oop in the
 JvmtiEventController::set_user_enabled
In-Reply-To: <S98YSOSlUjnt1BmanVNsSKreo7inwhlfM-hEJo_lErU=.1c4e3603-0b92-4604-8da6-507afe9252c7@github.com>
References: <S98YSOSlUjnt1BmanVNsSKreo7inwhlfM-hEJo_lErU=.1c4e3603-0b92-4604-8da6-507afe9252c7@github.com>
Message-ID: <RMmidV2Z-M4UdIMnqdgzw3IVTqWbTHJFWlB87vhO_L4=.fc1867ce-bfb8-47c8-a884-f378e39bb36d@github.com>

On Wed, 26 Nov 2025 04:42:48 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The issue reproduced by running test 
> vmTestbase/nsk/jvmti/AttachOnDemand/attach022[1]/TestDescription.java
> with `-XX:+CheckUnhandledOops`.
> 
> No need to flush object free events during VM init. So it is fine to move it after handling the oop.
> 
> Testing with tier1-5.

Looks good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28500#pullrequestreview-3531993784

From dholmes at openjdk.org  Tue Dec  2 20:38:02 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 2 Dec 2025 20:38:02 GMT
Subject: RFR: 8372179: Remove Unused ConcurrentHashTable::MultiGetHandle
In-Reply-To: <q-Y1GRBQYb90aqz6gCUsmyO_g3jwKsq5M2qIv2mOmz0=.152c826e-0089-4230-8fa2-54f7bd322a52@github.com>
References: <q-Y1GRBQYb90aqz6gCUsmyO_g3jwKsq5M2qIv2mOmz0=.152c826e-0089-4230-8fa2-54f7bd322a52@github.com>
Message-ID: <ANDILSdgstbMXGf3hfgY0U0ps9-dl30Ro1QC0dbmPEE=.8c496607-ba0d-4c09-a434-898e9836bcb7@github.com>

On Wed, 19 Nov 2025 15:58:07 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review the removal of `ConcurrentHashTable::MultiGetHandle` which is never used anywhere but in gtests.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

Seems fine. Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28396#pullrequestreview-3532011398

From pchilanomate at openjdk.org  Tue Dec  2 20:42:29 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 2 Dec 2025 20:42:29 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v12]
In-Reply-To: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
Message-ID: <ckP6AwbDS--WqWEY7u8G85IQPYfmDt40jARAB_L6ciU=.929ba610-4e03-4cee-a71b-98361517d697@github.com>

> 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 terms of mount and un...

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  simplify assert

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28361/files
  - new: https://git.openjdk.org/jdk/pull/28361/files/1f1cd594..7ffbbc6d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28361&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28361&range=10-11

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

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

From pchilanomate at openjdk.org  Tue Dec  2 20:42:30 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 2 Dec 2025 20:42:30 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v11]
In-Reply-To: <JMq7LxVJ7_B1ypy-DDaeTJMKGO_9VPvQiWqb2JUkLAY=.3eea6f9e-723a-42c2-aa1b-6d6dab0f3279@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <URdOE6ZdBSqYc7LrGrVReCSpFh-KVt0IuuC8TIyfsJw=.b98e6ea7-1b29-487d-bf93-0aaf7259cc3c@github.com>
 <JMq7LxVJ7_B1ypy-DDaeTJMKGO_9VPvQiWqb2JUkLAY=.3eea6f9e-723a-42c2-aa1b-6d6dab0f3279@github.com>
Message-ID: <AC_Jcyka6ot70oBXchaghxIeJq6jkvCY2t_DIMiXEI8=.dbfa623b-0aaf-48ae-a7e4-9d1e6b4ec28a@github.com>

On Tue, 2 Dec 2025 20:28:22 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Yes, this is a great work!
>
Thanks for the review Serguei!

> src/hotspot/share/runtime/mountUnmountDisabler.cpp line 87:
> 
>> 85:       }
>> 86:       DEBUG_ONLY(bool is_virtual = java_lang_VirtualThread::is_instance(_current->jvmti_vthread()));
>> 87:       assert((_is_mount && is_virtual) || (!_is_mount && !is_virtual), "wrong identity");
> 
> Nit: Thank you for update! This check can be simplified with:
> 
>       assert(_is_mount == is_virtual), "wrong identity");
> 
> But it becomes more obscure though. Feel free to ignore this comment.

I applied the suggestion, it reads well to me.

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

PR Comment: https://git.openjdk.org/jdk/pull/28361#issuecomment-3603874550
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2582710357

From jsikstro at openjdk.org  Tue Dec  2 20:53:06 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 2 Dec 2025 20:53:06 GMT
Subject: Integrated: 8372961: [BACKOUT] Remove the default value of
 InitialRAMPercentage
Message-ID: <yjmfrbFCoBzvxvhQNEvCPXtmXQSQIS79Q7kC4RtEhMw=.f88094fa-3d4b-4096-9a4f-5a5d1f739d03@github.com>

Hello,

The change causes a number of tests to fail. Let's back this out. Thanks.

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

Commit messages:
 - 8372961: [BACKOUT] Remove the default value of InitialRAMPercentage

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

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

From stefank at openjdk.org  Tue Dec  2 20:53:07 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 2 Dec 2025 20:53:07 GMT
Subject: Integrated: 8372961: [BACKOUT] Remove the default value of
 InitialRAMPercentage
In-Reply-To: <yjmfrbFCoBzvxvhQNEvCPXtmXQSQIS79Q7kC4RtEhMw=.f88094fa-3d4b-4096-9a4f-5a5d1f739d03@github.com>
References: <yjmfrbFCoBzvxvhQNEvCPXtmXQSQIS79Q7kC4RtEhMw=.f88094fa-3d4b-4096-9a4f-5a5d1f739d03@github.com>
Message-ID: <Kh3ull6Uxzr7Vw4160tvsCsYFkwCqWchTk7-KtEpAGA=.3f467978-233c-4467-885c-cb3374d408a5@github.com>

On Tue, 2 Dec 2025 20:43:03 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> The change causes a number of tests to fail. Let's back this out. Thanks.

Clean backout. Trivial.

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

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28617#pullrequestreview-3532035245

From jsikstro at openjdk.org  Tue Dec  2 20:53:07 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 2 Dec 2025 20:53:07 GMT
Subject: Integrated: 8372961: [BACKOUT] Remove the default value of
 InitialRAMPercentage
In-Reply-To: <Kh3ull6Uxzr7Vw4160tvsCsYFkwCqWchTk7-KtEpAGA=.3f467978-233c-4467-885c-cb3374d408a5@github.com>
References: <yjmfrbFCoBzvxvhQNEvCPXtmXQSQIS79Q7kC4RtEhMw=.f88094fa-3d4b-4096-9a4f-5a5d1f739d03@github.com>
 <Kh3ull6Uxzr7Vw4160tvsCsYFkwCqWchTk7-KtEpAGA=.3f467978-233c-4467-885c-cb3374d408a5@github.com>
Message-ID: <M2JeAhSNqWpORmsPKIjR4mMK06yKEJWCBIaDU04AglU=.9e7c6bcb-4165-480a-b25c-ba5556a9d517@github.com>

On Tue, 2 Dec 2025 20:43:40 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Hello,
>> 
>> The change causes a number of tests to fail. Let's back this out. Thanks.
>
> Clean backout. Trivial.

Thank you @stefank

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

PR Comment: https://git.openjdk.org/jdk/pull/28617#issuecomment-3603895276

From jsikstro at openjdk.org  Tue Dec  2 20:53:09 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 2 Dec 2025 20:53:09 GMT
Subject: Integrated: 8372961: [BACKOUT] Remove the default value of
 InitialRAMPercentage
In-Reply-To: <yjmfrbFCoBzvxvhQNEvCPXtmXQSQIS79Q7kC4RtEhMw=.f88094fa-3d4b-4096-9a4f-5a5d1f739d03@github.com>
References: <yjmfrbFCoBzvxvhQNEvCPXtmXQSQIS79Q7kC4RtEhMw=.f88094fa-3d4b-4096-9a4f-5a5d1f739d03@github.com>
Message-ID: <sc7VkyPmZrE_85mc5qLt5KTqjHMPzZ4dDHPwkLyJ7js=.bec628c6-82a9-45a7-a833-930702a70ac2@github.com>

On Tue, 2 Dec 2025 20:43:03 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> The change causes a number of tests to fail. Let's back this out. Thanks.

Trying again.

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

PR Comment: https://git.openjdk.org/jdk/pull/28617#issuecomment-3603905339

From jsikstro at openjdk.org  Tue Dec  2 20:53:10 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 2 Dec 2025 20:53:10 GMT
Subject: Integrated: 8372961: [BACKOUT] Remove the default value of
 InitialRAMPercentage
In-Reply-To: <yjmfrbFCoBzvxvhQNEvCPXtmXQSQIS79Q7kC4RtEhMw=.f88094fa-3d4b-4096-9a4f-5a5d1f739d03@github.com>
References: <yjmfrbFCoBzvxvhQNEvCPXtmXQSQIS79Q7kC4RtEhMw=.f88094fa-3d4b-4096-9a4f-5a5d1f739d03@github.com>
Message-ID: <Y3kNrKaQhdpDYPwP45PEJiDcd5HjPvCCPkQd54c1wBI=.c1d8f0f5-a532-4ccf-9b4e-5e6ece630cee@github.com>

On Tue, 2 Dec 2025 20:43:03 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> The change causes a number of tests to fail. Let's back this out. Thanks.

This pull request has now been integrated.

Changeset: 0bead706
Author:    Joel Sikstr?m <jsikstro at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0bead70651ea3bf8dccf9942ef8d1bf3fb78c2ea
Stats:     4 lines in 3 files changed: 1 ins; 0 del; 3 mod

8372961: [BACKOUT] Remove the default value of InitialRAMPercentage

Reviewed-by: stefank

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

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

From bperez at openjdk.org  Tue Dec  2 21:08:12 2025
From: bperez at openjdk.org (Ben Perez)
Date: Tue, 2 Dec 2025 21:08:12 GMT
Subject: RFR: 8355216: Accelerate P-256 arithmetic on aarch64 [v3]
In-Reply-To: <EiLAVdcIX_OKisbKoR6H6ADweL9LSuLfIRQgRYYNw7o=.8c823874-0af8-4c54-8e61-a2c43243b2e0@github.com>
References: <EiLAVdcIX_OKisbKoR6H6ADweL9LSuLfIRQgRYYNw7o=.8c823874-0af8-4c54-8e61-a2c43243b2e0@github.com>
Message-ID: <sh8-lsjqj-wo39KcL3k2YTPvumzfxqi0itO-U3xRNeM=.cb21c55e-fcf3-49f1-b324-d8160e5240e3@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:

  fixed assertions in assembler_aarch64.hpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27946/files
  - new: https://git.openjdk.org/jdk/pull/27946/files/293ad948..ee2f01ac

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

  Stats: 10 lines in 2 files changed: 0 ins; 2 del; 8 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 lmesnik at openjdk.org  Tue Dec  2 21:09:11 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 2 Dec 2025 21:09:11 GMT
Subject: RFR: 8372039: post_sampled_object_alloc is called while lock is
 handled [v5]
In-Reply-To: <UmK9h-k8eDPiD32Xg16Oy5LKZ3v53L0saObiSLVT01M=.6f40435f-205f-4309-b610-04110571f3a3@github.com>
References: <UmK9h-k8eDPiD32Xg16Oy5LKZ3v53L0saObiSLVT01M=.6f40435f-205f-4309-b610-04110571f3a3@github.com>
Message-ID: <mpkHthp2MRmZ1iHsvXgF_EcBCSSU52AmFOCmO9-H7TE=.b734e6d1-0f24-4b77-ac29-ea364709117c@github.com>

> The AOT allocates objects while holding lock. The jvmti events can't be posted in such case. The allocation sampling might be just temporary disabled while AOT objects are allocated. 
> 
> I prefer to disable jvmti events for allocation only, not for AOT globally. If there are more events should be generated during AOT initialization, we might want to preserve them and post after initialization is completed. 
> 
> The existing failure could be reproduced by running tests with jvmti stress agent and ZGC enabled. Like
> make run-test JTREG_JVMTI_STRESS_AGENT=debugger=true TEST=gc/z/TestGarbageCollectorMXBean.java
> 
> Note: 
> I prelaced NoJvmtiVMObjectAllocMark, it was not used. Also it was incorrect. The 
> NoJvmtiEventsMark should be set even if jvmti events are not enable for this thread. Since jvmti events might be enabled just in the middle of the mark.

Leonid Mesnik has updated the pull request incrementally with seven additional commits since the last revision:

 - Apply suggestion from @alexmenkov
   
   Co-authored-by: Alex Menkov <alexey.menkov at oracle.com>
 - Apply suggestion from @alexmenkov
   
   Co-authored-by: Alex Menkov <alexey.menkov at oracle.com>
 - Apply suggestion from @alexmenkov
   
   Co-authored-by: Alex Menkov <alexey.menkov at oracle.com>
 - Update test/hotspot/jtreg/serviceability/jvmti/events/SampledObjectAlloc/SamplingDuringInit/libSamplingDuringInit.cpp
   
   Co-authored-by: Alex Menkov <alexey.menkov at oracle.com>
 - Update test/hotspot/jtreg/serviceability/jvmti/events/SampledObjectAlloc/SamplingDuringInit/SamplingDuringInit.java
   
   Co-authored-by: Alex Menkov <alexey.menkov at oracle.com>
 - Update src/hotspot/share/runtime/javaThread.hpp
   
   Co-authored-by: Alex Menkov <alexey.menkov at oracle.com>
 - Update src/hotspot/share/runtime/javaThread.cpp
   
   Co-authored-by: Alex Menkov <alexey.menkov at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28544/files
  - new: https://git.openjdk.org/jdk/pull/28544/files/f7e869b2..aaa0ccbb

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

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

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

From amenkov at openjdk.org  Tue Dec  2 21:09:16 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 2 Dec 2025 21:09:16 GMT
Subject: RFR: 8372039: post_sampled_object_alloc is called while lock is
 handled [v4]
In-Reply-To: <UvDf93Ksz_ykKylF7FKC2O7xHi8zw9HKSD1xaoL360g=.dee4b184-5fc4-477a-906a-b9762d9c6ff7@github.com>
References: <UmK9h-k8eDPiD32Xg16Oy5LKZ3v53L0saObiSLVT01M=.6f40435f-205f-4309-b610-04110571f3a3@github.com>
 <UvDf93Ksz_ykKylF7FKC2O7xHi8zw9HKSD1xaoL360g=.dee4b184-5fc4-477a-906a-b9762d9c6ff7@github.com>
Message-ID: <ytRtbZRc4hBLmCHeVFi8aQeuUWg3DLyVetsRM7GnuE8=.3ff8b1cb-fb4a-4ffb-ad7b-1d8a7b384aab@github.com>

On Fri, 28 Nov 2025 21:09:24 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The AOT allocates objects while holding lock. The jvmti events can't be posted in such case. The allocation sampling might be just temporary disabled while AOT objects are allocated. 
>> 
>> I prefer to disable jvmti events for allocation only, not for AOT globally. If there are more events should be generated during AOT initialization, we might want to preserve them and post after initialization is completed. 
>> 
>> The existing failure could be reproduced by running tests with jvmti stress agent and ZGC enabled. Like
>> make run-test JTREG_JVMTI_STRESS_AGENT=debugger=true TEST=gc/z/TestGarbageCollectorMXBean.java
>> 
>> Note: 
>> I prelaced NoJvmtiVMObjectAllocMark, it was not used. Also it was incorrect. The 
>> NoJvmtiEventsMark should be set even if jvmti events are not enable for this thread. Since jvmti events might be enabled just in the middle of the mark.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   made jvmti_events_disalber as counter

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

> 452:   _is_disable_suspend(false),
> 453:   _is_in_java_upcall(false),
> 454:   _jvmti_events_disabled(false),

Suggestion:

  _jvmti_events_disabled(0),

src/hotspot/share/runtime/javaThread.hpp line 768:

> 766:   // - JVMTI is making a Java upcall (_is_in_java_upcall)
> 767:   bool should_hide_jvmti_events() const          { return _is_in_VTMS_transition || _is_disable_suspend
> 768:     || _is_in_java_upcall || _jvmti_events_disabled != 0; }

Suggestion:

  bool should_hide_jvmti_events() const {
    return _is_in_VTMS_transition || _is_disable_suspend || _is_in_java_upcall || _jvmti_events_disabled != 0;
  }

test/hotspot/jtreg/serviceability/jvmti/events/SampledObjectAlloc/SamplingDuringInit/SamplingDuringInit.java line 26:

> 24: /**
> 25:  * @test
> 26:  * @summary  Test verify that object allocation sampling is disabled during AOT.

Suggestion:

 * @summary The test verifies that object allocation sampling is disabled during AOT.

test/hotspot/jtreg/serviceability/jvmti/events/SampledObjectAlloc/SamplingDuringInit/libSamplingDuringInit.cpp line 26:

> 24: #include "jvmti.h"
> 25: #include "jvmti_common.hpp"
> 26: 

Suggestion:

test/hotspot/jtreg/serviceability/jvmti/events/SampledObjectAlloc/SamplingDuringInit/libSamplingDuringInit.cpp line 34:

> 32:   LOG("Sampled object\n");
> 33: }
> 34: 

Suggestion:

test/hotspot/jtreg/serviceability/jvmti/events/SampledObjectAlloc/SamplingDuringInit/libSamplingDuringInit.cpp line 49:

> 47:     return JNI_ERR;
> 48:   }
> 49: 

Suggestion:

test/hotspot/jtreg/serviceability/jvmti/events/SampledObjectAlloc/SamplingDuringInit/libSamplingDuringInit.cpp line 67:

> 65:   err = jvmti->SetHeapSamplingInterval(10);
> 66:   check_jvmti_error(err, "SetHeapSamplingInterval");
> 67: 

Suggestion:

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28544#discussion_r2582743429
PR Review Comment: https://git.openjdk.org/jdk/pull/28544#discussion_r2582750762
PR Review Comment: https://git.openjdk.org/jdk/pull/28544#discussion_r2582754970
PR Review Comment: https://git.openjdk.org/jdk/pull/28544#discussion_r2582755827
PR Review Comment: https://git.openjdk.org/jdk/pull/28544#discussion_r2582756365
PR Review Comment: https://git.openjdk.org/jdk/pull/28544#discussion_r2582756981
PR Review Comment: https://git.openjdk.org/jdk/pull/28544#discussion_r2582759498

From asmehra at openjdk.org  Tue Dec  2 21:10:03 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Tue, 2 Dec 2025 21:10:03 GMT
Subject: RFR: 8372617: Save and restore stubgen stubs when using an AOT
 code cache
In-Reply-To: <Go54Gywh42CRwyklMujtDmvPuZ78orCsyekS0vmZ68I=.7cda3e62-209f-494b-9c89-b59653232813@github.com>
References: <Go54Gywh42CRwyklMujtDmvPuZ78orCsyekS0vmZ68I=.7cda3e62-209f-494b-9c89-b59653232813@github.com>
Message-ID: <RBFD7jDQy6qY6kLzBfvnel8IadjlDWDQNJzvWpn1R3o=.5c3ca3ae-8319-41c5-acf3-1a0ff540b1ab@github.com>

On Thu, 20 Nov 2025 14:59:02 GMT, Andrew Dinn <adinn at openjdk.org> 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

Looks good. I only have minor comments, some typos and unused code.

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 1846:

> 1844: 
> 1845:     bool add_extras = !is_oop && (!aligned || sizeof(jlong) == size);
> 1846:     int extra_count = ((add_extras ? 1 : 0) * 3);

I think it would read better if a macro is used instead of hard-coding 3 here, something like `UnsafeMemoryAccess::ADDRESS_COUNT"

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`.

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.

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".

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.

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

src/hotspot/cpu/zero/stubRoutines_zero.cpp line 35:

> 33: 
> 34: #if INCLUDE_CDS
> 35: // nothing to do for xero

xero->zero

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.

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.

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 :).

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`

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

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.

src/hotspot/share/runtime/stubCodeGenerator.cpp line 118:

> 116: // default_handler.
> 117: 
> 118: void StubCodeGenerator::register_unsafe_access_handlers(GrowableArray<address> &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?

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

Changes requested by asmehra (Committer).

PR Review: https://git.openjdk.org/jdk/pull/28433#pullrequestreview-3531142588
PR Review Comment: https://git.openjdk.org/jdk/pull/28433#discussion_r2582028698
PR Review Comment: https://git.openjdk.org/jdk/pull/28433#discussion_r2582087169
PR Review Comment: https://git.openjdk.org/jdk/pull/28433#discussion_r2582094005
PR Review Comment: https://git.openjdk.org/jdk/pull/28433#discussion_r2582097741
PR Review Comment: https://git.openjdk.org/jdk/pull/28433#discussion_r2582736962
PR Review Comment: https://git.openjdk.org/jdk/pull/28433#discussion_r2582730520
PR Review Comment: https://git.openjdk.org/jdk/pull/28433#discussion_r2582744339
PR Review Comment: https://git.openjdk.org/jdk/pull/28433#discussion_r2582752398
PR Review Comment: https://git.openjdk.org/jdk/pull/28433#discussion_r2582024777
PR Review Comment: https://git.openjdk.org/jdk/pull/28433#discussion_r2582024431
PR Review Comment: https://git.openjdk.org/jdk/pull/28433#discussion_r2582015259
PR Review Comment: https://git.openjdk.org/jdk/pull/28433#discussion_r2582014593
PR Review Comment: https://git.openjdk.org/jdk/pull/28433#discussion_r2582014427
PR Review Comment: https://git.openjdk.org/jdk/pull/28433#discussion_r2582013969

From amenkov at openjdk.org  Tue Dec  2 21:14:33 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 2 Dec 2025 21:14:33 GMT
Subject: RFR: 8372552: unhandled oop in the
 JvmtiEventController::set_user_enabled
In-Reply-To: <S98YSOSlUjnt1BmanVNsSKreo7inwhlfM-hEJo_lErU=.1c4e3603-0b92-4604-8da6-507afe9252c7@github.com>
References: <S98YSOSlUjnt1BmanVNsSKreo7inwhlfM-hEJo_lErU=.1c4e3603-0b92-4604-8da6-507afe9252c7@github.com>
Message-ID: <u2bI6YRr6_GlR87NRPXb2yunNGdgJN5g9oLy7M6ETb4=.ed20abe4-3c0f-4a87-8eac-8822f09e862c@github.com>

On Wed, 26 Nov 2025 04:42:48 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The issue reproduced by running test 
> vmTestbase/nsk/jvmti/AttachOnDemand/attach022[1]/TestDescription.java
> with `-XX:+CheckUnhandledOops`.
> 
> No need to flush object free events during VM init. So it is fine to move it after handling the oop.
> 
> Testing with tier1-5.

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28500#pullrequestreview-3532124536

From sspitsyn at openjdk.org  Tue Dec  2 21:22:12 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 2 Dec 2025 21:22:12 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v12]
In-Reply-To: <ckP6AwbDS--WqWEY7u8G85IQPYfmDt40jARAB_L6ciU=.929ba610-4e03-4cee-a71b-98361517d697@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <ckP6AwbDS--WqWEY7u8G85IQPYfmDt40jARAB_L6ciU=.929ba610-4e03-4cee-a71b-98361517d697@github.com>
Message-ID: <fPa-U_4A3CzC8YNAyCALLvAZNeIcQkc_2sasnhcCAgs=.d0dd726a-411c-4547-9062-86650c7113cf@github.com>

On Tue, 2 Dec 2025 20:42:29 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> 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 incrementally with one additional commit since the last revision:
> 
>   simplify assert

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28361#pullrequestreview-3532150956

From amenkov at openjdk.org  Tue Dec  2 21:24:53 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 2 Dec 2025 21:24:53 GMT
Subject: RFR: 8372039: post_sampled_object_alloc is called while lock is
 handled [v5]
In-Reply-To: <mpkHthp2MRmZ1iHsvXgF_EcBCSSU52AmFOCmO9-H7TE=.b734e6d1-0f24-4b77-ac29-ea364709117c@github.com>
References: <UmK9h-k8eDPiD32Xg16Oy5LKZ3v53L0saObiSLVT01M=.6f40435f-205f-4309-b610-04110571f3a3@github.com>
 <mpkHthp2MRmZ1iHsvXgF_EcBCSSU52AmFOCmO9-H7TE=.b734e6d1-0f24-4b77-ac29-ea364709117c@github.com>
Message-ID: <4-yIaDJAERF9W6jzvgKZ-iqTf27YogFBsLBxb-K86Fw=.15960f7b-f507-4425-b260-f8d148afda9b@github.com>

On Tue, 2 Dec 2025 21:09:11 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The AOT allocates objects while holding lock. The jvmti events can't be posted in such case. The allocation sampling might be just temporary disabled while AOT objects are allocated. 
>> 
>> I prefer to disable jvmti events for allocation only, not for AOT globally. If there are more events should be generated during AOT initialization, we might want to preserve them and post after initialization is completed. 
>> 
>> The existing failure could be reproduced by running tests with jvmti stress agent and ZGC enabled. Like
>> make run-test JTREG_JVMTI_STRESS_AGENT=debugger=true TEST=gc/z/TestGarbageCollectorMXBean.java
>> 
>> Note: 
>> I prelaced NoJvmtiVMObjectAllocMark, it was not used. Also it was incorrect. The 
>> NoJvmtiEventsMark should be set even if jvmti events are not enable for this thread. Since jvmti events might be enabled just in the middle of the mark.
>
> Leonid Mesnik has updated the pull request incrementally with seven additional commits since the last revision:
> 
>  - Apply suggestion from @alexmenkov
>    
>    Co-authored-by: Alex Menkov <alexey.menkov at oracle.com>
>  - Apply suggestion from @alexmenkov
>    
>    Co-authored-by: Alex Menkov <alexey.menkov at oracle.com>
>  - Apply suggestion from @alexmenkov
>    
>    Co-authored-by: Alex Menkov <alexey.menkov at oracle.com>
>  - Update test/hotspot/jtreg/serviceability/jvmti/events/SampledObjectAlloc/SamplingDuringInit/libSamplingDuringInit.cpp
>    
>    Co-authored-by: Alex Menkov <alexey.menkov at oracle.com>
>  - Update test/hotspot/jtreg/serviceability/jvmti/events/SampledObjectAlloc/SamplingDuringInit/SamplingDuringInit.java
>    
>    Co-authored-by: Alex Menkov <alexey.menkov at oracle.com>
>  - Update src/hotspot/share/runtime/javaThread.hpp
>    
>    Co-authored-by: Alex Menkov <alexey.menkov at oracle.com>
>  - Update src/hotspot/share/runtime/javaThread.cpp
>    
>    Co-authored-by: Alex Menkov <alexey.menkov at oracle.com>

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28544#pullrequestreview-3532157793

From sspitsyn at openjdk.org  Tue Dec  2 22:04:45 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 2 Dec 2025 22:04:45 GMT
Subject: RFR: 8372039: post_sampled_object_alloc is called while lock is
 handled [v5]
In-Reply-To: <mpkHthp2MRmZ1iHsvXgF_EcBCSSU52AmFOCmO9-H7TE=.b734e6d1-0f24-4b77-ac29-ea364709117c@github.com>
References: <UmK9h-k8eDPiD32Xg16Oy5LKZ3v53L0saObiSLVT01M=.6f40435f-205f-4309-b610-04110571f3a3@github.com>
 <mpkHthp2MRmZ1iHsvXgF_EcBCSSU52AmFOCmO9-H7TE=.b734e6d1-0f24-4b77-ac29-ea364709117c@github.com>
Message-ID: <9ZbaqmcinlEmgQkJm9ardDAIC5SeoWfBb0BCgfsTPO4=.57f7effb-cc59-41b2-860c-f536d27653c2@github.com>

On Tue, 2 Dec 2025 21:09:11 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The AOT allocates objects while holding lock. The jvmti events can't be posted in such case. The allocation sampling might be just temporary disabled while AOT objects are allocated. 
>> 
>> I prefer to disable jvmti events for allocation only, not for AOT globally. If there are more events should be generated during AOT initialization, we might want to preserve them and post after initialization is completed. 
>> 
>> The existing failure could be reproduced by running tests with jvmti stress agent and ZGC enabled. Like
>> make run-test JTREG_JVMTI_STRESS_AGENT=debugger=true TEST=gc/z/TestGarbageCollectorMXBean.java
>> 
>> Note: 
>> I prelaced NoJvmtiVMObjectAllocMark, it was not used. Also it was incorrect. The 
>> NoJvmtiEventsMark should be set even if jvmti events are not enable for this thread. Since jvmti events might be enabled just in the middle of the mark.
>
> Leonid Mesnik has updated the pull request incrementally with seven additional commits since the last revision:
> 
>  - Apply suggestion from @alexmenkov
>    
>    Co-authored-by: Alex Menkov <alexey.menkov at oracle.com>
>  - Apply suggestion from @alexmenkov
>    
>    Co-authored-by: Alex Menkov <alexey.menkov at oracle.com>
>  - Apply suggestion from @alexmenkov
>    
>    Co-authored-by: Alex Menkov <alexey.menkov at oracle.com>
>  - Update test/hotspot/jtreg/serviceability/jvmti/events/SampledObjectAlloc/SamplingDuringInit/libSamplingDuringInit.cpp
>    
>    Co-authored-by: Alex Menkov <alexey.menkov at oracle.com>
>  - Update test/hotspot/jtreg/serviceability/jvmti/events/SampledObjectAlloc/SamplingDuringInit/SamplingDuringInit.java
>    
>    Co-authored-by: Alex Menkov <alexey.menkov at oracle.com>
>  - Update src/hotspot/share/runtime/javaThread.hpp
>    
>    Co-authored-by: Alex Menkov <alexey.menkov at oracle.com>
>  - Update src/hotspot/share/runtime/javaThread.cpp
>    
>    Co-authored-by: Alex Menkov <alexey.menkov at oracle.com>

The fix looks good in general. I've requested a minor test update though.

test/hotspot/jtreg/serviceability/jvmti/events/SampledObjectAlloc/SamplingDuringInit/libSamplingDuringInit.cpp line 32:

> 30: SampledObjectAlloc(jvmtiEnv *jvmti, JNIEnv* jni, jthread thread, jobject object, jclass object_klass, jlong size) {
> 31:   LOG("Sampled object\n");
> 32: }

I'd suggest to increment a counter here. Then check it at the end and fail if it is not 0.

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

PR Review: https://git.openjdk.org/jdk/pull/28544#pullrequestreview-3532263502
PR Review Comment: https://git.openjdk.org/jdk/pull/28544#discussion_r2582904026

From duke at openjdk.org  Tue Dec  2 22:06:18 2025
From: duke at openjdk.org (Chad Rakoczy)
Date: Tue, 2 Dec 2025 22:06:18 GMT
Subject: RFR: 8371046: Segfault in
 compiler/whitebox/StressNMethodRelocation.java with -XX:+UseZGC [v2]
In-Reply-To: <k0-Cr7yor3F4OKDiZdT3lIrFiSgI_YRCR8_FphgQmlk=.4f60b60e-127d-413e-ab8f-26d6c4911142@github.com>
References: <k0-Cr7yor3F4OKDiZdT3lIrFiSgI_YRCR8_FphgQmlk=.4f60b60e-127d-413e-ab8f-26d6c4911142@github.com>
Message-ID: <hQo3CkLhsZLq7-L4_5ui7eXaoycrENU5zyFS4JwzvVE=.a78ad8ce-8435-4009-a6c0-28fde884ac63@github.com>

> [JDK-8371046](https://bugs.openjdk.org/browse/JDK-8371046)
> 
> This pull request fixes two crashes (see below) and adds `InvalidationReason::RELOCATED` to better describe why an nmethod is marked not entrant during relocation.
> 
> ---
> 
> #### 1. Test Bug
> 
> It?s possible for an `nmethod` to be unloaded without its `_state` being explicitly set to `not_entrant`. Checking only `is_in_use()` isn?t sufficient, since the `nmethod` may already be in the process of unloading and therefore may not have a lock (as with ZGC, where `nmethods` are locked individually).
> 
> The fix adds an additional `is_unloading()` check in WhiteBox before acquiring the lock.
> 
> This issue was reproducible fairly consistently (every few runs) by executing `compiler/whitebox/StressNMethodRelocation.java` with  `-XX:+UseZGC -XX:ReservedCodeCacheSize=32m`
> 
> 
> After applying this patch, the original crash stopped occurring, though a more infrequent crash was still observed.
> 
> ---
> 
> #### 2. Implementation Bug
> 
> `nmethod::relocate` works by copying the instructions of an `nmethod` and then adjusting the call sites to account for new PC-relative offsets.
> 
> Previously, this fix-up happened *after* calling `post_init()`, which registers the `nmethod` and makes it visible to the GC. This introduced a race condition where the GC might attempt to resolve a call site before it had been fixed.
> 
> The fix ensures that all call sites are patched **before** the `nmethod` is registered.
> 
> In testing, the crash previously occurred roughly 60 times in 5,000 runs (~1.2%). With this patch, no crashes were observed in the same number of runs.

Chad Rakoczy 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 'origin/master' into JDK-8371046
 - Add comment
 - Add guarantee
 - Clear inline caches before calling post_init
 - Fix relocations before registering nmethod
 - Add is_unloading() check before aquiring ic lock

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28241/files
  - new: https://git.openjdk.org/jdk/pull/28241/files/dac140bb..7160f835

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

  Stats: 149874 lines in 621 files changed: 103255 ins; 19601 del; 27018 mod
  Patch: https://git.openjdk.org/jdk/pull/28241.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28241/head:pull/28241

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

From duke at openjdk.org  Tue Dec  2 22:06:20 2025
From: duke at openjdk.org (Chad Rakoczy)
Date: Tue, 2 Dec 2025 22:06:20 GMT
Subject: RFR: 8371046: Segfault in
 compiler/whitebox/StressNMethodRelocation.java with -XX:+UseZGC
In-Reply-To: <Wp26yu5-XzxQu263XG8F_ulOdo052Z1ljoN8kQVhkAk=.5ad009c7-570b-4c26-aa25-27ef6a3ac3a9@github.com>
References: <k0-Cr7yor3F4OKDiZdT3lIrFiSgI_YRCR8_FphgQmlk=.4f60b60e-127d-413e-ab8f-26d6c4911142@github.com>
 <Wp26yu5-XzxQu263XG8F_ulOdo052Z1ljoN8kQVhkAk=.5ad009c7-570b-4c26-aa25-27ef6a3ac3a9@github.com>
Message-ID: <zJVw4ekTMfKjLjm4Ul6LaQrC7W8Q8-FN5xSH25jwRGY=.9e2b7cea-3d94-454b-ac18-3a21d5ce0d41@github.com>

On Tue, 2 Dec 2025 17:32:05 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Yes, my main concern is that new encoding of address in cloned nmethod may not fit into existing instructions set. At least with guarantee we can catch such case if it happened.

I updated the assert to be a guarantee and updated the comment describing why we skip calling `CallRelocation::fix_relocation_after_move()`. 

Testing for tier1 and tier2 has passed on linux aarch64. I am currently running more intensive stress testing and will update with the results when it completes.

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

PR Comment: https://git.openjdk.org/jdk/pull/28241#issuecomment-3604089528

From liach at openjdk.org  Tue Dec  2 22:06:49 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 2 Dec 2025 22:06:49 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v3]
In-Reply-To: <WB3aHVk-aSxkuKL1H7QacVuQDMhbeiSdmXBMH_-6hKE=.f108b496-55dc-4a7d-97e4-31893fef2c7e@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <eXO79ZBlZUltqddmReHLTSFSr3x8PiH0a5s740GHrfk=.5cf01f8f-7ac5-4def-b17d-dfd6f10e9614@github.com>
 <WB3aHVk-aSxkuKL1H7QacVuQDMhbeiSdmXBMH_-6hKE=.f108b496-55dc-4a7d-97e4-31893fef2c7e@github.com>
Message-ID: <wU-3_Jug08C5ivglSRAlHpsDwJxUunUvfXNL3ClpW3Q=.02728eab-bc16-46b0-802f-b27608359040@github.com>

On Tue, 2 Dec 2025 20:18:19 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Tweak VH usage in some classes
>
> src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2042:
> 
>> 2040:             // This is still a hot path if vh is not constant - in this case,
>> 2041:             // asType is the bottleneck for constant folding, unfortunately
>> 2042:             var result = vh.getMethodHandle(mode).asType(symbolicMethodTypeInvoker);
> 
> `mode` and `symbolicMethodTypeInvoker` are part of `AccessDescriptor` while `vh` comes as an argument. What guarantees that a cached adapter is compatible with `vh` observed during subsequent calls? It means that `vh` shape stays exactly the same shape. Is it correct? Would be good to have it validated with asserts.

I am assuming that the previous `vh` observed is compatible with future ones if compiler can fold the `vh` into a constant. If it is not, we can drop the updates to the cache field in the C2 compiled slow code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2582922472

From liach at openjdk.org  Tue Dec  2 22:10:31 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 2 Dec 2025 22:10:31 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v3]
In-Reply-To: <_Z6KpxCYH2n3sHuT6-kRP4cSTAN3-s5UA0rbfrJSIgA=.e9d4089c-8329-406b-9a0a-167a24311c13@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <eXO79ZBlZUltqddmReHLTSFSr3x8PiH0a5s740GHrfk=.5cf01f8f-7ac5-4def-b17d-dfd6f10e9614@github.com>
 <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com>
 <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com>
 <M5yxETmdJBlueGf6KC7P8oSAZIEeiSu8rOHAoIxu0sc=.4bc347cb-40d5-4432-bc94-38a59730183d@github.com>
 <3OE37qXGHhLAhnRQM188hhygrLYBtI3FLBMK0tGVH30=.5d1b4406-3bb3-4788-8059-e78260b79ec1@github.com>
 <kZDurlwNJsrYZRbeHLXVTKqUQcW2QGFGLE-WNN-vz4o=.44bc4d21-cc9d-4d94-b40c-4b6ad9ab11aa@github.com>
 <7WF8DlorrU_B2__G2wr43w1PZwJh8mEhD5dY10YDIOo=.ec416c38-1aff-4dd6-8792-d6a0e01f91ce@github.com>
 <E7Lwc7nwEvsmQhLMYT5Ruj5j7BhVDcfyBRUfhinUyzQ=.3293c6f1-6ce4-47d8-aa48-ba9c69ba60eb@github.com>
 <ogD0Gl3QSb1pLJUqOn877wI6asY5TW0MV7mPFlNXM5A=.8af15b77-010a-4d34-901b-928c4a3fe425@github.com>
 <_Z6KpxCYH2n3sHuT6-kRP4cSTAN3-s5UA0r
 bfrJSIgA=.e9d4089c-8329-406b-9a0a-167a24311c13@github.com>
Message-ID: <cWF4r8rgGleVvKUgrzYDQ0bcj_7QhY1PulNMpZtwBcs=.abcdfd8f-9a3f-4d1f-a55f-f16ea320cf92@github.com>

On Tue, 2 Dec 2025 20:12:12 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> No. The avoidance of cache update simply trims down the generated code by throwing away the meaningless cache update.
>> 
>> The access to cache is already safeguarded by `constant == MethodHandleImpl.CONSTANT_YES`. I should have moved `var cache = adaptedMh;` into the if block of `constant == CONSTANT_YES`.
>
> I still find it confusing, especially tri-state logic part.
> 
> For background, `isCompileConstant` was introduced as part of LF sharing effort to get rid of Java-level profiling in optimized code. The pattern is was designed for was:
> 
>   if (isCompileConstant(...)) {
>     return ...;
>   } else {
>     ... // do some extra work (either in interpreter, C1, or not-fully-optimized version in C2) 
>   }
> 
> 
> In this patch, you don't follow that pattern and aadd new state (`CONSTANT_PENDING`) to distinguish interpreter/C1 from C2. What's the motivation? Why do you want to avoid cache updates coming from C2-generated code?

I am assuming that if C2 determines this `vh` is not a constant, we can drop it. Is that a right way to move along, or could C2 transition from "not a constant" to "is a constant" during the phases?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2582931449

From sspitsyn at openjdk.org  Tue Dec  2 22:19:26 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 2 Dec 2025 22:19:26 GMT
Subject: RFR: 8372552: unhandled oop in the
 JvmtiEventController::set_user_enabled
In-Reply-To: <S98YSOSlUjnt1BmanVNsSKreo7inwhlfM-hEJo_lErU=.1c4e3603-0b92-4604-8da6-507afe9252c7@github.com>
References: <S98YSOSlUjnt1BmanVNsSKreo7inwhlfM-hEJo_lErU=.1c4e3603-0b92-4604-8da6-507afe9252c7@github.com>
Message-ID: <o7oNu_Qqm_wqIt1zzSpui2uKC1MYbAhQKs6stlNs9TQ=.9d26b0b9-bb65-4596-b458-8bb17143c2c7@github.com>

On Wed, 26 Nov 2025 04:42:48 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The issue reproduced by running test 
> vmTestbase/nsk/jvmti/AttachOnDemand/attach022[1]/TestDescription.java
> with `-XX:+CheckUnhandledOops`.
> 
> No need to flush object free events during VM init. So it is fine to move it after handling the oop.
> 
> Testing with tier1-5.

Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28500#pullrequestreview-3532317632

From lmesnik at openjdk.org  Tue Dec  2 22:28:00 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 2 Dec 2025 22:28:00 GMT
Subject: RFR: 8372552: unhandled oop in the
 JvmtiEventController::set_user_enabled
In-Reply-To: <RMmidV2Z-M4UdIMnqdgzw3IVTqWbTHJFWlB87vhO_L4=.fc1867ce-bfb8-47c8-a884-f378e39bb36d@github.com>
References: <S98YSOSlUjnt1BmanVNsSKreo7inwhlfM-hEJo_lErU=.1c4e3603-0b92-4604-8da6-507afe9252c7@github.com>
 <RMmidV2Z-M4UdIMnqdgzw3IVTqWbTHJFWlB87vhO_L4=.fc1867ce-bfb8-47c8-a884-f378e39bb36d@github.com>
Message-ID: <M7I565o0FefgrsX2DXWP3w1NkJN8RnJYXvrG5T2gplY=.bc92090f-8ba8-4328-a145-e40071d25548@github.com>

On Tue, 2 Dec 2025 20:29:34 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> The issue reproduced by running test 
>> vmTestbase/nsk/jvmti/AttachOnDemand/attach022[1]/TestDescription.java
>> with `-XX:+CheckUnhandledOops`.
>> 
>> No need to flush object free events during VM init. So it is fine to move it after handling the oop.
>> 
>> Testing with tier1-5.
>
> Looks good.

@plummercj, @alexmenkov, @sspitsyn Thank you for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/28500#issuecomment-3604212792

From lmesnik at openjdk.org  Tue Dec  2 22:31:17 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 2 Dec 2025 22:31:17 GMT
Subject: Integrated: 8372552: unhandled oop in the
 JvmtiEventController::set_user_enabled
In-Reply-To: <S98YSOSlUjnt1BmanVNsSKreo7inwhlfM-hEJo_lErU=.1c4e3603-0b92-4604-8da6-507afe9252c7@github.com>
References: <S98YSOSlUjnt1BmanVNsSKreo7inwhlfM-hEJo_lErU=.1c4e3603-0b92-4604-8da6-507afe9252c7@github.com>
Message-ID: <VWlVGpCxt4kkYhDUngWIMahFTYytc4m-NgmltTJzWFE=.9b79c41f-2fc7-4ec0-8f5a-98d3d6a98c44@github.com>

On Wed, 26 Nov 2025 04:42:48 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The issue reproduced by running test 
> vmTestbase/nsk/jvmti/AttachOnDemand/attach022[1]/TestDescription.java
> with `-XX:+CheckUnhandledOops`.
> 
> No need to flush object free events during VM init. So it is fine to move it after handling the oop.
> 
> Testing with tier1-5.

This pull request has now been integrated.

Changeset: b0a758f2
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b0a758f2180a8305c05e9640192818bbb31d7922
Stats:     10 lines in 1 file changed: 5 ins; 4 del; 1 mod

8372552: unhandled oop in the JvmtiEventController::set_user_enabled

Reviewed-by: cjplummer, amenkov, sspitsyn

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

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

From lmesnik at openjdk.org  Tue Dec  2 22:37:22 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 2 Dec 2025 22:37:22 GMT
Subject: RFR: 8372039: post_sampled_object_alloc is called while lock is
 handled [v6]
In-Reply-To: <UmK9h-k8eDPiD32Xg16Oy5LKZ3v53L0saObiSLVT01M=.6f40435f-205f-4309-b610-04110571f3a3@github.com>
References: <UmK9h-k8eDPiD32Xg16Oy5LKZ3v53L0saObiSLVT01M=.6f40435f-205f-4309-b610-04110571f3a3@github.com>
Message-ID: <yyueGj3VqNJRO1Q7XJABxU3C0NuSHh7jBoMWtHomhrQ=.a32259c9-c5f4-43f1-a55a-db3acedb7b6b@github.com>

> The AOT allocates objects while holding lock. The jvmti events can't be posted in such case. The allocation sampling might be just temporary disabled while AOT objects are allocated. 
> 
> I prefer to disable jvmti events for allocation only, not for AOT globally. If there are more events should be generated during AOT initialization, we might want to preserve them and post after initialization is completed. 
> 
> The existing failure could be reproduced by running tests with jvmti stress agent and ZGC enabled. Like
> make run-test JTREG_JVMTI_STRESS_AGENT=debugger=true TEST=gc/z/TestGarbageCollectorMXBean.java
> 
> Note: 
> I prelaced NoJvmtiVMObjectAllocMark, it was not used. Also it was incorrect. The 
> NoJvmtiEventsMark should be set even if jvmti events are not enable for this thread. Since jvmti events might be enabled just in the middle of the mark.

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

  extended testing

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28544/files
  - new: https://git.openjdk.org/jdk/pull/28544/files/aaa0ccbb..830b5f94

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

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

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

From sspitsyn at openjdk.org  Tue Dec  2 23:15:49 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 2 Dec 2025 23:15:49 GMT
Subject: RFR: 8372039: post_sampled_object_alloc is called while lock is
 handled [v6]
In-Reply-To: <yyueGj3VqNJRO1Q7XJABxU3C0NuSHh7jBoMWtHomhrQ=.a32259c9-c5f4-43f1-a55a-db3acedb7b6b@github.com>
References: <UmK9h-k8eDPiD32Xg16Oy5LKZ3v53L0saObiSLVT01M=.6f40435f-205f-4309-b610-04110571f3a3@github.com>
 <yyueGj3VqNJRO1Q7XJABxU3C0NuSHh7jBoMWtHomhrQ=.a32259c9-c5f4-43f1-a55a-db3acedb7b6b@github.com>
Message-ID: <KrTCcVRt0x9ZUEH5wCVa6H1ftFicFhNZ7cT2SyXCoHU=.4059ab70-0af9-4948-874f-52675e73d755@github.com>

On Tue, 2 Dec 2025 22:37:22 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The AOT allocates objects while holding lock. The jvmti events can't be posted in such case. The allocation sampling might be just temporary disabled while AOT objects are allocated. 
>> 
>> I prefer to disable jvmti events for allocation only, not for AOT globally. If there are more events should be generated during AOT initialization, we might want to preserve them and post after initialization is completed. 
>> 
>> The existing failure could be reproduced by running tests with jvmti stress agent and ZGC enabled. Like
>> make run-test JTREG_JVMTI_STRESS_AGENT=debugger=true TEST=gc/z/TestGarbageCollectorMXBean.java
>> 
>> Note: 
>> I prelaced NoJvmtiVMObjectAllocMark, it was not used. Also it was incorrect. The 
>> NoJvmtiEventsMark should be set even if jvmti events are not enable for this thread. Since jvmti events might be enabled just in the middle of the mark.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   extended testing

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28544#pullrequestreview-3532435540

From liach at openjdk.org  Tue Dec  2 23:20:12 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 2 Dec 2025 23:20:12 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v4]
In-Reply-To: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
Message-ID: <tl1EOBPOzkNrl3TgmEuNiH0gS5f663gwpFhHEx2P7fc=.b69f6b86-f810-4c07-b58f-b4a659b794af@github.com>

> 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 eight additional commits since the last revision:

 - Rollback getAndAdd for now
 - Redundant change
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache
 - Stage
 - Review tweaks
 - Tweak VH usage in some classes
 - Logical fallacy
 - 8160821

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28585/files
  - new: https://git.openjdk.org/jdk/pull/28585/files/7bcdcbf3..d49ad129

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

  Stats: 4382 lines in 98 files changed: 2923 ins; 688 del; 771 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 liach at openjdk.org  Tue Dec  2 23:30:13 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 2 Dec 2025 23:30:13 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v4]
In-Reply-To: <tl1EOBPOzkNrl3TgmEuNiH0gS5f663gwpFhHEx2P7fc=.b69f6b86-f810-4c07-b58f-b4a659b794af@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <tl1EOBPOzkNrl3TgmEuNiH0gS5f663gwpFhHEx2P7fc=.b69f6b86-f810-4c07-b58f-b4a659b794af@github.com>
Message-ID: <K5oFQYj9AIsg2lqbWOWc3l_otFCPUV-Q9glYUz18kGQ=.7a39ec2f-5f5b-46a7-b298-8656d721ba85@github.com>

On Tue, 2 Dec 2025 23:20:12 GMT, Chen Liang <liach at openjdk.org> 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 eight additional commits since the last revision:
> 
>  - Rollback getAndAdd for now
>  - Redundant change
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache
>  - Stage
>  - Review tweaks
>  - Tweak VH usage in some classes
>  - Logical fallacy
>  - 8160821

After consulting with @iwanowww, I realized the non-constant status cannot be determined, that the C2 compiled method can even transition from 0 to 1, so I am simplifying this code to only handle the constant case. It seems the getAndAdd IR test no longer fails with this change, and I removed a lot of other redundant changes.

I updated the VarHandleExact benchmark added by @JornVernee, and added a case of dropping return values by changing access mode to `getAndAdd` consistently. Now they have the following performance numbers:

Benchmark                                        Mode  Cnt  Score   Error  Units
VarHandleExact.exact_exactInvocation             avgt   30  3.843 ? 0.062  ns/op
VarHandleExact.generic_exactInvocation           avgt   30  3.797 ? 0.049  ns/op
VarHandleExact.generic_genericInvocation         avgt   30  3.757 ? 0.034  ns/op
VarHandleExact.generic_returnDroppingInvocation  avgt   30  3.754 ? 0.026  ns/op

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

PR Comment: https://git.openjdk.org/jdk/pull/28585#issuecomment-3604377750

From lmesnik at openjdk.org  Tue Dec  2 23:51:28 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 2 Dec 2025 23:51:28 GMT
Subject: RFR: 8372039: post_sampled_object_alloc is called while lock is
 handled [v4]
In-Reply-To: <pZ9i5b1FUOCZkZY-gn97BhwvAWetUBbAMe7lHYA8uRY=.e8292b29-a6c1-492e-85a5-911288e12cd5@github.com>
References: <UmK9h-k8eDPiD32Xg16Oy5LKZ3v53L0saObiSLVT01M=.6f40435f-205f-4309-b610-04110571f3a3@github.com>
 <UvDf93Ksz_ykKylF7FKC2O7xHi8zw9HKSD1xaoL360g=.dee4b184-5fc4-477a-906a-b9762d9c6ff7@github.com>
 <pZ9i5b1FUOCZkZY-gn97BhwvAWetUBbAMe7lHYA8uRY=.e8292b29-a6c1-492e-85a5-911288e12cd5@github.com>
Message-ID: <P49b4xriJxDScFkPU8hsiQLERVwG_i11rGWyvLRodFw=.4b04c12e-492e-48dc-b638-ef4236927bea@github.com>

On Fri, 28 Nov 2025 22:48:10 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   made jvmti_events_disalber as counter
>
> Looks good.

@fisk, @alexmenkov, @sspitsyn Thank you for review and provided feedback

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

PR Comment: https://git.openjdk.org/jdk/pull/28544#issuecomment-3604418038

From lmesnik at openjdk.org  Tue Dec  2 23:51:31 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 2 Dec 2025 23:51:31 GMT
Subject: Integrated: 8372039: post_sampled_object_alloc is called while lock is
 handled
In-Reply-To: <UmK9h-k8eDPiD32Xg16Oy5LKZ3v53L0saObiSLVT01M=.6f40435f-205f-4309-b610-04110571f3a3@github.com>
References: <UmK9h-k8eDPiD32Xg16Oy5LKZ3v53L0saObiSLVT01M=.6f40435f-205f-4309-b610-04110571f3a3@github.com>
Message-ID: <tLN6QSBu89eRQdkiawfemonxZxijlU9zLvrCRZ-DRRA=.885b948b-d60d-419e-abda-305e775dbd23@github.com>

On Thu, 27 Nov 2025 20:12:11 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The AOT allocates objects while holding lock. The jvmti events can't be posted in such case. The allocation sampling might be just temporary disabled while AOT objects are allocated. 
> 
> I prefer to disable jvmti events for allocation only, not for AOT globally. If there are more events should be generated during AOT initialization, we might want to preserve them and post after initialization is completed. 
> 
> The existing failure could be reproduced by running tests with jvmti stress agent and ZGC enabled. Like
> make run-test JTREG_JVMTI_STRESS_AGENT=debugger=true TEST=gc/z/TestGarbageCollectorMXBean.java
> 
> Note: 
> I prelaced NoJvmtiVMObjectAllocMark, it was not used. Also it was incorrect. The 
> NoJvmtiEventsMark should be set even if jvmti events are not enable for this thread. Since jvmti events might be enabled just in the middle of the mark.

This pull request has now been integrated.

Changeset: f5e4cd7f
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f5e4cd7f0d12fd21399b192b32a5c9abfe8a3564
Stats:     194 lines in 8 files changed: 150 ins; 30 del; 14 mod

8372039: post_sampled_object_alloc is called while lock is handled

Reviewed-by: sspitsyn, eosterlund, amenkov

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

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

From vlivanov at openjdk.org  Wed Dec  3 01:42:45 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 3 Dec 2025 01:42:45 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v3]
In-Reply-To: <cWF4r8rgGleVvKUgrzYDQ0bcj_7QhY1PulNMpZtwBcs=.abcdfd8f-9a3f-4d1f-a55f-f16ea320cf92@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <eXO79ZBlZUltqddmReHLTSFSr3x8PiH0a5s740GHrfk=.5cf01f8f-7ac5-4def-b17d-dfd6f10e9614@github.com>
 <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com>
 <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com>
 <M5yxETmdJBlueGf6KC7P8oSAZIEeiSu8rOHAoIxu0sc=.4bc347cb-40d5-4432-bc94-38a59730183d@github.com>
 <3OE37qXGHhLAhnRQM188hhygrLYBtI3FLBMK0tGVH30=.5d1b4406-3bb3-4788-8059-e78260b79ec1@github.com>
 <kZDurlwNJsrYZRbeHLXVTKqUQcW2QGFGLE-WNN-vz4o=.44bc4d21-cc9d-4d94-b40c-4b6ad9ab11aa@github.com>
 <7WF8DlorrU_B2__G2wr43w1PZwJh8mEhD5dY10YDIOo=.ec416c38-1aff-4dd6-8792-d6a0e01f91ce@github.com>
 <E7Lwc7nwEvsmQhLMYT5Ruj5j7BhVDcfyBRUfhinUyzQ=.3293c6f1-6ce4-47d8-aa48-ba9c69ba60eb@github.com>
 <ogD0Gl3QSb1pLJUqOn877wI6asY5TW0MV7mPFlNXM5A=.8af15b77-010a-4d34-901b-928c4a3fe425@github.com>
 <_Z6KpxCYH2n3sHuT6-kRP4cSTAN3-s5UA0r
 bfrJSIgA=.e9d4089c-8329-406b-9a0a-167a24311c13@github.com>
 <cWF4r8rgGleVvKUgrzYDQ0bcj_7QhY1PulNMpZtwBcs=.abcdfd8f-9a3f-4d1f-a55f-f16ea320cf92@github.com>
Message-ID: <5CADH75ZjadKttOKwsykRFUPlQKLiwCW8E5WkM_75a4=.fd992c8f-e8bc-4775-9ea3-d5212664e3df@github.com>

On Tue, 2 Dec 2025 22:08:20 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I still find it confusing, especially tri-state logic part.
>> 
>> For background, `isCompileConstant` was introduced as part of LF sharing effort to get rid of Java-level profiling in optimized code. The pattern is was designed for was:
>> 
>>   if (isCompileConstant(...)) {
>>     return ...;
>>   } else {
>>     ... // do some extra work (either in interpreter, C1, or not-fully-optimized version in C2) 
>>   }
>> 
>> 
>> In this patch, you don't follow that pattern and aadd new state (`CONSTANT_PENDING`) to distinguish interpreter/C1 from C2. What's the motivation? Why do you want to avoid cache updates coming from C2-generated code?
>
> I am assuming that if C2 determines this `vh` is not a constant, we can drop it. Is that a right way to move along, or could C2 transition from "not a constant" to "is a constant" during the phases?

Sorry, I still don't understand how it is intended to work. Why does `MethodHandleImpl.isCompileConstant(vh) == true` imply that the cached value is compatible with the constant `vh`?


// Keep capturing - vh may suddenly get promoted to a constant by C2


Capturing happens outside compiler thread. It is not affected by C2 (except when it completely prunes the whole block).

So, either any captured adaptation is valid/compatible or there's a concurrency issue when C2 kicks in and there's a concurrent cache update happening with incompatible version.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2583346750

From vlivanov at openjdk.org  Wed Dec  3 01:56:27 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 3 Dec 2025 01:56:27 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v4]
In-Reply-To: <tl1EOBPOzkNrl3TgmEuNiH0gS5f663gwpFhHEx2P7fc=.b69f6b86-f810-4c07-b58f-b4a659b794af@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <tl1EOBPOzkNrl3TgmEuNiH0gS5f663gwpFhHEx2P7fc=.b69f6b86-f810-4c07-b58f-b4a659b794af@github.com>
Message-ID: <qZSAoBWMqcYPnd8SF41u64_b2edwi60xmEBzSMiH5eQ=.330c21a8-2720-4b9e-8947-9dfb6ad5b220@github.com>

On Tue, 2 Dec 2025 23:20:12 GMT, Chen Liang <liach at openjdk.org> 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 eight additional commits since the last revision:
> 
>  - Rollback getAndAdd for now
>  - Redundant change
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache
>  - Stage
>  - Review tweaks
>  - Tweak VH usage in some classes
>  - Logical fallacy
>  - 8160821

test/micro/org/openjdk/bench/java/lang/invoke/VarHandleExact.java line 81:

> 79: 
> 80:     @Benchmark
> 81:     public void generic_returnDroppingInvocation() {

What about "all-generic" case (` { generic.getAndAdd(data, 42); }`)?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2583363907

From kvn at openjdk.org  Wed Dec  3 04:02:55 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 3 Dec 2025 04:02:55 GMT
Subject: RFR: 8371046: Segfault in
 compiler/whitebox/StressNMethodRelocation.java with -XX:+UseZGC [v2]
In-Reply-To: <hQo3CkLhsZLq7-L4_5ui7eXaoycrENU5zyFS4JwzvVE=.a78ad8ce-8435-4009-a6c0-28fde884ac63@github.com>
References: <k0-Cr7yor3F4OKDiZdT3lIrFiSgI_YRCR8_FphgQmlk=.4f60b60e-127d-413e-ab8f-26d6c4911142@github.com>
 <hQo3CkLhsZLq7-L4_5ui7eXaoycrENU5zyFS4JwzvVE=.a78ad8ce-8435-4009-a6c0-28fde884ac63@github.com>
Message-ID: <zXb73XKxhhc_-Jm6UHqr8ouQdO4X9-jKTUIPEbNg6vU=.97f87d35-67ee-481d-b6a9-5fbf281f0a69@github.com>

On Tue, 2 Dec 2025 22:06:18 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

>> [JDK-8371046](https://bugs.openjdk.org/browse/JDK-8371046)
>> 
>> This pull request fixes two crashes (see below) and adds `InvalidationReason::RELOCATED` to better describe why an nmethod is marked not entrant during relocation.
>> 
>> ---
>> 
>> #### 1. Test Bug
>> 
>> It?s possible for an `nmethod` to be unloaded without its `_state` being explicitly set to `not_entrant`. Checking only `is_in_use()` isn?t sufficient, since the `nmethod` may already be in the process of unloading and therefore may not have a lock (as with ZGC, where `nmethods` are locked individually).
>> 
>> The fix adds an additional `is_unloading()` check in WhiteBox before acquiring the lock.
>> 
>> This issue was reproducible fairly consistently (every few runs) by executing `compiler/whitebox/StressNMethodRelocation.java` with  `-XX:+UseZGC -XX:ReservedCodeCacheSize=32m`
>> 
>> 
>> After applying this patch, the original crash stopped occurring, though a more infrequent crash was still observed.
>> 
>> ---
>> 
>> #### 2. Implementation Bug
>> 
>> `nmethod::relocate` works by copying the instructions of an `nmethod` and then adjusting the call sites to account for new PC-relative offsets.
>> 
>> Previously, this fix-up happened *after* calling `post_init()`, which registers the `nmethod` and makes it visible to the GC. This introduced a race condition where the GC might attempt to resolve a call site before it had been fixed.
>> 
>> The fix ensures that all call sites are patched **before** the `nmethod` is registered.
>> 
>> In testing, the crash previously occurred roughly 60 times in 5,000 runs (~1.2%). With this patch, no crashes were observed in the same number of runs.
>
> Chad Rakoczy 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 'origin/master' into JDK-8371046
>  - Add comment
>  - Add guarantee
>  - Clear inline caches before calling post_init
>  - Fix relocations before registering nmethod
>  - Add is_unloading() check before aquiring ic lock

Marked as reviewed by kvn (Reviewer).

Thank you. I  tentatively approve you fix waiting results of your testing.

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

PR Review: https://git.openjdk.org/jdk/pull/28241#pullrequestreview-3533089848
PR Comment: https://git.openjdk.org/jdk/pull/28241#issuecomment-3604993192

From liach at openjdk.org  Wed Dec  3 04:13:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 3 Dec 2025 04:13:55 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v3]
In-Reply-To: <5CADH75ZjadKttOKwsykRFUPlQKLiwCW8E5WkM_75a4=.fd992c8f-e8bc-4775-9ea3-d5212664e3df@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <eXO79ZBlZUltqddmReHLTSFSr3x8PiH0a5s740GHrfk=.5cf01f8f-7ac5-4def-b17d-dfd6f10e9614@github.com>
 <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com>
 <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com>
 <M5yxETmdJBlueGf6KC7P8oSAZIEeiSu8rOHAoIxu0sc=.4bc347cb-40d5-4432-bc94-38a59730183d@github.com>
 <3OE37qXGHhLAhnRQM188hhygrLYBtI3FLBMK0tGVH30=.5d1b4406-3bb3-4788-8059-e78260b79ec1@github.com>
 <kZDurlwNJsrYZRbeHLXVTKqUQcW2QGFGLE-WNN-vz4o=.44bc4d21-cc9d-4d94-b40c-4b6ad9ab11aa@github.com>
 <7WF8DlorrU_B2__G2wr43w1PZwJh8mEhD5dY10YDIOo=.ec416c38-1aff-4dd6-8792-d6a0e01f91ce@github.com>
 <E7Lwc7nwEvsmQhLMYT5Ruj5j7BhVDcfyBRUfhinUyzQ=.3293c6f1-6ce4-47d8-aa48-ba9c69ba60eb@github.com>
 <ogD0Gl3QSb1pLJUqOn877wI6asY5TW0MV7mPFlNXM5A=.8af15b77-010a-4d34-901b-928c4a3fe425@github.com>
 <_Z6KpxCYH2n3sHuT6-kRP4cSTAN3-s5UA0r
 bfrJSIgA=.e9d4089c-8329-406b-9a0a-167a24311c13@github.com>
 <cWF4r8rgGleVvKUgrzYDQ0bcj_7QhY1PulNMpZtwBcs=.abcdfd8f-9a3f-4d1f-a55f-f16ea320cf92@github.com>
 <5CADH75ZjadKttOKwsykRFUPlQKLiwCW8E5WkM_75a4=.fd992c8f-e8bc-4775-9ea3-d5212664e3df@github.com>
Message-ID: <JwKK9FX_wiYEYaRppgToqEqutrnpodk7cNJCwYLf8i0=.69cbfa2b-2c03-45ab-ad84-b9f086621bd3@github.com>

On Wed, 3 Dec 2025 01:40:29 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> any captured adaptation is valid/compatible

Yes, if `vh` is a constant, any captured adaptation from `vh.getMethodHandle(mode).asType(symbolicMethodTypeInvoker)` is valid/compatible.

For thread safety, MethodHandle supports safe publication, so I think we are fine publishing this way.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2583556067

From liach at openjdk.org  Wed Dec  3 04:13:59 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 3 Dec 2025 04:13:59 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v4]
In-Reply-To: <qZSAoBWMqcYPnd8SF41u64_b2edwi60xmEBzSMiH5eQ=.330c21a8-2720-4b9e-8947-9dfb6ad5b220@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <tl1EOBPOzkNrl3TgmEuNiH0gS5f663gwpFhHEx2P7fc=.b69f6b86-f810-4c07-b58f-b4a659b794af@github.com>
 <qZSAoBWMqcYPnd8SF41u64_b2edwi60xmEBzSMiH5eQ=.330c21a8-2720-4b9e-8947-9dfb6ad5b220@github.com>
Message-ID: <ZiSBOCO3bqyMVdVVPQFHYNILEc54-Fr0-nC4l1fS0R4=.8a41924b-8ba3-4f27-b27f-7f11f66947a4@github.com>

On Wed, 3 Dec 2025 01:53:13 GMT, Vladimir Ivanov <vlivanov at openjdk.org> 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 eight additional commits since the last revision:
>> 
>>  - Rollback getAndAdd for now
>>  - Redundant change
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache
>>  - Stage
>>  - Review tweaks
>>  - Tweak VH usage in some classes
>>  - Logical fallacy
>>  - 8160821
>
> test/micro/org/openjdk/bench/java/lang/invoke/VarHandleExact.java line 81:
> 
>> 79: 
>> 80:     @Benchmark
>> 81:     public void generic_returnDroppingInvocation() {
> 
> What about "all-generic" case (` { generic.getAndAdd(data, 42); }`)?

I can change the `generic_genericInvocation` to an all-generic case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2583556794

From dholmes at openjdk.org  Wed Dec  3 04:21:56 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 3 Dec 2025 04:21:56 GMT
Subject: RFR: 8371306: JDK-8367002 behavior might not match existing
 HotSpot behavior.
In-Reply-To: <6Rlv3LqIljnMFAoDX1kgGT1hWCVGgU-UNS-UOYIpNrU=.760472eb-f9ab-415f-8618-e596b0d50c7b@github.com>
References: <6Rlv3LqIljnMFAoDX1kgGT1hWCVGgU-UNS-UOYIpNrU=.760472eb-f9ab-415f-8618-e596b0d50c7b@github.com>
Message-ID: <ytE06-YmvRYlvMkbzYIqraXKlNiGj-3edDWizlo_7Sk=.dc94a17c-f169-4202-8927-0ead73ab91fd@github.com>

On Tue, 25 Nov 2025 18:24:42 GMT, Dean Long <dlong at openjdk.org> wrote:

> When deoptimizing to the interpreter, we need to restore the thrown exception to the original, otherwise it might be caught by the wrong handler.  In the test case, that means restoring the original ArithmeticException instead of keeping the new/recursive IllegalAccessError.

Seems simple enough, but also not an expert here.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28497#pullrequestreview-3533115624

From epeter at openjdk.org  Wed Dec  3 05:46:05 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 3 Dec 2025 05:46:05 GMT
Subject: RFR: 8351889: C2 crash: assertion failed:  Base pointers must
 match (addp 344) [v4]
In-Reply-To: <w-yCuouqlwsCiBjv5stRarSJwFeRhqRrfKT9zC0lUuk=.f782fb00-4c68-4305-ae38-1a1b1cf62108@github.com>
References: <IKOYjLXrS8q1GMjbaL2HOBNH8Oa_16k4WBa2NaMngS8=.c6fd7fbb-4758-48b2-a992-3702b2718e59@github.com>
 <w-yCuouqlwsCiBjv5stRarSJwFeRhqRrfKT9zC0lUuk=.f782fb00-4c68-4305-ae38-1a1b1cf62108@github.com>
Message-ID: <9mnRXpB16Y6Mw0TSGFJz-69m24lzCNPMC_B1_YseD4M=.be94bbba-88ce-4958-a8bd-89862d7ec2e7@github.com>

On Tue, 2 Dec 2025 09:49:29 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> The test case has an out of loop `Store` with an `AddP` address
>> expression that has other uses and is in the loop body. Schematically,
>> only showing the address subgraph and the bases for the `AddP`s:
>> 
>> 
>> Store#195 -> AddP#133 -> AddP#134 -> CastPP#110
>>                      -> CastPP#110
>> 
>> 
>> Both `AddP`s have the same base, a `CastPP` that's also in the loop
>> body.
>> 
>> That loop is a counted loop and only has 3 iterations so is fully
>> unrolled. First, one iteration is peeled:
>> 
>> 
>>                                 /-> CastPP#110
>> Store#195 -> Phi#360 -> AddP#133 -> AddP#134 -> CastPP#110
>>                     -> AddP#277 -> AddP#278 -> CastPP#283
>>                                 -> CastPP#283
>> 
>> 
>> 
>> The `AddP`s and `CastPP` are cloned (because in the loop body). As
>> part of peeling, `PhaseIdealLoop::peeled_dom_test_elim()` is
>> called. It finds the test that guards `CastPP#283` in the peeled
>> iteration dominates and replaces the test that guards `CastPP#110`
>> (the test in the peeled iteration is the clone of the test in the
>> loop). That causes `CastPP#110`'s control to be updated to that of the
>> test in the peeled iteration and to be yanked from the loop. So now
>> `CastPP#283` and `CastPP#110` have the same inputs.
>> 
>> Next unrolling happens:
>> 
>> 
>>                                            /-> CastPP#110
>>                                /-> AddP#400 -> AddP#401 -> CastPP#110
>> Store#195 -> Phi#360 -> Phi#477 -> AddP#133 -> AddP#134 -> CastPP#110
>>                   \                        -> CastPP#110
>>                    -> AddP#277 -> AddP#278 -> CastPP#283
>>                                -> CastPP#283
>> 
>> 
>> 
>> `AddP`s are cloned once more but not the `CastPP`s because they are
>> both in the peeled iteration now. A new `Phi` is added.
>> 
>> Next igvn runs. It's going to push the `AddP`s through the `Phi`s.
>> 
>> Through `Phi#477`:
>> 
>> 
>> 
>>                                 /-> CastPP#110
>> Store#195 -> Phi#360 -> AddP#510 -> Phi#509 -> AddP#401 -> CastPP#110
>>                   \                        -> AddP#134 -> CastPP#110
>>                    -> AddP#277 -> AddP#278 -> CastPP#283
>>                                -> CastPP#283
>> 
>> 
>> 
>> Through `Phi#360`:
>> 
>> 
>>                                            /-> AddP#134 -> CastPP#110
>>                                 /-> Phi#509 -> AddP#401 -> CastPP#110
>> Store#195 -> AddP#516 -> Phi#515 -> AddP#278 -> CastPP#283
>>                      -> Phi#514 -> CastPP#283
>>  ...
>
> 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 14 additional commits since the last revision:
> 
>  - more
>  - review
>  - Merge branch 'master' into JDK-8351889
>  - exp
>  - Merge branch 'master' into JDK-8351889
>  - verif
>  - Merge branch 'master' into JDK-8351889
>  - test seed
>  - more
>  - Merge branch 'master' into JDK-8351889
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/d6d17aab...15c17bb1

I think I'm on board with the solution now. It is probably best to do it during IGVN. I have a few more suggestions below :)

src/hotspot/share/opto/cfgnode.cpp line 2171:

> 2169:       !wait_for_region_igvn(phase)) {
> 2170:     // If one of the inputs is a cast that has yet to be processed by igvn, delay processing of this node to give the
> 2171:     // inputs a chance to optimize and possibly end up with identical inputs.

I think we should have more detail here. Why is this a good idea? Is this an optimization? Or is it for correctness?

I think you should say something about possibly having multiple cast nodes that could be commoned, and then they would keep their ctrl. But if we uncast, then we lose the info about the ctrl, and below we insert a new cast with a different (later) ctrl. This has two downsides:
- The ctrl is later than necessary: suboptimal
- If we have 3 or more copies of casts with the same ctrl, and now we remove two and create a new one with a different ctrl, then the remaining old and the new cast cannot common because they have different ctrl.
  - this suboptimal
  - this also creates issues along AddP paths: it can be that at some AddP we get one cast and at another AddP a different cast. They all come from the same original base address, just casted differently. But it makes it difficult to check consistency, and asserts fail.

This is not very concise yet, you can probably formulate it in a better way ;)

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

> 2074:     if (addp->in(AddPNode::Base) == n->in(AddPNode::Base)) {
> 2075:       return false;
> 2076:     }

Suggestion:

    if (!addp->is_AddP() ||
        addp->in(AddPNode::Base)->is_top() ||
        addp->in(AddPNode::Base) == n->in(AddPNode::Base)) {
      return false;
    }

test/hotspot/jtreg/compiler/c2/TestMismatchedAddPAfterMaxUnroll.java line 35:

> 33:  *                   -XX:+StressIGVN TestMismatchedAddPAfterMaxUnroll
> 34:  * @run main/othervm TestMismatchedAddPAfterMaxUnroll
> 35:  */

What about a run with our new fancy flag `-XX:VerifyIterativeGVN=10000`?

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

PR Review: https://git.openjdk.org/jdk/pull/25386#pullrequestreview-3533246147
PR Review Comment: https://git.openjdk.org/jdk/pull/25386#discussion_r2583686701
PR Review Comment: https://git.openjdk.org/jdk/pull/25386#discussion_r2583690118
PR Review Comment: https://git.openjdk.org/jdk/pull/25386#discussion_r2583697429

From epeter at openjdk.org  Wed Dec  3 05:46:06 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 3 Dec 2025 05:46:06 GMT
Subject: RFR: 8351889: C2 crash: assertion failed:  Base pointers must
 match (addp 344) [v4]
In-Reply-To: <9mnRXpB16Y6Mw0TSGFJz-69m24lzCNPMC_B1_YseD4M=.be94bbba-88ce-4958-a8bd-89862d7ec2e7@github.com>
References: <IKOYjLXrS8q1GMjbaL2HOBNH8Oa_16k4WBa2NaMngS8=.c6fd7fbb-4758-48b2-a992-3702b2718e59@github.com>
 <w-yCuouqlwsCiBjv5stRarSJwFeRhqRrfKT9zC0lUuk=.f782fb00-4c68-4305-ae38-1a1b1cf62108@github.com>
 <9mnRXpB16Y6Mw0TSGFJz-69m24lzCNPMC_B1_YseD4M=.be94bbba-88ce-4958-a8bd-89862d7ec2e7@github.com>
Message-ID: <9HDQAMPQo9VBlnXt7WpTjK51AcNHwOfHxc4t9YyBCxc=.818e962a-8898-41a1-920d-58444d70961b@github.com>

On Wed, 3 Dec 2025 05:36:52 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
>> 
>>  - more
>>  - review
>>  - Merge branch 'master' into JDK-8351889
>>  - exp
>>  - Merge branch 'master' into JDK-8351889
>>  - verif
>>  - Merge branch 'master' into JDK-8351889
>>  - test seed
>>  - more
>>  - Merge branch 'master' into JDK-8351889
>>  - ... and 4 more: https://git.openjdk.org/jdk/compare/d6d17aab...15c17bb1
>
> src/hotspot/share/opto/phaseX.cpp line 2076:
> 
>> 2074:     if (addp->in(AddPNode::Base) == n->in(AddPNode::Base)) {
>> 2075:       return false;
>> 2076:     }
> 
> Suggestion:
> 
>     if (!addp->is_AddP() ||
>         addp->in(AddPNode::Base)->is_top() ||
>         addp->in(AddPNode::Base) == n->in(AddPNode::Base)) {
>       return false;
>     }

It could be a bit compacted.

How do you imagine `verify_node_invariants_for` will grow over time? I suspect it will become a laundry-list of invariants, we continue going down through it as long as no invariant is violated. For that, it may make more sense to invert your condition, and assert/print inside the if-block. It would make the code more extendable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25386#discussion_r2583696057

From fyang at openjdk.org  Wed Dec  3 07:06:05 2025
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 3 Dec 2025 07:06:05 GMT
Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization [v7]
In-Reply-To: <4-PqNRUxM-80k4mQdYNzc0HrirtkTCjfVAzgRewW08M=.d2fe4512-16cd-4abf-8a7f-e91341c37110@github.com>
References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com>
 <4-PqNRUxM-80k4mQdYNzc0HrirtkTCjfVAzgRewW08M=.d2fe4512-16cd-4abf-8a7f-e91341c37110@github.com>
Message-ID: <kGcWuSBOv6kMw47PcGYJ6PGioE9KaT-eQq9gAEJBhbg=.3a112f23-a310-4d81-b9d5-20e33b3cd9c0@github.com>

On Mon, 1 Dec 2025 15:13:13 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> 
>> This pr add CMoveF/D on riscv, which enable vectorization of statement like: `op_1 bop op_2 ? res_f_d_1 : res_f_d_2 in a loop`.
>> 
>> This pr is also a preparation for further vectorization in https://github.com/openjdk/jdk/pull/28231.
>> 
>> Previously it's https://github.com/openjdk/jdk/pull/25341, but at that time, C2 SLP has some issue with unsigned comparison, which is now fixed, so it's good to continue the work.
>> 
>> # Test
>> ## Jtreg
>> 
>> in progress...
>> 
>> ## Performance
>> 
>> Column names meanings:
>> * p: with patch
>> * p+v: with patch, `-XX:+UseVectorCmov -XX:+UseCMoveUnconditionally` turned on
>> * m: without patch
>> * m+v: without patch, `-XX:+UseVectorCmov -XX:+UseCMoveUnconditionally` turned on
>> 
>> #### Average improvement
>> 
>> NOTE: With only this PR, it brings performance benefit in case of `CMoveF+CmpF`, `CMoveD+ComD`, `CMoveF+CmpI`, `CMoveD+CmpL`. The data below is based on fullly implmenting the vectorization of `CMoveI/L/F/D+CmpI/L/F/D`, which will be achieved by https://github.com/openjdk/jdk/pull/28231.
>> 
>> For details, check the performance data in https://github.com/openjdk/jdk/pull/25341 on riscv.
>> <google-sheets-html-origin style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
>> Opt (m/p) | Opt (m+v/p+v) | Opt (p/p+v) | Opt (m/p+v)
>> -- | -- | -- | --
>> 1.022782609 | 2.198717391 | 2.162673913 | 2.199
>> 
>> </google-sheets-html-origin>
>
> Hamlin Li has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove log_warning
>  - add test cases: BoolTest::ge/gt in enc_cmove_fp_cmp_fp

Latest version seems fine to me. Thanks for the update.
As we are very close to JDK 26 rampdown (2025/12/04), I suggest we postpone this to JDK 27.

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

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28309#pullrequestreview-3533498917

From stuefe at openjdk.org  Wed Dec  3 07:29:43 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 3 Dec 2025 07:29:43 GMT
Subject: RFR: 8363996: Obsolete UseCompressedClassPointers
Message-ID: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>

_This patch is not intended for JDK 26_. 

I'm posting it now to collect feedback and, barring any objections, plan to push it once JDK 27 opens.

This change removes the uncompressed Klass pointer mode and, with compressed Klass pointers remaining as the only option, the `UseCompressedClassPointers` switch.

For motivation, please take a look at CSR associated with the deprecation (which we did for JDK 25) and the preparatory discussion we had at the start of the year around this topic [2].

This patch is quite invasive and touches many parts of the JVM, since its goal is to remove most traces of the uncompressed Klass path and to take advantage of opportunities for simplification. In some cases, I did not take opportunities for further simplification to keep the patch somewhat legible; it will be onerous enough to review.

### Implementation Notes

With uncompressed Klass pointers removed, we have three modes of operation left (including 32-bit):
  a) 64-bit, COH off - this is the old `+UseCompressedClassPointers` mode. This is now the standard mode until we run with COH by default.
  b) 64-bit, COH on
  c) 32-bit - Here, we run with a "fake" narrow Klass pointer mode. We run with hardcoded narrowKlass base == NULL and shift = 0, so nKlass == Klass*. The difference to (a, b) is that we don't use a class space. This was implemented with JDK-8363998 [3] - for more details, please see that issue and its PR.

I ensured *arm32* builds and I performed some rudimentary checks (selected metaspace/gc tests, and a simple Spring PetClinic run). Vendors with an interest in arm32 will have to step up and do their own, more thorough unit testing. Also, I did not see anyone doing follow-up work after JDK-8363998 [3] - so some issues may still lurk from that patch as well (but maybe JDK-8363998 was just not breaking anything).

I did not check *zero 32-bit*, the only other platform supporting 32-bit. Anyone with an interest in 32-bit zero should chip in.
  
Pre-existing errors: While working on this patch, I stumbled over a few occurrences of old but benign bugs. Mostly old code assuming CompressedClassPointers and CompressedOops were still tied together (example: Arguments::set_heap_size()). These bugs are implicitly fixed with this patch.

### Testing

- tier 1 2 3 locally on Linux x64
- SAP ran their whole set of tests for all the platforms they support.


[1] https://bugs.openjdk.org/browse/JDK-8350754
[2] https://mail.openjdk.org/pipermail/hotspot-dev/2025-February/101023.html
[3] https://bugs.openjdk.org/browse/JDK-8363998

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

Commit messages:
 - Copyright fixes
 - Merge branch 'openjdk:master' into JDK-8363996-Obsolete-UseCompressedClassPointers
 - Review feedback
 - Fix after JDK-8372045
 - fix riscv build
 - fix TestVMConfigInHsErrFile
 - remove switch from global
 - fix aarch64 build
 - wip
 - close to finish
 - ... and 39 more: https://git.openjdk.org/jdk/compare/6f2169ff...64d7984a

Changes: https://git.openjdk.org/jdk/pull/28366/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28366&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8363996
  Stats: 1735 lines in 139 files changed: 64 ins; 1198 del; 473 mod
  Patch: https://git.openjdk.org/jdk/pull/28366.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28366/head:pull/28366

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

From duke at openjdk.org  Wed Dec  3 07:29:45 2025
From: duke at openjdk.org (ExE Boss)
Date: Wed, 3 Dec 2025 07:29:45 GMT
Subject: RFR: 8363996: Obsolete UseCompressedClassPointers
In-Reply-To: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
References: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
Message-ID: <olxLs_dNOwXvb6V377c53XD9KqJc-cN2F-6Dgkzi7ZA=.75cad7a2-151c-4de6-84cb-38a5f517fdbc@github.com>

On Tue, 18 Nov 2025 08:17:37 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> _This patch is not intended for JDK 26_. 
> 
> I'm posting it now to collect feedback and, barring any objections, plan to push it once JDK 27 opens.
> 
> This change removes the uncompressed Klass pointer mode and, with compressed Klass pointers remaining as the only option, the `UseCompressedClassPointers` switch.
> 
> For motivation, please take a look at CSR associated with the deprecation (which we did for JDK 25) and the preparatory discussion we had at the start of the year around this topic [2].
> 
> This patch is quite invasive and touches many parts of the JVM, since its goal is to remove most traces of the uncompressed Klass path and to take advantage of opportunities for simplification. In some cases, I did not take opportunities for further simplification to keep the patch somewhat legible; it will be onerous enough to review.
> 
> ### Implementation Notes
> 
> With uncompressed Klass pointers removed, we have three modes of operation left (including 32-bit):
>   a) 64-bit, COH off - this is the old `+UseCompressedClassPointers` mode. This is now the standard mode until we run with COH by default.
>   b) 64-bit, COH on
>   c) 32-bit - Here, we run with a "fake" narrow Klass pointer mode. We run with hardcoded narrowKlass base == NULL and shift = 0, so nKlass == Klass*. The difference to (a, b) is that we don't use a class space. This was implemented with JDK-8363998 [3] - for more details, please see that issue and its PR.
> 
> I ensured *arm32* builds and I performed some rudimentary checks (selected metaspace/gc tests, and a simple Spring PetClinic run). Vendors with an interest in arm32 will have to step up and do their own, more thorough unit testing. Also, I did not see anyone doing follow-up work after JDK-8363998 [3] - so some issues may still lurk from that patch as well (but maybe JDK-8363998 was just not breaking anything).
> 
> I did not check *zero 32-bit*, the only other platform supporting 32-bit. Anyone with an interest in 32-bit zero should chip in.
>   
> Pre-existing errors: While working on this patch, I stumbled over a few occurrences of old but benign bugs. Mostly old code assuming CompressedClassPointers and CompressedOops were still tied together (example: Arguments::set_heap_size()). These bugs are implicitly fixed with this patch.
> 
> ### Testing
> 
> - tier 1 2 3 locally on Linux x64
> - SAP ran their whole set of tests for all the platforms they support.
> 
> 
> [1] https://bugs.openjdk.org/browse/JDK-8350754
> [2] https://mail.openjdk.org/pipermail/hotspot-dev/2025-February...

These?comments probably?apply to?many?other locations:

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

But?the?changes should?probably be?done in?a?separate?PR, if?at?all.

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 4919:

> 4917:   } else {
> 4918:     ldrw(dst, Address(src, oopDesc::klass_offset_in_bytes()));
> 4919:     decode_klass_not_null(dst);

The `decode_klass_not_null(dst)` call is?now?common to?all?branches, so?it?can be?moved outside:

if (UseCompactObjectHeaders) {
	load_narrow_klass_compact(dst, src);
} else {
	ldrw(dst, Address(src, oopDesc::klass_offset_in_bytes()));
}
decode_klass_not_null(dst);

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 4998:

> 4996:     ldrw(tmp1, Address(obj1, oopDesc::klass_offset_in_bytes()));
> 4997:     ldrw(tmp2, Address(obj2, oopDesc::klass_offset_in_bytes()));
> 4998:     cmpw(tmp1, tmp2);

Same?here, but?with `cmpw(tmp1,?tmp2)`.

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

PR Review: https://git.openjdk.org/jdk/pull/28366#pullrequestreview-3484591668
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2543442496
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2543444838

From stuefe at openjdk.org  Wed Dec  3 07:29:47 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 3 Dec 2025 07:29:47 GMT
Subject: RFR: 8363996: Obsolete UseCompressedClassPointers
In-Reply-To: <olxLs_dNOwXvb6V377c53XD9KqJc-cN2F-6Dgkzi7ZA=.75cad7a2-151c-4de6-84cb-38a5f517fdbc@github.com>
References: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
 <olxLs_dNOwXvb6V377c53XD9KqJc-cN2F-6Dgkzi7ZA=.75cad7a2-151c-4de6-84cb-38a5f517fdbc@github.com>
Message-ID: <ZjHdtQxrx1jfYPKwpqEUfyZEkwZwUy3beLEEtDN7Fz4=.b110fae0-c345-4406-bda4-2823200deb43@github.com>

On Wed, 19 Nov 2025 20:22:19 GMT, ExE Boss <duke at openjdk.org> wrote:

>> _This patch is not intended for JDK 26_. 
>> 
>> I'm posting it now to collect feedback and, barring any objections, plan to push it once JDK 27 opens.
>> 
>> This change removes the uncompressed Klass pointer mode and, with compressed Klass pointers remaining as the only option, the `UseCompressedClassPointers` switch.
>> 
>> For motivation, please take a look at CSR associated with the deprecation (which we did for JDK 25) and the preparatory discussion we had at the start of the year around this topic [2].
>> 
>> This patch is quite invasive and touches many parts of the JVM, since its goal is to remove most traces of the uncompressed Klass path and to take advantage of opportunities for simplification. In some cases, I did not take opportunities for further simplification to keep the patch somewhat legible; it will be onerous enough to review.
>> 
>> ### Implementation Notes
>> 
>> With uncompressed Klass pointers removed, we have three modes of operation left (including 32-bit):
>>   a) 64-bit, COH off - this is the old `+UseCompressedClassPointers` mode. This is now the standard mode until we run with COH by default.
>>   b) 64-bit, COH on
>>   c) 32-bit - Here, we run with a "fake" narrow Klass pointer mode. We run with hardcoded narrowKlass base == NULL and shift = 0, so nKlass == Klass*. The difference to (a, b) is that we don't use a class space. This was implemented with JDK-8363998 [3] - for more details, please see that issue and its PR.
>> 
>> I ensured *arm32* builds and I performed some rudimentary checks (selected metaspace/gc tests, and a simple Spring PetClinic run). Vendors with an interest in arm32 will have to step up and do their own, more thorough unit testing. Also, I did not see anyone doing follow-up work after JDK-8363998 [3] - so some issues may still lurk from that patch as well (but maybe JDK-8363998 was just not breaking anything).
>> 
>> I did not check *zero 32-bit*, the only other platform supporting 32-bit. Anyone with an interest in 32-bit zero should chip in.
>>   
>> Pre-existing errors: While working on this patch, I stumbled over a few occurrences of old but benign bugs. Mostly old code assuming CompressedClassPointers and CompressedOops were still tied together (example: Arguments::set_heap_size()). These bugs are implicitly fixed with this patch.
>> 
>> ### Testing
>> 
>> - tier 1 2 3 locally on Linux x64
>> - SAP ran their whole set of tests for all the platforms they support.
>> 
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8350754
>> [2...
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 4998:
> 
>> 4996:     ldrw(tmp1, Address(obj1, oopDesc::klass_offset_in_bytes()));
>> 4997:     ldrw(tmp2, Address(obj2, oopDesc::klass_offset_in_bytes()));
>> 4998:     cmpw(tmp1, tmp2);
> 
> Same?here, but?with `cmpw(tmp1,?tmp2)`.

I did your suggested changes, but will hold on doing similar changes (moving instructions out of now common branches) for now; I feel that this makes the diff less clear, and this PR will be annoying to review as it is; lots of onerous work. Let's hear what others think once I undrafted this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2581326249

From epeter at openjdk.org  Wed Dec  3 08:01:06 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 3 Dec 2025 08:01:06 GMT
Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization [v7]
In-Reply-To: <4-PqNRUxM-80k4mQdYNzc0HrirtkTCjfVAzgRewW08M=.d2fe4512-16cd-4abf-8a7f-e91341c37110@github.com>
References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com>
 <4-PqNRUxM-80k4mQdYNzc0HrirtkTCjfVAzgRewW08M=.d2fe4512-16cd-4abf-8a7f-e91341c37110@github.com>
Message-ID: <4nP7XPYsi87jqsutMCdufFx4Jz6aa-X_pPpjd_uGoG0=.8ce4119b-c3bb-4cc3-b714-ccbeb9ac7f42@github.com>

On Mon, 1 Dec 2025 15:13:13 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> 
>> This pr add CMoveF/D on riscv, which enable vectorization of statement like: `op_1 bop op_2 ? res_f_d_1 : res_f_d_2 in a loop`.
>> 
>> This pr is also a preparation for further vectorization in https://github.com/openjdk/jdk/pull/28231.
>> 
>> Previously it's https://github.com/openjdk/jdk/pull/25341, but at that time, C2 SLP has some issue with unsigned comparison, which is now fixed, so it's good to continue the work.
>> 
>> # Test
>> ## Jtreg
>> 
>> in progress...
>> 
>> ## Performance
>> 
>> Column names meanings:
>> * p: with patch
>> * p+v: with patch, `-XX:+UseVectorCmov -XX:+UseCMoveUnconditionally` turned on
>> * m: without patch
>> * m+v: without patch, `-XX:+UseVectorCmov -XX:+UseCMoveUnconditionally` turned on
>> 
>> #### Average improvement
>> 
>> NOTE: With only this PR, it brings performance benefit in case of `CMoveF+CmpF`, `CMoveD+ComD`, `CMoveF+CmpI`, `CMoveD+CmpL`. The data below is based on fullly implmenting the vectorization of `CMoveI/L/F/D+CmpI/L/F/D`, which will be achieved by https://github.com/openjdk/jdk/pull/28231.
>> 
>> For details, check the performance data in https://github.com/openjdk/jdk/pull/25341 on riscv.
>> <google-sheets-html-origin style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
>> Opt (m/p) | Opt (m+v/p+v) | Opt (p/p+v) | Opt (m/p+v)
>> -- | -- | -- | --
>> 1.022782609 | 2.198717391 | 2.162673913 | 2.199
>> 
>> </google-sheets-html-origin>
>
> Hamlin Li has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove log_warning
>  - add test cases: BoolTest::ge/gt in enc_cmove_fp_cmp_fp

I can help review this as well, but currently there is a lot going on with JDK26 bugs. Hopefully things settle down in a few weeks.

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

PR Comment: https://git.openjdk.org/jdk/pull/28309#issuecomment-3605543510

From mbaesken at openjdk.org  Wed Dec  3 08:09:12 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 3 Dec 2025 08:09:12 GMT
Subject: RFR: 8371893: [macOS] use dead_strip linker option to reduce
 binary size [v5]
In-Reply-To: <AGacEUKglaOEHAh2He4z3f3sXfJjimF8q-2yzLRnlhM=.c14c4fce-8f81-4eb0-8be3-c87caab5f74a@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
 <AGacEUKglaOEHAh2He4z3f3sXfJjimF8q-2yzLRnlhM=.c14c4fce-8f81-4eb0-8be3-c87caab5f74a@github.com>
Message-ID: <jtI9qujDvqKs-Lva7WzXQbk_pXhsIdwWrMJjL-KTnFc=.5d4c0f2b-c205-4997-9285-19bae53dea0a@github.com>

On Tue, 25 Nov 2025 13:12:06 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols.
>> Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) :
>> (before -> after setting the option)
>> 
>> 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib
>> 264K -> 248K images/jdk/lib/libjavajpeg.dylib
>> 152K -> 132K images/jdk/lib/libjli.dylib
>> 388K -> 296K images/jdk/lib/liblcms.dylib
>> 164K -> 128K images/jdk/lib/libzip.dylib
>> 
>> 
>> and libjvm :
>> 
>> 20M -> 18M images/jdk/lib/server/libjvm.dylib
>> 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use dead_strip on macOS arrch64 AND x86_64

Thanks for testing !

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

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3605564159

From mbaesken at openjdk.org  Wed Dec  3 08:09:13 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 3 Dec 2025 08:09:13 GMT
Subject: Integrated: 8371893: [macOS] use dead_strip linker option to reduce
 binary size
In-Reply-To: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
Message-ID: <68YkLbtPCCMXMUfLNYA7pIL4eP7ZqOWno0eOeMo7W6s=.bf818f36-049f-4cb4-8ac0-d0b83776dec7@github.com>

On Fri, 14 Nov 2025 11:25:05 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols.
> Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) :
> (before -> after setting the option)
> 
> 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib
> 264K -> 248K images/jdk/lib/libjavajpeg.dylib
> 152K -> 132K images/jdk/lib/libjli.dylib
> 388K -> 296K images/jdk/lib/liblcms.dylib
> 164K -> 128K images/jdk/lib/libzip.dylib
> 
> 
> and libjvm :
> 
> 20M -> 18M images/jdk/lib/server/libjvm.dylib
> 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM

This pull request has now been integrated.

Changeset: 8f3d0ade
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8f3d0ade11ddb45bb1719b6818e1b51df237a59b
Stats:     3 lines in 1 file changed: 3 ins; 0 del; 0 mod

8371893: [macOS] use dead_strip linker option to reduce binary size

Reviewed-by: erikj, lucy, serb

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

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

From duke at openjdk.org  Wed Dec  3 08:37:02 2025
From: duke at openjdk.org (Harshit470250)
Date: Wed, 3 Dec 2025 08:37:02 GMT
Subject: RFR: 8347396: Efficient TypeFunc creations [v3]
In-Reply-To: <VQs3SMtk1y6xTi8nCvTeWsTFfCQlTJtDdCGnfWQmRmw=.f3b33ba1-3efe-477b-b6d2-b43faae9ee2b@github.com>
References: <VQs3SMtk1y6xTi8nCvTeWsTFfCQlTJtDdCGnfWQmRmw=.f3b33ba1-3efe-477b-b6d2-b43faae9ee2b@github.com>
Message-ID: <da-a4Id_azWgrrTjDQEeYR6rm4D2l5jZAHIMx9x4v4w=.38b3a577-a776-49c4-8afb-27c684c126ad@github.com>

> This PR do similar changes done by [JDK-8330851](https://bugs.openjdk.org/browse/JDK-8330851) on the GC TypeFunc creation as suggested by [JDK-8347396](https://bugs.openjdk.org/browse/JDK-8347396). As discussed in [https://github.com/openjdk/jdk/pull/21782#discussion_r1906535686,](https://github.com/openjdk/jdk/pull/21782#discussion_r1906535686) I have put guard on the shenandoah gc specific part of the code.

Harshit470250 has updated the pull request incrementally with 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

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27279/files
  - new: https://git.openjdk.org/jdk/pull/27279/files/6e6a2bbf..4dfa36ca

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

  Stats: 145 lines in 5 files changed: 67 ins; 73 del; 5 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 sspitsyn at openjdk.org  Wed Dec  3 08:44:50 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 3 Dec 2025 08:44:50 GMT
Subject: RFR: 6960970: Debugger very slow during stepping [v6]
In-Reply-To: <gFgkgW9blz_tD337KoxIvOECPeJaQ-LfhifJiaosDjw=.11fda5cd-baae-48bb-a12e-4018eeb5cd15@github.com>
References: <gFgkgW9blz_tD337KoxIvOECPeJaQ-LfhifJiaosDjw=.11fda5cd-baae-48bb-a12e-4018eeb5cd15@github.com>
Message-ID: <enBp5r41RtxIz_QNIu2bh3Y4ZMxC46hcrEM1B1UXxdc=.ba77ca00-b28b-495e-9e0f-d627a4b3f2e2@github.com>

> This change fixes a long standing performance issue related to the debugger single stepping that is using JVMTI `FramePop` events as a part of step over handling. The performance issue is that the target thread continues its execution in very slow `interp-only` mode in a context of frame marked for `FramePop` notification with the JVMTI `NotifyFramePop`. It includes other method calls recursively upon a return from the frame.
> 
> This fix is to avoid enforcing the `interp-only` execution mode for threads when `FramePop` events are enabled with the JVMTI `SetEventNotificationMode()`. Instead, the target frame has been deoptimized and kept interpreted by disabling `OSR` optimization by the function `InterpreterRuntime::frequency_counter_overflow_inner()`. (Big thanks to @fisk for this suggestion!) Additionally, some tweaks are applied in several places where the `java_thread->is_interp_only_mode()` is checked.
> The other details will be provided in the first PR request comment.
> 
> Testing:
>  - test `serviceability/jvmti/vthread/ThreadStateTest` was updated to provide some extra test coverage
>  - submitted mach5 tiers 1-6

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

  review: optimize hide_single_stepping and post_method_exit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28407/files
  - new: https://git.openjdk.org/jdk/pull/28407/files/d82e4efe..bb4b11f9

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

  Stats: 14 lines in 1 file changed: 5 ins; 3 del; 6 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 sspitsyn at openjdk.org  Wed Dec  3 08:50:03 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 3 Dec 2025 08:50:03 GMT
Subject: RFR: 6960970: Debugger very slow during stepping [v7]
In-Reply-To: <gFgkgW9blz_tD337KoxIvOECPeJaQ-LfhifJiaosDjw=.11fda5cd-baae-48bb-a12e-4018eeb5cd15@github.com>
References: <gFgkgW9blz_tD337KoxIvOECPeJaQ-LfhifJiaosDjw=.11fda5cd-baae-48bb-a12e-4018eeb5cd15@github.com>
Message-ID: <U_9kRmJrY4s0NTSuTkzZctskhApUlSkJhbldVf1bZ3g=.5ea5a021-752a-4b1f-99c3-a1d193198291@github.com>

> This change fixes a long standing performance issue related to the debugger single stepping that is using JVMTI `FramePop` events as a part of step over handling. The performance issue is that the target thread continues its execution in very slow `interp-only` mode in a context of frame marked for `FramePop` notification with the JVMTI `NotifyFramePop`. It includes other method calls recursively upon a return from the frame.
> 
> This fix is to avoid enforcing the `interp-only` execution mode for threads when `FramePop` events are enabled with the JVMTI `SetEventNotificationMode()`. Instead, the target frame has been deoptimized and kept interpreted by disabling `OSR` optimization by the function `InterpreterRuntime::frequency_counter_overflow_inner()`. (Big thanks to @fisk for this suggestion!) Additionally, some tweaks are applied in several places where the `java_thread->is_interp_only_mode()` is checked.
> The other details will be provided in the first PR request comment.
> 
> Testing:
>  - test `serviceability/jvmti/vthread/ThreadStateTest` was updated to provide some extra test coverage
>  - submitted mach5 tiers 1-6

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

 - 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
 - cleanup: removed an old code fragment in frame.cpp
 - 6960970: Debugger very slow during stepping

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28407/files
  - new: https://git.openjdk.org/jdk/pull/28407/files/bb4b11f9..abb1950c

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

  Stats: 64652 lines in 1068 files changed: 42639 ins; 15493 del; 6520 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 clanger at openjdk.org  Wed Dec  3 08:57:57 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 3 Dec 2025 08:57:57 GMT
Subject: RFR: 8351842: Windows specific issues in combination of JEP 493
 and --with-external-symbols-in-bundles=public [v6]
In-Reply-To: <huhCl0rPGZES4M2bmzw3UNOSr9o3ZZJeMxKJ32-4aiY=.56837106-54a9-489d-a66c-b301ed27f53b@github.com>
References: <R-zg2t6gMm9oZgSijkRxJ0ErqtvoFeqPyfUGbhZRkEQ=.17b0ed93-ea7b-4a37-8471-12624c937a71@github.com>
 <7xjbY7Wkdo7ImiFeTdjUWgYkB-7155QLLxtZ13M3-Io=.d86b647e-6335-43ea-bf1c-ccd2113e74dd@github.com>
 <huhCl0rPGZES4M2bmzw3UNOSr9o3ZZJeMxKJ32-4aiY=.56837106-54a9-489d-a66c-b301ed27f53b@github.com>
Message-ID: <g5yQzsFb450W-yrRwgo_hII22Ul4KPlEZR_Fg1Ghkhw=.8df91669-e895-4242-8473-c08e43421df9@github.com>

On Mon, 1 Dec 2025 15:17:13 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Christoph Langer has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Cleanup comment
>>  - Fix pdb filtering for JMODs build
>
> make/CreateJmods.gmk line 72:
> 
>> 70:         DEST := $(LIBS_DIR_FILTERED), \
>> 71:         FILES := $(FILES_LIBS), \
>> 72:         NAME_MACRO := rename_stripped \
> 
> These trailing commas were deliberate and are part of the [Code Conventions for the Build System](https://openjdk.org/groups/build/doc/code-conventions.html) (17, though it's not very clearly stated).

ok, fixed.

> make/Images.gmk line 313:
> 
>> 311:   $(call SetupCopyStrippedDebuginfo,JDK)
>> 312:   $(call SetupCopyStrippedDebuginfo,JRE)
>> 313: endif
> 
> I might be missing something, but why is this needed? Shouldn't the public pdbs already be part of the jmods in this case and so would get linked into the image by jlink?

You are right. And this seems to work with linkable runtime as well. So I removed that part.

> make/Images.gmk line 322:
> 
>> 320:       $(eval DBGFILES := $(if $(filter true+public,$(call isTargetOs,windows)+$(SHIP_DEBUG_SYMBOLS)), \
>> 321:         $(filter-out %.stripped.pdb,$(DBGFILES)),$(DBGFILES)) \
>> 322:       ) \
> 
> I think I would use lower case for `DBGFILES` to signify a local variable and reduce risk of clashing with any other variable in the current context.

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24012#discussion_r2584191011
PR Review Comment: https://git.openjdk.org/jdk/pull/24012#discussion_r2584193678
PR Review Comment: https://git.openjdk.org/jdk/pull/24012#discussion_r2584195087

From dlong at openjdk.org  Wed Dec  3 09:05:06 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 3 Dec 2025 09:05:06 GMT
Subject: RFR: 8371306: JDK-8367002 behavior might not match existing
 HotSpot behavior.
In-Reply-To: <ytE06-YmvRYlvMkbzYIqraXKlNiGj-3edDWizlo_7Sk=.dc94a17c-f169-4202-8927-0ead73ab91fd@github.com>
References: <6Rlv3LqIljnMFAoDX1kgGT1hWCVGgU-UNS-UOYIpNrU=.760472eb-f9ab-415f-8618-e596b0d50c7b@github.com>
 <ytE06-YmvRYlvMkbzYIqraXKlNiGj-3edDWizlo_7Sk=.dc94a17c-f169-4202-8927-0ead73ab91fd@github.com>
Message-ID: <DuM4m9c51hhUk48Ifa-d6IGW5HRB7wUUIMepH_J2Yt4=.c8b2c498-e4ea-4213-b412-04288f216e29@github.com>

On Wed, 3 Dec 2025 04:19:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> When deoptimizing to the interpreter, we need to restore the thrown exception to the original, otherwise it might be caught by the wrong handler.  In the test case, that means restoring the original ArithmeticException instead of keeping the new/recursive IllegalAccessError.
>
> Seems simple enough, but also not an expert here.
> 
> Thanks

Thanks @dholmes-ora .

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

PR Comment: https://git.openjdk.org/jdk/pull/28497#issuecomment-3605766160

From dlong at openjdk.org  Wed Dec  3 09:05:08 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 3 Dec 2025 09:05:08 GMT
Subject: Integrated: 8371306: JDK-8367002 behavior might not match existing
 HotSpot behavior.
In-Reply-To: <6Rlv3LqIljnMFAoDX1kgGT1hWCVGgU-UNS-UOYIpNrU=.760472eb-f9ab-415f-8618-e596b0d50c7b@github.com>
References: <6Rlv3LqIljnMFAoDX1kgGT1hWCVGgU-UNS-UOYIpNrU=.760472eb-f9ab-415f-8618-e596b0d50c7b@github.com>
Message-ID: <l7hPU4S1y6XBnaO7Amkr8EcfzEE0imB_qu6q2z7xhT4=.4bc426de-22e2-4f61-a59d-57cf09a9f8f9@github.com>

On Tue, 25 Nov 2025 18:24:42 GMT, Dean Long <dlong at openjdk.org> wrote:

> When deoptimizing to the interpreter, we need to restore the thrown exception to the original, otherwise it might be caught by the wrong handler.  In the test case, that means restoring the original ArithmeticException instead of keeping the new/recursive IllegalAccessError.

This pull request has now been integrated.

Changeset: a1e86941
Author:    Dean Long <dlong at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a1e8694109ad87690e18fc03d17b6b9519092d81
Stats:     13 lines in 3 files changed: 10 ins; 0 del; 3 mod

8371306: JDK-8367002 behavior might not match existing HotSpot behavior.

Reviewed-by: thartmann, dholmes

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

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

From iwalulya at openjdk.org  Wed Dec  3 09:24:55 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Wed, 3 Dec 2025 09:24:55 GMT
Subject: RFR: 8372179: Remove Unused ConcurrentHashTable::MultiGetHandle
In-Reply-To: <q-Y1GRBQYb90aqz6gCUsmyO_g3jwKsq5M2qIv2mOmz0=.152c826e-0089-4230-8fa2-54f7bd322a52@github.com>
References: <q-Y1GRBQYb90aqz6gCUsmyO_g3jwKsq5M2qIv2mOmz0=.152c826e-0089-4230-8fa2-54f7bd322a52@github.com>
Message-ID: <3oYw-dGliUDEzEiC_Xrm4f5zjJTmxxYwZyPxDp8i0QU=.aaf67c3d-fe98-4fb0-b148-f2877791ed40@github.com>

On Wed, 19 Nov 2025 15:58:07 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review the removal of `ConcurrentHashTable::MultiGetHandle` which is never used anywhere but in gtests.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

Marked as reviewed by iwalulya (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28396#pullrequestreview-3534013654

From clanger at openjdk.org  Wed Dec  3 09:54:38 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 3 Dec 2025 09:54:38 GMT
Subject: RFR: 8351842: Windows specific issues in combination of JEP 493
 and --with-external-symbols-in-bundles=public [v7]
In-Reply-To: <R-zg2t6gMm9oZgSijkRxJ0ErqtvoFeqPyfUGbhZRkEQ=.17b0ed93-ea7b-4a37-8471-12624c937a71@github.com>
References: <R-zg2t6gMm9oZgSijkRxJ0ErqtvoFeqPyfUGbhZRkEQ=.17b0ed93-ea7b-4a37-8471-12624c937a71@github.com>
Message-ID: <GmCc0zKQhuTx4s7vzyjFA2gztgss7VxwcAFOUkw8ifw=.c4f69a8c-1407-45d7-a17f-59e1af2578f8@github.com>

> This PR addresses an issue that can be observed when building on Windows with configure options `--enable-linkable-runtime` and `--with-external-symbols-in-bundles=public`.
> 
> The problem is that with this special build configuration, we build two sets of .pdb files for the binaries. The first set is the standard debug symbols files named <binary-name>.pdb. The second set consists of stripped debug symbols file called <binary-name>.stripped.pdb which have less information but enough to present line numbers in hs-err files.
> 
> During build we use the *.stripped.pdb files for compiling the jmods and also the bundle files. However, in the images folder, both sets of .pdb files exist. The tests for runtime linking will now, in the absence of jmod files, pick up the .pdb files (without *stripped*) from images, but in the runtime the hashes of the *stripped* files are stored.
> 
> With this change, the standard .pdb files in the `--with-external-symbols-in-bundles=public` configuration are now the stripped files and we create a set of full pdb files named *.full.pdb. Jmods and Bundles still contain the stripped pdb files and we also fix the issue that the debug symbols bundle also contained stripped pdb files so far. With this fix, it will contain the full pdb files and extracting these over a JDK runtime will replace stripped pdbs with full pdbs.

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

  Review feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24012/files
  - new: https://git.openjdk.org/jdk/pull/24012/files/ca92b6a1..c3e29e5c

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

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

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

From clanger at openjdk.org  Wed Dec  3 09:54:39 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 3 Dec 2025 09:54:39 GMT
Subject: RFR: 8351842: Windows specific issues in combination of JEP 493
 and --with-external-symbols-in-bundles=public [v6]
In-Reply-To: <huhCl0rPGZES4M2bmzw3UNOSr9o3ZZJeMxKJ32-4aiY=.56837106-54a9-489d-a66c-b301ed27f53b@github.com>
References: <R-zg2t6gMm9oZgSijkRxJ0ErqtvoFeqPyfUGbhZRkEQ=.17b0ed93-ea7b-4a37-8471-12624c937a71@github.com>
 <7xjbY7Wkdo7ImiFeTdjUWgYkB-7155QLLxtZ13M3-Io=.d86b647e-6335-43ea-bf1c-ccd2113e74dd@github.com>
 <huhCl0rPGZES4M2bmzw3UNOSr9o3ZZJeMxKJ32-4aiY=.56837106-54a9-489d-a66c-b301ed27f53b@github.com>
Message-ID: <GPavItGemfCK-A-Bmn2PpbMlwzvMbX1CLK89XxBL_tA=.4a5696df-3fe6-4133-87aa-18303905be1a@github.com>

On Mon, 1 Dec 2025 19:33:06 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> From what I can tell, this is also removing the full debug symbols from the actual JDK/JRE images in all cases and all platforms, so they actually match the bundles. I think that's ok, but it needs to be clearly stated somewhere, at least in the bug, for future reference of when that happened.

Yes, you are right. I added a sentence to the JBS bug.

I also implemented your feedback, please look again.

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

PR Comment: https://git.openjdk.org/jdk/pull/24012#issuecomment-3605978192

From kevinw at openjdk.org  Wed Dec  3 10:05:30 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 3 Dec 2025 10:05:30 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v11]
In-Reply-To: <dGQiREV1bRcNuIAhjHDSSsR6369oD24FlT7Ud1U2_ok=.8aa2ac09-dc96-48b0-8de2-e3ca6457386f@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <dGQiREV1bRcNuIAhjHDSSsR6369oD24FlT7Ud1U2_ok=.8aa2ac09-dc96-48b0-8de2-e3ca6457386f@github.com>
Message-ID: <CUcdfulNom90fhuZZOM5TtD3CaxWXOKXuiLHNET5AmQ=.06bb6eba-ec1f-42c8-82c0-7cba07d1d32e@github.com>

On Wed, 26 Nov 2025 20:35:11 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
>> 
>> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
>> 
>> TRUE
>> FALSE
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed spaces and CRLF

src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 78:

> 76:    * <p>For more information about creating and using the AOT artifacts, and detailed
> 77:    * specification of the corresponding JVM command-line options, please refer
> 78:    * to <a href="https://openjdk.org/jeps/483">483</a> and <a href="https://openjdk.org/jeps/514">514</a>.

One more late nit: these links have just the raw number in the link text. Better to have:

* to <a href="https://openjdk.org/jeps/483">JEP 483</a> and <a href="https://openjdk.org/jeps/514">JEP 514</a>.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2584438379

From cnorrbin at openjdk.org  Wed Dec  3 10:08:50 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Wed, 3 Dec 2025 10:08:50 GMT
Subject: RFR: 8372615: Many container tests fail when running rootless on
 cgroup v1 [v2]
In-Reply-To: <pEceZpCbgMCqwPQoKiGcLgFlv-UpLg5Rv4PcHclFRKQ=.822a2343-fe24-4384-9214-f88c80a103a0@github.com>
References: <vMiWENH7dMmRw5miQHPYNnETLlwMgklDZyGxk_JCPu4=.a98f9e35-3bb4-4aaf-b89b-a2547c4e6f29@github.com>
 <pEceZpCbgMCqwPQoKiGcLgFlv-UpLg5Rv4PcHclFRKQ=.822a2343-fe24-4384-9214-f88c80a103a0@github.com>
Message-ID: <zDsykp-YyLiCkLehUHngSG-fLkyS3xk1DBm0XQGql6A=.bd8215b4-49fb-473a-8b34-02854bdaa8b9@github.com>

On Mon, 1 Dec 2025 12:45:06 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> Many container tests verify that various resource limits work as expected. However, when running containers in rootless mode on both Docker and Podman with cgroup v1, resource limits are not supported. This causes tests to fail with error messages like: `Resource limits are not supported and ignored on cgroups V1 rootless systems`.
>> 
>> To address this, we should skip these tests when running on configurations that don't support resource limits, similar to how we already handle other unsupported configurations (e.g., missing container engine or incompatibility with a specific cgroup version or container runtime).
>> 
>> To check for this, we now need to use `Metrics.systemMetrics().getProvider()` from `jdk.internal.platform.Metrics` to detect cgroup v1. I've added this functionality to `DockerTestUtils`, which is already used by all container tests. As a result, all container tests now need to include the `java.base/jdk.internal.platform` module, even if they don't directly test resource limits.
>> 
>> Testing:
>> * Oracle tiers 1-5
>> * Local testing:
>>   - `hotspot/jtreg/containers/` 
>>   - `jdk/jdk/internal/platform/docker/`
>> on cgroup v1/v2 with Podman and Docker in both rootful and rootless configurations
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reworked check docker/resourcelimit functions

Thank you for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/28557#issuecomment-3606036558

From cnorrbin at openjdk.org  Wed Dec  3 10:08:51 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Wed, 3 Dec 2025 10:08:51 GMT
Subject: Integrated: 8372615: Many container tests fail when running rootless
 on cgroup v1
In-Reply-To: <vMiWENH7dMmRw5miQHPYNnETLlwMgklDZyGxk_JCPu4=.a98f9e35-3bb4-4aaf-b89b-a2547c4e6f29@github.com>
References: <vMiWENH7dMmRw5miQHPYNnETLlwMgklDZyGxk_JCPu4=.a98f9e35-3bb4-4aaf-b89b-a2547c4e6f29@github.com>
Message-ID: <tOoj-MIEKUKTnUIgsR9lC93aEbBGyI5TMlhszWcSkes=.8716b906-2f74-4d90-b7db-55855d23fd4a@github.com>

On Fri, 28 Nov 2025 15:03:25 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> Many container tests verify that various resource limits work as expected. However, when running containers in rootless mode on both Docker and Podman with cgroup v1, resource limits are not supported. This causes tests to fail with error messages like: `Resource limits are not supported and ignored on cgroups V1 rootless systems`.
> 
> To address this, we should skip these tests when running on configurations that don't support resource limits, similar to how we already handle other unsupported configurations (e.g., missing container engine or incompatibility with a specific cgroup version or container runtime).
> 
> To check for this, we now need to use `Metrics.systemMetrics().getProvider()` from `jdk.internal.platform.Metrics` to detect cgroup v1. I've added this functionality to `DockerTestUtils`, which is already used by all container tests. As a result, all container tests now need to include the `java.base/jdk.internal.platform` module, even if they don't directly test resource limits.
> 
> Testing:
> * Oracle tiers 1-5
> * Local testing:
>   - `hotspot/jtreg/containers/` 
>   - `jdk/jdk/internal/platform/docker/`
> on cgroup v1/v2 with Podman and Docker in both rootful and rootless configurations

This pull request has now been integrated.

Changeset: f1a4d1bf
Author:    Casper Norrbin <cnorrbin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f1a4d1bfde652cf758117b93bbd02ae8248e805e
Stats:     154 lines in 27 files changed: 29 ins; 71 del; 54 mod

8372615: Many container tests fail when running rootless on cgroup v1

Reviewed-by: sgehwolf, dholmes

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

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

From duke at openjdk.org  Wed Dec  3 10:13:14 2025
From: duke at openjdk.org (Ruben)
Date: Wed, 3 Dec 2025 10:13:14 GMT
Subject: RFR: 8372942: AArch64: Set JVM flags for Neoverse V3AE core
Message-ID: <E0Fdz0OrKiYwvHaBVOUns9YCtHKwl8lBZrIC6UYZj-o=.1652733f-4423-415c-a621-22118aa464cc@github.com>

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.

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

Commit messages:
 - 8372942: AArch64: Set JVM flags for Neoverse V3AE core

Changes: https://git.openjdk.org/jdk/pull/28607/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28607&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372942
  Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 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 ysuenaga at openjdk.org  Wed Dec  3 10:27:04 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Wed, 3 Dec 2025 10:27:04 GMT
Subject: RFR: 8371014: Dump JFR recording on CrashOnOutOfMemoryError is
 incorrectly implemented
Message-ID: <SiBemHHhiHk3uDElvjRK16U2SNea7P1wsptA_4z7kxA=.0746951f-41b4-46b4-8397-40603dea6298@github.com>

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.

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

Commit messages:
 - Fix typo
 - Delete TestEmergencyDumpAtOOM.java from ProblemList
 - 8371014: Dump JFR recording on CrashOnOutOfMemoryError is incorrectly implemented

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

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

From mbaesken at openjdk.org  Wed Dec  3 10:27:05 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 3 Dec 2025 10:27:05 GMT
Subject: RFR: 8371014: Dump JFR recording on CrashOnOutOfMemoryError is
 incorrectly implemented
In-Reply-To: <SiBemHHhiHk3uDElvjRK16U2SNea7P1wsptA_4z7kxA=.0746951f-41b4-46b4-8397-40603dea6298@github.com>
References: <SiBemHHhiHk3uDElvjRK16U2SNea7P1wsptA_4z7kxA=.0746951f-41b4-46b4-8397-40603dea6298@github.com>
Message-ID: <bZdqbLu_C8RrX6GWWFGMJiAZLsIfAuoshaAth5QggLY=.7394a63c-1a10-4450-81d0-1b3bc45ae146@github.com>

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

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

With your PR added, we do not observe the error in test TestEmergencyDumpAtOOM any more.

src/hotspot/share/jfr/jfr.cpp line 159:

> 157: 
> 158: void Jfr::on_vm_error_report(outputStream* st) {
> 159:   assert(!JfrRecorder::is_recording(), "JFR should be stopped at erorr reporting");

'erorr' - please fix the little typo !

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

PR Comment: https://git.openjdk.org/jdk/pull/28563#issuecomment-3605855107
PR Review Comment: https://git.openjdk.org/jdk/pull/28563#discussion_r2584283966

From pminborg at openjdk.org  Wed Dec  3 10:34:41 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 3 Dec 2025 10:34:41 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v3]
In-Reply-To: <kOkb_9GWTlrv8dTymEXOvlbPw9fuoemDMn9dAZWNrOE=.0affa2da-5dd2-495d-a4ec-d348a00c7f92@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <eXO79ZBlZUltqddmReHLTSFSr3x8PiH0a5s740GHrfk=.5cf01f8f-7ac5-4def-b17d-dfd6f10e9614@github.com>
 <hzq42574wKnkKeZcBGJ-aOSY5hVrpoUKM8t25GMibxg=.b7728079-a9f7-4b35-8150-a94110d8e698@github.com>
 <kOkb_9GWTlrv8dTymEXOvlbPw9fuoemDMn9dAZWNrOE=.0affa2da-5dd2-495d-a4ec-d348a00c7f92@github.com>
Message-ID: <4gKSL8hFAE2qSuTmhJa6JMfoB6JfUnK9fzwHAnH2Zzg=.9fc69461-bbe7-4242-b3b1-b4b004f35ce0@github.com>

On Tue, 2 Dec 2025 17:24:41 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2036:
>> 
>>> 2034:             var constant = MethodHandleImpl.isCompileConstant(vh);
>>> 2035:             var cache = adaptedMh;
>>> 2036:             if (constant == MethodHandleImpl.CONSTANT_YES && cache != null) {
>> 
>> Rookie question: Is there multi-thread considerations here? How about visibility across threads?
>
> MethodHandle is immutable and can be safely published. So this is ok.

I meant that even though objects are immutable, plain semantics might not always do. 

Reference: https://shipilev.net/blog/2014/safe-public-construction/

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2584535309

From duke at openjdk.org  Wed Dec  3 11:27:54 2025
From: duke at openjdk.org (Vishal Chand)
Date: Wed, 3 Dec 2025 11:27:54 GMT
Subject: RFR: 8372652: Re-enable LocalRandom clinit after monitor pinning
 improvements
In-Reply-To: <NKJ_sFkC5imJ92NeWmi47PWtmC3JHpQAyRqmiJtfQO4=.61690dab-0237-467a-b65c-9e57c9167b13@github.com>
References: <IgEuelEzPt9Atv8KQR1Sa80QaKGllGNR-nWRF-sdm3Y=.72ccb838-8723-4fb8-9547-ed20e51b00f1@github.com>
 <IBk5-edc3PLSPqI5HZ4pDOthGiFBlj2MDMKs_A0kLEk=.3b7097c9-afe9-4441-a0b1-bdd20eb1468f@github.com>
 <YiOD-Uhl8zzAYb-uLYLs9itATGW4GQjH7iPKMRtdARE=.3cebae80-b55e-4a60-b92e-593e579d4931@github.com>
 <0BI-aekYlNzNe8szo_NjO14MRbrV_NjjQN6IYB_AT40=.5c548a70-d6fa-4eb9-b7cc-3c44f84ea833@github.com>
 <NKJ_sFkC5imJ92NeWmi47PWtmC3JHpQAyRqmiJtfQO4=.61690dab-0237-467a-b65c-9e57c9167b13@github.com>
Message-ID: <84ySmxXNDoSdUqvUJpevcTAtmzb9RIoqqWmkB7tx10c=.f01b7b99-acbb-4a34-a065-6c1250cdd522@github.com>

On Tue, 2 Dec 2025 12:48:54 GMT, Alan Bateman <alanb at openjdk.org> 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 There are failures with `make test TEST=vmTestbase/ JTREG=TEST_THREAD_FACTORY=Virtual` even without the change. 
> 
> Does running with JTREG_EXTRA_PROBLEM_LISTS=ProblemList-Virtual.txt improve this?

@AlanBateman No, it doesn't help.

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

PR Comment: https://git.openjdk.org/jdk/pull/28547#issuecomment-3606398679

From alanb at openjdk.org  Wed Dec  3 11:45:22 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 3 Dec 2025 11:45:22 GMT
Subject: RFR: 8372652: Re-enable LocalRandom clinit after monitor pinning
 improvements
In-Reply-To: <NKJ_sFkC5imJ92NeWmi47PWtmC3JHpQAyRqmiJtfQO4=.61690dab-0237-467a-b65c-9e57c9167b13@github.com>
References: <IgEuelEzPt9Atv8KQR1Sa80QaKGllGNR-nWRF-sdm3Y=.72ccb838-8723-4fb8-9547-ed20e51b00f1@github.com>
 <IBk5-edc3PLSPqI5HZ4pDOthGiFBlj2MDMKs_A0kLEk=.3b7097c9-afe9-4441-a0b1-bdd20eb1468f@github.com>
 <YiOD-Uhl8zzAYb-uLYLs9itATGW4GQjH7iPKMRtdARE=.3cebae80-b55e-4a60-b92e-593e579d4931@github.com>
 <0BI-aekYlNzNe8szo_NjO14MRbrV_NjjQN6IYB_AT40=.5c548a70-d6fa-4eb9-b7cc-3c44f84ea833@github.com>
 <NKJ_sFkC5imJ92NeWmi47PWtmC3JHpQAyRqmiJtfQO4=.61690dab-0237-467a-b65c-9e57c9167b13@github.com>
Message-ID: <Qe1Bynlcysxp-nHUftok5-2WfhY0yCFUEJbMsPZs-6o=.5d9927f3-c33e-4d4c-9533-eb58424993e7@github.com>

On Tue, 2 Dec 2025 12:48:54 GMT, Alan Bateman <alanb at openjdk.org> 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 There are failures with `make test TEST=vmTestbase/ JTREG=TEST_THREAD_FACTORY=Virtual` even without the change. 
> 
> Does running with JTREG_EXTRA_PROBLEM_LISTS=ProblemList-Virtual.txt improve this?

> @AlanBateman No, it doesn't help.

I don't have any other suggestions except that this change will likely require a lot of test runs to ensure that it doesn't bring back an issue. My guess (and Leonid might remember more) is that we using a j.u.concurrent lock in the java.io classes was problematic. We reverted this code back to using monitors after JEP 491 was integrated, and as Patricio mentions, a timeout is used to attempt to barge when pinned and this avoids the deadlocks that we might have seen at the time.

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

PR Comment: https://git.openjdk.org/jdk/pull/28547#issuecomment-3606459891

From thartmann at openjdk.org  Wed Dec  3 11:46:23 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 3 Dec 2025 11:46:23 GMT
Subject: RFR: 8371046: Segfault in
 compiler/whitebox/StressNMethodRelocation.java with -XX:+UseZGC [v2]
In-Reply-To: <hQo3CkLhsZLq7-L4_5ui7eXaoycrENU5zyFS4JwzvVE=.a78ad8ce-8435-4009-a6c0-28fde884ac63@github.com>
References: <k0-Cr7yor3F4OKDiZdT3lIrFiSgI_YRCR8_FphgQmlk=.4f60b60e-127d-413e-ab8f-26d6c4911142@github.com>
 <hQo3CkLhsZLq7-L4_5ui7eXaoycrENU5zyFS4JwzvVE=.a78ad8ce-8435-4009-a6c0-28fde884ac63@github.com>
Message-ID: <eVjSDLmqVTLXt9yFIQdUD4_qbR_vZFQYHvkVT-GZBF0=.65ab40a5-8de1-46c2-90ec-5ac099f02a35@github.com>

On Tue, 2 Dec 2025 22:06:18 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

>> [JDK-8371046](https://bugs.openjdk.org/browse/JDK-8371046)
>> 
>> This pull request fixes two crashes (see below) and adds `InvalidationReason::RELOCATED` to better describe why an nmethod is marked not entrant during relocation.
>> 
>> ---
>> 
>> #### 1. Test Bug
>> 
>> It?s possible for an `nmethod` to be unloaded without its `_state` being explicitly set to `not_entrant`. Checking only `is_in_use()` isn?t sufficient, since the `nmethod` may already be in the process of unloading and therefore may not have a lock (as with ZGC, where `nmethods` are locked individually).
>> 
>> The fix adds an additional `is_unloading()` check in WhiteBox before acquiring the lock.
>> 
>> This issue was reproducible fairly consistently (every few runs) by executing `compiler/whitebox/StressNMethodRelocation.java` with  `-XX:+UseZGC -XX:ReservedCodeCacheSize=32m`
>> 
>> 
>> After applying this patch, the original crash stopped occurring, though a more infrequent crash was still observed.
>> 
>> ---
>> 
>> #### 2. Implementation Bug
>> 
>> `nmethod::relocate` works by copying the instructions of an `nmethod` and then adjusting the call sites to account for new PC-relative offsets.
>> 
>> Previously, this fix-up happened *after* calling `post_init()`, which registers the `nmethod` and makes it visible to the GC. This introduced a race condition where the GC might attempt to resolve a call site before it had been fixed.
>> 
>> The fix ensures that all call sites are patched **before** the `nmethod` is registered.
>> 
>> In testing, the crash previously occurred roughly 60 times in 5,000 runs (~1.2%). With this patch, no crashes were observed in the same number of runs.
>
> Chad Rakoczy 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 'origin/master' into JDK-8371046
>  - Add comment
>  - Add guarantee
>  - Clear inline caches before calling post_init
>  - Fix relocations before registering nmethod
>  - Add is_unloading() check before aquiring ic lock

FTR: Testing on our side all passed.

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

PR Comment: https://git.openjdk.org/jdk/pull/28241#issuecomment-3606464293

From thartmann at openjdk.org  Wed Dec  3 11:54:02 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 3 Dec 2025 11:54:02 GMT
Subject: RFR: 8372701: Randomized profile counters [v2]
In-Reply-To: <YAdyTG2jqY3OcJ7M4mD0CkL56a0p6ciaHYM-ow9Ham8=.0cb57295-acde-4e49-984b-b8756ed99850@github.com>
References: <jKjmIONZcytzVjS4absOwOLv_QOF9qhIJifYhN6JyP4=.dceced94-bc29-43e6-9062-8dc77c2a6133@github.com>
 <YAdyTG2jqY3OcJ7M4mD0CkL56a0p6ciaHYM-ow9Ham8=.0cb57295-acde-4e49-984b-b8756ed99850@github.com>
Message-ID: <vP3GzUDISRkvmmGenTIPJqBcJ2Img3k4pU2eEqe-2OA=.22385445-a442-46c2-b996-4bb737fe5df0@github.com>

On Thu, 27 Nov 2025 17:18:35 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> 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 with a new target base due to a merge or a rebase. The pull request now contains 52 commits:
> 
>  - Merge remote-tracking branch 'refs/remotes/origin/JDK-8134940' into JDK-8134940
>  - whitespace
>  - AArch64
>  - Minimize deltas to master
>  - Better
>  - Inter
>  - Cleanup
>  - Cleanup
>  - Merge master
>  - D'oh
>  - ... and 42 more: https://git.openjdk.org/jdk/compare/b2f97131...49d52d82

I can run our internal performance testing with this but it currently fails to build on AArch64:

[2025-12-03T11:49:29,644Z] * For target hotspot_variant-server_libjvm_objs_c1_LIRAssembler_aarch64.o:
[2025-12-03T11:49:29,644Z] /System/Volumes/Data/mesos/work_dir/slaves/da1065b5-7b94-4f0d-85e9-a3a252b9a32e-S5842/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/a3ab2e9e-0898-4ceb-94ab-4f606db9de4d/runs/44169997-4fbe-4f98-98b9-d11781843c5e/workspace/open/src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp:2739:18: error: lambda capture 'op' is not used [-Werror,-Wunused-lambda-capture]
[2025-12-03T11:49:29,644Z]   auto lambda = [op, stub] (LIR_Assembler* ce, LIR_Op* base_op) {
[2025-12-03T11:49:29,644Z]                  ^~~
[2025-12-03T11:49:29,644Z] 1 error generated.
[2025-12-03T11:49:29,644Z] * For target hotspot_variant-server_libjvm_objs_static_c1_LIRAssembler_aarch64.o:
[2025-12-03T11:49:29,644Z] /System/Volumes/Data/mesos/work_dir/slaves/da1065b5-7b94-4f0d-85e9-a3a252b9a32e-S5842/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/a3ab2e9e-0898-4ceb-94ab-4f606db9de4d/runs/44169997-4fbe-4f98-98b9-d11781843c5e/workspace/open/src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp:2739:18: error: lambda capture 'op' is not used [-Werror,-Wunused-lambda-capture]
[2025-12-03T11:49:29,644Z]   auto lambda = [op, stub] (LIR_Assembler* ce, LIR_Op* base_op) {
[2025-12-03T11:49:29,644Z]                  ^~~
[2025-12-03T11:49:29,644Z] 1 error generated.

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

PR Comment: https://git.openjdk.org/jdk/pull/28541#issuecomment-3606493180

From coleenp at openjdk.org  Wed Dec  3 13:17:45 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 3 Dec 2025 13:17:45 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v8]
In-Reply-To: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
Message-ID: <HOlXGoe8-oMYP_mCYb_xxO9F13ji624MlCfQ3-_zebM=.6240c45e-bf23-4799-b9c2-175460afa2d5@github.com>

> ArrayKlass doesn't set AccessFlags so don't look for them there.  See CR for details.
> Fixed SA and jvmci.  @iwanowww Can you check that I changed C2 correctly (we talked about this in August).
> Tested with tier1-4.  5-7 in progress.

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

  Take out ?: for array classes in set_raw_access_flags call.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28371/files
  - new: https://git.openjdk.org/jdk/pull/28371/files/c7247c00..d311ded9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28371&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28371&range=06-07

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

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

From coleenp at openjdk.org  Wed Dec  3 13:17:46 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 3 Dec 2025 13:17:46 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v7]
In-Reply-To: <lyWK2X4EtG3Rq45neyn16-wytK0CVi82blyrj2JGsd4=.28c7a6b0-bcac-4259-a58e-7f721a545a26@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
 <lyWK2X4EtG3Rq45neyn16-wytK0CVi82blyrj2JGsd4=.28c7a6b0-bcac-4259-a58e-7f721a545a26@github.com>
Message-ID: <ZTn7i92Naw3uYroLePr4QyMjBx5iV5hczjEw4ZF-VGM=.66162f0d-5770-4859-8602-05d3adf262e6@github.com>

On Tue, 2 Dec 2025 13:24:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> ArrayKlass doesn't set AccessFlags so don't look for them there.  See CR for details.
>> Fixed SA and jvmci.  @iwanowww Can you check that I changed C2 correctly (we talked about this in August).
>> Tested with tier1-4.  5-7 in progress.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed indentation.

Thanks for reviewing Vladimir, Dean and Serguei, and review in progress Chen. I'm not planning to integrate this until JDK 27.

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

PR Comment: https://git.openjdk.org/jdk/pull/28371#issuecomment-3606802218

From coleenp at openjdk.org  Wed Dec  3 13:17:48 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 3 Dec 2025 13:17:48 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v5]
In-Reply-To: <jWgxAVYx6nsm4W7dxhRb7zwV-a5oKYyjRUUnvWbU99A=.887e5b6e-4123-4cf7-b5b3-917ccbfe5d91@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
 <r4etVDZnERk-bUlx-6uMtxP03xvMa0a51MnBlA7eIz0=.4e16178f-517a-400e-a7bf-0a890664aa2c@github.com>
 <jWgxAVYx6nsm4W7dxhRb7zwV-a5oKYyjRUUnvWbU99A=.887e5b6e-4123-4cf7-b5b3-917ccbfe5d91@github.com>
Message-ID: <H6yqUYEyVUcIQYPwSrZltiNvYD1mc4m8YfVhTE-hWR8=.c0588fe4-7d2f-4157-b1b7-9e77f4381fa8@github.com>

On Mon, 1 Dec 2025 20:43:25 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added a comment for checking interface guard after array guard.
>
> src/hotspot/share/classfile/javaClasses.cpp line 1096:
> 
>> 1094:   // Set the raw access_flags, this is used by reflection instead of modifier flags.
>> 1095:   // The Java code for array classes gets the access flags from the element type.
>> 1096:   set_raw_access_flags(mirror(), k->is_array_klass() ? 0 : InstanceKlass::cast(k)->access_flags().as_unsigned_short());
> 
> Should we merge this is_array_klass() query with the main if-else block below? We can probably skip setting raw access flags for array classes.

Yes, that would be an improvement.  I'll still set them to zero (even though it can be elided), so that I can keep the comment for array types though.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28371#discussion_r2585064578

From jvernee at openjdk.org  Wed Dec  3 13:26:28 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 3 Dec 2025 13:26:28 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v3]
In-Reply-To: <JwKK9FX_wiYEYaRppgToqEqutrnpodk7cNJCwYLf8i0=.69cbfa2b-2c03-45ab-ad84-b9f086621bd3@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <eXO79ZBlZUltqddmReHLTSFSr3x8PiH0a5s740GHrfk=.5cf01f8f-7ac5-4def-b17d-dfd6f10e9614@github.com>
 <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com>
 <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com>
 <M5yxETmdJBlueGf6KC7P8oSAZIEeiSu8rOHAoIxu0sc=.4bc347cb-40d5-4432-bc94-38a59730183d@github.com>
 <3OE37qXGHhLAhnRQM188hhygrLYBtI3FLBMK0tGVH30=.5d1b4406-3bb3-4788-8059-e78260b79ec1@github.com>
 <kZDurlwNJsrYZRbeHLXVTKqUQcW2QGFGLE-WNN-vz4o=.44bc4d21-cc9d-4d94-b40c-4b6ad9ab11aa@github.com>
 <7WF8DlorrU_B2__G2wr43w1PZwJh8mEhD5dY10YDIOo=.ec416c38-1aff-4dd6-8792-d6a0e01f91ce@github.com>
 <E7Lwc7nwEvsmQhLMYT5Ruj5j7BhVDcfyBRUfhinUyzQ=.3293c6f1-6ce4-47d8-aa48-ba9c69ba60eb@github.com>
 <ogD0Gl3QSb1pLJUqOn877wI6asY5TW0MV7mPFlNXM5A=.8af15b77-010a-4d34-901b-928c4a3fe425@github.com>
 <_Z6KpxCYH2n3sHuT6-kRP4cSTAN3-s5UA0r
 bfrJSIgA=.e9d4089c-8329-406b-9a0a-167a24311c13@github.com>
 <cWF4r8rgGleVvKUgrzYDQ0bcj_7QhY1PulNMpZtwBcs=.abcdfd8f-9a3f-4d1f-a55f-f16ea320cf92@github.com>
 <5CADH75ZjadKttOKwsykRFUPlQKLiwCW8E5WkM_75a4=.fd992c8f-e8bc-4775-9ea3-d5212664e3df@github.com>
 <JwKK9FX_wiYEYaRppgToqEqutrnpodk7cNJCwYLf8i0=.69cbfa2b-2c03-45ab-ad84-b9f086621bd3@github.com>
Message-ID: <5QPAetQEkrBgFKtMt0i9Ku_4s2GCirMl2uqLH3j8x7g=.e5fc8964-0080-45f7-9005-31922ec06ba1@github.com>

On Wed, 3 Dec 2025 04:10:05 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Sorry, I still don't understand how it is intended to work. Why does `MethodHandleImpl.isCompileConstant(vh) == true` imply that the cached value is compatible with the constant `vh`?
>> 
>> 
>> // Keep capturing - vh may suddenly get promoted to a constant by C2
>> 
>> 
>> Capturing happens outside compiler thread. It is not affected by C2 (except when it completely prunes the whole block).
>> 
>> So, either any captured adaptation is valid/compatible or there's a concurrency issue when C2 kicks in and there's a concurrent cache update happening with incompatible version.
>
>> any captured adaptation is valid/compatible
> 
> Yes, if `vh` is a constant, any captured adaptation from `vh.getMethodHandle(mode).asType(symbolicMethodTypeInvoker)` is valid/compatible.
> 
> For thread safety, MethodHandle supports safe publication, so I think we are fine publishing this way.

Looking at this, I'm not sure we can assume that we only see one mode and type when the VH is constant. There seems to be a lot of non-local reasoning involved.

For example, you could have a var handle invoker created with `MethodHandless::varHandleInvoker`, which is cached, so the `AccessDescriptor` can be shared among many different use sites. For an individual use-site, the receiver VH may well be a constant, but that doesn't mean that the cache isn't polluted by the var handle from another use site, as far as I can tell.

The thread safety issue comes from a C2 thread racing to read the `lastAdaption` cache vs another Java thread writing to the cache. AFAICS, this race is still possible even when `vh` is a compile time constant.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2585100537

From jvernee at openjdk.org  Wed Dec  3 13:37:54 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 3 Dec 2025 13:37:54 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v3]
In-Reply-To: <5QPAetQEkrBgFKtMt0i9Ku_4s2GCirMl2uqLH3j8x7g=.e5fc8964-0080-45f7-9005-31922ec06ba1@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <eXO79ZBlZUltqddmReHLTSFSr3x8PiH0a5s740GHrfk=.5cf01f8f-7ac5-4def-b17d-dfd6f10e9614@github.com>
 <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com>
 <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com>
 <M5yxETmdJBlueGf6KC7P8oSAZIEeiSu8rOHAoIxu0sc=.4bc347cb-40d5-4432-bc94-38a59730183d@github.com>
 <3OE37qXGHhLAhnRQM188hhygrLYBtI3FLBMK0tGVH30=.5d1b4406-3bb3-4788-8059-e78260b79ec1@github.com>
 <kZDurlwNJsrYZRbeHLXVTKqUQcW2QGFGLE-WNN-vz4o=.44bc4d21-cc9d-4d94-b40c-4b6ad9ab11aa@github.com>
 <7WF8DlorrU_B2__G2wr43w1PZwJh8mEhD5dY10YDIOo=.ec416c38-1aff-4dd6-8792-d6a0e01f91ce@github.com>
 <E7Lwc7nwEvsmQhLMYT5Ruj5j7BhVDcfyBRUfhinUyzQ=.3293c6f1-6ce4-47d8-aa48-ba9c69ba60eb@github.com>
 <ogD0Gl3QSb1pLJUqOn877wI6asY5TW0MV7mPFlNXM5A=.8af15b77-010a-4d34-901b-928c4a3fe425@github.com>
 <_Z6KpxCYH2n3sHuT6-kRP4cSTAN3-s5UA0r
 bfrJSIgA=.e9d4089c-8329-406b-9a0a-167a24311c13@github.com>
 <cWF4r8rgGleVvKUgrzYDQ0bcj_7QhY1PulNMpZtwBcs=.abcdfd8f-9a3f-4d1f-a55f-f16ea320cf92@github.com>
 <5CADH75ZjadKttOKwsykRFUPlQKLiwCW8E5WkM_75a4=.fd992c8f-e8bc-4775-9ea3-d5212664e3df@github.com>
 <JwKK9FX_wiYEYaRppgToqEqutrnpodk7cNJCwYLf8i0=.69cbfa2b-2c03-45ab-ad84-b9f086621bd3@github.com>
 <5QPAetQEkrBgFKtMt0i9Ku_4s2GCirMl2uqLH3j8x7g=.e5fc8964-0080-45f7-9005-31922ec06ba1@github.com>
Message-ID: <fYi_M2-uq5LpwcEac1xjqYUwlhUSlAjCm5zPhJrvLhA=.f89046cc-e769-4c9a-8bf7-464830f46890@github.com>

On Wed, 3 Dec 2025 13:23:18 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>>> any captured adaptation is valid/compatible
>> 
>> Yes, if `vh` is a constant, any captured adaptation from `vh.getMethodHandle(mode).asType(symbolicMethodTypeInvoker)` is valid/compatible.
>> 
>> For thread safety, MethodHandle supports safe publication, so I think we are fine publishing this way.
>
> Looking at this, I'm not sure we can assume that we only see one mode and type when the VH is constant. There seems to be a lot of non-local reasoning involved.
> 
> For example, you could have a var handle invoker created with `MethodHandless::varHandleInvoker`, which is cached, so the `AccessDescriptor` can be shared among many different use sites. For an individual use-site, the receiver VH may well be a constant, but that doesn't mean that the cache isn't polluted by the var handle from another use site, as far as I can tell.
> 
> The thread safety issue comes from a C2 thread racing to read the `lastAdaption` cache vs another Java thread writing to the cache. AFAICS, this race is still possible even when `vh` is a compile time constant.

I think even without using an invoker, you could end up in a similar situation if you have something like:


static Object m(VarHandle vh) {
    return vh.get();
}


Which is called by several different threads. At some point this method may be inlined into one of its callees, where `vh` then becomes a constant. But at the same time, other threads are still writing to the cache.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2585142665

From tschatzl at openjdk.org  Wed Dec  3 13:39:44 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 3 Dec 2025 13:39:44 GMT
Subject: RFR: 8372179: Remove Unused ConcurrentHashTable::MultiGetHandle
In-Reply-To: <3oYw-dGliUDEzEiC_Xrm4f5zjJTmxxYwZyPxDp8i0QU=.aaf67c3d-fe98-4fb0-b148-f2877791ed40@github.com>
References: <q-Y1GRBQYb90aqz6gCUsmyO_g3jwKsq5M2qIv2mOmz0=.152c826e-0089-4230-8fa2-54f7bd322a52@github.com>
 <3oYw-dGliUDEzEiC_Xrm4f5zjJTmxxYwZyPxDp8i0QU=.aaf67c3d-fe98-4fb0-b148-f2877791ed40@github.com>
Message-ID: <2MJWsNES8rUusWPja_d4AR4xE1yubXpTw3Uwc2806x8=.9b3f4773-b3ca-4835-90f4-98e908257155@github.com>

On Wed, 3 Dec 2025 09:21:52 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review the removal of `ConcurrentHashTable::MultiGetHandle` which is never used anywhere but in gtests.
>> 
>> Testing: gha
>> 
>> Thanks,
>>   Thomas
>
> Marked as reviewed by iwalulya (Reviewer).

Thanks @walulyai @dholmes-ora for your reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/28396#issuecomment-3606890424

From tschatzl at openjdk.org  Wed Dec  3 13:39:45 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 3 Dec 2025 13:39:45 GMT
Subject: Integrated: 8372179: Remove Unused ConcurrentHashTable::MultiGetHandle
In-Reply-To: <q-Y1GRBQYb90aqz6gCUsmyO_g3jwKsq5M2qIv2mOmz0=.152c826e-0089-4230-8fa2-54f7bd322a52@github.com>
References: <q-Y1GRBQYb90aqz6gCUsmyO_g3jwKsq5M2qIv2mOmz0=.152c826e-0089-4230-8fa2-54f7bd322a52@github.com>
Message-ID: <2N_mU29qZCP_BWOjh4K5-AGd1L6961F2nz3mQURayWU=.b49047a9-b64c-4052-a24d-c9926e287e4f@github.com>

On Wed, 19 Nov 2025 15:58:07 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review the removal of `ConcurrentHashTable::MultiGetHandle` which is never used anywhere but in gtests.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 135661b4
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/135661b4389663b8c2e348d9e61e72cc628636bb
Stats:     37 lines in 3 files changed: 0 ins; 34 del; 3 mod

8372179: Remove Unused ConcurrentHashTable::MultiGetHandle

Reviewed-by: dholmes, iwalulya

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

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

From cnorrbin at openjdk.org  Wed Dec  3 13:55:06 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Wed, 3 Dec 2025 13:55:06 GMT
Subject: RFR: 8367319: Add os interfaces to get machine and container
 values separately [v5]
In-Reply-To: <gxXrAX2NGPyZnHuA4ttkfJ8MagiiELK-Wk700A2ZBgw=.00aaf9ab-976d-476a-ba4d-8a4063d96130@github.com>
References: <gxXrAX2NGPyZnHuA4ttkfJ8MagiiELK-Wk700A2ZBgw=.00aaf9ab-976d-476a-ba4d-8a4063d96130@github.com>
Message-ID: <lI_E9fdbu_ilitVsUyZBFZZ3M1D-Y4lC1UaLvpP1drU=.d28d0b3f-8112-4d76-8f14-edce2923f7bb@github.com>

> 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 eight commits:

 - 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
 - Fixed print type
 - separate-machine-container-functions

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

Changes: https://git.openjdk.org/jdk/pull/27646/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27646&range=04
  Stats: 384 lines in 20 files changed: 241 ins; 54 del; 89 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 aartemov at openjdk.org  Wed Dec  3 14:04:28 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Wed, 3 Dec 2025 14:04:28 GMT
Subject: RFR: 8366671: Refactor Thread::SpinAcquire and Thread::SpinRelease
 [v12]
In-Reply-To: <NtY8E8fBeSokCAQYP3OQEwfnppSugtTJ8uAtQtD0zvg=.88f2988d-47fd-4b8a-af89-488ed6b37870@github.com>
References: <NtY8E8fBeSokCAQYP3OQEwfnppSugtTJ8uAtQtD0zvg=.88f2988d-47fd-4b8a-af89-488ed6b37870@github.com>
Message-ID: <BLbZykwmGPMfOyN0A7lrjaht-OWDbWK9_ArQRZZTVCU=.4bbd7292-3028-44f2-b0a5-cb4f29c2044b@github.com>

> Hi, 
> 
> please consider the following changes:
> 
> In this PR `Thread::SpinAcquire()` and `Thread::SpinRelease()` methods are refactored into a utility class `SpinCriticalSection`. The motivation is to make it easier for developers to use this lightweight synchronization mechanism in the codebase. The two aforementioned methods were used in JFR to create short critical sections with a helper class, but that was not the case for the object monitor code. 
> 
> Tested in tiers 1 - 5.

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

  8366671: Added NoSafepointVerifier

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28264/files
  - new: https://git.openjdk.org/jdk/pull/28264/files/a418211f..f987e128

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28264&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28264&range=10-11

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

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

From aartemov at openjdk.org  Wed Dec  3 14:04:29 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Wed, 3 Dec 2025 14:04:29 GMT
Subject: RFR: 8366671: Refactor Thread::SpinAcquire and Thread::SpinRelease
 [v9]
In-Reply-To: <qy9C3kZOZc7-RzO3SUUV8SMdWywQC92m3jSr-n_e15U=.2e8b1a41-7945-46e7-bcb5-807f62f0e3e0@github.com>
References: <NtY8E8fBeSokCAQYP3OQEwfnppSugtTJ8uAtQtD0zvg=.88f2988d-47fd-4b8a-af89-488ed6b37870@github.com>
 <3bBZzigernOcTkARE9am0ZmHR9NWsmp3xa0ksSLYiE8=.981d0f10-5b41-40c8-a35c-f953b0d1df08@github.com>
 <8aNv20VZljWCq6M_lZKe6dhlahN0nHoH91JDHEeIo8Y=.3d917870-0e49-4e40-95e2-df9dcaa3fe4d@github.com>
 <svlyDLeLPwYpnzHM6cP8UPc7pkMninSM-3xd2FUesQY=.027d3aa9-1e6d-433a-ac74-4e1d682c751f@github.com>
 <qy9C3kZOZc7-RzO3SUUV8SMdWywQC92m3jSr-n_e15U=.2e8b1a41-7945-46e7-bcb5-807f62f0e3e0@github.com>
Message-ID: <c-nPkaA8vrBGaTWWEBaEEP2D8ADrXY2kUjsTvO_6MgM=.ed5dc115-8a90-4176-a160-74eb8a3de516@github.com>

On Mon, 1 Dec 2025 13:17:48 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> I see. Yeah, do not think we have a construction that does exactly this right now. But we can easily extend the NSV to only call `Thread::current()` if it is not active. Something like:

Thanks, added.

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

PR Comment: https://git.openjdk.org/jdk/pull/28264#issuecomment-3607000721

From cnorrbin at openjdk.org  Wed Dec  3 14:08:11 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Wed, 3 Dec 2025 14:08:11 GMT
Subject: RFR: 8367319: Add os interfaces to get machine and container
 values separately [v2]
In-Reply-To: <vHaEQwa7Uy3TE5FMX5q56dYaAZR3J5Jfn_eOitct5Xg=.ab002eb6-5a08-4fd2-8ad0-fb7ea8fd04cf@github.com>
References: <gxXrAX2NGPyZnHuA4ttkfJ8MagiiELK-Wk700A2ZBgw=.00aaf9ab-976d-476a-ba4d-8a4063d96130@github.com>
 <YsSD07LmdasM7tN-4ULeMtGLTZzaWiWsxW-Zj6dtDe8=.5684f897-19b4-4293-8265-6929b6d3f5fd@github.com>
 <INNocSY8muwF1hpn9g3P2VqHG_eXh1FQr5FO_-kdrnQ=.6192f1a0-da56-47f2-8bb1-b446be1b5302@github.com>
 <afMVy5NIZSFVFy-tGfJI41K80VgbkU1UYtfrIoyjjlc=.9e9f3808-984d-459e-be5a-5f682be35a12@github.com>
 <PC-n6BbcphUei7Uy_zJMnHBwIISaRAZuJyfnHn56sf8=.e97195e9-e17e-4af3-bade-95a9b1e0f4f0@github.com>
 <vHaEQwa7Uy3TE5FMX5q56dYaAZR3J5Jfn_eOitct5Xg=.ab002eb6-5a08-4fd2-8ad0-fb7ea8fd04cf@github.com>
Message-ID: <qNMFRQqmGN9RL8F3FXOofKvdn21pPjY3b5gdxqa11Ro=.c99d1197-64ff-4e98-96c3-eb5dd93c6ab5@github.com>

On Mon, 27 Oct 2025 08:40:03 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>>> is that alternative container implementation really implementing a container, or a virtual machine?
>> 
>> You would have to define what you mean by "container" and "virtual machine".  Isolating CPU usage ala tasksets seems a natural partitioning approach for a "container" environment to me.
>
>> > is that alternative container implementation really implementing a container, or a virtual machine?
>> 
>> You would have to define what you mean by "container" and "virtual machine". Isolating CPU usage ala tasksets seems a natural partitioning approach for a "container" environment to me.
> 
> Not sure if me defining containers and virtual machines will take this discussion further. But for what it's worth, it is becoming popular to run a "MicroVM" instead of a container (cf. firecracker, new mac OS "containers" that are micro VMs). What it has in common with containers is that it is lightweight and starts fast. But it has dedicated hardware and you can't see the host hardware availability from it. So a perhaps more relevant question is:
> 1) How are these modelled today? AFAIK: they are not detected as containers.
> 2) How can we model these today? AFAIK: we can't get resource usage information from the host.
> 3) How do we want to model these today? IMO: not as containers. They quack more like virtual machines than containers and there is no obvious benefit of knowing about the world outside of the micro VM.
> 
> Regardless of these thoughts around micro VMs, I don't know if we will get far with trying to predict whether this API will fit well for a future hypothetical container system that works differently, or not. I'd vote for crossing that bridge when we get there instead, if we eventually find out then, that it could do with being updated. Does that sound good?

After some offline discussion with @fisk , I've pushed a couple minor changes:
- First, when there is no memory limit, internal functions currently set the limit to a predefined `value_unlimited`. However, for callers of the public API, returning this value is less helpful, they only need to know whether a limit exists. So now, if the memory limit is unlimited, we simply return `false` to indicate there is no enforced limit.
- Second, I've removed the asserts for `is_containerized()`. There's nothing actually preventing someone from checking cgroup values directly, so we shouldn't block this with an assert. Also, since being "containerized" is partly defined as having a resource limit set, it seems redundant to require checking for a limit before accessing its value.

 
@dholmes-ora, could you please take another look at these changes? I hope I've addressed some of the earlier pain points and that we can move closer to getting this finalized.

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

PR Comment: https://git.openjdk.org/jdk/pull/27646#issuecomment-3607030533

From liach at openjdk.org  Wed Dec  3 14:11:22 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 3 Dec 2025 14:11:22 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v3]
In-Reply-To: <4gKSL8hFAE2qSuTmhJa6JMfoB6JfUnK9fzwHAnH2Zzg=.9fc69461-bbe7-4242-b3b1-b4b004f35ce0@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <eXO79ZBlZUltqddmReHLTSFSr3x8PiH0a5s740GHrfk=.5cf01f8f-7ac5-4def-b17d-dfd6f10e9614@github.com>
 <hzq42574wKnkKeZcBGJ-aOSY5hVrpoUKM8t25GMibxg=.b7728079-a9f7-4b35-8150-a94110d8e698@github.com>
 <kOkb_9GWTlrv8dTymEXOvlbPw9fuoemDMn9dAZWNrOE=.0affa2da-5dd2-495d-a4ec-d348a00c7f92@github.com>
 <4gKSL8hFAE2qSuTmhJa6JMfoB6JfUnK9fzwHAnH2Zzg=.9fc69461-bbe7-4242-b3b1-b4b004f35ce0@github.com>
Message-ID: <dueAilXXeNgz_LcD8YuczPzfr6W9ljTUTfpGCcN8auM=.ac500515-0824-43f4-9ffe-e3ada53fe02f@github.com>

On Wed, 3 Dec 2025 10:31:07 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> MethodHandle is immutable and can be safely published. So this is ok.
>
> I meant that even though objects are immutable, plain semantics might not always do. 
> 
> Reference: https://shipilev.net/blog/2014/safe-public-construction/

MethodHandle is safe. All fields in Method Handle hierarchies are either lazy/stable or final. You can refer to the `invokers` field in `MethodType`, and the `MethodHandle` array in `Invokers` for precedents.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2585263336

From liach at openjdk.org  Wed Dec  3 14:11:23 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 3 Dec 2025 14:11:23 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v3]
In-Reply-To: <dueAilXXeNgz_LcD8YuczPzfr6W9ljTUTfpGCcN8auM=.ac500515-0824-43f4-9ffe-e3ada53fe02f@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <eXO79ZBlZUltqddmReHLTSFSr3x8PiH0a5s740GHrfk=.5cf01f8f-7ac5-4def-b17d-dfd6f10e9614@github.com>
 <hzq42574wKnkKeZcBGJ-aOSY5hVrpoUKM8t25GMibxg=.b7728079-a9f7-4b35-8150-a94110d8e698@github.com>
 <kOkb_9GWTlrv8dTymEXOvlbPw9fuoemDMn9dAZWNrOE=.0affa2da-5dd2-495d-a4ec-d348a00c7f92@github.com>
 <4gKSL8hFAE2qSuTmhJa6JMfoB6JfUnK9fzwHAnH2Zzg=.9fc69461-bbe7-4242-b3b1-b4b004f35ce0@github.com>
 <dueAilXXeNgz_LcD8YuczPzfr6W9ljTUTfpGCcN8auM=.ac500515-0824-43f4-9ffe-e3ada53fe02f@github.com>
Message-ID: <4F_HqL-oY7z2ENI9yIAS7VS3NDjEljsqx4E2zK5HxJ0=.8f5ab39a-66e1-4ea3-ace2-226d6bd39d77@github.com>

On Wed, 3 Dec 2025 14:06:00 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I meant that even though objects are immutable, plain semantics might not always do. 
>> 
>> Reference: https://shipilev.net/blog/2014/safe-public-construction/
>
> MethodHandle is safe. All fields in Method Handle hierarchies are either lazy/stable or final. You can refer to the `invokers` field in `MethodType`, and the `MethodHandle` array in `Invokers` for precedents.

In extreme cases where a barrier is needed, java.lang.invoke already issue necessary barriers, most notably the storeStoreFence, such as https://github.com/openjdk/jdk/blob/135661b4389663b8c2e348d9e61e72cc628636bb/src/java.base/share/classes/java/lang/invoke/CallSite.java#L138
or https://github.com/openjdk/jdk/blob/135661b4389663b8c2e348d9e61e72cc628636bb/src/java.base/share/classes/java/lang/ClassValue.java#L411-L417

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2585270552

From eastigeevich at openjdk.org  Wed Dec  3 14:40:00 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Wed, 3 Dec 2025 14:40:00 GMT
Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact
 on GenZGC performance [v11]
In-Reply-To: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
Message-ID: <__PxBymm9q5Emt512PHuhX3k_3r7z5wGDgZKB0KkzvU=.0beedeea-6c5b-45d5-aee8-445018158581@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 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.
> 
> Benchmarking results: Neoverse-N1 r3p1 (Graviton 2)
> 
> - Baseline
> 
> $ taskset -c 0-3 java -Xbootclasspath/a:./wb.jar -XX:+UnlockDiagnosticVMOptions -XX:-NeoverseN1Errata1542419 -XX:+UseZGC -XX:ZYoungGCThreads=1 -XX:ZOldGC...

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

  Add support of deferred icache invalidation to other GCs and JIT

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28328/files
  - new: https://git.openjdk.org/jdk/pull/28328/files/dbeeecf1..79f9a2a0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28328&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28328&range=09-10

  Stats: 199 lines in 16 files changed: 151 ins; 20 del; 28 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 erikj at openjdk.org  Wed Dec  3 14:48:35 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 3 Dec 2025 14:48:35 GMT
Subject: RFR: 8351842: Windows specific issues in combination of JEP 493
 and --with-external-symbols-in-bundles=public [v7]
In-Reply-To: <GmCc0zKQhuTx4s7vzyjFA2gztgss7VxwcAFOUkw8ifw=.c4f69a8c-1407-45d7-a17f-59e1af2578f8@github.com>
References: <R-zg2t6gMm9oZgSijkRxJ0ErqtvoFeqPyfUGbhZRkEQ=.17b0ed93-ea7b-4a37-8471-12624c937a71@github.com>
 <GmCc0zKQhuTx4s7vzyjFA2gztgss7VxwcAFOUkw8ifw=.c4f69a8c-1407-45d7-a17f-59e1af2578f8@github.com>
Message-ID: <Rs6aZ6JwkPx7IFtraY8XfTbHqAWCKcSyL7SIn0MyzlE=.7c7b4634-4729-40e9-8256-f1974f7e956a@github.com>

On Wed, 3 Dec 2025 09:54:38 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> This PR addresses an issue that can be observed when building on Windows with configure options `--enable-linkable-runtime` and `--with-external-symbols-in-bundles=public`.
>> 
>> The problem is that with this special build configuration, we build two sets of .pdb files for the binaries. The first set is the standard debug symbols files named <binary-name>.pdb. The second set consists of stripped debug symbols file called <binary-name>.stripped.pdb which have less information but enough to present line numbers in hs-err files.
>> 
>> During build we use the *.stripped.pdb files for compiling the jmods and also the bundle files. However, in the images folder, both sets of .pdb files exist. The tests for runtime linking will now, in the absence of jmod files, pick up the .pdb files (without *stripped*) from images, but in the runtime the hashes of the *stripped* files are stored.
>> 
>> With this change, the standard .pdb files in the `--with-external-symbols-in-bundles=public` configuration are now the stripped files and we create a set of full pdb files named *.full.pdb. Jmods and Bundles still contain the stripped pdb files and we also fix the issue that the debug symbols bundle also contained stripped pdb files so far. With this fix, it will contain the full pdb files and extracting these over a JDK runtime will replace stripped pdbs with full pdbs.
>
> Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback

Build changes look good.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24012#pullrequestreview-3535417592

From eastigeevich at openjdk.org  Wed Dec  3 14:55:17 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Wed, 3 Dec 2025 14:55:17 GMT
Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact
 on GCs and JIT performance [v12]
In-Reply-To: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
Message-ID: <NK7PtqkIlCpB3krrmi2BWwKPjZ7UTnelPIjIPvbaJ2Y=.52d40961-6a53-4425-8015-e0e25585924d@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 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.
> 
> Benchmarking results: Neoverse-N1 r3p1 (Graviton 2)
> 
> - Baseline
> 
> $ taskset -c 0-3 java -Xbootclasspath/a:./wb.jar -XX:+UnlockDiagnosticVMOptions -XX:-NeoverseN1Errata1542419 -XX:+UseZGC -XX:ZYoungGCThreads=1 -XX:ZOldGC...

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

  Remove trailing whitespaces

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28328/files
  - new: https://git.openjdk.org/jdk/pull/28328/files/79f9a2a0..8c5ef0e8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28328&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28328&range=10-11

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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  Wed Dec  3 15:13:21 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Wed, 3 Dec 2025 15:13:21 GMT
Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact
 on GCs and JIT performance [v3]
In-Reply-To: <-cnMy4YHNCrKRqt_2Kkh9ksi-qE8ndZLB5yoyKkS3gM=.3f328f98-15a2-4736-9a6c-f9ab0705b830@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
 <HRolQfccrR5yCZGW3kM_0PXETSQIgghN8gDt14z3MII=.04b2e704-84a4-42bf-b808-2cdd2a8bd035@github.com>
 <lbD4zbjYiP0_4iNTwiepHxAlO441S-KxyOtAP9r8zws=.1b5a83a4-081b-4d66-9ad1-c57d94ee65ef@github.com>
 <-cnMy4YHNCrKRqt_2Kkh9ksi-qE8ndZLB5yoyKkS3gM=.3f328f98-15a2-4736-9a6c-f9ab0705b830@github.com>
Message-ID: <Ymvz568RFMGEXLsCy1cg74PExkUeJ4rtBldXIfUS50c=.f0395367-8912-44cf-a6ef-b3ebf1f69a67@github.com>

On Tue, 25 Nov 2025 13:04:55 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Yeah patching all nmethods as one unit is basically equivalent to making the code cache processing a STW operation. Last time we processed the code cache STW was JDK 11. A dark place I don't want to go back to. It can get pretty big and mess up latency. So I'm in favour of limiting the fix and not re-introduce STW code cache processing.
>> 
>> Otherwise yes you are correct; we perform synchronous cross modifying code with no assumptions about instruction cache coherency because we didn't trust it would actually work for all ARM implementations. Seems like that was a good bet. We rely on it on x64 still though.
>> 
>> It's a bit surprising to me if they invalidate all TLB entries, effectively ripping out the entire virtual address space, even when a range is passed in. If so, a horrible alternative might be to use mprotect to temporarily remove execution permission on the affected per nmethod pages, and detect over shooting in the signal handler, resuming execution when execution privileges are then restored immediately after. That should limit the affected VA to close to what is actually invalidated. But it would look horrible.
>
>> It's a bit surprising to me if they invalidate all TLB entries, effectively ripping out the entire virtual address space, even when a range is passed in. If so,
> 
> "Because the cache-maintenance wasn't needed, we can do the TLBI instead.
> In fact, the I-Cache line-size isn't relevant anymore, we can reduce
> the number of traps by producing a fake value.
> 
> "For user-space, the kernel's work is now to trap CTR_EL0 to hide DIC,
> and produce a fake IminLine. EL3 traps the now-necessary I-Cache
> maintenance and performs the inner-shareable-TLBI that makes everything
> better."
> 
> My interpretation of this is that we only need to do the synchronization dance once, at the end of the patching. But I guess we don't know exactly if we have an affected core or if the kernel workaround is in action.

@theRealAph @fisk @shipilev 
I have updated all places to use optimized icache invalidation. Could you please have a look?
I am running different tests and benchmarks.

@fisk @shipilev 
- I added `nmethod::has_non_immediate_oops`. I think it's easy to detect them when we generate code. If this is OK, we might need to update `ZNMethod::attach_gc_data` and `ShenandoahNMethod::detect_reloc_oops`.
- Code of `G1NMethodClosure::do_evacuation_and_fixup(nmethod* nm)` looks strange:

  _oc.set_nm(nm);

  // Evacuate objects pointed to by the nmethod
  nm->oops_do(&_oc);

  if (_strong) {
    // CodeCache unloading support
    nm->mark_as_maybe_on_stack();

    BarrierSetNMethod* bs_nm = BarrierSet::barrier_set()->barrier_set_nmethod();
    bs_nm->disarm(nm);
  }

  ICacheInvalidationContext icic(nm->has_non_immediate_oops());

  nm->fix_oop_relocations();


If `_strong` is true, we disarm `nm` and patch it with `fix_oop_relocations`. I have assertions checking we can defer icache invalidation. Neither of them are triggered. I thing this path always happens at a safepoint.

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

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

From sgehwolf at openjdk.org  Wed Dec  3 15:24:32 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 3 Dec 2025 15:24:32 GMT
Subject: RFR: 8367319: Add os interfaces to get machine and container
 values separately [v5]
In-Reply-To: <lI_E9fdbu_ilitVsUyZBFZZ3M1D-Y4lC1UaLvpP1drU=.d28d0b3f-8112-4d76-8f14-edce2923f7bb@github.com>
References: <gxXrAX2NGPyZnHuA4ttkfJ8MagiiELK-Wk700A2ZBgw=.00aaf9ab-976d-476a-ba4d-8a4063d96130@github.com>
 <lI_E9fdbu_ilitVsUyZBFZZ3M1D-Y4lC1UaLvpP1drU=.d28d0b3f-8112-4d76-8f14-edce2923f7bb@github.com>
Message-ID: <Q5LOAsRhyY58X2jHFSRDKqyAKWFzWfcITJwuuk50D2o=.b7e3b0ef-6700-4ced-90fc-48126bf1db9f@github.com>

On Wed, 3 Dec 2025 13:55:06 GMT, Casper Norrbin <cnorrbin at openjdk.org> 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 eight commits:
> 
>  - 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
>  - Fixed print type
>  - separate-machine-container-functions

src/hotspot/os/linux/os_linux.cpp line 222:

> 220:     return true;
> 221:   }
> 222:   return false;

Assume this usage:

physical_memory_size mem_limit = 0;
if (!os::Container::memory_limit(mem_limit)) {
  // assume mem_limit == 0;
}


The general contract for cases where a function returned `false` (i.e. error) is that the passed in reference remains untouched. This seems to violate that contract. `value` could change from whatever the initial value was to `value_unlimited` and return `false`.

src/hotspot/os/linux/os_linux.cpp line 226:

> 224: 
> 225: bool os::Container::memory_soft_limit(physical_memory_size_type& value) {
> 226:   if (OSContainer::memory_soft_limit_in_bytes(value) && value != 0) {

Why the `value != 0` check? Shouldn't this check for `value_unlimited` as is done for other `limit` functions? Same issue applies in the theoretical case where `0` is being read. The function returns `false`, but the initial `value` might have not been `0`.

src/hotspot/os/linux/os_linux.cpp line 236:

> 234:     return true;
> 235:   }
> 236:   return false;

Same here with the changed `value` when `value_unlimited` is being read, and function returning `false`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27646#discussion_r2585526251
PR Review Comment: https://git.openjdk.org/jdk/pull/27646#discussion_r2585539114
PR Review Comment: https://git.openjdk.org/jdk/pull/27646#discussion_r2585548526

From pchilanomate at openjdk.org  Wed Dec  3 15:27:06 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 3 Dec 2025 15:27:06 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v13]
In-Reply-To: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
Message-ID: <p6lFKQ-dibdBFgeRjm2oaHSE1MwKSJ1x4gUXJNQRBX4=.96d83b12-93af-44c8-a0d5-50cb7e8e7b8d@github.com>

> 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 terms of mount and un...

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

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

Changes: https://git.openjdk.org/jdk/pull/28361/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28361&range=12
  Stats: 1957 lines in 41 files changed: 914 ins; 823 del; 220 mod
  Patch: https://git.openjdk.org/jdk/pull/28361.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28361/head:pull/28361

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

From macarte at openjdk.org  Wed Dec  3 15:27:54 2025
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 3 Dec 2025 15:27:54 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v8]
In-Reply-To: <ftPvHBlncWJz1yN6Gjclx4Z-QcgHijYUp2tJ1wQfP8Q=.ebd2ac22-0e3a-4f2f-83aa-4c753b6e806d@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <Tr-Hep5GKs8WK18D22iF09MA78Yf-AqmDN7lnXj7Lzs=.35a44c9a-6bce-4c9a-aa7f-e14051a1d2ec@github.com>
 <ftPvHBlncWJz1yN6Gjclx4Z-QcgHijYUp2tJ1wQfP8Q=.ebd2ac22-0e3a-4f2f-83aa-4c753b6e806d@github.com>
Message-ID: <1xvBfNax6BA3eMN--W-IcfjlKVcMd_vJq9Gh9edqtmg=.a489f78b-6a8f-4ada-a6fc-87a667ad6a7d@github.com>

On Fri, 21 Nov 2025 11:50:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove single whitespace
>
> test/hotspot/jtreg/runtime/cds/appcds/aotCache/HotSpotAOTCacheMXBeanTest.java line 45:
> 
>> 43: import jdk.test.lib.process.OutputAnalyzer;
>> 44: 
>> 45: public class HotSpotAOTCacheMXBeanTest {
> 
> In addition to testing the endRecording operation, we also need to test both the direct and indirect access to the MXBean. The test currently obtains a proxy with newPlatformMXBeanProxy (good) but the direct access with ManagementFactory.getPlatformMXBean is not tested right now.
> 
> Another thing to test is that getObjectName returns the expected object name.

Agreed and I will add these additional tests in a subsequent PR

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2585561932

From eastigeevich at openjdk.org  Wed Dec  3 15:42:38 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Wed, 3 Dec 2025 15:42:38 GMT
Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact
 on GCs and JIT performance [v13]
In-Reply-To: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
Message-ID: <rtneArX_lMKv-UqOQNXv8DT_n8pY4UNn7nEE4FpKT4k=.ca641bc2-9d9a-4e0b-a329-da375913f5db@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 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.
> 
> Benchmarking results: Neoverse-N1 r3p1 (Graviton 2)
> 
> - Baseline
> 
> $ taskset -c 0-3 java -Xbootclasspath/a:./wb.jar -XX:+UnlockDiagnosticVMOptions -XX:-NeoverseN1Errata1542419 -XX:+UseZGC -XX:ZYoungGCThreads=1 -XX:ZOldGC...

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

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

Changes: https://git.openjdk.org/jdk/pull/28328/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28328&range=12
  Stats: 879 lines in 25 files changed: 839 ins; 7 del; 33 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 liach at openjdk.org  Wed Dec  3 15:54:30 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 3 Dec 2025 15:54:30 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v5]
In-Reply-To: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
Message-ID: <ceOdRSrfzY1OowDWPakngZ0JXtZJXDh2saVG29_rDwo=.2a396bce-0f78-493e-b53f-6a154005c272@github.com>

> 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:

  Fix problem identified by Jorn

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28585/files
  - new: https://git.openjdk.org/jdk/pull/28585/files/d49ad129..89e21b4b

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

  Stats: 40 lines in 3 files changed: 25 ins; 2 del; 13 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 shade at openjdk.org  Wed Dec  3 16:14:05 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 3 Dec 2025 16:14:05 GMT
Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact
 on GCs and JIT performance [v13]
In-Reply-To: <rtneArX_lMKv-UqOQNXv8DT_n8pY4UNn7nEE4FpKT4k=.ca641bc2-9d9a-4e0b-a329-da375913f5db@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
 <rtneArX_lMKv-UqOQNXv8DT_n8pY4UNn7nEE4FpKT4k=.ca641bc2-9d9a-4e0b-a329-da375913f5db@github.com>
Message-ID: <Kl5e4lLy09In3ii23YLueZVqzzzkBkZJLGAJb2k7Aio=.4347ba54-eb6b-4a9f-81e8-6db06a03824f@github.com>

On Wed, 3 Dec 2025 15:42:38 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> Arm Neoverse N1 erratum 1542419: "The core might fetch a stale instruction from memory which violates the ordering of instruction fetches". It is fixed in Neoverse N1 r4p1.
>>  
>> Neoverse-N1 implementations mitigate erratum 1542419 with a workaround:
>> - Disable coherent icache.
>> - Trap IC IVAU instructions.
>> - Execute:
>>    - `tlbi vae3is, xzr`
>>    - `dsb sy`
>>  
>>  `tlbi vae3is, xzr` invalidates translations for all address spaces (global for address).  It waits for all memory accesses using in-scope old translation information to complete before it is considered complete.
>>  
>> As this workaround has significant overhead, Arm Neoverse N1 (MP050) Software Developer Errata Notice version 29.0 suggests:
>> 
>> "Since one TLB inner-shareable invalidation is enough to avoid this erratum, the number of injected TLB invalidations should be minimized in the trap handler to mitigate the performance impact due to this workaround."
>> 
>> This PR introduces a mechanism to defer instruction cache (ICache) invalidation for AArch64 to address the Arm Neoverse N1 erratum 1542419, which causes significant performance overhead if ICache invalidation is performed too frequently. The implementation includes detection of affected Neoverse N1 CPUs and automatic enabling of the workaround for relevant Neoverse N1 revisions.
>> 
>> Changes include:
>> 
>> * Added a new diagnostic JVM flag `NeoverseN1Errata1542419` to enable or disable the workaround for the erratum. The flag is automatically enabled for Neoverse N1 CPUs prior to r4p1, as detected during VM initialization.
>> * Introduced the `ICacheInvalidationContext` class to manage deferred ICache invalidation, with platform-specific logic for AArch64. This context is used to batch ICache invalidations, reducing performance impact. As the address for icache invalidation is not relevant, we use the nmethod's code start address.
>> * Provided a default (no-op) implementation for `ICacheInvalidationContext` on platforms where the workaround is not needed, ensuring portability and minimal impact on other architectures.
>> * Modified barrier patching and relocation logic (`ZBarrierSetAssembler`, `ZNMethod`, `RelocIterator`, and related code) to accept a `defer_icache_invalidation` parameter, allowing ICache invalidation to be deferred and later performed in bulk.
>> 
>> Benchmarking results: Neoverse-N1 r3p1 (Graviton 2)
>> 
>> - Baseline
>> 
>> $ taskset -c 0-3 java -Xbootclasspath/a:./wb.jar -XX:+UnlockDiagnosticVMOptions -XX:-NeoverseN1...
>
> 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:

src/hotspot/cpu/aarch64/globals_aarch64.hpp line 133:

> 131:           "Enable workaround for Neoverse N1 erratum 1542419")          \
> 132:   product(bool, UseDeferredICacheInvalidation, false, DIAGNOSTIC,       \
> 133:           "Defer multiple ICache invalidation to single invalidation")  \

Since the `ICacheInvalidationContext` is in shared code, and I suppose x86_64 would also benefit from this (at least eventually), this sounds like `globals.hpp` option.

src/hotspot/share/asm/codeBuffer.cpp line 371:

> 369:       !((oop_Relocation*)reloc)->oop_is_immediate()) {
> 370:     _has_non_immediate_oops = true;
> 371:   }

Honestly, this looks fragile? We can go into nmethods patching for some other reason, not for patching oops.

Also, we still might need to go and patch immediate oops? I see this:


  // Instruct loadConP of x86_64.ad places oops in code that are not also
  // listed in the oop section.
  static bool mustIterateImmediateOopsInCode() { return true; }


Is there a substantial loss is doing icache invalidation without checking for the existence of interesting oops? Do you have an idea how many methods this filters?

src/hotspot/share/asm/codeBuffer.cpp line 939:

> 937:     // Move all the code and relocations to the new blob:
> 938:     relocate_code_to(&cb);
> 939:   }

Here and later, the preferred style is:

Suggestion:

  // Move all the code and relocations to the new blob:
  {
    ICacheInvalidationContext icic(ICacheInvalidation::NOT_NEEDED);
    relocate_code_to(&cb);
  }

src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp line 37:

> 35: #include "memory/universe.hpp"
> 36: #include "runtime/atomicAccess.hpp"
> 37: #include "runtime/icache.hpp"

Include is added, but no actual use? Is something missing, or this is a leftover include?

test/hotspot/jtreg/gc/TestDeferredICacheInvalidation.java line 28:

> 26: 
> 27: /*
> 28:  * @test id=ParallelGC

Usually just:

Suggestion:

 * @test id=parallel

test/hotspot/jtreg/gc/TestDeferredICacheInvalidation.java line 34:

> 32:  * @requires vm.debug
> 33:  * @requires os.family=="linux"
> 34:  * @requires os.arch=="aarch64"

I am guessing it is more future-proof to drop Linux/AArch64 filters, and rely on test doing the right thing, regardless of the config. I see it already skips when `UseDeferredICacheInvalidation` is off.

test/micro/org/openjdk/bench/vm/gc/GCPatchingNmethodCost.java line 184:

> 182:     @Benchmark
> 183:     @Warmup(iterations = 0)
> 184:     @Measurement(iterations = 1)

Not sure what is the intent here. Maybe you wanted `@BenchmarkMode(OneShot)` instead?

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

PR Review: https://git.openjdk.org/jdk/pull/28328#pullrequestreview-3535752098
PR Review Comment: https://git.openjdk.org/jdk/pull/28328#discussion_r2585729392
PR Review Comment: https://git.openjdk.org/jdk/pull/28328#discussion_r2585679778
PR Review Comment: https://git.openjdk.org/jdk/pull/28328#discussion_r2585704068
PR Review Comment: https://git.openjdk.org/jdk/pull/28328#discussion_r2585707389
PR Review Comment: https://git.openjdk.org/jdk/pull/28328#discussion_r2585735476
PR Review Comment: https://git.openjdk.org/jdk/pull/28328#discussion_r2585734553
PR Review Comment: https://git.openjdk.org/jdk/pull/28328#discussion_r2585743873

From jsikstro at openjdk.org  Wed Dec  3 16:17:48 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 3 Dec 2025 16:17:48 GMT
Subject: RFR: 8373023: [REDO] Remove the default value of InitialRAMPercentage
Message-ID: <GUN_73n4tGiqwmNTooT9WVxzRSqC2oSoi1s1ZVHteUk=.971f0216-7db6-4929-8310-61cb24ca3ea0@github.com>

Hello,

We backed out this change in https://github.com/openjdk/jdk/pull/28617 after issues in found in testing. Moving forward, we've decided to problem list a few tests that assumes that a GC does not run during their execution. When the initial heap size becomes very low with this change, it may trigger additional GCs, which may interfere with a few tests.

We are planning to follow up on the problem lists with test fixes in:
https://github.com/openjdk/jdk/pull/28638, https://github.com/openjdk/jdk/pull/28637

>From the original RFE: 

This RFE changes the default of `InitialRAMPercentage` to 0, effectively removing its default value. Please see the CSR for specific details on this change.

Changing the default value to 0 results in the behavior that the initial heap size (InitialHeapSize) is set to the minimum heap size (MinHeapSize). This is because of the following lines in `Arguments::set_heap_size()`, which takes the MAX value of MinHeapSize as well:

uint64_t initial_memory = (uint64_t)(((double)MaxRAM * InitialRAMPercentage) / 100);
...

reasonable_initial = MAX3(reasonable_initial, reasonable_minimum, MinHeapSize);
reasonable_initial = MIN2(reasonable_initial, MaxHeapSize);


This change improves startup performance for all GCs, but affects the time-to-peak performance in some out-of-the-box configurations for some GCs. This is mainly visible in ParallelGC.

Testing:
* Oracle's tier1-3

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

Commit messages:
 - 8373023: [REDO] Remove the default value of InitialRAMPercentage

Changes: https://git.openjdk.org/jdk/pull/28641/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28641&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373023
  Stats: 17 lines in 5 files changed: 13 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/28641.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28641/head:pull/28641

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

From stefank at openjdk.org  Wed Dec  3 16:17:48 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 3 Dec 2025 16:17:48 GMT
Subject: RFR: 8373023: [REDO] Remove the default value of
 InitialRAMPercentage
In-Reply-To: <GUN_73n4tGiqwmNTooT9WVxzRSqC2oSoi1s1ZVHteUk=.971f0216-7db6-4929-8310-61cb24ca3ea0@github.com>
References: <GUN_73n4tGiqwmNTooT9WVxzRSqC2oSoi1s1ZVHteUk=.971f0216-7db6-4929-8310-61cb24ca3ea0@github.com>
Message-ID: <_7hhMVDBlAR2bfHSyPIMAT5lN7UkZIUbKedUfJpK_gw=.148bce4a-1e8d-4572-aae3-42c29d53e193@github.com>

On Wed, 3 Dec 2025 16:07:07 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> We backed out this change in https://github.com/openjdk/jdk/pull/28617 after issues in found in testing. Moving forward, we've decided to problem list a few tests that assumes that a GC does not run during their execution. When the initial heap size becomes very low with this change, it may trigger additional GCs, which may interfere with a few tests.
> 
> We are planning to follow up on the problem lists with test fixes in:
> https://github.com/openjdk/jdk/pull/28638, https://github.com/openjdk/jdk/pull/28637
> 
> From the original RFE: 
> 
> This RFE changes the default of `InitialRAMPercentage` to 0, effectively removing its default value. Please see the CSR for specific details on this change.
> 
> Changing the default value to 0 results in the behavior that the initial heap size (InitialHeapSize) is set to the minimum heap size (MinHeapSize). This is because of the following lines in `Arguments::set_heap_size()`, which takes the MAX value of MinHeapSize as well:
> 
> uint64_t initial_memory = (uint64_t)(((double)MaxRAM * InitialRAMPercentage) / 100);
> ...
> 
> reasonable_initial = MAX3(reasonable_initial, reasonable_minimum, MinHeapSize);
> reasonable_initial = MIN2(reasonable_initial, MaxHeapSize);
> 
> 
> This change improves startup performance for all GCs, but affects the time-to-peak performance in some out-of-the-box configurations for some GCs. This is mainly visible in ParallelGC.
> 
> Testing:
> * Oracle's tier1-3

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28641#pullrequestreview-3535823126

From jsikstro at openjdk.org  Wed Dec  3 16:33:00 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 3 Dec 2025 16:33:00 GMT
Subject: RFR: 8373023: [REDO] Remove the default value of
 InitialRAMPercentage [v2]
In-Reply-To: <GUN_73n4tGiqwmNTooT9WVxzRSqC2oSoi1s1ZVHteUk=.971f0216-7db6-4929-8310-61cb24ca3ea0@github.com>
References: <GUN_73n4tGiqwmNTooT9WVxzRSqC2oSoi1s1ZVHteUk=.971f0216-7db6-4929-8310-61cb24ca3ea0@github.com>
Message-ID: <p3-ZrCGziJuIkHPjDbDRlfBRyG-8Za4fW6ZR0PZr65A=.78f91b82-92b5-4df3-8459-0e1a01389e27@github.com>

> Hello,
> 
> We backed out this change in https://github.com/openjdk/jdk/pull/28617 after issues in found in testing. Moving forward, we've decided to problem list a few tests that assumes that a GC does not run during their execution. When the initial heap size becomes very low with this change, it may trigger additional GCs, which may interfere with a few tests.
> 
> We are planning to follow up on the problem lists with test fixes in:
> https://github.com/openjdk/jdk/pull/28638, https://github.com/openjdk/jdk/pull/28637
> 
> From the original RFE: 
> 
> This RFE changes the default of `InitialRAMPercentage` to 0, effectively removing its default value. Please see the CSR for specific details on this change.
> 
> Changing the default value to 0 results in the behavior that the initial heap size (InitialHeapSize) is set to the minimum heap size (MinHeapSize). This is because of the following lines in `Arguments::set_heap_size()`, which takes the MAX value of MinHeapSize as well:
> 
> uint64_t initial_memory = (uint64_t)(((double)MaxRAM * InitialRAMPercentage) / 100);
> ...
> 
> reasonable_initial = MAX3(reasonable_initial, reasonable_minimum, MinHeapSize);
> reasonable_initial = MIN2(reasonable_initial, MaxHeapSize);
> 
> 
> This change improves startup performance for all GCs, but affects the time-to-peak performance in some out-of-the-box configurations for some GCs. This is mainly visible in ParallelGC.
> 
> Testing:
> * Oracle's tier1-3

Joel Sikstr?m has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Remove unnecessary line
 - 8373023: [REDO] Remove the default value of InitialRAMPercentage

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

Changes: https://git.openjdk.org/jdk/pull/28641/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28641&range=01
  Stats: 15 lines in 5 files changed: 11 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/28641.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28641/head:pull/28641

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

From stefank at openjdk.org  Wed Dec  3 16:33:01 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 3 Dec 2025 16:33:01 GMT
Subject: RFR: 8373023: [REDO] Remove the default value of
 InitialRAMPercentage [v2]
In-Reply-To: <p3-ZrCGziJuIkHPjDbDRlfBRyG-8Za4fW6ZR0PZr65A=.78f91b82-92b5-4df3-8459-0e1a01389e27@github.com>
References: <GUN_73n4tGiqwmNTooT9WVxzRSqC2oSoi1s1ZVHteUk=.971f0216-7db6-4929-8310-61cb24ca3ea0@github.com>
 <p3-ZrCGziJuIkHPjDbDRlfBRyG-8Za4fW6ZR0PZr65A=.78f91b82-92b5-4df3-8459-0e1a01389e27@github.com>
Message-ID: <PZ-i5m1OdLBGoa9Vj_vjNLXIDLsaLjF3rO0CCGFTAe8=.24d06758-c095-46fc-b91e-2e4bdd8f6a1f@github.com>

On Wed, 3 Dec 2025 16:30:04 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> We backed out this change in https://github.com/openjdk/jdk/pull/28617 after issues in found in testing. Moving forward, we've decided to problem list a few tests that assumes that a GC does not run during their execution. When the initial heap size becomes very low with this change, it may trigger additional GCs, which may interfere with a few tests.
>> 
>> We are planning to follow up on the problem lists with test fixes in:
>> https://github.com/openjdk/jdk/pull/28638, https://github.com/openjdk/jdk/pull/28637
>> 
>> From the original RFE: 
>> 
>> This RFE changes the default of `InitialRAMPercentage` to 0, effectively removing its default value. Please see the CSR for specific details on this change.
>> 
>> Changing the default value to 0 results in the behavior that the initial heap size (InitialHeapSize) is set to the minimum heap size (MinHeapSize). This is because of the following lines in `Arguments::set_heap_size()`, which takes the MAX value of MinHeapSize as well:
>> 
>> uint64_t initial_memory = (uint64_t)(((double)MaxRAM * InitialRAMPercentage) / 100);
>> ...
>> 
>> reasonable_initial = MAX3(reasonable_initial, reasonable_minimum, MinHeapSize);
>> reasonable_initial = MIN2(reasonable_initial, MaxHeapSize);
>> 
>> 
>> This change improves startup performance for all GCs, but affects the time-to-peak performance in some out-of-the-box configurations for some GCs. This is mainly visible in ParallelGC.
>> 
>> Testing:
>> * Oracle's tier1-3
>
> Joel Sikstr?m has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Remove unnecessary line
>  - 8373023: [REDO] Remove the default value of InitialRAMPercentage

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28641#pullrequestreview-3535924296

From sjohanss at openjdk.org  Wed Dec  3 16:33:01 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Wed, 3 Dec 2025 16:33:01 GMT
Subject: RFR: 8373023: [REDO] Remove the default value of
 InitialRAMPercentage [v2]
In-Reply-To: <p3-ZrCGziJuIkHPjDbDRlfBRyG-8Za4fW6ZR0PZr65A=.78f91b82-92b5-4df3-8459-0e1a01389e27@github.com>
References: <GUN_73n4tGiqwmNTooT9WVxzRSqC2oSoi1s1ZVHteUk=.971f0216-7db6-4929-8310-61cb24ca3ea0@github.com>
 <p3-ZrCGziJuIkHPjDbDRlfBRyG-8Za4fW6ZR0PZr65A=.78f91b82-92b5-4df3-8459-0e1a01389e27@github.com>
Message-ID: <j5pvKeN28hnk0wQBhE82dR0qM0ZR62JH_IpjEGKr9Sc=.ad274655-c1a5-46d5-a3a4-cb8834a168df@github.com>

On Wed, 3 Dec 2025 16:30:04 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> We backed out this change in https://github.com/openjdk/jdk/pull/28617 after issues in found in testing. Moving forward, we've decided to problem list a few tests that assumes that a GC does not run during their execution. When the initial heap size becomes very low with this change, it may trigger additional GCs, which may interfere with a few tests.
>> 
>> We are planning to follow up on the problem lists with test fixes in:
>> https://github.com/openjdk/jdk/pull/28638, https://github.com/openjdk/jdk/pull/28637
>> 
>> From the original RFE: 
>> 
>> This RFE changes the default of `InitialRAMPercentage` to 0, effectively removing its default value. Please see the CSR for specific details on this change.
>> 
>> Changing the default value to 0 results in the behavior that the initial heap size (InitialHeapSize) is set to the minimum heap size (MinHeapSize). This is because of the following lines in `Arguments::set_heap_size()`, which takes the MAX value of MinHeapSize as well:
>> 
>> uint64_t initial_memory = (uint64_t)(((double)MaxRAM * InitialRAMPercentage) / 100);
>> ...
>> 
>> reasonable_initial = MAX3(reasonable_initial, reasonable_minimum, MinHeapSize);
>> reasonable_initial = MIN2(reasonable_initial, MaxHeapSize);
>> 
>> 
>> This change improves startup performance for all GCs, but affects the time-to-peak performance in some out-of-the-box configurations for some GCs. This is mainly visible in ParallelGC.
>> 
>> Testing:
>> * Oracle's tier1-3
>
> Joel Sikstr?m has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Remove unnecessary line
>  - 8373023: [REDO] Remove the default value of InitialRAMPercentage

Looks good

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

Marked as reviewed by sjohanss (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28641#pullrequestreview-3535928296

From alanb at openjdk.org  Wed Dec  3 16:33:03 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 3 Dec 2025 16:33:03 GMT
Subject: RFR: 8373023: [REDO] Remove the default value of
 InitialRAMPercentage [v2]
In-Reply-To: <p3-ZrCGziJuIkHPjDbDRlfBRyG-8Za4fW6ZR0PZr65A=.78f91b82-92b5-4df3-8459-0e1a01389e27@github.com>
References: <GUN_73n4tGiqwmNTooT9WVxzRSqC2oSoi1s1ZVHteUk=.971f0216-7db6-4929-8310-61cb24ca3ea0@github.com>
 <p3-ZrCGziJuIkHPjDbDRlfBRyG-8Za4fW6ZR0PZr65A=.78f91b82-92b5-4df3-8459-0e1a01389e27@github.com>
Message-ID: <dzsdRNHb44Vj4VSTO6GSl8yPzRoJ0LoO3mb9SGrmTlc=.897d4ac3-57c6-4128-87a2-419168683f0a@github.com>

On Wed, 3 Dec 2025 16:30:04 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> We backed out this change in https://github.com/openjdk/jdk/pull/28617 after issues in found in testing. Moving forward, we've decided to problem list a few tests that assumes that a GC does not run during their execution. When the initial heap size becomes very low with this change, it may trigger additional GCs, which may interfere with a few tests.
>> 
>> We are planning to follow up on the problem lists with test fixes in:
>> https://github.com/openjdk/jdk/pull/28638, https://github.com/openjdk/jdk/pull/28637
>> 
>> From the original RFE: 
>> 
>> This RFE changes the default of `InitialRAMPercentage` to 0, effectively removing its default value. Please see the CSR for specific details on this change.
>> 
>> Changing the default value to 0 results in the behavior that the initial heap size (InitialHeapSize) is set to the minimum heap size (MinHeapSize). This is because of the following lines in `Arguments::set_heap_size()`, which takes the MAX value of MinHeapSize as well:
>> 
>> uint64_t initial_memory = (uint64_t)(((double)MaxRAM * InitialRAMPercentage) / 100);
>> ...
>> 
>> reasonable_initial = MAX3(reasonable_initial, reasonable_minimum, MinHeapSize);
>> reasonable_initial = MIN2(reasonable_initial, MaxHeapSize);
>> 
>> 
>> This change improves startup performance for all GCs, but affects the time-to-peak performance in some out-of-the-box configurations for some GCs. This is mainly visible in ParallelGC.
>> 
>> Testing:
>> * Oracle's tier1-3
>
> Joel Sikstr?m has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Remove unnecessary line
>  - 8373023: [REDO] Remove the default value of InitialRAMPercentage

test/jdk/ProblemList.txt line 718:

> 716: 
> 717: com/sun/jdi/InvokeHangTest.java                                 8218463 linux-all
> 718: com/sun/jdi/MethodInvokeWithTraceOnTest.java                    8373022 generic-all

What about java/lang/management/MemoryPoolMXBean/ThresholdTest.java, that was the test that started failing for me yesterday.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28641#discussion_r2585802135

From jsikstro at openjdk.org  Wed Dec  3 16:33:04 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 3 Dec 2025 16:33:04 GMT
Subject: RFR: 8373023: [REDO] Remove the default value of
 InitialRAMPercentage [v2]
In-Reply-To: <dzsdRNHb44Vj4VSTO6GSl8yPzRoJ0LoO3mb9SGrmTlc=.897d4ac3-57c6-4128-87a2-419168683f0a@github.com>
References: <GUN_73n4tGiqwmNTooT9WVxzRSqC2oSoi1s1ZVHteUk=.971f0216-7db6-4929-8310-61cb24ca3ea0@github.com>
 <p3-ZrCGziJuIkHPjDbDRlfBRyG-8Za4fW6ZR0PZr65A=.78f91b82-92b5-4df3-8459-0e1a01389e27@github.com>
 <dzsdRNHb44Vj4VSTO6GSl8yPzRoJ0LoO3mb9SGrmTlc=.897d4ac3-57c6-4128-87a2-419168683f0a@github.com>
Message-ID: <tz_PxS9CFDNHpnK7OsV3sNmfwqAhe854C0yuTAJ2xBY=.d6b4d10a-5113-4f69-b916-3d9466d0305c@github.com>

On Wed, 3 Dec 2025 16:24:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Joel Sikstr?m has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Remove unnecessary line
>>  - 8373023: [REDO] Remove the default value of InitialRAMPercentage
>
> test/jdk/ProblemList.txt line 718:
> 
>> 716: 
>> 717: com/sun/jdi/InvokeHangTest.java                                 8218463 linux-all
>> 718: com/sun/jdi/MethodInvokeWithTraceOnTest.java                    8373022 generic-all
> 
> What about java/lang/management/MemoryPoolMXBean/ThresholdTest.java, that was the test that started failing for me yesterday.

The test failure in java/lang/management/MemoryPoolMXBean/ThresholdTest.java is fixed in https://github.com/openjdk/jdk/pull/28630

This was a pre-existing issue that is not directly tied to this change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28641#discussion_r2585814488

From alanb at openjdk.org  Wed Dec  3 16:33:05 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 3 Dec 2025 16:33:05 GMT
Subject: RFR: 8373023: [REDO] Remove the default value of
 InitialRAMPercentage [v2]
In-Reply-To: <tz_PxS9CFDNHpnK7OsV3sNmfwqAhe854C0yuTAJ2xBY=.d6b4d10a-5113-4f69-b916-3d9466d0305c@github.com>
References: <GUN_73n4tGiqwmNTooT9WVxzRSqC2oSoi1s1ZVHteUk=.971f0216-7db6-4929-8310-61cb24ca3ea0@github.com>
 <p3-ZrCGziJuIkHPjDbDRlfBRyG-8Za4fW6ZR0PZr65A=.78f91b82-92b5-4df3-8459-0e1a01389e27@github.com>
 <dzsdRNHb44Vj4VSTO6GSl8yPzRoJ0LoO3mb9SGrmTlc=.897d4ac3-57c6-4128-87a2-419168683f0a@github.com>
 <tz_PxS9CFDNHpnK7OsV3sNmfwqAhe854C0yuTAJ2xBY=.d6b4d10a-5113-4f69-b916-3d9466d0305c@github.com>
Message-ID: <cUu0BWV8Yzyv_Wb1XO9pWMFvRlQ0kOK2U9LFBbxBMxk=.6fe7ccaf-b0d3-453d-91f6-56b578f170b1@github.com>

On Wed, 3 Dec 2025 16:27:50 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> test/jdk/ProblemList.txt line 718:
>> 
>>> 716: 
>>> 717: com/sun/jdi/InvokeHangTest.java                                 8218463 linux-all
>>> 718: com/sun/jdi/MethodInvokeWithTraceOnTest.java                    8373022 generic-all
>> 
>> What about java/lang/management/MemoryPoolMXBean/ThresholdTest.java, that was the test that started failing for me yesterday.
>
> The test failure in java/lang/management/MemoryPoolMXBean/ThresholdTest.java is fixed in https://github.com/openjdk/jdk/pull/28630
> 
> This was a pre-existing issue that is not directly tied to this change.

Thanks, I didn't see that change go by.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28641#discussion_r2585821941

From liach at openjdk.org  Wed Dec  3 16:43:24 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 3 Dec 2025 16:43:24 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v6]
In-Reply-To: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
Message-ID: <qmC_8KrBI4dTudSWMXPzMKMAwE24-kEfuEtSKaaVs4M=.b4fbf7c3-7fa4-485e-a0df-265fe4dbfa03@github.com>

> 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 two additional commits since the last revision:

 - Test from Jorn
 - Copyright years

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28585/files
  - new: https://git.openjdk.org/jdk/pull/28585/files/89e21b4b..ff7b3629

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

  Stats: 107 lines in 3 files changed: 105 ins; 0 del; 2 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 liach at openjdk.org  Wed Dec  3 16:46:44 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 3 Dec 2025 16:46:44 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v8]
In-Reply-To: <HOlXGoe8-oMYP_mCYb_xxO9F13ji624MlCfQ3-_zebM=.6240c45e-bf23-4799-b9c2-175460afa2d5@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
 <HOlXGoe8-oMYP_mCYb_xxO9F13ji624MlCfQ3-_zebM=.6240c45e-bf23-4799-b9c2-175460afa2d5@github.com>
Message-ID: <oivFNBHDut6vL19TEPdAv0Wh5-H63mpTOdnwogwOMT0=.87f3df38-2a52-4fdc-bc2d-1060a73efd16@github.com>

On Wed, 3 Dec 2025 13:17:45 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> ArrayKlass doesn't set AccessFlags so don't look for them there.  See CR for details.
>> Fixed SA and jvmci.  @iwanowww Can you check that I changed C2 correctly (we talked about this in August).
>> Tested with tier1-4.  5-7 in progress.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Take out ?: for array classes in set_raw_access_flags call.

Thanks for this update!

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28371#pullrequestreview-3535989981

From aboldtch at openjdk.org  Wed Dec  3 17:11:45 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 3 Dec 2025 17:11:45 GMT
Subject: RFR: 8373023: [REDO] Remove the default value of
 InitialRAMPercentage [v2]
In-Reply-To: <p3-ZrCGziJuIkHPjDbDRlfBRyG-8Za4fW6ZR0PZr65A=.78f91b82-92b5-4df3-8459-0e1a01389e27@github.com>
References: <GUN_73n4tGiqwmNTooT9WVxzRSqC2oSoi1s1ZVHteUk=.971f0216-7db6-4929-8310-61cb24ca3ea0@github.com>
 <p3-ZrCGziJuIkHPjDbDRlfBRyG-8Za4fW6ZR0PZr65A=.78f91b82-92b5-4df3-8459-0e1a01389e27@github.com>
Message-ID: <91wcjDr16DLwAqjJjEDY7vWy_0Vn0JWMFp-L4YKyhPk=.82048e1a-0915-4494-977d-f191a4ab1fea@github.com>

On Wed, 3 Dec 2025 16:33:00 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> We backed out this change in https://github.com/openjdk/jdk/pull/28617 after issues in found in testing. Moving forward, we've decided to problem list a few tests that assumes that a GC does not run during their execution. When the initial heap size becomes very low with this change, it may trigger additional GCs, which may interfere with a few tests.
>> 
>> We are planning to follow up on the problem lists with test fixes in:
>> https://github.com/openjdk/jdk/pull/28638, https://github.com/openjdk/jdk/pull/28637
>> 
>> From the original RFE: 
>> 
>> This RFE changes the default of `InitialRAMPercentage` to 0, effectively removing its default value. Please see the CSR for specific details on this change.
>> 
>> Changing the default value to 0 results in the behavior that the initial heap size (InitialHeapSize) is set to the minimum heap size (MinHeapSize). This is because of the following lines in `Arguments::set_heap_size()`, which takes the MAX value of MinHeapSize as well:
>> 
>> uint64_t initial_memory = (uint64_t)(((double)MaxRAM * InitialRAMPercentage) / 100);
>> ...
>> 
>> reasonable_initial = MAX3(reasonable_initial, reasonable_minimum, MinHeapSize);
>> reasonable_initial = MIN2(reasonable_initial, MaxHeapSize);
>> 
>> 
>> This change improves startup performance for all GCs, but affects the time-to-peak performance in some out-of-the-box configurations for some GCs. This is mainly visible in ParallelGC.
>> 
>> Testing:
>> * Oracle's tier1-3
>
> Joel Sikstr?m has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Remove unnecessary line
>  - 8373023: [REDO] Remove the default value of InitialRAMPercentage

Marked as reviewed by aboldtch (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28641#pullrequestreview-3536100361

From macarte at openjdk.org  Wed Dec  3 17:23:37 2025
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 3 Dec 2025 17:23:37 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v12]
In-Reply-To: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
Message-ID: <S9zq5vNrG8dXfRi-rLA58Lr2T4t9TF6LWS8ouA3vcig=.b6a62909-5dd8-4fe8-9c46-487f28be4813@github.com>

> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
> 
> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
> 
> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
> 
> TRUE
> FALSE
> 
> Passes tier1 on linux (x64) and windows (x64)

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

  Small doc change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28010/files
  - new: https://git.openjdk.org/jdk/pull/28010/files/0086e0ec..6024cf2e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28010&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28010&range=10-11

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

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

From coleenp at openjdk.org  Wed Dec  3 17:24:10 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 3 Dec 2025 17:24:10 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v13]
In-Reply-To: <p6lFKQ-dibdBFgeRjm2oaHSE1MwKSJ1x4gUXJNQRBX4=.96d83b12-93af-44c8-a0d5-50cb7e8e7b8d@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <p6lFKQ-dibdBFgeRjm2oaHSE1MwKSJ1x4gUXJNQRBX4=.96d83b12-93af-44c8-a0d5-50cb7e8e7b8d@github.com>
Message-ID: <xP9VPEsVoZNBEwVWfHCpiGaTR3BftJNSn0Q9NtIANg0=.49345947-5b9e-46e8-aa4c-0df492af83fe@github.com>

On Wed, 3 Dec 2025 15:27:06 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> 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

Still good! Maybe you should wait for the last three GHA actions to finish first

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28361#pullrequestreview-3536145413

From jsikstro at openjdk.org  Wed Dec  3 18:05:31 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 3 Dec 2025 18:05:31 GMT
Subject: RFR: 8373023: [REDO] Remove the default value of
 InitialRAMPercentage [v2]
In-Reply-To: <p3-ZrCGziJuIkHPjDbDRlfBRyG-8Za4fW6ZR0PZr65A=.78f91b82-92b5-4df3-8459-0e1a01389e27@github.com>
References: <GUN_73n4tGiqwmNTooT9WVxzRSqC2oSoi1s1ZVHteUk=.971f0216-7db6-4929-8310-61cb24ca3ea0@github.com>
 <p3-ZrCGziJuIkHPjDbDRlfBRyG-8Za4fW6ZR0PZr65A=.78f91b82-92b5-4df3-8459-0e1a01389e27@github.com>
Message-ID: <EYyhCO8nGZcmnywlm6DrYZUI88r3K4MDMjgWvrBA0uo=.d2b822f5-7bf3-49a3-87f0-1030d8ac4e41@github.com>

On Wed, 3 Dec 2025 16:33:00 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> We backed out this change in https://github.com/openjdk/jdk/pull/28617 after issues in found in testing. Moving forward, we've decided to problem list a few tests that assumes that a GC does not run during their execution. When the initial heap size becomes very low with this change, it may trigger additional GCs, which may interfere with a few tests.
>> 
>> We are planning to follow up on the problem lists with test fixes in:
>> https://github.com/openjdk/jdk/pull/28638, https://github.com/openjdk/jdk/pull/28637
>> 
>> From the original RFE: 
>> 
>> This RFE changes the default of `InitialRAMPercentage` to 0, effectively removing its default value. Please see the CSR for specific details on this change.
>> 
>> Changing the default value to 0 results in the behavior that the initial heap size (InitialHeapSize) is set to the minimum heap size (MinHeapSize). This is because of the following lines in `Arguments::set_heap_size()`, which takes the MAX value of MinHeapSize as well:
>> 
>> uint64_t initial_memory = (uint64_t)(((double)MaxRAM * InitialRAMPercentage) / 100);
>> ...
>> 
>> reasonable_initial = MAX3(reasonable_initial, reasonable_minimum, MinHeapSize);
>> reasonable_initial = MIN2(reasonable_initial, MaxHeapSize);
>> 
>> 
>> This change improves startup performance for all GCs, but affects the time-to-peak performance in some out-of-the-box configurations for some GCs. This is mainly visible in ParallelGC.
>> 
>> Testing:
>> * Oracle's tier1-3
>
> Joel Sikstr?m has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Remove unnecessary line
>  - 8373023: [REDO] Remove the default value of InitialRAMPercentage

Thank you for the reviews everyone!

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

PR Comment: https://git.openjdk.org/jdk/pull/28641#issuecomment-3608115890

From jsikstro at openjdk.org  Wed Dec  3 18:05:32 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 3 Dec 2025 18:05:32 GMT
Subject: Integrated: 8373023: [REDO] Remove the default value of
 InitialRAMPercentage
In-Reply-To: <GUN_73n4tGiqwmNTooT9WVxzRSqC2oSoi1s1ZVHteUk=.971f0216-7db6-4929-8310-61cb24ca3ea0@github.com>
References: <GUN_73n4tGiqwmNTooT9WVxzRSqC2oSoi1s1ZVHteUk=.971f0216-7db6-4929-8310-61cb24ca3ea0@github.com>
Message-ID: <BRclm-HgARNdCRAOjAiCEIIGQ2dgELZv69tns7uir4c=.dfc4a0f9-e878-4730-8eee-99a6dba0e257@github.com>

On Wed, 3 Dec 2025 16:07:07 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> We backed out this change in https://github.com/openjdk/jdk/pull/28617 after issues in found in testing. Moving forward, we've decided to problem list a few tests that assumes that a GC does not run during their execution. When the initial heap size becomes very low with this change, it may trigger additional GCs, which may interfere with a few tests.
> 
> We are planning to follow up on the problem lists with test fixes in:
> https://github.com/openjdk/jdk/pull/28638, https://github.com/openjdk/jdk/pull/28637
> 
> From the original RFE: 
> 
> This RFE changes the default of `InitialRAMPercentage` to 0, effectively removing its default value. Please see the CSR for specific details on this change.
> 
> Changing the default value to 0 results in the behavior that the initial heap size (InitialHeapSize) is set to the minimum heap size (MinHeapSize). This is because of the following lines in `Arguments::set_heap_size()`, which takes the MAX value of MinHeapSize as well:
> 
> uint64_t initial_memory = (uint64_t)(((double)MaxRAM * InitialRAMPercentage) / 100);
> ...
> 
> reasonable_initial = MAX3(reasonable_initial, reasonable_minimum, MinHeapSize);
> reasonable_initial = MIN2(reasonable_initial, MaxHeapSize);
> 
> 
> This change improves startup performance for all GCs, but affects the time-to-peak performance in some out-of-the-box configurations for some GCs. This is mainly visible in ParallelGC.
> 
> Testing:
> * Oracle's tier1-3

This pull request has now been integrated.

Changeset: 8d80778e
Author:    Joel Sikstr?m <jsikstro at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8d80778e05aee878f9a3e8beabe6a0cfd0a02c16
Stats:     15 lines in 5 files changed: 11 ins; 1 del; 3 mod

8373023: [REDO] Remove the default value of InitialRAMPercentage

Reviewed-by: stefank, sjohanss, aboldtch

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

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

From macarte at openjdk.org  Wed Dec  3 18:05:39 2025
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 3 Dec 2025 18:05:39 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v13]
In-Reply-To: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
Message-ID: <telpnxu2IwUklNb4a7PIyMk9er8fZQ5yMwn4Uzo6VWs=.396e33fa-1524-4254-bf01-4f0d5f1d98f9@github.com>

> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
> 
> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
> 
> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
> 
> TRUE
> FALSE
> 
> Passes tier1 on linux (x64) and windows (x64)

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

  Removed superfluous library

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28010/files
  - new: https://git.openjdk.org/jdk/pull/28010/files/6024cf2e..67400da9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28010&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28010&range=11-12

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

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

From macarte at openjdk.org  Wed Dec  3 18:05:42 2025
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 3 Dec 2025 18:05:42 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v8]
In-Reply-To: <ftPvHBlncWJz1yN6Gjclx4Z-QcgHijYUp2tJ1wQfP8Q=.ebd2ac22-0e3a-4f2f-83aa-4c753b6e806d@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <Tr-Hep5GKs8WK18D22iF09MA78Yf-AqmDN7lnXj7Lzs=.35a44c9a-6bce-4c9a-aa7f-e14051a1d2ec@github.com>
 <ftPvHBlncWJz1yN6Gjclx4Z-QcgHijYUp2tJ1wQfP8Q=.ebd2ac22-0e3a-4f2f-83aa-4c753b6e806d@github.com>
Message-ID: <CN17j92gSz5UikhTYA9KE6oDSAk6o8b8Emkn4lLdPG4=.6d7d314a-f207-4bc8-bfc5-1d58dd5c6398@github.com>

On Fri, 21 Nov 2025 11:44:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove single whitespace
>
> test/hotspot/jtreg/runtime/cds/appcds/aotCache/HotSpotAOTCacheMXBeanTest.java line 31:
> 
>> 29:  * @requires vm.cds.write.archived.java.heap
>> 30:  * @library /test/jdk/lib/testlibrary /test/lib
>> 31:  *          /test/hotspot/jtreg/runtime/cds/appcds/aotCache/test-classes
> 
> Is test-classes used?

Tested and removed, thank you!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2586114349

From kevinw at openjdk.org  Wed Dec  3 18:15:13 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 3 Dec 2025 18:15:13 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v13]
In-Reply-To: <telpnxu2IwUklNb4a7PIyMk9er8fZQ5yMwn4Uzo6VWs=.396e33fa-1524-4254-bf01-4f0d5f1d98f9@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <telpnxu2IwUklNb4a7PIyMk9er8fZQ5yMwn4Uzo6VWs=.396e33fa-1524-4254-bf01-4f0d5f1d98f9@github.com>
Message-ID: <mBqDaHJoy5Jh8wfuNbjXrJxhX9LEk_C2LuK0Z2a7cDU=.c17e4966-071f-4808-8095-f11b02b255c0@github.com>

On Wed, 3 Dec 2025 18:05:39 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
>> 
>> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
>> 
>> TRUE
>> FALSE
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed superfluous library

Looks good, thanks for the updates.
Would be great if you can get to the 4 vs 2 indent note from Alan.

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28010#pullrequestreview-3536328651

From eastigeevich at openjdk.org  Wed Dec  3 18:48:32 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Wed, 3 Dec 2025 18:48:32 GMT
Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact
 on GCs and JIT performance [v13]
In-Reply-To: <Kl5e4lLy09In3ii23YLueZVqzzzkBkZJLGAJb2k7Aio=.4347ba54-eb6b-4a9f-81e8-6db06a03824f@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
 <rtneArX_lMKv-UqOQNXv8DT_n8pY4UNn7nEE4FpKT4k=.ca641bc2-9d9a-4e0b-a329-da375913f5db@github.com>
 <Kl5e4lLy09In3ii23YLueZVqzzzkBkZJLGAJb2k7Aio=.4347ba54-eb6b-4a9f-81e8-6db06a03824f@github.com>
Message-ID: <TNyOayj-ljQFUNklcFWFkLkCAk0Rz445UnWVYw98SLE=.f8d83ee3-71d7-4011-bcab-87abf47ed9eb@github.com>

On Wed, 3 Dec 2025 16:10:55 GMT, Aleksey Shipilev <shade at openjdk.org> 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
>
> test/micro/org/openjdk/bench/vm/gc/GCPatchingNmethodCost.java line 184:
> 
>> 182:     @Benchmark
>> 183:     @Warmup(iterations = 0)
>> 184:     @Measurement(iterations = 1)
> 
> Not sure what is the intent here. Maybe you wanted `@BenchmarkMode(OneShot)` instead?

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)`.

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

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

From shade at openjdk.org  Wed Dec  3 18:53:13 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 3 Dec 2025 18:53:13 GMT
Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact
 on GCs and JIT performance [v13]
In-Reply-To: <TNyOayj-ljQFUNklcFWFkLkCAk0Rz445UnWVYw98SLE=.f8d83ee3-71d7-4011-bcab-87abf47ed9eb@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
 <rtneArX_lMKv-UqOQNXv8DT_n8pY4UNn7nEE4FpKT4k=.ca641bc2-9d9a-4e0b-a329-da375913f5db@github.com>
 <Kl5e4lLy09In3ii23YLueZVqzzzkBkZJLGAJb2k7Aio=.4347ba54-eb6b-4a9f-81e8-6db06a03824f@github.com>
 <TNyOayj-ljQFUNklcFWFkLkCAk0Rz445UnWVYw98SLE=.f8d83ee3-71d7-4011-bcab-87abf47ed9eb@github.com>
Message-ID: <q-Cu3xNrUYcTgpyEF_qQu_avHDvO9oSXi35vcEFJvko=.6b4baa37-f143-45b0-8e89-f5f560f5c8ae@github.com>

On Wed, 3 Dec 2025 18:45:25 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/vm/gc/GCPatchingNmethodCost.java line 184:
>> 
>>> 182:     @Benchmark
>>> 183:     @Warmup(iterations = 0)
>>> 184:     @Measurement(iterations = 1)
>> 
>> Not sure what is the intent here. Maybe you wanted `@BenchmarkMode(OneShot)` instead?
>
> 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.

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

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

From eastigeevich at openjdk.org  Wed Dec  3 18:53:10 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Wed, 3 Dec 2025 18:53:10 GMT
Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact
 on GCs and JIT performance [v13]
In-Reply-To: <Kl5e4lLy09In3ii23YLueZVqzzzkBkZJLGAJb2k7Aio=.4347ba54-eb6b-4a9f-81e8-6db06a03824f@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
 <rtneArX_lMKv-UqOQNXv8DT_n8pY4UNn7nEE4FpKT4k=.ca641bc2-9d9a-4e0b-a329-da375913f5db@github.com>
 <Kl5e4lLy09In3ii23YLueZVqzzzkBkZJLGAJb2k7Aio=.4347ba54-eb6b-4a9f-81e8-6db06a03824f@github.com>
Message-ID: <W5TcIjBx38SKka6sgFJbenaWPf4oFsex7UanJdj4zio=.d4f77822-8065-4a2f-8f78-e42f17942f24@github.com>

On Wed, 3 Dec 2025 16:00:05 GMT, Aleksey Shipilev <shade at openjdk.org> 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
>
> src/hotspot/share/asm/codeBuffer.cpp line 939:
> 
>> 937:     // Move all the code and relocations to the new blob:
>> 938:     relocate_code_to(&cb);
>> 939:   }
> 
> Here and later, the preferred style is:
> 
> Suggestion:
> 
>   // Move all the code and relocations to the new blob:
>   {
>     ICacheInvalidationContext icic(ICacheInvalidation::NOT_NEEDED);
>     relocate_code_to(&cb);
>   }

I followed @xmas92 comments on style to use a blank line. @xmas92, what style should I follow?

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

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

From macarte at openjdk.org  Wed Dec  3 19:17:50 2025
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 3 Dec 2025 19:17:50 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v14]
In-Reply-To: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
Message-ID: <rTxyRGAykexX1pJvT-C9gdnzlox3PaV5HsWZUbd4tWk=.b8266a59-b1af-4c2f-9aef-461561d84ca2@github.com>

> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
> 
> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
> 
> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
> 
> TRUE
> FALSE
> 
> Passes tier1 on linux (x64) and windows (x64)

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

  Fixed indent and spacing issues

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28010/files
  - new: https://git.openjdk.org/jdk/pull/28010/files/67400da9..6cd920da

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28010&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28010&range=12-13

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

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

From vlivanov at openjdk.org  Wed Dec  3 19:39:56 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 3 Dec 2025 19:39:56 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v6]
In-Reply-To: <qmC_8KrBI4dTudSWMXPzMKMAwE24-kEfuEtSKaaVs4M=.b4fbf7c3-7fa4-485e-a0df-265fe4dbfa03@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <qmC_8KrBI4dTudSWMXPzMKMAwE24-kEfuEtSKaaVs4M=.b4fbf7c3-7fa4-485e-a0df-265fe4dbfa03@github.com>
Message-ID: <OChEencVyX1xRYDW-2u0O8R8fO6WS8IbXAbP47uALcY=.c5158037-ff46-4b6d-be4d-ec68c756cb3b@github.com>

On Wed, 3 Dec 2025 16:43:24 GMT, Chen Liang <liach at openjdk.org> 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 two additional commits since the last revision:
> 
>  - Test from Jorn
>  - Copyright years

src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2036:

> 2034:         // from two writes (they must not be tearable)
> 2035:         private record Adaption(VarHandle vh, MethodHandle mh) {}
> 2036:         private @Stable Adaption adaption;

Is a soft reference needed here? The situation looks similar to `MH.asTypeSoftCache`. It can keep some classes referred by `vh` alive for unnecessarily long.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2586374014

From macarte at openjdk.org  Wed Dec  3 19:40:07 2025
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 3 Dec 2025 19:40:07 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v8]
In-Reply-To: <exRz3HQ-bV93DEgOuUZxw3NRkQlBtxK734A8jTw70i8=.9498a654-570a-4746-a751-f0bc3d58a688@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <Tr-Hep5GKs8WK18D22iF09MA78Yf-AqmDN7lnXj7Lzs=.35a44c9a-6bce-4c9a-aa7f-e14051a1d2ec@github.com>
 <exRz3HQ-bV93DEgOuUZxw3NRkQlBtxK734A8jTw70i8=.9498a654-570a-4746-a751-f0bc3d58a688@github.com>
Message-ID: <ct5U7Bzb-43CkS0AZb_QuDzafz34vAVcF0F0nRpTXGw=.c3216144-d8b9-4159-bf9a-c054d31444d6@github.com>

On Fri, 21 Nov 2025 11:33:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove single whitespace
>
> src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 97:
> 
>> 95:    * successfully; {@code false} otherwise.
>> 96:    */
>> 97:    public boolean endRecording();
> 
> Minor nit is that we usually use 4-space rather than 2-space indent in the java sources. You might want to check the /** .. */ comments in a few of the files as they are misaligned in a few places.

fixed - thank you

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2586374138

From eastigeevich at openjdk.org  Wed Dec  3 19:51:32 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Wed, 3 Dec 2025 19:51:32 GMT
Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact
 on GCs and JIT performance [v13]
In-Reply-To: <q-Cu3xNrUYcTgpyEF_qQu_avHDvO9oSXi35vcEFJvko=.6b4baa37-f143-45b0-8e89-f5f560f5c8ae@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
 <rtneArX_lMKv-UqOQNXv8DT_n8pY4UNn7nEE4FpKT4k=.ca641bc2-9d9a-4e0b-a329-da375913f5db@github.com>
 <Kl5e4lLy09In3ii23YLueZVqzzzkBkZJLGAJb2k7Aio=.4347ba54-eb6b-4a9f-81e8-6db06a03824f@github.com>
 <TNyOayj-ljQFUNklcFWFkLkCAk0Rz445UnWVYw98SLE=.f8d83ee3-71d7-4011-bcab-87abf47ed9eb@github.com>
 <q-Cu3xNrUYcTgpyEF_qQu_avHDvO9oSXi35vcEFJvko=.6b4baa37-f143-45b0-8e89-f5f560f5c8ae@github.com>
Message-ID: <eXswBzRDVTunuOvsneav_TJ_HdU_M4xRp4lzYWmgjIs=.df5bc49c-1342-47d1-8016-9f2b9399b4a5@github.com>

On Wed, 3 Dec 2025 18:50:44 GMT, Aleksey Shipilev <shade at openjdk.org> 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.

I have `Thread.sleep(1000)` in `setupCodeCache()` to let everything to settle down. I use it because I saw high variance in GC times. With it variance became OK.

Maybe I should use `System.gc()` instead of `Thread.sleep`.

> So you probably want OneShot with the default number of iterations.

Will I need to recreate an object and to rerun Java methods before each iteration? The first iteration will collect garbage object `fields`. So following iterations running GC will do nothing. Or will they patch nmethods again?

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

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

From kvn at openjdk.org  Wed Dec  3 19:53:25 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 3 Dec 2025 19:53:25 GMT
Subject: RFR: 8357258: x86: Improve receiver type profiling reliability
 [v8]
In-Reply-To: <avqNAcH5MpUoM31mrtm0Z6qnPqpgbpGszW01AtFbYXk=.359b8088-c0b5-4a01-aefc-fe3c02bdd60a@github.com>
References: <X9RJoDWqk67MlK7P4ACCbzROxLkfEqvU0zDid3zymnc=.7c0086a3-f514-4b0d-8bc0-592bf4a05bba@github.com>
 <avqNAcH5MpUoM31mrtm0Z6qnPqpgbpGszW01AtFbYXk=.359b8088-c0b5-4a01-aefc-fe3c02bdd60a@github.com>
Message-ID: <F0AGcHFzher5MFo5wCM7sEhsj0ZzRCIvsDtJ1VRKhp8=.083e1cb9-ed66-4a59-807d-78023a974c4c@github.com>

On Tue, 2 Dec 2025 10:31:22 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the bug for discussion what issues current machinery has. 
>> 
>> This PR executes the plan outlined in the bug:
>>  1. Common the receiver type profiling code in interpreter and C1
>>  2. Rewrite receiver type profiling code to only do atomic receiver slot installations
>>  3. Trim `C1OptimizeVirtualCallProfiling` to only claim slots when receiver is installed 
>> 
>> This PR does _not_ do atomic counter updates themselves, as it may have much wider performance implications, including regressions. This PR should be at least performance neutral.
>> 
>> Additional testing:
>>   - [x] Linux x86_64 server fastdebug, `compiler/`
>>   - [x] Linux x86_64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:
> 
>  - 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
>  - Offset is always rscratch1, no need to save it
>  - Grossly simplify register shuffling
>  - ... and 11 more: https://git.openjdk.org/jdk/compare/7278d2e8...3c5019d9

This looks good. Thank you for cleaning up code and detailed comments.
I submitted our testing.

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

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

From asmehra at openjdk.org  Wed Dec  3 19:53:45 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Wed, 3 Dec 2025 19:53:45 GMT
Subject: RFR: 8373046: Method::get_c2i_unverified_entry() and
 get_c2i_no_clinit_check_entry() are missing check for abstract method
Message-ID: <0J8wPEDgQcJlN-yVMzfGoAFO02Km2Hv3zYJobWMNmFM=.b80b95b3-58b9-4b2f-94ee-db0025d14cb4@github.com>

This PR fixes a bug introduced by [JDK-8365501](https://bugs.openjdk.org/browse/JDK-8365501). It restores the behavior of `Method::get_c2i_unverified_entry` or `Method::get_c2i_no_clinit_check_entry` for abstract methods as it was before JDK-8365501. It was never the intention of JDK-8365501 to change the behavior.
I am not sure if there is any possible code flow that can result in calling `Method::get_c2i_unverified_entry` or `Method::get_c2i_no_clinit_check_entry` for abstract methods, but I think it is safe to keep the behavior of these functions as before.

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

Commit messages:
 - 8373046: Method::get_c2i_unverified_entry() and get_c2i_no_clinit_check_entry() are missing check for abstract method

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

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

From pchilanomate at openjdk.org  Wed Dec  3 20:01:11 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 3 Dec 2025 20:01:11 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v13]
In-Reply-To: <xP9VPEsVoZNBEwVWfHCpiGaTR3BftJNSn0Q9NtIANg0=.49345947-5b9e-46e8-aa4c-0df492af83fe@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <p6lFKQ-dibdBFgeRjm2oaHSE1MwKSJ1x4gUXJNQRBX4=.96d83b12-93af-44c8-a0d5-50cb7e8e7b8d@github.com>
 <xP9VPEsVoZNBEwVWfHCpiGaTR3BftJNSn0Q9NtIANg0=.49345947-5b9e-46e8-aa4c-0df492af83fe@github.com>
Message-ID: <plvMeLzQ8ppJ9pZsbY18b-L6RBEIFapI3Ex3L71zQkY=.0b000a39-22f7-49c6-993b-4b5979f80f93@github.com>

On Wed, 3 Dec 2025 17:21:33 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Still good! Maybe you should wait for the last three GHA actions to finish first
>
Done now. Thanks for the re-review Coleen!

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

PR Comment: https://git.openjdk.org/jdk/pull/28361#issuecomment-3608600548

From pchilanomate at openjdk.org  Wed Dec  3 20:04:36 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 3 Dec 2025 20:04:36 GMT
Subject: Integrated: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI
In-Reply-To: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
Message-ID: <R7yo6-n9jaF5YwNegJZRZpbmgaQj7HSl3ozX0cF_sb0=.90ad397f-075e-4387-921f-0c5d3ac9d939@github.com>

On Mon, 17 Nov 2025 20:19:58 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> 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 terms of mount and un...

This pull request has now been integrated.

Changeset: e534ee99
Author:    Patricio Chilano Mateo <pchilanomate at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e534ee99327fed2263302a00061fb46fcdc6e302
Stats:     1957 lines in 41 files changed: 914 ins; 823 del; 220 mod

8364343: Virtual Thread transition management needs to be independent of JVM TI

Co-authored-by: Alan Bateman <alanb at openjdk.org>
Reviewed-by: coleenp, dholmes, sspitsyn

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

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

From kvn at openjdk.org  Wed Dec  3 20:07:26 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 3 Dec 2025 20:07:26 GMT
Subject: RFR: 8373046: Method::get_c2i_unverified_entry() and
 get_c2i_no_clinit_check_entry() are missing check for abstract method
In-Reply-To: <0J8wPEDgQcJlN-yVMzfGoAFO02Km2Hv3zYJobWMNmFM=.b80b95b3-58b9-4b2f-94ee-db0025d14cb4@github.com>
References: <0J8wPEDgQcJlN-yVMzfGoAFO02Km2Hv3zYJobWMNmFM=.b80b95b3-58b9-4b2f-94ee-db0025d14cb4@github.com>
Message-ID: <MO4uR7w9ma1YSbPyObrys2SmWVDEXxIM9JJCLqAGmsY=.028061f6-1575-43e2-a7e8-4109ee3d9dbc@github.com>

On Wed, 3 Dec 2025 19:45:12 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

> This PR fixes a bug introduced by [JDK-8365501](https://bugs.openjdk.org/browse/JDK-8365501). It restores the behavior of `Method::get_c2i_unverified_entry` or `Method::get_c2i_no_clinit_check_entry` for abstract methods as it was before JDK-8365501. It was never the intention of JDK-8365501 to change the behavior.
> I am not sure if there is any possible code flow that can result in calling `Method::get_c2i_unverified_entry` or `Method::get_c2i_no_clinit_check_entry` for abstract methods, but I think it is safe to keep the behavior of these functions as before.

src/hotspot/share/oops/method.cpp line 180:

> 178: address Method::get_c2i_no_clinit_check_entry() {
> 179:   if (is_abstract()) {
> 180:     return nullptr;

Why it is `nullptr` instead of `SharedRuntime::get_handle_wrong_method_abstract_stub()`. Add comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28645#discussion_r2586449811

From coleenp at openjdk.org  Wed Dec  3 20:28:59 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 3 Dec 2025 20:28:59 GMT
Subject: RFR: 8366671: Refactor Thread::SpinAcquire and Thread::SpinRelease
 [v12]
In-Reply-To: <BLbZykwmGPMfOyN0A7lrjaht-OWDbWK9_ArQRZZTVCU=.4bbd7292-3028-44f2-b0a5-cb4f29c2044b@github.com>
References: <NtY8E8fBeSokCAQYP3OQEwfnppSugtTJ8uAtQtD0zvg=.88f2988d-47fd-4b8a-af89-488ed6b37870@github.com>
 <BLbZykwmGPMfOyN0A7lrjaht-OWDbWK9_ArQRZZTVCU=.4bbd7292-3028-44f2-b0a5-cb4f29c2044b@github.com>
Message-ID: <GphLP_jJx0h1zS2RFbwjwr8GRPSmuwWX-c2N4anppbc=.43d82645-6d50-4675-a735-988f77ee4b1c@github.com>

On Wed, 3 Dec 2025 14:04:28 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, 
>> 
>> please consider the following changes:
>> 
>> In this PR `Thread::SpinAcquire()` and `Thread::SpinRelease()` methods are refactored into a utility class `SpinCriticalSection`. The motivation is to make it easier for developers to use this lightweight synchronization mechanism in the codebase. The two aforementioned methods were used in JFR to create short critical sections with a helper class, but that was not the case for the object monitor code. 
>> 
>> Tested in tiers 1 - 5.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8366671: Added NoSafepointVerifier

The NSV addition seems okay.  I was afraid it would be messier than it turned out to be.  Thanks.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28264#pullrequestreview-3536796538

From aph at openjdk.org  Wed Dec  3 20:40:45 2025
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 3 Dec 2025 20:40:45 GMT
Subject: RFR: 8363996: Obsolete UseCompressedClassPointers
In-Reply-To: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
References: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
Message-ID: <1ylERIxcH47S_3TkReUXaGLfMgYBVrvniM-2qMcReMg=.4a242937-c1db-45e9-b905-9df0dece3cc4@github.com>

On Tue, 18 Nov 2025 08:17:37 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> _This patch is not intended for JDK 26_. 
> 
> I'm posting it now to collect feedback and, barring any objections, plan to push it once JDK 27 opens.
> 
> This change removes the uncompressed Klass pointer mode and, with compressed Klass pointers remaining as the only option, the `UseCompressedClassPointers` switch.
> 
> For motivation, please take a look at CSR associated with the deprecation (which we did for JDK 25) and the preparatory discussion we had at the start of the year around this topic [2].
> 
> This patch is quite invasive and touches many parts of the JVM, since its goal is to remove most traces of the uncompressed Klass path and to take advantage of opportunities for simplification. In some cases, I did not take opportunities for further simplification to keep the patch somewhat legible; it will be onerous enough to review.
> 
> ### Implementation Notes
> 
> With uncompressed Klass pointers removed, we have three modes of operation left (including 32-bit):
>   a) 64-bit, COH off - this is the old `+UseCompressedClassPointers` mode. This is now the standard mode until we run with COH by default.
>   b) 64-bit, COH on
>   c) 32-bit - Here, we run with a "fake" narrow Klass pointer mode. We run with hardcoded narrowKlass base == NULL and shift = 0, so nKlass == Klass*. The difference to (a, b) is that we don't use a class space. This was implemented with JDK-8363998 [3] - for more details, please see that issue and its PR.
> 
> I ensured *arm32* builds and I performed some rudimentary checks (selected metaspace/gc tests, and a simple Spring PetClinic run). Vendors with an interest in arm32 will have to step up and do their own, more thorough unit testing. Also, I did not see anyone doing follow-up work after JDK-8363998 [3] - so some issues may still lurk from that patch as well (but maybe JDK-8363998 was just not breaking anything).
> 
> I did not check *zero 32-bit*, the only other platform supporting 32-bit. Anyone with an interest in 32-bit zero should chip in.
>   
> Pre-existing errors: While working on this patch, I stumbled over a few occurrences of old but benign bugs. Mostly old code assuming CompressedClassPointers and CompressedOops were still tied together (example: Arguments::set_heap_size()). These bugs are implicitly fixed with this patch.
> 
> ### Testing
> 
> - tier 1 2 3 locally on Linux x64
> - SAP ran their whole set of tests for all the platforms they support.
> 
> 
> [1] https://bugs.openjdk.org/browse/JDK-8350754
> [2] https://mail.openjdk.org/pipermail/hotspot-dev/2025-February...

https://github.com/openjdk/jdk/pull/28366/files?w=1 makes this PR easier to read.

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

PR Comment: https://git.openjdk.org/jdk/pull/28366#issuecomment-3608746121

From aph at openjdk.org  Wed Dec  3 20:45:53 2025
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 3 Dec 2025 20:45:53 GMT
Subject: RFR: 8363996: Obsolete UseCompressedClassPointers
In-Reply-To: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
References: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
Message-ID: <wOU0vkAx2Rnk5yOY9DcWnZpAGIJU8dvt0aAksOCKkRA=.6a8bf8a7-360d-4b27-82e6-5e19e4376b13@github.com>

On Tue, 18 Nov 2025 08:17:37 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> _This patch is not intended for JDK 26_. 
> 
> I'm posting it now to collect feedback and, barring any objections, plan to push it once JDK 27 opens.
> 
> This change removes the uncompressed Klass pointer mode and, with compressed Klass pointers remaining as the only option, the `UseCompressedClassPointers` switch.
> 
> For motivation, please take a look at CSR associated with the deprecation (which we did for JDK 25) and the preparatory discussion we had at the start of the year around this topic [2].
> 
> This patch is quite invasive and touches many parts of the JVM, since its goal is to remove most traces of the uncompressed Klass path and to take advantage of opportunities for simplification. In some cases, I did not take opportunities for further simplification to keep the patch somewhat legible; it will be onerous enough to review.
> 
> ### Implementation Notes
> 
> With uncompressed Klass pointers removed, we have three modes of operation left (including 32-bit):
>   a) 64-bit, COH off - this is the old `+UseCompressedClassPointers` mode. This is now the standard mode until we run with COH by default.
>   b) 64-bit, COH on
>   c) 32-bit - Here, we run with a "fake" narrow Klass pointer mode. We run with hardcoded narrowKlass base == NULL and shift = 0, so nKlass == Klass*. The difference to (a, b) is that we don't use a class space. This was implemented with JDK-8363998 [3] - for more details, please see that issue and its PR.
> 
> I ensured *arm32* builds and I performed some rudimentary checks (selected metaspace/gc tests, and a simple Spring PetClinic run). Vendors with an interest in arm32 will have to step up and do their own, more thorough unit testing. Also, I did not see anyone doing follow-up work after JDK-8363998 [3] - so some issues may still lurk from that patch as well (but maybe JDK-8363998 was just not breaking anything).
> 
> I did not check *zero 32-bit*, the only other platform supporting 32-bit. Anyone with an interest in 32-bit zero should chip in.
>   
> Pre-existing errors: While working on this patch, I stumbled over a few occurrences of old but benign bugs. Mostly old code assuming CompressedClassPointers and CompressedOops were still tied together (example: Arguments::set_heap_size()). These bugs are implicitly fixed with this patch.
> 
> ### Testing
> 
> - tier 1 2 3 locally on Linux x64
> - SAP ran their whole set of tests for all the platforms they support.
> 
> 
> [1] https://bugs.openjdk.org/browse/JDK-8350754
> [2] https://mail.openjdk.org/pipermail/hotspot-dev/2025-February...

src/hotspot/share/oops/klass.cpp line 1063:

> 1061:   // This can be expensive, but it is worth checking that this klass is actually
> 1062:   // in the CLD graph but not in production.
> 1063: 

Suggestion:


Stray blank line?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2586552890

From mr at openjdk.org  Wed Dec  3 20:47:40 2025
From: mr at openjdk.org (Mark Reinhold)
Date: Wed, 3 Dec 2025 20:47:40 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v12]
In-Reply-To: <S9zq5vNrG8dXfRi-rLA58Lr2T4t9TF6LWS8ouA3vcig=.b6a62909-5dd8-4fe8-9c46-487f28be4813@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <S9zq5vNrG8dXfRi-rLA58Lr2T4t9TF6LWS8ouA3vcig=.b6a62909-5dd8-4fe8-9c46-487f28be4813@github.com>
Message-ID: <2BNyWIHsF3Idzqy1u0MlC_K6nvb_k6_aWOKzHXhf1PQ=.326df265-59ff-4fe9-a244-dc88246a4afb@github.com>

On Wed, 3 Dec 2025 17:23:37 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
>> 
>> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
>> 
>> TRUE
>> FALSE
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Small doc change

Changes requested by mr (Lead).

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

PR Review: https://git.openjdk.org/jdk/pull/28010#pullrequestreview-3536758143

From mr at openjdk.org  Wed Dec  3 20:47:48 2025
From: mr at openjdk.org (Mark Reinhold)
Date: Wed, 3 Dec 2025 20:47:48 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v11]
In-Reply-To: <dGQiREV1bRcNuIAhjHDSSsR6369oD24FlT7Ud1U2_ok=.8aa2ac09-dc96-48b0-8de2-e3ca6457386f@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <dGQiREV1bRcNuIAhjHDSSsR6369oD24FlT7Ud1U2_ok=.8aa2ac09-dc96-48b0-8de2-e3ca6457386f@github.com>
Message-ID: <1vNADqcyDvebfWHyjYF0BEgWb7-xhh_f2GHdBnEaZQQ=.9415cb27-f2b8-4214-86b2-72772d7cb278@github.com>

On Wed, 26 Nov 2025 20:35:11 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
>> 
>> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
>> 
>> TRUE
>> FALSE
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed spaces and CRLF

src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 37:

> 35:  * <p> The management interface is registered with the platform {@link MBeanServer
> 36:  * MBeanServer}. The {@link ObjectName ObjectName} that uniquely identifies the management
> 37:  * interface within the {@code MBeanServer} is: "jdk.management:type=HotSpotAOTCache".

Drop the colon after "is", and put the object name in `{@code ...}` rather than double quotes.

src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 44:

> 42:  * {@code HotSpotAOTCacheMXBean} defines one operation at this time to
> 43:  * end the AOT recording. More operations and/or properties may be added in a
> 44:  * future release.

Drop this paragraph. It's obvious that there's only one operation, and uncertain statements about future releases add no value.

src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 50:

> 48: public interface HotSpotAOTCacheMXBean extends PlatformManagedObject {
> 49:   /**
> 50:    * If an AOT recording is in progress, ends the recording. This operation completes

s/operation completes/method returns/

src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 53:

> 51:    * after the AOT artifacts have been completely written.
> 52:    *
> 53:    * <p>The JVM will start recording AOT artifacts upon start-up if certain JVM options are

s/certain/appropriate/ -- "certain" suggests that you're not going to tell the reader what they are.

src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 57:

> 55:    * the {@code endRecording} method is called. Examples:
> 56:    *
> 57:    * <p> java -XX:AOTCacheOutput=app.aot ....

Put this command, and the others below, in `{@code ...}`, and precede them with a dollar prompt (`$`) so that they look more like command lines.

src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 63:

> 61:    *    that will be used to generate the AOT cache file app.aot. In a future execution of this application,
> 62:    *    -XX:AOTCache=app.aot can be provided to improve the application's
> 63:    *    start-up and warm-up performance.

Tighten and clarify: `The JVM records optimization information for the current application in the AOT cache file {@code app.aot}. in a future run of the application, the option {@code -XX:AOTCache=app.aot} will cause the JVM to use the cache to improve the application's startup and warmup performance.`

src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 69:

> 67:    *
> 68:    * <blockquote>
> 69:    *    The JVM will record optimization information about the current application

`The JVM records optimization information for the current application in the AOT configuration file {@code app.aotconfig}. ...`

src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 84:

> 82:    *
> 83:    * <p> There are also no APIs to querying whether the AOT recording is in progress, or what AOT
> 84:    * artifacts are being recorded.

Drop "Note:", it's meaningless. Merge these two paragraphs. s/to querying/to query/. s/the AOT/an AOT/.

src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 92:

> 90:    * procedures rely on an external agent to select the correct moment to end training.
> 91:    * In this way the selected length of training produces the correct set of AOT
> 92:    * optimizations in the AOT archive, without interfering with the application code.

You seem to be saying here that using this method from within an application is not necessarily the best approach, but you say it in a very roundabout way. Consider something like:

     * This method enables an application to end its own AOT recording
     * programatically, but that is not necessarily the best approach. Doing so
     * requires changing the application?s code, which might not be
     * feasible. Even when it is feasible, injecting training-specific logic
     * into the application reduces the similarity between training runs and
     * production runs, potentially making the AOT cache less effective. It may
     * be better to arrange for an external agent to end the training run,
     * thereby creating an AOT cache without interfering with the application?s
     * code.
 ```

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2586483272
PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2586486393
PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2586493320
PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2586488596
PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2586490840
PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2586506998
PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2586509392
PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2586515533
PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2586550031

From mr at openjdk.org  Wed Dec  3 20:47:50 2025
From: mr at openjdk.org (Mark Reinhold)
Date: Wed, 3 Dec 2025 20:47:50 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v11]
In-Reply-To: <CUcdfulNom90fhuZZOM5TtD3CaxWXOKXuiLHNET5AmQ=.06bb6eba-ec1f-42c8-82c0-7cba07d1d32e@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <dGQiREV1bRcNuIAhjHDSSsR6369oD24FlT7Ud1U2_ok=.8aa2ac09-dc96-48b0-8de2-e3ca6457386f@github.com>
 <CUcdfulNom90fhuZZOM5TtD3CaxWXOKXuiLHNET5AmQ=.06bb6eba-ec1f-42c8-82c0-7cba07d1d32e@github.com>
Message-ID: <C4YPT2GKTm42OjocWetcXwiTJ7xKDNppLKVNXxMkudg=.53fa3511-0cc2-442d-8f76-28328e0e5c8a@github.com>

On Wed, 3 Dec 2025 10:02:55 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed spaces and CRLF
>
> src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 78:
> 
>> 76:    * <p>For more information about creating and using the AOT artifacts, and detailed
>> 77:    * specification of the corresponding JVM command-line options, please refer
>> 78:    * to <a href="https://openjdk.org/jeps/483">483</a> and <a href="https://openjdk.org/jeps/514">514</a>.
> 
> One more late nit: these links have just the raw number in the link text. Better to have:
> 
> * to <a href="https://openjdk.org/jeps/483">JEP 483</a> and <a href="https://openjdk.org/jeps/514">JEP 514</a>.

My original suggestion was to say `please refer to JEPs <a href=...>483</a> and <a href=...>514</a>`, but this is fine, too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2586511793

From pchilanomate at openjdk.org  Wed Dec  3 21:07:08 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 3 Dec 2025 21:07:08 GMT
Subject: RFR: 8366671: Refactor Thread::SpinAcquire and Thread::SpinRelease
 [v12]
In-Reply-To: <BLbZykwmGPMfOyN0A7lrjaht-OWDbWK9_ArQRZZTVCU=.4bbd7292-3028-44f2-b0a5-cb4f29c2044b@github.com>
References: <NtY8E8fBeSokCAQYP3OQEwfnppSugtTJ8uAtQtD0zvg=.88f2988d-47fd-4b8a-af89-488ed6b37870@github.com>
 <BLbZykwmGPMfOyN0A7lrjaht-OWDbWK9_ArQRZZTVCU=.4bbd7292-3028-44f2-b0a5-cb4f29c2044b@github.com>
Message-ID: <0akXzzAj2Qo0u8Es21NeLBJvj2JJrHj-4s1OfiiM3Ts=.45c7d1e1-9910-4aa7-95b3-97bec8dd3fb6@github.com>

On Wed, 3 Dec 2025 14:04:28 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, 
>> 
>> please consider the following changes:
>> 
>> In this PR `Thread::SpinAcquire()` and `Thread::SpinRelease()` methods are refactored into a utility class `SpinCriticalSection`. The motivation is to make it easier for developers to use this lightweight synchronization mechanism in the codebase. The two aforementioned methods were used in JFR to create short critical sections with a helper class, but that was not the case for the object monitor code. 
>> 
>> Tested in tiers 1 - 5.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8366671: Added NoSafepointVerifier

Looks good to me.

src/hotspot/share/runtime/objectMonitor.cpp line 2056:

> 2054:       // there is nothing to do.
> 2055:       if (old_state == java_lang_VirtualThread::WAIT ||
> 2056:         old_state == java_lang_VirtualThread::TIMED_WAIT) {

The original alignment was correct.

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

PR Review: https://git.openjdk.org/jdk/pull/28264#pullrequestreview-3536920406
PR Review Comment: https://git.openjdk.org/jdk/pull/28264#discussion_r2586603053

From duke at openjdk.org  Wed Dec  3 21:35:02 2025
From: duke at openjdk.org (Chad Rakoczy)
Date: Wed, 3 Dec 2025 21:35:02 GMT
Subject: RFR: 8371046: Segfault in
 compiler/whitebox/StressNMethodRelocation.java with -XX:+UseZGC [v2]
In-Reply-To: <zXb73XKxhhc_-Jm6UHqr8ouQdO4X9-jKTUIPEbNg6vU=.97f87d35-67ee-481d-b6a9-5fbf281f0a69@github.com>
References: <k0-Cr7yor3F4OKDiZdT3lIrFiSgI_YRCR8_FphgQmlk=.4f60b60e-127d-413e-ab8f-26d6c4911142@github.com>
 <hQo3CkLhsZLq7-L4_5ui7eXaoycrENU5zyFS4JwzvVE=.a78ad8ce-8435-4009-a6c0-28fde884ac63@github.com>
 <zXb73XKxhhc_-Jm6UHqr8ouQdO4X9-jKTUIPEbNg6vU=.97f87d35-67ee-481d-b6a9-5fbf281f0a69@github.com>
Message-ID: <j0iwzJzJKPYtJ_EDb0cYr-q_INNDuLShuOYCZLb4cdo=.264f1c4a-e8dc-4764-bbbb-fd2963dbb92f@github.com>

On Wed, 3 Dec 2025 04:00:16 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Thank you. I tentatively approve you fix waiting results of your testing.

My testing passed and the original crash no longer reproduces. Thanks for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/28241#issuecomment-3608916279

From duke at openjdk.org  Wed Dec  3 21:35:06 2025
From: duke at openjdk.org (duke)
Date: Wed, 3 Dec 2025 21:35:06 GMT
Subject: RFR: 8371046: Segfault in
 compiler/whitebox/StressNMethodRelocation.java with -XX:+UseZGC [v2]
In-Reply-To: <hQo3CkLhsZLq7-L4_5ui7eXaoycrENU5zyFS4JwzvVE=.a78ad8ce-8435-4009-a6c0-28fde884ac63@github.com>
References: <k0-Cr7yor3F4OKDiZdT3lIrFiSgI_YRCR8_FphgQmlk=.4f60b60e-127d-413e-ab8f-26d6c4911142@github.com>
 <hQo3CkLhsZLq7-L4_5ui7eXaoycrENU5zyFS4JwzvVE=.a78ad8ce-8435-4009-a6c0-28fde884ac63@github.com>
Message-ID: <lor56shWc_URIU5nNJ8mgGSxsnnkxeOoI718T8UfEZY=.8cffacfb-7440-46f6-b95a-3bab27e5fe42@github.com>

On Tue, 2 Dec 2025 22:06:18 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

>> [JDK-8371046](https://bugs.openjdk.org/browse/JDK-8371046)
>> 
>> This pull request fixes two crashes (see below) and adds `InvalidationReason::RELOCATED` to better describe why an nmethod is marked not entrant during relocation.
>> 
>> ---
>> 
>> #### 1. Test Bug
>> 
>> It?s possible for an `nmethod` to be unloaded without its `_state` being explicitly set to `not_entrant`. Checking only `is_in_use()` isn?t sufficient, since the `nmethod` may already be in the process of unloading and therefore may not have a lock (as with ZGC, where `nmethods` are locked individually).
>> 
>> The fix adds an additional `is_unloading()` check in WhiteBox before acquiring the lock.
>> 
>> This issue was reproducible fairly consistently (every few runs) by executing `compiler/whitebox/StressNMethodRelocation.java` with  `-XX:+UseZGC -XX:ReservedCodeCacheSize=32m`
>> 
>> 
>> After applying this patch, the original crash stopped occurring, though a more infrequent crash was still observed.
>> 
>> ---
>> 
>> #### 2. Implementation Bug
>> 
>> `nmethod::relocate` works by copying the instructions of an `nmethod` and then adjusting the call sites to account for new PC-relative offsets.
>> 
>> Previously, this fix-up happened *after* calling `post_init()`, which registers the `nmethod` and makes it visible to the GC. This introduced a race condition where the GC might attempt to resolve a call site before it had been fixed.
>> 
>> The fix ensures that all call sites are patched **before** the `nmethod` is registered.
>> 
>> In testing, the crash previously occurred roughly 60 times in 5,000 runs (~1.2%). With this patch, no crashes were observed in the same number of runs.
>
> Chad Rakoczy 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 'origin/master' into JDK-8371046
>  - Add comment
>  - Add guarantee
>  - Clear inline caches before calling post_init
>  - Fix relocations before registering nmethod
>  - Add is_unloading() check before aquiring ic lock

@chadrako 
Your change (at version 7160f835b4f70f3626f2a7f32a021ace8d266200) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/28241#issuecomment-3608924399

From mdoerr at openjdk.org  Wed Dec  3 21:35:55 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 3 Dec 2025 21:35:55 GMT
Subject: RFR: 8371014: Dump JFR recording on CrashOnOutOfMemoryError is
 incorrectly implemented
In-Reply-To: <SiBemHHhiHk3uDElvjRK16U2SNea7P1wsptA_4z7kxA=.0746951f-41b4-46b4-8397-40603dea6298@github.com>
References: <SiBemHHhiHk3uDElvjRK16U2SNea7P1wsptA_4z7kxA=.0746951f-41b4-46b4-8397-40603dea6298@github.com>
Message-ID: <DGFl3s8vmgJ3OKXcZqge33rSgTlnGuS3DxN2_UnIX5c=.9d97c05d-bab2-4f50-9b8f-c3b73e66666a@github.com>

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

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

I think this makes sense, but should also be reviewed by JFR folks.

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

Marked as reviewed by mdoerr (Reviewer).

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

From asmehra at openjdk.org  Wed Dec  3 22:07:11 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Wed, 3 Dec 2025 22:07:11 GMT
Subject: RFR: 8373046: Method::get_c2i_unverified_entry() and
 get_c2i_no_clinit_check_entry() are missing check for abstract method
In-Reply-To: <MO4uR7w9ma1YSbPyObrys2SmWVDEXxIM9JJCLqAGmsY=.028061f6-1575-43e2-a7e8-4109ee3d9dbc@github.com>
References: <0J8wPEDgQcJlN-yVMzfGoAFO02Km2Hv3zYJobWMNmFM=.b80b95b3-58b9-4b2f-94ee-db0025d14cb4@github.com>
 <MO4uR7w9ma1YSbPyObrys2SmWVDEXxIM9JJCLqAGmsY=.028061f6-1575-43e2-a7e8-4109ee3d9dbc@github.com>
Message-ID: <HErGj_gtbadDgvANl7XcnNFBKKOwBiDQc9dg1mDpJ10=.663a417b-5219-484e-8dc2-da70aeddbc3e@github.com>

On Wed, 3 Dec 2025 20:05:02 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> This PR fixes a bug introduced by [JDK-8365501](https://bugs.openjdk.org/browse/JDK-8365501). It restores the behavior of `Method::get_c2i_unverified_entry` or `Method::get_c2i_no_clinit_check_entry` for abstract methods as it was before JDK-8365501. It was never the intention of JDK-8365501 to change the behavior.
>> I am not sure if there is any possible code flow that can result in calling `Method::get_c2i_unverified_entry` or `Method::get_c2i_no_clinit_check_entry` for abstract methods, but I think it is safe to keep the behavior of these functions as before.
>
> src/hotspot/share/oops/method.cpp line 180:
> 
>> 178: address Method::get_c2i_no_clinit_check_entry() {
>> 179:   if (is_abstract()) {
>> 180:     return nullptr;
> 
> Why it is `nullptr` instead of `SharedRuntime::get_handle_wrong_method_abstract_stub()`. Add comment.

This is not a new behavior. It was `nullptr` before JDK-8365501:

  _abstract_method_handler->set_entry_points(SharedRuntime::throw_AbstractMethodError_entry(),
                                             wrong_method_abstract,
                                             wrong_method_abstract,
                                             nullptr);

I am not sure why it was null and not `wrong_method_abstract`.
Change that sets `_c2i_no_clinit_check_entry` to null was introduced in https://github.com/openjdk/jdk/commit/242bd67c6c3bb314302502aae19e092e0820290c

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28645#discussion_r2586760646

From macarte at openjdk.org  Wed Dec  3 22:29:24 2025
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 3 Dec 2025 22:29:24 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v15]
In-Reply-To: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
Message-ID: <HiF5EwAj4DlTEOa85zqXgd2RbgbQjLNayJ6925N00ZU=.34ad1757-d497-4166-b9c7-745c8d82d228@github.com>

> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
> 
> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
> 
> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
> 
> TRUE
> FALSE
> 
> Passes tier1 on linux (x64) and windows (x64)

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

  Incorporate feedback into documentation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28010/files
  - new: https://git.openjdk.org/jdk/pull/28010/files/6cd920da..8b0e27f2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28010&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28010&range=13-14

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

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

From duke at openjdk.org  Wed Dec  3 23:05:58 2025
From: duke at openjdk.org (wb-ly878512)
Date: Wed, 3 Dec 2025 23:05:58 GMT
Subject: RFR: 8372384: Remove unused local variable in
 MacroAssembler::sha512_update_sha_state on PPC
Message-ID: <xiibUHeBKM3Y2J3CbTRBd0TE7hNhb3MkWNMdwbqji8E=.1c8a9e5c-a75e-4773-a169-5570dcdcccf6@github.com>

Issue
-----
https://bugs.openjdk.org/browse/JDK-8372384
Summary
-------
Remove an unused local variable from the PowerPC SHA-512 macro assembler implementation.
Problem
-------
`MacroAssembler::sha512_update_sha_state` in `macroAssembler_ppc_sha.cpp` defines a local constant:
  static const int total_inis = sizeof(inis)/sizeof(VectorRegister);
which is never used. This triggers static analysis warnings (e.g. ?unused variable? / ?dead code?) and slightly reduces code clarity, although it has no impact on correctness or runtime behavior.
The rest of the function relies only on `total_hs` and the implicit relation between `hs` and `inis`. The unused `total_inis` appears to be left over from an earlier version of the code or a refactoring.
Solution
--------
Remove the unused local variable `total_inis` and keep the existing logic unchanged.
Testing
-------
Trivial change. No additional testing.

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

Commit messages:
 - 8372384: Remove unused local variable in MacroAssembler::sha512_update_sha_state on PPC

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

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

From mdoerr at openjdk.org  Wed Dec  3 23:05:59 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 3 Dec 2025 23:05:59 GMT
Subject: RFR: 8372384: Remove unused local variable in
 MacroAssembler::sha512_update_sha_state on PPC
In-Reply-To: <xiibUHeBKM3Y2J3CbTRBd0TE7hNhb3MkWNMdwbqji8E=.1c8a9e5c-a75e-4773-a169-5570dcdcccf6@github.com>
References: <xiibUHeBKM3Y2J3CbTRBd0TE7hNhb3MkWNMdwbqji8E=.1c8a9e5c-a75e-4773-a169-5570dcdcccf6@github.com>
Message-ID: <HRdvPOAcEIyhHiKoDkb3sMr6Y2Jq2JX1MYaIZ3Fjj_I=.0773a198-dc77-481f-8cf7-9f286f912983@github.com>

On Mon, 24 Nov 2025 08:05:15 GMT, wb-ly878512 <duke at openjdk.org> wrote:

> Issue
> -----
> https://bugs.openjdk.org/browse/JDK-8372384
> Summary
> -------
> Remove an unused local variable from the PowerPC SHA-512 macro assembler implementation.
> Problem
> -------
> `MacroAssembler::sha512_update_sha_state` in `macroAssembler_ppc_sha.cpp` defines a local constant:
>   static const int total_inis = sizeof(inis)/sizeof(VectorRegister);
> which is never used. This triggers static analysis warnings (e.g. ?unused variable? / ?dead code?) and slightly reduces code clarity, although it has no impact on correctness or runtime behavior.
> The rest of the function relies only on `total_hs` and the implicit relation between `hs` and `inis`. The unused `total_inis` appears to be left over from an earlier version of the code or a refactoring.
> Solution
> --------
> Remove the unused local variable `total_inis` and keep the existing logic unchanged.
> Testing
> -------
> Trivial change. No additional testing.

Looks good and trivial.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28472#pullrequestreview-3505372051

From duke at openjdk.org  Wed Dec  3 23:05:59 2025
From: duke at openjdk.org (wb-ly878512)
Date: Wed, 3 Dec 2025 23:05:59 GMT
Subject: RFR: 8372384: Remove unused local variable in
 MacroAssembler::sha512_update_sha_state on PPC
In-Reply-To: <xiibUHeBKM3Y2J3CbTRBd0TE7hNhb3MkWNMdwbqji8E=.1c8a9e5c-a75e-4773-a169-5570dcdcccf6@github.com>
References: <xiibUHeBKM3Y2J3CbTRBd0TE7hNhb3MkWNMdwbqji8E=.1c8a9e5c-a75e-4773-a169-5570dcdcccf6@github.com>
Message-ID: <ascStBcCcRc99t7zR-v8SJ-DJ7rgDbJ3mEdTLH5behA=.1c0a4481-0ef0-46be-8a02-d9509a9ae62e@github.com>

On Mon, 24 Nov 2025 08:05:15 GMT, wb-ly878512 <duke at openjdk.org> wrote:

> Issue
> -----
> https://bugs.openjdk.org/browse/JDK-8372384
> Summary
> -------
> Remove an unused local variable from the PowerPC SHA-512 macro assembler implementation.
> Problem
> -------
> `MacroAssembler::sha512_update_sha_state` in `macroAssembler_ppc_sha.cpp` defines a local constant:
>   static const int total_inis = sizeof(inis)/sizeof(VectorRegister);
> which is never used. This triggers static analysis warnings (e.g. ?unused variable? / ?dead code?) and slightly reduces code clarity, although it has no impact on correctness or runtime behavior.
> The rest of the function relies only on `total_hs` and the implicit relation between `hs` and `inis`. The unused `total_inis` appears to be left over from an earlier version of the code or a refactoring.
> Solution
> --------
> Remove the unused local variable `total_inis` and keep the existing logic unchanged.
> Testing
> -------
> Trivial change. No additional testing.

The contribution is made on behalf of Alibaba.

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

PR Comment: https://git.openjdk.org/jdk/pull/28472#issuecomment-3569637678

From eastigeevich at openjdk.org  Wed Dec  3 23:36:03 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Wed, 3 Dec 2025 23:36:03 GMT
Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact
 on GCs and JIT performance [v13]
In-Reply-To: <Kl5e4lLy09In3ii23YLueZVqzzzkBkZJLGAJb2k7Aio=.4347ba54-eb6b-4a9f-81e8-6db06a03824f@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
 <rtneArX_lMKv-UqOQNXv8DT_n8pY4UNn7nEE4FpKT4k=.ca641bc2-9d9a-4e0b-a329-da375913f5db@github.com>
 <Kl5e4lLy09In3ii23YLueZVqzzzkBkZJLGAJb2k7Aio=.4347ba54-eb6b-4a9f-81e8-6db06a03824f@github.com>
Message-ID: <z1ruHGM9HHIcv4BSrkuS_RTo64sLga_AjXBnk6jOriw=.0f2f95aa-869d-4183-92f6-83f3415a0e02@github.com>

On Wed, 3 Dec 2025 15:54:24 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Honestly, this looks fragile? We can go into nmethods patching for some other reason, not for patching oops.

For GCs on ARM64, I found only patching `nmethod::fix_oop_relocations` and patching ZGC barriers. This may be because `mustIterateImmediateOopsInCode` return false on ARM64. We will need to add support of instructions modified through `OopClosure::do_oop`.

> Is there a substantial loss is doing icache invalidation without checking for the existence of interesting oops? Do you have an idea how many methods this filters?

https://github.com/openjdk/jdk/pull/28328#issuecomment-3558673810

Axel (@xmas92) saw some SpecJVM regressions. I think they might be caused by the increased number of icache invalidation. We had not patched methods, no icache invalidation, before this PR and started always-icache invalidation after this PR. I will be checking SpecJVM, SpecJBB and other benchmarks (dacapo, renaissance).

I might check if the following approach does not have much overhead:
- In `nmethod::fix_oop_relocations`

ICacheInvalidationContext icic(UseDeferredICacheInvalidation : ICacheInvalidation::DEFERRED ? ICacheInvalidation::IMMEDIATE);
bool patching_code = false;
while (iter.next()) {
...
patching_code = reloc->fix_oop_relocation();
...
patching_code = reloc->fix_metadata_relocation();
}
If (icic.mode() ==  ICacheInvalidation::DEFERRED && !patching_code) {
  icic.set_mode(ICacheInvalidation::NOT_NEEDED);
}


If it works, it will reduce amount of changes.

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

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

From liach at openjdk.org  Wed Dec  3 23:44:01 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 3 Dec 2025 23:44:01 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v6]
In-Reply-To: <OChEencVyX1xRYDW-2u0O8R8fO6WS8IbXAbP47uALcY=.c5158037-ff46-4b6d-be4d-ec68c756cb3b@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <qmC_8KrBI4dTudSWMXPzMKMAwE24-kEfuEtSKaaVs4M=.b4fbf7c3-7fa4-485e-a0df-265fe4dbfa03@github.com>
 <OChEencVyX1xRYDW-2u0O8R8fO6WS8IbXAbP47uALcY=.c5158037-ff46-4b6d-be4d-ec68c756cb3b@github.com>
Message-ID: <pbMDRrV6ly1k6hJzTYDGzFca-OuJbJJoz-pI0QNVckY=.6045281c-edbc-40c8-b418-74ccea04b2b6@github.com>

On Wed, 3 Dec 2025 19:37:25 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Test from Jorn
>>  - Copyright years
>
> src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2036:
> 
>> 2034:         // from two writes (they must not be tearable)
>> 2035:         private record Adaption(VarHandle vh, MethodHandle mh) {}
>> 2036:         private @Stable Adaption adaption;
> 
> Is a soft reference needed here? The situation looks similar to `MH.asTypeSoftCache`. It can keep some classes referred by `vh` alive for unnecessarily long.

I don't think we can use a SoftReference here if we need to achieve constant folding.

Looking at inline_reference_get0, I think we might introduce another field property to trust a reference (potentially in an array) if both that reference and the referent within the reference is non-null.  I think that belongs to a separate RFE. What do you think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2586946357

From duke at openjdk.org  Wed Dec  3 23:44:12 2025
From: duke at openjdk.org (Vic Wang)
Date: Wed, 3 Dec 2025 23:44:12 GMT
Subject: RFR: 8367478: Improve UseAVX setting and add cpu descriptions for
 zhaoxin processors
Message-ID: <LBWpAyFqe8AT4WYw6cSWlvouAtJQ2FnsWudpyucG4ic=.4be84eb3-fba2-4954-b024-9803136f80b2@github.com>

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

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

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

From zsong at openjdk.org  Wed Dec  3 23:44:12 2025
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 3 Dec 2025 23:44:12 GMT
Subject: RFR: 8367478: Improve UseAVX setting and add cpu descriptions for
 zhaoxin processors
In-Reply-To: <LBWpAyFqe8AT4WYw6cSWlvouAtJQ2FnsWudpyucG4ic=.4be84eb3-fba2-4954-b024-9803136f80b2@github.com>
References: <LBWpAyFqe8AT4WYw6cSWlvouAtJQ2FnsWudpyucG4ic=.4be84eb3-fba2-4954-b024-9803136f80b2@github.com>
Message-ID: <gAQy_3HD3X1XGIM_q95l3W1ZnmtdMbuaDxWqZHfT89M=.dbb294dc-2288-41b1-8444-12746a85ca0f@github.com>

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

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

Hi @Double-Minds-JV ,
Could you please issue the command "/covered" one more time? Please don't add any text after "/covered", thanks.

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

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

From eastigeevich at openjdk.org  Wed Dec  3 23:58:04 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Wed, 3 Dec 2025 23:58:04 GMT
Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact
 on GCs and JIT performance [v13]
In-Reply-To: <rtneArX_lMKv-UqOQNXv8DT_n8pY4UNn7nEE4FpKT4k=.ca641bc2-9d9a-4e0b-a329-da375913f5db@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
 <rtneArX_lMKv-UqOQNXv8DT_n8pY4UNn7nEE4FpKT4k=.ca641bc2-9d9a-4e0b-a329-da375913f5db@github.com>
Message-ID: <g9ktblHsa6_ShZqjSfHQgts0Ap9y7qRPr5XMao0A-LU=.170d25dc-f979-479a-8b33-47a014bc7a42@github.com>

On Wed, 3 Dec 2025 15:42:38 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> Arm Neoverse N1 erratum 1542419: "The core might fetch a stale instruction from memory which violates the ordering of instruction fetches". It is fixed in Neoverse N1 r4p1.
>>  
>> Neoverse-N1 implementations mitigate erratum 1542419 with a workaround:
>> - Disable coherent icache.
>> - Trap IC IVAU instructions.
>> - Execute:
>>    - `tlbi vae3is, xzr`
>>    - `dsb sy`
>>  
>>  `tlbi vae3is, xzr` invalidates translations for all address spaces (global for address).  It waits for all memory accesses using in-scope old translation information to complete before it is considered complete.
>>  
>> As this workaround has significant overhead, Arm Neoverse N1 (MP050) Software Developer Errata Notice version 29.0 suggests:
>> 
>> "Since one TLB inner-shareable invalidation is enough to avoid this erratum, the number of injected TLB invalidations should be minimized in the trap handler to mitigate the performance impact due to this workaround."
>> 
>> This PR introduces a mechanism to defer instruction cache (ICache) invalidation for AArch64 to address the Arm Neoverse N1 erratum 1542419, which causes significant performance overhead if ICache invalidation is performed too frequently. The implementation includes detection of affected Neoverse N1 CPUs and automatic enabling of the workaround for relevant Neoverse N1 revisions.
>> 
>> Changes include:
>> 
>> * Added a new diagnostic JVM flag `NeoverseN1Errata1542419` to enable or disable the workaround for the erratum. The flag is automatically enabled for Neoverse N1 CPUs prior to r4p1, as detected during VM initialization.
>> * Introduced the `ICacheInvalidationContext` class to manage deferred ICache invalidation, with platform-specific logic for AArch64. This context is used to batch ICache invalidations, reducing performance impact. As the address for icache invalidation is not relevant, we use the nmethod's code start address.
>> * Provided a default (no-op) implementation for `ICacheInvalidationContext` on platforms where the workaround is not needed, ensuring portability and minimal impact on other architectures.
>> * Modified barrier patching and relocation logic (`ZBarrierSetAssembler`, `ZNMethod`, `RelocIterator`, and related code) to accept a `defer_icache_invalidation` parameter, allowing ICache invalidation to be deferred and later performed in bulk.
>> 
>> Benchmarking results: Neoverse-N1 r3p1 (Graviton 2)
>> 
>> - Baseline
>> 
>> $ taskset -c 0-3 java -Xbootclasspath/a:./wb.jar -XX:+UnlockDiagnosticVMOptions -XX:-NeoverseN1...
>
> 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

src/hotspot/os_cpu/linux_aarch64/icache_linux_aarch64.hpp line 114:

> 112:   _code = nullptr;
> 113:   _size = 0;
> 114:   _mode = ICacheInvalidation::NOT_NEEDED;

This should be inside IF.

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

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

From dlong at openjdk.org  Wed Dec  3 23:57:57 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 3 Dec 2025 23:57:57 GMT
Subject: RFR: 8373046: Method::get_c2i_unverified_entry() and
 get_c2i_no_clinit_check_entry() are missing check for abstract method
In-Reply-To: <0J8wPEDgQcJlN-yVMzfGoAFO02Km2Hv3zYJobWMNmFM=.b80b95b3-58b9-4b2f-94ee-db0025d14cb4@github.com>
References: <0J8wPEDgQcJlN-yVMzfGoAFO02Km2Hv3zYJobWMNmFM=.b80b95b3-58b9-4b2f-94ee-db0025d14cb4@github.com>
Message-ID: <ZmtoUAyBe-SiTPGbRsxzsUrbuRdjThfJQ2wJus1ntPQ=.f975d319-6a49-43c4-b24d-82ea0c3afe89@github.com>

On Wed, 3 Dec 2025 19:45:12 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

> This PR fixes a bug introduced by [JDK-8365501](https://bugs.openjdk.org/browse/JDK-8365501). It restores the behavior of `Method::get_c2i_unverified_entry` or `Method::get_c2i_no_clinit_check_entry` for abstract methods as it was before JDK-8365501. It was never the intention of JDK-8365501 to change the behavior.
> I am not sure if there is any possible code flow that can result in calling `Method::get_c2i_unverified_entry` or `Method::get_c2i_no_clinit_check_entry` for abstract methods, but I think it is safe to keep the behavior of these functions as before.

It would be nice to have a test for this.  Currently, it looks like calling get_c2i_no_clinit_check_entry with an abstract method is impossible.  The same might be true for get_c2i_unverified_entry.

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

PR Comment: https://git.openjdk.org/jdk/pull/28645#issuecomment-3609322745

From duke at openjdk.org  Thu Dec  4 00:25:05 2025
From: duke at openjdk.org (Chad Rakoczy)
Date: Thu, 4 Dec 2025 00:25:05 GMT
Subject: Integrated: 8371046: Segfault in
 compiler/whitebox/StressNMethodRelocation.java with -XX:+UseZGC
In-Reply-To: <k0-Cr7yor3F4OKDiZdT3lIrFiSgI_YRCR8_FphgQmlk=.4f60b60e-127d-413e-ab8f-26d6c4911142@github.com>
References: <k0-Cr7yor3F4OKDiZdT3lIrFiSgI_YRCR8_FphgQmlk=.4f60b60e-127d-413e-ab8f-26d6c4911142@github.com>
Message-ID: <VDVsZUFA_mO8FR8szdg-k5Yx1bPkkOkFIfBbmbywbCA=.c7b46cd6-0224-43a9-b955-08cbf5320d76@github.com>

On Tue, 11 Nov 2025 17:32:22 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

> [JDK-8371046](https://bugs.openjdk.org/browse/JDK-8371046)
> 
> This pull request fixes two crashes (see below) and adds `InvalidationReason::RELOCATED` to better describe why an nmethod is marked not entrant during relocation.
> 
> ---
> 
> #### 1. Test Bug
> 
> It?s possible for an `nmethod` to be unloaded without its `_state` being explicitly set to `not_entrant`. Checking only `is_in_use()` isn?t sufficient, since the `nmethod` may already be in the process of unloading and therefore may not have a lock (as with ZGC, where `nmethods` are locked individually).
> 
> The fix adds an additional `is_unloading()` check in WhiteBox before acquiring the lock.
> 
> This issue was reproducible fairly consistently (every few runs) by executing `compiler/whitebox/StressNMethodRelocation.java` with  `-XX:+UseZGC -XX:ReservedCodeCacheSize=32m`
> 
> 
> After applying this patch, the original crash stopped occurring, though a more infrequent crash was still observed.
> 
> ---
> 
> #### 2. Implementation Bug
> 
> `nmethod::relocate` works by copying the instructions of an `nmethod` and then adjusting the call sites to account for new PC-relative offsets.
> 
> Previously, this fix-up happened *after* calling `post_init()`, which registers the `nmethod` and makes it visible to the GC. This introduced a race condition where the GC might attempt to resolve a call site before it had been fixed.
> 
> The fix ensures that all call sites are patched **before** the `nmethod` is registered.
> 
> In testing, the crash previously occurred roughly 60 times in 5,000 runs (~1.2%). With this patch, no crashes were observed in the same number of runs.

This pull request has now been integrated.

Changeset: 48563446
Author:    Chad Rakoczy <chadrako at amazon.com>
Committer: Vladimir Kozlov <kvn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4856344668042fcbc4d15966519d27fb0a4f509f
Stats:     64 lines in 7 files changed: 38 ins; 21 del; 5 mod

8371046: Segfault in compiler/whitebox/StressNMethodRelocation.java with -XX:+UseZGC

Reviewed-by: kvn, eastigeevich

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

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

From kvn at openjdk.org  Thu Dec  4 00:43:02 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 4 Dec 2025 00:43:02 GMT
Subject: RFR: 8373046: Method::get_c2i_unverified_entry() and
 get_c2i_no_clinit_check_entry() are missing check for abstract method
In-Reply-To: <ZmtoUAyBe-SiTPGbRsxzsUrbuRdjThfJQ2wJus1ntPQ=.f975d319-6a49-43c4-b24d-82ea0c3afe89@github.com>
References: <0J8wPEDgQcJlN-yVMzfGoAFO02Km2Hv3zYJobWMNmFM=.b80b95b3-58b9-4b2f-94ee-db0025d14cb4@github.com>
 <ZmtoUAyBe-SiTPGbRsxzsUrbuRdjThfJQ2wJus1ntPQ=.f975d319-6a49-43c4-b24d-82ea0c3afe89@github.com>
Message-ID: <gujJJfdVDI_N3cCiXnVqGGKuDMEW88PdWQUcjUptMo0=.9f3b703e-dc6b-4732-a4db-72691b31047f@github.com>

On Wed, 3 Dec 2025 23:55:22 GMT, Dean Long <dlong at openjdk.org> wrote:

> It would be nice to have a test for this. Currently, it looks like calling get_c2i_no_clinit_check_entry with an abstract method is impossible. The same might be true for get_c2i_unverified_entry.

It is good idea. Let's do it as separate RFE.  Currently we restored pre-existing behavior. Let's push it before RDP1 tomorrow.

Let me do quick testing.

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

PR Comment: https://git.openjdk.org/jdk/pull/28645#issuecomment-3609415533

From kvn at openjdk.org  Thu Dec  4 00:43:00 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 4 Dec 2025 00:43:00 GMT
Subject: RFR: 8373046: Method::get_c2i_unverified_entry() and
 get_c2i_no_clinit_check_entry() are missing check for abstract method
In-Reply-To: <0J8wPEDgQcJlN-yVMzfGoAFO02Km2Hv3zYJobWMNmFM=.b80b95b3-58b9-4b2f-94ee-db0025d14cb4@github.com>
References: <0J8wPEDgQcJlN-yVMzfGoAFO02Km2Hv3zYJobWMNmFM=.b80b95b3-58b9-4b2f-94ee-db0025d14cb4@github.com>
Message-ID: <FdqiRZZOSCkfnjoLaPsLAuQCirn37htexuvN5AvprMM=.97a2b469-dd0d-46ed-97fd-5045171d0081@github.com>

On Wed, 3 Dec 2025 19:45:12 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

> This PR fixes a bug introduced by [JDK-8365501](https://bugs.openjdk.org/browse/JDK-8365501). It restores the behavior of `Method::get_c2i_unverified_entry` or `Method::get_c2i_no_clinit_check_entry` for abstract methods as it was before JDK-8365501. It was never the intention of JDK-8365501 to change the behavior.
> I am not sure if there is any possible code flow that can result in calling `Method::get_c2i_unverified_entry` or `Method::get_c2i_no_clinit_check_entry` for abstract methods, but I think it is safe to keep the behavior of these functions as before.

Marked as reviewed by kvn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28645#pullrequestreview-3537428675

From kvn at openjdk.org  Thu Dec  4 00:43:04 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 4 Dec 2025 00:43:04 GMT
Subject: RFR: 8373046: Method::get_c2i_unverified_entry() and
 get_c2i_no_clinit_check_entry() are missing check for abstract method
In-Reply-To: <HErGj_gtbadDgvANl7XcnNFBKKOwBiDQc9dg1mDpJ10=.663a417b-5219-484e-8dc2-da70aeddbc3e@github.com>
References: <0J8wPEDgQcJlN-yVMzfGoAFO02Km2Hv3zYJobWMNmFM=.b80b95b3-58b9-4b2f-94ee-db0025d14cb4@github.com>
 <MO4uR7w9ma1YSbPyObrys2SmWVDEXxIM9JJCLqAGmsY=.028061f6-1575-43e2-a7e8-4109ee3d9dbc@github.com>
 <HErGj_gtbadDgvANl7XcnNFBKKOwBiDQc9dg1mDpJ10=.663a417b-5219-484e-8dc2-da70aeddbc3e@github.com>
Message-ID: <1F-iP71KKt3Q3ll-ayQGpE-NbEBPpkm0L5nQLC-bSDQ=.15202299-17c7-432e-b893-1b0b2f8aa0ca@github.com>

On Wed, 3 Dec 2025 22:04:00 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> src/hotspot/share/oops/method.cpp line 180:
>> 
>>> 178: address Method::get_c2i_no_clinit_check_entry() {
>>> 179:   if (is_abstract()) {
>>> 180:     return nullptr;
>> 
>> Why it is `nullptr` instead of `SharedRuntime::get_handle_wrong_method_abstract_stub()`. Add comment.
>
> This is not a new behavior. It was `nullptr` before JDK-8365501:
> 
>   _abstract_method_handler->set_entry_points(SharedRuntime::throw_AbstractMethodError_entry(),
>                                              wrong_method_abstract,
>                                              wrong_method_abstract,
>                                              nullptr);
> 
> I am not sure why it was null and not `wrong_method_abstract`.
> Change that sets `_c2i_no_clinit_check_entry` to null was introduced in https://github.com/openjdk/jdk/commit/242bd67c6c3bb314302502aae19e092e0820290c

Thank you for checking this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28645#discussion_r2587026094

From dlong at openjdk.org  Thu Dec  4 00:46:59 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 4 Dec 2025 00:46:59 GMT
Subject: RFR: 8347396: Efficient TypeFunc creations [v3]
In-Reply-To: <da-a4Id_azWgrrTjDQEeYR6rm4D2l5jZAHIMx9x4v4w=.38b3a577-a776-49c4-8afb-27c684c126ad@github.com>
References: <VQs3SMtk1y6xTi8nCvTeWsTFfCQlTJtDdCGnfWQmRmw=.f3b33ba1-3efe-477b-b6d2-b43faae9ee2b@github.com>
 <da-a4Id_azWgrrTjDQEeYR6rm4D2l5jZAHIMx9x4v4w=.38b3a577-a776-49c4-8afb-27c684c126ad@github.com>
Message-ID: <wg7GBYkGVNry-5sjDWAxxWcgsL2y8NWbxJBobYYCz98=.3814f3ee-e517-4485-a46a-27e46660e081@github.com>

On Wed, 3 Dec 2025 08:37:02 GMT, Harshit470250 <duke at openjdk.org> 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 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

How about leaving make_clone_type_Type() in barrierSetC2.cpp?  I don't see a need to move it into runtime.cpp.

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

PR Comment: https://git.openjdk.org/jdk/pull/27279#issuecomment-3609423313

From VicWang at zhaoxin.com  Thu Dec  4 01:44:07 2025
From: VicWang at zhaoxin.com (Vic Wang(BJ-RD))
Date: Thu, 4 Dec 2025 01:44:07 +0000
Subject: =?utf-8?B?5Zue5aSNOiBSRlI6IDgzNjc0Nzg6IEltcHJvdmUgVXNlQVZYIHNldHRpbmcg?=
 =?utf-8?Q?and_add_cpu_descriptions_for_zhaoxin_processors?=
In-Reply-To: <gAQy_3HD3X1XGIM_q95l3W1ZnmtdMbuaDxWqZHfT89M=.dbb294dc-2288-41b1-8444-12746a85ca0f@github.com>
References: <LBWpAyFqe8AT4WYw6cSWlvouAtJQ2FnsWudpyucG4ic=.4be84eb3-fba2-4954-b024-9803136f80b2@github.com>
 <gAQy_3HD3X1XGIM_q95l3W1ZnmtdMbuaDxWqZHfT89M=.dbb294dc-2288-41b1-8444-12746a85ca0f@github.com>
Message-ID: <117fd5eae1bb4020bce9c5c9f4368b8e@zhaoxin.com>


>-----????-----
>???: hotspot-dev <hotspot-dev-retn at openjdk.org> ?? Zhao Song
>????: 2025?12?4? 7:44
>???: hotspot-dev at openjdk.org
>??: Re: RFR: 8367478: Improve UseAVX setting and add cpu descriptions for zhaoxin processors
>
>On Fri, 12 Sep 2025 01:49:23 GMT, Vic Wang <duke at openjdk.org> wrote:
>
>> Here is the patch that improving the UseAVX setting and add cpu descriptions for zhaoxin processors.
>> Can you help to review this patch?
>> Thank you!
>
>Hi @Double-Minds-JV ,
>Could you please issue the command "/covered" one more time? Please don't add any text after "/covered", thanks.
>-------------

Hi Song,
I've already issued the '/covered' again, thanks.

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


?????
?????????????????????????????????????????????????????
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 liach at openjdk.org  Thu Dec  4 01:48:31 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 4 Dec 2025 01:48:31 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v7]
In-Reply-To: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
Message-ID: <7ayMTZ4nXMyB1SXNRcYGjdxidNHDcAUNv_8fQZDUaPI=.a558d3a2-1d3e-4b45-8ba7-393c55a52785@github.com>

> 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:

  Revert void special case removal due to C2 shortage causing TestZGCBarrierElision::testAtomicThenAtomicAnotherField failure

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28585/files
  - new: https://git.openjdk.org/jdk/pull/28585/files/ff7b3629..8200fb28

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

  Stats: 23 lines in 1 file changed: 20 ins; 0 del; 3 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 asmehra at openjdk.org  Thu Dec  4 01:50:58 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Thu, 4 Dec 2025 01:50:58 GMT
Subject: RFR: 8373046: Method::get_c2i_unverified_entry() and
 get_c2i_no_clinit_check_entry() are missing check for abstract method
In-Reply-To: <gujJJfdVDI_N3cCiXnVqGGKuDMEW88PdWQUcjUptMo0=.9f3b703e-dc6b-4732-a4db-72691b31047f@github.com>
References: <0J8wPEDgQcJlN-yVMzfGoAFO02Km2Hv3zYJobWMNmFM=.b80b95b3-58b9-4b2f-94ee-db0025d14cb4@github.com>
 <ZmtoUAyBe-SiTPGbRsxzsUrbuRdjThfJQ2wJus1ntPQ=.f975d319-6a49-43c4-b24d-82ea0c3afe89@github.com>
 <gujJJfdVDI_N3cCiXnVqGGKuDMEW88PdWQUcjUptMo0=.9f3b703e-dc6b-4732-a4db-72691b31047f@github.com>
Message-ID: <_BNHeZKa-5rb1e-IUqtecuycfSV7JnGuiBA67czhNi0=.88dc7df5-05cc-4c79-b0a9-018a252ef851@github.com>

On Thu, 4 Dec 2025 00:39:59 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Let me do quick testing.

I will for the testing to complete before integrating it.

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

PR Comment: https://git.openjdk.org/jdk/pull/28645#issuecomment-3609611638

From vlivanov at openjdk.org  Thu Dec  4 01:58:56 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 4 Dec 2025 01:58:56 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v6]
In-Reply-To: <pbMDRrV6ly1k6hJzTYDGzFca-OuJbJJoz-pI0QNVckY=.6045281c-edbc-40c8-b418-74ccea04b2b6@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <qmC_8KrBI4dTudSWMXPzMKMAwE24-kEfuEtSKaaVs4M=.b4fbf7c3-7fa4-485e-a0df-265fe4dbfa03@github.com>
 <OChEencVyX1xRYDW-2u0O8R8fO6WS8IbXAbP47uALcY=.c5158037-ff46-4b6d-be4d-ec68c756cb3b@github.com>
 <pbMDRrV6ly1k6hJzTYDGzFca-OuJbJJoz-pI0QNVckY=.6045281c-edbc-40c8-b418-74ccea04b2b6@github.com>
Message-ID: <8tu3HIArCw2cdoYR2SjI0b-TWYQxQLKkjQgucJEj8D4=.10946ec2-4958-48df-add4-b29d11c09448@github.com>

On Wed, 3 Dec 2025 23:41:01 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2036:
>> 
>>> 2034:         // from two writes (they must not be tearable)
>>> 2035:         private record Adaption(VarHandle vh, MethodHandle mh) {}
>>> 2036:         private @Stable Adaption adaption;
>> 
>> Is a soft reference needed here? The situation looks similar to `MH.asTypeSoftCache`. It can keep some classes referred by `vh` alive for unnecessarily long.
>
> I don't think we can use a SoftReference here if we need to achieve constant folding.
> 
> Looking at inline_reference_get0, I think we might introduce another field property to trust a reference (potentially in an array) if both that reference and the referent within the reference is non-null.  I think that belongs to a separate RFE. What do you think?

Then it makes sense to limit the caching to safe cases only for now. Otherwise, it would functionally regress due to a possible memory leak.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2587156042

From vlivanov at openjdk.org  Thu Dec  4 02:02:57 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 4 Dec 2025 02:02:57 GMT
Subject: RFR: 8373046: Method::get_c2i_unverified_entry() and
 get_c2i_no_clinit_check_entry() are missing check for abstract method
In-Reply-To: <0J8wPEDgQcJlN-yVMzfGoAFO02Km2Hv3zYJobWMNmFM=.b80b95b3-58b9-4b2f-94ee-db0025d14cb4@github.com>
References: <0J8wPEDgQcJlN-yVMzfGoAFO02Km2Hv3zYJobWMNmFM=.b80b95b3-58b9-4b2f-94ee-db0025d14cb4@github.com>
Message-ID: <RTPAaE4fPk-TfCT7ROyaTrw9MtlPZrNI69cscA7NA7g=.ded95320-2c58-442e-a94c-203f99b84eab@github.com>

On Wed, 3 Dec 2025 19:45:12 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

> This PR fixes a bug introduced by [JDK-8365501](https://bugs.openjdk.org/browse/JDK-8365501). It restores the behavior of `Method::get_c2i_unverified_entry` or `Method::get_c2i_no_clinit_check_entry` for abstract methods as it was before JDK-8365501. It was never the intention of JDK-8365501 to change the behavior.
> I am not sure if there is any possible code flow that can result in calling `Method::get_c2i_unverified_entry` or `Method::get_c2i_no_clinit_check_entry` for abstract methods, but I think it is safe to keep the behavior of these functions as before.

Looks good.

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

Marked as reviewed by vlivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28645#pullrequestreview-3537586732

From sparasa at openjdk.org  Thu Dec  4 02:44:51 2025
From: sparasa at openjdk.org (Srinivas Vamsi Parasa)
Date: Thu, 4 Dec 2025 02:44:51 GMT
Subject: RFR: 8349452: Fix performance regression for Arrays.fill() with
 AVX512 [v10]
In-Reply-To: <vR7Pzk96gG0PlTn5P5U1qlqyCvISC0dCMxUXyWHfy2g=.e58b097d-790c-4725-8ac8-7e8f2c94ac50@github.com>
References: <vR7Pzk96gG0PlTn5P5U1qlqyCvISC0dCMxUXyWHfy2g=.e58b097d-790c-4725-8ac8-7e8f2c94ac50@github.com>
Message-ID: <N-7XCtb2GXLv10t2lo8jkzoMbI-f0LAJ5gWNMQC4E5c=.098a9b7a-16a8-49f8-a327-9d0490c66e45@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.185
> 2 | 0.46 | 0.16 | 0.195
> 3 | 0.46 | 0.176 | 0.199
> 4 | 0.46 | 0.244 | 0.207
> 5 | 0.46 | 0.29 | 0.32
> 10 | 0.46 | 0.58 | 0.303
> 15 | 0.46 | 0.42 | 0.271
> 16 | 0.46 | 0.46 | 0.32
> 17 | 0.21 | 0.5 | 0.299
> 20 | 0.21 | 0.37 | 0.299
> 25 | 0.21 | 0.59 | 0.282
> 31 | 0.21 | 0.53 | 0.273
> 32 | 0.21 | 0.58 | 0.199
> 35 | 0.5 | 0.77 | 0.259
> 40 | 0.5 | 0.61 | 0.33
> 45 | 0.5 | 0.52 | 0.281
> 48 | 0.5 | 0.66 | 0.32
> 49 | 0.22 | 0.69 | 0.3
> 50 | 0.22 | 0.78 | 0.3
> 55 | 0.22 | 0.67 | 0.292
> 60 | 0.22 | 0.67 | 0.3293
> 64 | 0.22 | 0.82 | 0.23
> 70 | 0.51 | 1.1 | 0.34
> 80 | 0.49 | 0.89 | 0.365
> 90 | 0.225 | 0.68 | 0.33
> 100 | 0.54 | 1.09 | 0.347
> 110 | 0.6 | 0.98 | 0.36
> 120 | 0.26 | 0.75 | 0.386
> 128 | 0.266 | 1.1 | 0.289

Srinivas Vamsi Parasa 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:

 - Fix for failing tests; keep dest pointer unchanged
 - Merge branch 'master' of https://git.openjdk.java.net/jdk into fill_array
 - Merge branch 'master' of https://git.openjdk.java.net/jdk into fill_array
 - fix missing array length updates for size=1
 - revert to jccb in one place
 - remove all masked stores altogether
 - fastpath for size <= 4 bytes
 - Merge branch 'master' of https://git.openjdk.java.net/jdk into fill_array
 - undo jccb to jcc change as needed
 - refactor code to use fill32_tail at the end of the stub
 - ... and 2 more: https://git.openjdk.org/jdk/compare/eda35725...f54dfd78

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28442/files
  - new: https://git.openjdk.org/jdk/pull/28442/files/d3724b88..f54dfd78

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28442&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28442&range=08-09

  Stats: 20479 lines in 460 files changed: 11197 ins; 6643 del; 2639 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 kvn at openjdk.org  Thu Dec  4 04:44:56 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 4 Dec 2025 04:44:56 GMT
Subject: RFR: 8373046: Method::get_c2i_unverified_entry() and
 get_c2i_no_clinit_check_entry() are missing check for abstract method
In-Reply-To: <0J8wPEDgQcJlN-yVMzfGoAFO02Km2Hv3zYJobWMNmFM=.b80b95b3-58b9-4b2f-94ee-db0025d14cb4@github.com>
References: <0J8wPEDgQcJlN-yVMzfGoAFO02Km2Hv3zYJobWMNmFM=.b80b95b3-58b9-4b2f-94ee-db0025d14cb4@github.com>
Message-ID: <XkmleVi-eX5zZmAitc1H3iiTgTJJMtwbWE_qoMdWHUs=.f18029a8-21e3-4aa0-82d3-e11fe7a9b695@github.com>

On Wed, 3 Dec 2025 19:45:12 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

> This PR fixes a bug introduced by [JDK-8365501](https://bugs.openjdk.org/browse/JDK-8365501). It restores the behavior of `Method::get_c2i_unverified_entry` or `Method::get_c2i_no_clinit_check_entry` for abstract methods as it was before JDK-8365501. It was never the intention of JDK-8365501 to change the behavior.
> I am not sure if there is any possible code flow that can result in calling `Method::get_c2i_unverified_entry` or `Method::get_c2i_no_clinit_check_entry` for abstract methods, but I think it is safe to keep the behavior of these functions as before.

My testing passed on most platforms (MacOs-aarch64 still running but I think it is fine).

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

PR Comment: https://git.openjdk.org/jdk/pull/28645#issuecomment-3610093712

From kvn at openjdk.org  Thu Dec  4 04:44:58 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 4 Dec 2025 04:44:58 GMT
Subject: RFR: 8373046: Method::get_c2i_unverified_entry() and
 get_c2i_no_clinit_check_entry() are missing check for abstract method
In-Reply-To: <_BNHeZKa-5rb1e-IUqtecuycfSV7JnGuiBA67czhNi0=.88dc7df5-05cc-4c79-b0a9-018a252ef851@github.com>
References: <0J8wPEDgQcJlN-yVMzfGoAFO02Km2Hv3zYJobWMNmFM=.b80b95b3-58b9-4b2f-94ee-db0025d14cb4@github.com>
 <ZmtoUAyBe-SiTPGbRsxzsUrbuRdjThfJQ2wJus1ntPQ=.f975d319-6a49-43c4-b24d-82ea0c3afe89@github.com>
 <gujJJfdVDI_N3cCiXnVqGGKuDMEW88PdWQUcjUptMo0=.9f3b703e-dc6b-4732-a4db-72691b31047f@github.com>
 <_BNHeZKa-5rb1e-IUqtecuycfSV7JnGuiBA67czhNi0=.88dc7df5-05cc-4c79-b0a9-018a252ef851@github.com>
Message-ID: <2KZKDCK_OP0P_Ac_8OgsCxaoL7lCVVgr_8Bv2J7fp4w=.d239185a-eb34-4be8-a13e-dd4a35da6885@github.com>

On Thu, 4 Dec 2025 01:48:42 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>>> It would be nice to have a test for this. Currently, it looks like calling get_c2i_no_clinit_check_entry with an abstract method is impossible. The same might be true for get_c2i_unverified_entry.
>> 
>> It is good idea. Let's do it as separate RFE.  Currently we restored pre-existing behavior. Let's push it before RDP1 tomorrow.
>> 
>> Let me do quick testing.
>
>> Let me do quick testing.
> 
> I will wait for the testing to complete before integrating it.

@ashu-mehra you can integrate it when you are ready

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

PR Comment: https://git.openjdk.org/jdk/pull/28645#issuecomment-3610094818

From asmehra at openjdk.org  Thu Dec  4 05:06:09 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Thu, 4 Dec 2025 05:06:09 GMT
Subject: RFR: 8373046: Method::get_c2i_unverified_entry() and
 get_c2i_no_clinit_check_entry() are missing check for abstract method
In-Reply-To: <2KZKDCK_OP0P_Ac_8OgsCxaoL7lCVVgr_8Bv2J7fp4w=.d239185a-eb34-4be8-a13e-dd4a35da6885@github.com>
References: <0J8wPEDgQcJlN-yVMzfGoAFO02Km2Hv3zYJobWMNmFM=.b80b95b3-58b9-4b2f-94ee-db0025d14cb4@github.com>
 <ZmtoUAyBe-SiTPGbRsxzsUrbuRdjThfJQ2wJus1ntPQ=.f975d319-6a49-43c4-b24d-82ea0c3afe89@github.com>
 <gujJJfdVDI_N3cCiXnVqGGKuDMEW88PdWQUcjUptMo0=.9f3b703e-dc6b-4732-a4db-72691b31047f@github.com>
 <_BNHeZKa-5rb1e-IUqtecuycfSV7JnGuiBA67czhNi0=.88dc7df5-05cc-4c79-b0a9-018a252ef851@github.com>
 <2KZKDCK_OP0P_Ac_8OgsCxaoL7lCVVgr_8Bv2J7fp4w=.d239185a-eb34-4be8-a13e-dd4a35da6885@github.com>
Message-ID: <norrJcLjMqm0f2mqm8Ms2tvdurp7IPMlLKNRdg_4sTo=.978f5d5f-7ce2-4f84-b7c9-bee3ec657859@github.com>

On Thu, 4 Dec 2025 04:42:25 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>>> Let me do quick testing.
>> 
>> I will wait for the testing to complete before integrating it.
>
> @ashu-mehra you can integrate it when you are ready

@vnkozlov @iwanowww thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/28645#issuecomment-3610151998

From asmehra at openjdk.org  Thu Dec  4 05:06:10 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Thu, 4 Dec 2025 05:06:10 GMT
Subject: Integrated: 8373046: Method::get_c2i_unverified_entry() and
 get_c2i_no_clinit_check_entry() are missing check for abstract method
In-Reply-To: <0J8wPEDgQcJlN-yVMzfGoAFO02Km2Hv3zYJobWMNmFM=.b80b95b3-58b9-4b2f-94ee-db0025d14cb4@github.com>
References: <0J8wPEDgQcJlN-yVMzfGoAFO02Km2Hv3zYJobWMNmFM=.b80b95b3-58b9-4b2f-94ee-db0025d14cb4@github.com>
Message-ID: <3N3EJmUy-wL_O0a8jywLFcWOfsWkDBiO5WoZURmXf8w=.7926994c-b00b-4a1a-b0bb-e77f3e0b2287@github.com>

On Wed, 3 Dec 2025 19:45:12 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

> This PR fixes a bug introduced by [JDK-8365501](https://bugs.openjdk.org/browse/JDK-8365501). It restores the behavior of `Method::get_c2i_unverified_entry` or `Method::get_c2i_no_clinit_check_entry` for abstract methods as it was before JDK-8365501. It was never the intention of JDK-8365501 to change the behavior.
> I am not sure if there is any possible code flow that can result in calling `Method::get_c2i_unverified_entry` or `Method::get_c2i_no_clinit_check_entry` for abstract methods, but I think it is safe to keep the behavior of these functions as before.

This pull request has now been integrated.

Changeset: dbf0742b
Author:    Ashutosh Mehra <asmehra at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dbf0742bf205ec57477373ebd43016383f7e7791
Stats:     6 lines in 1 file changed: 6 ins; 0 del; 0 mod

8373046: Method::get_c2i_unverified_entry() and get_c2i_no_clinit_check_entry() are missing check for abstract method

Reviewed-by: kvn, vlivanov

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

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

From dholmes at openjdk.org  Thu Dec  4 05:15:03 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 4 Dec 2025 05:15:03 GMT
Subject: RFR: 8363996: Obsolete UseCompressedClassPointers
In-Reply-To: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
References: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
Message-ID: <V-Whc7AbQjp9KB3mixDSUX0MTDBgVLZreyI_PVIZdX0=.e4ebc8f5-a9c4-441d-8382-5ad65121dfad@github.com>

On Tue, 18 Nov 2025 08:17:37 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> _This patch is not intended for JDK 26_. 
> 
> I'm posting it now to collect feedback and, barring any objections, plan to push it once JDK 27 opens.
> 
> This change removes the uncompressed Klass pointer mode and, with compressed Klass pointers remaining as the only option, the `UseCompressedClassPointers` switch.
> 
> For motivation, please take a look at CSR associated with the deprecation (which we did for JDK 25) and the preparatory discussion we had at the start of the year around this topic [2].
> 
> This patch is quite invasive and touches many parts of the JVM, since its goal is to remove most traces of the uncompressed Klass path and to take advantage of opportunities for simplification. In some cases, I did not take opportunities for further simplification to keep the patch somewhat legible; it will be onerous enough to review.
> 
> ### Implementation Notes
> 
> With uncompressed Klass pointers removed, we have three modes of operation left (including 32-bit):
>   a) 64-bit, COH off - this is the old `+UseCompressedClassPointers` mode. This is now the standard mode until we run with COH by default.
>   b) 64-bit, COH on
>   c) 32-bit - Here, we run with a "fake" narrow Klass pointer mode. We run with hardcoded narrowKlass base == NULL and shift = 0, so nKlass == Klass*. The difference to (a, b) is that we don't use a class space. This was implemented with JDK-8363998 [3] - for more details, please see that issue and its PR.
> 
> I ensured *arm32* builds and I performed some rudimentary checks (selected metaspace/gc tests, and a simple Spring PetClinic run). Vendors with an interest in arm32 will have to step up and do their own, more thorough unit testing. Also, I did not see anyone doing follow-up work after JDK-8363998 [3] - so some issues may still lurk from that patch as well (but maybe JDK-8363998 was just not breaking anything).
> 
> I did not check *zero 32-bit*, the only other platform supporting 32-bit. Anyone with an interest in 32-bit zero should chip in.
>   
> Pre-existing errors: While working on this patch, I stumbled over a few occurrences of old but benign bugs. Mostly old code assuming CompressedClassPointers and CompressedOops were still tied together (example: Arguments::set_heap_size()). These bugs are implicitly fixed with this patch.
> 
> ### Testing
> 
> - tier 1 2 3 locally on Linux x64
> - SAP ran their whole set of tests for all the platforms they support.
> 
> 
> [1] https://bugs.openjdk.org/browse/JDK-8350754
> [2] https://mail.openjdk.org/pipermail/hotspot-dev/2025-February...

About a third of the way through. Mostly all pretty straight-forward but unclear why a number of _LP64 guards can be removed?

src/hotspot/share/cds/aotMetaspace.cpp line 1853:

> 1851: //
> 1852: // The range encompassing both spaces will be suitable to en/decode narrow Klass
> 1853: //  pointers: the base will be valid for encoding, the range [Base, End) and not

Suggestion:

//  pointers: the base will be valid for encoding the range [Base, End) and not

src/hotspot/share/cds/archiveBuilder.cpp line 671:

> 669:       dump_region->allocate(sizeof(address));
> 670:     }
> 671: #ifdef _LP64

Not obvious this isn't still needed.

src/hotspot/share/cds/archiveBuilder.cpp line 1140:

> 1138: };
> 1139: 
> 1140: #ifdef _LP64

Again not clear why this can be removed.

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

PR Review: https://git.openjdk.org/jdk/pull/28366#pullrequestreview-3538084962
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2587534751
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2587540478
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2587563999

From aboldtch at openjdk.org  Thu Dec  4 06:16:05 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 4 Dec 2025 06:16:05 GMT
Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact
 on GCs and JIT performance [v13]
In-Reply-To: <Kl5e4lLy09In3ii23YLueZVqzzzkBkZJLGAJb2k7Aio=.4347ba54-eb6b-4a9f-81e8-6db06a03824f@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
 <rtneArX_lMKv-UqOQNXv8DT_n8pY4UNn7nEE4FpKT4k=.ca641bc2-9d9a-4e0b-a329-da375913f5db@github.com>
 <Kl5e4lLy09In3ii23YLueZVqzzzkBkZJLGAJb2k7Aio=.4347ba54-eb6b-4a9f-81e8-6db06a03824f@github.com>
Message-ID: <834LXpq7tgXkAdLSbu_J-OoTWWYhCxr40d-y80Z5z3M=.84badc91-3b8f-44db-800b-b48cd1dfc8d6@github.com>

On Wed, 3 Dec 2025 16:00:05 GMT, Aleksey Shipilev <shade at openjdk.org> 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
>
> src/hotspot/share/asm/codeBuffer.cpp line 939:
> 
>> 937:     // Move all the code and relocations to the new blob:
>> 938:     relocate_code_to(&cb);
>> 939:   }
> 
> Here and later, the preferred style is:
> 
> Suggestion:
> 
>   // Move all the code and relocations to the new blob:
>   {
>     ICacheInvalidationContext icic(ICacheInvalidation::NOT_NEEDED);
>     relocate_code_to(&cb);
>   }

Go ahead and use @shipilev suggested change. Following the code style of the surrounding code is usually my preference as well. 

_The style comments we had earlier all applied to the ZGC code which has a certain style._

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

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

From duke at openjdk.org  Thu Dec  4 06:17:59 2025
From: duke at openjdk.org (Harshit470250)
Date: Thu, 4 Dec 2025 06:17:59 GMT
Subject: RFR: 8347396: Efficient TypeFunc creations [v3]
In-Reply-To: <da-a4Id_azWgrrTjDQEeYR6rm4D2l5jZAHIMx9x4v4w=.38b3a577-a776-49c4-8afb-27c684c126ad@github.com>
References: <VQs3SMtk1y6xTi8nCvTeWsTFfCQlTJtDdCGnfWQmRmw=.f3b33ba1-3efe-477b-b6d2-b43faae9ee2b@github.com>
 <da-a4Id_azWgrrTjDQEeYR6rm4D2l5jZAHIMx9x4v4w=.38b3a577-a776-49c4-8afb-27c684c126ad@github.com>
Message-ID: <RVJ3KK-WOQIWevdGxpzuWSgzm3EtOxQ6LdYvLGm24oM=.c36dd749-a390-49d8-845f-550a7c804cac@github.com>

On Wed, 3 Dec 2025 08:37:02 GMT, Harshit470250 <duke at openjdk.org> 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 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

After moving make_clone_type_Type() into barrierSetC2.cpp when I try to include the barrierSetC2.cpp file into runtime.cpp or type.cpp it causes redefinition of many functions.
I get these errors


duplicate symbol 'BarrierSetC2::load_at_resolved(C2Access&, Type const*) const' in:
    /Users/harshitdhiman/jdk/build/macosx-aarch64-server-fastdebug/hotspot/variant-server/libjvm/objs/barrierSetC2.o
    /Users/harshitdhiman/jdk/build/macosx-aarch64-server-fastdebug/hotspot/variant-server/libjvm/objs/runtime.o
duplicate symbol 'BarrierStubC2::entry()' in:
    /Users/harshitdhiman/jdk/build/macosx-aarch64-server-fastdebug/hotspot/variant-server/libjvm/objs/barrierSetC2.o
    /Users/harshitdhiman/jdk/build/macosx-aarch64-server-fastdebug/hotspot/variant-server/libjvm/objs/runtime.o



Can you suggest a way to solve this?

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

PR Comment: https://git.openjdk.org/jdk/pull/27279#issuecomment-3610474295

From aboldtch at openjdk.org  Thu Dec  4 06:29:59 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 4 Dec 2025 06:29:59 GMT
Subject: RFR: 8366671: Refactor Thread::SpinAcquire and Thread::SpinRelease
 [v12]
In-Reply-To: <BLbZykwmGPMfOyN0A7lrjaht-OWDbWK9_ArQRZZTVCU=.4bbd7292-3028-44f2-b0a5-cb4f29c2044b@github.com>
References: <NtY8E8fBeSokCAQYP3OQEwfnppSugtTJ8uAtQtD0zvg=.88f2988d-47fd-4b8a-af89-488ed6b37870@github.com>
 <BLbZykwmGPMfOyN0A7lrjaht-OWDbWK9_ArQRZZTVCU=.4bbd7292-3028-44f2-b0a5-cb4f29c2044b@github.com>
Message-ID: <HZCe9tbBmJ40vFlT_kQdXGCLZgYjlB-2lMC_7vlzrE4=.b99521d5-2347-45cb-b500-7588420181d1@github.com>

On Wed, 3 Dec 2025 14:04:28 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, 
>> 
>> please consider the following changes:
>> 
>> In this PR `Thread::SpinAcquire()` and `Thread::SpinRelease()` methods are refactored into a utility class `SpinCriticalSection`. The motivation is to make it easier for developers to use this lightweight synchronization mechanism in the codebase. The two aforementioned methods were used in JFR to create short critical sections with a helper class, but that was not the case for the object monitor code. 
>> 
>> Tested in tiers 1 - 5.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8366671: Added NoSafepointVerifier

Thanks for this refactoring!

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

Marked as reviewed by aboldtch (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28264#pullrequestreview-3538348134

From dholmes at openjdk.org  Thu Dec  4 06:53:04 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 4 Dec 2025 06:53:04 GMT
Subject: RFR: 8367319: Add os interfaces to get machine and container
 values separately [v5]
In-Reply-To: <Q5LOAsRhyY58X2jHFSRDKqyAKWFzWfcITJwuuk50D2o=.b7e3b0ef-6700-4ced-90fc-48126bf1db9f@github.com>
References: <gxXrAX2NGPyZnHuA4ttkfJ8MagiiELK-Wk700A2ZBgw=.00aaf9ab-976d-476a-ba4d-8a4063d96130@github.com>
 <lI_E9fdbu_ilitVsUyZBFZZ3M1D-Y4lC1UaLvpP1drU=.d28d0b3f-8112-4d76-8f14-edce2923f7bb@github.com>
 <Q5LOAsRhyY58X2jHFSRDKqyAKWFzWfcITJwuuk50D2o=.b7e3b0ef-6700-4ced-90fc-48126bf1db9f@github.com>
Message-ID: <Zw1--idz925pWBSxndgs-bXyYxg_8MFgsJbceYchAdo=.4d17b893-44ef-4d8f-bcf7-b8cee90a9da6@github.com>

On Wed, 3 Dec 2025 15:15:45 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Casper Norrbin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
>> 
>>  - 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
>>  - Fixed print type
>>  - separate-machine-container-functions
>
> src/hotspot/os/linux/os_linux.cpp line 222:
> 
>> 220:     return true;
>> 221:   }
>> 222:   return false;
> 
> Assume this usage:
> 
> physical_memory_size mem_limit = 0;
> if (!os::Container::memory_limit(mem_limit)) {
>   // assume mem_limit == 0;
> }
> 
> 
> The general contract for cases where a function returned `false` (i.e. error) is that the passed in reference remains untouched. This seems to violate that contract. `value` could change from whatever the initial value was to `value_unlimited` and return `false`.

I don't see a specification for any of these bool-returning functions with out-parameters (whether already existing or new here) so I'm not quite sure how to read a lot of them. Does returning true mean asking about a limit was successful, or that it was successful and there is a limit? Do the low-level functions have the same behaviour as the higher-level ones?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27646#discussion_r2587796557

From stuefe at openjdk.org  Thu Dec  4 07:00:33 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 4 Dec 2025 07:00:33 GMT
Subject: RFR: 8363996: Obsolete UseCompressedClassPointers [v2]
In-Reply-To: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
References: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
Message-ID: <ldiIiY3LSNshPye3DZvJLoFzqF3drGAWabsO8siCeGU=.87f7cf4f-67c6-4cfa-9cd4-2a238a2272be@github.com>

> _This patch is not intended for JDK 26_. 
> 
> I'm posting it now to collect feedback and, barring any objections, plan to push it once JDK 27 opens.
> 
> This change removes the uncompressed Klass pointer mode and, with compressed Klass pointers remaining as the only option, the `UseCompressedClassPointers` switch.
> 
> For motivation, please take a look at CSR associated with the deprecation (which we did for JDK 25) and the preparatory discussion we had at the start of the year around this topic [2].
> 
> This patch is quite invasive and touches many parts of the JVM, since its goal is to remove most traces of the uncompressed Klass path and to take advantage of opportunities for simplification. In some cases, I did not take opportunities for further simplification to keep the patch somewhat legible; it will be onerous enough to review.
> 
> ### Implementation Notes
> 
> With uncompressed Klass pointers removed, we have three modes of operation left (including 32-bit):
>   a) 64-bit, COH off - this is the old `+UseCompressedClassPointers` mode. This is now the standard mode until we run with COH by default.
>   b) 64-bit, COH on
>   c) 32-bit - Here, we run with a "fake" narrow Klass pointer mode. We run with hardcoded narrowKlass base == NULL and shift = 0, so nKlass == Klass*. The difference to (a, b) is that we don't use a class space. This was implemented with JDK-8363998 [3] - for more details, please see that issue and its PR.
> 
> I ensured *arm32* builds and I performed some rudimentary checks (selected metaspace/gc tests, and a simple Spring PetClinic run). Vendors with an interest in arm32 will have to step up and do their own, more thorough unit testing. Also, I did not see anyone doing follow-up work after JDK-8363998 [3] - so some issues may still lurk from that patch as well (but maybe JDK-8363998 was just not breaking anything).
> 
> I did not check *zero 32-bit*, the only other platform supporting 32-bit. Anyone with an interest in 32-bit zero should chip in.
>   
> Pre-existing errors: While working on this patch, I stumbled over a few occurrences of old but benign bugs. Mostly old code assuming CompressedClassPointers and CompressedOops were still tied together (example: Arguments::set_heap_size()). These bugs are implicitly fixed with this patch.
> 
> ### Testing
> 
> - tier 1 2 3 locally on Linux x64
> - SAP ran their whole set of tests for all the platforms they support.
> 
> 
> [1] https://bugs.openjdk.org/browse/JDK-8350754
> [2] https://mail.openjdk.org/pipermail/hotspot-dev/2025-February...

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

  Update src/hotspot/share/cds/aotMetaspace.cpp
  
  Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28366/files
  - new: https://git.openjdk.org/jdk/pull/28366/files/64d7984a..141113a0

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

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

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

From stuefe at openjdk.org  Thu Dec  4 07:06:49 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 4 Dec 2025 07:06:49 GMT
Subject: RFR: 8363996: Obsolete UseCompressedClassPointers [v3]
In-Reply-To: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
References: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
Message-ID: <iuFGPYMntccuF67iSGdqenHob1nhmj2NEzrzPUbIgmk=.4a1423df-c614-4549-93d6-35b3c4f7220d@github.com>

> _This patch is not intended for JDK 26_. 
> 
> I'm posting it now to collect feedback and, barring any objections, plan to push it once JDK 27 opens.
> 
> This change removes the uncompressed Klass pointer mode and, with compressed Klass pointers remaining as the only option, the `UseCompressedClassPointers` switch.
> 
> For motivation, please take a look at CSR associated with the deprecation (which we did for JDK 25) and the preparatory discussion we had at the start of the year around this topic [2].
> 
> This patch is quite invasive and touches many parts of the JVM, since its goal is to remove most traces of the uncompressed Klass path and to take advantage of opportunities for simplification. In some cases, I did not take opportunities for further simplification to keep the patch somewhat legible; it will be onerous enough to review.
> 
> ### Implementation Notes
> 
> With uncompressed Klass pointers removed, we have three modes of operation left (including 32-bit):
>   a) 64-bit, COH off - this is the old `+UseCompressedClassPointers` mode. This is now the standard mode until we run with COH by default.
>   b) 64-bit, COH on
>   c) 32-bit - Here, we run with a "fake" narrow Klass pointer mode. We run with hardcoded narrowKlass base == NULL and shift = 0, so nKlass == Klass*. The difference to (a, b) is that we don't use a class space. This was implemented with JDK-8363998 [3] - for more details, please see that issue and its PR.
> 
> I ensured *arm32* builds and I performed some rudimentary checks (selected metaspace/gc tests, and a simple Spring PetClinic run). Vendors with an interest in arm32 will have to step up and do their own, more thorough unit testing. Also, I did not see anyone doing follow-up work after JDK-8363998 [3] - so some issues may still lurk from that patch as well (but maybe JDK-8363998 was just not breaking anything).
> 
> I did not check *zero 32-bit*, the only other platform supporting 32-bit. Anyone with an interest in 32-bit zero should chip in.
>   
> Pre-existing errors: While working on this patch, I stumbled over a few occurrences of old but benign bugs. Mostly old code assuming CompressedClassPointers and CompressedOops were still tied together (example: Arguments::set_heap_size()). These bugs are implicitly fixed with this patch.
> 
> ### Testing
> 
> - tier 1 2 3 locally on Linux x64
> - SAP ran their whole set of tests for all the platforms they support.
> 
> 
> [1] https://bugs.openjdk.org/browse/JDK-8350754
> [2] https://mail.openjdk.org/pipermail/hotspot-dev/2025-February...

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

  Apply suggestion from @theRealAph
  
  Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28366/files
  - new: https://git.openjdk.org/jdk/pull/28366/files/141113a0..074a2337

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

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

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

From stuefe at openjdk.org  Thu Dec  4 07:06:52 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 4 Dec 2025 07:06:52 GMT
Subject: RFR: 8363996: Obsolete UseCompressedClassPointers [v3]
In-Reply-To: <V-Whc7AbQjp9KB3mixDSUX0MTDBgVLZreyI_PVIZdX0=.e4ebc8f5-a9c4-441d-8382-5ad65121dfad@github.com>
References: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
 <V-Whc7AbQjp9KB3mixDSUX0MTDBgVLZreyI_PVIZdX0=.e4ebc8f5-a9c4-441d-8382-5ad65121dfad@github.com>
Message-ID: <crsYU_Tu05BFWgbBK3eFianA3GQ1zHl3Og9EgY7FRtI=.4976b9da-ef03-4f7e-b84c-12bbd8136b23@github.com>

On Thu, 4 Dec 2025 04:59:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply suggestion from @theRealAph
>>   
>>   Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>
>
> src/hotspot/share/cds/archiveBuilder.cpp line 671:
> 
>> 669:       dump_region->allocate(sizeof(address));
>> 670:     }
>> 671: #ifdef _LP64
> 
> Not obvious this isn't still needed.

That is a small simplification that should have been part of https://bugs.openjdk.org/browse/JDK-8363998. The test


alignment = nth_bit(ArchiveBuilder::precomputed_narrow_klass_shift());


can be applied to 32-bit, too. There, precomputed_narrow_klass_shift() is zero.

> src/hotspot/share/cds/archiveBuilder.cpp line 1140:
> 
>> 1138: };
>> 1139: 
>> 1140: #ifdef _LP64
> 
> Again not clear why this can be removed.

Same reasoning. 32-bit now also uses narrow Klass pointers, so that code can be made unconditionally compilable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2587823782
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2587825926

From stuefe at openjdk.org  Thu Dec  4 07:09:01 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 4 Dec 2025 07:09:01 GMT
Subject: RFR: 8363996: Obsolete UseCompressedClassPointers
In-Reply-To: <1ylERIxcH47S_3TkReUXaGLfMgYBVrvniM-2qMcReMg=.4a242937-c1db-45e9-b905-9df0dece3cc4@github.com>
References: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
 <1ylERIxcH47S_3TkReUXaGLfMgYBVrvniM-2qMcReMg=.4a242937-c1db-45e9-b905-9df0dece3cc4@github.com>
Message-ID: <tkxu-GE6GBi2tLDhE29Zv4k3_UuHnF4hpK83HPFzx1Y=.2f8639a0-5f0d-4286-9a2f-a4c911d7408d@github.com>

On Wed, 3 Dec 2025 20:37:25 GMT, Andrew Haley <aph at openjdk.org> wrote:

> https://github.com/openjdk/jdk/pull/28366/files?w=1 makes this PR easier to read.

Yes, "hide widespaces" is useful. Github is still surprisingly bad at managing large patches.

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

PR Comment: https://git.openjdk.org/jdk/pull/28366#issuecomment-3610611623

From kbarrett at openjdk.org  Thu Dec  4 08:26:06 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 4 Dec 2025 08:26:06 GMT
Subject: RFR: 8366671: Refactor Thread::SpinAcquire and Thread::SpinRelease
 [v12]
In-Reply-To: <BLbZykwmGPMfOyN0A7lrjaht-OWDbWK9_ArQRZZTVCU=.4bbd7292-3028-44f2-b0a5-cb4f29c2044b@github.com>
References: <NtY8E8fBeSokCAQYP3OQEwfnppSugtTJ8uAtQtD0zvg=.88f2988d-47fd-4b8a-af89-488ed6b37870@github.com>
 <BLbZykwmGPMfOyN0A7lrjaht-OWDbWK9_ArQRZZTVCU=.4bbd7292-3028-44f2-b0a5-cb4f29c2044b@github.com>
Message-ID: <_Bufj-FTIPiGAdIIHeAfVuoYbGp5BRLMsRtDS9Os6ek=.4cd41efc-c3e4-4d37-be9f-4856d9c8bc93@github.com>

On Wed, 3 Dec 2025 14:04:28 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, 
>> 
>> please consider the following changes:
>> 
>> In this PR `Thread::SpinAcquire()` and `Thread::SpinRelease()` methods are refactored into a utility class `SpinCriticalSection`. The motivation is to make it easier for developers to use this lightweight synchronization mechanism in the codebase. The two aforementioned methods were used in JFR to create short critical sections with a helper class, but that was not the case for the object monitor code. 
>> 
>> Tested in tiers 1 - 5.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8366671: Added NoSafepointVerifier

Marked as reviewed by kbarrett (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28264#pullrequestreview-3538685648

From kbarrett at openjdk.org  Thu Dec  4 08:31:57 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 4 Dec 2025 08:31:57 GMT
Subject: RFR: 8372938: Fix reference to DeferredStatic<T> in HotSpot Style
 Guide
In-Reply-To: <U3JAGHbJ5Cf61IKK3X6J4tMCwF_XfO3OYFh_7Z5outw=.880ba930-972a-4637-a708-08459d38c05f@github.com>
References: <re4DxMiOgwBWbPKHqXTXzJZeGWG0TYs-Bdyzqe_RE14=.fe7a761c-2fc6-44d2-a196-f4ccba2868b0@github.com>
 <U3JAGHbJ5Cf61IKK3X6J4tMCwF_XfO3OYFh_7Z5outw=.880ba930-972a-4637-a708-08459d38c05f@github.com>
Message-ID: <kpVU-YJ_-uPeP2mVuvM4N22xry5yh_FBD7_KA7DP_eg=.2fac2266-bb96-434f-823e-c0c57dd23171@github.com>

On Tue, 2 Dec 2025 14:21:01 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Please review this trivial editorial fix to the HotSpot Style Guide.
>> JDK-8360458 changed the name of the utility class `Deferred<T>` to
>> `DeferredStatic<T>`, but forgot to update the reference to that class in the
>> Style Guide.
>
> Marked as reviewed by stefank (Reviewer).

Thanks for reviews @stefank and @jdksjolen

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

PR Comment: https://git.openjdk.org/jdk/pull/28602#issuecomment-3610857772

From kbarrett at openjdk.org  Thu Dec  4 08:35:07 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 4 Dec 2025 08:35:07 GMT
Subject: Integrated: 8372938: Fix reference to DeferredStatic<T> in HotSpot
 Style Guide
In-Reply-To: <re4DxMiOgwBWbPKHqXTXzJZeGWG0TYs-Bdyzqe_RE14=.fe7a761c-2fc6-44d2-a196-f4ccba2868b0@github.com>
References: <re4DxMiOgwBWbPKHqXTXzJZeGWG0TYs-Bdyzqe_RE14=.fe7a761c-2fc6-44d2-a196-f4ccba2868b0@github.com>
Message-ID: <LaGTgRwIqwVnudRmwxU0jl6etnQNmzhTgMig4V__sOY=.c3302eba-cad0-446a-b945-790d6cd6d369@github.com>

On Tue, 2 Dec 2025 14:05:01 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this trivial editorial fix to the HotSpot Style Guide.
> JDK-8360458 changed the name of the utility class `Deferred<T>` to
> `DeferredStatic<T>`, but forgot to update the reference to that class in the
> Style Guide.

This pull request has now been integrated.

Changeset: bb867ed2
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bb867ed23e2d6394d7e7dab55cf2122889fdf3ac
Stats:     3 lines in 2 files changed: 0 ins; 0 del; 3 mod

8372938: Fix reference to DeferredStatic<T> in HotSpot Style Guide

Reviewed-by: stefank, jsjolen

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

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

From sgehwolf at openjdk.org  Thu Dec  4 08:40:02 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 4 Dec 2025 08:40:02 GMT
Subject: RFR: 8367319: Add os interfaces to get machine and container
 values separately [v5]
In-Reply-To: <Zw1--idz925pWBSxndgs-bXyYxg_8MFgsJbceYchAdo=.4d17b893-44ef-4d8f-bcf7-b8cee90a9da6@github.com>
References: <gxXrAX2NGPyZnHuA4ttkfJ8MagiiELK-Wk700A2ZBgw=.00aaf9ab-976d-476a-ba4d-8a4063d96130@github.com>
 <lI_E9fdbu_ilitVsUyZBFZZ3M1D-Y4lC1UaLvpP1drU=.d28d0b3f-8112-4d76-8f14-edce2923f7bb@github.com>
 <Q5LOAsRhyY58X2jHFSRDKqyAKWFzWfcITJwuuk50D2o=.b7e3b0ef-6700-4ced-90fc-48126bf1db9f@github.com>
 <Zw1--idz925pWBSxndgs-bXyYxg_8MFgsJbceYchAdo=.4d17b893-44ef-4d8f-bcf7-b8cee90a9da6@github.com>
Message-ID: <EdnWyzTqxqti6PdX52PDtVqha-nygYXheZab7R-q7y4=.7a937620-9af7-488e-ac37-be43f77750fb@github.com>

On Thu, 4 Dec 2025 06:50:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/os/linux/os_linux.cpp line 222:
>> 
>>> 220:     return true;
>>> 221:   }
>>> 222:   return false;
>> 
>> Assume this usage:
>> 
>> physical_memory_size mem_limit = 0;
>> if (!os::Container::memory_limit(mem_limit)) {
>>   // assume mem_limit == 0;
>> }
>> 
>> 
>> The general contract for cases where a function returned `false` (i.e. error) is that the passed in reference remains untouched. This seems to violate that contract. `value` could change from whatever the initial value was to `value_unlimited` and return `false`.
>
> I don't see a specification for any of these bool-returning functions with out-parameters (whether already existing or new here) so I'm not quite sure how to read a lot of them. Does returning true mean asking about a limit was successful, or that it was successful and there is a limit? Do the low-level functions have the same behaviour as the higher-level ones?

This started with:
https://bugs.openjdk.org/browse/JDK-8357086

They should have the same meaning throughout. Returning `true` means the passed in reference has been set to a value. In the container case it might be `value_unlimited` (for example an interface file has value `max`). So if the desire is to return `false` for unlimited, then this needs to be handled on top.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27646#discussion_r2588068482

From cnorrbin at openjdk.org  Thu Dec  4 09:32:00 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Thu, 4 Dec 2025 09:32:00 GMT
Subject: RFR: 8367319: Add os interfaces to get machine and container
 values separately [v5]
In-Reply-To: <EdnWyzTqxqti6PdX52PDtVqha-nygYXheZab7R-q7y4=.7a937620-9af7-488e-ac37-be43f77750fb@github.com>
References: <gxXrAX2NGPyZnHuA4ttkfJ8MagiiELK-Wk700A2ZBgw=.00aaf9ab-976d-476a-ba4d-8a4063d96130@github.com>
 <lI_E9fdbu_ilitVsUyZBFZZ3M1D-Y4lC1UaLvpP1drU=.d28d0b3f-8112-4d76-8f14-edce2923f7bb@github.com>
 <Q5LOAsRhyY58X2jHFSRDKqyAKWFzWfcITJwuuk50D2o=.b7e3b0ef-6700-4ced-90fc-48126bf1db9f@github.com>
 <Zw1--idz925pWBSxndgs-bXyYxg_8MFgsJbceYchAdo=.4d17b893-44ef-4d8f-bcf7-b8cee90a9da6@github.com>
 <EdnWyzTqxqti6PdX52PDtVqha-nygYXheZab7R-q7y4=.7a937620-9af7-488e-ac37-be43f77750fb@github.com>
Message-ID: <GEsqWomVqhCLXVtqyajBXpw2xkIdvbS5IVFPMBuGaTo=.a162aa48-ec1e-451a-8d72-e47ab6a1b433@github.com>

On Thu, 4 Dec 2025 08:37:11 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> I don't see a specification for any of these bool-returning functions with out-parameters (whether already existing or new here) so I'm not quite sure how to read a lot of them. Does returning true mean asking about a limit was successful, or that it was successful and there is a limit? Do the low-level functions have the same behaviour as the higher-level ones?
>
> This started with:
> https://bugs.openjdk.org/browse/JDK-8357086
> 
> They should have the same meaning throughout. Returning `true` means the passed in reference has been set to a value. In the container case it might be `value_unlimited` (for example an interface file has value `max`). So if the desire is to return `false` for unlimited, then this needs to be handled on top.

>From my perspective, returning `true` from one of these functions means that the out-parameter is set to a valid, meaningful value and can be used safely by the caller. However, if the function returns `false`, there is no guarantee that the out-parameter is untouched, so relying on its previous value is unsafe. Your example is to me is a bad pattern and is brittle at best.

There is a distinction between `OSContainer::memory_limit_in_bytes` (which always fetches and returns the cgroup, including `value_unlimited` for no limit) and the higher-level `os::Container::memory_limit`, which is about determining whether there is an effective limit at all, and if so, what it is. It doesn't make sense to return `true` if there is no limit, since there wouldn't be a meaningful value to provide. `value_unlimited` is just an internal constant and not helpful for callers.

That said, I can update so we don't pass through the out-parameter so that we don't modify it when returning `false`, to be somewhat more consistent. But I still believe we should return `false` when no limit is set.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27646#discussion_r2588233182

From cnorrbin at openjdk.org  Thu Dec  4 09:42:14 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Thu, 4 Dec 2025 09:42:14 GMT
Subject: RFR: 8367319: Add os interfaces to get machine and container
 values separately [v5]
In-Reply-To: <Q5LOAsRhyY58X2jHFSRDKqyAKWFzWfcITJwuuk50D2o=.b7e3b0ef-6700-4ced-90fc-48126bf1db9f@github.com>
References: <gxXrAX2NGPyZnHuA4ttkfJ8MagiiELK-Wk700A2ZBgw=.00aaf9ab-976d-476a-ba4d-8a4063d96130@github.com>
 <lI_E9fdbu_ilitVsUyZBFZZ3M1D-Y4lC1UaLvpP1drU=.d28d0b3f-8112-4d76-8f14-edce2923f7bb@github.com>
 <Q5LOAsRhyY58X2jHFSRDKqyAKWFzWfcITJwuuk50D2o=.b7e3b0ef-6700-4ced-90fc-48126bf1db9f@github.com>
Message-ID: <hUCHvV6AQEotIR_EzbDVbGc2LRvivQRYN4RJ648v5sQ=.2c41db5f-b912-4fc0-889e-a866070ebd39@github.com>

On Wed, 3 Dec 2025 15:19:15 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Casper Norrbin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
>> 
>>  - 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
>>  - Fixed print type
>>  - separate-machine-container-functions
>
> src/hotspot/os/linux/os_linux.cpp line 226:
> 
>> 224: 
>> 225: bool os::Container::memory_soft_limit(physical_memory_size_type& value) {
>> 226:   if (OSContainer::memory_soft_limit_in_bytes(value) && value != 0) {
> 
> Why the `value != 0` check? Shouldn't this check for `value_unlimited` as is done for other `limit` functions? Same issue applies in the theoretical case where `0` is being read. The function returns `false`, but the initial `value` might have not been `0`.

With no soft limit set in cgroup v2, the corresponding `memory.low` is set to 0 by default. However, looking at this for cgroup v1, it could instead be a very high number, so we return `value_unlimited`. We should probably change one so both behave the same.

Here it makes sense to check for both `0` and `value_unlimited` instead of just `0`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27646#discussion_r2588267446

From sgehwolf at openjdk.org  Thu Dec  4 10:05:03 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 4 Dec 2025 10:05:03 GMT
Subject: RFR: 8367319: Add os interfaces to get machine and container
 values separately [v5]
In-Reply-To: <GEsqWomVqhCLXVtqyajBXpw2xkIdvbS5IVFPMBuGaTo=.a162aa48-ec1e-451a-8d72-e47ab6a1b433@github.com>
References: <gxXrAX2NGPyZnHuA4ttkfJ8MagiiELK-Wk700A2ZBgw=.00aaf9ab-976d-476a-ba4d-8a4063d96130@github.com>
 <lI_E9fdbu_ilitVsUyZBFZZ3M1D-Y4lC1UaLvpP1drU=.d28d0b3f-8112-4d76-8f14-edce2923f7bb@github.com>
 <Q5LOAsRhyY58X2jHFSRDKqyAKWFzWfcITJwuuk50D2o=.b7e3b0ef-6700-4ced-90fc-48126bf1db9f@github.com>
 <Zw1--idz925pWBSxndgs-bXyYxg_8MFgsJbceYchAdo=.4d17b893-44ef-4d8f-bcf7-b8cee90a9da6@github.com>
 <EdnWyzTqxqti6PdX52PDtVqha-nygYXheZab7R-q7y4=.7a937620-9af7-488e-ac37-be43f77750fb@github.com>
 <GEsqWomVqhCLXVtqyajBXpw2xkIdvbS5IVFPMBuGaTo=.a162aa48-ec1e-451a-8d72-e47ab6a1b433@github.com>
Message-ID: <-fJmK2NEtYRIt_gO260itXoFE06wOgtn2is7EGZk4ek=.ab54f399-1c09-48c9-827d-fc2c9efad6e0@github.com>

On Thu, 4 Dec 2025 09:28:52 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> There is a distinction between `OSContainer::memory_limit_in_bytes` (which always fetches and returns the cgroup, including `value_unlimited` for no limit) and the higher-level `os::Container::memory_limit`, which is about determining whether there is an effective limit at all, and if so, what it is. It doesn't make sense to return `true` if there is no limit, since there wouldn't be a meaningful value to provide. `value_unlimited` is just an internal constant and not helpful for callers.

OK. This should be noted in a comment for `os::Container::xxx` functions.

> That said, I can update so we don't pass through the out-parameter so that we don't modify it when returning `false`, to be somewhat more consistent.

I'd prefer that, yes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27646#discussion_r2588352903

From ayang at openjdk.org  Thu Dec  4 10:10:44 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 4 Dec 2025 10:10:44 GMT
Subject: RFR: 8370198: Test gc/arguments/TestShrinkHeapInSteps.java
 crashed:  assert(left >= right) failed: avoid underflow [v2]
In-Reply-To: <WKjyigvXghJNT-bijIBX8dyE1cdd3GsubdHvrNrYHyM=.dedfb4bc-b098-4d8f-8f5a-291d92fe9f2d@github.com>
References: <WKjyigvXghJNT-bijIBX8dyE1cdd3GsubdHvrNrYHyM=.dedfb4bc-b098-4d8f-8f5a-291d92fe9f2d@github.com>
Message-ID: <vdMrM6h6DqATiQV2Dv1BDQyKgAfEgFVbJ_AFIkTHgcE=.eb5bddd8-c148-4bf9-9425-fb3a3ca5f789@github.com>

> Add an early-return for outside-heap address in `CollectedHeap::is_in` API.
> 
> While investigating this failure (JDK-8370198), I realized that some java-threads (compiler-threads) in `native` state can invoke `CollectedHeap` APIs. Since heap-resizing occurs inside safepoint but java-threads in `native` state just ignore safepoint, I have added some assert to catch such dangerous uses, where the return value might not be stable.
> 
> Test: tie1-5; can't reproduce the JDK-8370198 with or without this patch for >8000 runs.

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

 - review
 - Merge branch 'master' into sgc-is-in-early-return
 - sgc-is-in-early-return

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28393/files
  - new: https://git.openjdk.org/jdk/pull/28393/files/6f435555..515c739e

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

  Stats: 71805 lines in 1278 files changed: 47297 ins; 17182 del; 7326 mod
  Patch: https://git.openjdk.org/jdk/pull/28393.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28393/head:pull/28393

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

From ayang at openjdk.org  Thu Dec  4 10:10:46 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 4 Dec 2025 10:10:46 GMT
Subject: RFR: 8370198: Test gc/arguments/TestShrinkHeapInSteps.java
 crashed:  assert(left >= right) failed: avoid underflow
In-Reply-To: <WKjyigvXghJNT-bijIBX8dyE1cdd3GsubdHvrNrYHyM=.dedfb4bc-b098-4d8f-8f5a-291d92fe9f2d@github.com>
References: <WKjyigvXghJNT-bijIBX8dyE1cdd3GsubdHvrNrYHyM=.dedfb4bc-b098-4d8f-8f5a-291d92fe9f2d@github.com>
Message-ID: <zw4hINhZs_P0o1x8uqNFBaa2v9f7xJH2EQ4rFfo4z90=.43bc1ea8-08d6-4cf5-a435-62127ae8dd64@github.com>

On Wed, 19 Nov 2025 15:39:27 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Add an early-return for outside-heap address in `CollectedHeap::is_in` API.
> 
> While investigating this failure (JDK-8370198), I realized that some java-threads (compiler-threads) in `native` state can invoke `CollectedHeap` APIs. Since heap-resizing occurs inside safepoint but java-threads in `native` state just ignore safepoint, I have added some assert to catch such dangerous uses, where the return value might not be stable.
> 
> Test: tie1-5; can't reproduce the JDK-8370198 with or without this patch for >8000 runs.

After some offline discussion with Stefan, it's suggested that `CollectedHeap::is_in` should probably require callers to be in good state (e.g. not java-threads-in-native).

After removing the asserts in `MacroAssembler::set_narrow_klass`, I don't any crashes with placing such state-verification at the beginning of `is_in`. Therefore, it's probably best to make the assumption explicit (as a precondition).

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

PR Comment: https://git.openjdk.org/jdk/pull/28393#issuecomment-3611267941

From mgronlun at openjdk.org  Thu Dec  4 10:29:35 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 4 Dec 2025 10:29:35 GMT
Subject: RFR: 8373062: JFR build failure with CDS disabled [v2]
In-Reply-To: <VBzvkarY-LB9n0CZheJ2JKxRe98VkeRqotTD8P4-vmY=.5ce21498-d7d2-4289-875e-46a01bf4b3e5@github.com>
References: <VBzvkarY-LB9n0CZheJ2JKxRe98VkeRqotTD8P4-vmY=.5ce21498-d7d2-4289-875e-46a01bf4b3e5@github.com>
Message-ID: <3UTq-N9HJwvAaxkyFlRMfjpCJVWL7pM5g3S4qFiRGQo=.ed758eaf-4e0d-4b48-8226-1f3df4fbdaca@github.com>

> Greetings,
> 
> [JDK-8365400](https://bugs.openjdk.org/browse/JDK-8365400) caused a build problem when passing build option "--disable-cds" because of missing conditionals.
> 
> Testing: manually building with "--disable-cds"
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  post_class_load_event wrongly placed inside INCLUDE_CDS section

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28656/files
  - new: https://git.openjdk.org/jdk/pull/28656/files/513642a6..369297f5

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

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

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

From cnorrbin at openjdk.org  Thu Dec  4 10:32:46 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Thu, 4 Dec 2025 10:32:46 GMT
Subject: RFR: 8367319: Add os interfaces to get machine and container
 values separately [v6]
In-Reply-To: <gxXrAX2NGPyZnHuA4ttkfJ8MagiiELK-Wk700A2ZBgw=.00aaf9ab-976d-476a-ba4d-8a4063d96130@github.com>
References: <gxXrAX2NGPyZnHuA4ttkfJ8MagiiELK-Wk700A2ZBgw=.00aaf9ab-976d-476a-ba4d-8a4063d96130@github.com>
Message-ID: <uHiQOLDZ0iw4ZHbvkiQVRBmLFtKkqzaGJQh1J_cyfD8=.5ed9eea3-3cd3-4352-89ae-35d842cac34d@github.com>

> 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 incrementally with one additional commit since the last revision:

  feedback updates

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27646/files
  - new: https://git.openjdk.org/jdk/pull/27646/files/58a809bc..3eda822e

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

  Stats: 13 lines in 2 files changed: 10 ins; 0 del; 3 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 stuefe at openjdk.org  Thu Dec  4 10:48:26 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 4 Dec 2025 10:48:26 GMT
Subject: RFR: 8340297: Use-after-free recognition for metaspace and class
 space [v10]
In-Reply-To: <ckYAP8HHGv4OhEIpJM_Rrg-H9RPBAzyC4AS5iYBTVZo=.a51b849a-c917-4a03-9bae-853a39e97f8a@github.com>
References: <e7K9hloTVns_L6mpJEgB192r_5jRUm0zyO6ThMl8ti0=.068e7e7f-bd03-48e5-98bd-66a3dd61868a@github.com>
 <ckYAP8HHGv4OhEIpJM_Rrg-H9RPBAzyC4AS5iYBTVZo=.a51b849a-c917-4a03-9bae-853a39e97f8a@github.com>
Message-ID: <FRN2Iepc68TdZHU8dyCWFpzq668xKYRbS1ej9SKi1cY=.b57469e9-f399-40fa-9e48-7aaaa5e1db02@github.com>

On Fri, 24 Oct 2025 06:37:43 GMT, Thomas Stuefe <stuefe at openjdk.org> 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 incrementally with one additional commit since the last revision:
> 
>   includes sorted

Ping..

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

PR Comment: https://git.openjdk.org/jdk/pull/25891#issuecomment-3611461837

From stuefe at openjdk.org  Thu Dec  4 10:48:25 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 4 Dec 2025 10:48:25 GMT
Subject: RFR: 8340297: Use-after-free recognition for metaspace and class
 space [v11]
In-Reply-To: <e7K9hloTVns_L6mpJEgB192r_5jRUm0zyO6ThMl8ti0=.068e7e7f-bd03-48e5-98bd-66a3dd61868a@github.com>
References: <e7K9hloTVns_L6mpJEgB192r_5jRUm0zyO6ThMl8ti0=.068e7e7f-bd03-48e5-98bd-66a3dd61868a@github.com>
Message-ID: <KKxcFtCsRLUW_n7FwdK6UF9MQ-UD2Nc2tjCJwmp9IC0=.0d8dd3af-1339-4bd8-b847-a6d4c0df9d5f@github.com>

> 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

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

Changes: https://git.openjdk.org/jdk/pull/25891/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25891&range=10
  Stats: 483 lines in 26 files changed: 399 ins; 27 del; 57 mod
  Patch: https://git.openjdk.org/jdk/pull/25891.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25891/head:pull/25891

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

From stuefe at openjdk.org  Thu Dec  4 11:05:59 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 4 Dec 2025 11:05:59 GMT
Subject: RFR: 8359706: Add file descriptor count and maximum limit to
 VM.info [v2]
In-Reply-To: <36A5noLY70ktfD5Hjabo7xw3HDJmqi2rL3_OBrfNkTg=.c78dcf7e-faa6-47df-91e6-24b96769c499@github.com>
References: <a1HhcupsCROYETAf5X3Gbz5WqojDYbwjMcR4ZKx7uGI=.bedae8d1-08e8-426e-b073-5e207e18573a@github.com>
 <rm4JsWZQ9cCT8atMmnVuAdeyK18T6PAJFOUppCC5Vqw=.add3357a-d19a-4793-bd3a-e7f67d512bd7@github.com>
 <36A5noLY70ktfD5Hjabo7xw3HDJmqi2rL3_OBrfNkTg=.c78dcf7e-faa6-47df-91e6-24b96769c499@github.com>
Message-ID: <ZRvaVPGpvmPeEIIbuC7GY2ml-ch6VI5nq3LaoOmMOfE=.25840359-86ab-4cef-aef5-4e1f51d2d282@github.com>

On Wed, 29 Oct 2025 14:47:44 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updates
>
>> 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 
> 
> I'm trying to understand what functionality you're after here. Is the specific number of open file descriptors important or is it enough to just report that there are "a lot" of file descriptors open? If so, @tstuefe's suggested approach of looking at `/proc/self/status` and FDSize and don't report the exact number if over some limit is a good compromise I think.
> 
> I couldn't find any good documentation for Mac's `proc_pidinfo`, but looking at the source code it's not an expensive operation at all (https://github.com/apple/darwin-xnu/blob/2ff845c2e033bd0ff64b5b6aa6063a1f8f65aa32/bsd/kern/proc_info.c#L486). I know very little of AIX to have an opinion, but if it's an issue maybe we can skip reporting it for now?

> Thanks @jsikstro and @tstuefe for the insightful comments. Just to note, the maximum possible FDs (NOFILE) is already printed in VM.info (and maybe should be added to the hs_err file), the main idea of this patch is to provide the current number of open file descriptors for diagnosing FD exhaustion (compared against the max FD) and FD leaks.
> 
> Would a timed loop for both AIX and Linux (exiting the scan if it takes more than a set threshold) work 

that would be my preferred solution

> and what would be an acceptable threshold? 

A few ms; 50 maybe?

> Maybe we could report that the FD count above the current counted value if we reach the threshold or fall back to reporting the FDSize field from /proc/self/status on Linux as a rough estimate?

I would not put any work into this. Just report what you got, as in ">10000" or somesuch. If this time limit hits, we have a ton of file descriptors, or something is wrong with /proc; either is rare. The exact number does not matter then. An analyst would probably have to look at the machine or the VM process to check what's going on. E.g. who opens that many files.

> 
> Also, the Mac API is undocumented - https://zameermanji.com/blog/2021/8/1/counting-open-file-descriptors-on-macos/.

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

PR Comment: https://git.openjdk.org/jdk/pull/27971#issuecomment-3611539814

From stefank at openjdk.org  Thu Dec  4 11:11:21 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 4 Dec 2025 11:11:21 GMT
Subject: RFR: 8370198: Test gc/arguments/TestShrinkHeapInSteps.java
 crashed:  assert(left >= right) failed: avoid underflow [v2]
In-Reply-To: <vdMrM6h6DqATiQV2Dv1BDQyKgAfEgFVbJ_AFIkTHgcE=.eb5bddd8-c148-4bf9-9425-fb3a3ca5f789@github.com>
References: <WKjyigvXghJNT-bijIBX8dyE1cdd3GsubdHvrNrYHyM=.dedfb4bc-b098-4d8f-8f5a-291d92fe9f2d@github.com>
 <vdMrM6h6DqATiQV2Dv1BDQyKgAfEgFVbJ_AFIkTHgcE=.eb5bddd8-c148-4bf9-9425-fb3a3ca5f789@github.com>
Message-ID: <-e8AEMg9uK0iEqJznCz9AwGvtrGGXFKXqOjQvkqpQUE=.3abe8aed-fc9b-428f-b9c6-efc684f10f85@github.com>

On Thu, 4 Dec 2025 10:10:44 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Add an early-return for outside-heap address in `CollectedHeap::is_in` API.
>> 
>> While investigating this failure (JDK-8370198), I realized that some java-threads (compiler-threads) in `native` state can invoke `CollectedHeap` APIs. Since heap-resizing occurs inside safepoint but java-threads in `native` state just ignore safepoint, I have added some assert to catch such dangerous uses, where the return value might not be stable.
>> 
>> Test: tie1-5; can't reproduce the JDK-8370198 with or without this patch for >8000 runs.
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - review
>  - Merge branch 'master' into sgc-is-in-early-return
>  - sgc-is-in-early-return

Please extract the verification into a helper function / macro

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

Changes requested by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28393#pullrequestreview-3539419555

From jsjolen at openjdk.org  Thu Dec  4 11:11:21 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 4 Dec 2025 11:11:21 GMT
Subject: RFR: 8340297: Use-after-free recognition for metaspace and class
 space [v10]
In-Reply-To: <FRN2Iepc68TdZHU8dyCWFpzq668xKYRbS1ej9SKi1cY=.b57469e9-f399-40fa-9e48-7aaaa5e1db02@github.com>
References: <e7K9hloTVns_L6mpJEgB192r_5jRUm0zyO6ThMl8ti0=.068e7e7f-bd03-48e5-98bd-66a3dd61868a@github.com>
 <ckYAP8HHGv4OhEIpJM_Rrg-H9RPBAzyC4AS5iYBTVZo=.a51b849a-c917-4a03-9bae-853a39e97f8a@github.com>
 <FRN2Iepc68TdZHU8dyCWFpzq668xKYRbS1ej9SKi1cY=.b57469e9-f399-40fa-9e48-7aaaa5e1db02@github.com>
Message-ID: <nyeTrbS-i2xUNiqFi0c9N9FQrXxz6HDf0cuWef1Ft5o=.8669ccdb-f629-4987-8207-db9f39f3fe44@github.com>

On Thu, 4 Dec 2025 10:45:10 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Ping..

Looks like @shipilev doesn't have the cycles for this :). How about we pull towards this happening anyway? It seems like it would be a useful feature to have. I'll have to do another review, though.

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

PR Comment: https://git.openjdk.org/jdk/pull/25891#issuecomment-3611583605

From ayang at openjdk.org  Thu Dec  4 11:28:40 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 4 Dec 2025 11:28:40 GMT
Subject: RFR: 8370198: Test gc/arguments/TestShrinkHeapInSteps.java
 crashed:  assert(left >= right) failed: avoid underflow [v3]
In-Reply-To: <WKjyigvXghJNT-bijIBX8dyE1cdd3GsubdHvrNrYHyM=.dedfb4bc-b098-4d8f-8f5a-291d92fe9f2d@github.com>
References: <WKjyigvXghJNT-bijIBX8dyE1cdd3GsubdHvrNrYHyM=.dedfb4bc-b098-4d8f-8f5a-291d92fe9f2d@github.com>
Message-ID: <MletNy8VM8gz765TK_XbczaTYtyPS4Jsdc1mDmxWomQ=.ff5019b9-5dda-4237-840e-4fe53d9ef61e@github.com>

> Add an early-return for outside-heap address in `CollectedHeap::is_in` API.
> 
> While investigating this failure (JDK-8370198), I realized that some java-threads (compiler-threads) in `native` state can invoke `CollectedHeap` APIs. Since heap-resizing occurs inside safepoint but java-threads in `native` state just ignore safepoint, I have added some assert to catch such dangerous uses, where the return value might not be stable.
> 
> Test: tie1-5; can't reproduce the JDK-8370198 with or without this patch for >8000 runs.

Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:

  review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28393/files
  - new: https://git.openjdk.org/jdk/pull/28393/files/515c739e..1a7bbae0

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

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

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

From aph at openjdk.org  Thu Dec  4 11:52:00 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 4 Dec 2025 11:52:00 GMT
Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() [v3]
In-Reply-To: <SIYhGsf5_2F6gUNHFuGT_mOGFR2QO5E-ZntNCqFqDqM=.0d56c710-10eb-4f39-b2fc-664cc4e0cce1@github.com>
References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com>
 <SIYhGsf5_2F6gUNHFuGT_mOGFR2QO5E-ZntNCqFqDqM=.0d56c710-10eb-4f39-b2fc-664cc4e0cce1@github.com>
Message-ID: <kta_3vVQvi-NedQaVoVJKN5rypJUDDLHMqFWC6fDg-M=.5e844253-9bf7-40fe-8b24-720cad918c63@github.com>

On Tue, 2 Dec 2025 13:54:01 GMT, Fei Gao <fgao at openjdk.org> 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 six additional commits since the last revision:
> 
>  - 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
>  - 8363620: AArch64: reimplement emit_static_call_stub()
>    
>    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 bytes 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-...

src/hotspot/cpu/aarch64/compiledIC_aarch64.cpp line 180:

> 178:     nativeCallTrampolineStub_at(trampoline_stub_addr)->set_destination(stub);
> 179:   }
> 180: 

Suggestion:


  // This code is executed while other threads are running. We must                                                                                                                  
  // ensure that at all times there is a valid path of execution. A                                                                                                                  
  // racing thread either observes a call (possibly via a trampoline)                                                                                                                
  // to SharedRuntime::resolve_static_call_C or a complete call to the                                                                                                               
  // interpreter.                                                                                                                                                                    
  //                                                                                                                                                                                 
  // If a racing thread observes an updated direct branch at a call                                                                                                                  
  // site, it must also observe all of the updated instructions in the                                                                                                               
  // static interpreter stub.                                                                                                                                                        
  //                                                                                                                                                                                 
  // To ensure this, we first update the static interpreter stub, then                                                                                                               
  // the trampoline, then the direct branch at the call site.                                                                                                                        
  //                                                                                                                                                                                 
  // AArch64 stub_via_BL                                                                                                                                                             
  // {                                                                                                                                                                               
  // 0:X0=instr:"MOV w0, #2";                                                                                                                                                        
  // 0:X1=instr:"BL .+16";                                                                                                                                                           
  // 0:X10=P1:new;                                                                                                                                                                   
  // 0:X11=P1:L0;                                                                                                                                                                    
  // }                                                                                                                                                                               
  //                                                                                                                                                                                 
  // P0              |  P1            ;                                                                                                                                              
  // STR W0, [X10]   |L0:             ;                                                                                                                                              
  // DC CVAU, X10    |  BL old        ;                                                                                                                                              
  // DSB ISH         |  B end         ;                                                                                                                                              
  // IC IVAU, X10    |old:            ;                                                                                                                                              
  // DSB ISH         |  MOV w0, #0    ;                                                                                                                                              
  //                 |  RET           ;                                                                                                                                              
  // STR W1, [X11]   |new:            ;                                                                                                                                              
  //                 |  MOV w0, #1    ;                                                                                                                                              
  //                 |  RET           ;                                                                                                                                              
  //                 |end:            ;                                                                                                                                              
  // forall(1:X0=0 / 1:X0=2)                                                                                                                                                        
  //                                                                                                                                                                                 
  // We maintan an invariant: every call site either points directly                                                                                                                 
  // to the call destination or to the call site's trampoline. The                                                                                                                   
  // trampoline points to the call destination. Even if the trampoline                                                                                                               
  // is not in use, and therefore not reachable, it still points to                                                                                                                  
  // the call destination.                                                                                                                                                           
  //                                                                                                                                                                                 
  // If a racing thread reaches the static call stub via a trampoline,                                                                                                               
  // we must ensure that it observes the static call stub in                                                                                                                          // full. Initially we place an ISB at the start of the static call                                                                                                                
  // stub. After we update the static call stub we rewrite the ISB                                                                                                                  
  // with 'B .+4' A racing thread either observes the ISB or the                                                                                                                    
  // branch. Once the stub has been rewritten and the instruction and                                                                                                               
  // data caches have been synchronized to the point of unification by                                                                                                              
  // ICache::invalidate_range, either is sufficient to ensure that the                                                                                                              
  // subsequent instructions are observed.                                                                                                                                          
  //                                                                                                                                                                                
  // As confirmed by the litmus test below, when a racing executing                                                                                                                 
  // thread reaches the static call stub:                                                                                                                                           

  //   - If it observes the 'B .+4', it will also observe the updated 'MOV's                                                                                                        
  //   - Or, it will execute the 'ISB' - the instruction fetch ensures                                                                                                              
  //     the updated 'MOV's are observed.                                                                                                                                           
  //                                                                                                                                                                                
  // AArch64 stub_via_BR                                                                                                                                                            
  // {                                                                                                                                                                              
  // [target] = P1:old;                                                                                                                                                             
  //                                                                                                                                                                                
  //                               1:X0 = 0;                                                                                                                                        
  // 0:X1 = instr:"MOV X0, #3";                                                                                                                                                     
  // 0:X2 = instr:"b .+4";                                                                                                                                                          
  // 0:X3 = target;                1:X3 = target;                                                                                                                                   
  // 0:X4 = P1:new;                                                                                                                                                                 
  // 0:X5 = P1:patch;                                                                                                                                                               
  // }                                                                                                                                                                              
  //                                                                                                                                                                                
  // P0                          | P1                        ;                                                                                                                      
  // STR W1, [X5]                |  LDR X2, [X3]             ;                                                                                                                      
  // DC CVAU, X5                 |  BR X2                    ;                                                                                                                      
  // DSB ISH                     |new:                       ;                                                                                                                      
  // IC IVAU, X5                 |  ISB                      ;                                                                                                                      
  // DSB ISH                     |patch:                     ;                                                                                                                      
  // STR W2, [X4]                |  MOV X0, #2               ;                                                                                                                      
  // STR X4, [X3]                |  B end                    ;                                                                                                                      
  //                             |old:                       ;                                                                                                                      
  //                             |  MOV X0, #1               ;                                                                                                                      
  //                             |  B end                    ;                                                                                                                      
  //                             |end:                       ;                                                                                                                      
  // forall (1:X0=1 / 1:X0=3)                                                                                                                                                      

  NativeJump::insert(stub, stub + NativeJump::instruction_size);

  address trampoline_stub_addr = _call->get_trampoline();
  if (trampoline_stub_addr != nullptr) {
    nativeCallTrampolineStub_at(trampoline_stub_addr)->set_destination(stub);
  }

  // Update jump to call.                                                                                                                                                           
  _call->set_destination(stub);
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26638#discussion_r2588743655

From aph at openjdk.org  Thu Dec  4 11:57:09 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 4 Dec 2025 11:57:09 GMT
Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() [v3]
In-Reply-To: <kta_3vVQvi-NedQaVoVJKN5rypJUDDLHMqFWC6fDg-M=.5e844253-9bf7-40fe-8b24-720cad918c63@github.com>
References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com>
 <SIYhGsf5_2F6gUNHFuGT_mOGFR2QO5E-ZntNCqFqDqM=.0d56c710-10eb-4f39-b2fc-664cc4e0cce1@github.com>
 <kta_3vVQvi-NedQaVoVJKN5rypJUDDLHMqFWC6fDg-M=.5e844253-9bf7-40fe-8b24-720cad918c63@github.com>
Message-ID: <ssEDRY-9OkcWXfXLZIioSzz3_luPHLR3E_aoczbOCVM=.2bf5bd10-89de-44e4-8e5c-369dd89c3bce@github.com>

On Thu, 4 Dec 2025 11:48:50 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> 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 six additional commits since the last revision:
>> 
>>  - 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
>>  - 8363620: AArch64: reimplement emit_static_call_stub()
>>    
>>    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 bytes 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] ht...
>
> src/hotspot/cpu/aarch64/compiledIC_aarch64.cpp line 180:
> 
>> 178:     nativeCallTrampolineStub_at(trampoline_stub_addr)->set_destination(stub);
>> 179:   }
>> 180: 
> 
> Suggestion:
> 
> 
>   // This code is executed while other threads are running. We must                                                                                                                  
>   // ensure that at all times there is a valid path of execution. A                                                                                                                  
>   // racing thread either observes a call (possibly via a trampoline)                                                                                                                
>   // to SharedRuntime::resolve_static_call_C or a complete call to the                                                                                                               
>   // interpreter.                                                                                                                                                                    
>   //                                                                                                                                                                                 
>   // If a racing thread observes an updated direct branch at a call                                                                                                                  
>   // site, it must also observe all of the updated instructions in the                                                                                                               
>   // static interpreter stub.                                                                                                                                                        
>   //                                                                                                                                                                                 
>   // To ensure this, we first update the static interpreter stub, then                                                                                                               
>   // the trampoline, then the direct branch at the call site.                                                                                                                        
>   //                                                                                                                                       ...

Here's my thinking:

First say what you want to achieve and why.

Be definite about what you say in comments. Avoid words like "generally", for example. Always use the strongest words you can. For example, "because" is stronger than "since".

Be concise. The purpose of all code is to ensure correctness, so you don't have to say so.

This comment is not perfect, so feel free to amend anything that is unclear.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26638#discussion_r2588762916

From aph at openjdk.org  Thu Dec  4 12:02:30 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 4 Dec 2025 12:02:30 GMT
Subject: RFR: 8363996: Obsolete UseCompressedClassPointers [v3]
In-Reply-To: <iuFGPYMntccuF67iSGdqenHob1nhmj2NEzrzPUbIgmk=.4a1423df-c614-4549-93d6-35b3c4f7220d@github.com>
References: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
 <iuFGPYMntccuF67iSGdqenHob1nhmj2NEzrzPUbIgmk=.4a1423df-c614-4549-93d6-35b3c4f7220d@github.com>
Message-ID: <PEUWeI3-Cf6-D97C3UIwkF2tZu3uH6aSkl-1HU1frNM=.586665ea-8412-4871-9dcb-2a3163022d48@github.com>

On Thu, 4 Dec 2025 07:06:49 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> _This patch is not intended for JDK 26_. 
>> 
>> I'm posting it now to collect feedback and, barring any objections, plan to push it once JDK 27 opens.
>> 
>> This change removes the uncompressed Klass pointer mode and, with compressed Klass pointers remaining as the only option, the `UseCompressedClassPointers` switch.
>> 
>> For motivation, please take a look at CSR associated with the deprecation (which we did for JDK 25) and the preparatory discussion we had at the start of the year around this topic [2].
>> 
>> This patch is quite invasive and touches many parts of the JVM, since its goal is to remove most traces of the uncompressed Klass path and to take advantage of opportunities for simplification. In some cases, I did not take opportunities for further simplification to keep the patch somewhat legible; it will be onerous enough to review.
>> 
>> ### Implementation Notes
>> 
>> With uncompressed Klass pointers removed, we have three modes of operation left (including 32-bit):
>>   a) 64-bit, COH off - this is the old `+UseCompressedClassPointers` mode. This is now the standard mode until we run with COH by default.
>>   b) 64-bit, COH on
>>   c) 32-bit - Here, we run with a "fake" narrow Klass pointer mode. We run with hardcoded narrowKlass base == NULL and shift = 0, so nKlass == Klass*. The difference to (a, b) is that we don't use a class space. This was implemented with JDK-8363998 [3] - for more details, please see that issue and its PR.
>> 
>> I ensured *arm32* builds and I performed some rudimentary checks (selected metaspace/gc tests, and a simple Spring PetClinic run). Vendors with an interest in arm32 will have to step up and do their own, more thorough unit testing. Also, I did not see anyone doing follow-up work after JDK-8363998 [3] - so some issues may still lurk from that patch as well (but maybe JDK-8363998 was just not breaking anything).
>> 
>> I did not check *zero 32-bit*, the only other platform supporting 32-bit. Anyone with an interest in 32-bit zero should chip in.
>>   
>> Pre-existing errors: While working on this patch, I stumbled over a few occurrences of old but benign bugs. Mostly old code assuming CompressedClassPointers and CompressedOops were still tied together (example: Arguments::set_heap_size()). These bugs are implicitly fixed with this patch.
>> 
>> ### Testing
>> 
>> - tier 1 2 3 locally on Linux x64
>> - SAP ran their whole set of tests for all the platforms they support.
>> 
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8350754
>> [2...
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestion from @theRealAph
>   
>   Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>

src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp line 1281:

> 1279:   Rtmp1 = op->tmp3()->as_register();
> 1280:   select_different_registers(obj, dst, k_RInfo, klass_RInfo, Rtmp1);
> 1281: 

Suggestion:

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2588781883

From aph at openjdk.org  Thu Dec  4 12:06:05 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 4 Dec 2025 12:06:05 GMT
Subject: RFR: 8363996: Obsolete UseCompressedClassPointers [v3]
In-Reply-To: <iuFGPYMntccuF67iSGdqenHob1nhmj2NEzrzPUbIgmk=.4a1423df-c614-4549-93d6-35b3c4f7220d@github.com>
References: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
 <iuFGPYMntccuF67iSGdqenHob1nhmj2NEzrzPUbIgmk=.4a1423df-c614-4549-93d6-35b3c4f7220d@github.com>
Message-ID: <3GE775UHXUoDMOLKl9C7Ao52gXf3U-_cfiC5ruJBz2w=.66997f1e-6dce-4803-903a-a787b3496183@github.com>

On Thu, 4 Dec 2025 07:06:49 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> _This patch is not intended for JDK 26_. 
>> 
>> I'm posting it now to collect feedback and, barring any objections, plan to push it once JDK 27 opens.
>> 
>> This change removes the uncompressed Klass pointer mode and, with compressed Klass pointers remaining as the only option, the `UseCompressedClassPointers` switch.
>> 
>> For motivation, please take a look at CSR associated with the deprecation (which we did for JDK 25) and the preparatory discussion we had at the start of the year around this topic [2].
>> 
>> This patch is quite invasive and touches many parts of the JVM, since its goal is to remove most traces of the uncompressed Klass path and to take advantage of opportunities for simplification. In some cases, I did not take opportunities for further simplification to keep the patch somewhat legible; it will be onerous enough to review.
>> 
>> ### Implementation Notes
>> 
>> With uncompressed Klass pointers removed, we have three modes of operation left (including 32-bit):
>>   a) 64-bit, COH off - this is the old `+UseCompressedClassPointers` mode. This is now the standard mode until we run with COH by default.
>>   b) 64-bit, COH on
>>   c) 32-bit - Here, we run with a "fake" narrow Klass pointer mode. We run with hardcoded narrowKlass base == NULL and shift = 0, so nKlass == Klass*. The difference to (a, b) is that we don't use a class space. This was implemented with JDK-8363998 [3] - for more details, please see that issue and its PR.
>> 
>> I ensured *arm32* builds and I performed some rudimentary checks (selected metaspace/gc tests, and a simple Spring PetClinic run). Vendors with an interest in arm32 will have to step up and do their own, more thorough unit testing. Also, I did not see anyone doing follow-up work after JDK-8363998 [3] - so some issues may still lurk from that patch as well (but maybe JDK-8363998 was just not breaking anything).
>> 
>> I did not check *zero 32-bit*, the only other platform supporting 32-bit. Anyone with an interest in 32-bit zero should chip in.
>>   
>> Pre-existing errors: While working on this patch, I stumbled over a few occurrences of old but benign bugs. Mostly old code assuming CompressedClassPointers and CompressedOops were still tied together (example: Arguments::set_heap_size()). These bugs are implicitly fixed with this patch.
>> 
>> ### Testing
>> 
>> - tier 1 2 3 locally on Linux x64
>> - SAP ran their whole set of tests for all the platforms they support.
>> 
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8350754
>> [2...
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestion from @theRealAph
>   
>   Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>

src/hotspot/share/cds/aotMappedHeapLoader.hpp line 55:

> 53:   static bool can_use() { return can_map() || can_load(); }
> 54: 
> 55:   // Can this VM map archived heap region? Currently only G1+compressed{oops,cp}

Suggestion:

  // Can this VM map archived heap region? Currently only G1.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2588797500

From dholmes at openjdk.org  Thu Dec  4 12:13:05 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 4 Dec 2025 12:13:05 GMT
Subject: RFR: 8366671: Refactor Thread::SpinAcquire and Thread::SpinRelease
 [v12]
In-Reply-To: <BLbZykwmGPMfOyN0A7lrjaht-OWDbWK9_ArQRZZTVCU=.4bbd7292-3028-44f2-b0a5-cb4f29c2044b@github.com>
References: <NtY8E8fBeSokCAQYP3OQEwfnppSugtTJ8uAtQtD0zvg=.88f2988d-47fd-4b8a-af89-488ed6b37870@github.com>
 <BLbZykwmGPMfOyN0A7lrjaht-OWDbWK9_ArQRZZTVCU=.4bbd7292-3028-44f2-b0a5-cb4f29c2044b@github.com>
Message-ID: <204L9XlL2bBMtfNvqWuvXgBdUfR04jt6-NrWFCzfR7A=.5d3b8c34-2949-4707-b26b-ee57c4546ead@github.com>

On Wed, 3 Dec 2025 14:04:28 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, 
>> 
>> please consider the following changes:
>> 
>> In this PR `Thread::SpinAcquire()` and `Thread::SpinRelease()` methods are refactored into a utility class `SpinCriticalSection`. The motivation is to make it easier for developers to use this lightweight synchronization mechanism in the codebase. The two aforementioned methods were used in JFR to create short critical sections with a helper class, but that was not the case for the object monitor code. 
>> 
>> Tested in tiers 1 - 5.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8366671: Added NoSafepointVerifier

src/hotspot/share/utilities/spinCriticalSection.hpp line 46:

> 44:   // compared to  smaller/larger types.
> 45:   volatile int* const _lock;
> 46:   DEBUG_ONLY(NoSafepointVerifier _nsv;)

I thought NSV had to be used as a StackObj ?? I don't understand why it is a field of SCS.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28264#discussion_r2588051933

From mbaesken at openjdk.org  Thu Dec  4 12:26:15 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 4 Dec 2025 12:26:15 GMT
Subject: RFR: 8351842: Windows specific issues in combination of JEP 493
 and --with-external-symbols-in-bundles=public [v7]
In-Reply-To: <GmCc0zKQhuTx4s7vzyjFA2gztgss7VxwcAFOUkw8ifw=.c4f69a8c-1407-45d7-a17f-59e1af2578f8@github.com>
References: <R-zg2t6gMm9oZgSijkRxJ0ErqtvoFeqPyfUGbhZRkEQ=.17b0ed93-ea7b-4a37-8471-12624c937a71@github.com>
 <GmCc0zKQhuTx4s7vzyjFA2gztgss7VxwcAFOUkw8ifw=.c4f69a8c-1407-45d7-a17f-59e1af2578f8@github.com>
Message-ID: <9UaIabNuOXVVLwf9B932e9r5nWuWYbv42F3VOIFmZ4U=.66ffe47e-f3da-4a51-a270-924ae627ab5f@github.com>

On Wed, 3 Dec 2025 09:54:38 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> This PR addresses an issue that can be observed when building on Windows with configure options `--enable-linkable-runtime` and `--with-external-symbols-in-bundles=public`.
>> 
>> The problem is that with this special build configuration, we build two sets of .pdb files for the binaries. The first set is the standard debug symbols files named <binary-name>.pdb. The second set consists of stripped debug symbols file called <binary-name>.stripped.pdb which have less information but enough to present line numbers in hs-err files.
>> 
>> During build we use the *.stripped.pdb files for compiling the jmods and also the bundle files. However, in the images folder, both sets of .pdb files exist. The tests for runtime linking will now, in the absence of jmod files, pick up the .pdb files (without *stripped*) from images, but in the runtime the hashes of the *stripped* files are stored.
>> 
>> With this change, the standard .pdb files in the `--with-external-symbols-in-bundles=public` configuration are now the stripped files and we create a set of full pdb files named *.full.pdb. Jmods and Bundles still contain the stripped pdb files and we also fix the issue that the debug symbols bundle also contained stripped pdb files so far. With this fix, it will contain the full pdb files and extracting these over a JDK runtime will replace stripped pdbs with full pdbs.
>
> Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback

Marked as reviewed by mbaesken (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24012#pullrequestreview-3539755805

From coleenp at openjdk.org  Thu Dec  4 12:35:40 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 4 Dec 2025 12:35:40 GMT
Subject: RFR: 8366671: Refactor Thread::SpinAcquire and Thread::SpinRelease
 [v12]
In-Reply-To: <204L9XlL2bBMtfNvqWuvXgBdUfR04jt6-NrWFCzfR7A=.5d3b8c34-2949-4707-b26b-ee57c4546ead@github.com>
References: <NtY8E8fBeSokCAQYP3OQEwfnppSugtTJ8uAtQtD0zvg=.88f2988d-47fd-4b8a-af89-488ed6b37870@github.com>
 <BLbZykwmGPMfOyN0A7lrjaht-OWDbWK9_ArQRZZTVCU=.4bbd7292-3028-44f2-b0a5-cb4f29c2044b@github.com>
 <204L9XlL2bBMtfNvqWuvXgBdUfR04jt6-NrWFCzfR7A=.5d3b8c34-2949-4707-b26b-ee57c4546ead@github.com>
Message-ID: <N7vHuN5b9KhsJe530nxvGwy7s0hbswRiro-oOmumsME=.5b461e49-6609-4f64-92c6-21e7186b1258@github.com>

On Thu, 4 Dec 2025 08:31:33 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8366671: Added NoSafepointVerifier
>
> src/hotspot/share/utilities/spinCriticalSection.hpp line 46:
> 
>> 44:   // compared to  smaller/larger types.
>> 45:   volatile int* const _lock;
>> 46:   DEBUG_ONLY(NoSafepointVerifier _nsv;)
> 
> I thought NSV had to be used as a StackObj ?? I don't understand why it is a field of SCS.

It can be a field of a StackObj too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28264#discussion_r2588894187

From aph at openjdk.org  Thu Dec  4 12:39:30 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 4 Dec 2025 12:39:30 GMT
Subject: RFR: 8372701: Randomized profile counters [v3]
In-Reply-To: <jKjmIONZcytzVjS4absOwOLv_QOF9qhIJifYhN6JyP4=.dceced94-bc29-43e6-9062-8dc77c2a6133@github.com>
References: <jKjmIONZcytzVjS4absOwOLv_QOF9qhIJifYhN6JyP4=.dceced94-bc29-43e6-9062-8dc77c2a6133@github.com>
Message-ID: <Z3xSycWsDflD-8z95W-cbINmyR5RcJeUpvG3mnxdtEE=.3247d5d9-a18a-414f-8fc8-c11346455dd8@github.com>

> 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 with a new target base due to a merge or a rebase. The pull request now contains 54 commits:

 - More
 - Merge branch 'master' into JDK-8134940
 - Merge remote-tracking branch 'refs/remotes/origin/JDK-8134940' into JDK-8134940
 - whitespace
 - AArch64
 - Minimize deltas to master
 - Better
 - Inter
 - Cleanup
 - Cleanup
 - ... and 44 more: https://git.openjdk.org/jdk/compare/5bd7db03...a7476d22

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

Changes: https://git.openjdk.org/jdk/pull/28541/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28541&range=02
  Stats: 1150 lines in 26 files changed: 921 ins; 38 del; 191 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 aph at openjdk.org  Thu Dec  4 12:44:58 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 4 Dec 2025 12:44:58 GMT
Subject: RFR: 8372701: Randomized profile counters [v2]
In-Reply-To: <vP3GzUDISRkvmmGenTIPJqBcJ2Img3k4pU2eEqe-2OA=.22385445-a442-46c2-b996-4bb737fe5df0@github.com>
References: <jKjmIONZcytzVjS4absOwOLv_QOF9qhIJifYhN6JyP4=.dceced94-bc29-43e6-9062-8dc77c2a6133@github.com>
 <YAdyTG2jqY3OcJ7M4mD0CkL56a0p6ciaHYM-ow9Ham8=.0cb57295-acde-4e49-984b-b8756ed99850@github.com>
 <vP3GzUDISRkvmmGenTIPJqBcJ2Img3k4pU2eEqe-2OA=.22385445-a442-46c2-b996-4bb737fe5df0@github.com>
Message-ID: <l_egyDhBscIQGnTRY7M8m3K4NngeIiPr8Lc6Tq2T2bE=.3501b90d-13b9-4170-994b-d4f73a68a55c@github.com>

On Wed, 3 Dec 2025 11:51:31 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> I can run our internal performance testing with this but it currently fails to build on AArch64:

Done, thank you.

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

PR Comment: https://git.openjdk.org/jdk/pull/28541#issuecomment-3612074273

From stuefe at openjdk.org  Thu Dec  4 13:36:43 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 4 Dec 2025 13:36:43 GMT
Subject: RFR: 8363996: Obsolete UseCompressedClassPointers [v4]
In-Reply-To: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
References: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
Message-ID: <jedU_ilFWTbEPv8RFDP9uPw7T9-tO5V_ETTw-2Ial3g=.2a930bec-f4d7-406b-ac29-d64e7b106b03@github.com>

> _This patch is not intended for JDK 26_. 
> 
> I'm posting it now to collect feedback and, barring any objections, plan to push it once JDK 27 opens.
> 
> This change removes the uncompressed Klass pointer mode and, with compressed Klass pointers remaining as the only option, the `UseCompressedClassPointers` switch.
> 
> For motivation, please take a look at CSR associated with the deprecation (which we did for JDK 25) and the preparatory discussion we had at the start of the year around this topic [2].
> 
> This patch is quite invasive and touches many parts of the JVM, since its goal is to remove most traces of the uncompressed Klass path and to take advantage of opportunities for simplification. In some cases, I did not take opportunities for further simplification to keep the patch somewhat legible; it will be onerous enough to review.
> 
> ### Implementation Notes
> 
> With uncompressed Klass pointers removed, we have three modes of operation left (including 32-bit):
>   a) 64-bit, COH off - this is the old `+UseCompressedClassPointers` mode. This is now the standard mode until we run with COH by default.
>   b) 64-bit, COH on
>   c) 32-bit - Here, we run with a "fake" narrow Klass pointer mode. We run with hardcoded narrowKlass base == NULL and shift = 0, so nKlass == Klass*. The difference to (a, b) is that we don't use a class space. This was implemented with JDK-8363998 [3] - for more details, please see that issue and its PR.
> 
> I ensured *arm32* builds and I performed some rudimentary checks (selected metaspace/gc tests, and a simple Spring PetClinic run). Vendors with an interest in arm32 will have to step up and do their own, more thorough unit testing. Also, I did not see anyone doing follow-up work after JDK-8363998 [3] - so some issues may still lurk from that patch as well (but maybe JDK-8363998 was just not breaking anything).
> 
> I did not check *zero 32-bit*, the only other platform supporting 32-bit. Anyone with an interest in 32-bit zero should chip in.
>   
> Pre-existing errors: While working on this patch, I stumbled over a few occurrences of old but benign bugs. Mostly old code assuming CompressedClassPointers and CompressedOops were still tied together (example: Arguments::set_heap_size()). These bugs are implicitly fixed with this patch.
> 
> ### Testing
> 
> - tier 1 2 3 locally on Linux x64
> - SAP ran their whole set of tests for all the platforms they support.
> 
> 
> [1] https://bugs.openjdk.org/browse/JDK-8350754
> [2] https://mail.openjdk.org/pipermail/hotspot-dev/2025-February...

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

  Update src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp
  
  Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28366/files
  - new: https://git.openjdk.org/jdk/pull/28366/files/074a2337..9e85a653

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

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

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

From tschatzl at openjdk.org  Thu Dec  4 13:39:30 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 4 Dec 2025 13:39:30 GMT
Subject: RFR: 8370198: Test gc/arguments/TestShrinkHeapInSteps.java
 crashed:  assert(left >= right) failed: avoid underflow [v3]
In-Reply-To: <MletNy8VM8gz765TK_XbczaTYtyPS4Jsdc1mDmxWomQ=.ff5019b9-5dda-4237-840e-4fe53d9ef61e@github.com>
References: <WKjyigvXghJNT-bijIBX8dyE1cdd3GsubdHvrNrYHyM=.dedfb4bc-b098-4d8f-8f5a-291d92fe9f2d@github.com>
 <MletNy8VM8gz765TK_XbczaTYtyPS4Jsdc1mDmxWomQ=.ff5019b9-5dda-4237-840e-4fe53d9ef61e@github.com>
Message-ID: <7Dy3XDFXp0_So2NClGXt-t88GSiTNeIQIIp8ngmTlxg=.fac7d5a5-8953-4b9a-b93f-651ec4cf845c@github.com>

On Thu, 4 Dec 2025 11:28:40 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Add an early-return for outside-heap address in `CollectedHeap::is_in` API.
>> 
>> While investigating this failure (JDK-8370198), I realized that some java-threads (compiler-threads) in `native` state can invoke `CollectedHeap` APIs. Since heap-resizing occurs inside safepoint but java-threads in `native` state just ignore safepoint, I have added some assert to catch such dangerous uses, where the return value might not be stable.
>> 
>> Test: tie1-5; can't reproduce the JDK-8370198 with or without this patch for >8000 runs.
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

lgtm; I think `verify_not_in_native_if_java_thread` could be made a `NOT_DEBUG_RETURN` method which I tend to prefer to have less defines in the code. Either is fine to me though.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28393#pullrequestreview-3540081518

From thartmann at openjdk.org  Thu Dec  4 13:41:39 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 4 Dec 2025 13:41:39 GMT
Subject: RFR: 8372701: Randomized profile counters [v3]
In-Reply-To: <Z3xSycWsDflD-8z95W-cbINmyR5RcJeUpvG3mnxdtEE=.3247d5d9-a18a-414f-8fc8-c11346455dd8@github.com>
References: <jKjmIONZcytzVjS4absOwOLv_QOF9qhIJifYhN6JyP4=.dceced94-bc29-43e6-9062-8dc77c2a6133@github.com>
 <Z3xSycWsDflD-8z95W-cbINmyR5RcJeUpvG3mnxdtEE=.3247d5d9-a18a-414f-8fc8-c11346455dd8@github.com>
Message-ID: <iJLtYeVBT40xFQvISBdToauPAJ_Ll_eZOHpW-QGEc5U=.700d48ea-95eb-48d0-bbed-fffe45ee6da5@github.com>

On Thu, 4 Dec 2025 12:39:30 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> 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 with a new target base due to a merge or a rebase. The pull request now contains 54 commits:
> 
>  - More
>  - Merge branch 'master' into JDK-8134940
>  - Merge remote-tracking branch 'refs/remotes/origin/JDK-8134940' into JDK-8134940
>  - whitespace
>  - AArch64
>  - Minimize deltas to master
>  - Better
>  - Inter
>  - Cleanup
>  - Cleanup
>  - ... and 44 more: https://git.openjdk.org/jdk/compare/5bd7db03...a7476d22

Thanks, still fails though:


[2025-12-04T13:35:07,965Z] * For target hotspot_variant-server_libjvm_objs_c1_MacroAssembler_aarch64.o:
[2025-12-04T13:35:07,965Z] /opt/mach5/mesos/work_dir/slaves/da1065b5-7b94-4f0d-85e9-a3a252b9a32e-S11677/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/aaf0c312-b425-4910-a568-48e356b81714/runs/ffe8e70a-35bd-4ae4-bed8-85bd71130e51/workspace/open/src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp: In member function 'void C1_MacroAssembler::save_profile_rng()':
[2025-12-04T13:35:07,965Z] /opt/mach5/mesos/work_dir/slaves/da1065b5-7b94-4f0d-85e9-a3a252b9a32e-S11677/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/aaf0c312-b425-4910-a568-48e356b81714/runs/ffe8e70a-35bd-4ae4-bed8-85bd71130e51/workspace/open/src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp:302:54: error: 'profile_rng_offset' is not a member of 'JavaThread'
[2025-12-04T13:35:07,965Z]   302 |     strw(r_profile_rng, Address(rthread, JavaThread::profile_rng_offset()));
[2025-12-04T13:35:07,965Z]       |                                                      ^~~~~~~~~~~~~~~~~~
[2025-12-04T13:35:07,965Z] /opt/mach5/mesos/work_dir/slaves/da1065b5-7b94-4f0d-85e9-a3a252b9a32e-S11677/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/aaf0c312-b425-4910-a568-48e356b81714/runs/ffe8e70a-35bd-4ae4-bed8-85bd71130e51/workspace/open/src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp: In member function 'void C1_MacroAssembler::restore_profile_rng()':
[2025-12-04T13:35:07,965Z] /opt/mach5/mesos/work_dir/slaves/da1065b5-7b94-4f0d-85e9-a3a252b9a32e-S11677/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/aaf0c312-b425-4910-a568-48e356b81714/runs/ffe8e70a-35bd-4ae4-bed8-85bd71130e51/workspace/open/src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp:308:54: error: 'profile_rng_offset' is not a member of 'JavaThread'
[2025-12-04T13:35:07,965Z]   308 |     ldrw(r_profile_rng, Address(rthread, JavaThread::profile_rng_offset()));
[2025-12-04T13:35:07,965Z]       |                                                      ^~~~~~~~~~~~~~~~~~
[2025-12-04T13:35:07,965Z] * For target hotspot_variant-server_libjvm_objs_static_c1_MacroAssembler_aarch64.o:
[2025-12-04T13:35:07,965Z] /opt/mach5/mesos/work_dir/slaves/da1065b5-7b94-4f0d-85e9-a3a252b9a32e-S11677/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/aaf0c312-b425-4910-a568-48e356b81714/runs/ffe8e70a-35bd-4ae4-bed8-85bd71130e51/workspace/open/src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp: In member function 'void C1_MacroAssembler::save_profile_rng()':
[2025-12-04T13:35:07,966Z] /opt/mach5/mesos/work_dir/slaves/da1065b5-7b94-4f0d-85e9-a3a252b9a32e-S11677/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/aaf0c312-b425-4910-a568-48e356b81714/runs/ffe8e70a-35bd-4ae4-bed8-85bd71130e51/workspace/open/src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp:302:54: error: 'profile_rng_offset' is not a member of 'JavaThread'
[2025-12-04T13:35:07,966Z]   302 |     strw(r_profile_rng, Address(rthread, JavaThread::profile_rng_offset()));
[2025-12-04T13:35:07,966Z]       |                                                      ^~~~~~~~~~~~~~~~~~
[2025-12-04T13:35:07,966Z] /opt/mach5/mesos/work_dir/slaves/da1065b5-7b94-4f0d-85e9-a3a252b9a32e-S11677/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/aaf0c312-b425-4910-a568-48e356b81714/runs/ffe8e70a-35bd-4ae4-bed8-85bd71130e51/workspace/open/src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp: In member function 'void C1_MacroAssembler::restore_profile_rng()':
[2025-12-04T13:35:07,966Z] /opt/mach5/mesos/work_dir/slaves/da1065b5-7b94-4f0d-85e9-a3a252b9a32e-S11677/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/aaf0c312-b425-4910-a568-48e356b81714/runs/ffe8e70a-35bd-4ae4-bed8-85bd71130e51/workspace/open/src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp:308:54: error: 'profile_rng_offset' is not a member of 'JavaThread'
[2025-12-04T13:35:07,966Z]   308 |     ldrw(r_profile_rng, Address(rthread, JavaThread::profile_rng_offset()));
[2025-12-04T13:35:07,966Z]       |                                                      ^~~~~~~~~~~~~~~~~~
[2025-12-04T13:35:07,966Z]

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

PR Comment: https://git.openjdk.org/jdk/pull/28541#issuecomment-3612317449

From stuefe at openjdk.org  Thu Dec  4 14:06:20 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 4 Dec 2025 14:06:20 GMT
Subject: RFR: 8363996: Obsolete UseCompressedClassPointers [v3]
In-Reply-To: <3GE775UHXUoDMOLKl9C7Ao52gXf3U-_cfiC5ruJBz2w=.66997f1e-6dce-4803-903a-a787b3496183@github.com>
References: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
 <iuFGPYMntccuF67iSGdqenHob1nhmj2NEzrzPUbIgmk=.4a1423df-c614-4549-93d6-35b3c4f7220d@github.com>
 <3GE775UHXUoDMOLKl9C7Ao52gXf3U-_cfiC5ruJBz2w=.66997f1e-6dce-4803-903a-a787b3496183@github.com>
Message-ID: <lfHCfh2PtXvaUswzDZ5ULos9ZqE36oFOhBdKJoAZuVk=.d161792a-ab19-4a9e-a557-4a80f877e4ae@github.com>

On Thu, 4 Dec 2025 12:03:25 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply suggestion from @theRealAph
>>   
>>   Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>
>
> src/hotspot/share/cds/aotMappedHeapLoader.hpp line 55:
> 
>> 53:   static bool can_use() { return can_map() || can_load(); }
>> 54: 
>> 55:   // Can this VM map archived heap region? Currently only G1+compressed{oops,cp}
> 
> Suggestion:
> 
>   // Can this VM map archived heap region? Currently only G1.

After thinking about this, I got confused. Should heap archiving not actually depend on CompressedOops, too, in addition to CompressedClassPointers? Otherwise we would have the heap region at runtime at exactly the same address as at compile time...

That would be a preexisting bug. It may just be one of the old "UseCompressedClassPointers is tied to UseCompressedOops" bugs. But if true, we would have seen CDT crashes e.g. with G1 and heaps > 32g.

I'll take a look.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2589215456

From coleenp at openjdk.org  Thu Dec  4 14:23:16 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 4 Dec 2025 14:23:16 GMT
Subject: RFR: 8366671: Refactor Thread::SpinAcquire and Thread::SpinRelease
 [v12]
In-Reply-To: <BLbZykwmGPMfOyN0A7lrjaht-OWDbWK9_ArQRZZTVCU=.4bbd7292-3028-44f2-b0a5-cb4f29c2044b@github.com>
References: <NtY8E8fBeSokCAQYP3OQEwfnppSugtTJ8uAtQtD0zvg=.88f2988d-47fd-4b8a-af89-488ed6b37870@github.com>
 <BLbZykwmGPMfOyN0A7lrjaht-OWDbWK9_ArQRZZTVCU=.4bbd7292-3028-44f2-b0a5-cb4f29c2044b@github.com>
Message-ID: <-gTmPQQN2W8rHqHxqGFNj4Z-aTMTgt4HQXM34lOQicM=.646804e9-b052-4eb4-9485-3de322be9b8e@github.com>

On Wed, 3 Dec 2025 14:04:28 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, 
>> 
>> please consider the following changes:
>> 
>> In this PR `Thread::SpinAcquire()` and `Thread::SpinRelease()` methods are refactored into a utility class `SpinCriticalSection`. The motivation is to make it easier for developers to use this lightweight synchronization mechanism in the codebase. The two aforementioned methods were used in JFR to create short critical sections with a helper class, but that was not the case for the object monitor code. 
>> 
>> Tested in tiers 1 - 5.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8366671: Added NoSafepointVerifier

src/hotspot/share/runtime/objectMonitor.cpp line 2056:

> 2054:       // there is nothing to do.
> 2055:       if (old_state == java_lang_VirtualThread::WAIT ||
> 2056:         old_state == java_lang_VirtualThread::TIMED_WAIT) {

Suggestion:

          old_state == java_lang_VirtualThread::TIMED_WAIT) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28264#discussion_r2589278239

From fthevenet at openjdk.org  Thu Dec  4 14:26:29 2025
From: fthevenet at openjdk.org (Frederic Thevenet)
Date: Thu, 4 Dec 2025 14:26:29 GMT
Subject: RFR: 8253683: Clean up and clarify uses of
 os::vm_allocation_granularity
In-Reply-To: <t1YFEQDP7_gQO-1SGvGRjAMbVE4nVs5a9wMFJtB0DOs=.a44ce263-642c-42cf-8135-dd0121ce24ce@github.com>
References: <t1YFEQDP7_gQO-1SGvGRjAMbVE4nVs5a9wMFJtB0DOs=.a44ce263-642c-42cf-8135-dd0121ce24ce@github.com>
Message-ID: <hE4UfcTf6NW-N6J0t4wXUOT5ONo-1C7Z9FvL3HX1nt8=.146e9294-7d9a-4567-a136-6ea0b4270254@github.com>

On Tue, 25 Nov 2025 14:31:39 GMT, Casper Norrbin <cnorrbin at openjdk.org> 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

Please note that  I am not a formal reviewer for the JDK project, but I thought I'd chip in and do some of the leg work. I hope this is useful.

src/hotspot/os/posix/os_posix.cpp line 458:

> 456: 
> 457: static size_t calculate_aligned_extra_size(size_t size, size_t alignment) {
> 458:   assert(is_aligned(alignment, os::vm_allocation_granularity()),

Shouldn't `alignment` be checked as  a multiple of page size rather than alloc granularity as well?
I don't see it being used for aligning an address.

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)

src/hotspot/share/jfr/recorder/storage/jfrVirtualMemory.cpp line 117:

> 115:   assert(_rs.size() != 0, "invariant");
> 116:   assert(is_aligned(_rs.base(), os::vm_allocation_granularity()), "invariant");
> 117:   assert(is_aligned(_rs.size(), os::vm_page_size()), "invariant");

The assert at line 117 is now redundant with the one done at 125.
AFAICT, neither `os::trace_page_sizes` nor `MemTracker::record_virtual_memory_tag`  have side effects that could affect `_rs.size()`, so line 125 could probably be removed.

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

PR Review: https://git.openjdk.org/jdk/pull/28493#pullrequestreview-3534618037
PR Review Comment: https://git.openjdk.org/jdk/pull/28493#discussion_r2585008814
PR Review Comment: https://git.openjdk.org/jdk/pull/28493#discussion_r2584750844
PR Review Comment: https://git.openjdk.org/jdk/pull/28493#discussion_r2588354727

From fthevenet at openjdk.org  Thu Dec  4 14:26:31 2025
From: fthevenet at openjdk.org (Frederic Thevenet)
Date: Thu, 4 Dec 2025 14:26:31 GMT
Subject: RFR: 8253683: Clean up and clarify uses of
 os::vm_allocation_granularity
In-Reply-To: <hE4UfcTf6NW-N6J0t4wXUOT5ONo-1C7Z9FvL3HX1nt8=.146e9294-7d9a-4567-a136-6ea0b4270254@github.com>
References: <t1YFEQDP7_gQO-1SGvGRjAMbVE4nVs5a9wMFJtB0DOs=.a44ce263-642c-42cf-8135-dd0121ce24ce@github.com>
 <hE4UfcTf6NW-N6J0t4wXUOT5ONo-1C7Z9FvL3HX1nt8=.146e9294-7d9a-4567-a136-6ea0b4270254@github.com>
Message-ID: <VTSRzWMTusy7pNm2nYJFFRdJj7uQ1yw8I_mp_ctK6Ek=.b6f1cef1-da16-4271-9261-a803accdc383@github.com>

On Thu, 4 Dec 2025 10:03:05 GMT, Frederic Thevenet <fthevenet at openjdk.org> 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/share/jfr/recorder/storage/jfrVirtualMemory.cpp line 117:
> 
>> 115:   assert(_rs.size() != 0, "invariant");
>> 116:   assert(is_aligned(_rs.base(), os::vm_allocation_granularity()), "invariant");
>> 117:   assert(is_aligned(_rs.size(), os::vm_page_size()), "invariant");
> 
> The assert at line 117 is now redundant with the one done at 125.
> AFAICT, neither `os::trace_page_sizes` nor `MemTracker::record_virtual_memory_tag`  have side effects that could affect `_rs.size()`, so line 125 could probably be removed.

Although this is not a change made by this PR, I'm a bit puzzled by the need to first assert `_rs.base()` is aligned on `vm_allocation_granularity` at 116 and then on `vm_page_size` at 124; is this needed? Should we attempt to maybe clarify that as part of this PR?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28493#discussion_r2588357427

From clanger at openjdk.org  Thu Dec  4 14:27:35 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 4 Dec 2025 14:27:35 GMT
Subject: RFR: 8351842: Windows specific issues in combination of JEP 493
 and --with-external-symbols-in-bundles=public [v7]
In-Reply-To: <GmCc0zKQhuTx4s7vzyjFA2gztgss7VxwcAFOUkw8ifw=.c4f69a8c-1407-45d7-a17f-59e1af2578f8@github.com>
References: <R-zg2t6gMm9oZgSijkRxJ0ErqtvoFeqPyfUGbhZRkEQ=.17b0ed93-ea7b-4a37-8471-12624c937a71@github.com>
 <GmCc0zKQhuTx4s7vzyjFA2gztgss7VxwcAFOUkw8ifw=.c4f69a8c-1407-45d7-a17f-59e1af2578f8@github.com>
Message-ID: <R93W9QTAn0O78EY6A6UQpb1T4a6YBxY1-tr6fIIz0pE=.b105325d-0a1a-4e3c-ac33-7fd128ffe029@github.com>

On Wed, 3 Dec 2025 09:54:38 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> This PR addresses an issue that can be observed when building on Windows with configure options `--enable-linkable-runtime` and `--with-external-symbols-in-bundles=public`.
>> 
>> The problem is that with this special build configuration, we build two sets of .pdb files for the binaries. The first set is the standard debug symbols files named <binary-name>.pdb. The second set consists of stripped debug symbols file called <binary-name>.stripped.pdb which have less information but enough to present line numbers in hs-err files.
>> 
>> During build we use the *.stripped.pdb files for compiling the jmods and also the bundle files. However, in the images folder, both sets of .pdb files exist. The tests for runtime linking will now, in the absence of jmod files, pick up the .pdb files (without *stripped*) from images, but in the runtime the hashes of the *stripped* files are stored.
>> 
>> With this change, the standard .pdb files in the `--with-external-symbols-in-bundles=public` configuration are now the stripped files and we create a set of full pdb files named *.full.pdb. Jmods and Bundles still contain the stripped pdb files and we also fix the issue that the debug symbols bundle also contained stripped pdb files so far. With this fix, it will contain the full pdb files and extracting these over a JDK runtime will replace stripped pdbs with full pdbs.
>
> Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/24012#issuecomment-3612510925

From aph at openjdk.org  Thu Dec  4 14:43:06 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 4 Dec 2025 14:43:06 GMT
Subject: RFR: 8363996: Obsolete UseCompressedClassPointers [v3]
In-Reply-To: <lfHCfh2PtXvaUswzDZ5ULos9ZqE36oFOhBdKJoAZuVk=.d161792a-ab19-4a9e-a557-4a80f877e4ae@github.com>
References: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
 <iuFGPYMntccuF67iSGdqenHob1nhmj2NEzrzPUbIgmk=.4a1423df-c614-4549-93d6-35b3c4f7220d@github.com>
 <3GE775UHXUoDMOLKl9C7Ao52gXf3U-_cfiC5ruJBz2w=.66997f1e-6dce-4803-903a-a787b3496183@github.com>
 <lfHCfh2PtXvaUswzDZ5ULos9ZqE36oFOhBdKJoAZuVk=.d161792a-ab19-4a9e-a557-4a80f877e4ae@github.com>
Message-ID: <UKw0Cjnfcefhae0F3zEJibzhwFYeZSNX59dqtPgB1bQ=.1eeae023-03b4-4ca2-a82c-e1e8107d032a@github.com>

On Thu, 4 Dec 2025 14:03:26 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/share/cds/aotMappedHeapLoader.hpp line 55:
>> 
>>> 53:   static bool can_use() { return can_map() || can_load(); }
>>> 54: 
>>> 55:   // Can this VM map archived heap region? Currently only G1+compressed{oops,cp}
>> 
>> Suggestion:
>> 
>>   // Can this VM map archived heap region? Currently only G1.
>
> After thinking about this, I got confused. Should heap archiving not actually depend on CompressedOops, too, in addition to CompressedClassPointers? Otherwise we would have the heap region at runtime at exactly the same address as at compile time...
> 
> That would be a preexisting bug. It may just be one of the old "UseCompressedClassPointers is tied to UseCompressedOops" bugs. But if true, we would have seen CDT crashes e.g. with G1 and heaps > 32g.
> 
> I'll take a look.

Sorry, my mistake. Just compressed CP. Maybe just delete the comment, which violates

Rule 1: Comments should not duplicate the code

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2589349492

From stuefe at openjdk.org  Thu Dec  4 15:04:51 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 4 Dec 2025 15:04:51 GMT
Subject: RFR: 8363996: Obsolete UseCompressedClassPointers [v3]
In-Reply-To: <UKw0Cjnfcefhae0F3zEJibzhwFYeZSNX59dqtPgB1bQ=.1eeae023-03b4-4ca2-a82c-e1e8107d032a@github.com>
References: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
 <iuFGPYMntccuF67iSGdqenHob1nhmj2NEzrzPUbIgmk=.4a1423df-c614-4549-93d6-35b3c4f7220d@github.com>
 <3GE775UHXUoDMOLKl9C7Ao52gXf3U-_cfiC5ruJBz2w=.66997f1e-6dce-4803-903a-a787b3496183@github.com>
 <lfHCfh2PtXvaUswzDZ5ULos9ZqE36oFOhBdKJoAZuVk=.d161792a-ab19-4a9e-a557-4a80f877e4ae@github.com>
 <UKw0Cjnfcefhae0F3zEJibzhwFYeZSNX59dqtPgB1bQ=.1eeae023-03b4-4ca2-a82c-e1e8107d032a@github.com>
Message-ID: <6t_cgEV2UcFEf5C148g7aIj9AObCmwJI_YMfJ_s7VUs=.6681d5cc-4c69-46dd-9d17-89a2d2d723ea@github.com>

On Thu, 4 Dec 2025 14:39:39 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> After thinking about this, I got confused. Should heap archiving not actually depend on CompressedOops, too, in addition to CompressedClassPointers? Otherwise we would have the heap region at runtime at exactly the same address as at compile time...
>> 
>> That would be a preexisting bug. It may just be one of the old "UseCompressedClassPointers is tied to UseCompressedOops" bugs. But if true, we would have seen CDT crashes e.g. with G1 and heaps > 32g.
>> 
>> I'll take a look.
>
> Sorry, my mistake. Just compressed CP. Maybe just delete the comment, which violates
> 
> Rule 1: Comments should not duplicate the code

Ashu just reminded me that we do relocate uncompressed oops when loading the CDS archive at runtime. We never got around to do that for uncompressed Klass pointers in object headers, and it was also never really necessary.

So you are right, the comment should either just be removed or explain the G1 restriction.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2589430925

From clanger at openjdk.org  Thu Dec  4 15:09:00 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 4 Dec 2025 15:09:00 GMT
Subject: Integrated: 8351842: Windows specific issues in combination of JEP 493
 and --with-external-symbols-in-bundles=public
In-Reply-To: <R-zg2t6gMm9oZgSijkRxJ0ErqtvoFeqPyfUGbhZRkEQ=.17b0ed93-ea7b-4a37-8471-12624c937a71@github.com>
References: <R-zg2t6gMm9oZgSijkRxJ0ErqtvoFeqPyfUGbhZRkEQ=.17b0ed93-ea7b-4a37-8471-12624c937a71@github.com>
Message-ID: <vL8Ngy9-zpYrFWAwb1dFk4sn__kaD-xjt28hCcipgGc=.9f45b1b6-6955-4320-8c0c-f1f42b5fe3fa@github.com>

On Wed, 12 Mar 2025 15:57:40 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> This PR addresses an issue that can be observed when building on Windows with configure options `--enable-linkable-runtime` and `--with-external-symbols-in-bundles=public`.
> 
> The problem is that with this special build configuration, we build two sets of .pdb files for the binaries. The first set is the standard debug symbols files named <binary-name>.pdb. The second set consists of stripped debug symbols file called <binary-name>.stripped.pdb which have less information but enough to present line numbers in hs-err files.
> 
> During build we use the *.stripped.pdb files for compiling the jmods and also the bundle files. However, in the images folder, both sets of .pdb files exist. The tests for runtime linking will now, in the absence of jmod files, pick up the .pdb files (without *stripped*) from images, but in the runtime the hashes of the *stripped* files are stored.
> 
> With this change, the standard .pdb files in the `--with-external-symbols-in-bundles=public` configuration are now the stripped files and we create a set of full pdb files named *.full.pdb. Jmods and Bundles still contain the stripped pdb files and we also fix the issue that the debug symbols bundle also contained stripped pdb files so far. With this fix, it will contain the full pdb files and extracting these over a JDK runtime will replace stripped pdbs with full pdbs.

This pull request has now been integrated.

Changeset: 33dda887
Author:    Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/33dda887d99d39b2d003fd6521db97d45da474f0
Stats:     102 lines in 7 files changed: 35 ins; 46 del; 21 mod

8351842: Windows specific issues in combination of JEP 493 and --with-external-symbols-in-bundles=public

Reviewed-by: erikj, mbaesken

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

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

From vlivanov at openjdk.org  Thu Dec  4 19:17:29 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 4 Dec 2025 19:17:29 GMT
Subject: RFR: 8357258: x86: Improve receiver type profiling reliability
 [v8]
In-Reply-To: <avqNAcH5MpUoM31mrtm0Z6qnPqpgbpGszW01AtFbYXk=.359b8088-c0b5-4a01-aefc-fe3c02bdd60a@github.com>
References: <X9RJoDWqk67MlK7P4ACCbzROxLkfEqvU0zDid3zymnc=.7c0086a3-f514-4b0d-8bc0-592bf4a05bba@github.com>
 <avqNAcH5MpUoM31mrtm0Z6qnPqpgbpGszW01AtFbYXk=.359b8088-c0b5-4a01-aefc-fe3c02bdd60a@github.com>
Message-ID: <dEG0Z-h_AKU79xlcWa3tyWqbMZSFqm9m6vEKl19JlBo=.deff71db-d617-4df9-8aa0-7242875b666c@github.com>

On Tue, 2 Dec 2025 10:31:22 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the bug for discussion what issues current machinery has. 
>> 
>> This PR executes the plan outlined in the bug:
>>  1. Common the receiver type profiling code in interpreter and C1
>>  2. Rewrite receiver type profiling code to only do atomic receiver slot installations
>>  3. Trim `C1OptimizeVirtualCallProfiling` to only claim slots when receiver is installed 
>> 
>> This PR does _not_ do atomic counter updates themselves, as it may have much wider performance implications, including regressions. This PR should be at least performance neutral.
>> 
>> Additional testing:
>>   - [x] Linux x86_64 server fastdebug, `compiler/`
>>   - [x] Linux x86_64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:
> 
>  - 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
>  - Offset is always rscratch1, no need to save it
>  - Grossly simplify register shuffling
>  - ... and 11 more: https://git.openjdk.org/jdk/compare/7278d2e8...3c5019d9

Overall, looks good to me. Nice work, Aleksey!

I'm curious how performance-sensitive that part of code is. Does it make sense to try to further optimize it?

For example:
  - 2 slots is the most common case; any benefits from optimizing specifically for it (e.g., unroll the loops)?
  -  fast path can be further optimized for no nulls case by offloading more work on found_null slow path [1]

[1]

    // Fastest: receiver is already installed
    int i = 0;
    for (; i < receiver_count(); i++) {
      if (receiver(i) == recv) goto found_recv(i);
      if (receiver(i) == null) goto found_null(i);
    }
  
    goto polymorphic
  
    // Slow: try to install receiver
  found_null(i):
    // Finish the search
    for (int j = i ; j < receiver_count(); j++) {
      if (receiver(j) == recv) goto found_recv(j);
    }
    CAS(&receiver(i), null, recv);
    goto restart
...

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

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

From dholmes at openjdk.org  Thu Dec  4 19:36:05 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 4 Dec 2025 19:36:05 GMT
Subject: RFR: 8366671: Refactor Thread::SpinAcquire and Thread::SpinRelease
 [v12]
In-Reply-To: <N7vHuN5b9KhsJe530nxvGwy7s0hbswRiro-oOmumsME=.5b461e49-6609-4f64-92c6-21e7186b1258@github.com>
References: <NtY8E8fBeSokCAQYP3OQEwfnppSugtTJ8uAtQtD0zvg=.88f2988d-47fd-4b8a-af89-488ed6b37870@github.com>
 <BLbZykwmGPMfOyN0A7lrjaht-OWDbWK9_ArQRZZTVCU=.4bbd7292-3028-44f2-b0a5-cb4f29c2044b@github.com>
 <204L9XlL2bBMtfNvqWuvXgBdUfR04jt6-NrWFCzfR7A=.5d3b8c34-2949-4707-b26b-ee57c4546ead@github.com>
 <N7vHuN5b9KhsJe530nxvGwy7s0hbswRiro-oOmumsME=.5b461e49-6609-4f64-92c6-21e7186b1258@github.com>
Message-ID: <IBR6hBctgnAQHcdf35T_1kmGMUb2ZbxpKlYiZrAOHRo=.0455b947-2c7e-4965-b4d0-82020b3c2d1e@github.com>

On Thu, 4 Dec 2025 12:33:02 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/utilities/spinCriticalSection.hpp line 46:
>> 
>>> 44:   // compared to  smaller/larger types.
>>> 45:   volatile int* const _lock;
>>> 46:   DEBUG_ONLY(NoSafepointVerifier _nsv;)
>> 
>> I thought NSV had to be used as a StackObj ?? I don't understand why it is a field of SCS.
>
> It can be a field of a StackObj too.

Okay, yes I misunderstand the purpose here. We want the NSV covering the critical section, not just the code of the SCS.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28264#discussion_r2590322392

From dholmes at openjdk.org  Thu Dec  4 19:40:02 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 4 Dec 2025 19:40:02 GMT
Subject: RFR: 8366671: Refactor Thread::SpinAcquire and Thread::SpinRelease
 [v12]
In-Reply-To: <BLbZykwmGPMfOyN0A7lrjaht-OWDbWK9_ArQRZZTVCU=.4bbd7292-3028-44f2-b0a5-cb4f29c2044b@github.com>
References: <NtY8E8fBeSokCAQYP3OQEwfnppSugtTJ8uAtQtD0zvg=.88f2988d-47fd-4b8a-af89-488ed6b37870@github.com>
 <BLbZykwmGPMfOyN0A7lrjaht-OWDbWK9_ArQRZZTVCU=.4bbd7292-3028-44f2-b0a5-cb4f29c2044b@github.com>
Message-ID: <Z0c-dWNWbxGumcLpse7-H3fGuAI5h9XBdu9bsJdRGeA=.bf035f09-aedf-401a-bf6d-90cf2568d48c@github.com>

On Wed, 3 Dec 2025 14:04:28 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, 
>> 
>> please consider the following changes:
>> 
>> In this PR `Thread::SpinAcquire()` and `Thread::SpinRelease()` methods are refactored into a utility class `SpinCriticalSection`. The motivation is to make it easier for developers to use this lightweight synchronization mechanism in the codebase. The two aforementioned methods were used in JFR to create short critical sections with a helper class, but that was not the case for the object monitor code. 
>> 
>> Tested in tiers 1 - 5.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8366671: Added NoSafepointVerifier

src/hotspot/share/utilities/spinCriticalSection.hpp line 54:

> 52:   SpinCriticalSection(volatile int* lock)
> 53:     : _lock(lock)
> 54:       DEBUG_ONLY(COMMA _nsv(Thread::current_or_null_safe() != nullptr)) {

So we need to allow for null because this can be called early in VM init whilst the main thread is still attaching, but why do we need the "safe" variant? That is only for code that can be executed in a signal handling context

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28264#discussion_r2590332917

From ayang at openjdk.org  Thu Dec  4 19:46:35 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 4 Dec 2025 19:46:35 GMT
Subject: RFR: 8370198: Test gc/arguments/TestShrinkHeapInSteps.java
 crashed:  assert(left >= right) failed: avoid underflow [v4]
In-Reply-To: <WKjyigvXghJNT-bijIBX8dyE1cdd3GsubdHvrNrYHyM=.dedfb4bc-b098-4d8f-8f5a-291d92fe9f2d@github.com>
References: <WKjyigvXghJNT-bijIBX8dyE1cdd3GsubdHvrNrYHyM=.dedfb4bc-b098-4d8f-8f5a-291d92fe9f2d@github.com>
Message-ID: <InyhuhR_Me5U37VRtH0OrcP2KrkaF_Il4WLvbPu6Mbk=.0982a838-b55a-488e-abca-65c77f37f34b@github.com>

> Add an early-return for outside-heap address in `CollectedHeap::is_in` API.
> 
> While investigating this failure (JDK-8370198), I realized that some java-threads (compiler-threads) in `native` state can invoke `CollectedHeap` APIs. Since heap-resizing occurs inside safepoint but java-threads in `native` state just ignore safepoint, I have added some assert to catch such dangerous uses, where the return value might not be stable.
> 
> Test: tie1-5; can't reproduce the JDK-8370198 with or without this patch for >8000 runs.

Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:

  review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28393/files
  - new: https://git.openjdk.org/jdk/pull/28393/files/1a7bbae0..40ee3859

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

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

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

From dlong at openjdk.org  Thu Dec  4 20:14:32 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 4 Dec 2025 20:14:32 GMT
Subject: RFR: 8347396: Efficient TypeFunc creations [v3]
In-Reply-To: <da-a4Id_azWgrrTjDQEeYR6rm4D2l5jZAHIMx9x4v4w=.38b3a577-a776-49c4-8afb-27c684c126ad@github.com>
References: <VQs3SMtk1y6xTi8nCvTeWsTFfCQlTJtDdCGnfWQmRmw=.f3b33ba1-3efe-477b-b6d2-b43faae9ee2b@github.com>
 <da-a4Id_azWgrrTjDQEeYR6rm4D2l5jZAHIMx9x4v4w=.38b3a577-a776-49c4-8afb-27c684c126ad@github.com>
Message-ID: <7OlfD2Jc5Vu7a8x_QmCuDONR_u7AjPQJwqeTJLkAzR0=.723e9b17-44c2-4982-a54c-5b0bc07f3f81@github.com>

On Wed, 3 Dec 2025 08:37:02 GMT, Harshit470250 <duke at openjdk.org> 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 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

Do you have a branch that reproduces the problem, so I can take a look?

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

PR Comment: https://git.openjdk.org/jdk/pull/27279#issuecomment-3614148857

From eastigeevich at openjdk.org  Thu Dec  4 21:16:26 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Thu, 4 Dec 2025 21:16:26 GMT
Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact
 on GCs and JIT performance [v13]
In-Reply-To: <Kl5e4lLy09In3ii23YLueZVqzzzkBkZJLGAJb2k7Aio=.4347ba54-eb6b-4a9f-81e8-6db06a03824f@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
 <rtneArX_lMKv-UqOQNXv8DT_n8pY4UNn7nEE4FpKT4k=.ca641bc2-9d9a-4e0b-a329-da375913f5db@github.com>
 <Kl5e4lLy09In3ii23YLueZVqzzzkBkZJLGAJb2k7Aio=.4347ba54-eb6b-4a9f-81e8-6db06a03824f@github.com>
Message-ID: <7IU85M4fl7Hk58g_oBLgw5g9QEHDhmSCLN6K5IhH9YQ=.46291089-efb6-432f-ac17-3480200c494a@github.com>

On Wed, 3 Dec 2025 15:54:24 GMT, Aleksey Shipilev <shade at openjdk.org> 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
>
> src/hotspot/share/asm/codeBuffer.cpp line 371:
> 
>> 369:       !((oop_Relocation*)reloc)->oop_is_immediate()) {
>> 370:     _has_non_immediate_oops = true;
>> 371:   }
> 
> Honestly, this looks fragile? We can go into nmethods patching for some other reason, not for patching oops.
> 
> Also, we still might need to go and patch immediate oops? I see this:
> 
> 
>   // Instruct loadConP of x86_64.ad places oops in code that are not also
>   // listed in the oop section.
>   static bool mustIterateImmediateOopsInCode() { return true; }
> 
> 
> Is there a substantial loss is doing icache invalidation without checking for the existence of interesting oops? Do you have an idea how many methods this filters?

@shipilev 
Moving `ICacheInvalidationContext icic` to `nmethod::fix_oop_relocations` works. The fragile code is no more needed.

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

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

From kvn at openjdk.org  Thu Dec  4 21:49:06 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 4 Dec 2025 21:49:06 GMT
Subject: RFR: 8357258: x86: Improve receiver type profiling reliability
 [v8]
In-Reply-To: <dEG0Z-h_AKU79xlcWa3tyWqbMZSFqm9m6vEKl19JlBo=.deff71db-d617-4df9-8aa0-7242875b666c@github.com>
References: <X9RJoDWqk67MlK7P4ACCbzROxLkfEqvU0zDid3zymnc=.7c0086a3-f514-4b0d-8bc0-592bf4a05bba@github.com>
 <avqNAcH5MpUoM31mrtm0Z6qnPqpgbpGszW01AtFbYXk=.359b8088-c0b5-4a01-aefc-fe3c02bdd60a@github.com>
 <dEG0Z-h_AKU79xlcWa3tyWqbMZSFqm9m6vEKl19JlBo=.deff71db-d617-4df9-8aa0-7242875b666c@github.com>
Message-ID: <463CgW4WDJnmLWha1DJLYIWw_UEh4ba9vdeQq80QfJM=.08d3125b-f5cd-4d29-8e0d-921448c792f2@github.com>

On Thu, 4 Dec 2025 19:14:43 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> 2 slots is the most common case; any benefits from optimizing specifically for it (e.g., unroll the loops)?

Yes, since `row_limit()` is statically know and does not change we can have two versions of code based on its value:
  - `<= 2` slots: fully unrolled (much less instructions)
  - `> 2` slots: current proposed code

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

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

From kvn at openjdk.org  Thu Dec  4 21:56:46 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 4 Dec 2025 21:56:46 GMT
Subject: RFR: 8357258: x86: Improve receiver type profiling reliability
 [v8]
In-Reply-To: <dEG0Z-h_AKU79xlcWa3tyWqbMZSFqm9m6vEKl19JlBo=.deff71db-d617-4df9-8aa0-7242875b666c@github.com>
References: <X9RJoDWqk67MlK7P4ACCbzROxLkfEqvU0zDid3zymnc=.7c0086a3-f514-4b0d-8bc0-592bf4a05bba@github.com>
 <avqNAcH5MpUoM31mrtm0Z6qnPqpgbpGszW01AtFbYXk=.359b8088-c0b5-4a01-aefc-fe3c02bdd60a@github.com>
 <dEG0Z-h_AKU79xlcWa3tyWqbMZSFqm9m6vEKl19JlBo=.deff71db-d617-4df9-8aa0-7242875b666c@github.com>
Message-ID: <PN__c7hAh4MrWJ8OaxzJ4gBbqTwCGW537nC4XuRiF-o=.d0fabeb9-0466-45a5-88bb-7c91d27bf1a4@github.com>

On Thu, 4 Dec 2025 19:14:43 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> fast path can be further optimized for no nulls case by offloading more work on found_null slow path [1]

I don't think we need to optimize `> 2` slots case. Such setting is not current default. Also based on @shipilev comments 2 separate loops is more or less optimal.

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

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

From asmehra at openjdk.org  Thu Dec  4 22:33:34 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Thu, 4 Dec 2025 22:33:34 GMT
Subject: RFR: 8373114: Redundant MethodCounters in the preimage generated by
 training run
Message-ID: <LRw06Cn_4dcRW8YyFVr3RijMHIha7nPzBrcNNzaIny8=.dc07d0ee-b797-4434-aad0-956a00c2ea6f@github.com>

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

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

Commit messages:
 - 8373114: Redundant MethodCounters in the preimage generated by training run

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

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

From asmehra at openjdk.org  Thu Dec  4 22:37:46 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Thu, 4 Dec 2025 22:37:46 GMT
Subject: RFR: 8373114: Redundant MethodCounters in the preimage generated
 by training run
In-Reply-To: <LRw06Cn_4dcRW8YyFVr3RijMHIha7nPzBrcNNzaIny8=.dc07d0ee-b797-4434-aad0-956a00c2ea6f@github.com>
References: <LRw06Cn_4dcRW8YyFVr3RijMHIha7nPzBrcNNzaIny8=.dc07d0ee-b797-4434-aad0-956a00c2ea6f@github.com>
Message-ID: <4bklYUCt-566y9y9DEncz2d8W8U23wAdXHVn9vIoYqY=.2a140834-9ffd-4bbf-82ef-4767ae1862f7@github.com>

On Thu, 4 Dec 2025 22:16:03 GMT, Ashutosh Mehra <asmehra at openjdk.org> 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

I did a force-push to fix the bug id in the commit message.

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

PR Comment: https://git.openjdk.org/jdk/pull/28670#issuecomment-3614593351

From coleenp at openjdk.org  Thu Dec  4 22:43:51 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 4 Dec 2025 22:43:51 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v8]
In-Reply-To: <HOlXGoe8-oMYP_mCYb_xxO9F13ji624MlCfQ3-_zebM=.6240c45e-bf23-4799-b9c2-175460afa2d5@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
 <HOlXGoe8-oMYP_mCYb_xxO9F13ji624MlCfQ3-_zebM=.6240c45e-bf23-4799-b9c2-175460afa2d5@github.com>
Message-ID: <EzHVGdHIdqSRsFlzhFFOHeYYVsNWXu6lXWJYhJAPV_I=.b905813d-a2ef-4b73-87dc-9317509be561@github.com>

On Wed, 3 Dec 2025 13:17:45 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> ArrayKlass doesn't set AccessFlags so don't look for them there.  See CR for details.
>> Fixed SA and jvmci.  @iwanowww Can you check that I changed C2 correctly (we talked about this in August).
>> Tested with tier1-4.  5-7 in progress.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Take out ?: for array classes in set_raw_access_flags call.

Thanks for reviewing and your help, Vladimir, Dean, Chen and Serguei.

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

PR Comment: https://git.openjdk.org/jdk/pull/28371#issuecomment-3614608117

From coleenp at openjdk.org  Thu Dec  4 22:43:52 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 4 Dec 2025 22:43:52 GMT
Subject: Integrated: 8372098: Move AccessFlags to InstanceKlass
In-Reply-To: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
Message-ID: <QhjAOtWuWDyJkO-C7PE4GVPIDZrxDfeRRxYgp8D2-zs=.df6180bc-0860-432b-a048-109c8bb2afc3@github.com>

On Tue, 18 Nov 2025 13:27:06 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> ArrayKlass doesn't set AccessFlags so don't look for them there.  See CR for details.
> Fixed SA and jvmci.  @iwanowww Can you check that I changed C2 correctly (we talked about this in August).
> Tested with tier1-4.  5-7 in progress.

This pull request has now been integrated.

Changeset: 13e32bf1
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/13e32bf1667a3be8492d1e4e3a273951202acd9c
Stats:     166 lines in 25 files changed: 75 ins; 59 del; 32 mod

8372098: Move AccessFlags to InstanceKlass

Reviewed-by: liach, vlivanov, dlong, sspitsyn

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

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

From vlivanov at openjdk.org  Thu Dec  4 23:04:57 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 4 Dec 2025 23:04:57 GMT
Subject: RFR: 8373114: Redundant MethodCounters in the preimage generated
 by training run
In-Reply-To: <LRw06Cn_4dcRW8YyFVr3RijMHIha7nPzBrcNNzaIny8=.dc07d0ee-b797-4434-aad0-956a00c2ea6f@github.com>
References: <LRw06Cn_4dcRW8YyFVr3RijMHIha7nPzBrcNNzaIny8=.dc07d0ee-b797-4434-aad0-956a00c2ea6f@github.com>
Message-ID: <agWLS8uUUOXgaeU9ka0naNgVYhtrXSRmF3NkG6jzAbY=.d8e7474f-9b77-4183-99b5-6a62819046eb@github.com>

On Thu, 4 Dec 2025 22:16:03 GMT, Ashutosh Mehra <asmehra at openjdk.org> 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

I'm not an expert in CDS, but the fix doesn't look right. It breaks Metadata traversal CDS relies on. Instead, if you don't want to keep around `MethodCounter`s not linked to MTDs, break the link from `Method` (`Method::_method_counters`) before dumping pre-image and restore it from archived `TrainingDataSet` during assembly phase.

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

PR Comment: https://git.openjdk.org/jdk/pull/28670#issuecomment-3614669752

From asmehra at openjdk.org  Thu Dec  4 23:52:55 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Thu, 4 Dec 2025 23:52:55 GMT
Subject: RFR: 8373114: Redundant MethodCounters in the preimage generated
 by training run
In-Reply-To: <agWLS8uUUOXgaeU9ka0naNgVYhtrXSRmF3NkG6jzAbY=.d8e7474f-9b77-4183-99b5-6a62819046eb@github.com>
References: <LRw06Cn_4dcRW8YyFVr3RijMHIha7nPzBrcNNzaIny8=.dc07d0ee-b797-4434-aad0-956a00c2ea6f@github.com>
 <agWLS8uUUOXgaeU9ka0naNgVYhtrXSRmF3NkG6jzAbY=.d8e7474f-9b77-4183-99b5-6a62819046eb@github.com>
Message-ID: <LU5FoKbfXYJE26LzMgqcNd4H1LXgESe0gQQ8lw4C6aA=.58fdd835-a897-40f1-ac61-61bca374d4a9@github.com>

On Thu, 4 Dec 2025 23:02:05 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> I'm not an expert in CDS, but the fix doesn't look right. It breaks Metadata traversal CDS relies on. Instead, if you don't want to keep around MethodCounters not linked to MTDs, break the link from Method (Method::_method_counters) before dumping pre-image and restore it from archived TrainingDataSet during assembly phase.

Right, this is not the correct fix. It breaks the Method->MethodCounters link for all the methods. We need to preserve the links for the MethodCounters that get added through MTD.

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

PR Comment: https://git.openjdk.org/jdk/pull/28670#issuecomment-3614766014

From serb at openjdk.org  Fri Dec  5 00:03:03 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 5 Dec 2025 00:03:03 GMT
Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2]
In-Reply-To: <cvgJS_iWaWwvWZzJIdh-ZcayJIB-bDghKi3dwCQxaLc=.70ef9601-fa8f-45d8-ad55-226e41a68da5@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
 <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
 <uVgMcy7gR7CkOAW7roSvTUbtZws5c62YPEuDKFdxu2w=.64b1f219-f6f1-4bc2-87fd-3ce2a946f340@github.com>
 <qf-5r_MLqzrO8SgfWIHH4Gj4aw8FyCVvhZI_mWCBQ_0=.6b4b864b-409f-42f7-9759-1ae1fd55c398@github.com>
 <Q0gXAzDo8zPlzceEMLzA0Qu82VaW6vPHZ_Z-dQKXWRI=.c5411dc2-728c-49db-8a7c-bec5e6eefcd3@github.com>
 <cvgJS_iWaWwvWZzJIdh-ZcayJIB-bDghKi3dwCQxaLc=.70ef9601-fa8f-45d8-ad55-226e41a68da5@github.com>
Message-ID: <9M7wUIoPHmHhIuq_ogQVrmE731WXZBi1qWKo4aq4haI=.a7cb7dac-5475-49e6-9647-50c69c58736a@github.com>

On Thu, 27 Nov 2025 04:24:23 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>Hmm, I didn't create this with the idea of backporting it in mind. Should I do that?

Not necessarily the one where you do refactoring, only the part for the missing ?no omit frame pointer? option. It can be done separately to simplify the backport.

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

PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-3614783229

From sspitsyn at openjdk.org  Fri Dec  5 01:38:47 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 5 Dec 2025 01:38:47 GMT
Subject: RFR: 6960970: Debugger very slow during stepping [v8]
In-Reply-To: <gFgkgW9blz_tD337KoxIvOECPeJaQ-LfhifJiaosDjw=.11fda5cd-baae-48bb-a12e-4018eeb5cd15@github.com>
References: <gFgkgW9blz_tD337KoxIvOECPeJaQ-LfhifJiaosDjw=.11fda5cd-baae-48bb-a12e-4018eeb5cd15@github.com>
Message-ID: <Y2_Ok1BMRugWOI_8jl2UNGgz4SWetNMjNC7SPuyDf58=.85d6112f-bcab-4da5-8246-e7b6df52d155@github.com>

> This change fixes a long standing performance issue related to the debugger single stepping that is using JVMTI `FramePop` events as a part of step over handling. The performance issue is that the target thread continues its execution in very slow `interp-only` mode in a context of frame marked for `FramePop` notification with the JVMTI `NotifyFramePop`. It includes other method calls recursively upon a return from the frame.
> 
> This fix is to avoid enforcing the `interp-only` execution mode for threads when `FramePop` events are enabled with the JVMTI `SetEventNotificationMode()`. Instead, the target frame has been deoptimized and kept interpreted by disabling `OSR` optimization by the function `InterpreterRuntime::frequency_counter_overflow_inner()`. (Big thanks to @fisk for this suggestion!) Additionally, some tweaks are applied in several places where the `java_thread->is_interp_only_mode()` is checked.
> The other details will be provided in the first PR request comment.
> 
> Testing:
>  - test `serviceability/jvmti/vthread/ThreadStateTest` was updated to provide some extra test coverage
>  - submitted mach5 tiers 1-6

Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:

 - 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
 - cleanup: removed an old code fragment in frame.cpp
 - 6960970: Debugger very slow during stepping

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

Changes: https://git.openjdk.org/jdk/pull/28407/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28407&range=07
  Stats: 255 lines in 22 files changed: 158 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 sspitsyn at openjdk.org  Fri Dec  5 02:33:34 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 5 Dec 2025 02:33:34 GMT
Subject: RFR: 6960970: Debugger very slow during stepping [v9]
In-Reply-To: <gFgkgW9blz_tD337KoxIvOECPeJaQ-LfhifJiaosDjw=.11fda5cd-baae-48bb-a12e-4018eeb5cd15@github.com>
References: <gFgkgW9blz_tD337KoxIvOECPeJaQ-LfhifJiaosDjw=.11fda5cd-baae-48bb-a12e-4018eeb5cd15@github.com>
Message-ID: <jqqycDJFS3q3T3Ceifau6VHhiInSnHy2ML7nJKRHKww=.fda3bdc9-1b40-4347-9cc0-f73135031f00@github.com>

> This change fixes a long standing performance issue related to the debugger single stepping that is using JVMTI `FramePop` events as a part of step over handling. The performance issue is that the target thread continues its execution in very slow `interp-only` mode in a context of frame marked for `FramePop` notification with the JVMTI `NotifyFramePop`. It includes other method calls recursively upon a return from the frame.
> 
> This fix is to avoid enforcing the `interp-only` execution mode for threads when `FramePop` events are enabled with the JVMTI `SetEventNotificationMode()`. Instead, the target frame has been deoptimized and kept interpreted by disabling `OSR` optimization by the function `InterpreterRuntime::frequency_counter_overflow_inner()`. (Big thanks to @fisk for this suggestion!) Additionally, some tweaks are applied in several places where the `java_thread->is_interp_only_mode()` is checked.
> The other details will be provided in the first PR request comment.
> 
> Testing:
>  - test `serviceability/jvmti/vthread/ThreadStateTest` was updated to provide some extra test coverage
>  - submitted mach5 tiers 1-6

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

  merge: add fragments dropped by incorrect merge

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28407/files
  - new: https://git.openjdk.org/jdk/pull/28407/files/9d2589be..91df8454

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28407&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28407&range=07-08

  Stats: 37 lines in 2 files changed: 36 ins; 0 del; 1 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 duke at openjdk.org  Fri Dec  5 05:41:03 2025
From: duke at openjdk.org (Harshit470250)
Date: Fri, 5 Dec 2025 05:41:03 GMT
Subject: RFR: 8347396: Efficient TypeFunc creations [v3]
In-Reply-To: <da-a4Id_azWgrrTjDQEeYR6rm4D2l5jZAHIMx9x4v4w=.38b3a577-a776-49c4-8afb-27c684c126ad@github.com>
References: <VQs3SMtk1y6xTi8nCvTeWsTFfCQlTJtDdCGnfWQmRmw=.f3b33ba1-3efe-477b-b6d2-b43faae9ee2b@github.com>
 <da-a4Id_azWgrrTjDQEeYR6rm4D2l5jZAHIMx9x4v4w=.38b3a577-a776-49c4-8afb-27c684c126ad@github.com>
Message-ID: <yxthYW3xnPJNVXrxRFUuFPY_8741Dg5MAJZp-cIttrc=.61ff8873-f90b-4c4f-bb8e-259b4d52de21@github.com>

On Wed, 3 Dec 2025 08:37:02 GMT, Harshit470250 <duke at openjdk.org> 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 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

I have reproduced it [here](https://github.com/Harshit470250/jdk/pull/2).

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

PR Comment: https://git.openjdk.org/jdk/pull/27279#issuecomment-3615381956

From kvn at openjdk.org  Fri Dec  5 06:12:11 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 5 Dec 2025 06:12:11 GMT
Subject: RFR: 8357258: x86: Improve receiver type profiling reliability
 [v8]
In-Reply-To: <avqNAcH5MpUoM31mrtm0Z6qnPqpgbpGszW01AtFbYXk=.359b8088-c0b5-4a01-aefc-fe3c02bdd60a@github.com>
References: <X9RJoDWqk67MlK7P4ACCbzROxLkfEqvU0zDid3zymnc=.7c0086a3-f514-4b0d-8bc0-592bf4a05bba@github.com>
 <avqNAcH5MpUoM31mrtm0Z6qnPqpgbpGszW01AtFbYXk=.359b8088-c0b5-4a01-aefc-fe3c02bdd60a@github.com>
Message-ID: <1oFMd7KL-qhMxhHPi0mTspnW8oNMF8ZVGucT6IJXwv4=.d81f2eca-9ddc-4d63-8a20-40c2192e1004@github.com>

On Tue, 2 Dec 2025 10:31:22 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the bug for discussion what issues current machinery has. 
>> 
>> This PR executes the plan outlined in the bug:
>>  1. Common the receiver type profiling code in interpreter and C1
>>  2. Rewrite receiver type profiling code to only do atomic receiver slot installations
>>  3. Trim `C1OptimizeVirtualCallProfiling` to only claim slots when receiver is installed 
>> 
>> This PR does _not_ do atomic counter updates themselves, as it may have much wider performance implications, including regressions. This PR should be at least performance neutral.
>> 
>> Additional testing:
>>   - [x] Linux x86_64 server fastdebug, `compiler/`
>>   - [x] Linux x86_64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:
> 
>  - 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
>  - Offset is always rscratch1, no need to save it
>  - Grossly simplify register shuffling
>  - ... and 11 more: https://git.openjdk.org/jdk/compare/7278d2e8...3c5019d9

My testing of version 07 passed clean

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

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

From stefank at openjdk.org  Fri Dec  5 07:53:18 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 5 Dec 2025 07:53:18 GMT
Subject: RFR: 8370198: Test gc/arguments/TestShrinkHeapInSteps.java
 crashed:  assert(left >= right) failed: avoid underflow [v4]
In-Reply-To: <InyhuhR_Me5U37VRtH0OrcP2KrkaF_Il4WLvbPu6Mbk=.0982a838-b55a-488e-abca-65c77f37f34b@github.com>
References: <WKjyigvXghJNT-bijIBX8dyE1cdd3GsubdHvrNrYHyM=.dedfb4bc-b098-4d8f-8f5a-291d92fe9f2d@github.com>
 <InyhuhR_Me5U37VRtH0OrcP2KrkaF_Il4WLvbPu6Mbk=.0982a838-b55a-488e-abca-65c77f37f34b@github.com>
Message-ID: <OfZ_wBJQgRC2-KvUae0ZGTscYRaSmaEQQ4nf4AL1o5g=.7bda4328-af74-48d4-9933-b07a595a550f@github.com>

On Thu, 4 Dec 2025 19:46:35 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Add an early-return for outside-heap address in `CollectedHeap::is_in` API.
>> 
>> While investigating this failure (JDK-8370198), I realized that some java-threads (compiler-threads) in `native` state can invoke `CollectedHeap` APIs. Since heap-resizing occurs inside safepoint but java-threads in `native` state just ignore safepoint, I have added some assert to catch such dangerous uses, where the return value might not be stable.
>> 
>> Test: tie1-5; can't reproduce the JDK-8370198 with or without this patch for >8000 runs.
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Changes requested by stefank (Reviewer).

src/hotspot/share/gc/serial/serialHeap.cpp line 634:

> 632: bool SerialHeap::is_in(const void* p) const {
> 633:   // precondition
> 634:   DEBUG_ONLY(verify_not_in_native_if_java_thread();)

No need for `DEBUG_ONLY` now that you've added `NOT_DEBUG_RETURN`
Suggestion:

  verify_not_in_native_if_java_thread();

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

PR Review: https://git.openjdk.org/jdk/pull/28393#pullrequestreview-3543492436
PR Review Comment: https://git.openjdk.org/jdk/pull/28393#discussion_r2591730326

From aartemov at openjdk.org  Fri Dec  5 09:27:36 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Fri, 5 Dec 2025 09:27:36 GMT
Subject: RFR: 8366671: Refactor Thread::SpinAcquire and Thread::SpinRelease
 [v13]
In-Reply-To: <NtY8E8fBeSokCAQYP3OQEwfnppSugtTJ8uAtQtD0zvg=.88f2988d-47fd-4b8a-af89-488ed6b37870@github.com>
References: <NtY8E8fBeSokCAQYP3OQEwfnppSugtTJ8uAtQtD0zvg=.88f2988d-47fd-4b8a-af89-488ed6b37870@github.com>
Message-ID: <oESnFGaCr5_ofIxq1SnMyn3qpw_j47--aLQt5A9D4CQ=.3703cb3e-c813-4062-acbe-51d397aa51f7@github.com>

> Hi, 
> 
> please consider the following changes:
> 
> In this PR `Thread::SpinAcquire()` and `Thread::SpinRelease()` methods are refactored into a utility class `SpinCriticalSection`. The motivation is to make it easier for developers to use this lightweight synchronization mechanism in the codebase. The two aforementioned methods were used in JFR to create short critical sections with a helper class, but that was not the case for the object monitor code. 
> 
> Tested in tiers 1 - 5.

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

  Update src/hotspot/share/runtime/objectMonitor.cpp
  
  Co-authored-by: Coleen Phillimore <coleen.phillimore at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28264/files
  - new: https://git.openjdk.org/jdk/pull/28264/files/f987e128..debff9db

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28264&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28264&range=11-12

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

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

From aartemov at openjdk.org  Fri Dec  5 09:27:38 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Fri, 5 Dec 2025 09:27:38 GMT
Subject: RFR: 8366671: Refactor Thread::SpinAcquire and Thread::SpinRelease
 [v12]
In-Reply-To: <0akXzzAj2Qo0u8Es21NeLBJvj2JJrHj-4s1OfiiM3Ts=.45c7d1e1-9910-4aa7-95b3-97bec8dd3fb6@github.com>
References: <NtY8E8fBeSokCAQYP3OQEwfnppSugtTJ8uAtQtD0zvg=.88f2988d-47fd-4b8a-af89-488ed6b37870@github.com>
 <BLbZykwmGPMfOyN0A7lrjaht-OWDbWK9_ArQRZZTVCU=.4bbd7292-3028-44f2-b0a5-cb4f29c2044b@github.com>
 <0akXzzAj2Qo0u8Es21NeLBJvj2JJrHj-4s1OfiiM3Ts=.45c7d1e1-9910-4aa7-95b3-97bec8dd3fb6@github.com>
Message-ID: <7AST7fsz9_GDP-EMHUo7lH-WjnbkSuxGFlFytencHU4=.8ab98e51-55af-4830-8d15-a161ce674ce0@github.com>

On Wed, 3 Dec 2025 21:03:07 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8366671: Added NoSafepointVerifier
>
> src/hotspot/share/runtime/objectMonitor.cpp line 2056:
> 
>> 2054:       // there is nothing to do.
>> 2055:       if (old_state == java_lang_VirtualThread::WAIT ||
>> 2056:         old_state == java_lang_VirtualThread::TIMED_WAIT) {
> 
> The original alignment was correct.

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28264#discussion_r2591975651

From aartemov at openjdk.org  Fri Dec  5 09:37:06 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Fri, 5 Dec 2025 09:37:06 GMT
Subject: RFR: 8366671: Refactor Thread::SpinAcquire and Thread::SpinRelease
 [v12]
In-Reply-To: <Z0c-dWNWbxGumcLpse7-H3fGuAI5h9XBdu9bsJdRGeA=.bf035f09-aedf-401a-bf6d-90cf2568d48c@github.com>
References: <NtY8E8fBeSokCAQYP3OQEwfnppSugtTJ8uAtQtD0zvg=.88f2988d-47fd-4b8a-af89-488ed6b37870@github.com>
 <BLbZykwmGPMfOyN0A7lrjaht-OWDbWK9_ArQRZZTVCU=.4bbd7292-3028-44f2-b0a5-cb4f29c2044b@github.com>
 <Z0c-dWNWbxGumcLpse7-H3fGuAI5h9XBdu9bsJdRGeA=.bf035f09-aedf-401a-bf6d-90cf2568d48c@github.com>
Message-ID: <g51FTZgI8RY6EqjJxfGYFe8RltiRQG8muogTidUqvJc=.95e1128b-d6e1-40cd-a624-aee2630fbfb7@github.com>

On Thu, 4 Dec 2025 19:36:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8366671: Added NoSafepointVerifier
>
> src/hotspot/share/utilities/spinCriticalSection.hpp line 54:
> 
>> 52:   SpinCriticalSection(volatile int* lock)
>> 53:     : _lock(lock)
>> 54:       DEBUG_ONLY(COMMA _nsv(Thread::current_or_null_safe() != nullptr)) {
> 
> So we need to allow for null because this can be called early in VM init whilst the main thread is still attaching, but why do we need the "safe" variant? That is only for code that can be executed in a signal handling context

Is this safety measure redundant though? I mean we move the code into a utility class, which may, potentially, end up being used in that context. It is not the case now, sure. If we do not allow that, we need document this and use a non-safe `current_or_null()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28264#discussion_r2592009754

From bkilambi at openjdk.org  Fri Dec  5 10:55:01 2025
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Fri, 5 Dec 2025 10:55:01 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v5]
In-Reply-To: <Vqu9FE4SgvqWFWn0U9718IDFzJviLpKyRyfYc7qrrZ0=.04845f2a-e4f5-4bb5-8f8f-d6bb001ca9c3@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <Vqu9FE4SgvqWFWn0U9718IDFzJviLpKyRyfYc7qrrZ0=.04845f2a-e4f5-4bb5-8f8f-d6bb001ca9c3@github.com>
Message-ID: <xnv1Opu5mYuEW8QCbg9LJm7O9CWGrKD9t4mI-EOALgU=.1ea2fb88-bbd8-4ce1-bd3d-6b5289f146e5@github.com>

On Wed, 26 Nov 2025 11:34:11 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Add a new  Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type.
>> - Add necessary inline expander support.
>>    - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA.
>> - Use existing Float16 vector IR and backend support.
>> - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations.
>>  
>> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc).
>> 
>> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels.
>> 
>> <img width="1449" height="629" alt="image" src="https://github.com/user-attachments/assets/b4474361-9886-4315-a614-f4073fd075b9" />
>> 
>> 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:
> 
>   Cleanups

src/hotspot/share/opto/vectorIntrinsics.cpp line 341:

> 339:       laneType     == nullptr || !laneType->is_con() ||
> 340:       vector_klass == nullptr || vector_klass->const_oop() == nullptr ||
> 341:       laneType     == nullptr || !laneType->is_con() ||

is this repeating the same condition on line 339?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2592254926

From ayang at openjdk.org  Fri Dec  5 11:01:17 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 5 Dec 2025 11:01:17 GMT
Subject: RFR: 8370198: Test gc/arguments/TestShrinkHeapInSteps.java
 crashed:  assert(left >= right) failed: avoid underflow [v5]
In-Reply-To: <WKjyigvXghJNT-bijIBX8dyE1cdd3GsubdHvrNrYHyM=.dedfb4bc-b098-4d8f-8f5a-291d92fe9f2d@github.com>
References: <WKjyigvXghJNT-bijIBX8dyE1cdd3GsubdHvrNrYHyM=.dedfb4bc-b098-4d8f-8f5a-291d92fe9f2d@github.com>
Message-ID: <NmuSRRaTMsLhiejYs3If27QxYcmuh71L7ViT5EWGjOY=.d90b539a-8376-4be5-837c-6cd0824975c6@github.com>

> Add an early-return for outside-heap address in `CollectedHeap::is_in` API.
> 
> While investigating this failure (JDK-8370198), I realized that some java-threads (compiler-threads) in `native` state can invoke `CollectedHeap` APIs. Since heap-resizing occurs inside safepoint but java-threads in `native` state just ignore safepoint, I have added some assert to catch such dangerous uses, where the return value might not be stable.
> 
> Test: tie1-5; can't reproduce the JDK-8370198 with or without this patch for >8000 runs.

Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/share/gc/serial/serialHeap.cpp
  
  Co-authored-by: Stefan Karlsson <stefan.karlsson at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28393/files
  - new: https://git.openjdk.org/jdk/pull/28393/files/40ee3859..6f4f258d

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

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

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

From jvernee at openjdk.org  Fri Dec  5 11:10:27 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 5 Dec 2025 11:10:27 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v7]
In-Reply-To: <7ayMTZ4nXMyB1SXNRcYGjdxidNHDcAUNv_8fQZDUaPI=.a558d3a2-1d3e-4b45-8ba7-393c55a52785@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <7ayMTZ4nXMyB1SXNRcYGjdxidNHDcAUNv_8fQZDUaPI=.a558d3a2-1d3e-4b45-8ba7-393c55a52785@github.com>
Message-ID: <n-1cYeDh_yS2bYWFtuBlVsMCn43a4CSec_1uuP-jGh0=.22185d73-ac9e-43e0-8edf-0879c9509ed5@github.com>

On Thu, 4 Dec 2025 01:48:31 GMT, Chen Liang <liach at openjdk.org> 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:
> 
>   Revert void special case removal due to C2 shortage causing TestZGCBarrierElision::testAtomicThenAtomicAnotherField failure

Latest version looks much better to me (as mentioned offline). What was the issue with the failing test around the removal of the _V guard template?

Also, looks like the new IR test is failing in GHA

test/hotspot/jtreg/compiler/c2/irTests/constantFold/VarHandleMismatchedTypeFold.java line 48:

> 46:     public static void main(String[] args) {
> 47:         TestFramework.runWithFlags(
> 48:             "-XX:+UnlockExperimentalVMOptions"

Why is this flag needed?

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

PR Review: https://git.openjdk.org/jdk/pull/28585#pullrequestreview-3544230655
PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2592287594

From stefank at openjdk.org  Fri Dec  5 11:49:56 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 5 Dec 2025 11:49:56 GMT
Subject: RFR: 8370198: Test gc/arguments/TestShrinkHeapInSteps.java
 crashed:  assert(left >= right) failed: avoid underflow [v5]
In-Reply-To: <NmuSRRaTMsLhiejYs3If27QxYcmuh71L7ViT5EWGjOY=.d90b539a-8376-4be5-837c-6cd0824975c6@github.com>
References: <WKjyigvXghJNT-bijIBX8dyE1cdd3GsubdHvrNrYHyM=.dedfb4bc-b098-4d8f-8f5a-291d92fe9f2d@github.com>
 <NmuSRRaTMsLhiejYs3If27QxYcmuh71L7ViT5EWGjOY=.d90b539a-8376-4be5-837c-6cd0824975c6@github.com>
Message-ID: <WJ_L53bROh1lDl6VInB-UwExF9LX7D3ba2cgKnoqR0I=.907238a1-7ba1-4781-ba23-b236a331e692@github.com>

On Fri, 5 Dec 2025 11:01:17 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Add an early-return for outside-heap address in `CollectedHeap::is_in` API.
>> 
>> While investigating this failure (JDK-8370198), I realized that some java-threads (compiler-threads) in `native` state can invoke `CollectedHeap` APIs. Since heap-resizing occurs inside safepoint but java-threads in `native` state just ignore safepoint, I have added some assert to catch such dangerous uses, where the return value might not be stable.
>> 
>> Test: tie1-5; can't reproduce the JDK-8370198 with or without this patch for >8000 runs.
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/gc/serial/serialHeap.cpp
>   
>   Co-authored-by: Stefan Karlsson <stefan.karlsson at oracle.com>

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28393#pullrequestreview-3544404740

From dholmes at openjdk.org  Fri Dec  5 11:51:01 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 5 Dec 2025 11:51:01 GMT
Subject: RFR: 8366671: Refactor Thread::SpinAcquire and Thread::SpinRelease
 [v12]
In-Reply-To: <g51FTZgI8RY6EqjJxfGYFe8RltiRQG8muogTidUqvJc=.95e1128b-d6e1-40cd-a624-aee2630fbfb7@github.com>
References: <NtY8E8fBeSokCAQYP3OQEwfnppSugtTJ8uAtQtD0zvg=.88f2988d-47fd-4b8a-af89-488ed6b37870@github.com>
 <BLbZykwmGPMfOyN0A7lrjaht-OWDbWK9_ArQRZZTVCU=.4bbd7292-3028-44f2-b0a5-cb4f29c2044b@github.com>
 <Z0c-dWNWbxGumcLpse7-H3fGuAI5h9XBdu9bsJdRGeA=.bf035f09-aedf-401a-bf6d-90cf2568d48c@github.com>
 <g51FTZgI8RY6EqjJxfGYFe8RltiRQG8muogTidUqvJc=.95e1128b-d6e1-40cd-a624-aee2630fbfb7@github.com>
Message-ID: <KbihuIqL_t7wzUfBlOrV_8WJBd_f7Bk5J2cabYY_588=.0db43b71-5b27-4734-9acd-d55e41cfb052@github.com>

On Fri, 5 Dec 2025 09:34:06 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> src/hotspot/share/utilities/spinCriticalSection.hpp line 54:
>> 
>>> 52:   SpinCriticalSection(volatile int* lock)
>>> 53:     : _lock(lock)
>>> 54:       DEBUG_ONLY(COMMA _nsv(Thread::current_or_null_safe() != nullptr)) {
>> 
>> So we need to allow for null because this can be called early in VM init whilst the main thread is still attaching, but why do we need the "safe" variant? That is only for code that can be executed in a signal handling context
>
> Is this safety measure redundant though? I mean we move the code into a utility class, which may, potentially, end up being used in that context. It is not the case now, sure. If we do not allow that, we need document this and use a non-safe `current_or_null()`.

Well we moved it for convenience but we really don't want it to start being used all over. :) I don't like this kind of "just in case" code as it indicates to me that we don't really know how/where the code is being used - and where do you draw the line? This is debug code so the performance aspect is not a concern, but I prefer not to have it but if you like document that this is not for use in signal-handling context. But this isn't a deal-breaker if others think it worth being ultra-conservative here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28264#discussion_r2592416534

From qpzhang at openjdk.org  Fri Dec  5 12:11:14 2025
From: qpzhang at openjdk.org (Patrick Zhang)
Date: Fri, 5 Dec 2025 12:11:14 GMT
Subject: RFR: 8365991: AArch64: Ignore BlockZeroingLowLimit when
 UseBlockZeroing is false [v7]
In-Reply-To: <tW59JkXtBEwBuw6qkKM0YIxJjTwoTbGZ3oWhXurqwC8=.e5e87d0b-ce15-4d2b-97dd-b747a69df5fd@github.com>
References: <pSbTemGu8e1IiEiqk0ENZ_GgEVyi-NoA2U01iK_dMDM=.a8308160-ba13-4b39-9696-93e1e3e6f67f@github.com>
 <GjVnBFpmztg63oLghMGJ9h178LbFxKFQk-2IbR8T3Rk=.8fd619fc-6c35-459a-bf7f-ed20d48295eb@github.com>
 <X2pvoXwE_OG1CrPot5efsgf8N1wqMr2rp-WrqDxlcXw=.e772e271-ae35-47f1-8523-56542a88db43@github.com>
 <tW59JkXtBEwBuw6qkKM0YIxJjTwoTbGZ3oWhXurqwC8=.e5e87d0b-ce15-4d2b-97dd-b747a69df5fd@github.com>
Message-ID: <FUhLoCD6jDJLLs4t0nt9C9VwiSkV2qca_wKyMewjJBQ=.021b9f30-c23e-487d-88ad-06510421d963@github.com>

On Mon, 24 Nov 2025 09:13:19 GMT, Patrick Zhang <qpzhang at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 6273:
>> 
>>> 6271:     result = zero_words(r10, r11);
>>> 6272:   } else {
>>> 6273: #ifndef PRODUCT
>> 
>> What is this change for?
>
> The reason of why I swapped the `if` and `else` code block is:
> 1). Initially, I intended to add a check for `UseBlockZeroing` to determine whether to call `zero_words_reg_reg`. Swapping the `if` and `else` branches makes it easier to compare the behavior with and without this additional condition. Otherwise, the if-cond would be like `if (!UseBlockZeroing || cnt <= (uint64_t)BlockZeroingLowLimit / BytesPerWord)`.
> 2). Later, we decided not to check `UseBlockZeroing` here but I still didn't roll back this change because the comments of warning `There is no need to check UseBlockZeroing..` should be placed before such an if condition, instead of the old one.

Resolved this if no further concern, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26917#discussion_r2592467642

From qpzhang at openjdk.org  Fri Dec  5 12:11:16 2025
From: qpzhang at openjdk.org (Patrick Zhang)
Date: Fri, 5 Dec 2025 12:11:16 GMT
Subject: RFR: 8365991: AArch64: Ignore BlockZeroingLowLimit when
 UseBlockZeroing is false [v7]
In-Reply-To: <Ww3ORHqx6LlDQKlkH83q8jcZlKloPC5E0Cd2sB8R5Zg=.ee27c69f-3412-4b4e-8288-f36ebf8494e2@github.com>
References: <pSbTemGu8e1IiEiqk0ENZ_GgEVyi-NoA2U01iK_dMDM=.a8308160-ba13-4b39-9696-93e1e3e6f67f@github.com>
 <GjVnBFpmztg63oLghMGJ9h178LbFxKFQk-2IbR8T3Rk=.8fd619fc-6c35-459a-bf7f-ed20d48295eb@github.com>
 <X2pvoXwE_OG1CrPot5efsgf8N1wqMr2rp-WrqDxlcXw=.e772e271-ae35-47f1-8523-56542a88db43@github.com>
 <tW59JkXtBEwBuw6qkKM0YIxJjTwoTbGZ3oWhXurqwC8=.e5e87d0b-ce15-4d2b-97dd-b747a69df5fd@github.com>
 <Ww3ORHqx6LlDQKlkH83q8jcZlKloPC5E0Cd2sB8R5Zg=.ee27c69f-3412-4b4e-8288-f36ebf8494e2@github.com>
Message-ID: <PWgJd1oLHct76XEhEG7KjuWV3Ok6Ub7sBU9mk0cO5WU=.7effc5a3-c13b-435b-bebf-841b70817fc5@github.com>

On Tue, 25 Nov 2025 13:29:16 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> I wondered why `MacroAssembler::zero_words` uses 16 words to do `stp` unrolling, while `generate_zero_blocks()` 8 words (`const int MacroAssembler::zero_words_block_size = 8;`), so defined this variable to compare `8 vs 16` but did not find obvious performance difference. 
>> 
>> Regarding the var name `block_size`, could `unroll` or `unroll_words` be better?
>
>> I wondered why `MacroAssembler::zero_words` uses 16 words to do `stp` unrolling, while `generate_zero_blocks()` 8 words (`const int MacroAssembler::zero_words_block_size = 8;`), so defined this variable to compare `8 vs 16` but did not find obvious performance difference.
>> 
>> Regarding the var name `block_size`, could `unroll` or `unroll_words` be better?
> 
> What's wrong with 16? I'm asking not from a "my teachers said always name constants" point of view, but from a reader's understanding point of view. Named constants are all well and good if the constant has some meaning, but this one is just two words. Perhaps `2 * WordSize` would do.

[PR 4919](https://github.com/openjdk/jdk/pull/4919/files#diff-0f4150a9c607ccd590bf256daa800c0276144682a92bc6bdced5e8bc1bb81f3aL4737) for [8270947: AArch64: C1: use zero_words to initialize all objects](https://bugs.openjdk.org/browse/JDK-8270947) changed the loop unroll length from 4 STPs (clearing 8 words) to 8 STPs (clearing 16 words) within the loop. In fact, before that PR, it seems the value 16 was from the `SmallArraySize` (`18 * BytesPerLong`).

For the current code snippet, I think, using `2 * WordSize` to the constant is not ideal, as it suggests the size of the unroll length and can be confusing. A better choice might be `2 * MacroAssembler::zero_words_block_size`, which more accurately reflects the intended meaning. Is this acceptable?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26917#discussion_r2592464052

From qpzhang at openjdk.org  Fri Dec  5 12:15:51 2025
From: qpzhang at openjdk.org (Patrick Zhang)
Date: Fri, 5 Dec 2025 12:15:51 GMT
Subject: RFR: 8365991: AArch64: Ignore BlockZeroingLowLimit when
 UseBlockZeroing is false [v9]
In-Reply-To: <pSbTemGu8e1IiEiqk0ENZ_GgEVyi-NoA2U01iK_dMDM=.a8308160-ba13-4b39-9696-93e1e3e6f67f@github.com>
References: <pSbTemGu8e1IiEiqk0ENZ_GgEVyi-NoA2U01iK_dMDM=.a8308160-ba13-4b39-9696-93e1e3e6f67f@github.com>
Message-ID: <zoteX6dK1myYWIUMdzHIfWKBCwVQVW5u5q1zSSF8arQ=.89a4d971-645f-4469-a137-8b67a8b22484@github.com>

> 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:

  Changed the constant 16 to 2 * zero_words_block_size
  
  Signed-off-by: Patrick Zhang <patrick at os.amperecomputing.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26917/files
  - new: https://git.openjdk.org/jdk/pull/26917/files/a23ec878..f39078bd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26917&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26917&range=07-08

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 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 galder at openjdk.org  Fri Dec  5 13:38:24 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Fri, 5 Dec 2025 13:38:24 GMT
Subject: RFR: 8347273: C2: VerifyIterativeGVN for Ideal and Identity [v10]
In-Reply-To: <1C0ByMoDpDlOmbDQVgBTQg7yKI0UaLtX92Xmf0bta4E=.0c060c5a-d60d-4cbe-84c5-03884116ef34@github.com>
References: <D2JxhhSJt3FxdHxUaE1790GaGfNirmhcpErVJsfuh6w=.ec592c7a-de4e-4014-91f3-9f8d641c2f25@github.com>
 <1C0ByMoDpDlOmbDQVgBTQg7yKI0UaLtX92Xmf0bta4E=.0c060c5a-d60d-4cbe-84c5-03884116ef34@github.com>
Message-ID: <LbVQ1RSc8dPZV0NcohaV9wWvwgE9qLc8dunlhodMwHo=.96359d2d-076f-4cdf-962a-334d1b9ec480@github.com>

On Thu, 12 Jun 2025 09:12:03 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> **Past Work**
>> With https://github.com/openjdk/jdk/pull/11775 / [JDK-8298952](https://bugs.openjdk.org/browse/JDK-8298952) we added `Node::Value` verification.
>> 
>> **This PR**
>> I'm now adding verification for `Ideal` and `Identity`. I'm adding two bits to the flag `VerifyIterativeGVN`.
>> 
>> I found many many  node types that hit my verification assert, i.e. that could still be optimized after IGVN is over, just because these nodes were not put on the worklist any more.
>> 
>> My approach was to aggressively bail-out for all nodes that had an issue. This way, we can address one by one in follow-up RFEs. For many, I did some initial assessment, and left some comments about what issues I encountered.
>> 
>> **Future Work:**
>> In many cases, the issue is just a missing notification when inputs of inputs are changed. These would be good starter tasks. But there are probably also more complicated cases. And there are surely cases where verification will be impossible, because it is possible that the Idea / Identity optimizations traverse longer paths, and we cannot expect that notification makes it down that path. For those cases, we will have to leave the exception and document it well.
>> 
>> I filed:
>> [JDK-8359103](https://bugs.openjdk.org/browse/JDK-8359103) C2 VerifyIterativeGVN: Umbrella for extending Ideal and Identity verification (JDK-8347273)
>> (We can file subtasks for the nodes we want to fix. I don't want to file them all now, but we should file them as we are investigating, so that there is no duplicate work.)
>> 
>> Testing passed tier1-3, with extra timeout factor 20.
>
> Emanuel Peter 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 79 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8347273-verify-IGVN-Ideal-Identity
>  - update comments for Christian
>  - Apply suggestions from code review
>    
>    Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>  - reorder flags for Christian
>  - max_modes
>  - use stringStream instead of ttyLocker
>  - assert(false) for Christian
>  - rename for Christian
>  - Update src/hotspot/share/opto/phaseX.cpp
>    
>    Co-authored-by: Manuel H?ssig <manuel at haessig.org>
>  - review suggestions, and handled a few more edge cases
>  - ... and 69 more: https://git.openjdk.org/jdk/compare/44e9f72c...d9546d87

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

> 1964:     //
> 1965:     // Found with:
> 1966:     //   compiler/codegen/TestBooleanVect.java

@eme64 Did you really encounter issues for this min/max codes with `TestBooleanVect`? Or is test name incorrect here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22970#discussion_r2592718199

From roland at openjdk.org  Fri Dec  5 13:48:51 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Fri, 5 Dec 2025 13:48:51 GMT
Subject: RFR: 8351889: C2 crash: assertion failed:  Base pointers must
 match (addp 344) [v4]
In-Reply-To: <9mnRXpB16Y6Mw0TSGFJz-69m24lzCNPMC_B1_YseD4M=.be94bbba-88ce-4958-a8bd-89862d7ec2e7@github.com>
References: <IKOYjLXrS8q1GMjbaL2HOBNH8Oa_16k4WBa2NaMngS8=.c6fd7fbb-4758-48b2-a992-3702b2718e59@github.com>
 <w-yCuouqlwsCiBjv5stRarSJwFeRhqRrfKT9zC0lUuk=.f782fb00-4c68-4305-ae38-1a1b1cf62108@github.com>
 <9mnRXpB16Y6Mw0TSGFJz-69m24lzCNPMC_B1_YseD4M=.be94bbba-88ce-4958-a8bd-89862d7ec2e7@github.com>
Message-ID: <FeAsQWj0xGArOAJcWg3NZD-VDDtkg-bwjm3YtLSpYi8=.c79eec8d-51f4-470c-aeed-764dd3123e15@github.com>

On Wed, 3 Dec 2025 05:43:30 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> I think I'm on board with the solution now. It is probably best to do it during IGVN. I have a few more suggestions below :)

Updated change should address your comments.

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

PR Comment: https://git.openjdk.org/jdk/pull/25386#issuecomment-3616982320

From roland at openjdk.org  Fri Dec  5 13:48:50 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Fri, 5 Dec 2025 13:48:50 GMT
Subject: RFR: 8351889: C2 crash: assertion failed:  Base pointers must
 match (addp 344) [v5]
In-Reply-To: <IKOYjLXrS8q1GMjbaL2HOBNH8Oa_16k4WBa2NaMngS8=.c6fd7fbb-4758-48b2-a992-3702b2718e59@github.com>
References: <IKOYjLXrS8q1GMjbaL2HOBNH8Oa_16k4WBa2NaMngS8=.c6fd7fbb-4758-48b2-a992-3702b2718e59@github.com>
Message-ID: <lJ_q1MxUgjyRIHuOAAMwlgZV-V4ZbXicJ78Gyry2dIQ=.b1085ad9-0870-467c-b27a-773a2d4a4e3e@github.com>

> The test case has an out of loop `Store` with an `AddP` address
> expression that has other uses and is in the loop body. Schematically,
> only showing the address subgraph and the bases for the `AddP`s:
> 
> 
> Store#195 -> AddP#133 -> AddP#134 -> CastPP#110
>                      -> CastPP#110
> 
> 
> Both `AddP`s have the same base, a `CastPP` that's also in the loop
> body.
> 
> That loop is a counted loop and only has 3 iterations so is fully
> unrolled. First, one iteration is peeled:
> 
> 
>                                 /-> CastPP#110
> Store#195 -> Phi#360 -> AddP#133 -> AddP#134 -> CastPP#110
>                     -> AddP#277 -> AddP#278 -> CastPP#283
>                                 -> CastPP#283
> 
> 
> 
> The `AddP`s and `CastPP` are cloned (because in the loop body). As
> part of peeling, `PhaseIdealLoop::peeled_dom_test_elim()` is
> called. It finds the test that guards `CastPP#283` in the peeled
> iteration dominates and replaces the test that guards `CastPP#110`
> (the test in the peeled iteration is the clone of the test in the
> loop). That causes `CastPP#110`'s control to be updated to that of the
> test in the peeled iteration and to be yanked from the loop. So now
> `CastPP#283` and `CastPP#110` have the same inputs.
> 
> Next unrolling happens:
> 
> 
>                                            /-> CastPP#110
>                                /-> AddP#400 -> AddP#401 -> CastPP#110
> Store#195 -> Phi#360 -> Phi#477 -> AddP#133 -> AddP#134 -> CastPP#110
>                   \                        -> CastPP#110
>                    -> AddP#277 -> AddP#278 -> CastPP#283
>                                -> CastPP#283
> 
> 
> 
> `AddP`s are cloned once more but not the `CastPP`s because they are
> both in the peeled iteration now. A new `Phi` is added.
> 
> Next igvn runs. It's going to push the `AddP`s through the `Phi`s.
> 
> Through `Phi#477`:
> 
> 
> 
>                                 /-> CastPP#110
> Store#195 -> Phi#360 -> AddP#510 -> Phi#509 -> AddP#401 -> CastPP#110
>                   \                        -> AddP#134 -> CastPP#110
>                    -> AddP#277 -> AddP#278 -> CastPP#283
>                                -> CastPP#283
> 
> 
> 
> Through `Phi#360`:
> 
> 
>                                            /-> AddP#134 -> CastPP#110
>                                 /-> Phi#509 -> AddP#401 -> CastPP#110
> Store#195 -> AddP#516 -> Phi#515 -> AddP#278 -> CastPP#283
>                      -> Phi#514 -> CastPP#283
>                                 -> CastP#110
> 
> 
> Then `Phi#514` which has 2 `CastPP`s as input with identical inputs is
> transformed into anot...

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

  review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25386/files
  - new: https://git.openjdk.org/jdk/pull/25386/files/15c17bb1..20154a12

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

  Stats: 34 lines in 3 files changed: 17 ins; 6 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/25386.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25386/head:pull/25386

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

From roland at openjdk.org  Fri Dec  5 13:52:12 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Fri, 5 Dec 2025 13:52:12 GMT
Subject: RFR: 8354282: C2: more crashes in compiled code because of
 dependency on removed range check CastIIs [v9]
In-Reply-To: <qos-VYvgreqGsB7ke35RmM3L9uHnnM6nUsm2QONKXc4=.9c902d61-5f45-41f5-8276-ac28830c2bf5@github.com>
References: <qos-VYvgreqGsB7ke35RmM3L9uHnnM6nUsm2QONKXc4=.9c902d61-5f45-41f5-8276-ac28830c2bf5@github.com>
Message-ID: <fbJG9nqubON7ElRKkt7chDL7Jki6W0lHsGDWXhRHcgM=.80a0846e-d42b-44d7-bd40-68b0bbb8b9fd@github.com>

> This is a variant of 8332827. In 8332827, an array access becomes
> dependent on a range check `CastII` for another array access. When,
> after loop opts are over, that RC `CastII` was removed, the array
> access could float and an out of bound access happened. With the fix
> for 8332827, RC `CastII`s are no longer removed.
> 
> With this one what happens is that some transformations applied after
> loop opts are over widen the type of the RC `CastII`. As a result, the
> type of the RC `CastII` is no longer narrower than that of its input,
> the `CastII` is removed and the dependency is lost.
> 
> There are 2 transformations that cause this to happen:
> 
> - after loop opts are over, the type of the `CastII` nodes are widen
>   so nodes that have the same inputs but a slightly different type can
>   common.
>   
> - When pushing a `CastII` through an `Add`, if of the type both inputs
>   of the `Add`s are non constant, then we end up widening the type
>   (the resulting `Add` has a type that's wider than that of the
>   initial `CastII`).
>   
> There are already 3 types of `Cast` nodes depending on the
> optimizations that are allowed. Either the `Cast` is floating
> (`depends_only_test()` returns `true`) or pinned. Either the `Cast`
> can be removed if it no longer narrows the type of its input or
> not. We already have variants of the `CastII`:
> 
> - if the Cast can float and be removed when it doesn't narrow the type
> of its input.
> 
> - if the Cast is pinned and be removed when it doesn't narrow the type
> of its input.
> 
> - if the Cast is pinned and can't be removed when it doesn't narrow
> the type of its input.
> 
> What we need here, I think, is the 4th combination:
> 
> - if the Cast can float and can't be removed when it doesn't narrow
> the type of its input.
> 
> Anyway, things are becoming confusing with all these different
> variants named in ways that don't always help figure out what
> constraints one of them operate under. So I refactored this and that's
> the biggest part of this change. The fix consists in marking `Cast`
> nodes when their type is widen in a way that prevents them from being
> optimized out.
> 
> Tobias ran performance testing with a slightly different version of
> this change and there was no regression.

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

  Update src/hotspot/share/opto/castnode.hpp
  
  Co-authored-by: Emanuel Peter <emanuel.peter at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24575/files
  - new: https://git.openjdk.org/jdk/pull/24575/files/93b8b0c5..cab44429

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24575&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24575&range=07-08

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

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

From galder at openjdk.org  Fri Dec  5 14:02:06 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Fri, 5 Dec 2025 14:02:06 GMT
Subject: RFR: 8347273: C2: VerifyIterativeGVN for Ideal and Identity [v10]
In-Reply-To: <LbVQ1RSc8dPZV0NcohaV9wWvwgE9qLc8dunlhodMwHo=.96359d2d-076f-4cdf-962a-334d1b9ec480@github.com>
References: <D2JxhhSJt3FxdHxUaE1790GaGfNirmhcpErVJsfuh6w=.ec592c7a-de4e-4014-91f3-9f8d641c2f25@github.com>
 <1C0ByMoDpDlOmbDQVgBTQg7yKI0UaLtX92Xmf0bta4E=.0c060c5a-d60d-4cbe-84c5-03884116ef34@github.com>
 <LbVQ1RSc8dPZV0NcohaV9wWvwgE9qLc8dunlhodMwHo=.96359d2d-076f-4cdf-962a-334d1b9ec480@github.com>
Message-ID: <M8OTzbwaQijXhezwFbjBo8RHVVd-l8z0cLtUjG5Rask=.12f69dc2-7ba2-4a7e-a939-79818171ef59@github.com>

On Fri, 5 Dec 2025 13:35:22 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

>> Emanuel Peter 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 79 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8347273-verify-IGVN-Ideal-Identity
>>  - update comments for Christian
>>  - Apply suggestions from code review
>>    
>>    Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>>  - reorder flags for Christian
>>  - max_modes
>>  - use stringStream instead of ttyLocker
>>  - assert(false) for Christian
>>  - rename for Christian
>>  - Update src/hotspot/share/opto/phaseX.cpp
>>    
>>    Co-authored-by: Manuel H?ssig <manuel at haessig.org>
>>  - review suggestions, and handled a few more edge cases
>>  - ... and 69 more: https://git.openjdk.org/jdk/compare/968ce906...d9546d87
>
> src/hotspot/share/opto/phaseX.cpp line 1966:
> 
>> 1964:     //
>> 1965:     // Found with:
>> 1966:     //   compiler/codegen/TestBooleanVect.java
> 
> @eme64 Did you really encounter issues for this min/max codes with `TestBooleanVect`? Or is test name incorrect here?

Seems correct. I removed all the cases and indeed `TestBooleanVect` fails. All good :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22970#discussion_r2592791745

From roland at openjdk.org  Fri Dec  5 14:05:06 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Fri, 5 Dec 2025 14:05:06 GMT
Subject: RFR: 8354282: C2: more crashes in compiled code because of
 dependency on removed range check CastIIs [v10]
In-Reply-To: <qos-VYvgreqGsB7ke35RmM3L9uHnnM6nUsm2QONKXc4=.9c902d61-5f45-41f5-8276-ac28830c2bf5@github.com>
References: <qos-VYvgreqGsB7ke35RmM3L9uHnnM6nUsm2QONKXc4=.9c902d61-5f45-41f5-8276-ac28830c2bf5@github.com>
Message-ID: <S0C_y4_BZ3l56hm9XGUtrcbFy9kOHfKnllKwXuqUkkg=.763f7645-c941-48b6-a54c-76b2a8b8d547@github.com>

> This is a variant of 8332827. In 8332827, an array access becomes
> dependent on a range check `CastII` for another array access. When,
> after loop opts are over, that RC `CastII` was removed, the array
> access could float and an out of bound access happened. With the fix
> for 8332827, RC `CastII`s are no longer removed.
> 
> With this one what happens is that some transformations applied after
> loop opts are over widen the type of the RC `CastII`. As a result, the
> type of the RC `CastII` is no longer narrower than that of its input,
> the `CastII` is removed and the dependency is lost.
> 
> There are 2 transformations that cause this to happen:
> 
> - after loop opts are over, the type of the `CastII` nodes are widen
>   so nodes that have the same inputs but a slightly different type can
>   common.
>   
> - When pushing a `CastII` through an `Add`, if of the type both inputs
>   of the `Add`s are non constant, then we end up widening the type
>   (the resulting `Add` has a type that's wider than that of the
>   initial `CastII`).
>   
> There are already 3 types of `Cast` nodes depending on the
> optimizations that are allowed. Either the `Cast` is floating
> (`depends_only_test()` returns `true`) or pinned. Either the `Cast`
> can be removed if it no longer narrows the type of its input or
> not. We already have variants of the `CastII`:
> 
> - if the Cast can float and be removed when it doesn't narrow the type
> of its input.
> 
> - if the Cast is pinned and be removed when it doesn't narrow the type
> of its input.
> 
> - if the Cast is pinned and can't be removed when it doesn't narrow
> the type of its input.
> 
> What we need here, I think, is the 4th combination:
> 
> - if the Cast can float and can't be removed when it doesn't narrow
> the type of its input.
> 
> Anyway, things are becoming confusing with all these different
> variants named in ways that don't always help figure out what
> constraints one of them operate under. So I refactored this and that's
> the biggest part of this change. The fix consists in marking `Cast`
> nodes when their type is widen in a way that prevents them from being
> optimized out.
> 
> Tobias ran performance testing with a slightly different version of
> this change and there was no regression.

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

  review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24575/files
  - new: https://git.openjdk.org/jdk/pull/24575/files/cab44429..4a877c43

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24575&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24575&range=08-09

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

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

From roland at openjdk.org  Fri Dec  5 14:05:09 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Fri, 5 Dec 2025 14:05:09 GMT
Subject: RFR: 8354282: C2: more crashes in compiled code because of
 dependency on removed range check CastIIs [v8]
In-Reply-To: <m1ysk4e8E_cBjRPbnGy9d4UxXjG8SDh2JICWwd2zVRI=.cefc4dd5-ef0a-42ae-9e62-45295ab4bebc@github.com>
References: <qos-VYvgreqGsB7ke35RmM3L9uHnnM6nUsm2QONKXc4=.9c902d61-5f45-41f5-8276-ac28830c2bf5@github.com>
 <qab0P8PMsV9UzIT8JqUuAixFJbzNkpjd_FCSDnVB49U=.f52c826c-480f-4330-ba68-01b22f21b044@github.com>
 <m1ysk4e8E_cBjRPbnGy9d4UxXjG8SDh2JICWwd2zVRI=.cefc4dd5-ef0a-42ae-9e62-45295ab4bebc@github.com>
Message-ID: <5DHx3WmMb1UtSeyiEiYCiisVgRFggPFfxBggpgtuD6M=.d72a9c07-9624-47ea-9398-a0d1dee69755@github.com>

On Tue, 2 Dec 2025 17:32:09 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
>> 
>>  - Merge branch 'master' into JDK-8354282
>>  - whitespace
>>  - review
>>  - review
>>  - Update src/hotspot/share/opto/castnode.cpp
>>    
>>    Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>>  - Update src/hotspot/share/opto/castnode.cpp
>>    
>>    Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>>  - Update src/hotspot/share/opto/castnode.cpp
>>    
>>    Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>>  - Update test/hotspot/jtreg/compiler/c2/irTests/TestPushAddThruCast.java
>>    
>>    Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>>  - review
>>  - review
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/ef5e744a...93b8b0c5
>
> src/hotspot/share/opto/castnode.hpp line 105:
> 
>> 103:     // All the possible combinations of floating/narrowing with example use cases:
>> 104: 
>> 105:     // Use case example: Range Check CastII
> 
> I believe this is incorrect, a range check should be floating non-narrowing. It is only narrowing if the length of the array is a constant. It is because this cast encodes the dependency on the condition `index u< length`. This condition cannot be expressed in terms of `Type` unless `length` is a constant.

Range check `CastII` were added to protect the `ConvI2L` in the address expression on 64 bits. The problem there was, in some cases, that the `ConvI2L` would float above the range check (because `ConvI2L` has no control input) and could end up with an out of range input (which in turn would cause the `ConvI2L` to become `top` in places where it wasn't expected).
So `CastII` doesn't carry the control dependency of an array access on its range check. That dependency is carried by the `MemNode` which has its control input set to the range check.
What you're saying, if I understand it correctly, would be true if the `CastII` was required to prevent an array `Load` from floating. But that's not the case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24575#discussion_r2592801401

From roland at openjdk.org  Fri Dec  5 14:05:10 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Fri, 5 Dec 2025 14:05:10 GMT
Subject: RFR: 8354282: C2: more crashes in compiled code because of
 dependency on removed range check CastIIs [v8]
In-Reply-To: <Cc4kPMFfdFtp_BbY0vKneM2Vfk0R6MWSPDHr7IPTXbk=.3bfa561b-cfee-43e2-a7c0-3111a4fbd0db@github.com>
References: <qos-VYvgreqGsB7ke35RmM3L9uHnnM6nUsm2QONKXc4=.9c902d61-5f45-41f5-8276-ac28830c2bf5@github.com>
 <qab0P8PMsV9UzIT8JqUuAixFJbzNkpjd_FCSDnVB49U=.f52c826c-480f-4330-ba68-01b22f21b044@github.com>
 <eVM0N3eEULNEo24IpZAZJVQRaTsYvigY4arq-FQkrL0=.f17e309a-430d-4daf-a397-da383c463347@github.com>
 <0An6wz0QZZxtVg-lP4IyqWTekcYkSmvosrVWkI7cH70=.86c07374-2127-4892-a369-ceefa82dd0b7@github.com>
 <_rBmTvf064PXyVEAX4zqk43DNgVr0gQDPzPcdQ4XI1A=.660e7e89-0a49-47e0-9639-972cbfbac5f0@github.com>
 <4qc5jJ1KA09yko5rWioBGstpuuRNxOiNWXRdRdh9h_E=.17c8ace8-c672-4451-bd15-247d66d92cef@github.com>
 <TFNSHF-AKiqE5cWd2FcbyW0akq0NNYzqYS8hLIRfXo4=.5ada81f6-b099-45d2-adf8-cbce720f0a8a@github.com>
 <Cc4kPMFfdFtp_BbY0vKneM2Vfk0R6MWSPDHr7IPTXbk=.3bfa561b-cfee-43e2-a7c0-3111a4fbd0db@github.com>
Message-ID: <PtyQNC-WYVwd6IY2ZSC_GSXHCnjrQrmPywptLI_Ws2Y=.ac045930-dd1b-4474-89b9-e9f513ffa93d@github.com>

On Tue, 2 Dec 2025 17:41:37 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Ok, I now read the PR from the top, and not just recent changes. If one were to start reading from the top, it would be clear without my suggestions here. But I think it could still be good to apply something about letting the Cast float to where we would hoist the RC.
>
> Naming is hard, but it is worth pointing out in the comment that floating here refers to `depends_only_on_test`. In other words, a cast is considered floating if it is legal to change the control input of a cast from an `IfTrue` or `IfFalse` to an `IfTrue` and `IfFalse` that dominates the current control input, and the corresponding conditions of the `If`s are the same. In contrast, we cannot do that for a pinned cast, and if the control is folded away, the control input of the pinned cast is changed to the control predecessor of the folded node.
> 
> It is also worth noting that we have `Node::pinned` which means the node is pinned AT the control input while pinned here means that it is pinned UNDER the control input. Very confusing!

I added a mention of `depends_only_on_test`. Is that good enough?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24575#discussion_r2592784214

From epeter at openjdk.org  Fri Dec  5 14:28:38 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 5 Dec 2025 14:28:38 GMT
Subject: RFR: 8351889: C2 crash: assertion failed:  Base pointers must
 match (addp 344) [v5]
In-Reply-To: <lJ_q1MxUgjyRIHuOAAMwlgZV-V4ZbXicJ78Gyry2dIQ=.b1085ad9-0870-467c-b27a-773a2d4a4e3e@github.com>
References: <IKOYjLXrS8q1GMjbaL2HOBNH8Oa_16k4WBa2NaMngS8=.c6fd7fbb-4758-48b2-a992-3702b2718e59@github.com>
 <lJ_q1MxUgjyRIHuOAAMwlgZV-V4ZbXicJ78Gyry2dIQ=.b1085ad9-0870-467c-b27a-773a2d4a4e3e@github.com>
Message-ID: <2o1eUSi-ngISF33nhD0ie40H3PUeyT0rrV1DYjd7Ud4=.b05b3657-c32d-477a-8834-8747a8e98ed0@github.com>

On Fri, 5 Dec 2025 13:48:50 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> The test case has an out of loop `Store` with an `AddP` address
>> expression that has other uses and is in the loop body. Schematically,
>> only showing the address subgraph and the bases for the `AddP`s:
>> 
>> 
>> Store#195 -> AddP#133 -> AddP#134 -> CastPP#110
>>                      -> CastPP#110
>> 
>> 
>> Both `AddP`s have the same base, a `CastPP` that's also in the loop
>> body.
>> 
>> That loop is a counted loop and only has 3 iterations so is fully
>> unrolled. First, one iteration is peeled:
>> 
>> 
>>                                 /-> CastPP#110
>> Store#195 -> Phi#360 -> AddP#133 -> AddP#134 -> CastPP#110
>>                     -> AddP#277 -> AddP#278 -> CastPP#283
>>                                 -> CastPP#283
>> 
>> 
>> 
>> The `AddP`s and `CastPP` are cloned (because in the loop body). As
>> part of peeling, `PhaseIdealLoop::peeled_dom_test_elim()` is
>> called. It finds the test that guards `CastPP#283` in the peeled
>> iteration dominates and replaces the test that guards `CastPP#110`
>> (the test in the peeled iteration is the clone of the test in the
>> loop). That causes `CastPP#110`'s control to be updated to that of the
>> test in the peeled iteration and to be yanked from the loop. So now
>> `CastPP#283` and `CastPP#110` have the same inputs.
>> 
>> Next unrolling happens:
>> 
>> 
>>                                            /-> CastPP#110
>>                                /-> AddP#400 -> AddP#401 -> CastPP#110
>> Store#195 -> Phi#360 -> Phi#477 -> AddP#133 -> AddP#134 -> CastPP#110
>>                   \                        -> CastPP#110
>>                    -> AddP#277 -> AddP#278 -> CastPP#283
>>                                -> CastPP#283
>> 
>> 
>> 
>> `AddP`s are cloned once more but not the `CastPP`s because they are
>> both in the peeled iteration now. A new `Phi` is added.
>> 
>> Next igvn runs. It's going to push the `AddP`s through the `Phi`s.
>> 
>> Through `Phi#477`:
>> 
>> 
>> 
>>                                 /-> CastPP#110
>> Store#195 -> Phi#360 -> AddP#510 -> Phi#509 -> AddP#401 -> CastPP#110
>>                   \                        -> AddP#134 -> CastPP#110
>>                    -> AddP#277 -> AddP#278 -> CastPP#283
>>                                -> CastPP#283
>> 
>> 
>> 
>> Through `Phi#360`:
>> 
>> 
>>                                            /-> AddP#134 -> CastPP#110
>>                                 /-> Phi#509 -> AddP#401 -> CastPP#110
>> Store#195 -> AddP#516 -> Phi#515 -> AddP#278 -> CastPP#283
>>                      -> Phi#514 -> CastPP#283
>>  ...
>
> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Excellent, this looks great! Thanks for the updates @rwestrel !

I did not run testing again now. I think we can do that when a second reviewer gives the approval :)

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

Marked as reviewed by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25386#pullrequestreview-3544999922

From epeter at openjdk.org  Fri Dec  5 14:28:44 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 5 Dec 2025 14:28:44 GMT
Subject: RFR: 8351889: C2 crash: assertion failed:  Base pointers must
 match (addp 344) [v2]
In-Reply-To: <Bhla13OznDGq-IiiVXHGO6bdh4s4-oNou9I13IcYprc=.d50b2219-4a78-4169-abbf-5f6b06398e52@github.com>
References: <IKOYjLXrS8q1GMjbaL2HOBNH8Oa_16k4WBa2NaMngS8=.c6fd7fbb-4758-48b2-a992-3702b2718e59@github.com>
 <yTXik4qj-ATkbr-xboirhZpRKH_MAmTmeNmDfJ9Q_RQ=.9a750626-b8e4-4142-b034-008424d2eeef@github.com>
 <Bhla13OznDGq-IiiVXHGO6bdh4s4-oNou9I13IcYprc=.d50b2219-4a78-4169-abbf-5f6b06398e52@github.com>
Message-ID: <Gw1n7QdKureNVBAaHKOLQSEt94pYdlKVos8ZO9NYnT0=.2f9f1e71-9008-46fc-918a-5c1b65f86b59@github.com>

On Thu, 2 Oct 2025 04:03:58 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - test seed
>>  - more
>>  - Merge branch 'master' into JDK-8351889
>>  - Merge branch 'master' into JDK-8351889
>>  - more
>>  - test
>>  - fix
>
> What if we just relax the assert?  I failed to figure out what this assert is protecting us from by looking at the code.  So what happens in a product build or when this assert is commented out?

@dean-long @galderz Do you want to do the second review?

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

PR Comment: https://git.openjdk.org/jdk/pull/25386#issuecomment-3617140509

From bkilambi at openjdk.org  Fri Dec  5 14:45:10 2025
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Fri, 5 Dec 2025 14:45:10 GMT
Subject: RFR: 8371711: AArch64: SVE intrinsics for Arrays.sort methods (int,
 float)
Message-ID: <8i4snpt_829luK8hB9U6qgJ833kiNK1hPe7IckfaoJ8=.5cd666c6-b4c9-4ff5-bb39-d1243afd61f0@github.com>

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            10000    avgt    3      0.99    1.72
ArraysSort.floatSort            100000   avgt    3      1.00    1.94
ArraysSort.floatSort            1000000  avgt    3      1.00    2.13
ArraysSort.intParallelSort      10       avgt    3      1.08    1.08
ArraysSort.intParallelSort      25       avgt    3      1.04    1.05
ArraysSort.intParallelSort      50       avgt    3      1.29    1.30
ArraysSort.intParallelSort      75       avgt    3      1.16    1.16
ArraysSort.intParallelSort      100      avgt    3      1.07    1.07
ArraysSort.intParallelSort      1000     avgt    3      1.13    1.13
ArraysSort.intParallelSort      10000    avgt    3      1.49    1.38
ArraysSort.intParallelSort      100000   avgt    3      1.64    1.62
ArraysSort.intParallelSort      1000000  avgt    3      2.26    2.27
ArraysSort.intSort              10       avgt    3      1.08    1.08
ArraysSort.intSort              25       avgt    3      1.02    1.02
ArraysSort.intSort              50       avgt    3      1.25    1.25
ArraysSort.intSort              75       avgt    3      1.16    1.20
ArraysSort.intSort              100      avgt    3      1.07    1.07
ArraysSort.intSort              1000     avgt    3      1.12    1.13
ArraysSort.intSort              10000    avgt    3      1.94    1.95
ArraysSort.intSort              100000   avgt    3      1.86    1.86
ArraysSort.intSort              1000000  avgt    3      2.09    2.09


On Neoverse V2:


Benchmark                       (size)   Mode    Cnt    A       B
ArraysSort.floatParallelSort    10       avgt    3      1.02    1.02
ArraysSort.floatParallelSort    25       avgt    3      0.97    0.71
ArraysSort.floatParallelSort    50       avgt    3      0.94    0.65
ArraysSort.floatParallelSort    75       avgt    3      0.96    0.82
ArraysSort.floatParallelSort    100      avgt    3      0.95    0.84
ArraysSort.floatParallelSort    1000     avgt    3      1.01    0.94
ArraysSort.floatParallelSort    10000    avgt    3      1.01    1.25
ArraysSort.floatParallelSort    100000   avgt    3      1.01    1.09
ArraysSort.floatParallelSort    1000000  avgt    3      1.00    1.10
ArraysSort.floatSort            10       avgt    3      1.02    1.00
ArraysSort.floatSort            25       avgt    3      0.99    0.76
ArraysSort.floatSort            50       avgt    3      0.97    0.66
ArraysSort.floatSort            75       avgt    3      1.01    0.83
ArraysSort.floatSort            100      avgt    3      1.00    0.85
ArraysSort.floatSort            1000     avgt    3      0.99    0.93
ArraysSort.floatSort            10000    avgt    3      1.00    1.28
ArraysSort.floatSort            100000   avgt    3      1.00    1.37
ArraysSort.floatSort            1000000  avgt    3      1.00    1.48
ArraysSort.intParallelSort      10       avgt    3      1.05    1.05
ArraysSort.intParallelSort      25       avgt    3      0.99    0.84
ArraysSort.intParallelSort      50       avgt    3      1.03    1.14
ArraysSort.intParallelSort      75       avgt    3      0.91    0.99
ArraysSort.intParallelSort      100      avgt    3      0.98    0.96
ArraysSort.intParallelSort      1000     avgt    3      1.32    1.30
ArraysSort.intParallelSort      10000    avgt    3      1.40    1.40
ArraysSort.intParallelSort      100000   avgt    3      1.00    1.04
ArraysSort.intParallelSort      1000000  avgt    3      1.15    1.14
ArraysSort.intSort              10       avgt    3      1.05    1.05
ArraysSort.intSort              25       avgt    3      1.03    1.03
ArraysSort.intSort              50       avgt    3      1.08    1.14
ArraysSort.intSort              75       avgt    3      0.88    0.98
ArraysSort.intSort              100      avgt    3      1.01    0.99
ArraysSort.intSort              1000     avgt    3      1.3     1.32
ArraysSort.intSort              10000    avgt    3      1.43    1.43
ArraysSort.intSort              100000   avgt    3      1.30    1.30
ArraysSort.intSort              1000000  avgt    3      1.37    1.37

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

Commit messages:
 - AArch64 SVE implementation for Arrays.sort
 - Prepare base for SVE implementation in libsimdsort

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

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

From roland at openjdk.org  Fri Dec  5 14:52:51 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Fri, 5 Dec 2025 14:52:51 GMT
Subject: RFR: 8344116: C2: remove slice parameter from LoadNode::make [v13]
In-Reply-To: <nK1pBktv_yvYEM2aBdvRLT_8-msPgAm7A25-mtJZey4=.1776a51e-7df7-4e84-9fe8-229eae1f9970@github.com>
References: <Po0DIjZv6wmSdwNcL1BeN5s9xvih8YKDqaw7Io5wIl8=.82dc3319-de61-4afc-898c-a7550bf9c9ac@github.com>
 <CukQodDOO4993Qbcwca_3G0TULTVhaZp4sJc2_s1U-g=.5e8e3dbb-c91c-4d71-84d2-0ae6816ca6f0@github.com>
 <qoYq2xfVb-8DqSX6eCtrCOu4pbQFO-mr5peJJiQ8F2s=.1756d12f-9f54-4d17-a569-106a330f9935@github.com>
 <2oDqUvcW_3hJRPRri4uttpkgfeCovL4ZZkcI0R1bB1A=.173b3a58-d0f1-4b29-94d1-77b0a350c790@github.com>
 <2wAnS7drj_r3dqsy5CEF9vBG40KizHsQDOxMeNymwhw=.9bc29879-eead-401c-b750-814592feff63@github.com>
 <-1wiWF_UEvCO6xPuYvIsElBzPPQDejGahm9Xd5YszPU=.cfb41cb1-f681-4e75-8c29-2d928468f53b@github.com>
 <nK1pBktv_yvYEM2aBdvRLT_8-msPgAm7A25-mtJZey4=.1776a51e-7df7-4e84-9fe8-229eae1f9970@github.com>
Message-ID: <42lOFbyCuQt4xj-pK-ME6ScceXqTnGOY0HrWnJMK56k=.87b29936-511f-4ba4-a429-e8b9faed83a2@github.com>

On Sun, 30 Nov 2025 08:03:32 GMT, Zihao Lin <duke at openjdk.org> wrote:

>> I had a closer look and I think you ran into an inconsistency. Let me see if I can get it fixed as a separate change.
>
> Sure, it's better to separate to another change. I am not familiar this part, please pin me if you have better solution. Thanks!

I filed https://bugs.openjdk.org/browse/JDK-8373143 for this but I keep finding new issues. So this one will take some time.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24258#discussion_r2592955645

From fgao at openjdk.org  Fri Dec  5 15:25:15 2025
From: fgao at openjdk.org (Fei Gao)
Date: Fri, 5 Dec 2025 15:25:15 GMT
Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() [v4]
In-Reply-To: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com>
References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com>
Message-ID: <syk4LZyr75-MUPGmSyJmsuWWCIjWOcens1nGBjWLqF0=.773a2cef-3dda-4611-9e56-3ffe6be1de80@github.com>

> 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 nine additional commits since the last revision:

 - 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
 - 8363620: AArch64: reimplement emit_static_call_stub()
   
   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 bytes 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

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26638/files
  - new: https://git.openjdk.org/jdk/pull/26638/files/6d3669c1..59c842bd

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

  Stats: 18818 lines in 405 files changed: 9853 ins; 6916 del; 2049 mod
  Patch: https://git.openjdk.org/jdk/pull/26638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26638/head:pull/26638

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

From fgao at openjdk.org  Fri Dec  5 15:32:34 2025
From: fgao at openjdk.org (Fei Gao)
Date: Fri, 5 Dec 2025 15:32:34 GMT
Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() [v3]
In-Reply-To: <ssEDRY-9OkcWXfXLZIioSzz3_luPHLR3E_aoczbOCVM=.2bf5bd10-89de-44e4-8e5c-369dd89c3bce@github.com>
References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com>
 <SIYhGsf5_2F6gUNHFuGT_mOGFR2QO5E-ZntNCqFqDqM=.0d56c710-10eb-4f39-b2fc-664cc4e0cce1@github.com>
 <kta_3vVQvi-NedQaVoVJKN5rypJUDDLHMqFWC6fDg-M=.5e844253-9bf7-40fe-8b24-720cad918c63@github.com>
 <ssEDRY-9OkcWXfXLZIioSzz3_luPHLR3E_aoczbOCVM=.2bf5bd10-89de-44e4-8e5c-369dd89c3bce@github.com>
Message-ID: <koJgIyLmsksmDuucQarob4XO1wSWTUeTDRwKgORf_dc=.4d8f214d-3790-4650-8a83-5f617622f2cc@github.com>

On Thu, 4 Dec 2025 11:54:31 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/compiledIC_aarch64.cpp line 180:
>> 
>>> 178:     nativeCallTrampolineStub_at(trampoline_stub_addr)->set_destination(stub);
>>> 179:   }
>>> 180: 
>> 
>> Suggestion:
>> 
>> 
>>   // This code is executed while other threads are running. We must                                                                                                                  
>>   // ensure that at all times there is a valid path of execution. A                                                                                                                  
>>   // racing thread either observes a call (possibly via a trampoline)                                                                                                                
>>   // to SharedRuntime::resolve_static_call_C or a complete call to the                                                                                                               
>>   // interpreter.                                                                                                                                                                    
>>   //                                                                                                                                                                                 
>>   // If a racing thread observes an updated direct branch at a call                                                                                                                  
>>   // site, it must also observe all of the updated instructions in the                                                                                                               
>>   // static interpreter stub.                                                                                                                                                        
>>   //                                                                                                                                                                                 
>>   // To ensure this, we first update the static interpreter stub, then                                                                                                               
>>   // the trampoline, then the direct branch at the call site.                                                                                                                        
>>   //                                                                                              ...
>
> Here's my thinking:
> 
> First say what you want to achieve and why.
> 
> Be definite about what you say in comments. Avoid words like "generally", for example. Always use the strongest words you can. For example, "because" is stronger than "since".
> 
> Be concise. The purpose of all code is to ensure correctness, so you don't have to say so.
> 
> This comment is not perfect, so feel free to amend anything that is unclear.

@theRealAph Many thanks for your feedback and your time! 

I?ve updated the commit with your suggestion. I made a small adjustment on top of what you proposed?hope it?s not unnecessary.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26638#discussion_r2593083821

From fgao at openjdk.org  Fri Dec  5 15:49:15 2025
From: fgao at openjdk.org (Fei Gao)
Date: Fri, 5 Dec 2025 15:49:15 GMT
Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() [v5]
In-Reply-To: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com>
References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com>
Message-ID: <HJEaGuERxWK3yRAacXiugTXtP4fcl2iS9F69D4ctroM=.24ade772-5208-44f6-a9dd-47d4e53fa410@github.com>

> 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 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:

  Update comments based on Aph's suggestion

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26638/files
  - new: https://git.openjdk.org/jdk/pull/26638/files/59c842bd..f03979a1

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

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

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

From ayang at openjdk.org  Fri Dec  5 16:18:01 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 5 Dec 2025 16:18:01 GMT
Subject: RFR: 8373145: [BACKOUT] Remove
 ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch
Message-ID: <wsubNSyCl36aHMLgp74oRAj9as94uzm88IUhip6HW8A=.6e383a45-ed6c-45eb-b1f1-42e575262eec@github.com>

Clean revert of [JDK-8371643](https://bugs.openjdk.org/browse/JDK-8371643) to reduce CI noise.

`runtime/cds/appcds/methodHandles/MethodHandlesSpreadArgumentsTest.java` with `-XX:+UseZGC -XX:+UseCompactObjectHeaders` fails 10% of the time.

After the revert, the test passes 2K runs.

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

Commit messages:
 - Revert "8371643: Remove ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch"

Changes: https://git.openjdk.org/jdk/pull/28679/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28679&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373145
  Stats: 69 lines in 7 files changed: 66 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/28679.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28679/head:pull/28679

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

From mdoerr at openjdk.org  Fri Dec  5 16:33:10 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 5 Dec 2025 16:33:10 GMT
Subject: RFR: 8373145: [BACKOUT] Remove
 ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch
In-Reply-To: <wsubNSyCl36aHMLgp74oRAj9as94uzm88IUhip6HW8A=.6e383a45-ed6c-45eb-b1f1-42e575262eec@github.com>
References: <wsubNSyCl36aHMLgp74oRAj9as94uzm88IUhip6HW8A=.6e383a45-ed6c-45eb-b1f1-42e575262eec@github.com>
Message-ID: <kVxSIzA82tl_oFjO97zHeLzpOlSrvtMpzeQkwBx6JBk=.a8e5783e-27fd-4275-8014-dcd346552548@github.com>

On Fri, 5 Dec 2025 16:09:45 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Clean revert of [JDK-8371643](https://bugs.openjdk.org/browse/JDK-8371643) to reduce CI noise.
> 
> `runtime/cds/appcds/methodHandles/MethodHandlesSpreadArgumentsTest.java` with `-XX:+UseZGC -XX:+UseCompactObjectHeaders` fails 10% of the time.
> 
> After the revert, the test passes 2K runs.

Backout is correct (clean).

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28679#pullrequestreview-3545488972

From kvn at openjdk.org  Fri Dec  5 17:20:56 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 5 Dec 2025 17:20:56 GMT
Subject: RFR: 8373145: [BACKOUT] Remove
 ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch
In-Reply-To: <wsubNSyCl36aHMLgp74oRAj9as94uzm88IUhip6HW8A=.6e383a45-ed6c-45eb-b1f1-42e575262eec@github.com>
References: <wsubNSyCl36aHMLgp74oRAj9as94uzm88IUhip6HW8A=.6e383a45-ed6c-45eb-b1f1-42e575262eec@github.com>
Message-ID: <ti5ZnuL9vvYHPsmHL9jOqc8_2S9HWKEwHY8AOaAejxU=.aeba4867-b8e6-4994-8de4-6d2ef6696091@github.com>

On Fri, 5 Dec 2025 16:09:45 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Clean revert of [JDK-8371643](https://bugs.openjdk.org/browse/JDK-8371643) to reduce CI noise.
> 
> `runtime/cds/appcds/methodHandles/MethodHandlesSpreadArgumentsTest.java` with `-XX:+UseZGC -XX:+UseCompactObjectHeaders` fails 10% of the time.
> 
> After the revert, the test passes 2K runs.

Good.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28679#pullrequestreview-3545668409

From eastigeevich at openjdk.org  Fri Dec  5 17:52:20 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Fri, 5 Dec 2025 17:52:20 GMT
Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact
 on GCs and JIT performance [v14]
In-Reply-To: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
Message-ID: <Z9pHy1Dz1gFWexsxfR1coHVGaHQDzL24trTRJ-2aR_o=.255edf2f-d25e-434d-8aca-d0af575f5006@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 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.
> 
> Benchmarking results: Neoverse-N1 r3p1 (Graviton 2)
> 
> - Baseline
> 
> $ taskset -c 0-3 java -Xbootclasspath/a:./wb.jar -XX:+UnlockDiagnosticVMOptions -XX:-NeoverseN1Errata1542419 -XX:+UseZGC -XX:ZYoungGCThreads=1 -XX:ZOldGC...

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

  Implement nested ICacheInvalidationContext

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28328/files
  - new: https://git.openjdk.org/jdk/pull/28328/files/4b04496f..b9380fd8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28328&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28328&range=12-13

  Stats: 402 lines in 27 files changed: 162 ins; 167 del; 73 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 erikj at openjdk.org  Fri Dec  5 19:00:55 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 5 Dec 2025 19:00:55 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: <ntE273ScH2i1lAZ-7M4GYVnDx4OkGsAUGJ_cwLYx17o=.76057e40-3a46-4709-ac3c-ccfa8cd8172b@github.com>

On Fri, 5 Dec 2025 09:44:16 GMT, Bhavana Kilambi <bkilambi at openjdk.org> 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            ...

make/modules/java.base/Lib.gmk line 225:

> 223: 
> 224:   TARGETS += $(BUILD_LIBSIMD_SORT)
> 225: endif

This whole block should be combined with the existing block above, something like this:


ifeq ($(call isTargetOs, linux)+$(call isTargetCpu, x86_64 aarch64)+$(INCLUDE_COMPILER2)+$(filter $(TOOLCHAIN_TYPE), gcc), true+true+true+gcc)
  ##############################################################################
  ## Build libsimdsort
  ##############################################################################

  $(eval $(call SetupJdkLibrary, BUILD_LIBSIMD_SORT, \
      NAME := simdsort, \
      LINK_TYPE := C++, \
      OPTIMIZATION := HIGH, \
      INCLUDES := $(OPENJDK_TARGET_CPU_ARCH), \
      CXXFLAGS := -std=c++17, \
      CXXFLAGS_linux_aarch64 := -march=armv8.2-a+sve, \
      DISABLED_WARNINGS_gcc := unused-variable, \
      LIBS_linux := $(LIBM), \
  ))

  TARGETS += $(BUILD_LIBSIMD_SORT)
endif


Unfortunately we don't currently support CXXFLAGS_<os>_<cpu>, just CFLAGS_<os>_<cpu>, but this can be fixed and I think it should be since we now have a need for it.


diff --git a/make/common/native/Flags.gmk b/make/common/native/Flags.gmk
index efb4c08e74c..2f3680af7c7 100644
--- a/make/common/native/Flags.gmk
+++ b/make/common/native/Flags.gmk
@@ -106,10 +106,12 @@ define SetupCompilerFlags
     $1_EXTRA_CFLAGS += -DSTATIC_BUILD=1
   endif
 
-  # Pickup extra OPENJDK_TARGET_OS_TYPE, OPENJDK_TARGET_OS and/or TOOLCHAIN_TYPE
-  # dependent variables for CXXFLAGS.
+  # Pickup extra OPENJDK_TARGET_OS_TYPE, OPENJDK_TARGET_OS, TOOLCHAIN_TYPE and
+  # OPENJDK_TARGET_OS plus OPENJDK_TARGET_CPU pair dependent variables for
+  # CXXFLAGS.
   $1_EXTRA_CXXFLAGS := $$($1_CXXFLAGS_$(OPENJDK_TARGET_OS_TYPE)) $$($1_CXXFLAGS_$(OPENJDK_TARGET_OS)) \
-      $$($1_CXXFLAGS_$(TOOLCHAIN_TYPE))
+      $$($1_CXXFLAGS_$(TOOLCHAIN_TYPE)) \
+      $$($1_CXXFLAGS_$(OPENJDK_TARGET_OS)_$(OPENJDK_TARGET_CPU))
 
   ifneq ($(DEBUG_LEVEL), release)
     # Pickup extra debug dependent variables for CXXFLAGS


The above at least compiles for me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28675#discussion_r2593665862

From ayang at openjdk.org  Fri Dec  5 19:20:12 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 5 Dec 2025 19:20:12 GMT
Subject: RFR: 8373145: [BACKOUT] Remove
 ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch
In-Reply-To: <wsubNSyCl36aHMLgp74oRAj9as94uzm88IUhip6HW8A=.6e383a45-ed6c-45eb-b1f1-42e575262eec@github.com>
References: <wsubNSyCl36aHMLgp74oRAj9as94uzm88IUhip6HW8A=.6e383a45-ed6c-45eb-b1f1-42e575262eec@github.com>
Message-ID: <u73wLCBJ4gBOn9Z-UQqsxWXWav2ILNbSt6InF3Od_qc=.c89256c7-2686-4171-94a5-c4e709230d94@github.com>

On Fri, 5 Dec 2025 16:09:45 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Clean revert of [JDK-8371643](https://bugs.openjdk.org/browse/JDK-8371643) to reduce CI noise.
> 
> `runtime/cds/appcds/methodHandles/MethodHandlesSpreadArgumentsTest.java` with `-XX:+UseZGC -XX:+UseCompactObjectHeaders` fails 10% of the time.
> 
> After the revert, the test passes 2K runs.

Thanks for review. Merging now to resolve CI failures.

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

PR Comment: https://git.openjdk.org/jdk/pull/28679#issuecomment-3618235905

From ayang at openjdk.org  Fri Dec  5 19:20:13 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 5 Dec 2025 19:20:13 GMT
Subject: Integrated: 8373145: [BACKOUT] Remove
 ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch
In-Reply-To: <wsubNSyCl36aHMLgp74oRAj9as94uzm88IUhip6HW8A=.6e383a45-ed6c-45eb-b1f1-42e575262eec@github.com>
References: <wsubNSyCl36aHMLgp74oRAj9as94uzm88IUhip6HW8A=.6e383a45-ed6c-45eb-b1f1-42e575262eec@github.com>
Message-ID: <yJUmj5QMXJUQv1YGYp0msZs4aAaJo0OwKeuLf7tOzUE=.e2261367-aef9-419e-9491-aacb4cdf167e@github.com>

On Fri, 5 Dec 2025 16:09:45 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Clean revert of [JDK-8371643](https://bugs.openjdk.org/browse/JDK-8371643) to reduce CI noise.
> 
> `runtime/cds/appcds/methodHandles/MethodHandlesSpreadArgumentsTest.java` with `-XX:+UseZGC -XX:+UseCompactObjectHeaders` fails 10% of the time.
> 
> After the revert, the test passes 2K runs.

This pull request has now been integrated.

Changeset: 43787890
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/43787890291d71de61b28b8a4e3bf9aaba46757a
Stats:     69 lines in 7 files changed: 66 ins; 0 del; 3 mod

8373145: [BACKOUT] Remove ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch

Reviewed-by: mdoerr, kvn

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

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

From sviswanathan at openjdk.org  Fri Dec  5 19:50:01 2025
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 5 Dec 2025 19:50:01 GMT
Subject: RFR: 8349452: Fix performance regression for Arrays.fill() with
 AVX512 [v10]
In-Reply-To: <N-7XCtb2GXLv10t2lo8jkzoMbI-f0LAJ5gWNMQC4E5c=.098a9b7a-16a8-49f8-a327-9d0490c66e45@github.com>
References: <vR7Pzk96gG0PlTn5P5U1qlqyCvISC0dCMxUXyWHfy2g=.e58b097d-790c-4725-8ac8-7e8f2c94ac50@github.com>
 <N-7XCtb2GXLv10t2lo8jkzoMbI-f0LAJ5gWNMQC4E5c=.098a9b7a-16a8-49f8-a327-9d0490c66e45@github.com>
Message-ID: <nDxuYN2u47TFp3AradQDrSP9-nuMPA4SB-Y6vEnEOOY=.3b6b4535-20af-4777-9210-202f21766e2c@github.com>

On Thu, 4 Dec 2025 02:44:51 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

>> The goal of this PR is to fix the performance regression in Arrays.fill() x86 stubs caused by masked AVX stores. The fix is to replace the masked AVX stores with store instructions without masks (i.e. unmasked stores). `fill32_masked()` and `fill64_masked()` stubs are replaced with `fill32_unmasked()` and `fill64_unmasked()` respectively.
>> 
>> To speedup unmasked stores, array fills for sizes < 64 bytes are broken down into sequences of 32B, 16B, 8B, 4B, 2B and 1B stores, depending on the size.
>> 
>> 
>> ### **Performance comparison for byte array fills in a loop for 1 million times**
>> 
>> 
>> UseAVX=3   ByteArray Size | +OptimizeFill    (Masked store   stub)     [secs] | -OptimizeFill   (No stub)   [secs] | --->This PR: +OptimizeFill   (Unmasked store   stub)   [secs]
>> -- | -- | -- | --
>> 1 | 0.46 | 0.14 | 0.189
>> 2 | 0.46 | 0.16 | 0.191
>> 3 | 0.46 | 0.176 | 0.199
>> 4 | 0.46 | 0.244 | 0.212
>> 5 | 0.46 | 0.29 | 0.364
>> 10 | 0.46 | 0.58 | 0.354
>> 15 | 0.46 | 0.42 | 0.325
>> 16 | 0.46 | 0.46 | 0.281
>> 17 | 0.21 | 0.5 | 0.365
>> 20 | 0.21 | 0.37 | 0.326
>> 25 | 0.21 | 0.59 | 0.343
>> 31 | 0.21 | 0.53 | 0.317
>> 32 | 0.21 | 0.58 | 0.249
>> 35 | 0.5 | 0.77 | 0.303
>> 40 | 0.5 | 0.61 | 0.312
>> 45 | 0.5 | 0.52 | 0.364
>> 48 | 0.5 | 0.66 | 0.283
>> 49 | 0.22 | 0.69 | 0.367
>> 50 | 0.22 | 0.78 | 0.344
>> 55 | 0.22 | 0.67 | 0.332
>> 60 | 0.22 | 0.67 | 0.312
>> 64 | 0.22 | 0.82 | 0.253
>> 70 | 0.51 | 1.1 | 0.394
>> 80 | 0.49 | 0.89 | 0.346
>> 90 | 0.225 | 0.68 | 0.385
>> 100 | 0.54 | 1.09 | 0.364
>> 110 | 0.6 | 0.98 | 0.416
>> 120 | 0.26 | 0.75 | 0.367
>> 128 | 0.266 | 1.1 | 0.342
>
> Srinivas Vamsi Parasa has updated the pull request 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:
> 
>  - Fix for failing tests; keep dest pointer unchanged
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into fill_array
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into fill_array
>  - fix missing array length updates for size=1
>  - revert to jccb in one place
>  - remove all masked stores altogether
>  - fastpath for size <= 4 bytes
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into fill_array
>  - undo jccb to jcc change as needed
>  - refactor code to use fill32_tail at the end of the stub
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/57a0bfb1...f54dfd78

Looks good to me.

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

Marked as reviewed by sviswanathan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28442#pullrequestreview-3546213874

From coleenp at openjdk.org  Fri Dec  5 20:44:58 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 5 Dec 2025 20:44:58 GMT
Subject: RFR: 8366671: Refactor Thread::SpinAcquire and Thread::SpinRelease
 [v12]
In-Reply-To: <KbihuIqL_t7wzUfBlOrV_8WJBd_f7Bk5J2cabYY_588=.0db43b71-5b27-4734-9acd-d55e41cfb052@github.com>
References: <NtY8E8fBeSokCAQYP3OQEwfnppSugtTJ8uAtQtD0zvg=.88f2988d-47fd-4b8a-af89-488ed6b37870@github.com>
 <BLbZykwmGPMfOyN0A7lrjaht-OWDbWK9_ArQRZZTVCU=.4bbd7292-3028-44f2-b0a5-cb4f29c2044b@github.com>
 <Z0c-dWNWbxGumcLpse7-H3fGuAI5h9XBdu9bsJdRGeA=.bf035f09-aedf-401a-bf6d-90cf2568d48c@github.com>
 <g51FTZgI8RY6EqjJxfGYFe8RltiRQG8muogTidUqvJc=.95e1128b-d6e1-40cd-a624-aee2630fbfb7@github.com>
 <KbihuIqL_t7wzUfBlOrV_8WJBd_f7Bk5J2cabYY_588=.0db43b71-5b27-4734-9acd-d55e41cfb052@github.com>
Message-ID: <RDgpMBLrvMdqjHIGHkt07nePBNX6EEGVycu-zgFCGis=.1b1427dd-cd73-46e5-961f-7406cb5ea7a5@github.com>

On Fri, 5 Dec 2025 11:47:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Is this safety measure redundant though? I mean we move the code into a utility class, which may, potentially, end up being used in that context. It is not the case now, sure. If we do not allow that, we need document this and use a non-safe `current_or_null()`.
>
> Well we moved it for convenience but we really don't want it to start being used all over. :) I don't like this kind of "just in case" code as it indicates to me that we don't really know how/where the code is being used - and where do you draw the line? This is debug code so the performance aspect is not a concern, but I prefer not to have it but if you like document that this is not for use in signal-handling context. But this isn't a deal-breaker if others think it worth being ultra-conservative here.

I hadn't noticed the 'safe' variant of Thread::current_or_null, but it seems like it might be appropriate from the implementation if this can be called very early in VM initialization for ParkEvents.


inline Thread* Thread::current_or_null_safe() {
  if (ThreadLocalStorage::is_initialized()) {
    return ThreadLocalStorage::thread();
  }
  return nullptr;
}


It seems to cover more than the case of being called in a signal handler.  I think it's not a bad usage.  I was going to vote the other way until I saw the implementation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28264#discussion_r2593941064

From aph at openjdk.org  Sat Dec  6 09:45:59 2025
From: aph at openjdk.org (Andrew Haley)
Date: Sat, 6 Dec 2025 09:45:59 GMT
Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() [v5]
In-Reply-To: <HJEaGuERxWK3yRAacXiugTXtP4fcl2iS9F69D4ctroM=.24ade772-5208-44f6-a9dd-47d4e53fa410@github.com>
References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com>
 <HJEaGuERxWK3yRAacXiugTXtP4fcl2iS9F69D4ctroM=.24ade772-5208-44f6-a9dd-47d4e53fa410@github.com>
Message-ID: <kCnAXn60i3EpXO6HLT0_Pgk4HKNXtvHwGPq5EdjfdQY=.b0b50515-26ff-4e4a-99a4-11151f375da3@github.com>

On Fri, 5 Dec 2025 15:49:15 GMT, Fei Gao <fgao at openjdk.org> 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 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:
> 
>   Update comments based on Aph's suggestion

test/micro/org/openjdk/bench/vm/compiler/StaticCallStub.java line 68:

> 66:     public static class FarJump extends StaticCallStub {}
> 67: 
> 68: }

Suggestion:

}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26638#discussion_r2594687637

From aph at openjdk.org  Sat Dec  6 09:55:56 2025
From: aph at openjdk.org (Andrew Haley)
Date: Sat, 6 Dec 2025 09:55:56 GMT
Subject: RFR: 8372701: Randomized profile counters [v3]
In-Reply-To: <iJLtYeVBT40xFQvISBdToauPAJ_Ll_eZOHpW-QGEc5U=.700d48ea-95eb-48d0-bbed-fffe45ee6da5@github.com>
References: <jKjmIONZcytzVjS4absOwOLv_QOF9qhIJifYhN6JyP4=.dceced94-bc29-43e6-9062-8dc77c2a6133@github.com>
 <Z3xSycWsDflD-8z95W-cbINmyR5RcJeUpvG3mnxdtEE=.3247d5d9-a18a-414f-8fc8-c11346455dd8@github.com>
 <iJLtYeVBT40xFQvISBdToauPAJ_Ll_eZOHpW-QGEc5U=.700d48ea-95eb-48d0-bbed-fffe45ee6da5@github.com>
Message-ID: <gYgsUtJfUwn57DIypn94HS57kZw8GKiuZ4yohxQPdvc=.a5618230-0f44-44ff-b5e2-7ff684733aa6@github.com>

On Thu, 4 Dec 2025 13:39:15 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Thanks, still fails though:

Sure, but which configuration is that? I don't see such a failure in the Github tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/28541#issuecomment-3619828036

From aph at openjdk.org  Sat Dec  6 10:28:02 2025
From: aph at openjdk.org (Andrew Haley)
Date: Sat, 6 Dec 2025 10:28:02 GMT
Subject: RFR: 8372701: Randomized profile counters [v4]
In-Reply-To: <jKjmIONZcytzVjS4absOwOLv_QOF9qhIJifYhN6JyP4=.dceced94-bc29-43e6-9062-8dc77c2a6133@github.com>
References: <jKjmIONZcytzVjS4absOwOLv_QOF9qhIJifYhN6JyP4=.dceced94-bc29-43e6-9062-8dc77c2a6133@github.com>
Message-ID: <CjfS8zXtvye99E6j5rz7U4mO7SLE5aU7u4U4vBW8b4Y=.2cb24d4b-c385-4d37-9ba2-bc96b804b975@github.com>

> 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:

  Fix x86 lambda

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28541/files
  - new: https://git.openjdk.org/jdk/pull/28541/files/a7476d22..a5c094e9

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

  Stats: 1 line in 1 file changed: 0 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 aph at openjdk.org  Sat Dec  6 10:35:55 2025
From: aph at openjdk.org (Andrew Haley)
Date: Sat, 6 Dec 2025 10:35:55 GMT
Subject: RFR: 8372701: Randomized profile counters [v3]
In-Reply-To: <gYgsUtJfUwn57DIypn94HS57kZw8GKiuZ4yohxQPdvc=.a5618230-0f44-44ff-b5e2-7ff684733aa6@github.com>
References: <jKjmIONZcytzVjS4absOwOLv_QOF9qhIJifYhN6JyP4=.dceced94-bc29-43e6-9062-8dc77c2a6133@github.com>
 <Z3xSycWsDflD-8z95W-cbINmyR5RcJeUpvG3mnxdtEE=.3247d5d9-a18a-414f-8fc8-c11346455dd8@github.com>
 <iJLtYeVBT40xFQvISBdToauPAJ_Ll_eZOHpW-QGEc5U=.700d48ea-95eb-48d0-bbed-fffe45ee6da5@github.com>
 <gYgsUtJfUwn57DIypn94HS57kZw8GKiuZ4yohxQPdvc=.a5618230-0f44-44ff-b5e2-7ff684733aa6@github.com>
Message-ID: <J9sDnvvGblxmdcXr9xZ1uDaTCZee2qnyUiz26iEeLKM=.3887d6be-8140-412f-9cf8-5deb86373256@github.com>

On Sat, 6 Dec 2025 09:53:41 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > Thanks, still fails though:
> 
> Sure, but which configuration is that? I don't see such a failure in the Github tests.

I just did a macos x86 and aarch64 minimal build, and it's fine too. I have no idea what you are seeing

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

PR Comment: https://git.openjdk.org/jdk/pull/28541#issuecomment-3619881503

From zlin at openjdk.org  Sat Dec  6 12:07:04 2025
From: zlin at openjdk.org (Zihao Lin)
Date: Sat, 6 Dec 2025 12:07:04 GMT
Subject: RFR: 8344116: C2: remove slice parameter from LoadNode::make [v15]
In-Reply-To: <Po0DIjZv6wmSdwNcL1BeN5s9xvih8YKDqaw7Io5wIl8=.82dc3319-de61-4afc-898c-a7550bf9c9ac@github.com>
References: <Po0DIjZv6wmSdwNcL1BeN5s9xvih8YKDqaw7Io5wIl8=.82dc3319-de61-4afc-898c-a7550bf9c9ac@github.com>
Message-ID: <y591wIg09v6OFJYoOJtLui8MUh5mHSxT-sf-YWyWc9M=.9dfe7396-4edd-452b-a083-15c94604700f@github.com>

> This patch remove slice parameter from LoadNode::make
> 
> I have done more work which remove slice paramater from StoreNode::make.
> 
> Mention in https://github.com/openjdk/jdk/pull/21834#pullrequestreview-2429164805
> 
> Hi team, I am new, I'd appreciate any guidance. Thank a lot!

Zihao Lin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:

 - Merge branch 'master' into 8344116
 - Merge branch 'master' into 8344116
 - remove adr_type from graphKit
 - Fix test failed
 - Merge branch 'openjdk:master' into 8344116
 - Merge branch 'openjdk:master' into 8344116
 - fix conflict
 - Merge master
 - remove C2AccessValuePtr
 - fix assert
 - ... and 8 more: https://git.openjdk.org/jdk/compare/b0f59f60...c526f021

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

Changes: https://git.openjdk.org/jdk/pull/24258/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24258&range=14
  Stats: 316 lines in 22 files changed: 47 ins; 89 del; 180 mod
  Patch: https://git.openjdk.org/jdk/pull/24258.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24258/head:pull/24258

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

From asmehra at openjdk.org  Sun Dec  7 02:45:55 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Sun, 7 Dec 2025 02:45:55 GMT
Subject: RFR: 8373114: Redundant MethodCounters in the preimage generated
 by training run
In-Reply-To: <LU5FoKbfXYJE26LzMgqcNd4H1LXgESe0gQQ8lw4C6aA=.58fdd835-a897-40f1-ac61-61bca374d4a9@github.com>
References: <LRw06Cn_4dcRW8YyFVr3RijMHIha7nPzBrcNNzaIny8=.dc07d0ee-b797-4434-aad0-956a00c2ea6f@github.com>
 <agWLS8uUUOXgaeU9ka0naNgVYhtrXSRmF3NkG6jzAbY=.d8e7474f-9b77-4183-99b5-6a62819046eb@github.com>
 <LU5FoKbfXYJE26LzMgqcNd4H1LXgESe0gQQ8lw4C6aA=.58fdd835-a897-40f1-ac61-61bca374d4a9@github.com>
Message-ID: <QO9RUwTx5KJoXk1OBAnSfZMx8xos_lLtpZZm9n_wx-4=.e45116cf-5beb-41dd-b6c9-35b9081ce70f@github.com>

On Thu, 4 Dec 2025 23:50:15 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

> Right, this is not the correct fix. It breaks the Method->MethodCounters link for all the methods. We need to preserve the links for the MethodCounters that get added through MTD.

hmm, I think I am wrong here again. We don't need to preserve the Method->MCS link. We only need the MTD->MCS link.

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

PR Comment: https://git.openjdk.org/jdk/pull/28670#issuecomment-3621517645

From asmehra at openjdk.org  Sun Dec  7 02:45:56 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Sun, 7 Dec 2025 02:45:56 GMT
Subject: RFR: 8373114: Redundant MethodCounters in the preimage generated
 by training run
In-Reply-To: <LRw06Cn_4dcRW8YyFVr3RijMHIha7nPzBrcNNzaIny8=.dc07d0ee-b797-4434-aad0-956a00c2ea6f@github.com>
References: <LRw06Cn_4dcRW8YyFVr3RijMHIha7nPzBrcNNzaIny8=.dc07d0ee-b797-4434-aad0-956a00c2ea6f@github.com>
Message-ID: <oHb8PFbXCgkpIU7zDoxe2FH718T1ShmUqwKX-G5_D8I=.0af1e77c-703d-4c6b-8c9d-c35a331b5b1c@github.com>

On Thu, 4 Dec 2025 22:16:03 GMT, Ashutosh Mehra <asmehra at openjdk.org> 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

I looked at the code again and unless I missed something it looks like the MCS from MTD are not used at all. I don't see their usage either in mainline or in leyden premain branch. Why do we even care to store MCS at all then? @veresov can you please comment about this?

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

PR Comment: https://git.openjdk.org/jdk/pull/28670#issuecomment-3621518031

From iveresov at openjdk.org  Sun Dec  7 05:43:55 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Sun, 7 Dec 2025 05:43:55 GMT
Subject: RFR: 8373114: Redundant MethodCounters in the preimage generated
 by training run
In-Reply-To: <LRw06Cn_4dcRW8YyFVr3RijMHIha7nPzBrcNNzaIny8=.dc07d0ee-b797-4434-aad0-956a00c2ea6f@github.com>
References: <LRw06Cn_4dcRW8YyFVr3RijMHIha7nPzBrcNNzaIny8=.dc07d0ee-b797-4434-aad0-956a00c2ea6f@github.com>
Message-ID: <QCYr-gelNbdNe61ez5AW9wN5RiL-YzqwlRdP9vLsFdo=.77e0d1ba-4088-4e04-827b-e0de409b4ce6@github.com>

On Thu, 4 Dec 2025 22:16:03 GMT, Ashutosh Mehra <asmehra at openjdk.org> 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

They are not used right now but @vnkozlov is going to use them for the A4 recompilation strategy.

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

PR Comment: https://git.openjdk.org/jdk/pull/28670#issuecomment-3621638038

From qamai at openjdk.org  Sun Dec  7 12:08:18 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Sun, 7 Dec 2025 12:08:18 GMT
Subject: RFR: 8367341: C2: apply KnownBits and unsigned bounds to And / Or
 operations [v7]
In-Reply-To: <SqHEdFScmcQRe6wTaITLemzMzWD6jxGWCRWzHNepqjE=.ab7e7553-3a43-4b43-abc3-338d6493a35d@github.com>
References: <SqHEdFScmcQRe6wTaITLemzMzWD6jxGWCRWzHNepqjE=.ab7e7553-3a43-4b43-abc3-338d6493a35d@github.com>
Message-ID: <D35W5XiaiB4fJX8hGUzZxzp8xLKleIDFFqWNubmvtw8=.4e13c49c-37cd-4ebb-b39c-9ba1b59deb2c@github.com>

> Hi,
> 
> This PR improves the implementation of `AndNode/OrNode/XorNode::Value` by taking advantages of the additional information in `TypeInt`. The implementation is pretty straightforward. A clever trick is that by analyzing the negative and positive ranges of a `TypeInt` separately, we have better info for the leading bits. I also implement gtest unit tests to verify the correctness and monotonicity of the inference functions.
> 
> Please take a look and leave your reviews, thanks a lot.

Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge branch 'master' into andorxor
 - Merge branch 'master' into andorxor
 - Merge branch 'master' into andorxor
 - Add assertion for the helper in CTPComparator
   
   Co-authored-by: Emanuel Peter <emanuel.peter at oracle.com>
 - remove std::hash
 - remove unordered_map, add some comments for all_instances_size
 - Emanuel's reviews
 - Improve Value inferences of And, Or, Xor and implement gtest for general Value inferences

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

Changes: https://git.openjdk.org/jdk/pull/27618/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27618&range=06
  Stats: 964 lines in 9 files changed: 630 ins; 313 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/27618.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27618/head:pull/27618

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

From qamai at openjdk.org  Sun Dec  7 12:12:20 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Sun, 7 Dec 2025 12:12:20 GMT
Subject: RFR: 8372779: C2: Disambiguate Node::adr_type for the IR graph
 [v3]
In-Reply-To: <dEidZLl1MkM6TbAxS2FsitU70AYAahwzK9cun61wwV8=.ccdad883-5d8f-403e-a19f-40aef0f53b11@github.com>
References: <dEidZLl1MkM6TbAxS2FsitU70AYAahwzK9cun61wwV8=.ccdad883-5d8f-403e-a19f-40aef0f53b11@github.com>
Message-ID: <KMe08qt3HwEW_ewxHKx20KerRqY2EP9ucNOLgRBKKcA=.fa352cdc-0f09-479e-9d6a-7c6a56bfb301@github.com>

> Hi,
> 
> Currently, `Node::adr_type` is ambiguous. For some, it refers to the memory the node consumes, while for the others, it refer to the memory the node produces. This PR removes that ambiguity by introducing `Node::in_adr_type` and `Node::out_adr_type` that refer to those properties, respectively. It also introduces a local verification of the memory graph during compilation. These additions uncover some issues:
> 
> - Sometimes, the memory is wired incorrectly, such as in `LibraryCall::extend_setCurrentThread`, the `Phi` collect the `StoreNode`s instead of the whole memory state. I think these issues do not result in crashes or miscompilation, though.
> - `AryEqNode` reports `adr_type` being `TypeAryPtr::BYTES` (it inherits this from `StrIntrinsicNode`). This is incorrect, however, as it can accept `char[]` inputs, too.
> - For nodes such as `StrInflatedCopyNode`, as it consumes more than it produces, during scheduling, we need to compute anti-dependencies. This is not the case, so I fixed it by making it kill all the memory it consumes.
> - `GraphKit::set_output_for_allocation` uses a raw `ProjNode` as the base for a `MergeMem`, this is really suspicious. I didn't fix it, as it seems to not result in any symptom at the moment.
> 
> In the end, the execution of the compiler is strictly more restricted than before, and there is less room for ambiguity.
> 
> Please take a look and leave your reviews, thanks a lot.

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

 - Merge branch 'master' into adrtype
 - store_to_memory does not emit MemBars
 - Disambiguate Node::adr_type

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28570/files
  - new: https://git.openjdk.org/jdk/pull/28570/files/b39029a3..ec31fb75

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

  Stats: 29305 lines in 803 files changed: 17601 ins; 8334 del; 3370 mod
  Patch: https://git.openjdk.org/jdk/pull/28570.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28570/head:pull/28570

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

From dholmes at openjdk.org  Sun Dec  7 22:40:01 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 7 Dec 2025 22:40:01 GMT
Subject: RFR: 8366671: Refactor Thread::SpinAcquire and Thread::SpinRelease
 [v12]
In-Reply-To: <RDgpMBLrvMdqjHIGHkt07nePBNX6EEGVycu-zgFCGis=.1b1427dd-cd73-46e5-961f-7406cb5ea7a5@github.com>
References: <NtY8E8fBeSokCAQYP3OQEwfnppSugtTJ8uAtQtD0zvg=.88f2988d-47fd-4b8a-af89-488ed6b37870@github.com>
 <BLbZykwmGPMfOyN0A7lrjaht-OWDbWK9_ArQRZZTVCU=.4bbd7292-3028-44f2-b0a5-cb4f29c2044b@github.com>
 <Z0c-dWNWbxGumcLpse7-H3fGuAI5h9XBdu9bsJdRGeA=.bf035f09-aedf-401a-bf6d-90cf2568d48c@github.com>
 <g51FTZgI8RY6EqjJxfGYFe8RltiRQG8muogTidUqvJc=.95e1128b-d6e1-40cd-a624-aee2630fbfb7@github.com>
 <KbihuIqL_t7wzUfBlOrV_8WJBd_f7Bk5J2cabYY_588=.0db43b71-5b27-4734-9acd-d55e41cfb052@github.com>
 <RDgpMBLrvMdqjHIGHkt07nePBNX6EEGVycu-zgFCGis=.1b1427dd-cd73-46e5-961f-7406cb5ea7a5@github.com>
Message-ID: <bC6YmsXPkCll0XRGHJf5aDhBHtudQkHWSyoF9hsPwdA=.cc36939c-071d-4e10-91de-040949bff1f9@github.com>

On Fri, 5 Dec 2025 20:42:41 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Well we moved it for convenience but we really don't want it to start being used all over. :) I don't like this kind of "just in case" code as it indicates to me that we don't really know how/where the code is being used - and where do you draw the line? This is debug code so the performance aspect is not a concern, but I prefer not to have it but if you like document that this is not for use in signal-handling context. But this isn't a deal-breaker if others think it worth being ultra-conservative here.
>
> I hadn't noticed the 'safe' variant of Thread::current_or_null, but it seems like it might be appropriate from the implementation if this can be called very early in VM initialization for ParkEvents.
> 
> 
> inline Thread* Thread::current_or_null_safe() {
>   if (ThreadLocalStorage::is_initialized()) {
>     return ThreadLocalStorage::thread();
>   }
>   return nullptr;
> }
> 
> 
> It seems to cover more than the case of being called in a signal handler.  I think it's not a bad usage.  I was going to vote the other way until I saw the implementation.

Coleen I am not at all sure what you mean by that. The "safe" implementation has to use library-based TLS, rather than language/compiler-based as the latter is definitely not signal-safe while the former is deemed safe enough for reading TLS values. Because the safe version can be called very early in VM init we have to check the library-based TLS is initilalized.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28264#discussion_r2596661529

From xgong at openjdk.org  Mon Dec  8 02:03:25 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 8 Dec 2025 02:03:25 GMT
Subject: RFR: 8372136: VectorAPI: Refactor subword gather load API java
 implementation
In-Reply-To: <SEUxzD0msReThVgeMRw5uapRw-UIjewDJP27RAt3ZzY=.991e5f58-347e-44fe-92db-b56576aab780@github.com>
References: <SEUxzD0msReThVgeMRw5uapRw-UIjewDJP27RAt3ZzY=.991e5f58-347e-44fe-92db-b56576aab780@github.com>
Message-ID: <dr4DwOiElIFqU85IesPJhFEAG16aF34SuHAwedfuI6Y=.44afec79-1116-4865-9e4c-8057b9b3ff0b@github.com>

On Thu, 27 Nov 2025 01:42:07 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> The current subword (`byte`/`short`) gather load API implementation is not well-suited for platforms that provide native vector instructions for these operations. As **discussed in PR [1]**, we'd like to re-implement these APIs with a **unified cross-platform** solution.
> 
> The main idea is to re-implement the API at Java-level, by performing multiple sub-gather operations. Each sub-gather operation loads a portion of elements using a specific index vector by calling the HotSpot intrinsic API. The partial results are then merged using vector `slice` and `or` operations. This design simplifies the VM compiler intrinsic implementation and better aligns with the Vector API design principles.
> 
> Key changes:
> 1. Re-implement the subword gather load API at the Java level. The HotSpot intrinsic `VectorSupport.loadWithMap` is simplified by reducing the vector index parameters from four (vix1-vix4) to a single parameter.
> 2. Adjust the compiler intrinsic implementation to support the new Java API, including updates to the x86 backend implementation.
> 
> The performance impact varies across different scenarios on X86. I tested the performance with different AVX levels on an X86 machine that supports AVX512. To achieve optimal performance, I also **applied PR [2]**, which improves the performance of the **`slice()`** API on X86. Following is the summarized performance gains, where:
> 
> - "non masked" means the gather operation is not the masked gather API.
> - "masked" means the gather operation is the masked gather API.
> - "1 gather cases" means the gather API is implemented with a single gather operation. E.g. Load `Short128Vector` with `MaxVectorSize=256`.
> - "2 gather cases" means the gather API is implemented with 2 parts of gather operations. E.g. Load `Short256Vector` with `MaxVectorSize=256`.
> - "4 gather cases" means the gather API is implemented with 4 parts of gather operations. E.g. Load `Byte256Vector` with `MaxVectorSize=256`.
> - "Un-intrinsified" means the gather operation is not supported to be intrinsified by hotspot. E.g. Load `Byte512Vector` with `MaxVectorSize=256`. The singificant performance uplifts comes from the Java-level changes which removes the vector index generation and range checks for such cases.
> 
> 
> ----------------------------------------------------------------------------
>                |          UseAVX=3           |          UseAVX=2           |
>                |-----------------------------|-----------------------------|
>                |  non maske...

ping

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

PR Comment: https://git.openjdk.org/jdk/pull/28520#issuecomment-3624161715

From liach at openjdk.org  Mon Dec  8 02:08:37 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 8 Dec 2025 02:08:37 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v8]
In-Reply-To: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
Message-ID: <C0kGO-Sn5AEvyTvnM3HWEVA30vjCsol9mwiTFzJItA0=.6d97913c-f521-4c43-97ec-edd718de55fc@github.com>

> 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 15 additional commits since the last revision:

 - Bugs and verify loader leak
 - Try to avoid loader leak
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache
 - Revert void special case removal due to C2 shortage causing TestZGCBarrierElision::testAtomicThenAtomicAnotherField failure
 - Test from Jorn
 - Copyright years
 - Fix problem identified by Jorn
 - Rollback getAndAdd for now
 - Redundant change
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache
 - ... and 5 more: https://git.openjdk.org/jdk/compare/295928d3...eebb8ff7

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28585/files
  - new: https://git.openjdk.org/jdk/pull/28585/files/8200fb28..eebb8ff7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28585&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28585&range=06-07

  Stats: 10547 lines in 389 files changed: 7296 ins; 2024 del; 1227 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 liach at openjdk.org  Mon Dec  8 02:08:37 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 8 Dec 2025 02:08:37 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v3]
In-Reply-To: <fYi_M2-uq5LpwcEac1xjqYUwlhUSlAjCm5zPhJrvLhA=.f89046cc-e769-4c9a-8bf7-464830f46890@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <eXO79ZBlZUltqddmReHLTSFSr3x8PiH0a5s740GHrfk=.5cf01f8f-7ac5-4def-b17d-dfd6f10e9614@github.com>
 <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com>
 <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com>
 <M5yxETmdJBlueGf6KC7P8oSAZIEeiSu8rOHAoIxu0sc=.4bc347cb-40d5-4432-bc94-38a59730183d@github.com>
 <3OE37qXGHhLAhnRQM188hhygrLYBtI3FLBMK0tGVH30=.5d1b4406-3bb3-4788-8059-e78260b79ec1@github.com>
 <kZDurlwNJsrYZRbeHLXVTKqUQcW2QGFGLE-WNN-vz4o=.44bc4d21-cc9d-4d94-b40c-4b6ad9ab11aa@github.com>
 <7WF8DlorrU_B2__G2wr43w1PZwJh8mEhD5dY10YDIOo=.ec416c38-1aff-4dd6-8792-d6a0e01f91ce@github.com>
 <E7Lwc7nwEvsmQhLMYT5Ruj5j7BhVDcfyBRUfhinUyzQ=.3293c6f1-6ce4-47d8-aa48-ba9c69ba60eb@github.com>
 <ogD0Gl3QSb1pLJUqOn877wI6asY5TW0MV7mPFlNXM5A=.8af15b77-010a-4d34-901b-928c4a3fe425@github.com>
 <_Z6KpxCYH2n3sHuT6-kRP4cSTAN3-s5UA0r
 bfrJSIgA=.e9d4089c-8329-406b-9a0a-167a24311c13@github.com>
 <cWF4r8rgGleVvKUgrzYDQ0bcj_7QhY1PulNMpZtwBcs=.abcdfd8f-9a3f-4d1f-a55f-f16ea320cf92@github.com>
 <5CADH75ZjadKttOKwsykRFUPlQKLiwCW8E5WkM_75a4=.fd992c8f-e8bc-4775-9ea3-d5212664e3df@github.com>
 <JwKK9FX_wiYEYaRppgToqEqutrnpodk7cNJCwYLf8i0=.69cbfa2b-2c03-45ab-ad84-b9f086621bd3@github.com>
 <5QPAetQEkrBgFKtMt0i9Ku_4s2GCirMl2uqLH3j8x7g=.e5fc8964-0080-45f7-9005-31922ec06ba1@github.com>
 <fYi_M2-uq5LpwcEac1xjqYUwlhUSlAjCm5zPhJrvLhA=.f89046cc-e769-4c9a-8bf7-464830f46890@github.com>
Message-ID: <A4U0U7ZHrzGTPqez3pBNUYot4P5Fyn-nlEc6zmKtKy4=.74cff907-3f4f-4d0a-9f95-5f0198fdad19@github.com>

On Wed, 3 Dec 2025 13:34:40 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Looking at this, I'm not sure we can assume that we only see one mode and type when the VH is constant. There seems to be a lot of non-local reasoning involved.
>> 
>> For example, you could have a var handle invoker created with `MethodHandless::varHandleInvoker`, which is cached, so the `AccessDescriptor` can be shared among many different use sites. For an individual use-site, the receiver VH may well be a constant, but that doesn't mean that the cache isn't polluted by the var handle from another use site, as far as I can tell.
>> 
>> The thread safety issue comes from a C2 thread racing to read the `lastAdaption` cache vs another Java thread writing to the cache. AFAICS, this race is still possible even when `vh` is a compile time constant.
>
> I think even without using an invoker, you could end up in a similar situation if you have something like:
> 
> 
> static Object m(VarHandle vh) {
>     return vh.get();
> }
> 
> 
> Which is called by several different threads. At some point this method may be inlined into one of its callees, where `vh` then becomes a constant. But at the same time, other threads are still writing to the cache.

This issue should have been fixed, and there's a unit test to verify.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2596829589

From liach at openjdk.org  Mon Dec  8 02:08:37 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 8 Dec 2025 02:08:37 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v6]
In-Reply-To: <8tu3HIArCw2cdoYR2SjI0b-TWYQxQLKkjQgucJEj8D4=.10946ec2-4958-48df-add4-b29d11c09448@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <qmC_8KrBI4dTudSWMXPzMKMAwE24-kEfuEtSKaaVs4M=.b4fbf7c3-7fa4-485e-a0df-265fe4dbfa03@github.com>
 <OChEencVyX1xRYDW-2u0O8R8fO6WS8IbXAbP47uALcY=.c5158037-ff46-4b6d-be4d-ec68c756cb3b@github.com>
 <pbMDRrV6ly1k6hJzTYDGzFca-OuJbJJoz-pI0QNVckY=.6045281c-edbc-40c8-b418-74ccea04b2b6@github.com>
 <8tu3HIArCw2cdoYR2SjI0b-TWYQxQLKkjQgucJEj8D4=.10946ec2-4958-48df-add4-b29d11c09448@github.com>
Message-ID: <aP0TanKX6SJJEKjDgcDt8Nrzp0P8OE9NOc_GqQ2jcjM=.397243f7-e15b-43f0-b057-ada705b0ed3a@github.com>

On Thu, 4 Dec 2025 01:55:57 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> I don't think we can use a SoftReference here if we need to achieve constant folding.
>> 
>> Looking at inline_reference_get0, I think we might introduce another field property to trust a reference (potentially in an array) if both that reference and the referent within the reference is non-null.  I think that belongs to a separate RFE. What do you think?
>
> Then it makes sense to limit the caching to safe cases only for now. Otherwise, it would functionally regress due to a possible memory leak.

I have added a primitive checking system to ensure safety for most cases and added a unit test to ensure there is no memory leak due to this cache.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2596829153

From liach at openjdk.org  Mon Dec  8 02:08:38 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 8 Dec 2025 02:08:38 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v7]
In-Reply-To: <n-1cYeDh_yS2bYWFtuBlVsMCn43a4CSec_1uuP-jGh0=.22185d73-ac9e-43e0-8edf-0879c9509ed5@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <7ayMTZ4nXMyB1SXNRcYGjdxidNHDcAUNv_8fQZDUaPI=.a558d3a2-1d3e-4b45-8ba7-393c55a52785@github.com>
 <n-1cYeDh_yS2bYWFtuBlVsMCn43a4CSec_1uuP-jGh0=.22185d73-ac9e-43e0-8edf-0879c9509ed5@github.com>
Message-ID: <Pk5FCRbmEDh05M1XSiTRwoiN36kTdc8NIFtrSIR_o5Q=.5ef9dae0-74b1-43b9-929b-b53c16070dc6@github.com>

On Fri, 5 Dec 2025 11:03:18 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert void special case removal due to C2 shortage causing TestZGCBarrierElision::testAtomicThenAtomicAnotherField failure
>
> test/hotspot/jtreg/compiler/c2/irTests/constantFold/VarHandleMismatchedTypeFold.java line 48:
> 
>> 46:     public static void main(String[] args) {
>> 47:         TestFramework.runWithFlags(
>> 48:             "-XX:+UnlockExperimentalVMOptions"
> 
> Why is this flag needed?

Indeed, simplified this to `TestFramework.run()`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2596827495

From jbhateja at openjdk.org  Mon Dec  8 03:33:05 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 8 Dec 2025 03:33:05 GMT
Subject: RFR: 8368977: Provide clear naming for AVX10 identifiers
In-Reply-To: <6XYgqaHA0PPZzvnfysKOP5XGP7e_RMkVFt9PV2OT3Gk=.e5f33072-a91a-4e57-99f3-81cc4ae4d844@github.com>
References: <6XYgqaHA0PPZzvnfysKOP5XGP7e_RMkVFt9PV2OT3Gk=.e5f33072-a91a-4e57-99f3-81cc4ae4d844@github.com>
Message-ID: <UCSx0eDSzdLOti5d3X378WTEQ1R1bu1I077ldLTXlng=.338efdd0-85fa-4fb6-9e51-2049d70537dc@github.com>

On Mon, 17 Nov 2025 03:46:50 GMT, Mohamed Issa <missa at openjdk.org> wrote:

> This is a simple change that renames all AVX10 identifiers to explicitly show which sub-versions are in use. Right now, AVX10.2 is the only case to worry about. Also, the new AVX10.2 floating point conversion instructions are now used whenever possible to satisfy any related bytecode cast operations. The JTREG tests listed below were used to verify correctness with the recommended JVM options mentioned in corresponding source files. Each test included runs through emulation with AVX10.2 enabled and disabled to exercise all possible paths. All modifications and tests used [OpenJDK v26-b24](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B24) as the baseline build.
> 
> 1. `jtreg:test/hotspot/jtreg/compiler/codegen/TestByteDoubleVect.java`
> 2. `jtreg:test/hotspot/jtreg/compiler/codegen/TestByteFloatVect.java`
> 3. `jtreg:test/hotspot/jtreg/compiler/codegen/TestIntDoubleVect.java`
> 4. `jtreg:test/hotspot/jtreg/compiler/codegen/TestIntFloatVect.java`
> 5. `jtreg:test/hotspot/jtreg/compiler/codegen/TestLongDoubleVect.java`
> 6. `jtreg:test/hotspot/jtreg/compiler/codegen/TestLongFloatVect.java`
> 7. `jtreg:test/hotspot/jtreg/compiler/codegen/TestShortDoubleVect.java`
> 8. `jtreg:test/hotspot/jtreg/compiler/codegen/TestShortFloatVect.java`
> 9. `jtreg:test/hotspot/jtreg/compiler/floatingpoint/ScalarFPtoIntCastTest.java`
> 10. `jtreg:test/hotspot/jtreg/compiler/vectorapi/VectorFPtoIntCastTest.java`
> 11. `jtreg:test/hotspot/jtreg/compiler/vectorization/runner/ArrayTypeConvertTest.java`
> 12. `jtreg:test/jdk/jdk/incubator/vector/Double64VectorTests.java`
> 13. `jtreg:test/jdk/jdk/incubator/vector/Double128VectorTests.java`
> 14. `jtreg:test/jdk/jdk/incubator/vector/Double256VectorTests.java`
> 15. `jtreg:test/jdk/jdk/incubator/vector/Double512VectorTests.java`
> 16. `jtreg:test/jdk/jdk/incubator/vector/DoubleMaxVectorTests.java`
> 17. `jtreg:test/jdk/jdk/incubator/vector/Float64VectorTests.java`
> 18. `jtreg:test/jdk/jdk/incubator/vector/Float128VectorTests.java`
> 19. `jtreg:test/jdk/jdk/incubator/vector/Float256VectorTests.java`
> 20. `jtreg:test/jdk/jdk/incubator/vector/Float512VectorTests.java`
> 21. `jtreg:test/jdk/jdk/incubator/vector/FloatMaxVectorTests.java`
> 22. `jtreg:test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorOperations.java`
> 23. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java`

src/hotspot/cpu/x86/templateTable_x86.cpp line 1605:

> 1603:       __ jcc(Assembler::notEqual, L);
> 1604:       __ call_VM_leaf(CAST_FROM_FN_PTR(address, SharedRuntime::f2i), 1);
> 1605:     }

This change should be part of a seperate PR.

src/hotspot/cpu/x86/templateTable_x86.cpp line 1620:

> 1618:       __ jcc(Assembler::notEqual, L);
> 1619:       __ call_VM_leaf(CAST_FROM_FN_PTR(address, SharedRuntime::f2l), 1);
> 1620:     }

Please restrict this PR to name change related changes only.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28344#discussion_r2596923804
PR Review Comment: https://git.openjdk.org/jdk/pull/28344#discussion_r2596925402

From dholmes at openjdk.org  Mon Dec  8 05:46:11 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 8 Dec 2025 05:46:11 GMT
Subject: RFR: 8363996: Obsolete UseCompressedClassPointers [v4]
In-Reply-To: <jedU_ilFWTbEPv8RFDP9uPw7T9-tO5V_ETTw-2Ial3g=.2a930bec-f4d7-406b-ac29-d64e7b106b03@github.com>
References: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
 <jedU_ilFWTbEPv8RFDP9uPw7T9-tO5V_ETTw-2Ial3g=.2a930bec-f4d7-406b-ac29-d64e7b106b03@github.com>
Message-ID: <C27hTdtvSPVlY5_SA2im3ONCPPNOloeng31CVDJI7Ok=.70867e89-be37-48d1-ba49-063a6c28ce96@github.com>

On Thu, 4 Dec 2025 13:36:43 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> _This patch is not intended for JDK 26_. 
>> 
>> I'm posting it now to collect feedback and, barring any objections, plan to push it once JDK 27 opens.
>> 
>> This change removes the uncompressed Klass pointer mode and, with compressed Klass pointers remaining as the only option, the `UseCompressedClassPointers` switch.
>> 
>> For motivation, please take a look at CSR associated with the deprecation (which we did for JDK 25) and the preparatory discussion we had at the start of the year around this topic [2].
>> 
>> This patch is quite invasive and touches many parts of the JVM, since its goal is to remove most traces of the uncompressed Klass path and to take advantage of opportunities for simplification. In some cases, I did not take opportunities for further simplification to keep the patch somewhat legible; it will be onerous enough to review.
>> 
>> ### Implementation Notes
>> 
>> With uncompressed Klass pointers removed, we have three modes of operation left (including 32-bit):
>>   a) 64-bit, COH off - this is the old `+UseCompressedClassPointers` mode. This is now the standard mode until we run with COH by default.
>>   b) 64-bit, COH on
>>   c) 32-bit - Here, we run with a "fake" narrow Klass pointer mode. We run with hardcoded narrowKlass base == NULL and shift = 0, so nKlass == Klass*. The difference to (a, b) is that we don't use a class space. This was implemented with JDK-8363998 [3] - for more details, please see that issue and its PR.
>> 
>> I ensured *arm32* builds and I performed some rudimentary checks (selected metaspace/gc tests, and a simple Spring PetClinic run). Vendors with an interest in arm32 will have to step up and do their own, more thorough unit testing. Also, I did not see anyone doing follow-up work after JDK-8363998 [3] - so some issues may still lurk from that patch as well (but maybe JDK-8363998 was just not breaking anything).
>> 
>> I did not check *zero 32-bit*, the only other platform supporting 32-bit. Anyone with an interest in 32-bit zero should chip in.
>>   
>> Pre-existing errors: While working on this patch, I stumbled over a few occurrences of old but benign bugs. Mostly old code assuming CompressedClassPointers and CompressedOops were still tied together (example: Arguments::set_heap_size()). These bugs are implicitly fixed with this patch.
>> 
>> ### Testing
>> 
>> - tier 1 2 3 locally on Linux x64
>> - SAP ran their whole set of tests for all the platforms they support.
>> 
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8350754
>> [2...
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp
>   
>   Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>

I've completed a pass through everything and have a couple of comments on the functional changes.

The tests were quite hard to follow in places and I've flagged a few where you seemed to have done a more extensive rewrite than what was actually needed for the obsoletion - making it hard to assess the changes.

Thanks

src/hotspot/share/memory/metaspace.cpp line 661:

> 659:   MaxMetaspaceSize = MAX2(MaxMetaspaceSize, commit_alignment());
> 660: 
> 661:   if (using_class_space()) {

Shouldn't this now just be a build-time `ifdef _LP64` check?

src/hotspot/share/memory/metaspace.cpp line 728:

> 726:   }
> 727: 
> 728:   // a) if CDS is active (runtime, Xshare=on), it will create the class space

You have left descriptions of a) and b) but now we have no idea what they are referring to. ???

src/hotspot/share/runtime/arguments.cpp line 1591:

> 1589: 
> 1590:       size_t heap_end = HeapBaseMinAddress + MaxHeapSize;
> 1591:       size_t max_coop_heap = max_heap_for_compressed_oops();

Please don't change the types in this PR.

test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointers.java line 294:

> 292:     }
> 293: 
> 294:     public static void heapBaseMinAddressTestNoCoop() throws Exception {

It is not obvious to me why this test case was deleted.

test/hotspot/jtreg/runtime/ErrorHandling/TestVMConfigInHsErrFile.java line 59:

> 57:     switch (args[0]) {
> 58:       case "coh-on" -> testCompactObjectHeaders();
> 59:       case "coh-off" -> testCompressedClassPointers();

You seem to have done a complete test rewrite here and it is not obvious to me it follows as part of the obsoletion of UCCP.

test/hotspot/jtreg/runtime/cds/appcds/TestCombinedCompressedFlags.java line 67:

> 65:         private void initExecArgs() {
> 66:             // We fail this test if the UseCompressedOops setting used at dumptime differs from runtime,
> 67:             // succeed if it is identical

This test seems to reduce to pretty much nothing. ??

test/hotspot/jtreg/runtime/cds/appcds/TestZGCWithCDS.java line 44:

> 42:     private final static String UNABLE_TO_USE_ARCHIVE = "Unable to use shared archive.";
> 43:     private final static String ERR_MSG = "The saved state of UseCompressedOops (0) is different from runtime (1), CDS will be disabled.";
> 44:     private final static String COMPACT_OBJECT_HEADERS = "-XX:+UseCompactObjectHeaders";

Again this test seems to have a lot of unrelated changes. This is obscuring the actual differences and makes the review harder.

test/jdk/java/lang/instrument/GetObjectSizeIntrinsicsTest.java line 318:

> 316: 
> 317:     // Includes length, excludes alignment gap to base
> 318:     static final int ARRAY_HEADER_SIZE = Platform.is64bit() ? 16 : 12;

Again unrelated change.

test/jdk/jdk/jfr/event/gc/objectcount/ObjectCountEventVerifier.java line 75:

> 73:         final int bytesPerWord = runsOn32Bit ? 4 : 8;
> 74:         final int objectHeaderSize = runsOn32Bit ? 12 : 16;
> 75:         final int alignmentGap = runsOn32Bit ? 4 : 0;

Again unrelated changes.

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

PR Review: https://git.openjdk.org/jdk/pull/28366#pullrequestreview-3550086639
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2597013211
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2597014493
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2597023027
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2597045861
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2597050708
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2597102266
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2597107079
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2597110703
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2597114451

From dholmes at openjdk.org  Mon Dec  8 05:57:07 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 8 Dec 2025 05:57:07 GMT
Subject: RFR: 8367319: Add os interfaces to get machine and container
 values separately [v5]
In-Reply-To: <-fJmK2NEtYRIt_gO260itXoFE06wOgtn2is7EGZk4ek=.ab54f399-1c09-48c9-827d-fc2c9efad6e0@github.com>
References: <gxXrAX2NGPyZnHuA4ttkfJ8MagiiELK-Wk700A2ZBgw=.00aaf9ab-976d-476a-ba4d-8a4063d96130@github.com>
 <lI_E9fdbu_ilitVsUyZBFZZ3M1D-Y4lC1UaLvpP1drU=.d28d0b3f-8112-4d76-8f14-edce2923f7bb@github.com>
 <Q5LOAsRhyY58X2jHFSRDKqyAKWFzWfcITJwuuk50D2o=.b7e3b0ef-6700-4ced-90fc-48126bf1db9f@github.com>
 <Zw1--idz925pWBSxndgs-bXyYxg_8MFgsJbceYchAdo=.4d17b893-44ef-4d8f-bcf7-b8cee90a9da6@github.com>
 <EdnWyzTqxqti6PdX52PDtVqha-nygYXheZab7R-q7y4=.7a937620-9af7-488e-ac37-be43f77750fb@github.com>
 <GEsqWomVqhCLXVtqyajBXpw2xkIdvbS5IVFPMBuGaTo=.a162aa48-ec1e-451a-8d72-e47ab6a1b433@github.com>
 <-fJmK2NEtYRIt_gO260itXoFE06wOgtn2is7EGZk4ek=.ab54f399-1c09-48c9-827d-fc2c9efad6e0@github.com>
Message-ID: <2sNRC-cjy5fk-s932GpEJXIHIlMPW1zukpL5nt7SlqI=.7c794055-2b91-4307-9fff-4b7e0fa5be60@github.com>

On Thu, 4 Dec 2025 10:02:40 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> From my perspective, returning `true` from one of these functions means that the out-parameter is set to a valid, meaningful value and can be used safely by the caller. However, if the function returns `false`, there is no guarantee that the out-parameter is untouched, so relying on its previous value is unsafe. Your example is to me is a bad pattern and is brittle at best.
>> 
>> There is a distinction between `OSContainer::memory_limit_in_bytes` (which always fetches and returns the cgroup, including `value_unlimited` for no limit) and the higher-level `os::Container::memory_limit`, which is about determining whether there is an effective limit at all, and if so, what it is. It doesn't make sense to return `true` if there is no limit, since there wouldn't be a meaningful value to provide. `value_unlimited` is just an internal constant and not helpful for callers.
>> 
>> That said, I can update so we don't pass through the out-parameter so that we don't modify it when returning `false`, to be somewhat more consistent. But I still believe we should return `false` when no limit is set.
>
>> There is a distinction between `OSContainer::memory_limit_in_bytes` (which always fetches and returns the cgroup, including `value_unlimited` for no limit) and the higher-level `os::Container::memory_limit`, which is about determining whether there is an effective limit at all, and if so, what it is. It doesn't make sense to return `true` if there is no limit, since there wouldn't be a meaningful value to provide. `value_unlimited` is just an internal constant and not helpful for callers.
> 
> OK. This should be noted in a comment for `os::Container::xxx` functions.
> 
>> That said, I can update so we don't pass through the out-parameter so that we don't modify it when returning `false`, to be somewhat more consistent.
> 
> I'd prefer that, yes.

> However, if the function returns false, there is no guarantee that the out-parameter is untouched

I think that should be guaranteed. This is our API we can make it as strict as we desire. If I have preset a sentinel value and the op fails then I should be able to rely on my sentinel remaining intact.

> It doesn't make sense to return true if there is no limit

But now you are overloading the use of the return value. It was intended to reflect success or failure, not provide semantic information.  The higher-level function can choose to return true when there is a limit and false when there is not, but it can't also mean "or an error occurred".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27646#discussion_r2597137251

From qamai at openjdk.org  Mon Dec  8 07:41:01 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 8 Dec 2025 07:41:01 GMT
Subject: RFR: 8354282: C2: more crashes in compiled code because of
 dependency on removed range check CastIIs [v8]
In-Reply-To: <5DHx3WmMb1UtSeyiEiYCiisVgRFggPFfxBggpgtuD6M=.d72a9c07-9624-47ea-9398-a0d1dee69755@github.com>
References: <qos-VYvgreqGsB7ke35RmM3L9uHnnM6nUsm2QONKXc4=.9c902d61-5f45-41f5-8276-ac28830c2bf5@github.com>
 <qab0P8PMsV9UzIT8JqUuAixFJbzNkpjd_FCSDnVB49U=.f52c826c-480f-4330-ba68-01b22f21b044@github.com>
 <m1ysk4e8E_cBjRPbnGy9d4UxXjG8SDh2JICWwd2zVRI=.cefc4dd5-ef0a-42ae-9e62-45295ab4bebc@github.com>
 <5DHx3WmMb1UtSeyiEiYCiisVgRFggPFfxBggpgtuD6M=.d72a9c07-9624-47ea-9398-a0d1dee69755@github.com>
Message-ID: <q3hiQRnGW4gRZ7_Bif7NMWC1CbEBQ27mV8t3nHKn5qs=.ab59b092-90a9-48f8-bc05-0526617a5bf0@github.com>

On Fri, 5 Dec 2025 14:02:14 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> src/hotspot/share/opto/castnode.hpp line 105:
>> 
>>> 103:     // All the possible combinations of floating/narrowing with example use cases:
>>> 104: 
>>> 105:     // Use case example: Range Check CastII
>> 
>> I believe this is incorrect, a range check should be floating non-narrowing. It is only narrowing if the length of the array is a constant. It is because this cast encodes the dependency on the condition `index u< length`. This condition cannot be expressed in terms of `Type` unless `length` is a constant.
>
> Range check `CastII` were added to protect the `ConvI2L` in the address expression on 64 bits. The problem there was, in some cases, that the `ConvI2L` would float above the range check (because `ConvI2L` has no control input) and could end up with an out of range input (which in turn would cause the `ConvI2L` to become `top` in places where it wasn't expected).
> So `CastII` doesn't carry the control dependency of an array access on its range check. That dependency is carried by the `MemNode` which has its control input set to the range check.
> What you're saying, if I understand it correctly, would be true if the `CastII` was required to prevent an array `Load` from floating. But that's not the case.

Got it, sorry I misunderstood!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24575#discussion_r2597364668

From qamai at openjdk.org  Mon Dec  8 07:48:05 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 8 Dec 2025 07:48:05 GMT
Subject: RFR: 8354282: C2: more crashes in compiled code because of
 dependency on removed range check CastIIs [v10]
In-Reply-To: <S0C_y4_BZ3l56hm9XGUtrcbFy9kOHfKnllKwXuqUkkg=.763f7645-c941-48b6-a54c-76b2a8b8d547@github.com>
References: <qos-VYvgreqGsB7ke35RmM3L9uHnnM6nUsm2QONKXc4=.9c902d61-5f45-41f5-8276-ac28830c2bf5@github.com>
 <S0C_y4_BZ3l56hm9XGUtrcbFy9kOHfKnllKwXuqUkkg=.763f7645-c941-48b6-a54c-76b2a8b8d547@github.com>
Message-ID: <ia7rREp56b2WIwAmKK3MN6Lgxv-P5TUSX3_OFx7bK0Y=.f873f0c8-a55b-4c06-9362-911a3de2f578@github.com>

On Fri, 5 Dec 2025 14:05:06 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> This is a variant of 8332827. In 8332827, an array access becomes
>> dependent on a range check `CastII` for another array access. When,
>> after loop opts are over, that RC `CastII` was removed, the array
>> access could float and an out of bound access happened. With the fix
>> for 8332827, RC `CastII`s are no longer removed.
>> 
>> With this one what happens is that some transformations applied after
>> loop opts are over widen the type of the RC `CastII`. As a result, the
>> type of the RC `CastII` is no longer narrower than that of its input,
>> the `CastII` is removed and the dependency is lost.
>> 
>> There are 2 transformations that cause this to happen:
>> 
>> - after loop opts are over, the type of the `CastII` nodes are widen
>>   so nodes that have the same inputs but a slightly different type can
>>   common.
>>   
>> - When pushing a `CastII` through an `Add`, if of the type both inputs
>>   of the `Add`s are non constant, then we end up widening the type
>>   (the resulting `Add` has a type that's wider than that of the
>>   initial `CastII`).
>>   
>> There are already 3 types of `Cast` nodes depending on the
>> optimizations that are allowed. Either the `Cast` is floating
>> (`depends_only_test()` returns `true`) or pinned. Either the `Cast`
>> can be removed if it no longer narrows the type of its input or
>> not. We already have variants of the `CastII`:
>> 
>> - if the Cast can float and be removed when it doesn't narrow the type
>> of its input.
>> 
>> - if the Cast is pinned and be removed when it doesn't narrow the type
>> of its input.
>> 
>> - if the Cast is pinned and can't be removed when it doesn't narrow
>> the type of its input.
>> 
>> What we need here, I think, is the 4th combination:
>> 
>> - if the Cast can float and can't be removed when it doesn't narrow
>> the type of its input.
>> 
>> Anyway, things are becoming confusing with all these different
>> variants named in ways that don't always help figure out what
>> constraints one of them operate under. So I refactored this and that's
>> the biggest part of this change. The fix consists in marking `Cast`
>> nodes when their type is widen in a way that prevents them from being
>> optimized out.
>> 
>> Tobias ran performance testing with a slightly different version of
>> this change and there was no regression.
>
> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Marked as reviewed by qamai (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/24575#pullrequestreview-3550550450

From duke at openjdk.org  Mon Dec  8 08:15:00 2025
From: duke at openjdk.org (ExE Boss)
Date: Mon, 8 Dec 2025 08:15:00 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v8]
In-Reply-To: <C0kGO-Sn5AEvyTvnM3HWEVA30vjCsol9mwiTFzJItA0=.6d97913c-f521-4c43-97ec-edd718de55fc@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <C0kGO-Sn5AEvyTvnM3HWEVA30vjCsol9mwiTFzJItA0=.6d97913c-f521-4c43-97ec-edd718de55fc@github.com>
Message-ID: <y0IHGapGQpdfvYIgLQ0TAWUV0aUbFppFb_oAOOvkZVc=.245f1c6b-2357-4e57-98e9-4704931b6b84@github.com>

On Mon, 8 Dec 2025 02:08:37 GMT, Chen Liang <liach at openjdk.org> 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 15 additional commits since the last revision:
> 
>  - Bugs and verify loader leak
>  - Try to avoid loader leak
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache
>  - Revert void special case removal due to C2 shortage causing TestZGCBarrierElision::testAtomicThenAtomicAnotherField failure
>  - Test from Jorn
>  - Copyright years
>  - Fix problem identified by Jorn
>  - Rollback getAndAdd for now
>  - Redundant change
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/17ebc456...eebb8ff7

make/jdk/src/classes/build/tools/methodhandle/VarHandleGuardMethodGenerator.java line 145:

> 143:                             MethodHandle.linkToStatic(<LINK_TO_STATIC_ARGS>);
> 144:                         } else {
> 145:                             <RETURN>ad.adaptedMethodHandle(handle).invokeBasic(<LINK_TO_INVOKER_ARGS>);

The?old?version didn?t?use?`<RETURN>` in?`GUARD_METHOD_TEMPLATE_V`:
Suggestion:

                            ad.adaptedMethodHandle(handle).invokeBasic(<LINK_TO_INVOKER_ARGS>);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2597461675

From thartmann at openjdk.org  Mon Dec  8 08:41:06 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 8 Dec 2025 08:41:06 GMT
Subject: RFR: 8372701: Randomized profile counters [v4]
In-Reply-To: <CjfS8zXtvye99E6j5rz7U4mO7SLE5aU7u4U4vBW8b4Y=.2cb24d4b-c385-4d37-9ba2-bc96b804b975@github.com>
References: <jKjmIONZcytzVjS4absOwOLv_QOF9qhIJifYhN6JyP4=.dceced94-bc29-43e6-9062-8dc77c2a6133@github.com>
 <CjfS8zXtvye99E6j5rz7U4mO7SLE5aU7u4U4vBW8b4Y=.2cb24d4b-c385-4d37-9ba2-bc96b804b975@github.com>
Message-ID: <o2GyBnryv44hSQ3eTwdSpn0xZGdUdSnykw7hR208puI=.edefd5a7-3762-44fb-a1a0-6ba655d23996@github.com>

On Sat, 6 Dec 2025 10:28:02 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> 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:
> 
>   Fix x86 lambda

That was on Linux AArch64. Let me re-run.

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

PR Comment: https://git.openjdk.org/jdk/pull/28541#issuecomment-3625675954

From thartmann at openjdk.org  Mon Dec  8 08:45:17 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 8 Dec 2025 08:45:17 GMT
Subject: RFR: 8372701: Randomized profile counters [v4]
In-Reply-To: <CjfS8zXtvye99E6j5rz7U4mO7SLE5aU7u4U4vBW8b4Y=.2cb24d4b-c385-4d37-9ba2-bc96b804b975@github.com>
References: <jKjmIONZcytzVjS4absOwOLv_QOF9qhIJifYhN6JyP4=.dceced94-bc29-43e6-9062-8dc77c2a6133@github.com>
 <CjfS8zXtvye99E6j5rz7U4mO7SLE5aU7u4U4vBW8b4Y=.2cb24d4b-c385-4d37-9ba2-bc96b804b975@github.com>
Message-ID: <p4A4eM1zSlD8mpvml8SwakhG3mIwWgf6yGbJYbnKBPo=.2c7dcc1b-956c-4063-bfb3-d7fb67cd0c8c@github.com>

On Sat, 6 Dec 2025 10:28:02 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> 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:
> 
>   Fix x86 lambda

Ah, I think the problem is that there are merge conflicts with master. Could you please resolve them?

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

PR Comment: https://git.openjdk.org/jdk/pull/28541#issuecomment-3625699403

From aartemov at openjdk.org  Mon Dec  8 09:24:03 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Mon, 8 Dec 2025 09:24:03 GMT
Subject: RFR: 8366671: Refactor Thread::SpinAcquire and Thread::SpinRelease
 [v12]
In-Reply-To: <bC6YmsXPkCll0XRGHJf5aDhBHtudQkHWSyoF9hsPwdA=.cc36939c-071d-4e10-91de-040949bff1f9@github.com>
References: <NtY8E8fBeSokCAQYP3OQEwfnppSugtTJ8uAtQtD0zvg=.88f2988d-47fd-4b8a-af89-488ed6b37870@github.com>
 <BLbZykwmGPMfOyN0A7lrjaht-OWDbWK9_ArQRZZTVCU=.4bbd7292-3028-44f2-b0a5-cb4f29c2044b@github.com>
 <Z0c-dWNWbxGumcLpse7-H3fGuAI5h9XBdu9bsJdRGeA=.bf035f09-aedf-401a-bf6d-90cf2568d48c@github.com>
 <g51FTZgI8RY6EqjJxfGYFe8RltiRQG8muogTidUqvJc=.95e1128b-d6e1-40cd-a624-aee2630fbfb7@github.com>
 <KbihuIqL_t7wzUfBlOrV_8WJBd_f7Bk5J2cabYY_588=.0db43b71-5b27-4734-9acd-d55e41cfb052@github.com>
 <RDgpMBLrvMdqjHIGHkt07nePBNX6EEGVycu-zgFCGis=.1b1427dd-cd73-46e5-961f-7406cb5ea7a5@github.com>
 <bC6YmsXPkCll0XRGHJf5aDhBHtudQkHWSyoF9hsPwdA=.cc36939c-071d-4e10-91de-040949bff1f9@github.com>
Message-ID: <PE4qX-iP2pUraSKInpccGsgMBM0v0pnaWlqkwOoWc-A=.b850cb0d-d39b-449e-af9b-1302913a4655@github.com>

On Sun, 7 Dec 2025 22:37:12 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I hadn't noticed the 'safe' variant of Thread::current_or_null, but it seems like it might be appropriate from the implementation if this can be called very early in VM initialization for ParkEvents.
>> 
>> 
>> inline Thread* Thread::current_or_null_safe() {
>>   if (ThreadLocalStorage::is_initialized()) {
>>     return ThreadLocalStorage::thread();
>>   }
>>   return nullptr;
>> }
>> 
>> 
>> It seems to cover more than the case of being called in a signal handler.  I think it's not a bad usage.  I was going to vote the other way until I saw the implementation.
>
> Coleen I am not at all sure what you mean by that. The "safe" implementation has to use library-based TLS, rather than language/compiler-based as the latter is definitely not signal-safe while the former is deemed safe enough for reading TLS values. Because the safe version can be called very early in VM init we have to check the library-based TLS is initilalized.

I think we don't want complication as the one that David described in this supposedly simple utility object. Let's just use the unsafe version and document when it should not be used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28264#discussion_r2597759386

From aartemov at openjdk.org  Mon Dec  8 09:52:37 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Mon, 8 Dec 2025 09:52:37 GMT
Subject: RFR: 8366671: Refactor Thread::SpinAcquire and Thread::SpinRelease
 [v14]
In-Reply-To: <NtY8E8fBeSokCAQYP3OQEwfnppSugtTJ8uAtQtD0zvg=.88f2988d-47fd-4b8a-af89-488ed6b37870@github.com>
References: <NtY8E8fBeSokCAQYP3OQEwfnppSugtTJ8uAtQtD0zvg=.88f2988d-47fd-4b8a-af89-488ed6b37870@github.com>
Message-ID: <6R4WXWJlPBDkckb22HlRjZtsbM9oweatac1BirwD4mQ=.2cc93475-5b5a-4a56-a723-ba4d28497c31@github.com>

> Hi, 
> 
> please consider the following changes:
> 
> In this PR `Thread::SpinAcquire()` and `Thread::SpinRelease()` methods are refactored into a utility class `SpinCriticalSection`. The motivation is to make it easier for developers to use this lightweight synchronization mechanism in the codebase. The two aforementioned methods were used in JFR to create short critical sections with a helper class, but that was not the case for the object monitor code. 
> 
> Tested in tiers 1 - 5.

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

  8366671: Use non-safe current_or_null.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28264/files
  - new: https://git.openjdk.org/jdk/pull/28264/files/debff9db..a40f6d81

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28264&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28264&range=12-13

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

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

From bkilambi at openjdk.org  Mon Dec  8 10:38:12 2025
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Mon, 8 Dec 2025 10:38:12 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v5]
In-Reply-To: <Vqu9FE4SgvqWFWn0U9718IDFzJviLpKyRyfYc7qrrZ0=.04845f2a-e4f5-4bb5-8f8f-d6bb001ca9c3@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <Vqu9FE4SgvqWFWn0U9718IDFzJviLpKyRyfYc7qrrZ0=.04845f2a-e4f5-4bb5-8f8f-d6bb001ca9c3@github.com>
Message-ID: <PDD86rpbT5E1O892-PSEzhUEX-z0hePJ2dmohhkhX7Q=.ac4846db-9c08-4241-a66f-2b70071f6668@github.com>

On Wed, 26 Nov 2025 11:34:11 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Add a new  Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type.
>> - Add necessary inline expander support.
>>    - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA.
>> - Use existing Float16 vector IR and backend support.
>> - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations.
>>  
>> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc).
>> 
>> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels.
>> 
>> <img width="1449" height="629" alt="image" src="https://github.com/user-attachments/assets/b4474361-9886-4315-a614-f4073fd075b9" />
>> 
>> 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:
> 
>   Cleanups

test/hotspot/jtreg/compiler/vectorapi/TestFloat16VectorOperations.java line 134:

> 132:                            .intoArray(output, i);
> 133:         }
> 134:         for (; i < LEN; i++) {

Will this not result in autovectorization instead and also overwrite the `output` array results from vectorapi which were previously computed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2598040108

From epeter at openjdk.org  Mon Dec  8 10:43:01 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 8 Dec 2025 10:43:01 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v5]
In-Reply-To: <PDD86rpbT5E1O892-PSEzhUEX-z0hePJ2dmohhkhX7Q=.ac4846db-9c08-4241-a66f-2b70071f6668@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <Vqu9FE4SgvqWFWn0U9718IDFzJviLpKyRyfYc7qrrZ0=.04845f2a-e4f5-4bb5-8f8f-d6bb001ca9c3@github.com>
 <PDD86rpbT5E1O892-PSEzhUEX-z0hePJ2dmohhkhX7Q=.ac4846db-9c08-4241-a66f-2b70071f6668@github.com>
Message-ID: <o-yNlHUJg47pk2nHJCWJSyJHOxRBff_zc8NeP7Sym4s=.eb5643e3-9d7e-43ff-a3b4-8dfa8d38d7fd@github.com>

On Mon, 8 Dec 2025 10:35:23 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Cleanups
>
> test/hotspot/jtreg/compiler/vectorapi/TestFloat16VectorOperations.java line 134:
> 
>> 132:                            .intoArray(output, i);
>> 133:         }
>> 134:         for (; i < LEN; i++) {
> 
> Will this not result in autovectorization instead and also overwrite the `output` array results from vectorapi which were previously computed?

Yes: there could be auto-vectorization.
No: `i` is not reset, it keeps counting from where `i < SPECIES.loopBound(LEN)` fails, and handles the tail, right?

It could be good to run this test once with and once without auto vectorization, just to make sure the vectors you see are from the Vector API, and not auto vectorization.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2598054314

From bkilambi at openjdk.org  Mon Dec  8 11:27:59 2025
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Mon, 8 Dec 2025 11:27:59 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v5]
In-Reply-To: <o-yNlHUJg47pk2nHJCWJSyJHOxRBff_zc8NeP7Sym4s=.eb5643e3-9d7e-43ff-a3b4-8dfa8d38d7fd@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <Vqu9FE4SgvqWFWn0U9718IDFzJviLpKyRyfYc7qrrZ0=.04845f2a-e4f5-4bb5-8f8f-d6bb001ca9c3@github.com>
 <PDD86rpbT5E1O892-PSEzhUEX-z0hePJ2dmohhkhX7Q=.ac4846db-9c08-4241-a66f-2b70071f6668@github.com>
 <o-yNlHUJg47pk2nHJCWJSyJHOxRBff_zc8NeP7Sym4s=.eb5643e3-9d7e-43ff-a3b4-8dfa8d38d7fd@github.com>
Message-ID: <noO_zbgz9xdFkKd0iRFBg-ucAo1Q2VsFV6gysdyVypg=.8dbfdf85-c7a0-4a47-8fbb-fd407c6d0fe3@github.com>

On Mon, 8 Dec 2025 10:39:51 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/vectorapi/TestFloat16VectorOperations.java line 134:
>> 
>>> 132:                            .intoArray(output, i);
>>> 133:         }
>>> 134:         for (; i < LEN; i++) {
>> 
>> Will this not result in autovectorization instead and also overwrite the `output` array results from vectorapi which were previously computed?
>
> Yes: there could be auto-vectorization.
> No: `i` is not reset, it keeps counting from where `i < SPECIES.loopBound(LEN)` fails, and handles the tail, right?
> 
> It could be good to run this test once with and once without auto vectorization, just to make sure the vectors you see are from the Vector API, and not auto vectorization.

Thanks. I missed that `i` isn't being reinitialised/reset again. Do we even need the tail loop in this case when the `LEN = 2048`? We may not even have any tail iterations?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2598233546

From coleenp at openjdk.org  Mon Dec  8 12:43:00 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 8 Dec 2025 12:43:00 GMT
Subject: RFR: 8366671: Refactor Thread::SpinAcquire and Thread::SpinRelease
 [v14]
In-Reply-To: <6R4WXWJlPBDkckb22HlRjZtsbM9oweatac1BirwD4mQ=.2cc93475-5b5a-4a56-a723-ba4d28497c31@github.com>
References: <NtY8E8fBeSokCAQYP3OQEwfnppSugtTJ8uAtQtD0zvg=.88f2988d-47fd-4b8a-af89-488ed6b37870@github.com>
 <6R4WXWJlPBDkckb22HlRjZtsbM9oweatac1BirwD4mQ=.2cc93475-5b5a-4a56-a723-ba4d28497c31@github.com>
Message-ID: <8tlz4aJmAFoSSG_TCZ8XMMj9FdArbxfkGOtBWY_Vkeg=.a865a3f6-7cac-47ee-b31f-998c517c9e43@github.com>

On Mon, 8 Dec 2025 09:52:37 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, 
>> 
>> please consider the following changes:
>> 
>> In this PR `Thread::SpinAcquire()` and `Thread::SpinRelease()` methods are refactored into a utility class `SpinCriticalSection`. The motivation is to make it easier for developers to use this lightweight synchronization mechanism in the codebase. The two aforementioned methods were used in JFR to create short critical sections with a helper class, but that was not the case for the object monitor code. 
>> 
>> Tested in tiers 1 - 5.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8366671: Use non-safe current_or_null.

I think sine the answer to my previous question is 'no', the unsafe version of thread_or_null is fine, and better.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28264#pullrequestreview-3551870959

From coleenp at openjdk.org  Mon Dec  8 12:43:02 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 8 Dec 2025 12:43:02 GMT
Subject: RFR: 8366671: Refactor Thread::SpinAcquire and Thread::SpinRelease
 [v12]
In-Reply-To: <PE4qX-iP2pUraSKInpccGsgMBM0v0pnaWlqkwOoWc-A=.b850cb0d-d39b-449e-af9b-1302913a4655@github.com>
References: <NtY8E8fBeSokCAQYP3OQEwfnppSugtTJ8uAtQtD0zvg=.88f2988d-47fd-4b8a-af89-488ed6b37870@github.com>
 <BLbZykwmGPMfOyN0A7lrjaht-OWDbWK9_ArQRZZTVCU=.4bbd7292-3028-44f2-b0a5-cb4f29c2044b@github.com>
 <Z0c-dWNWbxGumcLpse7-H3fGuAI5h9XBdu9bsJdRGeA=.bf035f09-aedf-401a-bf6d-90cf2568d48c@github.com>
 <g51FTZgI8RY6EqjJxfGYFe8RltiRQG8muogTidUqvJc=.95e1128b-d6e1-40cd-a624-aee2630fbfb7@github.com>
 <KbihuIqL_t7wzUfBlOrV_8WJBd_f7Bk5J2cabYY_588=.0db43b71-5b27-4734-9acd-d55e41cfb052@github.com>
 <RDgpMBLrvMdqjHIGHkt07nePBNX6EEGVycu-zgFCGis=.1b1427dd-cd73-46e5-961f-7406cb5ea7a5@github.com>
 <bC6YmsXPkCll0XRGHJf5aDhBHtudQkHWSyoF9hsPwdA=.cc36939c-071d-4e10-91de-040949bff1f9@github.com>
 <PE4qX-iP2pUraSKInpccGsgMBM0v0pnaWlqkwOoWc-A=.b850cb0d-d39b-449e-af9b-1302913a4655@github.com>
Message-ID: <UI25SdDAt4IhIDq5Gb7QJwyqx8td87ODo6k1cGYrLQc=.8b3bf59b-a56e-4924-bfb8-753c82851b68@github.com>

On Mon, 8 Dec 2025 09:21:25 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Coleen I am not at all sure what you mean by that. The "safe" implementation has to use library-based TLS, rather than language/compiler-based as the latter is definitely not signal-safe while the former is deemed safe enough for reading TLS values. Because the safe version can be called very early in VM init we have to check the library-based TLS is initilalized.
>
> I think we don't want complication as the one that David described in this supposedly simple utility object. Let's just use the unsafe version and document when it should not be used.

> Because the safe version can be called very early in VM init we have to check the library-based TLS is initilalized.

Can the ParkEvent not be called very early in VM init as well?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28264#discussion_r2598467366

From aartemov at openjdk.org  Mon Dec  8 12:50:59 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Mon, 8 Dec 2025 12:50:59 GMT
Subject: RFR: 8366671: Refactor Thread::SpinAcquire and Thread::SpinRelease
 [v12]
In-Reply-To: <UI25SdDAt4IhIDq5Gb7QJwyqx8td87ODo6k1cGYrLQc=.8b3bf59b-a56e-4924-bfb8-753c82851b68@github.com>
References: <NtY8E8fBeSokCAQYP3OQEwfnppSugtTJ8uAtQtD0zvg=.88f2988d-47fd-4b8a-af89-488ed6b37870@github.com>
 <BLbZykwmGPMfOyN0A7lrjaht-OWDbWK9_ArQRZZTVCU=.4bbd7292-3028-44f2-b0a5-cb4f29c2044b@github.com>
 <Z0c-dWNWbxGumcLpse7-H3fGuAI5h9XBdu9bsJdRGeA=.bf035f09-aedf-401a-bf6d-90cf2568d48c@github.com>
 <g51FTZgI8RY6EqjJxfGYFe8RltiRQG8muogTidUqvJc=.95e1128b-d6e1-40cd-a624-aee2630fbfb7@github.com>
 <KbihuIqL_t7wzUfBlOrV_8WJBd_f7Bk5J2cabYY_588=.0db43b71-5b27-4734-9acd-d55e41cfb052@github.com>
 <RDgpMBLrvMdqjHIGHkt07nePBNX6EEGVycu-zgFCGis=.1b1427dd-cd73-46e5-961f-7406cb5ea7a5@github.com>
 <bC6YmsXPkCll0XRGHJf5aDhBHtudQkHWSyoF9hsPwdA=.cc36939c-071d-4e10-91de-040949bff1f9@github.com>
 <PE4qX-iP2pUraSKInpccGsgMBM0v0pnaWlqkwOoWc-A=.b850cb0d-d39b-449e-af9b-1302913a4655@github.com>
 <UI25SdDAt4IhIDq5Gb7QJwyqx8td87ODo6k1cGYrLQc=.8b3bf59b-a56e-4924-bfb8-753c82851b68@github.com>
Message-ID: <328KtTBIXsGzjIVrTBc79c5UHJjDwuf44CD8NiNXKxk=.fdb6e67f-2795-4e77-a3b9-3cf5f1774cdb@github.com>

On Mon, 8 Dec 2025 12:38:11 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I think we don't want complication as the one that David described in this supposedly simple utility object. Let's just use the unsafe version and document when it should not be used.
>
>> Because the safe version can be called very early in VM init we have to check the library-based TLS is initilalized.
> 
> Can the ParkEvent not be called very early in VM init as well?

I guess we should assume that it can be called at any time.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28264#discussion_r2598506670

From aartemov at openjdk.org  Mon Dec  8 12:56:53 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Mon, 8 Dec 2025 12:56:53 GMT
Subject: RFR: 8366671: Refactor Thread::SpinAcquire and Thread::SpinRelease
 [v15]
In-Reply-To: <NtY8E8fBeSokCAQYP3OQEwfnppSugtTJ8uAtQtD0zvg=.88f2988d-47fd-4b8a-af89-488ed6b37870@github.com>
References: <NtY8E8fBeSokCAQYP3OQEwfnppSugtTJ8uAtQtD0zvg=.88f2988d-47fd-4b8a-af89-488ed6b37870@github.com>
Message-ID: <S17J-2hDlDeS2qYJhPN2dww5vKxOk9Ug_I0gdFMHU9Q=.dc031058-08d0-4e52-b231-ba92f72e1486@github.com>

> Hi, 
> 
> please consider the following changes:
> 
> In this PR `Thread::SpinAcquire()` and `Thread::SpinRelease()` methods are refactored into a utility class `SpinCriticalSection`. The motivation is to make it easier for developers to use this lightweight synchronization mechanism in the codebase. The two aforementioned methods were used in JFR to create short critical sections with a helper class, but that was not the case for the object monitor code. 
> 
> Tested in tiers 1 - 5.

Anton Artemov 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:

 - Merge remote-tracking branch 'origin/master' into JDK-8366671-refactor-spin-acquire-spin-release
 - 8366671: Use non-safe current_or_null.
 - Update src/hotspot/share/runtime/objectMonitor.cpp
   
   Co-authored-by: Coleen Phillimore <coleen.phillimore at oracle.com>
 - 8366671: Added NoSafepointVerifier
 - 8366671: Modified the comment.
 - Merge remote-tracking branch 'origin/master' into JDK-8366671-refactor-spin-acquire-spin-release
 - 8366671: Addressed reviewer's comments.
 - 8366671: Addressed reviewers' comments.
 - 8366671: Addressed reviewer's comments
 - 8366671: Removed redundant include.
 - ... and 9 more: https://git.openjdk.org/jdk/compare/3c241263...7e0cf5a5

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28264/files
  - new: https://git.openjdk.org/jdk/pull/28264/files/a40f6d81..7e0cf5a5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28264&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28264&range=13-14

  Stats: 21464 lines in 497 files changed: 12414 ins; 6894 del; 2156 mod
  Patch: https://git.openjdk.org/jdk/pull/28264.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28264/head:pull/28264

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

From luhenry at openjdk.org  Mon Dec  8 13:13:00 2025
From: luhenry at openjdk.org (Ludovic Henry)
Date: Mon, 8 Dec 2025 13:13:00 GMT
Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization [v7]
In-Reply-To: <4-PqNRUxM-80k4mQdYNzc0HrirtkTCjfVAzgRewW08M=.d2fe4512-16cd-4abf-8a7f-e91341c37110@github.com>
References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com>
 <4-PqNRUxM-80k4mQdYNzc0HrirtkTCjfVAzgRewW08M=.d2fe4512-16cd-4abf-8a7f-e91341c37110@github.com>
Message-ID: <a8Jj1OuTL0dGwYRJhsSkL5FyDJxvUEYiB0ORsQWQo30=.44f49b76-218d-4256-accd-77befb1e4259@github.com>

On Mon, 1 Dec 2025 15:13:13 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> 
>> This pr add CMoveF/D on riscv, which enable vectorization of statement like: `op_1 bop op_2 ? res_f_d_1 : res_f_d_2 in a loop`.
>> 
>> This pr is also a preparation for further vectorization in https://github.com/openjdk/jdk/pull/28231.
>> 
>> Previously it's https://github.com/openjdk/jdk/pull/25341, but at that time, C2 SLP has some issue with unsigned comparison, which is now fixed, so it's good to continue the work.
>> 
>> # Test
>> ## Jtreg
>> 
>> in progress...
>> 
>> ## Performance
>> 
>> Column names meanings:
>> * p: with patch
>> * p+v: with patch, `-XX:+UseVectorCmov -XX:+UseCMoveUnconditionally` turned on
>> * m: without patch
>> * m+v: without patch, `-XX:+UseVectorCmov -XX:+UseCMoveUnconditionally` turned on
>> 
>> #### Average improvement
>> 
>> NOTE: With only this PR, it brings performance benefit in case of `CMoveF+CmpF`, `CMoveD+ComD`, `CMoveF+CmpI`, `CMoveD+CmpL`. The data below is based on fullly implmenting the vectorization of `CMoveI/L/F/D+CmpI/L/F/D`, which will be achieved by https://github.com/openjdk/jdk/pull/28231.
>> 
>> For details, check the performance data in https://github.com/openjdk/jdk/pull/25341 on riscv.
>> <google-sheets-html-origin style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
>> Opt (m/p) | Opt (m+v/p+v) | Opt (p/p+v) | Opt (m/p+v)
>> -- | -- | -- | --
>> 1.022782609 | 2.198717391 | 2.162673913 | 2.199
>> 
>> </google-sheets-html-origin>
>
> Hamlin Li has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove log_warning
>  - add test cases: BoolTest::ge/gt in enc_cmove_fp_cmp_fp

Marked as reviewed by luhenry (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/28309#pullrequestreview-3552013870

From iwalulya at openjdk.org  Mon Dec  8 13:31:12 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 8 Dec 2025 13:31:12 GMT
Subject: RFR: 8363996: Obsolete UseCompressedClassPointers [v4]
In-Reply-To: <jedU_ilFWTbEPv8RFDP9uPw7T9-tO5V_ETTw-2Ial3g=.2a930bec-f4d7-406b-ac29-d64e7b106b03@github.com>
References: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
 <jedU_ilFWTbEPv8RFDP9uPw7T9-tO5V_ETTw-2Ial3g=.2a930bec-f4d7-406b-ac29-d64e7b106b03@github.com>
Message-ID: <zFfEexmtxjovY_ScXvsWxZSqMEzbN719AAMpC4b2PYI=.50a015c8-c7ae-4ec2-a4d4-4788b8e828da@github.com>

On Thu, 4 Dec 2025 13:36:43 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> _This patch is not intended for JDK 26_. 
>> 
>> I'm posting it now to collect feedback and, barring any objections, plan to push it once JDK 27 opens.
>> 
>> This change removes the uncompressed Klass pointer mode and, with compressed Klass pointers remaining as the only option, the `UseCompressedClassPointers` switch.
>> 
>> For motivation, please take a look at CSR associated with the deprecation (which we did for JDK 25) and the preparatory discussion we had at the start of the year around this topic [2].
>> 
>> This patch is quite invasive and touches many parts of the JVM, since its goal is to remove most traces of the uncompressed Klass path and to take advantage of opportunities for simplification. In some cases, I did not take opportunities for further simplification to keep the patch somewhat legible; it will be onerous enough to review.
>> 
>> ### Implementation Notes
>> 
>> With uncompressed Klass pointers removed, we have three modes of operation left (including 32-bit):
>>   a) 64-bit, COH off - this is the old `+UseCompressedClassPointers` mode. This is now the standard mode until we run with COH by default.
>>   b) 64-bit, COH on
>>   c) 32-bit - Here, we run with a "fake" narrow Klass pointer mode. We run with hardcoded narrowKlass base == NULL and shift = 0, so nKlass == Klass*. The difference to (a, b) is that we don't use a class space. This was implemented with JDK-8363998 [3] - for more details, please see that issue and its PR.
>> 
>> I ensured *arm32* builds and I performed some rudimentary checks (selected metaspace/gc tests, and a simple Spring PetClinic run). Vendors with an interest in arm32 will have to step up and do their own, more thorough unit testing. Also, I did not see anyone doing follow-up work after JDK-8363998 [3] - so some issues may still lurk from that patch as well (but maybe JDK-8363998 was just not breaking anything).
>> 
>> I did not check *zero 32-bit*, the only other platform supporting 32-bit. Anyone with an interest in 32-bit zero should chip in.
>>   
>> Pre-existing errors: While working on this patch, I stumbled over a few occurrences of old but benign bugs. Mostly old code assuming CompressedClassPointers and CompressedOops were still tied together (example: Arguments::set_heap_size()). These bugs are implicitly fixed with this patch.
>> 
>> ### Testing
>> 
>> - tier 1 2 3 locally on Linux x64
>> - SAP ran their whole set of tests for all the platforms they support.
>> 
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8350754
>> [2...
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp
>   
>   Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>

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

> 490:     assert(CompressedKlassPointers::is_encodable(ik),
> 491:            "Klass " PTR_FORMAT "needs a narrow Klass ID, but is not encodable", p2i(ik));
> 492:   }

Suggestion:

  assert(ik == nullptr || CompressedKlassPointers::is_encodable(ik),
         "Klass " PTR_FORMAT "needs a narrow Klass ID, but is not encodable", p2i(ik));

src/hotspot/share/oops/oop.inline.hpp line 104:

> 102:       return CompressedKlassPointers::decode_not_null(_metadata._compressed_klass);
> 103:     default:
> 104:       return _metadata._klass;

Suggestion:

      ShouldNotReachHere();

src/hotspot/share/oops/oop.inline.hpp line 115:

> 113:       return CompressedKlassPointers::decode(_metadata._compressed_klass);
> 114:     default:
> 115:       return _metadata._klass;

Suggestion:

      ShouldNotReachHere();

src/hotspot/share/oops/oop.inline.hpp line 128:

> 126:     }
> 127:     default:
> 128:       return AtomicAccess::load_acquire(&_metadata._klass);

Suggestion:

      ShouldNotReachHere();

src/hotspot/share/oops/oop.inline.hpp line 139:

> 137:       return CompressedKlassPointers::decode_without_asserts(_metadata._compressed_klass);
> 138:     default:
> 139:       return _metadata._klass;

klass_mode() is either `Compact` or `Compressed`
Should be changed to:
Suggestion:

      ShouldNotReachHere();

src/hotspot/share/oops/oop.inline.hpp line 157:

> 155:   assert(Universe::is_bootstrapping() || (k != nullptr && k->is_klass()), "incorrect Klass");
> 156:   assert(!UseCompactObjectHeaders, "don't set Klass* with compact headers");
> 157:   _metadata._compressed_klass = CompressedKlassPointers::encode_not_null(k);

We might have to reconsider if we need to maintain the`union _metadata`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2598158553
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2598641735
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2598409080
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2598413848
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2598407527
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2598474672

From epeter at openjdk.org  Mon Dec  8 13:42:14 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 8 Dec 2025 13:42:14 GMT
Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization [v7]
In-Reply-To: <4-PqNRUxM-80k4mQdYNzc0HrirtkTCjfVAzgRewW08M=.d2fe4512-16cd-4abf-8a7f-e91341c37110@github.com>
References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com>
 <4-PqNRUxM-80k4mQdYNzc0HrirtkTCjfVAzgRewW08M=.d2fe4512-16cd-4abf-8a7f-e91341c37110@github.com>
Message-ID: <OYMrNQ1p3FfWtLtWoVQGsUW-6GzCPXoT8NWAzg62Ohc=.c1b7338a-c41f-49d2-ac8a-457845447c93@github.com>

On Mon, 1 Dec 2025 15:13:13 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> 
>> This pr add CMoveF/D on riscv, which enable vectorization of statement like: `op_1 bop op_2 ? res_f_d_1 : res_f_d_2 in a loop`.
>> 
>> This pr is also a preparation for further vectorization in https://github.com/openjdk/jdk/pull/28231.
>> 
>> Previously it's https://github.com/openjdk/jdk/pull/25341, but at that time, C2 SLP has some issue with unsigned comparison, which is now fixed, so it's good to continue the work.
>> 
>> # Test
>> ## Jtreg
>> 
>> in progress...
>> 
>> ## Performance
>> 
>> Column names meanings:
>> * p: with patch
>> * p+v: with patch, `-XX:+UseVectorCmov -XX:+UseCMoveUnconditionally` turned on
>> * m: without patch
>> * m+v: without patch, `-XX:+UseVectorCmov -XX:+UseCMoveUnconditionally` turned on
>> 
>> #### Average improvement
>> 
>> NOTE: With only this PR, it brings performance benefit in case of `CMoveF+CmpF`, `CMoveD+ComD`, `CMoveF+CmpI`, `CMoveD+CmpL`. The data below is based on fullly implmenting the vectorization of `CMoveI/L/F/D+CmpI/L/F/D`, which will be achieved by https://github.com/openjdk/jdk/pull/28231.
>> 
>> For details, check the performance data in https://github.com/openjdk/jdk/pull/25341 on riscv.
>> <google-sheets-html-origin style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
>> Opt (m/p) | Opt (m+v/p+v) | Opt (p/p+v) | Opt (m/p+v)
>> -- | -- | -- | --
>> 1.022782609 | 2.198717391 | 2.162673913 | 2.199
>> 
>> </google-sheets-html-origin>
>
> Hamlin Li has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove log_warning
>  - add test cases: BoolTest::ge/gt in enc_cmove_fp_cmp_fp

Nice work! I did not review the RISC-V specific changes, but had a look at the tests. Wow, there are a lot of them, and that's a good thing :)

I have a few comments below, to consider for improvement.

test/hotspot/jtreg/compiler/c2/irTests/TestConditionalMove.java line 39:

> 37:  * @summary Auto-vectorization enhancement to support vector conditional move.
> 38:  * @library /test/lib /
> 39:  * @run driver compiler.c2.irTests.TestConditionalMove

Suggestion:

 * @run driver ${test.main.class}

Might as well do that now. Avoids wrong copy of class name, which can lead to wrong test being run.

test/hotspot/jtreg/compiler/c2/irTests/TestConditionalMove.java line 1564:

> 1562:     // @IR(counts = {IRNode.CMOVE_I, ">0", IRNode.CMP_L, ">0"},
> 1563:     //     applyIf = {"UseVectorCmov", "false"},
> 1564:     //     applyIfPlatform = {"riscv64", "true"})

Why are these all commented out?

test/hotspot/jtreg/compiler/c2/irTests/TestScalarConditionalMoveCmpObj.java line 34:

> 32:  * @test
> 33:  * @summary Test conditional move + compare object.
> 34:  * @requires vm.simpleArch == "riscv64"

It would be really nice if we generally have no platform requirements at the top of the file, but just IR test applyIf instead. That way, everyone benefits from everyone else's tests and we have less test duplication down the line.

test/hotspot/jtreg/compiler/c2/irTests/TestScalarConditionalMoveCmpObj.java line 356:

> 354:             };
> 355:         }
> 356:     }

You could use `Generators.java`, it creates "interesting" distributions, and makes sure we use sufficient special case values.

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

Changes requested by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28309#pullrequestreview-3552071451
PR Review Comment: https://git.openjdk.org/jdk/pull/28309#discussion_r2598623788
PR Review Comment: https://git.openjdk.org/jdk/pull/28309#discussion_r2598632136
PR Review Comment: https://git.openjdk.org/jdk/pull/28309#discussion_r2598660768
PR Review Comment: https://git.openjdk.org/jdk/pull/28309#discussion_r2598654446

From mli at openjdk.org  Mon Dec  8 13:42:15 2025
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 8 Dec 2025 13:42:15 GMT
Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization [v7]
In-Reply-To: <a8Jj1OuTL0dGwYRJhsSkL5FyDJxvUEYiB0ORsQWQo30=.44f49b76-218d-4256-accd-77befb1e4259@github.com>
References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com>
 <4-PqNRUxM-80k4mQdYNzc0HrirtkTCjfVAzgRewW08M=.d2fe4512-16cd-4abf-8a7f-e91341c37110@github.com>
 <a8Jj1OuTL0dGwYRJhsSkL5FyDJxvUEYiB0ORsQWQo30=.44f49b76-218d-4256-accd-77befb1e4259@github.com>
Message-ID: <DtSoujnGFQGCwptyldajRQXJ47zc1w3SGzvxJ5gf7wk=.9506ab09-907e-4c35-9020-2afead0a4129@github.com>

On Mon, 8 Dec 2025 13:10:28 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - remove log_warning
>>  - add test cases: BoolTest::ge/gt in enc_cmove_fp_cmp_fp
>
> Marked as reviewed by luhenry (Committer).

@luhenry Thank you!

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

PR Comment: https://git.openjdk.org/jdk/pull/28309#issuecomment-3626985436

From epeter at openjdk.org  Mon Dec  8 13:42:16 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 8 Dec 2025 13:42:16 GMT
Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization [v7]
In-Reply-To: <DtSoujnGFQGCwptyldajRQXJ47zc1w3SGzvxJ5gf7wk=.9506ab09-907e-4c35-9020-2afead0a4129@github.com>
References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com>
 <4-PqNRUxM-80k4mQdYNzc0HrirtkTCjfVAzgRewW08M=.d2fe4512-16cd-4abf-8a7f-e91341c37110@github.com>
 <a8Jj1OuTL0dGwYRJhsSkL5FyDJxvUEYiB0ORsQWQo30=.44f49b76-218d-4256-accd-77befb1e4259@github.com>
 <DtSoujnGFQGCwptyldajRQXJ47zc1w3SGzvxJ5gf7wk=.9506ab09-907e-4c35-9020-2afead0a4129@github.com>
Message-ID: <P8aPgLJrZxbVSwhIPSFtb5SIaoM6B4pSr6fZIOu6qFY=.ce2e534f-c717-47c6-9505-7386e9144b24@github.com>

On Mon, 8 Dec 2025 13:36:24 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Marked as reviewed by luhenry (Committer).
>
> @luhenry Thank you!

@Hamlin-Li Oh bummer, I was just a few seconds too slow ?

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

PR Comment: https://git.openjdk.org/jdk/pull/28309#issuecomment-3626995177

From mli at openjdk.org  Mon Dec  8 13:42:17 2025
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 8 Dec 2025 13:42:17 GMT
Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization [v7]
In-Reply-To: <OYMrNQ1p3FfWtLtWoVQGsUW-6GzCPXoT8NWAzg62Ohc=.c1b7338a-c41f-49d2-ac8a-457845447c93@github.com>
References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com>
 <4-PqNRUxM-80k4mQdYNzc0HrirtkTCjfVAzgRewW08M=.d2fe4512-16cd-4abf-8a7f-e91341c37110@github.com>
 <OYMrNQ1p3FfWtLtWoVQGsUW-6GzCPXoT8NWAzg62Ohc=.c1b7338a-c41f-49d2-ac8a-457845447c93@github.com>
Message-ID: <EPehXgaFolkqr8DwvFIWLjgLsmyyRKW7cR6aHg_36nE=.629ff02b-bc4a-4090-8fbe-003361bcce89@github.com>

On Mon, 8 Dec 2025 13:36:38 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> Nice work! I did not review the RISC-V specific changes, but had a look at the tests. Wow, there are a lot of them, and that's a good thing :)
> 
> I have a few comments below, to consider for improvement.

@eme64 Thanks for having a look.
Seems there is a race condition here. :) I just triggered the integration. 
I'll file new bug to address your comment.

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

PR Comment: https://git.openjdk.org/jdk/pull/28309#issuecomment-3626997007

From epeter at openjdk.org  Mon Dec  8 13:42:19 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 8 Dec 2025 13:42:19 GMT
Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization [v7]
In-Reply-To: <OYMrNQ1p3FfWtLtWoVQGsUW-6GzCPXoT8NWAzg62Ohc=.c1b7338a-c41f-49d2-ac8a-457845447c93@github.com>
References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com>
 <4-PqNRUxM-80k4mQdYNzc0HrirtkTCjfVAzgRewW08M=.d2fe4512-16cd-4abf-8a7f-e91341c37110@github.com>
 <OYMrNQ1p3FfWtLtWoVQGsUW-6GzCPXoT8NWAzg62Ohc=.c1b7338a-c41f-49d2-ac8a-457845447c93@github.com>
Message-ID: <HR3zdTzdAfCyELu9H0C43KAjIy6f2Wrvrvy_m9B8cQY=.4758006d-bd20-4922-8b4e-98d293de4668@github.com>

On Mon, 8 Dec 2025 13:21:12 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - remove log_warning
>>  - add test cases: BoolTest::ge/gt in enc_cmove_fp_cmp_fp
>
> test/hotspot/jtreg/compiler/c2/irTests/TestConditionalMove.java line 39:
> 
>> 37:  * @summary Auto-vectorization enhancement to support vector conditional move.
>> 38:  * @library /test/lib /
>> 39:  * @run driver compiler.c2.irTests.TestConditionalMove
> 
> Suggestion:
> 
>  * @run driver ${test.main.class}
> 
> Might as well do that now. Avoids wrong copy of class name, which can lead to wrong test being run.

Also: if you are already renaming these tests, you might move them to a better directory as well. We want to avoid the `irTests` directory in the future,  and sort by topic instead.

Idea: put it under a `compiler/c2/cmove` directory.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28309#discussion_r2598664764

From mli at openjdk.org  Mon Dec  8 13:42:20 2025
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 8 Dec 2025 13:42:20 GMT
Subject: Integrated: 8357551: RISC-V: support CMoveF/D vectorization
In-Reply-To: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com>
References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com>
Message-ID: <V_nKV1tP1D4STIS3xJZCVLrVqihXWcWeQYEH7UQ6sMA=.7a47e220-686c-42d7-98a4-deaef1d9eeab@github.com>

On Thu, 13 Nov 2025 21:34:30 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> 
> This pr add CMoveF/D on riscv, which enable vectorization of statement like: `op_1 bop op_2 ? res_f_d_1 : res_f_d_2 in a loop`.
> 
> This pr is also a preparation for further vectorization in https://github.com/openjdk/jdk/pull/28231.
> 
> Previously it's https://github.com/openjdk/jdk/pull/25341, but at that time, C2 SLP has some issue with unsigned comparison, which is now fixed, so it's good to continue the work.
> 
> # Test
> ## Jtreg
> 
> in progress...
> 
> ## Performance
> 
> Column names meanings:
> * p: with patch
> * p+v: with patch, `-XX:+UseVectorCmov -XX:+UseCMoveUnconditionally` turned on
> * m: without patch
> * m+v: without patch, `-XX:+UseVectorCmov -XX:+UseCMoveUnconditionally` turned on
> 
> #### Average improvement
> 
> NOTE: With only this PR, it brings performance benefit in case of `CMoveF+CmpF`, `CMoveD+ComD`, `CMoveF+CmpI`, `CMoveD+CmpL`. The data below is based on fullly implmenting the vectorization of `CMoveI/L/F/D+CmpI/L/F/D`, which will be achieved by https://github.com/openjdk/jdk/pull/28231.
> 
> For details, check the performance data in https://github.com/openjdk/jdk/pull/25341 on riscv.
> <google-sheets-html-origin style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
> Opt (m/p) | Opt (m+v/p+v) | Opt (p/p+v) | Opt (m/p+v)
> -- | -- | -- | --
> 1.022782609 | 2.198717391 | 2.162673913 | 2.199
> 
> </google-sheets-html-origin>

This pull request has now been integrated.

Changeset: 6700baa5
Author:    Hamlin Li <mli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6700baa5052046f53eb1b04ed3205bbd8e9e9070
Stats:     10199 lines in 15 files changed: 6731 ins; 3270 del; 198 mod

8357551: RISC-V: support CMoveF/D vectorization

Reviewed-by: fyang, luhenry

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

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

From epeter at openjdk.org  Mon Dec  8 13:45:10 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 8 Dec 2025 13:45:10 GMT
Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization [v7]
In-Reply-To: <EPehXgaFolkqr8DwvFIWLjgLsmyyRKW7cR6aHg_36nE=.629ff02b-bc4a-4090-8fbe-003361bcce89@github.com>
References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com>
 <4-PqNRUxM-80k4mQdYNzc0HrirtkTCjfVAzgRewW08M=.d2fe4512-16cd-4abf-8a7f-e91341c37110@github.com>
 <OYMrNQ1p3FfWtLtWoVQGsUW-6GzCPXoT8NWAzg62Ohc=.c1b7338a-c41f-49d2-ac8a-457845447c93@github.com>
 <EPehXgaFolkqr8DwvFIWLjgLsmyyRKW7cR6aHg_36nE=.629ff02b-bc4a-4090-8fbe-003361bcce89@github.com>
Message-ID: <dyUHdwmoQCVu5bBrnzgAK6RmWJxKOWaLM_8-EJME9So=.824ece2f-b98e-4b4a-98d7-64eec01d4f5b@github.com>

On Mon, 8 Dec 2025 13:39:23 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Nice work! I did not review the RISC-V specific changes, but had a look at the tests. Wow, there are a lot of them, and that's a good thing :)
>> 
>> I have a few comments below, to consider for improvement.
>
>> Nice work! I did not review the RISC-V specific changes, but had a look at the tests. Wow, there are a lot of them, and that's a good thing :)
>> 
>> I have a few comments below, to consider for improvement.
> 
> @eme64 Thanks for having a look.
> Seems there is a race condition here. :) I just triggered the integration. 
> I'll file new bug to address your comment.

@Hamlin-Li Sounds good. I don't blame you, you had 2 reviewers ;)
I also did not run internal testing. Most likely everything will be fine.
Thanks for addressing my comments in the future, much appreciated!

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

PR Comment: https://git.openjdk.org/jdk/pull/28309#issuecomment-3627007431

From fgao at openjdk.org  Mon Dec  8 14:01:48 2025
From: fgao at openjdk.org (Fei Gao)
Date: Mon, 8 Dec 2025 14:01:48 GMT
Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() [v6]
In-Reply-To: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com>
References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com>
Message-ID: <CEvEqPtlTMiv7fX1G_spyCpyl8afEZn4McrzIBd5GRY=.d233254e-3626-4044-a3e1-c82bcbd55e45@github.com>

> 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/d15fa0d5...415495da

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26638/files
  - new: https://git.openjdk.org/jdk/pull/26638/files/f03979a1..415495da

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

  Stats: 3812 lines in 163 files changed: 3062 ins; 338 del; 412 mod
  Patch: https://git.openjdk.org/jdk/pull/26638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26638/head:pull/26638

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

From fgao at openjdk.org  Mon Dec  8 14:06:04 2025
From: fgao at openjdk.org (Fei Gao)
Date: Mon, 8 Dec 2025 14:06:04 GMT
Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() [v5]
In-Reply-To: <kCnAXn60i3EpXO6HLT0_Pgk4HKNXtvHwGPq5EdjfdQY=.b0b50515-26ff-4e4a-99a4-11151f375da3@github.com>
References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com>
 <HJEaGuERxWK3yRAacXiugTXtP4fcl2iS9F69D4ctroM=.24ade772-5208-44f6-a9dd-47d4e53fa410@github.com>
 <kCnAXn60i3EpXO6HLT0_Pgk4HKNXtvHwGPq5EdjfdQY=.b0b50515-26ff-4e4a-99a4-11151f375da3@github.com>
Message-ID: <O0NpEWBlGkCSIvlqThwYByqNX5N3njQ1dMgZ-Rn4BDA=.2be50c92-6dd3-4801-8f39-12ae53fb4b35@github.com>

On Sat, 6 Dec 2025 09:43:33 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Fei Gao 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:
>> 
>>   Update comments based on Aph's suggestion
>
> test/micro/org/openjdk/bench/vm/compiler/StaticCallStub.java line 68:
> 
>> 66:     public static class FarJump extends StaticCallStub {}
>> 67: 
>> 68: }
> 
> Suggestion:
> 
> }

Done. Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26638#discussion_r2598761582

From bkilambi at openjdk.org  Mon Dec  8 14:14:17 2025
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Mon, 8 Dec 2025 14:14:17 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v5]
In-Reply-To: <Vqu9FE4SgvqWFWn0U9718IDFzJviLpKyRyfYc7qrrZ0=.04845f2a-e4f5-4bb5-8f8f-d6bb001ca9c3@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <Vqu9FE4SgvqWFWn0U9718IDFzJviLpKyRyfYc7qrrZ0=.04845f2a-e4f5-4bb5-8f8f-d6bb001ca9c3@github.com>
Message-ID: <9l2GpacNaxOlYFPSJe-nRiAm1cPWcxYxg65R0o0ElgE=.59208f2f-df36-4eb3-93ac-62ada0eca4d6@github.com>

On Wed, 26 Nov 2025 11:34:11 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Add a new  Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type.
>> - Add necessary inline expander support.
>>    - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA.
>> - Use existing Float16 vector IR and backend support.
>> - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations.
>>  
>> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc).
>> 
>> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels.
>> 
>> <img width="1449" height="629" alt="image" src="https://github.com/user-attachments/assets/b4474361-9886-4315-a614-f4073fd075b9" />
>> 
>> 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:
> 
>   Cleanups

test/hotspot/jtreg/compiler/vectorapi/TestFloat16VectorOperations.java line 82:

> 80:         output = new short[LEN];
> 81: 
> 82:         short min_value = float16ToRawShortBits(Float16.MIN_VALUE);

`min_value` and `max_value` not being used anywhere?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2598793109

From roland at openjdk.org  Mon Dec  8 14:52:35 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Mon, 8 Dec 2025 14:52:35 GMT
Subject: RFR: 8354282: C2: more crashes in compiled code because of
 dependency on removed range check CastIIs
In-Reply-To: <2uqd_nRO0UZWonQnFDqkWYvrYwTGQbDEDnWx3C4eoAo=.65472aeb-e9c2-4f99-8728-d4c7e1afaf57@github.com>
References: <qos-VYvgreqGsB7ke35RmM3L9uHnnM6nUsm2QONKXc4=.9c902d61-5f45-41f5-8276-ac28830c2bf5@github.com>
 <2uqd_nRO0UZWonQnFDqkWYvrYwTGQbDEDnWx3C4eoAo=.65472aeb-e9c2-4f99-8728-d4c7e1afaf57@github.com>
Message-ID: <vQk5vs86JYvB8x6j11ZxN7TXNavhUqS3LJxEczDB35I=.34a4107c-e54b-4008-b201-be34ee039e6f@github.com>

On Mon, 14 Apr 2025 11:50:27 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> This is a variant of 8332827. In 8332827, an array access becomes
>> dependent on a range check `CastII` for another array access. When,
>> after loop opts are over, that RC `CastII` was removed, the array
>> access could float and an out of bound access happened. With the fix
>> for 8332827, RC `CastII`s are no longer removed.
>> 
>> With this one what happens is that some transformations applied after
>> loop opts are over widen the type of the RC `CastII`. As a result, the
>> type of the RC `CastII` is no longer narrower than that of its input,
>> the `CastII` is removed and the dependency is lost.
>> 
>> There are 2 transformations that cause this to happen:
>> 
>> - after loop opts are over, the type of the `CastII` nodes are widen
>>   so nodes that have the same inputs but a slightly different type can
>>   common.
>>   
>> - When pushing a `CastII` through an `Add`, if of the type both inputs
>>   of the `Add`s are non constant, then we end up widening the type
>>   (the resulting `Add` has a type that's wider than that of the
>>   initial `CastII`).
>>   
>> There are already 3 types of `Cast` nodes depending on the
>> optimizations that are allowed. Either the `Cast` is floating
>> (`depends_only_test()` returns `true`) or pinned. Either the `Cast`
>> can be removed if it no longer narrows the type of its input or
>> not. We already have variants of the `CastII`:
>> 
>> - if the Cast can float and be removed when it doesn't narrow the type
>> of its input.
>> 
>> - if the Cast is pinned and be removed when it doesn't narrow the type
>> of its input.
>> 
>> - if the Cast is pinned and can't be removed when it doesn't narrow
>> the type of its input.
>> 
>> What we need here, I think, is the 4th combination:
>> 
>> - if the Cast can float and can't be removed when it doesn't narrow
>> the type of its input.
>> 
>> Anyway, things are becoming confusing with all these different
>> variants named in ways that don't always help figure out what
>> constraints one of them operate under. So I refactored this and that's
>> the biggest part of this change. The fix consists in marking `Cast`
>> nodes when their type is widen in a way that prevents them from being
>> optimized out.
>> 
>> Tobias ran performance testing with a slightly different version of
>> this change and there was no regression.
>
> If a `CastII` that does not narrow its input has its type being a constant, do you think GVN should transform it into a constant, or such nodes should return the bottom type so that it is not folded into a floating `ConNode`?

@merykitty @eme64 @chhagedorn thanks for the reviews
Does testing need to be run on this before I integrate?

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

PR Comment: https://git.openjdk.org/jdk/pull/24575#issuecomment-3627292197

From kvn at openjdk.org  Mon Dec  8 15:46:25 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 8 Dec 2025 15:46:25 GMT
Subject: RFR: 8373114: Redundant MethodCounters in the preimage generated
 by training run
In-Reply-To: <QCYr-gelNbdNe61ez5AW9wN5RiL-YzqwlRdP9vLsFdo=.77e0d1ba-4088-4e04-827b-e0de409b4ce6@github.com>
References: <LRw06Cn_4dcRW8YyFVr3RijMHIha7nPzBrcNNzaIny8=.dc07d0ee-b797-4434-aad0-956a00c2ea6f@github.com>
 <QCYr-gelNbdNe61ez5AW9wN5RiL-YzqwlRdP9vLsFdo=.77e0d1ba-4088-4e04-827b-e0de409b4ce6@github.com>
Message-ID: <aO-jBrY1nltg1UjIRIR3HU_eJl5GTahrhwIj090f9QY=.ccd34d01-b6f3-4f4f-aa76-ce69a51d6c02@github.com>

On Sun, 7 Dec 2025 05:41:38 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

> They are not used right now but @vnkozlov is going to use them for the A4 recompilation strategy.

yes, I need it for A4 entry counter.

Also I thought MC is used to cache MTD pointer:
https://github.com/openjdk/leyden/blob/master/src/hotspot/share/oops/trainingData.cpp#L120

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

PR Comment: https://git.openjdk.org/jdk/pull/28670#issuecomment-3627579312

From epeter at openjdk.org  Mon Dec  8 15:50:55 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 8 Dec 2025 15:50:55 GMT
Subject: RFR: 8354282: C2: more crashes in compiled code because of
 dependency on removed range check CastIIs
In-Reply-To: <vQk5vs86JYvB8x6j11ZxN7TXNavhUqS3LJxEczDB35I=.34a4107c-e54b-4008-b201-be34ee039e6f@github.com>
References: <qos-VYvgreqGsB7ke35RmM3L9uHnnM6nUsm2QONKXc4=.9c902d61-5f45-41f5-8276-ac28830c2bf5@github.com>
 <2uqd_nRO0UZWonQnFDqkWYvrYwTGQbDEDnWx3C4eoAo=.65472aeb-e9c2-4f99-8728-d4c7e1afaf57@github.com>
 <vQk5vs86JYvB8x6j11ZxN7TXNavhUqS3LJxEczDB35I=.34a4107c-e54b-4008-b201-be34ee039e6f@github.com>
Message-ID: <l4_QKbxkFJShOP217rWGzoCaBJT3w51SLleJaza6wK4=.91cd9b8f-ea84-4b32-8891-d8491010b650@github.com>

On Mon, 8 Dec 2025 14:49:41 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> If a `CastII` that does not narrow its input has its type being a constant, do you think GVN should transform it into a constant, or such nodes should return the bottom type so that it is not folded into a floating `ConNode`?
>
> @merykitty @eme64 @chhagedorn thanks for the reviews
> Does testing need to be run on this before I integrate?

@rwestrel I'll run some testing now ...

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

PR Comment: https://git.openjdk.org/jdk/pull/24575#issuecomment-3627616227

From aartemov at openjdk.org  Mon Dec  8 16:07:29 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Mon, 8 Dec 2025 16:07:29 GMT
Subject: RFR: 8366671: Refactor Thread::SpinAcquire and Thread::SpinRelease
 [v15]
In-Reply-To: <S17J-2hDlDeS2qYJhPN2dww5vKxOk9Ug_I0gdFMHU9Q=.dc031058-08d0-4e52-b231-ba92f72e1486@github.com>
References: <NtY8E8fBeSokCAQYP3OQEwfnppSugtTJ8uAtQtD0zvg=.88f2988d-47fd-4b8a-af89-488ed6b37870@github.com>
 <S17J-2hDlDeS2qYJhPN2dww5vKxOk9Ug_I0gdFMHU9Q=.dc031058-08d0-4e52-b231-ba92f72e1486@github.com>
Message-ID: <fHab0NAtmtyiyXpultWigsyU-s9-llTwNS40_9NqLM4=.57c73700-7d5f-48f7-b20a-479c0773841e@github.com>

On Mon, 8 Dec 2025 12:56:53 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, 
>> 
>> please consider the following changes:
>> 
>> In this PR `Thread::SpinAcquire()` and `Thread::SpinRelease()` methods are refactored into a utility class `SpinCriticalSection`. The motivation is to make it easier for developers to use this lightweight synchronization mechanism in the codebase. The two aforementioned methods were used in JFR to create short critical sections with a helper class, but that was not the case for the object monitor code. 
>> 
>> Tested in tiers 1 - 5.
>
> Anton Artemov 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:
> 
>  - Merge remote-tracking branch 'origin/master' into JDK-8366671-refactor-spin-acquire-spin-release
>  - 8366671: Use non-safe current_or_null.
>  - Update src/hotspot/share/runtime/objectMonitor.cpp
>    
>    Co-authored-by: Coleen Phillimore <coleen.phillimore at oracle.com>
>  - 8366671: Added NoSafepointVerifier
>  - 8366671: Modified the comment.
>  - Merge remote-tracking branch 'origin/master' into JDK-8366671-refactor-spin-acquire-spin-release
>  - 8366671: Addressed reviewer's comments.
>  - 8366671: Addressed reviewers' comments.
>  - 8366671: Addressed reviewer's comments
>  - 8366671: Removed redundant include.
>  - ... and 9 more: https://git.openjdk.org/jdk/compare/7093e1a5...7e0cf5a5

Thanks for reviews, let's

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

PR Comment: https://git.openjdk.org/jdk/pull/28264#issuecomment-3627737570

From aartemov at openjdk.org  Mon Dec  8 16:09:47 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Mon, 8 Dec 2025 16:09:47 GMT
Subject: Integrated: 8366671: Refactor Thread::SpinAcquire and
 Thread::SpinRelease
In-Reply-To: <NtY8E8fBeSokCAQYP3OQEwfnppSugtTJ8uAtQtD0zvg=.88f2988d-47fd-4b8a-af89-488ed6b37870@github.com>
References: <NtY8E8fBeSokCAQYP3OQEwfnppSugtTJ8uAtQtD0zvg=.88f2988d-47fd-4b8a-af89-488ed6b37870@github.com>
Message-ID: <jm6-TKQx1JuOva4wf3hyhiQTBoff4WhMWj1M6wGoy6o=.842a6370-db0c-4e6d-b311-faf8cf83827f@github.com>

On Wed, 12 Nov 2025 11:17:22 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

> Hi, 
> 
> please consider the following changes:
> 
> In this PR `Thread::SpinAcquire()` and `Thread::SpinRelease()` methods are refactored into a utility class `SpinCriticalSection`. The motivation is to make it easier for developers to use this lightweight synchronization mechanism in the codebase. The two aforementioned methods were used in JFR to create short critical sections with a helper class, but that was not the case for the object monitor code. 
> 
> Tested in tiers 1 - 5.

This pull request has now been integrated.

Changeset: 355755d3
Author:    Anton Artemov <aartemov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/355755d35de5c3155d1ea8d1afdd0debe5296a13
Stats:     262 lines in 12 files changed: 143 ins; 107 del; 12 mod

8366671: Refactor Thread::SpinAcquire and Thread::SpinRelease

Co-authored-by: Axel Boldt-Christmas <aboldtch at openjdk.org>
Reviewed-by: coleenp, kbarrett, dholmes, aboldtch

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

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

From eastigeevich at openjdk.org  Mon Dec  8 17:39:05 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 8 Dec 2025 17:39:05 GMT
Subject: RFR: 8359359: AArch64: share trampolines between static calls to
 the same method [v9]
In-Reply-To: <l9q8GG_sZTsbmbqjQ3EBZpokzhH5PLKtfUWYT5_YSyI=.e29418f3-f6ab-4eb5-96ff-20c387e7ea9f@github.com>
References: <3mB1bU-08ZvsJkR52D-nNFObwsaysNHxBkF1L42lmIY=.459e1ba8-118e-4a3a-8049-415765d25553@github.com>
 <l9q8GG_sZTsbmbqjQ3EBZpokzhH5PLKtfUWYT5_YSyI=.e29418f3-f6ab-4eb5-96ff-20c387e7ea9f@github.com>
Message-ID: <HqUsl4iP5KNvdM5d9LTV2K6t6uVdE23cONq_Miej44U=.78fe36cb-06ec-462c-8630-aed2295c1274@github.com>

On Tue, 25 Nov 2025 18:00:10 GMT, Mikhail Ablakatov <mablakatov at openjdk.org> 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

lgtm

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

Marked as reviewed by eastigeevich (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25954#pullrequestreview-3553259493

From jvernee at openjdk.org  Mon Dec  8 17:54:02 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 8 Dec 2025 17:54:02 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v8]
In-Reply-To: <C0kGO-Sn5AEvyTvnM3HWEVA30vjCsol9mwiTFzJItA0=.6d97913c-f521-4c43-97ec-edd718de55fc@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <C0kGO-Sn5AEvyTvnM3HWEVA30vjCsol9mwiTFzJItA0=.6d97913c-f521-4c43-97ec-edd718de55fc@github.com>
Message-ID: <x-7pMREvH57ZMx31eV8YnUz4xfIFPIw73kkdh2w3ke4=.0b2377c3-8293-455d-9fa4-1812e8e6f763@github.com>

On Mon, 8 Dec 2025 02:08:37 GMT, Chen Liang <liach at openjdk.org> 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 15 additional commits since the last revision:
> 
>  - Bugs and verify loader leak
>  - Try to avoid loader leak
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache
>  - Revert void special case removal due to C2 shortage causing TestZGCBarrierElision::testAtomicThenAtomicAnotherField failure
>  - Test from Jorn
>  - Copyright years
>  - Fix problem identified by Jorn
>  - Rollback getAndAdd for now
>  - Redundant change
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/513d3327...eebb8ff7

src/java.base/share/classes/java/lang/invoke/IndirectVarHandle.java line 114:

> 112:         // but checking the signature type of MH mostly works
> 113:         return MethodHandle.isReachableFrom(vform.getMethodType(0), cl)
> 114:                 && target.isReachableFrom(cl);

Right... one of the filters may also keep a class loader alive. But to check them, we'd have to eagerly instantiate all of them as well.

FWIW, I don't think this is an issue we can just ignore. If a filter keeps a class loader alive, we'd still have a problem.

Maybe it's possible to collect all the types involved from the filter when creating an IndirectVarHandle instead, and save those in a separate list for this check.

src/java.base/share/classes/java/lang/invoke/MethodHandle.java line 983:

> 981:     }
> 982: 
> 983:     static boolean isBuiltinLoader(ClassLoader loader) {

I think this can still be private?

src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2018:

> 2016:         // Call MethodHandle.isReachableFrom for the used classes
> 2017:         return true;
> 2018:     }

Can you make this `abstract`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2599553053
PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2599496891
PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2599488329

From iklam at openjdk.org  Mon Dec  8 17:59:58 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 8 Dec 2025 17:59:58 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v15]
In-Reply-To: <HiF5EwAj4DlTEOa85zqXgd2RbgbQjLNayJ6925N00ZU=.34ad1757-d497-4166-b9c7-745c8d82d228@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <HiF5EwAj4DlTEOa85zqXgd2RbgbQjLNayJ6925N00ZU=.34ad1757-d497-4166-b9c7-745c8d82d228@github.com>
Message-ID: <zRzo1bngRxh42bVMgTw_XPwiMuStUUGRxw19k44oygc=.c8dcb7e7-8a7f-4c11-81fe-cd600b907b72@github.com>

On Wed, 3 Dec 2025 22:29:24 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
>> 
>> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
>> 
>> TRUE
>> FALSE
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporate feedback into documentation

Looks good to me.

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

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28010#pullrequestreview-3553358656

From mli at openjdk.org  Mon Dec  8 18:01:22 2025
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 8 Dec 2025 18:01:22 GMT
Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization [v7]
In-Reply-To: <HR3zdTzdAfCyELu9H0C43KAjIy6f2Wrvrvy_m9B8cQY=.4758006d-bd20-4922-8b4e-98d293de4668@github.com>
References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com>
 <4-PqNRUxM-80k4mQdYNzc0HrirtkTCjfVAzgRewW08M=.d2fe4512-16cd-4abf-8a7f-e91341c37110@github.com>
 <OYMrNQ1p3FfWtLtWoVQGsUW-6GzCPXoT8NWAzg62Ohc=.c1b7338a-c41f-49d2-ac8a-457845447c93@github.com>
 <HR3zdTzdAfCyELu9H0C43KAjIy6f2Wrvrvy_m9B8cQY=.4758006d-bd20-4922-8b4e-98d293de4668@github.com>
Message-ID: <YLkD9uTkHoHDS9xIjgy4d0CPXychurOKu0ek6ZjLeFg=.8564a131-7ed1-468d-8fca-846d67589120@github.com>

On Mon, 8 Dec 2025 13:34:10 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/c2/irTests/TestConditionalMove.java line 39:
>> 
>>> 37:  * @summary Auto-vectorization enhancement to support vector conditional move.
>>> 38:  * @library /test/lib /
>>> 39:  * @run driver compiler.c2.irTests.TestConditionalMove
>> 
>> Suggestion:
>> 
>>  * @run driver ${test.main.class}
>> 
>> Might as well do that now. Avoids wrong copy of class name, which can lead to wrong test being run.
>
> Also: if you are already renaming these tests, you might move them to a better directory as well. We want to avoid the `irTests` directory in the future,  and sort by topic instead.
> 
> Idea: put it under a `compiler/c2/cmove` directory.

addressed in https://github.com/openjdk/jdk/pull/28702.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28309#discussion_r2599583943

From mli at openjdk.org  Mon Dec  8 18:01:25 2025
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 8 Dec 2025 18:01:25 GMT
Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization [v7]
In-Reply-To: <OYMrNQ1p3FfWtLtWoVQGsUW-6GzCPXoT8NWAzg62Ohc=.c1b7338a-c41f-49d2-ac8a-457845447c93@github.com>
References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com>
 <4-PqNRUxM-80k4mQdYNzc0HrirtkTCjfVAzgRewW08M=.d2fe4512-16cd-4abf-8a7f-e91341c37110@github.com>
 <OYMrNQ1p3FfWtLtWoVQGsUW-6GzCPXoT8NWAzg62Ohc=.c1b7338a-c41f-49d2-ac8a-457845447c93@github.com>
Message-ID: <eSH5yZyHtLYwRG9AAQgsQBmX_mLnnB2bCTJ23fu8mA8=.5c3b8405-b3ce-4d68-86d1-c60fadc0fa22@github.com>

On Mon, 8 Dec 2025 13:32:54 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - remove log_warning
>>  - add test cases: BoolTest::ge/gt in enc_cmove_fp_cmp_fp
>
> test/hotspot/jtreg/compiler/c2/irTests/TestScalarConditionalMoveCmpObj.java line 34:
> 
>> 32:  * @test
>> 33:  * @summary Test conditional move + compare object.
>> 34:  * @requires vm.simpleArch == "riscv64"
> 
> It would be really nice if we generally have no platform requirements at the top of the file, but just IR test applyIf instead. That way, everyone benefits from everyone else's tests and we have less test duplication down the line.

addressed in https://github.com/openjdk/jdk/pull/28702.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28309#discussion_r2599583136

From iveresov at openjdk.org  Mon Dec  8 18:12:09 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Mon, 8 Dec 2025 18:12:09 GMT
Subject: RFR: 8373114: Redundant MethodCounters in the preimage generated
 by training run
In-Reply-To: <LRw06Cn_4dcRW8YyFVr3RijMHIha7nPzBrcNNzaIny8=.dc07d0ee-b797-4434-aad0-956a00c2ea6f@github.com>
References: <LRw06Cn_4dcRW8YyFVr3RijMHIha7nPzBrcNNzaIny8=.dc07d0ee-b797-4434-aad0-956a00c2ea6f@github.com>
Message-ID: <T6JgYsklvsJroQxJLTdTH5UYg07YA_R4fWPCk3ce0hs=.6d7ab7a3-31b7-4847-82a5-bfc980c7ea16@github.com>

On Thu, 4 Dec 2025 22:16:03 GMT, Ashutosh Mehra <asmehra at openjdk.org> 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

Yes, but caching is a runtime thing it's not really need in the archive. But for your work we probably do need it.

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

PR Comment: https://git.openjdk.org/jdk/pull/28670#issuecomment-3628370410

From macarte at openjdk.org  Mon Dec  8 18:29:02 2025
From: macarte at openjdk.org (Mat Carter)
Date: Mon, 8 Dec 2025 18:29:02 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v15]
In-Reply-To: <zRzo1bngRxh42bVMgTw_XPwiMuStUUGRxw19k44oygc=.c8dcb7e7-8a7f-4c11-81fe-cd600b907b72@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <HiF5EwAj4DlTEOa85zqXgd2RbgbQjLNayJ6925N00ZU=.34ad1757-d497-4166-b9c7-745c8d82d228@github.com>
 <zRzo1bngRxh42bVMgTw_XPwiMuStUUGRxw19k44oygc=.c8dcb7e7-8a7f-4c11-81fe-cd600b907b72@github.com>
Message-ID: <b1flBZPs6DeW7CEg1ggPW93o2IJQkO0d9pRba3J1wE0=.0663df75-cba3-47bd-8b3b-44287f84706a@github.com>

On Mon, 8 Dec 2025 17:57:38 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Looks good to me.

Thanks for the review and the documentation Ioi (I've updated the CSR); once Mark approves my updates based on his change requests we should be good to go.

Note that serviceability retargeted to jdk27 (they discussed this with me), this works for me although I know there's a process if we do want to hit JDK26 (given that we missed the first gate), let me know if there's consensus for pushing into JDK26

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

PR Comment: https://git.openjdk.org/jdk/pull/28010#issuecomment-3628441123

From liach at openjdk.org  Mon Dec  8 18:29:05 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 8 Dec 2025 18:29:05 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v8]
In-Reply-To: <x-7pMREvH57ZMx31eV8YnUz4xfIFPIw73kkdh2w3ke4=.0b2377c3-8293-455d-9fa4-1812e8e6f763@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <C0kGO-Sn5AEvyTvnM3HWEVA30vjCsol9mwiTFzJItA0=.6d97913c-f521-4c43-97ec-edd718de55fc@github.com>
 <x-7pMREvH57ZMx31eV8YnUz4xfIFPIw73kkdh2w3ke4=.0b2377c3-8293-455d-9fa4-1812e8e6f763@github.com>
Message-ID: <TnqE0J1VxzGZC177Lrtv8PM7HgXkA6cvJnfzkk4785c=.f35bbe36-e88a-4a01-9ecd-b7c8e4d9b8c1@github.com>

On Mon, 8 Dec 2025 17:49:41 GMT, Jorn Vernee <jvernee at openjdk.org> 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 15 additional commits since the last revision:
>> 
>>  - Bugs and verify loader leak
>>  - Try to avoid loader leak
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache
>>  - Revert void special case removal due to C2 shortage causing TestZGCBarrierElision::testAtomicThenAtomicAnotherField failure
>>  - Test from Jorn
>>  - Copyright years
>>  - Fix problem identified by Jorn
>>  - Rollback getAndAdd for now
>>  - Redundant change
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache
>>  - ... and 5 more: https://git.openjdk.org/jdk/compare/50bcb546...eebb8ff7
>
> src/java.base/share/classes/java/lang/invoke/IndirectVarHandle.java line 114:
> 
>> 112:         // but checking the signature type of MH mostly works
>> 113:         return MethodHandle.isReachableFrom(vform.getMethodType(0), cl)
>> 114:                 && target.isReachableFrom(cl);
> 
> Right... one of the filters may also keep a class loader alive. But to check them, we'd have to eagerly instantiate all of them as well.
> 
> FWIW, I don't think this is an issue we can just ignore. If a filter keeps a class loader alive, we'd still have a problem.
> 
> Maybe it's possible to collect all the types involved from the filter when creating an IndirectVarHandle instead, and save those in a separate list for this check.

I mean a filter method handle may keep other classes alive in addition to just its types. This is not possible from just checking the types. The vform method type is sufficient, because the types from the filter method type is always in one of the indirect layers.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2599683049

From ayang at openjdk.org  Mon Dec  8 18:56:09 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 8 Dec 2025 18:56:09 GMT
Subject: RFR: 8370198: Test gc/arguments/TestShrinkHeapInSteps.java
 crashed:  assert(left >= right) failed: avoid underflow [v5]
In-Reply-To: <NmuSRRaTMsLhiejYs3If27QxYcmuh71L7ViT5EWGjOY=.d90b539a-8376-4be5-837c-6cd0824975c6@github.com>
References: <WKjyigvXghJNT-bijIBX8dyE1cdd3GsubdHvrNrYHyM=.dedfb4bc-b098-4d8f-8f5a-291d92fe9f2d@github.com>
 <NmuSRRaTMsLhiejYs3If27QxYcmuh71L7ViT5EWGjOY=.d90b539a-8376-4be5-837c-6cd0824975c6@github.com>
Message-ID: <XumwHeZ-5oPhHcO7RycRhxA_5pbN0P_kl-d0UZJR1uU=.47c5ce6b-2d6c-42fe-95d8-4767b18361a2@github.com>

On Fri, 5 Dec 2025 11:01:17 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Add an early-return for outside-heap address in `CollectedHeap::is_in` API.
>> 
>> While investigating this failure (JDK-8370198), I realized that some java-threads (compiler-threads) in `native` state can invoke `CollectedHeap` APIs. Since heap-resizing occurs inside safepoint but java-threads in `native` state just ignore safepoint, I have added some assert to catch such dangerous uses, where the return value might not be stable.
>> 
>> Test: tie1-5; can't reproduce the JDK-8370198 with or without this patch for >8000 runs.
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/gc/serial/serialHeap.cpp
>   
>   Co-authored-by: Stefan Karlsson <stefan.karlsson at oracle.com>

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/28393#issuecomment-3628550209

From ayang at openjdk.org  Mon Dec  8 18:56:10 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 8 Dec 2025 18:56:10 GMT
Subject: Integrated: 8370198: Test gc/arguments/TestShrinkHeapInSteps.java
 crashed:  assert(left >= right) failed: avoid underflow
In-Reply-To: <WKjyigvXghJNT-bijIBX8dyE1cdd3GsubdHvrNrYHyM=.dedfb4bc-b098-4d8f-8f5a-291d92fe9f2d@github.com>
References: <WKjyigvXghJNT-bijIBX8dyE1cdd3GsubdHvrNrYHyM=.dedfb4bc-b098-4d8f-8f5a-291d92fe9f2d@github.com>
Message-ID: <K_IARQs0fu7O1Fne_BRSbMp1A0q7wk1zWG7LhJ9RKYU=.5090d8d6-a7ef-446b-bd1a-e4927e6d2f76@github.com>

On Wed, 19 Nov 2025 15:39:27 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Add an early-return for outside-heap address in `CollectedHeap::is_in` API.
> 
> While investigating this failure (JDK-8370198), I realized that some java-threads (compiler-threads) in `native` state can invoke `CollectedHeap` APIs. Since heap-resizing occurs inside safepoint but java-threads in `native` state just ignore safepoint, I have added some assert to catch such dangerous uses, where the return value might not be stable.
> 
> Test: tie1-5; can't reproduce the JDK-8370198 with or without this patch for >8000 runs.

This pull request has now been integrated.

Changeset: d34ef196
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d34ef196c298aa91f8511714cfb04b15ae7fbf0a
Stats:     21 lines in 4 files changed: 19 ins; 2 del; 0 mod

8370198: Test gc/arguments/TestShrinkHeapInSteps.java crashed:  assert(left >= right) failed: avoid underflow

Reviewed-by: stefank, tschatzl

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

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

From liach at openjdk.org  Mon Dec  8 19:10:48 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 8 Dec 2025 19:10:48 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v9]
In-Reply-To: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
Message-ID: <4YumBpbA2k8DC13H1s808_5OJx-1FMxD9CbIUfRTb8Q=.742f90c9-0d93-43b7-abe7-76422a0c8359@github.com>

> 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 17 additional commits since the last revision:

 - 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
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache
 - Revert void special case removal due to C2 shortage causing TestZGCBarrierElision::testAtomicThenAtomicAnotherField failure
 - Test from Jorn
 - Copyright years
 - Fix problem identified by Jorn
 - Rollback getAndAdd for now
 - ... and 7 more: https://git.openjdk.org/jdk/compare/1f095c6b...d734e8a6

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28585/files
  - new: https://git.openjdk.org/jdk/pull/28585/files/eebb8ff7..d734e8a6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28585&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28585&range=07-08

  Stats: 11891 lines in 51 files changed: 8198 ins; 3438 del; 255 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 ayang at openjdk.org  Mon Dec  8 19:11:10 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 8 Dec 2025 19:11:10 GMT
Subject: [jdk26] RFR: 8370198: Test gc/arguments/TestShrinkHeapInSteps.java
 crashed:  assert(left >= right) failed: avoid underflow
Message-ID: <NeZODWztZjkhI8wnXNnxtuxvkxC-AGlTcxA-sezVSzU=.8aa91669-d535-43a9-80a6-28bd9fe3f2ab@github.com>

8370198: Test gc/arguments/TestShrinkHeapInSteps.java crashed:  assert(left >= right) failed: avoid underflow

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

Commit messages:
 - Backport d34ef196c298aa91f8511714cfb04b15ae7fbf0a

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

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

From dholmes at openjdk.org  Mon Dec  8 19:47:09 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 8 Dec 2025 19:47:09 GMT
Subject: RFR: 8366671: Refactor Thread::SpinAcquire and Thread::SpinRelease
 [v12]
In-Reply-To: <328KtTBIXsGzjIVrTBc79c5UHJjDwuf44CD8NiNXKxk=.fdb6e67f-2795-4e77-a3b9-3cf5f1774cdb@github.com>
References: <NtY8E8fBeSokCAQYP3OQEwfnppSugtTJ8uAtQtD0zvg=.88f2988d-47fd-4b8a-af89-488ed6b37870@github.com>
 <BLbZykwmGPMfOyN0A7lrjaht-OWDbWK9_ArQRZZTVCU=.4bbd7292-3028-44f2-b0a5-cb4f29c2044b@github.com>
 <Z0c-dWNWbxGumcLpse7-H3fGuAI5h9XBdu9bsJdRGeA=.bf035f09-aedf-401a-bf6d-90cf2568d48c@github.com>
 <g51FTZgI8RY6EqjJxfGYFe8RltiRQG8muogTidUqvJc=.95e1128b-d6e1-40cd-a624-aee2630fbfb7@github.com>
 <KbihuIqL_t7wzUfBlOrV_8WJBd_f7Bk5J2cabYY_588=.0db43b71-5b27-4734-9acd-d55e41cfb052@github.com>
 <RDgpMBLrvMdqjHIGHkt07nePBNX6EEGVycu-zgFCGis=.1b1427dd-cd73-46e5-961f-7406cb5ea7a5@github.com>
 <bC6YmsXPkCll0XRGHJf5aDhBHtudQkHWSyoF9hsPwdA=.cc36939c-071d-4e10-91de-040949bff1f9@github.com>
 <PE4qX-iP2pUraSKInpccGsgMBM0v0pnaWlqkwOoWc-A=.b850cb0d-d39b-449e-af9b-1302913a4655@github.com>
 <UI25SdDAt4IhIDq5Gb7QJwyqx8td87ODo6k1cGYrLQc=.8b3bf59b-a56e-4924-bfb8-753c82851b68@github.com>
 <328KtTBIXsGzjIVrTBc79c5UHJjDwuf44CD8NiNXKxk=.fdb6e67f-2795-4e77-a3b9-3cf5f1774cdb@github.com>
Message-ID: <Zq7xrFj0WsRLK8wRprc6Co9LINVKdnoJf11G-vl413o=.a1f0beaa-528d-47b5-b4a4-9256e145ed4e@github.com>

On Mon, 8 Dec 2025 12:48:21 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>>> Because the safe version can be called very early in VM init we have to check the library-based TLS is initilalized.
>> 
>> Can the ParkEvent not be called very early in VM init as well?
>
> I guess we should assume that it can be called at any time.

The ParkEvent code is of course first called during VM init when we create the initial JavaThread. Really not sure why this is being raised.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28264#discussion_r2599911405

From iklam at openjdk.org  Mon Dec  8 19:50:57 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 8 Dec 2025 19:50:57 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v15]
In-Reply-To: <HiF5EwAj4DlTEOa85zqXgd2RbgbQjLNayJ6925N00ZU=.34ad1757-d497-4166-b9c7-745c8d82d228@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <HiF5EwAj4DlTEOa85zqXgd2RbgbQjLNayJ6925N00ZU=.34ad1757-d497-4166-b9c7-745c8d82d228@github.com>
Message-ID: <gUrT62X5ijdwfI_xFMDo8BwIOdLrjXxvFjwwiySZ8d4=.12beb30d-4922-4321-a49b-1abfb11f73fb@github.com>

On Wed, 3 Dec 2025 22:29:24 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
>> 
>> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
>> 
>> TRUE
>> FALSE
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporate feedback into documentation

I think it's OK to integrate into the mainline (for 27) once you get an approval from Mark.

For JDK 26, I think we can following this process:
- https://openjdk.org/jeps/3#Late-Enhancement-Request-Process

I'll try to update the JBS issue with a justification.

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

PR Comment: https://git.openjdk.org/jdk/pull/28010#issuecomment-3628741594

From jvernee at openjdk.org  Mon Dec  8 20:21:59 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 8 Dec 2025 20:21:59 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting [v4]
In-Reply-To: <ZAwzDRCIo_TqIYbErunjdBZkeKJDKFe_kgiS1dIhPrE=.fea109a5-f78d-4d6f-9344-d8afd8d3ffa9@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
 <ZAwzDRCIo_TqIYbErunjdBZkeKJDKFe_kgiS1dIhPrE=.fea109a5-f78d-4d6f-9344-d8afd8d3ffa9@github.com>
Message-ID: <rBzztCMKZC2_0XDZFEGwpZBja3nZqwzSuUEnMZ9qbpk=.89aa9495-3f30-4404-a0df-796ad2253700@github.com>

On Mon, 1 Dec 2025 18:27:34 GMT, Chen Liang <liach at openjdk.org> 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:
> 
>   bracket styles

I had a look at the document you wrote, but I think it still needs some work. I suggest maybe splitting that out into a separate PR.

src/java.base/share/classes/jdk/internal/vm/annotation/constant-folding.md line 12:

> 10: 
> 11: Constant folding means a read of a variable of a constant value can be replaced
> 12: by the read constant value, during the construction of an IR graph.  The

I think think constant folding encompasses much more than just field loads. E.g. folding `3 + 4` into `7` is also constant folding. More abstractly, I'd say that constant folding is essentially running a computation at compile time. The JIT compiler tries to do some of the computations in the code that it is compiling at compile time, so that they don't have to be done over and over when the compiled code is ran.

We can think of instance field loads as a computation that takes in an instance of an object, and returns the value of one of the fields. If the _input_ is a constant, it is that _computation_ that may be folded, and the _result_ of that computation is then also a constant. To do that fold, the JIT essentially has to determine if the computation will always return the same result when evaluated.

Another important condition for folding field loads is that the input to that computation is always the same: namely the instance from which the field is loaded. Even if a field is a trusted final, if the instance from which that field is loaded may vary, the JIT will not treat the value of that field as 'constant'. I don't think it's necessarily wrong to say that a field 'is constant', but that doesn't guarantee that the JIT is able to constant fold loads from that field.

I think the word 'constant' is a bit too vague on its own, and used to mean several different things. I detect some tension when reading the rest of this doc, where you say for instance 'may be constant', rather than the more decisive 'is constant'. For instance, a 'constant' is just a fixed value (such as '3'), but a 'constant field' is a field that can not be changed, and a load from a 'constant field' is not guaranteed to produce a (JIT) compile time 'constant'. I think you need to clearly define 'constant' earlier in the document, and potentially use different terms for these examples.

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

PR Review: https://git.openjdk.org/jdk/pull/28540#pullrequestreview-3553830433
PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2599952662

From bulasevich at openjdk.org  Mon Dec  8 20:32:07 2025
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Mon, 8 Dec 2025 20:32:07 GMT
Subject: RFR: 8371459: [REDO] AArch64: Use SHA3 GPR intrinsic where it's faster
Message-ID: <0UWmNJNS302Q51hnq3htCbHQ7wYT_yhQDkQyk5Y9_e8=.92d8ee56-c519-4699-87b8-8549666aee75@github.com>

This change revises a previous update to enable the SHA3 GPR intrinsic as an alternative to the SHA3 extension?based intrinsic on platforms where it performs better. In practice, it is enabled only on Apple and Qualcomm silicon. See the previous PR for measurement details: https://github.com/openjdk/jdk/pull/27726

Tests were updated accordingly: now UseSHA3Intrinsics can be enabled on AArch64 even without the SHA3 CPU capability.

The test TestUseSHA3IntrinsicsOptionOnSupportedCPU.java was also enabled on AMD as this platform supports the intrinsic.

TestUseSHA3IntrinsicsOptionOnSupportedCPU verifies that UseSHA3Intrinsics can only be enabled when UseSHA is enabled. This follows the behavior of other SHA options and the option description, see globals.hpp:

 product(bool, UseSHA3Intrinsics, false, DIAGNOSTIC,                       \
         "Use intrinsics for SHA3 crypto hash function. "                  \
         "Requires that UseSHA is enabled.")                               \

- the x86 implementation was updated to match this behavior.

I did not like the message _"Intrinsics for SHA3-224, SHA3-256, SHA3-384 and SHA3-512 crypto hash functions not available on this CPU"_ to be printed when the VM is started with `-XX:-UseSHA -XX:+UseSHA3Intrinsics`. Instead, it now prints _"UseSHA3Intrinsics requires that UseSHA is enabled"_ for this specific case, and the test was updated to check only for the presence of "warning:" in the output. I decided not to apply the same change for UseSHA1Intrinsics, UseSHA256Intrinsics, and UseSHA512Intrinsics on AArch64 and x86 to keep the modification minimal. Please let me know if you think these should be updated as well.

Testing on platforms
- AMD (machines with and without SHA3 CPU capability)
- AARCH (Apple CPU and Neoverse machines with and without SHA3 CPU capability)

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

Commit messages:
 - 8359256: AArch64: Use SHA3 GPR intrinsic where it's faster

Changes: https://git.openjdk.org/jdk/pull/28515/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28515&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371459
  Stats: 45 lines in 9 files changed: 21 ins; 6 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/28515.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28515/head:pull/28515

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

From liach at openjdk.org  Mon Dec  8 20:51:00 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 8 Dec 2025 20:51:00 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting [v4]
In-Reply-To: <rBzztCMKZC2_0XDZFEGwpZBja3nZqwzSuUEnMZ9qbpk=.89aa9495-3f30-4404-a0df-796ad2253700@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
 <ZAwzDRCIo_TqIYbErunjdBZkeKJDKFe_kgiS1dIhPrE=.fea109a5-f78d-4d6f-9344-d8afd8d3ffa9@github.com>
 <rBzztCMKZC2_0XDZFEGwpZBja3nZqwzSuUEnMZ9qbpk=.89aa9495-3f30-4404-a0df-796ad2253700@github.com>
Message-ID: <tru60I3zX9tu4atEvUJNFYKtMxkOoflfw07tT0uuc04=.41d22959-2f78-49b6-9713-93fa5a421fd8@github.com>

On Mon, 8 Dec 2025 20:00:20 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   bracket styles
>
> src/java.base/share/classes/jdk/internal/vm/annotation/constant-folding.md line 12:
> 
>> 10: 
>> 11: Constant folding means a read of a variable of a constant value can be replaced
>> 12: by the read constant value, during the construction of an IR graph.  The
> 
> I think think constant folding encompasses much more than just field loads. E.g. folding `3 + 4` into `7` is also constant folding. More abstractly, I'd say that constant folding is essentially running a computation at compile time. The JIT compiler tries to do some of the computations in the code that it is compiling at compile time, so that they don't have to be done over and over when the compiled code is ran.
> 
> We can think of instance field loads as a computation that takes in an instance of an object, and returns the value of one of the fields. If the _input_ is a constant, it is that _computation_ that may be folded, and the _result_ of that computation is then also a constant. To do that fold, the JIT essentially has to determine if the computation will always return the same result when evaluated.
> 
> Another important condition for folding field loads is that the input to that computation is always the same: namely the instance from which the field is loaded. Even if a field is a trusted final, if the instance from which that field is loaded may vary, the JIT will not treat the value of that field as 'constant'. I don't think it's necessarily wrong to say that a field 'is constant', but that doesn't guarantee that the JIT is able to constant fold loads from that field.
> 
> I think the word 'constant' is a bit too vague on its own, and used to mean several different things. I detect some tension when reading the rest of this doc, where you say for instance 'may be constant', rather than the more decisive 'is constant'. For instance, a 'constant' is just a fixed value (such as '3'), but a 'constant field' is a field that can not be changed, and a load from a 'constant field' is not guaranteed to produce a (JIT) compile time 'constant'. I think you need to clearly define 'constant' earlier in the document, and potentially use different terms for these examples.

Sure, I have created https://bugs.openjdk.org/browse/JDK-8373286 to track that effort instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2600090805

From liach at openjdk.org  Mon Dec  8 21:14:24 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 8 Dec 2025 21:14:24 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting [v5]
In-Reply-To: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
Message-ID: <gw03b-wEe3BhmlRhHB8jKUCZnA4TPUeOksb8GsRfPFs=.084ff401-f46e-4694-a417-06cd5e39c838@github.com>

> 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 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:

 - Jorn review
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting
 - bracket styles
 - Doc tweaks
 - Essay
 - Spurious change
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting
 - Issue number and test update
 - Fixed optional and unit test
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting
 - ... and 1 more: https://git.openjdk.org/jdk/compare/383203c0...b20b7f5b

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28540/files
  - new: https://git.openjdk.org/jdk/pull/28540/files/d353bdbe..b20b7f5b

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

  Stats: 38514 lines in 729 files changed: 24382 ins; 11087 del; 3045 mod
  Patch: https://git.openjdk.org/jdk/pull/28540.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28540/head:pull/28540

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

From dlong at openjdk.org  Mon Dec  8 21:31:05 2025
From: dlong at openjdk.org (Dean Long)
Date: Mon, 8 Dec 2025 21:31:05 GMT
Subject: RFR: 8347396: Efficient TypeFunc creations [v3]
In-Reply-To: <da-a4Id_azWgrrTjDQEeYR6rm4D2l5jZAHIMx9x4v4w=.38b3a577-a776-49c4-8afb-27c684c126ad@github.com>
References: <VQs3SMtk1y6xTi8nCvTeWsTFfCQlTJtDdCGnfWQmRmw=.f3b33ba1-3efe-477b-b6d2-b43faae9ee2b@github.com>
 <da-a4Id_azWgrrTjDQEeYR6rm4D2l5jZAHIMx9x4v4w=.38b3a577-a776-49c4-8afb-27c684c126ad@github.com>
Message-ID: <DNTJP7vlsmB3HS_Ar2O8Gki22sbosxGem2N15mCA4r4=.02c534da-c67f-465b-a7f1-3a9104afc82f@github.com>

On Wed, 3 Dec 2025 08:37:02 GMT, Harshit470250 <duke at openjdk.org> 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 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?

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

PR Comment: https://git.openjdk.org/jdk/pull/27279#issuecomment-3629077478

From missa at openjdk.org  Mon Dec  8 21:47:16 2025
From: missa at openjdk.org (Mohamed Issa)
Date: Mon, 8 Dec 2025 21:47:16 GMT
Subject: RFR: 8368977: Provide clear naming for AVX10 identifiers [v2]
In-Reply-To: <6XYgqaHA0PPZzvnfysKOP5XGP7e_RMkVFt9PV2OT3Gk=.e5f33072-a91a-4e57-99f3-81cc4ae4d844@github.com>
References: <6XYgqaHA0PPZzvnfysKOP5XGP7e_RMkVFt9PV2OT3Gk=.e5f33072-a91a-4e57-99f3-81cc4ae4d844@github.com>
Message-ID: <JZnx2wYn7sTlojACH-CG8c77eMFJo_WxAMA2hEWlSGI=.0ed3a154-f3e9-4815-9039-4ab1629b5060@github.com>

> This is a simple change that renames all AVX10 identifiers to explicitly show which sub-versions are in use. Right now, AVX10.2 is the only case to worry about. The JTREG tests listed below were used to verify correctness with the recommended JVM options mentioned in corresponding source files. Each test included runs through emulation with AVX10.2 enabled and disabled to exercise all possible paths. All modifications and tests used [OpenJDK v26-b24](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B24) as the baseline build.
> 
> 1. `jtreg:test/hotspot/jtreg/compiler/codegen/TestByteDoubleVect.java`
> 2. `jtreg:test/hotspot/jtreg/compiler/codegen/TestByteFloatVect.java`
> 3. `jtreg:test/hotspot/jtreg/compiler/codegen/TestIntDoubleVect.java`
> 4. `jtreg:test/hotspot/jtreg/compiler/codegen/TestIntFloatVect.java`
> 5. `jtreg:test/hotspot/jtreg/compiler/codegen/TestLongDoubleVect.java`
> 6. `jtreg:test/hotspot/jtreg/compiler/codegen/TestLongFloatVect.java`
> 7. `jtreg:test/hotspot/jtreg/compiler/codegen/TestShortDoubleVect.java`
> 8. `jtreg:test/hotspot/jtreg/compiler/codegen/TestShortFloatVect.java`
> 9. `jtreg:test/hotspot/jtreg/compiler/floatingpoint/ScalarFPtoIntCastTest.java`
> 10. `jtreg:test/hotspot/jtreg/compiler/vectorapi/VectorFPtoIntCastTest.java`
> 11. `jtreg:test/hotspot/jtreg/compiler/vectorization/runner/ArrayTypeConvertTest.java`
> 12. `jtreg:test/jdk/jdk/incubator/vector/Double64VectorTests.java`
> 13. `jtreg:test/jdk/jdk/incubator/vector/Double128VectorTests.java`
> 14. `jtreg:test/jdk/jdk/incubator/vector/Double256VectorTests.java`
> 15. `jtreg:test/jdk/jdk/incubator/vector/Double512VectorTests.java`
> 16. `jtreg:test/jdk/jdk/incubator/vector/DoubleMaxVectorTests.java`
> 17. `jtreg:test/jdk/jdk/incubator/vector/Float64VectorTests.java`
> 18. `jtreg:test/jdk/jdk/incubator/vector/Float128VectorTests.java`
> 19. `jtreg:test/jdk/jdk/incubator/vector/Float256VectorTests.java`
> 20. `jtreg:test/jdk/jdk/incubator/vector/Float512VectorTests.java`
> 21. `jtreg:test/jdk/jdk/incubator/vector/FloatMaxVectorTests.java`
> 22. `jtreg:test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorOperations.java`
> 23. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java`

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

  Remove changes that affect functionality

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28344/files
  - new: https://git.openjdk.org/jdk/pull/28344/files/15701ac5..2a029dab

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

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

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

From missa at openjdk.org  Mon Dec  8 21:47:19 2025
From: missa at openjdk.org (Mohamed Issa)
Date: Mon, 8 Dec 2025 21:47:19 GMT
Subject: RFR: 8368977: Provide clear naming for AVX10 identifiers [v2]
In-Reply-To: <UCSx0eDSzdLOti5d3X378WTEQ1R1bu1I077ldLTXlng=.338efdd0-85fa-4fb6-9e51-2049d70537dc@github.com>
References: <6XYgqaHA0PPZzvnfysKOP5XGP7e_RMkVFt9PV2OT3Gk=.e5f33072-a91a-4e57-99f3-81cc4ae4d844@github.com>
 <UCSx0eDSzdLOti5d3X378WTEQ1R1bu1I077ldLTXlng=.338efdd0-85fa-4fb6-9e51-2049d70537dc@github.com>
Message-ID: <17XWWvgxG5LiMeaGTY_5N31bYTxK1qEuuNTypNGa7Uw=.9961c541-89cf-4a4f-9d82-ea078a98c51b@github.com>

On Mon, 8 Dec 2025 03:28:59 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove changes that affect functionality
>
> src/hotspot/cpu/x86/templateTable_x86.cpp line 1605:
> 
>> 1603:       __ jcc(Assembler::notEqual, L);
>> 1604:       __ call_VM_leaf(CAST_FROM_FN_PTR(address, SharedRuntime::f2i), 1);
>> 1605:     }
> 
> This change should be part of a seperate PR.

Sure, I'll cover this in another PR.

> src/hotspot/cpu/x86/templateTable_x86.cpp line 1620:
> 
>> 1618:       __ jcc(Assembler::notEqual, L);
>> 1619:       __ call_VM_leaf(CAST_FROM_FN_PTR(address, SharedRuntime::f2l), 1);
>> 1620:     }
> 
> Please restrict this PR to name change related changes only.

I reverted changes to this file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28344#discussion_r2600243093
PR Review Comment: https://git.openjdk.org/jdk/pull/28344#discussion_r2600244394

From kbarrett at openjdk.org  Mon Dec  8 23:53:06 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 8 Dec 2025 23:53:06 GMT
Subject: RFR: 8373207: Make DeferredStatic class template constant
 initializable
Message-ID: <4VAnkKHpiibKYwvnzxSWYQR2VT9XdP_m4qIk5tVR7Xg=.04ae29ba-3241-4810-a414-bcf168f40390@github.com>

Please review this change to `DeferredStatic` to meet the requirements for
constant initialization, to ensure dynamic initialization won't even be
considered a possibility.

Testing: mach5 tier1.

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

Commit messages:
 - constexpr ctor

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

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

From vlivanov at openjdk.org  Tue Dec  9 00:03:57 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 9 Dec 2025 00:03:57 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: <KFgDNk__y8ot5_XNPCAiii1KMYHs_8T4sBkHSFUnhNY=.511f4a3b-3e59-4af6-bfac-c94bc10485ba@github.com>

On Fri, 5 Dec 2025 09:44:16 GMT, Bhavana Kilambi <bkilambi at openjdk.org> 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            ...

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?

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

PR Comment: https://git.openjdk.org/jdk/pull/28675#issuecomment-3629564612

From duke at openjdk.org  Tue Dec  9 01:18:10 2025
From: duke at openjdk.org (duke)
Date: Tue, 9 Dec 2025 01:18:10 GMT
Subject: Withdrawn: 8369442: ExitOnOutOfMemoryError should exit more gracefully
In-Reply-To: <jmDCleeQhVqoqZP3h6o4tKHn7VthljAD_wmZX93KCb4=.88ff8222-aea4-402c-9261-22e43b414f09@github.com>
References: <jmDCleeQhVqoqZP3h6o4tKHn7VthljAD_wmZX93KCb4=.88ff8222-aea4-402c-9261-22e43b414f09@github.com>
Message-ID: <r0QdqVENUjG8OtOCR8KSyZfc-CNKmFSy5kSBfL5NFH8=.37977cff-31dd-46a2-b584-c36be5384949@github.com>

On Thu, 9 Oct 2025 08:35:50 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See RFE for more discussion. It seems we have a leeway in defining what "exit" means for `-XX:+ExitOnOutOfMemoryError`, and this PR does it more akin to `JVM_Halt`, rather than abrupt `os::_exit`. This gives VM a chance to shutdown some of its subsystems gracefully.
> 
> Comments welcome!
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `tier1`
>  - [ ] Linux x86_64 server fastdebug, `all`

This pull request has been closed without being integrated.

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

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

From liach at openjdk.org  Tue Dec  9 01:31:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 9 Dec 2025 01:31:46 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs [v5]
In-Reply-To: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
Message-ID: <2QctOO9M2yu2_4OimyQAAcqcgK9MEfR-K99SsLl5Hno=.af6a8636-020e-4a7a-8cf2-263b966164cd@github.com>

> Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value).
> 
> This is a necessary prerequisite for https://bugs.openjdk.org/browse/JDK-8233268, which proposes enhanced null messages to `Objects::requireNonNull`.

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 18 additional commits since the last revision:

 - Update, review
 - Merge branch 'master' of https://github.com/openjdk/jdk into exp/requireNonNull-message-hacks
 - Merge branch 'master' of https://github.com/openjdk/jdk into exp/requireNonNull-message-hacks
 - Update NPE per roger review
 - Use c++ enum classes per jdksjolen
 - Merge branch 'exp/requireNonNull-message-hacks' of github.com:liachmodded/jdk into exp/requireNonNull-message-hacks
 - Web review
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
 - Merge branch 'master' of https://github.com/openjdk/jdk into exp/requireNonNull-message-hacks
 - Years
 - Roll back Objects.rNN for now
 - ... and 8 more: https://git.openjdk.org/jdk/compare/5fccdccb...2dafe83a

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26600/files
  - new: https://git.openjdk.org/jdk/pull/26600/files/4ba1f17c..2dafe83a

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

  Stats: 636041 lines in 7152 files changed: 435596 ins; 128248 del; 72197 mod
  Patch: https://git.openjdk.org/jdk/pull/26600.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26600/head:pull/26600

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

From jvernee at openjdk.org  Tue Dec  9 01:55:03 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 9 Dec 2025 01:55:03 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v9]
In-Reply-To: <4YumBpbA2k8DC13H1s808_5OJx-1FMxD9CbIUfRTb8Q=.742f90c9-0d93-43b7-abe7-76422a0c8359@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <4YumBpbA2k8DC13H1s808_5OJx-1FMxD9CbIUfRTb8Q=.742f90c9-0d93-43b7-abe7-76422a0c8359@github.com>
Message-ID: <IYPm0LdHZSWih7wNOxX8HwoG_TTQc9eZ4r3cxBUBYRE=.4b9b1732-0f2f-4e03-b527-9abb15c02c68@github.com>

On Mon, 8 Dec 2025 19:10:48 GMT, Chen Liang <liach at openjdk.org> 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 17 additional commits since the last revision:
> 
>  - 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
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache
>  - Revert void special case removal due to C2 shortage causing TestZGCBarrierElision::testAtomicThenAtomicAnotherField failure
>  - Test from Jorn
>  - Copyright years
>  - Fix problem identified by Jorn
>  - Rollback getAndAdd for now
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/b009bdb3...d734e8a6

Marked as reviewed by jvernee (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28585#pullrequestreview-3554899910

From asmehra at openjdk.org  Tue Dec  9 02:16:11 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Tue, 9 Dec 2025 02:16:11 GMT
Subject: RFR: 8373114: Redundant MethodCounters in the preimage generated
 by training run [v2]
In-Reply-To: <LRw06Cn_4dcRW8YyFVr3RijMHIha7nPzBrcNNzaIny8=.dc07d0ee-b797-4434-aad0-956a00c2ea6f@github.com>
References: <LRw06Cn_4dcRW8YyFVr3RijMHIha7nPzBrcNNzaIny8=.dc07d0ee-b797-4434-aad0-956a00c2ea6f@github.com>
Message-ID: <OSv1Smz_pkBiU7bXuzTOTIKkMug1zITyptuLPXDCfmA=.26ac46ce-0991-48be-a845-dc86b3ccde60@github.com>

> 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 two additional commits since the last revision:

 - Update fix
   
   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
 - Update
   
   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28670/files
  - new: https://git.openjdk.org/jdk/pull/28670/files/f741349f..b6bbd8c8

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

  Stats: 29 lines in 6 files changed: 26 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/28670.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28670/head:pull/28670

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

From asmehra at openjdk.org  Tue Dec  9 02:39:41 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Tue, 9 Dec 2025 02:39:41 GMT
Subject: RFR: 8373114: Redundant MethodCounters in the preimage generated
 by training run [v3]
In-Reply-To: <LRw06Cn_4dcRW8YyFVr3RijMHIha7nPzBrcNNzaIny8=.dc07d0ee-b797-4434-aad0-956a00c2ea6f@github.com>
References: <LRw06Cn_4dcRW8YyFVr3RijMHIha7nPzBrcNNzaIny8=.dc07d0ee-b797-4434-aad0-956a00c2ea6f@github.com>
Message-ID: <Ftzehw6uU22VX960CToHi7NxdC8d5OR5Nd_emv7hSjQ=.9c31a575-0e6b-4e01-a454-d7e6c172a034@github.com>

> 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 <asmehra at redhat.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28670/files
  - new: https://git.openjdk.org/jdk/pull/28670/files/b6bbd8c8..9bbb4789

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

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

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

From asmehra at openjdk.org  Tue Dec  9 02:39:42 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Tue, 9 Dec 2025 02:39:42 GMT
Subject: RFR: 8373114: Redundant MethodCounters in the preimage generated
 by training run [v2]
In-Reply-To: <OSv1Smz_pkBiU7bXuzTOTIKkMug1zITyptuLPXDCfmA=.26ac46ce-0991-48be-a845-dc86b3ccde60@github.com>
References: <LRw06Cn_4dcRW8YyFVr3RijMHIha7nPzBrcNNzaIny8=.dc07d0ee-b797-4434-aad0-956a00c2ea6f@github.com>
 <OSv1Smz_pkBiU7bXuzTOTIKkMug1zITyptuLPXDCfmA=.26ac46ce-0991-48be-a845-dc86b3ccde60@github.com>
Message-ID: <YebtWBu7SiOoPufA0CSEP1llirgcQ8Zp2vfps4vY0uI=.bb6d5f29-b5cf-4657-bb72-d8d65a0ea034@github.com>

On Tue, 9 Dec 2025 02:16:11 GMT, Ashutosh Mehra <asmehra at openjdk.org> 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 two additional commits since the last revision:
> 
>  - Update fix
>    
>    Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>  - Update
>    
>    Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

Okay, I updated the fix. Idea is the same as before - add MethodCounters reachable from MethodTrainingData, not from Method. But the new fix relies on updating `ArchiveBuilder::get_follow_mode` to add the filter instead of changing Metadata traversal. The filter relies on the assumption that only the MethodCounters that are associated with MethodTrainingData need to be stored in the AOT cache. 
This additional filtering was not enough as I noticed number of MCS were still more than number of MTD. This is because some new MCS are created during the assembly phase and they get linked to the existing MTD. This situation was fixed by updating `MethodTrainingData::make()` to avoid doing any lookup in the assembly phase when the JVM is outside AOT safepoint. This makes sense because we shouldn't be using training data for compilations that happen outside of AOT safe point in the assembly phase.

Another approach I thought of was to add the filtering in `ArchiveBuilder::get_follow_mode` such that only the  MethodCounters referenced by MTDs are stored in the AOTCache. It is possible to get the enclosing MetaspaceObj but not I couldn't find an easy way to get the type of the enclosing object.

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

PR Comment: https://git.openjdk.org/jdk/pull/28670#issuecomment-3629940217

From iveresov at openjdk.org  Tue Dec  9 03:48:58 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Tue, 9 Dec 2025 03:48:58 GMT
Subject: RFR: 8373114: Redundant MethodCounters in the preimage generated
 by training run [v3]
In-Reply-To: <Ftzehw6uU22VX960CToHi7NxdC8d5OR5Nd_emv7hSjQ=.9c31a575-0e6b-4e01-a454-d7e6c172a034@github.com>
References: <LRw06Cn_4dcRW8YyFVr3RijMHIha7nPzBrcNNzaIny8=.dc07d0ee-b797-4434-aad0-956a00c2ea6f@github.com>
 <Ftzehw6uU22VX960CToHi7NxdC8d5OR5Nd_emv7hSjQ=.9c31a575-0e6b-4e01-a454-d7e6c172a034@github.com>
Message-ID: <IymFfzHan2FTWWQlRUSpf2L_2bwRK1B33q9wChDfiiQ=.50708e32-c7b2-46f5-9392-c0c0ce7ffc0c@github.com>

On Tue, 9 Dec 2025 02:39:41 GMT, Ashutosh Mehra <asmehra at openjdk.org> 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 <asmehra at redhat.com>

What's the percentage of the memory usage in the archive do you typically see attributed to MCs?

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

PR Comment: https://git.openjdk.org/jdk/pull/28670#issuecomment-3630120301

From jsjolen at openjdk.org  Tue Dec  9 07:40:57 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 9 Dec 2025 07:40:57 GMT
Subject: RFR: 8373207: Make DeferredStatic class template constant
 initializable
In-Reply-To: <4VAnkKHpiibKYwvnzxSWYQR2VT9XdP_m4qIk5tVR7Xg=.04ae29ba-3241-4810-a414-bcf168f40390@github.com>
References: <4VAnkKHpiibKYwvnzxSWYQR2VT9XdP_m4qIk5tVR7Xg=.04ae29ba-3241-4810-a414-bcf168f40390@github.com>
Message-ID: <0UfGYjmS3u-Z2f_0RvQXRw_THPJEwVq6_0FAm5eWrqs=.94aec517-568a-4c05-a1a7-83ffe8f082f5@github.com>

On Mon, 8 Dec 2025 23:45:58 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to `DeferredStatic` to meet the requirements for
> constant initialization, to ensure dynamic initialization won't even be
> considered a possibility.
> 
> Testing: mach5 tier1.

Marked as reviewed by jsjolen (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28710#pullrequestreview-3555920336

From epeter at openjdk.org  Tue Dec  9 07:57:06 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 9 Dec 2025 07:57:06 GMT
Subject: RFR: 8354282: C2: more crashes in compiled code because of
 dependency on removed range check CastIIs [v8]
In-Reply-To: <2xxjKX6hMeKDfS9SGBEvll8yadDthCoUjCIRpaE8ObA=.b567ec00-7dad-4b57-82a4-db1149fc8942@github.com>
References: <qos-VYvgreqGsB7ke35RmM3L9uHnnM6nUsm2QONKXc4=.9c902d61-5f45-41f5-8276-ac28830c2bf5@github.com>
 <qab0P8PMsV9UzIT8JqUuAixFJbzNkpjd_FCSDnVB49U=.f52c826c-480f-4330-ba68-01b22f21b044@github.com>
 <2xxjKX6hMeKDfS9SGBEvll8yadDthCoUjCIRpaE8ObA=.b567ec00-7dad-4b57-82a4-db1149fc8942@github.com>
Message-ID: <YioP6iNBxqCcL5wwbDvn0OeJKgDyaL_t-PxvhS0NueI=.460a1c92-a5e2-43ff-bc03-224d8aa922f3@github.com>

On Tue, 2 Dec 2025 13:52:04 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
>> 
>>  - Merge branch 'master' into JDK-8354282
>>  - whitespace
>>  - review
>>  - review
>>  - Update src/hotspot/share/opto/castnode.cpp
>>    
>>    Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>>  - Update src/hotspot/share/opto/castnode.cpp
>>    
>>    Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>>  - Update src/hotspot/share/opto/castnode.cpp
>>    
>>    Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>>  - Update test/hotspot/jtreg/compiler/c2/irTests/TestPushAddThruCast.java
>>    
>>    Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>>  - review
>>  - review
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/ef5e744a...93b8b0c5
>
> Thanks for the update, it looks good to me! If @eme64 also agrees with the latest patch, we can submit some testing and then hopefully get it in right before the fork.

@chhagedorn I see that an internal IR test is failing - one that you added a while back. Could you have a look what may have gone wrong?

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

PR Comment: https://git.openjdk.org/jdk/pull/24575#issuecomment-3630859059

From jbhateja at openjdk.org  Tue Dec  9 08:30:14 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 9 Dec 2025 08:30:14 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v6]
In-Reply-To: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
Message-ID: <VAJhUqGSgwjChOnk92olPNL0IxBUJo5IdgpdWPZ7EBM=.5d730c53-51cf-49ea-b30a-eb8e260b674c@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.
> 
> <img width="1344" height="532" alt="image" src="https://github.com/user-attachments/assets/c8157c3c-22b0-4bc1-9de9-7a68cadb7b2a" />
> 
> Initial RFP[1] was floated on the panama-dev mailing list.
> 
> Kindly review the draft PR and share your feedback.
> 
> Best Regards,
> Jatin
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html

Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:

 - 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
 - Adding support for custom basic  type T_FLOAT16, passing BasicType lane types to inline expander entries
 - Cleaning up interface as per review suggestions
 - Some cleanups
 - Fix some JTREG failures
 - ... and 9 more: https://git.openjdk.org/jdk/compare/5f083aba...e830d855

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

Changes: https://git.openjdk.org/jdk/pull/28002/files
  Webrev: Webrev is not available because diff is too large
  Stats: 509573 lines in 231 files changed: 281304 ins; 226541 del; 1728 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 Dec  9 08:30:15 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 9 Dec 2025 08:30:15 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v5]
In-Reply-To: <noO_zbgz9xdFkKd0iRFBg-ucAo1Q2VsFV6gysdyVypg=.8dbfdf85-c7a0-4a47-8fbb-fd407c6d0fe3@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <Vqu9FE4SgvqWFWn0U9718IDFzJviLpKyRyfYc7qrrZ0=.04845f2a-e4f5-4bb5-8f8f-d6bb001ca9c3@github.com>
 <PDD86rpbT5E1O892-PSEzhUEX-z0hePJ2dmohhkhX7Q=.ac4846db-9c08-4241-a66f-2b70071f6668@github.com>
 <o-yNlHUJg47pk2nHJCWJSyJHOxRBff_zc8NeP7Sym4s=.eb5643e3-9d7e-43ff-a3b4-8dfa8d38d7fd@github.com>
 <noO_zbgz9xdFkKd0iRFBg-ucAo1Q2VsFV6gysdyVypg=.8dbfdf85-c7a0-4a47-8fbb-fd407c6d0fe3@github.com>
Message-ID: <C8jnZIttgoew84TwqmU58RtTmwq3hLUZMPx7a_qcL58=.0d5de984-2115-4fd2-a144-f06ed345da75@github.com>

On Mon, 8 Dec 2025 11:25:22 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

>> Yes: there could be auto-vectorization.
>> No: `i` is not reset, it keeps counting from where `i < SPECIES.loopBound(LEN)` fails, and handles the tail, right?
>> 
>> It could be good to run this test once with and once without auto vectorization, just to make sure the vectors you see are from the Vector API, and not auto vectorization.
>
> Thanks. I missed that `i` isn't being reinitialised/reset again. Do we even need the tail loop in this case when the `LEN = 2048`? We may not even have any tail iterations?

@Bhavana-Kilambi vectorDim is a parameterizable parameter.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2601582561

From stefank at openjdk.org  Tue Dec  9 10:02:27 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 9 Dec 2025 10:02:27 GMT
Subject: [jdk26] RFR: 8370198: Test gc/arguments/TestShrinkHeapInSteps.java
 crashed:  assert(left >= right) failed: avoid underflow
In-Reply-To: <NeZODWztZjkhI8wnXNnxtuxvkxC-AGlTcxA-sezVSzU=.8aa91669-d535-43a9-80a6-28bd9fe3f2ab@github.com>
References: <NeZODWztZjkhI8wnXNnxtuxvkxC-AGlTcxA-sezVSzU=.8aa91669-d535-43a9-80a6-28bd9fe3f2ab@github.com>
Message-ID: <vV4cBAy_e85VS1o28YAy6vn2JQtumT5hs1TxApp52F8=.ead4c991-2565-4ace-84e2-2e451a8016b6@github.com>

On Mon, 8 Dec 2025 19:04:28 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> 8370198: Test gc/arguments/TestShrinkHeapInSteps.java crashed:  assert(left >= right) failed: avoid underflow

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28704#pullrequestreview-3556496393

From aph at openjdk.org  Tue Dec  9 10:03:46 2025
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 9 Dec 2025 10:03:46 GMT
Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() [v6]
In-Reply-To: <CEvEqPtlTMiv7fX1G_spyCpyl8afEZn4McrzIBd5GRY=.d233254e-3626-4044-a3e1-c82bcbd55e45@github.com>
References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com>
 <CEvEqPtlTMiv7fX1G_spyCpyl8afEZn4McrzIBd5GRY=.d233254e-3626-4044-a3e1-c82bcbd55e45@github.com>
Message-ID: <_dvuA-myjElGqbp-VHQMaRmFSoLZs_LzahI-9UedPL8=.42509430-4dde-43d9-8171-2d783cc9c550@github.com>

On Mon, 8 Dec 2025 14:01:48 GMT, Fei Gao <fgao at openjdk.org> 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/3c2e72cf...415495da

Yes, that looks good. It took some time, but it was worth it.

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

Marked as reviewed by aph (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26638#pullrequestreview-3556500520

From stefank at openjdk.org  Tue Dec  9 10:05:01 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 9 Dec 2025 10:05:01 GMT
Subject: RFR: 8373207: Make DeferredStatic class template constant
 initializable
In-Reply-To: <4VAnkKHpiibKYwvnzxSWYQR2VT9XdP_m4qIk5tVR7Xg=.04ae29ba-3241-4810-a414-bcf168f40390@github.com>
References: <4VAnkKHpiibKYwvnzxSWYQR2VT9XdP_m4qIk5tVR7Xg=.04ae29ba-3241-4810-a414-bcf168f40390@github.com>
Message-ID: <aCOm-K3J9yzlIRI2Hjpl1PtD1etBjMw5MvpMOZccJEU=.7b2eb61b-8990-4253-816f-684dcffc2f90@github.com>

On Mon, 8 Dec 2025 23:45:58 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to `DeferredStatic` to meet the requirements for
> constant initialization, to ensure dynamic initialization won't even be
> considered a possibility.
> 
> Testing: mach5 tier1.

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28710#pullrequestreview-3556506339

From cnorrbin at openjdk.org  Tue Dec  9 10:05:13 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Tue, 9 Dec 2025 10:05:13 GMT
Subject: RFR: 8367319: Add os interfaces to get machine and container
 values separately [v5]
In-Reply-To: <2sNRC-cjy5fk-s932GpEJXIHIlMPW1zukpL5nt7SlqI=.7c794055-2b91-4307-9fff-4b7e0fa5be60@github.com>
References: <gxXrAX2NGPyZnHuA4ttkfJ8MagiiELK-Wk700A2ZBgw=.00aaf9ab-976d-476a-ba4d-8a4063d96130@github.com>
 <lI_E9fdbu_ilitVsUyZBFZZ3M1D-Y4lC1UaLvpP1drU=.d28d0b3f-8112-4d76-8f14-edce2923f7bb@github.com>
 <Q5LOAsRhyY58X2jHFSRDKqyAKWFzWfcITJwuuk50D2o=.b7e3b0ef-6700-4ced-90fc-48126bf1db9f@github.com>
 <Zw1--idz925pWBSxndgs-bXyYxg_8MFgsJbceYchAdo=.4d17b893-44ef-4d8f-bcf7-b8cee90a9da6@github.com>
 <EdnWyzTqxqti6PdX52PDtVqha-nygYXheZab7R-q7y4=.7a937620-9af7-488e-ac37-be43f77750fb@github.com>
 <GEsqWomVqhCLXVtqyajBXpw2xkIdvbS5IVFPMBuGaTo=.a162aa48-ec1e-451a-8d72-e47ab6a1b433@github.com>
 <-fJmK2NEtYRIt_gO260itXoFE06wOgtn2is7EGZk4ek=.ab54f399-1c09-48c9-827d-fc2c9efad6e0@github.com>
 <2sNRC-cjy5fk-s932GpEJXIHIlMPW1zukpL5nt7SlqI=.7c794055-2b91-4307-9fff-4b7e0fa5be60@github.com>
Message-ID: <MAHyMDAEp981j0Y45uYosB_aOj86kulcq9idosBH7bk=.20b2b8bd-4be3-418e-9906-b7b08aa25aa1@github.com>

On Mon, 8 Dec 2025 05:53:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I think that should be guaranteed. This is our API we can make it as strict as we desire. If I have preset a sentinel value and the op fails then I should be able to rely on my sentinel remaining intact.

>From the feedback I've changed so returning `false` now doesn't change the value, so we keep that assumption.

> But now you are overloading the use of the return value. It was intended to reflect success or failure, not provide semantic information. The higher-level function can choose to return true when there is a limit and false when there is not, but it can't also mean "or an error occurred".

I'd argue that in this context, we fail (and should return `false`) when we can't find a limit. When a caller asks the generic `Container` layer for a limit and none is found, "no limit" isn't a meaningful limit to report. Not finding a limit is the failure here, not being unable to read a cgroup file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27646#discussion_r2601922557

From iwalulya at openjdk.org  Tue Dec  9 10:29:35 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Tue, 9 Dec 2025 10:29:35 GMT
Subject: RFR: 8373207: Make DeferredStatic class template constant
 initializable
In-Reply-To: <4VAnkKHpiibKYwvnzxSWYQR2VT9XdP_m4qIk5tVR7Xg=.04ae29ba-3241-4810-a414-bcf168f40390@github.com>
References: <4VAnkKHpiibKYwvnzxSWYQR2VT9XdP_m4qIk5tVR7Xg=.04ae29ba-3241-4810-a414-bcf168f40390@github.com>
Message-ID: <EwwJmfGPWB7pTNG0J8QwQuhiJlcrYybpL03-WGMe9SA=.2da39281-28f3-4d24-8346-cf607cf4e072@github.com>

On Mon, 8 Dec 2025 23:45:58 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to `DeferredStatic` to meet the requirements for
> constant initialization, to ensure dynamic initialization won't even be
> considered a possibility.
> 
> Testing: mach5 tier1.

Marked as reviewed by iwalulya (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28710#pullrequestreview-3556615546

From fgao at openjdk.org  Tue Dec  9 11:09:04 2025
From: fgao at openjdk.org (Fei Gao)
Date: Tue, 9 Dec 2025 11:09:04 GMT
Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() [v2]
In-Reply-To: <NPLsGrduyq6Fhus--wGRh8tOnbsowKm5gPHVdtL5mmg=.04048300-319a-4d1b-a1a7-109caf078ff8@github.com>
References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com>
 <NumjnPu4G4oJGGBCW6Q-nue3fl57GMeZCR1Whga6PiQ=.c4ebcd4d-e3c1-4bb9-9f46-5088dda819ac@github.com>
 <NPLsGrduyq6Fhus--wGRh8tOnbsowKm5gPHVdtL5mmg=.04048300-319a-4d1b-a1a7-109caf078ff8@github.com>
Message-ID: <PVsdSdDpB-MF3DT1B1vflfIHOH02jQ2-h3YfmzzIDPE=.07e7fec5-7be6-496a-b219-e0deb93d557a@github.com>

On Sun, 30 Nov 2025 17:08:22 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> 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 three additional commits since the last revision:
>> 
>>  - Patch 'isb' to 'nop'
>>  - Merge branch 'master' into reimplement-static-call-stub
>>  - 8363620: AArch64: reimplement emit_static_call_stub()
>>    
>>    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 bytes 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
>
> Your benchmark doesn't work. Please fix it.

@theRealAph Thanks for your review and for your time!

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

PR Comment: https://git.openjdk.org/jdk/pull/26638#issuecomment-3631651452

From duke at openjdk.org  Tue Dec  9 11:36:00 2025
From: duke at openjdk.org (ExE Boss)
Date: Tue, 9 Dec 2025 11:36:00 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v8]
In-Reply-To: <TnqE0J1VxzGZC177Lrtv8PM7HgXkA6cvJnfzkk4785c=.f35bbe36-e88a-4a01-9ecd-b7c8e4d9b8c1@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <C0kGO-Sn5AEvyTvnM3HWEVA30vjCsol9mwiTFzJItA0=.6d97913c-f521-4c43-97ec-edd718de55fc@github.com>
 <x-7pMREvH57ZMx31eV8YnUz4xfIFPIw73kkdh2w3ke4=.0b2377c3-8293-455d-9fa4-1812e8e6f763@github.com>
 <TnqE0J1VxzGZC177Lrtv8PM7HgXkA6cvJnfzkk4785c=.f35bbe36-e88a-4a01-9ecd-b7c8e4d9b8c1@github.com>
Message-ID: <vbMNwvwURTD0foFJDmvO0S8iB2DKLBgfN7JQpma35dw=.e6bfa39e-24e4-4bb2-a0d0-a23726146148@github.com>

On Mon, 8 Dec 2025 18:26:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/IndirectVarHandle.java line 114:
>> 
>>> 112:         // but checking the signature type of MH mostly works
>>> 113:         return MethodHandle.isReachableFrom(vform.getMethodType(0), cl)
>>> 114:                 && target.isReachableFrom(cl);
>> 
>> Right... one of the filters may also keep a class loader alive. But to check them, we'd have to eagerly instantiate all of them as well.
>> 
>> FWIW, I don't think this is an issue we can just ignore. If a filter keeps a class loader alive, we'd still have a problem.
>> 
>> Maybe it's possible to collect all the types involved from the filter when creating an IndirectVarHandle instead, and save those in a separate list for this check.
>
> I mean a filter method handle may keep other classes alive in addition to just its types. This is not possible from just checking the types. The vform method type is sufficient, because the types from the filter method type is always in one of the indirect layers.

Also, it?s?possible for?intermediate `MethodHandle`s used?as?part of?`MethodHandle` combinators to?refer to?types from?different class?loaders.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2602260725

From dholmes at openjdk.org  Tue Dec  9 12:02:03 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 9 Dec 2025 12:02:03 GMT
Subject: RFR: 8367319: Add os interfaces to get machine and container
 values separately [v5]
In-Reply-To: <MAHyMDAEp981j0Y45uYosB_aOj86kulcq9idosBH7bk=.20b2b8bd-4be3-418e-9906-b7b08aa25aa1@github.com>
References: <gxXrAX2NGPyZnHuA4ttkfJ8MagiiELK-Wk700A2ZBgw=.00aaf9ab-976d-476a-ba4d-8a4063d96130@github.com>
 <lI_E9fdbu_ilitVsUyZBFZZ3M1D-Y4lC1UaLvpP1drU=.d28d0b3f-8112-4d76-8f14-edce2923f7bb@github.com>
 <Q5LOAsRhyY58X2jHFSRDKqyAKWFzWfcITJwuuk50D2o=.b7e3b0ef-6700-4ced-90fc-48126bf1db9f@github.com>
 <Zw1--idz925pWBSxndgs-bXyYxg_8MFgsJbceYchAdo=.4d17b893-44ef-4d8f-bcf7-b8cee90a9da6@github.com>
 <EdnWyzTqxqti6PdX52PDtVqha-nygYXheZab7R-q7y4=.7a937620-9af7-488e-ac37-be43f77750fb@github.com>
 <GEsqWomVqhCLXVtqyajBXpw2xkIdvbS5IVFPMBuGaTo=.a162aa48-ec1e-451a-8d72-e47ab6a1b433@github.com>
 <-fJmK2NEtYRIt_gO260itXoFE06wOgtn2is7EGZk4ek=.ab54f399-1c09-48c9-827d-fc2c9efad6e0@github.com>
 <2sNRC-cjy5fk-s932GpEJXIHIlMPW1zukpL5nt7SlqI=.7c794055-2b91-4307-9fff-4b7e0fa5be60@github.com>
 <MAHyMDAEp981j0Y45uYosB_aOj86kulcq9idosBH7bk=.20b2b8bd-4be3-418e-9906-b7b08aa25aa1@github.com>
Message-ID: <IW9XhTNTCRo344GVTpTY4D-m00Iu0eEecHaiWEjAeZE=.fe94cabe-5c09-427d-b4a1-4ab477cfa714@github.com>

On Tue, 9 Dec 2025 10:01:50 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>>> However, if the function returns false, there is no guarantee that the out-parameter is untouched
>> 
>> I think that should be guaranteed. This is our API we can make it as strict as we desire. If I have preset a sentinel value and the op fails then I should be able to rely on my sentinel remaining intact.
>> 
>>> It doesn't make sense to return true if there is no limit
>> 
>> But now you are overloading the use of the return value. It was intended to reflect success or failure, not provide semantic information.  The higher-level function can choose to return true when there is a limit and false when there is not, but it can't also mean "or an error occurred".
>
>> I think that should be guaranteed. This is our API we can make it as strict as we desire. If I have preset a sentinel value and the op fails then I should be able to rely on my sentinel remaining intact.
> 
> From the feedback I've changed so returning `false` now doesn't change the value, so we keep that assumption.
> 
>> But now you are overloading the use of the return value. It was intended to reflect success or failure, not provide semantic information. The higher-level function can choose to return true when there is a limit and false when there is not, but it can't also mean "or an error occurred".
> 
> I'd argue that in this context, we fail (and should return `false`) when we can't find a limit. When a caller asks the generic `Container` layer for a limit and none is found, "no limit" isn't a meaningful limit to report. Not finding a limit is the failure here, not being unable to read a cgroup file.

The way you would respond to an actual failure to read a cgroup file would be completely different to how you respond to there being no limit. Defining a sentinel value to represent "no limit" would make perfect sense for this API in my opinion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27646#discussion_r2602342170

From chagedorn at openjdk.org  Tue Dec  9 14:10:55 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 9 Dec 2025 14:10:55 GMT
Subject: RFR: 8354282: C2: more crashes in compiled code because of
 dependency on removed range check CastIIs [v10]
In-Reply-To: <S0C_y4_BZ3l56hm9XGUtrcbFy9kOHfKnllKwXuqUkkg=.763f7645-c941-48b6-a54c-76b2a8b8d547@github.com>
References: <qos-VYvgreqGsB7ke35RmM3L9uHnnM6nUsm2QONKXc4=.9c902d61-5f45-41f5-8276-ac28830c2bf5@github.com>
 <S0C_y4_BZ3l56hm9XGUtrcbFy9kOHfKnllKwXuqUkkg=.763f7645-c941-48b6-a54c-76b2a8b8d547@github.com>
Message-ID: <Hv3RkhUSK9vUr_YsXoTu9ftBo-JqzYNizHITCv_y3P0=.e8d35ffb-24f5-4889-9cd0-486ec72229ca@github.com>

On Fri, 5 Dec 2025 14:05:06 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> This is a variant of 8332827. In 8332827, an array access becomes
>> dependent on a range check `CastII` for another array access. When,
>> after loop opts are over, that RC `CastII` was removed, the array
>> access could float and an out of bound access happened. With the fix
>> for 8332827, RC `CastII`s are no longer removed.
>> 
>> With this one what happens is that some transformations applied after
>> loop opts are over widen the type of the RC `CastII`. As a result, the
>> type of the RC `CastII` is no longer narrower than that of its input,
>> the `CastII` is removed and the dependency is lost.
>> 
>> There are 2 transformations that cause this to happen:
>> 
>> - after loop opts are over, the type of the `CastII` nodes are widen
>>   so nodes that have the same inputs but a slightly different type can
>>   common.
>>   
>> - When pushing a `CastII` through an `Add`, if of the type both inputs
>>   of the `Add`s are non constant, then we end up widening the type
>>   (the resulting `Add` has a type that's wider than that of the
>>   initial `CastII`).
>>   
>> There are already 3 types of `Cast` nodes depending on the
>> optimizations that are allowed. Either the `Cast` is floating
>> (`depends_only_test()` returns `true`) or pinned. Either the `Cast`
>> can be removed if it no longer narrows the type of its input or
>> not. We already have variants of the `CastII`:
>> 
>> - if the Cast can float and be removed when it doesn't narrow the type
>> of its input.
>> 
>> - if the Cast is pinned and be removed when it doesn't narrow the type
>> of its input.
>> 
>> - if the Cast is pinned and can't be removed when it doesn't narrow
>> the type of its input.
>> 
>> What we need here, I think, is the 4th combination:
>> 
>> - if the Cast can float and can't be removed when it doesn't narrow
>> the type of its input.
>> 
>> Anyway, things are becoming confusing with all these different
>> variants named in ways that don't always help figure out what
>> constraints one of them operate under. So I refactored this and that's
>> the biggest part of this change. The fix consists in marking `Cast`
>> nodes when their type is widen in a way that prevents them from being
>> optimized out.
>> 
>> Tobias ran performance testing with a slightly different version of
>> this change and there was no regression.
>
> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

I had a look and it seems that the internal test is relying on a `CastII` node to be removed after loop opts, when we widen `CastII` nodes, to trigger an ideal optimization. That is no longer the case with this patch because we keep the `CastII` node in the graph. The fix would be to improve the ideal optimization to look through cast nodes. However, this feels out of scope, especially since this PR is a bug fix for JDK 26.

I therefore propose to fix the internal test before integrating this PR and then follow up with an RFE to fix the ideal optimization. I can take care of this and let you know once this is done.

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

PR Comment: https://git.openjdk.org/jdk/pull/24575#issuecomment-3632449257

From liach at openjdk.org  Tue Dec  9 14:42:22 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 9 Dec 2025 14:42:22 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v8]
In-Reply-To: <vbMNwvwURTD0foFJDmvO0S8iB2DKLBgfN7JQpma35dw=.e6bfa39e-24e4-4bb2-a0d0-a23726146148@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <C0kGO-Sn5AEvyTvnM3HWEVA30vjCsol9mwiTFzJItA0=.6d97913c-f521-4c43-97ec-edd718de55fc@github.com>
 <x-7pMREvH57ZMx31eV8YnUz4xfIFPIw73kkdh2w3ke4=.0b2377c3-8293-455d-9fa4-1812e8e6f763@github.com>
 <TnqE0J1VxzGZC177Lrtv8PM7HgXkA6cvJnfzkk4785c=.f35bbe36-e88a-4a01-9ecd-b7c8e4d9b8c1@github.com>
 <vbMNwvwURTD0foFJDmvO0S8iB2DKLBgfN7JQpma35dw=.e6bfa39e-24e4-4bb2-a0d0-a23726146148@github.com>
Message-ID: <KgSWz6paWRbabiT2-0aXlosIwzR3GCFI2wTFwp-j2Jc=.30ad9792-896e-4ee1-a1c5-11627439f557@github.com>

On Tue, 9 Dec 2025 11:33:31 GMT, ExE Boss <duke at openjdk.org> wrote:

>> I mean a filter method handle may keep other classes alive in addition to just its types. This is not possible from just checking the types. The vform method type is sufficient, because the types from the filter method type is always in one of the indirect layers.
>
> Also, it?s?possible for?intermediate `MethodHandle`s used?as?part of?`MethodHandle` combinators to?refer to?types from?different class?loaders.

It is, but after all, there can be similar resource leak risks from calling LambdaMetafactory or other APIs too. We expect AccessDescriptor construction to be mostly limited to specific sites.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2602958025

From roland at openjdk.org  Tue Dec  9 15:03:07 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Tue, 9 Dec 2025 15:03:07 GMT
Subject: RFR: 8354282: C2: more crashes in compiled code because of
 dependency on removed range check CastIIs [v10]
In-Reply-To: <Hv3RkhUSK9vUr_YsXoTu9ftBo-JqzYNizHITCv_y3P0=.e8d35ffb-24f5-4889-9cd0-486ec72229ca@github.com>
References: <qos-VYvgreqGsB7ke35RmM3L9uHnnM6nUsm2QONKXc4=.9c902d61-5f45-41f5-8276-ac28830c2bf5@github.com>
 <S0C_y4_BZ3l56hm9XGUtrcbFy9kOHfKnllKwXuqUkkg=.763f7645-c941-48b6-a54c-76b2a8b8d547@github.com>
 <Hv3RkhUSK9vUr_YsXoTu9ftBo-JqzYNizHITCv_y3P0=.e8d35ffb-24f5-4889-9cd0-486ec72229ca@github.com>
Message-ID: <h4PUcH7W3bc1JdibHMfz32Dg1IaX88lMwMpmAe5yXYA=.79060d24-7747-4f02-b748-a666ce307544@github.com>

On Tue, 9 Dec 2025 14:07:22 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> I therefore propose to fix the internal test before integrating this PR and then follow up with an RFE to fix the ideal optimization. I can take care of this and let you know once this is done.

That sounds good to me. Should I take care of the ideal transformation? Let me know when the internal test is so I can proceed with the integration.

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

PR Comment: https://git.openjdk.org/jdk/pull/24575#issuecomment-3632713131

From lkorinth at openjdk.org  Tue Dec  9 15:04:11 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 9 Dec 2025 15:04:11 GMT
Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization
Message-ID: <BoAV8eR2EWmzvZHkuo_MLRoc8F-1uyxBKXobaFcxFz8=.4bbc7c56-2d86-4eb9-a0f1-3abe4ec74b07@github.com>

This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`.  Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads.

It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads.

This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253.

I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look.

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

Depends on: https://git.openjdk.org/jdk/pull/28719

Commit messages:
 - 8367993: G1: Speed up ConcurrentMark initialization

Changes: https://git.openjdk.org/jdk/pull/28723/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28723&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367993
  Stats: 97 lines in 10 files changed: 53 ins; 21 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/28723.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28723/head:pull/28723

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

From syan at openjdk.org  Tue Dec  9 15:05:38 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 9 Dec 2025 15:05:38 GMT
Subject: RFR: 8371948: TestStackOverflowDuringInit.java fails xss too small
 on linux-aarch64 [v2]
In-Reply-To: <P6KhJ0rZttqTHVxuVi_POYRVmy2oGpaUj03Gnz3LXOQ=.9449af19-abc3-44ad-99e9-6e70ce008e3c@github.com>
References: <P6KhJ0rZttqTHVxuVi_POYRVmy2oGpaUj03Gnz3LXOQ=.9449af19-abc3-44ad-99e9-6e70ce008e3c@github.com>
Message-ID: <ZVOO_DsBX2ns0XMURVfOyAk0Y2eUd0C68QdMa1Euywk=.9dacd56b-e382-4329-a67d-c5e17777e4ac@github.com>

> Hi all,
> 
> On linux-aarch64, when page size is 64K, the minimal java thread stack size is 448K. So this PR increase the minimal java thread stack size in test/hotspot/jtreg/runtime/ClassInitErrors/TestStackOverflowDuringInit.java. Below is the calculation formula for the minimal java thread stack size:
> 
> 
> page_size = 64K
> _java_thread_min_stack_allowed = 72K
> _stack_red_zone_size = align_up(StackRedPages * unit, page_size) = align_up(1*4K, 64K) = 64K
> _stack_yellow_zone_size = align_up(StackYellowPages * unit, page_size) = align_up(2*4K, 64K) = 64K
> _stack_reserved_zone_size = align_up(StackReservedPages * unit, page_size) = align_up(1*4K, 64K) = 64K
> _stack_shadow_zone_size = align_up(StackShadowPages * unit, page_size) = align_up(25*4K, 64K) = 128K
> _java_thread_min_stack_allowed = align_up(72K+64K+64K+64K+128K, 64K) = 448K
> 
> 
> This PR add whitebox API getMinimumJavaStackSize() to the the allowd minimum java stack size, and get the allowed minimum java stack size in test/hotspot/jtreg/runtime/ClassInitErrors/TestStackOverflowDuringInit.java
> 
> Change has been verified locally both on linux-x64 and linux-aarch64.

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

 - Make TestStackOverflowDuringInit.java start java sub-process after get wb.getMinimumJavaStackSize()
 - Make TestStackOverflowDuringInit.java start java sub-process after get wb.getMinimumJavaStackSize()
 - Add WhiteBox.getMinimumJavaStackSize() to get the minimum allowed java stack size
 - Merge branch 'openjdk:master' into jbs8371948
 - 8371948: TestStackOverflowDuringInit.java fails xss too small on linux-aarch64

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28352/files
  - new: https://git.openjdk.org/jdk/pull/28352/files/633f6a79..b3f4fa96

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

  Stats: 96082 lines in 1652 files changed: 63062 ins; 23095 del; 9925 mod
  Patch: https://git.openjdk.org/jdk/pull/28352.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28352/head:pull/28352

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

From chagedorn at openjdk.org  Tue Dec  9 15:27:11 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 9 Dec 2025 15:27:11 GMT
Subject: RFR: 8354282: C2: more crashes in compiled code because of
 dependency on removed range check CastIIs [v10]
In-Reply-To: <S0C_y4_BZ3l56hm9XGUtrcbFy9kOHfKnllKwXuqUkkg=.763f7645-c941-48b6-a54c-76b2a8b8d547@github.com>
References: <qos-VYvgreqGsB7ke35RmM3L9uHnnM6nUsm2QONKXc4=.9c902d61-5f45-41f5-8276-ac28830c2bf5@github.com>
 <S0C_y4_BZ3l56hm9XGUtrcbFy9kOHfKnllKwXuqUkkg=.763f7645-c941-48b6-a54c-76b2a8b8d547@github.com>
Message-ID: <gr34OEbHU-i8u9aNDr9jL2v8TWyTCVmc3gqE1EtgLi0=.47aee3e3-0579-4762-98a1-1cd8584b9f54@github.com>

On Fri, 5 Dec 2025 14:05:06 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> This is a variant of 8332827. In 8332827, an array access becomes
>> dependent on a range check `CastII` for another array access. When,
>> after loop opts are over, that RC `CastII` was removed, the array
>> access could float and an out of bound access happened. With the fix
>> for 8332827, RC `CastII`s are no longer removed.
>> 
>> With this one what happens is that some transformations applied after
>> loop opts are over widen the type of the RC `CastII`. As a result, the
>> type of the RC `CastII` is no longer narrower than that of its input,
>> the `CastII` is removed and the dependency is lost.
>> 
>> There are 2 transformations that cause this to happen:
>> 
>> - after loop opts are over, the type of the `CastII` nodes are widen
>>   so nodes that have the same inputs but a slightly different type can
>>   common.
>>   
>> - When pushing a `CastII` through an `Add`, if of the type both inputs
>>   of the `Add`s are non constant, then we end up widening the type
>>   (the resulting `Add` has a type that's wider than that of the
>>   initial `CastII`).
>>   
>> There are already 3 types of `Cast` nodes depending on the
>> optimizations that are allowed. Either the `Cast` is floating
>> (`depends_only_test()` returns `true`) or pinned. Either the `Cast`
>> can be removed if it no longer narrows the type of its input or
>> not. We already have variants of the `CastII`:
>> 
>> - if the Cast can float and be removed when it doesn't narrow the type
>> of its input.
>> 
>> - if the Cast is pinned and be removed when it doesn't narrow the type
>> of its input.
>> 
>> - if the Cast is pinned and can't be removed when it doesn't narrow
>> the type of its input.
>> 
>> What we need here, I think, is the 4th combination:
>> 
>> - if the Cast can float and can't be removed when it doesn't narrow
>> the type of its input.
>> 
>> Anyway, things are becoming confusing with all these different
>> variants named in ways that don't always help figure out what
>> constraints one of them operate under. So I refactored this and that's
>> the biggest part of this change. The fix consists in marking `Cast`
>> nodes when their type is widen in a way that prevents them from being
>> optimized out.
>> 
>> Tobias ran performance testing with a slightly different version of
>> this change and there was no regression.
>
> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Thanks Roland! I'll let you know and file a follow-up RFE and assign it to you. I will dump all the relevant information in there with a test case.

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

PR Comment: https://git.openjdk.org/jdk/pull/24575#issuecomment-3632843345

From asmehra at openjdk.org  Tue Dec  9 15:52:26 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Tue, 9 Dec 2025 15:52:26 GMT
Subject: RFR: 8373114: Redundant MethodCounters in the preimage generated
 by training run [v3]
In-Reply-To: <Ftzehw6uU22VX960CToHi7NxdC8d5OR5Nd_emv7hSjQ=.9c31a575-0e6b-4e01-a454-d7e6c172a034@github.com>
References: <LRw06Cn_4dcRW8YyFVr3RijMHIha7nPzBrcNNzaIny8=.dc07d0ee-b797-4434-aad0-956a00c2ea6f@github.com>
 <Ftzehw6uU22VX960CToHi7NxdC8d5OR5Nd_emv7hSjQ=.9c31a575-0e6b-4e01-a454-d7e6c172a034@github.com>
Message-ID: <8P1c3rNKSv1gQThHAJEeT2WjbzC-XBRvCyMBhaVPDTY=.ae1a780d-3ac0-4ac8-9059-9f38ebbdf1ec@github.com>

On Tue, 9 Dec 2025 02:39:41 GMT, Ashutosh Mehra <asmehra at openjdk.org> 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 <asmehra at redhat.com>

Before the patch with mainline:
In pre-image:

[19.021s][debug  ][aot         ]                         ro_cnt   ro_bytes     % |   rw_cnt   rw_bytes     % |  all_cnt  all_bytes     %
[19.021s][debug  ][aot         ] MethodCounters      :        0          0   0.0 |    22485    1439040   6.2 |    22485    1439040   2.6
[19.021s][debug  ][aot         ] MethodTrainingData  :        0          0   0.0 |     4998     519792   2.2 |     4998     519792   0.9

In final AOTCache:


[6.655s][debug][aot         ]                         ro_cnt   ro_bytes     % |   rw_cnt   rw_bytes     % |  all_cnt  all_bytes     %  
[6.655s][debug][aot         ] MethodCounters      :        0          0   0.0 |     8535     546240   2.5 |     8535     546240   1.0
[6.655s][debug][aot         ] MethodTrainingData  :        0          0   0.0 |     4998     519792   2.3 |     4998     519792   1.0


After the new fix, I see following stats:

In pre-image:

[12.397s][debug  ][aot         ]                         ro_cnt   ro_bytes     % |   rw_cnt   rw_bytes     % |  all_cnt  all_bytes     %
[12.397s][debug  ][aot         ] MethodCounters      :        0          0   0.0 |     5440     348160   1.6 |     5440     348160   0.6
[12.397s][debug  ][aot         ] MethodTrainingData  :        0          0   0.0 |     4985     518440   2.3 |     4985     518440   1.0


In final AOTCache:

[7.452s][debug][aot         ]                         ro_cnt   ro_bytes     % |   rw_cnt   rw_bytes     % |  all_cnt  all_bytes     %
[7.452s][debug][aot         ] MethodCounters      :        0          0   0.0 |     4942     316288   1.4 |     4942     316288   0.6
[7.452s][debug][aot         ] MethodTrainingData  :        0          0   0.0 |     4985     518440   2.3 |     4985     518440   1.0


So the size of MethodCounters is 2.6% (before fix) vs 0.6% (after fix) in the preimage, and 1% (before fix) vs 0.6% (after fix) in the AOTCache.

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

PR Comment: https://git.openjdk.org/jdk/pull/28670#issuecomment-3632961425

From eosterlund at openjdk.org  Tue Dec  9 16:53:26 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 9 Dec 2025 16:53:26 GMT
Subject: RFR: 8367319: Add os interfaces to get machine and container
 values separately [v5]
In-Reply-To: <IW9XhTNTCRo344GVTpTY4D-m00Iu0eEecHaiWEjAeZE=.fe94cabe-5c09-427d-b4a1-4ab477cfa714@github.com>
References: <gxXrAX2NGPyZnHuA4ttkfJ8MagiiELK-Wk700A2ZBgw=.00aaf9ab-976d-476a-ba4d-8a4063d96130@github.com>
 <lI_E9fdbu_ilitVsUyZBFZZ3M1D-Y4lC1UaLvpP1drU=.d28d0b3f-8112-4d76-8f14-edce2923f7bb@github.com>
 <Q5LOAsRhyY58X2jHFSRDKqyAKWFzWfcITJwuuk50D2o=.b7e3b0ef-6700-4ced-90fc-48126bf1db9f@github.com>
 <Zw1--idz925pWBSxndgs-bXyYxg_8MFgsJbceYchAdo=.4d17b893-44ef-4d8f-bcf7-b8cee90a9da6@github.com>
 <EdnWyzTqxqti6PdX52PDtVqha-nygYXheZab7R-q7y4=.7a937620-9af7-488e-ac37-be43f77750fb@github.com>
 <GEsqWomVqhCLXVtqyajBXpw2xkIdvbS5IVFPMBuGaTo=.a162aa48-ec1e-451a-8d72-e47ab6a1b433@github.com>
 <-fJmK2NEtYRIt_gO260itXoFE06wOgtn2is7EGZk4ek=.ab54f399-1c09-48c9-827d-fc2c9efad6e0@github.com>
 <2sNRC-cjy5fk-s932GpEJXIHIlMPW1zukpL5nt7SlqI=.7c794055-2b91-4307-9fff-4b7e0fa5be60@github.com>
 <MAHyMDAEp981j0Y45uYosB_aOj86kulcq9idosBH7bk=.20b2b8bd-4be3-418e-9906-b7b08aa25aa1@github.com>
 <IW9XhTNTCRo344GVTpTY4D-m00Iu0eEecHaiWEjAeZE=.fe94cabe-5c09-427d-b4a1-4ab477cfa714@github.com>
Message-ID: <oJWy5PKSvxS7WNvt3OkzRa4X42nt14S9MuYUzGxmmjY=.119ce16d-e840-48db-85da-0588c611f6af@github.com>

On Tue, 9 Dec 2025 11:59:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> I think that should be guaranteed. This is our API we can make it as strict as we desire. If I have preset a sentinel value and the op fails then I should be able to rely on my sentinel remaining intact.
>> 
>> From the feedback I've changed so returning `false` now doesn't change the value, so we keep that assumption.
>> 
>>> But now you are overloading the use of the return value. It was intended to reflect success or failure, not provide semantic information. The higher-level function can choose to return true when there is a limit and false when there is not, but it can't also mean "or an error occurred".
>> 
>> I'd argue that in this context, we fail (and should return `false`) when we can't find a limit. When a caller asks the generic `Container` layer for a limit and none is found, "no limit" isn't a meaningful limit to report. Not finding a limit is the failure here, not being unable to read a cgroup file.
>
> The way you would respond to an actual failure to read a cgroup file would be completely different to how you respond to there being no limit. Defining a sentinel value to represent "no limit" would make perfect sense for this API in my opinion.

As a user of this API, I don't see what I would do about there being an error reading a limit, vs reading that there is a limit which does not do any actual limiting. In both cases I act as if there is no container limit I can use and fall back to looking st machine limits. Maybe it's a lack of imagination, but I don't know what else I'm supposed to do.

If complaining in a log or something is the answer, then I'd prefer such complaints to be inside of the implementation instead of having the user do that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27646#discussion_r2603483788

From aph at openjdk.org  Tue Dec  9 17:09:43 2025
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 9 Dec 2025 17:09:43 GMT
Subject: RFR: 8372701: Randomized profile counters [v5]
In-Reply-To: <jKjmIONZcytzVjS4absOwOLv_QOF9qhIJifYhN6JyP4=.dceced94-bc29-43e6-9062-8dc77c2a6133@github.com>
References: <jKjmIONZcytzVjS4absOwOLv_QOF9qhIJifYhN6JyP4=.dceced94-bc29-43e6-9062-8dc77c2a6133@github.com>
Message-ID: <1nJnov3s2hhiLuO0W2FNcSAiGu5eEjZauQxfzd5YXKw=.8c593111-294a-4df7-8ce0-322871a801f3@github.com>

> 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 with a new target base due to a merge or a rebase. The pull request now contains 58 commits:

 - Merge from master branch
 - Merge remote-tracking branch 'refs/remotes/origin/JDK-8134940' into JDK-8134940
 - Fix x86 lambda
 - More
 - Merge branch 'master' into JDK-8134940
 - Merge branch 'master' into JDK-8134940
 - Merge remote-tracking branch 'refs/remotes/origin/JDK-8134940' into JDK-8134940
 - whitespace
 - AArch64
 - Minimize deltas to master
 - ... and 48 more: https://git.openjdk.org/jdk/compare/7da91533...96db42e2

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

Changes: https://git.openjdk.org/jdk/pull/28541/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28541&range=04
  Stats: 1150 lines in 26 files changed: 921 ins; 38 del; 191 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 aph at openjdk.org  Tue Dec  9 17:12:01 2025
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 9 Dec 2025 17:12:01 GMT
Subject: RFR: 8372701: Randomized profile counters [v4]
In-Reply-To: <p4A4eM1zSlD8mpvml8SwakhG3mIwWgf6yGbJYbnKBPo=.2c7dcc1b-956c-4063-bfb3-d7fb67cd0c8c@github.com>
References: <jKjmIONZcytzVjS4absOwOLv_QOF9qhIJifYhN6JyP4=.dceced94-bc29-43e6-9062-8dc77c2a6133@github.com>
 <CjfS8zXtvye99E6j5rz7U4mO7SLE5aU7u4U4vBW8b4Y=.2cb24d4b-c385-4d37-9ba2-bc96b804b975@github.com>
 <p4A4eM1zSlD8mpvml8SwakhG3mIwWgf6yGbJYbnKBPo=.2c7dcc1b-956c-4063-bfb3-d7fb67cd0c8c@github.com>
Message-ID: <DlRYHZsTcBy9eWQp-1orpxd6DuyOdkr8t6eZg9cvhz4=.abde2df9-5142-462d-9d75-426eea1359b4@github.com>

On Mon, 8 Dec 2025 08:42:59 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Ah, I think the problem is that there are merge conflicts with master. Could you please resolve them?

Done.

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

PR Comment: https://git.openjdk.org/jdk/pull/28541#issuecomment-3633336743

From chagedorn at openjdk.org  Tue Dec  9 17:59:20 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 9 Dec 2025 17:59:20 GMT
Subject: RFR: 8354282: C2: more crashes in compiled code because of
 dependency on removed range check CastIIs [v10]
In-Reply-To: <S0C_y4_BZ3l56hm9XGUtrcbFy9kOHfKnllKwXuqUkkg=.763f7645-c941-48b6-a54c-76b2a8b8d547@github.com>
References: <qos-VYvgreqGsB7ke35RmM3L9uHnnM6nUsm2QONKXc4=.9c902d61-5f45-41f5-8276-ac28830c2bf5@github.com>
 <S0C_y4_BZ3l56hm9XGUtrcbFy9kOHfKnllKwXuqUkkg=.763f7645-c941-48b6-a54c-76b2a8b8d547@github.com>
Message-ID: <7ZPdHr7IzEoj0yh45zEt-8ogQ8-2q435PPXieqqZKJU=.4366191f-729e-4e38-84f3-628f0d83cb33@github.com>

On Fri, 5 Dec 2025 14:05:06 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> This is a variant of 8332827. In 8332827, an array access becomes
>> dependent on a range check `CastII` for another array access. When,
>> after loop opts are over, that RC `CastII` was removed, the array
>> access could float and an out of bound access happened. With the fix
>> for 8332827, RC `CastII`s are no longer removed.
>> 
>> With this one what happens is that some transformations applied after
>> loop opts are over widen the type of the RC `CastII`. As a result, the
>> type of the RC `CastII` is no longer narrower than that of its input,
>> the `CastII` is removed and the dependency is lost.
>> 
>> There are 2 transformations that cause this to happen:
>> 
>> - after loop opts are over, the type of the `CastII` nodes are widen
>>   so nodes that have the same inputs but a slightly different type can
>>   common.
>>   
>> - When pushing a `CastII` through an `Add`, if of the type both inputs
>>   of the `Add`s are non constant, then we end up widening the type
>>   (the resulting `Add` has a type that's wider than that of the
>>   initial `CastII`).
>>   
>> There are already 3 types of `Cast` nodes depending on the
>> optimizations that are allowed. Either the `Cast` is floating
>> (`depends_only_test()` returns `true`) or pinned. Either the `Cast`
>> can be removed if it no longer narrows the type of its input or
>> not. We already have variants of the `CastII`:
>> 
>> - if the Cast can float and be removed when it doesn't narrow the type
>> of its input.
>> 
>> - if the Cast is pinned and be removed when it doesn't narrow the type
>> of its input.
>> 
>> - if the Cast is pinned and can't be removed when it doesn't narrow
>> the type of its input.
>> 
>> What we need here, I think, is the 4th combination:
>> 
>> - if the Cast can float and can't be removed when it doesn't narrow
>> the type of its input.
>> 
>> Anyway, things are becoming confusing with all these different
>> variants named in ways that don't always help figure out what
>> constraints one of them operate under. So I refactored this and that's
>> the biggest part of this change. The fix consists in marking `Cast`
>> nodes when their type is widen in a way that prevents them from being
>> optimized out.
>> 
>> Tobias ran performance testing with a slightly different version of
>> this change and there was no regression.
>
> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

The internal test is fixed and sanity testing passed - you can move forward with integrating this PR :-)

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

PR Comment: https://git.openjdk.org/jdk/pull/24575#issuecomment-3633535520

From thartmann at openjdk.org  Tue Dec  9 18:11:15 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 9 Dec 2025 18:11:15 GMT
Subject: [jdk26] RFR: 8373145: [BACKOUT] Remove
 ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch
Message-ID: <Eftv3Cv3DhVK9usfrrULxR_Ls0nJfB5dtozvtk2Tmgg=.ef96333a-1a03-4496-8411-c988a0dc1798@github.com>

Hi all,

This pull request contains a backport of commit [43787890](https://github.com/openjdk/jdk/commit/43787890291d71de61b28b8a4e3bf9aaba46757a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Albert Mingkun Yang on 5 Dec 2025 and was reviewed by Martin Doerr and Vladimir Kozlov.

Thanks!

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

Commit messages:
 - Backport 43787890291d71de61b28b8a4e3bf9aaba46757a

Changes: https://git.openjdk.org/jdk/pull/28728/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28728&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373145
  Stats: 69 lines in 7 files changed: 66 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/28728.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28728/head:pull/28728

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

From chagedorn at openjdk.org  Tue Dec  9 18:11:15 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 9 Dec 2025 18:11:15 GMT
Subject: [jdk26] RFR: 8373145: [BACKOUT] Remove
 ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch
In-Reply-To: <Eftv3Cv3DhVK9usfrrULxR_Ls0nJfB5dtozvtk2Tmgg=.ef96333a-1a03-4496-8411-c988a0dc1798@github.com>
References: <Eftv3Cv3DhVK9usfrrULxR_Ls0nJfB5dtozvtk2Tmgg=.ef96333a-1a03-4496-8411-c988a0dc1798@github.com>
Message-ID: <MYUMYwCvr5M000McErM7EB2oVPyXAJgoDGMfWA_s5LA=.53c5ab3b-3934-42a0-adda-4e6ff7d12fd8@github.com>

On Tue, 9 Dec 2025 17:54:33 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [43787890](https://github.com/openjdk/jdk/commit/43787890291d71de61b28b8a4e3bf9aaba46757a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Albert Mingkun Yang on 5 Dec 2025 and was reviewed by Martin Doerr and Vladimir Kozlov.
> 
> Thanks!

Looks good!

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

Marked as reviewed by chagedorn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28728#pullrequestreview-3558845542

From thartmann at openjdk.org  Tue Dec  9 18:14:08 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 9 Dec 2025 18:14:08 GMT
Subject: [jdk26] RFR: 8373145: [BACKOUT] Remove
 ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch
In-Reply-To: <Eftv3Cv3DhVK9usfrrULxR_Ls0nJfB5dtozvtk2Tmgg=.ef96333a-1a03-4496-8411-c988a0dc1798@github.com>
References: <Eftv3Cv3DhVK9usfrrULxR_Ls0nJfB5dtozvtk2Tmgg=.ef96333a-1a03-4496-8411-c988a0dc1798@github.com>
Message-ID: <O_vvAkgTs0slNJKua5L6UnOF5z_PlKUSNxegNS8AodQ=.8511daa1-0159-4f1b-9336-65bd4d9570d2@github.com>

On Tue, 9 Dec 2025 17:54:33 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [43787890](https://github.com/openjdk/jdk/commit/43787890291d71de61b28b8a4e3bf9aaba46757a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Albert Mingkun Yang on 5 Dec 2025 and was reviewed by Martin Doerr and Vladimir Kozlov.
> 
> Thanks!

Thanks Christian!

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

PR Comment: https://git.openjdk.org/jdk/pull/28728#issuecomment-3633593617

From ayang at openjdk.org  Tue Dec  9 18:27:23 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 9 Dec 2025 18:27:23 GMT
Subject: [jdk26] RFR: 8370198: Test gc/arguments/TestShrinkHeapInSteps.java
 crashed:  assert(left >= right) failed: avoid underflow
In-Reply-To: <NeZODWztZjkhI8wnXNnxtuxvkxC-AGlTcxA-sezVSzU=.8aa91669-d535-43a9-80a6-28bd9fe3f2ab@github.com>
References: <NeZODWztZjkhI8wnXNnxtuxvkxC-AGlTcxA-sezVSzU=.8aa91669-d535-43a9-80a6-28bd9fe3f2ab@github.com>
Message-ID: <E3k2R5-PKN-XJND81d9vcLfOcdf1sURYwJXUMsd5jog=.bd088718-20ed-49ac-865d-f588f46a937c@github.com>

On Mon, 8 Dec 2025 19:04:28 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> 8370198: Test gc/arguments/TestShrinkHeapInSteps.java crashed:  assert(left >= right) failed: avoid underflow

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/28704#issuecomment-3633641525

From ayang at openjdk.org  Tue Dec  9 18:27:24 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 9 Dec 2025 18:27:24 GMT
Subject: [jdk26] Integrated: 8370198: Test
 gc/arguments/TestShrinkHeapInSteps.java crashed:  assert(left >= right)
 failed: avoid underflow
In-Reply-To: <NeZODWztZjkhI8wnXNnxtuxvkxC-AGlTcxA-sezVSzU=.8aa91669-d535-43a9-80a6-28bd9fe3f2ab@github.com>
References: <NeZODWztZjkhI8wnXNnxtuxvkxC-AGlTcxA-sezVSzU=.8aa91669-d535-43a9-80a6-28bd9fe3f2ab@github.com>
Message-ID: <HZ5_NyZmN_8bLXM5wSkR0Alo08SMM3SFhacvHM49lIc=.b4a690b4-ae06-4c5c-b820-93193e203611@github.com>

On Mon, 8 Dec 2025 19:04:28 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> 8370198: Test gc/arguments/TestShrinkHeapInSteps.java crashed:  assert(left >= right) failed: avoid underflow

This pull request has now been integrated.

Changeset: 22fe7077
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/22fe70770acfb938dd95b361dbe8573abb1c84b1
Stats:     21 lines in 4 files changed: 19 ins; 2 del; 0 mod

8370198: Test gc/arguments/TestShrinkHeapInSteps.java crashed:  assert(left >= right) failed: avoid underflow

Reviewed-by: stefank
Backport-of: d34ef196c298aa91f8511714cfb04b15ae7fbf0a

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

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

From thartmann at openjdk.org  Tue Dec  9 18:40:27 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 9 Dec 2025 18:40:27 GMT
Subject: [jdk26] Integrated: 8373145: [BACKOUT] Remove
 ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch
In-Reply-To: <Eftv3Cv3DhVK9usfrrULxR_Ls0nJfB5dtozvtk2Tmgg=.ef96333a-1a03-4496-8411-c988a0dc1798@github.com>
References: <Eftv3Cv3DhVK9usfrrULxR_Ls0nJfB5dtozvtk2Tmgg=.ef96333a-1a03-4496-8411-c988a0dc1798@github.com>
Message-ID: <l602tdXGBu_ZZ_s033mQFnQXTr1KNQtzZYIqYD7dlRw=.e5523a1e-3ca1-42f8-9b29-c79ccda44d15@github.com>

On Tue, 9 Dec 2025 17:54:33 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [43787890](https://github.com/openjdk/jdk/commit/43787890291d71de61b28b8a4e3bf9aaba46757a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Albert Mingkun Yang on 5 Dec 2025 and was reviewed by Martin Doerr and Vladimir Kozlov.
> 
> Thanks!

This pull request has now been integrated.

Changeset: bf0bc379
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bf0bc37924b0c4f287d552253b63c06b9af5d5b5
Stats:     69 lines in 7 files changed: 66 ins; 0 del; 3 mod

8373145: [BACKOUT] Remove ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch

Reviewed-by: chagedorn
Backport-of: 43787890291d71de61b28b8a4e3bf9aaba46757a

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

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

From kbarrett at openjdk.org  Wed Dec 10 00:00:39 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 10 Dec 2025 00:00:39 GMT
Subject: RFR: 8373207: Make DeferredStatic class template constant
 initializable
In-Reply-To: <0UfGYjmS3u-Z2f_0RvQXRw_THPJEwVq6_0FAm5eWrqs=.94aec517-568a-4c05-a1a7-83ffe8f082f5@github.com>
References: <4VAnkKHpiibKYwvnzxSWYQR2VT9XdP_m4qIk5tVR7Xg=.04ae29ba-3241-4810-a414-bcf168f40390@github.com>
 <0UfGYjmS3u-Z2f_0RvQXRw_THPJEwVq6_0FAm5eWrqs=.94aec517-568a-4c05-a1a7-83ffe8f082f5@github.com>
Message-ID: <Li8OCjH9o9a-a-ylwlOOHcPcZAYGIsvGk5Qd5Vi7zUQ=.646912fe-b4c5-4806-a24c-6ec595dc5ea4@github.com>

On Tue, 9 Dec 2025 07:37:57 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Please review this change to `DeferredStatic` to meet the requirements for
>> constant initialization, to ensure dynamic initialization won't even be
>> considered a possibility.
>> 
>> Testing: mach5 tier1.
>
> Marked as reviewed by jsjolen (Reviewer).

Thanks for reviews @jdksjolen , @stefank , and @walulyai

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

PR Comment: https://git.openjdk.org/jdk/pull/28710#issuecomment-3634773173

From kbarrett at openjdk.org  Wed Dec 10 00:11:45 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 10 Dec 2025 00:11:45 GMT
Subject: Integrated: 8373207: Make DeferredStatic class template constant
 initializable
In-Reply-To: <4VAnkKHpiibKYwvnzxSWYQR2VT9XdP_m4qIk5tVR7Xg=.04ae29ba-3241-4810-a414-bcf168f40390@github.com>
References: <4VAnkKHpiibKYwvnzxSWYQR2VT9XdP_m4qIk5tVR7Xg=.04ae29ba-3241-4810-a414-bcf168f40390@github.com>
Message-ID: <2CAokf-Kg_AeK8UoVx9g6o15MohjskHK9qpF0d5uqmI=.3f24b919-02b0-42cd-aa4b-cf75fd1a804f@github.com>

On Mon, 8 Dec 2025 23:45:58 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to `DeferredStatic` to meet the requirements for
> constant initialization, to ensure dynamic initialization won't even be
> considered a possibility.
> 
> Testing: mach5 tier1.

This pull request has now been integrated.

Changeset: 7f9951a9
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7f9951a93479ac0ddd74375fdef92095fb65741b
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8373207: Make DeferredStatic class template constant initializable

Reviewed-by: jsjolen, stefank, iwalulya

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

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

From wenanjian at openjdk.org  Wed Dec 10 02:24:04 2025
From: wenanjian at openjdk.org (Anjian Wen)
Date: Wed, 10 Dec 2025 02:24:04 GMT
Subject: RFR: 8373069: RISC-V: implement GHASH intrinsic
Message-ID: <zxCNQIhhidoKzHbxL0z8h_Tp1N8pCmlHNoJ2wx30XF8=.a3d8eb05-9a07-403e-a014-84c3bb32b001@github.com>

support GHASH intrinsic for crypt GCM, which need zvkg extension. 

passed the tests in 
test/hotspot/jtreg/compiler/codegen/aes/
test/jdk/com/sun/crypto

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

Commit messages:
 - Add some flag
 - RISC-V: implement GHASH intrinsic

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

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

From syan at openjdk.org  Wed Dec 10 02:44:04 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 10 Dec 2025 02:44:04 GMT
Subject: RFR: 8371948: TestStackOverflowDuringInit.java fails xss too small
 on linux-aarch64 [v3]
In-Reply-To: <P6KhJ0rZttqTHVxuVi_POYRVmy2oGpaUj03Gnz3LXOQ=.9449af19-abc3-44ad-99e9-6e70ce008e3c@github.com>
References: <P6KhJ0rZttqTHVxuVi_POYRVmy2oGpaUj03Gnz3LXOQ=.9449af19-abc3-44ad-99e9-6e70ce008e3c@github.com>
Message-ID: <tTfhFUI4CtoZl5awF6ZjFuvWi7pqvsXzY7RnPVc_gmE=.aacf460c-f580-43e8-bc67-34aa2c228290@github.com>

> Hi all,
> 
> On linux-aarch64, when page size is 64K, the minimal java thread stack size is 448K. So this PR increase the minimal java thread stack size in test/hotspot/jtreg/runtime/ClassInitErrors/TestStackOverflowDuringInit.java. Below is the calculation formula for the minimal java thread stack size:
> 
> 
> page_size = 64K
> _java_thread_min_stack_allowed = 72K
> _stack_red_zone_size = align_up(StackRedPages * unit, page_size) = align_up(1*4K, 64K) = 64K
> _stack_yellow_zone_size = align_up(StackYellowPages * unit, page_size) = align_up(2*4K, 64K) = 64K
> _stack_reserved_zone_size = align_up(StackReservedPages * unit, page_size) = align_up(1*4K, 64K) = 64K
> _stack_shadow_zone_size = align_up(StackShadowPages * unit, page_size) = align_up(25*4K, 64K) = 128K
> _java_thread_min_stack_allowed = align_up(72K+64K+64K+64K+128K, 64K) = 448K
> 
> 
> This PR add whitebox API getMinimumJavaStackSize() to the the allowd minimum java stack size, and get the allowed minimum java stack size in test/hotspot/jtreg/runtime/ClassInitErrors/TestStackOverflowDuringInit.java
> 
> Change has been verified locally both on linux-x64 and linux-aarch64.

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

  Try to fix size_t->jint data loss compiler warning

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28352/files
  - new: https://git.openjdk.org/jdk/pull/28352/files/b3f4fa96..bad8596c

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

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

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

From syan at openjdk.org  Wed Dec 10 03:21:58 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 10 Dec 2025 03:21:58 GMT
Subject: RFR: 8371948: TestStackOverflowDuringInit.java fails xss too small
 on linux-aarch64 [v4]
In-Reply-To: <P6KhJ0rZttqTHVxuVi_POYRVmy2oGpaUj03Gnz3LXOQ=.9449af19-abc3-44ad-99e9-6e70ce008e3c@github.com>
References: <P6KhJ0rZttqTHVxuVi_POYRVmy2oGpaUj03Gnz3LXOQ=.9449af19-abc3-44ad-99e9-6e70ce008e3c@github.com>
Message-ID: <BWTwLbEacLAJd4lHyvIlwJSU_3H-8kYp7dbEMku5leA=.d8fcbea1-a8b8-449b-8f14-ccbbbd924291@github.com>

> Hi all,
> 
> On linux-aarch64, when page size is 64K, the minimal java thread stack size is 448K. So this PR increase the minimal java thread stack size in test/hotspot/jtreg/runtime/ClassInitErrors/TestStackOverflowDuringInit.java. Below is the calculation formula for the minimal java thread stack size:
> 
> 
> page_size = 64K
> _java_thread_min_stack_allowed = 72K
> _stack_red_zone_size = align_up(StackRedPages * unit, page_size) = align_up(1*4K, 64K) = 64K
> _stack_yellow_zone_size = align_up(StackYellowPages * unit, page_size) = align_up(2*4K, 64K) = 64K
> _stack_reserved_zone_size = align_up(StackReservedPages * unit, page_size) = align_up(1*4K, 64K) = 64K
> _stack_shadow_zone_size = align_up(StackShadowPages * unit, page_size) = align_up(25*4K, 64K) = 128K
> _java_thread_min_stack_allowed = align_up(72K+64K+64K+64K+128K, 64K) = 448K
> 
> 
> This PR add whitebox API getMinimumJavaStackSize() to the the allowd minimum java stack size, and get the allowed minimum java stack size in test/hotspot/jtreg/runtime/ClassInitErrors/TestStackOverflowDuringInit.java
> 
> Change has been verified locally both on linux-x64 and linux-aarch64.

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

  Use jlong instead of jint

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28352/files
  - new: https://git.openjdk.org/jdk/pull/28352/files/bad8596c..f45cc0cb

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

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

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

From iklam at openjdk.org  Wed Dec 10 06:38:26 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 10 Dec 2025 06:38:26 GMT
Subject: RFR: 8373114: Redundant MethodCounters in the preimage generated
 by training run [v2]
In-Reply-To: <YebtWBu7SiOoPufA0CSEP1llirgcQ8Zp2vfps4vY0uI=.bb6d5f29-b5cf-4657-bb72-d8d65a0ea034@github.com>
References: <LRw06Cn_4dcRW8YyFVr3RijMHIha7nPzBrcNNzaIny8=.dc07d0ee-b797-4434-aad0-956a00c2ea6f@github.com>
 <OSv1Smz_pkBiU7bXuzTOTIKkMug1zITyptuLPXDCfmA=.26ac46ce-0991-48be-a845-dc86b3ccde60@github.com>
 <YebtWBu7SiOoPufA0CSEP1llirgcQ8Zp2vfps4vY0uI=.bb6d5f29-b5cf-4657-bb72-d8d65a0ea034@github.com>
Message-ID: <a85ZuRDWytfJs9yTAzrKUGZ1OM9AJEU9VLbNoCehJyI=.11694df2-ab91-421c-9ba4-f354a75fb0e5@github.com>

On Tue, 9 Dec 2025 02:34:01 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

> Another approach I thought of was to add the filtering in `ArchiveBuilder::get_follow_mode` such that only the MethodCounters referenced by MTDs are stored in the AOTCache. It is possible to get the enclosing MetaspaceObj for the `MetaspaceClosure::Ref` passed to `get_follow_mode` but I couldn't find an easy way to get the type of the enclosing object, which makes it difficult to check if the MethodCounters being added came from Method or MTD.

Hi Ashutosh, I've created a patch for finding the type of the enclosing obj:

https://github.com/iklam/jdk/commit/cef9437484e119fde1b4eb07a809b33d83e35bdd

Could you try to see if that works for you?

Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/28670#issuecomment-3635611525

From dholmes at openjdk.org  Wed Dec 10 07:31:33 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 10 Dec 2025 07:31:33 GMT
Subject: RFR: 8367319: Add os interfaces to get machine and container
 values separately [v5]
In-Reply-To: <oJWy5PKSvxS7WNvt3OkzRa4X42nt14S9MuYUzGxmmjY=.119ce16d-e840-48db-85da-0588c611f6af@github.com>
References: <gxXrAX2NGPyZnHuA4ttkfJ8MagiiELK-Wk700A2ZBgw=.00aaf9ab-976d-476a-ba4d-8a4063d96130@github.com>
 <lI_E9fdbu_ilitVsUyZBFZZ3M1D-Y4lC1UaLvpP1drU=.d28d0b3f-8112-4d76-8f14-edce2923f7bb@github.com>
 <Q5LOAsRhyY58X2jHFSRDKqyAKWFzWfcITJwuuk50D2o=.b7e3b0ef-6700-4ced-90fc-48126bf1db9f@github.com>
 <Zw1--idz925pWBSxndgs-bXyYxg_8MFgsJbceYchAdo=.4d17b893-44ef-4d8f-bcf7-b8cee90a9da6@github.com>
 <EdnWyzTqxqti6PdX52PDtVqha-nygYXheZab7R-q7y4=.7a937620-9af7-488e-ac37-be43f77750fb@github.com>
 <GEsqWomVqhCLXVtqyajBXpw2xkIdvbS5IVFPMBuGaTo=.a162aa48-ec1e-451a-8d72-e47ab6a1b433@github.com>
 <-fJmK2NEtYRIt_gO260itXoFE06wOgtn2is7EGZk4ek=.ab54f399-1c09-48c9-827d-fc2c9efad6e0@github.com>
 <2sNRC-cjy5fk-s932GpEJXIHIlMPW1zukpL5nt7SlqI=.7c794055-2b91-4307-9fff-4b7e0fa5be60@github.com>
 <MAHyMDAEp981j0Y45uYosB_aOj86kulcq9idosBH7bk=.20b2b8bd-4be3-418e-9906-b7b08aa25aa1@github.com>
 <IW9XhTNTCRo344GVTpTY4D-m00Iu0eEecHaiWEjAeZE=.fe94cabe-5c09-427d-b4a1-4ab477cfa714@github.com>
 <oJWy5PKSvxS7WNvt3OkzRa4X42nt14S9MuY
 UzGxmmjY=.119ce16d-e840-48db-85da-0588c611f6af@github.com>
Message-ID: <p27SB8vgfzMtahbR1YpA3vdaU78lTtZCMIwfKsb1Z7o=.d7fa43b3-ac01-42de-ba69-61b4034398f1@github.com>

On Tue, 9 Dec 2025 16:50:08 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> The way you would respond to an actual failure to read a cgroup file would be completely different to how you respond to there being no limit. Defining a sentinel value to represent "no limit" would make perfect sense for this API in my opinion.
>
> As a user of this API, I don't see what I would do about there being an error reading a limit, vs reading that there is a limit which does not do any actual limiting. In both cases I act as if there is no container limit I can use and fall back to looking st machine limits. Maybe it's a lack of imagination, but I don't know what else I'm supposed to do.
> 
> If complaining in a log or something is the answer, then I'd prefer such complaints to be inside of the implementation instead of having the user do that.

Based on that you would not want errors to be reported at all. I was expecting at least logging on error or perhaps some kind of "abort" if the error signifies a fatal condition for what you are trying to do. Maybe errors are so unlikely that we really don't care? But I would not assume an error means there is no limit and proceed on that basis - YMMV.

But I will step aside from the discussion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27646#discussion_r2605509918

From epeter at openjdk.org  Wed Dec 10 07:38:33 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 10 Dec 2025 07:38:33 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v9]
In-Reply-To: <4YumBpbA2k8DC13H1s808_5OJx-1FMxD9CbIUfRTb8Q=.742f90c9-0d93-43b7-abe7-76422a0c8359@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <4YumBpbA2k8DC13H1s808_5OJx-1FMxD9CbIUfRTb8Q=.742f90c9-0d93-43b7-abe7-76422a0c8359@github.com>
Message-ID: <FcLav5WxQpzUXuUVVjqCnl44iRF8rDACYssSokT0zZE=.bec8fe32-2d9b-49c1-904a-044a9361e3d5@github.com>

On Mon, 8 Dec 2025 19:10:48 GMT, Chen Liang <liach at openjdk.org> 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 17 additional commits since the last revision:
> 
>  - 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
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache
>  - Revert void special case removal due to C2 shortage causing TestZGCBarrierElision::testAtomicThenAtomicAnotherField failure
>  - Test from Jorn
>  - Copyright years
>  - Fix problem identified by Jorn
>  - Rollback getAndAdd for now
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/edba0887...d734e8a6

Was asked on slack to review IR tests, so that's all I'm doing here - won't review the whole patch ;)

test/hotspot/jtreg/compiler/c2/irTests/constantFold/VarHandleMismatchedTypeFold.java line 2:

> 1: /*
> 2:  * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.

We want to eventually migrate all tests from `c2/irTests` to more "topic based" directories, so it would be great if you already migrated them now, since you probably would know a better name/place now already ;)

test/hotspot/jtreg/compiler/c2/irTests/constantFold/VarHandleMismatchedTypeFold.java line 41:

> 39:  * @summary Verify constant folding is possible for mismatched VarHandle access
> 40:  * @library /test/lib /
> 41:  * @requires vm.compiler2.enabled

What would happen if you removed this? Is the test expected to fail anywhere? IR rules are executed only if C2 is available anyway, so probably you don't need this restriction.

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

Changes requested by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28585#pullrequestreview-3561137086
PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2605521507
PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2605526968

From epeter at openjdk.org  Wed Dec 10 07:42:29 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 10 Dec 2025 07:42:29 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting [v5]
In-Reply-To: <gw03b-wEe3BhmlRhHB8jKUCZnA4TPUeOksb8GsRfPFs=.084ff401-f46e-4694-a417-06cd5e39c838@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
 <gw03b-wEe3BhmlRhHB8jKUCZnA4TPUeOksb8GsRfPFs=.084ff401-f46e-4694-a417-06cd5e39c838@github.com>
Message-ID: <QGoa6zG12OzZgrx0gZd39aww0y0fCbaHjf_NwnB4dtQ=.4a5e96b3-de70-40de-8e4d-557b3c5feaec@github.com>

On Mon, 8 Dec 2025 21:14:24 GMT, Chen Liang <liach at openjdk.org> 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 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:
> 
>  - Jorn review
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting
>  - bracket styles
>  - Doc tweaks
>  - Essay
>  - Spurious change
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting
>  - Issue number and test update
>  - Fixed optional and unit test
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/f4fe3397...b20b7f5b

Drive-by comments about IR test only ;)

test/hotspot/jtreg/compiler/c2/irTests/constantFold/TestOptional.java line 2:

> 1: /*
> 2:  * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.

We would like to move all tests away from `irTests`. It would be better to sort tests by topic, rather than by the method we test them.

test/hotspot/jtreg/compiler/c2/irTests/constantFold/TestOptional.java line 39:

> 37:  * @summary Verify constant folding for Optional
> 38:  * @library /test/lib /
> 39:  * @requires vm.compiler2.enabled

I doubt you actually need the C2 restriction here. IR tests could still run verification for results without C2. IR rules only run if C2 is available, otherwise the test can still pass, just no IR rules are run.

test/hotspot/jtreg/compiler/c2/irTests/constantFold/TestOptional.java line 40:

> 38:  * @library /test/lib /
> 39:  * @requires vm.compiler2.enabled
> 40:  * @run driver compiler.c2.irTests.constantFold.TestOptional

Suggestion:

 * @run driver ${test.main.class}

Since this is now possible, we should use this templated approach now, to avoid invoking the wrong test classes by accident.

-------------

Changes requested by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28540#pullrequestreview-3561154527
PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2605537189
PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2605543019
PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2605539633

From dholmes at openjdk.org  Wed Dec 10 07:52:31 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 10 Dec 2025 07:52:31 GMT
Subject: RFR: 8371948: TestStackOverflowDuringInit.java fails xss too small
 on linux-aarch64 [v4]
In-Reply-To: <BWTwLbEacLAJd4lHyvIlwJSU_3H-8kYp7dbEMku5leA=.d8fcbea1-a8b8-449b-8f14-ccbbbd924291@github.com>
References: <P6KhJ0rZttqTHVxuVi_POYRVmy2oGpaUj03Gnz3LXOQ=.9449af19-abc3-44ad-99e9-6e70ce008e3c@github.com>
 <BWTwLbEacLAJd4lHyvIlwJSU_3H-8kYp7dbEMku5leA=.d8fcbea1-a8b8-449b-8f14-ccbbbd924291@github.com>
Message-ID: <ThFvEVtNoDMmmkPDUg9eo3FHNRfkoi-CHNWon5Y3U6E=.b7ef3a2e-0dec-4f87-838e-90346ce7ddd4@github.com>

On Wed, 10 Dec 2025 03:21:58 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> On linux-aarch64, when page size is 64K, the minimal java thread stack size is 448K. So this PR increase the minimal java thread stack size in test/hotspot/jtreg/runtime/ClassInitErrors/TestStackOverflowDuringInit.java. Below is the calculation formula for the minimal java thread stack size:
>> 
>> 
>> page_size = 64K
>> _java_thread_min_stack_allowed = 72K
>> _stack_red_zone_size = align_up(StackRedPages * unit, page_size) = align_up(1*4K, 64K) = 64K
>> _stack_yellow_zone_size = align_up(StackYellowPages * unit, page_size) = align_up(2*4K, 64K) = 64K
>> _stack_reserved_zone_size = align_up(StackReservedPages * unit, page_size) = align_up(1*4K, 64K) = 64K
>> _stack_shadow_zone_size = align_up(StackShadowPages * unit, page_size) = align_up(25*4K, 64K) = 128K
>> _java_thread_min_stack_allowed = align_up(72K+64K+64K+64K+128K, 64K) = 448K
>> 
>> 
>> This PR add whitebox API getMinimumJavaStackSize() to the the allowd minimum java stack size, and get the allowed minimum java stack size in test/hotspot/jtreg/runtime/ClassInitErrors/TestStackOverflowDuringInit.java
>> 
>> Change has been verified locally both on linux-x64 and linux-aarch64.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use jlong instead of jint

Looking good. Just a couple of minor issues.

Thanks

src/hotspot/share/runtime/os.cpp line 2580:

> 2578: }
> 2579: 
> 2580: jlong os::get_minimum_java_stack_sizes() {

Suggestion:

jlong os::get_minimum_java_stack_size() {

src/hotspot/share/runtime/os.hpp line 394:

> 392:  public:
> 393:   // get allowed minimum java stack sizes
> 394:   static jlong get_minimum_java_stack_sizes();

Suggestion:

  // get allowed minimum java stack size
  static jlong get_minimum_java_stack_size();

test/hotspot/jtreg/runtime/memory/ReadMinimumJavaStackSize.java line 1:

> 1: /*

We don't need a test to exercise the WhiteBox API explicitly.

test/lib/jdk/test/whitebox/WhiteBox.java line 80:

> 78:   public native long getHeapSpaceAlignment();
> 79:   public native long getHeapAlignment();
> 80:   public native long  getMinimumJavaStackSize();

Suggestion:

  public native long getMinimumJavaStackSize();

-------------

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28352#pullrequestreview-3561172332
PR Review Comment: https://git.openjdk.org/jdk/pull/28352#discussion_r2605559716
PR Review Comment: https://git.openjdk.org/jdk/pull/28352#discussion_r2605552128
PR Review Comment: https://git.openjdk.org/jdk/pull/28352#discussion_r2605565863
PR Review Comment: https://git.openjdk.org/jdk/pull/28352#discussion_r2605566674

From roland at openjdk.org  Wed Dec 10 08:08:28 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Wed, 10 Dec 2025 08:08:28 GMT
Subject: RFR: 8354282: C2: more crashes in compiled code because of
 dependency on removed range check CastIIs [v10]
In-Reply-To: <7ZPdHr7IzEoj0yh45zEt-8ogQ8-2q435PPXieqqZKJU=.4366191f-729e-4e38-84f3-628f0d83cb33@github.com>
References: <qos-VYvgreqGsB7ke35RmM3L9uHnnM6nUsm2QONKXc4=.9c902d61-5f45-41f5-8276-ac28830c2bf5@github.com>
 <S0C_y4_BZ3l56hm9XGUtrcbFy9kOHfKnllKwXuqUkkg=.763f7645-c941-48b6-a54c-76b2a8b8d547@github.com>
 <7ZPdHr7IzEoj0yh45zEt-8ogQ8-2q435PPXieqqZKJU=.4366191f-729e-4e38-84f3-628f0d83cb33@github.com>
Message-ID: <OO-BqLIANnI6d3lMvxyDsWCspgFF2dEa7GMQnRKgIxc=.1886a1c8-9569-4419-bff3-17ddb08a1d8f@github.com>

On Tue, 9 Dec 2025 17:56:32 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review
>
> The internal test is fixed and sanity testing passed - you can move forward with integrating this PR :-)

@chhagedorn @eme64 @merykitty thanks for the reviews and testing

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24575#issuecomment-3635860312

From chagedorn at openjdk.org  Wed Dec 10 08:09:27 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 10 Dec 2025 08:09:27 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v9]
In-Reply-To: <4YumBpbA2k8DC13H1s808_5OJx-1FMxD9CbIUfRTb8Q=.742f90c9-0d93-43b7-abe7-76422a0c8359@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <4YumBpbA2k8DC13H1s808_5OJx-1FMxD9CbIUfRTb8Q=.742f90c9-0d93-43b7-abe7-76422a0c8359@github.com>
Message-ID: <7__4QGMz-5idIedYYk-0HrQnnMfTa4d-Gl75gvajV0A=.ecba821d-731d-420f-a3f6-9feeb869b20b@github.com>

On Mon, 8 Dec 2025 19:10:48 GMT, Chen Liang <liach at openjdk.org> 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 17 additional commits since the last revision:
> 
>  - 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
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache
>  - Revert void special case removal due to C2 shortage causing TestZGCBarrierElision::testAtomicThenAtomicAnotherField failure
>  - Test from Jorn
>  - Copyright years
>  - Fix problem identified by Jorn
>  - Rollback getAndAdd for now
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/45fb0e07...d734e8a6

test/hotspot/jtreg/compiler/c2/irTests/constantFold/VarHandleMismatchedTypeFold.java line 70:

> 68: 
> 69:     @Check(test = "testSum")
> 70:     public void runTestSum() {

Drive-by comment: From the method name, it seems that you want to have a runner method. For that, you need to switch to `@Run`. But you can also do result verification with `@Check`. In the latter case, you do not need to call `testSum()` again but you can just add a `long result` as parameter. The IR framework will then call this `@Check` method with the result of `testSum()`.

Example:
https://github.com/openjdk/jdk/blob/1bbbce75c5e68429c2a32519eb3c36d964dcdf57/test/hotspot/jtreg/testlibrary_tests/ir_framework/examples/CheckedTestExample.java#L94-L102

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2605606400

From shade at openjdk.org  Wed Dec 10 08:33:30 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 10 Dec 2025 08:33:30 GMT
Subject: RFR: 8357258: x86: Improve receiver type profiling reliability
 [v9]
In-Reply-To: <X9RJoDWqk67MlK7P4ACCbzROxLkfEqvU0zDid3zymnc=.7c0086a3-f514-4b0d-8bc0-592bf4a05bba@github.com>
References: <X9RJoDWqk67MlK7P4ACCbzROxLkfEqvU0zDid3zymnc=.7c0086a3-f514-4b0d-8bc0-592bf4a05bba@github.com>
Message-ID: <8N5F01Ve6BLQjlsJ7nD53xn70wa_NrRMqeuSb1Grp6M=.f45dd3b4-b282-41a8-a245-b7673bf65261@github.com>

> See the bug for discussion what issues current machinery has. 
> 
> This PR executes the plan outlined in the bug:
>  1. Common the receiver type profiling code in interpreter and C1
>  2. Rewrite receiver type profiling code to only do atomic receiver slot installations
>  3. Trim `C1OptimizeVirtualCallProfiling` to only claim slots when receiver is installed 
> 
> This PR does _not_ do atomic counter updates themselves, as it may have much wider performance implications, including regressions. This PR should be at least performance neutral.
> 
> Additional testing:
>   - [x] Linux x86_64 server fastdebug, `compiler/`
>   - [x] Linux x86_64 server fastdebug, `all`

Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:

 - 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
 - Offset is always rscratch1, no need to save it
 - ... and 12 more: https://git.openjdk.org/jdk/compare/1bbbce75...c28810e3

-------------

Changes: https://git.openjdk.org/jdk/pull/25305/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25305&range=08
  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 shade at openjdk.org  Wed Dec 10 08:33:32 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 10 Dec 2025 08:33:32 GMT
Subject: RFR: 8357258: x86: Improve receiver type profiling reliability
 [v8]
In-Reply-To: <dEG0Z-h_AKU79xlcWa3tyWqbMZSFqm9m6vEKl19JlBo=.deff71db-d617-4df9-8aa0-7242875b666c@github.com>
References: <X9RJoDWqk67MlK7P4ACCbzROxLkfEqvU0zDid3zymnc=.7c0086a3-f514-4b0d-8bc0-592bf4a05bba@github.com>
 <avqNAcH5MpUoM31mrtm0Z6qnPqpgbpGszW01AtFbYXk=.359b8088-c0b5-4a01-aefc-fe3c02bdd60a@github.com>
 <dEG0Z-h_AKU79xlcWa3tyWqbMZSFqm9m6vEKl19JlBo=.deff71db-d617-4df9-8aa0-7242875b666c@github.com>
Message-ID: <znkJzX6vqwn6MuX7YdQ6duTJ9srsVC1cjqZV0M2oYuQ=.0b1a7244-40d8-4809-b726-38af03701274@github.com>

On Thu, 4 Dec 2025 19:14:43 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> I'm curious how performance-sensitive that part of code is. Does it make sense to try to further optimize it?

This is about 5-th-ish version of this code, so I don't think there is more juice to squeeze out of it. The current version is more or less optimal. The stratification into three cases looks the best performing overall.

> fast path can be further optimized for no nulls case by offloading more work on found_null slow path [1]

Yeah, but putting checks for both installed receiver and nullptr slot turns out hurting performance; this is bad even without extra control flow. Two separate loops are more efficient, even for small number of iterations. It also helpfully optimizes for the best case, when profile is smaller than `TypeProfileWidth`, which is what we want.

>  2 slots is the most common case; any benefits from optimizing specifically for it (e.g., unroll the loops)?

I don't think it is worth the extra complexity, honestly. The loop-y code in current version is still a significant code density win over the decision-tree (unrolled, effectively) approach we are doing currently. Keeping this thing simple means more reliability and less testing surface, plus much less headache to port to other architectures.

Note that the goal for this work is to _improve profiling reliability_ without hopefully ceding too much ground in code density and performance. When I started out, it was not clear if it is doable, given the need for atomics; but it looks doable indeed. So I think we should call this thing done and move on to solving the actual performance problem in this code: the contention on counter updates.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25305#issuecomment-3635936502

From chagedorn at openjdk.org  Wed Dec 10 08:43:36 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 10 Dec 2025 08:43:36 GMT
Subject: RFR: 8354282: C2: more crashes in compiled code because of
 dependency on removed range check CastIIs [v10]
In-Reply-To: <S0C_y4_BZ3l56hm9XGUtrcbFy9kOHfKnllKwXuqUkkg=.763f7645-c941-48b6-a54c-76b2a8b8d547@github.com>
References: <qos-VYvgreqGsB7ke35RmM3L9uHnnM6nUsm2QONKXc4=.9c902d61-5f45-41f5-8276-ac28830c2bf5@github.com>
 <S0C_y4_BZ3l56hm9XGUtrcbFy9kOHfKnllKwXuqUkkg=.763f7645-c941-48b6-a54c-76b2a8b8d547@github.com>
Message-ID: <TIlutsvz6BsHteQOvOf-mqI0aA4Bpo3tqSbcijLWvZc=.90e62397-ee7a-43b5-ba4b-b18983710708@github.com>

On Fri, 5 Dec 2025 14:05:06 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> This is a variant of 8332827. In 8332827, an array access becomes
>> dependent on a range check `CastII` for another array access. When,
>> after loop opts are over, that RC `CastII` was removed, the array
>> access could float and an out of bound access happened. With the fix
>> for 8332827, RC `CastII`s are no longer removed.
>> 
>> With this one what happens is that some transformations applied after
>> loop opts are over widen the type of the RC `CastII`. As a result, the
>> type of the RC `CastII` is no longer narrower than that of its input,
>> the `CastII` is removed and the dependency is lost.
>> 
>> There are 2 transformations that cause this to happen:
>> 
>> - after loop opts are over, the type of the `CastII` nodes are widen
>>   so nodes that have the same inputs but a slightly different type can
>>   common.
>>   
>> - When pushing a `CastII` through an `Add`, if of the type both inputs
>>   of the `Add`s are non constant, then we end up widening the type
>>   (the resulting `Add` has a type that's wider than that of the
>>   initial `CastII`).
>>   
>> There are already 3 types of `Cast` nodes depending on the
>> optimizations that are allowed. Either the `Cast` is floating
>> (`depends_only_test()` returns `true`) or pinned. Either the `Cast`
>> can be removed if it no longer narrows the type of its input or
>> not. We already have variants of the `CastII`:
>> 
>> - if the Cast can float and be removed when it doesn't narrow the type
>> of its input.
>> 
>> - if the Cast is pinned and be removed when it doesn't narrow the type
>> of its input.
>> 
>> - if the Cast is pinned and can't be removed when it doesn't narrow
>> the type of its input.
>> 
>> What we need here, I think, is the 4th combination:
>> 
>> - if the Cast can float and can't be removed when it doesn't narrow
>> the type of its input.
>> 
>> Anyway, things are becoming confusing with all these different
>> variants named in ways that don't always help figure out what
>> constraints one of them operate under. So I refactored this and that's
>> the biggest part of this change. The fix consists in marking `Cast`
>> nodes when their type is widen in a way that prevents them from being
>> optimized out.
>> 
>> Tobias ran performance testing with a slightly different version of
>> this change and there was no regression.
>
> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Marked as reviewed by chagedorn (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24575#pullrequestreview-3561363531

From roland at openjdk.org  Wed Dec 10 08:48:41 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Wed, 10 Dec 2025 08:48:41 GMT
Subject: Integrated: 8354282: C2: more crashes in compiled code because of
 dependency on removed range check CastIIs
In-Reply-To: <qos-VYvgreqGsB7ke35RmM3L9uHnnM6nUsm2QONKXc4=.9c902d61-5f45-41f5-8276-ac28830c2bf5@github.com>
References: <qos-VYvgreqGsB7ke35RmM3L9uHnnM6nUsm2QONKXc4=.9c902d61-5f45-41f5-8276-ac28830c2bf5@github.com>
Message-ID: <37GHpeFd6FKbfVuMmdhz9-YPcEQcC_fYBRjlLzrkRHg=.f865988e-1ca9-4731-921c-b73029c484cd@github.com>

On Thu, 10 Apr 2025 15:15:54 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> This is a variant of 8332827. In 8332827, an array access becomes
> dependent on a range check `CastII` for another array access. When,
> after loop opts are over, that RC `CastII` was removed, the array
> access could float and an out of bound access happened. With the fix
> for 8332827, RC `CastII`s are no longer removed.
> 
> With this one what happens is that some transformations applied after
> loop opts are over widen the type of the RC `CastII`. As a result, the
> type of the RC `CastII` is no longer narrower than that of its input,
> the `CastII` is removed and the dependency is lost.
> 
> There are 2 transformations that cause this to happen:
> 
> - after loop opts are over, the type of the `CastII` nodes are widen
>   so nodes that have the same inputs but a slightly different type can
>   common.
>   
> - When pushing a `CastII` through an `Add`, if of the type both inputs
>   of the `Add`s are non constant, then we end up widening the type
>   (the resulting `Add` has a type that's wider than that of the
>   initial `CastII`).
>   
> There are already 3 types of `Cast` nodes depending on the
> optimizations that are allowed. Either the `Cast` is floating
> (`depends_only_test()` returns `true`) or pinned. Either the `Cast`
> can be removed if it no longer narrows the type of its input or
> not. We already have variants of the `CastII`:
> 
> - if the Cast can float and be removed when it doesn't narrow the type
> of its input.
> 
> - if the Cast is pinned and be removed when it doesn't narrow the type
> of its input.
> 
> - if the Cast is pinned and can't be removed when it doesn't narrow
> the type of its input.
> 
> What we need here, I think, is the 4th combination:
> 
> - if the Cast can float and can't be removed when it doesn't narrow
> the type of its input.
> 
> Anyway, things are becoming confusing with all these different
> variants named in ways that don't always help figure out what
> constraints one of them operate under. So I refactored this and that's
> the biggest part of this change. The fix consists in marking `Cast`
> nodes when their type is widen in a way that prevents them from being
> optimized out.
> 
> Tobias ran performance testing with a slightly different version of
> this change and there was no regression.

This pull request has now been integrated.

Changeset: 00068a80
Author:    Roland Westrelin <roland at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/00068a80304a809297d0df8698850861e9a1c5e9
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, qamai, galder, epeter

-------------

PR: https://git.openjdk.org/jdk/pull/24575

From sgehwolf at openjdk.org  Wed Dec 10 09:07:43 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 10 Dec 2025 09:07:43 GMT
Subject: RFR: 8367319: Add os interfaces to get machine and container
 values separately [v6]
In-Reply-To: <uHiQOLDZ0iw4ZHbvkiQVRBmLFtKkqzaGJQh1J_cyfD8=.5ed9eea3-3cd3-4352-89ae-35d842cac34d@github.com>
References: <gxXrAX2NGPyZnHuA4ttkfJ8MagiiELK-Wk700A2ZBgw=.00aaf9ab-976d-476a-ba4d-8a4063d96130@github.com>
 <uHiQOLDZ0iw4ZHbvkiQVRBmLFtKkqzaGJQh1J_cyfD8=.5ed9eea3-3cd3-4352-89ae-35d842cac34d@github.com>
Message-ID: <4glPodATF7NcZ5fuFWWrr2Biih1BTP8zOdH1NRbtUIc=.5d4e06b2-554e-4cc5-b95e-cdeeeb6d3d81@github.com>

On Thu, 4 Dec 2025 10:32:46 GMT, Casper Norrbin <cnorrbin at openjdk.org> 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 incrementally with one additional commit since the last revision:
> 
>   feedback updates

Given the comment about the `os::Container` class I'm fine with this. It seems an improvement to the API using code in JFR et. al.

src/hotspot/share/runtime/os.hpp line 378:

> 376:   // Methods return true and set the out-parameter if a limit is found,
> 377:   // or false if no limit exists or it cannot be determined.
> 378:   class Container : AllStatic {

Good.

-------------

Marked as reviewed by sgehwolf (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27646#pullrequestreview-3561443830
PR Review Comment: https://git.openjdk.org/jdk/pull/27646#discussion_r2605780728

From iklam at openjdk.org  Wed Dec 10 09:39:58 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 10 Dec 2025 09:39:58 GMT
Subject: RFR: 8373392: Replace CDS object subgraphs with
 @AOTSafeClassInitializer
Message-ID: <nwFU9L_ngxAg_QtXjVq_IvhIxlnHj49sWV-qMUCS0YY=.4417a88a-c604-415f-b389-12a19938fed3@github.com>

In legacy CDS, Java objects used by certain classes are computed ahead of time using "object subgraphs"

https://github.com/openjdk/jdk/blob/1bbbce75c5e68429c2a32519eb3c36d964dcdf57/src/hotspot/share/cds/heapShared.cpp#L168-L171

Examples of subgraphs:

- `java.lang.Integer$IntegerCache::cache`
- `jdk.internal.module.ArchivedBootLayer::bootLayer`

The implementation requires special code (in both Java and C++) to be executed when a CDS archive is created or loaded. As a result, we have an execution model that's difficult to implement/extend and the behavior is hard to understand.

To move towards the AOT Cache Snapshot Model ([JDK-8365645](https://bugs.openjdk.org/browse/JDK-8365645)) we should replace the subgraphs with the use of `@AOTSafeClassInitializer`, and if necessary, `@AOTRuntimeSetup`. This will simplify the current implementation, and make it possible to extend AOT-initializations to more core classes.

Note, the use of `@AOTSafeClassInitializer` requires `-XX:+AOTClassLinking`. For the time being, we retain the old CDS object subgraph code to cover the `-XX:-AOTClassLinking` cases. Such code will be marked with comments like `/* Legacy CDS archive support (to be deprecated) */`. All future AOT creation of Java objects will be done with  `@AOTSafeClassInitializer`.

-------------

Commit messages:
 - 8373392: Replace CDS object subgraphs with @AOTSafeClassInitializer

Changes: https://git.openjdk.org/jdk/pull/28736/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28736&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373392
  Stats: 602 lines in 29 files changed: 368 ins; 186 del; 48 mod
  Patch: https://git.openjdk.org/jdk/pull/28736.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28736/head:pull/28736

PR: https://git.openjdk.org/jdk/pull/28736

From bmaillard at openjdk.org  Wed Dec 10 09:45:25 2025
From: bmaillard at openjdk.org (=?UTF-8?B?QmVub8OudA==?= Maillard)
Date: Wed, 10 Dec 2025 09:45:25 GMT
Subject: RFR: 8370519: C2: Hit MemLimit when running with
 +VerifyLoopOptimizations [v3]
In-Reply-To: <_HueHgU8Ha0yoG9cckWMGfms8D0WC6zGWKykIQkCeZM=.3f929996-99ee-4535-8973-b23ccf6b291e@github.com>
References: <W7EnT28-84mtwppISdr_ydCV9HSaXk72y7fyd29z4wQ=.7331c81d-c36f-4a1c-b949-e7045f524d07@github.com>
 <rFGy_mZFS29oe2Ie23rRCqFQigWHLghMgum7heKDZcw=.8447fff4-e59d-4ea0-9005-9e5f71930489@github.com>
 <_HueHgU8Ha0yoG9cckWMGfms8D0WC6zGWKykIQkCeZM=.3f929996-99ee-4535-8973-b23ccf6b291e@github.com>
Message-ID: <2y_kifh8vJEM5lyJpXJQ-rXVAz7ThwswYO0q4-7At00=.9607b284-e8be-4b6b-bf22-3671ac936ad5@github.com>

On Tue, 2 Dec 2025 11:16:50 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/c2/TestVerifyLoopOptimizationsHighMemUsage.java line 28:
>> 
>>> 26:  * @bug 8370519
>>> 27:  * @summary C2: Hit MemLimit when running with +VerifyLoopOptimizations
>>> 28:  * @run main/othervm -XX:CompileCommand=compileonly,*TestVerifyLoopOptimizationsHighMemUsage*::* -XX:-TieredCompilation -Xbatch
>> 
>> Out of curiosity, have you try reducing the test with `creduce`? I fixed a similar issue in [JDK-8366990](https://bugs.openjdk.org/browse/JDK-8366990), and initially reviewers were concerned about the long compilation time. I was able to get decent results with `creduce` by using  `-XX:CompileCommand=memlimit`. Not sure if it's worth doing here though.
>
> I don't have `creduce` set up. I tried minimizing the test case by hand but it was fairly time consuming. It currently runs in 30s on a fairly fast machine.

I am giving it a try on my setup, I'll let you know if something comes up.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28581#discussion_r2605912924

From bmaillard at openjdk.org  Wed Dec 10 09:45:28 2025
From: bmaillard at openjdk.org (=?UTF-8?B?QmVub8OudA==?= Maillard)
Date: Wed, 10 Dec 2025 09:45:28 GMT
Subject: RFR: 8370519: C2: Hit MemLimit when running with
 +VerifyLoopOptimizations [v3]
In-Reply-To: <FkXbOvbukpCfSEBmYIOsn1IUaRnPZhEYv3yfz3Dz-QQ=.da549428-ed90-424e-8a77-dac3a745ed67@github.com>
References: <W7EnT28-84mtwppISdr_ydCV9HSaXk72y7fyd29z4wQ=.7331c81d-c36f-4a1c-b949-e7045f524d07@github.com>
 <FkXbOvbukpCfSEBmYIOsn1IUaRnPZhEYv3yfz3Dz-QQ=.da549428-ed90-424e-8a77-dac3a745ed67@github.com>
Message-ID: <jBuG2f0a6kNU_NG4TdgwAryvHqYYsL63wd-ZSBF-Avs=.4669f1b3-e55a-41cc-8efd-d77162dfc2d1@github.com>

On Tue, 2 Dec 2025 11:21:05 GMT, Roland Westrelin <roland at openjdk.org> 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 two additional commits since the last revision:
> 
>  - review
>  - review

test/hotspot/jtreg/compiler/c2/TestVerifyLoopOptimizationsHighMemUsage.java line 30:

> 28:  * @summary C2: Hit MemLimit when running with +VerifyLoopOptimizations
> 29:  * @run main/othervm -XX:CompileCommand=compileonly,*TestVerifyLoopOptimizationsHighMemUsage*::* -XX:-TieredCompilation -Xbatch
> 30:  *                   -XX:+UnlockDiagnosticVMOptions -XX:+StressLoopPeeling -XX:+VerifyLoopOptimizations

I think you'll also need `-XX:+IgnoreUnrecognizedVMOptions` (it is causing issues in Github actions).
Suggestion:

 *                   -XX:+UnlockDiagnosticVMOptions -XX:+IgnoreUnrecognizedVMOptions
 *                   -XX:+StressLoopPeeling -XX:+VerifyLoopOptimizations

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28581#discussion_r2605877498

From dlong at openjdk.org  Wed Dec 10 09:46:31 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 10 Dec 2025 09:46:31 GMT
Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() [v6]
In-Reply-To: <CEvEqPtlTMiv7fX1G_spyCpyl8afEZn4McrzIBd5GRY=.d233254e-3626-4044-a3e1-c82bcbd55e45@github.com>
References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com>
 <CEvEqPtlTMiv7fX1G_spyCpyl8afEZn4McrzIBd5GRY=.d233254e-3626-4044-a3e1-c82bcbd55e45@github.com>
Message-ID: <IgJPZjkSTXXaSc1nY_-nKBXxvOO33c41CCihYus-Pkg=.aced8ffe-3a3a-45dc-8ca5-ff09e9c6c8d1@github.com>

On Mon, 8 Dec 2025 14:01:48 GMT, Fei Gao <fgao at openjdk.org> 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/eceb20fd...415495da

I think `set_stub_to_clean` is the wrong place to restore the ISB.  I don't think it is guaranteed to be called between `set_to_interpreted` calls.  Instead, `reresolve_call_site` or `fixup_callers_callsite` will call `set_to_clean`.  But even if the ISB is guaranteed to be restored, how to we guarantee that it is observed?  Don't we have the same problem with the rewritten ISB as we did with the rewritten MOVs?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26638#issuecomment-3636214142

From jbhateja at openjdk.org  Wed Dec 10 10:07:28 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 10 Dec 2025 10:07:28 GMT
Subject: RFR: 8368977: Provide clear naming for AVX10 identifiers [v2]
In-Reply-To: <JZnx2wYn7sTlojACH-CG8c77eMFJo_WxAMA2hEWlSGI=.0ed3a154-f3e9-4815-9039-4ab1629b5060@github.com>
References: <6XYgqaHA0PPZzvnfysKOP5XGP7e_RMkVFt9PV2OT3Gk=.e5f33072-a91a-4e57-99f3-81cc4ae4d844@github.com>
 <JZnx2wYn7sTlojACH-CG8c77eMFJo_WxAMA2hEWlSGI=.0ed3a154-f3e9-4815-9039-4ab1629b5060@github.com>
Message-ID: <bvUzpvPndu3S-IHhz-Ct1SLrFla1N9GsH_fjXjdAMO8=.c221adea-1710-4f11-86c7-38e2317a4563@github.com>

On Mon, 8 Dec 2025 21:47:16 GMT, Mohamed Issa <missa at openjdk.org> wrote:

>> This is a simple change that renames all AVX10 identifiers to explicitly show which sub-versions are in use. Right now, AVX10.2 is the only case to worry about. The JTREG tests listed below were used to verify correctness with the recommended JVM options mentioned in corresponding source files. Each test included runs through emulation with AVX10.2 enabled and disabled to exercise all possible paths. All modifications and tests used [OpenJDK v26-b24](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B24) as the baseline build.
>> 
>> 1. `jtreg:test/hotspot/jtreg/compiler/codegen/TestByteDoubleVect.java`
>> 2. `jtreg:test/hotspot/jtreg/compiler/codegen/TestByteFloatVect.java`
>> 3. `jtreg:test/hotspot/jtreg/compiler/codegen/TestIntDoubleVect.java`
>> 4. `jtreg:test/hotspot/jtreg/compiler/codegen/TestIntFloatVect.java`
>> 5. `jtreg:test/hotspot/jtreg/compiler/codegen/TestLongDoubleVect.java`
>> 6. `jtreg:test/hotspot/jtreg/compiler/codegen/TestLongFloatVect.java`
>> 7. `jtreg:test/hotspot/jtreg/compiler/codegen/TestShortDoubleVect.java`
>> 8. `jtreg:test/hotspot/jtreg/compiler/codegen/TestShortFloatVect.java`
>> 9. `jtreg:test/hotspot/jtreg/compiler/floatingpoint/ScalarFPtoIntCastTest.java`
>> 10. `jtreg:test/hotspot/jtreg/compiler/vectorapi/VectorFPtoIntCastTest.java`
>> 11. `jtreg:test/hotspot/jtreg/compiler/vectorization/runner/ArrayTypeConvertTest.java`
>> 12. `jtreg:test/jdk/jdk/incubator/vector/Double64VectorTests.java`
>> 13. `jtreg:test/jdk/jdk/incubator/vector/Double128VectorTests.java`
>> 14. `jtreg:test/jdk/jdk/incubator/vector/Double256VectorTests.java`
>> 15. `jtreg:test/jdk/jdk/incubator/vector/Double512VectorTests.java`
>> 16. `jtreg:test/jdk/jdk/incubator/vector/DoubleMaxVectorTests.java`
>> 17. `jtreg:test/jdk/jdk/incubator/vector/Float64VectorTests.java`
>> 18. `jtreg:test/jdk/jdk/incubator/vector/Float128VectorTests.java`
>> 19. `jtreg:test/jdk/jdk/incubator/vector/Float256VectorTests.java`
>> 20. `jtreg:test/jdk/jdk/incubator/vector/Float512VectorTests.java`
>> 21. `jtreg:test/jdk/jdk/incubator/vector/FloatMaxVectorTests.java`
>> 22. `jtreg:test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorOperations.java`
>> 23. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java`
>
> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove changes that affect functionality

LGTM, naming now follows the AVX10 versions sheme where an instruction supported by a version is guaranteed to be supported by all the version above it.

-------------

Marked as reviewed by jbhateja (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28344#pullrequestreview-3561706798

From jbhateja at openjdk.org  Wed Dec 10 10:23:30 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 10 Dec 2025 10:23:30 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v7]
In-Reply-To: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
Message-ID: <H1M8_FtGtYl2jww_n3OE5o3G8SFCe8TMl-XgtRA6Krg=.fb56cb81-2890-47c5-b35b-b2d730e3e71f@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.
> 
> <img width="1344" height="532" alt="image" src="https://github.com/user-attachments/assets/c8157c3c-22b0-4bc1-9de9-7a68cadb7b2a" />
> 
> Initial RFP[1] was floated on the panama-dev mailing list.
> 
> Kindly review the draft PR and share your feedback.
> 
> Best Regards,
> Jatin
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html

Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:

 - 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
 - Adding support for custom basic  type T_FLOAT16, passing BasicType lane types to inline expander entries
 - Cleaning up interface as per review suggestions
 - Some cleanups
 - ... and 10 more: https://git.openjdk.org/jdk/compare/b60ac710...44ac727d

-------------

Changes: https://git.openjdk.org/jdk/pull/28002/files
  Webrev: Webrev is not available because diff is too large
  Stats: 515190 lines in 231 files changed: 284426 ins; 229037 del; 1727 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 fgao at openjdk.org  Wed Dec 10 11:20:28 2025
From: fgao at openjdk.org (Fei Gao)
Date: Wed, 10 Dec 2025 11:20:28 GMT
Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() [v6]
In-Reply-To: <IgJPZjkSTXXaSc1nY_-nKBXxvOO33c41CCihYus-Pkg=.aced8ffe-3a3a-45dc-8ca5-ff09e9c6c8d1@github.com>
References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com>
 <CEvEqPtlTMiv7fX1G_spyCpyl8afEZn4McrzIBd5GRY=.d233254e-3626-4044-a3e1-c82bcbd55e45@github.com>
 <IgJPZjkSTXXaSc1nY_-nKBXxvOO33c41CCihYus-Pkg=.aced8ffe-3a3a-45dc-8ca5-ff09e9c6c8d1@github.com>
Message-ID: <vx1ZdWyW9HA_iqF8FFyIYqzSJUKnKRH0ckcVRjENTFA=.b9c60eb5-102e-4697-82d4-b2ab06a57acc@github.com>

On Wed, 10 Dec 2025 09:43:44 GMT, Dean Long <dlong at openjdk.org> wrote:

> I think `set_stub_to_clean` is the wrong place to restore the ISB. I don't think it is guaranteed to be called between `set_to_interpreted` calls. Instead, `reresolve_call_site` or `fixup_callers_callsite` will call `set_to_clean`. But even if the ISB is guaranteed to be restored, how to we guarantee that it is observed? Don't we have the same problem with the rewritten ISB as we did with the rewritten MOVs?

Thanks for your review @dean-long !

Based on my limited understanding, and as discussed earlier by Mikhail and Andrew [here](https://github.com/openjdk/jdk/pull/26638#issuecomment-3179283141), it is both unsafe and unnecessary to clear the static call stub by calling `CompiledDirectCall::set_stub_to_clean` in any situation where the stub is shared between calls to the same method.

In fact, `CompiledDirectCall::set_stub_to_clean` was effectively unused before
https://github.com/openjdk/jdk/pull/23573. That PR introduced a use of `set_stub_to_clean` when creating a relocated copy of an nmethod [here](https://github.com/openjdk/jdk/blob/8eaeb6990b85ac8717f4fc4ce883f674017b91f3/src/hotspot/share/code/nmethod.cpp#L1532), before the copy is marked as in use. Under these conditions, the ISB is guaranteed to be restored and observed. I think there is no race related to restoring the ISB.

WDYT? Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26638#issuecomment-3636597692

From bkilambi at openjdk.org  Wed Dec 10 11:24:28 2025
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Wed, 10 Dec 2025 11:24:28 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v7]
In-Reply-To: <H1M8_FtGtYl2jww_n3OE5o3G8SFCe8TMl-XgtRA6Krg=.fb56cb81-2890-47c5-b35b-b2d730e3e71f@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <H1M8_FtGtYl2jww_n3OE5o3G8SFCe8TMl-XgtRA6Krg=.fb56cb81-2890-47c5-b35b-b2d730e3e71f@github.com>
Message-ID: <EZZJHvwvigZ6Fs9prEOVr8DGGtZbbxd1yxMf594q5Wc=.a05a98cc-c11f-4561-9922-a318217f4108@github.com>

On Wed, 10 Dec 2025 10:23:30 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Add a new  Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type.
>> - Add necessary inline expander support.
>>    - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA.
>> - Use existing Float16 vector IR and backend support.
>> - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations.
>>  
>> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc).
>> 
>> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels.
>> 
>> <img width="1344" height="532" alt="image" src="https://github.com/user-attachments/assets/c8157c3c-22b0-4bc1-9de9-7a68cadb7b2a" />
>> 
>> Initial RFP[1] was floated on the panama-dev mailing list.
>> 
>> Kindly review the draft PR and share your feedback.
>> 
>> Best Regards,
>> Jatin
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
> 
>  - 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
>  - Adding support for custom basic  type T_FLOAT16, passing BasicType lane types to inline expander entries
>  - Cleaning up interface as per review suggestions
>  - Some cleanups
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/b60ac710...44ac727d

This patch results in two of the JTREG tests failing on aarch64 machines-


jdk/incubator/vector/Float16Vector512Tests.java
compiler/vectorapi/TestFloat16VectorOperations.java


which is due to an issue in the `aarch64.ad` file. Fixed the failures and also added aarch64 specific IR rules which were missing for some of the tests in the `compiler/vectorapi/TestFloat16VectorOperations.java` test.

@jatin-bhateja Could you please add the attached fix to this patch? Thanks!
[fix.patch](https://github.com/user-attachments/files/24076067/fix.patch)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3636610190

From epeter at openjdk.org  Wed Dec 10 13:12:34 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 10 Dec 2025 13:12:34 GMT
Subject: RFR: 8372845: C2: Fold identity hash code if object is constant
 [v3]
In-Reply-To: <AqXlBQi24MmML3tltUJiZa0bEYzORazv9mVo41lrIP4=.13265855-6308-47d1-93f0-006bfe06fdfa@github.com>
References: <KPNLohuiE3Os64ib8cPl8cyPUbmvzOF2y687qapKSgc=.cae21b9f-2fa9-4e78-a5ef-7912cf906dfa@github.com>
 <AqXlBQi24MmML3tltUJiZa0bEYzORazv9mVo41lrIP4=.13265855-6308-47d1-93f0-006bfe06fdfa@github.com>
Message-ID: <cavp_9ZUlDCfuwg9Eyp8wDms7j5GOtSZPwYk-QYMbVI=.bfed4082-375e-4a52-a2a1-4071843b7550@github.com>

On Tue, 2 Dec 2025 23:25:29 GMT, Chen Liang <liach at openjdk.org> 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:
> 
>   Typo

Drive-by comments

test/hotspot/jtreg/compiler/c2/irTests/constantFold/IdentityHashCodeFold.java line 37:

> 35:  * @library /test/lib /
> 36:  * @requires vm.compiler2.enabled
> 37:  * @run driver compiler.c2.irTests.constantFold.IdentityHashCodeFold

Suggestion:

 * @run driver ${test.main.class}

Is the C2 requirement really necessary?

test/hotspot/jtreg/compiler/c2/irTests/constantFold/IdentityHashCodeFold.java line 51:

> 49:     public int testSum() {
> 50:         return a.hashCode() + System.identityHashCode(b);
> 51:     }

This does not test correctness of the result. How confident are we that this patch is sufficiently tested?
How can we test that the compiled and interpreter hashcode are equivalent?

-------------

PR Review: https://git.openjdk.org/jdk/pull/28589#pullrequestreview-3562463539
PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2606597900
PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2606602984

From duke at openjdk.org  Wed Dec 10 13:15:46 2025
From: duke at openjdk.org (Ruben)
Date: Wed, 10 Dec 2025 13:15:46 GMT
Subject: RFR: 8366441: AArch64: Support WFET in OnSpinWait
Message-ID: <pCQ3UJd__52UsHCs4O0oLcLZTXN602dBEP8zmRvU-H4=.aff34c5d-0a53-4e9a-8107-b6fadc7d9cca@github.com>

Implement OnSpinWait based on WFET - wait for event with timeout:
 - introduce OnSpinWaitDelay - the OnSpinWait time in nanoseconds;
 - the OnSpinWaitInstCount is expected to be 1 when WFET is used;
 - the waiting loop is followed by SB - to ensure following instructions aren't speculated until wait is finished;
 - the timer register is read via the self-synchronized view CNTVCTSS_EL0 to prevent the read being hoisted out of the loop.

The WFET and CNTVCTSS_EL0 read are added to aarch64-asmtest.py as hex values - using the instruction mnemonics would require support of -march=armv9-2.a, and consequently, the binutils 2.36+.

-------------

Commit messages:
 - Update
 - Merge from mainline
 - 8366441: AArch64: Support WFET in OnSpinWait

Changes: https://git.openjdk.org/jdk/pull/27030/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27030&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366441
  Stats: 1272 lines in 14 files changed: 153 ins; 1 del; 1118 mod
  Patch: https://git.openjdk.org/jdk/pull/27030.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27030/head:pull/27030

PR: https://git.openjdk.org/jdk/pull/27030

From aph at openjdk.org  Wed Dec 10 13:15:46 2025
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 10 Dec 2025 13:15:46 GMT
Subject: RFR: 8366441: AArch64: Support WFET in OnSpinWait
In-Reply-To: <pCQ3UJd__52UsHCs4O0oLcLZTXN602dBEP8zmRvU-H4=.aff34c5d-0a53-4e9a-8107-b6fadc7d9cca@github.com>
References: <pCQ3UJd__52UsHCs4O0oLcLZTXN602dBEP8zmRvU-H4=.aff34c5d-0a53-4e9a-8107-b6fadc7d9cca@github.com>
Message-ID: <IPimGRgvAU6qfY4SfLBET3GSY6dB-D-8wMdAGkj8dH0=.63a99e19-8c6c-45a2-905b-6dd27b6893e6@github.com>

On Mon, 1 Sep 2025 11:00:27 GMT, Ruben <duke at openjdk.org> wrote:

> The WFET and CNTVCTSS_EL0 read are added to aarch64-asmtest.py as hex values - using the instruction mnemonics would require support of -march=armv9-2.a, and consequently, the binutils 2.36+.

So please use binutils 2.36+.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27030#issuecomment-3242604646

From epeter at openjdk.org  Wed Dec 10 13:18:31 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 10 Dec 2025 13:18:31 GMT
Subject: RFR: 8370519: C2: Hit MemLimit when running with
 +VerifyLoopOptimizations [v3]
In-Reply-To: <FkXbOvbukpCfSEBmYIOsn1IUaRnPZhEYv3yfz3Dz-QQ=.da549428-ed90-424e-8a77-dac3a745ed67@github.com>
References: <W7EnT28-84mtwppISdr_ydCV9HSaXk72y7fyd29z4wQ=.7331c81d-c36f-4a1c-b949-e7045f524d07@github.com>
 <FkXbOvbukpCfSEBmYIOsn1IUaRnPZhEYv3yfz3Dz-QQ=.da549428-ed90-424e-8a77-dac3a745ed67@github.com>
Message-ID: <G89yMENAdUzXCgStQ1TIoV78nGlSH1JdFayw8MyP2cU=.9dc5bb37-75b6-4abf-9323-de5ec1501a15@github.com>

On Tue, 2 Dec 2025 11:21:05 GMT, Roland Westrelin <roland at openjdk.org> 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 two additional commits since the last revision:
> 
>  - review
>  - review

Changes requested by epeter (Reviewer).

src/hotspot/share/opto/loopnode.hpp line 672:

> 670:   bool  _allow_optimizations;   // Allow loop optimizations
> 671: 
> 672:   IdealLoopTree( PhaseIdealLoop* phase, Node *head, Node *tail );

Suggestion:

  IdealLoopTree(PhaseIdealLoop* phase, Node* head, Node* tail);

src/hotspot/share/opto/loopnode.hpp line 1217:

> 1215:     PhaseTransform(Ideal_Loop),
> 1216:     _arena(mtCompiler, Arena::Tag::tag_idealloop),
> 1217:     _loop_or_ctrl(&_arena),

How about some of the other data structures? For example `_idom`?

test/hotspot/jtreg/compiler/c2/TestVerifyLoopOptimizationsHighMemUsage.java line 32:

> 30:  *                   -XX:+UnlockDiagnosticVMOptions -XX:+StressLoopPeeling -XX:+VerifyLoopOptimizations
> 31:  *                   -XX:StressSeed=3106998670 TestVerifyLoopOptimizationsHighMemUsage
> 32:  * @run main TestVerifyLoopOptimizationsHighMemUsage

Suggestion:

 * @run main ${test.main.class}

Also: your test does not have a `package` declaration.

-------------

PR Review: https://git.openjdk.org/jdk/pull/28581#pullrequestreview-3562480981
PR Review Comment: https://git.openjdk.org/jdk/pull/28581#discussion_r2606610438
PR Review Comment: https://git.openjdk.org/jdk/pull/28581#discussion_r2606618710
PR Review Comment: https://git.openjdk.org/jdk/pull/28581#discussion_r2606620987

From epeter at openjdk.org  Wed Dec 10 13:21:27 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 10 Dec 2025 13:21:27 GMT
Subject: RFR: 8372779: C2: Disambiguate Node::adr_type for the IR graph
 [v3]
In-Reply-To: <KMe08qt3HwEW_ewxHKx20KerRqY2EP9ucNOLgRBKKcA=.fa352cdc-0f09-479e-9d6a-7c6a56bfb301@github.com>
References: <dEidZLl1MkM6TbAxS2FsitU70AYAahwzK9cun61wwV8=.ccdad883-5d8f-403e-a19f-40aef0f53b11@github.com>
 <KMe08qt3HwEW_ewxHKx20KerRqY2EP9ucNOLgRBKKcA=.fa352cdc-0f09-479e-9d6a-7c6a56bfb301@github.com>
Message-ID: <opcUxZyR0Zd5FEpFYahlFYkovBw4CafX8tCrDWpSKZQ=.441ecb8a-35c4-4ca2-8dde-cb2d5db629e1@github.com>

On Sun, 7 Dec 2025 12:12:20 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> Currently, `Node::adr_type` is ambiguous. For some, it refers to the memory the node consumes, while for the others, it refer to the memory the node produces. This PR removes that ambiguity by introducing `Node::in_adr_type` and `Node::out_adr_type` that refer to those properties, respectively. It also introduces a local verification of the memory graph during compilation. These additions uncover some issues:
>> 
>> - Sometimes, the memory is wired incorrectly, such as in `LibraryCall::extend_setCurrentThread`, the `Phi` collect the `StoreNode`s instead of the whole memory state. I think these issues do not result in crashes or miscompilation, though.
>> - `AryEqNode` reports `adr_type` being `TypeAryPtr::BYTES` (it inherits this from `StrIntrinsicNode`). This is incorrect, however, as it can accept `char[]` inputs, too.
>> - For nodes such as `StrInflatedCopyNode`, as it consumes more than it produces, during scheduling, we need to compute anti-dependencies. This is not the case, so I fixed it by making it kill all the memory it consumes.
>> - `GraphKit::set_output_for_allocation` uses a raw `ProjNode` as the base for a `MergeMem`, this is really suspicious. I didn't fix it, as it seems to not result in any symptom at the moment.
>> 
>> In the end, the execution of the compiler is strictly more restricted than before, and there is less room for ambiguity.
>> 
>> Please take a look and leave your reviews, thanks a lot.
>
> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into adrtype
>  - store_to_memory does not emit MemBars
>  - Disambiguate Node::adr_type

@merykitty I can't promise that I'll review the PR yet. But I have an initial question:
Since some cases were wrong, does that mean we can find reproducers for those cases? Because it may be worth backporting some cases, but we would first need to know if there are cases that actually are currently wrong.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28570#issuecomment-3637055561

From mbaesken at openjdk.org  Wed Dec 10 14:26:33 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 10 Dec 2025 14:26:33 GMT
Subject: RFR: 8372348: Adjust some UL / JFR string deduplication output
 messages
In-Reply-To: <kLaKX3lyoQshzjHXilycyq9_ixhaiQMy76zmavAX35M=.682f43b9-e72f-48ed-90a5-fcb84b3d3c90@github.com>
References: <7-XRp229KFw3V2bFPMnaWaoPdF3ZCYVNuViEo2O7eUI=.e0247347-188b-44bf-935c-6b0186026fd3@github.com>
 <2r6k6Av9MTNmMxpbga6MJoUCu0vECsr7IDL6wAzJ_Ig=.c9106917-1635-4d3c-b6c4-f4c5f0659440@github.com>
 <kLaKX3lyoQshzjHXilycyq9_ixhaiQMy76zmavAX35M=.682f43b9-e72f-48ed-90a5-fcb84b3d3c90@github.com>
Message-ID: <Ien8WqqsVLY--khvk8WkOeaSpaAKWcQ45x_5tCxQZTI=.f0f9bb58-ef10-4c78-8746-49f5a7bfa803@github.com>

On Mon, 24 Nov 2025 08:20:09 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/stringdedup/stringDedupStat.cpp line 218:
>> 
>>> 216:   log_debug(stringdedup)("      Known:       %12zu(%5.1f%%)", _known, known_percent);
>>> 217:   log_debug(stringdedup)("      Shared:      %12zu(%5.1f%%)", _known_shared, known_shared_percent);
>>> 218:   log_debug(stringdedup)("      New unknown: %12zu(%5.1f%%)" STRDEDUP_BYTES_FORMAT,
>> 
>> I'm wondering if just `Unknown` would be more self-explanatory than `New unknown`? We have `Known` already, and `New unknown` is the complement of `Known`
>
> Maybe , but the variables are named `_new / _new_bytes` and the JFR fields also have 'new' in the name. So it maybe makes sense to keep 'new' in the UL and related output.

The avg  (now named total avg) is for some people also a bit mysterious .
It is , taken from total_stat , the` deduped bytes / new bytes` .  Why is it called avg? avg of what ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28455#discussion_r2606867602

From eastigeevich at openjdk.org  Wed Dec 10 15:09:30 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Wed, 10 Dec 2025 15:09:30 GMT
Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact
 on GCs and JIT performance [v15]
In-Reply-To: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
Message-ID: <wQCvqP2QoXY5enNEuFFEKyt2r3Ae9bJWYaFGGvAzuJ4=.b3404fbb-fae4-43d6-81bc-97fa5f8e45da@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 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.
> 
> Benchmarking results: Neoverse-N1 r3p1 (Graviton 2), 5 000 nmethods, 1 parallel thread, 1 concurrent thread, 3 forks, ms/op (lower better)
> 
> - ZGC
> 
> | Benchmark | accessedFieldCount | Baseline | Error (Baseline) | Fix | ...

Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:

  Fix tier1 failures

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28328/files
  - new: https://git.openjdk.org/jdk/pull/28328/files/b9380fd8..85691beb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28328&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28328&range=13-14

  Stats: 69 lines in 10 files changed: 27 ins; 31 del; 11 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 liach at openjdk.org  Wed Dec 10 15:27:56 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 10 Dec 2025 15:27:56 GMT
Subject: RFR: 8373392: Replace CDS object subgraphs with
 @AOTSafeClassInitializer
In-Reply-To: <nwFU9L_ngxAg_QtXjVq_IvhIxlnHj49sWV-qMUCS0YY=.4417a88a-c604-415f-b389-12a19938fed3@github.com>
References: <nwFU9L_ngxAg_QtXjVq_IvhIxlnHj49sWV-qMUCS0YY=.4417a88a-c604-415f-b389-12a19938fed3@github.com>
Message-ID: <T2dpMbwbHVIMHigIEI971AnIIFeB7xpWmveNWxHn0w4=.b6e46ea4-a1a6-47b7-8bf4-0c0c81c1d912@github.com>

On Wed, 10 Dec 2025 09:31:37 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> In legacy CDS, Java objects used by certain classes are computed ahead of time using "object subgraphs"
> 
> https://github.com/openjdk/jdk/blob/1bbbce75c5e68429c2a32519eb3c36d964dcdf57/src/hotspot/share/cds/heapShared.cpp#L168-L171
> 
> Examples of subgraphs:
> 
> - `java.lang.Integer$IntegerCache::cache`
> - `jdk.internal.module.ArchivedBootLayer::bootLayer`
> 
> The implementation requires special code (in both Java and C++) to be executed when a CDS archive is created or loaded. As a result, we have an execution model that's difficult to implement/extend and the behavior is hard to understand.
> 
> To move towards the AOT Cache Snapshot Model ([JDK-8365645](https://bugs.openjdk.org/browse/JDK-8365645)) we should replace the subgraphs with the use of `@AOTSafeClassInitializer`, and if necessary, `@AOTRuntimeSetup`. This will simplify the current implementation, and make it possible to extend AOT-initializations to more core classes.
> 
> Note, the use of `@AOTSafeClassInitializer` requires `-XX:+AOTClassLinking`. For the time being, we retain the old CDS object subgraph code to cover the `-XX:-AOTClassLinking` cases. Such code will be marked with comments like `/* Legacy CDS archive support (to be deprecated) */`. All future AOT creation of Java objects will be done with  `@AOTSafeClassInitializer`.

Is IntegerCache.cache the only field that need to be adjusted according to system properties after loading from AOT archive?

src/java.base/share/classes/java/util/ImmutableCollections.java line 80:

> 78:     @AOTRuntimeSetup
> 79:     private static void runtimeSetup() {
> 80:          // to generate a reasonably random and well-mixed SALT, use an arbitrary

Suggestion:

        // to generate a reasonably random and well-mixed SALT, use an arbitrary

-------------

PR Review: https://git.openjdk.org/jdk/pull/28736#pullrequestreview-3563043067
PR Review Comment: https://git.openjdk.org/jdk/pull/28736#discussion_r2607052565

From asteiner at openjdk.org  Wed Dec 10 15:28:00 2025
From: asteiner at openjdk.org (Andreas Steiner)
Date: Wed, 10 Dec 2025 15:28:00 GMT
Subject: RFR: 8372348: Adjust some UL / JFR string deduplication output
 messages
In-Reply-To: <Ien8WqqsVLY--khvk8WkOeaSpaAKWcQ45x_5tCxQZTI=.f0f9bb58-ef10-4c78-8746-49f5a7bfa803@github.com>
References: <7-XRp229KFw3V2bFPMnaWaoPdF3ZCYVNuViEo2O7eUI=.e0247347-188b-44bf-935c-6b0186026fd3@github.com>
 <2r6k6Av9MTNmMxpbga6MJoUCu0vECsr7IDL6wAzJ_Ig=.c9106917-1635-4d3c-b6c4-f4c5f0659440@github.com>
 <kLaKX3lyoQshzjHXilycyq9_ixhaiQMy76zmavAX35M=.682f43b9-e72f-48ed-90a5-fcb84b3d3c90@github.com>
 <Ien8WqqsVLY--khvk8WkOeaSpaAKWcQ45x_5tCxQZTI=.f0f9bb58-ef10-4c78-8746-49f5a7bfa803@github.com>
Message-ID: <pNpdqbYFfgvrIkYZRCFEldiccxVqyq1vQB3hxnIs1Nk=.b7f28843-7e09-477f-9a0f-63bb3314b9f8@github.com>

On Wed, 10 Dec 2025 14:23:24 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Maybe , but the variables are named `_new / _new_bytes` and the JFR fields also have 'new' in the name. So it maybe makes sense to keep 'new' in the UL and related output.
>
> The avg  (now named total avg) is for some people also a bit mysterious .
> It is , taken from total_stat , the` deduped bytes / new bytes` .  Why is it called avg? avg of what ?

Adding total will be helpful already, but why are not the numbers printed on which the avg is based? Because otherwise you don't get an impression what the percentage mean.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28455#discussion_r2607111295

From liach at openjdk.org  Wed Dec 10 15:39:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 10 Dec 2025 15:39:53 GMT
Subject: RFR: 8372845: C2: Fold identity hash code if object is constant
 [v3]
In-Reply-To: <cavp_9ZUlDCfuwg9Eyp8wDms7j5GOtSZPwYk-QYMbVI=.bfed4082-375e-4a52-a2a1-4071843b7550@github.com>
References: <KPNLohuiE3Os64ib8cPl8cyPUbmvzOF2y687qapKSgc=.cae21b9f-2fa9-4e78-a5ef-7912cf906dfa@github.com>
 <AqXlBQi24MmML3tltUJiZa0bEYzORazv9mVo41lrIP4=.13265855-6308-47d1-93f0-006bfe06fdfa@github.com>
 <cavp_9ZUlDCfuwg9Eyp8wDms7j5GOtSZPwYk-QYMbVI=.bfed4082-375e-4a52-a2a1-4071843b7550@github.com>
Message-ID: <XpDpc28hjOioKUPvgyyCXCVkZLVeHL7GGmoEW5--1UE=.809ce0b3-8992-4f55-98a8-8834401597a5@github.com>

On Wed, 10 Dec 2025 13:07:20 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Typo
>
> test/hotspot/jtreg/compiler/c2/irTests/constantFold/IdentityHashCodeFold.java line 37:
> 
>> 35:  * @library /test/lib /
>> 36:  * @requires vm.compiler2.enabled
>> 37:  * @run driver compiler.c2.irTests.constantFold.IdentityHashCodeFold
> 
> Suggestion:
> 
>  * @run driver ${test.main.class}
> 
> Is the C2 requirement really necessary?

The C2 requirement is effective if a build configuration disables the compiler2 feature. I don't know if we run tests in such a build. I copied this from `compiler/c2/irTests/TestEnumFinalFold.java` in particular.

> test/hotspot/jtreg/compiler/c2/irTests/constantFold/IdentityHashCodeFold.java line 51:
> 
>> 49:     public int testSum() {
>> 50:         return a.hashCode() + System.identityHashCode(b);
>> 51:     }
> 
> This does not test correctness of the result. How confident are we that this patch is sufficiently tested?
> How can we test that the compiled and interpreter hashcode are equivalent?

I can't find a way to access the identity hash code without compilation. Would something like a method that calls System.identityHashCode but is not inlied work?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2607156541
PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2607151871

From liach at openjdk.org  Wed Dec 10 15:41:05 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 10 Dec 2025 15:41:05 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v9]
In-Reply-To: <FcLav5WxQpzUXuUVVjqCnl44iRF8rDACYssSokT0zZE=.bec8fe32-2d9b-49c1-904a-044a9361e3d5@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <4YumBpbA2k8DC13H1s808_5OJx-1FMxD9CbIUfRTb8Q=.742f90c9-0d93-43b7-abe7-76422a0c8359@github.com>
 <FcLav5WxQpzUXuUVVjqCnl44iRF8rDACYssSokT0zZE=.bec8fe32-2d9b-49c1-904a-044a9361e3d5@github.com>
Message-ID: <D-aRjXHF-4ULG3oRHz4gRb9zk14TWLKsUeyYv_gIv_8=.b1f70fe1-e673-4bae-915c-20edcbc4e1da@github.com>

On Wed, 10 Dec 2025 07:32:59 GMT, Emanuel Peter <epeter at openjdk.org> 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 17 additional commits since the last revision:
>> 
>>  - 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
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache
>>  - Revert void special case removal due to C2 shortage causing TestZGCBarrierElision::testAtomicThenAtomicAnotherField failure
>>  - Test from Jorn
>>  - Copyright years
>>  - Fix problem identified by Jorn
>>  - Rollback getAndAdd for now
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/bdc0543f...d734e8a6
>
> test/hotspot/jtreg/compiler/c2/irTests/constantFold/VarHandleMismatchedTypeFold.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.
> 
> We want to eventually migrate all tests from `c2/irTests` to more "topic based" directories, so it would be great if you already migrated them now, since you probably would know a better name/place now already ;)

What would be a good directory? I used `c2/irTests/constantFold` as a topic. Maybe you can find a more straightforward directory for constant folding verification.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2607162521

From fyang at openjdk.org  Wed Dec 10 16:12:28 2025
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 10 Dec 2025 16:12:28 GMT
Subject: RFR: 8373069: RISC-V: implement GHASH intrinsic
In-Reply-To: <zxCNQIhhidoKzHbxL0z8h_Tp1N8pCmlHNoJ2wx30XF8=.a3d8eb05-9a07-403e-a014-84c3bb32b001@github.com>
References: <zxCNQIhhidoKzHbxL0z8h_Tp1N8pCmlHNoJ2wx30XF8=.a3d8eb05-9a07-403e-a014-84c3bb32b001@github.com>
Message-ID: <wQsJrlfTFaGoXLwVCvikU6F8boxdk4j9TVlomGYCmH0=.4f3d2ec2-7efa-4892-bf85-98aec0e9a43e@github.com>

On Fri, 28 Nov 2025 03:54:29 GMT, Anjian Wen <wenanjian at openjdk.org> wrote:

> support GHASH intrinsic for crypt GCM, which need zvkg extension. 
> 
> passed the tests in 
> test/hotspot/jtreg/compiler/codegen/aes/
> test/jdk/com/sun/crypto

src/hotspot/cpu/riscv/assembler_riscv.hpp line 1989:

> 1987: 
> 1988:   // Vector GHASH (Zvkg) Extension
> 1989:   INSN(vgmul_vv, 0b1110111, 0b010, 0b10001, 0b1, 0b101000);

Seems not used anywhere?

src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 2857:

> 2855:     VectorRegister partial_hash = v29;
> 2856:     VectorRegister hash_subkey = v30;
> 2857:     VectorRegister cipher_text = v31;

Can we simply start from `v1` here?

src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 7109:

> 7107:     }
> 7108: 
> 7109:     if (UseGHASHIntrinsics && UseZvbb) {

Do we need to re-check `UseZvbb` here? `UseGHASHIntrinsics` will be disabled if we don't have `UseZvbb`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28548#discussion_r2607290431
PR Review Comment: https://git.openjdk.org/jdk/pull/28548#discussion_r2607281675
PR Review Comment: https://git.openjdk.org/jdk/pull/28548#discussion_r2607273308

From hgreule at openjdk.org  Wed Dec 10 16:13:42 2025
From: hgreule at openjdk.org (Hannes Greule)
Date: Wed, 10 Dec 2025 16:13:42 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v9]
In-Reply-To: <D-aRjXHF-4ULG3oRHz4gRb9zk14TWLKsUeyYv_gIv_8=.b1f70fe1-e673-4bae-915c-20edcbc4e1da@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <4YumBpbA2k8DC13H1s808_5OJx-1FMxD9CbIUfRTb8Q=.742f90c9-0d93-43b7-abe7-76422a0c8359@github.com>
 <FcLav5WxQpzUXuUVVjqCnl44iRF8rDACYssSokT0zZE=.bec8fe32-2d9b-49c1-904a-044a9361e3d5@github.com>
 <D-aRjXHF-4ULG3oRHz4gRb9zk14TWLKsUeyYv_gIv_8=.b1f70fe1-e673-4bae-915c-20edcbc4e1da@github.com>
Message-ID: <UI6TaTd_TAFzCA7YJDYnM1JEMXHXFqSxTDlEVht8WmE=.d003e695-43c1-43bf-940c-7c31aa35da45@github.com>

On Wed, 10 Dec 2025 15:38:12 GMT, Chen Liang <liach at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/c2/irTests/constantFold/VarHandleMismatchedTypeFold.java line 2:
>> 
>>> 1: /*
>>> 2:  * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.
>> 
>> We want to eventually migrate all tests from `c2/irTests` to more "topic based" directories, so it would be great if you already migrated them now, since you probably would know a better name/place now already ;)
>
> What would be a good directory? I used `c2/irTests/constantFold` as a topic. Maybe you can find a more straightforward directory for constant folding verification.

Maybe something like `c2/methodhandles` would be a good fit?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2607297537

From liach at openjdk.org  Wed Dec 10 16:38:21 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 10 Dec 2025 16:38:21 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v9]
In-Reply-To: <UI6TaTd_TAFzCA7YJDYnM1JEMXHXFqSxTDlEVht8WmE=.d003e695-43c1-43bf-940c-7c31aa35da45@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <4YumBpbA2k8DC13H1s808_5OJx-1FMxD9CbIUfRTb8Q=.742f90c9-0d93-43b7-abe7-76422a0c8359@github.com>
 <FcLav5WxQpzUXuUVVjqCnl44iRF8rDACYssSokT0zZE=.bec8fe32-2d9b-49c1-904a-044a9361e3d5@github.com>
 <D-aRjXHF-4ULG3oRHz4gRb9zk14TWLKsUeyYv_gIv_8=.b1f70fe1-e673-4bae-915c-20edcbc4e1da@github.com>
 <UI6TaTd_TAFzCA7YJDYnM1JEMXHXFqSxTDlEVht8WmE=.d003e695-43c1-43bf-940c-7c31aa35da45@github.com>
Message-ID: <7XWutFIFgBWASCLSHH0XdEurVGgfX14HwelxQttnbr8=.9d92b47a-3313-46c1-822d-79a55cfb7d04@github.com>

On Wed, 10 Dec 2025 16:11:07 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

>> What would be a good directory? I used `c2/irTests/constantFold` as a topic. Maybe you can find a more straightforward directory for constant folding verification.
>
> Maybe something like `c2/methodhandles` would be a good fit?

There is `compiler/jsr292` directory, that might work I think.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2607392582

From epeter at openjdk.org  Wed Dec 10 17:21:05 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 10 Dec 2025 17:21:05 GMT
Subject: RFR: 8372845: C2: Fold identity hash code if object is constant
 [v3]
In-Reply-To: <XpDpc28hjOioKUPvgyyCXCVkZLVeHL7GGmoEW5--1UE=.809ce0b3-8992-4f55-98a8-8834401597a5@github.com>
References: <KPNLohuiE3Os64ib8cPl8cyPUbmvzOF2y687qapKSgc=.cae21b9f-2fa9-4e78-a5ef-7912cf906dfa@github.com>
 <AqXlBQi24MmML3tltUJiZa0bEYzORazv9mVo41lrIP4=.13265855-6308-47d1-93f0-006bfe06fdfa@github.com>
 <cavp_9ZUlDCfuwg9Eyp8wDms7j5GOtSZPwYk-QYMbVI=.bfed4082-375e-4a52-a2a1-4071843b7550@github.com>
 <XpDpc28hjOioKUPvgyyCXCVkZLVeHL7GGmoEW5--1UE=.809ce0b3-8992-4f55-98a8-8834401597a5@github.com>
Message-ID: <6ip4JrJ4WiYEe6d2FA_WQ5dDjxAk2RPaPbwth4jNeJM=.43d7879d-89a4-434c-80ea-371c92581686@github.com>

On Wed, 10 Dec 2025 15:36:36 GMT, Chen Liang <liach at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/c2/irTests/constantFold/IdentityHashCodeFold.java line 37:
>> 
>>> 35:  * @library /test/lib /
>>> 36:  * @requires vm.compiler2.enabled
>>> 37:  * @run driver compiler.c2.irTests.constantFold.IdentityHashCodeFold
>> 
>> Suggestion:
>> 
>>  * @run driver ${test.main.class}
>> 
>> Is the C2 requirement really necessary?
>
> The C2 requirement is effective if a build configuration disables the compiler2 feature. I don't know if we run tests in such a build. I copied this from `compiler/c2/irTests/TestEnumFinalFold.java` in particular.

You can for example run it with C1 or Xint only. That would disable the test. Or someone runs it with Graal.
I would generally remove `@requires` from any test we can, to get more coverage.

>> test/hotspot/jtreg/compiler/c2/irTests/constantFold/IdentityHashCodeFold.java line 51:
>> 
>>> 49:     public int testSum() {
>>> 50:         return a.hashCode() + System.identityHashCode(b);
>>> 51:     }
>> 
>> This does not test correctness of the result. How confident are we that this patch is sufficiently tested?
>> How can we test that the compiled and interpreter hashcode are equivalent?
>
> I can't find a way to access the identity hash code without compilation. Would something like a method that calls System.identityHashCode but is not inlied work?

You could compute the result in the static initializer, it should therefore be computed in the interpreter. And then add a `@Check` method to compare the `testSum` value from the compiler.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2607542060
PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2607538782

From iklam at openjdk.org  Wed Dec 10 17:32:38 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 10 Dec 2025 17:32:38 GMT
Subject: RFR: 8373392: Replace CDS object subgraphs with
 @AOTSafeClassInitializer
In-Reply-To: <T2dpMbwbHVIMHigIEI971AnIIFeB7xpWmveNWxHn0w4=.b6e46ea4-a1a6-47b7-8bf4-0c0c81c1d912@github.com>
References: <nwFU9L_ngxAg_QtXjVq_IvhIxlnHj49sWV-qMUCS0YY=.4417a88a-c604-415f-b389-12a19938fed3@github.com>
 <T2dpMbwbHVIMHigIEI971AnIIFeB7xpWmveNWxHn0w4=.b6e46ea4-a1a6-47b7-8bf4-0c0c81c1d912@github.com>
Message-ID: <BDaPZ6gkZ_1Bgj73wiO8ZwatxNyt5nxSzu_yXeEYHWk=.40e6594a-018e-4778-8a7b-4b2a50d806f1@github.com>

On Wed, 10 Dec 2025 15:25:29 GMT, Chen Liang <liach at openjdk.org> wrote:

> Is IntegerCache.cache the only field that need to be adjusted according to system properties after loading from AOT archive?

I think so. The cache size for all other Number types are fixed and cannot be modified by the command-line.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28736#issuecomment-3638192576

From liach at openjdk.org  Wed Dec 10 17:39:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 10 Dec 2025 17:39:46 GMT
Subject: RFR: 8373392: Replace CDS object subgraphs with
 @AOTSafeClassInitializer
In-Reply-To: <nwFU9L_ngxAg_QtXjVq_IvhIxlnHj49sWV-qMUCS0YY=.4417a88a-c604-415f-b389-12a19938fed3@github.com>
References: <nwFU9L_ngxAg_QtXjVq_IvhIxlnHj49sWV-qMUCS0YY=.4417a88a-c604-415f-b389-12a19938fed3@github.com>
Message-ID: <SnsvxbACMDrUxVQHu5xUkSSGQPVJae2pOYtCCIykhfU=.ab0888de-9108-453c-b552-f94bc04bc8d9@github.com>

On Wed, 10 Dec 2025 09:31:37 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> In legacy CDS, Java objects used by certain classes are computed ahead of time using "object subgraphs"
> 
> https://github.com/openjdk/jdk/blob/1bbbce75c5e68429c2a32519eb3c36d964dcdf57/src/hotspot/share/cds/heapShared.cpp#L168-L171
> 
> Examples of subgraphs:
> 
> - `java.lang.Integer$IntegerCache::cache`
> - `jdk.internal.module.ArchivedBootLayer::bootLayer`
> 
> The implementation requires special code (in both Java and C++) to be executed when a CDS archive is created or loaded. As a result, we have an execution model that's difficult to implement/extend and the behavior is hard to understand.
> 
> To move towards the AOT Cache Snapshot Model ([JDK-8365645](https://bugs.openjdk.org/browse/JDK-8365645)) we should replace the subgraphs with the use of `@AOTSafeClassInitializer`, and if necessary, `@AOTRuntimeSetup`. This will simplify the current implementation, and make it possible to extend AOT-initializations to more core classes.
> 
> Note, the use of `@AOTSafeClassInitializer` requires `-XX:+AOTClassLinking`. For the time being, we retain the old CDS object subgraph code to cover the `-XX:-AOTClassLinking` cases. Such code will be marked with comments like `/* Legacy CDS archive support (to be deprecated) */`. All future AOT creation of Java objects will be done with  `@AOTSafeClassInitializer`.

The Java code changes look reasonable.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28736#pullrequestreview-3563746741

From qamai at openjdk.org  Wed Dec 10 17:40:43 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 10 Dec 2025 17:40:43 GMT
Subject: RFR: 8372779: C2: Disambiguate Node::adr_type for the IR graph
 [v3]
In-Reply-To: <opcUxZyR0Zd5FEpFYahlFYkovBw4CafX8tCrDWpSKZQ=.441ecb8a-35c4-4ca2-8dde-cb2d5db629e1@github.com>
References: <dEidZLl1MkM6TbAxS2FsitU70AYAahwzK9cun61wwV8=.ccdad883-5d8f-403e-a19f-40aef0f53b11@github.com>
 <KMe08qt3HwEW_ewxHKx20KerRqY2EP9ucNOLgRBKKcA=.fa352cdc-0f09-479e-9d6a-7c6a56bfb301@github.com>
 <opcUxZyR0Zd5FEpFYahlFYkovBw4CafX8tCrDWpSKZQ=.441ecb8a-35c4-4ca2-8dde-cb2d5db629e1@github.com>
Message-ID: <b-e9N1yiz6aeLaMnKM5Y_oTaGHXiOWURSdtU5JXRz9U=.6be16c0f-566a-4838-b8b2-05fb657654fb@github.com>

On Wed, 10 Dec 2025 13:18:48 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Merge branch 'master' into adrtype
>>  - store_to_memory does not emit MemBars
>>  - Disambiguate Node::adr_type
>
> @merykitty I can't promise that I'll review the PR yet. But I have an initial question:
> Since some cases were wrong, does that mean we can find reproducers for those cases? Because it may be worth backporting some cases, but we would first need to know if there are cases that actually are currently wrong.

@eme64 Thanks a lot for taking a look. Normally, those intrinsics are not exposed bare, so it is hard to misschedule them. But I can craft one, at least on my machine, it fails with only `--add-opens=java.base/java.lang=ALL-UNNAMED`

    import java.lang.invoke.MethodHandle;
    import java.lang.invoke.MethodHandles;
    import java.lang.invoke.MethodType;

    public class TestAntiDependency {
        static final MethodHandle COMPRESS_HANDLE;
        static {
            try {
                var lookup = MethodHandles.privateLookupIn(String.class, MethodHandles.lookup());
                Class<?> stringUtf16Class = lookup.findClass("java.lang.StringUTF16");
                COMPRESS_HANDLE = lookup.findStatic(stringUtf16Class, "compress", MethodType.methodType(int.class, char[].class, int.class, byte[].class, int.class, int.class));
            } catch (Exception e) {
                throw new RuntimeException(e);
            }
        }

        public static void main(String[] args) throws Throwable {
            for (int i = 0; i < 50000; i++) {
                if (test() != 0) {
                    throw new AssertionError();
                }
            }
        }

        static int test() throws Throwable {
            char[] src = new char[4];
            byte[] dst = new byte[4];

            int l = (int) COMPRESS_HANDLE.invokeExact(src, 0, dst, 0, 4);
            src[0] = 1;
            return dst[0];
        }
    }

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28570#issuecomment-3638228258

From qamai at openjdk.org  Wed Dec 10 17:45:10 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 10 Dec 2025 17:45:10 GMT
Subject: RFR: 8372779: C2: Disambiguate Node::adr_type for the IR graph
 [v3]
In-Reply-To: <KMe08qt3HwEW_ewxHKx20KerRqY2EP9ucNOLgRBKKcA=.fa352cdc-0f09-479e-9d6a-7c6a56bfb301@github.com>
References: <dEidZLl1MkM6TbAxS2FsitU70AYAahwzK9cun61wwV8=.ccdad883-5d8f-403e-a19f-40aef0f53b11@github.com>
 <KMe08qt3HwEW_ewxHKx20KerRqY2EP9ucNOLgRBKKcA=.fa352cdc-0f09-479e-9d6a-7c6a56bfb301@github.com>
Message-ID: <-Uq0PhdsB_FeQ6DCNRes_tvSzy0uJhKTD73OL26r2-4=.47ae2131-ad40-40b2-bddb-d306a386cffb@github.com>

On Sun, 7 Dec 2025 12:12:20 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> Currently, `Node::adr_type` is ambiguous. For some, it refers to the memory the node consumes, while for the others, it refer to the memory the node produces. This PR removes that ambiguity by introducing `Node::in_adr_type` and `Node::out_adr_type` that refer to those properties, respectively. It also introduces a local verification of the memory graph during compilation. These additions uncover some issues:
>> 
>> - Sometimes, the memory is wired incorrectly, such as in `LibraryCall::extend_setCurrentThread`, the `Phi` collect the `StoreNode`s instead of the whole memory state. I think these issues do not result in crashes or miscompilation, though.
>> - `AryEqNode` reports `adr_type` being `TypeAryPtr::BYTES` (it inherits this from `StrIntrinsicNode`). This is incorrect, however, as it can accept `char[]` inputs, too.
>> - For nodes such as `StrInflatedCopyNode`, as it consumes more than it produces, during scheduling, we need to compute anti-dependencies. This is not the case, so I fixed it by making it kill all the memory it consumes.
>> - `GraphKit::set_output_for_allocation` uses a raw `ProjNode` as the base for a `MergeMem`, this is really suspicious. I didn't fix it, as it seems to not result in any symptom at the moment.
>> 
>> In the end, the execution of the compiler is strictly more restricted than before, and there is less room for ambiguity.
>> 
>> Please take a look and leave your reviews, thanks a lot.
>
> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into adrtype
>  - store_to_memory does not emit MemBars
>  - Disambiguate Node::adr_type

For the other issues (`AryEqNode` advertises incorrect `adr_type` and `LibraryCall::extend_setCurrentThread` incorrectly wires the memory nodes), there is no immediate issue apart from incorrectly looking graph, so I have not come up with a real failure.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28570#issuecomment-3638245320

From mr at openjdk.org  Wed Dec 10 18:20:00 2025
From: mr at openjdk.org (Mark Reinhold)
Date: Wed, 10 Dec 2025 18:20:00 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v15]
In-Reply-To: <HiF5EwAj4DlTEOa85zqXgd2RbgbQjLNayJ6925N00ZU=.34ad1757-d497-4166-b9c7-745c8d82d228@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <HiF5EwAj4DlTEOa85zqXgd2RbgbQjLNayJ6925N00ZU=.34ad1757-d497-4166-b9c7-745c8d82d228@github.com>
Message-ID: <0-DIQXf7yQXROjQZ82p1StLcHJiN4WwJU5A-uW1CVqw=.437dde89-0136-4afe-8641-8580abbf0697@github.com>

On Wed, 3 Dec 2025 22:29:24 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
>> 
>> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
>> 
>> TRUE
>> FALSE
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporate feedback into documentation

Marked as reviewed by mr (Lead).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28010#pullrequestreview-3563912082

From ayang at openjdk.org  Wed Dec 10 18:34:50 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 10 Dec 2025 18:34:50 GMT
Subject: RFR: 8373449: Parallel: Obsolete deprecated PSChunkLargeArrays
Message-ID: <4Qgp_QW_5sreJ5W4srufeKwDQzAd1Ajn601diouyd3g=.2361b5f9-31c3-496f-9121-3df9abfc7bc4@github.com>

Obsolete a deprecated jvm flag. Its default value is `true`.

Test: tier1-3

-------------

Commit messages:
 - pgc-obsolete-array-chunk

Changes: https://git.openjdk.org/jdk/pull/28754/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28754&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373449
  Stats: 9 lines in 3 files changed: 1 ins; 6 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28754.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28754/head:pull/28754

PR: https://git.openjdk.org/jdk/pull/28754

From duke at openjdk.org  Wed Dec 10 18:41:32 2025
From: duke at openjdk.org (duke)
Date: Wed, 10 Dec 2025 18:41:32 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v15]
In-Reply-To: <HiF5EwAj4DlTEOa85zqXgd2RbgbQjLNayJ6925N00ZU=.34ad1757-d497-4166-b9c7-745c8d82d228@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <HiF5EwAj4DlTEOa85zqXgd2RbgbQjLNayJ6925N00ZU=.34ad1757-d497-4166-b9c7-745c8d82d228@github.com>
Message-ID: <abyii1o4tj07P6jyBf8GJK4rgSj0_1LAg8hr-tjM71M=.0baff849-cfac-4dd4-ab40-f85392471cf7@github.com>

On Wed, 3 Dec 2025 22:29:24 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
>> 
>> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
>> 
>> TRUE
>> FALSE
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporate feedback into documentation

@macarte 
Your change (at version 8b0e27f26b94eb3f9e0c18b542f54da85e784121) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28010#issuecomment-3638450580

From macarte at openjdk.org  Wed Dec 10 18:52:05 2025
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 10 Dec 2025 18:52:05 GMT
Subject: Integrated: 8369736 - Add management interface for AOT cache creation
In-Reply-To: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
Message-ID: <0BIvIWfOQcKWZkhKpzxB6uJQC3caaKvqEeBzi7WU5b4=.b7c9874b-c5c8-4fec-ab7b-28df8457d88a@github.com>

On Tue, 28 Oct 2025 01:17:57 GMT, Mat Carter <macarte at openjdk.org> wrote:

> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
> 
> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
> 
> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
> 
> TRUE
> FALSE
> 
> Passes tier1 on linux (x64) and windows (x64)

This pull request has now been integrated.

Changeset: 413f852b
Author:    Mat Carter <macarte at openjdk.org>
Committer: Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/413f852bdb4767b2a1c29431144616668888138d
Stats:     335 lines in 10 files changed: 332 ins; 0 del; 3 mod

8369736: Add management interface for AOT cache creation

Reviewed-by: mr, iklam, kevinw

-------------

PR: https://git.openjdk.org/jdk/pull/28010

From iklam at openjdk.org  Wed Dec 10 19:18:07 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 10 Dec 2025 19:18:07 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v15]
In-Reply-To: <HiF5EwAj4DlTEOa85zqXgd2RbgbQjLNayJ6925N00ZU=.34ad1757-d497-4166-b9c7-745c8d82d228@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <HiF5EwAj4DlTEOa85zqXgd2RbgbQjLNayJ6925N00ZU=.34ad1757-d497-4166-b9c7-745c8d82d228@github.com>
Message-ID: <IT6BSYlxvqy2lOZon0SewMkGwdEIlCwONU488cI5adU=.137c96b4-20f5-48f4-8793-22a932f61ed4@github.com>

On Wed, 3 Dec 2025 22:29:24 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
>> 
>> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
>> 
>> TRUE
>> FALSE
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporate feedback into documentation

FYI, I've added a request to include this in JDK 26.

- https://bugs.openjdk.org/browse/JDK-8369736?focusedId=14840372&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14840372

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28010#issuecomment-3638593964

From shade at openjdk.org  Wed Dec 10 19:19:22 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 10 Dec 2025 19:19:22 GMT
Subject: RFR: 8373266: Strengthen constant CardTable base accesses
Message-ID: <k38G94Tpq-aEKy5qzf8vaCMgcn0KHYw4JTWm0-RWgIQ=.5da23c7e-d826-41c2-b42f-ec2a90fd2213@github.com>

Shenandoah and G1 are using CardTable for most of its infrastructure, but flip the card tables as they go, and maintain the actual card table reference in TLS. As such, accessing card table base from assembler and compilers runs into risk of accidentally encoding the wrong card table base in generated code. 

Most of the current code avoids this trouble by carefully implementing their GC barriers to avoid touching shared parts where card table base constness is assumed. _Except_ for JVMCI, that reads the card table base for G1 barrier set, and that is wrong. The JVMCI users would need to rectify this downstream.

Shenandoah added a few asserts to catch these errors:
 SHENANDOAHGC_ONLY(assert(!UseShenandoahGC, "Shenandoah byte_map_base is not constant.");)

...but G1 would also benefit from the similar safety mechanism.

This PR strengthens the code to prevent future accidents.

Additional testing:
 - [x] Linux x86_64 server fastdebug, `hotspot_gc`
 - [x] Linux x86_64 server fastdebug, `tier1` with Serial, Parallel, G1, Shenandoah, Z
 - [x] Linux AArch64 server fastdebug, `tier1` with Serial, Parallel, G1, Shenandoah, Z
 - [x] GHA, cross-compilation only

-------------

Commit messages:
 - 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: https://git.openjdk.org/jdk/pull/28703/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28703&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373266
  Stats: 99 lines in 15 files changed: 35 ins; 25 del; 39 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 vlivanov at openjdk.org  Wed Dec 10 19:49:07 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 10 Dec 2025 19:49:07 GMT
Subject: RFR: 8372845: C2: Fold identity hash code if object is constant
 [v3]
In-Reply-To: <6ip4JrJ4WiYEe6d2FA_WQ5dDjxAk2RPaPbwth4jNeJM=.43d7879d-89a4-434c-80ea-371c92581686@github.com>
References: <KPNLohuiE3Os64ib8cPl8cyPUbmvzOF2y687qapKSgc=.cae21b9f-2fa9-4e78-a5ef-7912cf906dfa@github.com>
 <AqXlBQi24MmML3tltUJiZa0bEYzORazv9mVo41lrIP4=.13265855-6308-47d1-93f0-006bfe06fdfa@github.com>
 <cavp_9ZUlDCfuwg9Eyp8wDms7j5GOtSZPwYk-QYMbVI=.bfed4082-375e-4a52-a2a1-4071843b7550@github.com>
 <XpDpc28hjOioKUPvgyyCXCVkZLVeHL7GGmoEW5--1UE=.809ce0b3-8992-4f55-98a8-8834401597a5@github.com>
 <6ip4JrJ4WiYEe6d2FA_WQ5dDjxAk2RPaPbwth4jNeJM=.43d7879d-89a4-434c-80ea-371c92581686@github.com>
Message-ID: <r2gvtXpF9spuh0PGFRWFuKhgKSInOJ8UbZ2rWTNzLB8=.5f60583a-ee90-40b8-8826-8893fa7b8372@github.com>

On Wed, 10 Dec 2025 17:18:15 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> The C2 requirement is effective if a build configuration disables the compiler2 feature. I don't know if we run tests in such a build. I copied this from `compiler/c2/irTests/TestEnumFinalFold.java` in particular.
>
> You can for example run it with C1 or Xint only. That would disable the test. Or someone runs it with Graal.
> I would generally remove `@requires` from any test we can, to get more coverage.

It's a test on C2 IR. What's the point in running it w/o C2?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2608004982

From vlivanov at openjdk.org  Wed Dec 10 19:51:06 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 10 Dec 2025 19:51:06 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v9]
In-Reply-To: <4YumBpbA2k8DC13H1s808_5OJx-1FMxD9CbIUfRTb8Q=.742f90c9-0d93-43b7-abe7-76422a0c8359@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <4YumBpbA2k8DC13H1s808_5OJx-1FMxD9CbIUfRTb8Q=.742f90c9-0d93-43b7-abe7-76422a0c8359@github.com>
Message-ID: <dz1Gx2KnQQHRvxsEaMeX6y3q7peELc4vg3QJlPbWqdc=.83c80c74-b468-4ad5-b142-db08a588a74e@github.com>

On Mon, 8 Dec 2025 19:10:48 GMT, Chen Liang <liach at openjdk.org> 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 17 additional commits since the last revision:
> 
>  - 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
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache
>  - Revert void special case removal due to C2 shortage causing TestZGCBarrierElision::testAtomicThenAtomicAnotherField failure
>  - Test from Jorn
>  - Copyright years
>  - Fix problem identified by Jorn
>  - Rollback getAndAdd for now
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/8da6ec63...d734e8a6

make/jdk/src/classes/build/tools/methodhandle/VarHandleGuardMethodGenerator.java line 132:

> 130:     // TestZGCBarrierElision.testAtomicThenAtomicAnotherField fails
> 131:     // However, testArrayAtomicThenAtomic, testAtomicThenAtomic, and
> 132:     // testArrayAtomicThenAtomicAtUnknownIndices works

It doesn't look right. Was is the root cause of the failure? Can it be a test bug?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2608010297

From vlivanov at openjdk.org  Wed Dec 10 19:57:03 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 10 Dec 2025 19:57:03 GMT
Subject: RFR: 8357258: x86: Improve receiver type profiling reliability
 [v9]
In-Reply-To: <8N5F01Ve6BLQjlsJ7nD53xn70wa_NrRMqeuSb1Grp6M=.f45dd3b4-b282-41a8-a245-b7673bf65261@github.com>
References: <X9RJoDWqk67MlK7P4ACCbzROxLkfEqvU0zDid3zymnc=.7c0086a3-f514-4b0d-8bc0-592bf4a05bba@github.com>
 <8N5F01Ve6BLQjlsJ7nD53xn70wa_NrRMqeuSb1Grp6M=.f45dd3b4-b282-41a8-a245-b7673bf65261@github.com>
Message-ID: <m57oNroEfHSLq3id_IxpNqZdMoEFw9t0KTUKRw9JZFQ=.c3db6306-d265-40c7-8ca1-f0c0ea717a4e@github.com>

On Wed, 10 Dec 2025 08:33:30 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the bug for discussion what issues current machinery has. 
>> 
>> This PR executes the plan outlined in the bug:
>>  1. Common the receiver type profiling code in interpreter and C1
>>  2. Rewrite receiver type profiling code to only do atomic receiver slot installations
>>  3. Trim `C1OptimizeVirtualCallProfiling` to only claim slots when receiver is installed 
>> 
>> This PR does _not_ do atomic counter updates themselves, as it may have much wider performance implications, including regressions. This PR should be at least performance neutral.
>> 
>> Additional testing:
>>   - [x] Linux x86_64 server fastdebug, `compiler/`
>>   - [x] Linux x86_64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
> 
>  - 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
>  - Offset is always rscratch1, no need to save it
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/1bbbce75...c28810e3

Looks good.

Thanks for the clarifications, Aleksey. Just wanted to get a sense how much performance-wise we leave on the table and whether it is worth to spend more time on it later.

-------------

Marked as reviewed by vlivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25305#pullrequestreview-3564254380
PR Comment: https://git.openjdk.org/jdk/pull/25305#issuecomment-3638717818

From kvn at openjdk.org  Wed Dec 10 20:11:42 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 10 Dec 2025 20:11:42 GMT
Subject: RFR: 8357258: x86: Improve receiver type profiling reliability
 [v9]
In-Reply-To: <8N5F01Ve6BLQjlsJ7nD53xn70wa_NrRMqeuSb1Grp6M=.f45dd3b4-b282-41a8-a245-b7673bf65261@github.com>
References: <X9RJoDWqk67MlK7P4ACCbzROxLkfEqvU0zDid3zymnc=.7c0086a3-f514-4b0d-8bc0-592bf4a05bba@github.com>
 <8N5F01Ve6BLQjlsJ7nD53xn70wa_NrRMqeuSb1Grp6M=.f45dd3b4-b282-41a8-a245-b7673bf65261@github.com>
Message-ID: <bXPbFwhRmQHUmRvFCFhLqKhC0aWX-q0L_GN_Vqeq2_U=.ec9cbca9-e3fa-4db0-8d4e-58b38da7a12e@github.com>

On Wed, 10 Dec 2025 08:33:30 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the bug for discussion what issues current machinery has. 
>> 
>> This PR executes the plan outlined in the bug:
>>  1. Common the receiver type profiling code in interpreter and C1
>>  2. Rewrite receiver type profiling code to only do atomic receiver slot installations
>>  3. Trim `C1OptimizeVirtualCallProfiling` to only claim slots when receiver is installed 
>> 
>> This PR does _not_ do atomic counter updates themselves, as it may have much wider performance implications, including regressions. This PR should be at least performance neutral.
>> 
>> Additional testing:
>>   - [x] Linux x86_64 server fastdebug, `compiler/`
>>   - [x] Linux x86_64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
> 
>  - 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
>  - Offset is always rscratch1, no need to save it
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/1bbbce75...c28810e3

Yes, we can look on this later if we need to optimize it more. Thankfully it is in one place now.

I don't need to retest it since you didn't change code after v07 and only merged from mainline.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25305#pullrequestreview-3564300007

From dlong at openjdk.org  Wed Dec 10 20:22:30 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 10 Dec 2025 20:22:30 GMT
Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() [v6]
In-Reply-To: <CEvEqPtlTMiv7fX1G_spyCpyl8afEZn4McrzIBd5GRY=.d233254e-3626-4044-a3e1-c82bcbd55e45@github.com>
References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com>
 <CEvEqPtlTMiv7fX1G_spyCpyl8afEZn4McrzIBd5GRY=.d233254e-3626-4044-a3e1-c82bcbd55e45@github.com>
Message-ID: <NtMPMeCg0Pr3xvm6APh556G0XHh9ZuOJrX0ZhWqDRXM=.81294a86-b76f-4ed3-aa4b-d6afd72b09af@github.com>

On Mon, 8 Dec 2025 14:01:48 GMT, Fei Gao <fgao at openjdk.org> 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/681c5b52...415495da

My concern is that it appears possible to call `set_to_interpreted` multiple times in the lifecycle of the call site, and some of those times could have the entry point still patched to a branch instead of ISB, however set_to_interpreted seems to assume the entry point is an ISB and the comments use that assumption to argue for its correctness.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26638#issuecomment-3638814807

From dholmes at openjdk.org  Wed Dec 10 21:05:53 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 10 Dec 2025 21:05:53 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v15]
In-Reply-To: <HiF5EwAj4DlTEOa85zqXgd2RbgbQjLNayJ6925N00ZU=.34ad1757-d497-4166-b9c7-745c8d82d228@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <HiF5EwAj4DlTEOa85zqXgd2RbgbQjLNayJ6925N00ZU=.34ad1757-d497-4166-b9c7-745c8d82d228@github.com>
Message-ID: <X13ctyRpg3UL3UD_kvGh7OtXqeX7M4rH75L12fhwmro=.925e29a0-a26b-446d-b010-9912ecd80943@github.com>

On Wed, 3 Dec 2025 22:29:24 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
>> 
>> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
>> 
>> TRUE
>> FALSE
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporate feedback into documentation

This change has broken the "since" checker test: tools/sincechecker/modules/jdk.management/JdkManagementCheckSince.java

src/jdk.management/jdk/management/HotSpotAOTCacheMXBean.java:44 class: jdk.management.HotSpotAOTCacheMXBean: `@since` version: 26; should be: 27
src/jdk.management/jdk/management/HotSpotAOTCacheMXBean.java:92 method: boolean jdk.management.HotSpotAOTCacheMXBean.endRecording(): `@since` version: 26; should be: 27
java.lang.Exception: The `@since` checker found 2 problems

Bug being filed

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28010#issuecomment-3638949417

From asmehra at openjdk.org  Wed Dec 10 21:29:01 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Wed, 10 Dec 2025 21:29:01 GMT
Subject: RFR: 8373114: Redundant MethodCounters in the preimage generated
 by training run [v2]
In-Reply-To: <a85ZuRDWytfJs9yTAzrKUGZ1OM9AJEU9VLbNoCehJyI=.11694df2-ab91-421c-9ba4-f354a75fb0e5@github.com>
References: <LRw06Cn_4dcRW8YyFVr3RijMHIha7nPzBrcNNzaIny8=.dc07d0ee-b797-4434-aad0-956a00c2ea6f@github.com>
 <OSv1Smz_pkBiU7bXuzTOTIKkMug1zITyptuLPXDCfmA=.26ac46ce-0991-48be-a845-dc86b3ccde60@github.com>
 <YebtWBu7SiOoPufA0CSEP1llirgcQ8Zp2vfps4vY0uI=.bb6d5f29-b5cf-4657-bb72-d8d65a0ea034@github.com>
 <a85ZuRDWytfJs9yTAzrKUGZ1OM9AJEU9VLbNoCehJyI=.11694df2-ab91-421c-9ba4-f354a75fb0e5@github.com>
Message-ID: <TDLmwaf-hbLghg2-meetZwaHt3u08edaU1O-pnBsGC0=.99ea1cbf-d76d-41f2-a63d-6b4a2683d0f1@github.com>

On Wed, 10 Dec 2025 06:35:33 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> > Another approach I thought of was to add the filtering in ArchiveBuilder::get_follow_mode such that only the MethodCounters referenced by MTDs are stored in the AOTCache. It is possible to get the enclosing MetaspaceObj for the MetaspaceClosure::Ref passed to get_follow_mode but I couldn't find an easy way to get the type of the enclosing object, which makes it difficult to check if the MethodCounters being added came from Method or MTD.

> 
> Hi Ashutosh, I've created a patch for finding the type of the enclosing obj:
> 
> https://github.com/iklam/jdk/commit/cef9437484e119fde1b4eb07a809b33d83e35bdd
> 
> Could you try to see if that works for you?
> 

@iklam thanks for the changes. This is indeed what I wanted and updated the patch with the following change:

          address enclosing_obj = ref->enclosing_obj();
          if (ref->enclosing_obj_msotype() == MetaspaceObj::MethodTrainingDataType) {
            return make_a_copy;
          }

But it seems like this is not sufficient.  With this approach number of MethodCounters are only 1142 while the MTDs are around 4k. This is because in `ArchiveBuilder::gather_one_source_obj` the MCs that are first reached from Method get stored in the `_src_obj_table` with `_follow_mode=set_to_null`. Subsequent visits to such MCs through MTDs are ignored.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28670#issuecomment-3639025756

From kvn at openjdk.org  Wed Dec 10 21:30:09 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 10 Dec 2025 21:30:09 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v15]
In-Reply-To: <HiF5EwAj4DlTEOa85zqXgd2RbgbQjLNayJ6925N00ZU=.34ad1757-d497-4166-b9c7-745c8d82d228@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <HiF5EwAj4DlTEOa85zqXgd2RbgbQjLNayJ6925N00ZU=.34ad1757-d497-4166-b9c7-745c8d82d228@github.com>
Message-ID: <LEJm3sKWe3Rkb-JadJ1BgoqpLZWiDc2psjfkHVNgdH0=.c2ca2cc8-fa90-4355-8f27-4b190812f596@github.com>

On Wed, 3 Dec 2025 22:29:24 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
>> 
>> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
>> 
>> TRUE
>> FALSE
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporate feedback into documentation

At least current code will be simple to backport to 26.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28010#issuecomment-3639029804

From liach at openjdk.org  Wed Dec 10 22:11:49 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 10 Dec 2025 22:11:49 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v9]
In-Reply-To: <dz1Gx2KnQQHRvxsEaMeX6y3q7peELc4vg3QJlPbWqdc=.83c80c74-b468-4ad5-b142-db08a588a74e@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <4YumBpbA2k8DC13H1s808_5OJx-1FMxD9CbIUfRTb8Q=.742f90c9-0d93-43b7-abe7-76422a0c8359@github.com>
 <dz1Gx2KnQQHRvxsEaMeX6y3q7peELc4vg3QJlPbWqdc=.83c80c74-b468-4ad5-b142-db08a588a74e@github.com>
Message-ID: <jWUg1PcHY-3f02g350EMzhd6fYEp-4SxVcw51oRrs9s=.3fcc1b25-1086-42a8-876b-fa991840e247@github.com>

On Wed, 10 Dec 2025 19:48:49 GMT, Vladimir Ivanov <vlivanov at openjdk.org> 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 17 additional commits since the last revision:
>> 
>>  - 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
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache
>>  - Revert void special case removal due to C2 shortage causing TestZGCBarrierElision::testAtomicThenAtomicAnotherField failure
>>  - Test from Jorn
>>  - Copyright years
>>  - Fix problem identified by Jorn
>>  - Rollback getAndAdd for now
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/f510a486...d734e8a6
>
> make/jdk/src/classes/build/tools/methodhandle/VarHandleGuardMethodGenerator.java line 132:
> 
>> 130:     // TestZGCBarrierElision.testAtomicThenAtomicAnotherField fails
>> 131:     // However, testArrayAtomicThenAtomic, testAtomicThenAtomic, and
>> 132:     // testArrayAtomicThenAtomicAtUnknownIndices works
> 
> It doesn't look right. What is the root cause of the failure? Can it be a test bug?

I think that is when two different VarHandles are both invoked non-exactly in two call sites in one method, the 2nd one fails to be inlined, that the compare-and-exchange from the 2nd one is not present in the final IR. The deoptimization reason is either "unstable-if" or "too many null checks", I think I will try look into it in another effort.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2608390544

From vlivanov at openjdk.org  Wed Dec 10 22:16:22 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 10 Dec 2025 22:16:22 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v9]
In-Reply-To: <jWUg1PcHY-3f02g350EMzhd6fYEp-4SxVcw51oRrs9s=.3fcc1b25-1086-42a8-876b-fa991840e247@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <4YumBpbA2k8DC13H1s808_5OJx-1FMxD9CbIUfRTb8Q=.742f90c9-0d93-43b7-abe7-76422a0c8359@github.com>
 <dz1Gx2KnQQHRvxsEaMeX6y3q7peELc4vg3QJlPbWqdc=.83c80c74-b468-4ad5-b142-db08a588a74e@github.com>
 <jWUg1PcHY-3f02g350EMzhd6fYEp-4SxVcw51oRrs9s=.3fcc1b25-1086-42a8-876b-fa991840e247@github.com>
Message-ID: <RCay8vN8lKss9VF4kH0GiyQVeTn7LeUap2K8zq7zK-M=.88e751ba-ae5f-4736-a418-0824936de8db@github.com>

On Wed, 10 Dec 2025 22:09:21 GMT, Chen Liang <liach at openjdk.org> wrote:

>> make/jdk/src/classes/build/tools/methodhandle/VarHandleGuardMethodGenerator.java line 132:
>> 
>>> 130:     // TestZGCBarrierElision.testAtomicThenAtomicAnotherField fails
>>> 131:     // However, testArrayAtomicThenAtomic, testAtomicThenAtomic, and
>>> 132:     // testArrayAtomicThenAtomicAtUnknownIndices works
>> 
>> It doesn't look right. What is the root cause of the failure? Can it be a test bug?
>
> I think that is when two different VarHandles are both invoked non-exactly in two call sites in one method, the 2nd one fails to be inlined, that the compare-and-exchange from the 2nd one is not present in the final IR. The deoptimization reason is either "unstable-if" or "too many null checks", I think I will try look into it in another effort.

If it's a test problem, then it's better to comment out the problematic test case instead.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2608398869

From kbarrett at openjdk.org  Wed Dec 10 22:30:27 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 10 Dec 2025 22:30:27 GMT
Subject: RFR: 8372754: Add wrapper for <cstdlib>
Message-ID: <7QNN5i5DkBH7c9YXWh5U40JwTKmiBPJSAcLm-f1HE_8=.9b18027e-8274-46d1-ba2d-e70514c40fc3@github.com>

Please review this change that adds a HotSpot wrapper for <cstdlib>.  It also
includes the forbidden function declarations for functions declared there,
moving them from forbiddenFunctions.hpp and friends.

The AIX-specific workaround for its macro-based renaming of malloc/calloc is
also moved to this wrapper, so there is a single location for it. Also cleaned
it up a bit, based on further investigation of the problem.

Also changed uses of <cstdlib> and <stdlib.h> to include the wrapper instead.
There are still a couple of includes of <stdlib.h> in the hotspot directory,
because they can't use the hotspot wrapper: os/windows/include/jvm_md.h and
share/adlc/adlc.hpp.  I looked at removing the one in windows jvm_md.h, but
there are a lot of dependencies on that implicit include in non-HotSpot code.

While updating to use the wrapper, I also did a small amount of include
cleanup here and there.  The changes around immediate_aarch64.hpp are perhaps
a little less trivial than I should have made here.

Testing: mach5 tier1

This should probably be retested by aix port maintainer folks, although I
don't think I made any relevant changes since you last tested it.

This change also resolves:

-------------

Commit messages:
 - add wrapper for <cstdlib>

Changes: https://git.openjdk.org/jdk/pull/28562/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28562&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372754
  Stats: 221 lines in 34 files changed: 152 ins; 59 del; 10 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 jwaters at openjdk.org  Wed Dec 10 22:30:27 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 10 Dec 2025 22:30:27 GMT
Subject: RFR: 8372754: Add wrapper for <cstdlib>
In-Reply-To: <7QNN5i5DkBH7c9YXWh5U40JwTKmiBPJSAcLm-f1HE_8=.9b18027e-8274-46d1-ba2d-e70514c40fc3@github.com>
References: <7QNN5i5DkBH7c9YXWh5U40JwTKmiBPJSAcLm-f1HE_8=.9b18027e-8274-46d1-ba2d-e70514c40fc3@github.com>
Message-ID: <McwAxDk5pmIx-rQfU1QXaxVk_YGkoykqhL-4P9oz4YM=.8a5c7b88-00ac-4198-bb4e-bea41f7e42ca@github.com>

On Sat, 29 Nov 2025 05:09:49 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that adds a HotSpot wrapper for <cstdlib>.  It also
> includes the forbidden function declarations for functions declared there,
> moving them from forbiddenFunctions.hpp and friends.
> 
> The AIX-specific workaround for its macro-based renaming of malloc/calloc is
> also moved to this wrapper, so there is a single location for it. Also cleaned
> it up a bit, based on further investigation of the problem.
> 
> Also changed uses of <cstdlib> and <stdlib.h> to include the wrapper instead.
> There are still a couple of includes of <stdlib.h> in the hotspot directory,
> because they can't use the hotspot wrapper: os/windows/include/jvm_md.h and
> share/adlc/adlc.hpp.  I looked at removing the one in windows jvm_md.h, but
> there are a lot of dependencies on that implicit include in non-HotSpot code.
> 
> While updating to use the wrapper, I also did a small amount of include
> cleanup here and there.  The changes around immediate_aarch64.hpp are perhaps
> a little less trivial than I should have made here.
> 
> Testing: mach5 tier1
> 
> This should probably be retested by aix port maintainer folks, although I
> don't think I made any relevant changes since you last tested it.
> 
> This change also resolves:

Are we using wrappers for C Standard Library headers as well now?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28562#issuecomment-3591035059

From aleonard at openjdk.org  Wed Dec 10 22:30:27 2025
From: aleonard at openjdk.org (Andrew Leonard)
Date: Wed, 10 Dec 2025 22:30:27 GMT
Subject: RFR: 8372754: Add wrapper for <cstdlib>
In-Reply-To: <7QNN5i5DkBH7c9YXWh5U40JwTKmiBPJSAcLm-f1HE_8=.9b18027e-8274-46d1-ba2d-e70514c40fc3@github.com>
References: <7QNN5i5DkBH7c9YXWh5U40JwTKmiBPJSAcLm-f1HE_8=.9b18027e-8274-46d1-ba2d-e70514c40fc3@github.com>
Message-ID: <LEXW4IuhUuf7ew4gREH2bOSW1CcH_JeaTXWjSiTibBY=.cd74c411-0ab3-4c73-b853-07ddf61f1a5d@github.com>

On Sat, 29 Nov 2025 05:09:49 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that adds a HotSpot wrapper for <cstdlib>.  It also
> includes the forbidden function declarations for functions declared there,
> moving them from forbiddenFunctions.hpp and friends.
> 
> The AIX-specific workaround for its macro-based renaming of malloc/calloc is
> also moved to this wrapper, so there is a single location for it. Also cleaned
> it up a bit, based on further investigation of the problem.
> 
> Also changed uses of <cstdlib> and <stdlib.h> to include the wrapper instead.
> There are still a couple of includes of <stdlib.h> in the hotspot directory,
> because they can't use the hotspot wrapper: os/windows/include/jvm_md.h and
> share/adlc/adlc.hpp.  I looked at removing the one in windows jvm_md.h, but
> there are a lot of dependencies on that implicit include in non-HotSpot code.
> 
> While updating to use the wrapper, I also did a small amount of include
> cleanup here and there.  The changes around immediate_aarch64.hpp are perhaps
> a little less trivial than I should have made here.
> 
> Testing: mach5 tier1
> 
> This should probably be retested by aix port maintainer folks, although I
> don't think I made any relevant changes since you last tested it.
> 
> This change also resolves:

@kimbarrett I've successfully built Temurin on our AIX 7.2 ndoe with this patch, many thanks https://ci.adoptium.net/job/build-scripts/job/jobs/job/jdk/job/jdk-aix-ppc64-temurin/457/console

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28562#issuecomment-3597717364

From kbarrett at openjdk.org  Wed Dec 10 22:30:28 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 10 Dec 2025 22:30:28 GMT
Subject: RFR: 8372754: Add wrapper for <cstdlib>
In-Reply-To: <McwAxDk5pmIx-rQfU1QXaxVk_YGkoykqhL-4P9oz4YM=.8a5c7b88-00ac-4198-bb4e-bea41f7e42ca@github.com>
References: <7QNN5i5DkBH7c9YXWh5U40JwTKmiBPJSAcLm-f1HE_8=.9b18027e-8274-46d1-ba2d-e70514c40fc3@github.com>
 <McwAxDk5pmIx-rQfU1QXaxVk_YGkoykqhL-4P9oz4YM=.8a5c7b88-00ac-4198-bb4e-bea41f7e42ca@github.com>
Message-ID: <y4oaOLAGdv1JwX9wHb6UxSbFwmjtEQmQ72LvZMVH5rA=.198ebd7a-b0d3-4fa0-ad63-fb0343f38526@github.com>

On Sat, 29 Nov 2025 06:13:10 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Are we using wrappers for C Standard Library headers as well now?

For those with corresponding C++ headers, yes.  Those .h files were deprecated
forever, but then in some more recent C++ Standard they were undeprecated but
described as being intented for use only in code that was intended to be valid
as both C and C++.

I'm thinking we might want to introduce wrappers for at least some other C
library headers, again as a shared place HotSpot-specific tailoring.  But
that's something for (possibly much) later.  First working through the C++
Standard Library headers.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28562#issuecomment-3639208533

From kbarrett at openjdk.org  Wed Dec 10 22:31:51 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 10 Dec 2025 22:31:51 GMT
Subject: RFR: 8372754: Add wrapper for <cstdlib>
In-Reply-To: <7QNN5i5DkBH7c9YXWh5U40JwTKmiBPJSAcLm-f1HE_8=.9b18027e-8274-46d1-ba2d-e70514c40fc3@github.com>
References: <7QNN5i5DkBH7c9YXWh5U40JwTKmiBPJSAcLm-f1HE_8=.9b18027e-8274-46d1-ba2d-e70514c40fc3@github.com>
Message-ID: <f6YtaY2EuY3jzzOyXTQhyeLZfF7w5BhXrKwq8iA9MEk=.3a9aa58c-6a29-4ae8-8b04-0d3e7c89e9aa@github.com>

On Sat, 29 Nov 2025 05:09:49 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that adds a HotSpot wrapper for <cstdlib>.  It also
> includes the forbidden function declarations for functions declared there,
> moving them from forbiddenFunctions.hpp and friends.
> 
> The AIX-specific workaround for its macro-based renaming of malloc/calloc is
> also moved to this wrapper, so there is a single location for it. Also cleaned
> it up a bit, based on further investigation of the problem.
> 
> Also changed uses of <cstdlib> and <stdlib.h> to include the wrapper instead.
> There are still a couple of includes of <stdlib.h> in the hotspot directory,
> because they can't use the hotspot wrapper: os/windows/include/jvm_md.h and
> share/adlc/adlc.hpp.  I looked at removing the one in windows jvm_md.h, but
> there are a lot of dependencies on that implicit include in non-HotSpot code.
> 
> While updating to use the wrapper, I also did a small amount of include
> cleanup here and there.  The changes around immediate_aarch64.hpp are perhaps
> a little less trivial than I should have made here.
> 
> Testing: mach5 tier1
> 
> This should probably be retested by aix port maintainer folks, although I
> don't think I made any relevant changes since you last tested it.
> 
> This change also resolves:

src/hotspot/share/cppstdlib/cstdlib.hpp line 70:

> 68: // namespace, macro replacement causes the expanded names to be added instead
> 69: // of the intended names. We can't remove std::vec_malloc and std::vec_calloc,
> 70: // but we do add the standard names in case someone uses them.

We might be able to avoid this mess by first including `<stdlib.h>`, then remove the macros, and
then include `<cstdlib>`.  But hopefully we won't have to wait forever to just retire this whole
workaround.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28562#discussion_r2608437303

From syan at openjdk.org  Thu Dec 11 01:57:58 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 11 Dec 2025 01:57:58 GMT
Subject: RFR: 8371948: TestStackOverflowDuringInit.java fails xss too small
 on linux-aarch64 [v5]
In-Reply-To: <P6KhJ0rZttqTHVxuVi_POYRVmy2oGpaUj03Gnz3LXOQ=.9449af19-abc3-44ad-99e9-6e70ce008e3c@github.com>
References: <P6KhJ0rZttqTHVxuVi_POYRVmy2oGpaUj03Gnz3LXOQ=.9449af19-abc3-44ad-99e9-6e70ce008e3c@github.com>
Message-ID: <L1U5kByReJGXcxHMZG21t0teqI3WH4sh59saejQwryA=.d95f42e9-6e53-4755-8a2f-36c6732aa86b@github.com>

> Hi all,
> 
> On linux-aarch64, when page size is 64K, the minimal java thread stack size is 448K. So this PR increase the minimal java thread stack size in test/hotspot/jtreg/runtime/ClassInitErrors/TestStackOverflowDuringInit.java. Below is the calculation formula for the minimal java thread stack size:
> 
> 
> page_size = 64K
> _java_thread_min_stack_allowed = 72K
> _stack_red_zone_size = align_up(StackRedPages * unit, page_size) = align_up(1*4K, 64K) = 64K
> _stack_yellow_zone_size = align_up(StackYellowPages * unit, page_size) = align_up(2*4K, 64K) = 64K
> _stack_reserved_zone_size = align_up(StackReservedPages * unit, page_size) = align_up(1*4K, 64K) = 64K
> _stack_shadow_zone_size = align_up(StackShadowPages * unit, page_size) = align_up(25*4K, 64K) = 128K
> _java_thread_min_stack_allowed = align_up(72K+64K+64K+64K+128K, 64K) = 448K
> 
> 
> This PR add whitebox API getMinimumJavaStackSize() to the the allowd minimum java stack size, and get the allowed minimum java stack size in test/hotspot/jtreg/runtime/ClassInitErrors/TestStackOverflowDuringInit.java
> 
> Change has been verified locally both on linux-x64 and linux-aarch64.

SendaoYan has updated the pull request incrementally with two additional commits since the last revision:

 - remove test/hotspot/jtreg/runtime/memory/ReadMinimumJavaStackSize.java
 - Use get_minimum_java_stack_size instead of get_minimum_java_stack_sizes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28352/files
  - new: https://git.openjdk.org/jdk/pull/28352/files/f45cc0cb..ee8c621f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28352&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28352&range=03-04

  Stats: 51 lines in 5 files changed: 0 ins; 46 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/28352.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28352/head:pull/28352

PR: https://git.openjdk.org/jdk/pull/28352

From syan at openjdk.org  Thu Dec 11 02:11:25 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 11 Dec 2025 02:11:25 GMT
Subject: RFR: 8371948: TestStackOverflowDuringInit.java fails xss too small
 on linux-aarch64 [v4]
In-Reply-To: <ThFvEVtNoDMmmkPDUg9eo3FHNRfkoi-CHNWon5Y3U6E=.b7ef3a2e-0dec-4f87-838e-90346ce7ddd4@github.com>
References: <P6KhJ0rZttqTHVxuVi_POYRVmy2oGpaUj03Gnz3LXOQ=.9449af19-abc3-44ad-99e9-6e70ce008e3c@github.com>
 <BWTwLbEacLAJd4lHyvIlwJSU_3H-8kYp7dbEMku5leA=.d8fcbea1-a8b8-449b-8f14-ccbbbd924291@github.com>
 <ThFvEVtNoDMmmkPDUg9eo3FHNRfkoi-CHNWon5Y3U6E=.b7ef3a2e-0dec-4f87-838e-90346ce7ddd4@github.com>
Message-ID: <7kVq0fx3slrYGIW-Q6lwPw92gELG0E7BmhjVgAGc_8w=.75d74468-ee41-4e4d-a038-1645616fe778@github.com>

On Wed, 10 Dec 2025 07:46:27 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use jlong instead of jint
>
> src/hotspot/share/runtime/os.cpp line 2580:
> 
>> 2578: }
>> 2579: 
>> 2580: jlong os::get_minimum_java_stack_sizes() {
> 
> Suggestion:
> 
> jlong os::get_minimum_java_stack_size() {

Fixed.

> src/hotspot/share/runtime/os.hpp line 394:
> 
>> 392:  public:
>> 393:   // get allowed minimum java stack sizes
>> 394:   static jlong get_minimum_java_stack_sizes();
> 
> Suggestion:
> 
>   // get allowed minimum java stack size
>   static jlong get_minimum_java_stack_size();

Thanks. `get_minimum_java_stack_sizes` has been replaced as `get_minimum_java_stack_size`.

> test/hotspot/jtreg/runtime/memory/ReadMinimumJavaStackSize.java line 1:
> 
>> 1: /*
> 
> We don't need a test to exercise the WhiteBox API explicitly.

Okey. The new test test/hotspot/jtreg/runtime/memory/ReadMinimumJavaStackSize.java has been removed.

> test/lib/jdk/test/whitebox/WhiteBox.java line 80:
> 
>> 78:   public native long getHeapSpaceAlignment();
>> 79:   public native long getHeapAlignment();
>> 80:   public native long  getMinimumJavaStackSize();
> 
> Suggestion:
> 
>   public native long getMinimumJavaStackSize();

Thanks. Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28352#discussion_r2608861966
PR Review Comment: https://git.openjdk.org/jdk/pull/28352#discussion_r2608861218
PR Review Comment: https://git.openjdk.org/jdk/pull/28352#discussion_r2608863514
PR Review Comment: https://git.openjdk.org/jdk/pull/28352#discussion_r2608862645

From wenanjian at openjdk.org  Thu Dec 11 02:36:01 2025
From: wenanjian at openjdk.org (Anjian Wen)
Date: Thu, 11 Dec 2025 02:36:01 GMT
Subject: RFR: 8373069: RISC-V: implement GHASH intrinsic [v2]
In-Reply-To: <zxCNQIhhidoKzHbxL0z8h_Tp1N8pCmlHNoJ2wx30XF8=.a3d8eb05-9a07-403e-a014-84c3bb32b001@github.com>
References: <zxCNQIhhidoKzHbxL0z8h_Tp1N8pCmlHNoJ2wx30XF8=.a3d8eb05-9a07-403e-a014-84c3bb32b001@github.com>
Message-ID: <MvXHqGrKnnXeOqhmNqgGaUofs1bOaFSrVbeSgDvoMU8=.66a53405-632f-476b-861b-decba4db98e9@github.com>

> support GHASH intrinsic for crypt GCM, which need zvkg extension. 
> 
> passed the tests in 
> test/hotspot/jtreg/compiler/codegen/aes/
> test/jdk/com/sun/crypto

Anjian Wen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge branch 'openjdk:master' into ghash_intrinsic
 - Add some flag
 - RISC-V: implement GHASH intrinsic

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28548/files
  - new: https://git.openjdk.org/jdk/pull/28548/files/a0392dda..b59700b0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28548&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28548&range=00-01

  Stats: 25244 lines in 213 files changed: 16836 ins; 7396 del; 1012 mod
  Patch: https://git.openjdk.org/jdk/pull/28548.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28548/head:pull/28548

PR: https://git.openjdk.org/jdk/pull/28548

From wenanjian at openjdk.org  Thu Dec 11 02:46:09 2025
From: wenanjian at openjdk.org (Anjian Wen)
Date: Thu, 11 Dec 2025 02:46:09 GMT
Subject: RFR: 8373069: RISC-V: implement GHASH intrinsic [v3]
In-Reply-To: <zxCNQIhhidoKzHbxL0z8h_Tp1N8pCmlHNoJ2wx30XF8=.a3d8eb05-9a07-403e-a014-84c3bb32b001@github.com>
References: <zxCNQIhhidoKzHbxL0z8h_Tp1N8pCmlHNoJ2wx30XF8=.a3d8eb05-9a07-403e-a014-84c3bb32b001@github.com>
Message-ID: <1CV70nG2aoOVmc0tRt0Nw-BnUXfjeqync-0RxuVfya0=.ff36c52a-b468-410e-a602-a472f125848c@github.com>

> support GHASH intrinsic for crypt GCM, which need zvkg extension. 
> 
> passed the tests in 
> test/hotspot/jtreg/compiler/codegen/aes/
> test/jdk/com/sun/crypto

Anjian Wen has updated the pull request incrementally with one additional commit since the last revision:

  modify some format and change name

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28548/files
  - new: https://git.openjdk.org/jdk/pull/28548/files/b59700b0..fc63cb77

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28548&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28548&range=01-02

  Stats: 6 lines in 2 files changed: 0 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/28548.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28548/head:pull/28548

PR: https://git.openjdk.org/jdk/pull/28548

From wenanjian at openjdk.org  Thu Dec 11 02:46:09 2025
From: wenanjian at openjdk.org (Anjian Wen)
Date: Thu, 11 Dec 2025 02:46:09 GMT
Subject: RFR: 8373069: RISC-V: implement GHASH intrinsic [v3]
In-Reply-To: <wQsJrlfTFaGoXLwVCvikU6F8boxdk4j9TVlomGYCmH0=.4f3d2ec2-7efa-4892-bf85-98aec0e9a43e@github.com>
References: <zxCNQIhhidoKzHbxL0z8h_Tp1N8pCmlHNoJ2wx30XF8=.a3d8eb05-9a07-403e-a014-84c3bb32b001@github.com>
 <wQsJrlfTFaGoXLwVCvikU6F8boxdk4j9TVlomGYCmH0=.4f3d2ec2-7efa-4892-bf85-98aec0e9a43e@github.com>
Message-ID: <P8A0DvXdYorUQa8fRVDLRhOfi-oluA1aKbsBG64jYW4=.b7fea5df-c6c6-441f-8ba2-a4fd6ea7e840@github.com>

On Wed, 10 Dec 2025 16:09:09 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Anjian Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   modify some format and change name
>
> src/hotspot/cpu/riscv/assembler_riscv.hpp line 1989:
> 
>> 1987: 
>> 1988:   // Vector GHASH (Zvkg) Extension
>> 1989:   INSN(vgmul_vv, 0b1110111, 0b010, 0b10001, 0b1, 0b101000);
> 
> Seems not used anywhere?

yes, I don't use it in this patch, it is one of the zvkg ins, maybe we can enable it later when we need it and I have move it.

> src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 2857:
> 
>> 2855:     VectorRegister partial_hash = v29;
>> 2856:     VectorRegister hash_subkey = v30;
>> 2857:     VectorRegister cipher_text = v31;
> 
> Can we simply start from `v1` here?

sure, we can use v1 here, done

> src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 7109:
> 
>> 7107:     }
>> 7108: 
>> 7109:     if (UseGHASHIntrinsics && UseZvbb) {
> 
> Do we need to re-check `UseZvbb` here? `UseGHASHIntrinsics` will be disabled if we don't have `UseZvbb`.

yes, fixed it

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28548#discussion_r2608913077
PR Review Comment: https://git.openjdk.org/jdk/pull/28548#discussion_r2608909648
PR Review Comment: https://git.openjdk.org/jdk/pull/28548#discussion_r2608910567

From jwaters at openjdk.org  Thu Dec 11 04:16:35 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 11 Dec 2025 04:16:35 GMT
Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v17]
In-Reply-To: <bQTvyHEmPdxFBDWwSOKMc3802ERzj_kNrtzaD3E-EsU=.d7295faa-6934-4cd1-81fd-8f25e0ca3757@github.com>
References: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
 <bQTvyHEmPdxFBDWwSOKMc3802ERzj_kNrtzaD3E-EsU=.d7295faa-6934-4cd1-81fd-8f25e0ca3757@github.com>
Message-ID: <SPHKePbhy-ODhlbbofkmX15aqCzAg2fxgNJs6ZeXTvQ=.486d36cd-940d-4fc5-ad2f-9199f0407967@github.com>

On Tue, 11 Nov 2025 13:01:23 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Several areas in HotSpot are broken in the gcc port. These, with the exception of 1 rather big oversight within SharedRuntime::frem and SharedRuntime::drem, are all minor correctness issues within the code. These mostly can be fixed with simple changes to the code. Note that I am not sure whether the SharedRuntime::frem and SharedRuntime::drem fix is correct. It may be that they can be removed entirely
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 30 commits:
> 
>  - Merge branch 'master' into hotspot
>  - CAST_FROM_FN_PTR in os_windows.cpp
>  - Merge branch 'master' into hotspot
>  - Merge branch 'openjdk:master' into hotspot
>  - _WINDOWS && AARCH64 in sharedRuntime.hpp
>  - AARCH64 in sharedRuntimeRem.cpp
>  - Refactor sharedRuntime.cpp
>  - CAST_FROM_FN_PTR in os_windows.cpp
>  - Merge branch 'openjdk:master' into hotspot
>  - fmod_winarm64 in sharedRuntime.cpp
>  - ... and 20 more: https://git.openjdk.org/jdk/compare/29100320...b93febb3

Note for anyone looking in: I'm intentionally not progressing this change until the broken fmod in the Visual Studio library is fixed, so we can avoid pushing the workaround in, which I'm not very fond of in the first place.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21627#issuecomment-3640007841

From jwaters at openjdk.org  Thu Dec 11 04:16:36 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 11 Dec 2025 04:16:36 GMT
Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v17]
In-Reply-To: <rixoaZyO8MBo7el4cFwzAdgw33AExaNYYv6wBxQmDVA=.1390ee26-4914-476d-a4bc-6075bfce3328@github.com>
References: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
 <bQTvyHEmPdxFBDWwSOKMc3802ERzj_kNrtzaD3E-EsU=.d7295faa-6934-4cd1-81fd-8f25e0ca3757@github.com>
 <4s1iWdgqtuzO_x_kKixSh2jyDwTNL8xhcNl5YkLV79I=.d176c971-f767-414d-a525-68bc5d66a758@github.com>
 <NvmqCVaUKvH0cAlztgDOtp7mqgnEO3JWW9OqkYaQhek=.d78da102-8c58-401b-ac3f-472348ff2012@github.com>
 <rixoaZyO8MBo7el4cFwzAdgw33AExaNYYv6wBxQmDVA=.1390ee26-4914-476d-a4bc-6075bfce3328@github.com>
Message-ID: <t9uEQFVSHsIoTObgdGqO9X06opYLipIsNJW-oPoXj8s=.6f0ba024-b39c-48e3-be1d-fcfb0aef23de@github.com>

On Wed, 12 Nov 2025 02:32:53 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> > > Some of these disparate changes are things I would approve of if they were offered separately. Others I think need more work.
> > > For example, for the sharedRuntime changes, is the fmod of infinity issue with Windows, or is it with Visual Studio. If the latter, the conditionalization of the workaround is wrong. Also, has a bug been filed with Microsoft for this? Or has it perhaps already been fixed in some version?
> > > Also, there are comments using "ARM64" but we use "AARCH64" in code.
> > 
> > 
> > @swesonga filed a bug for this, not sure if this is what you're referring to? https://developercommunity.visualstudio.com/t/fmod-incorrectly-returns-NaN-on-certain-/10793176
> 
> Yes, that's what I was looking for. Thanks for the pointer.
> 
> > I think this might be an issue with Visual Studio rather than Windows itself. Admittedly I really don't like all the conditionals either, and am hoping for it to be fixed in VS soon so I can delete the workaround entirely, but there hasn't been any news on whether this has been fixed yet or not.
> 
> Does gcc on Windows have the same problem? I'm guessing not. This seems almost certainly to be a VS problem, either with the generated code or (more likely) with a runtime support function. Of course, with that in mind we can't remove the workaround until we've moved the minimum supported version forward past the bug fix. That might be a while.

Sorry for not seeing this earlier. I don't believe gcc suffers from the same issue, though for now I cannot test it since gcc is currently broken due to a bug in its codeview debugging internals that still hasn't being fixed yet :(

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21627#issuecomment-3640013289

From jwaters at openjdk.org  Thu Dec 11 04:23:22 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 11 Dec 2025 04:23:22 GMT
Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v4]
In-Reply-To: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
Message-ID: <mvIFT2i9hbnO-551N2dHNp6XPaDs4hBZSQ6oXVvfkH8=.b7abfd4c-5228-47d5-8ce5-f350f87d1706@github.com>

> 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 22 commits:

 - 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
 - Revert recent changes to spec.gmk.template
 - Revert recent changes to flags-ldflags.m4
 - Revert recent changes to flags-cflags.m4
 - Remove no longer needed warning disable in JvmFeatures.gmk
 - Merge branch 'master' into patch-16
 - ... and 12 more: https://git.openjdk.org/jdk/compare/74dca863...550f951d

-------------

Changes: https://git.openjdk.org/jdk/pull/22464/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22464&range=03
  Stats: 60 lines in 8 files changed: 11 ins; 45 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 jbhateja at openjdk.org  Thu Dec 11 06:12:29 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 11 Dec 2025 06:12:29 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v7]
In-Reply-To: <H1M8_FtGtYl2jww_n3OE5o3G8SFCe8TMl-XgtRA6Krg=.fb56cb81-2890-47c5-b35b-b2d730e3e71f@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <H1M8_FtGtYl2jww_n3OE5o3G8SFCe8TMl-XgtRA6Krg=.fb56cb81-2890-47c5-b35b-b2d730e3e71f@github.com>
Message-ID: <lho5QXHxy87rtS6SRdOizf-Qtgdl7hTyTmvi2M1SGpk=.25bc3ffb-1390-4ab4-bcfe-28d215d70099@github.com>

On Wed, 10 Dec 2025 10:23:30 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Add a new  Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type.
>> - Add necessary inline expander support.
>>    - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA.
>> - Use existing Float16 vector IR and backend support.
>> - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations.
>>  
>> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc).
>> 
>> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels.
>> 
>> <img width="1344" height="532" alt="image" src="https://github.com/user-attachments/assets/c8157c3c-22b0-4bc1-9de9-7a68cadb7b2a" />
>> 
>> Initial RFP[1] was floated on the panama-dev mailing list.
>> 
>> Kindly review the draft PR and share your feedback.
>> 
>> Best Regards,
>> Jatin
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
> 
>  - 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
>  - Adding support for custom basic  type T_FLOAT16, passing BasicType lane types to inline expander entries
>  - Cleaning up interface as per review suggestions
>  - Some cleanups
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/b60ac710...44ac727d

> jdk/incubator/vector/Float16Vector512Tests.java



> This patch results in two of the JTREG tests failing on aarch64 machines-
> 
> ```
> jdk/incubator/vector/Float16Vector512Tests.java
> compiler/vectorapi/TestFloat16VectorOperations.java
> ```
> 
> which is due to an issue in the `aarch64.ad` file. Fixed the failures and also added aarch64 specific IR rules which were missing for some of the tests in the `compiler/vectorapi/TestFloat16VectorOperations.java` test.
> 
> @jatin-bhateja Could you please add the attached fix to this patch? Thanks! [fix.patch](https://github.com/user-attachments/files/24076067/fix.patch)

Hi @Bhavana-Kilambi , Thanks for running this thorugh your setup, I am also able to reproduce it on Google AXION, your fix fills the gap in instruction selector, I suggest creating a seperate PR for this ? You can either create a smaller standalone reproducer testcase or mention about the tests part of this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3640370652

From iklam at openjdk.org  Thu Dec 11 06:15:24 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 11 Dec 2025 06:15:24 GMT
Subject: RFR: 8373114: Redundant MethodCounters in the preimage generated
 by training run [v3]
In-Reply-To: <Ftzehw6uU22VX960CToHi7NxdC8d5OR5Nd_emv7hSjQ=.9c31a575-0e6b-4e01-a454-d7e6c172a034@github.com>
References: <LRw06Cn_4dcRW8YyFVr3RijMHIha7nPzBrcNNzaIny8=.dc07d0ee-b797-4434-aad0-956a00c2ea6f@github.com>
 <Ftzehw6uU22VX960CToHi7NxdC8d5OR5Nd_emv7hSjQ=.9c31a575-0e6b-4e01-a454-d7e6c172a034@github.com>
Message-ID: <51BI00llbwi8PwSDim1trHJeYuMX3tY-85ylFrZ6ipk=.3c7a29ff-76ab-4002-a208-a8eb427295e8@github.com>

On Tue, 9 Dec 2025 02:39:41 GMT, Ashutosh Mehra <asmehra at openjdk.org> 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 <asmehra at redhat.com>

> > > Another approach I thought of was to add the filtering in ArchiveBuilder::get_follow_mode such that only the MethodCounters referenced by MTDs are stored in the AOTCache. It is possible to get the enclosing MetaspaceObj for the MetaspaceClosure::Ref passed to get_follow_mode but I couldn't find an easy way to get the type of the enclosing object, which makes it difficult to check if the MethodCounters being added came from Method or MTD.
> 
> > Hi Ashutosh, I've created a patch for finding the type of the enclosing obj:
> > [iklam at cef9437](https://github.com/iklam/jdk/commit/cef9437484e119fde1b4eb07a809b33d83e35bdd)
> > Could you try to see if that works for you?
> 
> @iklam thanks for the changes. This is indeed what I wanted and updated the patch with the following change:
> 
> ```
>           address enclosing_obj = ref->enclosing_obj();
>           if (ref->enclosing_obj_msotype() == MetaspaceObj::MethodTrainingDataType) {
>             return make_a_copy;
>           }
> ```
> 
> But it seems like this is not sufficient. With this approach number of MethodCounters are only 1142 while the MTDs are around 4k. This is because in `ArchiveBuilder::gather_one_source_obj` the MCs that are first reached from Method get stored in the `_src_obj_table` with `_follow_mode=set_to_null`. Subsequent visits to such MCs through MTDs are ignored.

Currently `set_to_null` means that the referenced object should be always be excluded (with all subsequent references). Maybe we can change the meaning to "set the current reference to null, but allow the referenced object to be included via other references". If we make this change, it will be easier to handle similar situations in the future.

I am not sure if there's a compatibility issue -- probably not. Currently, we have never had a situation where the follow-mode of a referenced object is sometimes `set_to_null` and sometimes `make_a_copy`.

However, the implementation will be more complicated, as we have to remember the decision on each reference (currently the decision is remembered on the referenced object).

Maybe we should go with your first approach for now, and experiment with the second approach in a later RFE.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28670#issuecomment-3640384909

From epeter at openjdk.org  Thu Dec 11 07:22:34 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 11 Dec 2025 07:22:34 GMT
Subject: RFR: 8372845: C2: Fold identity hash code if object is constant
 [v3]
In-Reply-To: <r2gvtXpF9spuh0PGFRWFuKhgKSInOJ8UbZ2rWTNzLB8=.5f60583a-ee90-40b8-8826-8893fa7b8372@github.com>
References: <KPNLohuiE3Os64ib8cPl8cyPUbmvzOF2y687qapKSgc=.cae21b9f-2fa9-4e78-a5ef-7912cf906dfa@github.com>
 <AqXlBQi24MmML3tltUJiZa0bEYzORazv9mVo41lrIP4=.13265855-6308-47d1-93f0-006bfe06fdfa@github.com>
 <cavp_9ZUlDCfuwg9Eyp8wDms7j5GOtSZPwYk-QYMbVI=.bfed4082-375e-4a52-a2a1-4071843b7550@github.com>
 <XpDpc28hjOioKUPvgyyCXCVkZLVeHL7GGmoEW5--1UE=.809ce0b3-8992-4f55-98a8-8834401597a5@github.com>
 <6ip4JrJ4WiYEe6d2FA_WQ5dDjxAk2RPaPbwth4jNeJM=.43d7879d-89a4-434c-80ea-371c92581686@github.com>
 <r2gvtXpF9spuh0PGFRWFuKhgKSInOJ8UbZ2rWTNzLB8=.5f60583a-ee90-40b8-8826-8893fa7b8372@github.com>
Message-ID: <0b81mH1_Y6r905N2HmehXBbSFdzLpJIfuXHNfijpHBs=.c870b13e-a52f-4c00-b771-91cf9205cb4a@github.com>

On Wed, 10 Dec 2025 19:46:43 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> You can for example run it with C1 or Xint only. That would disable the test. Or someone runs it with Graal.
>> I would generally remove `@requires` from any test we can, to get more coverage.
>
> It's a test on C2 IR. What's the point in running it w/o C2?

You can always do more than just C2 IR verification. For example, we could also do result verification. That would give us coverage for C1 for example. I think it is just good practice not to have a restriction if it is not absolutely necessary.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2609462695

From jbhateja at openjdk.org  Thu Dec 11 07:32:58 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 11 Dec 2025 07:32:58 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v8]
In-Reply-To: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
Message-ID: <vb-vgf42wiwmQCdgQR1ouHiv3-S2gOrhG6jxL9CIj2k=.babee2e7-a37c-483f-87e5-b5b2856ecde2@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.
> 
> <img width="1344" height="532" alt="image" src="https://github.com/user-attachments/assets/c8157c3c-22b0-4bc1-9de9-7a68cadb7b2a" />
> 
> Initial RFP[1] was floated on the panama-dev mailing list.
> 
> Kindly review the draft PR and share your feedback.
> 
> Best Regards,
> Jatin
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Including test changes from Bhavana Kilambi (ARM)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28002/files
  - new: https://git.openjdk.org/jdk/pull/28002/files/44ac727d..7da5d147

Webrevs:
 - full: Webrev is not available because diff is too large
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28002&range=06-07

  Stats: 16 lines in 1 file changed: 10 ins; 0 del; 6 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  Thu Dec 11 09:07:42 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 11 Dec 2025 09:07:42 GMT
Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() [v6]
In-Reply-To: <NtMPMeCg0Pr3xvm6APh556G0XHh9ZuOJrX0ZhWqDRXM=.81294a86-b76f-4ed3-aa4b-d6afd72b09af@github.com>
References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com>
 <CEvEqPtlTMiv7fX1G_spyCpyl8afEZn4McrzIBd5GRY=.d233254e-3626-4044-a3e1-c82bcbd55e45@github.com>
 <NtMPMeCg0Pr3xvm6APh556G0XHh9ZuOJrX0ZhWqDRXM=.81294a86-b76f-4ed3-aa4b-d6afd72b09af@github.com>
Message-ID: <4n3LwIItTdN__WjnZZkHYDV25HWhFkpshLm_ngr3Rl8=.76385eac-68bf-47bd-81fd-c96e1eb16814@github.com>

On Wed, 10 Dec 2025 20:20:03 GMT, Dean Long <dlong at openjdk.org> wrote:

> My concern is that it appears possible to call `set_to_interpreted` multiple times in the lifecycle of the call site, and some of those times could have the entry point still patched to a branch instead of ISB, however set_to_interpreted seems to assume the entry point is an ISB and the comments use that assumption to argue for its correctness.

I see your point. However,  I don't see the comments to which you refer. Please, where are they?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26638#issuecomment-3640936573

From aartemov at openjdk.org  Thu Dec 11 09:17:58 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Thu, 11 Dec 2025 09:17:58 GMT
Subject: RFR: 8373497: SpinCriticalSection should use SpinYield
Message-ID: <RHXygdCF_IpKSJEDYgnHslxOdjUC1YjvssLitKsERv4=.a51620a1-963d-464b-9f97-03e76a7b5d9b@github.com>

Hi, please consider the following changes:

The original code of `Thread::SpinAqcuire()` was moved into a RAII object `SpinCriticalSection` in https://bugs.openjdk.org/browse/JDK-8366671

It to a great extent duplicates the code of the `SpinYield` class, which is more flexible. In this PR the duplication is removed as `SpinCriticalSection` now makes uses of  `SpinYield`.

Tested in tiers 1-3.

Extended performance testing has shown that the change is neutral.

-------------

Commit messages:
 - 8373497: SpinCriticalSection should use SpinYield

Changes: https://git.openjdk.org/jdk/pull/28763/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28763&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373497
  Stats: 18 lines in 1 file changed: 3 ins; 14 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28763.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28763/head:pull/28763

PR: https://git.openjdk.org/jdk/pull/28763

From dholmes at openjdk.org  Thu Dec 11 09:20:24 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 11 Dec 2025 09:20:24 GMT
Subject: RFR: 8371948: TestStackOverflowDuringInit.java fails xss too small
 on linux-aarch64 [v5]
In-Reply-To: <L1U5kByReJGXcxHMZG21t0teqI3WH4sh59saejQwryA=.d95f42e9-6e53-4755-8a2f-36c6732aa86b@github.com>
References: <P6KhJ0rZttqTHVxuVi_POYRVmy2oGpaUj03Gnz3LXOQ=.9449af19-abc3-44ad-99e9-6e70ce008e3c@github.com>
 <L1U5kByReJGXcxHMZG21t0teqI3WH4sh59saejQwryA=.d95f42e9-6e53-4755-8a2f-36c6732aa86b@github.com>
Message-ID: <Bhl0oj4_CwxWaFHsANLG_lcG6ImLGIy6jRBRk48PMkc=.01b13773-5fb3-4e64-badf-0a78f8db0fd7@github.com>

On Thu, 11 Dec 2025 01:57:58 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> On linux-aarch64, when page size is 64K, the minimal java thread stack size is 448K. So this PR increase the minimal java thread stack size in test/hotspot/jtreg/runtime/ClassInitErrors/TestStackOverflowDuringInit.java. Below is the calculation formula for the minimal java thread stack size:
>> 
>> 
>> page_size = 64K
>> _java_thread_min_stack_allowed = 72K
>> _stack_red_zone_size = align_up(StackRedPages * unit, page_size) = align_up(1*4K, 64K) = 64K
>> _stack_yellow_zone_size = align_up(StackYellowPages * unit, page_size) = align_up(2*4K, 64K) = 64K
>> _stack_reserved_zone_size = align_up(StackReservedPages * unit, page_size) = align_up(1*4K, 64K) = 64K
>> _stack_shadow_zone_size = align_up(StackShadowPages * unit, page_size) = align_up(25*4K, 64K) = 128K
>> _java_thread_min_stack_allowed = align_up(72K+64K+64K+64K+128K, 64K) = 448K
>> 
>> 
>> This PR add whitebox API getMinimumJavaStackSize() to the the allowd minimum java stack size, and get the allowed minimum java stack size in test/hotspot/jtreg/runtime/ClassInitErrors/TestStackOverflowDuringInit.java
>> 
>> Change has been verified locally both on linux-x64 and linux-aarch64.
>
> SendaoYan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove test/hotspot/jtreg/runtime/memory/ReadMinimumJavaStackSize.java
>  - Use get_minimum_java_stack_size instead of get_minimum_java_stack_sizes

Looks good. Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28352#pullrequestreview-3566467929

From dholmes at openjdk.org  Thu Dec 11 09:32:57 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 11 Dec 2025 09:32:57 GMT
Subject: RFR: 8373449: Parallel: Obsolete deprecated PSChunkLargeArrays
In-Reply-To: <4Qgp_QW_5sreJ5W4srufeKwDQzAd1Ajn601diouyd3g=.2361b5f9-31c3-496f-9121-3df9abfc7bc4@github.com>
References: <4Qgp_QW_5sreJ5W4srufeKwDQzAd1Ajn601diouyd3g=.2361b5f9-31c3-496f-9121-3df9abfc7bc4@github.com>
Message-ID: <VCpT9lee1wZv0x6I1tDAsZw1v1WwPrhOccmvLagEj28=.cdfb7c67-bbd2-4a51-ae9c-2e2c760cbd1f@github.com>

On Wed, 10 Dec 2025 18:09:17 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Obsolete a deprecated jvm flag. Its default value is `true`.
> 
> Test: tier1-3

Looks good. Thanks.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28754#pullrequestreview-3566523152

From roland at openjdk.org  Thu Dec 11 10:05:56 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Thu, 11 Dec 2025 10:05:56 GMT
Subject: RFR: 8370519: C2: Hit MemLimit when running with
 +VerifyLoopOptimizations [v4]
In-Reply-To: <W7EnT28-84mtwppISdr_ydCV9HSaXk72y7fyd29z4wQ=.7331c81d-c36f-4a1c-b949-e7045f524d07@github.com>
References: <W7EnT28-84mtwppISdr_ydCV9HSaXk72y7fyd29z4wQ=.7331c81d-c36f-4a1c-b949-e7045f524d07@github.com>
Message-ID: <v1vLDkCDxWoPyPG5alwz4HabgD9lFfE4f-mNoYmKPqA=.4d58b04c-36ab-4acb-beaf-085e99cc5b7e@github.com>

> 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 test/hotspot/jtreg/compiler/c2/TestVerifyLoopOptimizationsHighMemUsage.java
   
   Co-authored-by: Emanuel Peter <emanuel.peter at oracle.com>
 - Update test/hotspot/jtreg/compiler/c2/TestVerifyLoopOptimizationsHighMemUsage.java
   
   Co-authored-by: Beno?t Maillard <benoit.maillard at protonmail.com>
 - Update src/hotspot/share/opto/loopnode.hpp
   
   Co-authored-by: Emanuel Peter <emanuel.peter at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28581/files
  - new: https://git.openjdk.org/jdk/pull/28581/files/36fb3a6f..133fcddc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28581&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28581&range=02-03

  Stats: 4 lines in 2 files changed: 1 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 roland at openjdk.org  Thu Dec 11 10:35:27 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Thu, 11 Dec 2025 10:35:27 GMT
Subject: RFR: 8370519: C2: Hit MemLimit when running with
 +VerifyLoopOptimizations [v3]
In-Reply-To: <G89yMENAdUzXCgStQ1TIoV78nGlSH1JdFayw8MyP2cU=.9dc5bb37-75b6-4abf-9323-de5ec1501a15@github.com>
References: <W7EnT28-84mtwppISdr_ydCV9HSaXk72y7fyd29z4wQ=.7331c81d-c36f-4a1c-b949-e7045f524d07@github.com>
 <FkXbOvbukpCfSEBmYIOsn1IUaRnPZhEYv3yfz3Dz-QQ=.da549428-ed90-424e-8a77-dac3a745ed67@github.com>
 <G89yMENAdUzXCgStQ1TIoV78nGlSH1JdFayw8MyP2cU=.9dc5bb37-75b6-4abf-9323-de5ec1501a15@github.com>
Message-ID: <_4CdutrS1tyxf_rqM_xdgccYtxlQ0slKbNC9tYxK89Q=.d1289c09-69da-4962-be5a-42252cf33fdb@github.com>

On Wed, 10 Dec 2025 13:13:48 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - review
>>  - review
>
> src/hotspot/share/opto/loopnode.hpp line 1217:
> 
>> 1215:     PhaseTransform(Ideal_Loop),
>> 1216:     _arena(mtCompiler, Arena::Tag::tag_idealloop),
>> 1217:     _loop_or_ctrl(&_arena),
> 
> How about some of the other data structures? For example `_idom`?

They are allocated in the thread's resource area. So there's no leak and while for `_loop_or_ctrl` and `_body` there were issues that were solved by moving them to the compile arena, there hasn't been any so far with other data structures such as `_idom`. So, sure, we could pro actively move them to the new arena but do we gain anything from doing that?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28581#discussion_r2610055708

From eastigeevich at openjdk.org  Thu Dec 11 11:24:20 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Thu, 11 Dec 2025 11:24:20 GMT
Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact
 on GCs and JIT performance [v16]
In-Reply-To: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
Message-ID: <tTLfgklJegiPyVkoc01nt4exW548_ExAy0WXLiCfvXg=.443a4b83-78dc-444b-87e1-f4c750e5798b@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 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
>    - [ ] tier4
> 
> Benchmarking results: Neoverse-N1 r3p1 (Graviton 2), 5 000 nmethods...

Evgeny Astigeevich has updated the pull request incrementally with two additional commits since the last revision:

 - Add cache DIC IDC status to VM_Version
 - Fix tier3 failures

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28328/files
  - new: https://git.openjdk.org/jdk/pull/28328/files/85691beb..44f43e4e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28328&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28328&range=14-15

  Stats: 115 lines in 7 files changed: 49 ins; 50 del; 16 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 epeter at openjdk.org  Thu Dec 11 12:15:23 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 11 Dec 2025 12:15:23 GMT
Subject: RFR: 8370519: C2: Hit MemLimit when running with
 +VerifyLoopOptimizations [v3]
In-Reply-To: <_4CdutrS1tyxf_rqM_xdgccYtxlQ0slKbNC9tYxK89Q=.d1289c09-69da-4962-be5a-42252cf33fdb@github.com>
References: <W7EnT28-84mtwppISdr_ydCV9HSaXk72y7fyd29z4wQ=.7331c81d-c36f-4a1c-b949-e7045f524d07@github.com>
 <FkXbOvbukpCfSEBmYIOsn1IUaRnPZhEYv3yfz3Dz-QQ=.da549428-ed90-424e-8a77-dac3a745ed67@github.com>
 <G89yMENAdUzXCgStQ1TIoV78nGlSH1JdFayw8MyP2cU=.9dc5bb37-75b6-4abf-9323-de5ec1501a15@github.com>
 <_4CdutrS1tyxf_rqM_xdgccYtxlQ0slKbNC9tYxK89Q=.d1289c09-69da-4962-be5a-42252cf33fdb@github.com>
Message-ID: <eM6orDaUl9YGgfOsEGjzyr9ECFYmRmG2KrJQ5bXbrk4=.8705aa83-d6b4-4890-84a4-17ba0080fac4@github.com>

On Thu, 11 Dec 2025 10:32:34 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> src/hotspot/share/opto/loopnode.hpp line 1217:
>> 
>>> 1215:     PhaseTransform(Ideal_Loop),
>>> 1216:     _arena(mtCompiler, Arena::Tag::tag_idealloop),
>>> 1217:     _loop_or_ctrl(&_arena),
>> 
>> How about some of the other data structures? For example `_idom`?
>
> They are allocated in the thread's resource area. So there's no leak and while for `_loop_or_ctrl` and `_body` there were issues that were solved by moving them to the compile arena, there hasn't been any so far with other data structures such as `_idom`. So, sure, we could pro actively move them to the new arena but do we gain anything from doing that?

Yes, I think we would! Keeping `_idom` on the thread resource area means we often cannot use `ResourceMark` for other data structures, if possibly `_idom` is modified in the same scope.

@iwanowww could not place `ResourceMark`s in some of this current PR:
https://github.com/openjdk/jdk/pull/25315

For example:

+bool PhaseIdealLoop::optimize_reachability_fences() {
+  Compile::TracePhase tp(_t_reachability_optimize);
+
+  assert(OptimizeReachabilityFences, "required");
+
+  // ResourceMark rm; // NB! not safe because insert_rf may trigger _idom reallocation
+  Unique_Node_List redundant_rfs;
+  GrowableArray<Pair<Node*,Node*>> worklist;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28581#discussion_r2610352515

From wenanjian at openjdk.org  Thu Dec 11 12:22:13 2025
From: wenanjian at openjdk.org (Anjian Wen)
Date: Thu, 11 Dec 2025 12:22:13 GMT
Subject: RFR: 8373069: RISC-V: implement GHASH intrinsic [v4]
In-Reply-To: <zxCNQIhhidoKzHbxL0z8h_Tp1N8pCmlHNoJ2wx30XF8=.a3d8eb05-9a07-403e-a014-84c3bb32b001@github.com>
References: <zxCNQIhhidoKzHbxL0z8h_Tp1N8pCmlHNoJ2wx30XF8=.a3d8eb05-9a07-403e-a014-84c3bb32b001@github.com>
Message-ID: <8MCvHCHkscmoOkB_cKGP5mkhHWBw6B3PfalaBL4aVg0=.0a6e3bc9-7b6b-498d-81fb-1a276adc2a31@github.com>

> support GHASH intrinsic for crypt GCM, which need zvkg extension. 
> 
> passed the tests in 
> test/hotspot/jtreg/compiler/codegen/aes/
> test/jdk/com/sun/crypto

Anjian Wen has updated the pull request incrementally with one additional commit since the last revision:

  modify format

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28548/files
  - new: https://git.openjdk.org/jdk/pull/28548/files/fc63cb77..3bf38390

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28548&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28548&range=02-03

  Stats: 4 lines in 2 files changed: 0 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/28548.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28548/head:pull/28548

PR: https://git.openjdk.org/jdk/pull/28548

From cnorrbin at openjdk.org  Thu Dec 11 12:34:34 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Thu, 11 Dec 2025 12:34:34 GMT
Subject: RFR: 8253683: Clean up and clarify uses of
 os::vm_allocation_granularity
In-Reply-To: <hE4UfcTf6NW-N6J0t4wXUOT5ONo-1C7Z9FvL3HX1nt8=.146e9294-7d9a-4567-a136-6ea0b4270254@github.com>
References: <t1YFEQDP7_gQO-1SGvGRjAMbVE4nVs5a9wMFJtB0DOs=.a44ce263-642c-42cf-8135-dd0121ce24ce@github.com>
 <hE4UfcTf6NW-N6J0t4wXUOT5ONo-1C7Z9FvL3HX1nt8=.146e9294-7d9a-4567-a136-6ea0b4270254@github.com>
Message-ID: <IM5zJJq5WNR8R0q9tSPsF4CNvoBij3SGqZRQLmligtU=.80484cef-ac42-465e-8629-fa805a25fd7b@github.com>

On Wed, 3 Dec 2025 11:30:32 GMT, Frederic Thevenet <fthevenet at openjdk.org> 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)

The `p_buf` we are aligning (l2023) originates from a `VirtualAlloc` reserve call (l3011-3014), so it is already granularity-aligned. I believe this line and the following `chunk_size` calculation has more to do with large pages and proper NUMA support, as is said in the existing comment:

// we still need to round up to a page boundary (in case we are using large pages)
// but not to a chunk boundary (in case InterleavingGranularity doesn't align with page size)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28493#discussion_r2610412226

From roland at openjdk.org  Thu Dec 11 13:02:43 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Thu, 11 Dec 2025 13:02:43 GMT
Subject: RFR: 8370519: C2: Hit MemLimit when running with
 +VerifyLoopOptimizations [v5]
In-Reply-To: <W7EnT28-84mtwppISdr_ydCV9HSaXk72y7fyd29z4wQ=.7331c81d-c36f-4a1c-b949-e7045f524d07@github.com>
References: <W7EnT28-84mtwppISdr_ydCV9HSaXk72y7fyd29z4wQ=.7331c81d-c36f-4a1c-b949-e7045f524d07@github.com>
Message-ID: <1wI5cirlHfpzcuxIYfBYp1AZ-qXC8chszZKC9vHtkK4=.d7f4a152-4bed-4df5-b4ab-4062474cc220@github.com>

> 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 14 additional commits since the last revision:

 - review
 - Merge branch 'master' into JDK-8370519
 - Update test/hotspot/jtreg/compiler/c2/TestVerifyLoopOptimizationsHighMemUsage.java
   
   Co-authored-by: Emanuel Peter <emanuel.peter at oracle.com>
 - Update test/hotspot/jtreg/compiler/c2/TestVerifyLoopOptimizationsHighMemUsage.java
   
   Co-authored-by: Beno?t Maillard <benoit.maillard at protonmail.com>
 - Update src/hotspot/share/opto/loopnode.hpp
   
   Co-authored-by: Emanuel Peter <emanuel.peter at oracle.com>
 - review
 - review
 - Update src/hotspot/share/opto/compile.hpp
   
   Co-authored-by: Manuel H?ssig <manuel at haessig.org>
 - whitespaces
 - more
 - ... and 4 more: https://git.openjdk.org/jdk/compare/7f29f798...8411ff3d

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28581/files
  - new: https://git.openjdk.org/jdk/pull/28581/files/133fcddc..8411ff3d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28581&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28581&range=03-04

  Stats: 45013 lines in 627 files changed: 27798 ins; 14172 del; 3043 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  Thu Dec 11 13:04:42 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Thu, 11 Dec 2025 13:04:42 GMT
Subject: RFR: 8370519: C2: Hit MemLimit when running with
 +VerifyLoopOptimizations [v3]
In-Reply-To: <eM6orDaUl9YGgfOsEGjzyr9ECFYmRmG2KrJQ5bXbrk4=.8705aa83-d6b4-4890-84a4-17ba0080fac4@github.com>
References: <W7EnT28-84mtwppISdr_ydCV9HSaXk72y7fyd29z4wQ=.7331c81d-c36f-4a1c-b949-e7045f524d07@github.com>
 <FkXbOvbukpCfSEBmYIOsn1IUaRnPZhEYv3yfz3Dz-QQ=.da549428-ed90-424e-8a77-dac3a745ed67@github.com>
 <G89yMENAdUzXCgStQ1TIoV78nGlSH1JdFayw8MyP2cU=.9dc5bb37-75b6-4abf-9323-de5ec1501a15@github.com>
 <_4CdutrS1tyxf_rqM_xdgccYtxlQ0slKbNC9tYxK89Q=.d1289c09-69da-4962-be5a-42252cf33fdb@github.com>
 <eM6orDaUl9YGgfOsEGjzyr9ECFYmRmG2KrJQ5bXbrk4=.8705aa83-d6b4-4890-84a4-17ba0080fac4@github.com>
Message-ID: <0rToTq8A20oksbCQasA5Uuy4YNgDRIFt2GgwYbfOjKE=.7d94d1f5-8370-4a6b-98ca-68230b22c874@github.com>

On Thu, 11 Dec 2025 12:12:02 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> They are allocated in the thread's resource area. So there's no leak and while for `_loop_or_ctrl` and `_body` there were issues that were solved by moving them to the compile arena, there hasn't been any so far with other data structures such as `_idom`. So, sure, we could pro actively move them to the new arena but do we gain anything from doing that?
>
> Yes, I think we would! Keeping `_idom` on the thread resource area means we often cannot use `ResourceMark` for other data structures, if possibly `_idom` is modified in the same scope.
> 
> @iwanowww could not place `ResourceMark`s in some of this current PR:
> https://github.com/openjdk/jdk/pull/25315
> 
> For example:
> 
> +bool PhaseIdealLoop::optimize_reachability_fences() {
> +  Compile::TracePhase tp(_t_reachability_optimize);
> +
> +  assert(OptimizeReachabilityFences, "required");
> +
> +  // ResourceMark rm; // NB! not safe because insert_rf may trigger _idom reallocation
> +  Unique_Node_List redundant_rfs;
> +  GrowableArray<Pair<Node*,Node*>> worklist;

Ok. Done in new commit for `_idom` and `_dom_depth`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28581#discussion_r2610504368

From aph at openjdk.org  Thu Dec 11 13:41:20 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 11 Dec 2025 13:41:20 GMT
Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() [v6]
In-Reply-To: <CEvEqPtlTMiv7fX1G_spyCpyl8afEZn4McrzIBd5GRY=.d233254e-3626-4044-a3e1-c82bcbd55e45@github.com>
References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com>
 <CEvEqPtlTMiv7fX1G_spyCpyl8afEZn4McrzIBd5GRY=.d233254e-3626-4044-a3e1-c82bcbd55e45@github.com>
Message-ID: <tHF-qeZ12J1_ANlTDHCsqN4E5-_gKLLV6_glEWKBnS4=.967f4651-110b-4093-8982-c4e64081841c@github.com>

On Mon, 8 Dec 2025 14:01:48 GMT, Fei Gao <fgao at openjdk.org> 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/f7d24060...415495da

There seems to be bad stuff in this area.

For one, we rewrite compiled IC calls unnecessarily when they haven't changed. We should stop doing that for efficiency's sake, but I'm not sure that rewriting instructions when other threads are concurrently executing them is legal. For one thing, the ARM talks about "concurrent modification and execution," but doesn't make it clear if rewriting an instruction with the same value is modification. I guess it isn't. But I also see


void CompiledDirectCall::verify_mt_safe(const methodHandle& callee, address entry,
                                        NativeMovConstReg* method_holder,
                                        NativeJump* jump) {
  _call->verify();
  // A generated lambda form might be deleted from the Lambdaform
  // cache in MethodTypeForm.  If a jit compiled lambdaform method
  // becomes not entrant and the cache access returns null, the new
  // resolve will lead to a new generated LambdaForm.
  Method* old_method = reinterpret_cast<Method*>(method_holder->data());
  assert(old_method == nullptr || old_method == callee() ||
         callee->is_compiled_lambda_form() ||


If we really do rewrite the `Method*` in a compiled IC stub while other code is concurrently executing it, that is clearly undefined behaviour. If we have a stress test for jit-compiled lambda methods, I'd like to try it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26638#issuecomment-3641982149

From eastigeevich at openjdk.org  Thu Dec 11 14:18:28 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Thu, 11 Dec 2025 14:18:28 GMT
Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact
 on GCs and JIT performance [v17]
In-Reply-To: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
Message-ID: <R45RCms_eyEpAZycKaEMglj0t9HzZfycDse6luApdJc=.da2bae3f-1b3c-4a14-a1cc-70c744bc8478@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 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 failures
>       - `containers/docker/TestJcmdWithSideCar.java`: JD...

Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:

  Fix macos and windows aarch64 builds

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28328/files
  - new: https://git.openjdk.org/jdk/pull/28328/files/44f43e4e..2448b2d7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28328&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28328&range=15-16

  Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 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 mbaesken at openjdk.org  Thu Dec 11 14:25:14 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 11 Dec 2025 14:25:14 GMT
Subject: RFR: 8372348: Adjust some UL / JFR string deduplication output
 messages
In-Reply-To: <pNpdqbYFfgvrIkYZRCFEldiccxVqyq1vQB3hxnIs1Nk=.b7f28843-7e09-477f-9a0f-63bb3314b9f8@github.com>
References: <7-XRp229KFw3V2bFPMnaWaoPdF3ZCYVNuViEo2O7eUI=.e0247347-188b-44bf-935c-6b0186026fd3@github.com>
 <2r6k6Av9MTNmMxpbga6MJoUCu0vECsr7IDL6wAzJ_Ig=.c9106917-1635-4d3c-b6c4-f4c5f0659440@github.com>
 <kLaKX3lyoQshzjHXilycyq9_ixhaiQMy76zmavAX35M=.682f43b9-e72f-48ed-90a5-fcb84b3d3c90@github.com>
 <Ien8WqqsVLY--khvk8WkOeaSpaAKWcQ45x_5tCxQZTI=.f0f9bb58-ef10-4c78-8746-49f5a7bfa803@github.com>
 <pNpdqbYFfgvrIkYZRCFEldiccxVqyq1vQB3hxnIs1Nk=.b7f28843-7e09-477f-9a0f-63bb3314b9f8@github.com>
Message-ID: <FusqPTtOicwQ5QdQr8M2FJmblmUH46F-Rbsh6HBXi8w=.7d5a54eb-cfab-4c6a-8e26-1ab9535e6427@github.com>

On Wed, 10 Dec 2025 15:24:47 GMT, Andreas Steiner <asteiner at openjdk.org> wrote:

>> The avg  (now named total avg) is for some people also a bit mysterious .
>> It is , taken from total_stat , the` deduped bytes / new bytes` .  Why is it called avg? avg of what ?
>
> Adding total will be helpful already, but why are not the numbers printed on which the avg is based? Because otherwise you don't get an impression what the percentage mean.

` total avg of  deduped / new unknown bytes ` maybe ? That mentions what is used for the computation .
We could also print the values of  total deduped and new to make it more clear .

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28455#discussion_r2610777320

From rcastanedalo at openjdk.org  Thu Dec 11 14:38:45 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Thu, 11 Dec 2025 14:38:45 GMT
Subject: RFR: 8351889: C2 crash: assertion failed:  Base pointers must
 match (addp 344) [v5]
In-Reply-To: <lJ_q1MxUgjyRIHuOAAMwlgZV-V4ZbXicJ78Gyry2dIQ=.b1085ad9-0870-467c-b27a-773a2d4a4e3e@github.com>
References: <IKOYjLXrS8q1GMjbaL2HOBNH8Oa_16k4WBa2NaMngS8=.c6fd7fbb-4758-48b2-a992-3702b2718e59@github.com>
 <lJ_q1MxUgjyRIHuOAAMwlgZV-V4ZbXicJ78Gyry2dIQ=.b1085ad9-0870-467c-b27a-773a2d4a4e3e@github.com>
Message-ID: <3u22nbDF6M3weBExSGGYgGvisgMIeqDC4cLN1kIH-m8=.17ee76d4-1652-470f-8b52-af72091b9a95@github.com>

On Fri, 5 Dec 2025 13:48:50 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> The test case has an out of loop `Store` with an `AddP` address
>> expression that has other uses and is in the loop body. Schematically,
>> only showing the address subgraph and the bases for the `AddP`s:
>> 
>> 
>> Store#195 -> AddP#133 -> AddP#134 -> CastPP#110
>>                      -> CastPP#110
>> 
>> 
>> Both `AddP`s have the same base, a `CastPP` that's also in the loop
>> body.
>> 
>> That loop is a counted loop and only has 3 iterations so is fully
>> unrolled. First, one iteration is peeled:
>> 
>> 
>>                                 /-> CastPP#110
>> Store#195 -> Phi#360 -> AddP#133 -> AddP#134 -> CastPP#110
>>                     -> AddP#277 -> AddP#278 -> CastPP#283
>>                                 -> CastPP#283
>> 
>> 
>> 
>> The `AddP`s and `CastPP` are cloned (because in the loop body). As
>> part of peeling, `PhaseIdealLoop::peeled_dom_test_elim()` is
>> called. It finds the test that guards `CastPP#283` in the peeled
>> iteration dominates and replaces the test that guards `CastPP#110`
>> (the test in the peeled iteration is the clone of the test in the
>> loop). That causes `CastPP#110`'s control to be updated to that of the
>> test in the peeled iteration and to be yanked from the loop. So now
>> `CastPP#283` and `CastPP#110` have the same inputs.
>> 
>> Next unrolling happens:
>> 
>> 
>>                                            /-> CastPP#110
>>                                /-> AddP#400 -> AddP#401 -> CastPP#110
>> Store#195 -> Phi#360 -> Phi#477 -> AddP#133 -> AddP#134 -> CastPP#110
>>                   \                        -> CastPP#110
>>                    -> AddP#277 -> AddP#278 -> CastPP#283
>>                                -> CastPP#283
>> 
>> 
>> 
>> `AddP`s are cloned once more but not the `CastPP`s because they are
>> both in the peeled iteration now. A new `Phi` is added.
>> 
>> Next igvn runs. It's going to push the `AddP`s through the `Phi`s.
>> 
>> Through `Phi#477`:
>> 
>> 
>> 
>>                                 /-> CastPP#110
>> Store#195 -> Phi#360 -> AddP#510 -> Phi#509 -> AddP#401 -> CastPP#110
>>                   \                        -> AddP#134 -> CastPP#110
>>                    -> AddP#277 -> AddP#278 -> CastPP#283
>>                                -> CastPP#283
>> 
>> 
>> 
>> Through `Phi#360`:
>> 
>> 
>>                                            /-> AddP#134 -> CastPP#110
>>                                 /-> Phi#509 -> AddP#401 -> CastPP#110
>> Store#195 -> AddP#516 -> Phi#515 -> AddP#278 -> CastPP#283
>>                      -> Phi#514 -> CastPP#283
>>  ...
>
> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Thanks for the thorough analysis and fix, Roland! I agree this is the best way to go at the moment.

The invariant that AddP chains share the exact same base address node seems useful, as you mention above, to reduce the number of cases to think about. However, if we find in the future that this invariant becomes too difficult to maintain, we might want to consider relaxing it to "AddP chains have the same *uncast* base address". I guess this is the relaxation that @dean-long suggested above, and I believe it would preserve the spirit of the original assertion added to `Compile::final_graph_reshaping_main_switch()` by @rose00 many years ago when implementing the CastX2P/CastP2X nodes (perhaps to verify chains of AddP nodes induced by `CastX2PNode::Ideal` transformations?).

I'm running some internal testing, will come back with results.

src/hotspot/share/opto/phaseX.cpp line 2064:

> 2062: }
> 2063: 
> 2064: // Some other verifications that are no specific to a particular transformation

Suggestion:

// Some other verifications that are not specific to a particular transformation.

src/hotspot/share/opto/phaseX.cpp line 2065:

> 2063: 
> 2064: // Some other verifications that are no specific to a particular transformation
> 2065: bool PhaseIterGVN::verify_node_invariants_for(Node* n) {

Suggestion:

bool PhaseIterGVN::verify_node_invariants_for(const Node* n) {

src/hotspot/share/opto/phaseX.cpp line 2070:

> 2068:     if (addp->is_AddP() &&
> 2069:         !addp->in(AddPNode::Base)->is_top() &&
> 2070:         addp->in(AddPNode::Base) != n->in(AddPNode::Base)) {

Any way we could avoid this code duplication with the same check in `Compile::final_graph_reshaping_main_switch`?

src/hotspot/share/opto/phaseX.hpp line 496:

> 494:   bool verify_Ideal_for(Node* n, bool can_reshape);
> 495:   bool verify_Identity_for(Node* n);
> 496:   bool verify_node_invariants_for(Node* n);

Suggestion:

  bool verify_node_invariants_for(const Node* n);

-------------

PR Review: https://git.openjdk.org/jdk/pull/25386#pullrequestreview-3567683298
PR Review Comment: https://git.openjdk.org/jdk/pull/25386#discussion_r2610782593
PR Review Comment: https://git.openjdk.org/jdk/pull/25386#discussion_r2610784474
PR Review Comment: https://git.openjdk.org/jdk/pull/25386#discussion_r2610807655
PR Review Comment: https://git.openjdk.org/jdk/pull/25386#discussion_r2610790721

From thartmann at openjdk.org  Thu Dec 11 15:00:33 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 11 Dec 2025 15:00:33 GMT
Subject: RFR: 8372701: Randomized profile counters [v5]
In-Reply-To: <1nJnov3s2hhiLuO0W2FNcSAiGu5eEjZauQxfzd5YXKw=.8c593111-294a-4df7-8ce0-322871a801f3@github.com>
References: <jKjmIONZcytzVjS4absOwOLv_QOF9qhIJifYhN6JyP4=.dceced94-bc29-43e6-9062-8dc77c2a6133@github.com>
 <1nJnov3s2hhiLuO0W2FNcSAiGu5eEjZauQxfzd5YXKw=.8c593111-294a-4df7-8ce0-322871a801f3@github.com>
Message-ID: <BxQvwFp-zorwxRiwNksDT0Bp-PmKZuxbXnc4nHaXH8Y=.db07c559-4d8c-41e9-a2a3-e8b68b7e1a29@github.com>

On Tue, 9 Dec 2025 17:09:43 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> 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 with a new target base due to a merge or a rebase. The pull request now contains 58 commits:
> 
>  - Merge from master branch
>  - Merge remote-tracking branch 'refs/remotes/origin/JDK-8134940' into JDK-8134940
>  - Fix x86 lambda
>  - More
>  - Merge branch 'master' into JDK-8134940
>  - Merge branch 'master' into JDK-8134940
>  - Merge remote-tracking branch 'refs/remotes/origin/JDK-8134940' into JDK-8134940
>  - whitespace
>  - AArch64
>  - Minimize deltas to master
>  - ... and 48 more: https://git.openjdk.org/jdk/compare/7da91533...96db42e2

Thanks. Correctness testing is all clean on our side, I submitted benchmarks and will report back once it finished.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28541#issuecomment-3642327583

From roland at openjdk.org  Thu Dec 11 15:42:42 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Thu, 11 Dec 2025 15:42:42 GMT
Subject: RFR: 8370519: C2: Hit MemLimit when running with
 +VerifyLoopOptimizations [v6]
In-Reply-To: <W7EnT28-84mtwppISdr_ydCV9HSaXk72y7fyd29z4wQ=.7331c81d-c36f-4a1c-b949-e7045f524d07@github.com>
References: <W7EnT28-84mtwppISdr_ydCV9HSaXk72y7fyd29z4wQ=.7331c81d-c36f-4a1c-b949-e7045f524d07@github.com>
Message-ID: <ivWBI33pO0sKOtifG2aGTozX0ybXkxSazNW-T5rpJyU=.a77a85c6-3540-4ce8-8b82-db7bae444615@github.com>

> 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 one additional commit since the last revision:

  package declaration

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28581/files
  - new: https://git.openjdk.org/jdk/pull/28581/files/8411ff3d..1c040156

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28581&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28581&range=04-05

  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 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  Thu Dec 11 15:47:50 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Thu, 11 Dec 2025 15:47:50 GMT
Subject: RFR: 8351889: C2 crash: assertion failed:  Base pointers must
 match (addp 344) [v6]
In-Reply-To: <IKOYjLXrS8q1GMjbaL2HOBNH8Oa_16k4WBa2NaMngS8=.c6fd7fbb-4758-48b2-a992-3702b2718e59@github.com>
References: <IKOYjLXrS8q1GMjbaL2HOBNH8Oa_16k4WBa2NaMngS8=.c6fd7fbb-4758-48b2-a992-3702b2718e59@github.com>
Message-ID: <mByItBAq_6OnvZQAPwbfBHkiG80Z4BwqNDVOYjozO00=.af616fac-f772-407c-bf19-0d93a94f03d5@github.com>

> The test case has an out of loop `Store` with an `AddP` address
> expression that has other uses and is in the loop body. Schematically,
> only showing the address subgraph and the bases for the `AddP`s:
> 
> 
> Store#195 -> AddP#133 -> AddP#134 -> CastPP#110
>                      -> CastPP#110
> 
> 
> Both `AddP`s have the same base, a `CastPP` that's also in the loop
> body.
> 
> That loop is a counted loop and only has 3 iterations so is fully
> unrolled. First, one iteration is peeled:
> 
> 
>                                 /-> CastPP#110
> Store#195 -> Phi#360 -> AddP#133 -> AddP#134 -> CastPP#110
>                     -> AddP#277 -> AddP#278 -> CastPP#283
>                                 -> CastPP#283
> 
> 
> 
> The `AddP`s and `CastPP` are cloned (because in the loop body). As
> part of peeling, `PhaseIdealLoop::peeled_dom_test_elim()` is
> called. It finds the test that guards `CastPP#283` in the peeled
> iteration dominates and replaces the test that guards `CastPP#110`
> (the test in the peeled iteration is the clone of the test in the
> loop). That causes `CastPP#110`'s control to be updated to that of the
> test in the peeled iteration and to be yanked from the loop. So now
> `CastPP#283` and `CastPP#110` have the same inputs.
> 
> Next unrolling happens:
> 
> 
>                                            /-> CastPP#110
>                                /-> AddP#400 -> AddP#401 -> CastPP#110
> Store#195 -> Phi#360 -> Phi#477 -> AddP#133 -> AddP#134 -> CastPP#110
>                   \                        -> CastPP#110
>                    -> AddP#277 -> AddP#278 -> CastPP#283
>                                -> CastPP#283
> 
> 
> 
> `AddP`s are cloned once more but not the `CastPP`s because they are
> both in the peeled iteration now. A new `Phi` is added.
> 
> Next igvn runs. It's going to push the `AddP`s through the `Phi`s.
> 
> Through `Phi#477`:
> 
> 
> 
>                                 /-> CastPP#110
> Store#195 -> Phi#360 -> AddP#510 -> Phi#509 -> AddP#401 -> CastPP#110
>                   \                        -> AddP#134 -> CastPP#110
>                    -> AddP#277 -> AddP#278 -> CastPP#283
>                                -> CastPP#283
> 
> 
> 
> Through `Phi#360`:
> 
> 
>                                            /-> AddP#134 -> CastPP#110
>                                 /-> Phi#509 -> AddP#401 -> CastPP#110
> Store#195 -> AddP#516 -> Phi#515 -> AddP#278 -> CastPP#283
>                      -> Phi#514 -> CastPP#283
>                                 -> CastP#110
> 
> 
> Then `Phi#514` which has 2 `CastPP`s as input with identical inputs is
> transformed into anot...

Roland Westrelin has updated the pull request incrementally with two additional commits since the last revision:

 - Update src/hotspot/share/opto/phaseX.hpp
   
   Co-authored-by: Roberto Casta?eda Lozano <robcasloz at users.noreply.github.com>
 - Update src/hotspot/share/opto/phaseX.cpp
   
   Co-authored-by: Roberto Casta?eda Lozano <robcasloz at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25386/files
  - new: https://git.openjdk.org/jdk/pull/25386/files/20154a12..d2174c88

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25386&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25386&range=04-05

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25386.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25386/head:pull/25386

PR: https://git.openjdk.org/jdk/pull/25386

From roland at openjdk.org  Thu Dec 11 16:10:58 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Thu, 11 Dec 2025 16:10:58 GMT
Subject: RFR: 8351889: C2 crash: assertion failed:  Base pointers must
 match (addp 344) [v7]
In-Reply-To: <IKOYjLXrS8q1GMjbaL2HOBNH8Oa_16k4WBa2NaMngS8=.c6fd7fbb-4758-48b2-a992-3702b2718e59@github.com>
References: <IKOYjLXrS8q1GMjbaL2HOBNH8Oa_16k4WBa2NaMngS8=.c6fd7fbb-4758-48b2-a992-3702b2718e59@github.com>
Message-ID: <z8XnCZyLzTrAh8AT9e4OMkusEtjOCLOOJlBMDJyzGfI=.86ef7f0f-ac23-4d18-8b7b-7513c8808da8@github.com>

> The test case has an out of loop `Store` with an `AddP` address
> expression that has other uses and is in the loop body. Schematically,
> only showing the address subgraph and the bases for the `AddP`s:
> 
> 
> Store#195 -> AddP#133 -> AddP#134 -> CastPP#110
>                      -> CastPP#110
> 
> 
> Both `AddP`s have the same base, a `CastPP` that's also in the loop
> body.
> 
> That loop is a counted loop and only has 3 iterations so is fully
> unrolled. First, one iteration is peeled:
> 
> 
>                                 /-> CastPP#110
> Store#195 -> Phi#360 -> AddP#133 -> AddP#134 -> CastPP#110
>                     -> AddP#277 -> AddP#278 -> CastPP#283
>                                 -> CastPP#283
> 
> 
> 
> The `AddP`s and `CastPP` are cloned (because in the loop body). As
> part of peeling, `PhaseIdealLoop::peeled_dom_test_elim()` is
> called. It finds the test that guards `CastPP#283` in the peeled
> iteration dominates and replaces the test that guards `CastPP#110`
> (the test in the peeled iteration is the clone of the test in the
> loop). That causes `CastPP#110`'s control to be updated to that of the
> test in the peeled iteration and to be yanked from the loop. So now
> `CastPP#283` and `CastPP#110` have the same inputs.
> 
> Next unrolling happens:
> 
> 
>                                            /-> CastPP#110
>                                /-> AddP#400 -> AddP#401 -> CastPP#110
> Store#195 -> Phi#360 -> Phi#477 -> AddP#133 -> AddP#134 -> CastPP#110
>                   \                        -> CastPP#110
>                    -> AddP#277 -> AddP#278 -> CastPP#283
>                                -> CastPP#283
> 
> 
> 
> `AddP`s are cloned once more but not the `CastPP`s because they are
> both in the peeled iteration now. A new `Phi` is added.
> 
> Next igvn runs. It's going to push the `AddP`s through the `Phi`s.
> 
> Through `Phi#477`:
> 
> 
> 
>                                 /-> CastPP#110
> Store#195 -> Phi#360 -> AddP#510 -> Phi#509 -> AddP#401 -> CastPP#110
>                   \                        -> AddP#134 -> CastPP#110
>                    -> AddP#277 -> AddP#278 -> CastPP#283
>                                -> CastPP#283
> 
> 
> 
> Through `Phi#360`:
> 
> 
>                                            /-> AddP#134 -> CastPP#110
>                                 /-> Phi#509 -> AddP#401 -> CastPP#110
> Store#195 -> AddP#516 -> Phi#515 -> AddP#278 -> CastPP#283
>                      -> Phi#514 -> CastPP#283
>                                 -> CastP#110
> 
> 
> Then `Phi#514` which has 2 `CastPP`s as input with identical inputs is
> transformed into anot...

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:

 - review
 - Merge branch 'master' into JDK-8351889
 - Update src/hotspot/share/opto/phaseX.hpp
   
   Co-authored-by: Roberto Casta?eda Lozano <robcasloz at users.noreply.github.com>
 - Update src/hotspot/share/opto/phaseX.cpp
   
   Co-authored-by: Roberto Casta?eda Lozano <robcasloz at users.noreply.github.com>
 - review
 - more
 - review
 - Merge branch 'master' into JDK-8351889
 - exp
 - Merge branch 'master' into JDK-8351889
 - ... and 9 more: https://git.openjdk.org/jdk/compare/830e7075...100fad3d

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25386/files
  - new: https://git.openjdk.org/jdk/pull/25386/files/d2174c88..100fad3d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25386&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25386&range=05-06

  Stats: 45025 lines in 629 files changed: 27805 ins; 14178 del; 3042 mod
  Patch: https://git.openjdk.org/jdk/pull/25386.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25386/head:pull/25386

PR: https://git.openjdk.org/jdk/pull/25386

From roland at openjdk.org  Thu Dec 11 16:11:02 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Thu, 11 Dec 2025 16:11:02 GMT
Subject: RFR: 8351889: C2 crash: assertion failed:  Base pointers must
 match (addp 344) [v5]
In-Reply-To: <3u22nbDF6M3weBExSGGYgGvisgMIeqDC4cLN1kIH-m8=.17ee76d4-1652-470f-8b52-af72091b9a95@github.com>
References: <IKOYjLXrS8q1GMjbaL2HOBNH8Oa_16k4WBa2NaMngS8=.c6fd7fbb-4758-48b2-a992-3702b2718e59@github.com>
 <lJ_q1MxUgjyRIHuOAAMwlgZV-V4ZbXicJ78Gyry2dIQ=.b1085ad9-0870-467c-b27a-773a2d4a4e3e@github.com>
 <3u22nbDF6M3weBExSGGYgGvisgMIeqDC4cLN1kIH-m8=.17ee76d4-1652-470f-8b52-af72091b9a95@github.com>
Message-ID: <Dd43S383DWau6RX5f23a2nbUBVdMrJt-KhGUPIZPqnA=.9aa77caf-2085-497e-a5ab-ded365f384b1@github.com>

On Thu, 11 Dec 2025 14:29:16 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review
>
> src/hotspot/share/opto/phaseX.cpp line 2070:
> 
>> 2068:     if (addp->is_AddP() &&
>> 2069:         !addp->in(AddPNode::Base)->is_top() &&
>> 2070:         addp->in(AddPNode::Base) != n->in(AddPNode::Base)) {
> 
> Any way we could avoid this code duplication with the same check in `Compile::final_graph_reshaping_main_switch`?

I pushed a new commit. Is it what you had in mind?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25386#discussion_r2611166125

From eastigeevich at openjdk.org  Thu Dec 11 16:21:51 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Thu, 11 Dec 2025 16:21:51 GMT
Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact
 on GCs and JIT performance [v18]
In-Reply-To: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
Message-ID: <55OALV7rkAyerTV2RKIdh1J1qgZ1hUbHMtB-ND3DRZM=.b37afa75-d56e-4372-81fd-22bab5c2c533@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 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 failures
>       - `containers/docker/TestJcmdWithSideCar.java`: JD...

Evgeny Astigeevich 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 JDK-8370947
 - Fix macos and windows aarch64 builds
 - Add cache DIC IDC status to VM_Version
 - Fix tier3 failures
 - Fix tier1 failures
 - Implement nested ICacheInvalidationContext
 - 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
 - ... and 15 more: https://git.openjdk.org/jdk/compare/aa986be7...fc4bbe9d

-------------

Changes: https://git.openjdk.org/jdk/pull/28328/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28328&range=17
  Stats: 919 lines in 27 files changed: 852 ins; 21 del; 46 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 iklam at openjdk.org  Thu Dec 11 19:13:27 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 11 Dec 2025 19:13:27 GMT
Subject: [jdk26] RFR: 8369736: Add management interface for AOT cache creation
Message-ID: <7ZxAR7KNBo848aKmFEchA-IWSCSPyWIqxaGmjwNa-hs=.03784452-ec97-4109-a6a9-660762c682c4@github.com>

Hi all,

This pull request contains a backport of commit [413f852b](https://github.com/openjdk/jdk/commit/413f852bdb4767b2a1c29431144616668888138d) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Mat Carter on 10 Dec 2025 and was reviewed by Mark Reinhold, Ioi Lam and Kevin Walls.

Thanks!

-------------

Commit messages:
 - Backport 413f852bdb4767b2a1c29431144616668888138d

Changes: https://git.openjdk.org/jdk/pull/28772/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28772&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369736
  Stats: 335 lines in 10 files changed: 332 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/28772.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28772/head:pull/28772

PR: https://git.openjdk.org/jdk/pull/28772

From kvn at openjdk.org  Thu Dec 11 20:45:49 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 11 Dec 2025 20:45:49 GMT
Subject: [jdk26] RFR: 8369736: Add management interface for AOT cache
 creation
In-Reply-To: <7ZxAR7KNBo848aKmFEchA-IWSCSPyWIqxaGmjwNa-hs=.03784452-ec97-4109-a6a9-660762c682c4@github.com>
References: <7ZxAR7KNBo848aKmFEchA-IWSCSPyWIqxaGmjwNa-hs=.03784452-ec97-4109-a6a9-660762c682c4@github.com>
Message-ID: <sNLYYomBlkex9IsLGTFYdarT-EKDghteHWm1uiu6rcs=.b830c2e2-0f23-46bf-bc3d-16aa108f08d1@github.com>

On Thu, 11 Dec 2025 19:05:17 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [413f852b](https://github.com/openjdk/jdk/commit/413f852bdb4767b2a1c29431144616668888138d) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Mat Carter on 10 Dec 2025 and was reviewed by Mark Reinhold, Ioi Lam and Kevin Walls.
> 
> Thanks!

Good

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28772#pullrequestreview-3569226381

From missa at openjdk.org  Fri Dec 12 00:15:50 2025
From: missa at openjdk.org (Mohamed Issa)
Date: Fri, 12 Dec 2025 00:15:50 GMT
Subject: RFR: 8368977: Provide clear naming for AVX10 identifiers [v2]
In-Reply-To: <JZnx2wYn7sTlojACH-CG8c77eMFJo_WxAMA2hEWlSGI=.0ed3a154-f3e9-4815-9039-4ab1629b5060@github.com>
References: <6XYgqaHA0PPZzvnfysKOP5XGP7e_RMkVFt9PV2OT3Gk=.e5f33072-a91a-4e57-99f3-81cc4ae4d844@github.com>
 <JZnx2wYn7sTlojACH-CG8c77eMFJo_WxAMA2hEWlSGI=.0ed3a154-f3e9-4815-9039-4ab1629b5060@github.com>
Message-ID: <Noeha-OYR4D-QqCBFuuLF5IrAG1phoB50zb5VQFtjS8=.c3ac9209-f427-4217-93a3-7a7626c5adc8@github.com>

On Mon, 8 Dec 2025 21:47:16 GMT, Mohamed Issa <missa at openjdk.org> wrote:

>> This is a simple change that renames all AVX10 identifiers to explicitly show which sub-versions are in use. Right now, AVX10.2 is the only case to worry about. The JTREG tests listed below were used to verify correctness with the recommended JVM options mentioned in corresponding source files. Each test included runs through emulation with AVX10.2 enabled and disabled to exercise all possible paths. All modifications and tests used [OpenJDK v26-b24](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B24) as the baseline build.
>> 
>> 1. `jtreg:test/hotspot/jtreg/compiler/codegen/TestByteDoubleVect.java`
>> 2. `jtreg:test/hotspot/jtreg/compiler/codegen/TestByteFloatVect.java`
>> 3. `jtreg:test/hotspot/jtreg/compiler/codegen/TestIntDoubleVect.java`
>> 4. `jtreg:test/hotspot/jtreg/compiler/codegen/TestIntFloatVect.java`
>> 5. `jtreg:test/hotspot/jtreg/compiler/codegen/TestLongDoubleVect.java`
>> 6. `jtreg:test/hotspot/jtreg/compiler/codegen/TestLongFloatVect.java`
>> 7. `jtreg:test/hotspot/jtreg/compiler/codegen/TestShortDoubleVect.java`
>> 8. `jtreg:test/hotspot/jtreg/compiler/codegen/TestShortFloatVect.java`
>> 9. `jtreg:test/hotspot/jtreg/compiler/floatingpoint/ScalarFPtoIntCastTest.java`
>> 10. `jtreg:test/hotspot/jtreg/compiler/vectorapi/VectorFPtoIntCastTest.java`
>> 11. `jtreg:test/hotspot/jtreg/compiler/vectorization/runner/ArrayTypeConvertTest.java`
>> 12. `jtreg:test/jdk/jdk/incubator/vector/Double64VectorTests.java`
>> 13. `jtreg:test/jdk/jdk/incubator/vector/Double128VectorTests.java`
>> 14. `jtreg:test/jdk/jdk/incubator/vector/Double256VectorTests.java`
>> 15. `jtreg:test/jdk/jdk/incubator/vector/Double512VectorTests.java`
>> 16. `jtreg:test/jdk/jdk/incubator/vector/DoubleMaxVectorTests.java`
>> 17. `jtreg:test/jdk/jdk/incubator/vector/Float64VectorTests.java`
>> 18. `jtreg:test/jdk/jdk/incubator/vector/Float128VectorTests.java`
>> 19. `jtreg:test/jdk/jdk/incubator/vector/Float256VectorTests.java`
>> 20. `jtreg:test/jdk/jdk/incubator/vector/Float512VectorTests.java`
>> 21. `jtreg:test/jdk/jdk/incubator/vector/FloatMaxVectorTests.java`
>> 22. `jtreg:test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorOperations.java`
>> 23. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java`
>
> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove changes that affect functionality

@eme64, @mhaessig Ok to test?

@iwanowww In case you want to glance through changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28344#issuecomment-3644338061

From mhaessig at openjdk.org  Fri Dec 12 08:16:58 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Fri, 12 Dec 2025 08:16:58 GMT
Subject: RFR: 8368977: Provide clear naming for AVX10 identifiers [v2]
In-Reply-To: <JZnx2wYn7sTlojACH-CG8c77eMFJo_WxAMA2hEWlSGI=.0ed3a154-f3e9-4815-9039-4ab1629b5060@github.com>
References: <6XYgqaHA0PPZzvnfysKOP5XGP7e_RMkVFt9PV2OT3Gk=.e5f33072-a91a-4e57-99f3-81cc4ae4d844@github.com>
 <JZnx2wYn7sTlojACH-CG8c77eMFJo_WxAMA2hEWlSGI=.0ed3a154-f3e9-4815-9039-4ab1629b5060@github.com>
Message-ID: <sCXqxlanVTIVIVVcYFqqFPJGZpeGe2RvhFhKwvi5bpQ=.83a00788-f8b2-45c4-bd37-c563bb69ed9b@github.com>

On Mon, 8 Dec 2025 21:47:16 GMT, Mohamed Issa <missa at openjdk.org> wrote:

>> This is a simple change that renames all AVX10 identifiers to explicitly show which sub-versions are in use. Right now, AVX10.2 is the only case to worry about. The JTREG tests listed below were used to verify correctness with the recommended JVM options mentioned in corresponding source files. Each test included runs through emulation with AVX10.2 enabled and disabled to exercise all possible paths. All modifications and tests used [OpenJDK v26-b24](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B24) as the baseline build.
>> 
>> 1. `jtreg:test/hotspot/jtreg/compiler/codegen/TestByteDoubleVect.java`
>> 2. `jtreg:test/hotspot/jtreg/compiler/codegen/TestByteFloatVect.java`
>> 3. `jtreg:test/hotspot/jtreg/compiler/codegen/TestIntDoubleVect.java`
>> 4. `jtreg:test/hotspot/jtreg/compiler/codegen/TestIntFloatVect.java`
>> 5. `jtreg:test/hotspot/jtreg/compiler/codegen/TestLongDoubleVect.java`
>> 6. `jtreg:test/hotspot/jtreg/compiler/codegen/TestLongFloatVect.java`
>> 7. `jtreg:test/hotspot/jtreg/compiler/codegen/TestShortDoubleVect.java`
>> 8. `jtreg:test/hotspot/jtreg/compiler/codegen/TestShortFloatVect.java`
>> 9. `jtreg:test/hotspot/jtreg/compiler/floatingpoint/ScalarFPtoIntCastTest.java`
>> 10. `jtreg:test/hotspot/jtreg/compiler/vectorapi/VectorFPtoIntCastTest.java`
>> 11. `jtreg:test/hotspot/jtreg/compiler/vectorization/runner/ArrayTypeConvertTest.java`
>> 12. `jtreg:test/jdk/jdk/incubator/vector/Double64VectorTests.java`
>> 13. `jtreg:test/jdk/jdk/incubator/vector/Double128VectorTests.java`
>> 14. `jtreg:test/jdk/jdk/incubator/vector/Double256VectorTests.java`
>> 15. `jtreg:test/jdk/jdk/incubator/vector/Double512VectorTests.java`
>> 16. `jtreg:test/jdk/jdk/incubator/vector/DoubleMaxVectorTests.java`
>> 17. `jtreg:test/jdk/jdk/incubator/vector/Float64VectorTests.java`
>> 18. `jtreg:test/jdk/jdk/incubator/vector/Float128VectorTests.java`
>> 19. `jtreg:test/jdk/jdk/incubator/vector/Float256VectorTests.java`
>> 20. `jtreg:test/jdk/jdk/incubator/vector/Float512VectorTests.java`
>> 21. `jtreg:test/jdk/jdk/incubator/vector/FloatMaxVectorTests.java`
>> 22. `jtreg:test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorOperations.java`
>> 23. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java`
>
> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove changes that affect functionality

Thank you for this clarification, @missa-prime. This is very helpful.

I'll run testing on our side and report results.

-------------

PR Review: https://git.openjdk.org/jdk/pull/28344#pullrequestreview-3570787062

From tschatzl at openjdk.org  Fri Dec 12 08:47:15 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 12 Dec 2025 08:47:15 GMT
Subject: RFR: 8373449: Parallel: Obsolete deprecated PSChunkLargeArrays
In-Reply-To: <4Qgp_QW_5sreJ5W4srufeKwDQzAd1Ajn601diouyd3g=.2361b5f9-31c3-496f-9121-3df9abfc7bc4@github.com>
References: <4Qgp_QW_5sreJ5W4srufeKwDQzAd1Ajn601diouyd3g=.2361b5f9-31c3-496f-9121-3df9abfc7bc4@github.com>
Message-ID: <YNTlixS3si9IWNoc1zzmpHheowhM8k2pLouvwI7dMFs=.dafe0be6-a17d-43d4-9c21-906729b39b99@github.com>

On Wed, 10 Dec 2025 18:09:17 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Obsolete a deprecated jvm flag. Its default value is `true`.
> 
> Test: tier1-3

Marked as reviewed by tschatzl (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28754#pullrequestreview-3570876100

From kbarrett at openjdk.org  Fri Dec 12 09:05:52 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 12 Dec 2025 09:05:52 GMT
Subject: RFR: 8373449: Parallel: Obsolete deprecated PSChunkLargeArrays
In-Reply-To: <4Qgp_QW_5sreJ5W4srufeKwDQzAd1Ajn601diouyd3g=.2361b5f9-31c3-496f-9121-3df9abfc7bc4@github.com>
References: <4Qgp_QW_5sreJ5W4srufeKwDQzAd1Ajn601diouyd3g=.2361b5f9-31c3-496f-9121-3df9abfc7bc4@github.com>
Message-ID: <GnGujdsix-zjHcbaT7V_vfTTZhStvNtim0yjx_LVHVE=.c4786b18-4394-42d4-ab81-0a0e20370f7c@github.com>

On Wed, 10 Dec 2025 18:09:17 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Obsolete a deprecated jvm flag. Its default value is `true`.
> 
> Test: tier1-3

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28754#pullrequestreview-3570946339

From duke at openjdk.org  Fri Dec 12 09:43:31 2025
From: duke at openjdk.org (SilenceZheng66)
Date: Fri, 12 Dec 2025 09:43:31 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v22]
In-Reply-To: <rAPcRMkxD0uoJTzadbMR7eui7ixfiVHCKy8JCvS5TPc=.6307f4fd-e333-41c8-97f2-81971974eb93@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <rAPcRMkxD0uoJTzadbMR7eui7ixfiVHCKy8JCvS5TPc=.6307f4fd-e333-41c8-97f2-81971974eb93@github.com>
Message-ID: <C2nKyRSBdqEqIK0I3bEP1X4PM1K3Gb3HhPaxqgJeIS8=.62ffb736-16a7-4da9-8d11-1c147dfb40a1@github.com>

On Fri, 18 Jul 2025 13:13:38 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
>> 
>> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
>> 
>> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
>> 
>> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
>> 
>> ## Performance evaluation
>> 
>> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
>> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
>> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
>> 
>> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging.
>> 
>> Test: tier1-8
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits:
> 
>  - merge
>  - Merge branch 'master' into pgc-size-policy
>  - review
>  - review
>  - Merge branch 'master' into pgc-size-policy
>  - review
>  - review
>  - Merge branch 'master' into pgc-size-policy
>  - Merge branch 'master' into pgc-size-policy
>  - review
>  - ... and 23 more: https://git.openjdk.org/jdk/compare/7da274de...295dc853

src/hotspot/share/gc/parallel/psParallelCompact.cpp line 1070:

> 1068:     size_policy->sample_old_gen_used_bytes(MAX2(pre_gc_values.old_gen_used(), old_gen->used_in_bytes()));
> 1069: 
> 1070:     if (UseAdaptiveSizePolicy) {

I think this code block could raise heap size don't expand in some specific case, maybe you should optimize it. @albertnetymk

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2613566233

From dlong at openjdk.org  Fri Dec 12 10:15:59 2025
From: dlong at openjdk.org (Dean Long)
Date: Fri, 12 Dec 2025 10:15:59 GMT
Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() [v6]
In-Reply-To: <4n3LwIItTdN__WjnZZkHYDV25HWhFkpshLm_ngr3Rl8=.76385eac-68bf-47bd-81fd-c96e1eb16814@github.com>
References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com>
 <CEvEqPtlTMiv7fX1G_spyCpyl8afEZn4McrzIBd5GRY=.d233254e-3626-4044-a3e1-c82bcbd55e45@github.com>
 <NtMPMeCg0Pr3xvm6APh556G0XHh9ZuOJrX0ZhWqDRXM=.81294a86-b76f-4ed3-aa4b-d6afd72b09af@github.com>
 <4n3LwIItTdN__WjnZZkHYDV25HWhFkpshLm_ngr3Rl8=.76385eac-68bf-47bd-81fd-c96e1eb16814@github.com>
Message-ID: <6k0jwjNuqZbpH1bjPxJg2qw6Hug9gL1IQV2Na16gWgw=.eaec40ba-cdf1-414f-b138-1837698cd42e@github.com>

On Thu, 11 Dec 2025 09:04:22 GMT, Andrew Haley <aph at openjdk.org> wrote:

> I see your point. However, I don't see the comments to which you refer. Please, where are they?

Sorry, I meant the new comment in set_to_interpreted, in particular starting around line 145 "If a racing thread reaches the static call stub .... Initially we place an ISB at the start of the static call stub."  The way I read that and the litmus test below it is that we need to go from ISB to B .+4 every time we update the MOVs.  The litmus test assumes we start with ISB.  There is no litmus test for the case where the entry point has already been patched to B .+4 and then we want to update the MOVs again.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26638#issuecomment-3645830913

From dholmes at openjdk.org  Fri Dec 12 10:42:53 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 12 Dec 2025 10:42:53 GMT
Subject: RFR: 8373497: SpinCriticalSection should use SpinYield
In-Reply-To: <RHXygdCF_IpKSJEDYgnHslxOdjUC1YjvssLitKsERv4=.a51620a1-963d-464b-9f97-03e76a7b5d9b@github.com>
References: <RHXygdCF_IpKSJEDYgnHslxOdjUC1YjvssLitKsERv4=.a51620a1-963d-464b-9f97-03e76a7b5d9b@github.com>
Message-ID: <iH2-bECOiTPfCOqQUFtwKdWVo_4vGrNx977jSye-7OE=.0af0c691-5b15-4919-8e41-c7e55217895e@github.com>

On Thu, 11 Dec 2025 09:09:05 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> The original code of `Thread::SpinAqcuire()` was moved into a RAII object `SpinCriticalSection` in https://bugs.openjdk.org/browse/JDK-8366671
> 
> It to a great extent duplicates the code of the `SpinYield` class, which is more flexible. In this PR the duplication is removed as `SpinCriticalSection` now makes uses of  `SpinYield`.
> 
> Tested in tiers 1-3.
> 
> Extended performance testing has shown that the change is neutral.

Looks like a good cleanup. Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28763#pullrequestreview-3569977831

From mhaessig at openjdk.org  Fri Dec 12 12:47:16 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Fri, 12 Dec 2025 12:47:16 GMT
Subject: RFR: 8370519: C2: Hit MemLimit when running with
 +VerifyLoopOptimizations [v6]
In-Reply-To: <ivWBI33pO0sKOtifG2aGTozX0ybXkxSazNW-T5rpJyU=.a77a85c6-3540-4ce8-8b82-db7bae444615@github.com>
References: <W7EnT28-84mtwppISdr_ydCV9HSaXk72y7fyd29z4wQ=.7331c81d-c36f-4a1c-b949-e7045f524d07@github.com>
 <ivWBI33pO0sKOtifG2aGTozX0ybXkxSazNW-T5rpJyU=.a77a85c6-3540-4ce8-8b82-db7bae444615@github.com>
Message-ID: <0jWlBghKGEMjDb4DrpXH_Uhy7EMjdaqenRMoD-Bfu4Y=.78c9a448-8a3d-481f-95d4-aecba4a9e700@github.com>

On Thu, 11 Dec 2025 15:42:42 GMT, Roland Westrelin <roland at openjdk.org> 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

The new changes look good to me. I'll kick off some more testing.

-------------

PR Review: https://git.openjdk.org/jdk/pull/28581#pullrequestreview-3529839561

From mhaessig at openjdk.org  Fri Dec 12 12:47:20 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Fri, 12 Dec 2025 12:47:20 GMT
Subject: RFR: 8370519: C2: Hit MemLimit when running with
 +VerifyLoopOptimizations [v3]
In-Reply-To: <FkXbOvbukpCfSEBmYIOsn1IUaRnPZhEYv3yfz3Dz-QQ=.da549428-ed90-424e-8a77-dac3a745ed67@github.com>
References: <W7EnT28-84mtwppISdr_ydCV9HSaXk72y7fyd29z4wQ=.7331c81d-c36f-4a1c-b949-e7045f524d07@github.com>
 <FkXbOvbukpCfSEBmYIOsn1IUaRnPZhEYv3yfz3Dz-QQ=.da549428-ed90-424e-8a77-dac3a745ed67@github.com>
Message-ID: <m1FIyWeqkSgHinOhZsEPuxMZ9YGBBEsDLcPwA-ZCgbc=.522407ea-726b-4868-8393-a5bc8781a70a@github.com>

On Tue, 2 Dec 2025 11:21:05 GMT, Roland Westrelin <roland at openjdk.org> 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 two additional commits since the last revision:
> 
>  - review
>  - review

src/hotspot/share/opto/loopnode.hpp line 672:

> 670:   bool  _allow_optimizations;   // Allow loop optimizations
> 671: 
> 672:   IdealLoopTree( PhaseIdealLoop* phase, Node *head, Node *tail );

Suggestion:

  IdealLoopTree( PhaseIdealLoop* phase, Node* head, Node* tail );

Since you are changing this line.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28581#discussion_r2580968318

From mhaessig at openjdk.org  Fri Dec 12 12:52:03 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Fri, 12 Dec 2025 12:52:03 GMT
Subject: RFR: 8368977: Provide clear naming for AVX10 identifiers [v2]
In-Reply-To: <JZnx2wYn7sTlojACH-CG8c77eMFJo_WxAMA2hEWlSGI=.0ed3a154-f3e9-4815-9039-4ab1629b5060@github.com>
References: <6XYgqaHA0PPZzvnfysKOP5XGP7e_RMkVFt9PV2OT3Gk=.e5f33072-a91a-4e57-99f3-81cc4ae4d844@github.com>
 <JZnx2wYn7sTlojACH-CG8c77eMFJo_WxAMA2hEWlSGI=.0ed3a154-f3e9-4815-9039-4ab1629b5060@github.com>
Message-ID: <nHZKlpgmGxvRBxipbotAGB0ncBzRVdEID0Q_pGvmF0w=.7acbb9a2-2571-4603-b511-c6f0e5c1aa6d@github.com>

On Mon, 8 Dec 2025 21:47:16 GMT, Mohamed Issa <missa at openjdk.org> wrote:

>> This is a simple change that renames all AVX10 identifiers to explicitly show which sub-versions are in use. Right now, AVX10.2 is the only case to worry about. The JTREG tests listed below were used to verify correctness with the recommended JVM options mentioned in corresponding source files. Each test included runs through emulation with AVX10.2 enabled and disabled to exercise all possible paths. All modifications and tests used [OpenJDK v26-b24](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B24) as the baseline build.
>> 
>> 1. `jtreg:test/hotspot/jtreg/compiler/codegen/TestByteDoubleVect.java`
>> 2. `jtreg:test/hotspot/jtreg/compiler/codegen/TestByteFloatVect.java`
>> 3. `jtreg:test/hotspot/jtreg/compiler/codegen/TestIntDoubleVect.java`
>> 4. `jtreg:test/hotspot/jtreg/compiler/codegen/TestIntFloatVect.java`
>> 5. `jtreg:test/hotspot/jtreg/compiler/codegen/TestLongDoubleVect.java`
>> 6. `jtreg:test/hotspot/jtreg/compiler/codegen/TestLongFloatVect.java`
>> 7. `jtreg:test/hotspot/jtreg/compiler/codegen/TestShortDoubleVect.java`
>> 8. `jtreg:test/hotspot/jtreg/compiler/codegen/TestShortFloatVect.java`
>> 9. `jtreg:test/hotspot/jtreg/compiler/floatingpoint/ScalarFPtoIntCastTest.java`
>> 10. `jtreg:test/hotspot/jtreg/compiler/vectorapi/VectorFPtoIntCastTest.java`
>> 11. `jtreg:test/hotspot/jtreg/compiler/vectorization/runner/ArrayTypeConvertTest.java`
>> 12. `jtreg:test/jdk/jdk/incubator/vector/Double64VectorTests.java`
>> 13. `jtreg:test/jdk/jdk/incubator/vector/Double128VectorTests.java`
>> 14. `jtreg:test/jdk/jdk/incubator/vector/Double256VectorTests.java`
>> 15. `jtreg:test/jdk/jdk/incubator/vector/Double512VectorTests.java`
>> 16. `jtreg:test/jdk/jdk/incubator/vector/DoubleMaxVectorTests.java`
>> 17. `jtreg:test/jdk/jdk/incubator/vector/Float64VectorTests.java`
>> 18. `jtreg:test/jdk/jdk/incubator/vector/Float128VectorTests.java`
>> 19. `jtreg:test/jdk/jdk/incubator/vector/Float256VectorTests.java`
>> 20. `jtreg:test/jdk/jdk/incubator/vector/Float512VectorTests.java`
>> 21. `jtreg:test/jdk/jdk/incubator/vector/FloatMaxVectorTests.java`
>> 22. `jtreg:test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorOperations.java`
>> 23. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java`
>
> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove changes that affect functionality

Testing tier1-3 passed

-------------

Marked as reviewed by mhaessig (Committer).

PR Review: https://git.openjdk.org/jdk/pull/28344#pullrequestreview-3571695712

From coleenp at openjdk.org  Fri Dec 12 13:13:52 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 12 Dec 2025 13:13:52 GMT
Subject: RFR: 8373497: SpinCriticalSection should use SpinYield
In-Reply-To: <RHXygdCF_IpKSJEDYgnHslxOdjUC1YjvssLitKsERv4=.a51620a1-963d-464b-9f97-03e76a7b5d9b@github.com>
References: <RHXygdCF_IpKSJEDYgnHslxOdjUC1YjvssLitKsERv4=.a51620a1-963d-464b-9f97-03e76a7b5d9b@github.com>
Message-ID: <0mwpdYvblZT_wpA4M9af5IlyZnHRZctR85y4kWAByeI=.f352d845-8953-4928-b6c1-609380e3df32@github.com>

On Thu, 11 Dec 2025 09:09:05 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> The original code of `Thread::SpinAqcuire()` was moved into a RAII object `SpinCriticalSection` in https://bugs.openjdk.org/browse/JDK-8366671
> 
> It to a great extent duplicates the code of the `SpinYield` class, which is more flexible. In this PR the duplication is removed as `SpinCriticalSection` now makes uses of  `SpinYield`.
> 
> Tested in tiers 1-3.
> 
> Extended performance testing has shown that the change is neutral.

Thank you!!

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28763#pullrequestreview-3571764534

From stefank at openjdk.org  Fri Dec 12 14:21:57 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 12 Dec 2025 14:21:57 GMT
Subject: RFR: 8373599: Cleanup arguments.hpp includes
Message-ID: <Qk3QT6NyM0BgtE_qbj_s8LrSR8bTloYqu8ojT51cgEs=.f60dd6b4-e844-4b46-82a3-69efafe0206d@github.com>

In the Valhalla project we are considering using a property in Arguments to figure out if Valhalla is enabled. To minimize transitive-include-proliferation if this property ever needs to be checked in a header I propose that we clean up the header includes in arguments.hpp.

I'm opening the review for this so that I can get opinions on the move of functions. I'm going to compile this on all our platforms and will likely add a few more includes when unrelated files fail to compile because they relied on the includes provided through by java.hpp and arguments.hpp.

-------------

Commit messages:
 - 8373599

Changes: https://git.openjdk.org/jdk/pull/28791/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28791&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373599
  Stats: 68 lines in 7 files changed: 38 ins; 20 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/28791.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28791/head:pull/28791

PR: https://git.openjdk.org/jdk/pull/28791

From iklam at openjdk.org  Fri Dec 12 14:33:14 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 12 Dec 2025 14:33:14 GMT
Subject: [jdk26] RFR: 8369736: Add management interface for AOT cache
 creation
In-Reply-To: <sNLYYomBlkex9IsLGTFYdarT-EKDghteHWm1uiu6rcs=.b830c2e2-0f23-46bf-bc3d-16aa108f08d1@github.com>
References: <7ZxAR7KNBo848aKmFEchA-IWSCSPyWIqxaGmjwNa-hs=.03784452-ec97-4109-a6a9-660762c682c4@github.com>
 <sNLYYomBlkex9IsLGTFYdarT-EKDghteHWm1uiu6rcs=.b830c2e2-0f23-46bf-bc3d-16aa108f08d1@github.com>
Message-ID: <_kA4bTDICP0GPkKHWYobWxOKJ4XXQDkOonFi7Zr_GlY=.742b2034-8086-48d0-803b-874428cd8214@github.com>

On Thu, 11 Dec 2025 20:43:11 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Hi all,
>> 
>> This pull request contains a backport of commit [413f852b](https://github.com/openjdk/jdk/commit/413f852bdb4767b2a1c29431144616668888138d) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>> 
>> The commit being backported was authored by Mat Carter on 10 Dec 2025 and was reviewed by Mark Reinhold, Ioi Lam and Kevin Walls.
>> 
>> Thanks!
>
> Good

Thanks @vnkozlov for the review
Passed tiers 1 - 4 and builds-tier-5

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28772#issuecomment-3646707792

From iklam at openjdk.org  Fri Dec 12 14:36:42 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 12 Dec 2025 14:36:42 GMT
Subject: [jdk26] Integrated: 8369736: Add management interface for AOT cache
 creation
In-Reply-To: <7ZxAR7KNBo848aKmFEchA-IWSCSPyWIqxaGmjwNa-hs=.03784452-ec97-4109-a6a9-660762c682c4@github.com>
References: <7ZxAR7KNBo848aKmFEchA-IWSCSPyWIqxaGmjwNa-hs=.03784452-ec97-4109-a6a9-660762c682c4@github.com>
Message-ID: <qFwM_ybl67eTZMO_XCyFNisH7fP40fWYjNg3IABJVF8=.93f68a4b-45cb-403a-9184-be8c50c36efb@github.com>

On Thu, 11 Dec 2025 19:05:17 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [413f852b](https://github.com/openjdk/jdk/commit/413f852bdb4767b2a1c29431144616668888138d) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Mat Carter on 10 Dec 2025 and was reviewed by Mark Reinhold, Ioi Lam and Kevin Walls.
> 
> Thanks!

This pull request has now been integrated.

Changeset: d9bc8221
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d9bc82216842bf521ccb7c451b4b411adb0cf3cc
Stats:     335 lines in 10 files changed: 332 ins; 0 del; 3 mod

8369736: Add management interface for AOT cache creation

Reviewed-by: kvn
Backport-of: 413f852bdb4767b2a1c29431144616668888138d

-------------

PR: https://git.openjdk.org/jdk/pull/28772

From iklam at openjdk.org  Fri Dec 12 15:03:01 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 12 Dec 2025 15:03:01 GMT
Subject: RFR: 8373441: Remove DCmdFactory::_enabled
Message-ID: <XE188S-C6EdTA2PRsdsQTi4Z550PW6DNpL3awvANazU=.1b0cd4d1-56cd-491a-b80c-8e2bafcc78ca@github.com>

The `DCmdFactory::_enabled` is always set to `true` and there doesn't seem to be a reason to set it to `false`.

This PR removes this field and simplified the creation of `DCmdFactory` objects.

The related `_hidden` field is also currently not used, but may be used in the future when deprecating DCmds, so we leave it unchanged.

Note that now `jmm_GetDiagnosticCommandInfo()` always set `dcmdInfo::enabled` to `true` to be compatible with Java code.

-------------

Commit messages:
 - Added comments about Java API
 - 8373441: Remove DCmdFactory::_enabled

Changes: https://git.openjdk.org/jdk/pull/28794/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28794&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373441
  Stats: 100 lines in 6 files changed: 4 ins; 25 del; 71 mod
  Patch: https://git.openjdk.org/jdk/pull/28794.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28794/head:pull/28794

PR: https://git.openjdk.org/jdk/pull/28794

From stefank at openjdk.org  Fri Dec 12 15:06:39 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 12 Dec 2025 15:06:39 GMT
Subject: RFR: 8373599: Cleanup arguments.hpp includes [v2]
In-Reply-To: <Qk3QT6NyM0BgtE_qbj_s8LrSR8bTloYqu8ojT51cgEs=.f60dd6b4-e844-4b46-82a3-69efafe0206d@github.com>
References: <Qk3QT6NyM0BgtE_qbj_s8LrSR8bTloYqu8ojT51cgEs=.f60dd6b4-e844-4b46-82a3-69efafe0206d@github.com>
Message-ID: <Kqz_5CO6d3_qHfiP4oBX9R8-w4XhLgf41eFGcBPABRM=.64ef1a0f-20b2-4adb-ba32-4b96b5310319@github.com>

> In the Valhalla project we are considering using a property in Arguments to figure out if Valhalla is enabled. To minimize transitive-include-proliferation if this property ever needs to be checked in a header I propose that we clean up the header includes in arguments.hpp.
> 
> I'm opening the review for this so that I can get opinions on the move of functions. I'm going to compile this on all our platforms and will likely add a few more includes when unrelated files fail to compile because they relied on the includes provided through by java.hpp and arguments.hpp.

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Sort order

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28791/files
  - new: https://git.openjdk.org/jdk/pull/28791/files/e1d1bf61..90f3919c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28791&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28791&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28791.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28791/head:pull/28791

PR: https://git.openjdk.org/jdk/pull/28791

From rcastanedalo at openjdk.org  Fri Dec 12 15:40:47 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 12 Dec 2025 15:40:47 GMT
Subject: RFR: 8351889: C2 crash: assertion failed:  Base pointers must
 match (addp 344) [v7]
In-Reply-To: <z8XnCZyLzTrAh8AT9e4OMkusEtjOCLOOJlBMDJyzGfI=.86ef7f0f-ac23-4d18-8b7b-7513c8808da8@github.com>
References: <IKOYjLXrS8q1GMjbaL2HOBNH8Oa_16k4WBa2NaMngS8=.c6fd7fbb-4758-48b2-a992-3702b2718e59@github.com>
 <z8XnCZyLzTrAh8AT9e4OMkusEtjOCLOOJlBMDJyzGfI=.86ef7f0f-ac23-4d18-8b7b-7513c8808da8@github.com>
Message-ID: <IayFdH9iFOuvlJCeK4g9SsaDauFCKsE2vO4xbaQppzs=.c71d6102-856a-408e-a485-97eecd06f1ca@github.com>

On Thu, 11 Dec 2025 16:10:58 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> The test case has an out of loop `Store` with an `AddP` address
>> expression that has other uses and is in the loop body. Schematically,
>> only showing the address subgraph and the bases for the `AddP`s:
>> 
>> 
>> Store#195 -> AddP#133 -> AddP#134 -> CastPP#110
>>                      -> CastPP#110
>> 
>> 
>> Both `AddP`s have the same base, a `CastPP` that's also in the loop
>> body.
>> 
>> That loop is a counted loop and only has 3 iterations so is fully
>> unrolled. First, one iteration is peeled:
>> 
>> 
>>                                 /-> CastPP#110
>> Store#195 -> Phi#360 -> AddP#133 -> AddP#134 -> CastPP#110
>>                     -> AddP#277 -> AddP#278 -> CastPP#283
>>                                 -> CastPP#283
>> 
>> 
>> 
>> The `AddP`s and `CastPP` are cloned (because in the loop body). As
>> part of peeling, `PhaseIdealLoop::peeled_dom_test_elim()` is
>> called. It finds the test that guards `CastPP#283` in the peeled
>> iteration dominates and replaces the test that guards `CastPP#110`
>> (the test in the peeled iteration is the clone of the test in the
>> loop). That causes `CastPP#110`'s control to be updated to that of the
>> test in the peeled iteration and to be yanked from the loop. So now
>> `CastPP#283` and `CastPP#110` have the same inputs.
>> 
>> Next unrolling happens:
>> 
>> 
>>                                            /-> CastPP#110
>>                                /-> AddP#400 -> AddP#401 -> CastPP#110
>> Store#195 -> Phi#360 -> Phi#477 -> AddP#133 -> AddP#134 -> CastPP#110
>>                   \                        -> CastPP#110
>>                    -> AddP#277 -> AddP#278 -> CastPP#283
>>                                -> CastPP#283
>> 
>> 
>> 
>> `AddP`s are cloned once more but not the `CastPP`s because they are
>> both in the peeled iteration now. A new `Phi` is added.
>> 
>> Next igvn runs. It's going to push the `AddP`s through the `Phi`s.
>> 
>> Through `Phi#477`:
>> 
>> 
>> 
>>                                 /-> CastPP#110
>> Store#195 -> Phi#360 -> AddP#510 -> Phi#509 -> AddP#401 -> CastPP#110
>>                   \                        -> AddP#134 -> CastPP#110
>>                    -> AddP#277 -> AddP#278 -> CastPP#283
>>                                -> CastPP#283
>> 
>> 
>> 
>> Through `Phi#360`:
>> 
>> 
>>                                            /-> AddP#134 -> CastPP#110
>>                                 /-> Phi#509 -> AddP#401 -> CastPP#110
>> Store#195 -> AddP#516 -> Phi#515 -> AddP#278 -> CastPP#283
>>                      -> Phi#514 -> CastPP#283
>>  ...
>
> 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:
> 
>  - review
>  - Merge branch 'master' into JDK-8351889
>  - Update src/hotspot/share/opto/phaseX.hpp
>    
>    Co-authored-by: Roberto Casta?eda Lozano <robcasloz at users.noreply.github.com>
>  - Update src/hotspot/share/opto/phaseX.cpp
>    
>    Co-authored-by: Roberto Casta?eda Lozano <robcasloz at users.noreply.github.com>
>  - review
>  - more
>  - review
>  - Merge branch 'master' into JDK-8351889
>  - exp
>  - Merge branch 'master' into JDK-8351889
>  - ... and 9 more: https://git.openjdk.org/jdk/compare/fc520c13...100fad3d

Looks good!

-------------

Marked as reviewed by rcastanedalo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25386#pullrequestreview-3572383700

From coleenp at openjdk.org  Fri Dec 12 15:45:26 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 12 Dec 2025 15:45:26 GMT
Subject: RFR: 8373599: Cleanup arguments.hpp includes [v2]
In-Reply-To: <Kqz_5CO6d3_qHfiP4oBX9R8-w4XhLgf41eFGcBPABRM=.64ef1a0f-20b2-4adb-ba32-4b96b5310319@github.com>
References: <Qk3QT6NyM0BgtE_qbj_s8LrSR8bTloYqu8ojT51cgEs=.f60dd6b4-e844-4b46-82a3-69efafe0206d@github.com>
 <Kqz_5CO6d3_qHfiP4oBX9R8-w4XhLgf41eFGcBPABRM=.64ef1a0f-20b2-4adb-ba32-4b96b5310319@github.com>
Message-ID: <LYAbIbgu10sGhEtVWI47ZD1RJ3kOJ3FgEr786RFL2b0=.aaa1965d-6a74-4653-96eb-5192210274b8@github.com>

On Fri, 12 Dec 2025 15:06:39 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> In the Valhalla project we are considering using a property in Arguments to figure out if Valhalla is enabled. To minimize transitive-include-proliferation if this property ever needs to be checked in a header I propose that we clean up the header includes in arguments.hpp.
>> 
>> I'm opening the review for this so that I can get opinions on the move of functions. I'm going to compile this on all our platforms and will likely add a few more includes when unrelated files fail to compile because they relied on the includes provided through by java.hpp and arguments.hpp.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Sort order

This looks good, pending all the platforms building.  Thanks!

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28791#pullrequestreview-3572410510

From jsjolen at openjdk.org  Fri Dec 12 15:54:00 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 12 Dec 2025 15:54:00 GMT
Subject: RFR: 8373441: Remove DCmdFactory::_enabled
In-Reply-To: <XE188S-C6EdTA2PRsdsQTi4Z550PW6DNpL3awvANazU=.1b0cd4d1-56cd-491a-b80c-8e2bafcc78ca@github.com>
References: <XE188S-C6EdTA2PRsdsQTi4Z550PW6DNpL3awvANazU=.1b0cd4d1-56cd-491a-b80c-8e2bafcc78ca@github.com>
Message-ID: <QYbz0RunslxVNZl_SNODduk9j5kl7LXpfiXiCUu9A9w=.4f7bdb43-9f66-4b9a-aa66-b6c7340cc7af@github.com>

On Fri, 12 Dec 2025 14:54:52 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The `DCmdFactory::_enabled` is always set to `true` and there doesn't seem to be a reason to set it to `false`.
> 
> This PR removes this field and simplified the creation of `DCmdFactory` objects.
> 
> The related `_hidden` field is also currently not used, but may be used in the future when deprecating DCmds, so we leave it unchanged.
> 
> Note that now `jmm_GetDiagnosticCommandInfo()` always set `dcmdInfo::enabled` to `true` to be compatible with Java code.

Fine by me, thanks.

-------------

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28794#pullrequestreview-3572462286

From qamai at openjdk.org  Fri Dec 12 16:06:22 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 12 Dec 2025 16:06:22 GMT
Subject: RFR: 8373591: C2: Fix the memory around some intrinsics nodes [v2]
In-Reply-To: <xqPVnw7PtK7ch97NBoScQARyosgTZhsq8Jypd6h2Cyg=.61115100-f6f0-4f16-a01c-33e587b3ecaf@github.com>
References: <xqPVnw7PtK7ch97NBoScQARyosgTZhsq8Jypd6h2Cyg=.61115100-f6f0-4f16-a01c-33e587b3ecaf@github.com>
Message-ID: <zJUpknUHAneMzbCwodxCiOYpjTHLMpgk2Lh8Q9h5luk=.80948152-f7e3-4665-ae47-96be1c4dc163@github.com>

> Hi,
> 
> This is extracted from #28570 , there are 2 issues here:
> 
> - Some intrinsics nodes advertise incorrect `adr_type`. For example, `AryEqNode` reports `adr_type` being `TypeAryPtr::BYTES` (it inherits this from `StrIntrinsicNode`). This is incorrect, however, as it can accept `char[]` inputs, too. Another case is `VectorizedHashCodeNode`, which reports its `adr_type` being `TypePtr::BOTTOM`, but it actually extracts a memory slice and does not consume the whole memory.
> - For nodes such as `StrInflatedCopyNode`, as they consume more than they produce, during scheduling, we need to compute anti-dependencies. This is not the case, so we should fix it by making the nodes kill all the memory they consume. This issue is often not present because these intrinsics are not exposed bare to general usage.
> 
> Please kindly review, thanks a lot.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  Fix Shenandoah

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28789/files
  - new: https://git.openjdk.org/jdk/pull/28789/files/e9789170..1e026354

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28789&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28789&range=00-01

  Stats: 10 lines in 1 file changed: 8 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28789.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28789/head:pull/28789

PR: https://git.openjdk.org/jdk/pull/28789

From iklam at openjdk.org  Fri Dec 12 16:06:38 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 12 Dec 2025 16:06:38 GMT
Subject: RFR: 8373599: Cleanup arguments.hpp includes [v2]
In-Reply-To: <Kqz_5CO6d3_qHfiP4oBX9R8-w4XhLgf41eFGcBPABRM=.64ef1a0f-20b2-4adb-ba32-4b96b5310319@github.com>
References: <Qk3QT6NyM0BgtE_qbj_s8LrSR8bTloYqu8ojT51cgEs=.f60dd6b4-e844-4b46-82a3-69efafe0206d@github.com>
 <Kqz_5CO6d3_qHfiP4oBX9R8-w4XhLgf41eFGcBPABRM=.64ef1a0f-20b2-4adb-ba32-4b96b5310319@github.com>
Message-ID: <0fc2IQc2RkDUTux87XaoVxpydiYxLri9nI7ijYzibPg=.9a9b8a3b-8e7c-4485-aa6d-79a9dbd9a3dd@github.com>

On Fri, 12 Dec 2025 15:06:39 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> In the Valhalla project we are considering using a property in Arguments to figure out if Valhalla is enabled. To minimize transitive-include-proliferation if this property ever needs to be checked in a header I propose that we clean up the header includes in arguments.hpp.
>> 
>> I'm opening the review for this so that I can get opinions on the move of functions. I'm going to compile this on all our platforms and will likely add a few more includes when unrelated files fail to compile because they relied on the includes provided through by java.hpp and arguments.hpp.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Sort order

I think this clean up is good by itself.

However, do you plan to include arguments.hpp in a lot of files (including files) just to check if valhalla is enabled?

If that's the case, I think it's better to move the check into its own header, similar to existing files like cdsConfig.hpp and gcConfig.hpp.  Maybe valueTypeConfig.hpp?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28791#issuecomment-3647181924

From coleenp at openjdk.org  Fri Dec 12 16:09:35 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 12 Dec 2025 16:09:35 GMT
Subject: RFR: 8373599: Cleanup arguments.hpp includes [v2]
In-Reply-To: <Kqz_5CO6d3_qHfiP4oBX9R8-w4XhLgf41eFGcBPABRM=.64ef1a0f-20b2-4adb-ba32-4b96b5310319@github.com>
References: <Qk3QT6NyM0BgtE_qbj_s8LrSR8bTloYqu8ojT51cgEs=.f60dd6b4-e844-4b46-82a3-69efafe0206d@github.com>
 <Kqz_5CO6d3_qHfiP4oBX9R8-w4XhLgf41eFGcBPABRM=.64ef1a0f-20b2-4adb-ba32-4b96b5310319@github.com>
Message-ID: <LmK9lPPY7_-ocTxTnEEitCCCoUtBHSi15NiPfDnu7ug=.dafb21f9-b3e0-4704-9a14-b9f44a7aed5b@github.com>

On Fri, 12 Dec 2025 15:06:39 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> In the Valhalla project we are considering using a property in Arguments to figure out if Valhalla is enabled. To minimize transitive-include-proliferation if this property ever needs to be checked in a header I propose that we clean up the header includes in arguments.hpp.
>> 
>> I'm opening the review for this so that I can get opinions on the move of functions. I'm going to compile this on all our platforms and will likely add a few more includes when unrelated files fail to compile because they relied on the includes provided through by java.hpp and arguments.hpp.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Sort order

Let's see how many files end up with enable_valhalla() first, then decide, after @Arraying work on https://bugs.openjdk.org/browse/JDK-8371357.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28791#issuecomment-3647194853

From phubner at openjdk.org  Fri Dec 12 16:18:50 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Fri, 12 Dec 2025 16:18:50 GMT
Subject: RFR: 8373599: Cleanup arguments.hpp includes [v2]
In-Reply-To: <LmK9lPPY7_-ocTxTnEEitCCCoUtBHSi15NiPfDnu7ug=.dafb21f9-b3e0-4704-9a14-b9f44a7aed5b@github.com>
References: <Qk3QT6NyM0BgtE_qbj_s8LrSR8bTloYqu8ojT51cgEs=.f60dd6b4-e844-4b46-82a3-69efafe0206d@github.com>
 <Kqz_5CO6d3_qHfiP4oBX9R8-w4XhLgf41eFGcBPABRM=.64ef1a0f-20b2-4adb-ba32-4b96b5310319@github.com>
 <LmK9lPPY7_-ocTxTnEEitCCCoUtBHSi15NiPfDnu7ug=.dafb21f9-b3e0-4704-9a14-b9f44a7aed5b@github.com>
Message-ID: <YH-LB1hQNQmEK8pt50Gd23vU_iuf99RTroSexMeFMFM=.767beb08-5b70-4340-95ac-73d35c630dc6@github.com>

On Fri, 12 Dec 2025 16:06:52 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Let's see how many files end up with enable_valhalla() first, then decide, after @Arraying work on https://bugs.openjdk.org/browse/JDK-8371357.

As of right now 37 non-test files have `is_valhalla_enabled()` and 26 new `#include "runtime/arguments.hpp` if I scripted correctly. I don't anticipate those numbers changing much until integration.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28791#issuecomment-3647230267

From stefank at openjdk.org  Fri Dec 12 16:24:53 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 12 Dec 2025 16:24:53 GMT
Subject: RFR: 8373599: Cleanup arguments.hpp includes [v2]
In-Reply-To: <0fc2IQc2RkDUTux87XaoVxpydiYxLri9nI7ijYzibPg=.9a9b8a3b-8e7c-4485-aa6d-79a9dbd9a3dd@github.com>
References: <Qk3QT6NyM0BgtE_qbj_s8LrSR8bTloYqu8ojT51cgEs=.f60dd6b4-e844-4b46-82a3-69efafe0206d@github.com>
 <Kqz_5CO6d3_qHfiP4oBX9R8-w4XhLgf41eFGcBPABRM=.64ef1a0f-20b2-4adb-ba32-4b96b5310319@github.com>
 <0fc2IQc2RkDUTux87XaoVxpydiYxLri9nI7ijYzibPg=.9a9b8a3b-8e7c-4485-aa6d-79a9dbd9a3dd@github.com>
Message-ID: <mZim-kBaOvyk2FWYTqg4jk5VX_nAVJmB0EKwFXfnLOs=.7273122e-2ff2-4031-a22f-57928459322e@github.com>

On Fri, 12 Dec 2025 16:03:26 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> I think this clean up is good by itself.
> 
> However, do you plan to include arguments.hpp in a lot of files (including files) just to check if valhalla is enabled?
> 
> If that's the case, I think it's better to move the check into its own header, similar to existing files like cdsConfig.hpp and gcConfig.hpp. Maybe valueTypeConfig.hpp?

That would also be fine by me. Maybe we can bring that question over to the Valhalla PR:
https://github.com/openjdk/valhalla/pull/1759

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28791#issuecomment-3647251974

From kevinw at openjdk.org  Fri Dec 12 16:55:50 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 12 Dec 2025 16:55:50 GMT
Subject: RFR: 8373441: Remove DCmdFactory::_enabled
In-Reply-To: <XE188S-C6EdTA2PRsdsQTi4Z550PW6DNpL3awvANazU=.1b0cd4d1-56cd-491a-b80c-8e2bafcc78ca@github.com>
References: <XE188S-C6EdTA2PRsdsQTi4Z550PW6DNpL3awvANazU=.1b0cd4d1-56cd-491a-b80c-8e2bafcc78ca@github.com>
Message-ID: <OWIvuqKJUCvJjq598wQrZ8oqDMV7m-EQMEi1Yyh7t6A=.6dcc1d69-f3e7-4a77-9cd9-cc7b9882502e@github.com>

On Fri, 12 Dec 2025 14:54:52 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The `DCmdFactory::_enabled` is always set to `true` and there doesn't seem to be a reason to set it to `false`.
> 
> This PR removes this field and simplified the creation of `DCmdFactory` objects.
> 
> The related `_hidden` field is also currently not used, but may be used in the future when deprecating DCmds, so we leave it unchanged.
> 
> Note that now `jmm_GetDiagnosticCommandInfo()` always set `dcmdInfo::enabled` to `true` to be compatible with Java code.

The Java API has "enabled" handled in src/jdk.management/share/classes/com/sun/management/internal/DiagnosticCommandInfo.java
(and read in src/jdk.management/share/classes/com/sun/management/internal/DiagnosticCommandImpl.java)

In the public API docs we do specify a Descriptor for diagnostic commands:

https://docs.oracle.com/en/java/javase/25/docs/api/jdk.management/com/sun/management/DiagnosticCommandMBean.html
dcmd.enabled	boolean	True if the diagnostic command is enabled, false otherwise

dcmd.enabled is already not very meaningful as it's always true, but if it becomes truly meaningless, it needs thought on whether it stays, maybe with a comment that it is always true, or can be removed.

The Java api deals with remote connections, so interactions between JDK versions need considering.
If dcmd.enabled is not found, if a client app ever checks this Descriptor, does the app think it's not enabled?

Maybe it stays in the Descriptor for compatibility reasons, but can be removed from DiagnosticCommandInfo.

This could be a follow up issue if we aren't doing it now.

-------------

PR Review: https://git.openjdk.org/jdk/pull/28794#pullrequestreview-3572764279

From vlivanov at openjdk.org  Fri Dec 12 20:21:54 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 12 Dec 2025 20:21:54 GMT
Subject: RFR: 8368977: Provide clear naming for AVX10 identifiers [v2]
In-Reply-To: <JZnx2wYn7sTlojACH-CG8c77eMFJo_WxAMA2hEWlSGI=.0ed3a154-f3e9-4815-9039-4ab1629b5060@github.com>
References: <6XYgqaHA0PPZzvnfysKOP5XGP7e_RMkVFt9PV2OT3Gk=.e5f33072-a91a-4e57-99f3-81cc4ae4d844@github.com>
 <JZnx2wYn7sTlojACH-CG8c77eMFJo_WxAMA2hEWlSGI=.0ed3a154-f3e9-4815-9039-4ab1629b5060@github.com>
Message-ID: <oLCZBzgn6UCgn-26g4XuhGCqgy4g_ILvwbQNRCrAUiA=.5bd53995-c474-4fb1-be59-b99d5de17241@github.com>

On Mon, 8 Dec 2025 21:47:16 GMT, Mohamed Issa <missa at openjdk.org> wrote:

>> This is a simple change that renames all AVX10 identifiers to explicitly show which sub-versions are in use. Right now, AVX10.2 is the only case to worry about. The JTREG tests listed below were used to verify correctness with the recommended JVM options mentioned in corresponding source files. Each test included runs through emulation with AVX10.2 enabled and disabled to exercise all possible paths. All modifications and tests used [OpenJDK v26-b24](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B24) as the baseline build.
>> 
>> 1. `jtreg:test/hotspot/jtreg/compiler/codegen/TestByteDoubleVect.java`
>> 2. `jtreg:test/hotspot/jtreg/compiler/codegen/TestByteFloatVect.java`
>> 3. `jtreg:test/hotspot/jtreg/compiler/codegen/TestIntDoubleVect.java`
>> 4. `jtreg:test/hotspot/jtreg/compiler/codegen/TestIntFloatVect.java`
>> 5. `jtreg:test/hotspot/jtreg/compiler/codegen/TestLongDoubleVect.java`
>> 6. `jtreg:test/hotspot/jtreg/compiler/codegen/TestLongFloatVect.java`
>> 7. `jtreg:test/hotspot/jtreg/compiler/codegen/TestShortDoubleVect.java`
>> 8. `jtreg:test/hotspot/jtreg/compiler/codegen/TestShortFloatVect.java`
>> 9. `jtreg:test/hotspot/jtreg/compiler/floatingpoint/ScalarFPtoIntCastTest.java`
>> 10. `jtreg:test/hotspot/jtreg/compiler/vectorapi/VectorFPtoIntCastTest.java`
>> 11. `jtreg:test/hotspot/jtreg/compiler/vectorization/runner/ArrayTypeConvertTest.java`
>> 12. `jtreg:test/jdk/jdk/incubator/vector/Double64VectorTests.java`
>> 13. `jtreg:test/jdk/jdk/incubator/vector/Double128VectorTests.java`
>> 14. `jtreg:test/jdk/jdk/incubator/vector/Double256VectorTests.java`
>> 15. `jtreg:test/jdk/jdk/incubator/vector/Double512VectorTests.java`
>> 16. `jtreg:test/jdk/jdk/incubator/vector/DoubleMaxVectorTests.java`
>> 17. `jtreg:test/jdk/jdk/incubator/vector/Float64VectorTests.java`
>> 18. `jtreg:test/jdk/jdk/incubator/vector/Float128VectorTests.java`
>> 19. `jtreg:test/jdk/jdk/incubator/vector/Float256VectorTests.java`
>> 20. `jtreg:test/jdk/jdk/incubator/vector/Float512VectorTests.java`
>> 21. `jtreg:test/jdk/jdk/incubator/vector/FloatMaxVectorTests.java`
>> 22. `jtreg:test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorOperations.java`
>> 23. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java`
>
> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove changes that affect functionality

Looks good. Thanks for the cleanup!

-------------

Marked as reviewed by vlivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28344#pullrequestreview-3573461306

From iklam at openjdk.org  Fri Dec 12 23:37:20 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 12 Dec 2025 23:37:20 GMT
Subject: RFR: 8373441: Remove DCmdFactory::_enabled [v2]
In-Reply-To: <XE188S-C6EdTA2PRsdsQTi4Z550PW6DNpL3awvANazU=.1b0cd4d1-56cd-491a-b80c-8e2bafcc78ca@github.com>
References: <XE188S-C6EdTA2PRsdsQTi4Z550PW6DNpL3awvANazU=.1b0cd4d1-56cd-491a-b80c-8e2bafcc78ca@github.com>
Message-ID: <AjjRyNcaMQOA-qcgilZVf5STbEMEmWAoBy3_BidW48k=.15d682e2-f8b6-4e4d-8fc2-f482e117b6b2@github.com>

> The `DCmdFactory::_enabled` is always set to `true` and there doesn't seem to be a reason to set it to `false`.
> 
> This PR removes this field and simplified the creation of `DCmdFactory` objects.
> 
> The related `_hidden` field is also currently not used, but may be used in the future when deprecating DCmds, so we leave it unchanged.
> 
> Note that now `jmm_GetDiagnosticCommandInfo()` always set `dcmdInfo::enabled` to `true` to be compatible with Java code.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @kevinjwalls comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28794/files
  - new: https://git.openjdk.org/jdk/pull/28794/files/8a047713..98176aa7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28794&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28794&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28794.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28794/head:pull/28794

PR: https://git.openjdk.org/jdk/pull/28794

From iklam at openjdk.org  Fri Dec 12 23:37:22 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 12 Dec 2025 23:37:22 GMT
Subject: RFR: 8373441: Remove DCmdFactory::_enabled [v2]
In-Reply-To: <OWIvuqKJUCvJjq598wQrZ8oqDMV7m-EQMEi1Yyh7t6A=.6dcc1d69-f3e7-4a77-9cd9-cc7b9882502e@github.com>
References: <XE188S-C6EdTA2PRsdsQTi4Z550PW6DNpL3awvANazU=.1b0cd4d1-56cd-491a-b80c-8e2bafcc78ca@github.com>
 <OWIvuqKJUCvJjq598wQrZ8oqDMV7m-EQMEi1Yyh7t6A=.6dcc1d69-f3e7-4a77-9cd9-cc7b9882502e@github.com>
Message-ID: <5L7tLI0Xi70wDBou7BLE4TNtcUQRdlKRPUEjsM_77mE=.823865fb-28f1-4879-8e05-a811b24cf590@github.com>

On Fri, 12 Dec 2025 16:53:33 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> The Java API has "enabled" handled in src/jdk.management/share/classes/com/sun/management/internal/DiagnosticCommandInfo.java (and read in src/jdk.management/share/classes/com/sun/management/internal/DiagnosticCommandImpl.java)
> 
> In the public API docs we do specify a Descriptor for diagnostic commands:
> 
> https://docs.oracle.com/en/java/javase/25/docs/api/jdk.management/com/sun/management/DiagnosticCommandMBean.html dcmd.enabled boolean True if the diagnostic command is enabled, false otherwise
> 
> dcmd.enabled is already not very meaningful as it's always true, but if it becomes truly meaningless, it needs thought on whether it stays, maybe with a comment that it is always true, or can be removed.
> 
> The Java api deals with remote connections, so interactions between JDK versions need considering. If dcmd.enabled is not found, if a client app ever checks this Descriptor, does the app think it's not enabled?
> 
> Maybe it stays in the Descriptor for compatibility reasons, but can be removed from DiagnosticCommandInfo.
> 
> This could be a follow up issue if we aren't doing it now.

For compatibility reasons, I don't want to touch the Java APIs in this PR. I updated the comments in DiagnosticCommandMBean.java to say


 *     <th scope="row">dcmd.enabled</th><td>boolean</td>
 *     <td>This field is always true -- diagnostic commands cannot be disabled.</td>

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28794#issuecomment-3648510642

From missa at openjdk.org  Sat Dec 13 00:36:33 2025
From: missa at openjdk.org (Mohamed Issa)
Date: Sat, 13 Dec 2025 00:36:33 GMT
Subject: RFR: 8368977: Provide clear naming for AVX10 identifiers [v3]
In-Reply-To: <6XYgqaHA0PPZzvnfysKOP5XGP7e_RMkVFt9PV2OT3Gk=.e5f33072-a91a-4e57-99f3-81cc4ae4d844@github.com>
References: <6XYgqaHA0PPZzvnfysKOP5XGP7e_RMkVFt9PV2OT3Gk=.e5f33072-a91a-4e57-99f3-81cc4ae4d844@github.com>
Message-ID: <pLPidrXTKcxJnn2aMd1lh1Cd7fpZNFugd3sJ2-nNYzs=.9c89fe63-bc84-4e46-9298-7b887cf42f2b@github.com>

> This is a simple change that renames all AVX10 identifiers to explicitly show which sub-versions are in use. Right now, AVX10.2 is the only case to worry about. The JTREG tests listed below were used to verify correctness with the recommended JVM options mentioned in corresponding source files. Each test included runs through emulation with AVX10.2 enabled and disabled to exercise all possible paths. All modifications and tests used [OpenJDK v26-b24](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B24) as the baseline build.
> 
> 1. `jtreg:test/hotspot/jtreg/compiler/codegen/TestByteDoubleVect.java`
> 2. `jtreg:test/hotspot/jtreg/compiler/codegen/TestByteFloatVect.java`
> 3. `jtreg:test/hotspot/jtreg/compiler/codegen/TestIntDoubleVect.java`
> 4. `jtreg:test/hotspot/jtreg/compiler/codegen/TestIntFloatVect.java`
> 5. `jtreg:test/hotspot/jtreg/compiler/codegen/TestLongDoubleVect.java`
> 6. `jtreg:test/hotspot/jtreg/compiler/codegen/TestLongFloatVect.java`
> 7. `jtreg:test/hotspot/jtreg/compiler/codegen/TestShortDoubleVect.java`
> 8. `jtreg:test/hotspot/jtreg/compiler/codegen/TestShortFloatVect.java`
> 9. `jtreg:test/hotspot/jtreg/compiler/floatingpoint/ScalarFPtoIntCastTest.java`
> 10. `jtreg:test/hotspot/jtreg/compiler/vectorapi/VectorFPtoIntCastTest.java`
> 11. `jtreg:test/hotspot/jtreg/compiler/vectorization/runner/ArrayTypeConvertTest.java`
> 12. `jtreg:test/jdk/jdk/incubator/vector/Double64VectorTests.java`
> 13. `jtreg:test/jdk/jdk/incubator/vector/Double128VectorTests.java`
> 14. `jtreg:test/jdk/jdk/incubator/vector/Double256VectorTests.java`
> 15. `jtreg:test/jdk/jdk/incubator/vector/Double512VectorTests.java`
> 16. `jtreg:test/jdk/jdk/incubator/vector/DoubleMaxVectorTests.java`
> 17. `jtreg:test/jdk/jdk/incubator/vector/Float64VectorTests.java`
> 18. `jtreg:test/jdk/jdk/incubator/vector/Float128VectorTests.java`
> 19. `jtreg:test/jdk/jdk/incubator/vector/Float256VectorTests.java`
> 20. `jtreg:test/jdk/jdk/incubator/vector/Float512VectorTests.java`
> 21. `jtreg:test/jdk/jdk/incubator/vector/FloatMaxVectorTests.java`
> 22. `jtreg:test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorOperations.java`
> 23. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java`

Mohamed Issa 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 branch 'master' into user/missa-prime/nomenclature
 - Remove changes that affect functionality
 - Fix naming issue in vector floating point cast test file
 - Rename AVX10 identifiers to AVX10_2 and use AVX10.2 in template table conversion whenever available

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28344/files
  - new: https://git.openjdk.org/jdk/pull/28344/files/2a029dab..be7f5c80

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28344&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28344&range=01-02

  Stats: 134206 lines in 2054 files changed: 88096 ins; 33081 del; 13029 mod
  Patch: https://git.openjdk.org/jdk/pull/28344.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28344/head:pull/28344

PR: https://git.openjdk.org/jdk/pull/28344

From wkemper at openjdk.org  Sat Dec 13 00:49:28 2025
From: wkemper at openjdk.org (William Kemper)
Date: Sat, 13 Dec 2025 00:49:28 GMT
Subject: RFR: 8373203: Genshen: Non-strong reference leak in old gen
Message-ID: <JaJt39rlIHDKUiyQmDuh0uSyVslFVLKisMXo0r2gROk=.1056f4b4-441f-4ed2-9e7f-e81cbaca272c@github.com>

The generational mode for Shenandoah will collect _referents_ for the generation being collected. For example, if we have a young reference pointing to an old referent, that young reference will be processed after we finish marking the old generation. This presents a problem for discovery.
  
When the young mark _encounters_ a young reference with an old referent, it cannot _discover_ it because old marking hasn't finished. However, if it does not discover it, the old referent will be strongly marked. This, in turn, will prevent the old generation from clearing the referent (if it even reaches it again during old marking).
  
To solve this, we let young reference processing discover the old reference by having it use the old generation reference processor to do so. This means the old reference processor can have a discovered list that contains young weak references. If any of these young references reside in a region that is collected, old reference processing will crash when it processes such a reference. Therefore, we add a method `heal_discovered_lists` to traverse the discovered lists after young evacuation is complete. The method will replace any forwarded entries in the discovered list with the forwardee.

This PR also extends whitebox testing support for Shenandoah, giving us the ability to trigger young/old collections and interrogate some properties of heaps and regions.

-------------

Commit messages:
 - Oops, change name of class in test xdoc
 - Oops, initialize new field
 - Add missing newline
 - Add comments, fix typo, survive multiple young GCs
 - WIP: checkpoint
 - Clean up test, increase likelihood of cross generational references
 - Add test for genshen reference processing

Changes: https://git.openjdk.org/jdk/pull/28810/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28810&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373203
  Stats: 472 lines in 14 files changed: 437 ins; 18 del; 17 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 vlivanov at openjdk.org  Sat Dec 13 01:00:52 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Sat, 13 Dec 2025 01:00:52 GMT
Subject: RFR: 8372845: C2: Fold identity hash code if object is constant
 [v3]
In-Reply-To: <0b81mH1_Y6r905N2HmehXBbSFdzLpJIfuXHNfijpHBs=.c870b13e-a52f-4c00-b771-91cf9205cb4a@github.com>
References: <KPNLohuiE3Os64ib8cPl8cyPUbmvzOF2y687qapKSgc=.cae21b9f-2fa9-4e78-a5ef-7912cf906dfa@github.com>
 <AqXlBQi24MmML3tltUJiZa0bEYzORazv9mVo41lrIP4=.13265855-6308-47d1-93f0-006bfe06fdfa@github.com>
 <cavp_9ZUlDCfuwg9Eyp8wDms7j5GOtSZPwYk-QYMbVI=.bfed4082-375e-4a52-a2a1-4071843b7550@github.com>
 <XpDpc28hjOioKUPvgyyCXCVkZLVeHL7GGmoEW5--1UE=.809ce0b3-8992-4f55-98a8-8834401597a5@github.com>
 <6ip4JrJ4WiYEe6d2FA_WQ5dDjxAk2RPaPbwth4jNeJM=.43d7879d-89a4-434c-80ea-371c92581686@github.com>
 <r2gvtXpF9spuh0PGFRWFuKhgKSInOJ8UbZ2rWTNzLB8=.5f60583a-ee90-40b8-8826-8893fa7b8372@github.com>
 <0b81mH1_Y6r905N2HmehXBbSFdzLpJIfuXHNfijpHBs=.c870b13e-a52f-4c00-b771-91cf9205cb4a@github.com>
Message-ID: <Zm0KHLF0N7z6zTCb0VWWkamGx2qf4oVN1r_fYa_vVjw=.d9c2b07b-0a3f-43f0-b65e-29dc924ea6f4@github.com>

On Thu, 11 Dec 2025 07:19:24 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> It's a test on C2 IR. What's the point in running it w/o C2?
>
> You can always do more than just C2 IR verification. For example, we could also do result verification. That would give us coverage for C1 for example. I think it is just good practice not to have a restriction if it is not absolutely necessary.

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.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2615925589

From vlivanov at openjdk.org  Sat Dec 13 01:23:56 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Sat, 13 Dec 2025 01:23:56 GMT
Subject: RFR: 8372136: VectorAPI: Refactor subword gather load API java
 implementation
In-Reply-To: <SEUxzD0msReThVgeMRw5uapRw-UIjewDJP27RAt3ZzY=.991e5f58-347e-44fe-92db-b56576aab780@github.com>
References: <SEUxzD0msReThVgeMRw5uapRw-UIjewDJP27RAt3ZzY=.991e5f58-347e-44fe-92db-b56576aab780@github.com>
Message-ID: <jzqosxsOM5QuIQDVQOBuIyWYP6axGrpSErPxzzBNNr4=.0846c30d-62b1-4a69-9e5c-fee2513cf369@github.com>

On Thu, 27 Nov 2025 01:42:07 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> The current subword (`byte`/`short`) gather load API implementation is not well-suited for platforms that provide native vector instructions for these operations. As **discussed in PR [1]**, we'd like to re-implement these APIs with a **unified cross-platform** solution.
> 
> The main idea is to re-implement the API at Java-level, by performing multiple sub-gather operations. Each sub-gather operation loads a portion of elements using a specific index vector by calling the HotSpot intrinsic API. The partial results are then merged using vector `slice` and `or` operations. This design simplifies the VM compiler intrinsic implementation and better aligns with the Vector API design principles.
> 
> Key changes:
> 1. Re-implement the subword gather load API at the Java level. The HotSpot intrinsic `VectorSupport.loadWithMap` is simplified by reducing the vector index parameters from four (vix1-vix4) to a single parameter.
> 2. Adjust the compiler intrinsic implementation to support the new Java API, including updates to the x86 backend implementation.
> 
> The performance impact varies across different scenarios on X86. I tested the performance with different AVX levels on an X86 machine that supports AVX512. To achieve optimal performance, I also **applied PR [2]**, which improves the performance of the **`slice()`** API on X86. Following is the summarized performance gains, where:
> 
> - "non masked" means the gather operation is not the masked gather API.
> - "masked" means the gather operation is the masked gather API.
> - "1 gather cases" means the gather API is implemented with a single gather operation. E.g. Load `Short128Vector` with `MaxVectorSize=256`.
> - "2 gather cases" means the gather API is implemented with 2 parts of gather operations. E.g. Load `Short256Vector` with `MaxVectorSize=256`.
> - "4 gather cases" means the gather API is implemented with 4 parts of gather operations. E.g. Load `Byte256Vector` with `MaxVectorSize=256`.
> - "Un-intrinsified" means the gather operation is not supported to be intrinsified by hotspot. E.g. Load `Byte512Vector` with `MaxVectorSize=256`. The singificant performance uplifts comes from the Java-level changes which removes the vector index generation and range checks for such cases.
> 
> 
> ----------------------------------------------------------------------------
>                |          UseAVX=3           |          UseAVX=2           |
>                |-----------------------------|-----------------------------|
>                |  non maske...

Good work, Xiaohong! 

Can you, please, include samples of machine code generated before/after the patch (for AVX2 and AVX512)?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28520#issuecomment-3648697712

From ayang at openjdk.org  Sat Dec 13 02:07:07 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Sat, 13 Dec 2025 02:07:07 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v22]
In-Reply-To: <C2nKyRSBdqEqIK0I3bEP1X4PM1K3Gb3HhPaxqgJeIS8=.62ffb736-16a7-4da9-8d11-1c147dfb40a1@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <rAPcRMkxD0uoJTzadbMR7eui7ixfiVHCKy8JCvS5TPc=.6307f4fd-e333-41c8-97f2-81971974eb93@github.com>
 <C2nKyRSBdqEqIK0I3bEP1X4PM1K3Gb3HhPaxqgJeIS8=.62ffb736-16a7-4da9-8d11-1c147dfb40a1@github.com>
Message-ID: <g0INjxl-T0NTw_GN4GkKl-d-gwjKQAmQs7_YB1R_LWo=.eaaddff1-531c-4ebc-956c-b091676be405@github.com>

On Fri, 12 Dec 2025 09:37:48 GMT, SilenceZheng66 <duke at openjdk.org> wrote:

>> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits:
>> 
>>  - merge
>>  - Merge branch 'master' into pgc-size-policy
>>  - review
>>  - review
>>  - Merge branch 'master' into pgc-size-policy
>>  - review
>>  - review
>>  - Merge branch 'master' into pgc-size-policy
>>  - Merge branch 'master' into pgc-size-policy
>>  - review
>>  - ... and 23 more: https://git.openjdk.org/jdk/compare/7da274de...295dc853
>
> src/hotspot/share/gc/parallel/psParallelCompact.cpp line 1070:
> 
>> 1068:     size_policy->sample_old_gen_used_bytes(MAX2(pre_gc_values.old_gen_used(), old_gen->used_in_bytes()));
>> 1069: 
>> 1070:     if (UseAdaptiveSizePolicy) {
> 
> I think this code block could raise heap size don't expand in some specific case, maybe you should optimize it. @albertnetymk

@SilenceZheng66 Could you elaborate the issue, ideally, in a JBS ticket? (A reproducer/gc-log would be nice, but detailed description works as well.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2615984879

From jrose at openjdk.org  Sat Dec 13 02:13:52 2025
From: jrose at openjdk.org (John R Rose)
Date: Sat, 13 Dec 2025 02:13:52 GMT
Subject: RFR: 8372845: C2: Fold identity hash code if object is constant
 [v3]
In-Reply-To: <AqXlBQi24MmML3tltUJiZa0bEYzORazv9mVo41lrIP4=.13265855-6308-47d1-93f0-006bfe06fdfa@github.com>
References: <KPNLohuiE3Os64ib8cPl8cyPUbmvzOF2y687qapKSgc=.cae21b9f-2fa9-4e78-a5ef-7912cf906dfa@github.com>
 <AqXlBQi24MmML3tltUJiZa0bEYzORazv9mVo41lrIP4=.13265855-6308-47d1-93f0-006bfe06fdfa@github.com>
Message-ID: <_j4OsghE4w1f2L8K6QZOEGozC9-HrFDq1Mhn871B2_Q=.a32b5068-6fac-491a-8861-0d17526dbada@github.com>

On Tue, 2 Dec 2025 23:25:29 GMT, Chen Liang <liach at openjdk.org> 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:
> 
>   Typo

src/hotspot/share/opto/library_call.cpp line 4786:

> 4784:   if (t != nullptr && t->const_oop() != nullptr) {
> 4785:     jint hash = t->const_oop()->identity_hash_or_no_hash();
> 4786:     if (hash != 0) {

Don?t compare against zero, please, but against no_hash.  (Any other stray zeroes?)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2615991597

From vlivanov at openjdk.org  Sat Dec 13 02:35:58 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Sat, 13 Dec 2025 02:35:58 GMT
Subject: RFR: 8372845: C2: Fold identity hash code if object is constant
In-Reply-To: <Y9RInGfnnt-3jIJRmB0spEvZ-zM-JD31CiJu--cOcnU=.5fcf9718-c55a-4abe-8c2a-b34b586b0df8@github.com>
References: <KPNLohuiE3Os64ib8cPl8cyPUbmvzOF2y687qapKSgc=.cae21b9f-2fa9-4e78-a5ef-7912cf906dfa@github.com>
 <Y9RInGfnnt-3jIJRmB0spEvZ-zM-JD31CiJu--cOcnU=.5fcf9718-c55a-4abe-8c2a-b34b586b0df8@github.com>
Message-ID: <03LS79mJXIs41UMm3gio_urrsHSZP7dPw81NEfcag88=.c6542fe1-f94a-4e80-8393-7cd235136e34@github.com>

On Tue, 2 Dec 2025 23:08:44 GMT, Chen Liang <liach at openjdk.org> 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.
>
> I tried to come up with an example where the buggy code from Vladimir would inline to identityHashCode when the right call would be virtual - couldn't construct such a case unfortunately :(
> 
> I think we can deal with IGVN later, as this involves creating new macro node and other infrastructure support.

@liach please, incorporate latest version from https://github.com/openjdk/jdk/compare/master...iwanowww:jdk:c2.identity_hash

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28589#issuecomment-3648776804

From duke at openjdk.org  Sat Dec 13 03:11:56 2025
From: duke at openjdk.org (duke)
Date: Sat, 13 Dec 2025 03:11:56 GMT
Subject: RFR: 8368977: Provide clear naming for AVX10 identifiers [v3]
In-Reply-To: <pLPidrXTKcxJnn2aMd1lh1Cd7fpZNFugd3sJ2-nNYzs=.9c89fe63-bc84-4e46-9298-7b887cf42f2b@github.com>
References: <6XYgqaHA0PPZzvnfysKOP5XGP7e_RMkVFt9PV2OT3Gk=.e5f33072-a91a-4e57-99f3-81cc4ae4d844@github.com>
 <pLPidrXTKcxJnn2aMd1lh1Cd7fpZNFugd3sJ2-nNYzs=.9c89fe63-bc84-4e46-9298-7b887cf42f2b@github.com>
Message-ID: <9JSV7fdlASzIbFgoR_-pTOkMRrrCNu5rooSZ1nTaGhs=.d8d5fa21-342e-4d57-bc33-330369943d9a@github.com>

On Sat, 13 Dec 2025 00:36:33 GMT, Mohamed Issa <missa at openjdk.org> wrote:

>> This is a simple change that renames all AVX10 identifiers to explicitly show which sub-versions are in use. Right now, AVX10.2 is the only case to worry about. The JTREG tests listed below were used to verify correctness with the recommended JVM options mentioned in corresponding source files. Each test included runs through emulation with AVX10.2 enabled and disabled to exercise all possible paths. All modifications and tests used [OpenJDK v26-b24](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B24) as the baseline build.
>> 
>> 1. `jtreg:test/hotspot/jtreg/compiler/codegen/TestByteDoubleVect.java`
>> 2. `jtreg:test/hotspot/jtreg/compiler/codegen/TestByteFloatVect.java`
>> 3. `jtreg:test/hotspot/jtreg/compiler/codegen/TestIntDoubleVect.java`
>> 4. `jtreg:test/hotspot/jtreg/compiler/codegen/TestIntFloatVect.java`
>> 5. `jtreg:test/hotspot/jtreg/compiler/codegen/TestLongDoubleVect.java`
>> 6. `jtreg:test/hotspot/jtreg/compiler/codegen/TestLongFloatVect.java`
>> 7. `jtreg:test/hotspot/jtreg/compiler/codegen/TestShortDoubleVect.java`
>> 8. `jtreg:test/hotspot/jtreg/compiler/codegen/TestShortFloatVect.java`
>> 9. `jtreg:test/hotspot/jtreg/compiler/floatingpoint/ScalarFPtoIntCastTest.java`
>> 10. `jtreg:test/hotspot/jtreg/compiler/vectorapi/VectorFPtoIntCastTest.java`
>> 11. `jtreg:test/hotspot/jtreg/compiler/vectorization/runner/ArrayTypeConvertTest.java`
>> 12. `jtreg:test/jdk/jdk/incubator/vector/Double64VectorTests.java`
>> 13. `jtreg:test/jdk/jdk/incubator/vector/Double128VectorTests.java`
>> 14. `jtreg:test/jdk/jdk/incubator/vector/Double256VectorTests.java`
>> 15. `jtreg:test/jdk/jdk/incubator/vector/Double512VectorTests.java`
>> 16. `jtreg:test/jdk/jdk/incubator/vector/DoubleMaxVectorTests.java`
>> 17. `jtreg:test/jdk/jdk/incubator/vector/Float64VectorTests.java`
>> 18. `jtreg:test/jdk/jdk/incubator/vector/Float128VectorTests.java`
>> 19. `jtreg:test/jdk/jdk/incubator/vector/Float256VectorTests.java`
>> 20. `jtreg:test/jdk/jdk/incubator/vector/Float512VectorTests.java`
>> 21. `jtreg:test/jdk/jdk/incubator/vector/FloatMaxVectorTests.java`
>> 22. `jtreg:test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorOperations.java`
>> 23. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java`
>
> Mohamed Issa 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 branch 'master' into user/missa-prime/nomenclature
>  - Remove changes that affect functionality
>  - Fix naming issue in vector floating point cast test file
>  - Rename AVX10 identifiers to AVX10_2 and use AVX10.2 in template table conversion whenever available

@missa-prime 
Your change (at version be7f5c80ebeddd809248f3477051e98eda2b81f0) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28344#issuecomment-3648826101

From missa at openjdk.org  Sat Dec 13 03:20:00 2025
From: missa at openjdk.org (Mohamed Issa)
Date: Sat, 13 Dec 2025 03:20:00 GMT
Subject: Integrated: 8368977: Provide clear naming for AVX10 identifiers
In-Reply-To: <6XYgqaHA0PPZzvnfysKOP5XGP7e_RMkVFt9PV2OT3Gk=.e5f33072-a91a-4e57-99f3-81cc4ae4d844@github.com>
References: <6XYgqaHA0PPZzvnfysKOP5XGP7e_RMkVFt9PV2OT3Gk=.e5f33072-a91a-4e57-99f3-81cc4ae4d844@github.com>
Message-ID: <m8g3kYqy0KbkDx3G1tz9YT-4PzufYqyPNeW9gNEqznI=.74ce1160-770e-420e-b910-4de854c8d325@github.com>

On Mon, 17 Nov 2025 03:46:50 GMT, Mohamed Issa <missa at openjdk.org> wrote:

> This is a simple change that renames all AVX10 identifiers to explicitly show which sub-versions are in use. Right now, AVX10.2 is the only case to worry about. The JTREG tests listed below were used to verify correctness with the recommended JVM options mentioned in corresponding source files. Each test included runs through emulation with AVX10.2 enabled and disabled to exercise all possible paths. All modifications and tests used [OpenJDK v26-b24](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B24) as the baseline build.
> 
> 1. `jtreg:test/hotspot/jtreg/compiler/codegen/TestByteDoubleVect.java`
> 2. `jtreg:test/hotspot/jtreg/compiler/codegen/TestByteFloatVect.java`
> 3. `jtreg:test/hotspot/jtreg/compiler/codegen/TestIntDoubleVect.java`
> 4. `jtreg:test/hotspot/jtreg/compiler/codegen/TestIntFloatVect.java`
> 5. `jtreg:test/hotspot/jtreg/compiler/codegen/TestLongDoubleVect.java`
> 6. `jtreg:test/hotspot/jtreg/compiler/codegen/TestLongFloatVect.java`
> 7. `jtreg:test/hotspot/jtreg/compiler/codegen/TestShortDoubleVect.java`
> 8. `jtreg:test/hotspot/jtreg/compiler/codegen/TestShortFloatVect.java`
> 9. `jtreg:test/hotspot/jtreg/compiler/floatingpoint/ScalarFPtoIntCastTest.java`
> 10. `jtreg:test/hotspot/jtreg/compiler/vectorapi/VectorFPtoIntCastTest.java`
> 11. `jtreg:test/hotspot/jtreg/compiler/vectorization/runner/ArrayTypeConvertTest.java`
> 12. `jtreg:test/jdk/jdk/incubator/vector/Double64VectorTests.java`
> 13. `jtreg:test/jdk/jdk/incubator/vector/Double128VectorTests.java`
> 14. `jtreg:test/jdk/jdk/incubator/vector/Double256VectorTests.java`
> 15. `jtreg:test/jdk/jdk/incubator/vector/Double512VectorTests.java`
> 16. `jtreg:test/jdk/jdk/incubator/vector/DoubleMaxVectorTests.java`
> 17. `jtreg:test/jdk/jdk/incubator/vector/Float64VectorTests.java`
> 18. `jtreg:test/jdk/jdk/incubator/vector/Float128VectorTests.java`
> 19. `jtreg:test/jdk/jdk/incubator/vector/Float256VectorTests.java`
> 20. `jtreg:test/jdk/jdk/incubator/vector/Float512VectorTests.java`
> 21. `jtreg:test/jdk/jdk/incubator/vector/FloatMaxVectorTests.java`
> 22. `jtreg:test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorOperations.java`
> 23. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java`

This pull request has now been integrated.

Changeset: 4f1dcf89
Author:    Mohamed Issa <missa at openjdk.org>
Committer: Vladimir Ivanov <vlivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4f1dcf89b841e9a37d342bdf8c66bbbab9edb0d4
Stats:     99 lines in 9 files changed: 0 ins; 0 del; 99 mod

8368977: Provide clear naming for AVX10 identifiers

Reviewed-by: jbhateja, mhaessig, vlivanov

-------------

PR: https://git.openjdk.org/jdk/pull/28344

From dlong at openjdk.org  Sat Dec 13 03:33:55 2025
From: dlong at openjdk.org (Dean Long)
Date: Sat, 13 Dec 2025 03:33:55 GMT
Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() [v6]
In-Reply-To: <CEvEqPtlTMiv7fX1G_spyCpyl8afEZn4McrzIBd5GRY=.d233254e-3626-4044-a3e1-c82bcbd55e45@github.com>
References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com>
 <CEvEqPtlTMiv7fX1G_spyCpyl8afEZn4McrzIBd5GRY=.d233254e-3626-4044-a3e1-c82bcbd55e45@github.com>
Message-ID: <6E4yPY9dRcWGBT-vPPq7bOm1NfLdvIfLdecg34f6Tes=.11b0a7c1-798f-4ed2-a521-26059bc0ba5b@github.com>

On Mon, 8 Dec 2025 14:01:48 GMT, Fei Gao <fgao at openjdk.org> 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/358b594f...415495da

That comment about compiled lambda forms and the check for is_compiled_lambda_form() has always puzzled me.  As far as I can tell, it was introduced by the s390 port and later got moved into shared code.  The race because of old redefined methods might be more likely.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26638#issuecomment-3648859843

From aph at openjdk.org  Sat Dec 13 09:42:58 2025
From: aph at openjdk.org (Andrew Haley)
Date: Sat, 13 Dec 2025 09:42:58 GMT
Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() [v6]
In-Reply-To: <6E4yPY9dRcWGBT-vPPq7bOm1NfLdvIfLdecg34f6Tes=.11b0a7c1-798f-4ed2-a521-26059bc0ba5b@github.com>
References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com>
 <CEvEqPtlTMiv7fX1G_spyCpyl8afEZn4McrzIBd5GRY=.d233254e-3626-4044-a3e1-c82bcbd55e45@github.com>
 <6E4yPY9dRcWGBT-vPPq7bOm1NfLdvIfLdecg34f6Tes=.11b0a7c1-798f-4ed2-a521-26059bc0ba5b@github.com>
Message-ID: <yRkEv29KF1vLIy4V5nKDgQF7CfvVjUjfssdzZ0PccjA=.00171af8-a1aa-401b-9341-a80a6fb4e22e@github.com>

On Sat, 13 Dec 2025 03:31:16 GMT, Dean Long <dlong at openjdk.org> wrote:

> The race because of old redefined methods might be more likely.

Mm, yes. Do you know of a good stress test for that?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26638#issuecomment-3649160236

From lmesnik at openjdk.org  Sat Dec 13 20:07:25 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 13 Dec 2025 20:07:25 GMT
Subject: RFR: 8343809: Add requires tag to mark tests that are incompatible
 with exploded image
Message-ID: <GtxujYXXFK6Y32kkijCc7XyGcMStlbQs7C9OM2QxmfM=.cbfe5c94-c9ab-4852-bad2-66deb4932723@github.com>

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.

-------------

Commit messages:
 - 8343809: Add requires tag to mark tests that are incompatible with exploded image

Changes: https://git.openjdk.org/jdk/pull/28814/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28814&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343809
  Stats: 22 lines in 5 files changed: 20 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28814.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28814/head:pull/28814

PR: https://git.openjdk.org/jdk/pull/28814

From fjiang at openjdk.org  Sun Dec 14 04:05:54 2025
From: fjiang at openjdk.org (Feilong Jiang)
Date: Sun, 14 Dec 2025 04:05:54 GMT
Subject: RFR: 8373069: RISC-V: implement GHASH intrinsic [v4]
In-Reply-To: <8MCvHCHkscmoOkB_cKGP5mkhHWBw6B3PfalaBL4aVg0=.0a6e3bc9-7b6b-498d-81fb-1a276adc2a31@github.com>
References: <zxCNQIhhidoKzHbxL0z8h_Tp1N8pCmlHNoJ2wx30XF8=.a3d8eb05-9a07-403e-a014-84c3bb32b001@github.com>
 <8MCvHCHkscmoOkB_cKGP5mkhHWBw6B3PfalaBL4aVg0=.0a6e3bc9-7b6b-498d-81fb-1a276adc2a31@github.com>
Message-ID: <z4U9VPenNTJ-dDttALjAhzdyNGyrG9nEQii7C90U5YE=.59056d4b-d031-48dc-a495-60ba66ae9437@github.com>

On Thu, 11 Dec 2025 12:22:13 GMT, Anjian Wen <wenanjian at openjdk.org> wrote:

>> support GHASH intrinsic for crypt GCM, which need zvkg extension. 
>> 
>> passed the tests in 
>> test/hotspot/jtreg/compiler/codegen/aes/
>> test/jdk/com/sun/crypto
>
> Anjian Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   modify format

src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 3019:

> 3017:     assert(UseGHASHIntrinsics, "Must be");
> 3018:     assert(UseZvbb, "need Zvbb extension support");
> 3019:     assert(UseZvkg, "need GHASH instructions (Zvkg extension) support");

Do we need `UseZvbb` and  `UseZvkg` assertions here? `UseGHASHIntrinsics` should be enough as it depends on `UseZvbb` and  `UseZvkg`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28548#discussion_r2616696345

From aph at openjdk.org  Sun Dec 14 09:31:09 2025
From: aph at openjdk.org (Andrew Haley)
Date: Sun, 14 Dec 2025 09:31:09 GMT
Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() [v6]
In-Reply-To: <6k0jwjNuqZbpH1bjPxJg2qw6Hug9gL1IQV2Na16gWgw=.eaec40ba-cdf1-414f-b138-1837698cd42e@github.com>
References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com>
 <CEvEqPtlTMiv7fX1G_spyCpyl8afEZn4McrzIBd5GRY=.d233254e-3626-4044-a3e1-c82bcbd55e45@github.com>
 <NtMPMeCg0Pr3xvm6APh556G0XHh9ZuOJrX0ZhWqDRXM=.81294a86-b76f-4ed3-aa4b-d6afd72b09af@github.com>
 <4n3LwIItTdN__WjnZZkHYDV25HWhFkpshLm_ngr3Rl8=.76385eac-68bf-47bd-81fd-c96e1eb16814@github.com>
 <6k0jwjNuqZbpH1bjPxJg2qw6Hug9gL1IQV2Na16gWgw=.eaec40ba-cdf1-414f-b138-1837698cd42e@github.com>
Message-ID: <0GeWBqRqf3BboZgnTOPFTzeMyyTIWA61pVZIL2eHtGY=.0c148e57-f643-40ea-aa1f-5505b3ffb60b@github.com>

On Fri, 12 Dec 2025 10:13:27 GMT, Dean Long <dlong at openjdk.org> wrote:

> > I see your point. However, I don't see the comments to which you refer. Please, where are they?
> 
> Sorry, I meant the new comment in set_to_interpreted, in particular starting around line 145 "If a racing thread reaches the static call stub .... Initially we place an ISB at the start of the static call stub." The way I read that and the litmus test below it is that we need to go from ISB to B .+4 every time we update the MOVs.

Yes, we definitely do. The guarantee must be that the observability of the MOVs happens-before the observability of the B .+4.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26638#issuecomment-3650591237

From ayang at openjdk.org  Mon Dec 15 00:18:11 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 15 Dec 2025 00:18:11 GMT
Subject: RFR: 8373449: Parallel: Obsolete deprecated PSChunkLargeArrays
 [v2]
In-Reply-To: <4Qgp_QW_5sreJ5W4srufeKwDQzAd1Ajn601diouyd3g=.2361b5f9-31c3-496f-9121-3df9abfc7bc4@github.com>
References: <4Qgp_QW_5sreJ5W4srufeKwDQzAd1Ajn601diouyd3g=.2361b5f9-31c3-496f-9121-3df9abfc7bc4@github.com>
Message-ID: <8uoQUHrN_EExU4VSXPFCE5STuRZ7JKciVsHL0JpD7y8=.7c2241a2-fcc7-4b61-acbb-b2be3a0ab2f8@github.com>

> Obsolete a deprecated jvm flag. Its default value is `true`.
> 
> Test: tier1-3

Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - merge
 - pgc-obsolete-array-chunk

-------------

Changes: https://git.openjdk.org/jdk/pull/28754/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28754&range=01
  Stats: 10 lines in 3 files changed: 2 ins; 6 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28754.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28754/head:pull/28754

PR: https://git.openjdk.org/jdk/pull/28754

From kbarrett at openjdk.org  Mon Dec 15 01:37:11 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 15 Dec 2025 01:37:11 GMT
Subject: RFR: 8372754: Add wrapper for <cstdlib> [v2]
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: <cphviQVoQ7e5Qsupc5SAHZk9fSW-CTU6l1M5bxHNSNo=.e03193a9-8674-48b1-9d74-210a93c0e381@github.com>

> Please review this change that adds a HotSpot wrapper for <cstdlib>.  It also
> includes the forbidden function declarations for functions declared there,
> moving them from forbiddenFunctions.hpp and friends.
> 
> The AIX-specific workaround for its macro-based renaming of malloc/calloc is
> also moved to this wrapper, so there is a single location for it. Also cleaned
> it up a bit, based on further investigation of the problem.
> 
> Also changed uses of <cstdlib> and <stdlib.h> to include the wrapper instead.
> There are still a couple of includes of <stdlib.h> in the hotspot directory,
> because they can't use the hotspot wrapper: os/windows/include/jvm_md.h and
> share/adlc/adlc.hpp.  I looked at removing the one in windows jvm_md.h, but
> there are a lot of dependencies on that implicit include in non-HotSpot code.
> 
> While updating to use the wrapper, I also did a small amount of include
> cleanup here and there.  The changes around immediate_aarch64.hpp are perhaps
> a little less trivial than I should have made here.
> 
> Testing: mach5 tier1
> 
> This should probably be retested by aix port maintainer folks, although I
> don't think I made any relevant changes since you last tested it.
> 
> This change also resolves:

Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'master' into wrap-cstdlib
 - add wrapper for <cstdlib>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28562/files
  - new: https://git.openjdk.org/jdk/pull/28562/files/3dd6389a..f210f9ef

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28562&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28562&range=00-01

  Stats: 5754 lines in 220 files changed: 3513 ins; 587 del; 1654 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 fyang at openjdk.org  Mon Dec 15 01:44:57 2025
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 15 Dec 2025 01:44:57 GMT
Subject: RFR: 8373069: RISC-V: implement GHASH intrinsic [v4]
In-Reply-To: <8MCvHCHkscmoOkB_cKGP5mkhHWBw6B3PfalaBL4aVg0=.0a6e3bc9-7b6b-498d-81fb-1a276adc2a31@github.com>
References: <zxCNQIhhidoKzHbxL0z8h_Tp1N8pCmlHNoJ2wx30XF8=.a3d8eb05-9a07-403e-a014-84c3bb32b001@github.com>
 <8MCvHCHkscmoOkB_cKGP5mkhHWBw6B3PfalaBL4aVg0=.0a6e3bc9-7b6b-498d-81fb-1a276adc2a31@github.com>
Message-ID: <v8ITeVbN22plVmUAuQon2-iWYYXhm7qDML3kR7VJQPg=.4c6d1b1d-28f1-4efb-bd9c-64f3e6408c81@github.com>

On Thu, 11 Dec 2025 12:22:13 GMT, Anjian Wen <wenanjian at openjdk.org> wrote:

>> support GHASH intrinsic for crypt GCM, which need zvkg extension. 
>> 
>> passed the tests in 
>> test/hotspot/jtreg/compiler/codegen/aes/
>> test/jdk/com/sun/crypto
>
> Anjian Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   modify format

src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 3021:

> 3019:     assert(UseZvkg, "need GHASH instructions (Zvkg extension) support");
> 3020: 
> 3021:     __ align(CodeEntryAlignment);

Can you move this line to immediately before L3025? Like:

    __ align(CodeEntryAlignment);
    address start = __ pc();
    __ enter();


Then it looks more obvious where we want to align the code. BTW: Seems CBC and CTR intrinsics need similar adjustment.

src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 3052:

> 3050:       __ vghsh_vv(partial_hash, hash_subkey, cipher_text);
> 3051:       __ subi(blocks, blocks, 1);
> 3052:       __ bnez(blocks, L_ghash_loop);

Please leave a new line after the loop.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28548#discussion_r2617702776
PR Review Comment: https://git.openjdk.org/jdk/pull/28548#discussion_r2617699025

From kbarrett at openjdk.org  Mon Dec 15 01:47:52 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 15 Dec 2025 01:47:52 GMT
Subject: RFR: 8373449: Parallel: Obsolete deprecated PSChunkLargeArrays
 [v2]
In-Reply-To: <8uoQUHrN_EExU4VSXPFCE5STuRZ7JKciVsHL0JpD7y8=.7c2241a2-fcc7-4b61-acbb-b2be3a0ab2f8@github.com>
References: <4Qgp_QW_5sreJ5W4srufeKwDQzAd1Ajn601diouyd3g=.2361b5f9-31c3-496f-9121-3df9abfc7bc4@github.com>
 <8uoQUHrN_EExU4VSXPFCE5STuRZ7JKciVsHL0JpD7y8=.7c2241a2-fcc7-4b61-acbb-b2be3a0ab2f8@github.com>
Message-ID: <i5Lvyz5FGZ5LxKMHla9jOw2QiBFSF6--C_cHCyDS1Sg=.0a55fc53-ebd5-4fea-a54e-1a899b24827c@github.com>

On Mon, 15 Dec 2025 00:18:11 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Obsolete a deprecated jvm flag. Its default value is `true`.
>> 
>> Test: tier1-3
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - merge
>  - pgc-obsolete-array-chunk

Still good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28754#pullrequestreview-3576136852

From ayang at openjdk.org  Mon Dec 15 01:53:05 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 15 Dec 2025 01:53:05 GMT
Subject: RFR: 8373449: Parallel: Obsolete deprecated PSChunkLargeArrays
 [v2]
In-Reply-To: <8uoQUHrN_EExU4VSXPFCE5STuRZ7JKciVsHL0JpD7y8=.7c2241a2-fcc7-4b61-acbb-b2be3a0ab2f8@github.com>
References: <4Qgp_QW_5sreJ5W4srufeKwDQzAd1Ajn601diouyd3g=.2361b5f9-31c3-496f-9121-3df9abfc7bc4@github.com>
 <8uoQUHrN_EExU4VSXPFCE5STuRZ7JKciVsHL0JpD7y8=.7c2241a2-fcc7-4b61-acbb-b2be3a0ab2f8@github.com>
Message-ID: <I1DkhLd4hja95zBkj6-Wp5Z85uPbt0R0834eI3r5R9c=.6a0cadb7-6bd1-4f9e-bd8e-77b5fb8ceb1a@github.com>

On Mon, 15 Dec 2025 00:18:11 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Obsolete a deprecated jvm flag. Its default value is `true`.
>> 
>> Test: tier1-3
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - merge
>  - pgc-obsolete-array-chunk

Thanks for review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28754#issuecomment-3652578437

From ayang at openjdk.org  Mon Dec 15 01:53:06 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 15 Dec 2025 01:53:06 GMT
Subject: Integrated: 8373449: Parallel: Obsolete deprecated PSChunkLargeArrays
In-Reply-To: <4Qgp_QW_5sreJ5W4srufeKwDQzAd1Ajn601diouyd3g=.2361b5f9-31c3-496f-9121-3df9abfc7bc4@github.com>
References: <4Qgp_QW_5sreJ5W4srufeKwDQzAd1Ajn601diouyd3g=.2361b5f9-31c3-496f-9121-3df9abfc7bc4@github.com>
Message-ID: <NP1s02VKTR3X7kFZDEOp268Rg5z05pj80hpbYxM1Lto=.79a0038f-d869-44d9-980d-06969dbe9b7b@github.com>

On Wed, 10 Dec 2025 18:09:17 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Obsolete a deprecated jvm flag. Its default value is `true`.
> 
> Test: tier1-3

This pull request has now been integrated.

Changeset: eda1ab21
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/eda1ab2143f8bb25fce2e5c086aeb4ecb4141f55
Stats:     10 lines in 3 files changed: 2 ins; 6 del; 2 mod

8373449: Parallel: Obsolete deprecated PSChunkLargeArrays

Reviewed-by: kbarrett, dholmes, tschatzl

-------------

PR: https://git.openjdk.org/jdk/pull/28754

From wenanjian at openjdk.org  Mon Dec 15 03:02:28 2025
From: wenanjian at openjdk.org (Anjian Wen)
Date: Mon, 15 Dec 2025 03:02:28 GMT
Subject: RFR: 8373069: RISC-V: implement GHASH intrinsic [v4]
In-Reply-To: <z4U9VPenNTJ-dDttALjAhzdyNGyrG9nEQii7C90U5YE=.59056d4b-d031-48dc-a495-60ba66ae9437@github.com>
References: <zxCNQIhhidoKzHbxL0z8h_Tp1N8pCmlHNoJ2wx30XF8=.a3d8eb05-9a07-403e-a014-84c3bb32b001@github.com>
 <8MCvHCHkscmoOkB_cKGP5mkhHWBw6B3PfalaBL4aVg0=.0a6e3bc9-7b6b-498d-81fb-1a276adc2a31@github.com>
 <z4U9VPenNTJ-dDttALjAhzdyNGyrG9nEQii7C90U5YE=.59056d4b-d031-48dc-a495-60ba66ae9437@github.com>
Message-ID: <-33xKAvpX5TytD9QRVeSE2dZC_-OKDG-Oowwgq3g2fw=.57f37567-e175-4fd8-977e-06a2be36f19c@github.com>

On Sun, 14 Dec 2025 03:50:11 GMT, Feilong Jiang <fjiang at openjdk.org> wrote:

>> Anjian Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   modify format
>
> src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 3019:
> 
>> 3017:     assert(UseGHASHIntrinsics, "Must be");
>> 3018:     assert(UseZvbb, "need Zvbb extension support");
>> 3019:     assert(UseZvkg, "need GHASH instructions (Zvkg extension) support");
> 
> Do we need `UseZvbb` and  `UseZvkg` assertions here? `UseGHASHIntrinsics` should be enough as it depends on `UseZvbb` and  `UseZvkg`.

Thanks for pointing out. yes, it seems a little bit redundant, I'll try delete it and test it one more time for sure before update.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28548#discussion_r2617796611

From kbarrett at openjdk.org  Mon Dec 15 03:31:22 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 15 Dec 2025 03:31:22 GMT
Subject: RFR: 8373649: Convert simple AtomicAccess usage in ConcurrentHashTable
 to use Atomic<T>
Message-ID: <rcuhR8LdUTG0zHxMHGIbB6dD93LCz-voc8IHRV9NDnU=.3ace9437-f609-4702-b8c5-0f70db2a5935@github.com>

Please review this conversion of simple AtomicAccess usage in
ConcurrentHashTable to use Atomic<T>.  This is split out from the complete
conversion to simplify reviewing and testing.

Testing: mach5 tier1-3

-------------

Commit messages:
 - atomic claimer _next
 - atomic _resize_lock_owner
 - atomic _invisible_epoch
 - atomic _size_limit_reached

Changes: https://git.openjdk.org/jdk/pull/28816/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28816&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373649
  Stats: 58 lines in 3 files changed: 3 ins; 0 del; 55 mod
  Patch: https://git.openjdk.org/jdk/pull/28816.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28816/head:pull/28816

PR: https://git.openjdk.org/jdk/pull/28816

From dholmes at openjdk.org  Mon Dec 15 04:21:27 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 15 Dec 2025 04:21:27 GMT
Subject: RFR: 8369515: Deadlock between JVMTI and JNI
 ReleasePrimitiveArrayCritical
Message-ID: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>

As discussed in JBS the deadlock occurs when the call to `ReleasePrimitiveArrayCritical` performs the transition from native to VM, and in the process checks for special runtime exit conditions - which includes the `obj_deopt_suspend` request. The simple solution is to define a custom JNI ENTRY with custom `ThreadInVMfromNative` that elides the exit check.

The change is limited to `ReleasePrimitiveArrayCritical` and `ReleaseStringCritical`.

There is no regression test as this has only been seen in long running stress tests.

Testing:
   -tiers 1-6

-------------

Commit messages:
 - 8369515

Changes: https://git.openjdk.org/jdk/pull/28779/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28779&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369515
  Stats: 31 lines in 2 files changed: 27 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/28779.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28779/head:pull/28779

PR: https://git.openjdk.org/jdk/pull/28779

From dholmes at openjdk.org  Mon Dec 15 06:13:55 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 15 Dec 2025 06:13:55 GMT
Subject: RFR: 8373441: Remove DCmdFactory::_enabled [v2]
In-Reply-To: <AjjRyNcaMQOA-qcgilZVf5STbEMEmWAoBy3_BidW48k=.15d682e2-f8b6-4e4d-8fc2-f482e117b6b2@github.com>
References: <XE188S-C6EdTA2PRsdsQTi4Z550PW6DNpL3awvANazU=.1b0cd4d1-56cd-491a-b80c-8e2bafcc78ca@github.com>
 <AjjRyNcaMQOA-qcgilZVf5STbEMEmWAoBy3_BidW48k=.15d682e2-f8b6-4e4d-8fc2-f482e117b6b2@github.com>
Message-ID: <ppwkDYos68jcWO3LlFPFjyVqNdjvA56mPWgSG6Zkf5Q=.07a2fd74-2c98-426e-ae8a-92db8e7031b1@github.com>

On Fri, 12 Dec 2025 23:37:20 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The `DCmdFactory::_enabled` is always set to `true` and there doesn't seem to be a reason to set it to `false`.
>> 
>> This PR removes this field and simplified the creation of `DCmdFactory` objects.
>> 
>> The related `_hidden` field is also currently not used, but may be used in the future when deprecating DCmds, so we leave it unchanged.
>> 
>> Note that now `jmm_GetDiagnosticCommandInfo()` always set `dcmdInfo::enabled` to `true` to be compatible with Java code.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @kevinjwalls comments

If we are just changing the implementation then I guess this would be okay. But it seems the API for this allows for specific DCmds to be disabled (how?) - or at least intended for it to be possible. As per the doc:
> When the set of diagnostic commands currently supported by the Java Virtual Machine is modified, the DiagnosticCommandMBean emits a [Notification](https://docs.oracle.com/javase/8/docs/api/javax/management/Notification.html?is-external=true) with a [type](https://docs.oracle.com/javase/8/docs/api/javax/management/Notification.html?is-external=true#getType--) of[ "jmx.mbean.info.changed"](https://docs.oracle.com/javase/8/docs/api/javax/management/MBeanInfo.html#info-changed) and a [userData](https://docs.oracle.com/javase/8/docs/api/javax/management/Notification.html?is-external=true#getUserData--) that is the new MBeanInfo.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28794#issuecomment-3653521831

From dholmes at openjdk.org  Mon Dec 15 06:26:58 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 15 Dec 2025 06:26:58 GMT
Subject: RFR: 8373599: Cleanup arguments.hpp includes [v2]
In-Reply-To: <Kqz_5CO6d3_qHfiP4oBX9R8-w4XhLgf41eFGcBPABRM=.64ef1a0f-20b2-4adb-ba32-4b96b5310319@github.com>
References: <Qk3QT6NyM0BgtE_qbj_s8LrSR8bTloYqu8ojT51cgEs=.f60dd6b4-e844-4b46-82a3-69efafe0206d@github.com>
 <Kqz_5CO6d3_qHfiP4oBX9R8-w4XhLgf41eFGcBPABRM=.64ef1a0f-20b2-4adb-ba32-4b96b5310319@github.com>
Message-ID: <21W-AGpS3YI3AvNJCOzu1GM7gBJnl5kJpPwQhSYEEDo=.af74d679-5b21-4b9c-9f5a-0ffc31e1adea@github.com>

On Fri, 12 Dec 2025 15:06:39 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> In the Valhalla project we are considering using a property in Arguments to figure out if Valhalla is enabled. To minimize transitive-include-proliferation if this property ever needs to be checked in a header I propose that we clean up the header includes in arguments.hpp.
>> 
>> I'm opening the review for this so that I can get opinions on the move of functions. I'm going to compile this on all our platforms and will likely add a few more includes when unrelated files fail to compile because they relied on the includes provided through by java.hpp and arguments.hpp.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Sort order

I don't understand the motivation here. Why do we not have a global `UseValhalla` the way we have `UseXXX` for so many things. Including `argument.hpp` to ask `is_valhalla_enabled()` doesn't seem appropriate to me.

That said does it even make sense to use the word "Valhalla" here? Today I assume it means JEP-401 but next release? and the one after?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28791#issuecomment-3653605828

From mhaessig at openjdk.org  Mon Dec 15 07:24:55 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Mon, 15 Dec 2025 07:24:55 GMT
Subject: RFR: 8370519: C2: Hit MemLimit when running with
 +VerifyLoopOptimizations [v6]
In-Reply-To: <ivWBI33pO0sKOtifG2aGTozX0ybXkxSazNW-T5rpJyU=.a77a85c6-3540-4ce8-8b82-db7bae444615@github.com>
References: <W7EnT28-84mtwppISdr_ydCV9HSaXk72y7fyd29z4wQ=.7331c81d-c36f-4a1c-b949-e7045f524d07@github.com>
 <ivWBI33pO0sKOtifG2aGTozX0ybXkxSazNW-T5rpJyU=.a77a85c6-3540-4ce8-8b82-db7bae444615@github.com>
Message-ID: <f7UUVln9UFysvjIkDb-uFkqe-EzDruqnpv-Ui1bAoyg=.b7e5b446-cecb-4e88-b4cb-adb4b2d1d445@github.com>

On Thu, 11 Dec 2025 15:42:42 GMT, Roland Westrelin <roland at openjdk.org> 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

Testing passed tier1-3 linux-x64-debug, linux-aarch64-debug, macosx-aarch64-debug, macosx-x64-debug, windows-x64-debug.

-------------

Marked as reviewed by mhaessig (Committer).

PR Review: https://git.openjdk.org/jdk/pull/28581#pullrequestreview-3576777552

From xgong at openjdk.org  Mon Dec 15 08:36:51 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 15 Dec 2025 08:36:51 GMT
Subject: RFR: 8372136: VectorAPI: Refactor subword gather load API java
 implementation
In-Reply-To: <jzqosxsOM5QuIQDVQOBuIyWYP6axGrpSErPxzzBNNr4=.0846c30d-62b1-4a69-9e5c-fee2513cf369@github.com>
References: <SEUxzD0msReThVgeMRw5uapRw-UIjewDJP27RAt3ZzY=.991e5f58-347e-44fe-92db-b56576aab780@github.com>
 <jzqosxsOM5QuIQDVQOBuIyWYP6axGrpSErPxzzBNNr4=.0846c30d-62b1-4a69-9e5c-fee2513cf369@github.com>
Message-ID: <LXJstRa0dMhXG6NtlI27GIur7Tn-ds1kzFZWgThH0kc=.8421caef-a88b-4a5c-9256-7a0561bd52fb@github.com>

On Sat, 13 Dec 2025 01:21:14 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Good work, Xiaohong!
>
Thanks so much for your review!
 
> Can you, please, include samples of machine code generated before/after the patch (for AVX2 and AVX512)?

Sure. The generated code has no difference for cases that just need **1 gather load**. For cases that need **2/4 times** of gather loads, the main differences come from the **duplicate initializing instructions** before iterations of 8B gather loads (which could be optimized in future), and the additional code generated for **vector slice and merging**.

Following is an example of loading a `Short256Vector` under `-XX:UseAVX=2`, which needs 2 times of gather loads. The corresponding Java code is:

private static final VectorSpecies<Short> S_SPECIES = ShortVector.SPECIES_PREFERRED;

static void gather_short() {
    for (int i = 0; i < LENGTH; i += S_SPECIES.length()) {
        ShortVector.fromArray(S_SPECIES, sa, i, index, i)
                   .intoArray(sr, i);
    }
}

static void gather_short_masked() {
    VectorMask<Short> mask = VectorMask.fromArray(S_SPECIES, m, 0);
    for (int i = 0; i < LENGTH; i += S_SPECIES.length()) {
        ShortVector.fromArray(S_SPECIES, sa, i, index, i, mask)
                   .intoArray(sr, i);
    }
}




Here is the kernel code generated **without** this patch:

  0x00007a0e8c06ecb0:   vmovd  %r9d,%xmm1
  0x00007a0e8c06ecb5:   lea    0x10(%rbx,%rsi,2),%r14
  0x00007a0e8c06ecba:   mov    %r13,%r8
  0x00007a0e8c06ecbd:   mov    $0x10,%r9d
  0x00007a0e8c06ecc3:   vpxor  %ymm5,%ymm5,%ymm5
  0x00007a0e8c06ecc7:   vpxor  %ymm4,%ymm4,%ymm4
  0x00007a0e8c06eccb:   vpcmpeqd %ymm6,%ymm6,%ymm6
  0x00007a0e8c06eccf:   vpsubd %ymm6,%ymm5,%ymm6
  0x00007a0e8c06ecd3:   vpslld $0x1,%ymm6,%ymm6
  0x00007a0e8c06ecd8:   vmovdqu 0x41020(%rip),%ymm5        # Stub::Stub Generator vector_iota_indices_stub+128 0x00007a0e8c0afd00
                                                            ;   {external_word}
  0x00007a0e8c06ece0:   vpxor  %ymm3,%ymm3,%ymm3
  0x00007a0e8c06ece4:   mov    (%r8),%r11d
  0x00007a0e8c06ece7:   vpinsrw $0x0,(%r14,%r11,2),%xmm3,%xmm3
  0x00007a0e8c06ecee:   mov    0x4(%r8),%r11d
  0x00007a0e8c06ecf2:   vpinsrw $0x1,(%r14,%r11,2),%xmm3,%xmm3
  0x00007a0e8c06ecf9:   mov    0x8(%r8),%r11d
  0x00007a0e8c06ecfd:   vpinsrw $0x2,(%r14,%r11,2),%xmm3,%xmm3
  0x00007a0e8c06ed04:   mov    0xc(%r8),%r11d
  0x00007a0e8c06ed08:   vpinsrw $0x3,(%r14,%r11,2),%xmm3,%xmm3
  0x00007a0e8c06ed0f:   vpermd %ymm3,%ymm5,%ymm3
  0x00007a0e8c06ed14:   vpsubd %ymm6,%ymm5,%ymm5
  0x00007a0e8c06ed18:   vpor   %ymm3,%ymm4,%ymm4
  0x00007a0e8c06ed1c:   add    $0x10,%r8
  0x00007a0e8c06ed20:   sub    $0x4,%r9d
  0x00007a0e8c06ed24:   jne    0x00007a0e8c06ece0
  0x00007a0e8c06ed26:   vmovdqu %ymm4,0x10(%rbp,%rsi,2)


And here is the kernel code generated **with** this patch:

  0x000070118c06a033:   vmovd  %edi,%xmm5 
  0x000070118c06a037:   vmovq  %rbp,%xmm3
  0x000070118c06a03c:   vmovd  %ecx,%xmm2
  0x000070118c06a040:   mov    %r9d,(%rsp)
  0x000070118c06a044:   lea    0x10(%rsi,%r10,2),%r14                       # start of the second gather_load operation
  0x000070118c06a049:   mov    %r11,%rbp
  0x000070118c06a04c:   mov    $0x8,%ecx
  0x000070118c06a051:   vpxor  %xmm4,%xmm4,%xmm4
  0x000070118c06a055:   vpxor  %xmm10,%xmm10,%xmm10
  0x000070118c06a05a:   vpcmpeqd %xmm11,%xmm11,%xmm11
  0x000070118c06a05f:   vpsubd %xmm11,%xmm4,%xmm11
  0x000070118c06a064:   vpslld $0x1,%xmm11,%xmm11
  0x000070118c06a06a:   vmovdqu 0x45cgt8e(%rip),%xmm4        # Stub::Stub Generator vector_iota_indices_stub+128 0x000070118c0afd00
                                                            ;   {external_word}
  0x000070118c06a072:   vpxor  %xmm6,%xmm6,%xmm6
  0x000070118c06a076:   mov    0x0(%rbp),%edi
  0x000070118c06a079:   vpinsrw $0x0,(%r14,%rdi,2),%xmm6,%xmm6
  0x000070118c06a080:   mov    0x4(%rbp),%edi
  0x000070118c06a083:   vpinsrw $0x1,(%r14,%rdi,2),%xmm6,%xmm6
  0x000070118c06a08a:   mov    0x8(%rbp),%edi
  0x000070118c06a08d:   vpinsrw $0x2,(%r14,%rdi,2),%xmm6,%xmm6
  0x000070118c06a094:   mov    0xc(%rbp),%edi
  0x000070118c06a097:   vpinsrw $0x3,(%r14,%rdi,2),%xmm6,%xmm6
  0x000070118c06a09e:   vpermd %ymm6,%ymm4,%ymm6
  0x000070118c06a0a3:   vpsubd %xmm11,%xmm4,%xmm4
  0x000070118c06a0a8:   vpor   %xmm6,%xmm10,%xmm10
  0x000070118c06a0ac:   add    $0x10,%rbp
  0x000070118c06a0b0:   sub    $0x4,%ecx
  0x000070118c06a0b3:   jne    0x000070118c06a072
  0x000070118c06a0b5:   vmovdqu %xmm10,%xmm4                                # vector reinterpret, the end of second gather_load
  0x000070118c06a0ba:   vperm2i128 $0x21,%ymm4,%ymm9,%ymm6      # vector slice
 
  0x000070118c06a0c0:   lea    0x10(%rsi,%r10,2),%r11                               # start of the first gather_load operation                       
  0x000070118c06a0c5:   mov    %rax,%rcx
  0x000070118c06a0c8:   mov    $0x8,%r8d
  0x000070118c06a0ce:   vpxor  %xmm10,%xmm10,%xmm10
  0x000070118c06a0d3:   vpxor  %xmm4,%xmm4,%xmm4
  0x000070118c06a0d7:   vpcmpeqd %xmm13,%xmm13,%xmm13
  0x000070118c06a0dc:   vpsubd %xmm13,%xmm10,%xmm13
  0x000070118c06a0e1:   vpslld $0x1,%xmm13,%xmm13
  0x000070118c06a0e7:   vmovdqu 0x45c11(%rip),%xmm10        # Stub::Stub Generator vector_iota_indices_stub+128 0x000070118c0afd00
                                                            ;   {external_word}
  0x000070118c06a0ef:   vpxor  %xmm12,%xmm12,%xmm12
  0x000070118c06a0f4:   mov    (%rcx),%r9d
  0x000070118c06a0f7:   vpinsrw $0x0,(%r11,%r9,2),%xmm12,%xmm12
  0x000070118c06a0fe:   mov    0x4(%rcx),%r9d
  0x000070118c06a102:   vpinsrw $0x1,(%r11,%r9,2),%xmm12,%xmm12
  0x000070118c06a109:   mov    0x8(%rcx),%r9d
  0x000070118c06a10d:   vpinsrw $0x2,(%r11,%r9,2),%xmm12,%xmm12
  0x000070118c06a114:   mov    0xc(%rcx),%r9d
  0x000070118c06a118:   vpinsrw $0x3,(%r11,%r9,2),%xmm12,%xmm12
  0x000070118c06a11f:   vpermd %ymm12,%ymm10,%ymm12
  0x000070118c06a124:   vpsubd %xmm13,%xmm10,%xmm10
  0x000070118c06a129:   vpor   %xmm12,%xmm4,%xmm4
  0x000070118c06a12e:   add    $0x10,%rcx
  0x000070118c06a132:   sub    $0x4,%r8d
  0x000070118c06a136:   jne    0x000070118c06a0ef
  0x000070118c06a138:   vmovdqu %xmm4,%xmm4                     ; vector reinterpret, the end of the first gather_load 
  0x000070118c06a13c:   vpor   %ymm6,%ymm4,%ymm4             ; final merge
  0x000070118c06a140:   vmovq  %xmm3,%r11
  0x000070118c06a145:   vmovdqu %ymm4,0x10(%r11,%r10,2)     ;*invokestatic store {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - jdk.incubator.vector.ShortVector::intoArray at 44 (line 3514)
                                                            ; - VectorAPITest::gather_short at 38 (line 116)


For the masked cases, besides additional added instructions, there are more code generated for the **mask slice** operations.

I also attached the full code for kinds of cases. Please kindly share your feedback. Thanks a lot!
[avx2_short_max_after.txt](https://github.com/user-attachments/files/24160578/avx2_short_max_after.txt)
[avx2_short_max_before.txt](https://github.com/user-attachments/files/24160581/avx2_short_max_before.txt)
[avx3_short_max_before.txt](https://github.com/user-attachments/files/24160582/avx3_short_max_before.txt)
[avx3_short_max_after.txt](https://github.com/user-attachments/files/24160584/avx3_short_max_after.txt)
[avx3_short_max_masked_after.txt](https://github.com/user-attachments/files/24160638/avx3_short_max_masked_after.txt)
[avx3_short_max_masked_before.txt](https://github.com/user-attachments/files/24160644/avx3_short_max_masked_before.txt)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28520#issuecomment-3654421400

From aartemov at openjdk.org  Mon Dec 15 08:43:08 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Mon, 15 Dec 2025 08:43:08 GMT
Subject: RFR: 8373497: SpinCriticalSection should use SpinYield
In-Reply-To: <0mwpdYvblZT_wpA4M9af5IlyZnHRZctR85y4kWAByeI=.f352d845-8953-4928-b6c1-609380e3df32@github.com>
References: <RHXygdCF_IpKSJEDYgnHslxOdjUC1YjvssLitKsERv4=.a51620a1-963d-464b-9f97-03e76a7b5d9b@github.com>
 <0mwpdYvblZT_wpA4M9af5IlyZnHRZctR85y4kWAByeI=.f352d845-8953-4928-b6c1-609380e3df32@github.com>
Message-ID: <KPF-r-k0sOMuZb_mmFsZf-79RdZtqYqFQZGLz-a4CIM=.9abde4d3-ef98-4283-9459-fb18e1a8690e@github.com>

On Fri, 12 Dec 2025 13:10:59 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> The original code of `Thread::SpinAqcuire()` was moved into a RAII object `SpinCriticalSection` in https://bugs.openjdk.org/browse/JDK-8366671
>> 
>> It to a great extent duplicates the code of the `SpinYield` class, which is more flexible. In this PR the duplication is removed as `SpinCriticalSection` now makes uses of  `SpinYield`.
>> 
>> Tested in tiers 1-3.
>> 
>> Extended performance testing has shown that the change is neutral.
>
> Thank you!!

Thanks for reviews @coleenp and @dholmes-ora !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28763#issuecomment-3654435807

From aartemov at openjdk.org  Mon Dec 15 08:43:10 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Mon, 15 Dec 2025 08:43:10 GMT
Subject: Integrated: 8373497: SpinCriticalSection should use SpinYield
In-Reply-To: <RHXygdCF_IpKSJEDYgnHslxOdjUC1YjvssLitKsERv4=.a51620a1-963d-464b-9f97-03e76a7b5d9b@github.com>
References: <RHXygdCF_IpKSJEDYgnHslxOdjUC1YjvssLitKsERv4=.a51620a1-963d-464b-9f97-03e76a7b5d9b@github.com>
Message-ID: <XlgoS-LWTBnOnXf-WaSA5ohhiikwrM0Re8gufDLB1-U=.fb77ad3c-acb5-4890-bb31-cb2079327dcf@github.com>

On Thu, 11 Dec 2025 09:09:05 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> The original code of `Thread::SpinAqcuire()` was moved into a RAII object `SpinCriticalSection` in https://bugs.openjdk.org/browse/JDK-8366671
> 
> It to a great extent duplicates the code of the `SpinYield` class, which is more flexible. In this PR the duplication is removed as `SpinCriticalSection` now makes uses of  `SpinYield`.
> 
> Tested in tiers 1-3.
> 
> Extended performance testing has shown that the change is neutral.

This pull request has now been integrated.

Changeset: 5141e1a4
Author:    Anton Artemov <aartemov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5141e1a4f4ef7499ddd8684469d8038fd75403d2
Stats:     18 lines in 1 file changed: 3 ins; 14 del; 1 mod

8373497: SpinCriticalSection should use SpinYield

Reviewed-by: dholmes, coleenp

-------------

PR: https://git.openjdk.org/jdk/pull/28763

From aboldtch at openjdk.org  Mon Dec 15 10:14:07 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 15 Dec 2025 10:14:07 GMT
Subject: RFR: 8373668: Add override keyword to *Klass classes
Message-ID: <rJP1-555XexBIvK3yH_SdGiAEJjT38wEqZmslbynvOg=.1205594c-d2f0-40a1-9000-a7a6707a7d84@github.com>

Using override provides better visibility and compiler support for suspicious virtual methods. It makes it clears when reading a class header file if a new virtual interface is introduced or if it simply overridden.

Testing
 * GHA
 * Running tier1 on Oracle supported platforms

-------------

Commit messages:
 - Add override keyword to *Klass classes

Changes: https://git.openjdk.org/jdk/pull/28820/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28820&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373668
  Stats: 99 lines in 7 files changed: 0 ins; 5 del; 94 mod
  Patch: https://git.openjdk.org/jdk/pull/28820.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28820/head:pull/28820

PR: https://git.openjdk.org/jdk/pull/28820

From shade at openjdk.org  Mon Dec 15 10:17:11 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 15 Dec 2025 10:17:11 GMT
Subject: RFR: 8373266: Strengthen constant CardTable base accesses
In-Reply-To: <k38G94Tpq-aEKy5qzf8vaCMgcn0KHYw4JTWm0-RWgIQ=.5da23c7e-d826-41c2-b42f-ec2a90fd2213@github.com>
References: <k38G94Tpq-aEKy5qzf8vaCMgcn0KHYw4JTWm0-RWgIQ=.5da23c7e-d826-41c2-b42f-ec2a90fd2213@github.com>
Message-ID: <_szeC-N8HfgGKOuDjXYHs8SwZFQQnffiG31iwdLYO9k=.8e56abbd-cfd5-49fb-ab22-178616705f56@github.com>

On Mon, 8 Dec 2025 18:45:04 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Shenandoah and G1 are using CardTable for most of its infrastructure, but flip the card tables as they go, and maintain the actual card table reference in TLS. As such, accessing card table base from assembler and compilers runs into risk of accidentally encoding the wrong card table base in generated code. 
> 
> Most of the current code avoids this trouble by carefully implementing their GC barriers to avoid touching shared parts where card table base constness is assumed. _Except_ for JVMCI, that reads the card table base for G1 barrier set, and that is wrong. The JVMCI users would need to rectify this downstream.
> 
> Shenandoah added a few asserts to catch these errors:
>  SHENANDOAHGC_ONLY(assert(!UseShenandoahGC, "Shenandoah byte_map_base is not constant.");)
> 
> ...but G1 would also benefit from the similar safety mechanism.
> 
> This PR strengthens the code to prevent future accidents.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `hotspot_gc`
>  - [x] Linux x86_64 server fastdebug, `all` with Serial, Parallel, G1, Shenandoah, Z
>  - [x] Linux AArch64 server fastdebug, `all` with Serial, Parallel, G1, Shenandoah, Z
>  - [x] GHA, cross-compilation only

`all` tests are passing with various GC combinations as well. Ready for review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28703#issuecomment-3654844328

From rrich at openjdk.org  Mon Dec 15 10:26:08 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 15 Dec 2025 10:26:08 GMT
Subject: RFR: 8369515: Deadlock between JVMTI and JNI
 ReleasePrimitiveArrayCritical
In-Reply-To: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
References: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
Message-ID: <wMkcwC58TwDiGv1yMKfq3ZTBLj4HmU7VHce5xAbPpyU=.f6a5adc3-88cc-4279-bff6-d2aef46138f7@github.com>

On Fri, 12 Dec 2025 04:20:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

> As discussed in JBS the deadlock occurs when the call to `ReleasePrimitiveArrayCritical` performs the transition from native to VM, and in the process checks for special runtime exit conditions - which includes the `obj_deopt_suspend` request. The simple solution is to define a custom JNI ENTRY with custom `ThreadInVMfromNative` that elides the exit check.
> 
> The change is limited to `ReleasePrimitiveArrayCritical` and `ReleaseStringCritical`.
> 
> There is no regression test as this has only been seen in long running stress tests.
> 
> Testing:
>    -tiers 1-6

Thanks for providing a fix for the issue David.
I've scheduled some local testing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28779#issuecomment-3654877794

From qpzhang at openjdk.org  Mon Dec 15 10:26:54 2025
From: qpzhang at openjdk.org (Patrick Zhang)
Date: Mon, 15 Dec 2025 10:26:54 GMT
Subject: RFR: 8365991: AArch64: Ignore BlockZeroingLowLimit when
 UseBlockZeroing is false [v10]
In-Reply-To: <pSbTemGu8e1IiEiqk0ENZ_GgEVyi-NoA2U01iK_dMDM=.a8308160-ba13-4b39-9696-93e1e3e6f67f@github.com>
References: <pSbTemGu8e1IiEiqk0ENZ_GgEVyi-NoA2U01iK_dMDM=.a8308160-ba13-4b39-9696-93e1e3e6f67f@github.com>
Message-ID: <bS689hcbnx3TW1mFckt96o4Zc8hboTxSAWKjJKW1Ktk=.8f5fddc5-700e-42ae-b353-816aeb3a0ff3@github.com>

> 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 <patrick at os.amperecomputing.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26917/files
  - new: https://git.openjdk.org/jdk/pull/26917/files/f39078bd..5401fdf5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26917&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26917&range=08-09

  Stats: 13 lines in 2 files changed: 1 ins; 0 del; 12 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 aph at openjdk.org  Mon Dec 15 10:40:39 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 15 Dec 2025 10:40:39 GMT
Subject: RFR: 8372701: Randomized profile counters [v2]
In-Reply-To: <r-mcwZnhCQvaRfSM8aZzIcyAV8gdtPqOWdwnswW35uc=.c5c0ac59-4032-4a1a-9d13-d428e41b85aa@github.com>
References: <jKjmIONZcytzVjS4absOwOLv_QOF9qhIJifYhN6JyP4=.dceced94-bc29-43e6-9062-8dc77c2a6133@github.com>
 <YAdyTG2jqY3OcJ7M4mD0CkL56a0p6ciaHYM-ow9Ham8=.0cb57295-acde-4e49-984b-b8756ed99850@github.com>
 <r-mcwZnhCQvaRfSM8aZzIcyAV8gdtPqOWdwnswW35uc=.c5c0ac59-4032-4a1a-9d13-d428e41b85aa@github.com>
Message-ID: <prP0CBmI0Fxwu28rapv9RhTFY4JROMmWhSHWFSlNDEA=.a13961ad-a0f6-4ac0-948d-e9fd217b17ea@github.com>

On Thu, 27 Nov 2025 17:56:45 GMT, Andrew Haley <aph at openjdk.org> wrote:

> One other thing that comes into mind: the initial swing from `0` -> `1` for a type counter is important, since `0` means "never seen the type at all", and `>0` means "maybe the type is present, however rare". I would suspect subsampling a small count to `0` would cause performance anomalies. Especially if, say, this anomaly causes a deopt - reprofile - compile cycle. It would doubly hurt, if _reprofile_ would miss the type _again_. Probably hard to do with RNG, but maybe we should be doing the initial counter seed on installation without consulting RNG.

I've been thinking about this some more, and I wonder how important it really is. Let's say we don't compile a method until it's been interpreted a couple of hundred times (it's at least 128). We're speculating that the call site is polymorphic, but so far has been called only monomorpically, so we need to check every invocation, just in case. I guess this does happen occasionally during some application warmup scenarios, but does it really matter? I guess we could try a big performance test suite to learn if with (say) 64-times decimation we see more recompilation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28541#issuecomment-3654942036

From wenanjian at openjdk.org  Mon Dec 15 10:53:18 2025
From: wenanjian at openjdk.org (Anjian Wen)
Date: Mon, 15 Dec 2025 10:53:18 GMT
Subject: RFR: 8373069: RISC-V: implement GHASH intrinsic [v4]
In-Reply-To: <v8ITeVbN22plVmUAuQon2-iWYYXhm7qDML3kR7VJQPg=.4c6d1b1d-28f1-4efb-bd9c-64f3e6408c81@github.com>
References: <zxCNQIhhidoKzHbxL0z8h_Tp1N8pCmlHNoJ2wx30XF8=.a3d8eb05-9a07-403e-a014-84c3bb32b001@github.com>
 <8MCvHCHkscmoOkB_cKGP5mkhHWBw6B3PfalaBL4aVg0=.0a6e3bc9-7b6b-498d-81fb-1a276adc2a31@github.com>
 <v8ITeVbN22plVmUAuQon2-iWYYXhm7qDML3kR7VJQPg=.4c6d1b1d-28f1-4efb-bd9c-64f3e6408c81@github.com>
Message-ID: <N5MWmRuSgidaCacKggfCxX-_X2KzgKRD-r438h7bDXI=.b8850e31-8442-41dd-ba45-a84f23b5ec78@github.com>

On Mon, 15 Dec 2025 01:35:51 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Anjian Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   modify format
>
> src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 3021:
> 
>> 3019:     assert(UseZvkg, "need GHASH instructions (Zvkg extension) support");
>> 3020: 
>> 3021:     __ align(CodeEntryAlignment);
> 
> Can you move this line to immediately before L3025? Like:
> 
>     __ align(CodeEntryAlignment);
>     address start = __ pc();
>     __ enter();
> 
> 
> Then it looks more obvious where we want to align the code. BTW: Seems CBC and CTR intrinsics need similar adjustment.

it seems most of the intrinsics use align func before stub_id, maybe we can keep it for now and discuss all of them later?

> src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 3052:
> 
>> 3050:       __ vghsh_vv(partial_hash, hash_subkey, cipher_text);
>> 3051:       __ subi(blocks, blocks, 1);
>> 3052:       __ bnez(blocks, L_ghash_loop);
> 
> Please leave a new line after the loop.

Thanks, fixed!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28548#discussion_r2618904912
PR Review Comment: https://git.openjdk.org/jdk/pull/28548#discussion_r2618905299

From wenanjian at openjdk.org  Mon Dec 15 10:53:15 2025
From: wenanjian at openjdk.org (Anjian Wen)
Date: Mon, 15 Dec 2025 10:53:15 GMT
Subject: RFR: 8373069: RISC-V: implement GHASH intrinsic [v5]
In-Reply-To: <zxCNQIhhidoKzHbxL0z8h_Tp1N8pCmlHNoJ2wx30XF8=.a3d8eb05-9a07-403e-a014-84c3bb32b001@github.com>
References: <zxCNQIhhidoKzHbxL0z8h_Tp1N8pCmlHNoJ2wx30XF8=.a3d8eb05-9a07-403e-a014-84c3bb32b001@github.com>
Message-ID: <yRSHWlMt6VRBC2-LwmTM04tPCfPMMbf5TcPBMoL9KEk=.ef0684da-6ad9-47a6-bfcd-550c3c7be272@github.com>

> support GHASH intrinsic for crypt GCM, which need zvkg extension. 
> 
> passed the tests in 
> test/hotspot/jtreg/compiler/codegen/aes/
> test/jdk/com/sun/crypto

Anjian Wen has updated the pull request incrementally with one additional commit since the last revision:

  delete some redundant assert and modify some format

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28548/files
  - new: https://git.openjdk.org/jdk/pull/28548/files/3bf38390..fb0f549f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28548&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28548&range=03-04

  Stats: 24 lines in 2 files changed: 10 ins; 6 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/28548.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28548/head:pull/28548

PR: https://git.openjdk.org/jdk/pull/28548

From shade at openjdk.org  Mon Dec 15 11:18:31 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 15 Dec 2025 11:18:31 GMT
Subject: RFR: 8372701: Randomized profile counters [v2]
In-Reply-To: <prP0CBmI0Fxwu28rapv9RhTFY4JROMmWhSHWFSlNDEA=.a13961ad-a0f6-4ac0-948d-e9fd217b17ea@github.com>
References: <jKjmIONZcytzVjS4absOwOLv_QOF9qhIJifYhN6JyP4=.dceced94-bc29-43e6-9062-8dc77c2a6133@github.com>
 <YAdyTG2jqY3OcJ7M4mD0CkL56a0p6ciaHYM-ow9Ham8=.0cb57295-acde-4e49-984b-b8756ed99850@github.com>
 <r-mcwZnhCQvaRfSM8aZzIcyAV8gdtPqOWdwnswW35uc=.c5c0ac59-4032-4a1a-9d13-d428e41b85aa@github.com>
 <prP0CBmI0Fxwu28rapv9RhTFY4JROMmWhSHWFSlNDEA=.a13961ad-a0f6-4ac0-948d-e9fd217b17ea@github.com>
Message-ID: <ccf5KPazc5XBzD5VrpjF-W1BSHUNvPED5I5Ovt3eCEA=.345e48ae-eb4c-4659-a6ac-306c14877bf7@github.com>

On Mon, 15 Dec 2025 10:38:21 GMT, Andrew Haley <aph at openjdk.org> wrote:

> I've been thinking about this some more, and I wonder how important it really is. Let's say we don't compile a method until it's been interpreted a couple of hundred times (it's at least 128). We're speculating that the call site is polymorphic, but so far has been called only monomorpically, so we need to check every invocation, just in case. I guess this does happen occasionally during some application warmup scenarios, but does it really matter? 

For steady state it does not matter. But for warmup, Leyden teaches us (we were whack-a-mole-ing problems like these for the better part of the year there) that misguided trap-recompilation trip through C2 costs a lot. The compiler dynamics gets so funky that you start looking out for things that look "probably fine" on paper, but may conspire against you every so often. This looks to me as one of those things.

To make matters worse, for the applications that have clearly defined warmup/steady states, there is code that would execute _only_ during warmup. Think initialization code that takes a particular path once and only once. For warmup in AOT mode, you really want that code to be generated ahead of time. Because it defeats the purpose of AOT to spend lots of JIT compilation time recompiling for a one-off initialization case. Which forces AOT code to be compiled more pessimistically. I can see how missing a rare receiver sets up AOT compilation for overly optimistic compilation that would trap at runtime, and at the worst time -- at warmup -- when compilers are already burning up.

In other words, that "does happen occasionally during some application warmup scenarios" is one of the things that Leyden tries to summarily avoid. 

To your example: indeed, there is no recourse in case when really-polymorphic site is accidentally looking monomorphic due to code behavior artifacts: e.g. no one came with rare type just yet. But IMO that does not mean we would be opening more performance trap-doors when some code _did_ come with the rare type, especially if it is easy to handle.

The fact that some of your horses might have bolted, does not give you a good reason to open the barn door a bit wider :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28541#issuecomment-3655073299

From qpzhang at openjdk.org  Mon Dec 15 11:20:43 2025
From: qpzhang at openjdk.org (Patrick Zhang)
Date: Mon, 15 Dec 2025 11:20:43 GMT
Subject: RFR: 8365991: AArch64: Ignore BlockZeroingLowLimit when
 UseBlockZeroing is false [v7]
In-Reply-To: <PWgJd1oLHct76XEhEG7KjuWV3Ok6Ub7sBU9mk0cO5WU=.7effc5a3-c13b-435b-bebf-841b70817fc5@github.com>
References: <pSbTemGu8e1IiEiqk0ENZ_GgEVyi-NoA2U01iK_dMDM=.a8308160-ba13-4b39-9696-93e1e3e6f67f@github.com>
 <GjVnBFpmztg63oLghMGJ9h178LbFxKFQk-2IbR8T3Rk=.8fd619fc-6c35-459a-bf7f-ed20d48295eb@github.com>
 <X2pvoXwE_OG1CrPot5efsgf8N1wqMr2rp-WrqDxlcXw=.e772e271-ae35-47f1-8523-56542a88db43@github.com>
 <tW59JkXtBEwBuw6qkKM0YIxJjTwoTbGZ3oWhXurqwC8=.e5e87d0b-ce15-4d2b-97dd-b747a69df5fd@github.com>
 <Ww3ORHqx6LlDQKlkH83q8jcZlKloPC5E0Cd2sB8R5Zg=.ee27c69f-3412-4b4e-8288-f36ebf8494e2@github.com>
 <PWgJd1oLHct76XEhEG7KjuWV3Ok6Ub7sBU9mk0cO5WU=.7effc5a3-c13b-435b-bebf-841b70817fc5@github.com>
Message-ID: <Vps6CYxoQwmoCJgJvyeNxJD7xlEmM24wP7OQLyFEcSk=.959ff9ba-6f4b-4d39-89f1-012b76acac73@github.com>

On Fri, 5 Dec 2025 12:06:16 GMT, Patrick Zhang <qpzhang at openjdk.org> wrote:

>>> I wondered why `MacroAssembler::zero_words` uses 16 words to do `stp` unrolling, while `generate_zero_blocks()` 8 words (`const int MacroAssembler::zero_words_block_size = 8;`), so defined this variable to compare `8 vs 16` but did not find obvious performance difference.
>>> 
>>> Regarding the var name `block_size`, could `unroll` or `unroll_words` be better?
>> 
>> What's wrong with 16? I'm asking not from a "my teachers said always name constants" point of view, but from a reader's understanding point of view. Named constants are all well and good if the constant has some meaning, but this one is just two words. Perhaps `2 * WordSize` would do.
>
> [PR 4919](https://github.com/openjdk/jdk/pull/4919/files#diff-0f4150a9c607ccd590bf256daa800c0276144682a92bc6bdced5e8bc1bb81f3aL4737) for [8270947: AArch64: C1: use zero_words to initialize all objects](https://bugs.openjdk.org/browse/JDK-8270947) changed the loop unroll length from 4 STPs (clearing 8 words) to 8 STPs (clearing 16 words) within the loop. In fact, before that PR, it seems the value 16 was from the `SmallArraySize` (`18 * BytesPerLong`).
> 
> For the current code snippet, I think, using `2 * WordSize` to the constant is not ideal, as it suggests the size of the unroll length and can be confusing. A better choice might be `2 * MacroAssembler::zero_words_block_size`, which more accurately reflects the intended meaning. Is this acceptable?

Please see the latest commit. I renamed the var name to `unroll_words` in `address MacroAssembler::zero_words(Register base, uint64_t cnt)` and `address generate_zero_blocks()` and have them aligned, one for 16 words and the other for 8 words to do unrolling for block clearing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26917#discussion_r2618990845

From qpzhang at openjdk.org  Mon Dec 15 11:20:44 2025
From: qpzhang at openjdk.org (Patrick Zhang)
Date: Mon, 15 Dec 2025 11:20:44 GMT
Subject: RFR: 8365991: AArch64: Ignore BlockZeroingLowLimit when
 UseBlockZeroing is false [v7]
In-Reply-To: <Vps6CYxoQwmoCJgJvyeNxJD7xlEmM24wP7OQLyFEcSk=.959ff9ba-6f4b-4d39-89f1-012b76acac73@github.com>
References: <pSbTemGu8e1IiEiqk0ENZ_GgEVyi-NoA2U01iK_dMDM=.a8308160-ba13-4b39-9696-93e1e3e6f67f@github.com>
 <GjVnBFpmztg63oLghMGJ9h178LbFxKFQk-2IbR8T3Rk=.8fd619fc-6c35-459a-bf7f-ed20d48295eb@github.com>
 <X2pvoXwE_OG1CrPot5efsgf8N1wqMr2rp-WrqDxlcXw=.e772e271-ae35-47f1-8523-56542a88db43@github.com>
 <tW59JkXtBEwBuw6qkKM0YIxJjTwoTbGZ3oWhXurqwC8=.e5e87d0b-ce15-4d2b-97dd-b747a69df5fd@github.com>
 <Ww3ORHqx6LlDQKlkH83q8jcZlKloPC5E0Cd2sB8R5Zg=.ee27c69f-3412-4b4e-8288-f36ebf8494e2@github.com>
 <PWgJd1oLHct76XEhEG7KjuWV3Ok6Ub7sBU9mk0cO5WU=.7effc5a3-c13b-435b-bebf-841b70817fc5@github.com>
 <Vps6CYxoQwmoCJgJvyeNxJD7xlEmM24wP7OQLyFEcSk=.959ff9ba-6f4b-4d39-89f1-012b76acac73@github.com>
Message-ID: <AhsP1Gr_N6DyknJnoxwG_YId2M4DDVwSsKnrouWnXN4=.8ec1c7ea-ae16-4b8e-8ae2-0e410f8872d3@github.com>

On Mon, 15 Dec 2025 11:15:14 GMT, Patrick Zhang <qpzhang at openjdk.org> wrote:

>> [PR 4919](https://github.com/openjdk/jdk/pull/4919/files#diff-0f4150a9c607ccd590bf256daa800c0276144682a92bc6bdced5e8bc1bb81f3aL4737) for [8270947: AArch64: C1: use zero_words to initialize all objects](https://bugs.openjdk.org/browse/JDK-8270947) changed the loop unroll length from 4 STPs (clearing 8 words) to 8 STPs (clearing 16 words) within the loop. In fact, before that PR, it seems the value 16 was from the `SmallArraySize` (`18 * BytesPerLong`).
>> 
>> For the current code snippet, I think, using `2 * WordSize` to the constant is not ideal, as it suggests the size of the unroll length and can be confusing. A better choice might be `2 * MacroAssembler::zero_words_block_size`, which more accurately reflects the intended meaning. Is this acceptable?
>
> Please see the latest commit. I renamed the var name to `unroll_words` in `address MacroAssembler::zero_words(Register base, uint64_t cnt)` and `address generate_zero_blocks()` and have them aligned, one for 16 words and the other for 8 words to do unrolling for block clearing.

Resolved this on the old code. Any further comments, please feel free to reopen.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26917#discussion_r2618994635

From kbarrett at openjdk.org  Mon Dec 15 11:44:19 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 15 Dec 2025 11:44:19 GMT
Subject: RFR: 8373668: Add override keyword to *Klass classes
In-Reply-To: <rJP1-555XexBIvK3yH_SdGiAEJjT38wEqZmslbynvOg=.1205594c-d2f0-40a1-9000-a7a6707a7d84@github.com>
References: <rJP1-555XexBIvK3yH_SdGiAEJjT38wEqZmslbynvOg=.1205594c-d2f0-40a1-9000-a7a6707a7d84@github.com>
Message-ID: <ZwqwzA-EjLR6VpQxQSCXAbqJ9u7kaKHtqwJmMrhN0iY=.6bb9ec68-a294-40e0-abc4-5b0158d69c3f@github.com>

On Mon, 15 Dec 2025 10:08:18 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Using override provides better visibility and compiler support for suspicious virtual methods. It makes it clears when reading a class header file if a new virtual interface is introduced or if it simply overridden.
> 
> Testing
>  * GHA
>  * Running tier1 on Oracle supported platforms

Looks good.

A couple of pre-existing whitespace issues that you can fix or ignore.

I wonder if there would be any measurable benefit to using `final` instead in some
cases?  But that should be looked at separately.  It might be simpler to declare some
classes to be `final`.

src/hotspot/share/oops/instanceKlass.hpp line 906:

> 904:                                                   Array<InstanceKlass*>* transitive_interfaces) override;
> 905:   bool can_be_primary_super_slow() const override;
> 906:   size_t oop_size(oop obj)  const override    { return size_helper(); }

[pre-existing] Extra space before `const`.

src/hotspot/share/oops/instanceKlass.hpp line 952:

> 950:   }
> 951: 
> 952:   int size() const override           { return size(vtable_length(),

[pre-existing] Weird and confusing indentation for the arguments to `size(...)`.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28820#pullrequestreview-3577725050
PR Review Comment: https://git.openjdk.org/jdk/pull/28820#discussion_r2619059748
PR Review Comment: https://git.openjdk.org/jdk/pull/28820#discussion_r2619057335

From stefank at openjdk.org  Mon Dec 15 12:21:16 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 15 Dec 2025 12:21:16 GMT
Subject: RFR: 8373599: Cleanup arguments.hpp includes [v2]
In-Reply-To: <Kqz_5CO6d3_qHfiP4oBX9R8-w4XhLgf41eFGcBPABRM=.64ef1a0f-20b2-4adb-ba32-4b96b5310319@github.com>
References: <Qk3QT6NyM0BgtE_qbj_s8LrSR8bTloYqu8ojT51cgEs=.f60dd6b4-e844-4b46-82a3-69efafe0206d@github.com>
 <Kqz_5CO6d3_qHfiP4oBX9R8-w4XhLgf41eFGcBPABRM=.64ef1a0f-20b2-4adb-ba32-4b96b5310319@github.com>
Message-ID: <_E9zwmwzDIm8asUBOixzqTCC7zSdDKttYhkKjkGUQEY=.ac4f58d5-06fd-4aba-a05d-f6cd48a8c2c2@github.com>

On Fri, 12 Dec 2025 15:06:39 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> In the Valhalla project we are considering using a property in Arguments to figure out if Valhalla is enabled. To minimize transitive-include-proliferation if this property ever needs to be checked in a header I propose that we clean up the header includes in arguments.hpp.
>> 
>> I'm opening the review for this so that I can get opinions on the move of functions. I'm going to compile this on all our platforms and will likely add a few more includes when unrelated files fail to compile because they relied on the includes provided through by java.hpp and arguments.hpp.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Sort order

Anyone else wants to put the second reviewer stamp on this?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28791#issuecomment-3655312670

From tschatzl at openjdk.org  Mon Dec 15 12:21:16 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 15 Dec 2025 12:21:16 GMT
Subject: RFR: 8373668: Add override keyword to *Klass classes
In-Reply-To: <rJP1-555XexBIvK3yH_SdGiAEJjT38wEqZmslbynvOg=.1205594c-d2f0-40a1-9000-a7a6707a7d84@github.com>
References: <rJP1-555XexBIvK3yH_SdGiAEJjT38wEqZmslbynvOg=.1205594c-d2f0-40a1-9000-a7a6707a7d84@github.com>
Message-ID: <DshS6NGuvc4X1Vnjg8MexbLMt_cKNhWm2L726QZawf0=.6014fb16-73cd-48ed-8889-51b995a06173@github.com>

On Mon, 15 Dec 2025 10:08:18 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Using override provides better visibility and compiler support for suspicious virtual methods. It makes it clears when reading a class header file if a new virtual interface is introduced or if it simply overridden.
> 
> Testing
>  * GHA
>  * Running tier1 on Oracle supported platforms

Marked as reviewed by tschatzl (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28820#pullrequestreview-3577857898

From kbarrett at openjdk.org  Mon Dec 15 12:28:08 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 15 Dec 2025 12:28:08 GMT
Subject: RFR: 8373599: Cleanup arguments.hpp includes [v2]
In-Reply-To: <Kqz_5CO6d3_qHfiP4oBX9R8-w4XhLgf41eFGcBPABRM=.64ef1a0f-20b2-4adb-ba32-4b96b5310319@github.com>
References: <Qk3QT6NyM0BgtE_qbj_s8LrSR8bTloYqu8ojT51cgEs=.f60dd6b4-e844-4b46-82a3-69efafe0206d@github.com>
 <Kqz_5CO6d3_qHfiP4oBX9R8-w4XhLgf41eFGcBPABRM=.64ef1a0f-20b2-4adb-ba32-4b96b5310319@github.com>
Message-ID: <GXa036YTkC3X-vL1hLQQhQPRcaEL9rlvy5lZ4AGT1XA=.7af12d76-0eca-428d-af7c-75b573bbb81d@github.com>

On Fri, 12 Dec 2025 15:06:39 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> In the Valhalla project we are considering using a property in Arguments to figure out if Valhalla is enabled. To minimize transitive-include-proliferation if this property ever needs to be checked in a header I propose that we clean up the header includes in arguments.hpp.
>> 
>> I'm opening the review for this so that I can get opinions on the move of functions. I'm going to compile this on all our platforms and will likely add a few more includes when unrelated files fail to compile because they relied on the includes provided through by java.hpp and arguments.hpp.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Sort order

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28791#pullrequestreview-3577883660

From fjiang at openjdk.org  Mon Dec 15 12:33:18 2025
From: fjiang at openjdk.org (Feilong Jiang)
Date: Mon, 15 Dec 2025 12:33:18 GMT
Subject: RFR: 8373069: RISC-V: implement GHASH intrinsic [v5]
In-Reply-To: <yRSHWlMt6VRBC2-LwmTM04tPCfPMMbf5TcPBMoL9KEk=.ef0684da-6ad9-47a6-bfcd-550c3c7be272@github.com>
References: <zxCNQIhhidoKzHbxL0z8h_Tp1N8pCmlHNoJ2wx30XF8=.a3d8eb05-9a07-403e-a014-84c3bb32b001@github.com>
 <yRSHWlMt6VRBC2-LwmTM04tPCfPMMbf5TcPBMoL9KEk=.ef0684da-6ad9-47a6-bfcd-550c3c7be272@github.com>
Message-ID: <fr2dUm0H1akdUpj_1k1AYl3HGQ8gylmfsbHenlY-8CE=.0b7c3958-51da-4805-83e8-c8e19b0fcb64@github.com>

On Mon, 15 Dec 2025 10:53:15 GMT, Anjian Wen <wenanjian at openjdk.org> wrote:

>> support GHASH intrinsic for crypt GCM, which need zvkg extension. 
>> 
>> passed the tests in 
>> test/hotspot/jtreg/compiler/codegen/aes/
>> test/jdk/com/sun/crypto
>
> Anjian Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   delete some redundant assert and modify some format

Thanks!

-------------

Marked as reviewed by fjiang (Committer).

PR Review: https://git.openjdk.org/jdk/pull/28548#pullrequestreview-3577917011

From tschatzl at openjdk.org  Mon Dec 15 12:35:10 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 15 Dec 2025 12:35:10 GMT
Subject: RFR: 8373649: Convert simple AtomicAccess usage in
 ConcurrentHashTable to use Atomic<T>
In-Reply-To: <rcuhR8LdUTG0zHxMHGIbB6dD93LCz-voc8IHRV9NDnU=.3ace9437-f609-4702-b8c5-0f70db2a5935@github.com>
References: <rcuhR8LdUTG0zHxMHGIbB6dD93LCz-voc8IHRV9NDnU=.3ace9437-f609-4702-b8c5-0f70db2a5935@github.com>
Message-ID: <qWj65I2wF19f1CVMRTH9WvOep0zWOEqN2tIxDSrrpz0=.f5c20ac2-9861-453d-9007-d5bdc9c99d33@github.com>

On Mon, 15 Dec 2025 03:23:07 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this conversion of simple AtomicAccess usage in
> ConcurrentHashTable to use Atomic<T>.  This is split out from the complete
> conversion to simplify reviewing and testing.
> 
> Testing: mach5 tier1-3

Marked as reviewed by tschatzl (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28816#pullrequestreview-3577926251

From iwalulya at openjdk.org  Mon Dec 15 12:46:16 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 15 Dec 2025 12:46:16 GMT
Subject: RFR: 8373649: Convert simple AtomicAccess usage in
 ConcurrentHashTable to use Atomic<T>
In-Reply-To: <rcuhR8LdUTG0zHxMHGIbB6dD93LCz-voc8IHRV9NDnU=.3ace9437-f609-4702-b8c5-0f70db2a5935@github.com>
References: <rcuhR8LdUTG0zHxMHGIbB6dD93LCz-voc8IHRV9NDnU=.3ace9437-f609-4702-b8c5-0f70db2a5935@github.com>
Message-ID: <evdk9pg8BUZXP9gOFmlnHhCc9xyGfr72JPBQZg0ykTo=.6a45ed74-569f-4198-99b8-0f922136b314@github.com>

On Mon, 15 Dec 2025 03:23:07 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this conversion of simple AtomicAccess usage in
> ConcurrentHashTable to use Atomic<T>.  This is split out from the complete
> conversion to simplify reviewing and testing.
> 
> Testing: mach5 tier1-3

Marked as reviewed by iwalulya (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28816#pullrequestreview-3577980107

From duke at openjdk.org  Mon Dec 15 12:54:07 2025
From: duke at openjdk.org (SilenceZheng66)
Date: Mon, 15 Dec 2025 12:54:07 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v22]
In-Reply-To: <g0INjxl-T0NTw_GN4GkKl-d-gwjKQAmQs7_YB1R_LWo=.eaaddff1-531c-4ebc-956c-b091676be405@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <rAPcRMkxD0uoJTzadbMR7eui7ixfiVHCKy8JCvS5TPc=.6307f4fd-e333-41c8-97f2-81971974eb93@github.com>
 <C2nKyRSBdqEqIK0I3bEP1X4PM1K3Gb3HhPaxqgJeIS8=.62ffb736-16a7-4da9-8d11-1c147dfb40a1@github.com>
 <g0INjxl-T0NTw_GN4GkKl-d-gwjKQAmQs7_YB1R_LWo=.eaaddff1-531c-4ebc-956c-b091676be405@github.com>
Message-ID: <ET-MhWMYi6ja-ge-H209Fy9ZHkMPL-6ZaPEeegAAraM=.2f40c659-5c3c-486b-adea-66488fd6050d@github.com>

On Sat, 13 Dec 2025 02:04:27 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> src/hotspot/share/gc/parallel/psParallelCompact.cpp line 1070:
>> 
>>> 1068:     size_policy->sample_old_gen_used_bytes(MAX2(pre_gc_values.old_gen_used(), old_gen->used_in_bytes()));
>>> 1069: 
>>> 1070:     if (UseAdaptiveSizePolicy) {
>> 
>> I think this code block could raise heap size don't expand in some specific case, maybe you should optimize it. @albertnetymk
>
> @SilenceZheng66 Could you elaborate the issue, ideally, in a JBS ticket? (A reproducer/gc-log would be nice, but detailed description works as well.)

@albertnetymk Sure.  I will give detailed description here.

GC?PS MarkSweep?PS Scavenge

JVM configuraton:  
-Xmx2g 
-Xms256M 
-XX:MetaspaceSize=256m 
-XX:MaxMetaspaceSize=256m 
-XX:+PrintGCDateStamps 
-XX:+PrintGCDetails 
-XX:-UseAdaptiveSizePolicy 
-XX:+PrintAdaptiveSizePolicy 
-XX:+HeapDumpBeforeFullGC 
-XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=export/Logs/ 
-Xloggc:/export/Logs/gclogs.log 

JVM version?25.191-b12, although it's an old version without maintenance, I find out the problem might still in the latest version.

Problem Description: 
When starting a application(like SpringBoot), objects loading to VM continuously, my CPU usage suddenly began to skyrocket, followed by a full GC lasting over ten minutes with more than 2,700 occurrences. Examining the GC logs revealed that prior to the full GC, several successful young GC events had taken place until the old generation was completely filled. I read the source code and find out when -XX:-UseAdaptiveSizePolicy was set,  VM thread can't expand psOldGen, only GC worker can expand psOldGen's size in that condition. I assume that the transition from the younger generation to the older generation has been successful, so that GC worker's expansion was not reached, that made long term full GC happened.

Check List:
1. Container has enough place for heap expansion
2. Xms and Xmx were setting differently, same configuration in Serial GC can raise heap expansion

GC log sample:
// Full GC Starting
[PSYoungGen: 76276K->10735K(76288K)] 244793K->181638K(251392K), 0.0078092 secs] [Times: user=0.04 sys=0.00, real=0.01 secs] 
2025-12-10T14:11:58.663+0800: 24.604: [Heap Dump (before full gc): , 0.0000482 secs]2025-12-10T14:11:58.663+0800: 24.604: [Full GC (Ergonomics) [PSYoungGen: 10735K->0K(76288K)] [ParOldGen: 170902K->173351K(175104K)] 181638K->173351K(251392K), [Metaspace: 107770K->107770K(1146880K)], 0.5258832 secs] [Times: user=1.82 sys=0.00, real=0.52 secs] 
2025-12-10T14:11:59.268+0800: 25.210: [Heap Dump (before full gc): , 0.0000684 secs]2025-12-10T14:11:59.269+0800: 25.210: [Full GC (Ergonomics) [PSYoungGen: 65536K->0K(76288K)] [ParOldGen: 173351K->174276K(175104K)] 238887K->174276K(251392K), [Metaspace: 109096K->109096K(1148928K)], 0.3031080 secs] [Times: user=1.10 sys=0.01, real=0.30 secs] 
2025-12-10T14:11:59.710+0800: 25.651: [Heap Dump (before full gc): , 0.0000752 secs]2025-12-10T14:11:59.710+0800: 25.651: [Full GC (Ergonomics) [PSYoungGen: 65536K->0K(76288K)] [ParOldGen: 174276K->174980K(175104K)] 239812K->174980K(251392K), [Metaspace: 110351K->110351K(1148928K)], 0.3664816 secs] [Times: user=1.21 sys=0.00, real=0.37 secs]
// Full GC Running
2025-12-10T14:12:52.408+0800: 78.350: [Heap Dump (before full gc): , 0.0000535 secs]2025-12-10T14:12:52.409+0800: 78.350: [Full GC (Ergonomics) [PSYoungGen: 65536K->64255K(76288K)] [ParOldGen: 174893K->174893K(175104K)] 240429K->239149K(251392K), [Metaspace: 148330K->148330K(1183744K)], 0.2442300 secs] [Times: user=0.68 sys=0.00, real=0.25 secs] 
2025-12-10T14:12:52.656+0800: 78.598: [Heap Dump (before full gc): , 0.0000711 secs]2025-12-10T14:12:52.657+0800: 78.598: [Full GC (Ergonomics) [PSYoungGen: 65536K->64333K(76288K)] [ParOldGen: 174893K->174893K(175104K)] 240429K->239227K(251392K), [Metaspace: 148379K->148379K(1183744K)], 0.2102640 secs] [Times: user=0.53 sys=0.02, real=0.21 secs] 
2025-12-10T14:12:52.871+0800: 78.813: [Heap Dump (before full gc): , 0.0000622 secs]2025-12-10T14:12:52.872+0800: 78.813: [Full GC (Ergonomics) [PSYoungGen: 65534K->64252K(76288K)] [ParOldGen: 174893K->174893K(175104K)] 240428K->239146K(251392K), [Metaspace: 148488K->148488K(1183744K)], 0.2125166 secs] [Times: user=0.54 sys=0.00, real=0.22 secs]  
// Full GC Ending
2025-12-10T14:32:47.691+0800: 1273.632: [Heap Dump (before full gc): , 0.0000943 secs]2025-12-10T14:32:47.691+0800: 1273.633: [Full GC (Ergonomics) [PSYoungGen: 65536K->24273K(76288K)] [ParOldGen: 174627K->174626K(175104K)] 240163K->198899K(251392K), [Metaspace: 152567K->152567K(1187840K)], 0.3627505 secs] [Times: user=1.12 sys=0.00, real=0.37 secs] 
2025-12-10T14:35:18.172+0800: 1424.113: [Heap Dump (before full gc): , 0.0001014 secs]2025-12-10T14:35:18.172+0800: 1424.114: [Full GC (Ergonomics) [PSYoungGen: 65536K->9012K(76288K)] [ParOldGen: 174626K->174852K(175104K)] 240162K->183865K(251392K), [Metaspace: 152611K->152611K(1187840K)], 0.2574051 secs] [Times: user=0.63 sys=0.00, real=0.26 secs] 
2025-12-10T14:38:49.044+0800: 1634.986: [Heap Dump (before full gc): , 0.0001049 secs]2025-12-10T14:38:49.045+0800: 1634.987: [Full GC (Ergonomics) [PSYoungGen: 65536K->0K(76288K)] [ParOldGen: 174852K->133113K(175104K)] 240388K->133113K(251392K), [Metaspace: 152680K->152680K(1187840K)], 0.3655573 secs] [Times: user=1.01 sys=0.00, real=0.36 secs] 
2025-12-10T14:42:49.842+0800: 1875.784: [GC (Allocation Failure) AdaptiveSizePolicy::update_averages:  survived: 1671680  promoted: 0  overflow: false

If you need other details just let me know, thx!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2619293977

From stefank at openjdk.org  Mon Dec 15 12:59:49 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 15 Dec 2025 12:59:49 GMT
Subject: RFR: 8373599: Cleanup arguments.hpp includes [v2]
In-Reply-To: <Kqz_5CO6d3_qHfiP4oBX9R8-w4XhLgf41eFGcBPABRM=.64ef1a0f-20b2-4adb-ba32-4b96b5310319@github.com>
References: <Qk3QT6NyM0BgtE_qbj_s8LrSR8bTloYqu8ojT51cgEs=.f60dd6b4-e844-4b46-82a3-69efafe0206d@github.com>
 <Kqz_5CO6d3_qHfiP4oBX9R8-w4XhLgf41eFGcBPABRM=.64ef1a0f-20b2-4adb-ba32-4b96b5310319@github.com>
Message-ID: <ClL3tCWnBdclAyroSkgJxMgttuxM5oIcd7kUaRYXctI=.7fd6932a-386e-4806-9edd-d5315a654916@github.com>

On Fri, 12 Dec 2025 15:06:39 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> In the Valhalla project we are considering using a property in Arguments to figure out if Valhalla is enabled. To minimize transitive-include-proliferation if this property ever needs to be checked in a header I propose that we clean up the header includes in arguments.hpp.
>> 
>> I'm opening the review for this so that I can get opinions on the move of functions. I'm going to compile this on all our platforms and will likely add a few more includes when unrelated files fail to compile because they relied on the includes provided through by java.hpp and arguments.hpp.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Sort order

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28791#issuecomment-3655489435

From stefank at openjdk.org  Mon Dec 15 12:59:50 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 15 Dec 2025 12:59:50 GMT
Subject: Integrated: 8373599: Cleanup arguments.hpp includes
In-Reply-To: <Qk3QT6NyM0BgtE_qbj_s8LrSR8bTloYqu8ojT51cgEs=.f60dd6b4-e844-4b46-82a3-69efafe0206d@github.com>
References: <Qk3QT6NyM0BgtE_qbj_s8LrSR8bTloYqu8ojT51cgEs=.f60dd6b4-e844-4b46-82a3-69efafe0206d@github.com>
Message-ID: <-q29cL7Uz0tjXshcWPOy3cNZJ2skyipTCLdo_5Xt-z0=.71ac3175-d5bb-4442-853d-6f7beef78b09@github.com>

On Fri, 12 Dec 2025 14:11:55 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> In the Valhalla project we are considering using a property in Arguments to figure out if Valhalla is enabled. To minimize transitive-include-proliferation if this property ever needs to be checked in a header I propose that we clean up the header includes in arguments.hpp.
> 
> I'm opening the review for this so that I can get opinions on the move of functions. I'm going to compile this on all our platforms and will likely add a few more includes when unrelated files fail to compile because they relied on the includes provided through by java.hpp and arguments.hpp.

This pull request has now been integrated.

Changeset: f5187ebf
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f5187ebf7a4d4241f01612b62c514a1e4e272658
Stats:     67 lines in 7 files changed: 37 ins; 19 del; 11 mod

8373599: Cleanup arguments.hpp includes

Reviewed-by: coleenp, kbarrett

-------------

PR: https://git.openjdk.org/jdk/pull/28791

From aboldtch at openjdk.org  Mon Dec 15 13:22:55 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 15 Dec 2025 13:22:55 GMT
Subject: RFR: 8373668: Add override keyword to *Klass classes [v2]
In-Reply-To: <rJP1-555XexBIvK3yH_SdGiAEJjT38wEqZmslbynvOg=.1205594c-d2f0-40a1-9000-a7a6707a7d84@github.com>
References: <rJP1-555XexBIvK3yH_SdGiAEJjT38wEqZmslbynvOg=.1205594c-d2f0-40a1-9000-a7a6707a7d84@github.com>
Message-ID: <f-PTSiuHzVJQBdypXVtsxUVt07Y58v-UsjRPt_gkhFM=.28f2ddae-a8f5-496e-9a55-5a7116b801a2@github.com>

> Using override provides better visibility and compiler support for suspicious virtual methods. It makes it clears when reading a class header file if a new virtual interface is introduced or if it simply overridden.
> 
> Testing
>  * GHA
>  * Running tier1 on Oracle supported platforms

Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:

  Whitespace changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28820/files
  - new: https://git.openjdk.org/jdk/pull/28820/files/00859dbd..3b4009c8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28820&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28820&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/28820.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28820/head:pull/28820

PR: https://git.openjdk.org/jdk/pull/28820

From aboldtch at openjdk.org  Mon Dec 15 13:27:13 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 15 Dec 2025 13:27:13 GMT
Subject: RFR: 8373668: Add override keyword to *Klass classes [v2]
In-Reply-To: <ZwqwzA-EjLR6VpQxQSCXAbqJ9u7kaKHtqwJmMrhN0iY=.6bb9ec68-a294-40e0-abc4-5b0158d69c3f@github.com>
References: <rJP1-555XexBIvK3yH_SdGiAEJjT38wEqZmslbynvOg=.1205594c-d2f0-40a1-9000-a7a6707a7d84@github.com>
 <ZwqwzA-EjLR6VpQxQSCXAbqJ9u7kaKHtqwJmMrhN0iY=.6bb9ec68-a294-40e0-abc4-5b0158d69c3f@github.com>
Message-ID: <UWxTXdxxgCSv-vEa229AcWHnxhhEYxzBGT8kUhMLVY8=.a44c9897-0b15-4e51-82cc-7b14febbbca8@github.com>

On Mon, 15 Dec 2025 11:41:55 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> I wonder if there would be any measurable benefit to using `final` instead in some
> cases? But that should be looked at separately. It might be simpler to declare some
> classes to be `final`.

I know that I experimented with this at some point for the oop iterator. The result then was that it was not a reliable way to guarantee de-virtualisation. I also remember reading some blog post somewhere which explored different compilers and the benefits of final. I think it ultimately was not reliable enough to replace doing hand rolling things for where it matters, but got some improvements in some cases. However this was a few years ago so things might have improved. 

Regardless of performance improvements, I think the final keyword makes the intended inheritance more clear and would be a worthwhile future RFE.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28820#issuecomment-3655629666

From aph at openjdk.org  Mon Dec 15 13:44:31 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 15 Dec 2025 13:44:31 GMT
Subject: RFR: 8372701: Randomized profile counters [v2]
In-Reply-To: <ccf5KPazc5XBzD5VrpjF-W1BSHUNvPED5I5Ovt3eCEA=.345e48ae-eb4c-4659-a6ac-306c14877bf7@github.com>
References: <jKjmIONZcytzVjS4absOwOLv_QOF9qhIJifYhN6JyP4=.dceced94-bc29-43e6-9062-8dc77c2a6133@github.com>
 <YAdyTG2jqY3OcJ7M4mD0CkL56a0p6ciaHYM-ow9Ham8=.0cb57295-acde-4e49-984b-b8756ed99850@github.com>
 <r-mcwZnhCQvaRfSM8aZzIcyAV8gdtPqOWdwnswW35uc=.c5c0ac59-4032-4a1a-9d13-d428e41b85aa@github.com>
 <prP0CBmI0Fxwu28rapv9RhTFY4JROMmWhSHWFSlNDEA=.a13961ad-a0f6-4ac0-948d-e9fd217b17ea@github.com>
 <ccf5KPazc5XBzD5VrpjF-W1BSHUNvPED5I5Ovt3eCEA=.345e48ae-eb4c-4659-a6ac-306c14877bf7@github.com>
Message-ID: <PZJpDpkPaS1XwC5z36yuxnWiVXf02HUWgV0KpthO8Uc=.6fdcafdf-c27b-49fe-b9d3-ae2c3b31d871@github.com>

On Mon, 15 Dec 2025 11:13:27 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> To your example: indeed, there is no recourse in case when really-polymorphic site is accidentally looking monomorphic due to code behavior artifacts: e.g. no one came with rare type just yet. But IMO that does not mean we would be opening more performance trap-doors when some code _did_ come with the rare type, especially if it is easy to handle.

Thanks for this input, it helps a lot.

How cheap it is always to update type profile counters depends on how many threads are racily updating them. But it's easy to move type-profiling code from behind the random step to in front of it, so I'll make that change.

> The fact that some of your horses might have bolted, does not give you a good reason to open the barn door a bit wider

Agree totally in principle, but that analogy only works if the cost of closing the door is near-zero. It may well be so, we'll see.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28541#issuecomment-3655712779

From jwaters at openjdk.org  Mon Dec 15 14:40:46 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 15 Dec 2025 14:40:46 GMT
Subject: RFR: 8373668: Add override keyword to *Klass classes [v2]
In-Reply-To: <f-PTSiuHzVJQBdypXVtsxUVt07Y58v-UsjRPt_gkhFM=.28f2ddae-a8f5-496e-9a55-5a7116b801a2@github.com>
References: <rJP1-555XexBIvK3yH_SdGiAEJjT38wEqZmslbynvOg=.1205594c-d2f0-40a1-9000-a7a6707a7d84@github.com>
 <f-PTSiuHzVJQBdypXVtsxUVt07Y58v-UsjRPt_gkhFM=.28f2ddae-a8f5-496e-9a55-5a7116b801a2@github.com>
Message-ID: <YJZOLVJXNQS2ILqoLPtOb72AaCUX6v_1PXKzKPqdy6A=.86635be7-38ad-400e-b804-7d8801bea818@github.com>

On Mon, 15 Dec 2025 13:22:55 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Using override provides better visibility and compiler support for suspicious virtual methods. It makes it clears when reading a class header file if a new virtual interface is introduced or if it simply overridden.
>> 
>> Testing
>>  * GHA
>>  * Running tier1 on Oracle supported platforms
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Whitespace changes

+1 for use of helpful C++ features!

-------------

Marked as reviewed by jwaters (Committer).

PR Review: https://git.openjdk.org/jdk/pull/28820#pullrequestreview-3578544271

From mbaesken at openjdk.org  Mon Dec 15 14:59:46 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 15 Dec 2025 14:59:46 GMT
Subject: RFR: 8372348: Adjust some UL / JFR string deduplication output
 messages [v2]
In-Reply-To: <7-XRp229KFw3V2bFPMnaWaoPdF3ZCYVNuViEo2O7eUI=.e0247347-188b-44bf-935c-6b0186026fd3@github.com>
References: <7-XRp229KFw3V2bFPMnaWaoPdF3ZCYVNuViEo2O7eUI=.e0247347-188b-44bf-935c-6b0186026fd3@github.com>
Message-ID: <0SYxg-Sftdzpna9ftRjMfLGNf2D5JztmR8G5kdjPWnU=.6cd25f16-31f2-4658-86ed-3fe2216dc20d@github.com>

> There is some UL output in the string deduplication code that is not very clear and has room for improvement.
> The inspected strings number should be shown and the new unknown strings get a changed text.
> (also the new JFR strip dedup event  description is slightly adjusted)

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Enhance output

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28455/files
  - new: https://git.openjdk.org/jdk/pull/28455/files/667f80d5..ba0e3410

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28455&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28455&range=00-01

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28455.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28455/head:pull/28455

PR: https://git.openjdk.org/jdk/pull/28455

From mbaesken at openjdk.org  Mon Dec 15 14:59:47 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 15 Dec 2025 14:59:47 GMT
Subject: RFR: 8372348: Adjust some UL / JFR string deduplication output
 messages [v2]
In-Reply-To: <FusqPTtOicwQ5QdQr8M2FJmblmUH46F-Rbsh6HBXi8w=.7d5a54eb-cfab-4c6a-8e26-1ab9535e6427@github.com>
References: <7-XRp229KFw3V2bFPMnaWaoPdF3ZCYVNuViEo2O7eUI=.e0247347-188b-44bf-935c-6b0186026fd3@github.com>
 <2r6k6Av9MTNmMxpbga6MJoUCu0vECsr7IDL6wAzJ_Ig=.c9106917-1635-4d3c-b6c4-f4c5f0659440@github.com>
 <kLaKX3lyoQshzjHXilycyq9_ixhaiQMy76zmavAX35M=.682f43b9-e72f-48ed-90a5-fcb84b3d3c90@github.com>
 <Ien8WqqsVLY--khvk8WkOeaSpaAKWcQ45x_5tCxQZTI=.f0f9bb58-ef10-4c78-8746-49f5a7bfa803@github.com>
 <pNpdqbYFfgvrIkYZRCFEldiccxVqyq1vQB3hxnIs1Nk=.b7f28843-7e09-477f-9a0f-63bb3314b9f8@github.com>
 <FusqPTtOicwQ5QdQr8M2FJmblmUH46F-Rbsh6HBXi8w=.7d5a54eb-cfab-4c6a-8e26-1ab9535e6427@github.com>
Message-ID: <_pD8_vv2_v0M9KlqfxLhv0QT8Qynd0w1OFfpICgS7k8=.106bc0d3-810b-470e-954b-26d1f603ffcb@github.com>

On Thu, 11 Dec 2025 14:21:28 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Adding total will be helpful already, but why are not the numbers printed on which the avg is based? Because otherwise you don't get an impression what the percentage mean.
>
> ` total avg of  deduped / new unknown bytes ` maybe ? That mentions what is used for the computation .
> We could also print the values of  total deduped and new to make it more clear .

> Adding total will be helpful already, but why are not the numbers printed on which the avg is based? Because otherwise you don't get an impression what the percentage mean.

I added some more output, please check .

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28455#discussion_r2619767089

From roland at openjdk.org  Mon Dec 15 15:19:17 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Mon, 15 Dec 2025 15:19:17 GMT
Subject: RFR: 8351889: C2 crash: assertion failed:  Base pointers must
 match (addp 344) [v7]
In-Reply-To: <IayFdH9iFOuvlJCeK4g9SsaDauFCKsE2vO4xbaQppzs=.c71d6102-856a-408e-a485-97eecd06f1ca@github.com>
References: <IKOYjLXrS8q1GMjbaL2HOBNH8Oa_16k4WBa2NaMngS8=.c6fd7fbb-4758-48b2-a992-3702b2718e59@github.com>
 <z8XnCZyLzTrAh8AT9e4OMkusEtjOCLOOJlBMDJyzGfI=.86ef7f0f-ac23-4d18-8b7b-7513c8808da8@github.com>
 <IayFdH9iFOuvlJCeK4g9SsaDauFCKsE2vO4xbaQppzs=.c71d6102-856a-408e-a485-97eecd06f1ca@github.com>
Message-ID: <BvvqOdGEqslEz8pm65xddNfS4CDhwApUREarSo0C3NY=.89b8f72a-b586-44df-87b3-a3e220964ad5@github.com>

On Fri, 12 Dec 2025 15:37:58 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 19 additional commits since the last revision:
>> 
>>  - review
>>  - Merge branch 'master' into JDK-8351889
>>  - Update src/hotspot/share/opto/phaseX.hpp
>>    
>>    Co-authored-by: Roberto Casta?eda Lozano <robcasloz at users.noreply.github.com>
>>  - Update src/hotspot/share/opto/phaseX.cpp
>>    
>>    Co-authored-by: Roberto Casta?eda Lozano <robcasloz at users.noreply.github.com>
>>  - review
>>  - more
>>  - review
>>  - Merge branch 'master' into JDK-8351889
>>  - exp
>>  - Merge branch 'master' into JDK-8351889
>>  - ... and 9 more: https://git.openjdk.org/jdk/compare/3c66d85f...100fad3d
>
> Looks good!

@robcasloz thanks for the review. Does testing look ok?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25386#issuecomment-3656200397

From roland at openjdk.org  Mon Dec 15 15:25:44 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Mon, 15 Dec 2025 15:25:44 GMT
Subject: RFR: 8373591: C2: Fix the memory around some intrinsics nodes [v2]
In-Reply-To: <rQxzIkDfE_4ZTcQxuBwMk9k3FOesl_86dmXYi33kkDE=.f393b683-4b62-4af5-98e8-307ab7b0ab6f@github.com>
References: <xqPVnw7PtK7ch97NBoScQARyosgTZhsq8Jypd6h2Cyg=.61115100-f6f0-4f16-a01c-33e587b3ecaf@github.com>
 <BawKNUAtVMK3lI3blP9RaOG9A1cxm84iZhNKFYaPDOg=.dcd8f6bb-d137-4462-ad1a-816b4e94adba@github.com>
 <rQxzIkDfE_4ZTcQxuBwMk9k3FOesl_86dmXYi33kkDE=.f393b683-4b62-4af5-98e8-307ab7b0ab6f@github.com>
Message-ID: <YLCFqfSysXHB3bnJgSlR_70DqeVSJ7M0vleWtDeoSKg=.895b38ca-0dc5-469f-ac86-d4d7885bf32a@github.com>

On Fri, 12 Dec 2025 14:47:34 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> src/hotspot/share/opto/graphKit.cpp line 4191:
>> 
>>> 4189:   Node* res_mem = _gvn.transform(new SCMemProjNode(_gvn.transform(str)));
>>> 4190:   if (adr_type == TypePtr::BOTTOM) {
>>> 4191:     set_all_memory(res_mem);
>> 
>> I'm confused by this. Doesn't `StrCompressedCopyNode` only write to dst? So the only part of the memory state that it updates is the one for `TypeAryPtr::BYTES`?
>
> It is because if a node consumes more memory than it produces, we need to compute its anti-dependencies. And since we do not compute anti-dependencies of these nodes, it is safer to make them kill all the memory they consume. What do you think?

Could this be fixed by appending a `MemBarCPUOrderNode` on the slice of src?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28789#discussion_r2619864649

From rrich at openjdk.org  Mon Dec 15 15:54:29 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 15 Dec 2025 15:54:29 GMT
Subject: RFR: 8369515: Deadlock between JVMTI and JNI
 ReleasePrimitiveArrayCritical
In-Reply-To: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
References: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
Message-ID: <HNIuDe5WE7Q2TcLEypSmjKG0aEH2H3GtnLSCGYWdzlQ=.3f0582a5-5184-4416-8d0e-c61139541c33@github.com>

On Fri, 12 Dec 2025 04:20:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

> As discussed in JBS the deadlock occurs when the call to `ReleasePrimitiveArrayCritical` performs the transition from native to VM, and in the process checks for special runtime exit conditions - which includes the `obj_deopt_suspend` request. The simple solution is to define a custom JNI ENTRY with custom `ThreadInVMfromNative` that elides the exit check.
> 
> The change is limited to `ReleasePrimitiveArrayCritical` and `ReleaseStringCritical`.
> 
> There is no regression test as this has only been seen in long running stress tests.
> 
> Testing:
>    -tiers 1-6

@dholmes-ora I do think that also _entering_ a critical region is problematic if it is nested.
I'm currently testing with https://github.com/reinrich/jdk/commit/d7ce2ccb2150c92929b8d9140b4709833d188474 where a thread doesn't suspend for EscapeBarriers while in a critical region.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28779#issuecomment-3656372702

From aph at openjdk.org  Mon Dec 15 15:54:35 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 15 Dec 2025 15:54:35 GMT
Subject: RFR: 8372701: Randomized profile counters [v5]
In-Reply-To: <BxQvwFp-zorwxRiwNksDT0Bp-PmKZuxbXnc4nHaXH8Y=.db07c559-4d8c-41e9-a2a3-e8b68b7e1a29@github.com>
References: <jKjmIONZcytzVjS4absOwOLv_QOF9qhIJifYhN6JyP4=.dceced94-bc29-43e6-9062-8dc77c2a6133@github.com>
 <1nJnov3s2hhiLuO0W2FNcSAiGu5eEjZauQxfzd5YXKw=.8c593111-294a-4df7-8ce0-322871a801f3@github.com>
 <BxQvwFp-zorwxRiwNksDT0Bp-PmKZuxbXnc4nHaXH8Y=.db07c559-4d8c-41e9-a2a3-e8b68b7e1a29@github.com>
Message-ID: <3esDvJBbg-YIuvQm_Kh0CEtu3p9o9QrJr5ir0KUIoZI=.7fd51056-4744-45a7-8b85-0b3d17f4ab77@github.com>

On Thu, 11 Dec 2025 14:57:34 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Thanks. Correctness testing is all clean on our side, I submitted benchmarks and will report back once it finished.

Can you please run benchmarks with `-XX:+UnlockExperimentalVMOptions -XX:ProfileCaptureRatio=64`? Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28541#issuecomment-3656361764

From aph at openjdk.org  Mon Dec 15 15:54:38 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 15 Dec 2025 15:54:38 GMT
Subject: RFR: 8372701: Randomized profile counters [v2]
In-Reply-To: <PZJpDpkPaS1XwC5z36yuxnWiVXf02HUWgV0KpthO8Uc=.6fdcafdf-c27b-49fe-b9d3-ae2c3b31d871@github.com>
References: <jKjmIONZcytzVjS4absOwOLv_QOF9qhIJifYhN6JyP4=.dceced94-bc29-43e6-9062-8dc77c2a6133@github.com>
 <YAdyTG2jqY3OcJ7M4mD0CkL56a0p6ciaHYM-ow9Ham8=.0cb57295-acde-4e49-984b-b8756ed99850@github.com>
 <r-mcwZnhCQvaRfSM8aZzIcyAV8gdtPqOWdwnswW35uc=.c5c0ac59-4032-4a1a-9d13-d428e41b85aa@github.com>
 <prP0CBmI0Fxwu28rapv9RhTFY4JROMmWhSHWFSlNDEA=.a13961ad-a0f6-4ac0-948d-e9fd217b17ea@github.com>
 <ccf5KPazc5XBzD5VrpjF-W1BSHUNvPED5I5Ovt3eCEA=.345e48ae-eb4c-4659-a6ac-306c14877bf7@github.com>
 <PZJpDpkPaS1XwC5z36yuxnWiVXf02HUWgV0KpthO8Uc=.6fdcafdf-c27b-49fe-b9d3-ae2c3b31d871@github.com>
Message-ID: <Gl2QTfhJ9Xz06VgMKC4P0LNquf_0liD4pbqOPoCWVUc=.1aa47aa4-be51-45bc-b223-7e003b5235c8@github.com>

On Mon, 15 Dec 2025 13:41:10 GMT, Andrew Haley <aph at openjdk.org> wrote:

> How cheap it is always to update type profile counters depends on how many threads are racily updating them.

Sorry, my brain fart. We only need to _read_ the classes before the random step, so there is no scaling problem.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28541#issuecomment-3656371444

From shade at openjdk.org  Mon Dec 15 16:16:21 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 15 Dec 2025 16:16:21 GMT
Subject: RFR: 8372701: Randomized profile counters [v2]
In-Reply-To: <Gl2QTfhJ9Xz06VgMKC4P0LNquf_0liD4pbqOPoCWVUc=.1aa47aa4-be51-45bc-b223-7e003b5235c8@github.com>
References: <jKjmIONZcytzVjS4absOwOLv_QOF9qhIJifYhN6JyP4=.dceced94-bc29-43e6-9062-8dc77c2a6133@github.com>
 <YAdyTG2jqY3OcJ7M4mD0CkL56a0p6ciaHYM-ow9Ham8=.0cb57295-acde-4e49-984b-b8756ed99850@github.com>
 <r-mcwZnhCQvaRfSM8aZzIcyAV8gdtPqOWdwnswW35uc=.c5c0ac59-4032-4a1a-9d13-d428e41b85aa@github.com>
 <prP0CBmI0Fxwu28rapv9RhTFY4JROMmWhSHWFSlNDEA=.a13961ad-a0f6-4ac0-948d-e9fd217b17ea@github.com>
 <ccf5KPazc5XBzD5VrpjF-W1BSHUNvPED5I5Ovt3eCEA=.345e48ae-eb4c-4659-a6ac-306c14877bf7@github.com>
 <PZJpDpkPaS1XwC5z36yuxnWiVXf02HUWgV0KpthO8Uc=.6fdcafdf-c27b-49fe-b9d3-ae2c3b31d871@github.com>
 <Gl2QTfhJ9Xz06VgMKC4P0LNquf_0liD4pbqOPoCWVUc=.1aa47aa4-be51-45bc-b223-7e003b5235c8@github.com>
Message-ID: <0ZmeOFrD_Uviw6cyFkCu5_u2FKLDttYkcC8l6VVRIUs=.da1d30e8-c64b-4611-8254-2afa902be3a1@github.com>

On Mon, 15 Dec 2025 15:51:54 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > How cheap it is always to update type profile counters depends on how many threads are racily updating them.
> 
> Sorry, my brain fart. We only need to _read_ the classes before the random step, so there is no scaling problem.

Yes. And I hope after https://github.com/openjdk/jdk/pull/25305 you can really just specialize installation code a little: that code already knows whether it is about to install new receiver type in the table (so it can just write `1`), or it is an increment of known receiver (which can go RNG route). The poly counter would need some thinking about.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28541#issuecomment-3656471325

From rcastanedalo at openjdk.org  Mon Dec 15 16:21:11 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 15 Dec 2025 16:21:11 GMT
Subject: RFR: 8351889: C2 crash: assertion failed:  Base pointers must
 match (addp 344) [v7]
In-Reply-To: <BvvqOdGEqslEz8pm65xddNfS4CDhwApUREarSo0C3NY=.89b8f72a-b586-44df-87b3-a3e220964ad5@github.com>
References: <IKOYjLXrS8q1GMjbaL2HOBNH8Oa_16k4WBa2NaMngS8=.c6fd7fbb-4758-48b2-a992-3702b2718e59@github.com>
 <z8XnCZyLzTrAh8AT9e4OMkusEtjOCLOOJlBMDJyzGfI=.86ef7f0f-ac23-4d18-8b7b-7513c8808da8@github.com>
 <IayFdH9iFOuvlJCeK4g9SsaDauFCKsE2vO4xbaQppzs=.c71d6102-856a-408e-a485-97eecd06f1ca@github.com>
 <BvvqOdGEqslEz8pm65xddNfS4CDhwApUREarSo0C3NY=.89b8f72a-b586-44df-87b3-a3e220964ad5@github.com>
Message-ID: <ohBDpwCKN5OytzCnlNpUte2kdBeEw5plgQO0bq8zdEQ=.e872db12-fb74-4110-a86f-cd10ad63c628@github.com>

On Mon, 15 Dec 2025 15:16:20 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>  Does testing look ok?

Yes, test results look good.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25386#issuecomment-3656484496

From roland at openjdk.org  Mon Dec 15 16:21:11 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Mon, 15 Dec 2025 16:21:11 GMT
Subject: RFR: 8351889: C2 crash: assertion failed:  Base pointers must
 match (addp 344) [v7]
In-Reply-To: <ohBDpwCKN5OytzCnlNpUte2kdBeEw5plgQO0bq8zdEQ=.e872db12-fb74-4110-a86f-cd10ad63c628@github.com>
References: <IKOYjLXrS8q1GMjbaL2HOBNH8Oa_16k4WBa2NaMngS8=.c6fd7fbb-4758-48b2-a992-3702b2718e59@github.com>
 <z8XnCZyLzTrAh8AT9e4OMkusEtjOCLOOJlBMDJyzGfI=.86ef7f0f-ac23-4d18-8b7b-7513c8808da8@github.com>
 <IayFdH9iFOuvlJCeK4g9SsaDauFCKsE2vO4xbaQppzs=.c71d6102-856a-408e-a485-97eecd06f1ca@github.com>
 <BvvqOdGEqslEz8pm65xddNfS4CDhwApUREarSo0C3NY=.89b8f72a-b586-44df-87b3-a3e220964ad5@github.com>
 <ohBDpwCKN5OytzCnlNpUte2kdBeEw5plgQO0bq8zdEQ=.e872db12-fb74-4110-a86f-cd10ad63c628@github.com>
Message-ID: <JLF8Z8o0tfBfWEl2pnAI7EQigi2j_hewZjZYp6s301o=.504cacc5-fdef-4f98-bcf4-4fa565c89d19@github.com>

On Mon, 15 Dec 2025 16:15:49 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> @robcasloz thanks for the review. Does testing look ok?
>
>>  Does testing look ok?
> 
> Yes, test results look good.

@robcasloz @eme64 thanks for the reviews and testing

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25386#issuecomment-3656491847

From roland at openjdk.org  Mon Dec 15 16:21:13 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Mon, 15 Dec 2025 16:21:13 GMT
Subject: Integrated: 8351889: C2 crash: assertion failed: Base pointers must
 match (addp 344)
In-Reply-To: <IKOYjLXrS8q1GMjbaL2HOBNH8Oa_16k4WBa2NaMngS8=.c6fd7fbb-4758-48b2-a992-3702b2718e59@github.com>
References: <IKOYjLXrS8q1GMjbaL2HOBNH8Oa_16k4WBa2NaMngS8=.c6fd7fbb-4758-48b2-a992-3702b2718e59@github.com>
Message-ID: <6HPeY8lPjs_X0AA4EtTZhnt4OeVmp7-_WlY3FlSCGl0=.5b42364a-962c-4554-842d-ab50715ce990@github.com>

On Thu, 22 May 2025 08:35:18 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> The test case has an out of loop `Store` with an `AddP` address
> expression that has other uses and is in the loop body. Schematically,
> only showing the address subgraph and the bases for the `AddP`s:
> 
> 
> Store#195 -> AddP#133 -> AddP#134 -> CastPP#110
>                      -> CastPP#110
> 
> 
> Both `AddP`s have the same base, a `CastPP` that's also in the loop
> body.
> 
> That loop is a counted loop and only has 3 iterations so is fully
> unrolled. First, one iteration is peeled:
> 
> 
>                                 /-> CastPP#110
> Store#195 -> Phi#360 -> AddP#133 -> AddP#134 -> CastPP#110
>                     -> AddP#277 -> AddP#278 -> CastPP#283
>                                 -> CastPP#283
> 
> 
> 
> The `AddP`s and `CastPP` are cloned (because in the loop body). As
> part of peeling, `PhaseIdealLoop::peeled_dom_test_elim()` is
> called. It finds the test that guards `CastPP#283` in the peeled
> iteration dominates and replaces the test that guards `CastPP#110`
> (the test in the peeled iteration is the clone of the test in the
> loop). That causes `CastPP#110`'s control to be updated to that of the
> test in the peeled iteration and to be yanked from the loop. So now
> `CastPP#283` and `CastPP#110` have the same inputs.
> 
> Next unrolling happens:
> 
> 
>                                            /-> CastPP#110
>                                /-> AddP#400 -> AddP#401 -> CastPP#110
> Store#195 -> Phi#360 -> Phi#477 -> AddP#133 -> AddP#134 -> CastPP#110
>                   \                        -> CastPP#110
>                    -> AddP#277 -> AddP#278 -> CastPP#283
>                                -> CastPP#283
> 
> 
> 
> `AddP`s are cloned once more but not the `CastPP`s because they are
> both in the peeled iteration now. A new `Phi` is added.
> 
> Next igvn runs. It's going to push the `AddP`s through the `Phi`s.
> 
> Through `Phi#477`:
> 
> 
> 
>                                 /-> CastPP#110
> Store#195 -> Phi#360 -> AddP#510 -> Phi#509 -> AddP#401 -> CastPP#110
>                   \                        -> AddP#134 -> CastPP#110
>                    -> AddP#277 -> AddP#278 -> CastPP#283
>                                -> CastPP#283
> 
> 
> 
> Through `Phi#360`:
> 
> 
>                                            /-> AddP#134 -> CastPP#110
>                                 /-> Phi#509 -> AddP#401 -> CastPP#110
> Store#195 -> AddP#516 -> Phi#515 -> AddP#278 -> CastPP#283
>                      -> Phi#514 -> CastPP#283
>                                 -> CastP#110
> 
> 
> Then `Phi#514` which has 2 `CastPP`s as input with identical inputs is
> transformed into anot...

This pull request has now been integrated.

Changeset: ad29642d
Author:    Roland Westrelin <roland at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ad29642d8f4e8e0fb1223b14b85ab7841d7b1b51
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, epeter

-------------

PR: https://git.openjdk.org/jdk/pull/25386

From liach at openjdk.org  Mon Dec 15 17:10:24 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 15 Dec 2025 17:10:24 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v10]
In-Reply-To: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
Message-ID: <uSb1651TeOtyVJG6DpLQQnKF-suGwk6u8FLq65bCGoc=.4c5f81d2-11e4-4118-ac96-aab706e27c71@github.com>

> 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 20 additional commits since the last revision:

 - 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
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache
 - Revert void special case removal due to C2 shortage causing TestZGCBarrierElision::testAtomicThenAtomicAnotherField failure
 - Test from Jorn
 - ... and 10 more: https://git.openjdk.org/jdk/compare/f5945cc1...f9d808c1

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28585/files
  - new: https://git.openjdk.org/jdk/pull/28585/files/d734e8a6..f9d808c1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28585&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28585&range=08-09

  Stats: 19890 lines in 378 files changed: 12699 ins; 4700 del; 2491 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 jbhateja at openjdk.org  Mon Dec 15 17:27:12 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 15 Dec 2025 17:27:12 GMT
Subject: RFR: 8373480: Optimize multiplication by constant multiplier using LEA
 instructions
Message-ID: <uo_ugfdLTrURHDpmWF4Xfh2Hspum8XDJNYsUjhAEc1I=.131ef8cd-e2f3-4d8c-981c-a701452cb264@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.testConstMultiplierL  thrpt    2  283.578          ops/min


System: AMD EPYC 9B45 Turin:-
Baseline:-
Benchmark                                             Mode  Cnt    Score   Error    Units
ConstantMultiplierOptimization.testConstMultiplierI  thrpt    2  393.299          ops/min
ConstantMultiplierOptimization.testConstMultiplierL  thrpt    2  393.764          ops/min

Withopt:-
Benchmark                                             Mode  Cnt    Score   Error    Units
ConstantMultiplierOptimization.testConstMultiplierI  thrpt    2  409.790          ops/min
ConstantMultiplierOptimization.testConstMultiplierL  thrpt    2  409.756          ops/min



Effect of optimization is more pronounced on Intel server in comparison to AMD's,  As per Agner Fogs' instruction latency manual IMUL instruciton has resiprocal througput of 1 while Fast LEA has reciprocal througput of 0.25 on Zen4 and around 0.5 on Intel Sunnycove (Icelake), going by that we can executue more LEA in parallel in one cycle, it will need to be investigated seperately why we don't see similar gains on AMD target.

Kindly review and share your feedback.

Best Regards,
Jatin

-------------

Commit messages:
 - Adding IR framework tests
 - Adding benchmark
 - 8373480: Optimize constant input multiplication using LEA instructions

Changes: https://git.openjdk.org/jdk/pull/28759/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28759&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373480
  Stats: 535 lines in 8 files changed: 525 ins; 0 del; 10 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 liach at openjdk.org  Mon Dec 15 17:44:49 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 15 Dec 2025 17:44:49 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v11]
In-Reply-To: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
Message-ID: <4UBpAWbg2PlNeJ9-Wr4AvehrdVb8C8BYdoXfptvPI1o=.b92c5a06-6da9-4fe0-ab02-47c5a2126020@github.com>

> 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:

  Missed IR test review, rearrange benches

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28585/files
  - new: https://git.openjdk.org/jdk/pull/28585/files/f9d808c1..1d5461db

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28585&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28585&range=09-10

  Stats: 109 lines in 4 files changed: 89 ins; 11 del; 9 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 liach at openjdk.org  Mon Dec 15 17:44:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 15 Dec 2025 17:44:52 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v10]
In-Reply-To: <uSb1651TeOtyVJG6DpLQQnKF-suGwk6u8FLq65bCGoc=.4c5f81d2-11e4-4118-ac96-aab706e27c71@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <uSb1651TeOtyVJG6DpLQQnKF-suGwk6u8FLq65bCGoc=.4c5f81d2-11e4-4118-ac96-aab706e27c71@github.com>
Message-ID: <KCKLk6BlFlPZseapdDlcPQSRPKlChtBdhZoCIWKJjDY=.48c8570b-c05e-4a54-b811-44d42b92cd89@github.com>

On Mon, 15 Dec 2025 17:10:24 GMT, Chen Liang <liach at openjdk.org> 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 20 additional commits since the last revision:
> 
>  - 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
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache
>  - Revert void special case removal due to C2 shortage causing TestZGCBarrierElision::testAtomicThenAtomicAnotherField failure
>  - Test from Jorn
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/faea2335...f9d808c1

Since I just noticed the actual cause of the failure of caching is that AD is created per name+type combination, I have created a benchmark case for that instead of reusing the existing exact ones:


Benchmark                                 Mode  Cnt  Score   Error  Units
VarHandleTypeMismatch.exactInvocation     avgt   30  0.396 ? 0.009  ns/op
VarHandleTypeMismatch.genericInvocation   avgt   30  0.375 ? 0.009  ns/op
VarHandleTypeMismatch.pollutedInvocation  avgt   30  8.281 ? 0.222  ns/op

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28585#issuecomment-3656852491

From liach at openjdk.org  Mon Dec 15 17:44:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 15 Dec 2025 17:44:54 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v9]
In-Reply-To: <RCay8vN8lKss9VF4kH0GiyQVeTn7LeUap2K8zq7zK-M=.88e751ba-ae5f-4736-a418-0824936de8db@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <4YumBpbA2k8DC13H1s808_5OJx-1FMxD9CbIUfRTb8Q=.742f90c9-0d93-43b7-abe7-76422a0c8359@github.com>
 <dz1Gx2KnQQHRvxsEaMeX6y3q7peELc4vg3QJlPbWqdc=.83c80c74-b468-4ad5-b142-db08a588a74e@github.com>
 <jWUg1PcHY-3f02g350EMzhd6fYEp-4SxVcw51oRrs9s=.3fcc1b25-1086-42a8-876b-fa991840e247@github.com>
 <RCay8vN8lKss9VF4kH0GiyQVeTn7LeUap2K8zq7zK-M=.88e751ba-ae5f-4736-a418-0824936de8db@github.com>
Message-ID: <KFQe02Mv675jElyRifIZZTqXgo-YQks0IbGvmTtzHXU=.89ec6015-2416-456c-8287-1641579e4ab8@github.com>

On Wed, 10 Dec 2025 22:13:23 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> I think that is when two different VarHandles are both invoked non-exactly in two call sites in one method, the 2nd one fails to be inlined, that the compare-and-exchange from the 2nd one is not present in the final IR. The deoptimization reason is either "unstable-if" or "too many null checks", I think I will try look into it in another effort.
>
> If it's a test problem, then it's better to comment out the problematic test case instead.

I have diagnosed the reason, updated the comments, and added a benchmark to showcase this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2620294345

From pchilanomate at openjdk.org  Mon Dec 15 18:29:26 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 15 Dec 2025 18:29:26 GMT
Subject: RFR: 8372591: assert(!current->cont_fastpath() ||
 freeze.check_valid_fast_path()) failed
Message-ID: <6yaYr_fSazq20-3lshGS-_Lr-LqXMt4lTeaFzDs9U2U=.c865efd1-9b98-4fce-98dd-4e1fe50a45be@github.com>

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/ad29642d8f4e8e0fb1223b14
 b85ab7841d7b1b51/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

-------------

Commit messages:
 - v1

Changes: https://git.openjdk.org/jdk/pull/28830/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28830&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/28830.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28830/head:pull/28830

PR: https://git.openjdk.org/jdk/pull/28830

From aph at openjdk.org  Mon Dec 15 18:49:26 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 15 Dec 2025 18:49:26 GMT
Subject: RFR: 8372701: Randomized profile counters [v5]
In-Reply-To: <1nJnov3s2hhiLuO0W2FNcSAiGu5eEjZauQxfzd5YXKw=.8c593111-294a-4df7-8ce0-322871a801f3@github.com>
References: <jKjmIONZcytzVjS4absOwOLv_QOF9qhIJifYhN6JyP4=.dceced94-bc29-43e6-9062-8dc77c2a6133@github.com>
 <1nJnov3s2hhiLuO0W2FNcSAiGu5eEjZauQxfzd5YXKw=.8c593111-294a-4df7-8ce0-322871a801f3@github.com>
Message-ID: <QkEo7ytyGNKsig_FQcU68tuo3HHlHiaJPsPwaFCrE48=.34b31057-6bc3-4e6a-a621-3503c24c5050@github.com>

On Tue, 9 Dec 2025 17:09:43 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> 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 with a new target base due to a merge or a rebase. The pull request now contains 58 commits:
> 
>  - Merge from master branch
>  - Merge remote-tracking branch 'refs/remotes/origin/JDK-8134940' into JDK-8134940
>  - Fix x86 lambda
>  - More
>  - Merge branch 'master' into JDK-8134940
>  - Merge branch 'master' into JDK-8134940
>  - Merge remote-tracking branch 'refs/remotes/origin/JDK-8134940' into JDK-8134940
>  - whitespace
>  - AArch64
>  - Minimize deltas to master
>  - ... and 48 more: https://git.openjdk.org/jdk/compare/7da91533...96db42e2

> Yes. And I hope after #25305 you can really just specialize installation code a little: that code already knows whether it is about to install new receiver type in the table (so it can just write `1`), or it is an increment of known receiver (which can go RNG route). The poly counter would need some thinking about.

Sure, I'm excited to do that. Please merge as soon as you can. Do you intend to do the same for AArch64? I volunteer, if you like.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28541#issuecomment-3657089677

From shade at openjdk.org  Mon Dec 15 18:54:10 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 15 Dec 2025 18:54:10 GMT
Subject: RFR: 8372701: Randomized profile counters [v5]
In-Reply-To: <QkEo7ytyGNKsig_FQcU68tuo3HHlHiaJPsPwaFCrE48=.34b31057-6bc3-4e6a-a621-3503c24c5050@github.com>
References: <jKjmIONZcytzVjS4absOwOLv_QOF9qhIJifYhN6JyP4=.dceced94-bc29-43e6-9062-8dc77c2a6133@github.com>
 <1nJnov3s2hhiLuO0W2FNcSAiGu5eEjZauQxfzd5YXKw=.8c593111-294a-4df7-8ce0-322871a801f3@github.com>
 <QkEo7ytyGNKsig_FQcU68tuo3HHlHiaJPsPwaFCrE48=.34b31057-6bc3-4e6a-a621-3503c24c5050@github.com>
Message-ID: <g1KuqOGCJFui09o74-uK7gPbFuoGDpUzdWXwltcBijA=.201adaaf-8a32-4906-81cf-be68279236c4@github.com>

On Mon, 15 Dec 2025 18:46:50 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Sure, I'm excited to do that. Please merge as soon as you can. Do you intend to do the same for AArch64? I volunteer, if you like.

I really wanted to avoid breaking mainline before going on NY break :) I also wanted to task someone from our new cohort of OpenJDK engineers to put AArch64 version together in January. Meanwhile, feel free to just mix up that PR here, if you want to hack on it?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28541#issuecomment-3657105174

From liach at openjdk.org  Mon Dec 15 19:49:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 15 Dec 2025 19:49:52 GMT
Subject: RFR: 8372845: C2: Fold identity hash code if object is constant
 [v4]
In-Reply-To: <KPNLohuiE3Os64ib8cPl8cyPUbmvzOF2y687qapKSgc=.cae21b9f-2fa9-4e78-a5ef-7912cf906dfa@github.com>
References: <KPNLohuiE3Os64ib8cPl8cyPUbmvzOF2y687qapKSgc=.cae21b9f-2fa9-4e78-a5ef-7912cf906dfa@github.com>
Message-ID: <UjiK2tzVFPBS7-BCTt5cprbISPM9MvxCEtrvkooc0Wc=.7665d634-e648-49a6-ba6c-1ef85ee5377f@github.com>

> 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/9543b2fa...67a3954f

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28589/files
  - new: https://git.openjdk.org/jdk/pull/28589/files/b1d8be39..67a3954f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28589&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28589&range=02-03

  Stats: 44910 lines in 756 files changed: 29623 ins; 11706 del; 3581 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 Dec 15 19:49:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 15 Dec 2025 19:49:54 GMT
Subject: RFR: 8372845: C2: Fold identity hash code if object is constant
 [v3]
In-Reply-To: <Zm0KHLF0N7z6zTCb0VWWkamGx2qf4oVN1r_fYa_vVjw=.d9c2b07b-0a3f-43f0-b65e-29dc924ea6f4@github.com>
References: <KPNLohuiE3Os64ib8cPl8cyPUbmvzOF2y687qapKSgc=.cae21b9f-2fa9-4e78-a5ef-7912cf906dfa@github.com>
 <AqXlBQi24MmML3tltUJiZa0bEYzORazv9mVo41lrIP4=.13265855-6308-47d1-93f0-006bfe06fdfa@github.com>
 <cavp_9ZUlDCfuwg9Eyp8wDms7j5GOtSZPwYk-QYMbVI=.bfed4082-375e-4a52-a2a1-4071843b7550@github.com>
 <XpDpc28hjOioKUPvgyyCXCVkZLVeHL7GGmoEW5--1UE=.809ce0b3-8992-4f55-98a8-8834401597a5@github.com>
 <6ip4JrJ4WiYEe6d2FA_WQ5dDjxAk2RPaPbwth4jNeJM=.43d7879d-89a4-434c-80ea-371c92581686@github.com>
 <r2gvtXpF9spuh0PGFRWFuKhgKSInOJ8UbZ2rWTNzLB8=.5f60583a-ee90-40b8-8826-8893fa7b8372@github.com>
 <0b81mH1_Y6r905N2HmehXBbSFdzLpJIfuXHNfijpHBs=.c870b13e-a52f-4c00-b771-91cf9205cb4a@github.com>
 <Zm0KHLF0N7z6zTCb0VWWkamGx2qf4oVN1r_fYa_vVjw=.d9c2b07b-0a3f-43f0-b65e-29dc924ea6f4@github.com>
Message-ID: <KJCVn-I684j2nJux2FymhdEN-3Eu-z4eEsM3SHVEjyg=.97effc1a-980b-4cfb-8fda-8bc94f5c73b2@github.com>

On Sat, 13 Dec 2025 00:57:52 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> You can always do more than just C2 IR verification. For example, we could also do result verification. That would give us coverage for C1 for example. I think it is just good practice not to have a restriction if it is not absolutely necessary.
>
> 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.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2620621537

From liach at openjdk.org  Mon Dec 15 19:49:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 15 Dec 2025 19:49:55 GMT
Subject: RFR: 8372845: C2: Fold identity hash code if object is constant
 [v3]
In-Reply-To: <6ip4JrJ4WiYEe6d2FA_WQ5dDjxAk2RPaPbwth4jNeJM=.43d7879d-89a4-434c-80ea-371c92581686@github.com>
References: <KPNLohuiE3Os64ib8cPl8cyPUbmvzOF2y687qapKSgc=.cae21b9f-2fa9-4e78-a5ef-7912cf906dfa@github.com>
 <AqXlBQi24MmML3tltUJiZa0bEYzORazv9mVo41lrIP4=.13265855-6308-47d1-93f0-006bfe06fdfa@github.com>
 <cavp_9ZUlDCfuwg9Eyp8wDms7j5GOtSZPwYk-QYMbVI=.bfed4082-375e-4a52-a2a1-4071843b7550@github.com>
 <XpDpc28hjOioKUPvgyyCXCVkZLVeHL7GGmoEW5--1UE=.809ce0b3-8992-4f55-98a8-8834401597a5@github.com>
 <6ip4JrJ4WiYEe6d2FA_WQ5dDjxAk2RPaPbwth4jNeJM=.43d7879d-89a4-434c-80ea-371c92581686@github.com>
Message-ID: <7oLQjFLs3t_6kGwXXUNec_Kyvbm-CDu-qX7if_UDfy8=.c613c4d0-6df2-49a4-bfa1-807e10c07147@github.com>

On Wed, 10 Dec 2025 17:17:13 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> I can't find a way to access the identity hash code without compilation. Would something like a method that calls System.identityHashCode but is not inlied work?
>
> You could compute the result in the static initializer, it should therefore be computed in the interpreter. And then add a `@Check` method to compare the `testSum` value from the compiler.

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2620621850

From iklam at openjdk.org  Mon Dec 15 20:28:17 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 15 Dec 2025 20:28:17 GMT
Subject: RFR: 8373441: Remove DCmdFactory::_enabled [v2]
In-Reply-To: <ppwkDYos68jcWO3LlFPFjyVqNdjvA56mPWgSG6Zkf5Q=.07a2fd74-2c98-426e-ae8a-92db8e7031b1@github.com>
References: <XE188S-C6EdTA2PRsdsQTi4Z550PW6DNpL3awvANazU=.1b0cd4d1-56cd-491a-b80c-8e2bafcc78ca@github.com>
 <AjjRyNcaMQOA-qcgilZVf5STbEMEmWAoBy3_BidW48k=.15d682e2-f8b6-4e4d-8fc2-f482e117b6b2@github.com>
 <ppwkDYos68jcWO3LlFPFjyVqNdjvA56mPWgSG6Zkf5Q=.07a2fd74-2c98-426e-ae8a-92db8e7031b1@github.com>
Message-ID: <q4BmjvrFm3_ALV5EhJ_J59ZEiE_JnntbioCSk4zdArI=.a79e7fb2-40aa-4710-b3e5-dd43fbfd1238@github.com>

On Mon, 15 Dec 2025 06:11:22 GMT, David Holmes <dholmes at openjdk.org> wrote:

> If we are just changing the implementation then I guess this would be okay. But it seems the API for this allows for specific DCmds to be disabled (how?) - or at least intended for it to be possible. As per the doc:
> 
> > When the set of diagnostic commands currently supported by the Java Virtual Machine is modified, the DiagnosticCommandMBean emits a [Notification](https://docs.oracle.com/javase/8/docs/api/javax/management/Notification.html?is-external=true) with a [type](https://docs.oracle.com/javase/8/docs/api/javax/management/Notification.html?is-external=true#getType--) of[ "jmx.mbean.info.changed"](https://docs.oracle.com/javase/8/docs/api/javax/management/MBeanInfo.html#info-changed) and a [userData](https://docs.oracle.com/javase/8/docs/api/javax/management/Notification.html?is-external=true#getUserData--) that is the new MBeanInfo.

The above paragraph is about new commands being added:


int DCmdFactory::register_DCmdFactory(DCmdFactory* factory) {
  MutexLocker ml(DCmdFactory_lock, Mutex::_no_safepoint_check_flag);
  factory->_next = _DCmdFactoryList;
  _DCmdFactoryList = factory;
  if (_send_jmx_notification && !factory->_hidden
      && (factory->_export_flags & DCmd_Source_MBean)) {
    DCmdFactory::push_jmx_notification_request();
  }
  return 0; // Actually, there's no checks for duplicates
}


Which will eventually cause `DiagnosticCommandImpl::createDiagnosticFrameworkNotification()` to be called by HotSpot to dispatch the `Notification`.

I checked older source code like JDK 8, which has a `DCmdFactory::set_enabled()` method but there are no callers. If there had been a way to disable commands dynamically, that has been lost for a very long time.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28794#issuecomment-3657448785

From dholmes at openjdk.org  Mon Dec 15 20:54:32 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 15 Dec 2025 20:54:32 GMT
Subject: RFR: 8373654: Test sources/TestNoNull should only run once
Message-ID: <L0u3UjIJt8pEZdt8WfgVU8oGYUsCzeY6c55UPsm_Cus=.f55a3b5c-0104-45bd-8d84-9f26c7a38c03@github.com>

This test is checking for backsliding on the use of NULL in the hotspot source files. The test only needs to be run once per change but it is defined as a regular tier1 test which then gets run for each os-arch combination, plus product and debug, and then again with a bunch of flags in tier3. This is just a waste of resources. At a minimum we should make the test flagless so that it doesn't run in tier3, but we can also restrict it to a single platform.

Before the change the test ran 27 times in tier1-3 in our CI. After it runs once. 

Thanks

-------------

Commit messages:
 - 8373654: Test sources/TestNoNull should only run once

Changes: https://git.openjdk.org/jdk/pull/28818/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28818&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373654
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28818.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28818/head:pull/28818

PR: https://git.openjdk.org/jdk/pull/28818

From shade at openjdk.org  Mon Dec 15 20:54:33 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 15 Dec 2025 20:54:33 GMT
Subject: RFR: 8373654: Test sources/TestNoNull should only run once
In-Reply-To: <L0u3UjIJt8pEZdt8WfgVU8oGYUsCzeY6c55UPsm_Cus=.f55a3b5c-0104-45bd-8d84-9f26c7a38c03@github.com>
References: <L0u3UjIJt8pEZdt8WfgVU8oGYUsCzeY6c55UPsm_Cus=.f55a3b5c-0104-45bd-8d84-9f26c7a38c03@github.com>
Message-ID: <PguY25K3cPr0ysfCrNS20gMoc53wUeYnAs0CZ-JrMlQ=.5d96beb6-2d2c-416d-8dd4-dd4c43c76d3a@github.com>

On Mon, 15 Dec 2025 06:52:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This test is checking for backsliding on the use of NULL in the hotspot source files. The test only needs to be run once per change but it is defined as a regular tier1 test which then gets run for each os-arch combination, plus product and debug, and then again with a bunch of flags in tier3. This is just a waste of resources. At a minimum we should make the test flagless so that it doesn't run in tier3, but we can also restrict it to a single platform.
> 
> Before the change the test ran 27 times in tier1-3 in our CI. After it runs once. 
> 
> Thanks

`flagless` -- I agree!
`linux` and `amd64` -- as someone who re-runs this test on my M1 Mac to reproduce CI failures, I disagree!
`vm.debug` -- I am on the fence here, but probably fine to restrict it to debug only, as we expect most folks to run tests with debug VMs.

You might want to do this for other `sources/` tests?

-------------

PR Review: https://git.openjdk.org/jdk/pull/28818#pullrequestreview-3577715711

From dholmes at openjdk.org  Mon Dec 15 20:54:33 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 15 Dec 2025 20:54:33 GMT
Subject: RFR: 8373654: Test sources/TestNoNull should only run once
In-Reply-To: <L0u3UjIJt8pEZdt8WfgVU8oGYUsCzeY6c55UPsm_Cus=.f55a3b5c-0104-45bd-8d84-9f26c7a38c03@github.com>
References: <L0u3UjIJt8pEZdt8WfgVU8oGYUsCzeY6c55UPsm_Cus=.f55a3b5c-0104-45bd-8d84-9f26c7a38c03@github.com>
Message-ID: <vlZOWoST8q-wH026QV6rdSKCmAMWfQMZVAvxQhDqwUg=.bcb23b37-cdc7-4976-997a-caef41b656be@github.com>

On Mon, 15 Dec 2025 06:52:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This test is checking for backsliding on the use of NULL in the hotspot source files. The test only needs to be run once per change but it is defined as a regular tier1 test which then gets run for each os-arch combination, plus product and debug, and then again with a bunch of flags in tier3. This is just a waste of resources. At a minimum we should make the test flagless so that it doesn't run in tier3, but we can also restrict it to a single platform.
> 
> Before the change the test ran 27 times in tier1-3 in our CI. After it runs once. 
> 
> Thanks

Thanks for taking a look @shipilev !

> linux and amd64 -- as someone who re-runs this test on my M1 Mac to reproduce CI failures, I disagree!

Reality is that for every changeset integrated only one entity in the world actually needs to run this test. But I can drop the platform restriction - 4 runs is still better than 27.

> You might want to do this for other sources/ tests?

I'll take a look at what they do. I only tripped over this one when a stray file caused it to fail.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28818#issuecomment-3657554161

From dholmes at openjdk.org  Mon Dec 15 21:22:18 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 15 Dec 2025 21:22:18 GMT
Subject: RFR: 8373654: Tests in sources/ should only run once [v2]
In-Reply-To: <L0u3UjIJt8pEZdt8WfgVU8oGYUsCzeY6c55UPsm_Cus=.f55a3b5c-0104-45bd-8d84-9f26c7a38c03@github.com>
References: <L0u3UjIJt8pEZdt8WfgVU8oGYUsCzeY6c55UPsm_Cus=.f55a3b5c-0104-45bd-8d84-9f26c7a38c03@github.com>
Message-ID: <zSxW1N3vIuGI0x_MqpwzylBv68PkLNucOMbI1xZOKb4=.a0a9dc06-084b-4dcc-ba05-4da6050d5608@github.com>

> This test is checking for backsliding on the use of NULL in the hotspot source files. The test only needs to be run once per change but it is defined as a regular tier1 test which then gets run for each os-arch combination, plus product and debug, and then again with a bunch of flags in tier3. This is just a waste of resources. At a minimum we should make the test flagless so that it doesn't run in tier3, but we can also restrict it to a single platform.
> 
> Before the change the test ran 27 times in tier1-3 in our CI. After it runs once. 
> 
> 
> EDIT: Updated to include both tests in sources/
> 
> Thanks

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Relax platform restriction
  Add TestIncludesAreSorted

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28818/files
  - new: https://git.openjdk.org/jdk/pull/28818/files/ba9962c3..d06591b5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28818&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28818&range=00-01

  Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28818.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28818/head:pull/28818

PR: https://git.openjdk.org/jdk/pull/28818

From dlong at openjdk.org  Mon Dec 15 23:00:38 2025
From: dlong at openjdk.org (Dean Long)
Date: Mon, 15 Dec 2025 23:00:38 GMT
Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() [v6]
In-Reply-To: <yRkEv29KF1vLIy4V5nKDgQF7CfvVjUjfssdzZ0PccjA=.00171af8-a1aa-401b-9341-a80a6fb4e22e@github.com>
References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com>
 <CEvEqPtlTMiv7fX1G_spyCpyl8afEZn4McrzIBd5GRY=.d233254e-3626-4044-a3e1-c82bcbd55e45@github.com>
 <6E4yPY9dRcWGBT-vPPq7bOm1NfLdvIfLdecg34f6Tes=.11b0a7c1-798f-4ed2-a521-26059bc0ba5b@github.com>
 <yRkEv29KF1vLIy4V5nKDgQF7CfvVjUjfssdzZ0PccjA=.00171af8-a1aa-401b-9341-a80a6fb4e22e@github.com>
Message-ID: <yhtSX7dHSCAnDVCm5UX_9Pfx0-P3FnydZOAbRt7-6Ow=.253c5dbb-c7d1-4543-94cc-cbd1a05d5c0e@github.com>

On Sat, 13 Dec 2025 09:40:21 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > The race because of old redefined methods might be more likely.
> 
> Mm, yes. Do you know of a good stress test for that?

8225681 mentions vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine, so I would start there.  However, I suspect that the race is no longer possible, because redefining a class should require a safepoint, and after 8322630 we no longer allow a safepoint between resolving the callee and updating the call site.  But maybe there is still a race before the NoSafepointVerifier in resolve_helper if two threads are trying to resolve the same call site and they allow a safepoint during find_callee_info.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26638#issuecomment-3657951520

From ayang at openjdk.org  Tue Dec 16 00:19:07 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 16 Dec 2025 00:19:07 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v22]
In-Reply-To: <ET-MhWMYi6ja-ge-H209Fy9ZHkMPL-6ZaPEeegAAraM=.2f40c659-5c3c-486b-adea-66488fd6050d@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <rAPcRMkxD0uoJTzadbMR7eui7ixfiVHCKy8JCvS5TPc=.6307f4fd-e333-41c8-97f2-81971974eb93@github.com>
 <C2nKyRSBdqEqIK0I3bEP1X4PM1K3Gb3HhPaxqgJeIS8=.62ffb736-16a7-4da9-8d11-1c147dfb40a1@github.com>
 <g0INjxl-T0NTw_GN4GkKl-d-gwjKQAmQs7_YB1R_LWo=.eaaddff1-531c-4ebc-956c-b091676be405@github.com>
 <ET-MhWMYi6ja-ge-H209Fy9ZHkMPL-6ZaPEeegAAraM=.2f40c659-5c3c-486b-adea-66488fd6050d@github.com>
Message-ID: <ORGz3sV06WeoIr4xH5NXriQLmGaA5es8wXyKhn0ddJ4=.677f4c8c-7e6b-4ccb-92b0-2b34b2bf329b@github.com>

On Mon, 15 Dec 2025 12:48:18 GMT, SilenceZheng66 <duke at openjdk.org> wrote:

>> @SilenceZheng66 Could you elaborate the issue, ideally, in a JBS ticket? (A reproducer/gc-log would be nice, but detailed description works as well.)
>
> @albertnetymk Sure.  I will give detailed description here.
> 
> GC?PS MarkSweep?PS Scavenge
> 
> JVM configuraton:  
> -Xmx2g 
> -Xms256M 
> -XX:MetaspaceSize=256m 
> -XX:MaxMetaspaceSize=256m 
> -XX:+PrintGCDateStamps 
> -XX:+PrintGCDetails 
> -XX:-UseAdaptiveSizePolicy 
> -XX:+PrintAdaptiveSizePolicy 
> -XX:+HeapDumpBeforeFullGC 
> -XX:+HeapDumpOnOutOfMemoryError 
> -XX:HeapDumpPath=export/Logs/ 
> -Xloggc:/export/Logs/gclogs.log 
> 
> JVM version?25.191-b12, although it's an old version without maintenance, I find out the problem might still in the latest version.
> 
> Problem Description: 
> When starting a application(like SpringBoot), objects loading to VM continuously, my CPU usage suddenly began to skyrocket, followed by a full GC lasting over ten minutes with more than 2,700 occurrences. Examining the GC logs revealed that prior to the full GC, several successful young GC events had taken place until the old generation was completely filled. I read the source code and find out when -XX:-UseAdaptiveSizePolicy was set,  VM thread can't expand psOldGen, only GC worker can expand psOldGen's size in that condition. I assume that the transition from the younger generation to the older generation has been successful, so that GC worker's expansion was not reached, that made long term full GC happened.
> 
> Check List:
> 1. Container has enough place for heap expansion
> 2. Xms and Xmx were setting differently, same configuration in Serial GC can raise heap expansion
> 
> GC log sample:
> // Full GC Starting
> [PSYoungGen: 76276K->10735K(76288K)] 244793K->181638K(251392K), 0.0078092 secs] [Times: user=0.04 sys=0.00, real=0.01 secs] 
> 2025-12-10T14:11:58.663+0800: 24.604: [Heap Dump (before full gc): , 0.0000482 secs]2025-12-10T14:11:58.663+0800: 24.604: [Full GC (Ergonomics) [PSYoungGen: 10735K->0K(76288K)] [ParOldGen: 170902K->173351K(175104K)] 181638K->173351K(251392K), [Metaspace: 107770K->107770K(1146880K)], 0.5258832 secs] [Times: user=1.82 sys=0.00, real=0.52 secs] 
> 2025-12-10T14:11:59.268+0800: 25.210: [Heap Dump (before full gc): , 0.0000684 secs]2025-12-10T14:11:59.269+0800: 25.210: [Full GC (Ergonomics) [PSYoungGen: 65536K->0K(76288K)] [ParOldGen: 173351K->174276K(175104K)] 238887K->174276K(251392K), [Metaspace: 109096K->109096K(1148928K)], 0.3031080 secs] [Times: user=1.10 sys=0.01, real=0.30 secs] 
> 2025-12-10T14:11:59.710+0800: 25.651: [Heap Dump (before full gc): , 0.0000752 secs]2025-12-10T14:11:59.710+0800: 25.651: [Full GC (Ergonomics) [PSYoungGen: 65536K->0K(76288K)] [ParOldGen: 174276K->174980K(...

I?m not very familiar with this output format. The following three flags have been superseded by `-Xlog:gc*`:


-XX:+PrintGCDateStamps
-XX:+PrintGCDetails
-XX:+PrintAdaptiveSizePolicy


Could you try using `-Xlog:gc*` instead? I think that would make it easier for me to understand the issue.

Additionally, the change from `8338977: Parallel: Improve heap resizing heuristics` should have significantly improved adaptive resizing behavior. Running with `-XX:-UseAdaptiveSizePolicy` is not a configuration we recommend. Would it be possible for you to rerun your benchmark using a build that includes `8338977`, with `UseAdaptiveSizePolicy` enabled?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2621257012

From dholmes at openjdk.org  Tue Dec 16 01:08:51 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 16 Dec 2025 01:08:51 GMT
Subject: RFR: 8369515: Deadlock between JVMTI and JNI
 ReleasePrimitiveArrayCritical
In-Reply-To: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
References: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
Message-ID: <81N6cE39iTwOjsu2Jt1fU3ypFW7S6AjJw5Ufsgv2Xqs=.af055769-cc2b-4169-b02d-cc65b246427e@github.com>

On Fri, 12 Dec 2025 04:20:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

> As discussed in JBS the deadlock occurs when the call to `ReleasePrimitiveArrayCritical` performs the transition from native to VM, and in the process checks for special runtime exit conditions - which includes the `obj_deopt_suspend` request. The simple solution is to define a custom JNI ENTRY with custom `ThreadInVMfromNative` that elides the exit check.
> 
> The change is limited to `ReleasePrimitiveArrayCritical` and `ReleaseStringCritical`.
> 
> There is no regression test as this has only been seen in long running stress tests.
> 
> Testing:
>    -tiers 1-6

> I do think that also entering a critical region is problematic if it is nested.

Isn't nesting critical regions against the rules of using critical regions?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28779#issuecomment-3658251463

From qamai at openjdk.org  Tue Dec 16 02:31:57 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 16 Dec 2025 02:31:57 GMT
Subject: RFR: 8372845: C2: Fold identity hash code if object is constant
 [v4]
In-Reply-To: <UjiK2tzVFPBS7-BCTt5cprbISPM9MvxCEtrvkooc0Wc=.7665d634-e648-49a6-ba6c-1ef85ee5377f@github.com>
References: <KPNLohuiE3Os64ib8cPl8cyPUbmvzOF2y687qapKSgc=.cae21b9f-2fa9-4e78-a5ef-7912cf906dfa@github.com>
 <UjiK2tzVFPBS7-BCTt5cprbISPM9MvxCEtrvkooc0Wc=.7665d634-e648-49a6-ba6c-1ef85ee5377f@github.com>
Message-ID: <Yn1i_z0VV3RANxrRsTi0aULvhPrJ5cmTavZN7kbCT4E=.44df8c39-df2b-42a1-8b98-53ec540b1ee1@github.com>

On Mon, 15 Dec 2025 19:49:52 GMT, Chen Liang <liach at openjdk.org> 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/c026ba9b...67a3954f

src/hotspot/share/opto/library_call.cpp line 4806:

> 4804:     assert(!is_virtual, "no devirtualization for constant receiver?");
> 4805:     ciConstant identity_hash = t->const_oop()->identity_hash();
> 4806:     if (identity_hash.is_valid()) {

Is there any reason we don't calculate the identity hash right away if there is not any?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2621527376

From liach at openjdk.org  Tue Dec 16 02:42:59 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 16 Dec 2025 02:42:59 GMT
Subject: RFR: 8372845: C2: Fold identity hash code if object is constant
 [v4]
In-Reply-To: <Yn1i_z0VV3RANxrRsTi0aULvhPrJ5cmTavZN7kbCT4E=.44df8c39-df2b-42a1-8b98-53ec540b1ee1@github.com>
References: <KPNLohuiE3Os64ib8cPl8cyPUbmvzOF2y687qapKSgc=.cae21b9f-2fa9-4e78-a5ef-7912cf906dfa@github.com>
 <UjiK2tzVFPBS7-BCTt5cprbISPM9MvxCEtrvkooc0Wc=.7665d634-e648-49a6-ba6c-1ef85ee5377f@github.com>
 <Yn1i_z0VV3RANxrRsTi0aULvhPrJ5cmTavZN7kbCT4E=.44df8c39-df2b-42a1-8b98-53ec540b1ee1@github.com>
Message-ID: <OCdODPjkfuUnqO_CQakJB-B7wFpfLkmhECsVouA7vx4=.c5c19adb-04e7-4404-8287-7632b0d0bf86@github.com>

On Tue, 16 Dec 2025 02:29:05 GMT, Quan Anh Mai <qamai at openjdk.org> 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/cea24102...67a3954f
>
> src/hotspot/share/opto/library_call.cpp line 4806:
> 
>> 4804:     assert(!is_virtual, "no devirtualization for constant receiver?");
>> 4805:     ciConstant identity_hash = t->const_oop()->identity_hash();
>> 4806:     if (identity_hash.is_valid()) {
> 
> Is there any reason we don't calculate the identity hash right away if there is not any?

@iwanowww recommended not to so that we can save resources - ideally we should convert this to sort of macro node, so we can calculate the hash if the node is not eliminated in the end.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2621544616

From vlivanov at openjdk.org  Tue Dec 16 02:53:53 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 16 Dec 2025 02:53:53 GMT
Subject: RFR: 8372845: C2: Fold identity hash code if object is constant
 [v4]
In-Reply-To: <OCdODPjkfuUnqO_CQakJB-B7wFpfLkmhECsVouA7vx4=.c5c19adb-04e7-4404-8287-7632b0d0bf86@github.com>
References: <KPNLohuiE3Os64ib8cPl8cyPUbmvzOF2y687qapKSgc=.cae21b9f-2fa9-4e78-a5ef-7912cf906dfa@github.com>
 <UjiK2tzVFPBS7-BCTt5cprbISPM9MvxCEtrvkooc0Wc=.7665d634-e648-49a6-ba6c-1ef85ee5377f@github.com>
 <Yn1i_z0VV3RANxrRsTi0aULvhPrJ5cmTavZN7kbCT4E=.44df8c39-df2b-42a1-8b98-53ec540b1ee1@github.com>
 <OCdODPjkfuUnqO_CQakJB-B7wFpfLkmhECsVouA7vx4=.c5c19adb-04e7-4404-8287-7632b0d0bf86@github.com>
Message-ID: <4nezat7vgHclje5N0lTXYIW49lgU1c9Fb_PXiUhffmE=.2f83013e-994e-4cec-b1ae-43e37c0b3455@github.com>

On Tue, 16 Dec 2025 02:39:47 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/hotspot/share/opto/library_call.cpp line 4806:
>> 
>>> 4804:     assert(!is_virtual, "no devirtualization for constant receiver?");
>>> 4805:     ciConstant identity_hash = t->const_oop()->identity_hash();
>>> 4806:     if (identity_hash.is_valid()) {
>> 
>> Is there any reason we don't calculate the identity hash right away if there is not any?
>
> @iwanowww recommended not to so that we can save resources - ideally we should convert this to sort of macro node, so we can calculate the hash if the node is not eliminated in the end.

My main concern is possible interference with application, not performance.
 
One example is CDS where archive dumping is performed in a single thread with a fixed random generator seed. If identity hash computation can be triggered from JIT-compiler thread (with a different seed), it will break deterministic behavior.

Another case to illustrate another type of issues is biased locking: the optimization was disabled for objects with identity hash code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28589#discussion_r2621562185

From lmesnik at openjdk.org  Tue Dec 16 03:42:21 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 16 Dec 2025 03:42:21 GMT
Subject: RFR: 8373723: Deadlock with JvmtiTagMap::flush_object_free_events()
Message-ID: <NSbobPaTwRkepNErCWi1IEKZ0JT6R-dGNTI0S_dM8Ts=.53706809-f5ed-489c-be79-3020efea185b@github.com>

The JvmtiTagMap::flush_object_free_events() method might be called from different threads.
The thread waits using lock until other thread posting events. The locking thread is in vm state doesn't allowing safepoints. While other thread posting events might request safepoints.

The fix is to block thread to allow safepoints while waiting on the lock.

-------------

Commit messages:
 - 8373723: Deadlock with JvmtiTagMap::flush_object_free_events()

Changes: https://git.openjdk.org/jdk/pull/28839/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28839&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373723
  Stats: 4 lines in 1 file changed: 3 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28839.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28839/head:pull/28839

PR: https://git.openjdk.org/jdk/pull/28839

From dholmes at openjdk.org  Tue Dec 16 04:01:00 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 16 Dec 2025 04:01:00 GMT
Subject: RFR: 8373723: Deadlock with
 JvmtiTagMap::flush_object_free_events()
In-Reply-To: <NSbobPaTwRkepNErCWi1IEKZ0JT6R-dGNTI0S_dM8Ts=.53706809-f5ed-489c-be79-3020efea185b@github.com>
References: <NSbobPaTwRkepNErCWi1IEKZ0JT6R-dGNTI0S_dM8Ts=.53706809-f5ed-489c-be79-3020efea185b@github.com>
Message-ID: <07HKvRU8Zx99j0UnNMVNhY7XfoGMaqb_55hYJ-Ippk0=.a4d21351-3e03-407f-a0ed-870569cac816@github.com>

On Tue, 16 Dec 2025 03:34:47 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The JvmtiTagMap::flush_object_free_events() method might be called from different threads.
> The thread waits using lock until other thread posting events. The locking thread is in vm state doesn't allowing safepoints. While other thread posting events might request safepoints.
> 
> The fix is to block thread to allow safepoints while waiting on the lock.

src/hotspot/share/prims/jvmtiTagMap.cpp line 1208:

> 1206:     {
> 1207:       // If another thread is posting events, let it finish.
> 1208:       // This another thread might have safepoints during event callbacks.

The comment does not read correctly.

src/hotspot/share/prims/jvmtiTagMap.cpp line 1210:

> 1208:       // This another thread might have safepoints during event callbacks.
> 1209:       ThreadBlockInVM tbivm(JavaThread::current());
> 1210:       MonitorLocker ml(lock(), Mutex::_no_safepoint_check_flag);

Why not just remove the "no safepoint check" from the MonitorLocker?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28839#discussion_r2621667991
PR Review Comment: https://git.openjdk.org/jdk/pull/28839#discussion_r2621668730

From kbarrett at openjdk.org  Tue Dec 16 04:06:02 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 16 Dec 2025 04:06:02 GMT
Subject: RFR: 8373649: Convert simple AtomicAccess usage in
 ConcurrentHashTable to use Atomic<T>
In-Reply-To: <qWj65I2wF19f1CVMRTH9WvOep0zWOEqN2tIxDSrrpz0=.f5c20ac2-9861-453d-9007-d5bdc9c99d33@github.com>
References: <rcuhR8LdUTG0zHxMHGIbB6dD93LCz-voc8IHRV9NDnU=.3ace9437-f609-4702-b8c5-0f70db2a5935@github.com>
 <qWj65I2wF19f1CVMRTH9WvOep0zWOEqN2tIxDSrrpz0=.f5c20ac2-9861-453d-9007-d5bdc9c99d33@github.com>
Message-ID: <CRQAs2GAwYDD5FMW1hJVyifZg5YTP82re5xBNc3JIds=.4c1941f1-7774-445e-9cd3-8390c3bd2f5d@github.com>

On Mon, 15 Dec 2025 12:32:51 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Please review this conversion of simple AtomicAccess usage in
>> ConcurrentHashTable to use Atomic<T>.  This is split out from the complete
>> conversion to simplify reviewing and testing.
>> 
>> Testing: mach5 tier1-3
>
> Marked as reviewed by tschatzl (Reviewer).

Thanks for reviews @tschatzl and @walulyai

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28816#issuecomment-3658636839

From kbarrett at openjdk.org  Tue Dec 16 04:06:03 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 16 Dec 2025 04:06:03 GMT
Subject: Integrated: 8373649: Convert simple AtomicAccess usage in
 ConcurrentHashTable to use Atomic<T>
In-Reply-To: <rcuhR8LdUTG0zHxMHGIbB6dD93LCz-voc8IHRV9NDnU=.3ace9437-f609-4702-b8c5-0f70db2a5935@github.com>
References: <rcuhR8LdUTG0zHxMHGIbB6dD93LCz-voc8IHRV9NDnU=.3ace9437-f609-4702-b8c5-0f70db2a5935@github.com>
Message-ID: <R87DOER_uuA86gjPBsuEVflpeiWsa65tCgmjH4RD3OM=.881e3ce7-b8e3-4a2d-b946-f54169f0d2f7@github.com>

On Mon, 15 Dec 2025 03:23:07 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this conversion of simple AtomicAccess usage in
> ConcurrentHashTable to use Atomic<T>.  This is split out from the complete
> conversion to simplify reviewing and testing.
> 
> Testing: mach5 tier1-3

This pull request has now been integrated.

Changeset: 3f33eaa4
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3f33eaa42aff45422c94300573c898868189fdfc
Stats:     58 lines in 3 files changed: 3 ins; 0 del; 55 mod

8373649: Convert simple AtomicAccess usage in ConcurrentHashTable to use Atomic<T>

Reviewed-by: tschatzl, iwalulya

-------------

PR: https://git.openjdk.org/jdk/pull/28816

From dholmes at openjdk.org  Tue Dec 16 04:25:51 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 16 Dec 2025 04:25:51 GMT
Subject: RFR: 8343809: Add requires tag to mark tests that are incompatible
 with exploded image
In-Reply-To: <GtxujYXXFK6Y32kkijCc7XyGcMStlbQs7C9OM2QxmfM=.cbfe5c94-c9ab-4852-bad2-66deb4932723@github.com>
References: <GtxujYXXFK6Y32kkijCc7XyGcMStlbQs7C9OM2QxmfM=.cbfe5c94-c9ab-4852-bad2-66deb4932723@github.com>
Message-ID: <wt6XDk1-rd0KddQ0fIo6lm6OBKzxqPkzclO0MxmBlLQ=.66394099-a1c3-4ef0-8958-8606321fbfab@github.com>

On Sat, 13 Dec 2025 20:01:13 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The 
> jdk.explodedImage
> might be used to filter tests incompatible with 
> make exploded-run-test TEST=...
> 
> The exploded-run-test  mode is used only for quick manual testing and not in CI or ATR testing. However, it is make sense to reduce false positive failures so developers don't waste time during local testing.

Seems reasonable.

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28814#pullrequestreview-3581204741

From jwaters at openjdk.org  Tue Dec 16 04:37:48 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 16 Dec 2025 04:37:48 GMT
Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v5]
In-Reply-To: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
Message-ID: <hjRvIw3rtHoRZtf2h9T6wiHcF6iaIeyGjtOgRca_BUA=.9ef1111e-57ff-4290-bb39-fedaa5174232@github.com>

> 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 23 commits:

 - 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
 - Revert recent changes to spec.gmk.template
 - Revert recent changes to flags-ldflags.m4
 - Revert recent changes to flags-cflags.m4
 - Remove no longer needed warning disable in JvmFeatures.gmk
 - ... and 13 more: https://git.openjdk.org/jdk/compare/3f33eaa4...fbe79af6

-------------

Changes: https://git.openjdk.org/jdk/pull/22464/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22464&range=04
  Stats: 60 lines in 8 files changed: 11 ins; 45 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 dholmes at openjdk.org  Tue Dec 16 04:49:52 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 16 Dec 2025 04:49:52 GMT
Subject: RFR: 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: <foG1voIFiv_mFEDo5VAlX7n-iKntbtLzHBt6te9GjgY=.03c20e9e-cfa9-404f-998d-bc53b29c4579@github.com>

On Mon, 15 Dec 2025 16:53:05 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> When a frame is OSR and the caller is interpreted we call `push_cont_fastpath` to possible set `_cont_fastpath` to the `sp` of the sender. This is needed in order to keep track of interpreted frames in the stack, so that in case of unmounting we don't incorrectly execute the freeze fast path, which is only allowed when all frames are compiled.
> 
> The problem is that the OSR frame is created starting from the `unextended_sp` of the sender, not the `sp`, i.e we pop the interpreted frame like in `remove_activation`. This means that we could set a value to `_cont_fastpath` that will point outside the valid stack (below the `sp` of the OSR frame). If the gap between these stack addresses is big enough, `_cont_fastpath` could be later cleared while we still have the interpreter sender in the stack, leading to the reported crash. The simplest case where this will happen is if in a later call to yield all the extra frames leading to `Continuation.doYield` fit within this space [[1]](https://github.com/openjdk/jdk/blob/ad29642d8f4e8e0fb1223b14b85ab7841d7b1b51/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L232). It could also be cleared before that if for example at some point we returned from an interpreted callee and the sender sp it's not below `_cont_fastpath`[[2]](https://github.com/openjdk/jdk/blob/ad29642d8f4e8e0fb1223b
 14b85ab7841d7b1b51/src/hotspot/cpu/x86/interp_masm_x86.cpp#L1060).
> 
> The fix is to change `OSR_migration_begin` to set `_cont_fastpath` with the sender's `unextended_sp` instead. 
> 
> The patch includes new test `OSRWithManyLocals.java` which reliably reproduces the crash. I thought about adding it to the existing `OSRTest.java` but that was created to exercise a different issue. A better name for that test would be `OSRWithManyArgs.java`, so I could rename it in this patch if preferred (I also realized that test could be simplified and made easier to read but that's for another PR).
> 
> I tested the current patch with the new test and also run it through mach5 tiers1-7.
> 
> Thanks,
> Patricio

This seems to be a "day one" bug with virtual threads. Do you have an idea as to why it has not been noticed before?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28830#issuecomment-3658798159

From qamai at openjdk.org  Tue Dec 16 05:28:56 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 16 Dec 2025 05:28:56 GMT
Subject: RFR: 8367341: C2: apply KnownBits and unsigned bounds to And / Or
 operations [v7]
In-Reply-To: <D35W5XiaiB4fJX8hGUzZxzp8xLKleIDFFqWNubmvtw8=.4e13c49c-37cd-4ebb-b39c-9ba1b59deb2c@github.com>
References: <SqHEdFScmcQRe6wTaITLemzMzWD6jxGWCRWzHNepqjE=.ab7e7553-3a43-4b43-abc3-338d6493a35d@github.com>
 <D35W5XiaiB4fJX8hGUzZxzp8xLKleIDFFqWNubmvtw8=.4e13c49c-37cd-4ebb-b39c-9ba1b59deb2c@github.com>
Message-ID: <pNxFDqzFOPuyfZWkG7S0FYB4cnbZZrZUqQhEzhrpuIs=.870b46c6-6478-4822-824d-d2c0b2c43ef9@github.com>

On Sun, 7 Dec 2025 12:08:18 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This PR improves the implementation of `AndNode/OrNode/XorNode::Value` by taking advantages of the additional information in `TypeInt`. The implementation is pretty straightforward. A clever trick is that by analyzing the negative and positive ranges of a `TypeInt` separately, we have better info for the leading bits. I also implement gtest unit tests to verify the correctness and monotonicity of the inference functions.
>> 
>> Please take a look and leave your reviews, thanks a lot.
>
> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' into andorxor
>  - Merge branch 'master' into andorxor
>  - Merge branch 'master' into andorxor
>  - Add assertion for the helper in CTPComparator
>    
>    Co-authored-by: Emanuel Peter <emanuel.peter at oracle.com>
>  - remove std::hash
>  - remove unordered_map, add some comments for all_instances_size
>  - Emanuel's reviews
>  - Improve Value inferences of And, Or, Xor and implement gtest for general Value inferences

May I have a second review for this PR, please?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27618#issuecomment-3658904887

From dholmes at openjdk.org  Tue Dec 16 05:45:53 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 16 Dec 2025 05:45:53 GMT
Subject: RFR: 8373441: Remove DCmdFactory::_enabled [v2]
In-Reply-To: <AjjRyNcaMQOA-qcgilZVf5STbEMEmWAoBy3_BidW48k=.15d682e2-f8b6-4e4d-8fc2-f482e117b6b2@github.com>
References: <XE188S-C6EdTA2PRsdsQTi4Z550PW6DNpL3awvANazU=.1b0cd4d1-56cd-491a-b80c-8e2bafcc78ca@github.com>
 <AjjRyNcaMQOA-qcgilZVf5STbEMEmWAoBy3_BidW48k=.15d682e2-f8b6-4e4d-8fc2-f482e117b6b2@github.com>
Message-ID: <e9HrWI-CsO0LmVSwLPp43Gpn0dexy5aMDXT7ChJwpy0=.5106b6d0-9e20-4239-92c9-8522ec01974c@github.com>

On Fri, 12 Dec 2025 23:37:20 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The `DCmdFactory::_enabled` is always set to `true` and there doesn't seem to be a reason to set it to `false`.
>> 
>> This PR removes this field and simplified the creation of `DCmdFactory` objects.
>> 
>> The related `_hidden` field is also currently not used, but may be used in the future when deprecating DCmds, so we leave it unchanged.
>> 
>> Note that now `jmm_GetDiagnosticCommandInfo()` always set `dcmdInfo::enabled` to `true` to be compatible with Java code.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @kevinjwalls comments

For the history see 

https://bugs.openjdk.org/browse/JDK-7104647?focusedId=12336354&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12336354

The "enabled" capability came from the JRockit jrcmd tool:

https://docs.oracle.com/cd/E13150_01/jrockit_jvm/jrockit/geninfo/diagnos/ctrlbreakhndlr.html

> "You can enable or disable any diagnostic command using the system property -Djrockit.ctrlbreak.enable<name>=<true|false>, where name is the name of the diagnostic command."

But as far as I can see the DCmd framework never specified a mechanism for disabling a DCmd. @fparain may recall more details.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28794#issuecomment-3658938216

From qamai at openjdk.org  Tue Dec 16 06:23:12 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 16 Dec 2025 06:23:12 GMT
Subject: RFR: 8373591: C2: Fix the memory around some intrinsics nodes [v3]
In-Reply-To: <xqPVnw7PtK7ch97NBoScQARyosgTZhsq8Jypd6h2Cyg=.61115100-f6f0-4f16-a01c-33e587b3ecaf@github.com>
References: <xqPVnw7PtK7ch97NBoScQARyosgTZhsq8Jypd6h2Cyg=.61115100-f6f0-4f16-a01c-33e587b3ecaf@github.com>
Message-ID: <m1PRBAw6p8Zj-TEDSmv8P7B04xdHehUrBdNWDDwMeAo=.2a3b0a6f-31d4-43c8-85fa-5d25a59b7c62@github.com>

> Hi,
> 
> This is extracted from #28570 , there are 2 issues here:
> 
> - Some intrinsics nodes advertise incorrect `adr_type`. For example, `AryEqNode` reports `adr_type` being `TypeAryPtr::BYTES` (it inherits this from `StrIntrinsicNode`). This is incorrect, however, as it can accept `char[]` inputs, too. Another case is `VectorizedHashCodeNode`, which reports its `adr_type` being `TypePtr::BOTTOM`, but it actually extracts a memory slice and does not consume the whole memory.
> - For nodes such as `StrInflatedCopyNode`, as they consume more than they produce, during scheduling, we need to compute anti-dependencies. This is not the case, so we should fix it by making the nodes kill all the memory they consume. This issue is often not present because these intrinsics are not exposed bare to general usage.
> 
> Please kindly review, thanks a lot.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  Use MemBar instead of widening the intrinsic memory

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28789/files
  - new: https://git.openjdk.org/jdk/pull/28789/files/1e026354..9649a2f2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28789&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28789&range=01-02

  Stats: 62 lines in 3 files changed: 39 ins; 8 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/28789.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28789/head:pull/28789

PR: https://git.openjdk.org/jdk/pull/28789

From qamai at openjdk.org  Tue Dec 16 06:23:14 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 16 Dec 2025 06:23:14 GMT
Subject: RFR: 8373591: C2: Fix the memory around some intrinsics nodes [v3]
In-Reply-To: <YLCFqfSysXHB3bnJgSlR_70DqeVSJ7M0vleWtDeoSKg=.895b38ca-0dc5-469f-ac86-d4d7885bf32a@github.com>
References: <xqPVnw7PtK7ch97NBoScQARyosgTZhsq8Jypd6h2Cyg=.61115100-f6f0-4f16-a01c-33e587b3ecaf@github.com>
 <BawKNUAtVMK3lI3blP9RaOG9A1cxm84iZhNKFYaPDOg=.dcd8f6bb-d137-4462-ad1a-816b4e94adba@github.com>
 <rQxzIkDfE_4ZTcQxuBwMk9k3FOesl_86dmXYi33kkDE=.f393b683-4b62-4af5-98e8-307ab7b0ab6f@github.com>
 <YLCFqfSysXHB3bnJgSlR_70DqeVSJ7M0vleWtDeoSKg=.895b38ca-0dc5-469f-ac86-d4d7885bf32a@github.com>
Message-ID: <PbA21O7H0tmBFfYNnqrwFffsaoq9aXVm_qI6QbuZjYo=.a4cdf28f-72eb-48a2-8c94-b8ad8fcd6c41@github.com>

On Mon, 15 Dec 2025 15:23:23 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> It is because if a node consumes more memory than it produces, we need to compute its anti-dependencies. And since we do not compute anti-dependencies of these nodes, it is safer to make them kill all the memory they consume. What do you think?
>
> Could this be fixed by appending a `MemBarCPUOrderNode` on the slice of src?

That's a really great idea! I have implemented it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28789#discussion_r2621940305

From dholmes at openjdk.org  Tue Dec 16 06:44:54 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 16 Dec 2025 06:44:54 GMT
Subject: RFR: 8373668: Add override keyword to *Klass classes [v2]
In-Reply-To: <f-PTSiuHzVJQBdypXVtsxUVt07Y58v-UsjRPt_gkhFM=.28f2ddae-a8f5-496e-9a55-5a7116b801a2@github.com>
References: <rJP1-555XexBIvK3yH_SdGiAEJjT38wEqZmslbynvOg=.1205594c-d2f0-40a1-9000-a7a6707a7d84@github.com>
 <f-PTSiuHzVJQBdypXVtsxUVt07Y58v-UsjRPt_gkhFM=.28f2ddae-a8f5-496e-9a55-5a7116b801a2@github.com>
Message-ID: <gz69rKJpjSX-o1Fkdd75-74guFRz9X9tMq1lHy52Tno=.2b0a0bac-b9c5-444c-9b36-001a2c4bcb40@github.com>

On Mon, 15 Dec 2025 13:22:55 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Using override provides better visibility and compiler support for suspicious virtual methods. It makes it clears when reading a class header file if a new virtual interface is introduced or if it simply overridden.
>> 
>> Testing
>>  * GHA
>>  * Running tier1 on Oracle supported platforms
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Whitespace changes

This all seems reasonable. I hope an IDE assisted with determining where override was needed, and virtual was not.

I think it would be good to see things marked final in the future as well.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28820#pullrequestreview-3581552256

From alanb at openjdk.org  Tue Dec 16 06:53:56 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 16 Dec 2025 06:53:56 GMT
Subject: RFR: 8343809: Add requires tag to mark tests that are incompatible
 with exploded image
In-Reply-To: <GtxujYXXFK6Y32kkijCc7XyGcMStlbQs7C9OM2QxmfM=.cbfe5c94-c9ab-4852-bad2-66deb4932723@github.com>
References: <GtxujYXXFK6Y32kkijCc7XyGcMStlbQs7C9OM2QxmfM=.cbfe5c94-c9ab-4852-bad2-66deb4932723@github.com>
Message-ID: <rUzDWBQqGjhTVoXbL6-ooEqg8skum_7k9fFibARN9Ws=.e37119cb-824e-4d8a-ab6e-7e3937e73653@github.com>

On Sat, 13 Dec 2025 20:01:13 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The 
> jdk.explodedImage
> might be used to filter tests incompatible with 
> make exploded-run-test TEST=...
> 
> The exploded-run-test  mode is used only for quick manual testing and not in CI or ATR testing. However, it is make sense to reduce false positive failures so developers don't waste time during local testing.

test/jtreg-ext/requires/VMProps.java line 758:

> 756:         try {
> 757:             Path jmodFile = Path.of(System.getProperty("java.home"), "jmods", "java.base.jmod");
> 758:             if (jmodFile.toFile().exists()) {

In passing, the Path -> File conversion wouldn't be needed if you use Files.exists here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28814#discussion_r2622028508

From hgreule at openjdk.org  Tue Dec 16 07:12:59 2025
From: hgreule at openjdk.org (Hannes Greule)
Date: Tue, 16 Dec 2025 07:12:59 GMT
Subject: RFR: 8367341: C2: apply KnownBits and unsigned bounds to And / Or
 operations [v7]
In-Reply-To: <D35W5XiaiB4fJX8hGUzZxzp8xLKleIDFFqWNubmvtw8=.4e13c49c-37cd-4ebb-b39c-9ba1b59deb2c@github.com>
References: <SqHEdFScmcQRe6wTaITLemzMzWD6jxGWCRWzHNepqjE=.ab7e7553-3a43-4b43-abc3-338d6493a35d@github.com>
 <D35W5XiaiB4fJX8hGUzZxzp8xLKleIDFFqWNubmvtw8=.4e13c49c-37cd-4ebb-b39c-9ba1b59deb2c@github.com>
Message-ID: <PSTCd1zHm35W9sEa5YW5Df2iehltXNtdj7-wMe6sKPo=.39c9a441-b79c-4903-9f41-8c823b1f276d@github.com>

On Sun, 7 Dec 2025 12:08:18 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This PR improves the implementation of `AndNode/OrNode/XorNode::Value` by taking advantages of the additional information in `TypeInt`. The implementation is pretty straightforward. A clever trick is that by analyzing the negative and positive ranges of a `TypeInt` separately, we have better info for the leading bits. I also implement gtest unit tests to verify the correctness and monotonicity of the inference functions.
>> 
>> Please take a look and leave your reviews, thanks a lot.
>
> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' into andorxor
>  - Merge branch 'master' into andorxor
>  - Merge branch 'master' into andorxor
>  - Add assertion for the helper in CTPComparator
>    
>    Co-authored-by: Emanuel Peter <emanuel.peter at oracle.com>
>  - remove std::hash
>  - remove unordered_map, add some comments for all_instances_size
>  - Emanuel's reviews
>  - Improve Value inferences of And, Or, Xor and implement gtest for general Value inferences

Not sure if my review counts but I went through the changes again and it looks like all existing inference logic is covered by the more concise and also more powerful new logic.

-------------

Marked as reviewed by hgreule (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27618#pullrequestreview-3581649461

From duke at openjdk.org  Tue Dec 16 07:13:09 2025
From: duke at openjdk.org (SilenceZheng66)
Date: Tue, 16 Dec 2025 07:13:09 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v22]
In-Reply-To: <ORGz3sV06WeoIr4xH5NXriQLmGaA5es8wXyKhn0ddJ4=.677f4c8c-7e6b-4ccb-92b0-2b34b2bf329b@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <rAPcRMkxD0uoJTzadbMR7eui7ixfiVHCKy8JCvS5TPc=.6307f4fd-e333-41c8-97f2-81971974eb93@github.com>
 <C2nKyRSBdqEqIK0I3bEP1X4PM1K3Gb3HhPaxqgJeIS8=.62ffb736-16a7-4da9-8d11-1c147dfb40a1@github.com>
 <g0INjxl-T0NTw_GN4GkKl-d-gwjKQAmQs7_YB1R_LWo=.eaaddff1-531c-4ebc-956c-b091676be405@github.com>
 <ET-MhWMYi6ja-ge-H209Fy9ZHkMPL-6ZaPEeegAAraM=.2f40c659-5c3c-486b-adea-66488fd6050d@github.com>
 <ORGz3sV06WeoIr4xH5NXriQLmGaA5es8wXyKhn0ddJ4=.677f4c8c-7e6b-4ccb-92b0-2b34b2bf329b@github.com>
Message-ID: <cGMcm5aJjVSTOvlxIDAuU2wvnRvmrgAN685V4htwscU=.7d504563-b632-4c8c-aa0f-d161a5c5af10@github.com>

On Tue, 16 Dec 2025 00:15:58 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> @albertnetymk Sure.  I will give detailed description here.
>> 
>> GC?PS MarkSweep?PS Scavenge
>> 
>> JVM configuraton:  
>> -Xmx2g 
>> -Xms256M 
>> -XX:MetaspaceSize=256m 
>> -XX:MaxMetaspaceSize=256m 
>> -XX:+PrintGCDateStamps 
>> -XX:+PrintGCDetails 
>> -XX:-UseAdaptiveSizePolicy 
>> -XX:+PrintAdaptiveSizePolicy 
>> -XX:+HeapDumpBeforeFullGC 
>> -XX:+HeapDumpOnOutOfMemoryError 
>> -XX:HeapDumpPath=export/Logs/ 
>> -Xloggc:/export/Logs/gclogs.log 
>> 
>> JVM version?25.191-b12, although it's an old version without maintenance, I find out the problem might still in the latest version.
>> 
>> Problem Description: 
>> When starting a application(like SpringBoot), objects loading to VM continuously, my CPU usage suddenly began to skyrocket, followed by a full GC lasting over ten minutes with more than 2,700 occurrences. Examining the GC logs revealed that prior to the full GC, several successful young GC events had taken place until the old generation was completely filled. I read the source code and find out when -XX:-UseAdaptiveSizePolicy was set,  VM thread can't expand psOldGen, only GC worker can expand psOldGen's size in that condition. I assume that the transition from the younger generation to the older generation has been successful, so that GC worker's expansion was not reached, that made long term full GC happened.
>> 
>> Check List:
>> 1. Container has enough place for heap expansion
>> 2. Xms and Xmx were setting differently, same configuration in Serial GC can raise heap expansion
>> 
>> GC log sample:
>> // Full GC Starting
>> [PSYoungGen: 76276K->10735K(76288K)] 244793K->181638K(251392K), 0.0078092 secs] [Times: user=0.04 sys=0.00, real=0.01 secs] 
>> 2025-12-10T14:11:58.663+0800: 24.604: [Heap Dump (before full gc): , 0.0000482 secs]2025-12-10T14:11:58.663+0800: 24.604: [Full GC (Ergonomics) [PSYoungGen: 10735K->0K(76288K)] [ParOldGen: 170902K->173351K(175104K)] 181638K->173351K(251392K), [Metaspace: 107770K->107770K(1146880K)], 0.5258832 secs] [Times: user=1.82 sys=0.00, real=0.52 secs] 
>> 2025-12-10T14:11:59.268+0800: 25.210: [Heap Dump (before full gc): , 0.0000684 secs]2025-12-10T14:11:59.269+0800: 25.210: [Full GC (Ergonomics) [PSYoungGen: 65536K->0K(76288K)] [ParOldGen: 173351K->174276K(175104K)] 238887K->174276K(251392K), [Metaspace: 109096K->109096K(1148928K)], 0.3031080 secs] [Times: user=1.10 sys=0.01, real=0.30 secs] 
>> 2025-12-10T14:11:59.710+0800: 25.651: [Heap Dump (before full gc): , 0.0000752 secs]2025-12-10T14:11:59.710+0800: 25.651: [Full GC (Ergonomi...
>
> I?m not very familiar with this output format. The following three flags have been superseded by `-Xlog:gc*`:
> 
> 
> -XX:+PrintGCDateStamps
> -XX:+PrintGCDetails
> -XX:+PrintAdaptiveSizePolicy
> 
> 
> Could you try using `-Xlog:gc*` instead? I think that would make it easier for me to understand the issue.
> 
> Additionally, the change from `8338977: Parallel: Improve heap resizing heuristics` should have significantly improved adaptive resizing behavior. Running with `-XX:-UseAdaptiveSizePolicy` is not a configuration we recommend. Would it be possible for you to rerun your benchmark using a build that includes `8338977`, with `UseAdaptiveSizePolicy` enabled?

@albertnetymk Since my JVM's version is 25.191-b12, it does not support `-Xlog:gc*` configuration. I also know that your work aim to improve performance when `UseAdaptiveSizePolicy` enabled, but in my situation default configuration is disable that. Now I just curious about is it a bug when people use configurations as following and could raise full GC problems and heap can't expand. 

-Xmx2g
-Xms256M
-XX:-UseAdaptiveSizePolicy

I understand that's totally not your business, but if you know who can explain or confirm this "bug", just let me know, thx!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2622073234

From aboldtch at openjdk.org  Tue Dec 16 07:41:22 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 16 Dec 2025 07:41:22 GMT
Subject: RFR: 8373668: Add override keyword to *Klass classes [v2]
In-Reply-To: <f-PTSiuHzVJQBdypXVtsxUVt07Y58v-UsjRPt_gkhFM=.28f2ddae-a8f5-496e-9a55-5a7116b801a2@github.com>
References: <rJP1-555XexBIvK3yH_SdGiAEJjT38wEqZmslbynvOg=.1205594c-d2f0-40a1-9000-a7a6707a7d84@github.com>
 <f-PTSiuHzVJQBdypXVtsxUVt07Y58v-UsjRPt_gkhFM=.28f2ddae-a8f5-496e-9a55-5a7116b801a2@github.com>
Message-ID: <MuD4MlDg9w0ygmQkwdRVemqs8eoR7M4wN2QPQ6OsLsU=.59e5f962-5414-4c89-a4a4-73cbcc8560a1@github.com>

On Mon, 15 Dec 2025 13:22:55 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Using override provides better visibility and compiler support for suspicious virtual methods. It makes it clears when reading a class header file if a new virtual interface is introduced or if it simply overridden.
>> 
>> Testing
>>  * GHA
>>  * Running tier1 on Oracle supported platforms
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Whitespace changes

Thanks for the reviews. (Rebuilt with latest master merged locally.)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28820#issuecomment-3659209845

From aboldtch at openjdk.org  Tue Dec 16 07:41:23 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 16 Dec 2025 07:41:23 GMT
Subject: Integrated: 8373668: Add override keyword to *Klass classes
In-Reply-To: <rJP1-555XexBIvK3yH_SdGiAEJjT38wEqZmslbynvOg=.1205594c-d2f0-40a1-9000-a7a6707a7d84@github.com>
References: <rJP1-555XexBIvK3yH_SdGiAEJjT38wEqZmslbynvOg=.1205594c-d2f0-40a1-9000-a7a6707a7d84@github.com>
Message-ID: <se3Rp8Uk8c-90fLAp7W9TcCCKhYbZDeDE8OqLrU_QBE=.012b60ed-e2dd-40f1-a349-eff3ff88c3ad@github.com>

On Mon, 15 Dec 2025 10:08:18 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Using override provides better visibility and compiler support for suspicious virtual methods. It makes it clears when reading a class header file if a new virtual interface is introduced or if it simply overridden.
> 
> Testing
>  * GHA
>  * Running tier1 on Oracle supported platforms

This pull request has now been integrated.

Changeset: 78c2d572
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/78c2d57259ad829a2cfc1370efbb2a5913df4661
Stats:     102 lines in 7 files changed: 0 ins; 5 del; 97 mod

8373668: Add override keyword to *Klass classes

Reviewed-by: jwaters, dholmes, kbarrett, tschatzl

-------------

PR: https://git.openjdk.org/jdk/pull/28820

From rrich at openjdk.org  Tue Dec 16 08:31:54 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Tue, 16 Dec 2025 08:31:54 GMT
Subject: RFR: 8369515: Deadlock between JVMTI and JNI
 ReleasePrimitiveArrayCritical
In-Reply-To: <81N6cE39iTwOjsu2Jt1fU3ypFW7S6AjJw5Ufsgv2Xqs=.af055769-cc2b-4169-b02d-cc65b246427e@github.com>
References: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
 <81N6cE39iTwOjsu2Jt1fU3ypFW7S6AjJw5Ufsgv2Xqs=.af055769-cc2b-4169-b02d-cc65b246427e@github.com>
Message-ID: <f6nwwrKfVBBHTfg3g4YxqGwv0m174bzQV4m9jGQIcgg=.37c78e76-7fcf-4148-903a-8e970f8a1593@github.com>

On Tue, 16 Dec 2025 01:05:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > I do think that also entering a critical region is problematic if it is nested.
> 
> Isn't nesting critical regions against the rules of using critical regions?

For arrays it's explicitly allowed in the specification. There's also an example how to do it properly :)
I'll see if I can implement a reproducer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28779#issuecomment-3659373705

From aph at openjdk.org  Tue Dec 16 08:58:57 2025
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 16 Dec 2025 08:58:57 GMT
Subject: RFR: 8372701: Randomized profile counters [v5]
In-Reply-To: <g1KuqOGCJFui09o74-uK7gPbFuoGDpUzdWXwltcBijA=.201adaaf-8a32-4906-81cf-be68279236c4@github.com>
References: <jKjmIONZcytzVjS4absOwOLv_QOF9qhIJifYhN6JyP4=.dceced94-bc29-43e6-9062-8dc77c2a6133@github.com>
 <1nJnov3s2hhiLuO0W2FNcSAiGu5eEjZauQxfzd5YXKw=.8c593111-294a-4df7-8ce0-322871a801f3@github.com>
 <QkEo7ytyGNKsig_FQcU68tuo3HHlHiaJPsPwaFCrE48=.34b31057-6bc3-4e6a-a621-3503c24c5050@github.com>
 <g1KuqOGCJFui09o74-uK7gPbFuoGDpUzdWXwltcBijA=.201adaaf-8a32-4906-81cf-be68279236c4@github.com>
Message-ID: <75WbmHmJSCs3TkMLgqRGeTNe1iFLy8oDHj5zhCoOFZA=.7f820bab-2e35-4672-b364-2c050d04df4f@github.com>

On Mon, 15 Dec 2025 18:51:43 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > Sure, I'm excited to do that. Please merge as soon as you can. Do you intend to do the same for AArch64? I volunteer, if you like.
> 
> I really wanted to avoid breaking mainline before going on NY break :) 

?

> I also wanted to task someone from our new cohort of OpenJDK engineers to put AArch64 version together in January.

I see. Good idea.

> Meanwhile, feel free to just mix up that PR here, if you want to hack on it?

I'll do that, then. Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28541#issuecomment-3659469318

From shade at openjdk.org  Tue Dec 16 09:04:56 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 16 Dec 2025 09:04:56 GMT
Subject: RFR: 8373654: Tests in sources/ should only run once [v2]
In-Reply-To: <zSxW1N3vIuGI0x_MqpwzylBv68PkLNucOMbI1xZOKb4=.a0a9dc06-084b-4dcc-ba05-4da6050d5608@github.com>
References: <L0u3UjIJt8pEZdt8WfgVU8oGYUsCzeY6c55UPsm_Cus=.f55a3b5c-0104-45bd-8d84-9f26c7a38c03@github.com>
 <zSxW1N3vIuGI0x_MqpwzylBv68PkLNucOMbI1xZOKb4=.a0a9dc06-084b-4dcc-ba05-4da6050d5608@github.com>
Message-ID: <D1mbKJVySY5Ti56tK6E75rSEjDt35Kuba6RId-F-POE=.ebd771cf-05e8-486e-851f-f782a0b29a88@github.com>

On Mon, 15 Dec 2025 21:22:18 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This test is checking for backsliding on the use of NULL in the hotspot source files. The test only needs to be run once per change but it is defined as a regular tier1 test which then gets run for each os-arch combination, plus product and debug, and then again with a bunch of flags in tier3. This is just a waste of resources. At a minimum we should make the test flagless so that it doesn't run in tier3, but we can also restrict it to a single platform.
>> 
>> Before the change the test ran 27 times in tier1-3 in our CI. After it runs once. 
>> 
>> 
>> EDIT: Updated to include both tests in sources/
>> 
>> Thanks
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Relax platform restriction
>   Add TestIncludesAreSorted

Looks reasonable to me, with only stylistic nits.

test/hotspot/jtreg/sources/TestIncludesAreSorted.java line 28:

> 26:  * @bug 8343802
> 27:  * @comment Only need to run this once, in tier1.
> 28:  * @requires vm.flagless & vm.debug == true

Would that also work?

Suggestion:

 * @comment Only need to run this once, in tier1
 * @requires vm.flagless & vm.debug

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28818#pullrequestreview-3582036511
PR Review Comment: https://git.openjdk.org/jdk/pull/28818#discussion_r2622398643

From qamai at openjdk.org  Tue Dec 16 09:19:06 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 16 Dec 2025 09:19:06 GMT
Subject: RFR: 8367341: C2: apply KnownBits and unsigned bounds to And / Or
 operations [v8]
In-Reply-To: <SqHEdFScmcQRe6wTaITLemzMzWD6jxGWCRWzHNepqjE=.ab7e7553-3a43-4b43-abc3-338d6493a35d@github.com>
References: <SqHEdFScmcQRe6wTaITLemzMzWD6jxGWCRWzHNepqjE=.ab7e7553-3a43-4b43-abc3-338d6493a35d@github.com>
Message-ID: <xMDLn1jlE5MhYML12NNGMf8aCQ4ah6ztsvFwbXH-Qv4=.b798d07b-3ed7-403a-8da0-0b1e540c903a@github.com>

> Hi,
> 
> This PR improves the implementation of `AndNode/OrNode/XorNode::Value` by taking advantages of the additional information in `TypeInt`. The implementation is pretty straightforward. A clever trick is that by analyzing the negative and positive ranges of a `TypeInt` separately, we have better info for the leading bits. I also implement gtest unit tests to verify the correctness and monotonicity of the inference functions.
> 
> Please take a look and leave your reviews, thanks a lot.

Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:

 - Merge branch 'master' into andorxor
 - Merge branch 'master' into andorxor
 - Merge branch 'master' into andorxor
 - Merge branch 'master' into andorxor
 - Add assertion for the helper in CTPComparator
   
   Co-authored-by: Emanuel Peter <emanuel.peter at oracle.com>
 - remove std::hash
 - remove unordered_map, add some comments for all_instances_size
 - Emanuel's reviews
 - Improve Value inferences of And, Or, Xor and implement gtest for general Value inferences

-------------

Changes: https://git.openjdk.org/jdk/pull/27618/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27618&range=07
  Stats: 964 lines in 9 files changed: 630 ins; 313 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/27618.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27618/head:pull/27618

PR: https://git.openjdk.org/jdk/pull/27618

From qamai at openjdk.org  Tue Dec 16 09:19:08 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 16 Dec 2025 09:19:08 GMT
Subject: RFR: 8367341: C2: apply KnownBits and unsigned bounds to And / Or
 operations [v8]
In-Reply-To: <PSTCd1zHm35W9sEa5YW5Df2iehltXNtdj7-wMe6sKPo=.39c9a441-b79c-4903-9f41-8c823b1f276d@github.com>
References: <SqHEdFScmcQRe6wTaITLemzMzWD6jxGWCRWzHNepqjE=.ab7e7553-3a43-4b43-abc3-338d6493a35d@github.com>
 <D35W5XiaiB4fJX8hGUzZxzp8xLKleIDFFqWNubmvtw8=.4e13c49c-37cd-4ebb-b39c-9ba1b59deb2c@github.com>
 <PSTCd1zHm35W9sEa5YW5Df2iehltXNtdj7-wMe6sKPo=.39c9a441-b79c-4903-9f41-8c823b1f276d@github.com>
Message-ID: <52_j1S_p1zU3IWYaoZ6w8eIZgbmarcvem1QSS5In75c=.af279e73-566c-4a86-9964-8731e4446e31@github.com>

On Tue, 16 Dec 2025 07:10:19 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
>> 
>>  - Merge branch 'master' into andorxor
>>  - Merge branch 'master' into andorxor
>>  - Merge branch 'master' into andorxor
>>  - Merge branch 'master' into andorxor
>>  - Add assertion for the helper in CTPComparator
>>    
>>    Co-authored-by: Emanuel Peter <emanuel.peter at oracle.com>
>>  - remove std::hash
>>  - remove unordered_map, add some comments for all_instances_size
>>  - Emanuel's reviews
>>  - Improve Value inferences of And, Or, Xor and implement gtest for general Value inferences
>
> Not sure if my review counts but I went through the changes again and it looks like all existing inference logic is covered by the more concise and also more powerful new logic.

@SirYwell Thanks very much for your review!
@eme64 I have just merged with master, could you test the patch again, please?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27618#issuecomment-3659549915

From asteiner at openjdk.org  Tue Dec 16 09:28:02 2025
From: asteiner at openjdk.org (Andreas Steiner)
Date: Tue, 16 Dec 2025 09:28:02 GMT
Subject: RFR: 8372348: Adjust some UL / JFR string deduplication output
 messages [v2]
In-Reply-To: <_pD8_vv2_v0M9KlqfxLhv0QT8Qynd0w1OFfpICgS7k8=.106bc0d3-810b-470e-954b-26d1f603ffcb@github.com>
References: <7-XRp229KFw3V2bFPMnaWaoPdF3ZCYVNuViEo2O7eUI=.e0247347-188b-44bf-935c-6b0186026fd3@github.com>
 <2r6k6Av9MTNmMxpbga6MJoUCu0vECsr7IDL6wAzJ_Ig=.c9106917-1635-4d3c-b6c4-f4c5f0659440@github.com>
 <kLaKX3lyoQshzjHXilycyq9_ixhaiQMy76zmavAX35M=.682f43b9-e72f-48ed-90a5-fcb84b3d3c90@github.com>
 <Ien8WqqsVLY--khvk8WkOeaSpaAKWcQ45x_5tCxQZTI=.f0f9bb58-ef10-4c78-8746-49f5a7bfa803@github.com>
 <pNpdqbYFfgvrIkYZRCFEldiccxVqyq1vQB3hxnIs1Nk=.b7f28843-7e09-477f-9a0f-63bb3314b9f8@github.com>
 <FusqPTtOicwQ5QdQr8M2FJmblmUH46F-Rbsh6HBXi8w=.7d5a54eb-cfab-4c6a-8e26-1ab9535e6427@github.com>
 <_pD8_vv2_v0M9KlqfxLhv0QT8Qynd0w1OFfpICgS7k8=.106bc0d3-810b-470e-954b-26d1f603ffcb@github.com>
Message-ID: <Ib4Xs5UvRLYmjQ9pKpUtDbdbv_UZK9F2FcowlpBIMQU=.dfe630bb-19e2-43e4-b23e-0fb53f87d461@github.com>

On Mon, 15 Dec 2025 14:55:53 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> ` total avg of  deduped / new unknown bytes ` maybe ? That mentions what is used for the computation .
>> We could also print the values of  total deduped and new to make it more clear .
>
>> Adding total will be helpful already, but why are not the numbers printed on which the avg is based? Because otherwise you don't get an impression what the percentage mean.
> 
> I added some more output, please check .

I would appreciate the additional output to get a better understanding of the provided total avg.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28455#discussion_r2622478208

From epeter at openjdk.org  Tue Dec 16 09:37:18 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 16 Dec 2025 09:37:18 GMT
Subject: RFR: 8367341: C2: apply KnownBits and unsigned bounds to And / Or
 operations [v8]
In-Reply-To: <xMDLn1jlE5MhYML12NNGMf8aCQ4ah6ztsvFwbXH-Qv4=.b798d07b-3ed7-403a-8da0-0b1e540c903a@github.com>
References: <SqHEdFScmcQRe6wTaITLemzMzWD6jxGWCRWzHNepqjE=.ab7e7553-3a43-4b43-abc3-338d6493a35d@github.com>
 <xMDLn1jlE5MhYML12NNGMf8aCQ4ah6ztsvFwbXH-Qv4=.b798d07b-3ed7-403a-8da0-0b1e540c903a@github.com>
Message-ID: <RbRMycvT-S5osTtd9eWWvdkLGcXol2jF4MejA8oa-7o=.5f557c93-6106-431c-8c08-b0413356cc32@github.com>

On Tue, 16 Dec 2025 09:19:06 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This PR improves the implementation of `AndNode/OrNode/XorNode::Value` by taking advantages of the additional information in `TypeInt`. The implementation is pretty straightforward. A clever trick is that by analyzing the negative and positive ranges of a `TypeInt` separately, we have better info for the leading bits. I also implement gtest unit tests to verify the correctness and monotonicity of the inference functions.
>> 
>> Please take a look and leave your reviews, thanks a lot.
>
> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
> 
>  - Merge branch 'master' into andorxor
>  - Merge branch 'master' into andorxor
>  - Merge branch 'master' into andorxor
>  - Merge branch 'master' into andorxor
>  - Add assertion for the helper in CTPComparator
>    
>    Co-authored-by: Emanuel Peter <emanuel.peter at oracle.com>
>  - remove std::hash
>  - remove unordered_map, add some comments for all_instances_size
>  - Emanuel's reviews
>  - Improve Value inferences of And, Or, Xor and implement gtest for general Value inferences

Testing launched ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27618#issuecomment-3659620884

From tschatzl at openjdk.org  Tue Dec 16 10:11:24 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 16 Dec 2025 10:11:24 GMT
Subject: RFR: 8372754: Add wrapper for <cstdlib> [v2]
In-Reply-To: <cphviQVoQ7e5Qsupc5SAHZk9fSW-CTU6l1M5bxHNSNo=.e03193a9-8674-48b1-9d74-210a93c0e381@github.com>
References: <7QNN5i5DkBH7c9YXWh5U40JwTKmiBPJSAcLm-f1HE_8=.9b18027e-8274-46d1-ba2d-e70514c40fc3@github.com>
 <cphviQVoQ7e5Qsupc5SAHZk9fSW-CTU6l1M5bxHNSNo=.e03193a9-8674-48b1-9d74-210a93c0e381@github.com>
Message-ID: <mX5HpK_uECRN_mnmu4yu1H1GT_Yfp24JhxS_tkXeYCg=.00784e86-4701-43c3-b46c-df7a1df5a262@github.com>

On Mon, 15 Dec 2025 01:37:11 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change that adds a HotSpot wrapper for <cstdlib>.  It also
>> includes the forbidden function declarations for functions declared there,
>> moving them from forbiddenFunctions.hpp and friends.
>> 
>> The AIX-specific workaround for its macro-based renaming of malloc/calloc is
>> also moved to this wrapper, so there is a single location for it. Also cleaned
>> it up a bit, based on further investigation of the problem.
>> 
>> Also changed uses of <cstdlib> and <stdlib.h> to include the wrapper instead.
>> There are still a couple of includes of <stdlib.h> in the hotspot directory,
>> because they can't use the hotspot wrapper: os/windows/include/jvm_md.h and
>> share/adlc/adlc.hpp.  I looked at removing the one in windows jvm_md.h, but
>> there are a lot of dependencies on that implicit include in non-HotSpot code.
>> 
>> While updating to use the wrapper, I also did a small amount of include
>> cleanup here and there.  The changes around immediate_aarch64.hpp are perhaps
>> a little less trivial than I should have made here.
>> 
>> Testing: mach5 tier1
>> 
>> This should probably be retested by aix port maintainer folks, although I
>> don't think I made any relevant changes since you last tested it.
>> 
>> This change also resolves:
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into wrap-cstdlib
>  - add wrapper for <cstdlib>

Marked as reviewed by tschatzl (Reviewer).

src/hotspot/os/aix/libperfstat_aix.hpp line 36:

> 34: 
> 35: #include "cppstdlib/cstdlib.hpp"
> 36: #include <sys/types.h>

Maybe add a newline between the double-quoted and the angle-bracketed includes similar to other files.

-------------

PR Review: https://git.openjdk.org/jdk/pull/28562#pullrequestreview-3582289172
PR Review Comment: https://git.openjdk.org/jdk/pull/28562#discussion_r2622615151

From bkilambi at openjdk.org  Tue Dec 16 10:23:32 2025
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Tue, 16 Dec 2025 10:23:32 GMT
Subject: RFR: 8371711: AArch64: SVE intrinsics for Arrays.sort methods
 (int, float)
In-Reply-To: <KFgDNk__y8ot5_XNPCAiii1KMYHs_8T4sBkHSFUnhNY=.511f4a3b-3e59-4af6-bfac-c94bc10485ba@github.com>
References: <8i4snpt_829luK8hB9U6qgJ833kiNK1hPe7IckfaoJ8=.5cd666c6-b4c9-4ff5-bb39-d1243afd61f0@github.com>
 <KFgDNk__y8ot5_XNPCAiii1KMYHs_8T4sBkHSFUnhNY=.511f4a3b-3e59-4af6-bfac-c94bc10485ba@github.com>
Message-ID: <euCUSp3YAz3EGfwjJUmNQFE072k0Ykpw8V0q44c4nKw=.191f04cd-f710-45de-9df5-b019ed1c678e@github.com>

On Tue, 9 Dec 2025 00:01:26 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> 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?

@iwanowww  This sounds good. I can wait until you post your PR and then I can start working on updating this patch based on that. Thanks a lot!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28675#issuecomment-3659808712

From aph at openjdk.org  Tue Dec 16 11:03:05 2025
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 16 Dec 2025 11:03:05 GMT
Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() [v6]
In-Reply-To: <yhtSX7dHSCAnDVCm5UX_9Pfx0-P3FnydZOAbRt7-6Ow=.253c5dbb-c7d1-4543-94cc-cbd1a05d5c0e@github.com>
References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com>
 <CEvEqPtlTMiv7fX1G_spyCpyl8afEZn4McrzIBd5GRY=.d233254e-3626-4044-a3e1-c82bcbd55e45@github.com>
 <6E4yPY9dRcWGBT-vPPq7bOm1NfLdvIfLdecg34f6Tes=.11b0a7c1-798f-4ed2-a521-26059bc0ba5b@github.com>
 <yRkEv29KF1vLIy4V5nKDgQF7CfvVjUjfssdzZ0PccjA=.00171af8-a1aa-401b-9341-a80a6fb4e22e@github.com>
 <yhtSX7dHSCAnDVCm5UX_9Pfx0-P3FnydZOAbRt7-6Ow=.253c5dbb-c7d1-4543-94cc-cbd1a05d5c0e@github.com>
Message-ID: <TEoePwnDJIw1BQ6kk9-9ggawyVL3luz0rgDALvnN-5Q=.0dfa7cd9-3298-49a7-965d-01d4365986c0@github.com>

On Mon, 15 Dec 2025 22:58:07 GMT, Dean Long <dlong at openjdk.org> wrote:

> But maybe there is still a race before the NoSafepointVerifier in resolve_helper if two threads are trying to resolve the same call site and they allow a safepoint during find_callee_info.

I can't really understand why that might matter. I do, though see a possible problem when two threads resolve the same call site. They both lock on`CompiledICLocker`, one wins the race, resolves the site. The other loses, exits, but it sees the patched call site with no intervening ISB.  An ISB in `CompiledICLocker::~CompiledICLocker() ` would fix that.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26638#issuecomment-3659955321

From ayang at openjdk.org  Tue Dec 16 11:10:13 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 16 Dec 2025 11:10:13 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v22]
In-Reply-To: <cGMcm5aJjVSTOvlxIDAuU2wvnRvmrgAN685V4htwscU=.7d504563-b632-4c8c-aa0f-d161a5c5af10@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <rAPcRMkxD0uoJTzadbMR7eui7ixfiVHCKy8JCvS5TPc=.6307f4fd-e333-41c8-97f2-81971974eb93@github.com>
 <C2nKyRSBdqEqIK0I3bEP1X4PM1K3Gb3HhPaxqgJeIS8=.62ffb736-16a7-4da9-8d11-1c147dfb40a1@github.com>
 <g0INjxl-T0NTw_GN4GkKl-d-gwjKQAmQs7_YB1R_LWo=.eaaddff1-531c-4ebc-956c-b091676be405@github.com>
 <ET-MhWMYi6ja-ge-H209Fy9ZHkMPL-6ZaPEeegAAraM=.2f40c659-5c3c-486b-adea-66488fd6050d@github.com>
 <ORGz3sV06WeoIr4xH5NXriQLmGaA5es8wXyKhn0ddJ4=.677f4c8c-7e6b-4ccb-92b0-2b34b2bf329b@github.com>
 <cGMcm5aJjVSTOvlxIDAuU2wvnRvmrgAN685V4htwscU=.7d504563-b632-4c8c-aa0f-d161a5c5af10@github.com>
Message-ID: <xd1lCeILblTqeUfjuI0_A5e0l6mSVp4mnU94xix_Xrg=.c7255661-6dfb-4e89-86f4-2eed5a687697@github.com>

On Tue, 16 Dec 2025 07:09:55 GMT, SilenceZheng66 <duke at openjdk.org> wrote:

> Since my JVM's version is 25.191-b12 ...

I thought it means JDK25... My apologies.

>  Now I just curious about is it a bug when people use configurations as following and could raise full GC problems and heap can't expand.

I think that behavior is definitely undesirable. Whether or not it's a bug can be subjective.

I believe this behavior has been fixed/improved in later releases of JDK. At least the following two tickets are relevant.

JDK-8328744: Parallel: Parallel GC throws OOM before heap is fully expanded
Use max old-gen capacity to decide whether to start a "proactive" full-gc, instead of young-gc.

JDK-8338977: Parallel: Improve heap resizing heuristics 
In `PSParallelCompact::summary_phase`, old-gen is expanded via `ParallelScavengeHeap::heap()->old_gen()->try_expand_till_size` even with `-XX:-UseAdaptiveSizePolicy`.

I wonder if you can try your benchmark(s) with newer JDKs and check if the problem persists.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2622829786

From sspitsyn at openjdk.org  Tue Dec 16 11:26:34 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 16 Dec 2025 11:26:34 GMT
Subject: RFR: 6960970: Debugger very slow during stepping [v10]
In-Reply-To: <gFgkgW9blz_tD337KoxIvOECPeJaQ-LfhifJiaosDjw=.11fda5cd-baae-48bb-a12e-4018eeb5cd15@github.com>
References: <gFgkgW9blz_tD337KoxIvOECPeJaQ-LfhifJiaosDjw=.11fda5cd-baae-48bb-a12e-4018eeb5cd15@github.com>
Message-ID: <rDo9gCaD2-85m2TVwyfBv8PuvUeKpZHqulm66KkNAck=.52321d24-0f17-4524-bcd1-877a72c1315b@github.com>

> This change fixes a long standing performance issue related to the debugger single stepping that is using JVMTI `FramePop` events as a part of step over handling. The performance issue is that the target thread continues its execution in very slow `interp-only` mode in a context of frame marked for `FramePop` notification with the JVMTI `NotifyFramePop`. It includes other method calls recursively upon a return from the frame.
> 
> This fix is to avoid enforcing the `interp-only` execution mode for threads when `FramePop` events are enabled with the JVMTI `SetEventNotificationMode()`. Instead, the target frame has been deoptimized and kept interpreted by disabling `OSR` optimization by the function `InterpreterRuntime::frequency_counter_overflow_inner()`. (Big thanks to @fisk for this suggestion!) Additionally, some tweaks are applied in several places where the `java_thread->is_interp_only_mode()` is checked.
> The other details will be provided in the first PR request comment.
> 
> Testing:
>  - test `serviceability/jvmti/vthread/ThreadStateTest` was updated to provide some extra test coverage
>  - submitted mach5 tiers 1-6

Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - 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
 - cleanup: removed an old code fragment in frame.cpp
 - ... and 1 more: https://git.openjdk.org/jdk/compare/53ebcdbd...8e0164c2

-------------

Changes: https://git.openjdk.org/jdk/pull/28407/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28407&range=09
  Stats: 292 lines in 22 files changed: 194 ins; 61 del; 37 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 thartmann at openjdk.org  Tue Dec 16 11:28:22 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 16 Dec 2025 11:28:22 GMT
Subject: RFR: 8372701: Randomized profile counters [v5]
In-Reply-To: <3esDvJBbg-YIuvQm_Kh0CEtu3p9o9QrJr5ir0KUIoZI=.7fd51056-4744-45a7-8b85-0b3d17f4ab77@github.com>
References: <jKjmIONZcytzVjS4absOwOLv_QOF9qhIJifYhN6JyP4=.dceced94-bc29-43e6-9062-8dc77c2a6133@github.com>
 <1nJnov3s2hhiLuO0W2FNcSAiGu5eEjZauQxfzd5YXKw=.8c593111-294a-4df7-8ce0-322871a801f3@github.com>
 <BxQvwFp-zorwxRiwNksDT0Bp-PmKZuxbXnc4nHaXH8Y=.db07c559-4d8c-41e9-a2a3-e8b68b7e1a29@github.com>
 <3esDvJBbg-YIuvQm_Kh0CEtu3p9o9QrJr5ir0KUIoZI=.7fd51056-4744-45a7-8b85-0b3d17f4ab77@github.com>
Message-ID: <VtNk3YUwsBvQxlhpy1VRLTd0ou-WpoQLhypZlpUkpW4=.2015cfd6-1484-4447-986c-4901121e90a6@github.com>

On Mon, 15 Dec 2025 15:49:57 GMT, Andrew Haley <aph at openjdk.org> wrote:

> I submitted benchmarks and will report back once it finished.

Unfortunately, I see various regressions. Here are the most severe ones:

Benchmark, Linux aarch64, Linux x64, MacOSX aarch64, Windows x64
DaCapo-jython-large, -23.96%, -12.88%, -12.12%, -11.40%
SPECjbb2005-G1, -2.13%, -9.80%, -1.60%, -0.78%
Crypto-AESBench_decrypt, -4.86%, -6.48%, -3.61%, -8.33
Crypto-AESGCMBench.decrypt, -2.19%, -2.94%, -0.55%, -3.68%
Crypto-AESGCMBench.encrypt, -2.79%, -2.67%, -1.60%, -1.82%


I currently don't have time to look into this but hopefully you can reproduce on your end.

> Can you please run benchmarks with -XX:+UnlockExperimentalVMOptions -XX:ProfileCaptureRatio=64? Thanks.

Missed that, let me add a run with these settings.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28541#issuecomment-3660054383
PR Comment: https://git.openjdk.org/jdk/pull/28541#issuecomment-3660056989

From dholmes at openjdk.org  Tue Dec 16 11:33:53 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 16 Dec 2025 11:33:53 GMT
Subject: RFR: 8369515: Deadlock between JVMTI and JNI
 ReleasePrimitiveArrayCritical
In-Reply-To: <f6nwwrKfVBBHTfg3g4YxqGwv0m174bzQV4m9jGQIcgg=.37c78e76-7fcf-4148-903a-8e970f8a1593@github.com>
References: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
 <81N6cE39iTwOjsu2Jt1fU3ypFW7S6AjJw5Ufsgv2Xqs=.af055769-cc2b-4169-b02d-cc65b246427e@github.com>
 <f6nwwrKfVBBHTfg3g4YxqGwv0m174bzQV4m9jGQIcgg=.37c78e76-7fcf-4148-903a-8e970f8a1593@github.com>
Message-ID: <xgjrAGLu6eiATWKmV8tu2lX83d91rHuOnQBTRs8Ki2M=.926db2f0-6a51-408a-820c-d140487cf1b1@github.com>

On Tue, 16 Dec 2025 08:29:32 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> > > I do think that also entering a critical region is problematic if it is nested.
> > 
> > 
> > Isn't nesting critical regions against the rules of using critical regions?
> 
> For arrays it's explicitly allowed in the specification. There's also an example how to do it properly :) I'll see if I can implement a reproducer.

Right I see that. It states:
> Inside a critical region, native code must not call other JNI functions, ...

but then explicitly allows the critical functions themselves to be an exception. Okay.

So isn't a fix for this simply to skip blocking as per your PR:

 if (is_obj_deopt_suspend() && !in_critical()) {

irrespective of nesting and without any need for any of the changes I proposed?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28779#issuecomment-3660076633

From jbhateja at openjdk.org  Tue Dec 16 11:42:30 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 16 Dec 2025 11:42:30 GMT
Subject: RFR: 8373480: Optimize multiplication by constant multiplier using
 LEA instructions [v2]
In-Reply-To: <uo_ugfdLTrURHDpmWF4Xfh2Hspum8XDJNYsUjhAEc1I=.131ef8cd-e2f3-4d8c-981c-a701452cb264@github.com>
References: <uo_ugfdLTrURHDpmWF4Xfh2Hspum8XDJNYsUjhAEc1I=.131ef8cd-e2f3-4d8c-981c-a701452cb264@github.com>
Message-ID: <fjmJzvDzuExJqu9qB3MfDlYFlYy5tmLveaW3dSkMkFM=.a7ead3e4-c679-4ded-b287-9738860c4ba0@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 incrementally with one additional commit since the last revision:

  Using test-framework for JTREG test generation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28759/files
  - new: https://git.openjdk.org/jdk/pull/28759/files/b82aa90f..7489c7fe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28759&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28759&range=00-01

  Stats: 344 lines in 1 file changed: 75 ins; 250 del; 19 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 dholmes at openjdk.org  Tue Dec 16 11:44:54 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 16 Dec 2025 11:44:54 GMT
Subject: RFR: 8373654: Tests in sources/ should only run once [v2]
In-Reply-To: <D1mbKJVySY5Ti56tK6E75rSEjDt35Kuba6RId-F-POE=.ebd771cf-05e8-486e-851f-f782a0b29a88@github.com>
References: <L0u3UjIJt8pEZdt8WfgVU8oGYUsCzeY6c55UPsm_Cus=.f55a3b5c-0104-45bd-8d84-9f26c7a38c03@github.com>
 <zSxW1N3vIuGI0x_MqpwzylBv68PkLNucOMbI1xZOKb4=.a0a9dc06-084b-4dcc-ba05-4da6050d5608@github.com>
 <D1mbKJVySY5Ti56tK6E75rSEjDt35Kuba6RId-F-POE=.ebd771cf-05e8-486e-851f-f782a0b29a88@github.com>
Message-ID: <RTbTpDIeY9Kqd2ch_jpNF2Lzs_hIK8LJF8NS73I_MzA=.53a8498d-4bb6-42af-97b8-ca15148cb81a@github.com>

On Tue, 16 Dec 2025 09:02:20 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Relax platform restriction
>>   Add TestIncludesAreSorted
>
> test/hotspot/jtreg/sources/TestIncludesAreSorted.java line 28:
> 
>> 26:  * @bug 8343802
>> 27:  * @comment Only need to run this once, in tier1.
>> 28:  * @requires vm.flagless & vm.debug == true
> 
> Would that also work?
> 
> Suggestion:
> 
>  * @comment Only need to run this once, in tier1
>  * @requires vm.flagless & vm.debug

Probably - certainly a number of tests have it, though the vast majority have explicit checks against true/false. For consistency I will try it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28818#discussion_r2622935270

From jbhateja at openjdk.org  Tue Dec 16 11:47:33 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 16 Dec 2025 11:47:33 GMT
Subject: RFR: 8373480: Optimize multiplication by constant multiplier using
 LEA instructions [v3]
In-Reply-To: <uo_ugfdLTrURHDpmWF4Xfh2Hspum8XDJNYsUjhAEc1I=.131ef8cd-e2f3-4d8c-981c-a701452cb264@github.com>
References: <uo_ugfdLTrURHDpmWF4Xfh2Hspum8XDJNYsUjhAEc1I=.131ef8cd-e2f3-4d8c-981c-a701452cb264@github.com>
Message-ID: <Fl2dxHDLEw-f9Jc-t5uobIoXoS4-HeO1YH1cOgCba9s=.fe7e8a4a-00c7-4ade-97a1-38f8590d93bd@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 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:

  Using template-framework for JTREG test generation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28759/files
  - new: https://git.openjdk.org/jdk/pull/28759/files/7489c7fe..d792c49b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28759&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28759&range=01-02

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 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 dholmes at openjdk.org  Tue Dec 16 11:53:11 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 16 Dec 2025 11:53:11 GMT
Subject: RFR: 8373654: Tests in sources/ should only run once [v3]
In-Reply-To: <L0u3UjIJt8pEZdt8WfgVU8oGYUsCzeY6c55UPsm_Cus=.f55a3b5c-0104-45bd-8d84-9f26c7a38c03@github.com>
References: <L0u3UjIJt8pEZdt8WfgVU8oGYUsCzeY6c55UPsm_Cus=.f55a3b5c-0104-45bd-8d84-9f26c7a38c03@github.com>
Message-ID: <yo2TFyn3QFpgPffZs7RTtrzlkyfNHmlQ2ikBo2L8BME=.74030b31-36fc-4bf7-b490-d97be9b81c88@github.com>

> This test is checking for backsliding on the use of NULL in the hotspot source files. The test only needs to be run once per change but it is defined as a regular tier1 test which then gets run for each os-arch combination, plus product and debug, and then again with a bunch of flags in tier3. This is just a waste of resources. At a minimum we should make the test flagless so that it doesn't run in tier3, but we can also restrict it to a single platform.
> 
> Before the change the test ran 27 times in tier1-3 in our CI. After it runs once. 
> 
> 
> EDIT: Updated to include both tests in sources/
> 
> Thanks

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  reviewer feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28818/files
  - new: https://git.openjdk.org/jdk/pull/28818/files/d06591b5..8fb98814

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28818&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28818&range=01-02

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28818.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28818/head:pull/28818

PR: https://git.openjdk.org/jdk/pull/28818

From shade at openjdk.org  Tue Dec 16 11:53:12 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 16 Dec 2025 11:53:12 GMT
Subject: RFR: 8373654: Tests in sources/ should only run once [v3]
In-Reply-To: <yo2TFyn3QFpgPffZs7RTtrzlkyfNHmlQ2ikBo2L8BME=.74030b31-36fc-4bf7-b490-d97be9b81c88@github.com>
References: <L0u3UjIJt8pEZdt8WfgVU8oGYUsCzeY6c55UPsm_Cus=.f55a3b5c-0104-45bd-8d84-9f26c7a38c03@github.com>
 <yo2TFyn3QFpgPffZs7RTtrzlkyfNHmlQ2ikBo2L8BME=.74030b31-36fc-4bf7-b490-d97be9b81c88@github.com>
Message-ID: <_LbXt3s8MqKGYphmJKuqVAWDIN0k5I-bJEKxZe2Ek_A=.01286197-49d5-4874-9d11-22a60db50386@github.com>

On Tue, 16 Dec 2025 11:50:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This test is checking for backsliding on the use of NULL in the hotspot source files. The test only needs to be run once per change but it is defined as a regular tier1 test which then gets run for each os-arch combination, plus product and debug, and then again with a bunch of flags in tier3. This is just a waste of resources. At a minimum we should make the test flagless so that it doesn't run in tier3, but we can also restrict it to a single platform.
>> 
>> Before the change the test ran 27 times in tier1-3 in our CI. After it runs once. 
>> 
>> 
>> EDIT: Updated to include both tests in sources/
>> 
>> Thanks
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reviewer feedback

Marked as reviewed by shade (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28818#pullrequestreview-3582695237

From dholmes at openjdk.org  Tue Dec 16 11:53:14 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 16 Dec 2025 11:53:14 GMT
Subject: RFR: 8373654: Tests in sources/ should only run once [v2]
In-Reply-To: <D1mbKJVySY5Ti56tK6E75rSEjDt35Kuba6RId-F-POE=.ebd771cf-05e8-486e-851f-f782a0b29a88@github.com>
References: <L0u3UjIJt8pEZdt8WfgVU8oGYUsCzeY6c55UPsm_Cus=.f55a3b5c-0104-45bd-8d84-9f26c7a38c03@github.com>
 <zSxW1N3vIuGI0x_MqpwzylBv68PkLNucOMbI1xZOKb4=.a0a9dc06-084b-4dcc-ba05-4da6050d5608@github.com>
 <D1mbKJVySY5Ti56tK6E75rSEjDt35Kuba6RId-F-POE=.ebd771cf-05e8-486e-851f-f782a0b29a88@github.com>
Message-ID: <wXkHwjKLFejPinsDjv9zHA7X4S-iiWVEajPGEQvpL-w=.be51d883-fa4b-45ee-b1c9-b28d89a1715d@github.com>

On Tue, 16 Dec 2025 09:02:31 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Relax platform restriction
>>   Add TestIncludesAreSorted
>
> Looks reasonable to me, with only stylistic nits.

Thanks for the review @shipilev !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28818#issuecomment-3660132152

From shade at openjdk.org  Tue Dec 16 11:55:57 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 16 Dec 2025 11:55:57 GMT
Subject: RFR: 8373654: Tests in sources/ should only run once [v3]
In-Reply-To: <yo2TFyn3QFpgPffZs7RTtrzlkyfNHmlQ2ikBo2L8BME=.74030b31-36fc-4bf7-b490-d97be9b81c88@github.com>
References: <L0u3UjIJt8pEZdt8WfgVU8oGYUsCzeY6c55UPsm_Cus=.f55a3b5c-0104-45bd-8d84-9f26c7a38c03@github.com>
 <yo2TFyn3QFpgPffZs7RTtrzlkyfNHmlQ2ikBo2L8BME=.74030b31-36fc-4bf7-b490-d97be9b81c88@github.com>
Message-ID: <kyCbcThIL9CJIDAKkXqMg-ihUvgczYaGVE_BZdCa3Bo=.956bed3b-b109-4d73-a8a2-1dc82d109aed@github.com>

On Tue, 16 Dec 2025 11:53:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This test is checking for backsliding on the use of NULL in the hotspot source files. The test only needs to be run once per change but it is defined as a regular tier1 test which then gets run for each os-arch combination, plus product and debug, and then again with a bunch of flags in tier3. This is just a waste of resources. At a minimum we should make the test flagless so that it doesn't run in tier3, but we can also restrict it to a single platform.
>> 
>> Before the change the test ran 27 times in tier1-3 in our CI. After it runs once. 
>> 
>> 
>> EDIT: Updated to include both tests in sources/
>> 
>> Thanks
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reviewer feedback

Important bit: Hotspot tests are running with fastdebug in GHA (job: `hs/tier1 common`), so the tests still run as PR check.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28818#issuecomment-3660150039

From jbhateja at openjdk.org  Tue Dec 16 11:56:40 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 16 Dec 2025 11:56:40 GMT
Subject: RFR: 8373480: Optimize multiplication by constant multiplier using
 LEA instructions [v4]
In-Reply-To: <uo_ugfdLTrURHDpmWF4Xfh2Hspum8XDJNYsUjhAEc1I=.131ef8cd-e2f3-4d8c-981c-a701452cb264@github.com>
References: <uo_ugfdLTrURHDpmWF4Xfh2Hspum8XDJNYsUjhAEc1I=.131ef8cd-e2f3-4d8c-981c-a701452cb264@github.com>
Message-ID: <lmoVQLIj0BwKp21ubCgFwHx-qtplZ4Ii_Wl52Oap-SQ=.7426c1b9-528a-4a96-8762-fd20648486e0@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 incrementally with one additional commit since the last revision:

  Minor cleanup in Template-Framework test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28759/files
  - new: https://git.openjdk.org/jdk/pull/28759/files/d792c49b..66a28502

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28759&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28759&range=02-03

  Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 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 rrich at openjdk.org  Tue Dec 16 13:01:50 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Tue, 16 Dec 2025 13:01:50 GMT
Subject: RFR: 8369515: Deadlock between JVMTI and JNI
 ReleasePrimitiveArrayCritical
In-Reply-To: <xgjrAGLu6eiATWKmV8tu2lX83d91rHuOnQBTRs8Ki2M=.926db2f0-6a51-408a-820c-d140487cf1b1@github.com>
References: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
 <81N6cE39iTwOjsu2Jt1fU3ypFW7S6AjJw5Ufsgv2Xqs=.af055769-cc2b-4169-b02d-cc65b246427e@github.com>
 <f6nwwrKfVBBHTfg3g4YxqGwv0m174bzQV4m9jGQIcgg=.37c78e76-7fcf-4148-903a-8e970f8a1593@github.com>
 <xgjrAGLu6eiATWKmV8tu2lX83d91rHuOnQBTRs8Ki2M=.926db2f0-6a51-408a-820c-d140487cf1b1@github.com>
Message-ID: <mVZqbJRdBQ2CXZ4pbj1DUb6nGzy75dfrINRw1CtoYAA=.823d6b0f-5360-4a1f-bf7c-60402da385b9@github.com>

On Tue, 16 Dec 2025 11:31:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

> So isn't a fix for this simply to skip blocking as per your PR:
> 
> ```
>  if (is_obj_deopt_suspend() && !in_critical()) {
> ```
> 
> irrespective of nesting and without any need for any of the changes I proposed?

Yes, I currently think so.
Testing so far is good. Don't have a reproducer yet for the deadlock.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28779#issuecomment-3660407119

From bkilambi at openjdk.org  Tue Dec 16 13:49:03 2025
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Tue, 16 Dec 2025 13:49:03 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v7]
In-Reply-To: <lho5QXHxy87rtS6SRdOizf-Qtgdl7hTyTmvi2M1SGpk=.25bc3ffb-1390-4ab4-bcfe-28d215d70099@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <H1M8_FtGtYl2jww_n3OE5o3G8SFCe8TMl-XgtRA6Krg=.fb56cb81-2890-47c5-b35b-b2d730e3e71f@github.com>
 <lho5QXHxy87rtS6SRdOizf-Qtgdl7hTyTmvi2M1SGpk=.25bc3ffb-1390-4ab4-bcfe-28d215d70099@github.com>
Message-ID: <zNHLhur1oCstOsckD8RkiLBlL60H-n2q8_1Ikz6g5Gk=.c1b33e99-16c6-4f8e-855d-a862bf04f9f3@github.com>

On Thu, 11 Dec 2025 06:08:58 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>  I suggest creating a seperate PR for this ? You can either create a smaller standalone reproducer testcase or mention about the tests part of this PR.

Hi @jbhateja, thanks for the suggestion. Based on the comments here - https://bugs.openjdk.org/browse/JDK-8373574, is it ok if my fix (along with a regression test as suggested) be part of this PR?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3660602956

From iklam at openjdk.org  Tue Dec 16 14:50:53 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 16 Dec 2025 14:50:53 GMT
Subject: RFR: 8373800: Remove ScopedValueBindingsResolver
Message-ID: <SlF9UG1hEtDxTxkDwxzFdFDUSVYRQXdssqR9sdjcSkE=.3061bd47-e191-486b-a07f-9d44e3b8c80d@github.com>

The `ScopedValueBindingsResolver::ScopedValueBindingsResolver()` constructor is invoked the first time 
`JVM_FindScopedValueBindings` is invoked, and may cause unexpected behavior if the loading of the `ScopedValue$Carrier` class fails to load (due to OOM, etc).

With this PR, `ScopedValue$Carrier` is loaded during bootstrap with all other `vmClasses`.

-------------

Commit messages:
 - Remove ScopedValueBindingsResolver to avoid potential NULL pointer returned by SystemDictionary::resolve_or_fail()

Changes: https://git.openjdk.org/jdk/pull/28849/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28849&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373800
  Stats: 15 lines in 2 files changed: 3 ins; 11 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28849.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28849/head:pull/28849

PR: https://git.openjdk.org/jdk/pull/28849

From stefank at openjdk.org  Tue Dec 16 14:56:15 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 16 Dec 2025 14:56:15 GMT
Subject: RFR: 8373801: Adopt arraycopy OopCopyResult from the lworld branch
Message-ID: <vuovhgARk6krDotYQS-asHzFkm93v8hPWx4zLwT1xC0=.fd37e81f-8714-40b7-a099-58fc653cd2e4@github.com>

In the Valhalla project there's code to restrict nulls in object arrays. In the GC arraycopy barrier we there have to both do null checks in addition to the already existing cast checks. If one of these two failed the code needs to propagate this up through the callers to the code that asked to do the checks. There it will throw the suitable exception. Previously, it was enough to say success or failed, and a boolean was enough. Now we need three states. So the bool was replaced with an OopCopyResult enum.

See: https://github.com/openjdk/valhalla/pull/1792

I propose that we bring this over to the mainline to lower the diff between lworld and the openjdk/jdk.

-------------

Commit messages:
 - 8373801: Adopt arraycopy OopCopyResult from the lworld branch

Changes: https://git.openjdk.org/jdk/pull/28850/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28850&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373801
  Stats: 199 lines in 12 files changed: 70 ins; 13 del; 116 mod
  Patch: https://git.openjdk.org/jdk/pull/28850.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28850/head:pull/28850

PR: https://git.openjdk.org/jdk/pull/28850

From stefank at openjdk.org  Tue Dec 16 15:04:44 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 16 Dec 2025 15:04:44 GMT
Subject: RFR: 8373801: Adopt arraycopy OopCopyResult from the lworld branch
 [v2]
In-Reply-To: <vuovhgARk6krDotYQS-asHzFkm93v8hPWx4zLwT1xC0=.fd37e81f-8714-40b7-a099-58fc653cd2e4@github.com>
References: <vuovhgARk6krDotYQS-asHzFkm93v8hPWx4zLwT1xC0=.fd37e81f-8714-40b7-a099-58fc653cd2e4@github.com>
Message-ID: <xL27bPDF6Wl05dCXSghM4SdhK_iuMvlZW4J4LsvAJ9M=.6d00cb20-6661-470f-aa85-2846d56fede8@github.com>

> In the Valhalla project there's code to restrict nulls in object arrays. In the GC arraycopy barrier we there have to both do null checks in addition to the already existing cast checks. If one of these two failed the code needs to propagate this up through the callers to the code that asked to do the checks. There it will throw the suitable exception. Previously, it was enough to say success or failed, and a boolean was enough. Now we need three states. So the bool was replaced with an OopCopyResult enum.
> 
> See: https://github.com/openjdk/valhalla/pull/1792
> 
> I propose that we bring this over to the mainline to lower the diff between lworld and the openjdk/jdk.

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Remove throw NPE function

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28850/files
  - new: https://git.openjdk.org/jdk/pull/28850/files/41ff47bd..25c24e3d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28850&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28850&range=00-01

  Stats: 9 lines in 1 file changed: 0 ins; 9 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28850.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28850/head:pull/28850

PR: https://git.openjdk.org/jdk/pull/28850

From fparain at openjdk.org  Tue Dec 16 15:28:21 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 16 Dec 2025 15:28:21 GMT
Subject: RFR: 8373441: Remove DCmdFactory::_enabled [v2]
In-Reply-To: <AjjRyNcaMQOA-qcgilZVf5STbEMEmWAoBy3_BidW48k=.15d682e2-f8b6-4e4d-8fc2-f482e117b6b2@github.com>
References: <XE188S-C6EdTA2PRsdsQTi4Z550PW6DNpL3awvANazU=.1b0cd4d1-56cd-491a-b80c-8e2bafcc78ca@github.com>
 <AjjRyNcaMQOA-qcgilZVf5STbEMEmWAoBy3_BidW48k=.15d682e2-f8b6-4e4d-8fc2-f482e117b6b2@github.com>
Message-ID: <_vX0iZx2pk5puYThVOlJ3CL8Cv2fketux6_yupud8sc=.be19dfc6-f9ac-40fc-9b8e-5477ec093a5b@github.com>

On Fri, 12 Dec 2025 23:37:20 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The `DCmdFactory::_enabled` is always set to `true` and there doesn't seem to be a reason to set it to `false`.
>> 
>> This PR removes this field and simplified the creation of `DCmdFactory` objects.
>> 
>> The related `_hidden` field is also currently not used, but may be used in the future when deprecating DCmds, so we leave it unchanged.
>> 
>> Note that now `jmm_GetDiagnosticCommandInfo()` always set `dcmdInfo::enabled` to `true` to be compatible with Java code.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @kevinjwalls comments

The "enabled" capability probably fall in the category of features that were initially implemented to emulate JRockit jrcmd  tool but were finally not integrated in HotSpot (I remember another feature like that, to execute an user shell script when some events were triggered).
I don't remember having used or debugged this enable/disable feature. It looks that dead code that have been here for too long. Thank you for having found it and cleaned it up.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28794#issuecomment-3661116214

From fparain at openjdk.org  Tue Dec 16 15:40:25 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 16 Dec 2025 15:40:25 GMT
Subject: RFR: 8373441: Remove DCmdFactory::_enabled [v2]
In-Reply-To: <AjjRyNcaMQOA-qcgilZVf5STbEMEmWAoBy3_BidW48k=.15d682e2-f8b6-4e4d-8fc2-f482e117b6b2@github.com>
References: <XE188S-C6EdTA2PRsdsQTi4Z550PW6DNpL3awvANazU=.1b0cd4d1-56cd-491a-b80c-8e2bafcc78ca@github.com>
 <AjjRyNcaMQOA-qcgilZVf5STbEMEmWAoBy3_BidW48k=.15d682e2-f8b6-4e4d-8fc2-f482e117b6b2@github.com>
Message-ID: <PSey24d8vzoiGbajbdvA6NJC3rogA2JSJ094bFILFBU=.ae2b5f7b-ebbc-40b5-bf97-17719df9c40e@github.com>

On Fri, 12 Dec 2025 23:37:20 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The `DCmdFactory::_enabled` is always set to `true` and there doesn't seem to be a reason to set it to `false`.
>> 
>> This PR removes this field and simplified the creation of `DCmdFactory` objects.
>> 
>> The related `_hidden` field is also currently not used, but may be used in the future when deprecating DCmds, so we leave it unchanged.
>> 
>> Note that now `jmm_GetDiagnosticCommandInfo()` always set `dcmdInfo::enabled` to `true` to be compatible with Java code.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @kevinjwalls comments

LGTM

More context: https://openjdk.org/jeps/137

> 1-1 Overview
> 
> The diagnostic command framework is fully implemented in native code and relies on HotSpot's internal exception mechanism. The rationale for a pure native implementation is to be able to execute diagnostic commands even in critical situations like an out-of-memory condition. All diagnostic commands are registered in a single list, and two flags control the way a user can interact with them. The hidden flag prevents a diagnostic command from appearing in the list of available commands returned by the help command. However, it's still possible to get the detailed help message for a hidden command with the help <command name> syntax, but it requires knowing the name of the hidden command. The second flag is enabled and it controls whether a command can be invoked or not. When listed with the help commands, disabled commands appear with a [disabled] label in their descriptions. If the user tries to invoke a disabled command, an error message is returned and the command is not run. This
  error message can be customized on a per-command basis. The framework just provides these two flags with their semantics; it doesn't provide any policy or mechanism to set or modify these flags. These actions will be delegated to the JVM or specific diagnostic commands.

The diagnostic command framework was developed at the same time we had requests to implement "Commercial features", the "enabled" flag might also have been intended to guard those commercial features (gone now).

-------------

Marked as reviewed by fparain (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28794#pullrequestreview-3583740017
PR Comment: https://git.openjdk.org/jdk/pull/28794#issuecomment-3661165228

From jbhateja at openjdk.org  Tue Dec 16 15:48:06 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 16 Dec 2025 15:48:06 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v7]
In-Reply-To: <zNHLhur1oCstOsckD8RkiLBlL60H-n2q8_1Ikz6g5Gk=.c1b33e99-16c6-4f8e-855d-a862bf04f9f3@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <H1M8_FtGtYl2jww_n3OE5o3G8SFCe8TMl-XgtRA6Krg=.fb56cb81-2890-47c5-b35b-b2d730e3e71f@github.com>
 <lho5QXHxy87rtS6SRdOizf-Qtgdl7hTyTmvi2M1SGpk=.25bc3ffb-1390-4ab4-bcfe-28d215d70099@github.com>
 <zNHLhur1oCstOsckD8RkiLBlL60H-n2q8_1Ikz6g5Gk=.c1b33e99-16c6-4f8e-855d-a862bf04f9f3@github.com>
Message-ID: <BJEB4Rq-cl7ROsU-CK0Gx1dqfb4tiDbrSSu24RNWoj0=.a17b8afa-e5db-4920-9d26-76d506b4d5c6@github.com>

On Tue, 16 Dec 2025 13:45:58 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

> > I suggest creating a seperate PR for this ? You can either create a smaller standalone reproducer testcase or mention about the tests part of this PR.
> 
> Hi @jbhateja, thanks for the suggestion. Based on the comments here - https://bugs.openjdk.org/browse/JDK-8373574, is it ok if my fix (along with a regression test as suggested) be part of this PR?

Hi @Bhavana-Kilambi , As @TobiHartmann suggested we can included your patch with the PR.
Best Regards

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3661203155

From mbaesken at openjdk.org  Tue Dec 16 16:00:00 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 16 Dec 2025 16:00:00 GMT
Subject: RFR: 8372348: Adjust some UL / JFR string deduplication output
 messages [v2]
In-Reply-To: <Ib4Xs5UvRLYmjQ9pKpUtDbdbv_UZK9F2FcowlpBIMQU=.dfe630bb-19e2-43e4-b23e-0fb53f87d461@github.com>
References: <7-XRp229KFw3V2bFPMnaWaoPdF3ZCYVNuViEo2O7eUI=.e0247347-188b-44bf-935c-6b0186026fd3@github.com>
 <2r6k6Av9MTNmMxpbga6MJoUCu0vECsr7IDL6wAzJ_Ig=.c9106917-1635-4d3c-b6c4-f4c5f0659440@github.com>
 <kLaKX3lyoQshzjHXilycyq9_ixhaiQMy76zmavAX35M=.682f43b9-e72f-48ed-90a5-fcb84b3d3c90@github.com>
 <Ien8WqqsVLY--khvk8WkOeaSpaAKWcQ45x_5tCxQZTI=.f0f9bb58-ef10-4c78-8746-49f5a7bfa803@github.com>
 <pNpdqbYFfgvrIkYZRCFEldiccxVqyq1vQB3hxnIs1Nk=.b7f28843-7e09-477f-9a0f-63bb3314b9f8@github.com>
 <FusqPTtOicwQ5QdQr8M2FJmblmUH46F-Rbsh6HBXi8w=.7d5a54eb-cfab-4c6a-8e26-1ab9535e6427@github.com>
 <_pD8_vv2_v0M9KlqfxLhv0QT8Qynd0w1OFfpICgS7k8=.106bc0d3-810b-470e-954b-26d1f603ffcb@github.com>
 <Ib4Xs5UvRLYmjQ9pKpUtDbdbv_UZK9F2FcowlpBIMQU=.dfe630bb-19e2-43e4-b23e-0fb53f87d461@github.com>
Message-ID: <Qdndx8YCmXcdlDcQj5_inq50Y5l1nSDYA1wwk7zXEJc=.036ea09b-2620-4f0a-853b-bd6bdc142a7a@github.com>

On Tue, 16 Dec 2025 09:25:18 GMT, Andreas Steiner <asteiner at openjdk.org> wrote:

>>> Adding total will be helpful already, but why are not the numbers printed on which the avg is based? Because otherwise you don't get an impression what the percentage mean.
>> 
>> I added some more output, please check .
>
> I would appreciate the additional output to get a better understanding of the provided total avg.

So are you fine with the current change ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28455#discussion_r2623859308

From lmesnik at openjdk.org  Tue Dec 16 16:51:56 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 16 Dec 2025 16:51:56 GMT
Subject: RFR: 8343809: Add requires tag to mark tests that are incompatible
 with exploded image [v2]
In-Reply-To: <GtxujYXXFK6Y32kkijCc7XyGcMStlbQs7C9OM2QxmfM=.cbfe5c94-c9ab-4852-bad2-66deb4932723@github.com>
References: <GtxujYXXFK6Y32kkijCc7XyGcMStlbQs7C9OM2QxmfM=.cbfe5c94-c9ab-4852-bad2-66deb4932723@github.com>
Message-ID: <V5dtzsq1IEKP5CaYB9oZNq89cA1dXin4S5X5ZWbZ4GU=.25109012-74e7-43b5-ad65-b3080eba7511@github.com>

> 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

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28814/files
  - new: https://git.openjdk.org/jdk/pull/28814/files/9be434fa..591c1eb7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28814&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28814&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28814.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28814/head:pull/28814

PR: https://git.openjdk.org/jdk/pull/28814

From roland at openjdk.org  Tue Dec 16 16:54:02 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Tue, 16 Dec 2025 16:54:02 GMT
Subject: RFR: 8373591: C2: Fix the memory around some intrinsics nodes [v3]
In-Reply-To: <m1PRBAw6p8Zj-TEDSmv8P7B04xdHehUrBdNWDDwMeAo=.2a3b0a6f-31d4-43c8-85fa-5d25a59b7c62@github.com>
References: <xqPVnw7PtK7ch97NBoScQARyosgTZhsq8Jypd6h2Cyg=.61115100-f6f0-4f16-a01c-33e587b3ecaf@github.com>
 <m1PRBAw6p8Zj-TEDSmv8P7B04xdHehUrBdNWDDwMeAo=.2a3b0a6f-31d4-43c8-85fa-5d25a59b7c62@github.com>
Message-ID: <Ys-5qRQBZ4GudYkFpVe4HPahsmMbK31BOgPzkImz5RY=.e4e5a691-68f4-4dbf-8a35-187513c15861@github.com>

On Tue, 16 Dec 2025 06:23:12 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This is extracted from #28570 , there are 2 issues here:
>> 
>> - Some intrinsics nodes advertise incorrect `adr_type`. For example, `AryEqNode` reports `adr_type` being `TypeAryPtr::BYTES` (it inherits this from `StrIntrinsicNode`). This is incorrect, however, as it can accept `char[]` inputs, too. Another case is `VectorizedHashCodeNode`, which reports its `adr_type` being `TypePtr::BOTTOM`, but it actually extracts a memory slice and does not consume the whole memory.
>> - For nodes such as `StrInflatedCopyNode`, as they consume more than they produce, during scheduling, we need to compute anti-dependencies. This is not the case, so we should fix it by making the nodes kill all the memory they consume. This issue is often not present because these intrinsics are not exposed bare to general usage.
>> 
>> Please kindly review, thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use MemBar instead of widening the intrinsic memory

src/hotspot/share/opto/graphKit.cpp line 4210:

> 4208:     //  StoreC -> MemBar -> MergeMem -> compress_string -> MergeMem -> CharMem
> 4209:     //                               -------------------------------->
> 4210:     Node* all_mem = reset_memory();

This code sequence is used several times. Would it make sense to factor it out in its own method?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28789#discussion_r2624030618

From aph at redhat.com  Tue Dec 16 17:26:24 2025
From: aph at redhat.com (Andrew Haley)
Date: Tue, 16 Dec 2025 17:26:24 +0000
Subject: RFR: 8372701: Randomized profile counters [v5]
In-Reply-To: <VtNk3YUwsBvQxlhpy1VRLTd0ou-WpoQLhypZlpUkpW4=.2015cfd6-1484-4447-986c-4901121e90a6@github.com>
References: <jKjmIONZcytzVjS4absOwOLv_QOF9qhIJifYhN6JyP4=.dceced94-bc29-43e6-9062-8dc77c2a6133@github.com>
 <1nJnov3s2hhiLuO0W2FNcSAiGu5eEjZauQxfzd5YXKw=.8c593111-294a-4df7-8ce0-322871a801f3@github.com>
 <BxQvwFp-zorwxRiwNksDT0Bp-PmKZuxbXnc4nHaXH8Y=.db07c559-4d8c-41e9-a2a3-e8b68b7e1a29@github.com>
 <3esDvJBbg-YIuvQm_Kh0CEtu3p9o9QrJr5ir0KUIoZI=.7fd51056-4744-45a7-8b85-0b3d17f4ab77@github.com>
 <VtNk3YUwsBvQxlhpy1VRLTd0ou-WpoQLhypZlpUkpW4=.2015cfd6-1484-4447-986c-4901121e90a6@github.com>
Message-ID: <a788944a-8bf2-4787-8382-274324eb53be@redhat.com>

On 16/12/2025 11:28, Tobias Hartmann wrote:
> Unfortunately, I see various regressions. Here are the most severe ones:
> 
> Benchmark, Linux aarch64, Linux x64, MacOSX aarch64, Windows x64
> DaCapo-jython-large, -23.96%, -12.88%, -12.12%, -11.40%
> SPECjbb2005-G1, -2.13%, -9.80%, -1.60%, -0.78%
> Crypto-AESBench_decrypt, -4.86%, -6.48%, -3.61%, -8.33
> Crypto-AESGCMBench.decrypt, -2.19%, -2.94%, -0.55%, -3.68%
> Crypto-AESGCMBench.encrypt, -2.79%, -2.67%, -1.60%, -1.82%

Huummm, that must be a bug; there is some minor code reorganization, but 
nothing that should cause such a big change. I'll investigate.

 > Missed that, let me add a run with these settings.

I don't think there's any point until I've fixed whatever bug is causing 
the above regressions. Thanks.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From liach at openjdk.org  Tue Dec 16 18:54:34 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 16 Dec 2025 18:54:34 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting [v6]
In-Reply-To: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
Message-ID: <uqj0bUkdXgXgqfHQZQoYNd57Civ4eZA_J5ijXvjxBXw=.9ad57214-28a8-4431-bef5-b54c5b3a2377@github.com>

> 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 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:

 - Recommended test tweaks
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting
 - Jorn review
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting
 - bracket styles
 - Doc tweaks
 - Essay
 - Spurious change
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting
 - ... and 4 more: https://git.openjdk.org/jdk/compare/57f00286...567e8925

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28540/files
  - new: https://git.openjdk.org/jdk/pull/28540/files/b20b7f5b..567e8925

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28540&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28540&range=04-05

  Stats: 21935 lines in 436 files changed: 14170 ins; 4911 del; 2854 mod
  Patch: https://git.openjdk.org/jdk/pull/28540.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28540/head:pull/28540

PR: https://git.openjdk.org/jdk/pull/28540

From wkemper at openjdk.org  Tue Dec 16 19:43:49 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 16 Dec 2025 19:43:49 GMT
Subject: RFR: 8373203: Genshen: Non-strong reference leak in old gen [v2]
In-Reply-To: <JaJt39rlIHDKUiyQmDuh0uSyVslFVLKisMXo0r2gROk=.1056f4b4-441f-4ed2-9e7f-e81cbaca272c@github.com>
References: <JaJt39rlIHDKUiyQmDuh0uSyVslFVLKisMXo0r2gROk=.1056f4b4-441f-4ed2-9e7f-e81cbaca272c@github.com>
Message-ID: <IGAZsP42Is3XVeP1KT8A9nZOFCKk7kMYgnri4MrDPB0=.7c05c4b0-da90-4e2c-a0ac-42f0d0036c54@github.com>

> The generational mode for Shenandoah will collect _referents_ for the generation being collected. For example, if we have a young reference pointing to an old referent, that young reference will be processed after we finish marking the old generation. This presents a problem for discovery.
>   
> When the young mark _encounters_ a young reference with an old referent, it cannot _discover_ it because old marking hasn't finished. However, if it does not discover it, the old referent will be strongly marked. This, in turn, will prevent the old generation from clearing the referent (if it even reaches it again during old marking).
>   
> To solve this, we let young reference processing discover the old reference by having it use the old generation reference processor to do so. This means the old reference processor can have a discovered list that contains young weak references. If any of these young references reside in a region that is collected, old reference processing will crash when it processes such a reference. Therefore, we add a method `heal_discovered_lists` to traverse the discovered lists after young evacuation is complete. The method will replace any forwarded entries in the discovered list with the forwardee.
> 
> This PR also extends whitebox testing support for Shenandoah, giving us the ability to trigger young/old collections and interrogate some properties of heaps and regions.

William Kemper has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision:

 - 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
 - Consolidate management of bootstrap cycle configuration
 - Use Events::log, not Event for simple log messages
 - Oops, change name of class in test xdoc
 - ... and 6 more: https://git.openjdk.org/jdk/compare/3f36a04d...1aaa4bfb

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28810/files
  - new: https://git.openjdk.org/jdk/pull/28810/files/f8eb0cae..1aaa4bfb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28810&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28810&range=00-01

  Stats: 312435 lines in 3092 files changed: 209779 ins; 60024 del; 42632 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 pchilanomate at openjdk.org  Tue Dec 16 20:04:28 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 16 Dec 2025 20:04:28 GMT
Subject: RFR: 8372591: assert(!current->cont_fastpath() ||
 freeze.check_valid_fast_path()) failed
In-Reply-To: <foG1voIFiv_mFEDo5VAlX7n-iKntbtLzHBt6te9GjgY=.03c20e9e-cfa9-404f-998d-bc53b29c4579@github.com>
References: <6yaYr_fSazq20-3lshGS-_Lr-LqXMt4lTeaFzDs9U2U=.c865efd1-9b98-4fce-98dd-4e1fe50a45be@github.com>
 <foG1voIFiv_mFEDo5VAlX7n-iKntbtLzHBt6te9GjgY=.03c20e9e-cfa9-404f-998d-bc53b29c4579@github.com>
Message-ID: <nCpqwLkPWZ-HdeOkpNN3EZE6BLEO3tWvRsBg7XGwxg4=.51968112-0302-4c8c-8818-e8b19a24d8f7@github.com>

On Tue, 16 Dec 2025 04:46:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This seems to be a "day one" bug with virtual threads. Do you have an idea as to why it has not been noticed before?
>
Yes, it's a day one bug. There are a couple of conditions that need to align to trigger it, but the most likely reason it went undetected is the requirement for a big enough difference between the `unextended_sp` and `sp` of the interpreted sender.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28830#issuecomment-3662166873

From liach at openjdk.org  Tue Dec 16 20:27:48 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 16 Dec 2025 20:27:48 GMT
Subject: RFR: 8373800: Remove ScopedValueBindingsResolver
In-Reply-To: <SlF9UG1hEtDxTxkDwxzFdFDUSVYRQXdssqR9sdjcSkE=.3061bd47-e191-486b-a07f-9d44e3b8c80d@github.com>
References: <SlF9UG1hEtDxTxkDwxzFdFDUSVYRQXdssqR9sdjcSkE=.3061bd47-e191-486b-a07f-9d44e3b8c80d@github.com>
Message-ID: <jYYC_M53P-r_-1e3rGwhpeOCylF0tJWl3pkTfkL46eY=.f3bfc95a-f528-437d-9142-f82277bf6acb@github.com>

On Tue, 16 Dec 2025 14:44:47 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The `ScopedValueBindingsResolver::ScopedValueBindingsResolver()` constructor is invoked the first time 
> `JVM_FindScopedValueBindings` is invoked, and may cause unexpected behavior if the loading of the `ScopedValue$Carrier` class fails to load (due to OOM, etc).
> 
> With this PR, `ScopedValue$Carrier` is loaded during bootstrap with all other `vmClasses`.

This class was originally in `jdk.incubator` so it had to be resolved this way. Not necessary any more indeed.

https://github.com/openjdk/jdk/pull/10952/files#diff-50437abcc14d6d69f89f6a6566f1ed016f60a8c2173d43cd681727b46a0dd314R1370

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28849#pullrequestreview-3584813027

From jrose at openjdk.org  Tue Dec 16 20:35:17 2025
From: jrose at openjdk.org (John R Rose)
Date: Tue, 16 Dec 2025 20:35:17 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting [v6]
In-Reply-To: <uqj0bUkdXgXgqfHQZQoYNd57Civ4eZA_J5ijXvjxBXw=.9ad57214-28a8-4431-bef5-b54c5b3a2377@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
 <uqj0bUkdXgXgqfHQZQoYNd57Civ4eZA_J5ijXvjxBXw=.9ad57214-28a8-4431-bef5-b54c5b3a2377@github.com>
Message-ID: <Z7NH79asegI9muFuJMbW4NL7ToJMmaspWzYpZlkGOCc=.d3b0d920-8598-4a0a-ac40-f4a23f811f56@github.com>

On Tue, 16 Dec 2025 18:54:34 GMT, Chen Liang <liach at openjdk.org> 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 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:
> 
>  - Recommended test tweaks
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting
>  - Jorn review
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting
>  - bracket styles
>  - Doc tweaks
>  - Essay
>  - Spurious change
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/384c62c9...567e8925

Excellent.  It does not pay down every bit of technical debt in this area, but it is a significant installment payment.

I think `constantFold` is OK as a directory name, although maybe a bit vague (folloing Jorn?s observations).

Perhaps `constantFields` or `fieldFolding`.  Or (most specifically) `trustedFinalFields`, but I think that is unnecessarily narrow.

I suggest `fieldFolding` or `foldFields` or the like.  The trusting logic is one way to fold fields, and also the forthcoming `ACC_STRICT_INIT`.  There are also proposals to infer strictness in the absence of `ACC_STRICT_INIT`.  All of those might have test cases associated with the tests for this feature.

We could expect several tests in here eventually, validating the folding properties of various flavors of constant fields.

-------------

Marked as reviewed by jrose (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28540#pullrequestreview-3584835561

From kevinw at openjdk.org  Tue Dec 16 20:46:46 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 16 Dec 2025 20:46:46 GMT
Subject: RFR: 8373441: Remove DCmdFactory::_enabled [v2]
In-Reply-To: <AjjRyNcaMQOA-qcgilZVf5STbEMEmWAoBy3_BidW48k=.15d682e2-f8b6-4e4d-8fc2-f482e117b6b2@github.com>
References: <XE188S-C6EdTA2PRsdsQTi4Z550PW6DNpL3awvANazU=.1b0cd4d1-56cd-491a-b80c-8e2bafcc78ca@github.com>
 <AjjRyNcaMQOA-qcgilZVf5STbEMEmWAoBy3_BidW48k=.15d682e2-f8b6-4e4d-8fc2-f482e117b6b2@github.com>
Message-ID: <adui1hf3MwZvlgT-cy3RamKYJeVPbtt-yoAXSL6jMLU=.0694d9b5-7d9f-44e4-9f9a-a9315be4d121@github.com>

On Fri, 12 Dec 2025 23:37:20 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The `DCmdFactory::_enabled` is always set to `true` and there doesn't seem to be a reason to set it to `false`.
>> 
>> This PR removes this field and simplified the creation of `DCmdFactory` objects.
>> 
>> The related `_hidden` field is also currently not used, but may be used in the future when deprecating DCmds, so we leave it unchanged.
>> 
>> Note that now `jmm_GetDiagnosticCommandInfo()` always set `dcmdInfo::enabled` to `true` to be compatible with Java code.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @kevinjwalls comments

Marked as reviewed by kevinw (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28794#pullrequestreview-3584868873

From kevinw at openjdk.org  Tue Dec 16 20:46:47 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 16 Dec 2025 20:46:47 GMT
Subject: RFR: 8373441: Remove DCmdFactory::_enabled [v2]
In-Reply-To: <PSey24d8vzoiGbajbdvA6NJC3rogA2JSJ094bFILFBU=.ae2b5f7b-ebbc-40b5-bf97-17719df9c40e@github.com>
References: <XE188S-C6EdTA2PRsdsQTi4Z550PW6DNpL3awvANazU=.1b0cd4d1-56cd-491a-b80c-8e2bafcc78ca@github.com>
 <AjjRyNcaMQOA-qcgilZVf5STbEMEmWAoBy3_BidW48k=.15d682e2-f8b6-4e4d-8fc2-f482e117b6b2@github.com>
 <PSey24d8vzoiGbajbdvA6NJC3rogA2JSJ094bFILFBU=.ae2b5f7b-ebbc-40b5-bf97-17719df9c40e@github.com>
Message-ID: <H8hznVoJQw6E6O09lymKyUYKc5PJSIf9vxV-C2419xg=.6275c817-e470-40ac-8b5c-803fb14950dc@github.com>

On Tue, 16 Dec 2025 15:36:31 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @kevinjwalls comments
>
> More context: https://openjdk.org/jeps/137
> 
>> 1-1 Overview
>> 
>> The diagnostic command framework is fully implemented in native code and relies on HotSpot's internal exception mechanism. The rationale for a pure native implementation is to be able to execute diagnostic commands even in critical situations like an out-of-memory condition. All diagnostic commands are registered in a single list, and two flags control the way a user can interact with them. The hidden flag prevents a diagnostic command from appearing in the list of available commands returned by the help command. However, it's still possible to get the detailed help message for a hidden command with the help <command name> syntax, but it requires knowing the name of the hidden command. The second flag is enabled and it controls whether a command can be invoked or not. When listed with the help commands, disabled commands appear with a [disabled] label in their descriptions. If the user tries to invoke a disabled command, an error message is returned and the command is not run. Thi
 s error message can be customized on a per-command basis. The framework just provides these two flags with their semantics; it doesn't provide any policy or mechanism to set or modify these flags. These actions will be delegated to the JVM or specific diagnostic commands.
> 
> The diagnostic command framework was developed at the same time we had requests to implement "Commercial features", the "enabled" flag might also have been intended to guard those commercial features (gone now).

Thanks @fparain Frederic for the extra context.  Had wondered if this feature had ever been used, particularly all the mechanism around the possible JMX Notification.  After this change, we may look at whether it should be removed also.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28794#issuecomment-3662306936

From dholmes at openjdk.org  Tue Dec 16 21:32:34 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 16 Dec 2025 21:32:34 GMT
Subject: RFR: 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: <Y1v1Vw0Ubg0YAcAEcyxDossBfHLT47_WYCmtVT7Q_7w=.2bc525dd-e8bb-4b1a-87ee-faa1754d4245@github.com>

On Mon, 15 Dec 2025 16:53:05 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> When a frame is OSR and the caller is interpreted we call `push_cont_fastpath` to possible set `_cont_fastpath` to the `sp` of the sender. This is needed in order to keep track of interpreted frames in the stack, so that in case of unmounting we don't incorrectly execute the freeze fast path, which is only allowed when all frames are compiled.
> 
> The problem is that the OSR frame is created starting from the `unextended_sp` of the sender, not the `sp`, i.e we pop the interpreted frame like in `remove_activation`. This means that we could set a value to `_cont_fastpath` that will point outside the valid stack (below the `sp` of the OSR frame). If the gap between these stack addresses is big enough, `_cont_fastpath` could be later cleared while we still have the interpreter sender in the stack, leading to the reported crash. The simplest case where this will happen is if in a later call to yield all the extra frames leading to `Continuation.doYield` fit within this space [[1]](https://github.com/openjdk/jdk/blob/ad29642d8f4e8e0fb1223b14b85ab7841d7b1b51/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L232). It could also be cleared before that if for example at some point we returned from an interpreted callee and the sender sp it's not below `_cont_fastpath`[[2]](https://github.com/openjdk/jdk/blob/ad29642d8f4e8e0fb1223b
 14b85ab7841d7b1b51/src/hotspot/cpu/x86/interp_masm_x86.cpp#L1060).
> 
> The fix is to change `OSR_migration_begin` to set `_cont_fastpath` with the sender's `unextended_sp` instead. 
> 
> The patch includes new test `OSRWithManyLocals.java` which reliably reproduces the crash. I thought about adding it to the existing `OSRTest.java` but that was created to exercise a different issue. A better name for that test would be `OSRWithManyArgs.java`, so I could rename it in this patch if preferred (I also realized that test could be simplified and made easier to read but that's for another PR).
> 
> I tested the current patch with the new test and also run it through mach5 tiers1-7.
> 
> Thanks,
> Patricio

Good find!

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28830#pullrequestreview-3585017718

From lmesnik at openjdk.org  Tue Dec 16 21:46:53 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 16 Dec 2025 21:46:53 GMT
Subject: RFR: 8373723: Deadlock with
 JvmtiTagMap::flush_object_free_events()
In-Reply-To: <07HKvRU8Zx99j0UnNMVNhY7XfoGMaqb_55hYJ-Ippk0=.a4d21351-3e03-407f-a0ed-870569cac816@github.com>
References: <NSbobPaTwRkepNErCWi1IEKZ0JT6R-dGNTI0S_dM8Ts=.53706809-f5ed-489c-be79-3020efea185b@github.com>
 <07HKvRU8Zx99j0UnNMVNhY7XfoGMaqb_55hYJ-Ippk0=.a4d21351-3e03-407f-a0ed-870569cac816@github.com>
Message-ID: <Hw0rLP418GSpw56FVhNRyi5Ty3G6cIECeC_eYRHihNk=.93fa855e-b6bb-4027-b310-a1de5ef7ced7@github.com>

On Tue, 16 Dec 2025 03:57:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The JvmtiTagMap::flush_object_free_events() method might be called from different threads.
>> The thread waits using lock until other thread posting events. The locking thread is in vm state doesn't allowing safepoints. While other thread posting events might request safepoints.
>> 
>> The fix is to block thread to allow safepoints while waiting on the lock.
>
> src/hotspot/share/prims/jvmtiTagMap.cpp line 1210:
> 
>> 1208:       // This another thread might have safepoints during event callbacks.
>> 1209:       ThreadBlockInVM tbivm(JavaThread::current());
>> 1210:       MonitorLocker ml(lock(), Mutex::_no_safepoint_check_flag);
> 
> Why not just remove the "no safepoint check" from the MonitorLocker?

This is lock is used in different places, including 
`JvmtiTagMap::check_hashmaps_for_heapwalk`
which is called from VMThread. 
Thus JvmtiTagMap_lock can't has rank `safepoint` and this `MonitorLocker` should also has `_no_safepoint_check_flag`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28839#discussion_r2624844825

From dholmes at openjdk.org  Tue Dec 16 22:06:41 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 16 Dec 2025 22:06:41 GMT
Subject: RFR: 8373723: Deadlock with
 JvmtiTagMap::flush_object_free_events()
In-Reply-To: <07HKvRU8Zx99j0UnNMVNhY7XfoGMaqb_55hYJ-Ippk0=.a4d21351-3e03-407f-a0ed-870569cac816@github.com>
References: <NSbobPaTwRkepNErCWi1IEKZ0JT6R-dGNTI0S_dM8Ts=.53706809-f5ed-489c-be79-3020efea185b@github.com>
 <07HKvRU8Zx99j0UnNMVNhY7XfoGMaqb_55hYJ-Ippk0=.a4d21351-3e03-407f-a0ed-870569cac816@github.com>
Message-ID: <S5TaUPeth9CYhLtExhTLgSy4epqzNG0R-vpnCfiHyHU=.59c900b0-d82a-4a65-a73a-853771250067@github.com>

On Tue, 16 Dec 2025 03:56:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The JvmtiTagMap::flush_object_free_events() method might be called from different threads.
>> The thread waits using lock until other thread posting events. The locking thread is in vm state doesn't allowing safepoints. While other thread posting events might request safepoints.
>> 
>> The fix is to block thread to allow safepoints while waiting on the lock.
>
> src/hotspot/share/prims/jvmtiTagMap.cpp line 1208:
> 
>> 1206:     {
>> 1207:       // If another thread is posting events, let it finish.
>> 1208:       // This another thread might have safepoints during event callbacks.
> 
> The comment does not read correctly.

Suggestion:

// The other thread can block for safepoints during event callbacks, so ensure we
// are safepoint-safe while waiting.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28839#discussion_r2624903690

From dholmes at openjdk.org  Tue Dec 16 22:06:43 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 16 Dec 2025 22:06:43 GMT
Subject: RFR: 8373723: Deadlock with
 JvmtiTagMap::flush_object_free_events()
In-Reply-To: <Hw0rLP418GSpw56FVhNRyi5Ty3G6cIECeC_eYRHihNk=.93fa855e-b6bb-4027-b310-a1de5ef7ced7@github.com>
References: <NSbobPaTwRkepNErCWi1IEKZ0JT6R-dGNTI0S_dM8Ts=.53706809-f5ed-489c-be79-3020efea185b@github.com>
 <07HKvRU8Zx99j0UnNMVNhY7XfoGMaqb_55hYJ-Ippk0=.a4d21351-3e03-407f-a0ed-870569cac816@github.com>
 <Hw0rLP418GSpw56FVhNRyi5Ty3G6cIECeC_eYRHihNk=.93fa855e-b6bb-4027-b310-a1de5ef7ced7@github.com>
Message-ID: <qr2YEUQTF-ctJnk6BCiEzXaRlLAzXRrjGmV12QlWPHg=.04a9dee9-07a7-4bcf-82cb-913b6efe544a@github.com>

On Tue, 16 Dec 2025 21:44:20 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiTagMap.cpp line 1210:
>> 
>>> 1208:       // This another thread might have safepoints during event callbacks.
>>> 1209:       ThreadBlockInVM tbivm(JavaThread::current());
>>> 1210:       MonitorLocker ml(lock(), Mutex::_no_safepoint_check_flag);
>> 
>> Why not just remove the "no safepoint check" from the MonitorLocker?
>
> This is lock is used in different places, including 
> `JvmtiTagMap::check_hashmaps_for_heapwalk`
> which is called from VMThread. 
> Thus JvmtiTagMap_lock can't has rank `safepoint` and this `MonitorLocker` should also has `_no_safepoint_check_flag`.

Okay. It does seem like the one case of waiting for event posting to complete, is the only place we need to be safepoint-safe.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28839#discussion_r2624900432

From duke at openjdk.org  Tue Dec 16 22:52:13 2025
From: duke at openjdk.org (Ruben)
Date: Tue, 16 Dec 2025 22:52:13 GMT
Subject: RFR: 8373696: AArch64: Refine post-call NOPs
Message-ID: <IYr1eAznZw4gu4pj399qpqSdYX4q5J572m79d9Cdh5E=.ccd850a7-0d78-4f19-84f9-fc82f2ff7707@github.com>

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       |  -0.096% |    -0.773% to  0.586% |
  | org.renaissance.twitter.finagle.JmhFinagleChirper.run |  -0.200% |    -1.143% to  0.698% |
  | org.renaissance.twitter.finagle.JmhFinagleHttp.run    |  -0.865% |    -1.328% to -0.251% |
  |------------------------------------------------------------------------------------------|
  | Overall geometric mean: -0.459% change (90% CI: [-0.839%, -0.097%])                      |
  |------------------------------------------------------------------------------------------|

-------------

Commit messages:
 - 8373696: AArch64: Refine post-call NOPs
 - 8373696: AArch64: C1: Embed FP constants into the main code

Changes: https://git.openjdk.org/jdk/pull/28855/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28855&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373696
  Stats: 573 lines in 12 files changed: 473 ins; 42 del; 58 mod
  Patch: https://git.openjdk.org/jdk/pull/28855.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28855/head:pull/28855

PR: https://git.openjdk.org/jdk/pull/28855

From lmesnik at openjdk.org  Tue Dec 16 23:08:24 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 16 Dec 2025 23:08:24 GMT
Subject: RFR: 8373723: Deadlock with
 JvmtiTagMap::flush_object_free_events() [v2]
In-Reply-To: <NSbobPaTwRkepNErCWi1IEKZ0JT6R-dGNTI0S_dM8Ts=.53706809-f5ed-489c-be79-3020efea185b@github.com>
References: <NSbobPaTwRkepNErCWi1IEKZ0JT6R-dGNTI0S_dM8Ts=.53706809-f5ed-489c-be79-3020efea185b@github.com>
Message-ID: <IMsnsYbZoXe4awSTqUotD9bUi4MMZ-rrJbYaxlAO_Os=.be3d6e50-a040-42c0-9398-1b51cff68269@github.com>

> The JvmtiTagMap::flush_object_free_events() method might be called from different threads.
> The thread waits using lock until other thread posting events. The locking thread is in vm state doesn't allowing safepoints. While other thread posting events might request safepoints.
> 
> The fix is to block thread to allow safepoints while waiting on the lock.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  applid David's suggestion

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28839/files
  - new: https://git.openjdk.org/jdk/pull/28839/files/3035f2b4..6790f159

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28839&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28839&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28839.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28839/head:pull/28839

PR: https://git.openjdk.org/jdk/pull/28839

From lmesnik at openjdk.org  Tue Dec 16 23:08:25 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 16 Dec 2025 23:08:25 GMT
Subject: RFR: 8373723: Deadlock with
 JvmtiTagMap::flush_object_free_events() [v2]
In-Reply-To: <S5TaUPeth9CYhLtExhTLgSy4epqzNG0R-vpnCfiHyHU=.59c900b0-d82a-4a65-a73a-853771250067@github.com>
References: <NSbobPaTwRkepNErCWi1IEKZ0JT6R-dGNTI0S_dM8Ts=.53706809-f5ed-489c-be79-3020efea185b@github.com>
 <07HKvRU8Zx99j0UnNMVNhY7XfoGMaqb_55hYJ-Ippk0=.a4d21351-3e03-407f-a0ed-870569cac816@github.com>
 <S5TaUPeth9CYhLtExhTLgSy4epqzNG0R-vpnCfiHyHU=.59c900b0-d82a-4a65-a73a-853771250067@github.com>
Message-ID: <kx14xotDQMrXNWb3MRyftYQLcoo2iXJDDU1yIvMPMMc=.320c7043-748f-472c-82a1-eba6f59d3ba5@github.com>

On Tue, 16 Dec 2025 22:04:19 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiTagMap.cpp line 1208:
>> 
>>> 1206:     {
>>> 1207:       // If another thread is posting events, let it finish.
>>> 1208:       // This another thread might have safepoints during event callbacks.
>> 
>> The comment does not read correctly.
>
> Suggestion:
> 
> // The other thread can block for safepoints during event callbacks, so ensure we
> // are safepoint-safe while waiting.

Thank you for your suggestion.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28839#discussion_r2625038070

From iklam at openjdk.org  Tue Dec 16 23:20:26 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 16 Dec 2025 23:20:26 GMT
Subject: RFR: 8373441: Remove DCmdFactory::_enabled [v2]
In-Reply-To: <H8hznVoJQw6E6O09lymKyUYKc5PJSIf9vxV-C2419xg=.6275c817-e470-40ac-8b5c-803fb14950dc@github.com>
References: <XE188S-C6EdTA2PRsdsQTi4Z550PW6DNpL3awvANazU=.1b0cd4d1-56cd-491a-b80c-8e2bafcc78ca@github.com>
 <AjjRyNcaMQOA-qcgilZVf5STbEMEmWAoBy3_BidW48k=.15d682e2-f8b6-4e4d-8fc2-f482e117b6b2@github.com>
 <PSey24d8vzoiGbajbdvA6NJC3rogA2JSJ094bFILFBU=.ae2b5f7b-ebbc-40b5-bf97-17719df9c40e@github.com>
 <H8hznVoJQw6E6O09lymKyUYKc5PJSIf9vxV-C2419xg=.6275c817-e470-40ac-8b5c-803fb14950dc@github.com>
Message-ID: <vQrQ9PNZaSzfCfw4AZQe8pnUGIAB5FvAOncqzxguvlo=.9f26b5e8-a211-4856-b110-b0d220cc8880@github.com>

On Tue, 16 Dec 2025 20:43:14 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> More context: https://openjdk.org/jeps/137
>> 
>>> 1-1 Overview
>>> 
>>> The diagnostic command framework is fully implemented in native code and relies on HotSpot's internal exception mechanism. The rationale for a pure native implementation is to be able to execute diagnostic commands even in critical situations like an out-of-memory condition. All diagnostic commands are registered in a single list, and two flags control the way a user can interact with them. The hidden flag prevents a diagnostic command from appearing in the list of available commands returned by the help command. However, it's still possible to get the detailed help message for a hidden command with the help <command name> syntax, but it requires knowing the name of the hidden command. The second flag is enabled and it controls whether a command can be invoked or not. When listed with the help commands, disabled commands appear with a [disabled] label in their descriptions. If the user tries to invoke a disabled command, an error message is returned and the command is not run. Th
 is error message can be customized on a per-command basis. The framework just provides these two flags with their semantics; it doesn't provide any policy or mechanism to set or modify these flags. These actions will be delegated to the JVM or specific diagnostic commands.
>> 
>> The diagnostic command framework was developed at the same time we had requests to implement "Commercial features", the "enabled" flag might also have been intended to guard those commercial features (gone now).
>
> Thanks @fparain Frederic for the extra context.  Had wondered if this feature had ever been used, particularly all the mechanism around the possible JMX Notification.  After this change, we may look at whether it should be removed also.

Thanks @kevinjwalls @fparain @kevinjwalls for the review

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28794#issuecomment-3662832242

From iklam at openjdk.org  Tue Dec 16 23:20:27 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 16 Dec 2025 23:20:27 GMT
Subject: Integrated: 8373441: Remove DCmdFactory::_enabled
In-Reply-To: <XE188S-C6EdTA2PRsdsQTi4Z550PW6DNpL3awvANazU=.1b0cd4d1-56cd-491a-b80c-8e2bafcc78ca@github.com>
References: <XE188S-C6EdTA2PRsdsQTi4Z550PW6DNpL3awvANazU=.1b0cd4d1-56cd-491a-b80c-8e2bafcc78ca@github.com>
Message-ID: <RxByniX_b6rPrJESSqHi8WN2TJ1LdVqZJIfkBxNUjrM=.c1747871-bc12-45fa-9b42-56c1975b0d8f@github.com>

On Fri, 12 Dec 2025 14:54:52 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The `DCmdFactory::_enabled` is always set to `true` and there doesn't seem to be a reason to set it to `false`.
> 
> This PR removes this field and simplified the creation of `DCmdFactory` objects.
> 
> The related `_hidden` field is also currently not used, but may be used in the future when deprecating DCmds, so we leave it unchanged.
> 
> Note that now `jmm_GetDiagnosticCommandInfo()` always set `dcmdInfo::enabled` to `true` to be compatible with Java code.

This pull request has now been integrated.

Changeset: 3f077102
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3f07710270dbe7268f21828dff20e2eb810b1e70
Stats:     102 lines in 7 files changed: 4 ins; 25 del; 73 mod

8373441: Remove DCmdFactory::_enabled

Reviewed-by: kevinw, fparain, jsjolen

-------------

PR: https://git.openjdk.org/jdk/pull/28794

From duke at openjdk.org  Tue Dec 16 23:24:30 2025
From: duke at openjdk.org (Ruben)
Date: Tue, 16 Dec 2025 23:24:30 GMT
Subject: RFR: 8373697: AArch64: Remove deopt stub code for nmethods with small
 stack frames
Message-ID: <LvdwgIjv2xY3pmOijohkA1h2c61vUSWtgEug7b4k8-w=.6f6e5cbd-a9f1-4154-8205-de52479fdd1f@github.com>

Removal of deoptimization stub codes improves density of compiled code.
It is possible at least for methods with relatively small stack frames.

-------------

Commit messages:
 - 8373697: AArch64: Remove deopt stub code for nmethods with small stack frames
 - 8373697: AArch64: is_deoptimized should only be set for compiled frames
 - 8373697: Merge nmethod::is_deopt_entry into nmethod::is_deopt_pc.

Changes: https://git.openjdk.org/jdk/pull/28857/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28857&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373697
  Stats: 889 lines in 49 files changed: 740 ins; 72 del; 77 mod
  Patch: https://git.openjdk.org/jdk/pull/28857.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28857/head:pull/28857

PR: https://git.openjdk.org/jdk/pull/28857

From dlong at openjdk.org  Tue Dec 16 23:59:58 2025
From: dlong at openjdk.org (Dean Long)
Date: Tue, 16 Dec 2025 23:59:58 GMT
Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() [v6]
In-Reply-To: <CEvEqPtlTMiv7fX1G_spyCpyl8afEZn4McrzIBd5GRY=.d233254e-3626-4044-a3e1-c82bcbd55e45@github.com>
References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com>
 <CEvEqPtlTMiv7fX1G_spyCpyl8afEZn4McrzIBd5GRY=.d233254e-3626-4044-a3e1-c82bcbd55e45@github.com>
Message-ID: <I5XL0k_oBVrm7csBlnHijgHW-a3iJTZk0C3CmxTPjXA=.fd8ce7f7-f61a-459f-abc2-438f097fcc17@github.com>

On Mon, 8 Dec 2025 14:01:48 GMT, Fei Gao <fgao at openjdk.org> 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/946d55b3...415495da

What about a 3rd thread that sees the call site already resolved so never calls the resolve helper?  It won't execute an ISB either.  I thought the ISB was only need to changed to the stub, not the call site.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26638#issuecomment-3662949048

From wkemper at openjdk.org  Wed Dec 17 00:29:18 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 17 Dec 2025 00:29:18 GMT
Subject: RFR: 8373203: Genshen: Non-strong reference leak in old gen [v3]
In-Reply-To: <JaJt39rlIHDKUiyQmDuh0uSyVslFVLKisMXo0r2gROk=.1056f4b4-441f-4ed2-9e7f-e81cbaca272c@github.com>
References: <JaJt39rlIHDKUiyQmDuh0uSyVslFVLKisMXo0r2gROk=.1056f4b4-441f-4ed2-9e7f-e81cbaca272c@github.com>
Message-ID: <BeP9UlUdtGL8xE3Z1iG783xGAjQw8FGfGL6oH8kz-Qs=.84e1fdca-8f2a-4bca-98d7-50e87590ab9d@github.com>

> The generational mode for Shenandoah will collect _referents_ for the generation being collected. For example, if we have a young reference pointing to an old referent, that young reference will be processed after we finish marking the old generation. This presents a problem for discovery.
>   
> When the young mark _encounters_ a young reference with an old referent, it cannot _discover_ it because old marking hasn't finished. However, if it does not discover it, the old referent will be strongly marked. This, in turn, will prevent the old generation from clearing the referent (if it even reaches it again during old marking).
>   
> To solve this, we let young reference processing discover the old reference by having it use the old generation reference processor to do so. This means the old reference processor can have a discovered list that contains young weak references. If any of these young references reside in a region that is collected, old reference processing will crash when it processes such a reference. Therefore, we add a method `heal_discovered_lists` to traverse the discovered lists after young evacuation is complete. The method will replace any forwarded entries in the discovered list with the forwardee.
> 
> This PR also extends whitebox testing support for Shenandoah, giving us the ability to trigger young/old collections and interrogate some properties of heaps and regions.

William Kemper has updated the pull request incrementally with one additional commit since the last revision:

  Sort includes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28810/files
  - new: https://git.openjdk.org/jdk/pull/28810/files/1aaa4bfb..bc42a6ee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28810&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28810&range=01-02

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 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 fyang at openjdk.org  Wed Dec 17 01:22:51 2025
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 17 Dec 2025 01:22:51 GMT
Subject: RFR: 8373069: RISC-V: implement GHASH intrinsic [v5]
In-Reply-To: <yRSHWlMt6VRBC2-LwmTM04tPCfPMMbf5TcPBMoL9KEk=.ef0684da-6ad9-47a6-bfcd-550c3c7be272@github.com>
References: <zxCNQIhhidoKzHbxL0z8h_Tp1N8pCmlHNoJ2wx30XF8=.a3d8eb05-9a07-403e-a014-84c3bb32b001@github.com>
 <yRSHWlMt6VRBC2-LwmTM04tPCfPMMbf5TcPBMoL9KEk=.ef0684da-6ad9-47a6-bfcd-550c3c7be272@github.com>
Message-ID: <aDUkiyO2lSi83gmOsHQ6KYpPjaReDq1Ktw-BXet3GYQ=.52ea7d31-b0a2-4e68-bc6b-bc6e294df067@github.com>

On Mon, 15 Dec 2025 10:53:15 GMT, Anjian Wen <wenanjian at openjdk.org> wrote:

>> support GHASH intrinsic for crypt GCM, which need zvkg extension. 
>> 
>> passed the tests in 
>> test/hotspot/jtreg/compiler/codegen/aes/
>> test/jdk/com/sun/crypto
>
> Anjian Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   delete some redundant assert and modify some format

Thanks!

-------------

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28548#pullrequestreview-3585593305

From dlong at openjdk.org  Wed Dec 17 02:26:58 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 17 Dec 2025 02:26:58 GMT
Subject: RFR: 8373697: AArch64: Remove deoptimization stub code for
 nmethods with small stack frames
In-Reply-To: <LvdwgIjv2xY3pmOijohkA1h2c61vUSWtgEug7b4k8-w=.6f6e5cbd-a9f1-4154-8205-de52479fdd1f@github.com>
References: <LvdwgIjv2xY3pmOijohkA1h2c61vUSWtgEug7b4k8-w=.6f6e5cbd-a9f1-4154-8205-de52479fdd1f@github.com>
Message-ID: <9DEiudi1rEEJKtKMj6QWBTZVX188uZkXAJ-8jMSJqOE=.337e7eaf-27c8-42a2-9723-d8ee56139e1c@github.com>

On Tue, 16 Dec 2025 23:15:12 GMT, Ruben <duke at openjdk.org> wrote:

> Removal of deoptimization stub codes improves density of compiled code.
> It is possible at least for methods with relatively small stack frames.

I can see what you did, and it is very clever, but it would be nice to have it described, at least at a high level, in the comments somewhere and here in the PR.  Also, should we consider alternative solutions, like putting the original pc at a fixed slot in the compiled frames?

src/hotspot/share/opto/output.cpp line 1794:

> 1792:     }
> 1793:     // Emit the deopt handler code if needed.
> 1794:     if (AlwaysEmitDeoptStubCode

I count 5 times this same expression is repeated.  Maybe it would make sense to move it to an inlined helper function.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28857#issuecomment-3663343041
PR Review Comment: https://git.openjdk.org/jdk/pull/28857#discussion_r2625364847

From duke at openjdk.org  Wed Dec 17 02:40:02 2025
From: duke at openjdk.org (duke)
Date: Wed, 17 Dec 2025 02:40:02 GMT
Subject: RFR: 8373069: RISC-V: implement GHASH intrinsic [v5]
In-Reply-To: <yRSHWlMt6VRBC2-LwmTM04tPCfPMMbf5TcPBMoL9KEk=.ef0684da-6ad9-47a6-bfcd-550c3c7be272@github.com>
References: <zxCNQIhhidoKzHbxL0z8h_Tp1N8pCmlHNoJ2wx30XF8=.a3d8eb05-9a07-403e-a014-84c3bb32b001@github.com>
 <yRSHWlMt6VRBC2-LwmTM04tPCfPMMbf5TcPBMoL9KEk=.ef0684da-6ad9-47a6-bfcd-550c3c7be272@github.com>
Message-ID: <OB_ecB7gbIZpvKweHUdigpTb1zSZQxcMC70QuamrWBs=.cc4b48a5-e221-4014-bb2e-55b3e50648c5@github.com>

On Mon, 15 Dec 2025 10:53:15 GMT, Anjian Wen <wenanjian at openjdk.org> wrote:

>> support GHASH intrinsic for crypt GCM, which need zvkg extension. 
>> 
>> passed the tests in 
>> test/hotspot/jtreg/compiler/codegen/aes/
>> test/jdk/com/sun/crypto
>
> Anjian Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   delete some redundant assert and modify some format

@Anjian-Wen 
Your change (at version fb0f549fa52739938d5a2607fba4860049e0d74f) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28548#issuecomment-3663376150

From wenanjian at openjdk.org  Wed Dec 17 02:44:05 2025
From: wenanjian at openjdk.org (Anjian Wen)
Date: Wed, 17 Dec 2025 02:44:05 GMT
Subject: Integrated: 8373069: RISC-V: implement GHASH intrinsic
In-Reply-To: <zxCNQIhhidoKzHbxL0z8h_Tp1N8pCmlHNoJ2wx30XF8=.a3d8eb05-9a07-403e-a014-84c3bb32b001@github.com>
References: <zxCNQIhhidoKzHbxL0z8h_Tp1N8pCmlHNoJ2wx30XF8=.a3d8eb05-9a07-403e-a014-84c3bb32b001@github.com>
Message-ID: <9HJCSkd5XPFJ8-xXhcf7f8FD2py5_jJjB4RuEzgRSZk=.952128e6-3c8e-4c7d-8bc0-566cb0253ee2@github.com>

On Fri, 28 Nov 2025 03:54:29 GMT, Anjian Wen <wenanjian at openjdk.org> wrote:

> support GHASH intrinsic for crypt GCM, which need zvkg extension. 
> 
> passed the tests in 
> test/hotspot/jtreg/compiler/codegen/aes/
> test/jdk/com/sun/crypto

This pull request has now been integrated.

Changeset: e635330a
Author:    Anjian Wen <wenanjian at openjdk.org>
Committer: Feilong Jiang <fjiang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e635330ae17fd2ce653ec75fd57fdd72d2512bba
Stats:     94 lines in 6 files changed: 86 ins; 4 del; 4 mod

8373069: RISC-V: implement GHASH intrinsic

Reviewed-by: fjiang, fyang

-------------

PR: https://git.openjdk.org/jdk/pull/28548

From qpzhang at openjdk.org  Wed Dec 17 03:47:56 2025
From: qpzhang at openjdk.org (Patrick Zhang)
Date: Wed, 17 Dec 2025 03:47:56 GMT
Subject: RFR: 8365991: AArch64: Ignore BlockZeroingLowLimit when
 UseBlockZeroing is false [v4]
In-Reply-To: <MGiMcmDMuGsTDuPdqrAc8hdMRbkxm7SwjHRCsLqh8dg=.b4700324-db76-4de3-988d-368a38234fc0@github.com>
References: <pSbTemGu8e1IiEiqk0ENZ_GgEVyi-NoA2U01iK_dMDM=.a8308160-ba13-4b39-9696-93e1e3e6f67f@github.com>
 <ojYKlYh3GgnfdImR6oA93RRs-0uc0a7ukpb9fi5ZXsQ=.2ae7f457-9b3a-4768-babc-e1c92b532fab@github.com>
 <bxtYdFD36_D9PtwWyKKPkC2z7hxC4ArDiovwWOKaMhc=.8c858f44-2d75-40b8-b91c-bdda2ff85745@github.com>
 <AWBsjcYr3xUS5h2Tu_tu-3-qnp345tRxR4S_RVARYtA=.4d34e726-6753-47cd-92ef-00dd4bea87d9@github.com>
 <HSGgYMh0eXTLkfvMKIYvASej2QLJ5hA70uVS5I-utc4=.2b296425-2eda-4bdc-9966-e19cee59f82f@github.com>
 <gAsbTJvZ9KSYNDpyKOX_6vctaFKxh6pw9K93H_Qiks0=.cb832560-8130-4391-8d4c-576a0fcbad5f@github.com>
 <eXl4qSdHNo2yrfVLa8stDuAyn8O7Yiuf33RvvPC91wU=.7953ac01-fc0e-492d-967a-a615698e2736@github.com>
 <5Q-u2mZQot1qUYvX2QuOi2jGTxy8kb79Hb2e6d4zHx4=.6f7af4f7-1f65-43ac-a76d-ae8a4145c3b8@github.com>
 <PKPR7zFxLRpUdWQB4cu6msm5jQVYn6y05kZJtFmMSfY=.44dc76f1-f903-4d2d-a50b-4ce6f6c5c115@github.com>
 <MGiMcmDMuGsTDuPdqrAc8hdMRbkxm7SwjHRCsLqh8dg=.b4700324-db76-4de3-988d-368a38234fc0@github.com>
Message-ID: <RLmQh1p1brBhsS3eJ6Lpi4zt3NOlz4buoHmj99UjOLg=.31439967-6d65-4405-bf99-60cbb41243ab@github.com>

On Tue, 28 Oct 2025 12:08:01 GMT, Andrew Haley <aph at openjdk.org> wrote:

>>> > I would like to reiterate that I have no objection to the functions when the `-XX:+UseBlockZeroing` option is set, everything can keep as is. My point is that `BlockZeroingLowLimit` serves literally/specifically as a switch to control whether DC ZVA instructions are generated for clearing instances under a specified bytes size limitation, rather than for deciding between unrolling and callout. Therefore, it should NOT affect the code-gen results any longer when `-XX:-UseBlockZeroing` is set, should it?
>>> 
>>> It does not. When `-XX:-UseBlockZeroing` is set, `BlockZeroingLowLimit` is ignored.
>> 
>> 
>> zero_words does not check `UseBlockZeroing`, it directly compares `cnt` and `BlockZeroingLowLimit / BytesPerWord`.
>> 
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L6198C1-L6204C16
>> 
>> 
>> address MacroAssembler::zero_words(Register base, uint64_t cnt)
>> {
>>   assert(wordSize <= BlockZeroingLowLimit,
>>             "increase BlockZeroingLowLimit");
>>   address result = nullptr;
>>   if (cnt <= (uint64_t)BlockZeroingLowLimit / BytesPerWord) {
>> #ifndef PRODUCT
>> 
>> 
>> In contrast, the inner stub function does so.
>> 
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp#L669
>> 
>>   address generate_zero_blocks() {
>>     Label done;
>>     Label base_aligned;
>> 
>>     Register base = r10, cnt = r11;
>> 
>>     __ align(CodeEntryAlignment);
>>     StubId stub_id = StubId::stubgen_zero_blocks_id;
>>     StubCodeMark mark(this, stub_id);
>>     address start = __ pc();
>> 
>>     if (UseBlockZeroing) {
>
>> > > I would like to reiterate that I have no objection to the functions when the `-XX:+UseBlockZeroing` option is set, everything can keep as is. My point is that `BlockZeroingLowLimit` serves literally/specifically as a switch to control whether DC ZVA instructions are generated for clearing instances under a specified bytes size limitation, rather than for deciding between unrolling and callout. Therefore, it should NOT affect the code-gen results any longer when `-XX:-UseBlockZeroing` is set, should it?
>> > 
>> > 
>> > It does not. When `-XX:-UseBlockZeroing` is set, `BlockZeroingLowLimit` is ignored.
>> 
>> zero_words does not check `UseBlockZeroing`, it directly compares `cnt` and `BlockZeroingLowLimit / BytesPerWord`.
> 
> It doesn't need to because
> 
> 
>   if (!UseBlockZeroing && !FLAG_IS_DEFAULT(BlockZeroingLowLimit)) {
>     warning("BlockZeroingLowLimit has been ignored because UseBlockZeroing is disabled");
>     FLAG_SET_DEFAULT(BlockZeroingLowLimit, is_zva_enabled() ? (4 * VM_Version::zva_length()) : 256);
>   }
> 
> 
> That is to say, if a user sets `BlockZeroingLowLimit` and `-XX:-UseBlockZeroing`, then the user's `BlockZeroingLowLimit` is, rightly, ignored.

Hi, @theRealAph , It has been a long time since I proposed this PR, the patch has become simple and straight-forward after several rounds of updating. I would like to see it move forward soon rather than remain on hold.  Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26917#issuecomment-3663511186

From alanb at openjdk.org  Wed Dec 17 06:52:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 17 Dec 2025 06:52:51 GMT
Subject: RFR: 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: <273aHscNQPebiQ456y_i91um8SqD6uEkGJyrSSiHGjQ=.0c8a0f01-9281-433e-a386-be913a985b90@github.com>

On Mon, 15 Dec 2025 16:53:05 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> When a frame is OSR and the caller is interpreted we call `push_cont_fastpath` to possible set `_cont_fastpath` to the `sp` of the sender. This is needed in order to keep track of interpreted frames in the stack, so that in case of unmounting we don't incorrectly execute the freeze fast path, which is only allowed when all frames are compiled.
> 
> The problem is that the OSR frame is created starting from the `unextended_sp` of the sender, not the `sp`, i.e we pop the interpreted frame like in `remove_activation`. This means that we could set a value to `_cont_fastpath` that will point outside the valid stack (below the `sp` of the OSR frame). If the gap between these stack addresses is big enough, `_cont_fastpath` could be later cleared while we still have the interpreter sender in the stack, leading to the reported crash. The simplest case where this will happen is if in a later call to yield all the extra frames leading to `Continuation.doYield` fit within this space [[1]](https://github.com/openjdk/jdk/blob/ad29642d8f4e8e0fb1223b14b85ab7841d7b1b51/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L232). It could also be cleared before that if for example at some point we returned from an interpreted callee and the sender sp it's not below `_cont_fastpath`[[2]](https://github.com/openjdk/jdk/blob/ad29642d8f4e8e0fb1223b
 14b85ab7841d7b1b51/src/hotspot/cpu/x86/interp_masm_x86.cpp#L1060).
> 
> The fix is to change `OSR_migration_begin` to set `_cont_fastpath` with the sender's `unextended_sp` instead. 
> 
> The patch includes new test `OSRWithManyLocals.java` which reliably reproduces the crash. I thought about adding it to the existing `OSRTest.java` but that was created to exercise a different issue. A better name for that test would be `OSRWithManyArgs.java`, so I could rename it in this patch if preferred (I also realized that test could be simplified and made easier to read but that's for another PR).
> 
> I tested the current patch with the new test and also run it through mach5 tiers1-7.
> 
> Thanks,
> Patricio

Marked as reviewed by alanb (Reviewer).

> 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. 

I think what you have is good but maybe me wonder if there might be other corner cases that might need further Continuations tests.

-------------

PR Review: https://git.openjdk.org/jdk/pull/28830#pullrequestreview-3586265715
PR Comment: https://git.openjdk.org/jdk/pull/28830#issuecomment-3663912139

From stefank at openjdk.org  Wed Dec 17 07:58:55 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 17 Dec 2025 07:58:55 GMT
Subject: RFR: 8373203: Genshen: Non-strong reference leak in old gen [v3]
In-Reply-To: <BeP9UlUdtGL8xE3Z1iG783xGAjQw8FGfGL6oH8kz-Qs=.84e1fdca-8f2a-4bca-98d7-50e87590ab9d@github.com>
References: <JaJt39rlIHDKUiyQmDuh0uSyVslFVLKisMXo0r2gROk=.1056f4b4-441f-4ed2-9e7f-e81cbaca272c@github.com>
 <BeP9UlUdtGL8xE3Z1iG783xGAjQw8FGfGL6oH8kz-Qs=.84e1fdca-8f2a-4bca-98d7-50e87590ab9d@github.com>
Message-ID: <mXjtJJQckzJ4DwiQ7tk9K8lSMZAZFafmovgUDV-lpoA=.ee397dea-6035-4a35-a09a-2eb57ab69d14@github.com>

On Wed, 17 Dec 2025 00:29:18 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> The generational mode for Shenandoah will collect _referents_ for the generation being collected. For example, if we have a young reference pointing to an old referent, that young reference will be processed after we finish marking the old generation. This presents a problem for discovery.
>>   
>> When the young mark _encounters_ a young reference with an old referent, it cannot _discover_ it because old marking hasn't finished. However, if it does not discover it, the old referent will be strongly marked. This, in turn, will prevent the old generation from clearing the referent (if it even reaches it again during old marking).
>>   
>> To solve this, we let young reference processing discover the old reference by having it use the old generation reference processor to do so. This means the old reference processor can have a discovered list that contains young weak references. If any of these young references reside in a region that is collected, old reference processing will crash when it processes such a reference. Therefore, we add a method `heal_discovered_lists` to traverse the discovered lists after young evacuation is complete. The method will replace any forwarded entries in the discovered list with the forwardee.
>> 
>> This PR also extends whitebox testing support for Shenandoah, giving us the ability to trigger young/old collections and interrogate some properties of heaps and regions.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Sort includes

I added a few style proposals to make the Shenandoah sections look more consistent with the surrounding style in the shared code.

src/hotspot/share/prims/whitebox.cpp line 704:

> 702: #endif // INCLUDE_G1GC
> 703: 
> 704: #if INCLUDE_SHENANDOAHGC

Suggestion:

#if INCLUDE_SHENANDOAHGC

src/hotspot/share/prims/whitebox.cpp line 741:

> 739: WB_END
> 740: 
> 741: #endif

Suggestion:

#endif // INCLUDE_SHENANDOAHGC

src/hotspot/share/prims/whitebox.cpp line 2939:

> 2937: 
> 2938: #endif
> 2939: 

Suggestion:

#endif

test/lib/jdk/test/whitebox/WhiteBox.java line 317:

> 315:   public native long[] g1GetMixedGCInfo(int liveness);
> 316: 
> 317:   public native int shenandoahRegionSize();

Suggestion:

  // Shenandoah

  public native int shenandoahRegionSize();

-------------

PR Review: https://git.openjdk.org/jdk/pull/28810#pullrequestreview-3586442631
PR Review Comment: https://git.openjdk.org/jdk/pull/28810#discussion_r2625971356
PR Review Comment: https://git.openjdk.org/jdk/pull/28810#discussion_r2625972227
PR Review Comment: https://git.openjdk.org/jdk/pull/28810#discussion_r2625970693
PR Review Comment: https://git.openjdk.org/jdk/pull/28810#discussion_r2625975644

From asteiner at openjdk.org  Wed Dec 17 08:41:00 2025
From: asteiner at openjdk.org (Andreas Steiner)
Date: Wed, 17 Dec 2025 08:41:00 GMT
Subject: RFR: 8372348: Adjust some UL / JFR string deduplication output
 messages [v2]
In-Reply-To: <0SYxg-Sftdzpna9ftRjMfLGNf2D5JztmR8G5kdjPWnU=.6cd25f16-31f2-4658-86ed-3fe2216dc20d@github.com>
References: <7-XRp229KFw3V2bFPMnaWaoPdF3ZCYVNuViEo2O7eUI=.e0247347-188b-44bf-935c-6b0186026fd3@github.com>
 <0SYxg-Sftdzpna9ftRjMfLGNf2D5JztmR8G5kdjPWnU=.6cd25f16-31f2-4658-86ed-3fe2216dc20d@github.com>
Message-ID: <OZ3yyditxO4aHK-uAGJrbP7i2tORYNyC09YmFPLVqy4=.740fff26-3038-4abf-82fa-1889a625bef4@github.com>

On Mon, 15 Dec 2025 14:59:46 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There is some UL output in the string deduplication code that is not very clear and has room for improvement.
>> The inspected strings number should be shown and the new unknown strings get a changed text.
>> (also the new JFR strip dedup event  description is slightly adjusted)
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Enhance output

Marked as reviewed by asteiner (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28455#pullrequestreview-3586593528

From mbaesken at openjdk.org  Wed Dec 17 08:49:41 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 17 Dec 2025 08:49:41 GMT
Subject: RFR: 8372348: Adjust some UL / JFR string deduplication output
 messages [v2]
In-Reply-To: <0SYxg-Sftdzpna9ftRjMfLGNf2D5JztmR8G5kdjPWnU=.6cd25f16-31f2-4658-86ed-3fe2216dc20d@github.com>
References: <7-XRp229KFw3V2bFPMnaWaoPdF3ZCYVNuViEo2O7eUI=.e0247347-188b-44bf-935c-6b0186026fd3@github.com>
 <0SYxg-Sftdzpna9ftRjMfLGNf2D5JztmR8G5kdjPWnU=.6cd25f16-31f2-4658-86ed-3fe2216dc20d@github.com>
Message-ID: <3lwySCT_ELDE4YfNwCOZA5eh8vwTkjaEm8fcBAGtu9U=.1e084622-91cf-4377-b858-2d5d734c7936@github.com>

On Mon, 15 Dec 2025 14:59:46 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There is some UL output in the string deduplication code that is not very clear and has room for improvement.
>> The inspected strings number should be shown and the new unknown strings get a changed text.
>> (also the new JFR strip dedup event  description is slightly adjusted)
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Enhance output

Thanks for the review !

May I have a second review , please ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28455#issuecomment-3664278657

From fandreuzzi at openjdk.org  Wed Dec 17 09:01:40 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 17 Dec 2025 09:01:40 GMT
Subject: RFR: 8372348: Adjust some UL / JFR string deduplication output
 messages [v2]
In-Reply-To: <0SYxg-Sftdzpna9ftRjMfLGNf2D5JztmR8G5kdjPWnU=.6cd25f16-31f2-4658-86ed-3fe2216dc20d@github.com>
References: <7-XRp229KFw3V2bFPMnaWaoPdF3ZCYVNuViEo2O7eUI=.e0247347-188b-44bf-935c-6b0186026fd3@github.com>
 <0SYxg-Sftdzpna9ftRjMfLGNf2D5JztmR8G5kdjPWnU=.6cd25f16-31f2-4658-86ed-3fe2216dc20d@github.com>
Message-ID: <NF3bJuTenP1wrJrzegI0y8OcEopc3cSXNQly_3MIsmg=.d13c8927-ba7a-4bbb-af54-099e39869879@github.com>

On Mon, 15 Dec 2025 14:59:46 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There is some UL output in the string deduplication code that is not very clear and has room for improvement.
>> The inspected strings number should be shown and the new unknown strings get a changed text.
>> (also the new JFR strip dedup event  description is slightly adjusted)
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Enhance output

src/hotspot/share/gc/shared/stringdedup/stringDedupStat.cpp line 107:

> 105:     last_stat->_deduped, STRDEDUP_BYTES_PARAM(last_stat->_deduped_bytes),
> 106:     percent_of(total_stat->_deduped_bytes, total_stat->_new_bytes),
> 107:     total_stat->_deduped_bytes, total_stat->_new_bytes,

Shouldn't these two use `STRDEDUP_BYTES_FORMAT` and `STRDEDUP_BYTES_PARAM`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28455#discussion_r2626160489

From aph at openjdk.org  Wed Dec 17 09:17:26 2025
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 17 Dec 2025 09:17:26 GMT
Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() [v6]
In-Reply-To: <I5XL0k_oBVrm7csBlnHijgHW-a3iJTZk0C3CmxTPjXA=.fd8ce7f7-f61a-459f-abc2-438f097fcc17@github.com>
References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com>
 <CEvEqPtlTMiv7fX1G_spyCpyl8afEZn4McrzIBd5GRY=.d233254e-3626-4044-a3e1-c82bcbd55e45@github.com>
 <I5XL0k_oBVrm7csBlnHijgHW-a3iJTZk0C3CmxTPjXA=.fd8ce7f7-f61a-459f-abc2-438f097fcc17@github.com>
Message-ID: <iO4qsGbQGgvnqnnuGtS6mC1Op6rwSH5nQtiJ8nisacQ=.3536f06d-98e8-4acf-a0f6-92dde870ad27@github.com>

On Tue, 16 Dec 2025 23:57:11 GMT, Dean Long <dlong at openjdk.org> wrote:

> What about a 3rd thread that sees the call site already resolved so never calls the resolve helper? It won't execute an ISB either. I thought the ISB was only needed to see changes to the stub, not the call site.

I'm sorry, the language I used was poor. When I said "resolved the call site" I should have said "patches the stub, the patches the call site to point to the stub".

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26638#issuecomment-3664390784

From aph at openjdk.org  Wed Dec 17 09:22:08 2025
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 17 Dec 2025 09:22:08 GMT
Subject: RFR: 8373697: AArch64: Remove deoptimization stub code for
 nmethods with small stack frames
In-Reply-To: <9DEiudi1rEEJKtKMj6QWBTZVX188uZkXAJ-8jMSJqOE=.337e7eaf-27c8-42a2-9723-d8ee56139e1c@github.com>
References: <LvdwgIjv2xY3pmOijohkA1h2c61vUSWtgEug7b4k8-w=.6f6e5cbd-a9f1-4154-8205-de52479fdd1f@github.com>
 <9DEiudi1rEEJKtKMj6QWBTZVX188uZkXAJ-8jMSJqOE=.337e7eaf-27c8-42a2-9723-d8ee56139e1c@github.com>
Message-ID: <9oBl1MohXE3_k7L5hX-WtVuTA5Mo3pCl4DHI-xCZInA=.ff37644d-6425-4b47-900e-70ae167912a3@github.com>

On Wed, 17 Dec 2025 02:21:04 GMT, Dean Long <dlong at openjdk.org> wrote:

> I can see what you did, and it is very clever, but it would be nice to have it described, at least at a high level, in the comments somewhere and here in the PR.

Indeed. It's essential to describe what has been done, as a courtesy to the reviewers if nothing else.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28857#issuecomment-3664409307

From aph at openjdk.org  Wed Dec 17 09:35:48 2025
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 17 Dec 2025 09:35:48 GMT
Subject: RFR: 8373696: AArch64: Refine post-call NOPs
In-Reply-To: <IYr1eAznZw4gu4pj399qpqSdYX4q5J572m79d9Cdh5E=.ccd850a7-0d78-4f19-84f9-fc82f2ff7707@github.com>
References: <IYr1eAznZw4gu4pj399qpqSdYX4q5J572m79d9Cdh5E=.ccd850a7-0d78-4f19-84f9-fc82f2ff7707@github.com>
Message-ID: <dWPoRFGyblY6jRLFkhxRpRO1-qKrVR0pyYKNeyCEI8A=.c4b9d54b-e8ad-4e92-a5d4-69f34af7ebf7@github.com>

On Tue, 16 Dec 2025 22:45:08 GMT, Ruben <duke at openjdk.org> 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       |  -0.096% |    -0.773% to  0.586% |
>   | org.renaissance.twitter.finagle.J...

While the basic idea is a good one, I think there are better ways to do it.

Consider fixing the number of instructions to two rather than three. Then a post-call NOP can be either 'nop; movk/movz` or `b.nv; movk/adrp`. Or something similar.. `b.nv` is more expensive, but should be rare.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28855#issuecomment-3664486119

From stefank at openjdk.org  Wed Dec 17 09:41:45 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 17 Dec 2025 09:41:45 GMT
Subject: RFR: 8373801: Adopt arraycopy OopCopyResult from the lworld branch
 [v2]
In-Reply-To: <xL27bPDF6Wl05dCXSghM4SdhK_iuMvlZW4J4LsvAJ9M=.6d00cb20-6661-470f-aa85-2846d56fede8@github.com>
References: <vuovhgARk6krDotYQS-asHzFkm93v8hPWx4zLwT1xC0=.fd37e81f-8714-40b7-a099-58fc653cd2e4@github.com>
 <xL27bPDF6Wl05dCXSghM4SdhK_iuMvlZW4J4LsvAJ9M=.6d00cb20-6661-470f-aa85-2846d56fede8@github.com>
Message-ID: <D3wrh6itQAKufqFr8P4o64rH7ZMwJzGCUcz_rAHcVA4=.a2bfae87-ba36-492c-91c8-aae43952591a@github.com>

On Tue, 16 Dec 2025 15:04:44 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> In the Valhalla project there's code to restrict nulls in object arrays. In the GC arraycopy barrier we there have to both do null checks in addition to the already existing cast checks. If one of these two failed the code needs to propagate this up through the callers to the code that asked to do the checks. There it will throw the suitable exception. Previously, it was enough to say success or failed, and a boolean was enough. Now we need three states. So the bool was replaced with an OopCopyResult enum.
>> 
>> See: https://github.com/openjdk/valhalla/pull/1792
>> 
>> I propose that we bring this over to the mainline to lower the diff between lworld and the openjdk/jdk.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove throw NPE function

Tier1 testing passes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28850#issuecomment-3664510129

From alanb at openjdk.org  Wed Dec 17 09:56:35 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 17 Dec 2025 09:56:35 GMT
Subject: RFR: 8373800: Remove ScopedValueBindingsResolver
In-Reply-To: <SlF9UG1hEtDxTxkDwxzFdFDUSVYRQXdssqR9sdjcSkE=.3061bd47-e191-486b-a07f-9d44e3b8c80d@github.com>
References: <SlF9UG1hEtDxTxkDwxzFdFDUSVYRQXdssqR9sdjcSkE=.3061bd47-e191-486b-a07f-9d44e3b8c80d@github.com>
Message-ID: <cBG4heK6MYkZ-YineZaf2dK9M2UXb7VMHRzTvPlwV_M=.7f67ac5c-409c-4fc5-8ed3-6d7ed5cfde27@github.com>

On Tue, 16 Dec 2025 14:44:47 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The `ScopedValueBindingsResolver::ScopedValueBindingsResolver()` constructor is invoked the first time 
> `JVM_FindScopedValueBindings` is invoked, and may cause unexpected behavior if the loading of the `ScopedValue$Carrier` class fails to load (due to OOM, etc).
> 
> With this PR, `ScopedValue$Carrier` is loaded during bootstrap with all other `vmClasses`.

src/hotspot/share/classfile/vmClassMacros.hpp line 193:

> 191:   do_klass(FillerObject_klass,                          jdk_internal_vm_FillerObject                          ) \
> 192:                                                                                                                 \
> 193:   /* JEP 506: Scoped Values */                                                                                  \

I think you cn drop "JEP 506" from the comment as the feature is permanent now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28849#discussion_r2626359823

From thartmann at openjdk.org  Wed Dec 17 09:59:54 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 17 Dec 2025 09:59:54 GMT
Subject: RFR: 8372701: Randomized profile counters
In-Reply-To: <a788944a-8bf2-4787-8382-274324eb53be@redhat.com>
References: <jKjmIONZcytzVjS4absOwOLv_QOF9qhIJifYhN6JyP4=.dceced94-bc29-43e6-9062-8dc77c2a6133@github.com>
 <a788944a-8bf2-4787-8382-274324eb53be@redhat.com>
Message-ID: <TANJ_hBLr0o3xIfxpmWgM47PNGSa9b8PqAXpyrtgxO0=.d68e394b-a68c-470c-beeb-336c338d8896@github.com>

On Tue, 16 Dec 2025 17:28:24 GMT, Andrew Haley <aph at redhat.com> wrote:

> I don't think there's any point until I've fixed whatever bug is causing the above regressions. Thanks.

Right, I see similar results with `-XX:ProfileCaptureRatio=64`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28541#issuecomment-3664581530

From duke at openjdk.org  Wed Dec 17 10:29:08 2025
From: duke at openjdk.org (SilenceZheng66)
Date: Wed, 17 Dec 2025 10:29:08 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v22]
In-Reply-To: <xd1lCeILblTqeUfjuI0_A5e0l6mSVp4mnU94xix_Xrg=.c7255661-6dfb-4e89-86f4-2eed5a687697@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <rAPcRMkxD0uoJTzadbMR7eui7ixfiVHCKy8JCvS5TPc=.6307f4fd-e333-41c8-97f2-81971974eb93@github.com>
 <C2nKyRSBdqEqIK0I3bEP1X4PM1K3Gb3HhPaxqgJeIS8=.62ffb736-16a7-4da9-8d11-1c147dfb40a1@github.com>
 <g0INjxl-T0NTw_GN4GkKl-d-gwjKQAmQs7_YB1R_LWo=.eaaddff1-531c-4ebc-956c-b091676be405@github.com>
 <ET-MhWMYi6ja-ge-H209Fy9ZHkMPL-6ZaPEeegAAraM=.2f40c659-5c3c-486b-adea-66488fd6050d@github.com>
 <ORGz3sV06WeoIr4xH5NXriQLmGaA5es8wXyKhn0ddJ4=.677f4c8c-7e6b-4ccb-92b0-2b34b2bf329b@github.com>
 <cGMcm5aJjVSTOvlxIDAuU2wvnRvmrgAN685V4htwscU=.7d504563-b632-4c8c-aa0f-d161a5c5af10@github.com>
 <xd1lCeILblTqeUfjuI0_A5e0l6mSVp4mnU94xix_Xrg=.c7255661-6dfb-4e89-86f4-2eed5a687697@github.com>
Message-ID: <-l_zOUn6BoYsrRF-0W1Dl581XtE-TEPXiXhadRiMPHs=.dfbf70eb-0f54-4485-a967-befd6269edaf@github.com>

On Tue, 16 Dec 2025 11:07:07 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> @albertnetymk Since my JVM's version is 25.191-b12, it does not support `-Xlog:gc*` configuration. I also know that your work aim to improve performance when `UseAdaptiveSizePolicy` enabled, but in my situation default configuration is disable that. Now I just curious about is it a bug when people use configurations as following and could raise full GC problems and heap can't expand. 
>> 
>> -Xmx2g
>> -Xms256M
>> -XX:-UseAdaptiveSizePolicy
>> 
>> I understand that's totally not your business, but if you know who can explain or confirm this "bug", just let me know, thx!
>
>> Since my JVM's version is 25.191-b12 ...
> 
> I thought it means JDK25... My apologies.
> 
>>  Now I just curious about is it a bug when people use configurations as following and could raise full GC problems and heap can't expand.
> 
> I think that behavior is definitely undesirable. Whether or not it's a bug can be subjective.
> 
> I believe this behavior has been fixed/improved in later releases of JDK. At least the following two tickets are relevant.
> 
> JDK-8328744: Parallel: Parallel GC throws OOM before heap is fully expanded
> Use max old-gen capacity to decide whether to start a "proactive" full-gc, instead of young-gc.
> 
> JDK-8338977: Parallel: Improve heap resizing heuristics 
> In `PSParallelCompact::summary_phase`, old-gen is expanded via `ParallelScavengeHeap::heap()->old_gen()->try_expand_till_size` even with `-XX:-UseAdaptiveSizePolicy`.
> 
> I wonder if you can try your benchmark(s) with newer JDKs and check if the problem persists.

Thanks! I thinks these two ticket solved the problem I met, which means newer version JDK will not have this issue any more?. @albertnetymk

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2626467932

From iklam at openjdk.org  Wed Dec 17 10:49:37 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 17 Dec 2025 10:49:37 GMT
Subject: RFR: 8373800: Remove ScopedValueBindingsResolver [v2]
In-Reply-To: <SlF9UG1hEtDxTxkDwxzFdFDUSVYRQXdssqR9sdjcSkE=.3061bd47-e191-486b-a07f-9d44e3b8c80d@github.com>
References: <SlF9UG1hEtDxTxkDwxzFdFDUSVYRQXdssqR9sdjcSkE=.3061bd47-e191-486b-a07f-9d44e3b8c80d@github.com>
Message-ID: <4f1W8gNx9PjZRobBluA2b48KNdjZU7NZPLvwBd7pmGQ=.b1fd41f8-5413-4e17-9947-a714ec22b9ff@github.com>

> The `ScopedValueBindingsResolver::ScopedValueBindingsResolver()` constructor is invoked the first time 
> `JVM_FindScopedValueBindings` is invoked, and may cause unexpected behavior if the loading of the `ScopedValue$Carrier` class fails to load (due to OOM, etc).
> 
> With this PR, `ScopedValue$Carrier` is loaded during bootstrap with all other `vmClasses`.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @AlanBateman comment: remove "JEP 506"

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28849/files
  - new: https://git.openjdk.org/jdk/pull/28849/files/6f6aac92..42ffeaa2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28849&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28849&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28849.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28849/head:pull/28849

PR: https://git.openjdk.org/jdk/pull/28849

From iklam at openjdk.org  Wed Dec 17 10:49:39 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 17 Dec 2025 10:49:39 GMT
Subject: RFR: 8373800: Remove ScopedValueBindingsResolver [v2]
In-Reply-To: <cBG4heK6MYkZ-YineZaf2dK9M2UXb7VMHRzTvPlwV_M=.7f67ac5c-409c-4fc5-8ed3-6d7ed5cfde27@github.com>
References: <SlF9UG1hEtDxTxkDwxzFdFDUSVYRQXdssqR9sdjcSkE=.3061bd47-e191-486b-a07f-9d44e3b8c80d@github.com>
 <cBG4heK6MYkZ-YineZaf2dK9M2UXb7VMHRzTvPlwV_M=.7f67ac5c-409c-4fc5-8ed3-6d7ed5cfde27@github.com>
Message-ID: <-w8i91atzxjSX2LbQ98bkYAywiQ_DCYttTL5fUtx8hk=.7d9d560a-a6fa-4cc3-9d2c-6fcc6e5c056e@github.com>

On Wed, 17 Dec 2025 09:54:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @AlanBateman comment: remove "JEP 506"
>
> src/hotspot/share/classfile/vmClassMacros.hpp line 193:
> 
>> 191:   do_klass(FillerObject_klass,                          jdk_internal_vm_FillerObject                          ) \
>> 192:                                                                                                                 \
>> 193:   /* JEP 506: Scoped Values */                                                                                  \
> 
> I think you cn drop "JEP 506" from the comment as the feature is permanent now.

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28849#discussion_r2626543512

From aph at openjdk.org  Wed Dec 17 11:22:57 2025
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 17 Dec 2025 11:22:57 GMT
Subject: RFR: 8373696: AArch64: Refine post-call NOPs
In-Reply-To: <IYr1eAznZw4gu4pj399qpqSdYX4q5J572m79d9Cdh5E=.ccd850a7-0d78-4f19-84f9-fc82f2ff7707@github.com>
References: <IYr1eAznZw4gu4pj399qpqSdYX4q5J572m79d9Cdh5E=.ccd850a7-0d78-4f19-84f9-fc82f2ff7707@github.com>
Message-ID: <3vwwr8CwTPqUSBQTOeUca6QtEMuVqxkuhebFvR2BLL8=.e6ba9a3b-31a9-4d9c-990b-37ab628a4bd4@github.com>

On Tue, 16 Dec 2025 22:45:08 GMT, Ruben <duke at openjdk.org> 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       |  -0.096% |    -0.773% to  0.586% |
>   | org.renaissance.twitter.finagle.J...

src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp line 140:

> 138:   }
> 139: }
> 140: 

This shouldn't be here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28855#discussion_r2626663660

From mablakatov at openjdk.org  Wed Dec 17 11:43:25 2025
From: mablakatov at openjdk.org (Mikhail Ablakatov)
Date: Wed, 17 Dec 2025 11:43:25 GMT
Subject: RFR: 8373794: Move nmethod header from CodeCache
Message-ID: <RZYpT82maT4ayWODxISztNMAQwPOqilJsmjTtfZA9X4=.5953f303-ddb7-4f1e-ab27-e5b3ccaa039f@github.com>

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.

-------------

Commit messages:
 - 8373794: Move nmethod header from CodeCache:

Changes: https://git.openjdk.org/jdk/pull/28866/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28866&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373794
  Stats: 625 lines in 17 files changed: 168 ins; 15 del; 442 mod
  Patch: https://git.openjdk.org/jdk/pull/28866.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28866/head:pull/28866

PR: https://git.openjdk.org/jdk/pull/28866

From alanb at openjdk.org  Wed Dec 17 11:56:32 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 17 Dec 2025 11:56:32 GMT
Subject: RFR: 8373800: Remove ScopedValueBindingsResolver [v2]
In-Reply-To: <4f1W8gNx9PjZRobBluA2b48KNdjZU7NZPLvwBd7pmGQ=.b1fd41f8-5413-4e17-9947-a714ec22b9ff@github.com>
References: <SlF9UG1hEtDxTxkDwxzFdFDUSVYRQXdssqR9sdjcSkE=.3061bd47-e191-486b-a07f-9d44e3b8c80d@github.com>
 <4f1W8gNx9PjZRobBluA2b48KNdjZU7NZPLvwBd7pmGQ=.b1fd41f8-5413-4e17-9947-a714ec22b9ff@github.com>
Message-ID: <I6XKII8nmpqmreqlnEgdoXRxnS6YIEGjJo1UJjCjW4k=.cd28e3e4-6e11-490c-8021-5e9ad5cf5c04@github.com>

On Wed, 17 Dec 2025 10:49:37 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The `ScopedValueBindingsResolver::ScopedValueBindingsResolver()` constructor is invoked the first time 
>> `JVM_FindScopedValueBindings` is invoked, and may cause unexpected behavior if the loading of the `ScopedValue$Carrier` class fails to load (due to OOM, etc).
>> 
>> With this PR, `ScopedValue$Carrier` is loaded during bootstrap with all other `vmClasses`.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @AlanBateman comment: remove "JEP 506"

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28849#pullrequestreview-3587381154

From fgao at openjdk.org  Wed Dec 17 12:09:19 2025
From: fgao at openjdk.org (Fei Gao)
Date: Wed, 17 Dec 2025 12:09:19 GMT
Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() [v6]
In-Reply-To: <TEoePwnDJIw1BQ6kk9-9ggawyVL3luz0rgDALvnN-5Q=.0dfa7cd9-3298-49a7-965d-01d4365986c0@github.com>
References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com>
 <CEvEqPtlTMiv7fX1G_spyCpyl8afEZn4McrzIBd5GRY=.d233254e-3626-4044-a3e1-c82bcbd55e45@github.com>
 <6E4yPY9dRcWGBT-vPPq7bOm1NfLdvIfLdecg34f6Tes=.11b0a7c1-798f-4ed2-a521-26059bc0ba5b@github.com>
 <yRkEv29KF1vLIy4V5nKDgQF7CfvVjUjfssdzZ0PccjA=.00171af8-a1aa-401b-9341-a80a6fb4e22e@github.com>
 <yhtSX7dHSCAnDVCm5UX_9Pfx0-P3FnydZOAbRt7-6Ow=.253c5dbb-c7d1-4543-94cc-cbd1a05d5c0e@github.com>
 <TEoePwnDJIw1BQ6kk9-9ggawyVL3luz0rgDALvnN-5Q=.0dfa7cd9-3298-49a7-965d-01d4365986c0@github.com>
Message-ID: <nPgiY87FhQoQ-hUDy5bDG7ufXdef2vfN17mZjI6FyYc=.21999f30-4ede-49ff-b6f6-fd36ca530992@github.com>

On Tue, 16 Dec 2025 10:59:16 GMT, Andrew Haley <aph at openjdk.org> wrote:

> I can't really understand why that might matter. I do, though see a possible problem when two threads resolve the same call site. They both lock on`CompiledICLocker`, one wins the race, resolves the site. The other loses, exits, but it sees the patched call site with no intervening ISB. An ISB in `CompiledICLocker::~CompiledICLocker() ` would fix that.

@theRealAph Sorry, I don?t quite understand this point. If the second thread observes the patched stub without the ISB, does that mean it must have observed the patched B .+4 and also the updated MOV instructions, since the visibility of the MOVs is guaranteed to happen before the visibility of the B .+4? If so, what is the problem here? Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26638#issuecomment-3665046658

From aph at openjdk.org  Wed Dec 17 12:14:43 2025
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 17 Dec 2025 12:14:43 GMT
Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() [v6]
In-Reply-To: <nPgiY87FhQoQ-hUDy5bDG7ufXdef2vfN17mZjI6FyYc=.21999f30-4ede-49ff-b6f6-fd36ca530992@github.com>
References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com>
 <CEvEqPtlTMiv7fX1G_spyCpyl8afEZn4McrzIBd5GRY=.d233254e-3626-4044-a3e1-c82bcbd55e45@github.com>
 <6E4yPY9dRcWGBT-vPPq7bOm1NfLdvIfLdecg34f6Tes=.11b0a7c1-798f-4ed2-a521-26059bc0ba5b@github.com>
 <yRkEv29KF1vLIy4V5nKDgQF7CfvVjUjfssdzZ0PccjA=.00171af8-a1aa-401b-9341-a80a6fb4e22e@github.com>
 <yhtSX7dHSCAnDVCm5UX_9Pfx0-P3FnydZOAbRt7-6Ow=.253c5dbb-c7d1-4543-94cc-cbd1a05d5c0e@github.com>
 <TEoePwnDJIw1BQ6kk9-9ggawyVL3luz0rgDALvnN-5Q=.0dfa7cd9-3298-49a7-965d-01d4365986c0@github.com>
 <nPgiY87FhQoQ-hUDy5bDG7ufXdef2vfN17mZjI6FyYc=.21999f30-4ede-49ff-b6f6-fd36ca530992@github.com>
Message-ID: <DuyupqIerQYS62xHWrLNIVvgmg6ehbgNkZtL2N02_HI=.f1d96b9e-425e-417d-b122-5cef558027e9@github.com>

On Wed, 17 Dec 2025 12:06:13 GMT, Fei Gao <fgao at openjdk.org> wrote:

> > I can't really understand why that might matter. I do, though see a possible problem when two threads resolve the same call site. They both lock on`CompiledICLocker`, one wins the race, resolves the site. The other loses, exits, but it sees the patched call site with no intervening ISB. An ISB in `CompiledICLocker::~CompiledICLocker() ` would fix that.
> 
> @theRealAph Sorry, I don?t quite understand this point. If the second thread observes the patched stub without the ISB, does that mean it must have observed the patched B .+4 and also the updated MOV instructions, since the visibility of the MOVs is guaranteed to happen before the visibility of the B .+4? 

That visibility is not guaranteed. A `B .+4` already exists because the static stub has already been patched. We then rewrite the static stub because the destination method moved.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26638#issuecomment-3665067872

From alanb at openjdk.org  Wed Dec 17 12:43:11 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 17 Dec 2025 12:43:11 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting [v6]
In-Reply-To: <uqj0bUkdXgXgqfHQZQoYNd57Civ4eZA_J5ijXvjxBXw=.9ad57214-28a8-4431-bef5-b54c5b3a2377@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
 <uqj0bUkdXgXgqfHQZQoYNd57Civ4eZA_J5ijXvjxBXw=.9ad57214-28a8-4431-bef5-b54c5b3a2377@github.com>
Message-ID: <qOhoXNM5IZb-rp2wf3RmXeXjNYVhuqhsnBxEUbVvgs0=.1839d452-03b0-4744-89f8-3248c9791b84@github.com>

On Tue, 16 Dec 2025 18:54:34 GMT, Chen Liang <liach at openjdk.org> 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 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:
> 
>  - Recommended test tweaks
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting
>  - Jorn review
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting
>  - bracket styles
>  - Doc tweaks
>  - Essay
>  - Spurious change
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/c6348e62...567e8925

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28540#pullrequestreview-3587543908

From roland at openjdk.org  Wed Dec 17 12:44:19 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Wed, 17 Dec 2025 12:44:19 GMT
Subject: RFR: 8370519: C2: Hit MemLimit when running with
 +VerifyLoopOptimizations [v6]
In-Reply-To: <ivWBI33pO0sKOtifG2aGTozX0ybXkxSazNW-T5rpJyU=.a77a85c6-3540-4ce8-8b82-db7bae444615@github.com>
References: <W7EnT28-84mtwppISdr_ydCV9HSaXk72y7fyd29z4wQ=.7331c81d-c36f-4a1c-b949-e7045f524d07@github.com>
 <ivWBI33pO0sKOtifG2aGTozX0ybXkxSazNW-T5rpJyU=.a77a85c6-3540-4ce8-8b82-db7bae444615@github.com>
Message-ID: <KqRz0yHhWdztoyphniPDKQYkFqQXtjQWhswjx9NeLVk=.ea9c0b2f-0394-4c2a-87a5-1ab345d7e45d@github.com>

On Thu, 11 Dec 2025 15:42:42 GMT, Roland Westrelin <roland at openjdk.org> 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

Anyone else for a review of this change?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28581#issuecomment-3665173297

From jbhateja at openjdk.org  Wed Dec 17 12:56:01 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 17 Dec 2025 12:56:01 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v9]
In-Reply-To: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
Message-ID: <tRwCEAHLj8beRKhrrlMdf3Ng0iDe6YnJYcbvWNyvxRE=.d2da523d-8f57-4554-a3e3-0604e05fd214@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.
> 
> <img width="1344" height="532" alt="image" src="https://github.com/user-attachments/assets/c8157c3c-22b0-4bc1-9de9-7a68cadb7b2a" />
> 
> Initial RFP[1] was floated on the panama-dev mailing list.
> 
> Kindly review the draft PR and share your feedback.
> 
> Best Regards,
> Jatin
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html

Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:

 - Fix from Bhavana Kilambi for failing JTREG regressions on AARCH64
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
 - Including test changes from Bhavana Kilambi (ARM)
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
 - Optimizing tail handling
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
 - Cleanups
 - Fix failing jtreg test in CI
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
 - Cleanups
 - ... and 13 more: https://git.openjdk.org/jdk/compare/5e7ae281...703f313d

-------------

Changes: https://git.openjdk.org/jdk/pull/28002/files
  Webrev: Webrev is not available because diff is too large
  Stats: 515408 lines in 232 files changed: 284464 ins; 229217 del; 1727 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 iklam at openjdk.org  Wed Dec 17 13:22:44 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 17 Dec 2025 13:22:44 GMT
Subject: RFR: 8373800: Remove ScopedValueBindingsResolver [v2]
In-Reply-To: <jYYC_M53P-r_-1e3rGwhpeOCylF0tJWl3pkTfkL46eY=.f3bfc95a-f528-437d-9142-f82277bf6acb@github.com>
References: <SlF9UG1hEtDxTxkDwxzFdFDUSVYRQXdssqR9sdjcSkE=.3061bd47-e191-486b-a07f-9d44e3b8c80d@github.com>
 <jYYC_M53P-r_-1e3rGwhpeOCylF0tJWl3pkTfkL46eY=.f3bfc95a-f528-437d-9142-f82277bf6acb@github.com>
Message-ID: <shhaRQraiqJZ4KzwJjURkjbJ2mdn31oCqHQ51gynNZE=.615390c8-9fe2-48cb-9aec-178f636221b0@github.com>

On Tue, 16 Dec 2025 20:24:47 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @AlanBateman comment: remove "JEP 506"
>
> This class was originally in `jdk.incubator` so it had to be resolved this way. Not necessary any more indeed.
> 
> https://github.com/openjdk/jdk/pull/10952/files#diff-50437abcc14d6d69f89f6a6566f1ed016f60a8c2173d43cd681727b46a0dd314R1370

Thanks @liach @AlanBateman for the review

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28849#issuecomment-3665319872

From iklam at openjdk.org  Wed Dec 17 13:22:45 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 17 Dec 2025 13:22:45 GMT
Subject: Integrated: 8373800: Remove ScopedValueBindingsResolver
In-Reply-To: <SlF9UG1hEtDxTxkDwxzFdFDUSVYRQXdssqR9sdjcSkE=.3061bd47-e191-486b-a07f-9d44e3b8c80d@github.com>
References: <SlF9UG1hEtDxTxkDwxzFdFDUSVYRQXdssqR9sdjcSkE=.3061bd47-e191-486b-a07f-9d44e3b8c80d@github.com>
Message-ID: <sOf5hhrJffgBIoZjYDVgTM_h5-V5Gj8wPF_GvRgCXw8=.09f5e609-018c-436c-97ef-21a1dc69d3da@github.com>

On Tue, 16 Dec 2025 14:44:47 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The `ScopedValueBindingsResolver::ScopedValueBindingsResolver()` constructor is invoked the first time 
> `JVM_FindScopedValueBindings` is invoked, and may cause unexpected behavior if the loading of the `ScopedValue$Carrier` class fails to load (due to OOM, etc).
> 
> With this PR, `ScopedValue$Carrier` is loaded during bootstrap with all other `vmClasses`.

This pull request has now been integrated.

Changeset: 39306d7a
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/39306d7ab901a1d27d9bfd80f04d917b4d17d07f
Stats:     15 lines in 2 files changed: 3 ins; 11 del; 1 mod

8373800: Remove ScopedValueBindingsResolver

Reviewed-by: alanb, liach

-------------

PR: https://git.openjdk.org/jdk/pull/28849

From epeter at openjdk.org  Wed Dec 17 13:48:17 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 17 Dec 2025 13:48:17 GMT
Subject: RFR: 8370519: C2: Hit MemLimit when running with
 +VerifyLoopOptimizations [v6]
In-Reply-To: <ivWBI33pO0sKOtifG2aGTozX0ybXkxSazNW-T5rpJyU=.a77a85c6-3540-4ce8-8b82-db7bae444615@github.com>
References: <W7EnT28-84mtwppISdr_ydCV9HSaXk72y7fyd29z4wQ=.7331c81d-c36f-4a1c-b949-e7045f524d07@github.com>
 <ivWBI33pO0sKOtifG2aGTozX0ybXkxSazNW-T5rpJyU=.a77a85c6-3540-4ce8-8b82-db7bae444615@github.com>
Message-ID: <ARZ0GBSVkVCBELoVRy1H-zNuGfKdfOWIzi2cca6-uGQ=.f9bad95a-aa09-4193-aff0-bae365732399@github.com>

On Thu, 11 Dec 2025 15:42:42 GMT, Roland Westrelin <roland at openjdk.org> 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

Looks good to me. We should have done this a while ago anyway.

The only question I have is about reducing the test. @benoitmaillard did you make any progress with that?

-------------

Marked as reviewed by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28581#pullrequestreview-3587834222

From roland at openjdk.org  Wed Dec 17 14:06:48 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Wed, 17 Dec 2025 14:06:48 GMT
Subject: RFR: 8373343: C2: verify AddP base input only set for heap
 addresses [v2]
In-Reply-To: <vUMsaQLeZqS9yC_nnkLQXxAjcNthZ_89LDPC3DQfi4Y=.42122b7d-b735-48e6-a00e-ef3407ea2580@github.com>
References: <fdm8TK_FBJheQ_Wkd_KobosU0uTioUuRZhIK38I3Q-g=.8ae8e498-9c14-4cae-8e68-4c39914a8195@github.com>
 <UX4WA3wQ60ySAOYpdd6MJW5J5QXbqh6wvlhRlJecNxw=.7486aee9-e91f-45ef-bae0-12f4c24b07ca@github.com>
 <ElVoKrC0Z5p63UyUoOBBfEvSjhSJH6dmGtb6540aPqU=.6d30cdcc-6419-4238-b8b4-d52522e4ba9c@github.com>
 <vUMsaQLeZqS9yC_nnkLQXxAjcNthZ_89LDPC3DQfi4Y=.42122b7d-b735-48e6-a00e-ef3407ea2580@github.com>
Message-ID: <Zbm9YhaKSNO0hQ5JdKgg1MEksFz-7EKLx8ffbgIHQwY=.9bf2d725-6ef5-44bb-95d8-a54479fb1299@github.com>

On Wed, 17 Dec 2025 03:00:34 GMT, Dean Long <dlong at openjdk.org> wrote:

>> `isa_oopptr()` is non null for all oops, array and instance.
>
> It seems like "dest" is always an oop here and we don't need to check isa_oopptr().

It is always an heap address. But when used at object creation time, it's not yet an oop. It only becomes one once it is initialized. For those `Store`s to the not yet initialized object, I don't think the base edge is needed (there can't be any safepoint until the object becomes an actual oop) and code elsewhere (`InitializeNode::capture_store()`) doesn't set the base input either.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28769#discussion_r2627200158

From mbaesken at openjdk.org  Wed Dec 17 14:12:33 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 17 Dec 2025 14:12:33 GMT
Subject: RFR: 8372348: Adjust some UL / JFR string deduplication output
 messages [v2]
In-Reply-To: <NF3bJuTenP1wrJrzegI0y8OcEopc3cSXNQly_3MIsmg=.d13c8927-ba7a-4bbb-af54-099e39869879@github.com>
References: <7-XRp229KFw3V2bFPMnaWaoPdF3ZCYVNuViEo2O7eUI=.e0247347-188b-44bf-935c-6b0186026fd3@github.com>
 <0SYxg-Sftdzpna9ftRjMfLGNf2D5JztmR8G5kdjPWnU=.6cd25f16-31f2-4658-86ed-3fe2216dc20d@github.com>
 <NF3bJuTenP1wrJrzegI0y8OcEopc3cSXNQly_3MIsmg=.d13c8927-ba7a-4bbb-af54-099e39869879@github.com>
Message-ID: <YqMxjK1RnFYtpjjU5oP24tnm_qEUDf3tktjUSWyMynQ=.5ace1bbb-dd26-4d7a-8402-b9d58021e9bc@github.com>

On Wed, 17 Dec 2025 08:58:15 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Enhance output
>
> src/hotspot/share/gc/shared/stringdedup/stringDedupStat.cpp line 107:
> 
>> 105:     last_stat->_deduped, STRDEDUP_BYTES_PARAM(last_stat->_deduped_bytes),
>> 106:     percent_of(total_stat->_deduped_bytes, total_stat->_new_bytes),
>> 107:     total_stat->_deduped_bytes, total_stat->_new_bytes,
> 
> Shouldn't these two use `STRDEDUP_BYTES_FORMAT` and `STRDEDUP_BYTES_PARAM`?

Yeah seems so,  this is what is used for `  STRDEDUP_BYTES_PARAM(last_stat->_new_bytes), STRDEDUP_BYTES_PARAM(last_stat->_deduped_bytes),`  .

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28455#discussion_r2627221140

From heidinga at openjdk.org  Wed Dec 17 14:29:10 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Wed, 17 Dec 2025 14:29:10 GMT
Subject: RFR: 8373392: Replace CDS object subgraphs with
 @AOTSafeClassInitializer
In-Reply-To: <nwFU9L_ngxAg_QtXjVq_IvhIxlnHj49sWV-qMUCS0YY=.4417a88a-c604-415f-b389-12a19938fed3@github.com>
References: <nwFU9L_ngxAg_QtXjVq_IvhIxlnHj49sWV-qMUCS0YY=.4417a88a-c604-415f-b389-12a19938fed3@github.com>
Message-ID: <vg9pS9ukU_J_ogGf-tX36gZME8MV6KyXCab-IeJecjQ=.4f170715-ccfd-4486-8449-68442d361533@github.com>

On Wed, 10 Dec 2025 09:31:37 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> In legacy CDS, Java objects used by certain classes are computed ahead of time using "object subgraphs"
> 
> https://github.com/openjdk/jdk/blob/1bbbce75c5e68429c2a32519eb3c36d964dcdf57/src/hotspot/share/cds/heapShared.cpp#L168-L171
> 
> Examples of subgraphs:
> 
> - `java.lang.Integer$IntegerCache::cache`
> - `jdk.internal.module.ArchivedBootLayer::bootLayer`
> 
> The implementation requires special code (in both Java and C++) to be executed when a CDS archive is created or loaded. As a result, we have an execution model that's difficult to implement/extend and the behavior is hard to understand.
> 
> To move towards the AOT Cache Snapshot Model ([JDK-8365645](https://bugs.openjdk.org/browse/JDK-8365645)) we should replace the subgraphs with the use of `@AOTSafeClassInitializer`, and if necessary, `@AOTRuntimeSetup`. This will simplify the current implementation, and make it possible to extend AOT-initializations to more core classes.
> 
> Note, the use of `@AOTSafeClassInitializer` requires `-XX:+AOTClassLinking`. For the time being, we retain the old CDS object subgraph code to cover the `-XX:-AOTClassLinking` cases. Such code will be marked with comments like `/* Legacy CDS archive support (to be deprecated) */`. All future AOT creation of Java objects will be done with  `@AOTSafeClassInitializer`.

Marked as reviewed by heidinga (no project role).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28736#pullrequestreview-3588008090

From mbaesken at openjdk.org  Wed Dec 17 14:37:57 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 17 Dec 2025 14:37:57 GMT
Subject: RFR: 8372348: Adjust some UL / JFR string deduplication output
 messages [v3]
In-Reply-To: <7-XRp229KFw3V2bFPMnaWaoPdF3ZCYVNuViEo2O7eUI=.e0247347-188b-44bf-935c-6b0186026fd3@github.com>
References: <7-XRp229KFw3V2bFPMnaWaoPdF3ZCYVNuViEo2O7eUI=.e0247347-188b-44bf-935c-6b0186026fd3@github.com>
Message-ID: <jh6UcHdAQpaGgoqjGJOAehHx8rHSzK6UGz5uZbokSLg=.03c23543-b08c-4bb6-87f4-6894f03644ee@github.com>

> There is some UL output in the string deduplication code that is not very clear and has room for improvement.
> The inspected strings number should be shown and the new unknown strings get a changed text.
> (also the new JFR strip dedup event  description is slightly adjusted)

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Adjust output

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28455/files
  - new: https://git.openjdk.org/jdk/pull/28455/files/ba0e3410..2eb2857a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28455&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28455&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28455.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28455/head:pull/28455

PR: https://git.openjdk.org/jdk/pull/28455

From bmaillard at openjdk.org  Wed Dec 17 14:41:15 2025
From: bmaillard at openjdk.org (=?UTF-8?B?QmVub8OudA==?= Maillard)
Date: Wed, 17 Dec 2025 14:41:15 GMT
Subject: RFR: 8370519: C2: Hit MemLimit when running with
 +VerifyLoopOptimizations [v6]
In-Reply-To: <rFGy_mZFS29oe2Ie23rRCqFQigWHLghMgum7heKDZcw=.8447fff4-e59d-4ea0-9005-9e5f71930489@github.com>
References: <W7EnT28-84mtwppISdr_ydCV9HSaXk72y7fyd29z4wQ=.7331c81d-c36f-4a1c-b949-e7045f524d07@github.com>
 <rFGy_mZFS29oe2Ie23rRCqFQigWHLghMgum7heKDZcw=.8447fff4-e59d-4ea0-9005-9e5f71930489@github.com>
Message-ID: <7766DTMPPwqyQJVBI6QwIM0G1Y1_4iUrTjzdsddRpb4=.b1b3a551-7546-4e26-b2bf-02203611b28a@github.com>

On Mon, 1 Dec 2025 16:52:39 GMT, Beno?t Maillard <bmaillard at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   package declaration
>
> Thanks for fixing this @rwestrel, I agree with the solution. I noticed that this could be a problem while working on [JDK-8366990](https://bugs.openjdk.org/browse/JDK-8366990), but there was no reproducer at the time.

> The only question I have is about reducing the test. @benoitmaillard did you make any progress with that?

Still a WIP, I had to restart the script a few times, it's a bit of trial and error in this case. I was initially able to reduce the code by a large margin, but it still took a long time to run. Now I am trying to reduce the memory available with `-XX:CompileCommand=memlimit` to see if we can make it fail faster @eme64.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28581#issuecomment-3665654318

From fandreuzzi at openjdk.org  Wed Dec 17 15:39:20 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 17 Dec 2025 15:39:20 GMT
Subject: RFR: 8372348: Adjust some UL / JFR string deduplication output
 messages [v3]
In-Reply-To: <jh6UcHdAQpaGgoqjGJOAehHx8rHSzK6UGz5uZbokSLg=.03c23543-b08c-4bb6-87f4-6894f03644ee@github.com>
References: <7-XRp229KFw3V2bFPMnaWaoPdF3ZCYVNuViEo2O7eUI=.e0247347-188b-44bf-935c-6b0186026fd3@github.com>
 <jh6UcHdAQpaGgoqjGJOAehHx8rHSzK6UGz5uZbokSLg=.03c23543-b08c-4bb6-87f4-6894f03644ee@github.com>
Message-ID: <nVbMDwqmxPqaz5-Du6P7sP1S4tyXVXXhp2IoWPNHuqU=.6e373a00-8d68-4f11-8671-7d308721faf3@github.com>

On Wed, 17 Dec 2025 14:37:57 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There is some UL output in the string deduplication code that is not very clear and has room for improvement.
>> The inspected strings number should be shown and the new unknown strings get a changed text.
>> (also the new JFR strip dedup event  description is slightly adjusted)
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust output

Marked as reviewed by fandreuzzi (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28455#pullrequestreview-3588334817

From tschatzl at openjdk.org  Wed Dec 17 15:42:24 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 17 Dec 2025 15:42:24 GMT
Subject: RFR: 8373801: Adopt arraycopy OopCopyResult from the lworld branch
 [v2]
In-Reply-To: <xL27bPDF6Wl05dCXSghM4SdhK_iuMvlZW4J4LsvAJ9M=.6d00cb20-6661-470f-aa85-2846d56fede8@github.com>
References: <vuovhgARk6krDotYQS-asHzFkm93v8hPWx4zLwT1xC0=.fd37e81f-8714-40b7-a099-58fc653cd2e4@github.com>
 <xL27bPDF6Wl05dCXSghM4SdhK_iuMvlZW4J4LsvAJ9M=.6d00cb20-6661-470f-aa85-2846d56fede8@github.com>
Message-ID: <MMw13rmdHpChxmyqAWMHqAgrg70y0Gw2-L57fFf3ErM=.050e17f8-d9cd-48dd-9292-f456553fe164@github.com>

On Tue, 16 Dec 2025 15:04:44 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> In the Valhalla project there's code to restrict nulls in object arrays. In the GC arraycopy barrier we there have to both do null checks in addition to the already existing cast checks. If one of these two failed the code needs to propagate this up through the callers to the code that asked to do the checks. There it will throw the suitable exception. Previously, it was enough to say success or failed, and a boolean was enough. Now we need three states. So the bool was replaced with an OopCopyResult enum.
>> 
>> See: https://github.com/openjdk/valhalla/pull/1792
>> 
>> I propose that we bring this over to the mainline to lower the diff between lworld and the openjdk/jdk.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove throw NPE function

Marked as reviewed by tschatzl (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28850#pullrequestreview-3588346814

From fgao at openjdk.org  Wed Dec 17 15:43:35 2025
From: fgao at openjdk.org (Fei Gao)
Date: Wed, 17 Dec 2025 15:43:35 GMT
Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() [v6]
In-Reply-To: <DuyupqIerQYS62xHWrLNIVvgmg6ehbgNkZtL2N02_HI=.f1d96b9e-425e-417d-b122-5cef558027e9@github.com>
References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com>
 <CEvEqPtlTMiv7fX1G_spyCpyl8afEZn4McrzIBd5GRY=.d233254e-3626-4044-a3e1-c82bcbd55e45@github.com>
 <6E4yPY9dRcWGBT-vPPq7bOm1NfLdvIfLdecg34f6Tes=.11b0a7c1-798f-4ed2-a521-26059bc0ba5b@github.com>
 <yRkEv29KF1vLIy4V5nKDgQF7CfvVjUjfssdzZ0PccjA=.00171af8-a1aa-401b-9341-a80a6fb4e22e@github.com>
 <yhtSX7dHSCAnDVCm5UX_9Pfx0-P3FnydZOAbRt7-6Ow=.253c5dbb-c7d1-4543-94cc-cbd1a05d5c0e@github.com>
 <TEoePwnDJIw1BQ6kk9-9ggawyVL3luz0rgDALvnN-5Q=.0dfa7cd9-3298-49a7-965d-01d4365986c0@github.com>
 <nPgiY87FhQoQ-hUDy5bDG7ufXdef2vfN17mZjI6FyYc=.21999f30-4ede-49ff-b6f6-fd36ca530992@github.com>
 <DuyupqIerQYS62xHWrLNIVvgmg6ehbgNkZtL2N02_HI=.f1d96b9e-425e-417d-b122-5cef558027e9@github.com>
Message-ID: <cHbuIgpwzbNOERsbubuipYsFPkqaBwAJIVvZhNLSdos=.8844631c-6f63-4a45-ae8a-a5e8523e47df@github.com>

On Wed, 17 Dec 2025 12:12:07 GMT, Andrew Haley <aph at openjdk.org> wrote:

> 
> That visibility is not guaranteed. A `B .+4` already exists because the static stub has already been patched. We then rewrite the static stub because the destination method moved.

I see. Thanks for your explanation!

> What about a 3rd thread that sees the call site already resolved so never calls the resolve helper? It won't execute an ISB either. I thought the ISB was only needed to see changes to the stub, not the call site.

Assume the following race:
- One thread has already entered the resolver and started patching, but has not yet completed.
- Another thread has **not** observed the updated call site, but **has** observed the patched trampoline stub and therefore reaches the static call stub directly via the trampoline stub.

In this case, the second thread will not execute the resolver. An ISB in `CompiledICLocker::~CompiledICLocker()` would not address this scenario, because the second thread never goes through the resolver path and therefore never executes that ISB. As a result, the second thread may execute stale MOV instructions in the static call stub. Would that be a problem? I?m not sure whether this is what @dean-long had in mind.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26638#issuecomment-3665933390

From pchilanomate at openjdk.org  Wed Dec 17 16:07:47 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 17 Dec 2025 16:07:47 GMT
Subject: RFR: 8372591: assert(!current->cont_fastpath() ||
 freeze.check_valid_fast_path()) failed
In-Reply-To: <273aHscNQPebiQ456y_i91um8SqD6uEkGJyrSSiHGjQ=.0c8a0f01-9281-433e-a386-be913a985b90@github.com>
References: <6yaYr_fSazq20-3lshGS-_Lr-LqXMt4lTeaFzDs9U2U=.c865efd1-9b98-4fce-98dd-4e1fe50a45be@github.com>
 <273aHscNQPebiQ456y_i91um8SqD6uEkGJyrSSiHGjQ=.0c8a0f01-9281-433e-a386-be913a985b90@github.com>
Message-ID: <jum-niu-IXNrZiFdqS66xnTCRqR4AdeKsclzKAOpC5c=.4a65c50a-1b27-4e4d-89db-e4743abcaa82@github.com>

On Wed, 17 Dec 2025 06:50:04 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > 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.
> 
> I think what you have is good but maybe me wonder if there might be other corner cases that might need further Continuations tests.
>
I can't think of others looking at the code. But `OSRTest.java` covers many different OSR scenarios already with methods that have many parameters.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28830#issuecomment-3666034208

From pchilanomate at openjdk.org  Wed Dec 17 16:07:50 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 17 Dec 2025 16:07:50 GMT
Subject: RFR: 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: <b3Mf46Q2dDfEkwS-Uf7ghM8YeomEQUfSiKNm8LzCkc8=.89499554-f641-4348-a131-05b41ff2430c@github.com>

On Mon, 15 Dec 2025 16:53:05 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> When a frame is OSR and the caller is interpreted we call `push_cont_fastpath` to possible set `_cont_fastpath` to the `sp` of the sender. This is needed in order to keep track of interpreted frames in the stack, so that in case of unmounting we don't incorrectly execute the freeze fast path, which is only allowed when all frames are compiled.
> 
> The problem is that the OSR frame is created starting from the `unextended_sp` of the sender, not the `sp`, i.e we pop the interpreted frame like in `remove_activation`. This means that we could set a value to `_cont_fastpath` that will point outside the valid stack (below the `sp` of the OSR frame). If the gap between these stack addresses is big enough, `_cont_fastpath` could be later cleared while we still have the interpreter sender in the stack, leading to the reported crash. The simplest case where this will happen is if in a later call to yield all the extra frames leading to `Continuation.doYield` fit within this space [[1]](https://github.com/openjdk/jdk/blob/ad29642d8f4e8e0fb1223b14b85ab7841d7b1b51/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L232). It could also be cleared before that if for example at some point we returned from an interpreted callee and the sender sp it's not below `_cont_fastpath`[[2]](https://github.com/openjdk/jdk/blob/ad29642d8f4e8e0fb1223b
 14b85ab7841d7b1b51/src/hotspot/cpu/x86/interp_masm_x86.cpp#L1060).
> 
> The fix is to change `OSR_migration_begin` to set `_cont_fastpath` with the sender's `unextended_sp` instead. 
> 
> The patch includes new test `OSRWithManyLocals.java` which reliably reproduces the crash. I thought about adding it to the existing `OSRTest.java` but that was created to exercise a different issue. A better name for that test would be `OSRWithManyArgs.java`, so I could rename it in this patch if preferred (I also realized that test could be simplified and made easier to read but that's for another PR).
> 
> I tested the current patch with the new test and also run it through mach5 tiers1-7.
> 
> Thanks,
> Patricio

Thanks for the reviews David and Alan!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28830#issuecomment-3666036171

From pchilanomate at openjdk.org  Wed Dec 17 16:10:56 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 17 Dec 2025 16:10:56 GMT
Subject: RFR: 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: <_LgB7c2fIE-RBo1CpmjeirR4oG6v8JBVQZ8spZzDLY8=.a67da689-d204-4550-86b6-c0efde380892@github.com>

On Mon, 15 Dec 2025 16:53:05 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> When a frame is OSR and the caller is interpreted we call `push_cont_fastpath` to possible set `_cont_fastpath` to the `sp` of the sender. This is needed in order to keep track of interpreted frames in the stack, so that in case of unmounting we don't incorrectly execute the freeze fast path, which is only allowed when all frames are compiled.
> 
> The problem is that the OSR frame is created starting from the `unextended_sp` of the sender, not the `sp`, i.e we pop the interpreted frame like in `remove_activation`. This means that we could set a value to `_cont_fastpath` that will point outside the valid stack (below the `sp` of the OSR frame). If the gap between these stack addresses is big enough, `_cont_fastpath` could be later cleared while we still have the interpreter sender in the stack, leading to the reported crash. The simplest case where this will happen is if in a later call to yield all the extra frames leading to `Continuation.doYield` fit within this space [[1]](https://github.com/openjdk/jdk/blob/ad29642d8f4e8e0fb1223b14b85ab7841d7b1b51/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L232). It could also be cleared before that if for example at some point we returned from an interpreted callee and the sender sp it's not below `_cont_fastpath`[[2]](https://github.com/openjdk/jdk/blob/ad29642d8f4e8e0fb1223b
 14b85ab7841d7b1b51/src/hotspot/cpu/x86/interp_masm_x86.cpp#L1060).
> 
> The fix is to change `OSR_migration_begin` to set `_cont_fastpath` with the sender's `unextended_sp` instead. 
> 
> The patch includes new test `OSRWithManyLocals.java` which reliably reproduces the crash. I thought about adding it to the existing `OSRTest.java` but that was created to exercise a different issue. A better name for that test would be `OSRWithManyArgs.java`, so I could rename it in this patch if preferred (I also realized that test could be simplified and made easier to read but that's for another PR).
> 
> I tested the current patch with the new test and also run it through mach5 tiers1-7.
> 
> Thanks,
> Patricio

@reinrich @TheRealMDoerr Could you verify if this fix is correct for ppc too? Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28830#issuecomment-3666056474

From lucy at openjdk.org  Wed Dec 17 17:23:27 2025
From: lucy at openjdk.org (Lutz Schmidt)
Date: Wed, 17 Dec 2025 17:23:27 GMT
Subject: RFR: 8372348: Adjust some UL / JFR string deduplication output
 messages [v3]
In-Reply-To: <jh6UcHdAQpaGgoqjGJOAehHx8rHSzK6UGz5uZbokSLg=.03c23543-b08c-4bb6-87f4-6894f03644ee@github.com>
References: <7-XRp229KFw3V2bFPMnaWaoPdF3ZCYVNuViEo2O7eUI=.e0247347-188b-44bf-935c-6b0186026fd3@github.com>
 <jh6UcHdAQpaGgoqjGJOAehHx8rHSzK6UGz5uZbokSLg=.03c23543-b08c-4bb6-87f4-6894f03644ee@github.com>
Message-ID: <cb-tfhFA1PPTk7ltIYZ1CJNfAVnlf8kyvSO69i1dGY4=.4ddb0c59-9e5f-418c-8353-5a1330ef486b@github.com>

On Wed, 17 Dec 2025 14:37:57 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There is some UL output in the string deduplication code that is not very clear and has room for improvement.
>> The inspected strings number should be shown and the new unknown strings get a changed text.
>> (also the new JFR strip dedup event  description is slightly adjusted)
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust output

This looks good.

-------------

Marked as reviewed by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28455#pullrequestreview-3588780858

From iklam at openjdk.org  Wed Dec 17 17:46:59 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 17 Dec 2025 17:46:59 GMT
Subject: RFR: 8373114: Redundant MethodCounters in the preimage generated
 by training run [v3]
In-Reply-To: <Ftzehw6uU22VX960CToHi7NxdC8d5OR5Nd_emv7hSjQ=.9c31a575-0e6b-4e01-a454-d7e6c172a034@github.com>
References: <LRw06Cn_4dcRW8YyFVr3RijMHIha7nPzBrcNNzaIny8=.dc07d0ee-b797-4434-aad0-956a00c2ea6f@github.com>
 <Ftzehw6uU22VX960CToHi7NxdC8d5OR5Nd_emv7hSjQ=.9c31a575-0e6b-4e01-a454-d7e6c172a034@github.com>
Message-ID: <SY6s8GGmGKLNTY0t1Q6Zy_5e1k2gGeBF4L9AjV6f6xc=.e74128b2-7a1f-4a56-ae0f-ca7afcd90983@github.com>

On Tue, 9 Dec 2025 02:39:41 GMT, Ashutosh Mehra <asmehra at openjdk.org> 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 <asmehra at redhat.com>

LGTM

-------------

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28670#pullrequestreview-3588874442

From iklam at openjdk.org  Wed Dec 17 18:16:23 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 17 Dec 2025 18:16:23 GMT
Subject: RFR: 8373392: Replace CDS object subgraphs with
 @AOTSafeClassInitializer [v2]
In-Reply-To: <nwFU9L_ngxAg_QtXjVq_IvhIxlnHj49sWV-qMUCS0YY=.4417a88a-c604-415f-b389-12a19938fed3@github.com>
References: <nwFU9L_ngxAg_QtXjVq_IvhIxlnHj49sWV-qMUCS0YY=.4417a88a-c604-415f-b389-12a19938fed3@github.com>
Message-ID: <y7hJSyxC6Co9pbu_Zovdo4Orxlom23jJ5IOetBVqLIs=.e33daeb4-a1ed-4f28-b667-981de2058a29@github.com>

> In legacy CDS, Java objects used by certain classes are computed ahead of time using "object subgraphs"
> 
> https://github.com/openjdk/jdk/blob/1bbbce75c5e68429c2a32519eb3c36d964dcdf57/src/hotspot/share/cds/heapShared.cpp#L168-L171
> 
> Examples of subgraphs:
> 
> - `java.lang.Integer$IntegerCache::cache`
> - `jdk.internal.module.ArchivedBootLayer::bootLayer`
> 
> The implementation requires special code (in both Java and C++) to be executed when a CDS archive is created or loaded. As a result, we have an execution model that's difficult to implement/extend and the behavior is hard to understand.
> 
> To move towards the AOT Cache Snapshot Model ([JDK-8365645](https://bugs.openjdk.org/browse/JDK-8365645)) we should replace the subgraphs with the use of `@AOTSafeClassInitializer`, and if necessary, `@AOTRuntimeSetup`. This will simplify the current implementation, and make it possible to extend AOT-initializations to more core classes.
> 
> Note, the use of `@AOTSafeClassInitializer` requires `-XX:+AOTClassLinking`. For the time being, we retain the old CDS object subgraph code to cover the `-XX:-AOTClassLinking` cases. Such code will be marked with comments like `/* Legacy CDS archive support (to be deprecated) */`. All future AOT creation of Java objects will be done with  `@AOTSafeClassInitializer`.

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 three additional commits since the last revision:

 - @liach comment: Fixed identation
 - Merge branch 'master' into 8373392-replace-cds-object-subgraphs-with-aot-safe-class-initializer
 - 8373392: Replace CDS object subgraphs with @AOTSafeClassInitializer

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28736/files
  - new: https://git.openjdk.org/jdk/pull/28736/files/562d15a9..5497502f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28736&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28736&range=00-01

  Stats: 15093 lines in 587 files changed: 9847 ins; 1687 del; 3559 mod
  Patch: https://git.openjdk.org/jdk/pull/28736.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28736/head:pull/28736

PR: https://git.openjdk.org/jdk/pull/28736

From aph at openjdk.org  Wed Dec 17 18:21:03 2025
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 17 Dec 2025 18:21:03 GMT
Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() [v6]
In-Reply-To: <cHbuIgpwzbNOERsbubuipYsFPkqaBwAJIVvZhNLSdos=.8844631c-6f63-4a45-ae8a-a5e8523e47df@github.com>
References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com>
 <CEvEqPtlTMiv7fX1G_spyCpyl8afEZn4McrzIBd5GRY=.d233254e-3626-4044-a3e1-c82bcbd55e45@github.com>
 <6E4yPY9dRcWGBT-vPPq7bOm1NfLdvIfLdecg34f6Tes=.11b0a7c1-798f-4ed2-a521-26059bc0ba5b@github.com>
 <yRkEv29KF1vLIy4V5nKDgQF7CfvVjUjfssdzZ0PccjA=.00171af8-a1aa-401b-9341-a80a6fb4e22e@github.com>
 <yhtSX7dHSCAnDVCm5UX_9Pfx0-P3FnydZOAbRt7-6Ow=.253c5dbb-c7d1-4543-94cc-cbd1a05d5c0e@github.com>
 <TEoePwnDJIw1BQ6kk9-9ggawyVL3luz0rgDALvnN-5Q=.0dfa7cd9-3298-49a7-965d-01d4365986c0@github.com>
 <nPgiY87FhQoQ-hUDy5bDG7ufXdef2vfN17mZjI6FyYc=.21999f30-4ede-49ff-b6f6-fd36ca530992@github.com>
 <DuyupqIerQYS62xHWrLNIVvgmg6ehbgNkZtL2N02_HI=.f1d96b9e-425e-417d-b122-5cef558027e9@github.com>
 <cHbuIgpwzbNOERsbubuipYsFPkqaBwAJIVvZhNLSdos=.8844631c-6f63-4a45-ae8a-a5e8523e47df@github.com>
Message-ID: <2-SaowCI03bZE2PdHEwG7LPwbIRnFwQ7oMRS58kchXg=.a36c6bcd-0e38-4ba1-97aa-a0cfdc66ef86@github.com>

On Wed, 17 Dec 2025 15:39:49 GMT, Fei Gao <fgao at openjdk.org> wrote:

> Assume the following race:
> 
>     * One thread has already entered the resolver and started patching, but has not yet completed.
> 
>     * Another thread has **not** observed the updated call site, but **has** observed the patched trampoline stub and therefore reaches the static call stub directly via the trampoline stub.

OK.

> In this case, the second thread will not execute the resolver. An ISB in `CompiledICLocker::~CompiledICLocker()` would not address this scenario, because the second thread never goes through the resolver path and therefore never executes that ISB. As a result, the second thread may execute stale MOV instructions in the static call stub. Would that be a problem? 

I don't think that's possible, because rewriting when a class gets redefined only happens at a safepoint. So I think we're OK, probably.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26638#issuecomment-3666589717

From wkemper at openjdk.org  Wed Dec 17 19:39:57 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 17 Dec 2025 19:39:57 GMT
Subject: RFR: 8373203: Genshen: Non-strong reference leak in old gen [v4]
In-Reply-To: <JaJt39rlIHDKUiyQmDuh0uSyVslFVLKisMXo0r2gROk=.1056f4b4-441f-4ed2-9e7f-e81cbaca272c@github.com>
References: <JaJt39rlIHDKUiyQmDuh0uSyVslFVLKisMXo0r2gROk=.1056f4b4-441f-4ed2-9e7f-e81cbaca272c@github.com>
Message-ID: <ON4iOBMDZ_XJDitl2YyjjEw2L5UuSc5oFjr2iB6scHQ=.83468810-6a0b-4651-9b1b-ebfda9cf4483@github.com>

> The generational mode for Shenandoah will collect _referents_ for the generation being collected. For example, if we have a young reference pointing to an old referent, that young reference will be processed after we finish marking the old generation. This presents a problem for discovery.
>   
> When the young mark _encounters_ a young reference with an old referent, it cannot _discover_ it because old marking hasn't finished. However, if it does not discover it, the old referent will be strongly marked. This, in turn, will prevent the old generation from clearing the referent (if it even reaches it again during old marking).
>   
> To solve this, we let young reference processing discover the old reference by having it use the old generation reference processor to do so. This means the old reference processor can have a discovered list that contains young weak references. If any of these young references reside in a region that is collected, old reference processing will crash when it processes such a reference. Therefore, we add a method `heal_discovered_lists` to traverse the discovered lists after young evacuation is complete. The method will replace any forwarded entries in the discovered list with the forwardee.
> 
> This PR also extends whitebox testing support for Shenandoah, giving us the ability to trigger young/old collections and interrogate some properties of heaps and regions.

William Kemper has updated the pull request incrementally with one additional commit since the last revision:

  Fix idiosyncratic white space in whitebox
  
  Co-authored-by: Stefan Karlsson <stefan.karlsson at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28810/files
  - new: https://git.openjdk.org/jdk/pull/28810/files/bc42a6ee..74b7307c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28810&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28810&range=02-03

  Stats: 6 lines in 2 files changed: 3 ins; 2 del; 1 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 iklam at openjdk.org  Wed Dec 17 20:04:48 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 17 Dec 2025 20:04:48 GMT
Subject: RFR: 8373392: Replace CDS object subgraphs with
 @AOTSafeClassInitializer [v3]
In-Reply-To: <nwFU9L_ngxAg_QtXjVq_IvhIxlnHj49sWV-qMUCS0YY=.4417a88a-c604-415f-b389-12a19938fed3@github.com>
References: <nwFU9L_ngxAg_QtXjVq_IvhIxlnHj49sWV-qMUCS0YY=.4417a88a-c604-415f-b389-12a19938fed3@github.com>
Message-ID: <ObHUe60IbQtKQeY50_QL4HRA1IB54iUsNL71yo4RcNw=.dc0d6b3e-33d3-49ff-b468-dd99d59592a2@github.com>

> In legacy CDS, Java objects used by certain classes are computed ahead of time using "object subgraphs"
> 
> https://github.com/openjdk/jdk/blob/1bbbce75c5e68429c2a32519eb3c36d964dcdf57/src/hotspot/share/cds/heapShared.cpp#L168-L171
> 
> Examples of subgraphs:
> 
> - `java.lang.Integer$IntegerCache::cache`
> - `jdk.internal.module.ArchivedBootLayer::bootLayer`
> 
> The implementation requires special code (in both Java and C++) to be executed when a CDS archive is created or loaded. As a result, we have an execution model that's difficult to implement/extend and the behavior is hard to understand.
> 
> To move towards the AOT Cache Snapshot Model ([JDK-8365645](https://bugs.openjdk.org/browse/JDK-8365645)) we should replace the subgraphs with the use of `@AOTSafeClassInitializer`, and if necessary, `@AOTRuntimeSetup`. This will simplify the current implementation, and make it possible to extend AOT-initializations to more core classes.
> 
> Note, the use of `@AOTSafeClassInitializer` requires `-XX:+AOTClassLinking`. For the time being, we retain the old CDS object subgraph code to cover the `-XX:-AOTClassLinking` cases. Such code will be marked with comments like `/* Legacy CDS archive support (to be deprecated) */`. All future AOT creation of Java objects will be done with  `@AOTSafeClassInitializer`.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Fixed test case -- the regexp pattern could match the stats for the subgraphs table, which now has a single entry

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28736/files
  - new: https://git.openjdk.org/jdk/pull/28736/files/5497502f..306d9167

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28736&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28736&range=01-02

  Stats: 41 lines in 1 file changed: 38 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/28736.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28736/head:pull/28736

PR: https://git.openjdk.org/jdk/pull/28736

From iklam at openjdk.org  Wed Dec 17 20:08:28 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 17 Dec 2025 20:08:28 GMT
Subject: RFR: 8373392: Replace CDS object subgraphs with
 @AOTSafeClassInitializer [v3]
In-Reply-To: <ObHUe60IbQtKQeY50_QL4HRA1IB54iUsNL71yo4RcNw=.dc0d6b3e-33d3-49ff-b468-dd99d59592a2@github.com>
References: <nwFU9L_ngxAg_QtXjVq_IvhIxlnHj49sWV-qMUCS0YY=.4417a88a-c604-415f-b389-12a19938fed3@github.com>
 <ObHUe60IbQtKQeY50_QL4HRA1IB54iUsNL71yo4RcNw=.dc0d6b3e-33d3-49ff-b468-dd99d59592a2@github.com>
Message-ID: <6Ime-D9wgZGM9Qz-u4IhkQ00fnRPUQOwmX-O70Lz41s=.5c6627aa-9239-4805-987b-aa8c79241f72@github.com>

On Wed, 17 Dec 2025 20:04:48 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> In legacy CDS, Java objects used by certain classes are computed ahead of time using "object subgraphs"
>> 
>> https://github.com/openjdk/jdk/blob/1bbbce75c5e68429c2a32519eb3c36d964dcdf57/src/hotspot/share/cds/heapShared.cpp#L168-L171
>> 
>> Examples of subgraphs:
>> 
>> - `java.lang.Integer$IntegerCache::cache`
>> - `jdk.internal.module.ArchivedBootLayer::bootLayer`
>> 
>> The implementation requires special code (in both Java and C++) to be executed when a CDS archive is created or loaded. As a result, we have an execution model that's difficult to implement/extend and the behavior is hard to understand.
>> 
>> To move towards the AOT Cache Snapshot Model ([JDK-8365645](https://bugs.openjdk.org/browse/JDK-8365645)) we should replace the subgraphs with the use of `@AOTSafeClassInitializer`, and if necessary, `@AOTRuntimeSetup`. This will simplify the current implementation, and make it possible to extend AOT-initializations to more core classes.
>> 
>> Note, the use of `@AOTSafeClassInitializer` requires `-XX:+AOTClassLinking`. For the time being, we retain the old CDS object subgraph code to cover the `-XX:-AOTClassLinking` cases. Such code will be marked with comments like `/* Legacy CDS archive support (to be deprecated) */`. All future AOT creation of Java objects will be done with  `@AOTSafeClassInitializer`.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed test case -- the regexp pattern could match the stats for the subgraphs table, which now has a single entry

I have to fix the SharedSymbolTableBucketSize.java test. With this PR and testing with `-vmoptions:-XX:+AOTClassLinking -vmoptions:-XX:+UseZGC`, the first block of "table stats" has a single entry.

I fixed the test case to look for "Shared symbol table stats", which is the info that the test case intends to check.


[...]
[0.591s][info][cds]     type array classes =     9
[0.591s][info][cds]                symbols = 46244
[0.681s][info][aot,hashtables] Shared subgraphs table stats -------- base: 0x0000000800000000
[0.681s][info][aot,hashtables] Number of entries       :         1
[0.681s][info][aot,hashtables] Total bytes used        :        24
[0.681s][info][aot,hashtables] Average bytes per entry :    24.000
[0.681s][info][aot,hashtables] Average bucket size     :     1.000
[0.681s][info][aot,hashtables] Variance of bucket size :     0.000
[0.681s][info][aot,hashtables] Std. dev. of bucket size:     0.000
[0.681s][info][aot,hashtables] Maximum bucket size     :         1
[0.681s][info][aot,hashtables] Empty buckets           :         0
[0.681s][info][aot,hashtables] Value_Only buckets      :         1
[0.681s][info][aot,hashtables] Other buckets           :         0
[0.688s][info][aot,hashtables] Shared symbol table stats -------- base: 0x0000000800000000
[0.688s][info][aot,hashtables] Number of entries       :     46244
[0.688s][info][aot,hashtables] Total bytes used        :    393792
[0.688s][info][aot,hashtables] Average bytes per entry :     8.516
[0.688s][info][aot,hashtables] Average bucket size     :     7.734
[0.688s][info][aot,hashtables] Variance of bucket size :     7.513
[0.688s][info][aot,hashtables] Std. dev. of bucket size:     2.741
[0.688s][info][aot,hashtables] Maximum bucket size     :        20
[0.688s][info][aot,hashtables] Empty buckets           :         2
[0.688s][info][aot,hashtables] Value_Only buckets      :        24
[0.688s][info][aot,hashtables] Other buckets           :      5953

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28736#issuecomment-3666964418

From mdoerr at openjdk.org  Wed Dec 17 20:33:45 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 17 Dec 2025 20:33:45 GMT
Subject: RFR: 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: <OMSXymeuuZNhw4T78KI11ddVCUFVCuNy3qOr32v5Uvc=.4f7cdf58-3f96-4752-9363-31a09a4e0444@github.com>

On Mon, 15 Dec 2025 16:53:05 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> When a frame is OSR and the caller is interpreted we call `push_cont_fastpath` to possible set `_cont_fastpath` to the `sp` of the sender. This is needed in order to keep track of interpreted frames in the stack, so that in case of unmounting we don't incorrectly execute the freeze fast path, which is only allowed when all frames are compiled.
> 
> The problem is that the OSR frame is created starting from the `unextended_sp` of the sender, not the `sp`, i.e we pop the interpreted frame like in `remove_activation`. This means that we could set a value to `_cont_fastpath` that will point outside the valid stack (below the `sp` of the OSR frame). If the gap between these stack addresses is big enough, `_cont_fastpath` could be later cleared while we still have the interpreter sender in the stack, leading to the reported crash. The simplest case where this will happen is if in a later call to yield all the extra frames leading to `Continuation.doYield` fit within this space [[1]](https://github.com/openjdk/jdk/blob/ad29642d8f4e8e0fb1223b14b85ab7841d7b1b51/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L232). It could also be cleared before that if for example at some point we returned from an interpreted callee and the sender sp it's not below `_cont_fastpath`[[2]](https://github.com/openjdk/jdk/blob/ad29642d8f4e8e0fb1223b
 14b85ab7841d7b1b51/src/hotspot/cpu/x86/interp_masm_x86.cpp#L1060).
> 
> The fix is to change `OSR_migration_begin` to set `_cont_fastpath` with the sender's `unextended_sp` instead. 
> 
> The patch includes new test `OSRWithManyLocals.java` which reliably reproduces the crash. I thought about adding it to the existing `OSRTest.java` but that was created to exercise a different issue. A better name for that test would be `OSRWithManyArgs.java`, so I could rename it in this patch if preferred (I also realized that test could be simplified and made easier to read but that's for another PR).
> 
> I tested the current patch with the new test and also run it through mach5 tiers1-7.
> 
> Thanks,
> Patricio

Thanks for the ping! A quick run of the test has passed on PPC64. We'll run more tests. @reinrich may want to take a look, too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28830#issuecomment-3667045863

From cjplummer at openjdk.org  Wed Dec 17 20:52:41 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 17 Dec 2025 20:52:41 GMT
Subject: RFR: 8373794: Move nmethod header from CodeCache
In-Reply-To: <RZYpT82maT4ayWODxISztNMAQwPOqilJsmjTtfZA9X4=.5953f303-ddb7-4f1e-ab27-e5b3ccaa039f@github.com>
References: <RZYpT82maT4ayWODxISztNMAQwPOqilJsmjTtfZA9X4=.5953f303-ddb7-4f1e-ab27-e5b3ccaa039f@github.com>
Message-ID: <D3QW0mZMMB6xqqWLHzby7OrXqmhk6wym_aer9NO-3cY=.3b5d2679-0274-4982-816d-f0470b282dc5@github.com>

On Wed, 17 Dec 2025 11:34:46 GMT, Mikhail Ablakatov <mablakatov at openjdk.org> 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.

The SA changes look ok, but you'll need to do some testing by hand. The existing SA tests don't do a good job of testing compiler support. Specifically,  you should run the clhsdb "livenmethods" and "dumpcodecache" commands and make sure the output looks reasonable. Note you may see an issue with "dumpcodecache" getting stuck after producing some output. You can ignore that. I just filed [JDK-8373933](https://bugs.openjdk.org/browse/JDK-8373933) for it.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/NMethod.java line 104:

> 102: 
> 103:     sun.jvm.hotspot.types.Field f = type.getField("_speculations_offset", false, false);
> 104:     if (f != null) {

Why is there a need for a null check here?

-------------

PR Review: https://git.openjdk.org/jdk/pull/28866#pullrequestreview-3588754711
PR Review Comment: https://git.openjdk.org/jdk/pull/28866#discussion_r2627897856

From dholmes at openjdk.org  Wed Dec 17 21:23:48 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 17 Dec 2025 21:23:48 GMT
Subject: RFR: 8373723: Deadlock with
 JvmtiTagMap::flush_object_free_events() [v2]
In-Reply-To: <IMsnsYbZoXe4awSTqUotD9bUi4MMZ-rrJbYaxlAO_Os=.be3d6e50-a040-42c0-9398-1b51cff68269@github.com>
References: <NSbobPaTwRkepNErCWi1IEKZ0JT6R-dGNTI0S_dM8Ts=.53706809-f5ed-489c-be79-3020efea185b@github.com>
 <IMsnsYbZoXe4awSTqUotD9bUi4MMZ-rrJbYaxlAO_Os=.be3d6e50-a040-42c0-9398-1b51cff68269@github.com>
Message-ID: <JYpiJ2jVnMbH6wrfiXcuxBBnaWKbVQm-ALwy8ax4gxA=.bb7a3041-28f6-4c18-afe5-dee9c46ee42c@github.com>

On Tue, 16 Dec 2025 23:08:24 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The JvmtiTagMap::flush_object_free_events() method might be called from different threads.
>> The thread waits using lock until other thread posting events. The locking thread is in vm state doesn't allowing safepoints. While other thread posting events might request safepoints.
>> 
>> The fix is to block thread to allow safepoints while waiting on the lock.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   applid David's suggestion

Looks good. Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28839#pullrequestreview-3589724147

From dholmes at openjdk.org  Wed Dec 17 21:32:33 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 17 Dec 2025 21:32:33 GMT
Subject: RFR: 8369515: Deadlock between JVMTI and JNI
 ReleasePrimitiveArrayCritical
In-Reply-To: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
References: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
Message-ID: <6Suuy1lWRKVyMBTgqxecKvIoHRnZwakNswyhHR09CFs=.3addbcfb-628c-4d61-b29b-83964436cc1b@github.com>

On Fri, 12 Dec 2025 04:20:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

> As discussed in JBS the deadlock occurs when the call to `ReleasePrimitiveArrayCritical` performs the transition from native to VM, and in the process checks for special runtime exit conditions - which includes the `obj_deopt_suspend` request. The simple solution is to define a custom JNI ENTRY with custom `ThreadInVMfromNative` that elides the exit check.
> 
> The change is limited to `ReleasePrimitiveArrayCritical` and `ReleaseStringCritical`.
> 
> There is no regression test as this has only been seen in long running stress tests.
> 
> Testing:
>    -tiers 1-6

I tested tiers 1-6 with the simplified fix and nothing has turned up.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28779#issuecomment-3667274570

From aph at openjdk.org  Wed Dec 17 22:04:42 2025
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 17 Dec 2025 22:04:42 GMT
Subject: RFR: 8372701: Randomized profile counters
In-Reply-To: <TANJ_hBLr0o3xIfxpmWgM47PNGSa9b8PqAXpyrtgxO0=.d68e394b-a68c-470c-beeb-336c338d8896@github.com>
References: <jKjmIONZcytzVjS4absOwOLv_QOF9qhIJifYhN6JyP4=.dceced94-bc29-43e6-9062-8dc77c2a6133@github.com>
 <a788944a-8bf2-4787-8382-274324eb53be@redhat.com>
 <TANJ_hBLr0o3xIfxpmWgM47PNGSa9b8PqAXpyrtgxO0=.d68e394b-a68c-470c-beeb-336c338d8896@github.com>
Message-ID: <s5vnjnqXgXrXe-7QnMfTaqL90yictkz_jRI17A2wRdM=.c6feb811-0c7a-421b-995e-8f05ffd0d51d@github.com>

On Wed, 17 Dec 2025 09:57:30 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> > I don't think there's any point until I've fixed whatever bug is causing the above regressions. Thanks.
> 
> Right, I see similar results with `-XX:ProfileCaptureRatio=64`.

I just can't see these jython regressions with MacOS or Linux AArch64, and I can't explain them. Any deltas are within the margin of error. I don't understand this at all.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28541#issuecomment-3667385018

From lmesnik at openjdk.org  Wed Dec 17 22:05:40 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 17 Dec 2025 22:05:40 GMT
Subject: RFR: 8373654: Tests in sources/ should only run once [v3]
In-Reply-To: <yo2TFyn3QFpgPffZs7RTtrzlkyfNHmlQ2ikBo2L8BME=.74030b31-36fc-4bf7-b490-d97be9b81c88@github.com>
References: <L0u3UjIJt8pEZdt8WfgVU8oGYUsCzeY6c55UPsm_Cus=.f55a3b5c-0104-45bd-8d84-9f26c7a38c03@github.com>
 <yo2TFyn3QFpgPffZs7RTtrzlkyfNHmlQ2ikBo2L8BME=.74030b31-36fc-4bf7-b490-d97be9b81c88@github.com>
Message-ID: <o_QrbbxF-QKVo7Fsy5FwoweoBnaGorwju14aymhdtmI=.610fc8b5-2747-409c-9588-4b1ba98b4adb@github.com>

On Tue, 16 Dec 2025 11:53:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This test is checking for backsliding on the use of NULL in the hotspot source files. The test only needs to be run once per change but it is defined as a regular tier1 test which then gets run for each os-arch combination, plus product and debug, and then again with a bunch of flags in tier3. This is just a waste of resources. At a minimum we should make the test flagless so that it doesn't run in tier3, but we can also restrict it to a single platform.
>> 
>> Before the change the test ran 27 times in tier1-3 in our CI. After it runs once. 
>> 
>> 
>> EDIT: Updated to include both tests in sources/
>> 
>> Thanks
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reviewer feedback

Marked as reviewed by lmesnik (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28818#pullrequestreview-3589872056

From liach at openjdk.org  Wed Dec 17 22:07:29 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 17 Dec 2025 22:07:29 GMT
Subject: RFR: 8373392: Replace CDS object subgraphs with
 @AOTSafeClassInitializer [v3]
In-Reply-To: <ObHUe60IbQtKQeY50_QL4HRA1IB54iUsNL71yo4RcNw=.dc0d6b3e-33d3-49ff-b468-dd99d59592a2@github.com>
References: <nwFU9L_ngxAg_QtXjVq_IvhIxlnHj49sWV-qMUCS0YY=.4417a88a-c604-415f-b389-12a19938fed3@github.com>
 <ObHUe60IbQtKQeY50_QL4HRA1IB54iUsNL71yo4RcNw=.dc0d6b3e-33d3-49ff-b468-dd99d59592a2@github.com>
Message-ID: <UGi8SIOC2541L09U7Ma21UhtgRObvJ5KsG4xrSsjPvk=.8263a392-1936-4224-b9ce-630d45ba4c6a@github.com>

On Wed, 17 Dec 2025 20:04:48 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> In legacy CDS, Java objects used by certain classes are computed ahead of time using "object subgraphs"
>> 
>> https://github.com/openjdk/jdk/blob/1bbbce75c5e68429c2a32519eb3c36d964dcdf57/src/hotspot/share/cds/heapShared.cpp#L168-L171
>> 
>> Examples of subgraphs:
>> 
>> - `java.lang.Integer$IntegerCache::cache`
>> - `jdk.internal.module.ArchivedBootLayer::bootLayer`
>> 
>> The implementation requires special code (in both Java and C++) to be executed when a CDS archive is created or loaded. As a result, we have an execution model that's difficult to implement/extend and the behavior is hard to understand.
>> 
>> To move towards the AOT Cache Snapshot Model ([JDK-8365645](https://bugs.openjdk.org/browse/JDK-8365645)) we should replace the subgraphs with the use of `@AOTSafeClassInitializer`, and if necessary, `@AOTRuntimeSetup`. This will simplify the current implementation, and make it possible to extend AOT-initializations to more core classes.
>> 
>> Note, the use of `@AOTSafeClassInitializer` requires `-XX:+AOTClassLinking`. For the time being, we retain the old CDS object subgraph code to cover the `-XX:-AOTClassLinking` cases. Such code will be marked with comments like `/* Legacy CDS archive support (to be deprecated) */`. All future AOT creation of Java objects will be done with  `@AOTSafeClassInitializer`.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed test case -- the regexp pattern could match the stats for the subgraphs table, which now has a single entry

The new tests look fine to me.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28736#pullrequestreview-3589877162

From dholmes at openjdk.org  Wed Dec 17 22:18:03 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 17 Dec 2025 22:18:03 GMT
Subject: RFR: 8373654: Tests in sources/ should only run once [v3]
In-Reply-To: <o_QrbbxF-QKVo7Fsy5FwoweoBnaGorwju14aymhdtmI=.610fc8b5-2747-409c-9588-4b1ba98b4adb@github.com>
References: <L0u3UjIJt8pEZdt8WfgVU8oGYUsCzeY6c55UPsm_Cus=.f55a3b5c-0104-45bd-8d84-9f26c7a38c03@github.com>
 <yo2TFyn3QFpgPffZs7RTtrzlkyfNHmlQ2ikBo2L8BME=.74030b31-36fc-4bf7-b490-d97be9b81c88@github.com>
 <o_QrbbxF-QKVo7Fsy5FwoweoBnaGorwju14aymhdtmI=.610fc8b5-2747-409c-9588-4b1ba98b4adb@github.com>
Message-ID: <rZonCO7FUnC5j2sjUn0VkD6IneZLfgBmd6LdXsaPFvM=.a10460f8-e318-41ca-9d4c-da9304d31bca@github.com>

On Wed, 17 Dec 2025 22:02:52 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reviewer feedback
>
> Marked as reviewed by lmesnik (Reviewer).

Thanks for the review @lmesnik !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28818#issuecomment-3667415180

From iklam at openjdk.org  Wed Dec 17 22:19:58 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 17 Dec 2025 22:19:58 GMT
Subject: RFR: 8373392: Replace CDS object subgraphs with
 @AOTSafeClassInitializer [v3]
In-Reply-To: <UGi8SIOC2541L09U7Ma21UhtgRObvJ5KsG4xrSsjPvk=.8263a392-1936-4224-b9ce-630d45ba4c6a@github.com>
References: <nwFU9L_ngxAg_QtXjVq_IvhIxlnHj49sWV-qMUCS0YY=.4417a88a-c604-415f-b389-12a19938fed3@github.com>
 <ObHUe60IbQtKQeY50_QL4HRA1IB54iUsNL71yo4RcNw=.dc0d6b3e-33d3-49ff-b468-dd99d59592a2@github.com>
 <UGi8SIOC2541L09U7Ma21UhtgRObvJ5KsG4xrSsjPvk=.8263a392-1936-4224-b9ce-630d45ba4c6a@github.com>
Message-ID: <wtmcXvHzUT_C4xaZCjpaDpG_0OQJZ0SOt-TGnoLhrrQ=.3c109b8a-2b38-4a5c-b912-9855773c2d78@github.com>

On Wed, 17 Dec 2025 22:04:42 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed test case -- the regexp pattern could match the stats for the subgraphs table, which now has a single entry
>
> The new tests look fine to me.

Thank you @liach @DanHeidinga for the review

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28736#issuecomment-3667419351

From iklam at openjdk.org  Wed Dec 17 22:20:00 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 17 Dec 2025 22:20:00 GMT
Subject: Integrated: 8373392: Replace CDS object subgraphs with
 @AOTSafeClassInitializer
In-Reply-To: <nwFU9L_ngxAg_QtXjVq_IvhIxlnHj49sWV-qMUCS0YY=.4417a88a-c604-415f-b389-12a19938fed3@github.com>
References: <nwFU9L_ngxAg_QtXjVq_IvhIxlnHj49sWV-qMUCS0YY=.4417a88a-c604-415f-b389-12a19938fed3@github.com>
Message-ID: <UkRvaYW_7gXE7xTCwdt_nZ7OxrdwYIdeC1OqsEGH1H8=.95d3746f-746f-47e0-9e22-bef7673a7838@github.com>

On Wed, 10 Dec 2025 09:31:37 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> In legacy CDS, Java objects used by certain classes are computed ahead of time using "object subgraphs"
> 
> https://github.com/openjdk/jdk/blob/1bbbce75c5e68429c2a32519eb3c36d964dcdf57/src/hotspot/share/cds/heapShared.cpp#L168-L171
> 
> Examples of subgraphs:
> 
> - `java.lang.Integer$IntegerCache::cache`
> - `jdk.internal.module.ArchivedBootLayer::bootLayer`
> 
> The implementation requires special code (in both Java and C++) to be executed when a CDS archive is created or loaded. As a result, we have an execution model that's difficult to implement/extend and the behavior is hard to understand.
> 
> To move towards the AOT Cache Snapshot Model ([JDK-8365645](https://bugs.openjdk.org/browse/JDK-8365645)) we should replace the subgraphs with the use of `@AOTSafeClassInitializer`, and if necessary, `@AOTRuntimeSetup`. This will simplify the current implementation, and make it possible to extend AOT-initializations to more core classes.
> 
> Note, the use of `@AOTSafeClassInitializer` requires `-XX:+AOTClassLinking`. For the time being, we retain the old CDS object subgraph code to cover the `-XX:-AOTClassLinking` cases. Such code will be marked with comments like `/* Legacy CDS archive support (to be deprecated) */`. All future AOT creation of Java objects will be done with  `@AOTSafeClassInitializer`.

This pull request has now been integrated.

Changeset: 232b41b2
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/232b41b2227bc9d03d88d316aa28d0cbe87086f7
Stats:     642 lines in 30 files changed: 406 ins; 186 del; 50 mod

8373392: Replace CDS object subgraphs with @AOTSafeClassInitializer

Reviewed-by: liach, heidinga

-------------

PR: https://git.openjdk.org/jdk/pull/28736

From dholmes at openjdk.org  Wed Dec 17 22:18:05 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 17 Dec 2025 22:18:05 GMT
Subject: Integrated: 8373654: Tests in sources/ should only run once
In-Reply-To: <L0u3UjIJt8pEZdt8WfgVU8oGYUsCzeY6c55UPsm_Cus=.f55a3b5c-0104-45bd-8d84-9f26c7a38c03@github.com>
References: <L0u3UjIJt8pEZdt8WfgVU8oGYUsCzeY6c55UPsm_Cus=.f55a3b5c-0104-45bd-8d84-9f26c7a38c03@github.com>
Message-ID: <Nnv2crlWGdbEVIrPKAxfrXDynjgphnmIM2GfxzSXnIk=.87a014ec-6770-474e-8220-5ddb58e6c78a@github.com>

On Mon, 15 Dec 2025 06:52:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This test is checking for backsliding on the use of NULL in the hotspot source files. The test only needs to be run once per change but it is defined as a regular tier1 test which then gets run for each os-arch combination, plus product and debug, and then again with a bunch of flags in tier3. This is just a waste of resources. At a minimum we should make the test flagless so that it doesn't run in tier3, but we can also restrict it to a single platform.
> 
> Before the change the test ran 27 times in tier1-3 in our CI. After it runs once. 
> 
> 
> EDIT: Updated to include both tests in sources/
> 
> Thanks

This pull request has now been integrated.

Changeset: b3fab414
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b3fab41460eabf253879d140b55b6b12036c7c10
Stats:     4 lines in 2 files changed: 4 ins; 0 del; 0 mod

8373654: Tests in sources/ should only run once

Reviewed-by: shade, lmesnik

-------------

PR: https://git.openjdk.org/jdk/pull/28818

From dlong at openjdk.org  Wed Dec 17 23:37:58 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 17 Dec 2025 23:37:58 GMT
Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() [v6]
In-Reply-To: <CEvEqPtlTMiv7fX1G_spyCpyl8afEZn4McrzIBd5GRY=.d233254e-3626-4044-a3e1-c82bcbd55e45@github.com>
References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com>
 <CEvEqPtlTMiv7fX1G_spyCpyl8afEZn4McrzIBd5GRY=.d233254e-3626-4044-a3e1-c82bcbd55e45@github.com>
Message-ID: <GQ45QXe6X73UgsrH3EjwetINZh4DDkcakFtoCPWzFbA=.4ea46b5f-3242-4ba9-86d9-d928c67631c6@github.com>

On Mon, 8 Dec 2025 14:01:48 GMT, Fei Gao <fgao at openjdk.org> 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/d39a5164...415495da

Actually, that scenario does seem possible.  Consider:
1. Call site points to trampoline
2. Thread 1 hits call site and enters trampoline, then gets rescheduled
3. Something causes a re-resolve and the call site to be reset to the resolve stub
4. Thread 2 hits the call site and eventually calls set_to_interpreted, updating stub, trampoline, and call site
Depending on when Thread 1 resumes, I believe Thread 1 can see any of the following:
1. old destination
2. stub destination with ISB + MOVs
3. stub destination with B + MOVs

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26638#issuecomment-3667592195

From liach at openjdk.org  Thu Dec 18 00:03:10 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 18 Dec 2025 00:03:10 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting [v7]
In-Reply-To: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
Message-ID: <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com>

> 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

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28540/files
  - new: https://git.openjdk.org/jdk/pull/28540/files/567e8925..16db9901

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28540&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28540&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28540.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28540/head:pull/28540

PR: https://git.openjdk.org/jdk/pull/28540

From liach at openjdk.org  Thu Dec 18 00:03:13 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 18 Dec 2025 00:03:13 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting [v6]
In-Reply-To: <uqj0bUkdXgXgqfHQZQoYNd57Civ4eZA_J5ijXvjxBXw=.9ad57214-28a8-4431-bef5-b54c5b3a2377@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
 <uqj0bUkdXgXgqfHQZQoYNd57Civ4eZA_J5ijXvjxBXw=.9ad57214-28a8-4431-bef5-b54c5b3a2377@github.com>
Message-ID: <7WM2llDmHIma5F6pRh7EIdeubuz7qI-uTqvSsqmfug4=.6ce794e4-c270-4d83-a481-5ac75a71afc9@github.com>

On Tue, 16 Dec 2025 18:54:34 GMT, Chen Liang <liach at openjdk.org> 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 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:
> 
>  - Recommended test tweaks
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting
>  - Jorn review
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting
>  - bracket styles
>  - Doc tweaks
>  - Essay
>  - Spurious change
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/0095e40a...567e8925

After offline discussion, we have decided to move this test to `compiler/corelibs`, which will become the future home for various compiler framework-based tests verifying the behavior of core library APIs once they are compiled. For example, this package may add more constant folding verifications (such as for Lazy Constants) or loop hoisting verification for FFM API.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28540#issuecomment-3667634659

From rrich at openjdk.org  Thu Dec 18 00:05:06 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Thu, 18 Dec 2025 00:05:06 GMT
Subject: RFR: 8372591: assert(!current->cont_fastpath() ||
 freeze.check_valid_fast_path()) failed
In-Reply-To: <_LgB7c2fIE-RBo1CpmjeirR4oG6v8JBVQZ8spZzDLY8=.a67da689-d204-4550-86b6-c0efde380892@github.com>
References: <6yaYr_fSazq20-3lshGS-_Lr-LqXMt4lTeaFzDs9U2U=.c865efd1-9b98-4fce-98dd-4e1fe50a45be@github.com>
 <_LgB7c2fIE-RBo1CpmjeirR4oG6v8JBVQZ8spZzDLY8=.a67da689-d204-4550-86b6-c0efde380892@github.com>
Message-ID: <kCm-ez6k9Jj2bmCrEyNZ_5FbnjsO2yx3V8MK26KO6xw=.bc3645bd-08aa-4f28-a4c1-412b2441e5ba@github.com>

On Wed, 17 Dec 2025 16:08:10 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> @reinrich @TheRealMDoerr Could you verify if this fix is correct for ppc too? Thanks.

The fix looks correct. Strangely the reproducer didn't work on ppc. Not even with 3x the locals in the osr method. I'll look a little more into it...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28830#issuecomment-3667644764

From dholmes at openjdk.org  Thu Dec 18 00:09:33 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 18 Dec 2025 00:09:33 GMT
Subject: [jdk26] RFR: 8372988: Test
 runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java failed:
 Unexpected interrupt
Message-ID: <o0a9tClnl3qKoBBxDHyFixBaDiM84XiepTyh-019bT0=.2ca18887-23aa-40a6-9472-1f4b518dfab2@github.com>

Hi all,

This pull request contains a backport of commit [1748737b](https://github.com/openjdk/jdk/commit/1748737b99f283f69b4be0910b6623a27d804e68) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by David Holmes on 16 Dec 2025 and was reviewed by Coleen Phillimore, Ioi Lam and Johan Sj?len.

Thanks!

-------------

Commit messages:
 - Backport 1748737b99f283f69b4be0910b6623a27d804e68

Changes: https://git.openjdk.org/jdk/pull/28882/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28882&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372988
  Stats: 21 lines in 4 files changed: 5 ins; 4 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/28882.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28882/head:pull/28882

PR: https://git.openjdk.org/jdk/pull/28882

From rrich at openjdk.org  Thu Dec 18 00:14:21 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Thu, 18 Dec 2025 00:14:21 GMT
Subject: RFR: 8369515: Deadlock between JVMTI and JNI
 ReleasePrimitiveArrayCritical
In-Reply-To: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
References: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
Message-ID: <ygHQH4Rzb4oK6rmpERi561IezMZjDLSd5uF2ALUy2Kw=.1c16facd-cbcb-4ab5-b6d4-3c57ffff35c8@github.com>

On Fri, 12 Dec 2025 04:20:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

> As discussed in JBS the deadlock occurs when the call to `ReleasePrimitiveArrayCritical` performs the transition from native to VM, and in the process checks for special runtime exit conditions - which includes the `obj_deopt_suspend` request. The simple solution is to define a custom JNI ENTRY with custom `ThreadInVMfromNative` that elides the exit check.
> 
> The change is limited to `ReleasePrimitiveArrayCritical` and `ReleaseStringCritical`.
> 
> There is no regression test as this has only been seen in long running stress tests.
> 
> Testing:
>    -tiers 1-6

Thanks! Same with my testing.
I doubt that I'll find the time to write a reproducer though.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28779#issuecomment-3667664024

From coleenp at openjdk.org  Thu Dec 18 00:46:04 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 18 Dec 2025 00:46:04 GMT
Subject: [jdk26] RFR: 8372988: Test
 runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java failed:
 Unexpected interrupt
In-Reply-To: <o0a9tClnl3qKoBBxDHyFixBaDiM84XiepTyh-019bT0=.2ca18887-23aa-40a6-9472-1f4b518dfab2@github.com>
References: <o0a9tClnl3qKoBBxDHyFixBaDiM84XiepTyh-019bT0=.2ca18887-23aa-40a6-9472-1f4b518dfab2@github.com>
Message-ID: <4FAdlkDaQquG36wiS22izoweDN9ocbf4FieHJDZXgfU=.c510b295-b099-4498-b5d9-b0f5d707c90d@github.com>

On Thu, 18 Dec 2025 00:01:54 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [1748737b](https://github.com/openjdk/jdk/commit/1748737b99f283f69b4be0910b6623a27d804e68) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by David Holmes on 16 Dec 2025 and was reviewed by Coleen Phillimore, Ioi Lam and Johan Sj?len.
> 
> Thanks!

Yes, this backport looks good.

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28882#pullrequestreview-3590228989

From dholmes at openjdk.org  Thu Dec 18 00:51:22 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 18 Dec 2025 00:51:22 GMT
Subject: [jdk26] RFR: 8372988: Test
 runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java failed:
 Unexpected interrupt
In-Reply-To: <4FAdlkDaQquG36wiS22izoweDN9ocbf4FieHJDZXgfU=.c510b295-b099-4498-b5d9-b0f5d707c90d@github.com>
References: <o0a9tClnl3qKoBBxDHyFixBaDiM84XiepTyh-019bT0=.2ca18887-23aa-40a6-9472-1f4b518dfab2@github.com>
 <4FAdlkDaQquG36wiS22izoweDN9ocbf4FieHJDZXgfU=.c510b295-b099-4498-b5d9-b0f5d707c90d@github.com>
Message-ID: <w66lXvRYF0B0htc4Y_Q2ZqzU8Ft4ySn-PcweESTOUt4=.1808ce1b-39ac-4f3c-81a2-80cd0e2aae53@github.com>

On Thu, 18 Dec 2025 00:43:34 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Hi all,
>> 
>> This pull request contains a backport of commit [1748737b](https://github.com/openjdk/jdk/commit/1748737b99f283f69b4be0910b6623a27d804e68) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>> 
>> The commit being backported was authored by David Holmes on 16 Dec 2025 and was reviewed by Coleen Phillimore, Ioi Lam and Johan Sj?len.
>> 
>> Thanks!
>
> Yes, this backport looks good.

Thank for the review @coleenp !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28882#issuecomment-3667747461

From dholmes at openjdk.org  Thu Dec 18 00:51:23 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 18 Dec 2025 00:51:23 GMT
Subject: [jdk26] Integrated: 8372988: Test
 runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java failed:
 Unexpected interrupt
In-Reply-To: <o0a9tClnl3qKoBBxDHyFixBaDiM84XiepTyh-019bT0=.2ca18887-23aa-40a6-9472-1f4b518dfab2@github.com>
References: <o0a9tClnl3qKoBBxDHyFixBaDiM84XiepTyh-019bT0=.2ca18887-23aa-40a6-9472-1f4b518dfab2@github.com>
Message-ID: <ucvCrXXdLuQ9F6O8JjNdSblsivLAtpQf9frcSDHp7vM=.961817db-789e-45ee-b2f7-8289046d7d5a@github.com>

On Thu, 18 Dec 2025 00:01:54 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [1748737b](https://github.com/openjdk/jdk/commit/1748737b99f283f69b4be0910b6623a27d804e68) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by David Holmes on 16 Dec 2025 and was reviewed by Coleen Phillimore, Ioi Lam and Johan Sj?len.
> 
> Thanks!

This pull request has now been integrated.

Changeset: a2111b0c
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a2111b0ca6fc3a6352597316d46c7219bf2af763
Stats:     21 lines in 4 files changed: 5 ins; 4 del; 12 mod

8372988: Test runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java failed: Unexpected interrupt

Reviewed-by: coleenp
Backport-of: 1748737b99f283f69b4be0910b6623a27d804e68

-------------

PR: https://git.openjdk.org/jdk/pull/28882

From dholmes at openjdk.org  Thu Dec 18 01:21:17 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 18 Dec 2025 01:21:17 GMT
Subject: RFR: 8369515: Deadlock between JVMTI and JNI
 ReleasePrimitiveArrayCritical [v2]
In-Reply-To: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
References: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
Message-ID: <DdndhI1g51Z9rEMIpU99IPI47NtmbYNYWHVEBrBEOSQ=.7137830c-4ce8-4133-b0bd-ebc9eafe671e@github.com>

> As discussed in JBS the deadlock occurs when the call to `ReleasePrimitiveArrayCritical` performs the transition from native to VM, and in the process checks for special runtime exit conditions - which includes the `obj_deopt_suspend` request. The simple solution is to define a custom JNI ENTRY with custom `ThreadInVMfromNative` that elides the exit check.
> 
> The change is limited to `ReleasePrimitiveArrayCritical` and `ReleaseStringCritical`.
> 
> UPDATE: we are now employing a much simpler solution.
> 
> There is no regression test as this has only been seen in long running stress tests.
> 
> Testing:
>    -tiers 1-6

David Holmes 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:

 - Greatly simplifed fix to just defer object_deopt whilst in JNI critical region
 - Merge branch 'master' into 8369515-jni-critical
 - Revert "8369515"
   
   This reverts commit 3beb23ccbf5adb98d8c6ad404d40c603bbf499dc.
 - 8369515

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28779/files
  - new: https://git.openjdk.org/jdk/pull/28779/files/3beb23cc..b96a9bc2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28779&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28779&range=00-01

  Stats: 12369 lines in 431 files changed: 7742 ins; 1537 del; 3090 mod
  Patch: https://git.openjdk.org/jdk/pull/28779.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28779/head:pull/28779

PR: https://git.openjdk.org/jdk/pull/28779

From dlong at openjdk.org  Thu Dec 18 01:57:47 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 18 Dec 2025 01:57:47 GMT
Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute"
 switching [v22]
In-Reply-To: <jQmFrbatvNqwB2gTi0NhLCUii3qIlILrE_jdti5idyc=.96b6e698-105d-42d3-8e33-cc8ad8c9620e@github.com>
References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com>
 <jQmFrbatvNqwB2gTi0NhLCUii3qIlILrE_jdti5idyc=.96b6e698-105d-42d3-8e33-cc8ad8c9620e@github.com>
Message-ID: <72UOc-ZUvUYUR2xoscmB1gN5TVSIFKb1izWjEln4jrc=.11893391-281c-4f37-8715-e90053ba9510@github.com>

On Tue, 21 Oct 2025 15:54:18 GMT, Andrew Haley <aph at openjdk.org> 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 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.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2629214526

From coleenp at openjdk.org  Thu Dec 18 02:08:32 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 18 Dec 2025 02:08:32 GMT
Subject: RFR: 8373723: Deadlock with
 JvmtiTagMap::flush_object_free_events() [v2]
In-Reply-To: <IMsnsYbZoXe4awSTqUotD9bUi4MMZ-rrJbYaxlAO_Os=.be3d6e50-a040-42c0-9398-1b51cff68269@github.com>
References: <NSbobPaTwRkepNErCWi1IEKZ0JT6R-dGNTI0S_dM8Ts=.53706809-f5ed-489c-be79-3020efea185b@github.com>
 <IMsnsYbZoXe4awSTqUotD9bUi4MMZ-rrJbYaxlAO_Os=.be3d6e50-a040-42c0-9398-1b51cff68269@github.com>
Message-ID: <f8v5ZiTkeOEQAv6uDKBQZ7iZg9h6AldWCBauRtTUM2Y=.5612bfc6-84dc-492c-83af-61924f46c7ec@github.com>

On Tue, 16 Dec 2025 23:08:24 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The JvmtiTagMap::flush_object_free_events() method might be called from different threads.
>> The thread waits using lock until other thread posting events. The locking thread is in vm state doesn't allowing safepoints. While other thread posting events might request safepoints.
>> 
>> The fix is to block thread to allow safepoints while waiting on the lock.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   applid David's suggestion

This looks good.  Was there a test case that can be added?  Or is it noreg-hard?

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28839#pullrequestreview-3590388366

From dlong at openjdk.org  Thu Dec 18 02:26:25 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 18 Dec 2025 02:26:25 GMT
Subject: RFR: 8373794: Move nmethod header from CodeCache
In-Reply-To: <RZYpT82maT4ayWODxISztNMAQwPOqilJsmjTtfZA9X4=.5953f303-ddb7-4f1e-ab27-e5b3ccaa039f@github.com>
References: <RZYpT82maT4ayWODxISztNMAQwPOqilJsmjTtfZA9X4=.5953f303-ddb7-4f1e-ab27-e5b3ccaa039f@github.com>
Message-ID: <LAFydlD8_MzjwVnLzuGb6ICtSxWqSPsguQSM6lynUmA=.f71c0b41-948f-403d-8670-beeee6d6f9a9@github.com>

On Wed, 17 Dec 2025 11:34:46 GMT, Mikhail Ablakatov <mablakatov at openjdk.org> 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.

Wouldn't it be better to move the whole CodeBlob header out of the code cache?  Instead of nmethod having a _hdr pointer, CodeBlob would be in malloc space and have a _code pointer into the CodeCache.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28866#issuecomment-3668010082

From dlong at openjdk.org  Thu Dec 18 02:39:55 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 18 Dec 2025 02:39:55 GMT
Subject: RFR: 8373343: C2: verify AddP base input only set for heap
 addresses [v2]
In-Reply-To: <Zbm9YhaKSNO0hQ5JdKgg1MEksFz-7EKLx8ffbgIHQwY=.9bf2d725-6ef5-44bb-95d8-a54479fb1299@github.com>
References: <fdm8TK_FBJheQ_Wkd_KobosU0uTioUuRZhIK38I3Q-g=.8ae8e498-9c14-4cae-8e68-4c39914a8195@github.com>
 <UX4WA3wQ60ySAOYpdd6MJW5J5QXbqh6wvlhRlJecNxw=.7486aee9-e91f-45ef-bae0-12f4c24b07ca@github.com>
 <ElVoKrC0Z5p63UyUoOBBfEvSjhSJH6dmGtb6540aPqU=.6d30cdcc-6419-4238-b8b4-d52522e4ba9c@github.com>
 <vUMsaQLeZqS9yC_nnkLQXxAjcNthZ_89LDPC3DQfi4Y=.42122b7d-b735-48e6-a00e-ef3407ea2580@github.com>
 <Zbm9YhaKSNO0hQ5JdKgg1MEksFz-7EKLx8ffbgIHQwY=.9bf2d725-6ef5-44bb-95d8-a54479fb1299@github.com>
Message-ID: <j2d7HgTs_XREwZHkkBBkvkDPOAAaUqYQUdmr2onOxz8=.3088fcb9-c324-4c9f-9750-fabcf9ef630c@github.com>

On Wed, 17 Dec 2025 14:03:45 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> It seems like "dest" is always an oop here and we don't need to check isa_oopptr().
>
> It is always an heap address. But when used at object creation time, it's not yet an oop. It only becomes one once it is initialized. For those `Store`s to the not yet initialized object, I don't think the base edge is needed (there can't be any safepoint until the object becomes an actual oop) and code elsewhere (`InitializeNode::capture_store()`) doesn't set the base input either.

That makes sense as long as we can guarantee there is no safepoint.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28769#discussion_r2629279971

From dlong at openjdk.org  Thu Dec 18 03:29:53 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 18 Dec 2025 03:29:53 GMT
Subject: RFR: 8373343: C2: verify AddP base input only set for heap
 addresses [v2]
In-Reply-To: <T6ZxMdJ9pNnL8Ao63VPDxzkRhMKiSR6RfL6MuKM9-1Q=.8039caa8-5086-47eb-a0ef-2fca0093897a@github.com>
References: <fdm8TK_FBJheQ_Wkd_KobosU0uTioUuRZhIK38I3Q-g=.8ae8e498-9c14-4cae-8e68-4c39914a8195@github.com>
 <T6ZxMdJ9pNnL8Ao63VPDxzkRhMKiSR6RfL6MuKM9-1Q=.8039caa8-5086-47eb-a0ef-2fca0093897a@github.com>
Message-ID: <_x8OV9zV3TaggMMwjNpjaeBtQRIxXbmq-VvV10SmTHg=.b7a98f3f-19c6-442b-b71b-a86a5b6f685a@github.com>

On Wed, 17 Dec 2025 14:04:04 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> The base input of `AddP` is expected to only be set for heap accesses
>> but I noticed some inconsistencies so I added an assert in the `AddP`
>> constructor and fixed issues that it caught. AFAFICT, the
>> inconsistencies shouldn't create issues.
>
> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - review
>  - review
>  - merge
>  - more
>  - more
>  - more
>  - undo
>  - exps

src/hotspot/share/opto/memnode.cpp line 2570:

> 2568:             assert(tkls2->offset() == 0, "not a load of java_mirror");
> 2569: #endif
> 2570:             return adr2->in(AddPNode::Address);

What should the value of adr2->in(AddPNode::Offset) be at this point? 0 or java_mirror_offset()?  Do we need to check it?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28769#discussion_r2629405380

From qamai at openjdk.org  Thu Dec 18 03:41:54 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 18 Dec 2025 03:41:54 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: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
 <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com>
Message-ID: <z-Wg98IroOwuFo46i138RqYU_5GTZFcj_HEeZ0Y6EyA=.73155e37-4c51-4858-af9f-d2b8b9a5c537@github.com>

On Thu, 18 Dec 2025 00:03:10 GMT, Chen Liang <liach at openjdk.org> 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

Is this annotation just for constant folding of final fields? That seems pretty limited. Can we have it to notify that the final fields of a class can be treated as strict fields?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28540#issuecomment-3668189051

From liach at openjdk.org  Thu Dec 18 03:54:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 18 Dec 2025 03:54:53 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: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
 <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com>
Message-ID: <sczGFpqXfmfhNELGPv_PrdIirflHgkGC9kUnRZuJpbw=.92cab94d-f2eb-470b-a6e2-f2b153fbebcc@github.com>

On Thu, 18 Dec 2025 00:03:10 GMT, Chen Liang <liach at openjdk.org> 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

Yes, this is the purpose of this annotation for now. Unfortunately the JDK can only use strict after it leaves preview, so I think this is necessary to bridge the gap during this period.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28540#issuecomment-3668227064

From qamai at openjdk.org  Thu Dec 18 04:07:54 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 18 Dec 2025 04:07:54 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: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
 <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com>
Message-ID: <x8_6X-3RAu4djxnKBUehQh7fIaCBNM2TG8EYy5okwYA=.d678e7a0-122f-47bf-a9f6-2c5492f0d0f2@github.com>

On Thu, 18 Dec 2025 00:03:10 GMT, Chen Liang <liach at openjdk.org> 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

If the JDK wants to use strict then it can, it is the user code which does not have access to strict fields, isn't it? What I mean is why isn't this annotation stronger so we can improve the accesses into currently-trusted fields, too (`MemorySegment` fields for example).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28540#issuecomment-3668255154

From lmesnik at openjdk.org  Thu Dec 18 04:22:52 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 18 Dec 2025 04:22:52 GMT
Subject: RFR: 8373723: Deadlock with
 JvmtiTagMap::flush_object_free_events() [v2]
In-Reply-To: <IMsnsYbZoXe4awSTqUotD9bUi4MMZ-rrJbYaxlAO_Os=.be3d6e50-a040-42c0-9398-1b51cff68269@github.com>
References: <NSbobPaTwRkepNErCWi1IEKZ0JT6R-dGNTI0S_dM8Ts=.53706809-f5ed-489c-be79-3020efea185b@github.com>
 <IMsnsYbZoXe4awSTqUotD9bUi4MMZ-rrJbYaxlAO_Os=.be3d6e50-a040-42c0-9398-1b51cff68269@github.com>
Message-ID: <M2jayhvvkzTBjR9nBJn-l8j7bi4XdUIRypKqK5_x1ck=.91f810d1-0b06-4b10-b710-8c09bc6d67eb@github.com>

On Tue, 16 Dec 2025 23:08:24 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The JvmtiTagMap::flush_object_free_events() method might be called from different threads.
>> The thread waits using lock until other thread posting events. The locking thread is in vm state doesn't allowing safepoints. While other thread posting events might request safepoints.
>> 
>> The fix is to block thread to allow safepoints while waiting on the lock.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   applid David's suggestion

The failure reproduced with vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t001/TestDescription.java
Not very often though.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28839#issuecomment-3668292624

From lmesnik at openjdk.org  Thu Dec 18 04:30:02 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 18 Dec 2025 04:30:02 GMT
Subject: RFR: 8373723: Deadlock with
 JvmtiTagMap::flush_object_free_events() [v2]
In-Reply-To: <JYpiJ2jVnMbH6wrfiXcuxBBnaWKbVQm-ALwy8ax4gxA=.bb7a3041-28f6-4c18-afe5-dee9c46ee42c@github.com>
References: <NSbobPaTwRkepNErCWi1IEKZ0JT6R-dGNTI0S_dM8Ts=.53706809-f5ed-489c-be79-3020efea185b@github.com>
 <IMsnsYbZoXe4awSTqUotD9bUi4MMZ-rrJbYaxlAO_Os=.be3d6e50-a040-42c0-9398-1b51cff68269@github.com>
 <JYpiJ2jVnMbH6wrfiXcuxBBnaWKbVQm-ALwy8ax4gxA=.bb7a3041-28f6-4c18-afe5-dee9c46ee42c@github.com>
Message-ID: <tTcTRV6F31F7npwfdyATQXgz_0K2VFQLPVGYzK7EYG0=.b7a265e2-4c5b-47e0-907a-af5a0f2da692@github.com>

On Wed, 17 Dec 2025 21:21:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   applid David's suggestion
>
> Looks good. Thanks

@dholmes-ora, @coleenp Thank you for review and fedback!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28839#issuecomment-3668305965

From lmesnik at openjdk.org  Thu Dec 18 04:30:04 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 18 Dec 2025 04:30:04 GMT
Subject: Integrated: 8373723: Deadlock with
 JvmtiTagMap::flush_object_free_events()
In-Reply-To: <NSbobPaTwRkepNErCWi1IEKZ0JT6R-dGNTI0S_dM8Ts=.53706809-f5ed-489c-be79-3020efea185b@github.com>
References: <NSbobPaTwRkepNErCWi1IEKZ0JT6R-dGNTI0S_dM8Ts=.53706809-f5ed-489c-be79-3020efea185b@github.com>
Message-ID: <A2TDfxtYoUu30H_cM_63pn5SLZUQ-rVtcW0fEUIC3Yw=.80c84e36-3065-41c8-84ca-c7f259c6d591@github.com>

On Tue, 16 Dec 2025 03:34:47 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The JvmtiTagMap::flush_object_free_events() method might be called from different threads.
> The thread waits using lock until other thread posting events. The locking thread is in vm state doesn't allowing safepoints. While other thread posting events might request safepoints.
> 
> The fix is to block thread to allow safepoints while waiting on the lock.

This pull request has now been integrated.

Changeset: 0146077a
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0146077a51635500de771e9cf2c9788ae931b7a0
Stats:     4 lines in 1 file changed: 3 ins; 1 del; 0 mod

8373723: Deadlock with JvmtiTagMap::flush_object_free_events()

Reviewed-by: dholmes, coleenp

-------------

PR: https://git.openjdk.org/jdk/pull/28839

From liach at openjdk.org  Thu Dec 18 04:54:05 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 18 Dec 2025 04:54: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: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
 <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com>
Message-ID: <W2ThQOjO0bZN9WTjE18LzKXVkPbGDls4Xq7A-QqqqOA=.38b4ad80-9547-479a-86ae-a50cb056892a@github.com>

On Thu, 18 Dec 2025 00:03:10 GMT, Chen Liang <liach at openjdk.org> 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

What do you mean by this annotation being "stronger"? This annotation uses class granularity because javac generates synthetic fields like local variable captures, which cannot be annotated by field annotations.

The JDK will have to resort to an annotation, because JDK class files cannot use preview features because they need to be able to run with preview features off.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28540#issuecomment-3668363917

From qamai at openjdk.org  Thu Dec 18 05:00:56 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 18 Dec 2025 05:00:56 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: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
 <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com>
Message-ID: <mQ4Fm4K2xIuHNv_NyvU43L2LpN0SThdlhEYiel6jc_k=.19ed6b8f-385f-49e9-946b-ed87df7672fc@github.com>

On Thu, 18 Dec 2025 00:03:10 GMT, Chen Liang <liach at openjdk.org> 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

What I mean by stronger is that trusted final fields only ensure that their values are unchanged after initialization. Strict fields are unchanged unconditionally, there is only 1 observable state for a strict field of an object. As a result, in addition to constant folding, we can do load hoisting, too. So my question is why this annotation does not try to enforce a stronger invariant so that we can benefit from those invariants without having to wait for strict fields.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28540#issuecomment-3668379612

From syan at openjdk.org  Thu Dec 18 06:35:53 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 18 Dec 2025 06:35:53 GMT
Subject: RFR: 8371948: TestStackOverflowDuringInit.java fails xss too small
 on linux-aarch64 [v5]
In-Reply-To: <L1U5kByReJGXcxHMZG21t0teqI3WH4sh59saejQwryA=.d95f42e9-6e53-4755-8a2f-36c6732aa86b@github.com>
References: <P6KhJ0rZttqTHVxuVi_POYRVmy2oGpaUj03Gnz3LXOQ=.9449af19-abc3-44ad-99e9-6e70ce008e3c@github.com>
 <L1U5kByReJGXcxHMZG21t0teqI3WH4sh59saejQwryA=.d95f42e9-6e53-4755-8a2f-36c6732aa86b@github.com>
Message-ID: <5LBXSwk-8ojgURW0-eu4YGuTiyphcdRQPLH3ED8HVig=.00e5adac-be70-4880-b637-d23b9fd441bb@github.com>

On Thu, 11 Dec 2025 01:57:58 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> On linux-aarch64, when page size is 64K, the minimal java thread stack size is 448K. So this PR increase the minimal java thread stack size in test/hotspot/jtreg/runtime/ClassInitErrors/TestStackOverflowDuringInit.java. Below is the calculation formula for the minimal java thread stack size:
>> 
>> 
>> page_size = 64K
>> _java_thread_min_stack_allowed = 72K
>> _stack_red_zone_size = align_up(StackRedPages * unit, page_size) = align_up(1*4K, 64K) = 64K
>> _stack_yellow_zone_size = align_up(StackYellowPages * unit, page_size) = align_up(2*4K, 64K) = 64K
>> _stack_reserved_zone_size = align_up(StackReservedPages * unit, page_size) = align_up(1*4K, 64K) = 64K
>> _stack_shadow_zone_size = align_up(StackShadowPages * unit, page_size) = align_up(25*4K, 64K) = 128K
>> _java_thread_min_stack_allowed = align_up(72K+64K+64K+64K+128K, 64K) = 448K
>> 
>> 
>> This PR add whitebox API getMinimumJavaStackSize() to the the allowd minimum java stack size, and get the allowed minimum java stack size in test/hotspot/jtreg/runtime/ClassInitErrors/TestStackOverflowDuringInit.java
>> 
>> Change has been verified locally both on linux-x64 and linux-aarch64.
>
> SendaoYan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove test/hotspot/jtreg/runtime/memory/ReadMinimumJavaStackSize.java
>  - Use get_minimum_java_stack_size instead of get_minimum_java_stack_sizes

Looking for second reviewer since touch the hotspot files.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28352#issuecomment-3668617941

From epeter at openjdk.org  Thu Dec 18 07:08:01 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 18 Dec 2025 07:08:01 GMT
Subject: RFR: 8367341: C2: apply KnownBits and unsigned bounds to And / Or
 operations [v8]
In-Reply-To: <xMDLn1jlE5MhYML12NNGMf8aCQ4ah6ztsvFwbXH-Qv4=.b798d07b-3ed7-403a-8da0-0b1e540c903a@github.com>
References: <SqHEdFScmcQRe6wTaITLemzMzWD6jxGWCRWzHNepqjE=.ab7e7553-3a43-4b43-abc3-338d6493a35d@github.com>
 <xMDLn1jlE5MhYML12NNGMf8aCQ4ah6ztsvFwbXH-Qv4=.b798d07b-3ed7-403a-8da0-0b1e540c903a@github.com>
Message-ID: <Q6sKXKQ6Mm4gdlIWPrBty9Dau50ucJd_VE7hUl796Zo=.186e938b-9f0b-409a-9ca1-4422ff80479c@github.com>

On Tue, 16 Dec 2025 09:19:06 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This PR improves the implementation of `AndNode/OrNode/XorNode::Value` by taking advantages of the additional information in `TypeInt`. The implementation is pretty straightforward. A clever trick is that by analyzing the negative and positive ranges of a `TypeInt` separately, we have better info for the leading bits. I also implement gtest unit tests to verify the correctness and monotonicity of the inference functions.
>> 
>> Please take a look and leave your reviews, thanks a lot.
>
> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
> 
>  - Merge branch 'master' into andorxor
>  - Merge branch 'master' into andorxor
>  - Merge branch 'master' into andorxor
>  - Merge branch 'master' into andorxor
>  - Add assertion for the helper in CTPComparator
>    
>    Co-authored-by: Emanuel Peter <emanuel.peter at oracle.com>
>  - remove std::hash
>  - remove unordered_map, add some comments for all_instances_size
>  - Emanuel's reviews
>  - Improve Value inferences of And, Or, Xor and implement gtest for general Value inferences

Tests passed :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27618#issuecomment-3668698607

From qamai at openjdk.org  Thu Dec 18 07:26:58 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 18 Dec 2025 07:26:58 GMT
Subject: RFR: 8367341: C2: apply KnownBits and unsigned bounds to And / Or
 operations [v8]
In-Reply-To: <xMDLn1jlE5MhYML12NNGMf8aCQ4ah6ztsvFwbXH-Qv4=.b798d07b-3ed7-403a-8da0-0b1e540c903a@github.com>
References: <SqHEdFScmcQRe6wTaITLemzMzWD6jxGWCRWzHNepqjE=.ab7e7553-3a43-4b43-abc3-338d6493a35d@github.com>
 <xMDLn1jlE5MhYML12NNGMf8aCQ4ah6ztsvFwbXH-Qv4=.b798d07b-3ed7-403a-8da0-0b1e540c903a@github.com>
Message-ID: <pl2hRLxv5usmATfDZPqn2C9SXXSrjs5TuOEtBhebIRs=.c35b9c9f-6c34-4755-8b6a-929d21fd7b26@github.com>

On Tue, 16 Dec 2025 09:19:06 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This PR improves the implementation of `AndNode/OrNode/XorNode::Value` by taking advantages of the additional information in `TypeInt`. The implementation is pretty straightforward. A clever trick is that by analyzing the negative and positive ranges of a `TypeInt` separately, we have better info for the leading bits. I also implement gtest unit tests to verify the correctness and monotonicity of the inference functions.
>> 
>> Please take a look and leave your reviews, thanks a lot.
>
> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
> 
>  - Merge branch 'master' into andorxor
>  - Merge branch 'master' into andorxor
>  - Merge branch 'master' into andorxor
>  - Merge branch 'master' into andorxor
>  - Add assertion for the helper in CTPComparator
>    
>    Co-authored-by: Emanuel Peter <emanuel.peter at oracle.com>
>  - remove std::hash
>  - remove unordered_map, add some comments for all_instances_size
>  - Emanuel's reviews
>  - Improve Value inferences of And, Or, Xor and implement gtest for general Value inferences

Thanks a lot for your reviews and testing. I'm very glad that this PR took much less time :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27618#issuecomment-3668762656

From epeter at openjdk.org  Thu Dec 18 07:31:00 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 18 Dec 2025 07:31:00 GMT
Subject: RFR: 8367341: C2: apply KnownBits and unsigned bounds to And / Or
 operations [v8]
In-Reply-To: <xMDLn1jlE5MhYML12NNGMf8aCQ4ah6ztsvFwbXH-Qv4=.b798d07b-3ed7-403a-8da0-0b1e540c903a@github.com>
References: <SqHEdFScmcQRe6wTaITLemzMzWD6jxGWCRWzHNepqjE=.ab7e7553-3a43-4b43-abc3-338d6493a35d@github.com>
 <xMDLn1jlE5MhYML12NNGMf8aCQ4ah6ztsvFwbXH-Qv4=.b798d07b-3ed7-403a-8da0-0b1e540c903a@github.com>
Message-ID: <dEv3FhSJMjvAJQW3dXL8awTVYnmV4h5Dw2-x_bBPDMs=.9c1c7b55-8490-45d6-9eeb-0ba27e21892d@github.com>

On Tue, 16 Dec 2025 09:19:06 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This PR improves the implementation of `AndNode/OrNode/XorNode::Value` by taking advantages of the additional information in `TypeInt`. The implementation is pretty straightforward. A clever trick is that by analyzing the negative and positive ranges of a `TypeInt` separately, we have better info for the leading bits. I also implement gtest unit tests to verify the correctness and monotonicity of the inference functions.
>> 
>> Please take a look and leave your reviews, thanks a lot.
>
> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
> 
>  - Merge branch 'master' into andorxor
>  - Merge branch 'master' into andorxor
>  - Merge branch 'master' into andorxor
>  - Merge branch 'master' into andorxor
>  - Add assertion for the helper in CTPComparator
>    
>    Co-authored-by: Emanuel Peter <emanuel.peter at oracle.com>
>  - remove std::hash
>  - remove unordered_map, add some comments for all_instances_size
>  - Emanuel's reviews
>  - Improve Value inferences of And, Or, Xor and implement gtest for general Value inferences

Marked as reviewed by epeter (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27618#pullrequestreview-3591187556

From qamai at openjdk.org  Thu Dec 18 07:31:02 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 18 Dec 2025 07:31:02 GMT
Subject: RFR: 8367341: C2: apply KnownBits and unsigned bounds to And / Or
 operations [v8]
In-Reply-To: <Q6sKXKQ6Mm4gdlIWPrBty9Dau50ucJd_VE7hUl796Zo=.186e938b-9f0b-409a-9ca1-4422ff80479c@github.com>
References: <SqHEdFScmcQRe6wTaITLemzMzWD6jxGWCRWzHNepqjE=.ab7e7553-3a43-4b43-abc3-338d6493a35d@github.com>
 <xMDLn1jlE5MhYML12NNGMf8aCQ4ah6ztsvFwbXH-Qv4=.b798d07b-3ed7-403a-8da0-0b1e540c903a@github.com>
 <Q6sKXKQ6Mm4gdlIWPrBty9Dau50ucJd_VE7hUl796Zo=.186e938b-9f0b-409a-9ca1-4422ff80479c@github.com>
Message-ID: <UiULDBk-3Rd782uY2HZj9x2yNy-pkDzjYYNCyIwuTI8=.49a79341-4b2f-4188-90db-2da3d52a075d@github.com>

On Thu, 18 Dec 2025 07:05:06 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
>> 
>>  - Merge branch 'master' into andorxor
>>  - Merge branch 'master' into andorxor
>>  - Merge branch 'master' into andorxor
>>  - Merge branch 'master' into andorxor
>>  - Add assertion for the helper in CTPComparator
>>    
>>    Co-authored-by: Emanuel Peter <emanuel.peter at oracle.com>
>>  - remove std::hash
>>  - remove unordered_map, add some comments for all_instances_size
>>  - Emanuel's reviews
>>  - Improve Value inferences of And, Or, Xor and implement gtest for general Value inferences
>
> Tests passed :)

@eme64 Please reapprove this PR if you think it can integrate now, thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27618#issuecomment-3668774252

From qamai at openjdk.org  Thu Dec 18 07:34:09 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 18 Dec 2025 07:34:09 GMT
Subject: Integrated: 8367341: C2: apply KnownBits and unsigned bounds to And /
 Or operations
In-Reply-To: <SqHEdFScmcQRe6wTaITLemzMzWD6jxGWCRWzHNepqjE=.ab7e7553-3a43-4b43-abc3-338d6493a35d@github.com>
References: <SqHEdFScmcQRe6wTaITLemzMzWD6jxGWCRWzHNepqjE=.ab7e7553-3a43-4b43-abc3-338d6493a35d@github.com>
Message-ID: <0OCcvJWvibSXGQ8haUHXIwD-8pc1mhRDuGZ-BCvXNqs=.5487f297-3225-4f8b-9ec1-95a998d1b236@github.com>

On Fri, 3 Oct 2025 06:07:50 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> This PR improves the implementation of `AndNode/OrNode/XorNode::Value` by taking advantages of the additional information in `TypeInt`. The implementation is pretty straightforward. A clever trick is that by analyzing the negative and positive ranges of a `TypeInt` separately, we have better info for the leading bits. I also implement gtest unit tests to verify the correctness and monotonicity of the inference functions.
> 
> Please take a look and leave your reviews, thanks a lot.

This pull request has now been integrated.

Changeset: e6780506
Author:    Quan Anh Mai <qamai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e67805067a8f537862200e808e20464f12d21c9c
Stats:     964 lines in 9 files changed: 630 ins; 313 del; 21 mod

8367341: C2: apply KnownBits and unsigned bounds to And / Or operations

Reviewed-by: hgreule, epeter

-------------

PR: https://git.openjdk.org/jdk/pull/27618

From roland at openjdk.org  Thu Dec 18 08:40:00 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Thu, 18 Dec 2025 08:40:00 GMT
Subject: [jdk26] RFR: 8354282: C2: more crashes in compiled code because of
 dependency on removed range check CastIIs
Message-ID: <v5ojW_i9n41OjYszp5CpLQjPUxuNtV_MSGwGN_2_jLU=.4ab9554e-2ef2-4f65-8288-ad7f99f9bdfa@github.com>

Hi all,

This pull request contains a backport of commit [00068a80](https://github.com/openjdk/jdk/commit/00068a80304a809297d0df8698850861e9a1c5e9) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Roland Westrelin on 10 Dec 2025 and was reviewed by Christian Hagedorn, Quan Anh Mai, Galder Zamarre?o and Emanuel Peter.

Thanks!

-------------

Commit messages:
 - Backport 00068a80304a809297d0df8698850861e9a1c5e9

Changes: https://git.openjdk.org/jdk/pull/28892/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28892&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354282
  Stats: 367 lines in 13 files changed: 266 ins; 27 del; 74 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 roland at openjdk.org  Thu Dec 18 08:40:17 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Thu, 18 Dec 2025 08:40:17 GMT
Subject: [jdk26] RFR: 8351889: C2 crash: assertion failed: Base pointers must
 match (addp 344)
Message-ID: <pGBYr16YEbYzSHyQTnMK1EFzWv2dLR2P19P_gzEo7Bo=.0fc3368f-4917-4145-a178-845efaeaa1bd@github.com>

Hi all,

This pull request contains a backport of commit [ad29642d](https://github.com/openjdk/jdk/commit/ad29642d8f4e8e0fb1223b14b85ab7841d7b1b51) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Roland Westrelin on 15 Dec 2025 and was reviewed by Roberto Casta?eda Lozano and Emanuel Peter.

Thanks!

-------------

Commit messages:
 - Backport ad29642d8f4e8e0fb1223b14b85ab7841d7b1b51

Changes: https://git.openjdk.org/jdk/pull/28893/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28893&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351889
  Stats: 159 lines in 10 files changed: 148 ins; 3 del; 8 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 aph at openjdk.org  Thu Dec 18 09:14:00 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 18 Dec 2025 09:14:00 GMT
Subject: RFR: 8371948: TestStackOverflowDuringInit.java fails xss too small
 on linux-aarch64 [v5]
In-Reply-To: <L1U5kByReJGXcxHMZG21t0teqI3WH4sh59saejQwryA=.d95f42e9-6e53-4755-8a2f-36c6732aa86b@github.com>
References: <P6KhJ0rZttqTHVxuVi_POYRVmy2oGpaUj03Gnz3LXOQ=.9449af19-abc3-44ad-99e9-6e70ce008e3c@github.com>
 <L1U5kByReJGXcxHMZG21t0teqI3WH4sh59saejQwryA=.d95f42e9-6e53-4755-8a2f-36c6732aa86b@github.com>
Message-ID: <ZiCgqM444ldGD6OYSyIznvo8FuWVBtJMpoBHFNc597E=.cb3b3c88-293c-4fb3-b12c-789b32ba678c@github.com>

On Thu, 11 Dec 2025 01:57:58 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> On linux-aarch64, when page size is 64K, the minimal java thread stack size is 448K. So this PR increase the minimal java thread stack size in test/hotspot/jtreg/runtime/ClassInitErrors/TestStackOverflowDuringInit.java. Below is the calculation formula for the minimal java thread stack size:
>> 
>> 
>> page_size = 64K
>> _java_thread_min_stack_allowed = 72K
>> _stack_red_zone_size = align_up(StackRedPages * unit, page_size) = align_up(1*4K, 64K) = 64K
>> _stack_yellow_zone_size = align_up(StackYellowPages * unit, page_size) = align_up(2*4K, 64K) = 64K
>> _stack_reserved_zone_size = align_up(StackReservedPages * unit, page_size) = align_up(1*4K, 64K) = 64K
>> _stack_shadow_zone_size = align_up(StackShadowPages * unit, page_size) = align_up(25*4K, 64K) = 128K
>> _java_thread_min_stack_allowed = align_up(72K+64K+64K+64K+128K, 64K) = 448K
>> 
>> 
>> This PR add whitebox API getMinimumJavaStackSize() to the the allowd minimum java stack size, and get the allowed minimum java stack size in test/hotspot/jtreg/runtime/ClassInitErrors/TestStackOverflowDuringInit.java
>> 
>> Change has been verified locally both on linux-x64 and linux-aarch64.
>
> SendaoYan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove test/hotspot/jtreg/runtime/memory/ReadMinimumJavaStackSize.java
>  - Use get_minimum_java_stack_size instead of get_minimum_java_stack_sizes

Marked as reviewed by aph (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28352#pullrequestreview-3591597450

From mbaesken at openjdk.org  Thu Dec 18 09:17:23 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 18 Dec 2025 09:17:23 GMT
Subject: RFR: 8372348: Adjust some UL / JFR string deduplication output
 messages [v3]
In-Reply-To: <jh6UcHdAQpaGgoqjGJOAehHx8rHSzK6UGz5uZbokSLg=.03c23543-b08c-4bb6-87f4-6894f03644ee@github.com>
References: <7-XRp229KFw3V2bFPMnaWaoPdF3ZCYVNuViEo2O7eUI=.e0247347-188b-44bf-935c-6b0186026fd3@github.com>
 <jh6UcHdAQpaGgoqjGJOAehHx8rHSzK6UGz5uZbokSLg=.03c23543-b08c-4bb6-87f4-6894f03644ee@github.com>
Message-ID: <SIgyz2JbKbl4MO2Kg5wh4FnatHuHsPgHvL9Mfj4fl8o=.022b76d3-e8f3-4d05-afe1-61afe9ca57e6@github.com>

On Wed, 17 Dec 2025 14:37:57 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There is some UL output in the string deduplication code that is not very clear and has room for improvement.
>> The inspected strings number should be shown and the new unknown strings get a changed text.
>> (also the new JFR strip dedup event  description is slightly adjusted)
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust output

Thanks for the reviews !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28455#issuecomment-3669251460

From mbaesken at openjdk.org  Thu Dec 18 09:17:24 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 18 Dec 2025 09:17:24 GMT
Subject: Integrated: 8372348: Adjust some UL / JFR string deduplication output
 messages
In-Reply-To: <7-XRp229KFw3V2bFPMnaWaoPdF3ZCYVNuViEo2O7eUI=.e0247347-188b-44bf-935c-6b0186026fd3@github.com>
References: <7-XRp229KFw3V2bFPMnaWaoPdF3ZCYVNuViEo2O7eUI=.e0247347-188b-44bf-935c-6b0186026fd3@github.com>
Message-ID: <_3cvoV10VBegaPgnuOISQbRqZI6LqDOGq8qqn_yekas=.11a732ff-0d69-4fcc-a6fd-21093fbe80b7@github.com>

On Fri, 21 Nov 2025 15:19:54 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There is some UL output in the string deduplication code that is not very clear and has room for improvement.
> The inspected strings number should be shown and the new unknown strings get a changed text.
> (also the new JFR strip dedup event  description is slightly adjusted)

This pull request has now been integrated.

Changeset: 3f20eb94
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3f20eb943532c5c76e55b14292139749bd704ce4
Stats:     15 lines in 2 files changed: 4 ins; 0 del; 11 mod

8372348: Adjust some UL / JFR string deduplication output messages

Reviewed-by: fandreuzzi, lucy, asteiner

-------------

PR: https://git.openjdk.org/jdk/pull/28455

From fbredberg at openjdk.org  Thu Dec 18 09:22:39 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 18 Dec 2025 09:22:39 GMT
Subject: RFR: 8369515: Deadlock between JVMTI and JNI
 ReleasePrimitiveArrayCritical [v2]
In-Reply-To: <DdndhI1g51Z9rEMIpU99IPI47NtmbYNYWHVEBrBEOSQ=.7137830c-4ce8-4133-b0bd-ebc9eafe671e@github.com>
References: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
 <DdndhI1g51Z9rEMIpU99IPI47NtmbYNYWHVEBrBEOSQ=.7137830c-4ce8-4133-b0bd-ebc9eafe671e@github.com>
Message-ID: <03R4Nqk1-LPYuGLWCoS2ZXMrvbLKdN1JynWy3pcNG58=.d18c006f-a704-4d80-b836-ebd605281586@github.com>

On Thu, 18 Dec 2025 01:21:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> As discussed in JBS the deadlock occurs when the call to `ReleasePrimitiveArrayCritical` performs the transition from native to VM, and in the process checks for special runtime exit conditions - which includes the `obj_deopt_suspend` request. The simple solution is to define a custom JNI ENTRY with custom `ThreadInVMfromNative` that elides the exit check.
>> 
>> The change is limited to `ReleasePrimitiveArrayCritical` and `ReleaseStringCritical`.
>> 
>> UPDATE: we are now employing a much simpler solution.
>> 
>> There is no regression test as this has only been seen in long running stress tests.
>> 
>> Testing:
>>    -tiers 1-6
>
> David Holmes 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:
> 
>  - Greatly simplifed fix to just defer object_deopt whilst in JNI critical region
>  - Merge branch 'master' into 8369515-jni-critical
>  - Revert "8369515"
>    
>    This reverts commit 3beb23ccbf5adb98d8c6ad404d40c603bbf499dc.
>  - 8369515

Fixing deadlock issues caused by suspend requests can easily become quite messy, but not this time. I think it's an elegant solution, with a good explaining source code comment. Thank you!

-------------

Marked as reviewed by fbredberg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28779#pullrequestreview-3591638468

From jwaters at openjdk.org  Thu Dec 18 10:09:46 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 18 Dec 2025 10:09:46 GMT
Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v6]
In-Reply-To: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
Message-ID: <9d-P0_nfPLTsL56a1PsIzJc4vOSOh92FLzwFVYlgsFw=.739db1c3-f580-4698-ab27-06a036ab77df@github.com>

> 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 incrementally with one additional commit since the last revision:

  Revert LINK_TIME_OPTIMIZATION in ClientLibraries.gmk

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22464/files
  - new: https://git.openjdk.org/jdk/pull/22464/files/fbe79af6..3e6c0650

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22464&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22464&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 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 rcastanedalo at openjdk.org  Thu Dec 18 10:15:00 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Thu, 18 Dec 2025 10:15:00 GMT
Subject: [jdk26] RFR: 8351889: C2 crash: assertion failed: Base pointers
 must match (addp 344)
In-Reply-To: <pGBYr16YEbYzSHyQTnMK1EFzWv2dLR2P19P_gzEo7Bo=.0fc3368f-4917-4145-a178-845efaeaa1bd@github.com>
References: <pGBYr16YEbYzSHyQTnMK1EFzWv2dLR2P19P_gzEo7Bo=.0fc3368f-4917-4145-a178-845efaeaa1bd@github.com>
Message-ID: <XLhdbgYHKHouX87p8rPLg0_bXZh_tp-lqUY-_-qOjcA=.1f04d078-57da-44ba-9ac0-6ecf43e7c300@github.com>

On Thu, 18 Dec 2025 08:31:35 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [ad29642d](https://github.com/openjdk/jdk/commit/ad29642d8f4e8e0fb1223b14b85ab7841d7b1b51) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Roland Westrelin on 15 Dec 2025 and was reviewed by Roberto Casta?eda Lozano and Emanuel Peter.
> 
> Thanks!

Running internal tests, will come back with results.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28893#issuecomment-3669508548

From duke at openjdk.org  Thu Dec 18 11:38:47 2025
From: duke at openjdk.org (Ruben)
Date: Thu, 18 Dec 2025 11:38:47 GMT
Subject: RFR: 8373697: AArch64: Remove deoptimization stub code for
 nmethods with small stack frames
In-Reply-To: <LvdwgIjv2xY3pmOijohkA1h2c61vUSWtgEug7b4k8-w=.6f6e5cbd-a9f1-4154-8205-de52479fdd1f@github.com>
References: <LvdwgIjv2xY3pmOijohkA1h2c61vUSWtgEug7b4k8-w=.6f6e5cbd-a9f1-4154-8205-de52479fdd1f@github.com>
Message-ID: <laBBjEvksraEmA2GPDJ0VcgHLH2wmv-YZYNePhuz1yc=.d48b1b0c-5d69-4566-af86-c7336c50f8be@github.com>

On Tue, 16 Dec 2025 23:15:12 GMT, Ruben <duke at openjdk.org> wrote:

> Removal of deoptimization stub codes improves density of compiled code.
> It is possible at least for methods with relatively small stack frames.

Thank you for the feedback.

I agree that this change requires a detailed description.

I will be out of office until early January - I'm planning to provide more details, update PR description, and add comments, when I am back.

= A high-level description =

Assumptions:
- the deoptimization stub code needs to be unique per method only for the purpose of identifying the deoptimized method based on the pointer to the return address stored within the deoptimized compiled frame.
- for any deoptimized compiled frame, original PC slot always contains valid pointer into the deoptimized method

Normally, VM doesn't know how to find the original PC slot within the compiled frame until it knows what nmethod corresponds to the compiled frame: because layouts of compiled frames, and so offsets to the original PC slots, vary between compiled methods.

Prior to the change, the first thing the VM would do when parsing a deoptimized compiled frame: lookup nmethod using the return address which would be pointing to the nmethod-specific deoptimization stub code.
The chain of lookup was: return address -> find containing nmethod blob in code cache -> lookup the original PC slot offset -> load original PC from the compiled frame.

If we are to remove deoptimization stub code, we need an alternative way for the VM to identify the nmethod based on the return address value.
At the same time, the return address value should be a valid pointer to executable code transferring control to the shared deoptimization blob.

The proposal implemented in the current version:
 - introduce a number of extra entry points into the shared deoptimization blob: every entry point corresponds to a particular offset of original PC slot within a compiled frame;
 - when deoptimizing a compiled frame, use the original PC slot as usual and patch the return address with one of the extra entry points corresponding to original PC slot offset within the particular compiled frame

This allows VM to identify the location of original PC slot, and so to find the nmethod, based on the return address.
At the same time, the return address indeed transfers control to the shared deoptimization blob.

The proposed chain of lookup is: return address -> lookup the original PC slot offset -> load original PC from the compiled frame -> find containing nmethod blob in code cache.

A restriction is: the compiled frame size is not limited. So, for some of the methods - with relatively big stack frames - VM would not be able to find a matching extra entry point.
For those methods, the per-nmethod deoptimization stub code still has to be emitted.


> like putting the original pc at a fixed slot in the compiled frames

Technically, original PC slot is a fixed slot already:
https://github.com/openjdk/jdk/blob/2ba423db9925355348106fc9fcf84450123d2605/src/hotspot/share/opto/output.cpp#L232

The obstacle is that the fixed slots are located at the end of compiled frame, so offset to the first fixed slot depends on number of spill and argument slots.
I believe, it is possible to move the slot after the argument slots and before the spill slots - in this case, the offset has a relatively low upper limit.
However, that would result in moving all spill slots further into the compiled frame - correspondingly, increasing their offsets in memory access instructions.
That would increase a chance of a frequently accessed spill slot requiring an extra operation to compute its address within the stack frame.
This is unlikely to be an issue with LDR/STR due to the offset range they allow; however for LDP/STP the issue might be likely enough to happen.
As far as I understand, this might negatively affect performance due to extra operation required; and also might increase code size, indirectly further affecting the performance.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28857#issuecomment-3669859579

From duke at openjdk.org  Thu Dec 18 11:38:50 2025
From: duke at openjdk.org (Ruben)
Date: Thu, 18 Dec 2025 11:38:50 GMT
Subject: RFR: 8373697: AArch64: Remove deoptimization stub code for
 nmethods with small stack frames
In-Reply-To: <9DEiudi1rEEJKtKMj6QWBTZVX188uZkXAJ-8jMSJqOE=.337e7eaf-27c8-42a2-9723-d8ee56139e1c@github.com>
References: <LvdwgIjv2xY3pmOijohkA1h2c61vUSWtgEug7b4k8-w=.6f6e5cbd-a9f1-4154-8205-de52479fdd1f@github.com>
 <9DEiudi1rEEJKtKMj6QWBTZVX188uZkXAJ-8jMSJqOE=.337e7eaf-27c8-42a2-9723-d8ee56139e1c@github.com>
Message-ID: <pht2RUzuos73fVtcCIyC48T26PDJZdluQcDE3LLFI6U=.c633504f-70c0-4f71-8e56-65d19763bd0d@github.com>

On Wed, 17 Dec 2025 02:23:43 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Removal of deoptimization stub codes improves density of compiled code.
>> It is possible at least for methods with relatively small stack frames.
>
> src/hotspot/share/opto/output.cpp line 1794:
> 
>> 1792:     }
>> 1793:     // Emit the deopt handler code if needed.
>> 1794:     if (AlwaysEmitDeoptStubCode
> 
> I count 5 times this same expression is repeated.  Maybe it would make sense to move it to an inlined helper function.

I will add a helper function for this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28857#discussion_r2630696744

From mablakatov at openjdk.org  Thu Dec 18 11:46:01 2025
From: mablakatov at openjdk.org (Mikhail Ablakatov)
Date: Thu, 18 Dec 2025 11:46:01 GMT
Subject: RFR: 8373794: Move nmethod header from CodeCache
In-Reply-To: <D3QW0mZMMB6xqqWLHzby7OrXqmhk6wym_aer9NO-3cY=.3b5d2679-0274-4982-816d-f0470b282dc5@github.com>
References: <RZYpT82maT4ayWODxISztNMAQwPOqilJsmjTtfZA9X4=.5953f303-ddb7-4f1e-ab27-e5b3ccaa039f@github.com>
 <D3QW0mZMMB6xqqWLHzby7OrXqmhk6wym_aer9NO-3cY=.3b5d2679-0274-4982-816d-f0470b282dc5@github.com>
Message-ID: <OXdxkKPLpfH2x3USPVplcWsMSEnaTl5AdN6MZ47YNGM=.5870da0c-cd99-4305-a088-7c10dd0c5e20@github.com>

On Wed, 17 Dec 2025 17:14:29 GMT, Chris Plummer <cjplummer at openjdk.org> 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/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/NMethod.java line 104:
> 
>> 102: 
>> 103:     sun.jvm.hotspot.types.Field f = type.getField("_speculations_offset", false, false);
>> 104:     if (f != null) {
> 
> Why is there a need for a null check here?

`_speculations_offset` is present only when JVM is compiled with JVMCI enabled, see https://github.com/openjdk/jdk/pull/28866/files/bbb3711df942ec48b0b0a6eeb287f5364afa9098#diff-ccbdfe031dfc301041cac88f76f8eb2dcacff1b9f81c50073de5c6eaeb8b8223R256 . `type.getCIntegerField("_speculations_offset")` will throw an exception if the field is missing.

Though, if the SA can't be used at all with JVMCI disabled, this check can be omitted as redundant. Please let me know if that's the case.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28866#discussion_r2630716509

From duke at openjdk.org  Thu Dec 18 11:56:33 2025
From: duke at openjdk.org (Ruben)
Date: Thu, 18 Dec 2025 11:56:33 GMT
Subject: RFR: 8373697: AArch64: Remove deoptimization stub code for
 nmethods with small stack frames
In-Reply-To: <9DEiudi1rEEJKtKMj6QWBTZVX188uZkXAJ-8jMSJqOE=.337e7eaf-27c8-42a2-9723-d8ee56139e1c@github.com>
References: <LvdwgIjv2xY3pmOijohkA1h2c61vUSWtgEug7b4k8-w=.6f6e5cbd-a9f1-4154-8205-de52479fdd1f@github.com>
 <9DEiudi1rEEJKtKMj6QWBTZVX188uZkXAJ-8jMSJqOE=.337e7eaf-27c8-42a2-9723-d8ee56139e1c@github.com>
Message-ID: <3MFfyuSA_UVJLeWeVRmZpEZexynYnZtb1fca2dLhwcg=.767c3be6-6aea-4cff-8b2d-6349dbcc38bc@github.com>

On Wed, 17 Dec 2025 02:21:04 GMT, Dean Long <dlong at openjdk.org> wrote:

> should we consider alternative solutions

Another idea I've been thinking about, however in an abstract form only so far - it is not validated or thought through: 
- to remove the original PC slot and deoptimization stub codes completely
- to create a linked list of deoptimized frames with the head pointer being in the thread structure

The list would be linked via return address slots: each slot would be split into two fields: the original PC encoded as a 32-bit offset within the code cache, 32-bit offset to the next deoptimized stack frame if any.


The top deoptimized stack frame's return address would be handled in a different way: it would point to the shared deoptimization blob entry point; its original PC will be saved in the thread structure along with the head pointer.

Once deoptimization completes for the top deoptimized frame, the next stack frame in the list is patched to point to shared deoptimization blob.

I'm not sure about a few aspects:
- whether exception handling can result in discarding a deoptimized stack frame without it being processed
- what are requirements in terms of visibility from other threads - whether existing synchronization mechanism is sufficient to support this scheme
- whether original PC slot can be outside the code cache for AOT case

It is an abstract idea at this stage, and I am not meaning to propose it as an alternative for this PR. However, if it seems potentially feasible, I might be able to allocate some time to explore this more in future.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28857#issuecomment-3669923204

From bkilambi at openjdk.org  Thu Dec 18 12:44:53 2025
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Thu, 18 Dec 2025 12:44:53 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v7]
In-Reply-To: <BJEB4Rq-cl7ROsU-CK0Gx1dqfb4tiDbrSSu24RNWoj0=.a17b8afa-e5db-4920-9d26-76d506b4d5c6@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <H1M8_FtGtYl2jww_n3OE5o3G8SFCe8TMl-XgtRA6Krg=.fb56cb81-2890-47c5-b35b-b2d730e3e71f@github.com>
 <lho5QXHxy87rtS6SRdOizf-Qtgdl7hTyTmvi2M1SGpk=.25bc3ffb-1390-4ab4-bcfe-28d215d70099@github.com>
 <zNHLhur1oCstOsckD8RkiLBlL60H-n2q8_1Ikz6g5Gk=.c1b33e99-16c6-4f8e-855d-a862bf04f9f3@github.com>
 <BJEB4Rq-cl7ROsU-CK0Gx1dqfb4tiDbrSSu24RNWoj0=.a17b8afa-e5db-4920-9d26-76d506b4d5c6@github.com>
Message-ID: <5NNS6uN_GhivBLv-OhE1Tn0HJhrL6-TKlsN9wWKOytU=.d36bafc2-a5c4-4878-920c-6707cf3547bb@github.com>

On Tue, 16 Dec 2025 15:45:15 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>>>  I suggest creating a seperate PR for this ? You can either create a smaller standalone reproducer testcase or mention about the tests part of this PR.
>> 
>> Hi @jbhateja, thanks for the suggestion. Based on the comments here - https://bugs.openjdk.org/browse/JDK-8373574, is it ok if my fix (along with a regression test as suggested) be part of this PR?
>
>> > I suggest creating a seperate PR for this ? You can either create a smaller standalone reproducer testcase or mention about the tests part of this PR.
>> 
>> Hi @jbhateja, thanks for the suggestion. Based on the comments here - https://bugs.openjdk.org/browse/JDK-8373574, is it ok if my fix (along with a regression test as suggested) be part of this PR?
> 
> Hi @Bhavana-Kilambi , As @TobiHartmann suggested we can included your patch with the PR.
> Best Regards

Thanks @jatin-bhateja for including AArch64 changes to the patch. Also @TobiHartmann suggested (here - https://bugs.openjdk.org/browse/JDK-8373574) that it'd be good to have a regression test for the AArch64 failures. I have put together a small JTREG test taking one of the VectorAPI tests from `TestFloat16VectorOperations.java` introduced in this PR (which was the one failing on AArch64). Could you please include the testcase as well? The patch is attached here
[test.patch](https://github.com/user-attachments/files/24235556/test.patch)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3670100491

From mablakatov at openjdk.org  Thu Dec 18 13:24:37 2025
From: mablakatov at openjdk.org (Mikhail Ablakatov)
Date: Thu, 18 Dec 2025 13:24:37 GMT
Subject: RFR: 8357258: x86: Improve receiver type profiling reliability
 [v8]
In-Reply-To: <znkJzX6vqwn6MuX7YdQ6duTJ9srsVC1cjqZV0M2oYuQ=.0b1a7244-40d8-4809-b726-38af03701274@github.com>
References: <X9RJoDWqk67MlK7P4ACCbzROxLkfEqvU0zDid3zymnc=.7c0086a3-f514-4b0d-8bc0-592bf4a05bba@github.com>
 <avqNAcH5MpUoM31mrtm0Z6qnPqpgbpGszW01AtFbYXk=.359b8088-c0b5-4a01-aefc-fe3c02bdd60a@github.com>
 <dEG0Z-h_AKU79xlcWa3tyWqbMZSFqm9m6vEKl19JlBo=.deff71db-d617-4df9-8aa0-7242875b666c@github.com>
 <znkJzX6vqwn6MuX7YdQ6duTJ9srsVC1cjqZV0M2oYuQ=.0b1a7244-40d8-4809-b726-38af03701274@github.com>
Message-ID: <BpUXGyRy2jo8jDXQsaQZev474s1p1gAYEFiR5fcZ4Ag=.03df3dab-ddaf-468d-8932-10ea2614de28@github.com>

On Wed, 10 Dec 2025 08:28:47 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Overall, looks good to me. Nice work, Aleksey!
>> 
>> I'm curious how performance-sensitive that part of code is. Does it make sense to try to further optimize it?
>> 
>> For example:
>>   - 2 slots is the most common case; any benefits from optimizing specifically for it (e.g., unroll the loops)?
>>   -  fast path can be further optimized for no nulls case by offloading more work on found_null slow path [1]
>> 
>> [1]
>> 
>>     // Fastest: receiver is already installed
>>     int i = 0;
>>     for (; i < receiver_count(); i++) {
>>       if (receiver(i) == recv) goto found_recv(i);
>>       if (receiver(i) == null) goto found_null(i);
>>     }
>>   
>>     goto polymorphic
>>   
>>     // Slow: try to install receiver
>>   found_null(i):
>>     // Finish the search
>>     for (int j = i ; j < receiver_count(); j++) {
>>       if (receiver(j) == recv) goto found_recv(j);
>>     }
>>     CAS(&receiver(i), null, recv);
>>     goto restart
>> ...
>
>> I'm curious how performance-sensitive that part of code is. Does it make sense to try to further optimize it?
> 
> This is about 5-th-ish version of this code, so I don't think there is more juice to squeeze out of it. The current version is more or less optimal. The stratification into three cases looks the best performing overall.
> 
>> fast path can be further optimized for no nulls case by offloading more work on found_null slow path [1]
> 
> Yeah, but putting checks for both installed receiver and nullptr slot turns out hurting performance; this is bad even without extra control flow. Two separate loops are more efficient, even for small number of iterations. It also helpfully optimizes for the best case, when profile is smaller than `TypeProfileWidth`, which is what we want.
> 
>>  2 slots is the most common case; any benefits from optimizing specifically for it (e.g., unroll the loops)?
> 
> I don't think it is worth the extra complexity, honestly. The loop-y code in current version is still a significant code density win over the decision-tree (unrolled, effectively) approach we are doing currently. Keeping this thing simple means more reliability and less testing surface, plus much less headache to port to other architectures.
> 
> Note that the goal for this work is to _improve profiling reliability_ without hopefully ceding too much ground in code density and performance. When I started out, it was not clear if it is doable, given the need for atomics; but it looks doable indeed. So I think we should call this thing done and move on to solving the actual performance problem in this code: the contention on counter updates.

Hi @shipilev , are you aware of anyone working on or planning to implement the same for AArch64 by any chance?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25305#issuecomment-3670273806

From duke at openjdk.org  Thu Dec 18 13:31:02 2025
From: duke at openjdk.org (Ruben)
Date: Thu, 18 Dec 2025 13:31:02 GMT
Subject: RFR: 8373696: AArch64: Refine post-call NOPs
In-Reply-To: <dWPoRFGyblY6jRLFkhxRpRO1-qKrVR0pyYKNeyCEI8A=.c4b9d54b-e8ad-4e92-a5d4-69f34af7ebf7@github.com>
References: <IYr1eAznZw4gu4pj399qpqSdYX4q5J572m79d9Cdh5E=.ccd850a7-0d78-4f19-84f9-fc82f2ff7707@github.com>
 <dWPoRFGyblY6jRLFkhxRpRO1-qKrVR0pyYKNeyCEI8A=.c4b9d54b-e8ad-4e92-a5d4-69f34af7ebf7@github.com>
Message-ID: <ad6DCUp-mt3P-PeLGRw-XGLetzLqk2QA67FbTEYoVB0=.26b1136b-de16-4401-a722-e000ca0dc3c7@github.com>

On Wed, 17 Dec 2025 09:32:43 GMT, Andrew Haley <aph at openjdk.org> 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 ...
>
> While the basic idea is a good one, I think there are better ways to do it.
> 
> Consider fixing the number of instructions to two rather than three. Then a post-call NOP can be either 'nop; movk/movz` or `b.nv; movk/adrp`. Or something similar.. `b.nv` is more expensive, but should be rare.

Thank you for the feedback, @theRealAph,

I will be out of office until early January - I'm planning to respond in more detail and work on updating the PR when I am back.

I agree a fixed-length post-call NOP sequence would be preferable and would make the implementation simpler.

The `B.nv` might not be suitable in this case - I believe the branch will be "always taken".
However, I had considered using `CBNZ XZR, <#imm>`. So far, I avoided implementing it because it is unclear what performance effects this might have.

While I agree that the case will be rare in terms of static occurrences - it might still impact performance if a particular instance is on a frequent execution path.

I believe the change in C1 floating-point constants handling is a dependency for the current implementation - it allows keeping the constants section empty and ensures the compiler can determine the offset to the code blob header before the code buffer is finalized. However, if the approach is changed to a fixed post-call NOP sequence length, there will be no dependency between these two optimizations.

I will revisit both the post-call NOP sequence structure and the dependency on floating-point constants handling when I return in January.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28855#issuecomment-3670298853

From aph at openjdk.org  Thu Dec 18 13:55:41 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 18 Dec 2025 13:55:41 GMT
Subject: RFR: 8373696: AArch64: Refine post-call NOPs
In-Reply-To: <IYr1eAznZw4gu4pj399qpqSdYX4q5J572m79d9Cdh5E=.ccd850a7-0d78-4f19-84f9-fc82f2ff7707@github.com>
References: <IYr1eAznZw4gu4pj399qpqSdYX4q5J572m79d9Cdh5E=.ccd850a7-0d78-4f19-84f9-fc82f2ff7707@github.com>
Message-ID: <9G7UQDZGLfV0nhrQSv-a9EMvhIAkCdTB3hA9Pf6hRIo=.59b380be-e009-420e-8f76-7771e205467b@github.com>

On Tue, 16 Dec 2025 22:45:08 GMT, Ruben <duke at openjdk.org> 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       |  -0.096% |    -0.773% to  0.586% |
>   | org.renaissance.twitter.finagle.J...

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.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28855#issuecomment-3670392141

From aph at redhat.com  Thu Dec 18 14:27:20 2025
From: aph at redhat.com (Andrew Haley)
Date: Thu, 18 Dec 2025 14:27:20 +0000
Subject: RFR: 8373696: AArch64: Refine post-call NOPs
In-Reply-To: <9G7UQDZGLfV0nhrQSv-a9EMvhIAkCdTB3hA9Pf6hRIo=.59b380be-e009-420e-8f76-7771e205467b@github.com>
References: <IYr1eAznZw4gu4pj399qpqSdYX4q5J572m79d9Cdh5E=.ccd850a7-0d78-4f19-84f9-fc82f2ff7707@github.com>
 <9G7UQDZGLfV0nhrQSv-a9EMvhIAkCdTB3hA9Pf6hRIo=.59b380be-e009-420e-8f76-7771e205467b@github.com>
Message-ID: <8fa8285d-cf5b-449d-b793-7155f803cae0@redhat.com>

On 18/12/2025 13:55, Andrew Haley wrote:
>> 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.

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.


From duke at openjdk.org  Thu Dec 18 14:29:52 2025
From: duke at openjdk.org (Yuri Gaevsky)
Date: Thu, 18 Dec 2025 14:29:52 GMT
Subject: RFR: 8324124: RISC-V: implement _vectorizedMismatch intrinsic [v7]
In-Reply-To: <dxSBhJiLeVkLF8PvHW3MMg69vwXU0VshECCMz5HnhhI=.e0cbda8b-f7f6-44ff-806b-1f21496911be@github.com>
References: <dxSBhJiLeVkLF8PvHW3MMg69vwXU0VshECCMz5HnhhI=.e0cbda8b-f7f6-44ff-806b-1f21496911be@github.com>
Message-ID: <fqAU2x3EdNT4PfS_Zy8bOPFtLzJpOWm9k8QoeJ7q9Xc=.981de870-39af-4e52-99c8-06f2dfde70b5@github.com>

> Hello All,
> 
> Please review these changes to enable the __vectorizedMismatch_ intrinsic on RISC-V platform with RVV instructions supported.
> 
> Thank you,
> -Yuri Gaevsky
> 
> **Correctness checks:**
>   hotspot/jtreg/compiler/{intrinsic/c1/c2}/ under QEMU-8.1 with RVV v1.0.0 and -XX:TieredStopAtLevel=1/2/3/4.

Yuri Gaevsky has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge master
 - removed unneeded check for zero length; changed lmul from m8 to m2.
 - - moved vector register declarations into vectorized_mismatch() body.
   - added initial support for ArrayOperationPartialInlineSize.
 - removed obsolete code.
 - Merge master
 - Merge master
 - 8324124: RISC-V: implement _vectorizedMismatch intrinsic

-------------

Changes: https://git.openjdk.org/jdk/pull/17750/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17750&range=06
  Stats: 174 lines in 6 files changed: 168 ins; 5 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17750.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17750/head:pull/17750

PR: https://git.openjdk.org/jdk/pull/17750

From shade at openjdk.org  Thu Dec 18 15:27:01 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 18 Dec 2025 15:27:01 GMT
Subject: RFR: 8357258: x86: Improve receiver type profiling reliability
 [v8]
In-Reply-To: <znkJzX6vqwn6MuX7YdQ6duTJ9srsVC1cjqZV0M2oYuQ=.0b1a7244-40d8-4809-b726-38af03701274@github.com>
References: <X9RJoDWqk67MlK7P4ACCbzROxLkfEqvU0zDid3zymnc=.7c0086a3-f514-4b0d-8bc0-592bf4a05bba@github.com>
 <avqNAcH5MpUoM31mrtm0Z6qnPqpgbpGszW01AtFbYXk=.359b8088-c0b5-4a01-aefc-fe3c02bdd60a@github.com>
 <dEG0Z-h_AKU79xlcWa3tyWqbMZSFqm9m6vEKl19JlBo=.deff71db-d617-4df9-8aa0-7242875b666c@github.com>
 <znkJzX6vqwn6MuX7YdQ6duTJ9srsVC1cjqZV0M2oYuQ=.0b1a7244-40d8-4809-b726-38af03701274@github.com>
Message-ID: <cx0cFxMFR8PVPy-wLQe8relCMrhfhdIK761LWYlJEns=.210e1d3e-34d0-40ef-8de6-5247da5ece11@github.com>

On Wed, 10 Dec 2025 08:28:47 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Overall, looks good to me. Nice work, Aleksey!
>> 
>> I'm curious how performance-sensitive that part of code is. Does it make sense to try to further optimize it?
>> 
>> For example:
>>   - 2 slots is the most common case; any benefits from optimizing specifically for it (e.g., unroll the loops)?
>>   -  fast path can be further optimized for no nulls case by offloading more work on found_null slow path [1]
>> 
>> [1]
>> 
>>     // Fastest: receiver is already installed
>>     int i = 0;
>>     for (; i < receiver_count(); i++) {
>>       if (receiver(i) == recv) goto found_recv(i);
>>       if (receiver(i) == null) goto found_null(i);
>>     }
>>   
>>     goto polymorphic
>>   
>>     // Slow: try to install receiver
>>   found_null(i):
>>     // Finish the search
>>     for (int j = i ; j < receiver_count(); j++) {
>>       if (receiver(j) == recv) goto found_recv(j);
>>     }
>>     CAS(&receiver(i), null, recv);
>>     goto restart
>> ...
>
>> I'm curious how performance-sensitive that part of code is. Does it make sense to try to further optimize it?
> 
> This is about 5-th-ish version of this code, so I don't think there is more juice to squeeze out of it. The current version is more or less optimal. The stratification into three cases looks the best performing overall.
> 
>> fast path can be further optimized for no nulls case by offloading more work on found_null slow path [1]
> 
> Yeah, but putting checks for both installed receiver and nullptr slot turns out hurting performance; this is bad even without extra control flow. Two separate loops are more efficient, even for small number of iterations. It also helpfully optimizes for the best case, when profile is smaller than `TypeProfileWidth`, which is what we want.
> 
>>  2 slots is the most common case; any benefits from optimizing specifically for it (e.g., unroll the loops)?
> 
> I don't think it is worth the extra complexity, honestly. The loop-y code in current version is still a significant code density win over the decision-tree (unrolled, effectively) approach we are doing currently. Keeping this thing simple means more reliability and less testing surface, plus much less headache to port to other architectures.
> 
> Note that the goal for this work is to _improve profiling reliability_ without hopefully ceding too much ground in code density and performance. When I started out, it was not clear if it is doable, given the need for atomics; but it looks doable indeed. So I think we should call this thing done and move on to solving the actual performance problem in this code: the contention on counter updates.

> Hi @shipilev , are you aware of anyone working on or planning to implement the same for AArch64 by any chance?

I'll task one of our folks to do it after NY break. 

Speaking of, I will integrate this one after NY break as well, to avoid dealing with any possible fallout during the holidays.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25305#issuecomment-3670834495

From ogillespie at openjdk.org  Thu Dec 18 15:34:25 2025
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Thu, 18 Dec 2025 15:34:25 GMT
Subject: RFR: 8372701: Randomized profile counters [v5]
In-Reply-To: <1nJnov3s2hhiLuO0W2FNcSAiGu5eEjZauQxfzd5YXKw=.8c593111-294a-4df7-8ce0-322871a801f3@github.com>
References: <jKjmIONZcytzVjS4absOwOLv_QOF9qhIJifYhN6JyP4=.dceced94-bc29-43e6-9062-8dc77c2a6133@github.com>
 <1nJnov3s2hhiLuO0W2FNcSAiGu5eEjZauQxfzd5YXKw=.8c593111-294a-4df7-8ce0-322871a801f3@github.com>
Message-ID: <RWVI6OlhPp1-JymmTYg6DJFfoq7iBd2JyTZcMKrbeE4=.217158c4-6ce2-4a00-b8ec-a2b4fd375a4c@github.com>

On Tue, 9 Dec 2025 17:09:43 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> 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 with a new target base due to a merge or a rebase. The pull request now contains 58 commits:
> 
>  - Merge from master branch
>  - Merge remote-tracking branch 'refs/remotes/origin/JDK-8134940' into JDK-8134940
>  - Fix x86 lambda
>  - More
>  - Merge branch 'master' into JDK-8134940
>  - Merge branch 'master' into JDK-8134940
>  - Merge remote-tracking branch 'refs/remotes/origin/JDK-8134940' into JDK-8134940
>  - whitespace
>  - AArch64
>  - Minimize deltas to master
>  - ... and 48 more: https://git.openjdk.org/jdk/compare/7da91533...96db42e2

I tested the jython benchmark on my x86 host and while I didn't see the reported >10% regression, I did see some differences. Profiling hinted at String operations, and playing with jdk String benchmarks I found that enabling randomized profile counters seems to make the performance of `micro:org.openjdk.bench.java.lang.StringIndexOfChar.latin1_SSE4_String` bi-modal on my setup. See results at https://gist.github.com/olivergillespie/33324b5e95e1d8fc64dbcbff1884dade. I don't know how or if that connects to the other curious results, but sharing just in case it's helpful. Can provide any details/perfasm etc. if needed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28541#issuecomment-3670866566

From liach at openjdk.org  Thu Dec 18 16:28:36 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 18 Dec 2025 16:28:36 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting [v7]
In-Reply-To: <mQ4Fm4K2xIuHNv_NyvU43L2LpN0SThdlhEYiel6jc_k=.19ed6b8f-385f-49e9-946b-ed87df7672fc@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
 <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com>
 <mQ4Fm4K2xIuHNv_NyvU43L2LpN0SThdlhEYiel6jc_k=.19ed6b8f-385f-49e9-946b-ed87df7672fc@github.com>
Message-ID: <WZIrMr34M_m740iyXYjQ4Ojl6vzwr3vV6hb6pXFsknw=.08d8c598-ea0f-4bd7-8714-26365a7f3718@github.com>

On Thu, 18 Dec 2025 04:58:38 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> So my question is why this annotation does not try to enforce a stronger invariant so that we can benefit from those invariants without having to wait for strict fields.

No. We currently cannot enforce such final fields to be all written before the `Object::<init>` entry, and I also don't think mainline has this safe publication fence at the beginning of `Object::<init>` either.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28540#issuecomment-3671092060

From duke at openjdk.org  Thu Dec 18 16:31:04 2025
From: duke at openjdk.org (Ruben)
Date: Thu, 18 Dec 2025 16:31:04 GMT
Subject: RFR: 8366441: AArch64: Support WFET in OnSpinWait [v2]
In-Reply-To: <pCQ3UJd__52UsHCs4O0oLcLZTXN602dBEP8zmRvU-H4=.aff34c5d-0a53-4e9a-8107-b6fadc7d9cca@github.com>
References: <pCQ3UJd__52UsHCs4O0oLcLZTXN602dBEP8zmRvU-H4=.aff34c5d-0a53-4e9a-8107-b6fadc7d9cca@github.com>
Message-ID: <UI2bnAbh8QCHp_z2HF7QlGkhw3jmiE65KgKUAqAH5GI=.81f3cf8b-5d22-4050-80d2-948972329643@github.com>

> Implement OnSpinWait based on WFET - wait for event with timeout:
>  - introduce OnSpinWaitDelay - the OnSpinWait time in nanoseconds;
>  - the OnSpinWaitInstCount is expected to be 1 when WFET is used;
>  - the waiting loop is followed by SB - to ensure following instructions aren't speculated until wait is finished;
>  - the timer register is read via the self-synchronized view CNTVCTSS_EL0 to prevent the read being hoisted out of the loop.
> 
> The WFET and CNTVCTSS_EL0 read are added to aarch64-asmtest.py as hex values - using the instruction mnemonics would require support of -march=armv9-2.a, and consequently, the binutils 2.36+.

Ruben has updated the pull request incrementally with one additional commit since the last revision:

  Fix bsd_aarch64 build

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27030/files
  - new: https://git.openjdk.org/jdk/pull/27030/files/55efce00..c41fb0da

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27030&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27030&range=00-01

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27030.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27030/head:pull/27030

PR: https://git.openjdk.org/jdk/pull/27030

From qamai at openjdk.org  Thu Dec 18 16:49:25 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 18 Dec 2025 16:49:25 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting [v7]
In-Reply-To: <WZIrMr34M_m740iyXYjQ4Ojl6vzwr3vV6hb6pXFsknw=.08d8c598-ea0f-4bd7-8714-26365a7f3718@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
 <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com>
 <mQ4Fm4K2xIuHNv_NyvU43L2LpN0SThdlhEYiel6jc_k=.19ed6b8f-385f-49e9-946b-ed87df7672fc@github.com>
 <WZIrMr34M_m740iyXYjQ4Ojl6vzwr3vV6hb6pXFsknw=.08d8c598-ea0f-4bd7-8714-26365a7f3718@github.com>
Message-ID: <yKmMsZMaqrbOTZrjZYMdrQT7sfxJXUg7cKiwgBL0Zmk=.36d594ba-f807-4872-8036-940a873267a7@github.com>

On Thu, 18 Dec 2025 16:25:29 GMT, Chen Liang <liach at openjdk.org> wrote:

>> What I mean by stronger is that trusted final fields only ensure that their values are unchanged after initialization. Strict fields are unchanged unconditionally, there is only 1 observable state for a strict field of an object. As a result, in addition to constant folding, we can do load hoisting, too. So my question is why this annotation does not try to enforce a stronger invariant so that we can benefit from those invariants without having to wait for strict fields.
>
>> So my question is why this annotation does not try to enforce a stronger invariant so that we can benefit from those invariants without having to wait for strict fields.
> 
> No. We currently cannot enforce such final fields to be all written before the `Object::<init>` entry, and I also don't think mainline has this safe publication fence at the beginning of `Object::<init>` either.

@liach I don't think we need such a condition, we only need to ensure that the fields are not read from and the object does not escape to memory before the termination of `<init>`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28540#issuecomment-3671176336

From cjplummer at openjdk.org  Thu Dec 18 17:08:24 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 18 Dec 2025 17:08:24 GMT
Subject: RFR: 8373794: Move nmethod header from CodeCache
In-Reply-To: <OXdxkKPLpfH2x3USPVplcWsMSEnaTl5AdN6MZ47YNGM=.5870da0c-cd99-4305-a088-7c10dd0c5e20@github.com>
References: <RZYpT82maT4ayWODxISztNMAQwPOqilJsmjTtfZA9X4=.5953f303-ddb7-4f1e-ab27-e5b3ccaa039f@github.com>
 <D3QW0mZMMB6xqqWLHzby7OrXqmhk6wym_aer9NO-3cY=.3b5d2679-0274-4982-816d-f0470b282dc5@github.com>
 <OXdxkKPLpfH2x3USPVplcWsMSEnaTl5AdN6MZ47YNGM=.5870da0c-cd99-4305-a088-7c10dd0c5e20@github.com>
Message-ID: <pLY5S80MHBaMO-dxZZ-TviByW_eBH_VsNteySZWpflw=.bf699af4-259d-46f2-9496-ccd0677b9b8a@github.com>

On Thu, 18 Dec 2025 11:43:22 GMT, Mikhail Ablakatov <mablakatov at openjdk.org> wrote:

> Though, if the SA can't be used at all with JVMCI disabled, this check can be omitted as redundant. Please let me know if that's the case.

I know of no reason why SA won't work with JVMCI disabled, but I'm also not sure if we test that so there could be bugs.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28866#discussion_r2631875749

From mablakatov at openjdk.org  Thu Dec 18 17:18:41 2025
From: mablakatov at openjdk.org (Mikhail Ablakatov)
Date: Thu, 18 Dec 2025 17:18:41 GMT
Subject: RFR: 8373794: Move nmethod header from CodeCache
In-Reply-To: <LAFydlD8_MzjwVnLzuGb6ICtSxWqSPsguQSM6lynUmA=.f71c0b41-948f-403d-8670-beeee6d6f9a9@github.com>
References: <RZYpT82maT4ayWODxISztNMAQwPOqilJsmjTtfZA9X4=.5953f303-ddb7-4f1e-ab27-e5b3ccaa039f@github.com>
 <LAFydlD8_MzjwVnLzuGb6ICtSxWqSPsguQSM6lynUmA=.f71c0b41-948f-403d-8670-beeee6d6f9a9@github.com>
Message-ID: <uFs9gKNiVGN4nWJYMRT0WGOf7IFQYBANAuYmIO59A1w=.326f8390-6936-40ed-85fc-98e3a722053f@github.com>

On Thu, 18 Dec 2025 02:23:43 GMT, Dean Long <dlong at openjdk.org> wrote:

> Wouldn't it be better to move the whole CodeBlob header out of the code cache? Instead of nmethod having a _hdr pointer, CodeBlob would be in malloc space and have a _code pointer into the CodeCache.

It might be possible to move both `CodeBlob` and `nmethod` data to the C-heap. We'd still need something like an `_hdr` pointer, since JVM resolves a `CodeBlob` from a method/stub entry point using  [`CodeBlob* CodeCache::find_blob(void* start)`](https://github.com/openjdk/jdk/blob/7a7e7c9ae11cb124c14d5d2d3b7e2f5649205106/src/hotspot/share/code/codeCache.cpp#L640). So if we move every member field to the C-heap, we store a pointer to that data right before a method/stub entry point in the CodeCache and that's it. A `_code` pointer pointing from the C-heap into the CodeCache may not be necessary at all.

That said, this would require moving data for other `CodeBlob` subclasses (`AdapterBlob`, `ExceptionBlob`, etc.) to the C-heap, which would significantly broaden the scope of this patch. 

@Bhavana-Kilambi , what do you thing? Is this something you've considered?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28866#issuecomment-3671287737

From liach at openjdk.org  Thu Dec 18 18:12:59 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 18 Dec 2025 18:12:59 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: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
 <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com>
Message-ID: <Cq8wpx4mSX_YrA2q7vvKKgq0ChNnRDMdwWVOg43EO7w=.f7e01581-e9f3-4e33-9ae7-1e920eb59007@github.com>

On Thu, 18 Dec 2025 00:03:10 GMT, Chen Liang <liach at openjdk.org> 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

We can port JDK-8354068 to mainline, but I think this is better done as a separate effort from the introduction of this annotation.  This patch is more focused on the jdk implications.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28540#issuecomment-3671501119

From pchilanomate at openjdk.org  Thu Dec 18 19:01:58 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 18 Dec 2025 19:01:58 GMT
Subject: RFR: 8369515: Deadlock between JVMTI and JNI
 ReleasePrimitiveArrayCritical [v2]
In-Reply-To: <DdndhI1g51Z9rEMIpU99IPI47NtmbYNYWHVEBrBEOSQ=.7137830c-4ce8-4133-b0bd-ebc9eafe671e@github.com>
References: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
 <DdndhI1g51Z9rEMIpU99IPI47NtmbYNYWHVEBrBEOSQ=.7137830c-4ce8-4133-b0bd-ebc9eafe671e@github.com>
Message-ID: <RAEuicmS-hN6DvZheBoku1T2xxF4RBdMv9pR5HzXYb0=.ba0b1e4e-5a76-48f6-9f2d-101f129950b4@github.com>

On Thu, 18 Dec 2025 01:21:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> As discussed in JBS the deadlock occurs when the call to `ReleasePrimitiveArrayCritical` performs the transition from native to VM, and in the process checks for special runtime exit conditions - which includes the `obj_deopt_suspend` request. The simple solution is to define a custom JNI ENTRY with custom `ThreadInVMfromNative` that elides the exit check.
>> 
>> The change is limited to `ReleasePrimitiveArrayCritical` and `ReleaseStringCritical`.
>> 
>> UPDATE: we are now employing a much simpler solution.
>> 
>> There is no regression test as this has only been seen in long running stress tests.
>> 
>> Testing:
>>    -tiers 1-6
>
> David Holmes 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:
> 
>  - Greatly simplifed fix to just defer object_deopt whilst in JNI critical region
>  - Merge branch 'master' into 8369515-jni-critical
>  - Revert "8369515"
>    
>    This reverts commit 3beb23ccbf5adb98d8c6ad404d40c603bbf499dc.
>  - 8369515

Looks good to me.

FTR we are not processing this special exit condition when transitioning from `_thread_blocked` to `_thread_in_vm` already, so I would assume it should be also okay for any native->vm transition.

src/hotspot/share/runtime/javaThread.cpp line 1057:

> 1055:   // We mustn't block for object deopt if the thread is
> 1056:   // currently executing in a JNI critical region, as that
> 1057:   // can cause deadlock because the GCLocker is held.

I think the last part of the comment might be confusing because it's the deopt suspender that helds the lock waiting for this thread to exit the critical region [[1]](https://github.com/openjdk/jdk/blob/0b2712400b55d4a512db225d090c2f06f01f7f1f/src/hotspot/share/gc/shared/gcLocker.cpp#L108). Maybe "... cause deadlock because the suspender may allocate and block waiting for this thread to exit the critical region"?

-------------

Marked as reviewed by pchilanomate (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28779#pullrequestreview-3594584056
PR Comment: https://git.openjdk.org/jdk/pull/28779#issuecomment-3671778255
PR Review Comment: https://git.openjdk.org/jdk/pull/28779#discussion_r2632288550

From rrich at openjdk.org  Thu Dec 18 19:07:45 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Thu, 18 Dec 2025 19:07:45 GMT
Subject: RFR: 8372591: assert(!current->cont_fastpath() ||
 freeze.check_valid_fast_path()) failed
In-Reply-To: <kCm-ez6k9Jj2bmCrEyNZ_5FbnjsO2yx3V8MK26KO6xw=.bc3645bd-08aa-4f28-a4c1-412b2441e5ba@github.com>
References: <6yaYr_fSazq20-3lshGS-_Lr-LqXMt4lTeaFzDs9U2U=.c865efd1-9b98-4fce-98dd-4e1fe50a45be@github.com>
 <_LgB7c2fIE-RBo1CpmjeirR4oG6v8JBVQZ8spZzDLY8=.a67da689-d204-4550-86b6-c0efde380892@github.com>
 <kCm-ez6k9Jj2bmCrEyNZ_5FbnjsO2yx3V8MK26KO6xw=.bc3645bd-08aa-4f28-a4c1-412b2441e5ba@github.com>
Message-ID: <x_K0IOvZhCD_PHDZdxXiUBCuhtuZMl8giZ6n2ZbAUnM=.f82bb705-473c-4e55-a3c1-b996a34d8831@github.com>

On Thu, 18 Dec 2025 00:02:46 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> > @reinrich @TheRealMDoerr Could you verify if this fix is correct for ppc too? Thanks.
> 
> The fix looks correct. Strangely the reproducer didn't work on ppc. Not even with 3x the locals in the osr method. I'll look a little more into it...

On ppc we reach `OSR_migration_begin` with `_cont_fastpath` that's higher than `sender.sp()` so `push_cont_fastpath(sender.sp())` has no effect.
I'm not sure why this is. It might be due to the trimming with i2i calls where the sender is trimmed to a `parent frame` (the top frame always has room for max_stack). The sender is a lambda. Maybe it has done an i2c call as `top frame` (i.e. untrimmed) which set `_cont_fastpath`?

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?

Note that on ppc frame::id() returns the fp. Maybe this should be used as `_cont_fastpath`. Needs more investigation...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28830#issuecomment-3671801749

From pchilanomate at openjdk.org  Thu Dec 18 20:40:54 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 18 Dec 2025 20:40:54 GMT
Subject: RFR: 8372591: assert(!current->cont_fastpath() ||
 freeze.check_valid_fast_path()) failed
In-Reply-To: <x_K0IOvZhCD_PHDZdxXiUBCuhtuZMl8giZ6n2ZbAUnM=.f82bb705-473c-4e55-a3c1-b996a34d8831@github.com>
References: <6yaYr_fSazq20-3lshGS-_Lr-LqXMt4lTeaFzDs9U2U=.c865efd1-9b98-4fce-98dd-4e1fe50a45be@github.com>
 <_LgB7c2fIE-RBo1CpmjeirR4oG6v8JBVQZ8spZzDLY8=.a67da689-d204-4550-86b6-c0efde380892@github.com>
 <kCm-ez6k9Jj2bmCrEyNZ_5FbnjsO2yx3V8MK26KO6xw=.bc3645bd-08aa-4f28-a4c1-412b2441e5ba@github.com>
 <x_K0IOvZhCD_PHDZdxXiUBCuhtuZMl8giZ6n2ZbAUnM=.f82bb705-473c-4e55-a3c1-b996a34d8831@github.com>
Message-ID: <_lvm42phwda7i6vX6U6cFoaLLu07NELtWmW0pg73IVI=.83b5be81-f8a2-4364-8214-cf7638daff67@github.com>

On Thu, 18 Dec 2025 19:05:08 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> > > @reinrich @TheRealMDoerr Could you verify if this fix is correct for ppc too? Thanks.
> > 
> > 
> > The fix looks correct. Strangely the reproducer didn't work on ppc. Not even with 3x the locals in the osr method. I'll look a little more into it...
> 
> On ppc we reach `OSR_migration_begin` with `_cont_fastpath` that's higher than `sender.sp()` so `push_cont_fastpath(sender.sp())` has no effect. I'm not sure why this is. It might be due to the trimming with i2i calls where the sender is trimmed to a `parent frame` (the top frame always has room for max_stack). The sender is a lambda. Maybe it has done an i2c call as `top frame` (i.e. untrimmed) which set `_cont_fastpath`?
> 
Maybe, but I don't see which compiled method it could be, since methods before `foo` should be interpreted.

> If max_stack of the sender is very large then, due to trimming, unextended_sp < sp is possible and the assertion could also fail.
> 
> Maybe the maximum of unextended_sp and sp could be used?
>
On x64 and AArch64 we build the OSR frame starting from the sender's `unextended_sp` (modulo aligment). Is that not the case for ppc?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28830#issuecomment-3672131775

From aph at openjdk.org  Thu Dec 18 22:12:10 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 18 Dec 2025 22:12:10 GMT
Subject: RFR: 8372701: Randomized profile counters [v5]
In-Reply-To: <RWVI6OlhPp1-JymmTYg6DJFfoq7iBd2JyTZcMKrbeE4=.217158c4-6ce2-4a00-b8ec-a2b4fd375a4c@github.com>
References: <jKjmIONZcytzVjS4absOwOLv_QOF9qhIJifYhN6JyP4=.dceced94-bc29-43e6-9062-8dc77c2a6133@github.com>
 <1nJnov3s2hhiLuO0W2FNcSAiGu5eEjZauQxfzd5YXKw=.8c593111-294a-4df7-8ce0-322871a801f3@github.com>
 <RWVI6OlhPp1-JymmTYg6DJFfoq7iBd2JyTZcMKrbeE4=.217158c4-6ce2-4a00-b8ec-a2b4fd375a4c@github.com>
Message-ID: <al6_M21lmegsbec6Orl6k_VEVJw56Si18x5wp9ni5co=.6c8720ae-643b-42a1-bf18-4d17894ee90d@github.com>

On Thu, 18 Dec 2025 15:31:43 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

> I tested the jython benchmark on my x86 host and while I didn't see the reported >10% regression, I did see some differences. Profiling hinted at String operations, and playing with jdk String benchmarks I found that enabling randomized profile counters seems to make the performance of `micro:org.openjdk.bench.java.lang.StringIndexOfChar.latin1_SSE4_String` bi-modal on my setup. See results at https://gist.github.com/olivergillespie/33324b5e95e1d8fc64dbcbff1884dade. I don't know how or if that connects to the other curious results, but sharing just in case it's helpful. Can provide any details/perfasm etc. if needed.

Brilliant, that's just the kind of report I need.

I think I know the root cause of some of the problems. For some reason, even when C2 detects a natural loop, slightly unbalanced profile counters for the forward and backwards branches mean that some loop optimizations aren't being done. And that might well mess up auto-vectorizaton, for example.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28541#issuecomment-3672458557

From drwhite at openjdk.org  Thu Dec 18 23:55:43 2025
From: drwhite at openjdk.org (Derek White)
Date: Thu, 18 Dec 2025 23:55:43 GMT
Subject: RFR: 8349452: Fix performance regression for Arrays.fill() with
 AVX512 [v10]
In-Reply-To: <N-7XCtb2GXLv10t2lo8jkzoMbI-f0LAJ5gWNMQC4E5c=.098a9b7a-16a8-49f8-a327-9d0490c66e45@github.com>
References: <vR7Pzk96gG0PlTn5P5U1qlqyCvISC0dCMxUXyWHfy2g=.e58b097d-790c-4725-8ac8-7e8f2c94ac50@github.com>
 <N-7XCtb2GXLv10t2lo8jkzoMbI-f0LAJ5gWNMQC4E5c=.098a9b7a-16a8-49f8-a327-9d0490c66e45@github.com>
Message-ID: <a2uV6sSvNnMnamD9dtQEB3aA35Ak0XDCM1HzAEFqFT8=.a298783c-b584-482a-9b86-8c5ae11bc780@github.com>

On Thu, 4 Dec 2025 02:44:51 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

>> The goal of this PR is to fix the performance regression in Arrays.fill() x86 stubs caused by masked AVX stores. The fix is to replace the masked AVX stores with store instructions without masks (i.e. unmasked stores). `fill32_masked()` and `fill64_masked()` stubs are replaced with `fill32_unmasked()` and `fill64_unmasked()` respectively.
>> 
>> To speedup unmasked stores, array fills for sizes < 64 bytes are broken down into sequences of 32B, 16B, 8B, 4B, 2B and 1B stores, depending on the size.
>> 
>> 
>> ### **Performance comparison for byte array fills in a loop for 1 million times**
>> 
>> 
>> UseAVX=3   ByteArray Size | +OptimizeFill    (Masked store   stub)     [secs] | -OptimizeFill   (No stub)   [secs] | --->This PR: +OptimizeFill   (Unmasked store   stub)   [secs]
>> -- | -- | -- | --
>> 1 | 0.46 | 0.14 | 0.189
>> 2 | 0.46 | 0.16 | 0.191
>> 3 | 0.46 | 0.176 | 0.199
>> 4 | 0.46 | 0.244 | 0.212
>> 5 | 0.46 | 0.29 | 0.364
>> 10 | 0.46 | 0.58 | 0.354
>> 15 | 0.46 | 0.42 | 0.325
>> 16 | 0.46 | 0.46 | 0.281
>> 17 | 0.21 | 0.5 | 0.365
>> 20 | 0.21 | 0.37 | 0.326
>> 25 | 0.21 | 0.59 | 0.343
>> 31 | 0.21 | 0.53 | 0.317
>> 32 | 0.21 | 0.58 | 0.249
>> 35 | 0.5 | 0.77 | 0.303
>> 40 | 0.5 | 0.61 | 0.312
>> 45 | 0.5 | 0.52 | 0.364
>> 48 | 0.5 | 0.66 | 0.283
>> 49 | 0.22 | 0.69 | 0.367
>> 50 | 0.22 | 0.78 | 0.344
>> 55 | 0.22 | 0.67 | 0.332
>> 60 | 0.22 | 0.67 | 0.312
>> 64 | 0.22 | 0.82 | 0.253
>> 70 | 0.51 | 1.1 | 0.394
>> 80 | 0.49 | 0.89 | 0.346
>> 90 | 0.225 | 0.68 | 0.385
>> 100 | 0.54 | 1.09 | 0.364
>> 110 | 0.6 | 0.98 | 0.416
>> 120 | 0.26 | 0.75 | 0.367
>> 128 | 0.266 | 1.1 | 0.342
>
> Srinivas Vamsi Parasa has updated the pull request 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:
> 
>  - Fix for failing tests; keep dest pointer unchanged
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into fill_array
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into fill_array
>  - fix missing array length updates for size=1
>  - revert to jccb in one place
>  - remove all masked stores altogether
>  - fastpath for size <= 4 bytes
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into fill_array
>  - undo jccb to jcc change as needed
>  - refactor code to use fill32_tail at the end of the stub
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/c977d827...f54dfd78

No correctness issues, but some cleanups suggested. Thanks!

src/hotspot/cpu/x86/macroAssembler_x86.cpp line 5800:

> 5798:                                    Register rtmp, Register rtmp2, XMMRegister xtmp) {
> 5799:   ShortBranchVerifier sbv(this);
> 5800:   assert_different_registers(to, value, count, rtmp);

Should add rtmp2 to assert_different_registers also

src/hotspot/cpu/x86/macroAssembler_x86.cpp line 9339:

> 9337:   Label L_exit;
> 9338:   Label L_fill_start;
> 9339:   Label L_fill_32_tail;

This is a bit more style/readability suggestion:
I think these labels can move to the block starting on line 9387

L_fill_start, L_fill_32_tail, L_fill_96_bytes, 
L_fill_128_bytes, 
L_fill_128_bytes_loop, 
L_fill_128_bytes_loop_header, 
L_fill_128_bytes_loop_pre_header

src/hotspot/cpu/x86/macroAssembler_x86.cpp line 9340:

> 9338:   Label L_fill_start;
> 9339:   Label L_fill_32_tail;
> 9340:   Label L_fill_64_tail;

Similar suggestion: L_fill_64_tail can move to block starting on line 9462

src/hotspot/cpu/x86/macroAssembler_x86.cpp line 9341:

> 9339:   Label L_fill_32_tail;
> 9340:   Label L_fill_64_tail;
> 9341:   Label L_fill_64_bytes;

L_fill_64_bytes is now unused

src/hotspot/cpu/x86/macroAssembler_x86.cpp line 9345:

> 9343:   Label L_fill_128_bytes;
> 9344:   Label L_fill_128_bytes_loop;
> 9345:   Label L_fill_128_loop_header;

L_fill_128_bytes_loop_header is unused (preexisting?)

-------------

Changes requested by drwhite (Committer).

PR Review: https://git.openjdk.org/jdk/pull/28442#pullrequestreview-3595698466
PR Review Comment: https://git.openjdk.org/jdk/pull/28442#discussion_r2633030525
PR Review Comment: https://git.openjdk.org/jdk/pull/28442#discussion_r2633047540
PR Review Comment: https://git.openjdk.org/jdk/pull/28442#discussion_r2633049315
PR Review Comment: https://git.openjdk.org/jdk/pull/28442#discussion_r2633037229
PR Review Comment: https://git.openjdk.org/jdk/pull/28442#discussion_r2633039322

From kdnilsen at openjdk.org  Thu Dec 18 23:57:28 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 18 Dec 2025 23:57:28 GMT
Subject: RFR: 8373203: Genshen: Non-strong reference leak in old gen [v4]
In-Reply-To: <ON4iOBMDZ_XJDitl2YyjjEw2L5UuSc5oFjr2iB6scHQ=.83468810-6a0b-4651-9b1b-ebfda9cf4483@github.com>
References: <JaJt39rlIHDKUiyQmDuh0uSyVslFVLKisMXo0r2gROk=.1056f4b4-441f-4ed2-9e7f-e81cbaca272c@github.com>
 <ON4iOBMDZ_XJDitl2YyjjEw2L5UuSc5oFjr2iB6scHQ=.83468810-6a0b-4651-9b1b-ebfda9cf4483@github.com>
Message-ID: <TCtoHqrNHlkf4Lu3X6oPedfJQd5dRZd66KuX_Pt-3dU=.fe406617-1686-4367-80f3-18ced3b7ed58@github.com>

On Wed, 17 Dec 2025 19:39:57 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> The generational mode for Shenandoah will collect _referents_ for the generation being collected. For example, if we have a young reference pointing to an old referent, that young reference will be processed after we finish marking the old generation. This presents a problem for discovery.
>>   
>> When the young mark _encounters_ a young reference with an old referent, it cannot _discover_ it because old marking hasn't finished. However, if it does not discover it, the old referent will be strongly marked. This, in turn, will prevent the old generation from clearing the referent (if it even reaches it again during old marking).
>>   
>> To solve this, we let young reference processing discover the old reference by having it use the old generation reference processor to do so. This means the old reference processor can have a discovered list that contains young weak references. If any of these young references reside in a region that is collected, old reference processing will crash when it processes such a reference. Therefore, we add a method `heal_discovered_lists` to traverse the discovered lists after young evacuation is complete. The method will replace any forwarded entries in the discovered list with the forwardee.
>> 
>> This PR also extends whitebox testing support for Shenandoah, giving us the ability to trigger young/old collections and interrogate some properties of heaps and regions.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix idiosyncratic white space in whitebox
>   
>   Co-authored-by: Stefan Karlsson <stefan.karlsson at oracle.com>

Thanks for chasing this problem down.  Very important fix.

-------------

Marked as reviewed by kdnilsen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/28810#pullrequestreview-3595738667

From kbarrett at openjdk.org  Fri Dec 19 00:47:21 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 19 Dec 2025 00:47:21 GMT
Subject: RFR: 8372754: Add wrapper for <cstdlib> [v3]
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: <GQxmxQxuTFvU2Rs0-dzI3HmeLTNNEMZaZXa24EJBr84=.0ba08c66-54d3-4698-926f-5b5b55df9e81@github.com>

> Please review this change that adds a HotSpot wrapper for <cstdlib>.  It also
> includes the forbidden function declarations for functions declared there,
> moving them from forbiddenFunctions.hpp and friends.
> 
> The AIX-specific workaround for its macro-based renaming of malloc/calloc is
> also moved to this wrapper, so there is a single location for it. Also cleaned
> it up a bit, based on further investigation of the problem.
> 
> Also changed uses of <cstdlib> and <stdlib.h> to include the wrapper instead.
> There are still a couple of includes of <stdlib.h> in the hotspot directory,
> because they can't use the hotspot wrapper: os/windows/include/jvm_md.h and
> share/adlc/adlc.hpp.  I looked at removing the one in windows jvm_md.h, but
> there are a lot of dependencies on that implicit include in non-HotSpot code.
> 
> While updating to use the wrapper, I also did a small amount of include
> cleanup here and there.  The changes around immediate_aarch64.hpp are perhaps
> a little less trivial than I should have made here.
> 
> Testing: mach5 tier1
> 
> This should probably be retested by aix port maintainer folks, although I
> don't think I made any relevant changes since you last tested it.
> 
> This change also resolves:

Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Merge branch 'master' into wrap-cstdlib
 - tschatzl review
 - Merge branch 'master' into wrap-cstdlib
 - add wrapper for <cstdlib>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28562/files
  - new: https://git.openjdk.org/jdk/pull/28562/files/f210f9ef..7855de87

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28562&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28562&range=01-02

  Stats: 12445 lines in 476 files changed: 8212 ins; 1866 del; 2367 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 Dec 19 00:47:24 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 19 Dec 2025 00:47:24 GMT
Subject: RFR: 8372754: Add wrapper for <cstdlib> [v2]
In-Reply-To: <mX5HpK_uECRN_mnmu4yu1H1GT_Yfp24JhxS_tkXeYCg=.00784e86-4701-43c3-b46c-df7a1df5a262@github.com>
References: <7QNN5i5DkBH7c9YXWh5U40JwTKmiBPJSAcLm-f1HE_8=.9b18027e-8274-46d1-ba2d-e70514c40fc3@github.com>
 <cphviQVoQ7e5Qsupc5SAHZk9fSW-CTU6l1M5bxHNSNo=.e03193a9-8674-48b1-9d74-210a93c0e381@github.com>
 <mX5HpK_uECRN_mnmu4yu1H1GT_Yfp24JhxS_tkXeYCg=.00784e86-4701-43c3-b46c-df7a1df5a262@github.com>
Message-ID: <W3Ja1hJth32ACDGxG8kD-Nl7XP11fOjebx6vOlkXZKA=.813272bc-4aea-4595-bab0-89a008f95263@github.com>

On Tue, 16 Dec 2025 10:03:54 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'master' into wrap-cstdlib
>>  - add wrapper for <cstdlib>
>
> src/hotspot/os/aix/libperfstat_aix.hpp line 36:
> 
>> 34: 
>> 35: #include "cppstdlib/cstdlib.hpp"
>> 36: #include <sys/types.h>
> 
> Maybe add a newline between the double-quoted and the angle-bracketed includes similar to other files.

done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28562#discussion_r2633157909

From dlong at openjdk.org  Fri Dec 19 01:40:54 2025
From: dlong at openjdk.org (Dean Long)
Date: Fri, 19 Dec 2025 01:40:54 GMT
Subject: RFR: 8373697: AArch64: Remove deoptimization stub code for
 nmethods with small stack frames
In-Reply-To: <LvdwgIjv2xY3pmOijohkA1h2c61vUSWtgEug7b4k8-w=.6f6e5cbd-a9f1-4154-8205-de52479fdd1f@github.com>
References: <LvdwgIjv2xY3pmOijohkA1h2c61vUSWtgEug7b4k8-w=.6f6e5cbd-a9f1-4154-8205-de52479fdd1f@github.com>
Message-ID: <t2xlDyS0sQAWOsksIxe7KZ8fXEUNcLyQxxX_CAcOza8=.6a469df2-65bc-4882-bf57-a7324ecb0776@github.com>

On Tue, 16 Dec 2025 23:15:12 GMT, Ruben <duke at openjdk.org> wrote:

> Removal of deoptimization stub codes improves density of compiled code.
> It is possible at least for methods with relatively small stack frames.

A side table for the original PC does sound promising.  Then we can have smaller compiled frames.

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.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28857#issuecomment-3673062594

From dholmes at openjdk.org  Fri Dec 19 01:55:29 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 19 Dec 2025 01:55:29 GMT
Subject: RFR: 8369515: Deadlock between JVMTI and JNI
 ReleasePrimitiveArrayCritical [v3]
In-Reply-To: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
References: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
Message-ID: <qlT_BgonQ3i1_YIAJ6cmvp7u-WBr9JEik-WAhfDDMjQ=.b011b5bc-108d-445e-ab95-92c4457465eb@github.com>

> As discussed in JBS the deadlock occurs when the call to `ReleasePrimitiveArrayCritical` performs the transition from native to VM, and in the process checks for special runtime exit conditions - which includes the `obj_deopt_suspend` request. The simple solution is to define a custom JNI ENTRY with custom `ThreadInVMfromNative` that elides the exit check.
> 
> The change is limited to `ReleasePrimitiveArrayCritical` and `ReleaseStringCritical`.
> 
> UPDATE: we are now employing a much simpler solution.
> 
> There is no regression test as this has only been seen in long running stress tests.
> 
> Testing:
>    -tiers 1-6

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Exapnd comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28779/files
  - new: https://git.openjdk.org/jdk/pull/28779/files/b96a9bc2..9bc8a3f8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28779&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28779&range=01-02

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28779.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28779/head:pull/28779

PR: https://git.openjdk.org/jdk/pull/28779

From dholmes at openjdk.org  Fri Dec 19 01:55:32 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 19 Dec 2025 01:55:32 GMT
Subject: RFR: 8369515: Deadlock between JVMTI and JNI
 ReleasePrimitiveArrayCritical [v2]
In-Reply-To: <03R4Nqk1-LPYuGLWCoS2ZXMrvbLKdN1JynWy3pcNG58=.d18c006f-a704-4d80-b836-ebd605281586@github.com>
References: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
 <DdndhI1g51Z9rEMIpU99IPI47NtmbYNYWHVEBrBEOSQ=.7137830c-4ce8-4133-b0bd-ebc9eafe671e@github.com>
 <03R4Nqk1-LPYuGLWCoS2ZXMrvbLKdN1JynWy3pcNG58=.d18c006f-a704-4d80-b836-ebd605281586@github.com>
Message-ID: <pcrDW-Y9FJPJy2FR9BgaT-QVtyEFgYCJ8t7V9WZpLfE=.a46dfdca-4c46-414f-aad5-eed929aeeb10@github.com>

On Thu, 18 Dec 2025 09:20:06 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> David Holmes 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:
>> 
>>  - Greatly simplifed fix to just defer object_deopt whilst in JNI critical region
>>  - Merge branch 'master' into 8369515-jni-critical
>>  - Revert "8369515"
>>    
>>    This reverts commit 3beb23ccbf5adb98d8c6ad404d40c603bbf499dc.
>>  - 8369515
>
> Fixing deadlock issues caused by suspend requests can easily become quite messy, but not this time. I think it's an elegant solution, with a good explaining source code comment. Thank you!

Thanks for the reviews @fbredber and @pchilano !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28779#issuecomment-3673102814

From dholmes at openjdk.org  Fri Dec 19 01:55:34 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 19 Dec 2025 01:55:34 GMT
Subject: RFR: 8369515: Deadlock between JVMTI and JNI
 ReleasePrimitiveArrayCritical [v2]
In-Reply-To: <RAEuicmS-hN6DvZheBoku1T2xxF4RBdMv9pR5HzXYb0=.ba0b1e4e-5a76-48f6-9f2d-101f129950b4@github.com>
References: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
 <DdndhI1g51Z9rEMIpU99IPI47NtmbYNYWHVEBrBEOSQ=.7137830c-4ce8-4133-b0bd-ebc9eafe671e@github.com>
 <RAEuicmS-hN6DvZheBoku1T2xxF4RBdMv9pR5HzXYb0=.ba0b1e4e-5a76-48f6-9f2d-101f129950b4@github.com>
Message-ID: <fcrk1s7T_5aT6o_bkal4CnU1dUODHD9aWYct5mtGdus=.c5d8daa8-3571-42aa-8e5c-48d17b299ee1@github.com>

On Thu, 18 Dec 2025 18:56:19 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> David Holmes 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:
>> 
>>  - Greatly simplifed fix to just defer object_deopt whilst in JNI critical region
>>  - Merge branch 'master' into 8369515-jni-critical
>>  - Revert "8369515"
>>    
>>    This reverts commit 3beb23ccbf5adb98d8c6ad404d40c603bbf499dc.
>>  - 8369515
>
> src/hotspot/share/runtime/javaThread.cpp line 1057:
> 
>> 1055:   // We mustn't block for object deopt if the thread is
>> 1056:   // currently executing in a JNI critical region, as that
>> 1057:   // can cause deadlock because the GCLocker is held.
> 
> I think the last part of the comment might be confusing because it's the deopt suspender that helds the lock waiting for this thread to exit the critical region [[1]](https://github.com/openjdk/jdk/blob/0b2712400b55d4a512db225d090c2f06f01f7f1f/src/hotspot/share/gc/shared/gcLocker.cpp#L108). Maybe "... cause deadlock because the suspender may allocate and block waiting for this thread to exit the critical region"?

I have reworded and expanded the last part. Thanks

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28779#discussion_r2633282213

From syan at openjdk.org  Fri Dec 19 02:25:02 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 19 Dec 2025 02:25:02 GMT
Subject: RFR: 8371948: TestStackOverflowDuringInit.java fails xss too small
 on linux-aarch64
In-Reply-To: <h0A4PYQoUqKt9X6TSCIcZFBPUnr4E1vln_6rsuvspzY=.982c0d22-704d-48a7-88f3-23bdfc7131b3@github.com>
References: <P6KhJ0rZttqTHVxuVi_POYRVmy2oGpaUj03Gnz3LXOQ=.9449af19-abc3-44ad-99e9-6e70ce008e3c@github.com>
 <h0A4PYQoUqKt9X6TSCIcZFBPUnr4E1vln_6rsuvspzY=.982c0d22-704d-48a7-88f3-23bdfc7131b3@github.com>
Message-ID: <zTKnNbVVKbF-tHM8M9NdKw99zIQSH00ezcS8XjFlO_s=.0e962950-08e8-41c1-8d7f-909340fc69ab@github.com>

On Tue, 18 Nov 2025 02:57:30 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Hi all,
>> 
>> On linux-aarch64, when page size is 64K, the minimal java thread stack size is 448K. So this PR increase the minimal java thread stack size in test/hotspot/jtreg/runtime/ClassInitErrors/TestStackOverflowDuringInit.java. Below is the calculation formula for the minimal java thread stack size:
>> 
>> 
>> page_size = 64K
>> _java_thread_min_stack_allowed = 72K
>> _stack_red_zone_size = align_up(StackRedPages * unit, page_size) = align_up(1*4K, 64K) = 64K
>> _stack_yellow_zone_size = align_up(StackYellowPages * unit, page_size) = align_up(2*4K, 64K) = 64K
>> _stack_reserved_zone_size = align_up(StackReservedPages * unit, page_size) = align_up(1*4K, 64K) = 64K
>> _stack_shadow_zone_size = align_up(StackShadowPages * unit, page_size) = align_up(25*4K, 64K) = 128K
>> _java_thread_min_stack_allowed = align_up(72K+64K+64K+64K+128K, 64K) = 448K
>> 
>> 
>> This PR add whitebox API getMinimumJavaStackSize() to the the allowd minimum java stack size, and get the allowed minimum java stack size in test/hotspot/jtreg/runtime/ClassInitErrors/TestStackOverflowDuringInit.java
>> 
>> Change has been verified locally both on linux-x64 and linux-aarch64.
>
> A more resilient change would be to add a WhiteBox API to obtain the minimum stack for the actual platform in use, and then exec the VM with that as an -Xss value. Is that something you can do?

Thanks for the suggestions and reviews @dholmes-ora @theRealAph

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28352#issuecomment-3673198106

From syan at openjdk.org  Fri Dec 19 02:25:03 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 19 Dec 2025 02:25:03 GMT
Subject: Integrated: 8371948: TestStackOverflowDuringInit.java fails xss too
 small on linux-aarch64
In-Reply-To: <P6KhJ0rZttqTHVxuVi_POYRVmy2oGpaUj03Gnz3LXOQ=.9449af19-abc3-44ad-99e9-6e70ce008e3c@github.com>
References: <P6KhJ0rZttqTHVxuVi_POYRVmy2oGpaUj03Gnz3LXOQ=.9449af19-abc3-44ad-99e9-6e70ce008e3c@github.com>
Message-ID: <5qV2klAAC9h1vPTEpVJqn4-ZMTduvMI9n5ADZ3zueGk=.c49394f0-f83d-42ef-820a-b5eec7c556e8@github.com>

On Mon, 17 Nov 2025 14:31:46 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> On linux-aarch64, when page size is 64K, the minimal java thread stack size is 448K. So this PR increase the minimal java thread stack size in test/hotspot/jtreg/runtime/ClassInitErrors/TestStackOverflowDuringInit.java. Below is the calculation formula for the minimal java thread stack size:
> 
> 
> page_size = 64K
> _java_thread_min_stack_allowed = 72K
> _stack_red_zone_size = align_up(StackRedPages * unit, page_size) = align_up(1*4K, 64K) = 64K
> _stack_yellow_zone_size = align_up(StackYellowPages * unit, page_size) = align_up(2*4K, 64K) = 64K
> _stack_reserved_zone_size = align_up(StackReservedPages * unit, page_size) = align_up(1*4K, 64K) = 64K
> _stack_shadow_zone_size = align_up(StackShadowPages * unit, page_size) = align_up(25*4K, 64K) = 128K
> _java_thread_min_stack_allowed = align_up(72K+64K+64K+64K+128K, 64K) = 448K
> 
> 
> This PR add whitebox API getMinimumJavaStackSize() to the the allowd minimum java stack size, and get the allowed minimum java stack size in test/hotspot/jtreg/runtime/ClassInitErrors/TestStackOverflowDuringInit.java
> 
> Change has been verified locally both on linux-x64 and linux-aarch64.

This pull request has now been integrated.

Changeset: 360777c3
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/360777c3ad8fe5bfeb2af15ce1b89e04d4397b9f
Stats:     64 lines in 5 files changed: 36 ins; 2 del; 26 mod

8371948: TestStackOverflowDuringInit.java fails xss too small on linux-aarch64

Reviewed-by: dholmes, aph

-------------

PR: https://git.openjdk.org/jdk/pull/28352

From syan at openjdk.org  Fri Dec 19 02:51:27 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 19 Dec 2025 02:51:27 GMT
Subject: [jdk26] RFR: 8371948: TestStackOverflowDuringInit.java fails xss too
 small on linux-aarch64
Message-ID: <9CDku0hh81R4pgOU5H4VKLKW2znAadrNuTuNqhN8JH4=.bce75bac-5ce3-44bc-9af2-9b21c6e0da8f@github.com>

Hi all,

This pull request contains a backport of commit [360777c3](https://github.com/openjdk/jdk/commit/360777c3ad8fe5bfeb2af15ce1b89e04d4397b9f) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by SendaoYan on 19 Dec 2025 and was reviewed by David Holmes and Andrew Haley.

This clean backport PR will fix the test bug which cause fails on some linux-aarch64 machines,

Thanks!

-------------

Commit messages:
 - Backport 360777c3ad8fe5bfeb2af15ce1b89e04d4397b9f

Changes: https://git.openjdk.org/jdk/pull/28915/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28915&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371948
  Stats: 64 lines in 5 files changed: 36 ins; 2 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/28915.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28915/head:pull/28915

PR: https://git.openjdk.org/jdk/pull/28915

From dlong at openjdk.org  Fri Dec 19 05:10:53 2025
From: dlong at openjdk.org (Dean Long)
Date: Fri, 19 Dec 2025 05:10:53 GMT
Subject: RFR: 8373343: C2: verify AddP base input only set for heap
 addresses [v2]
In-Reply-To: <T6ZxMdJ9pNnL8Ao63VPDxzkRhMKiSR6RfL6MuKM9-1Q=.8039caa8-5086-47eb-a0ef-2fca0093897a@github.com>
References: <fdm8TK_FBJheQ_Wkd_KobosU0uTioUuRZhIK38I3Q-g=.8ae8e498-9c14-4cae-8e68-4c39914a8195@github.com>
 <T6ZxMdJ9pNnL8Ao63VPDxzkRhMKiSR6RfL6MuKM9-1Q=.8039caa8-5086-47eb-a0ef-2fca0093897a@github.com>
Message-ID: <T0HruhoroFuLPc19XTJdfGoyjFghHVMbubJEm_mVBGI=.49d653c9-d76c-4c0b-81b4-b898c1015108@github.com>

On Wed, 17 Dec 2025 14:04:04 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> The base input of `AddP` is expected to only be set for heap accesses
>> but I noticed some inconsistencies so I added an assert in the `AddP`
>> constructor and fixed issues that it caught. AFAFICT, the
>> inconsistencies shouldn't create issues.
>
> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - review
>  - review
>  - merge
>  - more
>  - more
>  - more
>  - undo
>  - exps

Marked as reviewed by dlong (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28769#pullrequestreview-3596852846

From qamai at openjdk.org  Fri Dec 19 05:50:56 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 19 Dec 2025 05:50:56 GMT
Subject: RFR: 8373343: C2: verify AddP base input only set for heap
 addresses [v2]
In-Reply-To: <T6ZxMdJ9pNnL8Ao63VPDxzkRhMKiSR6RfL6MuKM9-1Q=.8039caa8-5086-47eb-a0ef-2fca0093897a@github.com>
References: <fdm8TK_FBJheQ_Wkd_KobosU0uTioUuRZhIK38I3Q-g=.8ae8e498-9c14-4cae-8e68-4c39914a8195@github.com>
 <T6ZxMdJ9pNnL8Ao63VPDxzkRhMKiSR6RfL6MuKM9-1Q=.8039caa8-5086-47eb-a0ef-2fca0093897a@github.com>
Message-ID: <vTditLeuxbhf1cKct7R9K10xAKuUzIPIkX0dViP1lMs=.f1f907c1-f9e5-44fd-9fce-15548d8e2801@github.com>

On Wed, 17 Dec 2025 14:04:04 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> The base input of `AddP` is expected to only be set for heap accesses
>> but I noticed some inconsistencies so I added an assert in the `AddP`
>> constructor and fixed issues that it caught. AFAFICT, the
>> inconsistencies shouldn't create issues.
>
> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - review
>  - review
>  - merge
>  - more
>  - more
>  - more
>  - undo
>  - exps

Marked as reviewed by qamai (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28769#pullrequestreview-3596937444

From dholmes at openjdk.org  Fri Dec 19 06:08:52 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 19 Dec 2025 06:08:52 GMT
Subject: [jdk26] RFR: 8371948: TestStackOverflowDuringInit.java fails xss
 too small on linux-aarch64
In-Reply-To: <9CDku0hh81R4pgOU5H4VKLKW2znAadrNuTuNqhN8JH4=.bce75bac-5ce3-44bc-9af2-9b21c6e0da8f@github.com>
References: <9CDku0hh81R4pgOU5H4VKLKW2znAadrNuTuNqhN8JH4=.bce75bac-5ce3-44bc-9af2-9b21c6e0da8f@github.com>
Message-ID: <9Zt2IfL4YnMiEJPGHSt1d1F_EQwy72ZzMWzMKsOpfK0=.b71d21a8-3229-4c3a-9fb4-18ec9ad2e374@github.com>

On Fri, 19 Dec 2025 02:44:05 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [360777c3](https://github.com/openjdk/jdk/commit/360777c3ad8fe5bfeb2af15ce1b89e04d4397b9f) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by SendaoYan on 19 Dec 2025 and was reviewed by David Holmes and Andrew Haley.
> 
> This clean backport PR will fix the test bug which cause fails on some linux-aarch64 machines,
> 
> Thanks!

Marked as reviewed by dholmes (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28915#pullrequestreview-3597021040

From jbhateja at openjdk.org  Fri Dec 19 06:29:57 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 19 Dec 2025 06:29:57 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v9]
In-Reply-To: <bvuVSZazvV1xkWXg36-aNiHcYGm7OtwESmohHSDy58w=.dae1caf9-c2b4-4527-b1fa-adf3c18dc366@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <W3wLPA_gsj3C0nXvT2xQqIh5DlFJW0VszDQtmhkieJ0=.06dc05cd-c081-44f4-8fe5-e81c261dea8a@github.com>
 <xICotngWnv6o6yApK6uBKGMXro-V-x96TTZVZo3Jxx4=.f96530fe-491e-4caa-8d1a-9fff3018533f@github.com>
 <n7Xa6kvC3x_MgO9XMZjfJUdm0D30wsB-vYI-Ce3J3O4=.8c5ec613-3c86-49ba-87ab-d29d6be87b6f@github.com>
 <m3iiFd9268Wpp6ortuHKCEA7AwecpV22KL3UEi2E0XA=.a3920fc3-4a3e-47c2-a602-e72872560a40@github.com>
 <U8s19UjaUOh0ipUZeKkSAprwjOsFHHmNefi5AKcohSo=.0ba2cf00-29c4-41a6-b91c-65ff22e0ff92@github.com>
 <8hStIcvp252Ik7raxZL5BvFKKkXTflorjyOD9Cyakvc=.c5d1b302-5c49-46b1-91ba-2feda2e6a746@github.com>
 <bvuVSZazvV1xkWXg36-aNiHcYGm7OtwESmohHSDy58w=.dae1caf9-c2b4-4527-b1fa-adf3c18dc366@github.com>
Message-ID: <Xchw48xIyPtUaVaTzcWYPlqSJX2IiFiXls-PC_CSO3o=.c4e3748b-e826-4587-b26f-9011e15bbb94@github.com>

On Thu, 13 Nov 2025 19:47:52 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>>> The basic type codes are declared and shared across Java and HotSpot - it's used in `LaneType`. Can we pass a single argument that is the basic type instead of two arguments. HotSpot should know from the basic type what the carrier class and also what the operation type without it being explicitly told, since presumably it knew the inverse - the basic type from the element class.
>> 
>> Hi @PaulSandoz, T_HALFFLOAT used in LaneType is mainly used for differentiation of various cache keys used by conversion operation lookups. In principle, we can extend VM to acknowledge this new custom basic type on the lines of T_METADATA / T_ADDRESS; its scope for now will be restricted to VectorSupport. We can gradually expose this to C2 type, such that TypeVect for all Float16 VectorIR uses T_HALFFLOAT as its basic type; currently, we use T_SHORT as the lane type. Let me know if this looks reasonable
>
>> > The basic type codes are declared and shared across Java and HotSpot - it's used in `LaneType`. Can we pass a single argument that is the basic type instead of two arguments. HotSpot should know from the basic type what the carrier class and also what the operation type without it being explicitly told, since presumably it knew the inverse - the basic type from the element class.
>> 
>> Hi @PaulSandoz, T_HALFFLOAT used in LaneType is mainly used for differentiation of various cache keys used by conversion operation lookups. In principle, we can extend VM to acknowledge this new custom basic type on the lines of T_METADATA / T_ADDRESS; its scope for now will be restricted to VectorSupport. We can gradually expose this to C2 type, such that TypeVect for all Float16 VectorIR uses T_HALFFLOAT as its basic type; currently, we use T_SHORT as the lane type. Let me know if this looks reasonable
> 
> I am proposing something simpler, really as a temporary step until `Float16` becomes part of the `java.base` module. IIUC from the basic type we can reliably determine what the two arguments we currently passing are e.g.,  T_HALFFLOAT = { short.class, VECTOR_TYPE_FP16 }. So we don't need to pass two arguments, we can just pass one, the intrinsic can lookup the class and operation type kind.

Hi @PaulSandoz , your comments have been addressed. Please let us know if there are other comments.
Hi @eme64 , Kindly share your comments.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3673727967

From syan at openjdk.org  Fri Dec 19 06:43:36 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 19 Dec 2025 06:43:36 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v3]
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: <DpKNuQjx7_01t6mYuPRr8kNIDgqY2AW8pmc0PPJX4w8=.6f6ee917-33cd-409b-91cb-22c4161a3878@github.com>

> 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:
> 
> - [ ] All jtreg tests by fastdebug build

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  Update test/hotspot/jtreg/vmTestbase/gc/gctests/LargeObjects 5 tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28891/files
  - new: https://git.openjdk.org/jdk/pull/28891/files/3028bbea..7e67804f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=01-02

  Stats: 18 lines in 5 files changed: 16 ins; 0 del; 2 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 epeter at openjdk.org  Fri Dec 19 07:03:58 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 19 Dec 2025 07:03:58 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v9]
In-Reply-To: <Xchw48xIyPtUaVaTzcWYPlqSJX2IiFiXls-PC_CSO3o=.c4e3748b-e826-4587-b26f-9011e15bbb94@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <W3wLPA_gsj3C0nXvT2xQqIh5DlFJW0VszDQtmhkieJ0=.06dc05cd-c081-44f4-8fe5-e81c261dea8a@github.com>
 <xICotngWnv6o6yApK6uBKGMXro-V-x96TTZVZo3Jxx4=.f96530fe-491e-4caa-8d1a-9fff3018533f@github.com>
 <n7Xa6kvC3x_MgO9XMZjfJUdm0D30wsB-vYI-Ce3J3O4=.8c5ec613-3c86-49ba-87ab-d29d6be87b6f@github.com>
 <m3iiFd9268Wpp6ortuHKCEA7AwecpV22KL3UEi2E0XA=.a3920fc3-4a3e-47c2-a602-e72872560a40@github.com>
 <U8s19UjaUOh0ipUZeKkSAprwjOsFHHmNefi5AKcohSo=.0ba2cf00-29c4-41a6-b91c-65ff22e0ff92@github.com>
 <8hStIcvp252Ik7raxZL5BvFKKkXTflorjyOD9Cyakvc=.c5d1b302-5c49-46b1-91ba-2feda2e6a746@github.com>
 <bvuVSZazvV1xkWXg36-aNiHcYGm7OtwESmohHSDy58w=.dae1caf9-c2b4-4527-b1fa-adf3c18dc366@github.com>
 <Xchw48xIyPtUaVaTzcWYPlqSJX2IiFiXls-PC_CSO3o=.c4e3748b-e826-4587-b26f-9011e15bbb94@github.com>
Message-ID: <1ElN5XvEXAYGINpCIB2smhDrzekGyiXmG6o8-jnxDxk=.83a69a64-2894-40af-a2ee-9c35448c88b2@github.com>

On Fri, 19 Dec 2025 06:26:47 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>>> > The basic type codes are declared and shared across Java and HotSpot - it's used in `LaneType`. Can we pass a single argument that is the basic type instead of two arguments. HotSpot should know from the basic type what the carrier class and also what the operation type without it being explicitly told, since presumably it knew the inverse - the basic type from the element class.
>>> 
>>> Hi @PaulSandoz, T_HALFFLOAT used in LaneType is mainly used for differentiation of various cache keys used by conversion operation lookups. In principle, we can extend VM to acknowledge this new custom basic type on the lines of T_METADATA / T_ADDRESS; its scope for now will be restricted to VectorSupport. We can gradually expose this to C2 type, such that TypeVect for all Float16 VectorIR uses T_HALFFLOAT as its basic type; currently, we use T_SHORT as the lane type. Let me know if this looks reasonable
>> 
>> I am proposing something simpler, really as a temporary step until `Float16` becomes part of the `java.base` module. IIUC from the basic type we can reliably determine what the two arguments we currently passing are e.g.,  T_HALFFLOAT = { short.class, VECTOR_TYPE_FP16 }. So we don't need to pass two arguments, we can just pass one, the intrinsic can lookup the class and operation type kind.
>
> 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 :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3673842243

From syan at openjdk.org  Fri Dec 19 08:36:46 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 19 Dec 2025 08:36:46 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v4]
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: <EdAQiOYb1WPlFPvUMaQa9BySg-f7pkphVjy-olbsBV8=.32277461-69e2-460c-9aa6-a542a8ff1ddc@github.com>

> 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:
> 
> - [ ] All jtreg tests by fastdebug build

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  Fix other tests except CompiledMethodUnload/compmethunload001/TestDescription.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28891/files
  - new: https://git.openjdk.org/jdk/pull/28891/files/7e67804f..47c508a5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=02-03

  Stats: 178 lines in 31 files changed: 92 ins; 29 del; 57 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 aboldtch at openjdk.org  Fri Dec 19 08:42:50 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 19 Dec 2025 08:42:50 GMT
Subject: RFR: 8373801: Adopt arraycopy OopCopyResult from the lworld branch
 [v2]
In-Reply-To: <xL27bPDF6Wl05dCXSghM4SdhK_iuMvlZW4J4LsvAJ9M=.6d00cb20-6661-470f-aa85-2846d56fede8@github.com>
References: <vuovhgARk6krDotYQS-asHzFkm93v8hPWx4zLwT1xC0=.fd37e81f-8714-40b7-a099-58fc653cd2e4@github.com>
 <xL27bPDF6Wl05dCXSghM4SdhK_iuMvlZW4J4LsvAJ9M=.6d00cb20-6661-470f-aa85-2846d56fede8@github.com>
Message-ID: <SlkWGGM7PeTsGvoBp-GcUidKeirYaA95SRik_MtoW14=.7a45bf2a-05e7-4cba-babd-9b5067323611@github.com>

On Tue, 16 Dec 2025 15:04:44 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> In the Valhalla project there's code to restrict nulls in object arrays. In the GC arraycopy barrier we there have to both do null checks in addition to the already existing cast checks. If one of these two failed the code needs to propagate this up through the callers to the code that asked to do the checks. There it will throw the suitable exception. Previously, it was enough to say success or failed, and a boolean was enough. Now we need three states. So the bool was replaced with an OopCopyResult enum.
>> 
>> See: https://github.com/openjdk/valhalla/pull/1792
>> 
>> I propose that we bring this over to the mainline to lower the diff between lworld and the openjdk/jdk.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove throw NPE function

lgtm.

-------------

Marked as reviewed by aboldtch (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28850#pullrequestreview-3597566345

From syan at openjdk.org  Fri Dec 19 08:45:37 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 19 Dec 2025 08:45:37 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v5]
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: <o5RfVmRlL4rk-uklwwVWo-aZr5-pi1JnSm9okRCr3V4=.b4ae7097-db7f-48c6-a704-a0d180abe2c0@github.com>

> 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:
> 
> - [ ] All jtreg tests by fastdebug build

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  Increase max iteration for nsk/jvmti/CompiledMethodUnload/compmethunload001/TestDescription.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28891/files
  - new: https://git.openjdk.org/jdk/pull/28891/files/47c508a5..c752a052

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 jsikstro at openjdk.org  Fri Dec 19 09:07:46 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Fri, 19 Dec 2025 09:07:46 GMT
Subject: RFR: 8373801: Adopt arraycopy OopCopyResult from the lworld branch
 [v2]
In-Reply-To: <xL27bPDF6Wl05dCXSghM4SdhK_iuMvlZW4J4LsvAJ9M=.6d00cb20-6661-470f-aa85-2846d56fede8@github.com>
References: <vuovhgARk6krDotYQS-asHzFkm93v8hPWx4zLwT1xC0=.fd37e81f-8714-40b7-a099-58fc653cd2e4@github.com>
 <xL27bPDF6Wl05dCXSghM4SdhK_iuMvlZW4J4LsvAJ9M=.6d00cb20-6661-470f-aa85-2846d56fede8@github.com>
Message-ID: <7RIWg55D2iB93_2D8gGiB5XRwuIjjLH0Pi07F5r4j80=.4e83979d-466e-4095-9268-a761a7a14d4f@github.com>

On Tue, 16 Dec 2025 15:04:44 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> In the Valhalla project there's code to restrict nulls in object arrays. In the GC arraycopy barrier we there have to both do null checks in addition to the already existing cast checks. If one of these two failed the code needs to propagate this up through the callers to the code that asked to do the checks. There it will throw the suitable exception. Previously, it was enough to say success or failed, and a boolean was enough. Now we need three states. So the bool was replaced with an OopCopyResult enum.
>> 
>> See: https://github.com/openjdk/valhalla/pull/1792
>> 
>> I propose that we bring this over to the mainline to lower the diff between lworld and the openjdk/jdk.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove throw NPE function

Looks good.

-------------

Marked as reviewed by jsikstro (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28850#pullrequestreview-3597654894

From stefank at openjdk.org  Fri Dec 19 09:47:10 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 19 Dec 2025 09:47:10 GMT
Subject: RFR: 8373801: Adopt arraycopy OopCopyResult from the lworld branch
 [v3]
In-Reply-To: <vuovhgARk6krDotYQS-asHzFkm93v8hPWx4zLwT1xC0=.fd37e81f-8714-40b7-a099-58fc653cd2e4@github.com>
References: <vuovhgARk6krDotYQS-asHzFkm93v8hPWx4zLwT1xC0=.fd37e81f-8714-40b7-a099-58fc653cd2e4@github.com>
Message-ID: <HJNtQB8qFKySvXL403KGU4krZlkiyYlikVbZqQghvfw=.862bcc34-b14b-4e7a-becf-3c0288358773@github.com>

> In the Valhalla project there's code to restrict nulls in object arrays. In the GC arraycopy barrier we there have to both do null checks in addition to the already existing cast checks. If one of these two failed the code needs to propagate this up through the callers to the code that asked to do the checks. There it will throw the suitable exception. Previously, it was enough to say success or failed, and a boolean was enough. Now we need three states. So the bool was replaced with an OopCopyResult enum.
> 
> See: https://github.com/openjdk/valhalla/pull/1792
> 
> I propose that we bring this over to the mainline to lower the diff between lworld and the openjdk/jdk.

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Review comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28850/files
  - new: https://git.openjdk.org/jdk/pull/28850/files/25c24e3d..5825d92a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28850&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28850&range=01-02

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28850.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28850/head:pull/28850

PR: https://git.openjdk.org/jdk/pull/28850

From jsikstro at openjdk.org  Fri Dec 19 09:47:11 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Fri, 19 Dec 2025 09:47:11 GMT
Subject: RFR: 8373801: Adopt arraycopy OopCopyResult from the lworld branch
 [v3]
In-Reply-To: <HJNtQB8qFKySvXL403KGU4krZlkiyYlikVbZqQghvfw=.862bcc34-b14b-4e7a-becf-3c0288358773@github.com>
References: <vuovhgARk6krDotYQS-asHzFkm93v8hPWx4zLwT1xC0=.fd37e81f-8714-40b7-a099-58fc653cd2e4@github.com>
 <HJNtQB8qFKySvXL403KGU4krZlkiyYlikVbZqQghvfw=.862bcc34-b14b-4e7a-becf-3c0288358773@github.com>
Message-ID: <Heg9M6q44oNdojFr4rnu6HFaHAeuYasd3dpq2FKGukI=.0d915cb9-9dc9-4eb0-ace2-e91d75d1ae91@github.com>

On Fri, 19 Dec 2025 09:43:55 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> In the Valhalla project there's code to restrict nulls in object arrays. In the GC arraycopy barrier we there have to both do null checks in addition to the already existing cast checks. If one of these two failed the code needs to propagate this up through the callers to the code that asked to do the checks. There it will throw the suitable exception. Previously, it was enough to say success or failed, and a boolean was enough. Now we need three states. So the bool was replaced with an OopCopyResult enum.
>> 
>> See: https://github.com/openjdk/valhalla/pull/1792
>> 
>> I propose that we bring this over to the mainline to lower the diff between lworld and the openjdk/jdk.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment

Marked as reviewed by jsikstro (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28850#pullrequestreview-3597794124

From rrich at openjdk.org  Fri Dec 19 09:57:40 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Fri, 19 Dec 2025 09:57:40 GMT
Subject: RFR: 8369515: Deadlock between JVMTI and JNI
 ReleasePrimitiveArrayCritical [v3]
In-Reply-To: <qlT_BgonQ3i1_YIAJ6cmvp7u-WBr9JEik-WAhfDDMjQ=.b011b5bc-108d-445e-ab95-92c4457465eb@github.com>
References: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
 <qlT_BgonQ3i1_YIAJ6cmvp7u-WBr9JEik-WAhfDDMjQ=.b011b5bc-108d-445e-ab95-92c4457465eb@github.com>
Message-ID: <Hj-Ea8UpwQwUynp687GzvinD-tq3D5GAtiF5HeF51mc=.927737a3-bf4f-4685-ba66-c8557d25a9e6@github.com>

On Fri, 19 Dec 2025 01:55:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> As discussed in JBS the deadlock occurs when the call to `ReleasePrimitiveArrayCritical` performs the transition from native to VM, and in the process checks for special runtime exit conditions - which includes the `obj_deopt_suspend` request. The simple solution is to define a custom JNI ENTRY with custom `ThreadInVMfromNative` that elides the exit check.
>> 
>> The change is limited to `ReleasePrimitiveArrayCritical` and `ReleaseStringCritical`.
>> 
>> UPDATE: we are now employing a much simpler solution.
>> 
>> There is no regression test as this has only been seen in long running stress tests.
>> 
>> Testing:
>>    -tiers 1-6
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Exapnd comment

I wonder why there are no GHA tests?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28779#issuecomment-3674358347

From bmaillard at openjdk.org  Fri Dec 19 10:24:30 2025
From: bmaillard at openjdk.org (=?UTF-8?B?QmVub8OudA==?= Maillard)
Date: Fri, 19 Dec 2025 10:24:30 GMT
Subject: RFR: 8370519: C2: Hit MemLimit when running with
 +VerifyLoopOptimizations [v6]
In-Reply-To: <ivWBI33pO0sKOtifG2aGTozX0ybXkxSazNW-T5rpJyU=.a77a85c6-3540-4ce8-8b82-db7bae444615@github.com>
References: <W7EnT28-84mtwppISdr_ydCV9HSaXk72y7fyd29z4wQ=.7331c81d-c36f-4a1c-b949-e7045f524d07@github.com>
 <ivWBI33pO0sKOtifG2aGTozX0ybXkxSazNW-T5rpJyU=.a77a85c6-3540-4ce8-8b82-db7bae444615@github.com>
Message-ID: <qEoc6t9TVHMFRNCkPaxsdTC6LJ2kkzUctSzYJMA4j0g=.6fb77327-f3e4-46cd-9e12-c3384940c44b@github.com>

On Thu, 11 Dec 2025 15:42:42 GMT, Roland Westrelin <roland at openjdk.org> 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 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);
    }
}

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28581#issuecomment-3674476543

From dlong at openjdk.org  Fri Dec 19 10:36:58 2025
From: dlong at openjdk.org (Dean Long)
Date: Fri, 19 Dec 2025 10:36:58 GMT
Subject: RFR: 8373343: C2: verify AddP base input only set for heap
 addresses [v2]
In-Reply-To: <T6ZxMdJ9pNnL8Ao63VPDxzkRhMKiSR6RfL6MuKM9-1Q=.8039caa8-5086-47eb-a0ef-2fca0093897a@github.com>
References: <fdm8TK_FBJheQ_Wkd_KobosU0uTioUuRZhIK38I3Q-g=.8ae8e498-9c14-4cae-8e68-4c39914a8195@github.com>
 <T6ZxMdJ9pNnL8Ao63VPDxzkRhMKiSR6RfL6MuKM9-1Q=.8039caa8-5086-47eb-a0ef-2fca0093897a@github.com>
Message-ID: <qtbcjSvwrzlPMlILAAUEb0kdpCRATggtrijfOBbur3M=.e75675b0-98ac-4a32-9093-79dce2590f78@github.com>

On Wed, 17 Dec 2025 14:04:04 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> The base input of `AddP` is expected to only be set for heap accesses
>> but I noticed some inconsistencies so I added an assert in the `AddP`
>> constructor and fixed issues that it caught. AFAFICT, the
>> inconsistencies shouldn't create issues.
>
> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - review
>  - review
>  - merge
>  - more
>  - more
>  - more
>  - undo
>  - exps

I ran testing and got one mysterious timeout in
java/net/httpclient/DurationOverflowTest.java#withPropertyConfig
Normally this test runs in seconds, but it timed out in 9 minutes.  It could be unrelated to your changes or even a test bug, but I couldn't find any previous timeout failures for this test.
Most of your changes look low-risk.  The change I'm most concerned about is in LoadKlassNode::Identity, when it returns the Address edge instead of Base.

-------------

PR Review: https://git.openjdk.org/jdk/pull/28769#pullrequestreview-3598064741

From dlong at openjdk.org  Fri Dec 19 10:53:53 2025
From: dlong at openjdk.org (Dean Long)
Date: Fri, 19 Dec 2025 10:53:53 GMT
Subject: RFR: 8373343: C2: verify AddP base input only set for heap
 addresses [v2]
In-Reply-To: <T6ZxMdJ9pNnL8Ao63VPDxzkRhMKiSR6RfL6MuKM9-1Q=.8039caa8-5086-47eb-a0ef-2fca0093897a@github.com>
References: <fdm8TK_FBJheQ_Wkd_KobosU0uTioUuRZhIK38I3Q-g=.8ae8e498-9c14-4cae-8e68-4c39914a8195@github.com>
 <T6ZxMdJ9pNnL8Ao63VPDxzkRhMKiSR6RfL6MuKM9-1Q=.8039caa8-5086-47eb-a0ef-2fca0093897a@github.com>
Message-ID: <CAOFwoyk1kNXlqQNe8lXQZBEGL1MX412PTxxpIL6FDI=.dc3e9ec4-f7bd-4ce6-865b-f57911b7465d@github.com>

On Wed, 17 Dec 2025 14:04:04 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> The base input of `AddP` is expected to only be set for heap accesses
>> but I noticed some inconsistencies so I added an assert in the `AddP`
>> constructor and fixed issues that it caught. AFAFICT, the
>> inconsistencies shouldn't create issues.
>
> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - review
>  - review
>  - merge
>  - more
>  - more
>  - more
>  - undo
>  - exps

I'll try re-running testing to see if it fails again.

-------------

Changes requested by dlong (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28769#pullrequestreview-3598128322

From jnorlinder at openjdk.org  Fri Dec 19 10:55:14 2025
From: jnorlinder at openjdk.org (Jonas Norlinder)
Date: Fri, 19 Dec 2025 10:55:14 GMT
Subject: RFR: 8361716 : GCTraceCPUTime may report incorrect times during
 high load from JNI code [v4]
In-Reply-To: <6VAibdPXZ1bxQz656YRir_AuY0LNIATMvtyFdhen5rI=.ef106886-e47e-4357-85fd-e3eb789d1ba9@github.com>
References: <0XuPtyHEMMylip-V-HW7xFfZ6iR9EK1o8zTr5Xv4BNY=.112e82d2-f84a-41ec-8291-d668b52b142c@github.com>
 <69byqtWZYuAf5gRJ5gfVlearb93ETPJQlE-vQVzVa-k=.67664377-db19-4f60-83d7-df7ed09fea00@github.com>
 <6VAibdPXZ1bxQz656YRir_AuY0LNIATMvtyFdhen5rI=.ef106886-e47e-4357-85fd-e3eb789d1ba9@github.com>
Message-ID: <ORWizaon5YsKyjbWJu8qvXXmmP2ql62iwFU6-gMaL_c=.43bbbda7-835e-4a06-af22-118fd2488fcb@github.com>

On Wed, 17 Dec 2025 07:53:28 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use portable type
>
> A couple of more comments.

Me and @kstefanj had a discussion about pros and cons of using getrusage. Its unclear for both of us if we should introduce a major overhaul of the threading infrastructure to support as accurate sampling of system CPU time as possible on Linux with this patch (getrusage) or if we can accept a solution that may be less accurate in a scenario with high-frequency sampling.

We decided continue discussing what path to take after Christmas and new year celebrations. 

Happy holidays everyone! ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28824#issuecomment-3674586678

From stefank at openjdk.org  Fri Dec 19 10:55:51 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 19 Dec 2025 10:55:51 GMT
Subject: RFR: 8373801: Adopt arraycopy OopCopyResult from the lworld branch
 [v3]
In-Reply-To: <HJNtQB8qFKySvXL403KGU4krZlkiyYlikVbZqQghvfw=.862bcc34-b14b-4e7a-becf-3c0288358773@github.com>
References: <vuovhgARk6krDotYQS-asHzFkm93v8hPWx4zLwT1xC0=.fd37e81f-8714-40b7-a099-58fc653cd2e4@github.com>
 <HJNtQB8qFKySvXL403KGU4krZlkiyYlikVbZqQghvfw=.862bcc34-b14b-4e7a-becf-3c0288358773@github.com>
Message-ID: <krtnuv0bA6ooM0_OFRbY0H62RECskme2C7LdI7enSEE=.fcef1b1d-1e4d-4571-8ad6-c38d0c73c809@github.com>

On Fri, 19 Dec 2025 09:47:10 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> In the Valhalla project there's code to restrict nulls in object arrays. In the GC arraycopy barrier we there have to both do null checks in addition to the already existing cast checks. If one of these two failed the code needs to propagate this up through the callers to the code that asked to do the checks. There it will throw the suitable exception. Previously, it was enough to say success or failed, and a boolean was enough. Now we need three states. So the bool was replaced with an OopCopyResult enum.
>> 
>> See: https://github.com/openjdk/valhalla/pull/1792
>> 
>> I propose that we bring this over to the mainline to lower the diff between lworld and the openjdk/jdk.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28850#issuecomment-3674585869

From stefank at openjdk.org  Fri Dec 19 10:55:52 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 19 Dec 2025 10:55:52 GMT
Subject: Integrated: 8373801: Adopt arraycopy OopCopyResult from the lworld
 branch
In-Reply-To: <vuovhgARk6krDotYQS-asHzFkm93v8hPWx4zLwT1xC0=.fd37e81f-8714-40b7-a099-58fc653cd2e4@github.com>
References: <vuovhgARk6krDotYQS-asHzFkm93v8hPWx4zLwT1xC0=.fd37e81f-8714-40b7-a099-58fc653cd2e4@github.com>
Message-ID: <f7Ta8G5Zm9jDpBP5jwK39kYG8wyYpp4FJ_kDVDxO_Y8=.302e0aac-4eb9-43d4-8872-e04b3784d71e@github.com>

On Tue, 16 Dec 2025 14:47:15 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> In the Valhalla project there's code to restrict nulls in object arrays. In the GC arraycopy barrier we there have to both do null checks in addition to the already existing cast checks. If one of these two failed the code needs to propagate this up through the callers to the code that asked to do the checks. There it will throw the suitable exception. Previously, it was enough to say success or failed, and a boolean was enough. Now we need three states. So the bool was replaced with an OopCopyResult enum.
> 
> See: https://github.com/openjdk/valhalla/pull/1792
> 
> I propose that we bring this over to the mainline to lower the diff between lworld and the openjdk/jdk.

This pull request has now been integrated.

Changeset: 53e77d21
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/53e77d21c2308daad7d4aecf05da56609ed0291c
Stats:     192 lines in 12 files changed: 63 ins; 13 del; 116 mod

8373801: Adopt arraycopy OopCopyResult from the lworld branch

Reviewed-by: jsikstro, tschatzl, aboldtch

-------------

PR: https://git.openjdk.org/jdk/pull/28850

From cnorrbin at openjdk.org  Fri Dec 19 11:15:07 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Fri, 19 Dec 2025 11:15:07 GMT
Subject: RFR: 8373638: RBTree public interface does not check all input
 parameters for validity
Message-ID: <SOiJJksA_-pAmvj8O-QYI6vbA19kXlvswvChFxqAwl4=.535530cd-6dc8-4d14-a1ae-3ecbe74a927d@github.com>

Hi everyone,

The public interface for the `RBTree` assumes most input is valid, and does not check for null pointers. This could lead to potential null pointer dereferences. We should instead assert to give clearer errors in debug builds and to avoid trying to dereference these null pointers.

Testing:
- Oracle tiers 1-3

-------------

Commit messages:
 - nullptr asserts

Changes: https://git.openjdk.org/jdk/pull/28922/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28922&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373638
  Stats: 7 lines in 2 files changed: 7 ins; 0 del; 0 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 duke at openjdk.org  Fri Dec 19 12:15:42 2025
From: duke at openjdk.org (duke)
Date: Fri, 19 Dec 2025 12:15:42 GMT
Subject: Withdrawn: 8365306: Provide OS Process Size and Libc statistic metrics
 to JFR
In-Reply-To: <r4zqfECC3D8jZuWpPIDcE6PRmCkiKTQqXmpaQX-lG6k=.d57bc06c-92e8-4a01-827c-0013fbb9bed0@github.com>
References: <r4zqfECC3D8jZuWpPIDcE6PRmCkiKTQqXmpaQX-lG6k=.d57bc06c-92e8-4a01-827c-0013fbb9bed0@github.com>
Message-ID: <0qN4sAF2Ov5kJnH-f5HiWvk93t29ycVow454Rw9lsAs=.f548a8b3-387a-4f7b-9eb5-41f259a5e2f7@github.com>

On Wed, 13 Aug 2025 09:42:57 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> This provides the following new metrics:
> - `ProcessSize` event (new, periodic) 
>   - vsize (for analyzing address-space fragmentation issues)
>   - RSS including subtypes (subtypes are useful for excluding atypical issues, e.g. kernel problems that cause large file buffer bloat)
>   - peak RSS 
>   - process swap (if we swap we cannot trust the RSS values, plus it indicates bad sizing)
>   - pte size (to quickly see if we run with a super-large working set but an unsuitably small page size)
> - `LibcStatistics` (new, periodic)
>   - outstanding malloc size (important counterpoint to whatever NMT tries to tell me, which alone is often misleading)
>   - retained malloc size (super-important for the same reason)
>   - number of libc trims the hotspot executed (needed to gauge the usefulness of the retain counter, and to see if a customer employs native heap auto trimming (`-XX:TrimNativeHeapInterval`)
> - `NativeHeapTrim` (new, event-driven) (for both manual and automatic trims)
>    - RSS before and RSS after
>    - RSS recovered by this trim
>    - whether it was an automatic or manual trim
>    - duration
> - `JavaThreadStatistic`
>   - os thread counter (new field) (useful to understand the behavior of third-party code in our process if threads are created that bypass the JVM. E.g. some custom launchers do that.)
>   - nonJava thread counter (new field) (needed to interprete the os thread counter)
> 
> Notes:
> - we already have `ResidentSetSize` event, and the new `ProcessSize` event is a superset of that. I don't know how these cases are handled. I'd prefer to throw the old event out, but JMC has a hard-coded chart for RSS, so I kept it in unless someone tells me to remove it.
> 
> - Obviously, the libc events are very platform-specific. Still, I argue that these metrics are highly useful. We want people to use JFR and JMC; people include developers that are dealing with performance problems that require platform-specific knowledge to understand. See my comment in the JBS issue.
> 
> I provided implementations, as far as possible, to Linux, MacOS and Windows.
> 
> Testing:
> - ran the new tests manually and as part of GHAs

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/26756

From dholmes at openjdk.org  Fri Dec 19 12:43:13 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 19 Dec 2025 12:43:13 GMT
Subject: RFR: 8369515: Deadlock between JVMTI and JNI
 ReleasePrimitiveArrayCritical [v3]
In-Reply-To: <Hj-Ea8UpwQwUynp687GzvinD-tq3D5GAtiF5HeF51mc=.927737a3-bf4f-4685-ba66-c8557d25a9e6@github.com>
References: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
 <qlT_BgonQ3i1_YIAJ6cmvp7u-WBr9JEik-WAhfDDMjQ=.b011b5bc-108d-445e-ab95-92c4457465eb@github.com>
 <Hj-Ea8UpwQwUynp687GzvinD-tq3D5GAtiF5HeF51mc=.927737a3-bf4f-4685-ba66-c8557d25a9e6@github.com>
Message-ID: <6vFGKEFch604SQW5BCHD9DhoUeYGKKVBjvN8Q9ByPQ0=.605967f2-e2ed-497c-907e-55b85be2d3cb@github.com>

On Fri, 19 Dec 2025 09:54:42 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> I wonder why there are no GHA tests?

I don't run GHA by default.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28779#issuecomment-3674939902

From roland at openjdk.org  Fri Dec 19 13:15:38 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Fri, 19 Dec 2025 13:15:38 GMT
Subject: RFR: 8373343: C2: verify AddP base input only set for heap
 addresses [v3]
In-Reply-To: <fdm8TK_FBJheQ_Wkd_KobosU0uTioUuRZhIK38I3Q-g=.8ae8e498-9c14-4cae-8e68-4c39914a8195@github.com>
References: <fdm8TK_FBJheQ_Wkd_KobosU0uTioUuRZhIK38I3Q-g=.8ae8e498-9c14-4cae-8e68-4c39914a8195@github.com>
Message-ID: <kQMfKDd-5lJ-I3rXLgC2Y_u6lPAMUd_wSpf32HWcZ2s=.e93eda67-479a-44ed-821a-5b122daf062b@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:

  review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28769/files
  - new: https://git.openjdk.org/jdk/pull/28769/files/38eb3b3f..007e73cd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28769&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28769&range=01-02

  Stats: 3 lines in 1 file changed: 2 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 roland at openjdk.org  Fri Dec 19 13:19:08 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Fri, 19 Dec 2025 13:19:08 GMT
Subject: RFR: 8373343: C2: verify AddP base input only set for heap
 addresses [v2]
In-Reply-To: <_x8OV9zV3TaggMMwjNpjaeBtQRIxXbmq-VvV10SmTHg=.b7a98f3f-19c6-442b-b71b-a86a5b6f685a@github.com>
References: <fdm8TK_FBJheQ_Wkd_KobosU0uTioUuRZhIK38I3Q-g=.8ae8e498-9c14-4cae-8e68-4c39914a8195@github.com>
 <T6ZxMdJ9pNnL8Ao63VPDxzkRhMKiSR6RfL6MuKM9-1Q=.8039caa8-5086-47eb-a0ef-2fca0093897a@github.com>
 <_x8OV9zV3TaggMMwjNpjaeBtQRIxXbmq-VvV10SmTHg=.b7a98f3f-19c6-442b-b71b-a86a5b6f685a@github.com>
Message-ID: <G7QVgnu4z0IOHu4JYoNkGY2vq0SaLpGX10w1RnunO9I=.42ad7921-362b-45c3-af44-ea436302f084@github.com>

On Thu, 18 Dec 2025 03:27:29 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
>> 
>>  - review
>>  - review
>>  - merge
>>  - more
>>  - more
>>  - more
>>  - undo
>>  - exps
>
> src/hotspot/share/opto/memnode.cpp line 2570:
> 
>> 2568:             assert(tkls2->offset() == 0, "not a load of java_mirror");
>> 2569: #endif
>> 2570:             return adr2->in(AddPNode::Address);
> 
> What should the value of adr2->in(AddPNode::Offset) be at this point? 0 or java_mirror_offset()?  Do we need to check it?

I added a couple asserts here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28769#discussion_r2635070902

From rrich at openjdk.org  Fri Dec 19 13:52:18 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Fri, 19 Dec 2025 13:52:18 GMT
Subject: RFR: 8369515: Deadlock between JVMTI and JNI
 ReleasePrimitiveArrayCritical [v3]
In-Reply-To: <qlT_BgonQ3i1_YIAJ6cmvp7u-WBr9JEik-WAhfDDMjQ=.b011b5bc-108d-445e-ab95-92c4457465eb@github.com>
References: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
 <qlT_BgonQ3i1_YIAJ6cmvp7u-WBr9JEik-WAhfDDMjQ=.b011b5bc-108d-445e-ab95-92c4457465eb@github.com>
Message-ID: <1NnXP_p6_XPsKO0kPmmColRPJZBTmtcl9x0TdRAPjfI=.e4920b21-6c57-455e-89cb-59456a9da863@github.com>

On Fri, 19 Dec 2025 01:55:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> As discussed in JBS the deadlock occurs when the call to `ReleasePrimitiveArrayCritical` performs the transition from native to VM, and in the process checks for special runtime exit conditions - which includes the `obj_deopt_suspend` request. The simple solution is to define a custom JNI ENTRY with custom `ThreadInVMfromNative` that elides the exit check.
>> 
>> The change is limited to `ReleasePrimitiveArrayCritical` and `ReleaseStringCritical`.
>> 
>> UPDATE: we are now employing a much simpler solution.
>> 
>> There is no regression test as this has only been seen in long running stress tests.
>> 
>> Testing:
>>    -tiers 1-6
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Exapnd comment

Looks good.
Thanks, Richard.

A deadlock can still occur if the debugger suspends the thread in the critical region, e.g. to read a local variable. After [JDK-8373839](https://bugs.openjdk.org/browse/JDK-8373839) this shouldn't be possible anymore.

-------------

Marked as reviewed by rrich (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28779#pullrequestreview-3598687723
PR Comment: https://git.openjdk.org/jdk/pull/28779#issuecomment-3675155037

From roland at openjdk.org  Fri Dec 19 14:10:11 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Fri, 19 Dec 2025 14:10:11 GMT
Subject: RFR: 8370519: C2: Hit MemLimit when running with
 +VerifyLoopOptimizations [v6]
In-Reply-To: <qEoc6t9TVHMFRNCkPaxsdTC6LJ2kkzUctSzYJMA4j0g=.6fb77327-f3e4-46cd-9e12-c3384940c44b@github.com>
References: <W7EnT28-84mtwppISdr_ydCV9HSaXk72y7fyd29z4wQ=.7331c81d-c36f-4a1c-b949-e7045f524d07@github.com>
 <ivWBI33pO0sKOtifG2aGTozX0ybXkxSazNW-T5rpJyU=.a77a85c6-3540-4ce8-8b82-db7bae444615@github.com>
 <qEoc6t9TVHMFRNCkPaxsdTC6LJ2kkzUctSzYJMA4j0g=.6fb77327-f3e4-46cd-9e12-c3384940c44b@github.com>
Message-ID: <zKBeSbnskrWeGhDjGGK3W06v2TL6yX7ctFxPFsJc9R8=.7a70a059-0b28-428e-93b8-a46dc433101a@github.com>

On Fri, 19 Dec 2025 10:21:29 GMT, Beno?t Maillard <bmaillard at openjdk.org> 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`.

Thanks for working on that. Without the patch and no limit on memory usage, I see:

Arena Usage by Arena Type and compilation phase, at arena usage peak of 106292736
idealLoop                  11723824         0   2814728   8516320    392776         0         0         0         0         0         0         0         0 
output                     84858328  84858328         0         0         0         0         0         0         0         0         0         0         0 


With the fix:

Arena Usage by Arena Type and compilation phase, at arena usage peak of 98628104
idealLoop                   4288448         0   2814728   1080944         0    392776         0         0         0         0         0         0         0         0
output                     84858328  84858328         0         0         0         0         0         0         0         0         0         0         0         0


So 7+ MB of memory is saved but most of the memory is used by `output` anyway. As a consequence, with the fix, memory usage is still close to 100MB. I wonder how robust the test is going to be on other platforms (`output` memory usage could be higher) or as the C2 code evolves and memory usage changes.
Have you run it on other platforms with the fix to make sure it does pass everywhere?
If , say `idealLoop` usage was about as high as `output` without the fix, that would make the test more robust. In the process of coming up with that test, was there any other tests you try that took a bit longer to run but used a bit more memory?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28581#issuecomment-3675211322

From stefank at openjdk.org  Fri Dec 19 14:30:05 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 19 Dec 2025 14:30:05 GMT
Subject: RFR: 8374145: Remove legacy locking remnants from markWord
Message-ID: <4yUGXErqsnP6fbNf5jqqZe5oZL1rtf8YFEAwnlDVFRs=.0609c860-7f4f-4da7-897e-3929499e2a87@github.com>

There's a bunch of unused code in markWord that used to be used by the removed legacy locking. I propose that we remove it.

There's a Shenandoah change that should be checked closer. My thinking is:
 `is_being_inflated`: always returns false
 `has_displaced_mark_helper`: Only returns true if both these are true:
   * `!UseCompactObjectTable` - there's an early return for this earlier in the function.
   * `lockbits == monitor_value` - checked in the if-statement above

-------------

Commit messages:
 - 8374145: Remove legacy locking remnants from markWord

Changes: https://git.openjdk.org/jdk/pull/28927/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28927&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374145
  Stats: 33 lines in 2 files changed: 0 ins; 32 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28927.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28927/head:pull/28927

PR: https://git.openjdk.org/jdk/pull/28927

From aboldtch at openjdk.org  Fri Dec 19 14:30:06 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 19 Dec 2025 14:30:06 GMT
Subject: RFR: 8374145: Remove legacy locking remnants from markWord
In-Reply-To: <4yUGXErqsnP6fbNf5jqqZe5oZL1rtf8YFEAwnlDVFRs=.0609c860-7f4f-4da7-897e-3929499e2a87@github.com>
References: <4yUGXErqsnP6fbNf5jqqZe5oZL1rtf8YFEAwnlDVFRs=.0609c860-7f4f-4da7-897e-3929499e2a87@github.com>
Message-ID: <2Xbj1QOxPiOM5_e4mNuEbQpn2VFxwJ19xXpBnAy2_T8=.7d5d7174-3a37-464b-a25c-f89d7a5028f5@github.com>

On Fri, 19 Dec 2025 14:05:13 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> There's a bunch of unused code in markWord that used to be used by the removed legacy locking. I propose that we remove it.
> 
> There's a Shenandoah change that should be checked closer. My thinking is:
>  `is_being_inflated`: always returns false
>  `has_displaced_mark_helper`: Only returns true if both these are true:
>    * `!UseCompactObjectTable` - there's an early return for this earlier in the function.
>    * `lockbits == monitor_value` - checked in the if-statement above

Looks good. Just one thought.

src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp line 349:

> 347:   } else if (w.is_being_inflated() || w.has_displaced_mark_helper()) {
> 348:     // Informs caller that we aren't able to determine the age
> 349:     return markWord::max_age + 1; // sentinel

Not sure if we want an `!w.has_displaced_mark_helper()` assert. Even if we already check  for (and handled) the exact conditions (in the current implementation) for `has_displaced_mark_helper()`.

-------------

Marked as reviewed by aboldtch (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28927#pullrequestreview-3598758617
PR Review Comment: https://git.openjdk.org/jdk/pull/28927#discussion_r2635220791

From stefank at openjdk.org  Fri Dec 19 14:30:07 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 19 Dec 2025 14:30:07 GMT
Subject: RFR: 8374145: Remove legacy locking remnants from markWord
In-Reply-To: <2Xbj1QOxPiOM5_e4mNuEbQpn2VFxwJ19xXpBnAy2_T8=.7d5d7174-3a37-464b-a25c-f89d7a5028f5@github.com>
References: <4yUGXErqsnP6fbNf5jqqZe5oZL1rtf8YFEAwnlDVFRs=.0609c860-7f4f-4da7-897e-3929499e2a87@github.com>
 <2Xbj1QOxPiOM5_e4mNuEbQpn2VFxwJ19xXpBnAy2_T8=.7d5d7174-3a37-464b-a25c-f89d7a5028f5@github.com>
Message-ID: <MWTSeft3RYpBQ7ja-bVWkQjlRR7LOyo1Q0deHXt1FsU=.e0c7a21f-f466-4d05-a14b-e614e448e8aa@github.com>

On Fri, 19 Dec 2025 14:10:24 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> There's a bunch of unused code in markWord that used to be used by the removed legacy locking. I propose that we remove it.
>> 
>> There's a Shenandoah change that should be checked closer. My thinking is:
>>  `is_being_inflated`: always returns false
>>  `has_displaced_mark_helper`: Only returns true if both these are true:
>>    * `!UseCompactObjectTable` - there's an early return for this earlier in the function.
>>    * `lockbits == monitor_value` - checked in the if-statement above
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp line 349:
> 
>> 347:   } else if (w.is_being_inflated() || w.has_displaced_mark_helper()) {
>> 348:     // Informs caller that we aren't able to determine the age
>> 349:     return markWord::max_age + 1; // sentinel
> 
> Not sure if we want an `!w.has_displaced_mark_helper()` assert. Even if we already check  for (and handled) the exact conditions (in the current implementation) for `has_displaced_mark_helper()`.

That would work for me. I'll wait for input from the Shenandoah devs.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28927#discussion_r2635237702

From rrich at openjdk.org  Fri Dec 19 14:32:36 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Fri, 19 Dec 2025 14:32:36 GMT
Subject: RFR: 8372591: assert(!current->cont_fastpath() ||
 freeze.check_valid_fast_path()) failed
In-Reply-To: <_lvm42phwda7i6vX6U6cFoaLLu07NELtWmW0pg73IVI=.83b5be81-f8a2-4364-8214-cf7638daff67@github.com>
References: <6yaYr_fSazq20-3lshGS-_Lr-LqXMt4lTeaFzDs9U2U=.c865efd1-9b98-4fce-98dd-4e1fe50a45be@github.com>
 <_LgB7c2fIE-RBo1CpmjeirR4oG6v8JBVQZ8spZzDLY8=.a67da689-d204-4550-86b6-c0efde380892@github.com>
 <kCm-ez6k9Jj2bmCrEyNZ_5FbnjsO2yx3V8MK26KO6xw=.bc3645bd-08aa-4f28-a4c1-412b2441e5ba@github.com>
 <x_K0IOvZhCD_PHDZdxXiUBCuhtuZMl8giZ6n2ZbAUnM=.f82bb705-473c-4e55-a3c1-b996a34d8831@github.com>
 <_lvm42phwda7i6vX6U6cFoaLLu07NELtWmW0pg73IVI=.83b5be81-f8a2-4364-8214-cf7638daff67@github.com>
Message-ID: <evMtYfVg6JvfAlrQ5NdhSD4_gFM5U9Azx2ux9t9SbME=.98129440-5a57-4267-ab33-1b54562b3722@github.com>

On Thu, 18 Dec 2025 20:37:59 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> > 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?

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.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28830#issuecomment-3675281628

From stefank at openjdk.org  Fri Dec 19 14:39:42 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 19 Dec 2025 14:39:42 GMT
Subject: RFR: 8374151: Cleanup minor markWord function disorder
Message-ID: <EQkEVmZecrvLvgfZYAQ-8FrPgYGJYWEbqKKPaqWD734=.3c1353da-03d2-45d7-8d61-e059a4051d3c@github.com>

I propose a minor restructuring to have the hash, monitor, and displaced_marker_helper functions grouped instead of intermixed.

-------------

Depends on: https://git.openjdk.org/jdk/pull/28927

Commit messages:
 - 8374151: Cleanup minor markWord function disorder

Changes: https://git.openjdk.org/jdk/pull/28928/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28928&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374151
  Stats: 25 lines in 1 file changed: 12 ins; 11 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28928.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28928/head:pull/28928

PR: https://git.openjdk.org/jdk/pull/28928

From rcastanedalo at openjdk.org  Fri Dec 19 15:46:24 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 19 Dec 2025 15:46:24 GMT
Subject: [jdk26] RFR: 8351889: C2 crash: assertion failed: Base pointers
 must match (addp 344)
In-Reply-To: <pGBYr16YEbYzSHyQTnMK1EFzWv2dLR2P19P_gzEo7Bo=.0fc3368f-4917-4145-a178-845efaeaa1bd@github.com>
References: <pGBYr16YEbYzSHyQTnMK1EFzWv2dLR2P19P_gzEo7Bo=.0fc3368f-4917-4145-a178-845efaeaa1bd@github.com>
Message-ID: <jh2dBRs3zPAzgWOVoVwSGFHVSsj32SxuE5J1QeROpE4=.012f1fb8-79c2-409d-a0c2-fa58b35d4c39@github.com>

On Thu, 18 Dec 2025 08:31:35 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [ad29642d](https://github.com/openjdk/jdk/commit/ad29642d8f4e8e0fb1223b14b85ab7841d7b1b51) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Roland Westrelin on 15 Dec 2025 and was reviewed by Roberto Casta?eda Lozano and Emanuel Peter.
> 
> Thanks!

Test results look good!

-------------

Marked as reviewed by rcastanedalo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28893#pullrequestreview-3599075247

From duke at openjdk.org  Fri Dec 19 17:06:36 2025
From: duke at openjdk.org (Vishal Chand)
Date: Fri, 19 Dec 2025 17:06:36 GMT
Subject: RFR: 8372652: Re-enable LocalRandom clinit after monitor pinning
 improvements
In-Reply-To: <IgEuelEzPt9Atv8KQR1Sa80QaKGllGNR-nWRF-sdm3Y=.72ccb838-8723-4fb8-9547-ed20e51b00f1@github.com>
References: <IgEuelEzPt9Atv8KQR1Sa80QaKGllGNR-nWRF-sdm3Y=.72ccb838-8723-4fb8-9547-ed20e51b00f1@github.com>
Message-ID: <f_hLwAyxXRq1raZ-ZX78r6c8WjYGvCOL6GGJContIuc=.669779a7-874e-4031-810d-03a72f3e6c5b@github.com>

On Thu, 27 Nov 2025 23:33:56 GMT, Vishal Chand <duke at openjdk.org> wrote:

> This PR re-enables LocalRandom clinit after monitor pinning improvements.
> Enabling this one would start printing random seeds, which is useful for test debugging.

Hi Everyone,

Apologies for the delay - I just got bandwidth to work on this. I conducted extensive testing to ensure this change is safe and doesn't cause regressions. I stabilized the jtreg results with both the `baseline` and `the change` by running `make test TEST=vmTestbase/ JTREG=TEST_THREAD_FACTORY=Virtual` 3 times for each case to identify `passed`, `flaky`, `failed`, and `errored` tests. Then I ran the `failed` and `errored` tests 10 times each to eliminate flaky tests and get concrete numbers. Below are the results:

**=== BASELINE ===**
Passing (includes Flaky): 3048
Failing + Error: 15

**=== With Change ===**
Passing (includes Flaky): 3048
Failing + Error: 15

The failing tests are **identical** in both cases:

  test/hotspot/jtreg/vmTestbase/nsk/monitoring/MemoryUsage/from/from001/TestDescription.java
  test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadInfo/from_c/from_c001/TestDescription.java
  test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadInfo/getLockName/getlockname001/TestDescription.java
  test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadInfo/getLockOwnerName/getlockownername001/TestDescription.java
  test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadInfo/isInNative/isinnative001/TestDescription.java
  test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/GetThreadAllocatedBytes/baseBehaviorTest_directly/TestDescription.java
  test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/GetThreadAllocatedBytes/baseBehaviorTest_proxy_custom/TestDescription.java
  test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/GetThreadAllocatedBytes/baseBehaviorTest_proxy_default/TestDescription.java
  test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/GetThreadAllocatedBytes/baseBehaviorTest_server_custom/TestDescription.java
  test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/GetThreadAllocatedBytes/baseBehaviorTest_server_default/TestDescription.java
  test/hotspot/jtreg/vmTestbase/vm/mlvm/indy/func/jdi/breakpoint/Test.java
  test/hotspot/jtreg/vmTestbase/vm/mlvm/indy/func/jdi/breakpointOtherStratum/Test.java
  test/hotspot/jtreg/vmTestbase/vm/mlvm/indy/stress/jdi/breakpointInCompiledCode/Test.java
  test/hotspot/jtreg/vmTestbase/vm/mlvm/meth/func/jdi/breakpoint/Test.java
  test/hotspot/jtreg/vmTestbase/vm/mlvm/meth/func/jdi/breakpointOtherStratum/Test.java


I verified that the failure reasons are **identical** between baseline and change scenarios.

Based on these results, the change doesn't cause any regressions and is safe to merge.

Please let me know if you need more info, I'll be happy to share.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28547#issuecomment-3675825598

From kbarrett at openjdk.org  Fri Dec 19 18:08:28 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 19 Dec 2025 18:08:28 GMT
Subject: RFR: 8374145: Remove legacy locking remnants from markWord
In-Reply-To: <4yUGXErqsnP6fbNf5jqqZe5oZL1rtf8YFEAwnlDVFRs=.0609c860-7f4f-4da7-897e-3929499e2a87@github.com>
References: <4yUGXErqsnP6fbNf5jqqZe5oZL1rtf8YFEAwnlDVFRs=.0609c860-7f4f-4da7-897e-3929499e2a87@github.com>
Message-ID: <oH80ZAs4wlr-80KFBbdhUclnSW390IMam4Xqbonlbgc=.baf03f70-de14-4da6-858c-5cddb8336bb7@github.com>

On Fri, 19 Dec 2025 14:05:13 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> There's a bunch of unused code in markWord that used to be used by the removed legacy locking. I propose that we remove it.
> 
> There's a Shenandoah change that should be checked closer. My thinking is:
>  `is_being_inflated`: always returns false
>  `has_displaced_mark_helper`: Only returns true if both these are true:
>    * `!UseCompactObjectTable` - there's an early return for this earlier in the function.
>    * `lockbits == monitor_value` - checked in the if-statement above

Looks good.  No opinion about @xmas92 suggestion in the shenandoah change.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28927#pullrequestreview-3599550836

From cjplummer at openjdk.org  Fri Dec 19 18:46:02 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 19 Dec 2025 18:46:02 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v5]
In-Reply-To: <o5RfVmRlL4rk-uklwwVWo-aZr5-pi1JnSm9okRCr3V4=.b4ae7097-db7f-48c6-a704-a0d180abe2c0@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
 <o5RfVmRlL4rk-uklwwVWo-aZr5-pi1JnSm9okRCr3V4=.b4ae7097-db7f-48c6-a704-a0d180abe2c0@github.com>
Message-ID: <aeaIObD8KHYaIG3RoHEqqaDwLhSm7NqnC5TCst7F9Iw=.e163a2e8-47cf-40ca-b578-f50cbe37e2e6@github.com>

On Fri, 19 Dec 2025 08:45:37 GMT, SendaoYan <syan at openjdk.org> 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:
>> 
>> - [ ] All jtreg tests by fastdebug build
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Increase max iteration for nsk/jvmti/CompiledMethodUnload/compmethunload001/TestDescription.java

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.

test/hotspot/jtreg/vmTestbase/gc/gctests/LargeObjects/large001/large001.java line 154:

> 152: 
> 153:                     // Drop all references to the class and try to unload it
> 154:                     WhiteBox.getWhiteBox().fullGC();

Just to be clear, this is now no different than the `unloader.unloadClass()` call below in terms of how it is implemented. I wonder why the author originally used eatMemory() here and unloadClass() below.

test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassObjectReference/reflectedType/reflectype002/TestDescription.java line 71:

> 69:  *      -transport.address=dynamic
> 70:  *      -debugee.vmkeys="${test.vm.opts} ${test.java.opts} -Xbootclasspath/a:.
> 71:  *      -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI" ./bin

In all the JDI tests, this line should be indented to show that it is a continuation of `-debugee.vmkeys `started on the line before.

test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java line 50:

> 48:         "nsk.jvmti.CompiledMethodUnload.compmethunload001u";
> 49: 
> 50:     private final static int MAX_ITERATIONS = 50;

Can you explain the need for this change.

-------------

PR Review: https://git.openjdk.org/jdk/pull/28891#pullrequestreview-3599556766
PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2635960204
PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2635889453
PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2635893925

From wkemper at openjdk.org  Fri Dec 19 19:02:13 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 19 Dec 2025 19:02:13 GMT
Subject: RFR: 8373203: Genshen: Non-strong reference leak in old gen [v5]
In-Reply-To: <JaJt39rlIHDKUiyQmDuh0uSyVslFVLKisMXo0r2gROk=.1056f4b4-441f-4ed2-9e7f-e81cbaca272c@github.com>
References: <JaJt39rlIHDKUiyQmDuh0uSyVslFVLKisMXo0r2gROk=.1056f4b4-441f-4ed2-9e7f-e81cbaca272c@github.com>
Message-ID: <w54mYnLXBC06G1CWUNuNiWaGe_wYb4srV4sKVf0TOy8=.fa3b7b48-480b-4699-94b9-c7356d7b271b@github.com>

> The generational mode for Shenandoah will collect _referents_ for the generation being collected. For example, if we have a young reference pointing to an old referent, that young reference will be processed after we finish marking the old generation. This presents a problem for discovery.
>   
> When the young mark _encounters_ a young reference with an old referent, it cannot _discover_ it because old marking hasn't finished. However, if it does not discover it, the old referent will be strongly marked. This, in turn, will prevent the old generation from clearing the referent (if it even reaches it again during old marking).
>   
> To solve this, we let young reference processing discover the old reference by having it use the old generation reference processor to do so. This means the old reference processor can have a discovered list that contains young weak references. If any of these young references reside in a region that is collected, old reference processing will crash when it processes such a reference. Therefore, we add a method `heal_discovered_lists` to traverse the discovered lists after young evacuation is complete. The method will replace any forwarded entries in the discovered list with the forwardee.
> 
> This PR also extends whitebox testing support for Shenandoah, giving us the ability to trigger young/old collections and interrogate some properties of heaps and regions.

William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:

 - Merge remote-tracking branch 'jdk/master' into fix-old-reference-processing
 - Fix idiosyncratic white space in whitebox
   
   Co-authored-by: Stefan Karlsson <stefan.karlsson at oracle.com>
 - Sort includes
 - Heal old discovered lists in parallel
 - Fix comment
 - Factor duplicate code into shared method
 - Heal discovered oops in common place for degen and concurrent update refs
 - Merge remote-tracking branch 'jdk/master' into fix-old-reference-processing
 - Clear bootstrap mode for full GC that might have bypassed degenerated cycle
 - Do not bypass card barrier when healing discovered list
 - ... and 9 more: https://git.openjdk.org/jdk/compare/400d8cfb...f621b70c

-------------

Changes: https://git.openjdk.org/jdk/pull/28810/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28810&range=04
  Stats: 667 lines in 20 files changed: 535 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 coleenp at openjdk.org  Fri Dec 19 19:13:07 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 19 Dec 2025 19:13:07 GMT
Subject: RFR: 8374145: Remove legacy locking remnants from markWord
In-Reply-To: <4yUGXErqsnP6fbNf5jqqZe5oZL1rtf8YFEAwnlDVFRs=.0609c860-7f4f-4da7-897e-3929499e2a87@github.com>
References: <4yUGXErqsnP6fbNf5jqqZe5oZL1rtf8YFEAwnlDVFRs=.0609c860-7f4f-4da7-897e-3929499e2a87@github.com>
Message-ID: <Nkh1jcadMh-UL-GQb101yMKcU_ftt5xGnbIQk04ntFg=.6fa72e6d-f0dc-45d4-a095-5a02e0ab899b@github.com>

On Fri, 19 Dec 2025 14:05:13 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> There's a bunch of unused code in markWord that used to be used by the removed legacy locking. I propose that we remove it.
> 
> There's a Shenandoah change that should be checked closer. My thinking is:
>  `is_being_inflated`: always returns false
>  `has_displaced_mark_helper`: Only returns true if both these are true:
>    * `!UseCompactObjectTable` - there's an early return for this earlier in the function.
>    * `lockbits == monitor_value` - checked in the if-statement above

Thanks for finding these.

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28927#pullrequestreview-3599722153

From psandoz at openjdk.org  Fri Dec 19 22:52:56 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 19 Dec 2025 22:52:56 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v9]
In-Reply-To: <Xchw48xIyPtUaVaTzcWYPlqSJX2IiFiXls-PC_CSO3o=.c4e3748b-e826-4587-b26f-9011e15bbb94@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <W3wLPA_gsj3C0nXvT2xQqIh5DlFJW0VszDQtmhkieJ0=.06dc05cd-c081-44f4-8fe5-e81c261dea8a@github.com>
 <xICotngWnv6o6yApK6uBKGMXro-V-x96TTZVZo3Jxx4=.f96530fe-491e-4caa-8d1a-9fff3018533f@github.com>
 <n7Xa6kvC3x_MgO9XMZjfJUdm0D30wsB-vYI-Ce3J3O4=.8c5ec613-3c86-49ba-87ab-d29d6be87b6f@github.com>
 <m3iiFd9268Wpp6ortuHKCEA7AwecpV22KL3UEi2E0XA=.a3920fc3-4a3e-47c2-a602-e72872560a40@github.com>
 <U8s19UjaUOh0ipUZeKkSAprwjOsFHHmNefi5AKcohSo=.0ba2cf00-29c4-41a6-b91c-65ff22e0ff92@github.com>
 <8hStIcvp252Ik7raxZL5BvFKKkXTflorjyOD9Cyakvc=.c5d1b302-5c49-46b1-91ba-2feda2e6a746@github.com>
 <bvuVSZazvV1xkWXg36-aNiHcYGm7OtwESmohHSDy58w=.dae1caf9-c2b4-4527-b1fa-adf3c18dc366@github.com>
 <Xchw48xIyPtUaVaTzcWYPlqSJX2IiFiXls-PC_CSO3o=.c4e3748b-e826-4587-b26f-9011e15bbb94@github.com>
Message-ID: <8Z84JAkAC6yVFA_1j82FXuoqn1Gu5qQLBlgbcVDAuLQ=.ec5f98c0-42de-4395-a46e-bb2b0be3c12a@github.com>

On Fri, 19 Dec 2025 06:26:47 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>>> > The basic type codes are declared and shared across Java and HotSpot - it's used in `LaneType`. Can we pass a single argument that is the basic type instead of two arguments. HotSpot should know from the basic type what the carrier class and also what the operation type without it being explicitly told, since presumably it knew the inverse - the basic type from the element class.
>>> 
>>> Hi @PaulSandoz, T_HALFFLOAT used in LaneType is mainly used for differentiation of various cache keys used by conversion operation lookups. In principle, we can extend VM to acknowledge this new custom basic type on the lines of T_METADATA / T_ADDRESS; its scope for now will be restricted to VectorSupport. We can gradually expose this to C2 type, such that TypeVect for all Float16 VectorIR uses T_HALFFLOAT as its basic type; currently, we use T_SHORT as the lane type. Let me know if this looks reasonable
>> 
>> I am proposing something simpler, really as a temporary step until `Float16` becomes part of the `java.base` module. IIUC from the basic type we can reliably determine what the two arguments we currently passing are e.g.,  T_HALFFLOAT = { short.class, VECTOR_TYPE_FP16 }. So we don't need to pass two arguments, we can just pass one, the intrinsic can lookup the class and operation type kind.
>
> 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!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3676923873

From dlong at openjdk.org  Fri Dec 19 23:44:54 2025
From: dlong at openjdk.org (Dean Long)
Date: Fri, 19 Dec 2025 23:44:54 GMT
Subject: RFR: 8373343: C2: verify AddP base input only set for heap
 addresses [v3]
In-Reply-To: <kQMfKDd-5lJ-I3rXLgC2Y_u6lPAMUd_wSpf32HWcZ2s=.e93eda67-479a-44ed-821a-5b122daf062b@github.com>
References: <fdm8TK_FBJheQ_Wkd_KobosU0uTioUuRZhIK38I3Q-g=.8ae8e498-9c14-4cae-8e68-4c39914a8195@github.com>
 <kQMfKDd-5lJ-I3rXLgC2Y_u6lPAMUd_wSpf32HWcZ2s=.e93eda67-479a-44ed-821a-5b122daf062b@github.com>
Message-ID: <0jsb7vKbh77MzBuNJMhfyYKQjXtSSQS2aS6uA_BiEWk=.4a3f5fa0-64ee-46d5-9f5d-759f226356b1@github.com>

On Fri, 19 Dec 2025 13:15:38 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> The base input of `AddP` is expected to only be set for heap accesses
>> but I noticed some inconsistencies so I added an assert in the `AddP`
>> constructor and fixed issues that it caught. AFAFICT, the
>> inconsistencies shouldn't create issues.
>
> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Let me run testing again before I approve final version.  2nd round of testing passed, but it was on an earlier version.

-------------

PR Review: https://git.openjdk.org/jdk/pull/28769#pullrequestreview-3600464325

From dlong at openjdk.org  Fri Dec 19 23:44:56 2025
From: dlong at openjdk.org (Dean Long)
Date: Fri, 19 Dec 2025 23:44:56 GMT
Subject: RFR: 8373343: C2: verify AddP base input only set for heap
 addresses [v2]
In-Reply-To: <G7QVgnu4z0IOHu4JYoNkGY2vq0SaLpGX10w1RnunO9I=.42ad7921-362b-45c3-af44-ea436302f084@github.com>
References: <fdm8TK_FBJheQ_Wkd_KobosU0uTioUuRZhIK38I3Q-g=.8ae8e498-9c14-4cae-8e68-4c39914a8195@github.com>
 <T6ZxMdJ9pNnL8Ao63VPDxzkRhMKiSR6RfL6MuKM9-1Q=.8039caa8-5086-47eb-a0ef-2fca0093897a@github.com>
 <_x8OV9zV3TaggMMwjNpjaeBtQRIxXbmq-VvV10SmTHg=.b7a98f3f-19c6-442b-b71b-a86a5b6f685a@github.com>
 <G7QVgnu4z0IOHu4JYoNkGY2vq0SaLpGX10w1RnunO9I=.42ad7921-362b-45c3-af44-ea436302f084@github.com>
Message-ID: <5-o26FUaB5buQhV_DKDKzF0oFJO8nS2AGOtahIfHVOY=.f961b6aa-efc2-4786-8016-249635c93d0f@github.com>

On Fri, 19 Dec 2025 13:16:21 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> src/hotspot/share/opto/memnode.cpp line 2570:
>> 
>>> 2568:             assert(tkls2->offset() == 0, "not a load of java_mirror");
>>> 2569: #endif
>>> 2570:             return adr2->in(AddPNode::Address);
>> 
>> What should the value of adr2->in(AddPNode::Offset) be at this point? 0 or java_mirror_offset()?  Do we need to check it?
>
> I added a couple asserts here.

If adr2->in(AddPNode::Address) is also an AddP, it's actually adr2->in(AddPNode::Address)->in(AddPNode::Offset) I'm concerned about, but maybe checking it with something like Ideal_base_and_offset() is probably overkill given the TypeKlassPtr::offset() should be derived from that info.  In other words, the offset from the type should combine any non-zero offsets from Address and Offset edges.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28769#discussion_r2636591633

From duke at openjdk.org  Sat Dec 20 02:09:22 2025
From: duke at openjdk.org (duke)
Date: Sat, 20 Dec 2025 02:09:22 GMT
Subject: Withdrawn: 8368722: Vector API intrinsics enabled wrongly on platforms
 without support for misaligned vector access
In-Reply-To: <fi2SqsdPFoxDgBYKtul7N03Y95w3ScIJQQQAGJ7o7N0=.081b8b23-74c7-43e2-9f27-e1ffd74d47bc@github.com>
References: <fi2SqsdPFoxDgBYKtul7N03Y95w3ScIJQQQAGJ7o7N0=.081b8b23-74c7-43e2-9f27-e1ffd74d47bc@github.com>
Message-ID: <ekiReVNo5--GHCBgCT4foMDp4O5dV-nplz7gvmLZNto=.3ecf262c-badd-4724-bd6b-828413130cb8@github.com>

On Fri, 26 Sep 2025 01:44:19 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

> Hi,
> Can you help to review this patch? Thanks!
> 
> In `*VectorLoadStoreTests.java`,  `loadMemorySegmentMaskIOOBE` and `storeMemorySegmentMaskIOOBE` may fail because `int index = fi.apply((int) a.byteSize())` can generate random indices that result in misaligned addresses, leading to SIGBUS on hardware that disallows misaligned vector accesses.
> 
> Some RISC-V hardware supports fast misaligned scalar accesses but not vector ones, which causes SIGBUS when executing these tests with misaligned vector memory operations.
> 
> After [JDK-8368732](https://bugs.openjdk.org/browse/JDK-8368732), we can use `AlignVector` to check the result on platforms with or without fast misaligned vector accesses. When misaligned vector accesses are not supported, it is possible to completely disable the VM?s VectorAPI support by setting `EnableVectorSupport`, without affecting auto-vectorization.
> 
> In addition, after running fastdebug tests including `jdk_vector, jdk_vector_sanity, hotspot_vector_1, hotspot_vector_2, compiler/vectorapi, compiler/vectorization`, we found that some IR-related tests require EnableVectorSupport. Therefore, we added `@requires vm.opt.EnableVectorSupport == true` to skip these tests.
> 
> We can check the status of EnableVectorSupport as follows:
> 
> On k1
> $ java --add-modules=jdk.incubator.vector -Xlog:compilation -version
> [0.737s][info][compilation] EnableVectorSupport=false
> [0.738s][info][compilation] EnableVectorReboxing=false
> [0.738s][info][compilation] EnableVectorAggressiveReboxing=false
> 
> On qemu
> $ java --add-modules=jdk.incubator.vector -Xlog:compilation -version
> [3.048s][info][compilation] EnableVectorSupport=true
> [3.050s][info][compilation] EnableVectorReboxing=true
> [3.051s][info][compilation] EnableVectorAggressiveReboxing=true
> 
> 
> ### Test (fastdebug)
> - [x] Run jdk_vector, jdk_vector_sanity, hotspot_vector_1, hotspot_vector_2, compiler/vectorapi, compiler/vectorization on k1

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/27506

From syan at openjdk.org  Sat Dec 20 02:15:31 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 20 Dec 2025 02:15:31 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v6]
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: <OCX3rot-UiotkIs2Ec_S-n3toO41GcQ4nC_MvPg1Tzg=.7846e340-66ee-4364-af0e-0b6e18f9f569@github.com>

> 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:
> 
> - [ ] All jtreg tests by fastdebug build

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  Add indent for jdi tests in debugee.vmkeys line

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28891/files
  - new: https://git.openjdk.org/jdk/pull/28891/files/c752a052..5de8cc8c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=04-05

  Stats: 26 lines in 25 files changed: 1 ins; 0 del; 25 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 Dec 20 02:15:32 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 20 Dec 2025 02:15:32 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v5]
In-Reply-To: <aeaIObD8KHYaIG3RoHEqqaDwLhSm7NqnC5TCst7F9Iw=.e163a2e8-47cf-40ca-b578-f50cbe37e2e6@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
 <o5RfVmRlL4rk-uklwwVWo-aZr5-pi1JnSm9okRCr3V4=.b4ae7097-db7f-48c6-a704-a0d180abe2c0@github.com>
 <aeaIObD8KHYaIG3RoHEqqaDwLhSm7NqnC5TCst7F9Iw=.e163a2e8-47cf-40ca-b578-f50cbe37e2e6@github.com>
Message-ID: <EqCUPuNRgVnrBxBZ4JMv6hKmOIdaes2t9h1fod0aI5k=.033174b1-591d-40c6-af32-f9d1d47227fe@github.com>

On Fri, 19 Dec 2025 18:08:56 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Increase max iteration for nsk/jvmti/CompiledMethodUnload/compmethunload001/TestDescription.java
>
> test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassObjectReference/reflectedType/reflectype002/TestDescription.java line 71:
> 
>> 69:  *      -transport.address=dynamic
>> 70:  *      -debugee.vmkeys="${test.vm.opts} ${test.java.opts} -Xbootclasspath/a:.
>> 71:  *      -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI" ./bin
> 
> In all the JDI tests, this line should be indented to show that it is a continuation of `-debugee.vmkeys `started on the line before.

Thanks. The indent has been added for jni tests

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2636700458

From dlong at openjdk.org  Sat Dec 20 03:33:51 2025
From: dlong at openjdk.org (Dean Long)
Date: Sat, 20 Dec 2025 03:33:51 GMT
Subject: RFR: 8373343: C2: verify AddP base input only set for heap
 addresses [v3]
In-Reply-To: <kQMfKDd-5lJ-I3rXLgC2Y_u6lPAMUd_wSpf32HWcZ2s=.e93eda67-479a-44ed-821a-5b122daf062b@github.com>
References: <fdm8TK_FBJheQ_Wkd_KobosU0uTioUuRZhIK38I3Q-g=.8ae8e498-9c14-4cae-8e68-4c39914a8195@github.com>
 <kQMfKDd-5lJ-I3rXLgC2Y_u6lPAMUd_wSpf32HWcZ2s=.e93eda67-479a-44ed-821a-5b122daf062b@github.com>
Message-ID: <-GY9oBe-WRSh16Yi90rp79Xxi784nRtvdqBlMh4TiMs=.ba972df0-9298-4f94-8699-597601bd39ba@github.com>

On Fri, 19 Dec 2025 13:15:38 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> The base input of `AddP` is expected to only be set for heap accesses
>> but I noticed some inconsistencies so I added an assert in the `AddP`
>> constructor and fixed issues that it caught. AFAFICT, the
>> inconsistencies shouldn't create issues.
>
> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Tests passed.

-------------

Marked as reviewed by dlong (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28769#pullrequestreview-3600682440

From syan at openjdk.org  Sat Dec 20 04:43:08 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 20 Dec 2025 04:43:08 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v7]
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: <y_aGNrlNy13FM1p8Pq2_XZi9IL0_YGkslSO2PWGzngg=.dc1f7c2a-b100-46d5-9daa-eecbce3c163e@github.com>

> 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:
> 
> - [ ] All jtreg tests by fastdebug build

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  Update the comments for gc/gctests/LargeObjects/large001/large001.java related tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28891/files
  - new: https://git.openjdk.org/jdk/pull/28891/files/5de8cc8c..a5eaf607

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=05-06

  Stats: 25 lines in 5 files changed: 17 ins; 1 del; 7 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 Dec 20 04:50:54 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 20 Dec 2025 04:50:54 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v5]
In-Reply-To: <aeaIObD8KHYaIG3RoHEqqaDwLhSm7NqnC5TCst7F9Iw=.e163a2e8-47cf-40ca-b578-f50cbe37e2e6@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
 <o5RfVmRlL4rk-uklwwVWo-aZr5-pi1JnSm9okRCr3V4=.b4ae7097-db7f-48c6-a704-a0d180abe2c0@github.com>
 <aeaIObD8KHYaIG3RoHEqqaDwLhSm7NqnC5TCst7F9Iw=.e163a2e8-47cf-40ca-b578-f50cbe37e2e6@github.com>
Message-ID: <GETEUvGGbJVVtrHmhMlz-z2mLcXQI3QzZC-qHLpfUPY=.46a85c09-eff7-4550-a294-8d55d9a26aa5@github.com>

On Fri, 19 Dec 2025 18:41:58 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Increase max iteration for nsk/jvmti/CompiledMethodUnload/compmethunload001/TestDescription.java
>
> test/hotspot/jtreg/vmTestbase/gc/gctests/LargeObjects/large001/large001.java line 154:
> 
>> 152: 
>> 153:                     // Drop all references to the class and try to unload it
>> 154:                     WhiteBox.getWhiteBox().fullGC();
> 
> Just to be clear, this is now no different than the `unloader.unloadClass()` call below in terms of how it is implemented. I wonder why the author originally used eatMemory() here and unloadClass() below.

It seems that, the references is non null at the first time. So it will not unload the classes actually,

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2636777045

From syan at openjdk.org  Sat Dec 20 04:59:07 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 20 Dec 2025 04:59:07 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v8]
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: <DcXo_SUNshJuolC1QTuU6F18wjGhpR_k6YpRQr_EvI4=.b84a458a-f0d3-47b4-8555-e8e6eef6a2b7@github.com>

> 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:
> 
> - [ ] All jtreg tests by fastdebug build

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  Update comments about "using memory stressing techique"

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28891/files
  - new: https://git.openjdk.org/jdk/pull/28891/files/a5eaf607..567c7623

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=06-07

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 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 Dec 20 04:59:09 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 20 Dec 2025 04:59:09 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v5]
In-Reply-To: <aeaIObD8KHYaIG3RoHEqqaDwLhSm7NqnC5TCst7F9Iw=.e163a2e8-47cf-40ca-b578-f50cbe37e2e6@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
 <o5RfVmRlL4rk-uklwwVWo-aZr5-pi1JnSm9okRCr3V4=.b4ae7097-db7f-48c6-a704-a0d180abe2c0@github.com>
 <aeaIObD8KHYaIG3RoHEqqaDwLhSm7NqnC5TCst7F9Iw=.e163a2e8-47cf-40ca-b578-f50cbe37e2e6@github.com>
Message-ID: <QPeMREKa8oUX51nI4WRgmGRy7-9gEj28eykpQD0bVXw=.11428b76-74c9-4339-b6b7-8260d49132c1@github.com>

On Fri, 19 Dec 2025 18:42:44 GMT, Chris Plummer <cjplummer at openjdk.org> 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.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28891#issuecomment-3677383218

From swen at openjdk.org  Sat Dec 20 12:44:22 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 20 Dec 2025 12:44:22 GMT
Subject: RFR: 8371431: Warning message when turning off CompactStrings [v2]
In-Reply-To: <N2eKy-Mvph7nC71NSY3OchmQHhQ4GU-T1esSNLmDauY=.9e2347d8-bedd-4d4f-b000-791c9cdf8c24@github.com>
References: <N2eKy-Mvph7nC71NSY3OchmQHhQ4GU-T1esSNLmDauY=.9e2347d8-bedd-4d4f-b000-791c9cdf8c24@github.com>
Message-ID: <Xuj6WQ-ICHqLUDrJgL40h5q3JRu8rM9CPwBYLdwGt1U=.80d5d023-1d95-4d2d-975f-8f657a24771b@github.com>

> A warning message should be given before removing the CompactStrings off option.

Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge branch 'master' into compact_str_warn_2510
 - Merge branch 'master' into compact_str_warn_2510
 - from @liach
 - add warnings

-------------

Changes: https://git.openjdk.org/jdk/pull/27995/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27995&range=01
  Stats: 12 lines in 2 files changed: 0 ins; 9 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/27995.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27995/head:pull/27995

PR: https://git.openjdk.org/jdk/pull/27995

From aph at openjdk.org  Sat Dec 20 16:45:08 2025
From: aph at openjdk.org (Andrew Haley)
Date: Sat, 20 Dec 2025 16:45:08 GMT
Subject: RFR: 8373697: AArch64: Remove deoptimization stub code for
 nmethods with small stack frames
In-Reply-To: <laBBjEvksraEmA2GPDJ0VcgHLH2wmv-YZYNePhuz1yc=.d48b1b0c-5d69-4566-af86-c7336c50f8be@github.com>
References: <LvdwgIjv2xY3pmOijohkA1h2c61vUSWtgEug7b4k8-w=.6f6e5cbd-a9f1-4154-8205-de52479fdd1f@github.com>
 <laBBjEvksraEmA2GPDJ0VcgHLH2wmv-YZYNePhuz1yc=.d48b1b0c-5d69-4566-af86-c7336c50f8be@github.com>
Message-ID: <LtccnFOtsvcArUHqczVs5uXo4OUJ86lvgCdolGl__IA=.236d2a2c-5e23-4215-bf64-2dc0fafa657f@github.com>

On Thu, 18 Dec 2025 11:34:42 GMT, Ruben <duke at openjdk.org> wrote:

> If we are to remove deoptimization stub code, we need an alternative way for the VM to identify the nmethod based on the return address value.
> At the same time, the return address value should be a valid pointer to executable code transferring control to the shared deoptimization blob.

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.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28857#issuecomment-3677947326

From dlong at openjdk.org  Sat Dec 20 21:57:01 2025
From: dlong at openjdk.org (Dean Long)
Date: Sat, 20 Dec 2025 21:57:01 GMT
Subject: RFR: 8373697: AArch64: Remove deoptimization stub code for
 nmethods with small stack frames
In-Reply-To: <LvdwgIjv2xY3pmOijohkA1h2c61vUSWtgEug7b4k8-w=.6f6e5cbd-a9f1-4154-8205-de52479fdd1f@github.com>
References: <LvdwgIjv2xY3pmOijohkA1h2c61vUSWtgEug7b4k8-w=.6f6e5cbd-a9f1-4154-8205-de52479fdd1f@github.com>
Message-ID: <9Sl4H6Pm4KY36QZZCGcKD1I2f86oAxULIl0lVUuGazY=.955e8db5-3bc3-4f34-a500-d76758abe909@github.com>

On Tue, 16 Dec 2025 23:15:12 GMT, Ruben <duke at openjdk.org> 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?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28857#issuecomment-3678149408

From aph at openjdk.org  Sat Dec 20 23:44:58 2025
From: aph at openjdk.org (Andrew Haley)
Date: Sat, 20 Dec 2025 23:44:58 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: <LvdwgIjv2xY3pmOijohkA1h2c61vUSWtgEug7b4k8-w=.6f6e5cbd-a9f1-4154-8205-de52479fdd1f@github.com>
 <9Sl4H6Pm4KY36QZZCGcKD1I2f86oAxULIl0lVUuGazY=.955e8db5-3bc3-4f34-a500-d76758abe909@github.com>
Message-ID: <bGFyPju_GkrstT6Qh7cyCq5M2ebUDqcChw6Ya2rI9IQ=.9f067650-2461-47a8-bed6-b3de5be709b3@github.com>

On Sat, 20 Dec 2025 21:53:48 GMT, Dean Long <dlong at openjdk.org> wrote:

> That's a good idea. But instead of storing the nmethod* into r8, how about storing the original PC?

Mmm, yes. We can do that.

> 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?

I can't remember. If not, we can make it so,

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28857#issuecomment-3678211660

From rrich at openjdk.org  Sun Dec 21 18:17:01 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Sun, 21 Dec 2025 18:17:01 GMT
Subject: RFR: 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: <mkHOseA4KIXRBUvQZtgulc0LMRvE2qePy1LvFGUePNA=.bd8563f2-9185-4d9f-b975-86faa3a57f8b@github.com>

On Mon, 15 Dec 2025 16:53:05 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> When a frame is OSR and the caller is interpreted we call `push_cont_fastpath` to possible set `_cont_fastpath` to the `sp` of the sender. This is needed in order to keep track of interpreted frames in the stack, so that in case of unmounting we don't incorrectly execute the freeze fast path, which is only allowed when all frames are compiled.
> 
> The problem is that the OSR frame is created starting from the `unextended_sp` of the sender, not the `sp`, i.e we pop the interpreted frame like in `remove_activation`. This means that we could set a value to `_cont_fastpath` that will point outside the valid stack (below the `sp` of the OSR frame). If the gap between these stack addresses is big enough, `_cont_fastpath` could be later cleared while we still have the interpreter sender in the stack, leading to the reported crash. The simplest case where this will happen is if in a later call to yield all the extra frames leading to `Continuation.doYield` fit within this space [[1]](https://github.com/openjdk/jdk/blob/ad29642d8f4e8e0fb1223b14b85ab7841d7b1b51/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L232). It could also be cleared before that if for example at some point we returned from an interpreted callee and the sender sp it's not below `_cont_fastpath`[[2]](https://github.com/openjdk/jdk/blob/ad29642d8f4e8e0fb1223b
 14b85ab7841d7b1b51/src/hotspot/cpu/x86/interp_masm_x86.cpp#L1060).
> 
> The fix is to change `OSR_migration_begin` to set `_cont_fastpath` with the sender's `unextended_sp` instead. 
> 
> The patch includes new test `OSRWithManyLocals.java` which reliably reproduces the crash. I thought about adding it to the existing `OSRTest.java` but that was created to exercise a different issue. A better name for that test would be `OSRWithManyArgs.java`, so I could rename it in this patch if preferred (I also realized that test could be simplified and made easier to read but that's for another PR).
> 
> I tested the current patch with the new test and also run it through mach5 tiers1-7.
> 
> Thanks,
> Patricio

The fix is good (also for ppc). I'll analyze independently of this pr why the reproducer doesn't work on ppc.
Cheers, Richard.

-------------

Marked as reviewed by rrich (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28830#pullrequestreview-3601882335

From mbeckwit at openjdk.org  Sun Dec 21 18:44:44 2025
From: mbeckwit at openjdk.org (Monica Beckwith)
Date: Sun, 21 Dec 2025 18:44:44 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v11]
In-Reply-To: <RLcdu4bOlzGjDgFzeceN2TShErL7vxBgZEn0FIbjyDY=.1deb2754-34c4-4881-a211-7a8da5f0efac@github.com>
References: <RLcdu4bOlzGjDgFzeceN2TShErL7vxBgZEn0FIbjyDY=.1deb2754-34c4-4881-a211-7a8da5f0efac@github.com>
Message-ID: <b4lfHAGIgyfEqn9F_CohHI_rkyijZTiMOvuHfbyBMN4=.d2a22165-03a9-4198-ab80-b021ae5e64ef@github.com>

> **Implements:** https://bugs.openjdk.org/browse/JDK-8357445
> 
> Implement time-based heap uncommit for G1 during idle periods.
> 
> Key changes:
> - Added G1HeapEvaluationTask for periodic heap evaluation
> - Switch from G1ServiceTask to PeriodicTask for improved scheduling
> - Implemented time-based heap sizing policy with configurable uncommit delay
> - Added region activity tracking with last access timestamps
> - Integrated VM_G1ShrinkHeap operation for safe heap shrinking
> - Added new G1 flags: G1UseTimeBasedHeapSizing, G1TimeBasedEvaluationIntervalMillis, G1UncommitDelayMillis, G1MinRegionsToUncommit
> - Added 'sizing' log tag for heap sizing operations
> 
> Comprehensive Test Coverage:
> - Enhanced TestG1RegionUncommit: minimum heap boundaries, concurrent allocation/uncommit scenarios
> - Enhanced TestTimeBasedHeapSizing: humongous object handling, rapid allocation cycles, edge cases
> - Enhanced TestTimeBasedRegionTracking: concurrent region access, lifecycle transition validation
> - Enhanced TestTimeBasedHeapConfig: parameter boundary values, small heap configurations
> 
> This ensures time-based heap uncommit works correctly while maintaining all safety guarantees and test expectations.

Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision:

  Address Thomas Schatzl's review comments for JDK-8357445
  
  This commit addresses all issues raised in Thomas's November 2025 review
  of the time-based heap uncommit feature (PR #26240).
  
  Major architectural fix:
  - VM_G1ShrinkHeap::doit() now re-evaluates uncommit candidates at safepoint
    time by calling find_uncommit_candidates_by_time() during VM operation
    execution. This ensures regions are validated as still free at the point
    of uncommit, fixing the race condition where heap state could change
    between service thread evaluation and VM operation execution.
  
  Code quality improvements:
  - Removed redundant is_empty() checks in g1HeapSizingPolicy.cpp and
    g1HeapRegionManager.cpp since is_free() already implies empty
  - Replaced inefficient bubble sort with GrowableArray::sort() using
    lambda comparator for O(n log n) performance
  - Fixed lambda signature (G1HeapRegion** instead of const*) to match
    GrowableArray::sort() requirements
  - Added periods to sentence-style comments for consistency
  
  The implementation already had correct:
  - SuspendibleThreadSetJoiner placement in service thread task
  - GC coordination with 5% overhead threshold and G1ReservePercent
  - Proper assertions and validations
  
  Tested with SPECjbb2015 showing correct time-based region selection
  and uncommit behavior across varying load patterns.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26240/files
  - new: https://git.openjdk.org/jdk/pull/26240/files/c17f5938..cc7a779a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26240&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26240&range=09-10

  Stats: 126 lines in 6 files changed: 44 ins; 19 del; 63 mod
  Patch: https://git.openjdk.org/jdk/pull/26240.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26240/head:pull/26240

PR: https://git.openjdk.org/jdk/pull/26240

From mbeckwit at openjdk.org  Sun Dec 21 18:51:35 2025
From: mbeckwit at openjdk.org (Monica Beckwith)
Date: Sun, 21 Dec 2025 18:51:35 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v12]
In-Reply-To: <RLcdu4bOlzGjDgFzeceN2TShErL7vxBgZEn0FIbjyDY=.1deb2754-34c4-4881-a211-7a8da5f0efac@github.com>
References: <RLcdu4bOlzGjDgFzeceN2TShErL7vxBgZEn0FIbjyDY=.1deb2754-34c4-4881-a211-7a8da5f0efac@github.com>
Message-ID: <nMl-T8A78zWLrGde1m-5Vb_DI-kGhEfHCpCMNvuUjMU=.cdca754d-79a1-4a99-8aca-a3b68215f74b@github.com>

> **Implements:** https://bugs.openjdk.org/browse/JDK-8357445
> 
> Implement time-based heap uncommit for G1 during idle periods.
> 
> Key changes:
> - Added G1HeapEvaluationTask for periodic heap evaluation
> - Switch from G1ServiceTask to PeriodicTask for improved scheduling
> - Implemented time-based heap sizing policy with configurable uncommit delay
> - Added region activity tracking with last access timestamps
> - Integrated VM_G1ShrinkHeap operation for safe heap shrinking
> - Added new G1 flags: G1UseTimeBasedHeapSizing, G1TimeBasedEvaluationIntervalMillis, G1UncommitDelayMillis, G1MinRegionsToUncommit
> - Added 'sizing' log tag for heap sizing operations
> 
> Comprehensive Test Coverage:
> - Enhanced TestG1RegionUncommit: minimum heap boundaries, concurrent allocation/uncommit scenarios
> - Enhanced TestTimeBasedHeapSizing: humongous object handling, rapid allocation cycles, edge cases
> - Enhanced TestTimeBasedRegionTracking: concurrent region access, lifecycle transition validation
> - Enhanced TestTimeBasedHeapConfig: parameter boundary values, small heap configurations
> 
> This ensures time-based heap uncommit works correctly while maintaining all safety guarantees and test expectations.

Monica Beckwith has 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:

  Address Thomas Schatzl's review comments for JDK-8357445
  
  This commit addresses all issues raised in Thomas's November 2025 review
  of the time-based heap uncommit feature (PR #26240).
  
  Major architectural fix:
  - VM_G1ShrinkHeap::doit() now re-evaluates uncommit candidates at safepoint
    time by calling find_uncommit_candidates_by_time() during VM operation
    execution. This ensures regions are validated as still free at the point
    of uncommit, fixing the race condition where heap state could change
    between service thread evaluation and VM operation execution.
  
  Code quality improvements:
  - Removed redundant is_empty() checks in g1HeapSizingPolicy.cpp and
    g1HeapRegionManager.cpp since is_free() already implies empty
  - Replaced inefficient bubble sort with GrowableArray::sort() using
    lambda comparator for O(n log n) performance
  - Fixed lambda signature (G1HeapRegion** instead of const*) to match
    GrowableArray::sort() requirements
  - Added periods to sentence-style comments for consistency
  
  The implementation already had correct:
  - SuspendibleThreadSetJoiner placement in service thread task
  - GC coordination with 5% overhead threshold and G1ReservePercent
  - Proper assertions and validations
  
  Tested with SPECjbb2015 showing correct time-based region selection
  and uncommit behavior across varying load patterns.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26240/files
  - new: https://git.openjdk.org/jdk/pull/26240/files/cc7a779a..877ce1d2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26240&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26240&range=10-11

  Stats: 10 lines in 3 files changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/26240.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26240/head:pull/26240

PR: https://git.openjdk.org/jdk/pull/26240

From mbeckwit at openjdk.org  Sun Dec 21 21:28:52 2025
From: mbeckwit at openjdk.org (Monica Beckwith)
Date: Sun, 21 Dec 2025 21:28:52 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v10]
In-Reply-To: <RxerEMx6bjKcQ8xuj3NEVVdeJiLJ2kTEztt_5I5GfjY=.6ee24b2a-b01e-4027-8a80-8ae69489749f@github.com>
References: <RLcdu4bOlzGjDgFzeceN2TShErL7vxBgZEn0FIbjyDY=.1deb2754-34c4-4881-a211-7a8da5f0efac@github.com>
 <1FJGEob7g_zkJaboRxyS0hPJ1c590V6zZipDrZ3XpOw=.08c1cf33-af6b-49de-b94d-d4f2ca8f5a22@github.com>
 <RxerEMx6bjKcQ8xuj3NEVVdeJiLJ2kTEztt_5I5GfjY=.6ee24b2a-b01e-4027-8a80-8ae69489749f@github.com>
Message-ID: <Bb8e_QSNLO5SZmzP58y9Vo2EaZI5y9VElSlVK3MHDwQ=.d1f99647-8c9f-4058-8203-4ba96174d028@github.com>

On Thu, 20 Nov 2025 15:06:20 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> I stopped reviewing after >40 issues (still finding some while writing) because
> 
> * some of them were unresolved from last time. Please resolve comments that have been addressed or comment why the change did not address it. Having old unresolved comments are annoying for re-reviews because they make the reviewer unsure if there is some need for further clarification or not.
> * new code introduced the same issues again (e.g. use of `is_empty()`) without comment on why it can be used, after giving the reason why it can't be used.
> * the main issue that the time-based uncommit still interferes with gc based sizing without restriction still applies.
> * another is that the VM operation still does not re-evaluate the decisions, just uncommits a set number of regions. Possibly not even those that were found as candidates earlier afaict.
> * the only improvement I remember has been that `ServiceTask` is used now

Hi @tschatzl,

Thank you for the comprehensive review! I've addressed all the issues you raised in reviews. Since I cannot close comments that I didn't open, I've been checking them off as I completed each fix.

## Major Architectural Fix

**VM Operation Re-evaluation**

You were absolutely right that the service thread evaluation and VM operation execution were disconnected. The region selection was happening outside the safepoint, which could lead to incorrect behavior during concurrent GC operations.

**Fixed:** Modified `VM_G1ShrinkHeap::doit()` to re-evaluate uncommit candidates at the safepoint using `find_uncommit_candidates_by_time()`. This ensures we validate that candidate regions are still free at the point of uncommit:


void VM_G1ShrinkHeap::doit() {
  uint max_regions_to_shrink = (uint)(_bytes / G1HeapRegion::GrainBytes);
  GrowableArray<G1HeapRegion*> candidates(max_regions_to_shrink);
  _g1h->heap_sizing_policy()->find_uncommit_candidates_by_time(&candidates, max_regions_to_shrink);
  
  // Validation loop ensures regions are still free before uncommitting
  _g1h->shrink_with_time_based_selection(shrink_bytes);
}


## Code Quality Improvements

**Redundant `is_empty()` Checks**

You pointed out that `is_empty() && is_free()` was redundant since `is_free()` already implies the region is empty.

**Fixed:** Removed all redundant checks in g1HeapRegionManager.cpp and g1HeapSizingPolicy.cpp. Now using only `hr->is_free()` which is the proper check.

**Bubble Sort ? qsort**

Good catch on the inefficient bubble sort implementation.

**Fixed:** Replaced with `GrowableArray::sort()` using a lambda comparator in g1HeapRegionManager.cpp. This provides O(n log n) performance and leverages the standard library implementation:


static auto compare_region_age = [](G1HeapRegion** a, G1HeapRegion** b) -> int {
  Ticks time_a = (*a)->last_access_time();
  Ticks time_b = (*b)->last_access_time();
  if (time_a < time_b) return -1;
  if (time_a > time_b) return 1;
  return 0;
};
empty_regions.sort(compare_region_age);


**Comment Punctuation**

**Fixed:** Added periods to all sentence-style comments throughout the modified files for consistency with OpenJDK style guidelines.

**ResourceMark Comment**

**Fixed:** Removed the unclear "ResourceMark rm" comment in G1HeapEvaluationTask::execute() as requested.

**GC Alloc Regions Validation**

**Fixed:** Changed abandon_gc_alloc_regions() to an assertion checking they're already abandoned, rather than doing unnecessary work.

**GCCause Assertion**

**Fixed:** Added assertion that GC cause is _no_gc when performing time-based uncommit.

**Duplicate Log Information**

**Fixed:** Consolidated log messages to avoid repeating same information at different log levels. Lower level log now contains superset of information.

**Redundant idle_count Check**

**Fixed:** Removed redundant check for `idle_count < G1MinRegionsToUncommit` that was already validated at entry condition.

**Unnecessary Validation Method**

**Fixed:** Removed unnecessary validation method since candidates are already validated when selected with is_free() check.

## Already Correct

**SuspendibleThreadSetJoiner**

You mentioned this should be in the service task, not the VM operation. The implementation was already correct - the `SuspendibleThreadSetJoiner` is in `G1HeapEvaluationTask::execute()`, which runs on the service thread. The VM operation only handles the actual uncommit at the safepoint.

**GC Coordination**

The implementation already ensures GC-based sizing takes precedence through several mechanisms:
- The evaluation only proceeds when `short_term_gc_time_ratio() < 0.05` (5%)
- Time-based uncommit respects G1's existing reserve calculation (G1ReservePercent, default 10%)
- Young generation requirements are always preserved
- The conservative reserve ensures quick re-commit isn't needed during allocation bursts

**Assertions and Validations**

The code already includes proper assertions for GC cause validation and task initialization checks as suggested. The Heap_lock assertion was updated to allow safepoint execution: `assert(Heap_lock->owner() != nullptr || SafepointSynchronize::is_at_safepoint(), ...)`.

Let me know if you have any questions about these changes or if there's anything else you'd like me to address!

Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26240#issuecomment-3679504364

From dholmes at openjdk.org  Mon Dec 22 01:30:29 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 22 Dec 2025 01:30:29 GMT
Subject: RFR: 8369515: Deadlock between JVMTI and JNI
 ReleasePrimitiveArrayCritical [v3]
In-Reply-To: <qlT_BgonQ3i1_YIAJ6cmvp7u-WBr9JEik-WAhfDDMjQ=.b011b5bc-108d-445e-ab95-92c4457465eb@github.com>
References: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
 <qlT_BgonQ3i1_YIAJ6cmvp7u-WBr9JEik-WAhfDDMjQ=.b011b5bc-108d-445e-ab95-92c4457465eb@github.com>
Message-ID: <1wh7XkntsNC-F398ebv89gGlyYSZC58blKrA-oRqb8c=.54dfaa49-e5fa-4193-b276-6784cd9b47c9@github.com>

On Fri, 19 Dec 2025 01:55:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> As discussed in JBS the deadlock occurs when the call to `ReleasePrimitiveArrayCritical` performs the transition from native to VM, and in the process checks for special runtime exit conditions - which includes the `obj_deopt_suspend` request. The simple solution is to define a custom JNI ENTRY with custom `ThreadInVMfromNative` that elides the exit check.
>> 
>> The change is limited to `ReleasePrimitiveArrayCritical` and `ReleaseStringCritical`.
>> 
>> UPDATE: we are now employing a much simpler solution.
>> 
>> There is no regression test as this has only been seen in long running stress tests.
>> 
>> Testing:
>>    -tiers 1-6
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Exapnd comment

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28779#issuecomment-3679915216

From dholmes at openjdk.org  Mon Dec 22 01:30:30 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 22 Dec 2025 01:30:30 GMT
Subject: Integrated: 8369515: Deadlock between JVMTI and JNI
 ReleasePrimitiveArrayCritical
In-Reply-To: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
References: <XQfUbGDMI2zF_aLhEHfL2McHu0j3__WxTTgNE3LEwiE=.40186578-8566-4b95-8de6-b77b966dd750@github.com>
Message-ID: <JuSyw5LOTWtpBn777i-27UO_ae0TP5H9tOG6ULDBUTc=.fcb1dc75-3c77-4b15-9e05-92b0dd33be8d@github.com>

On Fri, 12 Dec 2025 04:20:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

> As discussed in JBS the deadlock occurs when the call to `ReleasePrimitiveArrayCritical` performs the transition from native to VM, and in the process checks for special runtime exit conditions - which includes the `obj_deopt_suspend` request. The simple solution is to define a custom JNI ENTRY with custom `ThreadInVMfromNative` that elides the exit check.
> 
> The change is limited to `ReleasePrimitiveArrayCritical` and `ReleaseStringCritical`.
> 
> UPDATE: we are now employing a much simpler solution.
> 
> There is no regression test as this has only been seen in long running stress tests.
> 
> Testing:
>    -tiers 1-6

This pull request has now been integrated.

Changeset: 25e87144
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/25e87144c20fcf5aca99b92f061a0051096c2605
Stats:     5 lines in 1 file changed: 4 ins; 0 del; 1 mod

8369515: Deadlock between JVMTI and JNI ReleasePrimitiveArrayCritical

Co-authored-by: Richard Reingruber <rrich at openjdk.org>
Reviewed-by: rrich, fbredberg, pchilanomate

-------------

PR: https://git.openjdk.org/jdk/pull/28779

From dholmes at openjdk.org  Mon Dec 22 01:58:59 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 22 Dec 2025 01:58:59 GMT
Subject: RFR: 8374151: Cleanup minor markWord function disorder
In-Reply-To: <EQkEVmZecrvLvgfZYAQ-8FrPgYGJYWEbqKKPaqWD734=.3c1353da-03d2-45d7-8d61-e059a4051d3c@github.com>
References: <EQkEVmZecrvLvgfZYAQ-8FrPgYGJYWEbqKKPaqWD734=.3c1353da-03d2-45d7-8d61-e059a4051d3c@github.com>
Message-ID: <Ux_so7BlDoEDCgkyqMPCs9bt88au0zbGdFG8y1zlzDI=.7c432735-c0ca-40b1-ac72-a3585e1a333b@github.com>

On Fri, 19 Dec 2025 14:33:09 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> I propose a minor restructuring to have the hash, monitor, and displaced_marker_helper functions grouped instead of intermixed.

Seems trivially fine.

I'm assuming this will allow some incoming valhalla changes to slide in more easily.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28928#pullrequestreview-3602278188

From fyang at openjdk.org  Mon Dec 22 02:54:04 2025
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 22 Dec 2025 02:54:04 GMT
Subject: RFR: 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: <sVLZYkjSz0Achyom5_nG6yc8SoBANtrq4k0CIVt0Zds=.4db065c9-0186-420d-94f9-e91e0fc8dd8f@github.com>

On Mon, 15 Dec 2025 16:53:05 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> When a frame is OSR and the caller is interpreted we call `push_cont_fastpath` to possible set `_cont_fastpath` to the `sp` of the sender. This is needed in order to keep track of interpreted frames in the stack, so that in case of unmounting we don't incorrectly execute the freeze fast path, which is only allowed when all frames are compiled.
> 
> The problem is that the OSR frame is created starting from the `unextended_sp` of the sender, not the `sp`, i.e we pop the interpreted frame like in `remove_activation`. This means that we could set a value to `_cont_fastpath` that will point outside the valid stack (below the `sp` of the OSR frame). If the gap between these stack addresses is big enough, `_cont_fastpath` could be later cleared while we still have the interpreter sender in the stack, leading to the reported crash. The simplest case where this will happen is if in a later call to yield all the extra frames leading to `Continuation.doYield` fit within this space [[1]](https://github.com/openjdk/jdk/blob/ad29642d8f4e8e0fb1223b14b85ab7841d7b1b51/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L232). It could also be cleared before that if for example at some point we returned from an interpreted callee and the sender sp it's not below `_cont_fastpath`[[2]](https://github.com/openjdk/jdk/blob/ad29642d8f4e8e0fb1223b
 14b85ab7841d7b1b51/src/hotspot/cpu/x86/interp_masm_x86.cpp#L1060).
> 
> The fix is to change `OSR_migration_begin` to set `_cont_fastpath` with the sender's `unextended_sp` instead. 
> 
> The patch includes new test `OSRWithManyLocals.java` which reliably reproduces the crash. I thought about adding it to the existing `OSRTest.java` but that was created to exercise a different issue. A better name for that test would be `OSRWithManyArgs.java`, so I could rename it in this patch if preferred (I also realized that test could be simplified and made easier to read but that's for another PR).
> 
> I tested the current patch with the new test and also run it through mach5 tiers1-7.
> 
> Thanks,
> Patricio

LGTM. I see the issue is there on linux-riscv64 as well when running the reproducer and this fix works.

-------------

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28830#pullrequestreview-3602407270

From cjplummer at openjdk.org  Mon Dec 22 03:20:01 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 22 Dec 2025 03:20:01 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v5]
In-Reply-To: <GETEUvGGbJVVtrHmhMlz-z2mLcXQI3QzZC-qHLpfUPY=.46a85c09-eff7-4550-a294-8d55d9a26aa5@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
 <o5RfVmRlL4rk-uklwwVWo-aZr5-pi1JnSm9okRCr3V4=.b4ae7097-db7f-48c6-a704-a0d180abe2c0@github.com>
 <aeaIObD8KHYaIG3RoHEqqaDwLhSm7NqnC5TCst7F9Iw=.e163a2e8-47cf-40ca-b578-f50cbe37e2e6@github.com>
 <GETEUvGGbJVVtrHmhMlz-z2mLcXQI3QzZC-qHLpfUPY=.46a85c09-eff7-4550-a294-8d55d9a26aa5@github.com>
Message-ID: <Ei_8xC0rtD8x8VNSL_0mGZEO8rMyhaa_52xvwt2IGUo=.1d8c07f6-34ca-4fd1-871a-66411ee3aa36@github.com>

On Sat, 20 Dec 2025 04:47:44 GMT, SendaoYan <syan at openjdk.org> wrote:

>> test/hotspot/jtreg/vmTestbase/gc/gctests/LargeObjects/large001/large001.java line 154:
>> 
>>> 152: 
>>> 153:                     // Drop all references to the class and try to unload it
>>> 154:                     WhiteBox.getWhiteBox().fullGC();
>> 
>> Just to be clear, this is now no different than the `unloader.unloadClass()` call below in terms of how it is implemented. I wonder why the author originally used eatMemory() here and unloadClass() below.
>
> It seems that, the references is non null at the first time. So it will not unload the classes actually,

I understand that difference. What I meant is before it used to use eatMemory() above to attempt to force class unloading (and you are correct, there should be none) and then below it was using unloadClass(), which essentially was the same as eatMemory(). I'm not sure why two different APIs where use. I'm wondering if we should change the test to just always use WB.fullGC() both here and below where the unloadClass() call. is being made.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2638494890

From cjplummer at openjdk.org  Mon Dec 22 03:20:04 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 22 Dec 2025 03:20:04 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v8]
In-Reply-To: <DcXo_SUNshJuolC1QTuU6F18wjGhpR_k6YpRQr_EvI4=.b84a458a-f0d3-47b4-8555-e8e6eef6a2b7@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
 <DcXo_SUNshJuolC1QTuU6F18wjGhpR_k6YpRQr_EvI4=.b84a458a-f0d3-47b4-8555-e8e6eef6a2b7@github.com>
Message-ID: <zUGCtUOOO6y6JqSNcZF3st5ckbAeeR6C-b8G8Zuv2l4=.c43e6c67-73a8-4dd3-aa26-59c60013c0a4@github.com>

On Sat, 20 Dec 2025 04:59:07 GMT, SendaoYan <syan at openjdk.org> 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:
>> 
>> - [ ] All jtreg tests by fastdebug build
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update comments about "using memory stressing techique"

test/hotspot/jtreg/vmTestbase/gc/gctests/LargeObjects/large002/TestDescription.java line 52:

> 50:  *     The test loads the classes with nsk.share.gc.GCClassUnloader class that
> 51:  *     extends nsk.share. *     The test loads the classes with nsk.share.gc.GCClassUnloader class.
> 52:  *     As soon as a class is loaded, the test creates an instance of

There seems to have been a copy-n-paste error here, and it was replicated in a few test  cases below.

test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/visibleMethods/visibmethod003/TestDescription.java line 71:

> 69:  *      -transport.address=dynamic
> 70:  *      -debugee.vmkeys="${test.vm.opts} ${test.java.opts} -Xbootclasspath/a:.
> 71:  *                      -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI" ./bin

I think ./bin should be moved to a newline.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2638499254
PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2638506867

From galder at openjdk.org  Mon Dec 22 06:01:52 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Mon, 22 Dec 2025 06:01:52 GMT
Subject: RFR: 8373480: Optimize multiplication by constant multiplier using
 LEA instructions [v4]
In-Reply-To: <lmoVQLIj0BwKp21ubCgFwHx-qtplZ4Ii_Wl52Oap-SQ=.7426c1b9-528a-4a96-8762-fd20648486e0@github.com>
References: <uo_ugfdLTrURHDpmWF4Xfh2Hspum8XDJNYsUjhAEc1I=.131ef8cd-e2f3-4d8c-981c-a701452cb264@github.com>
 <lmoVQLIj0BwKp21ubCgFwHx-qtplZ4Ii_Wl52Oap-SQ=.7426c1b9-528a-4a96-8762-fd20648486e0@github.com>
Message-ID: <UZCfleLrEYnSIOGSTSo4RV7cwi6mnq8ST5mwOfI90LY=.45802782-fc63-449c-88e1-ddc74420a510@github.com>

On Tue, 16 Dec 2025 11:56:40 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Emulate multiplier using LEA addressing scheme, where effective address = BASE + INDEX * SCALE + OFFSET
>> Refer to section "3.5.1.2 Using LEA" of Intel's optimization manual for details reagarding slow vs fast lea instructions.
>> Given that latency of IMUL with register operands is 3 cycles, a combination of two fast LEAs each with 1 cycle latency to emulate multipler is performant.
>> 
>> Consider X as the multiplicand, by variying the scale of  first LEA instruction we can generate 4 input i.e.
>> 
>> 
>>     X + X * 1 = 2X
>>     X + X * 2 = 3X
>>     X + X * 4 = 5X
>>     X + X * 8 = 9X
>> 
>> 
>> Following table list downs various multiplier combinations for output of first LEA at BASE and/or INDEX by varying the 
>> scale of second fast LEA instruction. We will only handle the cases which cannot be handled by just shift + add.
>> 
>> 
>>       BASE   INDEX   SCALE  MULTIPLER
>>         X      X       1       2       (Terminal)
>>         X      X       2       3       (Terminal)
>>         X      X       4       5       (Terminal)
>>         X      X       8       9       (Terminal)
>>        3X     3X       1       6
>>         X     3X       2       7
>>        5X     5X       1      10
>>         X     5X       2      11
>>         X     3X       4      13
>>        5X     5X       2      15
>>         X     2X       8      17
>>        9X     9X       1      18
>>         X     9X       2      19
>>         X     5X       4      21
>>        5X     5X       4      25
>>        9X     9X       2      27
>>         X     9X       4      37
>>         X     5X       8      41
>>        9X     9X       4      45
>>         X     9X       8      73
>>        9X     9X       8      81
>> 
>> 
>> All the non-unity inputs tied to BASE / INDEX  are derived out of terminal cases which represent first FAST LEA. Thus, all the multipliers can be computed using just two LEA instructions.
>> 
>> Performance numbers for new micro benchmark included with this patch shows around **5-50% improvments** on latest x86 servers.
>> 
>> 
>> System: INTEL(R) XEON(R) PLATINUM 8581C CPU @ 2.10GHz Emerald Rapids:-
>> Baseline:-
>> Benchmark                                             Mode  Cnt    Score   Error    Units
>> ConstantMultiplierOptimization.testConstMultiplierI  thrpt    2  189.690          ops/min
>> ConstantMultiplierOptimization.testConstMultiplierL  thrpt    2  196.283          ops/min
>> 
>> 
>> Withopt:-
>> Benchmark                                             Mode  Cnt    Score   Error    Units
>> Constant...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor cleanup in Template-Framework test

Nice improvement @jatin-bhateja, just some small comments

Matt did an [Advent of Compiler Optimizations video](https://youtu.be/1X88od0miHs?si=wlYCsbZ1vmJA_rVf) precisely on this topic recently :)

test/hotspot/jtreg/compiler/c2/TestConstantMultiplier.java line 62:

> 60: 
> 61:         // Add a java source file.
> 62:         comp.addJavaSourceCode("c2.compilerr.ConstantMultiplierTest", generate(comp));

Suggestion:

        comp.addJavaSourceCode("c2.compiler.ConstantMultiplierTest", generate(comp));


Package name spelling mistake.

test/micro/org/openjdk/bench/vm/compiler/ConstantMultiplierOptimization.java line 46:

> 44: public class ConstantMultiplierOptimization {
> 45: 
> 46:     public static int mul_by_25_I(int a) {

Should this and other methods be annotated with `@ForceInline` just in case?

-------------

Changes requested by galder (Author).

PR Review: https://git.openjdk.org/jdk/pull/28759#pullrequestreview-3602769564
PR Review Comment: https://git.openjdk.org/jdk/pull/28759#discussion_r2638758416
PR Review Comment: https://git.openjdk.org/jdk/pull/28759#discussion_r2638761774

From syan at openjdk.org  Mon Dec 22 06:17:56 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 22 Dec 2025 06:17:56 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v8]
In-Reply-To: <zUGCtUOOO6y6JqSNcZF3st5ckbAeeR6C-b8G8Zuv2l4=.c43e6c67-73a8-4dd3-aa26-59c60013c0a4@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
 <DcXo_SUNshJuolC1QTuU6F18wjGhpR_k6YpRQr_EvI4=.b84a458a-f0d3-47b4-8555-e8e6eef6a2b7@github.com>
 <zUGCtUOOO6y6JqSNcZF3st5ckbAeeR6C-b8G8Zuv2l4=.c43e6c67-73a8-4dd3-aa26-59c60013c0a4@github.com>
Message-ID: <PMgLqFCbe7xf7VQxMi4M_K41EYlnJ9eH6VDYjYkB8y8=.cd1b8144-e4f8-4406-bad4-d4049037b20e@github.com>

On Mon, 22 Dec 2025 03:12:17 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update comments about "using memory stressing techique"
>
> test/hotspot/jtreg/vmTestbase/gc/gctests/LargeObjects/large002/TestDescription.java line 52:
> 
>> 50:  *     The test loads the classes with nsk.share.gc.GCClassUnloader class that
>> 51:  *     extends nsk.share. *     The test loads the classes with nsk.share.gc.GCClassUnloader class.
>> 52:  *     As soon as a class is loaded, the test creates an instance of
> 
> There seems to have been a copy-n-paste error here, and it was replicated in a few test  cases below.

Sorry... Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2638795405

From syan at openjdk.org  Mon Dec 22 06:41:53 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 22 Dec 2025 06:41:53 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v8]
In-Reply-To: <zUGCtUOOO6y6JqSNcZF3st5ckbAeeR6C-b8G8Zuv2l4=.c43e6c67-73a8-4dd3-aa26-59c60013c0a4@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
 <DcXo_SUNshJuolC1QTuU6F18wjGhpR_k6YpRQr_EvI4=.b84a458a-f0d3-47b4-8555-e8e6eef6a2b7@github.com>
 <zUGCtUOOO6y6JqSNcZF3st5ckbAeeR6C-b8G8Zuv2l4=.c43e6c67-73a8-4dd3-aa26-59c60013c0a4@github.com>
Message-ID: <gtjx7gozkbNfujBY24gHMCBz5s6tHRl_9vg84sqRrS4=.b2c4c92f-b52e-4f69-84d4-580466d6a206@github.com>

On Mon, 22 Dec 2025 03:16:11 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update comments about "using memory stressing techique"
>
> test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/visibleMethods/visibmethod003/TestDescription.java line 71:
> 
>> 69:  *      -transport.address=dynamic
>> 70:  *      -debugee.vmkeys="${test.vm.opts} ${test.java.opts} -Xbootclasspath/a:.
>> 71:  *                      -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI" ./bin
> 
> I think ./bin should be moved to a newline.

Fixed for all the releated tests.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2638834843

From syan at openjdk.org  Mon Dec 22 07:20:07 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 22 Dec 2025 07:20:07 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v5]
In-Reply-To: <aeaIObD8KHYaIG3RoHEqqaDwLhSm7NqnC5TCst7F9Iw=.e163a2e8-47cf-40ca-b578-f50cbe37e2e6@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
 <o5RfVmRlL4rk-uklwwVWo-aZr5-pi1JnSm9okRCr3V4=.b4ae7097-db7f-48c6-a704-a0d180abe2c0@github.com>
 <aeaIObD8KHYaIG3RoHEqqaDwLhSm7NqnC5TCst7F9Iw=.e163a2e8-47cf-40ca-b578-f50cbe37e2e6@github.com>
Message-ID: <KzdEMOyPWPlRGoxYFjYzHiFA0Vqne3SxvjOOlwvAB10=.3be05771-98d9-45fa-99ed-c540e98764b8@github.com>

On Fri, 19 Dec 2025 18:11:10 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Increase max iteration for nsk/jvmti/CompiledMethodUnload/compmethunload001/TestDescription.java
>
> test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java line 50:
> 
>> 48:         "nsk.jvmti.CompiledMethodUnload.compmethunload001u";
>> 49: 
>> 50:     private final static int MAX_ITERATIONS = 50;
> 
> Can you explain the need for this change.

Test nsk/jvmti/CompiledMethodUnload/compmethunload001/TestDescription.java always fails after this PR with the default value `MAX_ITERATIONS = 5`.

After I change the value of MAX_ITERATIONS to 50, The test always passed, and the test log shows that the number of unloaded enents is different every time.


Number of unloaded events 12 number of iterations 25
Number of unloaded events 1 number of iterations 36
Number of unloaded events 4 number of iterations 30


Before this PR, test call eatMemory to trigger full GC, this may need lots time. After this PR, test call `WhiteBox.getWhiteBox().fullGC()` to trigger full GC, this may be finish quickly.

This test get the unload event count through jni function, the unload event count was recorded by C++ `volatile` variable `class_unloaded`. It's not synchronized. So I think it's reasonable to increase the max count to catch the `volatile` variable change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2638907204

From jbhateja at openjdk.org  Mon Dec 22 07:23:51 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 22 Dec 2025 07:23:51 GMT
Subject: RFR: 8373480: Optimize multiplication by constant multiplier using
 LEA instructions [v5]
In-Reply-To: <uo_ugfdLTrURHDpmWF4Xfh2Hspum8XDJNYsUjhAEc1I=.131ef8cd-e2f3-4d8c-981c-a701452cb264@github.com>
References: <uo_ugfdLTrURHDpmWF4Xfh2Hspum8XDJNYsUjhAEc1I=.131ef8cd-e2f3-4d8c-981c-a701452cb264@github.com>
Message-ID: <u6a8eMBpPAEynajktzZ3p8DSsCf6cMBXpjqmb81C2wA=.78f98211-81a4-4f65-a2c7-9ddc36fdf5d1@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 incrementally with one additional commit since the last revision:

  Review comments resolutions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28759/files
  - new: https://git.openjdk.org/jdk/pull/28759/files/66a28502..8e42a466

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28759&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28759&range=03-04

  Stats: 17 lines in 2 files changed: 13 ins; 3 del; 1 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  Mon Dec 22 07:28:06 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 22 Dec 2025 07:28:06 GMT
Subject: RFR: 8373480: Optimize multiplication by constant multiplier using
 LEA instructions [v4]
In-Reply-To: <UZCfleLrEYnSIOGSTSo4RV7cwi6mnq8ST5mwOfI90LY=.45802782-fc63-449c-88e1-ddc74420a510@github.com>
References: <uo_ugfdLTrURHDpmWF4Xfh2Hspum8XDJNYsUjhAEc1I=.131ef8cd-e2f3-4d8c-981c-a701452cb264@github.com>
 <lmoVQLIj0BwKp21ubCgFwHx-qtplZ4Ii_Wl52Oap-SQ=.7426c1b9-528a-4a96-8762-fd20648486e0@github.com>
 <UZCfleLrEYnSIOGSTSo4RV7cwi6mnq8ST5mwOfI90LY=.45802782-fc63-449c-88e1-ddc74420a510@github.com>
Message-ID: <IL5eRioEaSzm-EG-QRZnj8pYgMLdjYZhfKTqDyMr4hI=.4fee0a31-ec4c-4bac-a425-20857dffdf61@github.com>

On Mon, 22 Dec 2025 05:59:14 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

> Nice improvement @jatin-bhateja, just some small comments
> 
> Matt did an [Advent of Compiler Optimizations video](https://youtu.be/1X88od0miHs?si=wlYCsbZ1vmJA_rVf) precisely on this topic recently :)

Hi @galderz , Exaclty, JBS description clearly mentions that.

> test/micro/org/openjdk/bench/vm/compiler/ConstantMultiplierOptimization.java line 46:
> 
>> 44: public class ConstantMultiplierOptimization {
>> 45: 
>> 46:     public static int mul_by_25_I(int a) {
> 
> Should this and other methods be annotated with `@ForceInline` just in case?

Kernels are too small and should be inlined, but its better to force inlining, made that change, benchmark performance remains same.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28759#issuecomment-3680823623
PR Review Comment: https://git.openjdk.org/jdk/pull/28759#discussion_r2638921837

From chagedorn at openjdk.org  Mon Dec 22 07:33:57 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 22 Dec 2025 07:33:57 GMT
Subject: RFR: 8373343: C2: verify AddP base input only set for heap
 addresses [v3]
In-Reply-To: <kQMfKDd-5lJ-I3rXLgC2Y_u6lPAMUd_wSpf32HWcZ2s=.e93eda67-479a-44ed-821a-5b122daf062b@github.com>
References: <fdm8TK_FBJheQ_Wkd_KobosU0uTioUuRZhIK38I3Q-g=.8ae8e498-9c14-4cae-8e68-4c39914a8195@github.com>
 <kQMfKDd-5lJ-I3rXLgC2Y_u6lPAMUd_wSpf32HWcZ2s=.e93eda67-479a-44ed-821a-5b122daf062b@github.com>
Message-ID: <lFYFZQbpc_c9pEewnw47E8ju-Rqe3pE-wYu66bgnryA=.04f449cc-f02d-40ea-a855-a3c484f59784@github.com>

On Fri, 19 Dec 2025 13:15:38 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> The base input of `AddP` is expected to only be set for heap accesses
>> but I noticed some inconsistencies so I added an assert in the `AddP`
>> constructor and fixed issues that it caught. AFAFICT, the
>> inconsistencies shouldn't create issues.
>
> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Good improvement! I have two more suggestions but these could also be done separately.

src/hotspot/share/opto/graphKit.cpp line 2737:

> 2735: 
> 2736:   // First load the super-klass's check-offset
> 2737:   Node *p1 = gvn.transform(new AddPNode(C->top(), superklass, gvn.MakeConX(in_bytes(Klass::super_check_offset_offset()))));

Would it make sense to have 2 constructors or even better 2 `make()` methods with dedicated names instead of passing in top each time?

For example:

make_with_base(Node* base, Node* ptr, Node* offset)
make_off_heap(Node* ptr, Node* offset)

`make_off_heap()` can then call `make_with_base(Compile::current()->top, ptr, offset)`

src/hotspot/share/opto/graphKit.cpp line 2755:

> 2753:   chk_off_X = gvn.transform(new ConvI2LNode(chk_off_X));
> 2754: #endif
> 2755:   Node *p2 = gvn.transform(new AddPNode(C->top(),subklass,chk_off_X));

Suggestion:

  Node* p2 = gvn.transform(new AddPNode(C->top(), subklass, chk_off_X));

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.

-------------

Marked as reviewed by chagedorn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28769#pullrequestreview-3602937227
PR Review Comment: https://git.openjdk.org/jdk/pull/28769#discussion_r2638913566
PR Review Comment: https://git.openjdk.org/jdk/pull/28769#discussion_r2638921027
PR Review Comment: https://git.openjdk.org/jdk/pull/28769#discussion_r2638920830

From kbarrett at openjdk.org  Mon Dec 22 07:38:24 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 22 Dec 2025 07:38:24 GMT
Subject: RFR: 8374190: Convert ConcurrentHashTable atomic lists to use
 Atomic<T>
Message-ID: <AF4ZUl0ny2Mzk2XrJiWpUPvv63oubznivKfrGgbyz20=.a1c8a867-1f21-4ff9-b76b-91c456a126b8@github.com>

Please review this change to ConcurrentHashTable to use `Atomic<Node*>` for
the Node lists.  Note that this does not complete the replacement of direct
uses of AtomicAccess by that class; there's still one more group remaining.

Testing: mach5 tier1-3

-------------

Commit messages:
 - atomic _first & _next

Changes: https://git.openjdk.org/jdk/pull/28951/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28951&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374190
  Stats: 40 lines in 2 files changed: 12 ins; 0 del; 28 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 syan at openjdk.org  Mon Dec 22 08:46:55 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 22 Dec 2025 08:46:55 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v5]
In-Reply-To: <KzdEMOyPWPlRGoxYFjYzHiFA0Vqne3SxvjOOlwvAB10=.3be05771-98d9-45fa-99ed-c540e98764b8@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
 <o5RfVmRlL4rk-uklwwVWo-aZr5-pi1JnSm9okRCr3V4=.b4ae7097-db7f-48c6-a704-a0d180abe2c0@github.com>
 <aeaIObD8KHYaIG3RoHEqqaDwLhSm7NqnC5TCst7F9Iw=.e163a2e8-47cf-40ca-b578-f50cbe37e2e6@github.com>
 <KzdEMOyPWPlRGoxYFjYzHiFA0Vqne3SxvjOOlwvAB10=.3be05771-98d9-45fa-99ed-c540e98764b8@github.com>
Message-ID: <pXJtgsOmcDL1mfvYYCuTiQMdrY0IhnR5Sr4rSjuazI8=.afa116de-109c-4fcf-9456-7a68fd40b35a@github.com>

On Mon, 22 Dec 2025 07:16:49 GMT, SendaoYan <syan at openjdk.org> wrote:

>> test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java line 50:
>> 
>>> 48:         "nsk.jvmti.CompiledMethodUnload.compmethunload001u";
>>> 49: 
>>> 50:     private final static int MAX_ITERATIONS = 50;
>> 
>> Can you explain the need for this change.
>
> Test nsk/jvmti/CompiledMethodUnload/compmethunload001/TestDescription.java always fails after this PR with the default value `MAX_ITERATIONS = 5`.
> 
> After I change the value of MAX_ITERATIONS to 50, The test always passed, and the test log shows that the number of unloaded enents is different every time.
> 
> 
> Number of unloaded events 12 number of iterations 25
> Number of unloaded events 1 number of iterations 36
> Number of unloaded events 4 number of iterations 30
> 
> 
> Before this PR, test call eatMemory to trigger full GC, this may need lots time. After this PR, test call `WhiteBox.getWhiteBox().fullGC()` to trigger full GC, this may be finish quickly.
> 
> This test get the unload event count through jni function, the unload event count was recorded by C++ `volatile` variable `class_unloaded`. It's not synchronized. So I think it's reasonable to increase the max count to catch the `volatile` variable change.

Another solution is make some sleep after call `unloadClass()`


diff --git a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java
index 13058ec7864..15120d3cad6 100644
--- a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java
+++ b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java
@@ -47,7 +47,7 @@ public class compmethunload001 {
     private final static String CLS_TO_BE_UNLOADED =
         "nsk.jvmti.CompiledMethodUnload.compmethunload001u";
 
-    private final static int MAX_ITERATIONS = 50;
+    private final static int MAX_ITERATIONS = 5;
 
     static {
         try {
@@ -95,6 +95,7 @@ public static void callHotClass(String location) throws Exception {
 
         boolean clsUnloaded = clsUnLoader.unloadClass();
         clsUnLoader = null;
+        Thread.sleep(5000);
         System.gc();
     }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2639101290

From stefank at openjdk.org  Mon Dec 22 09:28:00 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 22 Dec 2025 09:28:00 GMT
Subject: RFR: 8374151: Cleanup minor markWord function disorder
In-Reply-To: <Ux_so7BlDoEDCgkyqMPCs9bt88au0zbGdFG8y1zlzDI=.7c432735-c0ca-40b1-ac72-a3585e1a333b@github.com>
References: <EQkEVmZecrvLvgfZYAQ-8FrPgYGJYWEbqKKPaqWD734=.3c1353da-03d2-45d7-8d61-e059a4051d3c@github.com>
 <Ux_so7BlDoEDCgkyqMPCs9bt88au0zbGdFG8y1zlzDI=.7c432735-c0ca-40b1-ac72-a3585e1a333b@github.com>
Message-ID: <HwrrnKBPOBjzZKMBRr49p5PFTfHvHpgEcnjVV7YwFyg=.ef339b8e-6bd5-448c-98d6-824b94ee7497@github.com>

On Mon, 22 Dec 2025 01:56:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I'm assuming this will allow some incoming valhalla changes to slide in more easily.

Maybe only marginally. The removal in #28927 clarifies an assumption in the Valhalla code that I was reviewing. And while discussing other cleanups to the markWord code in Valhalla, I noticed that markWord file could probably benefit from a clearer grouping of the existing function. So, this change isn't strictly necessary, but I do think it aids the readability of the file.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28928#issuecomment-3681193507

From stefank at openjdk.org  Mon Dec 22 09:28:01 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 22 Dec 2025 09:28:01 GMT
Subject: RFR: 8374151: Cleanup minor markWord function disorder
In-Reply-To: <EQkEVmZecrvLvgfZYAQ-8FrPgYGJYWEbqKKPaqWD734=.3c1353da-03d2-45d7-8d61-e059a4051d3c@github.com>
References: <EQkEVmZecrvLvgfZYAQ-8FrPgYGJYWEbqKKPaqWD734=.3c1353da-03d2-45d7-8d61-e059a4051d3c@github.com>
Message-ID: <MgX53J75N01H42FxKs7Bd4YBiPH3aveUh8uGftY1cQE=.da1c4e39-8aea-4c4f-bb97-cd5ea2ba91cc@github.com>

On Fri, 19 Dec 2025 14:33:09 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> I propose a minor restructuring to have the hash, monitor, and displaced_marker_helper functions grouped instead of intermixed.

Thanks for reviewing!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28928#issuecomment-3681194162

From stefank at openjdk.org  Mon Dec 22 09:35:12 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 22 Dec 2025 09:35:12 GMT
Subject: RFR: 8374145: Remove legacy locking remnants from markWord
In-Reply-To: <4yUGXErqsnP6fbNf5jqqZe5oZL1rtf8YFEAwnlDVFRs=.0609c860-7f4f-4da7-897e-3929499e2a87@github.com>
References: <4yUGXErqsnP6fbNf5jqqZe5oZL1rtf8YFEAwnlDVFRs=.0609c860-7f4f-4da7-897e-3929499e2a87@github.com>
Message-ID: <iMmxvkhUYDnVRuxzKW9uiZNKj0Co7OGR2oXpcefTVnk=.d5b5c55a-c941-4368-81cd-d7755cdea29e@github.com>

On Fri, 19 Dec 2025 14:05:13 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> There's a bunch of unused code in markWord that used to be used by the removed legacy locking. I propose that we remove it.
> 
> There's a Shenandoah change that should be checked closer. My thinking is:
>  `is_being_inflated`: always returns false
>  `has_displaced_mark_helper`: Only returns true if both these are true:
>    * `!UseCompactObjectTable` - there's an early return for this earlier in the function.
>    * `lockbits == monitor_value` - checked in the if-statement above

Thanks for the reviews!

-------------

PR Review: https://git.openjdk.org/jdk/pull/28927#pullrequestreview-3603327790

From stefank at openjdk.org  Mon Dec 22 09:35:13 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 22 Dec 2025 09:35:13 GMT
Subject: RFR: 8374145: Remove legacy locking remnants from markWord
In-Reply-To: <MWTSeft3RYpBQ7ja-bVWkQjlRR7LOyo1Q0deHXt1FsU=.e0c7a21f-f466-4d05-a14b-e614e448e8aa@github.com>
References: <4yUGXErqsnP6fbNf5jqqZe5oZL1rtf8YFEAwnlDVFRs=.0609c860-7f4f-4da7-897e-3929499e2a87@github.com>
 <2Xbj1QOxPiOM5_e4mNuEbQpn2VFxwJ19xXpBnAy2_T8=.7d5d7174-3a37-464b-a25c-f89d7a5028f5@github.com>
 <MWTSeft3RYpBQ7ja-bVWkQjlRR7LOyo1Q0deHXt1FsU=.e0c7a21f-f466-4d05-a14b-e614e448e8aa@github.com>
Message-ID: <2bKOJuGLuOye4emeXOSMwPqjWF0fBShko2UYWutYwxo=.f9f0240b-2d7c-4a3b-bd15-5e1ea16ed124@github.com>

On Fri, 19 Dec 2025 14:16:25 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp line 349:
>> 
>>> 347:   } else if (w.is_being_inflated() || w.has_displaced_mark_helper()) {
>>> 348:     // Informs caller that we aren't able to determine the age
>>> 349:     return markWord::max_age + 1; // sentinel
>> 
>> Not sure if we want an `!w.has_displaced_mark_helper()` assert. Even if we already check  for (and handled) the exact conditions (in the current implementation) for `has_displaced_mark_helper()`.
>
> That would work for me. I'll wait for input from the Shenandoah devs.

In the interest to get this integrated I've created an Enh for this:
https://bugs.openjdk.org/browse/JDK-8374191

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28927#discussion_r2639248718

From stefank at openjdk.org  Mon Dec 22 09:35:14 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 22 Dec 2025 09:35:14 GMT
Subject: Integrated: 8374145: Remove legacy locking remnants from markWord
In-Reply-To: <4yUGXErqsnP6fbNf5jqqZe5oZL1rtf8YFEAwnlDVFRs=.0609c860-7f4f-4da7-897e-3929499e2a87@github.com>
References: <4yUGXErqsnP6fbNf5jqqZe5oZL1rtf8YFEAwnlDVFRs=.0609c860-7f4f-4da7-897e-3929499e2a87@github.com>
Message-ID: <DbjA7FIM3Es3XLek5GJaxxuU4GR4SdkFrYX36vDEA9k=.0fddef34-6b9e-4209-92f1-c1c4f6951d88@github.com>

On Fri, 19 Dec 2025 14:05:13 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> There's a bunch of unused code in markWord that used to be used by the removed legacy locking. I propose that we remove it.
> 
> There's a Shenandoah change that should be checked closer. My thinking is:
>  `is_being_inflated`: always returns false
>  `has_displaced_mark_helper`: Only returns true if both these are true:
>    * `!UseCompactObjectTable` - there's an early return for this earlier in the function.
>    * `lockbits == monitor_value` - checked in the if-statement above

This pull request has now been integrated.

Changeset: e6c3ebe2
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e6c3ebe27b0dd4cbf1885d79ea50acb208e364fa
Stats:     33 lines in 2 files changed: 0 ins; 32 del; 1 mod

8374145: Remove legacy locking remnants from markWord

Reviewed-by: aboldtch, kbarrett, coleenp

-------------

PR: https://git.openjdk.org/jdk/pull/28927

From stefank at openjdk.org  Mon Dec 22 09:42:37 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 22 Dec 2025 09:42:37 GMT
Subject: RFR: 8374151: Cleanup minor markWord function disorder [v2]
In-Reply-To: <EQkEVmZecrvLvgfZYAQ-8FrPgYGJYWEbqKKPaqWD734=.3c1353da-03d2-45d7-8d61-e059a4051d3c@github.com>
References: <EQkEVmZecrvLvgfZYAQ-8FrPgYGJYWEbqKKPaqWD734=.3c1353da-03d2-45d7-8d61-e059a4051d3c@github.com>
Message-ID: <Z0eywF3LT8JudN8-lb_EMhDDb6nSJRIuEq_Bd1GR5fY=.b3add227-642d-43a5-b78b-31488cdabac1@github.com>

> I propose a minor restructuring to have the hash, monitor, and displaced_marker_helper functions grouped instead of intermixed.

Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28928/files
  - new: https://git.openjdk.org/jdk/pull/28928/files/21a499b1..21a499b1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28928&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28928&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28928.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28928/head:pull/28928

PR: https://git.openjdk.org/jdk/pull/28928

From stefank at openjdk.org  Mon Dec 22 09:54:09 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 22 Dec 2025 09:54:09 GMT
Subject: RFR: 8374151: Cleanup minor markWord function disorder [v3]
In-Reply-To: <EQkEVmZecrvLvgfZYAQ-8FrPgYGJYWEbqKKPaqWD734=.3c1353da-03d2-45d7-8d61-e059a4051d3c@github.com>
References: <EQkEVmZecrvLvgfZYAQ-8FrPgYGJYWEbqKKPaqWD734=.3c1353da-03d2-45d7-8d61-e059a4051d3c@github.com>
Message-ID: <CZ8TPYvBjelAwcdMzgkaXaMOh6GBsAtupsV6CkzfrLI=.71208359-2e71-42a3-954b-c8156423c8ed@github.com>

> I propose a minor restructuring to have the hash, monitor, and displaced_marker_helper functions grouped instead of intermixed.

Stefan Karlsson 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 'upstream/master' into 8374151_markword_discorder
 - 8374151: Cleanup minor markWord function disorder
 - 8374145: Remove legacy locking remnants from markWord

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28928/files
  - new: https://git.openjdk.org/jdk/pull/28928/files/21a499b1..70c9d633

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28928&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28928&range=01-02

  Stats: 2521 lines in 122 files changed: 1397 ins; 479 del; 645 mod
  Patch: https://git.openjdk.org/jdk/pull/28928.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28928/head:pull/28928

PR: https://git.openjdk.org/jdk/pull/28928

From rcastanedalo at openjdk.org  Mon Dec 22 10:09:50 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 22 Dec 2025 10:09:50 GMT
Subject: RFR: 8374151: Cleanup minor markWord function disorder [v3]
In-Reply-To: <CZ8TPYvBjelAwcdMzgkaXaMOh6GBsAtupsV6CkzfrLI=.71208359-2e71-42a3-954b-c8156423c8ed@github.com>
References: <EQkEVmZecrvLvgfZYAQ-8FrPgYGJYWEbqKKPaqWD734=.3c1353da-03d2-45d7-8d61-e059a4051d3c@github.com>
 <CZ8TPYvBjelAwcdMzgkaXaMOh6GBsAtupsV6CkzfrLI=.71208359-2e71-42a3-954b-c8156423c8ed@github.com>
Message-ID: <S4i-xR7pDmVD8mAODpSyPCX_ycEe8aInKgN8cYPuHEM=.1bc4323c-2128-45f9-840f-71290bb098f2@github.com>

On Mon, 22 Dec 2025 09:54:09 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I propose a minor restructuring to have the hash, monitor, and displaced_marker_helper functions grouped instead of intermixed.
>
> Stefan Karlsson 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 'upstream/master' into 8374151_markword_discorder
>  - 8374151: Cleanup minor markWord function disorder
>  - 8374145: Remove legacy locking remnants from markWord

Looks good, and trivial.

-------------

Marked as reviewed by rcastanedalo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28928#pullrequestreview-3603446559

From stefank at openjdk.org  Mon Dec 22 10:19:04 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 22 Dec 2025 10:19:04 GMT
Subject: RFR: 8374151: Cleanup minor markWord function disorder [v3]
In-Reply-To: <CZ8TPYvBjelAwcdMzgkaXaMOh6GBsAtupsV6CkzfrLI=.71208359-2e71-42a3-954b-c8156423c8ed@github.com>
References: <EQkEVmZecrvLvgfZYAQ-8FrPgYGJYWEbqKKPaqWD734=.3c1353da-03d2-45d7-8d61-e059a4051d3c@github.com>
 <CZ8TPYvBjelAwcdMzgkaXaMOh6GBsAtupsV6CkzfrLI=.71208359-2e71-42a3-954b-c8156423c8ed@github.com>
Message-ID: <ecK5qT0utLRG5RIGLD7LHgxSMzVUpB72afPTMRb7w3o=.d6672168-f1a6-4744-9f9c-9d87e9fcc733@github.com>

On Mon, 22 Dec 2025 09:54:09 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I propose a minor restructuring to have the hash, monitor, and displaced_marker_helper functions grouped instead of intermixed.
>
> Stefan Karlsson 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 'upstream/master' into 8374151_markword_discorder
>  - 8374151: Cleanup minor markWord function disorder
>  - 8374145: Remove legacy locking remnants from markWord

Thanks for re-reviewing!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28928#issuecomment-3681379907

From stefank at openjdk.org  Mon Dec 22 10:19:06 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 22 Dec 2025 10:19:06 GMT
Subject: Integrated: 8374151: Cleanup minor markWord function disorder
In-Reply-To: <EQkEVmZecrvLvgfZYAQ-8FrPgYGJYWEbqKKPaqWD734=.3c1353da-03d2-45d7-8d61-e059a4051d3c@github.com>
References: <EQkEVmZecrvLvgfZYAQ-8FrPgYGJYWEbqKKPaqWD734=.3c1353da-03d2-45d7-8d61-e059a4051d3c@github.com>
Message-ID: <yKdV2X2fTKOXdoxLyTl390LKIFn3lDecoraNngQgn2g=.ff3858dc-f3b7-4360-82b9-683c5ae83756@github.com>

On Fri, 19 Dec 2025 14:33:09 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> I propose a minor restructuring to have the hash, monitor, and displaced_marker_helper functions grouped instead of intermixed.

This pull request has now been integrated.

Changeset: 2715f5e6
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2715f5e698b49cd67faa233a3188e6a69ddb80c0
Stats:     25 lines in 1 file changed: 12 ins; 11 del; 2 mod

8374151: Cleanup minor markWord function disorder

Reviewed-by: rcastanedalo, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/28928

From jbhateja at openjdk.org  Mon Dec 22 12:09:01 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 22 Dec 2025 12:09:01 GMT
Subject: RFR: 8373480: Optimize multiplication by constant multiplier using
 LEA instructions [v6]
In-Reply-To: <uo_ugfdLTrURHDpmWF4Xfh2Hspum8XDJNYsUjhAEc1I=.131ef8cd-e2f3-4d8c-981c-a701452cb264@github.com>
References: <uo_ugfdLTrURHDpmWF4Xfh2Hspum8XDJNYsUjhAEc1I=.131ef8cd-e2f3-4d8c-981c-a701452cb264@github.com>
Message-ID: <vTZKK9fSVJPpo0sIXV1s-2hRvTOSLt78JbB3PYxiQNk=.f790a1d3-a515-4544-a304-85d80f20a927@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 incrementally with one additional commit since the last revision:

  Extending micro and jtreg tests for memory patterns

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28759/files
  - new: https://git.openjdk.org/jdk/pull/28759/files/8e42a466..b7756730

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28759&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28759&range=04-05

  Stats: 154 lines in 5 files changed: 142 ins; 0 del; 12 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 bkilambi at openjdk.org  Mon Dec 22 15:20:11 2025
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Mon, 22 Dec 2025 15:20:11 GMT
Subject: RFR: 8373794: Move nmethod header from CodeCache
In-Reply-To: <uFs9gKNiVGN4nWJYMRT0WGOf7IFQYBANAuYmIO59A1w=.326f8390-6936-40ed-85fc-98e3a722053f@github.com>
References: <RZYpT82maT4ayWODxISztNMAQwPOqilJsmjTtfZA9X4=.5953f303-ddb7-4f1e-ab27-e5b3ccaa039f@github.com>
 <LAFydlD8_MzjwVnLzuGb6ICtSxWqSPsguQSM6lynUmA=.f71c0b41-948f-403d-8670-beeee6d6f9a9@github.com>
 <uFs9gKNiVGN4nWJYMRT0WGOf7IFQYBANAuYmIO59A1w=.326f8390-6936-40ed-85fc-98e3a722053f@github.com>
Message-ID: <b5vqBo9KDHIe4eCV87exNY2qzQvJEKKPQC5fnU2YL3M=.2295bcbb-8830-4c6c-835c-a3ab39720690@github.com>

On Thu, 18 Dec 2025 17:15:35 GMT, Mikhail Ablakatov <mablakatov at openjdk.org> wrote:

> > Wouldn't it be better to move the whole CodeBlob header out of the code cache? Instead of nmethod having a _hdr pointer, CodeBlob would be in malloc space and have a _code pointer into the CodeCache.
> 
> It might be possible to move both `CodeBlob` and `nmethod` data to the C-heap. We'd still need something like an `_hdr` pointer, since JVM resolves a `CodeBlob` from a method/stub entry point using [`CodeBlob* CodeCache::find_blob(void* start)`](https://github.com/openjdk/jdk/blob/7a7e7c9ae11cb124c14d5d2d3b7e2f5649205106/src/hotspot/share/code/codeCache.cpp#L640). So if we move every member field to the C-heap, we store a pointer to that data right before a method/stub entry point in the CodeCache and that's it. A `_code` pointer pointing from the C-heap into the CodeCache may not be necessary at all.
> 
> That said, this would require moving data for other `CodeBlob` subclasses (`AdapterBlob`, `ExceptionBlob`, etc.) to the C-heap, which would significantly broaden the scope of this patch.
> 
> @Bhavana-Kilambi , what do you thing? Is this something you've considered?


That could be feasible, we might need to store two pointers - 
1. An off-heap `CodeBlob` field - `_code` pointing to the start of its CodeHeap block. Boundary accessors in `CodeBlob` like `code_begin()`, `code_end()`, `data_begin()` etc would derive from this pointer
2. A tiny back-pointer at the start of each `CodeHeap` block that holds  the owning `CodeBlob*`. This might be needed by `CodeCache::find_blob(void* start)` to return the off-heap `CodeBlob*`

However, I do agree with @mikabl-arm that this significantly broadens the scope of this patch. Moving the entire `CodeBlob` object out of the CodeCache touches every blob subtype, SA, any code that walks/iterates through all blobs in the code cache etc. From what we have observed, a considerable part of the `CodeCache` is occupied mainly by the non-profiled and profiled nmethods. Thus, the goal of this patch is to reduce the footprint of the nmethod object first (to make them as compact as possible), without changing the global lookup paths. Would it be okay for us to keep the current scope of this patch to move the nmethod header to off-heap memory and maybe create a new RFE to explore moving CodeBlob header to off-heap memory?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28866#issuecomment-3682508777

From fgao at openjdk.org  Mon Dec 22 18:02:59 2025
From: fgao at openjdk.org (Fei Gao)
Date: Mon, 22 Dec 2025 18:02:59 GMT
Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() [v6]
In-Reply-To: <2-SaowCI03bZE2PdHEwG7LPwbIRnFwQ7oMRS58kchXg=.a36c6bcd-0e38-4ba1-97aa-a0cfdc66ef86@github.com>
References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com>
 <CEvEqPtlTMiv7fX1G_spyCpyl8afEZn4McrzIBd5GRY=.d233254e-3626-4044-a3e1-c82bcbd55e45@github.com>
 <6E4yPY9dRcWGBT-vPPq7bOm1NfLdvIfLdecg34f6Tes=.11b0a7c1-798f-4ed2-a521-26059bc0ba5b@github.com>
 <yRkEv29KF1vLIy4V5nKDgQF7CfvVjUjfssdzZ0PccjA=.00171af8-a1aa-401b-9341-a80a6fb4e22e@github.com>
 <yhtSX7dHSCAnDVCm5UX_9Pfx0-P3FnydZOAbRt7-6Ow=.253c5dbb-c7d1-4543-94cc-cbd1a05d5c0e@github.com>
 <TEoePwnDJIw1BQ6kk9-9ggawyVL3luz0rgDALvnN-5Q=.0dfa7cd9-3298-49a7-965d-01d4365986c0@github.com>
 <nPgiY87FhQoQ-hUDy5bDG7ufXdef2vfN17mZjI6FyYc=.21999f30-4ede-49ff-b6f6-fd36ca530992@github.com>
 <DuyupqIerQYS62xHWrLNIVvgmg6ehbgNkZtL2N02_HI=.f1d96b9e-425e-417d-b122-5cef558027e9@github.com>
 <cHbuIgpwzbNOERsbubuipYsFPkqaBwAJIVvZhNLSdos=.8844631c-6f63-4a45-ae8a-a5e8523e47df@github.com>
 <2-SaowCI03bZE2PdHEwG7LPwbIRnFwQ7oMRS58kchXg=.a36c6bcd-0e38-4ba1-97aa-a0cfdc66ef86@github.com>
Message-ID: <nuYvD6GFgFQ8U4LWEQ_NYkTYpclNhXI79EwwwMpQuLo=.f77a7b69-64ae-46b1-a054-7e0609c74894@github.com>

On Wed, 17 Dec 2025 18:17:57 GMT, Andrew Haley <aph at openjdk.org> wrote:

>>> 
>>> That visibility is not guaranteed. A `B .+4` already exists because the static stub has already been patched. We then rewrite the static stub because the destination method moved.
>> 
>> I see. Thanks for your explanation!
>> 
>>> What about a 3rd thread that sees the call site already resolved so never calls the resolve helper? It won't execute an ISB either. I thought the ISB was only needed to see changes to the stub, not the call site.
>> 
>> Assume the following race:
>> - One thread has already entered the resolver and started patching, but has not yet completed.
>> - Another thread has **not** observed the updated call site, but **has** observed the patched trampoline stub and therefore reaches the static call stub directly via the trampoline stub.
>> 
>> In this case, the second thread will not execute the resolver. An ISB in `CompiledICLocker::~CompiledICLocker()` would not address this scenario, because the second thread never goes through the resolver path and therefore never executes that ISB. As a result, the second thread may execute stale MOV instructions in the static call stub. Would that be a problem? I?m not sure whether this is what @dean-long had in mind.
>
>> Assume the following race:
>> 
>>     * One thread has already entered the resolver and started patching, but has not yet completed.
>> 
>>     * Another thread has **not** observed the updated call site, but **has** observed the patched trampoline stub and therefore reaches the static call stub directly via the trampoline stub.
> 
> OK.
> 
>> In this case, the second thread will not execute the resolver. An ISB in `CompiledICLocker::~CompiledICLocker()` would not address this scenario, because the second thread never goes through the resolver path and therefore never executes that ISB. As a result, the second thread may execute stale MOV instructions in the static call stub. Would that be a problem? 
> 
> I don't think that's possible, because rewriting when a class gets redefined only happens at a safepoint. So I think we're OK, probably.

Thanks for your answers! @theRealAph @dean-long 

> Actually, that scenario does seem possible. Consider:
> 
> 1. Call site points to trampoline
> 2. Thread 1 hits call site and enters trampoline, then gets rescheduled
> 3. Something causes a re-resolve and the call site to be reset to the resolve stub
> 4. Thread 2 hits the call site and eventually calls set_to_interpreted, updating stub, trampoline, and call site
> 
> Depending on when Thread 1 resumes, I believe Thread 1 can see any of the following:
> 
> 1. old destination
> 2. stub destination with ISB + MOVs
> 3. stub destination with B + MOVs

For the case **without** class redefinition, patching performed by Thread 2 are limited to the following:

1. ISB + initial MOVs ? B + patched MOVs
2. B + patched MOVs ? B + patched MOVs (rewriting with **the same** values)

In either case, Thread 1 should always observe a valid set of MOV instructions, so these transitions appear safe.

**With** class redefinition, however, an additional patching becomes possible:

3. B + patched MOVs ? B + patched MOVs (rewriting with **different** values)

At that point, such patching by Thread 2 could potentially expose stale or partially updated MOV instructions to Thread 1. The key question, then, is **whether the race between Thread 1 and Thread 2 can coincide with class redefinition**.

> I don't think that's possible, because rewriting when a class gets redefined only happens at a safepoint. So I think we're OK, probably.

If patching the static call stub after class redefinition can only occur at a safepoint, then I would expect this race not to be possible, since there is no safepoint between executing the call site and entering the trampoline.

AFAIU, when a class is redefined, affected compiled callers are [marked not entrant](https://github.com/openjdk/jdk/blob/9715e6da8355a103d9066bd15ce68b4773cbadcb/src/hotspot/share/prims/jvmtiRedefineClasses.cpp#L278), and call sites are effectively [reset to go through the resolve stub](https://github.com/openjdk/jdk/blob/9715e6da8355a103d9066bd15ce68b4773cbadcb/src/hotspot/share/prims/jvmtiRedefineClasses.cpp#L218). What I have not been able to identify is **where the static call stub itself is patched as part of class redefinition**. I would really appreciate it if someone could point me to the relevant code path. 

If the static stub is **not** patched during class redefinition itself, then:

- after class redefinition completes and safepoints are exited,
- new threads are prevented from entering the caller because it is not entrant,
- but threads already executing inside the caller continue running, those threads may reach the resolve path and patch the static call stub outside of a safepoint.

If this understanding is incorrect, please let me know?I?d be happy to be corrected. Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26638#issuecomment-3683214894

From fgao at openjdk.org  Mon Dec 22 18:10:57 2025
From: fgao at openjdk.org (Fei Gao)
Date: Mon, 22 Dec 2025 18:10:57 GMT
Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() [v6]
In-Reply-To: <tHF-qeZ12J1_ANlTDHCsqN4E5-_gKLLV6_glEWKBnS4=.967f4651-110b-4093-8982-c4e64081841c@github.com>
References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com>
 <CEvEqPtlTMiv7fX1G_spyCpyl8afEZn4McrzIBd5GRY=.d233254e-3626-4044-a3e1-c82bcbd55e45@github.com>
 <tHF-qeZ12J1_ANlTDHCsqN4E5-_gKLLV6_glEWKBnS4=.967f4651-110b-4093-8982-c4e64081841c@github.com>
Message-ID: <z1QuX6NjaqF-Jv0gtN8CslxJapmMLp5AsBwD9FvRHBQ=.f5431ec3-8edd-42d4-b1dd-48f73142a8c4@github.com>

On Thu, 11 Dec 2025 13:38:54 GMT, Andrew Haley <aph at openjdk.org> wrote:

> For one thing, the ARM talks about "concurrent modification and execution," but doesn't make it clear if rewriting an instruction with the same value is modification. I guess it isn't.

Also, this is a really interesting question. Thanks to @jacobbramley, we?re looking into this to see if we can clarify it (but it might take a while, given the time of year).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26638#issuecomment-3683264541

From cjplummer at openjdk.org  Mon Dec 22 19:05:19 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 22 Dec 2025 19:05:19 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v5]
In-Reply-To: <pXJtgsOmcDL1mfvYYCuTiQMdrY0IhnR5Sr4rSjuazI8=.afa116de-109c-4fcf-9456-7a68fd40b35a@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
 <o5RfVmRlL4rk-uklwwVWo-aZr5-pi1JnSm9okRCr3V4=.b4ae7097-db7f-48c6-a704-a0d180abe2c0@github.com>
 <aeaIObD8KHYaIG3RoHEqqaDwLhSm7NqnC5TCst7F9Iw=.e163a2e8-47cf-40ca-b578-f50cbe37e2e6@github.com>
 <KzdEMOyPWPlRGoxYFjYzHiFA0Vqne3SxvjOOlwvAB10=.3be05771-98d9-45fa-99ed-c540e98764b8@github.com>
 <pXJtgsOmcDL1mfvYYCuTiQMdrY0IhnR5Sr4rSjuazI8=.afa116de-109c-4fcf-9456-7a68fd40b35a@github.com>
Message-ID: <mepFyg1eNNNJWzeRi8mS6r7BLfSEhb3LYzpfCHm-QKA=.f2333ddd-66b4-4fb3-93b8-aa84eb15d8a2@github.com>

On Mon, 22 Dec 2025 08:44:39 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Test nsk/jvmti/CompiledMethodUnload/compmethunload001/TestDescription.java always fails after this PR with the default value `MAX_ITERATIONS = 5`.
>> 
>> After I change the value of MAX_ITERATIONS to 50, The test run passed, and the test log shows that the number of unloaded enents is different every time.
>> 
>> 
>> Number of unloaded events 12 number of iterations 25
>> Number of unloaded events 1 number of iterations 36
>> Number of unloaded events 4 number of iterations 30
>> 
>> 
>> Before this PR, test call eatMemory to trigger full GC, this may need lots time. After this PR, test call `WhiteBox.getWhiteBox().fullGC()` to trigger full GC, this may be finish quickly.
>> 
>> Maybe that's why after this PR we need more try loop count to get the unload enent.
>> 
>> And if I add Thread.sleep(5000) after unloadClass() call  also make this test pass without change the value of MAX_ITERATIONS.
>> 
>> And I found that the vaule of MAX_ITERATIONS set to 50 seems do not enough. This will intermittent fails when run this test serially many times. So I change it to 500.
>
> Another solution is make some sleep after call `unloadClass()`
> 
> 
> diff --git a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java
> index 13058ec7864..15120d3cad6 100644
> --- a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java
> +++ b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java
> @@ -47,7 +47,7 @@ public class compmethunload001 {
>      private final static String CLS_TO_BE_UNLOADED =
>          "nsk.jvmti.CompiledMethodUnload.compmethunload001u";
>  
> -    private final static int MAX_ITERATIONS = 50;
> +    private final static int MAX_ITERATIONS = 5;
>  
>      static {
>          try {
> @@ -95,6 +95,7 @@ public static void callHotClass(String location) throws Exception {
>  
>          boolean clsUnloaded = clsUnLoader.unloadClass();
>          clsUnLoader = null;
> +        Thread.sleep(5000);
>          System.gc();
>      }

It seems this is somewhat poorly written test and is also somewhat imprecise and presumpive. I'm guessing the unload is delayed a bit because it happens async, and you can't really guess how long it is going to take for the unload to happen. The loop and the System.gc() calls are just passing time until the unload happens. The System.gc() calls should not be needed since the ClassUnloader.unloadClass() call should have been sufficient. I would suggest removing both System.gc() calls and just have a loop that does short sleeps until the unload happens. Maybe limit the loop to no more than 10 seconds. A more elegant approach would be to wait on a monitor for no more than 10 seconds, and have the native code notify the monitor when the unload happens.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2640938897

From dlong at openjdk.org  Mon Dec 22 19:29:56 2025
From: dlong at openjdk.org (Dean Long)
Date: Mon, 22 Dec 2025 19:29:56 GMT
Subject: RFR: 8373794: Move nmethod header from CodeCache
In-Reply-To: <b5vqBo9KDHIe4eCV87exNY2qzQvJEKKPQC5fnU2YL3M=.2295bcbb-8830-4c6c-835c-a3ab39720690@github.com>
References: <RZYpT82maT4ayWODxISztNMAQwPOqilJsmjTtfZA9X4=.5953f303-ddb7-4f1e-ab27-e5b3ccaa039f@github.com>
 <LAFydlD8_MzjwVnLzuGb6ICtSxWqSPsguQSM6lynUmA=.f71c0b41-948f-403d-8670-beeee6d6f9a9@github.com>
 <uFs9gKNiVGN4nWJYMRT0WGOf7IFQYBANAuYmIO59A1w=.326f8390-6936-40ed-85fc-98e3a722053f@github.com>
 <b5vqBo9KDHIe4eCV87exNY2qzQvJEKKPQC5fnU2YL3M=.2295bcbb-8830-4c6c-835c-a3ab39720690@github.com>
Message-ID: <hK-Ezcz9awUlneOcSnjUmnx81mWkZ8Yugj4QuAAG1z4=.17e436b3-690b-46ca-88ea-dcba5af99b55@github.com>

On Mon, 22 Dec 2025 15:16:54 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

> Would it be okay for us to keep the current scope of this patch to move the nmethod header to off-heap memory and maybe create a new RFE to explore moving CodeBlob header to off-heap memory?

That's fine with me.  I was thinking it would be comparable in complexity, but I hadn't worked it out as far as you have.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28866#issuecomment-3683832810

From dlong at openjdk.org  Mon Dec 22 23:32:06 2025
From: dlong at openjdk.org (Dean Long)
Date: Mon, 22 Dec 2025 23:32:06 GMT
Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() [v6]
In-Reply-To: <CEvEqPtlTMiv7fX1G_spyCpyl8afEZn4McrzIBd5GRY=.d233254e-3626-4044-a3e1-c82bcbd55e45@github.com>
References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com>
 <CEvEqPtlTMiv7fX1G_spyCpyl8afEZn4McrzIBd5GRY=.d233254e-3626-4044-a3e1-c82bcbd55e45@github.com>
Message-ID: <S1dAshI5ubrPKkQhVMhOTOILqVmQ0cRQuBvCiENzYHI=.d819772f-5952-4ab3-a399-d5b5685738cc@github.com>

On Mon, 8 Dec 2025 14:01:48 GMT, Fei Gao <fgao at openjdk.org> 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/8041f592...415495da

It is the callee that might be made not entrant by class redefinition, not necessarily the caller.  However, the caller could be made not entrant also, if there was a dependency on the callee, for example by inlining it.

I'm still unsure about the optimization of rewriting ISB to B.  Doesn't that mean the ISB is not really needed?  How is an entry point with a branch that used to be a ISB different from a branch that was always there, or no branch at all?  For example we could just omit it or have the caller jump to entry point + 4.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26638#issuecomment-3684535845
PR Comment: https://git.openjdk.org/jdk/pull/26638#issuecomment-3684541043

From syan at openjdk.org  Tue Dec 23 04:04:22 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 23 Dec 2025 04:04:22 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v5]
In-Reply-To: <mepFyg1eNNNJWzeRi8mS6r7BLfSEhb3LYzpfCHm-QKA=.f2333ddd-66b4-4fb3-93b8-aa84eb15d8a2@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
 <o5RfVmRlL4rk-uklwwVWo-aZr5-pi1JnSm9okRCr3V4=.b4ae7097-db7f-48c6-a704-a0d180abe2c0@github.com>
 <aeaIObD8KHYaIG3RoHEqqaDwLhSm7NqnC5TCst7F9Iw=.e163a2e8-47cf-40ca-b578-f50cbe37e2e6@github.com>
 <KzdEMOyPWPlRGoxYFjYzHiFA0Vqne3SxvjOOlwvAB10=.3be05771-98d9-45fa-99ed-c540e98764b8@github.com>
 <pXJtgsOmcDL1mfvYYCuTiQMdrY0IhnR5Sr4rSjuazI8=.afa116de-109c-4fcf-9456-7a68fd40b35a@github.com>
 <mepFyg1eNNNJWzeRi8mS6r7BLfSEhb3LYzpfCHm-QKA=.f2333ddd-66b4-4fb3-93b8-aa84eb15d8a2@github.com>
Message-ID: <wAusmw-EGpJttFkzRfxmexm6VP2SREMcsNn34DH3718=.66d40953-d88a-4b28-bd10-950cd3a1b3de@github.com>

On Mon, 22 Dec 2025 19:01:54 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Another solution is make some sleep after call `unloadClass()`
>> 
>> 
>> diff --git a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java
>> index 13058ec7864..15120d3cad6 100644
>> --- a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java
>> +++ b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java
>> @@ -47,7 +47,7 @@ public class compmethunload001 {
>>      private final static String CLS_TO_BE_UNLOADED =
>>          "nsk.jvmti.CompiledMethodUnload.compmethunload001u";
>>  
>> -    private final static int MAX_ITERATIONS = 50;
>> +    private final static int MAX_ITERATIONS = 5;
>>  
>>      static {
>>          try {
>> @@ -95,6 +95,7 @@ public static void callHotClass(String location) throws Exception {
>>  
>>          boolean clsUnloaded = clsUnLoader.unloadClass();
>>          clsUnLoader = null;
>> +        Thread.sleep(5000);
>>          System.gc();
>>      }
>
> It seems this is somewhat poorly written test and is also somewhat imprecise and presumpive. I'm guessing the unload is delayed a bit because it happens async, and you can't really guess how long it is going to take for the unload to happen. The loop and the System.gc() calls are just passing time until the unload happens. The System.gc() calls should not be needed since the ClassUnloader.unloadClass() call should have been sufficient. I would suggest removing both System.gc() calls and just have a loop that does short sleeps until the unload happens. Maybe limit the loop to no more than 10 seconds. A more elegant approach would be to wait on a monitor for no more than 10 seconds, and have the native code notify the monitor when the unload happens.

The code "wait on a monitor and notify from JNI" seems too complex for me. So I just limit the loop to no more than 10 seconds.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2641853242

From dholmes at openjdk.org  Tue Dec 23 05:33:51 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 23 Dec 2025 05:33:51 GMT
Subject: RFR: 8373638: RBTree public interface does not check all input
 parameters for validity
In-Reply-To: <SOiJJksA_-pAmvj8O-QYI6vbA19kXlvswvChFxqAwl4=.535530cd-6dc8-4d14-a1ae-3ecbe74a927d@github.com>
References: <SOiJJksA_-pAmvj8O-QYI6vbA19kXlvswvChFxqAwl4=.535530cd-6dc8-4d14-a1ae-3ecbe74a927d@github.com>
Message-ID: <gVxITxIMzXGljoTXMP7u6AQO4FCTBn2RqCtWDM1kM88=.b7da0f6f-2f52-437d-a0e6-4445f1383f6b@github.com>

On Fri, 19 Dec 2025 11:05:45 GMT, Casper Norrbin <cnorrbin at openjdk.org> 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

These all look like they would be good candidates for using `precond()`.

-------------

PR Review: https://git.openjdk.org/jdk/pull/28922#pullrequestreview-3606606499

From galder at openjdk.org  Tue Dec 23 05:45:54 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Tue, 23 Dec 2025 05:45:54 GMT
Subject: RFR: 8373480: Optimize multiplication by constant multiplier using
 LEA instructions [v6]
In-Reply-To: <vTZKK9fSVJPpo0sIXV1s-2hRvTOSLt78JbB3PYxiQNk=.f790a1d3-a515-4544-a304-85d80f20a927@github.com>
References: <uo_ugfdLTrURHDpmWF4Xfh2Hspum8XDJNYsUjhAEc1I=.131ef8cd-e2f3-4d8c-981c-a701452cb264@github.com>
 <vTZKK9fSVJPpo0sIXV1s-2hRvTOSLt78JbB3PYxiQNk=.f790a1d3-a515-4544-a304-85d80f20a927@github.com>
Message-ID: <1gb39c5Ai2AKZqk7UCJWyI5mh2nOxTWhomefhWQTeXA=.6286b980-2eab-485d-8c1d-005fd4add5a0@github.com>

On Mon, 22 Dec 2025 12:09:01 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Emulate multiplier using LEA addressing scheme, where effective address = BASE + INDEX * SCALE + OFFSET
>> Refer to section "3.5.1.2 Using LEA" of Intel's optimization manual for details reagarding slow vs fast lea instructions.
>> Given that latency of IMUL with register operands is 3 cycles, a combination of two fast LEAs each with 1 cycle latency to emulate multipler is performant.
>> 
>> Consider X as the multiplicand, by variying the scale of  first LEA instruction we can generate 4 input i.e.
>> 
>> 
>>     X + X * 1 = 2X
>>     X + X * 2 = 3X
>>     X + X * 4 = 5X
>>     X + X * 8 = 9X
>> 
>> 
>> Following table list downs various multiplier combinations for output of first LEA at BASE and/or INDEX by varying the 
>> scale of second fast LEA instruction. We will only handle the cases which cannot be handled by just shift + add.
>> 
>> 
>>       BASE   INDEX   SCALE  MULTIPLER
>>         X      X       1       2       (Terminal)
>>         X      X       2       3       (Terminal)
>>         X      X       4       5       (Terminal)
>>         X      X       8       9       (Terminal)
>>        3X     3X       1       6
>>         X     3X       2       7
>>        5X     5X       1      10
>>         X     5X       2      11
>>         X     3X       4      13
>>        5X     5X       2      15
>>         X     2X       8      17
>>        9X     9X       1      18
>>         X     9X       2      19
>>         X     5X       4      21
>>        5X     5X       4      25
>>        9X     9X       2      27
>>         X     9X       4      37
>>         X     5X       8      41
>>        9X     9X       4      45
>>         X     9X       8      73
>>        9X     9X       8      81
>> 
>> 
>> All the non-unity inputs tied to BASE / INDEX  are derived out of terminal cases which represent first FAST LEA. Thus, all the multipliers can be computed using just two LEA instructions.
>> 
>> Performance numbers for new micro benchmark included with this patch shows around **5-50% improvments** on latest x86 servers.
>> 
>> 
>> System: INTEL(R) XEON(R) PLATINUM 8581C CPU @ 2.10GHz Emerald Rapids:-
>> Baseline:-
>> Benchmark                                             Mode  Cnt    Score   Error    Units
>> ConstantMultiplierOptimization.testConstMultiplierI  thrpt    2  189.690          ops/min
>> ConstantMultiplierOptimization.testConstMultiplierL  thrpt    2  196.283          ops/min
>> 
>> 
>> Withopt:-
>> Benchmark                                             Mode  Cnt    Score   Error    Units
>> Constant...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Extending micro and jtreg tests for memory patterns

Thanks for the changes! Sorry I missed the reference in the JBS :)

-------------

Marked as reviewed by galder (Author).

PR Review: https://git.openjdk.org/jdk/pull/28759#pullrequestreview-3606628257

From dholmes at openjdk.org  Tue Dec 23 06:12:51 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 23 Dec 2025 06:12:51 GMT
Subject: RFR: 8374190: Convert ConcurrentHashTable atomic lists to use
 Atomic<T>
In-Reply-To: <AF4ZUl0ny2Mzk2XrJiWpUPvv63oubznivKfrGgbyz20=.a1c8a867-1f21-4ff9-b76b-91c456a126b8@github.com>
References: <AF4ZUl0ny2Mzk2XrJiWpUPvv63oubznivKfrGgbyz20=.a1c8a867-1f21-4ff9-b76b-91c456a126b8@github.com>
Message-ID: <hAa0LQeoZz5ewi845E8N7_Tg2eCtlclx69j6stTS8MI=.d46906a1-98ea-4575-9c7b-0c348eeac2f3@github.com>

On Mon, 22 Dec 2025 07:29:55 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to ConcurrentHashTable to use `Atomic<Node*>` for
> the Node lists.  Note that this does not complete the replacement of direct
> uses of AtomicAccess by that class; there's still one more group remaining.
> 
> Testing: mach5 tier1-3

This all seems reasonable.

Thanks

src/hotspot/share/utilities/concurrentHashTable.hpp line 178:

> 176:     // assignment, thus here we must cast const part away. Method is not static
> 177:     // due to an assert.
> 178:     void release_assign_node_ptr(const Atomic<Node*>* dst, Node* node) const;

The `const` part of the comment no longer seems relevant.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28951#pullrequestreview-3606620703
PR Review Comment: https://git.openjdk.org/jdk/pull/28951#discussion_r2641999957

From syan at openjdk.org  Tue Dec 23 06:18:11 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 23 Dec 2025 06:18:11 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v9]
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: <57mV8My9uVrRQwWkkizAkRt0U_XKsOTwGYjvSRGoP6c=.3e83f7a9-977f-43a3-bf35-c4fb1e86a9b0@github.com>

> 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:
> 
> - [ ] All jtreg tests by fastdebug build

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  Remove unnecessary catch OOME in gc/gctests/LargeObjects/large001/large001.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28891/files
  - new: https://git.openjdk.org/jdk/pull/28891/files/567c7623..e8d128e6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=07-08

  Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 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 jbhateja at openjdk.org  Tue Dec 23 06:25:53 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 23 Dec 2025 06:25:53 GMT
Subject: RFR: 8373480: Optimize multiplication by constant multiplier using
 LEA instructions [v6]
In-Reply-To: <vTZKK9fSVJPpo0sIXV1s-2hRvTOSLt78JbB3PYxiQNk=.f790a1d3-a515-4544-a304-85d80f20a927@github.com>
References: <uo_ugfdLTrURHDpmWF4Xfh2Hspum8XDJNYsUjhAEc1I=.131ef8cd-e2f3-4d8c-981c-a701452cb264@github.com>
 <vTZKK9fSVJPpo0sIXV1s-2hRvTOSLt78JbB3PYxiQNk=.f790a1d3-a515-4544-a304-85d80f20a927@github.com>
Message-ID: <iA3JY2OVFqQyi1mGH_HwSSGtJxDiYDYA6ztPt637904=.32af323b-6eab-4b96-957a-7dc42fa2c8f7@github.com>

On Mon, 22 Dec 2025 12:09:01 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Emulate multiplier using LEA addressing scheme, where effective address = BASE + INDEX * SCALE + OFFSET
>> Refer to section "3.5.1.2 Using LEA" of Intel's optimization manual for details reagarding slow vs fast lea instructions.
>> Given that latency of IMUL with register operands is 3 cycles, a combination of two fast LEAs each with 1 cycle latency to emulate multipler is performant.
>> 
>> Consider X as the multiplicand, by variying the scale of  first LEA instruction we can generate 4 input i.e.
>> 
>> 
>>     X + X * 1 = 2X
>>     X + X * 2 = 3X
>>     X + X * 4 = 5X
>>     X + X * 8 = 9X
>> 
>> 
>> Following table list downs various multiplier combinations for output of first LEA at BASE and/or INDEX by varying the 
>> scale of second fast LEA instruction. We will only handle the cases which cannot be handled by just shift + add.
>> 
>> 
>>       BASE   INDEX   SCALE  MULTIPLER
>>         X      X       1       2       (Terminal)
>>         X      X       2       3       (Terminal)
>>         X      X       4       5       (Terminal)
>>         X      X       8       9       (Terminal)
>>        3X     3X       1       6
>>         X     3X       2       7
>>        5X     5X       1      10
>>         X     5X       2      11
>>         X     3X       4      13
>>        5X     5X       2      15
>>         X     2X       8      17
>>        9X     9X       1      18
>>         X     9X       2      19
>>         X     5X       4      21
>>        5X     5X       4      25
>>        9X     9X       2      27
>>         X     9X       4      37
>>         X     5X       8      41
>>        9X     9X       4      45
>>         X     9X       8      73
>>        9X     9X       8      81
>> 
>> 
>> All the non-unity inputs tied to BASE / INDEX  are derived out of terminal cases which represent first FAST LEA. Thus, all the multipliers can be computed using just two LEA instructions.
>> 
>> Performance numbers for new micro benchmark included with this patch shows around **5-50% improvments** on latest x86 servers.
>> 
>> 
>> System: INTEL(R) XEON(R) PLATINUM 8581C CPU @ 2.10GHz Emerald Rapids:-
>> Baseline:-
>> Benchmark                                             Mode  Cnt    Score   Error    Units
>> ConstantMultiplierOptimization.testConstMultiplierI  thrpt    2  189.690          ops/min
>> ConstantMultiplierOptimization.testConstMultiplierL  thrpt    2  196.283          ops/min
>> 
>> 
>> Withopt:-
>> Benchmark                                             Mode  Cnt    Score   Error    Units
>> Constant...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Extending micro and jtreg tests for memory patterns

Hi @eme64 , @sviswa7, Can you also have a look.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28759#issuecomment-3685324809

From syan at openjdk.org  Tue Dec 23 06:56:44 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 23 Dec 2025 06:56:44 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v10]
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: <1SRvteO27ODfuUPUyovzjAHeTA_BH0-wcc5ODyiSJIo=.1fe140cf-239f-4303-8cbe-d4f884c4ffc6@github.com>

> 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:
> 
> - [ ] All jtreg tests by fastdebug build

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  Fix the copy-n-paste error

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28891/files
  - new: https://git.openjdk.org/jdk/pull/28891/files/e8d128e6..349ae833

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=08-09

  Stats: 24 lines in 4 files changed: 0 ins; 20 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  Tue Dec 23 07:32:47 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 23 Dec 2025 07:32:47 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v11]
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: <amsEAFtB9udzbEN2NtRLRBrIXQaALPNEexla2pTCOzU=.190b7a1e-b96c-413c-8d78-2b1ab1d9260c@github.com>

> 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:
> 
> - [ ] 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

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28891/files
  - new: https://git.openjdk.org/jdk/pull/28891/files/349ae833..6c144309

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=09-10

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 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 kbarrett at openjdk.org  Tue Dec 23 11:17:55 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 23 Dec 2025 11:17:55 GMT
Subject: RFR: 8374190: Convert ConcurrentHashTable atomic lists to use
 Atomic<T>
In-Reply-To: <hAa0LQeoZz5ewi845E8N7_Tg2eCtlclx69j6stTS8MI=.d46906a1-98ea-4575-9c7b-0c348eeac2f3@github.com>
References: <AF4ZUl0ny2Mzk2XrJiWpUPvv63oubznivKfrGgbyz20=.a1c8a867-1f21-4ff9-b76b-91c456a126b8@github.com>
 <hAa0LQeoZz5ewi845E8N7_Tg2eCtlclx69j6stTS8MI=.d46906a1-98ea-4575-9c7b-0c348eeac2f3@github.com>
Message-ID: <1dWWxpfyieTZiPq-2nyC9E6RFu9o6oTbI1Fgu2Yfva4=.15f9f4a3-7b74-47b6-9912-fe9ffda63420@github.com>

On Tue, 23 Dec 2025 05:37:42 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review this change to ConcurrentHashTable to use `Atomic<Node*>` for
>> the Node lists.  Note that this does not complete the replacement of direct
>> uses of AtomicAccess by that class; there's still one more group remaining.
>> 
>> Testing: mach5 tier1-3
>
> src/hotspot/share/utilities/concurrentHashTable.hpp line 178:
> 
>> 176:     // assignment, thus here we must cast const part away. Method is not static
>> 177:     // due to an assert.
>> 178:     void release_assign_node_ptr(const Atomic<Node*>* dst, Node* node) const;
> 
> The `const` part of the comment no longer seems relevant.

The `const` is still relevant, for the reason described. It's at least
arguable that it's kind of sketchy to do this. It certainly took me a bit of
study to understand. Note that I moved the position of the `const` qualifier
to its more usual location (in our code) for declaring a constant object (the
`Atomic<Node*>` is atomic). It could instead be written as `Atomic<Node*> const*`,
retaining the ordering from the original. Also see the implementation, where
we need to cast away the `const` qualifier, which is now being done with
`const_cast` rather than a C-style cast (that was also stripping off the `volatile`
qualifier, which the use of `AtomicAccess` implicitly reapplied).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28951#discussion_r2642847639

From epeter at openjdk.org  Tue Dec 23 11:49:52 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 23 Dec 2025 11:49:52 GMT
Subject: RFR: 8373480: Optimize multiplication by constant multiplier using
 LEA instructions [v6]
In-Reply-To: <iA3JY2OVFqQyi1mGH_HwSSGtJxDiYDYA6ztPt637904=.32af323b-6eab-4b96-957a-7dc42fa2c8f7@github.com>
References: <uo_ugfdLTrURHDpmWF4Xfh2Hspum8XDJNYsUjhAEc1I=.131ef8cd-e2f3-4d8c-981c-a701452cb264@github.com>
 <vTZKK9fSVJPpo0sIXV1s-2hRvTOSLt78JbB3PYxiQNk=.f790a1d3-a515-4544-a304-85d80f20a927@github.com>
 <iA3JY2OVFqQyi1mGH_HwSSGtJxDiYDYA6ztPt637904=.32af323b-6eab-4b96-957a-7dc42fa2c8f7@github.com>
Message-ID: <KlMsvRs5Vkb9I6gOdUeJPUCv_5pfrlGwQpkiAmcrlPo=.2b3766db-0ff4-45bb-afc4-f5423850dead@github.com>

On Tue, 23 Dec 2025 06:23:19 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Extending micro and jtreg tests for memory patterns
>
> Hi @eme64 , @sviswa7, Can you also have a look.

@jatin-bhateja That looks very exciting, I definitively want to have a look at this after the Christmas/New Year break ? 

I'll be especially excited to see the use of the Template Framework in action here :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28759#issuecomment-3686361935

From cjplummer at openjdk.org  Tue Dec 23 15:49:09 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 23 Dec 2025 15:49:09 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v11]
In-Reply-To: <amsEAFtB9udzbEN2NtRLRBrIXQaALPNEexla2pTCOzU=.190b7a1e-b96c-413c-8d78-2b1ab1d9260c@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
 <amsEAFtB9udzbEN2NtRLRBrIXQaALPNEexla2pTCOzU=.190b7a1e-b96c-413c-8d78-2b1ab1d9260c@github.com>
Message-ID: <hN2oDm-_9dIXdpd0AGmKz9PCXe0DdeZmS46iFaBxXN4=.dab75f8a-d140-4f6a-9be3-46ac95e70915@github.com>

On Tue, 23 Dec 2025 07:32:47 GMT, SendaoYan <syan at openjdk.org> 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:
>> 
>> - [ ] 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

Something strange is going on with this PR. I just get 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.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28891#issuecomment-3687093047

From fgao at openjdk.org  Tue Dec 23 16:54:00 2025
From: fgao at openjdk.org (Fei Gao)
Date: Tue, 23 Dec 2025 16:54:00 GMT
Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() [v6]
In-Reply-To: <S1dAshI5ubrPKkQhVMhOTOILqVmQ0cRQuBvCiENzYHI=.d819772f-5952-4ab3-a399-d5b5685738cc@github.com>
References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com>
 <CEvEqPtlTMiv7fX1G_spyCpyl8afEZn4McrzIBd5GRY=.d233254e-3626-4044-a3e1-c82bcbd55e45@github.com>
 <S1dAshI5ubrPKkQhVMhOTOILqVmQ0cRQuBvCiENzYHI=.d819772f-5952-4ab3-a399-d5b5685738cc@github.com>
Message-ID: <L9EncCwlS_pRwG0iiu03Z6i9VTzWEKsgaw2OwtYUOTk=.78ca49e8-8c31-4d1d-8415-ab41a5775ddf@github.com>

On Mon, 22 Dec 2025 23:29:39 GMT, Dean Long <dlong at openjdk.org> wrote:

> I'm still unsure about the optimization of rewriting ISB to B. Doesn't that mean the ISB is not really needed? How is an entry point with a branch that used to be a ISB different from a branch that was always there, or no branch at all? 

Thanks for asking.

Assume Thread 1 is executing the resolve stub while other threads may be executing concurrently. The sequence of actions Thread 1 performs is:

1. Patch the MOV instructions in the static call stub
2. Invalidate the instruction cache for the patched MOVs
3. Patch the trampoline
4. Patch the call site

The key point is that the trampoline uses an **indirect** branch, whereas the call site uses a **direct** branch, and these have very different visibility guarantees in the Arm memory model.

For a **direct** branch, the sequence
patch MOVs ? invalidate patched code ? patch direct branch
is sufficient. No ISB is required. Because the Arm memory model guarantees that if Thread 2 executes the call site and observes that it has been patched to point to the static call stub, it must observe the fully updated MOVs in the stub.

However, no such guarantee exists for an **indirect** branch, i.e. the trampoline. If Thread 3 reaches the static call stub via the trampoline, observing the updated trampoline target alone does not guarantee that it will observe the fully updated MOVs. How can we guarantee that?

An always-present ISB at the entry of the static call stub provides this guarantee, which is the existing implementation.

Is there another way to achieve the same effect? Yes: rewriting the ISB into a direct branch (B .+4) can also establish the required ordering. The sequence
patch MOVs ? invalidate patched code ? patch ISB to B .+4
creates a synchronized order similar to patching a **direct** call site. If Thread 3 observes that the original ISB has been rewritten to B .+4, it must also observe the fully updated MOVs.

In contrast, if the first instruction in the stub were always B .+4 from the beginning, there would be no observable change at that instruction, and therefore no guarantee that Thread 3 would observe the updated MOVs.

> For example, we could just omit it or have the caller jump to entry point + 4.

Yes, that is possible for Thread 2. However, we still need to address the issues faced by Thread 3.

If we don't patch trampoline while resolving static stub, ensuring that the trampoline never points to the static call stub, then the ?Thread 3? scenario disappears, and we would not need an ISB at all.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26638#issuecomment-3687310295

From fgao at openjdk.org  Tue Dec 23 16:59:07 2025
From: fgao at openjdk.org (Fei Gao)
Date: Tue, 23 Dec 2025 16:59:07 GMT
Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() [v6]
In-Reply-To: <2-SaowCI03bZE2PdHEwG7LPwbIRnFwQ7oMRS58kchXg=.a36c6bcd-0e38-4ba1-97aa-a0cfdc66ef86@github.com>
References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com>
 <CEvEqPtlTMiv7fX1G_spyCpyl8afEZn4McrzIBd5GRY=.d233254e-3626-4044-a3e1-c82bcbd55e45@github.com>
 <6E4yPY9dRcWGBT-vPPq7bOm1NfLdvIfLdecg34f6Tes=.11b0a7c1-798f-4ed2-a521-26059bc0ba5b@github.com>
 <yRkEv29KF1vLIy4V5nKDgQF7CfvVjUjfssdzZ0PccjA=.00171af8-a1aa-401b-9341-a80a6fb4e22e@github.com>
 <yhtSX7dHSCAnDVCm5UX_9Pfx0-P3FnydZOAbRt7-6Ow=.253c5dbb-c7d1-4543-94cc-cbd1a05d5c0e@github.com>
 <TEoePwnDJIw1BQ6kk9-9ggawyVL3luz0rgDALvnN-5Q=.0dfa7cd9-3298-49a7-965d-01d4365986c0@github.com>
 <nPgiY87FhQoQ-hUDy5bDG7ufXdef2vfN17mZjI6FyYc=.21999f30-4ede-49ff-b6f6-fd36ca530992@github.com>
 <DuyupqIerQYS62xHWrLNIVvgmg6ehbgNkZtL2N02_HI=.f1d96b9e-425e-417d-b122-5cef558027e9@github.com>
 <cHbuIgpwzbNOERsbubuipYsFPkqaBwAJIVvZhNLSdos=.8844631c-6f63-4a45-ae8a-a5e8523e47df@github.com>
 <2-SaowCI03bZE2PdHEwG7LPwbIRnFwQ7oMRS58kchXg=.a36c6bcd-0e38-4ba1-97aa-a0cfdc66ef86@github.com>
Message-ID: <jQg8hgv30bJRbNJ4lVVh1INC92ilqHQRo8JTCdoaxWk=.0c631342-b1aa-49f4-8bf3-cec9fb89bdad@github.com>

On Wed, 17 Dec 2025 18:17:57 GMT, Andrew Haley <aph at openjdk.org> wrote:

>>> 
>>> That visibility is not guaranteed. A `B .+4` already exists because the static stub has already been patched. We then rewrite the static stub because the destination method moved.
>> 
>> I see. Thanks for your explanation!
>> 
>>> What about a 3rd thread that sees the call site already resolved so never calls the resolve helper? It won't execute an ISB either. I thought the ISB was only needed to see changes to the stub, not the call site.
>> 
>> Assume the following race:
>> - One thread has already entered the resolver and started patching, but has not yet completed.
>> - Another thread has **not** observed the updated call site, but **has** observed the patched trampoline stub and therefore reaches the static call stub directly via the trampoline stub.
>> 
>> In this case, the second thread will not execute the resolver. An ISB in `CompiledICLocker::~CompiledICLocker()` would not address this scenario, because the second thread never goes through the resolver path and therefore never executes that ISB. As a result, the second thread may execute stale MOV instructions in the static call stub. Would that be a problem? I?m not sure whether this is what @dean-long had in mind.
>
>> Assume the following race:
>> 
>>     * One thread has already entered the resolver and started patching, but has not yet completed.
>> 
>>     * Another thread has **not** observed the updated call site, but **has** observed the patched trampoline stub and therefore reaches the static call stub directly via the trampoline stub.
> 
> OK.
> 
>> In this case, the second thread will not execute the resolver. An ISB in `CompiledICLocker::~CompiledICLocker()` would not address this scenario, because the second thread never goes through the resolver path and therefore never executes that ISB. As a result, the second thread may execute stale MOV instructions in the static call stub. Would that be a problem? 
> 
> I don't think that's possible, because rewriting when a class gets redefined only happens at a safepoint. So I think we're OK, probably.

@theRealAph It seems that patching ISB to B .+4 has caused some confusion, and there is still disagreement about the safety implications around class redefinition. How about avoiding trampoline patching when resolving the static stub, and ensuring that the trampoline never points to the static call stub? That might simplify the reasoning. What do you think? Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26638#issuecomment-3687327529

From kfarrell at openjdk.org  Tue Dec 23 19:58:17 2025
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Tue, 23 Dec 2025 19:58:17 GMT
Subject: RFR: 8359706: Add file descriptor count and maximum limit to
 VM.info [v4]
In-Reply-To: <a1HhcupsCROYETAf5X3Gbz5WqojDYbwjMcR4ZKx7uGI=.bedae8d1-08e8-426e-b073-5e207e18573a@github.com>
References: <a1HhcupsCROYETAf5X3Gbz5WqojDYbwjMcR4ZKx7uGI=.bedae8d1-08e8-426e-b073-5e207e18573a@github.com>
Message-ID: <w2ycxoCPdDFS6XkMxuwxGxEH77cm16W7HQknJL9vdR4=.9bee21b2-da7d-4e47-b052-a085d7826a47@github.com>

> Currently, it is only possible to read the number of open file descriptors of a Java process via the `UnixOperatingSystemMXBean` which is only accessible via JMX enabled tools. To improve servicability, it would be benifical to be able to view this information from jcmd VM.info output or hs_err_pid crash logs. This could help diagnose resource exhaustion and troubleshoot "too many open files" errors in Java processes on Unix platforms.
> 
> This PR adds reporting the current open file descriptor count to both jcmd VM.info output or hs_err_pid crash logs by refactoring the native JNI logic from `Java_com_sun_management_internal_OperatingSystemImpl_getOpenFileDescriptorCount0` of the `UnixOperatingSystemMXBean` into hotspot. Apple's API for retrieving open file descriptor count provides an array of the actual FDs to determine the count. To avoid using `malloc` to store this array in a potential signal handling context where stack space may be limited, the apple implementation instead allocates a fixed 32KB struct on the stack to store the open FDs and only reports the result if the struct is less than the max (1024 FDs). This should cover the majoirty of use cases.

Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:

  timed loop for aix and linux proc read

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27971/files
  - new: https://git.openjdk.org/jdk/pull/27971/files/bd00e399..7170aa06

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27971&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27971&range=02-03

  Stats: 57 lines in 2 files changed: 40 ins; 0 del; 17 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 kfarrell at openjdk.org  Tue Dec 23 20:07:36 2025
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Tue, 23 Dec 2025 20:07:36 GMT
Subject: RFR: 8359706: Add file descriptor count and maximum limit to
 VM.info [v5]
In-Reply-To: <a1HhcupsCROYETAf5X3Gbz5WqojDYbwjMcR4ZKx7uGI=.bedae8d1-08e8-426e-b073-5e207e18573a@github.com>
References: <a1HhcupsCROYETAf5X3Gbz5WqojDYbwjMcR4ZKx7uGI=.bedae8d1-08e8-426e-b073-5e207e18573a@github.com>
Message-ID: <giSpFX6Lza8Y2_h1fydfxxjAAup7B7C8XJdevKjC1T0=.af2fa92c-8c2b-46db-8b2e-a869e57150a5@github.com>

> Currently, it is only possible to read the number of open file descriptors of a Java process via the `UnixOperatingSystemMXBean` which is only accessible via JMX enabled tools. To improve servicability, it would be benifical to be able to view this information from jcmd VM.info output or hs_err_pid crash logs. This could help diagnose resource exhaustion and troubleshoot "too many open files" errors in Java processes on Unix platforms.
> 
> This PR adds reporting the current open file descriptor count to both jcmd VM.info output or hs_err_pid crash logs by refactoring the native JNI logic from `Java_com_sun_management_internal_OperatingSystemImpl_getOpenFileDescriptorCount0` of the `UnixOperatingSystemMXBean` into hotspot. Apple's API for retrieving open file descriptor count provides an array of the actual FDs to determine the count. To avoid using `malloc` to store this array in a potential signal handling context where stack space may be limited, the apple implementation instead allocates a fixed 32KB struct on the stack to store the open FDs and only reports the result if the struct is less than the max (1024 FDs). This should cover the majoirty of use cases.

Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:

  comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27971/files
  - new: https://git.openjdk.org/jdk/pull/27971/files/7170aa06..d2e82895

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27971&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27971&range=03-04

  Stats: 2 lines in 2 files changed: 2 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 kfarrell at openjdk.org  Tue Dec 23 20:11:21 2025
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Tue, 23 Dec 2025 20:11:21 GMT
Subject: RFR: 8359706: Add file descriptor count and maximum limit to
 VM.info [v5]
In-Reply-To: <giSpFX6Lza8Y2_h1fydfxxjAAup7B7C8XJdevKjC1T0=.af2fa92c-8c2b-46db-8b2e-a869e57150a5@github.com>
References: <a1HhcupsCROYETAf5X3Gbz5WqojDYbwjMcR4ZKx7uGI=.bedae8d1-08e8-426e-b073-5e207e18573a@github.com>
 <giSpFX6Lza8Y2_h1fydfxxjAAup7B7C8XJdevKjC1T0=.af2fa92c-8c2b-46db-8b2e-a869e57150a5@github.com>
Message-ID: <Hj_WFgShmsZ-msBN45PNzfP7jgCCv2XnTbH57abYqT0=.5438f014-3b06-4554-a069-5b9eab07500c@github.com>

On Tue, 23 Dec 2025 20:07:36 GMT, Kieran Farrell <kfarrell at openjdk.org> 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:
> 
>   comment

50ms timed loop added to limit the proc file read for the AIX and linux implementations.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27971#issuecomment-3687847914

From dlong at openjdk.org  Tue Dec 23 23:00:58 2025
From: dlong at openjdk.org (Dean Long)
Date: Tue, 23 Dec 2025 23:00:58 GMT
Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() [v6]
In-Reply-To: <jQg8hgv30bJRbNJ4lVVh1INC92ilqHQRo8JTCdoaxWk=.0c631342-b1aa-49f4-8bf3-cec9fb89bdad@github.com>
References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com>
 <CEvEqPtlTMiv7fX1G_spyCpyl8afEZn4McrzIBd5GRY=.d233254e-3626-4044-a3e1-c82bcbd55e45@github.com>
 <6E4yPY9dRcWGBT-vPPq7bOm1NfLdvIfLdecg34f6Tes=.11b0a7c1-798f-4ed2-a521-26059bc0ba5b@github.com>
 <yRkEv29KF1vLIy4V5nKDgQF7CfvVjUjfssdzZ0PccjA=.00171af8-a1aa-401b-9341-a80a6fb4e22e@github.com>
 <yhtSX7dHSCAnDVCm5UX_9Pfx0-P3FnydZOAbRt7-6Ow=.253c5dbb-c7d1-4543-94cc-cbd1a05d5c0e@github.com>
 <TEoePwnDJIw1BQ6kk9-9ggawyVL3luz0rgDALvnN-5Q=.0dfa7cd9-3298-49a7-965d-01d4365986c0@github.com>
 <nPgiY87FhQoQ-hUDy5bDG7ufXdef2vfN17mZjI6FyYc=.21999f30-4ede-49ff-b6f6-fd36ca530992@github.com>
 <DuyupqIerQYS62xHWrLNIVvgmg6ehbgNkZtL2N02_HI=.f1d96b9e-425e-417d-b122-5cef558027e9@github.com>
 <cHbuIgpwzbNOERsbubuipYsFPkqaBwAJIVvZhNLSdos=.8844631c-6f63-4a45-ae8a-a5e8523e47df@github.com>
 <2-SaowCI03bZE2PdHEwG7LPwbIRnFwQ7oMRS58kchXg=.a36c6bcd-0e38-4ba1-97aa-a0cfdc66ef86@github.com>
 <jQg8hgv30bJRbNJ4lVVh1INC92ilqHQRo8J
 TCdoaxWk=.0c631342-b1aa-49f4-8bf3-cec9fb89bdad@github.com>
Message-ID: <96mBwsh-w3rLPomiWo3kzdhpFQir_DgZu0W0uGrmw1c=.aac54ccd-9a93-4035-b7ca-e9c0f8d962e8@github.com>

On Tue, 23 Dec 2025 16:56:39 GMT, Fei Gao <fgao at openjdk.org> wrote:

>>> Assume the following race:
>>> 
>>>     * One thread has already entered the resolver and started patching, but has not yet completed.
>>> 
>>>     * Another thread has **not** observed the updated call site, but **has** observed the patched trampoline stub and therefore reaches the static call stub directly via the trampoline stub.
>> 
>> OK.
>> 
>>> In this case, the second thread will not execute the resolver. An ISB in `CompiledICLocker::~CompiledICLocker()` would not address this scenario, because the second thread never goes through the resolver path and therefore never executes that ISB. As a result, the second thread may execute stale MOV instructions in the static call stub. Would that be a problem? 
>> 
>> I don't think that's possible, because rewriting when a class gets redefined only happens at a safepoint. So I think we're OK, probably.
>
> @theRealAph It seems that patching ISB to B .+4 has caused some confusion, and there is still disagreement about the safety implications around class redefinition. How about avoiding trampoline patching when resolving the static stub, and ensuring that the trampoline never points to the static call stub? That might simplify the reasoning. What do you think? Thanks!

@fg1417 , thanks for the explanation.  It helps.  However, looking at the existing code even before this change, and what verify_mt_safe allows, I am worried that there are already races in this code, and using instruction patching and ISB makes it harder to analyze.  It has probably been discussed before, but why doesn't the stub read the Method* from data instead of using MOVK/MOVZ?
Winter break is coming up, so I probably won't be able look at this again until 2026.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26638#issuecomment-3688166789

From syan at openjdk.org  Wed Dec 24 01:41:12 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 24 Dec 2025 01:41:12 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v11]
In-Reply-To: <hN2oDm-_9dIXdpd0AGmKz9PCXe0DdeZmS46iFaBxXN4=.dab75f8a-d140-4f6a-9be3-46ac95e70915@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
 <amsEAFtB9udzbEN2NtRLRBrIXQaALPNEexla2pTCOzU=.190b7a1e-b96c-413c-8d78-2b1ab1d9260c@github.com>
 <hN2oDm-_9dIXdpd0AGmKz9PCXe0DdeZmS46iFaBxXN4=.dab75f8a-d140-4f6a-9be3-46ac95e70915@github.com>
Message-ID: <Fy0p5AP3vwTCJoAuzj984U2p5xZeIlzjmSC_GX6douM=.92bb0e86-5674-4c06-acca-8588d6d301cf@github.com>

On Tue, 23 Dec 2025 15:45:42 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> However, the PR claims that these commits were all done on Nov 22, not Dec.

Sorry. I seted the wrong data/time to 2025-11 on mine local machine by mistake. This cause this strange phenomenon

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28891#issuecomment-3688364502

From serb at openjdk.org  Wed Dec 24 01:49:49 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 24 Dec 2025 01:49:49 GMT
Subject: RFR: 8374316: Update copyright year to 2025 for hotspot in files where
 it was missed
Message-ID: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>

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 `

-------------

Commit messages:
 - 8374316: Update copyright year to 2025 for hotspot in files where it was missed

Changes: https://git.openjdk.org/jdk/pull/28970/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28970&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374316
  Stats: 519 lines in 519 files changed: 0 ins; 0 del; 519 mod
  Patch: https://git.openjdk.org/jdk/pull/28970.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28970/head:pull/28970

PR: https://git.openjdk.org/jdk/pull/28970

From kbarrett at openjdk.org  Wed Dec 24 04:34:53 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 24 Dec 2025 04:34:53 GMT
Subject: RFR: 8374316: Update copyright year to 2025 for hotspot in files
 where it was missed
In-Reply-To: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
References: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
Message-ID: <fJphLNivQT6v7aoC5o_wJqSbuRoZi7iBLlUmpD_B5cw=.eeed052d-b98e-4f5d-a3cf-3d516c3fad96@github.com>

On Wed, 24 Dec 2025 00:16:59 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in hotspot files updated in 2025 has been bumped to 2025. (to minimize... the patch...for now, all files modified by the commits in src/hotspot have been updated only.)

There are a lot of non-hotspot files in this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28970#issuecomment-3688645543

From serb at openjdk.org  Wed Dec 24 04:52:58 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 24 Dec 2025 04:52:58 GMT
Subject: RFR: 8374316: Update copyright year to 2025 for hotspot in files
 where it was missed
In-Reply-To: <fJphLNivQT6v7aoC5o_wJqSbuRoZi7iBLlUmpD_B5cw=.eeed052d-b98e-4f5d-a3cf-3d516c3fad96@github.com>
References: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
 <fJphLNivQT6v7aoC5o_wJqSbuRoZi7iBLlUmpD_B5cw=.eeed052d-b98e-4f5d-a3cf-3d516c3fad96@github.com>
Message-ID: <dBKMWCvfk1bUy0aCWJ7d6myTtQOQyg-kxA0whhThdYA=.e3f0e2a9-3f30-42ef-a48a-320f7308a133@github.com>

On Wed, 24 Dec 2025 04:32:25 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> There are a lot of non-hotspot files in this PR.

Most of them are related and were touched by the same commits pushed to `src/hotspot`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28970#issuecomment-3688672537

From serb at openjdk.org  Wed Dec 24 05:27:56 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 24 Dec 2025 05:27:56 GMT
Subject: RFR: 8374316: Update copyright year to 2025 for hotspot in files
 where it was missed
In-Reply-To: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
References: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
Message-ID: <9cmIm_ANkhZ9knsjEEdCJjy4qJH6TGMFcLoPMS1OVBQ=.53c83270-52bb-4c26-a415-e54a9ed37f56@github.com>

On Wed, 24 Dec 2025 00:16:59 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in hotspot files updated in 2025 has been bumped to 2025. (to minimize... the patch...for now, all files modified by the commits in src/hotspot have been updated only.)
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done `

I can split out some of these changes into a separate PR to make this one smaller, but I already have a bunch of them =(

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28970#issuecomment-3688721427

From syan at openjdk.org  Wed Dec 24 07:04:54 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 24 Dec 2025 07:04:54 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v12]
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: <He5X9QVpKoacWYBQevbZ9N8XV6ZT0yRTaqTL43ndAFw=.f2c7349a-cf8c-4f60-a9f3-797d638585b4@github.com>

> 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:
> 
> - [ ] All jtreg tests by fastdebug build

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  Remove unnecesary System.gc() and add sleep 1s to wait unload event happen

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28891/files
  - new: https://git.openjdk.org/jdk/pull/28891/files/6c144309..6fc4bb95

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=10-11

  Stats: 9 lines in 1 file changed: 1 ins; 1 del; 7 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  Wed Dec 24 07:25:42 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 24 Dec 2025 07:25:42 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v13]
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: <F67Pme6YGGdxPcgQZMezbApzktZht7Hp7leff4pWzps=.60e04bf1-a409-480b-82d5-e5ad87ef832e@github.com>

> 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:
> 
> - [ ] All jtreg tests by fastdebug build

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  Move the "./bin" after vmekys to new line

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28891/files
  - new: https://git.openjdk.org/jdk/pull/28891/files/6fc4bb95..fc2e144d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=11-12

  Stats: 44 lines in 22 files changed: 22 ins; 0 del; 22 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  Wed Dec 24 07:30:53 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 24 Dec 2025 07:30:53 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v5]
In-Reply-To: <QPeMREKa8oUX51nI4WRgmGRy7-9gEj28eykpQD0bVXw=.11428b76-74c9-4339-b6b7-8260d49132c1@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
 <o5RfVmRlL4rk-uklwwVWo-aZr5-pi1JnSm9okRCr3V4=.b4ae7097-db7f-48c6-a704-a0d180abe2c0@github.com>
 <aeaIObD8KHYaIG3RoHEqqaDwLhSm7NqnC5TCst7F9Iw=.e163a2e8-47cf-40ca-b578-f50cbe37e2e6@github.com>
 <QPeMREKa8oUX51nI4WRgmGRy7-9gEj28eykpQD0bVXw=.11428b76-74c9-4339-b6b7-8260d49132c1@github.com>
Message-ID: <pPN5obK1c-cFHaZWX0CXHrkjNmhFh7sV8gNdGEW_0wQ=.d9219a55-ba14-46f9-aa29-27be8e4b7776@github.com>

On Sat, 20 Dec 2025 04:55:02 GMT, SendaoYan <syan at openjdk.org> 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.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28891#issuecomment-3688934784

From syan at openjdk.org  Wed Dec 24 08:15:39 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 24 Dec 2025 08:15:39 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v14]
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: <6KN1kYB5JbzGX63M6tumdsgF435oXtobOFFVB39eWVg=.ca762d8a-f728-462b-9d69-ff2d10830883@github.com>

> 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:

  Use WhiteBox.fulllGC() both for test/hotspot/jtreg/vmTestbase/gc/gctests/LargeObjects/large001/large001.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28891/files
  - new: https://git.openjdk.org/jdk/pull/28891/files/fc2e144d..6610f776

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=12-13

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 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  Wed Dec 24 08:15:41 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 24 Dec 2025 08:15:41 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v5]
In-Reply-To: <Ei_8xC0rtD8x8VNSL_0mGZEO8rMyhaa_52xvwt2IGUo=.1d8c07f6-34ca-4fd1-871a-66411ee3aa36@github.com>
References: <7_oVvWw3nH2qi1ZWkCPID-qByis0_QHKH_sX3k8FVgU=.9bd80561-e935-41e0-8439-18a94eb359d8@github.com>
 <o5RfVmRlL4rk-uklwwVWo-aZr5-pi1JnSm9okRCr3V4=.b4ae7097-db7f-48c6-a704-a0d180abe2c0@github.com>
 <aeaIObD8KHYaIG3RoHEqqaDwLhSm7NqnC5TCst7F9Iw=.e163a2e8-47cf-40ca-b578-f50cbe37e2e6@github.com>
 <GETEUvGGbJVVtrHmhMlz-z2mLcXQI3QzZC-qHLpfUPY=.46a85c09-eff7-4550-a294-8d55d9a26aa5@github.com>
 <Ei_8xC0rtD8x8VNSL_0mGZEO8rMyhaa_52xvwt2IGUo=.1d8c07f6-34ca-4fd1-871a-66411ee3aa36@github.com>
Message-ID: <AlXVH55HuLs4eRx47t5HWJb4SN9F8jGuic_InqG20_E=.e99158a7-6c10-421c-8c13-936b6a065ec2@github.com>

On Mon, 22 Dec 2025 03:10:42 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> It seems that, the references is non null at the first time. So it will not unload the classes actually,
>
> I understand that difference. What I meant is before it used to use eatMemory() above to attempt to force class unloading (and you are correct, there should be none) and then below it was using unloadClass(), which essentially was the same as eatMemory(). I'm not sure why two different APIs where use. I'm wondering if we should change the test to just always use WB.fullGC() both here and below where the unloadClass() call. is being made.

I have changed the test always use WhiteBox.fullGC() instead of call unloadClass(). This test has been verified locally,

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2645091951

From syan at openjdk.org  Wed Dec 24 08:22:58 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 24 Dec 2025 08:22:58 GMT
Subject: RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to
 force GC and might cause GC in other threads [v15]
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: <6rYc9li648OsjOTvIZNadA0M4Dw_g0zwWtwPqCKGgxU=.e6b7b01d-5af8-421f-b2ae-9fedc5a69ba2@github.com>

> 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:
  - all: https://git.openjdk.org/jdk/pull/28891/files
  - new: https://git.openjdk.org/jdk/pull/28891/files/6610f776..f72866e6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28891&range=13-14

  Stats: 61 lines in 61 files changed: 0 ins; 0 del; 61 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 sparasa at openjdk.org  Wed Dec 24 22:06:43 2025
From: sparasa at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 24 Dec 2025 22:06:43 GMT
Subject: RFR: 8349452: Fix performance regression for Arrays.fill() with
 AVX512 [v11]
In-Reply-To: <vR7Pzk96gG0PlTn5P5U1qlqyCvISC0dCMxUXyWHfy2g=.e58b097d-790c-4725-8ac8-7e8f2c94ac50@github.com>
References: <vR7Pzk96gG0PlTn5P5U1qlqyCvISC0dCMxUXyWHfy2g=.e58b097d-790c-4725-8ac8-7e8f2c94ac50@github.com>
Message-ID: <07NHyGU8bmzafUXXdLP3X81f7OZrqP6JcXZmtPh78J4=.5551605a-ade3-4190-9cf8-ae2a68857694@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:

  cleanup code related to labels

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28442/files
  - new: https://git.openjdk.org/jdk/pull/28442/files/f54dfd78..1b401dcf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28442&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28442&range=09-10

  Stats: 32 lines in 1 file changed: 14 ins; 17 del; 1 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 sparasa at openjdk.org  Wed Dec 24 22:06:48 2025
From: sparasa at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 24 Dec 2025 22:06:48 GMT
Subject: RFR: 8349452: Fix performance regression for Arrays.fill() with
 AVX512 [v10]
In-Reply-To: <a2uV6sSvNnMnamD9dtQEB3aA35Ak0XDCM1HzAEFqFT8=.a298783c-b584-482a-9b86-8c5ae11bc780@github.com>
References: <vR7Pzk96gG0PlTn5P5U1qlqyCvISC0dCMxUXyWHfy2g=.e58b097d-790c-4725-8ac8-7e8f2c94ac50@github.com>
 <N-7XCtb2GXLv10t2lo8jkzoMbI-f0LAJ5gWNMQC4E5c=.098a9b7a-16a8-49f8-a327-9d0490c66e45@github.com>
 <a2uV6sSvNnMnamD9dtQEB3aA35Ak0XDCM1HzAEFqFT8=.a298783c-b584-482a-9b86-8c5ae11bc780@github.com>
Message-ID: <1AduCzJun4TEpFYX-yH5NrjLC1eTrubkyR8z_n45AZ4=.a022e38f-8e7e-452f-b0fb-c0df2b57e626@github.com>

On Thu, 18 Dec 2025 23:53:08 GMT, Derek White <drwhite at openjdk.org> wrote:

> No correctness issues, but some cleanups suggested. Thanks!

Thank you, Derek (@dwhite-intel) for your review comments and suggestions! Please see the updated code incorporating your suggestions.

> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 5800:
> 
>> 5798:                                    Register rtmp, Register rtmp2, XMMRegister xtmp) {
>> 5799:   ShortBranchVerifier sbv(this);
>> 5800:   assert_different_registers(to, value, count, rtmp);
> 
> Should add rtmp2 to assert_different_registers also

Thanks for catching that! Please see this fixed in the updated code.

> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 9339:
> 
>> 9337:   Label L_exit;
>> 9338:   Label L_fill_start;
>> 9339:   Label L_fill_32_tail;
> 
> This is a bit more style/readability suggestion:
> I think these labels can move to the block starting on line 9387
> 
> L_fill_start, L_fill_32_tail, L_fill_96_bytes, 
> L_fill_128_bytes, 
> L_fill_128_bytes_loop, 
> L_fill_128_bytes_loop_header, 
> L_fill_128_bytes_loop_pre_header

Please see these labels moved to the appropriate places as suggested to improve readability.

> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 9340:
> 
>> 9338:   Label L_fill_start;
>> 9339:   Label L_fill_32_tail;
>> 9340:   Label L_fill_64_tail;
> 
> Similar suggestion: L_fill_64_tail can move to block starting on line 9462

Please see the label L_fill_64_tail moved as suggested.

> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 9341:
> 
>> 9339:   Label L_fill_32_tail;
>> 9340:   Label L_fill_64_tail;
>> 9341:   Label L_fill_64_bytes;
> 
> L_fill_64_bytes is now unused

True, L_fill_64_bytes is now unused is unused now. Please see it removed in the updated code.

> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 9345:
> 
>> 9343:   Label L_fill_128_bytes;
>> 9344:   Label L_fill_128_bytes_loop;
>> 9345:   Label L_fill_128_loop_header;
> 
> L_fill_128_bytes_loop_header is unused (preexisting?)

L_fill_128_bytes_loop_header is a preexisting label and is being used.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28442#issuecomment-3690547891
PR Review Comment: https://git.openjdk.org/jdk/pull/28442#discussion_r2646294220
PR Review Comment: https://git.openjdk.org/jdk/pull/28442#discussion_r2646296508
PR Review Comment: https://git.openjdk.org/jdk/pull/28442#discussion_r2646296960
PR Review Comment: https://git.openjdk.org/jdk/pull/28442#discussion_r2646294502
PR Review Comment: https://git.openjdk.org/jdk/pull/28442#discussion_r2646295332

From kbarrett at openjdk.org  Thu Dec 25 04:07:44 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 25 Dec 2025 04:07:44 GMT
Subject: RFR: 8374328: Convert simple AtomicAccess uses in gc/shared to use
 Atomic<T>
Message-ID: <RJp0KKg8demYMWOXkrVs1g_jitLhTsvce6ZFO98ihNw=.2c8e0a03-d56a-450e-91c8-019931a717b8@github.com>

Please review these fairly simple changes to code in gc/shared to use
`Atomic<T>` instead of directly using `AtomicAccess`.

This change doesn't eliminate all remaining direct uses of `AtomicAccess` in
that directory; there are still a few uses that seem less simple, and maybe
some that should stay with direct `AtomicAccess`.

Testing: mach5 tier1-5

-------------

Commit messages:
 - pretouch
 - WorkerThread control
 - SuspendibleThreadSet control
 - GCLocker control
 - ConcurrentGCThread termination protocol
 - DeoptimizeNMethodBarriersALot gating counter

Changes: https://git.openjdk.org/jdk/pull/28987/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28987&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374328
  Stats: 57 lines in 12 files changed: 9 ins; 3 del; 45 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 syan at openjdk.org  Thu Dec 25 06:20:54 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 25 Dec 2025 06:20:54 GMT
Subject: [jdk26] RFR: 8371948: TestStackOverflowDuringInit.java fails xss
 too small on linux-aarch64
In-Reply-To: <9CDku0hh81R4pgOU5H4VKLKW2znAadrNuTuNqhN8JH4=.bce75bac-5ce3-44bc-9af2-9b21c6e0da8f@github.com>
References: <9CDku0hh81R4pgOU5H4VKLKW2znAadrNuTuNqhN8JH4=.bce75bac-5ce3-44bc-9af2-9b21c6e0da8f@github.com>
Message-ID: <Noi4KddBMpEvrZSBEBPdVBQOtB0o-F5MOVjbhYdvfG4=.f427d266-ab11-4dce-b9ad-467282674704@github.com>

On Fri, 19 Dec 2025 02:44:05 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [360777c3](https://github.com/openjdk/jdk/commit/360777c3ad8fe5bfeb2af15ce1b89e04d4397b9f) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by SendaoYan on 19 Dec 2025 and was reviewed by David Holmes and Andrew Haley.
> 
> This clean backport PR will fix the test bug which cause fails on some linux-aarch64 machines,
> 
> Thanks!

Thanks for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28915#issuecomment-3690996485

From syan at openjdk.org  Thu Dec 25 06:55:15 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 25 Dec 2025 06:55:15 GMT
Subject: [jdk26] Integrated: 8371948: TestStackOverflowDuringInit.java fails
 xss too small on linux-aarch64
In-Reply-To: <9CDku0hh81R4pgOU5H4VKLKW2znAadrNuTuNqhN8JH4=.bce75bac-5ce3-44bc-9af2-9b21c6e0da8f@github.com>
References: <9CDku0hh81R4pgOU5H4VKLKW2znAadrNuTuNqhN8JH4=.bce75bac-5ce3-44bc-9af2-9b21c6e0da8f@github.com>
Message-ID: <X0FVjGHa1GnxEllcmz9qHf9U_ZApfafiu8eIa8iLWS4=.4f79fd96-e3e4-45ce-ac63-7fb42a7786dc@github.com>

On Fri, 19 Dec 2025 02:44:05 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [360777c3](https://github.com/openjdk/jdk/commit/360777c3ad8fe5bfeb2af15ce1b89e04d4397b9f) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by SendaoYan on 19 Dec 2025 and was reviewed by David Holmes and Andrew Haley.
> 
> This clean backport PR will fix the test bug which cause fails on some linux-aarch64 machines,
> 
> Thanks!

This pull request has now been integrated.

Changeset: 535e8bea
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/535e8bea1a50a731d747dfbaa31bb39c4507dc2b
Stats:     64 lines in 5 files changed: 36 ins; 2 del; 26 mod

8371948: TestStackOverflowDuringInit.java fails xss too small on linux-aarch64

Reviewed-by: dholmes
Backport-of: 360777c3ad8fe5bfeb2af15ce1b89e04d4397b9f

-------------

PR: https://git.openjdk.org/jdk/pull/28915

From aph at openjdk.org  Thu Dec 25 09:57:55 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 25 Dec 2025 09:57:55 GMT
Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() [v6]
In-Reply-To: <jQg8hgv30bJRbNJ4lVVh1INC92ilqHQRo8JTCdoaxWk=.0c631342-b1aa-49f4-8bf3-cec9fb89bdad@github.com>
References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com>
 <CEvEqPtlTMiv7fX1G_spyCpyl8afEZn4McrzIBd5GRY=.d233254e-3626-4044-a3e1-c82bcbd55e45@github.com>
 <6E4yPY9dRcWGBT-vPPq7bOm1NfLdvIfLdecg34f6Tes=.11b0a7c1-798f-4ed2-a521-26059bc0ba5b@github.com>
 <yRkEv29KF1vLIy4V5nKDgQF7CfvVjUjfssdzZ0PccjA=.00171af8-a1aa-401b-9341-a80a6fb4e22e@github.com>
 <yhtSX7dHSCAnDVCm5UX_9Pfx0-P3FnydZOAbRt7-6Ow=.253c5dbb-c7d1-4543-94cc-cbd1a05d5c0e@github.com>
 <TEoePwnDJIw1BQ6kk9-9ggawyVL3luz0rgDALvnN-5Q=.0dfa7cd9-3298-49a7-965d-01d4365986c0@github.com>
 <nPgiY87FhQoQ-hUDy5bDG7ufXdef2vfN17mZjI6FyYc=.21999f30-4ede-49ff-b6f6-fd36ca530992@github.com>
 <DuyupqIerQYS62xHWrLNIVvgmg6ehbgNkZtL2N02_HI=.f1d96b9e-425e-417d-b122-5cef558027e9@github.com>
 <cHbuIgpwzbNOERsbubuipYsFPkqaBwAJIVvZhNLSdos=.8844631c-6f63-4a45-ae8a-a5e8523e47df@github.com>
 <2-SaowCI03bZE2PdHEwG7LPwbIRnFwQ7oMRS58kchXg=.a36c6bcd-0e38-4ba1-97aa-a0cfdc66ef86@github.com>
 <jQg8hgv30bJRbNJ4lVVh1INC92ilqHQRo8J
 TCdoaxWk=.0c631342-b1aa-49f4-8bf3-cec9fb89bdad@github.com>
Message-ID: <BKyrV6v8BMO_0GzA_sIhqfhzLTMygxggE1q85_VYTIs=.42320ace-2f91-4500-bede-22fce038dc40@github.com>

On Tue, 23 Dec 2025 16:56:39 GMT, Fei Gao <fgao at openjdk.org> wrote:

>>> Assume the following race:
>>> 
>>>     * One thread has already entered the resolver and started patching, but has not yet completed.
>>> 
>>>     * Another thread has **not** observed the updated call site, but **has** observed the patched trampoline stub and therefore reaches the static call stub directly via the trampoline stub.
>> 
>> OK.
>> 
>>> In this case, the second thread will not execute the resolver. An ISB in `CompiledICLocker::~CompiledICLocker()` would not address this scenario, because the second thread never goes through the resolver path and therefore never executes that ISB. As a result, the second thread may execute stale MOV instructions in the static call stub. Would that be a problem? 
>> 
>> I don't think that's possible, because rewriting when a class gets redefined only happens at a safepoint. So I think we're OK, probably.
>
> @theRealAph It seems that patching ISB to B .+4 has caused some confusion, and there is still disagreement about the safety implications around class redefinition. How about avoiding trampoline patching when resolving the static stub, and ensuring that the trampoline never points to the static call stub? That might simplify the reasoning. What do you think? Thanks!

> @fg1417 , thanks for the explanation. It helps. However, looking at the existing code even before this change, and what verify_mt_safe allows, I am worried that there are already races in this code, and using instruction patching and ISB makes it harder to analyze. 

> It has probably been discussed before, but why doesn't the stub read the Method* from data instead of using MOVK/MOVZ?

It has been discussed before; see my comment of Aug 6. You could use STLR/LDAR but that'd be more of a runtime overhead, and you need to read _two_ words. Also, it wouldn't be possible to use the guarantee that patching the jump at the call site makes the target instructions visible.

My problem here is not so much how to make this code correct, which is not difficult. It is that I do not know what a thread mutating a static call stub might be allowed to do. I already know that the initial writes to a static call stub are correctly synchronized, but later changes are not unless they are always done at a safepoint.

May that later mutation only happen at a safepoint? If that is so, then we're good to go, because a safepoint can do the ISB.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26638#issuecomment-3691247935

From serb at openjdk.org  Thu Dec 25 12:20:20 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 25 Dec 2025 12:20:20 GMT
Subject: RFR: 8374358: Update copyright year to 2025 for test/hotspot in files
 where it was missed
Message-ID: <k62yjzP56zxDMgVpeyyiCVPfhlYDEQ8tafzMcupqDMY=.5fbf79af-9933-49ad-bbe7-21865c03e64d@github.com>

The copyright year in the files under test/hotspot that were updated in 2025 has been bumped to 2025. These changes do not overlap with https://github.com/openjdk/jdk/pull/28970.

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`

-------------

Commit messages:
 - 8374358: Update copyright year to 2025 for test/hotspot in files where it was missed

Changes: https://git.openjdk.org/jdk/pull/28992/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28992&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374358
  Stats: 143 lines in 143 files changed: 0 ins; 0 del; 143 mod
  Patch: https://git.openjdk.org/jdk/pull/28992.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28992/head:pull/28992

PR: https://git.openjdk.org/jdk/pull/28992

From serb at openjdk.org  Fri Dec 26 00:07:06 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 26 Dec 2025 00:07:06 GMT
Subject: RFR: 8374360: Update copyright year to 2025 for test/jdk/jdk/jfr in
 files where it was missed
Message-ID: <6C-QmfFoCsa1rgj-QMwM6B7l91JEseDtmw-UPOBQXuQ=.40c49692-94e1-4f03-81a0-a2d86a86661b@github.com>

The copyright year in "test/jdk/jdk/jfr" files updated in 2025 has been bumped to 2025.

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`

-------------

Commit messages:
 - 8374360: Update copyright year to 2025 for test/jdk/jdk/jfr in files where it was missed

Changes: https://git.openjdk.org/jdk/pull/28993/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28993&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374360
  Stats: 60 lines in 60 files changed: 0 ins; 0 del; 60 mod
  Patch: https://git.openjdk.org/jdk/pull/28993.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28993/head:pull/28993

PR: https://git.openjdk.org/jdk/pull/28993

From egahlin at openjdk.org  Fri Dec 26 13:15:53 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 26 Dec 2025 13:15:53 GMT
Subject: RFR: 8374360: Update copyright year to 2025 for test/jdk/jdk/jfr
 in files where it was missed
In-Reply-To: <6C-QmfFoCsa1rgj-QMwM6B7l91JEseDtmw-UPOBQXuQ=.40c49692-94e1-4f03-81a0-a2d86a86661b@github.com>
References: <6C-QmfFoCsa1rgj-QMwM6B7l91JEseDtmw-UPOBQXuQ=.40c49692-94e1-4f03-81a0-a2d86a86661b@github.com>
Message-ID: <kFEZFWGf1tbbz3SCNLEheX3lvWu4wxXyYLaBHgEelPE=.d9fc6dea-204e-4808-94da-75720d6bc393@github.com>

On Thu, 25 Dec 2025 23:05:59 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in "test/jdk/jdk/jfr" files updated in 2025 has been bumped to 2025.
> 
> 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`

Marked as reviewed by egahlin (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28993#pullrequestreview-3613421161

From aph at openjdk.org  Fri Dec 26 16:17:06 2025
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 26 Dec 2025 16:17:06 GMT
Subject: RFR: 8363620: AArch64: reimplement emit_static_call_stub() [v6]
In-Reply-To: <BKyrV6v8BMO_0GzA_sIhqfhzLTMygxggE1q85_VYTIs=.42320ace-2f91-4500-bede-22fce038dc40@github.com>
References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com>
 <CEvEqPtlTMiv7fX1G_spyCpyl8afEZn4McrzIBd5GRY=.d233254e-3626-4044-a3e1-c82bcbd55e45@github.com>
 <6E4yPY9dRcWGBT-vPPq7bOm1NfLdvIfLdecg34f6Tes=.11b0a7c1-798f-4ed2-a521-26059bc0ba5b@github.com>
 <yRkEv29KF1vLIy4V5nKDgQF7CfvVjUjfssdzZ0PccjA=.00171af8-a1aa-401b-9341-a80a6fb4e22e@github.com>
 <yhtSX7dHSCAnDVCm5UX_9Pfx0-P3FnydZOAbRt7-6Ow=.253c5dbb-c7d1-4543-94cc-cbd1a05d5c0e@github.com>
 <TEoePwnDJIw1BQ6kk9-9ggawyVL3luz0rgDALvnN-5Q=.0dfa7cd9-3298-49a7-965d-01d4365986c0@github.com>
 <nPgiY87FhQoQ-hUDy5bDG7ufXdef2vfN17mZjI6FyYc=.21999f30-4ede-49ff-b6f6-fd36ca530992@github.com>
 <DuyupqIerQYS62xHWrLNIVvgmg6ehbgNkZtL2N02_HI=.f1d96b9e-425e-417d-b122-5cef558027e9@github.com>
 <cHbuIgpwzbNOERsbubuipYsFPkqaBwAJIVvZhNLSdos=.8844631c-6f63-4a45-ae8a-a5e8523e47df@github.com>
 <2-SaowCI03bZE2PdHEwG7LPwbIRnFwQ7oMRS58kchXg=.a36c6bcd-0e38-4ba1-97aa-a0cfdc66ef86@github.com>
 <jQg8hgv30bJRbNJ4lVVh1INC92ilqHQRo8J
 TCdoaxWk=.0c631342-b1aa-49f4-8bf3-cec9fb89bdad@github.com>
 <BKyrV6v8BMO_0GzA_sIhqfhzLTMygxggE1q85_VYTIs=.42320ace-2f91-4500-bede-22fce038dc40@github.com>
Message-ID: <gLm2LwQ7rnRcFoOvTRAwqgMP9xguafVWH_In19dRanY=.ef8bc0d9-264c-40f9-bd66-657a88678c5d@github.com>

On Thu, 25 Dec 2025 09:55:13 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> @theRealAph It seems that patching ISB to B .+4 has caused some confusion, and there is still disagreement about the safety implications around class redefinition. How about avoiding trampoline patching when resolving the static stub, and ensuring that the trampoline never points to the static call stub? That might simplify the reasoning. What do you think? Thanks!
>
>> @fg1417 , thanks for the explanation. It helps. However, looking at the existing code even before this change, and what verify_mt_safe allows, I am worried that there are already races in this code, and using instruction patching and ISB makes it harder to analyze. 
> 
>> It has probably been discussed before, but why doesn't the stub read the Method* from data instead of using MOVK/MOVZ?
> 
> It has been discussed before; see my comment of Aug 6. You could use STLR/LDAR but that'd be more of a runtime overhead, and you need to read _two_ words. Also, it wouldn't be possible to use the guarantee that patching the jump at the call site makes the target instructions visible.
> 
> My problem here is not so much how to make this code correct, which is not difficult. It is that I do not know what a thread mutating a static call stub might be allowed to do. I already know that the initial writes to a static call stub are correctly synchronized, but later changes are not unless they are always done at a safepoint.
> 
> May that later mutation only happen at a safepoint? If that is so, then we're good to go, because a safepoint can do the ISB.

> @theRealAph It seems that patching ISB to B .+4 has caused some confusion, and there is still disagreement about the safety implications around class redefinition.

For there to be substantial disagreement, there would have to be some plausible scenario in which there was a race condition. For that, redefinition of the call would have to occur outside a safepoint. I do not believe that's possible, and if it did happen it would break the existing code, regardless of this patch, because a racing thread would observe a partially-initialized MOVZ/MOVK sequence.

> How about avoiding trampoline patching when resolving the static stub, and ensuring that the trampoline never points to the static call stub? That might simplify the reasoning. What do you think? 

I think I already answered that: it weakens the invariant on which the correctness of trampolines is based, making the whole thing harder to reason about.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26638#issuecomment-3693064517

From serb at openjdk.org  Fri Dec 26 19:16:03 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 26 Dec 2025 19:16:03 GMT
Subject: Integrated: 8374360: Update copyright year to 2025 for
 test/jdk/jdk/jfr in files where it was missed
In-Reply-To: <6C-QmfFoCsa1rgj-QMwM6B7l91JEseDtmw-UPOBQXuQ=.40c49692-94e1-4f03-81a0-a2d86a86661b@github.com>
References: <6C-QmfFoCsa1rgj-QMwM6B7l91JEseDtmw-UPOBQXuQ=.40c49692-94e1-4f03-81a0-a2d86a86661b@github.com>
Message-ID: <tSen85283Vm8t0B1mMkBT8ufvMuAw2tB9FdpyjYzFjc=.031cd55b-a9aa-4620-9e56-ef39ffe7ef82@github.com>

On Thu, 25 Dec 2025 23:05:59 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in "test/jdk/jdk/jfr" files updated in 2025 has been bumped to 2025.
> 
> 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`

This pull request has now been integrated.

Changeset: ac07a41d
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ac07a41de9877aec3e9d5e7a23b0583038a7956d
Stats:     60 lines in 60 files changed: 0 ins; 0 del; 60 mod

8374360: Update copyright year to 2025 for test/jdk/jdk/jfr in files where it was missed

Reviewed-by: egahlin

-------------

PR: https://git.openjdk.org/jdk/pull/28993

From phh at openjdk.org  Fri Dec 26 23:03:12 2025
From: phh at openjdk.org (Paul Hohensee)
Date: Fri, 26 Dec 2025 23:03:12 GMT
Subject: RFR: 8374358: Update copyright year to 2025 for test/hotspot in
 files where it was missed
In-Reply-To: <k62yjzP56zxDMgVpeyyiCVPfhlYDEQ8tafzMcupqDMY=.5fbf79af-9933-49ad-bbe7-21865c03e64d@github.com>
References: <k62yjzP56zxDMgVpeyyiCVPfhlYDEQ8tafzMcupqDMY=.5fbf79af-9933-49ad-bbe7-21865c03e64d@github.com>
Message-ID: <ZLbQCiBp9hTnFWBN1seM1meM7HdqynWt6fP0trA0yCY=.cb22163e-f69d-4b51-acdc-4cda78d14b59@github.com>

On Thu, 25 Dec 2025 10:22:08 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in the files under test/hotspot that were updated in 2025 has been bumped to 2025. These changes do not overlap with https://github.com/openjdk/jdk/pull/28970.
> 
> 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`

Marked as reviewed by phh (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28992#pullrequestreview-3613937892

From serb at openjdk.org  Sat Dec 27 04:59:00 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 27 Dec 2025 04:59:00 GMT
Subject: Integrated: 8374358: Update copyright year to 2025 for test/hotspot in
 files where it was missed
In-Reply-To: <k62yjzP56zxDMgVpeyyiCVPfhlYDEQ8tafzMcupqDMY=.5fbf79af-9933-49ad-bbe7-21865c03e64d@github.com>
References: <k62yjzP56zxDMgVpeyyiCVPfhlYDEQ8tafzMcupqDMY=.5fbf79af-9933-49ad-bbe7-21865c03e64d@github.com>
Message-ID: <HY3T7G4sSRP25XxJylbgefpg2pUl9TW3uES9881veWc=.6f675961-cd4c-4533-ac28-f2666e4c3631@github.com>

On Thu, 25 Dec 2025 10:22:08 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in the files under test/hotspot that were updated in 2025 has been bumped to 2025. These changes do not overlap with https://github.com/openjdk/jdk/pull/28970.
> 
> 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`

This pull request has now been integrated.

Changeset: 2886c3b6
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2886c3b68a8d4b098f7d093f0406d2a15e5910dc
Stats:     143 lines in 143 files changed: 0 ins; 0 del; 143 mod

8374358: Update copyright year to 2025 for test/hotspot in files where it was missed

Reviewed-by: phh

-------------

PR: https://git.openjdk.org/jdk/pull/28992

From kbarrett at openjdk.org  Sat Dec 27 05:28:32 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 27 Dec 2025 05:28:32 GMT
Subject: RFR: 8374350: Convert hotspot gtests to use Atomic<T>
Message-ID: <BxRBFQ-RXjXDRiF75q_IepNnhurF97pwc2r_YquJx1U=.485cb8de-9395-41e3-a97e-457da24385dd@github.com>

Please review this change to convert HotSpot gtests to use Atomic<T> rather
than directly using AtomicAccess.

test_atomicAccess.cpp is, of course, not subject to this conversion.

test_globalCounter.cpp is also not included in this conversion.  The other
conversions were straight forward.  This test is less so, and I decided I
needed to spend more time studying it, so have left it for followup work.

The conversion of each test is a separate commit, in case that makes it easier
to review.

Testing: mach5 tier1

-------------

Commit messages:
 - test_archiveWorkers
 - test_concurrentHashtable
 - test_waitBarrier
 - test_singleWriterSynchronizer
 - test_globalCounter_nested
 - test_bufferNodeAllocator
 - test_stressCommitUncommit
 - test_g1CardSet
 - test_g1BatchedGangTask

Changes: https://git.openjdk.org/jdk/pull/29001/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29001&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374350
  Stats: 105 lines in 9 files changed: 6 ins; 0 del; 99 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 serb at openjdk.org  Sat Dec 27 07:40:58 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 27 Dec 2025 07:40:58 GMT
Subject: RFR: 8374316: Update copyright year to 2025 for hotspot in files
 where it was missed
In-Reply-To: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
References: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
Message-ID: <weXDVzJ1NVeizP0nigye-yZwlOeGsXCvbYkOWOYffho=.8f7c44b3-def1-45c4-9cf7-e403355361a2@github.com>

On Wed, 24 Dec 2025 00:16:59 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in hotspot files updated in 2025 has been bumped to 2025. (to minimize... the patch...for now, all files modified by the commits in src/hotspot have been updated only.)
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done `

I will update this PR to include all changes in src/hotspot and test/hotspot only. The rest will be done separately.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28970#issuecomment-3693798808

From serb at openjdk.org  Sat Dec 27 08:27:48 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 27 Dec 2025 08:27:48 GMT
Subject: RFR: 8374316: Update copyright year to 2025 for hotspot in files
 where it was missed [v2]
In-Reply-To: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
References: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
Message-ID: <1PnVxFvQfC9jvy7jFAVnY-0nOLDWnqVC71iAAizAzWI=.389a28a8-1a6b-4a7e-a67f-cdcb62b4af23@github.com>

> 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 `

Sergey Bylokhov 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:

  8374316: Update copyright year to 2025 for hotspot in files where it was missed

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28970/files
  - new: https://git.openjdk.org/jdk/pull/28970/files/e4855247..12ba39f6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28970&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28970&range=00-01

  Stats: 222 lines in 222 files changed: 0 ins; 0 del; 222 mod
  Patch: https://git.openjdk.org/jdk/pull/28970.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28970/head:pull/28970

PR: https://git.openjdk.org/jdk/pull/28970

From wenanjian at openjdk.org  Sat Dec 27 14:58:06 2025
From: wenanjian at openjdk.org (Anjian Wen)
Date: Sat, 27 Dec 2025 14:58:06 GMT
Subject: RFR: 8368724: RISC-V: Remove AvoidUnalignedAccesses Flag [v8]
In-Reply-To: <bwPsRUu6nY4b0erzZotiRmuENaLPvfiYJ3jimm8IMDY=.71626371-eb12-4632-9d36-af36393a3f72@github.com>
References: <bwPsRUu6nY4b0erzZotiRmuENaLPvfiYJ3jimm8IMDY=.71626371-eb12-4632-9d36-af36393a3f72@github.com>
Message-ID: <KGl8IKEo7S7UEr3Q3BKBbTBJEwJljkJ5-0N7Z0wzbBE=.b5056f38-0803-451b-9a24-d9a41275572d@github.com>

> According to the discuss in https://github.com/openjdk/jdk/pull/27445#, we can use UseUnalignedAccesses and !UseUnalignedAccesses to cover the AvoidUnalignedAccesses Flag, so I Remove the AvoidUnalignedAccesses Flag in this patch

Anjian Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge branch 'openjdk:master' into add_unaligned_access_check
 - move the use of UseUnalignedAccesses flag after it properly assigned.
 - modify the global flag change
 - fix the use of unaligned_access
 - delete whitespace
 - Merge branch 'master' into add_unaligned_access_check
 - delete AvoidUnalignedAccesses and extra unnecessary check
 - RISC-V: Add unaligned access check

-------------

Changes: https://git.openjdk.org/jdk/pull/27510/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27510&range=07
  Stats: 41 lines in 5 files changed: 2 ins; 9 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/27510.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27510/head:pull/27510

PR: https://git.openjdk.org/jdk/pull/27510

From serb at openjdk.org  Sun Dec 28 03:51:36 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 28 Dec 2025 03:51:36 GMT
Subject: RFR: 8374316: Update copyright year to 2025 for hotspot in files
 where it was missed [v3]
In-Reply-To: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
References: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
Message-ID: <reSTecn5OEkbqIgLWkD5RgHZ90csOpnY1ygVh2AgHeY=.48ef324b-314b-4173-bcc0-05e7b224c068@github.com>

> 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 `

Sergey Bylokhov 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:

  8374316: Update copyright year to 2025 for hotspot in files where it was missed

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28970/files
  - new: https://git.openjdk.org/jdk/pull/28970/files/12ba39f6..b8fe879e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28970&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28970&range=01-02

  Stats: 5 lines in 5 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/28970.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28970/head:pull/28970

PR: https://git.openjdk.org/jdk/pull/28970

From serb at openjdk.org  Sun Dec 28 03:51:36 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 28 Dec 2025 03:51:36 GMT
Subject: RFR: 8374316: Update copyright year to 2025 for hotspot in files
 where it was missed [v2]
In-Reply-To: <1PnVxFvQfC9jvy7jFAVnY-0nOLDWnqVC71iAAizAzWI=.389a28a8-1a6b-4a7e-a67f-cdcb62b4af23@github.com>
References: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
 <1PnVxFvQfC9jvy7jFAVnY-0nOLDWnqVC71iAAizAzWI=.389a28a8-1a6b-4a7e-a67f-cdcb62b4af23@github.com>
Message-ID: <e-wx1xmlYWHuGNHrhF5TCYp8UmuR1ujFjl8gxVjGpAk=.8b314ef9-c3c1-4e45-9450-ec44c081045c@github.com>

On Sat, 27 Dec 2025 08:27:48 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The copyright year in hotspot files updated in 2025 has been bumped to 2025. (to minimize... the patch...for now, all files modified by the commits in src/hotspot have been updated only.)
>> 
>> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
>> 
>> `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done `
>
> Sergey Bylokhov 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:
> 
>   8374316: Update copyright year to 2025 for hotspot in files where it was missed

I have to exclude files updated by this commit, since it was a copyright-only change:
JDK-8364597: Replace THL A29 Limited with Tencent
https://github.com/openjdk/jdk/commit/4c9eaddaef8

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28970#issuecomment-3693857773

From serb at openjdk.org  Sun Dec 28 03:56:39 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 28 Dec 2025 03:56:39 GMT
Subject: RFR: 8374316: Update copyright year to 2025 for hotspot in files
 where it was missed [v4]
In-Reply-To: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
References: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
Message-ID: <rLRlxg59ztJPN1eGournxUICh4mvQfqQkNIdbdIhHDM=.4ffd8bb3-8cf5-49e2-af8c-c2a3b23dad7b@github.com>

> 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 `

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

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28970/files
  - new: https://git.openjdk.org/jdk/pull/28970/files/b8fe879e..5b29083f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28970&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28970&range=02-03

  Stats: 902 lines in 771 files changed: 32 ins; 91 del; 779 mod
  Patch: https://git.openjdk.org/jdk/pull/28970.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28970/head:pull/28970

PR: https://git.openjdk.org/jdk/pull/28970

From kbarrett at openjdk.org  Mon Dec 29 09:40:59 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 29 Dec 2025 09:40:59 GMT
Subject: RFR: 8374316: Update copyright year to 2025 for hotspot in files
 where it was missed [v4]
In-Reply-To: <rLRlxg59ztJPN1eGournxUICh4mvQfqQkNIdbdIhHDM=.4ffd8bb3-8cf5-49e2-af8c-c2a3b23dad7b@github.com>
References: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
 <rLRlxg59ztJPN1eGournxUICh4mvQfqQkNIdbdIhHDM=.4ffd8bb3-8cf5-49e2-af8c-c2a3b23dad7b@github.com>
Message-ID: <SWOIaRxamByT07rEjKFqGRa7HPMyPncj4I39NcE6P8Q=.0a36484d-8ee3-4ff1-ab6a-f8ae54e986dc@github.com>

On Sun, 28 Dec 2025 03:56:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The copyright year in hotspot files updated in 2025 has been bumped to 2025. (to minimize... the patch...for now, all files modified by the commits in src/hotspot have been updated only.)
>> 
>> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
>> 
>> ~~`git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done `~~
>> 
>> `git diff origin/master --name-only | while read f; do git log origin/master --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done`
>
> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into copy_hotspot
>  - 8374316: Update copyright year to 2025 for hotspot in files where it was missed

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28970#pullrequestreview-3615459136

From mdoerr at openjdk.org  Mon Dec 29 11:03:57 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 29 Dec 2025 11:03:57 GMT
Subject: RFR: 8372384: Remove unused local variable in
 MacroAssembler::sha512_update_sha_state on PPC
In-Reply-To: <xiibUHeBKM3Y2J3CbTRBd0TE7hNhb3MkWNMdwbqji8E=.1c8a9e5c-a75e-4773-a169-5570dcdcccf6@github.com>
References: <xiibUHeBKM3Y2J3CbTRBd0TE7hNhb3MkWNMdwbqji8E=.1c8a9e5c-a75e-4773-a169-5570dcdcccf6@github.com>
Message-ID: <WsztkRAtDV7eKKpAOxwhKsAKhiOKJpFMkS6l3D2ONmM=.b2a60527-6e85-4b03-ab47-225b2c09d002@github.com>

On Mon, 24 Nov 2025 08:05:15 GMT, wb-ly878512 <duke at openjdk.org> wrote:

> Issue
> -----
> https://bugs.openjdk.org/browse/JDK-8372384
> Summary
> -------
> Remove an unused local variable from the PowerPC SHA-512 macro assembler implementation.
> Problem
> -------
> `MacroAssembler::sha512_update_sha_state` in `macroAssembler_ppc_sha.cpp` defines a local constant:
>   static const int total_inis = sizeof(inis)/sizeof(VectorRegister);
> which is never used. This triggers static analysis warnings (e.g. ?unused variable? / ?dead code?) and slightly reduces code clarity, although it has no impact on correctness or runtime behavior.
> The rest of the function relies only on `total_hs` and the implicit relation between `hs` and `inis`. The unused `total_inis` appears to be left over from an earlier version of the code or a refactoring.
> Solution
> --------
> Remove the unused local variable `total_inis` and keep the existing logic unchanged.
> Testing
> -------
> Trivial change. No additional testing.

Thanks for cleaning it up!
It would be helpful to enable GitHub Actions in your repo. That will enable automatic builds and tests.
The change is ready for integration. You can also use `/integrate delegate` if you want somebody else to do it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28472#issuecomment-3696178770

From eastigeevich at openjdk.org  Mon Dec 29 16:32:13 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 29 Dec 2025 16:32:13 GMT
Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact
 on GCs and JIT performance [v19]
In-Reply-To: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
Message-ID: <bLwJChLpj3xn-HV_bcD0VQmpL8Qw3XUVuD_4QGsTTno=.2df09b8a-ff29-454e-ab6f-afbdc68429ac@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 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 failures
>       - `containers/docker/TestJcmdWithSideCar.java`: JD...

Evgeny Astigeevich 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 'master' into JDK-8370947
 - Fix SpecJVM2008 regressions
 - Merge branch 'master' into JDK-8370947
 - Fix macos and windows aarch64 builds
 - Add cache DIC IDC status to VM_Version
 - Fix tier3 failures
 - Fix tier1 failures
 - Implement nested ICacheInvalidationContext
 - Fix linux-cross-compile build aarch64
 - Merge branch 'master' into JDK-8370947
 - ... and 17 more: https://git.openjdk.org/jdk/compare/5e685f6f...8a99c0e7

-------------

Changes: https://git.openjdk.org/jdk/pull/28328/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28328&range=18
  Stats: 872 lines in 33 files changed: 806 ins; 22 del; 44 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  Mon Dec 29 16:40:15 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 29 Dec 2025 16:40:15 GMT
Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact
 on GCs and JIT performance [v20]
In-Reply-To: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
Message-ID: <vf0nFt_J6N1J2gO7sFASugWCu2yGvay-RfWKjOufQxs=.7cde1be4-faf3-47f6-9da3-ccb8ee0703bb@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 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 failures
>       - `containers/docker/TestJcmdWithSideCar.java`: JD...

Evgeny Astigeevich has updated the pull request incrementally with three additional commits since the last revision:

 - Restore deleted comment
 - Remove redundant blank line
 - Remove redundant include

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28328/files
  - new: https://git.openjdk.org/jdk/pull/28328/files/8a99c0e7..2473fa5c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28328&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28328&range=18-19

  Stats: 3 lines in 3 files changed: 1 ins; 2 del; 0 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  Mon Dec 29 21:51:20 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 29 Dec 2025 21:51:20 GMT
Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact
 on GCs and JIT performance [v21]
In-Reply-To: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
Message-ID: <QedZccpniOaFQ_SbJqZd-IsyrdlBDa1CB1oa6vL1018=.a8378937-2234-499c-a1f6-20b8214afacd@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 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 failures
>       - `containers/docker/TestJcmdWithSideCar.java`: JD...

Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:

  Fix linux-cross-compile riscv64 build

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28328/files
  - new: https://git.openjdk.org/jdk/pull/28328/files/2473fa5c..967786b0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28328&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28328&range=19-20

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 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 serb at openjdk.org  Tue Dec 30 12:12:07 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 30 Dec 2025 12:12:07 GMT
Subject: Integrated: 8374316: Update copyright year to 2025 for hotspot in
 files where it was missed
In-Reply-To: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
References: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
Message-ID: <q5hguWA8JeDeU31OPzwGDT_V4BGx65-hGRIFqYTHdSM=.a1e57a7d-48e6-421e-ab1e-37fbdc54be02@github.com>

On Wed, 24 Dec 2025 00:16:59 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in hotspot files updated in 2025 has been bumped to 2025. (to minimize... the patch...for now, all files modified by the commits in src/hotspot have been updated only.)
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> ~~`git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done `~~
> 
> `git diff origin/master --name-only | while read f; do git log origin/master --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done`

This pull request has now been integrated.

Changeset: a6462d64
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a6462d641cba004829f9136df22f3d953c0e0c5d
Stats:     451 lines in 451 files changed: 0 ins; 0 del; 451 mod

8374316: Update copyright year to 2025 for hotspot in files where it was missed

Reviewed-by: kbarrett

-------------

PR: https://git.openjdk.org/jdk/pull/28970

From serb at openjdk.org  Tue Dec 30 12:34:15 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 30 Dec 2025 12:34:15 GMT
Subject: RFR: 8374383: Update the copyright year to 2025 in the remaining files
 under test/ where it was missed
Message-ID: <oF638zFTHP-q4TOjOW6H6q_tpIRdkZ8L7QEFXyjW9v0=.5808d93a-3adf-4d28-9255-14d59f662baa@github.com>

The copyright year in test/* files updated in 2025 has been bumped to 2025.

Updates to some tests in the test/langtools/jdk/javadoc/ group are skipped because some tests depend on exact output.

The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:

`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`

-------------

Commit messages:
 - revert langtools/jdk/javadoc/doclet/testSourceTab/SingleTab
 - 8374383: Update the copyright year to 2025 in the remaining files under test/ where it was missed.

Changes: https://git.openjdk.org/jdk/pull/29006/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29006&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374383
  Stats: 76 lines in 76 files changed: 0 ins; 0 del; 76 mod
  Patch: https://git.openjdk.org/jdk/pull/29006.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29006/head:pull/29006

PR: https://git.openjdk.org/jdk/pull/29006

From serb at openjdk.org  Tue Dec 30 20:18:34 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 30 Dec 2025 20:18:34 GMT
Subject: RFR: 8374391: Update the copyright year to 2025 in the remaining files
 under src/ where it was missed
Message-ID: <uo9SySuolbGqoeXPL8th0_bBaRt17Ux1fc0Y8NmkTeg=.623cb46e-973a-4715-b468-7a2dfe22c73e@github.com>

The copyright year in src/* files updated in 2025 has been bumped to 2025. This is the last PR for this task this year.

The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:

`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`

-------------

Commit messages:
 - 8374391: Update the copyright year to 2025 in the remaining files under src/ where it was missed

Changes: https://git.openjdk.org/jdk/pull/29008/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29008&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374391
  Stats: 89 lines in 89 files changed: 0 ins; 0 del; 89 mod
  Patch: https://git.openjdk.org/jdk/pull/29008.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29008/head:pull/29008

PR: https://git.openjdk.org/jdk/pull/29008

From jpai at openjdk.org  Wed Dec 31 04:52:50 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 31 Dec 2025 04:52:50 GMT
Subject: RFR: 8374383: Update the copyright year to 2025 in the remaining
 files under test/ where it was missed
In-Reply-To: <oF638zFTHP-q4TOjOW6H6q_tpIRdkZ8L7QEFXyjW9v0=.5808d93a-3adf-4d28-9255-14d59f662baa@github.com>
References: <oF638zFTHP-q4TOjOW6H6q_tpIRdkZ8L7QEFXyjW9v0=.5808d93a-3adf-4d28-9255-14d59f662baa@github.com>
Message-ID: <sXn8IoB2J5s7x3sF5ftW_adbPW8LxaZ_p0nWfgu2BsY=.f9752b40-934c-4c08-ab30-1f248d0c455e@github.com>

On Mon, 29 Dec 2025 22:27:22 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in test/* files updated in 2025 has been bumped to 2025.
> 
> Updates to some tests in the test/langtools/jdk/javadoc/ group are skipped because some tests depend on exact output.
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `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`

Looks OK to me. I did a trivial verification that the files updated in this PR were indeed updated in 2025.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29006#pullrequestreview-3620246101

From serb at openjdk.org  Wed Dec 31 10:09:05 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 31 Dec 2025 10:09:05 GMT
Subject: Integrated: 8374383: Update the copyright year to 2025 in the
 remaining files under test/ where it was missed
In-Reply-To: <oF638zFTHP-q4TOjOW6H6q_tpIRdkZ8L7QEFXyjW9v0=.5808d93a-3adf-4d28-9255-14d59f662baa@github.com>
References: <oF638zFTHP-q4TOjOW6H6q_tpIRdkZ8L7QEFXyjW9v0=.5808d93a-3adf-4d28-9255-14d59f662baa@github.com>
Message-ID: <smEHY8cgLh9-M18FFY97LLhNXwzDzE76Nt3pOopNIS8=.b4647ee0-2703-4bd5-a34a-06b114087b2f@github.com>

On Mon, 29 Dec 2025 22:27:22 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in test/* files updated in 2025 has been bumped to 2025.
> 
> Updates to some tests in the test/langtools/jdk/javadoc/ group are skipped because some tests depend on exact output.
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `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`

This pull request has now been integrated.

Changeset: c6246d58
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c6246d58f72942b66cb0632186366f0b99402306
Stats:     76 lines in 76 files changed: 0 ins; 0 del; 76 mod

8374383: Update the copyright year to 2025 in the remaining files under test/ where it was missed

Reviewed-by: jpai

-------------

PR: https://git.openjdk.org/jdk/pull/29006

From aph at openjdk.org  Wed Dec 31 15:22:06 2025
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 31 Dec 2025 15:22:06 GMT
Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact
 on GCs and JIT performance [v21]
In-Reply-To: <QedZccpniOaFQ_SbJqZd-IsyrdlBDa1CB1oa6vL1018=.a8378937-2234-499c-a1f6-20b8214afacd@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
 <QedZccpniOaFQ_SbJqZd-IsyrdlBDa1CB1oa6vL1018=.a8378937-2234-499c-a1f6-20b8214afacd@github.com>
Message-ID: <15wAKoik-66gfbUzGQEROBTv_cTV_I_6jq96S2ErOyA=.22e19b52-220c-4c35-9aaa-9f08719e16fa@github.com>

On Mon, 29 Dec 2025 21:51:20 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> Arm Neoverse N1 erratum 1542419: "The core might fetch a stale instruction from memory which violates the ordering of instruction fetches". It is fixed in Neoverse N1 r4p1.
>>  
>> Neoverse-N1 implementations mitigate erratum 1542419 with a workaround:
>> - Disable coherent icache.
>> - Trap IC IVAU instructions.
>> - Execute:
>>    - `tlbi vae3is, xzr`
>>    - `dsb sy`
>>  
>>  `tlbi vae3is, xzr` invalidates translations for all address spaces (global for address).  It waits for all memory accesses using in-scope old translation information to complete before it is considered complete.
>>  
>> As this workaround has significant overhead, Arm Neoverse N1 (MP050) Software Developer Errata Notice version 29.0 suggests:
>> 
>> "Since one TLB inner-shareable invalidation is enough to avoid this erratum, the number of injected TLB invalidations should be minimized in the trap handler to mitigate the performance impact due to this workaround."
>> 
>> This PR introduces a mechanism to defer instruction cache (ICache) invalidation for AArch64 to address the Arm Neoverse N1 erratum 1542419, which causes significant performance overhead if ICache invalidation is performed too frequently. The implementation includes detection of affected Neoverse N1 CPUs and automatic enabling of the workaround for relevant Neoverse N1 revisions.
>> 
>> Changes include:
>> 
>> * Added a new diagnostic JVM flag `NeoverseN1Errata1542419` to enable or disable the workaround for the erratum. The flag is automatically enabled for Neoverse N1 CPUs prior to r4p1, as detected during VM initialization.
>> * Introduced the `ICacheInvalidationContext` class to manage deferred ICache invalidation, with platform-specific logic for AArch64. This context is used to batch ICache invalidations, reducing performance impact. As the address for icache invalidation is not relevant, we use the nmethod's code start address.
>> * Provided a default (no-op) implementation for `ICacheInvalidationContext` on platforms where the workaround is not needed, ensuring portability and minimal impact on other architectures.
>> * Modified barrier patching and relocation logic (`ZBarrierSetAssembler`, `ZNMethod`, `RelocIterator`, and related code) to accept a `defer_icache_invalidation` parameter, allowing ICache invalidation to be deferred and later performed in bulk.
>> 
>> Testing results: linux fastdebug build
>> - Neoverse-N1 (Graviton 2)
>>    - [x] tier1: passed
>>    - [x] tier2: passed
>>    - [x] tier3: passed
>>    - [x] tier4: 3 failu...
>
> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix linux-cross-compile riscv64 build

Is there any reason not to do this by default on all AArch64?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28328#issuecomment-3702378081

From aivanov at openjdk.org  Wed Dec 31 15:35:53 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 31 Dec 2025 15:35:53 GMT
Subject: RFR: 8374391: Update the copyright year to 2025 in the remaining
 files under src/ where it was missed
In-Reply-To: <uo9SySuolbGqoeXPL8th0_bBaRt17Ux1fc0Y8NmkTeg=.623cb46e-973a-4715-b468-7a2dfe22c73e@github.com>
References: <uo9SySuolbGqoeXPL8th0_bBaRt17Ux1fc0Y8NmkTeg=.623cb46e-973a-4715-b468-7a2dfe22c73e@github.com>
Message-ID: <qgHsAf6PG9vbKvWMtLS8qMjDZaiHK38XZseoMcctP1s=.af0a3852-bbf5-43cf-b615-5188ce2a29e0@github.com>

On Tue, 30 Dec 2025 18:30:45 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in src/* files updated in 2025 has been bumped to 2025. This is the last PR for this task this year.
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `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`

Marked as reviewed by aivanov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29008#pullrequestreview-3621060611

From eastigeevich at openjdk.org  Wed Dec 31 16:10:10 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Wed, 31 Dec 2025 16:10:10 GMT
Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact
 on GCs and JIT performance [v21]
In-Reply-To: <15wAKoik-66gfbUzGQEROBTv_cTV_I_6jq96S2ErOyA=.22e19b52-220c-4c35-9aaa-9f08719e16fa@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
 <QedZccpniOaFQ_SbJqZd-IsyrdlBDa1CB1oa6vL1018=.a8378937-2234-499c-a1f6-20b8214afacd@github.com>
 <15wAKoik-66gfbUzGQEROBTv_cTV_I_6jq96S2ErOyA=.22e19b52-220c-4c35-9aaa-9f08719e16fa@github.com>
Message-ID: <yPoVq-X-9UlWSVpOhumN8VxrSI_lBSR5efh5Z6iPc0w=.2f1ba28a-7b42-4b03-8e25-21b31b7ee965@github.com>

On Wed, 31 Dec 2025 15:19:11 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Is there any reason not to do this by default on all AArch64?

It will be turned on if AArch64 has `ctr_el0.IDC` and `ctr_el0.DIC` set.
See https://github.com/openjdk/jdk/pull/28328/changes#diff-a87e260510f34ca7d9b0feb089ad982be8268c5c8aa5a71221f6738b051ea488R663

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28328#issuecomment-3702445761

From serb at openjdk.org  Wed Dec 31 17:20:09 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 31 Dec 2025 17:20:09 GMT
Subject: Integrated: 8374391: Update the copyright year to 2025 in the
 remaining files under src/ where it was missed
In-Reply-To: <uo9SySuolbGqoeXPL8th0_bBaRt17Ux1fc0Y8NmkTeg=.623cb46e-973a-4715-b468-7a2dfe22c73e@github.com>
References: <uo9SySuolbGqoeXPL8th0_bBaRt17Ux1fc0Y8NmkTeg=.623cb46e-973a-4715-b468-7a2dfe22c73e@github.com>
Message-ID: <F4AV_5qECl59yK4xOpwJv_zZJNk6uucZ2aQ1a8KRTrQ=.bf5679eb-75e2-474d-ad7a-8858342202b2@github.com>

On Tue, 30 Dec 2025 18:30:45 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in src/* files updated in 2025 has been bumped to 2025. This is the last PR for this task this year.
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `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`

This pull request has now been integrated.

Changeset: 2d1be8a9
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2d1be8a9e66fe82b60f7a22fd7796f0e54e60a5f
Stats:     89 lines in 89 files changed: 0 ins; 0 del; 89 mod

8374391: Update the copyright year to 2025 in the remaining files under src/ where it was missed

Reviewed-by: aivanov

-------------

PR: https://git.openjdk.org/jdk/pull/29008

From drwhite at openjdk.org  Wed Dec 31 22:32:59 2025
From: drwhite at openjdk.org (Derek White)
Date: Wed, 31 Dec 2025 22:32:59 GMT
Subject: RFR: 8349452: Fix performance regression for Arrays.fill() with
 AVX512 [v11]
In-Reply-To: <07NHyGU8bmzafUXXdLP3X81f7OZrqP6JcXZmtPh78J4=.5551605a-ade3-4190-9cf8-ae2a68857694@github.com>
References: <vR7Pzk96gG0PlTn5P5U1qlqyCvISC0dCMxUXyWHfy2g=.e58b097d-790c-4725-8ac8-7e8f2c94ac50@github.com>
 <07NHyGU8bmzafUXXdLP3X81f7OZrqP6JcXZmtPh78J4=.5551605a-ade3-4190-9cf8-ae2a68857694@github.com>
Message-ID: <YqzNGumiQmHaPctfUvRu66cUzwJP8TtNCkbS6xZRGhw=.4d3ed7a7-f10f-466f-8ff5-6a612e29dbed@github.com>

On Wed, 24 Dec 2025 22:06:43 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

>> The goal of this PR is to fix the performance regression in Arrays.fill() x86 stubs caused by masked AVX stores. The fix is to replace the masked AVX stores with store instructions without masks (i.e. unmasked stores). `fill32_masked()` and `fill64_masked()` stubs are replaced with `fill32_unmasked()` and `fill64_unmasked()` respectively.
>> 
>> To speedup unmasked stores, array fills for sizes < 64 bytes are broken down into sequences of 32B, 16B, 8B, 4B, 2B and 1B stores, depending on the size.
>> 
>> 
>> ### **Performance comparison for byte array fills in a loop for 1 million times**
>> 
>> 
>> UseAVX=3   ByteArray Size | +OptimizeFill    (Masked store   stub)     [secs] | -OptimizeFill   (No stub)   [secs] | --->This PR: +OptimizeFill   (Unmasked store   stub)   [secs]
>> -- | -- | -- | --
>> 1 | 0.46 | 0.14 | 0.189
>> 2 | 0.46 | 0.16 | 0.191
>> 3 | 0.46 | 0.176 | 0.199
>> 4 | 0.46 | 0.244 | 0.212
>> 5 | 0.46 | 0.29 | 0.364
>> 10 | 0.46 | 0.58 | 0.354
>> 15 | 0.46 | 0.42 | 0.325
>> 16 | 0.46 | 0.46 | 0.281
>> 17 | 0.21 | 0.5 | 0.365
>> 20 | 0.21 | 0.37 | 0.326
>> 25 | 0.21 | 0.59 | 0.343
>> 31 | 0.21 | 0.53 | 0.317
>> 32 | 0.21 | 0.58 | 0.249
>> 35 | 0.5 | 0.77 | 0.303
>> 40 | 0.5 | 0.61 | 0.312
>> 45 | 0.5 | 0.52 | 0.364
>> 48 | 0.5 | 0.66 | 0.283
>> 49 | 0.22 | 0.69 | 0.367
>> 50 | 0.22 | 0.78 | 0.344
>> 55 | 0.22 | 0.67 | 0.332
>> 60 | 0.22 | 0.67 | 0.312
>> 64 | 0.22 | 0.82 | 0.253
>> 70 | 0.51 | 1.1 | 0.394
>> 80 | 0.49 | 0.89 | 0.346
>> 90 | 0.225 | 0.68 | 0.385
>> 100 | 0.54 | 1.09 | 0.364
>> 110 | 0.6 | 0.98 | 0.416
>> 120 | 0.26 | 0.75 | 0.367
>> 128 | 0.266 | 1.1 | 0.342
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cleanup code related to labels

Looks good - thanks Vamsi

-------------

Marked as reviewed by drwhite (Committer).

PR Review: https://git.openjdk.org/jdk/pull/28442#pullrequestreview-3621485319