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