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