From aboldtch at openjdk.org  Fri Aug  1 06:03:56 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 1 Aug 2025 06:03:56 GMT
Subject: RFR: 8364141: Remove LockingMode related code from x86
In-Reply-To: <g7WNqmFlJOkai-zeEjD09M5TwpL3fAMkZUAy37b747U=.faa6d9f5-1894-4507-a0f1-1dd41f3bdd43@github.com>
References: <g7WNqmFlJOkai-zeEjD09M5TwpL3fAMkZUAy37b747U=.faa6d9f5-1894-4507-a0f1-1dd41f3bdd43@github.com>
Message-ID: <YUCNnDlbyF-z4NES5rRfdKosrR-Add2MlY2lYeY6ee8=.cf6aff10-ce90-4dd5-b378-c05a3bda7ad4@github.com>

On Wed, 30 Jul 2025 13:17:37 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
> 
> This PR removes `LockingMode` related code from the **x86** platform.
> 
> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.
> 
> Passes tier1-tier5 with no added problems.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 227:

> 225: void C2_MacroAssembler::fast_lock_lightweight(Register obj, Register box, Register rax_reg,
> 226:                                               Register t, Register thread) {
> 227:   assert(box == rbx, "Used for displaced header location");

Where does this RBX requirement come from? Do not recall it being a thing for the lightweight implementation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26552#discussion_r2247011594

From aboldtch at openjdk.org  Fri Aug  1 06:14:57 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 1 Aug 2025 06:14:57 GMT
Subject: RFR: 8364141: Remove LockingMode related code from x86
In-Reply-To: <g7WNqmFlJOkai-zeEjD09M5TwpL3fAMkZUAy37b747U=.faa6d9f5-1894-4507-a0f1-1dd41f3bdd43@github.com>
References: <g7WNqmFlJOkai-zeEjD09M5TwpL3fAMkZUAy37b747U=.faa6d9f5-1894-4507-a0f1-1dd41f3bdd43@github.com>
Message-ID: <m8gAjZPc85FAkX6HrgJvTY62GD-iWz7s9WULXmwrWoQ=.d48f80a3-7d38-4707-8dc4-b1ab80b6c1e3@github.com>

On Wed, 30 Jul 2025 13:17:37 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
> 
> This PR removes `LockingMode` related code from the **x86** platform.
> 
> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.
> 
> Passes tier1-tier5 with no added problems.

Nice cleanup! Some small initial comments.

All the "displaced header" comments looks out of place. Displacing the header word on the stack (in the box) was purely a LM_LEGACY thing. Now we only displace it in the ObjectMonitor which is only handled (inflation / deflation) in the C++ runtime.

There are some more `BasicLock::displaced_header_offset_in_bytes()` asserts inside the x86 code. For callers of these methods, could be removed now or when the `BasicLock` is cleaned up.

There are some unused variables because of "displaced header" code that is kept.

`fast_lock_lightweight` and `fast_unlock_lockweight` should probably be renamed `fast_lock` and `fast_unlock` to be in sync with all the comments. (Or all the comments should be updated) (Same with C2 AD instruction)

src/hotspot/cpu/x86/interp_masm_x86.cpp line 1032:

> 1030:   const Register tmp_reg = rbx;
> 1031:   const Register obj_reg = c_rarg3; // Will contain the oop
> 1032:   const Register rklass_decode_tmp = rscratch1;

Unused variable.

src/hotspot/cpu/x86/interp_masm_x86.cpp line 1037:

> 1035:   const int lock_offset = in_bytes(BasicObjectLock::lock_offset());
> 1036:   const int mark_offset = lock_offset +
> 1037:                           BasicLock::displaced_header_offset_in_bytes();

Unused variable.

src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp line 2194:

> 2192: 
> 2193:     // Load the oop from the handle
> 2194:     __ movptr(obj_reg, Address(oop_handle_reg, 0));

`mark_word_offset` and `count_mon` unused variable above.

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

Changes requested by aboldtch (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26552#pullrequestreview-3077803768
PR Review Comment: https://git.openjdk.org/jdk/pull/26552#discussion_r2247015924
PR Review Comment: https://git.openjdk.org/jdk/pull/26552#discussion_r2247016992
PR Review Comment: https://git.openjdk.org/jdk/pull/26552#discussion_r2247033438

From shade at openjdk.org  Fri Aug  1 06:30:06 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 1 Aug 2025 06:30:06 GMT
Subject: RFR: 8364359: Sort share/cds includes [v3]
In-Reply-To: <EXjfd_1v6IhM-rKuFxp1AyIQq0tWCiTYs-bQJ5-BUQ0=.c0fc2846-7bbe-40b2-b5a0-d0c38ae021fd@github.com>
References: <9k50LwUaGiciMBE69S8FuJWN0pDbbwA5SCLK51mDVfk=.c0c92087-c47b-492c-a2d3-621a9d4711d6@github.com>
 <EXjfd_1v6IhM-rKuFxp1AyIQq0tWCiTYs-bQJ5-BUQ0=.c0fc2846-7bbe-40b2-b5a0-d0c38ae021fd@github.com>
Message-ID: <qgv1cabE_iRtfm6ZJ7k6ioegsvG85-N_zCWrZL2iRxQ=.815520ac-47c9-490b-ba96-4bfeaba6db34@github.com>

On Thu, 31 Jul 2025 12:58:38 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> This PR sorts the includes in `hotspot/share/cds` using `SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted`.
>> 
>> Passes tier1.
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix test order

macos-aarch64 test failure looks unrelated.

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

PR Comment: https://git.openjdk.org/jdk/pull/26561#issuecomment-3142744805

From duke at openjdk.org  Fri Aug  1 06:30:07 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Fri, 1 Aug 2025 06:30:07 GMT
Subject: Integrated: 8364359: Sort share/cds includes
In-Reply-To: <9k50LwUaGiciMBE69S8FuJWN0pDbbwA5SCLK51mDVfk=.c0c92087-c47b-492c-a2d3-621a9d4711d6@github.com>
References: <9k50LwUaGiciMBE69S8FuJWN0pDbbwA5SCLK51mDVfk=.c0c92087-c47b-492c-a2d3-621a9d4711d6@github.com>
Message-ID: <bXUaEo0Pba-zt8a6WKDFlhOO4ajyEqN59At-NBT_6Ug=.d903cae4-d417-4410-af81-473ef2aab7ab@github.com>

On Wed, 30 Jul 2025 16:53:20 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> This PR sorts the includes in `hotspot/share/cds` using `SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted`.
> 
> Passes tier1.

This pull request has now been integrated.

Changeset: c9b8bd6f
Author:    Francesco Andreuzzi <andreuzzi.francesco at gmail.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c9b8bd6ff478fda23a10a6d3e04aec4478cb9ff6
Stats:     30 lines in 13 files changed: 15 ins; 13 del; 2 mod

8364359: Sort share/cds includes

Reviewed-by: shade, iklam

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

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

From sspitsyn at openjdk.org  Fri Aug  1 09:44:56 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 1 Aug 2025 09:44:56 GMT
Subject: RFR: 8306324: StopThread results in thread being marked as
 interrupted, leading to unexpected InterruptedException [v7]
In-Reply-To: <uyFxRbd5zvitt4VhzYOUtefXo8o2pd1D2VN26jVDtYM=.d13c4b61-4583-4302-9692-cd391d767b9d@github.com>
References: <sDAklD-arV33IpWiJwMkwUfNPMAmsr5cgboU4y0hjhk=.192cd7e5-f2a2-4b5c-83a9-5111bf1926ec@github.com>
 <uyFxRbd5zvitt4VhzYOUtefXo8o2pd1D2VN26jVDtYM=.d13c4b61-4583-4302-9692-cd391d767b9d@github.com>
Message-ID: <7LrTOiuQ3p-wZPtvdr-WkDPFzEawcmEeXzEtaIaJTrk=.5e74eda0-5414-4b13-935e-75f6f2a3f486@github.com>

On Thu, 31 Jul 2025 03:45:10 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> If JVMTI `StopThread` is done when the thread is in certain various states (but not all states), after the `async` exception is delivered and handled, hotspot leaves the thread's `interrupted` flag set. The end result is the next time the thread does something like `Thread.sleep()`, it will immediately get an `InterruptedException`.
>> 
>> The fix is to clear the `interrupted` flag in the `JavaThread::handle_async_exception()` after an `async` pending exception has been set to be thrown with the `set_pending_exception()`.
>> 
>> There are a couple of concerns with this fix which would be nice to sort out with reviewers:
>> 1.  The proposed fix may clear the interrupt state when it was already set prior to the issuing of the `StopThread()` (this concern was raised by @dholmes-ora in a comment of this JBS issue)
>> 2.  The impacted code path is shared between the class `InstallAsyncExceptionHandshakeClosure` used by the JVMTI `StopThread` implementation and the class `ScopedAsyncExceptionHandshakeClosure` used by the `ScopedMemoryAccess`
>> 
>> I feel that clearing the `interrupted` flag byt the `JavaThread::handle_async_exception()` is a right thing to do even though it was set before the call to `JavaThread::install_async_exception()`. Also, it has to be done for both `StopThread` and `ScopedMemoryAccess`.
>> 
>> The fix also includes minor tweaks of the test `StopThreadTest` to make the issue reproducible with it.
>> 
>> Testing:
>>  - Mach5 tiers 1-6 are passed
>>  - Ran the updated reproducer test `hotspot/jtreg/serviceability/jvmti/vthread/StopThreadTest`
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed typo: in latest update

Thank you for review and suggestions, Alan and Patricio!

David, do you have any concerns or suggestions? Should I wait for your approval?

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

PR Comment: https://git.openjdk.org/jdk/pull/26365#issuecomment-3143917402
PR Comment: https://git.openjdk.org/jdk/pull/26365#issuecomment-3143921149

From sspitsyn at openjdk.org  Fri Aug  1 09:44:57 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 1 Aug 2025 09:44:57 GMT
Subject: RFR: 8306324: StopThread results in thread being marked as
 interrupted, leading to unexpected InterruptedException [v7]
In-Reply-To: <0pW1wrr7ZPPK3faGmXIAhDi_f9pTaH-e6g8yVfw7g5o=.b068df42-b52d-4f1c-8c32-aaddd496d81f@github.com>
References: <sDAklD-arV33IpWiJwMkwUfNPMAmsr5cgboU4y0hjhk=.192cd7e5-f2a2-4b5c-83a9-5111bf1926ec@github.com>
 <uyFxRbd5zvitt4VhzYOUtefXo8o2pd1D2VN26jVDtYM=.d13c4b61-4583-4302-9692-cd391d767b9d@github.com>
 <0pW1wrr7ZPPK3faGmXIAhDi_f9pTaH-e6g8yVfw7g5o=.b068df42-b52d-4f1c-8c32-aaddd496d81f@github.com>
Message-ID: <QGme_ns5Rq0uHLwC4SbATZBKpI1wVdDHEZQMQjZC5OE=.72572fe4-e6ef-495c-b2e8-ab4806f4cd83@github.com>

On Thu, 31 Jul 2025 15:49:02 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed typo: in latest update
>
> src/hotspot/share/prims/jvm.cpp line 2899:
> 
>> 2897:       // An asynchronous exception could have been thrown on
>> 2898:       // us while we were sleeping. We do not overwrite those.
>> 2899:       if (!HAS_PENDING_EXCEPTION) {
> 
> Maybe not for this bug but we have this `HAS_PENDING_EXCEPTION` check here and further up but I don't see how we can have a pending exception when calling this method. Based on the comment here seems we just wanted to check the async ones as added now.

Should we always have `HAS_PENDING_EXCEPTION == true` if async exception was installed?
If so, then this newly added check is not really needed:

           if (!thread->has_async_exception_condition()) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26365#discussion_r2247472186

From jsikstro at openjdk.org  Fri Aug  1 10:44:40 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Fri, 1 Aug 2025 10:44:40 GMT
Subject: RFR: 8364518: Support for Job Objects in os::commit_memory_limit() on
 Windows
Message-ID: <ybsWeoo6MjS7HBqweDMwkVllcABSLyDcaOSNe828i6o=.8ae55f56-2042-4909-bb25-a1730e17ff64@github.com>

Hello,

We currently use os::commit_memory_limit() to limit the initial, min and max values when ergonomically setting the heap size. Right now, os::commit_memory_limit() returns the available virtual address space on Windows, which is guaranteed to be the upper-bound of how much memory can be committed. However, this does not take into account user-configurable limits.

I propose revising os::commit_memory_limit() to consider Windows Job Objects. Job Objects can, among other things, restrict the amount of memory that can be committed by a single process or all processes in a job. If we are unable to query Job Object information or if no limit is set, I suggest returning SIZE_MAX, since the next effective limit is the available virtual address space. The size of this virtual address space cannot be modified by the user, except by consuming it. 

For more details and short examples, I have created a GitHub repository summarizing my findings regarding memory limits and Job Objects on Windows: [https://github.com/jsikstro/MemoryLimitsWindows ](https://github.com/jsikstro/MemoryLimitsWindows).

Adding support for Job Objects in this way adds support for detecting memory limits when using native Windows Hyper-V containers, which uses Job Objects to limit memory.

Testing:
* Oracles tier1-2
* Manual testing on Windows using both [Process Governor](https://github.com/lowleveldesign/process-governor) (a popular tool), and creating a Job Object manually.

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

Commit messages:
 - 8364518: Support for Job Objects in os::commit_memory_limit() on Windows

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

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

From fbredberg at openjdk.org  Fri Aug  1 12:28:56 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Fri, 1 Aug 2025 12:28:56 GMT
Subject: RFR: 8364141: Remove LockingMode related code from x86
In-Reply-To: <YUCNnDlbyF-z4NES5rRfdKosrR-Add2MlY2lYeY6ee8=.cf6aff10-ce90-4dd5-b378-c05a3bda7ad4@github.com>
References: <g7WNqmFlJOkai-zeEjD09M5TwpL3fAMkZUAy37b747U=.faa6d9f5-1894-4507-a0f1-1dd41f3bdd43@github.com>
 <YUCNnDlbyF-z4NES5rRfdKosrR-Add2MlY2lYeY6ee8=.cf6aff10-ce90-4dd5-b378-c05a3bda7ad4@github.com>
Message-ID: <LwGbVokxrBPheDkx5ng8YGrx5Hz1jqTd2Dl-FPE3a9A=.cafaa721-1f82-4379-b7bc-86740aea6968@github.com>

On Fri, 1 Aug 2025 05:59:59 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
>> 
>> This PR removes `LockingMode` related code from the **x86** platform.
>> 
>> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.
>> 
>> Passes tier1-tier5 with no added problems.
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 227:
> 
>> 225: void C2_MacroAssembler::fast_lock_lightweight(Register obj, Register box, Register rax_reg,
>> 226:                                               Register t, Register thread) {
>> 227:   assert(box == rbx, "Used for displaced header location");
> 
> Where does this RBX requirement come from? Do not recall it being a thing for the lightweight implementation.

Good question! Long story short: `C2_MacroAssembler::fast_unlock` used to have this comment:

`// box: box address (displaced header location), killed. Must be EAX.
`
Looking at `cmpFastLock` in the `x86_64.ad` file I saw that the box was indeed hardwired to rax (e.g. `rax_RegP box`).

Since there was no special comment above `fast_lock_lightweight` I though that I should reuse the one from the deleted `fast_lock`. Then when looking in `cmpFastLockLightweight` I saw that box was hardwired to rbx. And ta-da, there you have the reason.

But now since you asked about it, I understand that the reason it say "Must be EAX" in `fast_lock`, was because it was used in a `cmpxchgptr`. But this was only used in the legacy locking mode, which is now deleted. So I will delete the comment and the assert().

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26552#discussion_r2247851859

From fbredberg at openjdk.org  Fri Aug  1 12:32:57 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Fri, 1 Aug 2025 12:32:57 GMT
Subject: RFR: 8364141: Remove LockingMode related code from x86
In-Reply-To: <mZDL0L3WAyZxzLOTd7WKOFpSx6o0ly_-EPcXTYhNAeQ=.073ef480-a999-48f3-93a0-3a94d160fa17@github.com>
References: <g7WNqmFlJOkai-zeEjD09M5TwpL3fAMkZUAy37b747U=.faa6d9f5-1894-4507-a0f1-1dd41f3bdd43@github.com>
 <mZDL0L3WAyZxzLOTd7WKOFpSx6o0ly_-EPcXTYhNAeQ=.073ef480-a999-48f3-93a0-3a94d160fa17@github.com>
Message-ID: <INkox5o1QwaI6jGsUbHSF5rR3Myt9NwM1v0XCh_r8BY=.b5dac371-f1ab-4bda-957c-5512405ec4d5@github.com>

On Wed, 30 Jul 2025 16:22:14 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
>> 
>> This PR removes `LockingMode` related code from the **x86** platform.
>> 
>> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.
>> 
>> Passes tier1-tier5 with no added problems.
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 389:
> 
>> 387: // obj: object to lock
>> 388: // rax: tmp -- KILLED
>> 389: // t  : tmp - cannot be obj nor rax -- KILLED
> 
> This same comment is repeated just above so you probably don't need it here.

Since it's more than 150 lives above, I'd rather keep this "copy" here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26552#discussion_r2247860770

From mbaesken at openjdk.org  Fri Aug  1 13:22:40 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 1 Aug 2025 13:22:40 GMT
Subject: RFR: 8364514: [asan] runtime/jni/checked/TestCharArrayReleasing.java
 heap-buffer-overflow
Message-ID: <yZawVqmQPuYBMqD2OZnkWLMti0SWMxLn0vQQhbBL3MY=.784dd3f5-2826-4f86-802f-88e0a7b53087@github.com>

When running with ASAN enabled binaries , the test runtime/jni/checked/TestCharArrayReleasing.java fails with a  heap-buffer-overflow . This is expected because the test checks API usage errors and this way triggers ASAN.

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

Commit messages:
 - JDK-8364514

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

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

From fbredberg at openjdk.org  Fri Aug  1 14:03:31 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Fri, 1 Aug 2025 14:03:31 GMT
Subject: RFR: 8364406: Remove LockingMode related code from aarch64
Message-ID: <YgHBd1bQAjTri-T6bu_WxnTz606-Wijg995KPVcbao0=.beb80bbe-9ff5-4c05-9ccc-a8e47519542a@github.com>

Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.

This PR removes `LockingMode` related code from the **aarch64** platform.

When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.

Passes tier1-tier5 with no added problems.

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

Commit messages:
 - 8364406: Remove LockingMode related code from aarch64

Changes: https://git.openjdk.org/jdk/pull/26594/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26594&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364406
  Stats: 577 lines in 9 files changed: 10 ins; 521 del; 46 mod
  Patch: https://git.openjdk.org/jdk/pull/26594.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26594/head:pull/26594

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

From aph at openjdk.org  Fri Aug  1 14:03:32 2025
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 1 Aug 2025 14:03:32 GMT
Subject: RFR: 8364406: Remove LockingMode related code from aarch64
In-Reply-To: <YgHBd1bQAjTri-T6bu_WxnTz606-Wijg995KPVcbao0=.beb80bbe-9ff5-4c05-9ccc-a8e47519542a@github.com>
References: <YgHBd1bQAjTri-T6bu_WxnTz606-Wijg995KPVcbao0=.beb80bbe-9ff5-4c05-9ccc-a8e47519542a@github.com>
Message-ID: <JO-YpPyS1tptK0jGa8AExkxEWVyWwQoQfITLYd3QkQ8=.c26e50be-383c-49bd-bd61-69ac27a228ab@github.com>

On Fri, 1 Aug 2025 11:22:50 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
> 
> This PR removes `LockingMode` related code from the **aarch64** platform.
> 
> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.
> 
> Passes tier1-tier5 with no added problems.

Looks good to me.

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

PR Review: https://git.openjdk.org/jdk/pull/26594#pullrequestreview-3079125218

From pchilanomate at openjdk.org  Fri Aug  1 14:09:04 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 1 Aug 2025 14:09:04 GMT
Subject: RFR: 8306324: StopThread results in thread being marked as
 interrupted, leading to unexpected InterruptedException [v7]
In-Reply-To: <QGme_ns5Rq0uHLwC4SbATZBKpI1wVdDHEZQMQjZC5OE=.72572fe4-e6ef-495c-b2e8-ab4806f4cd83@github.com>
References: <sDAklD-arV33IpWiJwMkwUfNPMAmsr5cgboU4y0hjhk=.192cd7e5-f2a2-4b5c-83a9-5111bf1926ec@github.com>
 <uyFxRbd5zvitt4VhzYOUtefXo8o2pd1D2VN26jVDtYM=.d13c4b61-4583-4302-9692-cd391d767b9d@github.com>
 <0pW1wrr7ZPPK3faGmXIAhDi_f9pTaH-e6g8yVfw7g5o=.b068df42-b52d-4f1c-8c32-aaddd496d81f@github.com>
 <QGme_ns5Rq0uHLwC4SbATZBKpI1wVdDHEZQMQjZC5OE=.72572fe4-e6ef-495c-b2e8-ab4806f4cd83@github.com>
Message-ID: <Ci_ghq96Gr9rvBiRyA03gDvm958HGPANPME27TOIj6I=.a4097777-0ae1-4fe8-95c3-21dc6815ec68@github.com>

On Fri, 1 Aug 2025 09:40:51 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/prims/jvm.cpp line 2899:
>> 
>>> 2897:       // An asynchronous exception could have been thrown on
>>> 2898:       // us while we were sleeping. We do not overwrite those.
>>> 2899:       if (!HAS_PENDING_EXCEPTION) {
>> 
>> Maybe not for this bug but we have this `HAS_PENDING_EXCEPTION` check here and further up but I don't see how we can have a pending exception when calling this method. Based on the comment here seems we just wanted to check the async ones as added now.
>
> Should we always have `HAS_PENDING_EXCEPTION == true` if async exception was installed?
> If so, then this newly added check is not really needed:
> 
>            if (!thread->has_async_exception_condition()) {

Until we process the async exception handshake operation, `HAS_PENDING_EXCEPTION` will be false. The only way for `HAS_PENDING_EXCEPTION` to be true would be if we already entered the method with a pending exception, but I don?t see how that is possible.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26365#discussion_r2248080447

From egahlin at openjdk.org  Fri Aug  1 15:24:55 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 1 Aug 2025 15:24:55 GMT
Subject: RFR: 8364258: ThreadGroup constant pool serialization is not
 normalized [v6]
In-Reply-To: <LAYJyPzZD7a9nCIFpHG9MKFQx_3ZUwBhf3wVuwuuDxI=.4dad1c72-163d-46f9-8b2d-54ad3eb149b3@github.com>
References: <gIJUvly5QIjQCZ8y483ZxIVRY292EivXkw5pXY_y8lY=.f600e5f0-677e-4c54-9bb0-8cc98598ab61@github.com>
 <LAYJyPzZD7a9nCIFpHG9MKFQx_3ZUwBhf3wVuwuuDxI=.4dad1c72-163d-46f9-8b2d-54ad3eb149b3@github.com>
Message-ID: <vRoLoFEWnPQlAhs9dtULW1CPHagvlv8MPmpea2dPE80=.b0e4254a-4ca5-44cf-a995-8ee0a0690d3a@github.com>

On Thu, 31 Jul 2025 21:18:14 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> The following change set normalizes the ThreadGroup constants being serialized to the .jfr binary file.
>> 
>> It does this in two parts:
>> 
>> 1. Re-inserts a scavenging scheme to remove stale (unloaded) ThreadGroups; some logic that we used to have in place, but may have been lost as part of the major refactoring around JFR Event Streaming, or even earlier.
>> 2. Introduces a per-epoch "is_serialized" scheme, building on top of JFR epoch generations.
>> 
>> Problem manifestation is a very high number of duplicated TGs (jdk.types.ThreadGroup) as part of JFR checkpoints.
>> 
>> Testing: jdk_jfr
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minimal window

Marked as reviewed by egahlin (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26558#pullrequestreview-3079642780

From ayang at openjdk.org  Fri Aug  1 15:49:03 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 1 Aug 2025 15:49:03 GMT
Subject: RFR: 8364518: Support for Job Objects in os::commit_memory_limit()
 on Windows
In-Reply-To: <ybsWeoo6MjS7HBqweDMwkVllcABSLyDcaOSNe828i6o=.8ae55f56-2042-4909-bb25-a1730e17ff64@github.com>
References: <ybsWeoo6MjS7HBqweDMwkVllcABSLyDcaOSNe828i6o=.8ae55f56-2042-4909-bb25-a1730e17ff64@github.com>
Message-ID: <bO9dI0YCHcV11uixaQTt20D6PU78IWDX8violfH4nYE=.d85c8e38-5268-4ad9-9f8c-28db717ceca5@github.com>

On Fri, 1 Aug 2025 10:38:32 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> We currently use os::commit_memory_limit() to limit the initial, min and max values when ergonomically setting the heap size. Right now, os::commit_memory_limit() returns the available virtual address space on Windows, which is guaranteed to be the upper-bound of how much memory can be committed. However, this does not take into account user-configurable limits.
> 
> I propose revising os::commit_memory_limit() to consider Windows Job Objects. Job Objects can, among other things, restrict the amount of memory that can be committed by a single process or all processes in a job. If we are unable to query Job Object information or if no limit is set, I suggest returning SIZE_MAX, since the next effective limit is the available virtual address space. The size of this virtual address space cannot be modified by the user, except by consuming it. 
> 
> For more details and short examples, I have created a GitHub repository summarizing my findings regarding memory limits and Job Objects on Windows: [https://github.com/jsikstro/MemoryLimitsWindows ](https://github.com/jsikstro/MemoryLimitsWindows).
> 
> Adding support for Job Objects in this way adds support for detecting memory limits when using native Windows Hyper-V containers, which uses Job Objects to limit memory.
> 
> Testing:
> * Oracles tier1-2
> * Manual testing on Windows using both [Process Governor](https://github.com/lowleveldesign/process-governor) (a popular tool), and creating a Job Object manually.

src/hotspot/os/windows/os_windows.cpp line 3306:

> 3304:   if (!res) {
> 3305:     return SIZE_MAX;
> 3306:   }

I wonder if it makes sense to print a warning or sth here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26593#discussion_r2248303775

From mgronlun at openjdk.org  Fri Aug  1 17:11:46 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 1 Aug 2025 17:11:46 GMT
Subject: RFR: 8364258: ThreadGroup constant pool serialization is not
 normalized [v7]
In-Reply-To: <gIJUvly5QIjQCZ8y483ZxIVRY292EivXkw5pXY_y8lY=.f600e5f0-677e-4c54-9bb0-8cc98598ab61@github.com>
References: <gIJUvly5QIjQCZ8y483ZxIVRY292EivXkw5pXY_y8lY=.f600e5f0-677e-4c54-9bb0-8cc98598ab61@github.com>
Message-ID: <RL0HEABjKoSMipI1YabLFVn1AHkPX1Lp5GHPFhC8oW0=.b7042043-53b5-4e0d-b8ac-9376402cab99@github.com>

> Greetings,
> 
> The following change set normalizes the ThreadGroup constants being serialized to the .jfr binary file.
> 
> It does this in two parts:
> 
> 1. Re-inserts a scavenging scheme to remove stale (unloaded) ThreadGroups; some logic that we used to have in place, but may have been lost as part of the major refactoring around JFR Event Streaming, or even earlier.
> 2. Introduces a per-epoch "is_serialized" scheme, building on top of JFR epoch generations.
> 
> Problem manifestation is a very high number of duplicated TGs (jdk.types.ThreadGroup) as part of JFR checkpoints.
> 
> Testing: jdk_jfr
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  handle no thread groups found

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26558/files
  - new: https://git.openjdk.org/jdk/pull/26558/files/c73a8f91..d3ae953c

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

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

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

From mgronlun at openjdk.org  Fri Aug  1 17:45:29 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 1 Aug 2025 17:45:29 GMT
Subject: RFR: 8364258: ThreadGroup constant pool serialization is not
 normalized [v8]
In-Reply-To: <gIJUvly5QIjQCZ8y483ZxIVRY292EivXkw5pXY_y8lY=.f600e5f0-677e-4c54-9bb0-8cc98598ab61@github.com>
References: <gIJUvly5QIjQCZ8y483ZxIVRY292EivXkw5pXY_y8lY=.f600e5f0-677e-4c54-9bb0-8cc98598ab61@github.com>
Message-ID: <llseRg_mbneeq4FuTVX2co5AWueZlv-kr1AO7wiI0og=.7edff125-24cd-44ce-9a6b-b3de11272d4a@github.com>

> Greetings,
> 
> The following change set normalizes the ThreadGroup constants being serialized to the .jfr binary file.
> 
> It does this in two parts:
> 
> 1. Re-inserts a scavenging scheme to remove stale (unloaded) ThreadGroups; some logic that we used to have in place, but may have been lost as part of the major refactoring around JFR Event Streaming, or even earlier.
> 2. Introduces a per-epoch "is_serialized" scheme, building on top of JFR epoch generations.
> 
> Problem manifestation is a very high number of duplicated TGs (jdk.types.ThreadGroup) as part of JFR checkpoints.
> 
> Testing: jdk_jfr
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  do not attempt to serialize a null thread group

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26558/files
  - new: https://git.openjdk.org/jdk/pull/26558/files/d3ae953c..7738eda8

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

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

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

From sspitsyn at openjdk.org  Sat Aug  2 04:21:54 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 2 Aug 2025 04:21:54 GMT
Subject: RFR: 8306324: StopThread results in thread being marked as
 interrupted, leading to unexpected InterruptedException [v7]
In-Reply-To: <Ci_ghq96Gr9rvBiRyA03gDvm958HGPANPME27TOIj6I=.a4097777-0ae1-4fe8-95c3-21dc6815ec68@github.com>
References: <sDAklD-arV33IpWiJwMkwUfNPMAmsr5cgboU4y0hjhk=.192cd7e5-f2a2-4b5c-83a9-5111bf1926ec@github.com>
 <uyFxRbd5zvitt4VhzYOUtefXo8o2pd1D2VN26jVDtYM=.d13c4b61-4583-4302-9692-cd391d767b9d@github.com>
 <0pW1wrr7ZPPK3faGmXIAhDi_f9pTaH-e6g8yVfw7g5o=.b068df42-b52d-4f1c-8c32-aaddd496d81f@github.com>
 <QGme_ns5Rq0uHLwC4SbATZBKpI1wVdDHEZQMQjZC5OE=.72572fe4-e6ef-495c-b2e8-ab4806f4cd83@github.com>
 <Ci_ghq96Gr9rvBiRyA03gDvm958HGPANPME27TOIj6I=.a4097777-0ae1-4fe8-95c3-21dc6815ec68@github.com>
Message-ID: <EhWU1LT4_7C4XHTajwU_0NKptPBoRXdn8l3VPZb_6TA=.d3c0f479-91e8-438c-b937-97d910771fac@github.com>

On Fri, 1 Aug 2025 14:06:41 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Should we always have `HAS_PENDING_EXCEPTION == true` if async exception was installed?
>> If so, then this newly added check is not really needed:
>> 
>>            if (!thread->has_async_exception_condition()) {
>
> Until we process the async exception handshake operation, `HAS_PENDING_EXCEPTION` will be false. The only way for `HAS_PENDING_EXCEPTION` to be true would be if we already entered the method with a pending exception, but I don?t see how that is possible.

Okay, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26365#discussion_r2249114695

From sspitsyn at openjdk.org  Sat Aug  2 04:24:59 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 2 Aug 2025 04:24:59 GMT
Subject: Integrated: 8306324: StopThread results in thread being marked as
 interrupted, leading to unexpected InterruptedException
In-Reply-To: <sDAklD-arV33IpWiJwMkwUfNPMAmsr5cgboU4y0hjhk=.192cd7e5-f2a2-4b5c-83a9-5111bf1926ec@github.com>
References: <sDAklD-arV33IpWiJwMkwUfNPMAmsr5cgboU4y0hjhk=.192cd7e5-f2a2-4b5c-83a9-5111bf1926ec@github.com>
Message-ID: <Xwm0UYjKWNwYTfuoWx_uYthzEMOvdcPLmQBIZ4bV8aQ=.40f0f0d7-6352-49b8-bfab-9e4742f683ba@github.com>

On Thu, 17 Jul 2025 10:12:16 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> If JVMTI `StopThread` is done when the thread is in certain various states (but not all states), after the `async` exception is delivered and handled, hotspot leaves the thread's `interrupted` flag set. The end result is the next time the thread does something like `Thread.sleep()`, it will immediately get an `InterruptedException`.
> 
> The fix is to clear the `interrupted` flag in the `JavaThread::handle_async_exception()` after an `async` pending exception has been set to be thrown with the `set_pending_exception()`.
> 
> There are a couple of concerns with this fix which would be nice to sort out with reviewers:
> 1.  The proposed fix may clear the interrupt state when it was already set prior to the issuing of the `StopThread()` (this concern was raised by @dholmes-ora in a comment of this JBS issue)
> 2.  The impacted code path is shared between the class `InstallAsyncExceptionHandshakeClosure` used by the JVMTI `StopThread` implementation and the class `ScopedAsyncExceptionHandshakeClosure` used by the `ScopedMemoryAccess`
> 
> I feel that clearing the `interrupted` flag byt the `JavaThread::handle_async_exception()` is a right thing to do even though it was set before the call to `JavaThread::install_async_exception()`. Also, it has to be done for both `StopThread` and `ScopedMemoryAccess`.
> 
> The fix also includes minor tweaks of the test `StopThreadTest` to make the issue reproducible with it.
> 
> Testing:
>  - Mach5 tiers 1-6 are passed
>  - Ran the updated reproducer test `hotspot/jtreg/serviceability/jvmti/vthread/StopThreadTest`

This pull request has now been integrated.

Changeset: e801e513
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e801e51311b3fb89bb08620dd5604c7ba9aed9df
Stats:     14 lines in 3 files changed: 4 ins; 4 del; 6 mod

8306324: StopThread results in thread being marked as interrupted, leading to unexpected InterruptedException

Reviewed-by: pchilanomate, alanb

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

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

From dholmes at openjdk.org  Sat Aug  2 07:00:59 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sat, 2 Aug 2025 07:00:59 GMT
Subject: RFR: 8306324: StopThread results in thread being marked as
 interrupted, leading to unexpected InterruptedException [v7]
In-Reply-To: <EhWU1LT4_7C4XHTajwU_0NKptPBoRXdn8l3VPZb_6TA=.d3c0f479-91e8-438c-b937-97d910771fac@github.com>
References: <sDAklD-arV33IpWiJwMkwUfNPMAmsr5cgboU4y0hjhk=.192cd7e5-f2a2-4b5c-83a9-5111bf1926ec@github.com>
 <uyFxRbd5zvitt4VhzYOUtefXo8o2pd1D2VN26jVDtYM=.d13c4b61-4583-4302-9692-cd391d767b9d@github.com>
 <0pW1wrr7ZPPK3faGmXIAhDi_f9pTaH-e6g8yVfw7g5o=.b068df42-b52d-4f1c-8c32-aaddd496d81f@github.com>
 <QGme_ns5Rq0uHLwC4SbATZBKpI1wVdDHEZQMQjZC5OE=.72572fe4-e6ef-495c-b2e8-ab4806f4cd83@github.com>
 <Ci_ghq96Gr9rvBiRyA03gDvm958HGPANPME27TOIj6I=.a4097777-0ae1-4fe8-95c3-21dc6815ec68@github.com>
 <EhWU1LT4_7C4XHTajwU_0NKptPBoRXdn8l3VPZb_6TA=.d3c0f479-91e8-438c-b937-97d910771fac@github.com>
Message-ID: <UYiH8x0c19PPGnMk2ou5yQqhj6u8yCcOTjOPvPesT9M=.7cbd2e1f-d39a-458a-9279-036e9ff7da8e@github.com>

On Sat, 2 Aug 2025 04:19:22 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Until we process the async exception handshake operation, `HAS_PENDING_EXCEPTION` will be false. The only way for `HAS_PENDING_EXCEPTION` to be true would be if we already entered the method with a pending exception, but I don?t see how that is possible.
>
> Okay, thanks!

I'm pretty sure that once-upon-a-time we would install any async exception in the `ThreadBlockInVM` destructor.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26365#discussion_r2249149459

From dholmes at openjdk.org  Sat Aug  2 07:05:59 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sat, 2 Aug 2025 07:05:59 GMT
Subject: RFR: 8306324: StopThread results in thread being marked as
 interrupted, leading to unexpected InterruptedException [v7]
In-Reply-To: <7LrTOiuQ3p-wZPtvdr-WkDPFzEawcmEeXzEtaIaJTrk=.5e74eda0-5414-4b13-935e-75f6f2a3f486@github.com>
References: <sDAklD-arV33IpWiJwMkwUfNPMAmsr5cgboU4y0hjhk=.192cd7e5-f2a2-4b5c-83a9-5111bf1926ec@github.com>
 <uyFxRbd5zvitt4VhzYOUtefXo8o2pd1D2VN26jVDtYM=.d13c4b61-4583-4302-9692-cd391d767b9d@github.com>
 <7LrTOiuQ3p-wZPtvdr-WkDPFzEawcmEeXzEtaIaJTrk=.5e74eda0-5414-4b13-935e-75f6f2a3f486@github.com>
Message-ID: <gSbD1dbSSdiQuRjyGsRh6iL0MLAqQZRBAK65DX3LmV0=.cb27028f-b78a-4450-85b4-0e23a1ec5af2@github.com>

On Fri, 1 Aug 2025 09:42:43 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> David, do you have any concerns or suggestions? Should I wait for your approval?

Sorry I was out of action for a couple of days. I'm happy to see the change to `sleep_nanos` restored. The change seems fine in the current state.

Though I have to wonder if there is any other non-directly-interruptible native blocking I/O operation that directly checks the interrupt flag and thus would see the stop request that way. Need to see if any Java library native code uses JNI to check the interrupt state.

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

PR Comment: https://git.openjdk.org/jdk/pull/26365#issuecomment-3146280109

From dholmes at openjdk.org  Sat Aug  2 07:09:56 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sat, 2 Aug 2025 07:09:56 GMT
Subject: RFR: 8349288: runtime/os/windows/TestAvailableProcessors.java
 fails on localized Windows platform [v9]
In-Reply-To: <UFTh0Uj9S9GAIdGwa1HTvabGFiJQxDnOoTU_t7W1vAA=.f22ef8ad-0660-4693-9d41-141d99983a2f@github.com>
References: <Ra31Q95DukIesp9Ivxsw4AYNOtqAm3JIeMSCtOHuTIM=.abd6dea4-4628-4983-9b38-642c21e792b5@github.com>
 <UFTh0Uj9S9GAIdGwa1HTvabGFiJQxDnOoTU_t7W1vAA=.f22ef8ad-0660-4693-9d41-141d99983a2f@github.com>
Message-ID: <ZJUkg_POYnlRTWxS2A-rOht6sBh2Eds2CIVSrKInXf4=.d4af71de-75e4-4af8-b684-a854211419ab@github.com>

On Wed, 25 Jun 2025 08:18:19 GMT, Kazuhisa Takakuri <ktakakuri at openjdk.org> wrote:

>> To resolve runtime/os/windows/TestAvailableProcessors.java failure, I made "systeminfo.exe" executed with "chcp 437". This ensures that the English message "OS Version: " is output on localized windows platforms.
>> I added the path C:\Windows\System32 to make chcp command recognized on the GHA Windows test machine. Without this addition, GHA will fail.
>> After this fix, I verified that the test passed.
>> 
>> https://github.com/openjdk/jdk/pull/22142
>> I refer to this fix.
>> tools/jpackage/windows/Win8301247Test.java does not run in GHA, so the problems with recognition of chcp command did not occur before.
>> 
>> Thanks.
>
> Kazuhisa Takakuri has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform

Sorry I did not see that further updates had occurred.

Seems okay.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23536#pullrequestreview-3080944747

From egahlin at openjdk.org  Sat Aug  2 07:40:59 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sat, 2 Aug 2025 07:40:59 GMT
Subject: RFR: 8364258: ThreadGroup constant pool serialization is not
 normalized [v8]
In-Reply-To: <llseRg_mbneeq4FuTVX2co5AWueZlv-kr1AO7wiI0og=.7edff125-24cd-44ce-9a6b-b3de11272d4a@github.com>
References: <gIJUvly5QIjQCZ8y483ZxIVRY292EivXkw5pXY_y8lY=.f600e5f0-677e-4c54-9bb0-8cc98598ab61@github.com>
 <llseRg_mbneeq4FuTVX2co5AWueZlv-kr1AO7wiI0og=.7edff125-24cd-44ce-9a6b-b3de11272d4a@github.com>
Message-ID: <12hEAV63qGAxWivowB48g9zieX19awQr9X0V3EUASR8=.3643cce7-d6fb-4e4a-80a5-d7c52fb40968@github.com>

On Fri, 1 Aug 2025 17:45:29 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> The following change set normalizes the ThreadGroup constants being serialized to the .jfr binary file.
>> 
>> It does this in two parts:
>> 
>> 1. Re-inserts a scavenging scheme to remove stale (unloaded) ThreadGroups; some logic that we used to have in place, but may have been lost as part of the major refactoring around JFR Event Streaming, or even earlier.
>> 2. Introduces a per-epoch "is_serialized" scheme, building on top of JFR epoch generations.
>> 
>> Problem manifestation is a very high number of duplicated TGs (jdk.types.ThreadGroup) as part of JFR checkpoints.
>> 
>> Testing: jdk_jfr
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   do not attempt to serialize a null thread group

Marked as reviewed by egahlin (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26558#pullrequestreview-3080950856

From syan at openjdk.org  Sat Aug  2 14:55:36 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 2 Aug 2025 14:55:36 GMT
Subject: RFR: 8362087: Test containers/docker/ShareTmpDir.java intermittent
 fails
Message-ID: <oSRNcbnXITyxH_EsCblndmwkjMgKFN0FOpeJ-HzEd7g=.2288123c-f4e6-42e9-87d9-2b0741f06335@github.com>

Hi all,

The test containers/docker/ShareTmpDir.java intermittent fails, because before this PR, test assume start two java process in docker container by two threads will make the two java process start simultancely, but in fact, the second java process maybe start slower than the first one, even that the first java process already exit and then the second java process not start yet. If we add `Thread.sleep(2000)` to the second thread at the begin of run() method, will make this intermittent failure to always reproduceable. This prove the anasyis.

If the two java process can not start simultancely, the expected '/tmp/hsperfdata_1 locked' error can not observed. So this test will intermittent fails.

This PR will check all the two java processes started already and runing simultancely before exit, this will make the expected '/tmp/hsperfdata_1 locked' error can be alway observed.

The touch file test/hotspot/jtreg/containers/docker/WaitForFlagFile.java only use for test containers/docker/ShareTmpDir.java.

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

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

Commit messages:
 - 8362087: Test containers/docker/ShareTmpDir.java intermittent fails

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

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

From duke at openjdk.org  Sat Aug  2 15:53:58 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Sat, 2 Aug 2025 15:53:58 GMT
Subject: RFR: 8362087: Test containers/docker/ShareTmpDir.java intermittent
 fails
In-Reply-To: <oSRNcbnXITyxH_EsCblndmwkjMgKFN0FOpeJ-HzEd7g=.2288123c-f4e6-42e9-87d9-2b0741f06335@github.com>
References: <oSRNcbnXITyxH_EsCblndmwkjMgKFN0FOpeJ-HzEd7g=.2288123c-f4e6-42e9-87d9-2b0741f06335@github.com>
Message-ID: <JZGgePZmm9opoloHpdF2FFiQjbT9uGJ85AAF-QMNfLM=.52956eb0-263b-46be-9411-3c7e73343e32@github.com>

On Sat, 2 Aug 2025 14:48:41 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> The test containers/docker/ShareTmpDir.java intermittent fails, because before this PR, test assume start two java process in docker container by two threads will make the two java process start simultancely, but in fact, the second java process maybe start slower than the first one, even that the first java process already exit and then the second java process not start yet. If we add `Thread.sleep(2000)` to the second thread at the begin of run() method, will make this intermittent failure to always reproduceable. This prove the anasyis.
> 
> If the two java process can not start simultancely, the expected '/tmp/hsperfdata_1 locked' error can not observed. So this test will intermittent fails.
> 
> This PR will check all the two java processes started already and runing simultancely before exit, this will make the expected '/tmp/hsperfdata_1 locked' error can be alway observed.
> 
> The touch file test/hotspot/jtreg/containers/docker/WaitForFlagFile.java only use for test containers/docker/ShareTmpDir.java.
> 
> Change has been verified locally, test-fix only, no risk.

test/hotspot/jtreg/containers/docker/ShareTmpDir.java line 86:

> 84:         Thread t1 = new Thread() {
> 85:                 public void run() {
> 86:                     opts.addClassOptions("1");

Is `addClassOptions` thread safe? I had a quick look and it didn't seem so

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26605#discussion_r2249295594

From syan at openjdk.org  Sun Aug  3 12:43:42 2025
From: syan at openjdk.org (SendaoYan)
Date: Sun, 3 Aug 2025 12:43:42 GMT
Subject: RFR: 8362087: Test containers/docker/ShareTmpDir.java intermittent
 fails [v2]
In-Reply-To: <oSRNcbnXITyxH_EsCblndmwkjMgKFN0FOpeJ-HzEd7g=.2288123c-f4e6-42e9-87d9-2b0741f06335@github.com>
References: <oSRNcbnXITyxH_EsCblndmwkjMgKFN0FOpeJ-HzEd7g=.2288123c-f4e6-42e9-87d9-2b0741f06335@github.com>
Message-ID: <0BdxR-lfZCypbrUa9jLchYXsLzDSkpdsRGRzALTH-Fg=.98f03a75-664c-4f20-9b2c-be9b61393638@github.com>

> Hi all,
> 
> The test containers/docker/ShareTmpDir.java intermittent fails, because before this PR, test assume start two java process in docker container by two threads will make the two java process start simultancely, but in fact, the second java process maybe start slower than the first one, even that the first java process already exit and then the second java process not start yet. If we add `Thread.sleep(2000)` to the second thread at the begin of run() method, will make this intermittent failure to always reproduceable. This prove the anasyis.
> 
> If the two java process can not start simultancely, the expected '/tmp/hsperfdata_1 locked' error can not observed. So this test will intermittent fails.
> 
> This PR will check all the two java processes started already and runing simultancely before exit, this will make the expected '/tmp/hsperfdata_1 locked' error can be alway observed.
> 
> The touch file test/hotspot/jtreg/containers/docker/WaitForFlagFile.java only use for test containers/docker/ShareTmpDir.java.
> 
> Change has been verified locally, test-fix only, no risk.

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

  Add synchronized lock for addClassOptions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26605/files
  - new: https://git.openjdk.org/jdk/pull/26605/files/7b00105f..284bda62

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

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

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

From syan at openjdk.org  Sun Aug  3 12:43:43 2025
From: syan at openjdk.org (SendaoYan)
Date: Sun, 3 Aug 2025 12:43:43 GMT
Subject: RFR: 8362087: Test containers/docker/ShareTmpDir.java intermittent
 fails [v2]
In-Reply-To: <JZGgePZmm9opoloHpdF2FFiQjbT9uGJ85AAF-QMNfLM=.52956eb0-263b-46be-9411-3c7e73343e32@github.com>
References: <oSRNcbnXITyxH_EsCblndmwkjMgKFN0FOpeJ-HzEd7g=.2288123c-f4e6-42e9-87d9-2b0741f06335@github.com>
 <JZGgePZmm9opoloHpdF2FFiQjbT9uGJ85AAF-QMNfLM=.52956eb0-263b-46be-9411-3c7e73343e32@github.com>
Message-ID: <7eRlpHHVp4r7kM9WMjqZzE-JG-UVem6snPR6xlTOZtE=.2aa59811-19ae-47be-a80f-e62f94de3725@github.com>

On Sat, 2 Aug 2025 15:51:07 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add synchronized lock for addClassOptions
>
> test/hotspot/jtreg/containers/docker/ShareTmpDir.java line 86:
> 
>> 84:         Thread t1 = new Thread() {
>> 85:                 public void run() {
>> 86:                     opts.addClassOptions("1");
> 
> Is `addClassOptions` thread safe? I had a quick look and it didn't seem so

Thanks for the reviews. I have add synchronized for both `opts.addClassOptions`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26605#discussion_r2249959172

From dholmes at openjdk.org  Sun Aug  3 21:10:56 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 3 Aug 2025 21:10:56 GMT
Subject: RFR: 8364314: java_lang_Thread::get_thread_status fails
 assert(base != nullptr) failed: Invalid base [v2]
In-Reply-To: <fshvnh428tQEdJRj5BMpEKrocg45Tls4jq4AbJ_idqE=.9a7915af-aeb8-44bf-801f-d97df4642115@github.com>
References: <ceYO3eEp5YWA4T5oDbw3Tqv0f-GUh2xTBqxjuWdsJl8=.f594db6c-8064-4a7a-a467-75ba86e950bd@github.com>
 <zEmmXnncIeBkHA6lfZBkOK3F19mjG1ExCad990UzhHM=.2c35f1aa-03c2-4588-8f4e-ce655c56256c@github.com>
 <fshvnh428tQEdJRj5BMpEKrocg45Tls4jq4AbJ_idqE=.9a7915af-aeb8-44bf-801f-d97df4642115@github.com>
Message-ID: <EtqAt6O_5Y78JYIg5W1O8cqXUwKDvdKLWIRoM0ypc4U=.26f4fbb5-5ce6-4c05-bd16-75609cfd1ff5@github.com>

On Wed, 30 Jul 2025 22:56:47 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Remove from ProblemList
>>  - Merge branch 'master' into 8364314-threadSMR
>>  - 8364314: java_lang_Thread::get_thread_status fails assert(base != nullptr) failed: Invalid base
>
> I just finished catching up on this other issue/PR:
> 
> [JDK-8361103](https://bugs.openjdk.org/browse/JDK-8361103) java_lang_Thread::async_get_stack_trace does not properly protect JavaThread
> https://github.com/openjdk/jdk/pull/26119
> 
> And this comment from @sspitsyn stuck out to me w.r.t. to this fix:
> 
> https://github.com/openjdk/jdk/pull/26119#discussion_r2209135122
> 
> 
> But, please, note that the JvmtiVTMSTransitionDisabler mechanism is enabled
> only when there is a JVMTI agent. Otherwise, it has been disabled for scalability
> purposes to exclude potentially high performance overhead at the VTMS
> transition points.
> 
> 
> The above comment from Serguei calls into question this suggested change that I posted on the PR:
> 
> https://github.com/openjdk/jdk/pull/26544/files#r2243188114
> 
> If the JvmtiVTMSTransitionDisabler only works when there's an agent attached,
> I don't think we're protecting the carrier thread at all since it can become unmounted
> at anytime when there's no agent.

@dcubed-ojdk I had already examined all the other clients of `cv_internal_thread_to_javaThread` and determined that they did not involve virtual threads - as referenced in our internal discussions. Unfortunately I forgot to put a comment to that affect in the JBS issue. In any case those usages are not relevant to the current PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/26544#issuecomment-3148699030

From dholmes at openjdk.org  Sun Aug  3 21:18:59 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 3 Aug 2025 21:18:59 GMT
Subject: RFR: 8364314: java_lang_Thread::get_thread_status fails
 assert(base != nullptr) failed: Invalid base [v2]
In-Reply-To: <E5dJotAuA9E6URmuDZ8qqEqR8a1XH3lUYEtPIPjo8YA=.2b6eb8eb-7688-4e90-833d-72af3db7eefa@github.com>
References: <ceYO3eEp5YWA4T5oDbw3Tqv0f-GUh2xTBqxjuWdsJl8=.f594db6c-8064-4a7a-a467-75ba86e950bd@github.com>
 <zEmmXnncIeBkHA6lfZBkOK3F19mjG1ExCad990UzhHM=.2c35f1aa-03c2-4588-8f4e-ce655c56256c@github.com>
 <E5dJotAuA9E6URmuDZ8qqEqR8a1XH3lUYEtPIPjo8YA=.2b6eb8eb-7688-4e90-833d-72af3db7eefa@github.com>
Message-ID: <Sg37S9R0s2wkTX2YNU78V_9JZ86K0NBLqH_fGRjsZKc=.3acbc900-f0f1-4816-9ba0-5de1a3f8179c@github.com>

On Wed, 30 Jul 2025 16:04:00 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Remove from ProblemList
>>  - Merge branch 'master' into 8364314-threadSMR
>>  - 8364314: java_lang_Thread::get_thread_status fails assert(base != nullptr) failed: Invalid base
>
> src/hotspot/share/services/threadService.cpp line 1487:
> 
>> 1485:     } else {
>> 1486:       // We may have previously found a carrier but since unmounted, so
>> 1487:       // clear that previous reference.
> 
> nit typo: s/but since unmounted/but it since unmounted.

I believe the grammar is correct. It could have said `have since unmounted`, but the `have` is not essential. However as I am expanding the later comment I may as well adjust this one.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26544#discussion_r2250138572

From dholmes at openjdk.org  Sun Aug  3 21:23:11 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 3 Aug 2025 21:23:11 GMT
Subject: RFR: 8364314: java_lang_Thread::get_thread_status fails
 assert(base != nullptr) failed: Invalid base [v3]
In-Reply-To: <ceYO3eEp5YWA4T5oDbw3Tqv0f-GUh2xTBqxjuWdsJl8=.f594db6c-8064-4a7a-a467-75ba86e950bd@github.com>
References: <ceYO3eEp5YWA4T5oDbw3Tqv0f-GUh2xTBqxjuWdsJl8=.f594db6c-8064-4a7a-a467-75ba86e950bd@github.com>
Message-ID: <znc_CIvq044Vk7l1pfCE51vKlQJqeuKWUwK8YScXlOQ=.43b20ad0-4d81-4b2f-94ea-3cb8ba5bfa64@github.com>

> After the changes in  JDK-8361912 we could "return " the carrier thread from `cv_internal_thread_to_JavaThread`, but before we hit the transition disabler the virtual thread could unmount. As a result when we execute this code:
> 
>   if (is_virtual) {
>     // 1st need to disable mount/unmount transitions
>     transition_disabler.init(jthread);
> 
>     carrier_thread = Handle(THREAD, java_lang_VirtualThread::carrier_thread(thread_h()));
>     if (carrier_thread != nullptr) {
>       java_thread = java_lang_Thread::thread(carrier_thread());
>     }
>   }
> 
> we hit the implicit else where "`carrier_thread == nullptr`" and we do nothing, but `java_thread` still holds the old carrier, which we then perform the handshake operation with:
> 
>   void do_thread(Thread* th) override {
>     Thread* current = Thread::current();
> 
>     bool is_virtual = java_lang_VirtualThread::is_instance(_thread_h());
>     if (_java_thread != nullptr) {
>       if (is_virtual) {
>         // mounted vthread, use carrier thread state
>         oop carrier_thread = java_lang_VirtualThread::carrier_thread(_thread_h());
>         _thread_status = java_lang_Thread::get_thread_status(carrier_thread);
>       } else {
> 
> But the `_java_thread` no longer has a carrier, so `get_thread_status` is passed null and we crash.
> 
> Simple fix is to clear `java_thread` when we find a null carrier oop. Also added an assert to guard against a null carrier oop in the handshake code, and added some additional commentary.
> 
> Testing:
>  - com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java
>  -  tier 5 and 6
> 
> Thanks

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

  Comments from Dan

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26544/files
  - new: https://git.openjdk.org/jdk/pull/26544/files/610186f1..96f92986

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

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

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

From dholmes at openjdk.org  Sun Aug  3 21:40:04 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 3 Aug 2025 21:40:04 GMT
Subject: RFR: 8364314: java_lang_Thread::get_thread_status fails
 assert(base != nullptr) failed: Invalid base [v2]
In-Reply-To: <E5dJotAuA9E6URmuDZ8qqEqR8a1XH3lUYEtPIPjo8YA=.2b6eb8eb-7688-4e90-833d-72af3db7eefa@github.com>
References: <ceYO3eEp5YWA4T5oDbw3Tqv0f-GUh2xTBqxjuWdsJl8=.f594db6c-8064-4a7a-a467-75ba86e950bd@github.com>
 <zEmmXnncIeBkHA6lfZBkOK3F19mjG1ExCad990UzhHM=.2c35f1aa-03c2-4588-8f4e-ce655c56256c@github.com>
 <E5dJotAuA9E6URmuDZ8qqEqR8a1XH3lUYEtPIPjo8YA=.2b6eb8eb-7688-4e90-833d-72af3db7eefa@github.com>
Message-ID: <946TA16iNlxe0auBXgwo6V8nrZrsZQnVufqBqd0qX30=.99710805-b883-42dc-996c-dc713e3541d4@github.com>

On Wed, 30 Jul 2025 16:08:09 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Remove from ProblemList
>>  - Merge branch 'master' into 8364314-threadSMR
>>  - 8364314: java_lang_Thread::get_thread_status fails assert(base != nullptr) failed: Invalid base
>
> src/hotspot/share/services/threadService.cpp line 1483:
> 
>> 1481:       // Note: this java_thread may not be protected by the ThreadsListHandle above,
>> 1482:       // but as we have disabled transitions, if we are mounted on it, then it can
>> 1483:       // not terminate and so is safe to handshake with.
> 
> Perhaps:
> 
>       // Note: The java_thread associated with this carrier_thread may not be
>       // protected by the ThreadsListHandle above. There could have been an
>       // unmount and remount after the ThreadsListHandle above was created
>       // and before the JvmtiVTMSTransitionDisabler was created. However, as
>       // we have disabled transitions, if we are mounted on it, then it cannot
>       // terminate and so is safe to handshake with.

Applied

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26544#discussion_r2250144301

From dholmes at openjdk.org  Sun Aug  3 21:40:05 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 3 Aug 2025 21:40:05 GMT
Subject: RFR: 8364314: java_lang_Thread::get_thread_status fails
 assert(base != nullptr) failed: Invalid base [v2]
In-Reply-To: <C7wF8ai41a466EU63pzNFUMT8sqm99ZAy5tFVVuYEh8=.adff2f27-c94e-4137-a3d0-583f9ffc5d9e@github.com>
References: <ceYO3eEp5YWA4T5oDbw3Tqv0f-GUh2xTBqxjuWdsJl8=.f594db6c-8064-4a7a-a467-75ba86e950bd@github.com>
 <zEmmXnncIeBkHA6lfZBkOK3F19mjG1ExCad990UzhHM=.2c35f1aa-03c2-4588-8f4e-ce655c56256c@github.com>
 <C7wF8ai41a466EU63pzNFUMT8sqm99ZAy5tFVVuYEh8=.adff2f27-c94e-4137-a3d0-583f9ffc5d9e@github.com>
Message-ID: <QsdUAdJcke43DXOycaXHfM1nNY5xStCow63-sJ_8cUk=.0d8166a7-835b-423c-a80c-1ecbd99b3d6c@github.com>

On Wed, 30 Jul 2025 23:51:27 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Remove from ProblemList
>>  - Merge branch 'master' into 8364314-threadSMR
>>  - 8364314: java_lang_Thread::get_thread_status fails assert(base != nullptr) failed: Invalid base
>
> src/hotspot/share/services/threadService.cpp line 1491:
> 
>> 1489:     }
>> 1490:   } else {
>> 1491:     java_thread = java_lang_Thread::thread(thread_h());
> 
> Preexistent after 8359870, but isn't this redundant? We should already have the target for this case.

Yes you are right. That part of the code was not directly visible in the earlier PRs and it got overlooked. But I would prefer to leave this for @AlanBateman to address as part of the change to remove the transition disabler. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26544#discussion_r2250144245

From dholmes at openjdk.org  Sun Aug  3 21:43:06 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 3 Aug 2025 21:43:06 GMT
Subject: RFR: 8364314: java_lang_Thread::get_thread_status fails
 assert(base != nullptr) failed: Invalid base [v2]
In-Reply-To: <-WeIeOX_JNhFcgNg8Y2NJzYPwQwxjVu0MMXPej6CJ3c=.830a06d9-4c22-49b8-8478-2831921518ab@github.com>
References: <ceYO3eEp5YWA4T5oDbw3Tqv0f-GUh2xTBqxjuWdsJl8=.f594db6c-8064-4a7a-a467-75ba86e950bd@github.com>
 <zEmmXnncIeBkHA6lfZBkOK3F19mjG1ExCad990UzhHM=.2c35f1aa-03c2-4588-8f4e-ce655c56256c@github.com>
 <-WeIeOX_JNhFcgNg8Y2NJzYPwQwxjVu0MMXPej6CJ3c=.830a06d9-4c22-49b8-8478-2831921518ab@github.com>
Message-ID: <MfdQC2mNc-UesItGcVNrL2gi8wy4q_E9pPxccfyNKAc=.25608001-3f6e-47fa-81d0-fa35a7c1d279@github.com>

On Thu, 31 Jul 2025 14:12:19 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Remove from ProblemList
>>  - Merge branch 'master' into 8364314-threadSMR
>>  - 8364314: java_lang_Thread::get_thread_status fails assert(base != nullptr) failed: Invalid base
>
> src/hotspot/share/services/threadService.cpp line 1281:
> 
>> 1279:         // mounted vthread, use carrier thread state
>> 1280:         oop carrier_thread = java_lang_VirtualThread::carrier_thread(_thread_h());
>> 1281:         assert(carrier_thread != nullptr, "should only get here for a mounted vthread");
> 
> This assert will trigger if unmounted when the handshake op runs. This is one of the transition cases. In the loom this is now changed to return so that the caller retries.

Yes but I am not trying to address the case of the disabler not functioning.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26544#discussion_r2250145163

From dholmes at openjdk.org  Sun Aug  3 21:50:01 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 3 Aug 2025 21:50:01 GMT
Subject: RFR: 8364314: java_lang_Thread::get_thread_status fails
 assert(base != nullptr) failed: Invalid base [v2]
In-Reply-To: <qM2GFxaVHmUUl6rwfOV1eXhNBp9KR0jAPJKJdWStVSg=.c9336fbe-3405-41e2-8165-2d5a178be45c@github.com>
References: <ceYO3eEp5YWA4T5oDbw3Tqv0f-GUh2xTBqxjuWdsJl8=.f594db6c-8064-4a7a-a467-75ba86e950bd@github.com>
 <zEmmXnncIeBkHA6lfZBkOK3F19mjG1ExCad990UzhHM=.2c35f1aa-03c2-4588-8f4e-ce655c56256c@github.com>
 <qM2GFxaVHmUUl6rwfOV1eXhNBp9KR0jAPJKJdWStVSg=.c9336fbe-3405-41e2-8165-2d5a178be45c@github.com>
Message-ID: <AyKZq6wm22W08drCnrHT6u5mAFdOEUWtuHuLDk53RDU=.bef8bcf7-9048-40e1-9c31-aab8fcfa74e6@github.com>

On Wed, 30 Jul 2025 09:31:50 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Remove from ProblemList
>>  - Merge branch 'master' into 8364314-threadSMR
>>  - 8364314: java_lang_Thread::get_thread_status fails assert(base != nullptr) failed: Invalid base
>
> Looks reasonable.

Thanks for the reviews @shipilev , @dcubed-ojdk , @pchilano and @sspitsyn .

As noted above this particular code is problematic for a range of reasons, but for now this fix maintains the pretense that the transition disabler actually works, and @AlanBateman will be fixing that as noted above.

Other clients of `cv_internal_thread_to_Java_thread` may potentially have issues if they ever have to deal with virtual threads (they currently don't or else are already being addressed), but that is not related to this fix, nor even the fix applied in JDK-8361912.

Thanks again for the reviews. If someone could re-review the comment changes that would be appreciated. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/26544#issuecomment-3148719468

From dholmes at openjdk.org  Sun Aug  3 22:31:57 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 3 Aug 2025 22:31:57 GMT
Subject: RFR: 8364106: Include java.runtime.version in thread dump output
In-Reply-To: <3mln0FWxBVHljWJixRL0M-hk9aD1Wf65iGKlfiK3dOo=.080c6cf8-d629-430c-9ca0-9f997f5701ac@github.com>
References: <lLL3n-lmOFiJnJ712idlTecQfw2mkVqeXTMLuVNv_j4=.f40bbb37-85e5-4fc5-8129-77320b6ebd79@github.com>
 <3mln0FWxBVHljWJixRL0M-hk9aD1Wf65iGKlfiK3dOo=.080c6cf8-d629-430c-9ca0-9f997f5701ac@github.com>
Message-ID: <MI63o4VZVYstucRwnhvPb29cNC9PKI5Z5JS3Ib4n7pw=.36810488-95ae-45ac-a83e-8b76098f3812@github.com>

On Tue, 29 Jul 2025 08:19:56 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Proposed output (similar to that produced for hs_err log):
>> 
>> 
>> Full thread dump Java HotSpot(TM) 64-Bit Server VM (26-internal-2025-07-28-0739549.daholme... mixed mode, sharing)
>>                  JRE version: Java(TM) SE Runtime Environment (26.0) (fastdebug build 26-internal-2025-07-28-0739549.daholme...)
>> 
>> Threads class SMR info:
>> ... 
>> 
>> Testing:
>>  - manual thread dump production via ctrl-\
>>  -  tiers 1-4 (sanity)
>> 
>> Potentially the null checks are not needed in this case as we should not be able to generate a thread dump until after things are initialized, but it doesn't really hurt.
>> 
>> Thanks
>
> Great to have this addition to the thread dump output. Thanks David.
> 
> Would there be merit to adding some test coverage for this ? Perhaps 1-2 extra lines in test/hotspot/jtreg/serviceability/dcmd/thread/PrintTest.java to check for the presence of "JRE version" etc. ?

Thanks for the reviews @coffeys and @AlanBateman !

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

PR Comment: https://git.openjdk.org/jdk/pull/26520#issuecomment-3148739423

From dholmes at openjdk.org  Sun Aug  3 22:31:58 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 3 Aug 2025 22:31:58 GMT
Subject: Integrated: 8364106: Include java.runtime.version in thread dump
 output
In-Reply-To: <lLL3n-lmOFiJnJ712idlTecQfw2mkVqeXTMLuVNv_j4=.f40bbb37-85e5-4fc5-8129-77320b6ebd79@github.com>
References: <lLL3n-lmOFiJnJ712idlTecQfw2mkVqeXTMLuVNv_j4=.f40bbb37-85e5-4fc5-8129-77320b6ebd79@github.com>
Message-ID: <iI0mQgJ__YvUqib65N14261SEXalwMgCYnOYtplE-ss=.c516bb84-4396-44d1-ae16-043037af188d@github.com>

On Mon, 28 Jul 2025 23:43:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Proposed output (similar to that produced for hs_err log):
> 
> 
> Full thread dump Java HotSpot(TM) 64-Bit Server VM (26-internal-2025-07-28-0739549.daholme... mixed mode, sharing)
>                  JRE version: Java(TM) SE Runtime Environment (26.0) (fastdebug build 26-internal-2025-07-28-0739549.daholme...)
> 
> Threads class SMR info:
> ... 
> 
> Testing:
>  - manual thread dump production via ctrl-\
>  -  tiers 1-4 (sanity)
> 
> Potentially the null checks are not needed in this case as we should not be able to generate a thread dump until after things are initialized, but it doesn't really hurt.
> 
> Thanks

This pull request has now been integrated.

Changeset: 158e59ab
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/158e59ab9184127089f9693ce256001f64b5945c
Stats:     19 lines in 2 files changed: 17 ins; 0 del; 2 mod

8364106: Include java.runtime.version in thread dump output

Reviewed-by: alanb, coffeys

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

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

From dholmes at openjdk.org  Sun Aug  3 22:47:04 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 3 Aug 2025 22:47:04 GMT
Subject: RFR: 8364235: Fix for JDK-8361447 breaks the alignment
 requirements for GuardedMemory [v4]
In-Reply-To: <PGNg5XV10TQ_DF2RuIymKXz0wmv7uahHHK-7kd4FZCI=.2361dfe2-ff05-4d3b-a2da-bc08512adbcc@github.com>
References: <2NMVt2xW6-rTS7vQPJ8fPkfabrTPiugEqGf4KlttYSo=.46b5d9f5-90b3-44b9-b3db-f139672145dc@github.com>
 <TekiCaaCeqBAmqGezDRHStSLT-b6VNv9J7VA-brCII0=.be40550e-52d1-442a-8422-e1e76c71929f@github.com>
 <PGNg5XV10TQ_DF2RuIymKXz0wmv7uahHHK-7kd4FZCI=.2361dfe2-ff05-4d3b-a2da-bc08512adbcc@github.com>
Message-ID: <UZ-GCxyDhSGIN71aAiIwYdUEY9bRHMFn4oKG21x3bvc=.d116eafd-3cc9-4e9b-aed0-275fd7cf010c@github.com>

On Wed, 30 Jul 2025 08:19:52 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   typo
>
> src/hotspot/share/memory/guardedMemory.hpp line 48:
> 
>> 46:  * |+sizeof(size_t)    | <tag>                | Tag word       |
>> 47:  * |+sizeof(void*)     | <tag2>               | Tag word       |
>> 48:  * |+sizeof(void*)     | 0xF1 <user_data> (   | User data      |
> 
> There's no mention of potential (and now actual) padding between <tag2> and <user_data> in this table.

Good point. I will add something.

> src/hotspot/share/memory/guardedMemory.hpp line 141:
> 
>> 139:    * to achieve this.
>> 140:    */
>> 141:   class alignas(16) GuardHeader : Guard {
> 
> Consider `alignas(std::max_align_t)`, since we're claiming it needs to be "maximally aligned".

But apparently `max_align_t` does not provide that - it provides the maximal alignment for scalar types, but "new-alignment" can be greater and it seems on Windows that is the case: we allocate at 16-byte alignment but `max_align_t` only has 8-byte alignment!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26524#discussion_r2250163963
PR Review Comment: https://git.openjdk.org/jdk/pull/26524#discussion_r2250163812

From dholmes at openjdk.org  Sun Aug  3 22:54:33 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 3 Aug 2025 22:54:33 GMT
Subject: RFR: 8364235: Fix for JDK-8361447 breaks the alignment
 requirements for GuardedMemory [v5]
In-Reply-To: <2NMVt2xW6-rTS7vQPJ8fPkfabrTPiugEqGf4KlttYSo=.46b5d9f5-90b3-44b9-b3db-f139672145dc@github.com>
References: <2NMVt2xW6-rTS7vQPJ8fPkfabrTPiugEqGf4KlttYSo=.46b5d9f5-90b3-44b9-b3db-f139672145dc@github.com>
Message-ID: <eJCKuEkAlCZO_9d_WbVzVLak_DwHS0pECnrhC6abF9o=.869327e0-f060-4584-a0a9-78453e305682@github.com>

> The fix for [JDK-8361447](https://bugs.openjdk.org/browse/JDK-8361447) added a new field to the `GuardHeader`, not realizing that the size of the `GuardHeader` must be such that the address of the user-data has the strictest necessary alignment (16-byte).
> 
> We need to add a padding field to restore the alignment.
> 
> A static assert is added to check the alignment.
> 
> Testing:
>  - tiers 1-3 (in progress)
> 
> Thanks

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

  Add "padding" to the layout description

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26524/files
  - new: https://git.openjdk.org/jdk/pull/26524/files/ab19a75d..e671ba73

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

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

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

From dholmes at openjdk.org  Sun Aug  3 22:54:34 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 3 Aug 2025 22:54:34 GMT
Subject: RFR: 8364235: Fix for JDK-8361447 breaks the alignment
 requirements for GuardedMemory [v4]
In-Reply-To: <5Vo_L-PB8eOItA8qo7e6M1ORq3HOLEJcydhHZ6EAIpk=.e9c509d5-3658-442f-b6bd-d413a0166252@github.com>
References: <2NMVt2xW6-rTS7vQPJ8fPkfabrTPiugEqGf4KlttYSo=.46b5d9f5-90b3-44b9-b3db-f139672145dc@github.com>
 <TekiCaaCeqBAmqGezDRHStSLT-b6VNv9J7VA-brCII0=.be40550e-52d1-442a-8422-e1e76c71929f@github.com>
 <5Vo_L-PB8eOItA8qo7e6M1ORq3HOLEJcydhHZ6EAIpk=.e9c509d5-3658-442f-b6bd-d413a0166252@github.com>
Message-ID: <pgoMuwlLX0ASB0EohWlvxkBiKu-Mo1kvN-b3faceHWc=.7b45c677-1aed-4551-bee0-abcf91ec751e@github.com>

On Wed, 30 Jul 2025 07:51:28 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   typo
>
> Marked as reviewed by aboldtch (Reviewer).

Thanks for the reviews @xmas92 and @jdksjolen !

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

PR Comment: https://git.openjdk.org/jdk/pull/26524#issuecomment-3148752697

From dholmes at openjdk.org  Mon Aug  4 01:45:52 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 4 Aug 2025 01:45:52 GMT
Subject: RFR: 8364514: [asan]
 runtime/jni/checked/TestCharArrayReleasing.java heap-buffer-overflow
In-Reply-To: <yZawVqmQPuYBMqD2OZnkWLMti0SWMxLn0vQQhbBL3MY=.784dd3f5-2826-4f86-802f-88e0a7b53087@github.com>
References: <yZawVqmQPuYBMqD2OZnkWLMti0SWMxLn0vQQhbBL3MY=.784dd3f5-2826-4f86-802f-88e0a7b53087@github.com>
Message-ID: <b5ZbNcF7ytMH7X2sUQKswlyY0c_eaMkDsTmPORuU-n4=.373c9b0b-63d9-4954-9164-f9b42c6ba25a@github.com>

On Fri, 1 Aug 2025 13:16:40 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running with ASAN enabled binaries , the test runtime/jni/checked/TestCharArrayReleasing.java fails with a  heap-buffer-overflow . This is expected because the test checks API usage errors and this way triggers ASAN.

Minor suggestion for the comment.

test/hotspot/jtreg/runtime/jni/checked/TestCharArrayReleasing.java line 28:

> 26:  * @bug 8357601
> 27:  * @requires vm.flagless
> 28:  * @comment array was allocated with raw malloc, this causes expected heap buffer issues and triggers asan

Suggestion:

 * @comment The check of the array allocated with raw malloc triggers ASAN as we peek into the malloc header space.

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26598#pullrequestreview-3082482433
PR Review Comment: https://git.openjdk.org/jdk/pull/26598#discussion_r2250246079

From dholmes at openjdk.org  Mon Aug  4 05:00:54 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 4 Aug 2025 05:00:54 GMT
Subject: RFR: 8263476: NMT: Stack guard pages should not be marked as
 committed
In-Reply-To: <BojYWaP10BJMEWDQYSRiMKR0cOWzMF5At9_3fwD6uUw=.becf6902-01f1-41e0-965d-18a945a6dfcf@github.com>
References: <BojYWaP10BJMEWDQYSRiMKR0cOWzMF5At9_3fwD6uUw=.becf6902-01f1-41e0-965d-18a945a6dfcf@github.com>
Message-ID: <vhnbuIIoBNpQgMAO4mAjJiYxv9YoCT-3pggvgrNBC6o=.f584ea17-1c0b-4469-a8d2-60f7ac8e7405@github.com>

On Thu, 31 Jul 2025 10:36:59 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Use reserved (instead of committed) memory for stack-guard-pages on linux like systems.
> 
> `os::must_commit_stack_guard_pages` uses `commit` in its name, but `commit` usually has specific meanings in OS memory context. The actual question the caller is asking is whether the caller needs to do some preparation work before marking the guard-pages as inaccessible. To avoid confusion, I changed it to "allocate". Other suggestions are welcome.
> 
> Test: tier1-3

I'm unclear what is actually meant by "commit" in the context of `os::must_commit_memory` but your proposal actually reverses the change that named it this way ([JDK-8159335](https://bugs.openjdk.org/browse/JDK-8159335)):

https://hg.openjdk.org/jdk9/jdk9/hotspot/rev/3950d1713ffa

This also seems a bit different to what @jdksjolen previously suggested in https://github.com/openjdk/jdk/pull/14896/. ??

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

PR Comment: https://git.openjdk.org/jdk/pull/26571#issuecomment-3149129649

From dholmes at openjdk.org  Mon Aug  4 05:24:01 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 4 Aug 2025 05:24:01 GMT
Subject: RFR: 8364235: Fix for JDK-8361447 breaks the alignment
 requirements for GuardedMemory [v5]
In-Reply-To: <eJCKuEkAlCZO_9d_WbVzVLak_DwHS0pECnrhC6abF9o=.869327e0-f060-4584-a0a9-78453e305682@github.com>
References: <2NMVt2xW6-rTS7vQPJ8fPkfabrTPiugEqGf4KlttYSo=.46b5d9f5-90b3-44b9-b3db-f139672145dc@github.com>
 <eJCKuEkAlCZO_9d_WbVzVLak_DwHS0pECnrhC6abF9o=.869327e0-f060-4584-a0a9-78453e305682@github.com>
Message-ID: <qDnzeewoudJ1mUIJd3LXLYnoTWYdVsbOwfqFpNGgRP4=.e8786e6f-c77c-402f-b0eb-747ba2fe7526@github.com>

On Sun, 3 Aug 2025 22:54:33 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The fix for [JDK-8361447](https://bugs.openjdk.org/browse/JDK-8361447) added a new field to the `GuardHeader`, not realizing that the size of the `GuardHeader` must be such that the address of the user-data has the strictest necessary alignment (16-byte).
>> 
>> We need to add a padding field to restore the alignment.
>> 
>> A static assert is added to check the alignment.
>> 
>> Testing:
>>  - tiers 1-3 (in progress)
>> 
>> Thanks
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add "padding" to the layout description

@kimbarrett and I discussed this further at some length after I flagged the `max_align_t` issue. On further analysis, considering in particular 32-bit systems, there is no guarantee that we actually get a properly aligned based address with `alignas(16)` when we are malloc'ing ourselves, as the "new alignment" may only be 8-bytes not 16-bytes. To deal with that Kim suggested revising the the `GuardedMemory` calculations so that we use `align_up(size, 16)` ensure the user-data will actually placed on a 16-byte boundary, regardless of the initial placement of the `GuardHeader` or its size. I am working on that revision.

I also want to investigate a potential regression test.

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

PR Comment: https://git.openjdk.org/jdk/pull/26524#issuecomment-3149161654

From jsikstro at openjdk.org  Mon Aug  4 07:40:12 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 4 Aug 2025 07:40:12 GMT
Subject: RFR: 8364518: Support for Job Objects in os::commit_memory_limit()
 on Windows [v2]
In-Reply-To: <ybsWeoo6MjS7HBqweDMwkVllcABSLyDcaOSNe828i6o=.8ae55f56-2042-4909-bb25-a1730e17ff64@github.com>
References: <ybsWeoo6MjS7HBqweDMwkVllcABSLyDcaOSNe828i6o=.8ae55f56-2042-4909-bb25-a1730e17ff64@github.com>
Message-ID: <1yjYw2L7Jta-_-v0KPNcvz8wS9arjOCzvrwQpZ6sP6k=.186ac2f0-6d5f-4dd6-bcdb-839841847f25@github.com>

> Hello,
> 
> We currently use os::commit_memory_limit() to limit the initial, min and max values when ergonomically setting the heap size. Right now, os::commit_memory_limit() returns the available virtual address space on Windows, which is guaranteed to be the upper-bound of how much memory can be committed. However, this does not take into account user-configurable limits.
> 
> I propose revising os::commit_memory_limit() to consider Windows Job Objects. Job Objects can, among other things, restrict the amount of memory that can be committed by a single process or all processes in a job. If we are unable to query Job Object information or if no limit is set, I suggest returning SIZE_MAX, since the next effective limit is the available virtual address space. The size of this virtual address space cannot be modified by the user, except by consuming it. 
> 
> For more details and short examples, I have created a GitHub repository summarizing my findings regarding memory limits and Job Objects on Windows: [https://github.com/jsikstro/MemoryLimitsWindows ](https://github.com/jsikstro/MemoryLimitsWindows).
> 
> Adding support for Job Objects in this way adds support for detecting memory limits when using native Windows Hyper-V containers, which uses Job Objects to limit memory.
> 
> Testing:
> * Oracles tier1-2
> * Manual testing on Windows using both [Process Governor](https://github.com/lowleveldesign/process-governor) (a popular tool), and creating a Job Object manually.

Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:

  Print error message if query fails

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26593/files
  - new: https://git.openjdk.org/jdk/pull/26593/files/436e2160..eb446664

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

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

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

From jsikstro at openjdk.org  Mon Aug  4 07:40:12 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 4 Aug 2025 07:40:12 GMT
Subject: RFR: 8364518: Support for Job Objects in os::commit_memory_limit()
 on Windows [v2]
In-Reply-To: <bO9dI0YCHcV11uixaQTt20D6PU78IWDX8violfH4nYE=.d85c8e38-5268-4ad9-9f8c-28db717ceca5@github.com>
References: <ybsWeoo6MjS7HBqweDMwkVllcABSLyDcaOSNe828i6o=.8ae55f56-2042-4909-bb25-a1730e17ff64@github.com>
 <bO9dI0YCHcV11uixaQTt20D6PU78IWDX8violfH4nYE=.d85c8e38-5268-4ad9-9f8c-28db717ceca5@github.com>
Message-ID: <z_s47BDzvGSDd8fOJKD4H3pKYnqW6vDzwNbJ8pdMNRs=.879439a2-1eec-49f1-8ebc-a3f00ff2417a@github.com>

On Fri, 1 Aug 2025 15:46:19 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Print error message if query fails
>
> src/hotspot/os/windows/os_windows.cpp line 3306:
> 
>> 3304:   if (!res) {
>> 3305:     return SIZE_MAX;
>> 3306:   }
> 
> I wonder if it makes sense to print a warning or sth here.

Looking at how `QueryInformationJobObject` is used in `os::win32::active_processors_in_job_object()`, which is the only other place where it is called, we do this when querying fails:


char buf[512];
size_t buf_len = os::lasterror(buf, sizeof(buf));
warning("Attempt to query job object information failed: %s", buf_len != 0 ? buf : "<unknown error>");


I'll add this to the code to be consistent with hos `os::win32::active_processors_in_job_object()` works, but I'm open to new suggestions as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26593#discussion_r2250657359

From ayang at openjdk.org  Mon Aug  4 07:52:59 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 4 Aug 2025 07:52:59 GMT
Subject: RFR: 8364518: Support for Job Objects in os::commit_memory_limit()
 on Windows [v2]
In-Reply-To: <1yjYw2L7Jta-_-v0KPNcvz8wS9arjOCzvrwQpZ6sP6k=.186ac2f0-6d5f-4dd6-bcdb-839841847f25@github.com>
References: <ybsWeoo6MjS7HBqweDMwkVllcABSLyDcaOSNe828i6o=.8ae55f56-2042-4909-bb25-a1730e17ff64@github.com>
 <1yjYw2L7Jta-_-v0KPNcvz8wS9arjOCzvrwQpZ6sP6k=.186ac2f0-6d5f-4dd6-bcdb-839841847f25@github.com>
Message-ID: <WbJq2GmIDl-xGFt3MsmGIpfbYlpE2m5LdIHbZM7cwX8=.ddf80ad8-400d-4faa-9b2d-15cbed66664f@github.com>

On Mon, 4 Aug 2025 07:40:12 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> We currently use os::commit_memory_limit() to limit the initial, min and max values when ergonomically setting the heap size. Right now, os::commit_memory_limit() returns the available virtual address space on Windows, which is guaranteed to be the upper-bound of how much memory can be committed. However, this does not take into account user-configurable limits.
>> 
>> I propose revising os::commit_memory_limit() to consider Windows Job Objects. Job Objects can, among other things, restrict the amount of memory that can be committed by a single process or all processes in a job. If we are unable to query Job Object information or if no limit is set, I suggest returning SIZE_MAX, since the next effective limit is the available virtual address space. The size of this virtual address space cannot be modified by the user, except by consuming it. 
>> 
>> For more details and short examples, I have created a GitHub repository summarizing my findings regarding memory limits and Job Objects on Windows: [https://github.com/jsikstro/MemoryLimitsWindows ](https://github.com/jsikstro/MemoryLimitsWindows).
>> 
>> Adding support for Job Objects in this way adds support for detecting memory limits when using native Windows Hyper-V containers, which uses Job Objects to limit memory.
>> 
>> Testing:
>> * Oracles tier1-2
>> * Manual testing on Windows using both [Process Governor](https://github.com/lowleveldesign/process-governor) (a popular tool), and creating a Job Object manually.
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Print error message if query fails

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26593#pullrequestreview-3083085532

From dholmes at openjdk.org  Mon Aug  4 08:01:59 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 4 Aug 2025 08:01:59 GMT
Subject: RFR: 8359820: Improve handshake/safepoint timeout diagnostic
 messages [v7]
In-Reply-To: <f8ydKyrpfDyPHFCFJ5mwuq2Uk2z_ZoLllhoDyS1Dy_4=.4308b09b-a7aa-46ce-9e59-7a9b57c7e7c8@github.com>
References: <FZ87bVfDootrLeANGguMFpcTm7X8AEqzuKVQspmSkmE=.4484090b-ba49-498c-bb07-71d22fd34823@github.com>
 <f8ydKyrpfDyPHFCFJ5mwuq2Uk2z_ZoLllhoDyS1Dy_4=.4308b09b-a7aa-46ce-9e59-7a9b57c7e7c8@github.com>
Message-ID: <nHm5k4_ouXadeNKh1_6PN14gWqTsX0zVT__410-hQwQ=.7515ae86-2c51-4850-bc42-20df14f89e7c@github.com>

On Mon, 28 Jul 2025 10:10:59 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> The problem in the issue description is not a problem by itself, the behavior is not unexpected, but it is somewhat difficult to find out what caused SIGILL to be fired.
>> 
>> We propagate this information from `handshake::handle_timeout()` to `VMError::report()` with a help of a global variable.  The same mechanism is used to address a similar issue in the safepoint timeout handler. 
>> 
>> Tested in tiers 1-3.
>
> Anton Artemov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8359820: Addressed reviewer's comments
>  - 8359820: Addressed reviewer's comments

src/hotspot/share/utilities/vmError.cpp line 108:

> 106: const intptr_t    VMError::segfault_address = pd_segfault_address;
> 107: volatile intptr_t VMError::_handshake_timeout_thread = p2i(nullptr);
> 108: volatile intptr_t VMError::_safepoint_timeout_thread = p2i(nullptr);

Sorry there was a typo in my suggestion - it should be `timed_out` to match the function names. (Or change the functions to use `timedout` - I tend to use `timedout` as a single "word" in these contexts.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26309#discussion_r2250716621

From amenkov at openjdk.org  Mon Aug  4 08:07:57 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Mon, 4 Aug 2025 08:07:57 GMT
Subject: RFR: 8364314: java_lang_Thread::get_thread_status fails
 assert(base != nullptr) failed: Invalid base [v3]
In-Reply-To: <znc_CIvq044Vk7l1pfCE51vKlQJqeuKWUwK8YScXlOQ=.43b20ad0-4d81-4b2f-94ea-3cb8ba5bfa64@github.com>
References: <ceYO3eEp5YWA4T5oDbw3Tqv0f-GUh2xTBqxjuWdsJl8=.f594db6c-8064-4a7a-a467-75ba86e950bd@github.com>
 <znc_CIvq044Vk7l1pfCE51vKlQJqeuKWUwK8YScXlOQ=.43b20ad0-4d81-4b2f-94ea-3cb8ba5bfa64@github.com>
Message-ID: <4nUxjeu2NqpgvZffx0CkskUqBD16Y4ZGIXbbG93mPos=.dfc8cb75-ca0e-46f9-a9ea-4fcbc755e50d@github.com>

On Sun, 3 Aug 2025 21:23:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> After the changes in  JDK-8361912 we could "return " the carrier thread from `cv_internal_thread_to_JavaThread`, but before we hit the transition disabler the virtual thread could unmount. As a result when we execute this code:
>> 
>>   if (is_virtual) {
>>     // 1st need to disable mount/unmount transitions
>>     transition_disabler.init(jthread);
>> 
>>     carrier_thread = Handle(THREAD, java_lang_VirtualThread::carrier_thread(thread_h()));
>>     if (carrier_thread != nullptr) {
>>       java_thread = java_lang_Thread::thread(carrier_thread());
>>     }
>>   }
>> 
>> we hit the implicit else where "`carrier_thread == nullptr`" and we do nothing, but `java_thread` still holds the old carrier, which we then perform the handshake operation with:
>> 
>>   void do_thread(Thread* th) override {
>>     Thread* current = Thread::current();
>> 
>>     bool is_virtual = java_lang_VirtualThread::is_instance(_thread_h());
>>     if (_java_thread != nullptr) {
>>       if (is_virtual) {
>>         // mounted vthread, use carrier thread state
>>         oop carrier_thread = java_lang_VirtualThread::carrier_thread(_thread_h());
>>         _thread_status = java_lang_Thread::get_thread_status(carrier_thread);
>>       } else {
>> 
>> But the `_java_thread` no longer has a carrier, so `get_thread_status` is passed null and we crash.
>> 
>> Simple fix is to clear `java_thread` when we find a null carrier oop. Also added an assert to guard against a null carrier oop in the handshake code, and added some additional commentary.
>> 
>> Testing:
>>  - com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java
>>  -  tier 5 and 6
>> 
>> Thanks
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comments from Dan

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26544#pullrequestreview-3083138979

From duke at openjdk.org  Mon Aug  4 08:37:23 2025
From: duke at openjdk.org (Anton Artemov)
Date: Mon, 4 Aug 2025 08:37:23 GMT
Subject: RFR: 8359820: Improve handshake/safepoint timeout diagnostic
 messages [v8]
In-Reply-To: <FZ87bVfDootrLeANGguMFpcTm7X8AEqzuKVQspmSkmE=.4484090b-ba49-498c-bb07-71d22fd34823@github.com>
References: <FZ87bVfDootrLeANGguMFpcTm7X8AEqzuKVQspmSkmE=.4484090b-ba49-498c-bb07-71d22fd34823@github.com>
Message-ID: <J_7p0R3HxKsa1KG_w6EoFPj0dcm7_POhnRxDRtHW_EI=.7d3147fe-f47c-45ab-abf3-04ce48a2524d@github.com>

> Hi, please consider the following changes:
> 
> The problem in the issue description is not a problem by itself, the behavior is not unexpected, but it is somewhat difficult to find out what caused SIGILL to be fired.
> 
> We propagate this information from `handshake::handle_timeout()` to `VMError::report()` with a help of a global variable.  The same mechanism is used to address a similar issue in the safepoint timeout handler. 
> 
> Tested in tiers 1-3.

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

 - 8359820: Addressed reviewer's comments
 - Merge remote-tracking branch 'origin/master' into JDK-8359820-SIGILL-with-low-handshake-timeout-on-intel-sde
 - 8359820: Addressed reviewer's comments
 - 8359820: Addressed reviewer's comments
 - Merge remote-tracking branch 'origin/master' into JDK-8359820-SIGILL-with-low-handshake-timeout-on-intel-sde
 - 8359820: Fixed spaces
 - 8359820: Addressed reviewer's comments
 - 8359820: Addressed reviewer's comments
 - 8359820: Addressed reviewer's comments
 - Merge remote-tracking branch 'origin/master' into JDK-8359820-SIGILL-with-low-handshake-timeout-on-intel-sde
 - ... and 7 more: https://git.openjdk.org/jdk/compare/be8a196c...d85769af

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26309/files
  - new: https://git.openjdk.org/jdk/pull/26309/files/9c914a50..d85769af

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

  Stats: 13107 lines in 357 files changed: 8735 ins; 3598 del; 774 mod
  Patch: https://git.openjdk.org/jdk/pull/26309.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26309/head:pull/26309

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

From duke at openjdk.org  Mon Aug  4 08:37:23 2025
From: duke at openjdk.org (Anton Artemov)
Date: Mon, 4 Aug 2025 08:37:23 GMT
Subject: RFR: 8359820: Improve handshake/safepoint timeout diagnostic
 messages [v7]
In-Reply-To: <nHm5k4_ouXadeNKh1_6PN14gWqTsX0zVT__410-hQwQ=.7515ae86-2c51-4850-bc42-20df14f89e7c@github.com>
References: <FZ87bVfDootrLeANGguMFpcTm7X8AEqzuKVQspmSkmE=.4484090b-ba49-498c-bb07-71d22fd34823@github.com>
 <f8ydKyrpfDyPHFCFJ5mwuq2Uk2z_ZoLllhoDyS1Dy_4=.4308b09b-a7aa-46ce-9e59-7a9b57c7e7c8@github.com>
 <nHm5k4_ouXadeNKh1_6PN14gWqTsX0zVT__410-hQwQ=.7515ae86-2c51-4850-bc42-20df14f89e7c@github.com>
Message-ID: <S8YDHks_-WRlLVRv00j71tFtGqHIj-BPCdqG-K-1EjU=.18b5c5be-8bb7-466e-81a3-6b178980a260@github.com>

On Mon, 4 Aug 2025 07:59:13 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8359820: Addressed reviewer's comments
>>  - 8359820: Addressed reviewer's comments
>
> src/hotspot/share/utilities/vmError.cpp line 108:
> 
>> 106: const intptr_t    VMError::segfault_address = pd_segfault_address;
>> 107: volatile intptr_t VMError::_handshake_timeout_thread = p2i(nullptr);
>> 108: volatile intptr_t VMError::_safepoint_timeout_thread = p2i(nullptr);
> 
> Sorry there was a typo in my suggestion - it should be `timed_out` to match the function names. (Or change the functions to use `timedout` - I tend to use `timedout` as a single "word" in these contexts.

Thanks for spotting, addressed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26309#discussion_r2250798694

From ayang at openjdk.org  Mon Aug  4 09:38:53 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 4 Aug 2025 09:38:53 GMT
Subject: RFR: 8263476: NMT: Stack guard pages should not be marked as
 committed
In-Reply-To: <vhnbuIIoBNpQgMAO4mAjJiYxv9YoCT-3pggvgrNBC6o=.f584ea17-1c0b-4469-a8d2-60f7ac8e7405@github.com>
References: <BojYWaP10BJMEWDQYSRiMKR0cOWzMF5At9_3fwD6uUw=.becf6902-01f1-41e0-965d-18a945a6dfcf@github.com>
 <vhnbuIIoBNpQgMAO4mAjJiYxv9YoCT-3pggvgrNBC6o=.f584ea17-1c0b-4469-a8d2-60f7ac8e7405@github.com>
Message-ID: <k4xyIM2trrZ26xsyTtCKyO5WyaHGQ4n-krlcAsdqJpg=.adb2baab-b595-4f51-a26d-a70b004a8942@github.com>

On Mon, 4 Aug 2025 04:58:13 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I'm unclear what is actually meant by "commit" in the context of ...

It has the same meaning as "commit" in `os::commit_memory` APIs -- OS promises to offer such memory when accessed, i.e. memory has read/write permission and is accounted in `Committed_AS` on Linux, for example.

> your proposal actually reverses the change that named it this way (JDK-8159335):

That PR used the more precise wording at that time, because we DO commit memory for stack-guard-pages. This PR, however, implements reserve-only memory for stack-guard-pages. In order to avoid confusion, I lifted up the abstraction (back to its original name), because one platform still requires stack-guard-pages to be committed.

The stack-guard-page logic is just invoking `os::guard_memory` on the stack-guard-pages, but among all platforms defined in `src/hotspot/os`, there are 2 platforms that require special treatment, i.e. some preparation work before calling `guard_memory`.

## Linux

In `os::create_attached_thread`, we can see the stack is mapped on demand for primordial thread (main-thread). Therefore, we need to ensure the stack-guard-pages are actually reserved. Handled in the `pd_create_stack_guard_pages` of the current PR. Other threads (non-main-threads) pre-reserve the whole stack, so they don't need special treatment.

## Windows

`guard_memory` requires to-be-guarded memory to be committed.

>From https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualprotect:

"You can set the access protection value on committed pages only."

Therefore, the preparation work for this platform is to commit stack-guard-pages.

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

PR Comment: https://git.openjdk.org/jdk/pull/26571#issuecomment-3149830241

From mgronlun at openjdk.org  Mon Aug  4 09:47:10 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 4 Aug 2025 09:47:10 GMT
Subject: Integrated: 8364258: ThreadGroup constant pool serialization is not
 normalized
In-Reply-To: <gIJUvly5QIjQCZ8y483ZxIVRY292EivXkw5pXY_y8lY=.f600e5f0-677e-4c54-9bb0-8cc98598ab61@github.com>
References: <gIJUvly5QIjQCZ8y483ZxIVRY292EivXkw5pXY_y8lY=.f600e5f0-677e-4c54-9bb0-8cc98598ab61@github.com>
Message-ID: <euFWC6ke4itOLmIdimnZMaSKA75dlaQL64PdplcIebs=.b91f630e-eafc-4883-a81c-8e5baf7d3587@github.com>

On Wed, 30 Jul 2025 16:08:59 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> The following change set normalizes the ThreadGroup constants being serialized to the .jfr binary file.
> 
> It does this in two parts:
> 
> 1. Re-inserts a scavenging scheme to remove stale (unloaded) ThreadGroups; some logic that we used to have in place, but may have been lost as part of the major refactoring around JFR Event Streaming, or even earlier.
> 2. Introduces a per-epoch "is_serialized" scheme, building on top of JFR epoch generations.
> 
> Problem manifestation is a very high number of duplicated TGs (jdk.types.ThreadGroup) as part of JFR checkpoints.
> 
> Testing: jdk_jfr
> 
> Thanks
> Markus

This pull request has now been integrated.

Changeset: 3bc44979
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3bc449797eb59f9770d2a06d260b23b6efd5ff0f
Stats:     938 lines in 12 files changed: 431 ins; 482 del; 25 mod

8364258: ThreadGroup constant pool serialization is not normalized

Reviewed-by: egahlin

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

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

From egahlin at openjdk.org  Mon Aug  4 12:26:53 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 4 Aug 2025 12:26:53 GMT
Subject: [jdk25] RFR: 8364258: ThreadGroup constant pool serialization is
 not normalized
In-Reply-To: <DvqtMLpkKmkZfiok2e6ygYAFV33h2bw26MizV2vCsH4=.1dde3ebd-1e66-4307-9d9d-8d5412a50151@github.com>
References: <DvqtMLpkKmkZfiok2e6ygYAFV33h2bw26MizV2vCsH4=.1dde3ebd-1e66-4307-9d9d-8d5412a50151@github.com>
Message-ID: <ZKYzjYYBmZeTywgBlVuQswA3MTVpUk7inJoO0oTrxrI=.ac94355d-5bcb-4a9b-a176-682640506e18@github.com>

On Mon, 4 Aug 2025 09:52:42 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> 8364258: ThreadGroup constant pool serialization is not normalized

Marked as reviewed by egahlin (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26618#pullrequestreview-3083961842

From jsjolen at openjdk.org  Mon Aug  4 12:37:01 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 4 Aug 2025 12:37:01 GMT
Subject: RFR: 8263476: NMT: Stack guard pages should not be marked as
 committed
In-Reply-To: <BojYWaP10BJMEWDQYSRiMKR0cOWzMF5At9_3fwD6uUw=.becf6902-01f1-41e0-965d-18a945a6dfcf@github.com>
References: <BojYWaP10BJMEWDQYSRiMKR0cOWzMF5At9_3fwD6uUw=.becf6902-01f1-41e0-965d-18a945a6dfcf@github.com>
Message-ID: <Kwrb1dkkecP2tFGM7IZxYiKN_9ke4u5xtje3G05V5H0=.9d830cad-a360-4fc0-a4a5-2fe6e01f0b91@github.com>

On Thu, 31 Jul 2025 10:36:59 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Use reserved (instead of committed) memory for stack-guard-pages on linux like systems.
> 
> `os::must_commit_stack_guard_pages` uses `commit` in its name, but `commit` usually has specific meanings in OS memory context. The actual question the caller is asking is whether the caller needs to do some preparation work before marking the guard-pages as inaccessible. To avoid confusion, I changed it to "allocate". Other suggestions are welcome.
> 
> Test: tier1-3

src/hotspot/os/linux/os_linux.cpp line 3455:

> 3453: 
> 3454:     if (stack_extent < (uintptr_t)addr + size) {
> 3455:       ::munmap((void*)stack_extent, (uintptr_t)(addr + size - stack_extent));

Could you explain this, is it fixing a pre-existing bug as well?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26571#discussion_r2251354077

From fbredberg at openjdk.org  Mon Aug  4 12:52:39 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Mon, 4 Aug 2025 12:52:39 GMT
Subject: RFR: 8364141: Remove LockingMode related code from x86 [v2]
In-Reply-To: <g7WNqmFlJOkai-zeEjD09M5TwpL3fAMkZUAy37b747U=.faa6d9f5-1894-4507-a0f1-1dd41f3bdd43@github.com>
References: <g7WNqmFlJOkai-zeEjD09M5TwpL3fAMkZUAy37b747U=.faa6d9f5-1894-4507-a0f1-1dd41f3bdd43@github.com>
Message-ID: <m3XncMjv5FTFkwbb-G3_LPmzaD0umC3f6d8MUgHMdg4=.ebe5d5a3-4078-4e10-b441-3cc8d5a5a177@github.com>

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
> 
> This PR removes `LockingMode` related code from the **x86** platform.
> 
> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.
> 
> Passes tier1-tier5 with no added problems.

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

  Update one after review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26552/files
  - new: https://git.openjdk.org/jdk/pull/26552/files/9290d4ad..2a052186

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

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

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

From fbredberg at openjdk.org  Mon Aug  4 12:52:40 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Mon, 4 Aug 2025 12:52:40 GMT
Subject: RFR: 8364141: Remove LockingMode related code from x86 [v2]
In-Reply-To: <m8gAjZPc85FAkX6HrgJvTY62GD-iWz7s9WULXmwrWoQ=.d48f80a3-7d38-4707-8dc4-b1ab80b6c1e3@github.com>
References: <g7WNqmFlJOkai-zeEjD09M5TwpL3fAMkZUAy37b747U=.faa6d9f5-1894-4507-a0f1-1dd41f3bdd43@github.com>
 <m8gAjZPc85FAkX6HrgJvTY62GD-iWz7s9WULXmwrWoQ=.d48f80a3-7d38-4707-8dc4-b1ab80b6c1e3@github.com>
Message-ID: <YYBxBeYzyeI6p0_2NDgZz5AtBMnd9zwRy9SnlORN6Z8=.ae8a60ab-f36b-4737-ad22-48e5de95158b@github.com>

On Fri, 1 Aug 2025 06:12:28 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update one after review
>
> Nice cleanup! Some small initial comments.
> 
> All the "displaced header" comments looks out of place. Displacing the header word on the stack (in the box) was purely a LM_LEGACY thing. Now we only displace it in the ObjectMonitor which is only handled (inflation / deflation) in the C++ runtime.
> 
> There are some more `BasicLock::displaced_header_offset_in_bytes()` asserts inside the x86 code. For callers of these methods, could be removed now or when the `BasicLock` is cleaned up.
> 
> There are some unused variables because of "displaced header" code that is kept.
> 
> `fast_lock_lightweight` and `fast_unlock_lockweight` should probably be renamed `fast_lock` and `fast_unlock` to be in sync with all the comments. (Or all the comments should be updated) (Same with C2 AD instruction)

@xmas92 
> All the "displaced header" comments looks out of place. Displacing the header word on the stack (in the box) was purely a LM_LEGACY thing. Now we only displace it in the ObjectMonitor which is only handled (inflation / deflation) in the C++ runtime.
> 
> There are some more `BasicLock::displaced_header_offset_in_bytes()` asserts inside the x86 code. For callers of these methods, could be removed now or when the `BasicLock` is cleaned up.

I basically agree. It's a bit of a mess right now and arguments that are called `disp_hdr` should probably be changed to `basic_lock`. But I'd rather do that in a separate PR and have this (and all the similar other platform PRs) only handle removing of dead code due to removal of the `LockingMode` flag. It's far easier to review a PR that has just removed code, than to a one that has also refactored lots of code.

> There are some unused variables because of "displaced header" code that is kept.

Fixed those you saw, and some more that I found.

> `fast_lock_lightweight` and `fast_unlock_lockweight` should probably be renamed `fast_lock` and `fast_unlock` to be in sync with all the comments. (Or all the comments should be updated) (Same with C2 AD instruction)

Totally agree. But that also for a separate PR after the shared (non-platform specific) files has been fixed.

> src/hotspot/cpu/x86/interp_masm_x86.cpp line 1032:
> 
>> 1030:   const Register tmp_reg = rbx;
>> 1031:   const Register obj_reg = c_rarg3; // Will contain the oop
>> 1032:   const Register rklass_decode_tmp = rscratch1;
> 
> Unused variable.

Fixed

> src/hotspot/cpu/x86/interp_masm_x86.cpp line 1037:
> 
>> 1035:   const int lock_offset = in_bytes(BasicObjectLock::lock_offset());
>> 1036:   const int mark_offset = lock_offset +
>> 1037:                           BasicLock::displaced_header_offset_in_bytes();
> 
> Unused variable.

Fixed

> src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp line 2194:
> 
>> 2192: 
>> 2193:     // Load the oop from the handle
>> 2194:     __ movptr(obj_reg, Address(oop_handle_reg, 0));
> 
> `mark_word_offset` and `count_mon` unused variable above.

Fixed

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

PR Comment: https://git.openjdk.org/jdk/pull/26552#issuecomment-3150525525
PR Review Comment: https://git.openjdk.org/jdk/pull/26552#discussion_r2251387407
PR Review Comment: https://git.openjdk.org/jdk/pull/26552#discussion_r2251387954
PR Review Comment: https://git.openjdk.org/jdk/pull/26552#discussion_r2251388647

From ayang at openjdk.org  Mon Aug  4 13:19:14 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 4 Aug 2025 13:19:14 GMT
Subject: RFR: 8263476: NMT: Stack guard pages should not be marked as
 committed [v2]
In-Reply-To: <BojYWaP10BJMEWDQYSRiMKR0cOWzMF5At9_3fwD6uUw=.becf6902-01f1-41e0-965d-18a945a6dfcf@github.com>
References: <BojYWaP10BJMEWDQYSRiMKR0cOWzMF5At9_3fwD6uUw=.becf6902-01f1-41e0-965d-18a945a6dfcf@github.com>
Message-ID: <wX8LHhAfHX8PKLH4XujwLo1j7090r8DOPfCgfphQ2-E=.608da498-cff0-4ec1-9dfe-3ae224a43e38@github.com>

> Use reserved (instead of committed) memory for stack-guard-pages on linux like systems.
> 
> `os::must_commit_stack_guard_pages` uses `commit` in its name, but `commit` usually has specific meanings in OS memory context. The actual question the caller is asking is whether the caller needs to do some preparation work before marking the guard-pages as inaccessible. To avoid confusion, I changed it to "allocate". Other suggestions are welcome.
> 
> Test: tier1-3

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 no-commit-stack-guard-page
 - no-commit-stack-guard-page

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26571/files
  - new: https://git.openjdk.org/jdk/pull/26571/files/82d02eb4..0061fcb9

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

  Stats: 8072 lines in 198 files changed: 5800 ins; 1740 del; 532 mod
  Patch: https://git.openjdk.org/jdk/pull/26571.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26571/head:pull/26571

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

From ayang at openjdk.org  Mon Aug  4 13:24:55 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 4 Aug 2025 13:24:55 GMT
Subject: RFR: 8263476: NMT: Stack guard pages should not be marked as
 committed [v2]
In-Reply-To: <Kwrb1dkkecP2tFGM7IZxYiKN_9ke4u5xtje3G05V5H0=.9d830cad-a360-4fc0-a4a5-2fe6e01f0b91@github.com>
References: <BojYWaP10BJMEWDQYSRiMKR0cOWzMF5At9_3fwD6uUw=.becf6902-01f1-41e0-965d-18a945a6dfcf@github.com>
 <Kwrb1dkkecP2tFGM7IZxYiKN_9ke4u5xtje3G05V5H0=.9d830cad-a360-4fc0-a4a5-2fe6e01f0b91@github.com>
Message-ID: <CxqLDWolGPMO_jg80yr-u08_cRBfPtIKRI5ewf8k7WU=.95281f2b-6716-4ee9-8df9-2cdd7e623d46@github.com>

On Mon, 4 Aug 2025 12:34:19 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The 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 no-commit-stack-guard-page
>>  - no-commit-stack-guard-page
>
> src/hotspot/os/linux/os_linux.cpp line 3455:
> 
>> 3453: 
>> 3454:     if (stack_extent < (uintptr_t)addr + size) {
>> 3455:       ::munmap((void*)stack_extent, (uintptr_t)(addr + size - stack_extent));
> 
> Could you explain this, is it fixing a pre-existing bug as well?

There is no pre-existing bug. The previous code ensures the memory range for stack-guard-pages are committed, note `os::commit_memory` is invoked in all paths. OTOH, the "reserve memory" call is only for main-thread in the new code. Also added a diagram, if that helps.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26571#discussion_r2251476887

From jsjolen at openjdk.org  Mon Aug  4 13:55:59 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 4 Aug 2025 13:55:59 GMT
Subject: RFR: 8263476: NMT: Stack guard pages should not be marked as
 committed [v2]
In-Reply-To: <wX8LHhAfHX8PKLH4XujwLo1j7090r8DOPfCgfphQ2-E=.608da498-cff0-4ec1-9dfe-3ae224a43e38@github.com>
References: <BojYWaP10BJMEWDQYSRiMKR0cOWzMF5At9_3fwD6uUw=.becf6902-01f1-41e0-965d-18a945a6dfcf@github.com>
 <wX8LHhAfHX8PKLH4XujwLo1j7090r8DOPfCgfphQ2-E=.608da498-cff0-4ec1-9dfe-3ae224a43e38@github.com>
Message-ID: <kCfkFUEayVN9i8Kj-8CYM-muyRmhSk3NhaQlZ084c7w=.702feb04-eb64-439d-b0ae-8ad7b2a93375@github.com>

On Mon, 4 Aug 2025 13:19:14 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Use reserved (instead of committed) memory for stack-guard-pages on linux like systems.
>> 
>> `os::must_commit_stack_guard_pages` uses `commit` in its name, but `commit` usually has specific meanings in OS memory context. The actual question the caller is asking is whether the caller needs to do some preparation work before marking the guard-pages as inaccessible. To avoid confusion, I changed it to "allocate". Other suggestions are welcome.
>> 
>> Test: tier1-3
>
> 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 no-commit-stack-guard-page
>  - no-commit-stack-guard-page

I think that the gist of the patch is fine, and I think it's an improvement. Looks essentially like what I wanted to do, but a bit better?

I have a couple of questions, though, as I don't understand why certain things were done (see comments)

src/hotspot/os/bsd/os_bsd.cpp line 1686:

> 1684: // munmap()ping them.  If not, just call uncommit_memory().
> 1685: bool os::remove_stack_guard_pages(char* addr, size_t size) {
> 1686:   ShouldNotReachHere();

The comment no longer makes any sense.

src/hotspot/os/bsd/os_bsd.inline.hpp line 44:

> 42:   assert(uses_stack_guard_pages(), "sanity check");
> 43:   return false;
> 44: }

I'm missing why it's OK to remove this.

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

PR Review: https://git.openjdk.org/jdk/pull/26571#pullrequestreview-3084305117
PR Review Comment: https://git.openjdk.org/jdk/pull/26571#discussion_r2251559222
PR Review Comment: https://git.openjdk.org/jdk/pull/26571#discussion_r2251569227

From jsjolen at openjdk.org  Mon Aug  4 13:56:00 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 4 Aug 2025 13:56:00 GMT
Subject: RFR: 8263476: NMT: Stack guard pages should not be marked as
 committed [v2]
In-Reply-To: <CxqLDWolGPMO_jg80yr-u08_cRBfPtIKRI5ewf8k7WU=.95281f2b-6716-4ee9-8df9-2cdd7e623d46@github.com>
References: <BojYWaP10BJMEWDQYSRiMKR0cOWzMF5At9_3fwD6uUw=.becf6902-01f1-41e0-965d-18a945a6dfcf@github.com>
 <Kwrb1dkkecP2tFGM7IZxYiKN_9ke4u5xtje3G05V5H0=.9d830cad-a360-4fc0-a4a5-2fe6e01f0b91@github.com>
 <CxqLDWolGPMO_jg80yr-u08_cRBfPtIKRI5ewf8k7WU=.95281f2b-6716-4ee9-8df9-2cdd7e623d46@github.com>
Message-ID: <rjIgNraKjfcDUQKw8zvy3jfLXy1tDk7seOMAYRO9y4g=.081ddad1-f540-4f07-827c-3017dd995f25@github.com>

On Mon, 4 Aug 2025 13:22:25 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> src/hotspot/os/linux/os_linux.cpp line 3455:
>> 
>>> 3453: 
>>> 3454:     if (stack_extent < (uintptr_t)addr + size) {
>>> 3455:       ::munmap((void*)stack_extent, (uintptr_t)(addr + size - stack_extent));
>> 
>> Could you explain this, is it fixing a pre-existing bug as well?
>
> There is no pre-existing bug. The previous code ensures the memory range for stack-guard-pages are committed, note `os::commit_memory` is invoked in all paths. OTOH, the "reserve memory" call is only for main-thread in the new code. Also added a diagram, if that helps.

Aha, now I understand. The diagram helped a lot!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26571#discussion_r2251557854

From ayang at openjdk.org  Mon Aug  4 14:04:15 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 4 Aug 2025 14:04:15 GMT
Subject: RFR: 8263476: NMT: Stack guard pages should not be marked as
 committed [v3]
In-Reply-To: <BojYWaP10BJMEWDQYSRiMKR0cOWzMF5At9_3fwD6uUw=.becf6902-01f1-41e0-965d-18a945a6dfcf@github.com>
References: <BojYWaP10BJMEWDQYSRiMKR0cOWzMF5At9_3fwD6uUw=.becf6902-01f1-41e0-965d-18a945a6dfcf@github.com>
Message-ID: <Hv5Bte_jswZl8u2WPO9HrwMaHnWGZVaPlNfDdROONCg=.4affdc2a-81da-4bd0-8a3d-3b2aa9d09283@github.com>

> Use reserved (instead of committed) memory for stack-guard-pages on linux like systems.
> 
> `os::must_commit_stack_guard_pages` uses `commit` in its name, but `commit` usually has specific meanings in OS memory context. The actual question the caller is asking is whether the caller needs to do some preparation work before marking the guard-pages as inaccessible. To avoid confusion, I changed it to "allocate". Other suggestions are welcome.
> 
> Test: tier1-3

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/26571/files
  - new: https://git.openjdk.org/jdk/pull/26571/files/0061fcb9..a248cff8

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

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

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

From alanb at openjdk.org  Mon Aug  4 14:05:56 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 4 Aug 2025 14:05:56 GMT
Subject: RFR: 8364314: java_lang_Thread::get_thread_status fails
 assert(base != nullptr) failed: Invalid base [v2]
In-Reply-To: <v7oMpIrrQG5rEy7XY-99u22GpM9VXu3-QgXItFefchw=.6f8e5048-55cf-4346-b6d2-94b147dbb31a@github.com>
References: <ceYO3eEp5YWA4T5oDbw3Tqv0f-GUh2xTBqxjuWdsJl8=.f594db6c-8064-4a7a-a467-75ba86e950bd@github.com>
 <zEmmXnncIeBkHA6lfZBkOK3F19mjG1ExCad990UzhHM=.2c35f1aa-03c2-4588-8f4e-ce655c56256c@github.com>
 <fshvnh428tQEdJRj5BMpEKrocg45Tls4jq4AbJ_idqE=.9a7915af-aeb8-44bf-801f-d97df4642115@github.com>
 <7UYBa8RmnDBaABnvni-SCxIJoloraOHZtSk7XWz81n0=.ffb3629e-7e19-41af-80a3-b9c70241f5da@github.com>
 <v7oMpIrrQG5rEy7XY-99u22GpM9VXu3-QgXItFefchw=.6f8e5048-55cf-4346-b6d2-94b147dbb31a@github.com>
Message-ID: <ZQ2fsX-e4nZ6c5S3bKfkiQT3Oz4j9-G-I8ifdTgrjWw=.93d658d1-1a16-45d8-9a3e-3df38e2928f9@github.com>

On Thu, 31 Jul 2025 12:07:42 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> If the JvmtiVTMSTransitionDisabler only works when there's an agent attached, I don't think we're protecting the carrier thread at all since it can become unmounted at anytime when there's no agent.
>> 
>> Right. The issue was discovered several weeks ago: https://bugs.openjdk.org/browse/JDK-8361913 Work in progress
>
>> If the JvmtiVTMSTransitionDisabler only works when there's an agent attached,
> I don't think we're protecting the carrier thread at all since it can become unmounted
> at anytime when there's no agent.
> 
> I've pushed some initial changes to the loom repo to deal with the transitions. This drops the use of JvmtiVTMSTransitionDisabler as this requires a JVMTI environment. We have a new stress too that bashes on dumpThreads while many virtual threads are parking and unparking. Need to go over this with @alexmenkov and @sspitsyn before proposing anything for main line.

> As noted above this particular code is problematic for a range of reasons, but for now this fix maintains the pretense that the transition disabler actually works, and @AlanBateman will be fixing that as noted above.

Yes, get_thread_snapshot has a bug tail. Longer term we need to put in infrastructure to interact with a specific virtual thread or all virtual threads. We need this for a second phase of thread dump anyway.  Short term we can use the same approach as Thread::getStackTrace by suspending the virtual thread when unmounted, have the handshake op check that the virtual thread and continuation is mounted, and retry if attempting a snapshot during a transition. I've put a possible change in this [draft PR](https://github.com/openjdk/jdk/pull/26612) - I need to discuss with Serguei and Alex on how they want to handle this.

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

PR Comment: https://git.openjdk.org/jdk/pull/26544#issuecomment-3150854651

From ayang at openjdk.org  Mon Aug  4 14:31:55 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 4 Aug 2025 14:31:55 GMT
Subject: RFR: 8263476: NMT: Stack guard pages should not be marked as
 committed [v2]
In-Reply-To: <kCfkFUEayVN9i8Kj-8CYM-muyRmhSk3NhaQlZ084c7w=.702feb04-eb64-439d-b0ae-8ad7b2a93375@github.com>
References: <BojYWaP10BJMEWDQYSRiMKR0cOWzMF5At9_3fwD6uUw=.becf6902-01f1-41e0-965d-18a945a6dfcf@github.com>
 <wX8LHhAfHX8PKLH4XujwLo1j7090r8DOPfCgfphQ2-E=.608da498-cff0-4ec1-9dfe-3ae224a43e38@github.com>
 <kCfkFUEayVN9i8Kj-8CYM-muyRmhSk3NhaQlZ084c7w=.702feb04-eb64-439d-b0ae-8ad7b2a93375@github.com>
Message-ID: <UD9VSnHOoTELaWXo7KyYT7LMIZBNiBj3wTVFiug8D2U=.0bc35853-312a-43ca-a0f3-a8c6ae2e4feb@github.com>

On Mon, 4 Aug 2025 13:52:41 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The 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 no-commit-stack-guard-page
>>  - no-commit-stack-guard-page
>
> src/hotspot/os/bsd/os_bsd.inline.hpp line 44:
> 
>> 42:   assert(uses_stack_guard_pages(), "sanity check");
>> 43:   return false;
>> 44: }
> 
> I'm missing why it's OK to remove this.

Previously, we require stack-guard-pages to be committed, and mmap MAP_STACK does "lazy" commit, so we have to perform commit explicitly. Now, we switch to reserve-only stack-guard-pages, so no explicit commit is needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26571#discussion_r2251679047

From mgronlun at openjdk.org  Mon Aug  4 14:55:03 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 4 Aug 2025 14:55:03 GMT
Subject: [jdk25] Integrated: 8364258: ThreadGroup constant pool serialization
 is not normalized
In-Reply-To: <DvqtMLpkKmkZfiok2e6ygYAFV33h2bw26MizV2vCsH4=.1dde3ebd-1e66-4307-9d9d-8d5412a50151@github.com>
References: <DvqtMLpkKmkZfiok2e6ygYAFV33h2bw26MizV2vCsH4=.1dde3ebd-1e66-4307-9d9d-8d5412a50151@github.com>
Message-ID: <rWM5w7qhnyVq874s2A9IoW-4_p-BkS1Brqt7SW_I9Rw=.da6666fc-76cf-4362-b743-690f9649e2a4@github.com>

On Mon, 4 Aug 2025 09:52:42 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> 8364258: ThreadGroup constant pool serialization is not normalized

This pull request has now been integrated.

Changeset: 1e2bf070
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1e2bf070f0cb9e852839347d1f5711c583091d85
Stats:     938 lines in 12 files changed: 431 ins; 482 del; 25 mod

8364258: ThreadGroup constant pool serialization is not normalized

Reviewed-by: egahlin
Backport-of: 3bc449797eb59f9770d2a06d260b23b6efd5ff0f

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

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

From duke at openjdk.org  Mon Aug  4 17:45:12 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 4 Aug 2025 17:45:12 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code generic
Message-ID: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>

Hi all,

This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110).

As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports:

CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup()

CPUTimeUsage::GC::gc_threads()
CPUTimeUsage::GC::vm_thread()
CPUTimeUsage::GC::stringdedup()

CPUTimeUsage::Runtime::vm_thread()


I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC.

I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table:


[12.517s][info][cpu] === CPU time Statistics =============================================================
[12.517s][info][cpu]                                                                             CPUs
[12.517s][info][cpu]                                                                s       %  utilized
[12.517s][info][cpu]    Process
[12.517s][info][cpu]      Total                                              175.7628  100.00      14.0
[12.517s][info][cpu]      VM Thread                                            7.0000    3.98       0.6
[12.517s][info][cpu]      Garbage Collection                                  72.0000   40.96       5.8
[12.517s][info][cpu]        GC Threads                                        70.0000   39.83       5.6
[12.517s][info][cpu]        VM Thread                                          1.0000    0.57       0.1
[12.518s][info][cpu]        String Deduplication                               0.0000    0.00       0.0
[12.518s][info][cpu] =====================================================================================


Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path.

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

Commit messages:
 - Make GC CPU time framework generic

Changes: https://git.openjdk.org/jdk/pull/26621/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26621&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364638
  Stats: 229 lines in 11 files changed: 170 ins; 44 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/26621.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26621/head:pull/26621

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

From duke at openjdk.org  Mon Aug  4 18:47:44 2025
From: duke at openjdk.org (mazhen)
Date: Mon, 4 Aug 2025 18:47:44 GMT
Subject: RFR: 8303612: runtime/StackGuardPages/TestStackGuardPagesNative.java
 fails with exit code 139
Message-ID: <oRl4abf8ZV5qD9GNScJMRwwZD2PkdiDGJykDFs1Cmgo=.8c961e33-291f-4ba1-b494-ad5eab7ee72c@github.com>

This pull request addresses an issue in `runtime/StackGuardPages/TestStackGuardPagesNative` where the native test component (`exeinvoke.c`) exhibited platform-dependent behavior and did not fully align with the intended test objectives for verifying stack guard page removal on thread detachment.

**Summary of the Problem:**

The `test_native_overflow_initial` scenario within `TestStackGuardPagesNative` showed inconsistent results:
*   On certain Linux distributions (e.g., CentOS 7), the test would hang and eventually time out during its second phase of stack allocation.
*   On other distributions (e.g., Ubuntu 24), the test would pass, but this pass was found to be coincidental, relying on an unintended `SEGV_MAPERR` to terminate a loop that should have had a defined exit condition.

The core issue was that the native code's second stack overflow attempt, designed to check for guard page removal, used an unbounded loop. Its termination (and thus the test's outcome) depended on platform-specific OS behavior regarding extensive stack allocation after guard pages are supposedly modified.

**Test Objective Analysis:**

The primary goal of `TestStackGuardPagesNative`, particularly for the initial thread (`test_native_overflow_initial`), is to:
1.  **Verify Guard Page Presence:** Confirm that when a native thread is attached to the JVM, a deliberate stack overflow triggers a `SIGSEGV` with `si_code = SEGV_ACCERR`, indicating an active stack guard page.
2.  **Verify Guard Page Removal/Modification:** After the thread detaches from the JVM via `DetachCurrentThread()`, confirm that the previously active stack guard page is no longer enforcing the same strict protection. This is ideally demonstrated by successfully allocating stack space up to the depth that previously caused the `SEGV_ACCERR`, **without encountering any signal**.

**How the Original Implementation Deviated from the Test Intent:**

The native `do_overflow` function, when invoked for the second phase (to check guard page removal), implemented an unconditional `for(;;)` loop.
*   **Intended Logic vs. Actual Behavior:** The test intended for this second phase to demonstrate that allocations up to the prior failure depth are now "clean" (no `SEGV_ACCERR`). However, the unbounded loop meant:
    *   On systems like CentOS 7, where deep stack allocation without an immediate `SEGV_MAPERR` was possible, this loop ran for an excessive duration, leading to a hang.
    *   On systems like Ubuntu 24, the loop *was* terminated by a `SEGV_MAPERR`. The existing result-checking logic in `run_native_overflow` incorrectly treated this `SEGV_MAPERR` as a "pass" condition for guard page removal, which is misleading. The true indication of successful guard page removal is the *absence* of any signal during the controlled second allocation phase.

This reliance on incidental, platform-dependent signal behavior to terminate the loop (and the misinterpretation of `SEGV_MAPERR` as a success) meant the test was not robustly verifying its core objective.

**Proposed Solution:**

This PR modifies the `do_overflow` function in `exeinvoke.c` to accurately reflect the test intent for both phases of stack overflow checking, ensuring deterministic behavior:

The `do_overflow` function is updated to use a single `while` loop whose condition correctly handles both the initial overflow check and the subsequent verification of guard page removal:


void do_overflow(){
  volatile int *p = NULL;
  // The loop condition is true if:
  // 1. It's the first run (_kp_rec_count == 0), causing the loop to run until SIGSEGV.
  // 2. It's the second run (_kp_rec_count > 0) AND the current allocation depth (_rec_count)
  //    is less than the depth that previously caused SIGSEGV (_kp_rec_count).
  while (_kp_rec_count == 0 || _rec_count < _kp_rec_count) {
    _rec_count++;
    p = (int*)alloca(128);
    _peek_value = p[0]; // Ensure memory is touched to trigger guard page if active
  }
  // - On the first run, this point is never reached due to longjmp from the signal handler.
  // - On the second run, if no SIGSEGV occurs, the loop completes when _rec_count == _kp_rec_count.
}


**Impact and Clarity of Test Outcome with This Change:**

*   **Prevents Hangs:** The primary impact of this change is the elimination of the potential for an infinite (or excessively long) loop during the second phase of `do_overflow`. The loop now has a defined boundary based on `_kp_rec_count`. This directly resolves the hang observed on platforms like CentOS 7.
*   **Deterministic Execution of `do_overflow`:** The `do_overflow` function will now consistently:
    *   In the first run: Execute until a `SIGSEGV` occurs and `longjmp` is called.
    *   In the second run: Execute allocations up to `_kp_rec_count` times. If no `SIGSEGV` occurs, it will complete this bounded loop and return normally. If a `SIGSEGV` *does* occur within these `_kp_rec_count` allocations, `longjmp` will be called.

This refinement ensures `TestStackGuardPagesNative` more accurately and reliably verifies the stack guard page lifecycle for native threads attached to the JVM.

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

Commit messages:
 - update copyright year in StackGuardPages test
 - 8303612: runtime/StackGuardPages/TestStackGuardPagesNative.java fails with exit code 139

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

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

From syan at openjdk.org  Mon Aug  4 18:47:45 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 4 Aug 2025 18:47:45 GMT
Subject: RFR: 8303612:
 runtime/StackGuardPages/TestStackGuardPagesNative.java fails with exit code
 139
In-Reply-To: <oRl4abf8ZV5qD9GNScJMRwwZD2PkdiDGJykDFs1Cmgo=.8c961e33-291f-4ba1-b494-ad5eab7ee72c@github.com>
References: <oRl4abf8ZV5qD9GNScJMRwwZD2PkdiDGJykDFs1Cmgo=.8c961e33-291f-4ba1-b494-ad5eab7ee72c@github.com>
Message-ID: <nyD0zSfiOH6ZbRaBEKmFJeFXJ5RLcDev0Li6s5wwA4I=.18907cff-75c8-43bb-aeb3-e9b965caee1d@github.com>

On Mon, 9 Jun 2025 06:53:20 GMT, mazhen <duke at openjdk.org> wrote:

> This pull request addresses an issue in `runtime/StackGuardPages/TestStackGuardPagesNative` where the native test component (`exeinvoke.c`) exhibited platform-dependent behavior and did not fully align with the intended test objectives for verifying stack guard page removal on thread detachment.
> 
> **Summary of the Problem:**
> 
> The `test_native_overflow_initial` scenario within `TestStackGuardPagesNative` showed inconsistent results:
> *   On certain Linux distributions (e.g., CentOS 7), the test would hang and eventually time out during its second phase of stack allocation.
> *   On other distributions (e.g., Ubuntu 24), the test would pass, but this pass was found to be coincidental, relying on an unintended `SEGV_MAPERR` to terminate a loop that should have had a defined exit condition.
> 
> The core issue was that the native code's second stack overflow attempt, designed to check for guard page removal, used an unbounded loop. Its termination (and thus the test's outcome) depended on platform-specific OS behavior regarding extensive stack allocation after guard pages are supposedly modified.
> 
> **Test Objective Analysis:**
> 
> The primary goal of `TestStackGuardPagesNative`, particularly for the initial thread (`test_native_overflow_initial`), is to:
> 1.  **Verify Guard Page Presence:** Confirm that when a native thread is attached to the JVM, a deliberate stack overflow triggers a `SIGSEGV` with `si_code = SEGV_ACCERR`, indicating an active stack guard page.
> 2.  **Verify Guard Page Removal/Modification:** After the thread detaches from the JVM via `DetachCurrentThread()`, confirm that the previously active stack guard page is no longer enforcing the same strict protection. This is ideally demonstrated by successfully allocating stack space up to the depth that previously caused the `SEGV_ACCERR`, **without encountering any signal**.
> 
> **How the Original Implementation Deviated from the Test Intent:**
> 
> The native `do_overflow` function, when invoked for the second phase (to check guard page removal), implemented an unconditional `for(;;)` loop.
> *   **Intended Logic vs. Actual Behavior:** The test intended for this second phase to demonstrate that allocations up to the prior failure depth are now "clean" (no `SEGV_ACCERR`). However, the unbounded loop meant:
>     *   On systems like CentOS 7, where deep stack allocation without an immediate `SEGV_MAPERR` was possible, this loop ran for an excessive duration, leading to a hang.
>     *   On systems like Ubuntu 24, the loop *...

The copyright year should be updated from 2023 to 2025.

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

PR Comment: https://git.openjdk.org/jdk/pull/25689#issuecomment-2957400490

From duke at openjdk.org  Mon Aug  4 18:47:45 2025
From: duke at openjdk.org (mazhen)
Date: Mon, 4 Aug 2025 18:47:45 GMT
Subject: RFR: 8303612:
 runtime/StackGuardPages/TestStackGuardPagesNative.java fails with exit code
 139
In-Reply-To: <nyD0zSfiOH6ZbRaBEKmFJeFXJ5RLcDev0Li6s5wwA4I=.18907cff-75c8-43bb-aeb3-e9b965caee1d@github.com>
References: <oRl4abf8ZV5qD9GNScJMRwwZD2PkdiDGJykDFs1Cmgo=.8c961e33-291f-4ba1-b494-ad5eab7ee72c@github.com>
 <nyD0zSfiOH6ZbRaBEKmFJeFXJ5RLcDev0Li6s5wwA4I=.18907cff-75c8-43bb-aeb3-e9b965caee1d@github.com>
Message-ID: <vhpQUsBxiQ3EfQ5mb1K2teKV4BKHhott5bAXv38Luk8=.b7612e9f-d997-4221-b8e0-f49814de7698@github.com>

On Tue, 10 Jun 2025 00:57:43 GMT, SendaoYan <syan at openjdk.org> wrote:

> The copyright year should be updated from 2023 to 2025.

Done. Updated the copyright year to 2025 as requested. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/25689#issuecomment-2957800693

From duke at openjdk.org  Mon Aug  4 18:47:45 2025
From: duke at openjdk.org (mazhen)
Date: Mon, 4 Aug 2025 18:47:45 GMT
Subject: RFR: 8303612:
 runtime/StackGuardPages/TestStackGuardPagesNative.java fails with exit code
 139
In-Reply-To: <oRl4abf8ZV5qD9GNScJMRwwZD2PkdiDGJykDFs1Cmgo=.8c961e33-291f-4ba1-b494-ad5eab7ee72c@github.com>
References: <oRl4abf8ZV5qD9GNScJMRwwZD2PkdiDGJykDFs1Cmgo=.8c961e33-291f-4ba1-b494-ad5eab7ee72c@github.com>
Message-ID: <blniq87ptY1r2ZSL2nR17MV-SHTmPOPcAPWRgCVqL24=.b011371a-c54e-4fd9-b25b-19e22c321d3f@github.com>

On Mon, 9 Jun 2025 06:53:20 GMT, mazhen <duke at openjdk.org> wrote:

> This pull request addresses an issue in `runtime/StackGuardPages/TestStackGuardPagesNative` where the native test component (`exeinvoke.c`) exhibited platform-dependent behavior and did not fully align with the intended test objectives for verifying stack guard page removal on thread detachment.
> 
> **Summary of the Problem:**
> 
> The `test_native_overflow_initial` scenario within `TestStackGuardPagesNative` showed inconsistent results:
> *   On certain Linux distributions (e.g., CentOS 7), the test would hang and eventually time out during its second phase of stack allocation.
> *   On other distributions (e.g., Ubuntu 24), the test would pass, but this pass was found to be coincidental, relying on an unintended `SEGV_MAPERR` to terminate a loop that should have had a defined exit condition.
> 
> The core issue was that the native code's second stack overflow attempt, designed to check for guard page removal, used an unbounded loop. Its termination (and thus the test's outcome) depended on platform-specific OS behavior regarding extensive stack allocation after guard pages are supposedly modified.
> 
> **Test Objective Analysis:**
> 
> The primary goal of `TestStackGuardPagesNative`, particularly for the initial thread (`test_native_overflow_initial`), is to:
> 1.  **Verify Guard Page Presence:** Confirm that when a native thread is attached to the JVM, a deliberate stack overflow triggers a `SIGSEGV` with `si_code = SEGV_ACCERR`, indicating an active stack guard page.
> 2.  **Verify Guard Page Removal/Modification:** After the thread detaches from the JVM via `DetachCurrentThread()`, confirm that the previously active stack guard page is no longer enforcing the same strict protection. This is ideally demonstrated by successfully allocating stack space up to the depth that previously caused the `SEGV_ACCERR`, **without encountering any signal**.
> 
> **How the Original Implementation Deviated from the Test Intent:**
> 
> The native `do_overflow` function, when invoked for the second phase (to check guard page removal), implemented an unconditional `for(;;)` loop.
> *   **Intended Logic vs. Actual Behavior:** The test intended for this second phase to demonstrate that allocations up to the prior failure depth are now "clean" (no `SEGV_ACCERR`). However, the unbounded loop meant:
>     *   On systems like CentOS 7, where deep stack allocation without an immediate `SEGV_MAPERR` was possible, this loop ran for an excessive duration, leading to a hang.
>     *   On systems like Ubuntu 24, the loop *...

Hi @jdksjolen ,

Following up on this. As per the bot's message two weeks ago, I've been waiting for my OCA to be processed, but it seems to be stuck.
I understand that PRs are not reviewed until the OCA is cleared, but since the suggested two-week waiting period has passed, I was hoping someone could help to check or escalate the status of my OCA application internally.

My Oracle Account Email: mz1999 at gmail.com

Any help would be greatly appreciated. Thank you!

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

PR Comment: https://git.openjdk.org/jdk/pull/25689#issuecomment-3050767270

From duke at openjdk.org  Mon Aug  4 19:34:01 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 4 Aug 2025 19:34:01 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v2]
In-Reply-To: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
Message-ID: <K-D2NwaTkdXGHHoThDUdcMjOvFRnUmQrq9RsmoS4lTk=.adbd7ca1-2c9d-4c65-b864-d9a18d615fe9@github.com>

> Hi all,
> 
> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110).
> 
> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports:
> 
> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup()
> 
> CPUTimeUsage::GC::gc_threads()
> CPUTimeUsage::GC::vm_thread()
> CPUTimeUsage::GC::stringdedup()
> 
> CPUTimeUsage::Runtime::vm_thread()
> 
> 
> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC.
> 
> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table:
> 
> 
> [12.517s][info][cpu] === CPU time Statistics =============================================================
> [12.517s][info][cpu]                                                                             CPUs
> [12.517s][info][cpu]                                                                s       %  utilized
> [12.517s][info][cpu]    Process
> [12.517s][info][cpu]      Total                                              175.7628  100.00      14.0
> [12.517s][info][cpu]      VM Thread                                            7.0000    3.98       0.6
> [12.517s][info][cpu]      Garbage Collection                                  72.0000   40.96       5.8
> [12.517s][info][cpu]        GC Threads                                        70.0000   39.83       5.6
> [12.517s][info][cpu]        VM Thread                                          1.0000    0.57       0.1
> [12.518s][info][cpu]        String Deduplication                               0.0000    0.00       0.0
> [12.518s][info][cpu] =====================================================================================
> 
> 
> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path.

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

  Remove assert which may not hold in tests that exists very fast
  
  It takes some time before the OS updates the underlying counters so process CPU time may be out of sync with regards to magnitude order compared to thread CPU time

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26621/files
  - new: https://git.openjdk.org/jdk/pull/26621/files/4f74c2bd..6a6e3996

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

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

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

From duke at openjdk.org  Mon Aug  4 19:53:24 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 4 Aug 2025 19:53:24 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v3]
In-Reply-To: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
Message-ID: <vT0yfqcx3CoiSOSKVrs0x9JNcud9uX6VchSyMk3sTG8=.052828eb-0e6b-4629-944a-69f2de4ff4fb@github.com>

> Hi all,
> 
> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110).
> 
> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports:
> 
> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup()
> 
> CPUTimeUsage::GC::gc_threads()
> CPUTimeUsage::GC::vm_thread()
> CPUTimeUsage::GC::stringdedup()
> 
> CPUTimeUsage::Runtime::vm_thread()
> 
> 
> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC.
> 
> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table:
> 
> 
> [12.517s][info][cpu] === CPU time Statistics =============================================================
> [12.517s][info][cpu]                                                                             CPUs
> [12.517s][info][cpu]                                                                s       %  utilized
> [12.517s][info][cpu]    Process
> [12.517s][info][cpu]      Total                                              175.7628  100.00      14.0
> [12.517s][info][cpu]      VM Thread                                            7.0000    3.98       0.6
> [12.517s][info][cpu]      Garbage Collection                                  72.0000   40.96       5.8
> [12.517s][info][cpu]        GC Threads                                        70.0000   39.83       5.6
> [12.517s][info][cpu]        VM Thread                                          1.0000    0.57       0.1
> [12.518s][info][cpu]        String Deduplication                               0.0000    0.00       0.0
> [12.518s][info][cpu] =====================================================================================
> 
> 
> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path.

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

  Prefer returning 0 over +/-inf,nan

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26621/files
  - new: https://git.openjdk.org/jdk/pull/26621/files/6a6e3996..216ba811

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

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

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

From dcubed at openjdk.org  Mon Aug  4 20:32:18 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 4 Aug 2025 20:32:18 GMT
Subject: RFR: 8364666: [BACKOUT] JDK-8360559 Optimize Math.sinh for x86 64 bit
 platforms
Message-ID: <7KiRaJZNUa7ZN8xp7Por5uhq6_G0HXfTpCUFCH8LHZ8=.9ab9cd02-40bb-43f5-9024-473868e326f7@github.com>

This reverts commit 05f8a6fca87d472a80e5952ddc90d8fa6589c75c.

This [BACKOUT] is being tested by an urgent Mach5 Tier1 job set.

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

Commit messages:
 - Revert "8360559: Optimize Math.sinh for x86 64 bit platforms"

Changes: https://git.openjdk.org/jdk/pull/26628/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26628&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364666
  Stats: 742 lines in 26 files changed: 0 ins; 739 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/26628.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26628/head:pull/26628

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

From ayang at openjdk.org  Mon Aug  4 20:34:04 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 4 Aug 2025 20:34:04 GMT
Subject: RFR: 8364666: [BACKOUT] JDK-8360559 Optimize Math.sinh for x86 64
 bit platforms
In-Reply-To: <7KiRaJZNUa7ZN8xp7Por5uhq6_G0HXfTpCUFCH8LHZ8=.9ab9cd02-40bb-43f5-9024-473868e326f7@github.com>
References: <7KiRaJZNUa7ZN8xp7Por5uhq6_G0HXfTpCUFCH8LHZ8=.9ab9cd02-40bb-43f5-9024-473868e326f7@github.com>
Message-ID: <tzcHGOZp-5DSw6vsg-nAweD4vuR4xtlizo4KadwNyzc=.d3c18ea7-45ff-4014-9fe5-4e101e9702cd@github.com>

On Mon, 4 Aug 2025 20:21:25 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> This reverts commit 05f8a6fca87d472a80e5952ddc90d8fa6589c75c.
> 
> This [BACKOUT] is being tested by an urgent Mach5 Tier1 job set.

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26628#pullrequestreview-3085667097

From dcubed at openjdk.org  Mon Aug  4 20:53:03 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 4 Aug 2025 20:53:03 GMT
Subject: RFR: 8364666: [BACKOUT] JDK-8360559 Optimize Math.sinh for x86 64
 bit platforms
In-Reply-To: <tzcHGOZp-5DSw6vsg-nAweD4vuR4xtlizo4KadwNyzc=.d3c18ea7-45ff-4014-9fe5-4e101e9702cd@github.com>
References: <7KiRaJZNUa7ZN8xp7Por5uhq6_G0HXfTpCUFCH8LHZ8=.9ab9cd02-40bb-43f5-9024-473868e326f7@github.com>
 <tzcHGOZp-5DSw6vsg-nAweD4vuR4xtlizo4KadwNyzc=.d3c18ea7-45ff-4014-9fe5-4e101e9702cd@github.com>
Message-ID: <VVIJ_KFQwOnEbffpkm1PdNyI0LH2E5J1PXTTc3E067k=.d69e07c3-565e-48d8-ab22-6e88fe4ff289@github.com>

On Mon, 4 Aug 2025 20:31:35 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This reverts commit 05f8a6fca87d472a80e5952ddc90d8fa6589c75c.
>> 
>> This [BACKOUT] is being tested by an urgent Mach5 Tier1 job set.
>
> Marked as reviewed by ayang (Reviewer).

@albertnetymk - Thanks for the review! We may not do the [BACKOUT] since we have
a proper fix being reviewed and tested over here:
https://github.com/openjdk/jdk/pull/26629

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

PR Comment: https://git.openjdk.org/jdk/pull/26628#issuecomment-3152374123

From dcubed at openjdk.org  Mon Aug  4 21:38:08 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 4 Aug 2025 21:38:08 GMT
Subject: RFR: 8364666: [BACKOUT] JDK-8360559 Optimize Math.sinh for x86 64
 bit platforms
In-Reply-To: <7KiRaJZNUa7ZN8xp7Por5uhq6_G0HXfTpCUFCH8LHZ8=.9ab9cd02-40bb-43f5-9024-473868e326f7@github.com>
References: <7KiRaJZNUa7ZN8xp7Por5uhq6_G0HXfTpCUFCH8LHZ8=.9ab9cd02-40bb-43f5-9024-473868e326f7@github.com>
Message-ID: <BuUPHLG09YQrKLxr-GeXuegKpr-g9ai8gDdsqbKzfTQ=.e54fc6aa-76f0-4cd3-b347-c80cf8bcbb0b@github.com>

On Mon, 4 Aug 2025 20:21:25 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> This reverts commit 05f8a6fca87d472a80e5952ddc90d8fa6589c75c.
> 
> This [BACKOUT] is being tested by an urgent Mach5 Tier1 job set.

Closing this [BACKOUT] PR in favor of the real fix in https://github.com/openjdk/jdk/pull/26629.

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

PR Comment: https://git.openjdk.org/jdk/pull/26628#issuecomment-3152471724

From dcubed at openjdk.org  Mon Aug  4 21:38:08 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 4 Aug 2025 21:38:08 GMT
Subject: Withdrawn: 8364666: [BACKOUT] JDK-8360559 Optimize Math.sinh for x86
 64 bit platforms
In-Reply-To: <7KiRaJZNUa7ZN8xp7Por5uhq6_G0HXfTpCUFCH8LHZ8=.9ab9cd02-40bb-43f5-9024-473868e326f7@github.com>
References: <7KiRaJZNUa7ZN8xp7Por5uhq6_G0HXfTpCUFCH8LHZ8=.9ab9cd02-40bb-43f5-9024-473868e326f7@github.com>
Message-ID: <d3lXymbb3R1wU3Mgj_7QxbqdbKrxADVdi_Er5y6JhAU=.9dc9b1f1-e3fe-4ea8-aea7-17d4bf1d2cca@github.com>

On Mon, 4 Aug 2025 20:21:25 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> This reverts commit 05f8a6fca87d472a80e5952ddc90d8fa6589c75c.
> 
> This [BACKOUT] is being tested by an urgent Mach5 Tier1 job set.

This pull request has been closed without being integrated.

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

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

From dholmes at openjdk.org  Mon Aug  4 21:51:15 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 4 Aug 2025 21:51:15 GMT
Subject: RFR: 8364314: java_lang_Thread::get_thread_status fails
 assert(base != nullptr) failed: Invalid base [v2]
In-Reply-To: <7UYBa8RmnDBaABnvni-SCxIJoloraOHZtSk7XWz81n0=.ffb3629e-7e19-41af-80a3-b9c70241f5da@github.com>
References: <ceYO3eEp5YWA4T5oDbw3Tqv0f-GUh2xTBqxjuWdsJl8=.f594db6c-8064-4a7a-a467-75ba86e950bd@github.com>
 <zEmmXnncIeBkHA6lfZBkOK3F19mjG1ExCad990UzhHM=.2c35f1aa-03c2-4588-8f4e-ce655c56256c@github.com>
 <fshvnh428tQEdJRj5BMpEKrocg45Tls4jq4AbJ_idqE=.9a7915af-aeb8-44bf-801f-d97df4642115@github.com>
 <7UYBa8RmnDBaABnvni-SCxIJoloraOHZtSk7XWz81n0=.ffb3629e-7e19-41af-80a3-b9c70241f5da@github.com>
Message-ID: <oqR3mPIzC0GcJH-f7Yv-ZcbxZIRf2urQT2gjsdMWcXs=.71ab73e6-36e1-4e28-9ebe-b361f74e2ab6@github.com>

On Wed, 30 Jul 2025 23:14:52 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> I just finished catching up on this other issue/PR:
>> 
>> [JDK-8361103](https://bugs.openjdk.org/browse/JDK-8361103) java_lang_Thread::async_get_stack_trace does not properly protect JavaThread
>> https://github.com/openjdk/jdk/pull/26119
>> 
>> And this comment from @sspitsyn stuck out to me w.r.t. to this fix:
>> 
>> https://github.com/openjdk/jdk/pull/26119#discussion_r2209135122
>> 
>> 
>> But, please, note that the JvmtiVTMSTransitionDisabler mechanism is enabled
>> only when there is a JVMTI agent. Otherwise, it has been disabled for scalability
>> purposes to exclude potentially high performance overhead at the VTMS
>> transition points.
>> 
>> 
>> The above comment from Serguei calls into question this suggested change that I posted on the PR:
>> 
>> https://github.com/openjdk/jdk/pull/26544/files#r2243188114
>> 
>> If the JvmtiVTMSTransitionDisabler only works when there's an agent attached,
>> I don't think we're protecting the carrier thread at all since it can become unmounted
>> at anytime when there's no agent.
>
>> If the JvmtiVTMSTransitionDisabler only works when there's an agent attached, I don't think we're protecting the carrier thread at all since it can become unmounted at anytime when there's no agent.
> 
> Right. The issue was discovered several weeks ago: https://bugs.openjdk.org/browse/JDK-8361913 Work in progress

Thanks for the re-review @alexmenkov !

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

PR Comment: https://git.openjdk.org/jdk/pull/26544#issuecomment-3152495124

From dholmes at openjdk.org  Mon Aug  4 21:51:15 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 4 Aug 2025 21:51:15 GMT
Subject: Integrated: 8364314: java_lang_Thread::get_thread_status fails
 assert(base != nullptr) failed: Invalid base
In-Reply-To: <ceYO3eEp5YWA4T5oDbw3Tqv0f-GUh2xTBqxjuWdsJl8=.f594db6c-8064-4a7a-a467-75ba86e950bd@github.com>
References: <ceYO3eEp5YWA4T5oDbw3Tqv0f-GUh2xTBqxjuWdsJl8=.f594db6c-8064-4a7a-a467-75ba86e950bd@github.com>
Message-ID: <fFXMlZuSGPCDBATtFD7NVaPLE2cM_WcvhM4ODezZpeU=.a8cc2e33-a7f2-400d-9469-3cd0c86fd290@github.com>

On Wed, 30 Jul 2025 05:14:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

> After the changes in  JDK-8361912 we could "return " the carrier thread from `cv_internal_thread_to_JavaThread`, but before we hit the transition disabler the virtual thread could unmount. As a result when we execute this code:
> 
>   if (is_virtual) {
>     // 1st need to disable mount/unmount transitions
>     transition_disabler.init(jthread);
> 
>     carrier_thread = Handle(THREAD, java_lang_VirtualThread::carrier_thread(thread_h()));
>     if (carrier_thread != nullptr) {
>       java_thread = java_lang_Thread::thread(carrier_thread());
>     }
>   }
> 
> we hit the implicit else where "`carrier_thread == nullptr`" and we do nothing, but `java_thread` still holds the old carrier, which we then perform the handshake operation with:
> 
>   void do_thread(Thread* th) override {
>     Thread* current = Thread::current();
> 
>     bool is_virtual = java_lang_VirtualThread::is_instance(_thread_h());
>     if (_java_thread != nullptr) {
>       if (is_virtual) {
>         // mounted vthread, use carrier thread state
>         oop carrier_thread = java_lang_VirtualThread::carrier_thread(_thread_h());
>         _thread_status = java_lang_Thread::get_thread_status(carrier_thread);
>       } else {
> 
> But the `_java_thread` no longer has a carrier, so `get_thread_status` is passed null and we crash.
> 
> Simple fix is to clear `java_thread` when we find a null carrier oop. Also added an assert to guard against a null carrier oop in the handshake code, and added some additional commentary.
> 
> Testing:
>  - com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java
>  -  tier 5 and 6
> 
> Thanks

This pull request has now been integrated.

Changeset: 84a4a364
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/84a4a3647c86baecc07abfa7d1d4b88e06984821
Stats:     14 lines in 2 files changed: 11 ins; 3 del; 0 mod

8364314: java_lang_Thread::get_thread_status fails assert(base != nullptr) failed: Invalid base

Reviewed-by: amenkov, shade, dcubed, pchilanomate, sspitsyn

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

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

From dcubed at openjdk.org  Mon Aug  4 23:31:09 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 4 Aug 2025 23:31:09 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v3]
In-Reply-To: <vT0yfqcx3CoiSOSKVrs0x9JNcud9uX6VchSyMk3sTG8=.052828eb-0e6b-4629-944a-69f2de4ff4fb@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <vT0yfqcx3CoiSOSKVrs0x9JNcud9uX6VchSyMk3sTG8=.052828eb-0e6b-4629-944a-69f2de4ff4fb@github.com>
Message-ID: <QpFMDMMRZ98B5iLM6o0kN9VUpEgURtymeOq0eq4-Fx4=.bed04d25-c5f4-42d8-96f5-cabc169c433b@github.com>

On Mon, 4 Aug 2025 19:53:24 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110).
>> 
>> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports:
>> 
>> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup()
>> 
>> CPUTimeUsage::GC::gc_threads()
>> CPUTimeUsage::GC::vm_thread()
>> CPUTimeUsage::GC::stringdedup()
>> 
>> CPUTimeUsage::Runtime::vm_thread()
>> 
>> 
>> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC.
>> 
>> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table:
>> 
>> 
>> [12.517s][info][cpu] === CPU time Statistics =============================================================
>> [12.517s][info][cpu]                                                                             CPUs
>> [12.517s][info][cpu]                                                                s       %  utilized
>> [12.517s][info][cpu]    Process
>> [12.517s][info][cpu]      Total                                              175.7628  100.00      14.0
>> [12.517s][info][cpu]      VM Thread                                            7.0000    3.98       0.6
>> [12.517s][info][cpu]      Garbage Collection                                  72.0000   40.96       5.8
>> [12.517s][info][cpu]        GC Threads                                        70.0000   39.83       5.6
>> [12.517s][info][cpu]        VM Thread                                          1.0000    0.57       0.1
>> [12.518s][info][cpu]        String Deduplication                               0.0000    0.00       0.0
>> [12.518s][info][cpu] =====================================================================================
>> 
>> 
>> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Prefer returning 0 over +/-inf,nan

Seems like JVM/TI folks will be interested also.

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

PR Comment: https://git.openjdk.org/jdk/pull/26621#issuecomment-3152782164

From dholmes at openjdk.org  Tue Aug  5 02:10:09 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 5 Aug 2025 02:10:09 GMT
Subject: RFR: 8263476: NMT: Stack guard pages should not be marked as
 committed [v3]
In-Reply-To: <Hv5Bte_jswZl8u2WPO9HrwMaHnWGZVaPlNfDdROONCg=.4affdc2a-81da-4bd0-8a3d-3b2aa9d09283@github.com>
References: <BojYWaP10BJMEWDQYSRiMKR0cOWzMF5At9_3fwD6uUw=.becf6902-01f1-41e0-965d-18a945a6dfcf@github.com>
 <Hv5Bte_jswZl8u2WPO9HrwMaHnWGZVaPlNfDdROONCg=.4affdc2a-81da-4bd0-8a3d-3b2aa9d09283@github.com>
Message-ID: <-m2C6FnT09hdxd-11YMFvujRqU1LX3R9GAnjFPGfmuk=.6b392586-bf99-4938-a88a-f43ccb39267b@github.com>

On Mon, 4 Aug 2025 14:04:15 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Use reserved (instead of committed) memory for stack-guard-pages on linux like systems.
>> 
>> `os::must_commit_stack_guard_pages` uses `commit` in its name, but `commit` usually has specific meanings in OS memory context. The actual question the caller is asking is whether the caller needs to do some preparation work before marking the guard-pages as inaccessible. To avoid confusion, I changed it to "allocate". Other suggestions are welcome.
>> 
>> Test: tier1-3
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

> Use reserved (instead of committed) memory for stack-guard-pages on linux like systems.

Why? What is the difference? Can we fail to get a stack-page when we need it if it was only reserved?

The issue description seems concerned with NMT output but you are actually making a significant change to the guard-page functionality  and I don't understand the motivation for doing so.

> In os::create_attached_thread, we can see the stack is mapped on demand for primordial thread (main-thread).

Note that this is not an expected case and we don't really support running the VM on the primordial thread and strongly advise against it. How did you test this?

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

PR Comment: https://git.openjdk.org/jdk/pull/26571#issuecomment-3153025686

From dholmes at openjdk.org  Tue Aug  5 02:31:04 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 5 Aug 2025 02:31:04 GMT
Subject: RFR: 8303612:
 runtime/StackGuardPages/TestStackGuardPagesNative.java fails with exit code
 139
In-Reply-To: <blniq87ptY1r2ZSL2nR17MV-SHTmPOPcAPWRgCVqL24=.b011371a-c54e-4fd9-b25b-19e22c321d3f@github.com>
References: <oRl4abf8ZV5qD9GNScJMRwwZD2PkdiDGJykDFs1Cmgo=.8c961e33-291f-4ba1-b494-ad5eab7ee72c@github.com>
 <blniq87ptY1r2ZSL2nR17MV-SHTmPOPcAPWRgCVqL24=.b011371a-c54e-4fd9-b25b-19e22c321d3f@github.com>
Message-ID: <lJRJpcHQe1HHoiDFbTwWZo13-3BhpMq4uwFNegBJ1ww=.1ccda972-41a1-4373-baba-c9f0a0e1795f@github.com>

On Wed, 9 Jul 2025 01:41:17 GMT, mazhen <duke at openjdk.org> wrote:

>> This pull request addresses an issue in `runtime/StackGuardPages/TestStackGuardPagesNative` where the native test component (`exeinvoke.c`) exhibited platform-dependent behavior and did not fully align with the intended test objectives for verifying stack guard page removal on thread detachment.
>> 
>> **Summary of the Problem:**
>> 
>> The `test_native_overflow_initial` scenario within `TestStackGuardPagesNative` showed inconsistent results:
>> *   On certain Linux distributions (e.g., CentOS 7), the test would hang and eventually time out during its second phase of stack allocation.
>> *   On other distributions (e.g., Ubuntu 24), the test would pass, but this pass was found to be coincidental, relying on an unintended `SEGV_MAPERR` to terminate a loop that should have had a defined exit condition.
>> 
>> The core issue was that the native code's second stack overflow attempt, designed to check for guard page removal, used an unbounded loop. Its termination (and thus the test's outcome) depended on platform-specific OS behavior regarding extensive stack allocation after guard pages are supposedly modified.
>> 
>> **Test Objective Analysis:**
>> 
>> The primary goal of `TestStackGuardPagesNative`, particularly for the initial thread (`test_native_overflow_initial`), is to:
>> 1.  **Verify Guard Page Presence:** Confirm that when a native thread is attached to the JVM, a deliberate stack overflow triggers a `SIGSEGV` with `si_code = SEGV_ACCERR`, indicating an active stack guard page.
>> 2.  **Verify Guard Page Removal/Modification:** After the thread detaches from the JVM via `DetachCurrentThread()`, confirm that the previously active stack guard page is no longer enforcing the same strict protection. This is ideally demonstrated by successfully allocating stack space up to the depth that previously caused the `SEGV_ACCERR`, **without encountering any signal**.
>> 
>> **How the Original Implementation Deviated from the Test Intent:**
>> 
>> The native `do_overflow` function, when invoked for the second phase (to check guard page removal), implemented an unconditional `for(;;)` loop.
>> *   **Intended Logic vs. Actual Behavior:** The test intended for this second phase to demonstrate that allocations up to the prior failure depth are now "clean" (no `SEGV_ACCERR`). However, the unbounded loop meant:
>>     *   On systems like CentOS 7, where deep stack allocation without an immediate `SEGV_MAPERR` was possible, this loop ran for an excessive duration, leading to a hang.
>>  ...
>
> Hi @jdksjolen ,
> 
> Following up on this. As per the bot's message two weeks ago, I've been waiting for my OCA to be processed, but it seems to be stuck.
> I understand that PRs are not reviewed until the OCA is cleared, but since the suggested two-week waiting period has passed, I was hoping someone could help to check or escalate the status of my OCA application internally.
> 
> My Oracle Account Email: mz1999 at gmail.com
> 
> Any help would be greatly appreciated. Thank you!

@mz1999 the forever-loop was added as part of the "hardening" changes by JDK-8295344, so it seems you are saying that introduced a new bug? How does your proposed change compare to the code that we had prior to the "hardening"? I just want to try and see what the original problem with this code was. Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/25689#issuecomment-3153058529

From dholmes at openjdk.org  Tue Aug  5 02:59:12 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 5 Aug 2025 02:59:12 GMT
Subject: RFR: 8359820: Improve handshake/safepoint timeout diagnostic
 messages [v8]
In-Reply-To: <J_7p0R3HxKsa1KG_w6EoFPj0dcm7_POhnRxDRtHW_EI=.7d3147fe-f47c-45ab-abf3-04ce48a2524d@github.com>
References: <FZ87bVfDootrLeANGguMFpcTm7X8AEqzuKVQspmSkmE=.4484090b-ba49-498c-bb07-71d22fd34823@github.com>
 <J_7p0R3HxKsa1KG_w6EoFPj0dcm7_POhnRxDRtHW_EI=.7d3147fe-f47c-45ab-abf3-04ce48a2524d@github.com>
Message-ID: <1U_dYNfwmT6t1Ymb9HUFntrTLFkR18Nxy8G-mN5apW0=.a1de2e75-31f0-4a0e-b012-059755d6661a@github.com>

On Mon, 4 Aug 2025 08:37:23 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> The problem in the issue description is not a problem by itself, the behavior is not unexpected, but it is somewhat difficult to find out what caused SIGILL to be fired.
>> 
>> We propagate this information from `handshake::handle_timeout()` to `VMError::report()` with a help of a global variable.  The same mechanism is used to address a similar issue in the safepoint timeout handler. 
>> 
>> Tested in tiers 1-3.
>
> 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 17 additional commits since the last revision:
> 
>  - 8359820: Addressed reviewer's comments
>  - Merge remote-tracking branch 'origin/master' into JDK-8359820-SIGILL-with-low-handshake-timeout-on-intel-sde
>  - 8359820: Addressed reviewer's comments
>  - 8359820: Addressed reviewer's comments
>  - Merge remote-tracking branch 'origin/master' into JDK-8359820-SIGILL-with-low-handshake-timeout-on-intel-sde
>  - 8359820: Fixed spaces
>  - 8359820: Addressed reviewer's comments
>  - 8359820: Addressed reviewer's comments
>  - 8359820: Addressed reviewer's comments
>  - Merge remote-tracking branch 'origin/master' into JDK-8359820-SIGILL-with-low-handshake-timeout-on-intel-sde
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/cd8cf2b8...d85769af

LGTM!

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26309#pullrequestreview-3086347740

From dholmes at openjdk.org  Tue Aug  5 06:32:12 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 5 Aug 2025 06:32:12 GMT
Subject: RFR: 8364141: Remove LockingMode related code from x86 [v2]
In-Reply-To: <m3XncMjv5FTFkwbb-G3_LPmzaD0umC3f6d8MUgHMdg4=.ebe5d5a3-4078-4e10-b441-3cc8d5a5a177@github.com>
References: <g7WNqmFlJOkai-zeEjD09M5TwpL3fAMkZUAy37b747U=.faa6d9f5-1894-4507-a0f1-1dd41f3bdd43@github.com>
 <m3XncMjv5FTFkwbb-G3_LPmzaD0umC3f6d8MUgHMdg4=.ebe5d5a3-4078-4e10-b441-3cc8d5a5a177@github.com>
Message-ID: <6GG7DTClrrPBBfGhO0OFwolXrssuVPjxbK8KkJ7uafk=.382a9e23-88b7-4fae-9e5e-00c88d309af8@github.com>

On Mon, 4 Aug 2025 12:52:39 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
>> 
>> This PR removes `LockingMode` related code from the **x86** platform.
>> 
>> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.
>> 
>> Passes tier1-tier5 with no added problems.
>
> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update one after review

Looks great! I ssuspect there may be more cleanup possible down the track but for now (with whitespace disabled) this PR clearly shows the eradication of the LockingMode.

Some minor nits in pre-existing code, and a couple of queries.

Thanks

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 392:

> 390: // Some commentary on balanced locking:
> 391: //
> 392: // fast_lock and fast_unlock are emitted only for provably balanced lock sites.

I assume this is also correct for `lightweight_lock` and `lightweight_unlock`?

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 397:

> 395: // The interpreter provides two properties:
> 396: // I1:  At return-time the interpreter automatically and quietly unlocks any
> 397: //      objects acquired the current activation (frame).  Recall that the

Suggestion:

//      objects acquired in the current activation (frame).  Recall that the

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 401:

> 399: //      a frame.
> 400: // I2:  If a method attempts to unlock an object that is not held by the
> 401: //      the frame the interpreter throws IMSX.

Suggestion:

//      frame the interpreter throws IMSX.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 409:

> 407: //
> 408: // The only other source of unbalanced locking would be JNI.  The "Java Native Interface:
> 409: // Programmer's Guide and Specification" claims that an object locked by jni_monitorenter

Suggestion:

// The only other source of unbalanced locking would be JNI.  The "Java Native Interface
// Specification" states that an object locked by JNI's_MonitorEnter

src/hotspot/cpu/x86/interp_masm_x86.cpp line 1034:

> 1032: 
> 1033:   // Load object pointer into obj_reg
> 1034:   movptr(obj_reg, Address(lock_reg, BasicObjectLock::obj_offset()));

Do you not still need the `in_bytes()` around `obj_offset()`?

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26552#pullrequestreview-3086744966
PR Review Comment: https://git.openjdk.org/jdk/pull/26552#discussion_r2253257552
PR Review Comment: https://git.openjdk.org/jdk/pull/26552#discussion_r2253258321
PR Review Comment: https://git.openjdk.org/jdk/pull/26552#discussion_r2253259156
PR Review Comment: https://git.openjdk.org/jdk/pull/26552#discussion_r2253263689
PR Review Comment: https://git.openjdk.org/jdk/pull/26552#discussion_r2253276071

From dholmes at openjdk.org  Tue Aug  5 06:36:05 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 5 Aug 2025 06:36:05 GMT
Subject: RFR: 8364406: Remove LockingMode related code from aarch64
In-Reply-To: <YgHBd1bQAjTri-T6bu_WxnTz606-Wijg995KPVcbao0=.beb80bbe-9ff5-4c05-9ccc-a8e47519542a@github.com>
References: <YgHBd1bQAjTri-T6bu_WxnTz606-Wijg995KPVcbao0=.beb80bbe-9ff5-4c05-9ccc-a8e47519542a@github.com>
Message-ID: <kGKjjCSh1KEFhPsWVD6ed0TkMP2ar5lYHziy19hHwPQ=.2c0ed731-5455-4284-a3f5-c145590d116d@github.com>

On Fri, 1 Aug 2025 11:22:50 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
> 
> This PR removes `LockingMode` related code from the **aarch64** platform.
> 
> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.
> 
> Passes tier1-tier5 with no added problems.

LGTM2!

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26594#pullrequestreview-3086791755

From dholmes at openjdk.org  Tue Aug  5 06:45:02 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 5 Aug 2025 06:45:02 GMT
Subject: RFR: 8364518: Support for Job Objects in os::commit_memory_limit()
 on Windows [v2]
In-Reply-To: <1yjYw2L7Jta-_-v0KPNcvz8wS9arjOCzvrwQpZ6sP6k=.186ac2f0-6d5f-4dd6-bcdb-839841847f25@github.com>
References: <ybsWeoo6MjS7HBqweDMwkVllcABSLyDcaOSNe828i6o=.8ae55f56-2042-4909-bb25-a1730e17ff64@github.com>
 <1yjYw2L7Jta-_-v0KPNcvz8wS9arjOCzvrwQpZ6sP6k=.186ac2f0-6d5f-4dd6-bcdb-839841847f25@github.com>
Message-ID: <FYyf4PdoanNjYQx_aDtIKQfFUAd3Ejgi4jxe-UjjZqE=.d442fc00-0e92-4b67-bd30-cd7b24f8dbeb@github.com>

On Mon, 4 Aug 2025 07:40:12 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> We currently use os::commit_memory_limit() to limit the initial, min and max values when ergonomically setting the heap size. Right now, os::commit_memory_limit() returns the available virtual address space on Windows, which is guaranteed to be the upper-bound of how much memory can be committed. However, this does not take into account user-configurable limits.
>> 
>> I propose revising os::commit_memory_limit() to consider Windows Job Objects. Job Objects can, among other things, restrict the amount of memory that can be committed by a single process or all processes in a job. If we are unable to query Job Object information or if no limit is set, I suggest returning SIZE_MAX, since the next effective limit is the available virtual address space. The size of this virtual address space cannot be modified by the user, except by consuming it. 
>> 
>> For more details and short examples, I have created a GitHub repository summarizing my findings regarding memory limits and Job Objects on Windows: [https://github.com/jsikstro/MemoryLimitsWindows ](https://github.com/jsikstro/MemoryLimitsWindows).
>> 
>> Adding support for Job Objects in this way adds support for detecting memory limits when using native Windows Hyper-V containers, which uses Job Objects to limit memory.
>> 
>> Testing:
>> * Oracle's tier1-2
>> * Manual testing on Windows using both [Process Governor](https://github.com/lowleveldesign/process-governor) (a popular tool), and creating a Job Object manually.
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Print error message if query fails

I can't help but think that this should be part of a broader effort to support "containers" on Windows. We allowed the use of JobObjects for the processor count because it was similar what you could do with cpu-sets on Linux and not fundamentally "container" related. What you propose here looks good, but surely there are more things that need to be adjusted to account for JobObjects in this space? Case in point I just raised a query today about why we have a confused notion of "physical memory" on Linux, depending on whether you are running in a container or not. I would suspect a similar distinction would need to be made on Windows if running under JobObjects.

To be clear I have no issue with the current PR providing this part of Windows "container" support, but I would like to see at least an Umbrella JBS issue (JEP?) created to cover everything that would be needed for such support. Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/26593#issuecomment-3153708050

From dholmes at openjdk.org  Tue Aug  5 06:48:06 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 5 Aug 2025 06:48:06 GMT
Subject: RFR: 8364518: Support for Job Objects in os::commit_memory_limit()
 on Windows [v2]
In-Reply-To: <1yjYw2L7Jta-_-v0KPNcvz8wS9arjOCzvrwQpZ6sP6k=.186ac2f0-6d5f-4dd6-bcdb-839841847f25@github.com>
References: <ybsWeoo6MjS7HBqweDMwkVllcABSLyDcaOSNe828i6o=.8ae55f56-2042-4909-bb25-a1730e17ff64@github.com>
 <1yjYw2L7Jta-_-v0KPNcvz8wS9arjOCzvrwQpZ6sP6k=.186ac2f0-6d5f-4dd6-bcdb-839841847f25@github.com>
Message-ID: <ev7zm5nnlid_OjvjInn2HHvH_ApAqNMDS3vWvi52r2U=.a411272c-c8b5-4ac4-b569-2c68670c070d@github.com>

On Mon, 4 Aug 2025 07:40:12 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> We currently use os::commit_memory_limit() to limit the initial, min and max values when ergonomically setting the heap size. Right now, os::commit_memory_limit() returns the available virtual address space on Windows, which is guaranteed to be the upper-bound of how much memory can be committed. However, this does not take into account user-configurable limits.
>> 
>> I propose revising os::commit_memory_limit() to consider Windows Job Objects. Job Objects can, among other things, restrict the amount of memory that can be committed by a single process or all processes in a job. If we are unable to query Job Object information or if no limit is set, I suggest returning SIZE_MAX, since the next effective limit is the available virtual address space. The size of this virtual address space cannot be modified by the user, except by consuming it. 
>> 
>> For more details and short examples, I have created a GitHub repository summarizing my findings regarding memory limits and Job Objects on Windows: [https://github.com/jsikstro/MemoryLimitsWindows ](https://github.com/jsikstro/MemoryLimitsWindows).
>> 
>> Adding support for Job Objects in this way adds support for detecting memory limits when using native Windows Hyper-V containers, which uses Job Objects to limit memory.
>> 
>> Testing:
>> * Oracle's tier1-2
>> * Manual testing on Windows using both [Process Governor](https://github.com/lowleveldesign/process-governor) (a popular tool), and creating a Job Object manually.
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Print error message if query fails

src/hotspot/os/windows/os_windows.cpp line 3321:

> 3319: 
> 3320:   // No limit
> 3321:   return SIZE_MAX;

Shouldn't we fallback to using ` GlobalMemoryStatusEx` if we are not part of a Job?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26593#discussion_r2253314501

From jsjolen at openjdk.org  Tue Aug  5 07:29:08 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 5 Aug 2025 07:29:08 GMT
Subject: RFR: 8303612:
 runtime/StackGuardPages/TestStackGuardPagesNative.java fails with exit code
 139
In-Reply-To: <oRl4abf8ZV5qD9GNScJMRwwZD2PkdiDGJykDFs1Cmgo=.8c961e33-291f-4ba1-b494-ad5eab7ee72c@github.com>
References: <oRl4abf8ZV5qD9GNScJMRwwZD2PkdiDGJykDFs1Cmgo=.8c961e33-291f-4ba1-b494-ad5eab7ee72c@github.com>
Message-ID: <PEAWUcztWC4ZE2QHELWc5xXhVhZcBY6l9eOqy9mfqls=.34e3f2b5-0ea4-4ba9-8422-48a9211625b2@github.com>

On Mon, 9 Jun 2025 06:53:20 GMT, mazhen <duke at openjdk.org> wrote:

> This pull request addresses an issue in `runtime/StackGuardPages/TestStackGuardPagesNative` where the native test component (`exeinvoke.c`) exhibited platform-dependent behavior and did not fully align with the intended test objectives for verifying stack guard page removal on thread detachment.
> 
> **Summary of the Problem:**
> 
> The `test_native_overflow_initial` scenario within `TestStackGuardPagesNative` showed inconsistent results:
> *   On certain Linux distributions (e.g., CentOS 7), the test would hang and eventually time out during its second phase of stack allocation.
> *   On other distributions (e.g., Ubuntu 24), the test would pass, but this pass was found to be coincidental, relying on an unintended `SEGV_MAPERR` to terminate a loop that should have had a defined exit condition.
> 
> The core issue was that the native code's second stack overflow attempt, designed to check for guard page removal, used an unbounded loop. Its termination (and thus the test's outcome) depended on platform-specific OS behavior regarding extensive stack allocation after guard pages are supposedly modified.
> 
> **Test Objective Analysis:**
> 
> The primary goal of `TestStackGuardPagesNative`, particularly for the initial thread (`test_native_overflow_initial`), is to:
> 1.  **Verify Guard Page Presence:** Confirm that when a native thread is attached to the JVM, a deliberate stack overflow triggers a `SIGSEGV` with `si_code = SEGV_ACCERR`, indicating an active stack guard page.
> 2.  **Verify Guard Page Removal/Modification:** After the thread detaches from the JVM via `DetachCurrentThread()`, confirm that the previously active stack guard page is no longer enforcing the same strict protection. This is ideally demonstrated by successfully allocating stack space up to the depth that previously caused the `SEGV_ACCERR`, **without encountering any signal**.
> 
> **How the Original Implementation Deviated from the Test Intent:**
> 
> The native `do_overflow` function, when invoked for the second phase (to check guard page removal), implemented an unconditional `for(;;)` loop.
> *   **Intended Logic vs. Actual Behavior:** The test intended for this second phase to demonstrate that allocations up to the prior failure depth are now "clean" (no `SEGV_ACCERR`). However, the unbounded loop meant:
>     *   On systems like CentOS 7, where deep stack allocation without an immediate `SEGV_MAPERR` was possible, this loop ran for an excessive duration, leading to a hang.
>     *   On systems like Ubuntu 24, the loop *...

Hi!

I've never seen a CentOS 7 error nor an Ubuntu error, where does this come from? This issue was created before the forever-loop was introduced, where we had this:

```c++
void do_overflow(){
  int *p = alloca(sizeof(int));
  if (_kp_rec_count == 0 || _rec_count < _kp_rec_count) {
      _rec_count ++;
      do_overflow();
  }



But that's the, morally, same code as you've added back. So, did the 'hardening' fix the original bug, but introduce a new bug? Isn't exit code 139 a SIGSEGV, so does this change a different type of bug?

Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/25689#issuecomment-3153827579

From duke at openjdk.org  Tue Aug  5 07:37:09 2025
From: duke at openjdk.org (duke)
Date: Tue, 5 Aug 2025 07:37:09 GMT
Subject: RFR: 8359820: Improve handshake/safepoint timeout diagnostic
 messages [v8]
In-Reply-To: <J_7p0R3HxKsa1KG_w6EoFPj0dcm7_POhnRxDRtHW_EI=.7d3147fe-f47c-45ab-abf3-04ce48a2524d@github.com>
References: <FZ87bVfDootrLeANGguMFpcTm7X8AEqzuKVQspmSkmE=.4484090b-ba49-498c-bb07-71d22fd34823@github.com>
 <J_7p0R3HxKsa1KG_w6EoFPj0dcm7_POhnRxDRtHW_EI=.7d3147fe-f47c-45ab-abf3-04ce48a2524d@github.com>
Message-ID: <e5_X2teDjxSsYKJMrqGLu3Oevd4TgV6HE0UGk92pTZo=.dd587ca1-06b5-46ac-8a52-9381178eba9b@github.com>

On Mon, 4 Aug 2025 08:37:23 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> The problem in the issue description is not a problem by itself, the behavior is not unexpected, but it is somewhat difficult to find out what caused SIGILL to be fired.
>> 
>> We propagate this information from `handshake::handle_timeout()` to `VMError::report()` with a help of a global variable.  The same mechanism is used to address a similar issue in the safepoint timeout handler. 
>> 
>> Tested in tiers 1-3.
>
> 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 17 additional commits since the last revision:
> 
>  - 8359820: Addressed reviewer's comments
>  - Merge remote-tracking branch 'origin/master' into JDK-8359820-SIGILL-with-low-handshake-timeout-on-intel-sde
>  - 8359820: Addressed reviewer's comments
>  - 8359820: Addressed reviewer's comments
>  - Merge remote-tracking branch 'origin/master' into JDK-8359820-SIGILL-with-low-handshake-timeout-on-intel-sde
>  - 8359820: Fixed spaces
>  - 8359820: Addressed reviewer's comments
>  - 8359820: Addressed reviewer's comments
>  - 8359820: Addressed reviewer's comments
>  - Merge remote-tracking branch 'origin/master' into JDK-8359820-SIGILL-with-low-handshake-timeout-on-intel-sde
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/b65e89c4...d85769af

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

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

PR Comment: https://git.openjdk.org/jdk/pull/26309#issuecomment-3153853570

From mbaesken at openjdk.org  Tue Aug  5 07:38:22 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 5 Aug 2025 07:38:22 GMT
Subject: RFR: 8364514: [asan]
 runtime/jni/checked/TestCharArrayReleasing.java heap-buffer-overflow [v2]
In-Reply-To: <yZawVqmQPuYBMqD2OZnkWLMti0SWMxLn0vQQhbBL3MY=.784dd3f5-2826-4f86-802f-88e0a7b53087@github.com>
References: <yZawVqmQPuYBMqD2OZnkWLMti0SWMxLn0vQQhbBL3MY=.784dd3f5-2826-4f86-802f-88e0a7b53087@github.com>
Message-ID: <kzZyChvR13kNIMjcVrUrIsVCW9jBzfI6rq6Tj8FOjME=.609f94d9-aa86-4322-9307-73e5723f345a@github.com>

> When running with ASAN enabled binaries , the test runtime/jni/checked/TestCharArrayReleasing.java fails with a  heap-buffer-overflow . This is expected because the test checks API usage errors and this way triggers ASAN.

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

  Adjust comment as suggested by David

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26598/files
  - new: https://git.openjdk.org/jdk/pull/26598/files/3258a5b3..644b4d10

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

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

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

From dholmes at openjdk.org  Tue Aug  5 07:56:05 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 5 Aug 2025 07:56:05 GMT
Subject: RFR: 8364514: [asan]
 runtime/jni/checked/TestCharArrayReleasing.java heap-buffer-overflow [v2]
In-Reply-To: <kzZyChvR13kNIMjcVrUrIsVCW9jBzfI6rq6Tj8FOjME=.609f94d9-aa86-4322-9307-73e5723f345a@github.com>
References: <yZawVqmQPuYBMqD2OZnkWLMti0SWMxLn0vQQhbBL3MY=.784dd3f5-2826-4f86-802f-88e0a7b53087@github.com>
 <kzZyChvR13kNIMjcVrUrIsVCW9jBzfI6rq6Tj8FOjME=.609f94d9-aa86-4322-9307-73e5723f345a@github.com>
Message-ID: <8YpuAkyjSh5U2jZrmqoJ84rLPtbE_VVRjY46-7lbgc4=.ef15249f-5c97-4b6b-8b25-48e257e7a5ef@github.com>

On Tue, 5 Aug 2025 07:38:22 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When running with ASAN enabled binaries , the test runtime/jni/checked/TestCharArrayReleasing.java fails with a  heap-buffer-overflow . This is expected because the test checks API usage errors and this way triggers ASAN.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust comment as suggested by David

Marked as reviewed by dholmes (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26598#pullrequestreview-3087033452

From mbaesken at openjdk.org  Tue Aug  5 08:06:13 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 5 Aug 2025 08:06:13 GMT
Subject: RFR: 8364514: [asan]
 runtime/jni/checked/TestCharArrayReleasing.java heap-buffer-overflow [v2]
In-Reply-To: <kzZyChvR13kNIMjcVrUrIsVCW9jBzfI6rq6Tj8FOjME=.609f94d9-aa86-4322-9307-73e5723f345a@github.com>
References: <yZawVqmQPuYBMqD2OZnkWLMti0SWMxLn0vQQhbBL3MY=.784dd3f5-2826-4f86-802f-88e0a7b53087@github.com>
 <kzZyChvR13kNIMjcVrUrIsVCW9jBzfI6rq6Tj8FOjME=.609f94d9-aa86-4322-9307-73e5723f345a@github.com>
Message-ID: <vj8IErN9qRplMzqUlIoToRHDQ-qWrMDqLYgAdhz07E4=.4143bdae-ad55-44cf-95f2-459d43749718@github.com>

On Tue, 5 Aug 2025 07:38:22 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When running with ASAN enabled binaries , the test runtime/jni/checked/TestCharArrayReleasing.java fails with a  heap-buffer-overflow . This is expected because the test checks API usage errors and this way triggers ASAN.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust comment as suggested by David

Thanks for the review !

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

PR Comment: https://git.openjdk.org/jdk/pull/26598#issuecomment-3154005652

From mbaesken at openjdk.org  Tue Aug  5 08:06:14 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 5 Aug 2025 08:06:14 GMT
Subject: Integrated: 8364514: [asan]
 runtime/jni/checked/TestCharArrayReleasing.java heap-buffer-overflow
In-Reply-To: <yZawVqmQPuYBMqD2OZnkWLMti0SWMxLn0vQQhbBL3MY=.784dd3f5-2826-4f86-802f-88e0a7b53087@github.com>
References: <yZawVqmQPuYBMqD2OZnkWLMti0SWMxLn0vQQhbBL3MY=.784dd3f5-2826-4f86-802f-88e0a7b53087@github.com>
Message-ID: <aK75MQSU7VhZqw1Mh4kUiq5XTxyGhJ_fCaelKQRFLsg=.450563f4-a6e6-46d1-a7ec-b83808a5e845@github.com>

On Fri, 1 Aug 2025 13:16:40 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running with ASAN enabled binaries , the test runtime/jni/checked/TestCharArrayReleasing.java fails with a  heap-buffer-overflow . This is expected because the test checks API usage errors and this way triggers ASAN.

This pull request has now been integrated.

Changeset: 67ba8b45
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/67ba8b45dd632c40d5e6872d2a6ce24f86c22152
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8364514: [asan] runtime/jni/checked/TestCharArrayReleasing.java heap-buffer-overflow

Reviewed-by: dholmes

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

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

From jsikstro at openjdk.org  Tue Aug  5 08:27:04 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 5 Aug 2025 08:27:04 GMT
Subject: RFR: 8364518: Support for Job Objects in os::commit_memory_limit()
 on Windows [v2]
In-Reply-To: <ev7zm5nnlid_OjvjInn2HHvH_ApAqNMDS3vWvi52r2U=.a411272c-c8b5-4ac4-b569-2c68670c070d@github.com>
References: <ybsWeoo6MjS7HBqweDMwkVllcABSLyDcaOSNe828i6o=.8ae55f56-2042-4909-bb25-a1730e17ff64@github.com>
 <1yjYw2L7Jta-_-v0KPNcvz8wS9arjOCzvrwQpZ6sP6k=.186ac2f0-6d5f-4dd6-bcdb-839841847f25@github.com>
 <ev7zm5nnlid_OjvjInn2HHvH_ApAqNMDS3vWvi52r2U=.a411272c-c8b5-4ac4-b569-2c68670c070d@github.com>
Message-ID: <bt3OhmvpSxXHJJmEFCO1_f1UMwi0aMN1TFYjj08BPbU=.155d1826-8f35-4d9c-a8d1-9ff5dbb6f055@github.com>

On Tue, 5 Aug 2025 06:45:50 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Print error message if query fails
>
> src/hotspot/os/windows/os_windows.cpp line 3321:
> 
>> 3319: 
>> 3320:   // No limit
>> 3321:   return SIZE_MAX;
> 
> Shouldn't we fallback to using ` GlobalMemoryStatusEx` if we are not part of a Job?

In [https://github.com/openjdk/jdk/pull/26530 ](https://github.com/openjdk/jdk/pull/26530) (concerning the implementation of os::commit_memory_limit and os::reserve_memory_limit), we return SIZE_MAX to indicate that there is no limit imposed by the user or system. We could potentially fall back to using `GlobalMemoryStatusEx`, which may be more accurate than returning SIZE_MAX. However, I think it is rare that there is a practical difference between using SIZE_MAX and the size of the available virtual address space, since both are typically very large values. If you or others feel strongly about falling back to reporting the size of available virtual address space from `GlobalMemoryStatusEx`, I?m open to that approach.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26593#discussion_r2253538357

From jsikstro at openjdk.org  Tue Aug  5 08:34:06 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 5 Aug 2025 08:34:06 GMT
Subject: RFR: 8364518: Support for Job Objects in os::commit_memory_limit()
 on Windows [v2]
In-Reply-To: <FYyf4PdoanNjYQx_aDtIKQfFUAd3Ejgi4jxe-UjjZqE=.d442fc00-0e92-4b67-bd30-cd7b24f8dbeb@github.com>
References: <ybsWeoo6MjS7HBqweDMwkVllcABSLyDcaOSNe828i6o=.8ae55f56-2042-4909-bb25-a1730e17ff64@github.com>
 <1yjYw2L7Jta-_-v0KPNcvz8wS9arjOCzvrwQpZ6sP6k=.186ac2f0-6d5f-4dd6-bcdb-839841847f25@github.com>
 <FYyf4PdoanNjYQx_aDtIKQfFUAd3Ejgi4jxe-UjjZqE=.d442fc00-0e92-4b67-bd30-cd7b24f8dbeb@github.com>
Message-ID: <6zPK6VWlzyk7vhdIYcIzgtdaSsZNubUTpFR6gZSYAlY=.b15fd2e6-b088-4eb0-905b-97f1cd58082d@github.com>

On Tue, 5 Aug 2025 06:42:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Print error message if query fails
>
> I can't help but think that this should be part of a broader effort to support "containers" on Windows. We allowed the use of JobObjects for the processor count because it was similar what you could do with cpu-sets on Linux and not fundamentally "container" related. What you propose here looks good, but surely there are more things that need to be adjusted to account for JobObjects in this space? Case in point I just raised a query today about why we have a confused notion of "physical memory" on Linux, depending on whether you are running in a container or not. I would suspect a similar distinction would need to be made on Windows if running under JobObjects.
> 
> To be clear I have no issue with the current PR providing this part of Windows "container" support, but I would like to see at least an Umbrella JBS issue (JEP?) created to cover everything that would be needed for such support. Thanks

Thank you for your input @dholmes-ora, and I agree that broader support for Job Objects, and by extension, native Windows containers, are possible in this space. I have nothing against creating an umbrella issue that covers adding support for native Windows containers. However, such containers were not my main focus, but an added benefit I suppose.

Using the size of the available virtual address space is a good indicator on how much memory can be committed, and will always be the absolute upper-bound. However, reading limits set by Job Object(s) is more complete IMO, since it (is the only way to?) limits how much memory can be committed, which is what this function is aiming to answer. So even though I think this overlaps with native Windows container support, I think this is a standalone enhancement as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/26593#issuecomment-3154096676

From aph at openjdk.org  Tue Aug  5 08:43:03 2025
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 5 Aug 2025 08:43:03 GMT
Subject: RFR: 8364406: Remove LockingMode related code from aarch64
In-Reply-To: <YgHBd1bQAjTri-T6bu_WxnTz606-Wijg995KPVcbao0=.beb80bbe-9ff5-4c05-9ccc-a8e47519542a@github.com>
References: <YgHBd1bQAjTri-T6bu_WxnTz606-Wijg995KPVcbao0=.beb80bbe-9ff5-4c05-9ccc-a8e47519542a@github.com>
Message-ID: <0WusCE1pJku6_tyIBSUsKzxfNQh1ndoge7Ob3SJkvyc=.88a10d59-6dad-418d-9a5b-61c0348216c6@github.com>

On Fri, 1 Aug 2025 11:22:50 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
> 
> This PR removes `LockingMode` related code from the **aarch64** platform.
> 
> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.
> 
> Passes tier1-tier5 with no added problems.

Marked as reviewed by aph (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26594#pullrequestreview-3087192206

From ayang at openjdk.org  Tue Aug  5 09:16:04 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 5 Aug 2025 09:16:04 GMT
Subject: RFR: 8263476: NMT: Stack guard pages should not be marked as
 committed [v3]
In-Reply-To: <-m2C6FnT09hdxd-11YMFvujRqU1LX3R9GAnjFPGfmuk=.6b392586-bf99-4938-a88a-f43ccb39267b@github.com>
References: <BojYWaP10BJMEWDQYSRiMKR0cOWzMF5At9_3fwD6uUw=.becf6902-01f1-41e0-965d-18a945a6dfcf@github.com>
 <Hv5Bte_jswZl8u2WPO9HrwMaHnWGZVaPlNfDdROONCg=.4affdc2a-81da-4bd0-8a3d-3b2aa9d09283@github.com>
 <-m2C6FnT09hdxd-11YMFvujRqU1LX3R9GAnjFPGfmuk=.6b392586-bf99-4938-a88a-f43ccb39267b@github.com>
Message-ID: <kkIhDicoTdlpDoPc8jwPC2j7l5aYBCOrQCKYuJq_mkE=.09a1b3e9-891d-4afa-bf04-7cfe7c2a16c2@github.com>

On Tue, 5 Aug 2025 02:07:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Why? What is the difference? Can we fail to get a stack-page when we need it if it was only reserved?

Those guard-pages should never be accessed; we have called `os::guard_memory` on them, so accessing them causes segfault. Since they will never use any physical memory, using committed-memory for them is unnecessary, and incurs some implementation complexity, which this patch tries to clean up.

> The issue description seems concerned with NMT output but you are actually making a significant change to the guard-page functionality ...

Indeed, the diff actually doesn't touch any NMT code; it changes how stack-guard-pages is implemented. I should update the ticket description to avoid confusions.

> Note that this is not an expected case and we don't really support running the VM on the primordial thread and strongly advise against it. How did you test this?

`pd_create_stack_guard_pages` contains some comments/doc explaining how to handle the special case for the primordial-thread, so I revised the existing implementation to support the new reserve-only mechanism. I ran the usual tier1-3 testing.

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

PR Comment: https://git.openjdk.org/jdk/pull/26571#issuecomment-3154236544

From jsjolen at openjdk.org  Tue Aug  5 10:20:05 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 5 Aug 2025 10:20:05 GMT
Subject: RFR: 8263476: NMT: Stack guard pages should not be marked as
 committed [v3]
In-Reply-To: <Hv5Bte_jswZl8u2WPO9HrwMaHnWGZVaPlNfDdROONCg=.4affdc2a-81da-4bd0-8a3d-3b2aa9d09283@github.com>
References: <BojYWaP10BJMEWDQYSRiMKR0cOWzMF5At9_3fwD6uUw=.becf6902-01f1-41e0-965d-18a945a6dfcf@github.com>
 <Hv5Bte_jswZl8u2WPO9HrwMaHnWGZVaPlNfDdROONCg=.4affdc2a-81da-4bd0-8a3d-3b2aa9d09283@github.com>
Message-ID: <XFVE0zpxpvKss8rVm-g2L1mdsoh4oLEfWm_hSQacdto=.97112baa-477c-436f-a3eb-579574b09676@github.com>

On Mon, 4 Aug 2025 14:04:15 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Use reserved (instead of committed) memory for stack-guard-pages on linux like systems.
>> 
>> `os::must_commit_stack_guard_pages` uses `commit` in its name, but `commit` usually has specific meanings in OS memory context. The actual question the caller is asking is whether the caller needs to do some preparation work before marking the guard-pages as inaccessible. To avoid confusion, I changed it to "allocate". Other suggestions are welcome.
>> 
>> Test: tier1-3
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

I like this solution, and I'm open to the idea of changing the title and contents of the ticket.

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

PR Comment: https://git.openjdk.org/jdk/pull/26571#issuecomment-3154583191

From duke at openjdk.org  Tue Aug  5 10:43:39 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Tue, 5 Aug 2025 10:43:39 GMT
Subject: RFR: 8364723: Sort share/interpreter includes
Message-ID: <7qTazdkllXqIeG4psogIJvNAWxhZWwDoqqy_2ScIfzY=.f0aaf1e9-b7d3-45ed-b81d-6f37408bf93f@github.com>

This PR sorts the includes in `hotspot/share/interpreter` using SortIncludes.java. I'm also adding the directory to TestIncludesAreSorted.

Passes tier1.

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

Commit messages:
 - sort

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

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

From duke at openjdk.org  Tue Aug  5 10:43:40 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Tue, 5 Aug 2025 10:43:40 GMT
Subject: RFR: 8364723: Sort share/interpreter includes
In-Reply-To: <7qTazdkllXqIeG4psogIJvNAWxhZWwDoqqy_2ScIfzY=.f0aaf1e9-b7d3-45ed-b81d-6f37408bf93f@github.com>
References: <7qTazdkllXqIeG4psogIJvNAWxhZWwDoqqy_2ScIfzY=.f0aaf1e9-b7d3-45ed-b81d-6f37408bf93f@github.com>
Message-ID: <cgN8gAShH2qyjN3Xumj2h24QGpZRi8I478H3KnujvOQ=.6a6b625d-c004-416e-b536-1b6c68c35a59@github.com>

On Tue, 5 Aug 2025 10:38:11 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> This PR sorts the includes in `hotspot/share/interpreter` using SortIncludes.java. I'm also adding the directory to TestIncludesAreSorted.
> 
> Passes tier1.

src/hotspot/share/interpreter/zero/bytecodeInterpreter.inline.hpp line 45:

> 43: #endif
> 44: 
> 45: # include "bytecodeInterpreter_zero.inline.hpp"

Does a space between `#` and `include` have any special significance which should be kept throughout reordering?

src/hotspot/share/interpreter/zero/zeroInterpreterGenerator.hpp line 32:

> 30: 
> 31: # include "entry_zero.hpp"
> 32: // # include "interpreter/interp_masm.hpp"

This was commented long time ago (1550fd889b467d9866ac00a3bc7ab1f879e7f20a), I guess it can be removed safely.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26639#discussion_r2253942952
PR Review Comment: https://git.openjdk.org/jdk/pull/26639#discussion_r2253944754

From dholmes at openjdk.org  Tue Aug  5 12:04:03 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 5 Aug 2025 12:04:03 GMT
Subject: RFR: 8263476: NMT: Stack guard pages should not be marked as
 committed [v3]
In-Reply-To: <kkIhDicoTdlpDoPc8jwPC2j7l5aYBCOrQCKYuJq_mkE=.09a1b3e9-891d-4afa-bf04-7cfe7c2a16c2@github.com>
References: <BojYWaP10BJMEWDQYSRiMKR0cOWzMF5At9_3fwD6uUw=.becf6902-01f1-41e0-965d-18a945a6dfcf@github.com>
 <Hv5Bte_jswZl8u2WPO9HrwMaHnWGZVaPlNfDdROONCg=.4affdc2a-81da-4bd0-8a3d-3b2aa9d09283@github.com>
 <-m2C6FnT09hdxd-11YMFvujRqU1LX3R9GAnjFPGfmuk=.6b392586-bf99-4938-a88a-f43ccb39267b@github.com>
 <kkIhDicoTdlpDoPc8jwPC2j7l5aYBCOrQCKYuJq_mkE=.09a1b3e9-891d-4afa-bf04-7cfe7c2a16c2@github.com>
Message-ID: <scNO_VC0223m8g-JxxbsFZK7ZVc2zPFxa9kzJLkuS3M=.df18299e-e658-4ef6-85c2-07592176b656@github.com>

On Tue, 5 Aug 2025 09:13:28 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Since they will never use any physical memory, using committed-memory for them is unnecessary, 

Windows only allows you to protect committed pages! Linux seems more lax. I don't know about BSD, or macOS or AIX.

> I should update the ticket description to avoid confusions.

Yes please do so. I think changing the guard mechanism in this way needs a bit more obvious "socialising". There may be people who would be interested in this but have ignored it because it appeared to be about NMT labelling! And we need the AIX folk to confirm the changes on their platform.

>  I ran the usual tier1-3 testing.

Normally our VM never gets loaded on the primordial thread so your changes there are untested. We may have one test that loads the VM on the primordial thread, but even then I'm not sure that would adequately test your changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/26571#issuecomment-3154923922

From fbredberg at openjdk.org  Tue Aug  5 12:16:08 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Tue, 5 Aug 2025 12:16:08 GMT
Subject: RFR: 8364141: Remove LockingMode related code from x86 [v2]
In-Reply-To: <6GG7DTClrrPBBfGhO0OFwolXrssuVPjxbK8KkJ7uafk=.382a9e23-88b7-4fae-9e5e-00c88d309af8@github.com>
References: <g7WNqmFlJOkai-zeEjD09M5TwpL3fAMkZUAy37b747U=.faa6d9f5-1894-4507-a0f1-1dd41f3bdd43@github.com>
 <m3XncMjv5FTFkwbb-G3_LPmzaD0umC3f6d8MUgHMdg4=.ebe5d5a3-4078-4e10-b441-3cc8d5a5a177@github.com>
 <6GG7DTClrrPBBfGhO0OFwolXrssuVPjxbK8KkJ7uafk=.382a9e23-88b7-4fae-9e5e-00c88d309af8@github.com>
Message-ID: <V9RyZfUoV5sBaoDMi_uCQdSBenhlGav-EDNW0p0W_eM=.a45b037f-b252-4289-97f1-8ca34502b7e1@github.com>

On Tue, 5 Aug 2025 06:25:13 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update one after review
>
> src/hotspot/cpu/x86/interp_masm_x86.cpp line 1034:
> 
>> 1032: 
>> 1033:   // Load object pointer into obj_reg
>> 1034:   movptr(obj_reg, Address(lock_reg, BasicObjectLock::obj_offset()));
> 
> Do you not still need the `in_bytes()` around `obj_offset()`?

I don't think so. Or at least there are lots of examples that seems to do just fine without `in_bytes()` around `obj_offset()`, like [this line](https://github.com/openjdk/jdk/blob/2a0521863ba7d9df9b4039e61b2ce6932960cd22/src/hotspot/cpu/x86/interp_masm_x86.cpp#L1073).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26552#discussion_r2254163684

From fbredberg at openjdk.org  Tue Aug  5 12:23:04 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Tue, 5 Aug 2025 12:23:04 GMT
Subject: RFR: 8364141: Remove LockingMode related code from x86 [v2]
In-Reply-To: <6GG7DTClrrPBBfGhO0OFwolXrssuVPjxbK8KkJ7uafk=.382a9e23-88b7-4fae-9e5e-00c88d309af8@github.com>
References: <g7WNqmFlJOkai-zeEjD09M5TwpL3fAMkZUAy37b747U=.faa6d9f5-1894-4507-a0f1-1dd41f3bdd43@github.com>
 <m3XncMjv5FTFkwbb-G3_LPmzaD0umC3f6d8MUgHMdg4=.ebe5d5a3-4078-4e10-b441-3cc8d5a5a177@github.com>
 <6GG7DTClrrPBBfGhO0OFwolXrssuVPjxbK8KkJ7uafk=.382a9e23-88b7-4fae-9e5e-00c88d309af8@github.com>
Message-ID: <BVlQwbBZGYi_AdwrtzsPJMCA16wFuFP-GDvonyZ5bmU=.5eb06c5b-024e-4b6b-a712-c8220f263b7d@github.com>

On Tue, 5 Aug 2025 06:14:57 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update one after review
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 392:
> 
>> 390: // Some commentary on balanced locking:
>> 391: //
>> 392: // fast_lock and fast_unlock are emitted only for provably balanced lock sites.
> 
> I assume this is also correct for `lightweight_lock` and `lightweight_unlock`?

I assume the same. But I don't want to change the comments too much, since I plan to do a clean up in which all "lightweight" prefixes will be gone and we will begin talking about it as the normal locking mode. And no, I will not just rename it `normal_lock()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26552#discussion_r2254178104

From fbredberg at openjdk.org  Tue Aug  5 12:36:00 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Tue, 5 Aug 2025 12:36:00 GMT
Subject: RFR: 8364141: Remove LockingMode related code from x86 [v3]
In-Reply-To: <g7WNqmFlJOkai-zeEjD09M5TwpL3fAMkZUAy37b747U=.faa6d9f5-1894-4507-a0f1-1dd41f3bdd43@github.com>
References: <g7WNqmFlJOkai-zeEjD09M5TwpL3fAMkZUAy37b747U=.faa6d9f5-1894-4507-a0f1-1dd41f3bdd43@github.com>
Message-ID: <-ncfIHskHiKnUbJ3nRR8rp678hInGalmZW4CnS5QJp0=.baabffb7-5f4f-4f06-9b23-315f8e9372a7@github.com>

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
> 
> This PR removes `LockingMode` related code from the **x86** platform.
> 
> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.
> 
> Passes tier1-tier5 with no added problems.

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

  Update two after review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26552/files
  - new: https://git.openjdk.org/jdk/pull/26552/files/2a052186..9fa0c947

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

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

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

From fbredberg at openjdk.org  Tue Aug  5 12:36:02 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Tue, 5 Aug 2025 12:36:02 GMT
Subject: RFR: 8364141: Remove LockingMode related code from x86 [v2]
In-Reply-To: <6GG7DTClrrPBBfGhO0OFwolXrssuVPjxbK8KkJ7uafk=.382a9e23-88b7-4fae-9e5e-00c88d309af8@github.com>
References: <g7WNqmFlJOkai-zeEjD09M5TwpL3fAMkZUAy37b747U=.faa6d9f5-1894-4507-a0f1-1dd41f3bdd43@github.com>
 <m3XncMjv5FTFkwbb-G3_LPmzaD0umC3f6d8MUgHMdg4=.ebe5d5a3-4078-4e10-b441-3cc8d5a5a177@github.com>
 <6GG7DTClrrPBBfGhO0OFwolXrssuVPjxbK8KkJ7uafk=.382a9e23-88b7-4fae-9e5e-00c88d309af8@github.com>
Message-ID: <4oH-UY40hMDHJ8JRjizYotMhfO6-zhMnw0onu_JvJo0=.5be9f40b-b384-4e78-a35b-df416d4b74e5@github.com>

On Tue, 5 Aug 2025 06:15:21 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update one after review
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 397:
> 
>> 395: // The interpreter provides two properties:
>> 396: // I1:  At return-time the interpreter automatically and quietly unlocks any
>> 397: //      objects acquired the current activation (frame).  Recall that the
> 
> Suggestion:
> 
> //      objects acquired in the current activation (frame).  Recall that the

Fixed

> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 401:
> 
>> 399: //      a frame.
>> 400: // I2:  If a method attempts to unlock an object that is not held by the
>> 401: //      the frame the interpreter throws IMSX.
> 
> Suggestion:
> 
> //      frame the interpreter throws IMSX.

Fixed

> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 409:
> 
>> 407: //
>> 408: // The only other source of unbalanced locking would be JNI.  The "Java Native Interface:
>> 409: // Programmer's Guide and Specification" claims that an object locked by jni_monitorenter
> 
> Suggestion:
> 
> // The only other source of unbalanced locking would be JNI.  The "Java Native Interface
> // Specification" states that an object locked by JNI's_MonitorEnter

Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26552#discussion_r2254201947
PR Review Comment: https://git.openjdk.org/jdk/pull/26552#discussion_r2254202571
PR Review Comment: https://git.openjdk.org/jdk/pull/26552#discussion_r2254203510

From shade at openjdk.org  Tue Aug  5 12:58:06 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 5 Aug 2025 12:58:06 GMT
Subject: RFR: 8364723: Sort share/interpreter includes
In-Reply-To: <7qTazdkllXqIeG4psogIJvNAWxhZWwDoqqy_2ScIfzY=.f0aaf1e9-b7d3-45ed-b81d-6f37408bf93f@github.com>
References: <7qTazdkllXqIeG4psogIJvNAWxhZWwDoqqy_2ScIfzY=.f0aaf1e9-b7d3-45ed-b81d-6f37408bf93f@github.com>
Message-ID: <CFvOCsqjFqtTbyt2LRYYOA4ssb0AM1r0QeIzE8MATBE=.e668b5d5-9acd-4bb6-933d-a952704f7fd1@github.com>

On Tue, 5 Aug 2025 10:38:11 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> This PR sorts the includes in `hotspot/share/interpreter` using SortIncludes.java. I'm also adding the directory to TestIncludesAreSorted.
> 
> Passes tier1.

This looks fine.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26639#pullrequestreview-3088155289

From ayang at openjdk.org  Tue Aug  5 12:58:04 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 5 Aug 2025 12:58:04 GMT
Subject: RFR: 8263476: Use reserved memory for stack guard pages [v3]
In-Reply-To: <scNO_VC0223m8g-JxxbsFZK7ZVc2zPFxa9kzJLkuS3M=.df18299e-e658-4ef6-85c2-07592176b656@github.com>
References: <BojYWaP10BJMEWDQYSRiMKR0cOWzMF5At9_3fwD6uUw=.becf6902-01f1-41e0-965d-18a945a6dfcf@github.com>
 <Hv5Bte_jswZl8u2WPO9HrwMaHnWGZVaPlNfDdROONCg=.4affdc2a-81da-4bd0-8a3d-3b2aa9d09283@github.com>
 <-m2C6FnT09hdxd-11YMFvujRqU1LX3R9GAnjFPGfmuk=.6b392586-bf99-4938-a88a-f43ccb39267b@github.com>
 <kkIhDicoTdlpDoPc8jwPC2j7l5aYBCOrQCKYuJq_mkE=.09a1b3e9-891d-4afa-bf04-7cfe7c2a16c2@github.com>
 <scNO_VC0223m8g-JxxbsFZK7ZVc2zPFxa9kzJLkuS3M=.df18299e-e658-4ef6-85c2-07592176b656@github.com>
Message-ID: <KuanZl4MZw85BBfDKRAe1mcathzh0xQiLHaIMlDhNCE=.21ce25c2-e185-4328-b5d2-b3c1d2a1569b@github.com>

On Tue, 5 Aug 2025 12:01:19 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Windows only allows you to protect committed pages!

That's true, but it is an implementation detail that should be dealt with inside `os::create_stack_guard_pages` -- the caller `StackOverflow` does not require guard-pages to be committed.

> Yes please do so. I think changing the guard mechanism in this way needs a bit more obvious "socialising". ...

Updated.

> ... but even then I'm not sure that would adequately test your changes.

I have gone through the git-history of `os::pd_create_stack_guard_pages` on linux, but don't see any particular test involved for that area of code. Anyway, I will run higher tiers of tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/26571#issuecomment-3155103573

From shade at openjdk.org  Tue Aug  5 12:58:07 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 5 Aug 2025 12:58:07 GMT
Subject: RFR: 8364723: Sort share/interpreter includes
In-Reply-To: <cgN8gAShH2qyjN3Xumj2h24QGpZRi8I478H3KnujvOQ=.6a6b625d-c004-416e-b536-1b6c68c35a59@github.com>
References: <7qTazdkllXqIeG4psogIJvNAWxhZWwDoqqy_2ScIfzY=.f0aaf1e9-b7d3-45ed-b81d-6f37408bf93f@github.com>
 <cgN8gAShH2qyjN3Xumj2h24QGpZRi8I478H3KnujvOQ=.6a6b625d-c004-416e-b536-1b6c68c35a59@github.com>
Message-ID: <dvdlq8E4Qvad68Sragc17RTEsM5clfDrufDyTdK6hqU=.b3343572-a6e9-4c81-b677-b48bec0cf280@github.com>

On Tue, 5 Aug 2025 10:39:13 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> This PR sorts the includes in `hotspot/share/interpreter` using SortIncludes.java. I'm also adding the directory to TestIncludesAreSorted.
>> 
>> Passes tier1.
>
> src/hotspot/share/interpreter/zero/bytecodeInterpreter.inline.hpp line 45:
> 
>> 43: #endif
>> 44: 
>> 45: # include "bytecodeInterpreter_zero.inline.hpp"
> 
> Does a space between `#` and `include` have any special significance which should be kept throughout reordering?

No, it is right to clean it up to `#include`.

> src/hotspot/share/interpreter/zero/zeroInterpreterGenerator.hpp line 32:
> 
>> 30: 
>> 31: # include "entry_zero.hpp"
>> 32: // # include "interpreter/interp_masm.hpp"
> 
> This was commented long time ago (1550fd889b467d9866ac00a3bc7ab1f879e7f20a), I guess it can be removed safely.

Correct.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26639#discussion_r2254258587
PR Review Comment: https://git.openjdk.org/jdk/pull/26639#discussion_r2254259562

From ayang at openjdk.org  Tue Aug  5 18:13:03 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 5 Aug 2025 18:13:03 GMT
Subject: RFR: 8263476: Use reserved memory for stack guard pages [v3]
In-Reply-To: <FrpsSrJPnzecNLiVIcpQ1N_eFqITv05bR9XG8bYzTi4=.398978ab-7bb7-4a50-84ae-6642e401488a@github.com>
References: <BojYWaP10BJMEWDQYSRiMKR0cOWzMF5At9_3fwD6uUw=.becf6902-01f1-41e0-965d-18a945a6dfcf@github.com>
 <Hv5Bte_jswZl8u2WPO9HrwMaHnWGZVaPlNfDdROONCg=.4affdc2a-81da-4bd0-8a3d-3b2aa9d09283@github.com>
 <FrpsSrJPnzecNLiVIcpQ1N_eFqITv05bR9XG8bYzTi4=.398978ab-7bb7-4a50-84ae-6642e401488a@github.com>
Message-ID: <_kfIQnrYWzpulkPWVw09y4PwoGkQ8MoseoBQyUqMsKE=.44227b0d-82cd-4f24-8b96-0ed480fe1333@github.com>

On Tue, 5 Aug 2025 18:00:34 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review
>
> src/hotspot/os/linux/os_linux.cpp line 3478:
> 
>> 3476:       ::munmap((void*)stack_extent, (uintptr_t)(addr + size - stack_extent));
>> 3477:     }
>> 3478:     return os::pd_attempt_reserve_memory_at(addr, size, !ExecMem) != nullptr;
> 
> This patch indeed goes beyond my original intention. IIRC,  my intention was to replace `os::commit()` with `::mprotect()` to set protection on stack guard pages.

I think our starting point is the same, dropping the use of `commit` for stack-guard-pages. However, I encountered some complication (linux main-thread and windows) along the way, which caused the patch to take this shape.

This particular line (L3478) is for linux main-thread only.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26571#discussion_r2255008389

From zgu at openjdk.org  Tue Aug  5 18:03:04 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Tue, 5 Aug 2025 18:03:04 GMT
Subject: RFR: 8263476: Use reserved memory for stack guard pages [v3]
In-Reply-To: <Hv5Bte_jswZl8u2WPO9HrwMaHnWGZVaPlNfDdROONCg=.4affdc2a-81da-4bd0-8a3d-3b2aa9d09283@github.com>
References: <BojYWaP10BJMEWDQYSRiMKR0cOWzMF5At9_3fwD6uUw=.becf6902-01f1-41e0-965d-18a945a6dfcf@github.com>
 <Hv5Bte_jswZl8u2WPO9HrwMaHnWGZVaPlNfDdROONCg=.4affdc2a-81da-4bd0-8a3d-3b2aa9d09283@github.com>
Message-ID: <FrpsSrJPnzecNLiVIcpQ1N_eFqITv05bR9XG8bYzTi4=.398978ab-7bb7-4a50-84ae-6642e401488a@github.com>

On Mon, 4 Aug 2025 14:04:15 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Use reserved (instead of committed) memory for stack-guard-pages on linux like systems.
>> 
>> `os::must_commit_stack_guard_pages` uses `commit` in its name, but `commit` usually has specific meanings in OS memory context. The actual question the caller is asking is whether the caller needs to do some preparation work before marking the guard-pages as inaccessible. To avoid confusion, I changed it to "allocate". Other suggestions are welcome.
>> 
>> Test: tier1-3
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

src/hotspot/os/linux/os_linux.cpp line 3478:

> 3476:       ::munmap((void*)stack_extent, (uintptr_t)(addr + size - stack_extent));
> 3477:     }
> 3478:     return os::pd_attempt_reserve_memory_at(addr, size, !ExecMem) != nullptr;

This patch indeed goes beyond my original intention. IIRC,  my intention was to replace `os::commit()` with `::mprotect()` to set protection on stack guard pages.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26571#discussion_r2254990412

From dholmes at openjdk.org  Wed Aug  6 00:19:12 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Aug 2025 00:19:12 GMT
Subject: RFR: 8364235: Fix for JDK-8361447 breaks the alignment
 requirements for GuardedMemory [v5]
In-Reply-To: <eJCKuEkAlCZO_9d_WbVzVLak_DwHS0pECnrhC6abF9o=.869327e0-f060-4584-a0a9-78453e305682@github.com>
References: <2NMVt2xW6-rTS7vQPJ8fPkfabrTPiugEqGf4KlttYSo=.46b5d9f5-90b3-44b9-b3db-f139672145dc@github.com>
 <eJCKuEkAlCZO_9d_WbVzVLak_DwHS0pECnrhC6abF9o=.869327e0-f060-4584-a0a9-78453e305682@github.com>
Message-ID: <US02g3fZZ4BmyRSvieJOO-_nDmRDeaM-lyybf8BF6bM=.71a12d99-0f42-4c69-ae96-51d4d16850ff@github.com>

On Sun, 3 Aug 2025 22:54:33 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The fix for [JDK-8361447](https://bugs.openjdk.org/browse/JDK-8361447) added a new field to the `GuardHeader`, not realizing that the size of the `GuardHeader` must be such that the address of the user-data has the strictest necessary alignment (16-byte).
>> 
>> We need to add a padding field to restore the alignment.
>> 
>> A static assert is added to check the alignment.
>> 
>> Testing:
>>  - tiers 1-3 (in progress)
>> 
>> Thanks
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add "padding" to the layout description

After even more discussions it seems there is no way to guarantee the required base-address alignment, we just have to assume it is correct (as we implicitly assume today), so the `alignas(16)`  fix will stay. Just need someone to re-approve after the comment edit. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/26524#issuecomment-3157009956

From dholmes at openjdk.org  Wed Aug  6 02:06:03 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Aug 2025 02:06:03 GMT
Subject: RFR: 8263476: Use reserved memory for stack guard pages [v3]
In-Reply-To: <Hv5Bte_jswZl8u2WPO9HrwMaHnWGZVaPlNfDdROONCg=.4affdc2a-81da-4bd0-8a3d-3b2aa9d09283@github.com>
References: <BojYWaP10BJMEWDQYSRiMKR0cOWzMF5At9_3fwD6uUw=.becf6902-01f1-41e0-965d-18a945a6dfcf@github.com>
 <Hv5Bte_jswZl8u2WPO9HrwMaHnWGZVaPlNfDdROONCg=.4affdc2a-81da-4bd0-8a3d-3b2aa9d09283@github.com>
Message-ID: <k3AklnzEeb5Ys0Tkt73YpXU_N1CvVOGxirhhTZsjOus=.3b6f09c8-68f5-4976-99f9-0d4de9a08db2@github.com>

On Mon, 4 Aug 2025 14:04:15 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Use reserved (instead of committed) memory for stack-guard-pages on linux like systems.
>> 
>> `os::must_commit_stack_guard_pages` uses `commit` in its name, but `commit` usually has specific meanings in OS memory context. The actual question the caller is asking is whether the caller needs to do some preparation work before marking the guard-pages as inaccessible. To avoid confusion, I changed it to "allocate". Other suggestions are welcome.
>> 
>> Test: tier1-3
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

> 8263476: Use reserved memory for stack guard pages

But this is still inaccurate as there are no changes to Windows. And while I can see where you dropped `os::commit` for Linux, I can't see what causes changes on the other OS. ?? Is this really just a Linux change?

I also still do not see any motivating argument for this. What is the benefit? You say it removes some complexity but I see no evidence of that in the PR. And doing different things on different platforms reduces the overall understandability of the code.

> but don't see any particular test involved for that area of code. Anyway, I will run higher tiers of tests.

You seem to be missing my point. You can run all the tiers you like and you will not be testing the code changes that relate to the primordial thread because we never use the primordial thread to run the VM (again I think we have one test that does so to ensure such a scenario at least does not crash on startup). If you are making changes to the way the stack is managed for the primordial thread then you are going to have to come up with a way to test those changes - or else propvide a convincing argument as to why the changes can be determined correct by observation. We basically leave that code alone.

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

PR Comment: https://git.openjdk.org/jdk/pull/26571#issuecomment-3157170151

From dholmes at openjdk.org  Wed Aug  6 02:09:03 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Aug 2025 02:09:03 GMT
Subject: RFR: 8263476: Use reserved memory for stack guard pages [v3]
In-Reply-To: <FrpsSrJPnzecNLiVIcpQ1N_eFqITv05bR9XG8bYzTi4=.398978ab-7bb7-4a50-84ae-6642e401488a@github.com>
References: <BojYWaP10BJMEWDQYSRiMKR0cOWzMF5At9_3fwD6uUw=.becf6902-01f1-41e0-965d-18a945a6dfcf@github.com>
 <Hv5Bte_jswZl8u2WPO9HrwMaHnWGZVaPlNfDdROONCg=.4affdc2a-81da-4bd0-8a3d-3b2aa9d09283@github.com>
 <FrpsSrJPnzecNLiVIcpQ1N_eFqITv05bR9XG8bYzTi4=.398978ab-7bb7-4a50-84ae-6642e401488a@github.com>
Message-ID: <Y06nt2THUQCaX7imrempGXN8ztnGflBwWc16JH1T3fo=.f4df6b35-88d4-417b-9b2c-87cb4354d793@github.com>

On Tue, 5 Aug 2025 18:00:34 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review
>
> src/hotspot/os/linux/os_linux.cpp line 3478:
> 
>> 3476:       ::munmap((void*)stack_extent, (uintptr_t)(addr + size - stack_extent));
>> 3477:     }
>> 3478:     return os::pd_attempt_reserve_memory_at(addr, size, !ExecMem) != nullptr;
> 
> This patch indeed goes beyond my original intention. IIRC,  my intention was to replace `os::commit()` with `::mprotect()` to set protection on stack guard pages.

@zhengyu123 I don't understand your comment - we already do use `mprotect` on the (committed) stack guard pages. ??

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26571#discussion_r2255695875

From duke at openjdk.org  Wed Aug  6 04:48:18 2025
From: duke at openjdk.org (Anton Artemov)
Date: Wed, 6 Aug 2025 04:48:18 GMT
Subject: Integrated: 8359820: Improve handshake/safepoint timeout diagnostic
 messages
In-Reply-To: <FZ87bVfDootrLeANGguMFpcTm7X8AEqzuKVQspmSkmE=.4484090b-ba49-498c-bb07-71d22fd34823@github.com>
References: <FZ87bVfDootrLeANGguMFpcTm7X8AEqzuKVQspmSkmE=.4484090b-ba49-498c-bb07-71d22fd34823@github.com>
Message-ID: <-1vBdBx68rRwtDIGZoq02SKEB6v76S59LZoSrU170yU=.f639cc5b-e650-45a7-b61f-bdfbe51f6858@github.com>

On Tue, 15 Jul 2025 08:37:38 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> The problem in the issue description is not a problem by itself, the behavior is not unexpected, but it is somewhat difficult to find out what caused SIGILL to be fired.
> 
> We propagate this information from `handshake::handle_timeout()` to `VMError::report()` with a help of a global variable.  The same mechanism is used to address a similar issue in the safepoint timeout handler. 
> 
> Tested in tiers 1-3.

This pull request has now been integrated.

Changeset: 6656e767
Author:    Anton Artemov <anton.artemov at oracle.com>
Committer: David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6656e767db05e8e11ea17385674d8aa4385c60ed
Stats:     34 lines in 5 files changed: 31 ins; 0 del; 3 mod

8359820: Improve handshake/safepoint timeout diagnostic messages

Reviewed-by: dholmes, stuefe

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

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

From dholmes at openjdk.org  Wed Aug  6 05:46:06 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Aug 2025 05:46:06 GMT
Subject: RFR: 8364141: Remove LockingMode related code from x86 [v3]
In-Reply-To: <-ncfIHskHiKnUbJ3nRR8rp678hInGalmZW4CnS5QJp0=.baabffb7-5f4f-4f06-9b23-315f8e9372a7@github.com>
References: <g7WNqmFlJOkai-zeEjD09M5TwpL3fAMkZUAy37b747U=.faa6d9f5-1894-4507-a0f1-1dd41f3bdd43@github.com>
 <-ncfIHskHiKnUbJ3nRR8rp678hInGalmZW4CnS5QJp0=.baabffb7-5f4f-4f06-9b23-315f8e9372a7@github.com>
Message-ID: <zx8GahcduAOfkFquUTI9B1xcP-j9m1MzrARtBe7oEus=.4f78f2b8-a4b6-4e03-bd68-853c6db46124@github.com>

On Tue, 5 Aug 2025 12:36:00 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
>> 
>> This PR removes `LockingMode` related code from the **x86** platform.
>> 
>> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.
>> 
>> Passes tier1-tier5 with no added problems.
>
> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update two after review

Marked as reviewed by dholmes (Reviewer).

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 409:

> 407: //
> 408: // The only other source of unbalanced locking would be JNI.  The "Java Native Interface
> 409: // Specification" states that an object locked by JNI's_MonitorEnter should not be

Suggestion:

// Specification" states that an object locked by JNI's MonitorEnter should not be

Sorry missed the misplaced underscore due to the red-wavy-line spelling error

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

PR Review: https://git.openjdk.org/jdk/pull/26552#pullrequestreview-3090489187
PR Review Comment: https://git.openjdk.org/jdk/pull/26552#discussion_r2255920037

From dholmes at openjdk.org  Wed Aug  6 06:47:05 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Aug 2025 06:47:05 GMT
Subject: RFR: 8364518: Support for Job Objects in os::commit_memory_limit()
 on Windows [v2]
In-Reply-To: <1yjYw2L7Jta-_-v0KPNcvz8wS9arjOCzvrwQpZ6sP6k=.186ac2f0-6d5f-4dd6-bcdb-839841847f25@github.com>
References: <ybsWeoo6MjS7HBqweDMwkVllcABSLyDcaOSNe828i6o=.8ae55f56-2042-4909-bb25-a1730e17ff64@github.com>
 <1yjYw2L7Jta-_-v0KPNcvz8wS9arjOCzvrwQpZ6sP6k=.186ac2f0-6d5f-4dd6-bcdb-839841847f25@github.com>
Message-ID: <GruSrV-8KZnWrQ5yEhYnpOPuYAp9PyPduwn5vlzkcyc=.f4f1b6b5-196c-44c7-b564-16c388957cfb@github.com>

On Mon, 4 Aug 2025 07:40:12 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> We currently use os::commit_memory_limit() to limit the initial, min and max values when ergonomically setting the heap size. Right now, os::commit_memory_limit() returns the available virtual address space on Windows, which is guaranteed to be the upper-bound of how much memory can be committed. However, this does not take into account user-configurable limits.
>> 
>> I propose revising os::commit_memory_limit() to consider Windows Job Objects. Job Objects can, among other things, restrict the amount of memory that can be committed by a single process or all processes in a job. If we are unable to query Job Object information or if no limit is set, I suggest returning SIZE_MAX, since the next effective limit is the available virtual address space. The size of this virtual address space cannot be modified by the user, except by consuming it. 
>> 
>> For more details and short examples, I have created a GitHub repository summarizing my findings regarding memory limits and Job Objects on Windows: [https://github.com/jsikstro/MemoryLimitsWindows ](https://github.com/jsikstro/MemoryLimitsWindows).
>> 
>> Adding support for Job Objects in this way adds support for detecting memory limits when using native Windows Hyper-V containers, which uses Job Objects to limit memory.
>> 
>> Testing:
>> * Oracle's tier1-2
>> * Manual testing on Windows using both [Process Governor](https://github.com/lowleveldesign/process-governor) (a popular tool), and creating a Job Object manually.
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Print error message if query fails

This looks good to me. I have filed 
> [JDK-8364803](https://bugs.openjdk.org/browse/JDK-8364803) Provide support for Windows Job Objects that limit process resources

as the umbrella task for Job Object support.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26593#pullrequestreview-3090620133

From jsikstro at openjdk.org  Wed Aug  6 07:58:09 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 6 Aug 2025 07:58:09 GMT
Subject: RFR: 8364518: Support for Job Objects in os::commit_memory_limit()
 on Windows [v2]
In-Reply-To: <WbJq2GmIDl-xGFt3MsmGIpfbYlpE2m5LdIHbZM7cwX8=.ddf80ad8-400d-4faa-9b2d-15cbed66664f@github.com>
References: <ybsWeoo6MjS7HBqweDMwkVllcABSLyDcaOSNe828i6o=.8ae55f56-2042-4909-bb25-a1730e17ff64@github.com>
 <1yjYw2L7Jta-_-v0KPNcvz8wS9arjOCzvrwQpZ6sP6k=.186ac2f0-6d5f-4dd6-bcdb-839841847f25@github.com>
 <WbJq2GmIDl-xGFt3MsmGIpfbYlpE2m5LdIHbZM7cwX8=.ddf80ad8-400d-4faa-9b2d-15cbed66664f@github.com>
Message-ID: <uTbOLsCkUn8u-HBPxoGbiw-EORTR5CIIpOzdxQl6lfg=.db29a92e-8332-4ed4-aa9f-365142d17267@github.com>

On Mon, 4 Aug 2025 07:50:20 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Print error message if query fails
>
> Marked as reviewed by ayang (Reviewer).

Thank you for the reviews! @albertnetymk @dholmes-ora

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

PR Comment: https://git.openjdk.org/jdk/pull/26593#issuecomment-3157917283

From jsikstro at openjdk.org  Wed Aug  6 07:58:10 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 6 Aug 2025 07:58:10 GMT
Subject: Integrated: 8364518: Support for Job Objects in
 os::commit_memory_limit() on Windows
In-Reply-To: <ybsWeoo6MjS7HBqweDMwkVllcABSLyDcaOSNe828i6o=.8ae55f56-2042-4909-bb25-a1730e17ff64@github.com>
References: <ybsWeoo6MjS7HBqweDMwkVllcABSLyDcaOSNe828i6o=.8ae55f56-2042-4909-bb25-a1730e17ff64@github.com>
Message-ID: <bA6dZe5TgoVBFgxDPa9OxA7l4H1hBOoVRPVujsqo8ks=.6ea377f0-c471-4801-a8d0-a27c2edd21fb@github.com>

On Fri, 1 Aug 2025 10:38:32 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> We currently use os::commit_memory_limit() to limit the initial, min and max values when ergonomically setting the heap size. Right now, os::commit_memory_limit() returns the available virtual address space on Windows, which is guaranteed to be the upper-bound of how much memory can be committed. However, this does not take into account user-configurable limits.
> 
> I propose revising os::commit_memory_limit() to consider Windows Job Objects. Job Objects can, among other things, restrict the amount of memory that can be committed by a single process or all processes in a job. If we are unable to query Job Object information or if no limit is set, I suggest returning SIZE_MAX, since the next effective limit is the available virtual address space. The size of this virtual address space cannot be modified by the user, except by consuming it. 
> 
> For more details and short examples, I have created a GitHub repository summarizing my findings regarding memory limits and Job Objects on Windows: [https://github.com/jsikstro/MemoryLimitsWindows ](https://github.com/jsikstro/MemoryLimitsWindows).
> 
> Adding support for Job Objects in this way adds support for detecting memory limits when using native Windows Hyper-V containers, which uses Job Objects to limit memory.
> 
> Testing:
> * Oracle's tier1-2
> * Manual testing on Windows using both [Process Governor](https://github.com/lowleveldesign/process-governor) (a popular tool), and creating a Job Object manually.

This pull request has now been integrated.

Changeset: 8d529bc4
Author:    Joel Sikstr?m <jsikstro at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8d529bc4f361407b0b5c3ac1e62c3be0f0b8d71c
Stats:     22 lines in 1 file changed: 18 ins; 0 del; 4 mod

8364518: Support for Job Objects in os::commit_memory_limit() on Windows

Reviewed-by: ayang, dholmes

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

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

From ayang at openjdk.org  Wed Aug  6 08:15:03 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 6 Aug 2025 08:15:03 GMT
Subject: RFR: 8263476: Use reserved memory for stack guard pages [v3]
In-Reply-To: <k3AklnzEeb5Ys0Tkt73YpXU_N1CvVOGxirhhTZsjOus=.3b6f09c8-68f5-4976-99f9-0d4de9a08db2@github.com>
References: <BojYWaP10BJMEWDQYSRiMKR0cOWzMF5At9_3fwD6uUw=.becf6902-01f1-41e0-965d-18a945a6dfcf@github.com>
 <Hv5Bte_jswZl8u2WPO9HrwMaHnWGZVaPlNfDdROONCg=.4affdc2a-81da-4bd0-8a3d-3b2aa9d09283@github.com>
 <k3AklnzEeb5Ys0Tkt73YpXU_N1CvVOGxirhhTZsjOus=.3b6f09c8-68f5-4976-99f9-0d4de9a08db2@github.com>
Message-ID: <pGNL4vcpXIQpz1TqzxJKbctlxrpbjouylf01NFNp3ss=.01c6f367-6faf-4ff2-b9f5-c64e111eaa6b@github.com>

On Wed, 6 Aug 2025 02:03:18 GMT, David Holmes <dholmes at openjdk.org> wrote:

> But this is still inaccurate as there are no changes to Windows. And while I can see where you dropped os::commit for Linux, I can't see what causes changes on the other OS. ?? Is this really just a Linux change?

The PR aims to change for all platforms, but due to platform-specific setting, only BSD and Linux are actually changed. (AIX and Windows ones are just renaming.)

After the change, AIX, BSD, and Linux (excluding main-thread) share the same behavior -- stack-guard-pages mprotected without any preparation. Windows is kept as is, because it's unique requirement on memory-protection.

> You say it removes some complexity but I see no evidence of that in the PR. And doing different things on different platforms reduces the overall understandability of the code.

The removed complexity is the stack-guard-pages preparation logic on BSD and Linux non-main-threads. Due to some intrinsic platform-difference, there will always be some inconsistency. However, the proposed code at least encapsulates that inconsistency to platform-specific logic -- `StackOverflow` doesn't require committing stack-guard-pages, and OS-stack-guard-page APIs don't mandate committing memory.

Maybe I am biased, but I find the new code much easier to read. With the old code, I was quite confused when I first read the linux code -- why we are committing the to-be-mprotected memory, isn't being-reserved enough? After going through all other platforms, I realized that this commit-requirement stems from Windows-specific memory-protection-needs-committed-memory. This seems like a leaky abstraction that exposes a platform-specific oddity on the shared API level.

> ... propvide a convincing argument as to why the changes can be determined correct by observation ...

How about the new diagram I added in `os::pd_create_stack_guard_pages` for linux main-thread?

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

PR Comment: https://git.openjdk.org/jdk/pull/26571#issuecomment-3158066057

From dfenacci at openjdk.org  Wed Aug  6 08:28:07 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Wed, 6 Aug 2025 08:28:07 GMT
Subject: RFR: 8358696: Assert with extreme values for -XX:BciProfileWidth
 [v4]
In-Reply-To: <AcIJdrrh4s5bDfif6nem9K_Ib3Fo-XoOo89dXB-DFGM=.5707af03-fcea-4ce5-86d5-26ef5090585a@github.com>
References: <5TRVeAXUQi6quM-nDWEij_jk6M5K2Vk31RA-Yjd8F2M=.5b63da45-93c3-4251-9e2e-3c64b7953919@github.com>
 <_preMnRE0tqL476Pb8bPPfkixInRa-ZH5Qom7W70AW4=.a71e36da-d0e1-44e4-a3fe-9091460b813f@github.com>
 <51aYnCiXel-vz4Zu40K08E1lyBtX5JXD8PXoCr5wWUE=.15def8e4-f7c3-42ae-976e-f79ed7415bfa@github.com>
 <AcIJdrrh4s5bDfif6nem9K_Ib3Fo-XoOo89dXB-DFGM=.5707af03-fcea-4ce5-86d5-26ef5090585a@github.com>
Message-ID: <2ejqHNlL-UYAWzOUnFmNax-kpwY7G4EPl_aHZVvYslE=.28c7ae7e-f085-49fa-812f-16c8e46fec5f@github.com>

On Fri, 25 Jul 2025 09:12:35 GMT, Saranya Natarajan <snatarajan at openjdk.org> wrote:

>> src/hotspot/share/runtime/globals.hpp line 1356:
>> 
>>> 1354:   develop(int, BciProfileWidth, 2,                                          \
>>> 1355:           "Number of return bci's to record in ret profile")                \
>>> 1356:           range(0, AARCH64_ONLY(1000) NOT_AARCH64(5000))                    \
>> 
>> I'm not too sure of the usual number of returns but even just 1000 sounds quite big as maximum. Do you think we could use that for all architectures?
>
> Thank you for the review. I have tested 1000 by reducing the `InterpreterCodeSize` to the smallest value in all the specified architecture in the source code on both AArch64 and x86. It works for 1000. Hence, I think it should work on all architectures. Do you propose I make it 1000 (or a lesser value) for all architecture ?

Yes, that was more or less what I was thinking (btw we might want to check with other architectures as well).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26139#discussion_r2256350579

From dfenacci at openjdk.org  Wed Aug  6 08:32:08 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Wed, 6 Aug 2025 08:32:08 GMT
Subject: RFR: 8358696: Assert with extreme values for -XX:BciProfileWidth
 [v5]
In-Reply-To: <FZb5ohOjJiGESfNXhIPs_xAaZ2BSnCY0NTVojzDgdYg=.d016aa21-8990-4998-b7e7-cd27abcb29ce@github.com>
References: <5TRVeAXUQi6quM-nDWEij_jk6M5K2Vk31RA-Yjd8F2M=.5b63da45-93c3-4251-9e2e-3c64b7953919@github.com>
 <FZb5ohOjJiGESfNXhIPs_xAaZ2BSnCY0NTVojzDgdYg=.d016aa21-8990-4998-b7e7-cd27abcb29ce@github.com>
Message-ID: <YBR5WhaXeQJbw-TwC9Xap8LxF_ohDc0CNdfnUKjyLR0=.6f4e7bdf-6adc-42e7-a2c0-e0d079b63466@github.com>

On Fri, 25 Jul 2025 09:01:12 GMT, Saranya Natarajan <snatarajan at openjdk.org> wrote:

>> **Issue**
>> Extreme values for BciProfileWidth flag such as `java -XX:BciProfileWidth=-1 -version` and `java -XX:BciProfileWidth=100000 -version `results in assert failure `assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x0000772b63a7a3a0 <= 0x0000772b63b75159 <= 0x0000772b63b75158 `. This is observed in a x86 machine.
>> 
>> **Analysis** 
>>  On debugging the issue, I found that increasing the size of the interpreter using the `InterpreterCodeSize` variable in `src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp` prevented the above mentioned assert from failing for large values of BciProfileWidth.  
>> 
>> **Proposal** 
>> Considering the fact that larger BciProfileWidth results in slower profiling, I have proposed a range between 0 to 5000 to restrict the value for BciProfileWidth for x86 machines. This maximum value is based on modifying the `InterpreterCodeSize` variable in `src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp` using the smallest `InterpreterCodeSize` for all the architectures.  As for the lower bound, a value of -1 would be the same as 0, as this simply means  no  return bci's will be recorded in ret profile. 
>> 
>> **Issue in AArch64**
>> Additionally running the command `java -XX:BciProfileWidth= 10000 -version` (or larger values) results in a different failure  `assert(offset_ok_for_immed(offset(), size)) failed: must be, was: 32768, 3` on an AArch64 machine.This is an issue of maximum offset for `ldr/str` in AArch64 which can be fixed using `form_address`  as mentioned in [JDK-8342736](https://bugs.openjdk.org/browse/JDK-8342736). In my preliminary fix using `form_address` on AArch64 machine. I had to modify 3 `ldr` and 1 `str` instruction (in file `src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp` at line number 926, 983, and 997). With this fix  using `form_address`, `BciProfileWidth` works for maximum of 5000 after which it crashes with`assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x0000772b63a7a3a0 <= 0x0000772b63b75159 <= 0x0000772b63b75158 `.  Without this fix `BciProfileWidth` works for a maximum value of 1300.   Currently, I have suggested to restrict the upper bound on AArch64 to 1000 instead
  of fixing it with `form_address`. 
>> 
>> **Question to reviewers**
>> Do you think this is a reasonable fix ?  For AArch64 do you suggest fixing using `form_address` ? If yes, do I fix it under this PR or create another one ?
>
> Saranya Natarajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressing review comment by adding intx flag

Thanks for the changes @sarannat. Do you think we could add a small regression test (or add a couple of simple tests to an existing one)?

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

PR Comment: https://git.openjdk.org/jdk/pull/26139#issuecomment-3158201493

From stuefe at openjdk.org  Wed Aug  6 08:56:09 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 6 Aug 2025 08:56:09 GMT
Subject: RFR: 8263476: Use reserved memory for stack guard pages [v3]
In-Reply-To: <Y06nt2THUQCaX7imrempGXN8ztnGflBwWc16JH1T3fo=.f4df6b35-88d4-417b-9b2c-87cb4354d793@github.com>
References: <BojYWaP10BJMEWDQYSRiMKR0cOWzMF5At9_3fwD6uUw=.becf6902-01f1-41e0-965d-18a945a6dfcf@github.com>
 <Hv5Bte_jswZl8u2WPO9HrwMaHnWGZVaPlNfDdROONCg=.4affdc2a-81da-4bd0-8a3d-3b2aa9d09283@github.com>
 <FrpsSrJPnzecNLiVIcpQ1N_eFqITv05bR9XG8bYzTi4=.398978ab-7bb7-4a50-84ae-6642e401488a@github.com>
 <Y06nt2THUQCaX7imrempGXN8ztnGflBwWc16JH1T3fo=.f4df6b35-88d4-417b-9b2c-87cb4354d793@github.com>
Message-ID: <vN_wF316lRKdbp2IY4bAc79SNK5gxyC-TsNPGspBs-U=.d9bd9fb9-b21b-4437-9080-368efa26d027@github.com>

On Wed, 6 Aug 2025 02:06:21 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/os/linux/os_linux.cpp line 3478:
>> 
>>> 3476:       ::munmap((void*)stack_extent, (uintptr_t)(addr + size - stack_extent));
>>> 3477:     }
>>> 3478:     return os::pd_attempt_reserve_memory_at(addr, size, !ExecMem) != nullptr;
>> 
>> This patch indeed goes beyond my original intention. IIRC,  my intention was to replace `os::commit()` with `::mprotect()` to set protection on stack guard pages.
>
> @zhengyu123 I don't understand your comment - we already do use `mprotect` on the (committed) stack guard pages. ??

I am confused, too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26571#discussion_r2256444975

From shade at openjdk.org  Wed Aug  6 09:12:36 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 6 Aug 2025 09:12:36 GMT
Subject: RFR: 8359820: Improve handshake/safepoint timeout diagnostic
 messages [v8]
In-Reply-To: <J_7p0R3HxKsa1KG_w6EoFPj0dcm7_POhnRxDRtHW_EI=.7d3147fe-f47c-45ab-abf3-04ce48a2524d@github.com>
References: <FZ87bVfDootrLeANGguMFpcTm7X8AEqzuKVQspmSkmE=.4484090b-ba49-498c-bb07-71d22fd34823@github.com>
 <J_7p0R3HxKsa1KG_w6EoFPj0dcm7_POhnRxDRtHW_EI=.7d3147fe-f47c-45ab-abf3-04ce48a2524d@github.com>
Message-ID: <fWGMUVwozCP0_o6xjUvRDq2sUdoOO0_P0TFzlHcjLMc=.a891752b-b921-404a-9485-50fe2e43eb23@github.com>

On Mon, 4 Aug 2025 08:37:23 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> The problem in the issue description is not a problem by itself, the behavior is not unexpected, but it is somewhat difficult to find out what caused SIGILL to be fired.
>> 
>> We propagate this information from `handshake::handle_timeout()` to `VMError::report()` with a help of a global variable.  The same mechanism is used to address a similar issue in the safepoint timeout handler. 
>> 
>> Tested in tiers 1-3.
>
> 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 17 additional commits since the last revision:
> 
>  - 8359820: Addressed reviewer's comments
>  - Merge remote-tracking branch 'origin/master' into JDK-8359820-SIGILL-with-low-handshake-timeout-on-intel-sde
>  - 8359820: Addressed reviewer's comments
>  - 8359820: Addressed reviewer's comments
>  - Merge remote-tracking branch 'origin/master' into JDK-8359820-SIGILL-with-low-handshake-timeout-on-intel-sde
>  - 8359820: Fixed spaces
>  - 8359820: Addressed reviewer's comments
>  - 8359820: Addressed reviewer's comments
>  - 8359820: Addressed reviewer's comments
>  - Merge remote-tracking branch 'origin/master' into JDK-8359820-SIGILL-with-low-handshake-timeout-on-intel-sde
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/1bb5a3bd...d85769af

A few post-integration notes, maybe do a little follow-up cleanup?

src/hotspot/share/utilities/vmError.cpp line 107:

> 105: const size_t      VMError::_reattempt_required_stack_headroom = 64 * K;
> 106: const intptr_t    VMError::segfault_address = pd_segfault_address;
> 107: volatile intptr_t VMError::_handshake_timed_out_thread = p2i(nullptr);

Not sure why we do `intptr_t` if we only ever expect real `Thread*` here? Would avoid doing awkward `p2i` conversions in comparisons.

src/hotspot/share/utilities/vmError.cpp line 825:

> 823:       if (_siginfo != nullptr && os::signal_sent_by_kill(_siginfo)) {
> 824:         if (_handshake_timed_out_thread == p2i(_thread)) {
> 825:           st->print(" (sent by handshake timeout handler");

Looks like this message misses the closing parenthesis? `(sent by kill)`, but `(sent by handshake timeout handler`.

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

PR Review: https://git.openjdk.org/jdk/pull/26309#pullrequestreview-3091525451
PR Review Comment: https://git.openjdk.org/jdk/pull/26309#discussion_r2256490100
PR Review Comment: https://git.openjdk.org/jdk/pull/26309#discussion_r2256491930

From duke at openjdk.org  Wed Aug  6 09:22:02 2025
From: duke at openjdk.org (snake66)
Date: Wed, 6 Aug 2025 09:22:02 GMT
Subject: RFR: 8263476: Use reserved memory for stack guard pages [v3]
In-Reply-To: <Hv5Bte_jswZl8u2WPO9HrwMaHnWGZVaPlNfDdROONCg=.4affdc2a-81da-4bd0-8a3d-3b2aa9d09283@github.com>
References: <BojYWaP10BJMEWDQYSRiMKR0cOWzMF5At9_3fwD6uUw=.becf6902-01f1-41e0-965d-18a945a6dfcf@github.com>
 <Hv5Bte_jswZl8u2WPO9HrwMaHnWGZVaPlNfDdROONCg=.4affdc2a-81da-4bd0-8a3d-3b2aa9d09283@github.com>
Message-ID: <JbRzkr3N83e0ny1dRUCmltTd-B37lr3wDiUGruB1d5w=.73f411ef-4670-449b-b739-0841fb1854d7@github.com>

On Mon, 4 Aug 2025 14:04:15 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Use reserved (instead of committed) memory for stack-guard-pages on linux like systems.
>> 
>> `os::must_commit_stack_guard_pages` uses `commit` in its name, but `commit` usually has specific meanings in OS memory context. The actual question the caller is asking is whether the caller needs to do some preparation work before marking the guard-pages as inaccessible. To avoid confusion, I changed it to "allocate". Other suggestions are welcome.
>> 
>> Test: tier1-3
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

>From the perspective of FreeBSD, I think this patch will simplify things a bit for us. Need to test it to be sure, but I'm confident it will not make things any harder for us at least :)

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

PR Comment: https://git.openjdk.org/jdk/pull/26571#issuecomment-3158535505

From duke at openjdk.org  Wed Aug  6 09:33:17 2025
From: duke at openjdk.org (Anton Artemov)
Date: Wed, 6 Aug 2025 09:33:17 GMT
Subject: RFR: 8359820: Improve handshake/safepoint timeout diagnostic
 messages [v8]
In-Reply-To: <fWGMUVwozCP0_o6xjUvRDq2sUdoOO0_P0TFzlHcjLMc=.a891752b-b921-404a-9485-50fe2e43eb23@github.com>
References: <FZ87bVfDootrLeANGguMFpcTm7X8AEqzuKVQspmSkmE=.4484090b-ba49-498c-bb07-71d22fd34823@github.com>
 <J_7p0R3HxKsa1KG_w6EoFPj0dcm7_POhnRxDRtHW_EI=.7d3147fe-f47c-45ab-abf3-04ce48a2524d@github.com>
 <fWGMUVwozCP0_o6xjUvRDq2sUdoOO0_P0TFzlHcjLMc=.a891752b-b921-404a-9485-50fe2e43eb23@github.com>
Message-ID: <2ss3g2gUZADqC-DNPRq_OERREs4k7u0yoATZEEq9lqs=.c4d89bdd-0160-464e-b0e5-0f00234a2592@github.com>

On Wed, 6 Aug 2025 09:08:01 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> 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 17 additional commits since the last revision:
>> 
>>  - 8359820: Addressed reviewer's comments
>>  - Merge remote-tracking branch 'origin/master' into JDK-8359820-SIGILL-with-low-handshake-timeout-on-intel-sde
>>  - 8359820: Addressed reviewer's comments
>>  - 8359820: Addressed reviewer's comments
>>  - Merge remote-tracking branch 'origin/master' into JDK-8359820-SIGILL-with-low-handshake-timeout-on-intel-sde
>>  - 8359820: Fixed spaces
>>  - 8359820: Addressed reviewer's comments
>>  - 8359820: Addressed reviewer's comments
>>  - 8359820: Addressed reviewer's comments
>>  - Merge remote-tracking branch 'origin/master' into JDK-8359820-SIGILL-with-low-handshake-timeout-on-intel-sde
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/ecbb76bf...d85769af
>
> src/hotspot/share/utilities/vmError.cpp line 107:
> 
>> 105: const size_t      VMError::_reattempt_required_stack_headroom = 64 * K;
>> 106: const intptr_t    VMError::segfault_address = pd_segfault_address;
>> 107: volatile intptr_t VMError::_handshake_timed_out_thread = p2i(nullptr);
> 
> Not sure why we do `intptr_t` if we only ever expect real `Thread*` here? Would avoid doing awkward `p2i` conversions in comparisons.

Thanks, created a separate issue for that.

> src/hotspot/share/utilities/vmError.cpp line 825:
> 
>> 823:       if (_siginfo != nullptr && os::signal_sent_by_kill(_siginfo)) {
>> 824:         if (_handshake_timed_out_thread == p2i(_thread)) {
>> 825:           st->print(" (sent by handshake timeout handler");
> 
> Looks like this message misses the closing parenthesis? `(sent by kill)`, but `(sent by handshake timeout handler`.

Thanks, created a separate issue for that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26309#discussion_r2256564220
PR Review Comment: https://git.openjdk.org/jdk/pull/26309#discussion_r2256564447

From cnorrbin at openjdk.org  Wed Aug  6 09:40:16 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Wed, 6 Aug 2025 09:40:16 GMT
Subject: RFR: 8352067: Remove the NMT treap and replace its uses with the
 utilities red-black tree
Message-ID: <xXuaevhTzxS26C6s7DR0BdSQDFPeV5cMg4_qImS_Uw4=.fa5dc831-57b2-409c-8015-ef3dbc143c65@github.com>

Hi everyone,

The utilities red-black tree and the NMT treap serve similar functions. Given the red-black tree's versatility and stricter constraints, the treap can be removed in favour of it.

I made some modifications to the red-black tree to make it compatible with previous treap usages:
- Updated the `visit_in_order` and `visit_range_in_order` functions to require the supplied callback to return a bool, which allows us to stop traversing early.
- Improved const-correctness by ensuring that invoking these functions on a const reference provides const pointers to nodes, while non-const references provide mutable pointers. Previously the two functions behaved differently.

Changes to NMT include:
- Modified components to align with the updated const-correctness of the red-black tree functions
- Renamed structures and variables to remove "treap" from their names to reflect the new tree

The treap was also used in one place in C2. I changed this to use the red-black tree and its cursor interface, which I felt was most fitting for the use case.

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

Commit messages:
 - Replace nmttreap with rbtree

Changes: https://git.openjdk.org/jdk/pull/26655/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26655&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352067
  Stats: 1016 lines in 14 files changed: 124 ins; 816 del; 76 mod
  Patch: https://git.openjdk.org/jdk/pull/26655.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26655/head:pull/26655

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

From stuefe at openjdk.org  Wed Aug  6 09:43:08 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 6 Aug 2025 09:43:08 GMT
Subject: RFR: 8263476: Use reserved memory for stack guard pages [v3]
In-Reply-To: <rjIgNraKjfcDUQKw8zvy3jfLXy1tDk7seOMAYRO9y4g=.081ddad1-f540-4f07-827c-3017dd995f25@github.com>
References: <BojYWaP10BJMEWDQYSRiMKR0cOWzMF5At9_3fwD6uUw=.becf6902-01f1-41e0-965d-18a945a6dfcf@github.com>
 <Kwrb1dkkecP2tFGM7IZxYiKN_9ke4u5xtje3G05V5H0=.9d830cad-a360-4fc0-a4a5-2fe6e01f0b91@github.com>
 <CxqLDWolGPMO_jg80yr-u08_cRBfPtIKRI5ewf8k7WU=.95281f2b-6716-4ee9-8df9-2cdd7e623d46@github.com>
 <rjIgNraKjfcDUQKw8zvy3jfLXy1tDk7seOMAYRO9y4g=.081ddad1-f540-4f07-827c-3017dd995f25@github.com>
Message-ID: <HyFMbg_ptvNbb4y3mufJuL2_x-UTrMWgmt3crjBld-Q=.dfbfe1d5-1bad-47f6-adf2-140afaf01e3c@github.com>

On Mon, 4 Aug 2025 13:48:05 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> There is no pre-existing bug. The previous code ensures the memory range for stack-guard-pages are committed, note `os::commit_memory` is invoked in all paths. OTOH, the "reserve memory" call is only for main-thread in the new code. Also added a diagram, if that helps.
>
> Aha, now I understand. The diagram helped a lot!

I don't think we should make this change, since it introduces a subtle bug.

Apart from being hard to understand, it also opens a time window where the stack guard pages are unmapped; at line 3478, we re-establish MAP_NORESERVE mapping here, but in this time window someone else may have mapped pages in there. Now someone lives in our stack. The reservation will fail, we return false, write a "cannot establish guard pages" warning. If the primordial thread stack grows into this region, it will overwrite that misplaced memory. Errors would be very rare and intermittent.

Apart from all that, it also means that we add two unnecessary calls to mmap to likely every startup, since the condition at line 3475 is now likely always true. 

Pre-existing: to be honest, I have no idea why we even do the munmap in the first place. Why would it matter if the primordial thread stack is larger than what we think it should be?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26571#discussion_r2256483228

From stuefe at openjdk.org  Wed Aug  6 09:43:07 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 6 Aug 2025 09:43:07 GMT
Subject: RFR: 8263476: Use reserved memory for stack guard pages [v3]
In-Reply-To: <Hv5Bte_jswZl8u2WPO9HrwMaHnWGZVaPlNfDdROONCg=.4affdc2a-81da-4bd0-8a3d-3b2aa9d09283@github.com>
References: <BojYWaP10BJMEWDQYSRiMKR0cOWzMF5At9_3fwD6uUw=.becf6902-01f1-41e0-965d-18a945a6dfcf@github.com>
 <Hv5Bte_jswZl8u2WPO9HrwMaHnWGZVaPlNfDdROONCg=.4affdc2a-81da-4bd0-8a3d-3b2aa9d09283@github.com>
Message-ID: <542qBu3o6FlB7clweC-_6iOjjS6bGasPdqPY8_KrxQg=.21bbcb26-637c-4c18-83aa-dc6333fe16c8@github.com>

On Mon, 4 Aug 2025 14:04:15 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Use reserved (instead of committed) memory for stack-guard-pages on linux like systems.
>> 
>> `os::must_commit_stack_guard_pages` uses `commit` in its name, but `commit` usually has specific meanings in OS memory context. The actual question the caller is asking is whether the caller needs to do some preparation work before marking the guard-pages as inaccessible. To avoid confusion, I changed it to "allocate". Other suggestions are welcome.
>> 
>> Test: tier1-3
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

@albertnetymk @zhengyu123 I am not sure I get the point of this RFE, or the problem it tries to solve. The difference between /proc/smaps output and NMT committed output - isn't this just wrong accounting on behalf of NMT? The pages are marked in /proc/smaps with RSS=0 because they are untouched. If you were to touch them before the commit, they probably would show up as committed, but it would be better to just count them in NMT as uncommitted.

About the commit itself: 

- reserved memory (MAP_NORESERVE) is not guaranteed to crash on touch. It usually does, but there is nothing in the standard saying it has to
- so, we mprotect the pages. However, POSIX says its not valid to protect memory not allocated by mmap. Even if they were mmap'ed, there were platforms, not sure which, which did not allow mprotect on memory allocated with mmap(MAP_NORESERVE). Not an issue on Linux, but I think there were other platforms that had this problem.
- therefore we may need to commit before calling mprotect.

Fun fact: We also may run on *customer-provided* stacks. The thread may have been launched externally, e.g. by a third-party custom launcher, and attached later; the customer may have started the thread providing their own stacks, which could live wherever. I have only seen this once with a particularly enterprising customer, and they placed the stacks in bss.

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

PR Review: https://git.openjdk.org/jdk/pull/26571#pullrequestreview-3091512380

From jsjolen at openjdk.org  Wed Aug  6 10:00:04 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 6 Aug 2025 10:00:04 GMT
Subject: RFR: 8352067: Remove the NMT treap and replace its uses with the
 utilities red-black tree
In-Reply-To: <xXuaevhTzxS26C6s7DR0BdSQDFPeV5cMg4_qImS_Uw4=.fa5dc831-57b2-409c-8015-ef3dbc143c65@github.com>
References: <xXuaevhTzxS26C6s7DR0BdSQDFPeV5cMg4_qImS_Uw4=.fa5dc831-57b2-409c-8015-ef3dbc143c65@github.com>
Message-ID: <ldeyZ0K38mQiARDC8A4KeHRwPdpTSRiegDzOlovcUCg=.46d2da2f-6efb-4302-a3a2-45364984a90c@github.com>

On Wed, 6 Aug 2025 09:29:05 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> The utilities red-black tree and the NMT treap serve similar functions. Given the red-black tree's versatility and stricter time complexity, the treap can be removed in favour of it.
> 
> I made some modifications to the red-black tree to make it compatible with previous treap usages:
> - Updated the `visit_in_order` and `visit_range_in_order` functions to require the supplied callback to return a bool, which allows us to stop traversing early.
> - Improved const-correctness by ensuring that invoking these functions on a const reference provides const pointers to nodes, while non-const references provide mutable pointers. Previously the two functions behaved differently.
> 
> Changes to NMT include:
> - Modified components to align with the updated const-correctness of the red-black tree functions
> - Renamed structures and variables to remove "treap" from their names to reflect the new tree
> 
> The treap was also used in one place in C2. I changed this to use the red-black tree and its cursor interface, which I felt was most fitting for the use case.

This LGTM. What testing did you run?

src/hotspot/share/nmt/vmatree.hpp line 196:

> 194: 
> 195: public:
> 196:   using VMARBTree = RBTreeCHeap<position, IntervalChange, PositionComparator, MemTag::mtNMT>;

You should be abl to just write 'mtNMT', same for all other `MemTag::` prefixes.

src/hotspot/share/opto/printinlining.cpp line 90:

> 88: 
> 89:   return node->val();
> 90: }

Could you expand the `auto`s? It should be a code action in VSCode if you use clangd. We tend to only use auto when it's a lambda.

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

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26655#pullrequestreview-3091786865
PR Review Comment: https://git.openjdk.org/jdk/pull/26655#discussion_r2256636655
PR Review Comment: https://git.openjdk.org/jdk/pull/26655#discussion_r2256634808

From cnorrbin at openjdk.org  Wed Aug  6 11:07:42 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Wed, 6 Aug 2025 11:07:42 GMT
Subject: RFR: 8352067: Remove the NMT treap and replace its uses with the
 utilities red-black tree [v2]
In-Reply-To: <xXuaevhTzxS26C6s7DR0BdSQDFPeV5cMg4_qImS_Uw4=.fa5dc831-57b2-409c-8015-ef3dbc143c65@github.com>
References: <xXuaevhTzxS26C6s7DR0BdSQDFPeV5cMg4_qImS_Uw4=.fa5dc831-57b2-409c-8015-ef3dbc143c65@github.com>
Message-ID: <Sw5KhaC03y3T-bZa54aSCpcXwgLyDeL9h6Mzsnva0BI=.3d877982-e6bf-416a-bcdf-5ba96e5def56@github.com>

> Hi everyone,
> 
> The utilities red-black tree and the NMT treap serve similar functions. Given the red-black tree's versatility and stricter time complexity, the treap can be removed in favour of it.
> 
> I made some modifications to the red-black tree to make it compatible with previous treap usages:
> - Updated the `visit_in_order` and `visit_range_in_order` functions to require the supplied callback to return a bool, which allows us to stop traversing early.
> - Improved const-correctness by ensuring that invoking these functions on a const reference provides const pointers to nodes, while non-const references provide mutable pointers. Previously the two functions behaved differently.
> 
> Changes to NMT include:
> - Modified components to align with the updated const-correctness of the red-black tree functions
> - Renamed structures and variables to remove "treap" from their names to reflect the new tree
> 
> The treap was also used in one place in C2. I changed this to use the red-black tree and its cursor interface, which I felt was most fitting for the use case.

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

  feedback fixes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26655/files
  - new: https://git.openjdk.org/jdk/pull/26655/files/97107f5b..a495e291

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

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

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

From ayang at openjdk.org  Wed Aug  6 11:43:07 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 6 Aug 2025 11:43:07 GMT
Subject: RFR: 8263476: Use reserved memory for stack guard pages [v3]
In-Reply-To: <542qBu3o6FlB7clweC-_6iOjjS6bGasPdqPY8_KrxQg=.21bbcb26-637c-4c18-83aa-dc6333fe16c8@github.com>
References: <BojYWaP10BJMEWDQYSRiMKR0cOWzMF5At9_3fwD6uUw=.becf6902-01f1-41e0-965d-18a945a6dfcf@github.com>
 <Hv5Bte_jswZl8u2WPO9HrwMaHnWGZVaPlNfDdROONCg=.4affdc2a-81da-4bd0-8a3d-3b2aa9d09283@github.com>
 <542qBu3o6FlB7clweC-_6iOjjS6bGasPdqPY8_KrxQg=.21bbcb26-637c-4c18-83aa-dc6333fe16c8@github.com>
Message-ID: <ddlZFqTukD6gbte-FhRHnNMfMUTBUtKEZciaM5zFORs=.72727a99-5a09-45e3-9d61-2a423d9f699d@github.com>

On Wed, 6 Aug 2025 09:40:22 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> I am not sure I get the point of this RFE, or the problem it tries to solve.

It's to reduce complexity of stack-guard-pages construction -- the end result changes files on Linux and BSD only. Note that this is the only place we can commit memory without first reserving the corresponding memory.

> The difference between /proc/smaps output and NMT committed output - isn't this just wrong accounting on behalf of NMT?

The end result, as a side effect, also removes such inconsistency. Both would show them as reserved-only.

> POSIX says its not valid to protect memory not allocated by mmap

Linux allows it:

"""
On Linux, it is always permissible to call mprotect() on any
address in a process's address space (except for the kernel
vsyscall area).
"""

> Apart from being hard to understand, it also opens a time window where the stack guard pages are unmapped;

Could you elaborate which part is hard to understand? I think the newly added diagram illustrates the stack-frame clearly.

> but in this time window someone else may have mapped pages in there.

Since Linux main-thread dynamically reserves memory for stack, it's always possible that address-ranges smaller than stack-top (including stack-guard-pages) are already reserved by others. I could "reuse" the reserved memory range for stack-guard-pages, but that can result in variance in NMT-accounting, depending on how OS stack reserving status.

>  If the primordial thread stack grows into this region, it will overwrite that misplaced memory. Errors would be very rare and intermittent.

According to `MAP_GROWSDOWN` (used for main-thread), it's a guaranteed segfault. (I also tried a small C program, artificially mmaping sth at stack-end, then allocating sth large on the stack. A segfault is generated as expected.)

"""
This growth can be repeated until the
mapping grows to within a page of the high end of the next
lower mapping, at which point touching the "guard" page
will result in a SIGSEGV signal.
"""

> Apart from all that, it also means that we add two unnecessary calls to mmap to likely every startup, since the condition at line 3475 is now likely always true.

This code is only for `is_primordial_thread == true`, but this is rarely used. Hence, David's concerns on testibility, "because we never use the primordial thread to run the VM".

Therefore, this actually removes one commit-call in the most common path, because non-main-thread performs zero preparation now.

> Pre-existing: to be honest, I have no idea why we even do the munmap in the first place. Why would it matter if the primordial thread stack is larger than what we think it should be?

It's covered in the doc right before `os::pd_create_stack_guard_pages` in Linux


// However, it's essential not to split the stack region by unmapping
// a region (leaving a hole) that's already part of the stack mapping,
// so if the stack mapping has already grown beyond the guard pages at
// the time we create them, we have to truncate the stack mapping.

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

PR Comment: https://git.openjdk.org/jdk/pull/26571#issuecomment-3159809021

From fbredberg at openjdk.org  Wed Aug  6 13:59:42 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 6 Aug 2025 13:59:42 GMT
Subject: RFR: 8364570: Remove LockingMode related code from riscv64
Message-ID: <TGtRFC9NpLCnaqcLtmFttGpJIHOWxXdUB4PZHfhSHoA=.0fb2f13f-f42b-4804-804e-9b24422a08c9@github.com>

Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.

This PR removes `LockingMode` related code from the **riscv64** platform.

When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.

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

Commit messages:
 - 8364570: Remove LockingMode related code from riscv64

Changes: https://git.openjdk.org/jdk/pull/26658/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26658&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364570
  Stats: 585 lines in 9 files changed: 11 ins; 524 del; 50 mod
  Patch: https://git.openjdk.org/jdk/pull/26658.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26658/head:pull/26658

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

From azafari at openjdk.org  Wed Aug  6 14:20:06 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Wed, 6 Aug 2025 14:20:06 GMT
Subject: RFR: 8360048: NMT crash in gtest/NMTGtests.java: fatal error: NMT
 corruption: Block at 0x0000017748307120: header canary broken [v2]
In-Reply-To: <mkeyNm6ooSR46efjdLv4beXhSZLJQZKMBrCvXfSQtCU=.218b9e5f-76ad-4301-b004-cbc69b2b83f0@github.com>
References: <ByslHvuFsvtks0mVSsNgiOzfAyj0MuVKIboQy15xmJE=.a82a592f-bbf2-4fc8-866e-91dcc477717c@github.com>
 <mkeyNm6ooSR46efjdLv4beXhSZLJQZKMBrCvXfSQtCU=.218b9e5f-76ad-4301-b004-cbc69b2b83f0@github.com>
Message-ID: <u18pxJc5KUL-W1PqLrz7dDIdJD-A04TPY6N656w2Fv0=.97047d4f-537b-44be-b20f-f4a172d9cc3c@github.com>

On Tue, 24 Jun 2025 14:52:09 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> The canary header test failed since there were concurrent `remove` and `free()` from the tree. The `remove` operations are synch'ed with corresponding NMT lock. The `ReserveMemory::reserve()` uses the same lock internally and is not included in the locked code block.
>> 
>> Tests: tier5 {macosx-aarch64, linux-x64, windows-x64} x {debug, release}
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   local VMT vs static one.

keep it open, bot!

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

PR Comment: https://git.openjdk.org/jdk/pull/25950#issuecomment-3160370481

From fbredberg at openjdk.org  Wed Aug  6 14:26:02 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 6 Aug 2025 14:26:02 GMT
Subject: RFR: 8364570: Remove LockingMode related code from riscv64
In-Reply-To: <TGtRFC9NpLCnaqcLtmFttGpJIHOWxXdUB4PZHfhSHoA=.0fb2f13f-f42b-4804-804e-9b24422a08c9@github.com>
References: <TGtRFC9NpLCnaqcLtmFttGpJIHOWxXdUB4PZHfhSHoA=.0fb2f13f-f42b-4804-804e-9b24422a08c9@github.com>
Message-ID: <Zunv6GF9HVEeXvzg9bg_FWnI-uQD5_CjoFJFQ-twXVQ=.c6f05211-fc5d-4c24-95d0-9e24f893925f@github.com>

On Wed, 6 Aug 2025 11:24:22 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
> 
> This PR removes `LockingMode` related code from the **riscv64** platform.
> 
> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.

@RealFYang
I've run rudimentary tests using QEMU, but it would be nice if you could take it for a spin on real hardware.

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

PR Comment: https://git.openjdk.org/jdk/pull/26658#issuecomment-3160395253

From zgu at openjdk.org  Wed Aug  6 14:33:04 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Wed, 6 Aug 2025 14:33:04 GMT
Subject: RFR: 8263476: Use reserved memory for stack guard pages [v3]
In-Reply-To: <vN_wF316lRKdbp2IY4bAc79SNK5gxyC-TsNPGspBs-U=.d9bd9fb9-b21b-4437-9080-368efa26d027@github.com>
References: <BojYWaP10BJMEWDQYSRiMKR0cOWzMF5At9_3fwD6uUw=.becf6902-01f1-41e0-965d-18a945a6dfcf@github.com>
 <Hv5Bte_jswZl8u2WPO9HrwMaHnWGZVaPlNfDdROONCg=.4affdc2a-81da-4bd0-8a3d-3b2aa9d09283@github.com>
 <FrpsSrJPnzecNLiVIcpQ1N_eFqITv05bR9XG8bYzTi4=.398978ab-7bb7-4a50-84ae-6642e401488a@github.com>
 <Y06nt2THUQCaX7imrempGXN8ztnGflBwWc16JH1T3fo=.f4df6b35-88d4-417b-9b2c-87cb4354d793@github.com>
 <vN_wF316lRKdbp2IY4bAc79SNK5gxyC-TsNPGspBs-U=.d9bd9fb9-b21b-4437-9080-368efa26d027@github.com>
Message-ID: <a1ChPGZljvKBAmAqA5QLfKe7UPNls4Zqb5iOcX6ZB00=.7b3ffd6d-3a3b-4d0b-9a69-7c01a74884cc@github.com>

On Wed, 6 Aug 2025 08:53:31 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> @zhengyu123 I don't understand your comment - we already do use `mprotect` on the (committed) stack guard pages. ??
>
> I am confused, too.

Sorry for the confusion. 

Current `create_stack_guard_pages()` implementation calls `os::commit_memory(addr, size, !ExecMem)` to setup the protection. The side-effect of the call introduced the problem I initially reported. What I mean in previous comment is to bypass `os::commit_memory()` call and call `::mprotect` to setup the protection, so that NMT won't record stack guard pages as `committed`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26571#discussion_r2257382029

From dcubed at openjdk.org  Wed Aug  6 17:32:00 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 6 Aug 2025 17:32:00 GMT
Subject: RFR: 8364235: Fix for JDK-8361447 breaks the alignment
 requirements for GuardedMemory [v5]
In-Reply-To: <eJCKuEkAlCZO_9d_WbVzVLak_DwHS0pECnrhC6abF9o=.869327e0-f060-4584-a0a9-78453e305682@github.com>
References: <2NMVt2xW6-rTS7vQPJ8fPkfabrTPiugEqGf4KlttYSo=.46b5d9f5-90b3-44b9-b3db-f139672145dc@github.com>
 <eJCKuEkAlCZO_9d_WbVzVLak_DwHS0pECnrhC6abF9o=.869327e0-f060-4584-a0a9-78453e305682@github.com>
Message-ID: <4UbgIPiKfzRbpkpK_DvM8CezBcXJ5-TfVw6zFW343Oo=.b1000c90-27ab-4756-b690-edc4a22c6510@github.com>

On Sun, 3 Aug 2025 22:54:33 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The fix for [JDK-8361447](https://bugs.openjdk.org/browse/JDK-8361447) added a new field to the `GuardHeader`, not realizing that the size of the `GuardHeader` must be such that the address of the user-data has the strictest necessary alignment (16-byte).
>> 
>> We need to add a padding field to restore the alignment.
>> 
>> A static assert is added to check the alignment.
>> 
>> Testing:
>>  - tiers 1-3 (in progress)
>> 
>> Thanks
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add "padding" to the layout description

Thumbs up.

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

Marked as reviewed by dcubed (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26524#pullrequestreview-3093589948

From ayang at openjdk.org  Wed Aug  6 20:31:14 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 6 Aug 2025 20:31:14 GMT
Subject: RFR: 8263476: Use reserved memory for stack guard pages [v3]
In-Reply-To: <a1ChPGZljvKBAmAqA5QLfKe7UPNls4Zqb5iOcX6ZB00=.7b3ffd6d-3a3b-4d0b-9a69-7c01a74884cc@github.com>
References: <BojYWaP10BJMEWDQYSRiMKR0cOWzMF5At9_3fwD6uUw=.becf6902-01f1-41e0-965d-18a945a6dfcf@github.com>
 <Hv5Bte_jswZl8u2WPO9HrwMaHnWGZVaPlNfDdROONCg=.4affdc2a-81da-4bd0-8a3d-3b2aa9d09283@github.com>
 <FrpsSrJPnzecNLiVIcpQ1N_eFqITv05bR9XG8bYzTi4=.398978ab-7bb7-4a50-84ae-6642e401488a@github.com>
 <Y06nt2THUQCaX7imrempGXN8ztnGflBwWc16JH1T3fo=.f4df6b35-88d4-417b-9b2c-87cb4354d793@github.com>
 <vN_wF316lRKdbp2IY4bAc79SNK5gxyC-TsNPGspBs-U=.d9bd9fb9-b21b-4437-9080-368efa26d027@github.com>
 <a1ChPGZljvKBAmAqA5QLfKe7UPNls4Zqb5iOcX6ZB00=.7b3ffd6d-3a3b-4d0b-9a69-7c01a74884cc@github.com>
Message-ID: <lBhveKtt7FdW2AllRPOfY-saPOipumgiQd1abxetChk=.391d880e-1666-4614-8b5e-5ac4471f4ce3@github.com>

On Wed, 6 Aug 2025 14:30:08 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Current create_stack_guard_pages() implementation calls os::commit_memory(addr, size, !ExecMem) to setup the protection.

Which `create_stack_guard_pages` are you referring to, in `StackOverflow` or `os`?

`StackOverflow::create_stack_guard_pages` invokes `os::create_stack_guard_pages` for some preparation work (optional for some platforms) and `os::guard_memory` for protection setup.

`os::commit_memory` is not directly related to memory protection.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26571#discussion_r2258222637

From ghan at openjdk.org  Thu Aug  7 01:56:41 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Thu, 7 Aug 2025 01:56:41 GMT
Subject: RFR: 8364822: Comment cleanup,
 stale references to closeDescriptors and UNIXProcess.c
Message-ID: <ZXqdazLhVhvXnmmduKJLrpFlg7O9GEKqLIbnsImISZI=.3f776eee-0496-48a6-8d57-56261898ec87@github.com>

Clean up some stale comment references.  Trivial changes.

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

Commit messages:
 - clean up some stale comment references

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

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

From dholmes at openjdk.org  Thu Aug  7 04:36:22 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 7 Aug 2025 04:36:22 GMT
Subject: RFR: 8364235: Fix for JDK-8361447 breaks the alignment
 requirements for GuardedMemory [v5]
In-Reply-To: <eJCKuEkAlCZO_9d_WbVzVLak_DwHS0pECnrhC6abF9o=.869327e0-f060-4584-a0a9-78453e305682@github.com>
References: <2NMVt2xW6-rTS7vQPJ8fPkfabrTPiugEqGf4KlttYSo=.46b5d9f5-90b3-44b9-b3db-f139672145dc@github.com>
 <eJCKuEkAlCZO_9d_WbVzVLak_DwHS0pECnrhC6abF9o=.869327e0-f060-4584-a0a9-78453e305682@github.com>
Message-ID: <TLnVHPai69PjICLrrBNU1QmDi3vQ_6OF6sremGPMc-8=.c9f42429-c887-4821-8dd8-196ae5900b47@github.com>

On Sun, 3 Aug 2025 22:54:33 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The fix for [JDK-8361447](https://bugs.openjdk.org/browse/JDK-8361447) added a new field to the `GuardHeader`, not realizing that the size of the `GuardHeader` must be such that the address of the user-data has the strictest necessary alignment (16-byte).
>> 
>> We need to add a padding field to restore the alignment.
>> 
>> A static assert is added to check the alignment.
>> 
>> Testing:
>>  - tiers 1-3 (in progress)
>> 
>> Thanks
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add "padding" to the layout description

Thanks Dan!

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

PR Comment: https://git.openjdk.org/jdk/pull/26524#issuecomment-3162350970

From dholmes at openjdk.org  Thu Aug  7 04:40:23 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 7 Aug 2025 04:40:23 GMT
Subject: Integrated: 8364235: Fix for JDK-8361447 breaks the alignment
 requirements for GuardedMemory
In-Reply-To: <2NMVt2xW6-rTS7vQPJ8fPkfabrTPiugEqGf4KlttYSo=.46b5d9f5-90b3-44b9-b3db-f139672145dc@github.com>
References: <2NMVt2xW6-rTS7vQPJ8fPkfabrTPiugEqGf4KlttYSo=.46b5d9f5-90b3-44b9-b3db-f139672145dc@github.com>
Message-ID: <Or0SgNXkKNS481FpzuRJmkdo3M5H63lDdDZHDVEjuB4=.3dd781a5-eb2e-4053-8b85-a0a581277748@github.com>

On Tue, 29 Jul 2025 06:32:20 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The fix for [JDK-8361447](https://bugs.openjdk.org/browse/JDK-8361447) added a new field to the `GuardHeader`, not realizing that the size of the `GuardHeader` must be such that the address of the user-data has the strictest necessary alignment (16-byte).
> 
> We need to add a padding field to restore the alignment.
> 
> A static assert is added to check the alignment.
> 
> Testing:
>  - tiers 1-3 (in progress)
> 
> Thanks

This pull request has now been integrated.

Changeset: 078d0d49
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/078d0d4968e26bb7a15417f1c4e891869c69dc6c
Stats:     14 lines in 1 file changed: 8 ins; 2 del; 4 mod

8364235: Fix for JDK-8361447 breaks the alignment requirements for GuardedMemory

Co-authored-by: Johan Sj?len <jsjolen at openjdk.org>
Reviewed-by: dcubed, jsjolen, aboldtch

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

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

From jsjolen at openjdk.org  Thu Aug  7 07:15:15 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 7 Aug 2025 07:15:15 GMT
Subject: RFR: 8352067: Remove the NMT treap and replace its uses with the
 utilities red-black tree [v2]
In-Reply-To: <Sw5KhaC03y3T-bZa54aSCpcXwgLyDeL9h6Mzsnva0BI=.3d877982-e6bf-416a-bcdf-5ba96e5def56@github.com>
References: <xXuaevhTzxS26C6s7DR0BdSQDFPeV5cMg4_qImS_Uw4=.fa5dc831-57b2-409c-8015-ef3dbc143c65@github.com>
 <Sw5KhaC03y3T-bZa54aSCpcXwgLyDeL9h6Mzsnva0BI=.3d877982-e6bf-416a-bcdf-5ba96e5def56@github.com>
Message-ID: <WsCsPrnp4k6dxkuxm-Bb10ZI_83HeLrWvktze3W7EWk=.79a7d257-58d5-4262-bae9-5ed4ba71d2bb@github.com>

On Wed, 6 Aug 2025 11:07:42 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> The utilities red-black tree and the NMT treap serve similar functions. Given the red-black tree's versatility and stricter time complexity, the treap can be removed in favour of it.
>> 
>> I made some modifications to the red-black tree to make it compatible with previous treap usages:
>> - Updated the `visit_in_order` and `visit_range_in_order` functions to require the supplied callback to return a bool, which allows us to stop traversing early.
>> - Improved const-correctness by ensuring that invoking these functions on a const reference provides const pointers to nodes, while non-const references provide mutable pointers. Previously the two functions behaved differently.
>> 
>> Changes to NMT include:
>> - Modified components to align with the updated const-correctness of the red-black tree functions
>> - Renamed structures and variables to remove "treap" from their names to reflect the new tree
>> 
>> The treap was also used in one place in C2. I changed this to use the red-black tree and its cursor interface, which I felt was most fitting for the use case.
>> 
>> Testing:
>> - Oracle tiers 1-3
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback fixes

Still OK

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

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26655#pullrequestreview-3095690422

From duke at openjdk.org  Thu Aug  7 08:32:21 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Thu, 7 Aug 2025 08:32:21 GMT
Subject: RFR: 8364822: Comment cleanup,
 stale references to closeDescriptors and UNIXProcess.c
In-Reply-To: <ZXqdazLhVhvXnmmduKJLrpFlg7O9GEKqLIbnsImISZI=.3f776eee-0496-48a6-8d57-56261898ec87@github.com>
References: <ZXqdazLhVhvXnmmduKJLrpFlg7O9GEKqLIbnsImISZI=.3f776eee-0496-48a6-8d57-56261898ec87@github.com>
Message-ID: <6vo8G2iwEgOTsRpbaXA5ONbxhJ0xmLMD0lL7XxCmVOk=.907a5dd2-ad38-4e5d-8091-0b057e51cfce@github.com>

On Thu, 7 Aug 2025 01:49:41 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

> Clean up some stale comment references.  Trivial changes.

src/hotspot/os/linux/os_linux.cpp line 4876:

> 4874:   // flag set.  If we don't set it, then careless 3rd party native code
> 4875:   // might fork and exec without closing all appropriate file descriptors
> 4876:   // , and this in turn might:

Shouldn't the comma go to the previous line?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26667#discussion_r2259543717

From azafari at openjdk.org  Thu Aug  7 09:20:41 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 7 Aug 2025 09:20:41 GMT
Subject: RFR: 8360048: NMT crash in gtest/NMTGtests.java: fatal error: NMT
 corruption: Block at 0x0000017748307120: header canary broken [v3]
In-Reply-To: <ByslHvuFsvtks0mVSsNgiOzfAyj0MuVKIboQy15xmJE=.a82a592f-bbf2-4fc8-866e-91dcc477717c@github.com>
References: <ByslHvuFsvtks0mVSsNgiOzfAyj0MuVKIboQy15xmJE=.a82a592f-bbf2-4fc8-866e-91dcc477717c@github.com>
Message-ID: <KCHIk95RhYXIPJVG7HdcFoBNavIvPfJuUL5OOXqgk0w=.78a512fd-c32d-4460-9d0f-fc65b82e9fe9@github.com>

> The canary header test failed since there were concurrent `remove` and `free()` from the tree. The `remove` operations are synch'ed with corresponding NMT lock. The `ReserveMemory::reserve()` uses the same lock internally and is not included in the locked code block.
> 
> Tests: tier5 {macosx-aarch64, linux-x64, windows-x64} x {debug, release}

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

 - Merge remote-tracking branch 'origin/master' into _8360048_corrupted_canary_header
 - local VMT vs static one.
 - 8360048: NMT crash in gtest/NMTGtests.java: fatal error: NMT corruption: Block at 0x0000017748307120: header canary broken

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

Changes: https://git.openjdk.org/jdk/pull/25950/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25950&range=02
  Stats: 129 lines in 5 files changed: 26 ins; 25 del; 78 mod
  Patch: https://git.openjdk.org/jdk/pull/25950.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25950/head:pull/25950

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

From fbredberg at openjdk.org  Thu Aug  7 09:23:37 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 7 Aug 2025 09:23:37 GMT
Subject: RFR: 8364141: Remove LockingMode related code from x86 [v4]
In-Reply-To: <g7WNqmFlJOkai-zeEjD09M5TwpL3fAMkZUAy37b747U=.faa6d9f5-1894-4507-a0f1-1dd41f3bdd43@github.com>
References: <g7WNqmFlJOkai-zeEjD09M5TwpL3fAMkZUAy37b747U=.faa6d9f5-1894-4507-a0f1-1dd41f3bdd43@github.com>
Message-ID: <wQPBsXlKAZtaZlcTLSgISHvII9vOIewNNoNW5cjBTW4=.9c3ffca2-7656-40ae-b6f5-5f7a9fc6151c@github.com>

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
> 
> This PR removes `LockingMode` related code from the **x86** platform.
> 
> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.
> 
> Passes tier1-tier5 with no added problems.

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

  Update three after review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26552/files
  - new: https://git.openjdk.org/jdk/pull/26552/files/9fa0c947..6c8b78b8

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

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

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

From fbredberg at openjdk.org  Thu Aug  7 09:23:37 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 7 Aug 2025 09:23:37 GMT
Subject: RFR: 8364141: Remove LockingMode related code from x86 [v3]
In-Reply-To: <zx8GahcduAOfkFquUTI9B1xcP-j9m1MzrARtBe7oEus=.4f78f2b8-a4b6-4e03-bd68-853c6db46124@github.com>
References: <g7WNqmFlJOkai-zeEjD09M5TwpL3fAMkZUAy37b747U=.faa6d9f5-1894-4507-a0f1-1dd41f3bdd43@github.com>
 <-ncfIHskHiKnUbJ3nRR8rp678hInGalmZW4CnS5QJp0=.baabffb7-5f4f-4f06-9b23-315f8e9372a7@github.com>
 <zx8GahcduAOfkFquUTI9B1xcP-j9m1MzrARtBe7oEus=.4f78f2b8-a4b6-4e03-bd68-853c6db46124@github.com>
Message-ID: <gMZD5OCdMtwRfl48RPIuLqSVarfGvONh6YbA8odoumI=.af178c65-0973-4ee4-8368-70cc86a095bd@github.com>

On Wed, 6 Aug 2025 05:43:13 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update two after review
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 409:
> 
>> 407: //
>> 408: // The only other source of unbalanced locking would be JNI.  The "Java Native Interface
>> 409: // Specification" states that an object locked by JNI's_MonitorEnter should not be
> 
> Suggestion:
> 
> // Specification" states that an object locked by JNI's MonitorEnter should not be
> 
> Sorry missed the misplaced underscore due to the red-wavy-line spelling error

Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26552#discussion_r2259672572

From duke at openjdk.org  Thu Aug  7 09:49:12 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 7 Aug 2025 09:49:12 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v4]
In-Reply-To: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
Message-ID: <SQ8LQ9lyCClcWIdoXPpcU9PDASmtEatIx3HGBj7kmdA=.306a44c4-4d49-4984-88d4-daf6e8c2a232@github.com>

> Hi all,
> 
> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110).
> 
> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports:
> 
> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup()
> 
> CPUTimeUsage::GC::gc_threads()
> CPUTimeUsage::GC::vm_thread()
> CPUTimeUsage::GC::stringdedup()
> 
> CPUTimeUsage::Runtime::vm_thread()
> 
> 
> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC.
> 
> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table:
> 
> 
> [12.517s][info][cpu] === CPU time Statistics =============================================================
> [12.517s][info][cpu]                                                                             CPUs
> [12.517s][info][cpu]                                                                s       %  utilized
> [12.517s][info][cpu]    Process
> [12.517s][info][cpu]      Total                                              175.7628  100.00      14.0
> [12.517s][info][cpu]      VM Thread                                            7.0000    3.98       0.6
> [12.517s][info][cpu]      Garbage Collection                                  72.0000   40.96       5.8
> [12.517s][info][cpu]        GC Threads                                        70.0000   39.83       5.6
> [12.517s][info][cpu]        VM Thread                                          1.0000    0.57       0.1
> [12.518s][info][cpu]        String Deduplication                               0.0000    0.00       0.0
> [12.518s][info][cpu] =====================================================================================
> 
> 
> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path.

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

  Improve robustness

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26621/files
  - new: https://git.openjdk.org/jdk/pull/26621/files/216ba811..3f552362

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

  Stats: 29 lines in 3 files changed: 23 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/26621.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26621/head:pull/26621

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

From ghan at openjdk.org  Thu Aug  7 10:19:14 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Thu, 7 Aug 2025 10:19:14 GMT
Subject: RFR: 8364822: Comment cleanup,
 stale references to closeDescriptors and UNIXProcess.c
In-Reply-To: <6vo8G2iwEgOTsRpbaXA5ONbxhJ0xmLMD0lL7XxCmVOk=.907a5dd2-ad38-4e5d-8091-0b057e51cfce@github.com>
References: <ZXqdazLhVhvXnmmduKJLrpFlg7O9GEKqLIbnsImISZI=.3f776eee-0496-48a6-8d57-56261898ec87@github.com>
 <6vo8G2iwEgOTsRpbaXA5ONbxhJ0xmLMD0lL7XxCmVOk=.907a5dd2-ad38-4e5d-8091-0b057e51cfce@github.com>
Message-ID: <pVQ1LLaQXXVeAfFO-UyNENLU6tEUNjA38KaMmTHCfU8=.da47963b-d250-49f9-802a-880aab3b0f83@github.com>

On Thu, 7 Aug 2025 08:29:12 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> Clean up some stale comment references.  Trivial changes.
>
> src/hotspot/os/linux/os_linux.cpp line 4876:
> 
>> 4874:   // flag set.  If we don't set it, then careless 3rd party native code
>> 4875:   // might fork and exec without closing all appropriate file descriptors
>> 4876:   // , and this in turn might:
> 
> Shouldn't the comma go to the previous line?

@fandreuz Thanks  for your comment! 

You're right to point this out ? I am not sure about the best placement either. I noticed that some other parts of the codebase use the same style (with the comma at the beginning of the line), so I followed that pattern here.

That said, I'm happy to adjust it if needed. Let's leave it to @kevinjwalls  to make the final call.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26667#discussion_r2259827846

From kevinw at openjdk.org  Thu Aug  7 10:28:15 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 7 Aug 2025 10:28:15 GMT
Subject: RFR: 8364822: Comment cleanup,
 stale references to closeDescriptors and UNIXProcess.c
In-Reply-To: <pVQ1LLaQXXVeAfFO-UyNENLU6tEUNjA38KaMmTHCfU8=.da47963b-d250-49f9-802a-880aab3b0f83@github.com>
References: <ZXqdazLhVhvXnmmduKJLrpFlg7O9GEKqLIbnsImISZI=.3f776eee-0496-48a6-8d57-56261898ec87@github.com>
 <6vo8G2iwEgOTsRpbaXA5ONbxhJ0xmLMD0lL7XxCmVOk=.907a5dd2-ad38-4e5d-8091-0b057e51cfce@github.com>
 <pVQ1LLaQXXVeAfFO-UyNENLU6tEUNjA38KaMmTHCfU8=.da47963b-d250-49f9-802a-880aab3b0f83@github.com>
Message-ID: <w5Kuj-8piriXRgJZC8iuMVy8xY1Yl5hhaSL32MbbzTU=.337d36a8-8d32-47a4-afcf-058ac75191aa@github.com>

On Thu, 7 Aug 2025 10:17:05 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

>> src/hotspot/os/linux/os_linux.cpp line 4876:
>> 
>>> 4874:   // flag set.  If we don't set it, then careless 3rd party native code
>>> 4875:   // might fork and exec without closing all appropriate file descriptors
>>> 4876:   // , and this in turn might:
>> 
>> Shouldn't the comma go to the previous line?
>
> @fandreuz Thanks  for your comment! 
> 
> You're right to point this out ? I am not sure about the best placement either. I noticed that some other parts of the codebase use the same style (with the comma at the beginning of the line), so I followed that pattern here.
> 
> That said, I'm happy to adjust it if needed. Let's leave it to @kevinjwalls  to make the final call.

Hi, it's a good review comment, beginning a line with a comma is not normal, we should keep the comma on the previous line.

I see some javadoc that does this, but in the examples I found, there are slightly complex constructs on the previous line, so you can more easily see it's correct if comma is split, like:


 751      * {@code (CT1 ct1, ..., CTn ctn)}
 752      * , statically represented using varargs.


But javadoc is also reformatted for humans, so the comma will not be split in the version people read. 8-)
Here we should stay with the English style, and not separate the comma, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26667#discussion_r2259852367

From ghan at openjdk.org  Thu Aug  7 11:24:30 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Thu, 7 Aug 2025 11:24:30 GMT
Subject: RFR: 8364822: Comment cleanup,
 stale references to closeDescriptors and UNIXProcess.c [v2]
In-Reply-To: <ZXqdazLhVhvXnmmduKJLrpFlg7O9GEKqLIbnsImISZI=.3f776eee-0496-48a6-8d57-56261898ec87@github.com>
References: <ZXqdazLhVhvXnmmduKJLrpFlg7O9GEKqLIbnsImISZI=.3f776eee-0496-48a6-8d57-56261898ec87@github.com>
Message-ID: <NT1iPfuWmGlFHQJSZeOInTLnWk-5dmRU08GSBVwiN-w=.38e01a76-48bf-441b-8ba2-e0ab379f87d2@github.com>

> Clean up some stale comment references.  Trivial changes.

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

  Update os_linux.cpp
  
  a small fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26667/files
  - new: https://git.openjdk.org/jdk/pull/26667/files/0c7ef910..3b55134c

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

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

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

From ghan at openjdk.org  Thu Aug  7 11:27:13 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Thu, 7 Aug 2025 11:27:13 GMT
Subject: RFR: 8364822: Comment cleanup,
 stale references to closeDescriptors and UNIXProcess.c [v2]
In-Reply-To: <w5Kuj-8piriXRgJZC8iuMVy8xY1Yl5hhaSL32MbbzTU=.337d36a8-8d32-47a4-afcf-058ac75191aa@github.com>
References: <ZXqdazLhVhvXnmmduKJLrpFlg7O9GEKqLIbnsImISZI=.3f776eee-0496-48a6-8d57-56261898ec87@github.com>
 <6vo8G2iwEgOTsRpbaXA5ONbxhJ0xmLMD0lL7XxCmVOk=.907a5dd2-ad38-4e5d-8091-0b057e51cfce@github.com>
 <pVQ1LLaQXXVeAfFO-UyNENLU6tEUNjA38KaMmTHCfU8=.da47963b-d250-49f9-802a-880aab3b0f83@github.com>
 <w5Kuj-8piriXRgJZC8iuMVy8xY1Yl5hhaSL32MbbzTU=.337d36a8-8d32-47a4-afcf-058ac75191aa@github.com>
Message-ID: <u-nilYA8cEtqil1ccaRQHxnSpRh2635Y0EbWK_2zq_Y=.40080bc2-509c-404d-a3b4-b20f478503e8@github.com>

On Thu, 7 Aug 2025 10:25:22 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> @fandreuz Thanks  for your comment! 
>> 
>> You're right to point this out ? I am not sure about the best placement either. I noticed that some other parts of the codebase use the same style (with the comma at the beginning of the line), so I followed that pattern here.
>> 
>> That said, I'm happy to adjust it if needed. Let's leave it to @kevinjwalls  to make the final call.
>
> Hi, it's a good review comment, beginning a line with a comma is not normal, we should keep the comma on the previous line.
> 
> I see some javadoc that does this, but in the examples I found, there are slightly complex constructs on the previous line, so you can more easily see it's correct if comma is split, like:
> 
> 
>  751      * {@code (CT1 ct1, ..., CTn ctn)}
>  752      * , statically represented using varargs.
> 
> 
> But javadoc is also reformatted for humans, so the comma will not be split in the version people read. 8-)
> Here we should stay with the English style, and not separate the comma, thanks!

hi @kevinjwalls , thanks a lot for the detailed explanation ? that makes sense! I've updated the comment accordingly. Please take another look when you have time.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26667#discussion_r2259983441

From dholmes at openjdk.org  Thu Aug  7 12:16:16 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 7 Aug 2025 12:16:16 GMT
Subject: RFR: 8364141: Remove LockingMode related code from x86 [v4]
In-Reply-To: <wQPBsXlKAZtaZlcTLSgISHvII9vOIewNNoNW5cjBTW4=.9c3ffca2-7656-40ae-b6f5-5f7a9fc6151c@github.com>
References: <g7WNqmFlJOkai-zeEjD09M5TwpL3fAMkZUAy37b747U=.faa6d9f5-1894-4507-a0f1-1dd41f3bdd43@github.com>
 <wQPBsXlKAZtaZlcTLSgISHvII9vOIewNNoNW5cjBTW4=.9c3ffca2-7656-40ae-b6f5-5f7a9fc6151c@github.com>
Message-ID: <qtBCAePJ87godYEcKzH5WKaAxhE3tq2USDayzUcmJq4=.08aa9484-4127-43f7-a382-01b8119f784e@github.com>

On Thu, 7 Aug 2025 09:23:37 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
>> 
>> This PR removes `LockingMode` related code from the **x86** platform.
>> 
>> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.
>> 
>> Passes tier1-tier5 with no added problems.
>
> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update three after review

Marked as reviewed by dholmes (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26552#pullrequestreview-3096874113

From kevinw at openjdk.org  Thu Aug  7 13:52:16 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 7 Aug 2025 13:52:16 GMT
Subject: RFR: 8364822: Comment cleanup,
 stale references to closeDescriptors and UNIXProcess.c [v2]
In-Reply-To: <NT1iPfuWmGlFHQJSZeOInTLnWk-5dmRU08GSBVwiN-w=.38e01a76-48bf-441b-8ba2-e0ab379f87d2@github.com>
References: <ZXqdazLhVhvXnmmduKJLrpFlg7O9GEKqLIbnsImISZI=.3f776eee-0496-48a6-8d57-56261898ec87@github.com>
 <NT1iPfuWmGlFHQJSZeOInTLnWk-5dmRU08GSBVwiN-w=.38e01a76-48bf-441b-8ba2-e0ab379f87d2@github.com>
Message-ID: <cZbCfNhsG5eOVaoaUngsUN2bUPlAyE_CRa8N4lJ0EnI=.cf436e3f-5c64-4d6d-a4f8-e30b45f40815@github.com>

On Thu, 7 Aug 2025 11:24:30 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

>> Clean up some stale comment references.  Trivial changes.
>
> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update os_linux.cpp
>   
>   a small fix

Yes, looks good.

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26667#pullrequestreview-3097255422

From duke at openjdk.org  Thu Aug  7 14:05:20 2025
From: duke at openjdk.org (duke)
Date: Thu, 7 Aug 2025 14:05:20 GMT
Subject: RFR: 8364822: Comment cleanup,
 stale references to closeDescriptors and UNIXProcess.c [v2]
In-Reply-To: <NT1iPfuWmGlFHQJSZeOInTLnWk-5dmRU08GSBVwiN-w=.38e01a76-48bf-441b-8ba2-e0ab379f87d2@github.com>
References: <ZXqdazLhVhvXnmmduKJLrpFlg7O9GEKqLIbnsImISZI=.3f776eee-0496-48a6-8d57-56261898ec87@github.com>
 <NT1iPfuWmGlFHQJSZeOInTLnWk-5dmRU08GSBVwiN-w=.38e01a76-48bf-441b-8ba2-e0ab379f87d2@github.com>
Message-ID: <zpWUBVMYi7oMxMHO4XiioEY8_1lJPOTS3_ki1OsMp_k=.6a2fef50-5f57-4041-ba67-84ec54dc284c@github.com>

On Thu, 7 Aug 2025 11:24:30 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

>> Clean up some stale comment references.  Trivial changes.
>
> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update os_linux.cpp
>   
>   a small fix

@hgqxjj 
Your change (at version 3b55134c3b015f88e486e8cc40b06a2537c95095) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/26667#issuecomment-3164338669

From ghan at openjdk.org  Thu Aug  7 14:09:17 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Thu, 7 Aug 2025 14:09:17 GMT
Subject: RFR: 8364822: Comment cleanup,
 stale references to closeDescriptors and UNIXProcess.c [v2]
In-Reply-To: <cZbCfNhsG5eOVaoaUngsUN2bUPlAyE_CRa8N4lJ0EnI=.cf436e3f-5c64-4d6d-a4f8-e30b45f40815@github.com>
References: <ZXqdazLhVhvXnmmduKJLrpFlg7O9GEKqLIbnsImISZI=.3f776eee-0496-48a6-8d57-56261898ec87@github.com>
 <NT1iPfuWmGlFHQJSZeOInTLnWk-5dmRU08GSBVwiN-w=.38e01a76-48bf-441b-8ba2-e0ab379f87d2@github.com>
 <cZbCfNhsG5eOVaoaUngsUN2bUPlAyE_CRa8N4lJ0EnI=.cf436e3f-5c64-4d6d-a4f8-e30b45f40815@github.com>
Message-ID: <FJ1Re04HWNzKGBEZu2S7EVfSNUnAMnEodIia_m28aH8=.6b725c35-7335-4902-9164-6aeae70bc4fe@github.com>

On Thu, 7 Aug 2025 13:49:56 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update os_linux.cpp
>>   
>>   a small fix
>
> Yes, looks good.

hi @kevinjwalls ,thank you for your review and approval.

I've run /integrate , please sponsor this change when you have time.

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

PR Comment: https://git.openjdk.org/jdk/pull/26667#issuecomment-3164350283

From rriggs at openjdk.org  Thu Aug  7 14:09:16 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 7 Aug 2025 14:09:16 GMT
Subject: RFR: 8364822: Comment cleanup,
 stale references to closeDescriptors and UNIXProcess.c [v2]
In-Reply-To: <NT1iPfuWmGlFHQJSZeOInTLnWk-5dmRU08GSBVwiN-w=.38e01a76-48bf-441b-8ba2-e0ab379f87d2@github.com>
References: <ZXqdazLhVhvXnmmduKJLrpFlg7O9GEKqLIbnsImISZI=.3f776eee-0496-48a6-8d57-56261898ec87@github.com>
 <NT1iPfuWmGlFHQJSZeOInTLnWk-5dmRU08GSBVwiN-w=.38e01a76-48bf-441b-8ba2-e0ab379f87d2@github.com>
Message-ID: <tdc7Jw7KTyE8lwfKkUSZFte-_w9jZ_0W7YtlNC948X0=.e3aeccd0-6d0a-4ecd-8009-604394d7e612@github.com>

On Thu, 7 Aug 2025 11:24:30 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

>> Clean up some stale comment references.  Trivial changes.
>
> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update os_linux.cpp
>   
>   a small fix

Looks good, thanks

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26667#pullrequestreview-3097333323

From kevinw at openjdk.org  Thu Aug  7 14:14:21 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 7 Aug 2025 14:14:21 GMT
Subject: RFR: 8364822: Comment cleanup,
 stale references to closeDescriptors and UNIXProcess.c [v2]
In-Reply-To: <NT1iPfuWmGlFHQJSZeOInTLnWk-5dmRU08GSBVwiN-w=.38e01a76-48bf-441b-8ba2-e0ab379f87d2@github.com>
References: <ZXqdazLhVhvXnmmduKJLrpFlg7O9GEKqLIbnsImISZI=.3f776eee-0496-48a6-8d57-56261898ec87@github.com>
 <NT1iPfuWmGlFHQJSZeOInTLnWk-5dmRU08GSBVwiN-w=.38e01a76-48bf-441b-8ba2-e0ab379f87d2@github.com>
Message-ID: <KtZ3o_DoS7RaswxmYAnvFI1bX1qvJAGpf5jgYzfbK5A=.16060ebf-a892-470a-8097-ea633d1925fa@github.com>

On Thu, 7 Aug 2025 11:24:30 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

>> Clean up some stale comment references.  Trivial changes.
>
> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update os_linux.cpp
>   
>   a small fix

Thanks, great to have the second review.

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

PR Comment: https://git.openjdk.org/jdk/pull/26667#issuecomment-3164366872

From ghan at openjdk.org  Thu Aug  7 14:14:22 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Thu, 7 Aug 2025 14:14:22 GMT
Subject: Integrated: 8364822: Comment cleanup,
 stale references to closeDescriptors and UNIXProcess.c
In-Reply-To: <ZXqdazLhVhvXnmmduKJLrpFlg7O9GEKqLIbnsImISZI=.3f776eee-0496-48a6-8d57-56261898ec87@github.com>
References: <ZXqdazLhVhvXnmmduKJLrpFlg7O9GEKqLIbnsImISZI=.3f776eee-0496-48a6-8d57-56261898ec87@github.com>
Message-ID: <sH5mj7S9U3rozNthAmnjGyjnc6vJvr_Rm5xMvzQPI-4=.46112ac2-70c0-4775-bdf0-a96bda5b494f@github.com>

On Thu, 7 Aug 2025 01:49:41 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

> Clean up some stale comment references.  Trivial changes.

This pull request has now been integrated.

Changeset: 83953c45
Author:    Guanqiang Han <ghan at openjdk.org>
Committer: Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/83953c458eb65b2af184340dd460325f2b56e5b9
Stats:     8 lines in 4 files changed: 0 ins; 3 del; 5 mod

8364822: Comment cleanup, stale references to closeDescriptors and UNIXProcess.c

Reviewed-by: kevinw, rriggs

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

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

From fjiang at openjdk.org  Thu Aug  7 15:20:15 2025
From: fjiang at openjdk.org (Feilong Jiang)
Date: Thu, 7 Aug 2025 15:20:15 GMT
Subject: RFR: 8364570: Remove LockingMode related code from riscv64
In-Reply-To: <TGtRFC9NpLCnaqcLtmFttGpJIHOWxXdUB4PZHfhSHoA=.0fb2f13f-f42b-4804-804e-9b24422a08c9@github.com>
References: <TGtRFC9NpLCnaqcLtmFttGpJIHOWxXdUB4PZHfhSHoA=.0fb2f13f-f42b-4804-804e-9b24422a08c9@github.com>
Message-ID: <x-vJJSZNc-43v3w3jxFD_WpyX6Tghv9khowquZtLO88=.d44f2a96-a96a-4232-aa5a-cde0dd13d812@github.com>

On Wed, 6 Aug 2025 11:24:22 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
> 
> This PR removes `LockingMode` related code from the **riscv64** platform.
> 
> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.

Looks good, with one minor comment.

src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp line 1821:

> 1819:     __ ld(obj_reg, Address(oop_handle_reg, 0));
> 1820: 
> 1821:     Label done, not_recursive;

label `done` is not used either. We can just remove it.

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

PR Review: https://git.openjdk.org/jdk/pull/26658#pullrequestreview-3097623099
PR Review Comment: https://git.openjdk.org/jdk/pull/26658#discussion_r2260643213

From jsikstro at openjdk.org  Thu Aug  7 16:43:50 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 7 Aug 2025 16:43:50 GMT
Subject: RFR: 8365050: Too verbose warning in os::commit_memory_limit() on
 Windows
Message-ID: <NSCsDz-eKA3QkSkBm64DFk325ciWfIQR7Qdgl-ZYsWA=.063ce7e2-7694-48d8-a918-91cd7363af54@github.com>

Hello,

This is a follow-up to [JDK-8364518](https://bugs.openjdk.org/browse/JDK-8364518), which introduced support for Job Objects in os::commit_memory_limit() on Windows. The single `warning(...)` turned out to be too verbose, as getting an error from `QueryInformationJobObject` is common when the process is not in a job and does not have permission to query information about a job. The verbosity results both in a lot of warning prints when building, and some tests to fail, which expects the output to contain something specific or nothing at all. See more details in the JBS issue.

To address this, I suggest we revise os::commit_memory_limit() to first check if the process is in a job before calling `QueryInformationJobObject`. When testing this locally, I can see that the verbose warnings when building are gone and the tests pass.

I'll run this through internal Oracle testing as well.

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

Commit messages:
 - 8365050: Too verbose warning in os::commit_memory_limit() on Windows

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

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

From duke at openjdk.org  Fri Aug  8 00:13:15 2025
From: duke at openjdk.org (duke)
Date: Fri, 8 Aug 2025 00:13:15 GMT
Subject: Withdrawn: 8356228: NMT does not record reserved memory base address
 correctly
In-Reply-To: <9cxOcodCQ6C9C3aco0ciPnjWrArvGpk-RlKkcTOD33o=.7f81a4e5-a7ef-48f7-bb50-7553a6e8b8c7@github.com>
References: <9cxOcodCQ6C9C3aco0ciPnjWrArvGpk-RlKkcTOD33o=.7f81a4e5-a7ef-48f7-bb50-7553a6e8b8c7@github.com>
Message-ID: <jGS6j14vFMwuF2aW37pKm9031pRyu-DRk-HxgLFYQxY=.98e93dd0-9c3b-4958-9537-f78f663a6344@github.com>

On Tue, 10 Jun 2025 11:23:14 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> The problem here stems from the following facts:
> 1) When requesting an aligned virtual memory, the size may be extended to meet the alignment requirements. The extra size from the two ends are released afterward. 
> 2) NMT ignores tracking of releasing CDS regions that are contained in larger regions, because they should be in a specific order.
> 3) In linux-aarch64 environment, the alignment size is 64K, reserve operations may fall into cases as 1) above.
> 
> So, if ArchiveBuffer memory is reserved with CDS tag, there might be some released regions that NMT ignored and then later complains their intersection with other regions (e.g., thread stack regions observed in the issue).
> 
> Solution is to reserve the memory with no tag (mtNone) and if it succeeds change the tag of the region to CDS for further trackings.
> 
> Tests:
> linux-x64: runtime/NMT jtreg tests passed
> linux-aarch64: tier1 to tier3 passed

This pull request has been closed without being integrated.

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

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

From ghan at openjdk.org  Fri Aug  8 01:10:27 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Fri, 8 Aug 2025 01:10:27 GMT
Subject: RFR: 8364822: Comment cleanup,
 stale references to closeDescriptors and UNIXProcess.c [v2]
In-Reply-To: <tdc7Jw7KTyE8lwfKkUSZFte-_w9jZ_0W7YtlNC948X0=.e3aeccd0-6d0a-4ecd-8009-604394d7e612@github.com>
References: <ZXqdazLhVhvXnmmduKJLrpFlg7O9GEKqLIbnsImISZI=.3f776eee-0496-48a6-8d57-56261898ec87@github.com>
 <NT1iPfuWmGlFHQJSZeOInTLnWk-5dmRU08GSBVwiN-w=.38e01a76-48bf-441b-8ba2-e0ab379f87d2@github.com>
 <tdc7Jw7KTyE8lwfKkUSZFte-_w9jZ_0W7YtlNC948X0=.e3aeccd0-6d0a-4ecd-8009-604394d7e612@github.com>
Message-ID: <YhEvAcC6nsSch04Gdaa5R1AS0ewHPcJOPGdtI3jCGTk=.a91bbd36-1a03-4997-8de2-4aabae1850f2@github.com>

On Thu, 7 Aug 2025 14:06:53 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update os_linux.cpp
>>   
>>   a small fix
>
> Looks good, thanks

hi @RogerRiggs, thank you for your review and approval.

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

PR Comment: https://git.openjdk.org/jdk/pull/26667#issuecomment-3166268830

From dholmes at openjdk.org  Fri Aug  8 02:44:10 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 8 Aug 2025 02:44:10 GMT
Subject: RFR: 8365050: Too verbose warning in os::commit_memory_limit() on
 Windows
In-Reply-To: <NSCsDz-eKA3QkSkBm64DFk325ciWfIQR7Qdgl-ZYsWA=.063ce7e2-7694-48d8-a918-91cd7363af54@github.com>
References: <NSCsDz-eKA3QkSkBm64DFk325ciWfIQR7Qdgl-ZYsWA=.063ce7e2-7694-48d8-a918-91cd7363af54@github.com>
Message-ID: <P4HUkMmO_zE7zGORnOM9b_YM-Z_mNVj6yxRyH2je-Bo=.e84192ee-9cdf-4fa9-8f99-316e75ed3c91@github.com>

On Thu, 7 Aug 2025 16:38:21 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> This is a follow-up to [JDK-8364518](https://bugs.openjdk.org/browse/JDK-8364518), which introduced support for Job Objects in os::commit_memory_limit() on Windows. The single `warning(...)` turned out to be too verbose, as getting an error from `QueryInformationJobObject` is common when the process is not in a job and does not have permission to query information about a job. The verbosity results both in a lot of warning prints when building, and some tests to fail, which expects the output to contain something specific or nothing at all. See more details in the JBS issue.
> 
> To address this, I suggest we revise os::commit_memory_limit() to first check if the process is in a job before calling `QueryInformationJobObject`. When testing this locally, I can see that the verbose warnings when building are gone and the tests pass.
> 
> I'll run this through internal Oracle testing as well.

Looks okay.

Sorry I should have realized we needed the same checks as for the CPU query.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26680#pullrequestreview-3099299754

From mbaesken at openjdk.org  Fri Aug  8 07:20:19 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 8 Aug 2025 07:20:19 GMT
Subject: RFR: 8365050: Too verbose warning in os::commit_memory_limit() on
 Windows
In-Reply-To: <NSCsDz-eKA3QkSkBm64DFk325ciWfIQR7Qdgl-ZYsWA=.063ce7e2-7694-48d8-a918-91cd7363af54@github.com>
References: <NSCsDz-eKA3QkSkBm64DFk325ciWfIQR7Qdgl-ZYsWA=.063ce7e2-7694-48d8-a918-91cd7363af54@github.com>
Message-ID: <iQwVoIGBd09nB0YEsuuKaa_MU_RuGMS247JDudz0kYY=.7eed64d0-0e82-421b-aa6f-be0788bf36b0@github.com>

On Thu, 7 Aug 2025 16:38:21 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> This is a follow-up to [JDK-8364518](https://bugs.openjdk.org/browse/JDK-8364518), which introduced support for Job Objects in os::commit_memory_limit() on Windows. The single `warning(...)` turned out to be too verbose, as getting an error from `QueryInformationJobObject` is common when the process is not in a job and does not have permission to query information about a job. The verbosity results both in a lot of warning prints when building, and some tests to fail, which expects the output to contain something specific or nothing at all. See more details in the JBS issue.
> 
> To address this, I suggest we revise os::commit_memory_limit() to first check if the process is in a job before calling `QueryInformationJobObject`. When testing this locally, I can see that the verbose warnings when building are gone and the tests pass.
> 
> Testing:
> * Oracle's tier1-4
> * Reported test failures now pass

I'll run your PR  through our Windows testing , will take a bit because it is not the fastest test-env.

You might consider factoring out the  IsProcessInJob  related checking from your code and  active_processors_in_job_object, maybe a little helper would make sense; but up to you just an idea.

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

PR Comment: https://git.openjdk.org/jdk/pull/26680#issuecomment-3166823511
PR Comment: https://git.openjdk.org/jdk/pull/26680#issuecomment-3166826223

From azafari at openjdk.org  Fri Aug  8 08:45:14 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 8 Aug 2025 08:45:14 GMT
Subject: RFR: 8360048: NMT crash in gtest/NMTGtests.java: fatal error: NMT
 corruption: Block at 0x0000017748307120: header canary broken [v2]
In-Reply-To: <CmZrpR9YtH7bw6rtfhuNQY7-cK2-Ih966n19z5AVfaI=.658eeecc-e65b-4701-bce8-e9870574302b@github.com>
References: <ByslHvuFsvtks0mVSsNgiOzfAyj0MuVKIboQy15xmJE=.a82a592f-bbf2-4fc8-866e-91dcc477717c@github.com>
 <mkeyNm6ooSR46efjdLv4beXhSZLJQZKMBrCvXfSQtCU=.218b9e5f-76ad-4301-b004-cbc69b2b83f0@github.com>
 <CmZrpR9YtH7bw6rtfhuNQY7-cK2-Ih966n19z5AVfaI=.658eeecc-e65b-4701-bce8-e9870574302b@github.com>
Message-ID: <bJQxbdgkhnmVg04la8CNXkQnp2v8Fka6DUO5viA_k00=.bf4a7399-bade-4123-8190-ac5a26799d75@github.com>

On Thu, 26 Jun 2025 08:02:13 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   local VMT vs static one.
>
> Nice!

Thanks for your reviews @jdksjolen and @gerard-ziemski.

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

PR Comment: https://git.openjdk.org/jdk/pull/25950#issuecomment-3167043852

From jsjolen at openjdk.org  Fri Aug  8 08:58:16 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 8 Aug 2025 08:58:16 GMT
Subject: RFR: 8360048: NMT crash in gtest/NMTGtests.java: fatal error: NMT
 corruption: Block at 0x0000017748307120: header canary broken [v3]
In-Reply-To: <KCHIk95RhYXIPJVG7HdcFoBNavIvPfJuUL5OOXqgk0w=.78a512fd-c32d-4460-9d0f-fc65b82e9fe9@github.com>
References: <ByslHvuFsvtks0mVSsNgiOzfAyj0MuVKIboQy15xmJE=.a82a592f-bbf2-4fc8-866e-91dcc477717c@github.com>
 <KCHIk95RhYXIPJVG7HdcFoBNavIvPfJuUL5OOXqgk0w=.78a512fd-c32d-4460-9d0f-fc65b82e9fe9@github.com>
Message-ID: <ODkRMdB8d-4pYLc7nYx-HelZzOkA7trwRNUbVHjgOFc=.7a0da37a-122e-4892-ad48-f22edfed0ba8@github.com>

On Thu, 7 Aug 2025 09:20:41 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> The canary header test failed since there were concurrent `remove` and `free()` from the tree. The `remove` operations are synch'ed with corresponding NMT lock. The `ReserveMemory::reserve()` uses the same lock internally and is not included in the locked code block.
>> 
>> Tests: tier5 {macosx-aarch64, linux-x64, windows-x64} x {debug, release}
>
> Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge remote-tracking branch 'origin/master' into _8360048_corrupted_canary_header
>  - local VMT vs static one.
>  - 8360048: NMT crash in gtest/NMTGtests.java: fatal error: NMT corruption: Block at 0x0000017748307120: header canary broken

Re-approved

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

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25950#pullrequestreview-3099997883

From azafari at openjdk.org  Fri Aug  8 08:58:23 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 8 Aug 2025 08:58:23 GMT
Subject: RFR: 8364280:
 NMTCommittedVirtualMemoryTracker.test_committed_virtualmemory_region_vm fails
 with assertion "negative distance"
Message-ID: <ncwJP21-QPQNcKJoK3TF-H9quyeAZvIQ1Dh4diBQiP0=.6f7e47d8-1cfd-4ef0-a307-1828d27c444f@github.com>

The VirtualMemoryTracker API uses a tree internally for tracking the memory regions and their states/info. This tree should not be changed when looking for some regions. If not synch'ed, the nodes in the tree may change meanwhile and the retrieved info are not as expected. The unit test in this PR did not synch these looking up with VMT. The corresponding lock is used to address the problem.

Tests:
local: linux-x64-debug NMTGtests
mach5: tiers 1-5, {macosx-aarch64, linux-x64, windows-x64} x {debug, release}

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

Commit messages:
 - 8364280: NMTCommittedVirtualMemoryTracker.test_committed_virtualmemory_region_vm fails with assertion "negative distance"

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

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

From azafari at openjdk.org  Fri Aug  8 09:09:22 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 8 Aug 2025 09:09:22 GMT
Subject: RFR: 8360048: NMT crash in gtest/NMTGtests.java: fatal error: NMT
 corruption: Block at 0x0000017748307120: header canary broken [v3]
In-Reply-To: <ODkRMdB8d-4pYLc7nYx-HelZzOkA7trwRNUbVHjgOFc=.7a0da37a-122e-4892-ad48-f22edfed0ba8@github.com>
References: <ByslHvuFsvtks0mVSsNgiOzfAyj0MuVKIboQy15xmJE=.a82a592f-bbf2-4fc8-866e-91dcc477717c@github.com>
 <KCHIk95RhYXIPJVG7HdcFoBNavIvPfJuUL5OOXqgk0w=.78a512fd-c32d-4460-9d0f-fc65b82e9fe9@github.com>
 <ODkRMdB8d-4pYLc7nYx-HelZzOkA7trwRNUbVHjgOFc=.7a0da37a-122e-4892-ad48-f22edfed0ba8@github.com>
Message-ID: <v5L11_EjsoewAbzkOwVAF9jIjUvvGvIiEl8K1cAM554=.a8c3abf6-0826-4d65-b6a4-88f5ee45686e@github.com>

On Fri, 8 Aug 2025 08:55:51 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into _8360048_corrupted_canary_header
>>  - local VMT vs static one.
>>  - 8360048: NMT crash in gtest/NMTGtests.java: fatal error: NMT corruption: Block at 0x0000017748307120: header canary broken
>
> Re-approved

Thank you @jdksjolen.

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

PR Comment: https://git.openjdk.org/jdk/pull/25950#issuecomment-3167109720

From azafari at openjdk.org  Fri Aug  8 09:09:23 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 8 Aug 2025 09:09:23 GMT
Subject: Integrated: 8360048: NMT crash in gtest/NMTGtests.java: fatal error:
 NMT corruption: Block at 0x0000017748307120: header canary broken
In-Reply-To: <ByslHvuFsvtks0mVSsNgiOzfAyj0MuVKIboQy15xmJE=.a82a592f-bbf2-4fc8-866e-91dcc477717c@github.com>
References: <ByslHvuFsvtks0mVSsNgiOzfAyj0MuVKIboQy15xmJE=.a82a592f-bbf2-4fc8-866e-91dcc477717c@github.com>
Message-ID: <yuoqoZ-BWznn211QxyLjzM9vwV1CbpiJ2UjWrUwk3oQ=.61565995-04c7-48bd-ab8c-c99a2a5df015@github.com>

On Tue, 24 Jun 2025 07:52:38 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> The canary header test failed since there were concurrent `remove` and `free()` from the tree. The `remove` operations are synch'ed with corresponding NMT lock. The `ReserveMemory::reserve()` uses the same lock internally and is not included in the locked code block.
> 
> Tests: tier5 {macosx-aarch64, linux-x64, windows-x64} x {debug, release}

This pull request has now been integrated.

Changeset: 1b3e2311
Author:    Afshin Zafari <azafari at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1b3e23110b2262e470a8c520b977273fd6a9e8d1
Stats:     129 lines in 5 files changed: 26 ins; 25 del; 78 mod

8360048: NMT crash in gtest/NMTGtests.java: fatal error: NMT corruption: Block at 0x0000017748307120: header canary broken

Reviewed-by: jsjolen, gziemski

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

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

From jsjolen at openjdk.org  Fri Aug  8 09:12:14 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 8 Aug 2025 09:12:14 GMT
Subject: RFR: 8364280:
 NMTCommittedVirtualMemoryTracker.test_committed_virtualmemory_region_vm fails
 with assertion "negative distance"
In-Reply-To: <ncwJP21-QPQNcKJoK3TF-H9quyeAZvIQ1Dh4diBQiP0=.6f7e47d8-1cfd-4ef0-a307-1828d27c444f@github.com>
References: <ncwJP21-QPQNcKJoK3TF-H9quyeAZvIQ1Dh4diBQiP0=.6f7e47d8-1cfd-4ef0-a307-1828d27c444f@github.com>
Message-ID: <OXsSAFEfaq3XkwK_4ngJ0Ecn37POro6QJBfFjJcV5ao=.b2dfeaab-44ba-403a-a99c-044e361e5c52@github.com>

On Fri, 8 Aug 2025 08:52:48 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> The VirtualMemoryTracker API uses a tree internally for tracking the memory regions and their states/info. This tree should not be changed when looking for some regions. If not synch'ed, the nodes in the tree may change meanwhile and the retrieved info are not as expected. The unit test in this PR did not synch these looking up with VMT. The corresponding lock is used to address the problem.
> 
> Tests:
> local: linux-x64-debug NMTGtests
> mach5: tiers 1-5, {macosx-aarch64, linux-x64, windows-x64} x {debug, release}

Marked as reviewed by jsjolen (Reviewer).

test/hotspot/gtest/runtime/test_committed_virtualmemory.cpp line 70:

> 68:           found_stack_top = true;
> 69:         }
> 70:         if(i_addr < stack_top && i_addr >= cmr.base()) {

Could you add a space between the `if` and opening paren?

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

PR Review: https://git.openjdk.org/jdk/pull/26689#pullrequestreview-3100043596
PR Review Comment: https://git.openjdk.org/jdk/pull/26689#discussion_r2262386191

From azafari at openjdk.org  Fri Aug  8 09:32:50 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 8 Aug 2025 09:32:50 GMT
Subject: RFR: 8364280:
 NMTCommittedVirtualMemoryTracker.test_committed_virtualmemory_region_vm fails
 with assertion "negative distance" [v2]
In-Reply-To: <ncwJP21-QPQNcKJoK3TF-H9quyeAZvIQ1Dh4diBQiP0=.6f7e47d8-1cfd-4ef0-a307-1828d27c444f@github.com>
References: <ncwJP21-QPQNcKJoK3TF-H9quyeAZvIQ1Dh4diBQiP0=.6f7e47d8-1cfd-4ef0-a307-1828d27c444f@github.com>
Message-ID: <VSSPL-IK2_KvgBoF-CxhVmk0cPPsaXhhWZEMkXZ1DQM=.599d4c76-fe75-4bf5-b7e9-24d01feb74fe@github.com>

> The VirtualMemoryTracker API uses a tree internally for tracking the memory regions and their states/info. This tree should not be changed when looking for some regions. If not synch'ed, the nodes in the tree may change meanwhile and the retrieved info are not as expected. The unit test in this PR did not synch these looking up with VMT. The corresponding lock is used to address the problem.
> 
> Tests:
> local: linux-x64-debug NMTGtests
> mach5: tiers 1-5, {macosx-aarch64, linux-x64, windows-x64} x {debug, release}

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

  space added

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26689/files
  - new: https://git.openjdk.org/jdk/pull/26689/files/829cce44..43a0a591

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

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

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

From fbredberg at openjdk.org  Fri Aug  8 09:56:45 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Fri, 8 Aug 2025 09:56:45 GMT
Subject: RFR: 8364570: Remove LockingMode related code from riscv64 [v2]
In-Reply-To: <TGtRFC9NpLCnaqcLtmFttGpJIHOWxXdUB4PZHfhSHoA=.0fb2f13f-f42b-4804-804e-9b24422a08c9@github.com>
References: <TGtRFC9NpLCnaqcLtmFttGpJIHOWxXdUB4PZHfhSHoA=.0fb2f13f-f42b-4804-804e-9b24422a08c9@github.com>
Message-ID: <qdApfimrKQlpcftHKqLBMrjnp4GkfBp9BS_KUfrUlO8=.db97e135-af97-4a2c-aba9-6eb454798425@github.com>

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
> 
> This PR removes `LockingMode` related code from the **riscv64** platform.
> 
> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.

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

  Update one after review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26658/files
  - new: https://git.openjdk.org/jdk/pull/26658/files/ea85a52d..a32ae39e

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

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

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

From fbredberg at openjdk.org  Fri Aug  8 09:56:45 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Fri, 8 Aug 2025 09:56:45 GMT
Subject: RFR: 8364570: Remove LockingMode related code from riscv64 [v2]
In-Reply-To: <x-vJJSZNc-43v3w3jxFD_WpyX6Tghv9khowquZtLO88=.d44f2a96-a96a-4232-aa5a-cde0dd13d812@github.com>
References: <TGtRFC9NpLCnaqcLtmFttGpJIHOWxXdUB4PZHfhSHoA=.0fb2f13f-f42b-4804-804e-9b24422a08c9@github.com>
 <x-vJJSZNc-43v3w3jxFD_WpyX6Tghv9khowquZtLO88=.d44f2a96-a96a-4232-aa5a-cde0dd13d812@github.com>
Message-ID: <lyD9f1TIFrAGvuL5EzPxah9uq6zpyg5VGb_Z9Z5SWK4=.aabc7586-78e1-4dcc-b298-997dfe369baa@github.com>

On Thu, 7 Aug 2025 15:15:14 GMT, Feilong Jiang <fjiang at openjdk.org> wrote:

>> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update one after review
>
> src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp line 1821:
> 
>> 1819:     __ ld(obj_reg, Address(oop_handle_reg, 0));
>> 1820: 
>> 1821:     Label done, not_recursive;
> 
> label `done` is not used either. We can just remove it.

Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26658#discussion_r2262501080

From azafari at openjdk.org  Fri Aug  8 12:47:07 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 8 Aug 2025 12:47:07 GMT
Subject: RFR: 8353444: NMT: rename 'category' to 'MemTag' in malloc tracker
 [v4]
In-Reply-To: <mVv-IomtzU25S1Xv1kQAy0gkUYPmuOLFDc-bJskDTaY=.c434ab86-536f-4e22-9dfa-64a00274c06b@github.com>
References: <mVv-IomtzU25S1Xv1kQAy0gkUYPmuOLFDc-bJskDTaY=.c434ab86-536f-4e22-9dfa-64a00274c06b@github.com>
Message-ID: <aVqFp6JycYndK9AVnPNX8JT3M7DuTkMH9Vr5dzuLTuA=.403ecce1-fee9-413c-a617-34510db67189@github.com>

> Renamed usage of 'category' for 'MemTag' cases.

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

  copyright fixed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25226/files
  - new: https://git.openjdk.org/jdk/pull/25226/files/85cfb2b4..0fddfd38

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

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

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

From azafari at openjdk.org  Fri Aug  8 12:55:42 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 8 Aug 2025 12:55:42 GMT
Subject: RFR: 8353444: NMT: rename 'category' to 'MemTag' in malloc tracker
 [v5]
In-Reply-To: <mVv-IomtzU25S1Xv1kQAy0gkUYPmuOLFDc-bJskDTaY=.c434ab86-536f-4e22-9dfa-64a00274c06b@github.com>
References: <mVv-IomtzU25S1Xv1kQAy0gkUYPmuOLFDc-bJskDTaY=.c434ab86-536f-4e22-9dfa-64a00274c06b@github.com>
Message-ID: <lBRzMW5p5JxzVyOj9_n1qNwF2b7B0Zbur_5EvwbguxE=.042caa0b-19d7-454d-8c13-f8c406736e44@github.com>

> Renamed usage of 'category' for 'MemTag' cases.

Afshin Zafari has updated the pull request with a new target base 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 _8353444_mem_category_to_memtag
 - copyright fixed
 - Merge remote-tracking branch 'origin/master' into _8353444_mem_category_to_memtag
 - fixed a missed test.
 - user-facing terms remained as 'category'
 - 8353444: NMT: rename 'category' to 'MemTag' in malloc tracker

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25226/files
  - new: https://git.openjdk.org/jdk/pull/25226/files/0fddfd38..79aba10b

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

  Stats: 102445 lines in 2508 files changed: 59434 ins; 28080 del; 14931 mod
  Patch: https://git.openjdk.org/jdk/pull/25226.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25226/head:pull/25226

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

From mbaesken at openjdk.org  Fri Aug  8 13:23:12 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 8 Aug 2025 13:23:12 GMT
Subject: RFR: 8365050: Too verbose warning in os::commit_memory_limit() on
 Windows
In-Reply-To: <iQwVoIGBd09nB0YEsuuKaa_MU_RuGMS247JDudz0kYY=.7eed64d0-0e82-421b-aa6f-be0788bf36b0@github.com>
References: <NSCsDz-eKA3QkSkBm64DFk325ciWfIQR7Qdgl-ZYsWA=.063ce7e2-7694-48d8-a918-91cd7363af54@github.com>
 <iQwVoIGBd09nB0YEsuuKaa_MU_RuGMS247JDudz0kYY=.7eed64d0-0e82-421b-aa6f-be0788bf36b0@github.com>
Message-ID: <1tyvpTC4k3xomfpw3XAdMI-S3BoizMim_YfRHedrF_0=.4f8e367b-fc7f-4507-8de6-39ea9789ef1b@github.com>

On Fri, 8 Aug 2025 07:16:40 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> I'll run your PR through our Windows testing , will take a bit because it is not the fastest test-env.

Our Windows tests with the PR added look okay so far !

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

PR Comment: https://git.openjdk.org/jdk/pull/26680#issuecomment-3167889166

From mbaesken at openjdk.org  Fri Aug  8 13:23:11 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 8 Aug 2025 13:23:11 GMT
Subject: RFR: 8365050: Too verbose warning in os::commit_memory_limit() on
 Windows
In-Reply-To: <NSCsDz-eKA3QkSkBm64DFk325ciWfIQR7Qdgl-ZYsWA=.063ce7e2-7694-48d8-a918-91cd7363af54@github.com>
References: <NSCsDz-eKA3QkSkBm64DFk325ciWfIQR7Qdgl-ZYsWA=.063ce7e2-7694-48d8-a918-91cd7363af54@github.com>
Message-ID: <gATOcob5AAwiVH5d2_-gVNd3_I5aq4bNgnbLRgibhCE=.a6dbfa89-9291-4bd2-9175-5fa3957767c1@github.com>

On Thu, 7 Aug 2025 16:38:21 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> This is a follow-up to [JDK-8364518](https://bugs.openjdk.org/browse/JDK-8364518), which introduced support for Job Objects in os::commit_memory_limit() on Windows. The single `warning(...)` turned out to be too verbose, as getting an error from `QueryInformationJobObject` is common when the process is not in a job and does not have permission to query information about a job. The verbosity results both in a lot of warning prints when building, and some tests to fail, which expects the output to contain something specific or nothing at all. See more details in the JBS issue.
> 
> To address this, I suggest we revise os::commit_memory_limit() to first check if the process is in a job before calling `QueryInformationJobObject`. When testing this locally, I can see that the verbose warnings when building are gone and the tests pass.
> 
> Testing:
> * Oracle's tier1-4
> * Reported test failures now pass

Marked as reviewed by mbaesken (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26680#pullrequestreview-3100810832

From fbredberg at openjdk.org  Fri Aug  8 14:19:50 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Fri, 8 Aug 2025 14:19:50 GMT
Subject: RFR: 8365146: Remove LockingMode related code from ppc64
Message-ID: <mKtlz6j_OunSKwTrSfwVxcErf8oTsclqe65OSJxXvlw=.b958a3bc-0253-4efd-a9ff-03ac0418ba23@github.com>

Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.

This PR removes `LockingMode` related code from the **ppc64le** platform.

When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.

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

Commit messages:
 - 8365146: Remove LockingMode related code from ppc64

Changes: https://git.openjdk.org/jdk/pull/26697/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26697&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365146
  Stats: 626 lines in 8 files changed: 1 ins; 573 del; 52 mod
  Patch: https://git.openjdk.org/jdk/pull/26697.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26697/head:pull/26697

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

From fbredberg at openjdk.org  Fri Aug  8 14:19:50 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Fri, 8 Aug 2025 14:19:50 GMT
Subject: RFR: 8365146: Remove LockingMode related code from ppc64
In-Reply-To: <mKtlz6j_OunSKwTrSfwVxcErf8oTsclqe65OSJxXvlw=.b958a3bc-0253-4efd-a9ff-03ac0418ba23@github.com>
References: <mKtlz6j_OunSKwTrSfwVxcErf8oTsclqe65OSJxXvlw=.b958a3bc-0253-4efd-a9ff-03ac0418ba23@github.com>
Message-ID: <SdjlmIO_4yiCgtsGucf9pJit6OvKehbmQkC0Y7lBTcQ=.a35e1b45-be4e-43fc-a36e-84d9610df4d6@github.com>

On Fri, 8 Aug 2025 12:53:10 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
> 
> This PR removes `LockingMode` related code from the **ppc64le** platform.
> 
> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.

@TheRealMDoerr (or @reinrich)
I've run rudimentary tests using QEMU, but it would be nice if you could take it for a spin on real hardware.

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

PR Comment: https://git.openjdk.org/jdk/pull/26697#issuecomment-3168108697

From stuefe at openjdk.org  Fri Aug  8 15:20:14 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 8 Aug 2025 15:20:14 GMT
Subject: RFR: 8263476: Use reserved memory for stack guard pages [v2]
In-Reply-To: <UD9VSnHOoTELaWXo7KyYT7LMIZBNiBj3wTVFiug8D2U=.0bc35853-312a-43ca-a0f3-a8c6ae2e4feb@github.com>
References: <BojYWaP10BJMEWDQYSRiMKR0cOWzMF5At9_3fwD6uUw=.becf6902-01f1-41e0-965d-18a945a6dfcf@github.com>
 <wX8LHhAfHX8PKLH4XujwLo1j7090r8DOPfCgfphQ2-E=.608da498-cff0-4ec1-9dfe-3ae224a43e38@github.com>
 <kCfkFUEayVN9i8Kj-8CYM-muyRmhSk3NhaQlZ084c7w=.702feb04-eb64-439d-b0ae-8ad7b2a93375@github.com>
 <UD9VSnHOoTELaWXo7KyYT7LMIZBNiBj3wTVFiug8D2U=.0bc35853-312a-43ca-a0f3-a8c6ae2e4feb@github.com>
Message-ID: <QppPdMuSxWNW4rgBTp_lscUg414JzuGXJj4HIB5VLEQ=.7f3a3057-a60e-4040-ac9a-dcfa935dde43@github.com>

On Mon, 4 Aug 2025 14:29:46 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> src/hotspot/os/bsd/os_bsd.inline.hpp line 44:
>> 
>>> 42:   assert(uses_stack_guard_pages(), "sanity check");
>>> 43:   return false;
>>> 44: }
>> 
>> I'm missing why it's OK to remove this.
>
> Previously, we require stack-guard-pages to be committed, and mmap MAP_STACK does "lazy" commit, so we have to perform commit explicitly. Now, we switch to reserve-only stack-guard-pages, so no explicit commit is needed.

Have you tested that on FreeBSD?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26571#discussion_r2263259099

From stuefe at openjdk.org  Fri Aug  8 15:23:26 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 8 Aug 2025 15:23:26 GMT
Subject: RFR: 8263476: Use reserved memory for stack guard pages [v3]
In-Reply-To: <ddlZFqTukD6gbte-FhRHnNMfMUTBUtKEZciaM5zFORs=.72727a99-5a09-45e3-9d61-2a423d9f699d@github.com>
References: <BojYWaP10BJMEWDQYSRiMKR0cOWzMF5At9_3fwD6uUw=.becf6902-01f1-41e0-965d-18a945a6dfcf@github.com>
 <Hv5Bte_jswZl8u2WPO9HrwMaHnWGZVaPlNfDdROONCg=.4affdc2a-81da-4bd0-8a3d-3b2aa9d09283@github.com>
 <542qBu3o6FlB7clweC-_6iOjjS6bGasPdqPY8_KrxQg=.21bbcb26-637c-4c18-83aa-dc6333fe16c8@github.com>
 <ddlZFqTukD6gbte-FhRHnNMfMUTBUtKEZciaM5zFORs=.72727a99-5a09-45e3-9d61-2a423d9f699d@github.com>
Message-ID: <juNl3NLkxzhC2I-t2IK0ksKxEBrqkE_5NfLPawd07XA=.f86ae8f0-2d38-472f-8a77-3a39b23128ac@github.com>

On Wed, 6 Aug 2025 11:40:38 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> > Apart from being hard to understand, it also opens a time window where the stack guard pages are unmapped;
> 
> Could you elaborate which part is hard to understand? I think the newly added diagram illustrates the stack-frame clearly.

Why we first unmap the stack area to then re-map it again, leading to the potential race I mentioned.

> 
> > but in this time window someone else may have mapped pages in there.
> 
> Since Linux main-thread dynamically reserves memory for stack, it's always possible that address-ranges smaller than stack-top (including stack-guard-pages) are already reserved by others.

Sorry, you lost me. What is stack_top in your description? Lowest or highest address? 

Are you saying that parts of the stack, including what is supposed to carry the stack guard, can be reserved by others? That cannot be true, otherwise we would destroy their mappings. Since we do an unconditional munmap, I assume the underlying pages are guaranteed to belong to this stack.

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

PR Comment: https://git.openjdk.org/jdk/pull/26571#issuecomment-3168286572

From zgu at openjdk.org  Fri Aug  8 16:57:12 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Fri, 8 Aug 2025 16:57:12 GMT
Subject: RFR: 8263476: Use reserved memory for stack guard pages [v3]
In-Reply-To: <lBhveKtt7FdW2AllRPOfY-saPOipumgiQd1abxetChk=.391d880e-1666-4614-8b5e-5ac4471f4ce3@github.com>
References: <BojYWaP10BJMEWDQYSRiMKR0cOWzMF5At9_3fwD6uUw=.becf6902-01f1-41e0-965d-18a945a6dfcf@github.com>
 <Hv5Bte_jswZl8u2WPO9HrwMaHnWGZVaPlNfDdROONCg=.4affdc2a-81da-4bd0-8a3d-3b2aa9d09283@github.com>
 <FrpsSrJPnzecNLiVIcpQ1N_eFqITv05bR9XG8bYzTi4=.398978ab-7bb7-4a50-84ae-6642e401488a@github.com>
 <Y06nt2THUQCaX7imrempGXN8ztnGflBwWc16JH1T3fo=.f4df6b35-88d4-417b-9b2c-87cb4354d793@github.com>
 <vN_wF316lRKdbp2IY4bAc79SNK5gxyC-TsNPGspBs-U=.d9bd9fb9-b21b-4437-9080-368efa26d027@github.com>
 <a1ChPGZljvKBAmAqA5QLfKe7UPNls4Zqb5iOcX6ZB00=.7b3ffd6d-3a3b-4d0b-9a69-7c01a74884cc@github.com>
 <lBhveKtt7FdW2AllRPOfY-saPOipumgiQd1abxetChk=.391d880e-1666-4614-8b5e-5ac4471f4ce3@github.com>
Message-ID: <4A7oRldFMwkl-RJwV-Ux4AZ3iOON3yFI73X0AlZEkq4=.47ddf4f2-17c5-4b8d-bd37-0d95cc0a34ca@github.com>

On Wed, 6 Aug 2025 20:28:49 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> > Current create_stack_guard_pages() implementation calls os::commit_memory(addr, size, !ExecMem) to setup the protection.
> 
> Which `create_stack_guard_pages` are you referring to, in `StackOverflow` or `os`?
> 
> `StackOverflow::create_stack_guard_pages` invokes `os::create_stack_guard_pages` for some preparation work (optional for some platforms) and `os::guard_memory` for protection setup.
> 
> `os::commit_memory` is not directly related to memory protection.

Ah, okay.  I believe I wanted to get rid of this `commit_memory` call which has the undesirable side-effort to NMT. 
BTW, do you need the `reserve_memory()`, are the guard pages already reserved as part of stack?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26571#discussion_r2263555660

From ayang at openjdk.org  Fri Aug  8 19:07:13 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 8 Aug 2025 19:07:13 GMT
Subject: RFR: 8263476: Use reserved memory for stack guard pages [v3]
In-Reply-To: <juNl3NLkxzhC2I-t2IK0ksKxEBrqkE_5NfLPawd07XA=.f86ae8f0-2d38-472f-8a77-3a39b23128ac@github.com>
References: <BojYWaP10BJMEWDQYSRiMKR0cOWzMF5At9_3fwD6uUw=.becf6902-01f1-41e0-965d-18a945a6dfcf@github.com>
 <Hv5Bte_jswZl8u2WPO9HrwMaHnWGZVaPlNfDdROONCg=.4affdc2a-81da-4bd0-8a3d-3b2aa9d09283@github.com>
 <542qBu3o6FlB7clweC-_6iOjjS6bGasPdqPY8_KrxQg=.21bbcb26-637c-4c18-83aa-dc6333fe16c8@github.com>
 <ddlZFqTukD6gbte-FhRHnNMfMUTBUtKEZciaM5zFORs=.72727a99-5a09-45e3-9d61-2a423d9f699d@github.com>
 <juNl3NLkxzhC2I-t2IK0ksKxEBrqkE_5NfLPawd07XA=.f86ae8f0-2d38-472f-8a77-3a39b23128ac@github.com>
Message-ID: <EgV2ylv7DzMSiK_2UmMIYP9nP8NlGsweihCSkMHCgl4=.09dea4da-92a7-4124-a38d-43122bd5ea3d@github.com>

On Fri, 8 Aug 2025 15:20:13 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Why we first unmap the stack area to then re-map it again, leading to the potential race I mentioned.

To ensure the reserved stack memory is contiguous, after the stack-guard-pages are removed (unguarded).
The old code also performs `munmap` as well, and the reasoning is the same, covered in the doc right before `os::pd_create_stack_guard_pages` in Linux.

> Sorry, you lost me. What is stack_top in your description? Lowest or highest address?

The lowest-address. This is the C code I used: stack-memory for main-thread is reserved ("stolen") by others and main-thread encounters segfault. Ofc, the more realistic racing is that another thread steals the stack-memory, but this is just to show the idea.

<details>

<summary>C source code</summary>


#define _GNU_SOURCE
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <unistd.h>
#include <sys/mman.h>

int main(void) {
    size_t page_size = sysconf(_SC_PAGESIZE);
    if (page_size == (size_t)-1) {
        perror("sysconf");
        return 1;
    }

    // Current stack address
    void *stack_addr = __builtin_frame_address(0);

    // Pick a page ~1MB below current stack and align down
    uintptr_t target = ((uintptr_t)stack_addr - 1024 * 1024) & ~(page_size - 1);

    // Map one page there ? "stealing" it from potential stack growth
    void *m = mmap((void *)target, page_size,
                   PROT_READ | PROT_WRITE,
                   MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED, -1, 0);
    if (m == MAP_FAILED) {
        perror("mmap");
        return 1;
    }

    // Now force the stack to grow downward into the stolen page
    // This large local array will overlap the mapping
    char buf[1024 * 1024]; // ~1MB
    buf[0] = 1;

    // If we get here, somehow no crash occurred
    printf("Unexpectedly survived.\n");
    return 0;
}

</details>

> Since we do an unconditional munmap, I assume the underlying pages are guaranteed to belong to this stack.

It's not really "unconditional", we check the memory-range to be munmap belongs to [stack-start, stack-end].

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

PR Comment: https://git.openjdk.org/jdk/pull/26571#issuecomment-3169031521

From ayang at openjdk.org  Fri Aug  8 19:07:14 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 8 Aug 2025 19:07:14 GMT
Subject: RFR: 8263476: Use reserved memory for stack guard pages [v3]
In-Reply-To: <4A7oRldFMwkl-RJwV-Ux4AZ3iOON3yFI73X0AlZEkq4=.47ddf4f2-17c5-4b8d-bd37-0d95cc0a34ca@github.com>
References: <BojYWaP10BJMEWDQYSRiMKR0cOWzMF5At9_3fwD6uUw=.becf6902-01f1-41e0-965d-18a945a6dfcf@github.com>
 <Hv5Bte_jswZl8u2WPO9HrwMaHnWGZVaPlNfDdROONCg=.4affdc2a-81da-4bd0-8a3d-3b2aa9d09283@github.com>
 <FrpsSrJPnzecNLiVIcpQ1N_eFqITv05bR9XG8bYzTi4=.398978ab-7bb7-4a50-84ae-6642e401488a@github.com>
 <Y06nt2THUQCaX7imrempGXN8ztnGflBwWc16JH1T3fo=.f4df6b35-88d4-417b-9b2c-87cb4354d793@github.com>
 <vN_wF316lRKdbp2IY4bAc79SNK5gxyC-TsNPGspBs-U=.d9bd9fb9-b21b-4437-9080-368efa26d027@github.com>
 <a1ChPGZljvKBAmAqA5QLfKe7UPNls4Zqb5iOcX6ZB00=.7b3ffd6d-3a3b-4d0b-9a69-7c01a74884cc@github.com>
 <lBhveKtt7FdW2AllRPOfY-saPOipumgiQd1abxetChk=.391d880e-1666-4614-8b5e-5ac4471f4ce3@github.com>
 <4A7oRldFMwkl-RJwV-Ux4AZ3iOON3yFI73X0AlZEkq4=.47ddf4f2-17c5-4b8d-bd37-0d95cc0a34ca@github.com>
Message-ID: <4Tw48W8DIPUxRGzJV47ikWaJfXylEVcyXhNmtbica_U=.d3948b28-82f4-44c9-b499-e11eceb2bbff@github.com>

On Fri, 8 Aug 2025 16:54:31 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> I believe I wanted to get rid of this commit_memory call which has the undesirable side-effort to NMT.

Yes, I believe I understand that correctly and achieved that in this PR.

> BTW, do you need the reserve_memory(), are the guard pages already reserved as part of stack?

It's platform-specific. For linux, only `is_primordial_thread` reserves stack-memory dynamically, so we need to do sth special for it. Other threads have all stack-memory reserved, requires no preparation before calling `os::guard_memory`. (I covered this in the implementation note section of ticket description, just fyi.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26571#discussion_r2263804282

From duke at openjdk.org  Fri Aug  8 22:36:19 2025
From: duke at openjdk.org (duke)
Date: Fri, 8 Aug 2025 22:36:19 GMT
Subject: Withdrawn: 8355298: Increase timeout for StressAsyncUL
In-Reply-To: <HNNV413pNib7S4m5hfHqaGDQXnlts6jbFvgkYonRZbs=.be82315d-65cc-4c2a-a128-7a54d5fb1c37@github.com>
References: <HNNV413pNib7S4m5hfHqaGDQXnlts6jbFvgkYonRZbs=.be82315d-65cc-4c2a-a128-7a54d5fb1c37@github.com>
Message-ID: <RiIc4aIAo5sflvZfBYKLjkiX5x1HwIB0IGtf8EYZcMg=.687eac9f-4039-4a8e-8e7e-4e8256384123@github.com>

On Mon, 9 Jun 2025 14:01:17 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> Running async UL with stalling mode enabled is very slow if your buffer is very small. This turns out to become an issue on slow machines, where we run the risk of the test timing out.
> 
> The ticket's suggestion (and title) is to increase the timeout. I think that it'd be fine to reduce the logging level to 'debug' instead, thus reducing the time required to run the test.
> 
> Obviously, if we go with this solution then the ticket name and description must be adjusted.

This pull request has been closed without being integrated.

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

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

From fjiang at openjdk.org  Sat Aug  9 11:08:16 2025
From: fjiang at openjdk.org (Feilong Jiang)
Date: Sat, 9 Aug 2025 11:08:16 GMT
Subject: RFR: 8364570: Remove LockingMode related code from riscv64 [v2]
In-Reply-To: <qdApfimrKQlpcftHKqLBMrjnp4GkfBp9BS_KUfrUlO8=.db97e135-af97-4a2c-aba9-6eb454798425@github.com>
References: <TGtRFC9NpLCnaqcLtmFttGpJIHOWxXdUB4PZHfhSHoA=.0fb2f13f-f42b-4804-804e-9b24422a08c9@github.com>
 <qdApfimrKQlpcftHKqLBMrjnp4GkfBp9BS_KUfrUlO8=.db97e135-af97-4a2c-aba9-6eb454798425@github.com>
Message-ID: <z9QoYarFGB-3WlQQqGHC-EFfCvlnknt5WJ1f7udPDvk=.c5089f9f-fe99-4dd1-a234-f0ba448c42d9@github.com>

On Fri, 8 Aug 2025 09:56:45 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
>> 
>> This PR removes `LockingMode` related code from the **riscv64** platform.
>> 
>> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.
>
> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update one after review

Marked as reviewed by fjiang (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/26658#pullrequestreview-3102922414

From snatarajan at openjdk.org  Sat Aug  9 15:35:00 2025
From: snatarajan at openjdk.org (Saranya Natarajan)
Date: Sat, 9 Aug 2025 15:35:00 GMT
Subject: RFR: 8358696: Assert with extreme values for -XX:BciProfileWidth
 [v6]
In-Reply-To: <5TRVeAXUQi6quM-nDWEij_jk6M5K2Vk31RA-Yjd8F2M=.5b63da45-93c3-4251-9e2e-3c64b7953919@github.com>
References: <5TRVeAXUQi6quM-nDWEij_jk6M5K2Vk31RA-Yjd8F2M=.5b63da45-93c3-4251-9e2e-3c64b7953919@github.com>
Message-ID: <Nt6C65eUJqxWJAPob_5ZvNiQXZJMQK_vD_Ik9NYSCm4=.773e5f1a-a02f-4206-99d8-e8003a708cd6@github.com>

> **Issue**
> Extreme values for BciProfileWidth flag such as `java -XX:BciProfileWidth=-1 -version` and `java -XX:BciProfileWidth=100000 -version `results in assert failure `assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x0000772b63a7a3a0 <= 0x0000772b63b75159 <= 0x0000772b63b75158 `. This is observed in a x86 machine.
> 
> **Analysis** 
>  On debugging the issue, I found that increasing the size of the interpreter using the `InterpreterCodeSize` variable in `src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp` prevented the above mentioned assert from failing for large values of BciProfileWidth.  
> 
> **Proposal** 
> Considering the fact that larger BciProfileWidth results in slower profiling, I have proposed a range between 0 to 5000 to restrict the value for BciProfileWidth for x86 machines. This maximum value is based on modifying the `InterpreterCodeSize` variable in `src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp` using the smallest `InterpreterCodeSize` for all the architectures.  As for the lower bound, a value of -1 would be the same as 0, as this simply means  no  return bci's will be recorded in ret profile. 
> 
> **Issue in AArch64**
> Additionally running the command `java -XX:BciProfileWidth= 10000 -version` (or larger values) results in a different failure  `assert(offset_ok_for_immed(offset(), size)) failed: must be, was: 32768, 3` on an AArch64 machine.This is an issue of maximum offset for `ldr/str` in AArch64 which can be fixed using `form_address`  as mentioned in [JDK-8342736](https://bugs.openjdk.org/browse/JDK-8342736). In my preliminary fix using `form_address` on AArch64 machine. I had to modify 3 `ldr` and 1 `str` instruction (in file `src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp` at line number 926, 983, and 997). With this fix  using `form_address`, `BciProfileWidth` works for maximum of 5000 after which it crashes with`assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x0000772b63a7a3a0 <= 0x0000772b63b75159 <= 0x0000772b63b75158 `.  Without this fix `BciProfileWidth` works for a maximum value of 1300.   Currently, I have suggested to restrict the upper bound on AArch64 to 1000 instead 
 of fixing it with `form_address`. 
> 
> **Question to reviewers**
> Do you think this is a reasonable fix ?  For AArch64 do you suggest fixing using `form_address` ? If yes, do I fix it under this PR or create another one ?

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

  Addressing review - testcase and max range is set to 1000

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26139/files
  - new: https://git.openjdk.org/jdk/pull/26139/files/2fc4b0b7..9dae3aef

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

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

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

From fyang at openjdk.org  Mon Aug 11 00:17:16 2025
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 11 Aug 2025 00:17:16 GMT
Subject: RFR: 8364570: Remove LockingMode related code from riscv64 [v2]
In-Reply-To: <qdApfimrKQlpcftHKqLBMrjnp4GkfBp9BS_KUfrUlO8=.db97e135-af97-4a2c-aba9-6eb454798425@github.com>
References: <TGtRFC9NpLCnaqcLtmFttGpJIHOWxXdUB4PZHfhSHoA=.0fb2f13f-f42b-4804-804e-9b24422a08c9@github.com>
 <qdApfimrKQlpcftHKqLBMrjnp4GkfBp9BS_KUfrUlO8=.db97e135-af97-4a2c-aba9-6eb454798425@github.com>
Message-ID: <CHAT2yULFGB8mG8t1EJQCrGMc7uN-ViJd25bQPbglqw=.69579f21-3b68-43aa-aee8-815f7a609e2d@github.com>

On Fri, 8 Aug 2025 09:56:45 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
>> 
>> This PR removes `LockingMode` related code from the **riscv64** platform.
>> 
>> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.
>
> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update one after review

@fbredber : Thanks for the ping. My local tier1-3 test result is good. Looks fine to me modulo several nits.

src/hotspot/cpu/riscv/interp_masm_riscv.cpp line 743:

> 741:   const Register tmp3 = c_rarg5;
> 742: 
> 743:   Label slow_case;

Nit: Maybe declare the two Labels `done` and `slow_case` on the same line.
`Label slow_case, done;`

src/hotspot/cpu/riscv/interp_masm_riscv.cpp line 745:

> 743:   Label slow_case;
> 744: 
> 745:   // Load object pointer into obj_reg c_rarg3

Suggestion: `// Load object pointer into obj_reg (c_rarg3)`

src/hotspot/cpu/riscv/interp_masm_riscv.cpp line 785:

> 783:   save_bcp(); // Save in case of exception
> 784: 
> 785:   // Load oop into obj_reg(c_rarg3)

Suggestion: `// Load oop into obj_reg (c_rarg3)`

src/hotspot/cpu/riscv/interp_masm_riscv.cpp line 791:

> 789:   sd(zr, Address(lock_reg, BasicObjectLock::obj_offset()));
> 790: 
> 791:   Label slow_case;

Similar here. We can declare the two Labels `done` and `slow_case` on the same line.

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

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26658#pullrequestreview-3103526665
PR Review Comment: https://git.openjdk.org/jdk/pull/26658#discussion_r2265176879
PR Review Comment: https://git.openjdk.org/jdk/pull/26658#discussion_r2265178957
PR Review Comment: https://git.openjdk.org/jdk/pull/26658#discussion_r2265179114
PR Review Comment: https://git.openjdk.org/jdk/pull/26658#discussion_r2265178181

From thartmann at openjdk.org  Mon Aug 11 01:42:15 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 11 Aug 2025 01:42:15 GMT
Subject: RFR: 8358696: Assert with extreme values for -XX:BciProfileWidth
 [v6]
In-Reply-To: <Nt6C65eUJqxWJAPob_5ZvNiQXZJMQK_vD_Ik9NYSCm4=.773e5f1a-a02f-4206-99d8-e8003a708cd6@github.com>
References: <5TRVeAXUQi6quM-nDWEij_jk6M5K2Vk31RA-Yjd8F2M=.5b63da45-93c3-4251-9e2e-3c64b7953919@github.com>
 <Nt6C65eUJqxWJAPob_5ZvNiQXZJMQK_vD_Ik9NYSCm4=.773e5f1a-a02f-4206-99d8-e8003a708cd6@github.com>
Message-ID: <1QbX5WHkEdjP-unAFJ1vYaoIc9bV8zz8dA-vKZCkYn8=.8e3704ae-9490-4471-9e5c-dae44004d46f@github.com>

On Sat, 9 Aug 2025 15:35:00 GMT, Saranya Natarajan <snatarajan at openjdk.org> wrote:

>> **Issue**
>> Extreme values for BciProfileWidth flag such as `java -XX:BciProfileWidth=-1 -version` and `java -XX:BciProfileWidth=100000 -version `results in assert failure `assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x0000772b63a7a3a0 <= 0x0000772b63b75159 <= 0x0000772b63b75158 `. This is observed in a x86 machine.
>> 
>> **Analysis** 
>>  On debugging the issue, I found that increasing the size of the interpreter using the `InterpreterCodeSize` variable in `src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp` prevented the above mentioned assert from failing for large values of BciProfileWidth.  
>> 
>> **Proposal** 
>> Considering the fact that larger BciProfileWidth results in slower profiling, I have proposed a range between 0 to 5000 to restrict the value for BciProfileWidth for x86 machines. This maximum value is based on modifying the `InterpreterCodeSize` variable in `src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp` using the smallest `InterpreterCodeSize` for all the architectures.  As for the lower bound, a value of -1 would be the same as 0, as this simply means  no  return bci's will be recorded in ret profile. 
>> 
>> **Issue in AArch64**
>> Additionally running the command `java -XX:BciProfileWidth= 10000 -version` (or larger values) results in a different failure  `assert(offset_ok_for_immed(offset(), size)) failed: must be, was: 32768, 3` on an AArch64 machine.This is an issue of maximum offset for `ldr/str` in AArch64 which can be fixed using `form_address`  as mentioned in [JDK-8342736](https://bugs.openjdk.org/browse/JDK-8342736). In my preliminary fix using `form_address` on AArch64 machine. I had to modify 3 `ldr` and 1 `str` instruction (in file `src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp` at line number 926, 983, and 997). With this fix  using `form_address`, `BciProfileWidth` works for maximum of 5000 after which it crashes with`assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x0000772b63a7a3a0 <= 0x0000772b63b75159 <= 0x0000772b63b75158 `.  Without this fix `BciProfileWidth` works for a maximum value of 1300.   Currently, I have suggested to restrict the upper bound on AArch64 to 1000 instead
  of fixing it with `form_address`. 
>> 
>> **Question to reviewers**
>> Do you think this is a reasonable fix ?  For AArch64 do you suggest fixing using `form_address` ? If yes, do I fix it under this PR or create another one ?
>> 
>> **Request to port maintainers**
>> @dafedafe suggested that we keep the upper boun...
>
> Saranya Natarajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing review - testcase and max range is set to 1000

test/hotspot/jtreg/compiler/arguments/TestBciProfileWidth.java line 28:

> 26:  * @summary Test the range defined in globals.hpp for BciProfileWidth
> 27:  * @bug 8358696
> 28:  * @run main/othervm -XX:BciProfileWidth=0

`BciProfileWidth` is debug only, right?

test/lib-test/jdk/test/whitebox/vm_flags/IntxTest.java line 41:

> 39:     private static final long COMPILE_THRESHOLD = VmFlagTest.WHITE_BOX.getIntxVMFlag("CompileThreshold");
> 40:     private static final Long[] TESTS = {0L, 100L, (long)(Integer.MAX_VALUE>>3)*100L};
> 41:     private static final String FLAG_DEBUG_NAME = "BinarySwitchThreshold";

Why did you move the location of the declaration?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26139#discussion_r2265539177
PR Review Comment: https://git.openjdk.org/jdk/pull/26139#discussion_r2265539538

From aboldtch at openjdk.org  Mon Aug 11 05:08:11 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 11 Aug 2025 05:08:11 GMT
Subject: RFR: 8364141: Remove LockingMode related code from x86 [v4]
In-Reply-To: <wQPBsXlKAZtaZlcTLSgISHvII9vOIewNNoNW5cjBTW4=.9c3ffca2-7656-40ae-b6f5-5f7a9fc6151c@github.com>
References: <g7WNqmFlJOkai-zeEjD09M5TwpL3fAMkZUAy37b747U=.faa6d9f5-1894-4507-a0f1-1dd41f3bdd43@github.com>
 <wQPBsXlKAZtaZlcTLSgISHvII9vOIewNNoNW5cjBTW4=.9c3ffca2-7656-40ae-b6f5-5f7a9fc6151c@github.com>
Message-ID: <8TcJ6y_O08pg5m9k3mnOUr0OnQPdPq6LMKOh8oIn1KM=.40cb7a32-8691-4069-bb48-13a767cad50e@github.com>

On Thu, 7 Aug 2025 09:23:37 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
>> 
>> This PR removes `LockingMode` related code from the **x86** platform.
>> 
>> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.
>> 
>> Passes tier1-tier5 with no added problems.
>
> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update three after review

Looks good. 

As long as we take a final pass after all code changes has been performed and clean up the comments, variable-, parameter- and function-names. Would be nice to end with a consistent nomenclature, and remove all outdated terms, at least w.r.t. legacy locking.

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

Marked as reviewed by aboldtch (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26552#pullrequestreview-3104058030

From mbaesken at openjdk.org  Mon Aug 11 08:14:12 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 11 Aug 2025 08:14:12 GMT
Subject: RFR: 8365050: Too verbose warning in os::commit_memory_limit() on
 Windows
In-Reply-To: <NSCsDz-eKA3QkSkBm64DFk325ciWfIQR7Qdgl-ZYsWA=.063ce7e2-7694-48d8-a918-91cd7363af54@github.com>
References: <NSCsDz-eKA3QkSkBm64DFk325ciWfIQR7Qdgl-ZYsWA=.063ce7e2-7694-48d8-a918-91cd7363af54@github.com>
Message-ID: <Gv_ECXK69J4eBvXxRRXRhv5tBNFaayEJBy1w0AxowDI=.9cb70b05-efc3-4e40-8560-7de5c932910f@github.com>

On Thu, 7 Aug 2025 16:38:21 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> This is a follow-up to [JDK-8364518](https://bugs.openjdk.org/browse/JDK-8364518), which introduced support for Job Objects in os::commit_memory_limit() on Windows. The single `warning(...)` turned out to be too verbose, as getting an error from `QueryInformationJobObject` is common when the process is not in a job and does not have permission to query information about a job. The verbosity results both in a lot of warning prints when building, and some tests to fail, which expects the output to contain something specific or nothing at all. See more details in the JBS issue.
> 
> To address this, I suggest we revise os::commit_memory_limit() to first check if the process is in a job before calling `QueryInformationJobObject`. When testing this locally, I can see that the verbose warnings when building are gone and the tests pass.
> 
> Testing:
> * Oracle's tier1-4
> * Reported test failures now pass

Windows tests with this patch look good, without it  LOTS of failures - so can this be integrated ?

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

PR Comment: https://git.openjdk.org/jdk/pull/26680#issuecomment-3173695763

From jsikstro at openjdk.org  Mon Aug 11 08:21:28 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 11 Aug 2025 08:21:28 GMT
Subject: RFR: 8365050: Too verbose warning in os::commit_memory_limit() on
 Windows
In-Reply-To: <Gv_ECXK69J4eBvXxRRXRhv5tBNFaayEJBy1w0AxowDI=.9cb70b05-efc3-4e40-8560-7de5c932910f@github.com>
References: <NSCsDz-eKA3QkSkBm64DFk325ciWfIQR7Qdgl-ZYsWA=.063ce7e2-7694-48d8-a918-91cd7363af54@github.com>
 <Gv_ECXK69J4eBvXxRRXRhv5tBNFaayEJBy1w0AxowDI=.9cb70b05-efc3-4e40-8560-7de5c932910f@github.com>
Message-ID: <UrTW8JQICswCLTsYB8BlKlm5oOa3GzcrWI3_kMILxAA=.02d1950d-4416-41c7-8567-48e1a119a7c9@github.com>

On Mon, 11 Aug 2025 08:11:15 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Hello,
>> 
>> This is a follow-up to [JDK-8364518](https://bugs.openjdk.org/browse/JDK-8364518), which introduced support for Job Objects in os::commit_memory_limit() on Windows. The single `warning(...)` turned out to be too verbose, as getting an error from `QueryInformationJobObject` is common when the process is not in a job and does not have permission to query information about a job. The verbosity results both in a lot of warning prints when building, and some tests to fail, which expects the output to contain something specific or nothing at all. See more details in the JBS issue.
>> 
>> To address this, I suggest we revise os::commit_memory_limit() to first check if the process is in a job before calling `QueryInformationJobObject`. When testing this locally, I can see that the verbose warnings when building are gone and the tests pass.
>> 
>> Testing:
>> * Oracle's tier1-4
>> * Reported test failures now pass
>
> Windows tests with this patch look good, without it  LOTS of failures - so can this be integrated ?

@MBaesken Yes, lets ship it. Sorry for the delay.
Thank you both for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/26680#issuecomment-3173709843

From jsikstro at openjdk.org  Mon Aug 11 08:21:29 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 11 Aug 2025 08:21:29 GMT
Subject: Integrated: 8365050: Too verbose warning in os::commit_memory_limit()
 on Windows
In-Reply-To: <NSCsDz-eKA3QkSkBm64DFk325ciWfIQR7Qdgl-ZYsWA=.063ce7e2-7694-48d8-a918-91cd7363af54@github.com>
References: <NSCsDz-eKA3QkSkBm64DFk325ciWfIQR7Qdgl-ZYsWA=.063ce7e2-7694-48d8-a918-91cd7363af54@github.com>
Message-ID: <olkG7ckwRrqB-sREkABmU83w8gL56V01AH_F7seZ4fE=.1997e3ee-fc95-424b-90d2-86ed60b16ced@github.com>

On Thu, 7 Aug 2025 16:38:21 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> This is a follow-up to [JDK-8364518](https://bugs.openjdk.org/browse/JDK-8364518), which introduced support for Job Objects in os::commit_memory_limit() on Windows. The single `warning(...)` turned out to be too verbose, as getting an error from `QueryInformationJobObject` is common when the process is not in a job and does not have permission to query information about a job. The verbosity results both in a lot of warning prints when building, and some tests to fail, which expects the output to contain something specific or nothing at all. See more details in the JBS issue.
> 
> To address this, I suggest we revise os::commit_memory_limit() to first check if the process is in a job before calling `QueryInformationJobObject`. When testing this locally, I can see that the verbose warnings when building are gone and the tests pass.
> 
> Testing:
> * Oracle's tier1-4
> * Reported test failures now pass

This pull request has now been integrated.

Changeset: f28126eb
Author:    Joel Sikstr?m <jsikstro at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f28126ebc2f792f0d64bbe6e841d9fafb433b7ea
Stats:     18 lines in 1 file changed: 15 ins; 0 del; 3 mod

8365050: Too verbose warning in os::commit_memory_limit() on Windows

Reviewed-by: dholmes, mbaesken

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

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

From jsikstro at openjdk.org  Mon Aug 11 08:26:26 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 11 Aug 2025 08:26:26 GMT
Subject: RFR: 8365050: Too verbose warning in os::commit_memory_limit() on
 Windows
In-Reply-To: <iQwVoIGBd09nB0YEsuuKaa_MU_RuGMS247JDudz0kYY=.7eed64d0-0e82-421b-aa6f-be0788bf36b0@github.com>
References: <NSCsDz-eKA3QkSkBm64DFk325ciWfIQR7Qdgl-ZYsWA=.063ce7e2-7694-48d8-a918-91cd7363af54@github.com>
 <iQwVoIGBd09nB0YEsuuKaa_MU_RuGMS247JDudz0kYY=.7eed64d0-0e82-421b-aa6f-be0788bf36b0@github.com>
Message-ID: <HWlf9kZ3NSgNltpHG1ex0Tx57WxldRBOOJ9yr8u-Qx0=.c80c69b1-c15e-46e7-b5d6-c8bc3308c6f5@github.com>

On Fri, 8 Aug 2025 07:17:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> You might consider factoring out the IsProcessInJob related checking from your code and active_processors_in_job_object, maybe a little helper would make sense; but up to you just an idea.

Daivd Holmes filed an umbrella task to "Provide support for Windows Job Objects that limit process resources" [JDK-8364803](https://bugs.openjdk.org/browse/JDK-8364803). I suggest we hold off with refactoring until then.

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

PR Comment: https://git.openjdk.org/jdk/pull/26680#issuecomment-3173729007

From fbredberg at openjdk.org  Mon Aug 11 09:01:16 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Mon, 11 Aug 2025 09:01:16 GMT
Subject: RFR: 8364141: Remove LockingMode related code from x86 [v4]
In-Reply-To: <8TcJ6y_O08pg5m9k3mnOUr0OnQPdPq6LMKOh8oIn1KM=.40cb7a32-8691-4069-bb48-13a767cad50e@github.com>
References: <g7WNqmFlJOkai-zeEjD09M5TwpL3fAMkZUAy37b747U=.faa6d9f5-1894-4507-a0f1-1dd41f3bdd43@github.com>
 <wQPBsXlKAZtaZlcTLSgISHvII9vOIewNNoNW5cjBTW4=.9c3ffca2-7656-40ae-b6f5-5f7a9fc6151c@github.com>
 <8TcJ6y_O08pg5m9k3mnOUr0OnQPdPq6LMKOh8oIn1KM=.40cb7a32-8691-4069-bb48-13a767cad50e@github.com>
Message-ID: <bFGJszcroOHILpWqzXpdPDMqgwYyKkNkjq3seuSGTOU=.f2396614-bee8-49d7-86f4-b0235fcb556f@github.com>

On Mon, 11 Aug 2025 05:05:28 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update three after review
>
> Looks good. 
> 
> As long as we take a final pass after all code changes has been performed and clean up the comments, variable-, parameter- and function-names. Would be nice to end with a consistent nomenclature, and remove all outdated terms, at least w.r.t. legacy locking.

@xmas92 
> As long as we take a final pass after all code changes has been performed and clean up the comments, variable-, parameter- and function-names. Would be nice to end with a consistent nomenclature, and remove all outdated terms, at least w.r.t. legacy locking.

That is my intention with this: [Cleanup after removing LockingMode related code](https://bugs.openjdk.org/browse/JDK-8365191)

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

PR Comment: https://git.openjdk.org/jdk/pull/26552#issuecomment-3173828593

From azafari at openjdk.org  Mon Aug 11 09:29:10 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 11 Aug 2025 09:29:10 GMT
Subject: RFR: 8364280:
 NMTCommittedVirtualMemoryTracker.test_committed_virtualmemory_region_vm fails
 with assertion "negative distance" [v2]
In-Reply-To: <OXsSAFEfaq3XkwK_4ngJ0Ecn37POro6QJBfFjJcV5ao=.b2dfeaab-44ba-403a-a99c-044e361e5c52@github.com>
References: <ncwJP21-QPQNcKJoK3TF-H9quyeAZvIQ1Dh4diBQiP0=.6f7e47d8-1cfd-4ef0-a307-1828d27c444f@github.com>
 <OXsSAFEfaq3XkwK_4ngJ0Ecn37POro6QJBfFjJcV5ao=.b2dfeaab-44ba-403a-a99c-044e361e5c52@github.com>
Message-ID: <9NQUn3WyRho9NxRDPti4e_q4bqSrQF4LFiP8w-lbCLM=.ee9cc923-12d3-44d3-8125-b7792909f1b8@github.com>

On Fri, 8 Aug 2025 09:08:57 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   space added
>
> test/hotspot/gtest/runtime/test_committed_virtualmemory.cpp line 70:
> 
>> 68:           found_stack_top = true;
>> 69:         }
>> 70:         if(i_addr < stack_top && i_addr >= cmr.base()) {
> 
> Could you add a space between the `if` and opening paren?

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26689#discussion_r2266136226

From azafari at openjdk.org  Mon Aug 11 09:33:16 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 11 Aug 2025 09:33:16 GMT
Subject: RFR: 8353444: NMT: rename 'category' to 'MemTag' in malloc tracker
 [v3]
In-Reply-To: <VyWYXgTSRRU837ZqpWAWiUbE033ZNugefwhgI2Zyq8c=.28575626-5fee-4618-87eb-075d3cca71b7@github.com>
References: <mVv-IomtzU25S1Xv1kQAy0gkUYPmuOLFDc-bJskDTaY=.c434ab86-536f-4e22-9dfa-64a00274c06b@github.com>
 <XTCTiot9phOVQqQh70O-hDD1TDVhNY0AVqkApZ4Ne-o=.21b610a9-8c2f-4c64-94a1-df7c31752530@github.com>
 <VyWYXgTSRRU837ZqpWAWiUbE033ZNugefwhgI2Zyq8c=.28575626-5fee-4618-87eb-075d3cca71b7@github.com>
Message-ID: <lvZ8SugJVzElPsq1h09zNlT67KX9gIfF_RBl3MlIZaQ=.4b9de8c0-1cbf-4a9e-8bc6-d5018417ad4d@github.com>

On Wed, 18 Jun 2025 12:13:32 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/master' into _8353444_mem_category_to_memtag
>>  - fixed a missed test.
>>  - user-facing terms remained as 'category'
>>  - 8353444: NMT: rename 'category' to 'MemTag' in malloc tracker
>
> test/hotspot/jtreg/runtime/NMT/MallocLimitTest.java line 3:
> 
>> 1: /*
>> 2:  * Copyright (c) 2022 SAP SE. All rights reserved.
>> 3:  * Copyright (c) 2022, 2025, Oracle and/or its affiliates. All rights reserved.
> 
> Revert this copyright notice.

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25226#discussion_r2266143376

From ayang at openjdk.org  Mon Aug 11 10:57:10 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 11 Aug 2025 10:57:10 GMT
Subject: RFR: 8352067: Remove the NMT treap and replace its uses with the
 utilities red-black tree [v2]
In-Reply-To: <Sw5KhaC03y3T-bZa54aSCpcXwgLyDeL9h6Mzsnva0BI=.3d877982-e6bf-416a-bcdf-5ba96e5def56@github.com>
References: <xXuaevhTzxS26C6s7DR0BdSQDFPeV5cMg4_qImS_Uw4=.fa5dc831-57b2-409c-8015-ef3dbc143c65@github.com>
 <Sw5KhaC03y3T-bZa54aSCpcXwgLyDeL9h6Mzsnva0BI=.3d877982-e6bf-416a-bcdf-5ba96e5def56@github.com>
Message-ID: <_64fHkIUSnCgZRdwphFKm6LqfUaSv_NKzd0-ivH3nEw=.4fc83148-7758-4ef7-969c-816aa0750a92@github.com>

On Wed, 6 Aug 2025 11:07:42 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> The utilities red-black tree and the NMT treap serve similar functions. Given the red-black tree's versatility and stricter time complexity, the treap can be removed in favour of it.
>> 
>> I made some modifications to the red-black tree to make it compatible with previous treap usages:
>> - Updated the `visit_in_order` and `visit_range_in_order` functions to require the supplied callback to return a bool, which allows us to stop traversing early.
>> - Improved const-correctness by ensuring that invoking these functions on a const reference provides const pointers to nodes, while non-const references provide mutable pointers. Previously the two functions behaved differently.
>> 
>> Changes to NMT include:
>> - Modified components to align with the updated const-correctness of the red-black tree functions
>> - Renamed structures and variables to remove "treap" from their names to reflect the new tree
>> 
>> The treap was also used in one place in C2. I changed this to use the red-black tree and its cursor interface, which I felt was most fitting for the use case.
>> 
>> Testing:
>> - Oracle tiers 1-3
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback fixes

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26655#pullrequestreview-3105279452

From snatarajan at openjdk.org  Mon Aug 11 11:17:31 2025
From: snatarajan at openjdk.org (Saranya Natarajan)
Date: Mon, 11 Aug 2025 11:17:31 GMT
Subject: RFR: 8358696: Assert with extreme values for -XX:BciProfileWidth
 [v7]
In-Reply-To: <5TRVeAXUQi6quM-nDWEij_jk6M5K2Vk31RA-Yjd8F2M=.5b63da45-93c3-4251-9e2e-3c64b7953919@github.com>
References: <5TRVeAXUQi6quM-nDWEij_jk6M5K2Vk31RA-Yjd8F2M=.5b63da45-93c3-4251-9e2e-3c64b7953919@github.com>
Message-ID: <a3A1JrsMuTkR1mYm_UjnCSL-jJk161xIYxtxIjrNW88=.51ec6516-2d72-4c51-8cfd-c8d505a7f8d2@github.com>

> **Issue**
> Extreme values for BciProfileWidth flag such as `java -XX:BciProfileWidth=-1 -version` and `java -XX:BciProfileWidth=100000 -version `results in assert failure `assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x0000772b63a7a3a0 <= 0x0000772b63b75159 <= 0x0000772b63b75158 `. This is observed in a x86 machine.
> 
> **Analysis** 
>  On debugging the issue, I found that increasing the size of the interpreter using the `InterpreterCodeSize` variable in `src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp` prevented the above mentioned assert from failing for large values of BciProfileWidth.  
> 
> **Proposal** 
> Considering the fact that larger BciProfileWidth results in slower profiling, I have proposed a range between 0 to 5000 to restrict the value for BciProfileWidth for x86 machines. This maximum value is based on modifying the `InterpreterCodeSize` variable in `src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp` using the smallest `InterpreterCodeSize` for all the architectures.  As for the lower bound, a value of -1 would be the same as 0, as this simply means  no  return bci's will be recorded in ret profile. 
> 
> **Issue in AArch64**
> Additionally running the command `java -XX:BciProfileWidth= 10000 -version` (or larger values) results in a different failure  `assert(offset_ok_for_immed(offset(), size)) failed: must be, was: 32768, 3` on an AArch64 machine.This is an issue of maximum offset for `ldr/str` in AArch64 which can be fixed using `form_address`  as mentioned in [JDK-8342736](https://bugs.openjdk.org/browse/JDK-8342736). In my preliminary fix using `form_address` on AArch64 machine. I had to modify 3 `ldr` and 1 `str` instruction (in file `src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp` at line number 926, 983, and 997). With this fix  using `form_address`, `BciProfileWidth` works for maximum of 5000 after which it crashes with`assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x0000772b63a7a3a0 <= 0x0000772b63b75159 <= 0x0000772b63b75158 `.  Without this fix `BciProfileWidth` works for a maximum value of 1300.   Currently, I have suggested to restrict the upper bound on AArch64 to 1000 instead 
 of fixing it with `form_address`. 
> 
> **Question to reviewers**
> Do you think this is a reasonable fix ?  For AArch64 do you suggest fixing using `form_address` ? If yes, do I fix it under this PR or create another one ?
> 
> **Request to port maintainers**
> @dafedafe suggested that we keep the upper bound of `BciProfileWidth` to 1000 pro...

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

  addressing review : adding vm.debug and moving a defn

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26139/files
  - new: https://git.openjdk.org/jdk/pull/26139/files/9dae3aef..60da70c6

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

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

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

From snatarajan at openjdk.org  Mon Aug 11 11:17:31 2025
From: snatarajan at openjdk.org (Saranya Natarajan)
Date: Mon, 11 Aug 2025 11:17:31 GMT
Subject: RFR: 8358696: Assert with extreme values for -XX:BciProfileWidth
 [v6]
In-Reply-To: <1QbX5WHkEdjP-unAFJ1vYaoIc9bV8zz8dA-vKZCkYn8=.8e3704ae-9490-4471-9e5c-dae44004d46f@github.com>
References: <5TRVeAXUQi6quM-nDWEij_jk6M5K2Vk31RA-Yjd8F2M=.5b63da45-93c3-4251-9e2e-3c64b7953919@github.com>
 <Nt6C65eUJqxWJAPob_5ZvNiQXZJMQK_vD_Ik9NYSCm4=.773e5f1a-a02f-4206-99d8-e8003a708cd6@github.com>
 <1QbX5WHkEdjP-unAFJ1vYaoIc9bV8zz8dA-vKZCkYn8=.8e3704ae-9490-4471-9e5c-dae44004d46f@github.com>
Message-ID: <ECYtRACv9J4K9z9CFQDAWRX7psioszU240ikVOO6RhM=.a88220a5-8ad5-4d0f-94e4-b0999e343d99@github.com>

On Mon, 11 Aug 2025 01:38:55 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Saranya Natarajan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressing review - testcase and max range is set to 1000
>
> test/hotspot/jtreg/compiler/arguments/TestBciProfileWidth.java line 28:
> 
>> 26:  * @summary Test the range defined in globals.hpp for BciProfileWidth
>> 27:  * @bug 8358696
>> 28:  * @run main/othervm -XX:BciProfileWidth=0
> 
> `BciProfileWidth` is debug only, right?

Thank you for the review. 
I have now included `@requires vm.debug`

> test/lib-test/jdk/test/whitebox/vm_flags/IntxTest.java line 41:
> 
>> 39:     private static final long COMPILE_THRESHOLD = VmFlagTest.WHITE_BOX.getIntxVMFlag("CompileThreshold");
>> 40:     private static final Long[] TESTS = {0L, 100L, (long)(Integer.MAX_VALUE>>3)*100L};
>> 41:     private static final String FLAG_DEBUG_NAME = "BinarySwitchThreshold";
> 
> Why did you move the location of the declaration?

This was an oversight. I have moved to where it was declared previously

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26139#discussion_r2266378826
PR Review Comment: https://git.openjdk.org/jdk/pull/26139#discussion_r2266384171

From snatarajan at openjdk.org  Mon Aug 11 11:20:15 2025
From: snatarajan at openjdk.org (Saranya Natarajan)
Date: Mon, 11 Aug 2025 11:20:15 GMT
Subject: RFR: 8358696: Assert with extreme values for -XX:BciProfileWidth
 [v6]
In-Reply-To: <Nt6C65eUJqxWJAPob_5ZvNiQXZJMQK_vD_Ik9NYSCm4=.773e5f1a-a02f-4206-99d8-e8003a708cd6@github.com>
References: <5TRVeAXUQi6quM-nDWEij_jk6M5K2Vk31RA-Yjd8F2M=.5b63da45-93c3-4251-9e2e-3c64b7953919@github.com>
 <Nt6C65eUJqxWJAPob_5ZvNiQXZJMQK_vD_Ik9NYSCm4=.773e5f1a-a02f-4206-99d8-e8003a708cd6@github.com>
Message-ID: <Wwdj_PsEMqXt1DnHNta4KXKpwJa7HSfUnOyld0C1Gec=.3870d0fd-c052-4333-a9b8-546346cbfb2d@github.com>

On Sat, 9 Aug 2025 15:35:00 GMT, Saranya Natarajan <snatarajan at openjdk.org> wrote:

>> **Issue**
>> Extreme values for BciProfileWidth flag such as `java -XX:BciProfileWidth=-1 -version` and `java -XX:BciProfileWidth=100000 -version `results in assert failure `assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x0000772b63a7a3a0 <= 0x0000772b63b75159 <= 0x0000772b63b75158 `. This is observed in a x86 machine.
>> 
>> **Analysis** 
>>  On debugging the issue, I found that increasing the size of the interpreter using the `InterpreterCodeSize` variable in `src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp` prevented the above mentioned assert from failing for large values of BciProfileWidth.  
>> 
>> **Proposal** 
>> Considering the fact that larger BciProfileWidth results in slower profiling, I have proposed a range between 0 to 5000 to restrict the value for BciProfileWidth for x86 machines. This maximum value is based on modifying the `InterpreterCodeSize` variable in `src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp` using the smallest `InterpreterCodeSize` for all the architectures.  As for the lower bound, a value of -1 would be the same as 0, as this simply means  no  return bci's will be recorded in ret profile. 
>> 
>> **Issue in AArch64**
>> Additionally running the command `java -XX:BciProfileWidth= 10000 -version` (or larger values) results in a different failure  `assert(offset_ok_for_immed(offset(), size)) failed: must be, was: 32768, 3` on an AArch64 machine.This is an issue of maximum offset for `ldr/str` in AArch64 which can be fixed using `form_address`  as mentioned in [JDK-8342736](https://bugs.openjdk.org/browse/JDK-8342736). In my preliminary fix using `form_address` on AArch64 machine. I had to modify 3 `ldr` and 1 `str` instruction (in file `src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp` at line number 926, 983, and 997). With this fix  using `form_address`, `BciProfileWidth` works for maximum of 5000 after which it crashes with`assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x0000772b63a7a3a0 <= 0x0000772b63b75159 <= 0x0000772b63b75158 `.  Without this fix `BciProfileWidth` works for a maximum value of 1300.   Currently, I have suggested to restrict the upper bound on AArch64 to 1000 instead
  of fixing it with `form_address`. 
>> 
>> **Question to reviewers**
>> Do you think this is a reasonable fix ?  For AArch64 do you suggest fixing using `form_address` ? If yes, do I fix it under this PR or create another one ?
>> 
>> **Request to port maintainers**
>> @dafedafe suggested that we keep the upper boun...
>
> Saranya Natarajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing review - testcase and max range is set to 1000

In the process of adding port maintainers to this PR, I by mistake added (and removed) some of them as contributor. I will update the contributor list before closing the PR. Sorry for the incovience

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

PR Comment: https://git.openjdk.org/jdk/pull/26139#issuecomment-3174300135

From mbaesken at openjdk.org  Mon Aug 11 11:58:29 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 11 Aug 2025 11:58:29 GMT
Subject: RFR: 8365240: [asan] exclude some tests when using asan enabled
 binaries
Message-ID: <nUj-L8dQTFkRUqiGgG8r_U7SAyOUmQzFHjZ1d1UMGo4=.a312b896-618c-4c4d-bd6e-881a067d17e1@github.com>

When using asan - enabled binaries, the following tests fail (on Linux x86_64).
This one uses ulimit in a way problematic with asan :
vmTestbase/nsk/jvmti/Allocate/alloc001/alloc001.java

 ```
stdout: [];
 stderr: [==19509==ERROR: AddressSanitizer failed to allocate 0xdfff0001000 (15392894357504) bytes at address 2008fff7000 (errno: 12)
==19509==ReserveShadowMemoryRange failed while trying to map 0xdfff0001000 bytes. Perhaps you're using ulimit -v

 exitValue = 134


This one seems to have rather strict memory requirements , and fails for some minimum allowed stack size settings
tools/launcher/TooSmallStackSize.java

PASSED: got expected error message with stack size of 16k
PASSED: got expected error message with stack size of 64k
Test output:
*** exitValue = 139
FAILED: VM failed to launch with minimum allowed stack size of 136k

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

Commit messages:
 - JDK-8365240

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

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

From ayang at openjdk.org  Mon Aug 11 12:14:11 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 11 Aug 2025 12:14:11 GMT
Subject: RFR: 8263476: Use reserved memory for stack guard pages [v4]
In-Reply-To: <BojYWaP10BJMEWDQYSRiMKR0cOWzMF5At9_3fwD6uUw=.becf6902-01f1-41e0-965d-18a945a6dfcf@github.com>
References: <BojYWaP10BJMEWDQYSRiMKR0cOWzMF5At9_3fwD6uUw=.becf6902-01f1-41e0-965d-18a945a6dfcf@github.com>
Message-ID: <a6EBMdqaYe-uVlisVbD3XJNRmAFVIFCZAw0V0TXI2GU=.45d3270e-17f4-4a33-8dcd-d01f9733d74c@github.com>

> Use reserved (instead of committed) memory for stack-guard-pages on linux like systems.
> 
> `os::must_commit_stack_guard_pages` uses `commit` in its name, but `commit` usually has specific meanings in OS memory context. The actual question the caller is asking is whether the caller needs to do some preparation work before marking the guard-pages as inaccessible. To avoid confusion, I changed it to "allocate". Other suggestions are welcome.
> 
> Test: ~tier1-3~ tier1-8

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

 - Merge branch 'master' into no-commit-stack-guard-page
 - review
 - review
 - Merge branch 'master' into no-commit-stack-guard-page
 - no-commit-stack-guard-page

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26571/files
  - new: https://git.openjdk.org/jdk/pull/26571/files/a248cff8..db7647fb

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

  Stats: 9769 lines in 303 files changed: 6276 ins; 2452 del; 1041 mod
  Patch: https://git.openjdk.org/jdk/pull/26571.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26571/head:pull/26571

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

From cnorrbin at openjdk.org  Mon Aug 11 12:26:18 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Mon, 11 Aug 2025 12:26:18 GMT
Subject: RFR: 8352067: Remove the NMT treap and replace its uses with the
 utilities red-black tree [v2]
In-Reply-To: <Sw5KhaC03y3T-bZa54aSCpcXwgLyDeL9h6Mzsnva0BI=.3d877982-e6bf-416a-bcdf-5ba96e5def56@github.com>
References: <xXuaevhTzxS26C6s7DR0BdSQDFPeV5cMg4_qImS_Uw4=.fa5dc831-57b2-409c-8015-ef3dbc143c65@github.com>
 <Sw5KhaC03y3T-bZa54aSCpcXwgLyDeL9h6Mzsnva0BI=.3d877982-e6bf-416a-bcdf-5ba96e5def56@github.com>
Message-ID: <FYyrOn3vFCEfdrwY5jx9evcR7r_PYVXnogdE28RrGRI=.8468ddbb-fe94-4d6a-932a-febec6e1295b@github.com>

On Wed, 6 Aug 2025 11:07:42 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> The utilities red-black tree and the NMT treap serve similar functions. Given the red-black tree's versatility and stricter time complexity, the treap can be removed in favour of it.
>> 
>> I made some modifications to the red-black tree to make it compatible with previous treap usages:
>> - Updated the `visit_in_order` and `visit_range_in_order` functions to require the supplied callback to return a bool, which allows us to stop traversing early.
>> - Improved const-correctness by ensuring that invoking these functions on a const reference provides const pointers to nodes, while non-const references provide mutable pointers. Previously the two functions behaved differently.
>> 
>> Changes to NMT include:
>> - Modified components to align with the updated const-correctness of the red-black tree functions
>> - Renamed structures and variables to remove "treap" from their names to reflect the new tree
>> 
>> The treap was also used in one place in C2. I changed this to use the red-black tree and its cursor interface, which I felt was most fitting for the use case.
>> 
>> Testing:
>> - Oracle tiers 1-3
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback fixes

Thank you for the reviews! Let's ship it :)

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

PR Comment: https://git.openjdk.org/jdk/pull/26655#issuecomment-3174530098

From cnorrbin at openjdk.org  Mon Aug 11 12:26:19 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Mon, 11 Aug 2025 12:26:19 GMT
Subject: Integrated: 8352067: Remove the NMT treap and replace its uses with
 the utilities red-black tree
In-Reply-To: <xXuaevhTzxS26C6s7DR0BdSQDFPeV5cMg4_qImS_Uw4=.fa5dc831-57b2-409c-8015-ef3dbc143c65@github.com>
References: <xXuaevhTzxS26C6s7DR0BdSQDFPeV5cMg4_qImS_Uw4=.fa5dc831-57b2-409c-8015-ef3dbc143c65@github.com>
Message-ID: <gC2jScKds85UpoReNXze8HnUUS0-5p2TycXAsYYQjFE=.dca8b59f-934e-456e-9cb9-0311b8897d57@github.com>

On Wed, 6 Aug 2025 09:29:05 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> The utilities red-black tree and the NMT treap serve similar functions. Given the red-black tree's versatility and stricter time complexity, the treap can be removed in favour of it.
> 
> I made some modifications to the red-black tree to make it compatible with previous treap usages:
> - Updated the `visit_in_order` and `visit_range_in_order` functions to require the supplied callback to return a bool, which allows us to stop traversing early.
> - Improved const-correctness by ensuring that invoking these functions on a const reference provides const pointers to nodes, while non-const references provide mutable pointers. Previously the two functions behaved differently.
> 
> Changes to NMT include:
> - Modified components to align with the updated const-correctness of the red-black tree functions
> - Renamed structures and variables to remove "treap" from their names to reflect the new tree
> 
> The treap was also used in one place in C2. I changed this to use the red-black tree and its cursor interface, which I felt was most fitting for the use case.
> 
> Testing:
> - Oracle tiers 1-3

This pull request has now been integrated.

Changeset: 0ad919c1
Author:    Casper Norrbin <cnorrbin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0ad919c1e54895b000b58f6a1b54d79f76970845
Stats:     1016 lines in 14 files changed: 124 ins; 816 del; 76 mod

8352067: Remove the NMT treap and replace its uses with the utilities red-black tree

Reviewed-by: jsjolen, ayang

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

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

From gziemski at openjdk.org  Mon Aug 11 16:09:13 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Mon, 11 Aug 2025 16:09:13 GMT
Subject: RFR: 8364280:
 NMTCommittedVirtualMemoryTracker.test_committed_virtualmemory_region_vm fails
 with assertion "negative distance" [v2]
In-Reply-To: <VSSPL-IK2_KvgBoF-CxhVmk0cPPsaXhhWZEMkXZ1DQM=.599d4c76-fe75-4bf5-b7e9-24d01feb74fe@github.com>
References: <ncwJP21-QPQNcKJoK3TF-H9quyeAZvIQ1Dh4diBQiP0=.6f7e47d8-1cfd-4ef0-a307-1828d27c444f@github.com>
 <VSSPL-IK2_KvgBoF-CxhVmk0cPPsaXhhWZEMkXZ1DQM=.599d4c76-fe75-4bf5-b7e9-24d01feb74fe@github.com>
Message-ID: <Cdj1Qx-qxP_0QH3refpInhx7XDQ8qTXFPyGx5b40s44=.212bd6e1-eb9b-46da-b5dc-c7f7af7b9de3@github.com>

On Fri, 8 Aug 2025 09:32:50 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> The VirtualMemoryTracker API uses a tree internally for tracking the memory regions and their states/info. This tree should not be changed when looking for some regions. If not synch'ed, the nodes in the tree may change meanwhile and the retrieved info are not as expected. The unit test in this PR did not synch these looking up with VMT. The corresponding lock is used to address the problem.
>> 
>> Tests:
>> local: linux-x64-debug NMTGtests
>> mach5: tiers 1-5, {macosx-aarch64, linux-x64, windows-x64} x {debug, release}
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   space added

Marked as reviewed by gziemski (Reviewer).

LGTM, thanks for fixing this!

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

PR Review: https://git.openjdk.org/jdk/pull/26689#pullrequestreview-3106607561
PR Comment: https://git.openjdk.org/jdk/pull/26689#issuecomment-3175619127

From coleenp at openjdk.org  Mon Aug 11 17:54:23 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 11 Aug 2025 17:54:23 GMT
Subject: RFR: 8364750: Remove unused declaration in jvm.cpp
Message-ID: <kmSkNYke2ZVgD59HLfAy6Mg8nrH71nLPHIyXm-57NJ0=.20304694-3dfa-4d69-bd86-6586e808d8b7@github.com>

Please review this trivial change to remove the declaration of the native JVM function that I removed in [JDK-8364187](https://bugs.openjdk.org/browse/JDK-8364187).
Tested with tier1 on Oracle supported platforms as sanity test (in progress).

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

Commit messages:
 - 8364750: Remove unused declaration in jvm.cpp

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

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

From liach at openjdk.org  Mon Aug 11 18:20:11 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 11 Aug 2025 18:20:11 GMT
Subject: RFR: 8364750: Remove unused declaration in jvm.cpp
In-Reply-To: <kmSkNYke2ZVgD59HLfAy6Mg8nrH71nLPHIyXm-57NJ0=.20304694-3dfa-4d69-bd86-6586e808d8b7@github.com>
References: <kmSkNYke2ZVgD59HLfAy6Mg8nrH71nLPHIyXm-57NJ0=.20304694-3dfa-4d69-bd86-6586e808d8b7@github.com>
Message-ID: <igrELleOTS5-j2jwEjiDVA9A_0CHINdLGOqa-FDBYOI=.16d384e9-49a2-4da1-aa4c-5f29a8e3fcdb@github.com>

On Mon, 11 Aug 2025 17:49:15 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this trivial change to remove the declaration of the native JVM function that I removed in [JDK-8364187](https://bugs.openjdk.org/browse/JDK-8364187).
> Tested with tier1 on Oracle supported platforms as sanity test (in progress).

Shouldn't the title mention `jvm.h` instead of `jvm.cpp`?

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

PR Comment: https://git.openjdk.org/jdk/pull/26732#issuecomment-3176261254

From shade at openjdk.org  Mon Aug 11 18:51:17 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 11 Aug 2025 18:51:17 GMT
Subject: RFR: 8364750: Remove unused declaration in jvm.cpp
In-Reply-To: <kmSkNYke2ZVgD59HLfAy6Mg8nrH71nLPHIyXm-57NJ0=.20304694-3dfa-4d69-bd86-6586e808d8b7@github.com>
References: <kmSkNYke2ZVgD59HLfAy6Mg8nrH71nLPHIyXm-57NJ0=.20304694-3dfa-4d69-bd86-6586e808d8b7@github.com>
Message-ID: <j4pEqTgsq_KNJSx3tIV0O4ZK_qk20f1NtI5EApqYUXs=.e45a5224-dffe-4175-8c43-2629e943ddf1@github.com>

On Mon, 11 Aug 2025 17:49:15 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this trivial change to remove the declaration of the native JVM function that I removed in [JDK-8364187](https://bugs.openjdk.org/browse/JDK-8364187).
> Tested with tier1 on Oracle supported platforms as sanity test (in progress).

Looks fine and trivial.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26732#pullrequestreview-3107226198

From lmesnik at openjdk.org  Mon Aug 11 19:42:13 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 11 Aug 2025 19:42:13 GMT
Subject: RFR: 8365240: [asan] exclude some tests when using asan enabled
 binaries
In-Reply-To: <nUj-L8dQTFkRUqiGgG8r_U7SAyOUmQzFHjZ1d1UMGo4=.a312b896-618c-4c4d-bd6e-881a067d17e1@github.com>
References: <nUj-L8dQTFkRUqiGgG8r_U7SAyOUmQzFHjZ1d1UMGo4=.a312b896-618c-4c4d-bd6e-881a067d17e1@github.com>
Message-ID: <MDTaRBhA3Sm7TH8B647RYyPhjUqq4KEpltnW78YHvwY=.bb4124b3-0674-4c59-818d-675f7bfd994e@github.com>

On Mon, 11 Aug 2025 11:52:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When using asan - enabled binaries, the following tests fail (on Linux x86_64).
> This one uses ulimit in a way problematic with asan :
> vmTestbase/nsk/jvmti/Allocate/alloc001/alloc001.java
> 
>  ```
> stdout: [];
>  stderr: [==19509==ERROR: AddressSanitizer failed to allocate 0xdfff0001000 (15392894357504) bytes at address 2008fff7000 (errno: 12)
> ==19509==ReserveShadowMemoryRange failed while trying to map 0xdfff0001000 bytes. Perhaps you're using ulimit -v
> 
>  exitValue = 134
> 
> 
> This one seems to have rather strict memory requirements , and fails for some minimum allowed stack size settings
> tools/launcher/TooSmallStackSize.java
> 
> PASSED: got expected error message with stack size of 16k
> PASSED: got expected error message with stack size of 64k
> Test output:
> *** exitValue = 139
> FAILED: VM failed to launch with minimum allowed stack size of 136k

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26725#pullrequestreview-3107524814

From sspitsyn at openjdk.org  Tue Aug 12 03:43:09 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 12 Aug 2025 03:43:09 GMT
Subject: RFR: 8365240: [asan] exclude some tests when using asan enabled
 binaries
In-Reply-To: <nUj-L8dQTFkRUqiGgG8r_U7SAyOUmQzFHjZ1d1UMGo4=.a312b896-618c-4c4d-bd6e-881a067d17e1@github.com>
References: <nUj-L8dQTFkRUqiGgG8r_U7SAyOUmQzFHjZ1d1UMGo4=.a312b896-618c-4c4d-bd6e-881a067d17e1@github.com>
Message-ID: <5-h_mFm-MT1hN0eyE3LIlssveIKitDmFBf0iDrke7Es=.6c480926-9735-4bbf-822b-d65f8f40d9d3@github.com>

On Mon, 11 Aug 2025 11:52:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When using asan - enabled binaries, the following tests fail (on Linux x86_64).
> This one uses ulimit in a way problematic with asan :
> vmTestbase/nsk/jvmti/Allocate/alloc001/alloc001.java
> 
>  ```
> stdout: [];
>  stderr: [==19509==ERROR: AddressSanitizer failed to allocate 0xdfff0001000 (15392894357504) bytes at address 2008fff7000 (errno: 12)
> ==19509==ReserveShadowMemoryRange failed while trying to map 0xdfff0001000 bytes. Perhaps you're using ulimit -v
> 
>  exitValue = 134
> 
> 
> This one seems to have rather strict memory requirements , and fails for some minimum allowed stack size settings
> tools/launcher/TooSmallStackSize.java
> 
> PASSED: got expected error message with stack size of 16k
> PASSED: got expected error message with stack size of 64k
> Test output:
> *** exitValue = 139
> FAILED: VM failed to launch with minimum allowed stack size of 136k

Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26725#pullrequestreview-3108442923

From mbaesken at openjdk.org  Tue Aug 12 07:20:17 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 12 Aug 2025 07:20:17 GMT
Subject: RFR: 8365240: [asan] exclude some tests when using asan enabled
 binaries
In-Reply-To: <nUj-L8dQTFkRUqiGgG8r_U7SAyOUmQzFHjZ1d1UMGo4=.a312b896-618c-4c4d-bd6e-881a067d17e1@github.com>
References: <nUj-L8dQTFkRUqiGgG8r_U7SAyOUmQzFHjZ1d1UMGo4=.a312b896-618c-4c4d-bd6e-881a067d17e1@github.com>
Message-ID: <afhwH3pzzKafxrmAwvVMjyXrbofPKc2M4NlBL9VMghI=.ee16b736-6164-4e8d-bb4f-a7143cb6b325@github.com>

On Mon, 11 Aug 2025 11:52:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When using asan - enabled binaries, the following tests fail (on Linux x86_64).
> This one uses ulimit in a way problematic with asan :
> vmTestbase/nsk/jvmti/Allocate/alloc001/alloc001.java
> 
>  ```
> stdout: [];
>  stderr: [==19509==ERROR: AddressSanitizer failed to allocate 0xdfff0001000 (15392894357504) bytes at address 2008fff7000 (errno: 12)
> ==19509==ReserveShadowMemoryRange failed while trying to map 0xdfff0001000 bytes. Perhaps you're using ulimit -v
> 
>  exitValue = 134
> 
> 
> This one seems to have rather strict memory requirements , and fails for some minimum allowed stack size settings
> tools/launcher/TooSmallStackSize.java
> 
> PASSED: got expected error message with stack size of 16k
> PASSED: got expected error message with stack size of 64k
> Test output:
> *** exitValue = 139
> FAILED: VM failed to launch with minimum allowed stack size of 136k

Thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/26725#issuecomment-3178007009

From mbaesken at openjdk.org  Tue Aug 12 07:20:17 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 12 Aug 2025 07:20:17 GMT
Subject: Integrated: 8365240: [asan] exclude some tests when using asan enabled
 binaries
In-Reply-To: <nUj-L8dQTFkRUqiGgG8r_U7SAyOUmQzFHjZ1d1UMGo4=.a312b896-618c-4c4d-bd6e-881a067d17e1@github.com>
References: <nUj-L8dQTFkRUqiGgG8r_U7SAyOUmQzFHjZ1d1UMGo4=.a312b896-618c-4c4d-bd6e-881a067d17e1@github.com>
Message-ID: <AVTBCNs7xSKFFFJVQa31cO3Hr62OkNNGfd0k7Vx0hyk=.1031daa7-66af-4975-91d3-1f2c029ea537@github.com>

On Mon, 11 Aug 2025 11:52:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When using asan - enabled binaries, the following tests fail (on Linux x86_64).
> This one uses ulimit in a way problematic with asan :
> vmTestbase/nsk/jvmti/Allocate/alloc001/alloc001.java
> 
>  ```
> stdout: [];
>  stderr: [==19509==ERROR: AddressSanitizer failed to allocate 0xdfff0001000 (15392894357504) bytes at address 2008fff7000 (errno: 12)
> ==19509==ReserveShadowMemoryRange failed while trying to map 0xdfff0001000 bytes. Perhaps you're using ulimit -v
> 
>  exitValue = 134
> 
> 
> This one seems to have rather strict memory requirements , and fails for some minimum allowed stack size settings
> tools/launcher/TooSmallStackSize.java
> 
> PASSED: got expected error message with stack size of 16k
> PASSED: got expected error message with stack size of 64k
> Test output:
> *** exitValue = 139
> FAILED: VM failed to launch with minimum allowed stack size of 136k

This pull request has now been integrated.

Changeset: d78fa5a9
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d78fa5a9f6254e2e93e75c693efba75e09736749
Stats:     6 lines in 2 files changed: 4 ins; 0 del; 2 mod

8365240: [asan] exclude some tests when using asan enabled binaries

Reviewed-by: lmesnik, sspitsyn

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

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

From thartmann at openjdk.org  Tue Aug 12 07:30:14 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 12 Aug 2025 07:30:14 GMT
Subject: RFR: 8358696: Assert with extreme values for -XX:BciProfileWidth
 [v7]
In-Reply-To: <a3A1JrsMuTkR1mYm_UjnCSL-jJk161xIYxtxIjrNW88=.51ec6516-2d72-4c51-8cfd-c8d505a7f8d2@github.com>
References: <5TRVeAXUQi6quM-nDWEij_jk6M5K2Vk31RA-Yjd8F2M=.5b63da45-93c3-4251-9e2e-3c64b7953919@github.com>
 <a3A1JrsMuTkR1mYm_UjnCSL-jJk161xIYxtxIjrNW88=.51ec6516-2d72-4c51-8cfd-c8d505a7f8d2@github.com>
Message-ID: <EyRs3jpd81NTAwzGKu4QMa08HeuMJLZLSFC1TO0MBpo=.033d96bd-e0cb-4313-a903-93f7e970f0d4@github.com>

On Mon, 11 Aug 2025 11:17:31 GMT, Saranya Natarajan <snatarajan at openjdk.org> wrote:

>> **Issue**
>> Extreme values for BciProfileWidth flag such as `java -XX:BciProfileWidth=-1 -version` and `java -XX:BciProfileWidth=100000 -version `results in assert failure `assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x0000772b63a7a3a0 <= 0x0000772b63b75159 <= 0x0000772b63b75158 `. This is observed in a x86 machine.
>> 
>> **Analysis** 
>>  On debugging the issue, I found that increasing the size of the interpreter using the `InterpreterCodeSize` variable in `src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp` prevented the above mentioned assert from failing for large values of BciProfileWidth.  
>> 
>> **Proposal** 
>> Considering the fact that larger BciProfileWidth results in slower profiling, I have proposed a range between 0 to 5000 to restrict the value for BciProfileWidth for x86 machines. This maximum value is based on modifying the `InterpreterCodeSize` variable in `src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp` using the smallest `InterpreterCodeSize` for all the architectures.  As for the lower bound, a value of -1 would be the same as 0, as this simply means  no  return bci's will be recorded in ret profile. 
>> 
>> **Issue in AArch64**
>> Additionally running the command `java -XX:BciProfileWidth= 10000 -version` (or larger values) results in a different failure  `assert(offset_ok_for_immed(offset(), size)) failed: must be, was: 32768, 3` on an AArch64 machine.This is an issue of maximum offset for `ldr/str` in AArch64 which can be fixed using `form_address`  as mentioned in [JDK-8342736](https://bugs.openjdk.org/browse/JDK-8342736). In my preliminary fix using `form_address` on AArch64 machine. I had to modify 3 `ldr` and 1 `str` instruction (in file `src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp` at line number 926, 983, and 997). With this fix  using `form_address`, `BciProfileWidth` works for maximum of 5000 after which it crashes with`assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x0000772b63a7a3a0 <= 0x0000772b63b75159 <= 0x0000772b63b75158 `.  Without this fix `BciProfileWidth` works for a maximum value of 1300.   Currently, I have suggested to restrict the upper bound on AArch64 to 1000 instead
  of fixing it with `form_address`. 
>> 
>> **Question to reviewers**
>> Do you think this is a reasonable fix ?  For AArch64 do you suggest fixing using `form_address` ? If yes, do I fix it under this PR or create another one ?
>> 
>> **Request to port maintainers**
>> @dafedafe suggested that we keep the upper boun...
>
> Saranya Natarajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressing review : adding vm.debug and moving a defn

Looks good to me.

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

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26139#pullrequestreview-3108965837

From azafari at openjdk.org  Tue Aug 12 08:06:17 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 12 Aug 2025 08:06:17 GMT
Subject: RFR: 8364280:
 NMTCommittedVirtualMemoryTracker.test_committed_virtualmemory_region_vm fails
 with assertion "negative distance" [v2]
In-Reply-To: <OXsSAFEfaq3XkwK_4ngJ0Ecn37POro6QJBfFjJcV5ao=.b2dfeaab-44ba-403a-a99c-044e361e5c52@github.com>
References: <ncwJP21-QPQNcKJoK3TF-H9quyeAZvIQ1Dh4diBQiP0=.6f7e47d8-1cfd-4ef0-a307-1828d27c444f@github.com>
 <OXsSAFEfaq3XkwK_4ngJ0Ecn37POro6QJBfFjJcV5ao=.b2dfeaab-44ba-403a-a99c-044e361e5c52@github.com>
Message-ID: <bH0HxElBTBcxe7MCIB6NuT5ZJ4aAAHL_OHEfKbo6d0w=.2463c553-5e73-4270-bd61-e285818e65f2@github.com>

On Fri, 8 Aug 2025 09:09:15 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   space added
>
> Marked as reviewed by jsjolen (Reviewer).

Thank you @jdksjolen and @gerard-ziemski for your reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/26689#issuecomment-3178181427

From azafari at openjdk.org  Tue Aug 12 08:06:18 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 12 Aug 2025 08:06:18 GMT
Subject: Integrated: 8364280:
 NMTCommittedVirtualMemoryTracker.test_committed_virtualmemory_region_vm fails
 with assertion "negative distance"
In-Reply-To: <ncwJP21-QPQNcKJoK3TF-H9quyeAZvIQ1Dh4diBQiP0=.6f7e47d8-1cfd-4ef0-a307-1828d27c444f@github.com>
References: <ncwJP21-QPQNcKJoK3TF-H9quyeAZvIQ1Dh4diBQiP0=.6f7e47d8-1cfd-4ef0-a307-1828d27c444f@github.com>
Message-ID: <64Dtwm1rprTTBxvzhDB64m5kCOec_LyaNWzzvt5Lbzw=.9f9f43a3-8082-4bb8-8aa8-59e07bd1b2c9@github.com>

On Fri, 8 Aug 2025 08:52:48 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> The VirtualMemoryTracker API uses a tree internally for tracking the memory regions and their states/info. This tree should not be changed when looking for some regions. If not synch'ed, the nodes in the tree may change meanwhile and the retrieved info are not as expected. The unit test in this PR did not synch these looking up with VMT. The corresponding lock is used to address the problem.
> 
> Tests:
> local: linux-x64-debug NMTGtests
> mach5: tiers 1-5, {macosx-aarch64, linux-x64, windows-x64} x {debug, release}

This pull request has now been integrated.

Changeset: db12f193
Author:    Afshin Zafari <azafari at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/db12f1934a659843d9cc77f4f21e67ebf9fa94e6
Stats:     21 lines in 1 file changed: 8 ins; 0 del; 13 mod

8364280: NMTCommittedVirtualMemoryTracker.test_committed_virtualmemory_region_vm fails with assertion "negative distance"

Reviewed-by: gziemski, jsjolen

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

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

From fyang at openjdk.org  Tue Aug 12 08:16:13 2025
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 12 Aug 2025 08:16:13 GMT
Subject: RFR: 8358696: Assert with extreme values for -XX:BciProfileWidth
 [v6]
In-Reply-To: <Wwdj_PsEMqXt1DnHNta4KXKpwJa7HSfUnOyld0C1Gec=.3870d0fd-c052-4333-a9b8-546346cbfb2d@github.com>
References: <5TRVeAXUQi6quM-nDWEij_jk6M5K2Vk31RA-Yjd8F2M=.5b63da45-93c3-4251-9e2e-3c64b7953919@github.com>
 <Nt6C65eUJqxWJAPob_5ZvNiQXZJMQK_vD_Ik9NYSCm4=.773e5f1a-a02f-4206-99d8-e8003a708cd6@github.com>
 <Wwdj_PsEMqXt1DnHNta4KXKpwJa7HSfUnOyld0C1Gec=.3870d0fd-c052-4333-a9b8-546346cbfb2d@github.com>
Message-ID: <gYopfBIfEjXccjL5pfV14A-j1De9lnJZjpY3-HzOzRg=.1f0afb69-ffea-4c0e-8300-dc4ae89caa62@github.com>

On Mon, 11 Aug 2025 11:17:13 GMT, Saranya Natarajan <snatarajan at openjdk.org> wrote:

>> Saranya Natarajan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressing review - testcase and max range is set to 1000
>
> In the process of adding port maintainers to this PR, I by mistake added (and removed) some of them as contributor. I will update the contributor list before closing the PR. Sorry for the inconvenience

@sarannat : Hi, Thanks for the ping!
I just tried the newly-added test on linux-riscv64 and I think we still need some extra change for this platform.
Do you mind adding that in this PR? I see the test pass with this addon change when running with fastdebug build.
[riscv-addon-fix.diff.txt](https://github.com/user-attachments/files/21729910/riscv-addon-fix.diff.txt)

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

PR Comment: https://git.openjdk.org/jdk/pull/26139#issuecomment-3178215604

From fbredberg at openjdk.org  Tue Aug 12 08:45:12 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Tue, 12 Aug 2025 08:45:12 GMT
Subject: RFR: 8364141: Remove LockingMode related code from x86 [v4]
In-Reply-To: <wQPBsXlKAZtaZlcTLSgISHvII9vOIewNNoNW5cjBTW4=.9c3ffca2-7656-40ae-b6f5-5f7a9fc6151c@github.com>
References: <g7WNqmFlJOkai-zeEjD09M5TwpL3fAMkZUAy37b747U=.faa6d9f5-1894-4507-a0f1-1dd41f3bdd43@github.com>
 <wQPBsXlKAZtaZlcTLSgISHvII9vOIewNNoNW5cjBTW4=.9c3ffca2-7656-40ae-b6f5-5f7a9fc6151c@github.com>
Message-ID: <P0eMQ261YArG0ctxcpMf-JVivBoffeiv3Le-0ohb5ZQ=.b5dd4235-d91f-4e7b-b098-b9f1cacf7f8f@github.com>

On Thu, 7 Aug 2025 09:23:37 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
>> 
>> This PR removes `LockingMode` related code from the **x86** platform.
>> 
>> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.
>> 
>> Passes tier1-tier5 with no added problems.
>
> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update three after review

Thanks everyone for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/26552#issuecomment-3178335696

From fbredberg at openjdk.org  Tue Aug 12 08:48:18 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Tue, 12 Aug 2025 08:48:18 GMT
Subject: RFR: 8364406: Remove LockingMode related code from aarch64
In-Reply-To: <YgHBd1bQAjTri-T6bu_WxnTz606-Wijg995KPVcbao0=.beb80bbe-9ff5-4c05-9ccc-a8e47519542a@github.com>
References: <YgHBd1bQAjTri-T6bu_WxnTz606-Wijg995KPVcbao0=.beb80bbe-9ff5-4c05-9ccc-a8e47519542a@github.com>
Message-ID: <8-OSwSabj00wZd5J044h-vaKQ0IiCfbiqPlnN3UduQ8=.1184bdd4-8e5a-44d0-85b1-e8beab9431aa@github.com>

On Fri, 1 Aug 2025 11:22:50 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
> 
> This PR removes `LockingMode` related code from the **aarch64** platform.
> 
> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.
> 
> Passes tier1-tier5 with no added problems.

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/26594#issuecomment-3178337536

From fbredberg at openjdk.org  Tue Aug 12 08:48:22 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Tue, 12 Aug 2025 08:48:22 GMT
Subject: Integrated: 8364141: Remove LockingMode related code from x86
In-Reply-To: <g7WNqmFlJOkai-zeEjD09M5TwpL3fAMkZUAy37b747U=.faa6d9f5-1894-4507-a0f1-1dd41f3bdd43@github.com>
References: <g7WNqmFlJOkai-zeEjD09M5TwpL3fAMkZUAy37b747U=.faa6d9f5-1894-4507-a0f1-1dd41f3bdd43@github.com>
Message-ID: <rszbS5VMRtaruQCzDil_gBlWitTN-9lbG1lQapJH8SY=.e5248ba2-99ef-4352-9b50-0467e9afcc3b@github.com>

On Wed, 30 Jul 2025 13:17:37 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
> 
> This PR removes `LockingMode` related code from the **x86** platform.
> 
> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.
> 
> Passes tier1-tier5 with no added problems.

This pull request has now been integrated.

Changeset: f155f7d6
Author:    Fredrik Bredberg <fbredberg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f155f7d6e50c702f65858774cfd02ef60aa9cad5
Stats:     639 lines in 10 files changed: 37 ins; 546 del; 56 mod

8364141: Remove LockingMode related code from x86

Reviewed-by: aboldtch, dholmes, coleenp

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

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

From fbredberg at openjdk.org  Tue Aug 12 08:48:19 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Tue, 12 Aug 2025 08:48:19 GMT
Subject: Integrated: 8364406: Remove LockingMode related code from aarch64
In-Reply-To: <YgHBd1bQAjTri-T6bu_WxnTz606-Wijg995KPVcbao0=.beb80bbe-9ff5-4c05-9ccc-a8e47519542a@github.com>
References: <YgHBd1bQAjTri-T6bu_WxnTz606-Wijg995KPVcbao0=.beb80bbe-9ff5-4c05-9ccc-a8e47519542a@github.com>
Message-ID: <9VlvJFTdM-aeA_9bGxEwqr-v9ev82cS4p5yP_tf3KCk=.6749ae77-73db-485b-86c8-dcc9929e837f@github.com>

On Fri, 1 Aug 2025 11:22:50 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
> 
> This PR removes `LockingMode` related code from the **aarch64** platform.
> 
> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.
> 
> Passes tier1-tier5 with no added problems.

This pull request has now been integrated.

Changeset: 3c0eed8e
Author:    Fredrik Bredberg <fbredberg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3c0eed8e476e4da540e4ea44ee966f278e04a067
Stats:     577 lines in 9 files changed: 10 ins; 521 del; 46 mod

8364406: Remove LockingMode related code from aarch64

Reviewed-by: aph, dholmes

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

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

From fbredberg at openjdk.org  Tue Aug 12 10:02:09 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Tue, 12 Aug 2025 10:02:09 GMT
Subject: RFR: 8364570: Remove LockingMode related code from riscv64 [v3]
In-Reply-To: <TGtRFC9NpLCnaqcLtmFttGpJIHOWxXdUB4PZHfhSHoA=.0fb2f13f-f42b-4804-804e-9b24422a08c9@github.com>
References: <TGtRFC9NpLCnaqcLtmFttGpJIHOWxXdUB4PZHfhSHoA=.0fb2f13f-f42b-4804-804e-9b24422a08c9@github.com>
Message-ID: <3sChOPKIk2-UqhUj4pWjToLW4rZhe-Xwx2qrJpwh8-s=.11ca8338-38bd-428a-ae2d-d962be6fdc67@github.com>

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
> 
> This PR removes `LockingMode` related code from the **riscv64** platform.
> 
> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.

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

 - Merge branch 'master' into 8364570_remove_lockingmode_riscv64
 - Update two after review
 - Update one after review
 - 8364570: Remove LockingMode related code from riscv64

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26658/files
  - new: https://git.openjdk.org/jdk/pull/26658/files/a32ae39e..0b244704

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

  Stats: 26689 lines in 690 files changed: 16193 ins; 8269 del; 2227 mod
  Patch: https://git.openjdk.org/jdk/pull/26658.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26658/head:pull/26658

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

From fbredberg at openjdk.org  Tue Aug 12 10:02:17 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Tue, 12 Aug 2025 10:02:17 GMT
Subject: RFR: 8364570: Remove LockingMode related code from riscv64 [v2]
In-Reply-To: <CHAT2yULFGB8mG8t1EJQCrGMc7uN-ViJd25bQPbglqw=.69579f21-3b68-43aa-aee8-815f7a609e2d@github.com>
References: <TGtRFC9NpLCnaqcLtmFttGpJIHOWxXdUB4PZHfhSHoA=.0fb2f13f-f42b-4804-804e-9b24422a08c9@github.com>
 <qdApfimrKQlpcftHKqLBMrjnp4GkfBp9BS_KUfrUlO8=.db97e135-af97-4a2c-aba9-6eb454798425@github.com>
 <CHAT2yULFGB8mG8t1EJQCrGMc7uN-ViJd25bQPbglqw=.69579f21-3b68-43aa-aee8-815f7a609e2d@github.com>
Message-ID: <Bce-qJ1eHKUQRzS4873R3D-CatrCM3y8-KYEisfmS-k=.2e3e9e32-53da-42ed-ae6b-49eb6f84e576@github.com>

On Sun, 10 Aug 2025 08:28:39 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update one after review
>
> src/hotspot/cpu/riscv/interp_masm_riscv.cpp line 743:
> 
>> 741:   const Register tmp3 = c_rarg5;
>> 742: 
>> 743:   Label slow_case;
> 
> Nit: Maybe declare the two Labels `done` and `slow_case` on the same line.
> `Label slow_case, done;`

Fixed

> src/hotspot/cpu/riscv/interp_masm_riscv.cpp line 745:
> 
>> 743:   Label slow_case;
>> 744: 
>> 745:   // Load object pointer into obj_reg c_rarg3
> 
> Suggestion: `// Load object pointer into obj_reg (c_rarg3)`

Fixed

> src/hotspot/cpu/riscv/interp_masm_riscv.cpp line 785:
> 
>> 783:   save_bcp(); // Save in case of exception
>> 784: 
>> 785:   // Load oop into obj_reg(c_rarg3)
> 
> Suggestion: `// Load oop into obj_reg (c_rarg3)`

Fixed

> src/hotspot/cpu/riscv/interp_masm_riscv.cpp line 791:
> 
>> 789:   sd(zr, Address(lock_reg, BasicObjectLock::obj_offset()));
>> 790: 
>> 791:   Label slow_case;
> 
> Similar here. We can declare the two Labels `done` and `slow_case` on the same line.

Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26658#discussion_r2269335286
PR Review Comment: https://git.openjdk.org/jdk/pull/26658#discussion_r2269336505
PR Review Comment: https://git.openjdk.org/jdk/pull/26658#discussion_r2269336934
PR Review Comment: https://git.openjdk.org/jdk/pull/26658#discussion_r2269335881

From gziemski at openjdk.org  Tue Aug 12 10:51:13 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 12 Aug 2025 10:51:13 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v2]
In-Reply-To: <8-K1wPHmyNI27RRTsvvuUdQJmt44m5QDr6cyt9hhLXQ=.ee86ccc9-839f-4af9-90eb-5d3a46b66ccf@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
 <8-K1wPHmyNI27RRTsvvuUdQJmt44m5QDr6cyt9hhLXQ=.ee86ccc9-839f-4af9-90eb-5d3a46b66ccf@github.com>
Message-ID: <RRnq_S05Y0vnE985bhgi3893QGFmeLC8h6aC1psnzKk=.45f910c0-c361-4c33-95c7-8e80fdfe30f5@github.com>

On Wed, 18 Jun 2025 16:40:53 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Hi all,
>> 
>> I would like to propose a fix for JDK-8319589. This will allow jcmd and jps running as root to get the complete list of JVMs running by all users, and to attach from root to non-root JVMs. Previously, JDK-8197387 introduced the same approach on Linux.
>> 
>> This change affects macOS, that uses "secure" per-user temporary directories. It only affects JVMs running as root, the behavior in non-privileged JVMs remains unchanged.
>> 
>> Jcmd and jps rely on LocalVmManager to get the initial list of the local VMs. The LocalVmManager uses sun.jvmstat.PlatformSupport to get the list of temp directories, where it searches for user's PerfData directory such as "hsperfdata_<username\>". In macosx the temp directories are per-user, the temp path is returned by confstr(_CS_DARWIN_USER_TEMP_DIR). The per-user directories are mode 700 and so they are read-protected from non-privileged users and can be accessed by the owner and the root.
>> 
>> Both jps and jcmd (HotSpotAttachProvider) create MonitoredVm objects, that have PerfDataBuffer that performs attachment to the target. Only the attachable VMs are listed in jcmd output.
>> 
>> The proposed patch changes the list of directories returned by the PlatformSupport#getTemporaryDirectories() in VMs running as root. The list is later used in VirtualMachineImpl (jdk.attach). It changes also the way mmap_attach_shared() searches for hsperfdata_<username\>/<pid\> files to map the shared memory. Mmap_attach_shared() and VirtualMachineImpl (via PlatformSupport) list the content of /var/folders, where the temp directories are located, more specificly the temp directories are /var/folders/<BUCKET\>/<ENCODED_UUID_UID\>/T as hinted in [1]. The full list is returned by newly added PlatformSupportImpl#getTemporaryDirectories().
>> 
>> The attaching client's VirtualMachineImpl needs the target process's temp directory to find .java<pid\> and create .attach<pid\> files. It uses the list returned by PlatformSupportImpl#getTemporaryDirectories() and the ProcessHandle of the target process to search for user's PerfData directory, e.g. hsperfdata_<username\>, which is in the target process's temp directory, exactly where it expects to see the .java<pid\> in return on sending SIGQUIT to the target VM.
>> 
>> Mmap_attach_shared() traverses the /var/folders in get_user_tmp_dir() and looks for a hsperfdata_<username\> folder. If that folder is found in /var/folders/*/*/T, that means the temp folder corresponds to the <username\> and to the ...
>
> Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - addressed review comments

Taking a look...

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

PR Comment: https://git.openjdk.org/jdk/pull/25824#issuecomment-3178801354

From fyang at openjdk.org  Tue Aug 12 11:01:14 2025
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 12 Aug 2025 11:01:14 GMT
Subject: RFR: 8364570: Remove LockingMode related code from riscv64 [v3]
In-Reply-To: <3sChOPKIk2-UqhUj4pWjToLW4rZhe-Xwx2qrJpwh8-s=.11ca8338-38bd-428a-ae2d-d962be6fdc67@github.com>
References: <TGtRFC9NpLCnaqcLtmFttGpJIHOWxXdUB4PZHfhSHoA=.0fb2f13f-f42b-4804-804e-9b24422a08c9@github.com>
 <3sChOPKIk2-UqhUj4pWjToLW4rZhe-Xwx2qrJpwh8-s=.11ca8338-38bd-428a-ae2d-d962be6fdc67@github.com>
Message-ID: <KeTwQnOFpXoqiByXC6MsbjRtZkO4mPtAn8hI753bb-k=.cba8e133-8099-4be7-b9e4-f0a4ec351999@github.com>

On Tue, 12 Aug 2025 10:02:09 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
>> 
>> This PR removes `LockingMode` related code from the **riscv64** platform.
>> 
>> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.
>
> Fredrik Bredberg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into 8364570_remove_lockingmode_riscv64
>  - Update two after review
>  - Update one after review
>  - 8364570: Remove LockingMode related code from riscv64

Still good to me. Thanks.

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

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26658#pullrequestreview-3109912066

From ayang at openjdk.org  Tue Aug 12 11:56:19 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 12 Aug 2025 11:56:19 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v4]
In-Reply-To: <SQ8LQ9lyCClcWIdoXPpcU9PDASmtEatIx3HGBj7kmdA=.306a44c4-4d49-4984-88d4-daf6e8c2a232@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <SQ8LQ9lyCClcWIdoXPpcU9PDASmtEatIx3HGBj7kmdA=.306a44c4-4d49-4984-88d4-daf6e8c2a232@github.com>
Message-ID: <yb3cFaOVf6zr2BJmWU7JElmWaPuGMULPl5mbj6cP97I=.c47904be-f8b4-4b3c-839e-f7b5dc9a9369@github.com>

On Thu, 7 Aug 2025 09:49:12 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110).
>> 
>> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports:
>> 
>> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup()
>> 
>> CPUTimeUsage::GC::gc_threads()
>> CPUTimeUsage::GC::vm_thread()
>> CPUTimeUsage::GC::stringdedup()
>> 
>> CPUTimeUsage::Runtime::vm_thread()
>> 
>> 
>> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC.
>> 
>> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table:
>> 
>> 
>> [71.425s][info][cpu   ] === CPU time Statistics =============================================================
>> [71.425s][info][cpu   ]                                                                             CPUs
>> [71.425s][info][cpu   ]                                                                s       %  utilized
>> [71.425s][info][cpu   ]    Process
>> [71.425s][info][cpu   ]      Total                                             1616.3627  100.00      22.6
>> [71.425s][info][cpu   ]      VM Thread                                            5.2992    0.33       0.1
>> [71.425s][info][cpu   ]      Garbage Collection                                  83.7322    5.18       1.2
>> [71.425s][info][cpu   ]        GC Threads                                        82.7671    5.12       1.2
>> [71.425s][info][cpu   ]        VM Thread                                          0.9651    0.06       0.0
>> [71.425s][info][cpu   ] =====================================================================================
>> 
>> 
>> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve robustness

src/hotspot/os/linux/os_linux.cpp line 4953:

> 4951:       // to detach itself from the VM - which should result in ESRCH.
> 4952:       assert_status(rc == ESRCH, rc, "pthread_getcpuclockid failed");
> 4953:       log_warning(os)("Could not sample thread CPU time");

Maybe diff msgs can be printed so that we know better what went wrong if `-1` is returned.

src/hotspot/share/gc/shared/collectedHeap.cpp line 610:

> 608: }
> 609: 
> 610: double calc_usage(double component_cpu_time, double process_cpu_time) {

Could `percent_of` be used instead?

src/hotspot/share/gc/shared/collectedHeap.cpp line 627:

> 625: 
> 626:   LogTarget(Info, cpu) cpuLog;
> 627:   if (cpuLog.is_enabled()) {

Can use early-return to reduce one indentation level.

src/hotspot/share/gc/shared/collectedHeap.hpp line 468:

> 466:   virtual void gc_threads_do(ThreadClosure* tc) const = 0;
> 467: 
> 468:   jlong elapsed_gc_cpu_time() const;

Seems unused.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2269575257
PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2269582730
PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2269586175
PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2269589768

From duke at openjdk.org  Tue Aug 12 12:24:35 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Tue, 12 Aug 2025 12:24:35 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v5]
In-Reply-To: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
Message-ID: <R5zawVwQKoUQAUOiGxy3bXsLJ8uuxU21AztKMu4hkhM=.0360b18b-0046-4491-a550-4c6b6fd75334@github.com>

> Hi all,
> 
> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110).
> 
> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports:
> 
> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup()
> 
> CPUTimeUsage::GC::gc_threads()
> CPUTimeUsage::GC::vm_thread()
> CPUTimeUsage::GC::stringdedup()
> 
> CPUTimeUsage::Runtime::vm_thread()
> 
> 
> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC.
> 
> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table:
> 
> 
> [71.425s][info][cpu   ] === CPU time Statistics =============================================================
> [71.425s][info][cpu   ]                                                                             CPUs
> [71.425s][info][cpu   ]                                                                s       %  utilized
> [71.425s][info][cpu   ]    Process
> [71.425s][info][cpu   ]      Total                                             1616.3627  100.00      22.6
> [71.425s][info][cpu   ]      VM Thread                                            5.2992    0.33       0.1
> [71.425s][info][cpu   ]      Garbage Collection                                  83.7322    5.18       1.2
> [71.425s][info][cpu   ]        GC Threads                                        82.7671    5.12       1.2
> [71.425s][info][cpu   ]        VM Thread                                          0.9651    0.06       0.0
> [71.425s][info][cpu   ] =====================================================================================
> 
> 
> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path.

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

  Feedback from Albert

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26621/files
  - new: https://git.openjdk.org/jdk/pull/26621/files/3f552362..143fcacb

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

  Stats: 34 lines in 3 files changed: 2 ins; 7 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/26621.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26621/head:pull/26621

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

From duke at openjdk.org  Tue Aug 12 12:24:37 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Tue, 12 Aug 2025 12:24:37 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v4]
In-Reply-To: <SQ8LQ9lyCClcWIdoXPpcU9PDASmtEatIx3HGBj7kmdA=.306a44c4-4d49-4984-88d4-daf6e8c2a232@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <SQ8LQ9lyCClcWIdoXPpcU9PDASmtEatIx3HGBj7kmdA=.306a44c4-4d49-4984-88d4-daf6e8c2a232@github.com>
Message-ID: <zn5tn_H1CoW9e-5ygaZMZqGGpamrsIGK1tFIR3dM-3s=.d57b900e-9141-4842-9f11-c6f005a153aa@github.com>

On Thu, 7 Aug 2025 09:49:12 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110).
>> 
>> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports:
>> 
>> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup()
>> 
>> CPUTimeUsage::GC::gc_threads()
>> CPUTimeUsage::GC::vm_thread()
>> CPUTimeUsage::GC::stringdedup()
>> 
>> CPUTimeUsage::Runtime::vm_thread()
>> 
>> 
>> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC.
>> 
>> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table:
>> 
>> 
>> [71.425s][info][cpu   ] === CPU time Statistics =============================================================
>> [71.425s][info][cpu   ]                                                                             CPUs
>> [71.425s][info][cpu   ]                                                                s       %  utilized
>> [71.425s][info][cpu   ]    Process
>> [71.425s][info][cpu   ]      Total                                             1616.3627  100.00      22.6
>> [71.425s][info][cpu   ]      VM Thread                                            5.2992    0.33       0.1
>> [71.425s][info][cpu   ]      Garbage Collection                                  83.7322    5.18       1.2
>> [71.425s][info][cpu   ]        GC Threads                                        82.7671    5.12       1.2
>> [71.425s][info][cpu   ]        VM Thread                                          0.9651    0.06       0.0
>> [71.425s][info][cpu   ] =====================================================================================
>> 
>> 
>> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve robustness

Thanks for the review @albertnetymk! I pushed changes reflecting your feedback.

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

PR Comment: https://git.openjdk.org/jdk/pull/26621#issuecomment-3179095971

From fbredberg at openjdk.org  Tue Aug 12 13:12:33 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Tue, 12 Aug 2025 13:12:33 GMT
Subject: RFR: 8365146: Remove LockingMode related code from ppc64 [v2]
In-Reply-To: <mKtlz6j_OunSKwTrSfwVxcErf8oTsclqe65OSJxXvlw=.b958a3bc-0253-4efd-a9ff-03ac0418ba23@github.com>
References: <mKtlz6j_OunSKwTrSfwVxcErf8oTsclqe65OSJxXvlw=.b958a3bc-0253-4efd-a9ff-03ac0418ba23@github.com>
Message-ID: <101mw24zKLsjXjexjOZKimofI_yySxPw3gGyJq9HT1s=.495f1653-86ec-4d90-82d6-091b90d592f6@github.com>

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
> 
> This PR removes `LockingMode` related code from the **ppc64le** platform.
> 
> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.

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

 - Merge branch 'master' into 8365146_remove_lockingmode_ppc64
 - 8365146: Remove LockingMode related code from ppc64

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26697/files
  - new: https://git.openjdk.org/jdk/pull/26697/files/e909d06d..e9c74f13

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

  Stats: 26680 lines in 689 files changed: 16192 ins; 8264 del; 2224 mod
  Patch: https://git.openjdk.org/jdk/pull/26697.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26697/head:pull/26697

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

From gziemski at openjdk.org  Tue Aug 12 15:10:20 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 12 Aug 2025 15:10:20 GMT
Subject: RFR: 8353444: NMT: rename 'category' to 'MemTag' in malloc tracker
 [v5]
In-Reply-To: <lBRzMW5p5JxzVyOj9_n1qNwF2b7B0Zbur_5EvwbguxE=.042caa0b-19d7-454d-8c13-f8c406736e44@github.com>
References: <mVv-IomtzU25S1Xv1kQAy0gkUYPmuOLFDc-bJskDTaY=.c434ab86-536f-4e22-9dfa-64a00274c06b@github.com>
 <lBRzMW5p5JxzVyOj9_n1qNwF2b7B0Zbur_5EvwbguxE=.042caa0b-19d7-454d-8c13-f8c406736e44@github.com>
Message-ID: <EqUUWZ81id3DhMs-wZuaEN1r1UlxYVWwkLHN0ByMKPc=.2a4a7bd4-2f5f-4e97-bcac-4f6014fc2a94@github.com>

On Fri, 8 Aug 2025 12:55:42 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> Renamed usage of 'category' for 'MemTag' cases.
>
> Afshin Zafari has updated the pull request with a new target base 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 _8353444_mem_category_to_memtag
>  - copyright fixed
>  - Merge remote-tracking branch 'origin/master' into _8353444_mem_category_to_memtag
>  - fixed a missed test.
>  - user-facing terms remained as 'category'
>  - 8353444: NMT: rename 'category' to 'MemTag' in malloc tracker

Changes requested by gziemski (Reviewer).

src/hotspot/share/nmt/mallocLimit.hpp line 57:

> 55: 
> 56:   void set_global_limit(size_t s, MallocLimitMode type);
> 57:   void set_mem_tag_limit(MemTag mem_tag, size_t s, MallocLimitMode mode);

Prefer the old names.

src/hotspot/share/nmt/mallocTracker.cpp line 131:

> 129: }
> 130: 
> 131: bool MallocMemorySummary::mem_tag_limit_reached(MemTag mem_tag, size_t s, size_t so_far, const malloclimit* limit) {

I think I prefer the old name of this API.

src/hotspot/share/nmt/mallocTracker.hpp line 216:

> 214:   // Called when a total limit break was detected.
> 215:   // Will return true if the limit was handled, false if it was ignored.
> 216:   static bool mem_tag_limit_reached(MemTag mem_tag, size_t s, size_t so_far, const malloclimit* limit);

I think I prefer the old name of this API.

src/hotspot/share/nmt/mallocTracker.hpp line 258:

> 256: 
> 257:   // MallocLimit: returns true if allocating s bytes on f would trigger
> 258:   // either global or the MemTag limit

No need to change the comment?

src/hotspot/share/nmt/mallocTracker.inline.hpp line 34:

> 32: #include "utilities/globalDefinitions.hpp"
> 33: 
> 34: // Returns true if allocating s bytes on f would trigger either global or the MemTag limit

No need to change the comment?

test/hotspot/gtest/nmt/test_nmt_malloclimit.cpp line 79:

> 77: }
> 78: 
> 79: TEST(NMT, MallocLimitPerMemTag) {

Prefer the old name.

test/hotspot/gtest/nmt/test_nmt_totals.cpp line 92:

> 90:     // spread over mem-tags
> 91:     int mtag = i % (mt_number_of_tags - 1);
> 92:     p[i] = NEW_C_HEAP_ARRAY(char, ALLOC_SIZE, (MemTag)mtag);

Prefer the old names.

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

PR Review: https://git.openjdk.org/jdk/pull/25226#pullrequestreview-3111280820
PR Review Comment: https://git.openjdk.org/jdk/pull/25226#discussion_r2270208623
PR Review Comment: https://git.openjdk.org/jdk/pull/25226#discussion_r2270197022
PR Review Comment: https://git.openjdk.org/jdk/pull/25226#discussion_r2270198699
PR Review Comment: https://git.openjdk.org/jdk/pull/25226#discussion_r2270200770
PR Review Comment: https://git.openjdk.org/jdk/pull/25226#discussion_r2270201911
PR Review Comment: https://git.openjdk.org/jdk/pull/25226#discussion_r2270204431
PR Review Comment: https://git.openjdk.org/jdk/pull/25226#discussion_r2270206418

From ayang at openjdk.org  Tue Aug 12 15:20:18 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 12 Aug 2025 15:20:18 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v5]
In-Reply-To: <R5zawVwQKoUQAUOiGxy3bXsLJ8uuxU21AztKMu4hkhM=.0360b18b-0046-4491-a550-4c6b6fd75334@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <R5zawVwQKoUQAUOiGxy3bXsLJ8uuxU21AztKMu4hkhM=.0360b18b-0046-4491-a550-4c6b6fd75334@github.com>
Message-ID: <ScJxz_3oq2-HVbpfLTOAQBMRL89M3ntox_z2__y66sQ=.50bdac15-d68a-4fa1-8c9b-1a1793b05a82@github.com>

On Tue, 12 Aug 2025 12:24:35 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110).
>> 
>> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports:
>> 
>> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup()
>> 
>> CPUTimeUsage::GC::gc_threads()
>> CPUTimeUsage::GC::vm_thread()
>> CPUTimeUsage::GC::stringdedup()
>> 
>> CPUTimeUsage::Runtime::vm_thread()
>> 
>> 
>> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC.
>> 
>> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table:
>> 
>> 
>> [71.425s][info][cpu   ] === CPU time Statistics =============================================================
>> [71.425s][info][cpu   ]                                                                             CPUs
>> [71.425s][info][cpu   ]                                                                s       %  utilized
>> [71.425s][info][cpu   ]    Process
>> [71.425s][info][cpu   ]      Total                                             1616.3627  100.00      22.6
>> [71.425s][info][cpu   ]      VM Thread                                            5.2992    0.33       0.1
>> [71.425s][info][cpu   ]      Garbage Collection                                  83.7322    5.18       1.2
>> [71.425s][info][cpu   ]        GC Threads                                        82.7671    5.12       1.2
>> [71.425s][info][cpu   ]        VM Thread                                          0.9651    0.06       0.0
>> [71.425s][info][cpu   ] =====================================================================================
>> 
>> 
>> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback from Albert

src/hotspot/share/gc/shared/collectedHeap.cpp line 610:

> 608: }
> 609: 
> 610: double percent_of(double component_cpu_time, double process_cpu_time) {

There is global function, `percent_of`. Can that be used directly?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2270240264

From dfenacci at openjdk.org  Tue Aug 12 15:20:21 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Tue, 12 Aug 2025 15:20:21 GMT
Subject: RFR: 8358696: Assert with extreme values for -XX:BciProfileWidth
 [v6]
In-Reply-To: <ECYtRACv9J4K9z9CFQDAWRX7psioszU240ikVOO6RhM=.a88220a5-8ad5-4d0f-94e4-b0999e343d99@github.com>
References: <5TRVeAXUQi6quM-nDWEij_jk6M5K2Vk31RA-Yjd8F2M=.5b63da45-93c3-4251-9e2e-3c64b7953919@github.com>
 <Nt6C65eUJqxWJAPob_5ZvNiQXZJMQK_vD_Ik9NYSCm4=.773e5f1a-a02f-4206-99d8-e8003a708cd6@github.com>
 <1QbX5WHkEdjP-unAFJ1vYaoIc9bV8zz8dA-vKZCkYn8=.8e3704ae-9490-4471-9e5c-dae44004d46f@github.com>
 <ECYtRACv9J4K9z9CFQDAWRX7psioszU240ikVOO6RhM=.a88220a5-8ad5-4d0f-94e4-b0999e343d99@github.com>
Message-ID: <oPH0G597q13SYnSti3t3SpasSC4L1EuqRl4X-JjXfX0=.cd5147ae-fcd6-490c-a479-62896cc02ce7@github.com>

On Mon, 11 Aug 2025 11:13:08 GMT, Saranya Natarajan <snatarajan at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/arguments/TestBciProfileWidth.java line 28:
>> 
>>> 26:  * @summary Test the range defined in globals.hpp for BciProfileWidth
>>> 27:  * @bug 8358696
>>> 28:  * @run main/othervm -XX:BciProfileWidth=0
>> 
>> `BciProfileWidth` is debug only, right?
>
> Thank you for the review. 
> I have now included `@requires vm.debug`

Shouldn't we check that the vm doesn't crash with `BciProfileWidth=-1` and `BciProfileWidth=100000` (or another very high value)?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26139#discussion_r2270238127

From iklam at openjdk.org  Tue Aug 12 16:23:25 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 12 Aug 2025 16:23:25 GMT
Subject: RFR: 8364454: ProblemList runtime/cds/DeterministicDump.java on
 macos for JDK-8363986
In-Reply-To: <0PEC7lDGkopYldlUKw9UGm35co3M2ANGiW9xxlzubuw=.55b155d3-6cd3-487c-a141-c013105921b0@github.com>
References: <vyYktqcsqjBwfXdkJXvL0B03VW5cpqUoPtZ5vTm25k0=.0304ed4e-f9a5-4145-b2c1-e9b43313416a@github.com>
 <0PEC7lDGkopYldlUKw9UGm35co3M2ANGiW9xxlzubuw=.55b155d3-6cd3-487c-a141-c013105921b0@github.com>
Message-ID: <0M7DL5CMxRJEocRFaGh8w0gsLRjo2uBp7F19jUGkJhY=.a582b5f7-4fe7-42a0-85b4-4a7510c9e613@github.com>

On Thu, 31 Jul 2025 19:56:36 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> The fix for JDK-8363986 is in progress but may take some time. ProblemList this test for now to avoid noise in testing.
>
> Looks good and trivial to me.

Thanks @calvinccheung for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/26578#issuecomment-3180104684

From iklam at openjdk.org  Tue Aug 12 16:23:26 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 12 Aug 2025 16:23:26 GMT
Subject: Integrated: 8364454: ProblemList runtime/cds/DeterministicDump.java on
 macos for JDK-8363986
In-Reply-To: <vyYktqcsqjBwfXdkJXvL0B03VW5cpqUoPtZ5vTm25k0=.0304ed4e-f9a5-4145-b2c1-e9b43313416a@github.com>
References: <vyYktqcsqjBwfXdkJXvL0B03VW5cpqUoPtZ5vTm25k0=.0304ed4e-f9a5-4145-b2c1-e9b43313416a@github.com>
Message-ID: <yroRsB6jTaGmDNpVpUL8YybZhUIf4mCZX1zCVZBNp-w=.5df2842f-3832-4830-8c37-67dbd66c854a@github.com>

On Thu, 31 Jul 2025 17:20:43 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The fix for JDK-8363986 is in progress but may take some time. ProblemList this test for now to avoid noise in testing.

This pull request has now been integrated.

Changeset: ad0fd13f
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ad0fd13f2007c93d8a109626a627823f30e4c8d7
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8364454: ProblemList runtime/cds/DeterministicDump.java on macos for JDK-8363986

Reviewed-by: ccheung

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

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

From coleenp at openjdk.org  Tue Aug 12 16:29:14 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 12 Aug 2025 16:29:14 GMT
Subject: RFR: 8364750: Remove unused declaration in jvm.h
In-Reply-To: <kmSkNYke2ZVgD59HLfAy6Mg8nrH71nLPHIyXm-57NJ0=.20304694-3dfa-4d69-bd86-6586e808d8b7@github.com>
References: <kmSkNYke2ZVgD59HLfAy6Mg8nrH71nLPHIyXm-57NJ0=.20304694-3dfa-4d69-bd86-6586e808d8b7@github.com>
Message-ID: <b-f-KeOaDQpNADWOHHxKd9s4kIM1vBO3gOwWaBZ2FZI=.b3518930-3bac-46a4-809b-5956002bda5e@github.com>

On Mon, 11 Aug 2025 17:49:15 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this trivial change to remove the declaration of the native JVM function that I removed in [JDK-8364187](https://bugs.openjdk.org/browse/JDK-8364187).
> Tested with tier1 on Oracle supported platforms as sanity test (in progress).

Thanks Chen, I fixed the title.  This is why I always seem to miss this file.
Thanks for reviewing Aleksey.

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

PR Comment: https://git.openjdk.org/jdk/pull/26732#issuecomment-3180130627

From coleenp at openjdk.org  Tue Aug 12 16:33:18 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 12 Aug 2025 16:33:18 GMT
Subject: Integrated: 8364750: Remove unused declaration in jvm.h
In-Reply-To: <kmSkNYke2ZVgD59HLfAy6Mg8nrH71nLPHIyXm-57NJ0=.20304694-3dfa-4d69-bd86-6586e808d8b7@github.com>
References: <kmSkNYke2ZVgD59HLfAy6Mg8nrH71nLPHIyXm-57NJ0=.20304694-3dfa-4d69-bd86-6586e808d8b7@github.com>
Message-ID: <C7gjUcVizR_UGdWw8psilCdl_cVWxI5UqWSuneY7_lI=.6a73faf3-0e73-4774-9325-dc318f4fba82@github.com>

On Mon, 11 Aug 2025 17:49:15 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this trivial change to remove the declaration of the native JVM function that I removed in [JDK-8364187](https://bugs.openjdk.org/browse/JDK-8364187).
> Tested with tier1 on Oracle supported platforms as sanity test (in progress).

This pull request has now been integrated.

Changeset: 4c03e593
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4c03e5938df0a9cb10c2379af81163795dd3a086
Stats:     10 lines in 1 file changed: 0 ins; 10 del; 0 mod

8364750: Remove unused declaration in jvm.h

Reviewed-by: shade

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

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

From bulasevich at openjdk.org  Tue Aug 12 19:07:17 2025
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Tue, 12 Aug 2025 19:07:17 GMT
Subject: RFR: 8358696: Assert with extreme values for -XX:BciProfileWidth
 [v7]
In-Reply-To: <a3A1JrsMuTkR1mYm_UjnCSL-jJk161xIYxtxIjrNW88=.51ec6516-2d72-4c51-8cfd-c8d505a7f8d2@github.com>
References: <5TRVeAXUQi6quM-nDWEij_jk6M5K2Vk31RA-Yjd8F2M=.5b63da45-93c3-4251-9e2e-3c64b7953919@github.com>
 <a3A1JrsMuTkR1mYm_UjnCSL-jJk161xIYxtxIjrNW88=.51ec6516-2d72-4c51-8cfd-c8d505a7f8d2@github.com>
Message-ID: <3gxI6LHS5BbGD3Dra6pdCPsRosCAO6W_rhUAQK0qAlA=.b75b1b5c-7e8d-4fbf-9b0d-83fdc424881e@github.com>

On Mon, 11 Aug 2025 11:17:31 GMT, Saranya Natarajan <snatarajan at openjdk.org> wrote:

>> **Issue**
>> Extreme values for BciProfileWidth flag such as `java -XX:BciProfileWidth=-1 -version` and `java -XX:BciProfileWidth=100000 -version `results in assert failure `assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x0000772b63a7a3a0 <= 0x0000772b63b75159 <= 0x0000772b63b75158 `. This is observed in a x86 machine.
>> 
>> **Analysis** 
>>  On debugging the issue, I found that increasing the size of the interpreter using the `InterpreterCodeSize` variable in `src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp` prevented the above mentioned assert from failing for large values of BciProfileWidth.  
>> 
>> **Proposal** 
>> Considering the fact that larger BciProfileWidth results in slower profiling, I have proposed a range between 0 to 5000 to restrict the value for BciProfileWidth for x86 machines. This maximum value is based on modifying the `InterpreterCodeSize` variable in `src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp` using the smallest `InterpreterCodeSize` for all the architectures.  As for the lower bound, a value of -1 would be the same as 0, as this simply means  no  return bci's will be recorded in ret profile. 
>> 
>> **Issue in AArch64**
>> Additionally running the command `java -XX:BciProfileWidth= 10000 -version` (or larger values) results in a different failure  `assert(offset_ok_for_immed(offset(), size)) failed: must be, was: 32768, 3` on an AArch64 machine.This is an issue of maximum offset for `ldr/str` in AArch64 which can be fixed using `form_address`  as mentioned in [JDK-8342736](https://bugs.openjdk.org/browse/JDK-8342736). In my preliminary fix using `form_address` on AArch64 machine. I had to modify 3 `ldr` and 1 `str` instruction (in file `src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp` at line number 926, 983, and 997). With this fix  using `form_address`, `BciProfileWidth` works for maximum of 5000 after which it crashes with`assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x0000772b63a7a3a0 <= 0x0000772b63b75159 <= 0x0000772b63b75158 `.  Without this fix `BciProfileWidth` works for a maximum value of 1300.   Currently, I have suggested to restrict the upper bound on AArch64 to 1000 instead
  of fixing it with `form_address`. 
>> 
>> **Question to reviewers**
>> Do you think this is a reasonable fix ?  For AArch64 do you suggest fixing using `form_address` ? If yes, do I fix it under this PR or create another one ?
>> 
>> **Request to port maintainers**
>> @dafedafe suggested that we keep the upper boun...
>
> Saranya Natarajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressing review : adding vm.debug and moving a defn

Marked as reviewed by bulasevich (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/26139#pullrequestreview-3112354691

From bulasevich at openjdk.org  Tue Aug 12 19:38:50 2025
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Tue, 12 Aug 2025 19:38:50 GMT
Subject: RFR: 8365166: ARM32: missing os::fetch_bcp_from_context implementation
Message-ID: <T1o4cX_F7Grd9IsCwDSbpynwl-ACT6WQ-rrwsgbIpss=.d1a230ec-37df-4133-bc9f-75395cd43a2c@github.com>

Since [JDK-8352251](https://bugs.openjdk.org/browse/JDK-8352251) (JEP 518: JFR Cooperative Sampling), jfrSampleRequest calls os::fetch_bcp_from_context(). On ARM32 port it is still Unimplemented(). It should read the corresponding field from uc_mcontext and return the BCP value.

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

Commit messages:
 - ensure Rbcp is R7
 - 8365166: ARM32: missing os::fetch_bcp_from_context implementation

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

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

From bulasevich at openjdk.org  Tue Aug 12 19:38:50 2025
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Tue, 12 Aug 2025 19:38:50 GMT
Subject: RFR: 8365166: ARM32: missing os::fetch_bcp_from_context
 implementation
In-Reply-To: <L2N3YfsOjjWtSyAzN3Y_zk-8-N8Ri7gEZ_f_Hbge5Pk=.8ce70c54-f2c6-45f4-acc3-53ec5a370942@github.com>
References: <T1o4cX_F7Grd9IsCwDSbpynwl-ACT6WQ-rrwsgbIpss=.d1a230ec-37df-4133-bc9f-75395cd43a2c@github.com>
 <L2N3YfsOjjWtSyAzN3Y_zk-8-N8Ri7gEZ_f_Hbge5Pk=.8ce70c54-f2c6-45f4-acc3-53ec5a370942@github.com>
Message-ID: <ZE-o4S5tIwDHZ9btazktuJFcgKe4N3riJ5gTZqXOnPM=.5bb5378d-6cdd-419e-a4e1-bee48b49cd02@github.com>

On Fri, 8 Aug 2025 17:07:06 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Since [JDK-8352251](https://bugs.openjdk.org/browse/JDK-8352251) (JEP 518: JFR Cooperative Sampling), jfrSampleRequest calls os::fetch_bcp_from_context(). On ARM32 port it is still Unimplemented(). It should read the corresponding field from uc_mcontext and return the BCP value.
>
> src/hotspot/os_cpu/linux_arm/os_linux_arm.cpp line 215:
> 
>> 213:   const ucontext_t* uc = (const ucontext_t*)ucVoid;
>> 214:   assert(os::Posix::ucontext_is_interpreter(uc), "invariant");
>> 215:   return (intptr_t*)uc->uc_mcontext.arm_r7;
> 
> You sure it is always R7? The `Rbcp` register definition seems to choose between R7 and R11: https://github.com/openjdk/jdk/blob/241808e13fb032b0ec192e0b7ff94891a653ac94/src/hotspot/cpu/arm/register_arm.hpp#L414-L415

Right. It seems a relic, but for consistency I added support for alternative Rbcp.
Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26699#discussion_r2270973006

From shade at openjdk.org  Tue Aug 12 19:38:50 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 12 Aug 2025 19:38:50 GMT
Subject: RFR: 8365166: ARM32: missing os::fetch_bcp_from_context
 implementation
In-Reply-To: <T1o4cX_F7Grd9IsCwDSbpynwl-ACT6WQ-rrwsgbIpss=.d1a230ec-37df-4133-bc9f-75395cd43a2c@github.com>
References: <T1o4cX_F7Grd9IsCwDSbpynwl-ACT6WQ-rrwsgbIpss=.d1a230ec-37df-4133-bc9f-75395cd43a2c@github.com>
Message-ID: <L2N3YfsOjjWtSyAzN3Y_zk-8-N8Ri7gEZ_f_Hbge5Pk=.8ce70c54-f2c6-45f4-acc3-53ec5a370942@github.com>

On Fri, 8 Aug 2025 14:27:20 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

> Since [JDK-8352251](https://bugs.openjdk.org/browse/JDK-8352251) (JEP 518: JFR Cooperative Sampling), jfrSampleRequest calls os::fetch_bcp_from_context(). On ARM32 port it is still Unimplemented(). It should read the corresponding field from uc_mcontext and return the BCP value.

src/hotspot/os_cpu/linux_arm/os_linux_arm.cpp line 215:

> 213:   const ucontext_t* uc = (const ucontext_t*)ucVoid;
> 214:   assert(os::Posix::ucontext_is_interpreter(uc), "invariant");
> 215:   return (intptr_t*)uc->uc_mcontext.arm_r7;

You sure it is always R7? The `Rbcp` register definition seems to choose between R7 and R11: https://github.com/openjdk/jdk/blob/241808e13fb032b0ec192e0b7ff94891a653ac94/src/hotspot/cpu/arm/register_arm.hpp#L414-L415

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26699#discussion_r2263587225

From shade at openjdk.org  Tue Aug 12 20:42:12 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 12 Aug 2025 20:42:12 GMT
Subject: RFR: 8365166: ARM32: missing os::fetch_bcp_from_context
 implementation
In-Reply-To: <T1o4cX_F7Grd9IsCwDSbpynwl-ACT6WQ-rrwsgbIpss=.d1a230ec-37df-4133-bc9f-75395cd43a2c@github.com>
References: <T1o4cX_F7Grd9IsCwDSbpynwl-ACT6WQ-rrwsgbIpss=.d1a230ec-37df-4133-bc9f-75395cd43a2c@github.com>
Message-ID: <3HIh34ISCV1iYOMdY-SKmIM8D-_L8jHe2e8GqAD2nfE=.0ce1a801-148c-46b1-8268-f74028aeb96f@github.com>

On Fri, 8 Aug 2025 14:27:20 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

> Since [JDK-8352251](https://bugs.openjdk.org/browse/JDK-8352251) (JEP 518: JFR Cooperative Sampling), jfrSampleRequest calls os::fetch_bcp_from_context(). On ARM32 port it is still Unimplemented(). It should read the corresponding field from uc_mcontext and return the BCP value.

Looks good, with minor nit.

src/hotspot/os_cpu/linux_arm/os_linux_arm.cpp line 216:

> 214:   assert(os::Posix::ucontext_is_interpreter(uc), "invariant");
> 215: #if (FP_REG_NUM == 11)
> 216:   assert(Rbcp == R7,  "expected FP=R11, Rbcp=R7");

Suggestion:

  assert(Rbcp == R7, "expected FP=R11, Rbcp=R7");

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26699#pullrequestreview-3112746558
PR Review Comment: https://git.openjdk.org/jdk/pull/26699#discussion_r2271168432

From bulasevich at openjdk.org  Wed Aug 13 00:07:26 2025
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Wed, 13 Aug 2025 00:07:26 GMT
Subject: RFR: 8365166: ARM32: missing os::fetch_bcp_from_context
 implementation [v2]
In-Reply-To: <T1o4cX_F7Grd9IsCwDSbpynwl-ACT6WQ-rrwsgbIpss=.d1a230ec-37df-4133-bc9f-75395cd43a2c@github.com>
References: <T1o4cX_F7Grd9IsCwDSbpynwl-ACT6WQ-rrwsgbIpss=.d1a230ec-37df-4133-bc9f-75395cd43a2c@github.com>
Message-ID: <uyHQ6DVIKi6qqIf7OQQEhteGKSQZcoR9NbUW6GznFxc=.307002a2-df96-4944-937e-b393eec045a1@github.com>

> Since [JDK-8352251](https://bugs.openjdk.org/browse/JDK-8352251) (JEP 518: JFR Cooperative Sampling), jfrSampleRequest calls os::fetch_bcp_from_context(). On ARM32 port it is still Unimplemented(). It should read the corresponding field from uc_mcontext and return the BCP value.

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

  Update src/hotspot/os_cpu/linux_arm/os_linux_arm.cpp
  
  Co-authored-by: Aleksey Shipil?v <shipilev at amazon.de>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26699/files
  - new: https://git.openjdk.org/jdk/pull/26699/files/ba5a37d8..b7fd42b3

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

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

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

From shade at openjdk.org  Wed Aug 13 06:29:18 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 13 Aug 2025 06:29:18 GMT
Subject: RFR: 8365166: ARM32: missing os::fetch_bcp_from_context
 implementation [v2]
In-Reply-To: <uyHQ6DVIKi6qqIf7OQQEhteGKSQZcoR9NbUW6GznFxc=.307002a2-df96-4944-937e-b393eec045a1@github.com>
References: <T1o4cX_F7Grd9IsCwDSbpynwl-ACT6WQ-rrwsgbIpss=.d1a230ec-37df-4133-bc9f-75395cd43a2c@github.com>
 <uyHQ6DVIKi6qqIf7OQQEhteGKSQZcoR9NbUW6GznFxc=.307002a2-df96-4944-937e-b393eec045a1@github.com>
Message-ID: <xxHNa_SLHUlbF7w285ZEGE0wT-elDJAAR39sQ2Vde30=.acddedb7-6e93-40d7-b17c-39f1e37b7601@github.com>

On Wed, 13 Aug 2025 00:07:26 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

>> Since [JDK-8352251](https://bugs.openjdk.org/browse/JDK-8352251) (JEP 518: JFR Cooperative Sampling), jfrSampleRequest calls os::fetch_bcp_from_context(). On ARM32 port it is still Unimplemented(). It should read the corresponding field from uc_mcontext and return the BCP value.
>
> Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/os_cpu/linux_arm/os_linux_arm.cpp
>   
>   Co-authored-by: Aleksey Shipil?v <shipilev at amazon.de>

Looks good.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26699#pullrequestreview-3114103814

From rrich at openjdk.org  Wed Aug 13 08:22:14 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 13 Aug 2025 08:22:14 GMT
Subject: RFR: 8365146: Remove LockingMode related code from ppc64
In-Reply-To: <SdjlmIO_4yiCgtsGucf9pJit6OvKehbmQkC0Y7lBTcQ=.a35e1b45-be4e-43fc-a36e-84d9610df4d6@github.com>
References: <mKtlz6j_OunSKwTrSfwVxcErf8oTsclqe65OSJxXvlw=.b958a3bc-0253-4efd-a9ff-03ac0418ba23@github.com>
 <SdjlmIO_4yiCgtsGucf9pJit6OvKehbmQkC0Y7lBTcQ=.a35e1b45-be4e-43fc-a36e-84d9610df4d6@github.com>
Message-ID: <EBSLscLBvbaYzPUOIGljiC4AoCsoksOuTqsTWfFWx0M=.a21a1dd5-94b8-4788-aebb-e80f76958d35@github.com>

On Fri, 8 Aug 2025 14:15:34 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> @TheRealMDoerr (or @reinrich)
> 
> I've run rudimentary tests using QEMU, but it would be nice if you could take it for a spin on real hardware.

Thanks for the notification. I've asked @MBaesken to do that, since @TheRealMDoerr and myself are currently both not in the office.

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

PR Comment: https://git.openjdk.org/jdk/pull/26697#issuecomment-3182706381

From fbredberg at openjdk.org  Wed Aug 13 08:43:12 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 13 Aug 2025 08:43:12 GMT
Subject: RFR: 8365146: Remove LockingMode related code from ppc64
In-Reply-To: <EBSLscLBvbaYzPUOIGljiC4AoCsoksOuTqsTWfFWx0M=.a21a1dd5-94b8-4788-aebb-e80f76958d35@github.com>
References: <mKtlz6j_OunSKwTrSfwVxcErf8oTsclqe65OSJxXvlw=.b958a3bc-0253-4efd-a9ff-03ac0418ba23@github.com>
 <SdjlmIO_4yiCgtsGucf9pJit6OvKehbmQkC0Y7lBTcQ=.a35e1b45-be4e-43fc-a36e-84d9610df4d6@github.com>
 <EBSLscLBvbaYzPUOIGljiC4AoCsoksOuTqsTWfFWx0M=.a21a1dd5-94b8-4788-aebb-e80f76958d35@github.com>
Message-ID: <52SYd4nSqCcU7odS8JyJ5QuNvTF_NEWlBVwpOyc5LCY=.0e98b56a-5d07-4446-9631-ad5a5368f48b@github.com>

On Wed, 13 Aug 2025 08:19:11 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> @TheRealMDoerr (or @reinrich)
>> I've run rudimentary tests using QEMU, but it would be nice if you could take it for a spin on real hardware.
>
>> @TheRealMDoerr (or @reinrich)
>> 
>> I've run rudimentary tests using QEMU, but it would be nice if you could take it for a spin on real hardware.
> 
> Thanks for the notification. I've asked @MBaesken to do that, since @TheRealMDoerr and myself are currently both not in the office.

No problem @reinrich.
I figured you were out on vacation. However, if would be nice if @MBaesken could have a quick look, and maybe give it a test run, because I want to integrate all the cpu platform stuff before removing the generic `LockingRelated` code.
Hope this text was not too much to read on a phone, and please continue to enjoy your time out of the office.

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

PR Comment: https://git.openjdk.org/jdk/pull/26697#issuecomment-3182774285

From fbredberg at openjdk.org  Wed Aug 13 08:46:14 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 13 Aug 2025 08:46:14 GMT
Subject: RFR: 8364570: Remove LockingMode related code from riscv64 [v3]
In-Reply-To: <3sChOPKIk2-UqhUj4pWjToLW4rZhe-Xwx2qrJpwh8-s=.11ca8338-38bd-428a-ae2d-d962be6fdc67@github.com>
References: <TGtRFC9NpLCnaqcLtmFttGpJIHOWxXdUB4PZHfhSHoA=.0fb2f13f-f42b-4804-804e-9b24422a08c9@github.com>
 <3sChOPKIk2-UqhUj4pWjToLW4rZhe-Xwx2qrJpwh8-s=.11ca8338-38bd-428a-ae2d-d962be6fdc67@github.com>
Message-ID: <ORVPFsmgWJhrcNU_uw8SO5B_4uhhIruZw8R_2SbrGgg=.63296a51-95d4-4202-bb1c-522067fed776@github.com>

On Tue, 12 Aug 2025 10:02:09 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
>> 
>> This PR removes `LockingMode` related code from the **riscv64** platform.
>> 
>> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.
>
> Fredrik Bredberg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into 8364570_remove_lockingmode_riscv64
>  - Update two after review
>  - Update one after review
>  - 8364570: Remove LockingMode related code from riscv64

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/26658#issuecomment-3182786521

From fbredberg at openjdk.org  Wed Aug 13 08:50:18 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 13 Aug 2025 08:50:18 GMT
Subject: Integrated: 8364570: Remove LockingMode related code from riscv64
In-Reply-To: <TGtRFC9NpLCnaqcLtmFttGpJIHOWxXdUB4PZHfhSHoA=.0fb2f13f-f42b-4804-804e-9b24422a08c9@github.com>
References: <TGtRFC9NpLCnaqcLtmFttGpJIHOWxXdUB4PZHfhSHoA=.0fb2f13f-f42b-4804-804e-9b24422a08c9@github.com>
Message-ID: <72Q8XdUx8UgKbJX-KuJ0iIMXgRkZzRLhW1PvtTgr4jI=.22f931cf-5850-4a02-80d2-c7be9afa92b4@github.com>

On Wed, 6 Aug 2025 11:24:22 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
> 
> This PR removes `LockingMode` related code from the **riscv64** platform.
> 
> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.

This pull request has now been integrated.

Changeset: e77cdd93
Author:    Fredrik Bredberg <fbredberg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e77cdd93ead5601fea4bb1bf1847835e1097b851
Stats:     584 lines in 9 files changed: 7 ins; 528 del; 49 mod

8364570: Remove LockingMode related code from riscv64

Reviewed-by: fyang, fjiang

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

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

From mbaesken at openjdk.org  Wed Aug 13 09:07:14 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 13 Aug 2025 09:07:14 GMT
Subject: RFR: 8365146: Remove LockingMode related code from ppc64 [v2]
In-Reply-To: <101mw24zKLsjXjexjOZKimofI_yySxPw3gGyJq9HT1s=.495f1653-86ec-4d90-82d6-091b90d592f6@github.com>
References: <mKtlz6j_OunSKwTrSfwVxcErf8oTsclqe65OSJxXvlw=.b958a3bc-0253-4efd-a9ff-03ac0418ba23@github.com>
 <101mw24zKLsjXjexjOZKimofI_yySxPw3gGyJq9HT1s=.495f1653-86ec-4d90-82d6-091b90d592f6@github.com>
Message-ID: <rA67M2Y1gYxYTZ15p3zPqIdr1gX1Mc2eAO0Jfnb7lsM=.16065401-e8c1-4362-8961-032922277c81@github.com>

On Tue, 12 Aug 2025 13:12:33 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
>> 
>> This PR removes `LockingMode` related code from the **ppc64le** platform.
>> 
>> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.
>
> Fredrik Bredberg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into 8365146_remove_lockingmode_ppc64
>  - 8365146: Remove LockingMode related code from ppc64

I added your PR to our build/test queue !

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

PR Comment: https://git.openjdk.org/jdk/pull/26697#issuecomment-3182865409

From snatarajan at openjdk.org  Wed Aug 13 09:35:08 2025
From: snatarajan at openjdk.org (Saranya Natarajan)
Date: Wed, 13 Aug 2025 09:35:08 GMT
Subject: RFR: 8358696: Assert with extreme values for -XX:BciProfileWidth
 [v8]
In-Reply-To: <5TRVeAXUQi6quM-nDWEij_jk6M5K2Vk31RA-Yjd8F2M=.5b63da45-93c3-4251-9e2e-3c64b7953919@github.com>
References: <5TRVeAXUQi6quM-nDWEij_jk6M5K2Vk31RA-Yjd8F2M=.5b63da45-93c3-4251-9e2e-3c64b7953919@github.com>
Message-ID: <x48Qtjsnz7ccoI5LdqiDmB8kO8FwmDjSE3ItYbtB4v0=.c22c1404-5766-4c32-a73a-a331cbe50f6d@github.com>

> **Issue**
> Extreme values for BciProfileWidth flag such as `java -XX:BciProfileWidth=-1 -version` and `java -XX:BciProfileWidth=100000 -version `results in assert failure `assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x0000772b63a7a3a0 <= 0x0000772b63b75159 <= 0x0000772b63b75158 `. This is observed in a x86 machine.
> 
> **Analysis** 
>  On debugging the issue, I found that increasing the size of the interpreter using the `InterpreterCodeSize` variable in `src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp` prevented the above mentioned assert from failing for large values of BciProfileWidth.  
> 
> **Proposal** 
> Considering the fact that larger BciProfileWidth results in slower profiling, I have proposed a range between 0 to 5000 to restrict the value for BciProfileWidth for x86 machines. This maximum value is based on modifying the `InterpreterCodeSize` variable in `src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp` using the smallest `InterpreterCodeSize` for all the architectures.  As for the lower bound, a value of -1 would be the same as 0, as this simply means  no  return bci's will be recorded in ret profile. 
> 
> **Issue in AArch64**
> Additionally running the command `java -XX:BciProfileWidth= 10000 -version` (or larger values) results in a different failure  `assert(offset_ok_for_immed(offset(), size)) failed: must be, was: 32768, 3` on an AArch64 machine.This is an issue of maximum offset for `ldr/str` in AArch64 which can be fixed using `form_address`  as mentioned in [JDK-8342736](https://bugs.openjdk.org/browse/JDK-8342736). In my preliminary fix using `form_address` on AArch64 machine. I had to modify 3 `ldr` and 1 `str` instruction (in file `src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp` at line number 926, 983, and 997). With this fix  using `form_address`, `BciProfileWidth` works for maximum of 5000 after which it crashes with`assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x0000772b63a7a3a0 <= 0x0000772b63b75159 <= 0x0000772b63b75158 `.  Without this fix `BciProfileWidth` works for a maximum value of 1300.   Currently, I have suggested to restrict the upper bound on AArch64 to 1000 instead 
 of fixing it with `form_address`. 
> 
> **Question to reviewers**
> Do you think this is a reasonable fix ?  For AArch64 do you suggest fixing using `form_address` ? If yes, do I fix it under this PR or create another one ?
> 
> **Request to port maintainers**
> @dafedafe suggested that we keep the upper bound of `BciProfileWidth` to 1000 pro...

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

  additions for  linux-riscv64

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26139/files
  - new: https://git.openjdk.org/jdk/pull/26139/files/60da70c6..2f511dbf

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

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

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

From snatarajan at openjdk.org  Wed Aug 13 09:43:13 2025
From: snatarajan at openjdk.org (Saranya Natarajan)
Date: Wed, 13 Aug 2025 09:43:13 GMT
Subject: RFR: 8358696: Assert with extreme values for -XX:BciProfileWidth
 [v6]
In-Reply-To: <gYopfBIfEjXccjL5pfV14A-j1De9lnJZjpY3-HzOzRg=.1f0afb69-ffea-4c0e-8300-dc4ae89caa62@github.com>
References: <5TRVeAXUQi6quM-nDWEij_jk6M5K2Vk31RA-Yjd8F2M=.5b63da45-93c3-4251-9e2e-3c64b7953919@github.com>
 <Nt6C65eUJqxWJAPob_5ZvNiQXZJMQK_vD_Ik9NYSCm4=.773e5f1a-a02f-4206-99d8-e8003a708cd6@github.com>
 <Wwdj_PsEMqXt1DnHNta4KXKpwJa7HSfUnOyld0C1Gec=.3870d0fd-c052-4333-a9b8-546346cbfb2d@github.com>
 <gYopfBIfEjXccjL5pfV14A-j1De9lnJZjpY3-HzOzRg=.1f0afb69-ffea-4c0e-8300-dc4ae89caa62@github.com>
Message-ID: <H9Ask5kC4V8oJQC4GxpaspJQ050jg_NyQXY4SYr-SkI=.c9f5aa70-09db-498c-b2cb-38f9ef1e046d@github.com>

On Tue, 12 Aug 2025 08:12:11 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> In the process of adding port maintainers to this PR, I by mistake added (and removed) some of them as contributor. I will update the contributor list before closing the PR. Sorry for the inconvenience
>
> @sarannat : Hi, Thanks for the ping!
> I just tried the newly-added test on linux-riscv64 and I think we still need some extra change for this platform.
> Do you mind adding that in this PR? I see the test pass with this addon change when running with fastdebug build.
> [riscv-addon-fix.diff.txt](https://github.com/user-attachments/files/21729910/riscv-addon-fix.diff.txt)

Thank you @RealFYang. I have added the changes suggested by you. Could you review it looks good ?

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

PR Comment: https://git.openjdk.org/jdk/pull/26139#issuecomment-3183013341

From snatarajan at openjdk.org  Wed Aug 13 09:48:18 2025
From: snatarajan at openjdk.org (Saranya Natarajan)
Date: Wed, 13 Aug 2025 09:48:18 GMT
Subject: RFR: 8358696: Assert with extreme values for -XX:BciProfileWidth
 [v7]
In-Reply-To: <3gxI6LHS5BbGD3Dra6pdCPsRosCAO6W_rhUAQK0qAlA=.b75b1b5c-7e8d-4fbf-9b0d-83fdc424881e@github.com>
References: <5TRVeAXUQi6quM-nDWEij_jk6M5K2Vk31RA-Yjd8F2M=.5b63da45-93c3-4251-9e2e-3c64b7953919@github.com>
 <a3A1JrsMuTkR1mYm_UjnCSL-jJk161xIYxtxIjrNW88=.51ec6516-2d72-4c51-8cfd-c8d505a7f8d2@github.com>
 <3gxI6LHS5BbGD3Dra6pdCPsRosCAO6W_rhUAQK0qAlA=.b75b1b5c-7e8d-4fbf-9b0d-83fdc424881e@github.com>
Message-ID: <QKZpJ1xGI3qBU4hLmqSjAqa9QL4K803L4G5CzBN7JkQ=.4c0e0ead-06fe-4975-8158-650abf8c49d9@github.com>

On Tue, 12 Aug 2025 19:04:24 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

>> Saranya Natarajan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   addressing review : adding vm.debug and moving a defn
>
> Marked as reviewed by bulasevich (Committer).

Thank you @bulasevich

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

PR Comment: https://git.openjdk.org/jdk/pull/26139#issuecomment-3183036976

From snatarajan at openjdk.org  Wed Aug 13 09:48:19 2025
From: snatarajan at openjdk.org (Saranya Natarajan)
Date: Wed, 13 Aug 2025 09:48:19 GMT
Subject: RFR: 8358696: Assert with extreme values for -XX:BciProfileWidth
 [v6]
In-Reply-To: <oPH0G597q13SYnSti3t3SpasSC4L1EuqRl4X-JjXfX0=.cd5147ae-fcd6-490c-a479-62896cc02ce7@github.com>
References: <5TRVeAXUQi6quM-nDWEij_jk6M5K2Vk31RA-Yjd8F2M=.5b63da45-93c3-4251-9e2e-3c64b7953919@github.com>
 <Nt6C65eUJqxWJAPob_5ZvNiQXZJMQK_vD_Ik9NYSCm4=.773e5f1a-a02f-4206-99d8-e8003a708cd6@github.com>
 <1QbX5WHkEdjP-unAFJ1vYaoIc9bV8zz8dA-vKZCkYn8=.8e3704ae-9490-4471-9e5c-dae44004d46f@github.com>
 <ECYtRACv9J4K9z9CFQDAWRX7psioszU240ikVOO6RhM=.a88220a5-8ad5-4d0f-94e4-b0999e343d99@github.com>
 <oPH0G597q13SYnSti3t3SpasSC4L1EuqRl4X-JjXfX0=.cd5147ae-fcd6-490c-a479-62896cc02ce7@github.com>
Message-ID: <vvPz4DbG8hvtva6heXU-ArTE3nXQHwfFCH9FKwdSd4I=.f123676a-02b2-4724-a493-cfee89c69058@github.com>

On Tue, 12 Aug 2025 15:16:40 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> Thank you for the review. 
>> I have now included `@requires vm.debug`
>
> Shouldn't we check that the vm doesn't crash with `BciProfileWidth=-1` and `BciProfileWidth=100000` (or another very high value)?

@dafedafe : I am working on this and will upload the changes soon.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26139#discussion_r2272747902

From azafari at openjdk.org  Wed Aug 13 11:19:58 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Wed, 13 Aug 2025 11:19:58 GMT
Subject: RFR: 8353444: NMT: rename 'category' to 'MemTag' in malloc tracker
 [v6]
In-Reply-To: <mVv-IomtzU25S1Xv1kQAy0gkUYPmuOLFDc-bJskDTaY=.c434ab86-536f-4e22-9dfa-64a00274c06b@github.com>
References: <mVv-IomtzU25S1Xv1kQAy0gkUYPmuOLFDc-bJskDTaY=.c434ab86-536f-4e22-9dfa-64a00274c06b@github.com>
Message-ID: <hoC7W0ro6JyIZEHlGdF3mApAo0-BKlM53p5O2Qhd75g=.5ccb1b9a-9296-46e3-9f40-01f77d3741c3@github.com>

> Renamed usage of 'category' for 'MemTag' cases.

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

  reverted some renamings

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25226/files
  - new: https://git.openjdk.org/jdk/pull/25226/files/79aba10b..d5340232

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

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

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

From azafari at openjdk.org  Wed Aug 13 11:20:03 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Wed, 13 Aug 2025 11:20:03 GMT
Subject: RFR: 8353444: NMT: rename 'category' to 'MemTag' in malloc tracker
 [v5]
In-Reply-To: <EqUUWZ81id3DhMs-wZuaEN1r1UlxYVWwkLHN0ByMKPc=.2a4a7bd4-2f5f-4e97-bcac-4f6014fc2a94@github.com>
References: <mVv-IomtzU25S1Xv1kQAy0gkUYPmuOLFDc-bJskDTaY=.c434ab86-536f-4e22-9dfa-64a00274c06b@github.com>
 <lBRzMW5p5JxzVyOj9_n1qNwF2b7B0Zbur_5EvwbguxE=.042caa0b-19d7-454d-8c13-f8c406736e44@github.com>
 <EqUUWZ81id3DhMs-wZuaEN1r1UlxYVWwkLHN0ByMKPc=.2a4a7bd4-2f5f-4e97-bcac-4f6014fc2a94@github.com>
Message-ID: <DjYE1y9sPCoPkB4mLHFNLxosPEp5avi9Lobur998oPU=.59d75313-c13f-4575-904b-ae135aaa49a2@github.com>

On Tue, 12 Aug 2025 15:07:23 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request with a new target base 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 _8353444_mem_category_to_memtag
>>  - copyright fixed
>>  - Merge remote-tracking branch 'origin/master' into _8353444_mem_category_to_memtag
>>  - fixed a missed test.
>>  - user-facing terms remained as 'category'
>>  - 8353444: NMT: rename 'category' to 'MemTag' in malloc tracker
>
> src/hotspot/share/nmt/mallocLimit.hpp line 57:
> 
>> 55: 
>> 56:   void set_global_limit(size_t s, MallocLimitMode type);
>> 57:   void set_mem_tag_limit(MemTag mem_tag, size_t s, MallocLimitMode mode);
> 
> Prefer the old names.

Done.

> src/hotspot/share/nmt/mallocTracker.cpp line 131:
> 
>> 129: }
>> 130: 
>> 131: bool MallocMemorySummary::mem_tag_limit_reached(MemTag mem_tag, size_t s, size_t so_far, const malloclimit* limit) {
> 
> I think I prefer the old name of this API.

Done.

> src/hotspot/share/nmt/mallocTracker.hpp line 216:
> 
>> 214:   // Called when a total limit break was detected.
>> 215:   // Will return true if the limit was handled, false if it was ignored.
>> 216:   static bool mem_tag_limit_reached(MemTag mem_tag, size_t s, size_t so_far, const malloclimit* limit);
> 
> I think I prefer the old name of this API.

Done.

> src/hotspot/share/nmt/mallocTracker.hpp line 258:
> 
>> 256: 
>> 257:   // MallocLimit: returns true if allocating s bytes on f would trigger
>> 258:   // either global or the MemTag limit
> 
> No need to change the comment?

Done.

> src/hotspot/share/nmt/mallocTracker.inline.hpp line 34:
> 
>> 32: #include "utilities/globalDefinitions.hpp"
>> 33: 
>> 34: // Returns true if allocating s bytes on f would trigger either global or the MemTag limit
> 
> No need to change the comment?

Done

> test/hotspot/gtest/nmt/test_nmt_malloclimit.cpp line 79:
> 
>> 77: }
>> 78: 
>> 79: TEST(NMT, MallocLimitPerMemTag) {
> 
> Prefer the old name.

Done.

> test/hotspot/gtest/nmt/test_nmt_totals.cpp line 92:
> 
>> 90:     // spread over mem-tags
>> 91:     int mtag = i % (mt_number_of_tags - 1);
>> 92:     p[i] = NEW_C_HEAP_ARRAY(char, ALLOC_SIZE, (MemTag)mtag);
> 
> Prefer the old names.

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25226#discussion_r2273038258
PR Review Comment: https://git.openjdk.org/jdk/pull/25226#discussion_r2273035083
PR Review Comment: https://git.openjdk.org/jdk/pull/25226#discussion_r2273035510
PR Review Comment: https://git.openjdk.org/jdk/pull/25226#discussion_r2273036187
PR Review Comment: https://git.openjdk.org/jdk/pull/25226#discussion_r2273036793
PR Review Comment: https://git.openjdk.org/jdk/pull/25226#discussion_r2273037263
PR Review Comment: https://git.openjdk.org/jdk/pull/25226#discussion_r2273037668

From bulasevich at openjdk.org  Wed Aug 13 12:45:13 2025
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Wed, 13 Aug 2025 12:45:13 GMT
Subject: RFR: 8365166: ARM32: missing os::fetch_bcp_from_context
 implementation [v2]
In-Reply-To: <uyHQ6DVIKi6qqIf7OQQEhteGKSQZcoR9NbUW6GznFxc=.307002a2-df96-4944-937e-b393eec045a1@github.com>
References: <T1o4cX_F7Grd9IsCwDSbpynwl-ACT6WQ-rrwsgbIpss=.d1a230ec-37df-4133-bc9f-75395cd43a2c@github.com>
 <uyHQ6DVIKi6qqIf7OQQEhteGKSQZcoR9NbUW6GznFxc=.307002a2-df96-4944-937e-b393eec045a1@github.com>
Message-ID: <p0onrVdQglPoY4f1X7JLKDL369oIS1fOddkJ9Y3WihM=.5d603f25-058b-47af-b80e-ddb42d781958@github.com>

On Wed, 13 Aug 2025 00:07:26 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

>> Since [JDK-8352251](https://bugs.openjdk.org/browse/JDK-8352251) (JEP 518: JFR Cooperative Sampling), jfrSampleRequest calls os::fetch_bcp_from_context(). On ARM32 port it is still Unimplemented(). It should read the corresponding field from uc_mcontext and return the BCP value.
>
> Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/os_cpu/linux_arm/os_linux_arm.cpp
>   
>   Co-authored-by: Aleksey Shipil?v <shipilev at amazon.de>

thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/26699#issuecomment-3183721826

From shade at openjdk.org  Wed Aug 13 12:49:17 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 13 Aug 2025 12:49:17 GMT
Subject: RFR: 8365166: ARM32: missing os::fetch_bcp_from_context
 implementation [v2]
In-Reply-To: <uyHQ6DVIKi6qqIf7OQQEhteGKSQZcoR9NbUW6GznFxc=.307002a2-df96-4944-937e-b393eec045a1@github.com>
References: <T1o4cX_F7Grd9IsCwDSbpynwl-ACT6WQ-rrwsgbIpss=.d1a230ec-37df-4133-bc9f-75395cd43a2c@github.com>
 <uyHQ6DVIKi6qqIf7OQQEhteGKSQZcoR9NbUW6GznFxc=.307002a2-df96-4944-937e-b393eec045a1@github.com>
Message-ID: <rkgymikf4cRiehyWK2OZC6vQ3vPQ_LFYHhM0fAyDi34=.88acf193-21a6-4c3c-a656-d3bdd20c0a6f@github.com>

On Wed, 13 Aug 2025 00:07:26 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

>> Since [JDK-8352251](https://bugs.openjdk.org/browse/JDK-8352251) (JEP 518: JFR Cooperative Sampling), jfrSampleRequest calls os::fetch_bcp_from_context(). On ARM32 port it is still Unimplemented(). It should read the corresponding field from uc_mcontext and return the BCP value.
>
> Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/os_cpu/linux_arm/os_linux_arm.cpp
>   
>   Co-authored-by: Aleksey Shipil?v <shipilev at amazon.de>

Huh, I wonder how the review was lost...

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26699#pullrequestreview-3115853061

From bulasevich at openjdk.org  Wed Aug 13 12:49:19 2025
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Wed, 13 Aug 2025 12:49:19 GMT
Subject: Integrated: 8365166: ARM32: missing os::fetch_bcp_from_context
 implementation
In-Reply-To: <T1o4cX_F7Grd9IsCwDSbpynwl-ACT6WQ-rrwsgbIpss=.d1a230ec-37df-4133-bc9f-75395cd43a2c@github.com>
References: <T1o4cX_F7Grd9IsCwDSbpynwl-ACT6WQ-rrwsgbIpss=.d1a230ec-37df-4133-bc9f-75395cd43a2c@github.com>
Message-ID: <5_5DNkOP9N7ZIOlJYOj0bt_gid3BVDz8OEyUOJYL2fI=.f68264e8-0384-4845-ac0a-23df1df0e9f6@github.com>

On Fri, 8 Aug 2025 14:27:20 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

> Since [JDK-8352251](https://bugs.openjdk.org/browse/JDK-8352251) (JEP 518: JFR Cooperative Sampling), jfrSampleRequest calls os::fetch_bcp_from_context(). On ARM32 port it is still Unimplemented(). It should read the corresponding field from uc_mcontext and return the BCP value.

This pull request has now been integrated.

Changeset: 001aaa1e
Author:    Boris Ulasevich <bulasevich at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/001aaa1e49f2692061cad44d68c9e81a27ea3b98
Stats:     10 lines in 1 file changed: 8 ins; 0 del; 2 mod

8365166: ARM32: missing os::fetch_bcp_from_context implementation

Reviewed-by: shade

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

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

From fyang at openjdk.org  Wed Aug 13 12:57:20 2025
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 13 Aug 2025 12:57:20 GMT
Subject: RFR: 8358696: Assert with extreme values for -XX:BciProfileWidth
 [v8]
In-Reply-To: <x48Qtjsnz7ccoI5LdqiDmB8kO8FwmDjSE3ItYbtB4v0=.c22c1404-5766-4c32-a73a-a331cbe50f6d@github.com>
References: <5TRVeAXUQi6quM-nDWEij_jk6M5K2Vk31RA-Yjd8F2M=.5b63da45-93c3-4251-9e2e-3c64b7953919@github.com>
 <x48Qtjsnz7ccoI5LdqiDmB8kO8FwmDjSE3ItYbtB4v0=.c22c1404-5766-4c32-a73a-a331cbe50f6d@github.com>
Message-ID: <RfM56uPYdCMn0gOxrmkcS09sF4lBgG1AZln7PdbKAdA=.96605d17-8a47-4494-b361-8b3783b7c201@github.com>

On Wed, 13 Aug 2025 09:35:08 GMT, Saranya Natarajan <snatarajan at openjdk.org> wrote:

>> **Issue**
>> Extreme values for BciProfileWidth flag such as `java -XX:BciProfileWidth=-1 -version` and `java -XX:BciProfileWidth=100000 -version `results in assert failure `assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x0000772b63a7a3a0 <= 0x0000772b63b75159 <= 0x0000772b63b75158 `. This is observed in a x86 machine.
>> 
>> **Analysis** 
>>  On debugging the issue, I found that increasing the size of the interpreter using the `InterpreterCodeSize` variable in `src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp` prevented the above mentioned assert from failing for large values of BciProfileWidth.  
>> 
>> **Proposal** 
>> Considering the fact that larger BciProfileWidth results in slower profiling, I have proposed a range between 0 to 5000 to restrict the value for BciProfileWidth for x86 machines. This maximum value is based on modifying the `InterpreterCodeSize` variable in `src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp` using the smallest `InterpreterCodeSize` for all the architectures.  As for the lower bound, a value of -1 would be the same as 0, as this simply means  no  return bci's will be recorded in ret profile. 
>> 
>> **Issue in AArch64**
>> Additionally running the command `java -XX:BciProfileWidth= 10000 -version` (or larger values) results in a different failure  `assert(offset_ok_for_immed(offset(), size)) failed: must be, was: 32768, 3` on an AArch64 machine.This is an issue of maximum offset for `ldr/str` in AArch64 which can be fixed using `form_address`  as mentioned in [JDK-8342736](https://bugs.openjdk.org/browse/JDK-8342736). In my preliminary fix using `form_address` on AArch64 machine. I had to modify 3 `ldr` and 1 `str` instruction (in file `src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp` at line number 926, 983, and 997). With this fix  using `form_address`, `BciProfileWidth` works for maximum of 5000 after which it crashes with`assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x0000772b63a7a3a0 <= 0x0000772b63b75159 <= 0x0000772b63b75158 `.  Without this fix `BciProfileWidth` works for a maximum value of 1300.   Currently, I have suggested to restrict the upper bound on AArch64 to 1000 instead
  of fixing it with `form_address`. 
>> 
>> **Question to reviewers**
>> Do you think this is a reasonable fix ?  For AArch64 do you suggest fixing using `form_address` ? If yes, do I fix it under this PR or create another one ?
>> 
>> **Request to port maintainers**
>> @dafedafe suggested that we keep the upper boun...
>
> Saranya Natarajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   additions for  linux-riscv64

LGTM. Thanks for the update!

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

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26139#pullrequestreview-3115891159

From azafari at openjdk.org  Wed Aug 13 13:40:21 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Wed, 13 Aug 2025 13:40:21 GMT
Subject: RFR: 8342730: Get rid of SummaryDiff in VMATree
Message-ID: <JShctGmb3UHnG21I3UAOCLu8b9KoGs8u9yO5iw_sUwc=.e0a33104-011f-47b0-bac4-59d18853c4c8@github.com>

`SummaryDiff` result of any `register_mapping()` call, is passed into the function rather than returned. This enables avoiding copying the structure to/from the stack.

Tests:
local linux-x64-debug: NMT gtests and JTREGs passed.

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

Commit messages:
 - 8342730: Get rid of SummaryDiff in VMATree

Changes: https://git.openjdk.org/jdk/pull/26761/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26761&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342730
  Stats: 367 lines in 9 files changed: 99 ins; 3 del; 265 mod
  Patch: https://git.openjdk.org/jdk/pull/26761.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26761/head:pull/26761

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

From kvn at openjdk.org  Wed Aug 13 20:11:46 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 13 Aug 2025 20:11:46 GMT
Subject: RFR: 8365512: Replace -Xcomp with -Xmixed for AOT assembly phase
Message-ID: <2FEKqWFIMsx4-EBHU9wabEh2mLUi8_WYsnRLBpSg96M=.b611f8e2-6f48-479a-8f89-0a351cc78d7f@github.com>

When debugging AOT code generation in Leyden repo I noticed that AOT JIT compilations are serial with -Xcomp even so we create a lot of compiler threads to speed up. It is because -Xcomp enforce blocking compilation and only one thread submits AOT compilations. Also -Xcomp triggers a lot more other, not AOT, compilations which we don't need during assembly phase.

I suggest to replace -Xcomp with -Xmixed for AOT assembly phase.

I want to push it into mainline first because in mainline we don't even do AOT compilation yet.

This should speed up AOT testing with -Xcomp.

Tested tier1-6,8,10 (-rt)

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

Commit messages:
 - 8365512: Replace -Xcomp with -Xmixed for AOT assembly phase

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

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

From sjohanss at openjdk.org  Thu Aug 14 08:05:17 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Thu, 14 Aug 2025 08:05:17 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v5]
In-Reply-To: <R5zawVwQKoUQAUOiGxy3bXsLJ8uuxU21AztKMu4hkhM=.0360b18b-0046-4491-a550-4c6b6fd75334@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <R5zawVwQKoUQAUOiGxy3bXsLJ8uuxU21AztKMu4hkhM=.0360b18b-0046-4491-a550-4c6b6fd75334@github.com>
Message-ID: <gGvBlaDob3SC_fl3j-Nwb-_ZBQyKO-kswVgxHTTxtAU=.7115d75f-85a9-4e7c-8679-3f1fdf5fa48b@github.com>

On Tue, 12 Aug 2025 12:24:35 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110).
>> 
>> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports:
>> 
>> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup()
>> 
>> CPUTimeUsage::GC::gc_threads()
>> CPUTimeUsage::GC::vm_thread()
>> CPUTimeUsage::GC::stringdedup()
>> 
>> CPUTimeUsage::Runtime::vm_thread()
>> 
>> 
>> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC.
>> 
>> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table:
>> 
>> 
>> [71.425s][info][cpu   ] === CPU time Statistics =============================================================
>> [71.425s][info][cpu   ]                                                                             CPUs
>> [71.425s][info][cpu   ]                                                                s       %  utilized
>> [71.425s][info][cpu   ]    Process
>> [71.425s][info][cpu   ]      Total                                             1616.3627  100.00      22.6
>> [71.425s][info][cpu   ]      VM Thread                                            5.2992    0.33       0.1
>> [71.425s][info][cpu   ]      Garbage Collection                                  83.7322    5.18       1.2
>> [71.425s][info][cpu   ]        GC Threads                                        82.7671    5.12       1.2
>> [71.425s][info][cpu   ]        VM Thread                                          0.9651    0.06       0.0
>> [71.425s][info][cpu   ] =====================================================================================
>> 
>> 
>> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback from Albert

Thanks for looking at this and improving the CPU tracking and making it easily accessible. 

Overall I think the change looks good, just a few comments/questions.

src/hotspot/os/linux/os_linux.cpp line 4953:

> 4951:       // to detach itself from the VM - which should result in ESRCH.
> 4952:       assert_status(rc == ESRCH, rc, "pthread_getcpuclockid failed");
> 4953:       log_warning(os)("Could not sample thread CPU time (return code %d)", rc);

Do we really want add a warning here? This API is used from a lot a places and reading the comment above i sound like it might happen from time to time without it being a very big deal?

The risk I see is that we sometimes will get a bunch of these warning in test and they will fail because we can't handle the additional output.

The same goes for the other warnings below.

src/hotspot/share/gc/shared/collectedHeap.cpp line 655:

> 653:   print_tracing_info();
> 654: 
> 655:   log_cpu_time();

As mentioned offline, I would prefer if this was moved away from `CollectedHeap` since it is now not only GC/Heap related times that are tracked. 

We could add a `Universe::before_exit()` which firsts does the CPU logging before calling `heap()->before_exit()`. As long as we do the logging before, would there be any problem with this?

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

Changes requested by sjohanss (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26621#pullrequestreview-3119416367
PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2275777432
PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2275805357

From duke at openjdk.org  Thu Aug 14 09:05:16 2025
From: duke at openjdk.org (snake66)
Date: Thu, 14 Aug 2025 09:05:16 GMT
Subject: RFR: 8263476: Use reserved memory for stack guard pages [v2]
In-Reply-To: <QppPdMuSxWNW4rgBTp_lscUg414JzuGXJj4HIB5VLEQ=.7f3a3057-a60e-4040-ac9a-dcfa935dde43@github.com>
References: <BojYWaP10BJMEWDQYSRiMKR0cOWzMF5At9_3fwD6uUw=.becf6902-01f1-41e0-965d-18a945a6dfcf@github.com>
 <wX8LHhAfHX8PKLH4XujwLo1j7090r8DOPfCgfphQ2-E=.608da498-cff0-4ec1-9dfe-3ae224a43e38@github.com>
 <kCfkFUEayVN9i8Kj-8CYM-muyRmhSk3NhaQlZ084c7w=.702feb04-eb64-439d-b0ae-8ad7b2a93375@github.com>
 <UD9VSnHOoTELaWXo7KyYT7LMIZBNiBj3wTVFiug8D2U=.0bc35853-312a-43ca-a0f3-a8c6ae2e4feb@github.com>
 <QppPdMuSxWNW4rgBTp_lscUg414JzuGXJj4HIB5VLEQ=.7f3a3057-a60e-4040-ac9a-dcfa935dde43@github.com>
Message-ID: <IP-0XHfQPVmaMb9K74FBo92JPx-oJh9eXjnhXkLD2iQ=.1cf23aac-2d64-49a4-ace1-8d900bf75b96@github.com>

On Fri, 8 Aug 2025 15:17:40 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Previously, we require stack-guard-pages to be committed, and mmap MAP_STACK does "lazy" commit, so we have to perform commit explicitly. Now, we switch to reserve-only stack-guard-pages, so no explicit commit is needed.
>
> Have you tested that on FreeBSD?

@tstuefe I have, and so far I can't see any negative effect of it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26571#discussion_r2275996829

From shade at openjdk.org  Thu Aug 14 10:25:00 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 14 Aug 2025 10:25:00 GMT
Subject: RFR: 8365165: Zap C-heap memory at delete/free
Message-ID: <ljSYFp1_TNhj2Vzf6uvNMbSCU0TqxRgR3nNFbXGoiVE=.8d31190f-3319-49a6-8c2f-94cb73e0d574@github.com>

We sometimes have a lifecycle problem with C-heap allocated objects. The most recent I dealt with is [JDK-8364501](https://bugs.openjdk.org/browse/JDK-8364501). It would be convenient to have diagnostic code to zap the memory that is freed on C heap. We already do this for alloc/realloc. When NMT is enabled (which it is for debug builds), we can also do this for frees, as NMT tells us the size of the free-ed block.

This PR introduces a new diagnostic flag to match other `Zap*` flags we already have, puts the zapping on free path, and wraps alloc/realloc zapping with the flag as well. The last part is not really necessary, but it is nicer to wrap zapping code with a flag like this, so we can disable it for testing performance. JCStress routinely opts-out of most of the zapping to gain higher sampling throughput on fastdebug builds.

Additional testing:
 - [x] Linux AArch64 server fastdebug, selectively rolling back [JDK-8364501](https://bugs.openjdk.org/browse/JDK-8364501) -- starts to immediately crash on reproducer
 - [ ] Linux AArch64 server fastdebug, `all` (no new crashes)
 - [ ] Linux x86_64 server fastdebug, `all` (no new crashes)

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

Commit messages:
 - More flag uses
 - Fix

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

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

From shade at openjdk.org  Thu Aug 14 11:28:18 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 14 Aug 2025 11:28:18 GMT
Subject: RFR: 8365512: Replace -Xcomp with -Xmixed for AOT assembly phase
In-Reply-To: <2FEKqWFIMsx4-EBHU9wabEh2mLUi8_WYsnRLBpSg96M=.b611f8e2-6f48-479a-8f89-0a351cc78d7f@github.com>
References: <2FEKqWFIMsx4-EBHU9wabEh2mLUi8_WYsnRLBpSg96M=.b611f8e2-6f48-479a-8f89-0a351cc78d7f@github.com>
Message-ID: <GuQTjZkq9sn8TeFNucgCsKdJn1qhzPLUhtlaqbaaWUg=.cc7322b2-4ed7-482e-b3de-cd3d58b5e789@github.com>

On Wed, 13 Aug 2025 20:03:43 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> When debugging AOT code generation in Leyden repo I noticed that AOT JIT compilations are serial with -Xcomp even so we create a lot of compiler threads to speed up. It is because -Xcomp enforce blocking compilation and only one thread submits AOT compilations. Also -Xcomp triggers a lot more other, not AOT, compilations which we don't need during assembly phase.
> 
> I suggest to replace -Xcomp with -Xmixed for AOT assembly phase.
> 
> I want to push it into mainline first because in mainline we don't even do AOT compilation yet.
> 
> This should speed up AOT testing with -Xcomp.
> 
> Tested tier1-6,8,10 (-rt)

This looks reasonable. I think the comment needs to be more explicit what and why we are doing this thing.

src/hotspot/share/cds/cdsConfig.cpp line 652:

> 650:         // -Xcomp triggers blocking compilation for all called methods,
> 651:         // but during AOT assembly phase we should AOT compile in parallel
> 652:         // (and not blocking) only methods collected during training run.

Suggestion:

        // Improve testing time with AOT and -Xcomp.
        // AOT assembly phase compiles methods collected during training run
        // with blocking compilation requests. There is no reason to compile the rest
        // of the core/infrastructure methods with aggressive/blocking compilation.

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

PR Review: https://git.openjdk.org/jdk/pull/26767#pullrequestreview-3120206347
PR Review Comment: https://git.openjdk.org/jdk/pull/26767#discussion_r2276353587

From sjohanss at openjdk.org  Thu Aug 14 11:30:18 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Thu, 14 Aug 2025 11:30:18 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v5]
In-Reply-To: <gGvBlaDob3SC_fl3j-Nwb-_ZBQyKO-kswVgxHTTxtAU=.7115d75f-85a9-4e7c-8679-3f1fdf5fa48b@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <R5zawVwQKoUQAUOiGxy3bXsLJ8uuxU21AztKMu4hkhM=.0360b18b-0046-4491-a550-4c6b6fd75334@github.com>
 <gGvBlaDob3SC_fl3j-Nwb-_ZBQyKO-kswVgxHTTxtAU=.7115d75f-85a9-4e7c-8679-3f1fdf5fa48b@github.com>
Message-ID: <cS5AxlzUZfGxn_j-M-Tz7IPlnh7MDeVFdAPq4DMEbfU=.957f5867-eca1-4cfe-9bac-b83f8756c653@github.com>

On Thu, 14 Aug 2025 07:49:26 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Feedback from Albert
>
> src/hotspot/os/linux/os_linux.cpp line 4953:
> 
>> 4951:       // to detach itself from the VM - which should result in ESRCH.
>> 4952:       assert_status(rc == ESRCH, rc, "pthread_getcpuclockid failed");
>> 4953:       log_warning(os)("Could not sample thread CPU time (return code %d)", rc);
> 
> Do we really want add a warning here? This API is used from a lot a places and reading the comment above i sound like it might happen from time to time without it being a very big deal?
> 
> The risk I see is that we sometimes will get a bunch of these warning in test and they will fail because we can't handle the additional output.
> 
> The same goes for the other warnings below.

Looked closer at the users of this and one user is `ThreadMXBean.getThreadCpuTime(long id)`. Looking at the API docs for that, returning -1 is not a error but the expected result for a terminated thread. So I think we should remove these warnings.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2276356967

From ayang at openjdk.org  Thu Aug 14 12:22:13 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 14 Aug 2025 12:22:13 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v5]
In-Reply-To: <cS5AxlzUZfGxn_j-M-Tz7IPlnh7MDeVFdAPq4DMEbfU=.957f5867-eca1-4cfe-9bac-b83f8756c653@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <R5zawVwQKoUQAUOiGxy3bXsLJ8uuxU21AztKMu4hkhM=.0360b18b-0046-4491-a550-4c6b6fd75334@github.com>
 <gGvBlaDob3SC_fl3j-Nwb-_ZBQyKO-kswVgxHTTxtAU=.7115d75f-85a9-4e7c-8679-3f1fdf5fa48b@github.com>
 <cS5AxlzUZfGxn_j-M-Tz7IPlnh7MDeVFdAPq4DMEbfU=.957f5867-eca1-4cfe-9bac-b83f8756c653@github.com>
Message-ID: <o0-H7tELe993CxAJeOGLFmHj1CBPCbbvjCvVSwj5Ww4=.a7565478-f8de-430f-b99e-77addf28b822@github.com>

On Thu, 14 Aug 2025 11:27:10 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> src/hotspot/os/linux/os_linux.cpp line 4953:
>> 
>>> 4951:       // to detach itself from the VM - which should result in ESRCH.
>>> 4952:       assert_status(rc == ESRCH, rc, "pthread_getcpuclockid failed");
>>> 4953:       log_warning(os)("Could not sample thread CPU time (return code %d)", rc);
>> 
>> Do we really want add a warning here? This API is used from a lot a places and reading the comment above i sound like it might happen from time to time without it being a very big deal?
>> 
>> The risk I see is that we sometimes will get a bunch of these warning in test and they will fail because we can't handle the additional output.
>> 
>> The same goes for the other warnings below.
>
> Looked closer at the users of this and one user is `ThreadMXBean.getThreadCpuTime(long id)`. Looking at the API docs for that, returning -1 is not a error but the expected result for a terminated thread. So I think we should remove these warnings.

> ... it might happen from time to time without it being a very big deal?

My concern is that we get a number on cpu-time without knowing the number is off by a large margin when failure occurs, so there should probably be some warning/msg somewhere.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2276473605

From duke at openjdk.org  Thu Aug 14 13:11:12 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 14 Aug 2025 13:11:12 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v5]
In-Reply-To: <o0-H7tELe993CxAJeOGLFmHj1CBPCbbvjCvVSwj5Ww4=.a7565478-f8de-430f-b99e-77addf28b822@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <R5zawVwQKoUQAUOiGxy3bXsLJ8uuxU21AztKMu4hkhM=.0360b18b-0046-4491-a550-4c6b6fd75334@github.com>
 <gGvBlaDob3SC_fl3j-Nwb-_ZBQyKO-kswVgxHTTxtAU=.7115d75f-85a9-4e7c-8679-3f1fdf5fa48b@github.com>
 <cS5AxlzUZfGxn_j-M-Tz7IPlnh7MDeVFdAPq4DMEbfU=.957f5867-eca1-4cfe-9bac-b83f8756c653@github.com>
 <o0-H7tELe993CxAJeOGLFmHj1CBPCbbvjCvVSwj5Ww4=.a7565478-f8de-430f-b99e-77addf28b822@github.com>
Message-ID: <yIoeSt75h8TpgAMPg7j2aTsL-G83QeeQDgd22ToDLQg=.f42807b5-a210-489f-8b31-db5b1c38808b@github.com>

On Thu, 14 Aug 2025 12:19:58 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Looked closer at the users of this and one user is `ThreadMXBean.getThreadCpuTime(long id)`. Looking at the API docs for that, returning -1 is not a error but the expected result for a terminated thread. So I think we should remove these warnings.
>
>> ... it might happen from time to time without it being a very big deal?
> 
> My concern is that we get a number on cpu-time without knowing the number is off by a large margin when failure occurs, so there should probably be some warning/msg somewhere.

I don't sample GC threads that have terminated, so I would prefer not having the warning as well, as it would not fail unless the machine is in a bad state and then we would have larger issues at hand anyways?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2276583734

From duke at openjdk.org  Thu Aug 14 13:11:14 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 14 Aug 2025 13:11:14 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v5]
In-Reply-To: <ScJxz_3oq2-HVbpfLTOAQBMRL89M3ntox_z2__y66sQ=.50bdac15-d68a-4fa1-8c9b-1a1793b05a82@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <R5zawVwQKoUQAUOiGxy3bXsLJ8uuxU21AztKMu4hkhM=.0360b18b-0046-4491-a550-4c6b6fd75334@github.com>
 <ScJxz_3oq2-HVbpfLTOAQBMRL89M3ntox_z2__y66sQ=.50bdac15-d68a-4fa1-8c9b-1a1793b05a82@github.com>
Message-ID: <QCEOIpsD9Z1ehlJ3JC_I5YSLk1K3p4lzFO2VT8x0vU8=.18470345-9342-4944-bf1b-524ff75d3452@github.com>

On Tue, 12 Aug 2025 15:17:19 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Feedback from Albert
>
> src/hotspot/share/gc/shared/collectedHeap.cpp line 610:
> 
>> 608: }
>> 609: 
>> 610: double percent_of(double component_cpu_time, double process_cpu_time) {
> 
> There is global function, `percent_of`. Can that be used directly?

Thanks! Certainly I misread your previous suggestion as a rename suggestion as I was not aware of that global function :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2276587345

From kvn at openjdk.org  Thu Aug 14 13:24:21 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 14 Aug 2025 13:24:21 GMT
Subject: RFR: 8365512: Replace -Xcomp with -Xmixed for AOT assembly phase
In-Reply-To: <GuQTjZkq9sn8TeFNucgCsKdJn1qhzPLUhtlaqbaaWUg=.cc7322b2-4ed7-482e-b3de-cd3d58b5e789@github.com>
References: <2FEKqWFIMsx4-EBHU9wabEh2mLUi8_WYsnRLBpSg96M=.b611f8e2-6f48-479a-8f89-0a351cc78d7f@github.com>
 <GuQTjZkq9sn8TeFNucgCsKdJn1qhzPLUhtlaqbaaWUg=.cc7322b2-4ed7-482e-b3de-cd3d58b5e789@github.com>
Message-ID: <5QTVKwG27CogDqah9nQXXIQco_IE8ak8sJunlPy0nUM=.0bc3a111-66c2-4ecb-a5bb-8a2b6bc0cf50@github.com>

On Thu, 14 Aug 2025 11:25:27 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> When debugging AOT code generation in Leyden repo I noticed that AOT JIT compilations are serial with -Xcomp even so we create a lot of compiler threads to speed up. It is because -Xcomp enforce blocking compilation and only one thread submits AOT compilations. Also -Xcomp triggers a lot more other, not AOT, compilations which we don't need during assembly phase.
>> 
>> I suggest to replace -Xcomp with -Xmixed for AOT assembly phase.
>> 
>> I want to push it into mainline first because in mainline we don't even do AOT compilation yet.
>> 
>> This should speed up AOT testing with -Xcomp.
>> 
>> Tested tier1-6,8,10 (-rt)
>
> src/hotspot/share/cds/cdsConfig.cpp line 652:
> 
>> 650:         // -Xcomp triggers blocking compilation for all called methods,
>> 651:         // but during AOT assembly phase we should AOT compile in parallel
>> 652:         // (and not blocking) only methods collected during training run.
> 
> Suggestion:
> 
>         // Improve testing time with AOT and -Xcomp.
>         // AOT assembly phase compiles methods collected during training run
>         // with blocking compilation requests. There is no reason to compile the rest
>         // of the core/infrastructure methods with aggressive/blocking compilation.

Thank you @shipilev for looking on this.

> with blocking compilation requests.

AOT compilation requests are not blocking. We submit bunch of requests for the same compilation level and only then wait when  queues are empty.

With -Xcomp we wait each compilation request. 

So I want to use "with non-blocking compilation requests. ". There rest of suggested comment is fine.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26767#discussion_r2276622448

From shade at openjdk.org  Thu Aug 14 13:43:13 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 14 Aug 2025 13:43:13 GMT
Subject: RFR: 8365512: Replace -Xcomp with -Xmixed for AOT assembly phase
In-Reply-To: <lUi8B3fCe9HRnO0DSPfAZ17tHPxtdLRLwWBejDtS5iI=.d9c5a193-2425-4e04-b6d5-23f96a9395f4@github.com>
References: <2FEKqWFIMsx4-EBHU9wabEh2mLUi8_WYsnRLBpSg96M=.b611f8e2-6f48-479a-8f89-0a351cc78d7f@github.com>
 <GuQTjZkq9sn8TeFNucgCsKdJn1qhzPLUhtlaqbaaWUg=.cc7322b2-4ed7-482e-b3de-cd3d58b5e789@github.com>
 <5QTVKwG27CogDqah9nQXXIQco_IE8ak8sJunlPy0nUM=.0bc3a111-66c2-4ecb-a5bb-8a2b6bc0cf50@github.com>
 <lUi8B3fCe9HRnO0DSPfAZ17tHPxtdLRLwWBejDtS5iI=.d9c5a193-2425-4e04-b6d5-23f96a9395f4@github.com>
Message-ID: <I5tZjnjNHWGZ3LbE7a-v2fg--FbhnD_MIOiErxt7ex4=.4cb0b1c6-d40b-4c50-b5d6-b0adb29d8254@github.com>

On Thu, 14 Aug 2025 13:36:54 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Thank you @shipilev for looking on this.
>> 
>>> with blocking compilation requests.
>> 
>> AOT compilation requests are not blocking. We submit bunch of requests for the same compilation level and only then wait when  queues are empty.
>> 
>> With -Xcomp we wait each compilation request. 
>> 
>> So I want to use "with non-blocking compilation requests. ". There rest of suggested comment is fine.
>
> Ah yes, right, d'uh. I wrote some of that code! Let me rewrite the comment...

// AOT assembly phase submits the non-blocking compilation requests 
        // for methods collected during training run, then waits for all compilations
        // to complete. With -Xcomp, we block for each compilation request, which is
        // counter-productive. Switching back to mixed mode improves testing time
        // with AOT and -Xcomp.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26767#discussion_r2276667953

From shade at openjdk.org  Thu Aug 14 13:43:12 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 14 Aug 2025 13:43:12 GMT
Subject: RFR: 8365512: Replace -Xcomp with -Xmixed for AOT assembly phase
In-Reply-To: <5QTVKwG27CogDqah9nQXXIQco_IE8ak8sJunlPy0nUM=.0bc3a111-66c2-4ecb-a5bb-8a2b6bc0cf50@github.com>
References: <2FEKqWFIMsx4-EBHU9wabEh2mLUi8_WYsnRLBpSg96M=.b611f8e2-6f48-479a-8f89-0a351cc78d7f@github.com>
 <GuQTjZkq9sn8TeFNucgCsKdJn1qhzPLUhtlaqbaaWUg=.cc7322b2-4ed7-482e-b3de-cd3d58b5e789@github.com>
 <5QTVKwG27CogDqah9nQXXIQco_IE8ak8sJunlPy0nUM=.0bc3a111-66c2-4ecb-a5bb-8a2b6bc0cf50@github.com>
Message-ID: <lUi8B3fCe9HRnO0DSPfAZ17tHPxtdLRLwWBejDtS5iI=.d9c5a193-2425-4e04-b6d5-23f96a9395f4@github.com>

On Thu, 14 Aug 2025 13:21:49 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> src/hotspot/share/cds/cdsConfig.cpp line 652:
>> 
>>> 650:         // -Xcomp triggers blocking compilation for all called methods,
>>> 651:         // but during AOT assembly phase we should AOT compile in parallel
>>> 652:         // (and not blocking) only methods collected during training run.
>> 
>> Suggestion:
>> 
>>         // Improve testing time with AOT and -Xcomp.
>>         // AOT assembly phase compiles methods collected during training run
>>         // with blocking compilation requests. There is no reason to compile the rest
>>         // of the core/infrastructure methods with aggressive/blocking compilation.
>
> Thank you @shipilev for looking on this.
> 
>> with blocking compilation requests.
> 
> AOT compilation requests are not blocking. We submit bunch of requests for the same compilation level and only then wait when  queues are empty.
> 
> With -Xcomp we wait each compilation request. 
> 
> So I want to use "with non-blocking compilation requests. ". There rest of suggested comment is fine.

Ah yes, right, d'uh. I wrote some of that code! Let me rewrite the comment...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26767#discussion_r2276663001

From kvn at openjdk.org  Thu Aug 14 13:54:27 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 14 Aug 2025 13:54:27 GMT
Subject: RFR: 8365512: Replace -Xcomp with -Xmixed for AOT assembly phase
 [v2]
In-Reply-To: <2FEKqWFIMsx4-EBHU9wabEh2mLUi8_WYsnRLBpSg96M=.b611f8e2-6f48-479a-8f89-0a351cc78d7f@github.com>
References: <2FEKqWFIMsx4-EBHU9wabEh2mLUi8_WYsnRLBpSg96M=.b611f8e2-6f48-479a-8f89-0a351cc78d7f@github.com>
Message-ID: <TvVFHdFf84uRnKC2LucQXjj5g9PQfgIKZUziZRxY0oU=.cb29b4c4-e1f0-4b9d-ac15-9c167d1912dd@github.com>

> When debugging AOT code generation in Leyden repo I noticed that AOT JIT compilations are serial with -Xcomp even so we create a lot of compiler threads to speed up. It is because -Xcomp enforce blocking compilation and only one thread submits AOT compilations. Also -Xcomp triggers a lot more other, not AOT, compilations which we don't need during assembly phase.
> 
> I suggest to replace -Xcomp with -Xmixed for AOT assembly phase.
> 
> I want to push it into mainline first because in mainline we don't even do AOT compilation yet.
> 
> This should speed up AOT testing with -Xcomp.
> 
> Tested tier1-6,8,10 (-rt)

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

  Update comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26767/files
  - new: https://git.openjdk.org/jdk/pull/26767/files/08bd075f..60861d3a

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

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

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

From kvn at openjdk.org  Thu Aug 14 13:54:28 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 14 Aug 2025 13:54:28 GMT
Subject: RFR: 8365512: Replace -Xcomp with -Xmixed for AOT assembly phase
 [v2]
In-Reply-To: <I5tZjnjNHWGZ3LbE7a-v2fg--FbhnD_MIOiErxt7ex4=.4cb0b1c6-d40b-4c50-b5d6-b0adb29d8254@github.com>
References: <2FEKqWFIMsx4-EBHU9wabEh2mLUi8_WYsnRLBpSg96M=.b611f8e2-6f48-479a-8f89-0a351cc78d7f@github.com>
 <GuQTjZkq9sn8TeFNucgCsKdJn1qhzPLUhtlaqbaaWUg=.cc7322b2-4ed7-482e-b3de-cd3d58b5e789@github.com>
 <5QTVKwG27CogDqah9nQXXIQco_IE8ak8sJunlPy0nUM=.0bc3a111-66c2-4ecb-a5bb-8a2b6bc0cf50@github.com>
 <lUi8B3fCe9HRnO0DSPfAZ17tHPxtdLRLwWBejDtS5iI=.d9c5a193-2425-4e04-b6d5-23f96a9395f4@github.com>
 <I5tZjnjNHWGZ3LbE7a-v2fg--FbhnD_MIOiErxt7ex4=.4cb0b1c6-d40b-4c50-b5d6-b0adb29d8254@github.com>
Message-ID: <yVsZ5g2Fhyp1a8gsYZI-vq18mw_WqLXmQxV3SCUNZCk=.ebf1585f-79b0-4cc1-bf74-99a4d99387e7@github.com>

On Thu, 14 Aug 2025 13:38:43 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Ah yes, right, d'uh. I wrote some of that code! Let me rewrite the comment...
>
> // AOT assembly phase submits the non-blocking compilation requests 
>         // for methods collected during training run, then waits for all compilations
>         // to complete. With -Xcomp, we block for each compilation request, which is
>         // counter-productive. Switching back to mixed mode improves testing time
>         // with AOT and -Xcomp.

I updated the comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26767#discussion_r2276702337

From mbaesken at openjdk.org  Thu Aug 14 13:55:32 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 14 Aug 2025 13:55:32 GMT
Subject: RFR: 8365146: Remove LockingMode related code from ppc64 [v2]
In-Reply-To: <rA67M2Y1gYxYTZ15p3zPqIdr1gX1Mc2eAO0Jfnb7lsM=.16065401-e8c1-4362-8961-032922277c81@github.com>
References: <mKtlz6j_OunSKwTrSfwVxcErf8oTsclqe65OSJxXvlw=.b958a3bc-0253-4efd-a9ff-03ac0418ba23@github.com>
 <101mw24zKLsjXjexjOZKimofI_yySxPw3gGyJq9HT1s=.495f1653-86ec-4d90-82d6-091b90d592f6@github.com>
 <rA67M2Y1gYxYTZ15p3zPqIdr1gX1Mc2eAO0Jfnb7lsM=.16065401-e8c1-4362-8961-032922277c81@github.com>
Message-ID: <dduSVDVHPu4yA1ABaVdgIZQoeP48nxDGeEiXFlmxp0U=.6cabde9e-f587-40d9-b18f-84e803f4af7a@github.com>

On Wed, 13 Aug 2025 09:04:33 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> I added your PR to our build/test queue !

With your patch added, on Linux ppc64le no issues were observed in our tests (jtreg + some internal tests).
(so far on AIX which is ppc64  bigendian no issues have been observed as well , I am not sure if your patch is influencing bigendian because you say 'This PR removes LockingMode related code from the ppc64le platform.' ) .

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

PR Comment: https://git.openjdk.org/jdk/pull/26697#issuecomment-3188540305

From shade at openjdk.org  Thu Aug 14 14:04:21 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 14 Aug 2025 14:04:21 GMT
Subject: RFR: 8365512: Replace -Xcomp with -Xmixed for AOT assembly phase
 [v2]
In-Reply-To: <TvVFHdFf84uRnKC2LucQXjj5g9PQfgIKZUziZRxY0oU=.cb29b4c4-e1f0-4b9d-ac15-9c167d1912dd@github.com>
References: <2FEKqWFIMsx4-EBHU9wabEh2mLUi8_WYsnRLBpSg96M=.b611f8e2-6f48-479a-8f89-0a351cc78d7f@github.com>
 <TvVFHdFf84uRnKC2LucQXjj5g9PQfgIKZUziZRxY0oU=.cb29b4c4-e1f0-4b9d-ac15-9c167d1912dd@github.com>
Message-ID: <OZThRcdpJFq6eOhuJVisEDzjOL59rSVHkaTzuAiuFEc=.90a6d61f-80d7-4a71-ae9d-92f736b47bb8@github.com>

On Thu, 14 Aug 2025 13:54:27 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> When debugging AOT code generation in Leyden repo I noticed that AOT JIT compilations are serial with -Xcomp even so we create a lot of compiler threads to speed up. It is because -Xcomp enforce blocking compilation and only one thread submits AOT compilations. Also -Xcomp triggers a lot more other, not AOT, compilations which we don't need during assembly phase.
>> 
>> I suggest to replace -Xcomp with -Xmixed for AOT assembly phase.
>> 
>> I want to push it into mainline first because in mainline we don't even do AOT compilation yet.
>> 
>> This should speed up AOT testing with -Xcomp.
>> 
>> Tested tier1-6,8,10 (-rt)
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update comment

Looks good!

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26767#pullrequestreview-3120726121

From kvn at openjdk.org  Thu Aug 14 14:10:17 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 14 Aug 2025 14:10:17 GMT
Subject: RFR: 8365512: Replace -Xcomp with -Xmixed for AOT assembly phase
 [v2]
In-Reply-To: <OZThRcdpJFq6eOhuJVisEDzjOL59rSVHkaTzuAiuFEc=.90a6d61f-80d7-4a71-ae9d-92f736b47bb8@github.com>
References: <2FEKqWFIMsx4-EBHU9wabEh2mLUi8_WYsnRLBpSg96M=.b611f8e2-6f48-479a-8f89-0a351cc78d7f@github.com>
 <TvVFHdFf84uRnKC2LucQXjj5g9PQfgIKZUziZRxY0oU=.cb29b4c4-e1f0-4b9d-ac15-9c167d1912dd@github.com>
 <OZThRcdpJFq6eOhuJVisEDzjOL59rSVHkaTzuAiuFEc=.90a6d61f-80d7-4a71-ae9d-92f736b47bb8@github.com>
Message-ID: <cuPkd-9bXjBU4rHjwFO9yyZ3v9LqkfQo4j-NkDkbhbE=.4b20f994-5f74-49dd-b4d1-dc97a1697310@github.com>

On Thu, 14 Aug 2025 14:02:00 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update comment
>
> Looks good!

Thank you @shipilev

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

PR Comment: https://git.openjdk.org/jdk/pull/26767#issuecomment-3188593258

From duke at openjdk.org  Thu Aug 14 14:12:18 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 14 Aug 2025 14:12:18 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v6]
In-Reply-To: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
Message-ID: <ad5DY2SsqO7vgu0f6q_eiabwSPRi2fhN_RV3GhcZTEY=.50c248b2-0834-4461-a136-972953578bc5@github.com>

> Hi all,
> 
> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110).
> 
> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports:
> 
> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup()
> 
> CPUTimeUsage::GC::gc_threads()
> CPUTimeUsage::GC::vm_thread()
> CPUTimeUsage::GC::stringdedup()
> 
> CPUTimeUsage::Runtime::vm_thread()
> 
> 
> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC.
> 
> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table:
> 
> 
> [71.425s][info][cpu   ] === CPU time Statistics =============================================================
> [71.425s][info][cpu   ]                                                                             CPUs
> [71.425s][info][cpu   ]                                                                s       %  utilized
> [71.425s][info][cpu   ]    Process
> [71.425s][info][cpu   ]      Total                                             1616.3627  100.00      22.6
> [71.425s][info][cpu   ]      VM Thread                                            5.2992    0.33       0.1
> [71.425s][info][cpu   ]      Garbage Collection                                  83.7322    5.18       1.2
> [71.425s][info][cpu   ]        GC Threads                                        82.7671    5.12       1.2
> [71.425s][info][cpu   ]        VM Thread                                          0.9651    0.06       0.0
> [71.425s][info][cpu   ] =====================================================================================
> 
> 
> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path.

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

 - Minor improvements and fixes per @kstefanj suggestions
 - use percent_of from globalDefinitions.hpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26621/files
  - new: https://git.openjdk.org/jdk/pull/26621/files/143fcacb..ddab1f0b

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

  Stats: 118 lines in 4 files changed: 60 ins; 57 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26621.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26621/head:pull/26621

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

From duke at openjdk.org  Thu Aug 14 14:12:21 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 14 Aug 2025 14:12:21 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v5]
In-Reply-To: <gGvBlaDob3SC_fl3j-Nwb-_ZBQyKO-kswVgxHTTxtAU=.7115d75f-85a9-4e7c-8679-3f1fdf5fa48b@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <R5zawVwQKoUQAUOiGxy3bXsLJ8uuxU21AztKMu4hkhM=.0360b18b-0046-4491-a550-4c6b6fd75334@github.com>
 <gGvBlaDob3SC_fl3j-Nwb-_ZBQyKO-kswVgxHTTxtAU=.7115d75f-85a9-4e7c-8679-3f1fdf5fa48b@github.com>
Message-ID: <Yxmr8aoGP6WDPBhO0GjM-T1wafn30W-8K083ylmGDB8=.1f3f0998-3734-482f-a37f-0f7d4d085a0a@github.com>

On Thu, 14 Aug 2025 08:02:45 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Feedback from Albert
>
> Thanks for looking at this and improving the CPU tracking and making it easily accessible. 
> 
> Overall I think the change looks good, just a few comments/questions.

Thanks for the review @kstefanj! I've pushed a patch reflecting your suggestions, but saved removal of log_warning until we have a consensus on a path forward.

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

PR Comment: https://git.openjdk.org/jdk/pull/26621#issuecomment-3188595880

From fbredberg at openjdk.org  Thu Aug 14 14:18:46 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 14 Aug 2025 14:18:46 GMT
Subject: RFR: 8365188: Remove LockingMode related code from s390
Message-ID: <xdOXPmKTkhBqJgMsl0kbtcuAtaHlLJevV7dM8fVecCY=.34afa6eb-bb0d-465b-bb25-2e6a6a052702@github.com>

Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.

This PR removes `LockingMode` related code from the **s390** platform.

When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.

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

Commit messages:
 - Merge branch 'master' into 8365188_remove_lockingmode_s390
 - 8365188: Remove LockingMode related code from s390

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

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

From fbredberg at openjdk.org  Thu Aug 14 14:18:46 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 14 Aug 2025 14:18:46 GMT
Subject: RFR: 8365188: Remove LockingMode related code from s390
In-Reply-To: <xdOXPmKTkhBqJgMsl0kbtcuAtaHlLJevV7dM8fVecCY=.34afa6eb-bb0d-465b-bb25-2e6a6a052702@github.com>
References: <xdOXPmKTkhBqJgMsl0kbtcuAtaHlLJevV7dM8fVecCY=.34afa6eb-bb0d-465b-bb25-2e6a6a052702@github.com>
Message-ID: <jBUm7M32txmMj_XKB6-9aMZEt39KKSg2eeg1C4yUi30=.6298a975-d184-42f8-ad1f-1e1b40a0f4c7@github.com>

On Thu, 14 Aug 2025 08:58:16 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
> 
> This PR removes `LockingMode` related code from the **s390** platform.
> 
> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.

@offamitkumar 
I've run rudimentary tests using QEMU, but it would be nice if you could take it for a spin on real hardware.

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

PR Comment: https://git.openjdk.org/jdk/pull/26772#issuecomment-3188610022

From fbredberg at openjdk.org  Thu Aug 14 14:38:11 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 14 Aug 2025 14:38:11 GMT
Subject: RFR: 8365146: Remove LockingMode related code from ppc64 [v2]
In-Reply-To: <dduSVDVHPu4yA1ABaVdgIZQoeP48nxDGeEiXFlmxp0U=.6cabde9e-f587-40d9-b18f-84e803f4af7a@github.com>
References: <mKtlz6j_OunSKwTrSfwVxcErf8oTsclqe65OSJxXvlw=.b958a3bc-0253-4efd-a9ff-03ac0418ba23@github.com>
 <101mw24zKLsjXjexjOZKimofI_yySxPw3gGyJq9HT1s=.495f1653-86ec-4d90-82d6-091b90d592f6@github.com>
 <rA67M2Y1gYxYTZ15p3zPqIdr1gX1Mc2eAO0Jfnb7lsM=.16065401-e8c1-4362-8961-032922277c81@github.com>
 <dduSVDVHPu4yA1ABaVdgIZQoeP48nxDGeEiXFlmxp0U=.6cabde9e-f587-40d9-b18f-84e803f4af7a@github.com>
Message-ID: <8TYedsslTEi01NjcSm_36HyQcPSA_lO9rcGm3eksey8=.c0b51ccc-a064-4f36-961b-9b544f5ed793@github.com>

On Thu, 14 Aug 2025 13:52:31 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> I added your PR to our build/test queue !
>
>> I added your PR to our build/test queue !
> 
> With your patch added, on Linux ppc64le no issues were observed in our tests (jtreg + some internal tests).
> (so far on AIX which is ppc64  bigendian no issues have been observed as well , I am not sure if your patch is influencing bigendian because you say 'This PR removes LockingMode related code from the ppc64le platform.' ) .

@MBaesken 
> I am not sure if your patch is influencing bigendian because you say 'This PR removes LockingMode related code from the ppc64le platform.' ) .

My patch should be totally endian-agnostic. It's just that our make system only seems to support `linux-ppc64le`.
I'll remove the `le` part from the description, hopefully that will prevent more people from being confused.
Anyhow, thanks for testing out the patch. Now I only need someone to review it as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/26697#issuecomment-3188688586

From kbarrett at openjdk.org  Thu Aug 14 22:36:10 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 14 Aug 2025 22:36:10 GMT
Subject: RFR: 8365165: Zap C-heap memory at delete/free
In-Reply-To: <ljSYFp1_TNhj2Vzf6uvNMbSCU0TqxRgR3nNFbXGoiVE=.8d31190f-3319-49a6-8c2f-94cb73e0d574@github.com>
References: <ljSYFp1_TNhj2Vzf6uvNMbSCU0TqxRgR3nNFbXGoiVE=.8d31190f-3319-49a6-8c2f-94cb73e0d574@github.com>
Message-ID: <fVGXjZVG8rPVMFsVhP0YQDK8EG_aasPBDlpS7a8WNqY=.0527b77b-f267-4706-b69b-d670d3b33e3a@github.com>

On Thu, 14 Aug 2025 10:16:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> We sometimes have a lifecycle problem with C-heap allocated objects. The most recent I dealt with is [JDK-8364501](https://bugs.openjdk.org/browse/JDK-8364501). It would be convenient to have diagnostic code to zap the memory that is freed on C heap. We already do this for alloc/realloc. When NMT is enabled (which it is for debug builds), we can also do this for frees, as NMT tells us the size of the free-ed block.
> 
> This PR introduces a new diagnostic flag to match other `Zap*` flags we already have, puts the zapping on free path, and wraps alloc/realloc zapping with the flag as well. The last part is not really necessary, but it is nicer to wrap zapping code with a flag like this, so we can disable it for testing performance. JCStress routinely opts-out of most of the zapping to gain higher sampling throughput on fastdebug builds.
> 
> Additional testing:
>  - [x] Linux AArch64 server fastdebug, selectively rolling back [JDK-8364501](https://bugs.openjdk.org/browse/JDK-8364501) -- starts to immediately crash on reproducer
>  - [x] Linux x86_64 server fastdebug, `all` (no new crashes, phew)
>  - [x] Linux AArch64 server fastdebug, `all` (no new crashes, phew)

src/hotspot/share/runtime/globals.hpp line 486:

> 484:           "Zap filler objects")                                             \
> 485:                                                                             \
> 486:   develop(bool, ZapCHeap, trueInDebug,                                      \

I have this vague recollection that maybe we used to do something like this, and decided to stop
because it really badly hurt performance in some cases. I know debug builds aren't expected to
be performant, but there's slow and then there's really unpleasant to use. Maybe make this
default to false and require explicit opt-in?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26775#discussion_r2277852056

From kvn at openjdk.org  Fri Aug 15 00:04:15 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 15 Aug 2025 00:04:15 GMT
Subject: Integrated: 8365512: Replace -Xcomp with -Xmixed for AOT assembly
 phase
In-Reply-To: <2FEKqWFIMsx4-EBHU9wabEh2mLUi8_WYsnRLBpSg96M=.b611f8e2-6f48-479a-8f89-0a351cc78d7f@github.com>
References: <2FEKqWFIMsx4-EBHU9wabEh2mLUi8_WYsnRLBpSg96M=.b611f8e2-6f48-479a-8f89-0a351cc78d7f@github.com>
Message-ID: <jPIXyVtGLdKGnNl-pGPHxoboGJ_UYea1C7BUw4fQRlw=.bf60df70-47f0-47a5-a29c-4ef5aa9f0550@github.com>

On Wed, 13 Aug 2025 20:03:43 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> When debugging AOT code generation in Leyden repo I noticed that AOT JIT compilations are serial with -Xcomp even so we create a lot of compiler threads to speed up. It is because -Xcomp enforce blocking compilation and only one thread submits AOT compilations. Also -Xcomp triggers a lot more other, not AOT, compilations which we don't need during assembly phase.
> 
> I suggest to replace -Xcomp with -Xmixed for AOT assembly phase.
> 
> I want to push it into mainline first because in mainline we don't even do AOT compilation yet.
> 
> This should speed up AOT testing with -Xcomp.
> 
> Tested tier1-6,8,10 (-rt)

This pull request has now been integrated.

Changeset: a65f2002
Author:    Vladimir Kozlov <kvn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a65f20022080e627da4782b9b643912a9dd69335
Stats:     11 lines in 1 file changed: 9 ins; 0 del; 2 mod

8365512: Replace -Xcomp with -Xmixed for AOT assembly phase

Reviewed-by: shade

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

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

From sjohanss at openjdk.org  Fri Aug 15 07:00:12 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Fri, 15 Aug 2025 07:00:12 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v5]
In-Reply-To: <yIoeSt75h8TpgAMPg7j2aTsL-G83QeeQDgd22ToDLQg=.f42807b5-a210-489f-8b31-db5b1c38808b@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <R5zawVwQKoUQAUOiGxy3bXsLJ8uuxU21AztKMu4hkhM=.0360b18b-0046-4491-a550-4c6b6fd75334@github.com>
 <gGvBlaDob3SC_fl3j-Nwb-_ZBQyKO-kswVgxHTTxtAU=.7115d75f-85a9-4e7c-8679-3f1fdf5fa48b@github.com>
 <cS5AxlzUZfGxn_j-M-Tz7IPlnh7MDeVFdAPq4DMEbfU=.957f5867-eca1-4cfe-9bac-b83f8756c653@github.com>
 <o0-H7tELe993CxAJeOGLFmHj1CBPCbbvjCvVSwj5Ww4=.a7565478-f8de-430f-b99e-77addf28b822@github.com>
 <yIoeSt75h8TpgAMPg7j2aTsL-G83QeeQDgd22ToDLQg=.f42807b5-a210-489f-8b31-db5b1c38808b@github.com>
Message-ID: <6XeFouUBD4PyYJbZ-YuwafTZIocx1tv8zYkrg_2y0BI=.d9a2dfd2-b005-4152-91ab-db4005cdb167@github.com>

On Thu, 14 Aug 2025 13:07:07 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>>> ... it might happen from time to time without it being a very big deal?
>> 
>> My concern is that we get a number on cpu-time without knowing the number is off by a large margin when failure occurs, so there should probably be some warning/msg somewhere.
>
> I don't sample GC threads that have terminated, so I would prefer not having the warning as well, as it would not fail unless the machine is in a bad state and then we would have larger issues at hand anyways?

> My concern is that we get a number on cpu-time without knowing the number is off by a large margin when failure occurs, so there should probably be some warning/msg somewhere.

Sure, that could be helpful. I don't think it should be a warning on the OS API though. Looking at the code a log message like that could be added to `CPUTimeThreadClosure::do_thread(...)`. To me it would be enough to have that on `log_info(cpu)` possibly even on debug-level. What do you think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2278420082

From mbaesken at openjdk.org  Fri Aug 15 07:21:12 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 15 Aug 2025 07:21:12 GMT
Subject: RFR: 8365146: Remove LockingMode related code from ppc64 [v2]
In-Reply-To: <101mw24zKLsjXjexjOZKimofI_yySxPw3gGyJq9HT1s=.495f1653-86ec-4d90-82d6-091b90d592f6@github.com>
References: <mKtlz6j_OunSKwTrSfwVxcErf8oTsclqe65OSJxXvlw=.b958a3bc-0253-4efd-a9ff-03ac0418ba23@github.com>
 <101mw24zKLsjXjexjOZKimofI_yySxPw3gGyJq9HT1s=.495f1653-86ec-4d90-82d6-091b90d592f6@github.com>
Message-ID: <OmP8d876PfLcF4qElWK9rZNin74y7VPThkA5UrdtcbY=.b7adb180-eece-4cc4-9b0d-8d8f662fefaf@github.com>

On Tue, 12 Aug 2025 13:12:33 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
>> 
>> This PR removes `LockingMode` related code from the **ppc64** platform.
>> 
>> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.
>
> Fredrik Bredberg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into 8365146_remove_lockingmode_ppc64
>  - 8365146: Remove LockingMode related code from ppc64

AIX tests are fine too.

> Anyhow, thanks for testing out the patch. Now I only need someone to review it as well.

I think Martin  @TheRealMDoerr will be back next week, he will probably look into it.

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

PR Comment: https://git.openjdk.org/jdk/pull/26697#issuecomment-3190826147

From ayang at openjdk.org  Fri Aug 15 08:08:13 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 15 Aug 2025 08:08:13 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v5]
In-Reply-To: <6XeFouUBD4PyYJbZ-YuwafTZIocx1tv8zYkrg_2y0BI=.d9a2dfd2-b005-4152-91ab-db4005cdb167@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <R5zawVwQKoUQAUOiGxy3bXsLJ8uuxU21AztKMu4hkhM=.0360b18b-0046-4491-a550-4c6b6fd75334@github.com>
 <gGvBlaDob3SC_fl3j-Nwb-_ZBQyKO-kswVgxHTTxtAU=.7115d75f-85a9-4e7c-8679-3f1fdf5fa48b@github.com>
 <cS5AxlzUZfGxn_j-M-Tz7IPlnh7MDeVFdAPq4DMEbfU=.957f5867-eca1-4cfe-9bac-b83f8756c653@github.com>
 <o0-H7tELe993CxAJeOGLFmHj1CBPCbbvjCvVSwj5Ww4=.a7565478-f8de-430f-b99e-77addf28b822@github.com>
 <yIoeSt75h8TpgAMPg7j2aTsL-G83QeeQDgd22ToDLQg=.f42807b5-a210-489f-8b31-db5b1c38808b@github.com>
 <6XeFouUBD4PyYJbZ-YuwafTZIocx1tv8zYkrg_2y0BI=.d9a2dfd2-b005-4152-91ab-db4005cdb167@github.com>
Message-ID: <YHjBFys5Pj9ZZNro4gMk-EHI6fFbHPnXgwmkvdsaQ2w=.4877c69c-805e-4b85-9b62-3153f3064c91@github.com>

On Fri, 15 Aug 2025 06:57:04 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>  I don't think it should be a warning on the OS API though.

Agree. At this level, returning `-1` already indicates the error -- callers should/can check the return-value and act on it.

> ... could be added to CPUTimeThreadClosure::do_thread(...)

There are dozens of callers though; `CPUTimeThreadClosure` is just one. For this particular patch, I think emitting some msg/warning somewhere inside `static void log_cpu_time` may be enough. WDYT?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2278499043

From sjohanss at openjdk.org  Fri Aug 15 08:27:12 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Fri, 15 Aug 2025 08:27:12 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v5]
In-Reply-To: <YHjBFys5Pj9ZZNro4gMk-EHI6fFbHPnXgwmkvdsaQ2w=.4877c69c-805e-4b85-9b62-3153f3064c91@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <R5zawVwQKoUQAUOiGxy3bXsLJ8uuxU21AztKMu4hkhM=.0360b18b-0046-4491-a550-4c6b6fd75334@github.com>
 <gGvBlaDob3SC_fl3j-Nwb-_ZBQyKO-kswVgxHTTxtAU=.7115d75f-85a9-4e7c-8679-3f1fdf5fa48b@github.com>
 <cS5AxlzUZfGxn_j-M-Tz7IPlnh7MDeVFdAPq4DMEbfU=.957f5867-eca1-4cfe-9bac-b83f8756c653@github.com>
 <o0-H7tELe993CxAJeOGLFmHj1CBPCbbvjCvVSwj5Ww4=.a7565478-f8de-430f-b99e-77addf28b822@github.com>
 <yIoeSt75h8TpgAMPg7j2aTsL-G83QeeQDgd22ToDLQg=.f42807b5-a210-489f-8b31-db5b1c38808b@github.com>
 <6XeFouUBD4PyYJbZ-YuwafTZIocx1tv8zYkrg_2y0BI=.d9a2dfd2-b005-4152-91ab-db4005cdb167@github.com>
 <YHjBFys5Pj9ZZNro4gMk-EHI6fFbHPnXgwmkvdsaQ2w=.4877c69c-805e-4b85-9b62-3153f3064c91@github.com>
Message-ID: <9BTb_r1e6tX82FC9MEZQi9XW3BpFQFkSBwGwYlYS-GE=.26214213-1f74-467c-b67d-103e2e1fcbae@github.com>

On Fri, 15 Aug 2025 08:05:06 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>>> My concern is that we get a number on cpu-time without knowing the number is off by a large margin when failure occurs, so there should probably be some warning/msg somewhere.
>> 
>> Sure, that could be helpful. I don't think it should be a warning on the OS API though. Looking at the code a log message like that could be added to `CPUTimeThreadClosure::do_thread(...)`. To me it would be enough to have that on `log_info(cpu)` possibly even on debug-level. What do you think?
>
>>  I don't think it should be a warning on the OS API though.
> 
> Agree. At this level, returning `-1` already indicates the error -- callers should/can check the return-value and act on it.
> 
>> ... could be added to CPUTimeThreadClosure::do_thread(...)
> 
> There are dozens of callers though; `CPUTimeThreadClosure` is just one. For this particular patch, I think emitting some msg/warning somewhere inside `static void log_cpu_time` may be enough. WDYT?

I don't have super strong opinion here, but to be able to add some message in `log_cpu_time` we would need to add logic to the `CPUTimeThreadClosure` to know if something went wrong or am I missing what you are suggesting? 

And that message would not know what thread we failed to measure, but the closure have that information.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2278524140

From ayang at openjdk.org  Fri Aug 15 08:45:12 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 15 Aug 2025 08:45:12 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v5]
In-Reply-To: <9BTb_r1e6tX82FC9MEZQi9XW3BpFQFkSBwGwYlYS-GE=.26214213-1f74-467c-b67d-103e2e1fcbae@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <R5zawVwQKoUQAUOiGxy3bXsLJ8uuxU21AztKMu4hkhM=.0360b18b-0046-4491-a550-4c6b6fd75334@github.com>
 <gGvBlaDob3SC_fl3j-Nwb-_ZBQyKO-kswVgxHTTxtAU=.7115d75f-85a9-4e7c-8679-3f1fdf5fa48b@github.com>
 <cS5AxlzUZfGxn_j-M-Tz7IPlnh7MDeVFdAPq4DMEbfU=.957f5867-eca1-4cfe-9bac-b83f8756c653@github.com>
 <o0-H7tELe993CxAJeOGLFmHj1CBPCbbvjCvVSwj5Ww4=.a7565478-f8de-430f-b99e-77addf28b822@github.com>
 <yIoeSt75h8TpgAMPg7j2aTsL-G83QeeQDgd22ToDLQg=.f42807b5-a210-489f-8b31-db5b1c38808b@github.com>
 <6XeFouUBD4PyYJbZ-YuwafTZIocx1tv8zYkrg_2y0BI=.d9a2dfd2-b005-4152-91ab-db4005cdb167@github.com>
 <YHjBFys5Pj9ZZNro4gMk-EHI6fFbHPnXgwmkvdsaQ2w=.4877c69c-805e-4b85-9b62-3153f3064c91@github.com>
 <9BTb_r1e6tX82FC9MEZQi9XW3BpFQFkSBwGwYlYS-GE=.26214213-1f74-467c-b67d-103e2e1fcbae@github.com>
Message-ID: <rlwaFxexzC5GYcLWSa0yk7ILusI3TOSGcClBybgB2B4=.e1cf3f57-0355-4b8d-89c7-4fff186aed23@github.com>

On Fri, 15 Aug 2025 08:24:38 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> ... am I missing what you are suggesting?

No. I think we are on the same page; I was more focusing on where the msg/warning will be, since this thread started with "Do we really want add a warning here?"

> And that message would not know what thread we failed to measure, but the closure have that information.

True; need to collect these info so that the printed msg/warning shows which thread(s) encountered a failure, if any.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2278547920

From ayang at openjdk.org  Fri Aug 15 10:18:09 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 15 Aug 2025 10:18:09 GMT
Subject: RFR: 8365188: Remove LockingMode related code from s390
In-Reply-To: <xdOXPmKTkhBqJgMsl0kbtcuAtaHlLJevV7dM8fVecCY=.34afa6eb-bb0d-465b-bb25-2e6a6a052702@github.com>
References: <xdOXPmKTkhBqJgMsl0kbtcuAtaHlLJevV7dM8fVecCY=.34afa6eb-bb0d-465b-bb25-2e6a6a052702@github.com>
Message-ID: <kVp_wIKVogXcH1tYoE4pLxHuksyNDXiVhMz2sESpuCY=.1b68cd59-48c5-4880-9871-7edeb842381e@github.com>

On Thu, 14 Aug 2025 08:58:16 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
> 
> This PR removes `LockingMode` related code from the **s390** platform.
> 
> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26772#pullrequestreview-3123536451

From ayang at openjdk.org  Fri Aug 15 10:38:17 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 15 Aug 2025 10:38:17 GMT
Subject: RFR: 8364723: Sort share/interpreter includes
In-Reply-To: <7qTazdkllXqIeG4psogIJvNAWxhZWwDoqqy_2ScIfzY=.f0aaf1e9-b7d3-45ed-b81d-6f37408bf93f@github.com>
References: <7qTazdkllXqIeG4psogIJvNAWxhZWwDoqqy_2ScIfzY=.f0aaf1e9-b7d3-45ed-b81d-6f37408bf93f@github.com>
Message-ID: <Cjp8vinDlDimeiNCLE8E_Un2bRsDqa-yPn92YlELO1g=.d635f37d-11c3-4558-8338-ed6ba910fca8@github.com>

On Tue, 5 Aug 2025 10:38:11 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> This PR sorts the includes in `hotspot/share/interpreter` using SortIncludes.java. I'm also adding the directory to TestIncludesAreSorted.
> 
> Passes tier1.

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26639#pullrequestreview-3123571394

From duke at openjdk.org  Fri Aug 15 10:41:12 2025
From: duke at openjdk.org (duke)
Date: Fri, 15 Aug 2025 10:41:12 GMT
Subject: RFR: 8364723: Sort share/interpreter includes
In-Reply-To: <7qTazdkllXqIeG4psogIJvNAWxhZWwDoqqy_2ScIfzY=.f0aaf1e9-b7d3-45ed-b81d-6f37408bf93f@github.com>
References: <7qTazdkllXqIeG4psogIJvNAWxhZWwDoqqy_2ScIfzY=.f0aaf1e9-b7d3-45ed-b81d-6f37408bf93f@github.com>
Message-ID: <ynuMwWcMWqjEmuKrgr7_QVe1yGAhO1OKW4nCvFsfMUY=.0f634530-517e-4328-b581-7cc288539bdc@github.com>

On Tue, 5 Aug 2025 10:38:11 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> This PR sorts the includes in `hotspot/share/interpreter` using SortIncludes.java. I'm also adding the directory to TestIncludesAreSorted.
> 
> Passes tier1.

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

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

PR Comment: https://git.openjdk.org/jdk/pull/26639#issuecomment-3191221449

From duke at openjdk.org  Fri Aug 15 10:48:23 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Fri, 15 Aug 2025 10:48:23 GMT
Subject: Integrated: 8364723: Sort share/interpreter includes
In-Reply-To: <7qTazdkllXqIeG4psogIJvNAWxhZWwDoqqy_2ScIfzY=.f0aaf1e9-b7d3-45ed-b81d-6f37408bf93f@github.com>
References: <7qTazdkllXqIeG4psogIJvNAWxhZWwDoqqy_2ScIfzY=.f0aaf1e9-b7d3-45ed-b81d-6f37408bf93f@github.com>
Message-ID: <EWiZWH268mSEfVkon9r7r2XOIRQXB1AYwldg1rWEvNA=.c8c29630-9fc1-41af-a6c9-83546093961f@github.com>

On Tue, 5 Aug 2025 10:38:11 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> This PR sorts the includes in `hotspot/share/interpreter` using SortIncludes.java. I'm also adding the directory to TestIncludesAreSorted.
> 
> Passes tier1.

This pull request has now been integrated.

Changeset: dbae90c9
Author:    Francesco Andreuzzi <andreuzzi.francesco at gmail.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dbae90c950200cb417aebeab65e5fce7a7e5f94f
Stats:     31 lines in 12 files changed: 14 ins; 17 del; 0 mod

8364723: Sort share/interpreter includes

Reviewed-by: shade, ayang

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

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

From duke at openjdk.org  Fri Aug 15 11:07:58 2025
From: duke at openjdk.org (Anton Artemov)
Date: Fri, 15 Aug 2025 11:07:58 GMT
Subject: RFR: 8365556: ObjectMonitor::try_lock_or_add_to_entry_list() returns
 true with the wrong state of the node
Message-ID: <YUOnpPZ57q-9oW7npgsONxWYI6K-FdUtvmSNzIO7w1Q=.06f70f3d-17e7-4583-9890-fe52d7a7af13@github.com>

Hi, please consider the following change:

ObjectMonitor::try_lock_or_add_to_entry_list() does not change the node state to TS_RUN in case of a successful acquisition of the object monitor. In certain cases this can brake the guarantee statement in the ObjectMonitor::wait() method and lead to a crash. The missing statement is added.

Tested in tiers 1 - 5.

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

Commit messages:
 - 8365556: Added missed statement for changing the node state to TS_RUN

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

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

From fbredberg at openjdk.org  Fri Aug 15 11:35:12 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Fri, 15 Aug 2025 11:35:12 GMT
Subject: RFR: 8365556: ObjectMonitor::try_lock_or_add_to_entry_list()
 returns true with the wrong state of the node
In-Reply-To: <YUOnpPZ57q-9oW7npgsONxWYI6K-FdUtvmSNzIO7w1Q=.06f70f3d-17e7-4583-9890-fe52d7a7af13@github.com>
References: <YUOnpPZ57q-9oW7npgsONxWYI6K-FdUtvmSNzIO7w1Q=.06f70f3d-17e7-4583-9890-fe52d7a7af13@github.com>
Message-ID: <8mUsAyokuBN11rbQOVQd5Sfar4cav6GWZTiZk8HrMeY=.617fa727-f241-47eb-8e43-d020fdfba621@github.com>

On Fri, 15 Aug 2025 07:22:02 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following change:
> 
> ObjectMonitor::try_lock_or_add_to_entry_list() does not change the node state to TS_RUN in case of a successful acquisition of the object monitor. In certain cases this can brake the guarantee statement in the ObjectMonitor::wait() method and lead to a crash. The missing statement is added.
> 
> Tested in tiers 1 - 5.

Thank you @toxaart for spotting, and fixing this.

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

Marked as reviewed by fbredberg (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26794#pullrequestreview-3123658866

From mbaesken at openjdk.org  Fri Aug 15 12:20:59 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 15 Aug 2025 12:20:59 GMT
Subject: RFR: 8359423: Improve error message in case of missing jsa shared
 archive [v2]
In-Reply-To: <LhjB0rkam9i1mj-8tnIqR9Ldwe68b5CUPJZwrak0mVk=.05e3b934-3495-4b1f-9045-db5ec9647332@github.com>
References: <LhjB0rkam9i1mj-8tnIqR9Ldwe68b5CUPJZwrak0mVk=.05e3b934-3495-4b1f-9045-db5ec9647332@github.com>
Message-ID: <hOolAOhxS2vIQyWChg9HU8PcFM_M6Ck3H737_hWj8ec=.8b6f4426-062d-4f87-bcd9-d00091c58912@github.com>

> In case we use `-Xshare:on` with additional flags (regarding coh or coops) and we have the corresponding jsa archive not present,
> we get this message/error :
> 
> 
> Error occurred during initialization of VM
> Unable to use shared archive.
> 
> 
> The error message could be a little improved, e.g. telling what jsa file is not present .
> For example
> 
> 
> ./images/jdk/bin/java -Xshare:on -version
> [0.017s][error][aot] Opening of static archive /build_linux/images/jdk/lib/server/classes.jsa failed
> Error occurred during initialization of VM
> Unable to use shared archive (unrecoverable archive loading error).

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

 - Merge remote-tracking branch 'origin/master' into JDK-8359423
 - Adjust log message in metaspaceShared
 - JDK-8359423

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25846/files
  - new: https://git.openjdk.org/jdk/pull/25846/files/df28ad45..8858819d

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

  Stats: 100931 lines in 2548 files changed: 54925 ins; 30873 del; 15133 mod
  Patch: https://git.openjdk.org/jdk/pull/25846.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25846/head:pull/25846

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

From fbredberg at openjdk.org  Fri Aug 15 12:44:22 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Fri, 15 Aug 2025 12:44:22 GMT
Subject: RFR: 8365189: Remove LockingMode related code from arm32
Message-ID: <bvw0sMNTLzhoms1UW34LXiFrkKDysBfeLAQftPjBh5o=.ddd3c817-4094-4cfe-afa2-4c751eae6814@github.com>

Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.

This PR removes `LockingMode` related code from the **arm32** platform.

When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.

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

Commit messages:
 - 8365189: Remove LockingMode related code from arm32

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

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

From fbredberg at openjdk.org  Fri Aug 15 12:44:22 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Fri, 15 Aug 2025 12:44:22 GMT
Subject: RFR: 8365189: Remove LockingMode related code from arm32
In-Reply-To: <bvw0sMNTLzhoms1UW34LXiFrkKDysBfeLAQftPjBh5o=.ddd3c817-4094-4cfe-afa2-4c751eae6814@github.com>
References: <bvw0sMNTLzhoms1UW34LXiFrkKDysBfeLAQftPjBh5o=.ddd3c817-4094-4cfe-afa2-4c751eae6814@github.com>
Message-ID: <ObdNVa5OnCj-R2Nx01CHQ3LwUfhmchcTwi7NLy-9PNo=.6d64d0f0-47ca-49f2-ac9a-e21be9f03090@github.com>

On Fri, 15 Aug 2025 09:29:04 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
> 
> This PR removes `LockingMode` related code from the **arm32** platform.
> 
> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.

@bulasevich
I've run rudimentary tests using QEMU, but it would be nice if you could take it for a spin on real hardware.

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

PR Comment: https://git.openjdk.org/jdk/pull/26795#issuecomment-3191412145

From shade at openjdk.org  Fri Aug 15 12:55:11 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 15 Aug 2025 12:55:11 GMT
Subject: RFR: 8365165: Zap C-heap memory at delete/free
In-Reply-To: <fVGXjZVG8rPVMFsVhP0YQDK8EG_aasPBDlpS7a8WNqY=.0527b77b-f267-4706-b69b-d670d3b33e3a@github.com>
References: <ljSYFp1_TNhj2Vzf6uvNMbSCU0TqxRgR3nNFbXGoiVE=.8d31190f-3319-49a6-8c2f-94cb73e0d574@github.com>
 <fVGXjZVG8rPVMFsVhP0YQDK8EG_aasPBDlpS7a8WNqY=.0527b77b-f267-4706-b69b-d670d3b33e3a@github.com>
Message-ID: <j2beWDYdbjLDjpeacrAgAJYSleYPTGtNuLUIj0pNwF0=.bd85fabb-c6e0-405f-80bc-938060fa6455@github.com>

On Thu, 14 Aug 2025 22:33:35 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> We sometimes have a lifecycle problem with C-heap allocated objects. The most recent I dealt with is [JDK-8364501](https://bugs.openjdk.org/browse/JDK-8364501). It would be convenient to have diagnostic code to zap the memory that is freed on C heap. We already do this for alloc/realloc. When NMT is enabled (which it is for debug builds), we can also do this for frees, as NMT tells us the size of the free-ed block.
>> 
>> This PR introduces a new diagnostic flag to match other `Zap*` flags we already have, puts the zapping on free path, and wraps alloc/realloc zapping with the flag as well. The last part is not really necessary, but it is nicer to wrap zapping code with a flag like this, so we can disable it for testing performance. JCStress routinely opts-out of most of the zapping to gain higher sampling throughput on fastdebug builds.
>> 
>> Additional testing:
>>  - [x] Linux AArch64 server fastdebug, selectively rolling back [JDK-8364501](https://bugs.openjdk.org/browse/JDK-8364501) -- starts to immediately crash on reproducer
>>  - [x] Linux x86_64 server fastdebug, `all` (no new crashes, phew)
>>  - [x] Linux AArch64 server fastdebug, `all` (no new crashes, phew)
>
> src/hotspot/share/runtime/globals.hpp line 486:
> 
>> 484:           "Zap filler objects")                                             \
>> 485:                                                                             \
>> 486:   develop(bool, ZapCHeap, trueInDebug,                                      \
> 
> I have this vague recollection that maybe we used to do something like this, and decided to stop
> because it really badly hurt performance in some cases. I know debug builds aren't expected to
> be performant, but there's slow and then there's really unpleasant to use. Maybe make this
> default to false and require explicit opt-in?

This is a legitimate concern. We have been optimizing/guarding zapping code over the years, because excessive zapping is sometimes not worth it. That said, the utility for diagnostic zapping lies in being enabled by default. If we had this zapping in place, [JDK-8364501](https://bugs.openjdk.org/browse/JDK-8364501) would have been trivial to find. So we already know it is useful.

To estimate rough costs of doing this extra work, I ran Linux x86_64 server fastdebug `tier1` with and without the patch, and here are the results:


# Before
62589.94s user 5358.93s system 4015% cpu 28:16.24 total
62453.49s user 5388.42s system 3993% cpu 28:18.60 total
62363.92s user 5347.49s system 3976% cpu 28:22.75 total

# After
62803.82s user 5350.01s system 3983% cpu 28:31.05 total
63868.84s user 5415.74s system 3997% cpu 28:33.04 total
63864.74s user 5521.71s system 4051% cpu 28:37.57 total


So there is an impact, but I will hard-pressed to call it really bad. 

The upside for this PR is that we can now summarily turn off malloc/realloc/free zapping, if we want to.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26775#discussion_r2278938398

From pchilanomate at openjdk.org  Fri Aug 15 13:47:13 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 15 Aug 2025 13:47:13 GMT
Subject: RFR: 8365556: ObjectMonitor::try_lock_or_add_to_entry_list()
 returns true with the wrong state of the node
In-Reply-To: <YUOnpPZ57q-9oW7npgsONxWYI6K-FdUtvmSNzIO7w1Q=.06f70f3d-17e7-4583-9890-fe52d7a7af13@github.com>
References: <YUOnpPZ57q-9oW7npgsONxWYI6K-FdUtvmSNzIO7w1Q=.06f70f3d-17e7-4583-9890-fe52d7a7af13@github.com>
Message-ID: <c6EUav8IeQcAWDEBBJieXhXXwbO6gkuSJaj8dtZMhvQ=.a2528c64-29c6-486f-8c58-4605eeecea54@github.com>

On Fri, 15 Aug 2025 07:22:02 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following change:
> 
> `ObjectMonitor::try_lock_or_add_to_entry_list() `does not change the node state to `TS_RUN `in case of a successful acquisition of the object monitor. In certain cases this can break the guarantee statement in the `ObjectMonitor::wait()` method and lead to a crash. The missing statement is added.
> 
> Tested in tiers 1 - 5.

Looks fine, but I don?t see how `ObjectMonitor::wait` would crash without this. Were you experimenting with some additional changes?

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

PR Comment: https://git.openjdk.org/jdk/pull/26794#issuecomment-3191535419

From duke at openjdk.org  Fri Aug 15 13:57:09 2025
From: duke at openjdk.org (Anton Artemov)
Date: Fri, 15 Aug 2025 13:57:09 GMT
Subject: RFR: 8365556: ObjectMonitor::try_lock_or_add_to_entry_list()
 returns true with the wrong state of the node
In-Reply-To: <c6EUav8IeQcAWDEBBJieXhXXwbO6gkuSJaj8dtZMhvQ=.a2528c64-29c6-486f-8c58-4605eeecea54@github.com>
References: <YUOnpPZ57q-9oW7npgsONxWYI6K-FdUtvmSNzIO7w1Q=.06f70f3d-17e7-4583-9890-fe52d7a7af13@github.com>
 <c6EUav8IeQcAWDEBBJieXhXXwbO6gkuSJaj8dtZMhvQ=.a2528c64-29c6-486f-8c58-4605eeecea54@github.com>
Message-ID: <3y8NtAzNxRQ4Gf5kEgLL75nZ3e7VDjSajdNyqa1dWSE=.9b29d0fa-951f-4ab2-8815-72b310f7adec@github.com>

On Fri, 15 Aug 2025 13:44:10 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Looks fine, but I don?t see how `ObjectMonitor::wait` would crash without this. Were you experimenting with some additional changes?

Yes I was, but I think a crash is possible even with the current state of things. The path I was thinking is: `wait() -> enter() -> enter_with_contention_mark() -> enter_internal() -> try_lock_or_add_to_entry_list()`. I think a guarantee statement on line 1944 would be broken if `try_lock_or_add_to_entry_list()` returned true without changing the state.

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

PR Comment: https://git.openjdk.org/jdk/pull/26794#issuecomment-3191558144

From pchilanomate at openjdk.org  Fri Aug 15 14:01:11 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 15 Aug 2025 14:01:11 GMT
Subject: RFR: 8365556: ObjectMonitor::try_lock_or_add_to_entry_list()
 returns true with the wrong state of the node
In-Reply-To: <3y8NtAzNxRQ4Gf5kEgLL75nZ3e7VDjSajdNyqa1dWSE=.9b29d0fa-951f-4ab2-8815-72b310f7adec@github.com>
References: <YUOnpPZ57q-9oW7npgsONxWYI6K-FdUtvmSNzIO7w1Q=.06f70f3d-17e7-4583-9890-fe52d7a7af13@github.com>
 <c6EUav8IeQcAWDEBBJieXhXXwbO6gkuSJaj8dtZMhvQ=.a2528c64-29c6-486f-8c58-4605eeecea54@github.com>
 <3y8NtAzNxRQ4Gf5kEgLL75nZ3e7VDjSajdNyqa1dWSE=.9b29d0fa-951f-4ab2-8815-72b310f7adec@github.com>
Message-ID: <WOr52emxmYwi5Tc7Ca99oaceE9vBZYO6tYR18jhuNU8=.d9f50303-c1d7-4779-8aa3-bbcc5af38cf9@github.com>

On Fri, 15 Aug 2025 13:53:48 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Yes I was, but I think a crash is possible even with the current state of things. The path I was thinking is: `wait() -> enter() -> enter_with_contention_mark() -> enter_internal() -> try_lock_or_add_to_entry_list()`. I think a guarantee statement on line 1944 would be broken if `try_lock_or_add_to_entry_list()` returned true without changing the state.
>
Right, but note that in that path we create a new `ObjectWaiter`. The one referenced in the assert on line 1944 is the original one.

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

PR Comment: https://git.openjdk.org/jdk/pull/26794#issuecomment-3191568445

From duke at openjdk.org  Fri Aug 15 14:04:09 2025
From: duke at openjdk.org (Anton Artemov)
Date: Fri, 15 Aug 2025 14:04:09 GMT
Subject: RFR: 8365556: ObjectMonitor::try_lock_or_add_to_entry_list()
 returns true with the wrong state of the node
In-Reply-To: <WOr52emxmYwi5Tc7Ca99oaceE9vBZYO6tYR18jhuNU8=.d9f50303-c1d7-4779-8aa3-bbcc5af38cf9@github.com>
References: <YUOnpPZ57q-9oW7npgsONxWYI6K-FdUtvmSNzIO7w1Q=.06f70f3d-17e7-4583-9890-fe52d7a7af13@github.com>
 <c6EUav8IeQcAWDEBBJieXhXXwbO6gkuSJaj8dtZMhvQ=.a2528c64-29c6-486f-8c58-4605eeecea54@github.com>
 <3y8NtAzNxRQ4Gf5kEgLL75nZ3e7VDjSajdNyqa1dWSE=.9b29d0fa-951f-4ab2-8815-72b310f7adec@github.com>
 <WOr52emxmYwi5Tc7Ca99oaceE9vBZYO6tYR18jhuNU8=.d9f50303-c1d7-4779-8aa3-bbcc5af38cf9@github.com>
Message-ID: <eJPm_NEiRoU3GnEdRoELrfmTw-WZHNmWBB9tAy4R9Lk=.2366fbac-691d-4604-83ba-8d39d3a6b9b1@github.com>

On Fri, 15 Aug 2025 13:58:43 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> > Yes I was, but I think a crash is possible even with the current state of things. The path I was thinking is: `wait() -> enter() -> enter_with_contention_mark() -> enter_internal() -> try_lock_or_add_to_entry_list()`. I think a guarantee statement on line 1944 would be broken if `try_lock_or_add_to_entry_list()` returned true without changing the state.
> 
> Right, but note that in that path we create a new `ObjectWaiter`. The one referenced in the assert on line 1944 is the original one.

Yes, a part of my changes was fiddling with an ObjectWaiter object. So I made a different flow. Nevertheless, this has to be fixed, because it is not correct.

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

PR Comment: https://git.openjdk.org/jdk/pull/26794#issuecomment-3191575780

From stuefe at openjdk.org  Fri Aug 15 14:17:11 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 15 Aug 2025 14:17:11 GMT
Subject: RFR: 8365165: Zap C-heap memory at delete/free
In-Reply-To: <j2beWDYdbjLDjpeacrAgAJYSleYPTGtNuLUIj0pNwF0=.bd85fabb-c6e0-405f-80bc-938060fa6455@github.com>
References: <ljSYFp1_TNhj2Vzf6uvNMbSCU0TqxRgR3nNFbXGoiVE=.8d31190f-3319-49a6-8c2f-94cb73e0d574@github.com>
 <fVGXjZVG8rPVMFsVhP0YQDK8EG_aasPBDlpS7a8WNqY=.0527b77b-f267-4706-b69b-d670d3b33e3a@github.com>
 <j2beWDYdbjLDjpeacrAgAJYSleYPTGtNuLUIj0pNwF0=.bd85fabb-c6e0-405f-80bc-938060fa6455@github.com>
Message-ID: <D9SLpxKYhFyy74tp6EaDn_Bc4I5oZXgt3he8e5imZQY=.e89d152c-b6c3-441e-b176-f04c57b290d6@github.com>

On Fri, 15 Aug 2025 12:52:28 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/share/runtime/globals.hpp line 486:
>> 
>>> 484:           "Zap filler objects")                                             \
>>> 485:                                                                             \
>>> 486:   develop(bool, ZapCHeap, trueInDebug,                                      \
>> 
>> I have this vague recollection that maybe we used to do something like this, and decided to stop
>> because it really badly hurt performance in some cases. I know debug builds aren't expected to
>> be performant, but there's slow and then there's really unpleasant to use. Maybe make this
>> default to false and require explicit opt-in?
>
> This is a legitimate concern. We have been optimizing/guarding zapping code over the years, because excessive zapping is sometimes not worth it. That said, the utility for diagnostic zapping lies in being enabled by default. If we had this zapping in place, [JDK-8364501](https://bugs.openjdk.org/browse/JDK-8364501) would have been trivial to find. So we already know it is useful.
> 
> To estimate rough costs of doing this extra work, I ran Linux x86_64 server fastdebug `tier1` with and without the patch, and here are the results:
> 
> 
> # Before
> 62589.94s user 5358.93s system 4015% cpu 28:16.24 total
> 62453.49s user 5388.42s system 3993% cpu 28:18.60 total
> 62363.92s user 5347.49s system 3976% cpu 28:22.75 total
> 
> # After
> 62803.82s user 5350.01s system 3983% cpu 28:31.05 total
> 63868.84s user 5415.74s system 3997% cpu 28:33.04 total
> 63864.74s user 5521.71s system 4051% cpu 28:37.57 total
> 
> 
> So there is an impact, but I will hard-pressed to call it really bad. 
> 
> The upside for this PR is that we can now summarily turn off malloc/realloc/free zapping, if we want to.

+1. Ideally, `os::malloc` and friends should not be terribly hot. That's why we have custom allocators for heavy fine-grained use cases like C2. 

`ZapCHeap` may be a bit misleading as a name, since all it does is zap on free. 

Zap on malloc would also be useful. If we are worried about speed, zapping the 1-2 words would already give 95% of effect, since that is in high likelyhood the later location for some important struct members. And there is some probability that the libc touches memory in the vicinity of the block start during allocation, so it's probably already paged in.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26775#discussion_r2279071437

From fbredberg at openjdk.org  Fri Aug 15 14:34:09 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Fri, 15 Aug 2025 14:34:09 GMT
Subject: RFR: 8365556: ObjectMonitor::try_lock_or_add_to_entry_list()
 returns true with the wrong state of the node
In-Reply-To: <eJPm_NEiRoU3GnEdRoELrfmTw-WZHNmWBB9tAy4R9Lk=.2366fbac-691d-4604-83ba-8d39d3a6b9b1@github.com>
References: <YUOnpPZ57q-9oW7npgsONxWYI6K-FdUtvmSNzIO7w1Q=.06f70f3d-17e7-4583-9890-fe52d7a7af13@github.com>
 <c6EUav8IeQcAWDEBBJieXhXXwbO6gkuSJaj8dtZMhvQ=.a2528c64-29c6-486f-8c58-4605eeecea54@github.com>
 <3y8NtAzNxRQ4Gf5kEgLL75nZ3e7VDjSajdNyqa1dWSE=.9b29d0fa-951f-4ab2-8815-72b310f7adec@github.com>
 <WOr52emxmYwi5Tc7Ca99oaceE9vBZYO6tYR18jhuNU8=.d9f50303-c1d7-4779-8aa3-bbcc5af38cf9@github.com>
 <eJPm_NEiRoU3GnEdRoELrfmTw-WZHNmWBB9tAy4R9Lk=.2366fbac-691d-4604-83ba-8d39d3a6b9b1@github.com>
Message-ID: <YIe4GSQkvMaSEAqNNjki3z6joATHKfTlfjZYZZYnz9g=.4c6ec09b-f92c-42c8-8047-36634fa3ad44@github.com>

On Fri, 15 Aug 2025 14:02:01 GMT, Anton Artemov <duke at openjdk.org> wrote:

> ... this has to be fixed, because it is not correct.

I do agree, not setting the state back to `TS_RUN` in case of a successful acquisition of the object monitor may cause problems in future refactorizations. Thus we should fix it now that we've spotted it.

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

PR Comment: https://git.openjdk.org/jdk/pull/26794#issuecomment-3191644029

From shade at openjdk.org  Fri Aug 15 14:37:10 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 15 Aug 2025 14:37:10 GMT
Subject: RFR: 8365165: Zap C-heap memory at delete/free
In-Reply-To: <D9SLpxKYhFyy74tp6EaDn_Bc4I5oZXgt3he8e5imZQY=.e89d152c-b6c3-441e-b176-f04c57b290d6@github.com>
References: <ljSYFp1_TNhj2Vzf6uvNMbSCU0TqxRgR3nNFbXGoiVE=.8d31190f-3319-49a6-8c2f-94cb73e0d574@github.com>
 <fVGXjZVG8rPVMFsVhP0YQDK8EG_aasPBDlpS7a8WNqY=.0527b77b-f267-4706-b69b-d670d3b33e3a@github.com>
 <j2beWDYdbjLDjpeacrAgAJYSleYPTGtNuLUIj0pNwF0=.bd85fabb-c6e0-405f-80bc-938060fa6455@github.com>
 <D9SLpxKYhFyy74tp6EaDn_Bc4I5oZXgt3he8e5imZQY=.e89d152c-b6c3-441e-b176-f04c57b290d6@github.com>
Message-ID: <7CjfVrfrQS5x4zyqEIR3V78AcOfkt9hzBbWFULhhHls=.91c46b8d-f353-44d8-a963-74dd32a233a7@github.com>

On Fri, 15 Aug 2025 14:14:38 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Zap on malloc would also be useful.

I don't understand. `ZapCHeap`, as implement in current PR, zaps on malloc as well. Well, actually, it just wraps the already existing zapping code with flag guards. I used to call the flag `ZapFreeCHeap`, but then realized we do malloc/realloc side already, so it just claimed those to be a part of the same zapping feature.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26775#discussion_r2279106510

From pchilanomate at openjdk.org  Fri Aug 15 14:40:11 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 15 Aug 2025 14:40:11 GMT
Subject: RFR: 8365556: ObjectMonitor::try_lock_or_add_to_entry_list()
 returns true with the wrong state of the node
In-Reply-To: <YUOnpPZ57q-9oW7npgsONxWYI6K-FdUtvmSNzIO7w1Q=.06f70f3d-17e7-4583-9890-fe52d7a7af13@github.com>
References: <YUOnpPZ57q-9oW7npgsONxWYI6K-FdUtvmSNzIO7w1Q=.06f70f3d-17e7-4583-9890-fe52d7a7af13@github.com>
Message-ID: <6MCqstmaVLWyEWeYqasaUuNVK2CZzQ-fpNTUl8Mwy8Q=.ba4bbed6-ad34-4deb-bf5a-591e91d8b140@github.com>

On Fri, 15 Aug 2025 07:22:02 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following change:
> 
> `ObjectMonitor::try_lock_or_add_to_entry_list() `does not change the node state to `TS_RUN `in case of a successful acquisition of the object monitor. In certain cases this can break the guarantee statement in the `ObjectMonitor::wait()` method and lead to a crash. The missing statement is added.
> 
> Tested in tiers 1 - 5.

I'm fine with the fix, I was just confused about the mention of the crash. I would add `assert(node->TState == ObjectWaiter::TS_RUN, "");` at the top though to avoid surprises.

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

PR Comment: https://git.openjdk.org/jdk/pull/26794#issuecomment-3191657249

From stuefe at openjdk.org  Fri Aug 15 14:57:09 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 15 Aug 2025 14:57:09 GMT
Subject: RFR: 8365165: Zap C-heap memory at delete/free
In-Reply-To: <7CjfVrfrQS5x4zyqEIR3V78AcOfkt9hzBbWFULhhHls=.91c46b8d-f353-44d8-a963-74dd32a233a7@github.com>
References: <ljSYFp1_TNhj2Vzf6uvNMbSCU0TqxRgR3nNFbXGoiVE=.8d31190f-3319-49a6-8c2f-94cb73e0d574@github.com>
 <fVGXjZVG8rPVMFsVhP0YQDK8EG_aasPBDlpS7a8WNqY=.0527b77b-f267-4706-b69b-d670d3b33e3a@github.com>
 <j2beWDYdbjLDjpeacrAgAJYSleYPTGtNuLUIj0pNwF0=.bd85fabb-c6e0-405f-80bc-938060fa6455@github.com>
 <D9SLpxKYhFyy74tp6EaDn_Bc4I5oZXgt3he8e5imZQY=.e89d152c-b6c3-441e-b176-f04c57b290d6@github.com>
 <7CjfVrfrQS5x4zyqEIR3V78AcOfkt9hzBbWFULhhHls=.91c46b8d-f353-44d8-a963-74dd32a233a7@github.com>
Message-ID: <UyMzVcTVITtdvbviWoszqsyp0ZQkEowhiMMat-Vyk1c=.e9e377fd-a982-484b-9fcd-42cc7d46f374@github.com>

On Fri, 15 Aug 2025 14:34:56 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> +1. Ideally, `os::malloc` and friends should not be terribly hot. That's why we have custom allocators for heavy fine-grained use cases like C2. 
>> 
>> `ZapCHeap` may be a bit misleading as a name, since all it does is zap on free. 
>> 
>> Zap on malloc would also be useful. If we are worried about speed, zapping the 1-2 words would already give 95% of effect, since that is in high likelyhood the later location for some important struct members. And there is some probability that the libc touches memory in the vicinity of the block start during allocation, so it's probably already paged in.
>
>> Zap on malloc would also be useful.
> 
> I don't understand. `ZapCHeap`, as implement in current PR, zaps on malloc as well. Well, actually, it just wraps the already existing zapping code with flag guards. I used to call the flag `ZapFreeCHeap`, but then realized we do malloc/realloc side already, so it just claimed those to be a part of the same zapping feature.

Okay, I see. So it's the other way around, we zap newly allocated memory, but not free memory. I thought you were doing that, according to your comment:

> When NMT is enabled (which it is for debug builds), we can also do this for frees, as NMT tells us the size of the free-ed block.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26775#discussion_r2279139574

From shade at openjdk.org  Fri Aug 15 15:07:09 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 15 Aug 2025 15:07:09 GMT
Subject: RFR: 8365165: Zap C-heap memory at delete/free
In-Reply-To: <UyMzVcTVITtdvbviWoszqsyp0ZQkEowhiMMat-Vyk1c=.e9e377fd-a982-484b-9fcd-42cc7d46f374@github.com>
References: <ljSYFp1_TNhj2Vzf6uvNMbSCU0TqxRgR3nNFbXGoiVE=.8d31190f-3319-49a6-8c2f-94cb73e0d574@github.com>
 <fVGXjZVG8rPVMFsVhP0YQDK8EG_aasPBDlpS7a8WNqY=.0527b77b-f267-4706-b69b-d670d3b33e3a@github.com>
 <j2beWDYdbjLDjpeacrAgAJYSleYPTGtNuLUIj0pNwF0=.bd85fabb-c6e0-405f-80bc-938060fa6455@github.com>
 <D9SLpxKYhFyy74tp6EaDn_Bc4I5oZXgt3he8e5imZQY=.e89d152c-b6c3-441e-b176-f04c57b290d6@github.com>
 <7CjfVrfrQS5x4zyqEIR3V78AcOfkt9hzBbWFULhhHls=.91c46b8d-f353-44d8-a963-74dd32a233a7@github.com>
 <UyMzVcTVITtdvbviWoszqsyp0ZQkEowhiMMat-Vyk1c=.e9e377fd-a982-484b-9fcd-42cc7d46f374@github.com>
Message-ID: <OvjhdTO1zbCwuKdpAoIw9bAMhL2xywILCaLvuxZsjlc=.ef2f9681-ded0-4d30-927d-a66ecb3dfddc@github.com>

On Fri, 15 Aug 2025 14:54:12 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>>> Zap on malloc would also be useful.
>> 
>> I don't understand. `ZapCHeap`, as implement in current PR, zaps on malloc as well. Well, actually, it just wraps the already existing zapping code with flag guards. I used to call the flag `ZapFreeCHeap`, but then realized we do malloc/realloc side already, so it just claimed those to be a part of the same zapping feature.
>
> Okay, I see. So it's the other way around, we zap newly allocated memory, but not free memory. I thought you were doing that, according to your comment:
> 
>> When NMT is enabled (which it is for debug builds), we can also do this for frees, as NMT tells us the size of the free-ed block.

The PR does *all three*, take a look? Current code already zaps on malloc/realloc path, those paths are now under new `ZapCHeap` flag. New code zaps on free path, and it is also under new `ZapCHeap` flag. So in the end, `ZapCHeap` covers malloc/realloc/free, and thus it has a proper name.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26775#discussion_r2279156982

From stuefe at openjdk.org  Fri Aug 15 15:19:12 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 15 Aug 2025 15:19:12 GMT
Subject: RFR: 8365165: Zap C-heap memory at delete/free
In-Reply-To: <OvjhdTO1zbCwuKdpAoIw9bAMhL2xywILCaLvuxZsjlc=.ef2f9681-ded0-4d30-927d-a66ecb3dfddc@github.com>
References: <ljSYFp1_TNhj2Vzf6uvNMbSCU0TqxRgR3nNFbXGoiVE=.8d31190f-3319-49a6-8c2f-94cb73e0d574@github.com>
 <fVGXjZVG8rPVMFsVhP0YQDK8EG_aasPBDlpS7a8WNqY=.0527b77b-f267-4706-b69b-d670d3b33e3a@github.com>
 <j2beWDYdbjLDjpeacrAgAJYSleYPTGtNuLUIj0pNwF0=.bd85fabb-c6e0-405f-80bc-938060fa6455@github.com>
 <D9SLpxKYhFyy74tp6EaDn_Bc4I5oZXgt3he8e5imZQY=.e89d152c-b6c3-441e-b176-f04c57b290d6@github.com>
 <7CjfVrfrQS5x4zyqEIR3V78AcOfkt9hzBbWFULhhHls=.91c46b8d-f353-44d8-a963-74dd32a233a7@github.com>
 <UyMzVcTVITtdvbviWoszqsyp0ZQkEowhiMMat-Vyk1c=.e9e377fd-a982-484b-9fcd-42cc7d46f374@github.com>
 <OvjhdTO1zbCwuKdpAoIw9bAMhL2xywILCaLvuxZsjlc=.ef2f9681-ded0-4d30-927d-a66ecb3dfddc@github.com>
Message-ID: <Dpsi87vJqzeq6AeKGO8I818jVSY1QCDmL_EoO_RU8Uc=.38649083-8cef-45bb-b090-d8b5fbe5c291@github.com>

On Fri, 15 Aug 2025 15:03:45 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Okay, I see. So it's the other way around, we zap newly allocated memory, but not free memory. I thought you were doing that, according to your comment:
>> 
>>> When NMT is enabled (which it is for debug builds), we can also do this for frees, as NMT tells us the size of the free-ed block.
>
> The PR does *all three*, take a look? Current code already zaps on malloc/realloc path, those paths are now under new `ZapCHeap` flag. New code zaps on free path, and it is also under new `ZapCHeap` flag. So in the end, `ZapCHeap` covers malloc/realloc/free, and thus it has a proper name.

Ah okay. I should not review on Friday evenings. All good, then.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26775#discussion_r2279194075

From kvn at openjdk.org  Fri Aug 15 18:18:12 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 15 Aug 2025 18:18:12 GMT
Subject: RFR: 8365165: Zap C-heap memory at delete/free
In-Reply-To: <ljSYFp1_TNhj2Vzf6uvNMbSCU0TqxRgR3nNFbXGoiVE=.8d31190f-3319-49a6-8c2f-94cb73e0d574@github.com>
References: <ljSYFp1_TNhj2Vzf6uvNMbSCU0TqxRgR3nNFbXGoiVE=.8d31190f-3319-49a6-8c2f-94cb73e0d574@github.com>
Message-ID: <qj-Tb8KPFeRgGicbYwhQWTz50_o7BMzX7MHbNC3HQ0U=.65c1510a-b5b1-4ad1-b63e-4f2d86c7c3f1@github.com>

On Thu, 14 Aug 2025 10:16:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> We sometimes have a lifecycle problem with C-heap allocated objects. The most recent I dealt with is [JDK-8364501](https://bugs.openjdk.org/browse/JDK-8364501). It would be convenient to have diagnostic code to zap the memory that is freed on C heap. We already do this for alloc/realloc. When NMT is enabled (which it is for debug builds), we can also do this for frees, as NMT tells us the size of the free-ed block.
> 
> This PR introduces a new diagnostic flag to match other `Zap*` flags we already have, puts the zapping on free path, and wraps alloc/realloc zapping with the flag as well. The last part is not really necessary, but it is nicer to wrap zapping code with a flag like this, so we can disable it for testing performance. JCStress routinely opts-out of most of the zapping to gain higher sampling throughput on fastdebug builds.
> 
> Additional testing:
>  - [x] Linux AArch64 server fastdebug, selectively rolling back [JDK-8364501](https://bugs.openjdk.org/browse/JDK-8364501) -- starts to immediately crash on reproducer
>  - [x] Linux x86_64 server fastdebug, `all` (no new crashes, phew)
>  - [x] Linux AArch64 server fastdebug, `all` (no new crashes, phew)

Looks good. I submitted testing.

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

PR Review: https://git.openjdk.org/jdk/pull/26775#pullrequestreview-3124757012

From kvn at openjdk.org  Fri Aug 15 23:21:10 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 15 Aug 2025 23:21:10 GMT
Subject: RFR: 8365165: Zap C-heap memory at delete/free
In-Reply-To: <ljSYFp1_TNhj2Vzf6uvNMbSCU0TqxRgR3nNFbXGoiVE=.8d31190f-3319-49a6-8c2f-94cb73e0d574@github.com>
References: <ljSYFp1_TNhj2Vzf6uvNMbSCU0TqxRgR3nNFbXGoiVE=.8d31190f-3319-49a6-8c2f-94cb73e0d574@github.com>
Message-ID: <bThSWIGy-BcZ09quLFn-fu7JKd5KQpY6dzOp_136-u0=.e0a405c8-c83f-4db0-a349-01f94f6f896c@github.com>

On Thu, 14 Aug 2025 10:16:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> We sometimes have a lifecycle problem with C-heap allocated objects. The most recent I dealt with is [JDK-8364501](https://bugs.openjdk.org/browse/JDK-8364501). It would be convenient to have diagnostic code to zap the memory that is freed on C heap. We already do this for alloc/realloc. When NMT is enabled (which it is for debug builds), we can also do this for frees, as NMT tells us the size of the free-ed block.
> 
> This PR introduces a new diagnostic flag to match other `Zap*` flags we already have, puts the zapping on free path, and wraps alloc/realloc zapping with the flag as well. The last part is not really necessary, but it is nicer to wrap zapping code with a flag like this, so we can disable it for testing performance. JCStress routinely opts-out of most of the zapping to gain higher sampling throughput on fastdebug builds.
> 
> Additional testing:
>  - [x] Linux AArch64 server fastdebug, selectively rolling back [JDK-8364501](https://bugs.openjdk.org/browse/JDK-8364501) -- starts to immediately crash on reproducer
>  - [x] Linux x86_64 server fastdebug, `all` (no new crashes, phew)
>  - [x] Linux AArch64 server fastdebug, `all` (no new crashes, phew)

My testing passed. Good.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26775#pullrequestreview-3125338454

From ysuenaga at openjdk.org  Sun Aug 17 09:09:44 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Sun, 17 Aug 2025 09:09:44 GMT
Subject: RFR: 8365633: Incorrect info is reported on hybrid CPU [v2]
In-Reply-To: <T2R7vtbL0AaZLcRKdAPjoM6I8kz6lclHBNnOXi8JIQY=.1af945fd-1592-423a-8a19-940dd1c531d3@github.com>
References: <T2R7vtbL0AaZLcRKdAPjoM6I8kz6lclHBNnOXi8JIQY=.1af945fd-1592-423a-8a19-940dd1c531d3@github.com>
Message-ID: <xeZsXlz_VUer4L2XraArNgofAegPxFvrpikCFdhYCBc=.8d7c0ac7-bd90-4e3b-b4db-461ee19db60a@github.com>

> `VM.info` DCmd reports CPU information. I ran this on Intel Core Ultra 5 225U , then I got following result:
> 
> 
> CPU: total 14 (initial active 14) (7 cores per cpu, 2 threads per core) family 6 model 181 stepping 0 microcode 0xffffffff, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, clwb, hv, serialize, rdtscp, rdpid, fsrm, gfni, f16c, cet_ibt, cet_ss
> CPU Model and flags from /proc/cpuinfo:
> model name : Intel(R) Core(TM) Ultra 5 225U
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm pni pclmulqdq monitor est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave osxsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch fsgsbase bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb intel_pt sha_ni umip gfni vaes vpclmulqdq rdpid ibrs ibpb stibp ssbd
> 
> 
> It reports "7 cores per cpu, 2 threads per core". 225U has hybrid architecture - 2 P cores, 8 E cores, 2 LP cores, and also P core has 2 threads per core. Then it should be "12 cores, 14 threads".
> https://www.intel.com/content/www/us/en/products/sku/241861/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html
> 
> According to Intel Software Developer's Manual, it seems to be difficult to get number of physical cores. In Linux kernel, it seems to be calculated by complex logic: https://github.com/torvalds/linux/blob/v6.16/arch/x86/kernel/smpboot.c#L567-L597
> In addition, all of P cores might not be enabled HT. Thus to show only number of threads is reasonable at this point.

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

  Add HYBRID to CPUFeature in JVMCI

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26808/files
  - new: https://git.openjdk.org/jdk/pull/26808/files/15828727..234a67b6

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

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

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

From kbarrett at openjdk.org  Sun Aug 17 12:49:10 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 17 Aug 2025 12:49:10 GMT
Subject: RFR: 8365165: Zap C-heap memory at delete/free
In-Reply-To: <ljSYFp1_TNhj2Vzf6uvNMbSCU0TqxRgR3nNFbXGoiVE=.8d31190f-3319-49a6-8c2f-94cb73e0d574@github.com>
References: <ljSYFp1_TNhj2Vzf6uvNMbSCU0TqxRgR3nNFbXGoiVE=.8d31190f-3319-49a6-8c2f-94cb73e0d574@github.com>
Message-ID: <PlIGicZ0cQ9wyc7rPY9PKEleRff-x60yfywYWbHThnw=.39a4d707-ac8b-420f-8caf-bee0c958c506@github.com>

On Thu, 14 Aug 2025 10:16:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> We sometimes have a lifecycle problem with C-heap allocated objects. The most recent I dealt with is [JDK-8364501](https://bugs.openjdk.org/browse/JDK-8364501). It would be convenient to have diagnostic code to zap the memory that is freed on C heap. We already do this for alloc/realloc. When NMT is enabled (which it is for debug builds), we can also do this for frees, as NMT tells us the size of the free-ed block.
> 
> This PR introduces a new diagnostic flag to match other `Zap*` flags we already have, puts the zapping on free path, and wraps alloc/realloc zapping with the flag as well. The last part is not really necessary, but it is nicer to wrap zapping code with a flag like this, so we can disable it for testing performance. JCStress routinely opts-out of most of the zapping to gain higher sampling throughput on fastdebug builds.
> 
> Additional testing:
>  - [x] Linux AArch64 server fastdebug, selectively rolling back [JDK-8364501](https://bugs.openjdk.org/browse/JDK-8364501) -- starts to immediately crash on reproducer
>  - [x] Linux x86_64 server fastdebug, `all` (no new crashes, phew)
>  - [x] Linux AArch64 server fastdebug, `all` (no new crashes, phew)

Marked as reviewed by kbarrett (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26775#pullrequestreview-3126327917

From kbarrett at openjdk.org  Sun Aug 17 12:49:11 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 17 Aug 2025 12:49:11 GMT
Subject: RFR: 8365165: Zap C-heap memory at delete/free
In-Reply-To: <OvjhdTO1zbCwuKdpAoIw9bAMhL2xywILCaLvuxZsjlc=.ef2f9681-ded0-4d30-927d-a66ecb3dfddc@github.com>
References: <ljSYFp1_TNhj2Vzf6uvNMbSCU0TqxRgR3nNFbXGoiVE=.8d31190f-3319-49a6-8c2f-94cb73e0d574@github.com>
 <fVGXjZVG8rPVMFsVhP0YQDK8EG_aasPBDlpS7a8WNqY=.0527b77b-f267-4706-b69b-d670d3b33e3a@github.com>
 <j2beWDYdbjLDjpeacrAgAJYSleYPTGtNuLUIj0pNwF0=.bd85fabb-c6e0-405f-80bc-938060fa6455@github.com>
 <D9SLpxKYhFyy74tp6EaDn_Bc4I5oZXgt3he8e5imZQY=.e89d152c-b6c3-441e-b176-f04c57b290d6@github.com>
 <7CjfVrfrQS5x4zyqEIR3V78AcOfkt9hzBbWFULhhHls=.91c46b8d-f353-44d8-a963-74dd32a233a7@github.com>
 <UyMzVcTVITtdvbviWoszqsyp0ZQkEowhiMMat-Vyk1c=.e9e377fd-a982-484b-9fcd-42cc7d46f374@github.com>
 <OvjhdTO1zbCwuKdpAoIw9bAMhL2xywILCaLvuxZsjlc=.ef2f9681-ded0-4d30-927d-a66ecb3dfddc@github.com>
Message-ID: <eu47VcQ_OUzJltQ-LAU3xjS2dYTJvlhg78JepwlAO6Y=.246203d5-e24a-4a4a-bb62-6ffd3a23eab0@github.com>

On Fri, 15 Aug 2025 15:03:45 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Okay, I see. So it's the other way around, we zap newly allocated memory, but not free memory. I thought you were doing that, according to your comment:
>> 
>>> When NMT is enabled (which it is for debug builds), we can also do this for frees, as NMT tells us the size of the free-ed block.
>
> The PR does *all three*, take a look? Current code already zaps on malloc/realloc path, those paths are now under new `ZapCHeap` flag. New code zaps on free path, and it is also under new `ZapCHeap` flag. So in the end, `ZapCHeap` covers malloc/realloc/free, and thus it has a proper name.

@shipilev Thanks for doing some performance testing. Yeah, that doesn't look too bad.

Change looks good.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26775#discussion_r2280866507

From aboldtch at openjdk.org  Mon Aug 18 06:49:14 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 18 Aug 2025 06:49:14 GMT
Subject: RFR: 8365556: ObjectMonitor::try_lock_or_add_to_entry_list()
 returns true with the wrong state of the node
In-Reply-To: <YUOnpPZ57q-9oW7npgsONxWYI6K-FdUtvmSNzIO7w1Q=.06f70f3d-17e7-4583-9890-fe52d7a7af13@github.com>
References: <YUOnpPZ57q-9oW7npgsONxWYI6K-FdUtvmSNzIO7w1Q=.06f70f3d-17e7-4583-9890-fe52d7a7af13@github.com>
Message-ID: <qalT8gSAQQXnrECvY-h-WiYYOBY51idLc5ZZFpLYZCE=.1d89e21d-73ef-43db-a6e9-f655776adfeb@github.com>

On Fri, 15 Aug 2025 07:22:02 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following change:
> 
> `ObjectMonitor::try_lock_or_add_to_entry_list() `does not change the node state to `TS_RUN `in case of a successful acquisition of the object monitor. In certain cases this can break the guarantee statement in the `ObjectMonitor::wait()` method and lead to a crash. The missing statement is added.
> 
> Tested in tiers 1 - 5.

Just a side note: 
_I am wondering if `try_lock_or_add_to_entry_list` should just be `add_to_entry_list` and just simply add a waiter to the list. Unclear if it is worth retrying the lock at this point. Given that the head only changes either when there are more threads trying to add themselves to the list or a thread has just acquired the lock and is removing themself. In either case unsure if we are more likely than at any other point to get the lock._

_And if we want to keep the behaviour of `try_lock_or_add_to_entry_list` it should probably try_lock first and then CAS the head. The window where we fail the CAS seems at least as significant as the window we spend allocating and initialising the ObjectWaiter between our previous lock attempt and calling `try_lock_or_add_to_entry_list`. Which would also be more inline with its name placing "lock" before "add to entry list"._

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

PR Comment: https://git.openjdk.org/jdk/pull/26794#issuecomment-3195340986

From dholmes at openjdk.org  Mon Aug 18 07:08:11 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 18 Aug 2025 07:08:11 GMT
Subject: RFR: 8365633: Incorrect info is reported on hybrid CPU [v2]
In-Reply-To: <xeZsXlz_VUer4L2XraArNgofAegPxFvrpikCFdhYCBc=.8d7c0ac7-bd90-4e3b-b4db-461ee19db60a@github.com>
References: <T2R7vtbL0AaZLcRKdAPjoM6I8kz6lclHBNnOXi8JIQY=.1af945fd-1592-423a-8a19-940dd1c531d3@github.com>
 <xeZsXlz_VUer4L2XraArNgofAegPxFvrpikCFdhYCBc=.8d7c0ac7-bd90-4e3b-b4db-461ee19db60a@github.com>
Message-ID: <HD2Xumfa9Aj6D6kpwvUl-GY97-wzEf4L1OVbCIN7VLk=.7e27681a-19c2-46b6-bd4d-4eb3eaa6e8d8@github.com>

On Sun, 17 Aug 2025 09:09:44 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> `VM.info` DCmd reports CPU information. I ran this on Intel Core Ultra 5 225U , then I got following result:
>> 
>> 
>> CPU: total 14 (initial active 14) (7 cores per cpu, 2 threads per core) family 6 model 181 stepping 0 microcode 0xffffffff, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, clwb, hv, serialize, rdtscp, rdpid, fsrm, gfni, f16c, cet_ibt, cet_ss
>> CPU Model and flags from /proc/cpuinfo:
>> model name : Intel(R) Core(TM) Ultra 5 225U
>> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm pni pclmulqdq monitor est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave osxsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch fsgsbase bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb intel_pt sha_ni umip gfni vaes vpclmulqdq rdpid ibrs ibpb stibp ssbd
>> 
>> 
>> It reports "7 cores per cpu, 2 threads per core". 225U has hybrid architecture - 2 P cores, 8 E cores, 2 LP cores, and also P core has 2 threads per core. Then it should be "12 cores, 14 threads".
>> https://www.intel.com/content/www/us/en/products/sku/241861/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html
>> 
>> According to Intel Software Developer's Manual, it seems to be difficult to get number of physical cores. In Linux kernel, it seems to be calculated by complex logic: https://github.com/torvalds/linux/blob/v6.16/arch/x86/kernel/smpboot.c#L567-L597
>> In addition, all of P cores might not be enabled HT. Thus to show only number of threads is reasonable at this point.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add HYBRID to CPUFeature in JVMCI

These hybrid CPUs are a nightmare to understand/describe/use. How does "logical cpus" map to what we return from `active_processor_count`? i.e. what does the DCmd show after your change?

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

PR Comment: https://git.openjdk.org/jdk/pull/26808#issuecomment-3195387030

From shade at openjdk.org  Mon Aug 18 08:12:16 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 18 Aug 2025 08:12:16 GMT
Subject: RFR: 8365165: Zap C-heap memory at delete/free
In-Reply-To: <ljSYFp1_TNhj2Vzf6uvNMbSCU0TqxRgR3nNFbXGoiVE=.8d31190f-3319-49a6-8c2f-94cb73e0d574@github.com>
References: <ljSYFp1_TNhj2Vzf6uvNMbSCU0TqxRgR3nNFbXGoiVE=.8d31190f-3319-49a6-8c2f-94cb73e0d574@github.com>
Message-ID: <LQn7pvqC4gClwjTbf7BDZ6KMmAlSvAoVj-P2N7dJDpU=.6dcff94e-641d-4060-9bea-a38c600d2fda@github.com>

On Thu, 14 Aug 2025 10:16:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> We sometimes have a lifecycle problem with C-heap allocated objects. The most recent I dealt with is [JDK-8364501](https://bugs.openjdk.org/browse/JDK-8364501). It would be convenient to have diagnostic code to zap the memory that is freed on C heap. We already do this for alloc/realloc. When NMT is enabled (which it is for debug builds), we can also do this for frees, as NMT tells us the size of the free-ed block.
> 
> This PR introduces a new diagnostic flag to match other `Zap*` flags we already have, puts the zapping on free path, and wraps alloc/realloc zapping with the flag as well. The last part is not really necessary, but it is nicer to wrap zapping code with a flag like this, so we can disable it for testing performance. JCStress routinely opts-out of most of the zapping to gain higher sampling throughput on fastdebug builds.
> 
> Additional testing:
>  - [x] Linux AArch64 server fastdebug, selectively rolling back [JDK-8364501](https://bugs.openjdk.org/browse/JDK-8364501) -- starts to immediately crash on reproducer
>  - [x] Linux x86_64 server fastdebug, `all` (no new crashes, phew)
>  - [x] Linux AArch64 server fastdebug, `all` (no new crashes, phew)

Thank you all! I think we are in consensus this is a right thing to do. So I am integrating.

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

PR Comment: https://git.openjdk.org/jdk/pull/26775#issuecomment-3195585835

From shade at openjdk.org  Mon Aug 18 08:15:16 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 18 Aug 2025 08:15:16 GMT
Subject: Integrated: 8365165: Zap C-heap memory at delete/free
In-Reply-To: <ljSYFp1_TNhj2Vzf6uvNMbSCU0TqxRgR3nNFbXGoiVE=.8d31190f-3319-49a6-8c2f-94cb73e0d574@github.com>
References: <ljSYFp1_TNhj2Vzf6uvNMbSCU0TqxRgR3nNFbXGoiVE=.8d31190f-3319-49a6-8c2f-94cb73e0d574@github.com>
Message-ID: <ljUdouy__A7YIguP87hCzAJRyA3xK4tEuFW-N3fR2gc=.4384fc71-3101-4766-babc-aa5a89e6f290@github.com>

On Thu, 14 Aug 2025 10:16:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> We sometimes have a lifecycle problem with C-heap allocated objects. The most recent I dealt with is [JDK-8364501](https://bugs.openjdk.org/browse/JDK-8364501). It would be convenient to have diagnostic code to zap the memory that is freed on C heap. We already do this for alloc/realloc. When NMT is enabled (which it is for debug builds), we can also do this for frees, as NMT tells us the size of the free-ed block.
> 
> This PR introduces a new diagnostic flag to match other `Zap*` flags we already have, puts the zapping on free path, and wraps alloc/realloc zapping with the flag as well. The last part is not really necessary, but it is nicer to wrap zapping code with a flag like this, so we can disable it for testing performance. JCStress routinely opts-out of most of the zapping to gain higher sampling throughput on fastdebug builds.
> 
> Additional testing:
>  - [x] Linux AArch64 server fastdebug, selectively rolling back [JDK-8364501](https://bugs.openjdk.org/browse/JDK-8364501) -- starts to immediately crash on reproducer
>  - [x] Linux x86_64 server fastdebug, `all` (no new crashes, phew)
>  - [x] Linux AArch64 server fastdebug, `all` (no new crashes, phew)

This pull request has now been integrated.

Changeset: ca753eba
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ca753ebad6681a76d18800d23898b7d6af83f567
Stats:     12 lines in 3 files changed: 9 ins; 0 del; 3 mod

8365165: Zap C-heap memory at delete/free

Reviewed-by: kvn, kbarrett

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

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

From ysuenaga at openjdk.org  Mon Aug 18 08:19:13 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Mon, 18 Aug 2025 08:19:13 GMT
Subject: RFR: 8365633: Incorrect info is reported on hybrid CPU [v2]
In-Reply-To: <xeZsXlz_VUer4L2XraArNgofAegPxFvrpikCFdhYCBc=.8d7c0ac7-bd90-4e3b-b4db-461ee19db60a@github.com>
References: <T2R7vtbL0AaZLcRKdAPjoM6I8kz6lclHBNnOXi8JIQY=.1af945fd-1592-423a-8a19-940dd1c531d3@github.com>
 <xeZsXlz_VUer4L2XraArNgofAegPxFvrpikCFdhYCBc=.8d7c0ac7-bd90-4e3b-b4db-461ee19db60a@github.com>
Message-ID: <0XqOqgNQeltWkfd-6Q6n-BkITEqjS3r2CnaGUOrIds4=.84521e88-a03c-43da-8ef0-8c0522829361@github.com>

On Sun, 17 Aug 2025 09:09:44 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> `VM.info` DCmd reports CPU information. I ran this on Intel Core Ultra 5 225U , then I got following result:
>> 
>> 
>> CPU: total 14 (initial active 14) (7 cores per cpu, 2 threads per core) family 6 model 181 stepping 0 microcode 0xffffffff, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, clwb, hv, serialize, rdtscp, rdpid, fsrm, gfni, f16c, cet_ibt, cet_ss
>> CPU Model and flags from /proc/cpuinfo:
>> model name : Intel(R) Core(TM) Ultra 5 225U
>> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm pni pclmulqdq monitor est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave osxsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch fsgsbase bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb intel_pt sha_ni umip gfni vaes vpclmulqdq rdpid ibrs ibpb stibp ssbd
>> 
>> 
>> It reports "7 cores per cpu, 2 threads per core". 225U has hybrid architecture - 2 P cores, 8 E cores, 2 LP cores, and also P core has 2 threads per core. Then it should be "12 cores, 14 threads".
>> https://www.intel.com/content/www/us/en/products/sku/241861/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html
>> 
>> According to Intel Software Developer's Manual, it seems to be difficult to get number of physical cores. In Linux kernel, it seems to be calculated by complex logic: https://github.com/torvalds/linux/blob/v6.16/arch/x86/kernel/smpboot.c#L567-L597
>> In addition, all of P cores might not be enabled HT. Thus to show only number of threads is reasonable at this point.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add HYBRID to CPUFeature in JVMCI

You can get following output from DCmd after this change:

CPU: total 14 (initial active 14) (14 threads) family 6 model 181 stepping 0 microcode 0xffffffff, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, clwb, hv, serialize, rdtscp, rdpid, fsrm, gfni, f16c, cet_ibt, cet_ss, hybrid


`-Xlog:os=trace` reports `active_processor_count` is 14 - it is correct on my laptop (Core Ultra), and matches the result of DCmd.

[0.021s][trace][os] active_processor_count: using static path - configured processors: 14
[0.022s][trace][os] active_processor_count: sched_getaffinity processor count: 14

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

PR Comment: https://git.openjdk.org/jdk/pull/26808#issuecomment-3195610671

From snatarajan at openjdk.org  Mon Aug 18 08:41:21 2025
From: snatarajan at openjdk.org (Saranya Natarajan)
Date: Mon, 18 Aug 2025 08:41:21 GMT
Subject: RFR: 8358696: Assert with extreme values for -XX:BciProfileWidth
 [v8]
In-Reply-To: <x48Qtjsnz7ccoI5LdqiDmB8kO8FwmDjSE3ItYbtB4v0=.c22c1404-5766-4c32-a73a-a331cbe50f6d@github.com>
References: <5TRVeAXUQi6quM-nDWEij_jk6M5K2Vk31RA-Yjd8F2M=.5b63da45-93c3-4251-9e2e-3c64b7953919@github.com>
 <x48Qtjsnz7ccoI5LdqiDmB8kO8FwmDjSE3ItYbtB4v0=.c22c1404-5766-4c32-a73a-a331cbe50f6d@github.com>
Message-ID: <yS5BgyK2thI_nWVancTKckcbnjEXM6OwRXxpNYKtxzs=.d24ff111-a6d0-42bd-883e-0287529a9e0d@github.com>

On Wed, 13 Aug 2025 09:35:08 GMT, Saranya Natarajan <snatarajan at openjdk.org> wrote:

>> **Issue**
>> Extreme values for BciProfileWidth flag such as `java -XX:BciProfileWidth=-1 -version` and `java -XX:BciProfileWidth=100000 -version `results in assert failure `assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x0000772b63a7a3a0 <= 0x0000772b63b75159 <= 0x0000772b63b75158 `. This is observed in a x86 machine.
>> 
>> **Analysis** 
>>  On debugging the issue, I found that increasing the size of the interpreter using the `InterpreterCodeSize` variable in `src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp` prevented the above mentioned assert from failing for large values of BciProfileWidth.  
>> 
>> **Proposal** 
>> Considering the fact that larger BciProfileWidth results in slower profiling, I have proposed a range between 0 to 5000 to restrict the value for BciProfileWidth for x86 machines. This maximum value is based on modifying the `InterpreterCodeSize` variable in `src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp` using the smallest `InterpreterCodeSize` for all the architectures.  As for the lower bound, a value of -1 would be the same as 0, as this simply means  no  return bci's will be recorded in ret profile. 
>> 
>> **Issue in AArch64**
>> Additionally running the command `java -XX:BciProfileWidth= 10000 -version` (or larger values) results in a different failure  `assert(offset_ok_for_immed(offset(), size)) failed: must be, was: 32768, 3` on an AArch64 machine.This is an issue of maximum offset for `ldr/str` in AArch64 which can be fixed using `form_address`  as mentioned in [JDK-8342736](https://bugs.openjdk.org/browse/JDK-8342736). In my preliminary fix using `form_address` on AArch64 machine. I had to modify 3 `ldr` and 1 `str` instruction (in file `src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp` at line number 926, 983, and 997). With this fix  using `form_address`, `BciProfileWidth` works for maximum of 5000 after which it crashes with`assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x0000772b63a7a3a0 <= 0x0000772b63b75159 <= 0x0000772b63b75158 `.  Without this fix `BciProfileWidth` works for a maximum value of 1300.   Currently, I have suggested to restrict the upper bound on AArch64 to 1000 instead
  of fixing it with `form_address`. 
>> 
>> **Question to reviewers**
>> Do you think this is a reasonable fix ?  For AArch64 do you suggest fixing using `form_address` ? If yes, do I fix it under this PR or create another one ?
>> 
>> **Request to port maintainers**
>> @dafedafe suggested that we keep the upper boun...
>
> Saranya Natarajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   additions for  linux-riscv64

@offamitkumar and @TheRealMDoerr : Would it be possible to test this PR in s390 and PPC ?

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

PR Comment: https://git.openjdk.org/jdk/pull/26139#issuecomment-3195691469

From mbaesken at openjdk.org  Mon Aug 18 11:42:50 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 18 Aug 2025 11:42:50 GMT
Subject: RFR: 8364352: Some tests fail when using a limited number of
 pregenerated .jsa CDS archives
Message-ID: <EnyzXiapmd29T3spHQT7QTBv2SVQVKVU6L2NEDoejHg=.65f803f7-09e0-4e5b-ac21-a60474c5facd@github.com>

Currently the default JVM comes on most platforms with 4 jsa files (for coops and nocoops; with and without compressed object headers), but for some shipments the number of jsa could be reduced (see also Images.gmk) .
But not all tests can deal with this.
Namely

test/hotspot/jtreg/runtime/CompressedOops/CompressedCPUSpecificClassSpaceReservation.java
test/hotspot/jtreg/runtime/cds/TestDefaultArchiveLoading.java
test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java (custom-cl-zgc)

were found to have issues.
There is already a requires  `vm.cds.default.archive.available`   that is used in similar tests and can be used in some of those cases too.

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

Commit messages:
 - JDK-8364352

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

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

From duke at openjdk.org  Mon Aug 18 13:40:21 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 18 Aug 2025 13:40:21 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v7]
In-Reply-To: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
Message-ID: <WNnTyj15PqUHRsB8v_cOi_Qx7FoYB-8T6jQAkePI27w=.fafb35b4-981d-43a2-9f1b-3a0652281a3a@github.com>

> Hi all,
> 
> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110).
> 
> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports:
> 
> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup()
> 
> CPUTimeUsage::GC::gc_threads()
> CPUTimeUsage::GC::vm_thread()
> CPUTimeUsage::GC::stringdedup()
> 
> CPUTimeUsage::Runtime::vm_thread()
> 
> 
> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC.
> 
> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table:
> 
> 
> [71.425s][info][cpu   ] === CPU time Statistics =============================================================
> [71.425s][info][cpu   ]                                                                             CPUs
> [71.425s][info][cpu   ]                                                                s       %  utilized
> [71.425s][info][cpu   ]    Process
> [71.425s][info][cpu   ]      Total                                             1616.3627  100.00      22.6
> [71.425s][info][cpu   ]      VM Thread                                            5.2992    0.33       0.1
> [71.425s][info][cpu   ]      Garbage Collection                                  83.7322    5.18       1.2
> [71.425s][info][cpu   ]        GC Threads                                        82.7671    5.12       1.2
> [71.425s][info][cpu   ]        VM Thread                                          0.9651    0.06       0.0
> [71.425s][info][cpu   ] =====================================================================================
> 
> 
> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path.

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

  Implement optional error handling

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26621/files
  - new: https://git.openjdk.org/jdk/pull/26621/files/ddab1f0b..8fe49703

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

  Stats: 38 lines in 6 files changed: 29 ins; 8 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26621.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26621/head:pull/26621

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

From duke at openjdk.org  Mon Aug 18 13:40:22 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 18 Aug 2025 13:40:22 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v6]
In-Reply-To: <ad5DY2SsqO7vgu0f6q_eiabwSPRi2fhN_RV3GhcZTEY=.50c248b2-0834-4461-a136-972953578bc5@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <ad5DY2SsqO7vgu0f6q_eiabwSPRi2fhN_RV3GhcZTEY=.50c248b2-0834-4461-a136-972953578bc5@github.com>
Message-ID: <N88QM9NlAP3Qe2xrKak5mJWyCjLJC6mV6o0kaGSfmhE=.6a93ada7-729b-4163-863b-36561ff0df18@github.com>

On Thu, 14 Aug 2025 14:12:18 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110).
>> 
>> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports:
>> 
>> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup()
>> 
>> CPUTimeUsage::GC::gc_threads()
>> CPUTimeUsage::GC::vm_thread()
>> CPUTimeUsage::GC::stringdedup()
>> 
>> CPUTimeUsage::Runtime::vm_thread()
>> 
>> 
>> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC.
>> 
>> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table:
>> 
>> 
>> [71.425s][info][cpu   ] === CPU time Statistics =============================================================
>> [71.425s][info][cpu   ]                                                                             CPUs
>> [71.425s][info][cpu   ]                                                                s       %  utilized
>> [71.425s][info][cpu   ]    Process
>> [71.425s][info][cpu   ]      Total                                             1616.3627  100.00      22.6
>> [71.425s][info][cpu   ]      VM Thread                                            5.2992    0.33       0.1
>> [71.425s][info][cpu   ]      Garbage Collection                                  83.7322    5.18       1.2
>> [71.425s][info][cpu   ]        GC Threads                                        82.7671    5.12       1.2
>> [71.425s][info][cpu   ]        VM Thread                                          0.9651    0.06       0.0
>> [71.425s][info][cpu   ] =====================================================================================
>> 
>> 
>> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path.
>
> Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Minor improvements and fixes per @kstefanj suggestions
>  - use percent_of from globalDefinitions.hpp

As per our offline discussion I implemented an optional error handling mechanism to allow users of this framework decide if they care or not.

If errors are found we print something like this in the end:

[0.569s][info][cpu] === CPU time Statistics =============================================================
[0.569s][info][cpu] WARNING: CPU time sampling reported errors, numbers may be unreliable
[0.569s][info][cpu]                                                                             CPUs
[0.569s][info][cpu]                                                                s       %  utilized
[0.569s][info][cpu]    Process
[0.569s][info][cpu]      Total                                                2.2719  100.00       4.0
[0.569s][info][cpu]      VM Thread                                            0.0031    0.14       0.0
[0.569s][info][cpu]      Garbage Collection                                   0.0146    0.64       0.0
[0.569s][info][cpu]        GC Threads                                         0.0141    0.62       0.0
[0.569s][info][cpu]        VM Thread                                          0.0006    0.03       0.0
[0.569s][info][cpu] =====================================================================================

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

PR Comment: https://git.openjdk.org/jdk/pull/26621#issuecomment-3196939663

From duke at openjdk.org  Mon Aug 18 13:56:03 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 18 Aug 2025 13:56:03 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v8]
In-Reply-To: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
Message-ID: <lYgyWIUfo-YSxjDQLSKNdUwIS2SW5VXQTJovyj89qt0=.d8c09b42-9576-49b3-b1c4-984bd3bb7f51@github.com>

> Hi all,
> 
> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110).
> 
> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports:
> 
> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup()
> 
> CPUTimeUsage::GC::gc_threads()
> CPUTimeUsage::GC::vm_thread()
> CPUTimeUsage::GC::stringdedup()
> 
> CPUTimeUsage::Runtime::vm_thread()
> 
> 
> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC.
> 
> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table:
> 
> 
> [71.425s][info][cpu   ] === CPU time Statistics =============================================================
> [71.425s][info][cpu   ]                                                                             CPUs
> [71.425s][info][cpu   ]                                                                s       %  utilized
> [71.425s][info][cpu   ]    Process
> [71.425s][info][cpu   ]      Total                                             1616.3627  100.00      22.6
> [71.425s][info][cpu   ]      VM Thread                                            5.2992    0.33       0.1
> [71.425s][info][cpu   ]      Garbage Collection                                  83.7322    5.18       1.2
> [71.425s][info][cpu   ]        GC Threads                                        82.7671    5.12       1.2
> [71.425s][info][cpu   ]        VM Thread                                          0.9651    0.06       0.0
> [71.425s][info][cpu   ] =====================================================================================
> 
> 
> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path.

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

 - Minor
 - Minor

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26621/files
  - new: https://git.openjdk.org/jdk/pull/26621/files/8fe49703..9aa28717

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

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

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

From duke at openjdk.org  Mon Aug 18 14:02:48 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 18 Aug 2025 14:02:48 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v9]
In-Reply-To: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
Message-ID: <5EyWJEFaUKY6HFqth8UA_Xbxl02RXXHFzS_DpokTSVc=.d497ffaa-7995-4079-8524-f36d2d15f7e9@github.com>

> Hi all,
> 
> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110).
> 
> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports:
> 
> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup()
> 
> CPUTimeUsage::GC::gc_threads()
> CPUTimeUsage::GC::vm_thread()
> CPUTimeUsage::GC::stringdedup()
> 
> CPUTimeUsage::Runtime::vm_thread()
> 
> 
> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC.
> 
> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table:
> 
> 
> [71.425s][info][cpu   ] === CPU time Statistics =============================================================
> [71.425s][info][cpu   ]                                                                             CPUs
> [71.425s][info][cpu   ]                                                                s       %  utilized
> [71.425s][info][cpu   ]    Process
> [71.425s][info][cpu   ]      Total                                             1616.3627  100.00      22.6
> [71.425s][info][cpu   ]      VM Thread                                            5.2992    0.33       0.1
> [71.425s][info][cpu   ]      Garbage Collection                                  83.7322    5.18       1.2
> [71.425s][info][cpu   ]        GC Threads                                        82.7671    5.12       1.2
> [71.425s][info][cpu   ]        VM Thread                                          0.9651    0.06       0.0
> [71.425s][info][cpu   ] =====================================================================================
> 
> 
> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path.

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

  Fix indentation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26621/files
  - new: https://git.openjdk.org/jdk/pull/26621/files/9aa28717..afbff568

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

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

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

From aboldtch at openjdk.org  Tue Aug 19 07:33:39 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 19 Aug 2025 07:33:39 GMT
Subject: RFR: 8365189: Remove LockingMode related code from arm32
In-Reply-To: <bvw0sMNTLzhoms1UW34LXiFrkKDysBfeLAQftPjBh5o=.ddd3c817-4094-4cfe-afa2-4c751eae6814@github.com>
References: <bvw0sMNTLzhoms1UW34LXiFrkKDysBfeLAQftPjBh5o=.ddd3c817-4094-4cfe-afa2-4c751eae6814@github.com>
Message-ID: <k8o4tQO6pqduS-BNhurBtrb0y6o-MM-G4JVbXaySCEs=.912d4f04-56e5-44d8-9190-95f5d6f14e2b@github.com>

On Fri, 15 Aug 2025 09:29:04 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
> 
> This PR removes `LockingMode` related code from the **arm32** platform.
> 
> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.

Looks good.

You unified some comment styles within a file, but kept them different across the files. 
Not sure the Fall through comments do much now when the ifs are gone.
A bunch of `[un]lock_done` lables are now only used with bind and are never jumped to.

Not sure any of these require fixing.

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

Marked as reviewed by aboldtch (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26795#pullrequestreview-3131074689

From aboldtch at openjdk.org  Tue Aug 19 07:37:37 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 19 Aug 2025 07:37:37 GMT
Subject: RFR: 8365188: Remove LockingMode related code from s390
In-Reply-To: <xdOXPmKTkhBqJgMsl0kbtcuAtaHlLJevV7dM8fVecCY=.34afa6eb-bb0d-465b-bb25-2e6a6a052702@github.com>
References: <xdOXPmKTkhBqJgMsl0kbtcuAtaHlLJevV7dM8fVecCY=.34afa6eb-bb0d-465b-bb25-2e6a6a052702@github.com>
Message-ID: <D-fABkTLx6cg3htR7SGWw7tXqQch-o9u9aX5k8gTEO0=.df5d009b-0438-4ba7-8fd7-615e88b475dc@github.com>

On Thu, 14 Aug 2025 08:58:16 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
> 
> This PR removes `LockingMode` related code from the **s390** platform.
> 
> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.

Looks good.

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

Marked as reviewed by aboldtch (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26772#pullrequestreview-3131086583

From amitkumar at openjdk.org  Tue Aug 19 07:46:45 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Tue, 19 Aug 2025 07:46:45 GMT
Subject: RFR: 8358696: Assert with extreme values for -XX:BciProfileWidth
 [v8]
In-Reply-To: <yS5BgyK2thI_nWVancTKckcbnjEXM6OwRXxpNYKtxzs=.d24ff111-a6d0-42bd-883e-0287529a9e0d@github.com>
References: <5TRVeAXUQi6quM-nDWEij_jk6M5K2Vk31RA-Yjd8F2M=.5b63da45-93c3-4251-9e2e-3c64b7953919@github.com>
 <x48Qtjsnz7ccoI5LdqiDmB8kO8FwmDjSE3ItYbtB4v0=.c22c1404-5766-4c32-a73a-a331cbe50f6d@github.com>
 <yS5BgyK2thI_nWVancTKckcbnjEXM6OwRXxpNYKtxzs=.d24ff111-a6d0-42bd-883e-0287529a9e0d@github.com>
Message-ID: <uONzIphPGYyOICj3VZF7u5r5fK-R6D7CVtS1ZZ9RQUE=.15638d87-f4c6-4054-a326-fe1e7f2ceb69@github.com>

On Mon, 18 Aug 2025 08:37:50 GMT, Saranya Natarajan <snatarajan at openjdk.org> wrote:

> @offamitkumar and @TheRealMDoerr : Would it be possible to test this PR in s390 and PPC ?

Hi @sarannat, thanks for the ping.
I ran tier1 test on s390x and result came out clean.

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

PR Comment: https://git.openjdk.org/jdk/pull/26139#issuecomment-3199605352

From duke at openjdk.org  Tue Aug 19 07:50:50 2025
From: duke at openjdk.org (Yagmur Eren)
Date: Tue, 19 Aug 2025 07:50:50 GMT
Subject: RFR: 8358748: Large page size initialization fails with assert
 "page_size must be a power of 2" [v3]
In-Reply-To: <Hz4zDgclbM7HtZP8VHh3yQBPlYXYgGoxwkKwSS50r9E=.634dd3a2-fd10-45e5-85fb-9f038d5ebd9c@github.com>
References: <Hz4zDgclbM7HtZP8VHh3yQBPlYXYgGoxwkKwSS50r9E=.634dd3a2-fd10-45e5-85fb-9f038d5ebd9c@github.com>
Message-ID: <uPqssi7wmYY1Ps4ejkQFM6-FMiKGJe7gEVPVVHYx7Yw=.3245565d-eb9c-43d3-9bc8-630ca84a0fa3@github.com>

> The VM now exits gracefully if `-XX:LargePageSizeInBytes` is set to a non power of two value, instead of asserting. After this change, `SizeTTest.java` failed because the tested values are not valid for `-XX:LargePageSizeInBytes` (`LargePageSizeInBytesConstraintFunc` returns `JVMFlag::VIOLATES_CONSTRAINT`). Therefore, I updated the test to use `NUMASpaceResizeRate`, since I believe that it only requires a flag of type `size_t`.
> 
> Before the change:
> 
> java -XX:+UseLargePages -XX:LargePageSizeInBytes=6 -version
> 
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # Internal Error (workspace/open/src/hotspot/share/runtime/os.cpp:2449), pid=1885945, tid=1885946
> # assert(is_power_of_2(page_size)) failed: page_size must be a power of 2: 0x6
> 
> 
> 
> After the change:
> 
> java -XX:+UseLargePages -XX:LargePageSizeInBytes=6 -version
> 
> LargePageSizeInBytes ( 6 ) must be a power of 2
> Improperly specified VM option 'LargePageSizeInBytes=6'
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.

Yagmur Eren has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - resolve conflic and merge master
 - some fixes
 - updating year
 - 8358748: Large page size initialization fails with assert "page_size must be a power of 2"

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

Changes: https://git.openjdk.org/jdk/pull/25994/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25994&range=02
  Stats: 16 lines in 4 files changed: 13 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/25994.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25994/head:pull/25994

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

From amitkumar at openjdk.org  Tue Aug 19 07:52:38 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Tue, 19 Aug 2025 07:52:38 GMT
Subject: RFR: 8365188: Remove LockingMode related code from s390
In-Reply-To: <xdOXPmKTkhBqJgMsl0kbtcuAtaHlLJevV7dM8fVecCY=.34afa6eb-bb0d-465b-bb25-2e6a6a052702@github.com>
References: <xdOXPmKTkhBqJgMsl0kbtcuAtaHlLJevV7dM8fVecCY=.34afa6eb-bb0d-465b-bb25-2e6a6a052702@github.com>
Message-ID: <CyWdSqwCzjDyBDiLp5wwXqB9tNfQKtN8DArBV0pThFI=.9ce20f63-7b5c-4324-b11d-01dd03a0fb6b@github.com>

On Thu, 14 Aug 2025 08:58:16 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
> 
> This PR removes `LockingMode` related code from the **s390** platform.
> 
> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.

I am running test on it, I will return with result in sometime. Sorry for delay.

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

PR Comment: https://git.openjdk.org/jdk/pull/26772#issuecomment-3199629648

From sjohanss at openjdk.org  Tue Aug 19 08:19:42 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Tue, 19 Aug 2025 08:19:42 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v9]
In-Reply-To: <5EyWJEFaUKY6HFqth8UA_Xbxl02RXXHFzS_DpokTSVc=.d497ffaa-7995-4079-8524-f36d2d15f7e9@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <5EyWJEFaUKY6HFqth8UA_Xbxl02RXXHFzS_DpokTSVc=.d497ffaa-7995-4079-8524-f36d2d15f7e9@github.com>
Message-ID: <Bu03eC719kfHl3voUWlvrisJferkSTjgHzBcB5tO7h8=.12d14aaa-9b47-4063-bc11-8c4482d5353a@github.com>

On Mon, 18 Aug 2025 14:02:48 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110).
>> 
>> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports:
>> 
>> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup()
>> 
>> CPUTimeUsage::GC::gc_threads()
>> CPUTimeUsage::GC::vm_thread()
>> CPUTimeUsage::GC::stringdedup()
>> 
>> CPUTimeUsage::Runtime::vm_thread()
>> 
>> 
>> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC.
>> 
>> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table:
>> 
>> 
>> [71.425s][info][cpu   ] === CPU time Statistics =============================================================
>> [71.425s][info][cpu   ]                                                                             CPUs
>> [71.425s][info][cpu   ]                                                                s       %  utilized
>> [71.425s][info][cpu   ]    Process
>> [71.425s][info][cpu   ]      Total                                             1616.3627  100.00      22.6
>> [71.425s][info][cpu   ]      VM Thread                                            5.2992    0.33       0.1
>> [71.425s][info][cpu   ]      Garbage Collection                                  83.7322    5.18       1.2
>> [71.425s][info][cpu   ]        GC Threads                                        82.7671    5.12       1.2
>> [71.425s][info][cpu   ]        VM Thread                                          0.9651    0.06       0.0
>> [71.425s][info][cpu   ] =====================================================================================
>> 
>> 
>> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix indentation

Just some minor things that you can fix before integrating. Otherwise I think this looks good.

src/hotspot/share/gc/shared/collectedHeap.cpp line 59:

> 57: #include "runtime/threadSMR.hpp"
> 58: #include "runtime/vmThread.hpp"
> 59: #include "services/cpuTimeUsage.hpp"

Can be removed now.

src/hotspot/share/gc/shared/collectedHeap.hpp line 434:

> 432:   void print_relative_to_gc(GCWhen::Type when) const;
> 433: 
> 434:   void log_cpu_time() const;

This has moved to `Universe` and can be removed.

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

Marked as reviewed by sjohanss (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26621#pullrequestreview-3131175838
PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2284454451
PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2284450710

From ayang at openjdk.org  Tue Aug 19 08:29:43 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 19 Aug 2025 08:29:43 GMT
Subject: RFR: 8358748: Large page size initialization fails with assert
 "page_size must be a power of 2" [v3]
In-Reply-To: <uPqssi7wmYY1Ps4ejkQFM6-FMiKGJe7gEVPVVHYx7Yw=.3245565d-eb9c-43d3-9bc8-630ca84a0fa3@github.com>
References: <Hz4zDgclbM7HtZP8VHh3yQBPlYXYgGoxwkKwSS50r9E=.634dd3a2-fd10-45e5-85fb-9f038d5ebd9c@github.com>
 <uPqssi7wmYY1Ps4ejkQFM6-FMiKGJe7gEVPVVHYx7Yw=.3245565d-eb9c-43d3-9bc8-630ca84a0fa3@github.com>
Message-ID: <wwuimXJfmgqUnIYirl59fjPNOkNy2b-Zilp_3Sl1IVw=.a89961f6-26e7-4e04-b951-6bd6e9ae1823@github.com>

On Tue, 19 Aug 2025 07:50:50 GMT, Yagmur Eren <duke at openjdk.org> wrote:

>> The VM now exits gracefully if `-XX:LargePageSizeInBytes` is set to a non power of two value, instead of asserting. After this change, `SizeTTest.java` failed because the tested values are not valid for `-XX:LargePageSizeInBytes` (`LargePageSizeInBytesConstraintFunc` returns `JVMFlag::VIOLATES_CONSTRAINT`). Therefore, I updated the test to use `NUMASpaceResizeRate`, since I believe that it only requires a flag of type `size_t`.
>> 
>> Before the change:
>> 
>> java -XX:+UseLargePages -XX:LargePageSizeInBytes=6 -version
>> 
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> # Internal Error (workspace/open/src/hotspot/share/runtime/os.cpp:2449), pid=1885945, tid=1885946
>> # assert(is_power_of_2(page_size)) failed: page_size must be a power of 2: 0x6
>> 
>> 
>> 
>> After the change:
>> 
>> java -XX:+UseLargePages -XX:LargePageSizeInBytes=6 -version
>> 
>> LargePageSizeInBytes ( 6 ) must be a power of 2
>> Improperly specified VM option 'LargePageSizeInBytes=6'
>> Error: Could not create the Java Virtual Machine.
>> Error: A fatal exception has occurred. Program will exit.
>
> Yagmur Eren has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - resolve conflic and merge master
>  - some fixes
>  - updating year
>  - 8358748: Large page size initialization fails with assert "page_size must be a power of 2"

> Therefore, I updated the test to use NUMASpaceResizeRate, since I believe that it only requires a flag of type size_t.

How about `LargePageHeapSizeThreshold`? It's `size_t` also. (`NUMASpaceResizeRate` is a ParallelGC-only flag.)

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

PR Comment: https://git.openjdk.org/jdk/pull/25994#issuecomment-3199759357

From duke at openjdk.org  Tue Aug 19 08:35:51 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 19 Aug 2025 08:35:51 GMT
Subject: RFR: 8365556: ObjectMonitor::try_lock_or_add_to_entry_list()
 returns true with the wrong state of the node [v2]
In-Reply-To: <YUOnpPZ57q-9oW7npgsONxWYI6K-FdUtvmSNzIO7w1Q=.06f70f3d-17e7-4583-9890-fe52d7a7af13@github.com>
References: <YUOnpPZ57q-9oW7npgsONxWYI6K-FdUtvmSNzIO7w1Q=.06f70f3d-17e7-4583-9890-fe52d7a7af13@github.com>
Message-ID: <QLgZ6cuvFwxw4XyzNpGDNrtRQ-F9q7use9MitZrmtOw=.79c74b19-99fd-45d9-8309-68dc15cbf13d@github.com>

> Hi, please consider the following change:
> 
> `ObjectMonitor::try_lock_or_add_to_entry_list() `does not change the node state to `TS_RUN `in case of a successful acquisition of the object monitor. In certain cases this can break the guarantee statement in the `ObjectMonitor::wait()` method and lead to a crash. The missing statement is added.
> 
> Tested in tiers 1 - 5.

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

  8365556: Added assert.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26794/files
  - new: https://git.openjdk.org/jdk/pull/26794/files/bf872c07..ad96db95

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

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

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

From duke at openjdk.org  Tue Aug 19 08:35:52 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 19 Aug 2025 08:35:52 GMT
Subject: RFR: 8365556: ObjectMonitor::try_lock_or_add_to_entry_list()
 returns true with the wrong state of the node
In-Reply-To: <6MCqstmaVLWyEWeYqasaUuNVK2CZzQ-fpNTUl8Mwy8Q=.ba4bbed6-ad34-4deb-bf5a-591e91d8b140@github.com>
References: <YUOnpPZ57q-9oW7npgsONxWYI6K-FdUtvmSNzIO7w1Q=.06f70f3d-17e7-4583-9890-fe52d7a7af13@github.com>
 <6MCqstmaVLWyEWeYqasaUuNVK2CZzQ-fpNTUl8Mwy8Q=.ba4bbed6-ad34-4deb-bf5a-591e91d8b140@github.com>
Message-ID: <7QLIaobSCybIX6vATlwuMu8U6n3uG_92pKUGGyK3gpw=.db0bb697-59f4-4703-b8f1-25769cf9b84e@github.com>

On Fri, 15 Aug 2025 14:37:31 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> I'm fine with the fix, I was just confused about the mention of the crash. I would also add `assert(node->TState == ObjectWaiter::TS_RUN, "");` at the top to avoid surprises.

Added an assert as suggested.

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

PR Comment: https://git.openjdk.org/jdk/pull/26794#issuecomment-3199771282

From duke at openjdk.org  Tue Aug 19 08:42:15 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Tue, 19 Aug 2025 08:42:15 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v10]
In-Reply-To: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
Message-ID: <Arayu_lQJTrqeOoW6nApckf17U1CtqswWgNJIhRKeas=.d121db1b-6cc3-4219-9624-0b57a8f62a4b@github.com>

> Hi all,
> 
> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110).
> 
> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports:
> 
> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup()
> 
> CPUTimeUsage::GC::gc_threads()
> CPUTimeUsage::GC::vm_thread()
> CPUTimeUsage::GC::stringdedup()
> 
> CPUTimeUsage::Runtime::vm_thread()
> 
> 
> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC.
> 
> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table:
> 
> 
> [71.425s][info][cpu   ] === CPU time Statistics =============================================================
> [71.425s][info][cpu   ]                                                                             CPUs
> [71.425s][info][cpu   ]                                                                s       %  utilized
> [71.425s][info][cpu   ]    Process
> [71.425s][info][cpu   ]      Total                                             1616.3627  100.00      22.6
> [71.425s][info][cpu   ]      VM Thread                                            5.2992    0.33       0.1
> [71.425s][info][cpu   ]      Garbage Collection                                  83.7322    5.18       1.2
> [71.425s][info][cpu   ]        GC Threads                                        82.7671    5.12       1.2
> [71.425s][info][cpu   ]        VM Thread                                          0.9651    0.06       0.0
> [71.425s][info][cpu   ] =====================================================================================
> 
> 
> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path.

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

  Remove unused

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26621/files
  - new: https://git.openjdk.org/jdk/pull/26621/files/afbff568..79a3323a

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

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

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

From aboldtch at openjdk.org  Tue Aug 19 09:21:47 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 19 Aug 2025 09:21:47 GMT
Subject: RFR: 8365146: Remove LockingMode related code from ppc64 [v2]
In-Reply-To: <101mw24zKLsjXjexjOZKimofI_yySxPw3gGyJq9HT1s=.495f1653-86ec-4d90-82d6-091b90d592f6@github.com>
References: <mKtlz6j_OunSKwTrSfwVxcErf8oTsclqe65OSJxXvlw=.b958a3bc-0253-4efd-a9ff-03ac0418ba23@github.com>
 <101mw24zKLsjXjexjOZKimofI_yySxPw3gGyJq9HT1s=.495f1653-86ec-4d90-82d6-091b90d592f6@github.com>
Message-ID: <lDv87wwNxFTatW7iTcnUxngvPSEfFS8cfX8-xpEJ1nE=.b7d43f39-edd5-4c79-bd1f-c03988edfe0f@github.com>

On Tue, 12 Aug 2025 13:12:33 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
>> 
>> This PR removes `LockingMode` related code from the **ppc64** platform.
>> 
>> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.
>
> Fredrik Bredberg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into 8365146_remove_lockingmode_ppc64
>  - 8365146: Remove LockingMode related code from ppc64

Looks good. Just need to remove some declarations in `src/hotspot/cpu/ppc/macroAssembler_ppc.hpp`

src/hotspot/cpu/ppc/macroAssembler_ppc.cpp line 2675:

> 2673: // "The box" is the space on the stack where we copy the object mark.
> 2674: void MacroAssembler::compiler_fast_lock_object(ConditionRegister flag, Register oop, Register box,
> 2675:                                                Register temp, Register displaced_header, Register current_header) {

Need to remove the declarations in the hpp file as well.

src/hotspot/cpu/ppc/macroAssembler_ppc.cpp line 2799:

> 2797: 
> 2798: void MacroAssembler::compiler_fast_unlock_object(ConditionRegister flag, Register oop, Register box,
> 2799:                                                  Register temp, Register displaced_header, Register current_header) {

Need to remove the declarations in the hpp file as well.

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

Marked as reviewed by aboldtch (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26697#pullrequestreview-3131439894
PR Review Comment: https://git.openjdk.org/jdk/pull/26697#discussion_r2284643473
PR Review Comment: https://git.openjdk.org/jdk/pull/26697#discussion_r2284644000

From amitkumar at openjdk.org  Tue Aug 19 09:59:39 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Tue, 19 Aug 2025 09:59:39 GMT
Subject: RFR: 8365188: Remove LockingMode related code from s390
In-Reply-To: <xdOXPmKTkhBqJgMsl0kbtcuAtaHlLJevV7dM8fVecCY=.34afa6eb-bb0d-465b-bb25-2e6a6a052702@github.com>
References: <xdOXPmKTkhBqJgMsl0kbtcuAtaHlLJevV7dM8fVecCY=.34afa6eb-bb0d-465b-bb25-2e6a6a052702@github.com>
Message-ID: <kudDHHOsWJ87Gbmird0PClT1dspCi4KD771ePd95URM=.4ecdf217-c3f8-4ece-8d32-efdfd2b50c69@github.com>

On Thu, 14 Aug 2025 08:58:16 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
> 
> This PR removes `LockingMode` related code from the **s390** platform.
> 
> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.

LGTM, tier1 tests are clean.

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

Marked as reviewed by amitkumar (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26772#pullrequestreview-3131586801

From mdoerr at openjdk.org  Tue Aug 19 10:15:42 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 19 Aug 2025 10:15:42 GMT
Subject: RFR: 8365146: Remove LockingMode related code from ppc64 [v2]
In-Reply-To: <101mw24zKLsjXjexjOZKimofI_yySxPw3gGyJq9HT1s=.495f1653-86ec-4d90-82d6-091b90d592f6@github.com>
References: <mKtlz6j_OunSKwTrSfwVxcErf8oTsclqe65OSJxXvlw=.b958a3bc-0253-4efd-a9ff-03ac0418ba23@github.com>
 <101mw24zKLsjXjexjOZKimofI_yySxPw3gGyJq9HT1s=.495f1653-86ec-4d90-82d6-091b90d592f6@github.com>
Message-ID: <veNK5YHW2-_-5I7ZnHjI8vtY8vGx4phAMoFQigywRU0=.98591381-1c30-475d-a834-fccc29a76b3d@github.com>

On Tue, 12 Aug 2025 13:12:33 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
>> 
>> This PR removes `LockingMode` related code from the **ppc64** platform.
>> 
>> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.
>
> Fredrik Bredberg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into 8365146_remove_lockingmode_ppc64
>  - 8365146: Remove LockingMode related code from ppc64

This looks good besides the missing .hpp file update.
Not sure what the plan regarding [JDK-8336325](https://bugs.openjdk.org/browse/JDK-8336325) is and if some of the removed code will be needed again.

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

PR Comment: https://git.openjdk.org/jdk/pull/26697#issuecomment-3200121233

From duke at openjdk.org  Tue Aug 19 11:27:51 2025
From: duke at openjdk.org (Yagmur Eren)
Date: Tue, 19 Aug 2025 11:27:51 GMT
Subject: RFR: 8358748: Large page size initialization fails with assert
 "page_size must be a power of 2" [v4]
In-Reply-To: <Hz4zDgclbM7HtZP8VHh3yQBPlYXYgGoxwkKwSS50r9E=.634dd3a2-fd10-45e5-85fb-9f038d5ebd9c@github.com>
References: <Hz4zDgclbM7HtZP8VHh3yQBPlYXYgGoxwkKwSS50r9E=.634dd3a2-fd10-45e5-85fb-9f038d5ebd9c@github.com>
Message-ID: <0sNSlwoh94xjIpd-z7WS2dp4bplQ27RJtawI5rR3G0M=.6d29b3ac-5580-42c2-ae54-bba6f00a9090@github.com>

> The VM now exits gracefully if `-XX:LargePageSizeInBytes` is set to a non power of two value, instead of asserting. After this change, `SizeTTest.java` failed because the tested values are not valid for `-XX:LargePageSizeInBytes` (`LargePageSizeInBytesConstraintFunc` returns `JVMFlag::VIOLATES_CONSTRAINT`). Therefore, I updated the test to use `NUMASpaceResizeRate`, since I believe that it only requires a flag of type `size_t`.
> 
> Before the change:
> 
> java -XX:+UseLargePages -XX:LargePageSizeInBytes=6 -version
> 
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # Internal Error (workspace/open/src/hotspot/share/runtime/os.cpp:2449), pid=1885945, tid=1885946
> # assert(is_power_of_2(page_size)) failed: page_size must be a power of 2: 0x6
> 
> 
> 
> After the change:
> 
> java -XX:+UseLargePages -XX:LargePageSizeInBytes=6 -version
> 
> LargePageSizeInBytes ( 6 ) must be a power of 2
> Improperly specified VM option 'LargePageSizeInBytes=6'
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.

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

  change the flag in sizet test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25994/files
  - new: https://git.openjdk.org/jdk/pull/25994/files/d5fdb70b..6dfa4a29

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

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

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

From duke at openjdk.org  Tue Aug 19 11:27:52 2025
From: duke at openjdk.org (Yagmur Eren)
Date: Tue, 19 Aug 2025 11:27:52 GMT
Subject: RFR: 8358748: Large page size initialization fails with assert
 "page_size must be a power of 2" [v3]
In-Reply-To: <wwuimXJfmgqUnIYirl59fjPNOkNy2b-Zilp_3Sl1IVw=.a89961f6-26e7-4e04-b951-6bd6e9ae1823@github.com>
References: <Hz4zDgclbM7HtZP8VHh3yQBPlYXYgGoxwkKwSS50r9E=.634dd3a2-fd10-45e5-85fb-9f038d5ebd9c@github.com>
 <uPqssi7wmYY1Ps4ejkQFM6-FMiKGJe7gEVPVVHYx7Yw=.3245565d-eb9c-43d3-9bc8-630ca84a0fa3@github.com>
 <wwuimXJfmgqUnIYirl59fjPNOkNy2b-Zilp_3Sl1IVw=.a89961f6-26e7-4e04-b951-6bd6e9ae1823@github.com>
Message-ID: <hGDovyqCllyjyFNlRFHR5FPYJAgnhRts49fufMkx0D4=.5a7c5b81-e492-42ce-a73e-06ebccf158ae@github.com>

On Tue, 19 Aug 2025 08:27:21 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> > Therefore, I updated the test to use NUMASpaceResizeRate, since I believe that it only requires a flag of type size_t.
> 
> How about `LargePageHeapSizeThreshold`? It's `size_t` also. (`NUMASpaceResizeRate` is a ParallelGC-only flag.)

LargePageHeapSizeThreshold would be better. I'll replace it. Thanks for the suggestion @albertnetymk!

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

PR Comment: https://git.openjdk.org/jdk/pull/25994#issuecomment-3200348697

From ayang at openjdk.org  Tue Aug 19 11:35:39 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 19 Aug 2025 11:35:39 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v10]
In-Reply-To: <Arayu_lQJTrqeOoW6nApckf17U1CtqswWgNJIhRKeas=.d121db1b-6cc3-4219-9624-0b57a8f62a4b@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <Arayu_lQJTrqeOoW6nApckf17U1CtqswWgNJIhRKeas=.d121db1b-6cc3-4219-9624-0b57a8f62a4b@github.com>
Message-ID: <iltLcUikaazrinRRYqwwtpi3BPf7MCqWrZALolhvK3c=.844faca7-d83f-48ac-8c4b-aedc6847f23e@github.com>

On Tue, 19 Aug 2025 08:42:15 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110).
>> 
>> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports:
>> 
>> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup()
>> 
>> CPUTimeUsage::GC::gc_threads()
>> CPUTimeUsage::GC::vm_thread()
>> CPUTimeUsage::GC::stringdedup()
>> 
>> CPUTimeUsage::Runtime::vm_thread()
>> 
>> 
>> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC.
>> 
>> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table:
>> 
>> 
>> [71.425s][info][cpu   ] === CPU time Statistics =============================================================
>> [71.425s][info][cpu   ]                                                                             CPUs
>> [71.425s][info][cpu   ]                                                                s       %  utilized
>> [71.425s][info][cpu   ]    Process
>> [71.425s][info][cpu   ]      Total                                             1616.3627  100.00      22.6
>> [71.425s][info][cpu   ]      VM Thread                                            5.2992    0.33       0.1
>> [71.425s][info][cpu   ]      Garbage Collection                                  83.7322    5.18       1.2
>> [71.425s][info][cpu   ]        GC Threads                                        82.7671    5.12       1.2
>> [71.425s][info][cpu   ]        VM Thread                                          0.9651    0.06       0.0
>> [71.425s][info][cpu   ] =====================================================================================
>> 
>> 
>> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused

src/hotspot/share/gc/shared/collectedHeap.cpp line 625:

> 623:       ClassLoaderDataGraph::print_on(&ls_trace);
> 624:     }
> 625:   }

I don't think this code movement should be done -- this calls back to `Universe` and CLDG printing is not necessarily tired to heap.

src/hotspot/share/services/cpuTimeUsage.cpp line 43:

> 41: public:
> 42:   virtual void do_thread(Thread* thread) {
> 43:     jlong cpu_time = os::thread_cpu_time(thread);

I guess a wrapper for `thread_cpu_time` can be created to group error-handling logic together, for all uses in this file.


jlong thread_cpu_time_or_zero(thread) {
  jlong cpu_time = os::..
  if (cpu_time == -1) {
    // mark-error
    return 0;
  }
  return cpu_time;
}

src/hotspot/share/services/cpuTimeUsage.hpp line 47:

> 45:     static jlong gc_threads();
> 46:     static jlong vm_thread();
> 47:     static jlong stringdedup();

I feel the API surface contains some redundancy.

For example, the GC-part API design exposes two ways to query and they are essentially the same -- for the sake of simplicity, I'd suggest keeping only one.

The calculation of `total` should be done by users of this API, I believe, when/if total is desirable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2284933253
PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2284962585
PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2284952784

From mdoerr at openjdk.org  Tue Aug 19 12:42:52 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 19 Aug 2025 12:42:52 GMT
Subject: RFR: 8358696: Assert with extreme values for -XX:BciProfileWidth
 [v8]
In-Reply-To: <x48Qtjsnz7ccoI5LdqiDmB8kO8FwmDjSE3ItYbtB4v0=.c22c1404-5766-4c32-a73a-a331cbe50f6d@github.com>
References: <5TRVeAXUQi6quM-nDWEij_jk6M5K2Vk31RA-Yjd8F2M=.5b63da45-93c3-4251-9e2e-3c64b7953919@github.com>
 <x48Qtjsnz7ccoI5LdqiDmB8kO8FwmDjSE3ItYbtB4v0=.c22c1404-5766-4c32-a73a-a331cbe50f6d@github.com>
Message-ID: <8gpz_pU_CectqZVtFlnWv0zMO4uSz5lT0KL4SUHdMFA=.3d7d897f-3fd7-4456-ba92-097811b50dee@github.com>

On Wed, 13 Aug 2025 09:35:08 GMT, Saranya Natarajan <snatarajan at openjdk.org> wrote:

>> **Issue**
>> Extreme values for BciProfileWidth flag such as `java -XX:BciProfileWidth=-1 -version` and `java -XX:BciProfileWidth=100000 -version `results in assert failure `assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x0000772b63a7a3a0 <= 0x0000772b63b75159 <= 0x0000772b63b75158 `. This is observed in a x86 machine.
>> 
>> **Analysis** 
>>  On debugging the issue, I found that increasing the size of the interpreter using the `InterpreterCodeSize` variable in `src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp` prevented the above mentioned assert from failing for large values of BciProfileWidth.  
>> 
>> **Proposal** 
>> Considering the fact that larger BciProfileWidth results in slower profiling, I have proposed a range between 0 to 5000 to restrict the value for BciProfileWidth for x86 machines. This maximum value is based on modifying the `InterpreterCodeSize` variable in `src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp` using the smallest `InterpreterCodeSize` for all the architectures.  As for the lower bound, a value of -1 would be the same as 0, as this simply means  no  return bci's will be recorded in ret profile. 
>> 
>> **Issue in AArch64**
>> Additionally running the command `java -XX:BciProfileWidth= 10000 -version` (or larger values) results in a different failure  `assert(offset_ok_for_immed(offset(), size)) failed: must be, was: 32768, 3` on an AArch64 machine.This is an issue of maximum offset for `ldr/str` in AArch64 which can be fixed using `form_address`  as mentioned in [JDK-8342736](https://bugs.openjdk.org/browse/JDK-8342736). In my preliminary fix using `form_address` on AArch64 machine. I had to modify 3 `ldr` and 1 `str` instruction (in file `src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp` at line number 926, 983, and 997). With this fix  using `form_address`, `BciProfileWidth` works for maximum of 5000 after which it crashes with`assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x0000772b63a7a3a0 <= 0x0000772b63b75159 <= 0x0000772b63b75158 `.  Without this fix `BciProfileWidth` works for a maximum value of 1300.   Currently, I have suggested to restrict the upper bound on AArch64 to 1000 instead
  of fixing it with `form_address`. 
>> 
>> **Question to reviewers**
>> Do you think this is a reasonable fix ?  For AArch64 do you suggest fixing using `form_address` ? If yes, do I fix it under this PR or create another one ?
>> 
>> **Request to port maintainers**
>> @dafedafe suggested that we keep the upper boun...
>
> Saranya Natarajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   additions for  linux-riscv64

PPC64 will need a fix, too. I'm looking into it. Thanks for the ping!

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

PR Comment: https://git.openjdk.org/jdk/pull/26139#issuecomment-3200597749

From snatarajan at openjdk.org  Tue Aug 19 12:42:51 2025
From: snatarajan at openjdk.org (Saranya Natarajan)
Date: Tue, 19 Aug 2025 12:42:51 GMT
Subject: RFR: 8358696: Assert with extreme values for -XX:BciProfileWidth
 [v8]
In-Reply-To: <uONzIphPGYyOICj3VZF7u5r5fK-R6D7CVtS1ZZ9RQUE=.15638d87-f4c6-4054-a326-fe1e7f2ceb69@github.com>
References: <5TRVeAXUQi6quM-nDWEij_jk6M5K2Vk31RA-Yjd8F2M=.5b63da45-93c3-4251-9e2e-3c64b7953919@github.com>
 <x48Qtjsnz7ccoI5LdqiDmB8kO8FwmDjSE3ItYbtB4v0=.c22c1404-5766-4c32-a73a-a331cbe50f6d@github.com>
 <yS5BgyK2thI_nWVancTKckcbnjEXM6OwRXxpNYKtxzs=.d24ff111-a6d0-42bd-883e-0287529a9e0d@github.com>
 <uONzIphPGYyOICj3VZF7u5r5fK-R6D7CVtS1ZZ9RQUE=.15638d87-f4c6-4054-a326-fe1e7f2ceb69@github.com>
Message-ID: <TuwNKasOu_AZ-jppCelzwlkXCHE5pPB1yOB5FqJqVKI=.24abeb5e-dad9-4d4c-8f43-e23122706835@github.com>

On Tue, 19 Aug 2025 07:43:55 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> @offamitkumar and @TheRealMDoerr : Would it be possible to test this PR in s390 and PPC ?
>
>> @offamitkumar and @TheRealMDoerr : Would it be possible to test this PR in s390 and PPC ?
> 
> Hi @sarannat, thanks for the ping.
> I ran tier1 test on s390x and result came out clean.

Thank you @offamitkumar

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

PR Comment: https://git.openjdk.org/jdk/pull/26139#issuecomment-3200596492

From ayang at openjdk.org  Tue Aug 19 12:57:44 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 19 Aug 2025 12:57:44 GMT
Subject: RFR: 8358748: Large page size initialization fails with assert
 "page_size must be a power of 2" [v4]
In-Reply-To: <0sNSlwoh94xjIpd-z7WS2dp4bplQ27RJtawI5rR3G0M=.6d29b3ac-5580-42c2-ae54-bba6f00a9090@github.com>
References: <Hz4zDgclbM7HtZP8VHh3yQBPlYXYgGoxwkKwSS50r9E=.634dd3a2-fd10-45e5-85fb-9f038d5ebd9c@github.com>
 <0sNSlwoh94xjIpd-z7WS2dp4bplQ27RJtawI5rR3G0M=.6d29b3ac-5580-42c2-ae54-bba6f00a9090@github.com>
Message-ID: <4zrUBlDVoRdM5MdMjmVHPiQx2dfaDtIriuZSIRSlh7s=.f3c5b225-7b13-4190-9500-3e309322b415@github.com>

On Tue, 19 Aug 2025 11:27:51 GMT, Yagmur Eren <duke at openjdk.org> wrote:

>> The VM now exits gracefully if `-XX:LargePageSizeInBytes` is set to a non power of two value, instead of asserting. After this change, `SizeTTest.java` failed because the tested values are not valid for `-XX:LargePageSizeInBytes` (`LargePageSizeInBytesConstraintFunc` returns `JVMFlag::VIOLATES_CONSTRAINT`). Therefore, I updated the test to use `NUMASpaceResizeRate`, since I believe that it only requires a flag of type `size_t`.
>> 
>> Before the change:
>> 
>> java -XX:+UseLargePages -XX:LargePageSizeInBytes=6 -version
>> 
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> # Internal Error (workspace/open/src/hotspot/share/runtime/os.cpp:2449), pid=1885945, tid=1885946
>> # assert(is_power_of_2(page_size)) failed: page_size must be a power of 2: 0x6
>> 
>> 
>> 
>> After the change:
>> 
>> java -XX:+UseLargePages -XX:LargePageSizeInBytes=6 -version
>> 
>> LargePageSizeInBytes ( 6 ) must be a power of 2
>> Improperly specified VM option 'LargePageSizeInBytes=6'
>> Error: Could not create the Java Virtual Machine.
>> Error: A fatal exception has occurred. Program will exit.
>
> Yagmur Eren has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change the flag in sizet test

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25994#pullrequestreview-3132196535

From pchilanomate at openjdk.org  Tue Aug 19 13:47:38 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 19 Aug 2025 13:47:38 GMT
Subject: RFR: 8365556: ObjectMonitor::try_lock_or_add_to_entry_list()
 returns true with the wrong state of the node [v2]
In-Reply-To: <QLgZ6cuvFwxw4XyzNpGDNrtRQ-F9q7use9MitZrmtOw=.79c74b19-99fd-45d9-8309-68dc15cbf13d@github.com>
References: <YUOnpPZ57q-9oW7npgsONxWYI6K-FdUtvmSNzIO7w1Q=.06f70f3d-17e7-4583-9890-fe52d7a7af13@github.com>
 <QLgZ6cuvFwxw4XyzNpGDNrtRQ-F9q7use9MitZrmtOw=.79c74b19-99fd-45d9-8309-68dc15cbf13d@github.com>
Message-ID: <3CB3-CW7d54OyloUybGfHwSkFiFmorGSxJWmI1hbtUQ=.4efd37d9-b380-4b96-a32a-abd9bde14ea7@github.com>

On Tue, 19 Aug 2025 08:35:51 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi, please consider the following change:
>> 
>> `ObjectMonitor::try_lock_or_add_to_entry_list() `does not change the node state to `TS_RUN `in case of a successful acquisition of the object monitor. In certain cases this can break the guarantee statement in the `ObjectMonitor::wait()` method and lead to a crash. The missing statement is added.
>> 
>> Tested in tiers 1 - 5.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8365556: Added assert.

Thanks, looks good to me.

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

Marked as reviewed by pchilanomate (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26794#pullrequestreview-3132420444

From duke at openjdk.org  Tue Aug 19 13:54:43 2025
From: duke at openjdk.org (duke)
Date: Tue, 19 Aug 2025 13:54:43 GMT
Subject: RFR: 8365556: ObjectMonitor::try_lock_or_add_to_entry_list()
 returns true with the wrong state of the node [v2]
In-Reply-To: <QLgZ6cuvFwxw4XyzNpGDNrtRQ-F9q7use9MitZrmtOw=.79c74b19-99fd-45d9-8309-68dc15cbf13d@github.com>
References: <YUOnpPZ57q-9oW7npgsONxWYI6K-FdUtvmSNzIO7w1Q=.06f70f3d-17e7-4583-9890-fe52d7a7af13@github.com>
 <QLgZ6cuvFwxw4XyzNpGDNrtRQ-F9q7use9MitZrmtOw=.79c74b19-99fd-45d9-8309-68dc15cbf13d@github.com>
Message-ID: <Sv94fYVmnPFYV8NsUt7Ul0DcSZZzY_T28bwc2wYMz4M=.2f054dbb-c41a-4358-b85e-1fa1d7cffb4c@github.com>

On Tue, 19 Aug 2025 08:35:51 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi, please consider the following change:
>> 
>> `ObjectMonitor::try_lock_or_add_to_entry_list() `does not change the node state to `TS_RUN `in case of a successful acquisition of the object monitor. In certain cases this can break the guarantee statement in the `ObjectMonitor::wait()` method and lead to a crash. The missing statement is added.
>> 
>> Tested in tiers 1 - 5.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8365556: Added assert.

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

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

PR Comment: https://git.openjdk.org/jdk/pull/26794#issuecomment-3200859828

From mdoerr at openjdk.org  Tue Aug 19 14:04:02 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 19 Aug 2025 14:04:02 GMT
Subject: RFR: 8358696: Assert with extreme values for -XX:BciProfileWidth
 [v8]
In-Reply-To: <x48Qtjsnz7ccoI5LdqiDmB8kO8FwmDjSE3ItYbtB4v0=.c22c1404-5766-4c32-a73a-a331cbe50f6d@github.com>
References: <5TRVeAXUQi6quM-nDWEij_jk6M5K2Vk31RA-Yjd8F2M=.5b63da45-93c3-4251-9e2e-3c64b7953919@github.com>
 <x48Qtjsnz7ccoI5LdqiDmB8kO8FwmDjSE3ItYbtB4v0=.c22c1404-5766-4c32-a73a-a331cbe50f6d@github.com>
Message-ID: <dQpWK73ywNOwdDT1Z0ByXG3wjWojGgmkdPZfey5B80M=.e14f639f-5ea6-46a1-9ca6-1f006e8bec9b@github.com>

On Wed, 13 Aug 2025 09:35:08 GMT, Saranya Natarajan <snatarajan at openjdk.org> wrote:

>> **Issue**
>> Extreme values for BciProfileWidth flag such as `java -XX:BciProfileWidth=-1 -version` and `java -XX:BciProfileWidth=100000 -version `results in assert failure `assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x0000772b63a7a3a0 <= 0x0000772b63b75159 <= 0x0000772b63b75158 `. This is observed in a x86 machine.
>> 
>> **Analysis** 
>>  On debugging the issue, I found that increasing the size of the interpreter using the `InterpreterCodeSize` variable in `src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp` prevented the above mentioned assert from failing for large values of BciProfileWidth.  
>> 
>> **Proposal** 
>> Considering the fact that larger BciProfileWidth results in slower profiling, I have proposed a range between 0 to 5000 to restrict the value for BciProfileWidth for x86 machines. This maximum value is based on modifying the `InterpreterCodeSize` variable in `src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp` using the smallest `InterpreterCodeSize` for all the architectures.  As for the lower bound, a value of -1 would be the same as 0, as this simply means  no  return bci's will be recorded in ret profile. 
>> 
>> **Issue in AArch64**
>> Additionally running the command `java -XX:BciProfileWidth= 10000 -version` (or larger values) results in a different failure  `assert(offset_ok_for_immed(offset(), size)) failed: must be, was: 32768, 3` on an AArch64 machine.This is an issue of maximum offset for `ldr/str` in AArch64 which can be fixed using `form_address`  as mentioned in [JDK-8342736](https://bugs.openjdk.org/browse/JDK-8342736). In my preliminary fix using `form_address` on AArch64 machine. I had to modify 3 `ldr` and 1 `str` instruction (in file `src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp` at line number 926, 983, and 997). With this fix  using `form_address`, `BciProfileWidth` works for maximum of 5000 after which it crashes with`assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x0000772b63a7a3a0 <= 0x0000772b63b75159 <= 0x0000772b63b75158 `.  Without this fix `BciProfileWidth` works for a maximum value of 1300.   Currently, I have suggested to restrict the upper bound on AArch64 to 1000 instead
  of fixing it with `form_address`. 
>> 
>> **Question to reviewers**
>> Do you think this is a reasonable fix ?  For AArch64 do you suggest fixing using `form_address` ? If yes, do I fix it under this PR or create another one ?
>> 
>> **Request to port maintainers**
>> @dafedafe suggested that we keep the upper boun...
>
> Saranya Natarajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   additions for  linux-riscv64

Can you add this patch, please?

diff --git a/src/hotspot/cpu/ppc/interp_masm_ppc.hpp b/src/hotspot/cpu/ppc/interp_masm_ppc.hpp
index d3969427db3..ac3825d152f 100644
--- a/src/hotspot/cpu/ppc/interp_masm_ppc.hpp
+++ b/src/hotspot/cpu/ppc/interp_masm_ppc.hpp
@@ -228,7 +228,7 @@ class InterpreterMacroAssembler: public MacroAssembler {
 
   // Interpreter profiling operations
   void set_method_data_pointer_for_bcp();
-  void test_method_data_pointer(Label& zero_continue);
+  void test_method_data_pointer(Label& zero_continue, bool may_be_far = false);
   void verify_method_data_pointer();
 
   void set_mdp_data_at(int constant, Register value);
diff --git a/src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp b/src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp
index 29fb54250c2..7557709653a 100644
--- a/src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp
+++ b/src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp
@@ -1249,10 +1249,14 @@ void InterpreterMacroAssembler::set_method_data_pointer_for_bcp() {
 }
 
 // Test ImethodDataPtr. If it is null, continue at the specified label.
-void InterpreterMacroAssembler::test_method_data_pointer(Label& zero_continue) {
+void InterpreterMacroAssembler::test_method_data_pointer(Label& zero_continue, bool may_be_far) {
   assert(ProfileInterpreter, "must be profiling interpreter");
   cmpdi(CR0, R28_mdx, 0);
-  beq(CR0, zero_continue);
+  if (may_be_far) {
+    bc_far_optimized(Assembler::bcondCRbiIs1, bi0(CR0, Assembler::equal), zero_continue);
+  } else {
+    beq(CR0, zero_continue);
+  }
 }
 
 void InterpreterMacroAssembler::verify_method_data_pointer() {
@@ -1555,7 +1559,7 @@ void InterpreterMacroAssembler::profile_ret(TosState state, Register return_bci,
     uint row;
 
     // If no method data exists, go to profile_continue.
-    test_method_data_pointer(profile_continue);
+    test_method_data_pointer(profile_continue, true);
 
     // Update the total ret count.
     increment_mdp_data_at(in_bytes(CounterData::count_offset()), scratch1, scratch2 );

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

PR Comment: https://git.openjdk.org/jdk/pull/26139#issuecomment-3200895865

From duke at openjdk.org  Tue Aug 19 14:30:48 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Tue, 19 Aug 2025 14:30:48 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v10]
In-Reply-To: <iltLcUikaazrinRRYqwwtpi3BPf7MCqWrZALolhvK3c=.844faca7-d83f-48ac-8c4b-aedc6847f23e@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <Arayu_lQJTrqeOoW6nApckf17U1CtqswWgNJIhRKeas=.d121db1b-6cc3-4219-9624-0b57a8f62a4b@github.com>
 <iltLcUikaazrinRRYqwwtpi3BPf7MCqWrZALolhvK3c=.844faca7-d83f-48ac-8c4b-aedc6847f23e@github.com>
Message-ID: <aMA_1F_MvwYqJ0MlI2N_aA1eRoVbaPoL05vpsfepu0Y=.3eca8d52-427d-4c1c-a1ea-b74d245ef242@github.com>

On Tue, 19 Aug 2025 11:18:48 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unused
>
> src/hotspot/share/gc/shared/collectedHeap.cpp line 625:
> 
>> 623:       ClassLoaderDataGraph::print_on(&ls_trace);
>> 624:     }
>> 625:   }
> 
> I don't think this code movement should be done -- this calls back to `Universe` and CLDG printing is not necessarily tired to heap.

The motivation to move into `CollectedHeap::before_exit` is that now we finally have a specific method that is called for GC activites during exit so there is no need to conflate java.cpp with these tasks.

> this calls back to Universe

It called back to Universe in java.cpp too. Maybe you would want `Universe::print_on` to be refactored into CollectedHeap too? If that's the case maybe we should save that for a separate issue.

 > CLDG printing is not necessarily tired to heap

That could be so, but it is put under `gc+exit` tag. Are you suggesting that we should break this apart and do it under another tag?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2285459470

From duke at openjdk.org  Tue Aug 19 14:48:43 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Tue, 19 Aug 2025 14:48:43 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v10]
In-Reply-To: <iltLcUikaazrinRRYqwwtpi3BPf7MCqWrZALolhvK3c=.844faca7-d83f-48ac-8c4b-aedc6847f23e@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <Arayu_lQJTrqeOoW6nApckf17U1CtqswWgNJIhRKeas=.d121db1b-6cc3-4219-9624-0b57a8f62a4b@github.com>
 <iltLcUikaazrinRRYqwwtpi3BPf7MCqWrZALolhvK3c=.844faca7-d83f-48ac-8c4b-aedc6847f23e@github.com>
Message-ID: <zZFaZy5nR-c_JfPOsuc6TBr4rNamvrjzfh9BRqyRjWI=.95005257-a9b6-403b-a94f-03ba5a8d70c2@github.com>

On Tue, 19 Aug 2025 11:27:53 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unused
>
> src/hotspot/share/services/cpuTimeUsage.hpp line 47:
> 
>> 45:     static jlong gc_threads();
>> 46:     static jlong vm_thread();
>> 47:     static jlong stringdedup();
> 
> I feel the API surface contains some redundancy.
> 
> For example, the GC-part API design exposes two ways to query and they are essentially the same -- for the sake of simplicity, I'd suggest keeping only one.
> 
> The calculation of `total` should be done by users of this API, I believe, when/if total is desirable.

The motivation for `total()` is that this is probably what most users want, but in case anyone want a sub-component I also expose each one of them. It also serves as documentation as what we currently consider to be "total", so I would prefer keeping it.

If you look at e.g. `WeakProcessor::CountingClosure`  the following is defined

  size_t dead() const { return _old_dead + _new_dead; }
  size_t new_dead() const { return _new_dead; }
  size_t total() const { return dead() + _live; }


so having such convenience method in hotspot is not unprecedented and I would prefer keeping it.

`statistics()` is a less important convenience method that can be removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2285510749

From ayang at openjdk.org  Tue Aug 19 15:03:42 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 19 Aug 2025 15:03:42 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v10]
In-Reply-To: <aMA_1F_MvwYqJ0MlI2N_aA1eRoVbaPoL05vpsfepu0Y=.3eca8d52-427d-4c1c-a1ea-b74d245ef242@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <Arayu_lQJTrqeOoW6nApckf17U1CtqswWgNJIhRKeas=.d121db1b-6cc3-4219-9624-0b57a8f62a4b@github.com>
 <iltLcUikaazrinRRYqwwtpi3BPf7MCqWrZALolhvK3c=.844faca7-d83f-48ac-8c4b-aedc6847f23e@github.com>
 <aMA_1F_MvwYqJ0MlI2N_aA1eRoVbaPoL05vpsfepu0Y=.3eca8d52-427d-4c1c-a1ea-b74d245ef242@github.com>
Message-ID: <wwupv4RWf2yaUTMM90m7ZSh5xOHDDt2skF01XSF8eJY=.9c6fc814-fcbc-4a69-8b2d-36c12c443fda@github.com>

On Tue, 19 Aug 2025 14:27:59 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> now we finally have a specific method that is called for GC activites...

Then, it should be in `Universe::before_exit`, not inside heap.

>> src/hotspot/share/services/cpuTimeUsage.hpp line 47:
>> 
>>> 45:     static jlong gc_threads();
>>> 46:     static jlong vm_thread();
>>> 47:     static jlong stringdedup();
>> 
>> I feel the API surface contains some redundancy.
>> 
>> For example, the GC-part API design exposes two ways to query and they are essentially the same -- for the sake of simplicity, I'd suggest keeping only one.
>> 
>> The calculation of `total` should be done by users of this API, I believe, when/if total is desirable.
>
> The motivation for `total()` is that this is probably what most users want, but in case anyone want a sub-component I also expose each one of them. It also serves as documentation as what we currently consider to be "total", so I would prefer keeping it.
> 
> If you look at e.g. `WeakProcessor::CountingClosure`  the following is defined
> 
>   size_t dead() const { return _old_dead + _new_dead; }
>   size_t new_dead() const { return _new_dead; }
>   size_t total() const { return dead() + _live; }
> 
> 
> so having such convenience method in hotspot is not unprecedented and I would prefer keeping it.
> 
> `statistics()` is a less important convenience method that can be removed.

I think the smallest API would be `statisics()`, which returns all sub-components, and consumers of this API can calculate other derived metrics. YMMV.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2285544932
PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2285551132

From duke at openjdk.org  Tue Aug 19 15:56:39 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Tue, 19 Aug 2025 15:56:39 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v10]
In-Reply-To: <wwupv4RWf2yaUTMM90m7ZSh5xOHDDt2skF01XSF8eJY=.9c6fc814-fcbc-4a69-8b2d-36c12c443fda@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <Arayu_lQJTrqeOoW6nApckf17U1CtqswWgNJIhRKeas=.d121db1b-6cc3-4219-9624-0b57a8f62a4b@github.com>
 <iltLcUikaazrinRRYqwwtpi3BPf7MCqWrZALolhvK3c=.844faca7-d83f-48ac-8c4b-aedc6847f23e@github.com>
 <aMA_1F_MvwYqJ0MlI2N_aA1eRoVbaPoL05vpsfepu0Y=.3eca8d52-427d-4c1c-a1ea-b74d245ef242@github.com>
 <wwupv4RWf2yaUTMM90m7ZSh5xOHDDt2skF01XSF8eJY=.9c6fc814-fcbc-4a69-8b2d-36c12c443fda@github.com>
Message-ID: <wUV5vCNB3AOoOV4xFD0k5dQihit6CHIETo9shtx96YE=.41b4a400-6f4f-4f62-bdbb-a2c88c792328@github.com>

On Tue, 19 Aug 2025 14:57:51 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> The motivation to move into `CollectedHeap::before_exit` is that now we finally have a specific method that is called for GC activites during exit so there is no need to conflate java.cpp with these tasks.
>> 
>>> this calls back to Universe
>> 
>> It called back to Universe in java.cpp too. Maybe you would want `Universe::print_on` to be refactored into CollectedHeap too? If that's the case maybe we should save that for a separate issue.
>> 
>>  > CLDG printing is not necessarily tired to heap
>> 
>> That could be so, but it is put under `gc+exit` tag. Are you suggesting that we should break this apart and do it under another tag?
>
>> now we finally have a specific method that is called for GC activites...
> 
> Then, it should be in `Universe::before_exit`, not inside heap.

FWIW; `Universe::print_on` do actually call collected heap as well.


void Universe::print_on(outputStream* st) {
  GCMutexLocker hl(Heap_lock); // Heap_lock might be locked by caller thread.
  st->print_cr("Heap");

  StreamIndentor si(st, 1);
  heap()->print_heap_on(st);
  MetaspaceUtils::print_on(st);
}


I would be OK with moving it to `Universe::before_exit` and I can see the argument that the log message is conflated with components that are not strictly GC. That being said, I think it would also make sense from a code perspective to put it under GC as the log tag is defined to be GC. The best solution would probably be to redefine the log tags and break the block apart, but that would be out-of-scope for this PR. I'll wait for @kstefanj input before proceeding.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2285690897

From duke at openjdk.org  Tue Aug 19 16:03:42 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Tue, 19 Aug 2025 16:03:42 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v10]
In-Reply-To: <wwupv4RWf2yaUTMM90m7ZSh5xOHDDt2skF01XSF8eJY=.9c6fc814-fcbc-4a69-8b2d-36c12c443fda@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <Arayu_lQJTrqeOoW6nApckf17U1CtqswWgNJIhRKeas=.d121db1b-6cc3-4219-9624-0b57a8f62a4b@github.com>
 <iltLcUikaazrinRRYqwwtpi3BPf7MCqWrZALolhvK3c=.844faca7-d83f-48ac-8c4b-aedc6847f23e@github.com>
 <aMA_1F_MvwYqJ0MlI2N_aA1eRoVbaPoL05vpsfepu0Y=.3eca8d52-427d-4c1c-a1ea-b74d245ef242@github.com>
 <wwupv4RWf2yaUTMM90m7ZSh5xOHDDt2skF01XSF8eJY=.9c6fc814-fcbc-4a69-8b2d-36c12c443fda@github.com>
Message-ID: <2wSybZnJX_B_94UbbiPj_gMeKGqoFeyhXk8AAtiM9lQ=.6ae7d021-fd81-425d-b47a-bf767ad7b4dd@github.com>

On Tue, 19 Aug 2025 15:00:15 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> The motivation for `total()` is that this is probably what most users want, but in case anyone want a sub-component I also expose each one of them. It also serves as documentation as what we currently consider to be "total", so I would prefer keeping it.
>> 
>> If you look at e.g. `WeakProcessor::CountingClosure`  the following is defined
>> 
>>   size_t dead() const { return _old_dead + _new_dead; }
>>   size_t new_dead() const { return _new_dead; }
>>   size_t total() const { return dead() + _live; }
>> 
>> 
>> so having such convenience method in hotspot is not unprecedented and I would prefer keeping it.
>> 
>> `statistics()` is a less important convenience method that can be removed.
>
> I think the smallest API would be `statisics()`, which returns all sub-components, and consumers of this API can calculate other derived metrics. YMMV.

I would remove `CPUTimeUsage::GC::statistics()` as I would prefer having coherent types between classes in the namespace and since using structs over of classes defeats some of the utility of putting everything into a namespace.

For instance, it makes little sense to define a struct for `Runtime` which only include one component currently and it would be less than ideal to return `jlong` for some classes and custom structs for others if we only have to pick one of these approaches.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2285707652

From dholmes at openjdk.org  Tue Aug 19 20:43:38 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 19 Aug 2025 20:43:38 GMT
Subject: RFR: 8358748: Large page size initialization fails with assert
 "page_size must be a power of 2" [v4]
In-Reply-To: <0sNSlwoh94xjIpd-z7WS2dp4bplQ27RJtawI5rR3G0M=.6d29b3ac-5580-42c2-ae54-bba6f00a9090@github.com>
References: <Hz4zDgclbM7HtZP8VHh3yQBPlYXYgGoxwkKwSS50r9E=.634dd3a2-fd10-45e5-85fb-9f038d5ebd9c@github.com>
 <0sNSlwoh94xjIpd-z7WS2dp4bplQ27RJtawI5rR3G0M=.6d29b3ac-5580-42c2-ae54-bba6f00a9090@github.com>
Message-ID: <e_rLJFcp4jDKO9OQIYRAtIn7ru3xZEz5AdX4TbrBYso=.575db331-cfa5-4053-8335-1b62bfd438e1@github.com>

On Tue, 19 Aug 2025 11:27:51 GMT, Yagmur Eren <duke at openjdk.org> wrote:

>> The VM now exits gracefully if `-XX:LargePageSizeInBytes` is set to a non power of two value, instead of asserting. After this change, `SizeTTest.java` failed because the tested values are not valid for `-XX:LargePageSizeInBytes` (`LargePageSizeInBytesConstraintFunc` returns `JVMFlag::VIOLATES_CONSTRAINT`). Therefore, I updated the test to use `NUMASpaceResizeRate`, since I believe that it only requires a flag of type `size_t`.
>> 
>> Before the change:
>> 
>> java -XX:+UseLargePages -XX:LargePageSizeInBytes=6 -version
>> 
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> # Internal Error (workspace/open/src/hotspot/share/runtime/os.cpp:2449), pid=1885945, tid=1885946
>> # assert(is_power_of_2(page_size)) failed: page_size must be a power of 2: 0x6
>> 
>> 
>> 
>> After the change:
>> 
>> java -XX:+UseLargePages -XX:LargePageSizeInBytes=6 -version
>> 
>> LargePageSizeInBytes ( 6 ) must be a power of 2
>> Improperly specified VM option 'LargePageSizeInBytes=6'
>> Error: Could not create the Java Virtual Machine.
>> Error: A fatal exception has occurred. Program will exit.
>
> Yagmur Eren has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change the flag in sizet test

Looks fine. Thnaks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25994#pullrequestreview-3133763372

From dholmes at openjdk.org  Wed Aug 20 02:09:36 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 20 Aug 2025 02:09:36 GMT
Subject: RFR: 8364352: Some tests fail when using a limited number of
 pregenerated .jsa CDS archives
In-Reply-To: <EnyzXiapmd29T3spHQT7QTBv2SVQVKVU6L2NEDoejHg=.65f803f7-09e0-4e5b-ac21-a60474c5facd@github.com>
References: <EnyzXiapmd29T3spHQT7QTBv2SVQVKVU6L2NEDoejHg=.65f803f7-09e0-4e5b-ac21-a60474c5facd@github.com>
Message-ID: <94-rbdkR3HFSuIiaXMgE9E-GWOQwgWgDz4xWDcYQPMk=.0841b935-819f-497a-81f9-cf5f6da9acf0@github.com>

On Mon, 18 Aug 2025 11:34:28 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently the default JVM comes on most platforms with 4 jsa files (for coops and nocoops; with and without compressed object headers), but for some shipments the number of jsa could be reduced (see also Images.gmk) .
> But not all tests can deal with this.
> Namely
> 
> test/hotspot/jtreg/runtime/CompressedOops/CompressedCPUSpecificClassSpaceReservation.java
> test/hotspot/jtreg/runtime/cds/TestDefaultArchiveLoading.java
> test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java (custom-cl-zgc)
> 
> were found to have issues.
> There is already a requires  `vm.cds.default.archive.available`   that is used in similar tests and can be used in some of those cases too.

test/hotspot/jtreg/runtime/CompressedOops/CompressedCPUSpecificClassSpaceReservation.java line 31:

> 29:  * @requires vm.flagless
> 30:  * @requires vm.cds
> 31:  * @requires vm.cds.default.archive.available

Does the notion of "default.archive" change depending on whether the VM is executing in COOPs/NoCOOPS or COH/NoCOH modes?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26820#discussion_r2286806425

From dholmes at openjdk.org  Wed Aug 20 02:35:38 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 20 Aug 2025 02:35:38 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v10]
In-Reply-To: <Arayu_lQJTrqeOoW6nApckf17U1CtqswWgNJIhRKeas=.d121db1b-6cc3-4219-9624-0b57a8f62a4b@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <Arayu_lQJTrqeOoW6nApckf17U1CtqswWgNJIhRKeas=.d121db1b-6cc3-4219-9624-0b57a8f62a4b@github.com>
Message-ID: <ZoYzKkxnDLWtS1fQgbDmqSP9Ar1BI6J5XXEmLk4fpew=.e1ebcb5c-ad21-4010-9e3d-27eaca630f58@github.com>

On Tue, 19 Aug 2025 08:42:15 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110).
>> 
>> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports:
>> 
>> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup()
>> 
>> CPUTimeUsage::GC::gc_threads()
>> CPUTimeUsage::GC::vm_thread()
>> CPUTimeUsage::GC::stringdedup()
>> 
>> CPUTimeUsage::Runtime::vm_thread()
>> 
>> 
>> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC.
>> 
>> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table:
>> 
>> 
>> [71.425s][info][cpu   ] === CPU time Statistics =============================================================
>> [71.425s][info][cpu   ]                                                                             CPUs
>> [71.425s][info][cpu   ]                                                                s       %  utilized
>> [71.425s][info][cpu   ]    Process
>> [71.425s][info][cpu   ]      Total                                             1616.3627  100.00      22.6
>> [71.425s][info][cpu   ]      VM Thread                                            5.2992    0.33       0.1
>> [71.425s][info][cpu   ]      Garbage Collection                                  83.7322    5.18       1.2
>> [71.425s][info][cpu   ]        GC Threads                                        82.7671    5.12       1.2
>> [71.425s][info][cpu   ]        VM Thread                                          0.9651    0.06       0.0
>> [71.425s][info][cpu   ] =====================================================================================
>> 
>> 
>> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused

I'll leave it to the GC folk to approve, but the shared code changes look good to me.

Thanks

src/hotspot/share/services/cpuTimeUsage.cpp line 2:

> 1: /*
> 2:  * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.

When refactoring code into a new file, the first copyright year for the new file should be the earliest copyright year of the substantial code/content in that file?not the year the new file is created.

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

PR Review: https://git.openjdk.org/jdk/pull/26621#pullrequestreview-3134573286
PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2286823424

From iklam at openjdk.org  Wed Aug 20 04:07:31 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 20 Aug 2025 04:07:31 GMT
Subject: RFR: 8365814: Consolidate has_been_archived() and has_been_buffered()
 in ArchiveBuilder
Message-ID: <CjcbzPgOlwDABX6nFwnR4TgkD-FcK8VSXZuz5tsSNJE=.ee6b4d03-9855-4bbd-9031-4a657dda358e@github.com>

Merged the two methods into one: `ArchiveBuilder::has_been_archived()`. Added comments and asserts to explain what the expected result is.

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

Commit messages:
 - 8365814: Consolidate has_been_archived() and has_been_buffered() in ArchiveBuilder

Changes: https://git.openjdk.org/jdk/pull/26853/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26853&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365814
  Stats: 36 lines in 4 files changed: 20 ins; 10 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/26853.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26853/head:pull/26853

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

From stuefe at openjdk.org  Wed Aug 20 04:44:36 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 20 Aug 2025 04:44:36 GMT
Subject: RFR: 8364352: Some tests fail when using a limited number of
 pregenerated .jsa CDS archives
In-Reply-To: <EnyzXiapmd29T3spHQT7QTBv2SVQVKVU6L2NEDoejHg=.65f803f7-09e0-4e5b-ac21-a60474c5facd@github.com>
References: <EnyzXiapmd29T3spHQT7QTBv2SVQVKVU6L2NEDoejHg=.65f803f7-09e0-4e5b-ac21-a60474c5facd@github.com>
Message-ID: <smmoOTZk7uLBXYP3dk04VWJVxYbpYmP6BDzpLtqTImQ=.40f126d5-dc02-4591-8e9e-122b3005c904@github.com>

On Mon, 18 Aug 2025 11:34:28 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently the default JVM comes on most platforms with 4 jsa files (for coops and nocoops; with and without compressed object headers), but for some shipments the number of jsa could be reduced (see also Images.gmk) .
> But not all tests can deal with this.
> Namely
> 
> test/hotspot/jtreg/runtime/CompressedOops/CompressedCPUSpecificClassSpaceReservation.java
> test/hotspot/jtreg/runtime/cds/TestDefaultArchiveLoading.java
> test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java (custom-cl-zgc)
> 
> were found to have issues.
> There is already a requires  `vm.cds.default.archive.available`   that is used in similar tests and can be used in some of those cases too.

Makes sense.

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26820#pullrequestreview-3134758490

From kvn at openjdk.org  Wed Aug 20 04:55:39 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 20 Aug 2025 04:55:39 GMT
Subject: RFR: 8365814: Consolidate has_been_archived() and
 has_been_buffered() in ArchiveBuilder
In-Reply-To: <CjcbzPgOlwDABX6nFwnR4TgkD-FcK8VSXZuz5tsSNJE=.ee6b4d03-9855-4bbd-9031-4a657dda358e@github.com>
References: <CjcbzPgOlwDABX6nFwnR4TgkD-FcK8VSXZuz5tsSNJE=.ee6b4d03-9855-4bbd-9031-4a657dda358e@github.com>
Message-ID: <1Ywg41frWZfBAQQr_zfnCLaBBg7dhTXgmKxALdFQGWc=.89e7d609-3eea-44d5-a881-943639659c1d@github.com>

On Wed, 20 Aug 2025 04:01:13 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Merged the two methods into one: `ArchiveBuilder::has_been_archived()`. Added comments and asserts to explain what the expected result is.

Good.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26853#pullrequestreview-3134774396

From duke at openjdk.org  Wed Aug 20 07:06:38 2025
From: duke at openjdk.org (Yagmur Eren)
Date: Wed, 20 Aug 2025 07:06:38 GMT
Subject: RFR: 8358748: Large page size initialization fails with assert
 "page_size must be a power of 2" [v4]
In-Reply-To: <0sNSlwoh94xjIpd-z7WS2dp4bplQ27RJtawI5rR3G0M=.6d29b3ac-5580-42c2-ae54-bba6f00a9090@github.com>
References: <Hz4zDgclbM7HtZP8VHh3yQBPlYXYgGoxwkKwSS50r9E=.634dd3a2-fd10-45e5-85fb-9f038d5ebd9c@github.com>
 <0sNSlwoh94xjIpd-z7WS2dp4bplQ27RJtawI5rR3G0M=.6d29b3ac-5580-42c2-ae54-bba6f00a9090@github.com>
Message-ID: <mkaTR0G9VgO71mX9MXi3D_5SAeRy6YuIHOiOpSffxZU=.63a18fb7-ee4e-4512-98c8-052fc7a21770@github.com>

On Tue, 19 Aug 2025 11:27:51 GMT, Yagmur Eren <duke at openjdk.org> wrote:

>> The VM now exits gracefully if `-XX:LargePageSizeInBytes` is set to a non power of two value, instead of asserting. After this change, `SizeTTest.java` failed because the tested values are not valid for `-XX:LargePageSizeInBytes` (`LargePageSizeInBytesConstraintFunc` returns `JVMFlag::VIOLATES_CONSTRAINT`). Therefore, I updated the test to use `NUMASpaceResizeRate`, since I believe that it only requires a flag of type `size_t`.
>> 
>> Before the change:
>> 
>> java -XX:+UseLargePages -XX:LargePageSizeInBytes=6 -version
>> 
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> # Internal Error (workspace/open/src/hotspot/share/runtime/os.cpp:2449), pid=1885945, tid=1885946
>> # assert(is_power_of_2(page_size)) failed: page_size must be a power of 2: 0x6
>> 
>> 
>> 
>> After the change:
>> 
>> java -XX:+UseLargePages -XX:LargePageSizeInBytes=6 -version
>> 
>> LargePageSizeInBytes ( 6 ) must be a power of 2
>> Improperly specified VM option 'LargePageSizeInBytes=6'
>> Error: Could not create the Java Virtual Machine.
>> Error: A fatal exception has occurred. Program will exit.
>
> Yagmur Eren has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change the flag in sizet test

Thanks a lot for the reviews! Can I also get a sponsor?

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

PR Comment: https://git.openjdk.org/jdk/pull/25994#issuecomment-3204462512

From duke at openjdk.org  Wed Aug 20 07:06:39 2025
From: duke at openjdk.org (duke)
Date: Wed, 20 Aug 2025 07:06:39 GMT
Subject: RFR: 8358748: Large page size initialization fails with assert
 "page_size must be a power of 2" [v4]
In-Reply-To: <0sNSlwoh94xjIpd-z7WS2dp4bplQ27RJtawI5rR3G0M=.6d29b3ac-5580-42c2-ae54-bba6f00a9090@github.com>
References: <Hz4zDgclbM7HtZP8VHh3yQBPlYXYgGoxwkKwSS50r9E=.634dd3a2-fd10-45e5-85fb-9f038d5ebd9c@github.com>
 <0sNSlwoh94xjIpd-z7WS2dp4bplQ27RJtawI5rR3G0M=.6d29b3ac-5580-42c2-ae54-bba6f00a9090@github.com>
Message-ID: <HhL6LIvCRVcsSTFuw4vlrUwRU3Cudm07BweNOeNSAEc=.cef6e8e9-566a-4a76-8243-c821dcbb6854@github.com>

On Tue, 19 Aug 2025 11:27:51 GMT, Yagmur Eren <duke at openjdk.org> wrote:

>> The VM now exits gracefully if `-XX:LargePageSizeInBytes` is set to a non power of two value, instead of asserting. After this change, `SizeTTest.java` failed because the tested values are not valid for `-XX:LargePageSizeInBytes` (`LargePageSizeInBytesConstraintFunc` returns `JVMFlag::VIOLATES_CONSTRAINT`). Therefore, I updated the test to use `NUMASpaceResizeRate`, since I believe that it only requires a flag of type `size_t`.
>> 
>> Before the change:
>> 
>> java -XX:+UseLargePages -XX:LargePageSizeInBytes=6 -version
>> 
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> # Internal Error (workspace/open/src/hotspot/share/runtime/os.cpp:2449), pid=1885945, tid=1885946
>> # assert(is_power_of_2(page_size)) failed: page_size must be a power of 2: 0x6
>> 
>> 
>> 
>> After the change:
>> 
>> java -XX:+UseLargePages -XX:LargePageSizeInBytes=6 -version
>> 
>> LargePageSizeInBytes ( 6 ) must be a power of 2
>> Improperly specified VM option 'LargePageSizeInBytes=6'
>> Error: Could not create the Java Virtual Machine.
>> Error: A fatal exception has occurred. Program will exit.
>
> Yagmur Eren has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change the flag in sizet test

@nelanbu 
Your change (at version 6dfa4a2990db66c49179b10dbbcdb03824b4a674) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/25994#issuecomment-3204468465

From jsjolen at openjdk.org  Wed Aug 20 07:10:43 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 20 Aug 2025 07:10:43 GMT
Subject: RFR: 8342730: Get rid of SummaryDiff in VMATree
In-Reply-To: <JShctGmb3UHnG21I3UAOCLu8b9KoGs8u9yO5iw_sUwc=.e0a33104-011f-47b0-bac4-59d18853c4c8@github.com>
References: <JShctGmb3UHnG21I3UAOCLu8b9KoGs8u9yO5iw_sUwc=.e0a33104-011f-47b0-bac4-59d18853c4c8@github.com>
Message-ID: <XGflyAH1aTBtwNm8DKBd-FPIxfWgdfjYjEKgbCVSAcA=.c96fbba2-d815-4e5e-bdf6-45da82d564bc@github.com>

On Wed, 13 Aug 2025 13:33:36 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> `SummaryDiff` result of any `register_mapping()` call, is passed into the function rather than returned. This enables avoiding copying the structure to/from the stack.
> 
> Tests:
> local linux-x64-debug: NMT gtests and JTREGs passed.

Thanks!

LGTM

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

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26761#pullrequestreview-3135084602

From jsjolen at openjdk.org  Wed Aug 20 07:11:41 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 20 Aug 2025 07:11:41 GMT
Subject: RFR: 8353444: NMT: rename 'category' to 'MemTag' in malloc tracker
 [v6]
In-Reply-To: <hoC7W0ro6JyIZEHlGdF3mApAo0-BKlM53p5O2Qhd75g=.5ccb1b9a-9296-46e3-9f40-01f77d3741c3@github.com>
References: <mVv-IomtzU25S1Xv1kQAy0gkUYPmuOLFDc-bJskDTaY=.c434ab86-536f-4e22-9dfa-64a00274c06b@github.com>
 <hoC7W0ro6JyIZEHlGdF3mApAo0-BKlM53p5O2Qhd75g=.5ccb1b9a-9296-46e3-9f40-01f77d3741c3@github.com>
Message-ID: <RnOaRXsJ_tBITiDaKnRosrrWg0aUDi-ZkOlw3jrHol0=.299bb673-f418-4716-9ed9-8ed1632bde88@github.com>

On Wed, 13 Aug 2025 11:19:58 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> Renamed usage of 'category' for 'MemTag' cases.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reverted some renamings

LGTM

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

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25226#pullrequestreview-3135086880

From mbaesken at openjdk.org  Wed Aug 20 07:17:43 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 20 Aug 2025 07:17:43 GMT
Subject: RFR: 8364352: Some tests fail when using a limited number of
 pregenerated .jsa CDS archives
In-Reply-To: <94-rbdkR3HFSuIiaXMgE9E-GWOQwgWgDz4xWDcYQPMk=.0841b935-819f-497a-81f9-cf5f6da9acf0@github.com>
References: <EnyzXiapmd29T3spHQT7QTBv2SVQVKVU6L2NEDoejHg=.65f803f7-09e0-4e5b-ac21-a60474c5facd@github.com>
 <94-rbdkR3HFSuIiaXMgE9E-GWOQwgWgDz4xWDcYQPMk=.0841b935-819f-497a-81f9-cf5f6da9acf0@github.com>
Message-ID: <9_SqooheFxiPUHUPh6CGpr_zmTMAEuPC8ttLrBIaRP8=.28ded786-d5a6-44fe-9479-7b648415a512@github.com>

On Wed, 20 Aug 2025 02:06:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Currently the default JVM comes on most platforms with 4 jsa files (for coops and nocoops; with and without compressed object headers), but for some shipments the number of jsa could be reduced (see also Images.gmk) .
>> But not all tests can deal with this.
>> Namely
>> 
>> test/hotspot/jtreg/runtime/CompressedOops/CompressedCPUSpecificClassSpaceReservation.java
>> test/hotspot/jtreg/runtime/cds/TestDefaultArchiveLoading.java
>> test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java (custom-cl-zgc)
>> 
>> were found to have issues.
>> There is already a requires  `vm.cds.default.archive.available`   that is used in similar tests and can be used in some of those cases too.
>
> test/hotspot/jtreg/runtime/CompressedOops/CompressedCPUSpecificClassSpaceReservation.java line 31:
> 
>> 29:  * @requires vm.flagless
>> 30:  * @requires vm.cds
>> 31:  * @requires vm.cds.default.archive.available
> 
> Does the notion of "default.archive" change depending on whether the VM is executing in COOPs/NoCOOPS or COH/NoCOH modes?

That's the coding 

https://github.com/openjdk/jdk/blob/320235ccb88b4b554cd5756b7e6a34ce97aabd53/test/jtreg-ext/requires/VMProps.java#L438

So it ALWAYS looks at classes,jsa .

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26820#discussion_r2287215741

From duke at openjdk.org  Wed Aug 20 07:19:48 2025
From: duke at openjdk.org (Yagmur Eren)
Date: Wed, 20 Aug 2025 07:19:48 GMT
Subject: Integrated: 8358748: Large page size initialization fails with assert
 "page_size must be a power of 2"
In-Reply-To: <Hz4zDgclbM7HtZP8VHh3yQBPlYXYgGoxwkKwSS50r9E=.634dd3a2-fd10-45e5-85fb-9f038d5ebd9c@github.com>
References: <Hz4zDgclbM7HtZP8VHh3yQBPlYXYgGoxwkKwSS50r9E=.634dd3a2-fd10-45e5-85fb-9f038d5ebd9c@github.com>
Message-ID: <0nlu83xgNw-lGAc4QUMr8WRKz5P4D34a36X3KTZp_9g=.d2475ef1-a198-4abc-9fae-1a1b0c12dc1e@github.com>

On Thu, 26 Jun 2025 07:48:43 GMT, Yagmur Eren <duke at openjdk.org> wrote:

> The VM now exits gracefully if `-XX:LargePageSizeInBytes` is set to a non power of two value, instead of asserting. After this change, `SizeTTest.java` failed because the tested values are not valid for `-XX:LargePageSizeInBytes` (`LargePageSizeInBytesConstraintFunc` returns `JVMFlag::VIOLATES_CONSTRAINT`). Therefore, I updated the test to use `NUMASpaceResizeRate`, since I believe that it only requires a flag of type `size_t`.
> 
> Before the change:
> 
> java -XX:+UseLargePages -XX:LargePageSizeInBytes=6 -version
> 
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # Internal Error (workspace/open/src/hotspot/share/runtime/os.cpp:2449), pid=1885945, tid=1885946
> # assert(is_power_of_2(page_size)) failed: page_size must be a power of 2: 0x6
> 
> 
> 
> After the change:
> 
> java -XX:+UseLargePages -XX:LargePageSizeInBytes=6 -version
> 
> LargePageSizeInBytes ( 6 ) must be a power of 2
> Improperly specified VM option 'LargePageSizeInBytes=6'
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.

This pull request has now been integrated.

Changeset: 40bc0832
Author:    Yagmur Eren <yagmur.eren at oracle.com>
Committer: Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/40bc083267c0bac64b1092c63325b8d245937b0e
Stats:     16 lines in 4 files changed: 13 ins; 0 del; 3 mod

8358748: Large page size initialization fails with assert "page_size must be a power of 2"

Reviewed-by: ayang, dholmes

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

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

From dholmes at openjdk.org  Wed Aug 20 08:15:50 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 20 Aug 2025 08:15:50 GMT
Subject: RFR: 8365556: ObjectMonitor::try_lock_or_add_to_entry_list()
 returns true with the wrong state of the node [v2]
In-Reply-To: <QLgZ6cuvFwxw4XyzNpGDNrtRQ-F9q7use9MitZrmtOw=.79c74b19-99fd-45d9-8309-68dc15cbf13d@github.com>
References: <YUOnpPZ57q-9oW7npgsONxWYI6K-FdUtvmSNzIO7w1Q=.06f70f3d-17e7-4583-9890-fe52d7a7af13@github.com>
 <QLgZ6cuvFwxw4XyzNpGDNrtRQ-F9q7use9MitZrmtOw=.79c74b19-99fd-45d9-8309-68dc15cbf13d@github.com>
Message-ID: <VeIhtU7KP64gM6kBefbpuPy_Fp4M2kyF5O7KNVeYSGE=.a56fd5af-b4a8-489e-990d-25d27d977a70@github.com>

On Tue, 19 Aug 2025 08:35:51 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi, please consider the following change:
>> 
>> `ObjectMonitor::try_lock_or_add_to_entry_list() `does not change the node state to `TS_RUN `in case of a successful acquisition of the object monitor. In certain cases this can break the guarantee statement in the `ObjectMonitor::wait()` method and lead to a crash. The missing statement is added.
>> 
>> Tested in tiers 1 - 5.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8365556: Added assert.

This fixes the issue at hand - thanks. I think any further changes should be done under seperate RFE's if wanted.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26794#pullrequestreview-3135331907

From duke at openjdk.org  Wed Aug 20 08:15:51 2025
From: duke at openjdk.org (Anton Artemov)
Date: Wed, 20 Aug 2025 08:15:51 GMT
Subject: Integrated: 8365556: ObjectMonitor::try_lock_or_add_to_entry_list()
 returns true with the wrong state of the node
In-Reply-To: <YUOnpPZ57q-9oW7npgsONxWYI6K-FdUtvmSNzIO7w1Q=.06f70f3d-17e7-4583-9890-fe52d7a7af13@github.com>
References: <YUOnpPZ57q-9oW7npgsONxWYI6K-FdUtvmSNzIO7w1Q=.06f70f3d-17e7-4583-9890-fe52d7a7af13@github.com>
Message-ID: <wfXbmynpIIOsStDB8JIEM0gzCNyTqu7FhtVUHE7Pn1s=.cae33b0b-cca6-4a77-b61f-4560fb4d7576@github.com>

On Fri, 15 Aug 2025 07:22:02 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following change:
> 
> `ObjectMonitor::try_lock_or_add_to_entry_list() `does not change the node state to `TS_RUN `in case of a successful acquisition of the object monitor. In certain cases this can break the guarantee statement in the `ObjectMonitor::wait()` method and lead to a crash. The missing statement is added.
> 
> Tested in tiers 1 - 5.

This pull request has now been integrated.

Changeset: 70f34693
Author:    Anton Artemov <anton.artemov at oracle.com>
Committer: David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/70f3469310f385c4953a9069ca99e0806bc6ef5b
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8365556: ObjectMonitor::try_lock_or_add_to_entry_list() returns true with the wrong state of the node

Reviewed-by: pchilanomate, dholmes, fbredberg

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

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

From sjohanss at openjdk.org  Wed Aug 20 08:17:43 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Wed, 20 Aug 2025 08:17:43 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v10]
In-Reply-To: <wUV5vCNB3AOoOV4xFD0k5dQihit6CHIETo9shtx96YE=.41b4a400-6f4f-4f62-bdbb-a2c88c792328@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <Arayu_lQJTrqeOoW6nApckf17U1CtqswWgNJIhRKeas=.d121db1b-6cc3-4219-9624-0b57a8f62a4b@github.com>
 <iltLcUikaazrinRRYqwwtpi3BPf7MCqWrZALolhvK3c=.844faca7-d83f-48ac-8c4b-aedc6847f23e@github.com>
 <aMA_1F_MvwYqJ0MlI2N_aA1eRoVbaPoL05vpsfepu0Y=.3eca8d52-427d-4c1c-a1ea-b74d245ef242@github.com>
 <wwupv4RWf2yaUTMM90m7ZSh5xOHDDt2skF01XSF8eJY=.9c6fc814-fcbc-4a69-8b2d-36c12c443fda@github.com>
 <wUV5vCNB3AOoOV4xFD0k5dQihit6CHIETo9shtx96YE=.41b4a400-6f4f-4f62-bdbb-a2c88c792328@github.com>
Message-ID: <XmOqCGscMAFtbqBS5IRsO625xeMAhhjU3jcy6ZMWPbk=.7aae9e83-4fc2-47bf-84a8-e4af27e2d1ef@github.com>

On Tue, 19 Aug 2025 15:54:29 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>>> now we finally have a specific method that is called for GC activites...
>> 
>> Then, it should be in `Universe::before_exit`, not inside heap.
>
> FWIW; `Universe::print_on` do actually call collected heap as well.
> 
> 
> void Universe::print_on(outputStream* st) {
>   GCMutexLocker hl(Heap_lock); // Heap_lock might be locked by caller thread.
>   st->print_cr("Heap");
> 
>   StreamIndentor si(st, 1);
>   heap()->print_heap_on(st);
>   MetaspaceUtils::print_on(st);
> }
> 
> 
> I would be OK with moving it to `Universe::before_exit` and I can see the argument that the log message is conflated with components that are not strictly GC. That being said, I think it would also make sense from a code perspective to put it under GC as the log tag is defined to be GC. The best solution would probably be to redefine the log tags and break the block apart, but that would be out-of-scope for this PR. I'll wait for @kstefanj input before proceeding.

I'm good with moving it to `Universe::before_exit` as well. Looks like a good fit now when it was added.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2287363859

From fbredberg at openjdk.org  Wed Aug 20 08:27:43 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 20 Aug 2025 08:27:43 GMT
Subject: RFR: 8365188: Remove LockingMode related code from s390
In-Reply-To: <xdOXPmKTkhBqJgMsl0kbtcuAtaHlLJevV7dM8fVecCY=.34afa6eb-bb0d-465b-bb25-2e6a6a052702@github.com>
References: <xdOXPmKTkhBqJgMsl0kbtcuAtaHlLJevV7dM8fVecCY=.34afa6eb-bb0d-465b-bb25-2e6a6a052702@github.com>
Message-ID: <gKNK0i7P9GEvs2N939wJiYuT-yI-l93E7KZc4fMi1F0=.d2c64224-c354-4cf0-94c3-c1c8f70585ea@github.com>

On Thu, 14 Aug 2025 08:58:16 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
> 
> This PR removes `LockingMode` related code from the **s390** platform.
> 
> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/26772#issuecomment-3204801100

From fbredberg at openjdk.org  Wed Aug 20 08:27:44 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 20 Aug 2025 08:27:44 GMT
Subject: Integrated: 8365188: Remove LockingMode related code from s390
In-Reply-To: <xdOXPmKTkhBqJgMsl0kbtcuAtaHlLJevV7dM8fVecCY=.34afa6eb-bb0d-465b-bb25-2e6a6a052702@github.com>
References: <xdOXPmKTkhBqJgMsl0kbtcuAtaHlLJevV7dM8fVecCY=.34afa6eb-bb0d-465b-bb25-2e6a6a052702@github.com>
Message-ID: <PVyOF2ZuZ0kc3zOxA3YJ2sMxmyKT6YxBm0iyALVzYQI=.ba45a607-86fa-442e-b26b-d4fbf775e834@github.com>

On Thu, 14 Aug 2025 08:58:16 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
> 
> This PR removes `LockingMode` related code from the **s390** platform.
> 
> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.

This pull request has now been integrated.

Changeset: 169d145e
Author:    Fredrik Bredberg <fbredberg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/169d145e997df4d7236635805c28b9215818432f
Stats:     498 lines in 7 files changed: 0 ins; 486 del; 12 mod

8365188: Remove LockingMode related code from s390

Reviewed-by: ayang, aboldtch, amitkumar

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

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

From aph at openjdk.org  Wed Aug 20 08:58:50 2025
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 20 Aug 2025 08:58:50 GMT
Subject: RFR: 8358696: Assert with extreme values for -XX:BciProfileWidth
 [v8]
In-Reply-To: <x48Qtjsnz7ccoI5LdqiDmB8kO8FwmDjSE3ItYbtB4v0=.c22c1404-5766-4c32-a73a-a331cbe50f6d@github.com>
References: <5TRVeAXUQi6quM-nDWEij_jk6M5K2Vk31RA-Yjd8F2M=.5b63da45-93c3-4251-9e2e-3c64b7953919@github.com>
 <x48Qtjsnz7ccoI5LdqiDmB8kO8FwmDjSE3ItYbtB4v0=.c22c1404-5766-4c32-a73a-a331cbe50f6d@github.com>
Message-ID: <1u3X9cabv-ybTzQXq7TAWha_8_97OBHH5-icvDiBqUk=.aba537c3-36bf-46d2-9d35-d755a29aca97@github.com>

On Wed, 13 Aug 2025 09:35:08 GMT, Saranya Natarajan <snatarajan at openjdk.org> wrote:

>> **Issue**
>> Extreme values for BciProfileWidth flag such as `java -XX:BciProfileWidth=-1 -version` and `java -XX:BciProfileWidth=100000 -version `results in assert failure `assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x0000772b63a7a3a0 <= 0x0000772b63b75159 <= 0x0000772b63b75158 `. This is observed in a x86 machine.
>> 
>> **Analysis** 
>>  On debugging the issue, I found that increasing the size of the interpreter using the `InterpreterCodeSize` variable in `src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp` prevented the above mentioned assert from failing for large values of BciProfileWidth.  
>> 
>> **Proposal** 
>> Considering the fact that larger BciProfileWidth results in slower profiling, I have proposed a range between 0 to 5000 to restrict the value for BciProfileWidth for x86 machines. This maximum value is based on modifying the `InterpreterCodeSize` variable in `src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp` using the smallest `InterpreterCodeSize` for all the architectures.  As for the lower bound, a value of -1 would be the same as 0, as this simply means  no  return bci's will be recorded in ret profile. 
>> 
>> **Issue in AArch64**
>> Additionally running the command `java -XX:BciProfileWidth= 10000 -version` (or larger values) results in a different failure  `assert(offset_ok_for_immed(offset(), size)) failed: must be, was: 32768, 3` on an AArch64 machine.This is an issue of maximum offset for `ldr/str` in AArch64 which can be fixed using `form_address`  as mentioned in [JDK-8342736](https://bugs.openjdk.org/browse/JDK-8342736). In my preliminary fix using `form_address` on AArch64 machine. I had to modify 3 `ldr` and 1 `str` instruction (in file `src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp` at line number 926, 983, and 997). With this fix  using `form_address`, `BciProfileWidth` works for maximum of 5000 after which it crashes with`assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x0000772b63a7a3a0 <= 0x0000772b63b75159 <= 0x0000772b63b75158 `.  Without this fix `BciProfileWidth` works for a maximum value of 1300.   Currently, I have suggested to restrict the upper bound on AArch64 to 1000 instead
  of fixing it with `form_address`. 
>> 
>> **Question to reviewers**
>> Do you think this is a reasonable fix ?  For AArch64 do you suggest fixing using `form_address` ? If yes, do I fix it under this PR or create another one ?
>> 
>> **Request to port maintainers**
>> @dafedafe suggested that we keep the upper boun...
>
> Saranya Natarajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   additions for  linux-riscv64

I don't think we want different limits in BciProfileWidth for AArch64 and x86. Please use `form_address` as necessary.

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

PR Comment: https://git.openjdk.org/jdk/pull/26139#issuecomment-3204917395

From duke at openjdk.org  Wed Aug 20 09:00:30 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Wed, 20 Aug 2025 09:00:30 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v11]
In-Reply-To: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
Message-ID: <UFXJrV71IKWGmnVANfYtYTgLJmRtnuN11dup9LHy_v8=.21b9e391-d8be-460c-87cb-c1fee94db422@github.com>

> Hi all,
> 
> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110).
> 
> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports:
> 
> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup()
> 
> CPUTimeUsage::GC::gc_threads()
> CPUTimeUsage::GC::vm_thread()
> CPUTimeUsage::GC::stringdedup()
> 
> CPUTimeUsage::Runtime::vm_thread()
> 
> 
> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC.
> 
> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table:
> 
> 
> [71.425s][info][cpu   ] === CPU time Statistics =============================================================
> [71.425s][info][cpu   ]                                                                             CPUs
> [71.425s][info][cpu   ]                                                                s       %  utilized
> [71.425s][info][cpu   ]    Process
> [71.425s][info][cpu   ]      Total                                             1616.3627  100.00      22.6
> [71.425s][info][cpu   ]      VM Thread                                            5.2992    0.33       0.1
> [71.425s][info][cpu   ]      Garbage Collection                                  83.7322    5.18       1.2
> [71.425s][info][cpu   ]        GC Threads                                        82.7671    5.12       1.2
> [71.425s][info][cpu   ]        VM Thread                                          0.9651    0.06       0.0
> [71.425s][info][cpu   ] =====================================================================================
> 
> 
> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path.

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

  Remove GCStatistics, add thread_cpu_time_or_zero, move GC/heap log to Universe::before_exit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26621/files
  - new: https://git.openjdk.org/jdk/pull/26621/files/79a3323a..f29d5af4

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

  Stats: 74 lines in 4 files changed: 22 ins; 45 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/26621.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26621/head:pull/26621

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

From fbredberg at openjdk.org  Wed Aug 20 09:05:09 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 20 Aug 2025 09:05:09 GMT
Subject: RFR: 8365146: Remove LockingMode related code from ppc64 [v3]
In-Reply-To: <mKtlz6j_OunSKwTrSfwVxcErf8oTsclqe65OSJxXvlw=.b958a3bc-0253-4efd-a9ff-03ac0418ba23@github.com>
References: <mKtlz6j_OunSKwTrSfwVxcErf8oTsclqe65OSJxXvlw=.b958a3bc-0253-4efd-a9ff-03ac0418ba23@github.com>
Message-ID: <ztFaCjEU6WEEUGFuZ6TvP57rwOQY9X4K64jJCXtOTI0=.d132f09c-c076-4ef2-8136-421be62d31d8@github.com>

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
> 
> This PR removes `LockingMode` related code from the **ppc64** platform.
> 
> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.

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

 - Merge branch 'master' into 8365146_remove_lockingmode_ppc64
 - Update after review
 - Merge branch 'master' into 8365146_remove_lockingmode_ppc64
 - 8365146: Remove LockingMode related code from ppc64

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26697/files
  - new: https://git.openjdk.org/jdk/pull/26697/files/e9c74f13..c396dcae

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

  Stats: 10407 lines in 339 files changed: 6619 ins; 2633 del; 1155 mod
  Patch: https://git.openjdk.org/jdk/pull/26697.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26697/head:pull/26697

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

From fbredberg at openjdk.org  Wed Aug 20 09:05:09 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 20 Aug 2025 09:05:09 GMT
Subject: RFR: 8365146: Remove LockingMode related code from ppc64 [v3]
In-Reply-To: <lDv87wwNxFTatW7iTcnUxngvPSEfFS8cfX8-xpEJ1nE=.b7d43f39-edd5-4c79-bd1f-c03988edfe0f@github.com>
References: <mKtlz6j_OunSKwTrSfwVxcErf8oTsclqe65OSJxXvlw=.b958a3bc-0253-4efd-a9ff-03ac0418ba23@github.com>
 <101mw24zKLsjXjexjOZKimofI_yySxPw3gGyJq9HT1s=.495f1653-86ec-4d90-82d6-091b90d592f6@github.com>
 <lDv87wwNxFTatW7iTcnUxngvPSEfFS8cfX8-xpEJ1nE=.b7d43f39-edd5-4c79-bd1f-c03988edfe0f@github.com>
Message-ID: <MFGzbaC9iw9RoGZyo0Xj9Tkl6yGAcWtAPOBU0Qs3RQ0=.56784926-e4b0-4415-b53a-1335060ab143@github.com>

On Tue, 19 Aug 2025 09:13:45 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Fredrik Bredberg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Merge branch 'master' into 8365146_remove_lockingmode_ppc64
>>  - Update after review
>>  - Merge branch 'master' into 8365146_remove_lockingmode_ppc64
>>  - 8365146: Remove LockingMode related code from ppc64
>
> src/hotspot/cpu/ppc/macroAssembler_ppc.cpp line 2675:
> 
>> 2673: // "The box" is the space on the stack where we copy the object mark.
>> 2674: void MacroAssembler::compiler_fast_lock_object(ConditionRegister flag, Register oop, Register box,
>> 2675:                                                Register temp, Register displaced_header, Register current_header) {
> 
> Need to remove the declarations in the hpp file as well.

Fixed

> src/hotspot/cpu/ppc/macroAssembler_ppc.cpp line 2799:
> 
>> 2797: 
>> 2798: void MacroAssembler::compiler_fast_unlock_object(ConditionRegister flag, Register oop, Register box,
>> 2799:                                                  Register temp, Register displaced_header, Register current_header) {
> 
> Need to remove the declarations in the hpp file as well.

Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26697#discussion_r2287491489
PR Review Comment: https://git.openjdk.org/jdk/pull/26697#discussion_r2287492916

From fbredberg at openjdk.org  Wed Aug 20 09:11:45 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 20 Aug 2025 09:11:45 GMT
Subject: RFR: 8365146: Remove LockingMode related code from ppc64 [v2]
In-Reply-To: <veNK5YHW2-_-5I7ZnHjI8vtY8vGx4phAMoFQigywRU0=.98591381-1c30-475d-a834-fccc29a76b3d@github.com>
References: <mKtlz6j_OunSKwTrSfwVxcErf8oTsclqe65OSJxXvlw=.b958a3bc-0253-4efd-a9ff-03ac0418ba23@github.com>
 <101mw24zKLsjXjexjOZKimofI_yySxPw3gGyJq9HT1s=.495f1653-86ec-4d90-82d6-091b90d592f6@github.com>
 <veNK5YHW2-_-5I7ZnHjI8vtY8vGx4phAMoFQigywRU0=.98591381-1c30-475d-a834-fccc29a76b3d@github.com>
Message-ID: <Ie1k1yp_VdrnnXIGnoYVPhQ18ryS6nP3bkRiikkydSo=.d4bbf9e7-8c99-48fa-9be6-9ba7e6b9eaee@github.com>

On Tue, 19 Aug 2025 10:13:01 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Fredrik Bredberg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'master' into 8365146_remove_lockingmode_ppc64
>>  - 8365146: Remove LockingMode related code from ppc64
>
> This looks good besides the missing .hpp file update.
> Not sure what the plan regarding [JDK-8336325](https://bugs.openjdk.org/browse/JDK-8336325) is and if some of the removed code will be needed again.

@TheRealMDoerr 
> This looks good besides the missing .hpp file update. Not sure what the plan regarding [JDK-8336325](https://bugs.openjdk.org/browse/JDK-8336325) is and if some of the removed code will be needed again.

The `UseHeavyMonitors` code was somewhat mixed up with the legacy locking code. So the current plan is that if we decide to add something that will force a slow path (as a develop or maybe diagnostic option), we?d do a clean addition.

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

PR Comment: https://git.openjdk.org/jdk/pull/26697#issuecomment-3205011045

From snatarajan at openjdk.org  Wed Aug 20 10:31:22 2025
From: snatarajan at openjdk.org (Saranya Natarajan)
Date: Wed, 20 Aug 2025 10:31:22 GMT
Subject: RFR: 8358696: Assert with extreme values for -XX:BciProfileWidth
 [v9]
In-Reply-To: <5TRVeAXUQi6quM-nDWEij_jk6M5K2Vk31RA-Yjd8F2M=.5b63da45-93c3-4251-9e2e-3c64b7953919@github.com>
References: <5TRVeAXUQi6quM-nDWEij_jk6M5K2Vk31RA-Yjd8F2M=.5b63da45-93c3-4251-9e2e-3c64b7953919@github.com>
Message-ID: <-SMEjFj6yBqm_pNlCxGL9l5sBegIXLyz28nPhdcW-6U=.06a121a1-ce40-4bc0-89c4-bb1dbe90c489@github.com>

> **Issue**
> Extreme values for BciProfileWidth flag such as `java -XX:BciProfileWidth=-1 -version` and `java -XX:BciProfileWidth=100000 -version `results in assert failure `assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x0000772b63a7a3a0 <= 0x0000772b63b75159 <= 0x0000772b63b75158 `. This is observed in a x86 machine.
> 
> **Analysis** 
>  On debugging the issue, I found that increasing the size of the interpreter using the `InterpreterCodeSize` variable in `src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp` prevented the above mentioned assert from failing for large values of BciProfileWidth.  
> 
> **Proposal** 
> Considering the fact that larger BciProfileWidth results in slower profiling, I have proposed a range between 0 to 5000 to restrict the value for BciProfileWidth for x86 machines. This maximum value is based on modifying the `InterpreterCodeSize` variable in `src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp` using the smallest `InterpreterCodeSize` for all the architectures.  As for the lower bound, a value of -1 would be the same as 0, as this simply means  no  return bci's will be recorded in ret profile. 
> 
> **Issue in AArch64**
> Additionally running the command `java -XX:BciProfileWidth= 10000 -version` (or larger values) results in a different failure  `assert(offset_ok_for_immed(offset(), size)) failed: must be, was: 32768, 3` on an AArch64 machine.This is an issue of maximum offset for `ldr/str` in AArch64 which can be fixed using `form_address`  as mentioned in [JDK-8342736](https://bugs.openjdk.org/browse/JDK-8342736). In my preliminary fix using `form_address` on AArch64 machine. I had to modify 3 `ldr` and 1 `str` instruction (in file `src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp` at line number 926, 983, and 997). With this fix  using `form_address`, `BciProfileWidth` works for maximum of 5000 after which it crashes with`assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x0000772b63a7a3a0 <= 0x0000772b63b75159 <= 0x0000772b63b75158 `.  Without this fix `BciProfileWidth` works for a maximum value of 1300.   Currently, I have suggested to restrict the upper bound on AArch64 to 1000 instead 
 of fixing it with `form_address`. 
> 
> **Question to reviewers**
> Do you think this is a reasonable fix ?  For AArch64 do you suggest fixing using `form_address` ? If yes, do I fix it under this PR or create another one ?
> 
> **Request to port maintainers**
> @dafedafe suggested that we keep the upper bound of `BciProfileWidth` to 1000 pro...

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

  fix for PPC64

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26139/files
  - new: https://git.openjdk.org/jdk/pull/26139/files/2f511dbf..4cd5f6c3

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

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

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

From snatarajan at openjdk.org  Wed Aug 20 10:31:23 2025
From: snatarajan at openjdk.org (Saranya Natarajan)
Date: Wed, 20 Aug 2025 10:31:23 GMT
Subject: RFR: 8358696: Assert with extreme values for -XX:BciProfileWidth
 [v8]
In-Reply-To: <dQpWK73ywNOwdDT1Z0ByXG3wjWojGgmkdPZfey5B80M=.e14f639f-5ea6-46a1-9ca6-1f006e8bec9b@github.com>
References: <5TRVeAXUQi6quM-nDWEij_jk6M5K2Vk31RA-Yjd8F2M=.5b63da45-93c3-4251-9e2e-3c64b7953919@github.com>
 <x48Qtjsnz7ccoI5LdqiDmB8kO8FwmDjSE3ItYbtB4v0=.c22c1404-5766-4c32-a73a-a331cbe50f6d@github.com>
 <dQpWK73ywNOwdDT1Z0ByXG3wjWojGgmkdPZfey5B80M=.e14f639f-5ea6-46a1-9ca6-1f006e8bec9b@github.com>
Message-ID: <tznU-XRBXEEH3DiPmDUQD7VcjjW7SJH3r-zsyD4uQz4=.38c01bca-9be2-46ef-aaee-5b99168f1c46@github.com>

On Tue, 19 Aug 2025 14:01:17 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Saranya Natarajan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   additions for  linux-riscv64
>
> Can you add this patch, please?
> 
> diff --git a/src/hotspot/cpu/ppc/interp_masm_ppc.hpp b/src/hotspot/cpu/ppc/interp_masm_ppc.hpp
> index d3969427db3..ac3825d152f 100644
> --- a/src/hotspot/cpu/ppc/interp_masm_ppc.hpp
> +++ b/src/hotspot/cpu/ppc/interp_masm_ppc.hpp
> @@ -228,7 +228,7 @@ class InterpreterMacroAssembler: public MacroAssembler {
>  
>    // Interpreter profiling operations
>    void set_method_data_pointer_for_bcp();
> -  void test_method_data_pointer(Label& zero_continue);
> +  void test_method_data_pointer(Label& zero_continue, bool may_be_far = false);
>    void verify_method_data_pointer();
>  
>    void set_mdp_data_at(int constant, Register value);
> diff --git a/src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp b/src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp
> index 29fb54250c2..7557709653a 100644
> --- a/src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp
> +++ b/src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp
> @@ -1249,10 +1249,14 @@ void InterpreterMacroAssembler::set_method_data_pointer_for_bcp() {
>  }
>  
>  // Test ImethodDataPtr. If it is null, continue at the specified label.
> -void InterpreterMacroAssembler::test_method_data_pointer(Label& zero_continue) {
> +void InterpreterMacroAssembler::test_method_data_pointer(Label& zero_continue, bool may_be_far) {
>    assert(ProfileInterpreter, "must be profiling interpreter");
>    cmpdi(CR0, R28_mdx, 0);
> -  beq(CR0, zero_continue);
> +  if (may_be_far) {
> +    bc_far_optimized(Assembler::bcondCRbiIs1, bi0(CR0, Assembler::equal), zero_continue);
> +  } else {
> +    beq(CR0, zero_continue);
> +  }
>  }
>  
>  void InterpreterMacroAssembler::verify_method_data_pointer() {
> @@ -1555,7 +1559,7 @@ void InterpreterMacroAssembler::profile_ret(TosState state, Register return_bci,
>      uint row;
>  
>      // If no method data exists, go to profile_continue.
> -    test_method_data_pointer(profile_continue);
> +    test_method_data_pointer(profile_continue, true);
>  
>      // Update the total ret count.
>      increment_mdp_data_at(in_bytes(CounterData::count_offset()), scratch1, scratch2 );

@TheRealMDoerr : Thank you for the patch.  I have added the changes suggested by you. Could you review if it looks good ?

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

PR Comment: https://git.openjdk.org/jdk/pull/26139#issuecomment-3205435266

From snatarajan at openjdk.org  Wed Aug 20 10:34:40 2025
From: snatarajan at openjdk.org (Saranya Natarajan)
Date: Wed, 20 Aug 2025 10:34:40 GMT
Subject: RFR: 8358696: Assert with extreme values for -XX:BciProfileWidth
 [v8]
In-Reply-To: <1u3X9cabv-ybTzQXq7TAWha_8_97OBHH5-icvDiBqUk=.aba537c3-36bf-46d2-9d35-d755a29aca97@github.com>
References: <5TRVeAXUQi6quM-nDWEij_jk6M5K2Vk31RA-Yjd8F2M=.5b63da45-93c3-4251-9e2e-3c64b7953919@github.com>
 <x48Qtjsnz7ccoI5LdqiDmB8kO8FwmDjSE3ItYbtB4v0=.c22c1404-5766-4c32-a73a-a331cbe50f6d@github.com>
 <1u3X9cabv-ybTzQXq7TAWha_8_97OBHH5-icvDiBqUk=.aba537c3-36bf-46d2-9d35-d755a29aca97@github.com>
Message-ID: <nA5g7-fc7AhNT2qNad-61k9IJUMIzlD4cYSz4xm4914=.db0d5d1c-c9e1-41f6-99f5-7ac01638add3@github.com>

On Wed, 20 Aug 2025 08:56:21 GMT, Andrew Haley <aph at openjdk.org> wrote:

> I don't think we want different limits in BciProfileWidth for AArch64 and x86. Please use `form_address` as necessary.

@theRealAph :Thank you for the review. Based on @dafedafe's comment, we have decided to keep the upper bound for BciProfileWidth at 1000, which is the same for both AArch64 and x86. With this upper bound, there is no need for `form_address`.

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

PR Comment: https://git.openjdk.org/jdk/pull/26139#issuecomment-3205465390

From ayang at openjdk.org  Wed Aug 20 10:41:44 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 20 Aug 2025 10:41:44 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v11]
In-Reply-To: <UFXJrV71IKWGmnVANfYtYTgLJmRtnuN11dup9LHy_v8=.21b9e391-d8be-460c-87cb-c1fee94db422@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <UFXJrV71IKWGmnVANfYtYTgLJmRtnuN11dup9LHy_v8=.21b9e391-d8be-460c-87cb-c1fee94db422@github.com>
Message-ID: <EeD3lyiym3t4NmCCIWlXF_c2YiAKwKyCfCsryHgEYh8=.32590bcb-0fa5-4abe-8fd5-c096d59aaa87@github.com>

On Wed, 20 Aug 2025 09:00:30 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110).
>> 
>> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports:
>> 
>> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup()
>> 
>> CPUTimeUsage::GC::gc_threads()
>> CPUTimeUsage::GC::vm_thread()
>> CPUTimeUsage::GC::stringdedup()
>> 
>> CPUTimeUsage::Runtime::vm_thread()
>> 
>> 
>> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC.
>> 
>> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table:
>> 
>> 
>> [71.425s][info][cpu   ] === CPU time Statistics =============================================================
>> [71.425s][info][cpu   ]                                                                             CPUs
>> [71.425s][info][cpu   ]                                                                s       %  utilized
>> [71.425s][info][cpu   ]    Process
>> [71.425s][info][cpu   ]      Total                                             1616.3627  100.00      22.6
>> [71.425s][info][cpu   ]      VM Thread                                            5.2992    0.33       0.1
>> [71.425s][info][cpu   ]      Garbage Collection                                  83.7322    5.18       1.2
>> [71.425s][info][cpu   ]        GC Threads                                        82.7671    5.12       1.2
>> [71.425s][info][cpu   ]        VM Thread                                          0.9651    0.06       0.0
>> [71.425s][info][cpu   ] =====================================================================================
>> 
>> 
>> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove GCStatistics, add thread_cpu_time_or_zero, move GC/heap log to Universe::before_exit

src/hotspot/share/memory/universe.cpp line 1318:

> 1316:   }
> 1317: 
> 1318:   const double vm_thread_cpu_time = (double) CPUTimeUsage::Runtime::vm_thread() / NANOSECS_PER_SEC;

Does `vm_thread_cpu_time` include gc-vm-thread time? Looking at how it's printed, "VM Thread" and "Garbage Collection" are two separate lines, suggesting there are no overlapping btw them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26621#discussion_r2287752295

From mdoerr at openjdk.org  Wed Aug 20 12:09:45 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 20 Aug 2025 12:09:45 GMT
Subject: RFR: 8365146: Remove LockingMode related code from ppc64 [v3]
In-Reply-To: <ztFaCjEU6WEEUGFuZ6TvP57rwOQY9X4K64jJCXtOTI0=.d132f09c-c076-4ef2-8136-421be62d31d8@github.com>
References: <mKtlz6j_OunSKwTrSfwVxcErf8oTsclqe65OSJxXvlw=.b958a3bc-0253-4efd-a9ff-03ac0418ba23@github.com>
 <ztFaCjEU6WEEUGFuZ6TvP57rwOQY9X4K64jJCXtOTI0=.d132f09c-c076-4ef2-8136-421be62d31d8@github.com>
Message-ID: <JG6nyNPKdUdWsWtHS1o_HMbfmrwENZnMJjut3OybY_E=.34e366f5-4af7-4e0f-b590-c6f8cb101f1c@github.com>

On Wed, 20 Aug 2025 09:05:09 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
>> 
>> This PR removes `LockingMode` related code from the **ppc64** platform.
>> 
>> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.
>
> Fredrik Bredberg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into 8365146_remove_lockingmode_ppc64
>  - Update after review
>  - Merge branch 'master' into 8365146_remove_lockingmode_ppc64
>  - 8365146: Remove LockingMode related code from ppc64

Thanks!

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26697#pullrequestreview-3136299670

From azafari at openjdk.org  Wed Aug 20 12:19:18 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Wed, 20 Aug 2025 12:19:18 GMT
Subject: RFR: 8353468: [ubsan] arguments.cpp:2422:23: runtime error:
 2.14748e+11 is outside the range of representable values of type 'int'
Message-ID: <plQ5n7EjsekIjeY431_mBeo4rfcH39SVdPWogF2rT44=.20180c89-665e-4054-8625-1b04f8306b3b@github.com>

In converting values of `-XMinf` and `-XMaxf` options to `int`, overflow was not checked. 
The values are checked against INT_MAX and clamped.

Tests: tiers 1-5.

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

Commit messages:
 - 8363468: [ubsan] arguments.cpp:2422:23: runtime error: 2.14748e+11 is outside the range of representable values of type 'int'

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

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

From mdoerr at openjdk.org  Wed Aug 20 12:21:45 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 20 Aug 2025 12:21:45 GMT
Subject: RFR: 8358696: Assert with extreme values for -XX:BciProfileWidth
 [v9]
In-Reply-To: <-SMEjFj6yBqm_pNlCxGL9l5sBegIXLyz28nPhdcW-6U=.06a121a1-ce40-4bc0-89c4-bb1dbe90c489@github.com>
References: <5TRVeAXUQi6quM-nDWEij_jk6M5K2Vk31RA-Yjd8F2M=.5b63da45-93c3-4251-9e2e-3c64b7953919@github.com>
 <-SMEjFj6yBqm_pNlCxGL9l5sBegIXLyz28nPhdcW-6U=.06a121a1-ce40-4bc0-89c4-bb1dbe90c489@github.com>
Message-ID: <fut6Bu2BFN_CHZz5lcti9FugPVV7_lGxPNLkm-mpdEE=.f2ca934f-cb83-46fc-9533-544f76a1749b@github.com>

On Wed, 20 Aug 2025 10:31:22 GMT, Saranya Natarajan <snatarajan at openjdk.org> wrote:

>> **Issue**
>> Extreme values for BciProfileWidth flag such as `java -XX:BciProfileWidth=-1 -version` and `java -XX:BciProfileWidth=100000 -version `results in assert failure `assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x0000772b63a7a3a0 <= 0x0000772b63b75159 <= 0x0000772b63b75158 `. This is observed in a x86 machine.
>> 
>> **Analysis** 
>>  On debugging the issue, I found that increasing the size of the interpreter using the `InterpreterCodeSize` variable in `src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp` prevented the above mentioned assert from failing for large values of BciProfileWidth.  
>> 
>> **Proposal** 
>> Considering the fact that larger BciProfileWidth results in slower profiling, I have proposed a range between 0 to 5000 to restrict the value for BciProfileWidth for x86 machines. This maximum value is based on modifying the `InterpreterCodeSize` variable in `src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp` using the smallest `InterpreterCodeSize` for all the architectures.  As for the lower bound, a value of -1 would be the same as 0, as this simply means  no  return bci's will be recorded in ret profile. 
>> 
>> **Issue in AArch64**
>> Additionally running the command `java -XX:BciProfileWidth= 10000 -version` (or larger values) results in a different failure  `assert(offset_ok_for_immed(offset(), size)) failed: must be, was: 32768, 3` on an AArch64 machine.This is an issue of maximum offset for `ldr/str` in AArch64 which can be fixed using `form_address`  as mentioned in [JDK-8342736](https://bugs.openjdk.org/browse/JDK-8342736). In my preliminary fix using `form_address` on AArch64 machine. I had to modify 3 `ldr` and 1 `str` instruction (in file `src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp` at line number 926, 983, and 997). With this fix  using `form_address`, `BciProfileWidth` works for maximum of 5000 after which it crashes with`assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x0000772b63a7a3a0 <= 0x0000772b63b75159 <= 0x0000772b63b75158 `.  Without this fix `BciProfileWidth` works for a maximum value of 1300.   Currently, I have suggested to restrict the upper bound on AArch64 to 1000 instead
  of fixing it with `form_address`. 
>> 
>> **Question to reviewers**
>> Do you think this is a reasonable fix ?  For AArch64 do you suggest fixing using `form_address` ? If yes, do I fix it under this PR or create another one ?
>> 
>> **Request to port maintainers**
>> @dafedafe suggested that we keep the upper boun...
>
> Saranya Natarajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix for PPC64

Thanks. This looks basically good and the test passes on PPC64. Only minor nits.

src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp line 1252:

> 1250: 
> 1251: // Test ImethodDataPtr. If it is null, continue at the specified label.
> 1252:   void InterpreterMacroAssembler::test_method_data_pointer(Label& zero_continue, bool may_be_far) {

Spaces at the beginning should be removed.

src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp line 1260:

> 1258:     beq(CR0, zero_continue);
> 1259:   }
> 1260: 

No need for an empty line.

test/lib-test/jdk/test/whitebox/vm_flags/IntxTest.java line 42:

> 40:     private static final long COMPILE_THRESHOLD = VmFlagTest.WHITE_BOX.getIntxVMFlag("CompileThreshold");
> 41:     private static final Long[] TESTS = {0L, 100L, (long)(Integer.MAX_VALUE>>3)*100L};
> 42: 

This empty line should not be removed.

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

PR Review: https://git.openjdk.org/jdk/pull/26139#pullrequestreview-3136336983
PR Review Comment: https://git.openjdk.org/jdk/pull/26139#discussion_r2287984667
PR Review Comment: https://git.openjdk.org/jdk/pull/26139#discussion_r2287989584
PR Review Comment: https://git.openjdk.org/jdk/pull/26139#discussion_r2287985495

From dholmes at openjdk.org  Wed Aug 20 12:32:42 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 20 Aug 2025 12:32:42 GMT
Subject: RFR: 8365604: Null pointer dereference in
 src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses()
In-Reply-To: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
Message-ID: <O_bhdRkPTNNPMh-njv0iY0vTStYNWjOclqPxxfX4elg=.8a79282a-c985-442b-a105-f178852e60d5@github.com>

On Fri, 15 Aug 2025 11:58:48 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> The defect has been detected and confirmed in the function ArchDesc::declareClasses() located in the file src/hotspot/share/adlc/output_h.cpp with static code analysis. This defect can potentially lead to a null pointer dereference.
> 
> The pointer instr->_matrule is dereferenced in line 1952 without checking for nullptr, although earlier in line 1858 the same pointer is checked for nullptr, which indicates that it can be null.
> 
> According to [this](https://github.com/openjdk/jdk/pull/26002#issuecomment-3023050372) comment, this PR contains fixes for similar cases in other places.

I've added some additional mailing lists to ensure better coverage here.

Also I think you need to update the JBS (and PR) title to reflect the broader scope of the changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/26798#issuecomment-3206112684

From dholmes at openjdk.org  Wed Aug 20 12:36:41 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 20 Aug 2025 12:36:41 GMT
Subject: RFR: 8365633: Incorrect info is reported on hybrid CPU [v2]
In-Reply-To: <xeZsXlz_VUer4L2XraArNgofAegPxFvrpikCFdhYCBc=.8d7c0ac7-bd90-4e3b-b4db-461ee19db60a@github.com>
References: <T2R7vtbL0AaZLcRKdAPjoM6I8kz6lclHBNnOXi8JIQY=.1af945fd-1592-423a-8a19-940dd1c531d3@github.com>
 <xeZsXlz_VUer4L2XraArNgofAegPxFvrpikCFdhYCBc=.8d7c0ac7-bd90-4e3b-b4db-461ee19db60a@github.com>
Message-ID: <JCK35OXc5UU8BQx8GRfQN4YRg_IxztlBIUWeQg_ZjMU=.f32985ce-5f58-46f4-8973-d7efbe76514e@github.com>

On Sun, 17 Aug 2025 09:09:44 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> `VM.info` DCmd reports CPU information. I ran this on Intel Core Ultra 5 225U , then I got following result:
>> 
>> 
>> CPU: total 14 (initial active 14) (7 cores per cpu, 2 threads per core) family 6 model 181 stepping 0 microcode 0xffffffff, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, clwb, hv, serialize, rdtscp, rdpid, fsrm, gfni, f16c, cet_ibt, cet_ss
>> CPU Model and flags from /proc/cpuinfo:
>> model name : Intel(R) Core(TM) Ultra 5 225U
>> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm pni pclmulqdq monitor est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave osxsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch fsgsbase bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb intel_pt sha_ni umip gfni vaes vpclmulqdq rdpid ibrs ibpb stibp ssbd
>> 
>> 
>> It reports "7 cores per cpu, 2 threads per core". 225U has hybrid architecture - 2 P cores, 8 E cores, 2 LP cores, and also P core has 2 threads per core. Then it should be "12 cores, 14 threads".
>> https://www.intel.com/content/www/us/en/products/sku/241861/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html
>> 
>> According to Intel Software Developer's Manual, it seems to be difficult to get number of physical cores. In Linux kernel, it seems to be calculated by complex logic: https://github.com/torvalds/linux/blob/v6.16/arch/x86/kernel/smpboot.c#L567-L597
>> In addition, all of P cores might not be enabled HT. Thus to show only number of threads is reasonable at this point.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add HYBRID to CPUFeature in JVMCI

Seems to me that if your issue is that `(7 cores per cpu, 2 threads per core) ` is an incorrect description then `(14 threads)` is just as wrong as it implies 1 processor/core with 14 threads. If we can't get accurate/reliable core and thread counts then maybe we should not report anything in that part.

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

PR Comment: https://git.openjdk.org/jdk/pull/26808#issuecomment-3206131900

From dholmes at openjdk.org  Wed Aug 20 13:01:55 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 20 Aug 2025 13:01:55 GMT
Subject: RFR: 8364352: Some tests fail when using a limited number of
 pregenerated .jsa CDS archives
In-Reply-To: <9_SqooheFxiPUHUPh6CGpr_zmTMAEuPC8ttLrBIaRP8=.28ded786-d5a6-44fe-9479-7b648415a512@github.com>
References: <EnyzXiapmd29T3spHQT7QTBv2SVQVKVU6L2NEDoejHg=.65f803f7-09e0-4e5b-ac21-a60474c5facd@github.com>
 <94-rbdkR3HFSuIiaXMgE9E-GWOQwgWgDz4xWDcYQPMk=.0841b935-819f-497a-81f9-cf5f6da9acf0@github.com>
 <9_SqooheFxiPUHUPh6CGpr_zmTMAEuPC8ttLrBIaRP8=.28ded786-d5a6-44fe-9479-7b648415a512@github.com>
Message-ID: <HkKVaB2jColT6AnFuWdsDvG2f_5lB8n6MhvMm28Zwa8=.80ed7022-d6ef-4612-be3c-eb335cf2ddcd@github.com>

On Wed, 20 Aug 2025 07:15:23 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> test/hotspot/jtreg/runtime/CompressedOops/CompressedCPUSpecificClassSpaceReservation.java line 31:
>> 
>>> 29:  * @requires vm.flagless
>>> 30:  * @requires vm.cds
>>> 31:  * @requires vm.cds.default.archive.available
>> 
>> Does the notion of "default.archive" change depending on whether the VM is executing in COOPs/NoCOOPS or COH/NoCOH modes?
>
> That's the coding 
> 
> https://github.com/openjdk/jdk/blob/320235ccb88b4b554cd5756b7e6a34ce97aabd53/test/jtreg-ext/requires/VMProps.java#L438
> 
> So it ALWAYS looks at classes,jsa .

Okay ... so what configuration does classes.jsa represent? I'm struggling to understand exactly which archive these tests need, or whether they should be able to work with any of the 4 variants. ??

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26820#discussion_r2288086642

From bulasevich at openjdk.org  Wed Aug 20 13:16:50 2025
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Wed, 20 Aug 2025 13:16:50 GMT
Subject: RFR: 8358696: Assert with extreme values for -XX:BciProfileWidth
 [v8]
In-Reply-To: <nA5g7-fc7AhNT2qNad-61k9IJUMIzlD4cYSz4xm4914=.db0d5d1c-c9e1-41f6-99f5-7ac01638add3@github.com>
References: <5TRVeAXUQi6quM-nDWEij_jk6M5K2Vk31RA-Yjd8F2M=.5b63da45-93c3-4251-9e2e-3c64b7953919@github.com>
 <x48Qtjsnz7ccoI5LdqiDmB8kO8FwmDjSE3ItYbtB4v0=.c22c1404-5766-4c32-a73a-a331cbe50f6d@github.com>
 <1u3X9cabv-ybTzQXq7TAWha_8_97OBHH5-icvDiBqUk=.aba537c3-36bf-46d2-9d35-d755a29aca97@github.com>
 <nA5g7-fc7AhNT2qNad-61k9IJUMIzlD4cYSz4xm4914=.db0d5d1c-c9e1-41f6-99f5-7ac01638add3@github.com>
Message-ID: <2oDcygh0RS8lLG8LMKfWoUDGnpV2VaTRn0hDWJGDr6g=.4971a7ff-32d7-410e-a60c-587e741c431d@github.com>

On Wed, 20 Aug 2025 10:31:45 GMT, Saranya Natarajan <snatarajan at openjdk.org> wrote:

> I don't think we want different limits in BciProfileWidth for AArch64 and x86. Please use `form_address` as necessary.

@theRealAph It was decided in that discussion to cap the maximum value of BciProfileWidth (a debug option) at 1000 across all platforms. Even this limit is already excessive, since methods with thousands of ret bytecodes are extremely uncommon. Unless there is another legitimate way to enlarge the MDO, I don?t think AArch64 code should be adjusted just to accommodate this artificial case.

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

PR Comment: https://git.openjdk.org/jdk/pull/26139#issuecomment-3206295005

From mbaesken at openjdk.org  Wed Aug 20 13:19:39 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 20 Aug 2025 13:19:39 GMT
Subject: RFR: 8364352: Some tests fail when using a limited number of
 pregenerated .jsa CDS archives
In-Reply-To: <HkKVaB2jColT6AnFuWdsDvG2f_5lB8n6MhvMm28Zwa8=.80ed7022-d6ef-4612-be3c-eb335cf2ddcd@github.com>
References: <EnyzXiapmd29T3spHQT7QTBv2SVQVKVU6L2NEDoejHg=.65f803f7-09e0-4e5b-ac21-a60474c5facd@github.com>
 <94-rbdkR3HFSuIiaXMgE9E-GWOQwgWgDz4xWDcYQPMk=.0841b935-819f-497a-81f9-cf5f6da9acf0@github.com>
 <9_SqooheFxiPUHUPh6CGpr_zmTMAEuPC8ttLrBIaRP8=.28ded786-d5a6-44fe-9479-7b648415a512@github.com>
 <HkKVaB2jColT6AnFuWdsDvG2f_5lB8n6MhvMm28Zwa8=.80ed7022-d6ef-4612-be3c-eb335cf2ddcd@github.com>
Message-ID: <OP_49_Dt_PDNIVTbEe9uPBWn-MsQyh-FqCFzwDSRnmk=.26fba79d-50fa-401b-80fd-7bb1952e6441@github.com>

On Wed, 20 Aug 2025 12:58:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> That's the coding 
>> 
>> https://github.com/openjdk/jdk/blob/320235ccb88b4b554cd5756b7e6a34ce97aabd53/test/jtreg-ext/requires/VMProps.java#L438
>> 
>> So it ALWAYS looks at classes,jsa .
>
> Okay ... so what configuration does classes.jsa represent? I'm struggling to understand exactly which archive these tests need, or whether they should be able to work with any of the 4 variants. ??

Afaik those are the 4 archives you find usually on Linux in the JVM image ; classes.jsa represents the compressed oops but no compressed object headers config .

./lib/server/classes_nocoops.jsa     -    no compressed oops
./lib/server/classes.jsa                     -   compressed oops
./lib/server/classes_coh.jsa             -    compressed object headers, compressed oops 
./lib/server/classes_nocoops_coh.jsa   -   compressed object headers, no compressed oops

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26820#discussion_r2288134656

From mbaesken at openjdk.org  Wed Aug 20 13:19:39 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 20 Aug 2025 13:19:39 GMT
Subject: RFR: 8364352: Some tests fail when using a limited number of
 pregenerated .jsa CDS archives
In-Reply-To: <OP_49_Dt_PDNIVTbEe9uPBWn-MsQyh-FqCFzwDSRnmk=.26fba79d-50fa-401b-80fd-7bb1952e6441@github.com>
References: <EnyzXiapmd29T3spHQT7QTBv2SVQVKVU6L2NEDoejHg=.65f803f7-09e0-4e5b-ac21-a60474c5facd@github.com>
 <94-rbdkR3HFSuIiaXMgE9E-GWOQwgWgDz4xWDcYQPMk=.0841b935-819f-497a-81f9-cf5f6da9acf0@github.com>
 <9_SqooheFxiPUHUPh6CGpr_zmTMAEuPC8ttLrBIaRP8=.28ded786-d5a6-44fe-9479-7b648415a512@github.com>
 <HkKVaB2jColT6AnFuWdsDvG2f_5lB8n6MhvMm28Zwa8=.80ed7022-d6ef-4612-be3c-eb335cf2ddcd@github.com>
 <OP_49_Dt_PDNIVTbEe9uPBWn-MsQyh-FqCFzwDSRnmk=.26fba79d-50fa-401b-80fd-7bb1952e6441@github.com>
Message-ID: <KgB7CtXlr5SnvAMThcX-8bBsvjE_rAKR9ljEahV0Wog=.6d1b1c1d-a571-4eb0-ad38-c121201412b0@github.com>

On Wed, 20 Aug 2025 13:13:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Okay ... so what configuration does classes.jsa represent? I'm struggling to understand exactly which archive these tests need, or whether they should be able to work with any of the 4 variants. ??
>
> Afaik those are the 4 archives you find usually on Linux in the JVM image ; classes.jsa represents the compressed oops but no compressed object headers config .
> 
> ./lib/server/classes_nocoops.jsa     -    no compressed oops
> ./lib/server/classes.jsa                     -   compressed oops
> ./lib/server/classes_coh.jsa             -    compressed object headers, compressed oops 
> ./lib/server/classes_nocoops_coh.jsa   -   compressed object headers, no compressed oops

Probably the requires vm.cds.default.archive.available  is from times with less jsa files then we usually have today . We could of course introduce 4 requires for all the different  jsa's we potentially have these days but I am not sure if it is really needed,

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26820#discussion_r2288140399

From mbaesken at openjdk.org  Wed Aug 20 13:19:40 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 20 Aug 2025 13:19:40 GMT
Subject: RFR: 8364352: Some tests fail when using a limited number of
 pregenerated .jsa CDS archives
In-Reply-To: <KgB7CtXlr5SnvAMThcX-8bBsvjE_rAKR9ljEahV0Wog=.6d1b1c1d-a571-4eb0-ad38-c121201412b0@github.com>
References: <EnyzXiapmd29T3spHQT7QTBv2SVQVKVU6L2NEDoejHg=.65f803f7-09e0-4e5b-ac21-a60474c5facd@github.com>
 <94-rbdkR3HFSuIiaXMgE9E-GWOQwgWgDz4xWDcYQPMk=.0841b935-819f-497a-81f9-cf5f6da9acf0@github.com>
 <9_SqooheFxiPUHUPh6CGpr_zmTMAEuPC8ttLrBIaRP8=.28ded786-d5a6-44fe-9479-7b648415a512@github.com>
 <HkKVaB2jColT6AnFuWdsDvG2f_5lB8n6MhvMm28Zwa8=.80ed7022-d6ef-4612-be3c-eb335cf2ddcd@github.com>
 <OP_49_Dt_PDNIVTbEe9uPBWn-MsQyh-FqCFzwDSRnmk=.26fba79d-50fa-401b-80fd-7bb1952e6441@github.com>
 <KgB7CtXlr5SnvAMThcX-8bBsvjE_rAKR9ljEahV0Wog=.6d1b1c1d-a571-4eb0-ad38-c121201412b0@github.com>
Message-ID: <zxGWV8YmI88ql8Qilcd37YFmEjldEfHL4aJoRiHEmBI=.a1bd5dcb-9e16-4fb7-bdc2-53d409e1a59b@github.com>

On Wed, 20 Aug 2025 13:15:13 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Afaik those are the 4 archives you find usually on Linux in the JVM image ; classes.jsa represents the compressed oops but no compressed object headers config .
>> 
>> ./lib/server/classes_nocoops.jsa     -    no compressed oops
>> ./lib/server/classes.jsa                     -   compressed oops
>> ./lib/server/classes_coh.jsa             -    compressed object headers, compressed oops 
>> ./lib/server/classes_nocoops_coh.jsa   -   compressed object headers, no compressed oops
>
> Probably the requires vm.cds.default.archive.available  is from times with less jsa files then we usually have today . We could of course introduce 4 requires for all the different  jsa's we potentially have these days but I am not sure if it is really needed,

btw could we have in other JVMs then server  (client? minimal?)  even MORE of those jsa files? I am getting confused too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26820#discussion_r2288145032

From coleenp at openjdk.org  Wed Aug 20 13:25:41 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 20 Aug 2025 13:25:41 GMT
Subject: RFR: 8365814: Consolidate has_been_archived() and
 has_been_buffered() in ArchiveBuilder
In-Reply-To: <CjcbzPgOlwDABX6nFwnR4TgkD-FcK8VSXZuz5tsSNJE=.ee6b4d03-9855-4bbd-9031-4a657dda358e@github.com>
References: <CjcbzPgOlwDABX6nFwnR4TgkD-FcK8VSXZuz5tsSNJE=.ee6b4d03-9855-4bbd-9031-4a657dda358e@github.com>
Message-ID: <F7u5rGal7Kh4KZz1RGjeWPDvXD_rqKO1lySjtWiaH6M=.b9ba5536-a5d6-4f92-8b38-603ddcf1463d@github.com>

On Wed, 20 Aug 2025 04:01:13 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Merged the two methods into one: `ArchiveBuilder::has_been_archived()`. Added comments and asserts to explain what the expected result is.

src/hotspot/share/cds/archiveBuilder.hpp line 448:

> 446:   bool has_been_archived(address src_addr) const;
> 447:   template <typename T> bool has_been_archived(T src_addr) const {
> 448:     return has_been_archived((address)src_addr);

What's the point of having a template if you're going to erase the type?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26853#discussion_r2288159601

From snatarajan at openjdk.org  Wed Aug 20 13:35:35 2025
From: snatarajan at openjdk.org (Saranya Natarajan)
Date: Wed, 20 Aug 2025 13:35:35 GMT
Subject: RFR: 8358696: Assert with extreme values for -XX:BciProfileWidth
 [v10]
In-Reply-To: <5TRVeAXUQi6quM-nDWEij_jk6M5K2Vk31RA-Yjd8F2M=.5b63da45-93c3-4251-9e2e-3c64b7953919@github.com>
References: <5TRVeAXUQi6quM-nDWEij_jk6M5K2Vk31RA-Yjd8F2M=.5b63da45-93c3-4251-9e2e-3c64b7953919@github.com>
Message-ID: <C7dZ8lGlZn_wlbsl9zH5xO_ABGY8Ww7hB-WfMQ6rIMs=.8d5a9c50-a318-43cf-b822-3c67bf448896@github.com>

> **Issue**
> Extreme values for BciProfileWidth flag such as `java -XX:BciProfileWidth=-1 -version` and `java -XX:BciProfileWidth=100000 -version `results in assert failure `assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x0000772b63a7a3a0 <= 0x0000772b63b75159 <= 0x0000772b63b75158 `. This is observed in a x86 machine.
> 
> **Analysis** 
>  On debugging the issue, I found that increasing the size of the interpreter using the `InterpreterCodeSize` variable in `src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp` prevented the above mentioned assert from failing for large values of BciProfileWidth.  
> 
> **Proposal** 
> Considering the fact that larger BciProfileWidth results in slower profiling, I have proposed a range between 0 to 5000 to restrict the value for BciProfileWidth for x86 machines. This maximum value is based on modifying the `InterpreterCodeSize` variable in `src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp` using the smallest `InterpreterCodeSize` for all the architectures.  As for the lower bound, a value of -1 would be the same as 0, as this simply means  no  return bci's will be recorded in ret profile. 
> 
> **Issue in AArch64**
> Additionally running the command `java -XX:BciProfileWidth= 10000 -version` (or larger values) results in a different failure  `assert(offset_ok_for_immed(offset(), size)) failed: must be, was: 32768, 3` on an AArch64 machine.This is an issue of maximum offset for `ldr/str` in AArch64 which can be fixed using `form_address`  as mentioned in [JDK-8342736](https://bugs.openjdk.org/browse/JDK-8342736). In my preliminary fix using `form_address` on AArch64 machine. I had to modify 3 `ldr` and 1 `str` instruction (in file `src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp` at line number 926, 983, and 997). With this fix  using `form_address`, `BciProfileWidth` works for maximum of 5000 after which it crashes with`assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x0000772b63a7a3a0 <= 0x0000772b63b75159 <= 0x0000772b63b75158 `.  Without this fix `BciProfileWidth` works for a maximum value of 1300.   Currently, I have suggested to restrict the upper bound on AArch64 to 1000 instead 
 of fixing it with `form_address`. 
> 
> **Question to reviewers**
> Do you think this is a reasonable fix ?  For AArch64 do you suggest fixing using `form_address` ? If yes, do I fix it under this PR or create another one ?
> 
> **Request to port maintainers**
> @dafedafe suggested that we keep the upper bound of `BciProfileWidth` to 1000 pro...

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

 - addressing review : nit comments
 - review : change to test case to test values outside the range

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26139/files
  - new: https://git.openjdk.org/jdk/pull/26139/files/4cd5f6c3..4f6ad175

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

  Stats: 28 lines in 3 files changed: 19 ins; 3 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/26139.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26139/head:pull/26139

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

From snatarajan at openjdk.org  Wed Aug 20 13:35:35 2025
From: snatarajan at openjdk.org (Saranya Natarajan)
Date: Wed, 20 Aug 2025 13:35:35 GMT
Subject: RFR: 8358696: Assert with extreme values for -XX:BciProfileWidth
 [v6]
In-Reply-To: <vvPz4DbG8hvtva6heXU-ArTE3nXQHwfFCH9FKwdSd4I=.f123676a-02b2-4724-a493-cfee89c69058@github.com>
References: <5TRVeAXUQi6quM-nDWEij_jk6M5K2Vk31RA-Yjd8F2M=.5b63da45-93c3-4251-9e2e-3c64b7953919@github.com>
 <Nt6C65eUJqxWJAPob_5ZvNiQXZJMQK_vD_Ik9NYSCm4=.773e5f1a-a02f-4206-99d8-e8003a708cd6@github.com>
 <1QbX5WHkEdjP-unAFJ1vYaoIc9bV8zz8dA-vKZCkYn8=.8e3704ae-9490-4471-9e5c-dae44004d46f@github.com>
 <ECYtRACv9J4K9z9CFQDAWRX7psioszU240ikVOO6RhM=.a88220a5-8ad5-4d0f-94e4-b0999e343d99@github.com>
 <oPH0G597q13SYnSti3t3SpasSC4L1EuqRl4X-JjXfX0=.cd5147ae-fcd6-490c-a479-62896cc02ce7@github.com>
 <vvPz4DbG8hvtva6heXU-ArTE3nXQHwfFCH9FKwdSd4I=.f123676a-02b2-4724-a493-cfee89c69058@github.com>
Message-ID: <mHiVm9cFBcUxFK67kkbwLhgiLxLS_Tx_2SjQAEKulfE=.d4b3b8ec-e86f-4668-b343-1f324f05aa17@github.com>

On Wed, 13 Aug 2025 09:45:21 GMT, Saranya Natarajan <snatarajan at openjdk.org> wrote:

>> Shouldn't we check that the vm doesn't crash with `BciProfileWidth=-1` and `BciProfileWidth=100000` (or another very high value)?
>
> @dafedafe : I am working on this and will upload the changes soon.

I have uploaded a test that checks two values of `BciProfileWidth` that outside the range

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26139#discussion_r2288185425

From fbredberg at openjdk.org  Wed Aug 20 13:36:41 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 20 Aug 2025 13:36:41 GMT
Subject: RFR: 8365189: Remove LockingMode related code from arm32
In-Reply-To: <k8o4tQO6pqduS-BNhurBtrb0y6o-MM-G4JVbXaySCEs=.912d4f04-56e5-44d8-9190-95f5d6f14e2b@github.com>
References: <bvw0sMNTLzhoms1UW34LXiFrkKDysBfeLAQftPjBh5o=.ddd3c817-4094-4cfe-afa2-4c751eae6814@github.com>
 <k8o4tQO6pqduS-BNhurBtrb0y6o-MM-G4JVbXaySCEs=.912d4f04-56e5-44d8-9190-95f5d6f14e2b@github.com>
Message-ID: <N8Krvy2_BTqejquD4CzmPBO_Sk7t4wn_3HUiJvEKQTU=.239beefd-fdb8-4de5-b6dc-c5a36c73eb7d@github.com>

On Tue, 19 Aug 2025 07:30:57 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
>> 
>> This PR removes `LockingMode` related code from the **arm32** platform.
>> 
>> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.
>
> Looks good.
> 
> You unified some comment styles within a file, but kept them different across the files. 
> Not sure the Fall through comments do much now when the ifs are gone.
> A bunch of `[un]lock_done` lables are now only used with bind and are never jumped to.
> 
> Not sure any of these require fixing.

@xmas92 
> You unified some comment styles within a file, but kept them different across the files. Not sure the Fall through comments do much now when the ifs are gone. A bunch of `[un]lock_done` lables are now only used with bind and are never jumped to.

It's hard not to unify comments within a file when you are changing the code, but didn't find it important enough to unify in all files.
I agree, the `Fall through` comments are not that useful. Looking at Aarch64 I see that they far more informative as they read `Slow path will re-enter here`. I also think you are wrong about the bunch of `[un]lock_done` lables being used only with bind. As far a I can tell they are all jumped to, but far later in the code.

> Not sure any of these require fixing.

I'll fix it if something else that needs fixing turns up, otherwise I'll let it pass.

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

PR Comment: https://git.openjdk.org/jdk/pull/26795#issuecomment-3206365654

From jsjolen at openjdk.org  Wed Aug 20 13:40:43 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 20 Aug 2025 13:40:43 GMT
Subject: RFR: 8353444: NMT: rename 'category' to 'MemTag' in malloc tracker
 [v6]
In-Reply-To: <hoC7W0ro6JyIZEHlGdF3mApAo0-BKlM53p5O2Qhd75g=.5ccb1b9a-9296-46e3-9f40-01f77d3741c3@github.com>
References: <mVv-IomtzU25S1Xv1kQAy0gkUYPmuOLFDc-bJskDTaY=.c434ab86-536f-4e22-9dfa-64a00274c06b@github.com>
 <hoC7W0ro6JyIZEHlGdF3mApAo0-BKlM53p5O2Qhd75g=.5ccb1b9a-9296-46e3-9f40-01f77d3741c3@github.com>
Message-ID: <BSfZi5UkF0Ud91qo2ySi2AI8QyRS_nuLCXCD7jzausw=.89950693-2487-49a7-9233-c3bfbc421856@github.com>

On Wed, 13 Aug 2025 11:19:58 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> Renamed usage of 'category' for 'MemTag' cases.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reverted some renamings

There's an approval missing, we need another person to review this.

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

PR Comment: https://git.openjdk.org/jdk/pull/25226#issuecomment-3206380697

From azafari at openjdk.org  Wed Aug 20 13:43:44 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Wed, 20 Aug 2025 13:43:44 GMT
Subject: Integrated: 8353444: NMT: rename 'category' to 'MemTag' in malloc
 tracker
In-Reply-To: <mVv-IomtzU25S1Xv1kQAy0gkUYPmuOLFDc-bJskDTaY=.c434ab86-536f-4e22-9dfa-64a00274c06b@github.com>
References: <mVv-IomtzU25S1Xv1kQAy0gkUYPmuOLFDc-bJskDTaY=.c434ab86-536f-4e22-9dfa-64a00274c06b@github.com>
Message-ID: <THfFPUsDYo05pOTp5m2Yeage7C1NR5K_wL6pwYLAXb8=.9e05aec1-1fd2-4f33-8393-72b3d00ae2f3@github.com>

On Wed, 14 May 2025 13:22:40 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> Renamed usage of 'category' for 'MemTag' cases.

This pull request has now been integrated.

Changeset: e912977a
Author:    Afshin Zafari <azafari at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e912977a6687917ed45520c4d8558ebe630e3f52
Stats:     30 lines in 5 files changed: 0 ins; 1 del; 29 mod

8353444: NMT: rename 'category' to 'MemTag' in malloc tracker

Reviewed-by: jsjolen

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

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

From azafari at openjdk.org  Wed Aug 20 13:40:41 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Wed, 20 Aug 2025 13:40:41 GMT
Subject: RFR: 8353444: NMT: rename 'category' to 'MemTag' in malloc tracker
In-Reply-To: <vQgwocz8YWurTflj_EJ4CGqvJ7U0PqvhEBv_FW9Yw4Y=.11bacdb3-bf13-41ba-a9d6-c194872864d4@github.com>
References: <mVv-IomtzU25S1Xv1kQAy0gkUYPmuOLFDc-bJskDTaY=.c434ab86-536f-4e22-9dfa-64a00274c06b@github.com>
 <vQgwocz8YWurTflj_EJ4CGqvJ7U0PqvhEBv_FW9Yw4Y=.11bacdb3-bf13-41ba-a9d6-c194872864d4@github.com>
Message-ID: <7Vh4eX5gCZiWr8AIjgWijTx8fTYbPfm5LU9m2x_kJfU=.265c619a-6c2f-4b2e-a158-54338a25ea40@github.com>

On Fri, 30 May 2025 12:16:07 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Renamed usage of 'category' for 'MemTag' cases.
>
> Can we use `category` as the term for any user-facing things? I'm thinking output from tooling, input options, docs, etc.

Thanks for review, @jdksjolen

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

PR Comment: https://git.openjdk.org/jdk/pull/25226#issuecomment-3205619416

From azafari at openjdk.org  Wed Aug 20 14:02:44 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Wed, 20 Aug 2025 14:02:44 GMT
Subject: RFR: 8353444: NMT: rename 'category' to 'MemTag' in malloc tracker
 [v6]
In-Reply-To: <BSfZi5UkF0Ud91qo2ySi2AI8QyRS_nuLCXCD7jzausw=.89950693-2487-49a7-9233-c3bfbc421856@github.com>
References: <mVv-IomtzU25S1Xv1kQAy0gkUYPmuOLFDc-bJskDTaY=.c434ab86-536f-4e22-9dfa-64a00274c06b@github.com>
 <hoC7W0ro6JyIZEHlGdF3mApAo0-BKlM53p5O2Qhd75g=.5ccb1b9a-9296-46e3-9f40-01f77d3741c3@github.com>
 <BSfZi5UkF0Ud91qo2ySi2AI8QyRS_nuLCXCD7jzausw=.89950693-2487-49a7-9233-c3bfbc421856@github.com>
Message-ID: <iKICOHedByOZIcF1wtsebiOlyk_9xEEGaO2bZQP7ZLM=.577cb6ae-a933-4d4f-b3b0-75641e6e35ba@github.com>

On Wed, 20 Aug 2025 13:38:04 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> There's an approval missing, we need another person to review this.

IIRC, only 1 re-review is needed.

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

PR Comment: https://git.openjdk.org/jdk/pull/25226#issuecomment-3206499047

From adinn at openjdk.org  Wed Aug 20 14:22:37 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 20 Aug 2025 14:22:37 GMT
Subject: RFR: 8365604: Null pointer dereference in
 src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses()
In-Reply-To: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
Message-ID: <mm_qPZgVNqoihxb53bJCzsnvmNg15xdfOr6tj3FcVvA=.cf3562a5-a2bf-4c6f-8250-fa07f2939143@github.com>

On Fri, 15 Aug 2025 11:58:48 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> The defect has been detected and confirmed in the function ArchDesc::declareClasses() located in the file src/hotspot/share/adlc/output_h.cpp with static code analysis. This defect can potentially lead to a null pointer dereference.
> 
> The pointer instr->_matrule is dereferenced in line 1952 without checking for nullptr, although earlier in line 1858 the same pointer is checked for nullptr, which indicates that it can be null.
> 
> According to [this](https://github.com/openjdk/jdk/pull/26002#issuecomment-3023050372) comment, this PR contains fixes for similar cases in other places.

I'm not clear that the original issue is necessarily a bug that needs fixing with a skip to the next else if case.

The justification for adding `instr->_matrule != nullptr && instr->_matrule->_rChild != nullptr` to the if branch test is that earlier code allows for the possibility that `instr->_matrule` might be null. However, that check is performed in an unconditional context for any value of `instr` whereas this specific else branch limits the circumstance to the case where `instr->is_ideal_copy()` is found to be true.

So, the prior test offers no guarantee that in this restricted case a null pointer should or should not be possible. The original design may assume that a successful test for `instr->is_ideal_copy()` ought to guarantee that both `instr->_matrule` and `instr->_matrule->_rChild` are non-null. That cannot be determined by the evidence offered. It can only be determined by looking at how instr is constructed.

So, rather than just skip to the next case we might need to handle this with an assert and fix whatever code is producing an ideal copy with null fields.

Given the level of analysis offered for this case I am suspicious as to whether the other cases tacked onto this issue ought to be accepted at face value without some justification as to why a null check and skip to the next case is correct.

I'm also wondering how and why all these cases and associated amendments were arrived at? Is this perhaps based on output from a code analysis tool (perhaps even a genAI tool). If so then I think 1) we ought to be told and 2) we ought to treat its recommendations with a very healthy dose of skepticism.

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

PR Comment: https://git.openjdk.org/jdk/pull/26798#issuecomment-3206613521

From duke at openjdk.org  Wed Aug 20 15:14:34 2025
From: duke at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Wed, 20 Aug 2025 15:14:34 GMT
Subject: RFR: 8365378: Redundant code in Deoptimization::print_statistics
Message-ID: <4qlNQcnx7UvD5kqrN0tyxulJTu-PZ5cDBy5AwYGHSTo=.d00af3bd-86f6-474c-a7ff-bd0ff5a79597@github.com>

Hi all,

The `Deoptimization::print_statistics` function has a conditional that is never invoked. `bc_case` is bound in a for loop and will always be < `BC_CASE_LIMIT`. Therefore, the entire condition will never hold, and the branch never execute. This change removes the dead code in order to increase maintainability.

I've run hotspot:tier1 to hotspot:tier3, in which I observed no test failures.

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

Commit messages:
 - Remove deoptimization statistics dead code.

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

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

From mdoerr at openjdk.org  Wed Aug 20 15:32:47 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 20 Aug 2025 15:32:47 GMT
Subject: RFR: 8358696: Assert with extreme values for -XX:BciProfileWidth
 [v10]
In-Reply-To: <fut6Bu2BFN_CHZz5lcti9FugPVV7_lGxPNLkm-mpdEE=.f2ca934f-cb83-46fc-9533-544f76a1749b@github.com>
References: <5TRVeAXUQi6quM-nDWEij_jk6M5K2Vk31RA-Yjd8F2M=.5b63da45-93c3-4251-9e2e-3c64b7953919@github.com>
 <-SMEjFj6yBqm_pNlCxGL9l5sBegIXLyz28nPhdcW-6U=.06a121a1-ce40-4bc0-89c4-bb1dbe90c489@github.com>
 <fut6Bu2BFN_CHZz5lcti9FugPVV7_lGxPNLkm-mpdEE=.f2ca934f-cb83-46fc-9533-544f76a1749b@github.com>
Message-ID: <60sgN5hitLgZGw3LHfU7GoQ9NWQA31D1Q_RUjjMiOqI=.1110e1b5-8560-4cd8-a695-5b3aa43af4c9@github.com>

On Wed, 20 Aug 2025 12:17:26 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Saranya Natarajan has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - addressing review : nit comments
>>  - review : change to test case to test values outside the range
>
> test/lib-test/jdk/test/whitebox/vm_flags/IntxTest.java line 42:
> 
>> 40:     private static final long COMPILE_THRESHOLD = VmFlagTest.WHITE_BOX.getIntxVMFlag("CompileThreshold");
>> 41:     private static final Long[] TESTS = {0L, 100L, (long)(Integer.MAX_VALUE>>3)*100L};
>> 42: 
> 
> This empty line should not be removed.

Thanks! But, the indentation of the next line looks odd, now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26139#discussion_r2288545780

From jsjolen at openjdk.org  Wed Aug 20 18:01:49 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 20 Aug 2025 18:01:49 GMT
Subject: RFR: 8353444: NMT: rename 'category' to 'MemTag' in malloc tracker
 [v6]
In-Reply-To: <iKICOHedByOZIcF1wtsebiOlyk_9xEEGaO2bZQP7ZLM=.577cb6ae-a933-4d4f-b3b0-75641e6e35ba@github.com>
References: <mVv-IomtzU25S1Xv1kQAy0gkUYPmuOLFDc-bJskDTaY=.c434ab86-536f-4e22-9dfa-64a00274c06b@github.com>
 <hoC7W0ro6JyIZEHlGdF3mApAo0-BKlM53p5O2Qhd75g=.5ccb1b9a-9296-46e3-9f40-01f77d3741c3@github.com>
 <BSfZi5UkF0Ud91qo2ySi2AI8QyRS_nuLCXCD7jzausw=.89950693-2487-49a7-9233-c3bfbc421856@github.com>
 <iKICOHedByOZIcF1wtsebiOlyk_9xEEGaO2bZQP7ZLM=.577cb6ae-a933-4d4f-b3b0-75641e6e35ba@github.com>
Message-ID: <9ikv2xVIglYpPSPNIWXIJlo-aqHMwMJLu6C1wcKkZm4=.ca0130ab-2bc8-4601-a015-473de1c7753a@github.com>

On Wed, 20 Aug 2025 13:59:38 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> > There's an approval missing, we need another person to review this.
> 
> IIRC, only 1 re-review is needed.

Yes, but there was only one review approval for this PR (see https://github.com/openjdk/jdk/commit/e912977a6687917ed45520c4d8558ebe630e3f52 `Reviewed-by` in the commit message). C'est la vie, I don't think that this PR is contentious enough to back it out, let's leave it as is.

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

PR Comment: https://git.openjdk.org/jdk/pull/25226#issuecomment-3207499022

From dcubed at openjdk.org  Wed Aug 20 18:41:48 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 20 Aug 2025 18:41:48 GMT
Subject: RFR: 8353444: NMT: rename 'category' to 'MemTag' in malloc tracker
 [v6]
In-Reply-To: <hoC7W0ro6JyIZEHlGdF3mApAo0-BKlM53p5O2Qhd75g=.5ccb1b9a-9296-46e3-9f40-01f77d3741c3@github.com>
References: <mVv-IomtzU25S1Xv1kQAy0gkUYPmuOLFDc-bJskDTaY=.c434ab86-536f-4e22-9dfa-64a00274c06b@github.com>
 <hoC7W0ro6JyIZEHlGdF3mApAo0-BKlM53p5O2Qhd75g=.5ccb1b9a-9296-46e3-9f40-01f77d3741c3@github.com>
Message-ID: <5tk2xsof4lVGbJesgdI8htGfmuLVjyuHmnMWUpVP3J8=.11d69ae6-fa96-4115-b768-cbe49b2dea9b@github.com>

On Wed, 13 Aug 2025 11:19:58 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> Renamed usage of 'category' for 'MemTag' cases.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reverted some renamings

HotSpot code and test changes require 2 reviewers including one (R)eviewer. GitHub shows you the commit message that it is going to use and if it does not show 2 names, then you need to get a second reviewer.

Of course, if you propose that a PR is trivial AND your (R)eviewer concurs, then you can integrate with one reviewer.

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

PR Comment: https://git.openjdk.org/jdk/pull/25226#issuecomment-3207608308

From snatarajan at openjdk.org  Wed Aug 20 20:21:08 2025
From: snatarajan at openjdk.org (Saranya Natarajan)
Date: Wed, 20 Aug 2025 20:21:08 GMT
Subject: RFR: 8358696: Assert with extreme values for -XX:BciProfileWidth
 [v11]
In-Reply-To: <5TRVeAXUQi6quM-nDWEij_jk6M5K2Vk31RA-Yjd8F2M=.5b63da45-93c3-4251-9e2e-3c64b7953919@github.com>
References: <5TRVeAXUQi6quM-nDWEij_jk6M5K2Vk31RA-Yjd8F2M=.5b63da45-93c3-4251-9e2e-3c64b7953919@github.com>
Message-ID: <sgsCVJZyBuFTDNQuZbG_z6BQZVqhfDKbrtSN0flpntA=.3bbd7e00-0f03-44de-9444-d27f6c69bc16@github.com>

> **Issue**
> Extreme values for BciProfileWidth flag such as `java -XX:BciProfileWidth=-1 -version` and `java -XX:BciProfileWidth=100000 -version `results in assert failure `assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x0000772b63a7a3a0 <= 0x0000772b63b75159 <= 0x0000772b63b75158 `. This is observed in a x86 machine.
> 
> **Analysis** 
>  On debugging the issue, I found that increasing the size of the interpreter using the `InterpreterCodeSize` variable in `src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp` prevented the above mentioned assert from failing for large values of BciProfileWidth.  
> 
> **Proposal** 
> Considering the fact that larger BciProfileWidth results in slower profiling, I have proposed a range between 0 to 5000 to restrict the value for BciProfileWidth for x86 machines. This maximum value is based on modifying the `InterpreterCodeSize` variable in `src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp` using the smallest `InterpreterCodeSize` for all the architectures.  As for the lower bound, a value of -1 would be the same as 0, as this simply means  no  return bci's will be recorded in ret profile. 
> 
> **Issue in AArch64**
> Additionally running the command `java -XX:BciProfileWidth= 10000 -version` (or larger values) results in a different failure  `assert(offset_ok_for_immed(offset(), size)) failed: must be, was: 32768, 3` on an AArch64 machine.This is an issue of maximum offset for `ldr/str` in AArch64 which can be fixed using `form_address`  as mentioned in [JDK-8342736](https://bugs.openjdk.org/browse/JDK-8342736). In my preliminary fix using `form_address` on AArch64 machine. I had to modify 3 `ldr` and 1 `str` instruction (in file `src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp` at line number 926, 983, and 997). With this fix  using `form_address`, `BciProfileWidth` works for maximum of 5000 after which it crashes with`assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x0000772b63a7a3a0 <= 0x0000772b63b75159 <= 0x0000772b63b75158 `.  Without this fix `BciProfileWidth` works for a maximum value of 1300.   Currently, I have suggested to restrict the upper bound on AArch64 to 1000 instead 
 of fixing it with `form_address`. 
> 
> **Question to reviewers**
> Do you think this is a reasonable fix ?  For AArch64 do you suggest fixing using `form_address` ? If yes, do I fix it under this PR or create another one ?
> 
> **Request to port maintainers**
> @dafedafe suggested that we keep the upper bound of `BciProfileWidth` to 1000 pro...

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

  addressing review - fixing indentation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26139/files
  - new: https://git.openjdk.org/jdk/pull/26139/files/4f6ad175..6cb9e98b

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

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

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

From snatarajan at openjdk.org  Wed Aug 20 20:23:45 2025
From: snatarajan at openjdk.org (Saranya Natarajan)
Date: Wed, 20 Aug 2025 20:23:45 GMT
Subject: RFR: 8358696: Assert with extreme values for -XX:BciProfileWidth
 [v11]
In-Reply-To: <60sgN5hitLgZGw3LHfU7GoQ9NWQA31D1Q_RUjjMiOqI=.1110e1b5-8560-4cd8-a695-5b3aa43af4c9@github.com>
References: <5TRVeAXUQi6quM-nDWEij_jk6M5K2Vk31RA-Yjd8F2M=.5b63da45-93c3-4251-9e2e-3c64b7953919@github.com>
 <-SMEjFj6yBqm_pNlCxGL9l5sBegIXLyz28nPhdcW-6U=.06a121a1-ce40-4bc0-89c4-bb1dbe90c489@github.com>
 <fut6Bu2BFN_CHZz5lcti9FugPVV7_lGxPNLkm-mpdEE=.f2ca934f-cb83-46fc-9533-544f76a1749b@github.com>
 <60sgN5hitLgZGw3LHfU7GoQ9NWQA31D1Q_RUjjMiOqI=.1110e1b5-8560-4cd8-a695-5b3aa43af4c9@github.com>
Message-ID: <ZSVzFiFr2JcElqv4K_5KDY7ouPTfcCg6XQyk9QbnXm8=.700277c9-0765-4e13-ba5b-f89b889cdfb5@github.com>

On Wed, 20 Aug 2025 15:30:19 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> test/lib-test/jdk/test/whitebox/vm_flags/IntxTest.java line 42:
>> 
>>> 40:     private static final long COMPILE_THRESHOLD = VmFlagTest.WHITE_BOX.getIntxVMFlag("CompileThreshold");
>>> 41:     private static final Long[] TESTS = {0L, 100L, (long)(Integer.MAX_VALUE>>3)*100L};
>>> 42: 
>> 
>> This empty line should not be removed.
>
> Thanks! But, the indentation of the next line looks odd, now.

Sorry. I have fixed this now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26139#discussion_r2289211759

From dholmes at openjdk.org  Wed Aug 20 20:56:37 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 20 Aug 2025 20:56:37 GMT
Subject: RFR: 8364352: Some tests fail when using a limited number of
 pregenerated .jsa CDS archives
In-Reply-To: <EnyzXiapmd29T3spHQT7QTBv2SVQVKVU6L2NEDoejHg=.65f803f7-09e0-4e5b-ac21-a60474c5facd@github.com>
References: <EnyzXiapmd29T3spHQT7QTBv2SVQVKVU6L2NEDoejHg=.65f803f7-09e0-4e5b-ac21-a60474c5facd@github.com>
Message-ID: <GtNL83Xo_ncqcYTVTO4Qz0pby8BvHeKe9pmptdFQLd4=.6902d787-ed68-420e-901b-56f88fe482f5@github.com>

On Mon, 18 Aug 2025 11:34:28 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently the default JVM comes on most platforms with 4 jsa files (for coops and nocoops; with and without compressed object headers), but for some shipments the number of jsa could be reduced (see also Images.gmk) .
> But not all tests can deal with this.
> Namely
> 
> test/hotspot/jtreg/runtime/CompressedOops/CompressedCPUSpecificClassSpaceReservation.java
> test/hotspot/jtreg/runtime/cds/TestDefaultArchiveLoading.java
> test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java (custom-cl-zgc)
> 
> were found to have issues.
> There is already a requires  `vm.cds.default.archive.available`   that is used in similar tests and can be used in some of those cases too.

test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java line 58:

> 56:  * @test id=custom-cl-zgc
> 57:  * @requires vm.cds.custom.loaders
> 58:  * @requires vm.cds.default.archive.available

Don't understand this one. This test is hard to follow but I think it does its own dumping of the CDS archive, so I don't see why it would need the default archive to exist. ???

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26820#discussion_r2289274145

From dlong at openjdk.org  Wed Aug 20 23:42:59 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 20 Aug 2025 23:42:59 GMT
Subject: RFR: 8358696: Assert with extreme values for -XX:BciProfileWidth
 [v11]
In-Reply-To: <sgsCVJZyBuFTDNQuZbG_z6BQZVqhfDKbrtSN0flpntA=.3bbd7e00-0f03-44de-9444-d27f6c69bc16@github.com>
References: <5TRVeAXUQi6quM-nDWEij_jk6M5K2Vk31RA-Yjd8F2M=.5b63da45-93c3-4251-9e2e-3c64b7953919@github.com>
 <sgsCVJZyBuFTDNQuZbG_z6BQZVqhfDKbrtSN0flpntA=.3bbd7e00-0f03-44de-9444-d27f6c69bc16@github.com>
Message-ID: <ArMMBmwIrELUVJC-CbHROAgjdAdA0Y_fjOMqa1wKiM0=.2c675809-0e36-4056-a53b-b8bde334df0d@github.com>

On Wed, 20 Aug 2025 20:21:08 GMT, Saranya Natarajan <snatarajan at openjdk.org> wrote:

>> **Issue**
>> Extreme values for BciProfileWidth flag such as `java -XX:BciProfileWidth=-1 -version` and `java -XX:BciProfileWidth=100000 -version `results in assert failure `assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x0000772b63a7a3a0 <= 0x0000772b63b75159 <= 0x0000772b63b75158 `. This is observed in a x86 machine.
>> 
>> **Analysis** 
>>  On debugging the issue, I found that increasing the size of the interpreter using the `InterpreterCodeSize` variable in `src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp` prevented the above mentioned assert from failing for large values of BciProfileWidth.  
>> 
>> **Proposal** 
>> Considering the fact that larger BciProfileWidth results in slower profiling, I have proposed a range between 0 to 5000 to restrict the value for BciProfileWidth for x86 machines. This maximum value is based on modifying the `InterpreterCodeSize` variable in `src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp` using the smallest `InterpreterCodeSize` for all the architectures.  As for the lower bound, a value of -1 would be the same as 0, as this simply means  no  return bci's will be recorded in ret profile. 
>> 
>> **Issue in AArch64**
>> Additionally running the command `java -XX:BciProfileWidth= 10000 -version` (or larger values) results in a different failure  `assert(offset_ok_for_immed(offset(), size)) failed: must be, was: 32768, 3` on an AArch64 machine.This is an issue of maximum offset for `ldr/str` in AArch64 which can be fixed using `form_address`  as mentioned in [JDK-8342736](https://bugs.openjdk.org/browse/JDK-8342736). In my preliminary fix using `form_address` on AArch64 machine. I had to modify 3 `ldr` and 1 `str` instruction (in file `src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp` at line number 926, 983, and 997). With this fix  using `form_address`, `BciProfileWidth` works for maximum of 5000 after which it crashes with`assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x0000772b63a7a3a0 <= 0x0000772b63b75159 <= 0x0000772b63b75158 `.  Without this fix `BciProfileWidth` works for a maximum value of 1300.   Currently, I have suggested to restrict the upper bound on AArch64 to 1000 instead
  of fixing it with `form_address`. 
>> 
>> **Question to reviewers**
>> Do you think this is a reasonable fix ?  For AArch64 do you suggest fixing using `form_address` ? If yes, do I fix it under this PR or create another one ?
>> 
>> **Request to port maintainers**
>> @dafedafe suggested that we keep the upper boun...
>
> Saranya Natarajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressing review - fixing indentation

If we wanted to decrease the code size, we could change the unrolled loop to a real loop.  But I think first we should answer the question, why are we profiling "ret" instructions at all?  As far as I can tell, the compilers are not using the profiling data for anything, so maybe we could just remove it.

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

PR Comment: https://git.openjdk.org/jdk/pull/26139#issuecomment-3208458542

From ysuenaga at openjdk.org  Thu Aug 21 00:14:52 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 21 Aug 2025 00:14:52 GMT
Subject: RFR: 8365633: Incorrect info is reported on hybrid CPU [v2]
In-Reply-To: <JCK35OXc5UU8BQx8GRfQN4YRg_IxztlBIUWeQg_ZjMU=.f32985ce-5f58-46f4-8973-d7efbe76514e@github.com>
References: <T2R7vtbL0AaZLcRKdAPjoM6I8kz6lclHBNnOXi8JIQY=.1af945fd-1592-423a-8a19-940dd1c531d3@github.com>
 <xeZsXlz_VUer4L2XraArNgofAegPxFvrpikCFdhYCBc=.8d7c0ac7-bd90-4e3b-b4db-461ee19db60a@github.com>
 <JCK35OXc5UU8BQx8GRfQN4YRg_IxztlBIUWeQg_ZjMU=.f32985ce-5f58-46f4-8973-d7efbe76514e@github.com>
Message-ID: <ib48_HG9jOGypNfz5wOVNxNpozWhaijMbTl2vlPLgN8=.c4efa25d-1e3d-4b76-995c-6cdba9344061@github.com>

On Wed, 20 Aug 2025 12:33:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

> `(14 threads)` is just as wrong as it implies 1 processor/core with 14 threads.

I don't think so because I think it does not contain neither "per core", thus it implies "total number of threads is 14".

However I don't stick to show number of threads on hybrid CPU because the user can refer data sheet from processor model name. I think it can be changed to nothing to show or "14 threads per processor" for clarification. Which do you like?

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

PR Comment: https://git.openjdk.org/jdk/pull/26808#issuecomment-3208514020

From dholmes at openjdk.org  Thu Aug 21 00:19:54 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 21 Aug 2025 00:19:54 GMT
Subject: RFR: 8263476: Use reserved memory for stack guard pages [v4]
In-Reply-To: <HyFMbg_ptvNbb4y3mufJuL2_x-UTrMWgmt3crjBld-Q=.dfbfe1d5-1bad-47f6-adf2-140afaf01e3c@github.com>
References: <BojYWaP10BJMEWDQYSRiMKR0cOWzMF5At9_3fwD6uUw=.becf6902-01f1-41e0-965d-18a945a6dfcf@github.com>
 <Kwrb1dkkecP2tFGM7IZxYiKN_9ke4u5xtje3G05V5H0=.9d830cad-a360-4fc0-a4a5-2fe6e01f0b91@github.com>
 <CxqLDWolGPMO_jg80yr-u08_cRBfPtIKRI5ewf8k7WU=.95281f2b-6716-4ee9-8df9-2cdd7e623d46@github.com>
 <rjIgNraKjfcDUQKw8zvy3jfLXy1tDk7seOMAYRO9y4g=.081ddad1-f540-4f07-827c-3017dd995f25@github.com>
 <HyFMbg_ptvNbb4y3mufJuL2_x-UTrMWgmt3crjBld-Q=.dfbfe1d5-1bad-47f6-adf2-140afaf01e3c@github.com>
Message-ID: <9TOE9KMqPT4A2KDPGqGvLaIV8-iIvJkglS-ZErsVR5I=.82057acc-2e12-439e-b180-8af9000598e7@github.com>

On Wed, 6 Aug 2025 09:05:47 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Aha, now I understand. The diagram helped a lot!
>
> I don't think we should make this change, since it introduces a subtle bug.
> 
> Apart from being hard to understand, it also opens a time window where the stack guard pages are unmapped; at line 3478, we re-establish MAP_NORESERVE mapping here, but in this time window someone else may have mapped pages in there. Now someone lives in our stack. The reservation will fail, we return false, write a "cannot establish guard pages" warning. If the primordial thread stack grows into this region, it will overwrite that misplaced memory. Errors would be very rare and intermittent.
> 
> Apart from all that, it also means that we add two unnecessary calls to mmap to likely every startup, since the condition at line 3475 is now likely always true. 
> 
> Pre-existing: to be honest, I have no idea why we even do the munmap in the first place. Why would it matter if the primordial thread stack is larger than what we think it should be?

@tstuefe the comment prior to `os::pd_create_stack_guard_pages` is explaining why the munmap is needed.

@albertnetymk  even with the diagram I do not understand this aspect of the change: why do we now need to check `addr+size`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26571#discussion_r2289573186

From iklam at openjdk.org  Thu Aug 21 01:01:54 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 21 Aug 2025 01:01:54 GMT
Subject: RFR: 8365814: Consolidate has_been_archived() and
 has_been_buffered() in ArchiveBuilder
In-Reply-To: <F7u5rGal7Kh4KZz1RGjeWPDvXD_rqKO1lySjtWiaH6M=.b9ba5536-a5d6-4f92-8b38-603ddcf1463d@github.com>
References: <CjcbzPgOlwDABX6nFwnR4TgkD-FcK8VSXZuz5tsSNJE=.ee6b4d03-9855-4bbd-9031-4a657dda358e@github.com>
 <F7u5rGal7Kh4KZz1RGjeWPDvXD_rqKO1lySjtWiaH6M=.b9ba5536-a5d6-4f92-8b38-603ddcf1463d@github.com>
Message-ID: <3i3MuMxtUXzV-XEZylDgQV9MCCGOF8at-HH0Ls6w2lo=.5bdec7cb-2bc6-45d0-9e6a-b13b05851208@github.com>

On Wed, 20 Aug 2025 13:22:32 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Merged the two methods into one: `ArchiveBuilder::has_been_archived()`. Added comments and asserts to explain what the expected result is.
>
> src/hotspot/share/cds/archiveBuilder.hpp line 448:
> 
>> 446:   bool has_been_archived(address src_addr) const;
>> 447:   template <typename T> bool has_been_archived(T src_addr) const {
>> 448:     return has_been_archived((address)src_addr);
> 
> What's the point of having a template if you're going to erase the type?

I did it this way so the caller doesn't need to do casting like


Method* m = xxx();
if (has_been_archived((address)m)) {.....}


Is there a better way to indicate that `has_been_archived()` takes any pointer?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26853#discussion_r2289619230

From dholmes at openjdk.org  Thu Aug 21 01:10:52 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 21 Aug 2025 01:10:52 GMT
Subject: RFR: 8353468: [ubsan] arguments.cpp:2422:23: runtime error:
 2.14748e+11 is outside the range of representable values of type 'int'
In-Reply-To: <plQ5n7EjsekIjeY431_mBeo4rfcH39SVdPWogF2rT44=.20180c89-665e-4054-8625-1b04f8306b3b@github.com>
References: <plQ5n7EjsekIjeY431_mBeo4rfcH39SVdPWogF2rT44=.20180c89-665e-4054-8625-1b04f8306b3b@github.com>
Message-ID: <jCtrRSFlt_pDKCkLKgYe36euKd1OSsIO2x08OsWZRBw=.69e2435f-59b6-41da-87ef-73619de715ff@github.com>

On Wed, 20 Aug 2025 12:12:01 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> In converting values of `-XMinf` and `-XMaxf` options to `int`, overflow was not checked. 
> The values are checked against INT_MAX and clamped.
> 
> Tests: tiers 1-5.

I guess this keeps ubsan happy. The constraint function for the actual globals will reject anything outside the range 1..100.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26859#pullrequestreview-3138705180

From dholmes at openjdk.org  Thu Aug 21 02:28:51 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 21 Aug 2025 02:28:51 GMT
Subject: RFR: 8365633: Incorrect info is reported on hybrid CPU [v2]
In-Reply-To: <ib48_HG9jOGypNfz5wOVNxNpozWhaijMbTl2vlPLgN8=.c4efa25d-1e3d-4b76-995c-6cdba9344061@github.com>
References: <T2R7vtbL0AaZLcRKdAPjoM6I8kz6lclHBNnOXi8JIQY=.1af945fd-1592-423a-8a19-940dd1c531d3@github.com>
 <xeZsXlz_VUer4L2XraArNgofAegPxFvrpikCFdhYCBc=.8d7c0ac7-bd90-4e3b-b4db-461ee19db60a@github.com>
 <JCK35OXc5UU8BQx8GRfQN4YRg_IxztlBIUWeQg_ZjMU=.f32985ce-5f58-46f4-8973-d7efbe76514e@github.com>
 <ib48_HG9jOGypNfz5wOVNxNpozWhaijMbTl2vlPLgN8=.c4efa25d-1e3d-4b76-995c-6cdba9344061@github.com>
Message-ID: <s77wxOBUOy0g0N7t6LSfcjBVA3yojDf_razmJvN_wpU=.f50cd5a2-5427-4e03-8185-b49bcbd18e45@github.com>

On Thu, 21 Aug 2025 00:12:12 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> > `(14 threads)` is just as wrong as it implies 1 processor/core with 14 threads.
> 
> I don't think so because I think it does not contain neither "per core", thus it implies "total number of threads is 14".
> 
> However I don't stick to show number of threads on hybrid CPU because the user can refer data sheet from processor model name. I think it can be changed to nothing to show or "14 threads per processor" for clarification. Which do you like?

I prefer nothing - thanks. "threads" is generally understood to be a sub-unit of "cores" which are a sub-unit of "processors", which might be a sub-unit of "sockets".

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

PR Comment: https://git.openjdk.org/jdk/pull/26808#issuecomment-3208778346

From dholmes at openjdk.org  Thu Aug 21 03:04:49 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 21 Aug 2025 03:04:49 GMT
Subject: RFR: 8365673: Incorrect number of cores are reported on Ryzen CPU
In-Reply-To: <BjQ9knzbbefSqRxv6jHHcy1HzSflVSYQvlSQKlt3AF8=.ae3685bd-87c1-45b0-a1ad-6e630bfe9af9@github.com>
References: <BjQ9knzbbefSqRxv6jHHcy1HzSflVSYQvlSQKlt3AF8=.ae3685bd-87c1-45b0-a1ad-6e630bfe9af9@github.com>
Message-ID: <KvuWVVkleJDQplK-e5njpat2XfZfhDX5zoxqnfQqmT8=.563490d3-a998-4eee-9725-43b0fa2de4af@github.com>

On Mon, 18 Aug 2025 10:01:46 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> According to [Programmer's Manual by AMD](https://docs.amd.com/v/u/en-US/40332-PUB_4.08), Bit 7:0 in ECX from CPUID leaf 80000008h means number of threads, not cores. Thus we should divide it by threads per core.

That appears to be a documentation errata that was fixed in June 2023 i.e it used to say "cores" (hence the NC name) but now it says "physical threads". I'm not sure the meaning actually changed based on the chip family (`if (cpu_family() >= 0x17) `) but rather should always be interpreted as number-of-threads no matter which chip you have. Unfortunately I/we have no way to test this across a range of AMD chips!

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

PR Comment: https://git.openjdk.org/jdk/pull/26819#issuecomment-3208834587

From aboldtch at openjdk.org  Thu Aug 21 05:07:04 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 21 Aug 2025 05:07:04 GMT
Subject: RFR: 8365146: Remove LockingMode related code from ppc64 [v3]
In-Reply-To: <ztFaCjEU6WEEUGFuZ6TvP57rwOQY9X4K64jJCXtOTI0=.d132f09c-c076-4ef2-8136-421be62d31d8@github.com>
References: <mKtlz6j_OunSKwTrSfwVxcErf8oTsclqe65OSJxXvlw=.b958a3bc-0253-4efd-a9ff-03ac0418ba23@github.com>
 <ztFaCjEU6WEEUGFuZ6TvP57rwOQY9X4K64jJCXtOTI0=.d132f09c-c076-4ef2-8136-421be62d31d8@github.com>
Message-ID: <qEFsQmkGEge9bztLFpE-xlid9AfunIMStXJtQGyMO2E=.2c8f7526-3a38-4f04-99aa-34096bcb970a@github.com>

On Wed, 20 Aug 2025 09:05:09 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
>> 
>> This PR removes `LockingMode` related code from the **ppc64** platform.
>> 
>> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.
>
> Fredrik Bredberg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into 8365146_remove_lockingmode_ppc64
>  - Update after review
>  - Merge branch 'master' into 8365146_remove_lockingmode_ppc64
>  - 8365146: Remove LockingMode related code from ppc64

Marked as reviewed by aboldtch (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26697#pullrequestreview-3139031777

From ysuenaga at openjdk.org  Thu Aug 21 06:29:30 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 21 Aug 2025 06:29:30 GMT
Subject: RFR: 8365633: Incorrect info is reported on hybrid CPU [v3]
In-Reply-To: <T2R7vtbL0AaZLcRKdAPjoM6I8kz6lclHBNnOXi8JIQY=.1af945fd-1592-423a-8a19-940dd1c531d3@github.com>
References: <T2R7vtbL0AaZLcRKdAPjoM6I8kz6lclHBNnOXi8JIQY=.1af945fd-1592-423a-8a19-940dd1c531d3@github.com>
Message-ID: <fuLI01E7pxwaoN4Xh8V9mxnszNv37LnlXWdGR1wuMQw=.f3d7fb2f-9a73-4ff9-b0b0-3f27b2d792cc@github.com>

> `VM.info` DCmd reports CPU information. I ran this on Intel Core Ultra 5 225U , then I got following result:
> 
> 
> CPU: total 14 (initial active 14) (7 cores per cpu, 2 threads per core) family 6 model 181 stepping 0 microcode 0xffffffff, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, clwb, hv, serialize, rdtscp, rdpid, fsrm, gfni, f16c, cet_ibt, cet_ss
> CPU Model and flags from /proc/cpuinfo:
> model name : Intel(R) Core(TM) Ultra 5 225U
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm pni pclmulqdq monitor est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave osxsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch fsgsbase bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb intel_pt sha_ni umip gfni vaes vpclmulqdq rdpid ibrs ibpb stibp ssbd
> 
> 
> It reports "7 cores per cpu, 2 threads per core". 225U has hybrid architecture - 2 P cores, 8 E cores, 2 LP cores, and also P core has 2 threads per core. Then it should be "12 cores, 14 threads".
> https://www.intel.com/content/www/us/en/products/sku/241861/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html
> 
> According to Intel Software Developer's Manual, it seems to be difficult to get number of physical cores. In Linux kernel, it seems to be calculated by complex logic: https://github.com/torvalds/linux/blob/v6.16/arch/x86/kernel/smpboot.c#L567-L597
> In addition, all of P cores might not be enabled HT. Thus to show only number of threads is reasonable at this point.

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

  Remove number of threads on hybrid CPU

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26808/files
  - new: https://git.openjdk.org/jdk/pull/26808/files/234a67b6..b1fd242c

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

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

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

From ysuenaga at openjdk.org  Thu Aug 21 06:29:31 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 21 Aug 2025 06:29:31 GMT
Subject: RFR: 8365633: Incorrect info is reported on hybrid CPU [v2]
In-Reply-To: <s77wxOBUOy0g0N7t6LSfcjBVA3yojDf_razmJvN_wpU=.f50cd5a2-5427-4e03-8185-b49bcbd18e45@github.com>
References: <T2R7vtbL0AaZLcRKdAPjoM6I8kz6lclHBNnOXi8JIQY=.1af945fd-1592-423a-8a19-940dd1c531d3@github.com>
 <xeZsXlz_VUer4L2XraArNgofAegPxFvrpikCFdhYCBc=.8d7c0ac7-bd90-4e3b-b4db-461ee19db60a@github.com>
 <JCK35OXc5UU8BQx8GRfQN4YRg_IxztlBIUWeQg_ZjMU=.f32985ce-5f58-46f4-8973-d7efbe76514e@github.com>
 <ib48_HG9jOGypNfz5wOVNxNpozWhaijMbTl2vlPLgN8=.c4efa25d-1e3d-4b76-995c-6cdba9344061@github.com>
 <s77wxOBUOy0g0N7t6LSfcjBVA3yojDf_razmJvN_wpU=.f50cd5a2-5427-4e03-8185-b49bcbd18e45@github.com>
Message-ID: <Ci8_ma7WvgKlP9KN-exqvmUDdXE-o7PUzDqyTA_5oLw=.c1371070-591d-465c-9ede-5ffce93d17ff@github.com>

On Thu, 21 Aug 2025 02:25:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> `(14 threads)` is just as wrong as it implies 1 processor/core with 14 threads.
>> 
>> I don't think so because I think it does not contain neither "per core", thus it implies "total number of threads is 14".
>> 
>> However I don't stick to show number of threads on hybrid CPU because the user can refer data sheet from processor model name. I think it can be changed to nothing to show or "14 threads per processor" for clarification. Which do you like?
>
>> > `(14 threads)` is just as wrong as it implies 1 processor/core with 14 threads.
>> 
>> I don't think so because I think it does not contain neither "per core", thus it implies "total number of threads is 14".
>> 
>> However I don't stick to show number of threads on hybrid CPU because the user can refer data sheet from processor model name. I think it can be changed to nothing to show or "14 threads per processor" for clarification. Which do you like?
> 
> I prefer nothing - thanks. "threads" is generally understood to be a sub-unit of "cores" which are a sub-unit of "processors", which might be a sub-unit of "sockets".

I removed number of threads information on hybrid CPU. @dholmes-ora Can you review?  
We can get following strings on hybrid CPU after this change:


CPU: total 14 (initial active 14)  family 6 model 181 stepping 0 microcode 0xffffffff, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, clwb, hv, serialize, rdtscp, rdpid, fsrm, gfni, f16c, cet_ibt, cet_ss, hybrid
CPU Model and flags from /proc/cpuinfo:
model name      : Intel(R) Core(TM) Ultra 5 225U

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

PR Comment: https://git.openjdk.org/jdk/pull/26808#issuecomment-3209164534

From ysuenaga at openjdk.org  Thu Aug 21 06:52:51 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 21 Aug 2025 06:52:51 GMT
Subject: RFR: 8365673: Incorrect number of cores are reported on Ryzen CPU
In-Reply-To: <KvuWVVkleJDQplK-e5njpat2XfZfhDX5zoxqnfQqmT8=.563490d3-a998-4eee-9725-43b0fa2de4af@github.com>
References: <BjQ9knzbbefSqRxv6jHHcy1HzSflVSYQvlSQKlt3AF8=.ae3685bd-87c1-45b0-a1ad-6e630bfe9af9@github.com>
 <KvuWVVkleJDQplK-e5njpat2XfZfhDX5zoxqnfQqmT8=.563490d3-a998-4eee-9725-43b0fa2de4af@github.com>
Message-ID: <55ZEwg9gcFmnPis8F_FxnzKYBoZcz49BY_ecF3KZWbc=.94ebfa86-d276-4a7f-a838-6b02d4485781@github.com>

On Thu, 21 Aug 2025 03:02:23 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I'm not sure the meaning actually changed based on the chip family (`if (cpu_family() >= 0x17)` )

I made the change in `VM_Version::cores_per_cpu()`, however this function calls from `threads_per_core()` in some case as following. To prevent recursive call, I add a condition for CPU family. SMT (equivalent with HT in Intel) seems to be introduced in Zen architecture (family `17h`), thus this logic should work.


uint VM_Version::threads_per_core() {
  uint result = 1;
  if (is_intel() && supports_processor_topology()) {
    result = _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus;
  } else if (is_zx() && supports_processor_topology()) {
    result = _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus;
  } else if (_cpuid_info.std_cpuid1_edx.bits.ht != 0) {
    if (cpu_family() >= 0x17) {
      result = _cpuid_info.ext_cpuid1E_ebx.bits.threads_per_core + 1;
    } else {
      result = _cpuid_info.std_cpuid1_ebx.bits.threads_per_cpu /
                 cores_per_cpu();
    }
  }
  return (result == 0 ? 1 : result);
}

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

PR Comment: https://git.openjdk.org/jdk/pull/26819#issuecomment-3209226406

From stefank at openjdk.org  Thu Aug 21 07:48:54 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 21 Aug 2025 07:48:54 GMT
Subject: RFR: 8353468: [ubsan] arguments.cpp:2422:23: runtime error:
 2.14748e+11 is outside the range of representable values of type 'int'
In-Reply-To: <plQ5n7EjsekIjeY431_mBeo4rfcH39SVdPWogF2rT44=.20180c89-665e-4054-8625-1b04f8306b3b@github.com>
References: <plQ5n7EjsekIjeY431_mBeo4rfcH39SVdPWogF2rT44=.20180c89-665e-4054-8625-1b04f8306b3b@github.com>
Message-ID: <k9IUTdCiIKbbfQrHRBzeoLtk-IjvddnRfqeUl9fbTBs=.f69be724-67a1-4e31-9aea-025a2c58620d@github.com>

On Wed, 20 Aug 2025 12:12:01 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> In converting values of `-XMinf` and `-XMaxf` options to `int`, overflow was not checked. 
> The values are checked against INT_MAX and clamped.
> 
> Tests: tiers 1-5.

The failing TestHeapFreeRatio.java test tests with an extreme positive value (2147483647), but it doesn't test with an extreme negative value:


  public static void main(String args[]) throws Exception {
    testMinMaxFreeRatio( "0.1", "0.5", Validation.VALID);
    testMinMaxFreeRatio(  ".1",  ".5", Validation.VALID);
    testMinMaxFreeRatio( "0.5", "0.5", Validation.VALID);

    testMinMaxFreeRatio("=0.1", "0.5", Validation.MIN_INVALID);
    testMinMaxFreeRatio("0.1f", "0.5", Validation.MIN_INVALID);
    testMinMaxFreeRatio(
                     "INVALID", "0.5", Validation.MIN_INVALID);

    testMinMaxFreeRatio( "0.1", "0.5f", Validation.MAX_INVALID);
    testMinMaxFreeRatio( "0.1", "=0.5", Validation.MAX_INVALID);
    testMinMaxFreeRatio(
                     "0.1",  "INVALID", Validation.MAX_INVALID);

    testMinMaxFreeRatio("-0.1", "0.5", Validation.OUT_OF_RANGE);
    testMinMaxFreeRatio( "1.1", "0.5", Validation.OUT_OF_RANGE);
    testMinMaxFreeRatio(
                  "2147483647", "0.5", Validation.OUT_OF_RANGE);
    testMinMaxFreeRatio( "0.1", "-0.5", Validation.OUT_OF_RANGE);
    testMinMaxFreeRatio( "0.1",  "1.5", Validation.OUT_OF_RANGE);
    testMinMaxFreeRatio(
                   "0.1", "2147483647", Validation.OUT_OF_RANGE);

    testMinMaxFreeRatio( "0.5",  "0.1", Validation.COMBINATION_INVALID);
    testMinMaxFreeRatio(  ".5",  ".10", Validation.COMBINATION_INVALID);
    testMinMaxFreeRatio("0.12","0.100", Validation.COMBINATION_INVALID);
  }


Would ubsan hit a similar value if it did and would you have to guard against INT_MIN as well?

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

PR Comment: https://git.openjdk.org/jdk/pull/26859#issuecomment-3209395616

From fbredberg at openjdk.org  Thu Aug 21 07:50:07 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 21 Aug 2025 07:50:07 GMT
Subject: RFR: 8365146: Remove LockingMode related code from ppc64 [v3]
In-Reply-To: <ztFaCjEU6WEEUGFuZ6TvP57rwOQY9X4K64jJCXtOTI0=.d132f09c-c076-4ef2-8136-421be62d31d8@github.com>
References: <mKtlz6j_OunSKwTrSfwVxcErf8oTsclqe65OSJxXvlw=.b958a3bc-0253-4efd-a9ff-03ac0418ba23@github.com>
 <ztFaCjEU6WEEUGFuZ6TvP57rwOQY9X4K64jJCXtOTI0=.d132f09c-c076-4ef2-8136-421be62d31d8@github.com>
Message-ID: <qXOIER-kE6KhasezFVqQSo2kbtJ_XPH7Yfet4BFs0lM=.227430ef-35cf-4549-9b00-2501c7d8cf88@github.com>

On Wed, 20 Aug 2025 09:05:09 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
>> 
>> This PR removes `LockingMode` related code from the **ppc64** platform.
>> 
>> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.
>
> Fredrik Bredberg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into 8365146_remove_lockingmode_ppc64
>  - Update after review
>  - Merge branch 'master' into 8365146_remove_lockingmode_ppc64
>  - 8365146: Remove LockingMode related code from ppc64

Thank you for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/26697#issuecomment-3209394286

From fbredberg at openjdk.org  Thu Aug 21 07:50:07 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 21 Aug 2025 07:50:07 GMT
Subject: Integrated: 8365146: Remove LockingMode related code from ppc64
In-Reply-To: <mKtlz6j_OunSKwTrSfwVxcErf8oTsclqe65OSJxXvlw=.b958a3bc-0253-4efd-a9ff-03ac0418ba23@github.com>
References: <mKtlz6j_OunSKwTrSfwVxcErf8oTsclqe65OSJxXvlw=.b958a3bc-0253-4efd-a9ff-03ac0418ba23@github.com>
Message-ID: <yRhmR5nQST6lj9JKAhiVUKqO1o8rNwkngJssiO57I38=.e4ac7e73-c3a7-4b58-9a35-59e83e19484a@github.com>

On Fri, 8 Aug 2025 12:53:10 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
> 
> This PR removes `LockingMode` related code from the **ppc64** platform.
> 
> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.

This pull request has now been integrated.

Changeset: a7c0f4b8
Author:    Fredrik Bredberg <fbredberg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a7c0f4b845c314099966f5669bfc7947bdf28004
Stats:     632 lines in 8 files changed: 1 ins; 579 del; 52 mod

8365146: Remove LockingMode related code from ppc64

Reviewed-by: aboldtch, mdoerr

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

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

From asemenov at openjdk.org  Thu Aug 21 09:01:12 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 21 Aug 2025 09:01:12 GMT
Subject: RFR: 8365604: Null pointer dereference in
 src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() [v2]
In-Reply-To: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
Message-ID: <clP7ORnQOS8o0QhYs7DyuOLjQ-bPKch1dK1hDqPzzaI=.9b61fd70-4622-4344-aea6-8661fb57427c@github.com>

> The defect has been detected and confirmed in the function ArchDesc::declareClasses() located in the file src/hotspot/share/adlc/output_h.cpp with static code analysis. This defect can potentially lead to a null pointer dereference.
> 
> The pointer instr->_matrule is dereferenced in line 1952 without checking for nullptr, although earlier in line 1858 the same pointer is checked for nullptr, which indicates that it can be null.
> 
> According to [this](https://github.com/openjdk/jdk/pull/26002#issuecomment-3023050372) comment, this PR contains fixes for similar cases in other places.

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

 - Update src/hotspot/share/c1/c1_LinearScan.cpp
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
 - Update src/hotspot/share/adlc/output_h.cpp
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26798/files
  - new: https://git.openjdk.org/jdk/pull/26798/files/80777ced..dd21148b

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

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

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

From asemenov at openjdk.org  Thu Aug 21 09:11:53 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 21 Aug 2025 09:11:53 GMT
Subject: RFR: 8365604: Null pointer dereference in
 src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() [v2]
In-Reply-To: <m-aR302_Qm6Np3fyTAaw5RB2q6t1vMW4vEolOaVueKo=.ff55cc84-9167-473a-af27-95becf011732@github.com>
References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
 <m-aR302_Qm6Np3fyTAaw5RB2q6t1vMW4vEolOaVueKo=.ff55cc84-9167-473a-af27-95becf011732@github.com>
Message-ID: <ftJY3jOzJsWM_Aq9WpMjcrn3uR4e9cs_dS9ibkfu3c4=.6b8bbd93-e8e1-4000-8d24-42d40ddd5c11@github.com>

On Wed, 20 Aug 2025 12:20:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Artem Semenov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update src/hotspot/share/c1/c1_LinearScan.cpp
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>>  - Update src/hotspot/share/adlc/output_h.cpp
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>
> src/hotspot/share/nmt/mallocSiteTable.cpp line 172:
> 
>> 170:        index < pos_idx && head != nullptr;
>> 171:        index++, head = ((MallocSiteHashtableEntry*)head->next() == nullptr) ? head :
>> 172:       (MallocSiteHashtableEntry*)head->next()) {}
> 
> This doesn't look right to me. We check `head != nullptr` in the loop condition so we cannot reach the assignment if it is null.

A situation is possible where head becomes nullptr when head->next() returns nullptr on the last iteration. Then, after the loop finishes, assert(head != nullptr) will trigger (only in debug mode), and return head->data() will cause a program error

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26798#discussion_r2290418847

From azafari at openjdk.org  Thu Aug 21 09:49:09 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 21 Aug 2025 09:49:09 GMT
Subject: RFR: 8353468: [ubsan] arguments.cpp:2422:23: runtime error:
 2.14748e+11 is outside the range of representable values of type 'int' [v2]
In-Reply-To: <plQ5n7EjsekIjeY431_mBeo4rfcH39SVdPWogF2rT44=.20180c89-665e-4054-8625-1b04f8306b3b@github.com>
References: <plQ5n7EjsekIjeY431_mBeo4rfcH39SVdPWogF2rT44=.20180c89-665e-4054-8625-1b04f8306b3b@github.com>
Message-ID: <4Ds0MTQtlz861U-p1N3flLCgZbBrFQdoG0Sclg6d9p4=.48ef346b-56c4-4a2e-a656-fbabc1514302@github.com>

> In converting values of `-XMinf` and `-XMaxf` options to `int`, overflow was not checked. 
> The values are checked against INT_MAX and clamped.
> 
> Tests: tiers 1-5.

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

  negative underflow checked.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26859/files
  - new: https://git.openjdk.org/jdk/pull/26859/files/747a0067..74144083

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

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

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

From azafari at openjdk.org  Thu Aug 21 09:54:51 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 21 Aug 2025 09:54:51 GMT
Subject: RFR: 8353468: [ubsan] arguments.cpp:2422:23: runtime error:
 2.14748e+11 is outside the range of representable values of type 'int'
In-Reply-To: <k9IUTdCiIKbbfQrHRBzeoLtk-IjvddnRfqeUl9fbTBs=.f69be724-67a1-4e31-9aea-025a2c58620d@github.com>
References: <plQ5n7EjsekIjeY431_mBeo4rfcH39SVdPWogF2rT44=.20180c89-665e-4054-8625-1b04f8306b3b@github.com>
 <k9IUTdCiIKbbfQrHRBzeoLtk-IjvddnRfqeUl9fbTBs=.f69be724-67a1-4e31-9aea-025a2c58620d@github.com>
Message-ID: <w-3zb2ajiANH7Ep_Fvt52He5M2x846DK0IrS2FEqU8o=.746c7944-5755-4e60-944d-704205f94cf5@github.com>

On Thu, 21 Aug 2025 07:46:29 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Would ubsan hit a similar value if it did and would you have to guard against INT_MIN as well?

UBSAN could also complain about the too small negative values.
The test and C++ source are changed for these cases.

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

PR Comment: https://git.openjdk.org/jdk/pull/26859#issuecomment-3209822242

From duke at openjdk.org  Thu Aug 21 10:00:10 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Thu, 21 Aug 2025 10:00:10 GMT
Subject: RFR: 8365917: Sort share/logging includes
Message-ID: <yVKq4z-VjDzM2UKJnuyqmIgsiTrm1P17p9TreJZGPcM=.8bb0451a-ab49-445f-9e79-a8d6e6d5c518@github.com>

This PR sorts the includes in `hotspot/share/logging` using `SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted`.

Passes `tier1`.

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

Commit messages:
 - sort

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

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

From adinn at openjdk.org  Thu Aug 21 10:01:59 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 21 Aug 2025 10:01:59 GMT
Subject: RFR: 8365604: Null pointer dereference in
 src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() [v2]
In-Reply-To: <ftJY3jOzJsWM_Aq9WpMjcrn3uR4e9cs_dS9ibkfu3c4=.6b8bbd93-e8e1-4000-8d24-42d40ddd5c11@github.com>
References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
 <m-aR302_Qm6Np3fyTAaw5RB2q6t1vMW4vEolOaVueKo=.ff55cc84-9167-473a-af27-95becf011732@github.com>
 <ftJY3jOzJsWM_Aq9WpMjcrn3uR4e9cs_dS9ibkfu3c4=.6b8bbd93-e8e1-4000-8d24-42d40ddd5c11@github.com>
Message-ID: <nfX_mlIzSSw6BnbOsToJC4QUI4u8SIO2WPOgbmcKV4o=.c6711b09-3989-4762-92a9-cde741c8b303@github.com>

On Thu, 21 Aug 2025 09:08:58 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> src/hotspot/share/nmt/mallocSiteTable.cpp line 172:
>> 
>>> 170:        index < pos_idx && head != nullptr;
>>> 171:        index++, head = ((MallocSiteHashtableEntry*)head->next() == nullptr) ? head :
>>> 172:       (MallocSiteHashtableEntry*)head->next()) {}
>> 
>> This doesn't look right to me. We check `head != nullptr` in the loop condition so we cannot reach the assignment if it is null.
>
> A situation is possible where head becomes nullptr when head->next() returns nullptr on the last iteration. Then, after the loop finishes, assert(head != nullptr) will trigger (only in debug mode), and return head->data() will cause a program error

Hmm, is it possible?

Perhaps you could explain how pos_idx is being used in this loop to guard against that happening and why that does not make this safe?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26798#discussion_r2290543955

From jnordstrom at openjdk.org  Thu Aug 21 10:07:48 2025
From: jnordstrom at openjdk.org (Joakim =?UTF-8?B?Tm9yZHN0csO2bQ==?=)
Date: Thu, 21 Aug 2025 10:07:48 GMT
Subject: RFR: 8365913: Support latest MSC_VER in abstract_vm_version.cpp
Message-ID: <m96A9c01TCmTDpCCsAt3MdpGXs21kDUW2_GRoziwmBY=.fc9b5e23-218d-4a1e-b882-05e85d7c15fe@github.com>

With the latest devkit upgrade for Windows, hs_err files and `-Xinternalversion` reports "`unknown MS VC++:1943`".

This fix adds the latest known MSC_VER version, as of current date according to https://learn.microsoft.com/en-us/cpp/overview/compiler-versions?view=msvc-170.

### Testing
- [x] Built locally and verified MSVC version is reported correctly
- [ ] tier1-tier3

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

Commit messages:
 - 8365913: Support latest MSC_VER in abstract_vm_version.cpp

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

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

From ayang at openjdk.org  Thu Aug 21 10:17:17 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 21 Aug 2025 10:17:17 GMT
Subject: RFR: 8263476: Use reserved memory for stack guard pages [v5]
In-Reply-To: <BojYWaP10BJMEWDQYSRiMKR0cOWzMF5At9_3fwD6uUw=.becf6902-01f1-41e0-965d-18a945a6dfcf@github.com>
References: <BojYWaP10BJMEWDQYSRiMKR0cOWzMF5At9_3fwD6uUw=.becf6902-01f1-41e0-965d-18a945a6dfcf@github.com>
Message-ID: <WvYUZZ5SdJGWxO3mqf8aBrciiI91obbJni4kNqmivfE=.f647da61-7f80-407c-b956-9f13d658535d@github.com>

> Use reserved (instead of committed) memory for stack-guard-pages on linux like systems.
> 
> `os::must_commit_stack_guard_pages` uses `commit` in its name, but `commit` usually has specific meanings in OS memory context. The actual question the caller is asking is whether the caller needs to do some preparation work before marking the guard-pages as inaccessible. To avoid confusion, I changed it to "allocate". Other suggestions are welcome.
> 
> Test: ~tier1-3~ tier1-8

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

 - Merge branch 'master' into no-commit-stack-guard-page
 - Merge branch 'master' into no-commit-stack-guard-page
 - review
 - review
 - Merge branch 'master' into no-commit-stack-guard-page
 - no-commit-stack-guard-page

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26571/files
  - new: https://git.openjdk.org/jdk/pull/26571/files/db7647fb..5e4de066

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

  Stats: 20038 lines in 667 files changed: 10180 ins; 7215 del; 2643 mod
  Patch: https://git.openjdk.org/jdk/pull/26571.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26571/head:pull/26571

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

From adinn at openjdk.org  Thu Aug 21 10:17:56 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 21 Aug 2025 10:17:56 GMT
Subject: RFR: 8365604: Null pointer dereference in
 src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() [v2]
In-Reply-To: <clP7ORnQOS8o0QhYs7DyuOLjQ-bPKch1dK1hDqPzzaI=.9b61fd70-4622-4344-aea6-8661fb57427c@github.com>
References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
 <clP7ORnQOS8o0QhYs7DyuOLjQ-bPKch1dK1hDqPzzaI=.9b61fd70-4622-4344-aea6-8661fb57427c@github.com>
Message-ID: <t1IN7M1W44RGuPkysGDxmmdmADmc6lFc0R11i4dKrcI=.de45ee4c-9a8d-436a-80e2-2d6224bf3ad0@github.com>

On Thu, 21 Aug 2025 09:01:12 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> The defect has been detected and confirmed in the function ArchDesc::declareClasses() located in the file src/hotspot/share/adlc/output_h.cpp with static code analysis. This defect can potentially lead to a null pointer dereference.
>> 
>> The pointer instr->_matrule is dereferenced in line 1952 without checking for nullptr, although earlier in line 1858 the same pointer is checked for nullptr, which indicates that it can be null.
>> 
>> According to [this](https://github.com/openjdk/jdk/pull/26002#issuecomment-3023050372) comment, this PR contains fixes for similar cases in other places.
>
> Artem Semenov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/hotspot/share/c1/c1_LinearScan.cpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Update src/hotspot/share/adlc/output_h.cpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

n.b. Before accepting any of the changes in this PR I'd really like to know whether they have arisen from reports of an actual null pointer dereference or they are simply derived from some theoretical analysis. In the latter case then I think we would need a better explanation of why an error can happen than we have seen so far. Given that requirement I also think each of the changes should be submitted in its own PR with its own justification. We should not modify control flow logic on the nod.

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

PR Comment: https://git.openjdk.org/jdk/pull/26798#issuecomment-3209906082

From asemenov at openjdk.org  Thu Aug 21 10:34:03 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 21 Aug 2025 10:34:03 GMT
Subject: RFR: 8365604: Null pointer dereference in
 src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses()
In-Reply-To: <O_bhdRkPTNNPMh-njv0iY0vTStYNWjOclqPxxfX4elg=.8a79282a-c985-442b-a105-f178852e60d5@github.com>
References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
 <O_bhdRkPTNNPMh-njv0iY0vTStYNWjOclqPxxfX4elg=.8a79282a-c985-442b-a105-f178852e60d5@github.com>
Message-ID: <sFP5T-Udewsb3RPw1JazXkAEFMWbtqADYzq-2VTyaAE=.e757c87b-1eb3-4bc0-8a0d-a76ff6a3a9ad@github.com>

On Wed, 20 Aug 2025 12:29:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I've added some additional mailing lists to ensure better coverage here.
> 
> Also I think you need to update the JBS (and PR) title to reflect the broader scope of the changes.

Please provide an example of an updated title?

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

PR Comment: https://git.openjdk.org/jdk/pull/26798#issuecomment-3209975632

From asemenov at openjdk.org  Thu Aug 21 10:34:04 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 21 Aug 2025 10:34:04 GMT
Subject: RFR: 8365604: Null pointer dereference in
 src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() [v2]
In-Reply-To: <m-aR302_Qm6Np3fyTAaw5RB2q6t1vMW4vEolOaVueKo=.ff55cc84-9167-473a-af27-95becf011732@github.com>
References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
 <m-aR302_Qm6Np3fyTAaw5RB2q6t1vMW4vEolOaVueKo=.ff55cc84-9167-473a-af27-95becf011732@github.com>
Message-ID: <MQRWuZVpXil3heDuvAQ5rXpMeTvYPUr0dUfO_Vv35oo=.688e7cea-48e5-425a-ab7c-4e6a6e8f202a@github.com>

On Wed, 20 Aug 2025 12:22:18 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Artem Semenov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update src/hotspot/share/c1/c1_LinearScan.cpp
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>>  - Update src/hotspot/share/adlc/output_h.cpp
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>
> src/hotspot/share/opto/vectorIntrinsics.cpp line 1319:
> 
>> 1317:     log_if_needed("  ** not supported: arity=%d op=%s vlen=%d etype=%s atype=%s ismask=no",
>> 1318:                     is_scatter, is_scatter ? "scatter" : "gather",
>> 1319:                     num_elem, type2name(elem_bt), type2name(arr_type->elem()->array_element_basic_type()));
> 
> There is  a bug here but I'm not sure it is what you think it is.

```addr_type->isa_aryptr();``` might return nullptr, while in ```elem_consistent_with_arr(elem_bt, arr_type, false)```, arr_type is only checked with an assert.
Moreover, the presence of a check in the original version indicates that arr_type can be null, and there is no protection against this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26798#discussion_r2290615638

From mdoerr at openjdk.org  Thu Aug 21 10:47:59 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 21 Aug 2025 10:47:59 GMT
Subject: RFR: 8358696: Assert with extreme values for -XX:BciProfileWidth
 [v11]
In-Reply-To: <ArMMBmwIrELUVJC-CbHROAgjdAdA0Y_fjOMqa1wKiM0=.2c675809-0e36-4056-a53b-b8bde334df0d@github.com>
References: <5TRVeAXUQi6quM-nDWEij_jk6M5K2Vk31RA-Yjd8F2M=.5b63da45-93c3-4251-9e2e-3c64b7953919@github.com>
 <sgsCVJZyBuFTDNQuZbG_z6BQZVqhfDKbrtSN0flpntA=.3bbd7e00-0f03-44de-9444-d27f6c69bc16@github.com>
 <ArMMBmwIrELUVJC-CbHROAgjdAdA0Y_fjOMqa1wKiM0=.2c675809-0e36-4056-a53b-b8bde334df0d@github.com>
Message-ID: <0frgDbdeT2orwVXd_58_fZHVO7gW_x63WlMUbOhDtlQ=.89c6e5a2-bd63-4453-adc3-870856bea6c3@github.com>

On Wed, 20 Aug 2025 23:39:50 GMT, Dean Long <dlong at openjdk.org> wrote:

> If we wanted to decrease the code size, we could change the unrolled loop to a real loop. But I think first we should answer the question, why are we profiling "ret" instructions at all? As far as I can tell, the compilers are not using the profiling data for anything, so maybe we could just remove it.

Interesting point. I wonder if it makes sense to collect as much profiling data in the interpreter as we currently do. C1 tier 3 can still collect it.

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

PR Comment: https://git.openjdk.org/jdk/pull/26139#issuecomment-3210013114

From asemenov at openjdk.org  Thu Aug 21 11:11:56 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 21 Aug 2025 11:11:56 GMT
Subject: RFR: 8365604: Null pointer dereference in
 src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() [v2]
In-Reply-To: <nfX_mlIzSSw6BnbOsToJC4QUI4u8SIO2WPOgbmcKV4o=.c6711b09-3989-4762-92a9-cde741c8b303@github.com>
References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
 <m-aR302_Qm6Np3fyTAaw5RB2q6t1vMW4vEolOaVueKo=.ff55cc84-9167-473a-af27-95becf011732@github.com>
 <ftJY3jOzJsWM_Aq9WpMjcrn3uR4e9cs_dS9ibkfu3c4=.6b8bbd93-e8e1-4000-8d24-42d40ddd5c11@github.com>
 <nfX_mlIzSSw6BnbOsToJC4QUI4u8SIO2WPOgbmcKV4o=.c6711b09-3989-4762-92a9-cde741c8b303@github.com>
Message-ID: <TMAYmQLsLMVYslI-dilLANogdWfQqCRdPML64fs1Rz8=.4a247460-76c9-46a3-92bd-df5ece4679ba@github.com>

On Thu, 21 Aug 2025 09:59:01 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> A situation is possible where head becomes nullptr when head->next() returns nullptr on the last iteration. Then, after the loop finishes, assert(head != nullptr) will trigger (only in debug mode), and return head->data() will cause a program error
>
> Hmm, is it possible?
> 
> Perhaps you could explain how pos_idx is being used in this loop to guard against that happening and why that does not make this safe?

```head->next()``` returns a pointer to _next without any checks.

In turn, the _next pointer is marked as volatile, which means it can be modified at any moment, for example, in another thread.

>From this, I conclude that a check in this location is desirable. Moreover, pos_idx is also not being checked. It is quite possible that ```head->next()``` could turn out to be nullptr.

But I don?t mind. If you are sure that there can?t be a nullptr in this place, I will withdraw this patch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26798#discussion_r2290701959

From duke at openjdk.org  Thu Aug 21 11:59:38 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 21 Aug 2025 11:59:38 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v12]
In-Reply-To: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
Message-ID: <zsCif8ratOrgUO3FdjVaT73uJlA9lFZkvE7D6EiV-8s=.ef893053-b573-4c0b-b09b-494931e8c1c5@github.com>

> Hi all,
> 
> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110).
> 
> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports:
> 
> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup()
> 
> CPUTimeUsage::GC::gc_threads()
> CPUTimeUsage::GC::vm_thread()
> CPUTimeUsage::GC::stringdedup()
> 
> CPUTimeUsage::Runtime::vm_thread()
> 
> 
> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC.
> 
> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table:
> 
> 
> [71.425s][info][cpu   ] === CPU time Statistics =============================================================
> [71.425s][info][cpu   ]                                                                             CPUs
> [71.425s][info][cpu   ]                                                                s       %  utilized
> [71.425s][info][cpu   ]    Process
> [71.425s][info][cpu   ]      Total                                             1616.3627  100.00      22.6
> [71.425s][info][cpu   ]      VM Thread                                            5.2992    0.33       0.1
> [71.425s][info][cpu   ]      Garbage Collection                                  83.7322    5.18       1.2
> [71.425s][info][cpu   ]        GC Threads                                        82.7671    5.12       1.2
> [71.425s][info][cpu   ]        VM Thread                                          0.9651    0.06       0.0
> [71.425s][info][cpu   ] =====================================================================================
> 
> 
> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path.

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

  Remove CPUTimeUsage::Runtime

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26621/files
  - new: https://git.openjdk.org/jdk/pull/26621/files/f29d5af4..b7fdc0f8

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

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

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

From duke at openjdk.org  Thu Aug 21 11:59:38 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 21 Aug 2025 11:59:38 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v11]
In-Reply-To: <UFXJrV71IKWGmnVANfYtYTgLJmRtnuN11dup9LHy_v8=.21b9e391-d8be-460c-87cb-c1fee94db422@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <UFXJrV71IKWGmnVANfYtYTgLJmRtnuN11dup9LHy_v8=.21b9e391-d8be-460c-87cb-c1fee94db422@github.com>
Message-ID: <knTn92ULPJfoVpr-kyXnIlZSkANc54Rc28NIAVEwKr4=.914f2dba-0d8c-4f53-acc1-2581904ff218@github.com>

On Wed, 20 Aug 2025 09:00:30 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110).
>> 
>> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports:
>> 
>> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup()
>> 
>> CPUTimeUsage::GC::gc_threads()
>> CPUTimeUsage::GC::vm_thread()
>> CPUTimeUsage::GC::stringdedup()
>> 
>> CPUTimeUsage::Runtime::vm_thread()
>> 
>> 
>> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC.
>> 
>> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table:
>> 
>> 
>> [71.425s][info][cpu   ] === CPU time Statistics =============================================================
>> [71.425s][info][cpu   ]                                                                             CPUs
>> [71.425s][info][cpu   ]                                                                s       %  utilized
>> [71.425s][info][cpu   ]    Process
>> [71.425s][info][cpu   ]      Total                                             1616.3627  100.00      22.6
>> [71.425s][info][cpu   ]      VM Thread                                            5.2992    0.33       0.1
>> [71.425s][info][cpu   ]      Garbage Collection                                  83.7322    5.18       1.2
>> [71.425s][info][cpu   ]        GC Threads                                        82.7671    5.12       1.2
>> [71.425s][info][cpu   ]        VM Thread                                          0.9651    0.06       0.0
>> [71.425s][info][cpu   ] =====================================================================================
>> 
>> 
>> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove GCStatistics, add thread_cpu_time_or_zero, move GC/heap log to Universe::before_exit

I had an offline discussion with @albertnetymk (thanks for bringing this up!) and we both agree that the current definition of `CPUTimeUsage::Runtime::vm_thread()` may be misread. As a consequence, we believe that expanding this interface to include more components would be best served by creating a separate PR that can serve as an explicit discussion for the layout. As such I'm removing `CPUTimeUsage::Runtime` from this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/26621#issuecomment-3210275213

From ayang at openjdk.org  Thu Aug 21 12:08:56 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 21 Aug 2025 12:08:56 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v12]
In-Reply-To: <zsCif8ratOrgUO3FdjVaT73uJlA9lFZkvE7D6EiV-8s=.ef893053-b573-4c0b-b09b-494931e8c1c5@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <zsCif8ratOrgUO3FdjVaT73uJlA9lFZkvE7D6EiV-8s=.ef893053-b573-4c0b-b09b-494931e8c1c5@github.com>
Message-ID: <Irg8M2fUPdf5Z-8QMghZgXH40R5x8zrWRRXvLDtIb9s=.4ef291f5-0d50-46f6-b67c-876f58b54171@github.com>

On Thu, 21 Aug 2025 11:59:38 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110).
>> 
>> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports:
>> 
>> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup()
>> 
>> CPUTimeUsage::GC::gc_threads()
>> CPUTimeUsage::GC::vm_thread()
>> CPUTimeUsage::GC::stringdedup()
>> 
>> CPUTimeUsage::Runtime::vm_thread()
>> 
>> 
>> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC.
>> 
>> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table:
>> 
>> 
>> [71.425s][info][cpu   ] === CPU time Statistics =============================================================
>> [71.425s][info][cpu   ]                                                                             CPUs
>> [71.425s][info][cpu   ]                                                                s       %  utilized
>> [71.425s][info][cpu   ]    Process
>> [71.425s][info][cpu   ]      Total                                             1616.3627  100.00      22.6
>> [71.425s][info][cpu   ]      VM Thread                                            5.2992    0.33       0.1
>> [71.425s][info][cpu   ]      Garbage Collection                                  83.7322    5.18       1.2
>> [71.425s][info][cpu   ]        GC Threads                                        82.7671    5.12       1.2
>> [71.425s][info][cpu   ]        VM Thread                                          0.9651    0.06       0.0
>> [71.425s][info][cpu   ] =====================================================================================
>> 
>> 
>> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove CPUTimeUsage::Runtime

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26621#pullrequestreview-3140358434

From adinn at openjdk.org  Thu Aug 21 12:11:53 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 21 Aug 2025 12:11:53 GMT
Subject: RFR: 8365604: Null pointer dereference in
 src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() [v2]
In-Reply-To: <TMAYmQLsLMVYslI-dilLANogdWfQqCRdPML64fs1Rz8=.4a247460-76c9-46a3-92bd-df5ece4679ba@github.com>
References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
 <m-aR302_Qm6Np3fyTAaw5RB2q6t1vMW4vEolOaVueKo=.ff55cc84-9167-473a-af27-95becf011732@github.com>
 <ftJY3jOzJsWM_Aq9WpMjcrn3uR4e9cs_dS9ibkfu3c4=.6b8bbd93-e8e1-4000-8d24-42d40ddd5c11@github.com>
 <nfX_mlIzSSw6BnbOsToJC4QUI4u8SIO2WPOgbmcKV4o=.c6711b09-3989-4762-92a9-cde741c8b303@github.com>
 <TMAYmQLsLMVYslI-dilLANogdWfQqCRdPML64fs1Rz8=.4a247460-76c9-46a3-92bd-df5ece4679ba@github.com>
Message-ID: <IPp6nZpu3m9vy6YmAi7OpffEWN5h8p81ss21dkBsPGU=.3edab52c-89d6-45f4-9daa-c35f48dc3bb0@github.com>

On Thu, 21 Aug 2025 11:09:12 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> Moreover, pos_idx is also not being checked

I don't know what you mean by this comment. `pos_idx` is being checked in the loop test before the call to `head->next()` in that same test.

The important question you need to address is why and what that check guarantees. I say you need to address it because you are the one claiming that there is a possible nullptr dereference  here without any evidence that it has occurred in practice. If that is based on a correct analysis of the code then you need to explain how we can arrive at a situtation where we hit a null pointer that takes into account the logic of the loop test. So far you have not done so.

n.b. I am not claiming there is no possibility of a nullptr dereference here (although I can form my own opinion). I'm asking you to tell me why I should take your claim that it is possible seriously. Your answers so far are not convincing me that you have understood how this code works.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26798#discussion_r2290852355

From duke at openjdk.org  Thu Aug 21 12:26:17 2025
From: duke at openjdk.org (Anton Artemov)
Date: Thu, 21 Aug 2025 12:26:17 GMT
Subject: RFR: 8362239: Reconcile enter_internal and reenter_internal in the
 ObjectMonitor code
Message-ID: <bFOL84k7J_i3djQTiPZ9Nc19u9Pe0eZnXGN5oqvJ29E=.0e0e6be2-bda4-4360-8f19-71c4f231028c@github.com>

Please consider the following changes:

The two methods of the `ObjectMonitor` class, namely `enter_internal()` and `reenter_internal()`, are reconciled. As a result, `reenter_internal()` is removed, whereas `enter_internal()` is modified. 

The modification affects the range of the code, where the thread is in the blocked state. Now, it is only a small part in the innermost loop of the method. However, suspension of the "contender" thread is not allowed on the initial entrance, as this can potentially lead to a deadlock: if the "contender" thread is suspended in the innermost loop, and the "resumer" thread is parked, no one will be making progress as the "resumer" thread cannot be woken up, as the "contender" thread has not yet exited the monitor to unpark the "resumer". 

In this sense, the initial entrance to the monitor is considered to be **atomic**, i.e. it is either completed, or not done at all. This means it should not be interrupted by a suspension request. The re-entrance to the monitor, however, allows suspension, as the monitor has been already owned by a "contender" thread.

Tested in tiers 1-5.

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

Commit messages:
 - 8362239: Reconciled enter_internal vs reenter_internal in the ObjectMonitor code

Changes: https://git.openjdk.org/jdk/pull/26858/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26858&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8362239
  Stats: 164 lines in 2 files changed: 43 ins; 79 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/26858.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26858/head:pull/26858

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

From dholmes at openjdk.org  Thu Aug 21 12:26:18 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 21 Aug 2025 12:26:18 GMT
Subject: RFR: 8362239: Reconcile enter_internal and reenter_internal in the
 ObjectMonitor code
In-Reply-To: <bFOL84k7J_i3djQTiPZ9Nc19u9Pe0eZnXGN5oqvJ29E=.0e0e6be2-bda4-4360-8f19-71c4f231028c@github.com>
References: <bFOL84k7J_i3djQTiPZ9Nc19u9Pe0eZnXGN5oqvJ29E=.0e0e6be2-bda4-4360-8f19-71c4f231028c@github.com>
Message-ID: <TiOMQnOdLWIztYBulaOc3oUi_PDbhZ242saN7S4Hxgk=.451ba488-55d5-4857-92af-e0af6a4605b6@github.com>

On Wed, 20 Aug 2025 11:20:38 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Please consider the following changes:
> 
> The two methods of the `ObjectMonitor` class, namely `enter_internal()` and `reenter_internal()`, are reconciled. As a result, `reenter_internal()` is removed, whereas `enter_internal()` is modified. 
> 
> The modification affects the range of the code, where the thread is in the blocked state. Now, it is only a small part in the innermost loop of the method. However, suspension of the "contender" thread is not allowed on the initial entrance, as this can potentially lead to a deadlock: if the "contender" thread is suspended in the innermost loop, and the "resumer" thread is parked, no one will be making progress as the "resumer" thread cannot be woken up, as the "contender" thread has not yet exited the monitor to unpark the "resumer". 
> 
> In this sense, the initial entrance to the monitor is considered to be **atomic**, i.e. it is either completed, or not done at all. This means it should not be interrupted by a suspension request. The re-entrance to the monitor, however, allows suspension, as the monitor has been already owned by a "contender" thread.
> 
> Tested in tiers 1-5.

src/hotspot/share/runtime/objectMonitor.cpp line 981:

> 979:     // Java objects.  This would avoid awkward lifecycle and liveness issues,
> 980:     // as well as eliminate a subset of ABA issues.
> 981:     // TODO: eliminate ObjectWaiter and enqueue either Threads or Events.

Side issue: I think this commentary can be removed now.

src/hotspot/share/runtime/objectMonitor.cpp line 1903:

> 1901:     } else {
> 1902:       guarantee(v == ObjectWaiter::TS_ENTER, "invariant");
> 1903:       enter_internal(current, &node, true);

Suggestion:

      enter_internal(current, &node, true /* do_reenter */);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26858#discussion_r2290151251
PR Review Comment: https://git.openjdk.org/jdk/pull/26858#discussion_r2290144195

From jsjolen at openjdk.org  Thu Aug 21 12:54:51 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 21 Aug 2025 12:54:51 GMT
Subject: RFR: 8365378: Redundant code in Deoptimization::print_statistics
In-Reply-To: <4qlNQcnx7UvD5kqrN0tyxulJTu-PZ5cDBy5AwYGHSTo=.d00af3bd-86f6-474c-a7ff-bd0ff5a79597@github.com>
References: <4qlNQcnx7UvD5kqrN0tyxulJTu-PZ5cDBy5AwYGHSTo=.d00af3bd-86f6-474c-a7ff-bd0ff5a79597@github.com>
Message-ID: <EDFuzpGdoqzKdFuOjZtfoalE2QENOKs0sOVCN9erBu8=.38d600b9-a4f0-4ab5-be72-7b950cca1bbf@github.com>

On Tue, 12 Aug 2025 12:31:28 GMT, Paul H?bner <duke at openjdk.org> wrote:

> Hi all,
> 
> The `Deoptimization::print_statistics` function has a conditional that is never invoked. `bc_case` is bound in a for loop and will always be < `BC_CASE_LIMIT`. Therefore, the entire condition will never hold, and the branch never execute. This change removes the dead code in order to increase maintainability.
> 
> I've run hotspot:tier1 to hotspot:tier3, in which I observed no test failures.

Marked as reviewed by jsjolen (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26744#pullrequestreview-3140536962

From coleenp at openjdk.org  Thu Aug 21 13:03:52 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 21 Aug 2025 13:03:52 GMT
Subject: RFR: 8365378: Redundant code in Deoptimization::print_statistics
In-Reply-To: <4qlNQcnx7UvD5kqrN0tyxulJTu-PZ5cDBy5AwYGHSTo=.d00af3bd-86f6-474c-a7ff-bd0ff5a79597@github.com>
References: <4qlNQcnx7UvD5kqrN0tyxulJTu-PZ5cDBy5AwYGHSTo=.d00af3bd-86f6-474c-a7ff-bd0ff5a79597@github.com>
Message-ID: <Fqr1oOe95yP2ANn36w0n4fHDKtTTC4I7JKjb15Kpr6Q=.2d5ebf10-130e-4536-be9e-b51066862003@github.com>

On Tue, 12 Aug 2025 12:31:28 GMT, Paul H?bner <duke at openjdk.org> wrote:

> Hi all,
> 
> The `Deoptimization::print_statistics` function has a conditional that is never invoked. `bc_case` is bound in a for loop and will always be < `BC_CASE_LIMIT`. Therefore, the entire condition will never hold, and the branch never execute. This change removes the dead code in order to increase maintainability.
> 
> I've run hotspot:tier1 to hotspot:tier3, in which I observed no test failures.

Looks good!

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26744#pullrequestreview-3140555973

From duke at openjdk.org  Thu Aug 21 13:03:53 2025
From: duke at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Thu, 21 Aug 2025 13:03:53 GMT
Subject: RFR: 8365378: Redundant code in Deoptimization::print_statistics
In-Reply-To: <EDFuzpGdoqzKdFuOjZtfoalE2QENOKs0sOVCN9erBu8=.38d600b9-a4f0-4ab5-be72-7b950cca1bbf@github.com>
References: <4qlNQcnx7UvD5kqrN0tyxulJTu-PZ5cDBy5AwYGHSTo=.d00af3bd-86f6-474c-a7ff-bd0ff5a79597@github.com>
 <EDFuzpGdoqzKdFuOjZtfoalE2QENOKs0sOVCN9erBu8=.38d600b9-a4f0-4ab5-be72-7b950cca1bbf@github.com>
Message-ID: <5Y1nwFwNO7OtJ8Jdw0QvcMKRuRzFAkhYDcxFnm89zgQ=.9e48d059-7e2c-47ac-9690-75311501a348@github.com>

On Thu, 21 Aug 2025 12:52:35 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi all,
>> 
>> The `Deoptimization::print_statistics` function has a conditional that is never invoked. `bc_case` is bound in a for loop and will always be < `BC_CASE_LIMIT`. Therefore, the entire condition will never hold, and the branch never execute. This change removes the dead code in order to increase maintainability.
>> 
>> I've run hotspot:tier1 to hotspot:tier3, in which I observed no test failures.
>
> Marked as reviewed by jsjolen (Reviewer).

Thanks for reviewing, @jdksjolen and @coleenp!

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

PR Comment: https://git.openjdk.org/jdk/pull/26744#issuecomment-3210500698

From duke at openjdk.org  Thu Aug 21 13:03:53 2025
From: duke at openjdk.org (duke)
Date: Thu, 21 Aug 2025 13:03:53 GMT
Subject: RFR: 8365378: Redundant code in Deoptimization::print_statistics
In-Reply-To: <4qlNQcnx7UvD5kqrN0tyxulJTu-PZ5cDBy5AwYGHSTo=.d00af3bd-86f6-474c-a7ff-bd0ff5a79597@github.com>
References: <4qlNQcnx7UvD5kqrN0tyxulJTu-PZ5cDBy5AwYGHSTo=.d00af3bd-86f6-474c-a7ff-bd0ff5a79597@github.com>
Message-ID: <OFCGCy0YdeK2LTduC_zLVVY-XjkaFdQ4GKk0hznPcW0=.f1629e9d-cc67-4e19-81d6-aa0c9514d744@github.com>

On Tue, 12 Aug 2025 12:31:28 GMT, Paul H?bner <duke at openjdk.org> wrote:

> Hi all,
> 
> The `Deoptimization::print_statistics` function has a conditional that is never invoked. `bc_case` is bound in a for loop and will always be < `BC_CASE_LIMIT`. Therefore, the entire condition will never hold, and the branch never execute. This change removes the dead code in order to increase maintainability.
> 
> I've run hotspot:tier1 to hotspot:tier3, in which I observed no test failures.

@Arraying 
Your change (at version 392dd29e4e61c8b369b83fcbd9309021a719d857) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/26744#issuecomment-3210508721

From coleenp at openjdk.org  Thu Aug 21 13:18:59 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 21 Aug 2025 13:18:59 GMT
Subject: RFR: 8365189: Remove LockingMode related code from arm32
In-Reply-To: <bvw0sMNTLzhoms1UW34LXiFrkKDysBfeLAQftPjBh5o=.ddd3c817-4094-4cfe-afa2-4c751eae6814@github.com>
References: <bvw0sMNTLzhoms1UW34LXiFrkKDysBfeLAQftPjBh5o=.ddd3c817-4094-4cfe-afa2-4c751eae6814@github.com>
Message-ID: <qr3UExI2MEAdzaYT8O6WHyVSPHmoGm0vfBjSkaqW4Ak=.05ca9e5c-ef3e-4cd3-8977-cc3ccdc6336a@github.com>

On Fri, 15 Aug 2025 09:29:04 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
> 
> This PR removes `LockingMode` related code from the **arm32** platform.
> 
> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.

Looks good!

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26795#pullrequestreview-3140644851

From asemenov at openjdk.org  Thu Aug 21 13:21:02 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 21 Aug 2025 13:21:02 GMT
Subject: RFR: 8365604: Null pointer dereference in
 src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() [v2]
In-Reply-To: <IPp6nZpu3m9vy6YmAi7OpffEWN5h8p81ss21dkBsPGU=.3edab52c-89d6-45f4-9daa-c35f48dc3bb0@github.com>
References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
 <m-aR302_Qm6Np3fyTAaw5RB2q6t1vMW4vEolOaVueKo=.ff55cc84-9167-473a-af27-95becf011732@github.com>
 <ftJY3jOzJsWM_Aq9WpMjcrn3uR4e9cs_dS9ibkfu3c4=.6b8bbd93-e8e1-4000-8d24-42d40ddd5c11@github.com>
 <nfX_mlIzSSw6BnbOsToJC4QUI4u8SIO2WPOgbmcKV4o=.c6711b09-3989-4762-92a9-cde741c8b303@github.com>
 <TMAYmQLsLMVYslI-dilLANogdWfQqCRdPML64fs1Rz8=.4a247460-76c9-46a3-92bd-df5ece4679ba@github.com>
 <IPp6nZpu3m9vy6YmAi7OpffEWN5h8p81ss21dkBsPGU=.3edab52c-89d6-45f4-9daa-c35f48dc3bb0@github.com>
Message-ID: <iA2tvBsBkeEoKQntaeQZpteiyfMJCSdhhGKzNO-CeHc=.f5fb60fb-37e6-4b2e-9146-0be0fe220b9d@github.com>

On Thu, 21 Aug 2025 12:09:38 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> ```head->next()``` returns a pointer to _next without any checks.
>> 
>> In turn, the _next pointer is marked as volatile, which means it can be modified at any moment, for example, in another thread.
>> 
>> From this, I conclude that a check in this location is desirable. Moreover, pos_idx is also not being checked. It is quite possible that ```head->next()``` could turn out to be nullptr.
>> 
>> But I don?t mind. If you are sure that there can?t be a nullptr in this place, I will withdraw this patch.
>
>> Moreover, pos_idx is also not being checked
> 
> I don't know what you mean by this comment. `pos_idx` is being checked in the loop test before the call to `head->next()` in that same test.
> 
> The important question you need to address is why and what that check guarantees. I say you need to address it because you are the one claiming that there is a possible nullptr dereference  here without any evidence that it has occurred in practice. If that is based on a correct analysis of the code then you need to explain how we can arrive at a situtation where we hit a null pointer that takes into account the logic of the loop test. So far you have not done so.
> 
> n.b. I am not claiming there is no possibility of a nullptr dereference here (although I can form my own opinion). I'm asking you to tell me why I should take your claim that it is possible seriously. Your answers so far are not convincing me that you have understood how this code works.

pos_idx receives its value when calling a certain function pos_idx_from_marker(marker), and there is no check before the loop to ensure that it is within the bounds of the _table size.

I mentioned above that I am not insisting on this particular patch. This issue was detected by a static analyzer and confirmed by a specialist from another organization. After that, based on my limited knowledge, I considered it confirmed? If you have any refutation, please share your thoughts. In that case, I will revert this patch and mark the trigger as ?NO FIX REQUIRED?.

As far as I have checked, there are no checks anywhere in the calls to this function to compare the marker with the table or any other entities in any form.

I certainly do not claim to understand this code as well as you or any other member of the hotspot team.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26798#discussion_r2291041769

From ayang at openjdk.org  Thu Aug 21 13:30:01 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 21 Aug 2025 13:30:01 GMT
Subject: RFR: 8365917: Sort share/logging includes
In-Reply-To: <yVKq4z-VjDzM2UKJnuyqmIgsiTrm1P17p9TreJZGPcM=.8bb0451a-ab49-445f-9e79-a8d6e6d5c518@github.com>
References: <yVKq4z-VjDzM2UKJnuyqmIgsiTrm1P17p9TreJZGPcM=.8bb0451a-ab49-445f-9e79-a8d6e6d5c518@github.com>
Message-ID: <sGX6QZhQKX9cNWih00QgUN6i9IWCd8671CDhnV0JzYU=.ae05326c-c022-46eb-8b6b-129eb58bb3c6@github.com>

On Thu, 21 Aug 2025 09:54:33 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> This PR sorts the includes in `hotspot/share/logging` using `SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted`.
> 
> Passes `tier1`.

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26877#pullrequestreview-3140687201

From duke at openjdk.org  Thu Aug 21 13:35:51 2025
From: duke at openjdk.org (duke)
Date: Thu, 21 Aug 2025 13:35:51 GMT
Subject: RFR: 8365917: Sort share/logging includes
In-Reply-To: <yVKq4z-VjDzM2UKJnuyqmIgsiTrm1P17p9TreJZGPcM=.8bb0451a-ab49-445f-9e79-a8d6e6d5c518@github.com>
References: <yVKq4z-VjDzM2UKJnuyqmIgsiTrm1P17p9TreJZGPcM=.8bb0451a-ab49-445f-9e79-a8d6e6d5c518@github.com>
Message-ID: <VYR0Blhi1YFfSHXS8bOUWcMmy7nli3HsKikbx5LCD0I=.4b2fa139-1cb4-4b79-85b7-5e2545493349@github.com>

On Thu, 21 Aug 2025 09:54:33 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> This PR sorts the includes in `hotspot/share/logging` using `SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted`.
> 
> Passes `tier1`.

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

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

PR Comment: https://git.openjdk.org/jdk/pull/26877#issuecomment-3210625212

From duke at openjdk.org  Thu Aug 21 13:52:53 2025
From: duke at openjdk.org (duke)
Date: Thu, 21 Aug 2025 13:52:53 GMT
Subject: RFR: 8364638: Refactor and make accumulated GC CPU time code
 generic [v12]
In-Reply-To: <zsCif8ratOrgUO3FdjVaT73uJlA9lFZkvE7D6EiV-8s=.ef893053-b573-4c0b-b09b-494931e8c1c5@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
 <zsCif8ratOrgUO3FdjVaT73uJlA9lFZkvE7D6EiV-8s=.ef893053-b573-4c0b-b09b-494931e8c1c5@github.com>
Message-ID: <7-F_uRu2j1uwCfI9QrIcLpaZ15gJVft_sNJlN7DicRc=.0d4f66ca-77f6-4f8e-bdbd-76fa86dbcaa2@github.com>

On Thu, 21 Aug 2025 11:59:38 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110).
>> 
>> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports:
>> 
>> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup()
>> 
>> CPUTimeUsage::GC::gc_threads()
>> CPUTimeUsage::GC::vm_thread()
>> CPUTimeUsage::GC::stringdedup()
>> 
>> 
>> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC.
>> 
>> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table:
>> 
>> 
>> [71.425s][info][cpu   ] === CPU time Statistics =============================================================
>> [71.425s][info][cpu   ]                                                                             CPUs
>> [71.425s][info][cpu   ]                                                                s       %  utilized
>> [71.425s][info][cpu   ]    Process
>> [71.425s][info][cpu   ]      Total                                             1616.3627  100.00      22.6
>> [71.425s][info][cpu   ]      Garbage Collection                                  83.7322    5.18       1.2
>> [71.425s][info][cpu   ]        GC Threads                                        82.7671    5.12       1.2
>> [71.425s][info][cpu   ]        VM Thread                                          0.9651    0.06       0.0
>> [71.425s][info][cpu   ] =====================================================================================
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove CPUTimeUsage::Runtime

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

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

PR Comment: https://git.openjdk.org/jdk/pull/26621#issuecomment-3210699903

From duke at openjdk.org  Thu Aug 21 14:03:02 2025
From: duke at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Thu, 21 Aug 2025 14:03:02 GMT
Subject: Integrated: 8365378: Redundant code in
 Deoptimization::print_statistics
In-Reply-To: <4qlNQcnx7UvD5kqrN0tyxulJTu-PZ5cDBy5AwYGHSTo=.d00af3bd-86f6-474c-a7ff-bd0ff5a79597@github.com>
References: <4qlNQcnx7UvD5kqrN0tyxulJTu-PZ5cDBy5AwYGHSTo=.d00af3bd-86f6-474c-a7ff-bd0ff5a79597@github.com>
Message-ID: <3LMWDafvRRpdpnP5iSjsoraBzAoHhBENK_lWPzQnNng=.665dbfce-05fb-470c-baf8-b4403207950a@github.com>

On Tue, 12 Aug 2025 12:31:28 GMT, Paul H?bner <duke at openjdk.org> wrote:

> Hi all,
> 
> The `Deoptimization::print_statistics` function has a conditional that is never invoked. `bc_case` is bound in a for loop and will always be < `BC_CASE_LIMIT`. Therefore, the entire condition will never hold, and the branch never execute. This change removes the dead code in order to increase maintainability.
> 
> I've run hotspot:tier1 to hotspot:tier3, in which I observed no test failures.

This pull request has now been integrated.

Changeset: 1548ac4f
Author:    Paul H?bner <paul.hubner at oracle.com>
Committer: Casper Norrbin <cnorrbin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1548ac4f54edbd370aa071fa1db4474574d2987f
Stats:     2 lines in 1 file changed: 0 ins; 2 del; 0 mod

8365378: Redundant code in Deoptimization::print_statistics

Reviewed-by: jsjolen, coleenp

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

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

From duke at openjdk.org  Thu Aug 21 14:08:05 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 21 Aug 2025 14:08:05 GMT
Subject: Integrated: 8364638: Refactor and make accumulated GC CPU time code
 generic
In-Reply-To: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
References: <StYnj1Q0tBWszF1W8dwnNLWQezKPYgFl6mTJHRfFyZY=.2cc5b960-746b-4597-88b6-bb141f9c9057@github.com>
Message-ID: <EzLxrw73zur7r-ktPhTsoGY7XkQvvBnO-0JCJVspKis=.796f3a2a-7486-4bad-990a-6fe3e8bf64a4@github.com>

On Mon, 4 Aug 2025 13:59:43 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> Hi all,
> 
> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110).
> 
> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports:
> 
> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup()
> 
> CPUTimeUsage::GC::gc_threads()
> CPUTimeUsage::GC::vm_thread()
> CPUTimeUsage::GC::stringdedup()
> 
> 
> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC.
> 
> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table:
> 
> 
> [71.425s][info][cpu   ] === CPU time Statistics =============================================================
> [71.425s][info][cpu   ]                                                                             CPUs
> [71.425s][info][cpu   ]                                                                s       %  utilized
> [71.425s][info][cpu   ]    Process
> [71.425s][info][cpu   ]      Total                                             1616.3627  100.00      22.6
> [71.425s][info][cpu   ]      Garbage Collection                                  83.7322    5.18       1.2
> [71.425s][info][cpu   ]        GC Threads                                        82.7671    5.12       1.2
> [71.425s][info][cpu   ]        VM Thread                                          0.9651    0.06       0.0
> [71.425s][info][cpu   ] =====================================================================================

This pull request has now been integrated.

Changeset: fb651fd6
Author:    Jonas Norlinder <jonas.norlinder at oracle.com>
Committer: Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fb651fd6d246e69b42363e050eb8d96afb633eed
Stats:     281 lines in 11 files changed: 202 ins; 76 del; 3 mod

8364638: Refactor and make accumulated GC CPU time code generic

Reviewed-by: ayang, sjohanss

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

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

From bulasevich at openjdk.org  Thu Aug 21 14:24:52 2025
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Thu, 21 Aug 2025 14:24:52 GMT
Subject: RFR: 8365189: Remove LockingMode related code from arm32
In-Reply-To: <ObdNVa5OnCj-R2Nx01CHQ3LwUfhmchcTwi7NLy-9PNo=.6d64d0f0-47ca-49f2-ac9a-e21be9f03090@github.com>
References: <bvw0sMNTLzhoms1UW34LXiFrkKDysBfeLAQftPjBh5o=.ddd3c817-4094-4cfe-afa2-4c751eae6814@github.com>
 <ObdNVa5OnCj-R2Nx01CHQ3LwUfhmchcTwi7NLy-9PNo=.6d64d0f0-47ca-49f2-ac9a-e21be9f03090@github.com>
Message-ID: <Vm2kRDGrPkpecupTlwc8uE8B5EU6byECO5voGJ0S878=.86ac09cf-b21a-4c0e-9a0c-7c9654a63995@github.com>

On Fri, 15 Aug 2025 12:39:59 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> @bulasevich I've run rudimentary tests using QEMU, but it would be nice if you could take it for a spin on real hardware.

Hi. Confirmed on real hardware, works fine. :)

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

PR Comment: https://git.openjdk.org/jdk/pull/26795#issuecomment-3210823246

From adinn at openjdk.org  Thu Aug 21 14:34:53 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 21 Aug 2025 14:34:53 GMT
Subject: RFR: 8365604: Null pointer dereference in
 src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() [v2]
In-Reply-To: <iA2tvBsBkeEoKQntaeQZpteiyfMJCSdhhGKzNO-CeHc=.f5fb60fb-37e6-4b2e-9146-0be0fe220b9d@github.com>
References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
 <m-aR302_Qm6Np3fyTAaw5RB2q6t1vMW4vEolOaVueKo=.ff55cc84-9167-473a-af27-95becf011732@github.com>
 <ftJY3jOzJsWM_Aq9WpMjcrn3uR4e9cs_dS9ibkfu3c4=.6b8bbd93-e8e1-4000-8d24-42d40ddd5c11@github.com>
 <nfX_mlIzSSw6BnbOsToJC4QUI4u8SIO2WPOgbmcKV4o=.c6711b09-3989-4762-92a9-cde741c8b303@github.com>
 <TMAYmQLsLMVYslI-dilLANogdWfQqCRdPML64fs1Rz8=.4a247460-76c9-46a3-92bd-df5ece4679ba@github.com>
 <IPp6nZpu3m9vy6YmAi7OpffEWN5h8p81ss21dkBsPGU=.3edab52c-89d6-45f4-9daa-c35f48dc3bb0@github.com>
 <iA2tvBsBkeEoKQntaeQZpteiyfMJCSdhhGKzNO-CeHc=.f5fb60fb-37e6-4b2e-9146-0be0fe220b9d@github.com>
Message-ID: <KS-ahFFjB-Ehnk_gU_5pM3mfuhHOvOYySiL5Q1wZeVc=.a8bef526-8f2b-495d-b2b7-efa88f1ed6d6@github.com>

On Thu, 21 Aug 2025 13:18:26 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>>> Moreover, pos_idx is also not being checked
>> 
>> I don't know what you mean by this comment. `pos_idx` is being checked in the loop test before the call to `head->next()` in that same test.
>> 
>> The important question you need to address is why and what that check guarantees. I say you need to address it because you are the one claiming that there is a possible nullptr dereference  here without any evidence that it has occurred in practice. If that is based on a correct analysis of the code then you need to explain how we can arrive at a situtation where we hit a null pointer that takes into account the logic of the loop test. So far you have not done so.
>> 
>> n.b. I am not claiming there is no possibility of a nullptr dereference here (although I can form my own opinion). I'm asking you to tell me why I should take your claim that it is possible seriously. Your answers so far are not convincing me that you have understood how this code works.
>
> pos_idx receives its value when calling a certain function pos_idx_from_marker(marker), and there is no check before the loop to ensure that it is within the bounds of the _table size.
> 
> I mentioned above that I am not insisting on this particular patch. This issue was detected by a static analyzer. After that, based on my limited knowledge, I considered it confirmed? If you have any refutation, please share your thoughts. In that case, I will revert this patch and mark the trigger as ?NO FIX REQUIRED?.
> 
> As far as I have checked, there are no checks anywhere in the calls to this function to compare the marker with the table or any other entities in any form.
> 
> I certainly do not claim to understand this code as well as you or any other member of the hotspot team.

Well, this leads right to the root of the problem I have with this report. As you say, pos_idx does indeed come out of a marker object. It took me abut a minute to identify that this marker object is created in the function that sits right above the one your code assistant flagged as problematic -- even though I am not at all familiar with this code. It looks clear to me that, given the right call sequence for calls that create a marker and then consume it here, the check on pos_idx will ensure that we don't drop off the end of the list with a null pointer. So, it looks very liek this code has been designed so that the presence of a marker with a suitable pos_idx is intended to ensure this loop terminates before that happens. I am sure someone in this project knows whether that is the case but it is not you or your coding assistant.

I'm not suggesting that that calling sequence is actually right and that the check for pos_idx will definitely avoid dropping off the end. Indeed, I would welcome a bug that proved it to be wrong. However, what is clear that both you and your coding assistant have failed to appreciate how some relatively obvious parts of this design actually operate. That renders your (or your tool's) analysis a shallow and unhelpful distraction; using it as an excuse to raise a purported 'issue' in the absence of any evidence of an actual issue is very much a waste of time for this project's reviewers.

Your error is compounded by the fact that you (or more likely your coding assistant) are suggesting changes which, because they are not founded in a correct understanding of the design, could potentially lead to worse outcomes than the speculative nullptr dereference they are intended to remedy -- as I explained when discussing your change to the control flow logic in the ALDC code. So, not only is this report unhelpful it is potentially harmful.

Ultimately the takeaway here is that the OpenJDK bug system is not here to report, review and add patches to remedy issues that you or your code assistant tool invents on the basis of misinformed assumptions. It is here to report, review and add patches to remedy issues that can be shown to actually affect the correct operation of the JVM and JDK,either by a reproducible test or by well-reasoned argument. So, please do not continue to spam the project with bug reports like this simply because a potentially bogus patch will improve your experience with what is clearly a decidedly fallible tool.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26798#discussion_r2291265263

From kvn at openjdk.org  Thu Aug 21 15:25:57 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 21 Aug 2025 15:25:57 GMT
Subject: RFR: 8365633: Incorrect info is reported on hybrid CPU [v2]
In-Reply-To: <Ci8_ma7WvgKlP9KN-exqvmUDdXE-o7PUzDqyTA_5oLw=.c1371070-591d-465c-9ede-5ffce93d17ff@github.com>
References: <T2R7vtbL0AaZLcRKdAPjoM6I8kz6lclHBNnOXi8JIQY=.1af945fd-1592-423a-8a19-940dd1c531d3@github.com>
 <xeZsXlz_VUer4L2XraArNgofAegPxFvrpikCFdhYCBc=.8d7c0ac7-bd90-4e3b-b4db-461ee19db60a@github.com>
 <JCK35OXc5UU8BQx8GRfQN4YRg_IxztlBIUWeQg_ZjMU=.f32985ce-5f58-46f4-8973-d7efbe76514e@github.com>
 <ib48_HG9jOGypNfz5wOVNxNpozWhaijMbTl2vlPLgN8=.c4efa25d-1e3d-4b76-995c-6cdba9344061@github.com>
 <s77wxOBUOy0g0N7t6LSfcjBVA3yojDf_razmJvN_wpU=.f50cd5a2-5427-4e03-8185-b49bcbd18e45@github.com>
 <Ci8_ma7WvgKlP9KN-exqvmUDdXE-o7PUzDqyTA_5oLw=.c1371070-591d-465c-9ede-5ffce93d17ff@github.com>
Message-ID: <4YNU88rQlx2qGZaZS-F35jCeNdaS7a5_wvbZWtsThWQ=.72dec440-5e13-479d-a3c5-91048660dd02@github.com>

On Thu, 21 Aug 2025 06:26:43 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>>> > `(14 threads)` is just as wrong as it implies 1 processor/core with 14 threads.
>>> 
>>> I don't think so because I think it does not contain neither "per core", thus it implies "total number of threads is 14".
>>> 
>>> However I don't stick to show number of threads on hybrid CPU because the user can refer data sheet from processor model name. I think it can be changed to nothing to show or "14 threads per processor" for clarification. Which do you like?
>> 
>> I prefer nothing - thanks. "threads" is generally understood to be a sub-unit of "cores" which are a sub-unit of "processors", which might be a sub-unit of "sockets".
>
> I removed number of threads information on hybrid CPU. @dholmes-ora Can you review?  
> We can get following strings on hybrid CPU after this change:
> 
> 
> CPU: total 14 (initial active 14)  family 6 model 181 stepping 0 microcode 0xffffffff, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, clwb, hv, serialize, rdtscp, rdpid, fsrm, gfni, f16c, cet_ibt, cet_ss, hybrid
> CPU Model and flags from /proc/cpuinfo:
> model name      : Intel(R) Core(TM) Ultra 5 225U

@YaSuenag  Is it possible to find from CPUID or OS calls the information about hybrid CPU configuration?

"( 2 P cores, 8 E cores, 2 LP cores)" in you case.  I would prefer if for hybrid CPU we print that info instead of "(7 cores per cpu, 2 threads per core) ".

It is important information when we debug issue on such CPUs.

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

PR Comment: https://git.openjdk.org/jdk/pull/26808#issuecomment-3211088436

From phh at openjdk.org  Thu Aug 21 19:00:58 2025
From: phh at openjdk.org (Paul Hohensee)
Date: Thu, 21 Aug 2025 19:00:58 GMT
Subject: RFR: 8365917: Sort share/logging includes
In-Reply-To: <yVKq4z-VjDzM2UKJnuyqmIgsiTrm1P17p9TreJZGPcM=.8bb0451a-ab49-445f-9e79-a8d6e6d5c518@github.com>
References: <yVKq4z-VjDzM2UKJnuyqmIgsiTrm1P17p9TreJZGPcM=.8bb0451a-ab49-445f-9e79-a8d6e6d5c518@github.com>
Message-ID: <QmjYDYXPJmoCW24M0ZO5CCr_XMNTPYpXPfQF_KpL-24=.ef556882-3004-4c45-8426-a237b0825fff@github.com>

On Thu, 21 Aug 2025 09:54:33 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> This PR sorts the includes in `hotspot/share/logging` using `SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted`.
> 
> Passes `tier1`.

Marked as reviewed by phh (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26877#pullrequestreview-3141927990

From duke at openjdk.org  Thu Aug 21 19:00:58 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Thu, 21 Aug 2025 19:00:58 GMT
Subject: Integrated: 8365917: Sort share/logging includes
In-Reply-To: <yVKq4z-VjDzM2UKJnuyqmIgsiTrm1P17p9TreJZGPcM=.8bb0451a-ab49-445f-9e79-a8d6e6d5c518@github.com>
References: <yVKq4z-VjDzM2UKJnuyqmIgsiTrm1P17p9TreJZGPcM=.8bb0451a-ab49-445f-9e79-a8d6e6d5c518@github.com>
Message-ID: <V6txLLngx7VMkiqN9kKFZcQno7jlavZy3nMhx96GoCQ=.1da9462f-7ae0-447a-9a77-0e914b0397c2@github.com>

On Thu, 21 Aug 2025 09:54:33 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> This PR sorts the includes in `hotspot/share/logging` using `SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted`.
> 
> Passes `tier1`.

This pull request has now been integrated.

Changeset: 11eccfc8
Author:    Francesco Andreuzzi <andreuzzi.francesco at gmail.com>
Committer: Paul Hohensee <phh at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/11eccfc85f8495b0cbc3965fd69911a6c7ed0140
Stats:     8 lines in 5 files changed: 5 ins; 3 del; 0 mod

8365917: Sort share/logging includes

Reviewed-by: ayang, phh

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

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

From coleenp at openjdk.org  Thu Aug 21 19:28:53 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 21 Aug 2025 19:28:53 GMT
Subject: RFR: 8365814: Consolidate has_been_archived() and
 has_been_buffered() in ArchiveBuilder
In-Reply-To: <3i3MuMxtUXzV-XEZylDgQV9MCCGOF8at-HH0Ls6w2lo=.5bdec7cb-2bc6-45d0-9e6a-b13b05851208@github.com>
References: <CjcbzPgOlwDABX6nFwnR4TgkD-FcK8VSXZuz5tsSNJE=.ee6b4d03-9855-4bbd-9031-4a657dda358e@github.com>
 <F7u5rGal7Kh4KZz1RGjeWPDvXD_rqKO1lySjtWiaH6M=.b9ba5536-a5d6-4f92-8b38-603ddcf1463d@github.com>
 <3i3MuMxtUXzV-XEZylDgQV9MCCGOF8at-HH0Ls6w2lo=.5bdec7cb-2bc6-45d0-9e6a-b13b05851208@github.com>
Message-ID: <cW_QXxbUK2Gx4B8Q_QzEK_kpZkJ8LEjCM4ZGGhy8cmg=.10e8c074-e84c-4219-8d43-539d3f8d286b@github.com>

On Thu, 21 Aug 2025 00:59:22 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/share/cds/archiveBuilder.hpp line 448:
>> 
>>> 446:   bool has_been_archived(address src_addr) const;
>>> 447:   template <typename T> bool has_been_archived(T src_addr) const {
>>> 448:     return has_been_archived((address)src_addr);
>> 
>> What's the point of having a template if you're going to erase the type?
>
> I did it this way so the caller doesn't need to do casting like
> 
> 
> Method* m = xxx();
> if (has_been_archived((address)m)) {.....}
> 
> 
> Is there a better way to indicate that `has_been_archived()` takes any pointer?

I think you probably should cast away the type at the call sites. The template's not going to make it any more type-safe.  It's sort of deceiving that it kinda looks type safe.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26853#discussion_r2291943273

From coleenp at openjdk.org  Thu Aug 21 20:24:55 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 21 Aug 2025 20:24:55 GMT
Subject: RFR: 8365814: Consolidate has_been_archived() and
 has_been_buffered() in ArchiveBuilder
In-Reply-To: <CjcbzPgOlwDABX6nFwnR4TgkD-FcK8VSXZuz5tsSNJE=.ee6b4d03-9855-4bbd-9031-4a657dda358e@github.com>
References: <CjcbzPgOlwDABX6nFwnR4TgkD-FcK8VSXZuz5tsSNJE=.ee6b4d03-9855-4bbd-9031-4a657dda358e@github.com>
Message-ID: <f2fMnFMxIfbRpEPJVJ0lZtcTGUGKZhadPdh4xmIswRg=.3e6633d0-d428-481a-8d46-e555daf81219@github.com>

On Wed, 20 Aug 2025 04:01:13 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Merged the two methods into one: `ArchiveBuilder::has_been_archived()`. Added comments and asserts to explain what the expected result is.

I see now that the type hiding template was already there.  This looks good.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26853#pullrequestreview-3142168473

From dholmes at openjdk.org  Fri Aug 22 00:16:50 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 22 Aug 2025 00:16:50 GMT
Subject: RFR: 8365633: Incorrect info is reported on hybrid CPU [v2]
In-Reply-To: <4YNU88rQlx2qGZaZS-F35jCeNdaS7a5_wvbZWtsThWQ=.72dec440-5e13-479d-a3c5-91048660dd02@github.com>
References: <T2R7vtbL0AaZLcRKdAPjoM6I8kz6lclHBNnOXi8JIQY=.1af945fd-1592-423a-8a19-940dd1c531d3@github.com>
 <xeZsXlz_VUer4L2XraArNgofAegPxFvrpikCFdhYCBc=.8d7c0ac7-bd90-4e3b-b4db-461ee19db60a@github.com>
 <JCK35OXc5UU8BQx8GRfQN4YRg_IxztlBIUWeQg_ZjMU=.f32985ce-5f58-46f4-8973-d7efbe76514e@github.com>
 <ib48_HG9jOGypNfz5wOVNxNpozWhaijMbTl2vlPLgN8=.c4efa25d-1e3d-4b76-995c-6cdba9344061@github.com>
 <s77wxOBUOy0g0N7t6LSfcjBVA3yojDf_razmJvN_wpU=.f50cd5a2-5427-4e03-8185-b49bcbd18e45@github.com>
 <Ci8_ma7WvgKlP9KN-exqvmUDdXE-o7PUzDqyTA_5oLw=.c1371070-591d-465c-9ede-5ffce93d17ff@github.com>
 <4YNU88rQlx2qGZaZS-F35jCeNdaS7a5_wvbZWtsThWQ=.72dec440-5e13-479d-a3c5-91048660dd02@github.com>
Message-ID: <IAVHt1Cv_PFrI56cklctn6p2Jj76GKb8-SGHwF44kwI=.106c17f2-284e-40d2-ba5f-943c2a8e3d52@github.com>

On Thu, 21 Aug 2025 15:23:25 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> I removed number of threads information on hybrid CPU. @dholmes-ora Can you review?  
>> We can get following strings on hybrid CPU after this change:
>> 
>> 
>> CPU: total 14 (initial active 14)  family 6 model 181 stepping 0 microcode 0xffffffff, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, clwb, hv, serialize, rdtscp, rdpid, fsrm, gfni, f16c, cet_ibt, cet_ss, hybrid
>> CPU Model and flags from /proc/cpuinfo:
>> model name      : Intel(R) Core(TM) Ultra 5 225U
>
> @YaSuenag  Is it possible to find from CPUID or OS calls the information about hybrid CPU configuration?
> 
> "( 2 P cores, 8 E cores, 2 LP cores)" in you case.  I would prefer if for hybrid CPU we print that info instead of "(7 cores per cpu, 2 threads per core) ".
> 
> It is important information when we debug issue on such CPUs.

@vnkozlov I'd like it if we could produce accurate information too but the OS doesn't supply it to us and doing it via CPUID is absurdly complicated. VMVersion is not setup to handle different kinds of cores.

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

PR Comment: https://git.openjdk.org/jdk/pull/26808#issuecomment-3212532526

From kvn at openjdk.org  Fri Aug 22 00:25:53 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 22 Aug 2025 00:25:53 GMT
Subject: RFR: 8365633: Incorrect info is reported on hybrid CPU [v2]
In-Reply-To: <IAVHt1Cv_PFrI56cklctn6p2Jj76GKb8-SGHwF44kwI=.106c17f2-284e-40d2-ba5f-943c2a8e3d52@github.com>
References: <T2R7vtbL0AaZLcRKdAPjoM6I8kz6lclHBNnOXi8JIQY=.1af945fd-1592-423a-8a19-940dd1c531d3@github.com>
 <xeZsXlz_VUer4L2XraArNgofAegPxFvrpikCFdhYCBc=.8d7c0ac7-bd90-4e3b-b4db-461ee19db60a@github.com>
 <JCK35OXc5UU8BQx8GRfQN4YRg_IxztlBIUWeQg_ZjMU=.f32985ce-5f58-46f4-8973-d7efbe76514e@github.com>
 <ib48_HG9jOGypNfz5wOVNxNpozWhaijMbTl2vlPLgN8=.c4efa25d-1e3d-4b76-995c-6cdba9344061@github.com>
 <s77wxOBUOy0g0N7t6LSfcjBVA3yojDf_razmJvN_wpU=.f50cd5a2-5427-4e03-8185-b49bcbd18e45@github.com>
 <Ci8_ma7WvgKlP9KN-exqvmUDdXE-o7PUzDqyTA_5oLw=.c1371070-591d-465c-9ede-5ffce93d17ff@github.com>
 <4YNU88rQlx2qGZaZS-F35jCeNdaS7a5_wvbZWtsThWQ=.72dec440-5e13-479d-a3c5-91048660dd02@github.com>
 <IAVHt1Cv_PFrI56cklctn6p2Jj76GKb8-SGHwF44kwI=.106c17f2-284e-40d2-ba5f-943c2a8e3d52@github.com>
Message-ID: <fyexn4O7eNhtUUvmlVqY7DcohnOxOSTHKr_33dJ4mkQ=.08ef0d33-82e1-498c-b629-bf1a698192ac@github.com>

On Fri, 22 Aug 2025 00:14:16 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> @YaSuenag  Is it possible to find from CPUID or OS calls the information about hybrid CPU configuration?
>> 
>> "( 2 P cores, 8 E cores, 2 LP cores)" in you case.  I would prefer if for hybrid CPU we print that info instead of "(7 cores per cpu, 2 threads per core) ".
>> 
>> It is important information when we debug issue on such CPUs.
>
> @vnkozlov I'd like it if we could produce accurate information too but the OS doesn't supply it to us and doing it via CPUID is absurdly complicated. VMVersion is not setup to handle different kinds of cores.

@dholmes-ora okay. Then we need, at least, to print "(hybrid cpu)".

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

PR Comment: https://git.openjdk.org/jdk/pull/26808#issuecomment-3212551582

From ysuenaga at openjdk.org  Fri Aug 22 00:35:52 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Fri, 22 Aug 2025 00:35:52 GMT
Subject: RFR: 8365633: Incorrect info is reported on hybrid CPU [v2]
In-Reply-To: <4YNU88rQlx2qGZaZS-F35jCeNdaS7a5_wvbZWtsThWQ=.72dec440-5e13-479d-a3c5-91048660dd02@github.com>
References: <T2R7vtbL0AaZLcRKdAPjoM6I8kz6lclHBNnOXi8JIQY=.1af945fd-1592-423a-8a19-940dd1c531d3@github.com>
 <xeZsXlz_VUer4L2XraArNgofAegPxFvrpikCFdhYCBc=.8d7c0ac7-bd90-4e3b-b4db-461ee19db60a@github.com>
 <JCK35OXc5UU8BQx8GRfQN4YRg_IxztlBIUWeQg_ZjMU=.f32985ce-5f58-46f4-8973-d7efbe76514e@github.com>
 <ib48_HG9jOGypNfz5wOVNxNpozWhaijMbTl2vlPLgN8=.c4efa25d-1e3d-4b76-995c-6cdba9344061@github.com>
 <s77wxOBUOy0g0N7t6LSfcjBVA3yojDf_razmJvN_wpU=.f50cd5a2-5427-4e03-8185-b49bcbd18e45@github.com>
 <Ci8_ma7WvgKlP9KN-exqvmUDdXE-o7PUzDqyTA_5oLw=.c1371070-591d-465c-9ede-5ffce93d17ff@github.com>
 <4YNU88rQlx2qGZaZS-F35jCeNdaS7a5_wvbZWtsThWQ=.72dec440-5e13-479d-a3c5-91048660dd02@github.com>
Message-ID: <tz_fA2Q0_xKAKWiJW8BXqlJrHUVUQWhLyoIHUhv2Flo=.bd0ebd44-b054-4282-a1bb-b5b06e0eead6@github.com>

On Thu, 21 Aug 2025 15:23:25 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Is it possible to find from CPUID or OS calls the information about hybrid CPU configuration?

I hope so too, but it is difficult as @dholmes-ora said unfortunately.

We can use `1Ah` leaf of `CPUID` to identify whether P core or not like [this code](https://github.com/YaSuenag/garakuta/blob/ebe4c8da6ed890f6144c1c32ff02b5ed3200df14/check-hybrid-cores/hy-core-check.c#L60-L95). However we would face following problem:

1. Leaf `1Ah` returns the information for the logical processor which was issued - we need to issue `CPUID` on all of logical processors with processor affinity.
2. We can identify "Intel Core" (P core) or not ("Intel Atom") via leaf `1Ah`, however we might not distinguish whether E core or LP core.
    * In Core Ultra 5 225U, both E core and LP core is Crestmont, thus they have same native model ID.

OS (Windows and Linux at least) cannot expose information about details of CPU cores AFAICS, thus it is difficult to show processor details to the user on `VM.info` and hs_err log.

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

PR Comment: https://git.openjdk.org/jdk/pull/26808#issuecomment-3212570100

From kvn at openjdk.org  Fri Aug 22 00:40:52 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 22 Aug 2025 00:40:52 GMT
Subject: RFR: 8365633: Incorrect info is reported on hybrid CPU [v2]
In-Reply-To: <tz_fA2Q0_xKAKWiJW8BXqlJrHUVUQWhLyoIHUhv2Flo=.bd0ebd44-b054-4282-a1bb-b5b06e0eead6@github.com>
References: <T2R7vtbL0AaZLcRKdAPjoM6I8kz6lclHBNnOXi8JIQY=.1af945fd-1592-423a-8a19-940dd1c531d3@github.com>
 <xeZsXlz_VUer4L2XraArNgofAegPxFvrpikCFdhYCBc=.8d7c0ac7-bd90-4e3b-b4db-461ee19db60a@github.com>
 <JCK35OXc5UU8BQx8GRfQN4YRg_IxztlBIUWeQg_ZjMU=.f32985ce-5f58-46f4-8973-d7efbe76514e@github.com>
 <ib48_HG9jOGypNfz5wOVNxNpozWhaijMbTl2vlPLgN8=.c4efa25d-1e3d-4b76-995c-6cdba9344061@github.com>
 <s77wxOBUOy0g0N7t6LSfcjBVA3yojDf_razmJvN_wpU=.f50cd5a2-5427-4e03-8185-b49bcbd18e45@github.com>
 <Ci8_ma7WvgKlP9KN-exqvmUDdXE-o7PUzDqyTA_5oLw=.c1371070-591d-465c-9ede-5ffce93d17ff@github.com>
 <4YNU88rQlx2qGZaZS-F35jCeNdaS7a5_wvbZWtsThWQ=.72dec440-5e13-479d-a3c5-91048660dd02@github.com>
 <tz_fA2Q0_xKAKWiJW8BXqlJrHUVUQWhLyoIHUhv2Flo=.bd0ebd44-b054-4282-a1bb-b5b06e0eead6@github.com>
Message-ID: <c8aWH66b0Dfh-RpN7uko0WbDR05nsYxhW-lRjk3pG2Y=.f8f33c1e-4a6c-46eb-9905-5515aef7ec50@github.com>

On Fri, 22 Aug 2025 00:33:10 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> @YaSuenag  Is it possible to find from CPUID or OS calls the information about hybrid CPU configuration?
>> 
>> "( 2 P cores, 8 E cores, 2 LP cores)" in you case.  I would prefer if for hybrid CPU we print that info instead of "(7 cores per cpu, 2 threads per core) ".
>> 
>> It is important information when we debug issue on such CPUs.
>
>> Is it possible to find from CPUID or OS calls the information about hybrid CPU configuration?
> 
> I hope so too, but it is difficult as @dholmes-ora said unfortunately.
> 
> We can use `1Ah` leaf of `CPUID` to identify whether P core or not like [this code](https://github.com/YaSuenag/garakuta/blob/ebe4c8da6ed890f6144c1c32ff02b5ed3200df14/check-hybrid-cores/hy-core-check.c#L60-L95). However we would face following problem:
> 
> 1. Leaf `1Ah` returns the information for the logical processor which was issued - we need to issue `CPUID` on all of logical processors with processor affinity.
> 2. We can identify "Intel Core" (P core) or not ("Intel Atom") via leaf `1Ah`, however we might not distinguish whether E core or LP core.
>     * In Core Ultra 5 225U, both E core and LP core is Crestmont, thus they have same native model ID.
> 
> OS (Windows and Linux at least) cannot expose information about details of CPU cores AFAICS, thus it is difficult to show processor details to the user on `VM.info` and hs_err log.

@YaSuenag Thank you for additional information. Yes, I agree with David and you.

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

PR Comment: https://git.openjdk.org/jdk/pull/26808#issuecomment-3212576807

From ysuenaga at openjdk.org  Fri Aug 22 00:58:26 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Fri, 22 Aug 2025 00:58:26 GMT
Subject: RFR: 8365633: Incorrect info is reported on hybrid CPU [v4]
In-Reply-To: <T2R7vtbL0AaZLcRKdAPjoM6I8kz6lclHBNnOXi8JIQY=.1af945fd-1592-423a-8a19-940dd1c531d3@github.com>
References: <T2R7vtbL0AaZLcRKdAPjoM6I8kz6lclHBNnOXi8JIQY=.1af945fd-1592-423a-8a19-940dd1c531d3@github.com>
Message-ID: <RyaCh5StldhzMTgCz-6wweIhrVMLBh59aiiCL5E4FYU=.724d05dd-2a8c-4aff-ac72-6cc08d38d60d@github.com>

> `VM.info` DCmd reports CPU information. I ran this on Intel Core Ultra 5 225U , then I got following result:
> 
> 
> CPU: total 14 (initial active 14) (7 cores per cpu, 2 threads per core) family 6 model 181 stepping 0 microcode 0xffffffff, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, clwb, hv, serialize, rdtscp, rdpid, fsrm, gfni, f16c, cet_ibt, cet_ss
> CPU Model and flags from /proc/cpuinfo:
> model name : Intel(R) Core(TM) Ultra 5 225U
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm pni pclmulqdq monitor est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave osxsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch fsgsbase bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb intel_pt sha_ni umip gfni vaes vpclmulqdq rdpid ibrs ibpb stibp ssbd
> 
> 
> It reports "7 cores per cpu, 2 threads per core". 225U has hybrid architecture - 2 P cores, 8 E cores, 2 LP cores, and also P core has 2 threads per core. Then it should be "12 cores, 14 threads".
> https://www.intel.com/content/www/us/en/products/sku/241861/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html
> 
> According to Intel Software Developer's Manual, it seems to be difficult to get number of physical cores. In Linux kernel, it seems to be calculated by complex logic: https://github.com/torvalds/linux/blob/v6.16/arch/x86/kernel/smpboot.c#L567-L597
> In addition, all of P cores might not be enabled HT. Thus to show only number of threads is reasonable at this point.

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

  Indicate "(hybrid)" on hybrid CPU

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26808/files
  - new: https://git.openjdk.org/jdk/pull/26808/files/b1fd242c..45c85012

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

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

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

From ysuenaga at openjdk.org  Fri Aug 22 00:58:26 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Fri, 22 Aug 2025 00:58:26 GMT
Subject: RFR: 8365633: Incorrect info is reported on hybrid CPU [v2]
In-Reply-To: <IAVHt1Cv_PFrI56cklctn6p2Jj76GKb8-SGHwF44kwI=.106c17f2-284e-40d2-ba5f-943c2a8e3d52@github.com>
References: <T2R7vtbL0AaZLcRKdAPjoM6I8kz6lclHBNnOXi8JIQY=.1af945fd-1592-423a-8a19-940dd1c531d3@github.com>
 <xeZsXlz_VUer4L2XraArNgofAegPxFvrpikCFdhYCBc=.8d7c0ac7-bd90-4e3b-b4db-461ee19db60a@github.com>
 <JCK35OXc5UU8BQx8GRfQN4YRg_IxztlBIUWeQg_ZjMU=.f32985ce-5f58-46f4-8973-d7efbe76514e@github.com>
 <ib48_HG9jOGypNfz5wOVNxNpozWhaijMbTl2vlPLgN8=.c4efa25d-1e3d-4b76-995c-6cdba9344061@github.com>
 <s77wxOBUOy0g0N7t6LSfcjBVA3yojDf_razmJvN_wpU=.f50cd5a2-5427-4e03-8185-b49bcbd18e45@github.com>
 <Ci8_ma7WvgKlP9KN-exqvmUDdXE-o7PUzDqyTA_5oLw=.c1371070-591d-465c-9ede-5ffce93d17ff@github.com>
 <4YNU88rQlx2qGZaZS-F35jCeNdaS7a5_wvbZWtsThWQ=.72dec440-5e13-479d-a3c5-91048660dd02@github.com>
 <IAVHt1Cv_PFrI56cklctn6p2Jj76GKb8-SGHwF44kwI=.106c17f2-284e-40d2-ba5f-943c2a8e3d52@github.com>
Message-ID: <NFws3_z-rI6zUGOeR0g-GyrlGWesOH6nMikRGsBM8r4=.c1a6a089-5644-4364-9dd2-0146e1869cce@github.com>

On Fri, 22 Aug 2025 00:14:16 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> @YaSuenag  Is it possible to find from CPUID or OS calls the information about hybrid CPU configuration?
>> 
>> "( 2 P cores, 8 E cores, 2 LP cores)" in you case.  I would prefer if for hybrid CPU we print that info instead of "(7 cores per cpu, 2 threads per core) ".
>> 
>> It is important information when we debug issue on such CPUs.
>
> @vnkozlov I'd like it if we could produce accurate information too but the OS doesn't supply it to us and doing it via CPUID is absurdly complicated. VMVersion is not setup to handle different kinds of cores.

Thanks a lot @dholmes-ora and @vnkozlov !
I updated this PR to show `(hybrid)` as @vnkozlov commented. We can see following strings after this change. I hope this patch confortable for you.


CPU: total 14 (initial active 14) (hybrid) family 6 model 181 stepping 0 microcode 0xffffffff, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, clwb, hv, serialize, rdtscp, rdpid, fsrm, gfni, f16c, cet_ibt, cet_ss, hybrid
CPU Model and flags from /proc/cpuinfo:
model name      : Intel(R) Core(TM) Ultra 5 225U

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

PR Comment: https://git.openjdk.org/jdk/pull/26808#issuecomment-3212598807

From kvn at openjdk.org  Fri Aug 22 01:09:51 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 22 Aug 2025 01:09:51 GMT
Subject: RFR: 8365633: Incorrect info is reported on hybrid CPU [v4]
In-Reply-To: <RyaCh5StldhzMTgCz-6wweIhrVMLBh59aiiCL5E4FYU=.724d05dd-2a8c-4aff-ac72-6cc08d38d60d@github.com>
References: <T2R7vtbL0AaZLcRKdAPjoM6I8kz6lclHBNnOXi8JIQY=.1af945fd-1592-423a-8a19-940dd1c531d3@github.com>
 <RyaCh5StldhzMTgCz-6wweIhrVMLBh59aiiCL5E4FYU=.724d05dd-2a8c-4aff-ac72-6cc08d38d60d@github.com>
Message-ID: <xElSgulg0obCqtIM2IeEz4mj-ldt65ORaSO8cpuICiA=.8722c5b8-cad7-4c1d-9fdb-87fae1c7352f@github.com>

On Fri, 22 Aug 2025 00:58:26 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> `VM.info` DCmd reports CPU information. I ran this on Intel Core Ultra 5 225U , then I got following result:
>> 
>> 
>> CPU: total 14 (initial active 14) (7 cores per cpu, 2 threads per core) family 6 model 181 stepping 0 microcode 0xffffffff, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, clwb, hv, serialize, rdtscp, rdpid, fsrm, gfni, f16c, cet_ibt, cet_ss
>> CPU Model and flags from /proc/cpuinfo:
>> model name : Intel(R) Core(TM) Ultra 5 225U
>> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm pni pclmulqdq monitor est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave osxsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch fsgsbase bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb intel_pt sha_ni umip gfni vaes vpclmulqdq rdpid ibrs ibpb stibp ssbd
>> 
>> 
>> It reports "7 cores per cpu, 2 threads per core". 225U has hybrid architecture - 2 P cores, 8 E cores, 2 LP cores, and also P core has 2 threads per core. Then it should be "12 cores, 14 threads".
>> https://www.intel.com/content/www/us/en/products/sku/241861/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html
>> 
>> According to Intel Software Developer's Manual, it seems to be difficult to get number of physical cores. In Linux kernel, it seems to be calculated by complex logic: https://github.com/torvalds/linux/blob/v6.16/arch/x86/kernel/smpboot.c#L567-L597
>> In addition, all of P cores might not be enabled HT. Thus to show only number of threads is reasonable at this point.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Indicate "(hybrid)" on hybrid CPU

Good. I will run out tests and let you know results.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26808#pullrequestreview-3142699505

From fbredberg at openjdk.org  Fri Aug 22 07:51:53 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Fri, 22 Aug 2025 07:51:53 GMT
Subject: RFR: 8365189: Remove LockingMode related code from arm32
In-Reply-To: <Vm2kRDGrPkpecupTlwc8uE8B5EU6byECO5voGJ0S878=.86ac09cf-b21a-4c0e-9a0c-7c9654a63995@github.com>
References: <bvw0sMNTLzhoms1UW34LXiFrkKDysBfeLAQftPjBh5o=.ddd3c817-4094-4cfe-afa2-4c751eae6814@github.com>
 <ObdNVa5OnCj-R2Nx01CHQ3LwUfhmchcTwi7NLy-9PNo=.6d64d0f0-47ca-49f2-ac9a-e21be9f03090@github.com>
 <Vm2kRDGrPkpecupTlwc8uE8B5EU6byECO5voGJ0S878=.86ac09cf-b21a-4c0e-9a0c-7c9654a63995@github.com>
Message-ID: <MYmPauLsn88O5LtGbNKu617QeT23Tyu3kK89uZEPdS4=.d34efe03-1bf9-46bb-8466-6c928593324b@github.com>

On Thu, 21 Aug 2025 14:22:28 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

>> @bulasevich
>> I've run rudimentary tests using QEMU, but it would be nice if you could take it for a spin on real hardware.
>
>> @bulasevich I've run rudimentary tests using QEMU, but it would be nice if you could take it for a spin on real hardware.
> 
> Hi. Confirmed on real hardware, works fine. :)

@bulasevich
> Hi. Confirmed on real hardware, works fine. :)

Debugging stuff that works in the simulator, but not on real hardware is the most boring experience. So I'm happy it worked. Thank you for testing.

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

PR Comment: https://git.openjdk.org/jdk/pull/26795#issuecomment-3213422844

From fbredberg at openjdk.org  Fri Aug 22 07:55:52 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Fri, 22 Aug 2025 07:55:52 GMT
Subject: RFR: 8365189: Remove LockingMode related code from arm32
In-Reply-To: <bvw0sMNTLzhoms1UW34LXiFrkKDysBfeLAQftPjBh5o=.ddd3c817-4094-4cfe-afa2-4c751eae6814@github.com>
References: <bvw0sMNTLzhoms1UW34LXiFrkKDysBfeLAQftPjBh5o=.ddd3c817-4094-4cfe-afa2-4c751eae6814@github.com>
Message-ID: <_GDc-F4Dfncfeg7qesndlsjrF4VNS7wvRSAcLLBALWU=.7b06d3f7-03ef-4682-a436-401628be15b9@github.com>

On Fri, 15 Aug 2025 09:29:04 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
> 
> This PR removes `LockingMode` related code from the **arm32** platform.
> 
> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.

Thank you for the reviews. But since I don't like to integrate on a Friday, I'll let it wait until Monday.

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

PR Comment: https://git.openjdk.org/jdk/pull/26795#issuecomment-3213436129

From duke at openjdk.org  Fri Aug 22 08:58:34 2025
From: duke at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Fri, 22 Aug 2025 08:58:34 GMT
Subject: RFR: 8364103: Convert existing sprintf-chains to stringStream
Message-ID: <xbbCS-TR5liWQKlJCsaDMsmLDZNuLIw54t9tCpphXTs=.78fc8a50-f39b-4253-8c10-9376ff25235b@github.com>

Hi all,

This PR refactors `javaClasses`' `print_stack_element_to_stream` to use a `stringStream` instead of manually maintaining a buffer with `os::snprintf` chains.

The JBS issue outlines to do this for all occurrences of `snprintf`-like chains. The majority of the calls to `os::snprintf`, `os::snprintf_checked`, `os::vsnprintf`, etc. occur just once. `LogTagSet::vwrite` is the only place to my knowledge where there remains a `vsnprintf` chain using manual buffer arithmetic. After consulting @jdksjolen, we decided that due to the
a) low-level nature of the code, and 
b) widespread usage of logging in the VM, 
this should probably warrant a larger discussion and/or separate issue. Personally, I feel like the performance & correctness risks of introducing a high-level abstraction here outweighs the benefits. 

I've run tests with JDK tiers 1-3 on macOS (AArch64, x64), Linux (AArch64, x64), and Windows (x64); all green.

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

Commit messages:
 - Refactor stack trace printing to use stringStream.

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

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

From duke at openjdk.org  Fri Aug 22 09:06:04 2025
From: duke at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Fri, 22 Aug 2025 09:06:04 GMT
Subject: RFR: 8365765: thread.inline.hpp includes the wrong primary header file
Message-ID: <60ojUdn_wXfg3Wl1PBatvNjMTEMFg5paCB5U0e0YqzU=.d6c2feeb-3409-4367-9a7b-f92fab7c411a@github.com>

Hi all,

This ensures `thread.inline.hpp` adheres to the style guide:
> All .inline.hpp files should include their corresponding .hpp file as the first include line with a blank line separating it from the rest of the include lines. [...]

I've run tests with JDK tiers 1-3 on macOS (AArch64, x64), Linux (AArch64, x64), and Windows (x64); all green.

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

Commit messages:
 - Fix primary header for thread.inline.hpp.

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

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

From duke at openjdk.org  Fri Aug 22 09:09:53 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Fri, 22 Aug 2025 09:09:53 GMT
Subject: RFR: 8365975: Sort share/memory includes
Message-ID: <TUfg-TEPul_3CAv9kmnFbiJ9C5vUxixuA8nJyk9F6TY=.e438c1c4-02d7-4f57-a810-93d1116091d7@github.com>

This PR sorts the includes in `hotspot/share/memory` using `SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted`, and removing a couple of unnecessary include statements.

Passes `tier1`.

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

Commit messages:
 - nn
 - revert
 - sort

Changes: https://git.openjdk.org/jdk/pull/26897/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26897&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365975
  Stats: 23 lines in 14 files changed: 11 ins; 10 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/26897.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26897/head:pull/26897

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

From stefank at openjdk.org  Fri Aug 22 09:36:52 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 22 Aug 2025 09:36:52 GMT
Subject: RFR: 8365765: thread.inline.hpp includes the wrong primary header
 file
In-Reply-To: <60ojUdn_wXfg3Wl1PBatvNjMTEMFg5paCB5U0e0YqzU=.d6c2feeb-3409-4367-9a7b-f92fab7c411a@github.com>
References: <60ojUdn_wXfg3Wl1PBatvNjMTEMFg5paCB5U0e0YqzU=.d6c2feeb-3409-4367-9a7b-f92fab7c411a@github.com>
Message-ID: <EmpnQqUkSKQ0dANFjfvNQQaCX8pBcpu3XER1iprulYU=.9e70994f-fef6-45fc-96e9-8625ea2fcfc8@github.com>

On Fri, 22 Aug 2025 08:57:54 GMT, Paul H?bner <duke at openjdk.org> wrote:

> Hi all,
> 
> This ensures `thread.inline.hpp` adheres to the style guide:
>> All .inline.hpp files should include their corresponding .hpp file as the first include line with a blank line separating it from the rest of the include lines. [...]
> 
> I've run tests with JDK tiers 1-3 on macOS (AArch64, x64), Linux (AArch64, x64), and Windows (x64); all green.

Thanks for cleaning this up!

I've left a nit that I'd like to get fixed.

Given that this PR changes the include headers it would be prudent to explicitly test building with precompiled headers disabled (Configure flag --disable-precompiled-headers) in addition to running tier1 testing.

src/hotspot/share/runtime/thread.inline.hpp line 29:

> 27: #define SHARE_RUNTIME_THREAD_INLINE_HPP
> 28: 
> 29: #include "thread.hpp"

We tend to include the directory even if it is implied by the current file's location.

Suggestion:

#include "runtime/thread.hpp"

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

Changes requested by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26896#pullrequestreview-3143789922
PR Review Comment: https://git.openjdk.org/jdk/pull/26896#discussion_r2293208048

From duke at openjdk.org  Fri Aug 22 09:44:43 2025
From: duke at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Fri, 22 Aug 2025 09:44:43 GMT
Subject: RFR: 8365765: thread.inline.hpp includes the wrong primary header
 file [v2]
In-Reply-To: <60ojUdn_wXfg3Wl1PBatvNjMTEMFg5paCB5U0e0YqzU=.d6c2feeb-3409-4367-9a7b-f92fab7c411a@github.com>
References: <60ojUdn_wXfg3Wl1PBatvNjMTEMFg5paCB5U0e0YqzU=.d6c2feeb-3409-4367-9a7b-f92fab7c411a@github.com>
Message-ID: <1879F3rreGMN4B7I0ZVl0AyUsjVilJ-dYKG0ZDytWGI=.7f63ae41-e1d2-4481-ae15-e0d2c7473ca1@github.com>

> Hi all,
> 
> This ensures `thread.inline.hpp` adheres to the style guide:
>> All .inline.hpp files should include their corresponding .hpp file as the first include line with a blank line separating it from the rest of the include lines. [...]
> 
> I've run tests with JDK tiers 1-3 on macOS (AArch64, x64), Linux (AArch64, x64), and Windows (x64); all green.

Paul H?bner has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/share/runtime/thread.inline.hpp
  
  Co-authored-by: Stefan Karlsson <stefan.karlsson at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26896/files
  - new: https://git.openjdk.org/jdk/pull/26896/files/246d02ef..6f671c61

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

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

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

From duke at openjdk.org  Fri Aug 22 09:45:10 2025
From: duke at openjdk.org (Anton Artemov)
Date: Fri, 22 Aug 2025 09:45:10 GMT
Subject: RFR: 8361370: runtime/Thread/TestThreadDumpMonitorContention.java
 fails due to time out on Windows
Message-ID: <BZscaovi-OCDqFducnsfhzKJxLN-nh0nz1hlYEvEXTM=.c7e3342f-b587-46a3-a703-8b5773fd623a@github.com>

Hi, please consider the following changes:

Jstack streaming output should be disabled in the test as JDK-8354461 suggest. 

When disabled, the test does not hang with ZGC enabled. 

Tested locally.

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

Commit messages:
 - 8361370: Fixed test timeout on Windows

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

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

From stefank at openjdk.org  Fri Aug 22 09:55:51 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 22 Aug 2025 09:55:51 GMT
Subject: RFR: 8365765: thread.inline.hpp includes the wrong primary header
 file [v2]
In-Reply-To: <1879F3rreGMN4B7I0ZVl0AyUsjVilJ-dYKG0ZDytWGI=.7f63ae41-e1d2-4481-ae15-e0d2c7473ca1@github.com>
References: <60ojUdn_wXfg3Wl1PBatvNjMTEMFg5paCB5U0e0YqzU=.d6c2feeb-3409-4367-9a7b-f92fab7c411a@github.com>
 <1879F3rreGMN4B7I0ZVl0AyUsjVilJ-dYKG0ZDytWGI=.7f63ae41-e1d2-4481-ae15-e0d2c7473ca1@github.com>
Message-ID: <oks4Kp5V51jq9A9zMN8Y5vp-C1y_BcR9ES3syKHb2Tw=.4d10d583-2380-40cd-ab8d-64297d646334@github.com>

On Fri, 22 Aug 2025 09:44:43 GMT, Paul H?bner <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This ensures `thread.inline.hpp` adheres to the style guide:
>>> All .inline.hpp files should include their corresponding .hpp file as the first include line with a blank line separating it from the rest of the include lines. [...]
>> 
>> I've run tests with JDK tiers 1-3 on macOS (AArch64, x64), Linux (AArch64, x64), and Windows (x64); all green.
>
> Paul H?bner has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/runtime/thread.inline.hpp
>   
>   Co-authored-by: Stefan Karlsson <stefan.karlsson at oracle.com>

Looks good!

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

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26896#pullrequestreview-3143866030

From stefank at openjdk.org  Fri Aug 22 09:59:51 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 22 Aug 2025 09:59:51 GMT
Subject: RFR: 8361370: runtime/Thread/TestThreadDumpMonitorContention.java
 fails due to time out on Windows
In-Reply-To: <BZscaovi-OCDqFducnsfhzKJxLN-nh0nz1hlYEvEXTM=.c7e3342f-b587-46a3-a703-8b5773fd623a@github.com>
References: <BZscaovi-OCDqFducnsfhzKJxLN-nh0nz1hlYEvEXTM=.c7e3342f-b587-46a3-a703-8b5773fd623a@github.com>
Message-ID: <-IvqGiD6GY4hNXo7T0WRfDQsCoeM3ve0IegsQYB_iBs=.65fd8548-4513-40f8-a5cc-f9ed3d87b003@github.com>

On Fri, 22 Aug 2025 08:54:40 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> Jstack streaming output should be disabled in the test as JDK-8354461 suggest. 
> 
> When disabled, the test does not hang with ZGC enabled. 
> 
> Tested locally.

test/hotspot/jtreg/runtime/Thread/TestThreadDumpMonitorContention.java line 53:

> 51:     final static String JSTACK = JDKToolFinder.getTestJDKTool("jstack");
> 52:     final static String PID = Long.toString(ProcessHandle.current().pid());
> 53:     final static String DISABLE_STREAMING_OUTPUT = "-J-Djdk.attach.allowStreamingOutput=false";

Would you mind writing a comment here explaining why this is needed for this test?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26895#discussion_r2293272478

From duke at openjdk.org  Fri Aug 22 10:01:30 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Fri, 22 Aug 2025 10:01:30 GMT
Subject: RFR: 8365975: Sort share/memory includes [v2]
In-Reply-To: <TUfg-TEPul_3CAv9kmnFbiJ9C5vUxixuA8nJyk9F6TY=.e438c1c4-02d7-4f57-a810-93d1116091d7@github.com>
References: <TUfg-TEPul_3CAv9kmnFbiJ9C5vUxixuA8nJyk9F6TY=.e438c1c4-02d7-4f57-a810-93d1116091d7@github.com>
Message-ID: <6rtzZx8IPP532a3qzBQ0lN9G9J5xWukiftDjNG0ENEE=.37b2564d-d793-407c-8d01-5cce731ad687@github.com>

> This PR sorts the includes in `hotspot/share/memory` using `SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted`, and removing a couple of unnecessary include statements.
> 
> Passes `tier1`.

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

  revert

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26897/files
  - new: https://git.openjdk.org/jdk/pull/26897/files/f455e15c..dbdcd4aa

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

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

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

From duke at openjdk.org  Fri Aug 22 11:07:17 2025
From: duke at openjdk.org (Anton Artemov)
Date: Fri, 22 Aug 2025 11:07:17 GMT
Subject: RFR: 8361370: runtime/Thread/TestThreadDumpMonitorContention.java
 fails due to time out on Windows [v2]
In-Reply-To: <BZscaovi-OCDqFducnsfhzKJxLN-nh0nz1hlYEvEXTM=.c7e3342f-b587-46a3-a703-8b5773fd623a@github.com>
References: <BZscaovi-OCDqFducnsfhzKJxLN-nh0nz1hlYEvEXTM=.c7e3342f-b587-46a3-a703-8b5773fd623a@github.com>
Message-ID: <eqKm36BE1yy0KZsht_6T0T31CR2l6TQV2aoAOGqWBXk=.55c55e5e-4c21-44ce-ac50-0a0284539a9a@github.com>

> Hi, please consider the following changes:
> 
> Jstack streaming output should be disabled in the test as JDK-8354461 suggest. 
> 
> When disabled, the test does not hang with ZGC enabled. 
> 
> Tested locally.

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

  8361370: Added explanatory comment.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26895/files
  - new: https://git.openjdk.org/jdk/pull/26895/files/724868b2..3bed268a

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

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

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

From duke at openjdk.org  Fri Aug 22 11:07:17 2025
From: duke at openjdk.org (Anton Artemov)
Date: Fri, 22 Aug 2025 11:07:17 GMT
Subject: RFR: 8361370: runtime/Thread/TestThreadDumpMonitorContention.java
 fails due to time out on Windows [v2]
In-Reply-To: <-IvqGiD6GY4hNXo7T0WRfDQsCoeM3ve0IegsQYB_iBs=.65fd8548-4513-40f8-a5cc-f9ed3d87b003@github.com>
References: <BZscaovi-OCDqFducnsfhzKJxLN-nh0nz1hlYEvEXTM=.c7e3342f-b587-46a3-a703-8b5773fd623a@github.com>
 <-IvqGiD6GY4hNXo7T0WRfDQsCoeM3ve0IegsQYB_iBs=.65fd8548-4513-40f8-a5cc-f9ed3d87b003@github.com>
Message-ID: <dJCHomhHoEW7j-icluOK1o4H8TKWKmuapXOEBiCiwj0=.9e6e544a-a221-4106-832b-16cc14fe2e1d@github.com>

On Fri, 22 Aug 2025 09:56:59 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8361370: Added explanatory comment.
>
> test/hotspot/jtreg/runtime/Thread/TestThreadDumpMonitorContention.java line 53:
> 
>> 51:     final static String JSTACK = JDKToolFinder.getTestJDKTool("jstack");
>> 52:     final static String PID = Long.toString(ProcessHandle.current().pid());
>> 53:     final static String DISABLE_STREAMING_OUTPUT = "-J-Djdk.attach.allowStreamingOutput=false";
> 
> Would you mind writing a comment here explaining why this is needed for this test?

Added a comment as suggested.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26895#discussion_r2293423945

From duke at openjdk.org  Fri Aug 22 11:38:53 2025
From: duke at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Fri, 22 Aug 2025 11:38:53 GMT
Subject: RFR: 8365765: thread.inline.hpp includes the wrong primary header
 file [v2]
In-Reply-To: <oks4Kp5V51jq9A9zMN8Y5vp-C1y_BcR9ES3syKHb2Tw=.4d10d583-2380-40cd-ab8d-64297d646334@github.com>
References: <60ojUdn_wXfg3Wl1PBatvNjMTEMFg5paCB5U0e0YqzU=.d6c2feeb-3409-4367-9a7b-f92fab7c411a@github.com>
 <1879F3rreGMN4B7I0ZVl0AyUsjVilJ-dYKG0ZDytWGI=.7f63ae41-e1d2-4481-ae15-e0d2c7473ca1@github.com>
 <oks4Kp5V51jq9A9zMN8Y5vp-C1y_BcR9ES3syKHb2Tw=.4d10d583-2380-40cd-ab8d-64297d646334@github.com>
Message-ID: <Nra92vusxYq19Um-1jsvUYurrWdDUyhwCFre2WOCNYg=.7a686c34-3fb1-4693-b3d8-5fba5dd7fbf7@github.com>

On Fri, 22 Aug 2025 09:53:28 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Paul H?bner has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/hotspot/share/runtime/thread.inline.hpp
>>   
>>   Co-authored-by: Stefan Karlsson <stefan.karlsson at oracle.com>
>
> Looks good!

@stefank thanks for the review! FYI, tier1 without precompiled headers has just passed on macOS, Linux and Windows.

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

PR Comment: https://git.openjdk.org/jdk/pull/26896#issuecomment-3214058425

From dlong at openjdk.org  Fri Aug 22 12:01:59 2025
From: dlong at openjdk.org (Dean Long)
Date: Fri, 22 Aug 2025 12:01:59 GMT
Subject: RFR: 8365604: Null pointer dereference in
 src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() [v2]
In-Reply-To: <clP7ORnQOS8o0QhYs7DyuOLjQ-bPKch1dK1hDqPzzaI=.9b61fd70-4622-4344-aea6-8661fb57427c@github.com>
References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
 <clP7ORnQOS8o0QhYs7DyuOLjQ-bPKch1dK1hDqPzzaI=.9b61fd70-4622-4344-aea6-8661fb57427c@github.com>
Message-ID: <MEJsxrF4K-t_cRGvOO3KpBBiUcF4MtHCxigyJD64WeU=.c5cf9542-204b-4e5f-b57d-61f900062352@github.com>

On Thu, 21 Aug 2025 09:01:12 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> The defect has been detected and confirmed in the function ArchDesc::declareClasses() located in the file src/hotspot/share/adlc/output_h.cpp with static code analysis. This defect can potentially lead to a null pointer dereference.
>> 
>> The pointer instr->_matrule is dereferenced in line 1952 without checking for nullptr, although earlier in line 1858 the same pointer is checked for nullptr, which indicates that it can be null.
>> 
>> According to [this](https://github.com/openjdk/jdk/pull/26002#issuecomment-3023050372) comment, this PR contains fixes for similar cases in other places.
>
> Artem Semenov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/hotspot/share/c1/c1_LinearScan.cpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Update src/hotspot/share/adlc/output_h.cpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

Most of these mitigations to guard against a possible null pointer dereference are inside `if` expressions, which means if there was a null pointer, then we will now end up in the `else` clause, changing the behavior of the code to something that was perhaps unintended, and we still don't know what caused the null pointer.  So this is just silently masking potential problems, and in my experience is usually not the correct fix.  Most of the time the correct fix is to tell the static analyzer that it is a false positive and move on.  Sometimes it is appropriate to add an assert or guarantee, and yes sometimes it is appropriate to do something different if there is a null, for example if it is a result of an allocation that can fail.

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

PR Comment: https://git.openjdk.org/jdk/pull/26798#issuecomment-3212300703

From asemenov at openjdk.org  Fri Aug 22 12:02:00 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Fri, 22 Aug 2025 12:02:00 GMT
Subject: RFR: 8365604: Null pointer dereference in
 src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() [v2]
In-Reply-To: <KS-ahFFjB-Ehnk_gU_5pM3mfuhHOvOYySiL5Q1wZeVc=.a8bef526-8f2b-495d-b2b7-efa88f1ed6d6@github.com>
References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
 <m-aR302_Qm6Np3fyTAaw5RB2q6t1vMW4vEolOaVueKo=.ff55cc84-9167-473a-af27-95becf011732@github.com>
 <ftJY3jOzJsWM_Aq9WpMjcrn3uR4e9cs_dS9ibkfu3c4=.6b8bbd93-e8e1-4000-8d24-42d40ddd5c11@github.com>
 <nfX_mlIzSSw6BnbOsToJC4QUI4u8SIO2WPOgbmcKV4o=.c6711b09-3989-4762-92a9-cde741c8b303@github.com>
 <TMAYmQLsLMVYslI-dilLANogdWfQqCRdPML64fs1Rz8=.4a247460-76c9-46a3-92bd-df5ece4679ba@github.com>
 <IPp6nZpu3m9vy6YmAi7OpffEWN5h8p81ss21dkBsPGU=.3edab52c-89d6-45f4-9daa-c35f48dc3bb0@github.com>
 <iA2tvBsBkeEoKQntaeQZpteiyfMJCSdhhGKzNO-CeHc=.f5fb60fb-37e6-4b2e-9146-0be0fe220b9d@github.com>
 <KS-ahFFjB-Ehnk_gU_5pM3mfuhHOvOYySiL5Q1wZeVc=.a8bef526-8f2b-495d-b2b7-efa88f1ed6d6@github.com>
Message-ID: <os0FO1i7DzfjdqmpWxKOPGa-6rHOdkNEA-fus5a9w8o=.dc80696d-3672-42a4-a205-977008c212bd@github.com>

On Thu, 21 Aug 2025 14:32:43 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> Well, this leads right to the root of the problem I have with this report. As you say, pos_idx does indeed come out of a marker object. It took me about a minute to identify that this marker object is created in the function that sits right above the one your code assistant flagged as problematic -- even though I am not at all familiar with this code. It looks clear to me that, given the right call sequence for calls that create a marker and then consume it here, the check on pos_idx will ensure that we don't drop off the end of the list with a null pointer. So, it looks very liek this code has been designed so that the presence of a marker with a suitable pos_idx is intended to ensure this loop terminates before that happens. I am sure someone in this project knows whether that is the case but it is not you or your coding assistant.
> 
> I'm not suggesting that that calling sequence is actually right and that the check for pos_idx will definitely avoid dropping off the end. Indeed, I would welcome a bug report that proved it to be wrong. However, what is clear that both you and your coding assistant have failed to appreciate how some relatively obvious parts of this design actually operate. That renders your (or your tool's) analysis a shallow and unhelpful distraction; using it as an excuse to raise a purported 'issue' in the absence of any evidence of an actual issue is very much a waste of time for this project's reviewers.
> 
> Your error is compounded by the fact that you (or more likely your coding assistant) are suggesting changes which, because they are not founded in a correct understanding of the design, could potentially lead to worse outcomes than the speculative nullptr dereference they are intended to remedy -- as I explained when discussing your change to the control flow logic in the ALDC code. So, not only is this report unhelpful it is potentially harmful.
> 
> Ultimately the takeaway here is that the OpenJDK bug system is not here to report, review and add patches to remedy issues that you or your code assistant tool invents on the basis of misinformed assumptions. It is here to report, review and add patches to remedy issues that can be shown to actually affect the correct operation of the JVM and JDK,either by a reproducible test or by well-reasoned argument. So, please do not continue to spam the project with bug reports like this simply because a potentially bogus patch will improve your experience with what is clearly a decidedly fallible tool.

I?m sorry to have taken up your time.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26798#discussion_r2293532235

From asemenov at openjdk.org  Fri Aug 22 12:02:01 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Fri, 22 Aug 2025 12:02:01 GMT
Subject: Withdrawn: 8365604: Null pointer dereference in
 src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses()
In-Reply-To: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
Message-ID: <kErw3f-D3SB4Yxj9Hi8GBrfshYhi7njMTMkZ-t9knPo=.43be4c0d-98c8-4912-82c5-807a38636cde@github.com>

On Fri, 15 Aug 2025 11:58:48 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> The defect has been detected and confirmed in the function ArchDesc::declareClasses() located in the file src/hotspot/share/adlc/output_h.cpp with static code analysis. This defect can potentially lead to a null pointer dereference.
> 
> The pointer instr->_matrule is dereferenced in line 1952 without checking for nullptr, although earlier in line 1858 the same pointer is checked for nullptr, which indicates that it can be null.
> 
> According to [this](https://github.com/openjdk/jdk/pull/26002#issuecomment-3023050372) comment, this PR contains fixes for similar cases in other places.

This pull request has been closed without being integrated.

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

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

From ayang at openjdk.org  Fri Aug 22 12:08:51 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 22 Aug 2025 12:08:51 GMT
Subject: RFR: 8365765: thread.inline.hpp includes the wrong primary header
 file [v2]
In-Reply-To: <1879F3rreGMN4B7I0ZVl0AyUsjVilJ-dYKG0ZDytWGI=.7f63ae41-e1d2-4481-ae15-e0d2c7473ca1@github.com>
References: <60ojUdn_wXfg3Wl1PBatvNjMTEMFg5paCB5U0e0YqzU=.d6c2feeb-3409-4367-9a7b-f92fab7c411a@github.com>
 <1879F3rreGMN4B7I0ZVl0AyUsjVilJ-dYKG0ZDytWGI=.7f63ae41-e1d2-4481-ae15-e0d2c7473ca1@github.com>
Message-ID: <HZ7yLh7SqDv5kSGUY2Nl7qRG6WI_wrHQZRYVq4qpN8c=.f9463646-3487-4664-bcde-a0443b1555fc@github.com>

On Fri, 22 Aug 2025 09:44:43 GMT, Paul H?bner <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This ensures `thread.inline.hpp` adheres to the style guide:
>>> All .inline.hpp files should include their corresponding .hpp file as the first include line with a blank line separating it from the rest of the include lines. [...]
>> 
>> I've run tests with JDK tiers 1-3 on macOS (AArch64, x64), Linux (AArch64, x64), and Windows (x64); all green.
>
> Paul H?bner has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/runtime/thread.inline.hpp
>   
>   Co-authored-by: Stefan Karlsson <stefan.karlsson at oracle.com>

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26896#pullrequestreview-3144246362

From kvn at openjdk.org  Fri Aug 22 15:16:55 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 22 Aug 2025 15:16:55 GMT
Subject: RFR: 8365633: Incorrect info is reported on hybrid CPU [v4]
In-Reply-To: <RyaCh5StldhzMTgCz-6wweIhrVMLBh59aiiCL5E4FYU=.724d05dd-2a8c-4aff-ac72-6cc08d38d60d@github.com>
References: <T2R7vtbL0AaZLcRKdAPjoM6I8kz6lclHBNnOXi8JIQY=.1af945fd-1592-423a-8a19-940dd1c531d3@github.com>
 <RyaCh5StldhzMTgCz-6wweIhrVMLBh59aiiCL5E4FYU=.724d05dd-2a8c-4aff-ac72-6cc08d38d60d@github.com>
Message-ID: <N_PpKWlIVwh6qHUub9jQUhiz66Aa2EJO5D3cxJlSZ5Q=.5258bacb-5a88-46a8-8766-797ad269baae@github.com>

On Fri, 22 Aug 2025 00:58:26 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> `VM.info` DCmd reports CPU information. I ran this on Intel Core Ultra 5 225U , then I got following result:
>> 
>> 
>> CPU: total 14 (initial active 14) (7 cores per cpu, 2 threads per core) family 6 model 181 stepping 0 microcode 0xffffffff, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, clwb, hv, serialize, rdtscp, rdpid, fsrm, gfni, f16c, cet_ibt, cet_ss
>> CPU Model and flags from /proc/cpuinfo:
>> model name : Intel(R) Core(TM) Ultra 5 225U
>> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm pni pclmulqdq monitor est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave osxsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch fsgsbase bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb intel_pt sha_ni umip gfni vaes vpclmulqdq rdpid ibrs ibpb stibp ssbd
>> 
>> 
>> It reports "7 cores per cpu, 2 threads per core". 225U has hybrid architecture - 2 P cores, 8 E cores, 2 LP cores, and also P core has 2 threads per core. Then it should be "12 cores, 14 threads".
>> https://www.intel.com/content/www/us/en/products/sku/241861/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html
>> 
>> According to Intel Software Developer's Manual, it seems to be difficult to get number of physical cores. In Linux kernel, it seems to be calculated by complex logic: https://github.com/torvalds/linux/blob/v6.16/arch/x86/kernel/smpboot.c#L567-L597
>> In addition, all of P cores might not be enabled HT. Thus to show only number of threads is reasonable at this point.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Indicate "(hybrid)" on hybrid CPU

My testing passed.

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

PR Comment: https://git.openjdk.org/jdk/pull/26808#issuecomment-3214735272

From jwaters at openjdk.org  Fri Aug 22 16:29:55 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 22 Aug 2025 16:29:55 GMT
Subject: RFR: 8365765: thread.inline.hpp includes the wrong primary header
 file [v2]
In-Reply-To: <1879F3rreGMN4B7I0ZVl0AyUsjVilJ-dYKG0ZDytWGI=.7f63ae41-e1d2-4481-ae15-e0d2c7473ca1@github.com>
References: <60ojUdn_wXfg3Wl1PBatvNjMTEMFg5paCB5U0e0YqzU=.d6c2feeb-3409-4367-9a7b-f92fab7c411a@github.com>
 <1879F3rreGMN4B7I0ZVl0AyUsjVilJ-dYKG0ZDytWGI=.7f63ae41-e1d2-4481-ae15-e0d2c7473ca1@github.com>
Message-ID: <ggRMd5MJUy0DiOW2KzLjEgmtFNDR0NNXW1B0YVd-Yx8=.a6c2067a-ba8e-45b7-a79b-c945aba25584@github.com>

On Fri, 22 Aug 2025 09:44:43 GMT, Paul H?bner <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This ensures `thread.inline.hpp` adheres to the style guide:
>>> All .inline.hpp files should include their corresponding .hpp file as the first include line with a blank line separating it from the rest of the include lines. [...]
>> 
>> I've run tests with JDK tiers 1-3 on macOS (AArch64, x64), Linux (AArch64, x64), and Windows (x64); all green.
>
> Paul H?bner has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/runtime/thread.inline.hpp
>   
>   Co-authored-by: Stefan Karlsson <stefan.karlsson at oracle.com>

Marked as reviewed by jwaters (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/26896#pullrequestreview-3145113628

From iklam at openjdk.org  Fri Aug 22 18:26:53 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 22 Aug 2025 18:26:53 GMT
Subject: RFR: 8364103: Convert existing sprintf-chains to stringStream
In-Reply-To: <xbbCS-TR5liWQKlJCsaDMsmLDZNuLIw54t9tCpphXTs=.78fc8a50-f39b-4253-8c10-9376ff25235b@github.com>
References: <xbbCS-TR5liWQKlJCsaDMsmLDZNuLIw54t9tCpphXTs=.78fc8a50-f39b-4253-8c10-9376ff25235b@github.com>
Message-ID: <j_adD4_DJO0OhxPzQCW_cT-fc6TXlHGp_LRElTvUFIA=.ba5ee74f-f3c0-4d50-a73b-c83042e99341@github.com>

On Fri, 22 Aug 2025 08:49:56 GMT, Paul H?bner <duke at openjdk.org> wrote:

> Hi all,
> 
> This PR refactors `javaClasses`' `print_stack_element_to_stream` to use a `stringStream` instead of manually maintaining a buffer with `os::snprintf` chains.
> 
> The JBS issue outlines to do this for all occurrences of `snprintf`-like chains. The majority of the calls to `os::snprintf`, `os::snprintf_checked`, `os::vsnprintf`, etc. occur just once. `LogTagSet::vwrite` is the only place to my knowledge where there remains a `vsnprintf` chain using manual buffer arithmetic. After consulting @jdksjolen, we decided that due to the
> a) low-level nature of the code, and 
> b) widespread usage of logging in the VM, 
> this should probably warrant a larger discussion and/or separate issue. Personally, I feel like the performance & correctness risks of introducing a high-level abstraction here outweighs the benefits. 
> 
> I've run tests with JDK tiers 1-3 on macOS (AArch64, x64), Linux (AArch64, x64), and Windows (x64); all green.

Why are we printing to a buffer first?

Originally this function was `java_lang_Throwable::print_stack_element_to_buffer()` and returns a buffer. Hence the anachronistic comment "// Print stack trace element to resource allocated buffer"  which is no longer correct.

I can't find any information from the history of this file:

https://github.com/openjdk/jdk/blame/68f3dd76c92ce3b0219ac2cc346718dd865645d9/hotspot/src/share/vm/classfile/javaClasses.cpp#L1161

I am guessing the reason is to avoid interleaving with other threads. I think the above comment should be updated to reflect this.

src/hotspot/share/classfile/javaClasses.cpp line 2591:

> 2589:   ResourceMark rm;
> 2590: 
> 2591:   // Get strings.

This comment is useless and should be removed.

src/hotspot/share/classfile/javaClasses.cpp line 2613:

> 2611: 
> 2612:   // The string stream that will handle all of the formatting and outputting.
> 2613:   stringStream ss;

This comment is not necessary.

src/hotspot/share/classfile/javaClasses.cpp line 2616:

> 2614: 
> 2615:   // Print stack trace line in buffer
> 2616:   ss.print("\tat %s.%s(", klass_name, method_name);

The comment about this line is useless and should be removed.

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

Changes requested by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26894#pullrequestreview-3145411128
PR Review Comment: https://git.openjdk.org/jdk/pull/26894#discussion_r2294390668
PR Review Comment: https://git.openjdk.org/jdk/pull/26894#discussion_r2294370267
PR Review Comment: https://git.openjdk.org/jdk/pull/26894#discussion_r2294391604

From amenkov at openjdk.org  Fri Aug 22 18:55:52 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 22 Aug 2025 18:55:52 GMT
Subject: RFR: 8361370: runtime/Thread/TestThreadDumpMonitorContention.java
 fails due to time out on Windows [v2]
In-Reply-To: <eqKm36BE1yy0KZsht_6T0T31CR2l6TQV2aoAOGqWBXk=.55c55e5e-4c21-44ce-ac50-0a0284539a9a@github.com>
References: <BZscaovi-OCDqFducnsfhzKJxLN-nh0nz1hlYEvEXTM=.c7e3342f-b587-46a3-a703-8b5773fd623a@github.com>
 <eqKm36BE1yy0KZsht_6T0T31CR2l6TQV2aoAOGqWBXk=.55c55e5e-4c21-44ce-ac50-0a0284539a9a@github.com>
Message-ID: <bmWSW70RUdf5F5e2PCTvoO-whYCqIAIP9pa_QZAPUd8=.c9fa7d8b-5eec-4419-852f-bcc04a031f94@github.com>

On Fri, 22 Aug 2025 11:07:17 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> Jstack streaming output should be disabled in the test as JDK-8354461 suggest. 
>> 
>> When disabled, the test does not hang with ZGC enabled. 
>> 
>> Tested locally.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8361370: Added explanatory comment.

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26895#pullrequestreview-3145508997

From iklam at openjdk.org  Fri Aug 22 20:43:56 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 22 Aug 2025 20:43:56 GMT
Subject: RFR: 8365814: Consolidate has_been_archived() and
 has_been_buffered() in ArchiveBuilder
In-Reply-To: <1Ywg41frWZfBAQQr_zfnCLaBBg7dhTXgmKxALdFQGWc=.89e7d609-3eea-44d5-a881-943639659c1d@github.com>
References: <CjcbzPgOlwDABX6nFwnR4TgkD-FcK8VSXZuz5tsSNJE=.ee6b4d03-9855-4bbd-9031-4a657dda358e@github.com>
 <1Ywg41frWZfBAQQr_zfnCLaBBg7dhTXgmKxALdFQGWc=.89e7d609-3eea-44d5-a881-943639659c1d@github.com>
Message-ID: <siVg_KkMVVKdVPaE8hGsPcZF09znpGFTxp-7D-cSgyQ=.6265bb07-f7bd-48a7-afde-c2dace78afa1@github.com>

On Wed, 20 Aug 2025 04:53:20 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Merged the two methods into one: `ArchiveBuilder::has_been_archived()`. Added comments and asserts to explain what the expected result is.
>
> Good.

Thanks @vnkozlov and @coleenp for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/26853#issuecomment-3215578101

From iklam at openjdk.org  Fri Aug 22 20:43:57 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 22 Aug 2025 20:43:57 GMT
Subject: Integrated: 8365814: Consolidate has_been_archived() and
 has_been_buffered() in ArchiveBuilder
In-Reply-To: <CjcbzPgOlwDABX6nFwnR4TgkD-FcK8VSXZuz5tsSNJE=.ee6b4d03-9855-4bbd-9031-4a657dda358e@github.com>
References: <CjcbzPgOlwDABX6nFwnR4TgkD-FcK8VSXZuz5tsSNJE=.ee6b4d03-9855-4bbd-9031-4a657dda358e@github.com>
Message-ID: <ybpfQzEfsP8IEsVEkFKD_sxAscMdxQLTF6e1S_u0Xvs=.d1e6a775-5731-42d3-98df-bfe1e8818ffd@github.com>

On Wed, 20 Aug 2025 04:01:13 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Merged the two methods into one: `ArchiveBuilder::has_been_archived()`. Added comments and asserts to explain what the expected result is.

This pull request has now been integrated.

Changeset: c01b4fc3
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c01b4fc348fff37c502d38ab3bb3385a5a8cff9a
Stats:     36 lines in 4 files changed: 20 ins; 10 del; 6 mod

8365814: Consolidate has_been_archived() and has_been_buffered() in ArchiveBuilder

Reviewed-by: kvn, coleenp

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

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

From ysuenaga at openjdk.org  Sat Aug 23 02:49:54 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Sat, 23 Aug 2025 02:49:54 GMT
Subject: RFR: 8365633: Incorrect info is reported on hybrid CPU [v4]
In-Reply-To: <N_PpKWlIVwh6qHUub9jQUhiz66Aa2EJO5D3cxJlSZ5Q=.5258bacb-5a88-46a8-8766-797ad269baae@github.com>
References: <T2R7vtbL0AaZLcRKdAPjoM6I8kz6lclHBNnOXi8JIQY=.1af945fd-1592-423a-8a19-940dd1c531d3@github.com>
 <RyaCh5StldhzMTgCz-6wweIhrVMLBh59aiiCL5E4FYU=.724d05dd-2a8c-4aff-ac72-6cc08d38d60d@github.com>
 <N_PpKWlIVwh6qHUub9jQUhiz66Aa2EJO5D3cxJlSZ5Q=.5258bacb-5a88-46a8-8766-797ad269baae@github.com>
Message-ID: <O_K-UHIz-hrbNN1AtPmnK6paKK-Tb5GghImyL8dF1rs=.d0157712-cc2f-4038-a6ab-8d3e17e90bd9@github.com>

On Fri, 22 Aug 2025 15:14:11 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Indicate "(hybrid)" on hybrid CPU
>
> My testing passed.

Thank you @vnkozlov !
@dholmes-ora , are you ok this change?

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

PR Comment: https://git.openjdk.org/jdk/pull/26808#issuecomment-3216156116

From iklam at openjdk.org  Sun Aug 24 04:43:13 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sun, 24 Aug 2025 04:43:13 GMT
Subject: RFR: 8366029: Do not add -XX:VerifyArchivedFields by default to CDS
 tests
Message-ID: <kW29551vr-Oc9BGv5E_uVAs3d8bRgeRSPOzAv1o4dhM=.6da9502c-7ac9-48d8-92ea-c2c7c34bfe49@github.com>

The diagnostic flag `VerifyArchivedFields` verifies the heap multiple times during VM bootstrap. It's supposed to find problems when heap corruptions when loading the CDS archive.

We added this option to almost all CDS tests by default, but this is rather costly and has not found any bugs for quite a while now.

This PR removes `VerifyArchivedFields` from most of the CDS tests. There is still one test case that explicitly runs with this flag so we have some coverage already.

When running all the CDS tests, this RFE can reduce the elapsed time by about 10%.

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

Commit messages:
 - 8366029: Do not add -XX:VerifyArchivedFields by default to CDS tests

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

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

From kbarrett at openjdk.org  Sun Aug 24 13:01:52 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 24 Aug 2025 13:01:52 GMT
Subject: RFR: 8364103: Convert existing sprintf-chains to stringStream
In-Reply-To: <xbbCS-TR5liWQKlJCsaDMsmLDZNuLIw54t9tCpphXTs=.78fc8a50-f39b-4253-8c10-9376ff25235b@github.com>
References: <xbbCS-TR5liWQKlJCsaDMsmLDZNuLIw54t9tCpphXTs=.78fc8a50-f39b-4253-8c10-9376ff25235b@github.com>
Message-ID: <1hCde5ZeDseE4OEegRk6GmcL7IbAlKIlW58WLdch4qg=.69de11c1-6116-4bb6-9efd-7039b69ad93e@github.com>

On Fri, 22 Aug 2025 08:49:56 GMT, Paul H?bner <duke at openjdk.org> wrote:

> Hi all,
> 
> This PR refactors `javaClasses`' `print_stack_element_to_stream` to use a `stringStream` instead of manually maintaining a buffer with `os::snprintf` chains.
> 
> The JBS issue outlines to do this for all occurrences of `snprintf`-like chains. The majority of the calls to `os::snprintf`, `os::snprintf_checked`, `os::vsnprintf`, etc. occur just once. `LogTagSet::vwrite` is the only place to my knowledge where there remains a `vsnprintf` chain using manual buffer arithmetic. After consulting @jdksjolen, we decided that due to the
> a) low-level nature of the code, and 
> b) widespread usage of logging in the VM, 
> this should probably warrant a larger discussion and/or separate issue. Personally, I feel like the performance & correctness risks of introducing a high-level abstraction here outweighs the benefits. 
> 
> I've run tests with JDK tiers 1-3 on macOS (AArch64, x64), Linux (AArch64, x64), and Windows (x64); all green.

src/hotspot/share/classfile/javaClasses.cpp line 2621:

> 2619:   if (module_name != nullptr) {
> 2620:     if (module_version != nullptr) {
> 2621:       ss.print("%s@%s/", module_name, module_version);

Here and other places, this change is going to merge-conflict with https://github.com/openjdk/jdk/pull/26849.
I think that PR should be allowed to go first.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26894#discussion_r2296651803

From kvn at openjdk.org  Sun Aug 24 15:30:49 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sun, 24 Aug 2025 15:30:49 GMT
Subject: RFR: 8366029: Do not add -XX:VerifyArchivedFields by default to
 CDS tests
In-Reply-To: <kW29551vr-Oc9BGv5E_uVAs3d8bRgeRSPOzAv1o4dhM=.6da9502c-7ac9-48d8-92ea-c2c7c34bfe49@github.com>
References: <kW29551vr-Oc9BGv5E_uVAs3d8bRgeRSPOzAv1o4dhM=.6da9502c-7ac9-48d8-92ea-c2c7c34bfe49@github.com>
Message-ID: <2ivUl80byHt4C0lwGTEJybWV702yae4y6x1N8iLELVo=.3d3210bf-3bdf-4e45-bc04-d6c3e905cf40@github.com>

On Sun, 24 Aug 2025 04:38:16 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The diagnostic flag `VerifyArchivedFields` verifies the heap multiple times during VM bootstrap. It's supposed to find problems when heap corruptions when loading the CDS archive.
> 
> We added this option to almost all CDS tests by default, but this is rather costly and has not found any bugs for quite a while now.
> 
> This PR removes `VerifyArchivedFields` from most of the CDS tests. There is still one test case that explicitly runs with this flag so we have some coverage already.
> 
> When running all the CDS tests, this RFE can reduce the elapsed time by about 10%.

Good.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26915#pullrequestreview-3149416060

From iklam at openjdk.org  Mon Aug 25 04:03:55 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 25 Aug 2025 04:03:55 GMT
Subject: RFR: 8366029: Do not add -XX:VerifyArchivedFields by default to
 CDS tests
In-Reply-To: <2ivUl80byHt4C0lwGTEJybWV702yae4y6x1N8iLELVo=.3d3210bf-3bdf-4e45-bc04-d6c3e905cf40@github.com>
References: <kW29551vr-Oc9BGv5E_uVAs3d8bRgeRSPOzAv1o4dhM=.6da9502c-7ac9-48d8-92ea-c2c7c34bfe49@github.com>
 <2ivUl80byHt4C0lwGTEJybWV702yae4y6x1N8iLELVo=.3d3210bf-3bdf-4e45-bc04-d6c3e905cf40@github.com>
Message-ID: <tj1UVX3CFm3BTB-Y65ctI_CTmMNk2MTIBbHLHG8Rn1k=.fa768659-c3cd-4c38-9e22-913498312e37@github.com>

On Sun, 24 Aug 2025 15:27:45 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> The diagnostic flag `VerifyArchivedFields` verifies the heap multiple times during VM bootstrap. It's supposed to find problems when heap corruptions when loading the CDS archive.
>> 
>> We added this option to almost all CDS tests by default, but this is rather costly and has not found any bugs for quite a while now.
>> 
>> This PR removes `VerifyArchivedFields` from most of the CDS tests. There is still one test case that explicitly runs with this flag so we have some coverage already.
>> 
>> When running all the CDS tests, this RFE can reduce the elapsed time by about 10%.
>
> Good.

Thanks @vnkozlov for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/26915#issuecomment-3218751658

From iklam at openjdk.org  Mon Aug 25 04:03:56 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 25 Aug 2025 04:03:56 GMT
Subject: Integrated: 8366029: Do not add -XX:VerifyArchivedFields by default to
 CDS tests
In-Reply-To: <kW29551vr-Oc9BGv5E_uVAs3d8bRgeRSPOzAv1o4dhM=.6da9502c-7ac9-48d8-92ea-c2c7c34bfe49@github.com>
References: <kW29551vr-Oc9BGv5E_uVAs3d8bRgeRSPOzAv1o4dhM=.6da9502c-7ac9-48d8-92ea-c2c7c34bfe49@github.com>
Message-ID: <bCdsZAM3PKTv9sR6g5bV6DaH7muMw12fILgaFdAXtQs=.21b6969a-51e1-485a-be22-259129a7551e@github.com>

On Sun, 24 Aug 2025 04:38:16 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The diagnostic flag `VerifyArchivedFields` verifies the heap multiple times during VM bootstrap. It's supposed to find problems when heap corruptions when loading the CDS archive.
> 
> We added this option to almost all CDS tests by default, but this is rather costly and has not found any bugs for quite a while now.
> 
> This PR removes `VerifyArchivedFields` from most of the CDS tests. There is still one test case that explicitly runs with this flag so we have some coverage already.
> 
> When running all the CDS tests, this RFE can reduce the elapsed time by about 10%.

This pull request has now been integrated.

Changeset: 15601b47
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/15601b4718ed26de6f57e633c4f41f6b0cd90cb0
Stats:     9 lines in 4 files changed: 2 ins; 6 del; 1 mod

8366029: Do not add -XX:VerifyArchivedFields by default to CDS tests

Reviewed-by: kvn

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

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

From fbredberg at openjdk.org  Mon Aug 25 06:50:58 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Mon, 25 Aug 2025 06:50:58 GMT
Subject: RFR: 8365189: Remove LockingMode related code from arm32
In-Reply-To: <bvw0sMNTLzhoms1UW34LXiFrkKDysBfeLAQftPjBh5o=.ddd3c817-4094-4cfe-afa2-4c751eae6814@github.com>
References: <bvw0sMNTLzhoms1UW34LXiFrkKDysBfeLAQftPjBh5o=.ddd3c817-4094-4cfe-afa2-4c751eae6814@github.com>
Message-ID: <etgNMEJCtneSSs9B4x4GW7YQaxa5BHT-In6zXW_IAZU=.cc184696-fc4f-4fbb-bed0-94b7ec98de12@github.com>

On Fri, 15 Aug 2025 09:29:04 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
> 
> This PR removes `LockingMode` related code from the **arm32** platform.
> 
> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.

It's Monday, lets...

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

PR Comment: https://git.openjdk.org/jdk/pull/26795#issuecomment-3219039517

From fbredberg at openjdk.org  Mon Aug 25 06:50:58 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Mon, 25 Aug 2025 06:50:58 GMT
Subject: Integrated: 8365189: Remove LockingMode related code from arm32
In-Reply-To: <bvw0sMNTLzhoms1UW34LXiFrkKDysBfeLAQftPjBh5o=.ddd3c817-4094-4cfe-afa2-4c751eae6814@github.com>
References: <bvw0sMNTLzhoms1UW34LXiFrkKDysBfeLAQftPjBh5o=.ddd3c817-4094-4cfe-afa2-4c751eae6814@github.com>
Message-ID: <CefZC2TV84Tk2EEg2LS-D5JaRgNuCpDw1ijDipFIAnw=.78877090-b998-4580-b476-e78d1d45f02b@github.com>

On Fri, 15 Aug 2025 09:29:04 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
> 
> This PR removes `LockingMode` related code from the **arm32** platform.
> 
> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.

This pull request has now been integrated.

Changeset: 0b8ae260
Author:    Fredrik Bredberg <fbredberg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0b8ae260282dbb1fa1e8ce9d14f06f353327e03c
Stats:     356 lines in 6 files changed: 15 ins; 283 del; 58 mod

8365189: Remove LockingMode related code from arm32

Reviewed-by: aboldtch, coleenp

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

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

From mbaesken at openjdk.org  Mon Aug 25 08:14:59 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 25 Aug 2025 08:14:59 GMT
Subject: RFR: 8364352: Some tests fail when using a limited number of
 pregenerated .jsa CDS archives
In-Reply-To: <GtNL83Xo_ncqcYTVTO4Qz0pby8BvHeKe9pmptdFQLd4=.6902d787-ed68-420e-901b-56f88fe482f5@github.com>
References: <EnyzXiapmd29T3spHQT7QTBv2SVQVKVU6L2NEDoejHg=.65f803f7-09e0-4e5b-ac21-a60474c5facd@github.com>
 <GtNL83Xo_ncqcYTVTO4Qz0pby8BvHeKe9pmptdFQLd4=.6902d787-ed68-420e-901b-56f88fe482f5@github.com>
Message-ID: <5e6obGQNZlN4awG0WbR1qWNcC7C88fgWEEEb4ZOTRNw=.ba0e22de-1350-401b-b0f1-0653976965ed@github.com>

On Wed, 20 Aug 2025 20:54:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Currently the default JVM comes on most platforms with 4 jsa files (for coops and nocoops; with and without compressed object headers), but for some shipments the number of jsa could be reduced (see also Images.gmk) .
>> But not all tests can deal with this.
>> Namely
>> 
>> test/hotspot/jtreg/runtime/CompressedOops/CompressedCPUSpecificClassSpaceReservation.java
>> test/hotspot/jtreg/runtime/cds/TestDefaultArchiveLoading.java
>> test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java (custom-cl-zgc)
>> 
>> were found to have issues.
>> There is already a requires  `vm.cds.default.archive.available`   that is used in similar tests and can be used in some of those cases too.
>
> test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java line 58:
> 
>> 56:  * @test id=custom-cl-zgc
>> 57:  * @requires vm.cds.custom.loaders
>> 58:  * @requires vm.cds.default.archive.available
> 
> Don't understand this one. This test is hard to follow but I think it does its own dumping of the CDS archive, so I don't see why it would need the default archive to exist. ???

we run into this error without the jsa in the zgc case
runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java#custom-cl-zgc


[0.002s][error][cds] Specified shared archive file not found (/jtreg_hotspot_tier2_work/JTwork/scratch/2/appcds-06h49m10s700.jsa)
[0.002s][error][cds] Not a valid shared archive file (/jtreg_hotspot_tier2_work/JTwork/scratch/2/appcds-06h49m10s700.jsa)
[0.002s][error][cds] CDS is incompatible with other specified options.
Error occurred during initialization of VM
Unable to use shared archive: invalid archive

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26820#discussion_r2297421350

From ghan at openjdk.org  Mon Aug 25 08:16:07 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Mon, 25 Aug 2025 08:16:07 GMT
Subject: RFR: 8366035: Simplify CPUTimeCounters::publish_gc_total_cpu_time
Message-ID: <ntNDtmG1fFR5BMjgDThR96R3R8VpdPAgThaR28Nok44=.b93537c8-c9e8-4cfd-9146-a4e3f32cfbde@github.com>

This change refactors CPUTimeCounters::publish_gc_total_cpu_time() to use Atomic::xchg instead of a CAS (cmpxchg) loop.
Please review it. Thanks

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

Commit messages:
 - 8366035: Simplify CPUTimeCounters::publish_gc_total_cpu_time

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

PR: https://git.openjdk.org/jdk/pull/26921

From ghan at openjdk.org  Mon Aug 25 08:45:47 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Mon, 25 Aug 2025 08:45:47 GMT
Subject: RFR: 8366035: Simplify CPUTimeCounters::publish_gc_total_cpu_time
 [v2]
In-Reply-To: <ntNDtmG1fFR5BMjgDThR96R3R8VpdPAgThaR28Nok44=.b93537c8-c9e8-4cfd-9146-a4e3f32cfbde@github.com>
References: <ntNDtmG1fFR5BMjgDThR96R3R8VpdPAgThaR28Nok44=.b93537c8-c9e8-4cfd-9146-a4e3f32cfbde@github.com>
Message-ID: <AlZZzoUCMfM6kWEWUk0tSIuoisMzmYWDdG_ibpCKHbU=.65a28dc2-466e-40d4-bc2d-aee23f3d76ce@github.com>

> This change refactors CPUTimeCounters::publish_gc_total_cpu_time() to use Atomic::xchg instead of a CAS (cmpxchg) loop.
> Please review it. Thanks

Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision:

  Update cpuTimeCounters.cpp
  
  a small fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26921/files
  - new: https://git.openjdk.org/jdk/pull/26921/files/0b66b63c..6dd9ff83

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26921&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26921&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26921.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26921/head:pull/26921

PR: https://git.openjdk.org/jdk/pull/26921

From shade at openjdk.org  Mon Aug 25 09:06:54 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 25 Aug 2025 09:06:54 GMT
Subject: RFR: 8365975: Sort share/memory includes [v2]
In-Reply-To: <6rtzZx8IPP532a3qzBQ0lN9G9J5xWukiftDjNG0ENEE=.37b2564d-d793-407c-8d01-5cce731ad687@github.com>
References: <TUfg-TEPul_3CAv9kmnFbiJ9C5vUxixuA8nJyk9F6TY=.e438c1c4-02d7-4f57-a810-93d1116091d7@github.com>
 <6rtzZx8IPP532a3qzBQ0lN9G9J5xWukiftDjNG0ENEE=.37b2564d-d793-407c-8d01-5cce731ad687@github.com>
Message-ID: <T8xdUGt3ARNffwXh20b-umS9c3NVEQyGFsRCgLR_6Ko=.ff394d2c-f0f3-41ad-b320-00f32d8c3860@github.com>

On Fri, 22 Aug 2025 10:01:30 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> This PR sorts the includes in `hotspot/share/memory` using `SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted`, and removing a couple of unnecessary include statements.
>> 
>> Passes `tier1`.
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert

This looks good to me. Someone from Runtime team should also take a look.

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26897#pullrequestreview-3150532402

From duke at openjdk.org  Mon Aug 25 09:09:52 2025
From: duke at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 25 Aug 2025 09:09:52 GMT
Subject: RFR: 8365765: thread.inline.hpp includes the wrong primary header
 file [v2]
In-Reply-To: <HZ7yLh7SqDv5kSGUY2Nl7qRG6WI_wrHQZRYVq4qpN8c=.f9463646-3487-4664-bcde-a0443b1555fc@github.com>
References: <60ojUdn_wXfg3Wl1PBatvNjMTEMFg5paCB5U0e0YqzU=.d6c2feeb-3409-4367-9a7b-f92fab7c411a@github.com>
 <1879F3rreGMN4B7I0ZVl0AyUsjVilJ-dYKG0ZDytWGI=.7f63ae41-e1d2-4481-ae15-e0d2c7473ca1@github.com>
 <HZ7yLh7SqDv5kSGUY2Nl7qRG6WI_wrHQZRYVq4qpN8c=.f9463646-3487-4664-bcde-a0443b1555fc@github.com>
Message-ID: <1vEUBat4c2gOrsy3qr9ASm5BdmUOgJpAJRCbXW9jErc=.e03f3c5c-fff5-4bab-ae19-864495fd4cf5@github.com>

On Fri, 22 Aug 2025 12:05:49 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Paul H?bner has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/hotspot/share/runtime/thread.inline.hpp
>>   
>>   Co-authored-by: Stefan Karlsson <stefan.karlsson at oracle.com>
>
> Marked as reviewed by ayang (Reviewer).

@albertnetymk @TheShermanTanker thanks for you reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26896#issuecomment-3219444232

From duke at openjdk.org  Mon Aug 25 09:09:53 2025
From: duke at openjdk.org (duke)
Date: Mon, 25 Aug 2025 09:09:53 GMT
Subject: RFR: 8365765: thread.inline.hpp includes the wrong primary header
 file [v2]
In-Reply-To: <1879F3rreGMN4B7I0ZVl0AyUsjVilJ-dYKG0ZDytWGI=.7f63ae41-e1d2-4481-ae15-e0d2c7473ca1@github.com>
References: <60ojUdn_wXfg3Wl1PBatvNjMTEMFg5paCB5U0e0YqzU=.d6c2feeb-3409-4367-9a7b-f92fab7c411a@github.com>
 <1879F3rreGMN4B7I0ZVl0AyUsjVilJ-dYKG0ZDytWGI=.7f63ae41-e1d2-4481-ae15-e0d2c7473ca1@github.com>
Message-ID: <3hg11_S_oiz5iFnyEy3xxtAEjFFkDIkbJzL3CluwMIg=.17c98eae-9962-483b-8653-b5bb50d7395a@github.com>

On Fri, 22 Aug 2025 09:44:43 GMT, Paul H?bner <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This ensures `thread.inline.hpp` adheres to the style guide:
>>> All .inline.hpp files should include their corresponding .hpp file as the first include line with a blank line separating it from the rest of the include lines. [...]
>> 
>> I've run tests with JDK tiers 1-3 on macOS (AArch64, x64), Linux (AArch64, x64), and Windows (x64); all green.
>
> Paul H?bner has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/runtime/thread.inline.hpp
>   
>   Co-authored-by: Stefan Karlsson <stefan.karlsson at oracle.com>

@Arraying 
Your change (at version 6f671c6162d61f30e903f8c682a44fc1f2b99bb0) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26896#issuecomment-3219445733

From ayang at openjdk.org  Mon Aug 25 09:14:53 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 25 Aug 2025 09:14:53 GMT
Subject: RFR: 8366035: Simplify CPUTimeCounters::publish_gc_total_cpu_time
 [v2]
In-Reply-To: <AlZZzoUCMfM6kWEWUk0tSIuoisMzmYWDdG_ibpCKHbU=.65a28dc2-466e-40d4-bc2d-aee23f3d76ce@github.com>
References: <ntNDtmG1fFR5BMjgDThR96R3R8VpdPAgThaR28Nok44=.b93537c8-c9e8-4cfd-9146-a4e3f32cfbde@github.com>
 <AlZZzoUCMfM6kWEWUk0tSIuoisMzmYWDdG_ibpCKHbU=.65a28dc2-466e-40d4-bc2d-aee23f3d76ce@github.com>
Message-ID: <HTGnxPQ0LJSi25X69QmDYlfaRY7iK6kEDqpfcLLMfI8=.4ac2efb6-4c25-46f7-bdf0-b9b9b353d237@github.com>

On Mon, 25 Aug 2025 08:45:47 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

>> This change refactors CPUTimeCounters::publish_gc_total_cpu_time() to use Atomic::xchg instead of a CAS (cmpxchg) loop.
>> Please review it. Thanks
>
> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update cpuTimeCounters.cpp
>   
>   a small fix

Marked as reviewed by ayang (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26921#pullrequestreview-3150560761

From duke at openjdk.org  Mon Aug 25 09:16:00 2025
From: duke at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 25 Aug 2025 09:16:00 GMT
Subject: Integrated: 8365765: thread.inline.hpp includes the wrong primary
 header file
In-Reply-To: <60ojUdn_wXfg3Wl1PBatvNjMTEMFg5paCB5U0e0YqzU=.d6c2feeb-3409-4367-9a7b-f92fab7c411a@github.com>
References: <60ojUdn_wXfg3Wl1PBatvNjMTEMFg5paCB5U0e0YqzU=.d6c2feeb-3409-4367-9a7b-f92fab7c411a@github.com>
Message-ID: <HawZNnpCFPywvpL-kiRxDgXRnmcXDW59H1RF2chaI8Y=.76a30487-6dc1-45bf-861c-2565d410044c@github.com>

On Fri, 22 Aug 2025 08:57:54 GMT, Paul H?bner <duke at openjdk.org> wrote:

> Hi all,
> 
> This ensures `thread.inline.hpp` adheres to the style guide:
>> All .inline.hpp files should include their corresponding .hpp file as the first include line with a blank line separating it from the rest of the include lines. [...]
> 
> I've run tests with JDK tiers 1-3 on macOS (AArch64, x64), Linux (AArch64, x64), and Windows (x64); all green.

This pull request has now been integrated.

Changeset: 5cc86738
Author:    Paul H?bner <paul.hubner at oracle.com>
Committer: Johan Sj?len <jsjolen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5cc86738411c36378b89d8f4932a54b3089cf22e
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8365765: thread.inline.hpp includes the wrong primary header file

Reviewed-by: stefank, ayang, jwaters

-------------

PR: https://git.openjdk.org/jdk/pull/26896

From kbarrett at openjdk.org  Mon Aug 25 09:58:52 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 25 Aug 2025 09:58:52 GMT
Subject: RFR: 8366035: Simplify CPUTimeCounters::publish_gc_total_cpu_time
 [v2]
In-Reply-To: <AlZZzoUCMfM6kWEWUk0tSIuoisMzmYWDdG_ibpCKHbU=.65a28dc2-466e-40d4-bc2d-aee23f3d76ce@github.com>
References: <ntNDtmG1fFR5BMjgDThR96R3R8VpdPAgThaR28Nok44=.b93537c8-c9e8-4cfd-9146-a4e3f32cfbde@github.com>
 <AlZZzoUCMfM6kWEWUk0tSIuoisMzmYWDdG_ibpCKHbU=.65a28dc2-466e-40d4-bc2d-aee23f3d76ce@github.com>
Message-ID: <c9-oSh7s2b0GDtuTKy3MJmONvqmzggFsTG1Re6TEVs0=.36edf6a4-cf2b-4752-a715-a9a035b50b3d@github.com>

On Mon, 25 Aug 2025 08:45:47 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

>> This change refactors CPUTimeCounters::publish_gc_total_cpu_time() to use Atomic::xchg instead of a CAS (cmpxchg) loop.
>> Please review it. Thanks
>
> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update cpuTimeCounters.cpp
>   
>   a small fix

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26921#pullrequestreview-3150736983

From stefank at openjdk.org  Mon Aug 25 11:55:51 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 25 Aug 2025 11:55:51 GMT
Subject: RFR: 8361370: runtime/Thread/TestThreadDumpMonitorContention.java
 fails due to time out on Windows [v2]
In-Reply-To: <eqKm36BE1yy0KZsht_6T0T31CR2l6TQV2aoAOGqWBXk=.55c55e5e-4c21-44ce-ac50-0a0284539a9a@github.com>
References: <BZscaovi-OCDqFducnsfhzKJxLN-nh0nz1hlYEvEXTM=.c7e3342f-b587-46a3-a703-8b5773fd623a@github.com>
 <eqKm36BE1yy0KZsht_6T0T31CR2l6TQV2aoAOGqWBXk=.55c55e5e-4c21-44ce-ac50-0a0284539a9a@github.com>
Message-ID: <uCogU4_QjZRpa1Ruve3oyMAc28LeoK2rlKVU4XfSYK8=.c31ea0ef-3647-4c01-97e4-6949e93e3727@github.com>

On Fri, 22 Aug 2025 11:07:17 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> Jstack streaming output should be disabled in the test as JDK-8354461 suggest. 
>> 
>> When disabled, the test does not hang with ZGC enabled. 
>> 
>> Tested locally.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8361370: Added explanatory comment.

Thanks for adding the comment. I leave this up to the serviceability devs to finalize the review. Maybe @sspitsyn or @plummercj could help out given that they reviewed JDK-8354461.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26895#issuecomment-3219969251

From mbaesken at openjdk.org  Mon Aug 25 13:01:07 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 25 Aug 2025 13:01:07 GMT
Subject: RFR: 8365442: [asan] runtime/ErrorHandling/CreateCoredumpOnCrash.java
 fails
Message-ID: <-GqE1fb2WD4p_wzi-OmxsyZg8InMm2lziqJxovx6SPk=.d1fb5604-6247-41e9-a924-bd8f5187e80f@github.com>

When running with asan - enabled binaries, the test CreateCoredumpOnCrash.java fails with the output below. Seems asan does not work well with ulimit used in the test, so better avoid running it with asan enabled.


[2025-08-09T09:25:35.801707203Z] Gathering output for process 4376
[2025-08-09T09:25:41.863125073Z] Waiting for completion for process 4376
[2025-08-09T09:25:41.863790182Z] Waiting for completion finished for process 4376
[2025-08-09T09:25:41.876094199Z] Gathering output for process 5017
[2025-08-09T09:25:41.883445027Z] Waiting for completion for process 5017
[2025-08-09T09:25:41.883598661Z] Waiting for completion finished for process 5017
----------System.err:(10/570)----------
java.lang.Exception: ulimit is not set correctly, try 'ulimit -c unlimited' and re-run.
at CreateCoredumpOnCrash.main(CreateCoredumpOnCrash.java:82)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
at java.base/java.lang.reflect.Method.invoke(Method.java:565)
at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335)
at java.base/java.lang.Thread.run(Thread.java:1474)

-------------

Commit messages:
 - JDK-8365442

Changes: https://git.openjdk.org/jdk/pull/26927/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26927&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365442
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26927.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26927/head:pull/26927

PR: https://git.openjdk.org/jdk/pull/26927

From iklam at openjdk.org  Mon Aug 25 17:47:39 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 25 Aug 2025 17:47:39 GMT
Subject: RFR: 8365885: Clean up constant pool reflection native code
In-Reply-To: <Sp5bJ-Ceo_WVhCq6Y9nGjJ_oTXdM-QinhEvf3Q8JUw4=.9ca004e5-d219-4e31-ab7b-e13b50b347e2@github.com>
References: <Sp5bJ-Ceo_WVhCq6Y9nGjJ_oTXdM-QinhEvf3Q8JUw4=.9ca004e5-d219-4e31-ab7b-e13b50b347e2@github.com>
Message-ID: <iag7qVaD750FcDUDtCFULBr5n0-dKGdCXPKFqVoMmyk=.bbe2fad1-f078-4fe1-8294-1c28eb33611b@github.com>

On Wed, 20 Aug 2025 21:29:29 GMT, Chen Liang <liach at openjdk.org> wrote:

> When I was trying to reuse this constant pool reflection for assembly phase indy argument validation, I noted the JNI code has a lot of confusing arguments. In particular, the JVM_ConstantPoolGetSize is wrong because of argument confusion. We should remove the unused arguments to reduce confusion.

LGTM

-------------

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26870#pullrequestreview-3152454131

From jsjolen at openjdk.org  Mon Aug 25 18:17:38 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 25 Aug 2025 18:17:38 GMT
Subject: RFR: 8303612:
 runtime/StackGuardPages/TestStackGuardPagesNative.java fails with exit code
 139
In-Reply-To: <blniq87ptY1r2ZSL2nR17MV-SHTmPOPcAPWRgCVqL24=.b011371a-c54e-4fd9-b25b-19e22c321d3f@github.com>
References: <oRl4abf8ZV5qD9GNScJMRwwZD2PkdiDGJykDFs1Cmgo=.8c961e33-291f-4ba1-b494-ad5eab7ee72c@github.com>
 <blniq87ptY1r2ZSL2nR17MV-SHTmPOPcAPWRgCVqL24=.b011371a-c54e-4fd9-b25b-19e22c321d3f@github.com>
Message-ID: <uVv5zJvsqwfx5qWXQj7r2PeYy4vNSHLgfpFa1Pau8CY=.c295adc4-e164-4aac-a692-cf41d93bd97f@github.com>

On Wed, 9 Jul 2025 01:41:17 GMT, mazhen <duke at openjdk.org> wrote:

>> This pull request addresses an issue in `runtime/StackGuardPages/TestStackGuardPagesNative` where the native test component (`exeinvoke.c`) exhibited platform-dependent behavior and did not fully align with the intended test objectives for verifying stack guard page removal on thread detachment.
>> 
>> **Summary of the Problem:**
>> 
>> The `test_native_overflow_initial` scenario within `TestStackGuardPagesNative` showed inconsistent results:
>> *   On certain Linux distributions (e.g., CentOS 7), the test would hang and eventually time out during its second phase of stack allocation.
>> *   On other distributions (e.g., Ubuntu 24), the test would pass, but this pass was found to be coincidental, relying on an unintended `SEGV_MAPERR` to terminate a loop that should have had a defined exit condition.
>> 
>> The core issue was that the native code's second stack overflow attempt, designed to check for guard page removal, used an unbounded loop. Its termination (and thus the test's outcome) depended on platform-specific OS behavior regarding extensive stack allocation after guard pages are supposedly modified.
>> 
>> **Test Objective Analysis:**
>> 
>> The primary goal of `TestStackGuardPagesNative`, particularly for the initial thread (`test_native_overflow_initial`), is to:
>> 1.  **Verify Guard Page Presence:** Confirm that when a native thread is attached to the JVM, a deliberate stack overflow triggers a `SIGSEGV` with `si_code = SEGV_ACCERR`, indicating an active stack guard page.
>> 2.  **Verify Guard Page Removal/Modification:** After the thread detaches from the JVM via `DetachCurrentThread()`, confirm that the previously active stack guard page is no longer enforcing the same strict protection. This is ideally demonstrated by successfully allocating stack space up to the depth that previously caused the `SEGV_ACCERR`, **without encountering any signal**.
>> 
>> **How the Original Implementation Deviated from the Test Intent:**
>> 
>> The native `do_overflow` function, when invoked for the second phase (to check guard page removal), implemented an unconditional `for(;;)` loop.
>> *   **Intended Logic vs. Actual Behavior:** The test intended for this second phase to demonstrate that allocations up to the prior failure depth are now "clean" (no `SEGV_ACCERR`). However, the unbounded loop meant:
>>     *   On systems like CentOS 7, where deep stack allocation without an immediate `SEGV_MAPERR` was possible, this loop ran for an excessive duration, leading to a hang.
>>  ...
>
> Hi @jdksjolen ,
> 
> Following up on this. As per the bot's message two weeks ago, I've been waiting for my OCA to be processed, but it seems to be stuck.
> I understand that PRs are not reviewed until the OCA is cleared, but since the suggested two-week waiting period has passed, I was hoping someone could help to check or escalate the status of my OCA application internally.
> 
> My Oracle Account Email: mz1999 at gmail.com
> 
> Any help would be greatly appreciated. Thank you!

Ping @mz1999

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25689#issuecomment-3221274470

From jsjolen at openjdk.org  Mon Aug 25 18:24:33 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 25 Aug 2025 18:24:33 GMT
Subject: RFR: 8365442: [asan]
 runtime/ErrorHandling/CreateCoredumpOnCrash.java fails
In-Reply-To: <-GqE1fb2WD4p_wzi-OmxsyZg8InMm2lziqJxovx6SPk=.d1fb5604-6247-41e9-a924-bd8f5187e80f@github.com>
References: <-GqE1fb2WD4p_wzi-OmxsyZg8InMm2lziqJxovx6SPk=.d1fb5604-6247-41e9-a924-bd8f5187e80f@github.com>
Message-ID: <IA_XEgLiYii4G3YggVRUYxqkZrTbJCY_hJFnjzpAnCw=.272a01f0-b732-45d4-9c79-6c99fb05492f@github.com>

On Mon, 25 Aug 2025 12:55:13 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running with asan - enabled binaries, the test CreateCoredumpOnCrash.java fails with the output below. Seems asan does not work well with ulimit used in the test, so better avoid running it with asan enabled.
> 
> 
> [2025-08-09T09:25:35.801707203Z] Gathering output for process 4376
> [2025-08-09T09:25:41.863125073Z] Waiting for completion for process 4376
> [2025-08-09T09:25:41.863790182Z] Waiting for completion finished for process 4376
> [2025-08-09T09:25:41.876094199Z] Gathering output for process 5017
> [2025-08-09T09:25:41.883445027Z] Waiting for completion for process 5017
> [2025-08-09T09:25:41.883598661Z] Waiting for completion finished for process 5017
> ----------System.err:(10/570)----------
> java.lang.Exception: ulimit is not set correctly, try 'ulimit -c unlimited' and re-run.
> at CreateCoredumpOnCrash.main(CreateCoredumpOnCrash.java:82)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> at java.base/java.lang.reflect.Method.invoke(Method.java:565)
> at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335)
> at java.base/java.lang.Thread.run(Thread.java:1474)

I guess it's because asan uses 20TiB of virtual address space? I'm OK with this being disabled on asan.

-------------

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26927#pullrequestreview-3152565896

From alanb at openjdk.org  Mon Aug 25 18:41:35 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 25 Aug 2025 18:41:35 GMT
Subject: RFR: 8365885: Clean up constant pool reflection native code
In-Reply-To: <Sp5bJ-Ceo_WVhCq6Y9nGjJ_oTXdM-QinhEvf3Q8JUw4=.9ca004e5-d219-4e31-ab7b-e13b50b347e2@github.com>
References: <Sp5bJ-Ceo_WVhCq6Y9nGjJ_oTXdM-QinhEvf3Q8JUw4=.9ca004e5-d219-4e31-ab7b-e13b50b347e2@github.com>
Message-ID: <Gxk9rHz_Fk9w_c9Clr6Icyszywtd4i_H7__EuDc4IG8=.77ff9f27-1052-4c23-8f6a-adacffd4912d@github.com>

On Wed, 20 Aug 2025 21:29:29 GMT, Chen Liang <liach at openjdk.org> wrote:

> When I was trying to reuse this constant pool reflection for assembly phase indy argument validation, I noted the JNI code has a lot of confusing arguments. In particular, the JVM_ConstantPoolGetSize is wrong because of argument confusion. We should remove the unused arguments to reduce confusion.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26870#pullrequestreview-3152611996

From dholmes at openjdk.org  Tue Aug 26 05:07:35 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 26 Aug 2025 05:07:35 GMT
Subject: RFR: 8353468: [ubsan] arguments.cpp:2422:23: runtime error:
 2.14748e+11 is outside the range of representable values of type 'int' [v2]
In-Reply-To: <4Ds0MTQtlz861U-p1N3flLCgZbBrFQdoG0Sclg6d9p4=.48ef346b-56c4-4a2e-a656-fbabc1514302@github.com>
References: <plQ5n7EjsekIjeY431_mBeo4rfcH39SVdPWogF2rT44=.20180c89-665e-4054-8625-1b04f8306b3b@github.com>
 <4Ds0MTQtlz861U-p1N3flLCgZbBrFQdoG0Sclg6d9p4=.48ef346b-56c4-4a2e-a656-fbabc1514302@github.com>
Message-ID: <IM65NlIssR6pAfZ3a_4PYM6zUGMwK3mUzFxzSKjOMoA=.1841c3c2-6f94-47ff-a7fc-fab90ca1ae5c@github.com>

On Thu, 21 Aug 2025 09:49:09 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> In converting values of `-XMinf` and `-XMaxf` options to `int`, overflow was not checked. 
>> The values are checked against INT_MAX and clamped.
>> 
>> Tests: tiers 1-5.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   negative underflow checked.

Update looks good. Thanks.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26859#pullrequestreview-3153932311

From dholmes at openjdk.org  Tue Aug 26 05:39:38 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 26 Aug 2025 05:39:38 GMT
Subject: RFR: 8361370: runtime/Thread/TestThreadDumpMonitorContention.java
 fails due to time out on Windows [v2]
In-Reply-To: <eqKm36BE1yy0KZsht_6T0T31CR2l6TQV2aoAOGqWBXk=.55c55e5e-4c21-44ce-ac50-0a0284539a9a@github.com>
References: <BZscaovi-OCDqFducnsfhzKJxLN-nh0nz1hlYEvEXTM=.c7e3342f-b587-46a3-a703-8b5773fd623a@github.com>
 <eqKm36BE1yy0KZsht_6T0T31CR2l6TQV2aoAOGqWBXk=.55c55e5e-4c21-44ce-ac50-0a0284539a9a@github.com>
Message-ID: <JB7jBrivhoL-LA_zzTj7FSK80N3ThC8zqoRd3e52Qnc=.2b59e306-5238-45aa-a80d-bf29c1c3369e@github.com>

On Fri, 22 Aug 2025 11:07:17 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> Jstack streaming output should be disabled in the test as JDK-8354461 suggest. 
>> 
>> When disabled, the test does not hang with ZGC enabled. 
>> 
>> Tested locally.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8361370: Added explanatory comment.

Per discussions in JBS this change to the test seems fine. Some minor edits on the comment needed.

Thanks.

test/hotspot/jtreg/runtime/Thread/TestThreadDumpMonitorContention.java line 56:

> 54:     // the attach streaming output is enabled and the tool output is lengthy we can get both buffers (the attach
> 55:     // channel and the tool redirection buffer) full and the test hangs.
> 56:     // Instead the attach operation output is buffered and is sent after the operation is completed

Suggestion:

    // jstack streaming output should be disabled because if the attach operation is executed at a safepoint,
    // the attach streaming output is enabled, and the tool output is lengthy, then we can get both buffers (the attach
    // channel and the tool redirection buffer) full and the test hangs.
    // Instead the attach operation output is buffered and is sent after the operation is completed.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26895#pullrequestreview-3153998943
PR Review Comment: https://git.openjdk.org/jdk/pull/26895#discussion_r2299829682

From dholmes at openjdk.org  Tue Aug 26 05:42:37 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 26 Aug 2025 05:42:37 GMT
Subject: RFR: 8364352: Some tests fail when using a limited number of
 pregenerated .jsa CDS archives
In-Reply-To: <5e6obGQNZlN4awG0WbR1qWNcC7C88fgWEEEb4ZOTRNw=.ba0e22de-1350-401b-b0f1-0653976965ed@github.com>
References: <EnyzXiapmd29T3spHQT7QTBv2SVQVKVU6L2NEDoejHg=.65f803f7-09e0-4e5b-ac21-a60474c5facd@github.com>
 <GtNL83Xo_ncqcYTVTO4Qz0pby8BvHeKe9pmptdFQLd4=.6902d787-ed68-420e-901b-56f88fe482f5@github.com>
 <5e6obGQNZlN4awG0WbR1qWNcC7C88fgWEEEb4ZOTRNw=.ba0e22de-1350-401b-b0f1-0653976965ed@github.com>
Message-ID: <gwWRTXQ6vjfRvGlLM3HenYaeTpn4kX8onqqQTbSfHHk=.9983800c-03d8-4f32-a3bd-4a224182e9da@github.com>

On Mon, 25 Aug 2025 08:12:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java line 58:
>> 
>>> 56:  * @test id=custom-cl-zgc
>>> 57:  * @requires vm.cds.custom.loaders
>>> 58:  * @requires vm.cds.default.archive.available
>> 
>> Don't understand this one. This test is hard to follow but I think it does its own dumping of the CDS archive, so I don't see why it would need the default archive to exist. ???
>
> we run into this error without the jsa in the zgc case
> runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java#custom-cl-zgc
> 
> 
> [0.002s][error][cds] Specified shared archive file not found (/jtreg_hotspot_tier2_work/JTwork/scratch/2/appcds-06h49m10s700.jsa)
> [0.002s][error][cds] Not a valid shared archive file (/jtreg_hotspot_tier2_work/JTwork/scratch/2/appcds-06h49m10s700.jsa)
> [0.002s][error][cds] CDS is incompatible with other specified options.
> Error occurred during initialization of VM
> Unable to use shared archive: invalid archive

But that is not a default archive. ???

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26820#discussion_r2299837919

From stuefe at openjdk.org  Tue Aug 26 06:14:39 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 26 Aug 2025 06:14:39 GMT
Subject: RFR: 8364352: Some tests fail when using a limited number of
 pregenerated .jsa CDS archives
In-Reply-To: <gwWRTXQ6vjfRvGlLM3HenYaeTpn4kX8onqqQTbSfHHk=.9983800c-03d8-4f32-a3bd-4a224182e9da@github.com>
References: <EnyzXiapmd29T3spHQT7QTBv2SVQVKVU6L2NEDoejHg=.65f803f7-09e0-4e5b-ac21-a60474c5facd@github.com>
 <GtNL83Xo_ncqcYTVTO4Qz0pby8BvHeKe9pmptdFQLd4=.6902d787-ed68-420e-901b-56f88fe482f5@github.com>
 <5e6obGQNZlN4awG0WbR1qWNcC7C88fgWEEEb4ZOTRNw=.ba0e22de-1350-401b-b0f1-0653976965ed@github.com>
 <gwWRTXQ6vjfRvGlLM3HenYaeTpn4kX8onqqQTbSfHHk=.9983800c-03d8-4f32-a3bd-4a224182e9da@github.com>
Message-ID: <S-Dug22fgH7CCXqJCmjgc3XLme2oM0Gj7IMh-E_ME7E=.6cd2215d-e71b-4a8a-8ffc-e3d3e47592d7@github.com>

On Tue, 26 Aug 2025 05:39:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> we run into this error without the jsa in the zgc case
>> runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java#custom-cl-zgc
>> 
>> 
>> [0.002s][error][cds] Specified shared archive file not found (/jtreg_hotspot_tier2_work/JTwork/scratch/2/appcds-06h49m10s700.jsa)
>> [0.002s][error][cds] Not a valid shared archive file (/jtreg_hotspot_tier2_work/JTwork/scratch/2/appcds-06h49m10s700.jsa)
>> [0.002s][error][cds] CDS is incompatible with other specified options.
>> Error occurred during initialization of VM
>> Unable to use shared archive: invalid archive
>
> But that is not a default archive. ???

The error is strange

[0.002s][error][cds] Specified shared archive file not found (/jtreg_hotspot_tier2_work/JTwork/scratch/2/appcds-06h49m10s700.jsa)

This is not the default archive file it cannot find. This is the generated one, no?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26820#discussion_r2299886791

From stuefe at openjdk.org  Tue Aug 26 06:14:40 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 26 Aug 2025 06:14:40 GMT
Subject: RFR: 8364352: Some tests fail when using a limited number of
 pregenerated .jsa CDS archives
In-Reply-To: <S-Dug22fgH7CCXqJCmjgc3XLme2oM0Gj7IMh-E_ME7E=.6cd2215d-e71b-4a8a-8ffc-e3d3e47592d7@github.com>
References: <EnyzXiapmd29T3spHQT7QTBv2SVQVKVU6L2NEDoejHg=.65f803f7-09e0-4e5b-ac21-a60474c5facd@github.com>
 <GtNL83Xo_ncqcYTVTO4Qz0pby8BvHeKe9pmptdFQLd4=.6902d787-ed68-420e-901b-56f88fe482f5@github.com>
 <5e6obGQNZlN4awG0WbR1qWNcC7C88fgWEEEb4ZOTRNw=.ba0e22de-1350-401b-b0f1-0653976965ed@github.com>
 <gwWRTXQ6vjfRvGlLM3HenYaeTpn4kX8onqqQTbSfHHk=.9983800c-03d8-4f32-a3bd-4a224182e9da@github.com>
 <S-Dug22fgH7CCXqJCmjgc3XLme2oM0Gj7IMh-E_ME7E=.6cd2215d-e71b-4a8a-8ffc-e3d3e47592d7@github.com>
Message-ID: <vvi0stwxlOly34PZF8X7rsryHf3NsA4Yi7cfzmvzJmg=.6926162c-abb9-48c6-a5cf-f1167fb2f9b5@github.com>

On Tue, 26 Aug 2025 06:11:04 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> But that is not a default archive. ???
>
> The error is strange
> 
> [0.002s][error][cds] Specified shared archive file not found (/jtreg_hotspot_tier2_work/JTwork/scratch/2/appcds-06h49m10s700.jsa)
> 
> This is not the default archive file it cannot find. This is the generated one, no?

Does the test succeed if you generate all archive files?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26820#discussion_r2299887763

From mbaesken at openjdk.org  Tue Aug 26 06:16:39 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 26 Aug 2025 06:16:39 GMT
Subject: RFR: 8365442: [asan]
 runtime/ErrorHandling/CreateCoredumpOnCrash.java fails
In-Reply-To: <-GqE1fb2WD4p_wzi-OmxsyZg8InMm2lziqJxovx6SPk=.d1fb5604-6247-41e9-a924-bd8f5187e80f@github.com>
References: <-GqE1fb2WD4p_wzi-OmxsyZg8InMm2lziqJxovx6SPk=.d1fb5604-6247-41e9-a924-bd8f5187e80f@github.com>
Message-ID: <YmVIfqc3PPSNB97nkmgQbLT8P_kVacfWToW6COsL1JI=.b16a22bf-d909-4198-8a6f-fcc80591b374@github.com>

On Mon, 25 Aug 2025 12:55:13 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running with asan - enabled binaries, the test CreateCoredumpOnCrash.java fails with the output below. Seems asan does not work well with ulimit used in the test, so better avoid running it with asan enabled.
> 
> 
> [2025-08-09T09:25:35.801707203Z] Gathering output for process 4376
> [2025-08-09T09:25:41.863125073Z] Waiting for completion for process 4376
> [2025-08-09T09:25:41.863790182Z] Waiting for completion finished for process 4376
> [2025-08-09T09:25:41.876094199Z] Gathering output for process 5017
> [2025-08-09T09:25:41.883445027Z] Waiting for completion for process 5017
> [2025-08-09T09:25:41.883598661Z] Waiting for completion finished for process 5017
> ----------System.err:(10/570)----------
> java.lang.Exception: ulimit is not set correctly, try 'ulimit -c unlimited' and re-run.
> at CreateCoredumpOnCrash.main(CreateCoredumpOnCrash.java:82)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> at java.base/java.lang.reflect.Method.invoke(Method.java:565)
> at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335)
> at java.base/java.lang.Thread.run(Thread.java:1474)

Thanks for the review !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26927#issuecomment-3222761735

From mbaesken at openjdk.org  Tue Aug 26 06:16:40 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 26 Aug 2025 06:16:40 GMT
Subject: Integrated: 8365442: [asan]
 runtime/ErrorHandling/CreateCoredumpOnCrash.java fails
In-Reply-To: <-GqE1fb2WD4p_wzi-OmxsyZg8InMm2lziqJxovx6SPk=.d1fb5604-6247-41e9-a924-bd8f5187e80f@github.com>
References: <-GqE1fb2WD4p_wzi-OmxsyZg8InMm2lziqJxovx6SPk=.d1fb5604-6247-41e9-a924-bd8f5187e80f@github.com>
Message-ID: <7YKqXc0y181KLGGxmLkX0cvWl8Qud6_J4nAyYZJ2cEc=.92656374-6b69-4b14-8b88-e9edb193c083@github.com>

On Mon, 25 Aug 2025 12:55:13 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running with asan - enabled binaries, the test CreateCoredumpOnCrash.java fails with the output below. Seems asan does not work well with ulimit used in the test, so better avoid running it with asan enabled.
> 
> 
> [2025-08-09T09:25:35.801707203Z] Gathering output for process 4376
> [2025-08-09T09:25:41.863125073Z] Waiting for completion for process 4376
> [2025-08-09T09:25:41.863790182Z] Waiting for completion finished for process 4376
> [2025-08-09T09:25:41.876094199Z] Gathering output for process 5017
> [2025-08-09T09:25:41.883445027Z] Waiting for completion for process 5017
> [2025-08-09T09:25:41.883598661Z] Waiting for completion finished for process 5017
> ----------System.err:(10/570)----------
> java.lang.Exception: ulimit is not set correctly, try 'ulimit -c unlimited' and re-run.
> at CreateCoredumpOnCrash.main(CreateCoredumpOnCrash.java:82)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> at java.base/java.lang.reflect.Method.invoke(Method.java:565)
> at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335)
> at java.base/java.lang.Thread.run(Thread.java:1474)

This pull request has now been integrated.

Changeset: e5ec4641
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e5ec464120bec50ab111ee32dfb930f26150b109
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8365442: [asan] runtime/ErrorHandling/CreateCoredumpOnCrash.java fails

Reviewed-by: jsjolen

-------------

PR: https://git.openjdk.org/jdk/pull/26927

From dholmes at openjdk.org  Tue Aug 26 06:31:38 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 26 Aug 2025 06:31:38 GMT
Subject: RFR: 8365633: Incorrect info is reported on hybrid CPU [v4]
In-Reply-To: <RyaCh5StldhzMTgCz-6wweIhrVMLBh59aiiCL5E4FYU=.724d05dd-2a8c-4aff-ac72-6cc08d38d60d@github.com>
References: <T2R7vtbL0AaZLcRKdAPjoM6I8kz6lclHBNnOXi8JIQY=.1af945fd-1592-423a-8a19-940dd1c531d3@github.com>
 <RyaCh5StldhzMTgCz-6wweIhrVMLBh59aiiCL5E4FYU=.724d05dd-2a8c-4aff-ac72-6cc08d38d60d@github.com>
Message-ID: <RfUTjyi7YOxE9qFMG5bgbvY9bw9cQMipfes-LOcQyLg=.d7606468-3d93-455d-abd5-4a878f69219d@github.com>

On Fri, 22 Aug 2025 00:58:26 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> `VM.info` DCmd reports CPU information. I ran this on Intel Core Ultra 5 225U , then I got following result:
>> 
>> 
>> CPU: total 14 (initial active 14) (7 cores per cpu, 2 threads per core) family 6 model 181 stepping 0 microcode 0xffffffff, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, clwb, hv, serialize, rdtscp, rdpid, fsrm, gfni, f16c, cet_ibt, cet_ss
>> CPU Model and flags from /proc/cpuinfo:
>> model name : Intel(R) Core(TM) Ultra 5 225U
>> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm pni pclmulqdq monitor est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave osxsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch fsgsbase bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb intel_pt sha_ni umip gfni vaes vpclmulqdq rdpid ibrs ibpb stibp ssbd
>> 
>> 
>> It reports "7 cores per cpu, 2 threads per core". 225U has hybrid architecture - 2 P cores, 8 E cores, 2 LP cores, and also P core has 2 threads per core. Then it should be "12 cores, 14 threads".
>> https://www.intel.com/content/www/us/en/products/sku/241861/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html
>> 
>> According to Intel Software Developer's Manual, it seems to be difficult to get number of physical cores. In Linux kernel, it seems to be calculated by complex logic: https://github.com/torvalds/linux/blob/v6.16/arch/x86/kernel/smpboot.c#L567-L597
>> In addition, all of P cores might not be enabled HT. Thus to show only number of threads is reasonable at this point.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Indicate "(hybrid)" on hybrid CPU

Sorry for the delay. Looks good. Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26808#pullrequestreview-3154112882

From dholmes at openjdk.org  Tue Aug 26 06:37:38 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 26 Aug 2025 06:37:38 GMT
Subject: RFR: 8365673: Incorrect number of cores are reported on Ryzen CPU
In-Reply-To: <BjQ9knzbbefSqRxv6jHHcy1HzSflVSYQvlSQKlt3AF8=.ae3685bd-87c1-45b0-a1ad-6e630bfe9af9@github.com>
References: <BjQ9knzbbefSqRxv6jHHcy1HzSflVSYQvlSQKlt3AF8=.ae3685bd-87c1-45b0-a1ad-6e630bfe9af9@github.com>
Message-ID: <Nxh_Qq9ofKR5NHgNAAQiojO-hWe4uDXCXXWeGn5zNZw=.dd2ecf19-dc40-4efa-9ced-5adaaf030f0d@github.com>

On Mon, 18 Aug 2025 10:01:46 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> `VM.info` DCmd reports CPU information. I ran this on Ryzen 3 3300X, then I got following result:
> 
> 
> CPU: total 8 (initial active 8) (8 cores per cpu, 2 threads per core) family 23 model 113 stepping 0 microcode 0xffffffff, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4a, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, hv, rdtscp, rdpid, f16c
> CPU Model and flags from /proc/cpuinfo:
> model name : AMD Ryzen 3 3300X 4-Core Processor
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl tsc_reliable nonstop_tsc cpuid extd_apicid tsc_known_freq pni pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm cmp_legacy svm cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw topoext perfctr_core ssbd ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 clzero xsaveerptr arat npt nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold v_vmsave_vmload umip rdpid
> 
> 
> It reports "8 cores per cpu, 2 threads per core". However, according to [spec sheet](https://www.amd.com/en/support/downloads/drivers.html/processors/ryzen/ryzen-3000-series/amd-ryzen-3-3300x.html), 3300X has 4 cores 8 threads. (In addition, cpuinfo says "4-Core Processor")
> 
> According to [Programmer's Manual by AMD](https://docs.amd.com/v/u/en-US/40332-PUB_4.08), Bit 7:0 in `ECX` from `CPUID` leaf `80000008h` means number of threads, not cores. Thus we should divide it by threads per core.
> 
> After this change, we can see correct number of cores as following on 3300X:
> 
> CPU: total 8 (initial active 8) (4 cores per cpu, 2 threads per core) family 23 model 113 stepping 0 microcode 0xffffffff, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4a, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, clwb, hv, rdtscp, rdpid, f16c
> CPU Model and flags from /proc/cpuinfo:
> model name      : AMD Ryzen 3 3300X 4-Core Processor

Okay now I understand. Sorry for the delay.

Don't forget a second review is needed.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26819#pullrequestreview-3154129994
PR Comment: https://git.openjdk.org/jdk/pull/26819#issuecomment-3222813047

From dholmes at openjdk.org  Tue Aug 26 07:04:38 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 26 Aug 2025 07:04:38 GMT
Subject: RFR: 8365885: Clean up constant pool reflection native code
In-Reply-To: <Sp5bJ-Ceo_WVhCq6Y9nGjJ_oTXdM-QinhEvf3Q8JUw4=.9ca004e5-d219-4e31-ab7b-e13b50b347e2@github.com>
References: <Sp5bJ-Ceo_WVhCq6Y9nGjJ_oTXdM-QinhEvf3Q8JUw4=.9ca004e5-d219-4e31-ab7b-e13b50b347e2@github.com>
Message-ID: <lXu0SV8E3CckrRonfFgx2JDU43jx_aixruPYVWP7AQc=.b9c8cc28-e954-4f81-a71a-66d224b0831e@github.com>

On Wed, 20 Aug 2025 21:29:29 GMT, Chen Liang <liach at openjdk.org> wrote:

> When I was trying to reuse this constant pool reflection for assembly phase indy argument validation, I noted the JNI code has a lot of confusing arguments. In particular, the JVM_ConstantPoolGetSize is wrong because of argument confusion. We should remove the unused arguments to reduce confusion.

Wow that was such a mess! It looks like the native methods were intended to be static - hence the initial unused argument. But how did this even work when the jvm.cpp implementations reversed the arguments ?? One was an instance of `ConstantPool` and the other the VM set `constantPoolOop`. !!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26870#issuecomment-3222886432

From ysuenaga at openjdk.org  Tue Aug 26 07:07:45 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Tue, 26 Aug 2025 07:07:45 GMT
Subject: Integrated: 8365633: Incorrect info is reported on hybrid CPU
In-Reply-To: <T2R7vtbL0AaZLcRKdAPjoM6I8kz6lclHBNnOXi8JIQY=.1af945fd-1592-423a-8a19-940dd1c531d3@github.com>
References: <T2R7vtbL0AaZLcRKdAPjoM6I8kz6lclHBNnOXi8JIQY=.1af945fd-1592-423a-8a19-940dd1c531d3@github.com>
Message-ID: <hDQSQ-QCmb3gzTBMWr488KnUzgXZbSVU7VLUfcMO2_s=.cee58f34-fec8-415b-b184-e86345a8eba0@github.com>

On Sat, 16 Aug 2025 14:11:27 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> `VM.info` DCmd reports CPU information. I ran this on Intel Core Ultra 5 225U , then I got following result:
> 
> 
> CPU: total 14 (initial active 14) (7 cores per cpu, 2 threads per core) family 6 model 181 stepping 0 microcode 0xffffffff, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, clwb, hv, serialize, rdtscp, rdpid, fsrm, gfni, f16c, cet_ibt, cet_ss
> CPU Model and flags from /proc/cpuinfo:
> model name : Intel(R) Core(TM) Ultra 5 225U
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm pni pclmulqdq monitor est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave osxsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch fsgsbase bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb intel_pt sha_ni umip gfni vaes vpclmulqdq rdpid ibrs ibpb stibp ssbd
> 
> 
> It reports "7 cores per cpu, 2 threads per core". 225U has hybrid architecture - 2 P cores, 8 E cores, 2 LP cores, and also P core has 2 threads per core. Then it should be "12 cores, 14 threads".
> https://www.intel.com/content/www/us/en/products/sku/241861/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html
> 
> According to Intel Software Developer's Manual, it seems to be difficult to get number of physical cores. In Linux kernel, it seems to be calculated by complex logic: https://github.com/torvalds/linux/blob/v6.16/arch/x86/kernel/smpboot.c#L567-L597
> In addition, all of P cores might not be enabled HT. Thus to show only number of threads is reasonable at this point.

This pull request has now been integrated.

Changeset: 5013d69d
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5013d69d96e5052972bc04c78a060fd9296518e2
Stats:     15 lines in 3 files changed: 10 ins; 0 del; 5 mod

8365633: Incorrect info is reported on hybrid CPU

Reviewed-by: kvn, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/26808

From duke at openjdk.org  Tue Aug 26 07:55:52 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 26 Aug 2025 07:55:52 GMT
Subject: RFR: 8361370: runtime/Thread/TestThreadDumpMonitorContention.java
 fails due to time out on Windows [v2]
In-Reply-To: <JB7jBrivhoL-LA_zzTj7FSK80N3ThC8zqoRd3e52Qnc=.2b59e306-5238-45aa-a80d-bf29c1c3369e@github.com>
References: <BZscaovi-OCDqFducnsfhzKJxLN-nh0nz1hlYEvEXTM=.c7e3342f-b587-46a3-a703-8b5773fd623a@github.com>
 <eqKm36BE1yy0KZsht_6T0T31CR2l6TQV2aoAOGqWBXk=.55c55e5e-4c21-44ce-ac50-0a0284539a9a@github.com>
 <JB7jBrivhoL-LA_zzTj7FSK80N3ThC8zqoRd3e52Qnc=.2b59e306-5238-45aa-a80d-bf29c1c3369e@github.com>
Message-ID: <OZBQc5bHzF9df_EsXFbFTyXJh_jJeV1u7an5AD004j8=.45ec3336-ce67-459e-a357-33d7e32f1161@github.com>

On Tue, 26 Aug 2025 05:34:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8361370: Added explanatory comment.
>
> test/hotspot/jtreg/runtime/Thread/TestThreadDumpMonitorContention.java line 56:
> 
>> 54:     // the attach streaming output is enabled and the tool output is lengthy we can get both buffers (the attach
>> 55:     // channel and the tool redirection buffer) full and the test hangs.
>> 56:     // Instead the attach operation output is buffered and is sent after the operation is completed
> 
> Suggestion:
> 
>     // jstack streaming output should be disabled because if the attach operation is executed at a safepoint,
>     // the attach streaming output is enabled, and the tool output is lengthy, then we can get both buffers (the attach
>     // channel and the tool redirection buffer) full and the test hangs.
>     // Instead the attach operation output is buffered and is sent after the operation is completed.

Thanks for spotting, addressed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26895#discussion_r2300125616

From duke at openjdk.org  Tue Aug 26 07:55:51 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 26 Aug 2025 07:55:51 GMT
Subject: RFR: 8361370: runtime/Thread/TestThreadDumpMonitorContention.java
 fails due to time out on Windows [v3]
In-Reply-To: <BZscaovi-OCDqFducnsfhzKJxLN-nh0nz1hlYEvEXTM=.c7e3342f-b587-46a3-a703-8b5773fd623a@github.com>
References: <BZscaovi-OCDqFducnsfhzKJxLN-nh0nz1hlYEvEXTM=.c7e3342f-b587-46a3-a703-8b5773fd623a@github.com>
Message-ID: <keVt1QMP_tId9Z70064-zFvb4Y9lmnqxNgMUp0wM3DY=.addc913d-c694-4efa-9da5-bf5e1b67ab88@github.com>

> Hi, please consider the following changes:
> 
> Jstack streaming output should be disabled in the test as JDK-8354461 suggest. 
> 
> When disabled, the test does not hang with ZGC enabled. 
> 
> Tested locally.

Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:

  8361370: Fixed typos in the comment.
  
  Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26895/files
  - new: https://git.openjdk.org/jdk/pull/26895/files/3bed268a..895a5d97

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26895&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26895&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/26895.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26895/head:pull/26895

PR: https://git.openjdk.org/jdk/pull/26895

From ghan at openjdk.org  Tue Aug 26 08:38:39 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Tue, 26 Aug 2025 08:38:39 GMT
Subject: RFR: 8366035: Simplify CPUTimeCounters::publish_gc_total_cpu_time
 [v2]
In-Reply-To: <HTGnxPQ0LJSi25X69QmDYlfaRY7iK6kEDqpfcLLMfI8=.4ac2efb6-4c25-46f7-bdf0-b9b9b353d237@github.com>
References: <ntNDtmG1fFR5BMjgDThR96R3R8VpdPAgThaR28Nok44=.b93537c8-c9e8-4cfd-9146-a4e3f32cfbde@github.com>
 <AlZZzoUCMfM6kWEWUk0tSIuoisMzmYWDdG_ibpCKHbU=.65a28dc2-466e-40d4-bc2d-aee23f3d76ce@github.com>
 <HTGnxPQ0LJSi25X69QmDYlfaRY7iK6kEDqpfcLLMfI8=.4ac2efb6-4c25-46f7-bdf0-b9b9b353d237@github.com>
Message-ID: <9OwgKIyEKxxfUjTtlUz7t0SMvvG40hFod-YUzXcFT8U=.49dcd745-341d-4664-b921-498fb54f35a0@github.com>

On Mon, 25 Aug 2025 09:11:45 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update cpuTimeCounters.cpp
>>   
>>   a small fix
>
> Marked as reviewed by ayang (Reviewer).

@albertnetymk @kimbarrett Thanks for your reviews! I?ve integrated this PR. Could you please sponsor it?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26921#issuecomment-3223168189

From ghan at openjdk.org  Tue Aug 26 08:38:40 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Tue, 26 Aug 2025 08:38:40 GMT
Subject: Integrated: 8366035: Simplify
 CPUTimeCounters::publish_gc_total_cpu_time
In-Reply-To: <ntNDtmG1fFR5BMjgDThR96R3R8VpdPAgThaR28Nok44=.b93537c8-c9e8-4cfd-9146-a4e3f32cfbde@github.com>
References: <ntNDtmG1fFR5BMjgDThR96R3R8VpdPAgThaR28Nok44=.b93537c8-c9e8-4cfd-9146-a4e3f32cfbde@github.com>
Message-ID: <0TIULUzP9Wjql9Wy3-kRj_jcK6Vt7Cm8HGqTwtyTDJ4=.8105d994-9038-4778-ab8c-349fdbfe3e48@github.com>

On Mon, 25 Aug 2025 08:10:17 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

> This change refactors CPUTimeCounters::publish_gc_total_cpu_time() to use Atomic::xchg instead of a CAS (cmpxchg) loop.
> Please review it. Thanks

This pull request has now been integrated.

Changeset: 2ae3ea2a
Author:    Guanqiang Han <ghan at openjdk.org>
Committer: Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2ae3ea2ad93b83deec1922159d80b94da0397357
Stats:     8 lines in 1 file changed: 0 ins; 6 del; 2 mod

8366035: Simplify CPUTimeCounters::publish_gc_total_cpu_time

Reviewed-by: ayang, kbarrett

-------------

PR: https://git.openjdk.org/jdk/pull/26921

From jsjolen at openjdk.org  Tue Aug 26 08:53:44 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 26 Aug 2025 08:53:44 GMT
Subject: RFR: 8365442: [asan]
 runtime/ErrorHandling/CreateCoredumpOnCrash.java fails
In-Reply-To: <-GqE1fb2WD4p_wzi-OmxsyZg8InMm2lziqJxovx6SPk=.d1fb5604-6247-41e9-a924-bd8f5187e80f@github.com>
References: <-GqE1fb2WD4p_wzi-OmxsyZg8InMm2lziqJxovx6SPk=.d1fb5604-6247-41e9-a924-bd8f5187e80f@github.com>
Message-ID: <S2lPvQSrnX3DVtvvqVfreHi-ys_9POvxrtygLmv1jb0=.f3dce36d-f087-41c0-850a-387c5ddb63d6@github.com>

On Mon, 25 Aug 2025 12:55:13 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running with asan - enabled binaries, the test CreateCoredumpOnCrash.java fails with the output below. Seems asan does not work well with ulimit used in the test, so better avoid running it with asan enabled.
> 
> 
> [2025-08-09T09:25:35.801707203Z] Gathering output for process 4376
> [2025-08-09T09:25:41.863125073Z] Waiting for completion for process 4376
> [2025-08-09T09:25:41.863790182Z] Waiting for completion finished for process 4376
> [2025-08-09T09:25:41.876094199Z] Gathering output for process 5017
> [2025-08-09T09:25:41.883445027Z] Waiting for completion for process 5017
> [2025-08-09T09:25:41.883598661Z] Waiting for completion finished for process 5017
> ----------System.err:(10/570)----------
> java.lang.Exception: ulimit is not set correctly, try 'ulimit -c unlimited' and re-run.
> at CreateCoredumpOnCrash.main(CreateCoredumpOnCrash.java:82)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> at java.base/java.lang.reflect.Method.invoke(Method.java:565)
> at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335)
> at java.base/java.lang.Thread.run(Thread.java:1474)

> Thanks for the review !
> 
> /integrate

Thanks for fixing it :). Could you please wait 24 hours after opening the PR and wait for a 2nd reviewer before integrating next time? I wasn't sure if this was actually trivial, and we want all time zones to get a chance to look at a PR before it goes in.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26927#issuecomment-3223232637

From stefank at openjdk.org  Tue Aug 26 09:43:34 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 26 Aug 2025 09:43:34 GMT
Subject: RFR: 8353468: [ubsan] arguments.cpp:2422:23: runtime error:
 2.14748e+11 is outside the range of representable values of type 'int' [v2]
In-Reply-To: <4Ds0MTQtlz861U-p1N3flLCgZbBrFQdoG0Sclg6d9p4=.48ef346b-56c4-4a2e-a656-fbabc1514302@github.com>
References: <plQ5n7EjsekIjeY431_mBeo4rfcH39SVdPWogF2rT44=.20180c89-665e-4054-8625-1b04f8306b3b@github.com>
 <4Ds0MTQtlz861U-p1N3flLCgZbBrFQdoG0Sclg6d9p4=.48ef346b-56c4-4a2e-a656-fbabc1514302@github.com>
Message-ID: <QmB_NMGiWUQH-13XHjEdgfOAmSm_HeY1JhVEMppceKk=.4b53e574-eacd-4970-9c9a-c35b9db93e63@github.com>

On Thu, 21 Aug 2025 09:49:09 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> In converting values of `-XMinf` and `-XMaxf` options to `int`, overflow was not checked. 
>> The values are checked against INT_MAX and clamped.
>> 
>> Tests: tiers 1-5.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   negative underflow checked.

I was looking and I'm starting to have some doubts about this surrounding code. 

If I run with the following command line (before the proposed changes):


$ ~/java/jdk-21/bin/java -Xminf5 -version

uintx MinHeapFreeRatio=500 is outside the allowed range [ 0 ... 100 ]
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.


So, this indicate that the user should not specify a percentage when setting -Xminf. The user should be setting a value that is a 100th of the percentage they want to use. So, this sounds like a ratio?  The code then takes the ratio value and multiplies with 100 (so that it gets a percentage) and then passes it into a flag called MinHeapFreeRatio! Fine, that flag is weirdly named, but see what happens in the next command line:


$ ~/java/jdk-21/bin/java -Xminf=5 -version

Bad min heap free percentage size: -Xminf=5
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

The error handling code talks about the format of -Xminf and complains that it isn't a percentage. But it shouldn't be a percentage it should be a ratio (that afterwards gets multiplied by 100 to get a percentage). So, the error message is wrong.

Note also that today and I guess with this PR we get this weird output if you specify a negative value:


$ java -Xminf-5 -version

uintx MinHeapFreeRatio=18446744073709551116 is outside the allowed range [ 0 ... 100 ]
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

Here the user gets a `18446744073709551116` reported even though that's not what the user specified on the command line.


I wonder if it wouldn't be better if we take care of checking that -Xminf and -Xmaxf is within [0.0, 1.0] and error out if it is not. And do all that before we even try to set Min/MaxHeapFreeRatio, so that we don't get error messages that isn't obvious how it correlates with the user's input.

I'd prefer to solve this bug as part of a cleanup like this, but I'm also fine with checking in what you have here and taking care of this as a follow-up PR.

-------------

PR Review: https://git.openjdk.org/jdk/pull/26859#pullrequestreview-3154834118

From ayang at openjdk.org  Tue Aug 26 10:59:36 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 26 Aug 2025 10:59:36 GMT
Subject: RFR: 8365975: Sort share/memory includes [v2]
In-Reply-To: <6rtzZx8IPP532a3qzBQ0lN9G9J5xWukiftDjNG0ENEE=.37b2564d-d793-407c-8d01-5cce731ad687@github.com>
References: <TUfg-TEPul_3CAv9kmnFbiJ9C5vUxixuA8nJyk9F6TY=.e438c1c4-02d7-4f57-a810-93d1116091d7@github.com>
 <6rtzZx8IPP532a3qzBQ0lN9G9J5xWukiftDjNG0ENEE=.37b2564d-d793-407c-8d01-5cce731ad687@github.com>
Message-ID: <WoXAKfA8CUSIppfvHFsN7V1ZXEXGVl_iQ3Zl9q8eYTM=.9fcb62ca-8ce4-43a9-97d4-fcf472255e89@github.com>

On Fri, 22 Aug 2025 10:01:30 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> This PR sorts the includes in `hotspot/share/memory` using `SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted`, and removing a couple of unnecessary include statements.
>> 
>> Passes `tier1`.
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert

Marked as reviewed by ayang (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26897#pullrequestreview-3155082295

From duke at openjdk.org  Tue Aug 26 10:59:36 2025
From: duke at openjdk.org (duke)
Date: Tue, 26 Aug 2025 10:59:36 GMT
Subject: RFR: 8365975: Sort share/memory includes [v2]
In-Reply-To: <6rtzZx8IPP532a3qzBQ0lN9G9J5xWukiftDjNG0ENEE=.37b2564d-d793-407c-8d01-5cce731ad687@github.com>
References: <TUfg-TEPul_3CAv9kmnFbiJ9C5vUxixuA8nJyk9F6TY=.e438c1c4-02d7-4f57-a810-93d1116091d7@github.com>
 <6rtzZx8IPP532a3qzBQ0lN9G9J5xWukiftDjNG0ENEE=.37b2564d-d793-407c-8d01-5cce731ad687@github.com>
Message-ID: <3WbMaXl0VfekG7xSWpfrikxjrsugqUEG6jQM1DkqiM8=.47a884c8-e336-4ae8-93bd-cd4892f2defd@github.com>

On Fri, 22 Aug 2025 10:01:30 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> This PR sorts the includes in `hotspot/share/memory` using `SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted`, and removing a couple of unnecessary include statements.
>> 
>> Passes `tier1`.
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert

@fandreuz 
Your change (at version dbdcd4aa1778fda464f8c553ef3cc4bc4a14854c) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26897#issuecomment-3223675874

From duke at openjdk.org  Tue Aug 26 11:04:35 2025
From: duke at openjdk.org (mazhen)
Date: Tue, 26 Aug 2025 11:04:35 GMT
Subject: RFR: 8303612:
 runtime/StackGuardPages/TestStackGuardPagesNative.java fails with exit code
 139
In-Reply-To: <lJRJpcHQe1HHoiDFbTwWZo13-3BhpMq4uwFNegBJ1ww=.1ccda972-41a1-4373-baba-c9f0a0e1795f@github.com>
References: <oRl4abf8ZV5qD9GNScJMRwwZD2PkdiDGJykDFs1Cmgo=.8c961e33-291f-4ba1-b494-ad5eab7ee72c@github.com>
 <blniq87ptY1r2ZSL2nR17MV-SHTmPOPcAPWRgCVqL24=.b011371a-c54e-4fd9-b25b-19e22c321d3f@github.com>
 <lJRJpcHQe1HHoiDFbTwWZo13-3BhpMq4uwFNegBJ1ww=.1ccda972-41a1-4373-baba-c9f0a0e1795f@github.com>
Message-ID: <Of5FTC1O-mz1Copg6nt2RPrNNqpbAup-0oyw2wpMTkg=.aea15777-8f96-4fb7-b05a-0493ba8e0c58@github.com>

On Tue, 5 Aug 2025 02:28:41 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Hi @jdksjolen ,
>> 
>> Following up on this. As per the bot's message two weeks ago, I've been waiting for my OCA to be processed, but it seems to be stuck.
>> I understand that PRs are not reviewed until the OCA is cleared, but since the suggested two-week waiting period has passed, I was hoping someone could help to check or escalate the status of my OCA application internally.
>> 
>> My Oracle Account Email: mz1999 at gmail.com
>> 
>> Any help would be greatly appreciated. Thank you!
>
> @mz1999 the forever-loop was added as part of the "hardening" changes by JDK-8295344, so it seems you are saying that introduced a new bug? How does your proposed change compare to the code that we had prior to the "hardening"? I just want to try and see what the original problem with this code was. Thanks

Hi @dholmes-ora  and @jdksjolen ,

Apologies for the delayed response.

Thank you for the comments. I wasn't aware of the historical context behind this test and the changes from JDK-8295344. My investigation started simply because I observed that the test behaved differently on two platforms. To help clarify what I'm seeing, let me walk you through my testing process with the original, unmodified `exeinvoke.c` code.

I reverted my local changes and ran the test on both Ubuntu 24 and CentOS 7.

### Test Environments

| Component      | Ubuntu 24.04 LTS                          | CentOS 7.9.2009                      |
| -------------- | ----------------------------------------- | ------------------------------------ |
| **OS Release** | Ubuntu 24.04.3 LTS                        | CentOS Linux release 7.9.2009 (Core) |
| **Kernel**     | 6.8.0-78-generic                          | 3.10.0-1160.el7.x86_64               |
| **glibc**      | ldd (Ubuntu GLIBC 2.39-0ubuntu8.5) 2.39   | ldd (GNU libc) 2.17                  |
| **GCC**        | gcc (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0 | gcc (GCC) 13.2.0                     |


### Test on Ubuntu 24.04 LTS

I ran the test using the following command to retain all test artifacts:

make test TEST="test/hotspot/jtreg/runtime/StackGuardPages/TestStackGuardPagesNative.java" JTREG="RETAIN=all"


The test passed successfully. The `TestStackGuardPagesNative.jtr` file shows:

...
----------System.out:(8/626)----------
[2025-08-26T07:35:59.646208363Z] Gathering output for process 379416
[2025-08-26T07:35:59.656232016Z] Waiting for completion for process 379416
[2025-08-26T07:35:59.656384019Z] Waiting for completion finished for process 379416
Output and diagnostic info for process 379416 was saved into 'pid-379416-output.log'
[2025-08-26T07:35:59.658186828Z] Gathering output for process 379439
[2025-08-26T07:35:59.658413390Z] Waiting for completion for process 379439
[2025-08-26T07:35:59.677953883Z] Waiting for completion finished for process 379439
Output and diagnostic info for process 379439 was saved into 'pid-379439-output.log'
----------System.err:(3/35)----------

JavaTest Message: Test complete.

result: Passed. Execution successful


test result: Passed. Execution successful


To understand *how* it passed, I examined the native process log for the `test_native_overflow_initial` scenario (`pid-379439-output.log`):

--- ProcessLog ---
cmd: /home/mazhen/works/jdk/build/linux-x86_64-server-release/images/test/hotspot/jtreg/native/invoke test_native_overflow_initial
exitvalue: 0
stderr: 
stdout: Test started with pid: 379439
Java thread is alive.

Testing NATIVE_OVERFLOW
Testing stack guard page behaviour for initial thread
run_native_overflow 379439
Got SIGSEGV(2) at address: 0x7fff45e5fff0
Test PASSED. Got access violation accessing guard page at 7104
Got SIGSEGV(1) at address: 0x7fff4575bf80
Test PASSED. No stack guard page is present. SIGSEGV(1) at 58191

The log shows that the second `do_overflow` call for the initial thread was terminated by a `SIGSEGV(1)` (`SEGV_MAPERR`). This observation prompted me to think about what the test's true intent might be.

Of course, this is just my interpretation, and I may be mistaken. From my reading, the test is designed as a two-phase process:

1. **Probe:** The first `do_overflow` call finds the exact allocation depth (`_rec_count`) that triggers the `SEGV_ACCERR` from the guard page.
2. **Verify:** The second `do_overflow` call should then confirm that after detaching the thread, it's safe to allocate up to that same depth again, this time completing **without any signal**.

A true "pass" for this verification should therefore correspond to the `_last_si_code == -1` check in the code, which explicitly handles the "no signal" scenario.


} else if (_last_si_code == -1) {
      printf("Test PASSED. No stack guard page is present. Maximum recursion level reached at %d\n", _rec_count);
}


However, the current test passes on Ubuntu not for this reason, but because the second overflow attempt is coincidentally terminated by a different signal, a `SEGV_MAPERR`. This shows that the test is not passing as intended.

### 2. Test on CentOS 7 (Hangs and Times Out)

Running the same test on CentOS 7 resulted in a timeout after 480 seconds. The `TestStackGuardPagesNative.jtr` file shows:

...
----------System.out:(6/436)----------
[2025-08-26T09:40:07.939476649Z] Gathering output for process 323
[2025-08-26T09:40:07.959566183Z] Waiting for completion for process 323
[2025-08-26T09:40:08.082615370Z] Waiting for completion finished for process 323
Output and diagnostic info for process 323 was saved into 'pid-323-output.log'
[2025-08-26T09:40:08.095675574Z] Gathering output for process 344
[2025-08-26T09:40:08.096106994Z] Waiting for completion for process 344
result: Error. "main" action timed out with a timeout of 480 seconds on agent 2


test result: Error. "main" action timed out with a timeout of 480 seconds on agent 2

I checked the test artifacts. The log for the `test_native_overflow` (non-initial thread) scenario, `pid-323-output.log`, was generated and showed a pass, as expected:

--- ProcessLog ---
cmd: /root/jdk/build/linux-x86_64-server-release/images/test/hotspot/jtreg/native/invoke test_native_overflow
exitvalue: 0
stderr: 
stdout: Test started with pid: 323
Java thread is alive.

Testing NATIVE_OVERFLOW
Testing stack guard page behaviour for other thread
run_native_overflow 342
Got SIGSEGV(2) at address: 0x2b4fffc94fb0
Test PASSED. Got access violation accessing guard page at 7137
Test PASSED. Not initial thread

However, the log for the failing `test_native_overflow_initial` scenario was not generated at all. This strongly suggests the process hung indefinitely in the `for(;;)` loop and was terminated before it had a chance to flush its output.

### Moving Forward

Your comments have been incredibly helpful. They've made me realize that this issue is far more complex than I first understood. My initial PR was focused squarely on fixing the hang symptom I observed on CentOS 7.

I will need to do some further investigation to fully understand the original problem that the for(;;) loop was intended to solve.

Thank you again for your guidance and patience.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25689#issuecomment-3223693969

From jwaters at openjdk.org  Tue Aug 26 12:34:39 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 26 Aug 2025 12:34:39 GMT
Subject: RFR: 8365975: Sort share/memory includes [v2]
In-Reply-To: <6rtzZx8IPP532a3qzBQ0lN9G9J5xWukiftDjNG0ENEE=.37b2564d-d793-407c-8d01-5cce731ad687@github.com>
References: <TUfg-TEPul_3CAv9kmnFbiJ9C5vUxixuA8nJyk9F6TY=.e438c1c4-02d7-4f57-a810-93d1116091d7@github.com>
 <6rtzZx8IPP532a3qzBQ0lN9G9J5xWukiftDjNG0ENEE=.37b2564d-d793-407c-8d01-5cce731ad687@github.com>
Message-ID: <hlW5KXHMaFEnNPBWMbUqNH0FXgChZELc1sCxLujS49Q=.e16c6a0b-c6dd-4d2e-a150-8821cd16b9df@github.com>

On Fri, 22 Aug 2025 10:01:30 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> This PR sorts the includes in `hotspot/share/memory` using `SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted`, and removing a couple of unnecessary include statements.
>> 
>> Passes `tier1`.
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert

I've never actually used the include sorting tool before. I see that it (SortIncludes.java) lives under jtreg, a strange place for a utility tool. Is it invoked automatically as part of the build process, or does one invoke it manually only when it's desired to sort includes of source files in a given directory? If it's the latter, it might be more suitable to be in src/utils instead. I digress, just thinking out loud here. The change itself is fine.

-------------

Marked as reviewed by jwaters (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26897#pullrequestreview-3155421239

From stefank at openjdk.org  Tue Aug 26 12:48:40 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 26 Aug 2025 12:48:40 GMT
Subject: RFR: 8365975: Sort share/memory includes [v2]
In-Reply-To: <6rtzZx8IPP532a3qzBQ0lN9G9J5xWukiftDjNG0ENEE=.37b2564d-d793-407c-8d01-5cce731ad687@github.com>
References: <TUfg-TEPul_3CAv9kmnFbiJ9C5vUxixuA8nJyk9F6TY=.e438c1c4-02d7-4f57-a810-93d1116091d7@github.com>
 <6rtzZx8IPP532a3qzBQ0lN9G9J5xWukiftDjNG0ENEE=.37b2564d-d793-407c-8d01-5cce731ad687@github.com>
Message-ID: <vRjtRUhAKf2_1MmXpELZGt4JpZKdozHLWj65SzDY5gk=.5958ee23-673d-4686-bb74-ae3f75dd47dd@github.com>

On Fri, 22 Aug 2025 10:01:30 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> This PR sorts the includes in `hotspot/share/memory` using `SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted`, and removing a couple of unnecessary include statements.
>> 
>> Passes `tier1`.
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert

FWIW, I had similar thoughts about the location of the tool when it was introduced:
https://mail.openjdk.org/pipermail/hotspot-dev/2025-March/103078.html

But I think I was in minority w.r.t. that when I asked around.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26897#issuecomment-3224034035

From liach at openjdk.org  Tue Aug 26 13:04:38 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 26 Aug 2025 13:04:38 GMT
Subject: RFR: 8365885: Clean up constant pool reflection native code
In-Reply-To: <Sp5bJ-Ceo_WVhCq6Y9nGjJ_oTXdM-QinhEvf3Q8JUw4=.9ca004e5-d219-4e31-ab7b-e13b50b347e2@github.com>
References: <Sp5bJ-Ceo_WVhCq6Y9nGjJ_oTXdM-QinhEvf3Q8JUw4=.9ca004e5-d219-4e31-ab7b-e13b50b347e2@github.com>
Message-ID: <PUaOsbfujqYHYuWN9ib9r-O3Baez4GqahEBOg3qFQGE=.8b40c1c8-eafe-4d3b-82d0-a4023b66c0ad@github.com>

On Wed, 20 Aug 2025 21:29:29 GMT, Chen Liang <liach at openjdk.org> wrote:

> When I was trying to reuse this constant pool reflection for assembly phase indy argument validation, I noted the JNI code has a lot of confusing arguments. In particular, the JVM_ConstantPoolGetSize is wrong because of argument confusion. We should remove the unused arguments to reduce confusion.

I think the old code consistently dropped the oop and used the instance despite what the jvm.h names indicate - if you call reflect_ConstantPool's function on the constantPoolOop (i.e. java.lang.Class for an IK) you get a crash.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26870#issuecomment-3224087039

From mbaesken at openjdk.org  Tue Aug 26 13:44:37 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 26 Aug 2025 13:44:37 GMT
Subject: RFR: 8364352: Some tests fail when using a limited number of
 pregenerated .jsa CDS archives
In-Reply-To: <vvi0stwxlOly34PZF8X7rsryHf3NsA4Yi7cfzmvzJmg=.6926162c-abb9-48c6-a5cf-f1167fb2f9b5@github.com>
References: <EnyzXiapmd29T3spHQT7QTBv2SVQVKVU6L2NEDoejHg=.65f803f7-09e0-4e5b-ac21-a60474c5facd@github.com>
 <GtNL83Xo_ncqcYTVTO4Qz0pby8BvHeKe9pmptdFQLd4=.6902d787-ed68-420e-901b-56f88fe482f5@github.com>
 <5e6obGQNZlN4awG0WbR1qWNcC7C88fgWEEEb4ZOTRNw=.ba0e22de-1350-401b-b0f1-0653976965ed@github.com>
 <gwWRTXQ6vjfRvGlLM3HenYaeTpn4kX8onqqQTbSfHHk=.9983800c-03d8-4f32-a3bd-4a224182e9da@github.com>
 <S-Dug22fgH7CCXqJCmjgc3XLme2oM0Gj7IMh-E_ME7E=.6cd2215d-e71b-4a8a-8ffc-e3d3e47592d7@github.com>
 <vvi0stwxlOly34PZF8X7rsryHf3NsA4Yi7cfzmvzJmg=.6926162c-abb9-48c6-a5cf-f1167fb2f9b5@github.com>
Message-ID: <S-vU58rzDspjHMwK_WaxUJreZ7xQb9z_DsXOdpJD3KE=.da9eada7-ef2e-4e57-b729-30786aad045e@github.com>

On Tue, 26 Aug 2025 06:11:42 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> The error is strange
>> 
>> [0.002s][error][cds] Specified shared archive file not found (/jtreg_hotspot_tier2_work/JTwork/scratch/2/appcds-06h49m10s700.jsa)
>> 
>> This is not the default archive file it cannot find. This is the generated one, no?
>
> Does the test succeed if you generate all archive files?

If I regenerate the needed archive  (the custom-cl-zgc test needs classes_nocoops.jsa, I think because of ZGC)  by calling  `java -Xshare:dump -XX:-UseCompressedOops`  the test works nicely.
So adding  `vm.cds.default.archive.available`  is not really accurate because we miss the other archive.  It just works because in my test JVM we have BOTH the default archive classes.jsa and the classes_nocoops.jsa  removed.
Maybe we should have `vm.cds.nocoops.archive.available`  additionally to make clear what is really missing .
And probably better failure messages showing what's missing  would not hurt too, but I have a separate JBS issue for this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26820#discussion_r2301044351

From duke at openjdk.org  Tue Aug 26 14:44:10 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 26 Aug 2025 14:44:10 GMT
Subject: RFR: 8364816: GetLastError() in os_windows.cpp should not store value
 to errno
Message-ID: <-kp4UVOCqF0ZxITA-Rra0t7rWXXC0wLvAnO3OwchPkU=.7873481b-991a-429e-9b4c-9f2c68fec48f@github.com>

Hi, please consider the following changes:

In `os_windows.cpp` in a few places results returned by `GetLastError()` are stored to `errno`. However, `errno` has no relation to `GetLastError()`, and their ranges are not the same.

Results of `GetLastError()` should be stored into variables of type `DWORD`.

The removed section in `src/hotspot/share/cds/aotClassLocation.cpp` was relying on values returned by `GetLastError()` and stored to `errno` in `os::stat()`. Though the logic was correct, these values should not be stored to `errno`. The functionality is preserved by storing a **valid** value `ENOENT` to `errno` in `os::stat()`. 

Tested in tiers 1 - 3.

-------------

Commit messages:
 - 8364816: Removed erroneous assignment of errno.
 - Merge remote-tracking branch 'origin/master' into JDK-8364816-get-last-error
 - 8364816: GetLastError stores return value in a DWORD variable

Changes: https://git.openjdk.org/jdk/pull/26901/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26901&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364816
  Stats: 25 lines in 2 files changed: 2 ins; 6 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/26901.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26901/head:pull/26901

PR: https://git.openjdk.org/jdk/pull/26901

From kvn at openjdk.org  Tue Aug 26 16:17:34 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 26 Aug 2025 16:17:34 GMT
Subject: RFR: 8365673: Incorrect number of cores are reported on Ryzen CPU
In-Reply-To: <BjQ9knzbbefSqRxv6jHHcy1HzSflVSYQvlSQKlt3AF8=.ae3685bd-87c1-45b0-a1ad-6e630bfe9af9@github.com>
References: <BjQ9knzbbefSqRxv6jHHcy1HzSflVSYQvlSQKlt3AF8=.ae3685bd-87c1-45b0-a1ad-6e630bfe9af9@github.com>
Message-ID: <mMILfyxWme9Rvoo-_sHZwszI11Thu8At550rwHby12g=.d0bf8c04-55b8-4080-a562-30e98c5de78f@github.com>

On Mon, 18 Aug 2025 10:01:46 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> `VM.info` DCmd reports CPU information. I ran this on Ryzen 3 3300X, then I got following result:
> 
> 
> CPU: total 8 (initial active 8) (8 cores per cpu, 2 threads per core) family 23 model 113 stepping 0 microcode 0xffffffff, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4a, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, hv, rdtscp, rdpid, f16c
> CPU Model and flags from /proc/cpuinfo:
> model name : AMD Ryzen 3 3300X 4-Core Processor
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl tsc_reliable nonstop_tsc cpuid extd_apicid tsc_known_freq pni pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm cmp_legacy svm cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw topoext perfctr_core ssbd ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 clzero xsaveerptr arat npt nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold v_vmsave_vmload umip rdpid
> 
> 
> It reports "8 cores per cpu, 2 threads per core". However, according to [spec sheet](https://www.amd.com/en/support/downloads/drivers.html/processors/ryzen/ryzen-3000-series/amd-ryzen-3-3300x.html), 3300X has 4 cores 8 threads. (In addition, cpuinfo says "4-Core Processor")
> 
> According to [Programmer's Manual by AMD](https://docs.amd.com/v/u/en-US/40332-PUB_4.08), Bit 7:0 in `ECX` from `CPUID` leaf `80000008h` means number of threads, not cores. Thus we should divide it by threads per core.
> 
> After this change, we can see correct number of cores as following on 3300X:
> 
> CPU: total 8 (initial active 8) (4 cores per cpu, 2 threads per core) family 23 model 113 stepping 0 microcode 0xffffffff, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4a, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, clwb, hv, rdtscp, rdpid, f16c
> CPU Model and flags from /proc/cpuinfo:
> model name      : AMD Ryzen 3 3300X 4-Core Processor

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26819#pullrequestreview-3156397528

From jsikstro at openjdk.org  Tue Aug 26 16:44:34 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 26 Aug 2025 16:44:34 GMT
Subject: RFR: 8364816: GetLastError() in os_windows.cpp should not store
 value to errno
In-Reply-To: <-kp4UVOCqF0ZxITA-Rra0t7rWXXC0wLvAnO3OwchPkU=.7873481b-991a-429e-9b4c-9f2c68fec48f@github.com>
References: <-kp4UVOCqF0ZxITA-Rra0t7rWXXC0wLvAnO3OwchPkU=.7873481b-991a-429e-9b4c-9f2c68fec48f@github.com>
Message-ID: <tywYVeoBA3OiHe1ezNOaWpu49yXu0PhTgf3gia0Oi18=.b92829d5-2160-4cc8-bf55-0f0bf9c495a2@github.com>

On Fri, 22 Aug 2025 12:34:41 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> In `os_windows.cpp` in a few places results returned by `GetLastError()` are stored to `errno`. However, `errno` has no relation to `GetLastError()`, and their ranges are not the same.
> 
> Results of `GetLastError()` should be stored into variables of type `DWORD`.
> 
> The removed section in `src/hotspot/share/cds/aotClassLocation.cpp` was relying on values returned by `GetLastError()` and stored to `errno` in `os::stat()`. Though the logic was correct, these values should not be stored to `errno`. The functionality is preserved by storing a **valid** value `ENOENT` to `errno` in `os::stat()`. 
> 
> Tested in tiers 1 - 3.

I have one comment but otherwise this looks reasonable!

src/hotspot/os/windows/os_windows.cpp line 4700:

> 4698:   if (hFile == INVALID_HANDLE_VALUE) {
> 4699:     DWORD errcode = ::GetLastError();
> 4700:     log_debug(os)("get_path_to_target() failed to CreateFileW: GetLastError->%lu.", errcode);

The callers of `get_path_to_target` expects errno to be set, which it isn't anymore. We should probably set errno in this case and update the comments.

See: https://github.com/openjdk/jdk/blob/master/src/hotspot/os/windows/os_windows.cpp#L4804-L4813 and https://github.com/openjdk/jdk/blob/master/src/hotspot/os/windows/os_windows.cpp#L5018-L5027

-------------

PR Review: https://git.openjdk.org/jdk/pull/26901#pullrequestreview-3156432237
PR Review Comment: https://git.openjdk.org/jdk/pull/26901#discussion_r2301524241

From liach at openjdk.org  Tue Aug 26 20:56:42 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 26 Aug 2025 20:56:42 GMT
Subject: RFR: 8365885: Clean up constant pool reflection native code
In-Reply-To: <Sp5bJ-Ceo_WVhCq6Y9nGjJ_oTXdM-QinhEvf3Q8JUw4=.9ca004e5-d219-4e31-ab7b-e13b50b347e2@github.com>
References: <Sp5bJ-Ceo_WVhCq6Y9nGjJ_oTXdM-QinhEvf3Q8JUw4=.9ca004e5-d219-4e31-ab7b-e13b50b347e2@github.com>
Message-ID: <W_1faEJeCtOK7su99mesFXN78dR3MbqR5H1glQVL84M=.10197cf0-fa19-48ea-82ea-95acd7fabb13@github.com>

On Wed, 20 Aug 2025 21:29:29 GMT, Chen Liang <liach at openjdk.org> wrote:

> When I was trying to reuse this constant pool reflection for assembly phase indy argument validation, I noted the JNI code has a lot of confusing arguments. In particular, the JVM_ConstantPoolGetSize is wrong because of argument confusion. We should remove the unused arguments to reduce confusion.

Thanks for the reviews! This will help my use of ConstantPool reflection for leyden prototyping.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26870#issuecomment-3225698937

From liach at openjdk.org  Tue Aug 26 20:56:43 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 26 Aug 2025 20:56:43 GMT
Subject: Integrated: 8365885: Clean up constant pool reflection native code
In-Reply-To: <Sp5bJ-Ceo_WVhCq6Y9nGjJ_oTXdM-QinhEvf3Q8JUw4=.9ca004e5-d219-4e31-ab7b-e13b50b347e2@github.com>
References: <Sp5bJ-Ceo_WVhCq6Y9nGjJ_oTXdM-QinhEvf3Q8JUw4=.9ca004e5-d219-4e31-ab7b-e13b50b347e2@github.com>
Message-ID: <iggbKdntBAm3-chs9gp-a_cwjuLsRqmQ-acpxVEB1-w=.5b1daf3e-4af1-4e3c-9af5-d9549bac108c@github.com>

On Wed, 20 Aug 2025 21:29:29 GMT, Chen Liang <liach at openjdk.org> wrote:

> When I was trying to reuse this constant pool reflection for assembly phase indy argument validation, I noted the JNI code has a lot of confusing arguments. In particular, the JVM_ConstantPoolGetSize is wrong because of argument confusion. We should remove the unused arguments to reduce confusion.

This pull request has now been integrated.

Changeset: b426151a
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b426151a33158637eb04c07a5133d95cbb8bf04c
Stats:     142 lines in 6 files changed: 18 ins; 3 del; 121 mod

8365885: Clean up constant pool reflection native code

Reviewed-by: iklam, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/26870

From ysuenaga at openjdk.org  Wed Aug 27 00:00:48 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Wed, 27 Aug 2025 00:00:48 GMT
Subject: Integrated: 8365673: Incorrect number of cores are reported on Ryzen
 CPU
In-Reply-To: <BjQ9knzbbefSqRxv6jHHcy1HzSflVSYQvlSQKlt3AF8=.ae3685bd-87c1-45b0-a1ad-6e630bfe9af9@github.com>
References: <BjQ9knzbbefSqRxv6jHHcy1HzSflVSYQvlSQKlt3AF8=.ae3685bd-87c1-45b0-a1ad-6e630bfe9af9@github.com>
Message-ID: <kVd0ZBNexFE8VqcybbsYfyKmouGjzpZdbTT9qD_o4I8=.47e04834-6f4e-441a-9507-048d0fad4f63@github.com>

On Mon, 18 Aug 2025 10:01:46 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> `VM.info` DCmd reports CPU information. I ran this on Ryzen 3 3300X, then I got following result:
> 
> 
> CPU: total 8 (initial active 8) (8 cores per cpu, 2 threads per core) family 23 model 113 stepping 0 microcode 0xffffffff, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4a, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, hv, rdtscp, rdpid, f16c
> CPU Model and flags from /proc/cpuinfo:
> model name : AMD Ryzen 3 3300X 4-Core Processor
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl tsc_reliable nonstop_tsc cpuid extd_apicid tsc_known_freq pni pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm cmp_legacy svm cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw topoext perfctr_core ssbd ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 clzero xsaveerptr arat npt nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold v_vmsave_vmload umip rdpid
> 
> 
> It reports "8 cores per cpu, 2 threads per core". However, according to [spec sheet](https://www.amd.com/en/support/downloads/drivers.html/processors/ryzen/ryzen-3000-series/amd-ryzen-3-3300x.html), 3300X has 4 cores 8 threads. (In addition, cpuinfo says "4-Core Processor")
> 
> According to [Programmer's Manual by AMD](https://docs.amd.com/v/u/en-US/40332-PUB_4.08), Bit 7:0 in `ECX` from `CPUID` leaf `80000008h` means number of threads, not cores. Thus we should divide it by threads per core.
> 
> After this change, we can see correct number of cores as following on 3300X:
> 
> CPU: total 8 (initial active 8) (4 cores per cpu, 2 threads per core) family 23 model 113 stepping 0 microcode 0xffffffff, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4a, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, clwb, hv, rdtscp, rdpid, f16c
> CPU Model and flags from /proc/cpuinfo:
> model name      : AMD Ryzen 3 3300X 4-Core Processor

This pull request has now been integrated.

Changeset: 1aca920f
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1aca920f5987399dbd114fd5e62b26b363363e64
Stats:     6 lines in 2 files changed: 3 ins; 0 del; 3 mod

8365673: Incorrect number of cores are reported on Ryzen CPU

Reviewed-by: dholmes, kvn

-------------

PR: https://git.openjdk.org/jdk/pull/26819

From ysuenaga at openjdk.org  Wed Aug 27 00:00:48 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Wed, 27 Aug 2025 00:00:48 GMT
Subject: RFR: 8365673: Incorrect number of cores are reported on Ryzen CPU
In-Reply-To: <BjQ9knzbbefSqRxv6jHHcy1HzSflVSYQvlSQKlt3AF8=.ae3685bd-87c1-45b0-a1ad-6e630bfe9af9@github.com>
References: <BjQ9knzbbefSqRxv6jHHcy1HzSflVSYQvlSQKlt3AF8=.ae3685bd-87c1-45b0-a1ad-6e630bfe9af9@github.com>
Message-ID: <WkRnhIFgMv0xyp6p7Nau5pArWdPv6W4wKvEv5LOwZIo=.739cd08c-2f8d-4df1-96de-f216854c9613@github.com>

On Mon, 18 Aug 2025 10:01:46 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> `VM.info` DCmd reports CPU information. I ran this on Ryzen 3 3300X, then I got following result:
> 
> 
> CPU: total 8 (initial active 8) (8 cores per cpu, 2 threads per core) family 23 model 113 stepping 0 microcode 0xffffffff, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4a, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, hv, rdtscp, rdpid, f16c
> CPU Model and flags from /proc/cpuinfo:
> model name : AMD Ryzen 3 3300X 4-Core Processor
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl tsc_reliable nonstop_tsc cpuid extd_apicid tsc_known_freq pni pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm cmp_legacy svm cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw topoext perfctr_core ssbd ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 clzero xsaveerptr arat npt nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold v_vmsave_vmload umip rdpid
> 
> 
> It reports "8 cores per cpu, 2 threads per core". However, according to [spec sheet](https://www.amd.com/en/support/downloads/drivers.html/processors/ryzen/ryzen-3000-series/amd-ryzen-3-3300x.html), 3300X has 4 cores 8 threads. (In addition, cpuinfo says "4-Core Processor")
> 
> According to [Programmer's Manual by AMD](https://docs.amd.com/v/u/en-US/40332-PUB_4.08), Bit 7:0 in `ECX` from `CPUID` leaf `80000008h` means number of threads, not cores. Thus we should divide it by threads per core.
> 
> After this change, we can see correct number of cores as following on 3300X:
> 
> CPU: total 8 (initial active 8) (4 cores per cpu, 2 threads per core) family 23 model 113 stepping 0 microcode 0xffffffff, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4a, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, clwb, hv, rdtscp, rdpid, f16c
> CPU Model and flags from /proc/cpuinfo:
> model name      : AMD Ryzen 3 3300X 4-Core Processor

Thank you both!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26819#issuecomment-3226151908

From dholmes at openjdk.org  Wed Aug 27 06:55:43 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 27 Aug 2025 06:55:43 GMT
Subject: RFR: 8353468: [ubsan] arguments.cpp:2422:23: runtime error:
 2.14748e+11 is outside the range of representable values of type 'int'
In-Reply-To: <k9IUTdCiIKbbfQrHRBzeoLtk-IjvddnRfqeUl9fbTBs=.f69be724-67a1-4e31-9aea-025a2c58620d@github.com>
References: <plQ5n7EjsekIjeY431_mBeo4rfcH39SVdPWogF2rT44=.20180c89-665e-4054-8625-1b04f8306b3b@github.com>
 <k9IUTdCiIKbbfQrHRBzeoLtk-IjvddnRfqeUl9fbTBs=.f69be724-67a1-4e31-9aea-025a2c58620d@github.com>
Message-ID: <9xuM_v7E5eDNMz12W0Rvy1am7kQLOUT4z0IZsTIrOWo=.aa348314-90bd-493d-9d35-bbb09cc05ad2@github.com>

On Thu, 21 Aug 2025 07:46:29 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> In converting values of `-XMinf` and `-XMaxf` options to `int`, overflow was not checked. 
>> The values are checked against INT_MAX and clamped.
>> 
>> Tests: tiers 1-5.
>
> The failing TestHeapFreeRatio.java test tests with an extreme positive value (2147483647), but it doesn't test with an extreme negative value:
> 
> 
>   public static void main(String args[]) throws Exception {
>     testMinMaxFreeRatio( "0.1", "0.5", Validation.VALID);
>     testMinMaxFreeRatio(  ".1",  ".5", Validation.VALID);
>     testMinMaxFreeRatio( "0.5", "0.5", Validation.VALID);
> 
>     testMinMaxFreeRatio("=0.1", "0.5", Validation.MIN_INVALID);
>     testMinMaxFreeRatio("0.1f", "0.5", Validation.MIN_INVALID);
>     testMinMaxFreeRatio(
>                      "INVALID", "0.5", Validation.MIN_INVALID);
> 
>     testMinMaxFreeRatio( "0.1", "0.5f", Validation.MAX_INVALID);
>     testMinMaxFreeRatio( "0.1", "=0.5", Validation.MAX_INVALID);
>     testMinMaxFreeRatio(
>                      "0.1",  "INVALID", Validation.MAX_INVALID);
> 
>     testMinMaxFreeRatio("-0.1", "0.5", Validation.OUT_OF_RANGE);
>     testMinMaxFreeRatio( "1.1", "0.5", Validation.OUT_OF_RANGE);
>     testMinMaxFreeRatio(
>                   "2147483647", "0.5", Validation.OUT_OF_RANGE);
>     testMinMaxFreeRatio( "0.1", "-0.5", Validation.OUT_OF_RANGE);
>     testMinMaxFreeRatio( "0.1",  "1.5", Validation.OUT_OF_RANGE);
>     testMinMaxFreeRatio(
>                    "0.1", "2147483647", Validation.OUT_OF_RANGE);
> 
>     testMinMaxFreeRatio( "0.5",  "0.1", Validation.COMBINATION_INVALID);
>     testMinMaxFreeRatio(  ".5",  ".10", Validation.COMBINATION_INVALID);
>     testMinMaxFreeRatio("0.12","0.100", Validation.COMBINATION_INVALID);
>   }
> 
> 
> Would ubsan hit a similar value if it did and would you have to guard against INT_MIN as well?

@stefank there is a bit of a history with the `-Xminf/-Xmaxf` flags and I agree there is more to clean up here ... maybe even get rid of these flags ... they are not even documented in the manpage when they should be!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26859#issuecomment-3226988421

From duke at openjdk.org  Wed Aug 27 07:37:28 2025
From: duke at openjdk.org (Anton Artemov)
Date: Wed, 27 Aug 2025 07:37:28 GMT
Subject: RFR: 8364816: GetLastError() in os_windows.cpp should not store
 value to errno [v2]
In-Reply-To: <-kp4UVOCqF0ZxITA-Rra0t7rWXXC0wLvAnO3OwchPkU=.7873481b-991a-429e-9b4c-9f2c68fec48f@github.com>
References: <-kp4UVOCqF0ZxITA-Rra0t7rWXXC0wLvAnO3OwchPkU=.7873481b-991a-429e-9b4c-9f2c68fec48f@github.com>
Message-ID: <RdWqcqPLHy6sZgvsrXB8h3YAAMM5ggqSue2ux2UAYQM=.67b14953-15e4-47d7-bb77-73d55949ace0@github.com>

> Hi, please consider the following changes:
> 
> In `os_windows.cpp` in a few places results returned by `GetLastError()` are stored to `errno`. However, `errno` has no relation to `GetLastError()`, and their ranges are not the same.
> 
> Results of `GetLastError()` should be stored into variables of type `DWORD`.
> 
> The removed section in `src/hotspot/share/cds/aotClassLocation.cpp` was relying on values returned by `GetLastError()` and stored to `errno` in `os::stat()`. Though the logic was correct, these values should not be stored to `errno`. The functionality is preserved by storing a **valid** value `ENOENT` to `errno` in `os::stat()`. 
> 
> Tested in tiers 1 - 3.

Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:

  8364816: Fixed misleading comments.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26901/files
  - new: https://git.openjdk.org/jdk/pull/26901/files/a2c42247..45f85e10

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26901&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26901&range=00-01

  Stats: 6 lines in 1 file changed: 0 ins; 4 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/26901.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26901/head:pull/26901

PR: https://git.openjdk.org/jdk/pull/26901

From duke at openjdk.org  Wed Aug 27 07:37:28 2025
From: duke at openjdk.org (Anton Artemov)
Date: Wed, 27 Aug 2025 07:37:28 GMT
Subject: RFR: 8364816: GetLastError() in os_windows.cpp should not store
 value to errno [v2]
In-Reply-To: <tywYVeoBA3OiHe1ezNOaWpu49yXu0PhTgf3gia0Oi18=.b92829d5-2160-4cc8-bf55-0f0bf9c495a2@github.com>
References: <-kp4UVOCqF0ZxITA-Rra0t7rWXXC0wLvAnO3OwchPkU=.7873481b-991a-429e-9b4c-9f2c68fec48f@github.com>
 <tywYVeoBA3OiHe1ezNOaWpu49yXu0PhTgf3gia0Oi18=.b92829d5-2160-4cc8-bf55-0f0bf9c495a2@github.com>
Message-ID: <tUEn2Xw2udFNWkyN1dzBGyjIom5f_ZcL8I9fXYFeFnA=.c3baec23-dfae-4d16-80fc-9ac0f4ab59ec@github.com>

On Tue, 26 Aug 2025 16:25:58 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8364816: Fixed misleading comments.
>
> src/hotspot/os/windows/os_windows.cpp line 4700:
> 
>> 4698:   if (hFile == INVALID_HANDLE_VALUE) {
>> 4699:     DWORD errcode = ::GetLastError();
>> 4700:     log_debug(os)("get_path_to_target() failed to CreateFileW: GetLastError->%lu.", errcode);
> 
> The callers of `get_path_to_target` expects errno to be set, which it isn't anymore. We should probably set errno in this case and update the comments.
> 
> See: https://github.com/openjdk/jdk/blob/master/src/hotspot/os/windows/os_windows.cpp#L4804-L4813 and https://github.com/openjdk/jdk/blob/master/src/hotspot/os/windows/os_windows.cpp#L5018-L5027

Thanks for spotting. Actually, this comment, as well as the code around it, is mine as well. When writing it, I was storing results of `GetLastError()` in `errno`, which as we know is wrong and is addressed in this PR. 

The callers of `get_path_to_target()` do not expect any value in `errno` actually. The only thing they do when failing (this is where the `errno` value would be potentially useful) is that freeing some char array and returning -1. The error, which caused it, has been already reported. The comment is misleading. I fixed it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26901#discussion_r2303129187

From jsikstro at openjdk.org  Wed Aug 27 08:45:43 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 27 Aug 2025 08:45:43 GMT
Subject: RFR: 8364816: GetLastError() in os_windows.cpp should not store
 value to errno [v2]
In-Reply-To: <tUEn2Xw2udFNWkyN1dzBGyjIom5f_ZcL8I9fXYFeFnA=.c3baec23-dfae-4d16-80fc-9ac0f4ab59ec@github.com>
References: <-kp4UVOCqF0ZxITA-Rra0t7rWXXC0wLvAnO3OwchPkU=.7873481b-991a-429e-9b4c-9f2c68fec48f@github.com>
 <tywYVeoBA3OiHe1ezNOaWpu49yXu0PhTgf3gia0Oi18=.b92829d5-2160-4cc8-bf55-0f0bf9c495a2@github.com>
 <tUEn2Xw2udFNWkyN1dzBGyjIom5f_ZcL8I9fXYFeFnA=.c3baec23-dfae-4d16-80fc-9ac0f4ab59ec@github.com>
Message-ID: <PqFr-tKnTkDFeABS-yq96BzIhspxCkUNnciu0QDfZJ8=.90b137b7-8bee-43e8-92e3-e4fe745517ef@github.com>

On Wed, 27 Aug 2025 07:33:47 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> src/hotspot/os/windows/os_windows.cpp line 4700:
>> 
>>> 4698:   if (hFile == INVALID_HANDLE_VALUE) {
>>> 4699:     DWORD errcode = ::GetLastError();
>>> 4700:     log_debug(os)("get_path_to_target() failed to CreateFileW: GetLastError->%lu.", errcode);
>> 
>> The callers of `get_path_to_target` expects errno to be set, which it isn't anymore. We should probably set errno in this case and update the comments.
>> 
>> See: https://github.com/openjdk/jdk/blob/master/src/hotspot/os/windows/os_windows.cpp#L4804-L4813 and https://github.com/openjdk/jdk/blob/master/src/hotspot/os/windows/os_windows.cpp#L5018-L5027
>
> Thanks for spotting. Actually, this comment, as well as the code around it, is mine as well. When writing it, I was storing results of `GetLastError()` in `errno`, which as we know is wrong and is addressed in this PR. 
> 
> The callers of `get_path_to_target()` do not expect any value in `errno` actually. The only thing they do when failing (this is where the `errno` value would be potentially useful) is that freeing some char array and returning -1. The error, which caused it, has been already reported. The comment is misleading. I fixed it.

I think we still need to set errno in the failure path in https://github.com/toxaart/jdk/blob/JDK-8364816-get-last-error/src/hotspot/os/windows/os_windows.cpp#L4804-L4811.

Right next to the Windows specific code that you removed in this PR, we are checking the errno result, which is unset if we exit from the path calling `get_path_to_target()`. See https://github.com/toxaart/jdk/blob/JDK-8364816-get-last-error/src/hotspot/share/cds/aotClassLocation.cpp#L234-L246.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26901#discussion_r2303285732

From azafari at openjdk.org  Wed Aug 27 09:54:43 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Wed, 27 Aug 2025 09:54:43 GMT
Subject: RFR: 8353468: [ubsan] arguments.cpp:2422:23: runtime error:
 2.14748e+11 is outside the range of representable values of type 'int' [v3]
In-Reply-To: <plQ5n7EjsekIjeY431_mBeo4rfcH39SVdPWogF2rT44=.20180c89-665e-4054-8625-1b04f8306b3b@github.com>
References: <plQ5n7EjsekIjeY431_mBeo4rfcH39SVdPWogF2rT44=.20180c89-665e-4054-8625-1b04f8306b3b@github.com>
Message-ID: <x2XW0ywYSy-9Tqh-Mzrhd3X1o8MTo5rADg48p92rpDo=.a3e4e6cf-ce98-48c7-b90d-cfa22b130e54@github.com>

> In converting values of `-XMinf` and `-XMaxf` options to `int`, overflow was not checked. 
> The values are checked against INT_MAX and clamped.
> 
> Tests: tiers 1-5.

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  improved invalid detection and error messages

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26859/files
  - new: https://git.openjdk.org/jdk/pull/26859/files/74144083..87e0b8d9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26859&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26859&range=01-02

  Stats: 20 lines in 2 files changed: 9 ins; 4 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/26859.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26859/head:pull/26859

PR: https://git.openjdk.org/jdk/pull/26859

From duke at openjdk.org  Wed Aug 27 10:51:57 2025
From: duke at openjdk.org (Anton Artemov)
Date: Wed, 27 Aug 2025 10:51:57 GMT
Subject: RFR: 8364816: GetLastError() in os_windows.cpp should not store
 value to errno [v3]
In-Reply-To: <-kp4UVOCqF0ZxITA-Rra0t7rWXXC0wLvAnO3OwchPkU=.7873481b-991a-429e-9b4c-9f2c68fec48f@github.com>
References: <-kp4UVOCqF0ZxITA-Rra0t7rWXXC0wLvAnO3OwchPkU=.7873481b-991a-429e-9b4c-9f2c68fec48f@github.com>
Message-ID: <jykFYKO4kKxEzIiad0A08Jl6scCIUEsYDyk_Qe8pqk4=.77cf23fa-7b19-4129-9400-0d26b78e43a3@github.com>

> Hi, please consider the following changes:
> 
> In `os_windows.cpp` in a few places results returned by `GetLastError()` are stored to `errno`. However, `errno` has no relation to `GetLastError()`, and their ranges are not the same.
> 
> Results of `GetLastError()` should be stored into variables of type `DWORD`.
> 
> The removed section in `src/hotspot/share/cds/aotClassLocation.cpp` was relying on values returned by `GetLastError()` and stored to `errno` in `os::stat()`. Though the logic was correct, these values should not be stored to `errno`. The functionality is preserved by storing a **valid** value `ENOENT` to `errno` in `os::stat()`. 
> 
> Tested in tiers 1 - 3.

Anton Artemov has updated the pull request incrementally with two additional commits since the last revision:

 - 8364816: Fixed whitespace error.
 - 8364816: Added missed assignment to errno.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26901/files
  - new: https://git.openjdk.org/jdk/pull/26901/files/45f85e10..322bed86

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26901&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26901&range=01-02

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26901.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26901/head:pull/26901

PR: https://git.openjdk.org/jdk/pull/26901

From duke at openjdk.org  Wed Aug 27 10:51:57 2025
From: duke at openjdk.org (Anton Artemov)
Date: Wed, 27 Aug 2025 10:51:57 GMT
Subject: RFR: 8364816: GetLastError() in os_windows.cpp should not store
 value to errno [v3]
In-Reply-To: <PqFr-tKnTkDFeABS-yq96BzIhspxCkUNnciu0QDfZJ8=.90b137b7-8bee-43e8-92e3-e4fe745517ef@github.com>
References: <-kp4UVOCqF0ZxITA-Rra0t7rWXXC0wLvAnO3OwchPkU=.7873481b-991a-429e-9b4c-9f2c68fec48f@github.com>
 <tywYVeoBA3OiHe1ezNOaWpu49yXu0PhTgf3gia0Oi18=.b92829d5-2160-4cc8-bf55-0f0bf9c495a2@github.com>
 <tUEn2Xw2udFNWkyN1dzBGyjIom5f_ZcL8I9fXYFeFnA=.c3baec23-dfae-4d16-80fc-9ac0f4ab59ec@github.com>
 <PqFr-tKnTkDFeABS-yq96BzIhspxCkUNnciu0QDfZJ8=.90b137b7-8bee-43e8-92e3-e4fe745517ef@github.com>
Message-ID: <iE1SI_tRssHeTO7UACV70XAVFXrMNNK7dbp0GrA9JtM=.9ce7f010-51ca-467e-ba9c-6f64f23074ca@github.com>

On Wed, 27 Aug 2025 08:42:50 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Thanks for spotting. Actually, this comment, as well as the code around it, is mine as well. When writing it, I was storing results of `GetLastError()` in `errno`, which as we know is wrong and is addressed in this PR. 
>> 
>> The callers of `get_path_to_target()` do not expect any value in `errno` actually. The only thing they do when failing (this is where the `errno` value would be potentially useful) is that freeing some char array and returning -1. The error, which caused it, has been already reported. The comment is misleading. I fixed it.
>
> I think we still need to set errno in the failure path in https://github.com/toxaart/jdk/blob/JDK-8364816-get-last-error/src/hotspot/os/windows/os_windows.cpp#L4804-L4811.
> 
> Right next to the Windows specific code that you removed in this PR, we are checking the errno result, which is unset if we exit from the path calling `get_path_to_target()`. See https://github.com/toxaart/jdk/blob/JDK-8364816-get-last-error/src/hotspot/share/cds/aotClassLocation.cpp#L234-L246.

This is an extremely rare case when someone wants to use symbolic links and cds archives. I have addressed.

Tested in tiers 1 - 3, all green.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26901#discussion_r2303558867

From azafari at openjdk.org  Wed Aug 27 11:15:41 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Wed, 27 Aug 2025 11:15:41 GMT
Subject: RFR: 8353468: [ubsan] arguments.cpp:2422:23: runtime error:
 2.14748e+11 is outside the range of representable values of type 'int'
In-Reply-To: <9xuM_v7E5eDNMz12W0Rvy1am7kQLOUT4z0IZsTIrOWo=.aa348314-90bd-493d-9d35-bbb09cc05ad2@github.com>
References: <plQ5n7EjsekIjeY431_mBeo4rfcH39SVdPWogF2rT44=.20180c89-665e-4054-8625-1b04f8306b3b@github.com>
 <k9IUTdCiIKbbfQrHRBzeoLtk-IjvddnRfqeUl9fbTBs=.f69be724-67a1-4e31-9aea-025a2c58620d@github.com>
 <9xuM_v7E5eDNMz12W0Rvy1am7kQLOUT4z0IZsTIrOWo=.aa348314-90bd-493d-9d35-bbb09cc05ad2@github.com>
Message-ID: <XdkmibOprQ5Xq8CwanQIHB2gmx46_B2OaIhYD3lsN1c=.bfa1c256-c5b6-4b45-9584-3385cf00b357@github.com>

On Wed, 27 Aug 2025 06:53:12 GMT, David Holmes <dholmes at openjdk.org> wrote:

> maybe even get rid of these flags

Let me know if these flags are to be removed. These flags are described or at least mentioned in Oracle guide to GC tuning.  or any backward compatibility?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26859#issuecomment-3227780926

From jsikstro at openjdk.org  Wed Aug 27 12:11:45 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 27 Aug 2025 12:11:45 GMT
Subject: RFR: 8364816: GetLastError() in os_windows.cpp should not store
 value to errno [v3]
In-Reply-To: <jykFYKO4kKxEzIiad0A08Jl6scCIUEsYDyk_Qe8pqk4=.77cf23fa-7b19-4129-9400-0d26b78e43a3@github.com>
References: <-kp4UVOCqF0ZxITA-Rra0t7rWXXC0wLvAnO3OwchPkU=.7873481b-991a-429e-9b4c-9f2c68fec48f@github.com>
 <jykFYKO4kKxEzIiad0A08Jl6scCIUEsYDyk_Qe8pqk4=.77cf23fa-7b19-4129-9400-0d26b78e43a3@github.com>
Message-ID: <X8jCqlZYNqbEvskUkQI3UtezFohZfkOILKsau38mIIY=.c099561f-06b8-480f-8d96-4885016c2ea3@github.com>

On Wed, 27 Aug 2025 10:51:57 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> In `os_windows.cpp` in a few places results returned by `GetLastError()` are stored to `errno`. However, `errno` has no relation to `GetLastError()`, and their ranges are not the same.
>> 
>> Results of `GetLastError()` should be stored into variables of type `DWORD`.
>> 
>> The removed section in `src/hotspot/share/cds/aotClassLocation.cpp` was relying on values returned by `GetLastError()` and stored to `errno` in `os::stat()`. Though the logic was correct, these values should not be stored to `errno`. The functionality is preserved by storing a **valid** value `ENOENT` to `errno` in `os::stat()`. 
>> 
>> Tested in tiers 1 - 3.
>
> Anton Artemov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8364816: Fixed whitespace error.
>  - 8364816: Added missed assignment to errno.

src/hotspot/os/windows/os_windows.cpp line 4821:

> 4819:     errno = ENOENT;
> 4820:     DWORD errcode = ::GetLastError();
> 4821:     log_debug(os)("os::stat() failed to GetFileAttributesExW: GetLastError->%lu.", errcode);

I'm not sure this is the right solution. Now that we don't store the value of `GetLastError()` in errno and instead set errno to `ENOENT`, we don't detect if we get some other error than no entry. I think we should only set errno to `ENOENT` if `GetLastError()` returns either `ERROR_FILE_NOT_FOUND` or `ERROR_PATH_NOT_FOUND`.

If `GetLastError()` returns something else, we should not set errno to `ENOENT`, but some other value. It's hard since we can't do a 1:1 mapping between `GetLastError()` and errno error values. We could use `EOTHER`, as defined in https://learn.microsoft.com/en-us/cpp/c-runtime-library/errno-constants?view=msvc-170. 

I really think that `os::stat` should move away from using errno in this case. Also, it isn't really communicated clearly that that `os::stat()` is setting errno. I think this is best addressed in a follow-up, but it makes it harder to reason clearly about this patch.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26901#discussion_r2303734030

From phubner at openjdk.org  Wed Aug 27 13:04:46 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Wed, 27 Aug 2025 13:04:46 GMT
Subject: RFR: 8342730: Get rid of SummaryDiff in VMATree
In-Reply-To: <JShctGmb3UHnG21I3UAOCLu8b9KoGs8u9yO5iw_sUwc=.e0a33104-011f-47b0-bac4-59d18853c4c8@github.com>
References: <JShctGmb3UHnG21I3UAOCLu8b9KoGs8u9yO5iw_sUwc=.e0a33104-011f-47b0-bac4-59d18853c4c8@github.com>
Message-ID: <PzpjRcfIp2QswCXuxRlfuDWS1knmb5S9crC2E-NJ6I4=.fa605b23-0b83-4c47-a9a3-2dc9140ff276@github.com>

On Wed, 13 Aug 2025 13:33:36 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> `SummaryDiff` result of any `register_mapping()` call, is passed into the function rather than returned. This enables avoiding copying the structure to/from the stack.
> 
> Tests:
> local linux-x64-debug: NMT gtests and JTREGs passed.

Thanks for the work, Afshin. I just have one small question and a few nitpicks, but other than that it looks in good shape to be merged.

src/hotspot/share/nmt/vmatree.cpp line 248:

> 246:                                                const RegionData& metadata, VMATree::SummaryDiff& diff, bool use_tag_inplace) {
> 247: 
> 248:   diff.clear();

I'm not sure I follow why this is introduced. Is there a situation where we/it makes sense to re-use `SumaryDiff`s?

test/hotspot/gtest/nmt/test_regions_tree.cpp line 102:

> 100:   NativeCallStack ncs;
> 101:   VMATree::RegionData rd = rt.make_region_data(ncs, mtTest);
> 102:   VMATree::SummaryDiff diff;

Nit: it's unused in the actual test/assertions right? Would call it `not_used` to be consistent with above test code then.

test/hotspot/gtest/nmt/test_regions_tree.cpp line 121:

> 119:   NativeCallStack ncs;
> 120:   VMATree::RegionData rd = rt.make_region_data(ncs, mtTest);
> 121:   VMATree::SummaryDiff diff;

Same naming nit here.

test/hotspot/gtest/nmt/test_regions_tree.cpp line 137:

> 135:   NativeCallStack ncs;
> 136:   VMATree::RegionData rd = rt.make_region_data(ncs, mtTest);
> 137:   VMATree::SummaryDiff diff;

Same naming nit here.

test/hotspot/gtest/nmt/test_vmatree.cpp line 1112:

> 1110:   {// Check committing into a reserved region inherits the call stacks
> 1111:     Tree tree;
> 1112:     VMATree::SummaryDiff diff;

Same nitpick here as in the other places in this file, I think it's more clear if we used `not_used` for cases where we discard the result. I'll stop pointing out every place this happens, consider this comment for the whole file.

-------------

PR Review: https://git.openjdk.org/jdk/pull/26761#pullrequestreview-3159649505
PR Review Comment: https://git.openjdk.org/jdk/pull/26761#discussion_r2303829869
PR Review Comment: https://git.openjdk.org/jdk/pull/26761#discussion_r2303845475
PR Review Comment: https://git.openjdk.org/jdk/pull/26761#discussion_r2303847970
PR Review Comment: https://git.openjdk.org/jdk/pull/26761#discussion_r2303848336
PR Review Comment: https://git.openjdk.org/jdk/pull/26761#discussion_r2303861190

From duke at openjdk.org  Wed Aug 27 13:09:39 2025
From: duke at openjdk.org (Anton Artemov)
Date: Wed, 27 Aug 2025 13:09:39 GMT
Subject: RFR: 8364816: GetLastError() in os_windows.cpp should not store
 value to errno [v4]
In-Reply-To: <-kp4UVOCqF0ZxITA-Rra0t7rWXXC0wLvAnO3OwchPkU=.7873481b-991a-429e-9b4c-9f2c68fec48f@github.com>
References: <-kp4UVOCqF0ZxITA-Rra0t7rWXXC0wLvAnO3OwchPkU=.7873481b-991a-429e-9b4c-9f2c68fec48f@github.com>
Message-ID: <CuRfAQfuS8YBTXFtdsYeGdya2B2Kqmz3BfigGhCoBbQ=.42c2276a-45d3-49b0-a151-5e764c4f69e7@github.com>

> Hi, please consider the following changes:
> 
> In `os_windows.cpp` in a few places results returned by `GetLastError()` are stored to `errno`. However, `errno` has no relation to `GetLastError()`, and their ranges are not the same.
> 
> Results of `GetLastError()` should be stored into variables of type `DWORD`.
> 
> The removed section in `src/hotspot/share/cds/aotClassLocation.cpp` was relying on values returned by `GetLastError()` and stored to `errno` in `os::stat()`. Though the logic was correct, these values should not be stored to `errno`. The functionality is preserved by storing a **valid** value `ENOENT` to `errno` in `os::stat()`. 
> 
> Tested in tiers 1 - 3.

Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:

  8364816: Modified case when ENOENT value is stored to errno.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26901/files
  - new: https://git.openjdk.org/jdk/pull/26901/files/322bed86..d989cbb3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26901&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26901&range=02-03

  Stats: 4 lines in 1 file changed: 3 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26901.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26901/head:pull/26901

PR: https://git.openjdk.org/jdk/pull/26901

From duke at openjdk.org  Wed Aug 27 13:09:40 2025
From: duke at openjdk.org (Anton Artemov)
Date: Wed, 27 Aug 2025 13:09:40 GMT
Subject: RFR: 8364816: GetLastError() in os_windows.cpp should not store
 value to errno [v3]
In-Reply-To: <X8jCqlZYNqbEvskUkQI3UtezFohZfkOILKsau38mIIY=.c099561f-06b8-480f-8d96-4885016c2ea3@github.com>
References: <-kp4UVOCqF0ZxITA-Rra0t7rWXXC0wLvAnO3OwchPkU=.7873481b-991a-429e-9b4c-9f2c68fec48f@github.com>
 <jykFYKO4kKxEzIiad0A08Jl6scCIUEsYDyk_Qe8pqk4=.77cf23fa-7b19-4129-9400-0d26b78e43a3@github.com>
 <X8jCqlZYNqbEvskUkQI3UtezFohZfkOILKsau38mIIY=.c099561f-06b8-480f-8d96-4885016c2ea3@github.com>
Message-ID: <70OE7xTg0vp47frIvwb8b7ZPFfFSIMWiuHiWiMrbkkU=.6cbb25c6-2686-4c5a-bbba-5e617358dc29@github.com>

On Wed, 27 Aug 2025 12:08:36 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> I'm not sure this is the right solution. Now that we don't store the value of `GetLastError()` in errno and instead set errno to `ENOENT`, we don't detect if we get some other error than no entry. I think we should only set errno to `ENOENT` if `GetLastError()` returns either `ERROR_FILE_NOT_FOUND` or `ERROR_PATH_NOT_FOUND`.

I added this `if` case, but generally I do not think it is needed at all. 

We do not need to detect multiple flavours of failure. Simply because we are interested only in the end result, which is "does the file exist or not". If it does not, it does not matter why.  Introducing generic value` EOTHER `which means anything and nothing in the same time will serve no purpose. 


> I really think that `os::stat` should move away from using errno in this case. Also, it isn't really communicated clearly that that `os::stat()` is setting errno. I think this is best addressed in a follow-up, but it makes it harder to reason clearly about this patch.

Maybe, but it is not in the scope of this PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26901#discussion_r2303875760

From jsikstro at openjdk.org  Wed Aug 27 14:18:45 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 27 Aug 2025 14:18:45 GMT
Subject: RFR: 8364816: GetLastError() in os_windows.cpp should not store
 value to errno [v3]
In-Reply-To: <70OE7xTg0vp47frIvwb8b7ZPFfFSIMWiuHiWiMrbkkU=.6cbb25c6-2686-4c5a-bbba-5e617358dc29@github.com>
References: <-kp4UVOCqF0ZxITA-Rra0t7rWXXC0wLvAnO3OwchPkU=.7873481b-991a-429e-9b4c-9f2c68fec48f@github.com>
 <jykFYKO4kKxEzIiad0A08Jl6scCIUEsYDyk_Qe8pqk4=.77cf23fa-7b19-4129-9400-0d26b78e43a3@github.com>
 <X8jCqlZYNqbEvskUkQI3UtezFohZfkOILKsau38mIIY=.c099561f-06b8-480f-8d96-4885016c2ea3@github.com>
 <70OE7xTg0vp47frIvwb8b7ZPFfFSIMWiuHiWiMrbkkU=.6cbb25c6-2686-4c5a-bbba-5e617358dc29@github.com>
Message-ID: <E0WCJygALj0AeTclpSF_Wx1-a4W_Q6dNbUNcnrNBA0E=.e569d626-9e90-4307-9d90-142e13b265c8@github.com>

On Wed, 27 Aug 2025 13:06:03 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> src/hotspot/os/windows/os_windows.cpp line 4821:
>> 
>>> 4819:     errno = ENOENT;
>>> 4820:     DWORD errcode = ::GetLastError();
>>> 4821:     log_debug(os)("os::stat() failed to GetFileAttributesExW: GetLastError->%lu.", errcode);
>> 
>> I'm not sure this is the right solution. Now that we don't store the value of `GetLastError()` in errno and instead set errno to `ENOENT`, we don't detect if we get some other error than no entry. I think we should only set errno to `ENOENT` if `GetLastError()` returns either `ERROR_FILE_NOT_FOUND` or `ERROR_PATH_NOT_FOUND`.
>> 
>> If `GetLastError()` returns something else, we should not set errno to `ENOENT`, but some other value. It's hard since we can't do a 1:1 mapping between `GetLastError()` and errno error values. We could use `EOTHER`, as defined in https://learn.microsoft.com/en-us/cpp/c-runtime-library/errno-constants?view=msvc-170. 
>> 
>> I really think that `os::stat` should move away from using errno in this case. Also, it isn't really communicated clearly that that `os::stat()` is setting errno. I think this is best addressed in a follow-up, but it makes it harder to reason clearly about this patch.
>
>> I'm not sure this is the right solution. Now that we don't store the value of `GetLastError()` in errno and instead set errno to `ENOENT`, we don't detect if we get some other error than no entry. I think we should only set errno to `ENOENT` if `GetLastError()` returns either `ERROR_FILE_NOT_FOUND` or `ERROR_PATH_NOT_FOUND`.
> 
> I added this `if` case, but generally I do not think it is needed at all. 
> 
> We do not need to detect multiple flavours of failure. Simply because we are interested only in the end result, which is "does the file exist or not". If it does not, it does not matter why.  Introducing generic value` EOTHER `which means anything and nothing at the same time will serve no purpose. 
> 
> 
>> I really think that `os::stat` should move away from using errno in this case. Also, it isn't really communicated clearly that that `os::stat()` is setting errno. I think this is best addressed in a follow-up, but it makes it harder to reason clearly about this patch.
> 
> Maybe, but it is not in the scope of this PR.

Okay, I agree that the way the codebase is using `os::stat()` right now, we only care about whether we failed to stat or not, with one exception in the AOT code that also checks the errno value.

I think this is a tricky situation, because as `os::stat()` is designed right now it returns -1 on failure, and sets the errno value appropriately. We can't reasonable translate all `GetLastError()` values to errno, so we need some compromise. I don't think it is right that we either don't set the errno value in all cases, or always set it to the same value here.

I'll let others fill in with what they think, but ultimately we should remove using errno completely from `os::stat()`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26901#discussion_r2304076575

From duke at openjdk.org  Wed Aug 27 14:40:50 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Wed, 27 Aug 2025 14:40:50 GMT
Subject: Integrated: 8365975: Sort share/memory includes
In-Reply-To: <TUfg-TEPul_3CAv9kmnFbiJ9C5vUxixuA8nJyk9F6TY=.e438c1c4-02d7-4f57-a810-93d1116091d7@github.com>
References: <TUfg-TEPul_3CAv9kmnFbiJ9C5vUxixuA8nJyk9F6TY=.e438c1c4-02d7-4f57-a810-93d1116091d7@github.com>
Message-ID: <8rJEmCqj9AgxnKKChlDzQFE4lRrrnJJ3JHVYttMNuQE=.5eac4707-a122-45a1-85f9-0108b8ace5b0@github.com>

On Fri, 22 Aug 2025 09:03:45 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> This PR sorts the includes in `hotspot/share/memory` using `SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted`, and removing a couple of unnecessary include statements.
> 
> Passes `tier1`.

This pull request has now been integrated.

Changeset: 79cea6dd
Author:    Francesco Andreuzzi <andreuzzi.francesco at gmail.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/79cea6dd174c22f99b4cafc835e6c843c1b4ec38
Stats:     22 lines in 13 files changed: 11 ins; 9 del; 2 mod

8365975: Sort share/memory includes

Reviewed-by: shade, ayang, jwaters

-------------

PR: https://git.openjdk.org/jdk/pull/26897

From coleenp at openjdk.org  Wed Aug 27 19:07:43 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 27 Aug 2025 19:07:43 GMT
Subject: RFR: 8366255: Remove 'package_to_module' function from
 imageFile.cpp
In-Reply-To: <P5jiAyZ2475JUN18lxRKfqiFk0uJD_PB78WAZjolYvs=.edbd72da-0c96-40bf-baa9-36acd4aef003@github.com>
References: <P5jiAyZ2475JUN18lxRKfqiFk0uJD_PB78WAZjolYvs=.edbd72da-0c96-40bf-baa9-36acd4aef003@github.com>
Message-ID: <HEcDLwJ2Aw2szZogNuEivkPCY9eQHr6hAY3u2jKV9IY=.b04b715e-063b-410e-8eb5-f332f3547cad@github.com>

On Wed, 27 Aug 2025 17:44:04 GMT, David Beaumont <duke at openjdk.org> wrote:

> Removing the 'package_to_module' function from imageFile.cpp and the associated JNI export.
> This code isn't used or referenced from anywhere, and removing it makes adapting the package flags for use with preview mode simpler.
> 
> A clone of the Valhalla PR:
> https://github.com/openjdk/valhalla/pull/1535

It's not really hotspot-runtime code unless @dholmes-ora knows anything about it.

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26965#pullrequestreview-3161420849

From alanb at openjdk.org  Wed Aug 27 19:13:43 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 27 Aug 2025 19:13:43 GMT
Subject: RFR: 8366255: Remove 'package_to_module' function from
 imageFile.cpp
In-Reply-To: <HEcDLwJ2Aw2szZogNuEivkPCY9eQHr6hAY3u2jKV9IY=.b04b715e-063b-410e-8eb5-f332f3547cad@github.com>
References: <P5jiAyZ2475JUN18lxRKfqiFk0uJD_PB78WAZjolYvs=.edbd72da-0c96-40bf-baa9-36acd4aef003@github.com>
 <HEcDLwJ2Aw2szZogNuEivkPCY9eQHr6hAY3u2jKV9IY=.b04b715e-063b-410e-8eb5-f332f3547cad@github.com>
Message-ID: <6Ivqs-b3ra8zpOOaHdyI1wsO0rEHs8EUtkJ5YtqvXRg=.b1502e86-f0e1-4da1-a83c-b70750116728@github.com>

On Wed, 27 Aug 2025 19:05:10 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> It's not really hotspot-runtime code unless @dholmes-ora knows anything about it.

Change to libjimage usually need eyes from both core-libs and hotspot-runtime, the latter due to the usage in classLoader.cpp.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26965#issuecomment-3229441815

From duke at openjdk.org  Wed Aug 27 21:40:43 2025
From: duke at openjdk.org (duke)
Date: Wed, 27 Aug 2025 21:40:43 GMT
Subject: RFR: 8366255: Remove 'package_to_module' function from
 imageFile.cpp
In-Reply-To: <P5jiAyZ2475JUN18lxRKfqiFk0uJD_PB78WAZjolYvs=.edbd72da-0c96-40bf-baa9-36acd4aef003@github.com>
References: <P5jiAyZ2475JUN18lxRKfqiFk0uJD_PB78WAZjolYvs=.edbd72da-0c96-40bf-baa9-36acd4aef003@github.com>
Message-ID: <_N9Qt-SwFiX_ayXGiYicj4C0v_1ZpUDLeron77ah1SY=.29222c50-2e06-4a0d-bce1-e6b8eb52b05a@github.com>

On Wed, 27 Aug 2025 17:44:04 GMT, David Beaumont <duke at openjdk.org> wrote:

> Removing the 'package_to_module' function from imageFile.cpp and the associated JNI export.
> This code isn't used or referenced from anywhere, and removing it makes adapting the package flags for use with preview mode simpler.
> 
> A clone of the Valhalla PR:
> https://github.com/openjdk/valhalla/pull/1535

@david-beaumont 
Your change (at version 7d92134a622d0a1ca05d0e0c3d915489c5517da2) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26965#issuecomment-3229824162

From dholmes at openjdk.org  Thu Aug 28 01:12:52 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 28 Aug 2025 01:12:52 GMT
Subject: RFR: 8303612:
 runtime/StackGuardPages/TestStackGuardPagesNative.java fails with exit code
 139
In-Reply-To: <oRl4abf8ZV5qD9GNScJMRwwZD2PkdiDGJykDFs1Cmgo=.8c961e33-291f-4ba1-b494-ad5eab7ee72c@github.com>
References: <oRl4abf8ZV5qD9GNScJMRwwZD2PkdiDGJykDFs1Cmgo=.8c961e33-291f-4ba1-b494-ad5eab7ee72c@github.com>
Message-ID: <YrVbbBI6MxpX2nlJfxZOHO77y6kRxNBrSZNBWb-L9Ag=.e1cb99f6-3e6a-4ae3-978f-b87b53ed1cf5@github.com>

On Mon, 9 Jun 2025 06:53:20 GMT, mazhen <duke at openjdk.org> wrote:

> This pull request addresses an issue in `runtime/StackGuardPages/TestStackGuardPagesNative` where the native test component (`exeinvoke.c`) exhibited platform-dependent behavior and did not fully align with the intended test objectives for verifying stack guard page removal on thread detachment.
> 
> **Summary of the Problem:**
> 
> The `test_native_overflow_initial` scenario within `TestStackGuardPagesNative` showed inconsistent results:
> *   On certain Linux distributions (e.g., CentOS 7), the test would hang and eventually time out during its second phase of stack allocation.
> *   On other distributions (e.g., Ubuntu 24), the test would pass, but this pass was found to be coincidental, relying on an unintended `SEGV_MAPERR` to terminate a loop that should have had a defined exit condition.
> 
> The core issue was that the native code's second stack overflow attempt, designed to check for guard page removal, used an unbounded loop. Its termination (and thus the test's outcome) depended on platform-specific OS behavior regarding extensive stack allocation after guard pages are supposedly modified.
> 
> **Test Objective Analysis:**
> 
> The primary goal of `TestStackGuardPagesNative`, particularly for the initial thread (`test_native_overflow_initial`), is to:
> 1.  **Verify Guard Page Presence:** Confirm that when a native thread is attached to the JVM, a deliberate stack overflow triggers a `SIGSEGV` with `si_code = SEGV_ACCERR`, indicating an active stack guard page.
> 2.  **Verify Guard Page Removal/Modification:** After the thread detaches from the JVM via `DetachCurrentThread()`, confirm that the previously active stack guard page is no longer enforcing the same strict protection. This is ideally demonstrated by successfully allocating stack space up to the depth that previously caused the `SEGV_ACCERR`, **without encountering any signal**.
> 
> **How the Original Implementation Deviated from the Test Intent:**
> 
> The native `do_overflow` function, when invoked for the second phase (to check guard page removal), implemented an unconditional `for(;;)` loop.
> *   **Intended Logic vs. Actual Behavior:** The test intended for this second phase to demonstrate that allocations up to the prior failure depth are now "clean" (no `SEGV_ACCERR`). However, the unbounded loop meant:
>     *   On systems like CentOS 7, where deep stack allocation without an immediate `SEGV_MAPERR` was possible, this loop ran for an excessive duration, leading to a hang.
>     *   On systems like Ubuntu 24, the loop *...

I think this fix addresses your CentOS timeout issue by ensuring that the overflow loop will terminate even if no SEGV is encountered. IIUC "normally" the peek would eventually fault when we hit the libc guard page, but on CentOS this may not be the case and the region beyond the current stack may be accessible and so not fault.

However, I don't see how this fix addresses the other failure modes that have been reported in this issue.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25689#pullrequestreview-3162584216

From dholmes at openjdk.org  Thu Aug 28 01:15:41 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 28 Aug 2025 01:15:41 GMT
Subject: RFR: 8353468: [ubsan] arguments.cpp:2422:23: runtime error:
 2.14748e+11 is outside the range of representable values of type 'int' [v3]
In-Reply-To: <x2XW0ywYSy-9Tqh-Mzrhd3X1o8MTo5rADg48p92rpDo=.a3e4e6cf-ce98-48c7-b90d-cfa22b130e54@github.com>
References: <plQ5n7EjsekIjeY431_mBeo4rfcH39SVdPWogF2rT44=.20180c89-665e-4054-8625-1b04f8306b3b@github.com>
 <x2XW0ywYSy-9Tqh-Mzrhd3X1o8MTo5rADg48p92rpDo=.a3e4e6cf-ce98-48c7-b90d-cfa22b130e54@github.com>
Message-ID: <yU_WJ0o3hjfdLIexyV0k2XkT7sH40IJRtXkMGkrDuY4=.b6bad22d-0c91-4e6a-acd0-ba1c371e6b38@github.com>

On Wed, 27 Aug 2025 09:54:43 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> In converting values of `-XMinf` and `-XMaxf` options to `int`, overflow was not checked. 
>> The values are checked against INT_MAX and clamped.
>> 
>> Tests: tiers 1-5.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improved invalid detection and error messages

Any removal of the flags would be in the future. We would have to deprecate first and follow a three step process - though these are not hotspot flags per-se (-XX) but non-standard launcher flags (-X).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26859#issuecomment-3230765703

From dholmes at openjdk.org  Thu Aug 28 01:28:45 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 28 Aug 2025 01:28:45 GMT
Subject: RFR: 8353468: [ubsan] arguments.cpp:2422:23: runtime error:
 2.14748e+11 is outside the range of representable values of type 'int' [v3]
In-Reply-To: <x2XW0ywYSy-9Tqh-Mzrhd3X1o8MTo5rADg48p92rpDo=.a3e4e6cf-ce98-48c7-b90d-cfa22b130e54@github.com>
References: <plQ5n7EjsekIjeY431_mBeo4rfcH39SVdPWogF2rT44=.20180c89-665e-4054-8625-1b04f8306b3b@github.com>
 <x2XW0ywYSy-9Tqh-Mzrhd3X1o8MTo5rADg48p92rpDo=.a3e4e6cf-ce98-48c7-b90d-cfa22b130e54@github.com>
Message-ID: <w1yU1ZStrSKCR70pg-WegpafHrscV7XjFub3mVfgsbM=.52f36820-1a8e-4cc2-9e9d-7a2030ebcde6@github.com>

On Wed, 27 Aug 2025 09:54:43 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> In converting values of `-XMinf` and `-XMaxf` options to `int`, overflow was not checked. 
>> The values are checked against INT_MAX and clamped.
>> 
>> Tests: tiers 1-5.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improved invalid detection and error messages

Changes requested by dholmes (Reviewer).

src/hotspot/share/runtime/arguments.cpp line 2422:

> 2420:       } else {
> 2421:         if (dmaxf < 0.0 || dmaxf > 1.0) {
> 2422:           JVMFlag::printError(true,"uintx MaxHeapFreeRatio=%s is outside the allowed range  [ 0.0 ... 1.0 ]\n", tail);

This needs to refer to the allowed range for `-Xmaxf` as that is what the user supplied. The user does not know this is just used to internally set `MaxHeapFreeRatio`. If `-Xminf` and `-Xmaxf` were actually VM `-XX` flags then we would have defined the appropriate constraint function for them. We need to emulate that here. There should also be checks that minf <= maxf.

-------------

PR Review: https://git.openjdk.org/jdk/pull/26859#pullrequestreview-3162630697
PR Review Comment: https://git.openjdk.org/jdk/pull/26859#discussion_r2305846137

From dholmes at openjdk.org  Thu Aug 28 02:51:42 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 28 Aug 2025 02:51:42 GMT
Subject: RFR: 8364816: GetLastError() in os_windows.cpp should not store
 value to errno [v4]
In-Reply-To: <CuRfAQfuS8YBTXFtdsYeGdya2B2Kqmz3BfigGhCoBbQ=.42c2276a-45d3-49b0-a151-5e764c4f69e7@github.com>
References: <-kp4UVOCqF0ZxITA-Rra0t7rWXXC0wLvAnO3OwchPkU=.7873481b-991a-429e-9b4c-9f2c68fec48f@github.com>
 <CuRfAQfuS8YBTXFtdsYeGdya2B2Kqmz3BfigGhCoBbQ=.42c2276a-45d3-49b0-a151-5e764c4f69e7@github.com>
Message-ID: <glOfjKInnwtGlZf88cU5ip_oJ1Mg_V9r_3hhm13N3Vw=.6839290c-4e9d-4e04-a528-2f8485e9faa2@github.com>

On Wed, 27 Aug 2025 13:09:39 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> In `os_windows.cpp` in a few places results returned by `GetLastError()` are stored to `errno`. However, `errno` has no relation to `GetLastError()`, and their ranges are not the same.
>> 
>> Results of `GetLastError()` should be stored into variables of type `DWORD`.
>> 
>> The removed section in `src/hotspot/share/cds/aotClassLocation.cpp` was relying on values returned by `GetLastError()` and stored to `errno` in `os::stat()`. Though the logic was correct, these values should not be stored to `errno`. The functionality is preserved by storing a **valid** value `ENOENT` to `errno` in `os::stat()`. 
>> 
>> Tested in tiers 1 - 3.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8364816: Modified case when ENOENT value is stored to errno.

Things are never simple. :)

The basic change of not setting `errno` from `GetLastError` is good. That is a bug that had to be fixed.

I think your approach for setting `errno` when callers expect it to be set is also good (but see below). Most callers of `os::stat` care only about success or failure - not the details of why (which you have recorded in the logging anyway if the user/developer is interested).

You also fixed the `aotClassLocation.cpp` hack because you should never have to check `errno` for Windows specific error codes - so that is an extra bonus IMO.

The more general problem of how to map `GetLastError` to `errno` when callers expect to check `errno`, may still remain in other places. That's a separate issue IMO. But I also note that in JDK 8 code we do perform such a mapping where needed (we have more cases to deal with post JDK 8 but it is worth looking at the old code).

However, this has highlighted a giant hole in the way `errno` is being used: we have cleanup code that will likely overwrite `errno` before the caller could get to check it! And if cleanup code doesn't then logging code will. This likely affects non-Windows code too - though it may be `ErrnoPreserver` is being used in enough places there. This seems to be a fairly new problem - I don't see it in JDK 21. I have filed [JDK-8366272](https://bugs.openjdk.org/browse/JDK-8366272)

I have flagged one thing, in relation to `_wopen` that needs fixing, but otherwise I think this PR is okay in this form. But then we need the follow up to properly manage `errno`.

Thanks

src/hotspot/os/windows/os_windows.cpp line 5035:

> 5033:   if (fd == -1) {
> 5034:     DWORD errcode = ::GetLastError();
> 5035:     log_debug(os)("os::open() failed to _wopen: GetLastError->%lu.", errcode);

This is not actually needed. `_wopen` sets `errno` not `GetlastError`, so the original code is just wrong.

However, (and this is a general problem with errno and cleanup actions) if we log the error, we will modify errno so even if a caller is checking errno they won't get what they expect. Even if not logging the `os::free` can also potentially modify errno so this use of errno is inherently flawed!

A proper fix (and likely applies to non-Windows code too) would be to save errno and restore only upon returning.

-------------

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26901#pullrequestreview-3162817653
PR Review Comment: https://git.openjdk.org/jdk/pull/26901#discussion_r2305958909

From dholmes at openjdk.org  Thu Aug 28 05:39:42 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 28 Aug 2025 05:39:42 GMT
Subject: RFR: 8365913: Support latest MSC_VER in abstract_vm_version.cpp
In-Reply-To: <m96A9c01TCmTDpCCsAt3MdpGXs21kDUW2_GRoziwmBY=.fc9b5e23-218d-4a1e-b882-05e85d7c15fe@github.com>
References: <m96A9c01TCmTDpCCsAt3MdpGXs21kDUW2_GRoziwmBY=.fc9b5e23-218d-4a1e-b882-05e85d7c15fe@github.com>
Message-ID: <ztYG7i2R-lwGB8yqhoewOUhCcEmI6vpbd_v55d3Y948=.e8136622-ced9-479f-9eac-5d35381b58b9@github.com>

On Thu, 21 Aug 2025 09:59:14 GMT, Joakim Nordstr?m <jnordstrom at openjdk.org> wrote:

> With the latest devkit upgrade for Windows, hs_err files and `-Xinternalversion` reports "`unknown MS VC++:1943`".
> 
> This fix adds the latest known MSC_VER version, as of current date according to https://learn.microsoft.com/en-us/cpp/overview/compiler-versions?view=msvc-170.
> 
> ### Testing
> - [x] Built locally and verified MSVC version is reported correctly
> - [ ] tier1-tier3

Looks good and trivial.

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26878#pullrequestreview-3163233894

From dholmes at openjdk.org  Thu Aug 28 06:52:41 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 28 Aug 2025 06:52:41 GMT
Subject: RFR: 8366232: JFR startup messages are shown with
 -Xlog:jfr+startup=warning
In-Reply-To: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
References: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
Message-ID: <upX9JgHw42jbEwfsFoVsnJwFtecUsC_EZVfrRZLlqbo=.37c0cf66-a924-4ebf-ae0d-b18b592a4ac5@github.com>

On Wed, 27 Aug 2025 12:07:54 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Only print the JFR startup messages when no or a < warning log level is set explicitly by the user.

I can't say I like the general changes to UL to accommodate this. I also don't really like what JFR is already doing. I'm trying to see what the motivation is here. It appears to be "give a verbose startup message but don't label it as a 'warning'".  But there is also no guarantee that `jfr+startup` is being logged to `stdout` so this could by-pass the user's control over logging output!

-------------

PR Review: https://git.openjdk.org/jdk/pull/26957#pullrequestreview-3163457152

From dholmes at openjdk.org  Thu Aug 28 07:00:50 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 28 Aug 2025 07:00:50 GMT
Subject: RFR: 8366255: Remove 'package_to_module' function from
 imageFile.cpp
In-Reply-To: <P5jiAyZ2475JUN18lxRKfqiFk0uJD_PB78WAZjolYvs=.edbd72da-0c96-40bf-baa9-36acd4aef003@github.com>
References: <P5jiAyZ2475JUN18lxRKfqiFk0uJD_PB78WAZjolYvs=.edbd72da-0c96-40bf-baa9-36acd4aef003@github.com>
Message-ID: <tfbnFbVEI1fl6_YQ5D_vq6ijsWqfc1o7A5ny7exrP6s=.634c00fc-9a96-4b96-b1f4-644ef19cd9d4@github.com>

On Wed, 27 Aug 2025 17:44:04 GMT, David Beaumont <duke at openjdk.org> wrote:

> Removing the 'package_to_module' function from imageFile.cpp and the associated JNI export.
> This code isn't used or referenced from anywhere, and removing it makes adapting the package flags for use with preview mode simpler.
> 
> A clone of the Valhalla PR:
> https://github.com/openjdk/valhalla/pull/1535

Nothing runtime affecting that I can see and no changes to hotspot code so no 24 hour rule.

Changes look fine.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26965#issuecomment-3232188089

From duke at openjdk.org  Thu Aug 28 07:00:50 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 28 Aug 2025 07:00:50 GMT
Subject: Integrated: 8366255: Remove 'package_to_module' function from
 imageFile.cpp
In-Reply-To: <P5jiAyZ2475JUN18lxRKfqiFk0uJD_PB78WAZjolYvs=.edbd72da-0c96-40bf-baa9-36acd4aef003@github.com>
References: <P5jiAyZ2475JUN18lxRKfqiFk0uJD_PB78WAZjolYvs=.edbd72da-0c96-40bf-baa9-36acd4aef003@github.com>
Message-ID: <_Vz0JIj_-iIS-GLeD1thRSIMWfTcVCI_VCGjPyYFiw8=.932ac097-bfc5-485c-9c12-0d73b301effd@github.com>

On Wed, 27 Aug 2025 17:44:04 GMT, David Beaumont <duke at openjdk.org> wrote:

> Removing the 'package_to_module' function from imageFile.cpp and the associated JNI export.
> This code isn't used or referenced from anywhere, and removing it makes adapting the package flags for use with preview mode simpler.
> 
> A clone of the Valhalla PR:
> https://github.com/openjdk/valhalla/pull/1535

This pull request has now been integrated.

Changeset: ab1f2af4
Author:    David Beaumont <david.beaumont at oracle.com>
Committer: David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ab1f2af4f0e9d3bea53f394413720c19fc7cae62
Stats:     139 lines in 4 files changed: 0 ins; 133 del; 6 mod

8366255: Remove 'package_to_module' function from imageFile.cpp

Reviewed-by: rriggs, coleenp

-------------

PR: https://git.openjdk.org/jdk/pull/26965

From jbechberger at openjdk.org  Thu Aug 28 07:02:46 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 28 Aug 2025 07:02:46 GMT
Subject: RFR: 8366232: JFR startup messages are shown with
 -Xlog:jfr+startup=warning
In-Reply-To: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
References: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
Message-ID: <tqclVA9tWr0X1nOHUxne-5gxWNqn2qi0T9NeIAGYgC4=.60ffdd28-7924-4eb2-ae55-f3ddc7840df0@github.com>

On Wed, 27 Aug 2025 12:07:54 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Only print the JFR startup messages when no or a < warning log level is set explicitly by the user.

The motivation is to better capture the user's intent. When the user doesn't set any warning level, then we keep the default behaviour, for backwards compatibility as in the original change, when the user sets the logging level, then we consider it.

You mentioned yourself in the original issue:


 I'm just not sure we have a way to query if the logging level has been explicitly set to a given value.


I just implemented this. I just implemented a way to properly check whether the user didn't specify a logging level, so the code doesn't have to assume that a `warning` logging level means the user didn't set anything.

This change tries to reduce confusion.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26957#issuecomment-3232196397

From azafari at openjdk.org  Thu Aug 28 07:29:46 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 28 Aug 2025 07:29:46 GMT
Subject: RFR: 8353468: [ubsan] arguments.cpp:2422:23: runtime error:
 2.14748e+11 is outside the range of representable values of type 'int' [v3]
In-Reply-To: <w1yU1ZStrSKCR70pg-WegpafHrscV7XjFub3mVfgsbM=.52f36820-1a8e-4cc2-9e9d-7a2030ebcde6@github.com>
References: <plQ5n7EjsekIjeY431_mBeo4rfcH39SVdPWogF2rT44=.20180c89-665e-4054-8625-1b04f8306b3b@github.com>
 <x2XW0ywYSy-9Tqh-Mzrhd3X1o8MTo5rADg48p92rpDo=.a3e4e6cf-ce98-48c7-b90d-cfa22b130e54@github.com>
 <w1yU1ZStrSKCR70pg-WegpafHrscV7XjFub3mVfgsbM=.52f36820-1a8e-4cc2-9e9d-7a2030ebcde6@github.com>
Message-ID: <c_sFYToa5A4s8wP6JXAWVPzSsTHAwmp1-LjImMdYdI0=.06deac44-abcd-4ec8-a0dc-3d4aad8458c0@github.com>

On Thu, 28 Aug 2025 01:26:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   improved invalid detection and error messages
>
> src/hotspot/share/runtime/arguments.cpp line 2422:
> 
>> 2420:       } else {
>> 2421:         if (dmaxf < 0.0 || dmaxf > 1.0) {
>> 2422:           JVMFlag::printError(true,"uintx MaxHeapFreeRatio=%s is outside the allowed range  [ 0.0 ... 1.0 ]\n", tail);
> 
> This needs to refer to the allowed range for `-Xmaxf` as that is what the user supplied. The user does not know this is just used to internally set `MaxHeapFreeRatio`. If `-Xminf` and `-Xmaxf` were actually VM `-XX` flags then we would have defined the appropriate constraint function for them. We need to emulate that here. There should also be checks that minf <= maxf.

This is exactly the source of confusion. User is allowed to enter `double` values in range `[0.0, 1.0]`, but the value is multiplied by 100 and stored in a `uintx`.
Using hard-coded constants `MinHeapFreeRatio ` and `MaxHeapFreeRatio` in the error message is as expected by tests.
These two flags have already constraint functions as `MinHeapFreeRatioConstraintFunc` and `MaxHeapFreeRatioConstraintFunc` where minf <= maxf is checked.
Checking the user input to be in [0.0, 1.0] cannot be done in the constraint functions, since the original input is missed due to * 100 and casting to uintx.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26859#discussion_r2306476665

From duke at openjdk.org  Thu Aug 28 07:46:41 2025
From: duke at openjdk.org (mazhen)
Date: Thu, 28 Aug 2025 07:46:41 GMT
Subject: RFR: 8303612:
 runtime/StackGuardPages/TestStackGuardPagesNative.java fails with exit code
 139
In-Reply-To: <lJRJpcHQe1HHoiDFbTwWZo13-3BhpMq4uwFNegBJ1ww=.1ccda972-41a1-4373-baba-c9f0a0e1795f@github.com>
References: <oRl4abf8ZV5qD9GNScJMRwwZD2PkdiDGJykDFs1Cmgo=.8c961e33-291f-4ba1-b494-ad5eab7ee72c@github.com>
 <blniq87ptY1r2ZSL2nR17MV-SHTmPOPcAPWRgCVqL24=.b011371a-c54e-4fd9-b25b-19e22c321d3f@github.com>
 <lJRJpcHQe1HHoiDFbTwWZo13-3BhpMq4uwFNegBJ1ww=.1ccda972-41a1-4373-baba-c9f0a0e1795f@github.com>
Message-ID: <v3Ju1h_P2bt1bhqcaio_xDWLllKDuH4raHjRPSeLZSo=.787a9271-2c05-48a8-847c-72e2b247ab43@github.com>

On Tue, 5 Aug 2025 02:28:41 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Hi @jdksjolen ,
>> 
>> Following up on this. As per the bot's message two weeks ago, I've been waiting for my OCA to be processed, but it seems to be stuck.
>> I understand that PRs are not reviewed until the OCA is cleared, but since the suggested two-week waiting period has passed, I was hoping someone could help to check or escalate the status of my OCA application internally.
>> 
>> My Oracle Account Email: mz1999 at gmail.com
>> 
>> Any help would be greatly appreciated. Thank you!
>
> @mz1999 the forever-loop was added as part of the "hardening" changes by JDK-8295344, so it seems you are saying that introduced a new bug? How does your proposed change compare to the code that we had prior to the "hardening"? I just want to try and see what the original problem with this code was. Thanks

Hi @dholmes-ora and @jdksjolen ,

Thank you so much for your insightful comments and for pointing me to the relevant JBS issues. After studying the history you pointed me to in JDK-8295344 and JDK-8293452, I think I have a better understanding of the evolution of this test and the critical reasoning behind the "hardening" fix.

Here?s my understanding of the test's journey, which I hope clarifies my intention with this PR.

### The Original Recursive Implementation

The original implementation was recursive, which looked something like this:


// Generation 1: Recursive and Bounded
void do_overflow(){
  int *p = alloca(sizeof(int));
  if (_kp_rec_count == 0 || _rec_count < _kp_rec_count) {
      _rec_count ++;
      do_overflow();
  }
}


My reading of `JDK-8293452` shows that the original test had a critical flaw: its **recursive nature** could corrupt the stack, leading to an unpredictable crash later in `DetachCurrentThread()`.

### The "Hardening" Fix (Iterative but Unbounded)

The "hardening" fix in `JDK-8295344` was created specifically to solve this by replacing recursion with an iterative `for(;;)` loop.


// Generation 2: Iterative but Unbounded
void do_overflow(){
  volatile int *p = NULL;
  if (_kp_rec_count == 0 || _rec_count < _kp_rec_count) {
    for(;;) {
      _rec_count++;
      p = (int*)alloca(128);
      _peek_value = p[0]; // Peek
    }
  }
}

While this successfully eliminated the stack corruption from `JDK-8293452`, it inadvertently introduced the new platform-dependent hang.

### My Proposed Change (Iterative and Bounded)

My proposed change is an evolution of this iterative approach, not a regression to recursion. It retains the iterative nature of the hardening fix but adds a boundary condition to the loop:


// Generation 3 (My PR): Iterative and Bounded
void do_overflow(){
  volatile int *p = NULL;
  while (_kp_rec_count == 0 || _rec_count < _kp_rec_count) {
    _rec_count++;
    p = (int*)alloca(128);
    _peek_value = p[0]; // Peek
  }
}


It retains the crucial **iterative** approach from `JDK-8295344` (solving the stack corruption from `JDK-8293452`), while also adding the necessary **boundary** (solving the hang introduced by `JDK-8295344`).

I believe this approach resolves both the original crash and the subsequent hang.

Thank you again for your guidance and patience.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25689#issuecomment-3232329368

From dholmes at openjdk.org  Thu Aug 28 07:57:43 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 28 Aug 2025 07:57:43 GMT
Subject: RFR: 8366232: JFR startup messages are shown with
 -Xlog:jfr+startup=warning
In-Reply-To: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
References: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
Message-ID: <OyJ4ccSOqfH0xY39FRh5tSO6JVjT-RFCe0dVr3G30ww=.a06256fa-6b5e-43ff-9668-7f5e192c7bed@github.com>

On Wed, 27 Aug 2025 12:07:54 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Only print the JFR startup messages when no or a < warning log level is set explicitly by the user.

What was the original issue? I have forgotten about this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26957#issuecomment-3232364965

From stefank at openjdk.org  Thu Aug 28 08:01:43 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 28 Aug 2025 08:01:43 GMT
Subject: RFR: 8353468: [ubsan] arguments.cpp:2422:23: runtime error:
 2.14748e+11 is outside the range of representable values of type 'int' [v3]
In-Reply-To: <c_sFYToa5A4s8wP6JXAWVPzSsTHAwmp1-LjImMdYdI0=.06deac44-abcd-4ec8-a0dc-3d4aad8458c0@github.com>
References: <plQ5n7EjsekIjeY431_mBeo4rfcH39SVdPWogF2rT44=.20180c89-665e-4054-8625-1b04f8306b3b@github.com>
 <x2XW0ywYSy-9Tqh-Mzrhd3X1o8MTo5rADg48p92rpDo=.a3e4e6cf-ce98-48c7-b90d-cfa22b130e54@github.com>
 <w1yU1ZStrSKCR70pg-WegpafHrscV7XjFub3mVfgsbM=.52f36820-1a8e-4cc2-9e9d-7a2030ebcde6@github.com>
 <c_sFYToa5A4s8wP6JXAWVPzSsTHAwmp1-LjImMdYdI0=.06deac44-abcd-4ec8-a0dc-3d4aad8458c0@github.com>
Message-ID: <WJ9Y5fZlgXvViZWRCFoDCQNeQ7zvcTtdHPyqt2AFxxw=.8ca2e476-1945-4897-a287-4b4b17446113@github.com>

On Thu, 28 Aug 2025 07:27:24 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> src/hotspot/share/runtime/arguments.cpp line 2422:
>> 
>>> 2420:       } else {
>>> 2421:         if (dmaxf < 0.0 || dmaxf > 1.0) {
>>> 2422:           JVMFlag::printError(true,"uintx MaxHeapFreeRatio=%s is outside the allowed range  [ 0.0 ... 1.0 ]\n", tail);
>> 
>> This needs to refer to the allowed range for `-Xmaxf` as that is what the user supplied. The user does not know this is just used to internally set `MaxHeapFreeRatio`. If `-Xminf` and `-Xmaxf` were actually VM `-XX` flags then we would have defined the appropriate constraint function for them. We need to emulate that here. There should also be checks that minf <= maxf.
>
> This is exactly the source of confusion. User is allowed to enter `double` values in range `[0.0, 1.0]`, but the value is multiplied by 100 and stored in a `uintx`.
> Using hard-coded constants `MinHeapFreeRatio ` and `MaxHeapFreeRatio` in the error message is as expected by tests.
> These two flags have already constraint functions as `MinHeapFreeRatioConstraintFunc` and `MaxHeapFreeRatioConstraintFunc` where minf <= maxf is checked.
> Checking the user input to be in [0.0, 1.0] cannot be done in the constraint functions, since the original input is missed due to * 100 and casting to uintx.

I agree with David's comment here. The suggestion is to explicitly pre-check that Xminf/Xmaxf falls within [0.0, 1.0], just so that the constraint function for MinHeapFreeRatio/MaxHeapFreeRatio triggers and gives a confusing message.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26859#discussion_r2306560558

From jbechberger at openjdk.org  Thu Aug 28 08:24:41 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 28 Aug 2025 08:24:41 GMT
Subject: RFR: 8366232: JFR startup messages are shown with
 -Xlog:jfr+startup=warning
In-Reply-To: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
References: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
Message-ID: <nmzMdCujz2lrDkT_owCBAlK-s_tpo2QEivFPL7fnZ5A=.3cf87678-ad16-47d5-9401-39987c0f90c9@github.com>

On Wed, 27 Aug 2025 12:07:54 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Only print the JFR startup messages when no or a < warning log level is set explicitly by the user.

The original issue was [JDK-8244190](https://bugs.openjdk.org/browse/JDK-8244190), this PR just fixes a short-coming of the implementation. The limitations is even mentioned in [one of the tests](https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/jfr/startupargs/TestStartupMessage.java):


        startJfrJvm("-Xlog:jfr+startup=error")
             .shouldNotContain("[jfr,startup")
             .shouldNotContain("Started recording")
             .shouldNotContain("Use jcmd");

         // Known limitation.
         // Can't turn off log with -Xlog:jfr+startup=warning

         startJfrJvm()
             .shouldContain("[info][jfr,startup")
             .shouldContain("Started recording")
             .shouldContain("Use jcmd");


This PR updates the test too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26957#issuecomment-3232456905

From cnorrbin at openjdk.org  Thu Aug 28 09:17:06 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Thu, 28 Aug 2025 09:17:06 GMT
Subject: RFR: 8366238: Improve RBTree API with stricter comparator semantics
 and pluggable validation/printing hooks.
Message-ID: <xBBv_Un-GHPOs_Ri3_1aop840xjcQpScyPXOJZ31kjo=.57eec1fc-d4ce-4b05-bff5-b9851f496503@github.com>

Hi everyone,

The current red-black tree can be made safer, and its inspection capabilities improved.

As briefly discussed in #26904, `COMPARATOR::cmp` could be made clearer and more robust. In particular, its `int` return type invites unsafe `return a ? b` arithmetic, and the boolean validation function also named `cmp` is misleading.

To address this, I?ve introduced the `RBTreeOrdering` enum, inspired by C++20?s `<=>`, which makes incorrect arithmetic impossible. The return type of `COMPARATOR::cmp` is now this enum, forcing users to write an explicit and safe comparison. From the discussion in that PR, I have also renamed the boolean `cmp` to `less`, making its purpose obvious and preventing confusion between the two functions.

Inspection has also been improved, especially for intrusive trees. Previously, `verify_self` only verified core RB-tree properties, yet intrusive nodes often hold additional data with their own separate invariants. Users had to perform those checks in a second traversal, and if an error occurs `print_on` produced little diagnostic value by only printing node addresses.

To solve this, the tree now accepts user-supplied verification and printing callables. This lets users validate their custom node data during the same walk and print richer information when errors occur.

Everything is implemented via template parameters with set defaults, so existing code remains unchanged while new code can opt in to the expanded functionality.

-------------

Commit messages:
 - rbtree better cmp and verify/print user functions

Changes: https://git.openjdk.org/jdk/pull/26981/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26981&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366238
  Stats: 258 lines in 7 files changed: 159 ins; 8 del; 91 mod
  Patch: https://git.openjdk.org/jdk/pull/26981.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26981/head:pull/26981

PR: https://git.openjdk.org/jdk/pull/26981

From duke at openjdk.org  Thu Aug 28 09:19:48 2025
From: duke at openjdk.org (Anton Artemov)
Date: Thu, 28 Aug 2025 09:19:48 GMT
Subject: RFR: 8364816: GetLastError() in os_windows.cpp should not store
 value to errno [v5]
In-Reply-To: <-kp4UVOCqF0ZxITA-Rra0t7rWXXC0wLvAnO3OwchPkU=.7873481b-991a-429e-9b4c-9f2c68fec48f@github.com>
References: <-kp4UVOCqF0ZxITA-Rra0t7rWXXC0wLvAnO3OwchPkU=.7873481b-991a-429e-9b4c-9f2c68fec48f@github.com>
Message-ID: <ZQvXHrE9ooQIVRp5hZQpME39EQ9fUJJGoE8rGH5zUx8=.0baf2490-f2fe-4d87-8a4b-2cf3a043802b@github.com>

> Hi, please consider the following changes:
> 
> In `os_windows.cpp` in a few places results returned by `GetLastError()` are stored to `errno`. However, `errno` has no relation to `GetLastError()`, and their ranges are not the same.
> 
> Results of `GetLastError()` should be stored into variables of type `DWORD`.
> 
> The removed section in `src/hotspot/share/cds/aotClassLocation.cpp` was relying on values returned by `GetLastError()` and stored to `errno` in `os::stat()`. Though the logic was correct, these values should not be stored to `errno`. The functionality is preserved by storing a **valid** value `ENOENT` to `errno` in `os::stat()`. 
> 
> Tested in tiers 1 - 3.

Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:

  8364816: Fixed _wopen case.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26901/files
  - new: https://git.openjdk.org/jdk/pull/26901/files/d989cbb3..f8f3632a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26901&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26901&range=03-04

  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/26901.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26901/head:pull/26901

PR: https://git.openjdk.org/jdk/pull/26901

From duke at openjdk.org  Thu Aug 28 09:21:26 2025
From: duke at openjdk.org (Anton Artemov)
Date: Thu, 28 Aug 2025 09:21:26 GMT
Subject: RFR: 8364816: GetLastError() in os_windows.cpp should not store
 value to errno [v4]
In-Reply-To: <glOfjKInnwtGlZf88cU5ip_oJ1Mg_V9r_3hhm13N3Vw=.6839290c-4e9d-4e04-a528-2f8485e9faa2@github.com>
References: <-kp4UVOCqF0ZxITA-Rra0t7rWXXC0wLvAnO3OwchPkU=.7873481b-991a-429e-9b4c-9f2c68fec48f@github.com>
 <CuRfAQfuS8YBTXFtdsYeGdya2B2Kqmz3BfigGhCoBbQ=.42c2276a-45d3-49b0-a151-5e764c4f69e7@github.com>
 <glOfjKInnwtGlZf88cU5ip_oJ1Mg_V9r_3hhm13N3Vw=.6839290c-4e9d-4e04-a528-2f8485e9faa2@github.com>
Message-ID: <E1sAOe6b_VAUHxqVh-GuOMS98bcX5g_DLA5I_9min3Y=.1dc2229f-c1ee-4a92-96c4-aff6efb827bd@github.com>

On Thu, 28 Aug 2025 02:15:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8364816: Modified case when ENOENT value is stored to errno.
>
> src/hotspot/os/windows/os_windows.cpp line 5035:
> 
>> 5033:   if (fd == -1) {
>> 5034:     DWORD errcode = ::GetLastError();
>> 5035:     log_debug(os)("os::open() failed to _wopen: GetLastError->%lu.", errcode);
> 
> This is not actually needed. `_wopen` sets `errno` not `GetlastError`, so the original code is just wrong.
> 
> However, (and this is a general problem with errno and cleanup actions) if we log the error, we will modify errno so even if a caller is checking errno they won't get what they expect. Even if not logging the `os::free` can also potentially modify errno so this use of errno is inherently flawed!
> 
> A proper fix (and likely applies to non-Windows code too) would be to save errno and restore only upon returning.

Thanks, I addressed this local problem. It looks like Windows os-related functions do not have consistency. Some, like this one, report the error type via `errno`, some can report via a separate call to `GetLastError`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26901#discussion_r2306791897

From jsikstro at openjdk.org  Thu Aug 28 09:32:46 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 28 Aug 2025 09:32:46 GMT
Subject: RFR: 8366238: Improve RBTree API with stricter comparator
 semantics and pluggable validation/printing hooks.
In-Reply-To: <xBBv_Un-GHPOs_Ri3_1aop840xjcQpScyPXOJZ31kjo=.57eec1fc-d4ce-4b05-bff5-b9851f496503@github.com>
References: <xBBv_Un-GHPOs_Ri3_1aop840xjcQpScyPXOJZ31kjo=.57eec1fc-d4ce-4b05-bff5-b9851f496503@github.com>
Message-ID: <EDJfrMVNF6K0122ygh6VuL64PHbIhFJi2019puS5KyU=.4c0692bf-734d-493c-b0f7-928523c5a7a6@github.com>

On Thu, 28 Aug 2025 09:06:26 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> The current red-black tree can be made safer, and its inspection capabilities improved.
> 
> As briefly discussed in #26904, `COMPARATOR::cmp` could be made clearer and more robust. In particular, its `int` return type invites unsafe `return a ? b` arithmetic, and the boolean validation function also named `cmp` is misleading.
> 
> To address this, I?ve introduced the `RBTreeOrdering` enum, inspired by C++20?s `<=>`, which makes incorrect arithmetic impossible. The return type of `COMPARATOR::cmp` is now this enum, forcing users to write an explicit and safe comparison. From the discussion in that PR, I have also renamed the boolean `cmp` to `less`, making its purpose obvious and preventing confusion between the two functions.
> 
> Inspection has also been improved, especially for intrusive trees. Previously, `verify_self` only verified core RB-tree properties, yet intrusive nodes often hold additional data with their own separate invariants. Users had to perform those checks in a second traversal, and if an error occurs `print_on` produced little diagnostic value by only printing node addresses.
> 
> To solve this, the tree now accepts user-supplied verification and printing callables. This lets users validate their custom node data during the same walk and print richer information when errors occur.
> 
> Everything is implemented via template parameters with set defaults, so existing code remains unchanged while new code can opt in to the expanded functionality.

The changes to ZGC looks OK. Thank you for this!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26981#issuecomment-3232716188

From ayang at openjdk.org  Thu Aug 28 09:43:48 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 28 Aug 2025 09:43:48 GMT
Subject: RFR: 8366238: Improve RBTree API with stricter comparator
 semantics and pluggable validation/printing hooks.
In-Reply-To: <xBBv_Un-GHPOs_Ri3_1aop840xjcQpScyPXOJZ31kjo=.57eec1fc-d4ce-4b05-bff5-b9851f496503@github.com>
References: <xBBv_Un-GHPOs_Ri3_1aop840xjcQpScyPXOJZ31kjo=.57eec1fc-d4ce-4b05-bff5-b9851f496503@github.com>
Message-ID: <Kob0t0RZEeCTqyenzGKuVaQoPqTQBX2xJOZCWaTDs1k=.f2d5d88c-0c3a-4e43-a650-5ee82b2f2a94@github.com>

On Thu, 28 Aug 2025 09:06:26 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> The current red-black tree can be made safer, and its inspection capabilities improved.
> 
> As briefly discussed in #26904, `COMPARATOR::cmp` could be made clearer and more robust. In particular, its `int` return type invites unsafe `return a ? b` arithmetic, and the boolean validation function also named `cmp` is misleading.
> 
> To address this, I?ve introduced the `RBTreeOrdering` enum, inspired by C++20?s `<=>`, which makes incorrect arithmetic impossible. The return type of `COMPARATOR::cmp` is now this enum, forcing users to write an explicit and safe comparison. From the discussion in that PR, I have also renamed the boolean `cmp` to `less`, making its purpose obvious and preventing confusion between the two functions.
> 
> Inspection has also been improved, especially for intrusive trees. Previously, `verify_self` only verified core RB-tree properties, yet intrusive nodes often hold additional data with their own separate invariants. Users had to perform those checks in a second traversal, and if an error occurs `print_on` produced little diagnostic value by only printing node addresses.
> 
> To solve this, the tree now accepts user-supplied verification and printing callables. This lets users validate their custom node data during the same walk and print richer information when errors occur.
> 
> Everything is implemented via template parameters with set defaults, so existing code remains unchanged while new code can opt in to the expanded functionality.
> 
> Testing:
> - Oracle tiers 1-3

src/hotspot/share/gc/z/zMappedCache.cpp line 121:

> 119: }
> 120: 
> 121: bool ZMappedCache::EntryCompare::less(const IntrusiveRBNode* a, const IntrusiveRBNode* b) {

I feel `less_than` sounds more natural as a method name; it also avoids "conflicting" with `RBTreeOrdering::less`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26981#discussion_r2306853612

From cnorrbin at openjdk.org  Thu Aug 28 09:58:43 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Thu, 28 Aug 2025 09:58:43 GMT
Subject: RFR: 8366238: Improve RBTree API with stricter comparator
 semantics and pluggable validation/printing hooks. [v2]
In-Reply-To: <xBBv_Un-GHPOs_Ri3_1aop840xjcQpScyPXOJZ31kjo=.57eec1fc-d4ce-4b05-bff5-b9851f496503@github.com>
References: <xBBv_Un-GHPOs_Ri3_1aop840xjcQpScyPXOJZ31kjo=.57eec1fc-d4ce-4b05-bff5-b9851f496503@github.com>
Message-ID: <FVr1vsTudWLVkei7kmou5fmYEhfglVAb5_BcwUKK0hM=.f5a65b5b-70b5-4042-9c2a-ea6b5c66a4ec@github.com>

> Hi everyone,
> 
> The current red-black tree can be made safer, and its inspection capabilities improved.
> 
> As briefly discussed in #26904, `COMPARATOR::cmp` could be made clearer and more robust. In particular, its `int` return type invites unsafe `return a ? b` arithmetic, and the boolean validation function also named `cmp` is misleading.
> 
> To address this, I?ve introduced the `RBTreeOrdering` enum, inspired by C++20?s `<=>`, which makes incorrect arithmetic impossible. The return type of `COMPARATOR::cmp` is now this enum, forcing users to write an explicit and safe comparison. From the discussion in that PR, I have also renamed the boolean `cmp` to `less`, making its purpose obvious and preventing confusion between the two functions.
> 
> Inspection has also been improved, especially for intrusive trees. Previously, `verify_self` only verified core RB-tree properties, yet intrusive nodes often hold additional data with their own separate invariants. Users had to perform those checks in a second traversal, and if an error occurs `print_on` produced little diagnostic value by only printing node addresses.
> 
> To solve this, the tree now accepts user-supplied verification and printing callables. This lets users validate their custom node data during the same walk and print richer information when errors occur.
> 
> Everything is implemented via template parameters with set defaults, so existing code remains unchanged while new code can opt in to the expanded functionality.
> 
> Testing:
> - Oracle tiers 1-3

Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:

  renamed less to less_than

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26981/files
  - new: https://git.openjdk.org/jdk/pull/26981/files/f386a71e..9dd20dbe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26981&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26981&range=00-01

  Stats: 16 lines in 5 files changed: 0 ins; 0 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/26981.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26981/head:pull/26981

PR: https://git.openjdk.org/jdk/pull/26981

From cnorrbin at openjdk.org  Thu Aug 28 09:58:44 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Thu, 28 Aug 2025 09:58:44 GMT
Subject: RFR: 8366238: Improve RBTree API with stricter comparator
 semantics and pluggable validation/printing hooks. [v2]
In-Reply-To: <Kob0t0RZEeCTqyenzGKuVaQoPqTQBX2xJOZCWaTDs1k=.f2d5d88c-0c3a-4e43-a650-5ee82b2f2a94@github.com>
References: <xBBv_Un-GHPOs_Ri3_1aop840xjcQpScyPXOJZ31kjo=.57eec1fc-d4ce-4b05-bff5-b9851f496503@github.com>
 <Kob0t0RZEeCTqyenzGKuVaQoPqTQBX2xJOZCWaTDs1k=.f2d5d88c-0c3a-4e43-a650-5ee82b2f2a94@github.com>
Message-ID: <iB4WD8AgFlp4Gx8RucDsOPaE8uxP5OaTgQ1lXbLZMH4=.4d8d5472-4874-45d3-a0ba-c8a2af55a798@github.com>

On Thu, 28 Aug 2025 09:40:48 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   renamed less to less_than
>
> src/hotspot/share/gc/z/zMappedCache.cpp line 121:
> 
>> 119: }
>> 120: 
>> 121: bool ZMappedCache::EntryCompare::less(const IntrusiveRBNode* a, const IntrusiveRBNode* b) {
> 
> I feel `less_than` sounds more natural as a method name; it also avoids "conflicting" with `RBTreeOrdering::less`.

Sounds like a good suggestion, done now in 9dd20db

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26981#discussion_r2306891336

From azafari at openjdk.org  Thu Aug 28 10:20:53 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 28 Aug 2025 10:20:53 GMT
Subject: RFR: 8366062: [ubsan] add non-zero offset to nullptr in
 cds/archiveBuilder.cpp
Message-ID: <ThshPn4opNV4ChF_608Q4tqu9XvRlPSR7poud_untM4=.cfac66ce-af53-476c-a5bf-fe1833f49166@github.com>

It is acceptable that the `SharedBaseAddress` option gets `0` at command line. The corresponding pointer arithmetic with `0` (`nullptr`) in archiveBuilder is UB.
Specific casts are used to avoid UBSAN error.

Tests:
linux-x64-debug: tier1 passed

-------------

Commit messages:
 - 8366062: [ubsan] add non-zero offset to nullptr in cds/archiveBuilder.cpp

Changes: https://git.openjdk.org/jdk/pull/26983/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26983&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366062
  Stats: 12 lines in 1 file changed: 6 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/26983.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26983/head:pull/26983

PR: https://git.openjdk.org/jdk/pull/26983

From ayang at openjdk.org  Thu Aug 28 10:35:43 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 28 Aug 2025 10:35:43 GMT
Subject: RFR: 8366238: Improve RBTree API with stricter comparator
 semantics and pluggable validation/printing hooks. [v2]
In-Reply-To: <FVr1vsTudWLVkei7kmou5fmYEhfglVAb5_BcwUKK0hM=.f5a65b5b-70b5-4042-9c2a-ea6b5c66a4ec@github.com>
References: <xBBv_Un-GHPOs_Ri3_1aop840xjcQpScyPXOJZ31kjo=.57eec1fc-d4ce-4b05-bff5-b9851f496503@github.com>
 <FVr1vsTudWLVkei7kmou5fmYEhfglVAb5_BcwUKK0hM=.f5a65b5b-70b5-4042-9c2a-ea6b5c66a4ec@github.com>
Message-ID: <-pgUZmzHmnazmnTdH40tHVdveyOASGCTsaO7I5-PnTo=.d7dac9e8-9601-4ede-a696-fd144f68d107@github.com>

On Thu, 28 Aug 2025 09:58:43 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> The current red-black tree can be made safer, and its inspection capabilities improved.
>> 
>> As briefly discussed in #26904, `COMPARATOR::cmp` could be made clearer and more robust. In particular, its `int` return type invites unsafe `return a ? b` arithmetic, and the boolean validation function also named `cmp` is misleading.
>> 
>> To address this, I?ve introduced the `RBTreeOrdering` enum, inspired by C++20?s `<=>`, which makes incorrect arithmetic impossible. The return type of `COMPARATOR::cmp` is now this enum, forcing users to write an explicit and safe comparison. From the discussion in that PR, I have also renamed the boolean `cmp` to `less`, making its purpose obvious and preventing confusion between the two functions.
>> 
>> Inspection has also been improved, especially for intrusive trees. Previously, `verify_self` only verified core RB-tree properties, yet intrusive nodes often hold additional data with their own separate invariants. Users had to perform those checks in a second traversal, and if an error occurs `print_on` produced little diagnostic value by only printing node addresses.
>> 
>> To solve this, the tree now accepts user-supplied verification and printing callables. This lets users validate their custom node data during the same walk and print richer information when errors occur.
>> 
>> Everything is implemented via template parameters with set defaults, so existing code remains unchanged while new code can opt in to the expanded functionality.
>> 
>> Testing:
>> - Oracle tiers 1-3
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   renamed less to less_than

I noticed that in one place


(parent_cmp <= 0 && hint_cmp < 0)

becomes

(parent_cmp != RBTreeOrdering::greater && hint_cmp == RBTreeOrdering::less)


I wonder if compare-result can have some helper apis so that the new code looks like

(parent_cmp.is_less_equal() && hint_cmp.is_less())


Can't say for sure one is definitely better than the other; just throwing out some ideas.

src/hotspot/share/nmt/vmatree.hpp line 56:

> 54:       if (a < b) return RBTreeOrdering::less;
> 55:       if (a == b) return RBTreeOrdering::equal;
> 56:       if (a > b) return RBTreeOrdering::greater;

Preexisting: no need for 3 `if`s, can be identical to the impl in `printinlining.hpp`.

src/hotspot/share/utilities/rbTree.hpp line 217:

> 215: 
> 216:   template <typename CMP>
> 217:   static constexpr bool HasNodeVerifier = has_less_type<CMP, bool, const NodeType*, const NodeType*>::value;

Does this need to be `has_less_than_type`?

-------------

PR Review: https://git.openjdk.org/jdk/pull/26981#pullrequestreview-3164179820
PR Review Comment: https://git.openjdk.org/jdk/pull/26981#discussion_r2306922430
PR Review Comment: https://git.openjdk.org/jdk/pull/26981#discussion_r2306982476

From cnorrbin at openjdk.org  Thu Aug 28 11:21:00 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Thu, 28 Aug 2025 11:21:00 GMT
Subject: RFR: 8366238: Improve RBTree API with stricter comparator
 semantics and pluggable validation/printing hooks. [v3]
In-Reply-To: <xBBv_Un-GHPOs_Ri3_1aop840xjcQpScyPXOJZ31kjo=.57eec1fc-d4ce-4b05-bff5-b9851f496503@github.com>
References: <xBBv_Un-GHPOs_Ri3_1aop840xjcQpScyPXOJZ31kjo=.57eec1fc-d4ce-4b05-bff5-b9851f496503@github.com>
Message-ID: <9p4A1E9arftDmwBvVfAMxnqbvBUZ9heQ4jbYXeEowrw=.76647921-46a2-4be2-9c7a-f19b167a71e9@github.com>

> Hi everyone,
> 
> The current red-black tree can be made safer, and its inspection capabilities improved.
> 
> As briefly discussed in #26904, `COMPARATOR::cmp` could be made clearer and more robust. In particular, its `int` return type invites unsafe `return a ? b` arithmetic, and the boolean validation function also named `cmp` is misleading.
> 
> To address this, I?ve introduced the `RBTreeOrdering` enum, inspired by C++20?s `<=>`, which makes incorrect arithmetic impossible. The return type of `COMPARATOR::cmp` is now this enum, forcing users to write an explicit and safe comparison. From the discussion in that PR, I have also renamed the boolean `cmp` to `less`, making its purpose obvious and preventing confusion between the two functions.
> 
> Inspection has also been improved, especially for intrusive trees. Previously, `verify_self` only verified core RB-tree properties, yet intrusive nodes often hold additional data with their own separate invariants. Users had to perform those checks in a second traversal, and if an error occurs `print_on` produced little diagnostic value by only printing node addresses.
> 
> To solve this, the tree now accepts user-supplied verification and printing callables. This lets users validate their custom node data during the same walk and print richer information when errors occur.
> 
> Everything is implemented via template parameters with set defaults, so existing code remains unchanged while new code can opt in to the expanded functionality.
> 
> Testing:
> - Oracle tiers 1-3

Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:

  albert feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26981/files
  - new: https://git.openjdk.org/jdk/pull/26981/files/9dd20dbe..f780a53e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26981&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26981&range=01-02

  Stats: 5 lines in 2 files changed: 0 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/26981.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26981/head:pull/26981

PR: https://git.openjdk.org/jdk/pull/26981

From cnorrbin at openjdk.org  Thu Aug 28 11:34:43 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Thu, 28 Aug 2025 11:34:43 GMT
Subject: RFR: 8366238: Improve RBTree API with stricter comparator
 semantics and pluggable validation/printing hooks. [v2]
In-Reply-To: <-pgUZmzHmnazmnTdH40tHVdveyOASGCTsaO7I5-PnTo=.d7dac9e8-9601-4ede-a696-fd144f68d107@github.com>
References: <xBBv_Un-GHPOs_Ri3_1aop840xjcQpScyPXOJZ31kjo=.57eec1fc-d4ce-4b05-bff5-b9851f496503@github.com>
 <FVr1vsTudWLVkei7kmou5fmYEhfglVAb5_BcwUKK0hM=.f5a65b5b-70b5-4042-9c2a-ea6b5c66a4ec@github.com>
 <-pgUZmzHmnazmnTdH40tHVdveyOASGCTsaO7I5-PnTo=.d7dac9e8-9601-4ede-a696-fd144f68d107@github.com>
Message-ID: <R319eYfQbdcFZQiD1T3MYZBoOCBo8HNAsVRiwP4WfQU=.099f0617-3ed9-4c21-b0e4-154dce574f04@github.com>

On Thu, 28 Aug 2025 10:32:41 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   renamed less to less_than
>
> I noticed that in one place
> 
> 
> (parent_cmp <= 0 && hint_cmp < 0)
> 
> becomes
> 
> (parent_cmp != RBTreeOrdering::greater && hint_cmp == RBTreeOrdering::less)
> 
> 
> I wonder if compare-result can have some helper apis so that the new code looks like
> 
> (parent_cmp.is_less_equal() && hint_cmp.is_less())
> 
> 
> Can't say for sure one is definitely better than the other; just throwing out some ideas.

Thank you for the review @albertnetymk.
> I wonder if compare-result can have some helper apis so that the new code looks like
> 
> ```
> (parent_cmp.is_less_equal() && hint_cmp.is_less())
> ```

Unfortunately, we can't add helpers directly to the `enum class`, so we'd have to either
1. Wrap it in another struct or class, or
2. Add a separate set of functions (e.g. `is_less(order)` or `is_less_equal(order)`)

Either option introduces extra code for something that's only used internally in the tree in a couple of places. For now, the explicit comparisons is (to me) readable enough, so I'd prefer to keep it as is.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26981#issuecomment-3233127699

From dholmes at openjdk.org  Thu Aug 28 12:51:44 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 28 Aug 2025 12:51:44 GMT
Subject: RFR: 8353468: [ubsan] arguments.cpp:2422:23: runtime error:
 2.14748e+11 is outside the range of representable values of type 'int' [v3]
In-Reply-To: <WJ9Y5fZlgXvViZWRCFoDCQNeQ7zvcTtdHPyqt2AFxxw=.8ca2e476-1945-4897-a287-4b4b17446113@github.com>
References: <plQ5n7EjsekIjeY431_mBeo4rfcH39SVdPWogF2rT44=.20180c89-665e-4054-8625-1b04f8306b3b@github.com>
 <x2XW0ywYSy-9Tqh-Mzrhd3X1o8MTo5rADg48p92rpDo=.a3e4e6cf-ce98-48c7-b90d-cfa22b130e54@github.com>
 <w1yU1ZStrSKCR70pg-WegpafHrscV7XjFub3mVfgsbM=.52f36820-1a8e-4cc2-9e9d-7a2030ebcde6@github.com>
 <c_sFYToa5A4s8wP6JXAWVPzSsTHAwmp1-LjImMdYdI0=.06deac44-abcd-4ec8-a0dc-3d4aad8458c0@github.com>
 <WJ9Y5fZlgXvViZWRCFoDCQNeQ7zvcTtdHPyqt2AFxxw=.8ca2e476-1945-4897-a287-4b4b17446113@github.com>
Message-ID: <MHgmvLb0Ja7SH-kQ25vSdcUZsqmCgehlxH887Q9K2Hc=.e05f1c8d-dc26-4b8d-8516-6fa870aec2b6@github.com>

On Thu, 28 Aug 2025 07:58:41 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> This is exactly the source of confusion. User is allowed to enter `double` values in range `[0.0, 1.0]`, but the value is multiplied by 100 and stored in a `uintx`.
>> Using hard-coded constants `MinHeapFreeRatio ` and `MaxHeapFreeRatio` in the error message is as expected by tests.
>> These two flags have already constraint functions as `MinHeapFreeRatioConstraintFunc` and `MaxHeapFreeRatioConstraintFunc` where minf <= maxf is checked.
>> Checking the user input to be in [0.0, 1.0] cannot be done in the constraint functions, since the original input is missed due to * 100 and casting to uintx.
>
> I agree with David's comment here. The suggestion is to explicitly pre-check that Xminf/Xmaxf falls within [0.0, 1.0], just so that the constraint functions for MinHeapFreeRatio and MaxHeapFreeRatio *don't* trigger and give confusing messages. [edited]

Exactly. The way these flags are currently handled is a mess. Given how they are used to set the other flags they need to be pre-checked for validity before being used by the other constraint function - because as you note by then it is too late as we already did the multiplcation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26859#discussion_r2307316555

From mbaesken at openjdk.org  Thu Aug 28 12:57:44 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 28 Aug 2025 12:57:44 GMT
Subject: RFR: 8364352: Some tests fail when using a limited number of
 pregenerated .jsa CDS archives
In-Reply-To: <EnyzXiapmd29T3spHQT7QTBv2SVQVKVU6L2NEDoejHg=.65f803f7-09e0-4e5b-ac21-a60474c5facd@github.com>
References: <EnyzXiapmd29T3spHQT7QTBv2SVQVKVU6L2NEDoejHg=.65f803f7-09e0-4e5b-ac21-a60474c5facd@github.com>
Message-ID: <qO0HVeaWEDzLK0butbukXRWq6M5Sl73dmTBqzCZB3L4=.37d3d348-cd5a-4650-ae57-104c1582b2f7@github.com>

On Mon, 18 Aug 2025 11:34:28 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently the default JVM comes on most platforms with 4 jsa files (for coops and nocoops; with and without compressed object headers), but for some shipments the number of jsa could be reduced (see also Images.gmk) .
> But not all tests can deal with this.
> Namely
> 
> test/hotspot/jtreg/runtime/CompressedOops/CompressedCPUSpecificClassSpaceReservation.java
> test/hotspot/jtreg/runtime/cds/TestDefaultArchiveLoading.java
> test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java (custom-cl-zgc)
> 
> were found to have issues.
> There is already a requires  `vm.cds.default.archive.available`   that is used in similar tests and can be used in some of those cases too.

So should I add  `vm.cds.nocoops.archive.available` for the  DynamicLoaderConstraintsTest.java test ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26820#issuecomment-3233391689

From dholmes at openjdk.org  Thu Aug 28 13:06:45 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 28 Aug 2025 13:06:45 GMT
Subject: RFR: 8366232: JFR startup messages are shown with
 -Xlog:jfr+startup=warning
In-Reply-To: <nmzMdCujz2lrDkT_owCBAlK-s_tpo2QEivFPL7fnZ5A=.3cf87678-ad16-47d5-9401-39987c0f90c9@github.com>
References: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
 <nmzMdCujz2lrDkT_owCBAlK-s_tpo2QEivFPL7fnZ5A=.3cf87678-ad16-47d5-9401-39987c0f90c9@github.com>
Message-ID: <DWf13_qW6ZElDVuy_IE8e3F1t6wzH8idAQkAV3lvb2Q=.58c915cd-9d2f-424f-ae08-b1aff5684690@github.com>

On Thu, 28 Aug 2025 08:22:05 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> The original issue was [JDK-8244190](https://bugs.openjdk.org/browse/JDK-8244190), this PR just fixes a short-coming of the implementation. 

Okay in the original JBS issue I wrote:

> How about you mark the output for jfr+startup info logging and have StartFlightRecording enable that logging level if not explicitly disabled? That way the output is the same, no other output is affected and the user can still turn it off if needed. I'm just not sure we have a way to query if the logging level has been explicitly set to a given value. 

But what got implemented was not what I had in mind - nor, I think,  is the adjustment you propose here. What I intended was along the lines of:

log_info(jfr, startup)("The startup message");

and then in the logic that starts JFR something like:

if (!log_is_enabled_on_stdout(info, jfr startup)
  Log::Configuration( /* enable jfr+startup on stdout */)

Though checking if it is enabled on stdout may be the tricky part. This was recognised in the original PR:

> I have chosen to implement 5. It's not perfect, but perhaps sufficient for now? 

but you also have to allow for it being turned off explicitly by the user.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26957#issuecomment-3233422789

From jbechberger at openjdk.org  Thu Aug 28 13:18:44 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 28 Aug 2025 13:18:44 GMT
Subject: RFR: 8366232: JFR startup messages are shown with
 -Xlog:jfr+startup=warning
In-Reply-To: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
References: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
Message-ID: <KJqwnWdQWsrYiVjMx_phP9rDmnLhOezEQVtTHZO1XBE=.d331fca6-49fd-4ac5-a6e0-3bb83dcb6ec2@github.com>

On Wed, 27 Aug 2025 12:07:54 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Only print the JFR startup messages when no or a < warning log level is set explicitly by the user.

But isn't my PR closer to what the user expects? When you explicitly set the level to `warning`, no `info` level messages should be printed

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26957#issuecomment-3233467744

From ayang at openjdk.org  Thu Aug 28 13:21:47 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 28 Aug 2025 13:21:47 GMT
Subject: RFR: 8366238: Improve RBTree API with stricter comparator
 semantics and pluggable validation/printing hooks. [v3]
In-Reply-To: <9p4A1E9arftDmwBvVfAMxnqbvBUZ9heQ4jbYXeEowrw=.76647921-46a2-4be2-9c7a-f19b167a71e9@github.com>
References: <xBBv_Un-GHPOs_Ri3_1aop840xjcQpScyPXOJZ31kjo=.57eec1fc-d4ce-4b05-bff5-b9851f496503@github.com>
 <9p4A1E9arftDmwBvVfAMxnqbvBUZ9heQ4jbYXeEowrw=.76647921-46a2-4be2-9c7a-f19b167a71e9@github.com>
Message-ID: <l6EtCjGAw3qAeFikEprg1LRInXwfcSDPYchSy5zeCQo=.92a2d1f4-9995-4ad9-85d3-ad7bf3d10daa@github.com>

On Thu, 28 Aug 2025 11:21:00 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> The current red-black tree can be made safer, and its inspection capabilities improved.
>> 
>> As briefly discussed in #26904, `COMPARATOR::cmp` could be made clearer and more robust. In particular, its `int` return type invites unsafe `return a ? b` arithmetic, and the boolean validation function also named `cmp` is misleading.
>> 
>> To address this, I?ve introduced the `RBTreeOrdering` enum, inspired by C++20?s `<=>`, which makes incorrect arithmetic impossible. The return type of `COMPARATOR::cmp` is now this enum, forcing users to write an explicit and safe comparison. From the discussion in that PR, I have also renamed the boolean `cmp` to `less`, making its purpose obvious and preventing confusion between the two functions.
>> 
>> Inspection has also been improved, especially for intrusive trees. Previously, `verify_self` only verified core RB-tree properties, yet intrusive nodes often hold additional data with their own separate invariants. Users had to perform those checks in a second traversal, and if an error occurs `print_on` produced little diagnostic value by only printing node addresses.
>> 
>> To solve this, the tree now accepts user-supplied verification and printing callables. This lets users validate their custom node data during the same walk and print richer information when errors occur.
>> 
>> Everything is implemented via template parameters with set defaults, so existing code remains unchanged while new code can opt in to the expanded functionality.
>> 
>> Testing:
>> - Oracle tiers 1-3
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   albert feedback

Marked as reviewed by ayang (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26981#pullrequestreview-3164838757

From syan at openjdk.org  Thu Aug 28 14:02:44 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 28 Aug 2025 14:02:44 GMT
Subject: RFR: 8362087: Test containers/docker/ShareTmpDir.java intermittent
 fails [v2]
In-Reply-To: <0BdxR-lfZCypbrUa9jLchYXsLzDSkpdsRGRzALTH-Fg=.98f03a75-664c-4f20-9b2c-be9b61393638@github.com>
References: <oSRNcbnXITyxH_EsCblndmwkjMgKFN0FOpeJ-HzEd7g=.2288123c-f4e6-42e9-87d9-2b0741f06335@github.com>
 <0BdxR-lfZCypbrUa9jLchYXsLzDSkpdsRGRzALTH-Fg=.98f03a75-664c-4f20-9b2c-be9b61393638@github.com>
Message-ID: <FOldsXBf4Fk5PmIE-u7tu89C1tPpmLT5qtNszt9I2FQ=.a6ef8a32-0e85-4f07-b11f-3d2332ec520c@github.com>

On Sun, 3 Aug 2025 12:43:42 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> The test containers/docker/ShareTmpDir.java intermittent fails, because before this PR, test assume start two java process in docker container by two threads will make the two java process start simultancely, but in fact, the second java process maybe start slower than the first one, even that the first java process already exit and then the second java process not start yet. If we add `Thread.sleep(2000)` to the second thread at the begin of run() method, will make this intermittent failure to always reproduceable. This prove the anasyis.
>> 
>> If the two java process can not start simultancely, the expected '/tmp/hsperfdata_1 locked' error can not observed. So this test will intermittent fails.
>> 
>> This PR will check all the two java processes started already and runing simultancely before exit, this will make the expected '/tmp/hsperfdata_1 locked' error can be alway observed.
>> 
>> The touch file test/hotspot/jtreg/containers/docker/WaitForFlagFile.java only use for test containers/docker/ShareTmpDir.java.
>> 
>> Change has been verified locally, test-fix only, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add synchronized lock for addClassOptions

Looking reviewers.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26605#issuecomment-3233623261

From dholmes at openjdk.org  Fri Aug 29 01:58:46 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 29 Aug 2025 01:58:46 GMT
Subject: RFR: 8366232: JFR startup messages are shown with
 -Xlog:jfr+startup=warning
In-Reply-To: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
References: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
Message-ID: <G8xjjyKWSViKoKoobA--pfHMy9XkU7jjunQEoL1mWqM=.2f48ba9a-93ef-4a10-9105-3c18a1395e1c@github.com>

On Wed, 27 Aug 2025 12:07:54 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Only print the JFR startup messages when no or a < warning log level is set explicitly by the user.

Functionally yes, but I'm just not sure about the mechanism. Need to think more about it. This reminds me of the flag complexity: FLAG_IS_DEFAULT, FLAG_IS_CMDLINE etc.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26957#issuecomment-3235455737

From dholmes at openjdk.org  Fri Aug 29 02:13:45 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 29 Aug 2025 02:13:45 GMT
Subject: RFR: 8303612:
 runtime/StackGuardPages/TestStackGuardPagesNative.java fails with exit code
 139
In-Reply-To: <v3Ju1h_P2bt1bhqcaio_xDWLllKDuH4raHjRPSeLZSo=.787a9271-2c05-48a8-847c-72e2b247ab43@github.com>
References: <oRl4abf8ZV5qD9GNScJMRwwZD2PkdiDGJykDFs1Cmgo=.8c961e33-291f-4ba1-b494-ad5eab7ee72c@github.com>
 <blniq87ptY1r2ZSL2nR17MV-SHTmPOPcAPWRgCVqL24=.b011371a-c54e-4fd9-b25b-19e22c321d3f@github.com>
 <lJRJpcHQe1HHoiDFbTwWZo13-3BhpMq4uwFNegBJ1ww=.1ccda972-41a1-4373-baba-c9f0a0e1795f@github.com>
 <v3Ju1h_P2bt1bhqcaio_xDWLllKDuH4raHjRPSeLZSo=.787a9271-2c05-48a8-847c-72e2b247ab43@github.com>
Message-ID: <9OlbWKyTFOYpZccYUTpm3A9s9J626Ru0oIUVdowRgmo=.e12cefae-b53f-47a2-9433-4c2b9c9f7f7d@github.com>

On Thu, 28 Aug 2025 07:44:20 GMT, mazhen <duke at openjdk.org> wrote:

> I believe this approach resolves both the original crash and the subsequent hang.

I agree this continues to fix the problem seen with the recursive approach. I also agree it should fix the CentOS hang.

However, I do not see how this will address the actual failure that is reported in JBS for this issue:

Testing NATIVE_OVERFLOW
Testing stack guard page behaviour for other thread
run_native_overflow 1281626
Got SIGSEGV(2) at address: 0xffff8daf3fa0
Test PASSED. Got access violation accessing guard page at 7983
Test PASSED. Not initial thread
];
 stderr: []
 exitValue = 139

The JBS connections and timeline is very hard to follow, but I believe this failure was seen after the hardening fix had been applied.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25689#issuecomment-3235481263

From dholmes at openjdk.org  Fri Aug 29 05:58:42 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 29 Aug 2025 05:58:42 GMT
Subject: RFR: 8364816: GetLastError() in os_windows.cpp should not store
 value to errno [v5]
In-Reply-To: <ZQvXHrE9ooQIVRp5hZQpME39EQ9fUJJGoE8rGH5zUx8=.0baf2490-f2fe-4d87-8a4b-2cf3a043802b@github.com>
References: <-kp4UVOCqF0ZxITA-Rra0t7rWXXC0wLvAnO3OwchPkU=.7873481b-991a-429e-9b4c-9f2c68fec48f@github.com>
 <ZQvXHrE9ooQIVRp5hZQpME39EQ9fUJJGoE8rGH5zUx8=.0baf2490-f2fe-4d87-8a4b-2cf3a043802b@github.com>
Message-ID: <hVmxZYsZAZVEy5nm5kxhw0P_NZ9jt2PcEjdVzRuGAKY=.d377f1c3-5bad-4ead-819c-b68e8dc8a293@github.com>

On Thu, 28 Aug 2025 09:19:48 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> In `os_windows.cpp` in a few places results returned by `GetLastError()` are stored to `errno`. However, `errno` has no relation to `GetLastError()`, and their ranges are not the same.
>> 
>> Results of `GetLastError()` should be stored into variables of type `DWORD`.
>> 
>> The removed section in `src/hotspot/share/cds/aotClassLocation.cpp` was relying on values returned by `GetLastError()` and stored to `errno` in `os::stat()`. Though the logic was correct, these values should not be stored to `errno`. The functionality is preserved by storing a **valid** value `ENOENT` to `errno` in `os::stat()`. 
>> 
>> Tested in tiers 1 - 3.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8364816: Fixed _wopen case.

One more tweak sorry.

src/hotspot/os/windows/os_windows.cpp line 5034:

> 5032:   // if opening files failed, errno has been set to indicate the problem
> 5033:   if (fd == -1) {
> 5034:     log_debug(os)("os::open() failed to _wopen: errno->%ld.", errno);

Suggestion:

    log_debug(os)("os::open() failed to _wopen: errno->%s.", strerror(errno));

-------------

PR Review: https://git.openjdk.org/jdk/pull/26901#pullrequestreview-3167459928
PR Review Comment: https://git.openjdk.org/jdk/pull/26901#discussion_r2309219515

From dholmes at openjdk.org  Fri Aug 29 06:02:42 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 29 Aug 2025 06:02:42 GMT
Subject: RFR: 8364352: Some tests fail when using a limited number of
 pregenerated .jsa CDS archives
In-Reply-To: <qO0HVeaWEDzLK0butbukXRWq6M5Sl73dmTBqzCZB3L4=.37d3d348-cd5a-4650-ae57-104c1582b2f7@github.com>
References: <EnyzXiapmd29T3spHQT7QTBv2SVQVKVU6L2NEDoejHg=.65f803f7-09e0-4e5b-ac21-a60474c5facd@github.com>
 <qO0HVeaWEDzLK0butbukXRWq6M5Sl73dmTBqzCZB3L4=.37d3d348-cd5a-4650-ae57-104c1582b2f7@github.com>
Message-ID: <OARz6zd6ufUewm72f9uH0Da9Vcur2ux79GJCRWNK-go=.f49c7b55-bada-47c6-b4c0-06d4cc9508f0@github.com>

On Thu, 28 Aug 2025 12:55:06 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> So should I add `vm.cds.nocoops.archive.available` for the DynamicLoaderConstraintsTest.java test ?

That seems reasonable

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26820#issuecomment-3235821493

From mbaesken at openjdk.org  Fri Aug 29 08:04:22 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 29 Aug 2025 08:04:22 GMT
Subject: RFR: 8366420: AOTMapTest fails when jsa is missing
Message-ID: <lNWjshdsRvOaNqHJp-zR-fVNBV7JL263IP2GOuSsmDw=.e866422e-b7ab-437d-9974-f4013dc9ac54@github.com>

We fail in one of our test setups with this output :
runtime/cds/appcds/aotCache/AOTMapTest_dynamic


 stdout: [[0.003s][error][cds] An error has occurred while processing the shared archive file. Run with -Xlog:aot,cds for details.
[0.003s][error][cds] Specified shared archive file not found (AOTMapTestApp.dynamic.jsa)
[0.003s][error][cds] Not a valid shared archive file (AOTMapTestApp.dynamic.jsa)
[0.003s][error][cds] CDS is incompatible with other specified options.
Error occurred during initialization of VM
Unable to use shared archive: invalid archive
];
 stderr: []
 exitValue = 1

java.lang.RuntimeException: Expected to get exit value of [0], exit value is: [1]
at jdk.test.lib.process.OutputAnalyzer.shouldHaveExitValue(OutputAnalyzer.java:522)
at jdk.test.lib.cds.CDSAppTester.executeAndCheck(CDSAppTester.java:217)
at jdk.test.lib.cds.CDSAppTester.productionRun(CDSAppTester.java:426)
at jdk.test.lib.cds.CDSAppTester.productionRun(CDSAppTester.java:393)
at jdk.test.lib.cds.CDSAppTester.runDynamicWorkflow(CDSAppTester.java:464)
at jdk.test.lib.cds.CDSAppTester.run(CDSAppTester.java:445)
at AOTMapTest.doTest(AOTMapTest.java:71)
at AOTMapTest.main(AOTMapTest.java:61)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
at java.base/java.lang.reflect.Method.invoke(Method.java:565)
at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
at java.base/java.lang.Thread.run(Thread.java:1474)


This test setup is a bit special because it contains only one jsa cds archive (the one for compressed object headers).  So the  'classes.jsa' is missing .

-------------

Commit messages:
 - JDK-8366420

Changes: https://git.openjdk.org/jdk/pull/27001/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27001&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366420
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27001.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27001/head:pull/27001

PR: https://git.openjdk.org/jdk/pull/27001

From duke at openjdk.org  Fri Aug 29 08:50:05 2025
From: duke at openjdk.org (Anton Artemov)
Date: Fri, 29 Aug 2025 08:50:05 GMT
Subject: RFR: 8364816: GetLastError() in os_windows.cpp should not store
 value to errno [v6]
In-Reply-To: <-kp4UVOCqF0ZxITA-Rra0t7rWXXC0wLvAnO3OwchPkU=.7873481b-991a-429e-9b4c-9f2c68fec48f@github.com>
References: <-kp4UVOCqF0ZxITA-Rra0t7rWXXC0wLvAnO3OwchPkU=.7873481b-991a-429e-9b4c-9f2c68fec48f@github.com>
Message-ID: <l0Sb8ystdCPoDocOKaVfD9UOcQGyhzEmPgv1DrIHYd8=.03b1a1d3-afda-4f29-89e5-9c5966cf17d9@github.com>

> Hi, please consider the following changes:
> 
> In `os_windows.cpp` in a few places results returned by `GetLastError()` are stored to `errno`. However, `errno` has no relation to `GetLastError()`, and their ranges are not the same.
> 
> Results of `GetLastError()` should be stored into variables of type `DWORD`.
> 
> The removed section in `src/hotspot/share/cds/aotClassLocation.cpp` was relying on values returned by `GetLastError()` and stored to `errno` in `os::stat()`. Though the logic was correct, these values should not be stored to `errno`. The functionality is preserved by storing a **valid** value `ENOENT` to `errno` in `os::stat()`. 
> 
> Tested in tiers 1 - 3.

Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:

  8364816: Addressed reviewer's comment.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26901/files
  - new: https://git.openjdk.org/jdk/pull/26901/files/f8f3632a..e920baff

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26901&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26901&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26901.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26901/head:pull/26901

PR: https://git.openjdk.org/jdk/pull/26901

From duke at openjdk.org  Fri Aug 29 08:50:06 2025
From: duke at openjdk.org (Anton Artemov)
Date: Fri, 29 Aug 2025 08:50:06 GMT
Subject: RFR: 8364816: GetLastError() in os_windows.cpp should not store
 value to errno [v5]
In-Reply-To: <hVmxZYsZAZVEy5nm5kxhw0P_NZ9jt2PcEjdVzRuGAKY=.d377f1c3-5bad-4ead-819c-b68e8dc8a293@github.com>
References: <-kp4UVOCqF0ZxITA-Rra0t7rWXXC0wLvAnO3OwchPkU=.7873481b-991a-429e-9b4c-9f2c68fec48f@github.com>
 <ZQvXHrE9ooQIVRp5hZQpME39EQ9fUJJGoE8rGH5zUx8=.0baf2490-f2fe-4d87-8a4b-2cf3a043802b@github.com>
 <hVmxZYsZAZVEy5nm5kxhw0P_NZ9jt2PcEjdVzRuGAKY=.d377f1c3-5bad-4ead-819c-b68e8dc8a293@github.com>
Message-ID: <z7ykVamfUr5lRqJBSoaT-igqi7aEVB7InPgsLZRVKxM=.debfba5a-13ce-4a47-b86a-d3bdfaecad1d@github.com>

On Fri, 29 Aug 2025 05:54:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8364816: Fixed _wopen case.
>
> src/hotspot/os/windows/os_windows.cpp line 5034:
> 
>> 5032:   // if opening files failed, errno has been set to indicate the problem
>> 5033:   if (fd == -1) {
>> 5034:     log_debug(os)("os::open() failed to _wopen: errno->%ld.", errno);
> 
> Suggestion:
> 
>     log_debug(os)("os::open() failed to _wopen: errno->%s.", strerror(errno));

Changed as suggested.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26901#discussion_r2309572930

From mbaesken at openjdk.org  Fri Aug 29 08:53:58 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 29 Aug 2025 08:53:58 GMT
Subject: RFR: 8364352: Some tests fail when using a limited number of
 pregenerated .jsa CDS archives [v2]
In-Reply-To: <EnyzXiapmd29T3spHQT7QTBv2SVQVKVU6L2NEDoejHg=.65f803f7-09e0-4e5b-ac21-a60474c5facd@github.com>
References: <EnyzXiapmd29T3spHQT7QTBv2SVQVKVU6L2NEDoejHg=.65f803f7-09e0-4e5b-ac21-a60474c5facd@github.com>
Message-ID: <Xuzh1fL3NTf7-vzskqt6Ydo3YctSBgUfRpeuVmLX68c=.16e09f2e-d0cb-44f1-bf83-447919b37e86@github.com>

> Currently the default JVM comes on most platforms with 4 jsa files (for coops and nocoops; with and without compressed object headers), but for some shipments the number of jsa could be reduced (see also Images.gmk) .
> But not all tests can deal with this.
> Namely
> 
> test/hotspot/jtreg/runtime/CompressedOops/CompressedCPUSpecificClassSpaceReservation.java
> test/hotspot/jtreg/runtime/cds/TestDefaultArchiveLoading.java
> test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java (custom-cl-zgc)
> 
> were found to have issues.
> There is already a requires  `vm.cds.default.archive.available`   that is used in similar tests and can be used in some of those cases too.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Add vm.cds.nocoops.archive.available

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26820/files
  - new: https://git.openjdk.org/jdk/pull/26820/files/5c34851f..567b8148

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26820&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26820&range=00-01

  Stats: 13 lines in 3 files changed: 12 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26820.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26820/head:pull/26820

PR: https://git.openjdk.org/jdk/pull/26820

From mbaesken at openjdk.org  Fri Aug 29 09:04:44 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 29 Aug 2025 09:04:44 GMT
Subject: RFR: 8364352: Some tests fail when using a limited number of
 pregenerated .jsa CDS archives
In-Reply-To: <OARz6zd6ufUewm72f9uH0Da9Vcur2ux79GJCRWNK-go=.f49c7b55-bada-47c6-b4c0-06d4cc9508f0@github.com>
References: <EnyzXiapmd29T3spHQT7QTBv2SVQVKVU6L2NEDoejHg=.65f803f7-09e0-4e5b-ac21-a60474c5facd@github.com>
 <qO0HVeaWEDzLK0butbukXRWq6M5Sl73dmTBqzCZB3L4=.37d3d348-cd5a-4650-ae57-104c1582b2f7@github.com>
 <OARz6zd6ufUewm72f9uH0Da9Vcur2ux79GJCRWNK-go=.f49c7b55-bada-47c6-b4c0-06d4cc9508f0@github.com>
Message-ID: <XrNxu6zbMwyYKu0JLdvLDghgcH5ixWqrGt5RMII464s=.75caec65-4db9-4ff9-b5a6-435db5115903@github.com>

On Fri, 29 Aug 2025 06:00:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > So should I add `vm.cds.nocoops.archive.available` for the DynamicLoaderConstraintsTest.java test ?
> 
> That seems reasonable


Great , I introduced a new 'requires' tag .

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26820#issuecomment-3236282914

From duke at openjdk.org  Fri Aug 29 10:48:45 2025
From: duke at openjdk.org (mazhen)
Date: Fri, 29 Aug 2025 10:48:45 GMT
Subject: RFR: 8303612:
 runtime/StackGuardPages/TestStackGuardPagesNative.java fails with exit code
 139
In-Reply-To: <9OlbWKyTFOYpZccYUTpm3A9s9J626Ru0oIUVdowRgmo=.e12cefae-b53f-47a2-9433-4c2b9c9f7f7d@github.com>
References: <oRl4abf8ZV5qD9GNScJMRwwZD2PkdiDGJykDFs1Cmgo=.8c961e33-291f-4ba1-b494-ad5eab7ee72c@github.com>
 <blniq87ptY1r2ZSL2nR17MV-SHTmPOPcAPWRgCVqL24=.b011371a-c54e-4fd9-b25b-19e22c321d3f@github.com>
 <lJRJpcHQe1HHoiDFbTwWZo13-3BhpMq4uwFNegBJ1ww=.1ccda972-41a1-4373-baba-c9f0a0e1795f@github.com>
 <v3Ju1h_P2bt1bhqcaio_xDWLllKDuH4raHjRPSeLZSo=.787a9271-2c05-48a8-847c-72e2b247ab43@github.com>
 <9OlbWKyTFOYpZccYUTpm3A9s9J626Ru0oIUVdowRgmo=.e12cefae-b53f-47a2-9433-4c2b9c9f7f7d@github.com>
Message-ID: <Qe64G4wBe0LoQ6Y8U192XDP6nbe5EJBR5GDdawVspP4=.ed336f5f-40bf-45fe-88e9-a764c2e7352a@github.com>

On Fri, 29 Aug 2025 02:11:19 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > I believe this approach resolves both the original crash and the subsequent hang.
> 
> I agree this continues to fix the problem seen with the recursive approach. I also agree it should fix the CentOS hang.
> 
> However, I do not see how this will address the actual failure that is reported in JBS for this issue:
> 
> Testing NATIVE_OVERFLOW Testing stack guard page behaviour for other thread run_native_overflow 1281626 Got SIGSEGV(2) at address: 0xffff8daf3fa0 Test PASSED. Got access violation accessing guard page at 7983 Test PASSED. Not initial thread ]; stderr: [] exitValue = 139
> 
> The JBS connections and timeline is very hard to follow, but I believe this failure was seen after the hardening fix had been applied.

Thank you for your patience and for pointing out the discrepancy. You were absolutely right to question how my PR addressed the failure mode in the JBS issue. After re-evaluating everything, I realize I have made a mistake and confused two separate issues. I sincerely apologize for the noise and for taking up your valuable time.

Let me clarify what happened. The JBS issue associated with this PR, `JDK-8303612`, describes a failure where the `Not initial thread` test passes but the process exits with `code 139`.

However, the problem I have been trying to solve is a **timeout hang** that occurs specifically in the **`"initial thread"`** scenario. 

My investigation started when I encountered this hang while running the `jdk17u` test suite on CentOS 7. The test timing out and ultimately reporting an error led me to incorrectly associate my hang with JDK-8303612, as on the surface they appeared to be related failures.

To confirm this, I re-ran the tests from the jdk17u repository on my CentOS 7 environment today. The relevant `TestStackGuardPagesNative.jtr` output is:


[2025-08-29T06:47:50.718385554Z] Gathering output for process 29415
[2025-08-29T06:47:50.741718596Z] Waiting for completion for process 29415
[2025-08-29T06:47:50.826107509Z] Waiting for completion finished for process 29415
Output and diagnostic info for process 29415 was saved into 'pid-29415-output.log'
[2025-08-29T06:47:50.833637359Z] Gathering output for process 29434
[2025-08-29T06:47:50.834255494Z] Waiting for completion for process 29434
[2025-08-29T06:56:22.496916196Z] Waiting for completion finished for process 29434
Output and diagnostic info for process 29434 was saved into 'pid-29434-output.log'
STDERR:
 stdout: [Test started with pid: 29434
Java thread is alive.
];
 stderr: []
 exitValue = 134

java.lang.RuntimeException: Expected to get exit value of [0]

	at jdk.test.lib.process.OutputAnalyzer.shouldHaveExitValue(OutputAnalyzer.java:504)
	at TestStackGuardPagesNative.main(TestStackGuardPagesNative.java:49)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335)
	at java.base/java.lang.Thread.run(Thread.java:840)

JavaTest Message: Test threw exception: java.lang.RuntimeException
JavaTest Message: shutting down test


TEST RESULT: Error. "main" action timed out with a timeout of 480 seconds on agent 2


The logs confirm that the `Not initial thread` test (`pid-29415`) completes successfully, while the `"initial thread"` test (`pid-29434`) hangs until the test harness kills it.

This is fundamentally different from the teardown crash described in `JDK-8303612`. 

Again, my apologies for the confusion I've caused. I will take some more time to reconsider the best path forward. If I cannot find a way to contribute that cleanly addresses a well-defined issue, it would be better to maintain the status quo.

Thank you again for your time and guidance.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25689#issuecomment-3236601589

From azafari at openjdk.org  Fri Aug 29 13:46:28 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 29 Aug 2025 13:46:28 GMT
Subject: RFR: 8353468: [ubsan] arguments.cpp:2422:23: runtime error:
 2.14748e+11 is outside the range of representable values of type 'int' [v4]
In-Reply-To: <plQ5n7EjsekIjeY431_mBeo4rfcH39SVdPWogF2rT44=.20180c89-665e-4054-8625-1b04f8306b3b@github.com>
References: <plQ5n7EjsekIjeY431_mBeo4rfcH39SVdPWogF2rT44=.20180c89-665e-4054-8625-1b04f8306b3b@github.com>
Message-ID: <KlKYfOCdt3BRQzlumgqblAec2VV9oJnt9bZ_ca8Nb_c=.bde9b177-a8ac-4043-b363-3225b89a7674@github.com>

> In converting values of `-XMinf` and `-XMaxf` options to `int`, overflow was not checked. 
> The values are checked against INT_MAX and clamped.
> 
> Tests: tiers 1-5.

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  improved tests and messages.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26859/files
  - new: https://git.openjdk.org/jdk/pull/26859/files/87e0b8d9..7f18f689

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26859&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26859&range=02-03

  Stats: 59 lines in 2 files changed: 46 ins; 5 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/26859.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26859/head:pull/26859

PR: https://git.openjdk.org/jdk/pull/26859

From iklam at openjdk.org  Fri Aug 29 18:08:42 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 29 Aug 2025 18:08:42 GMT
Subject: RFR: 8366420: AOTMapTest fails when jsa is missing
In-Reply-To: <lNWjshdsRvOaNqHJp-zR-fVNBV7JL263IP2GOuSsmDw=.e866422e-b7ab-437d-9974-f4013dc9ac54@github.com>
References: <lNWjshdsRvOaNqHJp-zR-fVNBV7JL263IP2GOuSsmDw=.e866422e-b7ab-437d-9974-f4013dc9ac54@github.com>
Message-ID: <iNi92sOkar5HvRH1lYT5oj-1snavDLY0AwV4kdSF4T8=.b4e62b6d-b540-4bd5-ab0d-e946a3224088@github.com>

On Fri, 29 Aug 2025 07:58:29 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We fail in one of our test setups with this output :
> runtime/cds/appcds/aotCache/AOTMapTest_dynamic
> 
> 
>  stdout: [[0.003s][error][cds] An error has occurred while processing the shared archive file. Run with -Xlog:aot,cds for details.
> [0.003s][error][cds] Specified shared archive file not found (AOTMapTestApp.dynamic.jsa)
> [0.003s][error][cds] Not a valid shared archive file (AOTMapTestApp.dynamic.jsa)
> [0.003s][error][cds] CDS is incompatible with other specified options.
> Error occurred during initialization of VM
> Unable to use shared archive: invalid archive
> ];
>  stderr: []
>  exitValue = 1
> 
> java.lang.RuntimeException: Expected to get exit value of [0], exit value is: [1]
> at jdk.test.lib.process.OutputAnalyzer.shouldHaveExitValue(OutputAnalyzer.java:522)
> at jdk.test.lib.cds.CDSAppTester.executeAndCheck(CDSAppTester.java:217)
> at jdk.test.lib.cds.CDSAppTester.productionRun(CDSAppTester.java:426)
> at jdk.test.lib.cds.CDSAppTester.productionRun(CDSAppTester.java:393)
> at jdk.test.lib.cds.CDSAppTester.runDynamicWorkflow(CDSAppTester.java:464)
> at jdk.test.lib.cds.CDSAppTester.run(CDSAppTester.java:445)
> at AOTMapTest.doTest(AOTMapTest.java:71)
> at AOTMapTest.main(AOTMapTest.java:61)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> at java.base/java.lang.reflect.Method.invoke(Method.java:565)
> at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
> at java.base/java.lang.Thread.run(Thread.java:1474)
> 
> 
> This test setup is a bit special because it contains only one jsa cds archive (the one for compressed object headers).  So the  'classes.jsa' is missing .

LGTM
(test fixs require only one reviewer)

-------------

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27001#pullrequestreview-3169622354

From jsjolen at openjdk.org  Fri Aug 29 18:56:53 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 29 Aug 2025 18:56:53 GMT
Subject: RFR: 8366363: MemBaseline accesses VMT without using lock
Message-ID: <EHr9P4Umy5YwrMVvcg7LOXp3Dp40jn2VZCAH1HiNxtU=.dc674737-8696-4d82-9852-3f1828320aa7@github.com>

Hi,

The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead.

-------------

Commit messages:
 - Remove now unused iterator
 - Use a copied VMATree instead of a LinkedList

Changes: https://git.openjdk.org/jdk/pull/27003/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366363
  Stats: 140 lines in 10 files changed: 75 ins; 44 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/27003.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27003/head:pull/27003

PR: https://git.openjdk.org/jdk/pull/27003

From jsjolen at openjdk.org  Fri Aug 29 19:04:41 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 29 Aug 2025 19:04:41 GMT
Subject: RFR: 8366363: MemBaseline accesses VMT without using lock
In-Reply-To: <EHr9P4Umy5YwrMVvcg7LOXp3Dp40jn2VZCAH1HiNxtU=.dc674737-8696-4d82-9852-3f1828320aa7@github.com>
References: <EHr9P4Umy5YwrMVvcg7LOXp3Dp40jn2VZCAH1HiNxtU=.dc674737-8696-4d82-9852-3f1828320aa7@github.com>
Message-ID: <-Z6DWW-tqahqtLzZt0ULHvFrTwL3uINZemJFO2OivhA=.0d918002-6ea9-4330-a97a-4b36521b7ab5@github.com>

On Fri, 29 Aug 2025 12:13:57 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead.

src/hotspot/share/utilities/rbTree.hpp line 454:

> 452: public:
> 453:   RBTree() : BaseType(), _allocator() {}
> 454:   RBTree(const RBTree& other) : BaseType(), _allocator() {

@caspernorrbin , I added this. Does it look correct?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27003#discussion_r2310890005

From lgxbslgx at gmail.com  Sat Aug 30 10:40:39 2025
From: lgxbslgx at gmail.com (Guoxiong Li)
Date: Sat, 30 Aug 2025 18:40:39 +0800
Subject: [Question] The property `vm.gc` in jtreg test
Message-ID: <CAPSsVqjD_hdYUFZd1z4z56RY5jNwfmpaQerEspmroVqf+oeBtw@mail.gmail.com>

Hi all,

I notice the meaning of the test property `vm.gc` is not clear.
The method `VMProps::vmGCforCDS` (shown below, in directory:
test/jtreg-ext/requires/VMProps.java)
extracts the property `vm.gc` from the option `test.cds.runtime.options`.
So the current `vm.gc` is about both CDS and GC, not only the GC.
I propose changing the current test property name `vm.gc` to `vm.gc.cds` or
`vm.cds.gc`.

Waiting for your opinion. Any ideas will be appreciated.

```java
    /**
     * "jtreg -vmoptions:-Dtest.cds.runtime.options=..." can be used to
specify
     * the GC type to be used when running with a CDS archive. Set "vm.gc"
accordingly,
     * so that tests that need to explicitly choose the GC type can be
excluded
     * with "@requires vm.gc == null".
     *
     * @param map - property-value pairs
     */
    protected void vmGCforCDS(SafeMap map) {
        if (!GC.isSelectedErgonomically()) {
            // The GC has been explicitly specified on the command line, so
            // jtreg will set the "vm.gc" property. Let's not interfere
with it.
            return;
        }

        String jtropts = System.getProperty("test.cds.runtime.options");
        if (jtropts != null) {
            for (String opt : jtropts.split(",")) {
                if (opt.startsWith(GC_PREFIX) && opt.endsWith(GC_SUFFIX)) {
                    String gc = opt.substring(GC_PREFIX.length(),
opt.length() - GC_SUFFIX.length());
                    map.put("vm.gc", () -> gc);
                }
            }
        }
    }
```

Best Regards,
-- Guoxiong
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-runtime-dev/attachments/20250830/76668247/attachment.htm>

From chen.l.liang at oracle.com  Sat Aug 30 13:43:34 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Sat, 30 Aug 2025 13:43:34 +0000
Subject: [Question] The property `vm.gc` in jtreg test
In-Reply-To: <CAPSsVqjD_hdYUFZd1z4z56RY5jNwfmpaQerEspmroVqf+oeBtw@mail.gmail.com>
References: <CAPSsVqjD_hdYUFZd1z4z56RY5jNwfmpaQerEspmroVqf+oeBtw@mail.gmail.com>
Message-ID: <SJ2PR10MB7669E4E8E980EA5FE277FD5DA205A@SJ2PR10MB7669.namprd10.prod.outlook.com>

Hello, I don't think this is as harmful as you have assumed.

The way CDS tests work (taking runtime/cds/appcds/aotCache/HelloAOTCache.java for example) is that the tests themselves are just drivers to execute jar applications (because CDS only works for jar applications). test.cds.runtime.options system property is only provided when running customized runtime/cds tests so flags can be passed to child vms, and all those tests anticipate vm.gc to indicate the gc for the child vm spawned by the driver.

In conclusion, I don't think a rename would be necessary, as I don't see a scenario where the driver itself would care about its own gc in addition to the child process gc.

CC'ing Ioi as Ioi is the main CDS area maintainer.

Chen
________________________________
From: hotspot-dev <hotspot-dev-retn at openjdk.org> on behalf of Guoxiong Li <lgxbslgx at gmail.com>
Sent: Saturday, August 30, 2025 5:40 AM
To: hotspot-gc-dev at openjdk.org <hotspot-gc-dev at openjdk.org>; hotspot-runtime-dev at openjdk.org <hotspot-runtime-dev at openjdk.org>; hotspot-dev at openjdk.org <hotspot-dev at openjdk.org>
Subject: [Question] The property `vm.gc` in jtreg test

Hi all,

I notice the meaning of the test property `vm.gc` is not clear.
The method `VMProps::vmGCforCDS` (shown below, in directory: test/jtreg-ext/requires/VMProps.java)
extracts the property `vm.gc` from the option `test.cds.runtime.options`.
So the current `vm.gc` is about both CDS and GC, not only the GC.
I propose changing the current test property name `vm.gc` to `vm.gc.cds` or `vm.cds.gc`.

Waiting for your opinion. Any ideas will be appreciated.

```java
    /**
     * "jtreg -vmoptions:-Dtest.cds.runtime.options=..." can be used to specify
     * the GC type to be used when running with a CDS archive. Set "vm.gc" accordingly,
     * so that tests that need to explicitly choose the GC type can be excluded
     * with "@requires vm.gc == null".
     *
     * @param map - property-value pairs
     */
    protected void vmGCforCDS(SafeMap map) {
        if (!GC.isSelectedErgonomically()) {
            // The GC has been explicitly specified on the command line, so
            // jtreg will set the "vm.gc" property. Let's not interfere with it.
            return;
        }

        String jtropts = System.getProperty("test.cds.runtime.options");
        if (jtropts != null) {
            for (String opt : jtropts.split(",")) {
                if (opt.startsWith(GC_PREFIX) && opt.endsWith(GC_SUFFIX)) {
                    String gc = opt.substring(GC_PREFIX.length(), opt.length() - GC_SUFFIX.length());
                    map.put("vm.gc", () -> gc);
                }
            }
        }
    }
```

Best Regards,
-- Guoxiong
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-runtime-dev/attachments/20250830/413dd8c9/attachment-0001.htm>

From duke at openjdk.org  Sun Aug 31 03:53:31 2025
From: duke at openjdk.org (Saint Wesonga)
Date: Sun, 31 Aug 2025 03:53:31 GMT
Subject: RFR: 8366483: ShowRegistersOnAssertTest uses wrong register pattern
 string for Windows on AArch64
Message-ID: <V28OqhZx6dxbkVwiRMWnFDSy1jbOkZxPfRmOuXx9fQU=.47be71b3-36da-4e03-b898-bc37594ce90d@github.com>

ShowRegistersOnAssertTest.java verifies that registers are printed in the error log when VMError::controlled_crash() is called. However, it searches for the pattern "R0=", which is valid on Linux AArch64 only. The Windows AArch64 [os::print_context](https://github.com/openjdk/jdk/blob/999761d0f6d37c9cd6ec482620800b694c5fb9ad/src/hotspot/os_cpu/windows_aarch64/os_windows_aarch64.cpp#L184-L186) implementation outputs registers in the format "X0 =". This change updates the test to use this pattern on the Windows AArch64 platform. The test passes with this change.

-------------

Commit messages:
 - Fix register matching string on Windows

Changes: https://git.openjdk.org/jdk/pull/27022/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27022&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366483
  Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27022.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27022/head:pull/27022

PR: https://git.openjdk.org/jdk/pull/27022