From coleenp at openjdk.org  Tue Jul  1 01:55:48 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 1 Jul 2025 01:55:48 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v12]
In-Reply-To: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
Message-ID: <6WPU5dGPFJ38KnDO88FvRIqQsclgmajiQ2RRKVm0ZCw=.3575812c-b388-42e6-8396-8c39162b6dc0@github.com>

> I copied this code for another test in the Valhalla repo and thought it would be a good utility function.  It might be better written using the Classfile API.
> Tested with test.

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

  Remove comment.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25857/files
  - new: https://git.openjdk.org/jdk/pull/25857/files/791f2146..9b704274

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

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

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

From coleenp at openjdk.org  Tue Jul  1 01:55:50 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 1 Jul 2025 01:55:50 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v11]
In-Reply-To: <h2U4wRTcEbLKV7Mve5iO6KOEee5t47ald41NEZxvfug=.abffc9dc-9e2d-4f4b-82e1-177654a56ced@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
 <mIHdl4_tc3bd4M13BlvV2CPjgZafZ7Yn5c7ohmCA7W4=.89aada01-a41a-47ed-a1ab-0c593cd45187@github.com>
 <h2U4wRTcEbLKV7Mve5iO6KOEee5t47ald41NEZxvfug=.abffc9dc-9e2d-4f4b-82e1-177654a56ced@github.com>
Message-ID: <Cxv_fFTrSmcEW1VjG-SsnTvsOb-Q3XZynHGJgAV-BZ8=.0d81cc8e-f2b1-4be8-a85e-d5caa8d4ddf1@github.com>

On Mon, 30 Jun 2025 23:26:17 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Update test/lib/RedefineClassHelper.java
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>>  - Update test/lib/RedefineClassHelper.java
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>>  - Update test/lib/RedefineClassHelper.java
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>
> test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/ClassVersionAfterRedefine.java line 45:
> 
>> 43:         ClassVersionAfterRedefine cvar = new ClassVersionAfterRedefine();
>> 44: 
>> 45:         // Poor man's renaming of class "TestClassOld" to "TestClassXXX"
> 
> It is not "poor man's" renaming anymore and RedefineClassHelper.replaceClassName() is self-explanable. So this comment could be just removed.

Okay.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2176243389

From dholmes at openjdk.org  Tue Jul  1 02:33:42 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 1 Jul 2025 02:33:42 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v12]
In-Reply-To: <6WPU5dGPFJ38KnDO88FvRIqQsclgmajiQ2RRKVm0ZCw=.3575812c-b388-42e6-8396-8c39162b6dc0@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
 <6WPU5dGPFJ38KnDO88FvRIqQsclgmajiQ2RRKVm0ZCw=.3575812c-b388-42e6-8396-8c39162b6dc0@github.com>
Message-ID: <kyFAicDYK1jfNdAsl2EDcdpARdZ6lhixLq47NoalRoY=.b18fe183-9728-4431-8908-0acb1f7db6ea@github.com>

On Tue, 1 Jul 2025 01:55:48 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I copied this code for another test in the Valhalla repo and thought it would be a good utility function.  It might be better written using the Classfile API.
>> Tested with test.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove comment.

LGTM!

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25857#pullrequestreview-2973299545

From dholmes at openjdk.org  Tue Jul  1 03:49:37 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 1 Jul 2025 03:49:37 GMT
Subject: RFR: 8361085: MemoryReserver log_on_large_pages_failure has
 incorrect format usage
In-Reply-To: <tyRBtI09kU7Aq3AwA3afRqiY0G73NDdasXmY784vs9U=.ac18eea9-1235-47e2-ad92-11e3efa650a9@github.com>
References: <tyRBtI09kU7Aq3AwA3afRqiY0G73NDdasXmY784vs9U=.ac18eea9-1235-47e2-ad92-11e3efa650a9@github.com>
Message-ID: <IO9l3QlvqdxFwrn4lsBCMFCN_xMptLr6x34v56Dte2U=.5915bdd9-d210-4c30-977b-e8a64ea9dd28@github.com>

On Mon, 30 Jun 2025 16:11:47 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this fix of an incorrect format usage.
> 
> The function calls `jio_snprintf` to format a message into a buffer. That
> message includes printing a pointer using `PTR_FORMAT`, but isn't using the
> `p2i` helper function. Fixing that is just a matter of using that helper.
> 
> However, there's no need to use `jio_snprintf` here, as the resulting message
> is then just passed to `warning`, which can handle output formatting directly.
> So we also move the formatting to the `warning` call, and remove the use of
> `jio_snprintf`. Note that calling `warning` without the `p2i` would have
> produced a compiler warning about the incorrect format usage.
> 
> Testing: mach5 tier1

Looks good.

It is strange that this pattern of doing a warning used to be used in a few places, even though `warning` has always been able to handle the formatting directly.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26050#pullrequestreview-2973378738

From mbaesken at openjdk.org  Tue Jul  1 07:43:41 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 1 Jul 2025 07:43:41 GMT
Subject: RFR: 8361043: [ubsan] os::print_hex_dump runtime error: applying
 non-zero offset 8 to null pointer
In-Reply-To: <ip2gRSkLuiZO_KF9NiTAQKSdtE6Y7JcsPXrk2aK_opo=.84f83db5-cfcd-4ae4-8def-3301a1fa20c9@github.com>
References: <_4x8AWT92UYqk8EnSmkl0esIdl9-0N99eOcRgjBlqwU=.316ac846-8072-449c-a147-2b8bf41e950b@github.com>
 <ip2gRSkLuiZO_KF9NiTAQKSdtE6Y7JcsPXrk2aK_opo=.84f83db5-cfcd-4ae4-8def-3301a1fa20c9@github.com>
Message-ID: <8c_aCipQXr4ZyZavqXXO-D57-6puH5X7Tya-cxie894=.892f061d-fa99-43d2-acdf-d6a353e0219f@github.com>

On Mon, 30 Jun 2025 08:14:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Forcing unsigned arithmetic doesn't seem right if `unitsize` is a signed int - it will work here as `unitsize` is always positive, but it looks weird to me. Does this compile okay on all platforms e.g. Windows?

Yes it compiles on all our platforms, including  MSVC 2022 .

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26037#discussion_r2176677378

From tschatzl at openjdk.org  Tue Jul  1 08:18:44 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 1 Jul 2025 08:18:44 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v12]
In-Reply-To: <9THM_-ewp6IHKihx_AAHi2AjhG86B9tD7IvqtUIxUe8=.501655a3-77d4-4996-a340-9141bbf25154@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <9THM_-ewp6IHKihx_AAHi2AjhG86B9tD7IvqtUIxUe8=.501655a3-77d4-4996-a340-9141bbf25154@github.com>
Message-ID: <37GU6UtugGvR3iwskdw2iFYJbXOI_CjN4T-tL7QKgZw=.0082a838-7941-4522-b88a-13911888bedb@github.com>

On Mon, 30 Jun 2025 15:58:07 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
>> 
>> 
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>> 
>> 
>> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
>> 
>> 
>> [1.500s][trace][gc] Process CPU time: 4.945370s
>> [1.500s][trace][gc] GC CPU time: 0.086382s
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>
> Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update closure name
>  - vtime -> cpu_time and _vm_vtime -> _vmthread_cpu_time

Changes requested by tschatzl (Reviewer).

src/hotspot/os/posix/os_posix.cpp line 1603:

> 1601: }
> 1602: 
> 1603: double os::elapsed_process_cpu_time() {

I am kind of conflicted about returning a rounded value (`double`) in that method. There does not seem to be a good reason to not just return the `ns` (integer) value and only do the rounding when presenting the value.

Sorry for not noticing earlier, it's just that recently I did that other change in that area, and the unnecessary effort (and rounding) has been an issue there as well.

src/hotspot/share/gc/shared/collectedHeap.cpp line 630:

> 628:     double process_cpu_time = os::elapsed_process_cpu_time();
> 629:     double gc_cpu_time = elapsed_gc_cpu_time();
> 630:     double string_dedup_cpu_time = UseStringDeduplication ? os::thread_cpu_time((Thread*)StringDedup::_processor->_thread) / NANOSECS_PER_SEC : 0;

Just for the record, this is a truncating integer divsion. I do not think this is expected here.

src/hotspot/share/gc/shared/collectedHeap.hpp line 247:

> 245:   virtual void stop() = 0;
> 246: 
> 247:   void before_exit();

Now that there is the `before_exit()` method, and `stop()` never called from outside, please make the latter `protected`.
Also, there is no need to make this method virtual any more imo. This could save the three empty overrides (but I can see that one might want to make this abstract for OO pureness). Whatever your decision is here, please change the visibility of `stop()`.

src/hotspot/share/gc/shared/collectedHeap.hpp line 253:

> 251:   virtual void safepoint_synchronize_end() {}
> 252: 
> 253:   static jlong vm_cpu_time();

This declaration does not have an implementation (and there is none needed). Please remove.

src/hotspot/share/runtime/os.hpp line 296:

> 294:   static jlong elapsed_frequency();
> 295: 
> 296:   static double elapsed_process_cpu_time();

Not sure if it is required that these methods return their values as `double`s in seconds. Given the uses, this seems unnecessary premature loss of precision.

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

PR Review: https://git.openjdk.org/jdk/pull/25779#pullrequestreview-2973827814
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2176692619
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2176602981
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2176701530
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2176705157
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2176605695

From shade at openjdk.org  Tue Jul  1 08:27:48 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 1 Jul 2025 08:27:48 GMT
Subject: RFR: 8359436: AOTCompileEagerly should not be diagnostic [v3]
In-Reply-To: <RcWV9llRY3iUBIsOk_IaF_cabIE59ZaX13FMYHm-m4s=.57a612aa-eddf-48fe-8d09-b38add8ec93c@github.com>
References: <dZEQ6cAv4KJjRLjmBDzqX0KPMDjmcbb9e--zVFx6B2g=.bf626b98-f39a-4955-b8e7-8f6c5dc14d09@github.com>
 <WgxZZjwz5aQhYltjeUuEMK07_H7KtWQrjbibeDj_X1U=.7b4bb5a5-fa1f-4182-a94e-b95c53824e70@github.com>
 <RcWV9llRY3iUBIsOk_IaF_cabIE59ZaX13FMYHm-m4s=.57a612aa-eddf-48fe-8d09-b38add8ec93c@github.com>
Message-ID: <Jf2cUTYXFF-cMl20lnQN30xhSQ1R3UDeCLvgZiETazo=.a9a59309-f618-4dfe-b277-e4bd0aa78e13@github.com>

On Wed, 25 Jun 2025 17:39:37 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Thanks! I think I am going to wait for JDK 25 enhancement request to be approved first.

Still waiting... Do I need to ask someone directly to review it?

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

PR Comment: https://git.openjdk.org/jdk/pull/25799#issuecomment-3022583200

From tschatzl at openjdk.org  Tue Jul  1 09:10:45 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 1 Jul 2025 09:10:45 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v12]
In-Reply-To: <37GU6UtugGvR3iwskdw2iFYJbXOI_CjN4T-tL7QKgZw=.0082a838-7941-4522-b88a-13911888bedb@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <9THM_-ewp6IHKihx_AAHi2AjhG86B9tD7IvqtUIxUe8=.501655a3-77d4-4996-a340-9141bbf25154@github.com>
 <37GU6UtugGvR3iwskdw2iFYJbXOI_CjN4T-tL7QKgZw=.0082a838-7941-4522-b88a-13911888bedb@github.com>
Message-ID: <jEBx8vDaTY-FxkRPJRjplZhmiBn6LXyeH5YgAxhTBrc=.b58df2bf-b8ba-421e-a55c-ab5b57ea6532@github.com>

On Tue, 1 Jul 2025 07:45:58 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update closure name
>>  - vtime -> cpu_time and _vm_vtime -> _vmthread_cpu_time
>
> src/hotspot/os/posix/os_posix.cpp line 1603:
> 
>> 1601: }
>> 1602: 
>> 1603: double os::elapsed_process_cpu_time() {
> 
> I am kind of conflicted about returning a rounded value (`double`) in that method. There does not seem to be a good reason to not just return the `ns` (integer) value and only do the rounding when presenting the value.
> 
> Sorry for not noticing earlier, it's just that recently I did that other change in that area, and the unnecessary effort (and rounding) has been an issue there as well.

Another thought I had was whether the `elapsed` prefix is actually necessary - all cpu times are since thread/process start.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2176935618

From mbaesken at openjdk.org  Tue Jul  1 09:22:44 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 1 Jul 2025 09:22:44 GMT
Subject: Integrated: 8361043: [ubsan] os::print_hex_dump runtime error:
 applying non-zero offset 8 to null pointer
In-Reply-To: <_4x8AWT92UYqk8EnSmkl0esIdl9-0N99eOcRgjBlqwU=.316ac846-8072-449c-a147-2b8bf41e950b@github.com>
References: <_4x8AWT92UYqk8EnSmkl0esIdl9-0N99eOcRgjBlqwU=.316ac846-8072-449c-a147-2b8bf41e950b@github.com>
Message-ID: <Ud-2MEWaVC0oCp78m-R2hwS02hN-h52LMjAK2Tt7r8Q=.7297e914-a6b6-4ade-af8f-17ff4c67d3d8@github.com>

On Mon, 30 Jun 2025 07:49:45 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running jtreg test
> runtime/cds/DeterministicDump
> with ubsan-enabled binaries (opt) on macOS aarch64, the following issue is reported :
> 
> 
> /jdk/src/hotspot/share/runtime/os.cpp:1045:15: runtime error: applying non-zero offset 8 to null pointer
>     #0 0x106156ad4 in os::print_hex_dump(outputStream*, unsigned char const*, unsigned char const*, int, bool, int, unsigned char const*, unsigned char const*) os.cpp:1045
>     #1 0x10524685c in ArchiveBuilder::CDSMapLogger::log(ArchiveBuilder*, FileMapInfo*, ArchiveHeapInfo*, char*, unsigned long) archiveBuilder.cpp:1573
>     #2 0x105245e60 in ArchiveBuilder::write_archive(FileMapInfo*, ArchiveHeapInfo*) archiveBuilder.cpp:1634
>     #3 0x106084fd4 in MetaspaceShared::write_static_archive(ArchiveBuilder*, FileMapInfo*, ArchiveHeapInfo*) metaspaceShared.cpp:1053
>     #4 0x10608411c in MetaspaceShared::preload_and_dump_impl(StaticArchiveBuilder&, JavaThread*) metaspaceShared.cpp:1030
>     #5 0x1060837b8 in MetaspaceShared::preload_and_dump(JavaThread*) metaspaceShared.cpp:812
>     #6 0x10660457c in Threads::create_vm(JavaVMInitArgs*, bool*) threads.cpp:892
>     #7 0x105ca60dc in JNI_CreateJavaVM jni.cpp:3680
>     #8 0x100fbe4d0 in JavaMain java.c:494
>     #9 0x100fc54fc in ThreadJavaMain java_md_macosx.m:679
>     #10 0x197372f90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90)
>     #11 0x19736dd30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30)

This pull request has now been integrated.

Changeset: 54c95cf2
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/54c95cf2261f871c47b3700ede31390c8f5e77dd
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8361043: [ubsan] os::print_hex_dump runtime error: applying non-zero offset 8 to null pointer

Reviewed-by: mdoerr, lucy

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

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

From duke at openjdk.org  Tue Jul  1 09:35:43 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Tue, 1 Jul 2025 09:35:43 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v12]
In-Reply-To: <37GU6UtugGvR3iwskdw2iFYJbXOI_CjN4T-tL7QKgZw=.0082a838-7941-4522-b88a-13911888bedb@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <9THM_-ewp6IHKihx_AAHi2AjhG86B9tD7IvqtUIxUe8=.501655a3-77d4-4996-a340-9141bbf25154@github.com>
 <37GU6UtugGvR3iwskdw2iFYJbXOI_CjN4T-tL7QKgZw=.0082a838-7941-4522-b88a-13911888bedb@github.com>
Message-ID: <k9TPvCuyHrJKpUGAOa_TPI_GxG8IUl6zjBPm_EyRNss=.3dfba520-d6cd-44d6-9965-4a0bdb7e63d8@github.com>

On Tue, 1 Jul 2025 07:08:45 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update closure name
>>  - vtime -> cpu_time and _vm_vtime -> _vmthread_cpu_time
>
> src/hotspot/share/runtime/os.hpp line 296:
> 
>> 294:   static jlong elapsed_frequency();
>> 295: 
>> 296:   static double elapsed_process_cpu_time();
> 
> Not sure if it is required that these methods return their values as `double`s in seconds. Given the uses, this seems unnecessary premature loss of precision.

It is not required, but I was conforming to the same type as the methods that was removed in JDK-8274051 and as well as `elapsedTime()`. `elapsedTime()` returns the wall-clock time in seconds since start in `double`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2177009372

From duke at openjdk.org  Tue Jul  1 09:48:59 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Tue, 1 Jul 2025 09:48:59 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v13]
In-Reply-To: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
Message-ID: <81zhYMzwafmk-EFXUn2z0ZUdjVTvjJUr_v9aXI8Hq2g=.8f8edc4c-488a-4452-818f-457305f52bb1@github.com>

> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
> 
> 
> [1.500s][info ][gc] GC CPU cost: 1.75%
> 
> 
> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
> 
> 
> [1.500s][trace][gc] Process CPU time: 4.945370s
> [1.500s][trace][gc] GC CPU time: 0.086382s
> [1.500s][info ][gc] GC CPU cost: 1.75%

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

  Make stop protected, remove integer divison, remove unused method

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25779/files
  - new: https://git.openjdk.org/jdk/pull/25779/files/35a74668..38841dc9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=11-12

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

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

From mhaessig at openjdk.org  Tue Jul  1 11:27:49 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Tue, 1 Jul 2025 11:27:49 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v9]
In-Reply-To: <V1R7QX7ECR-b4R9RafrckOzaQCZZlSOBvHqaixwEQcY=.8aef5d9b-5df2-40f6-b9d6-107f580fe907@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <V1R7QX7ECR-b4R9RafrckOzaQCZZlSOBvHqaixwEQcY=.8aef5d9b-5df2-40f6-b9d6-107f580fe907@github.com>
Message-ID: <U2pkrbJtCOAswOM9iXx8kEf2FQuQZDgedCpf0ZHreh0=.f519ca6c-aa4a-465b-9e11-825c9071afc8@github.com>

On Mon, 23 Jun 2025 19:26:11 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier.
>> 
>> We used to patch the verified entry point to make sure it was not_entrant.  The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler.  The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant.  We can do the same thing with a permanently armed nmethod entry barrier.
>> 
>> The solution I went with reserves one bit of the entry barrier guard value.  This bit must remain set, so I call it a "sticky" bit.  Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it.  The alternative would be to change the platform-specific code to do compare-and-swap.
>> 
>> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic.  For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod().  I suspect we could do the same for Shenandoah, if needed for performance.
>> 
>> This change also makes it a bit clearer that  the nmethod entry barrier effectively has two levels.  Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier().  This could be generalized if we decide we need more flavors of entry barriers.  The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels.
>
> Dean Long has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Merge branch 'master' into 8358821-patch-verified-entry
>  - 2nd try at arm fix
>  - rename arm_with to guard_with
>  - arm32 fix
>  - s390 fix courtesy of Amit Kumar
>  - remove is_sigill_not_entrant
>  - more cleanup
>  - more TheRealMDoerr suggestions
>  - TheRealMDoerr suggestions
>  - remove trailing space
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/6df0f5e3...a39c458c

Backing out #24831 sounds reasonable to me.

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

PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-3023516324

From duke at openjdk.org  Tue Jul  1 12:03:08 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Tue, 1 Jul 2025 12:03:08 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v14]
In-Reply-To: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
Message-ID: <M1X3PxWm8q4auPjWq_sOczcVrUWLTuxB7Oog8X27SDU=.f824afa5-4204-4dbe-979a-c1249a33d3dc@github.com>

> Add support to log CPU cost for GC during VM exit with `-Xlog:gc+cpu`.
> 
> 
> [1.563s][info][gc,cpu] GC CPU usage: 42.26%

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

  Change output per discussion

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25779/files
  - new: https://git.openjdk.org/jdk/pull/25779/files/38841dc9..3104ff6a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=12-13

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

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

From tschatzl at openjdk.org  Tue Jul  1 13:10:41 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 1 Jul 2025 13:10:41 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v14]
In-Reply-To: <M1X3PxWm8q4auPjWq_sOczcVrUWLTuxB7Oog8X27SDU=.f824afa5-4204-4dbe-979a-c1249a33d3dc@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <M1X3PxWm8q4auPjWq_sOczcVrUWLTuxB7Oog8X27SDU=.f824afa5-4204-4dbe-979a-c1249a33d3dc@github.com>
Message-ID: <j444ENcLHx-f7jhEZjVKzAXVljb5Wi-u1QtWUfIwZ4g=.93d898f6-90da-460b-bf07-8b50249d06a6@github.com>

On Tue, 1 Jul 2025 12:03:08 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc+cpu`.
>> 
>> 
>> [1.563s][info][gc,cpu] GC CPU usage: 42.26%
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change output per discussion

lgtm

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25779#pullrequestreview-2975373548

From duke at openjdk.org  Tue Jul  1 13:27:45 2025
From: duke at openjdk.org (duke)
Date: Tue, 1 Jul 2025 13:27:45 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v14]
In-Reply-To: <M1X3PxWm8q4auPjWq_sOczcVrUWLTuxB7Oog8X27SDU=.f824afa5-4204-4dbe-979a-c1249a33d3dc@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <M1X3PxWm8q4auPjWq_sOczcVrUWLTuxB7Oog8X27SDU=.f824afa5-4204-4dbe-979a-c1249a33d3dc@github.com>
Message-ID: <AT_pt4kQJ6Q2x0KKHqr5FWZzES0Uve6wQn3eWU02dLQ=.5ace16b9-1a88-4c74-b7e9-aab713be6fb2@github.com>

On Tue, 1 Jul 2025 12:03:08 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc+cpu`.
>> 
>> 
>> [1.563s][info][gc,cpu] GC CPU usage: 42.26%
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change output per discussion

@JonasNorlinder 
Your change (at version 3104ff6a383fddba3a94338f6307039b8e7086fa) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-3024012582

From shade at openjdk.org  Tue Jul  1 14:32:49 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 1 Jul 2025 14:32:49 GMT
Subject: RFR: 8359436: AOTCompileEagerly should not be diagnostic [v3]
In-Reply-To: <WgxZZjwz5aQhYltjeUuEMK07_H7KtWQrjbibeDj_X1U=.7b4bb5a5-fa1f-4182-a94e-b95c53824e70@github.com>
References: <dZEQ6cAv4KJjRLjmBDzqX0KPMDjmcbb9e--zVFx6B2g=.bf626b98-f39a-4955-b8e7-8f6c5dc14d09@github.com>
 <WgxZZjwz5aQhYltjeUuEMK07_H7KtWQrjbibeDj_X1U=.7b4bb5a5-fa1f-4182-a94e-b95c53824e70@github.com>
Message-ID: <Wq1ZZ0tYwjtyqZmfs-QnpC9wg2u4J2QTJFOo_KwSrBk=.ba37f9a7-4c0f-4604-bd90-4258342beb6c@github.com>

On Wed, 25 Jun 2025 10:13:49 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> A new AOTCompileEagerly flag introduced by [JDK-8355003](https://bugs.openjdk.org/browse/JDK-8355003) is marked as diagnostic. However, this flag guards the experimental feature, that is, whether the existence of AOT profiles should trigger immediate JIT compilation. Therefore, this flag should be at least be "experimental", rather than "diagnostic".
>> 
>> I don't think it makes sense to elevate this flag to full product flag, since once AOT code caching arrives, this flag would default to true, and would cause AOT loads instead of JIT compilations. Disabling the flag by user choice would be significantly counter-productive then.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `runtime/cds`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Add bug line
>  - Merge branch 'master' into JDK-8359436-aot-diagnostic
>  - Merge branch 'master' into JDK-8359436-aot-diagnostic
>  - Test
>  - Fix

JDK 25 enhancement request granted. I am integrating this to mainline, and would follow with JDK 25 backport.

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

PR Comment: https://git.openjdk.org/jdk/pull/25799#issuecomment-3024294182

From shade at openjdk.org  Tue Jul  1 14:32:51 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 1 Jul 2025 14:32:51 GMT
Subject: Integrated: 8359436: AOTCompileEagerly should not be diagnostic
In-Reply-To: <dZEQ6cAv4KJjRLjmBDzqX0KPMDjmcbb9e--zVFx6B2g=.bf626b98-f39a-4955-b8e7-8f6c5dc14d09@github.com>
References: <dZEQ6cAv4KJjRLjmBDzqX0KPMDjmcbb9e--zVFx6B2g=.bf626b98-f39a-4955-b8e7-8f6c5dc14d09@github.com>
Message-ID: <8-eiO-ZmxUDG88IeBmmhibxKDZIeSf-kg8Hr1QAvvH8=.2ba991f7-38dc-4772-ac08-eb605c2056b4@github.com>

On Fri, 13 Jun 2025 11:31:27 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> A new AOTCompileEagerly flag introduced by [JDK-8355003](https://bugs.openjdk.org/browse/JDK-8355003) is marked as diagnostic. However, this flag guards the experimental feature, that is, whether the existence of AOT profiles should trigger immediate JIT compilation. Therefore, this flag should be at least be "experimental", rather than "diagnostic".
> 
> I don't think it makes sense to elevate this flag to full product flag, since once AOT code caching arrives, this flag would default to true, and would cause AOT loads instead of JIT compilations. Disabling the flag by user choice would be significantly counter-productive then.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `runtime/cds`

This pull request has now been integrated.

Changeset: e1382973
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e138297323de3f6990c4c536b1cefd209ce3a69c
Stats:     103 lines in 2 files changed: 102 ins; 0 del; 1 mod

8359436: AOTCompileEagerly should not be diagnostic

Reviewed-by: kvn, syan, dholmes

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

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

From mbaesken at openjdk.org  Tue Jul  1 14:48:13 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 1 Jul 2025 14:48:13 GMT
Subject: RFR: 8361198: [AIX] fix misleading error output in
 thread_cpu_time_unchecked
Message-ID: <wOj72AJP6g77WdCgbn1CYRmTO3P4skVYZwvUc5fOfe4=.c64e73b3-2573-46ba-8c85-10eb91a59838@github.com>

Currently we have on AIX in thread_cpu_time_unchecked misleading error output in case of failing getthrds64 . This should be adjusted .

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

Commit messages:
 - JDK-8361198

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

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

From shade at openjdk.org  Tue Jul  1 15:40:23 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 1 Jul 2025 15:40:23 GMT
Subject: [jdk25] RFR: 8359436: AOTCompileEagerly should not be diagnostic
Message-ID: <VnNdAj-u2l5aBroTAIS4QDuKmDLuqA2V4aBcdiNjq18=.b10bea85-c21f-4ca3-8fcc-93c72960b259@github.com>

Backporting under granted JDK 25 enhancement request.

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

Commit messages:
 - Backport e138297323de3f6990c4c536b1cefd209ce3a69c

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

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

From kvn at openjdk.org  Tue Jul  1 16:28:49 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 1 Jul 2025 16:28:49 GMT
Subject: [jdk25] RFR: 8359436: AOTCompileEagerly should not be diagnostic
In-Reply-To: <VnNdAj-u2l5aBroTAIS4QDuKmDLuqA2V4aBcdiNjq18=.b10bea85-c21f-4ca3-8fcc-93c72960b259@github.com>
References: <VnNdAj-u2l5aBroTAIS4QDuKmDLuqA2V4aBcdiNjq18=.b10bea85-c21f-4ca3-8fcc-93c72960b259@github.com>
Message-ID: <d8DHf_BjSvC2PIjYKITzFKGYSF13v2FpePUIb2yPNHc=.369da079-3b0c-4a8d-a3d3-3cccbaad53f6@github.com>

On Tue, 1 Jul 2025 15:33:56 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Backporting under granted JDK 25 enhancement request.

Marked as reviewed by kvn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26073#pullrequestreview-2976151479

From lmesnik at openjdk.org  Tue Jul  1 17:07:41 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 1 Jul 2025 17:07:41 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v12]
In-Reply-To: <6WPU5dGPFJ38KnDO88FvRIqQsclgmajiQ2RRKVm0ZCw=.3575812c-b388-42e6-8396-8c39162b6dc0@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
 <6WPU5dGPFJ38KnDO88FvRIqQsclgmajiQ2RRKVm0ZCw=.3575812c-b388-42e6-8396-8c39162b6dc0@github.com>
Message-ID: <ZNfxJu-PG7RipEfrcHHCp_BWQqe_iCQkaYikwk1d1D8=.b4ea874c-6daf-404a-84df-23a1e24b6a29@github.com>

On Tue, 1 Jul 2025 01:55:48 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I copied this code for another test in the Valhalla repo and thought it would be a good utility function.  It might be better written using the Classfile API.
>> Tested with test.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove comment.

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25857#pullrequestreview-2976286692

From coleenp at openjdk.org  Tue Jul  1 17:17:50 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 1 Jul 2025 17:17:50 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v12]
In-Reply-To: <6WPU5dGPFJ38KnDO88FvRIqQsclgmajiQ2RRKVm0ZCw=.3575812c-b388-42e6-8396-8c39162b6dc0@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
 <6WPU5dGPFJ38KnDO88FvRIqQsclgmajiQ2RRKVm0ZCw=.3575812c-b388-42e6-8396-8c39162b6dc0@github.com>
Message-ID: <HqyfexQq8yOiiAqYHTr-oeYPzcbvPTsQyAXaN_K9wsI=.0341c181-8a93-452d-a68f-b624dc791d10@github.com>

On Tue, 1 Jul 2025 01:55:48 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I copied this code for another test in the Valhalla repo and thought it would be a good utility function.  It might be better written using the Classfile API.
>> Tested with test.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove comment.

Thanks for the reviews Leonid, Serguei and David, and thanks for the help with ClassFile API Chen.

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

PR Comment: https://git.openjdk.org/jdk/pull/25857#issuecomment-3024888621

From coleenp at openjdk.org  Tue Jul  1 17:17:51 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 1 Jul 2025 17:17:51 GMT
Subject: Integrated: 8359707: Add classfile modification code to
 RedefineClassHelper
In-Reply-To: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
Message-ID: <XoBo3W-O-cah9xL1v1KkDsC20iSTVxyDIdn_damW36s=.b079f981-22de-45f8-8dae-919f40111efd@github.com>

On Tue, 17 Jun 2025 17:11:01 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I copied this code for another test in the Valhalla repo and thought it would be a good utility function.  It might be better written using the Classfile API.
> Tested with test.

This pull request has now been integrated.

Changeset: e7a45003
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e7a450038a47a76d2e616ebce2a7fa8a51e36ea4
Stats:     91 lines in 2 files changed: 44 ins; 43 del; 4 mod

8359707: Add classfile modification code to RedefineClassHelper

Reviewed-by: lmesnik, dholmes, sspitsyn

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

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

From ccheung at openjdk.org  Tue Jul  1 17:40:48 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 1 Jul 2025 17:40:48 GMT
Subject: RFR: 8357064: cds/appcds/ArchiveRelocationTest.java failed with
 missing expected output
Message-ID: <4ZhoZI0AK9WTS4gyXXCHI9JXtsiJwo2u5vfKmuGTvA8=.ce8662f6-3257-469f-b915-65ccc12cd7ac@github.com>

The `cds/appcds/ArchiveRelocationTest.java` test failed intermittently on Windows when the "Failed to reserve spaces" error occurred. A fix is to relax the check of the expected output; just to check either one of the expected output exists.

Testing: ran the "hotspot_runtime" test group 60 times on Windows with the `-XX:+UseParallelGC -XX:+UseNUMA` VM options.

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

Commit messages:
 - 8357064: cds/appcds/ArchiveRelocationTest.java failed with missing expected output

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

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

From shade at openjdk.org  Tue Jul  1 18:11:37 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 1 Jul 2025 18:11:37 GMT
Subject: RFR: 8357064: cds/appcds/ArchiveRelocationTest.java failed with
 missing expected output
In-Reply-To: <4ZhoZI0AK9WTS4gyXXCHI9JXtsiJwo2u5vfKmuGTvA8=.ce8662f6-3257-469f-b915-65ccc12cd7ac@github.com>
References: <4ZhoZI0AK9WTS4gyXXCHI9JXtsiJwo2u5vfKmuGTvA8=.ce8662f6-3257-469f-b915-65ccc12cd7ac@github.com>
Message-ID: <Mx_qjcRlO9DCT7Rj2SCxGdOFqMlhYhG6Zep9NZNvT1E=.fa65e240-3cac-4d38-a8f6-73bb5c35a3ea@github.com>

On Tue, 1 Jul 2025 17:37:07 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> The `cds/appcds/ArchiveRelocationTest.java` test failed intermittently on Windows when the "Failed to reserve spaces" error occurred. A fix is to relax the check of the expected output; just to check either one of the expected output exists.
> 
> Testing: ran the "hotspot_runtime" test group 60 times on Windows with the `-XX:+UseParallelGC -XX:+UseNUMA` VM options.

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26075#pullrequestreview-2976513678

From iklam at openjdk.org  Tue Jul  1 18:30:21 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 1 Jul 2025 18:30:21 GMT
Subject: RFR: 8360164: AOT cache creation crashes in
 ~ThreadTotalCPUTimeClosure() [v4]
In-Reply-To: <0ngnvAd9W2v2J4DakBiym9GCrnnpNZbJjflZuHIIbBo=.77887a82-44a8-44a9-9c71-c42f98b330a5@github.com>
References: <0ngnvAd9W2v2J4DakBiym9GCrnnpNZbJjflZuHIIbBo=.77887a82-44a8-44a9-9c71-c42f98b330a5@github.com>
Message-ID: <pBNIoyjF1bdUVuFpRAdMRQX1G8UPTjgfXXDWdfe6YWc=.b9e28969-e632-4034-b7de-7b2286e19db2@github.com>

> `java -XX:AOTMode=create` calls `vm_exit(0)` to terminate the JVM (see [this e-mail thread](https://mail.openjdk.org/pipermail/hotspot-runtime-dev/2024-August/072122.html) for the reason for doing so). However, at this point, the JVM has executed quite a lot of Java code and there are many threads in the JVM that would require a proper shutdown. See [comments by @kimbarrett](https://bugs.openjdk.org/browse/JDK-8360164?focusedId=14792754&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14792754) for a detailed analysis.
> 
> This fix calls `JVM_Halt(0)` instead of `vm_exit(0)` so that the proper shutdown code is executed.

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

  reverted change in before_exit() as it is no longer needed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26008/files
  - new: https://git.openjdk.org/jdk/pull/26008/files/f8222e38..b8f7452e

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

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

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

From iklam at openjdk.org  Tue Jul  1 18:31:37 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 1 Jul 2025 18:31:37 GMT
Subject: RFR: 8357064: cds/appcds/ArchiveRelocationTest.java failed with
 missing expected output
In-Reply-To: <4ZhoZI0AK9WTS4gyXXCHI9JXtsiJwo2u5vfKmuGTvA8=.ce8662f6-3257-469f-b915-65ccc12cd7ac@github.com>
References: <4ZhoZI0AK9WTS4gyXXCHI9JXtsiJwo2u5vfKmuGTvA8=.ce8662f6-3257-469f-b915-65ccc12cd7ac@github.com>
Message-ID: <jpvCydn1iukolbB1qa5UNaWh-1L8lbSDpgp2RUadvug=.0cfc6c2a-a7ab-4355-bf41-c57558533d2f@github.com>

On Tue, 1 Jul 2025 17:37:07 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> The `cds/appcds/ArchiveRelocationTest.java` test failed intermittently on Windows when the "Failed to reserve spaces" error occurred. A fix is to relax the check of the expected output; just to check either one of the expected output exists.
> 
> Testing: ran the "hotspot_runtime" test group 60 times on Windows with the `-XX:+UseParallelGC -XX:+UseNUMA` VM options.

LGTM

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

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26075#pullrequestreview-2976577808

From ccheung at openjdk.org  Tue Jul  1 19:10:41 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 1 Jul 2025 19:10:41 GMT
Subject: RFR: 8360164: AOT cache creation crashes in
 ~ThreadTotalCPUTimeClosure() [v4]
In-Reply-To: <pBNIoyjF1bdUVuFpRAdMRQX1G8UPTjgfXXDWdfe6YWc=.b9e28969-e632-4034-b7de-7b2286e19db2@github.com>
References: <0ngnvAd9W2v2J4DakBiym9GCrnnpNZbJjflZuHIIbBo=.77887a82-44a8-44a9-9c71-c42f98b330a5@github.com>
 <pBNIoyjF1bdUVuFpRAdMRQX1G8UPTjgfXXDWdfe6YWc=.b9e28969-e632-4034-b7de-7b2286e19db2@github.com>
Message-ID: <YySJtfonQVJok9IVhrSMB4dyrYfIVaANGeA26imwdaw=.7b8d4174-504a-434a-b319-0f5e2f63be25@github.com>

On Tue, 1 Jul 2025 18:30:21 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> `java -XX:AOTMode=create` calls `vm_exit(0)` to terminate the JVM (see [this e-mail thread](https://mail.openjdk.org/pipermail/hotspot-runtime-dev/2024-August/072122.html) for the reason for doing so). However, at this point, the JVM has executed quite a lot of Java code and there are many threads in the JVM that would require a proper shutdown. See [comments by @kimbarrett](https://bugs.openjdk.org/browse/JDK-8360164?focusedId=14792754&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14792754) for a detailed analysis.
>> 
>> This fix calls `JVM_Halt(0)` instead of `vm_exit(0)` so that the proper shutdown code is executed.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reverted change in before_exit() as it is no longer needed

LGTM

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

Marked as reviewed by ccheung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26008#pullrequestreview-2976670475

From mli at openjdk.org  Tue Jul  1 19:29:20 2025
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 1 Jul 2025 19:29:20 GMT
Subject: RFR: 8360090: [TEST] RISC-V: disable some cds tests on qemu [v2]
In-Reply-To: <sEU3dcbcF1dX7DVHE3Hu9Vcue6GUeUEAUZ7jY_uQQMI=.eaeeacb1-b9b5-42d7-ac9d-82078f6ac353@github.com>
References: <sEU3dcbcF1dX7DVHE3Hu9Vcue6GUeUEAUZ7jY_uQQMI=.eaeeacb1-b9b5-42d7-ac9d-82078f6ac353@github.com>
Message-ID: <kB7jzBaLIw_W3H1Y7YamMQapoacrfB8b_SCt9e32P2E=.76c7491d-fecb-45d2-92a4-326e23dbff6b@github.com>

> Hi,
> Can you help to review this patch?
> 
> CDS does not work well in cross compilation env, this is by desgin, please check `JDKOPT_ENABLE_DISABLE_CDS_ARCHIVE` in make of jdk.
> 
> These tests depends on classes.jsa or classes_xxx.jsa which is not generated and will not be generated when build jdk in qemu environment for riscv, so we should disable them when qemu.
> 
> Thanks!

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

  check default archive

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25913/files
  - new: https://git.openjdk.org/jdk/pull/25913/files/7b48e4ea..8f9c7ba7

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

  Stats: 26 lines in 6 files changed: 19 ins; 7 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25913.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25913/head:pull/25913

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

From rehn at openjdk.org  Tue Jul  1 19:29:20 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 1 Jul 2025 19:29:20 GMT
Subject: RFR: 8360090: [TEST] RISC-V: disable some cds tests on qemu
In-Reply-To: <0Im1TXEP66tejiuNh7TcwwPeW2wsRtM8LY51BCwxAng=.871e86c1-51d4-4269-81cb-8b6f14cb82fe@github.com>
References: <sEU3dcbcF1dX7DVHE3Hu9Vcue6GUeUEAUZ7jY_uQQMI=.eaeeacb1-b9b5-42d7-ac9d-82078f6ac353@github.com>
 <0Im1TXEP66tejiuNh7TcwwPeW2wsRtM8LY51BCwxAng=.871e86c1-51d4-4269-81cb-8b6f14cb82fe@github.com>
Message-ID: <uux6Lf3dakBwN38mJJUT2rTRrtTlnPknxGybBwla23c=.4180a44b-847c-4618-aeea-28febffbf6a5@github.com>

On Mon, 30 Jun 2025 23:10:22 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> You can add new property for your condition in VMProps, saying vm.cds.archive.available that is true is archive is generated for JDK. Since the classes.jsa is mandatory the property should check if classes.jsa exists and if current configuration allows to miss classes.jsa. You could start with adding risc+qemu as a first configuration with optional cds archive. Later it could be extended.
> 
> Alternatively you could just throw SkippedException in the tests, assuming that number of them is small. There is an example with isCOHArchiveAvailable() check.

We can probably figure that out in test/jtreg-ext/requires/VMProps.java, so we can use require tag for it.

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

PR Comment: https://git.openjdk.org/jdk/pull/25913#issuecomment-3022895401

From mli at openjdk.org  Tue Jul  1 19:29:20 2025
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 1 Jul 2025 19:29:20 GMT
Subject: RFR: 8360090: [TEST] RISC-V: disable some cds tests on qemu
In-Reply-To: <uux6Lf3dakBwN38mJJUT2rTRrtTlnPknxGybBwla23c=.4180a44b-847c-4618-aeea-28febffbf6a5@github.com>
References: <sEU3dcbcF1dX7DVHE3Hu9Vcue6GUeUEAUZ7jY_uQQMI=.eaeeacb1-b9b5-42d7-ac9d-82078f6ac353@github.com>
 <0Im1TXEP66tejiuNh7TcwwPeW2wsRtM8LY51BCwxAng=.871e86c1-51d4-4269-81cb-8b6f14cb82fe@github.com>
 <uux6Lf3dakBwN38mJJUT2rTRrtTlnPknxGybBwla23c=.4180a44b-847c-4618-aeea-28febffbf6a5@github.com>
Message-ID: <b3BcWFguSZi4H2ua7VM5VX2GxWTrGi0BdzDg9jSlzNI=.939d58d1-0773-4cb0-99e7-c9be34d7ecb4@github.com>

On Tue, 1 Jul 2025 09:17:02 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> You can add new property for your condition in VMProps, saying vm.cds.archive.available that is true is archive is generated for JDK. Since the classes.jsa is mandatory the property should check if classes.jsa exists and if current configuration allows to miss classes.jsa. You could start with adding risc+qemu as a first configuration with optional cds archive. Later it could be extended.
> 
> Alternatively you could just throw SkippedException in the tests, assuming that number of them is small. There is an example with isCOHArchiveAvailable() check.

@lmesnik Thank you for the suggestion!

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

PR Comment: https://git.openjdk.org/jdk/pull/25913#issuecomment-3025250587

From mli at openjdk.org  Tue Jul  1 19:31:38 2025
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 1 Jul 2025 19:31:38 GMT
Subject: RFR: 8360090: [TEST] RISC-V: disable some cds tests on qemu
In-Reply-To: <sEU3dcbcF1dX7DVHE3Hu9Vcue6GUeUEAUZ7jY_uQQMI=.eaeeacb1-b9b5-42d7-ac9d-82078f6ac353@github.com>
References: <sEU3dcbcF1dX7DVHE3Hu9Vcue6GUeUEAUZ7jY_uQQMI=.eaeeacb1-b9b5-42d7-ac9d-82078f6ac353@github.com>
Message-ID: <vGt9NHGShMj-F7yr6d-LjUVBqy0UqrjvcuJ-Kl-s4d8=.6ea08058-7981-40aa-8b7c-44747314976f@github.com>

On Fri, 20 Jun 2025 09:27:14 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> Can you help to review this patch?
> 
> CDS does not work well in cross compilation env, this is by desgin, please check `JDKOPT_ENABLE_DISABLE_CDS_ARCHIVE` in make of jdk.
> 
> These tests depends on classes.jsa or classes_xxx.jsa which is not generated and will not be generated when build jdk in qemu environment for riscv, so we should disable them when qemu.
> 
> Thanks!

I modify it by introducing a "vm.cds.default.archive.available" in hotspot jtreg test, it checks whether the default archive file i.e. $JAVA_HOME/lib/server/classes.jsa exists. And these tests are skipped if default archive file does not exist in test jdk.

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

PR Comment: https://git.openjdk.org/jdk/pull/25913#issuecomment-3025256154

From ccheung at openjdk.org  Tue Jul  1 19:56:43 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 1 Jul 2025 19:56:43 GMT
Subject: RFR: 8357064: cds/appcds/ArchiveRelocationTest.java failed with
 missing expected output
In-Reply-To: <Mx_qjcRlO9DCT7Rj2SCxGdOFqMlhYhG6Zep9NZNvT1E=.fa65e240-3cac-4d38-a8f6-73bb5c35a3ea@github.com>
References: <4ZhoZI0AK9WTS4gyXXCHI9JXtsiJwo2u5vfKmuGTvA8=.ce8662f6-3257-469f-b915-65ccc12cd7ac@github.com>
 <Mx_qjcRlO9DCT7Rj2SCxGdOFqMlhYhG6Zep9NZNvT1E=.fa65e240-3cac-4d38-a8f6-73bb5c35a3ea@github.com>
Message-ID: <-_6mQBVVwRezfiSMx8YwtutXr_1-SqjW9VWL0t-CbvU=.8d1efa17-420d-4074-b4ba-66df35a6caab@github.com>

On Tue, 1 Jul 2025 18:09:32 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> The `cds/appcds/ArchiveRelocationTest.java` test failed intermittently on Windows when the "Failed to reserve spaces" error occurred. A fix is to relax the check of the expected output; just to check either one of the expected output exists.
>> 
>> Testing: ran the "hotspot_runtime" test group 60 times on Windows with the `-XX:+UseParallelGC -XX:+UseNUMA` VM options.
>
> Marked as reviewed by shade (Reviewer).

Thanks @shipilev @iklam for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/26075#issuecomment-3025317721

From ccheung at openjdk.org  Tue Jul  1 19:56:44 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 1 Jul 2025 19:56:44 GMT
Subject: Integrated: 8357064: cds/appcds/ArchiveRelocationTest.java failed with
 missing expected output
In-Reply-To: <4ZhoZI0AK9WTS4gyXXCHI9JXtsiJwo2u5vfKmuGTvA8=.ce8662f6-3257-469f-b915-65ccc12cd7ac@github.com>
References: <4ZhoZI0AK9WTS4gyXXCHI9JXtsiJwo2u5vfKmuGTvA8=.ce8662f6-3257-469f-b915-65ccc12cd7ac@github.com>
Message-ID: <wUGT5Mhq4Y_lGj6u-X9-qRHBzxjJlkPrDFce8Bl1RaY=.f13c190a-8865-41b2-904e-89d14a8191ab@github.com>

On Tue, 1 Jul 2025 17:37:07 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> The `cds/appcds/ArchiveRelocationTest.java` test failed intermittently on Windows when the "Failed to reserve spaces" error occurred. A fix is to relax the check of the expected output; just to check either one of the expected output exists.
> 
> Testing: ran the "hotspot_runtime" test group 60 times on Windows with the `-XX:+UseParallelGC -XX:+UseNUMA` VM options.

This pull request has now been integrated.

Changeset: 534d2b33
Author:    Calvin Cheung <ccheung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/534d2b33dc23d0171fdce3cb89d679d5088b4667
Stats:     6 lines in 1 file changed: 4 ins; 0 del; 2 mod

8357064: cds/appcds/ArchiveRelocationTest.java failed with missing expected output

Reviewed-by: shade, iklam

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

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

From iklam at openjdk.org  Tue Jul  1 20:24:46 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 1 Jul 2025 20:24:46 GMT
Subject: RFR: 8360164: AOT cache creation crashes in
 ~ThreadTotalCPUTimeClosure() [v4]
In-Reply-To: <o7DbkduebSQud6mdP972ON3A25ptrVMscZwzoeoPze8=.8db8a943-cc80-4499-be26-dd6601e5f197@github.com>
References: <0ngnvAd9W2v2J4DakBiym9GCrnnpNZbJjflZuHIIbBo=.77887a82-44a8-44a9-9c71-c42f98b330a5@github.com>
 <o7DbkduebSQud6mdP972ON3A25ptrVMscZwzoeoPze8=.8db8a943-cc80-4499-be26-dd6601e5f197@github.com>
Message-ID: <ZFTih-szyqiq2r5zs1HjZ14m4paWnyI9NsU2UjQe5F4=.a5be51a4-9190-4fcb-8e37-577b6d83b34d@github.com>

On Thu, 26 Jun 2025 23:56:51 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reverted change in before_exit() as it is no longer needed
>
> Good.

Thanks @vnkozlov @calvinccheung @dholmes-ora for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/26008#issuecomment-3025384396

From iklam at openjdk.org  Tue Jul  1 20:24:47 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 1 Jul 2025 20:24:47 GMT
Subject: Integrated: 8360164: AOT cache creation crashes in
 ~ThreadTotalCPUTimeClosure()
In-Reply-To: <0ngnvAd9W2v2J4DakBiym9GCrnnpNZbJjflZuHIIbBo=.77887a82-44a8-44a9-9c71-c42f98b330a5@github.com>
References: <0ngnvAd9W2v2J4DakBiym9GCrnnpNZbJjflZuHIIbBo=.77887a82-44a8-44a9-9c71-c42f98b330a5@github.com>
Message-ID: <wcj9G84IqQ6j3_dsNrRUO95zSAhW5Odz54gLkBDF1zI=.2d001c46-4d8e-4600-8565-63524db634e5@github.com>

On Thu, 26 Jun 2025 23:41:40 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> `java -XX:AOTMode=create` calls `vm_exit(0)` to terminate the JVM (see [this e-mail thread](https://mail.openjdk.org/pipermail/hotspot-runtime-dev/2024-August/072122.html) for the reason for doing so). However, at this point, the JVM has executed quite a lot of Java code and there are many threads in the JVM that would require a proper shutdown. See [comments by @kimbarrett](https://bugs.openjdk.org/browse/JDK-8360164?focusedId=14792754&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14792754) for a detailed analysis.
> 
> This fix calls `JVM_Halt(0)` instead of `vm_exit(0)` so that the proper shutdown code is executed.

This pull request has now been integrated.

Changeset: 7d7e60c8
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7d7e60c8aebc4b4c1e7121be702393e5bc46e9ce
Stats:     3 lines in 1 file changed: 1 ins; 2 del; 0 mod

8360164: AOT cache creation crashes in ~ThreadTotalCPUTimeClosure()

Reviewed-by: ccheung, kvn, dholmes

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

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

From mdoerr at openjdk.org  Tue Jul  1 20:26:38 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 1 Jul 2025 20:26:38 GMT
Subject: RFR: 8361198: [AIX] fix misleading error output in
 thread_cpu_time_unchecked
In-Reply-To: <wOj72AJP6g77WdCgbn1CYRmTO3P4skVYZwvUc5fOfe4=.c64e73b3-2573-46ba-8c85-10eb91a59838@github.com>
References: <wOj72AJP6g77WdCgbn1CYRmTO3P4skVYZwvUc5fOfe4=.c64e73b3-2573-46ba-8c85-10eb91a59838@github.com>
Message-ID: <02rbX34Ix0YTlWUb10w6KC5hVj37FLeti25r9VYc4Eo=.74abdab2-91f3-4ac3-ac14-705e19906b41@github.com>

On Tue, 1 Jul 2025 14:43:22 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently we have on AIX in thread_cpu_time_unchecked misleading error output in case of failing getthrds64 . This should be adjusted .

LGTM.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26070#pullrequestreview-2976837172

From lmesnik at openjdk.org  Tue Jul  1 21:06:40 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 1 Jul 2025 21:06:40 GMT
Subject: RFR: 8360090: [TEST] RISC-V: disable some cds tests on qemu [v2]
In-Reply-To: <kB7jzBaLIw_W3H1Y7YamMQapoacrfB8b_SCt9e32P2E=.76c7491d-fecb-45d2-92a4-326e23dbff6b@github.com>
References: <sEU3dcbcF1dX7DVHE3Hu9Vcue6GUeUEAUZ7jY_uQQMI=.eaeeacb1-b9b5-42d7-ac9d-82078f6ac353@github.com>
 <kB7jzBaLIw_W3H1Y7YamMQapoacrfB8b_SCt9e32P2E=.76c7491d-fecb-45d2-92a4-326e23dbff6b@github.com>
Message-ID: <4BxvAwkwZar8wvkFefsY3YCeW1yYaEh3gxEL16j5gxw=.9e87f0ab-fff0-438a-8825-424312b1ed26@github.com>

On Tue, 1 Jul 2025 19:29:20 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you help to review this patch?
>> 
>> CDS does not work well in cross compilation env, this is by desgin, please check `JDKOPT_ENABLE_DISABLE_CDS_ARCHIVE` in make of jdk.
>> 
>> These tests depends on classes.jsa or classes_xxx.jsa which is not generated and will not be generated when build jdk in qemu environment for riscv, so we should disable them when qemu.
>> 
>> Thanks!
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   check default archive

I think the change looks good. Note that I epxpect to have a separate test that verifies the content of JDK product and check if distribution has all expected files.

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

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25913#pullrequestreview-2976940263

From iklam at openjdk.org  Wed Jul  2 00:22:54 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 2 Jul 2025 00:22:54 GMT
Subject: RFR: 8360555: Archive all unnamed modules in CDS full module graph
Message-ID: <wShFgP1f2myBNCuyVnLXYiB1PEBQlkW5VcyIDmyeoRo=.fff71539-455b-4109-8f9c-81c2e16d0bc0@github.com>

The CDS full module graph is supposed to contain a snapshot of the boot layer, which has 3 unnamed modules for the boot, platform and system class loaders. Each unnamed module is represented by a `java.lang.Module` Java object and a `ModuleEntry` C++ object.

Currently, we archive only the `java.lang.Module` for the platform and system loaders. The other 4 objects are dynamically created in the production run while executing Java bytecodes during VM bootstrap.

With this PR, we archive all of the above 6 objects when `CDSConfig::is_dumping_full_module_graph()` is true.

This is required for [JDK-8350550](https://bugs.openjdk.org/browse/JDK-8350550), as we need the `java.lang.Module` object for archived classes in the unnamed module of the boot loader prior to executing any Java code.

We also archive the `ModuleEntry` objects for the 3 unnamed modules for uniformity, as these objects are already archived for named modules.

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

Commit messages:
 - 8360555: Archive all unnamed modules in CDS full module graph

Changes: https://git.openjdk.org/jdk/pull/26082/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26082&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8360555
  Stats: 187 lines in 13 files changed: 140 ins; 17 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/26082.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26082/head:pull/26082

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

From kbarrett at openjdk.org  Wed Jul  2 00:28:44 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 2 Jul 2025 00:28:44 GMT
Subject: RFR: 8361085: MemoryReserver log_on_large_pages_failure has
 incorrect format usage
In-Reply-To: <Ft07WmPH96Y7rBwGyH41XWNOp7YG3dgdKvbjyHqN3Is=.d6c25b2b-6451-47dc-8769-5652c85cfece@github.com>
References: <tyRBtI09kU7Aq3AwA3afRqiY0G73NDdasXmY784vs9U=.ac18eea9-1235-47e2-ad92-11e3efa650a9@github.com>
 <Ft07WmPH96Y7rBwGyH41XWNOp7YG3dgdKvbjyHqN3Is=.d6c25b2b-6451-47dc-8769-5652c85cfece@github.com>
Message-ID: <1M_nzc7-Z7lDEwNKAlLw2jLYIEfby-CX9kpHQ7mThQM=.ef8efc15-251b-4e74-abab-46fe5c8f0a11@github.com>

On Mon, 30 Jun 2025 16:46:28 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Please review this fix of an incorrect format usage.
>> 
>> The function calls `jio_snprintf` to format a message into a buffer. That
>> message includes printing a pointer using `PTR_FORMAT`, but isn't using the
>> `p2i` helper function. Fixing that is just a matter of using that helper.
>> 
>> However, there's no need to use `jio_snprintf` here, as the resulting message
>> is then just passed to `warning`, which can handle output formatting directly.
>> So we also move the formatting to the `warning` call, and remove the use of
>> `jio_snprintf`. Note that calling `warning` without the `p2i` would have
>> produced a compiler warning about the incorrect format usage.
>> 
>> Testing: mach5 tier1
>
> Marked as reviewed by stefank (Reviewer).

Thanks for reviews @stefank and @dholmes-ora

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

PR Comment: https://git.openjdk.org/jdk/pull/26050#issuecomment-3025910371

From kbarrett at openjdk.org  Wed Jul  2 00:28:45 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 2 Jul 2025 00:28:45 GMT
Subject: Integrated: 8361085: MemoryReserver log_on_large_pages_failure has
 incorrect format usage
In-Reply-To: <tyRBtI09kU7Aq3AwA3afRqiY0G73NDdasXmY784vs9U=.ac18eea9-1235-47e2-ad92-11e3efa650a9@github.com>
References: <tyRBtI09kU7Aq3AwA3afRqiY0G73NDdasXmY784vs9U=.ac18eea9-1235-47e2-ad92-11e3efa650a9@github.com>
Message-ID: <8MqnoV4dLNvRalY_jE99vWThB3KH3nFnm46wK3Any9o=.1f840e64-8f32-4488-a866-eda00fa6c27c@github.com>

On Mon, 30 Jun 2025 16:11:47 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this fix of an incorrect format usage.
> 
> The function calls `jio_snprintf` to format a message into a buffer. That
> message includes printing a pointer using `PTR_FORMAT`, but isn't using the
> `p2i` helper function. Fixing that is just a matter of using that helper.
> 
> However, there's no need to use `jio_snprintf` here, as the resulting message
> is then just passed to `warning`, which can handle output formatting directly.
> So we also move the formatting to the `warning` call, and remove the use of
> `jio_snprintf`. Note that calling `warning` without the `p2i` would have
> produced a compiler warning about the incorrect format usage.
> 
> Testing: mach5 tier1

This pull request has now been integrated.

Changeset: 1703915d
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1703915d3fe3608ca558671814f78d9dcf5886e6
Stats:     6 lines in 1 file changed: 0 ins; 3 del; 3 mod

8361085: MemoryReserver log_on_large_pages_failure has incorrect format usage

Reviewed-by: stefank, dholmes

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

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

From rehn at openjdk.org  Wed Jul  2 05:47:38 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 2 Jul 2025 05:47:38 GMT
Subject: RFR: 8360090: [TEST] RISC-V: disable some cds tests on qemu [v2]
In-Reply-To: <kB7jzBaLIw_W3H1Y7YamMQapoacrfB8b_SCt9e32P2E=.76c7491d-fecb-45d2-92a4-326e23dbff6b@github.com>
References: <sEU3dcbcF1dX7DVHE3Hu9Vcue6GUeUEAUZ7jY_uQQMI=.eaeeacb1-b9b5-42d7-ac9d-82078f6ac353@github.com>
 <kB7jzBaLIw_W3H1Y7YamMQapoacrfB8b_SCt9e32P2E=.76c7491d-fecb-45d2-92a4-326e23dbff6b@github.com>
Message-ID: <ItHpgy5mPHsuCW5ePuQWWNPY_C9fdlpE16PjVwbAqTg=.193cbb77-6f49-4a47-a732-ab2c032f59c2@github.com>

On Tue, 1 Jul 2025 19:29:20 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you help to review this patch?
>> 
>> CDS does not work well in cross compilation env, this is by desgin, please check `JDKOPT_ENABLE_DISABLE_CDS_ARCHIVE` in make of jdk.
>> 
>> These tests depends on classes.jsa or classes_xxx.jsa which is not generated and will not be generated when build jdk in qemu environment for riscv, so we should disable them when qemu.
>> 
>> Thanks!
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   check default archive

Nice work, thanks!

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

Marked as reviewed by rehn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25913#pullrequestreview-2977813731

From azeller at openjdk.org  Wed Jul  2 05:59:38 2025
From: azeller at openjdk.org (Arno Zeller)
Date: Wed, 2 Jul 2025 05:59:38 GMT
Subject: RFR: 8361198: [AIX] fix misleading error output in
 thread_cpu_time_unchecked
In-Reply-To: <wOj72AJP6g77WdCgbn1CYRmTO3P4skVYZwvUc5fOfe4=.c64e73b3-2573-46ba-8c85-10eb91a59838@github.com>
References: <wOj72AJP6g77WdCgbn1CYRmTO3P4skVYZwvUc5fOfe4=.c64e73b3-2573-46ba-8c85-10eb91a59838@github.com>
Message-ID: <dGJxCuQANobsIx4enc6WagPG8Q5wgz0dWGCcW3bET-I=.6959dda5-8653-4b5a-970a-5942bb313651@github.com>

On Tue, 1 Jul 2025 14:43:22 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently we have on AIX in thread_cpu_time_unchecked misleading error output in case of failing getthrds64 . This should be adjusted .

Looks trivial, but I would suggest to print the errno also for the case when pthread_getthrds_np fails a few lines above.

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

PR Comment: https://git.openjdk.org/jdk/pull/26070#issuecomment-3026554777

From dholmes at openjdk.org  Wed Jul  2 06:35:40 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 2 Jul 2025 06:35:40 GMT
Subject: RFR: 8357601: Checked version of JNI Release<type>ArrayElements
 needs to filter out known wrapped arrays
In-Reply-To: <03QoDXp-rOR3n546DRKYfDabRcdMYUOI8wCnINdW69Y=.c6fca915-9dc2-4737-92d1-a09c27babae9@github.com>
References: <Zg4Zabq290iG7P02xAkGT_fHXEsur-GE-w4-piJYc0E=.e0c38720-75bd-4b2a-9d6f-a225749b5a29@github.com>
 <03QoDXp-rOR3n546DRKYfDabRcdMYUOI8wCnINdW69Y=.c6fca915-9dc2-4737-92d1-a09c27babae9@github.com>
Message-ID: <cVeuDir_pveRDjZQrqsCI5AUdbx04RRNEBFJFxCwzOk=.a9502fd2-a75f-4596-815a-9e1eddd75c91@github.com>

On Tue, 1 Jul 2025 12:31:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The checked version of `Get`/`Release<type>ArrayElements` uses `GuardedMemory` to perform error checking. When releasing the array the code needs to check for the known array tags from the other JNI APIs and report an error.
>> 
>> We also expand `GuardedMemory` to allow for a second tag word so that we can discriminate additional allocation sites i.e. identifying use of `Get`/`SetPrimitiveArrayCritical`. And add further robustness to guard verification by using `SafeFetch`.
>> 
>> Testing
>>  - new test
>>  - Tiers 1-4 (sanity)
>
> Cool test. Looks fine.  I had some earlier comments but nothing that would really improve the change.

Thanks for the review @coleenp !

> src/hotspot/share/prims/jniCheck.cpp line 400:
> 
>> 398:   if (orig_result == STRING_TAG || orig_result == STRING_UTF_TAG) {
>> 399:     bool was_utf = orig_result == STRING_UTF_TAG;
>> 400:     tty->print_cr("%s: called on something allocated by %s",
> 
> Can you use log_warning(memory) for this message rather than tty?
> Maybe these should be tty since they're in jniCheck.

`tty` is used throughout the jniCheck code.

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

PR Comment: https://git.openjdk.org/jdk/pull/25444#issuecomment-3026627820
PR Review Comment: https://git.openjdk.org/jdk/pull/25444#discussion_r2179232621

From dholmes at openjdk.org  Wed Jul  2 07:25:43 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 2 Jul 2025 07:25:43 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v12]
In-Reply-To: <k9TPvCuyHrJKpUGAOa_TPI_GxG8IUl6zjBPm_EyRNss=.3dfba520-d6cd-44d6-9965-4a0bdb7e63d8@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <9THM_-ewp6IHKihx_AAHi2AjhG86B9tD7IvqtUIxUe8=.501655a3-77d4-4996-a340-9141bbf25154@github.com>
 <37GU6UtugGvR3iwskdw2iFYJbXOI_CjN4T-tL7QKgZw=.0082a838-7941-4522-b88a-13911888bedb@github.com>
 <k9TPvCuyHrJKpUGAOa_TPI_GxG8IUl6zjBPm_EyRNss=.3dfba520-d6cd-44d6-9965-4a0bdb7e63d8@github.com>
Message-ID: <y--qiGOt06nNV75zVSiyiy_TQVqTV4HvtB72_BrNmc0=.6e12feae-cd88-4d0c-a52b-50fe359861c9@github.com>

On Tue, 1 Jul 2025 09:33:26 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> src/hotspot/share/runtime/os.hpp line 296:
>> 
>>> 294:   static jlong elapsed_frequency();
>>> 295: 
>>> 296:   static double elapsed_process_cpu_time();
>> 
>> Not sure if it is required that these methods return their values as `double`s in seconds. Given the uses, this seems unnecessary premature loss of precision.
>
> It is not required, but I was conforming to the same type as the methods that was removed in JDK-8274051 and as well as `elapsedTime()`. `elapsedTime()` returns the wall-clock time in seconds since start in `double`.

I don't see how there is a loss of precision here, just because the unit ahead of the decimal point is seconds. 

2.123456789 seconds still has nanosecond precision

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2179319901

From dholmes at openjdk.org  Wed Jul  2 07:38:44 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 2 Jul 2025 07:38:44 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v14]
In-Reply-To: <M1X3PxWm8q4auPjWq_sOczcVrUWLTuxB7Oog8X27SDU=.f824afa5-4204-4dbe-979a-c1249a33d3dc@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <M1X3PxWm8q4auPjWq_sOczcVrUWLTuxB7Oog8X27SDU=.f824afa5-4204-4dbe-979a-c1249a33d3dc@github.com>
Message-ID: <v2hXWian6z-9A95u1KFlKuo6v-f2FrKfs-wmfqo36rI=.579bb7da-3179-488f-9c70-0695a9b0d456@github.com>

On Tue, 1 Jul 2025 12:03:08 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc+cpu`.
>> 
>> 
>> [2,430s][info][gc,cpu] GC CPU usage: 22,87% (Process: 26,8926s GC: 6,1491s)
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change output per discussion

@JonasNorlinder  you need two reviews before integrating hotspot changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-3026784458

From tschatzl at openjdk.org  Wed Jul  2 08:50:52 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 2 Jul 2025 08:50:52 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v12]
In-Reply-To: <y--qiGOt06nNV75zVSiyiy_TQVqTV4HvtB72_BrNmc0=.6e12feae-cd88-4d0c-a52b-50fe359861c9@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <9THM_-ewp6IHKihx_AAHi2AjhG86B9tD7IvqtUIxUe8=.501655a3-77d4-4996-a340-9141bbf25154@github.com>
 <37GU6UtugGvR3iwskdw2iFYJbXOI_CjN4T-tL7QKgZw=.0082a838-7941-4522-b88a-13911888bedb@github.com>
 <k9TPvCuyHrJKpUGAOa_TPI_GxG8IUl6zjBPm_EyRNss=.3dfba520-d6cd-44d6-9965-4a0bdb7e63d8@github.com>
 <y--qiGOt06nNV75zVSiyiy_TQVqTV4HvtB72_BrNmc0=.6e12feae-cd88-4d0c-a52b-50fe359861c9@github.com>
Message-ID: <GFlsWYyYqofynitxxCBikwUO0UJ_cA2X3HPDQ4BFs0k=.37c9a87d-8de3-4a5d-9cea-71d236d53ac4@github.com>

On Wed, 2 Jul 2025 07:22:54 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> It is not required, but I was conforming to the same type as the methods that was removed in JDK-8274051 and as well as `elapsedTime()`. `elapsedTime()` returns the wall-clock time in seconds since start in `double`.
>
> I don't see how there is a loss of precision here, just because the unit ahead of the decimal point is seconds. 
> 
> 2.123456789 seconds still has nanosecond precision

Instead of adding integer nanosecond values together to form a final sum and then divide just when printing the value, the code divides each part of the sum  and then add them together. The FP division is lossy due to (very minor) representation issues too.

Also performs unnecessary relatively costly FP operations.

Very negligible nowadays, but why incur these problems for no reason? There does not seem to be an advantage to keep intermediate values as doubles in seconds.

It's far from a blocker from me, in fact I already signed this off.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2179489841

From mli at openjdk.org  Wed Jul  2 08:59:48 2025
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 2 Jul 2025 08:59:48 GMT
Subject: RFR: 8360090: [TEST] RISC-V: disable some cds tests on qemu [v2]
In-Reply-To: <4BxvAwkwZar8wvkFefsY3YCeW1yYaEh3gxEL16j5gxw=.9e87f0ab-fff0-438a-8825-424312b1ed26@github.com>
References: <sEU3dcbcF1dX7DVHE3Hu9Vcue6GUeUEAUZ7jY_uQQMI=.eaeeacb1-b9b5-42d7-ac9d-82078f6ac353@github.com>
 <kB7jzBaLIw_W3H1Y7YamMQapoacrfB8b_SCt9e32P2E=.76c7491d-fecb-45d2-92a4-326e23dbff6b@github.com>
 <4BxvAwkwZar8wvkFefsY3YCeW1yYaEh3gxEL16j5gxw=.9e87f0ab-fff0-438a-8825-424312b1ed26@github.com>
Message-ID: <43Dj915AsgKxWBieNmt_6CYtj7SoF94EOyGdev0eQfw=.c4270bf8-deea-4e7d-a7db-39325771db21@github.com>

On Tue, 1 Jul 2025 21:04:02 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> I think the change looks good. Note that I epxpect to have a separate test that verifies the content of JDK product and check if distribution has all expected files.

Make sense. I created https://bugs.openjdk.org/browse/JDK-8361251 for the task.

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

PR Comment: https://git.openjdk.org/jdk/pull/25913#issuecomment-3027032549

From mli at openjdk.org  Wed Jul  2 08:59:49 2025
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 2 Jul 2025 08:59:49 GMT
Subject: RFR: 8360090: [TEST] RISC-V: disable some cds tests on qemu
In-Reply-To: <0Im1TXEP66tejiuNh7TcwwPeW2wsRtM8LY51BCwxAng=.871e86c1-51d4-4269-81cb-8b6f14cb82fe@github.com>
References: <sEU3dcbcF1dX7DVHE3Hu9Vcue6GUeUEAUZ7jY_uQQMI=.eaeeacb1-b9b5-42d7-ac9d-82078f6ac353@github.com>
 <0Im1TXEP66tejiuNh7TcwwPeW2wsRtM8LY51BCwxAng=.871e86c1-51d4-4269-81cb-8b6f14cb82fe@github.com>
Message-ID: <4dTNiv6pLsupOq_lsXvUeLpG-MRJGs4q30Nq2z0_RGc=.2c5cd0da-252e-4240-9c9e-a52e4e16c9d1@github.com>

On Mon, 30 Jun 2025 23:10:22 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Hi,
>> Can you help to review this patch?
>> 
>> CDS does not work well in cross compilation env, this is by desgin, please check `JDKOPT_ENABLE_DISABLE_CDS_ARCHIVE` in make of jdk.
>> 
>> These tests depends on classes.jsa or classes_xxx.jsa which is not generated and will not be generated when build jdk in qemu environment for riscv, so we should disable them when qemu.
>> 
>> Thanks!
>
> You can add new property for your condition in VMProps, saying vm.cds.archive.available that is true is archive is generated for JDK. Since the classes.jsa is mandatory the property should check if classes.jsa exists and if current configuration allows to miss classes.jsa. You could start with adding risc+qemu as a first configuration with optional cds archive.
> Later it could be extended.
> 
> Alternatively you could just throw SkippedException in the tests, assuming that number of them is small. There is an example with isCOHArchiveAvailable() check.

@lmesnik @robehn Thank you for reviewing!

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

PR Comment: https://git.openjdk.org/jdk/pull/25913#issuecomment-3027033552

From tschatzl at openjdk.org  Wed Jul  2 09:15:51 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 2 Jul 2025 09:15:51 GMT
Subject: RFR: 8361238: G1 tries to get CPU info from terminated threads at
 shutdown
Message-ID: <S_kFT9umHG9si2JoeathGFyVdJYf-ejUrOKrdhKwbb0=.406261d3-7962-4c18-981e-3e6aba28b6d4@github.com>

Hi all,

  please review this fix after the recent changes in void JDK-8274051 where G1 tries to get thread cpu time on already terminated threads.

The fix is to move the printing/statistics before stopping the threads. This seems fine for the two implementors of the method.

In a future change, since so few GCs implement `print_tracing_info`, the call should probably move to `stop()/begin_exit()`.

Testing: gha

Thanks,
  Thomas

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

Commit messages:
 - 8361238

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

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

From azeller at openjdk.org  Wed Jul  2 11:07:39 2025
From: azeller at openjdk.org (Arno Zeller)
Date: Wed, 2 Jul 2025 11:07:39 GMT
Subject: RFR: 8361238: G1 tries to get CPU info from terminated threads at
 shutdown
In-Reply-To: <S_kFT9umHG9si2JoeathGFyVdJYf-ejUrOKrdhKwbb0=.406261d3-7962-4c18-981e-3e6aba28b6d4@github.com>
References: <S_kFT9umHG9si2JoeathGFyVdJYf-ejUrOKrdhKwbb0=.406261d3-7962-4c18-981e-3e6aba28b6d4@github.com>
Message-ID: <hetZYi6kpVG1nJrK9IcQlix5MIE4N0JsY_MrHd2wfvY=.8f435f33-859f-4e6e-9786-cd642c08fd89@github.com>

On Wed, 2 Jul 2025 07:57:28 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this fix after the recent changes in void JDK-8274051 where G1 tries to get thread cpu time on already terminated threads.
> 
> The fix is to move the printing/statistics before stopping the threads. This seems fine for the two implementors of the method.
> 
> In a future change, since so few GCs implement `print_tracing_info`, the call should probably move to `stop()/begin_exit()`.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

Looks good to me - just verified that it solves the issues we have seen on AIX in tier1 tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/26086#issuecomment-3027438351

From ayang at openjdk.org  Wed Jul  2 11:26:49 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 2 Jul 2025 11:26:49 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v14]
In-Reply-To: <M1X3PxWm8q4auPjWq_sOczcVrUWLTuxB7Oog8X27SDU=.f824afa5-4204-4dbe-979a-c1249a33d3dc@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <M1X3PxWm8q4auPjWq_sOczcVrUWLTuxB7Oog8X27SDU=.f824afa5-4204-4dbe-979a-c1249a33d3dc@github.com>
Message-ID: <YqWHZkhe8jdAtrtQiHdNbdDUM8YoVG58RpIDgpjGfC0=.88fc1fc5-b831-44ef-b61c-a8c5f3418dc8@github.com>

On Tue, 1 Jul 2025 12:03:08 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc+cpu`.
>> 
>> 
>> [2,430s][info][gc,cpu] GC CPU usage: 22,87% (Process: 26,8926s GC: 6,1491s)
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change output per discussion

src/hotspot/share/gc/shared/collectedHeap.cpp line 211:

> 209: public:
> 210:   virtual void do_thread(Thread* thread) {
> 211:     Atomic::add(&_cpu_time, os::thread_cpu_time(thread));

Should we check for `-1` here?

src/hotspot/share/gc/shared/collectedHeap.cpp line 630:

> 628:     double process_cpu_time = os::elapsed_process_cpu_time();
> 629:     double gc_cpu_time = elapsed_gc_cpu_time();
> 630:     double string_dedup_cpu_time = UseStringDeduplication ? (double)os::thread_cpu_time((Thread*)StringDedup::_processor->_thread) / NANOSECS_PER_SEC : 0;

If we consider stringdedup as gc-time, should this line be inlined to `elapsed_gc_cpu_time`?

src/hotspot/share/gc/shared/collectedHeap.cpp line 634:

> 632:     if (process_cpu_time == -1 || gc_cpu_time == -1 || string_dedup_cpu_time == -1) {
> 633:       return;
> 634:     }

Should there be a warning-log here?

src/hotspot/share/gc/shared/collectedHeap.hpp line 135:

> 133:   NOT_PRODUCT(volatile size_t _promotion_failure_alot_gc_number;)
> 134: 
> 135:   static jlong _vmthread_cpu_time;

I wonder if it's more natural to make it non-static.

src/hotspot/share/gc/shared/collectedHeap.hpp line 212:

> 210: 
> 211:   // Stop any onging concurrent work and prepare for exit.
> 212:   virtual void stop() = 0;

Why `= 0` instead of `{}` as before?

src/hotspot/share/gc/z/zCollectedHeap.cpp line 25:

> 23: 
> 24: #include "classfile/classLoaderData.hpp"
> 25: #include "gc/shared/collectedHeap.inline.hpp"

Seems unneeded.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2179799665
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2179801486
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2179791109
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2179805696
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2179792124
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2179781501

From shade at openjdk.org  Wed Jul  2 11:54:47 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 2 Jul 2025 11:54:47 GMT
Subject: [jdk25] Integrated: 8359436: AOTCompileEagerly should not be
 diagnostic
In-Reply-To: <VnNdAj-u2l5aBroTAIS4QDuKmDLuqA2V4aBcdiNjq18=.b10bea85-c21f-4ca3-8fcc-93c72960b259@github.com>
References: <VnNdAj-u2l5aBroTAIS4QDuKmDLuqA2V4aBcdiNjq18=.b10bea85-c21f-4ca3-8fcc-93c72960b259@github.com>
Message-ID: <BAT_eGQj0YH2Pv4PwFBVFtiDHbjvJmNk8Jyixdb6rTs=.a28d8b85-436d-4426-b218-6f342ede3f59@github.com>

On Tue, 1 Jul 2025 15:33:56 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Backporting under granted JDK 25 enhancement request.

This pull request has now been integrated.

Changeset: b245c517
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b245c517e39086d8e90313d6d35be6f9062a67ce
Stats:     103 lines in 2 files changed: 102 ins; 0 del; 1 mod

8359436: AOTCompileEagerly should not be diagnostic

Reviewed-by: kvn
Backport-of: e138297323de3f6990c4c536b1cefd209ce3a69c

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

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

From shade at openjdk.org  Wed Jul  2 11:54:46 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 2 Jul 2025 11:54:46 GMT
Subject: [jdk25] RFR: 8359436: AOTCompileEagerly should not be diagnostic
In-Reply-To: <VnNdAj-u2l5aBroTAIS4QDuKmDLuqA2V4aBcdiNjq18=.b10bea85-c21f-4ca3-8fcc-93c72960b259@github.com>
References: <VnNdAj-u2l5aBroTAIS4QDuKmDLuqA2V4aBcdiNjq18=.b10bea85-c21f-4ca3-8fcc-93c72960b259@github.com>
Message-ID: <LH6nGHpdfFU-8uV78cmvXIoaQOexVYU8KrQijfuoShg=.6c2913e7-f5e0-4b65-ab4b-b3c5f2cf33c8@github.com>

On Tue, 1 Jul 2025 15:33:56 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Backporting under granted JDK 25 enhancement request.

Thanks! Here goes.

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

PR Comment: https://git.openjdk.org/jdk/pull/26073#issuecomment-3027584160

From kbarrett at openjdk.org  Wed Jul  2 16:01:51 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 2 Jul 2025 16:01:51 GMT
Subject: RFR: 8361238: G1 tries to get CPU info from terminated threads at
 shutdown
In-Reply-To: <S_kFT9umHG9si2JoeathGFyVdJYf-ejUrOKrdhKwbb0=.406261d3-7962-4c18-981e-3e6aba28b6d4@github.com>
References: <S_kFT9umHG9si2JoeathGFyVdJYf-ejUrOKrdhKwbb0=.406261d3-7962-4c18-981e-3e6aba28b6d4@github.com>
Message-ID: <TtVXe7euoWy7WsdodfkunCom9wYCvm1xSBS8Q1_0U4g=.906c71f4-cfa0-4ca1-9ab6-5a26955df25b@github.com>

On Wed, 2 Jul 2025 07:57:28 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this fix after the recent changes in void JDK-8274051 where G1 tries to get thread cpu time on already terminated threads.
> 
> The fix is to move the printing/statistics before stopping the threads. This seems fine for the two implementors of the method.
> 
> In a future change, since so few GCs implement `print_tracing_info`, the call should probably move to `stop()/begin_exit()`.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26086#pullrequestreview-2979755321

From duke at openjdk.org  Wed Jul  2 16:35:45 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Wed, 2 Jul 2025 16:35:45 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v14]
In-Reply-To: <YqWHZkhe8jdAtrtQiHdNbdDUM8YoVG58RpIDgpjGfC0=.88fc1fc5-b831-44ef-b61c-a8c5f3418dc8@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <M1X3PxWm8q4auPjWq_sOczcVrUWLTuxB7Oog8X27SDU=.f824afa5-4204-4dbe-979a-c1249a33d3dc@github.com>
 <YqWHZkhe8jdAtrtQiHdNbdDUM8YoVG58RpIDgpjGfC0=.88fc1fc5-b831-44ef-b61c-a8c5f3418dc8@github.com>
Message-ID: <5gxjJvYO7p9nN5ocu_mYS8lPX4RtL-_FLwQlqnuVCIk=.3626e6cc-b927-4c89-b026-9affa4d4e272@github.com>

On Wed, 2 Jul 2025 11:22:08 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:
>> 
>>   Change output per discussion
>
> src/hotspot/share/gc/shared/collectedHeap.cpp line 630:
> 
>> 628:     double process_cpu_time = os::elapsed_process_cpu_time();
>> 629:     double gc_cpu_time = elapsed_gc_cpu_time();
>> 630:     double string_dedup_cpu_time = UseStringDeduplication ? (double)os::thread_cpu_time((Thread*)StringDedup::_processor->_thread) / NANOSECS_PER_SEC : 0;
> 
> If we consider stringdedup as gc-time, should this line be inlined to `elapsed_gc_cpu_time`?

I'd prefer not to, as it is strictly not GC-time and we may want to use these methods in other places in the future.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2180503221

From duke at openjdk.org  Wed Jul  2 16:50:43 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Wed, 2 Jul 2025 16:50:43 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v14]
In-Reply-To: <YqWHZkhe8jdAtrtQiHdNbdDUM8YoVG58RpIDgpjGfC0=.88fc1fc5-b831-44ef-b61c-a8c5f3418dc8@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <M1X3PxWm8q4auPjWq_sOczcVrUWLTuxB7Oog8X27SDU=.f824afa5-4204-4dbe-979a-c1249a33d3dc@github.com>
 <YqWHZkhe8jdAtrtQiHdNbdDUM8YoVG58RpIDgpjGfC0=.88fc1fc5-b831-44ef-b61c-a8c5f3418dc8@github.com>
Message-ID: <33ZNj2C1QBn0aj20urwxjuyokqysfQVJQ6P9YWI8-B0=.73b336fa-e00c-4705-96ff-5385c3f8ba54@github.com>

On Wed, 2 Jul 2025 11:24:09 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:
>> 
>>   Change output per discussion
>
> src/hotspot/share/gc/shared/collectedHeap.hpp line 135:
> 
>> 133:   NOT_PRODUCT(volatile size_t _promotion_failure_alot_gc_number;)
>> 134: 
>> 135:   static jlong _vmthread_cpu_time;
> 
> I wonder if it's more natural to make it non-static.

Could you please elaborate? Other variables like `static size_t _stack_chunk_max_size` is also static.

> src/hotspot/share/gc/shared/collectedHeap.hpp line 212:
> 
>> 210: 
>> 211:   // Stop any onging concurrent work and prepare for exit.
>> 212:   virtual void stop() = 0;
> 
> Why `= 0` instead of `{}` as before?

It was suggested by @stefank in above discussions. https://github.com/openjdk/jdk/pull/25779#discussion_r2162341225 Is this something you think we should revert?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2180532088
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2180534726

From duke at openjdk.org  Wed Jul  2 17:01:28 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Wed, 2 Jul 2025 17:01:28 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v15]
In-Reply-To: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
Message-ID: <8CI578A5O8a_0TRQq7PXcHppypgvYSl9RiLtlUAeBpo=.8930c53e-ecc8-4102-9daa-b3944acccb48@github.com>

> Add support to log CPU cost for GC during VM exit with `-Xlog:gc+cpu`.
> 
> 
> [2,430s][info][gc,cpu] GC CPU usage: 22,87% (Process: 26,8926s GC: 6,1491s)

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

  Fixes after @albertnetymk review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25779/files
  - new: https://git.openjdk.org/jdk/pull/25779/files/3104ff6a..08093057

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=13-14

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

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

From mli at openjdk.org  Wed Jul  2 17:18:44 2025
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 2 Jul 2025 17:18:44 GMT
Subject: Integrated: 8360090: [TEST] RISC-V: disable some cds tests on qemu
In-Reply-To: <sEU3dcbcF1dX7DVHE3Hu9Vcue6GUeUEAUZ7jY_uQQMI=.eaeeacb1-b9b5-42d7-ac9d-82078f6ac353@github.com>
References: <sEU3dcbcF1dX7DVHE3Hu9Vcue6GUeUEAUZ7jY_uQQMI=.eaeeacb1-b9b5-42d7-ac9d-82078f6ac353@github.com>
Message-ID: <CVOHjcvCov_siYXMagIn51GxqI2cliqqBf3jIr4mlno=.55ecc82c-1830-4377-a3a5-d7ef1b753711@github.com>

On Fri, 20 Jun 2025 09:27:14 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> Can you help to review this patch?
> 
> CDS does not work well in cross compilation env, this is by desgin, please check `JDKOPT_ENABLE_DISABLE_CDS_ARCHIVE` in make of jdk.
> 
> These tests depends on classes.jsa or classes_xxx.jsa which is not generated and will not be generated when build jdk in qemu environment for riscv, so we should disable them when qemu.
> 
> Thanks!

This pull request has now been integrated.

Changeset: c5037059
Author:    Hamlin Li <mli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c50370599e40bfaeccba9aa6b28da661129f9450
Stats:     21 lines in 6 files changed: 19 ins; 0 del; 2 mod

8360090: [TEST] RISC-V: disable some cds tests on qemu

Reviewed-by: lmesnik, rehn

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

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

From sangheki at openjdk.org  Thu Jul  3 00:19:38 2025
From: sangheki at openjdk.org (Sangheon Kim)
Date: Thu, 3 Jul 2025 00:19:38 GMT
Subject: RFR: 8361238: G1 tries to get CPU info from terminated threads at
 shutdown
In-Reply-To: <S_kFT9umHG9si2JoeathGFyVdJYf-ejUrOKrdhKwbb0=.406261d3-7962-4c18-981e-3e6aba28b6d4@github.com>
References: <S_kFT9umHG9si2JoeathGFyVdJYf-ejUrOKrdhKwbb0=.406261d3-7962-4c18-981e-3e6aba28b6d4@github.com>
Message-ID: <PcrhYnlgWjCxBp55U1vcNBfhuM8f8Sm7b2OfFGeLXzQ=.9c08b4df-a678-4387-a3f6-e8fa651bdb0a@github.com>

On Wed, 2 Jul 2025 07:57:28 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this fix after the recent changes in void JDK-8274051 where G1 tries to get thread cpu time on already terminated threads.
> 
> The fix is to move the printing/statistics before stopping the threads. This seems fine for the two implementors of the method.
> 
> In a future change, since so few GCs implement `print_tracing_info`, the call should probably move to `stop()/begin_exit()`.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

LGTM

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

Marked as reviewed by sangheki (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26086#pullrequestreview-2981003924

From ayang at openjdk.org  Thu Jul  3 06:40:44 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 3 Jul 2025 06:40:44 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v14]
In-Reply-To: <5gxjJvYO7p9nN5ocu_mYS8lPX4RtL-_FLwQlqnuVCIk=.3626e6cc-b927-4c89-b026-9affa4d4e272@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <M1X3PxWm8q4auPjWq_sOczcVrUWLTuxB7Oog8X27SDU=.f824afa5-4204-4dbe-979a-c1249a33d3dc@github.com>
 <YqWHZkhe8jdAtrtQiHdNbdDUM8YoVG58RpIDgpjGfC0=.88fc1fc5-b831-44ef-b61c-a8c5f3418dc8@github.com>
 <5gxjJvYO7p9nN5ocu_mYS8lPX4RtL-_FLwQlqnuVCIk=.3626e6cc-b927-4c89-b026-9affa4d4e272@github.com>
Message-ID: <xXn0o0rIwotlmlz4_Akcte9dFM2-__VOk9XIva7EJ8E=.6f86fecb-a8c6-4b67-abac-958eee215f12@github.com>

On Wed, 2 Jul 2025 16:32:31 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/collectedHeap.cpp line 630:
>> 
>>> 628:     double process_cpu_time = os::elapsed_process_cpu_time();
>>> 629:     double gc_cpu_time = elapsed_gc_cpu_time();
>>> 630:     double string_dedup_cpu_time = UseStringDeduplication ? (double)os::thread_cpu_time((Thread*)StringDedup::_processor->_thread) / NANOSECS_PER_SEC : 0;
>> 
>> If we consider stringdedup as gc-time, should this line be inlined to `elapsed_gc_cpu_time`?
>
> I'd prefer not to, as it is strictly not GC-time and we may want to use these methods in other places in the future.

That would result into inconsistency, because we surely treat them as gc-time here. It'd be super confusing if the def of gc-time is not coherent inside JVM.

>> src/hotspot/share/gc/shared/collectedHeap.hpp line 135:
>> 
>>> 133:   NOT_PRODUCT(volatile size_t _promotion_failure_alot_gc_number;)
>>> 134: 
>>> 135:   static jlong _vmthread_cpu_time;
>> 
>> I wonder if it's more natural to make it non-static.
>
> Could you please elaborate? Other variables like `static size_t _stack_chunk_max_size` is also static.

This class contains both static and non-static fields. Since `_vmthread_cpu_time` is accessed in `elapsed_gc_cpu_time` (non-static), I tend to think it should be non-static. (`add_vmthread_cpu_time` is static, but its sole caller actually use the instance, i.e. dropping the static for it still compiles.)

>> src/hotspot/share/gc/shared/collectedHeap.hpp line 212:
>> 
>>> 210: 
>>> 211:   // Stop any onging concurrent work and prepare for exit.
>>> 212:   virtual void stop() = 0;
>> 
>> Why `= 0` instead of `{}` as before?
>
> It was suggested by @stefank in above discussions. https://github.com/openjdk/jdk/pull/25779#discussion_r2162341225 Is this something you think we should revert?

I understand the part of splitting it into two methods, but why making it pure-virtual? Wouldn't `{}` as before work?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2180979113
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2180969511
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2180975563

From tschatzl at openjdk.org  Thu Jul  3 07:01:53 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 3 Jul 2025 07:01:53 GMT
Subject: RFR: 8361238: G1 tries to get CPU info from terminated threads at
 shutdown
In-Reply-To: <TtVXe7euoWy7WsdodfkunCom9wYCvm1xSBS8Q1_0U4g=.906c71f4-cfa0-4ca1-9ab6-5a26955df25b@github.com>
References: <S_kFT9umHG9si2JoeathGFyVdJYf-ejUrOKrdhKwbb0=.406261d3-7962-4c18-981e-3e6aba28b6d4@github.com>
 <TtVXe7euoWy7WsdodfkunCom9wYCvm1xSBS8Q1_0U4g=.906c71f4-cfa0-4ca1-9ab6-5a26955df25b@github.com>
Message-ID: <E8M2JruuLu3ByeD4-Exf_KB7Qyq8wSceBxa5HXfeWnc=.d8bd2b16-6832-4052-8b45-d5315e96f3dd@github.com>

On Wed, 2 Jul 2025 15:58:46 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this fix after the recent changes in void JDK-8274051 where G1 tries to get thread cpu time on already terminated threads.
>> 
>> The fix is to move the printing/statistics before stopping the threads. This seems fine for the two implementors of the method.
>> 
>> In a future change, since so few GCs implement `print_tracing_info`, the call should probably move to `stop()/begin_exit()`.
>> 
>> Testing: gha
>> 
>> Thanks,
>>   Thomas
>
> Looks good.

Thanks @kimbarrett @sangheon for your reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/26086#issuecomment-3031103688

From tschatzl at openjdk.org  Thu Jul  3 07:01:54 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 3 Jul 2025 07:01:54 GMT
Subject: Integrated: 8361238: G1 tries to get CPU info from terminated threads
 at shutdown
In-Reply-To: <S_kFT9umHG9si2JoeathGFyVdJYf-ejUrOKrdhKwbb0=.406261d3-7962-4c18-981e-3e6aba28b6d4@github.com>
References: <S_kFT9umHG9si2JoeathGFyVdJYf-ejUrOKrdhKwbb0=.406261d3-7962-4c18-981e-3e6aba28b6d4@github.com>
Message-ID: <ORA3SqPqj-uklmgHI9C7ioxlYK-i1Wh2i1KHgHDWM6Q=.22beb082-d431-4f20-bd82-1674829dcc9e@github.com>

On Wed, 2 Jul 2025 07:57:28 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this fix after the recent changes in void JDK-8274051 where G1 tries to get thread cpu time on already terminated threads.
> 
> The fix is to move the printing/statistics before stopping the threads. This seems fine for the two implementors of the method.
> 
> In a future change, since so few GCs implement `print_tracing_info`, the call should probably move to `stop()/begin_exit()`.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 6c9236c8
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6c9236c80c236487a7c37dcb947c0f9192322208
Stats:     2 lines in 1 file changed: 1 ins; 1 del; 0 mod

8361238: G1 tries to get CPU info from terminated threads at shutdown

Reviewed-by: kbarrett, sangheki

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

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

From duke at openjdk.org  Thu Jul  3 07:15:43 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 3 Jul 2025 07:15:43 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v14]
In-Reply-To: <xXn0o0rIwotlmlz4_Akcte9dFM2-__VOk9XIva7EJ8E=.6f86fecb-a8c6-4b67-abac-958eee215f12@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <M1X3PxWm8q4auPjWq_sOczcVrUWLTuxB7Oog8X27SDU=.f824afa5-4204-4dbe-979a-c1249a33d3dc@github.com>
 <YqWHZkhe8jdAtrtQiHdNbdDUM8YoVG58RpIDgpjGfC0=.88fc1fc5-b831-44ef-b61c-a8c5f3418dc8@github.com>
 <5gxjJvYO7p9nN5ocu_mYS8lPX4RtL-_FLwQlqnuVCIk=.3626e6cc-b927-4c89-b026-9affa4d4e272@github.com>
 <xXn0o0rIwotlmlz4_Akcte9dFM2-__VOk9XIva7EJ8E=.6f86fecb-a8c6-4b67-abac-958eee215f12@github.com>
Message-ID: <o2HJ-mJZUvdhlLJUj2IFJScbBnZC1I6H2lMuGrM3JC0=.4e7ef168-3bb4-486b-a9bb-8fb2602e3985@github.com>

On Wed, 2 Jul 2025 21:11:04 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> I'd prefer not to, as it is strictly not GC-time and we may want to use these methods in other places in the future.
>
> That would result into inconsistency, because we surely treat them as gc-time here. It'd be super confusing if the def of gc-time is not coherent inside JVM.

OK, if we ever want to report these separately we can deal with that then. I will move it.

>> It was suggested by @stefank in above discussions. https://github.com/openjdk/jdk/pull/25779#discussion_r2162341225 Is this something you think we should revert?
>
> I understand the part of splitting it into two methods, but why making it pure-virtual? Wouldn't `{}` as before work?

Both works. I believe it was a stylistic choice.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2182033010
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2182034682

From jsjolen at openjdk.org  Thu Jul  3 07:33:40 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 3 Jul 2025 07:33:40 GMT
Subject: RFR: 8357601: Checked version of JNI Release<type>ArrayElements
 needs to filter out known wrapped arrays
In-Reply-To: <Zg4Zabq290iG7P02xAkGT_fHXEsur-GE-w4-piJYc0E=.e0c38720-75bd-4b2a-9d6f-a225749b5a29@github.com>
References: <Zg4Zabq290iG7P02xAkGT_fHXEsur-GE-w4-piJYc0E=.e0c38720-75bd-4b2a-9d6f-a225749b5a29@github.com>
Message-ID: <w7vQUXXc-vl7ftD658Cxya47RE1nAC0A67U8q9F3WwE=.913fdbe7-8ed2-4f22-a1e6-69da6c10b9ce@github.com>

On Mon, 26 May 2025 08:56:09 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The checked version of `Get`/`Release<type>ArrayElements` uses `GuardedMemory` to perform error checking. When releasing the array the code needs to check for the known array tags from the other JNI APIs and report an error.
> 
> We also expand `GuardedMemory` to allow for a second tag word so that we can discriminate additional allocation sites i.e. identifying use of `Get`/`SetPrimitiveArrayCritical`. And add further robustness to guard verification by using `SafeFetch`.
> 
> Testing
>  - new test
>  - Tiers 1-4 (sanity)

LGTM

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

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25444#pullrequestreview-2982067633

From duke at openjdk.org  Thu Jul  3 07:36:02 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 3 Jul 2025 07:36:02 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v16]
In-Reply-To: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
Message-ID: <oXU0PCFvdFMsAk0_0fJxydUm_poeQIXoIljfr_7zNTc=.1b69c062-3f69-4314-ab9a-68fc2946bf5a@github.com>

> Add support to log CPU cost for GC during VM exit with `-Xlog:gc+cpu`.
> 
> 
> [2,430s][info][gc,cpu] GC CPU usage: 22,87% (Process: 26,8926s GC: 6,1491s)

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

  Remove static and move string_dedup_cpu_time into elapsed_gc_cpu_time

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25779/files
  - new: https://git.openjdk.org/jdk/pull/25779/files/08093057..d4c7c69b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=14-15

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

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

From duke at openjdk.org  Thu Jul  3 07:40:56 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 3 Jul 2025 07:40:56 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v17]
In-Reply-To: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
Message-ID: <-4_N96vrUHQqE9FrFW9s3728cjGucdMFEvjFNYY7FoQ=.d651e847-4041-44f3-842e-56221a878430@github.com>

> Add support to log CPU cost for GC during VM exit with `-Xlog:gc+cpu`.
> 
> 
> [2,430s][info][gc,cpu] GC CPU usage: 22,87% (Process: 26,8926s GC: 6,1491s)

Jonas Norlinder has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits:

 - Move call to print_tracing_info
 - Merge branch 'master' into gc_cpu_time
 - Remove static and move string_dedup_cpu_time into elapsed_gc_cpu_time
 - Fixes after @albertnetymk review
 - Change output per discussion
 - Make stop protected, remove integer divison, remove unused method
 - Update closure name
 - vtime -> cpu_time and _vm_vtime -> _vmthread_cpu_time
 - Fixes after review from @stefank
 - Merge branch 'master' of github.com:JonasNorlinder/openjdk_jdk into gc_cpu_time
 - ... and 17 more: https://git.openjdk.org/jdk/compare/c75df634...f9c3aa64

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

Changes: https://git.openjdk.org/jdk/pull/25779/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=16
  Stats: 258 lines in 16 files changed: 244 ins; 9 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/25779.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25779/head:pull/25779

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

From mbaesken at openjdk.org  Thu Jul  3 07:55:20 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 3 Jul 2025 07:55:20 GMT
Subject: RFR: 8361198: [AIX] fix misleading error output in
 thread_cpu_time_unchecked [v2]
In-Reply-To: <wOj72AJP6g77WdCgbn1CYRmTO3P4skVYZwvUc5fOfe4=.c64e73b3-2573-46ba-8c85-10eb91a59838@github.com>
References: <wOj72AJP6g77WdCgbn1CYRmTO3P4skVYZwvUc5fOfe4=.c64e73b3-2573-46ba-8c85-10eb91a59838@github.com>
Message-ID: <XWz2Y1rmj30KdPlRrYlrRUJ7RfhutaWWxY8NFlSyWKI=.a751dd0a-4a3d-41f2-ace7-972459400836@github.com>

> Currently we have on AIX in thread_cpu_time_unchecked misleading error output in case of failing getthrds64 . This should be adjusted .

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

  pthread_getthrds_np failures - output errno too

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26070/files
  - new: https://git.openjdk.org/jdk/pull/26070/files/a190f427..b4373c42

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

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

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

From ayang at openjdk.org  Thu Jul  3 08:17:44 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 3 Jul 2025 08:17:44 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v17]
In-Reply-To: <-4_N96vrUHQqE9FrFW9s3728cjGucdMFEvjFNYY7FoQ=.d651e847-4041-44f3-842e-56221a878430@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <-4_N96vrUHQqE9FrFW9s3728cjGucdMFEvjFNYY7FoQ=.d651e847-4041-44f3-842e-56221a878430@github.com>
Message-ID: <cNDd6TUQMoiSQaniJEYeBkY-fvAZaAIj687PQdk3WOQ=.6f666493-a5be-4a18-ac6a-2ba27ed156d2@github.com>

On Thu, 3 Jul 2025 07:40:56 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc+cpu`.
>> 
>> 
>> [2,430s][info][gc,cpu] GC CPU usage: 22,87% (Process: 26,8926s GC: 6,1491s)
>
> Jonas Norlinder has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits:
> 
>  - Move call to print_tracing_info
>  - Merge branch 'master' into gc_cpu_time
>  - Remove static and move string_dedup_cpu_time into elapsed_gc_cpu_time
>  - Fixes after @albertnetymk review
>  - Change output per discussion
>  - Make stop protected, remove integer divison, remove unused method
>  - Update closure name
>  - vtime -> cpu_time and _vm_vtime -> _vmthread_cpu_time
>  - Fixes after review from @stefank
>  - Merge branch 'master' of github.com:JonasNorlinder/openjdk_jdk into gc_cpu_time
>  - ... and 17 more: https://git.openjdk.org/jdk/compare/c75df634...f9c3aa64

src/hotspot/share/gc/shared/collectedHeap.cpp line 206:

> 204: class CPUTimeThreadClosure : public ThreadClosure {
> 205: private:
> 206:   volatile jlong _cpu_time = 0;

There is no need for `volatile`. `gc_threads_do` runs on the calling thread, not on threads we are iterating on.

src/hotspot/share/gc/shared/collectedHeap.cpp line 226:

> 224:   if (string_dedup_cpu_time == -1) {
> 225:     return -1;
> 226:   }

Can probably move this to the very beginning for clearer separation: gc-time comes from three sources -- vmthread, string-dedup and gc-threads.

src/hotspot/share/gc/shared/cpuTimeScope.inline.hpp line 57:

> 55:   if (UsePerfData) {
> 56:     CPUTimeCounters::get_instance()->update_counter(CPUTimeGroups::CPUTimeType::vm, end);
> 57:   }

This class (name/interface) seems fairly generic, but the underlying impl is tightly coupled to vmthread. IOW, one can't use this class other than on vmthread. Maybe this class should be inside vmThread.cpp.

src/hotspot/share/runtime/cpuTimeCounters.hpp line 56:

> 54: 
> 55: class CPUTimeCounters: public CHeapObj<mtServiceability> {
> 56:   friend class CPUTimeScope;

I wonder if we avoid this. The public APIs should be enough.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2182127690
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2182131415
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2182146520
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2182156134

From ayang at openjdk.org  Thu Jul  3 08:17:45 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 3 Jul 2025 08:17:45 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v14]
In-Reply-To: <o2HJ-mJZUvdhlLJUj2IFJScbBnZC1I6H2lMuGrM3JC0=.4e7ef168-3bb4-486b-a9bb-8fb2602e3985@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <M1X3PxWm8q4auPjWq_sOczcVrUWLTuxB7Oog8X27SDU=.f824afa5-4204-4dbe-979a-c1249a33d3dc@github.com>
 <YqWHZkhe8jdAtrtQiHdNbdDUM8YoVG58RpIDgpjGfC0=.88fc1fc5-b831-44ef-b61c-a8c5f3418dc8@github.com>
 <5gxjJvYO7p9nN5ocu_mYS8lPX4RtL-_FLwQlqnuVCIk=.3626e6cc-b927-4c89-b026-9affa4d4e272@github.com>
 <xXn0o0rIwotlmlz4_Akcte9dFM2-__VOk9XIva7EJ8E=.6f86fecb-a8c6-4b67-abac-958eee215f12@github.com>
 <o2HJ-mJZUvdhlLJUj2IFJScbBnZC1I6H2lMuGrM3JC0=.4e7ef168-3bb4-486b-a9bb-8fb2602e3985@github.com>
Message-ID: <dXW1gV7uqON89fRcIFdANOn1EV5DJlUyHfXLQxaSqgw=.21fc3ddd-4792-48ae-923f-0b960da43226@github.com>

On Thu, 3 Jul 2025 07:13:14 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> I understand the part of splitting it into two methods, but why making it pure-virtual? Wouldn't `{}` as before work?
>
> Both works. I believe it was a stylistic choice.

I see; I'd prefer reverting this, as that reduces the diff size, but up to you.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2182134255

From azeller at openjdk.org  Thu Jul  3 08:20:39 2025
From: azeller at openjdk.org (Arno Zeller)
Date: Thu, 3 Jul 2025 08:20:39 GMT
Subject: RFR: 8361198: [AIX] fix misleading error output in
 thread_cpu_time_unchecked [v2]
In-Reply-To: <XWz2Y1rmj30KdPlRrYlrRUJ7RfhutaWWxY8NFlSyWKI=.a751dd0a-4a3d-41f2-ace7-972459400836@github.com>
References: <wOj72AJP6g77WdCgbn1CYRmTO3P4skVYZwvUc5fOfe4=.c64e73b3-2573-46ba-8c85-10eb91a59838@github.com>
 <XWz2Y1rmj30KdPlRrYlrRUJ7RfhutaWWxY8NFlSyWKI=.a751dd0a-4a3d-41f2-ace7-972459400836@github.com>
Message-ID: <PEOIchClVjSenzpzXy_rtITk8Clk2OufGPocwwYaWLo=.9f9bcaa5-12c8-4e4a-ac87-e1efe834b34a@github.com>

On Thu, 3 Jul 2025 07:55:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently we have on AIX in thread_cpu_time_unchecked misleading error output in case of failing getthrds64 . This should be adjusted .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   pthread_getthrds_np failures - output errno too

Looks good to me.

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

Marked as reviewed by azeller (Author).

PR Review: https://git.openjdk.org/jdk/pull/26070#pullrequestreview-2982203156

From duke at openjdk.org  Thu Jul  3 08:50:46 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 3 Jul 2025 08:50:46 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v17]
In-Reply-To: <cNDd6TUQMoiSQaniJEYeBkY-fvAZaAIj687PQdk3WOQ=.6f666493-a5be-4a18-ac6a-2ba27ed156d2@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <-4_N96vrUHQqE9FrFW9s3728cjGucdMFEvjFNYY7FoQ=.d651e847-4041-44f3-842e-56221a878430@github.com>
 <cNDd6TUQMoiSQaniJEYeBkY-fvAZaAIj687PQdk3WOQ=.6f666493-a5be-4a18-ac6a-2ba27ed156d2@github.com>
Message-ID: <1byklOUoicnZLix7PmzKBpAWfC_D1vCU22tRRsteank=.844a8042-3546-4e68-ac12-6ad5fb92a0ca@github.com>

On Thu, 3 Jul 2025 08:14:04 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Jonas Norlinder has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits:
>> 
>>  - Move call to print_tracing_info
>>  - Merge branch 'master' into gc_cpu_time
>>  - Remove static and move string_dedup_cpu_time into elapsed_gc_cpu_time
>>  - Fixes after @albertnetymk review
>>  - Change output per discussion
>>  - Make stop protected, remove integer divison, remove unused method
>>  - Update closure name
>>  - vtime -> cpu_time and _vm_vtime -> _vmthread_cpu_time
>>  - Fixes after review from @stefank
>>  - Merge branch 'master' of github.com:JonasNorlinder/openjdk_jdk into gc_cpu_time
>>  - ... and 17 more: https://git.openjdk.org/jdk/compare/c75df634...f9c3aa64
>
> src/hotspot/share/runtime/cpuTimeCounters.hpp line 56:
> 
>> 54: 
>> 55: class CPUTimeCounters: public CHeapObj<mtServiceability> {
>> 56:   friend class CPUTimeScope;
> 
> I wonder if we avoid this. The public APIs should be enough.

get_instance() is private. It was not clear to me if we would want to change get_instance() to public

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2182226865

From mbaesken at openjdk.org  Thu Jul  3 08:58:39 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 3 Jul 2025 08:58:39 GMT
Subject: RFR: 8361198: [AIX] fix misleading error output in
 thread_cpu_time_unchecked [v2]
In-Reply-To: <XWz2Y1rmj30KdPlRrYlrRUJ7RfhutaWWxY8NFlSyWKI=.a751dd0a-4a3d-41f2-ace7-972459400836@github.com>
References: <wOj72AJP6g77WdCgbn1CYRmTO3P4skVYZwvUc5fOfe4=.c64e73b3-2573-46ba-8c85-10eb91a59838@github.com>
 <XWz2Y1rmj30KdPlRrYlrRUJ7RfhutaWWxY8NFlSyWKI=.a751dd0a-4a3d-41f2-ace7-972459400836@github.com>
Message-ID: <WChVNLnjxfF6BFrLxDmj85yfAr9kSPmnRhDWjL6IRfs=.6752c5d3-578d-48f2-80a4-f17f4589b427@github.com>

On Thu, 3 Jul 2025 07:55:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently we have on AIX in thread_cpu_time_unchecked misleading error output in case of failing getthrds64 . This should be adjusted .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   pthread_getthrds_np failures - output errno too

Thanks for the reviews !
The tty output is also 'not so nice' , we might change this later to something better but not today .

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

PR Comment: https://git.openjdk.org/jdk/pull/26070#issuecomment-3031450011

From duke at openjdk.org  Thu Jul  3 08:59:49 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 3 Jul 2025 08:59:49 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v17]
In-Reply-To: <cNDd6TUQMoiSQaniJEYeBkY-fvAZaAIj687PQdk3WOQ=.6f666493-a5be-4a18-ac6a-2ba27ed156d2@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <-4_N96vrUHQqE9FrFW9s3728cjGucdMFEvjFNYY7FoQ=.d651e847-4041-44f3-842e-56221a878430@github.com>
 <cNDd6TUQMoiSQaniJEYeBkY-fvAZaAIj687PQdk3WOQ=.6f666493-a5be-4a18-ac6a-2ba27ed156d2@github.com>
Message-ID: <xaNyGPU0qjjngSwM4JemG_C_KhL3iVihaZjIdcJPLNs=.42dcce70-3ef1-464e-80f0-826855815ee5@github.com>

On Thu, 3 Jul 2025 08:09:35 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Jonas Norlinder has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits:
>> 
>>  - Move call to print_tracing_info
>>  - Merge branch 'master' into gc_cpu_time
>>  - Remove static and move string_dedup_cpu_time into elapsed_gc_cpu_time
>>  - Fixes after @albertnetymk review
>>  - Change output per discussion
>>  - Make stop protected, remove integer divison, remove unused method
>>  - Update closure name
>>  - vtime -> cpu_time and _vm_vtime -> _vmthread_cpu_time
>>  - Fixes after review from @stefank
>>  - Merge branch 'master' of github.com:JonasNorlinder/openjdk_jdk into gc_cpu_time
>>  - ... and 17 more: https://git.openjdk.org/jdk/compare/c75df634...f9c3aa64
>
> src/hotspot/share/gc/shared/cpuTimeScope.inline.hpp line 57:
> 
>> 55:   if (UsePerfData) {
>> 56:     CPUTimeCounters::get_instance()->update_counter(CPUTimeGroups::CPUTimeType::vm, end);
>> 57:   }
> 
> This class (name/interface) seems fairly generic, but the underlying impl is tightly coupled to vmthread. IOW, one can't use this class other than on vmthread. Maybe this class should be inside vmThread.cpp.

Good point. I think the class mostly belong in shared/gc so I will rename it to something more specific.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2182244772

From duke at openjdk.org  Thu Jul  3 09:06:06 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 3 Jul 2025 09:06:06 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v18]
In-Reply-To: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
Message-ID: <Ekyv2ZHZeFh7HQHYHXfwE2gUomcTPzIfyWv7gY7BSFs=.5f8cbf88-0c71-49cc-81ce-1ede650b37e6@github.com>

> Add support to log CPU cost for GC during VM exit with `-Xlog:gc+cpu`.
> 
> 
> [2,430s][info][gc,cpu] GC CPU usage: 22,87% (Process: 26,8926s GC: 6,1491s)

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

  CPUTimeScope->VMThreadCPUTimeScope, remove volatile and reorder elapsed_gc_cpu_time

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25779/files
  - new: https://git.openjdk.org/jdk/pull/25779/files/f9c3aa64..5694d6f3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=16-17

  Stats: 102 lines in 6 files changed: 47 ins; 46 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/25779.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25779/head:pull/25779

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

From mdoerr at openjdk.org  Thu Jul  3 09:48:39 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 3 Jul 2025 09:48:39 GMT
Subject: RFR: 8361198: [AIX] fix misleading error output in
 thread_cpu_time_unchecked [v2]
In-Reply-To: <XWz2Y1rmj30KdPlRrYlrRUJ7RfhutaWWxY8NFlSyWKI=.a751dd0a-4a3d-41f2-ace7-972459400836@github.com>
References: <wOj72AJP6g77WdCgbn1CYRmTO3P4skVYZwvUc5fOfe4=.c64e73b3-2573-46ba-8c85-10eb91a59838@github.com>
 <XWz2Y1rmj30KdPlRrYlrRUJ7RfhutaWWxY8NFlSyWKI=.a751dd0a-4a3d-41f2-ace7-972459400836@github.com>
Message-ID: <WW-Yl9c3JjK6w8yTYEDf_YDrdWJRCXQYLS5_1cxTgeY=.3031c7fb-81b0-4e14-9b27-8917084a574c@github.com>

On Thu, 3 Jul 2025 07:55:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently we have on AIX in thread_cpu_time_unchecked misleading error output in case of failing getthrds64 . This should be adjusted .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   pthread_getthrds_np failures - output errno too

Marked as reviewed by mdoerr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26070#pullrequestreview-2982502089

From ayang at openjdk.org  Thu Jul  3 10:07:44 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 3 Jul 2025 10:07:44 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v17]
In-Reply-To: <1byklOUoicnZLix7PmzKBpAWfC_D1vCU22tRRsteank=.844a8042-3546-4e68-ac12-6ad5fb92a0ca@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <-4_N96vrUHQqE9FrFW9s3728cjGucdMFEvjFNYY7FoQ=.d651e847-4041-44f3-842e-56221a878430@github.com>
 <cNDd6TUQMoiSQaniJEYeBkY-fvAZaAIj687PQdk3WOQ=.6f666493-a5be-4a18-ac6a-2ba27ed156d2@github.com>
 <1byklOUoicnZLix7PmzKBpAWfC_D1vCU22tRRsteank=.844a8042-3546-4e68-ac12-6ad5fb92a0ca@github.com>
Message-ID: <pyW7roEt9wrFak4wIM-Si8ygD7DypHU-6osLSYdveXU=.0a4eaeee-5c6a-432d-9f36-bb82dd3d5842@github.com>

On Thu, 3 Jul 2025 08:48:21 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> src/hotspot/share/runtime/cpuTimeCounters.hpp line 56:
>> 
>>> 54: 
>>> 55: class CPUTimeCounters: public CHeapObj<mtServiceability> {
>>> 56:   friend class CPUTimeScope;
>> 
>> I wonder if we avoid this. The public APIs should be enough.
>
> get_instance() is private. It was not clear to me if we would want to change get_instance() to public

Why do you need `get_instance`? Can you use the public static API?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2182389263

From duke at openjdk.org  Thu Jul  3 10:24:40 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 3 Jul 2025 10:24:40 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v19]
In-Reply-To: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
Message-ID: <AyCmbOIfecDueUpiIjXiZzJNRKq3u6x42xVHSQn3brY=.e11f93be-84da-42b5-a345-12634643279d@github.com>

> Add support to log CPU cost for GC during VM exit with `-Xlog:gc+cpu`.
> 
> 
> [2,430s][info][gc,cpu] GC CPU usage: 22,87% (Process: 26,8926s GC: 6,1491s)

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

  Remove friend class in CPUTimeCounters

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25779/files
  - new: https://git.openjdk.org/jdk/pull/25779/files/5694d6f3..c3a7258b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=17-18

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

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

From duke at openjdk.org  Thu Jul  3 10:24:42 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 3 Jul 2025 10:24:42 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v17]
In-Reply-To: <pyW7roEt9wrFak4wIM-Si8ygD7DypHU-6osLSYdveXU=.0a4eaeee-5c6a-432d-9f36-bb82dd3d5842@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <-4_N96vrUHQqE9FrFW9s3728cjGucdMFEvjFNYY7FoQ=.d651e847-4041-44f3-842e-56221a878430@github.com>
 <cNDd6TUQMoiSQaniJEYeBkY-fvAZaAIj687PQdk3WOQ=.6f666493-a5be-4a18-ac6a-2ba27ed156d2@github.com>
 <1byklOUoicnZLix7PmzKBpAWfC_D1vCU22tRRsteank=.844a8042-3546-4e68-ac12-6ad5fb92a0ca@github.com>
 <pyW7roEt9wrFak4wIM-Si8ygD7DypHU-6osLSYdveXU=.0a4eaeee-5c6a-432d-9f36-bb82dd3d5842@github.com>
Message-ID: <froFKd6r4kMesYKiQy_8jPruDyaQgrTRMIhUhmSO9S8=.ae79d6d0-b9ab-4d2f-93bc-0df8641c60c4@github.com>

On Thu, 3 Jul 2025 10:04:32 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> get_instance() is private. It was not clear to me if we would want to change get_instance() to public
>
> Why do you need `get_instance`? Can you use the public static API?

Oh, now I see what you mean. Thanks for pointing that out :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2182420834

From ayang at openjdk.org  Thu Jul  3 10:45:46 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 3 Jul 2025 10:45:46 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v19]
In-Reply-To: <AyCmbOIfecDueUpiIjXiZzJNRKq3u6x42xVHSQn3brY=.e11f93be-84da-42b5-a345-12634643279d@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <AyCmbOIfecDueUpiIjXiZzJNRKq3u6x42xVHSQn3brY=.e11f93be-84da-42b5-a345-12634643279d@github.com>
Message-ID: <K2tDamTIAYXFYzVLjrei2xRPQLxjaNpXyh1QRjR7wW0=.88ff61e4-464b-496a-acc6-620ad66995f6@github.com>

On Thu, 3 Jul 2025 10:24:40 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc+cpu`.
>> 
>> 
>> [2,430s][info][gc,cpu] GC CPU usage: 22,87% (Process: 26,8926s GC: 6,1491s)
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove friend class in CPUTimeCounters

src/hotspot/share/gc/shared/collectedHeap.hpp line 465:

> 463: 
> 464:   double elapsed_gc_cpu_time() const;
> 465:   void log_gc_cpu_time() const;

They can be private, I believe.

src/hotspot/share/gc/shared/stringdedup/stringDedup.hpp line 109:

> 107: #include "utilities/globalDefinitions.hpp"
> 108: 
> 109: class CollectedHeap;

Should not be necessary given the included header.

src/hotspot/share/gc/shared/stringdedup/stringDedupProcessor.hpp line 33:

> 31: #include "utilities/macros.hpp"
> 32: 
> 33: class CollectedHeap;

Should not be necessary given the included header.

src/hotspot/share/gc/shared/vmThreadCpuTimeScope.hpp line 37:

> 35:   bool    _enabled;
> 36:   bool    _is_gc_operation;
> 37:   Thread* _thread;

If this class is solely for vmthread, I guess using the more concrete type `VMThread` here seems more explicit.

src/hotspot/share/runtime/cpuTimeCounters.hpp line 36:

> 34: #include "runtime/perfDataTypes.hpp"
> 35: 
> 36: class VMThreadCPUTimeScope;

Seems unused.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2182436622
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2182460139
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2182460302
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2182449653
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2182438065

From duke at openjdk.org  Thu Jul  3 10:52:42 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 3 Jul 2025 10:52:42 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v19]
In-Reply-To: <K2tDamTIAYXFYzVLjrei2xRPQLxjaNpXyh1QRjR7wW0=.88ff61e4-464b-496a-acc6-620ad66995f6@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <AyCmbOIfecDueUpiIjXiZzJNRKq3u6x42xVHSQn3brY=.e11f93be-84da-42b5-a345-12634643279d@github.com>
 <K2tDamTIAYXFYzVLjrei2xRPQLxjaNpXyh1QRjR7wW0=.88ff61e4-464b-496a-acc6-620ad66995f6@github.com>
Message-ID: <sBYMUDKOEzVf94YI-uCl36x4Ib9l8e8yzljyMZB1-5c=.59f08e43-6d95-42ae-ae37-772daba761b5@github.com>

On Thu, 3 Jul 2025 10:29:24 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 friend class in CPUTimeCounters
>
> src/hotspot/share/gc/shared/collectedHeap.hpp line 465:
> 
>> 463: 
>> 464:   double elapsed_gc_cpu_time() const;
>> 465:   void log_gc_cpu_time() const;
> 
> They can be private, I believe.

`elapsed_gc_cpu_time()` will be callable through an MXBean in a future patch I'm planning, but can make `log_gc_cpu_time()` private

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2182476362

From duke at openjdk.org  Thu Jul  3 10:58:44 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 3 Jul 2025 10:58:44 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v19]
In-Reply-To: <K2tDamTIAYXFYzVLjrei2xRPQLxjaNpXyh1QRjR7wW0=.88ff61e4-464b-496a-acc6-620ad66995f6@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <AyCmbOIfecDueUpiIjXiZzJNRKq3u6x42xVHSQn3brY=.e11f93be-84da-42b5-a345-12634643279d@github.com>
 <K2tDamTIAYXFYzVLjrei2xRPQLxjaNpXyh1QRjR7wW0=.88ff61e4-464b-496a-acc6-620ad66995f6@github.com>
Message-ID: <ucGVhTMX-S-K1xuy2PSmGFAVywJUMPB_zkO2Bn859KY=.544ef513-4970-4c20-a5fa-c092668b5148@github.com>

On Thu, 3 Jul 2025 10:34:27 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 friend class in CPUTimeCounters
>
> src/hotspot/share/gc/shared/vmThreadCpuTimeScope.hpp line 37:
> 
>> 35:   bool    _enabled;
>> 36:   bool    _is_gc_operation;
>> 37:   Thread* _thread;
> 
> If this class is solely for vmthread, I guess using the more concrete type `VMThread` here seems more explicit.

OK, was storing it as `Thread` as it is only needed for `os::thread_cpu_time`. But now that we have renamed the class to something more specific it makes sense to be more explicit here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2182487230

From duke at openjdk.org  Thu Jul  3 11:16:01 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 3 Jul 2025 11:16:01 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v20]
In-Reply-To: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
Message-ID: <ftPODMSk4CGkrkszR-0xZQre5EhJHG7aTMwFXcspdmE=.9a4586dc-cf43-45fa-9f9b-e67812180e89@github.com>

> Add support to log CPU cost for GC during VM exit with `-Xlog:gc+cpu`.
> 
> 
> [2,430s][info][gc,cpu] GC CPU usage: 22,87% (Process: 26,8926s GC: 6,1491s)

Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision:

 - Remove unnecessary include
 - Remove unnecessary includes, explicit thread type and make log_gc_cpu_time private

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25779/files
  - new: https://git.openjdk.org/jdk/pull/25779/files/c3a7258b..a6564c70

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=18-19

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

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

From ayang at openjdk.org  Thu Jul  3 11:24:42 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 3 Jul 2025 11:24:42 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v20]
In-Reply-To: <ftPODMSk4CGkrkszR-0xZQre5EhJHG7aTMwFXcspdmE=.9a4586dc-cf43-45fa-9f9b-e67812180e89@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <ftPODMSk4CGkrkszR-0xZQre5EhJHG7aTMwFXcspdmE=.9a4586dc-cf43-45fa-9f9b-e67812180e89@github.com>
Message-ID: <1gL9vHhimIgmnwZy1Ca-XA9Qk_ykG38m8OpUcn6EC_U=.d782ea80-ec21-4387-b1a5-092c38fe0230@github.com>

On Thu, 3 Jul 2025 11:16:01 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc+cpu`.
>> 
>> 
>> [2,430s][info][gc,cpu] GC CPU usage: 22,87% (Process: 26,8926s GC: 6,1491s)
>
> Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove unnecessary include
>  - Remove unnecessary includes, explicit thread type and make log_gc_cpu_time private

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25779#pullrequestreview-2982789191

From duke at openjdk.org  Thu Jul  3 11:34:19 2025
From: duke at openjdk.org (hanguanqiang)
Date: Thu, 3 Jul 2025 11:34:19 GMT
Subject: RFR: 8344548: Incorrect StartAggressiveSweepingAt doc for segmented
 code cache
Message-ID: <4Kb1CzIxoBR4DXR9htBr3NINCgUup9coKCNFurAi93c=.253f5490-2263-4b3d-b921-2737ead6bb0a@github.com>

The flag StartAggressiveSweepingAt triggers aggressive code cache sweeping based on the percentage of free space in the entire code cache. The previous description referenced segmented vs non-segmented code cache, which is confusing and does not reflect the current implementation.

This patch updates the flag description to clearly state that the threshold is based on the total code cache free percentage, regardless of segmentation.

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

Commit messages:
 - 8344548: Incorrect StartAggressiveSweepingAt doc for segmented code cache

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

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

From mbaesken at openjdk.org  Thu Jul  3 11:38:43 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 3 Jul 2025 11:38:43 GMT
Subject: Integrated: 8361198: [AIX] fix misleading error output in
 thread_cpu_time_unchecked
In-Reply-To: <wOj72AJP6g77WdCgbn1CYRmTO3P4skVYZwvUc5fOfe4=.c64e73b3-2573-46ba-8c85-10eb91a59838@github.com>
References: <wOj72AJP6g77WdCgbn1CYRmTO3P4skVYZwvUc5fOfe4=.c64e73b3-2573-46ba-8c85-10eb91a59838@github.com>
Message-ID: <iwrJkS1PblYrbmqCaqJ2baEODVPzeDLbUKaEvnbIbmU=.a38c9836-5a8a-4d9e-9240-ac5066603ad9@github.com>

On Tue, 1 Jul 2025 14:43:22 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently we have on AIX in thread_cpu_time_unchecked misleading error output in case of failing getthrds64 . This should be adjusted .

This pull request has now been integrated.

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

8361198: [AIX] fix misleading error output in thread_cpu_time_unchecked

Reviewed-by: mdoerr, azeller

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

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

From dholmes at openjdk.org  Thu Jul  3 12:10:42 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 3 Jul 2025 12:10:42 GMT
Subject: RFR: 8357601: Checked version of JNI Release<type>ArrayElements
 needs to filter out known wrapped arrays
In-Reply-To: <w7vQUXXc-vl7ftD658Cxya47RE1nAC0A67U8q9F3WwE=.913fdbe7-8ed2-4f22-a1e6-69da6c10b9ce@github.com>
References: <Zg4Zabq290iG7P02xAkGT_fHXEsur-GE-w4-piJYc0E=.e0c38720-75bd-4b2a-9d6f-a225749b5a29@github.com>
 <w7vQUXXc-vl7ftD658Cxya47RE1nAC0A67U8q9F3WwE=.913fdbe7-8ed2-4f22-a1e6-69da6c10b9ce@github.com>
Message-ID: <IMmZiYES2zlKmTb1XrdZHTKEvlcYN7GybYy7kOlgXSs=.1e08a30e-a723-4ac5-b518-70c36f378409@github.com>

On Thu, 3 Jul 2025 07:31:17 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> The checked version of `Get`/`Release<type>ArrayElements` uses `GuardedMemory` to perform error checking. When releasing the array the code needs to check for the known array tags from the other JNI APIs and report an error.
>> 
>> We also expand `GuardedMemory` to allow for a second tag word so that we can discriminate additional allocation sites i.e. identifying use of `Get`/`SetPrimitiveArrayCritical`. And add further robustness to guard verification by using `SafeFetch`.
>> 
>> Testing
>>  - new test
>>  - Tiers 1-4 (sanity)
>
> LGTM

Thanks for the review @jdksjolen !

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

PR Comment: https://git.openjdk.org/jdk/pull/25444#issuecomment-3032027659

From duke at openjdk.org  Thu Jul  3 12:13:59 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 3 Jul 2025 12:13:59 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v21]
In-Reply-To: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
Message-ID: <SjFJr64gNm-vgv-GT5oC3u5WRxh9_XvHCKnCmpVoaOo=.a62b9a18-32aa-4d04-999a-c055cb8eca3e@github.com>

> Add support to log CPU cost for GC during VM exit with `-Xlog:gc+cpu`.
> 
> 
> [2,430s][info][gc,cpu] GC CPU usage: 22,87% (Process: 26,8926s GC: 6,1491s)

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

  Align string_dedup_cpu_time error handling to cpu_time/_vmthread_cpu_time's specification

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25779/files
  - new: https://git.openjdk.org/jdk/pull/25779/files/a6564c70..54ac0884

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=19-20

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

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

From tschatzl at openjdk.org  Thu Jul  3 12:41:46 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 3 Jul 2025 12:41:46 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v21]
In-Reply-To: <SjFJr64gNm-vgv-GT5oC3u5WRxh9_XvHCKnCmpVoaOo=.a62b9a18-32aa-4d04-999a-c055cb8eca3e@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <SjFJr64gNm-vgv-GT5oC3u5WRxh9_XvHCKnCmpVoaOo=.a62b9a18-32aa-4d04-999a-c055cb8eca3e@github.com>
Message-ID: <kpDxNYLcuga5RI26xEh0pHPgRfQcUhJK5Yb-WpVXvlg=.16be9a53-de61-4db4-91dd-76a0f9074811@github.com>

On Thu, 3 Jul 2025 12:13:59 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc+cpu`.
>> 
>> 
>> [2,430s][info][gc,cpu] GC CPU usage: 22,87% (Process: 26,8926s GC: 6,1491s)
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Align string_dedup_cpu_time error handling to cpu_time/_vmthread_cpu_time's specification

lgtm!

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25779#pullrequestreview-2983009540

From ayang at openjdk.org  Thu Jul  3 13:08:44 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 3 Jul 2025 13:08:44 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v21]
In-Reply-To: <SjFJr64gNm-vgv-GT5oC3u5WRxh9_XvHCKnCmpVoaOo=.a62b9a18-32aa-4d04-999a-c055cb8eca3e@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <SjFJr64gNm-vgv-GT5oC3u5WRxh9_XvHCKnCmpVoaOo=.a62b9a18-32aa-4d04-999a-c055cb8eca3e@github.com>
Message-ID: <LDVLmUXA2_2WsTY3ebV0IghzL7d6SiavucvQ0FOJEn0=.004dfde6-c0fa-4be1-b779-b5b992ba7338@github.com>

On Thu, 3 Jul 2025 12:13:59 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc+cpu`.
>> 
>> 
>> [2,430s][info][gc,cpu] GC CPU usage: 22,87% (Process: 26,8926s GC: 6,1491s)
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Align string_dedup_cpu_time error handling to cpu_time/_vmthread_cpu_time's specification

If threads in `elapsed_gc_cpu_time` gets -1 for cpu-time, users wouldn't be notified. Instead, the log will show gc usage is 0%. Could this behavior be surprising? Even worse, if only some threads get `-1`, the final gc usage will look normal but can be off by a noticeable margin.

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

PR Review: https://git.openjdk.org/jdk/pull/25779#pullrequestreview-2983099464

From duke at openjdk.org  Thu Jul  3 14:02:53 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 3 Jul 2025 14:02:53 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v21]
In-Reply-To: <LDVLmUXA2_2WsTY3ebV0IghzL7d6SiavucvQ0FOJEn0=.004dfde6-c0fa-4be1-b779-b5b992ba7338@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <SjFJr64gNm-vgv-GT5oC3u5WRxh9_XvHCKnCmpVoaOo=.a62b9a18-32aa-4d04-999a-c055cb8eca3e@github.com>
 <LDVLmUXA2_2WsTY3ebV0IghzL7d6SiavucvQ0FOJEn0=.004dfde6-c0fa-4be1-b779-b5b992ba7338@github.com>
Message-ID: <6tit-z77enFt7qFJzO2zoHMMhH_JV4kt5XXGRrHQ6Ng=.0f2e0a0b-0f1d-47be-8599-1b67d7f469a4@github.com>

On Thu, 3 Jul 2025 13:06:17 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> If threads in elapsed_gc_cpu_time gets -1 for cpu-time, users wouldn't be notified. Instead, the log will show gc usage is 0%. Could this behavior be surprising? Even worse, if only some threads get -1, the final gc usage will look normal but can be off by a noticeable margin.

If `os::thread_cpu_time` fails only intermittently the numbers may indeed be misleading. However if that ever happens the machine is in a very bad state. Many places in hotspot does not check if it returns -1 at all. Maybe we should consider adding a warning or other type of error handling in `os::thread_cpu_time` but that would belong in another PR imo.

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

PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-3032390753

From iklam at openjdk.org  Thu Jul  3 17:12:01 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 3 Jul 2025 17:12:01 GMT
Subject: RFR: 8336147: Clarify CDS documentation about static vs dynamic
 archive
Message-ID: <b1tondBAa4PpzE4j_II363or75AMEEpGHiZBROC0-0Y=.f90addfa-6ad4-450c-9136-7a0861a775ef@github.com>

Please review this doc clarification about the difference between CDS static and dynamic archives.

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

Commit messages:
 - Reworded per @shipilev suggestions
 - 8336147: Clarify CDS documentation about static vs dynamic archive

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

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

From shade at openjdk.org  Thu Jul  3 17:12:01 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 3 Jul 2025 17:12:01 GMT
Subject: RFR: 8336147: Clarify CDS documentation about static vs dynamic
 archive
In-Reply-To: <b1tondBAa4PpzE4j_II363or75AMEEpGHiZBROC0-0Y=.f90addfa-6ad4-450c-9136-7a0861a775ef@github.com>
References: <b1tondBAa4PpzE4j_II363or75AMEEpGHiZBROC0-0Y=.f90addfa-6ad4-450c-9136-7a0861a775ef@github.com>
Message-ID: <Fs6dK3e5_5MlYLgr-LsOMsK9OIsLIdEcxSpEeLpYkgo=.747fc51f-14d1-49a2-b4ee-b3162093f248@github.com>

On Thu, 3 Jul 2025 04:46:28 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Please review this doc clarification about the difference between CDS static and dynamic archives.

On the first read, I thought "enabling dynamic archive disables the following optimizations", which is not true, right? The limitations are only applied to the dynamic archive parts. Also, less efficient than what? Static archive does not store additional classes, so it is not very sensible to compare with. Would it be fairer to compare "static+dynamic" to "AOTCache"? Time to pitch Leyden's AOT here?

Also, do we really want to talk about implementation limitations in a fairly generic doc? I think we do a high-level overview (usage and general expectations) here.

Suggestion:

"The names "static" and "dynamic" are used for historical reasons. The dynamic archive, while still useful, supports a limited set of CDS optimizations that are normally available in static CDS archive. If the full set of CDS/AOT features is desired for additional classes, consider using AOTCache features."

src/java.base/share/man/java.md line 3761:

> 3759: 
> 3760: The names "static" and "dynamic" are used for historical reasons.
> 3761: The dynamic archive may be less efficient as it does not support the

Unnecessarily scary wording here, "less efficient".

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

PR Review: https://git.openjdk.org/jdk/pull/26109#pullrequestreview-2983052777
PR Review Comment: https://git.openjdk.org/jdk/pull/26109#discussion_r2182709420

From ccheung at openjdk.org  Thu Jul  3 17:27:40 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 3 Jul 2025 17:27:40 GMT
Subject: RFR: 8336147: Clarify CDS documentation about static vs dynamic
 archive
In-Reply-To: <b1tondBAa4PpzE4j_II363or75AMEEpGHiZBROC0-0Y=.f90addfa-6ad4-450c-9136-7a0861a775ef@github.com>
References: <b1tondBAa4PpzE4j_II363or75AMEEpGHiZBROC0-0Y=.f90addfa-6ad4-450c-9136-7a0861a775ef@github.com>
Message-ID: <hvMMjj8nHTyPbteMpB9nAmMw1xvG2ABj5kcfS7GyN2M=.7d3dbf95-45a8-4a41-9f32-9079f5075e5f@github.com>

On Thu, 3 Jul 2025 04:46:28 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Please review this doc clarification about the difference between CDS static and dynamic archives.

Looks good. Just one nit.

src/java.base/share/man/java.md line 3763:

> 3761: archive, while still useful, supports fewer optimizations than
> 3762: available for the static CDS archive. If the full set of CDS/AOT
> 3763: optimizations are desired, consider using the AOTCache features describe below.

Suggestion:

optimizations are desired, consider using the AOTCache feature described below.

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

Marked as reviewed by ccheung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26109#pullrequestreview-2984005309
PR Review Comment: https://git.openjdk.org/jdk/pull/26109#discussion_r2183324235

From shade at openjdk.org  Thu Jul  3 17:49:39 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 3 Jul 2025 17:49:39 GMT
Subject: RFR: 8336147: Clarify CDS documentation about static vs dynamic
 archive
In-Reply-To: <b1tondBAa4PpzE4j_II363or75AMEEpGHiZBROC0-0Y=.f90addfa-6ad4-450c-9136-7a0861a775ef@github.com>
References: <b1tondBAa4PpzE4j_II363or75AMEEpGHiZBROC0-0Y=.f90addfa-6ad4-450c-9136-7a0861a775ef@github.com>
Message-ID: <JLDSmAr4z5ORGlFX2V9SyQwSqE945jt-zq9_H0VM9vk=.42c5bc16-a57e-4153-86cb-bba12eeb7731@github.com>

On Thu, 3 Jul 2025 04:46:28 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Please review this doc clarification about the difference between CDS static and dynamic archives.

src/java.base/share/man/java.md line 3763:

> 3761: archive, while still useful, supports fewer optimizations than
> 3762: available for the static CDS archive. If the full set of CDS/AOT
> 3763: optimizations are desired, consider using the AOTCache features describe below.

Suggestion:

optimizations are desired, consider using the AOT cache features described below.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26109#discussion_r2183389640

From iklam at openjdk.org  Thu Jul  3 18:31:21 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 3 Jul 2025 18:31:21 GMT
Subject: RFR: 8336147: Clarify CDS documentation about static vs dynamic
 archive [v2]
In-Reply-To: <b1tondBAa4PpzE4j_II363or75AMEEpGHiZBROC0-0Y=.f90addfa-6ad4-450c-9136-7a0861a775ef@github.com>
References: <b1tondBAa4PpzE4j_II363or75AMEEpGHiZBROC0-0Y=.f90addfa-6ad4-450c-9136-7a0861a775ef@github.com>
Message-ID: <pkS_sC4dxLl7gQzsABOKHzOHUiqhjHYEJ5x347AKJQo=.b381b2f4-4751-46bc-aad2-3864f6a6db11@github.com>

> Please review this doc clarification about the difference between CDS static and dynamic archives.

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

  "AOTCache features" -> "AOT cache"

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26109/files
  - new: https://git.openjdk.org/jdk/pull/26109/files/6caa3715..bfb82882

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

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

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

From iklam at openjdk.org  Thu Jul  3 18:31:21 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 3 Jul 2025 18:31:21 GMT
Subject: RFR: 8336147: Clarify CDS documentation about static vs dynamic
 archive [v2]
In-Reply-To: <JLDSmAr4z5ORGlFX2V9SyQwSqE945jt-zq9_H0VM9vk=.42c5bc16-a57e-4153-86cb-bba12eeb7731@github.com>
References: <b1tondBAa4PpzE4j_II363or75AMEEpGHiZBROC0-0Y=.f90addfa-6ad4-450c-9136-7a0861a775ef@github.com>
 <JLDSmAr4z5ORGlFX2V9SyQwSqE945jt-zq9_H0VM9vk=.42c5bc16-a57e-4153-86cb-bba12eeb7731@github.com>
Message-ID: <IWpbEjDnf-C1nZFpO_AR7_MTZ4i8R3T5vYqaYNN8qdw=.a02e680c-225e-49ab-9429-79c070162b7d@github.com>

On Thu, 3 Jul 2025 17:47:01 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   "AOTCache features" -> "AOT cache"
>
> src/java.base/share/man/java.md line 3763:
> 
>> 3761: archive, while still useful, supports fewer optimizations than
>> 3762: available for the static CDS archive. If the full set of CDS/AOT
>> 3763: optimizations are desired, consider using the AOTCache features describe below.
> 
> Suggestion:
> 
> optimizations are desired, consider using the AOT cache features described below.

The word "features" sounds awkward here. I changed "AOTCache features" -> "AOT cache".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26109#discussion_r2183486751

From shade at openjdk.org  Thu Jul  3 18:36:42 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 3 Jul 2025 18:36:42 GMT
Subject: RFR: 8336147: Clarify CDS documentation about static vs dynamic
 archive [v2]
In-Reply-To: <pkS_sC4dxLl7gQzsABOKHzOHUiqhjHYEJ5x347AKJQo=.b381b2f4-4751-46bc-aad2-3864f6a6db11@github.com>
References: <b1tondBAa4PpzE4j_II363or75AMEEpGHiZBROC0-0Y=.f90addfa-6ad4-450c-9136-7a0861a775ef@github.com>
 <pkS_sC4dxLl7gQzsABOKHzOHUiqhjHYEJ5x347AKJQo=.b381b2f4-4751-46bc-aad2-3864f6a6db11@github.com>
Message-ID: <5Z6Y8FHnLQyNIfIZAnpZ4P1m028l-6QZVWOMJu9asWE=.235068c7-b593-4513-ab89-e2977a1903c6@github.com>

On Thu, 3 Jul 2025 18:31:21 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Please review this doc clarification about the difference between CDS static and dynamic archives.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   "AOTCache features" -> "AOT cache"

Looks good to me, thanks.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26109#pullrequestreview-2984263181

From ccheung at openjdk.org  Thu Jul  3 19:49:39 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 3 Jul 2025 19:49:39 GMT
Subject: RFR: 8336147: Clarify CDS documentation about static vs dynamic
 archive [v2]
In-Reply-To: <pkS_sC4dxLl7gQzsABOKHzOHUiqhjHYEJ5x347AKJQo=.b381b2f4-4751-46bc-aad2-3864f6a6db11@github.com>
References: <b1tondBAa4PpzE4j_II363or75AMEEpGHiZBROC0-0Y=.f90addfa-6ad4-450c-9136-7a0861a775ef@github.com>
 <pkS_sC4dxLl7gQzsABOKHzOHUiqhjHYEJ5x347AKJQo=.b381b2f4-4751-46bc-aad2-3864f6a6db11@github.com>
Message-ID: <v4MAwnaVlWMBWy_eFj1cU4coWq2yq1lMVgZz_Usrmz0=.e768c89e-c807-42be-9365-b2c504bcae08@github.com>

On Thu, 3 Jul 2025 18:31:21 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Please review this doc clarification about the difference between CDS static and dynamic archives.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   "AOTCache features" -> "AOT cache"

You forgot the following change:
`describe` -> `described`

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

PR Review: https://git.openjdk.org/jdk/pull/26109#pullrequestreview-2984476627

From dholmes at openjdk.org  Thu Jul  3 21:05:47 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 3 Jul 2025 21:05:47 GMT
Subject: Integrated: 8357601: Checked version of JNI Release<type>ArrayElements
 needs to filter out known wrapped arrays
In-Reply-To: <Zg4Zabq290iG7P02xAkGT_fHXEsur-GE-w4-piJYc0E=.e0c38720-75bd-4b2a-9d6f-a225749b5a29@github.com>
References: <Zg4Zabq290iG7P02xAkGT_fHXEsur-GE-w4-piJYc0E=.e0c38720-75bd-4b2a-9d6f-a225749b5a29@github.com>
Message-ID: <O1bMDjfI3XGbj1peRdAqcKjdO1Hi90BdevtNdA8Udxk=.1ffd6b86-125c-4c70-93aa-df2cff97c8ae@github.com>

On Mon, 26 May 2025 08:56:09 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The checked version of `Get`/`Release<type>ArrayElements` uses `GuardedMemory` to perform error checking. When releasing the array the code needs to check for the known array tags from the other JNI APIs and report an error.
> 
> We also expand `GuardedMemory` to allow for a second tag word so that we can discriminate additional allocation sites i.e. identifying use of `Get`/`SetPrimitiveArrayCritical`. And add further robustness to guard verification by using `SafeFetch`.
> 
> Testing
>  - new test
>  - Tiers 1-4 (sanity)

This pull request has now been integrated.

Changeset: da0a51ce
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/da0a51ce97453a47b2c7d11e5206774232309e69
Stats:     343 lines in 6 files changed: 321 ins; 6 del; 16 mod

8357601: Checked version of JNI Release<type>ArrayElements needs to filter out known wrapped arrays

Reviewed-by: coleenp, jsjolen

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

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

From iklam at openjdk.org  Thu Jul  3 21:19:22 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 3 Jul 2025 21:19:22 GMT
Subject: RFR: 8336147: Clarify CDS documentation about static vs dynamic
 archive [v3]
In-Reply-To: <b1tondBAa4PpzE4j_II363or75AMEEpGHiZBROC0-0Y=.f90addfa-6ad4-450c-9136-7a0861a775ef@github.com>
References: <b1tondBAa4PpzE4j_II363or75AMEEpGHiZBROC0-0Y=.f90addfa-6ad4-450c-9136-7a0861a775ef@github.com>
Message-ID: <Q70ONblSJCC29fuy0tsYOjE1wYX16po2IOETZoV67yk=.9cefcced-7b03-47fc-a1ce-90da121fffd3@github.com>

> Please review this doc clarification about the difference between CDS static and dynamic archives.

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

  @calvinccheung review: fixed type

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26109/files
  - new: https://git.openjdk.org/jdk/pull/26109/files/bfb82882..3c8833b3

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

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

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

From ccheung at openjdk.org  Thu Jul  3 21:19:22 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 3 Jul 2025 21:19:22 GMT
Subject: RFR: 8336147: Clarify CDS documentation about static vs dynamic
 archive [v3]
In-Reply-To: <Q70ONblSJCC29fuy0tsYOjE1wYX16po2IOETZoV67yk=.9cefcced-7b03-47fc-a1ce-90da121fffd3@github.com>
References: <b1tondBAa4PpzE4j_II363or75AMEEpGHiZBROC0-0Y=.f90addfa-6ad4-450c-9136-7a0861a775ef@github.com>
 <Q70ONblSJCC29fuy0tsYOjE1wYX16po2IOETZoV67yk=.9cefcced-7b03-47fc-a1ce-90da121fffd3@github.com>
Message-ID: <BJt-cI4fgOJiLXz00uTRGrg7teQcuNrOOvvwCsVGrUM=.967f4eb0-6576-410a-9d39-d878858a0652@github.com>

On Thu, 3 Jul 2025 21:16:10 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Please review this doc clarification about the difference between CDS static and dynamic archives.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @calvinccheung review: fixed type

Marked as reviewed by ccheung (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26109#pullrequestreview-2984711481

From iklam at openjdk.org  Thu Jul  3 21:19:22 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 3 Jul 2025 21:19:22 GMT
Subject: RFR: 8336147: Clarify CDS documentation about static vs dynamic
 archive [v2]
In-Reply-To: <v4MAwnaVlWMBWy_eFj1cU4coWq2yq1lMVgZz_Usrmz0=.e768c89e-c807-42be-9365-b2c504bcae08@github.com>
References: <b1tondBAa4PpzE4j_II363or75AMEEpGHiZBROC0-0Y=.f90addfa-6ad4-450c-9136-7a0861a775ef@github.com>
 <pkS_sC4dxLl7gQzsABOKHzOHUiqhjHYEJ5x347AKJQo=.b381b2f4-4751-46bc-aad2-3864f6a6db11@github.com>
 <v4MAwnaVlWMBWy_eFj1cU4coWq2yq1lMVgZz_Usrmz0=.e768c89e-c807-42be-9365-b2c504bcae08@github.com>
Message-ID: <dJ7kU8f2y6ZHymfBoPEyjrEzQCmjUZxZasKqIf12UMA=.fb45f784-c606-4256-9bab-d324a2e57af1@github.com>

On Thu, 3 Jul 2025 19:47:25 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> You forgot the following change: `describe` -> `described`

Fixed.

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

PR Comment: https://git.openjdk.org/jdk/pull/26109#issuecomment-3033669208

From dholmes at openjdk.org  Thu Jul  3 22:20:32 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 3 Jul 2025 22:20:32 GMT
Subject: RFR: 8356942:
 =?UTF-8?B?aW52b2tlaW50ZXJmYWNlwqBUaHJvd3PCoEFic3RyYWN0TWV0aG9kRXJyb3LCoEluc3RlYWQ=?=
 =?UTF-8?B?IA==?= =?UTF-8?B?b2bCoEluY29tcGF0aWJsZUNsYXNzQ2hhbmdlRXJyb3I=?=
Message-ID: <8Dh9B06hDuORGQ-uufrbswlGw9ABFFCA62sCJSUnJaY=.6498b7e8-a39b-43f0-a76f-a0ed9aea3905@github.com>

In [JDK-8186092](https://bugs.openjdk.org/browse/JDK-8186092) (way back in JDK 10) we elided loader constraint checks for overpass methods related to default methods by skipping them when initializing the itable for the interface. But that was the wrong thing to do. The overpass method is setup when there is a resolution/selection error so that the correct exception is thrown if the problematic method is invoked (like the ICCE reporting conflicting methods) and by eliding that entry we instead get the `AbstractMethhodError`.

The fix here is to revert that change from [JDK-8186092](https://bugs.openjdk.org/browse/JDK-8186092), and to address the loader constraint problem by adding the same check for overpass methods in `klassItable::check_constraints` that exists for `klassVtable::check_constraints`.

Testing:
 - new regression test
 - tiers 1-4

Thanks

PS. The diff is much smaller if you disable whitespace differences.

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

Commit messages:
 - regression test
 - 8356942: invokeinterface Throws AbstractMethodError Instead of IncompatibleClassChangeError

Changes: https://git.openjdk.org/jdk/pull/26122/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26122&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356942
  Stats: 128 lines in 6 files changed: 83 ins; 6 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/26122.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26122/head:pull/26122

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

From iklam at openjdk.org  Thu Jul  3 23:56:44 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 3 Jul 2025 23:56:44 GMT
Subject: RFR: 8336147: Clarify CDS documentation about static vs dynamic
 archive [v3]
In-Reply-To: <BJt-cI4fgOJiLXz00uTRGrg7teQcuNrOOvvwCsVGrUM=.967f4eb0-6576-410a-9d39-d878858a0652@github.com>
References: <b1tondBAa4PpzE4j_II363or75AMEEpGHiZBROC0-0Y=.f90addfa-6ad4-450c-9136-7a0861a775ef@github.com>
 <Q70ONblSJCC29fuy0tsYOjE1wYX16po2IOETZoV67yk=.9cefcced-7b03-47fc-a1ce-90da121fffd3@github.com>
 <BJt-cI4fgOJiLXz00uTRGrg7teQcuNrOOvvwCsVGrUM=.967f4eb0-6576-410a-9d39-d878858a0652@github.com>
Message-ID: <_T_iqaqzw5ETIZJBGxOxUpEgLmLW6dJVnqDakx3cKa0=.d62d8bf1-16dc-4a0e-a3d3-e935ca3fb2aa@github.com>

On Thu, 3 Jul 2025 21:15:10 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @calvinccheung review: fixed type
>
> Marked as reviewed by ccheung (Reviewer).

Thanks @calvinccheung and @shipilev for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/26109#issuecomment-3033964008

From iklam at openjdk.org  Thu Jul  3 23:56:44 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 3 Jul 2025 23:56:44 GMT
Subject: Integrated: 8336147: Clarify CDS documentation about static vs dynamic
 archive
In-Reply-To: <b1tondBAa4PpzE4j_II363or75AMEEpGHiZBROC0-0Y=.f90addfa-6ad4-450c-9136-7a0861a775ef@github.com>
References: <b1tondBAa4PpzE4j_II363or75AMEEpGHiZBROC0-0Y=.f90addfa-6ad4-450c-9136-7a0861a775ef@github.com>
Message-ID: <m3lVR3-vWl6ai3gpwsY_VYrxTZv9mWH22-Ibpy5wzF4=.cea07390-1318-49a1-adb7-3b682c65ba0d@github.com>

On Thu, 3 Jul 2025 04:46:28 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Please review this doc clarification about the difference between CDS static and dynamic archives.

This pull request has now been integrated.

Changeset: 854de8c9
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/854de8c9c6a1d851c1788e5f2250fe0928c51ca4
Stats:     4 lines in 1 file changed: 1 ins; 0 del; 3 mod

8336147: Clarify CDS documentation about static vs dynamic archive

Reviewed-by: ccheung, shade

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

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

From kbarrett at openjdk.org  Fri Jul  4 00:17:50 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 4 Jul 2025 00:17:50 GMT
Subject: RFR: 8361383: LogFileStreamOutput::write_decorations uses wrong type
 for format precisions
Message-ID: <WEZEQWuO_X8_LVeDe4nIFMk8DkoJSjtu4mqNDDHlE2Y=.d4132938-0cf3-4251-822b-4deba6914034@github.com>

Please review this change to LogFileStreamOutput to fix the type of the
precision values used when writing the decorations in a log message.

While I was at it, value-initialize the _decorator_padding in the
ctor-initializer rather than with a zero-filling loop.

Testing: mach5 tier1
Locally ran several tests that generate logging output and checked by eye the
decorator output.

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

Commit messages:
 - fix precision types in log printing

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

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

From dholmes at openjdk.org  Fri Jul  4 02:01:39 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 4 Jul 2025 02:01:39 GMT
Subject: RFR: 8361383: LogFileStreamOutput::write_decorations uses wrong
 type for format precisions
In-Reply-To: <WEZEQWuO_X8_LVeDe4nIFMk8DkoJSjtu4mqNDDHlE2Y=.d4132938-0cf3-4251-822b-4deba6914034@github.com>
References: <WEZEQWuO_X8_LVeDe4nIFMk8DkoJSjtu4mqNDDHlE2Y=.d4132938-0cf3-4251-822b-4deba6914034@github.com>
Message-ID: <A-yz5RckCH4r22VEEnivDm94RzoTNg0ZQlvACunDwPQ=.f8244a6a-0e74-48d3-bc40-48c847185f21@github.com>

On Fri, 4 Jul 2025 00:13:15 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to LogFileStreamOutput to fix the type of the
> precision values used when writing the decorations in a log message.
> 
> While I was at it, value-initialize the _decorator_padding in the
> ctor-initializer rather than with a zero-filling loop.
> 
> Testing: mach5 tier1
> Locally ran several tests that generate logging output and checked by eye the
> decorator output.

Looks good. Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26124#pullrequestreview-2985188029

From ayang at openjdk.org  Fri Jul  4 07:18:44 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 4 Jul 2025 07:18:44 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v21]
In-Reply-To: <SjFJr64gNm-vgv-GT5oC3u5WRxh9_XvHCKnCmpVoaOo=.a62b9a18-32aa-4d04-999a-c055cb8eca3e@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <SjFJr64gNm-vgv-GT5oC3u5WRxh9_XvHCKnCmpVoaOo=.a62b9a18-32aa-4d04-999a-c055cb8eca3e@github.com>
Message-ID: <0jCq2tboMZs8D5tB0lDRreM0lBPgcpnW5u0919kZewI=.996c1ee1-12ff-4b99-909a-0b30955b32b9@github.com>

On Thu, 3 Jul 2025 12:13:59 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc+cpu`.
>> 
>> 
>> [2,430s][info][gc,cpu] GC CPU usage: 22,87% (Process: 26,8926s GC: 6,1491s)
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Align string_dedup_cpu_time error handling to cpu_time/_vmthread_cpu_time's specification

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25779#pullrequestreview-2985878215

From duke at openjdk.org  Fri Jul  4 07:26:42 2025
From: duke at openjdk.org (duke)
Date: Fri, 4 Jul 2025 07:26:42 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v21]
In-Reply-To: <SjFJr64gNm-vgv-GT5oC3u5WRxh9_XvHCKnCmpVoaOo=.a62b9a18-32aa-4d04-999a-c055cb8eca3e@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <SjFJr64gNm-vgv-GT5oC3u5WRxh9_XvHCKnCmpVoaOo=.a62b9a18-32aa-4d04-999a-c055cb8eca3e@github.com>
Message-ID: <mgNFq5DTl1QyT5396-9-VoZcUX6hVfvPsz3LIGN5wi0=.46eb279d-82cd-4cc5-9d48-92d7607097f2@github.com>

On Thu, 3 Jul 2025 12:13:59 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc+cpu`.
>> 
>> 
>> [2,430s][info][gc,cpu] GC CPU usage: 22,87% (Process: 26,8926s GC: 6,1491s)
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Align string_dedup_cpu_time error handling to cpu_time/_vmthread_cpu_time's specification

@JonasNorlinder 
Your change (at version 54ac08840fe79dd82c86e2cb210343e5f369a399) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-3034808361

From duke at openjdk.org  Fri Jul  4 10:19:50 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Fri, 4 Jul 2025 10:19:50 GMT
Subject: Integrated: 8359110: Log accumulated GC and process CPU time upon VM
 exit
In-Reply-To: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
Message-ID: <5XnE45PdP7aRtYfKr96jVgSb8fu6im6ZDQIlwNgu6lI=.3af71c8f-4feb-4479-bcd1-2fa5b214ed2c@github.com>

On Thu, 12 Jun 2025 11:28:14 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> Add support to log CPU cost for GC during VM exit with `-Xlog:gc+cpu`.
> 
> 
> [2,430s][info][gc,cpu] GC CPU usage: 22,87% (Process: 26,8926s GC: 6,1491s)

This pull request has now been integrated.

Changeset: 56ebb8c1
Author:    Jonas Norlinder <jonas.norlinder at oracle.com>
Committer: Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/56ebb8c1b936e5a4c14486153c9f60df705095ad
Stats:     254 lines in 15 files changed: 240 ins; 9 del; 5 mod

8359110: Log accumulated GC and process CPU time upon VM exit

Co-authored-by: Erik ?sterlund <eosterlund at openjdk.org>
Co-authored-by: Jonas Norlinder <jnorlinder at openjdk.org>
Reviewed-by: tschatzl, ayang

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

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

From eastigeevich at openjdk.org  Fri Jul  4 13:59:39 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Fri, 4 Jul 2025 13:59:39 GMT
Subject: RFR: 8344548: Incorrect StartAggressiveSweepingAt doc for
 segmented code cache
In-Reply-To: <4Kb1CzIxoBR4DXR9htBr3NINCgUup9coKCNFurAi93c=.253f5490-2263-4b3d-b921-2737ead6bb0a@github.com>
References: <4Kb1CzIxoBR4DXR9htBr3NINCgUup9coKCNFurAi93c=.253f5490-2263-4b3d-b921-2737ead6bb0a@github.com>
Message-ID: <LrlYaXUgonpehoeO-zqdhsG5x5qyUZVDNJ9Auq3bAvM=.7e82d5cf-a749-4c23-8c3a-d4e254e837b7@github.com>

On Thu, 3 Jul 2025 11:29:02 GMT, hanguanqiang <duke at openjdk.org> wrote:

> The flag StartAggressiveSweepingAt triggers aggressive code cache sweeping based on the percentage of free space in the entire code cache. The previous description referenced segmented vs non-segmented code cache, which is confusing and does not reflect the current implementation.
> 
> This patch updates the flag description to clearly state that the threshold is based on the total code cache free percentage, regardless of segmentation.

lgtm

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

Marked as reviewed by eastigeevich (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26114#pullrequestreview-2987356786

From duke at openjdk.org  Fri Jul  4 14:13:27 2025
From: duke at openjdk.org (hanguanqiang)
Date: Fri, 4 Jul 2025 14:13:27 GMT
Subject: RFR: 8344548: Incorrect StartAggressiveSweepingAt doc for
 segmented code cache [v2]
In-Reply-To: <4Kb1CzIxoBR4DXR9htBr3NINCgUup9coKCNFurAi93c=.253f5490-2263-4b3d-b921-2737ead6bb0a@github.com>
References: <4Kb1CzIxoBR4DXR9htBr3NINCgUup9coKCNFurAi93c=.253f5490-2263-4b3d-b921-2737ead6bb0a@github.com>
Message-ID: <IYrVic9d23GxH2dBdAD-2zj1zTrfOUaLUHycxyOE2ek=.39df5c00-1eee-4149-9b93-ea09c558d8a3@github.com>

> The flag StartAggressiveSweepingAt triggers aggressive code cache sweeping based on the percentage of free space in the entire code cache. The previous description referenced segmented vs non-segmented code cache, which is confusing and does not reflect the current implementation.
> 
> This patch updates the flag description to clearly state that the threshold is based on the total code cache free percentage, regardless of segmentation.

hanguanqiang has updated the pull request with a new target base 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:

 - correct a compile error
 - Merge remote-tracking branch 'upstream/master' into 8344548
 - 8344548: Incorrect StartAggressiveSweepingAt doc for segmented code cache
   
   The flag StartAggressiveSweepingAt triggers aggressive code cache sweeping based on the percentage of free space in the entire code cache. The previous description referenced segmented vs non-segmented code cache, which is
   confusing and does not reflect the current implementation.
   
   This patch updates the flag description to clearly state that the threshold is based on the total code cache free percentage, regardless of segmentation.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26114/files
  - new: https://git.openjdk.org/jdk/pull/26114/files/698a3f28..cb1b2c60

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

  Stats: 3295 lines in 114 files changed: 2197 ins; 812 del; 286 mod
  Patch: https://git.openjdk.org/jdk/pull/26114.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26114/head:pull/26114

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

From duke at openjdk.org  Fri Jul  4 14:21:38 2025
From: duke at openjdk.org (hanguanqiang)
Date: Fri, 4 Jul 2025 14:21:38 GMT
Subject: RFR: 8344548: Incorrect StartAggressiveSweepingAt doc for
 segmented code cache [v2]
In-Reply-To: <LrlYaXUgonpehoeO-zqdhsG5x5qyUZVDNJ9Auq3bAvM=.7e82d5cf-a749-4c23-8c3a-d4e254e837b7@github.com>
References: <4Kb1CzIxoBR4DXR9htBr3NINCgUup9coKCNFurAi93c=.253f5490-2263-4b3d-b921-2737ead6bb0a@github.com>
 <LrlYaXUgonpehoeO-zqdhsG5x5qyUZVDNJ9Auq3bAvM=.7e82d5cf-a749-4c23-8c3a-d4e254e837b7@github.com>
Message-ID: <-bUAuPwNRRbf6d7qs2AJErsIlLJQbu9Hl0_ReKdUZ7A=.8473414f-b98b-4ca7-bf91-aca4ab0ccca5@github.com>

On Fri, 4 Jul 2025 13:57:01 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> hanguanqiang has updated the pull request with a new target base 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:
>> 
>>  - correct a compile error
>>  - Merge remote-tracking branch 'upstream/master' into 8344548
>>  - 8344548: Incorrect StartAggressiveSweepingAt doc for segmented code cache
>>    
>>    The flag StartAggressiveSweepingAt triggers aggressive code cache sweeping based on the percentage of free space in the entire code cache. The previous description referenced segmented vs non-segmented code cache, which is
>>    confusing and does not reflect the current implementation.
>>    
>>    This patch updates the flag description to clearly state that the threshold is based on the total code cache free percentage, regardless of segmentation.
>
> lgtm

Many thanks to you @eastig for reviewing

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

PR Comment: https://git.openjdk.org/jdk/pull/26114#issuecomment-3036461841

From iklam at openjdk.org  Fri Jul  4 16:51:16 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 4 Jul 2025 16:51:16 GMT
Subject: RFR: 8361367: AOT ExcludedClasses.java test failed with missing
 constant pool logs
Message-ID: <6dHEJG2KXApX0AaS5p2MeDDIZ2bF4cy7PVSjPpGMan4=.7d3eccb1-1796-498f-9d6c-e0669b566415@github.com>

This is a test bug.

The failures happen with `-Xcomp`. The following method is executed completely in compiled code:


static int hotSpot() {
    ShouldBeExcluded s = new ShouldBeExcluded();
    [.....]
    return counter + s.m() + s.f + b.m() + b.f;
}



C1 can generate code for reading `s.f` without resolving the `ShouldBeExcluded:f:I` reference inside the constant pool. Therefore, I removed two log messages from the test that may not be printed if the compiler happens to compile the corresponding bytecodes.

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

Commit messages:
 - 8361367: AOT ExcludedClasses.java test failed with missing constant pool logs

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

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

From mdoerr at openjdk.org  Fri Jul  4 22:50:48 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 4 Jul 2025 22:50:48 GMT
Subject: RFR: 8361433: [Big Endian] assert(verify_guards()) failed: Expected
 valid memory guards after 8357601
Message-ID: <u7lxG7g6hNkYD9i4PZlNEfhOfJ49pI0P5YOkk0frfZc=.09cf3e57-d974-4c5a-adca-a1920f49346c@github.com>

Big Endian fix for [JDK-8357601](https://bugs.openjdk.org/browse/JDK-8357601).

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

Commit messages:
 - 8361433: [Big Endian] assert(verify_guards()) failed: Expected valid memory guards after 8357601

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

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

From stuefe at openjdk.org  Sat Jul  5 16:12:42 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 5 Jul 2025 16:12:42 GMT
Subject: RFR: 8361433: [Big Endian] assert(verify_guards()) failed:
 Expected valid memory guards after 8357601
In-Reply-To: <u7lxG7g6hNkYD9i4PZlNEfhOfJ49pI0P5YOkk0frfZc=.09cf3e57-d974-4c5a-adca-a1920f49346c@github.com>
References: <u7lxG7g6hNkYD9i4PZlNEfhOfJ49pI0P5YOkk0frfZc=.09cf3e57-d974-4c5a-adca-a1920f49346c@github.com>
Message-ID: <Ttf3CY9AV3P_NDVh40dvfbu_VKbe1gJ1AiErDZaHjek=.e55d1aa4-f829-49ce-90d0-07041feef1b9@github.com>

On Fri, 4 Jul 2025 22:46:53 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Big Endian fix for [JDK-8357601](https://bugs.openjdk.org/browse/JDK-8357601).
> 
> Note: This is only a Big Endian fix. The code looks still wrong for platforms which don't support unaligned accesses. Also see `UseUnalignedAccesses`.

src/hotspot/share/memory/guardedMemory.hpp line 122:

> 120:         // SafeFetch. It doesn't matter if the value read happens
> 121:         // to be 0xFF as that is not what we expect anyway.
> 122:         u_char val = (u_char) (SafeFetch32((int*)c, 0xFF) BIG_ENDIAN_ONLY(>> 24));

Your fix is fine. Pre-existing: I wonder about the SafeFetch. A byte pointer traverses byte-wise over the memory. We use it to load a 32-bit value via SafeFetch32. 3/4 of those loads will be unaligned and also redundant. (I am surprised the unaligned access works on all platforms).

The guards themselves can be located at unaligned addresses I think, so we cannot just use int loads. Therefore I would have just used the old code without safefetch but preceded it with a safefetch check:


u_char* c = (u_char*) _guard;
+ if (!os::is_readable_pointer(align_up(c, BytesPerInt))) {
+   return false;
+ }
   u_char* end = c + GUARD_SIZE;
   while (c < end) {
     if (*c != badResourceValue) {
       return false;
     }
     c++;
   }

I think that would be pragmatic since the guard is only 16 byte and the chance of a guard straddling a page boundary is very small. But if one wanted to be more careful, one could use `os::is_readable_range()` instead.

@dholmes-ora  does this make sense?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26140#discussion_r2187412248

From mdoerr at openjdk.org  Sat Jul  5 17:34:26 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Sat, 5 Jul 2025 17:34:26 GMT
Subject: RFR: 8361433: [Big Endian] assert(verify_guards()) failed:
 Expected valid memory guards after 8357601 [v2]
In-Reply-To: <u7lxG7g6hNkYD9i4PZlNEfhOfJ49pI0P5YOkk0frfZc=.09cf3e57-d974-4c5a-adca-a1920f49346c@github.com>
References: <u7lxG7g6hNkYD9i4PZlNEfhOfJ49pI0P5YOkk0frfZc=.09cf3e57-d974-4c5a-adca-a1920f49346c@github.com>
Message-ID: <Cx4nqbG_ovKrTLfpjh52R-yyHITsIWeYw0BSEVjuxzQ=.dcbfbc7a-da19-414b-8289-d746bd998196@github.com>

> Big Endian fix for [JDK-8357601](https://bugs.openjdk.org/browse/JDK-8357601).
> 
> Note: The first commit is only a Big Endian fix. The code looks still wrong for platforms which don't support unaligned accesses. Also see `UseUnalignedAccesses`.
> The second commit changes to check `os::is_readable_range()`.

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

  Use os::is_readable_range().

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26140/files
  - new: https://git.openjdk.org/jdk/pull/26140/files/ced69858..2f467b3a

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

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

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

From mdoerr at openjdk.org  Sat Jul  5 17:34:26 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Sat, 5 Jul 2025 17:34:26 GMT
Subject: RFR: 8361433: [Big Endian] assert(verify_guards()) failed:
 Expected valid memory guards after 8357601 [v2]
In-Reply-To: <Ttf3CY9AV3P_NDVh40dvfbu_VKbe1gJ1AiErDZaHjek=.e55d1aa4-f829-49ce-90d0-07041feef1b9@github.com>
References: <u7lxG7g6hNkYD9i4PZlNEfhOfJ49pI0P5YOkk0frfZc=.09cf3e57-d974-4c5a-adca-a1920f49346c@github.com>
 <Ttf3CY9AV3P_NDVh40dvfbu_VKbe1gJ1AiErDZaHjek=.e55d1aa4-f829-49ce-90d0-07041feef1b9@github.com>
Message-ID: <IcGEhdJB39mPJCWpgJg_3MDspORvcDw4YDiWD0JhiSo=.28191d88-1758-4fa1-af38-641c3314ab60@github.com>

On Sat, 5 Jul 2025 16:09:21 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use os::is_readable_range().
>
> src/hotspot/share/memory/guardedMemory.hpp line 122:
> 
>> 120:         // SafeFetch. It doesn't matter if the value read happens
>> 121:         // to be 0xFF as that is not what we expect anyway.
>> 122:         u_char val = (u_char) (SafeFetch32((int*)c, 0xFF) BIG_ENDIAN_ONLY(>> 24));
> 
> Your fix is fine. Pre-existing: I wonder about the SafeFetch. A byte pointer traverses byte-wise over the memory. We use it to load a 32-bit value via SafeFetch32. 3/4 of those loads will be unaligned and also redundant. (I am surprised the unaligned access works on all platforms).
> 
> The guards themselves can be located at unaligned addresses I think, so we cannot just use int loads. Therefore I would have just used the old code without safefetch but preceded it with a safefetch check:
> 
> 
> u_char* c = (u_char*) _guard;
> + if (!os::is_readable_pointer(align_up(c, BytesPerInt))) {
> +   return false;
> + }
>    u_char* end = c + GUARD_SIZE;
>    while (c < end) {
>      if (*c != badResourceValue) {
>        return false;
>      }
>      c++;
>    }
> 
> I think that would be pragmatic since the guard is only 16 byte and the chance of a guard straddling a page boundary is very small. But if one wanted to be more careful, one could use `os::is_readable_range()` instead.
> 
> @dholmes-ora  does this make sense?

Thanks, Thomas! I've changed to use `os::is_readable_range()`. Note that alignment is already handled inside of that function. Please take a look!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26140#discussion_r2187504943

From dholmes at openjdk.org  Sun Jul  6 12:01:43 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 6 Jul 2025 12:01:43 GMT
Subject: RFR: 8361433: [Big Endian] assert(verify_guards()) failed:
 Expected valid memory guards after 8357601 [v2]
In-Reply-To: <IcGEhdJB39mPJCWpgJg_3MDspORvcDw4YDiWD0JhiSo=.28191d88-1758-4fa1-af38-641c3314ab60@github.com>
References: <u7lxG7g6hNkYD9i4PZlNEfhOfJ49pI0P5YOkk0frfZc=.09cf3e57-d974-4c5a-adca-a1920f49346c@github.com>
 <Ttf3CY9AV3P_NDVh40dvfbu_VKbe1gJ1AiErDZaHjek=.e55d1aa4-f829-49ce-90d0-07041feef1b9@github.com>
 <IcGEhdJB39mPJCWpgJg_3MDspORvcDw4YDiWD0JhiSo=.28191d88-1758-4fa1-af38-641c3314ab60@github.com>
Message-ID: <kbVexj1kcTxZ2yRU1aLGGFJq1Ll1fbYBvO_cWW5fJps=.526963bb-8ac0-400a-8942-144ff31ea693@github.com>

On Sat, 5 Jul 2025 17:30:58 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> src/hotspot/share/memory/guardedMemory.hpp line 122:
>> 
>>> 120:         // SafeFetch. It doesn't matter if the value read happens
>>> 121:         // to be 0xFF as that is not what we expect anyway.
>>> 122:         u_char val = (u_char) (SafeFetch32((int*)c, 0xFF) BIG_ENDIAN_ONLY(>> 24));
>> 
>> Your fix is fine. Pre-existing: I wonder about the SafeFetch. A byte pointer traverses byte-wise over the memory. We use it to load a 32-bit value via SafeFetch32. 3/4 of those loads will be unaligned and also redundant. (I am surprised the unaligned access works on all platforms).
>> 
>> The guards themselves can be located at unaligned addresses I think, so we cannot just use int loads. Therefore I would have just used the old code without safefetch but preceded it with a safefetch check:
>> 
>> 
>> u_char* c = (u_char*) _guard;
>> + if (!os::is_readable_pointer(align_up(c, BytesPerInt))) {
>> +   return false;
>> + }
>>    u_char* end = c + GUARD_SIZE;
>>    while (c < end) {
>>      if (*c != badResourceValue) {
>>        return false;
>>      }
>>      c++;
>>    }
>> 
>> I think that would be pragmatic since the guard is only 16 byte and the chance of a guard straddling a page boundary is very small. But if one wanted to be more careful, one could use `os::is_readable_range()` instead.
>> 
>> @dholmes-ora  does this make sense?
>
> Thanks, Thomas! I've changed to use `os::is_readable_range()`. Note that alignment is already handled inside of that function. Please take a look!

@TheRealMDoerr , @tstuefe  let me do a backout of JDK-8357601 in the morning. I need that fix to be complete and safe so it can be backported in a simple manner. Thanks.

I did not know that SafeFetch32 was not a generally usable API. I will look into @tstuefe suggested alternative.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26140#discussion_r2188216085

From iklam at openjdk.org  Sun Jul  6 23:08:26 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sun, 6 Jul 2025 23:08:26 GMT
Subject: [jdk25] RFR: 8360164: AOT cache creation crashes in
 ~ThreadTotalCPUTimeClosure()
Message-ID: <99jog4TdKhIldbCzRaCKtzyOiZBiNhv90xaM-xoEsDA=.e8c481a8-fc25-4001-afd1-d562402aefec@github.com>

Hi all,

This pull request contains a backport of commit [7d7e60c8](https://github.com/openjdk/jdk/commit/7d7e60c8aebc4b4c1e7121be702393e5bc46e9ce) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Ioi Lam on 1 Jul 2025 and was reviewed by Calvin Cheung, Vladimir Kozlov and David Holmes.

Thanks!

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

Commit messages:
 - Backport 7d7e60c8aebc4b4c1e7121be702393e5bc46e9ce

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

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

From dholmes at openjdk.org  Mon Jul  7 04:01:53 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 7 Jul 2025 04:01:53 GMT
Subject: RFR: 8361433: [Big Endian] assert(verify_guards()) failed:
 Expected valid memory guards after 8357601 [v2]
In-Reply-To: <Cx4nqbG_ovKrTLfpjh52R-yyHITsIWeYw0BSEVjuxzQ=.dcbfbc7a-da19-414b-8289-d746bd998196@github.com>
References: <u7lxG7g6hNkYD9i4PZlNEfhOfJ49pI0P5YOkk0frfZc=.09cf3e57-d974-4c5a-adca-a1920f49346c@github.com>
 <Cx4nqbG_ovKrTLfpjh52R-yyHITsIWeYw0BSEVjuxzQ=.dcbfbc7a-da19-414b-8289-d746bd998196@github.com>
Message-ID: <COyiY0_pjDEryzczGE4oqW8rZmPmBY4LD3JhmQpQ3u0=.89b7b456-d230-4a15-a7f6-c192f9a6cd90@github.com>

On Sat, 5 Jul 2025 17:34:26 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Big Endian fix for [JDK-8357601](https://bugs.openjdk.org/browse/JDK-8357601).
>> 
>> Note: The first commit is only a Big Endian fix. The code looks still wrong for platforms which don't support unaligned accesses. Also see `UseUnalignedAccesses`.
>> The second commit changes to check `os::is_readable_range()`.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use os::is_readable_range().

The original change has been backed out. Sorry for the inconvenience, and thanks for the suggested fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/26140#issuecomment-3043404601

From dholmes at openjdk.org  Mon Jul  7 07:45:40 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 7 Jul 2025 07:45:40 GMT
Subject: RFR: 8361367: AOT ExcludedClasses.java test failed with missing
 constant pool logs
In-Reply-To: <6dHEJG2KXApX0AaS5p2MeDDIZ2bF4cy7PVSjPpGMan4=.7d3eccb1-1796-498f-9d6c-e0669b566415@github.com>
References: <6dHEJG2KXApX0AaS5p2MeDDIZ2bF4cy7PVSjPpGMan4=.7d3eccb1-1796-498f-9d6c-e0669b566415@github.com>
Message-ID: <-inTQD4Kcvo55qQxKtF8d0D7GuyVLjzT1rpNpUH3EhQ=.d57613fb-a82f-4888-bb7b-92990020db87@github.com>

On Fri, 4 Jul 2025 16:46:07 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This is a test bug.
> 
> The failures happen with `-Xcomp`. The following method is executed completely in compiled code:
> 
> 
> static int hotSpot() {
>     ShouldBeExcluded s = new ShouldBeExcluded();
>     [.....]
>     return counter + s.m() + s.f + b.m() + b.f;
> }
> 
> 
> 
> C1 can generate code for reading `s.f` without resolving the `ShouldBeExcluded:f:I` reference inside the constant pool. Therefore, I removed two log messages from the test that may not be printed if the compiler happens to compile the corresponding bytecodes.

Seems reasonable.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26136#pullrequestreview-2992583463

From shade at openjdk.org  Mon Jul  7 08:10:51 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 7 Jul 2025 08:10:51 GMT
Subject: [jdk25] RFR: 8360164: AOT cache creation crashes in
 ~ThreadTotalCPUTimeClosure()
In-Reply-To: <99jog4TdKhIldbCzRaCKtzyOiZBiNhv90xaM-xoEsDA=.e8c481a8-fc25-4001-afd1-d562402aefec@github.com>
References: <99jog4TdKhIldbCzRaCKtzyOiZBiNhv90xaM-xoEsDA=.e8c481a8-fc25-4001-afd1-d562402aefec@github.com>
Message-ID: <AD4Ns3MEtxtIFpqPBBnRJy-MPkxLP8gQZ2b8r322XOk=.efdc2b9e-a234-4c4a-8c69-5b1ba446efbc@github.com>

On Sun, 6 Jul 2025 23:02:53 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [7d7e60c8](https://github.com/openjdk/jdk/commit/7d7e60c8aebc4b4c1e7121be702393e5bc46e9ce) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Ioi Lam on 1 Jul 2025 and was reviewed by Calvin Cheung, Vladimir Kozlov and David Holmes.
> 
> Thanks!

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26149#pullrequestreview-2992676694

From mdoerr at openjdk.org  Mon Jul  7 08:32:46 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 7 Jul 2025 08:32:46 GMT
Subject: RFR: 8361433: [Big Endian] assert(verify_guards()) failed:
 Expected valid memory guards after 8357601 [v2]
In-Reply-To: <Cx4nqbG_ovKrTLfpjh52R-yyHITsIWeYw0BSEVjuxzQ=.dcbfbc7a-da19-414b-8289-d746bd998196@github.com>
References: <u7lxG7g6hNkYD9i4PZlNEfhOfJ49pI0P5YOkk0frfZc=.09cf3e57-d974-4c5a-adca-a1920f49346c@github.com>
 <Cx4nqbG_ovKrTLfpjh52R-yyHITsIWeYw0BSEVjuxzQ=.dcbfbc7a-da19-414b-8289-d746bd998196@github.com>
Message-ID: <XWvIfP_KzqjtBoDLj8LnwlNL5uK-7Y_cAHRT4nuUN3I=.179a1afd-95ce-44eb-97c5-c4621827642b@github.com>

On Sat, 5 Jul 2025 17:34:26 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Big Endian fix for [JDK-8357601](https://bugs.openjdk.org/browse/JDK-8357601).
>> 
>> Note: The first commit is only a Big Endian fix. The code looks still wrong for platforms which don't support unaligned accesses. Also see `UseUnalignedAccesses`.
>> The second commit changes to check `os::is_readable_range()`.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use os::is_readable_range().

Will be handled by [JDK-8361447](https://bugs.openjdk.org/browse/JDK-8361447).

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

PR Comment: https://git.openjdk.org/jdk/pull/26140#issuecomment-3043966400

From mdoerr at openjdk.org  Mon Jul  7 08:32:46 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 7 Jul 2025 08:32:46 GMT
Subject: Withdrawn: 8361433: [Big Endian] assert(verify_guards()) failed:
 Expected valid memory guards after 8357601
In-Reply-To: <u7lxG7g6hNkYD9i4PZlNEfhOfJ49pI0P5YOkk0frfZc=.09cf3e57-d974-4c5a-adca-a1920f49346c@github.com>
References: <u7lxG7g6hNkYD9i4PZlNEfhOfJ49pI0P5YOkk0frfZc=.09cf3e57-d974-4c5a-adca-a1920f49346c@github.com>
Message-ID: <w16kkXeO4haObk2szh-RY3swKVn9jMa-mCDvOHN9Tm8=.883e1eb8-f850-4562-a9f4-90ff63c3ac4e@github.com>

On Fri, 4 Jul 2025 22:46:53 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Big Endian fix for [JDK-8357601](https://bugs.openjdk.org/browse/JDK-8357601).
> 
> Note: The first commit is only a Big Endian fix. The code looks still wrong for platforms which don't support unaligned accesses. Also see `UseUnalignedAccesses`.
> The second commit changes to check `os::is_readable_range()`.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Mon Jul  7 15:04:51 2025
From: duke at openjdk.org (duke)
Date: Mon, 7 Jul 2025 15:04:51 GMT
Subject: Withdrawn: 8356756: Cleanup: Make ClassLoaderData::_deallocate_list an
 object
In-Reply-To: <ricqli5_Ni9B8x9152BiX7rfL4g5jodL-wOvbA5KJrA=.569a6575-43c6-47cb-abb5-3b4050caa999@github.com>
References: <ricqli5_Ni9B8x9152BiX7rfL4g5jodL-wOvbA5KJrA=.569a6575-43c6-47cb-abb5-3b4050caa999@github.com>
Message-ID: <p-ctCzKttLGdmcx8ahFgQwUXYEpbjHeZYJ_KAPcuZu4=.9e52fdfd-4321-4cdf-a86e-6e805a6d221f@github.com>

On Thu, 8 May 2025 12:08:31 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> A small cleanup in order to get rid of some branches checking for null.
> 
> Testing: GHA

This pull request has been closed without being integrated.

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

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

From kvn at openjdk.org  Mon Jul  7 19:39:38 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 7 Jul 2025 19:39:38 GMT
Subject: [jdk25] RFR: 8360164: AOT cache creation crashes in
 ~ThreadTotalCPUTimeClosure()
In-Reply-To: <99jog4TdKhIldbCzRaCKtzyOiZBiNhv90xaM-xoEsDA=.e8c481a8-fc25-4001-afd1-d562402aefec@github.com>
References: <99jog4TdKhIldbCzRaCKtzyOiZBiNhv90xaM-xoEsDA=.e8c481a8-fc25-4001-afd1-d562402aefec@github.com>
Message-ID: <kTuY5U8voIBk2Kxa0q67M9EuDqmYjWXgSlaR0vyiEgc=.50f32148-ba0b-4d0d-9924-d5a85a11ee7a@github.com>

On Sun, 6 Jul 2025 23:02:53 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [7d7e60c8](https://github.com/openjdk/jdk/commit/7d7e60c8aebc4b4c1e7121be702393e5bc46e9ce) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Ioi Lam on 1 Jul 2025 and was reviewed by Calvin Cheung, Vladimir Kozlov and David Holmes.
> 
> Thanks!

Good.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26149#pullrequestreview-2995073801

From kvn at openjdk.org  Mon Jul  7 23:33:39 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 7 Jul 2025 23:33:39 GMT
Subject: RFR: 8361367: AOT ExcludedClasses.java test failed with missing
 constant pool logs
In-Reply-To: <6dHEJG2KXApX0AaS5p2MeDDIZ2bF4cy7PVSjPpGMan4=.7d3eccb1-1796-498f-9d6c-e0669b566415@github.com>
References: <6dHEJG2KXApX0AaS5p2MeDDIZ2bF4cy7PVSjPpGMan4=.7d3eccb1-1796-498f-9d6c-e0669b566415@github.com>
Message-ID: <PHQO0WvFZ20OBwjqJgzWcVty3DOqdRR7WT0cFBD9bQo=.d653ba97-1edc-45b7-beb8-4d7140386ba1@github.com>

On Fri, 4 Jul 2025 16:46:07 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This is a test bug.
> 
> The failures happen with `-Xcomp`. The following method is executed completely in compiled code:
> 
> 
> static int hotSpot() {
>     ShouldBeExcluded s = new ShouldBeExcluded();
>     [.....]
>     return counter + s.m() + s.f + b.m() + b.f;
> }
> 
> 
> 
> C1 can generate code for reading `s.f` without resolving the `ShouldBeExcluded:f:I` reference inside the constant pool. Therefore, I removed two log messages from the test that may not be printed if the compiler happens to compile the corresponding bytecodes.

Good.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26136#pullrequestreview-2995540387

From kvn at openjdk.org  Tue Jul  8 02:06:39 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 8 Jul 2025 02:06:39 GMT
Subject: RFR: 8344548: Incorrect StartAggressiveSweepingAt doc for
 segmented code cache [v2]
In-Reply-To: <IYrVic9d23GxH2dBdAD-2zj1zTrfOUaLUHycxyOE2ek=.39df5c00-1eee-4149-9b93-ea09c558d8a3@github.com>
References: <4Kb1CzIxoBR4DXR9htBr3NINCgUup9coKCNFurAi93c=.253f5490-2263-4b3d-b921-2737ead6bb0a@github.com>
 <IYrVic9d23GxH2dBdAD-2zj1zTrfOUaLUHycxyOE2ek=.39df5c00-1eee-4149-9b93-ea09c558d8a3@github.com>
Message-ID: <Fk_4VTHI2JaeECzXH1gytbe5ceNLgOLngFn33MfUtRc=.f919a231-a18a-43dd-9edf-9c179bbb99ad@github.com>

On Fri, 4 Jul 2025 14:13:27 GMT, guanqiang han <duke at openjdk.org> wrote:

>> The flag StartAggressiveSweepingAt triggers aggressive code cache sweeping based on the percentage of free space in the entire code cache. The previous description referenced segmented vs non-segmented code cache, which is confusing and does not reflect the current implementation.
>> 
>> This patch updates the flag description to clearly state that the threshold is based on the total code cache free percentage, regardless of segmentation.
>
> guanqiang han has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - correct a compile error
>  - Merge remote-tracking branch 'upstream/master' into 8344548
>  - 8344548: Incorrect StartAggressiveSweepingAt doc for segmented code cache
>    
>    The flag StartAggressiveSweepingAt triggers aggressive code cache sweeping based on the percentage of free space in the entire code cache. The previous description referenced segmented vs non-segmented code cache, which is
>    confusing and does not reflect the current implementation.
>    
>    This patch updates the flag description to clearly state that the threshold is based on the total code cache free percentage, regardless of segmentation.

src/hotspot/share/runtime/globals.hpp line 1573:

> 1571:                                                                             \
> 1572:   product(uintx, StartAggressiveSweepingAt, 10,                             \
> 1573:           "Start aggressive sweeping if X[%] of the total code cache is free.")\

I suggest : "Start aggressive sweeping if less than X[%] of the total code cache is free.")

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26114#discussion_r2191326749

From duke at openjdk.org  Tue Jul  8 02:37:39 2025
From: duke at openjdk.org (guanqiang han)
Date: Tue, 8 Jul 2025 02:37:39 GMT
Subject: RFR: 8344548: Incorrect StartAggressiveSweepingAt doc for
 segmented code cache [v2]
In-Reply-To: <Fk_4VTHI2JaeECzXH1gytbe5ceNLgOLngFn33MfUtRc=.f919a231-a18a-43dd-9edf-9c179bbb99ad@github.com>
References: <4Kb1CzIxoBR4DXR9htBr3NINCgUup9coKCNFurAi93c=.253f5490-2263-4b3d-b921-2737ead6bb0a@github.com>
 <IYrVic9d23GxH2dBdAD-2zj1zTrfOUaLUHycxyOE2ek=.39df5c00-1eee-4149-9b93-ea09c558d8a3@github.com>
 <Fk_4VTHI2JaeECzXH1gytbe5ceNLgOLngFn33MfUtRc=.f919a231-a18a-43dd-9edf-9c179bbb99ad@github.com>
Message-ID: <M26o4r3h8FlBlJRmvSkM0iOpWu0f-q8mf4yWpGc0q-M=.8b7e5592-8807-42da-831f-ba4eb793d96d@github.com>

On Tue, 8 Jul 2025 02:04:01 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> guanqiang han has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - correct a compile error
>>  - Merge remote-tracking branch 'upstream/master' into 8344548
>>  - 8344548: Incorrect StartAggressiveSweepingAt doc for segmented code cache
>>    
>>    The flag StartAggressiveSweepingAt triggers aggressive code cache sweeping based on the percentage of free space in the entire code cache. The previous description referenced segmented vs non-segmented code cache, which is
>>    confusing and does not reflect the current implementation.
>>    
>>    This patch updates the flag description to clearly state that the threshold is based on the total code cache free percentage, regardless of segmentation.
>
> src/hotspot/share/runtime/globals.hpp line 1573:
> 
>> 1571:                                                                             \
>> 1572:   product(uintx, StartAggressiveSweepingAt, 10,                             \
>> 1573:           "Start aggressive sweeping if X[%] of the total code cache is free.")\
> 
> I suggest : "Start aggressive sweeping if less than X[%] of the total code cache is free.")

Thank you very much for your valuable feedback. Your description is much clearer and more precise. I will update my PR accordingly.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26114#discussion_r2191354527

From duke at openjdk.org  Tue Jul  8 03:26:18 2025
From: duke at openjdk.org (guanqiang han)
Date: Tue, 8 Jul 2025 03:26:18 GMT
Subject: RFR: 8344548: Incorrect StartAggressiveSweepingAt doc for
 segmented code cache [v3]
In-Reply-To: <4Kb1CzIxoBR4DXR9htBr3NINCgUup9coKCNFurAi93c=.253f5490-2263-4b3d-b921-2737ead6bb0a@github.com>
References: <4Kb1CzIxoBR4DXR9htBr3NINCgUup9coKCNFurAi93c=.253f5490-2263-4b3d-b921-2737ead6bb0a@github.com>
Message-ID: <yskv9RlO5954R0-HDswrMMykGoCLnYe3QMaasT10-fU=.5a53ffa0-033b-4e39-bddf-c3a376e0d4ec@github.com>

> The flag StartAggressiveSweepingAt triggers aggressive code cache sweeping based on the percentage of free space in the entire code cache. The previous description referenced segmented vs non-segmented code cache, which is confusing and does not reflect the current implementation.
> 
> This patch updates the flag description to clearly state that the threshold is based on the total code cache free percentage, regardless of segmentation.

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

 - make description more precise
 - Merge remote-tracking branch 'upstream/master' into 8344548
 - correct a compile error
 - Merge remote-tracking branch 'upstream/master' into 8344548
 - 8344548: Incorrect StartAggressiveSweepingAt doc for segmented code cache
   
   The flag StartAggressiveSweepingAt triggers aggressive code cache sweeping based on the percentage of free space in the entire code cache. The previous description referenced segmented vs non-segmented code cache, which is
   confusing and does not reflect the current implementation.
   
   This patch updates the flag description to clearly state that the threshold is based on the total code cache free percentage, regardless of segmentation.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26114/files
  - new: https://git.openjdk.org/jdk/pull/26114/files/cb1b2c60..6b82418e

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

  Stats: 2179 lines in 96 files changed: 973 ins; 663 del; 543 mod
  Patch: https://git.openjdk.org/jdk/pull/26114.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26114/head:pull/26114

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

From duke at openjdk.org  Tue Jul  8 04:03:38 2025
From: duke at openjdk.org (guanqiang han)
Date: Tue, 8 Jul 2025 04:03:38 GMT
Subject: RFR: 8344548: Incorrect StartAggressiveSweepingAt doc for
 segmented code cache [v2]
In-Reply-To: <M26o4r3h8FlBlJRmvSkM0iOpWu0f-q8mf4yWpGc0q-M=.8b7e5592-8807-42da-831f-ba4eb793d96d@github.com>
References: <4Kb1CzIxoBR4DXR9htBr3NINCgUup9coKCNFurAi93c=.253f5490-2263-4b3d-b921-2737ead6bb0a@github.com>
 <IYrVic9d23GxH2dBdAD-2zj1zTrfOUaLUHycxyOE2ek=.39df5c00-1eee-4149-9b93-ea09c558d8a3@github.com>
 <Fk_4VTHI2JaeECzXH1gytbe5ceNLgOLngFn33MfUtRc=.f919a231-a18a-43dd-9edf-9c179bbb99ad@github.com>
 <M26o4r3h8FlBlJRmvSkM0iOpWu0f-q8mf4yWpGc0q-M=.8b7e5592-8807-42da-831f-ba4eb793d96d@github.com>
Message-ID: <UGGjKXDtreq8gJd0SNtAt_I5s7vCxV4gZ3RNnNssfro=.03580aed-c3e2-49c5-b281-b04a7739dd5b@github.com>

On Tue, 8 Jul 2025 02:35:05 GMT, guanqiang han <duke at openjdk.org> wrote:

>> src/hotspot/share/runtime/globals.hpp line 1573:
>> 
>>> 1571:                                                                             \
>>> 1572:   product(uintx, StartAggressiveSweepingAt, 10,                             \
>>> 1573:           "Start aggressive sweeping if X[%] of the total code cache is free.")\
>> 
>> I suggest : "Start aggressive sweeping if less than X[%] of the total code cache is free.")
>
> Thank you very much for your valuable feedback. Your description is much clearer and more precise. I will update my PR accordingly.

I?ve updated the PR based on your feedback?please kindly take another look when convenient?thanks a lot .

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26114#discussion_r2191425052

From dholmes at openjdk.org  Tue Jul  8 07:10:24 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 8 Jul 2025 07:10:24 GMT
Subject: RFR: 8356942:
 =?UTF-8?B?aW52b2tlaW50ZXJmYWNlwqBUaHJvd3PCoEFic3RyYWN0TWV0aG9kRXJyb3LCoEluc3RlYWQ=?=
 =?UTF-8?B?IA==?= =?UTF-8?B?b2bCoEluY29tcGF0aWJsZUNsYXNzQ2hhbmdlRXJyb3I=?= [v2]
In-Reply-To: <8Dh9B06hDuORGQ-uufrbswlGw9ABFFCA62sCJSUnJaY=.6498b7e8-a39b-43f0-a76f-a0ed9aea3905@github.com>
References: <8Dh9B06hDuORGQ-uufrbswlGw9ABFFCA62sCJSUnJaY=.6498b7e8-a39b-43f0-a76f-a0ed9aea3905@github.com>
Message-ID: <pOjAt2RD7YT6mRCalsFuSICmPZiGwU5WcvnIyLeuPzg=.421033ec-bb28-433d-ba2f-da5d9ded2a40@github.com>

> In [JDK-8186092](https://bugs.openjdk.org/browse/JDK-8186092) (way back in JDK 10) we elided loader constraint checks for overpass methods related to default methods by skipping them when initializing the itable for the interface. But that was the wrong thing to do. The overpass method is setup when there is a resolution/selection error so that the correct exception is thrown if the problematic method is invoked (like the ICCE reporting conflicting methods) and by eliding that entry we instead get the `AbstractMethhodError`.
> 
> The fix here is to revert that change from [JDK-8186092](https://bugs.openjdk.org/browse/JDK-8186092), and to address the loader constraint problem by adding the same check for overpass methods in `klassItable::check_constraints` that exists for `klassVtable::check_constraints`.
> 
> Testing:
>  - new regression test
>  - tiers 1-4
> 
> Thanks
> 
> PS. The diff is much smaller if you disable whitespace differences.

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

  Replaced new test by updating existing defmeth case that was missing the invokeinterface variants of the
  test scenario. Also updated all tests therein to use `throwsExact` so that the wrong kind of ICCE does not
  cause the test to pass by mistake.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26122/files
  - new: https://git.openjdk.org/jdk/pull/26122/files/5e49c497..29883542

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

  Stats: 185 lines in 6 files changed: 8 ins; 154 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/26122.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26122/head:pull/26122

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

From kvn at openjdk.org  Tue Jul  8 07:20:40 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 8 Jul 2025 07:20:40 GMT
Subject: RFR: 8344548: Incorrect StartAggressiveSweepingAt doc for
 segmented code cache [v3]
In-Reply-To: <yskv9RlO5954R0-HDswrMMykGoCLnYe3QMaasT10-fU=.5a53ffa0-033b-4e39-bddf-c3a376e0d4ec@github.com>
References: <4Kb1CzIxoBR4DXR9htBr3NINCgUup9coKCNFurAi93c=.253f5490-2263-4b3d-b921-2737ead6bb0a@github.com>
 <yskv9RlO5954R0-HDswrMMykGoCLnYe3QMaasT10-fU=.5a53ffa0-033b-4e39-bddf-c3a376e0d4ec@github.com>
Message-ID: <3cbbO8fFBbiVaNQXLtDWg29AFsf-_CqFMSJulIz4QUw=.3a4318bd-ae20-4082-abbd-7828450c50d3@github.com>

On Tue, 8 Jul 2025 03:26:18 GMT, guanqiang han <duke at openjdk.org> wrote:

>> The flag StartAggressiveSweepingAt triggers aggressive code cache sweeping based on the percentage of free space in the entire code cache. The previous description referenced segmented vs non-segmented code cache, which is confusing and does not reflect the current implementation.
>> 
>> This patch updates the flag description to clearly state that the threshold is based on the total code cache free percentage, regardless of segmentation.
>
> guanqiang han has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - make description more precise
>  - Merge remote-tracking branch 'upstream/master' into 8344548
>  - correct a compile error
>  - Merge remote-tracking branch 'upstream/master' into 8344548
>  - 8344548: Incorrect StartAggressiveSweepingAt doc for segmented code cache
>    
>    The flag StartAggressiveSweepingAt triggers aggressive code cache sweeping based on the percentage of free space in the entire code cache. The previous description referenced segmented vs non-segmented code cache, which is
>    confusing and does not reflect the current implementation.
>    
>    This patch updates the flag description to clearly state that the threshold is based on the total code cache free percentage, regardless of segmentation.

Good.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26114#pullrequestreview-2996300301

From duke at openjdk.org  Tue Jul  8 07:25:44 2025
From: duke at openjdk.org (duke)
Date: Tue, 8 Jul 2025 07:25:44 GMT
Subject: RFR: 8344548: Incorrect StartAggressiveSweepingAt doc for
 segmented code cache [v3]
In-Reply-To: <yskv9RlO5954R0-HDswrMMykGoCLnYe3QMaasT10-fU=.5a53ffa0-033b-4e39-bddf-c3a376e0d4ec@github.com>
References: <4Kb1CzIxoBR4DXR9htBr3NINCgUup9coKCNFurAi93c=.253f5490-2263-4b3d-b921-2737ead6bb0a@github.com>
 <yskv9RlO5954R0-HDswrMMykGoCLnYe3QMaasT10-fU=.5a53ffa0-033b-4e39-bddf-c3a376e0d4ec@github.com>
Message-ID: <d7V7Ypf29VDwjG01ToQZ8rKpEzvK7EU_jkI8xjiLSUk=.db03b69f-f397-417e-8c83-b56dfaab6441@github.com>

On Tue, 8 Jul 2025 03:26:18 GMT, guanqiang han <duke at openjdk.org> wrote:

>> The flag StartAggressiveSweepingAt triggers aggressive code cache sweeping based on the percentage of free space in the entire code cache. The previous description referenced segmented vs non-segmented code cache, which is confusing and does not reflect the current implementation.
>> 
>> This patch updates the flag description to clearly state that the threshold is based on the total code cache free percentage, regardless of segmentation.
>
> guanqiang han has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - make description more precise
>  - Merge remote-tracking branch 'upstream/master' into 8344548
>  - correct a compile error
>  - Merge remote-tracking branch 'upstream/master' into 8344548
>  - 8344548: Incorrect StartAggressiveSweepingAt doc for segmented code cache
>    
>    The flag StartAggressiveSweepingAt triggers aggressive code cache sweeping based on the percentage of free space in the entire code cache. The previous description referenced segmented vs non-segmented code cache, which is
>    confusing and does not reflect the current implementation.
>    
>    This patch updates the flag description to clearly state that the threshold is based on the total code cache free percentage, regardless of segmentation.

@hgqxjj 
Your change (at version 6b82418e4f4cdd40dd764d9657c27c6d08e5752e) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/26114#issuecomment-3047687262

From duke at openjdk.org  Tue Jul  8 11:52:49 2025
From: duke at openjdk.org (Guanqiang Han)
Date: Tue, 8 Jul 2025 11:52:49 GMT
Subject: Integrated: 8344548: Incorrect StartAggressiveSweepingAt doc for
 segmented code cache
In-Reply-To: <4Kb1CzIxoBR4DXR9htBr3NINCgUup9coKCNFurAi93c=.253f5490-2263-4b3d-b921-2737ead6bb0a@github.com>
References: <4Kb1CzIxoBR4DXR9htBr3NINCgUup9coKCNFurAi93c=.253f5490-2263-4b3d-b921-2737ead6bb0a@github.com>
Message-ID: <jbGplc5jHm5biBZYUiO7iy-F5SV-vm4hYzt9zbH3KFE=.f557d205-34bc-4063-8c98-94bb2ee520de@github.com>

On Thu, 3 Jul 2025 11:29:02 GMT, Guanqiang Han <duke at openjdk.org> wrote:

> The flag StartAggressiveSweepingAt triggers aggressive code cache sweeping based on the percentage of free space in the entire code cache. The previous description referenced segmented vs non-segmented code cache, which is confusing and does not reflect the current implementation.
> 
> This patch updates the flag description to clearly state that the threshold is based on the total code cache free percentage, regardless of segmentation.

This pull request has now been integrated.

Changeset: 27e6a4d2
Author:    han gq <hanguanqiang at kylinos.cn>
Committer: Evgeny Astigeevich <eastigeevich at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/27e6a4d2f7a4bdd12408e518e86aeb623f1c41bc
Stats:     3 lines in 1 file changed: 0 ins; 2 del; 1 mod

8344548: Incorrect StartAggressiveSweepingAt doc for segmented code cache

Reviewed-by: kvn, eastigeevich

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

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

From coleenp at openjdk.org  Tue Jul  8 11:57:40 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 8 Jul 2025 11:57:40 GMT
Subject: RFR: 8356942:
 =?UTF-8?B?aW52b2tlaW50ZXJmYWNlwqBUaHJvd3PCoEFic3RyYWN0TWV0aG9kRXJyb3LCoEluc3RlYWQ=?=
 =?UTF-8?B?IA==?= =?UTF-8?B?b2bCoEluY29tcGF0aWJsZUNsYXNzQ2hhbmdlRXJyb3I=?= [v2]
In-Reply-To: <pOjAt2RD7YT6mRCalsFuSICmPZiGwU5WcvnIyLeuPzg=.421033ec-bb28-433d-ba2f-da5d9ded2a40@github.com>
References: <8Dh9B06hDuORGQ-uufrbswlGw9ABFFCA62sCJSUnJaY=.6498b7e8-a39b-43f0-a76f-a0ed9aea3905@github.com>
 <pOjAt2RD7YT6mRCalsFuSICmPZiGwU5WcvnIyLeuPzg=.421033ec-bb28-433d-ba2f-da5d9ded2a40@github.com>
Message-ID: <a9zjRTMFu1eSi02KzbJrCbFxq3DG3u76fesPNxB9t1s=.0c155f80-7c52-4eec-99f5-970543ec72cd@github.com>

On Tue, 8 Jul 2025 07:10:24 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> In [JDK-8186092](https://bugs.openjdk.org/browse/JDK-8186092) (way back in JDK 10) we elided loader constraint checks for overpass methods related to default methods by skipping them when initializing the itable for the interface. But that was the wrong thing to do. The overpass method is setup when there is a resolution/selection error so that the correct exception is thrown if the problematic method is invoked (like the ICCE reporting conflicting methods) and by eliding that entry we instead get the `AbstractMethhodError`.
>> 
>> The fix here is to revert that change from [JDK-8186092](https://bugs.openjdk.org/browse/JDK-8186092), and to address the loader constraint problem by adding the same check for overpass methods in `klassItable::check_constraints` that exists for `klassVtable::check_constraints`.
>> 
>> Testing:
>>  - modified existing regression test
>>  - tiers 1-4
>> 
>> EDIT: originally there was a new regression test for this, but this area is already covered by the `vmTestBase` "`defmeth` tests. That test was missing the necessary invocation modes to expose the bug, so they have been added.
>> 
>> Thanks
>> 
>> PS. The diff is much smaller if you disable whitespace differences.
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replaced new test by updating existing defmeth case that was missing the invokeinterface variants of the
>   test scenario. Also updated all tests therein to use `throwsExact` so that the wrong kind of ICCE does not
>   cause the test to pass by mistake.

test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/ConflictingDefaultsTest.java line 86:

> 84:      * TEST: C c = new C(); c.m() ==> ICCE
> 85:      * TEST: I c = new C(); c.m() ==> ICCE
> 86:      * TEST: J c = new C(); c.m() ==> ICCE

So this is the generator code that generates the defmeth tests, but iirc, the tests are regenerated and the generated tests were the ones checked in and run.

And shouldn't the test from commit 87e30fd80172c5bd6748f140ddf6cd19adb62764 now fail?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26122#discussion_r2192297473

From dholmes at openjdk.org  Tue Jul  8 12:19:41 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 8 Jul 2025 12:19:41 GMT
Subject: RFR: 8356942:
 =?UTF-8?B?aW52b2tlaW50ZXJmYWNlwqBUaHJvd3PCoEFic3RyYWN0TWV0aG9kRXJyb3LCoEluc3RlYWQ=?=
 =?UTF-8?B?IA==?= =?UTF-8?B?b2bCoEluY29tcGF0aWJsZUNsYXNzQ2hhbmdlRXJyb3I=?= [v2]
In-Reply-To: <a9zjRTMFu1eSi02KzbJrCbFxq3DG3u76fesPNxB9t1s=.0c155f80-7c52-4eec-99f5-970543ec72cd@github.com>
References: <8Dh9B06hDuORGQ-uufrbswlGw9ABFFCA62sCJSUnJaY=.6498b7e8-a39b-43f0-a76f-a0ed9aea3905@github.com>
 <pOjAt2RD7YT6mRCalsFuSICmPZiGwU5WcvnIyLeuPzg=.421033ec-bb28-433d-ba2f-da5d9ded2a40@github.com>
 <a9zjRTMFu1eSi02KzbJrCbFxq3DG3u76fesPNxB9t1s=.0c155f80-7c52-4eec-99f5-970543ec72cd@github.com>
Message-ID: <-c65aEhmouyig7RWwCWBJxkhPXNnzL0-Wf-BTppYdVI=.e77dad5f-def7-43c1-87f1-44e969a1b1bf@github.com>

On Tue, 8 Jul 2025 11:55:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replaced new test by updating existing defmeth case that was missing the invokeinterface variants of the
>>   test scenario. Also updated all tests therein to use `throwsExact` so that the wrong kind of ICCE does not
>>   cause the test to pass by mistake.
>
> test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/ConflictingDefaultsTest.java line 86:
> 
>> 84:      * TEST: C c = new C(); c.m() ==> ICCE
>> 85:      * TEST: I c = new C(); c.m() ==> ICCE
>> 86:      * TEST: J c = new C(); c.m() ==> ICCE
> 
> So this is the generator code that generates the defmeth tests, but iirc, the tests are regenerated and the generated tests were the ones checked in and run.
> 
> And shouldn't the test from commit 87e30fd80172c5bd6748f140ddf6cd19adb62764 now fail?

I'm not aware of any checked in generated tests. I added the new tests here and they run.

Why should the test for loader-constraints fail? I fixed that issue just in a different way to the original fix. Hence the test passes as it should.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26122#discussion_r2192351727

From coleenp at openjdk.org  Tue Jul  8 12:24:39 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 8 Jul 2025 12:24:39 GMT
Subject: RFR: 8356942:
 =?UTF-8?B?aW52b2tlaW50ZXJmYWNlwqBUaHJvd3PCoEFic3RyYWN0TWV0aG9kRXJyb3LCoEluc3RlYWQ=?=
 =?UTF-8?B?IA==?= =?UTF-8?B?b2bCoEluY29tcGF0aWJsZUNsYXNzQ2hhbmdlRXJyb3I=?= [v2]
In-Reply-To: <pOjAt2RD7YT6mRCalsFuSICmPZiGwU5WcvnIyLeuPzg=.421033ec-bb28-433d-ba2f-da5d9ded2a40@github.com>
References: <8Dh9B06hDuORGQ-uufrbswlGw9ABFFCA62sCJSUnJaY=.6498b7e8-a39b-43f0-a76f-a0ed9aea3905@github.com>
 <pOjAt2RD7YT6mRCalsFuSICmPZiGwU5WcvnIyLeuPzg=.421033ec-bb28-433d-ba2f-da5d9ded2a40@github.com>
Message-ID: <sg2BaA5GbTmSv0xhlICIEuwWODgdoVIpXrXvrK5TFTQ=.e42c54a5-5dbf-4ea7-9ea1-2257df5ef96a@github.com>

On Tue, 8 Jul 2025 07:10:24 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> In [JDK-8186092](https://bugs.openjdk.org/browse/JDK-8186092) (way back in JDK 10) we elided loader constraint checks for overpass methods related to default methods by skipping them when initializing the itable for the interface. But that was the wrong thing to do. The overpass method is setup when there is a resolution/selection error so that the correct exception is thrown if the problematic method is invoked (like the ICCE reporting conflicting methods) and by eliding that entry we instead get the `AbstractMethhodError`.
>> 
>> The fix here is to revert that change from [JDK-8186092](https://bugs.openjdk.org/browse/JDK-8186092), and to address the loader constraint problem by adding the same check for overpass methods in `klassItable::check_constraints` that exists for `klassVtable::check_constraints`.
>> 
>> Testing:
>>  - modified existing regression test
>>  - tiers 1-4
>> 
>> EDIT: originally there was a new regression test for this, but this area is already covered by the `vmTestBase` "`defmeth` tests. That test was missing the necessary invocation modes to expose the bug, so they have been added.
>> 
>> Thanks
>> 
>> PS. The diff is much smaller if you disable whitespace differences.
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replaced new test by updating existing defmeth case that was missing the invokeinterface variants of the
>   test scenario. Also updated all tests therein to use `throwsExact` so that the wrong kind of ICCE does not
>   cause the test to pass by mistake.

Still so many questions...

src/hotspot/share/oops/klassVtable.cpp line 1185:

> 1183:       // Do not check loader constraints for overpass methods because overpass
> 1184:       // methods are created by the jvm to throw exceptions.
> 1185:       if (!target->is_overpass()) {

Why are loader constraints not checked for overpass methods?  In your description it says they _are_ checked?  But not here?  If the two methods that are duplicate on the inheritance path and should get ICCE have a loader constraint violation with one of their parameter or return type, they should get a LinkageError, but not ICCE.

What's confusing is that there are two check_constraints - I was looking at the wrong one that also has the !target->is_overpass() condition.  Are these mostly the same now?  Maybe after this change is backported they can be refactored so they share more code.

src/hotspot/share/oops/klassVtable.cpp line 1342:

> 1340:     if (target == nullptr || !target->is_public() || target->is_abstract()) {
> 1341:       // Entry does not resolve. Leave it empty for AbstractMethodError or other error.
> 1342:       if (!(target == nullptr) && !target->is_public()) {

Since you're here, can you fix this line to be target != nullptr ?  This part makes sense.  The reason to have overpass methods is to participate in resolution and selection.

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

PR Review: https://git.openjdk.org/jdk/pull/26122#pullrequestreview-2997364151
PR Review Comment: https://git.openjdk.org/jdk/pull/26122#discussion_r2192364443
PR Review Comment: https://git.openjdk.org/jdk/pull/26122#discussion_r2192339867

From iklam at openjdk.org  Tue Jul  8 17:37:44 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 8 Jul 2025 17:37:44 GMT
Subject: RFR: 8361367: AOT ExcludedClasses.java test failed with missing
 constant pool logs
In-Reply-To: <-inTQD4Kcvo55qQxKtF8d0D7GuyVLjzT1rpNpUH3EhQ=.d57613fb-a82f-4888-bb7b-92990020db87@github.com>
References: <6dHEJG2KXApX0AaS5p2MeDDIZ2bF4cy7PVSjPpGMan4=.7d3eccb1-1796-498f-9d6c-e0669b566415@github.com>
 <-inTQD4Kcvo55qQxKtF8d0D7GuyVLjzT1rpNpUH3EhQ=.d57613fb-a82f-4888-bb7b-92990020db87@github.com>
Message-ID: <QIeXMbzqv6uS0yO7BRTLKJO4dn21N3jD07Lx3y6gdxA=.3c7ded87-8fc2-41fb-9cfd-d1260750ce08@github.com>

On Mon, 7 Jul 2025 07:43:30 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This is a test bug.
>> 
>> The failures happen with `-Xcomp`. The following method is executed completely in compiled code:
>> 
>> 
>> static int hotSpot() {
>>     ShouldBeExcluded s = new ShouldBeExcluded();
>>     [.....]
>>     return counter + s.m() + s.f + b.m() + b.f;
>> }
>> 
>> 
>> 
>> C1 can generate code for reading `s.f` without resolving the `ShouldBeExcluded:f:I` reference inside the constant pool. Therefore, I removed two log messages from the test that may not be printed if the compiler happens to compile the corresponding bytecodes.
>
> Seems reasonable.
> 
> Thanks

Thanks @dholmes-ora @vnkozlov for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/26136#issuecomment-3049762957

From iklam at openjdk.org  Tue Jul  8 17:37:45 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 8 Jul 2025 17:37:45 GMT
Subject: Integrated: 8361367: AOT ExcludedClasses.java test failed with missing
 constant pool logs
In-Reply-To: <6dHEJG2KXApX0AaS5p2MeDDIZ2bF4cy7PVSjPpGMan4=.7d3eccb1-1796-498f-9d6c-e0669b566415@github.com>
References: <6dHEJG2KXApX0AaS5p2MeDDIZ2bF4cy7PVSjPpGMan4=.7d3eccb1-1796-498f-9d6c-e0669b566415@github.com>
Message-ID: <mDlOlpqMXDc67Xh3UGqy_AU38_OX3QL5r_e0kZAn_hI=.f5455694-d327-4573-9033-5fd0b9e2822f@github.com>

On Fri, 4 Jul 2025 16:46:07 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This is a test bug.
> 
> The failures happen with `-Xcomp`. The following method is executed completely in compiled code:
> 
> 
> static int hotSpot() {
>     ShouldBeExcluded s = new ShouldBeExcluded();
>     [.....]
>     return counter + s.m() + s.f + b.m() + b.f;
> }
> 
> 
> 
> C1 can generate code for reading `s.f` without resolving the `ShouldBeExcluded:f:I` reference inside the constant pool. Therefore, I removed two log messages from the test that may not be printed if the compiler happens to compile the corresponding bytecodes.

This pull request has now been integrated.

Changeset: 92712ef4
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/92712ef45dd81fa9f03fbd6427f8c1507f28e62b
Stats:     4 lines in 1 file changed: 0 ins; 3 del; 1 mod

8361367: AOT ExcludedClasses.java test failed with missing constant pool logs

Reviewed-by: dholmes, kvn

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

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

From iklam at openjdk.org  Tue Jul  8 17:38:45 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 8 Jul 2025 17:38:45 GMT
Subject: [jdk25] Integrated: 8360164: AOT cache creation crashes in
 ~ThreadTotalCPUTimeClosure()
In-Reply-To: <99jog4TdKhIldbCzRaCKtzyOiZBiNhv90xaM-xoEsDA=.e8c481a8-fc25-4001-afd1-d562402aefec@github.com>
References: <99jog4TdKhIldbCzRaCKtzyOiZBiNhv90xaM-xoEsDA=.e8c481a8-fc25-4001-afd1-d562402aefec@github.com>
Message-ID: <DBQmIWtzIQ3JfwpW_wRFQ2V4QjEt7ZjrJ2YtbjdGuOw=.78043d41-5bf8-4388-b61d-d60f01999b34@github.com>

On Sun, 6 Jul 2025 23:02:53 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [7d7e60c8](https://github.com/openjdk/jdk/commit/7d7e60c8aebc4b4c1e7121be702393e5bc46e9ce) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Ioi Lam on 1 Jul 2025 and was reviewed by Calvin Cheung, Vladimir Kozlov and David Holmes.
> 
> Thanks!

This pull request has now been integrated.

Changeset: b8965318
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b8965318c1b1ddafac7df6c0d6c807586876ebcf
Stats:     3 lines in 1 file changed: 1 ins; 2 del; 0 mod

8360164: AOT cache creation crashes in ~ThreadTotalCPUTimeClosure()

Reviewed-by: shade, kvn
Backport-of: 7d7e60c8aebc4b4c1e7121be702393e5bc46e9ce

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

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

From dholmes at openjdk.org  Tue Jul  8 21:22:44 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 8 Jul 2025 21:22:44 GMT
Subject: RFR: 8356942:
 =?UTF-8?B?aW52b2tlaW50ZXJmYWNlwqBUaHJvd3PCoEFic3RyYWN0TWV0aG9kRXJyb3LCoEluc3RlYWQ=?=
 =?UTF-8?B?IA==?= =?UTF-8?B?b2bCoEluY29tcGF0aWJsZUNsYXNzQ2hhbmdlRXJyb3I=?= [v2]
In-Reply-To: <sg2BaA5GbTmSv0xhlICIEuwWODgdoVIpXrXvrK5TFTQ=.e42c54a5-5dbf-4ea7-9ea1-2257df5ef96a@github.com>
References: <8Dh9B06hDuORGQ-uufrbswlGw9ABFFCA62sCJSUnJaY=.6498b7e8-a39b-43f0-a76f-a0ed9aea3905@github.com>
 <pOjAt2RD7YT6mRCalsFuSICmPZiGwU5WcvnIyLeuPzg=.421033ec-bb28-433d-ba2f-da5d9ded2a40@github.com>
 <sg2BaA5GbTmSv0xhlICIEuwWODgdoVIpXrXvrK5TFTQ=.e42c54a5-5dbf-4ea7-9ea1-2257df5ef96a@github.com>
Message-ID: <qgXzh3EB8S2kJ1gPQtwzV0r9AzOQwUglDQ99fJIjPX0=.f90c32e5-600d-42b1-a40d-0384568fe4ee@github.com>

On Tue, 8 Jul 2025 12:11:16 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replaced new test by updating existing defmeth case that was missing the invokeinterface variants of the
>>   test scenario. Also updated all tests therein to use `throwsExact` so that the wrong kind of ICCE does not
>>   cause the test to pass by mistake.
>
> src/hotspot/share/oops/klassVtable.cpp line 1342:
> 
>> 1340:     if (target == nullptr || !target->is_public() || target->is_abstract()) {
>> 1341:       // Entry does not resolve. Leave it empty for AbstractMethodError or other error.
>> 1342:       if (!(target == nullptr) && !target->is_public()) {
> 
> Since you're here, can you fix this line to be target != nullptr ?  This part makes sense.  The reason to have overpass methods is to participate in resolution and selection.

Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26122#discussion_r2193461830

From dholmes at openjdk.org  Tue Jul  8 21:25:56 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 8 Jul 2025 21:25:56 GMT
Subject: RFR: 8356942:
 =?UTF-8?B?aW52b2tlaW50ZXJmYWNlwqBUaHJvd3PCoEFic3RyYWN0TWV0aG9kRXJyb3LCoEluc3RlYWQ=?=
 =?UTF-8?B?IA==?= =?UTF-8?B?b2bCoEluY29tcGF0aWJsZUNsYXNzQ2hhbmdlRXJyb3I=?= [v3]
In-Reply-To: <8Dh9B06hDuORGQ-uufrbswlGw9ABFFCA62sCJSUnJaY=.6498b7e8-a39b-43f0-a76f-a0ed9aea3905@github.com>
References: <8Dh9B06hDuORGQ-uufrbswlGw9ABFFCA62sCJSUnJaY=.6498b7e8-a39b-43f0-a76f-a0ed9aea3905@github.com>
Message-ID: <S8h6abDBVIYEXswCi8IRPCFvaBbX5-ZE6WbfeFMJ2NE=.e9e9baba-6563-4403-a2c0-a7235dc13a3b@github.com>

> In [JDK-8186092](https://bugs.openjdk.org/browse/JDK-8186092) (way back in JDK 10) we elided loader constraint checks for overpass methods related to default methods by skipping them when initializing the itable for the interface. But that was the wrong thing to do. The overpass method is setup when there is a resolution/selection error so that the correct exception is thrown if the problematic method is invoked (like the ICCE reporting conflicting methods) and by eliding that entry we instead get the `AbstractMethhodError`.
> 
> The fix here is to revert that change from [JDK-8186092](https://bugs.openjdk.org/browse/JDK-8186092), and to address the loader constraint problem by adding the same check for overpass methods in `klassItable::check_constraints` that exists for `klassVtable::check_constraints`.
> 
> Testing:
>  - modified existing regression test
>  - tiers 1-4
> 
> EDIT: originally there was a new regression test for this, but this area is already covered by the `vmTestBase` "`defmeth` tests. That test was missing the necessary invocation modes to expose the bug, so they have been added.
> 
> Thanks
> 
> PS. The diff is much smaller if you disable whitespace differences.

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

  Fix weird logic - requested by Coleen

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26122/files
  - new: https://git.openjdk.org/jdk/pull/26122/files/29883542..d12213e3

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

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

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

From dholmes at openjdk.org  Tue Jul  8 21:31:39 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 8 Jul 2025 21:31:39 GMT
Subject: RFR: 8356942:
 =?UTF-8?B?aW52b2tlaW50ZXJmYWNlwqBUaHJvd3PCoEFic3RyYWN0TWV0aG9kRXJyb3LCoEluc3RlYWQ=?=
 =?UTF-8?B?IA==?= =?UTF-8?B?b2bCoEluY29tcGF0aWJsZUNsYXNzQ2hhbmdlRXJyb3I=?= [v2]
In-Reply-To: <sg2BaA5GbTmSv0xhlICIEuwWODgdoVIpXrXvrK5TFTQ=.e42c54a5-5dbf-4ea7-9ea1-2257df5ef96a@github.com>
References: <8Dh9B06hDuORGQ-uufrbswlGw9ABFFCA62sCJSUnJaY=.6498b7e8-a39b-43f0-a76f-a0ed9aea3905@github.com>
 <pOjAt2RD7YT6mRCalsFuSICmPZiGwU5WcvnIyLeuPzg=.421033ec-bb28-433d-ba2f-da5d9ded2a40@github.com>
 <sg2BaA5GbTmSv0xhlICIEuwWODgdoVIpXrXvrK5TFTQ=.e42c54a5-5dbf-4ea7-9ea1-2257df5ef96a@github.com>
Message-ID: <4XY5qLg38mHt72XRKAxWQIFJHZF0hssJ0_xy61G3SSY=.fe38f7f4-8c49-4c1f-b858-9b58f012cded@github.com>

On Tue, 8 Jul 2025 12:21:46 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replaced new test by updating existing defmeth case that was missing the invokeinterface variants of the
>>   test scenario. Also updated all tests therein to use `throwsExact` so that the wrong kind of ICCE does not
>>   cause the test to pass by mistake.
>
> src/hotspot/share/oops/klassVtable.cpp line 1185:
> 
>> 1183:       // Do not check loader constraints for overpass methods because overpass
>> 1184:       // methods are created by the jvm to throw exceptions.
>> 1185:       if (!target->is_overpass()) {
> 
> Why are loader constraints not checked for overpass methods?  In your description it says they _are_ checked?  But not here?  If the two methods that are duplicate on the inheritance path and should get ICCE have a loader constraint violation with one of their parameter or return type, they should get a LinkageError, but not ICCE.
> 
> What's confusing is that there are two check_constraints - I was looking at the wrong one that also has the !target->is_overpass() condition.  Are these mostly the same now?  Maybe after this change is backported they can be refactored so they share more code.

> Why are loader constraints not checked for overpass methods? In your description it says they are checked? 

I don't follow. They were checked prior to [JDK-8186092](https://bugs.openjdk.org/browse/JDK-8186092) but they should not be - you need to read [JDK-8186092](https://bugs.openjdk.org/browse/JDK-8186092) for the "why". I'm simply changing how we decide to skip them for overpass methods - using the same technique as is already applied to the vtable methods.

> What's confusing is that there are two check_constraints 

Yes one on the `klassVtable` and one on the `klassItable`. They do the same high-level job but are quite different in structure.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26122#discussion_r2193474205

From matsaave at openjdk.org  Tue Jul  8 21:41:13 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 8 Jul 2025 21:41:13 GMT
Subject: RFR: 8344073: Test runtime/cds/appcds/TestParallelGCWithCDS.java#id0
 failed
Message-ID: <JvKCH6SOsxxw19hCu2s1jSIzWqx3r0oyYHtdzlprre4=.24adaec7-c400-4131-8ecd-e6eda7884d62@github.com>

TestParallelGCWithCDS.java runs with various heap sizes even though a heap size of 2MB can be too small for G1. This patch changes the test so that it only runs with a 4MB heap.

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

Commit messages:
 - 8344073: Test runtime/cds/appcds/TestParallelGCWithCDS.java#id0 failed

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

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

From ccheung at openjdk.org  Tue Jul  8 22:15:38 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 8 Jul 2025 22:15:38 GMT
Subject: RFR: 8344073: Test
 runtime/cds/appcds/TestParallelGCWithCDS.java#id0 failed
In-Reply-To: <JvKCH6SOsxxw19hCu2s1jSIzWqx3r0oyYHtdzlprre4=.24adaec7-c400-4131-8ecd-e6eda7884d62@github.com>
References: <JvKCH6SOsxxw19hCu2s1jSIzWqx3r0oyYHtdzlprre4=.24adaec7-c400-4131-8ecd-e6eda7884d62@github.com>
Message-ID: <Ic0jvpJ71blAts3xKaTVBPqJBseWT5hsv_4AFLWkMtM=.aacca2e4-1469-45ba-add1-f4db5430cb10@github.com>

On Tue, 8 Jul 2025 21:36:14 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> TestParallelGCWithCDS.java runs with various heap sizes even though a heap size of 2MB can be too small for G1. This patch changes the test so that it only runs with a 4MB heap.

Looks good. I think it can be simplified further.

test/hotspot/jtreg/runtime/cds/appcds/TestParallelGCWithCDS.java line 128:

> 126:             // We dumped with G1, so we have an archived heap. At exec time, try to load them into
> 127:             // a small ParallelGC heap that may be too small.
> 128:             System.out.println("=======\n" + n + ". Exec with " + execGC);

Since you got rid of the `for` loop, I think it can be simplified without using the `n` variable.
Suggestion:

           System.out.println("2. Exec with " + execGC);

test/hotspot/jtreg/runtime/cds/appcds/TestParallelGCWithCDS.java line 143:

> 141:                 out.shouldNotHaveFatalError();
> 142:             }
> 143:             n++;

This can be removed together with its declaration at line 124.

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

PR Review: https://git.openjdk.org/jdk/pull/26204#pullrequestreview-2999215518
PR Review Comment: https://git.openjdk.org/jdk/pull/26204#discussion_r2193520949
PR Review Comment: https://git.openjdk.org/jdk/pull/26204#discussion_r2193521776

From coleenp at openjdk.org  Tue Jul  8 22:40:49 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 8 Jul 2025 22:40:49 GMT
Subject: RFR: 8356942:
 =?UTF-8?B?aW52b2tlaW50ZXJmYWNlwqBUaHJvd3PCoEFic3RyYWN0TWV0aG9kRXJyb3LCoEluc3RlYWQ=?=
 =?UTF-8?B?IA==?= =?UTF-8?B?b2bCoEluY29tcGF0aWJsZUNsYXNzQ2hhbmdlRXJyb3I=?= [v3]
In-Reply-To: <S8h6abDBVIYEXswCi8IRPCFvaBbX5-ZE6WbfeFMJ2NE=.e9e9baba-6563-4403-a2c0-a7235dc13a3b@github.com>
References: <8Dh9B06hDuORGQ-uufrbswlGw9ABFFCA62sCJSUnJaY=.6498b7e8-a39b-43f0-a76f-a0ed9aea3905@github.com>
 <S8h6abDBVIYEXswCi8IRPCFvaBbX5-ZE6WbfeFMJ2NE=.e9e9baba-6563-4403-a2c0-a7235dc13a3b@github.com>
Message-ID: <59TWztBno7U4Y_y3NEHqbpcC3i7tcLVqTk0xEbQErzc=.0f79114c-d276-4a22-824a-3e3c262b925c@github.com>

On Tue, 8 Jul 2025 21:25:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> In [JDK-8186092](https://bugs.openjdk.org/browse/JDK-8186092) (way back in JDK 10) we elided loader constraint checks for overpass methods related to default methods by skipping them when initializing the itable for the interface. But that was the wrong place to do that. The overpass method is setup when there is a resolution/selection error so that the correct exception is thrown if the problematic method is invoked (like the ICCE reporting conflicting methods) and by eliding that entry we instead get the `AbstractMethhodError`.
>> 
>> The fix here is to revert that change from [JDK-8186092](https://bugs.openjdk.org/browse/JDK-8186092), and to address the loader constraint problem by adding the same check for overpass methods in `klassItable::check_constraints` that exists for `klassVtable::check_constraints`.
>> 
>> Testing:
>>  - modified existing regression test
>>  - tiers 1-4
>> 
>> EDIT: originally there was a new regression test for this, but this area is already covered by the `vmTestBase` "`defmeth` tests. That test was missing the necessary invocation modes to expose the bug, so they have been added.
>> 
>> Thanks
>> 
>> PS. The diff is much smaller if you disable whitespace differences.
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix weird logic - requested by Coleen

Looks good.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26122#pullrequestreview-2999252763

From coleenp at openjdk.org  Tue Jul  8 22:40:51 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 8 Jul 2025 22:40:51 GMT
Subject: RFR: 8356942:
 =?UTF-8?B?aW52b2tlaW50ZXJmYWNlwqBUaHJvd3PCoEFic3RyYWN0TWV0aG9kRXJyb3LCoEluc3RlYWQ=?=
 =?UTF-8?B?IA==?= =?UTF-8?B?b2bCoEluY29tcGF0aWJsZUNsYXNzQ2hhbmdlRXJyb3I=?= [v2]
In-Reply-To: <4XY5qLg38mHt72XRKAxWQIFJHZF0hssJ0_xy61G3SSY=.fe38f7f4-8c49-4c1f-b858-9b58f012cded@github.com>
References: <8Dh9B06hDuORGQ-uufrbswlGw9ABFFCA62sCJSUnJaY=.6498b7e8-a39b-43f0-a76f-a0ed9aea3905@github.com>
 <pOjAt2RD7YT6mRCalsFuSICmPZiGwU5WcvnIyLeuPzg=.421033ec-bb28-433d-ba2f-da5d9ded2a40@github.com>
 <sg2BaA5GbTmSv0xhlICIEuwWODgdoVIpXrXvrK5TFTQ=.e42c54a5-5dbf-4ea7-9ea1-2257df5ef96a@github.com>
 <4XY5qLg38mHt72XRKAxWQIFJHZF0hssJ0_xy61G3SSY=.fe38f7f4-8c49-4c1f-b858-9b58f012cded@github.com>
Message-ID: <GBMukQiS8N_ylAQCIULNr269aey4MYtqV6D6tK03iZ4=.c531a8d0-86a0-4804-8198-4e9d468cfbe9@github.com>

On Tue, 8 Jul 2025 21:28:57 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/oops/klassVtable.cpp line 1185:
>> 
>>> 1183:       // Do not check loader constraints for overpass methods because overpass
>>> 1184:       // methods are created by the jvm to throw exceptions.
>>> 1185:       if (!target->is_overpass()) {
>> 
>> Why are loader constraints not checked for overpass methods?  In your description it says they _are_ checked?  But not here?  If the two methods that are duplicate on the inheritance path and should get ICCE have a loader constraint violation with one of their parameter or return type, they should get a LinkageError, but not ICCE.
>> 
>> What's confusing is that there are two check_constraints - I was looking at the wrong one that also has the !target->is_overpass() condition.  Are these mostly the same now?  Maybe after this change is backported they can be refactored so they share more code.
>
>> Why are loader constraints not checked for overpass methods? In your description it says they are checked? 
> 
> I don't follow. They were checked prior to [JDK-8186092](https://bugs.openjdk.org/browse/JDK-8186092) but they should not be - you need to read [JDK-8186092](https://bugs.openjdk.org/browse/JDK-8186092) for the "why". I'm simply changing how we decide to skip them for overpass methods - using the same technique as is already applied to the vtable methods.
> 
>> What's confusing is that there are two check_constraints 
> 
> Yes one on the `klassVtable` and one on the `klassItable`. They do the same high-level job but are quite different in structure.

Okay.  Now I see (thanks for the explanation).  The wrong thing to do wasn't skipping loader constraint checks, it was where we skip them.  Now that these methods look the same, the consistency is helpful for understanding this.

>> test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/ConflictingDefaultsTest.java line 86:
>> 
>>> 84:      * TEST: C c = new C(); c.m() ==> ICCE
>>> 85:      * TEST: I c = new C(); c.m() ==> ICCE
>>> 86:      * TEST: J c = new C(); c.m() ==> ICCE
>> 
>> So this is the generator code that generates the defmeth tests, but iirc, the tests are regenerated and the generated tests were the ones checked in and run.
>> 
>> And shouldn't the test from commit 87e30fd80172c5bd6748f140ddf6cd19adb62764 now fail?
>
> I'm not aware of any checked in generated tests. I added the new tests here and they run.
> 
> Why should the test for loader-constraints fail? I fixed that issue just in a different way to the original fix. Hence the test passes as it should.

Got it now.

Thanks for verifying that the new tests run.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26122#discussion_r2193547047
PR Review Comment: https://git.openjdk.org/jdk/pull/26122#discussion_r2193547246

From dholmes at openjdk.org  Wed Jul  9 06:35:16 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 9 Jul 2025 06:35:16 GMT
Subject: RFR: 8361647: Report the error reason on failed semaphore calls on
 macOS
Message-ID: <GuJEAc5YWJh8MO9SClBjWpA5WaHhc9L3GPf_Mj_CPw4=.1ac22207-36fa-4753-9515-88a04d3154fb@github.com>

Simple enhancement to report the reason for any failure when using the semaphore on macOS. This is to aid in diagnosing another failure.

Testing:
 - tiers 1-3 sanity
 - manually triggered a failure to check output (see JBS)

Thanks

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

Commit messages:
 - 8361647: Report the error reason on failed semaphore calls on macOS

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

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

From shade at openjdk.org  Wed Jul  9 07:14:42 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 9 Jul 2025 07:14:42 GMT
Subject: RFR: 8361647: Report the error reason on failed semaphore calls on
 macOS
In-Reply-To: <GuJEAc5YWJh8MO9SClBjWpA5WaHhc9L3GPf_Mj_CPw4=.1ac22207-36fa-4753-9515-88a04d3154fb@github.com>
References: <GuJEAc5YWJh8MO9SClBjWpA5WaHhc9L3GPf_Mj_CPw4=.1ac22207-36fa-4753-9515-88a04d3154fb@github.com>
Message-ID: <ZwxT9IkFrvakXNNHCkQgXryhL0LyClP6Zb5BFnxJLTY=.9dc16737-971c-41ff-a218-6c019002a0a4@github.com>

On Wed, 9 Jul 2025 06:30:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Simple enhancement to report the reason for any failure when using the semaphore on macOS. This is to aid in diagnosing another failure.
> 
> Testing:
>  - tiers 1-3 sanity
>  - manually triggered a failure to check output (see JBS)
> 
> Thanks

Looks reasonable.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26212#pullrequestreview-3000329329

From ayang at openjdk.org  Wed Jul  9 07:25:37 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 9 Jul 2025 07:25:37 GMT
Subject: RFR: 8361647: Report the error reason on failed semaphore calls on
 macOS
In-Reply-To: <GuJEAc5YWJh8MO9SClBjWpA5WaHhc9L3GPf_Mj_CPw4=.1ac22207-36fa-4753-9515-88a04d3154fb@github.com>
References: <GuJEAc5YWJh8MO9SClBjWpA5WaHhc9L3GPf_Mj_CPw4=.1ac22207-36fa-4753-9515-88a04d3154fb@github.com>
Message-ID: <MdCYxbKN6ZNKmWzO_6A6b2Tc3TynYsalTiuwMAhRKT4=.b8d884a2-942a-4209-9c61-de50a7187b67@github.com>

On Wed, 9 Jul 2025 06:30:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Simple enhancement to report the reason for any failure when using the semaphore on macOS. This is to aid in diagnosing another failure.
> 
> Testing:
>  - tiers 1-3 sanity
>  - manually triggered a failure to check output (see JBS)
> 
> Thanks

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26212#pullrequestreview-3000360403

From jwaters at openjdk.org  Wed Jul  9 09:33:38 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 9 Jul 2025 09:33:38 GMT
Subject: RFR: 8361647: Report the error reason on failed semaphore calls on
 macOS
In-Reply-To: <GuJEAc5YWJh8MO9SClBjWpA5WaHhc9L3GPf_Mj_CPw4=.1ac22207-36fa-4753-9515-88a04d3154fb@github.com>
References: <GuJEAc5YWJh8MO9SClBjWpA5WaHhc9L3GPf_Mj_CPw4=.1ac22207-36fa-4753-9515-88a04d3154fb@github.com>
Message-ID: <Q0XflDgXcd_0-SuBnX5WXpMrWgB75Y32zIIL2SuzajM=.183a468e-7582-4e2d-8a3f-5b1a343a9e80@github.com>

On Wed, 9 Jul 2025 06:30:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Simple enhancement to report the reason for any failure when using the semaphore on macOS. This is to aid in diagnosing another failure.
> 
> Testing:
>  - tiers 1-3 sanity
>  - manually triggered a failure to check output (see JBS)
> 
> Thanks

Looks ok, I'm curious why the name of the method was changed though

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

Marked as reviewed by jwaters (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26212#pullrequestreview-3000775211

From mbaesken at openjdk.org  Wed Jul  9 10:44:24 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 9 Jul 2025 10:44:24 GMT
Subject: RFR: 8360941: [ubsan] MemRegion::end() shows runtime error: applying
 non-zero offset 8388608 to null pointer
Message-ID: <LP6FbAxZpwbGf6lkNvLcSRSEOu-mYKjWGAJYBSIMcyk=.775595dc-7f73-4248-a235-f4b58933396b@github.com>

When running HS test
gtest/GTestWrapper.java
with ubsan-enabled binaries on macOS aarch64, the following error is reported (did not see this so far on Linux but there we use gcc and it seems the gcc/ubsan checks are a bit more limited).

test/hotspot/gtest/gc/g1/test_freeRegionList.cpp:37: Failure
Death test: child_G1FreeRegionList_length_()
    Result: died but not with expected exit code:
            Terminated by signal 6 (core dumped)
Actual msg:

[  DEATH   ] /jdk/src/hotspot/share/memory/memRegion.hpp:66:43: runtime error: applying non-zero offset 8388608 to null pointer
[  DEATH   ]     #0 0x108afd6f4 in MemRegion::end() const+0x84 (libjvm.dylib:arm64+0x16556f4)
[  DEATH   ]     #1 0x1075c68a0 in G1FreeRegionList_length_other_vm_Test::TestBody()+0x380 (libjvm.dylib:arm64+0x11e8a0)
[  DEATH   ]     #2 0x1090f3bb0 in testing::Test::Run()+0xc0 (libjvm.dylib:arm64+0x1c4bbb0)
[  DEATH   ]     #3 0x1090f4d94 in testing::TestInfo::Run()+0x1e4 (libjvm.dylib:arm64+0x1c4cd94)
[  DEATH   ]     #4 0x1090f6754 in testing::TestSuite::Run()+0x43c (libjvm.dylib:arm64+0x1c4e754)
[  DEATH   ]     #5 0x109103ca0 in testing::internal::UnitTestImpl::RunAllTests()+0x48c (libjvm.dylib:arm64+0x1c5bca0)
[  DEATH   ]     #6 0x109103588 in testing::UnitTest::Run()+0x78 (libjvm.dylib:arm64+0x1c5b588)
[  DEATH   ]     #7 0x1074a9ac0 in runUnitTestsInner(int, char**)+0x724 (libjvm.dylib:arm64+0x1ac0)
[  DEATH   ]     #8 0x102dc3f18 in main+0x2c (gtestLauncher:arm64+0x100003f18)
[  DEATH   ]     #9 0x196fea0dc  (<unknown module>)
[  DEATH   ] 
[  DEATH   ] SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /jdk/src/hotspot/share/memory/memRegion.hpp:66:43 in 
[  DEATH   ] 



Seems the test_freeRegionList.cpp uses a special MemRegion starting at nullptr ; but this causes a bit of trouble when adding to start == nullptr .
So far I see this issue just in the gtest, seems other MemRegion objects do not start at nullptr .

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

Commit messages:
 - JDK-8360941

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

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

From matsaave at openjdk.org  Wed Jul  9 14:06:55 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 9 Jul 2025 14:06:55 GMT
Subject: RFR: 8344073: Test
 runtime/cds/appcds/TestParallelGCWithCDS.java#id0 failed [v2]
In-Reply-To: <JvKCH6SOsxxw19hCu2s1jSIzWqx3r0oyYHtdzlprre4=.24adaec7-c400-4131-8ecd-e6eda7884d62@github.com>
References: <JvKCH6SOsxxw19hCu2s1jSIzWqx3r0oyYHtdzlprre4=.24adaec7-c400-4131-8ecd-e6eda7884d62@github.com>
Message-ID: <f_RdRtjthAIxIwTog5owdaD-Q5FFcSRrpgUX0EUMLfA=.b6bc7be2-47ea-4a38-9c86-f146cc8b58f8@github.com>

> TestParallelGCWithCDS.java runs with various heap sizes even though a heap size of 2MB can be too small for G1. This patch changes the test so that it only runs with a 4MB heap.

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  Calvin comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26204/files
  - new: https://git.openjdk.org/jdk/pull/26204/files/98359391..3fee7ea3

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

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

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

From iklam at openjdk.org  Wed Jul  9 15:41:39 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 9 Jul 2025 15:41:39 GMT
Subject: RFR: 8344073: Test
 runtime/cds/appcds/TestParallelGCWithCDS.java#id0 failed [v2]
In-Reply-To: <f_RdRtjthAIxIwTog5owdaD-Q5FFcSRrpgUX0EUMLfA=.b6bc7be2-47ea-4a38-9c86-f146cc8b58f8@github.com>
References: <JvKCH6SOsxxw19hCu2s1jSIzWqx3r0oyYHtdzlprre4=.24adaec7-c400-4131-8ecd-e6eda7884d62@github.com>
 <f_RdRtjthAIxIwTog5owdaD-Q5FFcSRrpgUX0EUMLfA=.b6bc7be2-47ea-4a38-9c86-f146cc8b58f8@github.com>
Message-ID: <qzpfwor-b3FAs8FlQjXLoykAiyQiezeY_XfJNSrn-YY=.14590d0e-b159-41a3-be51-01d87f697d63@github.com>

On Wed, 9 Jul 2025 14:06:55 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> TestParallelGCWithCDS.java runs with various heap sizes even though a heap size of 2MB can be too small for G1. This patch changes the test so that it only runs with a 4MB heap.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Calvin comments

LGTM

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

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26204#pullrequestreview-3002058304

From ccheung at openjdk.org  Wed Jul  9 16:01:38 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 9 Jul 2025 16:01:38 GMT
Subject: RFR: 8344073: Test
 runtime/cds/appcds/TestParallelGCWithCDS.java#id0 failed [v2]
In-Reply-To: <f_RdRtjthAIxIwTog5owdaD-Q5FFcSRrpgUX0EUMLfA=.b6bc7be2-47ea-4a38-9c86-f146cc8b58f8@github.com>
References: <JvKCH6SOsxxw19hCu2s1jSIzWqx3r0oyYHtdzlprre4=.24adaec7-c400-4131-8ecd-e6eda7884d62@github.com>
 <f_RdRtjthAIxIwTog5owdaD-Q5FFcSRrpgUX0EUMLfA=.b6bc7be2-47ea-4a38-9c86-f146cc8b58f8@github.com>
Message-ID: <UjaqtTN6wNe1v7ZSvNyQo1Kok9RTaWgch2ruOQFEU80=.e18cabca-0a42-48b3-a1a0-17018020aec5@github.com>

On Wed, 9 Jul 2025 14:06:55 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> TestParallelGCWithCDS.java runs with various heap sizes even though a heap size of 2MB can be too small for G1. This patch changes the test so that it only runs with a 4MB heap.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Calvin comments

Marked as reviewed by ccheung (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26204#pullrequestreview-3002124109

From matsaave at openjdk.org  Wed Jul  9 20:47:47 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 9 Jul 2025 20:47:47 GMT
Subject: RFR: 8344073: Test
 runtime/cds/appcds/TestParallelGCWithCDS.java#id0 failed [v2]
In-Reply-To: <UjaqtTN6wNe1v7ZSvNyQo1Kok9RTaWgch2ruOQFEU80=.e18cabca-0a42-48b3-a1a0-17018020aec5@github.com>
References: <JvKCH6SOsxxw19hCu2s1jSIzWqx3r0oyYHtdzlprre4=.24adaec7-c400-4131-8ecd-e6eda7884d62@github.com>
 <f_RdRtjthAIxIwTog5owdaD-Q5FFcSRrpgUX0EUMLfA=.b6bc7be2-47ea-4a38-9c86-f146cc8b58f8@github.com>
 <UjaqtTN6wNe1v7ZSvNyQo1Kok9RTaWgch2ruOQFEU80=.e18cabca-0a42-48b3-a1a0-17018020aec5@github.com>
Message-ID: <1ytHdtSJTZK3uS3kMG8LEB9yvZMdCzfH0Dws1Fam464=.52518d57-a109-4541-b3fa-b272fd4f1cd6@github.com>

On Wed, 9 Jul 2025 15:58:44 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Calvin comments
>
> Marked as reviewed by ccheung (Reviewer).

Thanks for the reviews @calvinccheung and @iklam!

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

PR Comment: https://git.openjdk.org/jdk/pull/26204#issuecomment-3053951856

From matsaave at openjdk.org  Wed Jul  9 20:47:49 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 9 Jul 2025 20:47:49 GMT
Subject: Integrated: 8344073: Test
 runtime/cds/appcds/TestParallelGCWithCDS.java#id0 failed
In-Reply-To: <JvKCH6SOsxxw19hCu2s1jSIzWqx3r0oyYHtdzlprre4=.24adaec7-c400-4131-8ecd-e6eda7884d62@github.com>
References: <JvKCH6SOsxxw19hCu2s1jSIzWqx3r0oyYHtdzlprre4=.24adaec7-c400-4131-8ecd-e6eda7884d62@github.com>
Message-ID: <Mx_DYud388S-Axjyfx7cw_gFfR872bp6OO8aQPJsvKo=.8fa06c06-e20d-4708-8da3-84ab9c25d2a1@github.com>

On Tue, 8 Jul 2025 21:36:14 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> TestParallelGCWithCDS.java runs with various heap sizes even though a heap size of 2MB can be too small for G1. This patch changes the test so that it only runs with a 4MB heap.

This pull request has now been integrated.

Changeset: 518536c6
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/518536c607cb383e810ee0f50f8af44e121f4ab3
Stats:     25 lines in 1 file changed: 0 ins; 11 del; 14 mod

8344073: Test runtime/cds/appcds/TestParallelGCWithCDS.java#id0 failed

Reviewed-by: ccheung, iklam

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

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

From iklam at openjdk.org  Wed Jul  9 23:56:45 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 9 Jul 2025 23:56:45 GMT
Subject: RFR: 8313395: LotsUnloadTest.java fails with OOME transiently with
 libgraal
In-Reply-To: <bQoZVMHQRcanfh5HXxyl9hGIuZjlVosw7QALkPYY9WA=.2c564597-efa7-491f-9bae-8e6c7631a269@github.com>
References: <bQoZVMHQRcanfh5HXxyl9hGIuZjlVosw7QALkPYY9WA=.2c564597-efa7-491f-9bae-8e6c7631a269@github.com>
Message-ID: <foL7e1X0W1uDcMhm9eZRrhWLoz2z_2sQkJ3VdlpgLWk=.10557354-012e-406c-bdd4-09c2d0e4182e@github.com>

On Tue, 20 Aug 2024 16:15:51 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This test fails intermittently due to delayed class unloading when both libgraal abd Xcomp enabled. Since the purpose of this test is neither to test libgraal nor Xcomp, it's better to exclude the test in this scenario to reduce noise.

A better fix is in https://github.com/openjdk/jdk/pull/26230

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

PR Comment: https://git.openjdk.org/jdk/pull/20648#issuecomment-3054480561

From iklam at openjdk.org  Wed Jul  9 23:58:12 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 9 Jul 2025 23:58:12 GMT
Subject: RFR: 8313395: LotsUnloadTest.java fails with OOME transiently with
 libgraal
Message-ID: <-yutkjCYs3I-5rdm569NPVDnIzz5ZiUiqRKl3arzE4w=.d5e0e797-f88c-4dde-a6e7-4bb01717fc3a@github.com>

It seems like when libgraal is used as the JIT, more heap space is allocated in the Java heap to support JIT compilation. This causes OOM in the test when the heap is very small.

The test allocates 1024 * 2 MB of heap objects but at any time keeps only 8 MB of them alive. The test expects class unloading would happen when the heap is filled with garbage. By increasing the heap size from 64MB to 256MB, we can still accomplish what the test wants to do but will be more friendly to libgraal.

The fact that libgraal uses more memory is still a concern, but that should be tested elsewhere, and is not the responsibility of this test.

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

Commit messages:
 - 8313395: LotsUnloadTest.java fails with OOME transiently with libgraal

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

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

From dholmes at openjdk.org  Thu Jul 10 01:57:49 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 10 Jul 2025 01:57:49 GMT
Subject: RFR: 8361647: Report the error reason on failed semaphore calls on
 macOS
In-Reply-To: <Q0XflDgXcd_0-SuBnX5WXpMrWgB75Y32zIIL2SuzajM=.183a468e-7582-4e2d-8a3f-5b1a343a9e80@github.com>
References: <GuJEAc5YWJh8MO9SClBjWpA5WaHhc9L3GPf_Mj_CPw4=.1ac22207-36fa-4753-9515-88a04d3154fb@github.com>
 <Q0XflDgXcd_0-SuBnX5WXpMrWgB75Y32zIIL2SuzajM=.183a468e-7582-4e2d-8a3f-5b1a343a9e80@github.com>
Message-ID: <-p6uKZq1WiXlYrO8xYPGHNSlY9Fmv9K0fB6PQplao0w=.9a83369f-e268-43cd-bb61-88f3fa4d5d53@github.com>

On Wed, 9 Jul 2025 09:31:15 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Looks ok, I'm curious why the name of the method was changed though

The name was already a little odd because the function is `semaphore_create` not `sem_init`, but it is where `sem_init_strerror` was called from. Now it is called from all the functions so the `init` part of the name made even less sense.

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

PR Comment: https://git.openjdk.org/jdk/pull/26212#issuecomment-3054979488

From dholmes at openjdk.org  Thu Jul 10 01:57:49 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 10 Jul 2025 01:57:49 GMT
Subject: RFR: 8361647: Report the error reason on failed semaphore calls on
 macOS
In-Reply-To: <GuJEAc5YWJh8MO9SClBjWpA5WaHhc9L3GPf_Mj_CPw4=.1ac22207-36fa-4753-9515-88a04d3154fb@github.com>
References: <GuJEAc5YWJh8MO9SClBjWpA5WaHhc9L3GPf_Mj_CPw4=.1ac22207-36fa-4753-9515-88a04d3154fb@github.com>
Message-ID: <xKyCxyUbF2M9QI3r15bOBwKu0sERrKaP0MszvyzKR7w=.0f084345-7315-44a2-9a6a-eb35b886cb43@github.com>

On Wed, 9 Jul 2025 06:30:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Simple enhancement to report the reason for any failure when using the semaphore on macOS. This is to aid in diagnosing another failure.
> 
> Testing:
>  - tiers 1-3 sanity
>  - manually triggered a failure to check output (see JBS)
> 
> Thanks

Thanks for all the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/26212#issuecomment-3054981634

From dholmes at openjdk.org  Thu Jul 10 01:57:50 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 10 Jul 2025 01:57:50 GMT
Subject: Integrated: 8361647: Report the error reason on failed semaphore calls
 on macOS
In-Reply-To: <GuJEAc5YWJh8MO9SClBjWpA5WaHhc9L3GPf_Mj_CPw4=.1ac22207-36fa-4753-9515-88a04d3154fb@github.com>
References: <GuJEAc5YWJh8MO9SClBjWpA5WaHhc9L3GPf_Mj_CPw4=.1ac22207-36fa-4753-9515-88a04d3154fb@github.com>
Message-ID: <uaXLU2o5nftv4WNECmL6pZMDJSXNFPtgcAIvhaVrHqg=.1774a858-409a-4540-8391-d79ad24aa059@github.com>

On Wed, 9 Jul 2025 06:30:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Simple enhancement to report the reason for any failure when using the semaphore on macOS. This is to aid in diagnosing another failure.
> 
> Testing:
>  - tiers 1-3 sanity
>  - manually triggered a failure to check output (see JBS)
> 
> Thanks

This pull request has now been integrated.

Changeset: c28bb8bf
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c28bb8bf7a0aa6cdd5b97a50fc961a25cb40228a
Stats:     18 lines in 1 file changed: 11 ins; 0 del; 7 mod

8361647: Report the error reason on failed semaphore calls on macOS

Reviewed-by: shade, ayang, jwaters

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

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

From dholmes at openjdk.org  Thu Jul 10 05:06:20 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 10 Jul 2025 05:06:20 GMT
Subject: RFR: 8361754: New test runtime/jni/checked/TestCharArrayReleasing.java
 can cause disk full errors
Message-ID: <gWmJact9gJWh4pFlkM__2BB3AG5v3__iTrM5DTubqJU=.9eb7a364-5f66-428c-93ce-bb29376dd214@github.com>

Please review this trivial fix to the test, which needed to set `-XX:-CreateCoredumpsOnCrash`, after which the exit code is 1 on all platforms.

The test now runs a lot faster too.

Thanks

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

Commit messages:
 - 8361754: New test runtime/jni/checked/TestCharArrayReleasing.java can cause disk full errors

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

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

From jpai at openjdk.org  Thu Jul 10 05:06:20 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 10 Jul 2025 05:06:20 GMT
Subject: RFR: 8361754: New test
 runtime/jni/checked/TestCharArrayReleasing.java can cause disk full errors
In-Reply-To: <gWmJact9gJWh4pFlkM__2BB3AG5v3__iTrM5DTubqJU=.9eb7a364-5f66-428c-93ce-bb29376dd214@github.com>
References: <gWmJact9gJWh4pFlkM__2BB3AG5v3__iTrM5DTubqJU=.9eb7a364-5f66-428c-93ce-bb29376dd214@github.com>
Message-ID: <Rg1HFjwiGRd3cyi_meNFrgj7JJ-kBp5Ngck1gCNtfl8=.701f6e0c-5f42-42a8-9c40-25528f3d5ad1@github.com>

On Thu, 10 Jul 2025 04:58:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this trivial fix to the test, which needed to set `-XX:-CreateCoredumpsOnCrash`, after which the exit code is 1 on all platforms.
> 
> The test now runs a lot faster too.
> 
> Thanks

Looks OK and trivial to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26235#pullrequestreview-3003923803

From darcy at openjdk.org  Thu Jul 10 05:06:20 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 10 Jul 2025 05:06:20 GMT
Subject: RFR: 8361754: New test
 runtime/jni/checked/TestCharArrayReleasing.java can cause disk full errors
In-Reply-To: <gWmJact9gJWh4pFlkM__2BB3AG5v3__iTrM5DTubqJU=.9eb7a364-5f66-428c-93ce-bb29376dd214@github.com>
References: <gWmJact9gJWh4pFlkM__2BB3AG5v3__iTrM5DTubqJU=.9eb7a364-5f66-428c-93ce-bb29376dd214@github.com>
Message-ID: <mdj5rEJsxQqzC3A_SfFyQZw-rVpxydgyAqnQqFz5_Ys=.2344cd01-830a-4da9-836b-d45f0b09aeb9@github.com>

On Thu, 10 Jul 2025 04:58:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this trivial fix to the test, which needed to set `-XX:-CreateCoredumpsOnCrash`, after which the exit code is 1 on all platforms.
> 
> The test now runs a lot faster too.
> 
> Thanks

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26235#pullrequestreview-3003923941

From dholmes at openjdk.org  Thu Jul 10 05:10:43 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 10 Jul 2025 05:10:43 GMT
Subject: RFR: 8361754: New test
 runtime/jni/checked/TestCharArrayReleasing.java can cause disk full errors
In-Reply-To: <Rg1HFjwiGRd3cyi_meNFrgj7JJ-kBp5Ngck1gCNtfl8=.701f6e0c-5f42-42a8-9c40-25528f3d5ad1@github.com>
References: <gWmJact9gJWh4pFlkM__2BB3AG5v3__iTrM5DTubqJU=.9eb7a364-5f66-428c-93ce-bb29376dd214@github.com>
 <Rg1HFjwiGRd3cyi_meNFrgj7JJ-kBp5Ngck1gCNtfl8=.701f6e0c-5f42-42a8-9c40-25528f3d5ad1@github.com>
Message-ID: <25qx1t19ItkYQGDozNu0-BOWQK3W5Uuhb08QHvl8Y4Q=.2819d036-27d3-4050-a734-d86544f3e19c@github.com>

On Thu, 10 Jul 2025 05:01:54 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Please review this trivial fix to the test, which needed to set `-XX:-CreateCoredumpsOnCrash`, after which the exit code is 1 on all platforms.
>> 
>> The test now runs a lot faster too.
>> 
>> Thanks
>
> Looks OK and trivial to me.

Thanks for the reviews @jaikiran and @jddarcy !

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

PR Comment: https://git.openjdk.org/jdk/pull/26235#issuecomment-3055562701

From dholmes at openjdk.org  Thu Jul 10 05:10:43 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 10 Jul 2025 05:10:43 GMT
Subject: Integrated: 8361754: New test
 runtime/jni/checked/TestCharArrayReleasing.java can cause disk full errors
In-Reply-To: <gWmJact9gJWh4pFlkM__2BB3AG5v3__iTrM5DTubqJU=.9eb7a364-5f66-428c-93ce-bb29376dd214@github.com>
References: <gWmJact9gJWh4pFlkM__2BB3AG5v3__iTrM5DTubqJU=.9eb7a364-5f66-428c-93ce-bb29376dd214@github.com>
Message-ID: <J_F0KX46e4fe8wveARQlIiL2atGqynKG_76BLgYJtVA=.2eddf72f-5d89-4555-9c94-6b3b5687b1ac@github.com>

On Thu, 10 Jul 2025 04:58:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this trivial fix to the test, which needed to set `-XX:-CreateCoredumpsOnCrash`, after which the exit code is 1 on all platforms.
> 
> The test now runs a lot faster too.
> 
> Thanks

This pull request has now been integrated.

Changeset: 2a53f5a5
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2a53f5a5c2544d4f7a77186d99addae110b06bab
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8361754: New test runtime/jni/checked/TestCharArrayReleasing.java can cause disk full errors

Reviewed-by: jpai, darcy

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

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

From duke at openjdk.org  Thu Jul 10 07:46:51 2025
From: duke at openjdk.org (duke)
Date: Thu, 10 Jul 2025 07:46:51 GMT
Subject: Withdrawn: 8356277: containers/docker/TestPids.java: Limit value 19128
 is not accepted as unlimited
In-Reply-To: <rh21qpq9dQeP3vq0QGFZEJJ6cKi3YMtnFYNMGpuhFBo=.e60b8ed5-ed91-4d5c-99dd-64f64bdf5530@github.com>
References: <rh21qpq9dQeP3vq0QGFZEJJ6cKi3YMtnFYNMGpuhFBo=.e60b8ed5-ed91-4d5c-99dd-64f64bdf5530@github.com>
Message-ID: <1p0GPqOwrpSM512inN3MkPkgiL5p8tfEU2aBKo5gxYo=.fea4ab45-0eb8-4451-8d66-46e9b2373543@github.com>

On Tue, 6 May 2025 14:06:54 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> When running the testcase in a VM with 16GB RAM it fails as systemd limits DefaultTasksMax based on available RAM.
> 
> 
> test/hotspot/jtreg/containers/docker/TestPids.java
> TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Limit value 19128 is not accepted as unlimited, log line was [0.083s][trace][os,container] Maximum number of tasks is: 19128
> 
> 
> DefaultTasksMax=28776 for RAM 24576MB
> DefaultTasksMax=19128 for RAM 16384MB
> DefaultTasksMax=1088 for RAM 1024MB
> 
> The testcase expects DefaultTasksMax>=20000.

This pull request has been closed without being integrated.

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

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

From dnsimon at openjdk.org  Thu Jul 10 09:41:38 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 10 Jul 2025 09:41:38 GMT
Subject: RFR: 8313395: LotsUnloadTest.java fails with OOME transiently with
 libgraal
In-Reply-To: <-yutkjCYs3I-5rdm569NPVDnIzz5ZiUiqRKl3arzE4w=.d5e0e797-f88c-4dde-a6e7-4bb01717fc3a@github.com>
References: <-yutkjCYs3I-5rdm569NPVDnIzz5ZiUiqRKl3arzE4w=.d5e0e797-f88c-4dde-a6e7-4bb01717fc3a@github.com>
Message-ID: <Di3pAfXTebChcysZnPKIGY45fy3itG1q4N9q3lxzHwE=.a7a34196-2a26-44b2-9fca-44e0cf8f6ba2@github.com>

On Wed, 9 Jul 2025 23:53:53 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> It seems like when libgraal is used as the JIT, more heap space is allocated in the Java heap to support JIT compilation. This causes OOM in the test when the heap is very small.
> 
> The test allocates 1024 * 2 MB of heap objects but at any time keeps only 8 MB of them alive. The test expects class unloading would happen when the heap is filled with garbage. By increasing the heap size from 64MB to 256MB, we can still accomplish what the test wants to do but will be more friendly to libgraal.
> 
> The fact that libgraal uses more memory is still a concern, but that should be tested elsewhere, and is not the responsibility of this test.

Is the increased memory usage of Graal limited to `-Xcomp` runs?

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

PR Comment: https://git.openjdk.org/jdk/pull/26230#issuecomment-3056590327

From dnsimon at openjdk.org  Thu Jul 10 15:54:39 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 10 Jul 2025 15:54:39 GMT
Subject: RFR: 8313395: LotsUnloadTest.java fails with OOME transiently with
 libgraal
In-Reply-To: <-yutkjCYs3I-5rdm569NPVDnIzz5ZiUiqRKl3arzE4w=.d5e0e797-f88c-4dde-a6e7-4bb01717fc3a@github.com>
References: <-yutkjCYs3I-5rdm569NPVDnIzz5ZiUiqRKl3arzE4w=.d5e0e797-f88c-4dde-a6e7-4bb01717fc3a@github.com>
Message-ID: <KsPelV2byBTpBQLkUVPNUr1QQZaGqtAN6VNzFy7z9XI=.c43180fd-0379-4163-a3cc-f0453b12f461@github.com>

On Wed, 9 Jul 2025 23:53:53 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> It seems like when libgraal is used as the JIT, more heap space is allocated in the Java heap to support JIT compilation. This causes OOM in the test when the heap is very small.
> 
> The test allocates 1024 * 2 MB of heap objects but at any time keeps only 8 MB of them alive. The test expects class unloading would happen when the heap is filled with garbage. By increasing the heap size from 64MB to 256MB, we can still accomplish what the test wants to do but will be more friendly to libgraal.
> 
> The fact that libgraal uses more memory is still a concern, but that should be tested elsewhere, and is not the responsibility of this test.

Marked as reviewed by dnsimon (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26230#pullrequestreview-3006346093

From iklam at openjdk.org  Thu Jul 10 15:54:40 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 10 Jul 2025 15:54:40 GMT
Subject: RFR: 8313395: LotsUnloadTest.java fails with OOME transiently with
 libgraal
In-Reply-To: <Di3pAfXTebChcysZnPKIGY45fy3itG1q4N9q3lxzHwE=.a7a34196-2a26-44b2-9fca-44e0cf8f6ba2@github.com>
References: <-yutkjCYs3I-5rdm569NPVDnIzz5ZiUiqRKl3arzE4w=.d5e0e797-f88c-4dde-a6e7-4bb01717fc3a@github.com>
 <Di3pAfXTebChcysZnPKIGY45fy3itG1q4N9q3lxzHwE=.a7a34196-2a26-44b2-9fca-44e0cf8f6ba2@github.com>
Message-ID: <9R_C_icRC_Zcit-R7snUypktyv2CUw7eQ0PzcZHMUhg=.7ed0b602-3ece-46d0-b06c-dad20c203196@github.com>

On Thu, 10 Jul 2025 09:38:56 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> Is the increased memory usage of Graal limited to `-Xcomp` runs?

Yes. Here are the logs from my comments in the bug report. Memory use goes from about 32m to about 96m when -Xcomp is used with graal.


$ java -Xmx64m -Xms32m -Xcomp -cp . LotsUnloadApp
$ java -Xmx64m -Xms32m -Xcomp -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -cp . LotsUnloadApp
$ java -Xmx64m -Xms32m -Xcomp -XX:+UnlockExperimentalVMOptions -XX:+UseGraalJIT -cp . LotsUnloadApp

Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "Thread-3"
Exception in thread "Thread-2" java.lang.OutOfMemoryError: Java heap space
java.lang.OutOfMemoryError: Java heap space
Exception in thread "Thread-0" java.lang.OutOfMemoryError: Java heap space

$ java -Xmx96m -Xms32m -Xcomp -XX:+UnlockExperimentalVMOptions -XX:+UseGraalJIT -cp . LotsUnloadApp
$

$ java -Xmx48m -Xms32m -Xcomp -cp . LotsUnloadApp
$ java -Xmx32m -Xms32m -Xcomp -cp . LotsUnloadApp
$ java -Xmx32m -Xms32m -XX:+UnlockExperimentalVMOptions -XX:+UseGraalJIT -cp . LotsUnloadApp
$

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

PR Comment: https://git.openjdk.org/jdk/pull/26230#issuecomment-3057974643

From dnsimon at openjdk.org  Thu Jul 10 15:54:40 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 10 Jul 2025 15:54:40 GMT
Subject: RFR: 8313395: LotsUnloadTest.java fails with OOME transiently with
 libgraal
In-Reply-To: <9R_C_icRC_Zcit-R7snUypktyv2CUw7eQ0PzcZHMUhg=.7ed0b602-3ece-46d0-b06c-dad20c203196@github.com>
References: <-yutkjCYs3I-5rdm569NPVDnIzz5ZiUiqRKl3arzE4w=.d5e0e797-f88c-4dde-a6e7-4bb01717fc3a@github.com>
 <Di3pAfXTebChcysZnPKIGY45fy3itG1q4N9q3lxzHwE=.a7a34196-2a26-44b2-9fca-44e0cf8f6ba2@github.com>
 <9R_C_icRC_Zcit-R7snUypktyv2CUw7eQ0PzcZHMUhg=.7ed0b602-3ece-46d0-b06c-dad20c203196@github.com>
Message-ID: <vp9qP7g1YemyR7Tn7gVAXgzO4w7S40YL_hHi9_OCCOw=.d893ed46-2482-46b1-bf3e-74a27345a207@github.com>

On Thu, 10 Jul 2025 15:38:08 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Yes. Here are the logs from my comments in the bug report. Memory use goes from about 32m to about 96m when -Xcomp is used with graal.

Ok, thanks. I think that largely mitigates the concern about extra memory usage. Without `-Xcomp`, there will not be many libgraal compilations involving the loaded classes.

These changes look good.

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

PR Comment: https://git.openjdk.org/jdk/pull/26230#issuecomment-3058026700

From ccheung at openjdk.org  Thu Jul 10 20:03:28 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 10 Jul 2025 20:03:28 GMT
Subject: RFR: 8361328:
 cds/appcds/dynamicArchive/TestAutoCreateSharedArchive.java archive timestamps
 comparison failed
Message-ID: <mODxkZ0CAYYqYFUWqwQntFVA_gcuPwhKpOnat_6f02g=.2865f25f-20c6-4a1d-9f34-d21517a03ade@github.com>

This test failure is intermittent and only seen with Windows non-debug build in 21u testing. It is due to the test is comparing the timestamp of a CDS archive with the timestamp of an archive which was generated in a previous test scenario.

Fixing it in mainline and then backport to 25 and 21u.

Testing: tested on Windows non-debug build with JDK 21u.

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

Commit messages:
 - 8361328: cds/appcds/dynamicArchive/TestAutoCreateSharedArchive.java archive timestamps comparison failed

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

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

From ccheung at openjdk.org  Thu Jul 10 21:23:16 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 10 Jul 2025 21:23:16 GMT
Subject: RFR: 8356807: Change log_info(cds) to
 `MetaspaceShared::report_loading_error()`
Message-ID: <0O1bxM4K1u4yAqJdUKntyiF8m9UGd8OeZm_hFZ8oc_c=.f8d8d27f-52be-4080-b7ef-4e253f93281e@github.com>

The patch changes some of the `aot_log_info(aot)()` to `MetaspaceShared::report_loading_error()` for those referring to an error condition during loading of AOT cache or CDS archive.

Passed tiers 1 - 4 testing.

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

Commit messages:
 - 8356807: Change log_info(cds) to

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

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

From iklam at openjdk.org  Thu Jul 10 21:42:45 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 10 Jul 2025 21:42:45 GMT
Subject: RFR: 8313395: LotsUnloadTest.java fails with OOME transiently with
 libgraal
In-Reply-To: <vp9qP7g1YemyR7Tn7gVAXgzO4w7S40YL_hHi9_OCCOw=.d893ed46-2482-46b1-bf3e-74a27345a207@github.com>
References: <-yutkjCYs3I-5rdm569NPVDnIzz5ZiUiqRKl3arzE4w=.d5e0e797-f88c-4dde-a6e7-4bb01717fc3a@github.com>
 <Di3pAfXTebChcysZnPKIGY45fy3itG1q4N9q3lxzHwE=.a7a34196-2a26-44b2-9fca-44e0cf8f6ba2@github.com>
 <9R_C_icRC_Zcit-R7snUypktyv2CUw7eQ0PzcZHMUhg=.7ed0b602-3ece-46d0-b06c-dad20c203196@github.com>
 <vp9qP7g1YemyR7Tn7gVAXgzO4w7S40YL_hHi9_OCCOw=.d893ed46-2482-46b1-bf3e-74a27345a207@github.com>
Message-ID: <PKpHd1_dHSDW5YDdqqHXHdiB8fpWbY2q4ow3iG4QmHw=.1f157351-4059-4801-ac3c-af338a2425fd@github.com>

On Thu, 10 Jul 2025 15:52:15 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>>> Is the increased memory usage of Graal limited to `-Xcomp` runs?
>> 
>> Yes. Here are the logs from my comments in the bug report. Memory use goes from about 32m to about 96m when -Xcomp is used with graal.
>> 
>> 
>> $ java -Xmx64m -Xms32m -Xcomp -cp . LotsUnloadApp
>> $ java -Xmx64m -Xms32m -Xcomp -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -cp . LotsUnloadApp
>> $ java -Xmx64m -Xms32m -Xcomp -XX:+UnlockExperimentalVMOptions -XX:+UseGraalJIT -cp . LotsUnloadApp
>> 
>> Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "Thread-3"
>> Exception in thread "Thread-2" java.lang.OutOfMemoryError: Java heap space
>> java.lang.OutOfMemoryError: Java heap space
>> Exception in thread "Thread-0" java.lang.OutOfMemoryError: Java heap space
>> 
>> $ java -Xmx96m -Xms32m -Xcomp -XX:+UnlockExperimentalVMOptions -XX:+UseGraalJIT -cp . LotsUnloadApp
>> $
>> 
>> $ java -Xmx48m -Xms32m -Xcomp -cp . LotsUnloadApp
>> $ java -Xmx32m -Xms32m -Xcomp -cp . LotsUnloadApp
>> $ java -Xmx32m -Xms32m -XX:+UnlockExperimentalVMOptions -XX:+UseGraalJIT -cp . LotsUnloadApp
>> $
>
>> Yes. Here are the logs from my comments in the bug report. Memory use goes from about 32m to about 96m when -Xcomp is used with graal.
> 
> Ok, thanks. I think that largely mitigates the concern about extra memory usage. Without `-Xcomp`, there will not be many libgraal compilations involving the loaded classes.
> 
> These changes look good.

Thanks @dougxc for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/26230#issuecomment-3059189932

From iklam at openjdk.org  Thu Jul 10 21:42:46 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 10 Jul 2025 21:42:46 GMT
Subject: Integrated: 8313395: LotsUnloadTest.java fails with OOME transiently
 with libgraal
In-Reply-To: <-yutkjCYs3I-5rdm569NPVDnIzz5ZiUiqRKl3arzE4w=.d5e0e797-f88c-4dde-a6e7-4bb01717fc3a@github.com>
References: <-yutkjCYs3I-5rdm569NPVDnIzz5ZiUiqRKl3arzE4w=.d5e0e797-f88c-4dde-a6e7-4bb01717fc3a@github.com>
Message-ID: <fdLsgeXiWUXFMGqWY3Ev78V5cEJ6eEd_CEgZgI8bye0=.c22da6e1-6530-4ebd-82db-75fabc17b17a@github.com>

On Wed, 9 Jul 2025 23:53:53 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> It seems like when libgraal is used as the JIT, more heap space is allocated in the Java heap to support JIT compilation. This causes OOM in the test when the heap is very small.
> 
> The test allocates 1024 * 2 MB of heap objects but at any time keeps only 8 MB of them alive. The test expects class unloading would happen when the heap is filled with garbage. By increasing the heap size from 64MB to 256MB, we can still accomplish what the test wants to do but will be more friendly to libgraal.
> 
> The fact that libgraal uses more memory is still a concern, but that should be tested elsewhere, and is not the responsibility of this test.

This pull request has now been integrated.

Changeset: ee0d309b
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ee0d309bbd33302d8c6f35155e975db77aaea785
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8313395: LotsUnloadTest.java fails with OOME transiently with libgraal

Reviewed-by: dnsimon

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

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

From iklam at openjdk.org  Fri Jul 11 01:37:37 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 11 Jul 2025 01:37:37 GMT
Subject: RFR: 8361328:
 cds/appcds/dynamicArchive/TestAutoCreateSharedArchive.java archive timestamps
 comparison failed
In-Reply-To: <mODxkZ0CAYYqYFUWqwQntFVA_gcuPwhKpOnat_6f02g=.2865f25f-20c6-4a1d-9f34-d21517a03ade@github.com>
References: <mODxkZ0CAYYqYFUWqwQntFVA_gcuPwhKpOnat_6f02g=.2865f25f-20c6-4a1d-9f34-d21517a03ade@github.com>
Message-ID: <SIEhIQqyLHd4_chWEO4N6BCFyxbYVsYp2pfEg98Gv0M=.55c924d8-014c-42bc-8fcf-de94e7f319f4@github.com>

On Thu, 10 Jul 2025 19:58:19 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> This test failure is intermittent and only seen with Windows non-debug build in 21u testing. It is due to the test is comparing the timestamp of a CDS archive with the timestamp of an archive which was generated in a previous test scenario.
> 
> Fixing it in mainline and then backport to 25 and 21u.
> 
> Testing: tested on Windows non-debug build with JDK 21u.

LGTM

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

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26250#pullrequestreview-3008126711

From iklam at openjdk.org  Fri Jul 11 04:21:38 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 11 Jul 2025 04:21:38 GMT
Subject: RFR: 8361383: LogFileStreamOutput::write_decorations uses wrong
 type for format precisions
In-Reply-To: <WEZEQWuO_X8_LVeDe4nIFMk8DkoJSjtu4mqNDDHlE2Y=.d4132938-0cf3-4251-822b-4deba6914034@github.com>
References: <WEZEQWuO_X8_LVeDe4nIFMk8DkoJSjtu4mqNDDHlE2Y=.d4132938-0cf3-4251-822b-4deba6914034@github.com>
Message-ID: <lYl9vGa85n5XTeCe5J2QPM2CjmPTIwZ2pAOYht5fKqY=.81063628-5e20-4eef-820f-99ed1e0cec05@github.com>

On Fri, 4 Jul 2025 00:13:15 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to LogFileStreamOutput to fix the type of the
> precision values used when writing the decorations in a log message.
> 
> While I was at it, value-initialize the _decorator_padding in the
> ctor-initializer rather than with a zero-filling loop.
> 
> Testing: mach5 tier1
> Locally ran several tests that generate logging output and checked by eye the
> decorator output.

Marked as reviewed by iklam (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26124#pullrequestreview-3008500002

From kbarrett at openjdk.org  Fri Jul 11 05:33:44 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 11 Jul 2025 05:33:44 GMT
Subject: RFR: 8361383: LogFileStreamOutput::write_decorations uses wrong
 type for format precisions
In-Reply-To: <A-yz5RckCH4r22VEEnivDm94RzoTNg0ZQlvACunDwPQ=.f8244a6a-0e74-48d3-bc40-48c847185f21@github.com>
References: <WEZEQWuO_X8_LVeDe4nIFMk8DkoJSjtu4mqNDDHlE2Y=.d4132938-0cf3-4251-822b-4deba6914034@github.com>
 <A-yz5RckCH4r22VEEnivDm94RzoTNg0ZQlvACunDwPQ=.f8244a6a-0e74-48d3-bc40-48c847185f21@github.com>
Message-ID: <MQKeQ9-WaZ8CPr4bbicrS8b6TwnKRqPc12sF8WD8Ei8=.6587caa4-665f-4866-b4cd-83f0c601b1e7@github.com>

On Fri, 4 Jul 2025 01:58:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review this change to LogFileStreamOutput to fix the type of the
>> precision values used when writing the decorations in a log message.
>> 
>> While I was at it, value-initialize the _decorator_padding in the
>> ctor-initializer rather than with a zero-filling loop.
>> 
>> Testing: mach5 tier1
>> Locally ran several tests that generate logging output and checked by eye the
>> decorator output.
>
> Looks good. Thanks

Thanks for reviews @dholmes-ora and @iklam

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

PR Comment: https://git.openjdk.org/jdk/pull/26124#issuecomment-3060608983

From kbarrett at openjdk.org  Fri Jul 11 05:33:44 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 11 Jul 2025 05:33:44 GMT
Subject: Integrated: 8361383: LogFileStreamOutput::write_decorations uses wrong
 type for format precisions
In-Reply-To: <WEZEQWuO_X8_LVeDe4nIFMk8DkoJSjtu4mqNDDHlE2Y=.d4132938-0cf3-4251-822b-4deba6914034@github.com>
References: <WEZEQWuO_X8_LVeDe4nIFMk8DkoJSjtu4mqNDDHlE2Y=.d4132938-0cf3-4251-822b-4deba6914034@github.com>
Message-ID: <2vg-KzPz8Faynju9hWQEkH6ZmF9_-JF1tbFwj2FZlKI=.fe938f5f-6b97-4520-a3d4-41a569b42989@github.com>

On Fri, 4 Jul 2025 00:13:15 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to LogFileStreamOutput to fix the type of the
> precision values used when writing the decorations in a log message.
> 
> While I was at it, value-initialize the _decorator_padding in the
> ctor-initializer rather than with a zero-filling loop.
> 
> Testing: mach5 tier1
> Locally ran several tests that generate logging output and checked by eye the
> decorator output.

This pull request has now been integrated.

Changeset: eddfc644
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/eddfc6449f325c55938a2b24fa651a024441b77a
Stats:     9 lines in 2 files changed: 1 ins; 0 del; 8 mod

8361383: LogFileStreamOutput::write_decorations uses wrong type for format precisions

Reviewed-by: dholmes, iklam

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

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

From tschatzl at openjdk.org  Fri Jul 11 10:46:50 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 11 Jul 2025 10:46:50 GMT
Subject: RFR: 8361706: Parallel weak klass link cleaning does not clean out
 previous klasses
Message-ID: <9CeeNb9Hr7qkUrLyEcA36e7q7XQLUChKvDrvTc-t29o=.c84d3081-a8a4-48d0-9e4d-0dc70467ab71@github.com>

Hi all,

  please review this fix to parallel weak klass link cleaning.

`KlassCleaningTask::work()` misses cleaning out previous versions of klasses (created by JVMTI class redefinition) as the regular single-threaded variant would do when calling `Klass::clean_weak_klass_links()` with `clean_live_klasses = true`.

The fix moves the cleaning of weak klass links for previous versions of the klass into `InstanceKlass::clean_weak_instanceklass_links()`.

Testing: gha, tier1-5, many runs of `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java`(with JDK-8361952 also out for review)

Thanks,
  Thomas

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

Commit messages:
 - * remove patch for JDK-8361952
 - * working version, do not recursively clean out
 - * another attempt
 - 8361706

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

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

From eosterlund at openjdk.org  Fri Jul 11 11:25:37 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 11 Jul 2025 11:25:37 GMT
Subject: RFR: 8361706: Parallel weak klass link cleaning does not clean out
 previous klasses
In-Reply-To: <9CeeNb9Hr7qkUrLyEcA36e7q7XQLUChKvDrvTc-t29o=.c84d3081-a8a4-48d0-9e4d-0dc70467ab71@github.com>
References: <9CeeNb9Hr7qkUrLyEcA36e7q7XQLUChKvDrvTc-t29o=.c84d3081-a8a4-48d0-9e4d-0dc70467ab71@github.com>
Message-ID: <dg_xvuQ6egW_SbhRCLyESf7lYT-fGOQNf-rZb9aLw28=.a95623b6-9010-4e44-887f-7864a21ed76f@github.com>

On Fri, 11 Jul 2025 10:38:51 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this fix to parallel weak klass link cleaning.
> 
> `KlassCleaningTask::work()` misses cleaning out previous versions of klasses (created by JVMTI class redefinition) as the regular single-threaded variant would do when calling `Klass::clean_weak_klass_links()` with `clean_live_klasses = true`.
> 
> The fix moves the cleaning of weak klass links for previous versions of the klass into `InstanceKlass::clean_weak_instanceklass_links()`.
> 
> Testing: gha, tier1-5, many runs of `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java`(with JDK-8361952 also out for review)
> 
> Thanks,
>   Thomas

Marked as reviewed by eosterlund (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26263#pullrequestreview-3009862639

From lucy at openjdk.org  Fri Jul 11 16:32:39 2025
From: lucy at openjdk.org (Lutz Schmidt)
Date: Fri, 11 Jul 2025 16:32:39 GMT
Subject: RFR: 8360941: [ubsan] MemRegion::end() shows runtime error:
 applying non-zero offset 8388608 to null pointer
In-Reply-To: <LP6FbAxZpwbGf6lkNvLcSRSEOu-mYKjWGAJYBSIMcyk=.775595dc-7f73-4248-a235-f4b58933396b@github.com>
References: <LP6FbAxZpwbGf6lkNvLcSRSEOu-mYKjWGAJYBSIMcyk=.775595dc-7f73-4248-a235-f4b58933396b@github.com>
Message-ID: <3gLyHX9SNhRjc4nOCj2QxqbGlUhq9OabRNLzHBhYQu4=.83240732-54c2-4260-8ec6-af28919ae2af@github.com>

On Wed, 9 Jul 2025 10:36:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running HS test
> gtest/GTestWrapper.java
> with ubsan-enabled binaries on macOS aarch64, the following error is reported (did not see this so far on Linux but there we use gcc and it seems the gcc/ubsan checks are a bit more limited).
> 
> test/hotspot/gtest/gc/g1/test_freeRegionList.cpp:37: Failure
> Death test: child_G1FreeRegionList_length_()
>     Result: died but not with expected exit code:
>             Terminated by signal 6 (core dumped)
> Actual msg:
> 
> [  DEATH   ] /jdk/src/hotspot/share/memory/memRegion.hpp:66:43: runtime error: applying non-zero offset 8388608 to null pointer
> [  DEATH   ]     #0 0x108afd6f4 in MemRegion::end() const+0x84 (libjvm.dylib:arm64+0x16556f4)
> [  DEATH   ]     #1 0x1075c68a0 in G1FreeRegionList_length_other_vm_Test::TestBody()+0x380 (libjvm.dylib:arm64+0x11e8a0)
> [  DEATH   ]     #2 0x1090f3bb0 in testing::Test::Run()+0xc0 (libjvm.dylib:arm64+0x1c4bbb0)
> [  DEATH   ]     #3 0x1090f4d94 in testing::TestInfo::Run()+0x1e4 (libjvm.dylib:arm64+0x1c4cd94)
> [  DEATH   ]     #4 0x1090f6754 in testing::TestSuite::Run()+0x43c (libjvm.dylib:arm64+0x1c4e754)
> [  DEATH   ]     #5 0x109103ca0 in testing::internal::UnitTestImpl::RunAllTests()+0x48c (libjvm.dylib:arm64+0x1c5bca0)
> [  DEATH   ]     #6 0x109103588 in testing::UnitTest::Run()+0x78 (libjvm.dylib:arm64+0x1c5b588)
> [  DEATH   ]     #7 0x1074a9ac0 in runUnitTestsInner(int, char**)+0x724 (libjvm.dylib:arm64+0x1ac0)
> [  DEATH   ]     #8 0x102dc3f18 in main+0x2c (gtestLauncher:arm64+0x100003f18)
> [  DEATH   ]     #9 0x196fea0dc  (<unknown module>)
> [  DEATH   ] 
> [  DEATH   ] SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /jdk/src/hotspot/share/memory/memRegion.hpp:66:43 in 
> [  DEATH   ] 
> 
> 
> 
> Seems the test_freeRegionList.cpp uses a special MemRegion starting at nullptr ; but this causes a bit of trouble when adding to start == nullptr .
> So far I see this issue just in the gtest, seems other MemRegion objects do not start at nullptr .

Looks awful to me. But anyway - approved.

This is a perfect example where we destroy the clean look of hotspot code to accommodate odd usage. Wouldn't it be better to code the ugly stuff in the test?

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

Marked as reviewed by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26216#pullrequestreview-3011039265

From kbarrett at openjdk.org  Fri Jul 11 17:23:38 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 11 Jul 2025 17:23:38 GMT
Subject: RFR: 8360941: [ubsan] MemRegion::end() shows runtime error:
 applying non-zero offset 8388608 to null pointer
In-Reply-To: <LP6FbAxZpwbGf6lkNvLcSRSEOu-mYKjWGAJYBSIMcyk=.775595dc-7f73-4248-a235-f4b58933396b@github.com>
References: <LP6FbAxZpwbGf6lkNvLcSRSEOu-mYKjWGAJYBSIMcyk=.775595dc-7f73-4248-a235-f4b58933396b@github.com>
Message-ID: <IjDrghHxj_L_e82A6KtgeLFWdsGqhRiLMvjNFrDbdv0=.09cc4e0d-9a0d-4ef8-8439-21061af473a7@github.com>

On Wed, 9 Jul 2025 10:36:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running HS test
> gtest/GTestWrapper.java
> with ubsan-enabled binaries on macOS aarch64, the following error is reported (did not see this so far on Linux but there we use gcc and it seems the gcc/ubsan checks are a bit more limited).
> 
> test/hotspot/gtest/gc/g1/test_freeRegionList.cpp:37: Failure
> Death test: child_G1FreeRegionList_length_()
>     Result: died but not with expected exit code:
>             Terminated by signal 6 (core dumped)
> Actual msg:
> 
> [  DEATH   ] /jdk/src/hotspot/share/memory/memRegion.hpp:66:43: runtime error: applying non-zero offset 8388608 to null pointer
> [  DEATH   ]     #0 0x108afd6f4 in MemRegion::end() const+0x84 (libjvm.dylib:arm64+0x16556f4)
> [  DEATH   ]     #1 0x1075c68a0 in G1FreeRegionList_length_other_vm_Test::TestBody()+0x380 (libjvm.dylib:arm64+0x11e8a0)
> [  DEATH   ]     #2 0x1090f3bb0 in testing::Test::Run()+0xc0 (libjvm.dylib:arm64+0x1c4bbb0)
> [  DEATH   ]     #3 0x1090f4d94 in testing::TestInfo::Run()+0x1e4 (libjvm.dylib:arm64+0x1c4cd94)
> [  DEATH   ]     #4 0x1090f6754 in testing::TestSuite::Run()+0x43c (libjvm.dylib:arm64+0x1c4e754)
> [  DEATH   ]     #5 0x109103ca0 in testing::internal::UnitTestImpl::RunAllTests()+0x48c (libjvm.dylib:arm64+0x1c5bca0)
> [  DEATH   ]     #6 0x109103588 in testing::UnitTest::Run()+0x78 (libjvm.dylib:arm64+0x1c5b588)
> [  DEATH   ]     #7 0x1074a9ac0 in runUnitTestsInner(int, char**)+0x724 (libjvm.dylib:arm64+0x1ac0)
> [  DEATH   ]     #8 0x102dc3f18 in main+0x2c (gtestLauncher:arm64+0x100003f18)
> [  DEATH   ]     #9 0x196fea0dc  (<unknown module>)
> [  DEATH   ] 
> [  DEATH   ] SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /jdk/src/hotspot/share/memory/memRegion.hpp:66:43 in 
> [  DEATH   ] 
> 
> 
> 
> Seems the test_freeRegionList.cpp uses a special MemRegion starting at nullptr ; but this causes a bit of trouble when adding to start == nullptr .
> So far I see this issue just in the gtest, seems other MemRegion objects do not start at nullptr .

Changes requested by kbarrett (Reviewer).

src/hotspot/share/memory/memRegion.hpp line 67:

> 65:   HeapWord* start() const { return _start; }
> 66:   // in the gtests we call end() with a _start == nullptr so adjust the addition to avoid ub
> 67:   HeapWord* end() const   { return reinterpret_cast<HeapWord*>(reinterpret_cast<uintptr_t>(_start) + (_word_size * sizeof(HeapWord))); }

I don't think this change should be made. Instead, fix the offending test.  The fake heap it creates starts
at null, but I think it could be anywhere, because nothing touches it.

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

PR Review: https://git.openjdk.org/jdk/pull/26216#pullrequestreview-3011295775
PR Review Comment: https://git.openjdk.org/jdk/pull/26216#discussion_r2201383050

From kbarrett at openjdk.org  Fri Jul 11 17:28:39 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 11 Jul 2025 17:28:39 GMT
Subject: RFR: 8360941: [ubsan] MemRegion::end() shows runtime error:
 applying non-zero offset 8388608 to null pointer
In-Reply-To: <IjDrghHxj_L_e82A6KtgeLFWdsGqhRiLMvjNFrDbdv0=.09cc4e0d-9a0d-4ef8-8439-21061af473a7@github.com>
References: <LP6FbAxZpwbGf6lkNvLcSRSEOu-mYKjWGAJYBSIMcyk=.775595dc-7f73-4248-a235-f4b58933396b@github.com>
 <IjDrghHxj_L_e82A6KtgeLFWdsGqhRiLMvjNFrDbdv0=.09cc4e0d-9a0d-4ef8-8439-21061af473a7@github.com>
Message-ID: <0dYbgQyQ4pS1i9v1SeMQFdp6rnRMfc4KkpkyMzYjX_U=.d200d56c-54b5-47f0-96d7-1d0fda9d3d44@github.com>

On Fri, 11 Jul 2025 17:21:14 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> When running HS test
>> gtest/GTestWrapper.java
>> with ubsan-enabled binaries on macOS aarch64, the following error is reported (did not see this so far on Linux but there we use gcc and it seems the gcc/ubsan checks are a bit more limited).
>> 
>> test/hotspot/gtest/gc/g1/test_freeRegionList.cpp:37: Failure
>> Death test: child_G1FreeRegionList_length_()
>>     Result: died but not with expected exit code:
>>             Terminated by signal 6 (core dumped)
>> Actual msg:
>> 
>> [  DEATH   ] /jdk/src/hotspot/share/memory/memRegion.hpp:66:43: runtime error: applying non-zero offset 8388608 to null pointer
>> [  DEATH   ]     #0 0x108afd6f4 in MemRegion::end() const+0x84 (libjvm.dylib:arm64+0x16556f4)
>> [  DEATH   ]     #1 0x1075c68a0 in G1FreeRegionList_length_other_vm_Test::TestBody()+0x380 (libjvm.dylib:arm64+0x11e8a0)
>> [  DEATH   ]     #2 0x1090f3bb0 in testing::Test::Run()+0xc0 (libjvm.dylib:arm64+0x1c4bbb0)
>> [  DEATH   ]     #3 0x1090f4d94 in testing::TestInfo::Run()+0x1e4 (libjvm.dylib:arm64+0x1c4cd94)
>> [  DEATH   ]     #4 0x1090f6754 in testing::TestSuite::Run()+0x43c (libjvm.dylib:arm64+0x1c4e754)
>> [  DEATH   ]     #5 0x109103ca0 in testing::internal::UnitTestImpl::RunAllTests()+0x48c (libjvm.dylib:arm64+0x1c5bca0)
>> [  DEATH   ]     #6 0x109103588 in testing::UnitTest::Run()+0x78 (libjvm.dylib:arm64+0x1c5b588)
>> [  DEATH   ]     #7 0x1074a9ac0 in runUnitTestsInner(int, char**)+0x724 (libjvm.dylib:arm64+0x1ac0)
>> [  DEATH   ]     #8 0x102dc3f18 in main+0x2c (gtestLauncher:arm64+0x100003f18)
>> [  DEATH   ]     #9 0x196fea0dc  (<unknown module>)
>> [  DEATH   ] 
>> [  DEATH   ] SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /jdk/src/hotspot/share/memory/memRegion.hpp:66:43 in 
>> [  DEATH   ] 
>> 
>> 
>> 
>> Seems the test_freeRegionList.cpp uses a special MemRegion starting at nullptr ; but this causes a bit of trouble when adding to start == nullptr .
>> So far I see this issue just in the gtest, seems other MemRegion objects do not start at nullptr .
>
> src/hotspot/share/memory/memRegion.hpp line 67:
> 
>> 65:   HeapWord* start() const { return _start; }
>> 66:   // in the gtests we call end() with a _start == nullptr so adjust the addition to avoid ub
>> 67:   HeapWord* end() const   { return reinterpret_cast<HeapWord*>(reinterpret_cast<uintptr_t>(_start) + (_word_size * sizeof(HeapWord))); }
> 
> I don't think this change should be made. Instead, fix the offending test.  The fake heap it creates starts
> at null, but I think it could be anywhere, because nothing touches it.

If it did (or does) need to be valid memory, then just allocate a chunk of
native memory for this fake heap for the test. That might be the safer thing
to do anyway, in case some future change leads to the fake region getting
touched.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26216#discussion_r2201398030

From coleenp at openjdk.org  Fri Jul 11 17:51:40 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 11 Jul 2025 17:51:40 GMT
Subject: RFR: 8361706: Parallel weak klass link cleaning does not clean out
 previous klasses
In-Reply-To: <9CeeNb9Hr7qkUrLyEcA36e7q7XQLUChKvDrvTc-t29o=.c84d3081-a8a4-48d0-9e4d-0dc70467ab71@github.com>
References: <9CeeNb9Hr7qkUrLyEcA36e7q7XQLUChKvDrvTc-t29o=.c84d3081-a8a4-48d0-9e4d-0dc70467ab71@github.com>
Message-ID: <b1dkj1MxRfSFOK7fxYvnywl-9TAS9lPc2crtNuYVgPI=.5d2ce08f-0af7-4339-a85b-5cafe1520c19@github.com>

On Fri, 11 Jul 2025 10:38:51 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this fix to parallel weak klass link cleaning.
> 
> `KlassCleaningTask::work()` misses cleaning out previous versions of klasses (created by JVMTI class redefinition) as the regular single-threaded variant would do when calling `Klass::clean_weak_klass_links()` with `clean_live_klasses = true`.
> 
> The fix moves the cleaning of weak klass links for previous versions of the klass into `InstanceKlass::clean_weak_instanceklass_links()`.
> 
> Testing: gha, tier1-5, many runs of `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java`(with JDK-8361952 also out for review)
> 
> Thanks,
>   Thomas

Can you make InstanceKlass::clean_weak_instanceklass_links() protected?  If not, this looks good.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26263#pullrequestreview-3011375434

From matsaave at openjdk.org  Fri Jul 11 20:46:38 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Fri, 11 Jul 2025 20:46:38 GMT
Subject: RFR: 8361328:
 cds/appcds/dynamicArchive/TestAutoCreateSharedArchive.java archive timestamps
 comparison failed
In-Reply-To: <mODxkZ0CAYYqYFUWqwQntFVA_gcuPwhKpOnat_6f02g=.2865f25f-20c6-4a1d-9f34-d21517a03ade@github.com>
References: <mODxkZ0CAYYqYFUWqwQntFVA_gcuPwhKpOnat_6f02g=.2865f25f-20c6-4a1d-9f34-d21517a03ade@github.com>
Message-ID: <01GBdZdYwfBfYbxRE7Ds3XDN8sQb3WTcwyQhyzQmgFk=.97b35309-ddce-4118-9c09-818fb598498d@github.com>

On Thu, 10 Jul 2025 19:58:19 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> This test failure is intermittent and only seen with Windows non-debug build in 21u testing. It is due to the test is comparing the timestamp of a CDS archive with the timestamp of an archive which was generated in a previous test scenario.
> 
> Fixing it in mainline and then backport to 25 and 21u.
> 
> Testing: tested on Windows non-debug build with JDK 21u.

LGTM!

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

Marked as reviewed by matsaave (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26250#pullrequestreview-3011929717

From ccheung at openjdk.org  Fri Jul 11 23:38:53 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 11 Jul 2025 23:38:53 GMT
Subject: RFR: 8356807: Change log_info(cds) to
 `MetaspaceShared::report_loading_error()` [v2]
In-Reply-To: <0O1bxM4K1u4yAqJdUKntyiF8m9UGd8OeZm_hFZ8oc_c=.f8d8d27f-52be-4080-b7ef-4e253f93281e@github.com>
References: <0O1bxM4K1u4yAqJdUKntyiF8m9UGd8OeZm_hFZ8oc_c=.f8d8d27f-52be-4080-b7ef-4e253f93281e@github.com>
Message-ID: <OpSwmSGO8OWtYFQPNZ1Ln9eRmiEcXGuZ6LcQ3nQl2is=.4a091226-ff3b-422d-9df8-8980afabb20c@github.com>

> The patch changes some of the `aot_log_info(aot)()` to `MetaspaceShared::report_loading_error()` for those referring to an error condition during loading of AOT cache or CDS archive.
> 
> Passed tiers 1 - 4 testing.

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

  update ServiceLoaderTest.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26253/files
  - new: https://git.openjdk.org/jdk/pull/26253/files/1e529f84..c85ff4ee

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

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

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

From ccheung at openjdk.org  Sat Jul 12 00:21:46 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Sat, 12 Jul 2025 00:21:46 GMT
Subject: RFR: 8361328:
 cds/appcds/dynamicArchive/TestAutoCreateSharedArchive.java archive timestamps
 comparison failed
In-Reply-To: <SIEhIQqyLHd4_chWEO4N6BCFyxbYVsYp2pfEg98Gv0M=.55c924d8-014c-42bc-8fcf-de94e7f319f4@github.com>
References: <mODxkZ0CAYYqYFUWqwQntFVA_gcuPwhKpOnat_6f02g=.2865f25f-20c6-4a1d-9f34-d21517a03ade@github.com>
 <SIEhIQqyLHd4_chWEO4N6BCFyxbYVsYp2pfEg98Gv0M=.55c924d8-014c-42bc-8fcf-de94e7f319f4@github.com>
Message-ID: <r0kNIiz6gA5xVFGs_Lyvoib3hkpdp5bpqtAC-bpF6y0=.465ffdca-7229-42a3-b6d1-17acac0a14d9@github.com>

On Fri, 11 Jul 2025 01:34:53 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This test failure is intermittent and only seen with Windows non-debug build in 21u testing. It is due to the test is comparing the timestamp of a CDS archive with the timestamp of an archive which was generated in a previous test scenario.
>> 
>> Fixing it in mainline and then backport to 25 and 21u.
>> 
>> Testing: tested on Windows non-debug build with JDK 21u.
>
> LGTM

Thanks @iklam @matias9927 for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/26250#issuecomment-3064360575

From ccheung at openjdk.org  Sat Jul 12 00:21:47 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Sat, 12 Jul 2025 00:21:47 GMT
Subject: Integrated: 8361328:
 cds/appcds/dynamicArchive/TestAutoCreateSharedArchive.java archive timestamps
 comparison failed
In-Reply-To: <mODxkZ0CAYYqYFUWqwQntFVA_gcuPwhKpOnat_6f02g=.2865f25f-20c6-4a1d-9f34-d21517a03ade@github.com>
References: <mODxkZ0CAYYqYFUWqwQntFVA_gcuPwhKpOnat_6f02g=.2865f25f-20c6-4a1d-9f34-d21517a03ade@github.com>
Message-ID: <UYm5AQ1Pwdd7J619Ka8MesVGDy3xHs8XupvJ17qJcD4=.6f0e5725-ca93-48fe-ba4c-bff6ae73e5b5@github.com>

On Thu, 10 Jul 2025 19:58:19 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> This test failure is intermittent and only seen with Windows non-debug build in 21u testing. It is due to the test is comparing the timestamp of a CDS archive with the timestamp of an archive which was generated in a previous test scenario.
> 
> Fixing it in mainline and then backport to 25 and 21u.
> 
> Testing: tested on Windows non-debug build with JDK 21u.

This pull request has now been integrated.

Changeset: 4a351e3e
Author:    Calvin Cheung <ccheung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4a351e3e57274df0adee37c472b62f477f75b7b8
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8361328: cds/appcds/dynamicArchive/TestAutoCreateSharedArchive.java archive timestamps comparison failed

Reviewed-by: iklam, matsaave

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

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

From dholmes at openjdk.org  Mon Jul 14 03:00:23 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 14 Jul 2025 03:00:23 GMT
Subject: RFR: 8360048: NMT crash in gtest/NMTGtests.java: fatal error: NMT
 corruption: Block at 0x0000017748307120: header canary broken
Message-ID: <gUIff3tC7KO9caTbRleaxcqvTLekIpCVqMu2Gbey19U=.9182d797-acee-4596-8bb6-3d36397c31c7@github.com>

This is a clone of https://github.com/openjdk/jdk/pull/25950 that we need to get integrated ASAP.

---

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.

---

I'm re-testing with tiers 1-4

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

Commit messages:
 - Merge branch 'master' into 8360048-nmt
 - 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/26284/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26284&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8360048
  Stats: 126 lines in 5 files changed: 20 ins; 21 del; 85 mod
  Patch: https://git.openjdk.org/jdk/pull/26284.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26284/head:pull/26284

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

From iklam at openjdk.org  Mon Jul 14 03:38:44 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 14 Jul 2025 03:38:44 GMT
Subject: RFR: 8356807: Change log_info(cds) to
 `MetaspaceShared::report_loading_error()` [v2]
In-Reply-To: <OpSwmSGO8OWtYFQPNZ1Ln9eRmiEcXGuZ6LcQ3nQl2is=.4a091226-ff3b-422d-9df8-8980afabb20c@github.com>
References: <0O1bxM4K1u4yAqJdUKntyiF8m9UGd8OeZm_hFZ8oc_c=.f8d8d27f-52be-4080-b7ef-4e253f93281e@github.com>
 <OpSwmSGO8OWtYFQPNZ1Ln9eRmiEcXGuZ6LcQ3nQl2is=.4a091226-ff3b-422d-9df8-8980afabb20c@github.com>
Message-ID: <JkwdvUX9mJLim85PQEDz65LotqqetYCwz-E27aFlZBY=.274840da-96dc-4630-8ac7-bbd0bf1943cd@github.com>

On Fri, 11 Jul 2025 23:38:53 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> The patch changes some of the `aot_log_info(aot)()` to `MetaspaceShared::report_loading_error()` for those referring to an error condition during loading of AOT cache or CDS archive.
>> 
>> Passed tiers 1 - 4 testing.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update ServiceLoaderTest.java

LGTM.
I would suggest running tiers 5 and 6 as well, as some test cases may be sensitive to the messages that are printed in the "error" level by `MetaspaceShared::report_loading_error()`

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

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26253#pullrequestreview-3014689730

From tschatzl at openjdk.org  Mon Jul 14 09:41:45 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 14 Jul 2025 09:41:45 GMT
Subject: RFR: 8361706: Parallel weak klass link cleaning does not clean out
 previous klasses
In-Reply-To: <b1dkj1MxRfSFOK7fxYvnywl-9TAS9lPc2crtNuYVgPI=.5d2ce08f-0af7-4339-a85b-5cafe1520c19@github.com>
References: <9CeeNb9Hr7qkUrLyEcA36e7q7XQLUChKvDrvTc-t29o=.c84d3081-a8a4-48d0-9e4d-0dc70467ab71@github.com>
 <b1dkj1MxRfSFOK7fxYvnywl-9TAS9lPc2crtNuYVgPI=.5d2ce08f-0af7-4339-a85b-5cafe1520c19@github.com>
Message-ID: <dUq3PrWrMSl6GPUF10OSD-qL8dQbr9xwFgUevM7pgEo=.40be9cf1-2213-4fa4-ad92-c1b1551af530@github.com>

On Fri, 11 Jul 2025 17:48:52 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Can you make InstanceKlass::clean_weak_instanceklass_links() protected? If not, this looks good.

It is required to be public right now.

Thanks @coleenp @fisk for your reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/26263#issuecomment-3068653905

From tschatzl at openjdk.org  Mon Jul 14 09:41:46 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 14 Jul 2025 09:41:46 GMT
Subject: Integrated: 8361706: Parallel weak klass link cleaning does not clean
 out previous klasses
In-Reply-To: <9CeeNb9Hr7qkUrLyEcA36e7q7XQLUChKvDrvTc-t29o=.c84d3081-a8a4-48d0-9e4d-0dc70467ab71@github.com>
References: <9CeeNb9Hr7qkUrLyEcA36e7q7XQLUChKvDrvTc-t29o=.c84d3081-a8a4-48d0-9e4d-0dc70467ab71@github.com>
Message-ID: <RwQ-oU1UeXOdF_Ra5i3FUH27EazAxpKZB4nAjaRVd6g=.24f9ba20-6401-4fdf-a203-f37b1efe4e51@github.com>

On Fri, 11 Jul 2025 10:38:51 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this fix to parallel weak klass link cleaning.
> 
> `KlassCleaningTask::work()` misses cleaning out previous versions of klasses (created by JVMTI class redefinition) as the regular single-threaded variant would do when calling `Klass::clean_weak_klass_links()` with `clean_live_klasses = true`.
> 
> The fix moves the cleaning of weak klass links for previous versions of the klass into `InstanceKlass::clean_weak_instanceklass_links()`.
> 
> Testing: gha, tier1-5, many runs of `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java`(with JDK-8361952 also out for review)
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 99c299f0
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/99c299f0985c8be63b9b60e589db520d83fd8033
Stats:     24 lines in 4 files changed: 12 ins; 10 del; 2 mod

8361706: Parallel weak klass link cleaning does not clean out previous klasses

Reviewed-by: eosterlund, coleenp

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

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

From tschatzl at openjdk.org  Mon Jul 14 11:07:15 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 14 Jul 2025 11:07:15 GMT
Subject: RFR: 8362151: Remove unnecessary ClassLoaderDataGraph friend classes
Message-ID: <bpPJXLhvyBUnM6BPzO_IV_l9O2VcD9V36BSxFeFYAxA=.8d0bb0ac-c630-4042-b6ce-a52ab8c05524@github.com>

Hi all,

  please review this trivial removal of some obsolete code related to friend declarations of deleted classes.

Testing: gha

Thanks,
  Thomas

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

Commit messages:
 - 8362151

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

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

From ayang at openjdk.org  Mon Jul 14 11:44:16 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 14 Jul 2025 11:44:16 GMT
Subject: RFR: 8362162: Use bool for caller of
 os::must_commit_stack_guard_pages()
Message-ID: <4bxvl6_HXRKf3yBxj93ZCCHBxf10_7cBT89uRnjN6g0=.a276c9a6-448a-4c60-b9f9-e555a542f6e8@github.com>

Trivial changing to use `bool` for boolean value.

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

Commit messages:
 - bool-trivial

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

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

From shade at openjdk.org  Mon Jul 14 12:56:52 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 14 Jul 2025 12:56:52 GMT
Subject: RFR: 8362162: Use bool for caller of
 os::must_commit_stack_guard_pages()
In-Reply-To: <4bxvl6_HXRKf3yBxj93ZCCHBxf10_7cBT89uRnjN6g0=.a276c9a6-448a-4c60-b9f9-e555a542f6e8@github.com>
References: <4bxvl6_HXRKf3yBxj93ZCCHBxf10_7cBT89uRnjN6g0=.a276c9a6-448a-4c60-b9f9-e555a542f6e8@github.com>
Message-ID: <jctZEi_cqRZ2DhiNQ_7FpALbodaw4LlFzPiRedRSr8M=.f0f6b33f-3823-46b8-8820-267fde57675f@github.com>

On Mon, 14 Jul 2025 11:38:13 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial changing to use `bool` for boolean value.

Right. Looks good and trivial.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26291#pullrequestreview-3016272518

From shade at openjdk.org  Mon Jul 14 15:07:42 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 14 Jul 2025 15:07:42 GMT
Subject: RFR: 8360048: NMT crash in gtest/NMTGtests.java: fatal error: NMT
 corruption: Block at 0x0000017748307120: header canary broken
In-Reply-To: <gUIff3tC7KO9caTbRleaxcqvTLekIpCVqMu2Gbey19U=.9182d797-acee-4596-8bb6-3d36397c31c7@github.com>
References: <gUIff3tC7KO9caTbRleaxcqvTLekIpCVqMu2Gbey19U=.9182d797-acee-4596-8bb6-3d36397c31c7@github.com>
Message-ID: <c_a-LPLK8yrESNibokoeG6_RwGWRZkza5qawt-JD9gs=.9335e64b-421d-4495-8556-5e7137f08a74@github.com>

On Mon, 14 Jul 2025 02:53:53 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This is a clone of https://github.com/openjdk/jdk/pull/25950 that we need to get integrated ASAP.
> 
> ---
> 
> 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.
> 
> ---
> 
> I'm re-testing with tiers 1-4

Are you accepting nits here? I see other PR was already reviewed.

Really hard to understand where the fix is. Bug synopsis also does not help :) I assume the problem is really in the test?

src/hotspot/share/nmt/virtualMemoryTracker.cpp line 244:

> 242:   address bottom = rmr->base();
> 243:   address top = rmr->end();
> 244:     tree()->visit_committed_regions(*rmr, [&](CommittedMemoryRegion& crgn) {

Looks like this is a correct indent:

Suggestion:

  tree()->visit_committed_regions(*rmr, [&](CommittedMemoryRegion& crgn) {

test/hotspot/gtest/runtime/test_virtualMemoryTracker.cpp line 132:

> 130:       rtree->commit_region(addr + 2 * cs, cs, stack);
> 131:       R r[] = { {addr, 3 * cs} };
> 132:       check(vmt,rmr, r);

Suggestion:

      check(vmt, rmr, r);

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

PR Review: https://git.openjdk.org/jdk/pull/26284#pullrequestreview-3016672212
PR Review Comment: https://git.openjdk.org/jdk/pull/26284#discussion_r2205132744
PR Review Comment: https://git.openjdk.org/jdk/pull/26284#discussion_r2205134570

From coleenp at openjdk.org  Mon Jul 14 15:12:39 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 14 Jul 2025 15:12:39 GMT
Subject: RFR: 8362151: Remove unnecessary ClassLoaderDataGraph friend
 classes
In-Reply-To: <bpPJXLhvyBUnM6BPzO_IV_l9O2VcD9V36BSxFeFYAxA=.8d0bb0ac-c630-4042-b6ce-a52ab8c05524@github.com>
References: <bpPJXLhvyBUnM6BPzO_IV_l9O2VcD9V36BSxFeFYAxA=.8d0bb0ac-c630-4042-b6ce-a52ab8c05524@github.com>
Message-ID: <t_YHUXuNWf9LxSTGv4afW_DOzZSJ9aj8YHjsxtwIUNw=.50b0747c-8c78-416a-8064-9df53de613ad@github.com>

On Mon, 14 Jul 2025 11:02:27 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this trivial removal of some obsolete code related to friend declarations of deleted classes.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

Looks good, looks trivial.  Thanks for cleaning this up.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26290#pullrequestreview-3016745901

From shade at openjdk.org  Mon Jul 14 16:47:43 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 14 Jul 2025 16:47:43 GMT
Subject: RFR: 8362151: Remove unnecessary ClassLoaderDataGraph friend
 classes
In-Reply-To: <bpPJXLhvyBUnM6BPzO_IV_l9O2VcD9V36BSxFeFYAxA=.8d0bb0ac-c630-4042-b6ce-a52ab8c05524@github.com>
References: <bpPJXLhvyBUnM6BPzO_IV_l9O2VcD9V36BSxFeFYAxA=.8d0bb0ac-c630-4042-b6ce-a52ab8c05524@github.com>
Message-ID: <Dvrj7OLzuoo0NXmMZ01XRwvy_0IeitD1TP7pHTbvsP8=.d10a2db8-8d06-4363-8752-888ef7005524@github.com>

On Mon, 14 Jul 2025 11:02:27 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this trivial removal of some obsolete code related to friend declarations of deleted classes.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26290#pullrequestreview-3017047698

From lmesnik at openjdk.org  Mon Jul 14 17:58:40 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 14 Jul 2025 17:58:40 GMT
Subject: RFR: 8358004: Delete applications/scimark/Scimark.java test
In-Reply-To: <_o6ne7B1-A7nSOva7Zns8IMv7rw0Ve4xTwqiSajNzcA=.755977c7-4376-415c-9f76-5acae9f12b5a@github.com>
References: <_o6ne7B1-A7nSOva7Zns8IMv7rw0Ve4xTwqiSajNzcA=.755977c7-4376-415c-9f76-5acae9f12b5a@github.com>
Message-ID: <qWzZIrbgSewZGqws1NFnY88b76jpDqb-QfNHDJyPwBk=.69e511eb-2206-45a9-89c5-5c432bd475eb@github.com>

On Tue, 20 May 2025 02:55:44 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Test 
> scimark has a bug, described in the https://bugs.openjdk.org/browse/JDK-8315797
> that causes test failure.
> 
> The Scimark is not maintained. The main goal of test was to provide example of Artifact-based test with 3rd party binary. There are a couple of other tests using Artifactory. So this test is completely useless now. 
> I am removing it just to avoid spending time for anyone who can run test and observe this failure.

ping

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

PR Comment: https://git.openjdk.org/jdk/pull/25316#issuecomment-3070458885

From coleenp at openjdk.org  Mon Jul 14 19:49:39 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 14 Jul 2025 19:49:39 GMT
Subject: RFR: 8358004: Delete applications/scimark/Scimark.java test
In-Reply-To: <_o6ne7B1-A7nSOva7Zns8IMv7rw0Ve4xTwqiSajNzcA=.755977c7-4376-415c-9f76-5acae9f12b5a@github.com>
References: <_o6ne7B1-A7nSOva7Zns8IMv7rw0Ve4xTwqiSajNzcA=.755977c7-4376-415c-9f76-5acae9f12b5a@github.com>
Message-ID: <VSuaNfGYSzgbO0keged87fN9sULvgHtSLc0i31IhcFY=.04b9d1b3-aa9c-457b-a267-2ee94124040f@github.com>

On Tue, 20 May 2025 02:55:44 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Test 
> scimark has a bug, described in the https://bugs.openjdk.org/browse/JDK-8315797
> that causes test failure.
> 
> The Scimark is not maintained. The main goal of test was to provide example of Artifact-based test with 3rd party binary. There are a couple of other tests using Artifactory. So this test is completely useless now. 
> I am removing it just to avoid spending time for anyone who can run test and observe this failure.

I was wondering if scimark ever found JVM bugs, but I think it's also run in the SPECjvm tests, like in bug [JDK-8352317](https://bugs.openjdk.org/browse/JDK-8352317). But this doesn't need Scimark.java.  Is this right?

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

PR Review: https://git.openjdk.org/jdk/pull/25316#pullrequestreview-3017560379

From dholmes at openjdk.org  Mon Jul 14 20:56:16 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 14 Jul 2025 20:56:16 GMT
Subject: RFR: 8360048: NMT crash in gtest/NMTGtests.java: fatal error: NMT
 corruption: Block at 0x0000017748307120: header canary broken [v2]
In-Reply-To: <gUIff3tC7KO9caTbRleaxcqvTLekIpCVqMu2Gbey19U=.9182d797-acee-4596-8bb6-3d36397c31c7@github.com>
References: <gUIff3tC7KO9caTbRleaxcqvTLekIpCVqMu2Gbey19U=.9182d797-acee-4596-8bb6-3d36397c31c7@github.com>
Message-ID: <yJEDxwa52f-71mm4eVPtbHtlxRHmCbG5QwHGkZ3zrvU=.873c3938-da7a-4b4e-b1d4-1859799ac7e8@github.com>

> This is a clone of https://github.com/openjdk/jdk/pull/25950 that we need to get integrated ASAP.
> 
> ---
> 
> 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.
> 
> ---
> 
> I'm re-testing with tiers 1-4

David Holmes has updated the pull request incrementally with two additional commits since the last revision:

 - Update test/hotspot/gtest/runtime/test_virtualMemoryTracker.cpp
   
   Co-authored-by: Aleksey Shipil?v <shipilev at amazon.de>
 - Update src/hotspot/share/nmt/virtualMemoryTracker.cpp
   
   Co-authored-by: Aleksey Shipil?v <shipilev at amazon.de>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26284/files
  - new: https://git.openjdk.org/jdk/pull/26284/files/a07a5c1b..faa38c29

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

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

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

From dholmes at openjdk.org  Mon Jul 14 20:58:38 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 14 Jul 2025 20:58:38 GMT
Subject: RFR: 8360048: NMT crash in gtest/NMTGtests.java: fatal error: NMT
 corruption: Block at 0x0000017748307120: header canary broken [v2]
In-Reply-To: <c_a-LPLK8yrESNibokoeG6_RwGWRZkza5qawt-JD9gs=.9335e64b-421d-4495-8556-5e7137f08a74@github.com>
References: <gUIff3tC7KO9caTbRleaxcqvTLekIpCVqMu2Gbey19U=.9182d797-acee-4596-8bb6-3d36397c31c7@github.com>
 <c_a-LPLK8yrESNibokoeG6_RwGWRZkza5qawt-JD9gs=.9335e64b-421d-4495-8556-5e7137f08a74@github.com>
Message-ID: <xUVWduaS3maSSvIhGzeukd9h2Uv5W1mPlZn3s8pC5HQ=.22119675-4782-4d26-a3f5-d3772a4caecd@github.com>

On Mon, 14 Jul 2025 15:04:47 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Are you accepting nits here? I see other PR was already reviewed.

The intent was to just create a proxy for the other PR so we could hit the integrate button. But that hasn't happened yet so nits accepted.

> Really hard to understand where the fix is. Bug synopsis also does not help :) I assume the problem is really in the test?

I have similar thoughts and am asking for some clarification from Gerard (as original reviewer).

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

PR Comment: https://git.openjdk.org/jdk/pull/26284#issuecomment-3070958149

From lmesnik at openjdk.org  Mon Jul 14 21:29:44 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 14 Jul 2025 21:29:44 GMT
Subject: RFR: 8358004: Delete applications/scimark/Scimark.java test
In-Reply-To: <_o6ne7B1-A7nSOva7Zns8IMv7rw0Ve4xTwqiSajNzcA=.755977c7-4376-415c-9f76-5acae9f12b5a@github.com>
References: <_o6ne7B1-A7nSOva7Zns8IMv7rw0Ve4xTwqiSajNzcA=.755977c7-4376-415c-9f76-5acae9f12b5a@github.com>
Message-ID: <BxoobONIku6_Zs9ocsh3wvAAZrD7_X5T5zsCed6CxBk=.e0015949-a5fd-47e7-8c50-811931f1be9d@github.com>

On Tue, 20 May 2025 02:55:44 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Test 
> scimark has a bug, described in the https://bugs.openjdk.org/browse/JDK-8315797
> that causes test failure.
> 
> The Scimark is not maintained. The main goal of test was to provide example of Artifact-based test with 3rd party binary. There are a couple of other tests using Artifactory. So this test is completely useless now. 
> I am removing it just to avoid spending time for anyone who can run test and observe this failure.

the scimark has never been found any issues, it was needed as an example af aritfactory usage in openjdk
The problem is that scimark itself has a a bug that can lead to test failures.

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

PR Comment: https://git.openjdk.org/jdk/pull/25316#issuecomment-3071040360

From gziemski at openjdk.org  Mon Jul 14 22:20:38 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Mon, 14 Jul 2025 22:20:38 GMT
Subject: RFR: 8360048: NMT crash in gtest/NMTGtests.java: fatal error: NMT
 corruption: Block at 0x0000017748307120: header canary broken [v2]
In-Reply-To: <yJEDxwa52f-71mm4eVPtbHtlxRHmCbG5QwHGkZ3zrvU=.873c3938-da7a-4b4e-b1d4-1859799ac7e8@github.com>
References: <gUIff3tC7KO9caTbRleaxcqvTLekIpCVqMu2Gbey19U=.9182d797-acee-4596-8bb6-3d36397c31c7@github.com>
 <yJEDxwa52f-71mm4eVPtbHtlxRHmCbG5QwHGkZ3zrvU=.873c3938-da7a-4b4e-b1d4-1859799ac7e8@github.com>
Message-ID: <DTujjcFU4qMovcE2aMWCLJIDIelnd_KtsFXjsR1Sprs=.be562840-dc78-4373-9031-ca1e159c9454@github.com>

On Mon, 14 Jul 2025 20:56:16 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This is a clone of https://github.com/openjdk/jdk/pull/25950 that we need to get integrated ASAP.
>> 
>> ---
>> 
>> 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.
>> 
>> ---
>> 
>> I'm re-testing with tiers 1-4
>
> David Holmes has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update test/hotspot/gtest/runtime/test_virtualMemoryTracker.cpp
>    
>    Co-authored-by: Aleksey Shipil?v <shipilev at amazon.de>
>  - Update src/hotspot/share/nmt/virtualMemoryTracker.cpp
>    
>    Co-authored-by: Aleksey Shipil?v <shipilev at amazon.de>

Wishing that we did not include all the tangential work in the original fix...

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

Marked as reviewed by gziemski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26284#pullrequestreview-3017974633

From gziemski at openjdk.org  Mon Jul 14 22:20:39 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Mon, 14 Jul 2025 22:20:39 GMT
Subject: RFR: 8360048: NMT crash in gtest/NMTGtests.java: fatal error: NMT
 corruption: Block at 0x0000017748307120: header canary broken [v2]
In-Reply-To: <xUVWduaS3maSSvIhGzeukd9h2Uv5W1mPlZn3s8pC5HQ=.22119675-4782-4d26-a3f5-d3772a4caecd@github.com>
References: <gUIff3tC7KO9caTbRleaxcqvTLekIpCVqMu2Gbey19U=.9182d797-acee-4596-8bb6-3d36397c31c7@github.com>
 <c_a-LPLK8yrESNibokoeG6_RwGWRZkza5qawt-JD9gs=.9335e64b-421d-4495-8556-5e7137f08a74@github.com>
 <xUVWduaS3maSSvIhGzeukd9h2Uv5W1mPlZn3s8pC5HQ=.22119675-4782-4d26-a3f5-d3772a4caecd@github.com>
Message-ID: <EitgPlCZSEdogPTYxwT8uJTxjujWUwi7GFSfuuS_30Q=.0ecafcad-13b3-4121-b7bf-41aca882391e@github.com>

On Mon, 14 Jul 2025 20:56:08 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Really hard to understand where the fix is. Bug synopsis also does not help :) I assume the problem is really in the test?

Agree, it's confusing, Afshin said:

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

but frankly I don't see any locks involved in this code path:

This where we detect the issue:


inline OutTypeParam MallocHeader::resolve_checked_impl(InTypeParam memblock) {
  char msg[256];
  address corruption = nullptr;
  if (!is_valid_malloced_pointer(memblock, msg, sizeof(msg))) {
    fatal("Not a valid malloc pointer: " PTR_FORMAT ": %s", p2i(memblock), msg);
  }
  OutTypeParam header_pointer = (OutTypeParam)memblock - 1;
  if (!header_pointer->check_block_integrity(msg, sizeof(msg), &corruption)) {
    header_pointer->print_block_on_error(tty, corruption != nullptr ? corruption : (address)header_pointer);
    fatal("NMT corruption: Block at " PTR_FORMAT ": %s", p2i(memblock), msg);
  }
  return header_pointer;
}


called by:


inline MallocHeader* MallocHeader::resolve_checked(void* memblock) {
  return MallocHeader::resolve_checked_impl<void*, MallocHeader*>(memblock);
}


called by:


void* MallocTracker::record_free_block(void* memblock) {
...
  MallocHeader* header = MallocHeader::resolve_checked(memblock);
...
}


called by:


static inline void* record_free(void* memblock) {
...
    return MallocTracker::record_free_block(memblock);
}


called by:


void  os::free(void *memblock) {
...
  permit_forbidden_function::free(old_outer_ptr);
}


called by:


  void Treap::remove_all() {
...
      _allocator.free(head);
...
  }


called by:


  static void test_add_committed_region_adjacent_overlapping() {
    RegionsTree* rtree = VirtualMemoryTracker::Instance::tree();
    rtree->tree().remove_all();

    size_t size  = 0x01000000;
    ReservedSpace rs = MemoryReserver::reserve(size, mtTest);
    MemTracker::NmtVirtualMemoryLocker nvml;
...


As you can see in the old code, we call `remove_all` before we lock (MemTracker::NmtVirtualMemoryLocker)

I think the simplest temp fix here would be to do:


  static void test_add_committed_region_adjacent_overlapping() {
    MemTracker::NmtVirtualMemoryLocker nvml;

    RegionsTree* rtree = VirtualMemoryTracker::Instance::tree();
    rtree->tree().remove_all();

    size_t size  = 0x01000000;
    ReservedSpace rs = MemoryReserver::reserve(size, mtTest);


In the new code we don't call `remove_all()`

Afshin original fix incorporated feedback, not directly applicable to this fix, and now I wish we went with a simple fix and left other enhancements for later. Live and learn...

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

PR Comment: https://git.openjdk.org/jdk/pull/26284#issuecomment-3071197578

From dholmes at openjdk.org  Mon Jul 14 22:33:49 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 14 Jul 2025 22:33:49 GMT
Subject: RFR: 8356941: AbstractMethodError in HotSpot Due to Incorrect Handling
 of Private Method
Message-ID: <qyWNTs0IOlf128C4ZdvOp9TE7O4w7bPaz2hJfHseIUk=.4a298588-6aff-471a-927b-beb3c9f0b194@github.com>

Private methods should never be considered as the implementation of a default method.

The first commit adds some additional logging I used to track down what was happening. I like it, but if reviewers think it too much I can drop it.

The second commit is the actual fix to exclude private methods, and adds the missing test case to the existing defmeth tests.

Testing:
 - tiers 1-4

Thanks

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

Commit messages:
 - Merge branch 'master' into 8356941-defaultmeth
 - Fix bug and add new testcases
 - Additional logging to identify the problem

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

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

From iklam at openjdk.org  Mon Jul 14 22:39:40 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 14 Jul 2025 22:39:40 GMT
Subject: RFR: 8356942:
 =?UTF-8?B?aW52b2tlaW50ZXJmYWNlwqBUaHJvd3PCoEFic3RyYWN0TWV0aG9kRXJyb3LCoEluc3RlYWQ=?=
 =?UTF-8?B?IA==?= =?UTF-8?B?b2bCoEluY29tcGF0aWJsZUNsYXNzQ2hhbmdlRXJyb3I=?= [v3]
In-Reply-To: <S8h6abDBVIYEXswCi8IRPCFvaBbX5-ZE6WbfeFMJ2NE=.e9e9baba-6563-4403-a2c0-a7235dc13a3b@github.com>
References: <8Dh9B06hDuORGQ-uufrbswlGw9ABFFCA62sCJSUnJaY=.6498b7e8-a39b-43f0-a76f-a0ed9aea3905@github.com>
 <S8h6abDBVIYEXswCi8IRPCFvaBbX5-ZE6WbfeFMJ2NE=.e9e9baba-6563-4403-a2c0-a7235dc13a3b@github.com>
Message-ID: <MenQZS-xUNAiy4Tp62bA25wm1esPHUl8xmLQOP8JjLk=.e831b960-33d9-429b-86db-111896a8884a@github.com>

On Tue, 8 Jul 2025 21:25:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> In [JDK-8186092](https://bugs.openjdk.org/browse/JDK-8186092) (way back in JDK 10) we elided loader constraint checks for overpass methods related to default methods by skipping them when initializing the itable for the interface. But that was the wrong place to do that. The overpass method is setup when there is a resolution/selection error so that the correct exception is thrown if the problematic method is invoked (like the ICCE reporting conflicting methods) and by eliding that entry we instead get the `AbstractMethhodError`.
>> 
>> The fix here is to revert that change from [JDK-8186092](https://bugs.openjdk.org/browse/JDK-8186092), and to address the loader constraint problem by adding the same check for overpass methods in `klassItable::check_constraints` that exists for `klassVtable::check_constraints`.
>> 
>> Testing:
>>  - modified existing regression test
>>  - tiers 1-4
>> 
>> EDIT: originally there was a new regression test for this, but this area is already covered by the `vmTestBase` "`defmeth` tests. That test was missing the necessary invocation modes to expose the bug, so they have been added.
>> 
>> Thanks
>> 
>> PS. The diff is much smaller if you disable whitespace differences.
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix weird logic - requested by Coleen

The changes look reasonable to me.

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

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26122#pullrequestreview-3017999789

From dholmes at openjdk.org  Mon Jul 14 22:39:40 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 14 Jul 2025 22:39:40 GMT
Subject: RFR: 8356942:
 =?UTF-8?B?aW52b2tlaW50ZXJmYWNlwqBUaHJvd3PCoEFic3RyYWN0TWV0aG9kRXJyb3LCoEluc3RlYWQ=?=
 =?UTF-8?B?IA==?= =?UTF-8?B?b2bCoEluY29tcGF0aWJsZUNsYXNzQ2hhbmdlRXJyb3I=?= [v3]
In-Reply-To: <59TWztBno7U4Y_y3NEHqbpcC3i7tcLVqTk0xEbQErzc=.0f79114c-d276-4a22-824a-3e3c262b925c@github.com>
References: <8Dh9B06hDuORGQ-uufrbswlGw9ABFFCA62sCJSUnJaY=.6498b7e8-a39b-43f0-a76f-a0ed9aea3905@github.com>
 <S8h6abDBVIYEXswCi8IRPCFvaBbX5-ZE6WbfeFMJ2NE=.e9e9baba-6563-4403-a2c0-a7235dc13a3b@github.com>
 <59TWztBno7U4Y_y3NEHqbpcC3i7tcLVqTk0xEbQErzc=.0f79114c-d276-4a22-824a-3e3c262b925c@github.com>
Message-ID: <qDPDff8_pLYs1-Z1ouI6APXTWo2g67OGTF_ymPwZ09E=.419636f7-c4e7-4483-8e3a-e398bd4d05e9@github.com>

On Tue, 8 Jul 2025 22:37:51 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix weird logic - requested by Coleen
>
> Looks good.

Thanks for the review @coleenp !

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

PR Comment: https://git.openjdk.org/jdk/pull/26122#issuecomment-3054992667

From dholmes at openjdk.org  Mon Jul 14 22:56:45 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 14 Jul 2025 22:56:45 GMT
Subject: RFR: 8356942:
 =?UTF-8?B?aW52b2tlaW50ZXJmYWNlwqBUaHJvd3PCoEFic3RyYWN0TWV0aG9kRXJyb3LCoEluc3RlYWQ=?=
 =?UTF-8?B?IA==?= =?UTF-8?B?b2bCoEluY29tcGF0aWJsZUNsYXNzQ2hhbmdlRXJyb3I=?= [v3]
In-Reply-To: <MenQZS-xUNAiy4Tp62bA25wm1esPHUl8xmLQOP8JjLk=.e831b960-33d9-429b-86db-111896a8884a@github.com>
References: <8Dh9B06hDuORGQ-uufrbswlGw9ABFFCA62sCJSUnJaY=.6498b7e8-a39b-43f0-a76f-a0ed9aea3905@github.com>
 <S8h6abDBVIYEXswCi8IRPCFvaBbX5-ZE6WbfeFMJ2NE=.e9e9baba-6563-4403-a2c0-a7235dc13a3b@github.com>
 <MenQZS-xUNAiy4Tp62bA25wm1esPHUl8xmLQOP8JjLk=.e831b960-33d9-429b-86db-111896a8884a@github.com>
Message-ID: <OvtXXAKX7K45s86pfmWsPJq8O_C8FiLksoGGjpmmV3s=.c2393b4e-ae66-44f7-9068-af2c5742e0c3@github.com>

On Mon, 14 Jul 2025 22:36:33 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix weird logic - requested by Coleen
>
> The changes look reasonable to me.

Thanks for the review @iklam !

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

PR Comment: https://git.openjdk.org/jdk/pull/26122#issuecomment-3071267381

From dholmes at openjdk.org  Mon Jul 14 22:56:45 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 14 Jul 2025 22:56:45 GMT
Subject: Integrated: 8356942:
 =?UTF-8?B?aW52b2tlaW50ZXJmYWNlwqBUaHJvd3PCoEFic3RyYWN0TWV0aG9kRXJyb3LCoEluc3RlYWQ=?=
 =?UTF-8?B?IA==?= =?UTF-8?B?b2bCoEluY29tcGF0aWJsZUNsYXNzQ2hhbmdlRXJyb3I=?=
In-Reply-To: <8Dh9B06hDuORGQ-uufrbswlGw9ABFFCA62sCJSUnJaY=.6498b7e8-a39b-43f0-a76f-a0ed9aea3905@github.com>
References: <8Dh9B06hDuORGQ-uufrbswlGw9ABFFCA62sCJSUnJaY=.6498b7e8-a39b-43f0-a76f-a0ed9aea3905@github.com>
Message-ID: <Gm2z_rBIPlUUJgbPkdf82_vyFEk5VOIbG-yak87OLKo=.403e3189-f7e3-4270-9583-d14285e2f6a0@github.com>

On Thu, 3 Jul 2025 22:11:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

> In [JDK-8186092](https://bugs.openjdk.org/browse/JDK-8186092) (way back in JDK 10) we elided loader constraint checks for overpass methods related to default methods by skipping them when initializing the itable for the interface. But that was the wrong place to do that. The overpass method is setup when there is a resolution/selection error so that the correct exception is thrown if the problematic method is invoked (like the ICCE reporting conflicting methods) and by eliding that entry we instead get the `AbstractMethhodError`.
> 
> The fix here is to revert that change from [JDK-8186092](https://bugs.openjdk.org/browse/JDK-8186092), and to address the loader constraint problem by adding the same check for overpass methods in `klassItable::check_constraints` that exists for `klassVtable::check_constraints`.
> 
> Testing:
>  - modified existing regression test
>  - tiers 1-4
> 
> EDIT: originally there was a new regression test for this, but this area is already covered by the `vmTestBase` "`defmeth` tests. That test was missing the necessary invocation modes to expose the bug, so they have been added.
> 
> Thanks
> 
> PS. The diff is much smaller if you disable whitespace differences.

This pull request has now been integrated.

Changeset: f36147b3
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f36147b3263662229e9a0ec712b9748711d2d85d
Stats:     71 lines in 2 files changed: 12 ins; 2 del; 57 mod

8356942: invokeinterface?Throws?AbstractMethodError?Instead of?IncompatibleClassChangeError

Reviewed-by: coleenp, iklam

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

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

From dholmes at openjdk.org  Tue Jul 15 00:52:54 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 15 Jul 2025 00:52:54 GMT
Subject: RFR: 8356941: AbstractMethodError in HotSpot Due to Incorrect
 Handling of Private Method [v2]
In-Reply-To: <qyWNTs0IOlf128C4ZdvOp9TE7O4w7bPaz2hJfHseIUk=.4a298588-6aff-471a-927b-beb3c9f0b194@github.com>
References: <qyWNTs0IOlf128C4ZdvOp9TE7O4w7bPaz2hJfHseIUk=.4a298588-6aff-471a-927b-beb3c9f0b194@github.com>
Message-ID: <nWFZw1gF1fWToINRFmJOExarreQRkUba1Qm0Ho6y7RQ=.65917004-c8d2-4943-862c-66f0aec9ce5f@github.com>

> Private methods should never be considered as the implementation of a default method.
> 
> The first commit adds some additional logging I used to track down what was happening. I like it, but if reviewers think it too much I can drop it.
> 
> The second commit is the actual fix to exclude private methods, and adds the missing test case to the existing defmeth tests.
> 
> Testing:
>  - tiers 1-4
> 
> Thanks

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

 - Merge branch 'master' into 8356941-defaultmeth
 - Merge branch 'master' into 8356941-defaultmeth
 - Fix bug and add new testcases
 - Additional logging to identify the problem

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26302/files
  - new: https://git.openjdk.org/jdk/pull/26302/files/784d307e..b839daa1

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

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

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

From kbarrett at openjdk.org  Tue Jul 15 01:34:44 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 15 Jul 2025 01:34:44 GMT
Subject: RFR: 8362162: Use bool for caller of
 os::must_commit_stack_guard_pages()
In-Reply-To: <4bxvl6_HXRKf3yBxj93ZCCHBxf10_7cBT89uRnjN6g0=.a276c9a6-448a-4c60-b9f9-e555a542f6e8@github.com>
References: <4bxvl6_HXRKf3yBxj93ZCCHBxf10_7cBT89uRnjN6g0=.a276c9a6-448a-4c60-b9f9-e555a542f6e8@github.com>
Message-ID: <joc1EspWUyyqw5364u-tzA6983ETpMQWj0DpmQ3b5Ic=.943b4b09-2b7c-48ea-a215-045b43a05b15@github.com>

On Mon, 14 Jul 2025 11:38:13 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial changing to use `bool` for boolean value.

Looks good, and trivial.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26291#pullrequestreview-3018239348

From duke at openjdk.org  Tue Jul 15 01:54:44 2025
From: duke at openjdk.org (duke)
Date: Tue, 15 Jul 2025 01:54:44 GMT
Subject: Withdrawn: 8357244: Move class declarations from
 attachListener_posix.cpp to header files
In-Reply-To: <6ParCD1eqRHVog8e3KB_kqWt6TJ3PoOWg5G5f21XZzs=.cd62ab5e-c040-4d06-b083-363e315f933a@github.com>
References: <6ParCD1eqRHVog8e3KB_kqWt6TJ3PoOWg5G5f21XZzs=.cd62ab5e-c040-4d06-b083-363e315f933a@github.com>
Message-ID: <9TfLZJNMQD4UIs70levH5iHC_2QMR9Sprz1X7-AVOTI=.9d7a7ff6-3a08-4f84-ae66-b999fdc5d866@github.com>

On Mon, 19 May 2025 11:09:43 GMT, Dmitry Cherepanov <dcherepanov at openjdk.org> wrote:

> The patch suggests moving class declarations from `attachListener_posix.cpp` to header files
> 
> It's moved in `openjdk/crac` project ahead of upstream and this causes merge conflicts every time attachListener code changes (e.g. https://github.com/openjdk/crac/pull/224). It's therefore suggested that the changes are included in upstream.

This pull request has been closed without being integrated.

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

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

From ccheung at openjdk.org  Tue Jul 15 04:24:56 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 15 Jul 2025 04:24:56 GMT
Subject: RFR: 8356807: Change log_info(cds) to
 `MetaspaceShared::report_loading_error()` [v3]
In-Reply-To: <0O1bxM4K1u4yAqJdUKntyiF8m9UGd8OeZm_hFZ8oc_c=.f8d8d27f-52be-4080-b7ef-4e253f93281e@github.com>
References: <0O1bxM4K1u4yAqJdUKntyiF8m9UGd8OeZm_hFZ8oc_c=.f8d8d27f-52be-4080-b7ef-4e253f93281e@github.com>
Message-ID: <VKDHtC6KoO1vhrgonhvXIE0Cmlp-oMhYv0pv2bGduYY=.43bbaf91-4b63-4d3d-8bb2-3365d97f3a90@github.com>

> The patch changes some of the `aot_log_info(aot)()` to `MetaspaceShared::report_loading_error()` for those referring to an error condition during loading of AOT cache or CDS archive.
> 
> Passed tiers 1 - 4 testing.

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

  update ArchivedModuleWithCustomImageTest.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26253/files
  - new: https://git.openjdk.org/jdk/pull/26253/files/c85ff4ee..1b55f8a4

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

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

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

From ccheung at openjdk.org  Tue Jul 15 04:24:56 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 15 Jul 2025 04:24:56 GMT
Subject: RFR: 8356807: Change log_info(cds) to
 `MetaspaceShared::report_loading_error()` [v2]
In-Reply-To: <OpSwmSGO8OWtYFQPNZ1Ln9eRmiEcXGuZ6LcQ3nQl2is=.4a091226-ff3b-422d-9df8-8980afabb20c@github.com>
References: <0O1bxM4K1u4yAqJdUKntyiF8m9UGd8OeZm_hFZ8oc_c=.f8d8d27f-52be-4080-b7ef-4e253f93281e@github.com>
 <OpSwmSGO8OWtYFQPNZ1Ln9eRmiEcXGuZ6LcQ3nQl2is=.4a091226-ff3b-422d-9df8-8980afabb20c@github.com>
Message-ID: <BjgjG9odmSTDcoUTx9dYQZlYlL9PyGVFZByVDc0D20A=.c8e2032c-bd05-4f4c-a221-438265c81195@github.com>

On Fri, 11 Jul 2025 23:38:53 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> The patch changes some of the `aot_log_info(aot)()` to `MetaspaceShared::report_loading_error()` for those referring to an error condition during loading of AOT cache or CDS archive.
>> 
>> Passed tiers 1 - 4 testing.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update ServiceLoaderTest.java

I noticed one test failure in tier5. Updated the `ArchiveModuleWithCustomImageTest.java` test.

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

PR Comment: https://git.openjdk.org/jdk/pull/26253#issuecomment-3071837518

From iklam at openjdk.org  Tue Jul 15 05:41:39 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 15 Jul 2025 05:41:39 GMT
Subject: RFR: 8356807: Change log_info(cds) to
 `MetaspaceShared::report_loading_error()` [v3]
In-Reply-To: <VKDHtC6KoO1vhrgonhvXIE0Cmlp-oMhYv0pv2bGduYY=.43bbaf91-4b63-4d3d-8bb2-3365d97f3a90@github.com>
References: <0O1bxM4K1u4yAqJdUKntyiF8m9UGd8OeZm_hFZ8oc_c=.f8d8d27f-52be-4080-b7ef-4e253f93281e@github.com>
 <VKDHtC6KoO1vhrgonhvXIE0Cmlp-oMhYv0pv2bGduYY=.43bbaf91-4b63-4d3d-8bb2-3365d97f3a90@github.com>
Message-ID: <08EdRKGLTpvjWR7Hz5zppZZCHshcqsQiIvlOwWgLC6A=.2930ccc9-9e62-4123-ab4c-0d9d16bd82ff@github.com>

On Tue, 15 Jul 2025 04:24:56 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> The patch changes some of the `aot_log_info(aot)()` to `MetaspaceShared::report_loading_error()` for those referring to an error condition during loading of AOT cache or CDS archive.
>> 
>> Passed tiers 1 - 4 testing.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update ArchivedModuleWithCustomImageTest.java

Marked as reviewed by iklam (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26253#pullrequestreview-3018735425

From ayang at openjdk.org  Tue Jul 15 07:54:43 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 15 Jul 2025 07:54:43 GMT
Subject: RFR: 8362162: Use bool for caller of
 os::must_commit_stack_guard_pages()
In-Reply-To: <4bxvl6_HXRKf3yBxj93ZCCHBxf10_7cBT89uRnjN6g0=.a276c9a6-448a-4c60-b9f9-e555a542f6e8@github.com>
References: <4bxvl6_HXRKf3yBxj93ZCCHBxf10_7cBT89uRnjN6g0=.a276c9a6-448a-4c60-b9f9-e555a542f6e8@github.com>
Message-ID: <G4LtxpFldZEGbc5v1-59ZRJENM33jaGFZ563f5M7EUU=.e2494d52-ee10-4ce2-87f0-53a7d95963c8@github.com>

On Mon, 14 Jul 2025 11:38:13 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial changing to use `bool` for boolean value.

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/26291#issuecomment-3072496217

From ayang at openjdk.org  Tue Jul 15 07:54:44 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 15 Jul 2025 07:54:44 GMT
Subject: Integrated: 8362162: Use bool for caller of
 os::must_commit_stack_guard_pages()
In-Reply-To: <4bxvl6_HXRKf3yBxj93ZCCHBxf10_7cBT89uRnjN6g0=.a276c9a6-448a-4c60-b9f9-e555a542f6e8@github.com>
References: <4bxvl6_HXRKf3yBxj93ZCCHBxf10_7cBT89uRnjN6g0=.a276c9a6-448a-4c60-b9f9-e555a542f6e8@github.com>
Message-ID: <jI26UrnnSkn6t2ymFZo5Yu1qSIyDsrgOtupgYupf6aU=.88299be3-0d46-4c10-ad17-356ffed5f1b9@github.com>

On Mon, 14 Jul 2025 11:38:13 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial changing to use `bool` for boolean value.

This pull request has now been integrated.

Changeset: c9ecc826
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c9ecc826668575678f11578a67f125d430ebffad
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8362162: Use bool for caller of os::must_commit_stack_guard_pages()

Reviewed-by: shade, kbarrett

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

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

From shade at openjdk.org  Tue Jul 15 08:31:47 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 15 Jul 2025 08:31:47 GMT
Subject: RFR: 8360048: NMT crash in gtest/NMTGtests.java: fatal error: NMT
 corruption: Block at 0x0000017748307120: header canary broken [v2]
In-Reply-To: <yJEDxwa52f-71mm4eVPtbHtlxRHmCbG5QwHGkZ3zrvU=.873c3938-da7a-4b4e-b1d4-1859799ac7e8@github.com>
References: <gUIff3tC7KO9caTbRleaxcqvTLekIpCVqMu2Gbey19U=.9182d797-acee-4596-8bb6-3d36397c31c7@github.com>
 <yJEDxwa52f-71mm4eVPtbHtlxRHmCbG5QwHGkZ3zrvU=.873c3938-da7a-4b4e-b1d4-1859799ac7e8@github.com>
Message-ID: <Z3BltYxT0nyWaSyukZcGtlQcZ9Wmb3qbiNlS4k-FMso=.3244baeb-f806-482c-8b1b-62ef6fcf8c69@github.com>

On Mon, 14 Jul 2025 20:56:16 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This is a clone of https://github.com/openjdk/jdk/pull/25950 that we need to get integrated ASAP.
>> 
>> ---
>> 
>> 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.
>> 
>> ---
>> 
>> I'm re-testing with tiers 1-4
>
> David Holmes has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update test/hotspot/gtest/runtime/test_virtualMemoryTracker.cpp
>    
>    Co-authored-by: Aleksey Shipil?v <shipilev at amazon.de>
>  - Update src/hotspot/share/nmt/virtualMemoryTracker.cpp
>    
>    Co-authored-by: Aleksey Shipil?v <shipilev at amazon.de>

So replacing the uses of (sigleton, shared) `VirtualMemoryTracker::Instance` with local `VirtualMemoryTracker vmt(true);` dodges the locking issue, right?

What confuses me in this patch is why are we doing replacements like:


-  site->commit_memory(rgn->committed_size());
+  site->commit_memory(VirtualMemoryTracker::Instance::committed_size(rgn));


Doesn't that introduce dependencies on that singleton instance? Can you confirm that is sane?

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

PR Review: https://git.openjdk.org/jdk/pull/26284#pullrequestreview-3019298822

From tschatzl at openjdk.org  Tue Jul 15 09:06:45 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 15 Jul 2025 09:06:45 GMT
Subject: RFR: 8362151: Remove unnecessary ClassLoaderDataGraph friend
 classes
In-Reply-To: <t_YHUXuNWf9LxSTGv4afW_DOzZSJ9aj8YHjsxtwIUNw=.50b0747c-8c78-416a-8064-9df53de613ad@github.com>
References: <bpPJXLhvyBUnM6BPzO_IV_l9O2VcD9V36BSxFeFYAxA=.8d0bb0ac-c630-4042-b6ce-a52ab8c05524@github.com>
 <t_YHUXuNWf9LxSTGv4afW_DOzZSJ9aj8YHjsxtwIUNw=.50b0747c-8c78-416a-8064-9df53de613ad@github.com>
Message-ID: <ght7MMFWkgAiTzH1J6yqlh3U5ZdIeSgjkqWk-CQAxjk=.8072d6b0-3466-45fd-9ad3-333b4a180f55@github.com>

On Mon, 14 Jul 2025 15:10:01 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this trivial removal of some obsolete code related to friend declarations of deleted classes.
>> 
>> Testing: gha
>> 
>> Thanks,
>>   Thomas
>
> Looks good, looks trivial.  Thanks for cleaning this up.

Thanks @coleenp @shipilev  for your reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/26290#issuecomment-3072797908

From tschatzl at openjdk.org  Tue Jul 15 09:06:46 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 15 Jul 2025 09:06:46 GMT
Subject: Integrated: 8362151: Remove unnecessary ClassLoaderDataGraph friend
 classes
In-Reply-To: <bpPJXLhvyBUnM6BPzO_IV_l9O2VcD9V36BSxFeFYAxA=.8d0bb0ac-c630-4042-b6ce-a52ab8c05524@github.com>
References: <bpPJXLhvyBUnM6BPzO_IV_l9O2VcD9V36BSxFeFYAxA=.8d0bb0ac-c630-4042-b6ce-a52ab8c05524@github.com>
Message-ID: <ykGnTwrEFjYB5pkFgTsf2tocorpUVNvZr-XWF_t6X-8=.932ecb76-fc37-48ae-92f8-1f2f6526b6cc@github.com>

On Mon, 14 Jul 2025 11:02:27 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this trivial removal of some obsolete code related to friend declarations of deleted classes.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 9697e5bf
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9697e5bf74bc7d7fbdf76eed42b8de3c05d69acc
Stats:     6 lines in 2 files changed: 0 ins; 6 del; 0 mod

8362151: Remove unnecessary ClassLoaderDataGraph friend classes

Reviewed-by: coleenp, shade

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

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

From duke at openjdk.org  Tue Jul 15 10:55:52 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 15 Jul 2025 10:55:52 GMT
Subject: RFR: 8359820: SIGILL with low -XX:HandshakeTimeout
Message-ID: <FZ87bVfDootrLeANGguMFpcTm7X8AEqzuKVQspmSkmE=.4484090b-ba49-498c-bb07-71d22fd34823@github.com>

Hi, please consider the following changes:

we augment the SIGILL handling in `os::signal_thread` with proper logging so that the initial crash information goes to stdout/stderr as well. 

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.

Tested in tiers 1-3.

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

Commit messages:
 - Merge remote-tracking branch 'origin/master' into JDK-8359820-SIGILL-with-low-handshake-timeout-on-intel-sde
 - 8359820: Augmented SIGILL handling to trace handshake timeout better.

Changes: https://git.openjdk.org/jdk/pull/26309/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26309&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359820
  Stats: 4 lines in 2 files changed: 3 ins; 0 del; 1 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 coleenp at openjdk.org  Tue Jul 15 12:11:44 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 15 Jul 2025 12:11:44 GMT
Subject: RFR: 8360048: NMT crash in gtest/NMTGtests.java: fatal error: NMT
 corruption: Block at 0x0000017748307120: header canary broken [v2]
In-Reply-To: <EitgPlCZSEdogPTYxwT8uJTxjujWUwi7GFSfuuS_30Q=.0ecafcad-13b3-4121-b7bf-41aca882391e@github.com>
References: <gUIff3tC7KO9caTbRleaxcqvTLekIpCVqMu2Gbey19U=.9182d797-acee-4596-8bb6-3d36397c31c7@github.com>
 <c_a-LPLK8yrESNibokoeG6_RwGWRZkza5qawt-JD9gs=.9335e64b-421d-4495-8556-5e7137f08a74@github.com>
 <xUVWduaS3maSSvIhGzeukd9h2Uv5W1mPlZn3s8pC5HQ=.22119675-4782-4d26-a3f5-d3772a4caecd@github.com>
 <EitgPlCZSEdogPTYxwT8uJTxjujWUwi7GFSfuuS_30Q=.0ecafcad-13b3-4121-b7bf-41aca882391e@github.com>
Message-ID: <zi4J1LI-4GYydWOLNv7gqOlRKBI6FTrucKPnF7gCvEk=.fd204620-051c-48ef-a2a0-f0e2aa5ce1e8@github.com>

On Mon, 14 Jul 2025 22:16:08 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>>> Are you accepting nits here? I see other PR was already reviewed.
>> 
>> The intent was to just create a proxy for the other PR so we could hit the integrate button. But that hasn't happened yet so nits accepted.
>> 
>>> Really hard to understand where the fix is. Bug synopsis also does not help :) I assume the problem is really in the test?
>> 
>> I have similar thoughts and am asking for some clarification from Gerard (as original reviewer).
>
>> Really hard to understand where the fix is. Bug synopsis also does not help :) I assume the problem is really in the test?
> 
> Agree, it's confusing, Afshin said:
> 
>> 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.
> 
> but frankly I don't see any locks involved in this code path:
> 
> This where we detect the issue:
> 
> 
> inline OutTypeParam MallocHeader::resolve_checked_impl(InTypeParam memblock) {
>   char msg[256];
>   address corruption = nullptr;
>   if (!is_valid_malloced_pointer(memblock, msg, sizeof(msg))) {
>     fatal("Not a valid malloc pointer: " PTR_FORMAT ": %s", p2i(memblock), msg);
>   }
>   OutTypeParam header_pointer = (OutTypeParam)memblock - 1;
>   if (!header_pointer->check_block_integrity(msg, sizeof(msg), &corruption)) {
>     header_pointer->print_block_on_error(tty, corruption != nullptr ? corruption : (address)header_pointer);
>     fatal("NMT corruption: Block at " PTR_FORMAT ": %s", p2i(memblock), msg);
>   }
>   return header_pointer;
> }
> 
> 
> called by:
> 
> 
> inline MallocHeader* MallocHeader::resolve_checked(void* memblock) {
>   return MallocHeader::resolve_checked_impl<void*, MallocHeader*>(memblock);
> }
> 
> 
> called by:
> 
> 
> void* MallocTracker::record_free_block(void* memblock) {
> ...
>   MallocHeader* header = MallocHeader::resolve_checked(memblock);
> ...
> }
> 
> 
> called by:
> 
> 
> static inline void* record_free(void* memblock) {
> ...
>     return MallocTracker::record_free_block(memblock);
> }
> 
> 
> called by:
> 
> 
> void  os::free(void *memblock) {
> ...
>   void* const old_outer_ptr = MemTracker::record_free(memblock);
> ...
> }
> 
> 
> called by:
> 
> 
>   void Treap::remove_all() {
> ...
>       _allocator.free(head);
> ...
>   }
> 
> 
> called by:
> 
> 
>   static void test_add_committed_region_adjacent_overlapping() {
>     RegionsTree* rtree = VirtualMemoryTracker::Instance::tree();
>     rtree->tree().remove_all();
> 
>     size_t size  = 0x01000000;
>     ReservedSpace rs = MemoryReserver::reserve(size, mtTest);
>     MemTracker::NmtVirtualMemoryLocker nvml;
> ...
> 
> 
> As you can see in the old code, we call `remove_all` before we lock (MemTracker::NmtVirtualMemoryLocker)
> 
> I think the simplest temp fix here would be to do:
> 
> 
>   static void test_add_committed_region_adjacent_overlapping() {
>     MemTracker::NmtVirtualMemoryLocker nvml;
> 
>     RegionsTree* rtree = VirtualMemoryTracker::Instance::tree();
>     rtree->tree().remove_all();
> 
>     size_t size  = 0x01000000;
>     ReservedSpace rs = MemoryReserver::reserve(size, mtTest);
> 
> 
> In the new code we...

@gerard-ziemski  Can you prepare just the test fix for us to review?  This should be a further RFE.

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

PR Comment: https://git.openjdk.org/jdk/pull/26284#issuecomment-3073351811

From coleenp at openjdk.org  Tue Jul 15 12:13:42 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 15 Jul 2025 12:13:42 GMT
Subject: RFR: 8358004: Delete applications/scimark/Scimark.java test
In-Reply-To: <_o6ne7B1-A7nSOva7Zns8IMv7rw0Ve4xTwqiSajNzcA=.755977c7-4376-415c-9f76-5acae9f12b5a@github.com>
References: <_o6ne7B1-A7nSOva7Zns8IMv7rw0Ve4xTwqiSajNzcA=.755977c7-4376-415c-9f76-5acae9f12b5a@github.com>
Message-ID: <MNP_vi0hZXvmnPctCEW8m4R-VQfO6wcRikz0TggRhTQ=.2d64d5d1-7b96-4be9-a37a-2e35de559c9e@github.com>

On Tue, 20 May 2025 02:55:44 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Test 
> scimark has a bug, described in the https://bugs.openjdk.org/browse/JDK-8315797
> that causes test failure.
> 
> The Scimark is not maintained. The main goal of test was to provide example of Artifact-based test with 3rd party binary. There are a couple of other tests using Artifactory. So this test is completely useless now. 
> I am removing it just to avoid spending time for anyone who can run test and observe this failure.

Okay, looks good.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25316#pullrequestreview-3020022181

From gziemski at openjdk.org  Tue Jul 15 12:59:41 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 15 Jul 2025 12:59:41 GMT
Subject: RFR: 8360048: NMT crash in gtest/NMTGtests.java: fatal error: NMT
 corruption: Block at 0x0000017748307120: header canary broken [v2]
In-Reply-To: <Z3BltYxT0nyWaSyukZcGtlQcZ9Wmb3qbiNlS4k-FMso=.3244baeb-f806-482c-8b1b-62ef6fcf8c69@github.com>
References: <gUIff3tC7KO9caTbRleaxcqvTLekIpCVqMu2Gbey19U=.9182d797-acee-4596-8bb6-3d36397c31c7@github.com>
 <yJEDxwa52f-71mm4eVPtbHtlxRHmCbG5QwHGkZ3zrvU=.873c3938-da7a-4b4e-b1d4-1859799ac7e8@github.com>
 <Z3BltYxT0nyWaSyukZcGtlQcZ9Wmb3qbiNlS4k-FMso=.3244baeb-f806-482c-8b1b-62ef6fcf8c69@github.com>
Message-ID: <gDGhHvdiAvpkcH4QsshBOb50a1l6yo9KgLPj-Rhkt64=.128163b1-25da-464a-8764-5b284278aa92@github.com>

On Tue, 15 Jul 2025 08:29:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> So replacing the uses of (sigleton, shared) `VirtualMemoryTracker::Instance` with local `VirtualMemoryTracker vmt(true);` dodges the locking issue, right?

Exactly.

> What confuses me in this patch is why are we doing replacements like:
> 
> ```
> -  site->commit_memory(rgn->committed_size());
> +  site->commit_memory(VirtualMemoryTracker::Instance::committed_size(rgn));
> ```
> 
> Doesn't that introduce dependencies on that singleton instance? Can you confirm that is sane?

I will take a look, but I think the plan now is to come up with a simple fix (since this needs to be backported to jdk25), so it looks like we are not going to push this one (Coleen said you fixed your issue already, so there  is urgency anymore? Please let me know if that is not the case)

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

PR Comment: https://git.openjdk.org/jdk/pull/26284#issuecomment-3073496019

From gziemski at openjdk.org  Tue Jul 15 12:59:41 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 15 Jul 2025 12:59:41 GMT
Subject: RFR: 8360048: NMT crash in gtest/NMTGtests.java: fatal error: NMT
 corruption: Block at 0x0000017748307120: header canary broken [v2]
In-Reply-To: <gDGhHvdiAvpkcH4QsshBOb50a1l6yo9KgLPj-Rhkt64=.128163b1-25da-464a-8764-5b284278aa92@github.com>
References: <gUIff3tC7KO9caTbRleaxcqvTLekIpCVqMu2Gbey19U=.9182d797-acee-4596-8bb6-3d36397c31c7@github.com>
 <yJEDxwa52f-71mm4eVPtbHtlxRHmCbG5QwHGkZ3zrvU=.873c3938-da7a-4b4e-b1d4-1859799ac7e8@github.com>
 <Z3BltYxT0nyWaSyukZcGtlQcZ9Wmb3qbiNlS4k-FMso=.3244baeb-f806-482c-8b1b-62ef6fcf8c69@github.com>
 <gDGhHvdiAvpkcH4QsshBOb50a1l6yo9KgLPj-Rhkt64=.128163b1-25da-464a-8764-5b284278aa92@github.com>
Message-ID: <5mjXq4G2jL0C5UXhHTEevJkL8IIKgFU6A0U0ezEwa6g=.cb1a199b-c5db-465c-bc3b-8a259d948217@github.com>

On Tue, 15 Jul 2025 12:56:45 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> So replacing the uses of (sigleton, shared) `VirtualMemoryTracker::Instance` with local `VirtualMemoryTracker vmt(true);` dodges the locking issue, right?
>> 
>> What confuses me in this patch is why are we doing replacements like:
>> 
>> 
>> -  site->commit_memory(rgn->committed_size());
>> +  site->commit_memory(VirtualMemoryTracker::Instance::committed_size(rgn));
>> 
>> 
>> Doesn't that introduce dependencies on that singleton instance? Can you confirm that is sane?
>
>> So replacing the uses of (sigleton, shared) `VirtualMemoryTracker::Instance` with local `VirtualMemoryTracker vmt(true);` dodges the locking issue, right?
> 
> Exactly.
> 
>> What confuses me in this patch is why are we doing replacements like:
>> 
>> ```
>> -  site->commit_memory(rgn->committed_size());
>> +  site->commit_memory(VirtualMemoryTracker::Instance::committed_size(rgn));
>> ```
>> 
>> Doesn't that introduce dependencies on that singleton instance? Can you confirm that is sane?
> 
> I will take a look, but I think the plan now is to come up with a simple fix (since this needs to be backported to jdk25), so it looks like we are not going to push this one (Coleen said you fixed your issue already, so there  is urgency anymore? Please let me know if that is not the case)

> @gerard-ziemski Can you prepare just the test fix for us to review? This should be a further RFE.

Happily, on it...

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

PR Comment: https://git.openjdk.org/jdk/pull/26284#issuecomment-3073498737

From shade at openjdk.org  Tue Jul 15 14:34:43 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 15 Jul 2025 14:34:43 GMT
Subject: RFR: 8360048: NMT crash in gtest/NMTGtests.java: fatal error: NMT
 corruption: Block at 0x0000017748307120: header canary broken [v2]
In-Reply-To: <gDGhHvdiAvpkcH4QsshBOb50a1l6yo9KgLPj-Rhkt64=.128163b1-25da-464a-8764-5b284278aa92@github.com>
References: <gUIff3tC7KO9caTbRleaxcqvTLekIpCVqMu2Gbey19U=.9182d797-acee-4596-8bb6-3d36397c31c7@github.com>
 <yJEDxwa52f-71mm4eVPtbHtlxRHmCbG5QwHGkZ3zrvU=.873c3938-da7a-4b4e-b1d4-1859799ac7e8@github.com>
 <Z3BltYxT0nyWaSyukZcGtlQcZ9Wmb3qbiNlS4k-FMso=.3244baeb-f806-482c-8b1b-62ef6fcf8c69@github.com>
 <gDGhHvdiAvpkcH4QsshBOb50a1l6yo9KgLPj-Rhkt64=.128163b1-25da-464a-8764-5b284278aa92@github.com>
Message-ID: <E79fEFiF-9ZteDEBFWtgeXUU7OQlWJnaNiuCc1y8jGY=.585642dd-68d8-4b10-bf52-7b70e1c02330@github.com>

On Tue, 15 Jul 2025 12:56:45 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> Coleen said you fixed your issue already, so there is urgency anymore? Please let me know if that is not the case)

Yeah, mine is [JDK-8361752](https://bugs.openjdk.org/browse/JDK-8361752), it is orthogonal to this. I am still interested not having gtest failures in our testing :)

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

PR Comment: https://git.openjdk.org/jdk/pull/26284#issuecomment-3073869228

From shade at openjdk.org  Tue Jul 15 15:10:43 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 15 Jul 2025 15:10:43 GMT
Subject: RFR: 8356941: AbstractMethodError in HotSpot Due to Incorrect
 Handling of Private Method [v2]
In-Reply-To: <nWFZw1gF1fWToINRFmJOExarreQRkUba1Qm0Ho6y7RQ=.65917004-c8d2-4943-862c-66f0aec9ce5f@github.com>
References: <qyWNTs0IOlf128C4ZdvOp9TE7O4w7bPaz2hJfHseIUk=.4a298588-6aff-471a-927b-beb3c9f0b194@github.com>
 <nWFZw1gF1fWToINRFmJOExarreQRkUba1Qm0Ho6y7RQ=.65917004-c8d2-4943-862c-66f0aec9ce5f@github.com>
Message-ID: <wVgvCxjh8XeIO0xMqoSlh3e6y7-DvFF1wUd65GqF_MQ=.2f64bb1b-c6c6-4c05-9780-68e6cd0641e7@github.com>

On Tue, 15 Jul 2025 00:52:54 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Private methods should never be considered as the implementation of a default method.
>> 
>> The first commit adds some additional logging I used to track down what was happening. I like it, but if reviewers think it too much I can drop it.
>> 
>> The second commit is the actual fix to exclude private methods, and adds the missing test case to the existing defmeth tests.
>> 
>> Testing:
>>  - tiers 1-4
>> 
>> Thanks
>
> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into 8356941-defaultmeth
>  - Merge branch 'master' into 8356941-defaultmeth
>  - Fix bug and add new testcases
>  - Additional logging to identify the problem

Maybe better without logging. It is not immediately clear if we need more `ResourceMark`-s around some logging messages?

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

PR Review: https://git.openjdk.org/jdk/pull/26302#pullrequestreview-3020870725

From coleenp at openjdk.org  Tue Jul 15 15:44:40 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 15 Jul 2025 15:44:40 GMT
Subject: RFR: 8356941: AbstractMethodError in HotSpot Due to Incorrect
 Handling of Private Method [v2]
In-Reply-To: <nWFZw1gF1fWToINRFmJOExarreQRkUba1Qm0Ho6y7RQ=.65917004-c8d2-4943-862c-66f0aec9ce5f@github.com>
References: <qyWNTs0IOlf128C4ZdvOp9TE7O4w7bPaz2hJfHseIUk=.4a298588-6aff-471a-927b-beb3c9f0b194@github.com>
 <nWFZw1gF1fWToINRFmJOExarreQRkUba1Qm0Ho6y7RQ=.65917004-c8d2-4943-862c-66f0aec9ce5f@github.com>
Message-ID: <ZVFFdhH0j0sKnC9miae9ieWIr1Qi7AO5Zm_EpQaBPuQ=.6a0747e3-95f1-4f58-ad40-8f08d01527ef@github.com>

On Tue, 15 Jul 2025 00:52:54 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Private methods should never be considered as the implementation of a default method.
>> 
>> The first commit adds some additional logging I used to track down what was happening. I like it, but if reviewers think it too much I can drop it.
>> 
>> The second commit is the actual fix to exclude private methods, and adds the missing test case to the existing defmeth tests.
>> 
>> Testing:
>>  - tiers 1-4
>> 
>> Thanks
>
> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into 8356941-defaultmeth
>  - Merge branch 'master' into 8356941-defaultmeth
>  - Fix bug and add new testcases
>  - Additional logging to identify the problem

I think the logging gets in the way of understanding the code.

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

PR Review: https://git.openjdk.org/jdk/pull/26302#pullrequestreview-3021035104

From matsaave at openjdk.org  Tue Jul 15 15:56:40 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 15 Jul 2025 15:56:40 GMT
Subject: RFR: 8356807: Change log_info(cds) to
 `MetaspaceShared::report_loading_error()` [v3]
In-Reply-To: <VKDHtC6KoO1vhrgonhvXIE0Cmlp-oMhYv0pv2bGduYY=.43bbaf91-4b63-4d3d-8bb2-3365d97f3a90@github.com>
References: <0O1bxM4K1u4yAqJdUKntyiF8m9UGd8OeZm_hFZ8oc_c=.f8d8d27f-52be-4080-b7ef-4e253f93281e@github.com>
 <VKDHtC6KoO1vhrgonhvXIE0Cmlp-oMhYv0pv2bGduYY=.43bbaf91-4b63-4d3d-8bb2-3365d97f3a90@github.com>
Message-ID: <kcml__hIPu6LYHRzZ0bG34or5LBxHtrOajDxQT5V_Rk=.7210d703-5837-43ee-8916-20eadd0cdb7f@github.com>

On Tue, 15 Jul 2025 04:24:56 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> The patch changes some of the `aot_log_info(aot)()` to `MetaspaceShared::report_loading_error()` for those referring to an error condition during loading of AOT cache or CDS archive.
>> 
>> Passed tiers 1 - 4 testing.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update ArchivedModuleWithCustomImageTest.java

LGTM! Just one nit below

src/hotspot/share/cds/filemap.cpp line 2021:

> 2019:   if (prop != nullptr) {
> 2020:     if (has_aot_linked_classes()) {
> 2021:       MetaspaceShared::report_loading_error("%s has aot-linked classes. It cannot be used when the "

The alignment was changed here.

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

Marked as reviewed by matsaave (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26253#pullrequestreview-3021074032
PR Review Comment: https://git.openjdk.org/jdk/pull/26253#discussion_r2207905581

From ccheung at openjdk.org  Tue Jul 15 16:13:39 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 15 Jul 2025 16:13:39 GMT
Subject: RFR: 8356807: Change log_info(cds) to
 `MetaspaceShared::report_loading_error()` [v3]
In-Reply-To: <kcml__hIPu6LYHRzZ0bG34or5LBxHtrOajDxQT5V_Rk=.7210d703-5837-43ee-8916-20eadd0cdb7f@github.com>
References: <0O1bxM4K1u4yAqJdUKntyiF8m9UGd8OeZm_hFZ8oc_c=.f8d8d27f-52be-4080-b7ef-4e253f93281e@github.com>
 <VKDHtC6KoO1vhrgonhvXIE0Cmlp-oMhYv0pv2bGduYY=.43bbaf91-4b63-4d3d-8bb2-3365d97f3a90@github.com>
 <kcml__hIPu6LYHRzZ0bG34or5LBxHtrOajDxQT5V_Rk=.7210d703-5837-43ee-8916-20eadd0cdb7f@github.com>
Message-ID: <we1_9Xx4XFmtg8Gx6Fs39uMDG68resrGfFOtZF3L68I=.02da6ba3-3f58-48ee-8fbe-f141e235905e@github.com>

On Tue, 15 Jul 2025 15:53:07 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update ArchivedModuleWithCustomImageTest.java
>
> src/hotspot/share/cds/filemap.cpp line 2021:
> 
>> 2019:   if (prop != nullptr) {
>> 2020:     if (has_aot_linked_classes()) {
>> 2021:       MetaspaceShared::report_loading_error("%s has aot-linked classes. It cannot be used when the "
> 
> The alignment was changed here.

Line 2022 already ends at column 115. If I indent it more to the right to align with line 2021, the line will end past column 125. I will leave it as is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26253#discussion_r2207942311

From gziemski at openjdk.org  Tue Jul 15 16:23:49 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 15 Jul 2025 16:23:49 GMT
Subject: RFR: 8362276: CLONE (simple fix) - NMT crash in gtest/NMTGtests.java:
 fatal error: NMT corruption: Block at 0x0000017748307120: header
 canary broken
Message-ID: <qQB1zCQqGIh5wPKBNEf2d7m49xfqOBwqUM0zOVcnlyQ=.8e32f46c-af0a-4ab8-a4a0-c23fa1474f28@github.com>

Me move the lock to make sure remove_all() is included.

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

Commit messages:
 - make sure the lock covers remove_all()

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

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

From ccheung at openjdk.org  Tue Jul 15 16:28:37 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 15 Jul 2025 16:28:37 GMT
Subject: RFR: 8356807: Change log_info(cds) to
 `MetaspaceShared::report_loading_error()` [v4]
In-Reply-To: <0O1bxM4K1u4yAqJdUKntyiF8m9UGd8OeZm_hFZ8oc_c=.f8d8d27f-52be-4080-b7ef-4e253f93281e@github.com>
References: <0O1bxM4K1u4yAqJdUKntyiF8m9UGd8OeZm_hFZ8oc_c=.f8d8d27f-52be-4080-b7ef-4e253f93281e@github.com>
Message-ID: <8ZMB1FAXFG6efY16TTAguNcCID8hoxhLbeZinyovkO8=.9a9d9629-04fe-4f32-8398-d7a45f74131c@github.com>

> The patch changes some of the `aot_log_info(aot)()` to `MetaspaceShared::report_loading_error()` for those referring to an error condition during loading of AOT cache or CDS archive.
> 
> Passed tiers 1 - 4 testing.

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

  fix indent in filemap.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26253/files
  - new: https://git.openjdk.org/jdk/pull/26253/files/1b55f8a4..02cc330b

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

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

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

From ccheung at openjdk.org  Tue Jul 15 16:28:38 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 15 Jul 2025 16:28:38 GMT
Subject: RFR: 8356807: Change log_info(cds) to
 `MetaspaceShared::report_loading_error()` [v3]
In-Reply-To: <we1_9Xx4XFmtg8Gx6Fs39uMDG68resrGfFOtZF3L68I=.02da6ba3-3f58-48ee-8fbe-f141e235905e@github.com>
References: <0O1bxM4K1u4yAqJdUKntyiF8m9UGd8OeZm_hFZ8oc_c=.f8d8d27f-52be-4080-b7ef-4e253f93281e@github.com>
 <VKDHtC6KoO1vhrgonhvXIE0Cmlp-oMhYv0pv2bGduYY=.43bbaf91-4b63-4d3d-8bb2-3365d97f3a90@github.com>
 <kcml__hIPu6LYHRzZ0bG34or5LBxHtrOajDxQT5V_Rk=.7210d703-5837-43ee-8916-20eadd0cdb7f@github.com>
 <we1_9Xx4XFmtg8Gx6Fs39uMDG68resrGfFOtZF3L68I=.02da6ba3-3f58-48ee-8fbe-f141e235905e@github.com>
Message-ID: <FIRp1zMCEAeUYhbm-aHsHgKN9tRgs8PPcMVtmuDgrxk=.31a840d9-f924-45ed-a83b-0cadd951f5a6@github.com>

On Tue, 15 Jul 2025 16:11:06 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> src/hotspot/share/cds/filemap.cpp line 2021:
>> 
>>> 2019:   if (prop != nullptr) {
>>> 2020:     if (has_aot_linked_classes()) {
>>> 2021:       MetaspaceShared::report_loading_error("%s has aot-linked classes. It cannot be used when the "
>> 
>> The alignment was changed here.
>
> Line 2022 already ends at column 115. If I indent it more to the right to align with line 2021, the line will end past column 125. I will leave it as is.

Fixed the indent per our offline discussion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26253#discussion_r2207969492

From matsaave at openjdk.org  Tue Jul 15 16:32:58 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 15 Jul 2025 16:32:58 GMT
Subject: RFR: 8356807: Change log_info(cds) to
 `MetaspaceShared::report_loading_error()` [v4]
In-Reply-To: <8ZMB1FAXFG6efY16TTAguNcCID8hoxhLbeZinyovkO8=.9a9d9629-04fe-4f32-8398-d7a45f74131c@github.com>
References: <0O1bxM4K1u4yAqJdUKntyiF8m9UGd8OeZm_hFZ8oc_c=.f8d8d27f-52be-4080-b7ef-4e253f93281e@github.com>
 <8ZMB1FAXFG6efY16TTAguNcCID8hoxhLbeZinyovkO8=.9a9d9629-04fe-4f32-8398-d7a45f74131c@github.com>
Message-ID: <q4NRw6Bab58QVWrppD0Gq88Vuwynw6fKJgFihV6cBiQ=.7e6cb10a-4aba-47e9-b008-73b98097f7fe@github.com>

On Tue, 15 Jul 2025 16:28:37 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> The patch changes some of the `aot_log_info(aot)()` to `MetaspaceShared::report_loading_error()` for those referring to an error condition during loading of AOT cache or CDS archive.
>> 
>> Passed tiers 1 - 4 testing.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix indent in filemap.cpp

Thanks for the fix, looks good!

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

Marked as reviewed by matsaave (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26253#pullrequestreview-3021186528

From shade at openjdk.org  Tue Jul 15 16:56:42 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 15 Jul 2025 16:56:42 GMT
Subject: RFR: 8362276: CLONE (simple fix) - NMT crash in
 gtest/NMTGtests.java: fatal error: NMT corruption: Block at
 0x0000017748307120: header canary broken
In-Reply-To: <qQB1zCQqGIh5wPKBNEf2d7m49xfqOBwqUM0zOVcnlyQ=.8e32f46c-af0a-4ab8-a4a0-c23fa1474f28@github.com>
References: <qQB1zCQqGIh5wPKBNEf2d7m49xfqOBwqUM0zOVcnlyQ=.8e32f46c-af0a-4ab8-a4a0-c23fa1474f28@github.com>
Message-ID: <zY2LNwRqhAaicsRFrVIE43-i8AGgqLuuFou2vNpQMpY=.dbaae28a-b26c-4a96-b438-f2f2d38ec71f@github.com>

On Tue, 15 Jul 2025 16:14:52 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> We move the lock to make sure remove_all() is included.

Looks good, but synopsis even more confusing than the original one. Suggestion:  "8362276: NMT tests should have locks for the entire tests" or something.

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

PR Review: https://git.openjdk.org/jdk/pull/26324#pullrequestreview-3021264275

From ccheung at openjdk.org  Tue Jul 15 17:29:44 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 15 Jul 2025 17:29:44 GMT
Subject: RFR: 8356807: Change log_info(cds) to
 `MetaspaceShared::report_loading_error()` [v3]
In-Reply-To: <08EdRKGLTpvjWR7Hz5zppZZCHshcqsQiIvlOwWgLC6A=.2930ccc9-9e62-4123-ab4c-0d9d16bd82ff@github.com>
References: <0O1bxM4K1u4yAqJdUKntyiF8m9UGd8OeZm_hFZ8oc_c=.f8d8d27f-52be-4080-b7ef-4e253f93281e@github.com>
 <VKDHtC6KoO1vhrgonhvXIE0Cmlp-oMhYv0pv2bGduYY=.43bbaf91-4b63-4d3d-8bb2-3365d97f3a90@github.com>
 <08EdRKGLTpvjWR7Hz5zppZZCHshcqsQiIvlOwWgLC6A=.2930ccc9-9e62-4123-ab4c-0d9d16bd82ff@github.com>
Message-ID: <zPVOM9fF1H4zTqXiUr_37OwRO33-SnfkeBuSy6n-mfA=.3e3de2e1-1bd4-4fad-aba5-bde56dfc7ee3@github.com>

On Tue, 15 Jul 2025 05:39:05 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update ArchivedModuleWithCustomImageTest.java
>
> Marked as reviewed by iklam (Reviewer).

Thanks @iklam @matias9927 for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/26253#issuecomment-3074541183

From ccheung at openjdk.org  Tue Jul 15 17:29:45 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 15 Jul 2025 17:29:45 GMT
Subject: Integrated: 8356807: Change log_info(cds) to
 `MetaspaceShared::report_loading_error()`
In-Reply-To: <0O1bxM4K1u4yAqJdUKntyiF8m9UGd8OeZm_hFZ8oc_c=.f8d8d27f-52be-4080-b7ef-4e253f93281e@github.com>
References: <0O1bxM4K1u4yAqJdUKntyiF8m9UGd8OeZm_hFZ8oc_c=.f8d8d27f-52be-4080-b7ef-4e253f93281e@github.com>
Message-ID: <-EeAaNFGX80bp_L3SoVQU7vO-0R43lc1kufqtMkVfAk=.3920434e-da2f-4f57-9a66-11e3bdc9f657@github.com>

On Thu, 10 Jul 2025 21:19:02 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> The patch changes some of the `aot_log_info(aot)()` to `MetaspaceShared::report_loading_error()` for those referring to an error condition during loading of AOT cache or CDS archive.
> 
> Passed tiers 1 - 4 testing.

This pull request has now been integrated.

Changeset: 38af17d0
Author:    Calvin Cheung <ccheung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/38af17d078d164b6550ecba329d46d5a8de77cd1
Stats:     34 lines in 4 files changed: 3 ins; 0 del; 31 mod

8356807: Change log_info(cds) to `MetaspaceShared::report_loading_error()`

Reviewed-by: matsaave, iklam

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

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

From coleenp at openjdk.org  Tue Jul 15 17:40:40 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 15 Jul 2025 17:40:40 GMT
Subject: RFR: 8356941: AbstractMethodError in HotSpot Due to Incorrect
 Handling of Private Method [v2]
In-Reply-To: <nWFZw1gF1fWToINRFmJOExarreQRkUba1Qm0Ho6y7RQ=.65917004-c8d2-4943-862c-66f0aec9ce5f@github.com>
References: <qyWNTs0IOlf128C4ZdvOp9TE7O4w7bPaz2hJfHseIUk=.4a298588-6aff-471a-927b-beb3c9f0b194@github.com>
 <nWFZw1gF1fWToINRFmJOExarreQRkUba1Qm0Ho6y7RQ=.65917004-c8d2-4943-862c-66f0aec9ce5f@github.com>
Message-ID: <YT53kii0W7BHT7JzhBLYcm0zpX4ED_ndpPKKqqJRXu0=.adfd659e-8ab6-4843-9405-24642f18df36@github.com>

On Tue, 15 Jul 2025 00:52:54 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Private methods should never be considered as the implementation of a default method.
>> 
>> The first commit adds some additional logging I used to track down what was happening. I like it, but if reviewers think it too much I can drop it.
>> 
>> The second commit is the actual fix to exclude private methods, and adds the missing test case to the existing defmeth tests.
>> 
>> Testing:
>>  - tiers 1-4
>> 
>> Thanks
>
> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into 8356941-defaultmeth
>  - Merge branch 'master' into 8356941-defaultmeth
>  - Fix bug and add new testcases
>  - Additional logging to identify the problem

src/hotspot/share/classfile/defaultMethods.cpp line 686:

> 684:           }
> 685:           Method* impl = klass->lookup_method(m->name(), m->signature());
> 686:           if (impl == nullptr || impl->is_overpass() || impl->is_static() || impl->is_private()) {

I still haven't figured out why this code fixes this issue, but why doesn't line 657 need the same change?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26302#discussion_r2208165331

From shade at openjdk.org  Tue Jul 15 18:39:43 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 15 Jul 2025 18:39:43 GMT
Subject: RFR: 8362276: CLONE (simple fix) - NMT crash in
 gtest/NMTGtests.java: fatal error: NMT corruption: Block at
 0x0000017748307120: header canary broken
In-Reply-To: <qQB1zCQqGIh5wPKBNEf2d7m49xfqOBwqUM0zOVcnlyQ=.8e32f46c-af0a-4ab8-a4a0-c23fa1474f28@github.com>
References: <qQB1zCQqGIh5wPKBNEf2d7m49xfqOBwqUM0zOVcnlyQ=.8e32f46c-af0a-4ab8-a4a0-c23fa1474f28@github.com>
Message-ID: <LVWysOvx6vOMOAWWWowjP273ap3dnGqiFiWzu45nzig=.d9d23a43-ab26-4965-adf2-367f7788dae3@github.com>

On Tue, 15 Jul 2025 16:14:52 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> We move the lock to make sure remove_all() is included.

Well, GHA thinks this does not work:


# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/Users/runner/work/jdk/jdk/src/hotspot/share/runtime/mutex.cpp:143), pid=5569, tid=259
#  assert(owner() != self) failed: invariant

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

PR Comment: https://git.openjdk.org/jdk/pull/26324#issuecomment-3074954015

From ccheung at openjdk.org  Tue Jul 15 21:16:49 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 15 Jul 2025 21:16:49 GMT
Subject: [jdk25] RFR: 8361328:
 cds/appcds/dynamicArchive/TestAutoCreateSharedArchive.java archive timestamps
 comparison failed
Message-ID: <m8ESWOx8FxmJzlk5r5Od1Hc_4YxpVbE2jGtEVezmy-s=.8619f85c-6cab-4907-a786-99877d47418f@github.com>

Hi all,

This pull request contains a backport of commit [4a351e3e](https://github.com/openjdk/jdk/commit/4a351e3e57274df0adee37c472b62f477f75b7b8) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Calvin Cheung on 12 Jul 2025 and was reviewed by Ioi Lam and Matias Saavedra Silva.

Thanks!

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

Commit messages:
 - Backport 4a351e3e57274df0adee37c472b62f477f75b7b8

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

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

From matsaave at openjdk.org  Tue Jul 15 21:22:38 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 15 Jul 2025 21:22:38 GMT
Subject: [jdk25] RFR: 8361328:
 cds/appcds/dynamicArchive/TestAutoCreateSharedArchive.java archive timestamps
 comparison failed
In-Reply-To: <m8ESWOx8FxmJzlk5r5Od1Hc_4YxpVbE2jGtEVezmy-s=.8619f85c-6cab-4907-a786-99877d47418f@github.com>
References: <m8ESWOx8FxmJzlk5r5Od1Hc_4YxpVbE2jGtEVezmy-s=.8619f85c-6cab-4907-a786-99877d47418f@github.com>
Message-ID: <Equt-hbv-Ra7qc7C9f81M4fb9W-ueE1O7iEYrzcIZa0=.29fed375-3c4f-431b-9d95-5e537acf6ec4@github.com>

On Tue, 15 Jul 2025 21:04:40 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [4a351e3e](https://github.com/openjdk/jdk/commit/4a351e3e57274df0adee37c472b62f477f75b7b8) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Calvin Cheung on 12 Jul 2025 and was reviewed by Ioi Lam and Matias Saavedra Silva.
> 
> Thanks!

Backport looks clean. Thanks!

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

Marked as reviewed by matsaave (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26333#pullrequestreview-3022362864

From iklam at openjdk.org  Tue Jul 15 21:35:40 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 15 Jul 2025 21:35:40 GMT
Subject: [jdk25] RFR: 8361328:
 cds/appcds/dynamicArchive/TestAutoCreateSharedArchive.java archive timestamps
 comparison failed
In-Reply-To: <m8ESWOx8FxmJzlk5r5Od1Hc_4YxpVbE2jGtEVezmy-s=.8619f85c-6cab-4907-a786-99877d47418f@github.com>
References: <m8ESWOx8FxmJzlk5r5Od1Hc_4YxpVbE2jGtEVezmy-s=.8619f85c-6cab-4907-a786-99877d47418f@github.com>
Message-ID: <Afdk8WC-4PLjjgLE2VMgFG9peZ8Bwoy9B-RWfm8UmG0=.d7e4427a-3e4a-4ccd-a013-9d10d7d31eac@github.com>

On Tue, 15 Jul 2025 21:04:40 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [4a351e3e](https://github.com/openjdk/jdk/commit/4a351e3e57274df0adee37c472b62f477f75b7b8) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Calvin Cheung on 12 Jul 2025 and was reviewed by Ioi Lam and Matias Saavedra Silva.
> 
> Thanks!

Marked as reviewed by iklam (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26333#pullrequestreview-3022410346

From ccheung at openjdk.org  Tue Jul 15 21:48:47 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 15 Jul 2025 21:48:47 GMT
Subject: [jdk25] RFR: 8361328:
 cds/appcds/dynamicArchive/TestAutoCreateSharedArchive.java archive timestamps
 comparison failed
In-Reply-To: <Equt-hbv-Ra7qc7C9f81M4fb9W-ueE1O7iEYrzcIZa0=.29fed375-3c4f-431b-9d95-5e537acf6ec4@github.com>
References: <m8ESWOx8FxmJzlk5r5Od1Hc_4YxpVbE2jGtEVezmy-s=.8619f85c-6cab-4907-a786-99877d47418f@github.com>
 <Equt-hbv-Ra7qc7C9f81M4fb9W-ueE1O7iEYrzcIZa0=.29fed375-3c4f-431b-9d95-5e537acf6ec4@github.com>
Message-ID: <wTzdQfuxOyCuwx3wVFooN_MQWhNjochpHtyitb-jY-U=.dac7c0ab-b3a3-40d6-9bff-04197f84e707@github.com>

On Tue, 15 Jul 2025 21:19:43 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> Hi all,
>> 
>> This pull request contains a backport of commit [4a351e3e](https://github.com/openjdk/jdk/commit/4a351e3e57274df0adee37c472b62f477f75b7b8) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>> 
>> The commit being backported was authored by Calvin Cheung on 12 Jul 2025 and was reviewed by Ioi Lam and Matias Saavedra Silva.
>> 
>> Thanks!
>
> Backport looks clean. Thanks!

Thanks @matias9927 @iklam for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/26333#issuecomment-3075830475

From ccheung at openjdk.org  Tue Jul 15 21:48:48 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 15 Jul 2025 21:48:48 GMT
Subject: [jdk25] Integrated: 8361328:
 cds/appcds/dynamicArchive/TestAutoCreateSharedArchive.java archive timestamps
 comparison failed
In-Reply-To: <m8ESWOx8FxmJzlk5r5Od1Hc_4YxpVbE2jGtEVezmy-s=.8619f85c-6cab-4907-a786-99877d47418f@github.com>
References: <m8ESWOx8FxmJzlk5r5Od1Hc_4YxpVbE2jGtEVezmy-s=.8619f85c-6cab-4907-a786-99877d47418f@github.com>
Message-ID: <u-Yg9dLU3VO751Uz8i723PxJd6EyS21v9ECG_Kw28kw=.3482defb-d345-49ed-9d3d-4c29824a95d7@github.com>

On Tue, 15 Jul 2025 21:04:40 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [4a351e3e](https://github.com/openjdk/jdk/commit/4a351e3e57274df0adee37c472b62f477f75b7b8) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Calvin Cheung on 12 Jul 2025 and was reviewed by Ioi Lam and Matias Saavedra Silva.
> 
> Thanks!

This pull request has now been integrated.

Changeset: e1926a6d
Author:    Calvin Cheung <ccheung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e1926a6d0e3252d2d3f16a93afaac4c289052148
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8361328: cds/appcds/dynamicArchive/TestAutoCreateSharedArchive.java archive timestamps comparison failed

Reviewed-by: matsaave, iklam
Backport-of: 4a351e3e57274df0adee37c472b62f477f75b7b8

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

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

From gziemski at openjdk.org  Tue Jul 15 22:48:30 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 15 Jul 2025 22:48:30 GMT
Subject: RFR: 8362276: NMT tests should have locks for the entire tests
 [v2]
In-Reply-To: <qQB1zCQqGIh5wPKBNEf2d7m49xfqOBwqUM0zOVcnlyQ=.8e32f46c-af0a-4ab8-a4a0-c23fa1474f28@github.com>
References: <qQB1zCQqGIh5wPKBNEf2d7m49xfqOBwqUM0zOVcnlyQ=.8e32f46c-af0a-4ab8-a4a0-c23fa1474f28@github.com>
Message-ID: <eUfwdxT_5O7wrultyFab65P3CBv4deXsUN_S6mmBrm8=.577d0e24-f711-46f7-9cc3-40eeda6c8065@github.com>

> We restructure the code to make sure we cover the code that uses the global tree instance (but nothing else that uses the same lock internally) as needed:
> 
> - we move MemoryReserver::reserve() to the top to do as the first thing
> - we grab the MemTracker::NmtVirtualMemoryLocker nvml
> - do all the usual test stuff, including checking, which grabs the global instance of the tree
> - we move remove_all() to the very bottom to do as the last thing
> 
> Testing: runnig Mach5 tier1-4 right now...

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

  restructure code to make sure we use the lock as needed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26324/files
  - new: https://git.openjdk.org/jdk/pull/26324/files/4958be33..4387bee2

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

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

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

From gziemski at openjdk.org  Tue Jul 15 22:48:30 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 15 Jul 2025 22:48:30 GMT
Subject: RFR: 8362276: NMT tests should have locks for the entire tests
In-Reply-To: <LVWysOvx6vOMOAWWWowjP273ap3dnGqiFiWzu45nzig=.d9d23a43-ab26-4965-adf2-367f7788dae3@github.com>
References: <qQB1zCQqGIh5wPKBNEf2d7m49xfqOBwqUM0zOVcnlyQ=.8e32f46c-af0a-4ab8-a4a0-c23fa1474f28@github.com>
 <LVWysOvx6vOMOAWWWowjP273ap3dnGqiFiWzu45nzig=.d9d23a43-ab26-4965-adf2-367f7788dae3@github.com>
Message-ID: <AGHX0CcYx8y6oo6ToPSrxTo-Ra55ZFE24pYyKwEp9mw=.470594d4-c17c-4771-af22-3cb792ad1c61@github.com>

On Tue, 15 Jul 2025 18:36:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Well, GHA thinks this does not work:
> 
> ```
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (/Users/runner/work/jdk/jdk/src/hotspot/share/runtime/mutex.cpp:143), pid=5569, tid=259
> #  assert(owner() != self) failed: invariant
> ```

Yes, this is probably why Afshin went with his fix, investigating ....

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

PR Comment: https://git.openjdk.org/jdk/pull/26324#issuecomment-3075293145

From coleenp at openjdk.org  Tue Jul 15 22:48:30 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 15 Jul 2025 22:48:30 GMT
Subject: RFR: 8362276: NMT tests should have locks for the entire tests
 [v2]
In-Reply-To: <zY2LNwRqhAaicsRFrVIE43-i8AGgqLuuFou2vNpQMpY=.dbaae28a-b26c-4a96-b438-f2f2d38ec71f@github.com>
References: <qQB1zCQqGIh5wPKBNEf2d7m49xfqOBwqUM0zOVcnlyQ=.8e32f46c-af0a-4ab8-a4a0-c23fa1474f28@github.com>
 <zY2LNwRqhAaicsRFrVIE43-i8AGgqLuuFou2vNpQMpY=.dbaae28a-b26c-4a96-b438-f2f2d38ec71f@github.com>
Message-ID: <fp3PwrkYiJYdykkQTjMHDo4gXKcZ0-BhvM8OOLAN0CM=.78d850d8-2a7f-4c4f-be0f-299e054f0572@github.com>

On Tue, 15 Jul 2025 16:54:01 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Looks good, but synopsis even more confusing than the original one. Suggestion: "8362276: NMT tests should have locks for the entire tests" or something.

Yes, please change the name to that.  We changed the synopsis of the bug today to remove CLONE (simple fix), so you should change both the PR and the bug title.

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

PR Comment: https://git.openjdk.org/jdk/pull/26324#issuecomment-3075898753

From lmesnik at openjdk.org  Wed Jul 16 00:31:47 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 16 Jul 2025 00:31:47 GMT
Subject: Integrated: 8358004: Delete applications/scimark/Scimark.java test
In-Reply-To: <_o6ne7B1-A7nSOva7Zns8IMv7rw0Ve4xTwqiSajNzcA=.755977c7-4376-415c-9f76-5acae9f12b5a@github.com>
References: <_o6ne7B1-A7nSOva7Zns8IMv7rw0Ve4xTwqiSajNzcA=.755977c7-4376-415c-9f76-5acae9f12b5a@github.com>
Message-ID: <fePKcKrkiJiAtJoETOAuJY7Cc9D5annncGdPMRCSjos=.147f29ae-aad2-432f-a88d-3a4ff10b91e5@github.com>

On Tue, 20 May 2025 02:55:44 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Test 
> scimark has a bug, described in the https://bugs.openjdk.org/browse/JDK-8315797
> that causes test failure.
> 
> The Scimark is not maintained. The main goal of test was to provide example of Artifact-based test with 3rd party binary. There are a couple of other tests using Artifactory. So this test is completely useless now. 
> I am removing it just to avoid spending time for anyone who can run test and observe this failure.

This pull request has now been integrated.

Changeset: a5c9bc70
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a5c9bc70324693e9d0b25bb2c51b91dfc750c453
Stats:     58 lines in 1 file changed: 0 ins; 58 del; 0 mod

8358004: Delete applications/scimark/Scimark.java test

Reviewed-by: syan, coleenp

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

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

From dholmes at openjdk.org  Wed Jul 16 02:08:40 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 16 Jul 2025 02:08:40 GMT
Subject: RFR: 8359820: SIGILL with low -XX:HandshakeTimeout
In-Reply-To: <FZ87bVfDootrLeANGguMFpcTm7X8AEqzuKVQspmSkmE=.4484090b-ba49-498c-bb07-71d22fd34823@github.com>
References: <FZ87bVfDootrLeANGguMFpcTm7X8AEqzuKVQspmSkmE=.4484090b-ba49-498c-bb07-71d22fd34823@github.com>
Message-ID: <tydGs9_Hv398LwQFgg5HrfEsvMxq3zB2KhUu51JB2jI=.efceb465-f108-4dd9-b43a-aa704646aab5@github.com>

On Tue, 15 Jul 2025 08:37:38 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> we augment the SIGILL handling in `os::signal_thread` with proper logging so that the initial crash information goes to stdout/stderr as well. 
> 
> 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.
> 
> Tested in tiers 1-3.

@toxaart I'm really looking for something in the fatal error handler so that instead of seeing just:

#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGILL (0x4) at pc=0x00007d9dc5a98d71 (sent by kill), pid=329828, tid=329852
#
# JRE version: Java(TM) SE Runtime Environment (26.0+3) (fastdebug build 26-ea+3-153)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 26-ea+3-153, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# C [libc.so.6+0x98d71] 


There is something there that indicates it was a handshake timeout. E.g.


# SIGILL (0x4) at pc=0x00007d9dc5a98d71 (sent by handshake timeout handlerl), pid=329828, tid=329852


We may need the handshake code to set a flag on the target Thread that the error code can query if it sees a SIGILL.

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

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

From syan at openjdk.org  Wed Jul 16 02:53:25 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 16 Jul 2025 02:53:25 GMT
Subject: [jdk25] RFR: 8358004: Delete applications/scimark/Scimark.java test
Message-ID: <sZMOLVpuyS1bMiVSRvuzMK35bivA3q4PckpIVRQqccE=.fbcde97f-397e-490a-a5bf-137d02f5e3fc@github.com>

Hi all,

This pull request contains a backport of commit [a5c9bc70](https://github.com/openjdk/jdk/commit/a5c9bc70324693e9d0b25bb2c51b91dfc750c453) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The Scimark is not maintained, this backport PR remove this useless tests which cause test failure. Test-fix only, no risk.

The commit being backported was authored by Leonid Mesnik on 16 Jul 2025 and was reviewed by SendaoYan and Coleen Phillimore.

Thanks!

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

Commit messages:
 - Backport a5c9bc70324693e9d0b25bb2c51b91dfc750c453

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

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

From duke at openjdk.org  Wed Jul 16 05:34:54 2025
From: duke at openjdk.org (duke)
Date: Wed, 16 Jul 2025 05:34:54 GMT
Subject: Withdrawn: 8344270: Update tier1_common and hotspot_misc groups to
 better organize hotspot non-component tests
In-Reply-To: <HwmHlJBdtkCsNZB_K4Ap_5cLH0mxC8zGeMXpqH_FQ38=.73fadae6-64cb-4ae5-92ea-40b92e0870e7@github.com>
References: <HwmHlJBdtkCsNZB_K4Ap_5cLH0mxC8zGeMXpqH_FQ38=.73fadae6-64cb-4ae5-92ea-40b92e0870e7@github.com>
Message-ID: <yWWe92TapC0QWDh91OM94dlpdHRev95d-LWpOwplXlg=.d56972c7-8f9f-4119-9257-a96cf4f506d1@github.com>

On Tue, 6 May 2025 17:43:51 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Can you please review following PR that improve test groups.
> The bug was originally filed  to eliminate duplication between tier1_common and hotspot_misc test groups.  However while looked on the test content of these groups I realized that there are some other issues. 
> 1) hotspot_resourcehogs groups should be executed always separately from other tests to don't cause intermittent failures.
> 2) it makes sense to run all gtest tests in tier1 but don't run in any other tiers (with any VM flags) 
> 3) testlibrary_tests and  sources should be a separate groups that don't need to be executed with any VM flags, or event with all builds 
> 
> So tier1_common includes non-component tests that should be executed in tier1. 
> **all** sanity tests
> **all** gttest tests (were not all of them)
> testlibrary_tests (might be os/cpu specifc, so need to run them with all builds)
> source code checking tests (no need to run them an all builds, but it takes only few seconds)
> 
> And it doesn't makes any sense to execute  tier1_common with any external VM flags.
> 
> While hotspot_misc now includes on 2 sanity tests.  It doesn't looks useful, but main purpose for this group would be to catch all tests that somehow missed from other groups. So let keep it. 
> 
> The new test groups were added mostly to add comments explaining their specific.

This pull request has been closed without being integrated.

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

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

From ccheung at openjdk.org  Wed Jul 16 06:33:18 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 16 Jul 2025 06:33:18 GMT
Subject: RFR: 8362336: Revert changes in metaspaceShared.cpp done via
 JDK-8356807
Message-ID: <jrW7L06iBIzAYx-2e3Bi7ZJmXtDWmjoM0cXFd0-4fvM=.ba6aacfa-5103-4adf-b217-966bc3e62797@github.com>

The changes in `metaspaceShared.cpp` for JDK-8356807 is causing bootcycle prebuilt failures. Therefore, reverting those changes.

Testing: tiers 1 - 3, builds-tier4.

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

Commit messages:
 - 8362336: Revert changes in metaspaceShared.cpp done via JDK-8356807

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

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

From dholmes at openjdk.org  Wed Jul 16 06:54:39 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 16 Jul 2025 06:54:39 GMT
Subject: RFR: 8356941: AbstractMethodError in HotSpot Due to Incorrect
 Handling of Private Method [v2]
In-Reply-To: <YT53kii0W7BHT7JzhBLYcm0zpX4ED_ndpPKKqqJRXu0=.adfd659e-8ab6-4843-9405-24642f18df36@github.com>
References: <qyWNTs0IOlf128C4ZdvOp9TE7O4w7bPaz2hJfHseIUk=.4a298588-6aff-471a-927b-beb3c9f0b194@github.com>
 <nWFZw1gF1fWToINRFmJOExarreQRkUba1Qm0Ho6y7RQ=.65917004-c8d2-4943-862c-66f0aec9ce5f@github.com>
 <YT53kii0W7BHT7JzhBLYcm0zpX4ED_ndpPKKqqJRXu0=.adfd659e-8ab6-4843-9405-24642f18df36@github.com>
Message-ID: <-3RNJiycRfcQauuARkAZtWcuppR2OCZMW1IJibmIjBE=.b4f4b136-4cc1-4c0d-a3ee-c9ad861f881f@github.com>

On Tue, 15 Jul 2025 17:38:11 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> why doesn't line 657 need the same change?

Are you asking why it doesn't need the change to address the current bug? That would be because that block of code has nothing at all to do with the current bug. That block is looking at superclass overpass and static methods, to see if they may be candidates for replacing by a default method. For each of those methods it checks if there is an implementation in the current class that matches the name and sig and is a real method, and if so it doesn't create an empty vtable slot for it for default method processing to fill in. I spent a long time trying to create a scenario that would hit this block and the condition you want changed, but failed. Lets say we are looking at a slot for method `void m()` for simplicity. First you need a superclass that declares as static `void m()` method. Then you need a subclass that implements a non-static `void m()` method. But you also need to have the subclass implement an interface with a default `void m()` method, but in that case we will never r
 each the block of code because we will find that default method is already present in the list of miranda methods that we already processed! (During this phase of processing, default methods are considered mirandas - pass 1).

Now as to the actual fix ... we have a subclass that we are processing, and a superclass that has a private `void m()` method, and a super-super-interface that defines the default `void m()` method. We find `void m()` in the superclass's default methods - hence we reach the block of code I modified. For this slot to be processed  for default method handling (i.e. to get the correct entry so we invoke the true default method) we need to decide to create an empty vtable slot. The current logic (mirroring that for superclass methods - including the comment block that may or may not be accurate) checks to see if the current class has a concrete implementation of `void m()` as that would replace use of the default implementation (class instance methods "win"), except that is only true for non-private concrete implementations - a private class method is never considered the implementation of an interface method. So if the method is private we need to create the empty vtable slot - hence th
 e fix. 

Note that `klass->lookup_method` looks up the method in the current class and all superclasses, and will find overpass and private methods - so an alternative fix would be to change the lookup to skip private methods (and we could also skip overpasses and then simplify the condition further). But the two approaches to the fix seem equivalent in terms of readability/complexity and what I did was slightly shorter to write and fitted in with the other checks nicely.

I hope that clarifies things.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26302#discussion_r2209440542

From dholmes at openjdk.org  Wed Jul 16 06:57:40 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 16 Jul 2025 06:57:40 GMT
Subject: RFR: 8356941: AbstractMethodError in HotSpot Due to Incorrect
 Handling of Private Method [v2]
In-Reply-To: <wVgvCxjh8XeIO0xMqoSlh3e6y7-DvFF1wUd65GqF_MQ=.2f64bb1b-c6c6-4c05-9780-68e6cd0641e7@github.com>
References: <qyWNTs0IOlf128C4ZdvOp9TE7O4w7bPaz2hJfHseIUk=.4a298588-6aff-471a-927b-beb3c9f0b194@github.com>
 <nWFZw1gF1fWToINRFmJOExarreQRkUba1Qm0Ho6y7RQ=.65917004-c8d2-4943-862c-66f0aec9ce5f@github.com>
 <wVgvCxjh8XeIO0xMqoSlh3e6y7-DvFF1wUd65GqF_MQ=.2f64bb1b-c6c6-4c05-9780-68e6cd0641e7@github.com>
Message-ID: <9S5ky44TQitucQ-rlsHzLR0IpfMhIYPbZkJLNT9tDLs=.f8706b10-cb40-44c5-bf5d-eecfc5faeb81@github.com>

On Tue, 15 Jul 2025 15:07:51 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 four additional commits since the last revision:
>> 
>>  - Merge branch 'master' into 8356941-defaultmeth
>>  - Merge branch 'master' into 8356941-defaultmeth
>>  - Fix bug and add new testcases
>>  - Additional logging to identify the problem
>
> Maybe better without logging. It is not immediately clear if we need more `ResourceMark`-s around some logging messages?

Thanks for looking at this @shipilev !

> Maybe better without logging. It is not immediately clear if we need more `ResourceMark`-s around some logging messages?

Regarding `ResourceMark` this is handled at the `generate_default_methods` entry point:

void DefaultMethods::generate_default_methods(
    InstanceKlass* klass, const GrowableArray<Method*>* mirandas, TRAPS) {
  assert(klass != nullptr, "invariant");
  assert(klass != vmClasses::Object_klass(), "Shouldn't be called for Object");

  // This resource mark is the bound for all memory allocation that takes
  // place during default method processing.  After this goes out of scope,
  // all (Resource) objects' memory will be reclaimed.  Be careful if adding an
  // embedded resource mark under here as that memory can't be used outside
  // whatever scope it's in.
  ResourceMark rm(THREAD);

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

PR Comment: https://git.openjdk.org/jdk/pull/26302#issuecomment-3077145815

From dholmes at openjdk.org  Wed Jul 16 07:07:49 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 16 Jul 2025 07:07:49 GMT
Subject: RFR: 8356941: AbstractMethodError in HotSpot Due to Incorrect
 Handling of Private Method [v2]
In-Reply-To: <ZVFFdhH0j0sKnC9miae9ieWIr1Qi7AO5Zm_EpQaBPuQ=.6a0747e3-95f1-4f58-ad40-8f08d01527ef@github.com>
References: <qyWNTs0IOlf128C4ZdvOp9TE7O4w7bPaz2hJfHseIUk=.4a298588-6aff-471a-927b-beb3c9f0b194@github.com>
 <nWFZw1gF1fWToINRFmJOExarreQRkUba1Qm0Ho6y7RQ=.65917004-c8d2-4943-862c-66f0aec9ce5f@github.com>
 <ZVFFdhH0j0sKnC9miae9ieWIr1Qi7AO5Zm_EpQaBPuQ=.6a0747e3-95f1-4f58-ad40-8f08d01527ef@github.com>
Message-ID: <oV0bcOwmwNccvNvFywF6Nc_eta8y6uJR_r142OUnXnU=.f4d11ffb-124c-4506-bbd1-9a9d93c86a1f@github.com>

On Tue, 15 Jul 2025 15:41:48 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Merge branch 'master' into 8356941-defaultmeth
>>  - Merge branch 'master' into 8356941-defaultmeth
>>  - Fix bug and add new testcases
>>  - Additional logging to identify the problem
>
> I think the logging gets in the way of understanding the code.  It makes the code hard to read.

Thanks for looking at this @coleenp !

> I think the logging gets in the way of understanding the code. It makes the code hard to read.

I don't disagree. Unfortunately to get the indentation working we need to use a very verbose form of the logging code - and there is lots of duplication. It may be possible to introduce a helper function, but it will still be quite intrusive.

That said I found the logging invaluable when trying to understand why the wrong method was being executed. Though that said the logging is still far from complete in terms of getting a full understanding of how things are processed - I had to add a lot more in my local repo to do the additional experiments today.

So I will remove the logging (and just stash my changes locally for next time).

Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/26302#issuecomment-3077212874

From dholmes at openjdk.org  Wed Jul 16 07:20:16 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 16 Jul 2025 07:20:16 GMT
Subject: RFR: 8356941: AbstractMethodError in HotSpot Due to Incorrect
 Handling of Private Method [v3]
In-Reply-To: <qyWNTs0IOlf128C4ZdvOp9TE7O4w7bPaz2hJfHseIUk=.4a298588-6aff-471a-927b-beb3c9f0b194@github.com>
References: <qyWNTs0IOlf128C4ZdvOp9TE7O4w7bPaz2hJfHseIUk=.4a298588-6aff-471a-927b-beb3c9f0b194@github.com>
Message-ID: <3e1yf3BEjmb_QhWGPVYtuejGRWP5T7pzFDXBs6WOi7w=.e1381a68-f6f5-4cb2-884e-6040edf8aadf@github.com>

> Private methods should never be considered as the implementation of a default method.
> 
> The first commit adds some additional logging I used to track down what was happening. I like it, but if reviewers think it too much I can drop it.
> 
> The second commit is the actual fix to exclude private methods, and adds the missing test case to the existing defmeth tests.
> 
> Testing:
>  - tiers 1-4
> 
> Thanks

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

  Revert "Additional logging to identify the problem"
  
  This reverts commit 60871844d32cbc58ea97b2186a2758e85613afa4.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26302/files
  - new: https://git.openjdk.org/jdk/pull/26302/files/b839daa1..704d6387

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

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

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

From shade at openjdk.org  Wed Jul 16 07:54:41 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 16 Jul 2025 07:54:41 GMT
Subject: RFR: 8362276: NMT tests should have locks for the entire tests
 [v2]
In-Reply-To: <eUfwdxT_5O7wrultyFab65P3CBv4deXsUN_S6mmBrm8=.577d0e24-f711-46f7-9cc3-40eeda6c8065@github.com>
References: <qQB1zCQqGIh5wPKBNEf2d7m49xfqOBwqUM0zOVcnlyQ=.8e32f46c-af0a-4ab8-a4a0-c23fa1474f28@github.com>
 <eUfwdxT_5O7wrultyFab65P3CBv4deXsUN_S6mmBrm8=.577d0e24-f711-46f7-9cc3-40eeda6c8065@github.com>
Message-ID: <YU1jZP-WCUJkXoSV8Jph11T9gxoDW9Szk6gpJC6bqR4=.fdadf963-e0a3-4743-a748-0164d89fc8ed@github.com>

On Tue, 15 Jul 2025 22:48:30 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> We restructure the code to make sure we cover the code that uses the global tree instance (but nothing else that uses the same lock internally) as needed:
>> 
>> - we move MemoryReserver::reserve() to the top to do as the first thing
>> - we grab the MemTracker::NmtVirtualMemoryLocker nvml
>> - do all the usual test stuff, including checking, which grabs the global instance of the tree
>> - we move remove_all() to the very bottom to do as the last thing
>> 
>> Testing: runnig Mach5 tier1-4 right now...
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restructure code to make sure we use the lock as needed

All right, this looks reasonable.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26324#pullrequestreview-3023633845

From syan at openjdk.org  Wed Jul 16 08:19:17 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 16 Jul 2025 08:19:17 GMT
Subject: RFR: 8359339: applications/jcstress tests should report
 SkippedException when can not resolve jcstress.jar
Message-ID: <wPkT2iwKdwNS3shCvYKaGlHT4IGxdooxD0vtqLa7l3Y=.d310f24c-6948-463a-815b-8a0b827e90f2@github.com>

Hi all,

I think it's more elegant that applications/jcstress tests report SkippedException when can not resolve jcstress.jar, rather than report  test failure. Change has been verified locally, test-fix only, no risk.

Tests:

- [x] Run test test/hotspot/jtreg/applications/jcstress/countdownlatch.java with -Djdk.test.lib.artifacts.jcstress-tests-all=/hygonjdk/yansendao/software/jdk/jcstress-tests-all-20241217-2035.jar, test run success as expected.
- [x] Run test test/hotspot/jtreg/applications/jcstress/countdownlatch.java without -Djdk.test.lib.artifacts.jcstress-tests-all=/hygonjdk/yansendao/software/jdk/jcstress-tests-all-20241217-2035.jar, test report shipped as expected.

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

Commit messages:
 - 8359339: applications/jcstress tests should report SkippedException when can not resolve jcstress.jar

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

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

From coleenp at openjdk.org  Wed Jul 16 11:19:41 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 16 Jul 2025 11:19:41 GMT
Subject: RFR: 8362276: NMT tests should have locks for the entire tests
 [v2]
In-Reply-To: <eUfwdxT_5O7wrultyFab65P3CBv4deXsUN_S6mmBrm8=.577d0e24-f711-46f7-9cc3-40eeda6c8065@github.com>
References: <qQB1zCQqGIh5wPKBNEf2d7m49xfqOBwqUM0zOVcnlyQ=.8e32f46c-af0a-4ab8-a4a0-c23fa1474f28@github.com>
 <eUfwdxT_5O7wrultyFab65P3CBv4deXsUN_S6mmBrm8=.577d0e24-f711-46f7-9cc3-40eeda6c8065@github.com>
Message-ID: <wZMlSaIjf_8tU8Z2rkrDlYAMh5tRb7iyE41_rEJHVio=.b6affdc1-57c7-41de-b36e-e702f8976ef3@github.com>

On Tue, 15 Jul 2025 22:48:30 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> We restructure the code to make sure we cover the code that uses the global tree instance (but nothing else that uses the same lock internally) as needed:
>> 
>> - we move MemoryReserver::reserve() to the top to do as the first thing
>> - we grab the MemTracker::NmtVirtualMemoryLocker nvml
>> - do all the usual test stuff, including checking, which grabs the global instance of the tree
>> - we move remove_all() to the very bottom to do as the last thing
>> 
>> Testing: runnig Mach5 tier1-4 right now...
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restructure code to make sure we use the lock as needed

test/hotspot/gtest/runtime/test_virtualMemoryTracker.cpp line 441:

> 439:     ReservedSpace rs = MemoryReserver::reserve(size, mtTest);
> 440: 
> 441:     RegionsTree* rtree = VirtualMemoryTracker::Instance::tree();

I have to confess to not paying attention to this change, but shouldn't you fetch the tree under the lock also?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26324#discussion_r2210054025

From shade at openjdk.org  Wed Jul 16 11:25:44 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 16 Jul 2025 11:25:44 GMT
Subject: RFR: 8362276: NMT tests should have locks for the entire tests
 [v2]
In-Reply-To: <wZMlSaIjf_8tU8Z2rkrDlYAMh5tRb7iyE41_rEJHVio=.b6affdc1-57c7-41de-b36e-e702f8976ef3@github.com>
References: <qQB1zCQqGIh5wPKBNEf2d7m49xfqOBwqUM0zOVcnlyQ=.8e32f46c-af0a-4ab8-a4a0-c23fa1474f28@github.com>
 <eUfwdxT_5O7wrultyFab65P3CBv4deXsUN_S6mmBrm8=.577d0e24-f711-46f7-9cc3-40eeda6c8065@github.com>
 <wZMlSaIjf_8tU8Z2rkrDlYAMh5tRb7iyE41_rEJHVio=.b6affdc1-57c7-41de-b36e-e702f8976ef3@github.com>
Message-ID: <zI_fct1OXUtiFTOyqvhp-4nINSeU1WkZ5KCuMiWhdn8=.ab2fcb45-beba-459f-afbc-80d9252f7999@github.com>

On Wed, 16 Jul 2025 11:17:27 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   restructure code to make sure we use the lock as needed
>
> test/hotspot/gtest/runtime/test_virtualMemoryTracker.cpp line 441:
> 
>> 439:     ReservedSpace rs = MemoryReserver::reserve(size, mtTest);
>> 440: 
>> 441:     RegionsTree* rtree = VirtualMemoryTracker::Instance::tree();
> 
> I have to confess to not paying attention to this change, but shouldn't you fetch the tree under the lock also?

I wondered the same, but this just returns an (unchanging) pointer. We are not in this locking game to ensure memory ordering, we only need mutual exclusion here. So IMO it does not matter for correctness whether we pull this under the lock or not.

Would be cleaner to do _everything_ under the lock, but this seems fine as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26324#discussion_r2210066296

From duke at openjdk.org  Wed Jul 16 12:21:51 2025
From: duke at openjdk.org (Anton Artemov)
Date: Wed, 16 Jul 2025 12:21:51 GMT
Subject: Withdrawn: 8359820: SIGILL with low -XX:HandshakeTimeout
In-Reply-To: <FZ87bVfDootrLeANGguMFpcTm7X8AEqzuKVQspmSkmE=.4484090b-ba49-498c-bb07-71d22fd34823@github.com>
References: <FZ87bVfDootrLeANGguMFpcTm7X8AEqzuKVQspmSkmE=.4484090b-ba49-498c-bb07-71d22fd34823@github.com>
Message-ID: <5douI4wu7Xm9fiwvEbA8F78cNF-GCdD3GppGeLZ7IVw=.93783fb2-0bfa-42d1-a5c8-dc37813a1b9f@github.com>

On Tue, 15 Jul 2025 08:37:38 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> we augment the SIGILL handling in `os::signal_thread` with proper logging so that the initial crash information goes to stdout/stderr as well. 
> 
> 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.
> 
> Tested in tiers 1-3.

This pull request has been closed without being integrated.

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

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

From coleenp at openjdk.org  Wed Jul 16 13:12:41 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 16 Jul 2025 13:12:41 GMT
Subject: RFR: 8362276: NMT tests should have locks for the entire tests
 [v2]
In-Reply-To: <eUfwdxT_5O7wrultyFab65P3CBv4deXsUN_S6mmBrm8=.577d0e24-f711-46f7-9cc3-40eeda6c8065@github.com>
References: <qQB1zCQqGIh5wPKBNEf2d7m49xfqOBwqUM0zOVcnlyQ=.8e32f46c-af0a-4ab8-a4a0-c23fa1474f28@github.com>
 <eUfwdxT_5O7wrultyFab65P3CBv4deXsUN_S6mmBrm8=.577d0e24-f711-46f7-9cc3-40eeda6c8065@github.com>
Message-ID: <wv--6nOM7O3xQNHCvqNFDkxjIgz3GyFCHtHGJgUokZI=.30fd62b6-2998-4e2d-b184-5c7955bc1168@github.com>

On Tue, 15 Jul 2025 22:48:30 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> We restructure the code to make sure we cover the code that uses the global tree instance (but nothing else that uses the same lock internally) as needed:
>> 
>> - we move MemoryReserver::reserve() to the top to do as the first thing
>> - we grab the MemTracker::NmtVirtualMemoryLocker nvml
>> - do all the usual test stuff, including checking, which grabs the global instance of the tree
>> - we move remove_all() to the very bottom to do as the last thing
>> 
>> Testing: runnig Mach5 tier1-4 right now...
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restructure code to make sure we use the lock as needed

This looks good.  Thank you for fixing the crash Gerard, and thank you for your attention to this bug Aleksey.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26324#pullrequestreview-3024929497

From coleenp at openjdk.org  Wed Jul 16 13:12:42 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 16 Jul 2025 13:12:42 GMT
Subject: RFR: 8362276: NMT tests should have locks for the entire tests
 [v2]
In-Reply-To: <zI_fct1OXUtiFTOyqvhp-4nINSeU1WkZ5KCuMiWhdn8=.ab2fcb45-beba-459f-afbc-80d9252f7999@github.com>
References: <qQB1zCQqGIh5wPKBNEf2d7m49xfqOBwqUM0zOVcnlyQ=.8e32f46c-af0a-4ab8-a4a0-c23fa1474f28@github.com>
 <eUfwdxT_5O7wrultyFab65P3CBv4deXsUN_S6mmBrm8=.577d0e24-f711-46f7-9cc3-40eeda6c8065@github.com>
 <wZMlSaIjf_8tU8Z2rkrDlYAMh5tRb7iyE41_rEJHVio=.b6affdc1-57c7-41de-b36e-e702f8976ef3@github.com>
 <zI_fct1OXUtiFTOyqvhp-4nINSeU1WkZ5KCuMiWhdn8=.ab2fcb45-beba-459f-afbc-80d9252f7999@github.com>
Message-ID: <MeEWGctVNU2ztzIoFArnt8uVvCRlIgk0BG9aelJIhdc=.6628461c-5075-4c81-8454-3601f6e09499@github.com>

On Wed, 16 Jul 2025 11:23:31 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> test/hotspot/gtest/runtime/test_virtualMemoryTracker.cpp line 441:
>> 
>>> 439:     ReservedSpace rs = MemoryReserver::reserve(size, mtTest);
>>> 440: 
>>> 441:     RegionsTree* rtree = VirtualMemoryTracker::Instance::tree();
>> 
>> I have to confess to not paying attention to this change, but shouldn't you fetch the tree under the lock also?
>
> I wondered the same, but this just returns an (unchanging) pointer. We are not in this locking game to ensure memory ordering, we only need mutual exclusion here. So IMO it does not matter for correctness whether we pull this under the lock or not.
> 
> Would be cleaner to do _everything_ under the lock, but this seems fine as well.

Okay, I see that too.  The code just made me wonder but it's okay.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26324#discussion_r2210381637

From coleenp at openjdk.org  Wed Jul 16 13:13:41 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 16 Jul 2025 13:13:41 GMT
Subject: RFR: 8356941: AbstractMethodError in HotSpot Due to Incorrect
 Handling of Private Method [v3]
In-Reply-To: <3e1yf3BEjmb_QhWGPVYtuejGRWP5T7pzFDXBs6WOi7w=.e1381a68-f6f5-4cb2-884e-6040edf8aadf@github.com>
References: <qyWNTs0IOlf128C4ZdvOp9TE7O4w7bPaz2hJfHseIUk=.4a298588-6aff-471a-927b-beb3c9f0b194@github.com>
 <3e1yf3BEjmb_QhWGPVYtuejGRWP5T7pzFDXBs6WOi7w=.e1381a68-f6f5-4cb2-884e-6040edf8aadf@github.com>
Message-ID: <rR7of5sKWHumUd83wV99HmZ2CwVWpHnzky1JHf3HpGQ=.60198381-bf2a-4930-95f3-8236fc01c609@github.com>

On Wed, 16 Jul 2025 07:20:16 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Private methods should never be considered as the implementation of a default method.
>> 
>> The first commit adds some additional logging I used to track down what was happening. I like it, but if reviewers think it too much I can drop it.
>> 
>> The second commit is the actual fix to exclude private methods, and adds the missing test case to the existing defmeth tests.
>> 
>> Testing:
>>  - tiers 1-4
>> 
>> Thanks
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Additional logging to identify the problem"
>   
>   This reverts commit 60871844d32cbc58ea97b2186a2758e85613afa4.

The fix looks good.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26302#pullrequestreview-3024410017

From coleenp at openjdk.org  Wed Jul 16 13:13:43 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 16 Jul 2025 13:13:43 GMT
Subject: RFR: 8356941: AbstractMethodError in HotSpot Due to Incorrect
 Handling of Private Method [v2]
In-Reply-To: <-3RNJiycRfcQauuARkAZtWcuppR2OCZMW1IJibmIjBE=.b4f4b136-4cc1-4c0d-a3ee-c9ad861f881f@github.com>
References: <qyWNTs0IOlf128C4ZdvOp9TE7O4w7bPaz2hJfHseIUk=.4a298588-6aff-471a-927b-beb3c9f0b194@github.com>
 <nWFZw1gF1fWToINRFmJOExarreQRkUba1Qm0Ho6y7RQ=.65917004-c8d2-4943-862c-66f0aec9ce5f@github.com>
 <YT53kii0W7BHT7JzhBLYcm0zpX4ED_ndpPKKqqJRXu0=.adfd659e-8ab6-4843-9405-24642f18df36@github.com>
 <-3RNJiycRfcQauuARkAZtWcuppR2OCZMW1IJibmIjBE=.b4f4b136-4cc1-4c0d-a3ee-c9ad861f881f@github.com>
Message-ID: <J4YcfcFLi5RsaLDv1WBzbETctRiQ7kABlR2hVwU3tfI=.1f08c20d-72b7-49c3-af58-91d7b057b58b@github.com>

On Wed, 16 Jul 2025 06:51:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/classfile/defaultMethods.cpp line 686:
>> 
>>> 684:           }
>>> 685:           Method* impl = klass->lookup_method(m->name(), m->signature());
>>> 686:           if (impl == nullptr || impl->is_overpass() || impl->is_static() || impl->is_private()) {
>> 
>> I still haven't figured out why this code fixes this issue, but why doesn't line 657 need the same change?
>
>> why doesn't line 657 need the same change?
> 
> Are you asking why it doesn't need the change to address the current bug? That would be because that block of code has nothing at all to do with the current bug. That block is looking at superclass overpass and static methods, to see if they may be candidates for replacing by a default method. For each of those methods it checks if there is an implementation in the current class that matches the name and sig and is a real method, and if so it doesn't create an empty vtable slot for it for default method processing to fill in. I spent a long time trying to create a scenario that would hit this block and the condition you want changed, but failed. Lets say we are looking at a slot for method `void m()` for simplicity. First you need a superclass that declares as static `void m()` method. Then you need a subclass that implements a non-static `void m()` method. But you also need to have the subclass implement an interface with a default `void m()` method, but in that case we will never
  reach the block of code because we will find that default method is already present in the list of miranda methods that we already processed! (During this phase of processing, default methods are considered mirandas - pass 1).
> 
> Now as to the actual fix ... we have a subclass that we are processing, and a superclass that has a private `void m()` method, and a super-super-interface that defines the default `void m()` method. We find `void m()` in the superclass's default methods - hence we reach the block of code I modified. For this slot to be processed  for default method handling (i.e. to get the correct entry so we invoke the true default method) we need to decide to create an empty vtable slot. The current logic (mirroring that for superclass methods - including the comment block that may or may not be accurate) checks to see if the current class has a concrete implementation of `void m()` as that would replace use of the default implementation (class instance methods "win"), except that is only true for non-private concrete implementations - a private class method is never considered the implementation of an interface method. So if the method is private we need to create the empty vtable slot - hence 
 the fix. 
> 
> Note that `klass->lookup_method` looks up the method in the current class and all superclasses, and will find overpass and private methods - so an alternative fix would be to change the lookup to skip private methods (and ...

I see why your fix fixes the bug in your test case.  I was asking about the block above with the identical comment and code.  Like you, I was trying to find a scenario where the block above your fix might also need the same condition added and couldn't find one.  Because if there's a private non-static function hiding a static function in a super class, the default method is then processed and will get the vtable slot added.
So your fix is good.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26302#discussion_r2210066182

From mbaesken at openjdk.org  Wed Jul 16 14:17:21 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 16 Jul 2025 14:17:21 GMT
Subject: RFR: 8360941: [ubsan] MemRegion::end() shows runtime error:
 applying non-zero offset 8388608 to null pointer [v2]
In-Reply-To: <LP6FbAxZpwbGf6lkNvLcSRSEOu-mYKjWGAJYBSIMcyk=.775595dc-7f73-4248-a235-f4b58933396b@github.com>
References: <LP6FbAxZpwbGf6lkNvLcSRSEOu-mYKjWGAJYBSIMcyk=.775595dc-7f73-4248-a235-f4b58933396b@github.com>
Message-ID: <p0EU9DnnjLz6iM0ZETE3tz4Suf_o0lrMBc7hRsy7PQ0=.d8134dec-0f25-444d-bec8-1ff6694f81cb@github.com>

> When running HS test
> gtest/GTestWrapper.java
> with ubsan-enabled binaries on macOS aarch64, the following error is reported (did not see this so far on Linux but there we use gcc and it seems the gcc/ubsan checks are a bit more limited).
> 
> test/hotspot/gtest/gc/g1/test_freeRegionList.cpp:37: Failure
> Death test: child_G1FreeRegionList_length_()
>     Result: died but not with expected exit code:
>             Terminated by signal 6 (core dumped)
> Actual msg:
> 
> [  DEATH   ] /jdk/src/hotspot/share/memory/memRegion.hpp:66:43: runtime error: applying non-zero offset 8388608 to null pointer
> [  DEATH   ]     #0 0x108afd6f4 in MemRegion::end() const+0x84 (libjvm.dylib:arm64+0x16556f4)
> [  DEATH   ]     #1 0x1075c68a0 in G1FreeRegionList_length_other_vm_Test::TestBody()+0x380 (libjvm.dylib:arm64+0x11e8a0)
> [  DEATH   ]     #2 0x1090f3bb0 in testing::Test::Run()+0xc0 (libjvm.dylib:arm64+0x1c4bbb0)
> [  DEATH   ]     #3 0x1090f4d94 in testing::TestInfo::Run()+0x1e4 (libjvm.dylib:arm64+0x1c4cd94)
> [  DEATH   ]     #4 0x1090f6754 in testing::TestSuite::Run()+0x43c (libjvm.dylib:arm64+0x1c4e754)
> [  DEATH   ]     #5 0x109103ca0 in testing::internal::UnitTestImpl::RunAllTests()+0x48c (libjvm.dylib:arm64+0x1c5bca0)
> [  DEATH   ]     #6 0x109103588 in testing::UnitTest::Run()+0x78 (libjvm.dylib:arm64+0x1c5b588)
> [  DEATH   ]     #7 0x1074a9ac0 in runUnitTestsInner(int, char**)+0x724 (libjvm.dylib:arm64+0x1ac0)
> [  DEATH   ]     #8 0x102dc3f18 in main+0x2c (gtestLauncher:arm64+0x100003f18)
> [  DEATH   ]     #9 0x196fea0dc  (<unknown module>)
> [  DEATH   ] 
> [  DEATH   ] SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /jdk/src/hotspot/share/memory/memRegion.hpp:66:43 in 
> [  DEATH   ] 
> 
> 
> 
> Seems the test_freeRegionList.cpp uses a special MemRegion starting at nullptr ; but this causes a bit of trouble when adding to start == nullptr .
> So far I see this issue just in the gtest, seems other MemRegion objects do not start at nullptr .

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

  Change the test, avoid using address 0

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26216/files
  - new: https://git.openjdk.org/jdk/pull/26216/files/e2407fd4..d31a4f39

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

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

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

From mbaesken at openjdk.org  Wed Jul 16 14:45:05 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 16 Jul 2025 14:45:05 GMT
Subject: RFR: 8360941: [ubsan] MemRegion::end() shows runtime error:
 applying non-zero offset 8388608 to null pointer [v3]
In-Reply-To: <LP6FbAxZpwbGf6lkNvLcSRSEOu-mYKjWGAJYBSIMcyk=.775595dc-7f73-4248-a235-f4b58933396b@github.com>
References: <LP6FbAxZpwbGf6lkNvLcSRSEOu-mYKjWGAJYBSIMcyk=.775595dc-7f73-4248-a235-f4b58933396b@github.com>
Message-ID: <z_rFgakOBZYIiEYpXJ7uUOSDKOJ6BCQDtxKwCf-rH7k=.cb4ff07e-b7e6-46ed-9fde-d73ebd117082@github.com>

> When running HS test
> gtest/GTestWrapper.java
> with ubsan-enabled binaries on macOS aarch64, the following error is reported (did not see this so far on Linux but there we use gcc and it seems the gcc/ubsan checks are a bit more limited).
> 
> test/hotspot/gtest/gc/g1/test_freeRegionList.cpp:37: Failure
> Death test: child_G1FreeRegionList_length_()
>     Result: died but not with expected exit code:
>             Terminated by signal 6 (core dumped)
> Actual msg:
> 
> [  DEATH   ] /jdk/src/hotspot/share/memory/memRegion.hpp:66:43: runtime error: applying non-zero offset 8388608 to null pointer
> [  DEATH   ]     #0 0x108afd6f4 in MemRegion::end() const+0x84 (libjvm.dylib:arm64+0x16556f4)
> [  DEATH   ]     #1 0x1075c68a0 in G1FreeRegionList_length_other_vm_Test::TestBody()+0x380 (libjvm.dylib:arm64+0x11e8a0)
> [  DEATH   ]     #2 0x1090f3bb0 in testing::Test::Run()+0xc0 (libjvm.dylib:arm64+0x1c4bbb0)
> [  DEATH   ]     #3 0x1090f4d94 in testing::TestInfo::Run()+0x1e4 (libjvm.dylib:arm64+0x1c4cd94)
> [  DEATH   ]     #4 0x1090f6754 in testing::TestSuite::Run()+0x43c (libjvm.dylib:arm64+0x1c4e754)
> [  DEATH   ]     #5 0x109103ca0 in testing::internal::UnitTestImpl::RunAllTests()+0x48c (libjvm.dylib:arm64+0x1c5bca0)
> [  DEATH   ]     #6 0x109103588 in testing::UnitTest::Run()+0x78 (libjvm.dylib:arm64+0x1c5b588)
> [  DEATH   ]     #7 0x1074a9ac0 in runUnitTestsInner(int, char**)+0x724 (libjvm.dylib:arm64+0x1ac0)
> [  DEATH   ]     #8 0x102dc3f18 in main+0x2c (gtestLauncher:arm64+0x100003f18)
> [  DEATH   ]     #9 0x196fea0dc  (<unknown module>)
> [  DEATH   ] 
> [  DEATH   ] SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /jdk/src/hotspot/share/memory/memRegion.hpp:66:43 in 
> [  DEATH   ] 
> 
> 
> 
> Seems the test_freeRegionList.cpp uses a special MemRegion starting at nullptr ; but this causes a bit of trouble when adding to start == nullptr .
> So far I see this issue just in the gtest, seems other MemRegion objects do not start at nullptr .

Matthias Baesken has updated the pull request incrementally with two additional commits since the last revision:

 - blank
 - blank

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26216/files
  - new: https://git.openjdk.org/jdk/pull/26216/files/d31a4f39..f325d877

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

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

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

From mbaesken at openjdk.org  Wed Jul 16 14:45:06 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 16 Jul 2025 14:45:06 GMT
Subject: RFR: 8360941: [ubsan] MemRegion::end() shows runtime error:
 applying non-zero offset 8388608 to null pointer [v2]
In-Reply-To: <p0EU9DnnjLz6iM0ZETE3tz4Suf_o0lrMBc7hRsy7PQ0=.d8134dec-0f25-444d-bec8-1ff6694f81cb@github.com>
References: <LP6FbAxZpwbGf6lkNvLcSRSEOu-mYKjWGAJYBSIMcyk=.775595dc-7f73-4248-a235-f4b58933396b@github.com>
 <p0EU9DnnjLz6iM0ZETE3tz4Suf_o0lrMBc7hRsy7PQ0=.d8134dec-0f25-444d-bec8-1ff6694f81cb@github.com>
Message-ID: <toG8tkBbYG_WbB_AlM64WmfifSz02CDdyCvwRZ1IN7o=.3de23e5c-7230-44fb-9645-eb3d21b3e516@github.com>

On Wed, 16 Jul 2025 14:17:21 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When running HS test
>> gtest/GTestWrapper.java
>> with ubsan-enabled binaries on macOS aarch64, the following error is reported (did not see this so far on Linux but there we use gcc and it seems the gcc/ubsan checks are a bit more limited).
>> 
>> test/hotspot/gtest/gc/g1/test_freeRegionList.cpp:37: Failure
>> Death test: child_G1FreeRegionList_length_()
>>     Result: died but not with expected exit code:
>>             Terminated by signal 6 (core dumped)
>> Actual msg:
>> 
>> [  DEATH   ] /jdk/src/hotspot/share/memory/memRegion.hpp:66:43: runtime error: applying non-zero offset 8388608 to null pointer
>> [  DEATH   ]     #0 0x108afd6f4 in MemRegion::end() const+0x84 (libjvm.dylib:arm64+0x16556f4)
>> [  DEATH   ]     #1 0x1075c68a0 in G1FreeRegionList_length_other_vm_Test::TestBody()+0x380 (libjvm.dylib:arm64+0x11e8a0)
>> [  DEATH   ]     #2 0x1090f3bb0 in testing::Test::Run()+0xc0 (libjvm.dylib:arm64+0x1c4bbb0)
>> [  DEATH   ]     #3 0x1090f4d94 in testing::TestInfo::Run()+0x1e4 (libjvm.dylib:arm64+0x1c4cd94)
>> [  DEATH   ]     #4 0x1090f6754 in testing::TestSuite::Run()+0x43c (libjvm.dylib:arm64+0x1c4e754)
>> [  DEATH   ]     #5 0x109103ca0 in testing::internal::UnitTestImpl::RunAllTests()+0x48c (libjvm.dylib:arm64+0x1c5bca0)
>> [  DEATH   ]     #6 0x109103588 in testing::UnitTest::Run()+0x78 (libjvm.dylib:arm64+0x1c5b588)
>> [  DEATH   ]     #7 0x1074a9ac0 in runUnitTestsInner(int, char**)+0x724 (libjvm.dylib:arm64+0x1ac0)
>> [  DEATH   ]     #8 0x102dc3f18 in main+0x2c (gtestLauncher:arm64+0x100003f18)
>> [  DEATH   ]     #9 0x196fea0dc  (<unknown module>)
>> [  DEATH   ] 
>> [  DEATH   ] SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /jdk/src/hotspot/share/memory/memRegion.hpp:66:43 in 
>> [  DEATH   ] 
>> 
>> 
>> 
>> Seems the test_freeRegionList.cpp uses a special MemRegion starting at nullptr ; but this causes a bit of trouble when adding to start == nullptr .
>> So far I see this issue just in the gtest, seems other MemRegion objects do not start at nullptr .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change the test, avoid using address 0

I adjusted the test and took 'some other address than null' .

And removed the cast from the header.

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

PR Comment: https://git.openjdk.org/jdk/pull/26216#issuecomment-3078911767

From mbaesken at openjdk.org  Wed Jul 16 14:45:06 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 16 Jul 2025 14:45:06 GMT
Subject: RFR: 8360941: [ubsan] MemRegion::end() shows runtime error:
 applying non-zero offset 8388608 to null pointer [v3]
In-Reply-To: <0dYbgQyQ4pS1i9v1SeMQFdp6rnRMfc4KkpkyMzYjX_U=.d200d56c-54b5-47f0-96d7-1d0fda9d3d44@github.com>
References: <LP6FbAxZpwbGf6lkNvLcSRSEOu-mYKjWGAJYBSIMcyk=.775595dc-7f73-4248-a235-f4b58933396b@github.com>
 <IjDrghHxj_L_e82A6KtgeLFWdsGqhRiLMvjNFrDbdv0=.09cc4e0d-9a0d-4ef8-8439-21061af473a7@github.com>
 <0dYbgQyQ4pS1i9v1SeMQFdp6rnRMfc4KkpkyMzYjX_U=.d200d56c-54b5-47f0-96d7-1d0fda9d3d44@github.com>
Message-ID: <M3TjSad_jgaGHBJID8ty2fXvPoKnz_ekBInM7LdPff4=.0ee88c02-eea8-4ca4-bb5e-2d12c71df290@github.com>

On Fri, 11 Jul 2025 17:25:50 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> src/hotspot/share/memory/memRegion.hpp line 67:
>> 
>>> 65:   HeapWord* start() const { return _start; }
>>> 66:   // in the gtests we call end() with a _start == nullptr so adjust the addition to avoid ub
>>> 67:   HeapWord* end() const   { return reinterpret_cast<HeapWord*>(reinterpret_cast<uintptr_t>(_start) + (_word_size * sizeof(HeapWord))); }
>> 
>> I don't think this change should be made. Instead, fix the offending test.  The fake heap it creates starts
>> at null, but I think it could be anywhere, because nothing touches it.
>
> If it did (or does) need to be valid memory, then just allocate a chunk of
> native memory for this fake heap for the test. That might be the safer thing
> to do anyway, in case some future change leads to the fake region getting
> touched.

> I don't think this change should be made. Instead, fix the offending test. The fake heap it creates starts at null, but I think it could be anywhere, because nothing touches it.

Let's do it this way !

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26216#discussion_r2210636582

From gziemski at openjdk.org  Wed Jul 16 15:30:47 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Wed, 16 Jul 2025 15:30:47 GMT
Subject: RFR: 8362276: NMT tests should have locks for the entire tests
 [v2]
In-Reply-To: <eUfwdxT_5O7wrultyFab65P3CBv4deXsUN_S6mmBrm8=.577d0e24-f711-46f7-9cc3-40eeda6c8065@github.com>
References: <qQB1zCQqGIh5wPKBNEf2d7m49xfqOBwqUM0zOVcnlyQ=.8e32f46c-af0a-4ab8-a4a0-c23fa1474f28@github.com>
 <eUfwdxT_5O7wrultyFab65P3CBv4deXsUN_S6mmBrm8=.577d0e24-f711-46f7-9cc3-40eeda6c8065@github.com>
Message-ID: <-QgAoOp8KW3R_4ZKl8sX8TbWe77YKPTgTT4AklS3zdg=.f7341293-e2e1-41ec-b5f7-175df1a9df01@github.com>

On Tue, 15 Jul 2025 22:48:30 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> We restructure the code to make sure we cover the code that uses the global tree instance (but nothing else that uses the same lock internally) as needed:
>> 
>> - we move MemoryReserver::reserve() to the top to do as the first thing
>> - we grab the MemTracker::NmtVirtualMemoryLocker nvml
>> - do all the usual test stuff, including checking, which grabs the global instance of the tree
>> - we move remove_all() to the very bottom to do as the last thing
>> 
>> Testing: passes Mach5 tier1-4
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restructure code to make sure we use the lock as needed

Thank you for the feedback and reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/26324#issuecomment-3079145856

From gziemski at openjdk.org  Wed Jul 16 15:30:48 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Wed, 16 Jul 2025 15:30:48 GMT
Subject: Integrated: 8362276: NMT tests should have locks for the entire tests
In-Reply-To: <qQB1zCQqGIh5wPKBNEf2d7m49xfqOBwqUM0zOVcnlyQ=.8e32f46c-af0a-4ab8-a4a0-c23fa1474f28@github.com>
References: <qQB1zCQqGIh5wPKBNEf2d7m49xfqOBwqUM0zOVcnlyQ=.8e32f46c-af0a-4ab8-a4a0-c23fa1474f28@github.com>
Message-ID: <nIQdaoaSveG1DuJPrzfG29zmIG81R3_ETVHcLrNuRSM=.ec23f2b8-2c92-4fa8-8f72-f42c06a60ffd@github.com>

On Tue, 15 Jul 2025 16:14:52 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> We restructure the code to make sure we cover the code that uses the global tree instance (but nothing else that uses the same lock internally) as needed:
> 
> - we move MemoryReserver::reserve() to the top to do as the first thing
> - we grab the MemTracker::NmtVirtualMemoryLocker nvml
> - do all the usual test stuff, including checking, which grabs the global instance of the tree
> - we move remove_all() to the very bottom to do as the last thing
> 
> Testing: passes Mach5 tier1-4

This pull request has now been integrated.

Changeset: 10ae6029
Author:    Gerard Ziemski <gziemski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/10ae6029444c1381f7b1b3dcb6b6f32a4ae57efa
Stats:     31 lines in 1 file changed: 17 ins; 13 del; 1 mod

8362276: NMT tests should have locks for the entire tests

Reviewed-by: shade, coleenp

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

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

From iklam at openjdk.org  Wed Jul 16 15:33:41 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 16 Jul 2025 15:33:41 GMT
Subject: RFR: 8362336: Revert changes in metaspaceShared.cpp done via
 JDK-8356807
In-Reply-To: <jrW7L06iBIzAYx-2e3Bi7ZJmXtDWmjoM0cXFd0-4fvM=.ba6aacfa-5103-4adf-b217-966bc3e62797@github.com>
References: <jrW7L06iBIzAYx-2e3Bi7ZJmXtDWmjoM0cXFd0-4fvM=.ba6aacfa-5103-4adf-b217-966bc3e62797@github.com>
Message-ID: <14jhRbFzlsJl31LBMyqofacvfYk6Y8gWh-wIsUJPDJE=.dc9b78a1-ab8a-482a-a8ca-b55d7803a24c@github.com>

On Wed, 16 Jul 2025 06:26:48 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> The changes in `metaspaceShared.cpp` for JDK-8356807 is causing bootcycle prebuilt failures. Therefore, reverting those changes.
> 
> Testing: tiers 1 - 3, builds-tier4.

Looks good and qualifies as a Trivial fix.

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

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26344#pullrequestreview-3025602592

From ccheung at openjdk.org  Wed Jul 16 16:07:44 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 16 Jul 2025 16:07:44 GMT
Subject: RFR: 8362336: Revert changes in metaspaceShared.cpp done via
 JDK-8356807
In-Reply-To: <14jhRbFzlsJl31LBMyqofacvfYk6Y8gWh-wIsUJPDJE=.dc9b78a1-ab8a-482a-a8ca-b55d7803a24c@github.com>
References: <jrW7L06iBIzAYx-2e3Bi7ZJmXtDWmjoM0cXFd0-4fvM=.ba6aacfa-5103-4adf-b217-966bc3e62797@github.com>
 <14jhRbFzlsJl31LBMyqofacvfYk6Y8gWh-wIsUJPDJE=.dc9b78a1-ab8a-482a-a8ca-b55d7803a24c@github.com>
Message-ID: <RqmPugWDTpIjYRZ-EBipcB5TmQfbSOqilEggKPRlgV8=.86cbd7a0-4260-44ec-8973-ab6faf03bd25@github.com>

On Wed, 16 Jul 2025 15:30:49 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The changes in `metaspaceShared.cpp` for JDK-8356807 is causing bootcycle prebuilt failures. Therefore, reverting those changes.
>> 
>> Testing: tiers 1 - 3, builds-tier4.
>
> Looks good and qualifies as a Trivial fix.

Thanks @iklam for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/26344#issuecomment-3079275067

From ccheung at openjdk.org  Wed Jul 16 16:07:44 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 16 Jul 2025 16:07:44 GMT
Subject: Integrated: 8362336: Revert changes in metaspaceShared.cpp done via
 JDK-8356807
In-Reply-To: <jrW7L06iBIzAYx-2e3Bi7ZJmXtDWmjoM0cXFd0-4fvM=.ba6aacfa-5103-4adf-b217-966bc3e62797@github.com>
References: <jrW7L06iBIzAYx-2e3Bi7ZJmXtDWmjoM0cXFd0-4fvM=.ba6aacfa-5103-4adf-b217-966bc3e62797@github.com>
Message-ID: <Hjc-bZrOyFyHLVQNovEm0GbYJvQxbyX2bDsRxbKXcLE=.7afe4fc9-c9df-43c1-a353-eb84fffa7684@github.com>

On Wed, 16 Jul 2025 06:26:48 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> The changes in `metaspaceShared.cpp` for JDK-8356807 is causing bootcycle prebuilt failures. Therefore, reverting those changes.
> 
> Testing: tiers 1 - 3, builds-tier4.

This pull request has now been integrated.

Changeset: 8193856a
Author:    Calvin Cheung <ccheung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8193856af8546332bfa180cb45154a4093b4fd2c
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8362336: Revert changes in metaspaceShared.cpp done via JDK-8356807

Reviewed-by: iklam

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

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

From dholmes at openjdk.org  Wed Jul 16 20:53:41 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 16 Jul 2025 20:53:41 GMT
Subject: RFR: 8356941: AbstractMethodError in HotSpot Due to Incorrect
 Handling of Private Method [v3]
In-Reply-To: <rR7of5sKWHumUd83wV99HmZ2CwVWpHnzky1JHf3HpGQ=.60198381-bf2a-4930-95f3-8236fc01c609@github.com>
References: <qyWNTs0IOlf128C4ZdvOp9TE7O4w7bPaz2hJfHseIUk=.4a298588-6aff-471a-927b-beb3c9f0b194@github.com>
 <3e1yf3BEjmb_QhWGPVYtuejGRWP5T7pzFDXBs6WOi7w=.e1381a68-f6f5-4cb2-884e-6040edf8aadf@github.com>
 <rR7of5sKWHumUd83wV99HmZ2CwVWpHnzky1JHf3HpGQ=.60198381-bf2a-4930-95f3-8236fc01c609@github.com>
Message-ID: <tjNP74ot5enGctN9uvfy-YSY1pnCiWciuLmaqNSB_oc=.9648acb7-1e3c-4b94-ba57-823dee182340@github.com>

On Wed, 16 Jul 2025 13:10:58 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert "Additional logging to identify the problem"
>>   
>>   This reverts commit 60871844d32cbc58ea97b2186a2758e85613afa4.
>
> The fix looks good.

Thanks for the review @coleenp !

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

PR Comment: https://git.openjdk.org/jdk/pull/26302#issuecomment-3080593082

From dholmes at openjdk.org  Wed Jul 16 21:35:03 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 16 Jul 2025 21:35:03 GMT
Subject: RFR: 8360048: NMT crash in gtest/NMTGtests.java: fatal error: NMT
 corruption: Block at 0x0000017748307120: header canary broken [v2]
In-Reply-To: <yJEDxwa52f-71mm4eVPtbHtlxRHmCbG5QwHGkZ3zrvU=.873c3938-da7a-4b4e-b1d4-1859799ac7e8@github.com>
References: <gUIff3tC7KO9caTbRleaxcqvTLekIpCVqMu2Gbey19U=.9182d797-acee-4596-8bb6-3d36397c31c7@github.com>
 <yJEDxwa52f-71mm4eVPtbHtlxRHmCbG5QwHGkZ3zrvU=.873c3938-da7a-4b4e-b1d4-1859799ac7e8@github.com>
Message-ID: <bqh4FA5WL-gVQb-4QltFT-NZHkWumYDuOl3rSOxM8Ig=.65542438-743f-4fd3-90bb-9e889b03830d@github.com>

On Mon, 14 Jul 2025 20:56:16 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This is a clone of https://github.com/openjdk/jdk/pull/25950 that we need to get integrated ASAP.
>> 
>> ---
>> 
>> 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.
>> 
>> ---
>> 
>> I'm re-testing with tiers 1-4
>
> David Holmes has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update test/hotspot/gtest/runtime/test_virtualMemoryTracker.cpp
>    
>    Co-authored-by: Aleksey Shipil?v <shipilev at amazon.de>
>  - Update src/hotspot/share/nmt/virtualMemoryTracker.cpp
>    
>    Co-authored-by: Aleksey Shipil?v <shipilev at amazon.de>

Closing this PR and returning control to Afshin and Gerard. The main issue we thought this would address was JDK-8361752 but that is a separate issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/26284#issuecomment-3081026274

From dholmes at openjdk.org  Wed Jul 16 21:35:04 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 16 Jul 2025 21:35:04 GMT
Subject: Withdrawn: 8360048: NMT crash in gtest/NMTGtests.java: fatal error:
 NMT corruption: Block at 0x0000017748307120: header canary broken
In-Reply-To: <gUIff3tC7KO9caTbRleaxcqvTLekIpCVqMu2Gbey19U=.9182d797-acee-4596-8bb6-3d36397c31c7@github.com>
References: <gUIff3tC7KO9caTbRleaxcqvTLekIpCVqMu2Gbey19U=.9182d797-acee-4596-8bb6-3d36397c31c7@github.com>
Message-ID: <K0UG-6l0lOmITr5vZ1RcxMkMLwrWO5vcJLLYp2AxQrw=.be79e4f2-08f6-4387-a3d4-2c4024a27b46@github.com>

On Mon, 14 Jul 2025 02:53:53 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This is a clone of https://github.com/openjdk/jdk/pull/25950 that we need to get integrated ASAP.
> 
> ---
> 
> 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.
> 
> ---
> 
> I'm re-testing with tiers 1-4

This pull request has been closed without being integrated.

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

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

From dholmes at openjdk.org  Thu Jul 17 01:08:49 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 17 Jul 2025 01:08:49 GMT
Subject: RFR: 8359339: applications/jcstress tests should report
 SkippedException when can not resolve jcstress.jar
In-Reply-To: <wPkT2iwKdwNS3shCvYKaGlHT4IGxdooxD0vtqLa7l3Y=.d310f24c-6948-463a-815b-8a0b827e90f2@github.com>
References: <wPkT2iwKdwNS3shCvYKaGlHT4IGxdooxD0vtqLa7l3Y=.d310f24c-6948-463a-815b-8a0b827e90f2@github.com>
Message-ID: <wVOVBNuGsD_ZmZidEzL5EupyydGqKM9nmnEvd5xez2M=.aea7dde8-e6e8-40f1-aca4-253bc05a6250@github.com>

On Wed, 16 Jul 2025 08:02:42 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> I think it's more elegant that applications/jcstress tests report SkippedException when can not resolve jcstress.jar, rather than report  test failure. Change has been verified locally, test-fix only, no risk.
> 
> Tests:
> 
> - [x] Run test test/hotspot/jtreg/applications/jcstress/countdownlatch.java with -Djdk.test.lib.artifacts.jcstress-tests-all=/hygonjdk/yansendao/software/jdk/jcstress-tests-all-20241217-2035.jar, test run success as expected.
> - [x] Run test test/hotspot/jtreg/applications/jcstress/countdownlatch.java without -Djdk.test.lib.artifacts.jcstress-tests-all=/hygonjdk/yansendao/software/jdk/jcstress-tests-all-20241217-2035.jar, test report shipped as expected.

I don't agree. If the jar is not found then you have a configuration/setup error. You need to know that. An Error makes you aware of the problem. Skipping won't be noticed unless you analyze SkippedException the same way you analyze errors - in which case just keep it an error.

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

PR Comment: https://git.openjdk.org/jdk/pull/26345#issuecomment-3082023810

From amitkumar at openjdk.org  Thu Jul 17 04:33:01 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Thu, 17 Jul 2025 04:33:01 GMT
Subject: RFR: 8330606: Redefinition doesn't but should verify the new klass
 [v3]
In-Reply-To: <QTz1M2nrFeExBl3PCQ1NhvJvjQf1gq30GkfI1fnfze8=.a20665b7-8b3a-4bf1-8f57-8c93874a8a7c@github.com>
References: <pxpFAGJcpI2NQjude2t70BPMmIl6rT3s3JUoi-MV3WQ=.eddb6a6f-6ee3-4592-a1ee-74c6200fad31@github.com>
 <il4KXlFgg1WhYmKowy3o_WOv6JJm1WY_Jek3_fs_rbA=.bf263451-182d-4cd9-8a37-371974c1dc2d@github.com>
 <QTz1M2nrFeExBl3PCQ1NhvJvjQf1gq30GkfI1fnfze8=.a20665b7-8b3a-4bf1-8f57-8c93874a8a7c@github.com>
Message-ID: <YnsULIIrxSD1oW9NT3tRaAVLCKxTsUptw6peh24NDsI=.487f9b97-b3ec-4503-877c-4176b5f1fee2@github.com>

On Thu, 6 Feb 2025 18:41:12 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>  It might be that you need to add some nop() bytecode or something to generate the code attribute?

@coleenp This seems like a valid solution. By the way, can we modify this testcase in OpenJDK or should the OpenJ9 team make the change in their repository. Which one do you suggest ?

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

PR Comment: https://git.openjdk.org/jdk/pull/22116#issuecomment-3082452043

From mbaesken at openjdk.org  Thu Jul 17 07:24:51 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 17 Jul 2025 07:24:51 GMT
Subject: RFR: 8360941: [ubsan] MemRegion::end() shows runtime error:
 applying non-zero offset 8388608 to null pointer [v3]
In-Reply-To: <z_rFgakOBZYIiEYpXJ7uUOSDKOJ6BCQDtxKwCf-rH7k=.cb4ff07e-b7e6-46ed-9fde-d73ebd117082@github.com>
References: <LP6FbAxZpwbGf6lkNvLcSRSEOu-mYKjWGAJYBSIMcyk=.775595dc-7f73-4248-a235-f4b58933396b@github.com>
 <z_rFgakOBZYIiEYpXJ7uUOSDKOJ6BCQDtxKwCf-rH7k=.cb4ff07e-b7e6-46ed-9fde-d73ebd117082@github.com>
Message-ID: <KZr9Cm2PqbqHpd1FnvRqFigJqpWyhzP1YTS0GBlMNw4=.cee0c48f-f322-41fe-b87b-0c7f26ad34a5@github.com>

On Wed, 16 Jul 2025 14:45:05 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When running HS test
>> gtest/GTestWrapper.java
>> with ubsan-enabled binaries on macOS aarch64, the following error is reported (did not see this so far on Linux but there we use gcc and it seems the gcc/ubsan checks are a bit more limited).
>> 
>> test/hotspot/gtest/gc/g1/test_freeRegionList.cpp:37: Failure
>> Death test: child_G1FreeRegionList_length_()
>>     Result: died but not with expected exit code:
>>             Terminated by signal 6 (core dumped)
>> Actual msg:
>> 
>> [  DEATH   ] /jdk/src/hotspot/share/memory/memRegion.hpp:66:43: runtime error: applying non-zero offset 8388608 to null pointer
>> [  DEATH   ]     #0 0x108afd6f4 in MemRegion::end() const+0x84 (libjvm.dylib:arm64+0x16556f4)
>> [  DEATH   ]     #1 0x1075c68a0 in G1FreeRegionList_length_other_vm_Test::TestBody()+0x380 (libjvm.dylib:arm64+0x11e8a0)
>> [  DEATH   ]     #2 0x1090f3bb0 in testing::Test::Run()+0xc0 (libjvm.dylib:arm64+0x1c4bbb0)
>> [  DEATH   ]     #3 0x1090f4d94 in testing::TestInfo::Run()+0x1e4 (libjvm.dylib:arm64+0x1c4cd94)
>> [  DEATH   ]     #4 0x1090f6754 in testing::TestSuite::Run()+0x43c (libjvm.dylib:arm64+0x1c4e754)
>> [  DEATH   ]     #5 0x109103ca0 in testing::internal::UnitTestImpl::RunAllTests()+0x48c (libjvm.dylib:arm64+0x1c5bca0)
>> [  DEATH   ]     #6 0x109103588 in testing::UnitTest::Run()+0x78 (libjvm.dylib:arm64+0x1c5b588)
>> [  DEATH   ]     #7 0x1074a9ac0 in runUnitTestsInner(int, char**)+0x724 (libjvm.dylib:arm64+0x1ac0)
>> [  DEATH   ]     #8 0x102dc3f18 in main+0x2c (gtestLauncher:arm64+0x100003f18)
>> [  DEATH   ]     #9 0x196fea0dc  (<unknown module>)
>> [  DEATH   ] 
>> [  DEATH   ] SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /jdk/src/hotspot/share/memory/memRegion.hpp:66:43 in 
>> [  DEATH   ] 
>> 
>> 
>> 
>> Seems the test_freeRegionList.cpp uses a special MemRegion starting at nullptr ; but this causes a bit of trouble when adding to start == nullptr .
>> So far I see this issue just in the gtest, seems other MemRegion objects do not start at nullptr .
>
> Matthias Baesken has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - blank
>  - blank

Taking 'some other address' than nullptr / 0  as suggested  just fails  (I worked yesterday with opt build where no failure was seen).
But fastdebug leads to this assert  , any ideas  ?
Or suggestions for a 'better' address  (!= 0) that works ?


#  Internal Error (/openjdk-jdk-dev-linux_aarch64-dbg/jdk/src/hotspot/share/gc/g1/g1HeapRegion.cpp:254), pid=1541642, tid=1541642
#  assert(Universe::on_page_boundary(mr.start()) && Universe::on_page_boundary(mr.end())) failed: invalid space boundaries
#
# Problematic frame:
# V  [libjvm.so+0x110d75c]  G1HeapRegion::G1HeapRegion(unsigned int, G1BlockOffsetTable*, MemRegion, G1CardSetConfiguration*)+0x158
#

---------------  T H R E A D  ---------------

Current thread (0x0000c8cccb63ed40):  JavaThread "main"             [_thread_in_native, id=1541642, stack(0x0000ffffeb8e0000,0x0000ffffebade000) (2040K)]

Stack: [0x0000ffffeb8e0000,0x0000ffffebade000],  sp=0x0000ffffebadc6c0,  free space=2033k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x110d75c]  G1HeapRegion::G1HeapRegion(unsigned int, G1BlockOffsetTable*, MemRegion, G1CardSetConfiguration*)+0x158  (g1HeapRegion.cpp:254)
V  [libjvm.so+0x5a235c]  test_G1FreeRegionList_length_()+0x20c  (test_freeRegionList.cpp:75)
V  [libjvm.so+0x5a29cc]  G1FreeRegionList_length_other_vm_Test::TestBody()+0x32c  (test_freeRegionList.cpp:37)
V  [libjvm.so+0x2075298]  testing::Test::Run()+0xe4  (gtest.cc:2670)
V  [libjvm.so+0x2075424]  testing::TestInfo::Run()+0x170  (gtest.cc:2836)
V  [libjvm.so+0x2075710]  testing::TestSuite::Run()+0x2d0  (gtest.cc:3015)
V  [libjvm.so+0x2081774]  testing::internal::UnitTestImpl::RunAllTests()+0x360  (gtest.cc:5920)
V  [libjvm.so+0x207506c]  testing::UnitTest::Run()+0x7c  (gtest.cc:2670)
V  [libjvm.so+0x45c31c]  runUnitTestsInner(int, char**)+0x3fc  (gtest.h:2317)
C  [gtestLauncher+0x7c0]  main+0x1c  (gtestLauncher.cpp:40)
C  [libc.so.6+0x284c4]
C  [libc.so.6+0x28598]  __libc_start_main+0x98

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

PR Comment: https://git.openjdk.org/jdk/pull/26216#issuecomment-3082910474

From mbaesken at openjdk.org  Thu Jul 17 08:05:49 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 17 Jul 2025 08:05:49 GMT
Subject: RFR: 8360941: [ubsan] MemRegion::end() shows runtime error:
 applying non-zero offset 8388608 to null pointer [v3]
In-Reply-To: <z_rFgakOBZYIiEYpXJ7uUOSDKOJ6BCQDtxKwCf-rH7k=.cb4ff07e-b7e6-46ed-9fde-d73ebd117082@github.com>
References: <LP6FbAxZpwbGf6lkNvLcSRSEOu-mYKjWGAJYBSIMcyk=.775595dc-7f73-4248-a235-f4b58933396b@github.com>
 <z_rFgakOBZYIiEYpXJ7uUOSDKOJ6BCQDtxKwCf-rH7k=.cb4ff07e-b7e6-46ed-9fde-d73ebd117082@github.com>
Message-ID: <IBHIO8A_NcZT_OzlH5PR2uKjSG3VF0jzOTTLUQ5V9eQ=.9e4fcb2d-2930-4e06-b33a-2093f061d812@github.com>

On Wed, 16 Jul 2025 14:45:05 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When running HS test
>> gtest/GTestWrapper.java
>> with ubsan-enabled binaries on macOS aarch64, the following error is reported (did not see this so far on Linux but there we use gcc and it seems the gcc/ubsan checks are a bit more limited).
>> 
>> test/hotspot/gtest/gc/g1/test_freeRegionList.cpp:37: Failure
>> Death test: child_G1FreeRegionList_length_()
>>     Result: died but not with expected exit code:
>>             Terminated by signal 6 (core dumped)
>> Actual msg:
>> 
>> [  DEATH   ] /jdk/src/hotspot/share/memory/memRegion.hpp:66:43: runtime error: applying non-zero offset 8388608 to null pointer
>> [  DEATH   ]     #0 0x108afd6f4 in MemRegion::end() const+0x84 (libjvm.dylib:arm64+0x16556f4)
>> [  DEATH   ]     #1 0x1075c68a0 in G1FreeRegionList_length_other_vm_Test::TestBody()+0x380 (libjvm.dylib:arm64+0x11e8a0)
>> [  DEATH   ]     #2 0x1090f3bb0 in testing::Test::Run()+0xc0 (libjvm.dylib:arm64+0x1c4bbb0)
>> [  DEATH   ]     #3 0x1090f4d94 in testing::TestInfo::Run()+0x1e4 (libjvm.dylib:arm64+0x1c4cd94)
>> [  DEATH   ]     #4 0x1090f6754 in testing::TestSuite::Run()+0x43c (libjvm.dylib:arm64+0x1c4e754)
>> [  DEATH   ]     #5 0x109103ca0 in testing::internal::UnitTestImpl::RunAllTests()+0x48c (libjvm.dylib:arm64+0x1c5bca0)
>> [  DEATH   ]     #6 0x109103588 in testing::UnitTest::Run()+0x78 (libjvm.dylib:arm64+0x1c5b588)
>> [  DEATH   ]     #7 0x1074a9ac0 in runUnitTestsInner(int, char**)+0x724 (libjvm.dylib:arm64+0x1ac0)
>> [  DEATH   ]     #8 0x102dc3f18 in main+0x2c (gtestLauncher:arm64+0x100003f18)
>> [  DEATH   ]     #9 0x196fea0dc  (<unknown module>)
>> [  DEATH   ] 
>> [  DEATH   ] SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /jdk/src/hotspot/share/memory/memRegion.hpp:66:43 in 
>> [  DEATH   ] 
>> 
>> 
>> 
>> Seems the test_freeRegionList.cpp uses a special MemRegion starting at nullptr ; but this causes a bit of trouble when adding to start == nullptr .
>> So far I see this issue just in the gtest, seems other MemRegion objects do not start at nullptr .
>
> Matthias Baesken has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - blank
>  - blank

@tschatzl , maybe you have a good suggestion for an address ?
Using  0 / nullptr
`MemRegion heap(nullptr, num_regions_in_test * G1HeapRegion::GrainWords);`
leads to undefined behaviour because we add to address 0 (and adjusting the HS coding for this is a bit ugly and was not liked).
But the new address used by me in the current commit triggers the assert above .

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

PR Comment: https://git.openjdk.org/jdk/pull/26216#issuecomment-3083042043

From syan at openjdk.org  Thu Jul 17 08:46:58 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 17 Jul 2025 08:46:58 GMT
Subject: RFR: 8359339: applications/jcstress tests should report
 SkippedException when can not resolve jcstress.jar
In-Reply-To: <wVOVBNuGsD_ZmZidEzL5EupyydGqKM9nmnEvd5xez2M=.aea7dde8-e6e8-40f1-aca4-253bc05a6250@github.com>
References: <wPkT2iwKdwNS3shCvYKaGlHT4IGxdooxD0vtqLa7l3Y=.d310f24c-6948-463a-815b-8a0b827e90f2@github.com>
 <wVOVBNuGsD_ZmZidEzL5EupyydGqKM9nmnEvd5xez2M=.aea7dde8-e6e8-40f1-aca4-253bc05a6250@github.com>
Message-ID: <NWknkm7-8WQ8FHC5ve_wrJEUUl31Mm3ppOQxBejXd7w=.7a328307-464f-4130-98f9-557c2f7d0edd@github.com>

On Thu, 17 Jul 2025 01:05:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I don't agree. If the jar is not found then you have a configuration/setup error. You need to know that. An Error makes you aware of the problem. Skipping won't be noticed unless you analyze SkippedException the same way you analyze errors - in which case just keep it an error.

Thanks @dholmes-ora. I think you are right, I will close this PR and the issue as 'not a issue'

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

PR Comment: https://git.openjdk.org/jdk/pull/26345#issuecomment-3083188881

From syan at openjdk.org  Thu Jul 17 08:46:58 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 17 Jul 2025 08:46:58 GMT
Subject: Withdrawn: 8359339: applications/jcstress tests should report
 SkippedException when can not resolve jcstress.jar
In-Reply-To: <wPkT2iwKdwNS3shCvYKaGlHT4IGxdooxD0vtqLa7l3Y=.d310f24c-6948-463a-815b-8a0b827e90f2@github.com>
References: <wPkT2iwKdwNS3shCvYKaGlHT4IGxdooxD0vtqLa7l3Y=.d310f24c-6948-463a-815b-8a0b827e90f2@github.com>
Message-ID: <NbXP-cCjDcZvACtDVAzkJRvuCBmaGakfGCBWm6B59Lg=.2a822050-9937-4843-8c97-a17bd74be3eb@github.com>

On Wed, 16 Jul 2025 08:02:42 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> I think it's more elegant that applications/jcstress tests report SkippedException when can not resolve jcstress.jar, rather than report  test failure. Change has been verified locally, test-fix only, no risk.
> 
> Tests:
> 
> - [x] Run test test/hotspot/jtreg/applications/jcstress/countdownlatch.java with -Djdk.test.lib.artifacts.jcstress-tests-all=/hygonjdk/yansendao/software/jdk/jcstress-tests-all-20241217-2035.jar, test run success as expected.
> - [x] Run test test/hotspot/jtreg/applications/jcstress/countdownlatch.java without -Djdk.test.lib.artifacts.jcstress-tests-all=/hygonjdk/yansendao/software/jdk/jcstress-tests-all-20241217-2035.jar, test report shipped as expected.

This pull request has been closed without being integrated.

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

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

From syan at openjdk.org  Thu Jul 17 09:42:03 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 17 Jul 2025 09:42:03 GMT
Subject: RFR: 8359339: applications/jcstress tests should report
 SkippedException when can not resolve jcstress.jar
In-Reply-To: <wPkT2iwKdwNS3shCvYKaGlHT4IGxdooxD0vtqLa7l3Y=.d310f24c-6948-463a-815b-8a0b827e90f2@github.com>
References: <wPkT2iwKdwNS3shCvYKaGlHT4IGxdooxD0vtqLa7l3Y=.d310f24c-6948-463a-815b-8a0b827e90f2@github.com>
Message-ID: <NzRsU06n23pSMs-14ZExtrJqqBDrcbDhpP_2U9PwPE8=.7cf3f902-19cc-41d0-80b2-ea530fa7686d@github.com>

On Wed, 16 Jul 2025 08:02:42 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> I think it's more elegant that applications/jcstress tests report SkippedException when can not resolve jcstress.jar, rather than report  test failure. Change has been verified locally, test-fix only, no risk.
> 
> Tests:
> 
> - [x] Run test test/hotspot/jtreg/applications/jcstress/countdownlatch.java with -Djdk.test.lib.artifacts.jcstress-tests-all=/hygonjdk/yansendao/software/jdk/jcstress-tests-all-20241217-2035.jar, test run success as expected.
> - [x] Run test test/hotspot/jtreg/applications/jcstress/countdownlatch.java without -Djdk.test.lib.artifacts.jcstress-tests-all=/hygonjdk/yansendao/software/jdk/jcstress-tests-all-20241217-2035.jar, test report shipped as expected.

But I found that there is no document to say how to run the application/jcstress tests, Should we update the file test/hotspot/jtreg/applications/jcstress/README

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

PR Comment: https://git.openjdk.org/jdk/pull/26345#issuecomment-3083367073

From sspitsyn at openjdk.org  Thu Jul 17 10:17:25 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 17 Jul 2025 10:17:25 GMT
Subject: RFR: 8306324: StopThread results in thread being marked as
 interrupted, leading to unexpected InterruptedException
Message-ID: <sDAklD-arV33IpWiJwMkwUfNPMAmsr5cgboU4y0hjhk=.192cd7e5-f2a2-4b5c-83a9-5111bf1926ec@github.com>

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`

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

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

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

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

From stuefe at openjdk.org  Thu Jul 17 11:37:57 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 17 Jul 2025 11:37:57 GMT
Subject: RFR: 8359339: applications/jcstress tests should report
 SkippedException when can not resolve jcstress.jar
In-Reply-To: <NzRsU06n23pSMs-14ZExtrJqqBDrcbDhpP_2U9PwPE8=.7cf3f902-19cc-41d0-80b2-ea530fa7686d@github.com>
References: <wPkT2iwKdwNS3shCvYKaGlHT4IGxdooxD0vtqLa7l3Y=.d310f24c-6948-463a-815b-8a0b827e90f2@github.com>
 <NzRsU06n23pSMs-14ZExtrJqqBDrcbDhpP_2U9PwPE8=.7cf3f902-19cc-41d0-80b2-ea530fa7686d@github.com>
Message-ID: <ZNJm-TVdCWv5XVxeTavuy1Q2s_XsLu71zHsAP7YYH4k=.4b27ed5e-e1d9-4650-845f-96f854222dc7@github.com>

On Thu, 17 Jul 2025 09:39:14 GMT, SendaoYan <syan at openjdk.org> wrote:

> But I found that there is no document to say how to run the application/jcstress tests, Should we update the file test/hotspot/jtreg/applications/jcstress/README

Sure, that would be useful.

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

PR Comment: https://git.openjdk.org/jdk/pull/26345#issuecomment-3083719955

From coleenp at openjdk.org  Thu Jul 17 12:05:49 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 17 Jul 2025 12:05:49 GMT
Subject: [jdk25] RFR: 8358004: Delete applications/scimark/Scimark.java
 test
In-Reply-To: <sZMOLVpuyS1bMiVSRvuzMK35bivA3q4PckpIVRQqccE=.fbcde97f-397e-490a-a5bf-137d02f5e3fc@github.com>
References: <sZMOLVpuyS1bMiVSRvuzMK35bivA3q4PckpIVRQqccE=.fbcde97f-397e-490a-a5bf-137d02f5e3fc@github.com>
Message-ID: <JJm-GnM7bUyUxaK9JPr-c98KLsVz7gXRbsmOCKWyEXI=.df63cfcd-1b62-4d81-9c1c-0155eca22be4@github.com>

On Wed, 16 Jul 2025 02:42:25 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [a5c9bc70](https://github.com/openjdk/jdk/commit/a5c9bc70324693e9d0b25bb2c51b91dfc750c453) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The Scimark is not maintained, this backport PR remove this useless tests which cause test failure. Test-fix only, no risk.
> 
> The commit being backported was authored by Leonid Mesnik on 16 Jul 2025 and was reviewed by SendaoYan and Coleen Phillimore.
> 
> Thanks!

Looks good.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26338#pullrequestreview-3029231200

From dholmes at openjdk.org  Thu Jul 17 12:15:50 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 17 Jul 2025 12:15:50 GMT
Subject: RFR: 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: <uWAOnbQcLHa_mWTvu2tCl7S-zm2JEFxhKSRiES58b24=.7b2363b9-e5e0-46b9-8060-91cdec5754df@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`

I need to dive into the code tomorrow but I can't help think that doing an actual interrupt is not really what is needed, we just need to unpark the thread if it is blocked ...

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

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

From syan at openjdk.org  Thu Jul 17 12:37:29 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 17 Jul 2025 12:37:29 GMT
Subject: RFR: 8362501: Update test/hotspot/jtreg/applications/jcstress/README
Message-ID: <Gv-CfzN4MbQDSvKMkXs6DWllE9saxTpkjIh92W8GkK4=.04b9e256-42cb-48de-a8e0-2345cdbc8b78@github.com>

Hi all,

Currently, this is no documentation on how to run the application/jcstress tests. I think it will be useful to complement the document test/hotspot/jtreg/applications/jcstress/README on how to run the jcstress tests in jtreg.

No behaviour has been change, only update the ducumentation, no risk.

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

Commit messages:
 - remove tmp
 - update
 - 8362501: Update test/hotspot/jtreg/applications/jcstress/README

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

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

From coleenp at openjdk.org  Thu Jul 17 12:39:51 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 17 Jul 2025 12:39:51 GMT
Subject: RFR: 8360555: Archive all unnamed modules in CDS full module graph
In-Reply-To: <wShFgP1f2myBNCuyVnLXYiB1PEBQlkW5VcyIDmyeoRo=.fff71539-455b-4109-8f9c-81c2e16d0bc0@github.com>
References: <wShFgP1f2myBNCuyVnLXYiB1PEBQlkW5VcyIDmyeoRo=.fff71539-455b-4109-8f9c-81c2e16d0bc0@github.com>
Message-ID: <aTs018gQ4ULkVAXdGUZiX-g7gKJkHEbMjKCob8i9FYA=.208a442c-52dc-4569-9c27-596fd1f94121@github.com>

On Wed, 2 Jul 2025 00:18:28 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The CDS full module graph is supposed to contain a snapshot of the boot layer, which has 3 unnamed modules for the boot, platform and system class loaders. Each unnamed module is represented by a `java.lang.Module` Java object and a `ModuleEntry` C++ object.
> 
> Currently, we archive only the `java.lang.Module` for the platform and system loaders. The other 4 objects are dynamically created in the production run while executing Java bytecodes during VM bootstrap.
> 
> With this PR, we archive all of the above 6 objects when `CDSConfig::is_dumping_full_module_graph()` is true.
> 
> This is required for [JDK-8350550](https://bugs.openjdk.org/browse/JDK-8350550), as we need the `java.lang.Module` object for archived classes in the unnamed module of the boot loader prior to executing any Java code.
> 
> We also archive the `ModuleEntry` objects for the 3 unnamed modules for uniformity, as these objects are already archived for named modules.

src/hotspot/share/classfile/modules.cpp line 777:

> 775:   if (CDSConfig::is_using_full_module_graph()) {
> 776:     precond(unnamed_module == ClassLoaderDataShared::archived_boot_unnamed_module());
> 777:     unnamed_module->restore_archived_oops(boot_loader_data);

If you're restoring the module oop from the archive, what is the module oop passed into this that the rest of the code is using?

src/java.base/share/classes/jdk/internal/loader/BootLoader.java line 71:

> 69:         }
> 70:         jla.addEnableNativeAccess(UNNAMED_MODULE);
> 71:         setBootLoaderUnnamedModule0(UNNAMED_MODULE);

Here it's being called.  Should this be called?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26082#discussion_r2213207332
PR Review Comment: https://git.openjdk.org/jdk/pull/26082#discussion_r2213222965

From coleenp at openjdk.org  Thu Jul 17 12:39:52 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 17 Jul 2025 12:39:52 GMT
Subject: RFR: 8360555: Archive all unnamed modules in CDS full module graph
In-Reply-To: <aTs018gQ4ULkVAXdGUZiX-g7gKJkHEbMjKCob8i9FYA=.208a442c-52dc-4569-9c27-596fd1f94121@github.com>
References: <wShFgP1f2myBNCuyVnLXYiB1PEBQlkW5VcyIDmyeoRo=.fff71539-455b-4109-8f9c-81c2e16d0bc0@github.com>
 <aTs018gQ4ULkVAXdGUZiX-g7gKJkHEbMjKCob8i9FYA=.208a442c-52dc-4569-9c27-596fd1f94121@github.com>
Message-ID: <I6QtmOydf5-vfixmLTwYX2aO6cEM_GUjNaxnAELfFDs=.4ffabffc-a01a-4d7e-8b3a-26deac5120c6@github.com>

On Thu, 17 Jul 2025 12:29:39 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The CDS full module graph is supposed to contain a snapshot of the boot layer, which has 3 unnamed modules for the boot, platform and system class loaders. Each unnamed module is represented by a `java.lang.Module` Java object and a `ModuleEntry` C++ object.
>> 
>> Currently, we archive only the `java.lang.Module` for the platform and system loaders. The other 4 objects are dynamically created in the production run while executing Java bytecodes during VM bootstrap.
>> 
>> With this PR, we archive all of the above 6 objects when `CDSConfig::is_dumping_full_module_graph()` is true.
>> 
>> This is required for [JDK-8350550](https://bugs.openjdk.org/browse/JDK-8350550), as we need the `java.lang.Module` object for archived classes in the unnamed module of the boot loader prior to executing any Java code.
>> 
>> We also archive the `ModuleEntry` objects for the 3 unnamed modules for uniformity, as these objects are already archived for named modules.
>
> src/hotspot/share/classfile/modules.cpp line 777:
> 
>> 775:   if (CDSConfig::is_using_full_module_graph()) {
>> 776:     precond(unnamed_module == ClassLoaderDataShared::archived_boot_unnamed_module());
>> 777:     unnamed_module->restore_archived_oops(boot_loader_data);
> 
> If you're restoring the module oop from the archive, what is the module oop passed into this that the rest of the code is using?

If you're storing the unnamed module oop in the archive should this method not be called?  If it is, what are you saving by archiving the unnamed module?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26082#discussion_r2213221120

From syan at openjdk.org  Thu Jul 17 12:45:00 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 17 Jul 2025 12:45:00 GMT
Subject: [jdk25] RFR: 8358004: Delete applications/scimark/Scimark.java
 test
In-Reply-To: <JJm-GnM7bUyUxaK9JPr-c98KLsVz7gXRbsmOCKWyEXI=.df63cfcd-1b62-4d81-9c1c-0155eca22be4@github.com>
References: <sZMOLVpuyS1bMiVSRvuzMK35bivA3q4PckpIVRQqccE=.fbcde97f-397e-490a-a5bf-137d02f5e3fc@github.com>
 <JJm-GnM7bUyUxaK9JPr-c98KLsVz7gXRbsmOCKWyEXI=.df63cfcd-1b62-4d81-9c1c-0155eca22be4@github.com>
Message-ID: <C75LyV7N0sGmO1HmoChcheorVymiBNaXiqmhBhcB-NA=.1fc10d97-94f0-4f88-99e0-90f193751440@github.com>

On Thu, 17 Jul 2025 12:03:29 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Looks good.

Thanks for the reviews. @coleenp

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

PR Comment: https://git.openjdk.org/jdk/pull/26338#issuecomment-3083920028

From syan at openjdk.org  Thu Jul 17 12:45:01 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 17 Jul 2025 12:45:01 GMT
Subject: [jdk25] Integrated: 8358004: Delete applications/scimark/Scimark.java
 test
In-Reply-To: <sZMOLVpuyS1bMiVSRvuzMK35bivA3q4PckpIVRQqccE=.fbcde97f-397e-490a-a5bf-137d02f5e3fc@github.com>
References: <sZMOLVpuyS1bMiVSRvuzMK35bivA3q4PckpIVRQqccE=.fbcde97f-397e-490a-a5bf-137d02f5e3fc@github.com>
Message-ID: <wRwPL4r8f4KobI4TzGTcQ1yySnPAk8531hvh3nIczNM=.70125543-6ce4-4f08-9305-48369ebb91f7@github.com>

On Wed, 16 Jul 2025 02:42:25 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [a5c9bc70](https://github.com/openjdk/jdk/commit/a5c9bc70324693e9d0b25bb2c51b91dfc750c453) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The Scimark is not maintained, this backport PR remove this useless tests which cause test failure. Test-fix only, no risk.
> 
> The commit being backported was authored by Leonid Mesnik on 16 Jul 2025 and was reviewed by SendaoYan and Coleen Phillimore.
> 
> Thanks!

This pull request has now been integrated.

Changeset: f1f6452e
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f1f6452e01e5a4521cb333d7456333f00cd9680c
Stats:     58 lines in 1 file changed: 0 ins; 58 del; 0 mod

8358004: Delete applications/scimark/Scimark.java test

Reviewed-by: coleenp
Backport-of: a5c9bc70324693e9d0b25bb2c51b91dfc750c453

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

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

From syan at openjdk.org  Thu Jul 17 12:45:55 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 17 Jul 2025 12:45:55 GMT
Subject: RFR: 8359339: applications/jcstress tests should report
 SkippedException when can not resolve jcstress.jar
In-Reply-To: <ZNJm-TVdCWv5XVxeTavuy1Q2s_XsLu71zHsAP7YYH4k=.4b27ed5e-e1d9-4650-845f-96f854222dc7@github.com>
References: <wPkT2iwKdwNS3shCvYKaGlHT4IGxdooxD0vtqLa7l3Y=.d310f24c-6948-463a-815b-8a0b827e90f2@github.com>
 <NzRsU06n23pSMs-14ZExtrJqqBDrcbDhpP_2U9PwPE8=.7cf3f902-19cc-41d0-80b2-ea530fa7686d@github.com>
 <ZNJm-TVdCWv5XVxeTavuy1Q2s_XsLu71zHsAP7YYH4k=.4b27ed5e-e1d9-4650-845f-96f854222dc7@github.com>
Message-ID: <rcS91_b6HFYHMCjrVWg34IY1fvwQQcCQHLmwcJgbPNY=.437b440c-6600-4ff1-9548-d6003b04165e@github.com>

On Thu, 17 Jul 2025 11:35:32 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > But I found that there is no document to say how to run the application/jcstress tests, Should we update the file test/hotspot/jtreg/applications/jcstress/README
> 
> Sure, that would be useful.

I have created a new PR https://github.com/openjdk/jdk/pull/26369 to update the document.

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

PR Comment: https://git.openjdk.org/jdk/pull/26345#issuecomment-3083930107

From duke at openjdk.org  Thu Jul 17 14:08:24 2025
From: duke at openjdk.org (Anton Artemov)
Date: Thu, 17 Jul 2025 14:08:24 GMT
Subject: RFR: 8359820: Improve handshake/safepoint timeout diagnostic
 messages [v2]
In-Reply-To: <FZ87bVfDootrLeANGguMFpcTm7X8AEqzuKVQspmSkmE=.4484090b-ba49-498c-bb07-71d22fd34823@github.com>
References: <FZ87bVfDootrLeANGguMFpcTm7X8AEqzuKVQspmSkmE=.4484090b-ba49-498c-bb07-71d22fd34823@github.com>
Message-ID: <CgMbxpMEiIMeTFuQW3VERXmZprNLiKhmUBuJPd2HF5c=.46f5f5d7-4cd3-4d44-bfff-4ce9adcfd707@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 pull request now contains eight commits:

 - Merge remote-tracking branch 'origin/master' into JDK-8359820-SIGILL-with-low-handshake-timeout-on-intel-sde
 - 8359820: Fixed test
 - 8359820: Removed extra line
 - Merge branch 'JDK-8359820-SIGILL-with-low-handshake-timeout-on-intel-sde' of https://github.com/toxaart/jdk into JDK-8359820-SIGILL-with-low-handshake-timeout-on-intel-sde
 - Merge remote-tracking branch 'origin/master' into JDK-8359820-SIGILL-with-low-handshake-timeout-on-intel-sde
 - 8359820:  Improved safepoint and handshake timeout report
 - 8359820: Fixed newline
 - 8359820: Explicitly report SIGILL fired by handshake timeout handler in VMError::report()

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

Changes: https://git.openjdk.org/jdk/pull/26309/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26309&range=01
  Stats: 21 lines in 5 files changed: 19 ins; 0 del; 2 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 kbarrett at openjdk.org  Thu Jul 17 14:38:48 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 17 Jul 2025 14:38:48 GMT
Subject: RFR: 8360941: [ubsan] MemRegion::end() shows runtime error:
 applying non-zero offset 8388608 to null pointer [v3]
In-Reply-To: <KZr9Cm2PqbqHpd1FnvRqFigJqpWyhzP1YTS0GBlMNw4=.cee0c48f-f322-41fe-b87b-0c7f26ad34a5@github.com>
References: <LP6FbAxZpwbGf6lkNvLcSRSEOu-mYKjWGAJYBSIMcyk=.775595dc-7f73-4248-a235-f4b58933396b@github.com>
 <z_rFgakOBZYIiEYpXJ7uUOSDKOJ6BCQDtxKwCf-rH7k=.cb4ff07e-b7e6-46ed-9fde-d73ebd117082@github.com>
 <KZr9Cm2PqbqHpd1FnvRqFigJqpWyhzP1YTS0GBlMNw4=.cee0c48f-f322-41fe-b87b-0c7f26ad34a5@github.com>
Message-ID: <D1ytKUYjTiUjOhqBcuft_xat-TFfoJ4S4aZToidnhoQ=.424be11c-e883-459d-afe1-395ebf1ff600@github.com>

On Thu, 17 Jul 2025 07:22:18 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Taking 'some other address' than nullptr / 0 as suggested just fails (I worked yesterday with opt build where no failure was seen). But fastdebug leads to this assert , any ideas ? Or suggestions for a 'better' address (!= 0) that works ?

It needs to be at least page-aligned.  I'm not finding any other alignment requirement just now, but there might
be a minimum region alignment that is more restrictive than page-aligned that I'm forgetting and haven't found.

So `align_up(addr, os::vm_page_size())` may work.

The other likely alignment possibility is `G1HeapRegion::GrainWord * BytesPerWord`.

I still think allocating the space might be safer.  So os::malloc space for one more region than the test calls for, and
align the result up to GrainWord alignment.

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

PR Comment: https://git.openjdk.org/jdk/pull/26216#issuecomment-3083940896

From alanb at openjdk.org  Thu Jul 17 14:44:48 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 17 Jul 2025 14:44:48 GMT
Subject: RFR: 8306324: StopThread results in thread being marked as
 interrupted, leading to unexpected InterruptedException
In-Reply-To: <uWAOnbQcLHa_mWTvu2tCl7S-zm2JEFxhKSRiES58b24=.7b2363b9-e5e0-46b9-8060-91cdec5754df@github.com>
References: <sDAklD-arV33IpWiJwMkwUfNPMAmsr5cgboU4y0hjhk=.192cd7e5-f2a2-4b5c-83a9-5111bf1926ec@github.com>
 <uWAOnbQcLHa_mWTvu2tCl7S-zm2JEFxhKSRiES58b24=.7b2363b9-e5e0-46b9-8060-91cdec5754df@github.com>
Message-ID: <NJGW-SVl7WpY8DhVC0As0zKMYY6jFSkjKLM8mn30pms=.a673c07b-ca4e-4813-bded-9ae06dcaaddb@github.com>

On Thu, 17 Jul 2025 12:13:22 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I need to dive into the code tomorrow but I can't help think that doing an actual interrupt is not really what is needed, we just need to unpark the thread if it is blocked ...

I think we also need to step back and write down examples of where JVMTI StopThread is useful. The main use-case may be in the debugger where is suspended at a breakpoint and the user wants to throw an exception to exercise some code path and exception handling. So I think it may be less about wakeup. Also if the target thread is in Object.wait then it can't continue until it re-enters the monitor so it's never been guaranteed to wakeup immediately. Although it may be unpalatable, I think we should look at having StopThread fail in these cases.

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

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

From mbaesken at openjdk.org  Thu Jul 17 15:41:30 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 17 Jul 2025 15:41:30 GMT
Subject: RFR: 8360941: [ubsan] MemRegion::end() shows runtime error:
 applying non-zero offset 8388608 to null pointer [v4]
In-Reply-To: <LP6FbAxZpwbGf6lkNvLcSRSEOu-mYKjWGAJYBSIMcyk=.775595dc-7f73-4248-a235-f4b58933396b@github.com>
References: <LP6FbAxZpwbGf6lkNvLcSRSEOu-mYKjWGAJYBSIMcyk=.775595dc-7f73-4248-a235-f4b58933396b@github.com>
Message-ID: <jpNR9jM5WVyQ9iNR4rGc0GCaGTVXB75wxUVXVGb6GGg=.6ca2dd58-fb93-4ff5-b513-b17de9816f54@github.com>

> When running HS test
> gtest/GTestWrapper.java
> with ubsan-enabled binaries on macOS aarch64, the following error is reported (did not see this so far on Linux but there we use gcc and it seems the gcc/ubsan checks are a bit more limited).
> 
> test/hotspot/gtest/gc/g1/test_freeRegionList.cpp:37: Failure
> Death test: child_G1FreeRegionList_length_()
>     Result: died but not with expected exit code:
>             Terminated by signal 6 (core dumped)
> Actual msg:
> 
> [  DEATH   ] /jdk/src/hotspot/share/memory/memRegion.hpp:66:43: runtime error: applying non-zero offset 8388608 to null pointer
> [  DEATH   ]     #0 0x108afd6f4 in MemRegion::end() const+0x84 (libjvm.dylib:arm64+0x16556f4)
> [  DEATH   ]     #1 0x1075c68a0 in G1FreeRegionList_length_other_vm_Test::TestBody()+0x380 (libjvm.dylib:arm64+0x11e8a0)
> [  DEATH   ]     #2 0x1090f3bb0 in testing::Test::Run()+0xc0 (libjvm.dylib:arm64+0x1c4bbb0)
> [  DEATH   ]     #3 0x1090f4d94 in testing::TestInfo::Run()+0x1e4 (libjvm.dylib:arm64+0x1c4cd94)
> [  DEATH   ]     #4 0x1090f6754 in testing::TestSuite::Run()+0x43c (libjvm.dylib:arm64+0x1c4e754)
> [  DEATH   ]     #5 0x109103ca0 in testing::internal::UnitTestImpl::RunAllTests()+0x48c (libjvm.dylib:arm64+0x1c5bca0)
> [  DEATH   ]     #6 0x109103588 in testing::UnitTest::Run()+0x78 (libjvm.dylib:arm64+0x1c5b588)
> [  DEATH   ]     #7 0x1074a9ac0 in runUnitTestsInner(int, char**)+0x724 (libjvm.dylib:arm64+0x1ac0)
> [  DEATH   ]     #8 0x102dc3f18 in main+0x2c (gtestLauncher:arm64+0x100003f18)
> [  DEATH   ]     #9 0x196fea0dc  (<unknown module>)
> [  DEATH   ] 
> [  DEATH   ] SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /jdk/src/hotspot/share/memory/memRegion.hpp:66:43 in 
> [  DEATH   ] 
> 
> 
> 
> Seems the test_freeRegionList.cpp uses a special MemRegion starting at nullptr ; but this causes a bit of trouble when adding to start == nullptr .
> So far I see this issue just in the gtest, seems other MemRegion objects do not start at nullptr .

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

  Avoid assertions, align address in test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26216/files
  - new: https://git.openjdk.org/jdk/pull/26216/files/f325d877..842077ad

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

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

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

From pchilanomate at openjdk.org  Thu Jul 17 16:37:50 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 17 Jul 2025 16:37:50 GMT
Subject: RFR: 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: <FP7dEg2yA4qYU0pADEjBsbLMo_qfh9aCS7p6BC2irZg=.8a762fd5-58a7-4386-a68a-49c6d3a863ae@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`

I also don?t see the purpose of setting the interrupted flag if all we want is for the target to wake up if it?s in one of the blocking calls. From the 3 cases in `JavaThread::interrupt()`, the only one where I see setting that flag is needed is for `Thread.sleep` because we check it to bail out, otherwise we would just keep sleeping for the remaining time. But maybe we could also add a `has_async_exception_condition()` check to bailout.

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

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

From gziemski at openjdk.org  Thu Jul 17 18:41:59 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Thu, 17 Jul 2025 18:41:59 GMT
Subject: RFR: 8362276: NMT tests should have locks for the entire tests
 [v2]
In-Reply-To: <eUfwdxT_5O7wrultyFab65P3CBv4deXsUN_S6mmBrm8=.577d0e24-f711-46f7-9cc3-40eeda6c8065@github.com>
References: <qQB1zCQqGIh5wPKBNEf2d7m49xfqOBwqUM0zOVcnlyQ=.8e32f46c-af0a-4ab8-a4a0-c23fa1474f28@github.com>
 <eUfwdxT_5O7wrultyFab65P3CBv4deXsUN_S6mmBrm8=.577d0e24-f711-46f7-9cc3-40eeda6c8065@github.com>
Message-ID: <ut75nG0CGcNwM0Kz6t76lSCcWSiPfl8yHEcJZYDe368=.cf4bb076-9730-46a6-8ca4-9f0937361209@github.com>

On Tue, 15 Jul 2025 22:48:30 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> We restructure the code to make sure we cover the code that uses the global tree instance (but nothing else that uses the same lock internally) as needed:
>> 
>> - we move MemoryReserver::reserve() to the top to do as the first thing
>> - we grab the MemTracker::NmtVirtualMemoryLocker nvml
>> - do all the usual test stuff, including checking, which grabs the global instance of the tree
>> - we move remove_all() to the very bottom to do as the last thing
>> 
>> Testing: passes Mach5 tier1-4
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restructure code to make sure we use the lock as needed

slash-backport :jdk25

/backport:jdk25

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

PR Comment: https://git.openjdk.org/jdk/pull/26324#issuecomment-3085057440
PR Comment: https://git.openjdk.org/jdk/pull/26324#issuecomment-3085061076

From iklam at openjdk.org  Thu Jul 17 22:43:48 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 17 Jul 2025 22:43:48 GMT
Subject: RFR: 8360555: Archive all unnamed modules in CDS full module graph
In-Reply-To: <I6QtmOydf5-vfixmLTwYX2aO6cEM_GUjNaxnAELfFDs=.4ffabffc-a01a-4d7e-8b3a-26deac5120c6@github.com>
References: <wShFgP1f2myBNCuyVnLXYiB1PEBQlkW5VcyIDmyeoRo=.fff71539-455b-4109-8f9c-81c2e16d0bc0@github.com>
 <aTs018gQ4ULkVAXdGUZiX-g7gKJkHEbMjKCob8i9FYA=.208a442c-52dc-4569-9c27-596fd1f94121@github.com>
 <I6QtmOydf5-vfixmLTwYX2aO6cEM_GUjNaxnAELfFDs=.4ffabffc-a01a-4d7e-8b3a-26deac5120c6@github.com>
Message-ID: <dwrToo7aFLg6SgqDSaYQkYvh-TPXWND7wZacVfp2QAY=.8420ecbe-362b-46a6-b583-4e5497b3c287@github.com>

On Thu, 17 Jul 2025 12:35:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/classfile/modules.cpp line 777:
>> 
>>> 775:   if (CDSConfig::is_using_full_module_graph()) {
>>> 776:     precond(unnamed_module == ClassLoaderDataShared::archived_boot_unnamed_module());
>>> 777:     unnamed_module->restore_archived_oops(boot_loader_data);
>> 
>> If you're restoring the module oop from the archive, what is the module oop passed into this that the rest of the code is using?
>
> If you're storing the unnamed module oop in the archive should this method not be called?  If it is, what are you saving by archiving the unnamed module?

The callstack is:


jdk.internal.loader.BootLoader.setBootLoaderUnnamedModule0(java.base at 26-internal/Native Method)
jdk.internal.loader.BootLoader.<clinit>(java.base at 26-internal/BootLoader.java:71)
jdk.internal.module.ModuleBootstrap.boot(java.base at 26-internal/ModuleBootstrap.java:162)
java.lang.System.initPhase2(java.base at 26-internal/System.java:1932)


Both the Java code and the native code have a handle to this unnamed module oop. The `precond` checks that they indeed are pointing the same oop.

Also, even though the oop is archived, we still need to set up some native states inside the `unnamed_module->restore_archived_oops(boot_loader_data)` call. E.g., set up the `OopHandle` that binds the oop to the `ModuleEntry`.

---------------
> what are you saving by archiving the unnamed module?

It's for [JDK-8350550](https://bugs.openjdk.org/browse/JDK-8350550)) -- I want to be able to reference the unnamed module before executing any Java code, so that archived classes can be loaded at the very beginning of `vmClasses::resolve_all()`. See my draft PR: https://github.com/openjdk/jdk/pull/26375

---------------
Currently, we still execute a lot of Java code when setting up the archived module graph (inside `ModuleBootstrap.boot()`. I am working on a way to enable the archived module graph without executing any Java code (which will be a few REFs after [JDK-8350550](https://bugs.openjdk.org/browse/JDK-8350550)), so this call will eventually be gone.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26082#discussion_r2214437363

From kbarrett at openjdk.org  Fri Jul 18 00:54:52 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 18 Jul 2025 00:54:52 GMT
Subject: RFR: 8360941: [ubsan] MemRegion::end() shows runtime error:
 applying non-zero offset 8388608 to null pointer [v4]
In-Reply-To: <jpNR9jM5WVyQ9iNR4rGc0GCaGTVXB75wxUVXVGb6GGg=.6ca2dd58-fb93-4ff5-b513-b17de9816f54@github.com>
References: <LP6FbAxZpwbGf6lkNvLcSRSEOu-mYKjWGAJYBSIMcyk=.775595dc-7f73-4248-a235-f4b58933396b@github.com>
 <jpNR9jM5WVyQ9iNR4rGc0GCaGTVXB75wxUVXVGb6GGg=.6ca2dd58-fb93-4ff5-b513-b17de9816f54@github.com>
Message-ID: <uBB4IJ6UUQ5t2fLKHyZlvYJRMA_Im_eHWCwFUNwrT70=.a6ff3604-8eda-4bb6-8565-00c8db6c049c@github.com>

On Thu, 17 Jul 2025 15:41:30 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When running HS test
>> gtest/GTestWrapper.java
>> with ubsan-enabled binaries on macOS aarch64, the following error is reported (did not see this so far on Linux but there we use gcc and it seems the gcc/ubsan checks are a bit more limited).
>> 
>> test/hotspot/gtest/gc/g1/test_freeRegionList.cpp:37: Failure
>> Death test: child_G1FreeRegionList_length_()
>>     Result: died but not with expected exit code:
>>             Terminated by signal 6 (core dumped)
>> Actual msg:
>> 
>> [  DEATH   ] /jdk/src/hotspot/share/memory/memRegion.hpp:66:43: runtime error: applying non-zero offset 8388608 to null pointer
>> [  DEATH   ]     #0 0x108afd6f4 in MemRegion::end() const+0x84 (libjvm.dylib:arm64+0x16556f4)
>> [  DEATH   ]     #1 0x1075c68a0 in G1FreeRegionList_length_other_vm_Test::TestBody()+0x380 (libjvm.dylib:arm64+0x11e8a0)
>> [  DEATH   ]     #2 0x1090f3bb0 in testing::Test::Run()+0xc0 (libjvm.dylib:arm64+0x1c4bbb0)
>> [  DEATH   ]     #3 0x1090f4d94 in testing::TestInfo::Run()+0x1e4 (libjvm.dylib:arm64+0x1c4cd94)
>> [  DEATH   ]     #4 0x1090f6754 in testing::TestSuite::Run()+0x43c (libjvm.dylib:arm64+0x1c4e754)
>> [  DEATH   ]     #5 0x109103ca0 in testing::internal::UnitTestImpl::RunAllTests()+0x48c (libjvm.dylib:arm64+0x1c5bca0)
>> [  DEATH   ]     #6 0x109103588 in testing::UnitTest::Run()+0x78 (libjvm.dylib:arm64+0x1c5b588)
>> [  DEATH   ]     #7 0x1074a9ac0 in runUnitTestsInner(int, char**)+0x724 (libjvm.dylib:arm64+0x1ac0)
>> [  DEATH   ]     #8 0x102dc3f18 in main+0x2c (gtestLauncher:arm64+0x100003f18)
>> [  DEATH   ]     #9 0x196fea0dc  (<unknown module>)
>> [  DEATH   ] 
>> [  DEATH   ] SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /jdk/src/hotspot/share/memory/memRegion.hpp:66:43 in 
>> [  DEATH   ] 
>> 
>> 
>> 
>> Seems the test_freeRegionList.cpp uses a special MemRegion starting at nullptr ; but this causes a bit of trouble when adding to start == nullptr .
>> So far I see this issue just in the gtest, seems other MemRegion objects do not start at nullptr .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid assertions, align address in test

test/hotspot/gtest/gc/g1/test_freeRegionList.cpp line 48:

> 46:   // does not access it.
> 47:   int val = 1;
> 48:   HeapWord* ptr = reinterpret_cast<HeapWord*>(&val);

The initial value for `val` doesn't matter, since we're using its address rather than value.
And the cast could be removed by changing the type of `val`, leading to something like this:

HeapWord val{};
HeapWord* ptr = align_up(&val, os::vm_page_size());

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26216#discussion_r2214604848

From dholmes at openjdk.org  Fri Jul 18 02:13:47 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 18 Jul 2025 02:13:47 GMT
Subject: RFR: 8362501: Update
 test/hotspot/jtreg/applications/jcstress/README
In-Reply-To: <Gv-CfzN4MbQDSvKMkXs6DWllE9saxTpkjIh92W8GkK4=.04b9e256-42cb-48de-a8e0-2345cdbc8b78@github.com>
References: <Gv-CfzN4MbQDSvKMkXs6DWllE9saxTpkjIh92W8GkK4=.04b9e256-42cb-48de-a8e0-2345cdbc8b78@github.com>
Message-ID: <3MiB6OM3vODfsd4d_n3xCZhOuLD216mNHcRMgX3UG8E=.f7c0a099-88b9-4a71-b81d-da7bedc85b99@github.com>

On Thu, 17 Jul 2025 12:29:00 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Currently, this is no documentation on how to run the application/jcstress tests. I think it will be useful to complement the document test/hotspot/jtreg/applications/jcstress/README on how to run the jcstress tests in jtreg.
> 
> No behaviour has been change, only update the ducumentation, no risk.

test/hotspot/jtreg/applications/jcstress/README line 31:

> 29: successfully. Before you start these tests, you should get the specified
> 30: build of org.openjdk.jcstress:jcstress-tests-all, the quickest way of
> 31: get specified build is download the prebuilt JAR from

Suggestion:

successfully. Before you start these tests, you should get the specified
build of org.openjdk.jcstress:jcstress-tests-all. The quickest way to
get the specified build is to download the prebuilt JAR from

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26369#discussion_r2214721322

From dholmes at openjdk.org  Fri Jul 18 02:17:46 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 18 Jul 2025 02:17:46 GMT
Subject: RFR: 8362501: Update
 test/hotspot/jtreg/applications/jcstress/README
In-Reply-To: <Gv-CfzN4MbQDSvKMkXs6DWllE9saxTpkjIh92W8GkK4=.04b9e256-42cb-48de-a8e0-2345cdbc8b78@github.com>
References: <Gv-CfzN4MbQDSvKMkXs6DWllE9saxTpkjIh92W8GkK4=.04b9e256-42cb-48de-a8e0-2345cdbc8b78@github.com>
Message-ID: <rRMmUGzJmHLHqcNZUFpXmXMnbUI2UJeCwSpfBLlXnEY=.ff625977-3810-4517-9a3a-8b89c089f638@github.com>

On Thu, 17 Jul 2025 12:29:00 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Currently, this is no documentation on how to run the application/jcstress tests. I think it will be useful to complement the document test/hotspot/jtreg/applications/jcstress/README on how to run the jcstress tests in jtreg.
> 
> No behaviour has been change, only update the ducumentation, no risk.

test/hotspot/jtreg/applications/jcstress/README line 35:

> 33: You should specific the JAR location with jtreg option such as
> 34: -Djdk.test.lib.artifacts.jcstress-tests-all=jcstress-tests-all-20241217-2035.jar
> 35: when start jcstress tests in jtreg.

Suggestion:

You should specify the JAR location by passing the following property when invoking jtreg. For example:
-Djdk.test.lib.artifacts.jcstress-tests-all=jcstress-tests-all-20241217-2035.jar

Though I'm unclear if this is a setting passed directly to jtreg, or whether it should be set via e.g. `-javaoption:-Dxxx` ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26369#discussion_r2214724943

From dholmes at openjdk.org  Fri Jul 18 03:22:53 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 18 Jul 2025 03:22:53 GMT
Subject: RFR: 8306324: StopThread results in thread being marked as
 interrupted, leading to unexpected InterruptedException
In-Reply-To: <FP7dEg2yA4qYU0pADEjBsbLMo_qfh9aCS7p6BC2irZg=.8a762fd5-58a7-4386-a68a-49c6d3a863ae@github.com>
References: <sDAklD-arV33IpWiJwMkwUfNPMAmsr5cgboU4y0hjhk=.192cd7e5-f2a2-4b5c-83a9-5111bf1926ec@github.com>
 <FP7dEg2yA4qYU0pADEjBsbLMo_qfh9aCS7p6BC2irZg=.8a762fd5-58a7-4386-a68a-49c6d3a863ae@github.com>
Message-ID: <Asna0L2_uaKQ1PQn8jXcoVm3vBrOTPomS_7NZwWe1bk=.e87baacf-ee4d-4fd2-9263-131aa71140b0@github.com>

On Thu, 17 Jul 2025 16:35:11 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> But maybe we could also add a has_async_exception_condition() check to bailout.

Yes.

BTW I don't think this is in any way new. I think Thread.stop would have had the same issue. Issuing the internal interrupt was just a convenient way to unblock all the interruptible blocking points - and as Alan notes, monitor acquisition is not interruptible. We likely did not care that this could make the interrupt state appear odd if the thread continued after the async (ThreadDeath) exception. Not sure it is really that different for the debugger - if we have stopped the thread (not just suspended it) then we shouldn't really be expecting it to continue as normal afterwards.

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

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

From syan at openjdk.org  Fri Jul 18 06:31:37 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 18 Jul 2025 06:31:37 GMT
Subject: RFR: 8362501: Update
 test/hotspot/jtreg/applications/jcstress/README [v2]
In-Reply-To: <Gv-CfzN4MbQDSvKMkXs6DWllE9saxTpkjIh92W8GkK4=.04b9e256-42cb-48de-a8e0-2345cdbc8b78@github.com>
References: <Gv-CfzN4MbQDSvKMkXs6DWllE9saxTpkjIh92W8GkK4=.04b9e256-42cb-48de-a8e0-2345cdbc8b78@github.com>
Message-ID: <_OAL4RIUkuwkPCOPg9arhmB71sz4xwkSsPuKzBVnLzo=.dc5503ee-2acf-4a03-b36d-e34c57b03d61@github.com>

> Hi all,
> 
> Currently, this is no documentation on how to run the application/jcstress tests. I think it will be useful to complement the document test/hotspot/jtreg/applications/jcstress/README on how to run the jcstress tests in jtreg.
> 
> No behaviour has been change, only update the ducumentation, no risk.

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

  Update README

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26369/files
  - new: https://git.openjdk.org/jdk/pull/26369/files/78320797..d024994c

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

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

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

From syan at openjdk.org  Fri Jul 18 06:31:37 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 18 Jul 2025 06:31:37 GMT
Subject: RFR: 8362501: Update
 test/hotspot/jtreg/applications/jcstress/README [v2]
In-Reply-To: <3MiB6OM3vODfsd4d_n3xCZhOuLD216mNHcRMgX3UG8E=.f7c0a099-88b9-4a71-b81d-da7bedc85b99@github.com>
References: <Gv-CfzN4MbQDSvKMkXs6DWllE9saxTpkjIh92W8GkK4=.04b9e256-42cb-48de-a8e0-2345cdbc8b78@github.com>
 <3MiB6OM3vODfsd4d_n3xCZhOuLD216mNHcRMgX3UG8E=.f7c0a099-88b9-4a71-b81d-da7bedc85b99@github.com>
Message-ID: <qRV4lz1Yw69QsuJGQs_GY2shYeQJGjBSvulR8Q9ei_o=.ea228422-10fd-4945-9c00-19f092baccb2@github.com>

On Fri, 18 Jul 2025 02:10:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update README
>
> test/hotspot/jtreg/applications/jcstress/README line 31:
> 
>> 29: successfully. Before you start these tests, you should get the specified
>> 30: build of org.openjdk.jcstress:jcstress-tests-all, the quickest way of
>> 31: get specified build is download the prebuilt JAR from
> 
> Suggestion:
> 
> successfully. Before you start these tests, you should get the specified
> build of org.openjdk.jcstress:jcstress-tests-all. The quickest way to
> get the specified build is to download the prebuilt JAR from

Thanks for the patiently reviews. @dholmes-ora 
The PR has been updated.

> test/hotspot/jtreg/applications/jcstress/README line 35:
> 
>> 33: You should specific the JAR location with jtreg option such as
>> 34: -Djdk.test.lib.artifacts.jcstress-tests-all=jcstress-tests-all-20241217-2035.jar
>> 35: when start jcstress tests in jtreg.
> 
> Suggestion:
> 
> You should specify the JAR location by passing the following property when invoking jtreg. For example:
> -Djdk.test.lib.artifacts.jcstress-tests-all=jcstress-tests-all-20241217-2035.jar
> 
> Though I'm unclear if this is a setting passed directly to jtreg, or whether it should be set via e.g. `-javaoption:-Dxxx` ?

I think use `-javaoption:` as prefix will be more expert, though use only -Dxxx will work also. PR has been updated, and I split this line to two lines.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26369#discussion_r2215083436
PR Review Comment: https://git.openjdk.org/jdk/pull/26369#discussion_r2215088674

From dholmes at openjdk.org  Fri Jul 18 07:03:50 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 18 Jul 2025 07:03:50 GMT
Subject: RFR: 8359820: Improve handshake/safepoint timeout diagnostic
 messages [v2]
In-Reply-To: <CgMbxpMEiIMeTFuQW3VERXmZprNLiKhmUBuJPd2HF5c=.46f5f5d7-4cd3-4d44-bfff-4ce9adcfd707@github.com>
References: <FZ87bVfDootrLeANGguMFpcTm7X8AEqzuKVQspmSkmE=.4484090b-ba49-498c-bb07-71d22fd34823@github.com>
 <CgMbxpMEiIMeTFuQW3VERXmZprNLiKhmUBuJPd2HF5c=.46f5f5d7-4cd3-4d44-bfff-4ce9adcfd707@github.com>
Message-ID: <dR9C46O4KQtFcsUwKBU6ZJiKqIdSI2Wy91VFj0B9ffo=.d9f3fda1-cd94-4a63-8362-ef9a1a4ee53b@github.com>

On Thu, 17 Jul 2025 14:08:24 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 pull request now contains eight commits:
> 
>  - Merge remote-tracking branch 'origin/master' into JDK-8359820-SIGILL-with-low-handshake-timeout-on-intel-sde
>  - 8359820: Fixed test
>  - 8359820: Removed extra line
>  - Merge branch 'JDK-8359820-SIGILL-with-low-handshake-timeout-on-intel-sde' of https://github.com/toxaart/jdk into JDK-8359820-SIGILL-with-low-handshake-timeout-on-intel-sde
>  - Merge remote-tracking branch 'origin/master' into JDK-8359820-SIGILL-with-low-handshake-timeout-on-intel-sde
>  - 8359820:  Improved safepoint and handshake timeout report
>  - 8359820: Fixed newline
>  - 8359820: Explicitly report SIGILL fired by handshake timeout handler in VMError::report()

Changes requested by dholmes (Reviewer).

src/hotspot/share/runtime/handshake.cpp line 49:

> 47: #include "utilities/systemMemoryBarrier.hpp"
> 48: 
> 49: intptr_t HandshakeTimedOutThread = p2i(nullptr);

Variable names don't start with a capital, or generally use camel-case.

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

> 823:         } else if (SafepointTimedOutThread != p2i(nullptr)) {
> 824:           st->print(" (sent by safepoint timeout handler, timed out thread " PTR_FORMAT ")", SafepointTimedOutThread);
> 825:         } else {

I was thinking here that we would only report the timeouts if the current thread was the one we had stashed away. That way we don't hijack a completely different occurrence of SIGILL.

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

PR Review: https://git.openjdk.org/jdk/pull/26309#pullrequestreview-3032262529
PR Review Comment: https://git.openjdk.org/jdk/pull/26309#discussion_r2215173455
PR Review Comment: https://git.openjdk.org/jdk/pull/26309#discussion_r2215180005

From duke at openjdk.org  Fri Jul 18 07:41:44 2025
From: duke at openjdk.org (Anton Artemov)
Date: Fri, 18 Jul 2025 07:41:44 GMT
Subject: RFR: 8359820: Improve handshake/safepoint timeout diagnostic
 messages [v3]
In-Reply-To: <FZ87bVfDootrLeANGguMFpcTm7X8AEqzuKVQspmSkmE=.4484090b-ba49-498c-bb07-71d22fd34823@github.com>
References: <FZ87bVfDootrLeANGguMFpcTm7X8AEqzuKVQspmSkmE=.4484090b-ba49-498c-bb07-71d22fd34823@github.com>
Message-ID: <Ql0l4nxCeZx7oGpm0DZHnbBxBo0veODNL7mRc7q0RH0=.13d48a16-ea7a-4b2f-aa9c-bee78b78a80d@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 incrementally with one additional commit since the last revision:

  8359820: Addressed reviewer's comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26309/files
  - new: https://git.openjdk.org/jdk/pull/26309/files/689e6147..40645638

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

  Stats: 10 lines in 4 files changed: 0 ins; 0 del; 10 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  Fri Jul 18 07:47:52 2025
From: duke at openjdk.org (Anton Artemov)
Date: Fri, 18 Jul 2025 07:47:52 GMT
Subject: RFR: 8359820: Improve handshake/safepoint timeout diagnostic
 messages [v2]
In-Reply-To: <dR9C46O4KQtFcsUwKBU6ZJiKqIdSI2Wy91VFj0B9ffo=.d9f3fda1-cd94-4a63-8362-ef9a1a4ee53b@github.com>
References: <FZ87bVfDootrLeANGguMFpcTm7X8AEqzuKVQspmSkmE=.4484090b-ba49-498c-bb07-71d22fd34823@github.com>
 <CgMbxpMEiIMeTFuQW3VERXmZprNLiKhmUBuJPd2HF5c=.46f5f5d7-4cd3-4d44-bfff-4ce9adcfd707@github.com>
 <dR9C46O4KQtFcsUwKBU6ZJiKqIdSI2Wy91VFj0B9ffo=.d9f3fda1-cd94-4a63-8362-ef9a1a4ee53b@github.com>
Message-ID: <ZfRUaGbO-6z8GtE2zmDR6vUQmdGjAYtoYgJI_O-5iJE=.bc682681-8482-44f6-8263-75f32c0b4954@github.com>

On Fri, 18 Jul 2025 06:58:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into JDK-8359820-SIGILL-with-low-handshake-timeout-on-intel-sde
>>  - 8359820: Fixed test
>>  - 8359820: Removed extra line
>>  - Merge branch 'JDK-8359820-SIGILL-with-low-handshake-timeout-on-intel-sde' of https://github.com/toxaart/jdk into JDK-8359820-SIGILL-with-low-handshake-timeout-on-intel-sde
>>  - Merge remote-tracking branch 'origin/master' into JDK-8359820-SIGILL-with-low-handshake-timeout-on-intel-sde
>>  - 8359820:  Improved safepoint and handshake timeout report
>>  - 8359820: Fixed newline
>>  - 8359820: Explicitly report SIGILL fired by handshake timeout handler in VMError::report()
>
> src/hotspot/share/runtime/handshake.cpp line 49:
> 
>> 47: #include "utilities/systemMemoryBarrier.hpp"
>> 48: 
>> 49: intptr_t HandshakeTimedOutThread = p2i(nullptr);
> 
> Variable names don't start with a capital, or generally use camel-case.

Thanks, addressed in the latest commit. Some other variables in that file do not follow convention though.

> src/hotspot/share/utilities/vmError.cpp line 825:
> 
>> 823:         } else if (SafepointTimedOutThread != p2i(nullptr)) {
>> 824:           st->print(" (sent by safepoint timeout handler, timed out thread " PTR_FORMAT ")", SafepointTimedOutThread);
>> 825:         } else {
> 
> I was thinking here that we would only report the timeouts if the current thread was the one we had stashed away. That way we don't hijack a completely different occurrence of SIGILL.

I changed the condition as suggested.

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

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

From stuefe at openjdk.org  Fri Jul 18 08:10:59 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 18 Jul 2025 08:10:59 GMT
Subject: RFR: 8359820: Improve handshake/safepoint timeout diagnostic
 messages [v3]
In-Reply-To: <Ql0l4nxCeZx7oGpm0DZHnbBxBo0veODNL7mRc7q0RH0=.13d48a16-ea7a-4b2f-aa9c-bee78b78a80d@github.com>
References: <FZ87bVfDootrLeANGguMFpcTm7X8AEqzuKVQspmSkmE=.4484090b-ba49-498c-bb07-71d22fd34823@github.com>
 <Ql0l4nxCeZx7oGpm0DZHnbBxBo0veODNL7mRc7q0RH0=.13d48a16-ea7a-4b2f-aa9c-bee78b78a80d@github.com>
Message-ID: <JuiV0so38mJbe3zEt5UM6fMUphJR5hfFFCXJQVc5kz0=.6e29eab5-1fd0-4f0d-9701-fd1a41797e6d@github.com>

On Fri, 18 Jul 2025 07:41:44 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 one additional commit since the last revision:
> 
>   8359820: Addressed reviewer's comments

src/hotspot/share/utilities/globalDefinitions.hpp line 1351:

> 1349: // Indicate VMError::report() that SIGILL came from safepoint timeout handler, report which thread timed out
> 1350: extern intptr_t safepointTimedOutThread;
> 1351: 

Do we really need this in globalDefinitions? This seems to be a mechanism highly specific to error handling and safe points.

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

> 825:         } else {
> 826:           st->print(" (sent by kill)");
> 827:         }

I don't understand.

Should not the receiving thread be the timeouted thread? So the one that is executing right now?

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

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

From stuefe at openjdk.org  Fri Jul 18 08:18:51 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 18 Jul 2025 08:18:51 GMT
Subject: RFR: 8359820: Improve handshake/safepoint timeout diagnostic
 messages [v3]
In-Reply-To: <Ql0l4nxCeZx7oGpm0DZHnbBxBo0veODNL7mRc7q0RH0=.13d48a16-ea7a-4b2f-aa9c-bee78b78a80d@github.com>
References: <FZ87bVfDootrLeANGguMFpcTm7X8AEqzuKVQspmSkmE=.4484090b-ba49-498c-bb07-71d22fd34823@github.com>
 <Ql0l4nxCeZx7oGpm0DZHnbBxBo0veODNL7mRc7q0RH0=.13d48a16-ea7a-4b2f-aa9c-bee78b78a80d@github.com>
Message-ID: <YaBMm44ml79pjuOdq3VZ7vRhANxOWgf4THGH_E8B1kg=.e7380cf2-fb19-4d94-a9bc-ee089c376564@github.com>

On Fri, 18 Jul 2025 07:41:44 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 one additional commit since the last revision:
> 
>   8359820: Addressed reviewer's comments

BTW, for artificially generated signals we already have a clear indication in hs_err files. We print the sigaction structure associated with the signal.

e.g.

 siginfo: si_signo: 4 (SIGILL), si_code: 0 (SI_USER), si_pid: 13281, si_uid: 1027



SI_USER => sent via kill command or pthread_kill
si_pid = sending process or thread id
si_uid = sending user (in case of outside process)

 See also: https://pubs.opengroup.org/onlinepubs/007904875/functions/sigaction.html

I have nothing against making this clearer, just saying that the info is already kind of there.

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

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

From mbaesken at openjdk.org  Fri Jul 18 08:21:48 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 18 Jul 2025 08:21:48 GMT
Subject: RFR: 8360941: [ubsan] MemRegion::end() shows runtime error:
 applying non-zero offset 8388608 to null pointer [v5]
In-Reply-To: <LP6FbAxZpwbGf6lkNvLcSRSEOu-mYKjWGAJYBSIMcyk=.775595dc-7f73-4248-a235-f4b58933396b@github.com>
References: <LP6FbAxZpwbGf6lkNvLcSRSEOu-mYKjWGAJYBSIMcyk=.775595dc-7f73-4248-a235-f4b58933396b@github.com>
Message-ID: <b4vLCFRr3Q6g9mcWOVo7kf4W97q63WtkQ4pPdK8g8Eo=.44c119fc-86d2-4e8c-9ca5-930875c820fe@github.com>

> When running HS test
> gtest/GTestWrapper.java
> with ubsan-enabled binaries on macOS aarch64, the following error is reported (did not see this so far on Linux but there we use gcc and it seems the gcc/ubsan checks are a bit more limited).
> 
> test/hotspot/gtest/gc/g1/test_freeRegionList.cpp:37: Failure
> Death test: child_G1FreeRegionList_length_()
>     Result: died but not with expected exit code:
>             Terminated by signal 6 (core dumped)
> Actual msg:
> 
> [  DEATH   ] /jdk/src/hotspot/share/memory/memRegion.hpp:66:43: runtime error: applying non-zero offset 8388608 to null pointer
> [  DEATH   ]     #0 0x108afd6f4 in MemRegion::end() const+0x84 (libjvm.dylib:arm64+0x16556f4)
> [  DEATH   ]     #1 0x1075c68a0 in G1FreeRegionList_length_other_vm_Test::TestBody()+0x380 (libjvm.dylib:arm64+0x11e8a0)
> [  DEATH   ]     #2 0x1090f3bb0 in testing::Test::Run()+0xc0 (libjvm.dylib:arm64+0x1c4bbb0)
> [  DEATH   ]     #3 0x1090f4d94 in testing::TestInfo::Run()+0x1e4 (libjvm.dylib:arm64+0x1c4cd94)
> [  DEATH   ]     #4 0x1090f6754 in testing::TestSuite::Run()+0x43c (libjvm.dylib:arm64+0x1c4e754)
> [  DEATH   ]     #5 0x109103ca0 in testing::internal::UnitTestImpl::RunAllTests()+0x48c (libjvm.dylib:arm64+0x1c5bca0)
> [  DEATH   ]     #6 0x109103588 in testing::UnitTest::Run()+0x78 (libjvm.dylib:arm64+0x1c5b588)
> [  DEATH   ]     #7 0x1074a9ac0 in runUnitTestsInner(int, char**)+0x724 (libjvm.dylib:arm64+0x1ac0)
> [  DEATH   ]     #8 0x102dc3f18 in main+0x2c (gtestLauncher:arm64+0x100003f18)
> [  DEATH   ]     #9 0x196fea0dc  (<unknown module>)
> [  DEATH   ] 
> [  DEATH   ] SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /jdk/src/hotspot/share/memory/memRegion.hpp:66:43 in 
> [  DEATH   ] 
> 
> 
> 
> Seems the test_freeRegionList.cpp uses a special MemRegion starting at nullptr ; but this causes a bit of trouble when adding to start == nullptr .
> So far I see this issue just in the gtest, seems other MemRegion objects do not start at nullptr .

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

  Simplify test coding

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26216/files
  - new: https://git.openjdk.org/jdk/pull/26216/files/842077ad..f0888cea

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

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

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

From duke at openjdk.org  Fri Jul 18 09:04:50 2025
From: duke at openjdk.org (Anton Artemov)
Date: Fri, 18 Jul 2025 09:04:50 GMT
Subject: RFR: 8359820: Improve handshake/safepoint timeout diagnostic
 messages [v3]
In-Reply-To: <JuiV0so38mJbe3zEt5UM6fMUphJR5hfFFCXJQVc5kz0=.6e29eab5-1fd0-4f0d-9701-fd1a41797e6d@github.com>
References: <FZ87bVfDootrLeANGguMFpcTm7X8AEqzuKVQspmSkmE=.4484090b-ba49-498c-bb07-71d22fd34823@github.com>
 <Ql0l4nxCeZx7oGpm0DZHnbBxBo0veODNL7mRc7q0RH0=.13d48a16-ea7a-4b2f-aa9c-bee78b78a80d@github.com>
 <JuiV0so38mJbe3zEt5UM6fMUphJR5hfFFCXJQVc5kz0=.6e29eab5-1fd0-4f0d-9701-fd1a41797e6d@github.com>
Message-ID: <gOUSZehyM2RAReny90AXGjGwd8lCMiDOoxIoEQfs7hQ=.067090d3-733e-425f-9bb6-ebf438a9090a@github.com>

On Fri, 18 Jul 2025 08:02:32 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8359820: Addressed reviewer's comments
>
> src/hotspot/share/utilities/vmError.cpp line 827:
> 
>> 825:         } else {
>> 826:           st->print(" (sent by kill)");
>> 827:         }
> 
> I don't understand.
> 
> Should not the receiving thread be the timeouted thread? So the one that is executing right now?

I think it can be that the receiving thread does not manage to report the error, but `safepointTimedOutThread` already got a value, which could confuse the reporting method of `VMError` called on another thread. I think this check is needed, as pointed out by @dholmes-ora .

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

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

From duke at openjdk.org  Fri Jul 18 09:14:39 2025
From: duke at openjdk.org (Anton Artemov)
Date: Fri, 18 Jul 2025 09:14:39 GMT
Subject: RFR: 8359820: Improve handshake/safepoint timeout diagnostic
 messages [v4]
In-Reply-To: <FZ87bVfDootrLeANGguMFpcTm7X8AEqzuKVQspmSkmE=.4484090b-ba49-498c-bb07-71d22fd34823@github.com>
References: <FZ87bVfDootrLeANGguMFpcTm7X8AEqzuKVQspmSkmE=.4484090b-ba49-498c-bb07-71d22fd34823@github.com>
Message-ID: <2aTRSndt5OybRRiIk8n--gjyH6q5sqrVNDxPHDMefuk=.1c68c38e-4fb7-4343-841d-b2f13ac97072@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 incrementally with one additional commit since the last revision:

  8359820: Addressed reviewer's comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26309/files
  - new: https://git.openjdk.org/jdk/pull/26309/files/40645638..27cb77d2

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

  Stats: 13 lines in 3 files changed: 6 ins; 7 del; 0 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 dholmes at openjdk.org  Fri Jul 18 09:14:39 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 18 Jul 2025 09:14:39 GMT
Subject: RFR: 8359820: Improve handshake/safepoint timeout diagnostic
 messages [v3]
In-Reply-To: <YaBMm44ml79pjuOdq3VZ7vRhANxOWgf4THGH_E8B1kg=.e7380cf2-fb19-4d94-a9bc-ee089c376564@github.com>
References: <FZ87bVfDootrLeANGguMFpcTm7X8AEqzuKVQspmSkmE=.4484090b-ba49-498c-bb07-71d22fd34823@github.com>
 <Ql0l4nxCeZx7oGpm0DZHnbBxBo0veODNL7mRc7q0RH0=.13d48a16-ea7a-4b2f-aa9c-bee78b78a80d@github.com>
 <YaBMm44ml79pjuOdq3VZ7vRhANxOWgf4THGH_E8B1kg=.e7380cf2-fb19-4d94-a9bc-ee089c376564@github.com>
Message-ID: <jLZV7rtCIsjW4GeQcjbOkNwyyEUXJTmZpwh5aawQ8Js=.3cb69104-0be8-4308-95db-ac7284e18bba@github.com>

On Fri, 18 Jul 2025 08:15:36 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> I have nothing against making this clearer, just saying that the info is already kind of there.

Yes, but there are a few reasons a SIGILL may have been fired at a thread, so it would be useful to get a clear indication of exactly why it happened. Not everyone will realize/know that SIGILL happens because of a timeout in handshake/safepoint.

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

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

From duke at openjdk.org  Fri Jul 18 09:14:40 2025
From: duke at openjdk.org (Anton Artemov)
Date: Fri, 18 Jul 2025 09:14:40 GMT
Subject: RFR: 8359820: Improve handshake/safepoint timeout diagnostic
 messages [v3]
In-Reply-To: <JuiV0so38mJbe3zEt5UM6fMUphJR5hfFFCXJQVc5kz0=.6e29eab5-1fd0-4f0d-9701-fd1a41797e6d@github.com>
References: <FZ87bVfDootrLeANGguMFpcTm7X8AEqzuKVQspmSkmE=.4484090b-ba49-498c-bb07-71d22fd34823@github.com>
 <Ql0l4nxCeZx7oGpm0DZHnbBxBo0veODNL7mRc7q0RH0=.13d48a16-ea7a-4b2f-aa9c-bee78b78a80d@github.com>
 <JuiV0so38mJbe3zEt5UM6fMUphJR5hfFFCXJQVc5kz0=.6e29eab5-1fd0-4f0d-9701-fd1a41797e6d@github.com>
Message-ID: <621DGOjIaG_AkeywY9lbO-wRJI-2rh7EY86ce9z4800=.bca519b0-48e2-492a-bec1-148ffae8b19c@github.com>

On Fri, 18 Jul 2025 07:59:35 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8359820: Addressed reviewer's comments
>
> src/hotspot/share/utilities/globalDefinitions.hpp line 1351:
> 
>> 1349: // Indicate VMError::report() that SIGILL came from safepoint timeout handler, report which thread timed out
>> 1350: extern intptr_t safepointTimedOutThread;
>> 1351: 
> 
> Do we really need this in globalDefinitions? This seems to be a mechanism highly specific to error handling and safe points.

No, we do not, it seemed like a good place for this "communicative" variables to be declared, but it can be done in safepoint.hpp and handshake.hpp respectively. Addressed in the latest commit.

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

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

From stuefe at openjdk.org  Fri Jul 18 09:43:54 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 18 Jul 2025 09:43:54 GMT
Subject: RFR: 8359820: Improve handshake/safepoint timeout diagnostic
 messages [v3]
In-Reply-To: <gOUSZehyM2RAReny90AXGjGwd8lCMiDOoxIoEQfs7hQ=.067090d3-733e-425f-9bb6-ebf438a9090a@github.com>
References: <FZ87bVfDootrLeANGguMFpcTm7X8AEqzuKVQspmSkmE=.4484090b-ba49-498c-bb07-71d22fd34823@github.com>
 <Ql0l4nxCeZx7oGpm0DZHnbBxBo0veODNL7mRc7q0RH0=.13d48a16-ea7a-4b2f-aa9c-bee78b78a80d@github.com>
 <JuiV0so38mJbe3zEt5UM6fMUphJR5hfFFCXJQVc5kz0=.6e29eab5-1fd0-4f0d-9701-fd1a41797e6d@github.com>
 <gOUSZehyM2RAReny90AXGjGwd8lCMiDOoxIoEQfs7hQ=.067090d3-733e-425f-9bb6-ebf438a9090a@github.com>
Message-ID: <Na2TQTC6TLlcOcnXUJclOANLj3Z5trlsHm2QEainxYE=.7017cd87-2bd1-437f-9072-834e165d590c@github.com>

On Fri, 18 Jul 2025 09:02:38 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> src/hotspot/share/utilities/vmError.cpp line 827:
>> 
>>> 825:         } else {
>>> 826:           st->print(" (sent by kill)");
>>> 827:         }
>> 
>> I don't understand.
>> 
>> Should not the receiving thread be the timeouted thread? So the one that is executing right now?
>
> I think it can be that the receiving thread does not manage to report the error, but `safepointTimedOutThread` already got a value, which could confuse the reporting method of `VMError` called on another thread. I think this check is needed, as pointed out by @dholmes-ora .

You lost me here.

Here we report a SIGILL being received by thread A, sent by thread B. This information is sure.

Do you mean that thread A was not the intended recipient of the SIGILL?

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

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

From stuefe at openjdk.org  Fri Jul 18 09:55:48 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 18 Jul 2025 09:55:48 GMT
Subject: RFR: 8359820: Improve handshake/safepoint timeout diagnostic
 messages [v3]
In-Reply-To: <jLZV7rtCIsjW4GeQcjbOkNwyyEUXJTmZpwh5aawQ8Js=.3cb69104-0be8-4308-95db-ac7284e18bba@github.com>
References: <FZ87bVfDootrLeANGguMFpcTm7X8AEqzuKVQspmSkmE=.4484090b-ba49-498c-bb07-71d22fd34823@github.com>
 <Ql0l4nxCeZx7oGpm0DZHnbBxBo0veODNL7mRc7q0RH0=.13d48a16-ea7a-4b2f-aa9c-bee78b78a80d@github.com>
 <YaBMm44ml79pjuOdq3VZ7vRhANxOWgf4THGH_E8B1kg=.e7380cf2-fb19-4d94-a9bc-ee089c376564@github.com>
 <jLZV7rtCIsjW4GeQcjbOkNwyyEUXJTmZpwh5aawQ8Js=.3cb69104-0be8-4308-95db-ac7284e18bba@github.com>
Message-ID: <cgkjiHoYRu54YNZCKG6Pvv2kysBEgIi4AhuPcnFNjVc=.bbee0900-5af7-4ad3-a51d-87bdac9e1f07@github.com>

On Fri, 18 Jul 2025 09:09:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > I have nothing against making this clearer, just saying that the info is already kind of there.
> 
> Yes, but there are a few reasons a SIGILL may have been fired at a thread, so it would be useful to get a clear indication of exactly why it happened. Not everyone will realize/know that SIGILL happens because of a timeout in handshake/safepoint.

I still don't get it.

- Is the receiving thread the one meant to receive the SIGILL? Then why print this at all, we have callstack and thread info already?
- Is the receiving thread not the originally intended recipient? But how? This can only happen either if the original recipient thread blocked - which we don't do in hotspot code AFAIK, so it could only be a library method that temporary sets a signal mask - or if there is a bug in the sending code - in which case we should fix it?
- Is the SIGILL completely unrelated to the safepoint? Then why print the information?

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

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

From duke at openjdk.org  Fri Jul 18 09:55:49 2025
From: duke at openjdk.org (Anton Artemov)
Date: Fri, 18 Jul 2025 09:55:49 GMT
Subject: RFR: 8359820: Improve handshake/safepoint timeout diagnostic
 messages [v3]
In-Reply-To: <Na2TQTC6TLlcOcnXUJclOANLj3Z5trlsHm2QEainxYE=.7017cd87-2bd1-437f-9072-834e165d590c@github.com>
References: <FZ87bVfDootrLeANGguMFpcTm7X8AEqzuKVQspmSkmE=.4484090b-ba49-498c-bb07-71d22fd34823@github.com>
 <Ql0l4nxCeZx7oGpm0DZHnbBxBo0veODNL7mRc7q0RH0=.13d48a16-ea7a-4b2f-aa9c-bee78b78a80d@github.com>
 <JuiV0so38mJbe3zEt5UM6fMUphJR5hfFFCXJQVc5kz0=.6e29eab5-1fd0-4f0d-9701-fd1a41797e6d@github.com>
 <gOUSZehyM2RAReny90AXGjGwd8lCMiDOoxIoEQfs7hQ=.067090d3-733e-425f-9bb6-ebf438a9090a@github.com>
 <Na2TQTC6TLlcOcnXUJclOANLj3Z5trlsHm2QEainxYE=.7017cd87-2bd1-437f-9072-834e165d590c@github.com>
Message-ID: <fSY-G3G5S_27j6S_zGoBXb650FF2XJgyHiW08DZT3vM=.16a03ea4-81bc-4e70-a415-aa2136076f6c@github.com>

On Fri, 18 Jul 2025 09:41:30 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> I think it can be that the receiving thread does not manage to report the error, but `safepointTimedOutThread` already got a value, which could confuse the reporting method of `VMError` called on another thread. I think this check is needed, as pointed out by @dholmes-ora .
>
> You lost me here.
> 
> Here we report a SIGILL being received by thread A, sent by thread B. This information is sure.
> 
> Do you mean that thread A was not the intended recipient of the SIGILL?

What I was trying to say is that to rely solely on the non-null value of the "communicative" variable, say `handshakeTimedOutThread` may not be  a good idea, as thread A (SIGILL receiver) may not be able to report the error for some reason. 

In the `handshake::handle_timeout()` code there is a sleep for 3 seconds. Hypothetically if any other thread receives SIGILL for any other reason within this time, while thread A is busy and can't report an error, it (the other thread) wont't be able to report properly as handshakeTimedOutThread already has a value. Therefore a check is the current thread is handshakeTimedOutThread is needed.

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

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

From stuefe at openjdk.org  Fri Jul 18 10:01:58 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 18 Jul 2025 10:01:58 GMT
Subject: RFR: 8359820: Improve handshake/safepoint timeout diagnostic
 messages [v4]
In-Reply-To: <2aTRSndt5OybRRiIk8n--gjyH6q5sqrVNDxPHDMefuk=.1c68c38e-4fb7-4343-841d-b2f13ac97072@github.com>
References: <FZ87bVfDootrLeANGguMFpcTm7X8AEqzuKVQspmSkmE=.4484090b-ba49-498c-bb07-71d22fd34823@github.com>
 <2aTRSndt5OybRRiIk8n--gjyH6q5sqrVNDxPHDMefuk=.1c68c38e-4fb7-4343-841d-b2f13ac97072@github.com>
Message-ID: <2MUhTQg-iME2UQHc306kCJMOnbBod3_59syTmsJUz8I=.92d9495d-0ac5-42c4-8632-1bb9725270fd@github.com>

On Fri, 18 Jul 2025 09:14:39 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 one additional commit since the last revision:
> 
>   8359820: Addressed reviewer's comments

To clarify, I am concerned about misleading printouts. Signal issues are difficult to analyze. Signals can interleave, overlap, get lost, or be blocked. I think it's important to be precise.

For example, saving gobal information A, sending signal, and in the handler printing "signal X relates to global information A" can be wrong. The signal can have some other cause. 

It would be good to save both the sender and recipent's thread id in the global information before sending the signal, the in the signal handler to correlate this with what sigaction_t says who send the signal, and with the receiving thread's thread id. 

That way we can be sure that, yes, X send a signal A to Y, I am Y, I got signal A from X, so this is safe information I could now print. It would make investigating issues like the one motivating this change a lot easier, especially when multiple signals are involved.

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

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

From stuefe at openjdk.org  Fri Jul 18 10:32:51 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 18 Jul 2025 10:32:51 GMT
Subject: RFR: 8359820: Improve handshake/safepoint timeout diagnostic
 messages [v3]
In-Reply-To: <fSY-G3G5S_27j6S_zGoBXb650FF2XJgyHiW08DZT3vM=.16a03ea4-81bc-4e70-a415-aa2136076f6c@github.com>
References: <FZ87bVfDootrLeANGguMFpcTm7X8AEqzuKVQspmSkmE=.4484090b-ba49-498c-bb07-71d22fd34823@github.com>
 <Ql0l4nxCeZx7oGpm0DZHnbBxBo0veODNL7mRc7q0RH0=.13d48a16-ea7a-4b2f-aa9c-bee78b78a80d@github.com>
 <JuiV0so38mJbe3zEt5UM6fMUphJR5hfFFCXJQVc5kz0=.6e29eab5-1fd0-4f0d-9701-fd1a41797e6d@github.com>
 <gOUSZehyM2RAReny90AXGjGwd8lCMiDOoxIoEQfs7hQ=.067090d3-733e-425f-9bb6-ebf438a9090a@github.com>
 <Na2TQTC6TLlcOcnXUJclOANLj3Z5trlsHm2QEainxYE=.7017cd87-2bd1-437f-9072-834e165d590c@github.com>
 <fSY-G3G5S_27j6S_zGoBXb650FF2XJgyHiW08DZT3vM=.16a03ea4-81bc-4e70-a415-aa2136076f6c@github.com>
Message-ID: <24NcK-U6TIRfFs9iNFQd98Rd3-zBhkdQKRxKMtQByqk=.db565b65-ce0d-4dce-8496-f783384f6fda@github.com>

On Fri, 18 Jul 2025 09:53:33 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> You lost me here.
>> 
>> Here we report a SIGILL being received by thread A, sent by thread B. This information is sure.
>> 
>> Do you mean that thread A was not the intended recipient of the SIGILL?
>
> What I was trying to say is that to rely solely on the non-null value of the "communicative" variable, say `handshakeTimedOutThread` may not be  a good idea, as thread A (SIGILL receiver) may not be able to report the error for some reason. 
> 
> In the `handshake::handle_timeout()` code there is a sleep for 3 seconds. Hypothetically if any other thread receives SIGILL for any other reason within this time, while thread A is busy and can't report an error, it (the other thread) wont't be able to report properly as handshakeTimedOutThread already has a value. Therefore a check is the current thread is handshakeTimedOutThread is needed.

@toxaart to prevent that we are talking at cross purposes, would you mind answering the questions I put in the other thread? https://github.com/openjdk/jdk/pull/26309#issuecomment-3088856848

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

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

From duke at openjdk.org  Fri Jul 18 10:49:52 2025
From: duke at openjdk.org (Anton Artemov)
Date: Fri, 18 Jul 2025 10:49:52 GMT
Subject: RFR: 8359820: Improve handshake/safepoint timeout diagnostic
 messages [v3]
In-Reply-To: <cgkjiHoYRu54YNZCKG6Pvv2kysBEgIi4AhuPcnFNjVc=.bbee0900-5af7-4ad3-a51d-87bdac9e1f07@github.com>
References: <FZ87bVfDootrLeANGguMFpcTm7X8AEqzuKVQspmSkmE=.4484090b-ba49-498c-bb07-71d22fd34823@github.com>
 <Ql0l4nxCeZx7oGpm0DZHnbBxBo0veODNL7mRc7q0RH0=.13d48a16-ea7a-4b2f-aa9c-bee78b78a80d@github.com>
 <YaBMm44ml79pjuOdq3VZ7vRhANxOWgf4THGH_E8B1kg=.e7380cf2-fb19-4d94-a9bc-ee089c376564@github.com>
 <jLZV7rtCIsjW4GeQcjbOkNwyyEUXJTmZpwh5aawQ8Js=.3cb69104-0be8-4308-95db-ac7284e18bba@github.com>
 <cgkjiHoYRu54YNZCKG6Pvv2kysBEgIi4AhuPcnFNjVc=.bbee0900-5af7-4ad3-a51d-87bdac9e1f07@github.com>
Message-ID: <zy9KDg1C9w_yzg0pnrChok7vk1LzsNU-YaxjyyH1YAs=.c59ba262-f7d3-48eb-a6da-5fda887a916b@github.com>

On Fri, 18 Jul 2025 09:53:33 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> * Is the receiving thread the one meant to receive the SIGILL? Then why print this at all, we have callstack and thread info already?

Yes, the receiving thread is the one to receive the SIGILL. I agree that the changes introduce a degree of redundancy, but it is difficult to see by looking at the thread callstack that it was killed by the timeout mechanism of the handshake. I found it by looking at events log, see the discussion in JBS. 


> * Is the receiving thread not the originally intended recipient? But how? This can only happen either if the original recipient thread blocked - which we don't do in hotspot code AFAIK, so it could only be a library method that temporary sets a signal mask - or if there is a bug in the sending code - in which case we should fix it?

I think I already described a possible situation: if the receiver does not report the crash within 3 seconds, then a fatal error will be reported by the calling thread. However, it may happen that any other thread receives SIGILL for any other reason within that time interval. But the "busy" thread is already in the "communicative" variable, which will not be the signal receiver in this particular case. I do not really know if this situation is just hypothetical or ever occurred in practice.

> * Is the SIGILL completely unrelated to the safepoint? Then why print the information?

No, it is intentionally fired by the timeout handler. Quote from mr. Shipilev, see the issue discussion: "The intent for SIGILL is to trigger the crash at the thread that blocks handshake/safepoint sync. E.g. a Java thread that is stuck on miscompiled loop without safepoint checks. Or some VM code that spins without VM transitions. See [JDK-8219584](https://bugs.openjdk.org/browse/JDK-8219584). This feature is remarkably useful in the field, used this dozens of times. So whatever we do, we need to keep printing the instructions block and hopefully a backtrace."

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

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

From dholmes at openjdk.org  Fri Jul 18 12:25:48 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 18 Jul 2025 12:25:48 GMT
Subject: RFR: 8359820: Improve handshake/safepoint timeout diagnostic
 messages [v4]
In-Reply-To: <2MUhTQg-iME2UQHc306kCJMOnbBod3_59syTmsJUz8I=.92d9495d-0ac5-42c4-8632-1bb9725270fd@github.com>
References: <FZ87bVfDootrLeANGguMFpcTm7X8AEqzuKVQspmSkmE=.4484090b-ba49-498c-bb07-71d22fd34823@github.com>
 <2aTRSndt5OybRRiIk8n--gjyH6q5sqrVNDxPHDMefuk=.1c68c38e-4fb7-4343-841d-b2f13ac97072@github.com>
 <2MUhTQg-iME2UQHc306kCJMOnbBod3_59syTmsJUz8I=.92d9495d-0ac5-42c4-8632-1bb9725270fd@github.com>
Message-ID: <yleb6K3Cd9AeUNyra1F1db7aJrdEflOTCuuGNU_vGzU=.576a1af3-9c9b-4cf2-90b2-02b961609322@github.com>

On Fri, 18 Jul 2025 09:59:29 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8359820: Addressed reviewer's comments
>
> To clarify, I am concerned about misleading printouts. Signal issues are difficult to analyze. Signals can interleave, overlap, get lost, or be blocked. I think it's important to be precise.
> 
> For example, saving gobal information A, sending signal, and in the handler printing "signal X relates to global information A" can be wrong. The signal can have some other cause. 
> 
> It would be good to save both the sender and recipent's thread id in the global information before sending the signal, the in the signal handler to correlate this with what sigaction_t says who send the signal, and with the receiving thread's thread id. 
> 
> That way we can be sure that, yes, X send a signal A to Y, I am Y, I got signal A from X, so this is safe information I could now print. It would make investigating issues like the one motivating this change a lot easier, especially when multiple signals are involved.

Not sure what is so hard to understand here @tstuefe . A thread is hit with a SIGILL and we report that now, but we don't report _why_ it was hit with the SIGILL. If there were only one reason (like it executed an illegal instruction) then it would be obvious, but we have hijacked SIGILL as a generic "something happened" signal. So the proposal here is to record the identity of the thread being sent a SIGILL due to a handshake or safepoint timeout, so that when that thread responds to the SIGILL it can see that is why it got it and report that fact. If a different thread also got a SIGILL for a different reason we don't want it reporting it was due to the timeout mechanism.

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

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

From stuefe at openjdk.org  Fri Jul 18 13:24:53 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 18 Jul 2025 13:24:53 GMT
Subject: RFR: 8359820: Improve handshake/safepoint timeout diagnostic
 messages [v3]
In-Reply-To: <zy9KDg1C9w_yzg0pnrChok7vk1LzsNU-YaxjyyH1YAs=.c59ba262-f7d3-48eb-a6da-5fda887a916b@github.com>
References: <FZ87bVfDootrLeANGguMFpcTm7X8AEqzuKVQspmSkmE=.4484090b-ba49-498c-bb07-71d22fd34823@github.com>
 <Ql0l4nxCeZx7oGpm0DZHnbBxBo0veODNL7mRc7q0RH0=.13d48a16-ea7a-4b2f-aa9c-bee78b78a80d@github.com>
 <YaBMm44ml79pjuOdq3VZ7vRhANxOWgf4THGH_E8B1kg=.e7380cf2-fb19-4d94-a9bc-ee089c376564@github.com>
 <jLZV7rtCIsjW4GeQcjbOkNwyyEUXJTmZpwh5aawQ8Js=.3cb69104-0be8-4308-95db-ac7284e18bba@github.com>
 <cgkjiHoYRu54YNZCKG6Pvv2kysBEgIi4AhuPcnFNjVc=.bbee0900-5af7-4ad3-a51d-87bdac9e1f07@github.com>
 <zy9KDg1C9w_yzg0pnrChok7vk1LzsNU-YaxjyyH1YAs=.c59ba262-f7d3-48eb-a6da-5fda887a916b@github.com>
Message-ID: <qFFDyzlvuX3MvOV0ueUzHbKeQmR4vdd5YI0em6tIgns=.33ad3edb-2a76-4749-af3a-5f8523865728@github.com>

On Fri, 18 Jul 2025 10:46:45 GMT, Anton Artemov <duke at openjdk.org> wrote:

>>> > I have nothing against making this clearer, just saying that the info is already kind of there.
>>> 
>>> Yes, but there are a few reasons a SIGILL may have been fired at a thread, so it would be useful to get a clear indication of exactly why it happened. Not everyone will realize/know that SIGILL happens because of a timeout in handshake/safepoint.
>> 
>> I still don't get it.
>> 
>> - Is the receiving thread the one meant to receive the SIGILL? Then why print this at all, we have callstack and thread info already?
>> - Is the receiving thread not the originally intended recipient? But how? This can only happen either if the original recipient thread blocked - which we don't do in hotspot code AFAIK, so it could only be a library method that temporary sets a signal mask - or if there is a bug in the sending code - in which case we should fix it?
>> - Is the SIGILL completely unrelated to the safepoint? Then why print the information?
>
>> * Is the receiving thread the one meant to receive the SIGILL? Then why print this at all, we have callstack and thread info already?
> 
> Yes, the receiving thread is the one to receive the SIGILL. I agree that the changes introduce a degree of redundancy, but it is difficult to see by looking at the thread callstack that it was killed by the timeout mechanism of the handshake. I found it by looking at events log, see the discussion in JBS. 
> 
> 
>> * Is the receiving thread not the originally intended recipient? But how? This can only happen either if the original recipient thread blocked - which we don't do in hotspot code AFAIK, so it could only be a library method that temporary sets a signal mask - or if there is a bug in the sending code - in which case we should fix it?
> 
> I think I already described a possible situation: if the receiver does not report the crash within 3 seconds, then a fatal error will be reported by the calling thread. However, it may happen that any other thread receives SIGILL for any other reason within that time interval. But the "busy" thread is already in the "communicative" variable, which will not be the signal receiver in this particular case. I do not really know if this situation is just hypothetical or ever occurred in practice.
> 
>> * Is the SIGILL completely unrelated to the safepoint? Then why print the information?
> 
> No, it is intentionally fired by the timeout handler. Quote from mr. Shipilev, see the issue discussion: "The intent for SIGILL is to trigger the crash at the thread that blocks handshake/safepoint sync. E.g. a Java thread that is stuck on miscompiled loop without safepoint checks. Or some VM code that spins without VM transitions. See [JDK-8219584](https://bugs.openjdk.org/browse/JDK-8219584). This feature is remarkably useful in the field, used this dozens of times. So whatever we do, we need to keep printing the instructions block and hopefully a backtrace."

@toxaart Thank you for laying it out to me.

So SDE slowed things down, we did not reach the safepoint, the timeout mechanism fired a SIGILL to the slow thread, the slow thread was not fast enough to end the JVM, and the sending thread then executed the fatal("Handshake timeout")? 

Which thread won the hs-err pid writing?  Was (A) the winner, and it started error handling? And you maybe saw a "Thread XXX also had an error" line from the sending thread? 

Or (B) did the slow thread not even get the signal, and the hs_err file you got was from the fatal("Handshake timeout") in the sending thread?

(B) would be odd; a signal sent with pthread_kill had not been delivered to the target thread for three seconds :-( is signal delivery on SDE broken, or is it just really slow?

In any case, I think I understand now that you try to improve the hs_err printout for case (A), right? If so, sure, that makes sense.

What confused me was your printout `timed out thread XXXXX`, which suggested to me that the receiving thread could be a different one from the one that should have been interrupted. But I missed the `if (handshakeTimedOutThread == p2i(_thread))` condition right above that.

> > * Is the receiving thread the one meant to receive the SIGILL? Then why print this at all, we have callstack and thread info already?
> 
> Yes, the receiving thread is the one to receive the SIGILL. I agree that the changes introduce a degree of redundancy, but it is difficult to see by looking at the thread callstack that it was killed by the timeout mechanism of the handshake. I found it by looking at events log, see the discussion in JBS.

No problem, its fine to make things clearer.

> 
> > * Is the receiving thread not the originally intended recipient? But how? This can only happen either if the original recipient thread blocked - which we don't do in hotspot code AFAIK, so it could only be a library method that temporary sets a signal mask - or if there is a bug in the sending code - in which case we should fix it?
> 
> I think I already described a possible situation: if the receiver does not report the crash within 3 seconds, then a fatal error will be reported by the calling thread.

To help with this case, I suggest a simple addition in handshake.cpp:


-  fatal("Handshake timeout");
+  fatal("Thread " PTR_FORMAT " has not cleared handshake op: " PTR_FORMAT ", then failed to terminate JVM",
+        p2i(target), p2i(op));
 }


which will show a clearer message at the start of the hs-err file, in case we don't have the VM output.

> However, it may happen that any other thread receives SIGILL for any other reason within that time interval. But the "busy" thread is already in the "communicative" variable, which will not be the signal receiver in this particular case. I do not really know if this situation is just hypothetical or ever occurred in practice.

Yes, it could happen. The mechanism could be improved by storing the fact that a SIGILL has been sent to thread X not in a global variable but in the `Thread` structure of X. Then, in VMError, one checks if the current thread had been the target of a recent pthread_kill, and only write "sent by xxx" in that case. I ignore here the possible case of multiple senders one receiver, because I think that is extremely unlikely.

Not saying you have to do this. Can also be done in a later RFE.

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

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

From stuefe at openjdk.org  Fri Jul 18 13:36:49 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 18 Jul 2025 13:36:49 GMT
Subject: RFR: 8359820: Improve handshake/safepoint timeout diagnostic
 messages [v3]
In-Reply-To: <qFFDyzlvuX3MvOV0ueUzHbKeQmR4vdd5YI0em6tIgns=.33ad3edb-2a76-4749-af3a-5f8523865728@github.com>
References: <FZ87bVfDootrLeANGguMFpcTm7X8AEqzuKVQspmSkmE=.4484090b-ba49-498c-bb07-71d22fd34823@github.com>
 <Ql0l4nxCeZx7oGpm0DZHnbBxBo0veODNL7mRc7q0RH0=.13d48a16-ea7a-4b2f-aa9c-bee78b78a80d@github.com>
 <YaBMm44ml79pjuOdq3VZ7vRhANxOWgf4THGH_E8B1kg=.e7380cf2-fb19-4d94-a9bc-ee089c376564@github.com>
 <jLZV7rtCIsjW4GeQcjbOkNwyyEUXJTmZpwh5aawQ8Js=.3cb69104-0be8-4308-95db-ac7284e18bba@github.com>
 <cgkjiHoYRu54YNZCKG6Pvv2kysBEgIi4AhuPcnFNjVc=.bbee0900-5af7-4ad3-a51d-87bdac9e1f07@github.com>
 <zy9KDg1C9w_yzg0pnrChok7vk1LzsNU-YaxjyyH1YAs=.c59ba262-f7d3-48eb-a6da-5fda887a916b@github.com>
 <qFFDyzlvuX3MvOV0ueUzHbKeQmR4vdd5YI0em6tIgns=.33ad3edb-2a76-4749-af3a-5f8523865728@github.com>
Message-ID: <vLfJ8fWvR6IxHOV_ltFGiUEE4hsciKo7kfHzizp1zx4=.f4f51dbd-2a7d-4756-9679-c3485bc94688@github.com>

On Fri, 18 Jul 2025 13:22:02 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>>> * Is the receiving thread the one meant to receive the SIGILL? Then why print this at all, we have callstack and thread info already?
>> 
>> Yes, the receiving thread is the one to receive the SIGILL. I agree that the changes introduce a degree of redundancy, but it is difficult to see by looking at the thread callstack that it was killed by the timeout mechanism of the handshake. I found it by looking at events log, see the discussion in JBS. 
>> 
>> 
>>> * Is the receiving thread not the originally intended recipient? But how? This can only happen either if the original recipient thread blocked - which we don't do in hotspot code AFAIK, so it could only be a library method that temporary sets a signal mask - or if there is a bug in the sending code - in which case we should fix it?
>> 
>> I think I already described a possible situation: if the receiver does not report the crash within 3 seconds, then a fatal error will be reported by the calling thread. However, it may happen that any other thread receives SIGILL for any other reason within that time interval. But the "busy" thread is already in the "communicative" variable, which will not be the signal receiver in this particular case. I do not really know if this situation is just hypothetical or ever occurred in practice.
>> 
>>> * Is the SIGILL completely unrelated to the safepoint? Then why print the information?
>> 
>> No, it is intentionally fired by the timeout handler. Quote from mr. Shipilev, see the issue discussion: "The intent for SIGILL is to trigger the crash at the thread that blocks handshake/safepoint sync. E.g. a Java thread that is stuck on miscompiled loop without safepoint checks. Or some VM code that spins without VM transitions. See [JDK-8219584](https://bugs.openjdk.org/browse/JDK-8219584). This feature is remarkably useful in the field, used this dozens of times. So whatever we do, we need to keep printing the instructions block and hopefully a backtrace."
>
> @toxaart Thank you for laying it out to me.
> 
> So SDE slowed things down, we did not reach the safepoint, the timeout mechanism fired a SIGILL to the slow thread, the slow thread was not fast enough to end the JVM, and the sending thread then executed the fatal("Handshake timeout")? 
> 
> Which thread won the hs-err pid writing?  Was (A) the winner, and it started error handling? And you maybe saw a "Thread XXX also had an error" line from the sending thread? 
> 
> Or (B) did the slow thread not even get the signal, and the hs_err file you got was from the fatal("Handshake timeout") in the sending thread?
> 
> (B) would be odd; a signal sent with pthread_kill had not been delivered to the target thread for three seconds :-( is signal delivery on SDE broken, or is it just really slow?
> 
> In any case, I think I understand now that you try to improve the hs_err printout for case (A), right? If so, sure, that makes sense.
> 
> What confused me was your printout `timed out thread XXXXX`, which suggested to me that the receiving thread could be a different one from the one that should have been interrupted. But I missed the `if (handshakeTimedOutThread == p2i(_thread))` condition right above that.
> 
>> > * Is the receiving thread the one meant to receive the SIGILL? Then why print this at all, we have callstack and thread info already?
>> 
>> Yes, the receiving thread is the one to receive the SIGILL. I agree that the changes introduce a degree of redundancy, but it is difficult to see by looking at the thread callstack that it was killed by the timeout mechanism of the handshake. I found it by looking at events log, see the discussion in JBS.
> 
> No problem, its fine to make things clearer.
> 
>> 
>> > * Is the receiving thread not the originally intended recipient? But how? This can only happen either if the original recipient thread blocked - which we don't do in hotspot code AFAIK, so it could only be a library method that temporary sets a signal mask - or if there is a bug in the sending code - in which case we should fix it?
>> 
>> I think I already described a possible situation: if the receiver does not report the crash within 3 seconds, then a fatal error will be reported by the calling thread.
> 
> To help with this case, I suggest a simple addition in handshake.cpp:
> 
> 
> -  fatal("Handshake timeout");
> +  fatal("Thread " PTR_FORMAT " has not cleared handshake op: " PTR_FORMAT ", then failed to terminate JVM",
> +        p2i(target), p2i(op));
>  }
> 
> 
> which will show a clearer message at the start...

> Not sure what is so hard to understand here @tstuefe . A thread is hit with a SIGILL and we report that now, but we don't report _why_ it was hit with the SIGILL. If there were only one reason (like it executed an illegal instruction) then it would be obvious, but we have hijacked SIGILL as a generic "something happened" signal. So the proposal here is to record the identity of the thread being sent a SIGILL due to a handshake or safepoint timeout, so that when that thread responds to the SIGILL it can see that is why it got it and report that fact. If a different thread also got a SIGILL for a different reason we don't want it reporting it was due to the timeout mechanism.

Thank you, @dholmes-ora . I already answered Anton, but I get that now.

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

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

From stuefe at openjdk.org  Fri Jul 18 13:36:51 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 18 Jul 2025 13:36:51 GMT
Subject: RFR: 8359820: Improve handshake/safepoint timeout diagnostic
 messages [v4]
In-Reply-To: <2aTRSndt5OybRRiIk8n--gjyH6q5sqrVNDxPHDMefuk=.1c68c38e-4fb7-4343-841d-b2f13ac97072@github.com>
References: <FZ87bVfDootrLeANGguMFpcTm7X8AEqzuKVQspmSkmE=.4484090b-ba49-498c-bb07-71d22fd34823@github.com>
 <2aTRSndt5OybRRiIk8n--gjyH6q5sqrVNDxPHDMefuk=.1c68c38e-4fb7-4343-841d-b2f13ac97072@github.com>
Message-ID: <E4lUlgIwJt1cBfVtS7-8ZR3bG8XgWDYoehMXKkR8o8Y=.45e23948-b22d-4ae1-8e43-041913de84fa@github.com>

On Fri, 18 Jul 2025 09:14:39 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 one additional commit since the last revision:
> 
>   8359820: Addressed reviewer's comments

src/hotspot/share/runtime/safepoint.cpp line 70:

> 68: #include "utilities/systemMemoryBarrier.hpp"
> 69: 
> 70: intptr_t safepointTimedOutThread = p2i(nullptr);

Maybe not a global variable. 

I would either make this a static member of SafePoint and the other one a static member of Handshake, or (maybe simpler) both static members of VMError, plus accessors.

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

> 820:       if (_siginfo != nullptr && os::signal_sent_by_kill(_siginfo)) {
> 821:         if (handshakeTimedOutThread == p2i(_thread)) {
> 822:           st->print(" (sent by handshake timeout handler, timed out thread " PTR_FORMAT ")", handshakeTimedOutThread);

since this thread is the timeouted thread, I think printing the thread's pointer is redundant and possibly confusing (it confused me). I would just write "sent by handshake timeout handler".

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

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

From heidinga at openjdk.org  Fri Jul 18 14:17:51 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Fri, 18 Jul 2025 14:17:51 GMT
Subject: RFR: 8356941: AbstractMethodError in HotSpot Due to Incorrect
 Handling of Private Method [v3]
In-Reply-To: <3e1yf3BEjmb_QhWGPVYtuejGRWP5T7pzFDXBs6WOi7w=.e1381a68-f6f5-4cb2-884e-6040edf8aadf@github.com>
References: <qyWNTs0IOlf128C4ZdvOp9TE7O4w7bPaz2hJfHseIUk=.4a298588-6aff-471a-927b-beb3c9f0b194@github.com>
 <3e1yf3BEjmb_QhWGPVYtuejGRWP5T7pzFDXBs6WOi7w=.e1381a68-f6f5-4cb2-884e-6040edf8aadf@github.com>
Message-ID: <QjIpOlKmu83vTE5dXpop94HUIeYXGsjXCmIsOP3SPPk=.8de72876-a4e6-4101-8bc2-73d3954d3393@github.com>

On Wed, 16 Jul 2025 07:20:16 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Private methods should never be considered as the implementation of a default method.
>> 
>> The first commit adds some additional logging I used to track down what was happening. I like it, but if reviewers think it too much I can drop it.
>> 
>> The second commit is the actual fix to exclude private methods, and adds the missing test case to the existing defmeth tests.
>> 
>> Testing:
>>  - tiers 1-4
>> 
>> Thanks
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Additional logging to identify the problem"
>   
>   This reverts commit 60871844d32cbc58ea97b2186a2758e85613afa4.

Current change is also fine.  Both suggestions are more for leaving breadcrumbs to help the next person to dig thru this code

src/hotspot/share/classfile/defaultMethods.cpp line 667:

> 665:         if (!already_in_vtable_slots(slots, m)) {
> 666:           Method* impl = klass->lookup_method(m->name(), m->signature());
> 667:           if (impl == nullptr || impl->is_overpass() || impl->is_static() || impl->is_private()) {

Trying to capture your and Coleen's discussion in a comment.  Does this correctly cover the gist of the discussion?

Suggestion:

         // Unless the klass provides a non-static public or package-private method for this name
         // & sig combo, we need to add the EmptyVtableSlot so default method processing finds
         // the correct candidate to fill in the slot later.
          if (impl == nullptr || impl->is_overpass() || impl->is_static() || impl->is_private()) {

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

Marked as reviewed by heidinga (no project role).

PR Review: https://git.openjdk.org/jdk/pull/26302#pullrequestreview-3033634330
PR Review Comment: https://git.openjdk.org/jdk/pull/26302#discussion_r2216102680

From heidinga at openjdk.org  Fri Jul 18 14:17:52 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Fri, 18 Jul 2025 14:17:52 GMT
Subject: RFR: 8356941: AbstractMethodError in HotSpot Due to Incorrect
 Handling of Private Method [v3]
In-Reply-To: <QjIpOlKmu83vTE5dXpop94HUIeYXGsjXCmIsOP3SPPk=.8de72876-a4e6-4101-8bc2-73d3954d3393@github.com>
References: <qyWNTs0IOlf128C4ZdvOp9TE7O4w7bPaz2hJfHseIUk=.4a298588-6aff-471a-927b-beb3c9f0b194@github.com>
 <3e1yf3BEjmb_QhWGPVYtuejGRWP5T7pzFDXBs6WOi7w=.e1381a68-f6f5-4cb2-884e-6040edf8aadf@github.com>
 <QjIpOlKmu83vTE5dXpop94HUIeYXGsjXCmIsOP3SPPk=.8de72876-a4e6-4101-8bc2-73d3954d3393@github.com>
Message-ID: <mE11_KeN-1Ju0JpP0odIuX6q4lvjm0N87Ig7ijAsrJQ=.39a9bed8-147e-4533-a404-e91b3ccbb96c@github.com>

On Fri, 18 Jul 2025 13:53:55 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert "Additional logging to identify the problem"
>>   
>>   This reverts commit 60871844d32cbc58ea97b2186a2758e85613afa4.
>
> src/hotspot/share/classfile/defaultMethods.cpp line 667:
> 
>> 665:         if (!already_in_vtable_slots(slots, m)) {
>> 666:           Method* impl = klass->lookup_method(m->name(), m->signature());
>> 667:           if (impl == nullptr || impl->is_overpass() || impl->is_static() || impl->is_private()) {
> 
> Trying to capture your and Coleen's discussion in a comment.  Does this correctly cover the gist of the discussion?
> 
> Suggestion:
> 
>          // Unless the klass provides a non-static public or package-private method for this name
>          // & sig combo, we need to add the EmptyVtableSlot so default method processing finds
>          // the correct candidate to fill in the slot later.
>           if (impl == nullptr || impl->is_overpass() || impl->is_static() || impl->is_private()) {

Alternatively, this same series of checks occurs in `FindMethodsByErasedSig::visit()` with a long comment there about the set of possible methods.  Is it worth replacing both sets of checks with a helper method that encapsulates the set of decisions?  


// Private interface methods are not candidates for default methods.
// invokespecial to private interface methods doesn't use default method logic.
// Private class methods are not candidates for default methods.
// Private methods do not override default methods, so need to perform
// default method inheritance without including private methods.
// The overpasses are your supertypes' errors, we do not include them.
static bool is_not_excluded_method(Method* m) {
    if (m != nullptr && !m->is_static() && !m->is_overpass() && !m->is_private()) {
       return true;
    }
    return false;
}


The name isn't great - feel free to replace with something better - but the idea is to capture the requirements in one place

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26302#discussion_r2216148094

From mbaesken at openjdk.org  Fri Jul 18 14:45:48 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 18 Jul 2025 14:45:48 GMT
Subject: RFR: 8360941: [ubsan] MemRegion::end() shows runtime error:
 applying non-zero offset 8388608 to null pointer [v5]
In-Reply-To: <b4vLCFRr3Q6g9mcWOVo7kf4W97q63WtkQ4pPdK8g8Eo=.44c119fc-86d2-4e8c-9ca5-930875c820fe@github.com>
References: <LP6FbAxZpwbGf6lkNvLcSRSEOu-mYKjWGAJYBSIMcyk=.775595dc-7f73-4248-a235-f4b58933396b@github.com>
 <b4vLCFRr3Q6g9mcWOVo7kf4W97q63WtkQ4pPdK8g8Eo=.44c119fc-86d2-4e8c-9ca5-930875c820fe@github.com>
Message-ID: <qSGzd33U748NvamJ3s8VvT9pzSa2dCA_7pZPzQA9nn4=.7f595fba-b518-47c2-8e30-2325aaed729c@github.com>

On Fri, 18 Jul 2025 08:21:48 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When running HS test
>> gtest/GTestWrapper.java
>> with ubsan-enabled binaries on macOS aarch64, the following error is reported (did not see this so far on Linux but there we use gcc and it seems the gcc/ubsan checks are a bit more limited).
>> 
>> test/hotspot/gtest/gc/g1/test_freeRegionList.cpp:37: Failure
>> Death test: child_G1FreeRegionList_length_()
>>     Result: died but not with expected exit code:
>>             Terminated by signal 6 (core dumped)
>> Actual msg:
>> 
>> [  DEATH   ] /jdk/src/hotspot/share/memory/memRegion.hpp:66:43: runtime error: applying non-zero offset 8388608 to null pointer
>> [  DEATH   ]     #0 0x108afd6f4 in MemRegion::end() const+0x84 (libjvm.dylib:arm64+0x16556f4)
>> [  DEATH   ]     #1 0x1075c68a0 in G1FreeRegionList_length_other_vm_Test::TestBody()+0x380 (libjvm.dylib:arm64+0x11e8a0)
>> [  DEATH   ]     #2 0x1090f3bb0 in testing::Test::Run()+0xc0 (libjvm.dylib:arm64+0x1c4bbb0)
>> [  DEATH   ]     #3 0x1090f4d94 in testing::TestInfo::Run()+0x1e4 (libjvm.dylib:arm64+0x1c4cd94)
>> [  DEATH   ]     #4 0x1090f6754 in testing::TestSuite::Run()+0x43c (libjvm.dylib:arm64+0x1c4e754)
>> [  DEATH   ]     #5 0x109103ca0 in testing::internal::UnitTestImpl::RunAllTests()+0x48c (libjvm.dylib:arm64+0x1c5bca0)
>> [  DEATH   ]     #6 0x109103588 in testing::UnitTest::Run()+0x78 (libjvm.dylib:arm64+0x1c5b588)
>> [  DEATH   ]     #7 0x1074a9ac0 in runUnitTestsInner(int, char**)+0x724 (libjvm.dylib:arm64+0x1ac0)
>> [  DEATH   ]     #8 0x102dc3f18 in main+0x2c (gtestLauncher:arm64+0x100003f18)
>> [  DEATH   ]     #9 0x196fea0dc  (<unknown module>)
>> [  DEATH   ] 
>> [  DEATH   ] SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /jdk/src/hotspot/share/memory/memRegion.hpp:66:43 in 
>> [  DEATH   ] 
>> 
>> 
>> 
>> Seems the test_freeRegionList.cpp uses a special MemRegion starting at nullptr ; but this causes a bit of trouble when adding to start == nullptr .
>> So far I see this issue just in the gtest, seems other MemRegion objects do not start at nullptr .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify test coding

Hi Kim, should I add you as contributor  ?

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

PR Comment: https://git.openjdk.org/jdk/pull/26216#issuecomment-3089724913

From mbaesken at openjdk.org  Fri Jul 18 14:45:49 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 18 Jul 2025 14:45:49 GMT
Subject: RFR: 8360941: [ubsan] MemRegion::end() shows runtime error:
 applying non-zero offset 8388608 to null pointer [v4]
In-Reply-To: <uBB4IJ6UUQ5t2fLKHyZlvYJRMA_Im_eHWCwFUNwrT70=.a6ff3604-8eda-4bb6-8565-00c8db6c049c@github.com>
References: <LP6FbAxZpwbGf6lkNvLcSRSEOu-mYKjWGAJYBSIMcyk=.775595dc-7f73-4248-a235-f4b58933396b@github.com>
 <jpNR9jM5WVyQ9iNR4rGc0GCaGTVXB75wxUVXVGb6GGg=.6ca2dd58-fb93-4ff5-b513-b17de9816f54@github.com>
 <uBB4IJ6UUQ5t2fLKHyZlvYJRMA_Im_eHWCwFUNwrT70=.a6ff3604-8eda-4bb6-8565-00c8db6c049c@github.com>
Message-ID: <1x72FO3QjEVGfvrDlYKNVbshR-O3MNOomkzPnQec02Q=.5b7a31a3-87b4-4a1c-b265-e2692ac64f0a@github.com>

On Fri, 18 Jul 2025 00:52:19 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Avoid assertions, align address in test
>
> test/hotspot/gtest/gc/g1/test_freeRegionList.cpp line 48:
> 
>> 46:   // does not access it.
>> 47:   int val = 1;
>> 48:   HeapWord* ptr = reinterpret_cast<HeapWord*>(&val);
> 
> The initial value for `val` doesn't matter, since we're using its address rather than value.
> And the cast could be removed by changing the type of `val`, leading to something like this:
> 
> HeapWord val{};
> HeapWord* ptr = align_up(&val, os::vm_page_size());

I adjusted the coding .

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26216#discussion_r2216231456

From coleenp at openjdk.org  Fri Jul 18 14:51:54 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 18 Jul 2025 14:51:54 GMT
Subject: RFR: 8356941: AbstractMethodError in HotSpot Due to Incorrect
 Handling of Private Method [v3]
In-Reply-To: <mE11_KeN-1Ju0JpP0odIuX6q4lvjm0N87Ig7ijAsrJQ=.39a9bed8-147e-4533-a404-e91b3ccbb96c@github.com>
References: <qyWNTs0IOlf128C4ZdvOp9TE7O4w7bPaz2hJfHseIUk=.4a298588-6aff-471a-927b-beb3c9f0b194@github.com>
 <3e1yf3BEjmb_QhWGPVYtuejGRWP5T7pzFDXBs6WOi7w=.e1381a68-f6f5-4cb2-884e-6040edf8aadf@github.com>
 <QjIpOlKmu83vTE5dXpop94HUIeYXGsjXCmIsOP3SPPk=.8de72876-a4e6-4101-8bc2-73d3954d3393@github.com>
 <mE11_KeN-1Ju0JpP0odIuX6q4lvjm0N87Ig7ijAsrJQ=.39a9bed8-147e-4533-a404-e91b3ccbb96c@github.com>
Message-ID: <-m7nBo3LfZ5o3AHsOSQNvH6JNk2DyjYqvP0j3AVXi-c=.494697a9-6e1c-4146-ab6b-e0f7cac73c1f@github.com>

On Fri, 18 Jul 2025 14:13:06 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> src/hotspot/share/classfile/defaultMethods.cpp line 667:
>> 
>>> 665:         if (!already_in_vtable_slots(slots, m)) {
>>> 666:           Method* impl = klass->lookup_method(m->name(), m->signature());
>>> 667:           if (impl == nullptr || impl->is_overpass() || impl->is_static() || impl->is_private()) {
>> 
>> Trying to capture your and Coleen's discussion in a comment.  Does this correctly cover the gist of the discussion?
>> 
>> Suggestion:
>> 
>>          // Unless the klass provides a non-static public or package-private method for this name
>>          // & sig combo, we need to add the EmptyVtableSlot so default method processing finds
>>          // the correct candidate to fill in the slot later.
>>           if (impl == nullptr || impl->is_overpass() || impl->is_static() || impl->is_private()) {
>
> Alternatively, this same series of checks occurs in `FindMethodsByErasedSig::visit()` with a long comment there about the set of possible methods.  Is it worth replacing both sets of checks with a helper method that encapsulates the set of decisions?  
> 
> 
> // Private interface methods are not candidates for default methods.
> // invokespecial to private interface methods doesn't use default method logic.
> // Private class methods are not candidates for default methods.
> // Private methods do not override default methods, so need to perform
> // default method inheritance without including private methods.
> // The overpasses are your supertypes' errors, we do not include them.
> static bool is_not_excluded_method(Method* m) {
>     if (m != nullptr && !m->is_static() && !m->is_overpass() && !m->is_private()) {
>        return true;
>     }
>     return false;
> }
> 
> 
> The name isn't great - feel free to replace with something better - but the idea is to capture the requirements in one place

I like this idea and I don't think there's harm in using this condition in the upper loop also, even though we couldn't find a case of a private method not getting to the code to create the empty vtable slots.  I tested the upper loop with that case and even though we couldn't prove it's needed, I think it's also harmless to make it the same.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26302#discussion_r2216251232

From duke at openjdk.org  Fri Jul 18 15:10:35 2025
From: duke at openjdk.org (Anton Artemov)
Date: Fri, 18 Jul 2025 15:10:35 GMT
Subject: RFR: 8359820: Improve handshake/safepoint timeout diagnostic
 messages [v5]
In-Reply-To: <FZ87bVfDootrLeANGguMFpcTm7X8AEqzuKVQspmSkmE=.4484090b-ba49-498c-bb07-71d22fd34823@github.com>
References: <FZ87bVfDootrLeANGguMFpcTm7X8AEqzuKVQspmSkmE=.4484090b-ba49-498c-bb07-71d22fd34823@github.com>
Message-ID: <ggMtbeagKlcBKFYnxX9QaDkzIx47EKoRnPIjetMkxCo=.4f3fd07f-fb9a-42c5-9a7d-2ae1f77f093b@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 incrementally with two additional commits since the last revision:

 - 8359820: Fixed spaces
 - 8359820: Addressed reviewer's comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26309/files
  - new: https://git.openjdk.org/jdk/pull/26309/files/27cb77d2..9ccf0960

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

  Stats: 37 lines in 7 files changed: 21 ins; 8 del; 8 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  Fri Jul 18 15:10:35 2025
From: duke at openjdk.org (Anton Artemov)
Date: Fri, 18 Jul 2025 15:10:35 GMT
Subject: RFR: 8359820: Improve handshake/safepoint timeout diagnostic
 messages [v3]
In-Reply-To: <qFFDyzlvuX3MvOV0ueUzHbKeQmR4vdd5YI0em6tIgns=.33ad3edb-2a76-4749-af3a-5f8523865728@github.com>
References: <FZ87bVfDootrLeANGguMFpcTm7X8AEqzuKVQspmSkmE=.4484090b-ba49-498c-bb07-71d22fd34823@github.com>
 <Ql0l4nxCeZx7oGpm0DZHnbBxBo0veODNL7mRc7q0RH0=.13d48a16-ea7a-4b2f-aa9c-bee78b78a80d@github.com>
 <YaBMm44ml79pjuOdq3VZ7vRhANxOWgf4THGH_E8B1kg=.e7380cf2-fb19-4d94-a9bc-ee089c376564@github.com>
 <jLZV7rtCIsjW4GeQcjbOkNwyyEUXJTmZpwh5aawQ8Js=.3cb69104-0be8-4308-95db-ac7284e18bba@github.com>
 <cgkjiHoYRu54YNZCKG6Pvv2kysBEgIi4AhuPcnFNjVc=.bbee0900-5af7-4ad3-a51d-87bdac9e1f07@github.com>
 <zy9KDg1C9w_yzg0pnrChok7vk1LzsNU-YaxjyyH1YAs=.c59ba262-f7d3-48eb-a6da-5fda887a916b@github.com>
 <qFFDyzlvuX3MvOV0ueUzHbKeQmR4vdd5YI0em6tIgns=.33ad3edb-2a76-4749-af3a-5f8523865728@github.com>
Message-ID: <EKx-SxWCHL5ZzNEBQYeikeqWYSEqZQCCBBmMXlcgadQ=.199b707f-e106-4ca3-9e98-c2edacad766f@github.com>

On Fri, 18 Jul 2025 13:22:02 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Was (A) the winner, and it started error handling? And you maybe saw a "Thread XXX also had an error" line from the sending thread?

Yes, the slow thread started reporting, and I think I also observed the latter message as well. Note that the fatal error is still processed in the end of the timeout handler, but not reported by VMError, as it can report only one such error. 

So yes, we want to improve the reporting for case A: when a slow thread receives a SIGILL and dies being able to handle the error, we want to know if SIGILL came from handshake/safepoint timeout and print extra info if that is the case.  

> To help with this case, I suggest a simple addition in handshake.cpp:

Thanks, added to the latest change. 


> Yes, it could happen. The mechanism could be improved by storing the fact that a SIGILL has been sent to thread X not in a global variable but in the `Thread` structure of X. Then, in VMError, one checks if the current thread had been the target of a recent pthread_kill, and only write "sent by xxx" in that case. I ignore here the possible case of multiple senders one receiver, because I think that is extremely unlikely.

I think this would be a more invasive change, we can do it when there is a real need.

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

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

From duke at openjdk.org  Fri Jul 18 15:10:35 2025
From: duke at openjdk.org (Anton Artemov)
Date: Fri, 18 Jul 2025 15:10:35 GMT
Subject: RFR: 8359820: Improve handshake/safepoint timeout diagnostic
 messages [v4]
In-Reply-To: <E4lUlgIwJt1cBfVtS7-8ZR3bG8XgWDYoehMXKkR8o8Y=.45e23948-b22d-4ae1-8e43-041913de84fa@github.com>
References: <FZ87bVfDootrLeANGguMFpcTm7X8AEqzuKVQspmSkmE=.4484090b-ba49-498c-bb07-71d22fd34823@github.com>
 <2aTRSndt5OybRRiIk8n--gjyH6q5sqrVNDxPHDMefuk=.1c68c38e-4fb7-4343-841d-b2f13ac97072@github.com>
 <E4lUlgIwJt1cBfVtS7-8ZR3bG8XgWDYoehMXKkR8o8Y=.45e23948-b22d-4ae1-8e43-041913de84fa@github.com>
Message-ID: <Rkf0zlYRFRpBGRA9g5YX2uB_TpZxx1LKeZTtUB2XeQU=.1c9394a2-5753-4ea2-80d6-2b5f58ae2ca2@github.com>

On Fri, 18 Jul 2025 13:31:43 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8359820: Addressed reviewer's comments
>
> src/hotspot/share/runtime/safepoint.cpp line 70:
> 
>> 68: #include "utilities/systemMemoryBarrier.hpp"
>> 69: 
>> 70: intptr_t safepointTimedOutThread = p2i(nullptr);
> 
> Maybe not a global variable. 
> 
> I would either make this a static member of SafePoint and the other one a static member of Handshake, or (maybe simpler) both static members of VMError, plus accessors.

Good idea, moved to `VMError`.

> src/hotspot/share/utilities/vmError.cpp line 822:
> 
>> 820:       if (_siginfo != nullptr && os::signal_sent_by_kill(_siginfo)) {
>> 821:         if (handshakeTimedOutThread == p2i(_thread)) {
>> 822:           st->print(" (sent by handshake timeout handler, timed out thread " PTR_FORMAT ")", handshakeTimedOutThread);
> 
> since this thread is the timeouted thread, I think printing the thread's pointer is redundant and possibly confusing (it confused me). I would just write "sent by handshake timeout handler".

Addressed in the latest commit.

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

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

From stuefe at openjdk.org  Fri Jul 18 15:35:49 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 18 Jul 2025 15:35:49 GMT
Subject: RFR: 8359820: Improve handshake/safepoint timeout diagnostic
 messages [v5]
In-Reply-To: <ggMtbeagKlcBKFYnxX9QaDkzIx47EKoRnPIjetMkxCo=.4f3fd07f-fb9a-42c5-9a7d-2ae1f77f093b@github.com>
References: <FZ87bVfDootrLeANGguMFpcTm7X8AEqzuKVQspmSkmE=.4484090b-ba49-498c-bb07-71d22fd34823@github.com>
 <ggMtbeagKlcBKFYnxX9QaDkzIx47EKoRnPIjetMkxCo=.4f3fd07f-fb9a-42c5-9a7d-2ae1f77f093b@github.com>
Message-ID: <CtEV1DapHPJel42GVA8GJNEu8_kVfy10Ks7G0cK4-vQ=.af1b2796-f307-49f4-92ed-99779c085401@github.com>

On Fri, 18 Jul 2025 15:10:35 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: Fixed spaces
>  - 8359820: Addressed reviewer's comments

Ok thanks.

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

Marked as reviewed by stuefe (Reviewer).

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

From stuefe at openjdk.org  Fri Jul 18 17:00:06 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 18 Jul 2025 17:00:06 GMT
Subject: RFR: 8360941: [ubsan] MemRegion::end() shows runtime error:
 applying non-zero offset 8388608 to null pointer [v5]
In-Reply-To: <b4vLCFRr3Q6g9mcWOVo7kf4W97q63WtkQ4pPdK8g8Eo=.44c119fc-86d2-4e8c-9ca5-930875c820fe@github.com>
References: <LP6FbAxZpwbGf6lkNvLcSRSEOu-mYKjWGAJYBSIMcyk=.775595dc-7f73-4248-a235-f4b58933396b@github.com>
 <b4vLCFRr3Q6g9mcWOVo7kf4W97q63WtkQ4pPdK8g8Eo=.44c119fc-86d2-4e8c-9ca5-930875c820fe@github.com>
Message-ID: <9l8nkWWX39FODpab3SRAOMoKyYlbwdTLysBmTIN7YJ0=.46bd081b-f659-4753-8e2c-2776d2f46b5a@github.com>

On Fri, 18 Jul 2025 08:21:48 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When running HS test
>> gtest/GTestWrapper.java
>> with ubsan-enabled binaries on macOS aarch64, the following error is reported (did not see this so far on Linux but there we use gcc and it seems the gcc/ubsan checks are a bit more limited).
>> 
>> test/hotspot/gtest/gc/g1/test_freeRegionList.cpp:37: Failure
>> Death test: child_G1FreeRegionList_length_()
>>     Result: died but not with expected exit code:
>>             Terminated by signal 6 (core dumped)
>> Actual msg:
>> 
>> [  DEATH   ] /jdk/src/hotspot/share/memory/memRegion.hpp:66:43: runtime error: applying non-zero offset 8388608 to null pointer
>> [  DEATH   ]     #0 0x108afd6f4 in MemRegion::end() const+0x84 (libjvm.dylib:arm64+0x16556f4)
>> [  DEATH   ]     #1 0x1075c68a0 in G1FreeRegionList_length_other_vm_Test::TestBody()+0x380 (libjvm.dylib:arm64+0x11e8a0)
>> [  DEATH   ]     #2 0x1090f3bb0 in testing::Test::Run()+0xc0 (libjvm.dylib:arm64+0x1c4bbb0)
>> [  DEATH   ]     #3 0x1090f4d94 in testing::TestInfo::Run()+0x1e4 (libjvm.dylib:arm64+0x1c4cd94)
>> [  DEATH   ]     #4 0x1090f6754 in testing::TestSuite::Run()+0x43c (libjvm.dylib:arm64+0x1c4e754)
>> [  DEATH   ]     #5 0x109103ca0 in testing::internal::UnitTestImpl::RunAllTests()+0x48c (libjvm.dylib:arm64+0x1c5bca0)
>> [  DEATH   ]     #6 0x109103588 in testing::UnitTest::Run()+0x78 (libjvm.dylib:arm64+0x1c5b588)
>> [  DEATH   ]     #7 0x1074a9ac0 in runUnitTestsInner(int, char**)+0x724 (libjvm.dylib:arm64+0x1ac0)
>> [  DEATH   ]     #8 0x102dc3f18 in main+0x2c (gtestLauncher:arm64+0x100003f18)
>> [  DEATH   ]     #9 0x196fea0dc  (<unknown module>)
>> [  DEATH   ] 
>> [  DEATH   ] SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /jdk/src/hotspot/share/memory/memRegion.hpp:66:43 in 
>> [  DEATH   ] 
>> 
>> 
>> 
>> Seems the test_freeRegionList.cpp uses a special MemRegion starting at nullptr ; but this causes a bit of trouble when adding to start == nullptr .
>> So far I see this issue just in the gtest, seems other MemRegion objects do not start at nullptr .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify test coding

test/hotspot/gtest/gc/g1/test_freeRegionList.cpp line 50:

> 48:   HeapWord* ptr = align_up(&val, os::vm_page_size());
> 49: 
> 50:   MemRegion heap(ptr, num_regions_in_test * G1HeapRegion::GrainWords);

I would not do it this way. The test should not write into the region, but if someone does mess up and does it, you get weird crashes. Possibly in other threads, because MemRegion is larger than your stack, and your stack may border on other stacks. Easier to just crash right on accessing uncommitted memory:

Suggestion:

  const size_t szw = num_regions_in_test * G1HeapRegion::GrainWords;
  const size_t sz = szw * BytePerWord;
  char* addr = os::reserve_memory(sz, mtTest);
  MemRegion heap((HeapWord*)ptr, szw);

and then after the test release it: `os::release_memory(addr, szw);`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26216#discussion_r2216370697

From sspitsyn at openjdk.org  Fri Jul 18 18:47:43 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 18 Jul 2025 18:47:43 GMT
Subject: RFR: 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: <C54IPjQer4AezxFqKIjFRbkGnlLCitFZLL1mnr4O_gQ=.c53ac3cf-ceee-4260-afee-620b8a241ca5@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`

Thank you for the comments and suggestions!
I'll give it a try to get rid of the interrupt flag setting.

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

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

From syan at openjdk.org  Sat Jul 19 02:15:37 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 19 Jul 2025 02:15:37 GMT
Subject: RFR: 8359827: Test runtime/Thread/ThreadCountLimit.java should run
 exclusively
Message-ID: <KFZNv5pVvr7Rddlm5xifJz6VzPzlFkmO7XPXrdJGWHw=.0664dc6c-992a-473d-b974-b2c40e06f45b@github.com>

Hi all,

The test runtime/Thread/ThreadCountLimit.java was observed fails when run with other tests. The test start subprocess with [shell prefix command](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/Thread/ThreadCountLimit.java#L82) `ulimit -u 4096` which intend to limite the usage of thread number. But this will cause test fails when this test run with other tests. I create a demo to demonstrate that.

I start a java process which will create 5k threads, and then I can not start new java process with prefix `ulimit -u 4096` on the same machine.

<img width="1573" height="182" alt="image" src="https://github.com/user-attachments/assets/8dd53ade-cad7-4a2f-b5d9-d4b2d200b728" />


[ManyThreads.java.txt](https://github.com/user-attachments/files/21324354/ManyThreads.java.txt)

So it's necessary to make this test run sperately to make this test success.
Change has been verified locally, test-fix only, risk is low.

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

Commit messages:
 - add test/hotspot/jtreg/runtime/Thread/stress/TEST.properties
 - 8359827: Test runtime/Thread/ThreadCountLimit.java should run exclusively

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

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

From syan at openjdk.org  Sat Jul 19 02:28:39 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 19 Jul 2025 02:28:39 GMT
Subject: RFR: 8359827: Test runtime/Thread/ThreadCountLimit.java should run
 exclusively [v2]
In-Reply-To: <KFZNv5pVvr7Rddlm5xifJz6VzPzlFkmO7XPXrdJGWHw=.0664dc6c-992a-473d-b974-b2c40e06f45b@github.com>
References: <KFZNv5pVvr7Rddlm5xifJz6VzPzlFkmO7XPXrdJGWHw=.0664dc6c-992a-473d-b974-b2c40e06f45b@github.com>
Message-ID: <ChycL6uT1_9xEgldDbu37a-XnFdXjX3DCuQS2JBZi7w=.8cfa4026-208e-4b1f-a951-1cef8665481e@github.com>

> Hi all,
> 
> The test runtime/Thread/ThreadCountLimit.java was observed fails when run with other tests. The test start subprocess with [shell prefix command](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/Thread/ThreadCountLimit.java#L82) `ulimit -u 4096` which intend to limite the usage of thread number. But this will cause test fails when this test run with other tests. I create a demo to demonstrate that.
> 
> I start a java process which will create 5k threads, and then I can not start new java process with prefix `ulimit -u 4096` on the same machine.
> 
> <img width="1573" height="182" alt="image" src="https://github.com/user-attachments/assets/8dd53ade-cad7-4a2f-b5d9-d4b2d200b728" />
> 
> 
> [ManyThreads.java.txt](https://github.com/user-attachments/files/21324354/ManyThreads.java.txt)
> 
> So it's necessary to make this test run sperately to make this test success.
> Change has been verified locally, test-fix only, risk is low.

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

  update TEST.groups

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26401/files
  - new: https://git.openjdk.org/jdk/pull/26401/files/12a1b4c5..3c3c697d

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

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

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

From alanb at openjdk.org  Sat Jul 19 07:17:39 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 19 Jul 2025 07:17:39 GMT
Subject: RFR: 8306324: StopThread results in thread being marked as
 interrupted, leading to unexpected InterruptedException
In-Reply-To: <C54IPjQer4AezxFqKIjFRbkGnlLCitFZLL1mnr4O_gQ=.c53ac3cf-ceee-4260-afee-620b8a241ca5@github.com>
References: <sDAklD-arV33IpWiJwMkwUfNPMAmsr5cgboU4y0hjhk=.192cd7e5-f2a2-4b5c-83a9-5111bf1926ec@github.com>
 <C54IPjQer4AezxFqKIjFRbkGnlLCitFZLL1mnr4O_gQ=.c53ac3cf-ceee-4260-afee-620b8a241ca5@github.com>
Message-ID: <A5IyCn9ZPNhsCTgtJNWP_ifvQVgyhexroa6bSYP8Pfs=.77d8fb62-b165-4284-8f40-7c7b1563f73d@github.com>

On Fri, 18 Jul 2025 18:44:45 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`
>
> Thank you for the comments and suggestions!
> I'll give it a try to get rid of the interrupt flag setting.

@sspitsyn It might be useful to reach out to the IDEs to see what they are doing. From a quick test with IntelliJ then it appears to invoke both StopThread and InterruptThread when "Exception to Throw" is used. In that case, it means that Thread.sleep will wakeup, even if StopThread doesn't interrupt.

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

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

From mdonovan at openjdk.org  Sun Jul 20 17:21:41 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Sun, 20 Jul 2025 17:21:41 GMT
Subject: RFR: 8356438: Update OutputAnalyzer to optionally print process
 output as it happens [v2]
In-Reply-To: <_aliNvujYU-gs7CUS7oB8VPK595xV4OLnd82vJwYTIY=.6b041c7e-3907-4217-b8ef-a59404ac0a08@github.com>
References: <cP-uMB2zwWrYPT2EOx-VpGAIaLjQY1YgkdQwehdjfo8=.d99ee1cf-5f91-40de-a5d1-fe6b762d1673@github.com>
 <J_G9wvyovxUuO0JdFMqnD7jvqUflEglF5L7qqvBc6-w=.e0def3d2-eb40-4167-b304-143f9d4c615d@github.com>
 <_aliNvujYU-gs7CUS7oB8VPK595xV4OLnd82vJwYTIY=.6b041c7e-3907-4217-b8ef-a59404ac0a08@github.com>
Message-ID: <NGriatYqq8l8ITZXKZRgM2um-GumOBDjsABJatlBR2o=.3a57360e-34c8-467b-8ca3-619c62d4abe4@github.com>

On Wed, 18 Jun 2025 04:41:06 GMT, David Holmes <dholmes at openjdk.org> wrote:

> 
> I see a few tests that do that, nearly all of which are network tests. It is not something I was familiar with. But it doesn't seem right to me that a particular test would use that property to change the behaviour of `OutputAnalyzer`. I also don't think the test should have to opt-in to this kind of behaviour rather than it being directly controlled by the person running the tests. To that end I would see `OutputAnalyzer` examining a specific property, e.g. `OutputAnalyzer.printToStdStreams` to control this.

I didn't mean to suggest that `OutputAnalyzer` uses the `test.debug` property directly, only that if `OutpuAnalyzer` had a constructor that took a boolean argument, the argument _could_ be set based on the value of `test.debug`...

`OutputAnalyzer oa = new OutputAnalyzer(myProcess, Boolean.getBoolean("test.debug"));`

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

PR Comment: https://git.openjdk.org/jdk/pull/25587#issuecomment-3094659115

From dholmes at openjdk.org  Sun Jul 20 21:55:49 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 20 Jul 2025 21:55:49 GMT
Subject: RFR: 8359820: Improve handshake/safepoint timeout diagnostic
 messages [v5]
In-Reply-To: <ggMtbeagKlcBKFYnxX9QaDkzIx47EKoRnPIjetMkxCo=.4f3fd07f-fb9a-42c5-9a7d-2ae1f77f093b@github.com>
References: <FZ87bVfDootrLeANGguMFpcTm7X8AEqzuKVQspmSkmE=.4484090b-ba49-498c-bb07-71d22fd34823@github.com>
 <ggMtbeagKlcBKFYnxX9QaDkzIx47EKoRnPIjetMkxCo=.4f3fd07f-fb9a-42c5-9a7d-2ae1f77f093b@github.com>
Message-ID: <nm_TxYRfv8-2L8rRt-HZE7Cchc4SarBu98N15t6lHdI=.aeba6656-edff-4066-b5ad-0a11b91091c3@github.com>

On Fri, 18 Jul 2025 15:10:35 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: Fixed spaces
>  - 8359820: Addressed reviewer's comments

The structure of this looks good, but I have a few remaining nits. Thanks.

src/hotspot/share/runtime/handshake.cpp line 214:

> 212:   }
> 213:   if (target != nullptr) {
> 214:     fatal("Thread " PTR_FORMAT " has not cleared handshake op: " PTR_FORMAT ", then failed to terminate JVM", p2i(target), p2i(op));

Suggestion:

    fatal("Thread " PTR_FORMAT " has not cleared handshake op %s, and failed to terminate the JVM", p2i(target), op->name());

The earlier logging statement that uses `p2i(op)` relies on an even earlier logging statement (line 189/190) that reports the name and the `p2i` value. But the fatal error message can't rely on using logging information to map the `p2i` value back to a name, so we need the name directly.

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

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

Suggestion:

volatile intptr_t VMError::_handshake_timeout_thread = p2i(nullptr);
volatile intptr_t VMError::_safepoint_timeout_thread = p2i(nullptr);

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

> 1338: }
> 1339: 
> 1340: void VMError::set_handshake_timed_out_thread(intptr_t x) {

Suggestion:

void VMError::set_handshake_timed_out_thread(intptr_t thread_addr) {

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

> 1342: }
> 1343: 
> 1344: void VMError::set_safepoint_timed_out_thread(intptr_t x) {

Suggestion:

void VMError::set_safepoint_timed_out_thread(intptr_t thread_addr) {

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26309#pullrequestreview-3036188379
PR Review Comment: https://git.openjdk.org/jdk/pull/26309#discussion_r2217970953
PR Review Comment: https://git.openjdk.org/jdk/pull/26309#discussion_r2217971507
PR Review Comment: https://git.openjdk.org/jdk/pull/26309#discussion_r2217972623
PR Review Comment: https://git.openjdk.org/jdk/pull/26309#discussion_r2217972740

From dholmes at openjdk.org  Sun Jul 20 22:35:28 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 20 Jul 2025 22:35:28 GMT
Subject: RFR: 8356941: AbstractMethodError in HotSpot Due to Incorrect
 Handling of Private Method [v4]
In-Reply-To: <qyWNTs0IOlf128C4ZdvOp9TE7O4w7bPaz2hJfHseIUk=.4a298588-6aff-471a-927b-beb3c9f0b194@github.com>
References: <qyWNTs0IOlf128C4ZdvOp9TE7O4w7bPaz2hJfHseIUk=.4a298588-6aff-471a-927b-beb3c9f0b194@github.com>
Message-ID: <ngzNrskgO75Qu3fKbg3n1mMyhQblVayU3uMq7c7AKd8=.05d1e429-34bc-497a-beb1-f603136942ac@github.com>

> Private methods should never be considered as the implementation of a default method.
> 
> The first commit adds some additional logging I used to track down what was happening. I like it, but if reviewers think it too much I can drop it.
> 
> The second commit is the actual fix to exclude private methods, and adds the missing test case to the existing defmeth tests.
> 
> Testing:
>  - tiers 1-4
> 
> Thanks

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

  Updated comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26302/files
  - new: https://git.openjdk.org/jdk/pull/26302/files/704d6387..56809168

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

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

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

From dholmes at openjdk.org  Sun Jul 20 22:47:02 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 20 Jul 2025 22:47:02 GMT
Subject: RFR: 8356941: AbstractMethodError in HotSpot Due to Incorrect
 Handling of Private Method [v5]
In-Reply-To: <qyWNTs0IOlf128C4ZdvOp9TE7O4w7bPaz2hJfHseIUk=.4a298588-6aff-471a-927b-beb3c9f0b194@github.com>
References: <qyWNTs0IOlf128C4ZdvOp9TE7O4w7bPaz2hJfHseIUk=.4a298588-6aff-471a-927b-beb3c9f0b194@github.com>
Message-ID: <WGeThEw5qnSvz2a3qvi31rGposTBBswNe-KY8HIL8sk=.951fcc7c-5157-43f5-9500-2548678b013b@github.com>

> Private methods should never be considered as the implementation of a default method.
> 
> The first commit adds some additional logging I used to track down what was happening. I like it, but if reviewers think it too much I can drop it.
> 
> The second commit is the actual fix to exclude private methods, and adds the missing test case to the existing defmeth tests.
> 
> Testing:
>  - tiers 1-4
> 
> Thanks

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

  typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26302/files
  - new: https://git.openjdk.org/jdk/pull/26302/files/56809168..d2797b0f

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

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

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

From dholmes at openjdk.org  Sun Jul 20 22:47:02 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 20 Jul 2025 22:47:02 GMT
Subject: RFR: 8356941: AbstractMethodError in HotSpot Due to Incorrect
 Handling of Private Method [v3]
In-Reply-To: <mE11_KeN-1Ju0JpP0odIuX6q4lvjm0N87Ig7ijAsrJQ=.39a9bed8-147e-4533-a404-e91b3ccbb96c@github.com>
References: <qyWNTs0IOlf128C4ZdvOp9TE7O4w7bPaz2hJfHseIUk=.4a298588-6aff-471a-927b-beb3c9f0b194@github.com>
 <3e1yf3BEjmb_QhWGPVYtuejGRWP5T7pzFDXBs6WOi7w=.e1381a68-f6f5-4cb2-884e-6040edf8aadf@github.com>
 <QjIpOlKmu83vTE5dXpop94HUIeYXGsjXCmIsOP3SPPk=.8de72876-a4e6-4101-8bc2-73d3954d3393@github.com>
 <mE11_KeN-1Ju0JpP0odIuX6q4lvjm0N87Ig7ijAsrJQ=.39a9bed8-147e-4533-a404-e91b3ccbb96c@github.com>
Message-ID: <xm6dYNoB_eiTmfXib4VlKMB8A3ivu5R4LhkJpEbC0tE=.97830263-3e96-44c7-840a-9a0cc8851add@github.com>

On Fri, 18 Jul 2025 14:13:06 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> src/hotspot/share/classfile/defaultMethods.cpp line 667:
>> 
>>> 665:         if (!already_in_vtable_slots(slots, m)) {
>>> 666:           Method* impl = klass->lookup_method(m->name(), m->signature());
>>> 667:           if (impl == nullptr || impl->is_overpass() || impl->is_static() || impl->is_private()) {
>> 
>> Trying to capture your and Coleen's discussion in a comment.  Does this correctly cover the gist of the discussion?
>> 
>> Suggestion:
>> 
>>          // Unless the klass provides a non-static public or package-private method for this name
>>          // & sig combo, we need to add the EmptyVtableSlot so default method processing finds
>>          // the correct candidate to fill in the slot later.
>>           if (impl == nullptr || impl->is_overpass() || impl->is_static() || impl->is_private()) {
>
> Alternatively, this same series of checks occurs in `FindMethodsByErasedSig::visit()` with a long comment there about the set of possible methods.  Is it worth replacing both sets of checks with a helper method that encapsulates the set of decisions?  
> 
> 
> // Private interface methods are not candidates for default methods.
> // invokespecial to private interface methods doesn't use default method logic.
> // Private class methods are not candidates for default methods.
> // Private methods do not override default methods, so need to perform
> // default method inheritance without including private methods.
> // The overpasses are your supertypes' errors, we do not include them.
> static bool is_not_excluded_method(Method* m) {
>     if (m != nullptr && !m->is_static() && !m->is_overpass() && !m->is_private()) {
>        return true;
>     }
>     return false;
> }
> 
> 
> The name isn't great - feel free to replace with something better - but the idea is to capture the requirements in one place

Thanks for the review @DanHeidinga . I have opted to just adjust the commentary around that piece of code.

I disagree with Coleen about the potential harm of also changing the upper loop - that would need further investigation.

It also occurred to me that the loop I am fixing is really just an optimization to check whether the current class could potentially use a different implementation for a default method versus its super class. We could unconditionally create an empty slot for all the super class default methods, and things still appear to work correctly. But there may be performance implications. I think what is causing us all to struggle somewhat with understanding the existing logic is that it starts from a position of filling everything in, then goes through and creates an empty slot for all those things that could be wrong; whereas it seems more understandable to me to start with an empty table and then insert everything we know is right. But I suspect the starting assumption here is that most of the time a subclass vtable is just a superclass vtable with a few additions and fewer modifications (ie. overrides), so the current approach is more optimal in general.

Anyway I appreciate the reviews and discussion. I will need someone to re-approve after the comment change. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26302#discussion_r2217988564

From dholmes at openjdk.org  Mon Jul 21 02:26:39 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 21 Jul 2025 02:26:39 GMT
Subject: RFR: 8359827: Test runtime/Thread/ThreadCountLimit.java should run
 exclusively [v2]
In-Reply-To: <ChycL6uT1_9xEgldDbu37a-XnFdXjX3DCuQS2JBZi7w=.8cfa4026-208e-4b1f-a951-1cef8665481e@github.com>
References: <KFZNv5pVvr7Rddlm5xifJz6VzPzlFkmO7XPXrdJGWHw=.0664dc6c-992a-473d-b974-b2c40e06f45b@github.com>
 <ChycL6uT1_9xEgldDbu37a-XnFdXjX3DCuQS2JBZi7w=.8cfa4026-208e-4b1f-a951-1cef8665481e@github.com>
Message-ID: <nbhNKzH9yDCslHn_LeBfdi--6eyMX3UM3LiQvCrZib0=.849d66c2-a822-41c4-a072-22c204fd97e7@github.com>

On Sat, 19 Jul 2025 02:28:39 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> The test runtime/Thread/ThreadCountLimit.java was observed fails when run with other tests. The test start subprocess with [shell prefix command](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/Thread/ThreadCountLimit.java#L82) `ulimit -u 4096` which intend to limite the usage of thread number. But this will cause test fails when this test run with other tests. I create a demo to demonstrate that.
>> 
>> I start a java process which will create 5k threads, and then I can not start new java process with prefix `ulimit -u 4096` on the same machine.
>> 
>> <img width="1573" height="182" alt="image" src="https://github.com/user-attachments/assets/8dd53ade-cad7-4a2f-b5d9-d4b2d200b728" />
>> 
>> 
>> [ManyThreads.java.txt](https://github.com/user-attachments/files/21324354/ManyThreads.java.txt)
>> 
>> So it's necessary to make this test run sperately to make this test success.
>> Change has been verified locally, test-fix only, risk is low.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update TEST.groups

@sendaoYan  `exclusiveAccess.dirs` does not work the way you expect/require. It simply indicates that only one test at a time may run from the given directory. It does not mean no other tests from any other directories may run.

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

PR Comment: https://git.openjdk.org/jdk/pull/26401#issuecomment-3095050162

From dholmes at openjdk.org  Mon Jul 21 02:32:47 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 21 Jul 2025 02:32:47 GMT
Subject: RFR: 8359827: Test runtime/Thread/ThreadCountLimit.java should run
 exclusively [v2]
In-Reply-To: <ChycL6uT1_9xEgldDbu37a-XnFdXjX3DCuQS2JBZi7w=.8cfa4026-208e-4b1f-a951-1cef8665481e@github.com>
References: <KFZNv5pVvr7Rddlm5xifJz6VzPzlFkmO7XPXrdJGWHw=.0664dc6c-992a-473d-b974-b2c40e06f45b@github.com>
 <ChycL6uT1_9xEgldDbu37a-XnFdXjX3DCuQS2JBZi7w=.8cfa4026-208e-4b1f-a951-1cef8665481e@github.com>
Message-ID: <GoVnA3fJZpXj9fHh8HFnrMOyO6ys32yBX2RPZ-ESdBw=.901f2c57-6513-4eaa-b5b0-7e00ab51e72a@github.com>

On Sat, 19 Jul 2025 02:28:39 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> The test runtime/Thread/ThreadCountLimit.java was observed fails when run with other tests. The test start subprocess with [shell prefix command](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/Thread/ThreadCountLimit.java#L82) `ulimit -u 4096` which intend to limite the usage of thread number. But this will cause test fails when this test run with other tests. I create a demo to demonstrate that.
>> 
>> I start a java process which will create 5k threads, and then I can not start new java process with prefix `ulimit -u 4096` on the same machine.
>> 
>> <img width="1573" height="182" alt="image" src="https://github.com/user-attachments/assets/8dd53ade-cad7-4a2f-b5d9-d4b2d200b728" />
>> 
>> 
>> [ManyThreads.java.txt](https://github.com/user-attachments/files/21324354/ManyThreads.java.txt)
>> 
>> So it's necessary to make this test run sperately to make this test success.
>> Change has been verified locally, test-fix only, risk is low.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update TEST.groups

FWIW we see no issue running this test, but we ensure we already have a high ulimit setting available in our test machines by default.

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

PR Comment: https://git.openjdk.org/jdk/pull/26401#issuecomment-3095055337

From syan at openjdk.org  Mon Jul 21 09:02:43 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 21 Jul 2025 09:02:43 GMT
Subject: RFR: 8359827: Test runtime/Thread/ThreadCountLimit.java should run
 exclusively [v2]
In-Reply-To: <GoVnA3fJZpXj9fHh8HFnrMOyO6ys32yBX2RPZ-ESdBw=.901f2c57-6513-4eaa-b5b0-7e00ab51e72a@github.com>
References: <KFZNv5pVvr7Rddlm5xifJz6VzPzlFkmO7XPXrdJGWHw=.0664dc6c-992a-473d-b974-b2c40e06f45b@github.com>
 <ChycL6uT1_9xEgldDbu37a-XnFdXjX3DCuQS2JBZi7w=.8cfa4026-208e-4b1f-a951-1cef8665481e@github.com>
 <GoVnA3fJZpXj9fHh8HFnrMOyO6ys32yBX2RPZ-ESdBw=.901f2c57-6513-4eaa-b5b0-7e00ab51e72a@github.com>
Message-ID: <vteGzJ6y_nYJdsCkkjSR0XknFuAg3-t3mKI8QGH9ypM=.c0547fcf-ee47-4a0f-b73e-eef2ed7aa7c4@github.com>

On Mon, 21 Jul 2025 02:29:37 GMT, David Holmes <dholmes at openjdk.org> wrote:

> FWIW we see no issue running this test, but we ensure we already have a high ulimit setting available in our test machines by default.

1. Maybe this test has been excluded by [TEST.groups](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/TEST.groups#L398)
2. The error reported in this testcase should not be related to the ulimit configuration of the test environment, but may be related to the number of CPU cores of the machine. On a machine with a large number of CPU cores, each testcase will start more gc threads and JIT threads, and the number of jtreg concurrency will also be relatively large, causing the total number of threads of all testcases to easily exceed 4096. For example, in the example below, my environment configuration ulimit -u is unlimited. I first start a background java process, which will start 5000 threads and will not exit; then I use shell predix `ulimit -u` to start the java process (similar to the test situation of this testcase), and then I cannot start java.

<img width="1594" height="164" alt="image" src="https://github.com/user-attachments/assets/095bee02-c61c-4d93-bcc8-8806dd561c96" />

[ManyThreads.java.txt](https://github.com/user-attachments/files/21343260/ManyThreads.java.txt)

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

PR Comment: https://git.openjdk.org/jdk/pull/26401#issuecomment-3095798953

From syan at openjdk.org  Mon Jul 21 09:17:32 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 21 Jul 2025 09:17:32 GMT
Subject: RFR: 8359827: Test runtime/Thread/ThreadCountLimit.java should run
 exclusively [v3]
In-Reply-To: <KFZNv5pVvr7Rddlm5xifJz6VzPzlFkmO7XPXrdJGWHw=.0664dc6c-992a-473d-b974-b2c40e06f45b@github.com>
References: <KFZNv5pVvr7Rddlm5xifJz6VzPzlFkmO7XPXrdJGWHw=.0664dc6c-992a-473d-b974-b2c40e06f45b@github.com>
Message-ID: <IoSJXUyo3Tb4vjzbO2Qqz0OfZlHwCla5mOaIfonrRtk=.58292b7b-dabe-4de6-83b8-22831241e18d@github.com>

> Hi all,
> 
> The test runtime/Thread/ThreadCountLimit.java was observed fails when run with other tests. The test start subprocess with [shell prefix command](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/Thread/ThreadCountLimit.java#L82) `ulimit -u 4096` which intend to limite the usage of thread number. But this will cause test fails when this test run with other tests. I create a demo to demonstrate that.
> 
> I start a java process which will create 5k threads, and then I can not start new java process with prefix `ulimit -u 4096` on the same machine.
> 
> <img width="1573" height="182" alt="image" src="https://github.com/user-attachments/assets/8dd53ade-cad7-4a2f-b5d9-d4b2d200b728" />
> 
> 
> [ManyThreads.java.txt](https://github.com/user-attachments/files/21324354/ManyThreads.java.txt)
> 
> So it's necessary to make this test run sperately to make this test success.
> Change has been verified locally, test-fix only, risk is low.

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

  mv test/hotspot/jtreg/runtime/Thread/stress/ThreadCountLimit.java test/hotspot/jtreg/resourcehogs/runtime/Thread/

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26401/files
  - new: https://git.openjdk.org/jdk/pull/26401/files/3c3c697d..5d6c69bc

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

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

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

From syan at openjdk.org  Mon Jul 21 09:22:39 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 21 Jul 2025 09:22:39 GMT
Subject: RFR: 8359827: Test runtime/Thread/ThreadCountLimit.java should run
 exclusively [v2]
In-Reply-To: <vteGzJ6y_nYJdsCkkjSR0XknFuAg3-t3mKI8QGH9ypM=.c0547fcf-ee47-4a0f-b73e-eef2ed7aa7c4@github.com>
References: <KFZNv5pVvr7Rddlm5xifJz6VzPzlFkmO7XPXrdJGWHw=.0664dc6c-992a-473d-b974-b2c40e06f45b@github.com>
 <ChycL6uT1_9xEgldDbu37a-XnFdXjX3DCuQS2JBZi7w=.8cfa4026-208e-4b1f-a951-1cef8665481e@github.com>
 <GoVnA3fJZpXj9fHh8HFnrMOyO6ys32yBX2RPZ-ESdBw=.901f2c57-6513-4eaa-b5b0-7e00ab51e72a@github.com>
 <vteGzJ6y_nYJdsCkkjSR0XknFuAg3-t3mKI8QGH9ypM=.c0547fcf-ee47-4a0f-b73e-eef2ed7aa7c4@github.com>
Message-ID: <N6cTp8QFyiY1sS-oBF6e9k8v3ORoakXpEimY3IyKGKU=.3470ef8e-b2e3-495c-901e-3073503c86e9@github.com>

On Mon, 21 Jul 2025 09:00:03 GMT, SendaoYan <syan at openjdk.org> wrote:

>> FWIW we see no issue running this test, but we ensure we already have a high ulimit setting available in our test machines by default.
>
>> FWIW we see no issue running this test, but we ensure we already have a high ulimit setting available in our test machines by default.
> 
> 1. Maybe this test has been excluded by [TEST.groups](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/TEST.groups#L398)
> 2. The error reported in this testcase should not be related to the ulimit configuration of the test environment, but may be related to the number of CPU cores of the machine. On a machine with a large number of CPU cores, each testcase will start more gc threads and JIT threads, and the number of jtreg concurrency will also be relatively large, causing the total number of threads of all testcases to easily exceed 4096. For example, in the example below, my environment configuration ulimit -u is unlimited. I first start a background java process, which will start 5000 threads and will not exit; then I use shell predix `ulimit -u` to start the java process (similar to the test situation of this testcase), and then I cannot start java.
> 
> <img width="1593" height="188" alt="image" src="https://github.com/user-attachments/assets/6b83d04a-a8dd-481b-96dd-f6372ff10591" />
> 
> 
> [ManyThreads.java.txt](https://github.com/user-attachments/files/21343335/ManyThreads.java.txt)

> @sendaoYan `exclusiveAccess.dirs` does not work the way you expect/require. It simply indicates that only one test at a time may run from the given directory. It does not mean no other tests from any other directories may run.

Thanks your correction @dholmes-ora.
I have move this test to test/hotspot/jtreg/resourcehogs, similar to [JDK-8227645](https://bugs.openjdk.org/browse/JDK-8227645).

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

PR Comment: https://git.openjdk.org/jdk/pull/26401#issuecomment-3095863364

From syan at openjdk.org  Mon Jul 21 09:52:29 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 21 Jul 2025 09:52:29 GMT
Subject: RFR: 8362834: Several runtime/Thread tests should mark as /native
Message-ID: <V6Eofnui54_4GbTMwOQ0MfQIYe55x6sscvPJFqF895c=.bcde2eab-03ba-4f46-8466-4d7153f66a14@github.com>

Hi all,

Some of the runtime/Thread tests ready mark as /native:
runtime/Thread/SuspendAtExit.java
runtime/Thread/StopAtExit.java

But there are some of the runtime/Thread tests needed to mark as /native:
runtime/Thread/AsyncExceptionTest.java
runtime/Thread/AsyncExceptionOnMonitorEnter.java
runtime/Thread/TestBreakSignalThreadDump.java#with_jsig
runtime/Thread/TestBreakSignalThreadDump.java#default

Without -nativepath jtreg option, the test will report test failure, such as: "Execution failed: `main' threw exception: java.lang.RuntimeException: Expected to get exit value of [0], exit value is: [1]", after this PR without -nativepath jtreg option, the test will report "Error. Use -nativepath to specify the location of native code", this will make test usage more friendly.

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

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

Commit messages:
 - Remove /othervm for test/hotspot/jtreg/runtime/Thread/TestBreakSignalThreadDump.java
 - Use main/native for test/hotspot/jtreg/runtime/Thread/TestBreakSignalThreadDump.java
 - 8362834: Several runtime/Thread tests should mark as /native

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

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

From dholmes at openjdk.org  Mon Jul 21 12:01:41 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 21 Jul 2025 12:01:41 GMT
Subject: RFR: 8359827: Test runtime/Thread/ThreadCountLimit.java should run
 exclusively [v2]
In-Reply-To: <vteGzJ6y_nYJdsCkkjSR0XknFuAg3-t3mKI8QGH9ypM=.c0547fcf-ee47-4a0f-b73e-eef2ed7aa7c4@github.com>
References: <KFZNv5pVvr7Rddlm5xifJz6VzPzlFkmO7XPXrdJGWHw=.0664dc6c-992a-473d-b974-b2c40e06f45b@github.com>
 <ChycL6uT1_9xEgldDbu37a-XnFdXjX3DCuQS2JBZi7w=.8cfa4026-208e-4b1f-a951-1cef8665481e@github.com>
 <GoVnA3fJZpXj9fHh8HFnrMOyO6ys32yBX2RPZ-ESdBw=.901f2c57-6513-4eaa-b5b0-7e00ab51e72a@github.com>
 <vteGzJ6y_nYJdsCkkjSR0XknFuAg3-t3mKI8QGH9ypM=.c0547fcf-ee47-4a0f-b73e-eef2ed7aa7c4@github.com>
Message-ID: <gyOH3NaJKRjTF0-uJD27iaDa1AyDzAeyScNtyC5InnM=.d6972e2f-2b67-4aef-9cc8-a5d2ef6e8cf0@github.com>

On Mon, 21 Jul 2025 09:00:03 GMT, SendaoYan <syan at openjdk.org> wrote:

>  I first start a background java process, which will start 5000 threads and will not exit; then I use shell predix ulimit -u to start the java process (similar to the test situation of this testcase), and then I cannot start java.

Okay, but in that scenario what is it you are actually running out of?

You are changing the test to suit the way you need to run it, but I'm not aware of anyone else reporting issues running this test.

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

PR Comment: https://git.openjdk.org/jdk/pull/26401#issuecomment-3096443703

From dholmes at openjdk.org  Mon Jul 21 12:19:40 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 21 Jul 2025 12:19:40 GMT
Subject: RFR: 8362834: Several runtime/Thread tests should mark as /native
In-Reply-To: <V6Eofnui54_4GbTMwOQ0MfQIYe55x6sscvPJFqF895c=.bcde2eab-03ba-4f46-8466-4d7153f66a14@github.com>
References: <V6Eofnui54_4GbTMwOQ0MfQIYe55x6sscvPJFqF895c=.bcde2eab-03ba-4f46-8466-4d7153f66a14@github.com>
Message-ID: <VL22Mz5s-MCotkb8vxiSJvU2x8aB45RT68WeB-TvGXc=.36c46006-258b-455b-a711-fdfd58a4b284@github.com>

On Mon, 21 Jul 2025 09:45:53 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Some of the runtime/Thread tests ready mark as /native:
> runtime/Thread/SuspendAtExit.java
> runtime/Thread/StopAtExit.java
> 
> But there are some of the runtime/Thread tests needed to mark as /native:
> runtime/Thread/AsyncExceptionTest.java
> runtime/Thread/AsyncExceptionOnMonitorEnter.java
> runtime/Thread/TestBreakSignalThreadDump.java#with_jsig
> runtime/Thread/TestBreakSignalThreadDump.java#default
> 
> Without -nativepath jtreg option, the test will report test failure, such as: "Execution failed: `main' threw exception: java.lang.RuntimeException: Expected to get exit value of [0], exit value is: [1]", after this PR without -nativepath jtreg option, the test will report "Error. Use -nativepath to specify the location of native code", this will make test usage more friendly.
> 
> Change has been verified locally, test-fix only, no risk.

Seems reasonable.

FWIW I always use a jtreg wrapper that sets the -nativepath no matter what test I'm running.

test/hotspot/jtreg/runtime/Thread/AsyncExceptionOnMonitorEnter.java line 2:

> 1: /*
> 2:  * Copyright (c) 2022, 2025 Oracle and/or its affiliates. All rights reserved.

Suggestion:

 * Copyright (c) 2022, 2025, Oracle and/or its affiliates. All rights reserved.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26411#pullrequestreview-3037822628
PR Review Comment: https://git.openjdk.org/jdk/pull/26411#discussion_r2219019242

From syan at openjdk.org  Mon Jul 21 12:36:40 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 21 Jul 2025 12:36:40 GMT
Subject: RFR: 8362834: Several runtime/Thread tests should mark as /native
 [v2]
In-Reply-To: <V6Eofnui54_4GbTMwOQ0MfQIYe55x6sscvPJFqF895c=.bcde2eab-03ba-4f46-8466-4d7153f66a14@github.com>
References: <V6Eofnui54_4GbTMwOQ0MfQIYe55x6sscvPJFqF895c=.bcde2eab-03ba-4f46-8466-4d7153f66a14@github.com>
Message-ID: <GP67qL_fUcbCfDnBjbETR17_sE88y_8PwmKQmVGfKuI=.75249a56-fca7-4dc5-a56d-023abe6db7a3@github.com>

> Hi all,
> 
> Some of the runtime/Thread tests ready mark as /native:
> runtime/Thread/SuspendAtExit.java
> runtime/Thread/StopAtExit.java
> 
> But there are some of the runtime/Thread tests needed to mark as /native:
> runtime/Thread/AsyncExceptionTest.java
> runtime/Thread/AsyncExceptionOnMonitorEnter.java
> runtime/Thread/TestBreakSignalThreadDump.java#with_jsig
> runtime/Thread/TestBreakSignalThreadDump.java#default
> 
> Without -nativepath jtreg option, the test will report test failure, such as: "Execution failed: `main' threw exception: java.lang.RuntimeException: Expected to get exit value of [0], exit value is: [1]", after this PR without -nativepath jtreg option, the test will report "Error. Use -nativepath to specify the location of native code", this will make test usage more friendly.
> 
> Change has been verified locally, test-fix only, no risk.

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

 - Update copyright year
 - Update copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26411/files
  - new: https://git.openjdk.org/jdk/pull/26411/files/bac6b529..0e79128d

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

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

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

From syan at openjdk.org  Mon Jul 21 12:36:41 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 21 Jul 2025 12:36:41 GMT
Subject: RFR: 8362834: Several runtime/Thread tests should mark as /native
 [v2]
In-Reply-To: <VL22Mz5s-MCotkb8vxiSJvU2x8aB45RT68WeB-TvGXc=.36c46006-258b-455b-a711-fdfd58a4b284@github.com>
References: <V6Eofnui54_4GbTMwOQ0MfQIYe55x6sscvPJFqF895c=.bcde2eab-03ba-4f46-8466-4d7153f66a14@github.com>
 <VL22Mz5s-MCotkb8vxiSJvU2x8aB45RT68WeB-TvGXc=.36c46006-258b-455b-a711-fdfd58a4b284@github.com>
Message-ID: <kC_fnxGci8bOVfAqAPb2ye6zMatSCcdPJsdLe4OOoNY=.273c4024-67e6-4f46-a472-843532702b7c@github.com>

On Mon, 21 Jul 2025 12:15:42 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update copyright year
>>  - Update copyright year
>
> test/hotspot/jtreg/runtime/Thread/AsyncExceptionOnMonitorEnter.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2022, 2025 Oracle and/or its affiliates. All rights reserved.
> 
> Suggestion:
> 
>  * Copyright (c) 2022, 2025, Oracle and/or its affiliates. All rights reserved.

Thanks. Has been fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26411#discussion_r2219071768

From snatarajan at openjdk.org  Mon Jul 21 13:12:56 2025
From: snatarajan at openjdk.org (Saranya Natarajan)
Date: Mon, 21 Jul 2025 13:12:56 GMT
Subject: RFR: 8358696: Assert with extreme values for -XX:BciProfileWidth
Message-ID: <5TRVeAXUQi6quM-nDWEij_jk6M5K2Vk31RA-Yjd8F2M=.5b63da45-93c3-4251-9e2e-3c64b7953919@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 ?

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

Commit messages:
 - Fix for AArch64
 - Modified the upper bound
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/26139/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26139&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358696
  Stats: 3 lines in 1 file changed: 2 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 syan at openjdk.org  Mon Jul 21 13:34:40 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 21 Jul 2025 13:34:40 GMT
Subject: RFR: 8359827: Test runtime/Thread/ThreadCountLimit.java should run
 exclusively [v2]
In-Reply-To: <gyOH3NaJKRjTF0-uJD27iaDa1AyDzAeyScNtyC5InnM=.d6972e2f-2b67-4aef-9cc8-a5d2ef6e8cf0@github.com>
References: <KFZNv5pVvr7Rddlm5xifJz6VzPzlFkmO7XPXrdJGWHw=.0664dc6c-992a-473d-b974-b2c40e06f45b@github.com>
 <ChycL6uT1_9xEgldDbu37a-XnFdXjX3DCuQS2JBZi7w=.8cfa4026-208e-4b1f-a951-1cef8665481e@github.com>
 <GoVnA3fJZpXj9fHh8HFnrMOyO6ys32yBX2RPZ-ESdBw=.901f2c57-6513-4eaa-b5b0-7e00ab51e72a@github.com>
 <vteGzJ6y_nYJdsCkkjSR0XknFuAg3-t3mKI8QGH9ypM=.c0547fcf-ee47-4a0f-b73e-eef2ed7aa7c4@github.com>
 <gyOH3NaJKRjTF0-uJD27iaDa1AyDzAeyScNtyC5InnM=.d6972e2f-2b67-4aef-9cc8-a5d2ef6e8cf0@github.com>
Message-ID: <9drXzcmyQFF3YB9kmuSSJyAjF65eemK1mbKlU1G-l6I=.87361ff3-e07c-4f90-a5d8-98ed6d864a19@github.com>

On Mon, 21 Jul 2025 11:59:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Okay, but in that scenario what is it you are actually running out of?

I think it's running out of "user processes" which limit by `ulimit -u 4096`.

I think it is the user processes set by `ulimit -u` are exhausted that Java cannot start.
I created a small example in C language to illustrate this problem. The create-thread program will try to create threads continuously until it can no longer create threads, or the number of threads created exceeds 5000.
1. Use bash -c "ulimit -u 1000 && ./create-thread" command to test that the number of threads that the create-thread program can create is about 580;
<img width="731" height="94" alt="image" src="https://github.com/user-attachments/assets/c236bc47-f27f-4a54-82b5-643952de255e" />

2. First directly start the create-thread program (background running mode), and then use bash -c "ulimit -u 4096 && ./create-thread" command to test the number of threads that the second create-thread process can create. It will be found that the second create-thread process cannot create any new thread. Explain that the number of max user processes limited by `ulimit -u 4096` includes the number of threads created by the first create-thread process.
This C language example shows that this testcase is not suitable for concurrent running with other test cases, otherwise you may encounter the failure described in the issue
<img width="708" height="218" alt="image" src="https://github.com/user-attachments/assets/6a02d745-3582-4bf6-b9ff-a7161ac6dda5" />


#include <stdio.h>
#include <pthread.h>
#include <unistd.h>
#include <errno.h>
#include <string.h>

void *thread_func() {
    while (1) {
        sleep(1);
    }
    return NULL;
}

int main() {
    pthread_t tid;
    int thread_count = 0;
    int ret;

    while (thread_count < 5000) {
        ret = pthread_create(&tid, NULL, thread_func, NULL);
        if (ret != 0) {
            if (ret == EAGAIN) {
                printf("can not create thread(EAGAIN) anymore: %d\n", thread_count);
                break;
            } else {
                printf("pthread_create error: %s\n", strerror(ret));
                break;
            }
        }
        thread_count++;
        if (thread_count % 1000 == 0) {
            printf("already create thread number %d\n", thread_count);
        }
    }
    printf("total created thread number: %d\n", thread_count);

    while (1) {
        sleep(1);
    }

    return 0;
}



> You are changing the test to suit the way you need to run it, but I'm not aware of anyone else reporting issues running this test.

I think the failure descripted by issue, only appearance on huge CPU core number machine.

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

PR Comment: https://git.openjdk.org/jdk/pull/26401#issuecomment-3096804639

From mbaesken at openjdk.org  Mon Jul 21 13:48:41 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 21 Jul 2025 13:48:41 GMT
Subject: RFR: 8360941: [ubsan] MemRegion::end() shows runtime error:
 applying non-zero offset 8388608 to null pointer [v6]
In-Reply-To: <LP6FbAxZpwbGf6lkNvLcSRSEOu-mYKjWGAJYBSIMcyk=.775595dc-7f73-4248-a235-f4b58933396b@github.com>
References: <LP6FbAxZpwbGf6lkNvLcSRSEOu-mYKjWGAJYBSIMcyk=.775595dc-7f73-4248-a235-f4b58933396b@github.com>
Message-ID: <othqWmDcZqpdMXoYd9sm7OysbjAyS_SfSe5TZL0fCvE=.9afd9bb4-8909-4c2d-8bef-00f5f3e2a5c6@github.com>

> When running HS test
> gtest/GTestWrapper.java
> with ubsan-enabled binaries on macOS aarch64, the following error is reported (did not see this so far on Linux but there we use gcc and it seems the gcc/ubsan checks are a bit more limited).
> 
> test/hotspot/gtest/gc/g1/test_freeRegionList.cpp:37: Failure
> Death test: child_G1FreeRegionList_length_()
>     Result: died but not with expected exit code:
>             Terminated by signal 6 (core dumped)
> Actual msg:
> 
> [  DEATH   ] /jdk/src/hotspot/share/memory/memRegion.hpp:66:43: runtime error: applying non-zero offset 8388608 to null pointer
> [  DEATH   ]     #0 0x108afd6f4 in MemRegion::end() const+0x84 (libjvm.dylib:arm64+0x16556f4)
> [  DEATH   ]     #1 0x1075c68a0 in G1FreeRegionList_length_other_vm_Test::TestBody()+0x380 (libjvm.dylib:arm64+0x11e8a0)
> [  DEATH   ]     #2 0x1090f3bb0 in testing::Test::Run()+0xc0 (libjvm.dylib:arm64+0x1c4bbb0)
> [  DEATH   ]     #3 0x1090f4d94 in testing::TestInfo::Run()+0x1e4 (libjvm.dylib:arm64+0x1c4cd94)
> [  DEATH   ]     #4 0x1090f6754 in testing::TestSuite::Run()+0x43c (libjvm.dylib:arm64+0x1c4e754)
> [  DEATH   ]     #5 0x109103ca0 in testing::internal::UnitTestImpl::RunAllTests()+0x48c (libjvm.dylib:arm64+0x1c5bca0)
> [  DEATH   ]     #6 0x109103588 in testing::UnitTest::Run()+0x78 (libjvm.dylib:arm64+0x1c5b588)
> [  DEATH   ]     #7 0x1074a9ac0 in runUnitTestsInner(int, char**)+0x724 (libjvm.dylib:arm64+0x1ac0)
> [  DEATH   ]     #8 0x102dc3f18 in main+0x2c (gtestLauncher:arm64+0x100003f18)
> [  DEATH   ]     #9 0x196fea0dc  (<unknown module>)
> [  DEATH   ] 
> [  DEATH   ] SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /jdk/src/hotspot/share/memory/memRegion.hpp:66:43 in 
> [  DEATH   ] 
> 
> 
> 
> Seems the test_freeRegionList.cpp uses a special MemRegion starting at nullptr ; but this causes a bit of trouble when adding to start == nullptr .
> So far I see this issue just in the gtest, seems other MemRegion objects do not start at nullptr .

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

  Suggestion by Thomas Stuefe

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26216/files
  - new: https://git.openjdk.org/jdk/pull/26216/files/f0888cea..0a9adaab

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

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

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

From coleenp at openjdk.org  Mon Jul 21 17:54:24 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 21 Jul 2025 17:54:24 GMT
Subject: RFR: 8360555: Archive all unnamed modules in CDS full module graph
In-Reply-To: <wShFgP1f2myBNCuyVnLXYiB1PEBQlkW5VcyIDmyeoRo=.fff71539-455b-4109-8f9c-81c2e16d0bc0@github.com>
References: <wShFgP1f2myBNCuyVnLXYiB1PEBQlkW5VcyIDmyeoRo=.fff71539-455b-4109-8f9c-81c2e16d0bc0@github.com>
Message-ID: <IBwASkspBPB4VCKVx3quHUdWnvtQskrSg5oT3k5qCXg=.9c1fc78b-853b-4bd7-8072-b668c1a87295@github.com>

On Wed, 2 Jul 2025 00:18:28 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The CDS full module graph is supposed to contain a snapshot of the boot layer, which has 3 unnamed modules for the boot, platform and system class loaders. Each unnamed module is represented by a `java.lang.Module` Java object and a `ModuleEntry` C++ object.
> 
> Currently, we archive only the `java.lang.Module` for the platform and system loaders. The other 4 objects are dynamically created in the production run while executing Java bytecodes during VM bootstrap.
> 
> With this PR, we archive all of the above 6 objects when `CDSConfig::is_dumping_full_module_graph()` is true.
> 
> This is required for [JDK-8350550](https://bugs.openjdk.org/browse/JDK-8350550), as we need the `java.lang.Module` object for archived classes in the unnamed module of the boot loader prior to executing any Java code.
> 
> We also archive the `ModuleEntry` objects for the 3 unnamed modules for uniformity, as these objects are already archived for named modules.

The code looks good.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26082#pullrequestreview-3039130102

From coleenp at openjdk.org  Mon Jul 21 17:54:25 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 21 Jul 2025 17:54:25 GMT
Subject: RFR: 8360555: Archive all unnamed modules in CDS full module graph
In-Reply-To: <dwrToo7aFLg6SgqDSaYQkYvh-TPXWND7wZacVfp2QAY=.8420ecbe-362b-46a6-b583-4e5497b3c287@github.com>
References: <wShFgP1f2myBNCuyVnLXYiB1PEBQlkW5VcyIDmyeoRo=.fff71539-455b-4109-8f9c-81c2e16d0bc0@github.com>
 <aTs018gQ4ULkVAXdGUZiX-g7gKJkHEbMjKCob8i9FYA=.208a442c-52dc-4569-9c27-596fd1f94121@github.com>
 <I6QtmOydf5-vfixmLTwYX2aO6cEM_GUjNaxnAELfFDs=.4ffabffc-a01a-4d7e-8b3a-26deac5120c6@github.com>
 <dwrToo7aFLg6SgqDSaYQkYvh-TPXWND7wZacVfp2QAY=.8420ecbe-362b-46a6-b583-4e5497b3c287@github.com>
Message-ID: <LEX_cIXqhLxxC2bGMRe1QT9qajhG6QzMY2UGUw3jCiI=.743b0785-0447-431c-8bac-595fa4d3123d@github.com>

On Thu, 17 Jul 2025 22:41:34 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> If you're storing the unnamed module oop in the archive should this method not be called?  If it is, what are you saving by archiving the unnamed module?
>
> The callstack is:
> 
> 
> jdk.internal.loader.BootLoader.setBootLoaderUnnamedModule0(java.base at 26-internal/Native Method)
> jdk.internal.loader.BootLoader.<clinit>(java.base at 26-internal/BootLoader.java:71)
> jdk.internal.module.ModuleBootstrap.boot(java.base at 26-internal/ModuleBootstrap.java:162)
> java.lang.System.initPhase2(java.base at 26-internal/System.java:1932)
> 
> 
> Both the Java code and the native code have a handle to this unnamed module oop. The `precond` checks that they indeed are pointing the same oop.
> 
> Also, even though the oop is archived, we still need to set up some native states inside the `unnamed_module->restore_archived_oops(boot_loader_data)` call. E.g., set up the `OopHandle` that binds the oop to the `ModuleEntry`.
> 
> ---------------
>> what are you saving by archiving the unnamed module?
> 
> It's for [JDK-8350550](https://bugs.openjdk.org/browse/JDK-8350550)) -- I want to be able to reference the unnamed module before executing any Java code, so that archived classes can be loaded at the very beginning of `vmClasses::resolve_all()`. See my draft PR: https://github.com/openjdk/jdk/pull/26375
> 
> ---------------
> Currently, we still execute a lot of Java code when setting up the archived module graph (inside `ModuleBootstrap.boot()`. I am working on a way to enable the archived module graph without executing any Java code (which will be a few REFs after [JDK-8350550](https://bugs.openjdk.org/browse/JDK-8350550)), so this call will eventually be gone.

Ok, I see.  At this point, you're just checking that what you've referred to before loading the unnamed module matches what you've previously saved in the shared archive. Did I get that right?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26082#discussion_r2219870762

From iklam at openjdk.org  Mon Jul 21 18:18:24 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 21 Jul 2025 18:18:24 GMT
Subject: RFR: 8360555: Archive all unnamed modules in CDS full module graph
In-Reply-To: <LEX_cIXqhLxxC2bGMRe1QT9qajhG6QzMY2UGUw3jCiI=.743b0785-0447-431c-8bac-595fa4d3123d@github.com>
References: <wShFgP1f2myBNCuyVnLXYiB1PEBQlkW5VcyIDmyeoRo=.fff71539-455b-4109-8f9c-81c2e16d0bc0@github.com>
 <aTs018gQ4ULkVAXdGUZiX-g7gKJkHEbMjKCob8i9FYA=.208a442c-52dc-4569-9c27-596fd1f94121@github.com>
 <I6QtmOydf5-vfixmLTwYX2aO6cEM_GUjNaxnAELfFDs=.4ffabffc-a01a-4d7e-8b3a-26deac5120c6@github.com>
 <dwrToo7aFLg6SgqDSaYQkYvh-TPXWND7wZacVfp2QAY=.8420ecbe-362b-46a6-b583-4e5497b3c287@github.com>
 <LEX_cIXqhLxxC2bGMRe1QT9qajhG6QzMY2UGUw3jCiI=.743b0785-0447-431c-8bac-595fa4d3123d@github.com>
Message-ID: <wcF3RwW9zi2dIkWfQq3JvpPNBtz0cLmxIF3sMnCxLSM=.baa296e9-2cc8-4fd6-a3d7-adee30ead821@github.com>

On Mon, 21 Jul 2025 17:51:34 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The callstack is:
>> 
>> 
>> jdk.internal.loader.BootLoader.setBootLoaderUnnamedModule0(java.base at 26-internal/Native Method)
>> jdk.internal.loader.BootLoader.<clinit>(java.base at 26-internal/BootLoader.java:71)
>> jdk.internal.module.ModuleBootstrap.boot(java.base at 26-internal/ModuleBootstrap.java:162)
>> java.lang.System.initPhase2(java.base at 26-internal/System.java:1932)
>> 
>> 
>> Both the Java code and the native code have a handle to this unnamed module oop. The `precond` checks that they indeed are pointing the same oop.
>> 
>> Also, even though the oop is archived, we still need to set up some native states inside the `unnamed_module->restore_archived_oops(boot_loader_data)` call. E.g., set up the `OopHandle` that binds the oop to the `ModuleEntry`.
>> 
>> ---------------
>>> what are you saving by archiving the unnamed module?
>> 
>> It's for [JDK-8350550](https://bugs.openjdk.org/browse/JDK-8350550)) -- I want to be able to reference the unnamed module before executing any Java code, so that archived classes can be loaded at the very beginning of `vmClasses::resolve_all()`. See my draft PR: https://github.com/openjdk/jdk/pull/26375
>> 
>> ---------------
>> Currently, we still execute a lot of Java code when setting up the archived module graph (inside `ModuleBootstrap.boot()`. I am working on a way to enable the archived module graph without executing any Java code (which will be a few REFs after [JDK-8350550](https://bugs.openjdk.org/browse/JDK-8350550)), so this call will eventually be gone.
>
> Ok, I see.  At this point, you're just checking that what you've referred to before loading the unnamed module matches what you've previously saved in the shared archive. Did I get that right?

Yes, it's checking that the Java and C++ code both found the same archived unnamed module.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26082#discussion_r2219925684

From heidinga at openjdk.org  Mon Jul 21 20:56:25 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Mon, 21 Jul 2025 20:56:25 GMT
Subject: RFR: 8356941: AbstractMethodError in HotSpot Due to Incorrect
 Handling of Private Method [v5]
In-Reply-To: <WGeThEw5qnSvz2a3qvi31rGposTBBswNe-KY8HIL8sk=.951fcc7c-5157-43f5-9500-2548678b013b@github.com>
References: <qyWNTs0IOlf128C4ZdvOp9TE7O4w7bPaz2hJfHseIUk=.4a298588-6aff-471a-927b-beb3c9f0b194@github.com>
 <WGeThEw5qnSvz2a3qvi31rGposTBBswNe-KY8HIL8sk=.951fcc7c-5157-43f5-9500-2548678b013b@github.com>
Message-ID: <UTQBCkzEWjUcprfdSIxaL5JC-HMeJ55f0DeUUGJ0jc8=.6ac5b674-43fe-423f-b3a3-9918364f7c97@github.com>

On Sun, 20 Jul 2025 22:47:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Private methods should never be considered as the implementation of a default method.
>> 
>> The first commit adds some additional logging I used to track down what was happening. I like it, but if reviewers think it too much I can drop it.
>> 
>> The second commit is the actual fix to exclude private methods, and adds the missing test case to the existing defmeth tests.
>> 
>> Testing:
>>  - tiers 1-4
>> 
>> Thanks
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo

Marked as reviewed by heidinga (no project role).

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

PR Review: https://git.openjdk.org/jdk/pull/26302#pullrequestreview-3039801120

From vlivanov at openjdk.org  Mon Jul 21 21:12:26 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Mon, 21 Jul 2025 21:12:26 GMT
Subject: RFR: 8360555: Archive all unnamed modules in CDS full module graph
In-Reply-To: <wShFgP1f2myBNCuyVnLXYiB1PEBQlkW5VcyIDmyeoRo=.fff71539-455b-4109-8f9c-81c2e16d0bc0@github.com>
References: <wShFgP1f2myBNCuyVnLXYiB1PEBQlkW5VcyIDmyeoRo=.fff71539-455b-4109-8f9c-81c2e16d0bc0@github.com>
Message-ID: <WmxC5zkqBOGGvaND4mgSqT-nvNoWZf9-tXb__-7IVhg=.e415698b-8e67-4bf5-b8bd-3bc59c355a08@github.com>

On Wed, 2 Jul 2025 00:18:28 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The CDS full module graph is supposed to contain a snapshot of the boot layer, which has 3 unnamed modules for the boot, platform and system class loaders. Each unnamed module is represented by a `java.lang.Module` Java object and a `ModuleEntry` C++ object.
> 
> Currently, we archive only the `java.lang.Module` for the platform and system loaders. The other 4 objects are dynamically created in the production run while executing Java bytecodes during VM bootstrap.
> 
> With this PR, we archive all of the above 6 objects when `CDSConfig::is_dumping_full_module_graph()` is true.
> 
> This is required for [JDK-8350550](https://bugs.openjdk.org/browse/JDK-8350550), as we need the `java.lang.Module` object for archived classes in the unnamed module of the boot loader prior to executing any Java code.
> 
> We also archive the `ModuleEntry` objects for the 3 unnamed modules for uniformity, as these objects are already archived for named modules.

Looks good.

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

Marked as reviewed by vlivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26082#pullrequestreview-3039865524

From coleenp at openjdk.org  Mon Jul 21 21:12:26 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 21 Jul 2025 21:12:26 GMT
Subject: RFR: 8356941: AbstractMethodError in HotSpot Due to Incorrect
 Handling of Private Method [v5]
In-Reply-To: <WGeThEw5qnSvz2a3qvi31rGposTBBswNe-KY8HIL8sk=.951fcc7c-5157-43f5-9500-2548678b013b@github.com>
References: <qyWNTs0IOlf128C4ZdvOp9TE7O4w7bPaz2hJfHseIUk=.4a298588-6aff-471a-927b-beb3c9f0b194@github.com>
 <WGeThEw5qnSvz2a3qvi31rGposTBBswNe-KY8HIL8sk=.951fcc7c-5157-43f5-9500-2548678b013b@github.com>
Message-ID: <7y05WuFkKqC76Y-oZrRGQID7Zif1sjGqxk4h39PFtgc=.61baee95-525f-44ad-8b57-538be6f38b5c@github.com>

On Sun, 20 Jul 2025 22:47:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Private methods should never be considered as the implementation of a default method.
>> 
>> The first commit adds some additional logging I used to track down what was happening. I like it, but if reviewers think it too much I can drop it.
>> 
>> The second commit is the actual fix to exclude private methods, and adds the missing test case to the existing defmeth tests.
>> 
>> Testing:
>>  - tiers 1-4
>> 
>> Thanks
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo

I'm a bit happier that the comment is now not duplicated, since neither was helpful to me.  This new comment is better.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26302#pullrequestreview-3039867782

From dholmes at openjdk.org  Mon Jul 21 21:18:27 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 21 Jul 2025 21:18:27 GMT
Subject: RFR: 8362834: Several runtime/Thread tests should mark as /native
 [v2]
In-Reply-To: <GP67qL_fUcbCfDnBjbETR17_sE88y_8PwmKQmVGfKuI=.75249a56-fca7-4dc5-a56d-023abe6db7a3@github.com>
References: <V6Eofnui54_4GbTMwOQ0MfQIYe55x6sscvPJFqF895c=.bcde2eab-03ba-4f46-8466-4d7153f66a14@github.com>
 <GP67qL_fUcbCfDnBjbETR17_sE88y_8PwmKQmVGfKuI=.75249a56-fca7-4dc5-a56d-023abe6db7a3@github.com>
Message-ID: <dvCMLVeZjh_iW8XHuhAPAs0aRcLR8SgTKkd5h_AW2kk=.573c93fd-4774-4d91-9395-a344fcd51bab@github.com>

On Mon, 21 Jul 2025 12:36:40 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Some of the runtime/Thread tests ready mark as /native:
>> runtime/Thread/SuspendAtExit.java
>> runtime/Thread/StopAtExit.java
>> 
>> But there are some of the runtime/Thread tests needed to mark as /native:
>> runtime/Thread/AsyncExceptionTest.java
>> runtime/Thread/AsyncExceptionOnMonitorEnter.java
>> runtime/Thread/TestBreakSignalThreadDump.java#with_jsig
>> runtime/Thread/TestBreakSignalThreadDump.java#default
>> 
>> Without -nativepath jtreg option, the test will report test failure, such as: "Execution failed: `main' threw exception: java.lang.RuntimeException: Expected to get exit value of [0], exit value is: [1]", after this PR without -nativepath jtreg option, the test will report "Error. Use -nativepath to specify the location of native code", this will make test usage more friendly.
>> 
>> Change has been verified locally, test-fix only, no risk.
>
> SendaoYan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright year
>  - Update copyright year

Marked as reviewed by dholmes (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26411#pullrequestreview-3039880230

From dholmes at openjdk.org  Mon Jul 21 21:23:23 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 21 Jul 2025 21:23:23 GMT
Subject: RFR: 8359827: Test runtime/Thread/ThreadCountLimit.java should run
 exclusively [v2]
In-Reply-To: <9drXzcmyQFF3YB9kmuSSJyAjF65eemK1mbKlU1G-l6I=.87361ff3-e07c-4f90-a5d8-98ed6d864a19@github.com>
References: <KFZNv5pVvr7Rddlm5xifJz6VzPzlFkmO7XPXrdJGWHw=.0664dc6c-992a-473d-b974-b2c40e06f45b@github.com>
 <ChycL6uT1_9xEgldDbu37a-XnFdXjX3DCuQS2JBZi7w=.8cfa4026-208e-4b1f-a951-1cef8665481e@github.com>
 <GoVnA3fJZpXj9fHh8HFnrMOyO6ys32yBX2RPZ-ESdBw=.901f2c57-6513-4eaa-b5b0-7e00ab51e72a@github.com>
 <vteGzJ6y_nYJdsCkkjSR0XknFuAg3-t3mKI8QGH9ypM=.c0547fcf-ee47-4a0f-b73e-eef2ed7aa7c4@github.com>
 <gyOH3NaJKRjTF0-uJD27iaDa1AyDzAeyScNtyC5InnM=.d6972e2f-2b67-4aef-9cc8-a5d2ef6e8cf0@github.com>
 <9drXzcmyQFF3YB9kmuSSJyAjF65eemK1mbKlU1G-l6I=.87361ff3-e07c-4f90-a5d8-98ed6d864a19@github.com>
Message-ID: <nVi_5m1j6wYFwqBh8Lc9qX0IU8mYwkr1qC90UynYjrg=.889f33c4-573e-4826-864f-21f255bfe781@github.com>

On Mon, 21 Jul 2025 13:30:47 GMT, SendaoYan <syan at openjdk.org> wrote:

> Explain that the number of max user processes limited by ulimit -u 4096 includes the number of threads created by the first create-thread process.

That's not the way ulimit should work in different sub-shells. What is the ulimit in the parent shell? I think the subshells are limited by the parent.

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

PR Comment: https://git.openjdk.org/jdk/pull/26401#issuecomment-3099081280

From kbarrett at openjdk.org  Mon Jul 21 21:36:29 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 21 Jul 2025 21:36:29 GMT
Subject: RFR: 8360941: [ubsan] MemRegion::end() shows runtime error:
 applying non-zero offset 8388608 to null pointer [v6]
In-Reply-To: <othqWmDcZqpdMXoYd9sm7OysbjAyS_SfSe5TZL0fCvE=.9afd9bb4-8909-4c2d-8bef-00f5f3e2a5c6@github.com>
References: <LP6FbAxZpwbGf6lkNvLcSRSEOu-mYKjWGAJYBSIMcyk=.775595dc-7f73-4248-a235-f4b58933396b@github.com>
 <othqWmDcZqpdMXoYd9sm7OysbjAyS_SfSe5TZL0fCvE=.9afd9bb4-8909-4c2d-8bef-00f5f3e2a5c6@github.com>
Message-ID: <e23Am13AtCi4GJPjXKZd729mWcwpi1uGbUn1L7AKCHE=.3e71032b-aaa0-4aeb-8d43-a8dbebf97f27@github.com>

On Mon, 21 Jul 2025 13:48:41 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When running HS test
>> gtest/GTestWrapper.java
>> with ubsan-enabled binaries on macOS aarch64, the following error is reported (did not see this so far on Linux but there we use gcc and it seems the gcc/ubsan checks are a bit more limited).
>> 
>> test/hotspot/gtest/gc/g1/test_freeRegionList.cpp:37: Failure
>> Death test: child_G1FreeRegionList_length_()
>>     Result: died but not with expected exit code:
>>             Terminated by signal 6 (core dumped)
>> Actual msg:
>> 
>> [  DEATH   ] /jdk/src/hotspot/share/memory/memRegion.hpp:66:43: runtime error: applying non-zero offset 8388608 to null pointer
>> [  DEATH   ]     #0 0x108afd6f4 in MemRegion::end() const+0x84 (libjvm.dylib:arm64+0x16556f4)
>> [  DEATH   ]     #1 0x1075c68a0 in G1FreeRegionList_length_other_vm_Test::TestBody()+0x380 (libjvm.dylib:arm64+0x11e8a0)
>> [  DEATH   ]     #2 0x1090f3bb0 in testing::Test::Run()+0xc0 (libjvm.dylib:arm64+0x1c4bbb0)
>> [  DEATH   ]     #3 0x1090f4d94 in testing::TestInfo::Run()+0x1e4 (libjvm.dylib:arm64+0x1c4cd94)
>> [  DEATH   ]     #4 0x1090f6754 in testing::TestSuite::Run()+0x43c (libjvm.dylib:arm64+0x1c4e754)
>> [  DEATH   ]     #5 0x109103ca0 in testing::internal::UnitTestImpl::RunAllTests()+0x48c (libjvm.dylib:arm64+0x1c5bca0)
>> [  DEATH   ]     #6 0x109103588 in testing::UnitTest::Run()+0x78 (libjvm.dylib:arm64+0x1c5b588)
>> [  DEATH   ]     #7 0x1074a9ac0 in runUnitTestsInner(int, char**)+0x724 (libjvm.dylib:arm64+0x1ac0)
>> [  DEATH   ]     #8 0x102dc3f18 in main+0x2c (gtestLauncher:arm64+0x100003f18)
>> [  DEATH   ]     #9 0x196fea0dc  (<unknown module>)
>> [  DEATH   ] 
>> [  DEATH   ] SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /jdk/src/hotspot/share/memory/memRegion.hpp:66:43 in 
>> [  DEATH   ] 
>> 
>> 
>> 
>> Seems the test_freeRegionList.cpp uses a special MemRegion starting at nullptr ; but this causes a bit of trouble when adding to start == nullptr .
>> So far I see this issue just in the gtest, seems other MemRegion objects do not start at nullptr .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Suggestion by Thomas Stuefe

Changes requested by kbarrett (Reviewer).

test/hotspot/gtest/gc/g1/test_freeRegionList.cpp line 50:

> 48:   const size_t sz = szw * BytesPerWord;
> 49:   char* addr = os::reserve_memory(sz, mtTest);
> 50:   MemRegion heap((HeapWord*)addr, szw);

So far as I can tell, there's no guarantee that `os::reserve_memory` will return an address with any
particular alignment. Since the earlier attempt with unaligned storage failed, it may only be by accident
that this isn't failing as well.  We have `os::reserve_memory_aligned`, or could add an extra region to
the desired size and align up the result.

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

PR Review: https://git.openjdk.org/jdk/pull/26216#pullrequestreview-3039929835
PR Review Comment: https://git.openjdk.org/jdk/pull/26216#discussion_r2220399489

From dholmes at openjdk.org  Tue Jul 22 00:39:34 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 22 Jul 2025 00:39:34 GMT
Subject: RFR: 8362846: Windows error reporting for dll_load doesn't check for a
 null buffer
Message-ID: <f9T0kMWo4bSSW8q1S7bYIh2w39-d8L3C_m5n0acKYyE=.ea2ddc53-edaf-40d5-b77e-83e1b58c4888@github.com>

Please review this simple fix for some missing null checks in `os::dll_load`. The primary issue handles Windows, while the additional is for Linux/BSD.

Testing:
- new gtest
- tiers 1-3

Thanks

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

Commit messages:
 - 8362846: Windows error reporting for dll_load doesn't check for a null buffer
 - 8362954: Missing error buffer null check in os::dll_load on Linux/BSD

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

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

From dholmes at openjdk.org  Tue Jul 22 00:41:31 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 22 Jul 2025 00:41:31 GMT
Subject: RFR: 8356941: AbstractMethodError in HotSpot Due to Incorrect
 Handling of Private Method [v5]
In-Reply-To: <WGeThEw5qnSvz2a3qvi31rGposTBBswNe-KY8HIL8sk=.951fcc7c-5157-43f5-9500-2548678b013b@github.com>
References: <qyWNTs0IOlf128C4ZdvOp9TE7O4w7bPaz2hJfHseIUk=.4a298588-6aff-471a-927b-beb3c9f0b194@github.com>
 <WGeThEw5qnSvz2a3qvi31rGposTBBswNe-KY8HIL8sk=.951fcc7c-5157-43f5-9500-2548678b013b@github.com>
Message-ID: <K_jnd_IFjgUzU4cVG2guq1GkjMmaYZzvQ5-MPeadY0E=.a3a0a20a-5dc5-459b-a5d5-53f4e4e1de32@github.com>

On Sun, 20 Jul 2025 22:47:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Private methods should never be considered as the implementation of a default method.
>> 
>> The first commit adds some additional logging I used to track down what was happening. I like it, but if reviewers think it too much I can drop it.
>> 
>> The second commit is the actual fix to exclude private methods, and adds the missing test case to the existing defmeth tests.
>> 
>> Testing:
>>  - tiers 1-4
>> 
>> Thanks
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo

Thanks again Coleen and Dan!

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

PR Comment: https://git.openjdk.org/jdk/pull/26302#issuecomment-3100144524

From dholmes at openjdk.org  Tue Jul 22 00:41:32 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 22 Jul 2025 00:41:32 GMT
Subject: Integrated: 8356941: AbstractMethodError in HotSpot Due to Incorrect
 Handling of Private Method
In-Reply-To: <qyWNTs0IOlf128C4ZdvOp9TE7O4w7bPaz2hJfHseIUk=.4a298588-6aff-471a-927b-beb3c9f0b194@github.com>
References: <qyWNTs0IOlf128C4ZdvOp9TE7O4w7bPaz2hJfHseIUk=.4a298588-6aff-471a-927b-beb3c9f0b194@github.com>
Message-ID: <HSY192B5hy3Hfc2CfIhg4DdpJhrBBrK_5bP7LT_WHiw=.2522a991-ed2f-4366-bcaf-c7d410a692a9@github.com>

On Mon, 14 Jul 2025 22:28:50 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Private methods should never be considered as the implementation of a default method.
> 
> The first commit adds some additional logging I used to track down what was happening. I like it, but if reviewers think it too much I can drop it.
> 
> The second commit is the actual fix to exclude private methods, and adds the missing test case to the existing defmeth tests.
> 
> Testing:
>  - tiers 1-4
> 
> Thanks

This pull request has now been integrated.

Changeset: 0385975f
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0385975f44fbe9d199677754ff5006bc5784b9c5
Stats:     14 lines in 2 files changed: 8 ins; 4 del; 2 mod

8356941: AbstractMethodError in HotSpot Due to Incorrect Handling of Private Method

Reviewed-by: coleenp, heidinga

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

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

From syan at openjdk.org  Tue Jul 22 01:08:30 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 22 Jul 2025 01:08:30 GMT
Subject: RFR: 8362834: Several runtime/Thread tests should mark as /native
 [v2]
In-Reply-To: <dvCMLVeZjh_iW8XHuhAPAs0aRcLR8SgTKkd5h_AW2kk=.573c93fd-4774-4d91-9395-a344fcd51bab@github.com>
References: <V6Eofnui54_4GbTMwOQ0MfQIYe55x6sscvPJFqF895c=.bcde2eab-03ba-4f46-8466-4d7153f66a14@github.com>
 <GP67qL_fUcbCfDnBjbETR17_sE88y_8PwmKQmVGfKuI=.75249a56-fca7-4dc5-a56d-023abe6db7a3@github.com>
 <dvCMLVeZjh_iW8XHuhAPAs0aRcLR8SgTKkd5h_AW2kk=.573c93fd-4774-4d91-9395-a344fcd51bab@github.com>
Message-ID: <zBVN4AYIIewPVyZzlpx5HkM1k6yQqvhvKqwP1kf5bOk=.bb223524-4fde-492b-b1ae-6fb71ad4e600@github.com>

On Mon, 21 Jul 2025 21:15:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update copyright year
>>  - Update copyright year
>
> Marked as reviewed by dholmes (Reviewer).

Thanks @dholmes-ora

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

PR Comment: https://git.openjdk.org/jdk/pull/26411#issuecomment-3100203376

From syan at openjdk.org  Tue Jul 22 01:08:31 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 22 Jul 2025 01:08:31 GMT
Subject: Integrated: 8362834: Several runtime/Thread tests should mark as
 /native
In-Reply-To: <V6Eofnui54_4GbTMwOQ0MfQIYe55x6sscvPJFqF895c=.bcde2eab-03ba-4f46-8466-4d7153f66a14@github.com>
References: <V6Eofnui54_4GbTMwOQ0MfQIYe55x6sscvPJFqF895c=.bcde2eab-03ba-4f46-8466-4d7153f66a14@github.com>
Message-ID: <zf25ON7eyqesMFMKXltGMpBTwUYIUMXEEVBc14EPODk=.86d0cf8d-a09c-43b3-b379-30307388160a@github.com>

On Mon, 21 Jul 2025 09:45:53 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Some of the runtime/Thread tests ready mark as /native:
> runtime/Thread/SuspendAtExit.java
> runtime/Thread/StopAtExit.java
> 
> But there are some of the runtime/Thread tests needed to mark as /native:
> runtime/Thread/AsyncExceptionTest.java
> runtime/Thread/AsyncExceptionOnMonitorEnter.java
> runtime/Thread/TestBreakSignalThreadDump.java#with_jsig
> runtime/Thread/TestBreakSignalThreadDump.java#default
> 
> Without -nativepath jtreg option, the test will report test failure, such as: "Execution failed: `main' threw exception: java.lang.RuntimeException: Expected to get exit value of [0], exit value is: [1]", after this PR without -nativepath jtreg option, the test will report "Error. Use -nativepath to specify the location of native code", this will make test usage more friendly.
> 
> Change has been verified locally, test-fix only, no risk.

This pull request has now been integrated.

Changeset: 699b8112
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/699b8112f8da7ceef2aa2a3ddb326aee88b29f8c
Stats:     7 lines in 3 files changed: 1 ins; 0 del; 6 mod

8362834: Several runtime/Thread tests should mark as /native

Reviewed-by: dholmes

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

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

From syan at openjdk.org  Tue Jul 22 02:04:24 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 22 Jul 2025 02:04:24 GMT
Subject: RFR: 8359827: Test runtime/Thread/ThreadCountLimit.java should run
 exclusively [v2]
In-Reply-To: <nVi_5m1j6wYFwqBh8Lc9qX0IU8mYwkr1qC90UynYjrg=.889f33c4-573e-4826-864f-21f255bfe781@github.com>
References: <KFZNv5pVvr7Rddlm5xifJz6VzPzlFkmO7XPXrdJGWHw=.0664dc6c-992a-473d-b974-b2c40e06f45b@github.com>
 <ChycL6uT1_9xEgldDbu37a-XnFdXjX3DCuQS2JBZi7w=.8cfa4026-208e-4b1f-a951-1cef8665481e@github.com>
 <GoVnA3fJZpXj9fHh8HFnrMOyO6ys32yBX2RPZ-ESdBw=.901f2c57-6513-4eaa-b5b0-7e00ab51e72a@github.com>
 <vteGzJ6y_nYJdsCkkjSR0XknFuAg3-t3mKI8QGH9ypM=.c0547fcf-ee47-4a0f-b73e-eef2ed7aa7c4@github.com>
 <gyOH3NaJKRjTF0-uJD27iaDa1AyDzAeyScNtyC5InnM=.d6972e2f-2b67-4aef-9cc8-a5d2ef6e8cf0@github.com>
 <9drXzcmyQFF3YB9kmuSSJyAjF65eemK1mbKlU1G-l6I=.87361ff3-e07c-4f90-a5d8-98ed6d864a19@github.com>
 <nVi_5m1j6wYFwqBh8Lc9qX0IU8mYwkr1qC90UynYjrg=.889f33c4-573e-4826-864f-21f255bfe781@github.com>
Message-ID: <3S9VWihhQYSNkWFaPKyl-PxTZ5SLzYRDLYBRRtZ5lhw=.b5d4a593-073d-4699-8f9d-8d5e039479af@github.com>

On Mon, 21 Jul 2025 21:20:19 GMT, David Holmes <dholmes at openjdk.org> wrote:

> That's not the way ulimit should work in different sub-shells. 

I initially thought that ulimit shouldn't work like that in different sub-shells. But actually ulimit works in different sub-shells as unexpectedly. 
The testcase runtime/Thread/ThreadCountLimit.java attempts to limited the number user processes of 4096 by adding the prefix "bash -c ulimit -u 4096" to start the [child process](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/Thread/ThreadCountLimit.java#L82), but the actual situation is that ulimit does not work as expected. If this testcase run with other tests simultaneously, the number of threads can created maybe be zero, at least the number always less than 4096, it depends how many user processes has been created in the test machine.

> What is the ulimit in the parent shell? I think the subshells are limited by the parent.

The ulimit in the parent shell is unlimited. The first process "./create-thread" can create 5k threads shows that the parent shell has no limit.

<img width="710" height="287" alt="image" src="https://github.com/user-attachments/assets/27b90b30-7107-4c66-a6bb-4e0fae3a0928" />

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

PR Comment: https://git.openjdk.org/jdk/pull/26401#issuecomment-3100424327

From dholmes at openjdk.org  Tue Jul 22 03:08:33 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 22 Jul 2025 03:08:33 GMT
Subject: RFR: 8356438: Update OutputAnalyzer to optionally print process
 output as it happens [v2]
In-Reply-To: <I79KijRZOM7Stzc7Sax_hFgxyPD_sEV2xaHZVipl2y4=.6f2fbe79-555c-4d04-9c38-25cea18075c5@github.com>
References: <cP-uMB2zwWrYPT2EOx-VpGAIaLjQY1YgkdQwehdjfo8=.d99ee1cf-5f91-40de-a5d1-fe6b762d1673@github.com>
 <J_G9wvyovxUuO0JdFMqnD7jvqUflEglF5L7qqvBc6-w=.e0def3d2-eb40-4167-b304-143f9d4c615d@github.com>
 <NBeas7VSHxEynwU9LXuGy-p9Lg9Tm5I9auSaHBExzRA=.effd0ad3-a5f2-4049-b4df-49030a0502ef@github.com>
 <v45mu9Zly3T9l94b-WP1p_4oB_Y2Pe0gdU6C3w_vRqM=.ebaa8261-3d70-43a1-82b2-bba9def061a2@github.com>
 <8pLm1mah1JKonu3z5tWwIpU_J5jEggSiBst-PNEdG4s=.931782e4-3e34-4535-bc71-622d76b871a7@github.com>
 <I79KijRZOM7Stzc7Sax_hFgxyPD_sEV2xaHZVipl2y4=.6f2fbe79-555c-4d04-9c38-25cea18075c5@github.com>
Message-ID: <e3ycLg1tKUV8ZSN7SMUwI-nF4pGkOp248Q1Y4xshAzE=.fb15e3c4-23ec-42ea-b2e6-724bef08c21e@github.com>

On Tue, 17 Jun 2025 17:33:31 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> To add on this, I should mention that I noticed a lot of tests are using OutputAnalyzer indirectly, returned as a result of a utility function, for example `ProcessTools.execute{Process,Command}`
>> 
>> 
>> git grep -E "ProcessTools.execute((Process)|(Command))" | wc -l
>>      351
>> 
>> 
>> Instead of calling one of OutputAnalyzer's constructors (700 invocations, but many of them are with the Eager, string based and not process based, constructor, which we don't care about)
>> 
>> 
>> I'm not sure adding additional parameters also to that code is an ideal solution, I'd much prefer adding the command line parameter to the docs of the OutputAnalyzer class, so that one knows to enable it when running the single test through jtreg
>> 
>> ---
>> 
>> That said, if there are multiple OutputAnalyzers going in a single test, then it makes perfect sense to have (or at least use) a constructor argument
>
>> But isn't it the person running the tests that wants to set this, not an inherent property of a test itself?
> 
> I'm not sure if I completely understand your question. A lot of tests use the `test.debug` system property to enable more verbose test output. It's enabled when someone runs the test e.g., `jtreg -Dtest.debug=true ...`
> 
> As you pointed out, a lot of tests may not care if the subprocess's output is cached or not, but for those that do, having to specify a second property could be onerous and using the same `test.debug` property inside OutputBuffer could result in unexpected output. If the OutputAnalyzer ctor took a boolean , a test could enable (or not) with something like `new OutputAnalyzer(childProc, Boolean.getBoolean("test.debug"))`
> 
>> I'm not sure adding additional parameters also to that code is an ideal solution,
> 
> There are two constructors that take Process objects as arguments. I was thinking that you could overload them to take the extra argument. 
> 
> 
> public OutputAnalyzer(Process process, Charset cs, boolean flushOutput)
> public OutputAnalyzer(Process process, boolean flushOutput)
> 
> 
> None of the existing tests would be affected and those tests that could benefit from inline output could specify it as needed. You're right that the use of OutputAnalyzer is usually indirect so that would cause some other code to be changed as well, but it only has to change when it becomes necessary to enable it. (And it can be updated in the same way i.e., overloading the methods to take an extra argument.)

As noted above, it is not usual for test to create an instance of `OutputAnalyzer` directly, so the extra constructor argument would seem of little general value. But okay, it might be useful in some case.

In terms of the existing PR to control the behaviour via System property, I'll repeat my comment that "verbose" is not really the right word here. This does not change the amount of output only where it also gets sent to, and that is hard-wired to stdout/err so the name should reflect that e.g. printToStdStreams ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25587#discussion_r2220910786

From dholmes at openjdk.org  Tue Jul 22 05:31:25 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 22 Jul 2025 05:31:25 GMT
Subject: RFR: 8359827: Test runtime/Thread/ThreadCountLimit.java should run
 exclusively [v3]
In-Reply-To: <IoSJXUyo3Tb4vjzbO2Qqz0OfZlHwCla5mOaIfonrRtk=.58292b7b-dabe-4de6-83b8-22831241e18d@github.com>
References: <KFZNv5pVvr7Rddlm5xifJz6VzPzlFkmO7XPXrdJGWHw=.0664dc6c-992a-473d-b974-b2c40e06f45b@github.com>
 <IoSJXUyo3Tb4vjzbO2Qqz0OfZlHwCla5mOaIfonrRtk=.58292b7b-dabe-4de6-83b8-22831241e18d@github.com>
Message-ID: <8Vg-JsCijuXpxUMHpedlHIY8H8UeZKO5hI4JiWai_4E=.88ec0fc9-8c3b-4fba-bfb3-a6f51167f7da@github.com>

On Mon, 21 Jul 2025 09:17:32 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> The test runtime/Thread/ThreadCountLimit.java was observed fails when run with other tests. The test start subprocess with [shell prefix command](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/Thread/ThreadCountLimit.java#L82) `ulimit -u 4096` which intend to limite the usage of thread number. But this will cause test fails when this test run with other tests. I create a demo to demonstrate that.
>> 
>> I start a java process which will create 5k threads, and then I can not start new java process with prefix `ulimit -u 4096` on the same machine.
>> 
>> <img width="1573" height="182" alt="image" src="https://github.com/user-attachments/assets/8dd53ade-cad7-4a2f-b5d9-d4b2d200b728" />
>> 
>> 
>> [ManyThreads.java.txt](https://github.com/user-attachments/files/21324354/ManyThreads.java.txt)
>> 
>> So it's necessary to make this test run sperately to make this test success.
>> Change has been verified locally, test-fix only, risk is low.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   mv test/hotspot/jtreg/runtime/Thread/stress/ThreadCountLimit.java test/hotspot/jtreg/resourcehogs/runtime/Thread/

There is definitely something unexpected/odd about the behaviour of `ulimit` when used in this way, though I do not observe the exact problems you describe unless I run a number of test processes concurrently - which is simply demonstrating machine overloading.

First, what does it even mean to use `ulimit -u`? The manpage says it limits the maximum number of processes  the user can create - it doesn't say "per shell" (and `setrlimit` confirms this). But you can easily demonstrate that the user can create far more processes/threads than have been set by a `ulimit` command running in another shell. So perhaps there is something else that affects how `ulimit` works, and that something is different between our systems and yours. ?? (I know there are capabilities that disable the limit but I couldn't see any indication such capabilities were present.)

Second, I observe that with `ulimit -u 1024` I can't even run `java-version` - which makes no sense in terms of number of threads created. Relatedly with a 4096 limit the test typically can only create around 2500 threads - so where did the other 1500+ go?

The use of `ulimit` was added to the test, for Linux only, because we found we could exhaust other resources that could then cause fatal errors in the VM in unexpected places - rather than the failure of `pthread_create` that we were trying to induce.

I'm really not sure how to proceed here. The change you propose affects all platforms, but there is only an issue for you on Linux.

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

PR Comment: https://git.openjdk.org/jdk/pull/26401#issuecomment-3101109747

From mbaesken at openjdk.org  Tue Jul 22 07:49:41 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 22 Jul 2025 07:49:41 GMT
Subject: RFR: 8360941: [ubsan] MemRegion::end() shows runtime error:
 applying non-zero offset 8388608 to null pointer [v7]
In-Reply-To: <LP6FbAxZpwbGf6lkNvLcSRSEOu-mYKjWGAJYBSIMcyk=.775595dc-7f73-4248-a235-f4b58933396b@github.com>
References: <LP6FbAxZpwbGf6lkNvLcSRSEOu-mYKjWGAJYBSIMcyk=.775595dc-7f73-4248-a235-f4b58933396b@github.com>
Message-ID: <LaXwwz-5Wjs6LXP6cHgcCFN9be8c64G5IfVa_zKmDQ8=.60ee0bf4-934b-4e6e-99aa-9522ed41a587@github.com>

> When running HS test
> gtest/GTestWrapper.java
> with ubsan-enabled binaries on macOS aarch64, the following error is reported (did not see this so far on Linux but there we use gcc and it seems the gcc/ubsan checks are a bit more limited).
> 
> test/hotspot/gtest/gc/g1/test_freeRegionList.cpp:37: Failure
> Death test: child_G1FreeRegionList_length_()
>     Result: died but not with expected exit code:
>             Terminated by signal 6 (core dumped)
> Actual msg:
> 
> [  DEATH   ] /jdk/src/hotspot/share/memory/memRegion.hpp:66:43: runtime error: applying non-zero offset 8388608 to null pointer
> [  DEATH   ]     #0 0x108afd6f4 in MemRegion::end() const+0x84 (libjvm.dylib:arm64+0x16556f4)
> [  DEATH   ]     #1 0x1075c68a0 in G1FreeRegionList_length_other_vm_Test::TestBody()+0x380 (libjvm.dylib:arm64+0x11e8a0)
> [  DEATH   ]     #2 0x1090f3bb0 in testing::Test::Run()+0xc0 (libjvm.dylib:arm64+0x1c4bbb0)
> [  DEATH   ]     #3 0x1090f4d94 in testing::TestInfo::Run()+0x1e4 (libjvm.dylib:arm64+0x1c4cd94)
> [  DEATH   ]     #4 0x1090f6754 in testing::TestSuite::Run()+0x43c (libjvm.dylib:arm64+0x1c4e754)
> [  DEATH   ]     #5 0x109103ca0 in testing::internal::UnitTestImpl::RunAllTests()+0x48c (libjvm.dylib:arm64+0x1c5bca0)
> [  DEATH   ]     #6 0x109103588 in testing::UnitTest::Run()+0x78 (libjvm.dylib:arm64+0x1c5b588)
> [  DEATH   ]     #7 0x1074a9ac0 in runUnitTestsInner(int, char**)+0x724 (libjvm.dylib:arm64+0x1ac0)
> [  DEATH   ]     #8 0x102dc3f18 in main+0x2c (gtestLauncher:arm64+0x100003f18)
> [  DEATH   ]     #9 0x196fea0dc  (<unknown module>)
> [  DEATH   ] 
> [  DEATH   ] SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /jdk/src/hotspot/share/memory/memRegion.hpp:66:43 in 
> [  DEATH   ] 
> 
> 
> 
> Seems the test_freeRegionList.cpp uses a special MemRegion starting at nullptr ; but this causes a bit of trouble when adding to start == nullptr .
> So far I see this issue just in the gtest, seems other MemRegion objects do not start at nullptr .

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

  Alignment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26216/files
  - new: https://git.openjdk.org/jdk/pull/26216/files/0a9adaab..53d20a2d

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

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

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

From stuefe at openjdk.org  Tue Jul 22 07:49:42 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 22 Jul 2025 07:49:42 GMT
Subject: RFR: 8360941: [ubsan] MemRegion::end() shows runtime error:
 applying non-zero offset 8388608 to null pointer [v6]
In-Reply-To: <e23Am13AtCi4GJPjXKZd729mWcwpi1uGbUn1L7AKCHE=.3e71032b-aaa0-4aeb-8d43-a8dbebf97f27@github.com>
References: <LP6FbAxZpwbGf6lkNvLcSRSEOu-mYKjWGAJYBSIMcyk=.775595dc-7f73-4248-a235-f4b58933396b@github.com>
 <othqWmDcZqpdMXoYd9sm7OysbjAyS_SfSe5TZL0fCvE=.9afd9bb4-8909-4c2d-8bef-00f5f3e2a5c6@github.com>
 <e23Am13AtCi4GJPjXKZd729mWcwpi1uGbUn1L7AKCHE=.3e71032b-aaa0-4aeb-8d43-a8dbebf97f27@github.com>
Message-ID: <8EmDTiK9GzGByvwR-qczVzTDVWmFjsmbC0nqNQcmx0Q=.53fb045f-9475-4d0d-b243-68934c75751b@github.com>

On Mon, 21 Jul 2025 21:33:27 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Suggestion by Thomas Stuefe
>
> test/hotspot/gtest/gc/g1/test_freeRegionList.cpp line 50:
> 
>> 48:   const size_t sz = szw * BytesPerWord;
>> 49:   char* addr = os::reserve_memory(sz, mtTest);
>> 50:   MemRegion heap((HeapWord*)addr, szw);
> 
> So far as I can tell, there's no guarantee that `os::reserve_memory` will return an address with any
> particular alignment. Since the earlier attempt with unaligned storage failed, it may only be by accident
> that this isn't failing as well.  We have `os::reserve_memory_aligned`, or could add an extra region to
> the desired size and align up the result.

`os::reserve_memory` addresses are always regular-page-aligned. But `os::reserve_memory_aligned` may be better here since I guess the addresses would better have been region-size-aligned, so aligned to G1HeapRegion::GrainWords. That could be larger than system page size.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26216#discussion_r2221537409

From mchevalier at openjdk.org  Tue Jul 22 08:16:33 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 22 Jul 2025 08:16:33 GMT
Subject: RFR: 8358696: Assert with extreme values for -XX:BciProfileWidth
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: <yVAjK7XL8NcTFAW8ukoMZJTv51sGlYPMI3dlE86MfbE=.39b08654-7480-4255-ac68-b0a353e9dc5f@github.com>

On Fri, 4 Jul 2025 21:47:24 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 ?

One nit, one open comment.

Not of a lot of opinion on whether to use `form_address` instead.  Since `BciProfileWidth` is a develop flag, I'm not too annoyed if we limit it to avoid some change that would affect product builds. Except of course if the offset issue is a deeper problem that deserves to be solved anyway.

src/hotspot/share/runtime/globals.hpp line 1354:

> 1352:           range(0, 8)                                                       \
> 1353:                                                                             \
> 1354:   develop(intx, BciProfileWidth, 2,                                         \

Recently, I've seen someone complaining about useless use of `intx`, saying that is brings less readability than a more fixed-width type when not needed. Here, [0, 5000] fits in 16 bits (even signed). One could change that into a simple `int` or something like that.

src/hotspot/share/runtime/globals.hpp line 1357:

> 1355:           "Number of return bci's to record in ret profile")                \
> 1356:           range(0, AARCH64_ONLY(1000) NOT_AARCH64(5000))                    \
> 1357:                                                                             \

Maybe that's one empty line too much (cf. other spacing just around).

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

PR Review: https://git.openjdk.org/jdk/pull/26139#pullrequestreview-3041683534
PR Review Comment: https://git.openjdk.org/jdk/pull/26139#discussion_r2221609770
PR Review Comment: https://git.openjdk.org/jdk/pull/26139#discussion_r2221600897

From syan at openjdk.org  Tue Jul 22 10:05:24 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 22 Jul 2025 10:05:24 GMT
Subject: RFR: 8359827: Test runtime/Thread/ThreadCountLimit.java should run
 exclusively [v4]
In-Reply-To: <KFZNv5pVvr7Rddlm5xifJz6VzPzlFkmO7XPXrdJGWHw=.0664dc6c-992a-473d-b974-b2c40e06f45b@github.com>
References: <KFZNv5pVvr7Rddlm5xifJz6VzPzlFkmO7XPXrdJGWHw=.0664dc6c-992a-473d-b974-b2c40e06f45b@github.com>
Message-ID: <aL4H04aHuIbBUQC4q61eZrGod5Xq2KwR6tywq-WDNrA=.aa21bfbe-d2d8-405e-8149-4e2613bf6bcb@github.com>

> Hi all,
> 
> The test runtime/Thread/ThreadCountLimit.java was observed fails when run with other tests. The test start subprocess with [shell prefix command](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/Thread/ThreadCountLimit.java#L82) `ulimit -u 4096` which intend to limite the usage of thread number. But this will cause test fails when this test run with other tests. I create a demo to demonstrate that.
> 
> I start a java process which will create 5k threads, and then I can not start new java process with prefix `ulimit -u 4096` on the same machine.
> 
> <img width="1573" height="182" alt="image" src="https://github.com/user-attachments/assets/8dd53ade-cad7-4a2f-b5d9-d4b2d200b728" />
> 
> 
> [ManyThreads.java.txt](https://github.com/user-attachments/files/21324354/ManyThreads.java.txt)
> 
> So it's necessary to make this test run sperately to make this test success.
> Change has been verified locally, test-fix only, risk is low.

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

  Use 'docker run --pids-limit 4096' to instead the original 'ulimit -u 4096'

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26401/files
  - new: https://git.openjdk.org/jdk/pull/26401/files/5d6c69bc..f993419b

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

  Stats: 327 lines in 4 files changed: 176 ins; 150 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26401.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26401/head:pull/26401

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

From syan at openjdk.org  Tue Jul 22 10:05:24 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 22 Jul 2025 10:05:24 GMT
Subject: RFR: 8359827: Test runtime/Thread/ThreadCountLimit.java should run
 exclusively [v3]
In-Reply-To: <8Vg-JsCijuXpxUMHpedlHIY8H8UeZKO5hI4JiWai_4E=.88ec0fc9-8c3b-4fba-bfb3-a6f51167f7da@github.com>
References: <KFZNv5pVvr7Rddlm5xifJz6VzPzlFkmO7XPXrdJGWHw=.0664dc6c-992a-473d-b974-b2c40e06f45b@github.com>
 <IoSJXUyo3Tb4vjzbO2Qqz0OfZlHwCla5mOaIfonrRtk=.58292b7b-dabe-4de6-83b8-22831241e18d@github.com>
 <8Vg-JsCijuXpxUMHpedlHIY8H8UeZKO5hI4JiWai_4E=.88ec0fc9-8c3b-4fba-bfb3-a6f51167f7da@github.com>
Message-ID: <Ze7HPgQndyhIC4njr3BoVIPuAwv96BEx4L5cKDWuYTo=.d6b5ea05-d9c0-4793-8d1a-03debd78fc58@github.com>

On Tue, 22 Jul 2025 05:28:28 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   mv test/hotspot/jtreg/runtime/Thread/stress/ThreadCountLimit.java test/hotspot/jtreg/resourcehogs/runtime/Thread/
>
> There is definitely something unexpected/odd about the behaviour of `ulimit` when used in this way, though I do not observe the exact problems you describe unless I run a number of test processes concurrently - which is simply demonstrating machine overloading.
> 
> First, what does it even mean to use `ulimit -u`? The manpage says it limits the maximum number of processes  the user can create - it doesn't say "per shell" (and `setrlimit` confirms this). But you can easily demonstrate that the user can create far more processes/threads than have been set by a `ulimit` command running in another shell. So perhaps there is something else that affects how `ulimit` works, and that something is different between our systems and yours. ?? (I know there are capabilities that disable the limit but I couldn't see any indication such capabilities were present.)
> 
> Second, I observe that with `ulimit -u 1024` I can't even run `java-version` - which makes no sense in terms of number of threads created. Relatedly with a 4096 limit the test typically can only create around 2500 threads - so where did the other 1500+ go?
> 
> The use of `ulimit` was added to the test, for Linux only, because we found we could exhaust other resources that could then cause fatal errors in the VM in unexpected places - rather than the failure of `pthread_create` that we were trying to induce.
> 
> I'm really not sure how to proceed here. The change you propose affects all platforms, but there is only an issue for you on Linux.

Hi @dholmes-ora 

> which is simply demonstrating machine overloading.

I think it's not machine overloading, becasuse the setting of 'ulimit -u' on my machine is 'unlimited'. I can create 5000 threads many times, show as below:

<img width="1013" height="811" alt="image" src="https://github.com/user-attachments/assets/9bee9870-d13c-4e00-b9c8-d2ad6813aa0f" />

> you can easily demonstrate that the user can create far more processes/threads than have been set by a ulimit command running in another shell

I think the 'ulimit -u' in sub-shell take effect in the sub-shell only, it's temporary setting, it will not affect the parent shell.

> Relatedly with a 4096 limit the test typically can only create around 2500 threads - so where did the other 1500+ go?

It seems that the sub-shell with 'ulimit -u 4096' prefix will count all the user processes number. It's just my speculatation.


Anyway, I change this PR to use `docker run --pids-limit 4096` to instead the original 'ulimit -u 4096'. It will make this test more complict but more elegant.

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

PR Comment: https://git.openjdk.org/jdk/pull/26401#issuecomment-3101970561

From syan at openjdk.org  Tue Jul 22 10:12:57 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 22 Jul 2025 10:12:57 GMT
Subject: RFR: 8359827: Test runtime/Thread/ThreadCountLimit.java should run
 exclusively [v5]
In-Reply-To: <KFZNv5pVvr7Rddlm5xifJz6VzPzlFkmO7XPXrdJGWHw=.0664dc6c-992a-473d-b974-b2c40e06f45b@github.com>
References: <KFZNv5pVvr7Rddlm5xifJz6VzPzlFkmO7XPXrdJGWHw=.0664dc6c-992a-473d-b974-b2c40e06f45b@github.com>
Message-ID: <QT7rtbEaWFobX9mwOPKAVGrve_o-oagGbZKZwvKQrSg=.ac9e0c24-78b3-4639-9740-8a41f5849799@github.com>

> Hi all,
> 
> The test runtime/Thread/ThreadCountLimit.java was observed fails when run with other tests. The test start subprocess with [shell prefix command](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/Thread/ThreadCountLimit.java#L82) `ulimit -u 4096` which intend to limite the usage of thread number. But this will cause test fails when this test run with other tests. I create a demo to demonstrate that.
> 
> I start a java process which will create 5k threads, and then I can not start new java process with prefix `ulimit -u 4096` on the same machine.
> 
> <img width="1573" height="182" alt="image" src="https://github.com/user-attachments/assets/8dd53ade-cad7-4a2f-b5d9-d4b2d200b728" />
> 
> 
> [ManyThreads.java.txt](https://github.com/user-attachments/files/21324354/ManyThreads.java.txt)
> 
> So it's necessary to make this test run sperately to make this test success.
> Change has been verified locally, test-fix only, risk is low.

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

  Remove extra whitespaces

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26401/files
  - new: https://git.openjdk.org/jdk/pull/26401/files/f993419b..374c297b

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

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

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

From stuefe at openjdk.org  Tue Jul 22 11:58:28 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 22 Jul 2025 11:58:28 GMT
Subject: RFR: 8360941: [ubsan] MemRegion::end() shows runtime error:
 applying non-zero offset 8388608 to null pointer [v7]
In-Reply-To: <LaXwwz-5Wjs6LXP6cHgcCFN9be8c64G5IfVa_zKmDQ8=.60ee0bf4-934b-4e6e-99aa-9522ed41a587@github.com>
References: <LP6FbAxZpwbGf6lkNvLcSRSEOu-mYKjWGAJYBSIMcyk=.775595dc-7f73-4248-a235-f4b58933396b@github.com>
 <LaXwwz-5Wjs6LXP6cHgcCFN9be8c64G5IfVa_zKmDQ8=.60ee0bf4-934b-4e6e-99aa-9522ed41a587@github.com>
Message-ID: <sS06DKX8TYMSYrXKteTiW894P8REKjupUCKb-DM8x_w=.6d46b0ee-46fb-41e3-94ba-1c3f3971f53a@github.com>

On Tue, 22 Jul 2025 07:49:41 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When running HS test
>> gtest/GTestWrapper.java
>> with ubsan-enabled binaries on macOS aarch64, the following error is reported (did not see this so far on Linux but there we use gcc and it seems the gcc/ubsan checks are a bit more limited).
>> 
>> test/hotspot/gtest/gc/g1/test_freeRegionList.cpp:37: Failure
>> Death test: child_G1FreeRegionList_length_()
>>     Result: died but not with expected exit code:
>>             Terminated by signal 6 (core dumped)
>> Actual msg:
>> 
>> [  DEATH   ] /jdk/src/hotspot/share/memory/memRegion.hpp:66:43: runtime error: applying non-zero offset 8388608 to null pointer
>> [  DEATH   ]     #0 0x108afd6f4 in MemRegion::end() const+0x84 (libjvm.dylib:arm64+0x16556f4)
>> [  DEATH   ]     #1 0x1075c68a0 in G1FreeRegionList_length_other_vm_Test::TestBody()+0x380 (libjvm.dylib:arm64+0x11e8a0)
>> [  DEATH   ]     #2 0x1090f3bb0 in testing::Test::Run()+0xc0 (libjvm.dylib:arm64+0x1c4bbb0)
>> [  DEATH   ]     #3 0x1090f4d94 in testing::TestInfo::Run()+0x1e4 (libjvm.dylib:arm64+0x1c4cd94)
>> [  DEATH   ]     #4 0x1090f6754 in testing::TestSuite::Run()+0x43c (libjvm.dylib:arm64+0x1c4e754)
>> [  DEATH   ]     #5 0x109103ca0 in testing::internal::UnitTestImpl::RunAllTests()+0x48c (libjvm.dylib:arm64+0x1c5bca0)
>> [  DEATH   ]     #6 0x109103588 in testing::UnitTest::Run()+0x78 (libjvm.dylib:arm64+0x1c5b588)
>> [  DEATH   ]     #7 0x1074a9ac0 in runUnitTestsInner(int, char**)+0x724 (libjvm.dylib:arm64+0x1ac0)
>> [  DEATH   ]     #8 0x102dc3f18 in main+0x2c (gtestLauncher:arm64+0x100003f18)
>> [  DEATH   ]     #9 0x196fea0dc  (<unknown module>)
>> [  DEATH   ] 
>> [  DEATH   ] SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /jdk/src/hotspot/share/memory/memRegion.hpp:66:43 in 
>> [  DEATH   ] 
>> 
>> 
>> 
>> Seems the test_freeRegionList.cpp uses a special MemRegion starting at nullptr ; but this causes a bit of trouble when adding to start == nullptr .
>> So far I see this issue just in the gtest, seems other MemRegion objects do not start at nullptr .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Alignment

Changes requested by stuefe (Reviewer).

test/hotspot/gtest/gc/g1/test_freeRegionList.cpp line 50:

> 48:   const size_t sz = szw * BytesPerWord;
> 49:   const size_t lpsz = os::large_page_size();
> 50:   char* addr = os::reserve_memory_aligned(sz, lpsz, mtTest);

Suggestion:

  char* addr = os::reserve_memory_aligned(sz, G1HeapRegion::GrainBytes, mtTest);


@MBaesken you want to align the start address at region size; not sure the G1 code we call in this test cares, but it might.

test/hotspot/gtest/gc/g1/test_freeRegionList.cpp line 94:

> 92:   bot_storage->uncommit_regions(0, num_regions_in_test);
> 93:   delete bot_storage;
> 94:   os::release_memory(addr, szw);

Wrong size; release_memory takes bytes, not words. Use `sz`.

This explains also the crash on Windows you told me about in your mail. Was this patch also in the testing queue?

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

PR Review: https://git.openjdk.org/jdk/pull/26216#pullrequestreview-3042623856
PR Review Comment: https://git.openjdk.org/jdk/pull/26216#discussion_r2222289653
PR Review Comment: https://git.openjdk.org/jdk/pull/26216#discussion_r2222273575

From dholmes at openjdk.org  Tue Jul 22 12:10:31 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 22 Jul 2025 12:10:31 GMT
Subject: RFR: 8359827: Test runtime/Thread/ThreadCountLimit.java should run
 exclusively [v5]
In-Reply-To: <QT7rtbEaWFobX9mwOPKAVGrve_o-oagGbZKZwvKQrSg=.ac9e0c24-78b3-4639-9740-8a41f5849799@github.com>
References: <KFZNv5pVvr7Rddlm5xifJz6VzPzlFkmO7XPXrdJGWHw=.0664dc6c-992a-473d-b974-b2c40e06f45b@github.com>
 <QT7rtbEaWFobX9mwOPKAVGrve_o-oagGbZKZwvKQrSg=.ac9e0c24-78b3-4639-9740-8a41f5849799@github.com>
Message-ID: <jGmaz-92bcMK8GfwIKdjQGJRwoX9LNNH0ozTq-JgO-Q=.66b1a4dd-a5a9-4755-ae45-e6b207bb00e0@github.com>

On Tue, 22 Jul 2025 10:12:57 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> The test runtime/Thread/ThreadCountLimit.java was observed fails when run with other tests. The test start subprocess with [shell prefix command](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/Thread/ThreadCountLimit.java#L82) `ulimit -u 4096` which intend to limite the usage of thread number. But this will cause test fails when this test run with other tests. I create a demo to demonstrate that.
>> 
>> I start a java process which will create 5k threads, and then I can not start new java process with prefix `ulimit -u 4096` on the same machine.
>> 
>> <img width="1573" height="182" alt="image" src="https://github.com/user-attachments/assets/8dd53ade-cad7-4a2f-b5d9-d4b2d200b728" />
>> 
>> 
>> [ManyThreads.java.txt](https://github.com/user-attachments/files/21324354/ManyThreads.java.txt)
>> 
>> So it's necessary to make this test run sperately to make this test success.
>> Change has been verified locally, test-fix only, risk is low.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove extra whitespaces

You can't just change the test to use docker! This is not a container test. We use special test tasks to run container tests in an environment where containers are enabled.

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

PR Comment: https://git.openjdk.org/jdk/pull/26401#issuecomment-3102434073

From syan at openjdk.org  Tue Jul 22 12:18:26 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 22 Jul 2025 12:18:26 GMT
Subject: RFR: 8359827: Test runtime/Thread/ThreadCountLimit.java should run
 exclusively [v6]
In-Reply-To: <KFZNv5pVvr7Rddlm5xifJz6VzPzlFkmO7XPXrdJGWHw=.0664dc6c-992a-473d-b974-b2c40e06f45b@github.com>
References: <KFZNv5pVvr7Rddlm5xifJz6VzPzlFkmO7XPXrdJGWHw=.0664dc6c-992a-473d-b974-b2c40e06f45b@github.com>
Message-ID: <fmXqxZ6du3sz6FUJ42NZ2kLMBQkOmDOP9SJUHK_RCCo=.1d086646-7415-42fa-acb0-bc29b05b4502@github.com>

> Hi all,
> 
> The test runtime/Thread/ThreadCountLimit.java was observed fails when run with other tests. The test start subprocess with [shell prefix command](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/Thread/ThreadCountLimit.java#L82) `ulimit -u 4096` which intend to limite the usage of thread number. But this will cause test fails when this test run with other tests. I create a demo to demonstrate that.
> 
> I start a java process which will create 5k threads, and then I can not start new java process with prefix `ulimit -u 4096` on the same machine.
> 
> <img width="1573" height="182" alt="image" src="https://github.com/user-attachments/assets/8dd53ade-cad7-4a2f-b5d9-d4b2d200b728" />
> 
> 
> [ManyThreads.java.txt](https://github.com/user-attachments/files/21324354/ManyThreads.java.txt)
> 
> So it's necessary to make this test run sperately to make this test success.
> Change has been verified locally, test-fix only, risk is low.

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

 - Revert "Use 'docker run --pids-limit 4096' to instead the original 'ulimit -u 4096'"
   
   This reverts commit f993419b20b5dd2273a4f6c3c54e79fb8f955383.
 - Revert "Remove extra whitespaces"
   
   This reverts commit 374c297b52b03e8b471465010f99b1b6bc3174f0.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26401/files
  - new: https://git.openjdk.org/jdk/pull/26401/files/374c297b..77884c21

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

  Stats: 327 lines in 4 files changed: 150 ins; 176 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26401.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26401/head:pull/26401

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

From syan at openjdk.org  Tue Jul 22 12:18:28 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 22 Jul 2025 12:18:28 GMT
Subject: RFR: 8359827: Test runtime/Thread/ThreadCountLimit.java should run
 exclusively [v5]
In-Reply-To: <jGmaz-92bcMK8GfwIKdjQGJRwoX9LNNH0ozTq-JgO-Q=.66b1a4dd-a5a9-4755-ae45-e6b207bb00e0@github.com>
References: <KFZNv5pVvr7Rddlm5xifJz6VzPzlFkmO7XPXrdJGWHw=.0664dc6c-992a-473d-b974-b2c40e06f45b@github.com>
 <QT7rtbEaWFobX9mwOPKAVGrve_o-oagGbZKZwvKQrSg=.ac9e0c24-78b3-4639-9740-8a41f5849799@github.com>
 <jGmaz-92bcMK8GfwIKdjQGJRwoX9LNNH0ozTq-JgO-Q=.66b1a4dd-a5a9-4755-ae45-e6b207bb00e0@github.com>
Message-ID: <CMPd1uwnjkxVfTvXYr_IHf9Q9EsnK3TkEP4ykNyP6TQ=.dee5e5df-2059-42a3-81ca-e50504eb6fd6@github.com>

On Tue, 22 Jul 2025 12:07:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

> You can't just change the test to use docker! This is not a container test. We use special test tasks to run container tests in an environment where containers are enabled.

Okey, I have revert the docker commit.

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

PR Comment: https://git.openjdk.org/jdk/pull/26401#issuecomment-3102456501

From syan at openjdk.org  Tue Jul 22 12:18:28 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 22 Jul 2025 12:18:28 GMT
Subject: RFR: 8359827: Test runtime/Thread/ThreadCountLimit.java should run
 exclusively [v5]
In-Reply-To: <CMPd1uwnjkxVfTvXYr_IHf9Q9EsnK3TkEP4ykNyP6TQ=.dee5e5df-2059-42a3-81ca-e50504eb6fd6@github.com>
References: <KFZNv5pVvr7Rddlm5xifJz6VzPzlFkmO7XPXrdJGWHw=.0664dc6c-992a-473d-b974-b2c40e06f45b@github.com>
 <QT7rtbEaWFobX9mwOPKAVGrve_o-oagGbZKZwvKQrSg=.ac9e0c24-78b3-4639-9740-8a41f5849799@github.com>
 <jGmaz-92bcMK8GfwIKdjQGJRwoX9LNNH0ozTq-JgO-Q=.66b1a4dd-a5a9-4755-ae45-e6b207bb00e0@github.com>
 <CMPd1uwnjkxVfTvXYr_IHf9Q9EsnK3TkEP4ykNyP6TQ=.dee5e5df-2059-42a3-81ca-e50504eb6fd6@github.com>
Message-ID: <C0FLc4rEJ-RA-MiigFcnlEdzgAlKR4TO_AbiHRTasL8=.522d5d6e-5463-46a8-8086-9db5f85bdfa6@github.com>

On Tue, 22 Jul 2025 12:14:47 GMT, SendaoYan <syan at openjdk.org> wrote:

> You can't just change the test to use docker! This is not a container test. We use special test tasks to run container tests in an environment where containers are enabled.

Okey, I have revert the docker commit.

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

PR Comment: https://git.openjdk.org/jdk/pull/26401#issuecomment-3102458289

From dholmes at openjdk.org  Tue Jul 22 12:18:27 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 22 Jul 2025 12:18:27 GMT
Subject: RFR: 8359827: Test runtime/Thread/ThreadCountLimit.java should run
 exclusively [v3]
In-Reply-To: <Ze7HPgQndyhIC4njr3BoVIPuAwv96BEx4L5cKDWuYTo=.d6b5ea05-d9c0-4793-8d1a-03debd78fc58@github.com>
References: <KFZNv5pVvr7Rddlm5xifJz6VzPzlFkmO7XPXrdJGWHw=.0664dc6c-992a-473d-b974-b2c40e06f45b@github.com>
 <IoSJXUyo3Tb4vjzbO2Qqz0OfZlHwCla5mOaIfonrRtk=.58292b7b-dabe-4de6-83b8-22831241e18d@github.com>
 <8Vg-JsCijuXpxUMHpedlHIY8H8UeZKO5hI4JiWai_4E=.88ec0fc9-8c3b-4fba-bfb3-a6f51167f7da@github.com>
 <Ze7HPgQndyhIC4njr3BoVIPuAwv96BEx4L5cKDWuYTo=.d6b5ea05-d9c0-4793-8d1a-03debd78fc58@github.com>
Message-ID: <tcEAZv4Ise48MPjAItf8WIYF0gWLgUMfXGXo9aq9SmM=.2f0122fb-20b0-4e65-94bc-0303b4f46081@github.com>

On Tue, 22 Jul 2025 09:58:53 GMT, SendaoYan <syan at openjdk.org> wrote:

> I think the 'ulimit -u' in sub-shell take effect in the sub-shell only, it's temporary setting, it will not affect the parent shell.

I'm finding some of these statements to be contradictory to the problem being stated. If the ulimit setting only affects the sub-shell then it can't cause other concurrent tests to hit the limit and fail to create threads! 

> It seems that the sub-shell with 'ulimit -u 4096' prefix will count all the user processes number. It's just my speculatation. That's why this test not suitable run with other tests simultaneous

If the sub-shell counts all processes/threads belonging to the user and applies the new ulimit then that would make some sense. But again how does that then cause any problem in a different shell?

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

PR Comment: https://git.openjdk.org/jdk/pull/26401#issuecomment-3102453314

From syan at openjdk.org  Tue Jul 22 12:45:25 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 22 Jul 2025 12:45:25 GMT
Subject: RFR: 8359827: Test runtime/Thread/ThreadCountLimit.java should run
 exclusively [v3]
In-Reply-To: <tcEAZv4Ise48MPjAItf8WIYF0gWLgUMfXGXo9aq9SmM=.2f0122fb-20b0-4e65-94bc-0303b4f46081@github.com>
References: <KFZNv5pVvr7Rddlm5xifJz6VzPzlFkmO7XPXrdJGWHw=.0664dc6c-992a-473d-b974-b2c40e06f45b@github.com>
 <IoSJXUyo3Tb4vjzbO2Qqz0OfZlHwCla5mOaIfonrRtk=.58292b7b-dabe-4de6-83b8-22831241e18d@github.com>
 <8Vg-JsCijuXpxUMHpedlHIY8H8UeZKO5hI4JiWai_4E=.88ec0fc9-8c3b-4fba-bfb3-a6f51167f7da@github.com>
 <Ze7HPgQndyhIC4njr3BoVIPuAwv96BEx4L5cKDWuYTo=.d6b5ea05-d9c0-4793-8d1a-03debd78fc58@github.com>
 <tcEAZv4Ise48MPjAItf8WIYF0gWLgUMfXGXo9aq9SmM=.2f0122fb-20b0-4e65-94bc-0303b4f46081@github.com>
Message-ID: <HbPI6HEEAV_ExgbIxIPOm4X4BiHnIq88RFNG9FTRfhc=.d31510f7-268a-4fc8-8a8c-cd952d809a2f@github.com>

On Tue, 22 Jul 2025 12:13:44 GMT, David Holmes <dholmes at openjdk.org> wrote:

> If the ulimit setting only affects the sub-shell then it can't cause other concurrent tests to hit the limit and fail to create threads!

Maybe some of my previous statements have caused some misunderstandings.
The usage of ulimit in this testcase will not cause other concurrent tests to hit the limit, but will cause this test itself do not have enough user processes to start the java.
On the huge core number machine, every test will create more JIT compiler threads and more GC work threads. So when this test run with other tests simultancely, we can see this test can not start subprocess java with prefix "ulimit -u", the subprocess java report `Failed to start thread "GC Thread#0"`, because the subprocess has limited by "ulimit -u 4096", and the user processes resources maybe has been occupied by other tests which run simultancely. And the other tests run normally, because they do not have 'ulimit -u' explicitly.

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

PR Comment: https://git.openjdk.org/jdk/pull/26401#issuecomment-3102544916

From snatarajan at openjdk.org  Tue Jul 22 13:03:11 2025
From: snatarajan at openjdk.org (Saranya Natarajan)
Date: Tue, 22 Jul 2025 13:03:11 GMT
Subject: RFR: 8358696: Assert with extreme values for -XX:BciProfileWidth
 [v2]
In-Reply-To: <yVAjK7XL8NcTFAW8ukoMZJTv51sGlYPMI3dlE86MfbE=.39b08654-7480-4255-ac68-b0a353e9dc5f@github.com>
References: <5TRVeAXUQi6quM-nDWEij_jk6M5K2Vk31RA-Yjd8F2M=.5b63da45-93c3-4251-9e2e-3c64b7953919@github.com>
 <yVAjK7XL8NcTFAW8ukoMZJTv51sGlYPMI3dlE86MfbE=.39b08654-7480-4255-ac68-b0a353e9dc5f@github.com>
Message-ID: <-UlWQi6Pf7UwQKUR8sL4_Rhoj9MEd8UMlH7naG_W7QM=.d8947291-df9e-40e8-8007-4438c6c490c3@github.com>

On Tue, 22 Jul 2025 08:08:28 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> Saranya Natarajan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   addressing review comment 1
>
> src/hotspot/share/runtime/globals.hpp line 1354:
> 
>> 1352:           range(0, 8)                                                       \
>> 1353:                                                                             \
>> 1354:   develop(intx, BciProfileWidth, 2,                                         \
> 
> Recently, I've seen someone complaining about useless use of `intx`, saying that is brings less readability than a more fixed-width type when not needed. Here, [0, 5000] fits in 16 bits (even signed). One could change that into a simple `int` or something like that.

Since `int` seems to fit the range. I have changed `intx` to `int `

> src/hotspot/share/runtime/globals.hpp line 1357:
> 
>> 1355:           "Number of return bci's to record in ret profile")                \
>> 1356:           range(0, AARCH64_ONLY(1000) NOT_AARCH64(5000))                    \
>> 1357:                                                                             \
> 
> Maybe that's one empty line too much (cf. other spacing just around).

Thank you. I fixed this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26139#discussion_r2222457832
PR Review Comment: https://git.openjdk.org/jdk/pull/26139#discussion_r2222456543

From snatarajan at openjdk.org  Tue Jul 22 13:03:10 2025
From: snatarajan at openjdk.org (Saranya Natarajan)
Date: Tue, 22 Jul 2025 13:03:10 GMT
Subject: RFR: 8358696: Assert with extreme values for -XX:BciProfileWidth
 [v2]
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: <U596ZXZkQMp6_k-EORvogaTUVDMX35kHoMQA1mNtI-E=.40b24280-34ca-49f2-a1f0-776840d73b12@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 comment 1

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26139/files
  - new: https://git.openjdk.org/jdk/pull/26139/files/6a36457d..a32b6ead

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

  Stats: 2 lines in 1 file changed: 0 ins; 1 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 rriggs at openjdk.org  Tue Jul 22 14:11:29 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 22 Jul 2025 14:11:29 GMT
Subject: RFR: 8356438: Update OutputAnalyzer to optionally print process
 output as it happens [v2]
In-Reply-To: <J_G9wvyovxUuO0JdFMqnD7jvqUflEglF5L7qqvBc6-w=.e0def3d2-eb40-4167-b304-143f9d4c615d@github.com>
References: <cP-uMB2zwWrYPT2EOx-VpGAIaLjQY1YgkdQwehdjfo8=.d99ee1cf-5f91-40de-a5d1-fe6b762d1673@github.com>
 <J_G9wvyovxUuO0JdFMqnD7jvqUflEglF5L7qqvBc6-w=.e0def3d2-eb40-4167-b304-143f9d4c615d@github.com>
Message-ID: <9Hxf6U6rzK6SZMDlZkwuyjszdFQLSv0Vb6TAWF24nGw=.499d5efe-83cc-43df-a36a-4499857adaea@github.com>

On Thu, 5 Jun 2025 09:36:37 GMT, Alice Pellegrini <duke at openjdk.org> wrote:

>> The implemented solution modifies the `OutputBuffer` implementation instead of the `OutputAnalyzer` implementation.
>> This is because the **OutputBuffer implementation which handles processes** (LazyOutputBuffer) starts a thread in its constructor, so we would need to add a strange additional constructor parameter to the `OutputBuffer.of(Process, Charset)` static method, while the printing through to stdout (and stderr) only makes sense for LazyOutputBuffer.
>> 
>> I believe changing the config option from `outputanalyzer.verbose` to `output buffer.verbose` would make it cleaner, and avoid referencing the OutputAnalyzer in the OutputBuffer implementation.
>
> Alice Pellegrini has updated the pull request with a new target base 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 8356438-outputanalyzer-optional-print
>  - Update test/lib/jdk/test/lib/process/OutputBuffer.java
>    
>    Co-authored-by: Chen Liang <liach at openjdk.org>
>  - Initial working solution

Catching up a bit. The use case is for running a test from the commandline where the timing of the output seems to be significant to the debugging sessions?  It is assumed that the test launches a subprocess and is monitoring its state.

Is there an example of the test where this would be used?

The test utilities of OutputAnalyzer may not be what you need. 
They encapsulate a number of behaviors that are readily available using ProcessBuilder and Process.

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

PR Comment: https://git.openjdk.org/jdk/pull/25587#issuecomment-3102914137

From mbaesken at openjdk.org  Tue Jul 22 14:16:40 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 22 Jul 2025 14:16:40 GMT
Subject: RFR: 8360941: [ubsan] MemRegion::end() shows runtime error:
 applying non-zero offset 8388608 to null pointer [v8]
In-Reply-To: <LP6FbAxZpwbGf6lkNvLcSRSEOu-mYKjWGAJYBSIMcyk=.775595dc-7f73-4248-a235-f4b58933396b@github.com>
References: <LP6FbAxZpwbGf6lkNvLcSRSEOu-mYKjWGAJYBSIMcyk=.775595dc-7f73-4248-a235-f4b58933396b@github.com>
Message-ID: <OxUVocYa0ZKGd55UmlMmfzO1QAKm9S2HxTWULDSZF5s=.750a3d6b-2e1a-4a7c-8bf9-c2a7504761ff@github.com>

> When running HS test
> gtest/GTestWrapper.java
> with ubsan-enabled binaries on macOS aarch64, the following error is reported (did not see this so far on Linux but there we use gcc and it seems the gcc/ubsan checks are a bit more limited).
> 
> test/hotspot/gtest/gc/g1/test_freeRegionList.cpp:37: Failure
> Death test: child_G1FreeRegionList_length_()
>     Result: died but not with expected exit code:
>             Terminated by signal 6 (core dumped)
> Actual msg:
> 
> [  DEATH   ] /jdk/src/hotspot/share/memory/memRegion.hpp:66:43: runtime error: applying non-zero offset 8388608 to null pointer
> [  DEATH   ]     #0 0x108afd6f4 in MemRegion::end() const+0x84 (libjvm.dylib:arm64+0x16556f4)
> [  DEATH   ]     #1 0x1075c68a0 in G1FreeRegionList_length_other_vm_Test::TestBody()+0x380 (libjvm.dylib:arm64+0x11e8a0)
> [  DEATH   ]     #2 0x1090f3bb0 in testing::Test::Run()+0xc0 (libjvm.dylib:arm64+0x1c4bbb0)
> [  DEATH   ]     #3 0x1090f4d94 in testing::TestInfo::Run()+0x1e4 (libjvm.dylib:arm64+0x1c4cd94)
> [  DEATH   ]     #4 0x1090f6754 in testing::TestSuite::Run()+0x43c (libjvm.dylib:arm64+0x1c4e754)
> [  DEATH   ]     #5 0x109103ca0 in testing::internal::UnitTestImpl::RunAllTests()+0x48c (libjvm.dylib:arm64+0x1c5bca0)
> [  DEATH   ]     #6 0x109103588 in testing::UnitTest::Run()+0x78 (libjvm.dylib:arm64+0x1c5b588)
> [  DEATH   ]     #7 0x1074a9ac0 in runUnitTestsInner(int, char**)+0x724 (libjvm.dylib:arm64+0x1ac0)
> [  DEATH   ]     #8 0x102dc3f18 in main+0x2c (gtestLauncher:arm64+0x100003f18)
> [  DEATH   ]     #9 0x196fea0dc  (<unknown module>)
> [  DEATH   ] 
> [  DEATH   ] SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /jdk/src/hotspot/share/memory/memRegion.hpp:66:43 in 
> [  DEATH   ] 
> 
> 
> 
> Seems the test_freeRegionList.cpp uses a special MemRegion starting at nullptr ; but this causes a bit of trouble when adding to start == nullptr .
> So far I see this issue just in the gtest, seems other MemRegion objects do not start at nullptr .

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

  Adjust alignment and freeing

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26216/files
  - new: https://git.openjdk.org/jdk/pull/26216/files/53d20a2d..bf783386

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

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

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

From mgronlun at openjdk.org  Tue Jul 22 14:39:28 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 22 Jul 2025 14:39:28 GMT
Subject: RFR: 8362846: Windows error reporting for dll_load doesn't check
 for a null buffer
In-Reply-To: <f9T0kMWo4bSSW8q1S7bYIh2w39-d8L3C_m5n0acKYyE=.ea2ddc53-edaf-40d5-b77e-83e1b58c4888@github.com>
References: <f9T0kMWo4bSSW8q1S7bYIh2w39-d8L3C_m5n0acKYyE=.ea2ddc53-edaf-40d5-b77e-83e1b58c4888@github.com>
Message-ID: <HkiAragJeenrJxyyqXhv05sIggAbV36tDAj-3_-Dkro=.08ced0f4-ab4f-4752-895b-aeaeff95bd7e@github.com>

On Tue, 22 Jul 2025 00:31:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this simple fix for some missing null checks in `os::dll_load`. The primary issue handles Windows, while the additional is for Linux/BSD.
> 
> Testing:
> - new gtest
> - tiers 1-3
> 
> Thanks

Seems to be broader than just Windows?

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

PR Comment: https://git.openjdk.org/jdk/pull/26420#issuecomment-3103056857

From mgronlun at openjdk.org  Tue Jul 22 14:42:25 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 22 Jul 2025 14:42:25 GMT
Subject: RFR: 8362846: Windows error reporting for dll_load doesn't check
 for a null buffer
In-Reply-To: <f9T0kMWo4bSSW8q1S7bYIh2w39-d8L3C_m5n0acKYyE=.ea2ddc53-edaf-40d5-b77e-83e1b58c4888@github.com>
References: <f9T0kMWo4bSSW8q1S7bYIh2w39-d8L3C_m5n0acKYyE=.ea2ddc53-edaf-40d5-b77e-83e1b58c4888@github.com>
Message-ID: <brp_vU_IBzsdT4s6lz2QBgnUaOL-EF8Iib6ICjxRR3g=.3f9baec8-61da-4159-8af7-4b802d55adfa@github.com>

On Tue, 22 Jul 2025 00:31:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this simple fix for some missing null checks in `os::dll_load`. The primary issue handles Windows, while the additional is for Linux/BSD.
> 
> Testing:
> - new gtest
> - tiers 1-3
> 
> Thanks

Looks good.

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

Marked as reviewed by mgronlun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26420#pullrequestreview-3043343582

From sspitsyn at openjdk.org  Tue Jul 22 15:18:00 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 22 Jul 2025 15:18:00 GMT
Subject: RFR: 8306324: StopThread results in thread being marked as
 interrupted, leading to unexpected InterruptedException
In-Reply-To: <C54IPjQer4AezxFqKIjFRbkGnlLCitFZLL1mnr4O_gQ=.c53ac3cf-ceee-4260-afee-620b8a241ca5@github.com>
References: <sDAklD-arV33IpWiJwMkwUfNPMAmsr5cgboU4y0hjhk=.192cd7e5-f2a2-4b5c-83a9-5111bf1926ec@github.com>
 <C54IPjQer4AezxFqKIjFRbkGnlLCitFZLL1mnr4O_gQ=.c53ac3cf-ceee-4260-afee-620b8a241ca5@github.com>
Message-ID: <ImGHURJermwdwu95tfZaA_0yfhqB4DId5S_DO0oJ2ek=.1590fd4a-36e2-4c4c-8417-697f9f8d9c8d@github.com>

On Fri, 18 Jul 2025 18:44:45 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`
>
> Thank you for the comments and suggestions!
> I'll give it a try to get rid of the interrupt flag setting.

> @sspitsyn It might be useful to reach out to the IDEs to see what they are doing. From a quick test with IntelliJ then it appears to invoke both StopThread and InterruptThread when "Exception to Throw" is used. In that case, it means that Thread.sleep will wakeup, even if StopThread doesn't interrupt.

Good suggestion, thanks.

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

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

From iklam at openjdk.org  Tue Jul 22 16:27:18 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 22 Jul 2025 16:27:18 GMT
Subject: RFR: 8360555: Archive all unnamed modules in CDS full module graph
 [v2]
In-Reply-To: <wShFgP1f2myBNCuyVnLXYiB1PEBQlkW5VcyIDmyeoRo=.fff71539-455b-4109-8f9c-81c2e16d0bc0@github.com>
References: <wShFgP1f2myBNCuyVnLXYiB1PEBQlkW5VcyIDmyeoRo=.fff71539-455b-4109-8f9c-81c2e16d0bc0@github.com>
Message-ID: <_vFFlWeNVOvdMJINFxpATL3_gC2xFhk5MH_2KXD3ahg=.8c826ef9-d6c9-4a5c-b0f8-48a50e647db4@github.com>

> The CDS full module graph is supposed to contain a snapshot of the boot layer, which has 3 unnamed modules for the boot, platform and system class loaders. Each unnamed module is represented by a `java.lang.Module` Java object and a `ModuleEntry` C++ object.
> 
> Currently, we archive only the `java.lang.Module` for the platform and system loaders. The other 4 objects are dynamically created in the production run while executing Java bytecodes during VM bootstrap.
> 
> With this PR, we archive all of the above 6 objects when `CDSConfig::is_dumping_full_module_graph()` is true.
> 
> This is required for [JDK-8350550](https://bugs.openjdk.org/browse/JDK-8350550), as we need the `java.lang.Module` object for archived classes in the unnamed module of the boot loader prior to executing any Java code.
> 
> We also archive the `ModuleEntry` objects for the 3 unnamed modules for uniformity, as these objects are already archived for named modules.

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge branch 'master' into 8360555-archive-all-unnamed-modules
 - 8360555: Archive all unnamed modules in CDS full module graph

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

Changes: https://git.openjdk.org/jdk/pull/26082/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26082&range=01
  Stats: 187 lines in 13 files changed: 140 ins; 17 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/26082.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26082/head:pull/26082

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

From coleenp at openjdk.org  Tue Jul 22 17:02:12 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 22 Jul 2025 17:02:12 GMT
Subject: RFR: 8360555: Archive all unnamed modules in CDS full module graph
 [v2]
In-Reply-To: <_vFFlWeNVOvdMJINFxpATL3_gC2xFhk5MH_2KXD3ahg=.8c826ef9-d6c9-4a5c-b0f8-48a50e647db4@github.com>
References: <wShFgP1f2myBNCuyVnLXYiB1PEBQlkW5VcyIDmyeoRo=.fff71539-455b-4109-8f9c-81c2e16d0bc0@github.com>
 <_vFFlWeNVOvdMJINFxpATL3_gC2xFhk5MH_2KXD3ahg=.8c826ef9-d6c9-4a5c-b0f8-48a50e647db4@github.com>
Message-ID: <Qjok1MhxHy61Q-eIt-bY3uCbCRQjQ2cR2pLRv5grX3I=.67cdae39-7ede-46f9-b840-b7f4dbf7b2e6@github.com>

On Tue, 22 Jul 2025 16:27:18 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The CDS full module graph is supposed to contain a snapshot of the boot layer, which has 3 unnamed modules for the boot, platform and system class loaders. Each unnamed module is represented by a `java.lang.Module` Java object and a `ModuleEntry` C++ object.
>> 
>> Currently, we archive only the `java.lang.Module` for the platform and system loaders. The other 4 objects are dynamically created in the production run while executing Java bytecodes during VM bootstrap.
>> 
>> With this PR, we archive all of the above 6 objects when `CDSConfig::is_dumping_full_module_graph()` is true.
>> 
>> This is required for [JDK-8350550](https://bugs.openjdk.org/browse/JDK-8350550), as we need the `java.lang.Module` object for archived classes in the unnamed module of the boot loader prior to executing any Java code.
>> 
>> We also archive the `ModuleEntry` objects for the 3 unnamed modules for uniformity, as these objects are already archived for named modules.
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into 8360555-archive-all-unnamed-modules
>  - 8360555: Archive all unnamed modules in CDS full module graph

Marked as reviewed by coleenp (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26082#pullrequestreview-3044001789

From kbarrett at openjdk.org  Tue Jul 22 19:08:54 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 22 Jul 2025 19:08:54 GMT
Subject: RFR: 8362846: Windows error reporting for dll_load doesn't check
 for a null buffer
In-Reply-To: <f9T0kMWo4bSSW8q1S7bYIh2w39-d8L3C_m5n0acKYyE=.ea2ddc53-edaf-40d5-b77e-83e1b58c4888@github.com>
References: <f9T0kMWo4bSSW8q1S7bYIh2w39-d8L3C_m5n0acKYyE=.ea2ddc53-edaf-40d5-b77e-83e1b58c4888@github.com>
Message-ID: <0g3ddMVYahyR8f2m9dbGfhhiAfwmgHHtAd5UwFRPm_I=.f27ca57e-7430-433c-a8d1-1600f0a96a04@github.com>

On Tue, 22 Jul 2025 00:31:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this simple fix for some missing null checks in `os::dll_load`. The primary issue handles Windows, while the additional is for Linux/BSD.
> 
> Testing:
> - new gtest
> - tiers 1-3
> 
> Thanks

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26420#pullrequestreview-3044499723

From kbarrett at openjdk.org  Tue Jul 22 20:06:55 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 22 Jul 2025 20:06:55 GMT
Subject: RFR: 8360941: [ubsan] MemRegion::end() shows runtime error:
 applying non-zero offset 8388608 to null pointer [v8]
In-Reply-To: <OxUVocYa0ZKGd55UmlMmfzO1QAKm9S2HxTWULDSZF5s=.750a3d6b-2e1a-4a7c-8bf9-c2a7504761ff@github.com>
References: <LP6FbAxZpwbGf6lkNvLcSRSEOu-mYKjWGAJYBSIMcyk=.775595dc-7f73-4248-a235-f4b58933396b@github.com>
 <OxUVocYa0ZKGd55UmlMmfzO1QAKm9S2HxTWULDSZF5s=.750a3d6b-2e1a-4a7c-8bf9-c2a7504761ff@github.com>
Message-ID: <VPlD65Sq5rtT9Tk1B2A6lTV9D1p-kP0XEy16VA9HVk0=.31b8939a-e8b0-422d-bdd3-9d3d8f0695ac@github.com>

On Tue, 22 Jul 2025 14:16:40 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When running HS test
>> gtest/GTestWrapper.java
>> with ubsan-enabled binaries on macOS aarch64, the following error is reported (did not see this so far on Linux but there we use gcc and it seems the gcc/ubsan checks are a bit more limited).
>> 
>> test/hotspot/gtest/gc/g1/test_freeRegionList.cpp:37: Failure
>> Death test: child_G1FreeRegionList_length_()
>>     Result: died but not with expected exit code:
>>             Terminated by signal 6 (core dumped)
>> Actual msg:
>> 
>> [  DEATH   ] /jdk/src/hotspot/share/memory/memRegion.hpp:66:43: runtime error: applying non-zero offset 8388608 to null pointer
>> [  DEATH   ]     #0 0x108afd6f4 in MemRegion::end() const+0x84 (libjvm.dylib:arm64+0x16556f4)
>> [  DEATH   ]     #1 0x1075c68a0 in G1FreeRegionList_length_other_vm_Test::TestBody()+0x380 (libjvm.dylib:arm64+0x11e8a0)
>> [  DEATH   ]     #2 0x1090f3bb0 in testing::Test::Run()+0xc0 (libjvm.dylib:arm64+0x1c4bbb0)
>> [  DEATH   ]     #3 0x1090f4d94 in testing::TestInfo::Run()+0x1e4 (libjvm.dylib:arm64+0x1c4cd94)
>> [  DEATH   ]     #4 0x1090f6754 in testing::TestSuite::Run()+0x43c (libjvm.dylib:arm64+0x1c4e754)
>> [  DEATH   ]     #5 0x109103ca0 in testing::internal::UnitTestImpl::RunAllTests()+0x48c (libjvm.dylib:arm64+0x1c5bca0)
>> [  DEATH   ]     #6 0x109103588 in testing::UnitTest::Run()+0x78 (libjvm.dylib:arm64+0x1c5b588)
>> [  DEATH   ]     #7 0x1074a9ac0 in runUnitTestsInner(int, char**)+0x724 (libjvm.dylib:arm64+0x1ac0)
>> [  DEATH   ]     #8 0x102dc3f18 in main+0x2c (gtestLauncher:arm64+0x100003f18)
>> [  DEATH   ]     #9 0x196fea0dc  (<unknown module>)
>> [  DEATH   ] 
>> [  DEATH   ] SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /jdk/src/hotspot/share/memory/memRegion.hpp:66:43 in 
>> [  DEATH   ] 
>> 
>> 
>> 
>> Seems the test_freeRegionList.cpp uses a special MemRegion starting at nullptr ; but this causes a bit of trouble when adding to start == nullptr .
>> So far I see this issue just in the gtest, seems other MemRegion objects do not start at nullptr .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust alignment and freeing

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26216#pullrequestreview-3044707093

From kbarrett at openjdk.org  Tue Jul 22 20:06:56 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 22 Jul 2025 20:06:56 GMT
Subject: RFR: 8360941: [ubsan] MemRegion::end() shows runtime error:
 applying non-zero offset 8388608 to null pointer [v6]
In-Reply-To: <8EmDTiK9GzGByvwR-qczVzTDVWmFjsmbC0nqNQcmx0Q=.53fb045f-9475-4d0d-b243-68934c75751b@github.com>
References: <LP6FbAxZpwbGf6lkNvLcSRSEOu-mYKjWGAJYBSIMcyk=.775595dc-7f73-4248-a235-f4b58933396b@github.com>
 <othqWmDcZqpdMXoYd9sm7OysbjAyS_SfSe5TZL0fCvE=.9afd9bb4-8909-4c2d-8bef-00f5f3e2a5c6@github.com>
 <e23Am13AtCi4GJPjXKZd729mWcwpi1uGbUn1L7AKCHE=.3e71032b-aaa0-4aeb-8d43-a8dbebf97f27@github.com>
 <8EmDTiK9GzGByvwR-qczVzTDVWmFjsmbC0nqNQcmx0Q=.53fb045f-9475-4d0d-b243-68934c75751b@github.com>
Message-ID: <FjWGqQYet7l_wL1rhUueLarYF9yFYdpxFVd_ST-avCY=.4043a9d9-8c70-4a98-999a-07f4ee69d482@github.com>

On Tue, 22 Jul 2025 07:44:26 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> test/hotspot/gtest/gc/g1/test_freeRegionList.cpp line 50:
>> 
>>> 48:   const size_t sz = szw * BytesPerWord;
>>> 49:   char* addr = os::reserve_memory(sz, mtTest);
>>> 50:   MemRegion heap((HeapWord*)addr, szw);
>> 
>> So far as I can tell, there's no guarantee that `os::reserve_memory` will return an address with any
>> particular alignment. Since the earlier attempt with unaligned storage failed, it may only be by accident
>> that this isn't failing as well.  We have `os::reserve_memory_aligned`, or could add an extra region to
>> the desired size and align up the result.
>
> `os::reserve_memory` addresses are always regular-page-aligned. But `os::reserve_memory_aligned` may be better here since I guess the addresses would better have been region-size-aligned, so aligned to G1HeapRegion::GrainWords. That could be larger than system page size.

Too bad the only way to find out about that alignment behavior is to dig into the sources for all ports
and read the documentation for the underlying OS function. :(

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26216#discussion_r2223717975

From iklam at openjdk.org  Tue Jul 22 20:20:05 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 22 Jul 2025 20:20:05 GMT
Subject: RFR: 8360555: Archive all unnamed modules in CDS full module graph
 [v2]
In-Reply-To: <Qjok1MhxHy61Q-eIt-bY3uCbCRQjQ2cR2pLRv5grX3I=.67cdae39-7ede-46f9-b840-b7f4dbf7b2e6@github.com>
References: <wShFgP1f2myBNCuyVnLXYiB1PEBQlkW5VcyIDmyeoRo=.fff71539-455b-4109-8f9c-81c2e16d0bc0@github.com>
 <_vFFlWeNVOvdMJINFxpATL3_gC2xFhk5MH_2KXD3ahg=.8c826ef9-d6c9-4a5c-b0f8-48a50e647db4@github.com>
 <Qjok1MhxHy61Q-eIt-bY3uCbCRQjQ2cR2pLRv5grX3I=.67cdae39-7ede-46f9-b840-b7f4dbf7b2e6@github.com>
Message-ID: <gDKXK7PuCQYRK-ZbSHVDOgdHVmtOsZhqtXFOuuhJZXw=.48d21c3e-1534-4968-b45f-5caf8adaef07@github.com>

On Tue, 22 Jul 2025 16:59:07 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge branch 'master' into 8360555-archive-all-unnamed-modules
>>  - 8360555: Archive all unnamed modules in CDS full module graph
>
> Marked as reviewed by coleenp (Reviewer).

Thanks @coleenp and @iwanowww for the review
Passed tiers 1-4 and builds-tier-5

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

PR Comment: https://git.openjdk.org/jdk/pull/26082#issuecomment-3104700644

From iklam at openjdk.org  Tue Jul 22 20:20:06 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 22 Jul 2025 20:20:06 GMT
Subject: Integrated: 8360555: Archive all unnamed modules in CDS full module
 graph
In-Reply-To: <wShFgP1f2myBNCuyVnLXYiB1PEBQlkW5VcyIDmyeoRo=.fff71539-455b-4109-8f9c-81c2e16d0bc0@github.com>
References: <wShFgP1f2myBNCuyVnLXYiB1PEBQlkW5VcyIDmyeoRo=.fff71539-455b-4109-8f9c-81c2e16d0bc0@github.com>
Message-ID: <qKrT8MaARdUaoXNN2HMBfN5O80tB6Af22_FdUCJpz5w=.6d2d7d31-e3bd-48a4-bd73-7bce4014628a@github.com>

On Wed, 2 Jul 2025 00:18:28 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The CDS full module graph is supposed to contain a snapshot of the boot layer, which has 3 unnamed modules for the boot, platform and system class loaders. Each unnamed module is represented by a `java.lang.Module` Java object and a `ModuleEntry` C++ object.
> 
> Currently, we archive only the `java.lang.Module` for the platform and system loaders. The other 4 objects are dynamically created in the production run while executing Java bytecodes during VM bootstrap.
> 
> With this PR, we archive all of the above 6 objects when `CDSConfig::is_dumping_full_module_graph()` is true.
> 
> This is required for [JDK-8350550](https://bugs.openjdk.org/browse/JDK-8350550), as we need the `java.lang.Module` object for archived classes in the unnamed module of the boot loader prior to executing any Java code.
> 
> We also archive the `ModuleEntry` objects for the 3 unnamed modules for uniformity, as these objects are already archived for named modules.

This pull request has now been integrated.

Changeset: aae99022
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/aae9902234d36049ec99a2f50934c526dd6235eb
Stats:     187 lines in 13 files changed: 140 ins; 17 del; 30 mod

8360555: Archive all unnamed modules in CDS full module graph

Reviewed-by: coleenp, vlivanov

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

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

From dholmes at openjdk.org  Tue Jul 22 21:45:04 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 22 Jul 2025 21:45:04 GMT
Subject: RFR: 8359827: Test runtime/Thread/ThreadCountLimit.java should run
 exclusively [v3]
In-Reply-To: <HbPI6HEEAV_ExgbIxIPOm4X4BiHnIq88RFNG9FTRfhc=.d31510f7-268a-4fc8-8a8c-cd952d809a2f@github.com>
References: <KFZNv5pVvr7Rddlm5xifJz6VzPzlFkmO7XPXrdJGWHw=.0664dc6c-992a-473d-b974-b2c40e06f45b@github.com>
 <IoSJXUyo3Tb4vjzbO2Qqz0OfZlHwCla5mOaIfonrRtk=.58292b7b-dabe-4de6-83b8-22831241e18d@github.com>
 <8Vg-JsCijuXpxUMHpedlHIY8H8UeZKO5hI4JiWai_4E=.88ec0fc9-8c3b-4fba-bfb3-a6f51167f7da@github.com>
 <Ze7HPgQndyhIC4njr3BoVIPuAwv96BEx4L5cKDWuYTo=.d6b5ea05-d9c0-4793-8d1a-03debd78fc58@github.com>
 <tcEAZv4Ise48MPjAItf8WIYF0gWLgUMfXGXo9aq9SmM=.2f0122fb-20b0-4e65-94bc-0303b4f46081@github.com>
 <HbPI6HEEAV_ExgbIxIPOm4X4BiHnIq88RFNG9FTRfhc=.d31510f7-268a-4fc8-8a8c-cd952d809a2f@github.com>
Message-ID: <ZXRmX-EzDb-sfekQe-rV7f5nhmbxtY8XLFJbTIhgC-I=.6a11783c-e0fe-4c75-811a-d11aa1e1e14b@github.com>

On Tue, 22 Jul 2025 12:39:42 GMT, SendaoYan <syan at openjdk.org> wrote:

> The usage of ulimit in this testcase will not cause other concurrent tests to hit the limit, but will cause this test itself do not have enough user processes to start the java.

Sorry - right I get it now. So basically with enough other activity on the machine all the 4096 process/thread capacity may have already been used up before the test can run. It isn't this test that is the "resource hog" as such. What we really want to do is more like `ulimit -u <current process/thread count> + 4096` but getting the current value is tricky.

One possible solution would be to loop so that if we get exitcode 1 then we retry with 4096*2 etc. 

      if (Platform.isLinux()) {
        // On Linux this test sometimes hits the limit for the maximum number of memory mappings,
        // which leads to various other failure modes. Run this test with a limit on how many
        // threads the process is allowed to create, so we hit that limit first. What we want is
        // for another "limit" processes to be available, but ulimit doesn't work that way and
        // if there are already many running processes we could fail to even start the JVM properly.
        // So we loop increasing the limit until we get a successful run. This is not foolproof.
        int pLimit = 4096;
        final String ULIMIT_CMD = "ulimit -u ";
        ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder(ThreadCountLimit.class.getName());
        String javaCmd = ProcessTools.getCommandLine(pb);
        for (int i = 1; i <= 10; i++) {
            // Relaunch the test with args.length > 0, and the ulimit set
            String cmd = ULIMIT_CMD + Integer.toString(pLimit * i) + " && " + javaCmd + " dummy";
            System.out.println("Trying: bash -c " + cmd);
            OutputAnalyzer oa = ProcessTools.executeCommand("bash", "-c", cmd);
            int exitValue = oa.getExitValue();
            switch (exitValue) {
              case 0: System.out.println("Success!"); return;
              case 1: System.out.println("Retry ..."); continue;
              default: oa.shouldHaveExitValue(0); // generate error report
            }
        }
        throw new Error("Failed to perform a successful run!");
      } else {
        // Not Linux so run directly.
        test();
      }

Took 5 loops to run on my system (ulimit -u 24576) when I had an unrestricted version of the test running which has about 20700 live threads.

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

PR Comment: https://git.openjdk.org/jdk/pull/26401#issuecomment-3104913285

From dholmes at openjdk.org  Wed Jul 23 00:04:59 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 23 Jul 2025 00:04:59 GMT
Subject: RFR: 8359827: Test runtime/Thread/ThreadCountLimit.java should run
 exclusively [v6]
In-Reply-To: <fmXqxZ6du3sz6FUJ42NZ2kLMBQkOmDOP9SJUHK_RCCo=.1d086646-7415-42fa-acb0-bc29b05b4502@github.com>
References: <KFZNv5pVvr7Rddlm5xifJz6VzPzlFkmO7XPXrdJGWHw=.0664dc6c-992a-473d-b974-b2c40e06f45b@github.com>
 <fmXqxZ6du3sz6FUJ42NZ2kLMBQkOmDOP9SJUHK_RCCo=.1d086646-7415-42fa-acb0-bc29b05b4502@github.com>
Message-ID: <dhEW4HAlBoQl2un1tUT3o2C16KfiP6UAehbM44DWYHg=.c0f038ae-3f2b-4f83-9f0b-507fad1f7cba@github.com>

On Tue, 22 Jul 2025 12:18:26 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> The test runtime/Thread/ThreadCountLimit.java was observed fails when run with other tests. The test start subprocess with [shell prefix command](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/Thread/ThreadCountLimit.java#L82) `ulimit -u 4096` which intend to limite the usage of thread number. But this will cause test fails when this test run with other tests. I create a demo to demonstrate that.
>> 
>> I start a java process which will create 5k threads, and then I can not start new java process with prefix `ulimit -u 4096` on the same machine.
>> 
>> <img width="1573" height="182" alt="image" src="https://github.com/user-attachments/assets/8dd53ade-cad7-4a2f-b5d9-d4b2d200b728" />
>> 
>> 
>> [ManyThreads.java.txt](https://github.com/user-attachments/files/21324354/ManyThreads.java.txt)
>> 
>> So it's necessary to make this test run sperately to make this test success.
>> Change has been verified locally, test-fix only, risk is low.
>
> SendaoYan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Use 'docker run --pids-limit 4096' to instead the original 'ulimit -u 4096'"
>    
>    This reverts commit f993419b20b5dd2273a4f6c3c54e79fb8f955383.
>  - Revert "Remove extra whitespaces"
>    
>    This reverts commit 374c297b52b03e8b471465010f99b1b6bc3174f0.

Testing - please ignore.

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

PR Comment: https://git.openjdk.org/jdk/pull/26401#issuecomment-3105189258

From dholmes at openjdk.org  Wed Jul 23 00:40:08 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 23 Jul 2025 00:40:08 GMT
Subject: RFR: 8362846: Windows error reporting for dll_load doesn't check
 for a null buffer
In-Reply-To: <HkiAragJeenrJxyyqXhv05sIggAbV36tDAj-3_-Dkro=.08ced0f4-ab4f-4752-895b-aeaeff95bd7e@github.com>
References: <f9T0kMWo4bSSW8q1S7bYIh2w39-d8L3C_m5n0acKYyE=.ea2ddc53-edaf-40d5-b77e-83e1b58c4888@github.com>
 <HkiAragJeenrJxyyqXhv05sIggAbV36tDAj-3_-Dkro=.08ced0f4-ab4f-4752-895b-aeaeff95bd7e@github.com>
Message-ID: <KIE4fMrMTYBCurqQDoHzfo9sIFY1zCbbbP4bt5SsWzE=.61c520d4-e570-4977-b82e-475e3acccb17@github.com>

On Tue, 22 Jul 2025 14:36:48 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Please review this simple fix for some missing null checks in `os::dll_load`. The primary issue handles Windows, while the additional is for Linux/BSD.
>> 
>> Testing:
>> - new gtest
>> - tiers 1-3
>> 
>> Thanks
>
> Seems to be broader than just Windows?

Thanks for the reviews @mgronlun and @kimbarrett !

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

PR Comment: https://git.openjdk.org/jdk/pull/26420#issuecomment-3105244854

From dholmes at openjdk.org  Wed Jul 23 00:40:08 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 23 Jul 2025 00:40:08 GMT
Subject: Integrated: 8362846: Windows error reporting for dll_load doesn't
 check for a null buffer
In-Reply-To: <f9T0kMWo4bSSW8q1S7bYIh2w39-d8L3C_m5n0acKYyE=.ea2ddc53-edaf-40d5-b77e-83e1b58c4888@github.com>
References: <f9T0kMWo4bSSW8q1S7bYIh2w39-d8L3C_m5n0acKYyE=.ea2ddc53-edaf-40d5-b77e-83e1b58c4888@github.com>
Message-ID: <4SuKSksbnO4iDu_okVIVZHpevqpNG66fsJjfKu9my5k=.2e25a622-aee6-4971-af80-e62f6e63c209@github.com>

On Tue, 22 Jul 2025 00:31:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this simple fix for some missing null checks in `os::dll_load`. The primary issue handles Windows, while the additional is for Linux/BSD.
> 
> Testing:
> - new gtest
> - tiers 1-3
> 
> Thanks

This pull request has now been integrated.

Changeset: 0735dc27
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0735dc27c71de46896afd2f0f608319304a3d549
Stats:     23 lines in 4 files changed: 22 ins; 0 del; 1 mod

8362846: Windows error reporting for dll_load doesn't check for a null buffer
8362954: Missing error buffer null check in os::dll_load on Linux/BSD

Reviewed-by: mgronlun, kbarrett

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

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

From syan at openjdk.org  Wed Jul 23 02:36:36 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 23 Jul 2025 02:36:36 GMT
Subject: RFR: 8359827: Test runtime/Thread/ThreadCountLimit.java should run
 exclusively [v7]
In-Reply-To: <KFZNv5pVvr7Rddlm5xifJz6VzPzlFkmO7XPXrdJGWHw=.0664dc6c-992a-473d-b974-b2c40e06f45b@github.com>
References: <KFZNv5pVvr7Rddlm5xifJz6VzPzlFkmO7XPXrdJGWHw=.0664dc6c-992a-473d-b974-b2c40e06f45b@github.com>
Message-ID: <sHxfoHH3aqq01Seqj1_yCAjVd6KaZsaErEMmk2SHfck=.9fcf329d-a766-4dcc-b390-bc9f87106ac5@github.com>

> Hi all,
> 
> The test runtime/Thread/ThreadCountLimit.java was observed fails when run with other tests. The test start subprocess with [shell prefix command](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/Thread/ThreadCountLimit.java#L82) `ulimit -u 4096` which intend to limite the usage of thread number. But this will cause test fails when this test run with other tests. I create a demo to demonstrate that.
> 
> I start a java process which will create 5k threads, and then I can not start new java process with prefix `ulimit -u 4096` on the same machine.
> 
> <img width="1573" height="182" alt="image" src="https://github.com/user-attachments/assets/8dd53ade-cad7-4a2f-b5d9-d4b2d200b728" />
> 
> 
> [ManyThreads.java.txt](https://github.com/user-attachments/files/21324354/ManyThreads.java.txt)
> 
> So it's necessary to make this test run sperately to make this test success.
> Change has been verified locally, test-fix only, risk is low.

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

 - Revert change to TEST.groups
 - Increase ulimit -u value to try 10 times

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26401/files
  - new: https://git.openjdk.org/jdk/pull/26401/files/77884c21..f49733d7

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

  Stats: 314 lines in 3 files changed: 164 ins; 150 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26401.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26401/head:pull/26401

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

From syan at openjdk.org  Wed Jul 23 02:36:36 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 23 Jul 2025 02:36:36 GMT
Subject: RFR: 8359827: Test runtime/Thread/ThreadCountLimit.java should run
 exclusively [v3]
In-Reply-To: <ZXRmX-EzDb-sfekQe-rV7f5nhmbxtY8XLFJbTIhgC-I=.6a11783c-e0fe-4c75-811a-d11aa1e1e14b@github.com>
References: <KFZNv5pVvr7Rddlm5xifJz6VzPzlFkmO7XPXrdJGWHw=.0664dc6c-992a-473d-b974-b2c40e06f45b@github.com>
 <IoSJXUyo3Tb4vjzbO2Qqz0OfZlHwCla5mOaIfonrRtk=.58292b7b-dabe-4de6-83b8-22831241e18d@github.com>
 <8Vg-JsCijuXpxUMHpedlHIY8H8UeZKO5hI4JiWai_4E=.88ec0fc9-8c3b-4fba-bfb3-a6f51167f7da@github.com>
 <Ze7HPgQndyhIC4njr3BoVIPuAwv96BEx4L5cKDWuYTo=.d6b5ea05-d9c0-4793-8d1a-03debd78fc58@github.com>
 <tcEAZv4Ise48MPjAItf8WIYF0gWLgUMfXGXo9aq9SmM=.2f0122fb-20b0-4e65-94bc-0303b4f46081@github.com>
 <HbPI6HEEAV_ExgbIxIPOm4X4BiHnIq88RFNG9FTRfhc=.d31510f7-268a-4fc8-8a8c-cd952d809a2f@github.com>
 <ZXRmX-EzDb-sfekQe-rV7f5nhmbxtY8XLFJbTIhgC-I=.6a11783c-e0fe-4c75-811a-d11aa1e1e14b@github.com>
Message-ID: <k2SR-aUC0VBF-HFKmxiADbEtPVov_iNLZWMIlZeShqA=.1096b886-b418-4fa4-8d36-b1ff11909442@github.com>

On Tue, 22 Jul 2025 21:41:44 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> If the ulimit setting only affects the sub-shell then it can't cause other concurrent tests to hit the limit and fail to create threads!
>> 
>> Maybe some of my previous statements have caused some misunderstandings.
>> The usage of ulimit in this testcase will not cause other concurrent tests to hit the limit, but will cause this test itself do not have enough user processes to start the java.
>> On the huge core number machine, every test will create more JIT compiler threads and more GC work threads. So when this test run with other tests simultancely, we can see this test can not start subprocess java with prefix "ulimit -u", the subprocess java report `Failed to start thread "GC Thread#0"`, because the subprocess has limited by "ulimit -u 4096", and the user processes resources maybe has been occupied by other tests which run simultancely. And the other tests run normally, because they do not have 'ulimit -u' explicitly.
>
>> The usage of ulimit in this testcase will not cause other concurrent tests to hit the limit, but will cause this test itself do not have enough user processes to start the java.
> 
> Sorry - right I get it now. So basically with enough other activity on the machine all the 4096 process/thread capacity may have already been used up before the test can run. It isn't this test that is the "resource hog" as such. What we really want to do is more like `ulimit -u <current process/thread count> + 4096` but getting the current value is tricky.
> 
> One possible solution would be to loop so that if we get exitcode 1 then we retry with 4096*2 etc. 
> 
>       if (Platform.isLinux()) {
>         // On Linux this test sometimes hits the limit for the maximum number of memory mappings,
>         // which leads to various other failure modes. Run this test with a limit on how many
>         // threads the process is allowed to create, so we hit that limit first. What we want is
>         // for another "limit" processes to be available, but ulimit doesn't work that way and
>         // if there are already many running processes we could fail to even start the JVM properly.
>         // So we loop increasing the limit until we get a successful run. This is not foolproof.
>         int pLimit = 4096;
>         final String ULIMIT_CMD = "ulimit -u ";
>         ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder(ThreadCountLimit.class.getName());
>         String javaCmd = ProcessTools.getCommandLine(pb);
>         for (int i = 1; i <= 10; i++) {
>             // Relaunch the test with args.length > 0, and the ulimit set
>             String cmd = ULIMIT_CMD + Integer.toString(pLimit * i) + " && " + javaCmd + " dummy";
>             System.out.println("Trying: bash -c " + cmd);
>             OutputAnalyzer oa = ProcessTools.executeCommand("bash", "-c", cmd);
>             int exitValue = oa.getExitValue();
>             switch (exitValue) {
>               case 0: System.out.println("Success!"); return;
>               case 1: System.out.println("Retry ..."); continue;
>               default: oa.shouldHaveExitValue(0); // generate error report
>             }
>         }
>         throw new Error("Failed to perform a successful run!");
>       } else {
>         // Not Linux so run directly.
>         test();
>       }
> 
> Took 5 loops to run on my system (ulimit -u 24576) when I had an unrestricted version of the test running which has about 20700 live threads.

Thanks @dholmes-ora very much.

I will verified this patch by ours CI.

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

PR Comment: https://git.openjdk.org/jdk/pull/26401#issuecomment-3105457139

From syan at openjdk.org  Wed Jul 23 02:39:44 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 23 Jul 2025 02:39:44 GMT
Subject: RFR: 8359827: Test runtime/Thread/ThreadCountLimit.java should run
 exclusively [v8]
In-Reply-To: <KFZNv5pVvr7Rddlm5xifJz6VzPzlFkmO7XPXrdJGWHw=.0664dc6c-992a-473d-b974-b2c40e06f45b@github.com>
References: <KFZNv5pVvr7Rddlm5xifJz6VzPzlFkmO7XPXrdJGWHw=.0664dc6c-992a-473d-b974-b2c40e06f45b@github.com>
Message-ID: <Zyi8B9UHcUeZORddfEGvYzV03Rp3xL97dMw9cu7RxfA=.c28feabe-5a1c-4574-885e-836639413ecf@github.com>

> Hi all,
> 
> The test runtime/Thread/ThreadCountLimit.java was observed fails when run with other tests. The test start subprocess with [shell prefix command](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/Thread/ThreadCountLimit.java#L82) `ulimit -u 4096` which intend to limite the usage of thread number. But this will cause test fails when this test run with other tests. I create a demo to demonstrate that.
> 
> I start a java process which will create 5k threads, and then I can not start new java process with prefix `ulimit -u 4096` on the same machine.
> 
> <img width="1573" height="182" alt="image" src="https://github.com/user-attachments/assets/8dd53ade-cad7-4a2f-b5d9-d4b2d200b728" />
> 
> 
> [ManyThreads.java.txt](https://github.com/user-attachments/files/21324354/ManyThreads.java.txt)
> 
> So it's necessary to make this test run sperately to make this test success.
> Change has been verified locally, test-fix only, risk is low.

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

  Revert change to TEST.groups

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26401/files
  - new: https://git.openjdk.org/jdk/pull/26401/files/f49733d7..00cd0abb

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

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

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

From dholmes at openjdk.org  Wed Jul 23 04:05:54 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 23 Jul 2025 04:05:54 GMT
Subject: RFR: 8359827: Test runtime/Thread/ThreadCountLimit.java should run
 exclusively [v8]
In-Reply-To: <Zyi8B9UHcUeZORddfEGvYzV03Rp3xL97dMw9cu7RxfA=.c28feabe-5a1c-4574-885e-836639413ecf@github.com>
References: <KFZNv5pVvr7Rddlm5xifJz6VzPzlFkmO7XPXrdJGWHw=.0664dc6c-992a-473d-b974-b2c40e06f45b@github.com>
 <Zyi8B9UHcUeZORddfEGvYzV03Rp3xL97dMw9cu7RxfA=.c28feabe-5a1c-4574-885e-836639413ecf@github.com>
Message-ID: <iaUUJJJdDz7ugQLYvCFTIjv5KOFqS-jHE__oJrPHk0k=.35ca79b6-5e55-4ab9-b470-a9a7916a3b8d@github.com>

On Wed, 23 Jul 2025 02:39:44 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> The test runtime/Thread/ThreadCountLimit.java was observed fails when run with other tests. The test start subprocess with [shell prefix command](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/Thread/ThreadCountLimit.java#L82) `ulimit -u 4096` which intend to limite the usage of thread number. But this will cause test fails when this test run with other tests. I create a demo to demonstrate that.
>> 
>> I start a java process which will create 5k threads, and then I can not start new java process with prefix `ulimit -u 4096` on the same machine.
>> 
>> <img width="1573" height="182" alt="image" src="https://github.com/user-attachments/assets/8dd53ade-cad7-4a2f-b5d9-d4b2d200b728" />
>> 
>> 
>> [ManyThreads.java.txt](https://github.com/user-attachments/files/21324354/ManyThreads.java.txt)
>> 
>> So it's necessary to make this test run sperately to make this test success.
>> Change has been verified locally, test-fix only, risk is low.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert change to TEST.groups

Looks good to me :)

I will run this through our CI as well.

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

PR Review: https://git.openjdk.org/jdk/pull/26401#pullrequestreview-3045504852

From dholmes at openjdk.org  Wed Jul 23 07:30:55 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 23 Jul 2025 07:30:55 GMT
Subject: RFR: 8359827: Test runtime/Thread/ThreadCountLimit.java should run
 exclusively [v8]
In-Reply-To: <Zyi8B9UHcUeZORddfEGvYzV03Rp3xL97dMw9cu7RxfA=.c28feabe-5a1c-4574-885e-836639413ecf@github.com>
References: <KFZNv5pVvr7Rddlm5xifJz6VzPzlFkmO7XPXrdJGWHw=.0664dc6c-992a-473d-b974-b2c40e06f45b@github.com>
 <Zyi8B9UHcUeZORddfEGvYzV03Rp3xL97dMw9cu7RxfA=.c28feabe-5a1c-4574-885e-836639413ecf@github.com>
Message-ID: <Ei8HdH3KpITU-fuOdKFazb7rZy2EyV67eu7KiXB9BXc=.a06893a1-5526-4f70-8f6c-36478d394bc4@github.com>

On Wed, 23 Jul 2025 02:39:44 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> The test runtime/Thread/ThreadCountLimit.java was observed fails when run with other tests. The test start subprocess with [shell prefix command](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/Thread/ThreadCountLimit.java#L82) `ulimit -u 4096` which intend to limite the usage of thread number. But this will cause test fails when this test run with other tests. I create a demo to demonstrate that.
>> 
>> I start a java process which will create 5k threads, and then I can not start new java process with prefix `ulimit -u 4096` on the same machine.
>> 
>> <img width="1573" height="182" alt="image" src="https://github.com/user-attachments/assets/8dd53ade-cad7-4a2f-b5d9-d4b2d200b728" />
>> 
>> 
>> [ManyThreads.java.txt](https://github.com/user-attachments/files/21324354/ManyThreads.java.txt)
>> 
>> So it's necessary to make this test run sperately to make this test success.
>> Change has been verified locally, test-fix only, risk is low.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert change to TEST.groups

Testing in our CI was fine - test passes on first iteration with 4096 in all case. I ran this standalone and within tier5.

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

PR Comment: https://git.openjdk.org/jdk/pull/26401#issuecomment-3106263202

From mbaesken at openjdk.org  Wed Jul 23 07:52:02 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 23 Jul 2025 07:52:02 GMT
Subject: RFR: 8360941: [ubsan] MemRegion::end() shows runtime error:
 applying non-zero offset 8388608 to null pointer [v8]
In-Reply-To: <OxUVocYa0ZKGd55UmlMmfzO1QAKm9S2HxTWULDSZF5s=.750a3d6b-2e1a-4a7c-8bf9-c2a7504761ff@github.com>
References: <LP6FbAxZpwbGf6lkNvLcSRSEOu-mYKjWGAJYBSIMcyk=.775595dc-7f73-4248-a235-f4b58933396b@github.com>
 <OxUVocYa0ZKGd55UmlMmfzO1QAKm9S2HxTWULDSZF5s=.750a3d6b-2e1a-4a7c-8bf9-c2a7504761ff@github.com>
Message-ID: <24t_XvQKJGQ9nHMR2YkZzuliFWAe-iVrEn0_YFPhoaM=.c28302e6-0e82-4699-93db-a22aae4d2b93@github.com>

On Tue, 22 Jul 2025 14:16:40 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When running HS test
>> gtest/GTestWrapper.java
>> with ubsan-enabled binaries on macOS aarch64, the following error is reported (did not see this so far on Linux but there we use gcc and it seems the gcc/ubsan checks are a bit more limited).
>> 
>> test/hotspot/gtest/gc/g1/test_freeRegionList.cpp:37: Failure
>> Death test: child_G1FreeRegionList_length_()
>>     Result: died but not with expected exit code:
>>             Terminated by signal 6 (core dumped)
>> Actual msg:
>> 
>> [  DEATH   ] /jdk/src/hotspot/share/memory/memRegion.hpp:66:43: runtime error: applying non-zero offset 8388608 to null pointer
>> [  DEATH   ]     #0 0x108afd6f4 in MemRegion::end() const+0x84 (libjvm.dylib:arm64+0x16556f4)
>> [  DEATH   ]     #1 0x1075c68a0 in G1FreeRegionList_length_other_vm_Test::TestBody()+0x380 (libjvm.dylib:arm64+0x11e8a0)
>> [  DEATH   ]     #2 0x1090f3bb0 in testing::Test::Run()+0xc0 (libjvm.dylib:arm64+0x1c4bbb0)
>> [  DEATH   ]     #3 0x1090f4d94 in testing::TestInfo::Run()+0x1e4 (libjvm.dylib:arm64+0x1c4cd94)
>> [  DEATH   ]     #4 0x1090f6754 in testing::TestSuite::Run()+0x43c (libjvm.dylib:arm64+0x1c4e754)
>> [  DEATH   ]     #5 0x109103ca0 in testing::internal::UnitTestImpl::RunAllTests()+0x48c (libjvm.dylib:arm64+0x1c5bca0)
>> [  DEATH   ]     #6 0x109103588 in testing::UnitTest::Run()+0x78 (libjvm.dylib:arm64+0x1c5b588)
>> [  DEATH   ]     #7 0x1074a9ac0 in runUnitTestsInner(int, char**)+0x724 (libjvm.dylib:arm64+0x1ac0)
>> [  DEATH   ]     #8 0x102dc3f18 in main+0x2c (gtestLauncher:arm64+0x100003f18)
>> [  DEATH   ]     #9 0x196fea0dc  (<unknown module>)
>> [  DEATH   ] 
>> [  DEATH   ] SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /jdk/src/hotspot/share/memory/memRegion.hpp:66:43 in 
>> [  DEATH   ] 
>> 
>> 
>> 
>> Seems the test_freeRegionList.cpp uses a special MemRegion starting at nullptr ; but this causes a bit of trouble when adding to start == nullptr .
>> So far I see this issue just in the gtest, seems other MemRegion objects do not start at nullptr .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust alignment and freeing

Thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/26216#issuecomment-3106329538

From mbaesken at openjdk.org  Wed Jul 23 07:52:02 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 23 Jul 2025 07:52:02 GMT
Subject: Integrated: 8360941: [ubsan] MemRegion::end() shows runtime error:
 applying non-zero offset 8388608 to null pointer
In-Reply-To: <LP6FbAxZpwbGf6lkNvLcSRSEOu-mYKjWGAJYBSIMcyk=.775595dc-7f73-4248-a235-f4b58933396b@github.com>
References: <LP6FbAxZpwbGf6lkNvLcSRSEOu-mYKjWGAJYBSIMcyk=.775595dc-7f73-4248-a235-f4b58933396b@github.com>
Message-ID: <0OOraeQ2JhuwmcqlOEXpWFJqcdBmzEiry7ZJVdXfBwk=.ed11d8c7-6f43-418e-a3c8-cf02d0b73fc9@github.com>

On Wed, 9 Jul 2025 10:36:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running HS test
> gtest/GTestWrapper.java
> with ubsan-enabled binaries on macOS aarch64, the following error is reported (did not see this so far on Linux but there we use gcc and it seems the gcc/ubsan checks are a bit more limited).
> 
> test/hotspot/gtest/gc/g1/test_freeRegionList.cpp:37: Failure
> Death test: child_G1FreeRegionList_length_()
>     Result: died but not with expected exit code:
>             Terminated by signal 6 (core dumped)
> Actual msg:
> 
> [  DEATH   ] /jdk/src/hotspot/share/memory/memRegion.hpp:66:43: runtime error: applying non-zero offset 8388608 to null pointer
> [  DEATH   ]     #0 0x108afd6f4 in MemRegion::end() const+0x84 (libjvm.dylib:arm64+0x16556f4)
> [  DEATH   ]     #1 0x1075c68a0 in G1FreeRegionList_length_other_vm_Test::TestBody()+0x380 (libjvm.dylib:arm64+0x11e8a0)
> [  DEATH   ]     #2 0x1090f3bb0 in testing::Test::Run()+0xc0 (libjvm.dylib:arm64+0x1c4bbb0)
> [  DEATH   ]     #3 0x1090f4d94 in testing::TestInfo::Run()+0x1e4 (libjvm.dylib:arm64+0x1c4cd94)
> [  DEATH   ]     #4 0x1090f6754 in testing::TestSuite::Run()+0x43c (libjvm.dylib:arm64+0x1c4e754)
> [  DEATH   ]     #5 0x109103ca0 in testing::internal::UnitTestImpl::RunAllTests()+0x48c (libjvm.dylib:arm64+0x1c5bca0)
> [  DEATH   ]     #6 0x109103588 in testing::UnitTest::Run()+0x78 (libjvm.dylib:arm64+0x1c5b588)
> [  DEATH   ]     #7 0x1074a9ac0 in runUnitTestsInner(int, char**)+0x724 (libjvm.dylib:arm64+0x1ac0)
> [  DEATH   ]     #8 0x102dc3f18 in main+0x2c (gtestLauncher:arm64+0x100003f18)
> [  DEATH   ]     #9 0x196fea0dc  (<unknown module>)
> [  DEATH   ] 
> [  DEATH   ] SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /jdk/src/hotspot/share/memory/memRegion.hpp:66:43 in 
> [  DEATH   ] 
> 
> 
> 
> Seems the test_freeRegionList.cpp uses a special MemRegion starting at nullptr ; but this causes a bit of trouble when adding to start == nullptr .
> So far I see this issue just in the gtest, seems other MemRegion objects do not start at nullptr .

This pull request has now been integrated.

Changeset: ceb0c0fc
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ceb0c0fc39c17793d13fff74e69f22ef07ec2c0f
Stats:     5 lines in 1 file changed: 4 ins; 0 del; 1 mod

8360941: [ubsan] MemRegion::end() shows runtime error: applying non-zero offset 8388608 to null pointer

Co-authored-by: Kim Barrett <kbarrett at openjdk.org>
Co-authored-by: Thomas Stuefe <stuefe at openjdk.org>
Reviewed-by: kbarrett, lucy

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

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

From stuefe at openjdk.org  Wed Jul 23 09:09:06 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 23 Jul 2025 09:09:06 GMT
Subject: RFR: 8362591: Wrong argument warning when heap size larger than coops
 threshold
Message-ID: <EBH4T75t0B_m3jpZrC7ftSdG3oAV6IPQhxNxdFNhjZs=.1b433232-27bb-47dd-bac5-693000e412ad@github.com>

Trivial fix to an argument warning that was incorrect. UseCompressedClassPointers has long been separated from UseCompressedOops (since JDK 15).

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

Commit messages:
 - also fix test
 - JDK-8362591-Wrong-argument-warning-when-heap-size-larger-than-coops-threshold

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

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

From mchevalier at openjdk.org  Wed Jul 23 10:12:08 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Wed, 23 Jul 2025 10:12:08 GMT
Subject: RFR: 8363357: Remove unused flag VerifyAdapterCalls
Message-ID: <nHDpuCVhFLd6SBqz0LT14ImgzKCasIR7psK1vBlDQZA=.84a456d2-1b97-4cb1-81f2-359a3a7a2f21@github.com>

It seems that the flag VerifyAdapterCalls is unused since [JDK-8350209](https://bugs.openjdk.org/browse/JDK-8350209), so pretty recently.

Let's remove it, very direct, no trick.

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

Commit messages:
 - Remove VerifyAdapterCalls

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

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

From snatarajan at openjdk.org  Wed Jul 23 11:05:56 2025
From: snatarajan at openjdk.org (Saranya Natarajan)
Date: Wed, 23 Jul 2025 11:05:56 GMT
Subject: RFR: 8358696: Assert with extreme values for -XX:BciProfileWidth
 [v3]
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: <t0g_2qf8mM1WgH6IiRgQwPWz7pQ7tcjUvz7vO7iLlqs=.4c0898c3-6197-4e41-b28e-d3f24d703155@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:

  fixing test failures due to intx -> int of BciProfileWidth

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26139/files
  - new: https://git.openjdk.org/jdk/pull/26139/files/a32b6ead..c3a85cd4

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

  Stats: 6 lines in 5 files changed: 0 ins; 2 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 syan at openjdk.org  Wed Jul 23 11:37:54 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 23 Jul 2025 11:37:54 GMT
Subject: RFR: 8359827: Test runtime/Thread/ThreadCountLimit.java should run
 exclusively [v8]
In-Reply-To: <Zyi8B9UHcUeZORddfEGvYzV03Rp3xL97dMw9cu7RxfA=.c28feabe-5a1c-4574-885e-836639413ecf@github.com>
References: <KFZNv5pVvr7Rddlm5xifJz6VzPzlFkmO7XPXrdJGWHw=.0664dc6c-992a-473d-b974-b2c40e06f45b@github.com>
 <Zyi8B9UHcUeZORddfEGvYzV03Rp3xL97dMw9cu7RxfA=.c28feabe-5a1c-4574-885e-836639413ecf@github.com>
Message-ID: <VOnz7M0dD1IRrgiN-WjjjI4uFVN_DABdAmDly6IY4nE=.6acbd84d-fe08-4f36-9860-15e306954483@github.com>

On Wed, 23 Jul 2025 02:39:44 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> The test runtime/Thread/ThreadCountLimit.java was observed fails when run with other tests. The test start subprocess with [shell prefix command](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/Thread/ThreadCountLimit.java#L82) `ulimit -u 4096` which intend to limite the usage of thread number. But this will cause test fails when this test run with other tests. I create a demo to demonstrate that.
>> 
>> I start a java process which will create 5k threads, and then I can not start new java process with prefix `ulimit -u 4096` on the same machine.
>> 
>> <img width="1573" height="182" alt="image" src="https://github.com/user-attachments/assets/8dd53ade-cad7-4a2f-b5d9-d4b2d200b728" />
>> 
>> 
>> [ManyThreads.java.txt](https://github.com/user-attachments/files/21324354/ManyThreads.java.txt)
>> 
>> So it's necessary to make this test run sperately to make this test success.
>> Change has been verified locally, test-fix only, risk is low.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert change to TEST.groups

Testing in our CI was fine - test passes on third iteration with 12288 in all case.

[ThreadCountLimit_id0.jtr.txt](https://github.com/user-attachments/files/21386820/ThreadCountLimit_id0.jtr.txt)

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

PR Comment: https://git.openjdk.org/jdk/pull/26401#issuecomment-3107333362

From chagedorn at openjdk.org  Wed Jul 23 12:07:53 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 23 Jul 2025 12:07:53 GMT
Subject: RFR: 8363357: Remove unused flag VerifyAdapterCalls
In-Reply-To: <nHDpuCVhFLd6SBqz0LT14ImgzKCasIR7psK1vBlDQZA=.84a456d2-1b97-4cb1-81f2-359a3a7a2f21@github.com>
References: <nHDpuCVhFLd6SBqz0LT14ImgzKCasIR7psK1vBlDQZA=.84a456d2-1b97-4cb1-81f2-359a3a7a2f21@github.com>
Message-ID: <WwqRpfYjXlWclfa-GQYRpcW1j_kXlDgeHVGi4Ap5bFA=.b060a4ae-3ec6-48be-b202-b9b3cd5a43c9@github.com>

On Wed, 23 Jul 2025 07:46:58 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> It seems that the flag VerifyAdapterCalls is unused since [JDK-8350209](https://bugs.openjdk.org/browse/JDK-8350209), so pretty recently.
> 
> Let's remove it, very direct, no trick.

Looks good!

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

Marked as reviewed by chagedorn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26440#pullrequestreview-3047071545

From myankelevich at openjdk.org  Wed Jul 23 13:01:58 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Wed, 23 Jul 2025 13:01:58 GMT
Subject: RFR: 8358696: Assert with extreme values for -XX:BciProfileWidth
 [v3]
In-Reply-To: <t0g_2qf8mM1WgH6IiRgQwPWz7pQ7tcjUvz7vO7iLlqs=.4c0898c3-6197-4e41-b28e-d3f24d703155@github.com>
References: <5TRVeAXUQi6quM-nDWEij_jk6M5K2Vk31RA-Yjd8F2M=.5b63da45-93c3-4251-9e2e-3c64b7953919@github.com>
 <t0g_2qf8mM1WgH6IiRgQwPWz7pQ7tcjUvz7vO7iLlqs=.4c0898c3-6197-4e41-b28e-d3f24d703155@github.com>
Message-ID: <U5XDKNbFt1lrBCeXrYosdcHz-Gg9PjFbCayLJDtaKr0=.d42da0c4-0a89-483c-bee4-f188e5777976@github.com>

On Wed, 23 Jul 2025 11:05:56 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:
> 
>   fixing test failures due to intx -> int of BciProfileWidth

test/lib-test/jdk/test/whitebox/vm_flags/IntxTest.java line 36:

> 34:  * @author igor.ignatyev at oracle.com
> 35:  */
> 36: import jdk.test.lib.Platform;

NIt: copyright date

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26139#discussion_r2225524788

From snatarajan at openjdk.org  Wed Jul 23 15:18:39 2025
From: snatarajan at openjdk.org (Saranya Natarajan)
Date: Wed, 23 Jul 2025 15:18:39 GMT
Subject: RFR: 8358696: Assert with extreme values for -XX:BciProfileWidth
 [v4]
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: <_preMnRE0tqL476Pb8bPPfkixInRa-ZH5Qom7W70AW4=.a71e36da-d0e1-44e4-a3fe-9091460b813f@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:

  fixing copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26139/files
  - new: https://git.openjdk.org/jdk/pull/26139/files/c3a85cd4..2d0084ba

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

  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 Jul 23 15:18:39 2025
From: snatarajan at openjdk.org (Saranya Natarajan)
Date: Wed, 23 Jul 2025 15:18:39 GMT
Subject: RFR: 8358696: Assert with extreme values for -XX:BciProfileWidth
 [v4]
In-Reply-To: <-UlWQi6Pf7UwQKUR8sL4_Rhoj9MEd8UMlH7naG_W7QM=.d8947291-df9e-40e8-8007-4438c6c490c3@github.com>
References: <5TRVeAXUQi6quM-nDWEij_jk6M5K2Vk31RA-Yjd8F2M=.5b63da45-93c3-4251-9e2e-3c64b7953919@github.com>
 <yVAjK7XL8NcTFAW8ukoMZJTv51sGlYPMI3dlE86MfbE=.39b08654-7480-4255-ac68-b0a353e9dc5f@github.com>
 <-UlWQi6Pf7UwQKUR8sL4_Rhoj9MEd8UMlH7naG_W7QM=.d8947291-df9e-40e8-8007-4438c6c490c3@github.com>
Message-ID: <wWT7UNEsRXUIg97Dp1wS93reUHAiWTU23cJIxTddY-A=.6c3960fa-d3c3-4af9-8676-12d270bf7633@github.com>

On Tue, 22 Jul 2025 12:59:35 GMT, Saranya Natarajan <snatarajan at openjdk.org> wrote:

>> src/hotspot/share/runtime/globals.hpp line 1354:
>> 
>>> 1352:           range(0, 8)                                                       \
>>> 1353:                                                                             \
>>> 1354:   develop(intx, BciProfileWidth, 2,                                         \
>> 
>> Recently, I've seen someone complaining about useless use of `intx`, saying that is brings less readability than a more fixed-width type when not needed. Here, [0, 5000] fits in 16 bits (even signed). One could change that into a simple `int` or something like that.
>
> Since `int` seems to fit the range. I have changed `intx` to `int `. Currently, fixing some test failures. I will address the failures in next commit.

I have now resolved the failing test cases.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26139#discussion_r2225921554

From dholmes at openjdk.org  Wed Jul 23 21:37:54 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 23 Jul 2025 21:37:54 GMT
Subject: RFR: 8359827: Test runtime/Thread/ThreadCountLimit.java need loop
 increasing the limit [v8]
In-Reply-To: <Zyi8B9UHcUeZORddfEGvYzV03Rp3xL97dMw9cu7RxfA=.c28feabe-5a1c-4574-885e-836639413ecf@github.com>
References: <KFZNv5pVvr7Rddlm5xifJz6VzPzlFkmO7XPXrdJGWHw=.0664dc6c-992a-473d-b974-b2c40e06f45b@github.com>
 <Zyi8B9UHcUeZORddfEGvYzV03Rp3xL97dMw9cu7RxfA=.c28feabe-5a1c-4574-885e-836639413ecf@github.com>
Message-ID: <yCBAYlXA2ou6I48FsuEB9k69w1JrGYfHcyLqFgWjIyY=.b05afb84-1ffd-48d0-ada7-1769ccd9a5e9@github.com>

On Wed, 23 Jul 2025 02:39:44 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> The test runtime/Thread/ThreadCountLimit.java was observed fails when run with other tests. The test start subprocess with [shell prefix command](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/Thread/ThreadCountLimit.java#L82) `ulimit -u 4096` which intend to limite the usage of thread number. But this will cause test fails when this test run with other tests. I create a demo to demonstrate that.
>> 
>> I start a java process which will create 5k threads, and then I can not start new java process with prefix `ulimit -u 4096` on the same machine.
>> 
>> <img width="1573" height="182" alt="image" src="https://github.com/user-attachments/assets/8dd53ade-cad7-4a2f-b5d9-d4b2d200b728" />
>> 
>> 
>> [ManyThreads.java.txt](https://github.com/user-attachments/files/21324354/ManyThreads.java.txt)
>> 
>> So it's necessary to make this test run sperately to make this test success.
>> Change has been verified locally, test-fix only, risk is low.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert change to TEST.groups

Marked as reviewed by dholmes (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26401#pullrequestreview-3049127774

From dholmes at openjdk.org  Thu Jul 24 01:25:58 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 24 Jul 2025 01:25:58 GMT
Subject: RFR: 8362591: Wrong argument warning when heap size larger than
 coops threshold
In-Reply-To: <EBH4T75t0B_m3jpZrC7ftSdG3oAV6IPQhxNxdFNhjZs=.1b433232-27bb-47dd-bac5-693000e412ad@github.com>
References: <EBH4T75t0B_m3jpZrC7ftSdG3oAV6IPQhxNxdFNhjZs=.1b433232-27bb-47dd-bac5-693000e412ad@github.com>
Message-ID: <_MIi3-wAET1Kr7IlamJ9JICYnQdcsRDNv4Qzw0XiVEs=.2062d509-7686-466e-8704-c0287c3dcc3c@github.com>

On Wed, 23 Jul 2025 04:39:26 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Trivial fix to an argument warning that was incorrect. UseCompressedClassPointers has long been separated from UseCompressedOops (since JDK 15).

Looks good and trivial.

`UseCompressedClassPointers` is being obsoleted in 26 anyway.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26439#pullrequestreview-3049615151

From syan at openjdk.org  Thu Jul 24 01:51:00 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 24 Jul 2025 01:51:00 GMT
Subject: RFR: 8359827: Test runtime/Thread/ThreadCountLimit.java need loop
 increasing the limit [v8]
In-Reply-To: <Ei8HdH3KpITU-fuOdKFazb7rZy2EyV67eu7KiXB9BXc=.a06893a1-5526-4f70-8f6c-36478d394bc4@github.com>
References: <KFZNv5pVvr7Rddlm5xifJz6VzPzlFkmO7XPXrdJGWHw=.0664dc6c-992a-473d-b974-b2c40e06f45b@github.com>
 <Zyi8B9UHcUeZORddfEGvYzV03Rp3xL97dMw9cu7RxfA=.c28feabe-5a1c-4574-885e-836639413ecf@github.com>
 <Ei8HdH3KpITU-fuOdKFazb7rZy2EyV67eu7KiXB9BXc=.a06893a1-5526-4f70-8f6c-36478d394bc4@github.com>
Message-ID: <HsYTXAVwMfopUnhAsC98GAqNIewr2n_4T-YC9nhNeyg=.9f16eeed-4213-4caa-9bb5-9ace23521805@github.com>

On Wed, 23 Jul 2025 07:28:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert change to TEST.groups
>
> Testing in our CI was fine - test passes on first iteration with 4096 in all case. I ran this standalone and within tier5.

Thanks your patient reviews and suggestions @dholmes-ora.

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

PR Comment: https://git.openjdk.org/jdk/pull/26401#issuecomment-3111673894

From syan at openjdk.org  Thu Jul 24 01:51:01 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 24 Jul 2025 01:51:01 GMT
Subject: Integrated: 8359827: Test runtime/Thread/ThreadCountLimit.java need
 loop increasing the limit
In-Reply-To: <KFZNv5pVvr7Rddlm5xifJz6VzPzlFkmO7XPXrdJGWHw=.0664dc6c-992a-473d-b974-b2c40e06f45b@github.com>
References: <KFZNv5pVvr7Rddlm5xifJz6VzPzlFkmO7XPXrdJGWHw=.0664dc6c-992a-473d-b974-b2c40e06f45b@github.com>
Message-ID: <ByY9Bhsx5cXP2IGF5f5b5craeGGxnEuuUfSWB6BATqk=.51164017-32db-40b9-b80e-0301ddfd8ff1@github.com>

On Sat, 19 Jul 2025 02:08:59 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> The test runtime/Thread/ThreadCountLimit.java was observed fails when run with other tests. The test start subprocess with [shell prefix command](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/Thread/ThreadCountLimit.java#L82) `ulimit -u 4096` which intend to limite the usage of thread number. But this will cause test fails when this test run with other tests. I create a demo to demonstrate that.
> 
> I start a java process which will create 5k threads, and then I can not start new java process with prefix `ulimit -u 4096` on the same machine.
> 
> <img width="1573" height="182" alt="image" src="https://github.com/user-attachments/assets/8dd53ade-cad7-4a2f-b5d9-d4b2d200b728" />
> 
> 
> [ManyThreads.java.txt](https://github.com/user-attachments/files/21324354/ManyThreads.java.txt)
> 
> So it's necessary to make this test run sperately to make this test success.
> Change has been verified locally, test-fix only, risk is low.

This pull request has now been integrated.

Changeset: fc803844
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fc8038441daebc717fedaeb107e37bf216d542d3
Stats:     20 lines in 1 file changed: 13 ins; 0 del; 7 mod

8359827: Test runtime/Thread/ThreadCountLimit.java need loop increasing the limit

Co-authored-by: David Holmes <dholmes at openjdk.org>
Reviewed-by: dholmes

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

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

From stuefe at openjdk.org  Thu Jul 24 05:12:06 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 24 Jul 2025 05:12:06 GMT
Subject: RFR: 8362591: Wrong argument warning when heap size larger than
 coops threshold
In-Reply-To: <EBH4T75t0B_m3jpZrC7ftSdG3oAV6IPQhxNxdFNhjZs=.1b433232-27bb-47dd-bac5-693000e412ad@github.com>
References: <EBH4T75t0B_m3jpZrC7ftSdG3oAV6IPQhxNxdFNhjZs=.1b433232-27bb-47dd-bac5-693000e412ad@github.com>
Message-ID: <NcNGTSOv4MLjxyxACNbkMdL2s1C36Jj2HDy0heTv0SI=.3853a0d8-563c-4e3c-93e3-438b2714058b@github.com>

On Wed, 23 Jul 2025 04:39:26 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Trivial fix to an argument warning that was incorrect. UseCompressedClassPointers has long been separated from UseCompressedOops (since JDK 15).

Thanks David!

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

PR Comment: https://git.openjdk.org/jdk/pull/26439#issuecomment-3111978687

From stuefe at openjdk.org  Thu Jul 24 05:12:06 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 24 Jul 2025 05:12:06 GMT
Subject: Integrated: 8362591: Wrong argument warning when heap size larger than
 coops threshold
In-Reply-To: <EBH4T75t0B_m3jpZrC7ftSdG3oAV6IPQhxNxdFNhjZs=.1b433232-27bb-47dd-bac5-693000e412ad@github.com>
References: <EBH4T75t0B_m3jpZrC7ftSdG3oAV6IPQhxNxdFNhjZs=.1b433232-27bb-47dd-bac5-693000e412ad@github.com>
Message-ID: <EeDljZYYpKH6YwTxNpBqqiMmI843ZYz3oiTs1rnKGHs=.972fa790-e491-475d-81ae-0db8c8721154@github.com>

On Wed, 23 Jul 2025 04:39:26 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Trivial fix to an argument warning that was incorrect. UseCompressedClassPointers has long been separated from UseCompressedOops (since JDK 15).

This pull request has now been integrated.

Changeset: 7a22b76b
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7a22b76b73e6a6906f191e59b7d2da238b401935
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8362591: Wrong argument warning when heap size larger than coops threshold

Reviewed-by: dholmes

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

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

From dholmes at openjdk.org  Thu Jul 24 06:46:05 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 24 Jul 2025 06:46:05 GMT
Subject: RFR: 8359827: Test runtime/Thread/ThreadCountLimit.java need loop
 increasing the limit [v8]
In-Reply-To: <HsYTXAVwMfopUnhAsC98GAqNIewr2n_4T-YC9nhNeyg=.9f16eeed-4213-4caa-9bb5-9ace23521805@github.com>
References: <KFZNv5pVvr7Rddlm5xifJz6VzPzlFkmO7XPXrdJGWHw=.0664dc6c-992a-473d-b974-b2c40e06f45b@github.com>
 <Zyi8B9UHcUeZORddfEGvYzV03Rp3xL97dMw9cu7RxfA=.c28feabe-5a1c-4574-885e-836639413ecf@github.com>
 <Ei8HdH3KpITU-fuOdKFazb7rZy2EyV67eu7KiXB9BXc=.a06893a1-5526-4f70-8f6c-36478d394bc4@github.com>
 <HsYTXAVwMfopUnhAsC98GAqNIewr2n_4T-YC9nhNeyg=.9f16eeed-4213-4caa-9bb5-9ace23521805@github.com>
Message-ID: <jFZDJOGrfLJxL-cO7lbdCHZZEHM-0Upza8T0UVwrM5A=.02556187-847e-4a8c-a02a-b6b4ee067eed@github.com>

On Thu, 24 Jul 2025 01:47:00 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Testing in our CI was fine - test passes on first iteration with 4096 in all case. I ran this standalone and within tier5.
>
> Thanks your patient reviews and suggestions @dholmes-ora.

@sendaoYan any hotspot related changes, including tests, require two reviews before integration.

It is probably prudent to wait for any feedback from other CI maintainers before backporting this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/26401#issuecomment-3112242318

From dfenacci at openjdk.org  Thu Jul 24 07:12:55 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Thu, 24 Jul 2025 07:12:55 GMT
Subject: RFR: 8358696: Assert with extreme values for -XX:BciProfileWidth
 [v4]
In-Reply-To: <_preMnRE0tqL476Pb8bPPfkixInRa-ZH5Qom7W70AW4=.a71e36da-d0e1-44e4-a3fe-9091460b813f@github.com>
References: <5TRVeAXUQi6quM-nDWEij_jk6M5K2Vk31RA-Yjd8F2M=.5b63da45-93c3-4251-9e2e-3c64b7953919@github.com>
 <_preMnRE0tqL476Pb8bPPfkixInRa-ZH5Qom7W70AW4=.a71e36da-d0e1-44e4-a3fe-9091460b813f@github.com>
Message-ID: <51aYnCiXel-vz4Zu40K08E1lyBtX5JXD8PXoCr5wWUE=.15def8e4-f7c3-42ae-976e-f79ed7415bfa@github.com>

On Wed, 23 Jul 2025 15:18:39 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:
> 
>   fixing copyright

Thanks for fixing this @sarannat. I left a couple of inline comments.

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?

test/lib-test/jdk/test/whitebox/vm_flags/IntxTest.java line 39:

> 37: public class IntxTest {
> 38:     private static final String FLAG_NAME = "OnStackReplacePercentage";
> 39:     private static final String FLAG_DEBUG_NAME = "BciProfileWidth";

Maybe we might want use another `intx` flag instead of just removing this (just to keep testing the WhiteBox)

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

PR Review: https://git.openjdk.org/jdk/pull/26139#pullrequestreview-3050359574
PR Review Comment: https://git.openjdk.org/jdk/pull/26139#discussion_r2227627961
PR Review Comment: https://git.openjdk.org/jdk/pull/26139#discussion_r2227611611

From syan at openjdk.org  Thu Jul 24 07:29:03 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 24 Jul 2025 07:29:03 GMT
Subject: RFR: 8359827: Test runtime/Thread/ThreadCountLimit.java need loop
 increasing the limit [v8]
In-Reply-To: <HsYTXAVwMfopUnhAsC98GAqNIewr2n_4T-YC9nhNeyg=.9f16eeed-4213-4caa-9bb5-9ace23521805@github.com>
References: <KFZNv5pVvr7Rddlm5xifJz6VzPzlFkmO7XPXrdJGWHw=.0664dc6c-992a-473d-b974-b2c40e06f45b@github.com>
 <Zyi8B9UHcUeZORddfEGvYzV03Rp3xL97dMw9cu7RxfA=.c28feabe-5a1c-4574-885e-836639413ecf@github.com>
 <Ei8HdH3KpITU-fuOdKFazb7rZy2EyV67eu7KiXB9BXc=.a06893a1-5526-4f70-8f6c-36478d394bc4@github.com>
 <HsYTXAVwMfopUnhAsC98GAqNIewr2n_4T-YC9nhNeyg=.9f16eeed-4213-4caa-9bb5-9ace23521805@github.com>
Message-ID: <kwqQvC-iV5QB4Q1ng4TRB65md1ahIqGGsCAQBoZlCLk=.695b52fe-d5cf-45a4-8496-a805f9c2fad8@github.com>

On Thu, 24 Jul 2025 01:47:00 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Testing in our CI was fine - test passes on first iteration with 4096 in all case. I ran this standalone and within tier5.
>
> Thanks your patient reviews and suggestions @dholmes-ora.

> @sendaoYan any hotspot related changes, including tests, require two reviews before integration.
> 
> It is probably prudent to wait for any feedback from other CI maintainers before backporting this change.

Sorry, I will pay attention next time.

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

PR Comment: https://git.openjdk.org/jdk/pull/26401#issuecomment-3112350967

From thartmann at openjdk.org  Thu Jul 24 09:03:05 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 24 Jul 2025 09:03:05 GMT
Subject: RFR: 8363357: Remove unused flag VerifyAdapterCalls
In-Reply-To: <nHDpuCVhFLd6SBqz0LT14ImgzKCasIR7psK1vBlDQZA=.84a456d2-1b97-4cb1-81f2-359a3a7a2f21@github.com>
References: <nHDpuCVhFLd6SBqz0LT14ImgzKCasIR7psK1vBlDQZA=.84a456d2-1b97-4cb1-81f2-359a3a7a2f21@github.com>
Message-ID: <NDvsnyDFDIqSmTDh92-h6bo2EwAlqbS4SIlzpoGpiQ8=.910f9a7a-2262-4502-b5d0-e36adafb862f@github.com>

On Wed, 23 Jul 2025 07:46:58 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> It seems that the flag VerifyAdapterCalls is unused since [JDK-8350209](https://bugs.openjdk.org/browse/JDK-8350209), so pretty recently.
> 
> Let's remove it, very direct, no trick.

Looks good to me too.

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

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26440#pullrequestreview-3050754843

From mchevalier at openjdk.org  Thu Jul 24 09:25:00 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Thu, 24 Jul 2025 09:25:00 GMT
Subject: RFR: 8363357: Remove unused flag VerifyAdapterCalls
In-Reply-To: <nHDpuCVhFLd6SBqz0LT14ImgzKCasIR7psK1vBlDQZA=.84a456d2-1b97-4cb1-81f2-359a3a7a2f21@github.com>
References: <nHDpuCVhFLd6SBqz0LT14ImgzKCasIR7psK1vBlDQZA=.84a456d2-1b97-4cb1-81f2-359a3a7a2f21@github.com>
Message-ID: <YCgWb_tHADBmy3InhDrSrP5M1nimEfBjLC_GVFkHMjI=.4e77e2b6-d2dc-466f-9b84-b65897f9bf64@github.com>

On Wed, 23 Jul 2025 07:46:58 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> It seems that the flag VerifyAdapterCalls is unused since [JDK-8350209](https://bugs.openjdk.org/browse/JDK-8350209), so pretty recently.
> 
> Let's remove it, very direct, no trick.

Thanks @chhagedorn & @TobiHartmann!

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

PR Comment: https://git.openjdk.org/jdk/pull/26440#issuecomment-3112717716

From mchevalier at openjdk.org  Thu Jul 24 09:25:00 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Thu, 24 Jul 2025 09:25:00 GMT
Subject: Integrated: 8363357: Remove unused flag VerifyAdapterCalls
In-Reply-To: <nHDpuCVhFLd6SBqz0LT14ImgzKCasIR7psK1vBlDQZA=.84a456d2-1b97-4cb1-81f2-359a3a7a2f21@github.com>
References: <nHDpuCVhFLd6SBqz0LT14ImgzKCasIR7psK1vBlDQZA=.84a456d2-1b97-4cb1-81f2-359a3a7a2f21@github.com>
Message-ID: <qLzshJIj5EMQUfnuk47vRED9xnNnvqCLkHT5D7bD_W0=.f09f70b1-e71e-4d31-869e-497c07eac815@github.com>

On Wed, 23 Jul 2025 07:46:58 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> It seems that the flag VerifyAdapterCalls is unused since [JDK-8350209](https://bugs.openjdk.org/browse/JDK-8350209), so pretty recently.
> 
> Let's remove it, very direct, no trick.

This pull request has now been integrated.

Changeset: 67e93281
Author:    Marc Chevalier <mchevalier at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/67e93281a4f9e76419f1d6e05099ecf2214ebbfd
Stats:     3 lines in 1 file changed: 0 ins; 3 del; 0 mod

8363357: Remove unused flag VerifyAdapterCalls

Reviewed-by: chagedorn, thartmann

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

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

From ayang at openjdk.org  Thu Jul 24 10:13:21 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 24 Jul 2025 10:13:21 GMT
Subject: RFR: 8364019: Add alignment precondition to Universe::reserve_heap
Message-ID: <zn5eMLyIaYJS2ooP8Os28aLCk_t8ZaDhxPGF6PLw7Qo=.b720b417-1433-493c-9ccf-1246e0dbd15e@github.com>

Simple converting a redundant `align_up` to assert.

Test: tier1

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

Commit messages:
 - heap-align-precondition

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

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

From stuefe at openjdk.org  Thu Jul 24 11:43:04 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 24 Jul 2025 11:43:04 GMT
Subject: RFR: 8320836: jtreg gtest runs should limit heap size
Message-ID: <McyuDqLADkEVaJaWV-YpFvW9goHSkaa9_8yitcby2XM=.cf23f454-e2fb-42a3-be17-84f92319933a@github.com>

Trivial fix to limit Java heap size when running the gtests. Otherwise, we run with an unknown malloc load (since GC structures, preallocated, may be very large), and not all tests like that.

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

Commit messages:
 - start

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

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

From cslucas at openjdk.org  Thu Jul 24 20:12:53 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Thu, 24 Jul 2025 20:12:53 GMT
Subject: RFR: 8320836: jtreg gtest runs should limit heap size
In-Reply-To: <McyuDqLADkEVaJaWV-YpFvW9goHSkaa9_8yitcby2XM=.cf23f454-e2fb-42a3-be17-84f92319933a@github.com>
References: <McyuDqLADkEVaJaWV-YpFvW9goHSkaa9_8yitcby2XM=.cf23f454-e2fb-42a3-be17-84f92319933a@github.com>
Message-ID: <i7YBTKZGeH7CFPlYfFZ1E7ZmZEb2Gnfid-Xc1-6CJkE=.d1bd0fa6-ae59-4ccf-889a-cd3715844d79@github.com>

On Thu, 24 Jul 2025 08:17:12 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Trivial fix to limit Java heap size when running the gtests. Otherwise, we run with an unknown malloc load (since GC structures, preallocated, may be very large), and not all tests like that.

LGTM. Thanks for fixing.

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

Marked as reviewed by cslucas (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26454#pullrequestreview-3053128599

From syan at openjdk.org  Fri Jul 25 02:42:01 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 25 Jul 2025 02:42:01 GMT
Subject: RFR: 8362501: Update
 test/hotspot/jtreg/applications/jcstress/README [v2]
In-Reply-To: <_OAL4RIUkuwkPCOPg9arhmB71sz4xwkSsPuKzBVnLzo=.dc5503ee-2acf-4a03-b36d-e34c57b03d61@github.com>
References: <Gv-CfzN4MbQDSvKMkXs6DWllE9saxTpkjIh92W8GkK4=.04b9e256-42cb-48de-a8e0-2345cdbc8b78@github.com>
 <_OAL4RIUkuwkPCOPg9arhmB71sz4xwkSsPuKzBVnLzo=.dc5503ee-2acf-4a03-b36d-e34c57b03d61@github.com>
Message-ID: <3X1UByQ02sqRhdMrrzLVzIIDbIC9p4H5Tr2QDGPdKMo=.45121642-5715-44ab-9911-1745459def1f@github.com>

On Fri, 18 Jul 2025 06:31:37 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Currently, this is no documentation on how to run the application/jcstress tests. I think it will be useful to complement the document test/hotspot/jtreg/applications/jcstress/README on how to run the jcstress tests in jtreg.
>> 
>> No behaviour has been change, only update the ducumentation, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update README

Hi @dholmes-ora ,can you review this PR again. The PR has been updated according your suggestions.

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

PR Comment: https://git.openjdk.org/jdk/pull/26369#issuecomment-3116190954

From syan at openjdk.org  Fri Jul 25 03:01:04 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 25 Jul 2025 03:01:04 GMT
Subject: RFR: 8320836: jtreg gtest runs should limit heap size
In-Reply-To: <McyuDqLADkEVaJaWV-YpFvW9goHSkaa9_8yitcby2XM=.cf23f454-e2fb-42a3-be17-84f92319933a@github.com>
References: <McyuDqLADkEVaJaWV-YpFvW9goHSkaa9_8yitcby2XM=.cf23f454-e2fb-42a3-be17-84f92319933a@github.com>
Message-ID: <3FPFUGu8EPVic2ug45SGXLXnnXA2NlDK59sz6lPgyIo=.81d5081c-d43b-4499-b680-c5baad348613@github.com>

On Thu, 24 Jul 2025 08:17:12 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Trivial fix to limit Java heap size when running the gtests. Otherwise, we run with an unknown malloc load (since GC structures, preallocated, may be very large), and not all tests like that.

test/hotspot/jtreg/gtest/GTestWrapper.java line 85:

> 83:         command.add("-jdk");
> 84:         command.add(Utils.TEST_JDK);
> 85:         command.add("-Xmx200m");

Should we need to update the copyright year.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26454#discussion_r2230032065

From dholmes at openjdk.org  Fri Jul 25 05:00:54 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 25 Jul 2025 05:00:54 GMT
Subject: RFR: 8320836: jtreg gtest runs should limit heap size
In-Reply-To: <3FPFUGu8EPVic2ug45SGXLXnnXA2NlDK59sz6lPgyIo=.81d5081c-d43b-4499-b680-c5baad348613@github.com>
References: <McyuDqLADkEVaJaWV-YpFvW9goHSkaa9_8yitcby2XM=.cf23f454-e2fb-42a3-be17-84f92319933a@github.com>
 <3FPFUGu8EPVic2ug45SGXLXnnXA2NlDK59sz6lPgyIo=.81d5081c-d43b-4499-b680-c5baad348613@github.com>
Message-ID: <jDBiodrvh9NpTB-Q62h-H6Y-6x2d39gQxxrDuCdJp4g=.aa09dd1a-026e-4f4f-9bd9-d129c6729fa4@github.com>

On Fri, 25 Jul 2025 02:57:57 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Trivial fix to limit Java heap size when running the gtests. Otherwise, we run with an unknown malloc load (since GC structures, preallocated, may be very large), and not all tests like that.
>
> test/hotspot/jtreg/gtest/GTestWrapper.java line 85:
> 
>> 83:         command.add("-jdk");
>> 84:         command.add(Utils.TEST_JDK);
>> 85:         command.add("-Xmx200m");
> 
> Should we need to update the copyright year.

Yes please

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26454#discussion_r2230135568

From dholmes at openjdk.org  Fri Jul 25 05:00:53 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 25 Jul 2025 05:00:53 GMT
Subject: RFR: 8320836: jtreg gtest runs should limit heap size
In-Reply-To: <McyuDqLADkEVaJaWV-YpFvW9goHSkaa9_8yitcby2XM=.cf23f454-e2fb-42a3-be17-84f92319933a@github.com>
References: <McyuDqLADkEVaJaWV-YpFvW9goHSkaa9_8yitcby2XM=.cf23f454-e2fb-42a3-be17-84f92319933a@github.com>
Message-ID: <sCeXAA0wB3IWquZFc09veoUHf3yAX3FRvdVAtrZh2vw=.45c7ed96-f79c-4ca0-83fe-a070d693242b@github.com>

On Thu, 24 Jul 2025 08:17:12 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Trivial fix to limit Java heap size when running the gtests. Otherwise, we run with an unknown malloc load (since GC structures, preallocated, may be very large), and not all tests like that.

Seems okay. Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26454#pullrequestreview-3054080369

From stuefe at openjdk.org  Fri Jul 25 05:07:42 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 25 Jul 2025 05:07:42 GMT
Subject: RFR: 8320836: jtreg gtest runs should limit heap size [v2]
In-Reply-To: <McyuDqLADkEVaJaWV-YpFvW9goHSkaa9_8yitcby2XM=.cf23f454-e2fb-42a3-be17-84f92319933a@github.com>
References: <McyuDqLADkEVaJaWV-YpFvW9goHSkaa9_8yitcby2XM=.cf23f454-e2fb-42a3-be17-84f92319933a@github.com>
Message-ID: <XYOGbTyiYSVeY8ldUtQuMDEViRyxXsZ5M1-20C6goDI=.7c57bd4f-c9e7-41df-b089-2eb2c1cadcba@github.com>

> Trivial fix to limit Java heap size when running the gtests. Otherwise, we run with an unknown malloc load (since GC structures, preallocated, may be very large), and not all tests like that.

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

  copyrights

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26454/files
  - new: https://git.openjdk.org/jdk/pull/26454/files/65ae1a5c..9d3ab31f

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

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

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

From dholmes at openjdk.org  Fri Jul 25 05:14:02 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 25 Jul 2025 05:14:02 GMT
Subject: RFR: 8320836: jtreg gtest runs should limit heap size [v2]
In-Reply-To: <XYOGbTyiYSVeY8ldUtQuMDEViRyxXsZ5M1-20C6goDI=.7c57bd4f-c9e7-41df-b089-2eb2c1cadcba@github.com>
References: <McyuDqLADkEVaJaWV-YpFvW9goHSkaa9_8yitcby2XM=.cf23f454-e2fb-42a3-be17-84f92319933a@github.com>
 <XYOGbTyiYSVeY8ldUtQuMDEViRyxXsZ5M1-20C6goDI=.7c57bd4f-c9e7-41df-b089-2eb2c1cadcba@github.com>
Message-ID: <B4EpbnW3fp-hDOXSdmZcgkgot-3uZmiD73xeTzPe9Fg=.f5f6718a-25d2-4c4d-b807-43025e68627c@github.com>

On Fri, 25 Jul 2025 05:07:42 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Trivial fix to limit Java heap size when running the gtests. Otherwise, we run with an unknown malloc load (since GC structures, preallocated, may be very large), and not all tests like that.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyrights

Marked as reviewed by dholmes (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26454#pullrequestreview-3054103202

From stuefe at openjdk.org  Fri Jul 25 05:14:03 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 25 Jul 2025 05:14:03 GMT
Subject: RFR: 8320836: jtreg gtest runs should limit heap size [v2]
In-Reply-To: <i7YBTKZGeH7CFPlYfFZ1E7ZmZEb2Gnfid-Xc1-6CJkE=.d1bd0fa6-ae59-4ccf-889a-cd3715844d79@github.com>
References: <McyuDqLADkEVaJaWV-YpFvW9goHSkaa9_8yitcby2XM=.cf23f454-e2fb-42a3-be17-84f92319933a@github.com>
 <i7YBTKZGeH7CFPlYfFZ1E7ZmZEb2Gnfid-Xc1-6CJkE=.d1bd0fa6-ae59-4ccf-889a-cd3715844d79@github.com>
Message-ID: <jQR8gyOBpRrTYOZZZ0bvBnqxj-lHG0WBxsBS3-90XI8=.ca8749bd-16aa-4073-999c-1ec36c8f9358@github.com>

On Thu, 24 Jul 2025 20:10:21 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   copyrights
>
> LGTM. Thanks for fixing.

@JohnTortugo @dholmes-ora I fixed the copyright, could one of you re-review, please?

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

PR Comment: https://git.openjdk.org/jdk/pull/26454#issuecomment-3116413358

From dholmes at openjdk.org  Fri Jul 25 05:29:53 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 25 Jul 2025 05:29:53 GMT
Subject: RFR: 8362501: Update
 test/hotspot/jtreg/applications/jcstress/README [v2]
In-Reply-To: <_OAL4RIUkuwkPCOPg9arhmB71sz4xwkSsPuKzBVnLzo=.dc5503ee-2acf-4a03-b36d-e34c57b03d61@github.com>
References: <Gv-CfzN4MbQDSvKMkXs6DWllE9saxTpkjIh92W8GkK4=.04b9e256-42cb-48de-a8e0-2345cdbc8b78@github.com>
 <_OAL4RIUkuwkPCOPg9arhmB71sz4xwkSsPuKzBVnLzo=.dc5503ee-2acf-4a03-b36d-e34c57b03d61@github.com>
Message-ID: <IaF3SoFbgcA8GCTuW14uUriIn3Os2U7Ep9L7tLpeH1Q=.8bc954be-f639-4f5a-b341-4dc2a8dbb223@github.com>

On Fri, 18 Jul 2025 06:31:37 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Currently, this is no documentation on how to run the application/jcstress tests. I think it will be useful to complement the document test/hotspot/jtreg/applications/jcstress/README on how to run the jcstress tests in jtreg.
>> 
>> No behaviour has been change, only update the ducumentation, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update README

Grammatical updates look fine - one further one flagged. I can't review as such as I can't validate the instructions being given as I don't know how to run these tests.

Maybe @lmesnik could review?

Or @shipilev may be able to review?

test/hotspot/jtreg/applications/jcstress/README line 35:

> 33: You should specific the JAR location with jtreg option such as
> 34: -javaoption:-Djdk.test.lib.artifacts.jcstress-tests-all=
> 35: jcstress-tests-all-20241217-2035.jar when start jcstress tests in jtreg.

Suggestion:

jcstress-tests-all-20241217-2035.jar when starting jcstress tests in jtreg.

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

PR Review: https://git.openjdk.org/jdk/pull/26369#pullrequestreview-3054121280
PR Comment: https://git.openjdk.org/jdk/pull/26369#issuecomment-3116446288
PR Review Comment: https://git.openjdk.org/jdk/pull/26369#discussion_r2230168069

From stuefe at openjdk.org  Fri Jul 25 06:42:59 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 25 Jul 2025 06:42:59 GMT
Subject: RFR: 8320836: jtreg gtest runs should limit heap size [v2]
In-Reply-To: <XYOGbTyiYSVeY8ldUtQuMDEViRyxXsZ5M1-20C6goDI=.7c57bd4f-c9e7-41df-b089-2eb2c1cadcba@github.com>
References: <McyuDqLADkEVaJaWV-YpFvW9goHSkaa9_8yitcby2XM=.cf23f454-e2fb-42a3-be17-84f92319933a@github.com>
 <XYOGbTyiYSVeY8ldUtQuMDEViRyxXsZ5M1-20C6goDI=.7c57bd4f-c9e7-41df-b089-2eb2c1cadcba@github.com>
Message-ID: <UV6FavKodbQ5gXr-gXBgZfZsQRKwYituh4f4jZ1VtN0=.5f043714-4872-4306-af19-45df46b68ae5@github.com>

On Fri, 25 Jul 2025 05:07:42 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Trivial fix to limit Java heap size when running the gtests. Otherwise, we run with an unknown malloc load (since GC structures, preallocated, may be very large), and not all tests like that.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyrights

Thanks David

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

PR Comment: https://git.openjdk.org/jdk/pull/26454#issuecomment-3116589265

From stuefe at openjdk.org  Fri Jul 25 06:43:00 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 25 Jul 2025 06:43:00 GMT
Subject: Integrated: 8320836: jtreg gtest runs should limit heap size
In-Reply-To: <McyuDqLADkEVaJaWV-YpFvW9goHSkaa9_8yitcby2XM=.cf23f454-e2fb-42a3-be17-84f92319933a@github.com>
References: <McyuDqLADkEVaJaWV-YpFvW9goHSkaa9_8yitcby2XM=.cf23f454-e2fb-42a3-be17-84f92319933a@github.com>
Message-ID: <Ud-gffXc_9WkVloTnkA49mvL40irl4wzbvTqqpWiOto=.1f84fde6-430d-4801-a69e-ca57791fa472@github.com>

On Thu, 24 Jul 2025 08:17:12 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Trivial fix to limit Java heap size when running the gtests. Otherwise, we run with an unknown malloc load (since GC structures, preallocated, may be very large), and not all tests like that.

This pull request has now been integrated.

Changeset: ac9e5102
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ac9e51023fc34a82b795950a109af2397826adaa
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8320836: jtreg gtest runs should limit heap size

Reviewed-by: dholmes, cslucas

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

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

From syan at openjdk.org  Fri Jul 25 07:24:37 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 25 Jul 2025 07:24:37 GMT
Subject: RFR: 8362501: Update
 test/hotspot/jtreg/applications/jcstress/README [v3]
In-Reply-To: <Gv-CfzN4MbQDSvKMkXs6DWllE9saxTpkjIh92W8GkK4=.04b9e256-42cb-48de-a8e0-2345cdbc8b78@github.com>
References: <Gv-CfzN4MbQDSvKMkXs6DWllE9saxTpkjIh92W8GkK4=.04b9e256-42cb-48de-a8e0-2345cdbc8b78@github.com>
Message-ID: <awU_2V_VRc0snMUfhOLBBPfEcQ92P8YaP9BnDFs9Bhg=.155f95e7-9e83-4cc5-808e-404e2a068043@github.com>

> Hi all,
> 
> Currently, this is no documentation on how to run the application/jcstress tests. I think it will be useful to complement the document test/hotspot/jtreg/applications/jcstress/README on how to run the jcstress tests in jtreg.
> 
> No behaviour has been change, only update the ducumentation, no risk.

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

  Use starting instead of start
  
  Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26369/files
  - new: https://git.openjdk.org/jdk/pull/26369/files/d024994c..716b97c4

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

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

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

From syan at openjdk.org  Fri Jul 25 07:24:38 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 25 Jul 2025 07:24:38 GMT
Subject: RFR: 8362501: Update
 test/hotspot/jtreg/applications/jcstress/README [v2]
In-Reply-To: <IaF3SoFbgcA8GCTuW14uUriIn3Os2U7Ep9L7tLpeH1Q=.8bc954be-f639-4f5a-b341-4dc2a8dbb223@github.com>
References: <Gv-CfzN4MbQDSvKMkXs6DWllE9saxTpkjIh92W8GkK4=.04b9e256-42cb-48de-a8e0-2345cdbc8b78@github.com>
 <_OAL4RIUkuwkPCOPg9arhmB71sz4xwkSsPuKzBVnLzo=.dc5503ee-2acf-4a03-b36d-e34c57b03d61@github.com>
 <IaF3SoFbgcA8GCTuW14uUriIn3Os2U7Ep9L7tLpeH1Q=.8bc954be-f639-4f5a-b341-4dc2a8dbb223@github.com>
Message-ID: <OtzIm_JVgKMPQQmJJBnS2QVNo5GM8PEvXvdrY_Hl6HA=.6f615996-e774-4da8-8478-bbcd98d08388@github.com>

On Fri, 25 Jul 2025 05:25:46 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update README
>
> test/hotspot/jtreg/applications/jcstress/README line 35:
> 
>> 33: You should specific the JAR location with jtreg option such as
>> 34: -javaoption:-Djdk.test.lib.artifacts.jcstress-tests-all=
>> 35: jcstress-tests-all-20241217-2035.jar when start jcstress tests in jtreg.
> 
> Suggestion:
> 
> jcstress-tests-all-20241217-2035.jar when starting jcstress tests in jtreg.

Thanks, applied.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26369#discussion_r2230357577

From snatarajan at openjdk.org  Fri Jul 25 09:01:12 2025
From: snatarajan at openjdk.org (Saranya Natarajan)
Date: Fri, 25 Jul 2025 09:01:12 GMT
Subject: RFR: 8358696: Assert with extreme values for -XX:BciProfileWidth
 [v5]
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: <FZb5ohOjJiGESfNXhIPs_xAaZ2BSnCY0NTVojzDgdYg=.d016aa21-8990-4998-b7e7-cd27abcb29ce@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 comment by adding intx flag

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26139/files
  - new: https://git.openjdk.org/jdk/pull/26139/files/2d0084ba..2fc4b0b7

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

  Stats: 2 lines in 1 file changed: 2 ins; 0 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  Fri Jul 25 09:15:57 2025
From: snatarajan at openjdk.org (Saranya Natarajan)
Date: Fri, 25 Jul 2025 09:15:57 GMT
Subject: RFR: 8358696: Assert with extreme values for -XX:BciProfileWidth
 [v4]
In-Reply-To: <51aYnCiXel-vz4Zu40K08E1lyBtX5JXD8PXoCr5wWUE=.15def8e4-f7c3-42ae-976e-f79ed7415bfa@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>
Message-ID: <AcIJdrrh4s5bDfif6nem9K_Ib3Fo-XoOo89dXB-DFGM=.5707af03-fcea-4ce5-86d5-26ef5090585a@github.com>

On Thu, 24 Jul 2025 07:08:24 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> Saranya Natarajan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixing copyright
>
> 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 ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26139#discussion_r2230592823

From snatarajan at openjdk.org  Fri Jul 25 09:15:59 2025
From: snatarajan at openjdk.org (Saranya Natarajan)
Date: Fri, 25 Jul 2025 09:15:59 GMT
Subject: RFR: 8358696: Assert with extreme values for -XX:BciProfileWidth
 [v5]
In-Reply-To: <51aYnCiXel-vz4Zu40K08E1lyBtX5JXD8PXoCr5wWUE=.15def8e4-f7c3-42ae-976e-f79ed7415bfa@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>
Message-ID: <na8MapNns180-Ne6qayPLVzkvX1qKEJQJVffH8Z1mPk=.f0b10244-dbc3-4c1c-b420-28b968a1e16b@github.com>

On Thu, 24 Jul 2025 06:59:52 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> Saranya Natarajan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   addressing review comment by adding intx flag
>
> test/lib-test/jdk/test/whitebox/vm_flags/IntxTest.java line 39:
> 
>> 37: public class IntxTest {
>> 38:     private static final String FLAG_NAME = "OnStackReplacePercentage";
>> 39:     private static final String FLAG_DEBUG_NAME = "BciProfileWidth";
> 
> Maybe we might want use another `intx` flag instead of just removing this (just to keep testing the WhiteBox)

I addressed this comment by adding `BinarySwitchThreshold` intx develop flag now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26139#discussion_r2230595014

From shade at openjdk.org  Fri Jul 25 09:44:54 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 25 Jul 2025 09:44:54 GMT
Subject: RFR: 8362501: Update
 test/hotspot/jtreg/applications/jcstress/README [v2]
In-Reply-To: <IaF3SoFbgcA8GCTuW14uUriIn3Os2U7Ep9L7tLpeH1Q=.8bc954be-f639-4f5a-b341-4dc2a8dbb223@github.com>
References: <Gv-CfzN4MbQDSvKMkXs6DWllE9saxTpkjIh92W8GkK4=.04b9e256-42cb-48de-a8e0-2345cdbc8b78@github.com>
 <_OAL4RIUkuwkPCOPg9arhmB71sz4xwkSsPuKzBVnLzo=.dc5503ee-2acf-4a03-b36d-e34c57b03d61@github.com>
 <IaF3SoFbgcA8GCTuW14uUriIn3Os2U7Ep9L7tLpeH1Q=.8bc954be-f639-4f5a-b341-4dc2a8dbb223@github.com>
Message-ID: <jmuye4qB2P1v8S55uQa52CGv5HKf6LWKocIvRXU_Hi8=.daa603a8-b2f2-4531-95ba-fac5df754b4b@github.com>

On Fri, 25 Jul 2025 05:27:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Or @shipilev may be able to review?

(slowly turns in his home office chair and stares curiously at his home server that produces jcstress binaries). Meh, I am on the fence on referencing 3rd party personal websites like mine. So I would defer to others if they are good with it.

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

PR Comment: https://git.openjdk.org/jdk/pull/26369#issuecomment-3117094407

From syan at openjdk.org  Fri Jul 25 10:42:55 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 25 Jul 2025 10:42:55 GMT
Subject: RFR: 8362501: Update
 test/hotspot/jtreg/applications/jcstress/README [v2]
In-Reply-To: <jmuye4qB2P1v8S55uQa52CGv5HKf6LWKocIvRXU_Hi8=.daa603a8-b2f2-4531-95ba-fac5df754b4b@github.com>
References: <Gv-CfzN4MbQDSvKMkXs6DWllE9saxTpkjIh92W8GkK4=.04b9e256-42cb-48de-a8e0-2345cdbc8b78@github.com>
 <_OAL4RIUkuwkPCOPg9arhmB71sz4xwkSsPuKzBVnLzo=.dc5503ee-2acf-4a03-b36d-e34c57b03d61@github.com>
 <IaF3SoFbgcA8GCTuW14uUriIn3Os2U7Ep9L7tLpeH1Q=.8bc954be-f639-4f5a-b341-4dc2a8dbb223@github.com>
 <jmuye4qB2P1v8S55uQa52CGv5HKf6LWKocIvRXU_Hi8=.daa603a8-b2f2-4531-95ba-fac5df754b4b@github.com>
Message-ID: <lZ-riksGwe4MGVLuz-hqnTz9-cvT4O6nQyAQr0m0n8U=.eee477b2-b0a6-4d53-b934-58b9d6d946ad@github.com>

On Fri, 25 Jul 2025 09:39:15 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > Or @shipilev may be able to review?
> 
> (slowly turns in his home office chair and stares curiously at his home server that produces jcstress binaries). Meh, I am on the fence on referencing 3rd party personal websites like mine. So I would defer to others if they are good with it.

The README.md in jcstress repo has already [referenced ](https://github.com/openjdk/jcstress/blob/master/README.md?plain=1#L24)your website~

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

PR Comment: https://git.openjdk.org/jdk/pull/26369#issuecomment-3117265969

From syan at openjdk.org  Fri Jul 25 12:57:34 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 25 Jul 2025 12:57:34 GMT
Subject: RFR: 8364114: Test TestHugePageDecisionsAtVMStartup.java#LP_enabled
 fails when no free hugepage
Message-ID: <xtrPwb4mg-gGCOXQwlYiGYC7F8iirF_trNYiDE9176E=.77ea0256-847b-4c9b-99bd-9f8fb0a753a2@github.com>

Hi all,

The test runtime/os/TestHugePageDecisionsAtVMStartup.java#LP_enabled will fails when there is no free hugepases.
The /proc/meminfo and /sys/kernel/mm/hugepages/hugepages-*/free_hugepages says there is no free hugepage, and the JVM output also say there is available large page.


> cat /proc/meminfo | grep -i HugePages
AnonHugePages:         0 kB
ShmemHugePages:        0 kB
FileHugePages:         0 kB
HugePages_Total:       2
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        2
Hugepagesize:       2048 kB

> ( set -x ; cat /sys/kernel/mm/hugepages/hugepages-*/free_hugepages )
+ cat /sys/kernel/mm/hugepages/hugepages-1048576kB/free_hugepages /sys/kernel/mm/hugepages/hugepages-2048kB/free_hugepages
0
0

JVM output snippet from java -XX:+UseLargePages -Xlog:pagesize -version
[0.001s][info][pagesize] Large page size (2M) failed sanity check, checking if smaller large page sizes are usable
[0.001s][warning][pagesize] UseLargePages disabled, no large pages configured and available on the system.


The JVM can not use large page when there is no available large, it's not a JVM bug. So I think it's not suitable to report test failure, but report SkippedException.

Change has been verified locally, test report SkippedException on the system without free hugepage, the test passes on the system with free hugepage. Test-fix only, risk is low.

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

Commit messages:
 - 8364114: Test TestHugePageDecisionsAtVMStartup.java#LP_enabled fails when no free hugepage

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

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

From stuefe at openjdk.org  Fri Jul 25 13:50:57 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 25 Jul 2025 13:50:57 GMT
Subject: RFR: 8364114: Test
 TestHugePageDecisionsAtVMStartup.java#LP_enabled fails when no free hugepage
In-Reply-To: <xtrPwb4mg-gGCOXQwlYiGYC7F8iirF_trNYiDE9176E=.77ea0256-847b-4c9b-99bd-9f8fb0a753a2@github.com>
References: <xtrPwb4mg-gGCOXQwlYiGYC7F8iirF_trNYiDE9176E=.77ea0256-847b-4c9b-99bd-9f8fb0a753a2@github.com>
Message-ID: <y1l1FYU7O15FTbY-xLxie-4R4w1L7B6PPeVIG4_fWLw=.39405b53-accc-4535-ab9c-be2510c6adc2@github.com>

On Fri, 25 Jul 2025 12:47:23 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> The test runtime/os/TestHugePageDecisionsAtVMStartup.java#LP_enabled will fails when there is no free hugepases.
> The /proc/meminfo and /sys/kernel/mm/hugepages/hugepages-*/free_hugepages says there is no free hugepage, and the JVM output also say there is available large page.
> 
> 
>> cat /proc/meminfo | grep -i HugePages
> AnonHugePages:         0 kB
> ShmemHugePages:        0 kB
> FileHugePages:         0 kB
> HugePages_Total:       2
> HugePages_Free:        0
> HugePages_Rsvd:        0
> HugePages_Surp:        2
> Hugepagesize:       2048 kB
> 
>> ( set -x ; cat /sys/kernel/mm/hugepages/hugepages-*/free_hugepages )
> + cat /sys/kernel/mm/hugepages/hugepages-1048576kB/free_hugepages /sys/kernel/mm/hugepages/hugepages-2048kB/free_hugepages
> 0
> 0
> 
> JVM output snippet from java -XX:+UseLargePages -Xlog:pagesize -version
> [0.001s][info][pagesize] Large page size (2M) failed sanity check, checking if smaller large page sizes are usable
> [0.001s][warning][pagesize] UseLargePages disabled, no large pages configured and available on the system.
> 
> 
> The JVM can not use large page when there is no available large page on system, it's not a JVM bug. So I think it's not suitable to report test failure, but report SkippedException.
> 
> Change has been verified locally, test report SkippedException on the system without free hugepage, the test passes on the system with free hugepage. Test-fix only, risk is low.

Thanks for fixing this.

Side note, I was long on the fence about just throwing that JVM-side startup test out. Since it seems superfluous - without the test, we would just proceed allocating the heap, not get the desired large pages, which would produce almost the same result. And it is no guarantee anyway, since we may pass the test and later fail to allocate the much larger heap.

test/hotspot/jtreg/runtime/os/TestHugePageDecisionsAtVMStartup.java line 32:

> 30:  * @modules java.base/jdk.internal.misc
> 31:  *          java.management
> 32:  * @build jtreg.SkippedException

I don't think these should be needed, should they?

test/lib/jdk/test/lib/os/linux/HugePageConfiguration.java line 186:

> 184:         return 0;
> 185:     }
> 186: 

Can you do it a bit more like the rest of the class - read this info in readFromOS and store it in a member? Print it with toString()? Then we see it in the test output, could be useful. But it cannot be part of the equals() comparison, I think, since there is no direct counterpart on the JVM-side log.

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

Changes requested by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26480#pullrequestreview-3055450911
PR Review Comment: https://git.openjdk.org/jdk/pull/26480#discussion_r2231116545
PR Review Comment: https://git.openjdk.org/jdk/pull/26480#discussion_r2231127605

From syan at openjdk.org  Sat Jul 26 03:33:35 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 26 Jul 2025 03:33:35 GMT
Subject: RFR: 8364114: Test
 TestHugePageDecisionsAtVMStartup.java#LP_enabled fails when no free hugepage
 [v2]
In-Reply-To: <xtrPwb4mg-gGCOXQwlYiGYC7F8iirF_trNYiDE9176E=.77ea0256-847b-4c9b-99bd-9f8fb0a753a2@github.com>
References: <xtrPwb4mg-gGCOXQwlYiGYC7F8iirF_trNYiDE9176E=.77ea0256-847b-4c9b-99bd-9f8fb0a753a2@github.com>
Message-ID: <MvCb6MeLbLSIjpd33_8rLvKN0MmqcKmoDIFgGubbtSQ=.0d061855-3cbe-45c6-863f-759089470bfe@github.com>

> Hi all,
> 
> The test runtime/os/TestHugePageDecisionsAtVMStartup.java#LP_enabled will fails when there is no free hugepases.
> The /proc/meminfo and /sys/kernel/mm/hugepages/hugepages-*/free_hugepages says there is no free hugepage, and the JVM output also say there is available large page.
> 
> 
>> cat /proc/meminfo | grep -i HugePages
> AnonHugePages:         0 kB
> ShmemHugePages:        0 kB
> FileHugePages:         0 kB
> HugePages_Total:       2
> HugePages_Free:        0
> HugePages_Rsvd:        0
> HugePages_Surp:        2
> Hugepagesize:       2048 kB
> 
>> ( set -x ; cat /sys/kernel/mm/hugepages/hugepages-*/free_hugepages )
> + cat /sys/kernel/mm/hugepages/hugepages-1048576kB/free_hugepages /sys/kernel/mm/hugepages/hugepages-2048kB/free_hugepages
> 0
> 0
> 
> JVM output snippet from java -XX:+UseLargePages -Xlog:pagesize -version
> [0.001s][info][pagesize] Large page size (2M) failed sanity check, checking if smaller large page sizes are usable
> [0.001s][warning][pagesize] UseLargePages disabled, no large pages configured and available on the system.
> 
> 
> The JVM can not use large page when there is no available large page on system, it's not a JVM bug. So I think it's not suitable to report test failure, but report SkippedException.
> 
> Change has been verified locally, test report SkippedException on the system without free hugepage, the test passes on the system with free hugepage. Test-fix only, risk is low.

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  Remove @build jtreg.SkippedException

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26480/files
  - new: https://git.openjdk.org/jdk/pull/26480/files/52bbdd9a..b2c096fa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26480&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26480&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26480.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26480/head:pull/26480

PR: https://git.openjdk.org/jdk/pull/26480

From syan at openjdk.org  Sat Jul 26 03:33:35 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 26 Jul 2025 03:33:35 GMT
Subject: RFR: 8364114: Test
 TestHugePageDecisionsAtVMStartup.java#LP_enabled fails when no free hugepage
 [v2]
In-Reply-To: <y1l1FYU7O15FTbY-xLxie-4R4w1L7B6PPeVIG4_fWLw=.39405b53-accc-4535-ab9c-be2510c6adc2@github.com>
References: <xtrPwb4mg-gGCOXQwlYiGYC7F8iirF_trNYiDE9176E=.77ea0256-847b-4c9b-99bd-9f8fb0a753a2@github.com>
 <y1l1FYU7O15FTbY-xLxie-4R4w1L7B6PPeVIG4_fWLw=.39405b53-accc-4535-ab9c-be2510c6adc2@github.com>
Message-ID: <r26ZxfX-fpRHnM1rvKYppvALmCCsrx6H0HRqHCAFHYQ=.604aa535-2bd7-4f6f-8b8c-29b0c80116fd@github.com>

On Fri, 25 Jul 2025 13:39:58 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove @build jtreg.SkippedException
>
> test/hotspot/jtreg/runtime/os/TestHugePageDecisionsAtVMStartup.java line 32:
> 
>> 30:  * @modules java.base/jdk.internal.misc
>> 31:  *          java.management
>> 32:  * @build jtreg.SkippedException
> 
> I don't think these should be needed, should they?

jtreg will build the class jtreg.SkippedException autimaticly, remove this directive will be okey. PR has been updated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26480#discussion_r2232460501

From syan at openjdk.org  Sat Jul 26 04:33:20 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 26 Jul 2025 04:33:20 GMT
Subject: RFR: 8364114: Test
 TestHugePageDecisionsAtVMStartup.java#LP_enabled fails when no free hugepage
 [v3]
In-Reply-To: <xtrPwb4mg-gGCOXQwlYiGYC7F8iirF_trNYiDE9176E=.77ea0256-847b-4c9b-99bd-9f8fb0a753a2@github.com>
References: <xtrPwb4mg-gGCOXQwlYiGYC7F8iirF_trNYiDE9176E=.77ea0256-847b-4c9b-99bd-9f8fb0a753a2@github.com>
Message-ID: <IBkZBr0sB3LgmV9OIn-viQ5ew8KGgHQsWQF5KUqBFHQ=.59448274-1dfa-4152-bd6e-bc0832d033c8@github.com>

> Hi all,
> 
> The test runtime/os/TestHugePageDecisionsAtVMStartup.java#LP_enabled will fails when there is no free hugepases.
> The /proc/meminfo and /sys/kernel/mm/hugepages/hugepages-*/free_hugepages says there is no free hugepage, and the JVM output also say there is available large page.
> 
> 
>> cat /proc/meminfo | grep -i HugePages
> AnonHugePages:         0 kB
> ShmemHugePages:        0 kB
> FileHugePages:         0 kB
> HugePages_Total:       2
> HugePages_Free:        0
> HugePages_Rsvd:        0
> HugePages_Surp:        2
> Hugepagesize:       2048 kB
> 
>> ( set -x ; cat /sys/kernel/mm/hugepages/hugepages-*/free_hugepages )
> + cat /sys/kernel/mm/hugepages/hugepages-1048576kB/free_hugepages /sys/kernel/mm/hugepages/hugepages-2048kB/free_hugepages
> 0
> 0
> 
> JVM output snippet from java -XX:+UseLargePages -Xlog:pagesize -version
> [0.001s][info][pagesize] Large page size (2M) failed sanity check, checking if smaller large page sizes are usable
> [0.001s][warning][pagesize] UseLargePages disabled, no large pages configured and available on the system.
> 
> 
> The JVM can not use large page when there is no available large page on system, it's not a JVM bug. So I think it's not suitable to report test failure, but report SkippedException.
> 
> Change has been verified locally, test report SkippedException on the system without free hugepage, the test passes on the system with free hugepage. Test-fix only, risk is low.

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  Make explicitAvailableHugePageNumber as a member of HugePageConfiguration

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26480/files
  - new: https://git.openjdk.org/jdk/pull/26480/files/b2c096fa..4e0c9a7a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26480&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26480&range=01-02

  Stats: 14 lines in 2 files changed: 10 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/26480.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26480/head:pull/26480

PR: https://git.openjdk.org/jdk/pull/26480

From syan at openjdk.org  Sat Jul 26 04:33:20 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 26 Jul 2025 04:33:20 GMT
Subject: RFR: 8364114: Test
 TestHugePageDecisionsAtVMStartup.java#LP_enabled fails when no free hugepage
 [v3]
In-Reply-To: <y1l1FYU7O15FTbY-xLxie-4R4w1L7B6PPeVIG4_fWLw=.39405b53-accc-4535-ab9c-be2510c6adc2@github.com>
References: <xtrPwb4mg-gGCOXQwlYiGYC7F8iirF_trNYiDE9176E=.77ea0256-847b-4c9b-99bd-9f8fb0a753a2@github.com>
 <y1l1FYU7O15FTbY-xLxie-4R4w1L7B6PPeVIG4_fWLw=.39405b53-accc-4535-ab9c-be2510c6adc2@github.com>
Message-ID: <_KFTBoj4UqoSP49Qe8Gva-ZvjMGG2kynvNazKCANnis=.db12d387-e318-4f14-98ab-6ef414ad7f70@github.com>

On Fri, 25 Jul 2025 13:44:53 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make explicitAvailableHugePageNumber as a member of HugePageConfiguration
>
> test/lib/jdk/test/lib/os/linux/HugePageConfiguration.java line 186:
> 
>> 184:         return 0;
>> 185:     }
>> 186: 
> 
> Can you do it a bit more like the rest of the class - read this info in readFromOS and store it in a member? Print it with toString()? Then we see it in the test output, could be useful. But it cannot be part of the equals() comparison, I think, since there is no direct counterpart on the JVM-side log.

PR has been updated as 'Make explicitAvailableHugePageNumber as a member of HugePageConfiguration'

The tests test/hotspot/jtreg/runtime/os/TestHugePageDetection.java test/hotspot/jtreg/runtime/os/TestHugePageDecisionsAtVMStartup.java test/hotspot/jtreg/runtime/os/THPsInThreadStackPreventionTest.java test/hotspot/jtreg/gc/z/TestAllocateHeapAt.java has been verified locally.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26480#discussion_r2232548981

From stuefe at openjdk.org  Sat Jul 26 04:52:03 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 26 Jul 2025 04:52:03 GMT
Subject: RFR: 8364114: Test
 TestHugePageDecisionsAtVMStartup.java#LP_enabled fails when no free hugepage
 [v3]
In-Reply-To: <IBkZBr0sB3LgmV9OIn-viQ5ew8KGgHQsWQF5KUqBFHQ=.59448274-1dfa-4152-bd6e-bc0832d033c8@github.com>
References: <xtrPwb4mg-gGCOXQwlYiGYC7F8iirF_trNYiDE9176E=.77ea0256-847b-4c9b-99bd-9f8fb0a753a2@github.com>
 <IBkZBr0sB3LgmV9OIn-viQ5ew8KGgHQsWQF5KUqBFHQ=.59448274-1dfa-4152-bd6e-bc0832d033c8@github.com>
Message-ID: <SzZ8l2FGhoDN6ceAHJXqJTtKxQG8f-ED7rxDxFCxEVs=.b31562d7-2a63-4db8-9750-5351a3b9863c@github.com>

On Sat, 26 Jul 2025 04:33:20 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> The test runtime/os/TestHugePageDecisionsAtVMStartup.java#LP_enabled will fails when there is no free hugepases.
>> The /proc/meminfo and /sys/kernel/mm/hugepages/hugepages-*/free_hugepages says there is no free hugepage, and the JVM output also say there is available large page.
>> 
>> 
>>> cat /proc/meminfo | grep -i HugePages
>> AnonHugePages:         0 kB
>> ShmemHugePages:        0 kB
>> FileHugePages:         0 kB
>> HugePages_Total:       2
>> HugePages_Free:        0
>> HugePages_Rsvd:        0
>> HugePages_Surp:        2
>> Hugepagesize:       2048 kB
>> 
>>> ( set -x ; cat /sys/kernel/mm/hugepages/hugepages-*/free_hugepages )
>> + cat /sys/kernel/mm/hugepages/hugepages-1048576kB/free_hugepages /sys/kernel/mm/hugepages/hugepages-2048kB/free_hugepages
>> 0
>> 0
>> 
>> JVM output snippet from java -XX:+UseLargePages -Xlog:pagesize -version
>> [0.001s][info][pagesize] Large page size (2M) failed sanity check, checking if smaller large page sizes are usable
>> [0.001s][warning][pagesize] UseLargePages disabled, no large pages configured and available on the system.
>> 
>> 
>> The JVM can not use large page when there is no available large page on system, it's not a JVM bug. So I think it's not suitable to report test failure, but report SkippedException.
>> 
>> Change has been verified locally, test report SkippedException on the system without free hugepage, the test passes on the system with free hugepage. Test-fix only, risk is low.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make explicitAvailableHugePageNumber as a member of HugePageConfiguration

Okay

-------------

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26480#pullrequestreview-3057668223

From syan at openjdk.org  Sun Jul 27 01:20:00 2025
From: syan at openjdk.org (SendaoYan)
Date: Sun, 27 Jul 2025 01:20:00 GMT
Subject: RFR: 8364114: Test
 TestHugePageDecisionsAtVMStartup.java#LP_enabled fails when no free hugepage
 [v3]
In-Reply-To: <SzZ8l2FGhoDN6ceAHJXqJTtKxQG8f-ED7rxDxFCxEVs=.b31562d7-2a63-4db8-9750-5351a3b9863c@github.com>
References: <xtrPwb4mg-gGCOXQwlYiGYC7F8iirF_trNYiDE9176E=.77ea0256-847b-4c9b-99bd-9f8fb0a753a2@github.com>
 <IBkZBr0sB3LgmV9OIn-viQ5ew8KGgHQsWQF5KUqBFHQ=.59448274-1dfa-4152-bd6e-bc0832d033c8@github.com>
 <SzZ8l2FGhoDN6ceAHJXqJTtKxQG8f-ED7rxDxFCxEVs=.b31562d7-2a63-4db8-9750-5351a3b9863c@github.com>
Message-ID: <VPfPdmHKEgbnTcb0phV11Qo-YiaxwnWyKH13qPBidzE=.d3394403-d57a-403f-90fd-64a9a5adf4de@github.com>

On Sat, 26 Jul 2025 04:49:26 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make explicitAvailableHugePageNumber as a member of HugePageConfiguration
>
> Okay

Thanks for the reviews and suggestions @tstuefe 

Do we need the second reviewer to this PR

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26480#issuecomment-3123697759

From dholmes at openjdk.org  Mon Jul 28 06:07:01 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 28 Jul 2025 06:07:01 GMT
Subject: RFR: 8364114: Test
 TestHugePageDecisionsAtVMStartup.java#LP_enabled fails when no free hugepage
 [v3]
In-Reply-To: <VPfPdmHKEgbnTcb0phV11Qo-YiaxwnWyKH13qPBidzE=.d3394403-d57a-403f-90fd-64a9a5adf4de@github.com>
References: <xtrPwb4mg-gGCOXQwlYiGYC7F8iirF_trNYiDE9176E=.77ea0256-847b-4c9b-99bd-9f8fb0a753a2@github.com>
 <IBkZBr0sB3LgmV9OIn-viQ5ew8KGgHQsWQF5KUqBFHQ=.59448274-1dfa-4152-bd6e-bc0832d033c8@github.com>
 <SzZ8l2FGhoDN6ceAHJXqJTtKxQG8f-ED7rxDxFCxEVs=.b31562d7-2a63-4db8-9750-5351a3b9863c@github.com>
 <VPfPdmHKEgbnTcb0phV11Qo-YiaxwnWyKH13qPBidzE=.d3394403-d57a-403f-90fd-64a9a5adf4de@github.com>
Message-ID: <VR2NOvNCzpJTgBzKgPEUPZVqGOa2RJ2BZRm-DQU4m1Y=.046b5a37-aa88-4c18-bac5-2a76c6e40b19@github.com>

On Sun, 27 Jul 2025 01:17:19 GMT, SendaoYan <syan at openjdk.org> wrote:

> Do we need the second reviewer to this PR

Yes. If it touches src/hotspot or test/hotspot, and is not a trivial fix (per the developer guide[1]) then we require two reviews.

[1] https://openjdk.org/guide/#trivial-changes

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26480#issuecomment-3125667328

From dholmes at openjdk.org  Mon Jul 28 06:20:03 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 28 Jul 2025 06:20:03 GMT
Subject: RFR: 8364114: Test
 TestHugePageDecisionsAtVMStartup.java#LP_enabled fails when no free hugepage
 [v3]
In-Reply-To: <IBkZBr0sB3LgmV9OIn-viQ5ew8KGgHQsWQF5KUqBFHQ=.59448274-1dfa-4152-bd6e-bc0832d033c8@github.com>
References: <xtrPwb4mg-gGCOXQwlYiGYC7F8iirF_trNYiDE9176E=.77ea0256-847b-4c9b-99bd-9f8fb0a753a2@github.com>
 <IBkZBr0sB3LgmV9OIn-viQ5ew8KGgHQsWQF5KUqBFHQ=.59448274-1dfa-4152-bd6e-bc0832d033c8@github.com>
Message-ID: <_uxF8OhaCf01JZU4Ks5OWIG1zeo15-lgh8RFisPItd4=.4ec473c0-6964-45a3-a49e-88e8e2d439f8@github.com>

On Sat, 26 Jul 2025 04:33:20 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> The test runtime/os/TestHugePageDecisionsAtVMStartup.java#LP_enabled will fails when there is no free hugepases.
>> The /proc/meminfo and /sys/kernel/mm/hugepages/hugepages-*/free_hugepages says there is no free hugepage, and the JVM output also say there is available large page.
>> 
>> 
>>> cat /proc/meminfo | grep -i HugePages
>> AnonHugePages:         0 kB
>> ShmemHugePages:        0 kB
>> FileHugePages:         0 kB
>> HugePages_Total:       2
>> HugePages_Free:        0
>> HugePages_Rsvd:        0
>> HugePages_Surp:        2
>> Hugepagesize:       2048 kB
>> 
>>> ( set -x ; cat /sys/kernel/mm/hugepages/hugepages-*/free_hugepages )
>> + cat /sys/kernel/mm/hugepages/hugepages-1048576kB/free_hugepages /sys/kernel/mm/hugepages/hugepages-2048kB/free_hugepages
>> 0
>> 0
>> 
>> JVM output snippet from java -XX:+UseLargePages -Xlog:pagesize -version
>> [0.001s][info][pagesize] Large page size (2M) failed sanity check, checking if smaller large page sizes are usable
>> [0.001s][warning][pagesize] UseLargePages disabled, no large pages configured and available on the system.
>> 
>> 
>> The JVM can not use large page when there is no available large page on system, it's not a JVM bug. So I think it's not suitable to report test failure, but report SkippedException.
>> 
>> Change has been verified locally, test report SkippedException on the system without free hugepage, the test passes on the system with free hugepage. Test-fix only, risk is low.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make explicitAvailableHugePageNumber as a member of HugePageConfiguration

I can't quite see how the first version of the change was actually reading the value from `/proc/meminfo`, but I don't like that we parse `/proc/meminfo` twice now - that's unnecessarily inefficient IMO. That said, it isn't a lot of information so I won't insist on a change.

Approved.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26480#pullrequestreview-3060564708

From sspitsyn at openjdk.org  Mon Jul 28 06:38:36 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 28 Jul 2025 06:38:36 GMT
Subject: RFR: 8306324: StopThread results in thread being marked as
 interrupted, leading to unexpected InterruptedException [v2]
In-Reply-To: <sDAklD-arV33IpWiJwMkwUfNPMAmsr5cgboU4y0hjhk=.192cd7e5-f2a2-4b5c-83a9-5111bf1926ec@github.com>
References: <sDAklD-arV33IpWiJwMkwUfNPMAmsr5cgboU4y0hjhk=.192cd7e5-f2a2-4b5c-83a9-5111bf1926ec@github.com>
Message-ID: <djr92IT1vZGJve5RPW1OQef0M6ntrA_uC8ErYV1ppuM=.4503a274-5790-4fa3-9382-e2da3af7a9c8@github.com>

> 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 with a new target base 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
 - 8306324: StopThread results in thread being marked as interrupted, leading to unexpected InterruptedException

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26365/files
  - new: https://git.openjdk.org/jdk/pull/26365/files/cd235460..8338fb55

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26365&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26365&range=00-01

  Stats: 14768 lines in 435 files changed: 7261 ins; 5653 del; 1854 mod
  Patch: https://git.openjdk.org/jdk/pull/26365.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26365/head:pull/26365

PR: https://git.openjdk.org/jdk/pull/26365

From syan at openjdk.org  Mon Jul 28 06:57:03 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 28 Jul 2025 06:57:03 GMT
Subject: RFR: 8364114: Test
 TestHugePageDecisionsAtVMStartup.java#LP_enabled fails when no free hugepage
 [v3]
In-Reply-To: <SzZ8l2FGhoDN6ceAHJXqJTtKxQG8f-ED7rxDxFCxEVs=.b31562d7-2a63-4db8-9750-5351a3b9863c@github.com>
References: <xtrPwb4mg-gGCOXQwlYiGYC7F8iirF_trNYiDE9176E=.77ea0256-847b-4c9b-99bd-9f8fb0a753a2@github.com>
 <IBkZBr0sB3LgmV9OIn-viQ5ew8KGgHQsWQF5KUqBFHQ=.59448274-1dfa-4152-bd6e-bc0832d033c8@github.com>
 <SzZ8l2FGhoDN6ceAHJXqJTtKxQG8f-ED7rxDxFCxEVs=.b31562d7-2a63-4db8-9750-5351a3b9863c@github.com>
Message-ID: <b8XYI_7OL0zMHYBKFCzmWvcUmufZUDoAzy_cfuH8N_w=.a8e1327a-6238-4cae-bd59-6c256542d93a@github.com>

On Sat, 26 Jul 2025 04:49:26 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make explicitAvailableHugePageNumber as a member of HugePageConfiguration
>
> Okay

Thanks @tstuefe @dholmes-ora for the reviews and suggetions.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26480#issuecomment-3125791909

From syan at openjdk.org  Mon Jul 28 06:57:04 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 28 Jul 2025 06:57:04 GMT
Subject: Integrated: 8364114: Test
 TestHugePageDecisionsAtVMStartup.java#LP_enabled fails when no free hugepage
In-Reply-To: <xtrPwb4mg-gGCOXQwlYiGYC7F8iirF_trNYiDE9176E=.77ea0256-847b-4c9b-99bd-9f8fb0a753a2@github.com>
References: <xtrPwb4mg-gGCOXQwlYiGYC7F8iirF_trNYiDE9176E=.77ea0256-847b-4c9b-99bd-9f8fb0a753a2@github.com>
Message-ID: <HLPmwUVUd0sX44I-8TvwAGGjpGNXqLPwze7cD7AYo48=.1c53dbbe-9856-4ea5-b7bd-a6a97281c4bd@github.com>

On Fri, 25 Jul 2025 12:47:23 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> The test runtime/os/TestHugePageDecisionsAtVMStartup.java#LP_enabled will fails when there is no free hugepases.
> The /proc/meminfo and /sys/kernel/mm/hugepages/hugepages-*/free_hugepages says there is no free hugepage, and the JVM output also say there is available large page.
> 
> 
>> cat /proc/meminfo | grep -i HugePages
> AnonHugePages:         0 kB
> ShmemHugePages:        0 kB
> FileHugePages:         0 kB
> HugePages_Total:       2
> HugePages_Free:        0
> HugePages_Rsvd:        0
> HugePages_Surp:        2
> Hugepagesize:       2048 kB
> 
>> ( set -x ; cat /sys/kernel/mm/hugepages/hugepages-*/free_hugepages )
> + cat /sys/kernel/mm/hugepages/hugepages-1048576kB/free_hugepages /sys/kernel/mm/hugepages/hugepages-2048kB/free_hugepages
> 0
> 0
> 
> JVM output snippet from java -XX:+UseLargePages -Xlog:pagesize -version
> [0.001s][info][pagesize] Large page size (2M) failed sanity check, checking if smaller large page sizes are usable
> [0.001s][warning][pagesize] UseLargePages disabled, no large pages configured and available on the system.
> 
> 
> The JVM can not use large page when there is no available large page on system, it's not a JVM bug. So I think it's not suitable to report test failure, but report SkippedException.
> 
> Change has been verified locally, test report SkippedException on the system without free hugepage, the test passes on the system with free hugepage. Test-fix only, risk is low.

This pull request has now been integrated.

Changeset: 3b0da298
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3b0da29879990e4ed6d22c8aed0659f3b40c37a3
Stats:     32 lines in 2 files changed: 29 ins; 0 del; 3 mod

8364114: Test TestHugePageDecisionsAtVMStartup.java#LP_enabled fails when no free hugepage

Reviewed-by: stuefe, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/26480

From sspitsyn at openjdk.org  Mon Jul 28 06:57:42 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 28 Jul 2025 06:57:42 GMT
Subject: RFR: 8306324: StopThread results in thread being marked as
 interrupted, leading to unexpected InterruptedException [v3]
In-Reply-To: <sDAklD-arV33IpWiJwMkwUfNPMAmsr5cgboU4y0hjhk=.192cd7e5-f2a2-4b5c-83a9-5111bf1926ec@github.com>
References: <sDAklD-arV33IpWiJwMkwUfNPMAmsr5cgboU4y0hjhk=.192cd7e5-f2a2-4b5c-83a9-5111bf1926ec@github.com>
Message-ID: <AWpHV3UvP_0bCI8pMBUQtIsYrmGcXLY8j9_KubieCHg=.2e793179-2c88-41d3-8672-dfa57e5625a0@github.com>

> 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:

  review: implemented a suggestion: do not set interrupt flag at all

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26365/files
  - new: https://git.openjdk.org/jdk/pull/26365/files/8338fb55..fde881f0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26365&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26365&range=01-02

  Stats: 8 lines in 1 file changed: 3 ins; 5 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26365.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26365/head:pull/26365

PR: https://git.openjdk.org/jdk/pull/26365

From sspitsyn at openjdk.org  Mon Jul 28 07:01:58 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 28 Jul 2025 07:01:58 GMT
Subject: RFR: 8306324: StopThread results in thread being marked as
 interrupted, leading to unexpected InterruptedException [v3]
In-Reply-To: <AWpHV3UvP_0bCI8pMBUQtIsYrmGcXLY8j9_KubieCHg=.2e793179-2c88-41d3-8672-dfa57e5625a0@github.com>
References: <sDAklD-arV33IpWiJwMkwUfNPMAmsr5cgboU4y0hjhk=.192cd7e5-f2a2-4b5c-83a9-5111bf1926ec@github.com>
 <AWpHV3UvP_0bCI8pMBUQtIsYrmGcXLY8j9_KubieCHg=.2e793179-2c88-41d3-8672-dfa57e5625a0@github.com>
Message-ID: <t112h-njRQZ9ruMkt5c6Sd7fYH-5UVmCu6F5GwpdAQQ=.889537f2-866c-4120-9169-33758fb8a2b4@github.com>

On Mon, 28 Jul 2025 06:57:42 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:
> 
>   review: implemented a suggestion: do not set interrupt flag at all

I've implemented and pushed the suggestion from Patricio. The mach5 tiers 1-6 are clean.
I'm not sure about correctness of the tweak in the `JavaThread::sleep_nanos()`:

@@ -2122,6 +2117,9 @@ bool JavaThread::sleep_nanos(jlong nanos) {
   jlong nanos_remaining = nanos;
 
   for (;;) {
+    if (has_async_exception_condition()) {
+      return false;
+    }
     // interruption has precedence over timing out
     if (this->is_interrupted(true)) {
       return false;

The mach5 tiers 1-6 tests are all passed without this tweak.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26365#issuecomment-3125809023

From tschatzl at openjdk.org  Mon Jul 28 07:58:54 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 28 Jul 2025 07:58:54 GMT
Subject: RFR: 8364019: Add alignment precondition to Universe::reserve_heap
In-Reply-To: <zn5eMLyIaYJS2ooP8Os28aLCk_t8ZaDhxPGF6PLw7Qo=.b720b417-1433-493c-9ccf-1246e0dbd15e@github.com>
References: <zn5eMLyIaYJS2ooP8Os28aLCk_t8ZaDhxPGF6PLw7Qo=.b720b417-1433-493c-9ccf-1246e0dbd15e@github.com>
Message-ID: <hgRKq3AiGWMlQE7t9peF-jxurb_USRfgJ5iQa-5Oqxk=.94477a47-8b99-4c88-b9d1-141ba9c2dc85@github.com>

On Thu, 24 Jul 2025 10:06:17 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple converting a redundant `align_up` to assert.
> 
> Test: tier1

Marked as reviewed by tschatzl (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26456#pullrequestreview-3061025595

From syan at openjdk.org  Mon Jul 28 08:31:33 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 28 Jul 2025 08:31:33 GMT
Subject: RFR: 8362501: Update
 test/hotspot/jtreg/applications/jcstress/README [v4]
In-Reply-To: <Gv-CfzN4MbQDSvKMkXs6DWllE9saxTpkjIh92W8GkK4=.04b9e256-42cb-48de-a8e0-2345cdbc8b78@github.com>
References: <Gv-CfzN4MbQDSvKMkXs6DWllE9saxTpkjIh92W8GkK4=.04b9e256-42cb-48de-a8e0-2345cdbc8b78@github.com>
Message-ID: <Wwg1FUee7XV-zrOiEag_diMIuhIWmfN9LLypapmTZN0=.81726fc2-c31a-45de-9eac-0621be46f0b0@github.com>

> Hi all,
> 
> Currently, this is no documentation on how to run the application/jcstress tests. I think it will be useful to complement the document test/hotspot/jtreg/applications/jcstress/README on how to run the jcstress tests in jtreg.
> 
> No behaviour has been change, only update the ducumentation, no risk.

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  The way to
  get the specified build you can reference the guide

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26369/files
  - new: https://git.openjdk.org/jdk/pull/26369/files/716b97c4..3be2e7f7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26369&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26369&range=02-03

  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/26369.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26369/head:pull/26369

PR: https://git.openjdk.org/jdk/pull/26369

From syan at openjdk.org  Mon Jul 28 08:31:34 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 28 Jul 2025 08:31:34 GMT
Subject: RFR: 8362501: Update
 test/hotspot/jtreg/applications/jcstress/README [v2]
In-Reply-To: <jmuye4qB2P1v8S55uQa52CGv5HKf6LWKocIvRXU_Hi8=.daa603a8-b2f2-4531-95ba-fac5df754b4b@github.com>
References: <Gv-CfzN4MbQDSvKMkXs6DWllE9saxTpkjIh92W8GkK4=.04b9e256-42cb-48de-a8e0-2345cdbc8b78@github.com>
 <_OAL4RIUkuwkPCOPg9arhmB71sz4xwkSsPuKzBVnLzo=.dc5503ee-2acf-4a03-b36d-e34c57b03d61@github.com>
 <IaF3SoFbgcA8GCTuW14uUriIn3Os2U7Ep9L7tLpeH1Q=.8bc954be-f639-4f5a-b341-4dc2a8dbb223@github.com>
 <jmuye4qB2P1v8S55uQa52CGv5HKf6LWKocIvRXU_Hi8=.daa603a8-b2f2-4531-95ba-fac5df754b4b@github.com>
Message-ID: <qA8z4Ecdw1SyXIxaCRIRhlDm3gN3Csvaz-6AeGRU8yw=.af8c7ff8-1f6c-4df3-aa57-33d71c8ae99a@github.com>

On Fri, 25 Jul 2025 09:39:15 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > Or @shipilev may be able to review?
> 
> (slowly turns in his home office chair and stares curiously at his home server that produces jcstress binaries). Meh, I am on the fence on referencing 3rd party personal websites like mine. So I would defer to others if they are good with it.

I have removed the 3rd party personal websites.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26369#issuecomment-3126117237

From shade at openjdk.org  Mon Jul 28 09:08:56 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 28 Jul 2025 09:08:56 GMT
Subject: RFR: 8362501: Update
 test/hotspot/jtreg/applications/jcstress/README [v4]
In-Reply-To: <Wwg1FUee7XV-zrOiEag_diMIuhIWmfN9LLypapmTZN0=.81726fc2-c31a-45de-9eac-0621be46f0b0@github.com>
References: <Gv-CfzN4MbQDSvKMkXs6DWllE9saxTpkjIh92W8GkK4=.04b9e256-42cb-48de-a8e0-2345cdbc8b78@github.com>
 <Wwg1FUee7XV-zrOiEag_diMIuhIWmfN9LLypapmTZN0=.81726fc2-c31a-45de-9eac-0621be46f0b0@github.com>
Message-ID: <ukPdPUO5eSSEkyMMXYUoIQZvfNlei9dASLvzdoDYGPg=.e05f2534-a6b7-4ccc-8e7a-f2024ba5d2f2@github.com>

On Mon, 28 Jul 2025 08:31:33 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Currently, this is no documentation on how to run the application/jcstress tests. I think it will be useful to complement the document test/hotspot/jtreg/applications/jcstress/README on how to run the jcstress tests in jtreg.
>> 
>> No behaviour has been change, only update the ducumentation, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   The way to
>   get the specified build you can reference the guide

Looks better. I think we can be less specific in the guidance, see below.

test/hotspot/jtreg/applications/jcstress/README line 34:

> 32: You should specific the JAR location with jtreg option such as
> 33: -javaoption:-Djdk.test.lib.artifacts.jcstress-tests-all=
> 34: jcstress-tests-all-20241217-2035.jar when starting jcstress tests in jtreg.

Suggestion:

successfully. These tests require a build of org.openjdk.jcstress:jcstress-tests-all.
If this artifact could not be found automatically, you can build it using jcstress
guide[1], and then pass the JAR location with JDK option such as 
-Djdk.test.lib.artifacts.jcstress-tests-all=jcstress-tests-all.jar, 
either with explicit -javaoption: or TEST_VM_OPTS test variable.

-------------

PR Review: https://git.openjdk.org/jdk/pull/26369#pullrequestreview-3061389801
PR Review Comment: https://git.openjdk.org/jdk/pull/26369#discussion_r2235459431

From duke at openjdk.org  Mon Jul 28 09:19:52 2025
From: duke at openjdk.org (Anton Artemov)
Date: Mon, 28 Jul 2025 09:19:52 GMT
Subject: RFR: 8359820: Improve handshake/safepoint timeout diagnostic
 messages [v6]
In-Reply-To: <FZ87bVfDootrLeANGguMFpcTm7X8AEqzuKVQspmSkmE=.4484090b-ba49-498c-bb07-71d22fd34823@github.com>
References: <FZ87bVfDootrLeANGguMFpcTm7X8AEqzuKVQspmSkmE=.4484090b-ba49-498c-bb07-71d22fd34823@github.com>
Message-ID: <GMAIqixQYJ39qEt4AZqsS98YGLaZmNjCHdeI7kEpN84=.66b896fe-6a10-43a1-89af-9dea3a65fed3@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 13 additional commits since the last revision:

 - 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
 - 8359820: Fixed test
 - 8359820: Removed extra line
 - Merge branch 'JDK-8359820-SIGILL-with-low-handshake-timeout-on-intel-sde' of https://github.com/toxaart/jdk into JDK-8359820-SIGILL-with-low-handshake-timeout-on-intel-sde
 - Merge remote-tracking branch 'origin/master' into JDK-8359820-SIGILL-with-low-handshake-timeout-on-intel-sde
 - ... and 3 more: https://git.openjdk.org/jdk/compare/e695e215...f97067c3

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26309/files
  - new: https://git.openjdk.org/jdk/pull/26309/files/9ccf0960..f97067c3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26309&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26309&range=04-05

  Stats: 15036 lines in 447 files changed: 7287 ins; 5799 del; 1950 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 ktakakuri at openjdk.org  Mon Jul 28 09:32:08 2025
From: ktakakuri at openjdk.org (Kazuhisa Takakuri)
Date: Mon, 28 Jul 2025 09:32:08 GMT
Subject: RFR: 8349288: runtime/os/windows/TestAvailableProcessors.java
 fails on localized Windows platform [v8]
In-Reply-To: <AyBYtnOX-I19A-XzxvFSw3wp7mfQDpS3vx9-y2d4-Ik=.ec034a22-d6c1-47fb-9459-809076ab6e1a@github.com>
References: <Ra31Q95DukIesp9Ivxsw4AYNOtqAm3JIeMSCtOHuTIM=.abd6dea4-4628-4983-9b38-642c21e792b5@github.com>
 <STlgNAPSBgWhFdC0FjPkBikj6BWGFIARLlYjgGJ5RBM=.90e1cf00-6440-4a22-b488-6ae3e5442c46@github.com>
 <hIuECle5gdWJxxZrRj3XsfIbfkknOfmtmCFfh_VA8o8=.bffc1a33-9a97-4515-9aa2-6e893ac1ca94@github.com>
 <AyBYtnOX-I19A-XzxvFSw3wp7mfQDpS3vx9-y2d4-Ik=.ec034a22-d6c1-47fb-9459-809076ab6e1a@github.com>
Message-ID: <FHajUIAPLMiDjCB8YzoeJDv3ap4ZocubAIjl3kZ9Y5I=.a0a9b29c-3795-43b8-9db2-07a1ebbe3a70@github.com>

On Fri, 20 Jun 2025 09:27:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> @AlanBateman This PR requires two approvals. I apologize for the long delay, but could you review it?
>
>> @AlanBateman This PR requires two approvals. I apologize for the long delay, but could you review it?
> 
> Sure, just have some drive by comments, switching to cp437 should be okay.

@AlanBateman I fixed the code as you suggested. Could you please review it?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23536#issuecomment-3126357906

From duke at openjdk.org  Mon Jul 28 10:10:59 2025
From: duke at openjdk.org (Anton Artemov)
Date: Mon, 28 Jul 2025 10:10:59 GMT
Subject: RFR: 8359820: Improve handshake/safepoint timeout diagnostic
 messages [v7]
In-Reply-To: <FZ87bVfDootrLeANGguMFpcTm7X8AEqzuKVQspmSkmE=.4484090b-ba49-498c-bb07-71d22fd34823@github.com>
References: <FZ87bVfDootrLeANGguMFpcTm7X8AEqzuKVQspmSkmE=.4484090b-ba49-498c-bb07-71d22fd34823@github.com>
Message-ID: <f8ydKyrpfDyPHFCFJ5mwuq2Uk2z_ZoLllhoDyS1Dy_4=.4308b09b-a7aa-46ce-9e59-7a9b57c7e7c8@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 incrementally with two additional commits since the last revision:

 - 8359820: Addressed reviewer's comments
 - 8359820: Addressed reviewer's comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26309/files
  - new: https://git.openjdk.org/jdk/pull/26309/files/f97067c3..9c914a50

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26309&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26309&range=05-06

  Stats: 13 lines in 3 files changed: 0 ins; 0 del; 13 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 Jul 28 10:11:02 2025
From: duke at openjdk.org (Anton Artemov)
Date: Mon, 28 Jul 2025 10:11:02 GMT
Subject: RFR: 8359820: Improve handshake/safepoint timeout diagnostic
 messages [v5]
In-Reply-To: <nm_TxYRfv8-2L8rRt-HZE7Cchc4SarBu98N15t6lHdI=.aeba6656-edff-4066-b5ad-0a11b91091c3@github.com>
References: <FZ87bVfDootrLeANGguMFpcTm7X8AEqzuKVQspmSkmE=.4484090b-ba49-498c-bb07-71d22fd34823@github.com>
 <ggMtbeagKlcBKFYnxX9QaDkzIx47EKoRnPIjetMkxCo=.4f3fd07f-fb9a-42c5-9a7d-2ae1f77f093b@github.com>
 <nm_TxYRfv8-2L8rRt-HZE7Cchc4SarBu98N15t6lHdI=.aeba6656-edff-4066-b5ad-0a11b91091c3@github.com>
Message-ID: <sOYbpljcjpM4aGLPIQO_wZ_S5n_vREtu4uBfTXux9Wc=.f0e8a44b-ba38-4368-8f08-187fdbb2c842@github.com>

On Sun, 20 Jul 2025 21:39:24 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: Fixed spaces
>>  - 8359820: Addressed reviewer's comments
>
> src/hotspot/share/runtime/handshake.cpp line 214:
> 
>> 212:   }
>> 213:   if (target != nullptr) {
>> 214:     fatal("Thread " PTR_FORMAT " has not cleared handshake op: " PTR_FORMAT ", then failed to terminate JVM", p2i(target), p2i(op));
> 
> Suggestion:
> 
>     fatal("Thread " PTR_FORMAT " has not cleared handshake op %s, and failed to terminate the JVM", p2i(target), op->name());
> 
> The earlier logging statement that uses `p2i(op)` relies on an even earlier logging statement (line 189/190) that reports the name and the `p2i` value. But the fatal error message can't rely on using logging information to map the `p2i` value back to a name, so we need the name directly.

Thanks, addressed in the latest commit.

> src/hotspot/share/utilities/vmError.cpp line 108:
> 
>> 106: const intptr_t    VMError::segfault_address = pd_segfault_address;
>> 107: volatile intptr_t VMError::handshakeTimedOutThread = p2i(nullptr);
>> 108: volatile intptr_t VMError::safepointTimedOutThread = p2i(nullptr);
> 
> Suggestion:
> 
> volatile intptr_t VMError::_handshake_timeout_thread = p2i(nullptr);
> volatile intptr_t VMError::_safepoint_timeout_thread = p2i(nullptr);

Addressed in the latest commit.

> src/hotspot/share/utilities/vmError.cpp line 1340:
> 
>> 1338: }
>> 1339: 
>> 1340: void VMError::set_handshake_timed_out_thread(intptr_t x) {
> 
> Suggestion:
> 
> void VMError::set_handshake_timed_out_thread(intptr_t thread_addr) {

Addressed in the latest commit.

> src/hotspot/share/utilities/vmError.cpp line 1344:
> 
>> 1342: }
>> 1343: 
>> 1344: void VMError::set_safepoint_timed_out_thread(intptr_t x) {
> 
> Suggestion:
> 
> void VMError::set_safepoint_timed_out_thread(intptr_t thread_addr) {

Addressed in the latest commit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26309#discussion_r2235680354
PR Review Comment: https://git.openjdk.org/jdk/pull/26309#discussion_r2235682175
PR Review Comment: https://git.openjdk.org/jdk/pull/26309#discussion_r2235681293
PR Review Comment: https://git.openjdk.org/jdk/pull/26309#discussion_r2235681597

From alanb at openjdk.org  Mon Jul 28 10:52:58 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 28 Jul 2025 10:52:58 GMT
Subject: RFR: 8306324: StopThread results in thread being marked as
 interrupted, leading to unexpected InterruptedException [v3]
In-Reply-To: <t112h-njRQZ9ruMkt5c6Sd7fYH-5UVmCu6F5GwpdAQQ=.889537f2-866c-4120-9169-33758fb8a2b4@github.com>
References: <sDAklD-arV33IpWiJwMkwUfNPMAmsr5cgboU4y0hjhk=.192cd7e5-f2a2-4b5c-83a9-5111bf1926ec@github.com>
 <AWpHV3UvP_0bCI8pMBUQtIsYrmGcXLY8j9_KubieCHg=.2e793179-2c88-41d3-8672-dfa57e5625a0@github.com>
 <t112h-njRQZ9ruMkt5c6Sd7fYH-5UVmCu6F5GwpdAQQ=.889537f2-866c-4120-9169-33758fb8a2b4@github.com>
Message-ID: <2faiO8M1kDjt63rmbo8EjfXOxA5ggxcpHp4S3Ok3S2A=.b85da477-0c63-47a2-aac8-988254863fd4@github.com>

On Mon, 28 Jul 2025 06:58:50 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: implemented a suggestion: do not set interrupt flag at all
>
> I've implemented and pushed the suggestion from Patricio. The mach5 tiers 1-6 are clean.
> I'm not sure about correctness of the tweak in the `JavaThread::sleep_nanos()`:
> 
> @@ -2122,6 +2117,9 @@ bool JavaThread::sleep_nanos(jlong nanos) {
>    jlong nanos_remaining = nanos;
>  
>    for (;;) {
> +    if (has_async_exception_condition()) {
> +      return false;
> +    }
>      // interruption has precedence over timing out
>      if (this->is_interrupted(true)) {
>        return false;
> 
> The mach5 tiers 1-6 tests are all passed without this tweak.

> > @sspitsyn It might be useful to reach out to the IDEs to see what they are doing. From a quick test with IntelliJ then it appears to invoke both StopThread and InterruptThread when "Exception to Throw" is used. In that case, it means that Thread.sleep will wakeup, even if StopThread doesn't interrupt.
> 
> Good suggestion, thanks.

It would put the onus on the debugger to interrupt, which I think is the right thing to do. it would remove the interrupt from JavaThread::install_async_exception and would mean no change to JavaThread::sleep_nanos.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26365#issuecomment-3126657391

From syan at openjdk.org  Mon Jul 28 12:37:43 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 28 Jul 2025 12:37:43 GMT
Subject: RFR: 8362501: Update
 test/hotspot/jtreg/applications/jcstress/README [v5]
In-Reply-To: <Gv-CfzN4MbQDSvKMkXs6DWllE9saxTpkjIh92W8GkK4=.04b9e256-42cb-48de-a8e0-2345cdbc8b78@github.com>
References: <Gv-CfzN4MbQDSvKMkXs6DWllE9saxTpkjIh92W8GkK4=.04b9e256-42cb-48de-a8e0-2345cdbc8b78@github.com>
Message-ID: <QmYz2Em781E3S8CsPKyIL7WXadn3jSQ6gGiEBrtPcu8=.a3b6647b-c2d9-423f-ba2e-26d496fb8ceb@github.com>

> Hi all,
> 
> Currently, this is no documentation on how to run the application/jcstress tests. I think it will be useful to complement the document test/hotspot/jtreg/applications/jcstress/README on how to run the jcstress tests in jtreg.
> 
> No behaviour has been change, only update the ducumentation, no risk.

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  Use less specific in the guidance

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26369/files
  - new: https://git.openjdk.org/jdk/pull/26369/files/3be2e7f7..7b52c0b4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26369&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26369&range=03-04

  Stats: 6 lines in 1 file changed: 0 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/26369.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26369/head:pull/26369

PR: https://git.openjdk.org/jdk/pull/26369

From syan at openjdk.org  Mon Jul 28 12:46:58 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 28 Jul 2025 12:46:58 GMT
Subject: RFR: 8362501: Update
 test/hotspot/jtreg/applications/jcstress/README [v4]
In-Reply-To: <ukPdPUO5eSSEkyMMXYUoIQZvfNlei9dASLvzdoDYGPg=.e05f2534-a6b7-4ccc-8e7a-f2024ba5d2f2@github.com>
References: <Gv-CfzN4MbQDSvKMkXs6DWllE9saxTpkjIh92W8GkK4=.04b9e256-42cb-48de-a8e0-2345cdbc8b78@github.com>
 <Wwg1FUee7XV-zrOiEag_diMIuhIWmfN9LLypapmTZN0=.81726fc2-c31a-45de-9eac-0621be46f0b0@github.com>
 <ukPdPUO5eSSEkyMMXYUoIQZvfNlei9dASLvzdoDYGPg=.e05f2534-a6b7-4ccc-8e7a-f2024ba5d2f2@github.com>
Message-ID: <bvwZyNvegISeo01c9-hYirH54Ovhso78GF_-IumLRe4=.114f61ce-4c95-444a-b994-e2a65c5e269f@github.com>

On Mon, 28 Jul 2025 09:05:18 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   The way to
>>   get the specified build you can reference the guide
>
> test/hotspot/jtreg/applications/jcstress/README line 34:
> 
>> 32: You should specific the JAR location with jtreg option such as
>> 33: -javaoption:-Djdk.test.lib.artifacts.jcstress-tests-all=
>> 34: jcstress-tests-all-20241217-2035.jar when starting jcstress tests in jtreg.
> 
> Suggestion:
> 
> successfully. These tests require a build of org.openjdk.jcstress:jcstress-tests-all.
> If this artifact could not be found automatically, you can build it using jcstress
> guide[1], and then pass the JAR location with JDK option such as 
> -Djdk.test.lib.artifacts.jcstress-tests-all=jcstress-tests-all.jar, 
> either with explicit -javaoption: or TEST_VM_OPTS test variable.

Thanks. The README has been updated according your suggest.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26369#discussion_r2236280370

From shade at openjdk.org  Mon Jul 28 13:36:57 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 28 Jul 2025 13:36:57 GMT
Subject: RFR: 8362501: Update
 test/hotspot/jtreg/applications/jcstress/README [v5]
In-Reply-To: <QmYz2Em781E3S8CsPKyIL7WXadn3jSQ6gGiEBrtPcu8=.a3b6647b-c2d9-423f-ba2e-26d496fb8ceb@github.com>
References: <Gv-CfzN4MbQDSvKMkXs6DWllE9saxTpkjIh92W8GkK4=.04b9e256-42cb-48de-a8e0-2345cdbc8b78@github.com>
 <QmYz2Em781E3S8CsPKyIL7WXadn3jSQ6gGiEBrtPcu8=.a3b6647b-c2d9-423f-ba2e-26d496fb8ceb@github.com>
Message-ID: <aLJ374fksiLuSecVXJ3M1azD48uy-fVI_gSmUjG2-AI=.4e4f18d7-3a34-406f-a598-7e2f1f6bd8c6@github.com>

On Mon, 28 Jul 2025 12:37:43 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Currently, this is no documentation on how to run the application/jcstress tests. I think it will be useful to complement the document test/hotspot/jtreg/applications/jcstress/README on how to run the jcstress tests in jtreg.
>> 
>> No behaviour has been change, only update the ducumentation, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use less specific in the guidance

Marked as reviewed by shade (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26369#pullrequestreview-3062771549

From jsikstro at openjdk.org  Mon Jul 28 13:45:56 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 28 Jul 2025 13:45:56 GMT
Subject: RFR: 8364019: Add alignment precondition to Universe::reserve_heap
In-Reply-To: <zn5eMLyIaYJS2ooP8Os28aLCk_t8ZaDhxPGF6PLw7Qo=.b720b417-1433-493c-9ccf-1246e0dbd15e@github.com>
References: <zn5eMLyIaYJS2ooP8Os28aLCk_t8ZaDhxPGF6PLw7Qo=.b720b417-1433-493c-9ccf-1246e0dbd15e@github.com>
Message-ID: <_pKyd5T7jCFl-FgWdY0NqW5FtynSbjrsUqPdrDtzeyA=.7f1e9210-3889-43c6-b4e2-0cee6df92bda@github.com>

On Thu, 24 Jul 2025 10:06:17 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple converting a redundant `align_up` to assert.
> 
> Test: tier1

Looks good.

-------------

Marked as reviewed by jsikstro (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26456#pullrequestreview-3062830022

From syan at openjdk.org  Mon Jul 28 13:49:55 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 28 Jul 2025 13:49:55 GMT
Subject: RFR: 8362501: Update
 test/hotspot/jtreg/applications/jcstress/README [v2]
In-Reply-To: <jmuye4qB2P1v8S55uQa52CGv5HKf6LWKocIvRXU_Hi8=.daa603a8-b2f2-4531-95ba-fac5df754b4b@github.com>
References: <Gv-CfzN4MbQDSvKMkXs6DWllE9saxTpkjIh92W8GkK4=.04b9e256-42cb-48de-a8e0-2345cdbc8b78@github.com>
 <_OAL4RIUkuwkPCOPg9arhmB71sz4xwkSsPuKzBVnLzo=.dc5503ee-2acf-4a03-b36d-e34c57b03d61@github.com>
 <IaF3SoFbgcA8GCTuW14uUriIn3Os2U7Ep9L7tLpeH1Q=.8bc954be-f639-4f5a-b341-4dc2a8dbb223@github.com>
 <jmuye4qB2P1v8S55uQa52CGv5HKf6LWKocIvRXU_Hi8=.daa603a8-b2f2-4531-95ba-fac5df754b4b@github.com>
Message-ID: <AwJ39Vz0i4ELtR_na6Ooc_S0naDTaULK2Fgga46uuiI=.48f76cf9-84bc-4a34-b192-ee4eebbd3545@github.com>

On Fri, 25 Jul 2025 09:39:15 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Or @shipilev may be able to review?
>
>> Or @shipilev may be able to review?
> 
> (slowly turns in his home office chair and stares curiously at his home server that produces jcstress binaries). Meh, I am on the fence on referencing 3rd party personal websites like mine. So I would defer to others if they are good with it.

Thanks @shipilev

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26369#issuecomment-3127326780

From jsjolen at openjdk.org  Mon Jul 28 14:20:08 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 28 Jul 2025 14:20:08 GMT
Subject: RFR: 8364198: NMT should have a better corruption message
Message-ID: <2gaFx0GXVxXsaqIcZwbhlhc4haQcFdHZBLhnfi_YgVk=.4d4f3f29-421f-4bf9-8f65-3b080e7f6474@github.com>

Hi,

When NMT detects a memory corruption it outputs "NMT corruption" and some helpful metadata. I'd like to change the prefix to "NMT has detected a memory corruption bug.". I want to do this because the old message sounds like it is NMT itself that has become corrupted, which is not what's happened. Instead, it should be clear that NMT has helped detect a bug stemming from somewhere else. This is meant to help avoid someone misunderstanding the message.

-------------

Commit messages:
 - Make NMT message friendlier

Changes: https://git.openjdk.org/jdk/pull/26507/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26507&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364198
  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/26507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26507/head:pull/26507

PR: https://git.openjdk.org/jdk/pull/26507

From jsjolen at openjdk.org  Mon Jul 28 14:20:08 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 28 Jul 2025 14:20:08 GMT
Subject: RFR: 8364198: NMT should have a better corruption message
In-Reply-To: <2gaFx0GXVxXsaqIcZwbhlhc4haQcFdHZBLhnfi_YgVk=.4d4f3f29-421f-4bf9-8f65-3b080e7f6474@github.com>
References: <2gaFx0GXVxXsaqIcZwbhlhc4haQcFdHZBLhnfi_YgVk=.4d4f3f29-421f-4bf9-8f65-3b080e7f6474@github.com>
Message-ID: <MCdUr-6t3LOqUDhLjiJIdcKuHXhCH7s4N_BEBAd_u4c=.ec13038e-4be6-4c1e-9a1b-d03eb6349e44@github.com>

On Mon, 28 Jul 2025 14:14:26 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> When NMT detects a memory corruption it outputs "NMT corruption" and some helpful metadata. I'd like to change the prefix to "NMT has detected a memory corruption bug.". I want to do this because the old message sounds like it is NMT itself that has become corrupted, which is not what's happened. Instead, it should be clear that NMT has helped detect a bug stemming from somewhere else. This is meant to help avoid someone misunderstanding the message.

@tstuefe , what do you think about this?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26507#issuecomment-3127448720

From ayang at openjdk.org  Mon Jul 28 14:22:00 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 28 Jul 2025 14:22:00 GMT
Subject: RFR: 8364019: Add alignment precondition to Universe::reserve_heap
In-Reply-To: <zn5eMLyIaYJS2ooP8Os28aLCk_t8ZaDhxPGF6PLw7Qo=.b720b417-1433-493c-9ccf-1246e0dbd15e@github.com>
References: <zn5eMLyIaYJS2ooP8Os28aLCk_t8ZaDhxPGF6PLw7Qo=.b720b417-1433-493c-9ccf-1246e0dbd15e@github.com>
Message-ID: <FaCJf1ln2G1nYqedc2VwQlgPraB7U8l0SvRnzpB4H_g=.92ea7254-11f1-40ab-9d53-26d40a8e46c6@github.com>

On Thu, 24 Jul 2025 10:06:17 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple converting a redundant `align_up` to assert.
> 
> Test: tier1

Thanks for review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26456#issuecomment-3127448977

From ayang at openjdk.org  Mon Jul 28 14:22:00 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 28 Jul 2025 14:22:00 GMT
Subject: Integrated: 8364019: Add alignment precondition to
 Universe::reserve_heap
In-Reply-To: <zn5eMLyIaYJS2ooP8Os28aLCk_t8ZaDhxPGF6PLw7Qo=.b720b417-1433-493c-9ccf-1246e0dbd15e@github.com>
References: <zn5eMLyIaYJS2ooP8Os28aLCk_t8ZaDhxPGF6PLw7Qo=.b720b417-1433-493c-9ccf-1246e0dbd15e@github.com>
Message-ID: <FhlqD8SA4V0a6Vi2Pc3Zj2-OQkJU_uWgazPP9v0HgsQ=.c3ca73a4-3371-4662-a526-90d5cefdad85@github.com>

On Thu, 24 Jul 2025 10:06:17 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple converting a redundant `align_up` to assert.
> 
> Test: tier1

This pull request has now been integrated.

Changeset: 70ebb5e8
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/70ebb5e8c9d99e17e84da798fed01626bc7f9ea0
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8364019: Add alignment precondition to Universe::reserve_heap

Reviewed-by: tschatzl, jsikstro

-------------

PR: https://git.openjdk.org/jdk/pull/26456

From tschatzl at openjdk.org  Mon Jul 28 14:50:36 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 28 Jul 2025 14:50:36 GMT
Subject: RFR: 8364197: G1: Sort G1 mutex locks by name and group them together
Message-ID: <PhF7nBjpjmPAJ7UHSyfYJbdRouucweAcwMmYk_pnctg=.694ddeb5-7eb6-404a-aaed-35bdce957bb1@github.com>

Hi all,

  please review this change to put together G1 mutex definitions/declarations and sort them. That makes it easier for me to verify changes in that area.

Testing: local compilation

Thanks,
  Thomas

-------------

Commit messages:
 - 8364197

Changes: https://git.openjdk.org/jdk/pull/26508/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26508&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364197
  Stats: 44 lines in 2 files changed: 21 ins; 15 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/26508.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26508/head:pull/26508

PR: https://git.openjdk.org/jdk/pull/26508

From coleenp at openjdk.org  Mon Jul 28 15:49:53 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 28 Jul 2025 15:49:53 GMT
Subject: RFR: 8364197: G1: Sort G1 mutex locks by name and group them
 together
In-Reply-To: <PhF7nBjpjmPAJ7UHSyfYJbdRouucweAcwMmYk_pnctg=.694ddeb5-7eb6-404a-aaed-35bdce957bb1@github.com>
References: <PhF7nBjpjmPAJ7UHSyfYJbdRouucweAcwMmYk_pnctg=.694ddeb5-7eb6-404a-aaed-35bdce957bb1@github.com>
Message-ID: <iZZdzRgqEmIkgveURxxQQ1FVHTN5sEkhAvL_aMcBV54=.0179dfbb-7a07-4131-acb3-605ea043deb4@github.com>

On Mon, 28 Jul 2025 14:44:20 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change to put together G1 mutex definitions/declarations and sort them. That makes it easier for me to verify changes in that area.
> 
> Testing: local compilation
> 
> Thanks,
>   Thomas

That looks nice.  Looks like you alphabetized them also.  You could have ordered the ones in mutexLocker.cpp by rank.

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26508#pullrequestreview-3063467239

From shade at openjdk.org  Mon Jul 28 17:48:53 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 28 Jul 2025 17:48:53 GMT
Subject: RFR: 8364198: NMT should have a better corruption message
In-Reply-To: <2gaFx0GXVxXsaqIcZwbhlhc4haQcFdHZBLhnfi_YgVk=.4d4f3f29-421f-4bf9-8f65-3b080e7f6474@github.com>
References: <2gaFx0GXVxXsaqIcZwbhlhc4haQcFdHZBLhnfi_YgVk=.4d4f3f29-421f-4bf9-8f65-3b080e7f6474@github.com>
Message-ID: <DKTtWjEYinHT4-fOx__Edi2pUgXnPxlo21h0-HyT1BQ=.f07bf773-3315-450b-b9a1-82f9acd17336@github.com>

On Mon, 28 Jul 2025 14:14:26 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> When NMT detects a memory corruption it outputs "NMT corruption" and some helpful metadata. I'd like to change the prefix to "NMT has detected a memory corruption bug.". I want to do this because the old message sounds like it is NMT itself that has become corrupted, which is not what's happened. Instead, it should be clear that NMT has helped detect a bug stemming from somewhere else. This is meant to help avoid someone misunderstanding the message.

Makes sense. I am not sure about the "bug" part. Also, do we care about mentioning NMT at all? I think a useful template is GCC malloc:


*** glibc detected *** malloc(): memory corruption


Something like below would do, I think.


NMT detected memory corruption. Block at ...


...or even:


Memory corruption detected. Block at ...

-------------

PR Review: https://git.openjdk.org/jdk/pull/26507#pullrequestreview-3063991444

From duke at openjdk.org  Mon Jul 28 20:10:05 2025
From: duke at openjdk.org (Alice Pellegrini)
Date: Mon, 28 Jul 2025 20:10:05 GMT
Subject: RFR: 8356438: Update OutputAnalyzer to optionally print process
 output as it happens [v2]
In-Reply-To: <J_G9wvyovxUuO0JdFMqnD7jvqUflEglF5L7qqvBc6-w=.e0def3d2-eb40-4167-b304-143f9d4c615d@github.com>
References: <cP-uMB2zwWrYPT2EOx-VpGAIaLjQY1YgkdQwehdjfo8=.d99ee1cf-5f91-40de-a5d1-fe6b762d1673@github.com>
 <J_G9wvyovxUuO0JdFMqnD7jvqUflEglF5L7qqvBc6-w=.e0def3d2-eb40-4167-b304-143f9d4c615d@github.com>
Message-ID: <s6SK1ACAOIlxZROm0d0-EXIVox-NGYA8PLbOmKE1mdI=.f6bcac25-9091-4e28-87c6-6de583690b88@github.com>

On Thu, 5 Jun 2025 09:36:37 GMT, Alice Pellegrini <duke at openjdk.org> wrote:

>> The implemented solution modifies the `OutputBuffer` implementation instead of the `OutputAnalyzer` implementation.
>> This is because the **OutputBuffer implementation which handles processes** (LazyOutputBuffer) starts a thread in its constructor, so we would need to add a strange additional constructor parameter to the `OutputBuffer.of(Process, Charset)` static method, while the printing through to stdout (and stderr) only makes sense for LazyOutputBuffer.
>> 
>> I believe changing the config option from `outputanalyzer.verbose` to `output buffer.verbose` would make it cleaner, and avoid referencing the OutputAnalyzer in the OutputBuffer implementation.
>
> Alice Pellegrini has updated the pull request with a new target base 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 8356438-outputanalyzer-optional-print
>  - Update test/lib/jdk/test/lib/process/OutputBuffer.java
>    
>    Co-authored-by: Chen Liang <liach at openjdk.org>
>  - Initial working solution

The need will be addressed in the affected test.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25587#issuecomment-3129311861

From duke at openjdk.org  Mon Jul 28 20:10:06 2025
From: duke at openjdk.org (Alice Pellegrini)
Date: Mon, 28 Jul 2025 20:10:06 GMT
Subject: Withdrawn: 8356438: Update OutputAnalyzer to optionally print process
 output as it happens
In-Reply-To: <cP-uMB2zwWrYPT2EOx-VpGAIaLjQY1YgkdQwehdjfo8=.d99ee1cf-5f91-40de-a5d1-fe6b762d1673@github.com>
References: <cP-uMB2zwWrYPT2EOx-VpGAIaLjQY1YgkdQwehdjfo8=.d99ee1cf-5f91-40de-a5d1-fe6b762d1673@github.com>
Message-ID: <iKap2LXfdXyhxtKUneQUWqgGNdRrMHK9K4QA0SSQjms=.c40228f4-ff39-4d8b-af21-090717734035@github.com>

On Mon, 2 Jun 2025 11:54:10 GMT, Alice Pellegrini <duke at openjdk.org> wrote:

> The implemented solution modifies the `OutputBuffer` implementation instead of the `OutputAnalyzer` implementation.
> This is because the **OutputBuffer implementation which handles processes** (LazyOutputBuffer) starts a thread in its constructor, so we would need to add a strange additional constructor parameter to the `OutputBuffer.of(Process, Charset)` static method, while the printing through to stdout (and stderr) only makes sense for LazyOutputBuffer.
> 
> I believe changing the config option from `outputanalyzer.verbose` to `output buffer.verbose` would make it cleaner, and avoid referencing the OutputAnalyzer in the OutputBuffer implementation.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/25587

From ccheung at openjdk.org  Mon Jul 28 22:29:04 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Mon, 28 Jul 2025 22:29:04 GMT
Subject: RFR: 8363928: Specifying AOTCacheOutput with a blank path causes the
 JVM to crash
Message-ID: <aYq_GTj91owLZ902BIGenpfhhOFweiN1GcwIXU_NgHA=.55df3532-64a8-4ccd-bba1-a3b2e0d5acc8@github.com>

Added a constraint check for the `AOTCacheOutput` option in order to avoid VM crash in case an empty value is specified.
Update `aotFlags/AOTFlags.java` to test this scenario.

Testing: ran test locally on linux-x64.

-------------

Commit messages:
 - 8363928: Specifying AOTCacheOutput with a blank path causes the JVM to crash

Changes: https://git.openjdk.org/jdk/pull/26518/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26518&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8363928
  Stats: 11 lines in 4 files changed: 11 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26518.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26518/head:pull/26518

PR: https://git.openjdk.org/jdk/pull/26518

From kvn at openjdk.org  Mon Jul 28 23:38:53 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 28 Jul 2025 23:38:53 GMT
Subject: RFR: 8363928: Specifying AOTCacheOutput with a blank path causes
 the JVM to crash
In-Reply-To: <aYq_GTj91owLZ902BIGenpfhhOFweiN1GcwIXU_NgHA=.55df3532-64a8-4ccd-bba1-a3b2e0d5acc8@github.com>
References: <aYq_GTj91owLZ902BIGenpfhhOFweiN1GcwIXU_NgHA=.55df3532-64a8-4ccd-bba1-a3b2e0d5acc8@github.com>
Message-ID: <gAuiSucJnmMAmWB9IKWu3V5ysYwCLGK4-4iv7dsJSu8=.d294294a-5a57-49ce-9f36-8ae7ce09f586@github.com>

On Mon, 28 Jul 2025 22:23:36 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Added a constraint check for the `AOTCacheOutput` option in order to avoid VM crash in case an empty value is specified.
> Update `aotFlags/AOTFlags.java` to test this scenario.
> 
> Testing: ran test locally on linux-x64.

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26518#pullrequestreview-3064823266

From kvn at openjdk.org  Mon Jul 28 23:58:38 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 28 Jul 2025 23:58:38 GMT
Subject: RFR: 8364198: NMT should have a better corruption message
In-Reply-To: <2gaFx0GXVxXsaqIcZwbhlhc4haQcFdHZBLhnfi_YgVk=.4d4f3f29-421f-4bf9-8f65-3b080e7f6474@github.com>
References: <2gaFx0GXVxXsaqIcZwbhlhc4haQcFdHZBLhnfi_YgVk=.4d4f3f29-421f-4bf9-8f65-3b080e7f6474@github.com>
Message-ID: <ALMvvInVKUh-dKTHEZFMmekmtb_Qz2MoUMkg9ilMQBM=.86922261-3a19-457d-bbba-23cc9f0670ca@github.com>

On Mon, 28 Jul 2025 14:14:26 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> When NMT detects a memory corruption it outputs "NMT corruption" and some helpful metadata. I'd like to change the prefix to "NMT has detected a memory corruption bug.". I want to do this because the old message sounds like it is NMT itself that has become corrupted, which is not what's happened. Instead, it should be clear that NMT has helped detect a bug stemming from somewhere else. This is meant to help avoid someone misunderstanding the message.

Looks good.

@jdksjolen is it possible to give more information in output? For example, where address is located: metaspace, code cache, arena, some C heap allocations (Does NMT keep track of such?).

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26507#pullrequestreview-3064829586

From kvn at openjdk.org  Mon Jul 28 23:58:44 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 28 Jul 2025 23:58:44 GMT
Subject: RFR: 8364198: NMT should have a better corruption message
In-Reply-To: <DKTtWjEYinHT4-fOx__Edi2pUgXnPxlo21h0-HyT1BQ=.f07bf773-3315-450b-b9a1-82f9acd17336@github.com>
References: <2gaFx0GXVxXsaqIcZwbhlhc4haQcFdHZBLhnfi_YgVk=.4d4f3f29-421f-4bf9-8f65-3b080e7f6474@github.com>
 <DKTtWjEYinHT4-fOx__Edi2pUgXnPxlo21h0-HyT1BQ=.f07bf773-3315-450b-b9a1-82f9acd17336@github.com>
Message-ID: <Li05I_tdqkqNEjxfDyRnDQI09hUBZt7O_O_dgAdJsZw=.b0d1d663-9fa0-4616-b1b6-34923471ba10@github.com>

On Mon, 28 Jul 2025 17:45:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Also, do we care about mentioning NMT at all? 

We have to give credits to NMT for detecting an issue.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26507#issuecomment-3130134565

From dholmes at openjdk.org  Mon Jul 28 23:59:21 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 28 Jul 2025 23:59:21 GMT
Subject: RFR: 8364106: Include java.runtime.version in thread dump output
Message-ID: <lLL3n-lmOFiJnJ712idlTecQfw2mkVqeXTMLuVNv_j4=.f40bbb37-85e5-4fc5-8129-77320b6ebd79@github.com>

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-3 (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

-------------

Commit messages:
 - Fixed formatting
 - 8364106: Include java.runtime.version in thread dump output

Changes: https://git.openjdk.org/jdk/pull/26520/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26520&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364106
  Stats: 15 lines in 1 file changed: 14 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26520.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26520/head:pull/26520

PR: https://git.openjdk.org/jdk/pull/26520

From stuefe at openjdk.org  Tue Jul 29 05:30:57 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 29 Jul 2025 05:30:57 GMT
Subject: RFR: 8364198: NMT should have a better corruption message
In-Reply-To: <2gaFx0GXVxXsaqIcZwbhlhc4haQcFdHZBLhnfi_YgVk=.4d4f3f29-421f-4bf9-8f65-3b080e7f6474@github.com>
References: <2gaFx0GXVxXsaqIcZwbhlhc4haQcFdHZBLhnfi_YgVk=.4d4f3f29-421f-4bf9-8f65-3b080e7f6474@github.com>
Message-ID: <2n5Q1tFSApaOvFwF7aW2qL04WYnvkoBpN4DxVflhwJ0=.7753c88a-5bc0-45d8-bde5-bcfc5b633bff@github.com>

On Mon, 28 Jul 2025 14:14:26 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> When NMT detects a memory corruption it outputs "NMT corruption" and some helpful metadata. I'd like to change the prefix to "NMT has detected a memory corruption bug.". I want to do this because the old message sounds like it is NMT itself that has become corrupted, which is not what's happened. Instead, it should be clear that NMT has helped detect a bug stemming from somewhere else. This is meant to help avoid someone misunderstanding the message.

Thanks. That makes a lot of sense. I was getting sick of defending NMT :)

-------------

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26507#pullrequestreview-3065525407

From stuefe at openjdk.org  Tue Jul 29 05:41:55 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 29 Jul 2025 05:41:55 GMT
Subject: RFR: 8364198: NMT should have a better corruption message
In-Reply-To: <ALMvvInVKUh-dKTHEZFMmekmtb_Qz2MoUMkg9ilMQBM=.86922261-3a19-457d-bbba-23cc9f0670ca@github.com>
References: <2gaFx0GXVxXsaqIcZwbhlhc4haQcFdHZBLhnfi_YgVk=.4d4f3f29-421f-4bf9-8f65-3b080e7f6474@github.com>
 <ALMvvInVKUh-dKTHEZFMmekmtb_Qz2MoUMkg9ilMQBM=.86922261-3a19-457d-bbba-23cc9f0670ca@github.com>
Message-ID: <pG5wUQFKd4FZsocy_3SFcikbUx0z3lWHHupfEYXZefc=.0ff07519-dc37-40d0-8ad6-daba70209bf3@github.com>

On Mon, 28 Jul 2025 23:42:44 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Looks good.
> 
> @jdksjolen is it possible to give more information in output? For example, where address is located: metaspace, code cache, arena, some C heap allocations (Does NMT keep track of such?).

Note that we already print out hexdump and whatnot for the broken block. 

Getting more information, for mmaped areas, should be relatively simple now that we have changed the mmap backend to use an interval tree (VMATree). We should be able to search for memory areas very quickly. But this malloc header change affects malloc only.

Here, we could write out the allocation call stack of the broken block if we run with NMT detail mode - the malloc header contains a reference to the malloc site table entry. This only works if the malloc header is uncorrupted enough (and can be safely recognized as such). If it ain't, we would need to track memory ranges for malloc using the new VMATree, but that opens a much bigger can of worms (malloc performance, concurrency etc).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26507#issuecomment-3130765260

From iklam at openjdk.org  Tue Jul 29 05:41:55 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 29 Jul 2025 05:41:55 GMT
Subject: RFR: 8363928: Specifying AOTCacheOutput with a blank path causes
 the JVM to crash
In-Reply-To: <aYq_GTj91owLZ902BIGenpfhhOFweiN1GcwIXU_NgHA=.55df3532-64a8-4ccd-bba1-a3b2e0d5acc8@github.com>
References: <aYq_GTj91owLZ902BIGenpfhhOFweiN1GcwIXU_NgHA=.55df3532-64a8-4ccd-bba1-a3b2e0d5acc8@github.com>
Message-ID: <ZdmVavvTZWgtYIaxwVbRKYDii1W4bwEVRlNppY65DnY=.e67e99ea-ce39-4cf7-8242-93b2ec33999b@github.com>

On Mon, 28 Jul 2025 22:23:36 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Added a constraint check for the `AOTCacheOutput` option in order to avoid VM crash in case an empty value is specified.
> Update `aotFlags/AOTFlags.java` to test this scenario.
> 
> Testing: ran test locally on linux-x64.

LGTM

-------------

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26518#pullrequestreview-3065558026

From dholmes at openjdk.org  Tue Jul 29 06:37:54 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 29 Jul 2025 06:37:54 GMT
Subject: RFR: 8364235: Fix for JDK-8361447 breaks the alignment requirements
 for GuardedMemory
Message-ID: <2NMVt2xW6-rTS7vQPJ8fPkfabrTPiugEqGf4KlttYSo=.46b5d9f5-90b3-44b9-b3db-f139672145dc@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

-------------

Commit messages:
 - 8364235: Fix for JDK-8361447 breaks the alignment requirements for GuardedMemory

Changes: https://git.openjdk.org/jdk/pull/26524/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26524&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364235
  Stats: 11 lines in 1 file changed: 9 ins; 2 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 jsjolen at openjdk.org  Tue Jul 29 06:42:56 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 29 Jul 2025 06:42:56 GMT
Subject: RFR: 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: <jhssYVyTL7Q7M70V_ounR46Bpy6so4glOka63R7kshM=.9b254a86-9477-4c41-a088-9277b4177e42@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

LGTM, but I'd prefer to do it the way I suggest.

src/hotspot/share/memory/guardedMemory.hpp line 144:

> 142: 
> 143:     void* padding; // Ensures 16-byte alignment
> 144: 

The right thing to do is to do:

```c++
class alignas(16) GuardHeader : Guard {
  // NO void* padding
};

src/hotspot/share/memory/guardedMemory.hpp line 164:

> 162: 
> 163:   static_assert(sizeof(GuardHeader) % 16 == 0, "GuardHeader must be 16-byte aligned");
> 164: 

`static_assert(alignof(GuardHeader) == 16, "GuardHeader must be 16-byte aligned");`

-------------

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26524#pullrequestreview-3065732073
PR Review Comment: https://git.openjdk.org/jdk/pull/26524#discussion_r2238686296
PR Review Comment: https://git.openjdk.org/jdk/pull/26524#discussion_r2238686915

From kbarrett at openjdk.org  Tue Jul 29 06:47:55 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 29 Jul 2025 06:47:55 GMT
Subject: RFR: 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: <oxasmf4lzJcK7irfsPn0PHF__rF3oTfK8c5BIBNOZI0=.95fa61fe-f92f-4f5f-af6a-cdd54e64f6c2@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

src/hotspot/share/memory/guardedMemory.hpp line 143:

> 141:     friend class GuardedMemory;
> 142: 
> 143:     void* padding; // Ensures 16-byte alignment

I'm not sure how this does anything for alignment, other than perhaps because the ABI happens to make
the desired alignment happen somehow.

But why not use `alignas(16)` somewhere?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26524#discussion_r2238697795

From dholmes at openjdk.org  Tue Jul 29 07:08:59 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 29 Jul 2025 07:08:59 GMT
Subject: RFR: 8306324: StopThread results in thread being marked as
 interrupted, leading to unexpected InterruptedException [v3]
In-Reply-To: <AWpHV3UvP_0bCI8pMBUQtIsYrmGcXLY8j9_KubieCHg=.2e793179-2c88-41d3-8672-dfa57e5625a0@github.com>
References: <sDAklD-arV33IpWiJwMkwUfNPMAmsr5cgboU4y0hjhk=.192cd7e5-f2a2-4b5c-83a9-5111bf1926ec@github.com>
 <AWpHV3UvP_0bCI8pMBUQtIsYrmGcXLY8j9_KubieCHg=.2e793179-2c88-41d3-8672-dfa57e5625a0@github.com>
Message-ID: <rJ6j7EgxbKBYoeE4XT9qABEMeE1CwVR7GNIdQcQAoNQ=.85308e5a-41d0-4f8e-a7e9-3a1b45ef5fb7@github.com>

On Mon, 28 Jul 2025 06:57:42 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:
> 
>   review: implemented a suggestion: do not set interrupt flag at all

FWIW the way this used to work in the past for the blocking methods is that "stop" would install the pending-async-exception and interrupt the thread to unblock it. The thread doing a sleep/park/wait would see that it was interrupted and proceed to throw `InterruptedException`, and in the process clear the interrupt flag (as per the spec). But when we attempted to return to Java from `_thread_in_vm` we would see the pending-async-exception and replaced the pending IE with the the async one (ThreadDeath usually).

But if the thread was not blocked in an interruptible blocking method then it would have the interrupt state set. So we basically have always behaved this way and I'm wondering what is driving us to change this behaviour now?

FWIW I think the fix is reasonable to avoid messing with the interrupt flag, but the fact Alan seems to want the "stop" to not interrupt at all makes me wonder how stop would then actually work?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26365#issuecomment-3130992741

From tschatzl at openjdk.org  Tue Jul 29 07:42:54 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 29 Jul 2025 07:42:54 GMT
Subject: RFR: 8364197: G1: Sort G1 mutex locks by name and group them
 together
In-Reply-To: <iZZdzRgqEmIkgveURxxQQ1FVHTN5sEkhAvL_aMcBV54=.0179dfbb-7a07-4131-acb3-605ea043deb4@github.com>
References: <PhF7nBjpjmPAJ7UHSyfYJbdRouucweAcwMmYk_pnctg=.694ddeb5-7eb6-404a-aaed-35bdce957bb1@github.com>
 <iZZdzRgqEmIkgveURxxQQ1FVHTN5sEkhAvL_aMcBV54=.0179dfbb-7a07-4131-acb3-605ea043deb4@github.com>
Message-ID: <U9o67jFbyPMPtbmZ7QddOiGWoKXd0aXmdy8WmE2pOP8=.8f5089bf-49a8-4325-aaf1-f3a96772e5ad@github.com>

On Mon, 28 Jul 2025 15:47:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> That looks nice. Looks like you alphabetized them also. You could have ordered the ones in mutexLocker.cpp by rank.

Which hunk do you mean? The one assigning the `nullptr` or the initialization using the macros? For the latter, all other locks were separated based on the macro (`MUTEX_DEFN`/`MUTEX_DEFL`) so I kept that.

Other than that I prefer alphabetic ordering. Makes it easier to see which one is missing if you forget one....

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26508#issuecomment-3131100081

From dholmes at openjdk.org  Tue Jul 29 07:50:53 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 29 Jul 2025 07:50:53 GMT
Subject: RFR: 8364235: Fix for JDK-8361447 breaks the alignment
 requirements for GuardedMemory
In-Reply-To: <oxasmf4lzJcK7irfsPn0PHF__rF3oTfK8c5BIBNOZI0=.95fa61fe-f92f-4f5f-af6a-cdd54e64f6c2@github.com>
References: <2NMVt2xW6-rTS7vQPJ8fPkfabrTPiugEqGf4KlttYSo=.46b5d9f5-90b3-44b9-b3db-f139672145dc@github.com>
 <oxasmf4lzJcK7irfsPn0PHF__rF3oTfK8c5BIBNOZI0=.95fa61fe-f92f-4f5f-af6a-cdd54e64f6c2@github.com>
Message-ID: <7Vqj1iuod1IJmEyR9r_BSHOkngc-g9_GSUWAbKe-4Us=.6f7c16a0-feeb-4496-9300-dad6201be5d6@github.com>

On Tue, 29 Jul 2025 06:45:01 GMT, Kim Barrett <kbarrett 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
>
> src/hotspot/share/memory/guardedMemory.hpp line 143:
> 
>> 141:     friend class GuardedMemory;
>> 142: 
>> 143:     void* padding; // Ensures 16-byte alignment
> 
> I'm not sure how this does anything for alignment, other than perhaps because the ABI happens to make
> the desired alignment happen somehow.
> 
> But why not use `alignas(16)` somewhere?

It ensures that the offset of the user-data ptr within the `GuardedMemory` object, places the user-data on a suitably aligned boundary.

I tried:

  alignas(16) u_char* _base_addr;

but that did not work. Perhaps I am using it wrong?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26524#discussion_r2238857847

From dholmes at openjdk.org  Tue Jul 29 07:50:55 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 29 Jul 2025 07:50:55 GMT
Subject: RFR: 8364235: Fix for JDK-8361447 breaks the alignment
 requirements for GuardedMemory
In-Reply-To: <jhssYVyTL7Q7M70V_ounR46Bpy6so4glOka63R7kshM=.9b254a86-9477-4c41-a088-9277b4177e42@github.com>
References: <2NMVt2xW6-rTS7vQPJ8fPkfabrTPiugEqGf4KlttYSo=.46b5d9f5-90b3-44b9-b3db-f139672145dc@github.com>
 <jhssYVyTL7Q7M70V_ounR46Bpy6so4glOka63R7kshM=.9b254a86-9477-4c41-a088-9277b4177e42@github.com>
Message-ID: <25J-d9i828o188kIFPGaQluKaDyzYbwGAvh_ms-wSso=.9fb4c6eb-758b-4b48-913b-5b84eb7145a7@github.com>

On Tue, 29 Jul 2025 06:38:59 GMT, Johan Sj?len <jsjolen 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
>
> src/hotspot/share/memory/guardedMemory.hpp line 144:
> 
>> 142: 
>> 143:     void* padding; // Ensures 16-byte alignment
>> 144: 
> 
> The right thing to do is to do:
> 
> ```c++
> class alignas(16) GuardHeader : Guard {
>   // NO void* padding
> };

That aligns the `GuardHeader` (something already done by `malloc`) but doesn't guarantee the alignment of the `_base_addr` field which is the user-data ptr.

> src/hotspot/share/memory/guardedMemory.hpp line 164:
> 
>> 162: 
>> 163:   static_assert(sizeof(GuardHeader) % 16 == 0, "GuardHeader must be 16-byte aligned");
>> 164: 
> 
> `static_assert(alignof(GuardHeader) == 16, "GuardHeader must be 16-byte aligned");`

Again `malloc` already aligned the `GuardHeader`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26524#discussion_r2238860572
PR Review Comment: https://git.openjdk.org/jdk/pull/26524#discussion_r2238861674

From dholmes at openjdk.org  Tue Jul 29 08:09:52 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 29 Jul 2025 08:09:52 GMT
Subject: RFR: 8364235: Fix for JDK-8361447 breaks the alignment
 requirements for GuardedMemory [v2]
In-Reply-To: <2NMVt2xW6-rTS7vQPJ8fPkfabrTPiugEqGf4KlttYSo=.46b5d9f5-90b3-44b9-b3db-f139672145dc@github.com>
References: <2NMVt2xW6-rTS7vQPJ8fPkfabrTPiugEqGf4KlttYSo=.46b5d9f5-90b3-44b9-b3db-f139672145dc@github.com>
Message-ID: <F0WAvSIePri0xNAFr_qmwCkJDetoQ6X70cTTC3CXit4=.7bc251c1-fe4a-48e8-962d-58105266ca53@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:

  Correct comments as per reviewer comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26524/files
  - new: https://git.openjdk.org/jdk/pull/26524/files/a7502d8c..4d252e3c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26524&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26524&range=00-01

  Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 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 coffeys at openjdk.org  Tue Jul 29 08:22:55 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 29 Jul 2025 08:22:55 GMT
Subject: RFR: 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: <3mln0FWxBVHljWJixRL0M-hk9aD1Wf65iGKlfiK3dOo=.080c6cf8-d629-430c-9ca0-9f997f5701ac@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-3 (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. ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26520#issuecomment-3131228690

From aboldtch at openjdk.org  Tue Jul 29 08:27:04 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 29 Jul 2025 08:27:04 GMT
Subject: RFR: 8364235: Fix for JDK-8361447 breaks the alignment
 requirements for GuardedMemory [v2]
In-Reply-To: <7Vqj1iuod1IJmEyR9r_BSHOkngc-g9_GSUWAbKe-4Us=.6f7c16a0-feeb-4496-9300-dad6201be5d6@github.com>
References: <2NMVt2xW6-rTS7vQPJ8fPkfabrTPiugEqGf4KlttYSo=.46b5d9f5-90b3-44b9-b3db-f139672145dc@github.com>
 <oxasmf4lzJcK7irfsPn0PHF__rF3oTfK8c5BIBNOZI0=.95fa61fe-f92f-4f5f-af6a-cdd54e64f6c2@github.com>
 <7Vqj1iuod1IJmEyR9r_BSHOkngc-g9_GSUWAbKe-4Us=.6f7c16a0-feeb-4496-9300-dad6201be5d6@github.com>
Message-ID: <2TwjPcp38oR6cGGwKkofLjsNgWKTYP2u6F72whsbhCw=.0463a182-11a0-462b-bf6f-6f14a2ddedd1@github.com>

On Tue, 29 Jul 2025 07:47:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/memory/guardedMemory.hpp line 143:
>> 
>>> 141:     friend class GuardedMemory;
>>> 142: 
>>> 143:     void* padding; // Ensures 16-byte alignment
>> 
>> I'm not sure how this does anything for alignment, other than perhaps because the ABI happens to make
>> the desired alignment happen somehow.
>> 
>> But why not use `alignas(16)` somewhere?
>
> It ensures that the offset of the user-data ptr within the `GuardedMemory` object, places the user-data on a suitably aligned boundary.
> 
> I tried:
> 
>   alignas(16) u_char* _base_addr;
> 
> but that did not work. Perhaps I am using it wrong?

That would simply align the "guarded memory handle"'s field (on the stack) not the value inside. It is the value we put in there that needs to be aligned.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26524#discussion_r2238954307

From aboldtch at openjdk.org  Tue Jul 29 08:33:05 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 29 Jul 2025 08:33:05 GMT
Subject: RFR: 8364235: Fix for JDK-8361447 breaks the alignment
 requirements for GuardedMemory [v2]
In-Reply-To: <25J-d9i828o188kIFPGaQluKaDyzYbwGAvh_ms-wSso=.9fb4c6eb-758b-4b48-913b-5b84eb7145a7@github.com>
References: <2NMVt2xW6-rTS7vQPJ8fPkfabrTPiugEqGf4KlttYSo=.46b5d9f5-90b3-44b9-b3db-f139672145dc@github.com>
 <jhssYVyTL7Q7M70V_ounR46Bpy6so4glOka63R7kshM=.9b254a86-9477-4c41-a088-9277b4177e42@github.com>
 <25J-d9i828o188kIFPGaQluKaDyzYbwGAvh_ms-wSso=.9fb4c6eb-758b-4b48-913b-5b84eb7145a7@github.com>
Message-ID: <Ooa50jrJKw13hfwcx3M1t4h3v3CSxE7S0_4iy73I4hs=.819023a7-d86a-4e42-b1af-c0820d80dbda@github.com>

On Tue, 29 Jul 2025 07:48:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/memory/guardedMemory.hpp line 144:
>> 
>>> 142: 
>>> 143:     void* padding; // Ensures 16-byte alignment
>>> 144: 
>> 
>> The right thing to do is to do:
>> 
>> ```c++
>> class alignas(16) GuardHeader : Guard {
>>   // NO void* padding
>> };
>
> That aligns the `GuardHeader` (something already done by `malloc`) but doesn't guarantee the alignment of the `_base_addr` field which is the user-data ptr.

Forcing `alignas(16)` alignment on `GuardHeader` directly implies `sizeof(GuardHeader) % 16 == 0` without the need of a padding field. And C++ will be required to insert 8 byte padding after `_tag2`. 

If it is important that the padding occurs after the header and before the size keep the current solution.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26524#discussion_r2238965325

From aboldtch at openjdk.org  Tue Jul 29 08:33:04 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 29 Jul 2025 08:33:04 GMT
Subject: RFR: 8364235: Fix for JDK-8361447 breaks the alignment
 requirements for GuardedMemory [v2]
In-Reply-To: <F0WAvSIePri0xNAFr_qmwCkJDetoQ6X70cTTC3CXit4=.7bc251c1-fe4a-48e8-962d-58105266ca53@github.com>
References: <2NMVt2xW6-rTS7vQPJ8fPkfabrTPiugEqGf4KlttYSo=.46b5d9f5-90b3-44b9-b3db-f139672145dc@github.com>
 <F0WAvSIePri0xNAFr_qmwCkJDetoQ6X70cTTC3CXit4=.7bc251c1-fe4a-48e8-962d-58105266ca53@github.com>
Message-ID: <T9C4Mjiw1paqOoA87oSneAbmZSStE4RgkrtA35MKckk=.75a71738-2197-4e8f-a7af-f1addb2b38d2@github.com>

On Tue, 29 Jul 2025 08:09:52 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:
> 
>   Correct comments as per reviewer comments

src/hotspot/share/memory/guardedMemory.hpp line 45:

> 43:  * |------------------------------------------------------------
> 44:  * |base_addr          | 0xABABABABABABABAB   | Head guard     |
> 45:  * |+16                | padding              | For alignment  |

Is `+sizeof(Guard)` or `+GUARD_SIZE` an alternative to `+16`. 16 is a little out of the blue for me.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26524#discussion_r2238973802

From jsjolen at openjdk.org  Tue Jul 29 08:40:01 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 29 Jul 2025 08:40:01 GMT
Subject: RFR: 8364198: NMT should have a better corruption message
In-Reply-To: <DKTtWjEYinHT4-fOx__Edi2pUgXnPxlo21h0-HyT1BQ=.f07bf773-3315-450b-b9a1-82f9acd17336@github.com>
References: <2gaFx0GXVxXsaqIcZwbhlhc4haQcFdHZBLhnfi_YgVk=.4d4f3f29-421f-4bf9-8f65-3b080e7f6474@github.com>
 <DKTtWjEYinHT4-fOx__Edi2pUgXnPxlo21h0-HyT1BQ=.f07bf773-3315-450b-b9a1-82f9acd17336@github.com>
Message-ID: <ZtZteexzp9sdNrUfUixN27A7P2qEFk6UK4zik7OmJPU=.52838bd2-7d2e-4d06-9ec5-f016af1627cd@github.com>

On Mon, 28 Jul 2025 17:45:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Makes sense. I am not sure about the "bug" part. Also, do we care about mentioning NMT at all? I think a useful template is GCC malloc:
> 
> ```
> *** glibc detected *** malloc(): memory corruption
> ```
> 
> Something like below would do, I think.
> 
> ```
> NMT detected memory corruption. Block at ...
> ```
> 
> ...or even:
> 
> ```
> Memory corruption detected. Block at ...
> ```

I wrote it like this to really hammer home the point, I felt it was more unambiguous.

I'm integrating it as-is, thank you all for your comments.

@vnkozlov, it's unfortunately hard to add more info as the header (that which is 'corrupted') is also where we store what kind of allocation it is.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26507#issuecomment-3131297131

From jsjolen at openjdk.org  Tue Jul 29 08:40:02 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 29 Jul 2025 08:40:02 GMT
Subject: Integrated: 8364198: NMT should have a better corruption message
In-Reply-To: <2gaFx0GXVxXsaqIcZwbhlhc4haQcFdHZBLhnfi_YgVk=.4d4f3f29-421f-4bf9-8f65-3b080e7f6474@github.com>
References: <2gaFx0GXVxXsaqIcZwbhlhc4haQcFdHZBLhnfi_YgVk=.4d4f3f29-421f-4bf9-8f65-3b080e7f6474@github.com>
Message-ID: <jGgQMV6izyF6cmW0eycDPVg7g28iNl6E1uxEzwaR6DM=.b823a6bb-2637-4c48-9ec7-9457d0706e4a@github.com>

On Mon, 28 Jul 2025 14:14:26 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> When NMT detects a memory corruption it outputs "NMT corruption" and some helpful metadata. I'd like to change the prefix to "NMT has detected a memory corruption bug.". I want to do this because the old message sounds like it is NMT itself that has become corrupted, which is not what's happened. Instead, it should be clear that NMT has helped detect a bug stemming from somewhere else. This is meant to help avoid someone misunderstanding the message.

This pull request has now been integrated.

Changeset: 2202156a
Author:    Johan Sj?len <jsjolen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2202156acc78d7d9ec128f8df5c09fcdff83697c
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8364198: NMT should have a better corruption message

Reviewed-by: kvn, stuefe

-------------

PR: https://git.openjdk.org/jdk/pull/26507

From stuefe at openjdk.org  Tue Jul 29 09:21:59 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 29 Jul 2025 09:21:59 GMT
Subject: RFR: 8364198: NMT should have a better corruption message
In-Reply-To: <Li05I_tdqkqNEjxfDyRnDQI09hUBZt7O_O_dgAdJsZw=.b0d1d663-9fa0-4616-b1b6-34923471ba10@github.com>
References: <2gaFx0GXVxXsaqIcZwbhlhc4haQcFdHZBLhnfi_YgVk=.4d4f3f29-421f-4bf9-8f65-3b080e7f6474@github.com>
 <DKTtWjEYinHT4-fOx__Edi2pUgXnPxlo21h0-HyT1BQ=.f07bf773-3315-450b-b9a1-82f9acd17336@github.com>
 <Li05I_tdqkqNEjxfDyRnDQI09hUBZt7O_O_dgAdJsZw=.b0d1d663-9fa0-4616-b1b6-34923471ba10@github.com>
Message-ID: <dXF3KXwAb2VsttDacFKMGEBu7IcVciGDjVBOhF_JpxE=.d6700317-d2e5-457d-a181-24d9bc1c6511@github.com>

On Mon, 28 Jul 2025 23:40:18 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Makes sense. I am not sure about the "bug" part. Also, do we care about mentioning NMT at all? I think a useful template is GCC malloc:
>> 
>> 
>> *** glibc detected *** malloc(): memory corruption
>> 
>> 
>> Something like below would do, I think.
>> 
>> 
>> NMT detected memory corruption. Block at ...
>> 
>> 
>> ...or even:
>> 
>> 
>> Memory corruption detected. Block at ...
>
>> Also, do we care about mentioning NMT at all? 
> 
> We have to give credits to NMT for detecting an issue.

> @vnkozlov, it's unfortunately hard to add more info as the header (that which is 'corrupted') is also where we store what kind of allocation it is.

Well, you could do it on a best-effort base.

- if there is an overwrite of the block footer (which is the much more likely scenario with buffer overflows), the header could still be correct. Extract the _mst_marker from the header, decode the malloc site table entry, then print out the associated stack trace.
- even if the header is corrupted, one could still read the _mst_marker. If it seems to identify a malloc site table entry, one could print that one's stack trace with the addition "we think the original allocation may have originated from:"

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26507#issuecomment-3131479757

From sspitsyn at openjdk.org  Tue Jul 29 09:45:11 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 29 Jul 2025 09:45:11 GMT
Subject: RFR: 8306324: StopThread results in thread being marked as
 interrupted, leading to unexpected InterruptedException [v4]
In-Reply-To: <sDAklD-arV33IpWiJwMkwUfNPMAmsr5cgboU4y0hjhk=.192cd7e5-f2a2-4b5c-83a9-5111bf1926ec@github.com>
References: <sDAklD-arV33IpWiJwMkwUfNPMAmsr5cgboU4y0hjhk=.192cd7e5-f2a2-4b5c-83a9-5111bf1926ec@github.com>
Message-ID: <dQefU7FTIWnL55lbx_5HesATraYtDsbcDg-4nQcvG34=.a87af660-4fc3-4a7d-bc60-c7d6081dc395@github.com>

> 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:

  review: remove tweak from JavaThread::sleep_nanos

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26365/files
  - new: https://git.openjdk.org/jdk/pull/26365/files/fde881f0..1f7b67c3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26365&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26365&range=02-03

  Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26365.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26365/head:pull/26365

PR: https://git.openjdk.org/jdk/pull/26365

From sspitsyn at openjdk.org  Tue Jul 29 09:45:11 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 29 Jul 2025 09:45:11 GMT
Subject: RFR: 8306324: StopThread results in thread being marked as
 interrupted, leading to unexpected InterruptedException [v3]
In-Reply-To: <2faiO8M1kDjt63rmbo8EjfXOxA5ggxcpHp4S3Ok3S2A=.b85da477-0c63-47a2-aac8-988254863fd4@github.com>
References: <sDAklD-arV33IpWiJwMkwUfNPMAmsr5cgboU4y0hjhk=.192cd7e5-f2a2-4b5c-83a9-5111bf1926ec@github.com>
 <AWpHV3UvP_0bCI8pMBUQtIsYrmGcXLY8j9_KubieCHg=.2e793179-2c88-41d3-8672-dfa57e5625a0@github.com>
 <t112h-njRQZ9ruMkt5c6Sd7fYH-5UVmCu6F5GwpdAQQ=.889537f2-866c-4120-9169-33758fb8a2b4@github.com>
 <2faiO8M1kDjt63rmbo8EjfXOxA5ggxcpHp4S3Ok3S2A=.b85da477-0c63-47a2-aac8-988254863fd4@github.com>
Message-ID: <wHcLHdFoUrCgyAt4h2wKwX2WGA-Wi9vI34d6hTzrd1I=.126398f8-a40e-45cd-bbc2-03aecbf354bf@github.com>

On Mon, 28 Jul 2025 10:50:23 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> It would put the onus on the debugger to interrupt, which I think is the right thing to do. it would remove the interrupt from JavaThread::install_async_exception and would mean no change to JavaThread::sleep_nanos.

Thank you for the suggestion. I've tested it and found that a couple of tests are failed including one JCK test. So, at a minimum this approach is going to be more complicated, it would require a supporting JDI update, consultation with the IDE vendors, CSR and a release note. Also, I kind of share the David's concern above. So, I'm thinking if it is okay to separate this effort from the current fix. I can file an enhancement if it makes sense and worth it.
As I see, the tweak in `JavaThread::sleep_nanos()` is not really needed, so I'll remove it now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26365#issuecomment-3131566270

From duke at openjdk.org  Tue Jul 29 09:48:11 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 29 Jul 2025 09:48:11 GMT
Subject: RFR: 8363949: Incorrect jtreg header in MonitorWithDeadObjectTest.java
Message-ID: <aL9b5b-GATHLDCakKIztuhSCKTK9bE3EKPmiZtUNO4g=.677e7a91-7f18-4d40-8650-4367a1bbae33@github.com>

Hi, please consider the following changes:

the mentioned test fails if run standalone with the following error: 
Error: Not a test or directory containing tests: runtime/Monitor/MonitorWithDeadObjectTest.java

The order of jtreg tags is not correct, to make it pass standalone it is sufficient to put @test first in each test.

-------------

Commit messages:
 - 8363949: Placed test annotation before requires annotation in the MonitorWithDeadObjectTest

Changes: https://git.openjdk.org/jdk/pull/26527/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26527&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8363949
  Stats: 6 lines in 1 file changed: 3 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26527.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26527/head:pull/26527

PR: https://git.openjdk.org/jdk/pull/26527

From stefank at openjdk.org  Tue Jul 29 09:53:57 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 29 Jul 2025 09:53:57 GMT
Subject: RFR: 8363949: Incorrect jtreg header in
 MonitorWithDeadObjectTest.java
In-Reply-To: <aL9b5b-GATHLDCakKIztuhSCKTK9bE3EKPmiZtUNO4g=.677e7a91-7f18-4d40-8650-4367a1bbae33@github.com>
References: <aL9b5b-GATHLDCakKIztuhSCKTK9bE3EKPmiZtUNO4g=.677e7a91-7f18-4d40-8650-4367a1bbae33@github.com>
Message-ID: <jx0V0nfNSCmPcyIfiNcQNIRqOWuMXrklAhpc_PGiiLY=.f4d7cf46-d512-49d2-9cbf-ca310c09a1f5@github.com>

On Tue, 29 Jul 2025 09:18:40 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> the mentioned test fails if run standalone with the following error: 
> Error: Not a test or directory containing tests: runtime/Monitor/MonitorWithDeadObjectTest.java
> 
> The order of jtreg tags is not correct, to make it pass standalone it is sufficient to put @test first in each test.

Marked as reviewed by stefank (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26527#pullrequestreview-3066616815

From stefank at openjdk.org  Tue Jul 29 09:57:54 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 29 Jul 2025 09:57:54 GMT
Subject: RFR: 8363949: Incorrect jtreg header in
 MonitorWithDeadObjectTest.java
In-Reply-To: <aL9b5b-GATHLDCakKIztuhSCKTK9bE3EKPmiZtUNO4g=.677e7a91-7f18-4d40-8650-4367a1bbae33@github.com>
References: <aL9b5b-GATHLDCakKIztuhSCKTK9bE3EKPmiZtUNO4g=.677e7a91-7f18-4d40-8650-4367a1bbae33@github.com>
Message-ID: <qg-txjUgVp6bYkvW8XzTYs4DxwcIvMEyvt95L1_zzgc=.7ad4a623-ffc1-4922-9fd7-b1786edf753a@github.com>

On Tue, 29 Jul 2025 09:18:40 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> the mentioned test fails if run standalone with the following error: 
> Error: Not a test or directory containing tests: runtime/Monitor/MonitorWithDeadObjectTest.java
> 
> The order of jtreg tags is not correct, to make it pass standalone it is sufficient to put @test first in each test.

I think the JBS issue summary needs to be updated to reflect that it is the `@requires` tag that is problematic and not the `@bug` tag.

I'm also wondering if there's anything we need to do to our test infrastructure to find these issues automatically? As I understand it, this was only found because @TobiHartmann went and manually tried to find issues like this. Maybe @lmesnik has some insights here or knows someone who deals with this part of the test infra.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26527#issuecomment-3131650470

From alanb at openjdk.org  Tue Jul 29 10:02:57 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 29 Jul 2025 10:02:57 GMT
Subject: RFR: 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: <hzFui5EE04P9mowAQlS6NUyrTF3Lkl_xv08A8SieZz4=.4f97952f-9f1c-4889-b420-5e2396e46f95@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-3 (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

src/hotspot/share/runtime/threads.cpp line 1383:

> 1381:                                 VM_Version::printable_jdk_debug_level() : "";
> 1382: 
> 1383:   st->print_cr("                 JRE version: %s%s%s (%s) (%sbuild %s)", runtime_name,

The move to modules in JDK 9 blurred the historical distinction between what we used to know as the JDK and JRE. So we don't use "JRE" anymore. I think it would be okay to say JDK or runtime version here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26520#discussion_r2239248907

From duke at openjdk.org  Tue Jul 29 11:09:53 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 29 Jul 2025 11:09:53 GMT
Subject: RFR: 8363949: Incorrect jtreg header in
 MonitorWithDeadObjectTest.java
In-Reply-To: <qg-txjUgVp6bYkvW8XzTYs4DxwcIvMEyvt95L1_zzgc=.7ad4a623-ffc1-4922-9fd7-b1786edf753a@github.com>
References: <aL9b5b-GATHLDCakKIztuhSCKTK9bE3EKPmiZtUNO4g=.677e7a91-7f18-4d40-8650-4367a1bbae33@github.com>
 <qg-txjUgVp6bYkvW8XzTYs4DxwcIvMEyvt95L1_zzgc=.7ad4a623-ffc1-4922-9fd7-b1786edf753a@github.com>
Message-ID: <QkvR83tptHItWUnShmDmBOCvDkCHfhSYBJqLVCFef2A=.f56b003e-2d66-4510-89d8-9ebc3e8d80bd@github.com>

On Tue, 29 Jul 2025 09:55:38 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> I think the JBS issue summary needs to be updated to reflect that it is the `@requires` tag that is problematic and not the `@bug` tag.

I updated the JBS issue as suggested.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26527#issuecomment-3131951534

From ktakakuri at openjdk.org  Tue Jul 29 12:28:58 2025
From: ktakakuri at openjdk.org (Kazuhisa Takakuri)
Date: Tue, 29 Jul 2025 12:28:58 GMT
Subject: RFR: 8349288: runtime/os/windows/TestAvailableProcessors.java
 fails on localized Windows platform [v7]
In-Reply-To: <jz3-bfvHYZrwmrcM7KzLJqhOUDwY98kHmMgut-_6KBQ=.c30ddaa5-d351-4f09-ad20-ab22a2fe32c9@github.com>
References: <Ra31Q95DukIesp9Ivxsw4AYNOtqAm3JIeMSCtOHuTIM=.abd6dea4-4628-4983-9b38-642c21e792b5@github.com>
 <20TRpLYXGNXfc4ppAfGQysrYBJWBwV4iK4tPTk8MiTM=.08e71de3-4b53-4735-9742-9e87ef05bfa4@github.com>
 <jz3-bfvHYZrwmrcM7KzLJqhOUDwY98kHmMgut-_6KBQ=.c30ddaa5-d351-4f09-ad20-ab22a2fe32c9@github.com>
Message-ID: <o9pKrVhf909oCFF5L0A8Fq8j5LOB6ingujH5AYfEr4s=.f45e846d-736b-477d-9a7c-0dcbe0c7095c@github.com>

On Thu, 8 May 2025 06:43:18 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> 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
>
> Re-running through our testing.

@dholmes-ora I have made some fixes, so please review it again.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23536#issuecomment-3132267985

From stuefe at openjdk.org  Tue Jul 29 13:32:07 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 29 Jul 2025 13:32:07 GMT
Subject: RFR: 8364202: CDS without G1 gives build error in slowdebug,
 asserts in fastdebug
Message-ID: <vQzRGUAI2aKft5togIby3x_8YwEGBZFQEoBhl4osT3E=.40dbcf0b-e9ca-489c-b7e2-3e346c945d67@github.com>

This patch fixes two problems:

- when building without INCLUDE_CDS_JAVA_HEAP (disabling G1 at configure, or building 32-bit), we get a linker error in slowdebug.
- when running with CDS, but without INCLUDE_CDS_JAVA_HEAP, we initialize CompressedKlassPointers via the "lenient" route where we allow optimized encoding base choice. This can lead to zero-based encoding, in which case we should not attempt to setup a protection zone at the start of the encoding range.

-------------

Commit messages:
 - redo assertion fix
 - fix build error
 - Fix assert when running with CDS but without heap

Changes: https://git.openjdk.org/jdk/pull/26523/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26523&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364202
  Stats: 19 lines in 5 files changed: 12 ins; 2 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/26523.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26523/head:pull/26523

PR: https://git.openjdk.org/jdk/pull/26523

From stuefe at openjdk.org  Tue Jul 29 13:32:07 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 29 Jul 2025 13:32:07 GMT
Subject: RFR: 8364202: CDS without G1 gives build error in slowdebug,
 asserts in fastdebug
In-Reply-To: <vQzRGUAI2aKft5togIby3x_8YwEGBZFQEoBhl4osT3E=.40dbcf0b-e9ca-489c-b7e2-3e346c945d67@github.com>
References: <vQzRGUAI2aKft5togIby3x_8YwEGBZFQEoBhl4osT3E=.40dbcf0b-e9ca-489c-b7e2-3e346c945d67@github.com>
Message-ID: <XTesevHZWyu4vhyOFemrdjGFh3tld-vNUpSWGd_zxUA=.c37790b6-2570-4f48-b6af-1a61b64f5c49@github.com>

On Tue, 29 Jul 2025 06:14:46 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> This patch fixes two problems:
> 
> - when building without INCLUDE_CDS_JAVA_HEAP (disabling G1 at configure, or building 32-bit), we get a linker error in slowdebug.
> - when running with CDS, but without INCLUDE_CDS_JAVA_HEAP, we initialize CompressedKlassPointers via the "lenient" route where we allow optimized encoding base choice. This can lead to zero-based encoding, in which case we should not attempt to setup a protection zone at the start of the encoding range.

NMT gtest failure on windows unrelated.

@tschatzl , @iklam , could you please review?

src/hotspot/share/cds/metaspaceShared.cpp line 1605:

> 1603: 
> 1604:       // Set up compressed Klass pointer encoding: the encoding range must
> 1605:       //  cover both archive and class space.

Reviewer Notes, changes in CDS explained:
- Line 1626: fix bug by only establishing a protection zone if the encoding base points to the start of the archive after setup (aka we don't end up running zero-based encoding)
- Lines 1619, 1623: We only have two cases: We either need to dictate the encoding (if CDS heap area exists), in which case the encoding base must be the start of the mappings. Or, we let the JVM choose freely, in which case we end up with base=zero if possible, base=mapping start otherwise. Assert both cases.
- Line 1606: When initializing `CompressedKlassPointers`, we should always feed in the mapping start for klass range start. This has no practical consequences, but it is cleaner and more consistent with the CDS=off path. I also added a comment to compressedKlass.hpp in that regard.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26523#issuecomment-3132551317
PR Comment: https://git.openjdk.org/jdk/pull/26523#issuecomment-3132552458
PR Review Comment: https://git.openjdk.org/jdk/pull/26523#discussion_r2239324348

From alanb at openjdk.org  Tue Jul 29 15:25:55 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 29 Jul 2025 15:25:55 GMT
Subject: RFR: 8306324: StopThread results in thread being marked as
 interrupted, leading to unexpected InterruptedException [v3]
In-Reply-To: <rJ6j7EgxbKBYoeE4XT9qABEMeE1CwVR7GNIdQcQAoNQ=.85308e5a-41d0-4f8e-a7e9-3a1b45ef5fb7@github.com>
References: <sDAklD-arV33IpWiJwMkwUfNPMAmsr5cgboU4y0hjhk=.192cd7e5-f2a2-4b5c-83a9-5111bf1926ec@github.com>
 <AWpHV3UvP_0bCI8pMBUQtIsYrmGcXLY8j9_KubieCHg=.2e793179-2c88-41d3-8672-dfa57e5625a0@github.com>
 <rJ6j7EgxbKBYoeE4XT9qABEMeE1CwVR7GNIdQcQAoNQ=.85308e5a-41d0-4f8e-a7e9-3a1b45ef5fb7@github.com>
Message-ID: <N3dkD7c4GS4NAd69ZZhkd6b2PTCeCqzAgSvwLFn5Q8o=.226045e8-f10f-4df5-83b2-770e136a8d14@github.com>

On Tue, 29 Jul 2025 07:06:21 GMT, David Holmes <dholmes at openjdk.org> wrote:

> FWIW I think the fix is reasonable to avoid messing with the interrupt flag, but the fact Alan seems to want the "stop" to not interrupt at all makes me wonder how stop would then actually work?

I don't think the current proposed change (which drop's setting the interrupt flag in install_async_exception) will cause a target thread blocked in sleep to wakeup. A target thread blocked in JavaThread::sleep_nanos will wakeup from park_nanos but will just park again with the remaining time. I assume this is the test failures that Serguei mentions.

As you noted, the bug is the side effect of setting the interrupt status of a target thread that is not in a InterruptedException throwing method. It may be that the "Throw Exception" feature in debuggers isn't used much and nobody has noticed.

If we can reach out the debugger/IDE maintainers then we might be able to a bit more insight into how this is used. In some debuggers you can't use "Throw Exception" (= StopThread) when the target is blocked in the native code or in the VM. When suspended at a breakpoint then it looks like IntelliJ calls both ThreadReference::stop and ThreadReference::interrupt but I can't tell if the latter is conditional or not.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26365#issuecomment-3133023220

From kvn at openjdk.org  Tue Jul 29 16:09:00 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 29 Jul 2025 16:09:00 GMT
Subject: RFR: 8364198: NMT should have a better corruption message
In-Reply-To: <ZtZteexzp9sdNrUfUixN27A7P2qEFk6UK4zik7OmJPU=.52838bd2-7d2e-4d06-9ec5-f016af1627cd@github.com>
References: <2gaFx0GXVxXsaqIcZwbhlhc4haQcFdHZBLhnfi_YgVk=.4d4f3f29-421f-4bf9-8f65-3b080e7f6474@github.com>
 <DKTtWjEYinHT4-fOx__Edi2pUgXnPxlo21h0-HyT1BQ=.f07bf773-3315-450b-b9a1-82f9acd17336@github.com>
 <ZtZteexzp9sdNrUfUixN27A7P2qEFk6UK4zik7OmJPU=.52838bd2-7d2e-4d06-9ec5-f016af1627cd@github.com>
Message-ID: <ZwMebXJgLxx2V9bP-Umtgy4FEU3BC2nBJnDk1IaggII=.f6394704-be08-4b76-a1d0-5a1e542274ae@github.com>

On Tue, 29 Jul 2025 08:36:59 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Makes sense. I am not sure about the "bug" part. Also, do we care about mentioning NMT at all? I think a useful template is GCC malloc:
>> 
>> 
>> *** glibc detected *** malloc(): memory corruption
>> 
>> 
>> Something like below would do, I think.
>> 
>> 
>> NMT detected memory corruption. Block at ...
>> 
>> 
>> ...or even:
>> 
>> 
>> Memory corruption detected. Block at ...
>
>> Makes sense. I am not sure about the "bug" part. Also, do we care about mentioning NMT at all? I think a useful template is GCC malloc:
>> 
>> ```
>> *** glibc detected *** malloc(): memory corruption
>> ```
>> 
>> Something like below would do, I think.
>> 
>> ```
>> NMT detected memory corruption. Block at ...
>> ```
>> 
>> ...or even:
>> 
>> ```
>> Memory corruption detected. Block at ...
>> ```
> 
> I wrote it like this to really hammer home the point, I felt it was more unambiguous.
> 
> I'm integrating it as-is, thank you all for your comments.
> 
> @vnkozlov, it's unfortunately hard to add more info as the header (that which is 'corrupted') is also where we store what kind of allocation it is.

>> @jdksjolen is it possible to give more information in output? For example, where address is located: metaspace, code cache, arena, some C heap allocations (Does NMT keep track of such?).

> Note that we already print out hexdump and whatnot for the broken block.

I did not know that. But looking on log in [JDK-8361382](https://bugs.openjdk.org/browse/JDK-8361382) I see it now. 

Should we include this into hs_err file instead as we do for code crash?

Is it possible to collect and provide information for the block preceding current block when it's header is damaged?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26507#issuecomment-3133171659

From ccheung at openjdk.org  Tue Jul 29 17:46:02 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 29 Jul 2025 17:46:02 GMT
Subject: RFR: 8363928: Specifying AOTCacheOutput with a blank path causes
 the JVM to crash
In-Reply-To: <gAuiSucJnmMAmWB9IKWu3V5ysYwCLGK4-4iv7dsJSu8=.d294294a-5a57-49ce-9f36-8ae7ce09f586@github.com>
References: <aYq_GTj91owLZ902BIGenpfhhOFweiN1GcwIXU_NgHA=.55df3532-64a8-4ccd-bba1-a3b2e0d5acc8@github.com>
 <gAuiSucJnmMAmWB9IKWu3V5ysYwCLGK4-4iv7dsJSu8=.d294294a-5a57-49ce-9f36-8ae7ce09f586@github.com>
Message-ID: <aVE36KcyHV1ZiTWWgZJPwsGlgDXDPgStD1qdUBhnM-I=.e320098c-fbee-461f-95d5-b1647ad4d2da@github.com>

On Mon, 28 Jul 2025 23:35:59 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Added a constraint check for the `AOTCacheOutput` option in order to avoid VM crash in case an empty value is specified.
>> Update `aotFlags/AOTFlags.java` to test this scenario.
>> 
>> Testing: ran test locally on linux-x64.
>
> Good.

Thanks @vnkozlov @iklam for the review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26518#issuecomment-3133453780

From ccheung at openjdk.org  Tue Jul 29 17:46:03 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 29 Jul 2025 17:46:03 GMT
Subject: Integrated: 8363928: Specifying AOTCacheOutput with a blank path
 causes the JVM to crash
In-Reply-To: <aYq_GTj91owLZ902BIGenpfhhOFweiN1GcwIXU_NgHA=.55df3532-64a8-4ccd-bba1-a3b2e0d5acc8@github.com>
References: <aYq_GTj91owLZ902BIGenpfhhOFweiN1GcwIXU_NgHA=.55df3532-64a8-4ccd-bba1-a3b2e0d5acc8@github.com>
Message-ID: <GoFebnorXamMewvywb1WBJFxMyxAf9E8EUfwhIL_l6o=.dd50dfb6-ba5d-4a4a-94d1-c83de80eece8@github.com>

On Mon, 28 Jul 2025 22:23:36 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Added a constraint check for the `AOTCacheOutput` option in order to avoid VM crash in case an empty value is specified.
> Update `aotFlags/AOTFlags.java` to test this scenario.
> 
> Testing: ran test locally on linux-x64.

This pull request has now been integrated.

Changeset: ea754316
Author:    Calvin Cheung <ccheung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ea754316fd6d691a701dfb4bc921ea8c92dc5dd4
Stats:     11 lines in 4 files changed: 11 ins; 0 del; 0 mod

8363928: Specifying AOTCacheOutput with a blank path causes the JVM to crash

Reviewed-by: kvn, iklam

-------------

PR: https://git.openjdk.org/jdk/pull/26518

From coleenp at openjdk.org  Tue Jul 29 19:41:59 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 29 Jul 2025 19:41:59 GMT
Subject: RFR: 8363949: Incorrect jtreg header in
 MonitorWithDeadObjectTest.java
In-Reply-To: <aL9b5b-GATHLDCakKIztuhSCKTK9bE3EKPmiZtUNO4g=.677e7a91-7f18-4d40-8650-4367a1bbae33@github.com>
References: <aL9b5b-GATHLDCakKIztuhSCKTK9bE3EKPmiZtUNO4g=.677e7a91-7f18-4d40-8650-4367a1bbae33@github.com>
Message-ID: <Zja3HcwftyvpESrnSv554J3XUWfWusJnErYVqYDN5K4=.fb1a9842-f126-4ce9-b839-8837fde8f541@github.com>

On Tue, 29 Jul 2025 09:18:40 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> the mentioned test fails if run standalone with the following error: 
> Error: Not a test or directory containing tests: runtime/Monitor/MonitorWithDeadObjectTest.java
> 
> The order of jtreg tags is not correct, to make it pass standalone it is sufficient to put @test first in each test.

Looks good!

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26527#pullrequestreview-3068916697

From ccheung at openjdk.org  Tue Jul 29 20:54:53 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 29 Jul 2025 20:54:53 GMT
Subject: RFR: 8364202: CDS without G1 gives build error in slowdebug,
 asserts in fastdebug
In-Reply-To: <vQzRGUAI2aKft5togIby3x_8YwEGBZFQEoBhl4osT3E=.40dbcf0b-e9ca-489c-b7e2-3e346c945d67@github.com>
References: <vQzRGUAI2aKft5togIby3x_8YwEGBZFQEoBhl4osT3E=.40dbcf0b-e9ca-489c-b7e2-3e346c945d67@github.com>
Message-ID: <lKEtyXUxTCnZxloK4F8d95c97x26Jy9Ubi-FtJAgUfo=.8d050f79-19d0-44ab-a58a-403b2f4e8c18@github.com>

On Tue, 29 Jul 2025 06:14:46 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> This patch fixes two problems:
> 
> - when building without INCLUDE_CDS_JAVA_HEAP (disabling G1 at configure, or building 32-bit), we get a linker error in slowdebug.
> - when running with CDS, but without INCLUDE_CDS_JAVA_HEAP, we initialize CompressedKlassPointers via the "lenient" route where we allow optimized encoding base choice. This can lead to zero-based encoding, in which case we should not attempt to setup a protection zone at the start of the encoding range.

Looks good.
I did some sanity testing (tiers 1 - 3, and zero build). No failures.

-------------

Marked as reviewed by ccheung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26523#pullrequestreview-3069192720

From iklam at openjdk.org  Tue Jul 29 21:19:53 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 29 Jul 2025 21:19:53 GMT
Subject: RFR: 8364202: CDS without G1 gives build error in slowdebug,
 asserts in fastdebug
In-Reply-To: <vQzRGUAI2aKft5togIby3x_8YwEGBZFQEoBhl4osT3E=.40dbcf0b-e9ca-489c-b7e2-3e346c945d67@github.com>
References: <vQzRGUAI2aKft5togIby3x_8YwEGBZFQEoBhl4osT3E=.40dbcf0b-e9ca-489c-b7e2-3e346c945d67@github.com>
Message-ID: <wpuPCuxzpYerk3htmQFSOpAqU6lfFagOLHz1DXmGW9U=.da03799f-01b5-468d-988b-527c0a2cc991@github.com>

On Tue, 29 Jul 2025 06:14:46 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> This patch fixes two problems:
> 
> - when building without INCLUDE_CDS_JAVA_HEAP (disabling G1 at configure, or building 32-bit), we get a linker error in slowdebug.
> - when running with CDS, but without INCLUDE_CDS_JAVA_HEAP, we initialize CompressedKlassPointers via the "lenient" route where we allow optimized encoding base choice. This can lead to zero-based encoding, in which case we should not attempt to setup a protection zone at the start of the encoding range.

LGTM

-------------

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26523#pullrequestreview-3069249805

From dholmes at openjdk.org  Tue Jul 29 23:47:54 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 29 Jul 2025 23:47:54 GMT
Subject: RFR: 8306324: StopThread results in thread being marked as
 interrupted, leading to unexpected InterruptedException [v3]
In-Reply-To: <N3dkD7c4GS4NAd69ZZhkd6b2PTCeCqzAgSvwLFn5Q8o=.226045e8-f10f-4df5-83b2-770e136a8d14@github.com>
References: <sDAklD-arV33IpWiJwMkwUfNPMAmsr5cgboU4y0hjhk=.192cd7e5-f2a2-4b5c-83a9-5111bf1926ec@github.com>
 <AWpHV3UvP_0bCI8pMBUQtIsYrmGcXLY8j9_KubieCHg=.2e793179-2c88-41d3-8672-dfa57e5625a0@github.com>
 <rJ6j7EgxbKBYoeE4XT9qABEMeE1CwVR7GNIdQcQAoNQ=.85308e5a-41d0-4f8e-a7e9-3a1b45ef5fb7@github.com>
 <N3dkD7c4GS4NAd69ZZhkd6b2PTCeCqzAgSvwLFn5Q8o=.226045e8-f10f-4df5-83b2-770e136a8d14@github.com>
Message-ID: <nCQ9rXDFA60ciIsZSDSgROuUJTf_jFI1tXeuIopT8SI=.5e9197e7-895e-40d8-b513-191452675e09@github.com>

On Tue, 29 Jul 2025 15:23:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I don't think the current proposed change (which drop's setting the interrupt flag in install_async_exception) will cause a target thread blocked in sleep to wakeup. A target thread blocked in JavaThread::sleep_nanos will wakeup from park_nanos but will just park again with the remaining time. I assume this is the test failures that Serguei mentions.

Right but that is why there was a tweak to `sleep_nanos`:

if (has_async_exception_condition()) {
      return false;
}

But that tweak has now been removed hence this fix no longer maintains the functionality of `StopThread`.

And again this issue of leaving the interrupt flag set has existed "forever".

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26365#issuecomment-3134402208

From stuefe at openjdk.org  Wed Jul 30 04:58:00 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 30 Jul 2025 04:58:00 GMT
Subject: RFR: 8364202: CDS without G1 gives build error in slowdebug,
 asserts in fastdebug
In-Reply-To: <wpuPCuxzpYerk3htmQFSOpAqU6lfFagOLHz1DXmGW9U=.da03799f-01b5-468d-988b-527c0a2cc991@github.com>
References: <vQzRGUAI2aKft5togIby3x_8YwEGBZFQEoBhl4osT3E=.40dbcf0b-e9ca-489c-b7e2-3e346c945d67@github.com>
 <wpuPCuxzpYerk3htmQFSOpAqU6lfFagOLHz1DXmGW9U=.da03799f-01b5-468d-988b-527c0a2cc991@github.com>
Message-ID: <x6jNjkpOqgrEGB_8WiTLRdF-xQi_GwJvEATdOek5cP4=.3f969256-e634-4865-80e7-3af0dc4744e5@github.com>

On Tue, 29 Jul 2025 21:17:44 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This patch fixes two problems:
>> 
>> - when building without INCLUDE_CDS_JAVA_HEAP (disabling G1 at configure, or building 32-bit), we get a linker error in slowdebug.
>> - when running with CDS, but without INCLUDE_CDS_JAVA_HEAP, we initialize CompressedKlassPointers via the "lenient" route where we allow optimized encoding base choice. This can lead to zero-based encoding, in which case we should not attempt to setup a protection zone at the start of the encoding range.
>
> LGTM

Thanks @iklam and @calvinccheung

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26523#issuecomment-3134848377

From stuefe at openjdk.org  Wed Jul 30 04:58:01 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 30 Jul 2025 04:58:01 GMT
Subject: Integrated: 8364202: CDS without G1 gives build error in slowdebug,
 asserts in fastdebug
In-Reply-To: <vQzRGUAI2aKft5togIby3x_8YwEGBZFQEoBhl4osT3E=.40dbcf0b-e9ca-489c-b7e2-3e346c945d67@github.com>
References: <vQzRGUAI2aKft5togIby3x_8YwEGBZFQEoBhl4osT3E=.40dbcf0b-e9ca-489c-b7e2-3e346c945d67@github.com>
Message-ID: <omNWNC1K6127jxEojBnXrFlRjnJf5rxExWkwpNCHlWE=.d2680b07-25ac-4be9-93da-75755edb3c7b@github.com>

On Tue, 29 Jul 2025 06:14:46 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> This patch fixes two problems:
> 
> - when building without INCLUDE_CDS_JAVA_HEAP (disabling G1 at configure, or building 32-bit), we get a linker error in slowdebug.
> - when running with CDS, but without INCLUDE_CDS_JAVA_HEAP, we initialize CompressedKlassPointers via the "lenient" route where we allow optimized encoding base choice. This can lead to zero-based encoding, in which case we should not attempt to setup a protection zone at the start of the encoding range.

This pull request has now been integrated.

Changeset: 164d0368
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/164d0368f608ff43789d2abd96cd0f5449458122
Stats:     19 lines in 5 files changed: 12 ins; 2 del; 5 mod

8364202: CDS without G1 gives build error in slowdebug, asserts in fastdebug

Reviewed-by: ccheung, iklam

-------------

PR: https://git.openjdk.org/jdk/pull/26523

From dholmes at openjdk.org  Wed Jul 30 05:20:38 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 30 Jul 2025 05:20:38 GMT
Subject: RFR: 8364314: java_lang_Thread::get_thread_status fails assert(base !=
 nullptr) failed: Invalid base
Message-ID: <ceYO3eEp5YWA4T5oDbw3Tqv0f-GUh2xTBqxjuWdsJl8=.f594db6c-8064-4a7a-a467-75ba86e950bd@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

-------------

Commit messages:
 - 8364314: java_lang_Thread::get_thread_status fails assert(base != nullptr) failed: Invalid base

Changes: https://git.openjdk.org/jdk/pull/26544/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26544&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364314
  Stats: 9 lines in 1 file changed: 8 ins; 1 del; 0 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  Wed Jul 30 06:16:59 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 30 Jul 2025 06:16:59 GMT
Subject: RFR: 8364235: Fix for JDK-8361447 breaks the alignment
 requirements for GuardedMemory [v2]
In-Reply-To: <Ooa50jrJKw13hfwcx3M1t4h3v3CSxE7S0_4iy73I4hs=.819023a7-d86a-4e42-b1af-c0820d80dbda@github.com>
References: <2NMVt2xW6-rTS7vQPJ8fPkfabrTPiugEqGf4KlttYSo=.46b5d9f5-90b3-44b9-b3db-f139672145dc@github.com>
 <jhssYVyTL7Q7M70V_ounR46Bpy6so4glOka63R7kshM=.9b254a86-9477-4c41-a088-9277b4177e42@github.com>
 <25J-d9i828o188kIFPGaQluKaDyzYbwGAvh_ms-wSso=.9fb4c6eb-758b-4b48-913b-5b84eb7145a7@github.com>
 <Ooa50jrJKw13hfwcx3M1t4h3v3CSxE7S0_4iy73I4hs=.819023a7-d86a-4e42-b1af-c0820d80dbda@github.com>
Message-ID: <xj3FDXSmK_8pdGTWTkoLcEHtMe59Ujmz6rOck7ZuT0g=.37581c93-1a1c-44d8-9ee1-2d65e2c90db8@github.com>

On Tue, 29 Jul 2025 08:27:46 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> That aligns the `GuardHeader` (something already done by `malloc`) but doesn't guarantee the alignment of the `_base_addr` field which is the user-data ptr.
>
> Forcing `alignas(16)` alignment on `GuardHeader` directly implies `sizeof(GuardHeader) % 16 == 0` without the need of a padding field. And C++ will be required to insert 8 byte padding after `_tag2`. 
> 
> If it is important that the padding occurs after the header and before the size keep the current solution.

I am surprised that `alignas` will pad in that way - I only expected it to align the initial placement. The docs do not seem to describe this, though the example implicitly does (as `sizeof(sse_t)` yields 32 not 16) [1]

I will test this out.

[1] http://en.cppreference.com/w/cpp/language/alignas.html

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26524#discussion_r2241630455

From dholmes at openjdk.org  Wed Jul 30 06:24:39 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 30 Jul 2025 06:24:39 GMT
Subject: RFR: 8364314: java_lang_Thread::get_thread_status fails
 assert(base != nullptr) failed: Invalid base [v2]
In-Reply-To: <ceYO3eEp5YWA4T5oDbw3Tqv0f-GUh2xTBqxjuWdsJl8=.f594db6c-8064-4a7a-a467-75ba86e950bd@github.com>
References: <ceYO3eEp5YWA4T5oDbw3Tqv0f-GUh2xTBqxjuWdsJl8=.f594db6c-8064-4a7a-a467-75ba86e950bd@github.com>
Message-ID: <zEmmXnncIeBkHA6lfZBkOK3F19mjG1ExCad990UzhHM=.2c35f1aa-03c2-4588-8f4e-ce655c56256c@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 with a new target base 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

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26544/files
  - new: https://git.openjdk.org/jdk/pull/26544/files/ad497497..610186f1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26544&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26544&range=00-01

  Stats: 20 lines in 6 files changed: 12 ins; 2 del; 6 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  Wed Jul 30 06:47:57 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 30 Jul 2025 06:47:57 GMT
Subject: RFR: 8364235: Fix for JDK-8361447 breaks the alignment
 requirements for GuardedMemory [v2]
In-Reply-To: <2TwjPcp38oR6cGGwKkofLjsNgWKTYP2u6F72whsbhCw=.0463a182-11a0-462b-bf6f-6f14a2ddedd1@github.com>
References: <2NMVt2xW6-rTS7vQPJ8fPkfabrTPiugEqGf4KlttYSo=.46b5d9f5-90b3-44b9-b3db-f139672145dc@github.com>
 <oxasmf4lzJcK7irfsPn0PHF__rF3oTfK8c5BIBNOZI0=.95fa61fe-f92f-4f5f-af6a-cdd54e64f6c2@github.com>
 <7Vqj1iuod1IJmEyR9r_BSHOkngc-g9_GSUWAbKe-4Us=.6f7c16a0-feeb-4496-9300-dad6201be5d6@github.com>
 <2TwjPcp38oR6cGGwKkofLjsNgWKTYP2u6F72whsbhCw=.0463a182-11a0-462b-bf6f-6f14a2ddedd1@github.com>
Message-ID: <wvKBQcmNfMJmLKUPNdarZ8NxfaaxZPmpAhMs73onrKw=.447f507b-9225-4578-848e-4e1cf0d552d1@github.com>

On Tue, 29 Jul 2025 08:24:02 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> It ensures that the offset of the user-data ptr within the `GuardedMemory` object, places the user-data on a suitably aligned boundary.
>> 
>> I tried:
>> 
>>   alignas(16) u_char* _base_addr;
>> 
>> but that did not work. Perhaps I am using it wrong?
>
> That would simply align the "guarded memory handle"'s field (on the stack) not the value inside. It is the value we put in there that needs to be aligned.

Yep I got confused about which ptr was the "user data".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26524#discussion_r2241689839

From dholmes at openjdk.org  Wed Jul 30 06:47:56 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 30 Jul 2025 06:47:56 GMT
Subject: RFR: 8364235: Fix for JDK-8361447 breaks the alignment
 requirements for GuardedMemory [v2]
In-Reply-To: <T9C4Mjiw1paqOoA87oSneAbmZSStE4RgkrtA35MKckk=.75a71738-2197-4e8f-a7af-f1addb2b38d2@github.com>
References: <2NMVt2xW6-rTS7vQPJ8fPkfabrTPiugEqGf4KlttYSo=.46b5d9f5-90b3-44b9-b3db-f139672145dc@github.com>
 <F0WAvSIePri0xNAFr_qmwCkJDetoQ6X70cTTC3CXit4=.7bc251c1-fe4a-48e8-962d-58105266ca53@github.com>
 <T9C4Mjiw1paqOoA87oSneAbmZSStE4RgkrtA35MKckk=.75a71738-2197-4e8f-a7af-f1addb2b38d2@github.com>
Message-ID: <4x3mMAwzEruFi1sAS4wgvEiLNTP87Flg4Cfl7-msZNs=.28c723b6-7d6a-42f6-9585-196839e8c15a@github.com>

On Tue, 29 Jul 2025 08:30:42 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:
>> 
>>   Correct comments as per reviewer comments
>
> src/hotspot/share/memory/guardedMemory.hpp line 45:
> 
>> 43:  * |------------------------------------------------------------
>> 44:  * |base_addr          | 0xABABABABABABABAB   | Head guard     |
>> 45:  * |+16                | padding              | For alignment  |
> 
> Is `+sizeof(Guard)` or `+GUARD_SIZE` an alternative to `+16`. 16 is a little out of the blue for me.

Fixed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26524#discussion_r2241688266

From dholmes at openjdk.org  Wed Jul 30 06:57:35 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 30 Jul 2025 06:57:35 GMT
Subject: RFR: 8364235: Fix for JDK-8361447 breaks the alignment
 requirements for GuardedMemory [v3]
In-Reply-To: <2NMVt2xW6-rTS7vQPJ8fPkfabrTPiugEqGf4KlttYSo=.46b5d9f5-90b3-44b9-b3db-f139672145dc@github.com>
References: <2NMVt2xW6-rTS7vQPJ8fPkfabrTPiugEqGf4KlttYSo=.46b5d9f5-90b3-44b9-b3db-f139672145dc@github.com>
Message-ID: <du2mFd_YMjQOey7of3E1RY-z3dNCwgjl_sf5Vfp8pPU=.07bde9d7-9116-4254-8ccf-55e93944d856@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:

  Simpler solutuion suggested by Johan.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26524/files
  - new: https://git.openjdk.org/jdk/pull/26524/files/4d252e3c..2d0ec967

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26524&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26524&range=01-02

  Stats: 13 lines in 1 file changed: 1 ins; 7 del; 5 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 sspitsyn at openjdk.org  Wed Jul 30 07:19:34 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 30 Jul 2025 07:19:34 GMT
Subject: RFR: 8306324: StopThread results in thread being marked as
 interrupted, leading to unexpected InterruptedException [v5]
In-Reply-To: <sDAklD-arV33IpWiJwMkwUfNPMAmsr5cgboU4y0hjhk=.192cd7e5-f2a2-4b5c-83a9-5111bf1926ec@github.com>
References: <sDAklD-arV33IpWiJwMkwUfNPMAmsr5cgboU4y0hjhk=.192cd7e5-f2a2-4b5c-83a9-5111bf1926ec@github.com>
Message-ID: <UYPujENcouAtWp9jPrM7r5bbQuOV-yV5Olc4t0tTju4=.962b0cab-b815-4de2-a84b-af6552f3dbdd@github.com>

> 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:

  review: restored the tweak in the JavaThread::sleep_nanos

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26365/files
  - new: https://git.openjdk.org/jdk/pull/26365/files/1f7b67c3..a46ef6f5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26365&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26365&range=03-04

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26365.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26365/head:pull/26365

PR: https://git.openjdk.org/jdk/pull/26365

From sspitsyn at openjdk.org  Wed Jul 30 07:19:34 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 30 Jul 2025 07:19:34 GMT
Subject: RFR: 8306324: StopThread results in thread being marked as
 interrupted, leading to unexpected InterruptedException [v3]
In-Reply-To: <nCQ9rXDFA60ciIsZSDSgROuUJTf_jFI1tXeuIopT8SI=.5e9197e7-895e-40d8-b513-191452675e09@github.com>
References: <sDAklD-arV33IpWiJwMkwUfNPMAmsr5cgboU4y0hjhk=.192cd7e5-f2a2-4b5c-83a9-5111bf1926ec@github.com>
 <AWpHV3UvP_0bCI8pMBUQtIsYrmGcXLY8j9_KubieCHg=.2e793179-2c88-41d3-8672-dfa57e5625a0@github.com>
 <rJ6j7EgxbKBYoeE4XT9qABEMeE1CwVR7GNIdQcQAoNQ=.85308e5a-41d0-4f8e-a7e9-3a1b45ef5fb7@github.com>
 <N3dkD7c4GS4NAd69ZZhkd6b2PTCeCqzAgSvwLFn5Q8o=.226045e8-f10f-4df5-83b2-770e136a8d14@github.com>
 <nCQ9rXDFA60ciIsZSDSgROuUJTf_jFI1tXeuIopT8SI=.5e9197e7-895e-40d8-b513-191452675e09@github.com>
Message-ID: <xSE3vh-Rc9U855LC5YnHLFERSCT60mxJJb9rLYcYOsM=.eed73eda-a162-4d50-ae9c-6292770e8a3d@github.com>

On Tue, 29 Jul 2025 23:45:09 GMT, David Holmes <dholmes at openjdk.org> wrote:

> But that tweak has now been removed hence this fix no longer maintains the functionality of StopThread.

Sorry, this was removed by a mistake. I incorrectly interpreted some code. Restored now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26365#issuecomment-3135132366

From dholmes at openjdk.org  Wed Jul 30 07:24:49 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 30 Jul 2025 07:24:49 GMT
Subject: RFR: 8364235: Fix for JDK-8361447 breaks the alignment
 requirements for GuardedMemory [v4]
In-Reply-To: <2NMVt2xW6-rTS7vQPJ8fPkfabrTPiugEqGf4KlttYSo=.46b5d9f5-90b3-44b9-b3db-f139672145dc@github.com>
References: <2NMVt2xW6-rTS7vQPJ8fPkfabrTPiugEqGf4KlttYSo=.46b5d9f5-90b3-44b9-b3db-f139672145dc@github.com>
Message-ID: <TekiCaaCeqBAmqGezDRHStSLT-b6VNv9J7VA-brCII0=.be40550e-52d1-442a-8422-e1e76c71929f@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:

  typo

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26524/files
  - new: https://git.openjdk.org/jdk/pull/26524/files/2d0ec967..ab19a75d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26524&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26524&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 sspitsyn at openjdk.org  Wed Jul 30 07:30:54 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 30 Jul 2025 07:30:54 GMT
Subject: RFR: 8306324: StopThread results in thread being marked as
 interrupted, leading to unexpected InterruptedException [v3]
In-Reply-To: <nCQ9rXDFA60ciIsZSDSgROuUJTf_jFI1tXeuIopT8SI=.5e9197e7-895e-40d8-b513-191452675e09@github.com>
References: <sDAklD-arV33IpWiJwMkwUfNPMAmsr5cgboU4y0hjhk=.192cd7e5-f2a2-4b5c-83a9-5111bf1926ec@github.com>
 <AWpHV3UvP_0bCI8pMBUQtIsYrmGcXLY8j9_KubieCHg=.2e793179-2c88-41d3-8672-dfa57e5625a0@github.com>
 <rJ6j7EgxbKBYoeE4XT9qABEMeE1CwVR7GNIdQcQAoNQ=.85308e5a-41d0-4f8e-a7e9-3a1b45ef5fb7@github.com>
 <N3dkD7c4GS4NAd69ZZhkd6b2PTCeCqzAgSvwLFn5Q8o=.226045e8-f10f-4df5-83b2-770e136a8d14@github.com>
 <nCQ9rXDFA60ciIsZSDSgROuUJTf_jFI1tXeuIopT8SI=.5e9197e7-895e-40d8-b513-191452675e09@github.com>
Message-ID: <NmLYLwgrfAg7eZPjX1BdmAibUeqckD1oCv4oNfFsSk8=.9aa30a35-4294-43ca-8d21-bd55081bd841@github.com>

On Tue, 29 Jul 2025 23:45:09 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I don't think the current proposed change (which drop's setting the interrupt flag in install_async_exception) will cause a target thread blocked in sleep to wakeup. A target thread blocked in JavaThread::sleep_nanos will wakeup from park_nanos but will just park again with the remaining time.

Thank you checking this. I've restored the tweak in the `JavaThread::sleep_nanos()`.

>  I assume this is the test failures that Serguei mentions.

The test failures I mentioned were after an attempt to remove the following lines from the `JavaThread::install_async_exception()`:

  oop vt_oop = vthread();
  if (vt_oop == nullptr || !vt_oop->is_a(vmClasses::BaseVirtualThread_klass())) {
    // Interrupt thread so it will wake up from a potential wait()/sleep()/park()
    this->interrupt();
  }
``` 
In order to remove the above a corresponding update in the jdwp/debugger is additionally needed to invoke the JVMTI `ThreadInterrupt()`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26365#issuecomment-3135163510

From dholmes at openjdk.org  Wed Jul 30 07:37:44 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 30 Jul 2025 07:37:44 GMT
Subject: RFR: 8364106: Include java.runtime.version in thread dump output
 [v2]
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: <xQ5GZWUWVieCEYJoih4y9S31xyYGu3QLKmFup25eyXc=.4f519ad2-19f4-4a4a-a17c-f6896f1da8d1@github.com>

> 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-3 (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

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  JRE -> JDK

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26520/files
  - new: https://git.openjdk.org/jdk/pull/26520/files/fe94369d..ec593bb0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26520&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26520&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26520.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26520/head:pull/26520

PR: https://git.openjdk.org/jdk/pull/26520

From dholmes at openjdk.org  Wed Jul 30 07:37:45 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 30 Jul 2025 07:37:45 GMT
Subject: RFR: 8364106: Include java.runtime.version in thread dump output
 [v2]
In-Reply-To: <hzFui5EE04P9mowAQlS6NUyrTF3Lkl_xv08A8SieZz4=.4f97952f-9f1c-4889-b420-5e2396e46f95@github.com>
References: <lLL3n-lmOFiJnJ712idlTecQfw2mkVqeXTMLuVNv_j4=.f40bbb37-85e5-4fc5-8129-77320b6ebd79@github.com>
 <hzFui5EE04P9mowAQlS6NUyrTF3Lkl_xv08A8SieZz4=.4f97952f-9f1c-4889-b420-5e2396e46f95@github.com>
Message-ID: <kex44J0S2X6tq9szl1IcwRpgPMhXp0J766WYFTz8Mz8=.88e0ef17-374f-4c5f-9502-d9d472f7aec2@github.com>

On Tue, 29 Jul 2025 09:59:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JRE -> JDK
>
> src/hotspot/share/runtime/threads.cpp line 1383:
> 
>> 1381:                                 VM_Version::printable_jdk_debug_level() : "";
>> 1382: 
>> 1383:   st->print_cr("                 JRE version: %s%s%s (%s) (%sbuild %s)", runtime_name,
> 
> The move to modules in JDK 9 blurred the historical distinction between what we used to know as the JDK and JRE. So we don't use "JRE" anymore. I think it would be okay to say JDK or runtime version here.

We probably need to file a general fix up for this as we still report "JRE" in `-Xinternalversion`, as well as the version string in the hs_err report. But I can change this one to "JDK"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26520#discussion_r2241781286

From coffeys at openjdk.org  Wed Jul 30 07:43:41 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 30 Jul 2025 07:43:41 GMT
Subject: RFR: 8364106: Include java.runtime.version in thread dump output
 [v3]
In-Reply-To: <kex44J0S2X6tq9szl1IcwRpgPMhXp0J766WYFTz8Mz8=.88e0ef17-374f-4c5f-9502-d9d472f7aec2@github.com>
References: <lLL3n-lmOFiJnJ712idlTecQfw2mkVqeXTMLuVNv_j4=.f40bbb37-85e5-4fc5-8129-77320b6ebd79@github.com>
 <hzFui5EE04P9mowAQlS6NUyrTF3Lkl_xv08A8SieZz4=.4f97952f-9f1c-4889-b420-5e2396e46f95@github.com>
 <kex44J0S2X6tq9szl1IcwRpgPMhXp0J766WYFTz8Mz8=.88e0ef17-374f-4c5f-9502-d9d472f7aec2@github.com>
Message-ID: <92mYpMgyghrqhpQKYtp1P3SuQw50i4cnFCQPVY8L5Wo=.0d712268-25cf-430a-804a-84fcfba27eba@github.com>

On Wed, 30 Jul 2025 07:32:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/runtime/threads.cpp line 1383:
>> 
>>> 1381:                                 VM_Version::printable_jdk_debug_level() : "";
>>> 1382: 
>>> 1383:   st->print_cr("                 JRE version: %s%s%s (%s) (%sbuild %s)", runtime_name,
>> 
>> The move to modules in JDK 9 blurred the historical distinction between what we used to know as the JDK and JRE. So we don't use "JRE" anymore. I think it would be okay to say JDK or runtime version here.
>
> We probably need to file a general fix up for this as we still report "JRE" in `-Xinternalversion`, as well as the version string in the hs_err report. But I can change this one to "JDK"

related to https://bugs.openjdk.org/browse/JDK-8330123

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26520#discussion_r2241798208

From dholmes at openjdk.org  Wed Jul 30 07:43:40 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 30 Jul 2025 07:43:40 GMT
Subject: RFR: 8364106: Include java.runtime.version in thread dump output
 [v3]
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: <_UCw6r1btIsTRznxMGw2y7KmZs8nysaIbQTtKw_8vEs=.e1f17a3a-af04-4af3-a2d0-d21e480e9434@github.com>

> 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-3 (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

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Add basic testing

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26520/files
  - new: https://git.openjdk.org/jdk/pull/26520/files/ec593bb0..b3a37a0d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26520&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26520&range=01-02

  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26520.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26520/head:pull/26520

PR: https://git.openjdk.org/jdk/pull/26520

From aboldtch at openjdk.org  Wed Jul 30 07:53:55 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 30 Jul 2025 07:53:55 GMT
Subject: RFR: 8364235: Fix for JDK-8361447 breaks the alignment
 requirements for GuardedMemory [v4]
In-Reply-To: <TekiCaaCeqBAmqGezDRHStSLT-b6VNv9J7VA-brCII0=.be40550e-52d1-442a-8422-e1e76c71929f@github.com>
References: <2NMVt2xW6-rTS7vQPJ8fPkfabrTPiugEqGf4KlttYSo=.46b5d9f5-90b3-44b9-b3db-f139672145dc@github.com>
 <TekiCaaCeqBAmqGezDRHStSLT-b6VNv9J7VA-brCII0=.be40550e-52d1-442a-8422-e1e76c71929f@github.com>
Message-ID: <5Vo_L-PB8eOItA8qo7e6M1ORq3HOLEJcydhHZ6EAIpk=.e9c509d5-3658-442f-b6bd-d413a0166252@github.com>

On Wed, 30 Jul 2025 07:24:49 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:
> 
>   typo

Marked as reviewed by aboldtch (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26524#pullrequestreview-3070290595

From kbarrett at openjdk.org  Wed Jul 30 08:22:57 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 30 Jul 2025 08:22:57 GMT
Subject: RFR: 8364235: Fix for JDK-8361447 breaks the alignment
 requirements for GuardedMemory [v4]
In-Reply-To: <TekiCaaCeqBAmqGezDRHStSLT-b6VNv9J7VA-brCII0=.be40550e-52d1-442a-8422-e1e76c71929f@github.com>
References: <2NMVt2xW6-rTS7vQPJ8fPkfabrTPiugEqGf4KlttYSo=.46b5d9f5-90b3-44b9-b3db-f139672145dc@github.com>
 <TekiCaaCeqBAmqGezDRHStSLT-b6VNv9J7VA-brCII0=.be40550e-52d1-442a-8422-e1e76c71929f@github.com>
Message-ID: <PGNg5XV10TQ_DF2RuIymKXz0wmv7uahHHK-7kd4FZCI=.2361dfe2-ff05-4d3b-a2da-bc08512adbcc@github.com>

On Wed, 30 Jul 2025 07:24:49 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:
> 
>   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.

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".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26524#discussion_r2241892422
PR Review Comment: https://git.openjdk.org/jdk/pull/26524#discussion_r2241892261

From duke at openjdk.org  Wed Jul 30 08:25:54 2025
From: duke at openjdk.org (duke)
Date: Wed, 30 Jul 2025 08:25:54 GMT
Subject: RFR: 8363949: Incorrect jtreg header in
 MonitorWithDeadObjectTest.java
In-Reply-To: <aL9b5b-GATHLDCakKIztuhSCKTK9bE3EKPmiZtUNO4g=.677e7a91-7f18-4d40-8650-4367a1bbae33@github.com>
References: <aL9b5b-GATHLDCakKIztuhSCKTK9bE3EKPmiZtUNO4g=.677e7a91-7f18-4d40-8650-4367a1bbae33@github.com>
Message-ID: <ONs8iVAYfsajiwbolQFZzzRL0LVLe0WhsbbBrfR7mcA=.7e494c1f-2dd8-4fec-85b6-662c103100dc@github.com>

On Tue, 29 Jul 2025 09:18:40 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> the mentioned test fails if run standalone with the following error: 
> Error: Not a test or directory containing tests: runtime/Monitor/MonitorWithDeadObjectTest.java
> 
> The order of jtreg tags is not correct, to make it pass standalone it is sufficient to put @test first in each test.

@toxaart 
Your change (at version 25ac27c23f4e33896010ff791237fd0c6799d0a5) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26527#issuecomment-3135316419

From alanb at openjdk.org  Wed Jul 30 08:41:55 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 30 Jul 2025 08:41:55 GMT
Subject: RFR: 8306324: StopThread results in thread being marked as
 interrupted, leading to unexpected InterruptedException [v5]
In-Reply-To: <UYPujENcouAtWp9jPrM7r5bbQuOV-yV5Olc4t0tTju4=.962b0cab-b815-4de2-a84b-af6552f3dbdd@github.com>
References: <sDAklD-arV33IpWiJwMkwUfNPMAmsr5cgboU4y0hjhk=.192cd7e5-f2a2-4b5c-83a9-5111bf1926ec@github.com>
 <UYPujENcouAtWp9jPrM7r5bbQuOV-yV5Olc4t0tTju4=.962b0cab-b815-4de2-a84b-af6552f3dbdd@github.com>
Message-ID: <C21FWOc1QhmBREVweVnw7o114pl_zOUdxpy4ZPYynHU=.af4e271f-0864-4949-8529-eaf068dcd270@github.com>

On Wed, 30 Jul 2025 07:19:34 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:
> 
>   review: restored the tweak in the JavaThread::sleep_nanos

The latest update to have JavaThread::sleep_nanos to bail out if there is async exception looks okay.  Combined it means that a StopThread when the target platform thread is in Thread.sleep and Object.wait will cause both to wakeup and throw the exception, without the side effect of setting the interrupt status. So I think it's a good approach.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26365#issuecomment-3135364067

From alanb at openjdk.org  Wed Jul 30 08:46:56 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 30 Jul 2025 08:46:56 GMT
Subject: RFR: 8306324: StopThread results in thread being marked as
 interrupted, leading to unexpected InterruptedException [v3]
In-Reply-To: <nCQ9rXDFA60ciIsZSDSgROuUJTf_jFI1tXeuIopT8SI=.5e9197e7-895e-40d8-b513-191452675e09@github.com>
References: <sDAklD-arV33IpWiJwMkwUfNPMAmsr5cgboU4y0hjhk=.192cd7e5-f2a2-4b5c-83a9-5111bf1926ec@github.com>
 <AWpHV3UvP_0bCI8pMBUQtIsYrmGcXLY8j9_KubieCHg=.2e793179-2c88-41d3-8672-dfa57e5625a0@github.com>
 <rJ6j7EgxbKBYoeE4XT9qABEMeE1CwVR7GNIdQcQAoNQ=.85308e5a-41d0-4f8e-a7e9-3a1b45ef5fb7@github.com>
 <N3dkD7c4GS4NAd69ZZhkd6b2PTCeCqzAgSvwLFn5Q8o=.226045e8-f10f-4df5-83b2-770e136a8d14@github.com>
 <nCQ9rXDFA60ciIsZSDSgROuUJTf_jFI1tXeuIopT8SI=.5e9197e7-895e-40d8-b513-191452675e09@github.com>
Message-ID: <Zk0pCIRNhW52pVS8LQlOxa-zlOdfj0mQcOC8Ke4IhFk=.0168453e-f11f-4e5e-a55c-9b8acba561c7@github.com>

On Tue, 29 Jul 2025 23:45:09 GMT, David Holmes <dholmes at openjdk.org> wrote:

> And again this issue of leaving the interrupt flag set has existed "forever".

Right, and mostly surfaced when updating JVMTI to support virtual threads.

The related issue is that JVMTI InterruptThread doesn't cause a platform thread to wakeup from interruptible I/O operations. It works when the target is a virtual thread because it's an upcall to Thread::interrupt, not so for platform threads.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26365#issuecomment-3135380028

From alanb at openjdk.org  Wed Jul 30 09:01:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 30 Jul 2025 09:01:54 GMT
Subject: RFR: 8364106: Include java.runtime.version in thread dump output
 [v3]
In-Reply-To: <92mYpMgyghrqhpQKYtp1P3SuQw50i4cnFCQPVY8L5Wo=.0d712268-25cf-430a-804a-84fcfba27eba@github.com>
References: <lLL3n-lmOFiJnJ712idlTecQfw2mkVqeXTMLuVNv_j4=.f40bbb37-85e5-4fc5-8129-77320b6ebd79@github.com>
 <hzFui5EE04P9mowAQlS6NUyrTF3Lkl_xv08A8SieZz4=.4f97952f-9f1c-4889-b420-5e2396e46f95@github.com>
 <kex44J0S2X6tq9szl1IcwRpgPMhXp0J766WYFTz8Mz8=.88e0ef17-374f-4c5f-9502-d9d472f7aec2@github.com>
 <92mYpMgyghrqhpQKYtp1P3SuQw50i4cnFCQPVY8L5Wo=.0d712268-25cf-430a-804a-84fcfba27eba@github.com>
Message-ID: <-rtY039IDHazl8ko2Sk4LGeyaC18EWpx6BaUiqEcSAw=.e16f5e63-825c-49fe-93c0-b7ccf403b9bf@github.com>

On Wed, 30 Jul 2025 07:39:58 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> We probably need to file a general fix up for this as we still report "JRE" in `-Xinternalversion`, as well as the version string in the hs_err report. But I can change this one to "JDK"
>
> related to https://bugs.openjdk.org/browse/JDK-8330123

> We probably need to file a general fix up for this as we still report "JRE" in -Xinternalversion, as well as the version string in the hs_err report.

I did a quick search of src/hotspot and these seems to the only two. Yes, would be good to update both.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26520#discussion_r2241986965

From shade at openjdk.org  Wed Jul 30 09:34:57 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 30 Jul 2025 09:34:57 GMT
Subject: RFR: 8364314: java_lang_Thread::get_thread_status fails
 assert(base != nullptr) failed: Invalid base [v2]
In-Reply-To: <zEmmXnncIeBkHA6lfZBkOK3F19mjG1ExCad990UzhHM=.2c35f1aa-03c2-4588-8f4e-ce655c56256c@github.com>
References: <ceYO3eEp5YWA4T5oDbw3Tqv0f-GUh2xTBqxjuWdsJl8=.f594db6c-8064-4a7a-a467-75ba86e950bd@github.com>
 <zEmmXnncIeBkHA6lfZBkOK3F19mjG1ExCad990UzhHM=.2c35f1aa-03c2-4588-8f4e-ce655c56256c@github.com>
Message-ID: <qM2GFxaVHmUUl6rwfOV1eXhNBp9KR0jAPJKJdWStVSg=.c9336fbe-3405-41e2-8165-2d5a178be45c@github.com>

On Wed, 30 Jul 2025 06:24:39 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 with a new target base 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.

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26544#pullrequestreview-3070623687

From alanb at openjdk.org  Wed Jul 30 10:46:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 30 Jul 2025 10:46:54 GMT
Subject: RFR: 8364106: Include java.runtime.version in thread dump output
 [v3]
In-Reply-To: <_UCw6r1btIsTRznxMGw2y7KmZs8nysaIbQTtKw_8vEs=.e1f17a3a-af04-4af3-a2d0-d21e480e9434@github.com>
References: <lLL3n-lmOFiJnJ712idlTecQfw2mkVqeXTMLuVNv_j4=.f40bbb37-85e5-4fc5-8129-77320b6ebd79@github.com>
 <_UCw6r1btIsTRznxMGw2y7KmZs8nysaIbQTtKw_8vEs=.e1f17a3a-af04-4af3-a2d0-d21e480e9434@github.com>
Message-ID: <etJlqR5zcaYaDAOu5evIlyVQyji-VYBp6h0m09TptEs=.0fa1f7e3-d8f0-4b96-941a-0f9e2838c977@github.com>

On Wed, 30 Jul 2025 07:43:40 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-3 (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
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add basic testing

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26520#pullrequestreview-3070863944

From coffeys at openjdk.org  Wed Jul 30 10:56:55 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 30 Jul 2025 10:56:55 GMT
Subject: RFR: 8364106: Include java.runtime.version in thread dump output
 [v3]
In-Reply-To: <_UCw6r1btIsTRznxMGw2y7KmZs8nysaIbQTtKw_8vEs=.e1f17a3a-af04-4af3-a2d0-d21e480e9434@github.com>
References: <lLL3n-lmOFiJnJ712idlTecQfw2mkVqeXTMLuVNv_j4=.f40bbb37-85e5-4fc5-8129-77320b6ebd79@github.com>
 <_UCw6r1btIsTRznxMGw2y7KmZs8nysaIbQTtKw_8vEs=.e1f17a3a-af04-4af3-a2d0-d21e480e9434@github.com>
Message-ID: <_2DtHnr4oq94Q1lVAS3OQpW4abx91aAeW2Md9JnxWLI=.89280feb-28bf-4a36-ac25-0412f2ef0025@github.com>

On Wed, 30 Jul 2025 07:43:40 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-3 (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
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add basic testing

Marked as reviewed by coffeys (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26520#pullrequestreview-3070891816

From syan at openjdk.org  Wed Jul 30 13:35:59 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 30 Jul 2025 13:35:59 GMT
Subject: RFR: 8362501: Update
 test/hotspot/jtreg/applications/jcstress/README [v5]
In-Reply-To: <QmYz2Em781E3S8CsPKyIL7WXadn3jSQ6gGiEBrtPcu8=.a3b6647b-c2d9-423f-ba2e-26d496fb8ceb@github.com>
References: <Gv-CfzN4MbQDSvKMkXs6DWllE9saxTpkjIh92W8GkK4=.04b9e256-42cb-48de-a8e0-2345cdbc8b78@github.com>
 <QmYz2Em781E3S8CsPKyIL7WXadn3jSQ6gGiEBrtPcu8=.a3b6647b-c2d9-423f-ba2e-26d496fb8ceb@github.com>
Message-ID: <jjEht6AcLppS5xnUXUSH-D367W6AS4ovvpaVu3nBw1w=.66338539-5891-4d81-89eb-dbc0cc16b5f4@github.com>

On Mon, 28 Jul 2025 12:37:43 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Currently, this is no documentation on how to run the application/jcstress tests. I think it will be useful to complement the document test/hotspot/jtreg/applications/jcstress/README on how to run the jcstress tests in jtreg.
>> 
>> No behaviour has been change, only update the ducumentation, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use less specific in the guidance

Looking for 2rd reviewer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26369#issuecomment-3136377623

From ayang at openjdk.org  Wed Jul 30 14:13:56 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 30 Jul 2025 14:13:56 GMT
Subject: RFR: 8364197: G1: Sort G1 mutex locks by name and group them
 together
In-Reply-To: <PhF7nBjpjmPAJ7UHSyfYJbdRouucweAcwMmYk_pnctg=.694ddeb5-7eb6-404a-aaed-35bdce957bb1@github.com>
References: <PhF7nBjpjmPAJ7UHSyfYJbdRouucweAcwMmYk_pnctg=.694ddeb5-7eb6-404a-aaed-35bdce957bb1@github.com>
Message-ID: <B5FNCKmtQVjqfdL_N7Q3PwShuBMBQa0XclRMRmq5d_c=.bf8ee2a6-d161-4181-aba7-31c489bd7a3d@github.com>

On Mon, 28 Jul 2025 14:44:20 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change to put together G1 mutex definitions/declarations and sort them. That makes it easier for me to verify changes in that area.
> 
> Testing: local compilation
> 
> Thanks,
>   Thomas

Marked as reviewed by ayang (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26508#pullrequestreview-3071774374

From lmesnik at openjdk.org  Wed Jul 30 15:22:58 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 30 Jul 2025 15:22:58 GMT
Subject: RFR: 8362501: Update
 test/hotspot/jtreg/applications/jcstress/README [v5]
In-Reply-To: <QmYz2Em781E3S8CsPKyIL7WXadn3jSQ6gGiEBrtPcu8=.a3b6647b-c2d9-423f-ba2e-26d496fb8ceb@github.com>
References: <Gv-CfzN4MbQDSvKMkXs6DWllE9saxTpkjIh92W8GkK4=.04b9e256-42cb-48de-a8e0-2345cdbc8b78@github.com>
 <QmYz2Em781E3S8CsPKyIL7WXadn3jSQ6gGiEBrtPcu8=.a3b6647b-c2d9-423f-ba2e-26d496fb8ceb@github.com>
Message-ID: <Z5tOsluNm7PRMAEX6-t6W3Lfdui1cfcoOBaC0MAtljw=.d3638c0f-fd30-4072-8b31-ea7594b39050@github.com>

On Mon, 28 Jul 2025 12:37:43 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Currently, this is no documentation on how to run the application/jcstress tests. I think it will be useful to complement the document test/hotspot/jtreg/applications/jcstress/README on how to run the jcstress tests in jtreg.
>> 
>> No behaviour has been change, only update the ducumentation, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use less specific in the guidance

Marked as reviewed by lmesnik (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26369#pullrequestreview-3072147529

From adinn at openjdk.org  Wed Jul 30 15:26:55 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 30 Jul 2025 15:26:55 GMT
Subject: RFR: 8364235: Fix for JDK-8361447 breaks the alignment
 requirements for GuardedMemory [v4]
In-Reply-To: <xj3FDXSmK_8pdGTWTkoLcEHtMe59Ujmz6rOck7ZuT0g=.37581c93-1a1c-44d8-9ee1-2d65e2c90db8@github.com>
References: <2NMVt2xW6-rTS7vQPJ8fPkfabrTPiugEqGf4KlttYSo=.46b5d9f5-90b3-44b9-b3db-f139672145dc@github.com>
 <jhssYVyTL7Q7M70V_ounR46Bpy6so4glOka63R7kshM=.9b254a86-9477-4c41-a088-9277b4177e42@github.com>
 <25J-d9i828o188kIFPGaQluKaDyzYbwGAvh_ms-wSso=.9fb4c6eb-758b-4b48-913b-5b84eb7145a7@github.com>
 <Ooa50jrJKw13hfwcx3M1t4h3v3CSxE7S0_4iy73I4hs=.819023a7-d86a-4e42-b1af-c0820d80dbda@github.com>
 <xj3FDXSmK_8pdGTWTkoLcEHtMe59Ujmz6rOck7ZuT0g=.37581c93-1a1c-44d8-9ee1-2d65e2c90db8@github.com>
Message-ID: <emeDrHYwdh2voVU5wbZLhyLqITCYJkDmas4R7g1eSZw=.61330834-5ca5-4ef0-a07c-f9b847fbe8ad@github.com>

On Wed, 30 Jul 2025 06:13:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Forcing `alignas(16)` alignment on `GuardHeader` directly implies `sizeof(GuardHeader) % 16 == 0` without the need of a padding field. And C++ will be required to insert 8 byte padding after `_tag2`. 
>> 
>> If it is important that the padding occurs after the header and before the size keep the current solution.
>
> I am surprised that `alignas` will pad in that way - I only expected it to align the initial placement. The docs do not seem to describe this, though the example implicitly does (as `sizeof(sse_t)` yields 32 not 16) [1]
> 
> I will test this out.
> 
> [1] http://en.cppreference.com/w/cpp/language/alignas.html

I would assume it has to do so in order to ensure arrays of objects all stay aligned.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26524#discussion_r2243078469

From pchilanomate at openjdk.org  Wed Jul 30 15:36:56 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 30 Jul 2025 15:36:56 GMT
Subject: RFR: 8306324: StopThread results in thread being marked as
 interrupted, leading to unexpected InterruptedException [v5]
In-Reply-To: <UYPujENcouAtWp9jPrM7r5bbQuOV-yV5Olc4t0tTju4=.962b0cab-b815-4de2-a84b-af6552f3dbdd@github.com>
References: <sDAklD-arV33IpWiJwMkwUfNPMAmsr5cgboU4y0hjhk=.192cd7e5-f2a2-4b5c-83a9-5111bf1926ec@github.com>
 <UYPujENcouAtWp9jPrM7r5bbQuOV-yV5Olc4t0tTju4=.962b0cab-b815-4de2-a84b-af6552f3dbdd@github.com>
Message-ID: <BRNPWlNjZbcr1roL0E4D2iuVkUvEX8_qsTkocmvLFL0=.44412b8e-7c0c-4d18-b936-e924a6b7dbbd@github.com>

On Wed, 30 Jul 2025 07:19:34 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:
> 
>   review: restored the tweak in the JavaThread::sleep_nanos

Changes look good to me, just a few comments below.

src/hotspot/share/runtime/javaThread.cpp line 2121:

> 2119:   for (;;) {
> 2120:     if (has_async_exception_condition()) {
> 2121:       return false;

The comment above `JavaThread::sleep_nanos` should be updated about this case.
Also, back in `JVM_SleepNanos` we should probably skip throwing IE for this case (even though it will be overwritten by the async one later).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26365#pullrequestreview-3072155539
PR Review Comment: https://git.openjdk.org/jdk/pull/26365#discussion_r2243072058

From fbredberg at openjdk.org  Wed Jul 30 15:38:44 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 30 Jul 2025 15:38:44 GMT
Subject: RFR: 8364141: Remove LockingMode related code from x86
Message-ID: <g7WNqmFlJOkai-zeEjD09M5TwpL3fAMkZUAy37b747U=.faa6d9f5-1894-4507-a0f1-1dd41f3bdd43@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.

-------------

Commit messages:
 - 8364141: Remove LockingMode related code from x86

Changes: https://git.openjdk.org/jdk/pull/26552/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26552&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364141
  Stats: 637 lines in 10 files changed: 44 ins; 537 del; 56 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 dcubed at openjdk.org  Wed Jul 30 16:16:55 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 30 Jul 2025 16:16:55 GMT
Subject: RFR: 8364314: java_lang_Thread::get_thread_status fails
 assert(base != nullptr) failed: Invalid base [v2]
In-Reply-To: <zEmmXnncIeBkHA6lfZBkOK3F19mjG1ExCad990UzhHM=.2c35f1aa-03c2-4588-8f4e-ce655c56256c@github.com>
References: <ceYO3eEp5YWA4T5oDbw3Tqv0f-GUh2xTBqxjuWdsJl8=.f594db6c-8064-4a7a-a467-75ba86e950bd@github.com>
 <zEmmXnncIeBkHA6lfZBkOK3F19mjG1ExCad990UzhHM=.2c35f1aa-03c2-4588-8f4e-ce655c56256c@github.com>
Message-ID: <E5dJotAuA9E6URmuDZ8qqEqR8a1XH3lUYEtPIPjo8YA=.2b6eb8eb-7688-4e90-833d-72af3db7eefa@github.com>

On Wed, 30 Jul 2025 06:24:39 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 with a new target base 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

Thumbs up. I have a single typo and a suggested rewording for a comment.

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.

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.

-------------

Marked as reviewed by dcubed (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26544#pullrequestreview-3072313007
PR Review Comment: https://git.openjdk.org/jdk/pull/26544#discussion_r2243188114
PR Review Comment: https://git.openjdk.org/jdk/pull/26544#discussion_r2243178676

From coleenp at openjdk.org  Wed Jul 30 16:24:53 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 30 Jul 2025 16:24:53 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: <mZDL0L3WAyZxzLOTd7WKOFpSx6o0ly_-EPcXTYhNAeQ=.073ef480-a999-48f3-93a0-3a94d160fa17@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 looks really good.  Thank you for the comment about balanced locking.

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.

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26552#pullrequestreview-3072397438
PR Review Comment: https://git.openjdk.org/jdk/pull/26552#discussion_r2243231761

From duke at openjdk.org  Wed Jul 30 16:58:07 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Wed, 30 Jul 2025 16:58:07 GMT
Subject: RFR: 8364359: Sort share/cds includes
Message-ID: <9k50LwUaGiciMBE69S8FuJWN0pDbbwA5SCLK51mDVfk=.c0c92087-c47b-492c-a2d3-621a9d4711d6@github.com>

This PR sorts the includes in `hotspot/share/cds` using `SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted`.

Passes tier1.

-------------

Commit messages:
 - sort

Changes: https://git.openjdk.org/jdk/pull/26561/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26561&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364359
  Stats: 34 lines in 13 files changed: 18 ins; 16 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26561.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26561/head:pull/26561

PR: https://git.openjdk.org/jdk/pull/26561

From mgronlun at openjdk.org  Wed Jul 30 17:09:17 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 30 Jul 2025 17:09:17 GMT
Subject: RFR: 8364258: ThreadGroup constant pool serialization is not
 normalized [v2]
In-Reply-To: <gIJUvly5QIjQCZ8y483ZxIVRY292EivXkw5pXY_y8lY=.f600e5f0-677e-4c54-9bb0-8cc98598ab61@github.com>
References: <gIJUvly5QIjQCZ8y483ZxIVRY292EivXkw5pXY_y8lY=.f600e5f0-677e-4c54-9bb0-8cc98598ab61@github.com>
Message-ID: <v_WEdYeLYChULtHXf9t-aYyFsc_IUK-9B9DzIrPJ4wE=.a29a5f14-e736-43dc-8f34-7653ec29db53@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:

  const Handle

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26558/files
  - new: https://git.openjdk.org/jdk/pull/26558/files/cec818ab..8c025caf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26558&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26558&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 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 dcubed at openjdk.org  Wed Jul 30 17:10:57 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 30 Jul 2025 17:10:57 GMT
Subject: RFR: 8364314: java_lang_Thread::get_thread_status fails
 assert(base != nullptr) failed: Invalid base [v2]
In-Reply-To: <zEmmXnncIeBkHA6lfZBkOK3F19mjG1ExCad990UzhHM=.2c35f1aa-03c2-4588-8f4e-ce655c56256c@github.com>
References: <ceYO3eEp5YWA4T5oDbw3Tqv0f-GUh2xTBqxjuWdsJl8=.f594db6c-8064-4a7a-a467-75ba86e950bd@github.com>
 <zEmmXnncIeBkHA6lfZBkOK3F19mjG1ExCad990UzhHM=.2c35f1aa-03c2-4588-8f4e-ce655c56256c@github.com>
Message-ID: <jswrYb7J-yTCSIfMw4fl9X05xAH7phlOB-9wve9P-cU=.aa7e424c-35d2-47f4-b5a8-cde40f5a0170@github.com>

On Wed, 30 Jul 2025 06:24:39 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 with a new target base 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

Ping @mgronlun @egahlin:

In src/hotspot/share/jfr/jni/jfrJavaSupport.cpp, the static `get_native(ThreadsListHandle& tlh, jobject thread)`
function calls `cv_internal_thread_to_JavaThread`.  There are two other functions in /jfrJavaSupport.cpp
that call `get_native` and both of those functions create a ThreadsListHandle before make that call which
is good.

However, both `JfrJavaSupport::exclude` and `JfrJavaSupport::include` do their virtual thread processing
before the creation of the ThreadsListHandle so what is protecting the virtual thread and the underlying
carrier thread?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26544#issuecomment-3137179051

From shade at openjdk.org  Wed Jul 30 17:13:55 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 30 Jul 2025 17:13:55 GMT
Subject: RFR: 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: <6kvE6RUKnk9ppXVFj5ijcOXLXC_nSG0RovElXb6IqUU=.07edb443-35bd-4ad9-b5aa-7a23f2d30611@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.

src/hotspot/share/cds/filemap.cpp line 80:

> 78: 
> 79: #include <errno.h>
> 80: #include <sys/stat.h>

This looks off. Is this auto-generated order? 

The Style Guide (https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md) says:


- Put conditional inclusions (#if ...) at the end of the section of HotSpot include lines. 
  This also applies to macro-expanded includes of platform dependent files.
- Put system includes in a section after the HotSpot include lines with a blank line
  separating the two sections.
``` 

So maybe there is a bug in the include sorter?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26561#discussion_r2243365449

From dcubed at openjdk.org  Wed Jul 30 17:18:55 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 30 Jul 2025 17:18:55 GMT
Subject: RFR: 8364314: java_lang_Thread::get_thread_status fails
 assert(base != nullptr) failed: Invalid base [v2]
In-Reply-To: <zEmmXnncIeBkHA6lfZBkOK3F19mjG1ExCad990UzhHM=.2c35f1aa-03c2-4588-8f4e-ce655c56256c@github.com>
References: <ceYO3eEp5YWA4T5oDbw3Tqv0f-GUh2xTBqxjuWdsJl8=.f594db6c-8064-4a7a-a467-75ba86e950bd@github.com>
 <zEmmXnncIeBkHA6lfZBkOK3F19mjG1ExCad990UzhHM=.2c35f1aa-03c2-4588-8f4e-ce655c56256c@github.com>
Message-ID: <c_bd9Xr4l3uCvDZ9bP66Y5hlKfm4FXp0rS_SemwYDJQ=.a5f94863-4cd2-486f-8ec7-ab6b4aa469fc@github.com>

On Wed, 30 Jul 2025 06:24:39 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 with a new target base 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

For the calls to `tlh.cv_internal_thread_to_JavaThread` in src/hotspot/share/prims/jvm.cpp,
the new logic added by:
[JDK-8361912](https://bugs.openjdk.org/browse/JDK-8361912) ThreadsListHandle::cv_internal_thread_to_JavaThread does not deal with a virtual thread's carrier thread

will allow the carrier JavaThread to be returned to the caller.
However, NONE of the callers in jvm.cpp use a JvmtiVTMSTransitionDisabler
to prevent the virtual thread from being unmounted from the
carrier thread. So at the time of the remainder of the logic in
the JVM calls, the `JavaThread* receiver` may be a stale
carrier thread that no longer has a virtual thread mounted.

I don't know if this is an issue or not.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26544#issuecomment-3137198268

From dcubed at openjdk.org  Wed Jul 30 17:31:55 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 30 Jul 2025 17:31:55 GMT
Subject: RFR: 8364314: java_lang_Thread::get_thread_status fails
 assert(base != nullptr) failed: Invalid base [v2]
In-Reply-To: <zEmmXnncIeBkHA6lfZBkOK3F19mjG1ExCad990UzhHM=.2c35f1aa-03c2-4588-8f4e-ce655c56256c@github.com>
References: <ceYO3eEp5YWA4T5oDbw3Tqv0f-GUh2xTBqxjuWdsJl8=.f594db6c-8064-4a7a-a467-75ba86e950bd@github.com>
 <zEmmXnncIeBkHA6lfZBkOK3F19mjG1ExCad990UzhHM=.2c35f1aa-03c2-4588-8f4e-ce655c56256c@github.com>
Message-ID: <6tbjZ96WIS2sAMUyITyO2wP78hAr4p2nQbZ61L1uoV4=.f2c35d60-94e3-464f-b525-5789c41ede3e@github.com>

On Wed, 30 Jul 2025 06:24:39 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 with a new target base 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

In src/hotspot/share/prims/whitebox.cpp, we have three functions:
- WB_HandshakeReadMonitors
- WB_HandshakeWalkStack
- WB_AsyncHandshakeWalkStack

that call `tlh.cv_internal_thread_to_JavaThread` and each of them
does a handshake operation with the 'target' thread. If the `target`
is a virtual thread, then we'll do the handshake with the carrier thread
and not with the virtual thread. None of these functions in whitebox.cpp
use a JvmtiVTMSTransitionDisabler to prevent the virtual thread from
being unmounted from the carrier thread. I could be missing it, but I
don't see a way that the virtual thread info that _should be_ mounted
on the carrier thread is being passed to the handshake code. So what
does the handshake code do when it gets down into the guts and
the carrier thread no longer has a virtual thread mounted on it or if
a different virtual thread is mounted on it?

I'm not sure who to ping for answering this query.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26544#issuecomment-3137238546

From dcubed at openjdk.org  Wed Jul 30 17:35:55 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 30 Jul 2025 17:35:55 GMT
Subject: RFR: 8364314: java_lang_Thread::get_thread_status fails
 assert(base != nullptr) failed: Invalid base [v2]
In-Reply-To: <zEmmXnncIeBkHA6lfZBkOK3F19mjG1ExCad990UzhHM=.2c35f1aa-03c2-4588-8f4e-ce655c56256c@github.com>
References: <ceYO3eEp5YWA4T5oDbw3Tqv0f-GUh2xTBqxjuWdsJl8=.f594db6c-8064-4a7a-a467-75ba86e950bd@github.com>
 <zEmmXnncIeBkHA6lfZBkOK3F19mjG1ExCad990UzhHM=.2c35f1aa-03c2-4588-8f4e-ce655c56256c@github.com>
Message-ID: <i420TMDeS6uGSAw5X21BQoNgA7Dg-qaEnuDIv-SILEM=.2ec3d7d1-2292-4107-b853-2027c70cb189@github.com>

On Wed, 30 Jul 2025 06:24:39 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 with a new target base 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

@dholmes-ora - I went back and took a wider look at all the code that calls
`tlh.cv_internal_thread_to_JavaThread` and posted three more comments
that are really more related to the original work done with:
[JDK-8361912](https://bugs.openjdk.org/browse/JDK-8361912) ThreadsListHandle::cv_internal_thread_to_JavaThread does not deal with a virtual thread's carrier thread

I think for fixing the crash that we're seeing in the CI, this fix is good to go,
but I do think there are some wider questions that need to be addressed
about virtual threads, carrier threads and how things should work. Perhaps
I'm worried about nothing and the other callsites to `tlh.cv_internal_thread_to_JavaThread` 
are just fine...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26544#issuecomment-3137250608

From duke at openjdk.org  Wed Jul 30 17:39:56 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Wed, 30 Jul 2025 17:39:56 GMT
Subject: RFR: 8364359: Sort share/cds includes
In-Reply-To: <6kvE6RUKnk9ppXVFj5ijcOXLXC_nSG0RovElXb6IqUU=.07edb443-35bd-4ad9-b5aa-7a23f2d30611@github.com>
References: <9k50LwUaGiciMBE69S8FuJWN0pDbbwA5SCLK51mDVfk=.c0c92087-c47b-492c-a2d3-621a9d4711d6@github.com>
 <6kvE6RUKnk9ppXVFj5ijcOXLXC_nSG0RovElXb6IqUU=.07edb443-35bd-4ad9-b5aa-7a23f2d30611@github.com>
Message-ID: <ImjqGG2-lfxQ7tAxPcQUCPvN7FgO-LwKqYOw1bsQm9M=.fc710905-a713-423c-b14d-d5e932d8bd4e@github.com>

On Wed, 30 Jul 2025 17:10:45 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Is this auto-generated order?

No, I moved `errno.h` and `sys/stat.h` manually.

> The Style Guide says: [...]

So the expected order is:
- hotspot includes
- hotspot conditional includes
- system includes
- system conditional includes

I got a comment about include order in another PR, and I interpreted it as "conditional includes always at the bottom". Happy to have it clarified now, I'll push another commit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26561#discussion_r2243431025

From duke at openjdk.org  Wed Jul 30 17:43:09 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Wed, 30 Jul 2025 17:43:09 GMT
Subject: RFR: 8364359: Sort share/cds includes [v2]
In-Reply-To: <9k50LwUaGiciMBE69S8FuJWN0pDbbwA5SCLK51mDVfk=.c0c92087-c47b-492c-a2d3-621a9d4711d6@github.com>
References: <9k50LwUaGiciMBE69S8FuJWN0pDbbwA5SCLK51mDVfk=.c0c92087-c47b-492c-a2d3-621a9d4711d6@github.com>
Message-ID: <tudnCx23ISdFqeInejo_2kevhRNx-3NZmAabVjCsGA8=.5b11b1cb-791f-4b2f-9153-2ff27c7e2888@github.com>

> 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:

  system includes below

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26561/files
  - new: https://git.openjdk.org/jdk/pull/26561/files/d795a3c8..485177eb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26561&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26561&range=00-01

  Stats: 6 lines in 1 file changed: 3 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26561.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26561/head:pull/26561

PR: https://git.openjdk.org/jdk/pull/26561

From duke at openjdk.org  Wed Jul 30 17:43:10 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Wed, 30 Jul 2025 17:43:10 GMT
Subject: RFR: 8364359: Sort share/cds includes [v2]
In-Reply-To: <ImjqGG2-lfxQ7tAxPcQUCPvN7FgO-LwKqYOw1bsQm9M=.fc710905-a713-423c-b14d-d5e932d8bd4e@github.com>
References: <9k50LwUaGiciMBE69S8FuJWN0pDbbwA5SCLK51mDVfk=.c0c92087-c47b-492c-a2d3-621a9d4711d6@github.com>
 <6kvE6RUKnk9ppXVFj5ijcOXLXC_nSG0RovElXb6IqUU=.07edb443-35bd-4ad9-b5aa-7a23f2d30611@github.com>
 <ImjqGG2-lfxQ7tAxPcQUCPvN7FgO-LwKqYOw1bsQm9M=.fc710905-a713-423c-b14d-d5e932d8bd4e@github.com>
Message-ID: <eRNH3LjCIwqvTxwGpB7a32dtE3FP4haFskroh9LuwUo=.101d4c92-fd22-457e-9c54-a0c56ba7ce32@github.com>

On Wed, 30 Jul 2025 17:36:59 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> src/hotspot/share/cds/filemap.cpp line 80:
>> 
>>> 78: 
>>> 79: #include <errno.h>
>>> 80: #include <sys/stat.h>
>> 
>> This looks off. Is this auto-generated order? 
>> 
>> The Style Guide (https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md) says:
>> 
>> 
>> - Put conditional inclusions (#if ...) at the end of the section of HotSpot include lines. 
>>   This also applies to macro-expanded includes of platform dependent files.
>> - Put system includes in a section after the HotSpot include lines with a blank line
>>   separating the two sections.
>> ``` 
>> 
>> So maybe there is a bug in the include sorter?
>
>> Is this auto-generated order?
> 
> No, I moved `errno.h` and `sys/stat.h` manually.
> 
>> The Style Guide says: [...]
> 
> So the expected order is:
> - hotspot includes
> - hotspot conditional includes
> - system includes
> - system conditional includes
> 
> I got a comment about include order in another PR, and I interpreted it as "conditional includes always at the bottom". Happy to have it clarified now, I'll push another commit.

485177eb34e1ef76cf940b5860350ab5fcdc8cdc

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26561#discussion_r2243439123

From shade at openjdk.org  Wed Jul 30 17:48:55 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 30 Jul 2025 17:48:55 GMT
Subject: RFR: 8364359: Sort share/cds includes [v2]
In-Reply-To: <eRNH3LjCIwqvTxwGpB7a32dtE3FP4haFskroh9LuwUo=.101d4c92-fd22-457e-9c54-a0c56ba7ce32@github.com>
References: <9k50LwUaGiciMBE69S8FuJWN0pDbbwA5SCLK51mDVfk=.c0c92087-c47b-492c-a2d3-621a9d4711d6@github.com>
 <6kvE6RUKnk9ppXVFj5ijcOXLXC_nSG0RovElXb6IqUU=.07edb443-35bd-4ad9-b5aa-7a23f2d30611@github.com>
 <ImjqGG2-lfxQ7tAxPcQUCPvN7FgO-LwKqYOw1bsQm9M=.fc710905-a713-423c-b14d-d5e932d8bd4e@github.com>
 <eRNH3LjCIwqvTxwGpB7a32dtE3FP4haFskroh9LuwUo=.101d4c92-fd22-457e-9c54-a0c56ba7ce32@github.com>
Message-ID: <XyxoUNWzqihqSiIJF2HP7MUqGPSaX72lmDOUNaSCf0U=.b26c68ae-a940-4bb9-8133-ed810168aa6d@github.com>

On Wed, 30 Jul 2025 17:40:16 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>>> Is this auto-generated order?
>> 
>> No, I moved `errno.h` and `sys/stat.h` manually.
>> 
>>> The Style Guide says: [...]
>> 
>> So the expected order is:
>> - hotspot includes
>> - hotspot conditional includes
>> - system includes
>> - system conditional includes
>> 
>> I got a comment about include order in another PR, and I interpreted it as "conditional includes always at the bottom". Happy to have it clarified now, I'll push another commit.
>
> 485177eb34e1ef76cf940b5860350ab5fcdc8cdc

> So the expected order is:

Yes, this is my interpretation of the guide, and I think this is the established style.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26561#discussion_r2243454032

From sspitsyn at openjdk.org  Wed Jul 30 22:52:56 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 30 Jul 2025 22:52:56 GMT
Subject: RFR: 8306324: StopThread results in thread being marked as
 interrupted, leading to unexpected InterruptedException [v5]
In-Reply-To: <BRNPWlNjZbcr1roL0E4D2iuVkUvEX8_qsTkocmvLFL0=.44412b8e-7c0c-4d18-b936-e924a6b7dbbd@github.com>
References: <sDAklD-arV33IpWiJwMkwUfNPMAmsr5cgboU4y0hjhk=.192cd7e5-f2a2-4b5c-83a9-5111bf1926ec@github.com>
 <UYPujENcouAtWp9jPrM7r5bbQuOV-yV5Olc4t0tTju4=.962b0cab-b815-4de2-a84b-af6552f3dbdd@github.com>
 <BRNPWlNjZbcr1roL0E4D2iuVkUvEX8_qsTkocmvLFL0=.44412b8e-7c0c-4d18-b936-e924a6b7dbbd@github.com>
Message-ID: <A2EyPk81zSyiu5jU9VB46ztciOW1GME18dGFMs0ENwQ=.6dcc2d2c-b83a-49b5-8689-6bc469c1cc01@github.com>

On Wed, 30 Jul 2025 15:22:12 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:
>> 
>>   review: restored the tweak in the JavaThread::sleep_nanos
>
> src/hotspot/share/runtime/javaThread.cpp line 2121:
> 
>> 2119:   for (;;) {
>> 2120:     if (has_async_exception_condition()) {
>> 2121:       return false;
> 
> The comment above `JavaThread::sleep_nanos` should be updated about this case.
> Also, back in `JVM_SleepNanos` we should probably skip throwing IE for this case (even though it will be overwritten by the async one later).

Good suggestion, will address it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26365#discussion_r2244007729

From dcubed at openjdk.org  Wed Jul 30 22:59:59 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 30 Jul 2025 22:59:59 GMT
Subject: RFR: 8364314: java_lang_Thread::get_thread_status fails
 assert(base != nullptr) failed: Invalid base [v2]
In-Reply-To: <zEmmXnncIeBkHA6lfZBkOK3F19mjG1ExCad990UzhHM=.2c35f1aa-03c2-4588-8f4e-ce655c56256c@github.com>
References: <ceYO3eEp5YWA4T5oDbw3Tqv0f-GUh2xTBqxjuWdsJl8=.f594db6c-8064-4a7a-a467-75ba86e950bd@github.com>
 <zEmmXnncIeBkHA6lfZBkOK3F19mjG1ExCad990UzhHM=.2c35f1aa-03c2-4588-8f4e-ce655c56256c@github.com>
Message-ID: <fshvnh428tQEdJRj5BMpEKrocg45Tls4jq4AbJ_idqE=.9a7915af-aeb8-44bf-801f-d97df4642115@github.com>

On Wed, 30 Jul 2025 06:24:39 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 with a new target base 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.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26544#issuecomment-3138052866

From amenkov at openjdk.org  Wed Jul 30 23:17:53 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 30 Jul 2025 23:17:53 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: <7UYBa8RmnDBaABnvni-SCxIJoloraOHZtSk7XWz81n0=.ffb3629e-7e19-41af-80a3-b9c70241f5da@github.com>

On Wed, 30 Jul 2025 22:56:47 GMT, Daniel D. Daugherty <dcubed 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

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26544#issuecomment-3138080439

From pchilanomate at openjdk.org  Wed Jul 30 23:56:54 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 30 Jul 2025 23:56:54 GMT
Subject: RFR: 8364314: java_lang_Thread::get_thread_status fails
 assert(base != nullptr) failed: Invalid base [v2]
In-Reply-To: <zEmmXnncIeBkHA6lfZBkOK3F19mjG1ExCad990UzhHM=.2c35f1aa-03c2-4588-8f4e-ce655c56256c@github.com>
References: <ceYO3eEp5YWA4T5oDbw3Tqv0f-GUh2xTBqxjuWdsJl8=.f594db6c-8064-4a7a-a467-75ba86e950bd@github.com>
 <zEmmXnncIeBkHA6lfZBkOK3F19mjG1ExCad990UzhHM=.2c35f1aa-03c2-4588-8f4e-ce655c56256c@github.com>
Message-ID: <C7wF8ai41a466EU63pzNFUMT8sqm99ZAy5tFVVuYEh8=.adff2f27-c94e-4137-a3d0-583f9ffc5d9e@github.com>

On Wed, 30 Jul 2025 06:24:39 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 with a new target base 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 good to me.

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.

-------------

Marked as reviewed by pchilanomate (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26544#pullrequestreview-3073639113
PR Review Comment: https://git.openjdk.org/jdk/pull/26544#discussion_r2244071125

From pchilanomate at openjdk.org  Wed Jul 30 23:56:55 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 30 Jul 2025 23:56:55 GMT
Subject: RFR: 8364314: java_lang_Thread::get_thread_status fails
 assert(base != nullptr) failed: Invalid base [v2]
In-Reply-To: <c_bd9Xr4l3uCvDZ9bP66Y5hlKfm4FXp0rS_SemwYDJQ=.a5f94863-4cd2-486f-8ec7-ab6b4aa469fc@github.com>
References: <ceYO3eEp5YWA4T5oDbw3Tqv0f-GUh2xTBqxjuWdsJl8=.f594db6c-8064-4a7a-a467-75ba86e950bd@github.com>
 <zEmmXnncIeBkHA6lfZBkOK3F19mjG1ExCad990UzhHM=.2c35f1aa-03c2-4588-8f4e-ce655c56256c@github.com>
 <c_bd9Xr4l3uCvDZ9bP66Y5hlKfm4FXp0rS_SemwYDJQ=.a5f94863-4cd2-486f-8ec7-ab6b4aa469fc@github.com>
Message-ID: <WI428KIeJT2_hmWf2CClbcDyMVoPLwsKYxEdYE2R1gY=.c2f82906-93ff-4ca9-8197-d6474ef736f0@github.com>

On Wed, 30 Jul 2025 17:15:55 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> For the calls to `tlh.cv_internal_thread_to_JavaThread` in src/hotspot/share/prims/jvm.cpp, the new logic added by: [JDK-8361912](https://bugs.openjdk.org/browse/JDK-8361912) ThreadsListHandle::cv_internal_thread_to_JavaThread does not deal with a virtual thread's carrier thread
> 
> will allow the carrier JavaThread to be returned to the caller. However, NONE of the callers in jvm.cpp use a JvmtiVTMSTransitionDisabler to prevent the virtual thread from being unmounted from the carrier thread. So at the time of the remainder of the logic in the JVM calls, the `JavaThread* receiver` may be a stale carrier thread that no longer has a virtual thread mounted.
> 
> I don't know if this is an issue or not.
>
Those two methods should only be called for platform threads. `VirtualThread` class overrides `Thread.interrupt`, and `Thread.setPriority` ignores virtual threads. Maybe we should add an assert there after the JDK-8361912 changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26544#issuecomment-3138157865

From pchilanomate at openjdk.org  Thu Jul 31 00:18:54 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 31 Jul 2025 00:18:54 GMT
Subject: RFR: 8364314: java_lang_Thread::get_thread_status fails
 assert(base != nullptr) failed: Invalid base [v2]
In-Reply-To: <6tbjZ96WIS2sAMUyITyO2wP78hAr4p2nQbZ61L1uoV4=.f2c35d60-94e3-464f-b525-5789c41ede3e@github.com>
References: <ceYO3eEp5YWA4T5oDbw3Tqv0f-GUh2xTBqxjuWdsJl8=.f594db6c-8064-4a7a-a467-75ba86e950bd@github.com>
 <zEmmXnncIeBkHA6lfZBkOK3F19mjG1ExCad990UzhHM=.2c35f1aa-03c2-4588-8f4e-ce655c56256c@github.com>
 <6tbjZ96WIS2sAMUyITyO2wP78hAr4p2nQbZ61L1uoV4=.f2c35d60-94e3-464f-b525-5789c41ede3e@github.com>
Message-ID: <zsRhrxWKaAVSLwS8C_1B10ZWP5F_M5jkYWzAhunWzow=.b97db14e-dd09-4fbd-a5ed-9c798b53ea73@github.com>

On Wed, 30 Jul 2025 17:29:42 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> In src/hotspot/share/prims/whitebox.cpp, we have three functions:
> 
> * WB_HandshakeReadMonitors
> * WB_HandshakeWalkStack
> * WB_AsyncHandshakeWalkStack
> 
> that call `tlh.cv_internal_thread_to_JavaThread` and each of them does a handshake operation with the 'target' thread. If the `target` is a virtual thread, then we'll do the handshake with the carrier thread and not with the virtual thread. None of these functions in whitebox.cpp use a JvmtiVTMSTransitionDisabler to prevent the virtual thread from being unmounted from the carrier thread. I could be missing it, but I don't see a way that the virtual thread info that _should be_ mounted on the carrier thread is being passed to the handshake code. So what does the handshake code do when it gets down into the guts and the carrier thread no longer has a virtual thread mounted on it or if a different virtual thread is mounted on it?
> 
> I'm not sure who to ping for answering this query.
>
Currently these are only used in tests with platform threads. If we would pass a virtual thread as argument, then in those cases you mentioned we would read/print the state of some other thread in the handshake closure, but there shouldn?t be a crash.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26544#issuecomment-3138198215

From syan at openjdk.org  Thu Jul 31 01:41:10 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 31 Jul 2025 01:41:10 GMT
Subject: RFR: 8362501: Update
 test/hotspot/jtreg/applications/jcstress/README [v2]
In-Reply-To: <IaF3SoFbgcA8GCTuW14uUriIn3Os2U7Ep9L7tLpeH1Q=.8bc954be-f639-4f5a-b341-4dc2a8dbb223@github.com>
References: <Gv-CfzN4MbQDSvKMkXs6DWllE9saxTpkjIh92W8GkK4=.04b9e256-42cb-48de-a8e0-2345cdbc8b78@github.com>
 <_OAL4RIUkuwkPCOPg9arhmB71sz4xwkSsPuKzBVnLzo=.dc5503ee-2acf-4a03-b36d-e34c57b03d61@github.com>
 <IaF3SoFbgcA8GCTuW14uUriIn3Os2U7Ep9L7tLpeH1Q=.8bc954be-f639-4f5a-b341-4dc2a8dbb223@github.com>
Message-ID: <3G6Ih2_6xcrIoqv01iizczql8D6zzZTTmN0w12A1_uk=.d0abf66e-d085-4f93-8ef2-dfbb182c6a63@github.com>

On Fri, 25 Jul 2025 05:27:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update README
>
> Or @shipilev may be able to review?

Thanks for the reviews and suggestions @dholmes-ora @shipilev @lmesnik

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26369#issuecomment-3138297451

From syan at openjdk.org  Thu Jul 31 01:41:10 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 31 Jul 2025 01:41:10 GMT
Subject: Integrated: 8362501: Update
 test/hotspot/jtreg/applications/jcstress/README
In-Reply-To: <Gv-CfzN4MbQDSvKMkXs6DWllE9saxTpkjIh92W8GkK4=.04b9e256-42cb-48de-a8e0-2345cdbc8b78@github.com>
References: <Gv-CfzN4MbQDSvKMkXs6DWllE9saxTpkjIh92W8GkK4=.04b9e256-42cb-48de-a8e0-2345cdbc8b78@github.com>
Message-ID: <F8yRgDpu82y3KoNCQW_493qYT7RVMkY-ZlzLVQN2rxk=.43947fe3-1dc7-42d0-a3a4-fb634df55ef6@github.com>

On Thu, 17 Jul 2025 12:29:00 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Currently, this is no documentation on how to run the application/jcstress tests. I think it will be useful to complement the document test/hotspot/jtreg/applications/jcstress/README on how to run the jcstress tests in jtreg.
> 
> No behaviour has been change, only update the ducumentation, no risk.

This pull request has now been integrated.

Changeset: 559795b0
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/559795b0eb8061325127fa9fdf8b80617fe47166
Stats:     8 lines in 1 file changed: 4 ins; 1 del; 3 mod

8362501: Update test/hotspot/jtreg/applications/jcstress/README

Reviewed-by: shade, lmesnik

-------------

PR: https://git.openjdk.org/jdk/pull/26369

From sspitsyn at openjdk.org  Thu Jul 31 03:37:35 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 31 Jul 2025 03:37:35 GMT
Subject: RFR: 8306324: StopThread results in thread being marked as
 interrupted, leading to unexpected InterruptedException [v6]
In-Reply-To: <sDAklD-arV33IpWiJwMkwUfNPMAmsr5cgboU4y0hjhk=.192cd7e5-f2a2-4b5c-83a9-5111bf1926ec@github.com>
References: <sDAklD-arV33IpWiJwMkwUfNPMAmsr5cgboU4y0hjhk=.192cd7e5-f2a2-4b5c-83a9-5111bf1926ec@github.com>
Message-ID: <S_dBvV8TCSyC63Z1zPq0kKYnljBqOLEyfbRJnhdvOqU=.8401dc7e-e17f-4e9f-bd94-79c077a62440@github.com>

> 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:

  review: correct comment in sleep_nanos and avoid trowing IE in JVM_SleepNanos

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26365/files
  - new: https://git.openjdk.org/jdk/pull/26365/files/a46ef6f5..476665cb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26365&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26365&range=04-05

  Stats: 7 lines in 2 files changed: 1 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/26365.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26365/head:pull/26365

PR: https://git.openjdk.org/jdk/pull/26365

From sspitsyn at openjdk.org  Thu Jul 31 03:45:10 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 31 Jul 2025 03:45:10 GMT
Subject: RFR: 8306324: StopThread results in thread being marked as
 interrupted, leading to unexpected InterruptedException [v7]
In-Reply-To: <sDAklD-arV33IpWiJwMkwUfNPMAmsr5cgboU4y0hjhk=.192cd7e5-f2a2-4b5c-83a9-5111bf1926ec@github.com>
References: <sDAklD-arV33IpWiJwMkwUfNPMAmsr5cgboU4y0hjhk=.192cd7e5-f2a2-4b5c-83a9-5111bf1926ec@github.com>
Message-ID: <uyFxRbd5zvitt4VhzYOUtefXo8o2pd1D2VN26jVDtYM=.d13c4b61-4583-4302-9692-cd391d767b9d@github.com>

> 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

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26365/files
  - new: https://git.openjdk.org/jdk/pull/26365/files/476665cb..11bc5a78

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26365&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26365&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26365.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26365/head:pull/26365

PR: https://git.openjdk.org/jdk/pull/26365

From sspitsyn at openjdk.org  Thu Jul 31 07:31:54 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 31 Jul 2025 07:31:54 GMT
Subject: RFR: 8306324: StopThread results in thread being marked as
 interrupted, leading to unexpected InterruptedException [v5]
In-Reply-To: <A2EyPk81zSyiu5jU9VB46ztciOW1GME18dGFMs0ENwQ=.6dcc2d2c-b83a-49b5-8689-6bc469c1cc01@github.com>
References: <sDAklD-arV33IpWiJwMkwUfNPMAmsr5cgboU4y0hjhk=.192cd7e5-f2a2-4b5c-83a9-5111bf1926ec@github.com>
 <UYPujENcouAtWp9jPrM7r5bbQuOV-yV5Olc4t0tTju4=.962b0cab-b815-4de2-a84b-af6552f3dbdd@github.com>
 <BRNPWlNjZbcr1roL0E4D2iuVkUvEX8_qsTkocmvLFL0=.44412b8e-7c0c-4d18-b936-e924a6b7dbbd@github.com>
 <A2EyPk81zSyiu5jU9VB46ztciOW1GME18dGFMs0ENwQ=.6dcc2d2c-b83a-49b5-8689-6bc469c1cc01@github.com>
Message-ID: <yiGnwEOil9Z6TTd0XiaiCax42OmdIoOQHl1GzODFnbM=.3e38dc60-871b-4b2d-8a0d-f6d1c4ede0c5@github.com>

On Wed, 30 Jul 2025 22:49:51 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/runtime/javaThread.cpp line 2121:
>> 
>>> 2119:   for (;;) {
>>> 2120:     if (has_async_exception_condition()) {
>>> 2121:       return false;
>> 
>> The comment above `JavaThread::sleep_nanos` should be updated about this case.
>> Also, back in `JVM_SleepNanos` we should probably skip throwing IE for this case (even though it will be overwritten by the async one later).
>
> Good suggestion, addressed now.

The mach5 tiers 1-6 are good with the latest pushes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26365#discussion_r2244579652

From alanb at openjdk.org  Thu Jul 31 07:42:55 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 31 Jul 2025 07:42:55 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: <NpX4T03NeDCLmFVL7EiORifCJkOMY7coSDJnEfcuJuA=.8ea68d65-5c31-4874-92ec-f6b390cb5333@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

Thanks for getting this to a good place.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26365#pullrequestreview-3074321124

From ayang at openjdk.org  Thu Jul 31 10:43:26 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 31 Jul 2025 10:43:26 GMT
Subject: RFR: 8263476: NMT: Stack guard pages should not be marked as committed
Message-ID: <BojYWaP10BJMEWDQYSRiMKR0cOWzMF5At9_3fwD6uUw=.becf6902-01f1-41e0-965d-18a945a6dfcf@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

-------------

Commit messages:
 - no-commit-stack-guard-page

Changes: https://git.openjdk.org/jdk/pull/26571/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26571&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8263476
  Stats: 25 lines in 8 files changed: 3 ins; 8 del; 14 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 sspitsyn at openjdk.org  Thu Jul 31 11:01:56 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 31 Jul 2025 11:01:56 GMT
Subject: RFR: 8364314: java_lang_Thread::get_thread_status fails
 assert(base != nullptr) failed: Invalid base [v2]
In-Reply-To: <zEmmXnncIeBkHA6lfZBkOK3F19mjG1ExCad990UzhHM=.2c35f1aa-03c2-4588-8f4e-ce655c56256c@github.com>
References: <ceYO3eEp5YWA4T5oDbw3Tqv0f-GUh2xTBqxjuWdsJl8=.f594db6c-8064-4a7a-a467-75ba86e950bd@github.com>
 <zEmmXnncIeBkHA6lfZBkOK3F19mjG1ExCad990UzhHM=.2c35f1aa-03c2-4588-8f4e-ce655c56256c@github.com>
Message-ID: <IHmlCe8TGUTl8vAhpFTy8qvpEPKJojT_uNiBSwYs7PE=.eb1fedcf-03c6-41b0-8e47-4f1cad2e1fcb@github.com>

On Wed, 30 Jul 2025 06:24:39 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 with a new target base 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

This is a reasonable safety fix. Looks good to me modulo comment wording which is being disussed.

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26544#pullrequestreview-3074937785

From sspitsyn at openjdk.org  Thu Jul 31 11:01:56 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 31 Jul 2025 11:01:56 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: <PhLK3TavJru-xZZPGVNxFHvMI2RS45VItxnhUCmkIRk=.62f9d26c-d0f1-4160-9d37-e95710aae36f@github.com>

On Wed, 30 Jul 2025 23:14:52 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Right. The issue was discovered several weeks ago: https://bugs.openjdk.org/browse/JDK-8361913 Work in progress

Also, I think a `TransitionDisabler` is more safe to install before the `cv_internal_thread_to_JavaThread()` is called. It would also prevent this bug to reproduce.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26544#issuecomment-3139469403

From alanb at openjdk.org  Thu Jul 31 12:09:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 31 Jul 2025 12:09:54 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: <v7oMpIrrQG5rEy7XY-99u22GpM9VXu3-QgXItFefchw=.6f8e5048-55cf-4346-b6d2-94b147dbb31a@github.com>

On Wed, 30 Jul 2025 23:14:52 GMT, Alex Menkov <amenkov 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.

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.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26544#issuecomment-3139703254

From shade at openjdk.org  Thu Jul 31 12:33:56 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 31 Jul 2025 12:33:56 GMT
Subject: RFR: 8364359: Sort share/cds includes [v2]
In-Reply-To: <tudnCx23ISdFqeInejo_2kevhRNx-3NZmAabVjCsGA8=.5b11b1cb-791f-4b2f-9153-2ff27c7e2888@github.com>
References: <9k50LwUaGiciMBE69S8FuJWN0pDbbwA5SCLK51mDVfk=.c0c92087-c47b-492c-a2d3-621a9d4711d6@github.com>
 <tudnCx23ISdFqeInejo_2kevhRNx-3NZmAabVjCsGA8=.5b11b1cb-791f-4b2f-9153-2ff27c7e2888@github.com>
Message-ID: <YSSIzb4G6dUe0Gg2aATlf-eGClFUXeAAnVar43LOb8s=.aa1bcc60-b7ea-4616-9069-68eeb06e9fbc@github.com>

On Wed, 30 Jul 2025 17:43:09 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:
> 
>   system includes below

Looks good to me with a minor nit. But I have missed things before, so someone else needs to take a look as well. For example @iklam or @calvinccheung, who are often in this area.

test/hotspot/jtreg/sources/TestIncludesAreSorted.java line 49:

> 47:                     "share/c1",
> 48:                     "share/ci",
> 49:                     "share/cds",

Unordered: `cds` < `ci`?

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26561#pullrequestreview-3075203723
PR Review Comment: https://git.openjdk.org/jdk/pull/26561#discussion_r2245250011

From duke at openjdk.org  Thu Jul 31 12:58:38 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Thu, 31 Jul 2025 12:58:38 GMT
Subject: RFR: 8364359: Sort share/cds includes [v3]
In-Reply-To: <9k50LwUaGiciMBE69S8FuJWN0pDbbwA5SCLK51mDVfk=.c0c92087-c47b-492c-a2d3-621a9d4711d6@github.com>
References: <9k50LwUaGiciMBE69S8FuJWN0pDbbwA5SCLK51mDVfk=.c0c92087-c47b-492c-a2d3-621a9d4711d6@github.com>
Message-ID: <EXjfd_1v6IhM-rKuFxp1AyIQq0tWCiTYs-bQJ5-BUQ0=.c0fc2846-7bbe-40b2-b5a0-d0c38ae021fd@github.com>

> 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

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26561/files
  - new: https://git.openjdk.org/jdk/pull/26561/files/485177eb..9d2f432a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26561&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26561&range=01-02

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26561.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26561/head:pull/26561

PR: https://git.openjdk.org/jdk/pull/26561

From duke at openjdk.org  Thu Jul 31 12:58:38 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Thu, 31 Jul 2025 12:58:38 GMT
Subject: RFR: 8364359: Sort share/cds includes [v2]
In-Reply-To: <YSSIzb4G6dUe0Gg2aATlf-eGClFUXeAAnVar43LOb8s=.aa1bcc60-b7ea-4616-9069-68eeb06e9fbc@github.com>
References: <9k50LwUaGiciMBE69S8FuJWN0pDbbwA5SCLK51mDVfk=.c0c92087-c47b-492c-a2d3-621a9d4711d6@github.com>
 <tudnCx23ISdFqeInejo_2kevhRNx-3NZmAabVjCsGA8=.5b11b1cb-791f-4b2f-9153-2ff27c7e2888@github.com>
 <YSSIzb4G6dUe0Gg2aATlf-eGClFUXeAAnVar43LOb8s=.aa1bcc60-b7ea-4616-9069-68eeb06e9fbc@github.com>
Message-ID: <1zJK-GNj0jSzp9MIyUx5jVnBnCXg8pbpn_ijFZ3M1d4=.23822beb-33c6-4391-bf68-b2afd87c3bd2@github.com>

On Thu, 31 Jul 2025 12:30:48 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   system includes below
>
> test/hotspot/jtreg/sources/TestIncludesAreSorted.java line 49:
> 
>> 47:                     "share/c1",
>> 48:                     "share/ci",
>> 49:                     "share/cds",
> 
> Unordered: `cds` < `ci`?

9d2f432

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26561#discussion_r2245307104

From tschatzl at openjdk.org  Thu Jul 31 14:12:02 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 31 Jul 2025 14:12:02 GMT
Subject: RFR: 8364197: G1: Sort G1 mutex locks by name and group them
 together
In-Reply-To: <B5FNCKmtQVjqfdL_N7Q3PwShuBMBQa0XclRMRmq5d_c=.bf8ee2a6-d161-4181-aba7-31c489bd7a3d@github.com>
References: <PhF7nBjpjmPAJ7UHSyfYJbdRouucweAcwMmYk_pnctg=.694ddeb5-7eb6-404a-aaed-35bdce957bb1@github.com>
 <B5FNCKmtQVjqfdL_N7Q3PwShuBMBQa0XclRMRmq5d_c=.bf8ee2a6-d161-4181-aba7-31c489bd7a3d@github.com>
Message-ID: <yR7_ZPE8zGlyZLKNqIcJhYw16Bxol5kiy97PU86y13Q=.5b1a1194-4615-4d4c-95ce-5a5c0ae0419c@github.com>

On Wed, 30 Jul 2025 14:11:21 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change to put together G1 mutex definitions/declarations and sort them. That makes it easier for me to verify changes in that area.
>> 
>> Testing: local compilation
>> 
>> Thanks,
>>   Thomas
>
> Marked as reviewed by ayang (Reviewer).

Thanks @albertnetymk @coleenp for your reviews

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26508#issuecomment-3140119237

From tschatzl at openjdk.org  Thu Jul 31 14:12:03 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 31 Jul 2025 14:12:03 GMT
Subject: Integrated: 8364197: G1: Sort G1 mutex locks by name and group them
 together
In-Reply-To: <PhF7nBjpjmPAJ7UHSyfYJbdRouucweAcwMmYk_pnctg=.694ddeb5-7eb6-404a-aaed-35bdce957bb1@github.com>
References: <PhF7nBjpjmPAJ7UHSyfYJbdRouucweAcwMmYk_pnctg=.694ddeb5-7eb6-404a-aaed-35bdce957bb1@github.com>
Message-ID: <aOQXycEtn1bAq0LetBBeJuamwEnRRPdlLXQREzooiMs=.d1bc5808-c82b-4306-8d9a-eaf2fc4596c6@github.com>

On Mon, 28 Jul 2025 14:44:20 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change to put together G1 mutex definitions/declarations and sort them. That makes it easier for me to verify changes in that area.
> 
> Testing: local compilation
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 5f357fa2
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5f357fa27d89a3ead3783a3197ba4c576802cb7a
Stats:     44 lines in 2 files changed: 21 ins; 15 del; 8 mod

8364197: G1: Sort G1 mutex locks by name and group them together

Reviewed-by: coleenp, ayang

-------------

PR: https://git.openjdk.org/jdk/pull/26508

From alanb at openjdk.org  Thu Jul 31 14:18:56 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 31 Jul 2025 14:18:56 GMT
Subject: RFR: 8364314: java_lang_Thread::get_thread_status fails
 assert(base != nullptr) failed: Invalid base [v2]
In-Reply-To: <zEmmXnncIeBkHA6lfZBkOK3F19mjG1ExCad990UzhHM=.2c35f1aa-03c2-4588-8f4e-ce655c56256c@github.com>
References: <ceYO3eEp5YWA4T5oDbw3Tqv0f-GUh2xTBqxjuWdsJl8=.f594db6c-8064-4a7a-a467-75ba86e950bd@github.com>
 <zEmmXnncIeBkHA6lfZBkOK3F19mjG1ExCad990UzhHM=.2c35f1aa-03c2-4588-8f4e-ce655c56256c@github.com>
Message-ID: <-WeIeOX_JNhFcgNg8Y2NJzYPwQwxjVu0MMXPej6CJ3c=.830a06d9-4c22-49b8-8478-2831921518ab@github.com>

On Wed, 30 Jul 2025 06:24:39 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 with a new target base 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.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26544#discussion_r2245520952

From shade at openjdk.org  Thu Jul 31 15:19:54 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 31 Jul 2025 15:19:54 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: <RTyOsJypce65EheKLv-YE8otc7jFjPMyC1JMRRPTsPw=.85836dbe-ac98-4e18-83b6-56c19ac57def@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

Marked as reviewed by shade (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26561#pullrequestreview-3075870426

From ayang at openjdk.org  Thu Jul 31 15:43:04 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 31 Jul 2025 15:43:04 GMT
Subject: RFR: 8363949: Incorrect jtreg header in
 MonitorWithDeadObjectTest.java
In-Reply-To: <aL9b5b-GATHLDCakKIztuhSCKTK9bE3EKPmiZtUNO4g=.677e7a91-7f18-4d40-8650-4367a1bbae33@github.com>
References: <aL9b5b-GATHLDCakKIztuhSCKTK9bE3EKPmiZtUNO4g=.677e7a91-7f18-4d40-8650-4367a1bbae33@github.com>
Message-ID: <IH2HjCEXkLhVIfATiaxuEAt8A8DTdW_pg1LYjj5hwxM=.6ba549eb-b284-4644-8412-1e7b72ae9fe1@github.com>

On Tue, 29 Jul 2025 09:18:40 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> the mentioned test fails if run standalone with the following error: 
> Error: Not a test or directory containing tests: runtime/Monitor/MonitorWithDeadObjectTest.java
> 
> The order of jtreg tags is not correct, to make it pass standalone it is sufficient to put @test first in each test.

Marked as reviewed by ayang (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26527#pullrequestreview-3075949913

From duke at openjdk.org  Thu Jul 31 15:43:05 2025
From: duke at openjdk.org (Anton Artemov)
Date: Thu, 31 Jul 2025 15:43:05 GMT
Subject: Integrated: 8363949: Incorrect jtreg header in
 MonitorWithDeadObjectTest.java
In-Reply-To: <aL9b5b-GATHLDCakKIztuhSCKTK9bE3EKPmiZtUNO4g=.677e7a91-7f18-4d40-8650-4367a1bbae33@github.com>
References: <aL9b5b-GATHLDCakKIztuhSCKTK9bE3EKPmiZtUNO4g=.677e7a91-7f18-4d40-8650-4367a1bbae33@github.com>
Message-ID: <Hpqma6SHJicKceVno7DmoOq3V_orp0RfRN6WphB_eAI=.7ad3037b-5ab3-4e53-b84a-749d761242cc@github.com>

On Tue, 29 Jul 2025 09:18:40 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> the mentioned test fails if run standalone with the following error: 
> Error: Not a test or directory containing tests: runtime/Monitor/MonitorWithDeadObjectTest.java
> 
> The order of jtreg tags is not correct, to make it pass standalone it is sufficient to put @test first in each test.

This pull request has now been integrated.

Changeset: c4fbfa21
Author:    Anton Artemov <anton.artemov at oracle.com>
Committer: Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c4fbfa21030c9a0e8a3e0eed1b0a0988eba08ddb
Stats:     6 lines in 1 file changed: 3 ins; 3 del; 0 mod

8363949: Incorrect jtreg header in MonitorWithDeadObjectTest.java

Reviewed-by: stefank, coleenp, ayang

-------------

PR: https://git.openjdk.org/jdk/pull/26527

From pchilanomate at openjdk.org  Thu Jul 31 15:57:55 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 31 Jul 2025 15:57:55 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: <0pW1wrr7ZPPK3faGmXIAhDi_f9pTaH-e6g8yVfw7g5o=.b068df42-b52d-4f1c-8c32-aaddd496d81f@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

Thanks Serguei, looks good to me.

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.

-------------

Marked as reviewed by pchilanomate (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26365#pullrequestreview-3075988282
PR Review Comment: https://git.openjdk.org/jdk/pull/26365#discussion_r2245769502

From mgronlun at openjdk.org  Thu Jul 31 18:24:38 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 31 Jul 2025 18:24:38 GMT
Subject: RFR: 8364258: ThreadGroup constant pool serialization is not
 normalized [v3]
In-Reply-To: <gIJUvly5QIjQCZ8y483ZxIVRY292EivXkw5pXY_y8lY=.f600e5f0-677e-4c54-9bb0-8cc98598ab61@github.com>
References: <gIJUvly5QIjQCZ8y483ZxIVRY292EivXkw5pXY_y8lY=.f600e5f0-677e-4c54-9bb0-8cc98598ab61@github.com>
Message-ID: <VMC36hkBX9-11dKJ_ocSs2N4bVecaJrcyL5qir9B2gU=.7e6e556f-d857-419d-bcd8-77c62985cea8@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:

  remove unused setter because of intrusive list

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26558/files
  - new: https://git.openjdk.org/jdk/pull/26558/files/8c025caf..3434343a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26558&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26558&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 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 iklam at openjdk.org  Thu Jul 31 20:00:06 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 31 Jul 2025 20:00:06 GMT
Subject: RFR: 8364454: ProblemList runtime/cds/DeterministicDump.java on macos
 for JDK-8363986
Message-ID: <vyYktqcsqjBwfXdkJXvL0B03VW5cpqUoPtZ5vTm25k0=.0304ed4e-f9a5-4145-b2c1-e9b43313416a@github.com>

The fix for JDK-8363986 is in progress but may take some time. ProblemList this test for now to avoid noise in testing.

-------------

Commit messages:
 - 8364454: ProblemList runtime/cds/DeterministicDump.java on macos for JDK-8363986

Changes: https://git.openjdk.org/jdk/pull/26578/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26578&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364454
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26578.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26578/head:pull/26578

PR: https://git.openjdk.org/jdk/pull/26578

From ccheung at openjdk.org  Thu Jul 31 20:00:06 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 31 Jul 2025 20:00:06 GMT
Subject: RFR: 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: <0PEC7lDGkopYldlUKw9UGm35co3M2ANGiW9xxlzubuw=.55b155d3-6cd3-487c-a141-c013105921b0@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.

Looks good and trivial to me.

-------------

Marked as reviewed by ccheung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26578#pullrequestreview-3076722372

From mgronlun at openjdk.org  Thu Jul 31 20:37:17 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 31 Jul 2025 20:37:17 GMT
Subject: RFR: 8364258: ThreadGroup constant pool serialization is not
 normalized [v4]
In-Reply-To: <gIJUvly5QIjQCZ8y483ZxIVRY292EivXkw5pXY_y8lY=.f600e5f0-677e-4c54-9bb0-8cc98598ab61@github.com>
References: <gIJUvly5QIjQCZ8y483ZxIVRY292EivXkw5pXY_y8lY=.f600e5f0-677e-4c54-9bb0-8cc98598ab61@github.com>
Message-ID: <zDcom3nY_baiySxF1Wox7ADEO38CECUWN7TeiUEu_N0=.88faa7d4-5395-4c6a-8764-e36e7aaf48a6@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:

  extend is_serialized scheme to JavaThreads

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26558/files
  - new: https://git.openjdk.org/jdk/pull/26558/files/3434343a..e973f67b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26558&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26558&range=02-03

  Stats: 38 lines in 3 files changed: 29 ins; 0 del; 9 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  Thu Jul 31 20:49:40 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 31 Jul 2025 20:49:40 GMT
Subject: RFR: 8364258: ThreadGroup constant pool serialization is not
 normalized [v5]
In-Reply-To: <gIJUvly5QIjQCZ8y483ZxIVRY292EivXkw5pXY_y8lY=.f600e5f0-677e-4c54-9bb0-8cc98598ab61@github.com>
References: <gIJUvly5QIjQCZ8y483ZxIVRY292EivXkw5pXY_y8lY=.f600e5f0-677e-4c54-9bb0-8cc98598ab61@github.com>
Message-ID: <1v_-nvJ23wTH984L50yKDaB3Onuna27PnpBAST4U1s8=.0dd882ce-bf65-46a7-87f2-8214f6799d9f@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:

  adjustment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26558/files
  - new: https://git.openjdk.org/jdk/pull/26558/files/e973f67b..0691e4c5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26558&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26558&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 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  Thu Jul 31 21:18:14 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 31 Jul 2025 21:18:14 GMT
Subject: RFR: 8364258: ThreadGroup constant pool serialization is not
 normalized [v6]
In-Reply-To: <gIJUvly5QIjQCZ8y483ZxIVRY292EivXkw5pXY_y8lY=.f600e5f0-677e-4c54-9bb0-8cc98598ab61@github.com>
References: <gIJUvly5QIjQCZ8y483ZxIVRY292EivXkw5pXY_y8lY=.f600e5f0-677e-4c54-9bb0-8cc98598ab61@github.com>
Message-ID: <LAYJyPzZD7a9nCIFpHG9MKFQx_3ZUwBhf3wVuwuuDxI=.4dad1c72-163d-46f9-8b2d-54ad3eb149b3@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:

  minimal window

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26558/files
  - new: https://git.openjdk.org/jdk/pull/26558/files/0691e4c5..c73a8f91

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26558&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26558&range=04-05

  Stats: 10 lines in 3 files changed: 1 ins; 4 del; 5 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 iklam at openjdk.org  Thu Jul 31 22:05:00 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 31 Jul 2025 22:05:00 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: <mqG8kYqxHxLvjUPz5moU7mQL8evo7gQCJ8uTxkN5wxg=.25c6f668-f59a-4da8-bc06-b55b1f768809@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

LGTM

-------------

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26561#pullrequestreview-3077016290

From duke at openjdk.org  Thu Jul 31 22:39:55 2025
From: duke at openjdk.org (duke)
Date: Thu, 31 Jul 2025 22:39:55 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: <nbK33oEDnIASZpiK3pxmDT6Ldp0Dz8b_gWRxlmJn-U0=.a685f8ce-f02a-4cab-93b4-ea77a7f562a0@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

@fandreuz 
Your change (at version 9d2f432a7818cf6b7b47ddf1a1227d41aa1a6a21) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26561#issuecomment-3141546859