From djelinski at openjdk.org  Mon Dec  1 11:03:15 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 1 Dec 2025 11:03:15 GMT
Subject: jmx-dev RFR: 8353738: Update TLS unit tests to not use
 certificates with MD5 signatures [v7]
In-Reply-To: <DTog6sfC8efnL2ysENz2zRAVGWNuGZ7hfE8mxrwP1vo=.dcf5fc1f-9188-4fd4-a2c2-e0930d2c257d@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
 <DTog6sfC8efnL2ysENz2zRAVGWNuGZ7hfE8mxrwP1vo=.dcf5fc1f-9188-4fd4-a2c2-e0930d2c257d@github.com>
Message-ID: <Q15PCCegrjbDS-CKa2jsyLoOeaAyvKLV3a5018Deb9g=.70160d1c-2168-4cbe-aa05-45569271111c@github.com>

On Mon, 24 Nov 2025 17:22:39 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA.
>
> Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
> 
>  - Updated IPAddressDNSIdentities and confirmed test fails for correct reason
>  - Merge branch 'master' into update-md5-certs
>  - Updated SAN methods in CertificateBuilder to take multiple names
>  - Merge branch 'master' into update-md5-certs
>  - removed IPIdentitites.java because it's identical to IPAddressIPIdenties; added IPv6 SAN ext
>  - removed unused keystore files, fixed certificate chain
>  - Merge branch 'master' into update-md5-certs
>  - changed line wrapping
>  - removed unnecessary comment and made getSSLContext(...) private
>  - changed tests to use SecurityUtils.removeDisabled*Algs methods
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/d0629285...ea9c2dce

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27342#pullrequestreview-3524380076

From mdonovan at openjdk.org  Mon Dec  1 12:21:04 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Mon, 1 Dec 2025 12:21:04 GMT
Subject: jmx-dev Integrated: 8353738: Update TLS unit tests to not use
 certificates with MD5 signatures
In-Reply-To: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
Message-ID: <KiVDvQMrcUC7gXrOaTXnGTgkn39UhSTGczGfyPrlU0Q=.4b6c2f93-e61a-4a58-883a-7501554ac7b8@github.com>

On Wed, 17 Sep 2025 11:50:51 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA.

This pull request has now been integrated.

Changeset: f5eecc45
Author:    Matthew Donovan <mdonovan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f5eecc454eb78fc1a3714dfe3cb94113238dd3ac
Stats:     3481 lines in 14 files changed: 402 ins; 2957 del; 122 mod

8353738: Update TLS unit tests to not use certificates with MD5 signatures

Reviewed-by: djelinski, abarashev

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

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

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

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

>> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes.
>> 
>> This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes:
>> 
>> - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. 
>> An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable transitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version.
>> 
>> - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`.
>> 
>> - The code was previously structured in t...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   missing to initialize _is_disabler_at_start

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

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

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

Suggestion:

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

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

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

The comment is helpful, thanks.

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

Marked as reviewed by coleenp (Reviewer).

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

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

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

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

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

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

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

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

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

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

okay.  seems like a better place for it.

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

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

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

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

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

Looks good.

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

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

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

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

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

So why do you need one in java_lang_Thread then?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes.
> 
> This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes:
> 
> - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. 
> An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable transitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version.
> 
> - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`.
> 
> - The code was previously structured in terms of mount and un...

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

  Fix comment in inline_native_vthread_start_transition

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

On Mon, 1 Dec 2025 23:00:16 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes.
>> 
>> This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes:
>> 
>> - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. 
>> An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable transitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version.
>> 
>> - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`.
>> 
>> - The code was previously structured in t...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in inline_native_vthread_start_transition

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

Thanks

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

Marked as reviewed by dholmes (Reviewer).

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

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

On Mon, 1 Dec 2025 23:00:16 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes.
>> 
>> This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes:
>> 
>> - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. 
>> An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable transitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version.
>> 
>> - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`.
>> 
>> - The code was previously structured in t...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in inline_native_vthread_start_transition

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

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

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

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

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

From pchilanomate at openjdk.org  Tue Dec  2 20:12:47 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 2 Dec 2025 20:12:47 GMT
Subject: jmx-dev RFR: 8364343: Virtual Thread transition management
 needs to be independent of JVM TI [v11]
In-Reply-To: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
Message-ID: <URdOE6ZdBSqYc7LrGrVReCSpFh-KVt0IuuC8TIyfsJw=.b98e6ea7-1b29-487d-bf93-0aaf7259cc3c@github.com>

> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes.
> 
> This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes:
> 
> - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. 
> An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable transitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version.
> 
> - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`.
> 
> - The code was previously structured in terms of mount and un...

Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:

 - Merge branch 'master' into JDK-8364343
 - rebind in end_transition only for mount case
 - Fix comment in inline_native_vthread_start_transition
 - missing to initialize _is_disabler_at_start
 - More changes from Coleen's review
 - Drop VTMS from names
 - keep preexisting rebind order for mount
 - Remove INCLUDE_JVMTI macro
 - David's comments
 - Rename VM methods for endFirstTransition/startFinalTransition
 - ... and 3 more: https://git.openjdk.org/jdk/compare/836ae793...1f1cd594

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

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

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

  Stats: 84290 lines in 1350 files changed: 54871 ins; 20868 del; 8551 mod
  Patch: https://git.openjdk.org/jdk/pull/28361.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28361/head:pull/28361

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

From pchilanomate at openjdk.org  Tue Dec  2 20:12:49 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 2 Dec 2025 20:12:49 GMT
Subject: jmx-dev RFR: 8364343: Virtual Thread transition management
 needs to be independent of JVM TI [v10]
In-Reply-To: <U0XMaJ4ujyejqeQTvz4l7ZwUf2IWRPWKZj3ptQMSOBs=.5ec74fa7-bff5-4220-9916-02209c34dbc9@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <T8jvz_3r2GJ8W55gqHXsRkNhMPRy3hLGF7ClwP84CM0=.c69c727e-6628-4aa2-92ca-e596542cf0e0@github.com>
 <U0XMaJ4ujyejqeQTvz4l7ZwUf2IWRPWKZj3ptQMSOBs=.5ec74fa7-bff5-4220-9916-02209c34dbc9@github.com>
Message-ID: <PP54KIhtKoCuuWU8YMqeEzY-p2NK8sI_6cUuGfE7-II=.2aa2a463-aba8-460b-b1eb-97d179e69ec7@github.com>

On Tue, 2 Dec 2025 06:20:44 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Nothing further from me. Again a great piece of work!
> 
> Thanks
>
Thanks for the review David!

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

PR Comment: https://git.openjdk.org/jdk/pull/28361#issuecomment-3603774217

From pchilanomate at openjdk.org  Tue Dec  2 20:20:32 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 2 Dec 2025 20:20:32 GMT
Subject: jmx-dev RFR: 8364343: Virtual Thread transition management
 needs to be independent of JVM TI [v11]
In-Reply-To: <jw0XiQQN7uLuurYCvcroRUTtpvzKYgKXpU1_lKcRWMo=.d06cff86-674b-4f54-951e-c83867e79f43@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <FPqDAUXw_1ZtwQLFHIgv1HAANXJn4kCHtofPMhG_gmw=.c05ba258-723f-4abc-b35a-ca29f02a4df5@github.com>
 <jFNO_Y3Ag0QIDP4INNnPUNDYjcoGHFZ83C3mebo7o9U=.dc183f1f-5f99-479f-832c-8af9c4fcf72a@github.com>
 <nW9xOi2sq3K_3ZpNyvvgzUf2p0roZU8hkKxcEtvK1nI=.03abf855-5f7b-4055-972c-8cff69df3816@github.com>
 <jw0XiQQN7uLuurYCvcroRUTtpvzKYgKXpU1_lKcRWMo=.d06cff86-674b-4f54-951e-c83867e79f43@github.com>
Message-ID: <X2XiyWz5DzOg4pXBxrYeCA_f2V3WNM2Rn58dZRhUOuw=.43b6aa7c-6533-49ce-adc6-93c6e397ed8f@github.com>

On Mon, 1 Dec 2025 19:46:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I renamed the methods as suggested. I remembered that we separated ThreadStart/ThreadEnd in 8306028 for future improvements related to JVMTI. Not sure if that?s still relevant but in any case probably better to leave that discussion for a separate bug.
>
> Given the comment block to define the terms "mount transition" and "unmount transition" then we could go a bit further and make it 6 methods: start/endMountTransition, start/endUnmountTransition, endFirstMountTransition and  startLastUnmountTransition. We don't have to do it now, but it would make the use-sites clearer I think.

Sounds good, filed https://bugs.openjdk.org/browse/JDK-8372953.

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

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

From pchilanomate at openjdk.org  Tue Dec  2 20:20:30 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 2 Dec 2025 20:20:30 GMT
Subject: jmx-dev RFR: 8364343: Virtual Thread transition management
 needs to be independent of JVM TI [v10]
In-Reply-To: <P9Too5Wi39kpbuKEdC6zi1AaV_gEdwV769JRMtd2Fz8=.10605426-19ce-45cc-a9de-47aaea2b118e@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <T8jvz_3r2GJ8W55gqHXsRkNhMPRy3hLGF7ClwP84CM0=.c69c727e-6628-4aa2-92ca-e596542cf0e0@github.com>
 <P9Too5Wi39kpbuKEdC6zi1AaV_gEdwV769JRMtd2Fz8=.10605426-19ce-45cc-a9de-47aaea2b118e@github.com>
Message-ID: <5iEOi2ZO_ZVQbanlfWXhjIyGMQvZ4rt09LIK9YP-bgg=.5d15e13d-81cc-4843-bdb2-244841949808@github.com>

On Tue, 2 Dec 2025 08:15:53 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix comment in inline_native_vthread_start_transition
>
> src/hotspot/share/runtime/mountUnmountDisabler.cpp line 88:
> 
>> 86:         // We rebinded on start_transition but the mount/unmount operation
>> 87:         // failed so now we need to rebind to the original state.
>> 88:         _current->rebind_to_jvmti_thread_state_of(_is_mount ? _vthread() : _current->threadObj());
> 
> Q: Not sure I fully understand this comment. We have done a rebind at the line 67 for an unmount transition only. But this comment tells that it was done for mount transition as well. Also, before this update, we used to do a rebind of `JvmtiThreadState` to a vthread in the `JvmtiVTMSTransitionDisabler::VTMS_mount_end()` for the normal (not failed) case. Please, could you explain a little bit more? It feels like this comment needs a correction.

Yes, well spotted. I changed it to rebind the state only for the mount case, as in current code. This already handles a successful mount or a failed unmount. I also added and assert to verify we rebinded to the correct identity.

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

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

From sspitsyn at openjdk.org  Tue Dec  2 20:31:30 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 2 Dec 2025 20:31:30 GMT
Subject: jmx-dev RFR: 8364343: Virtual Thread transition management
 needs to be independent of JVM TI [v11]
In-Reply-To: <URdOE6ZdBSqYc7LrGrVReCSpFh-KVt0IuuC8TIyfsJw=.b98e6ea7-1b29-487d-bf93-0aaf7259cc3c@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <URdOE6ZdBSqYc7LrGrVReCSpFh-KVt0IuuC8TIyfsJw=.b98e6ea7-1b29-487d-bf93-0aaf7259cc3c@github.com>
Message-ID: <JMq7LxVJ7_B1ypy-DDaeTJMKGO_9VPvQiWqb2JUkLAY=.3eea6f9e-723a-42c2-aa1b-6d6dab0f3279@github.com>

On Tue, 2 Dec 2025 20:12:47 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes.
>> 
>> This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes:
>> 
>> - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. 
>> An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable transitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version.
>> 
>> - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`.
>> 
>> - The code was previously structured in t...
>
> Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8364343
>  - rebind in end_transition only for mount case
>  - Fix comment in inline_native_vthread_start_transition
>  - missing to initialize _is_disabler_at_start
>  - More changes from Coleen's review
>  - Drop VTMS from names
>  - keep preexisting rebind order for mount
>  - Remove INCLUDE_JVMTI macro
>  - David's comments
>  - Rename VM methods for endFirstTransition/startFinalTransition
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/4b22489c...1f1cd594

Marked as reviewed by sspitsyn (Reviewer).

Yes, this is a great work!

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

> 85:       }
> 86:       DEBUG_ONLY(bool is_virtual = java_lang_VirtualThread::is_instance(_current->jvmti_vthread()));
> 87:       assert((_is_mount && is_virtual) || (!_is_mount && !is_virtual), "wrong identity");

Nit: Thank you for update! This check can be simplified with:

      assert(_is_mount == is_virtual), "wrong identity");

But it becomes more obscure though. Feel free to ignore this comment.

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

PR Review: https://git.openjdk.org/jdk/pull/28361#pullrequestreview-3531985682
PR Comment: https://git.openjdk.org/jdk/pull/28361#issuecomment-3603842122
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2582681780

From pchilanomate at openjdk.org  Tue Dec  2 20:42:29 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 2 Dec 2025 20:42:29 GMT
Subject: jmx-dev RFR: 8364343: Virtual Thread transition management
 needs to be independent of JVM TI [v12]
In-Reply-To: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
Message-ID: <ckP6AwbDS--WqWEY7u8G85IQPYfmDt40jARAB_L6ciU=.929ba610-4e03-4cee-a71b-98361517d697@github.com>

> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes.
> 
> This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes:
> 
> - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. 
> An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable transitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version.
> 
> - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`.
> 
> - The code was previously structured in terms of mount and un...

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

  simplify assert

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28361/files
  - new: https://git.openjdk.org/jdk/pull/28361/files/1f1cd594..7ffbbc6d

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

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

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

From pchilanomate at openjdk.org  Tue Dec  2 20:42:30 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 2 Dec 2025 20:42:30 GMT
Subject: jmx-dev RFR: 8364343: Virtual Thread transition management
 needs to be independent of JVM TI [v11]
In-Reply-To: <JMq7LxVJ7_B1ypy-DDaeTJMKGO_9VPvQiWqb2JUkLAY=.3eea6f9e-723a-42c2-aa1b-6d6dab0f3279@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <URdOE6ZdBSqYc7LrGrVReCSpFh-KVt0IuuC8TIyfsJw=.b98e6ea7-1b29-487d-bf93-0aaf7259cc3c@github.com>
 <JMq7LxVJ7_B1ypy-DDaeTJMKGO_9VPvQiWqb2JUkLAY=.3eea6f9e-723a-42c2-aa1b-6d6dab0f3279@github.com>
Message-ID: <AC_Jcyka6ot70oBXchaghxIeJq6jkvCY2t_DIMiXEI8=.dbfa623b-0aaf-48ae-a7e4-9d1e6b4ec28a@github.com>

On Tue, 2 Dec 2025 20:28:22 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Yes, this is a great work!
>
Thanks for the review Serguei!

> src/hotspot/share/runtime/mountUnmountDisabler.cpp line 87:
> 
>> 85:       }
>> 86:       DEBUG_ONLY(bool is_virtual = java_lang_VirtualThread::is_instance(_current->jvmti_vthread()));
>> 87:       assert((_is_mount && is_virtual) || (!_is_mount && !is_virtual), "wrong identity");
> 
> Nit: Thank you for update! This check can be simplified with:
> 
>       assert(_is_mount == is_virtual), "wrong identity");
> 
> But it becomes more obscure though. Feel free to ignore this comment.

I applied the suggestion, it reads well to me.

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

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

From sspitsyn at openjdk.org  Tue Dec  2 21:22:12 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 2 Dec 2025 21:22:12 GMT
Subject: jmx-dev RFR: 8364343: Virtual Thread transition management
 needs to be independent of JVM TI [v12]
In-Reply-To: <ckP6AwbDS--WqWEY7u8G85IQPYfmDt40jARAB_L6ciU=.929ba610-4e03-4cee-a71b-98361517d697@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <ckP6AwbDS--WqWEY7u8G85IQPYfmDt40jARAB_L6ciU=.929ba610-4e03-4cee-a71b-98361517d697@github.com>
Message-ID: <fPa-U_4A3CzC8YNAyCALLvAZNeIcQkc_2sasnhcCAgs=.d0dd726a-411c-4547-9062-86650c7113cf@github.com>

On Tue, 2 Dec 2025 20:42:29 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes.
>> 
>> This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes:
>> 
>> - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. 
>> An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable transitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version.
>> 
>> - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`.
>> 
>> - The code was previously structured in t...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify assert

Marked as reviewed by sspitsyn (Reviewer).

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

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

From kevinw at openjdk.org  Wed Dec  3 10:05:30 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 3 Dec 2025 10:05:30 GMT
Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache
 creation [v11]
In-Reply-To: <dGQiREV1bRcNuIAhjHDSSsR6369oD24FlT7Ud1U2_ok=.8aa2ac09-dc96-48b0-8de2-e3ca6457386f@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <dGQiREV1bRcNuIAhjHDSSsR6369oD24FlT7Ud1U2_ok=.8aa2ac09-dc96-48b0-8de2-e3ca6457386f@github.com>
Message-ID: <CUcdfulNom90fhuZZOM5TtD3CaxWXOKXuiLHNET5AmQ=.06bb6eba-ec1f-42c8-82c0-7cba07d1d32e@github.com>

On Wed, 26 Nov 2025 20:35:11 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
>> 
>> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
>> 
>> TRUE
>> FALSE
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed spaces and CRLF

src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 78:

> 76:    * <p>For more information about creating and using the AOT artifacts, and detailed
> 77:    * specification of the corresponding JVM command-line options, please refer
> 78:    * to <a href="https://openjdk.org/jeps/483">483</a> and <a href="https://openjdk.org/jeps/514">514</a>.

One more late nit: these links have just the raw number in the link text. Better to have:

* to <a href="https://openjdk.org/jeps/483">JEP 483</a> and <a href="https://openjdk.org/jeps/514">JEP 514</a>.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2584438379

From pchilanomate at openjdk.org  Wed Dec  3 15:27:06 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 3 Dec 2025 15:27:06 GMT
Subject: jmx-dev RFR: 8364343: Virtual Thread transition management
 needs to be independent of JVM TI [v13]
In-Reply-To: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
Message-ID: <p6lFKQ-dibdBFgeRjm2oaHSE1MwKSJ1x4gUXJNQRBX4=.96d83b12-93af-44c8-a0d5-50cb7e8e7b8d@github.com>

> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes.
> 
> This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes:
> 
> - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. 
> An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable transitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version.
> 
> - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`.
> 
> - The code was previously structured in terms of mount and un...

Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - Merge branch 'master' into JDK-8364343
 - simplify assert
 - Merge branch 'master' into JDK-8364343
 - rebind in end_transition only for mount case
 - Fix comment in inline_native_vthread_start_transition
 - missing to initialize _is_disabler_at_start
 - More changes from Coleen's review
 - Drop VTMS from names
 - keep preexisting rebind order for mount
 - Remove INCLUDE_JVMTI macro
 - ... and 5 more: https://git.openjdk.org/jdk/compare/829b8581...444ac0ce

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

Changes: https://git.openjdk.org/jdk/pull/28361/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28361&range=12
  Stats: 1957 lines in 41 files changed: 914 ins; 823 del; 220 mod
  Patch: https://git.openjdk.org/jdk/pull/28361.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28361/head:pull/28361

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

From macarte at openjdk.org  Wed Dec  3 15:27:54 2025
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 3 Dec 2025 15:27:54 GMT
Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache
 creation [v8]
In-Reply-To: <ftPvHBlncWJz1yN6Gjclx4Z-QcgHijYUp2tJ1wQfP8Q=.ebd2ac22-0e3a-4f2f-83aa-4c753b6e806d@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <Tr-Hep5GKs8WK18D22iF09MA78Yf-AqmDN7lnXj7Lzs=.35a44c9a-6bce-4c9a-aa7f-e14051a1d2ec@github.com>
 <ftPvHBlncWJz1yN6Gjclx4Z-QcgHijYUp2tJ1wQfP8Q=.ebd2ac22-0e3a-4f2f-83aa-4c753b6e806d@github.com>
Message-ID: <1xvBfNax6BA3eMN--W-IcfjlKVcMd_vJq9Gh9edqtmg=.a489f78b-6a8f-4ada-a6fc-87a667ad6a7d@github.com>

On Fri, 21 Nov 2025 11:50:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove single whitespace
>
> test/hotspot/jtreg/runtime/cds/appcds/aotCache/HotSpotAOTCacheMXBeanTest.java line 45:
> 
>> 43: import jdk.test.lib.process.OutputAnalyzer;
>> 44: 
>> 45: public class HotSpotAOTCacheMXBeanTest {
> 
> In addition to testing the endRecording operation, we also need to test both the direct and indirect access to the MXBean. The test currently obtains a proxy with newPlatformMXBeanProxy (good) but the direct access with ManagementFactory.getPlatformMXBean is not tested right now.
> 
> Another thing to test is that getObjectName returns the expected object name.

Agreed and I will add these additional tests in a subsequent PR

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2585561932

From macarte at openjdk.org  Wed Dec  3 17:23:37 2025
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 3 Dec 2025 17:23:37 GMT
Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache
 creation [v12]
In-Reply-To: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
Message-ID: <S9zq5vNrG8dXfRi-rLA58Lr2T4t9TF6LWS8ouA3vcig=.b6a62909-5dd8-4fe8-9c46-487f28be4813@github.com>

> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
> 
> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
> 
> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
> 
> TRUE
> FALSE
> 
> Passes tier1 on linux (x64) and windows (x64)

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

  Small doc change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28010/files
  - new: https://git.openjdk.org/jdk/pull/28010/files/0086e0ec..6024cf2e

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

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

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

From coleenp at openjdk.org  Wed Dec  3 17:24:10 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 3 Dec 2025 17:24:10 GMT
Subject: jmx-dev RFR: 8364343: Virtual Thread transition management
 needs to be independent of JVM TI [v13]
In-Reply-To: <p6lFKQ-dibdBFgeRjm2oaHSE1MwKSJ1x4gUXJNQRBX4=.96d83b12-93af-44c8-a0d5-50cb7e8e7b8d@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <p6lFKQ-dibdBFgeRjm2oaHSE1MwKSJ1x4gUXJNQRBX4=.96d83b12-93af-44c8-a0d5-50cb7e8e7b8d@github.com>
Message-ID: <xP9VPEsVoZNBEwVWfHCpiGaTR3BftJNSn0Q9NtIANg0=.49345947-5b9e-46e8-aa4c-0df492af83fe@github.com>

On Wed, 3 Dec 2025 15:27:06 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes.
>> 
>> This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes:
>> 
>> - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. 
>> An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable transitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version.
>> 
>> - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`.
>> 
>> - The code was previously structured in t...
>
> Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Merge branch 'master' into JDK-8364343
>  - simplify assert
>  - Merge branch 'master' into JDK-8364343
>  - rebind in end_transition only for mount case
>  - Fix comment in inline_native_vthread_start_transition
>  - missing to initialize _is_disabler_at_start
>  - More changes from Coleen's review
>  - Drop VTMS from names
>  - keep preexisting rebind order for mount
>  - Remove INCLUDE_JVMTI macro
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/829b8581...444ac0ce

Still good! Maybe you should wait for the last three GHA actions to finish first

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

Marked as reviewed by coleenp (Reviewer).

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

From macarte at openjdk.org  Wed Dec  3 18:05:39 2025
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 3 Dec 2025 18:05:39 GMT
Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache
 creation [v13]
In-Reply-To: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
Message-ID: <telpnxu2IwUklNb4a7PIyMk9er8fZQ5yMwn4Uzo6VWs=.396e33fa-1524-4254-bf01-4f0d5f1d98f9@github.com>

> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
> 
> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
> 
> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
> 
> TRUE
> FALSE
> 
> Passes tier1 on linux (x64) and windows (x64)

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

  Removed superfluous library

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28010/files
  - new: https://git.openjdk.org/jdk/pull/28010/files/6024cf2e..67400da9

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

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

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

From macarte at openjdk.org  Wed Dec  3 18:05:42 2025
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 3 Dec 2025 18:05:42 GMT
Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache
 creation [v8]
In-Reply-To: <ftPvHBlncWJz1yN6Gjclx4Z-QcgHijYUp2tJ1wQfP8Q=.ebd2ac22-0e3a-4f2f-83aa-4c753b6e806d@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <Tr-Hep5GKs8WK18D22iF09MA78Yf-AqmDN7lnXj7Lzs=.35a44c9a-6bce-4c9a-aa7f-e14051a1d2ec@github.com>
 <ftPvHBlncWJz1yN6Gjclx4Z-QcgHijYUp2tJ1wQfP8Q=.ebd2ac22-0e3a-4f2f-83aa-4c753b6e806d@github.com>
Message-ID: <CN17j92gSz5UikhTYA9KE6oDSAk6o8b8Emkn4lLdPG4=.6d7d314a-f207-4bc8-bfc5-1d58dd5c6398@github.com>

On Fri, 21 Nov 2025 11:44:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove single whitespace
>
> test/hotspot/jtreg/runtime/cds/appcds/aotCache/HotSpotAOTCacheMXBeanTest.java line 31:
> 
>> 29:  * @requires vm.cds.write.archived.java.heap
>> 30:  * @library /test/jdk/lib/testlibrary /test/lib
>> 31:  *          /test/hotspot/jtreg/runtime/cds/appcds/aotCache/test-classes
> 
> Is test-classes used?

Tested and removed, thank you!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2586114349

From kevinw at openjdk.org  Wed Dec  3 18:15:13 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 3 Dec 2025 18:15:13 GMT
Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache
 creation [v13]
In-Reply-To: <telpnxu2IwUklNb4a7PIyMk9er8fZQ5yMwn4Uzo6VWs=.396e33fa-1524-4254-bf01-4f0d5f1d98f9@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <telpnxu2IwUklNb4a7PIyMk9er8fZQ5yMwn4Uzo6VWs=.396e33fa-1524-4254-bf01-4f0d5f1d98f9@github.com>
Message-ID: <mBqDaHJoy5Jh8wfuNbjXrJxhX9LEk_C2LuK0Z2a7cDU=.c17e4966-071f-4808-8095-f11b02b255c0@github.com>

On Wed, 3 Dec 2025 18:05:39 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
>> 
>> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
>> 
>> TRUE
>> FALSE
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed superfluous library

Looks good, thanks for the updates.
Would be great if you can get to the 4 vs 2 indent note from Alan.

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28010#pullrequestreview-3536328651

From macarte at openjdk.org  Wed Dec  3 19:17:50 2025
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 3 Dec 2025 19:17:50 GMT
Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache
 creation [v14]
In-Reply-To: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
Message-ID: <rTxyRGAykexX1pJvT-C9gdnzlox3PaV5HsWZUbd4tWk=.b8266a59-b1af-4c2f-9aef-461561d84ca2@github.com>

> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
> 
> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
> 
> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
> 
> TRUE
> FALSE
> 
> Passes tier1 on linux (x64) and windows (x64)

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

  Fixed indent and spacing issues

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28010/files
  - new: https://git.openjdk.org/jdk/pull/28010/files/67400da9..6cd920da

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

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

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

From macarte at openjdk.org  Wed Dec  3 19:40:07 2025
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 3 Dec 2025 19:40:07 GMT
Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache
 creation [v8]
In-Reply-To: <exRz3HQ-bV93DEgOuUZxw3NRkQlBtxK734A8jTw70i8=.9498a654-570a-4746-a751-f0bc3d58a688@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <Tr-Hep5GKs8WK18D22iF09MA78Yf-AqmDN7lnXj7Lzs=.35a44c9a-6bce-4c9a-aa7f-e14051a1d2ec@github.com>
 <exRz3HQ-bV93DEgOuUZxw3NRkQlBtxK734A8jTw70i8=.9498a654-570a-4746-a751-f0bc3d58a688@github.com>
Message-ID: <ct5U7Bzb-43CkS0AZb_QuDzafz34vAVcF0F0nRpTXGw=.c3216144-d8b9-4159-bf9a-c054d31444d6@github.com>

On Fri, 21 Nov 2025 11:33:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove single whitespace
>
> src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 97:
> 
>> 95:    * successfully; {@code false} otherwise.
>> 96:    */
>> 97:    public boolean endRecording();
> 
> Minor nit is that we usually use 4-space rather than 2-space indent in the java sources. You might want to check the /** .. */ comments in a few of the files as they are misaligned in a few places.

fixed - thank you

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2586374138

From pchilanomate at openjdk.org  Wed Dec  3 20:01:11 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 3 Dec 2025 20:01:11 GMT
Subject: jmx-dev RFR: 8364343: Virtual Thread transition management
 needs to be independent of JVM TI [v13]
In-Reply-To: <xP9VPEsVoZNBEwVWfHCpiGaTR3BftJNSn0Q9NtIANg0=.49345947-5b9e-46e8-aa4c-0df492af83fe@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <p6lFKQ-dibdBFgeRjm2oaHSE1MwKSJ1x4gUXJNQRBX4=.96d83b12-93af-44c8-a0d5-50cb7e8e7b8d@github.com>
 <xP9VPEsVoZNBEwVWfHCpiGaTR3BftJNSn0Q9NtIANg0=.49345947-5b9e-46e8-aa4c-0df492af83fe@github.com>
Message-ID: <plvMeLzQ8ppJ9pZsbY18b-L6RBEIFapI3Ex3L71zQkY=.0b000a39-22f7-49c6-993b-4b5979f80f93@github.com>

On Wed, 3 Dec 2025 17:21:33 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Still good! Maybe you should wait for the last three GHA actions to finish first
>
Done now. Thanks for the re-review Coleen!

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

PR Comment: https://git.openjdk.org/jdk/pull/28361#issuecomment-3608600548

From pchilanomate at openjdk.org  Wed Dec  3 20:04:36 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 3 Dec 2025 20:04:36 GMT
Subject: jmx-dev Integrated: 8364343: Virtual Thread transition management
 needs to be independent of JVM TI
In-Reply-To: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
Message-ID: <R7yo6-n9jaF5YwNegJZRZpbmgaQj7HSl3ozX0cF_sb0=.90ad397f-075e-4387-921f-0c5d3ac9d939@github.com>

On Mon, 17 Nov 2025 20:19:58 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes.
> 
> This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes:
> 
> - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. 
> An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable transitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version.
> 
> - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`.
> 
> - The code was previously structured in terms of mount and un...

This pull request has now been integrated.

Changeset: e534ee99
Author:    Patricio Chilano Mateo <pchilanomate at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e534ee99327fed2263302a00061fb46fcdc6e302
Stats:     1957 lines in 41 files changed: 914 ins; 823 del; 220 mod

8364343: Virtual Thread transition management needs to be independent of JVM TI

Co-authored-by: Alan Bateman <alanb at openjdk.org>
Reviewed-by: coleenp, dholmes, sspitsyn

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

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

From mr at openjdk.org  Wed Dec  3 20:47:40 2025
From: mr at openjdk.org (Mark Reinhold)
Date: Wed, 3 Dec 2025 20:47:40 GMT
Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache
 creation [v12]
In-Reply-To: <S9zq5vNrG8dXfRi-rLA58Lr2T4t9TF6LWS8ouA3vcig=.b6a62909-5dd8-4fe8-9c46-487f28be4813@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <S9zq5vNrG8dXfRi-rLA58Lr2T4t9TF6LWS8ouA3vcig=.b6a62909-5dd8-4fe8-9c46-487f28be4813@github.com>
Message-ID: <2BNyWIHsF3Idzqy1u0MlC_K6nvb_k6_aWOKzHXhf1PQ=.326df265-59ff-4fe9-a244-dc88246a4afb@github.com>

On Wed, 3 Dec 2025 17:23:37 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
>> 
>> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
>> 
>> TRUE
>> FALSE
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Small doc change

Changes requested by mr (Lead).

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

PR Review: https://git.openjdk.org/jdk/pull/28010#pullrequestreview-3536758143

From mr at openjdk.org  Wed Dec  3 20:47:48 2025
From: mr at openjdk.org (Mark Reinhold)
Date: Wed, 3 Dec 2025 20:47:48 GMT
Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache
 creation [v11]
In-Reply-To: <dGQiREV1bRcNuIAhjHDSSsR6369oD24FlT7Ud1U2_ok=.8aa2ac09-dc96-48b0-8de2-e3ca6457386f@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <dGQiREV1bRcNuIAhjHDSSsR6369oD24FlT7Ud1U2_ok=.8aa2ac09-dc96-48b0-8de2-e3ca6457386f@github.com>
Message-ID: <1vNADqcyDvebfWHyjYF0BEgWb7-xhh_f2GHdBnEaZQQ=.9415cb27-f2b8-4214-86b2-72772d7cb278@github.com>

On Wed, 26 Nov 2025 20:35:11 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
>> 
>> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
>> 
>> TRUE
>> FALSE
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed spaces and CRLF

src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 37:

> 35:  * <p> The management interface is registered with the platform {@link MBeanServer
> 36:  * MBeanServer}. The {@link ObjectName ObjectName} that uniquely identifies the management
> 37:  * interface within the {@code MBeanServer} is: "jdk.management:type=HotSpotAOTCache".

Drop the colon after "is", and put the object name in `{@code ...}` rather than double quotes.

src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 44:

> 42:  * {@code HotSpotAOTCacheMXBean} defines one operation at this time to
> 43:  * end the AOT recording. More operations and/or properties may be added in a
> 44:  * future release.

Drop this paragraph. It's obvious that there's only one operation, and uncertain statements about future releases add no value.

src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 50:

> 48: public interface HotSpotAOTCacheMXBean extends PlatformManagedObject {
> 49:   /**
> 50:    * If an AOT recording is in progress, ends the recording. This operation completes

s/operation completes/method returns/

src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 53:

> 51:    * after the AOT artifacts have been completely written.
> 52:    *
> 53:    * <p>The JVM will start recording AOT artifacts upon start-up if certain JVM options are

s/certain/appropriate/ -- "certain" suggests that you're not going to tell the reader what they are.

src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 57:

> 55:    * the {@code endRecording} method is called. Examples:
> 56:    *
> 57:    * <p> java -XX:AOTCacheOutput=app.aot ....

Put this command, and the others below, in `{@code ...}`, and precede them with a dollar prompt (`$`) so that they look more like command lines.

src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 63:

> 61:    *    that will be used to generate the AOT cache file app.aot. In a future execution of this application,
> 62:    *    -XX:AOTCache=app.aot can be provided to improve the application's
> 63:    *    start-up and warm-up performance.

Tighten and clarify: `The JVM records optimization information for the current application in the AOT cache file {@code app.aot}. in a future run of the application, the option {@code -XX:AOTCache=app.aot} will cause the JVM to use the cache to improve the application's startup and warmup performance.`

src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 69:

> 67:    *
> 68:    * <blockquote>
> 69:    *    The JVM will record optimization information about the current application

`The JVM records optimization information for the current application in the AOT configuration file {@code app.aotconfig}. ...`

src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 84:

> 82:    *
> 83:    * <p> There are also no APIs to querying whether the AOT recording is in progress, or what AOT
> 84:    * artifacts are being recorded.

Drop "Note:", it's meaningless. Merge these two paragraphs. s/to querying/to query/. s/the AOT/an AOT/.

src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 92:

> 90:    * procedures rely on an external agent to select the correct moment to end training.
> 91:    * In this way the selected length of training produces the correct set of AOT
> 92:    * optimizations in the AOT archive, without interfering with the application code.

You seem to be saying here that using this method from within an application is not necessarily the best approach, but you say it in a very roundabout way. Consider something like:

     * This method enables an application to end its own AOT recording
     * programatically, but that is not necessarily the best approach. Doing so
     * requires changing the application?s code, which might not be
     * feasible. Even when it is feasible, injecting training-specific logic
     * into the application reduces the similarity between training runs and
     * production runs, potentially making the AOT cache less effective. It may
     * be better to arrange for an external agent to end the training run,
     * thereby creating an AOT cache without interfering with the application?s
     * code.
 ```

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2586483272
PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2586486393
PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2586493320
PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2586488596
PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2586490840
PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2586506998
PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2586509392
PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2586515533
PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2586550031

From mr at openjdk.org  Wed Dec  3 20:47:50 2025
From: mr at openjdk.org (Mark Reinhold)
Date: Wed, 3 Dec 2025 20:47:50 GMT
Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache
 creation [v11]
In-Reply-To: <CUcdfulNom90fhuZZOM5TtD3CaxWXOKXuiLHNET5AmQ=.06bb6eba-ec1f-42c8-82c0-7cba07d1d32e@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <dGQiREV1bRcNuIAhjHDSSsR6369oD24FlT7Ud1U2_ok=.8aa2ac09-dc96-48b0-8de2-e3ca6457386f@github.com>
 <CUcdfulNom90fhuZZOM5TtD3CaxWXOKXuiLHNET5AmQ=.06bb6eba-ec1f-42c8-82c0-7cba07d1d32e@github.com>
Message-ID: <C4YPT2GKTm42OjocWetcXwiTJ7xKDNppLKVNXxMkudg=.53fa3511-0cc2-442d-8f76-28328e0e5c8a@github.com>

On Wed, 3 Dec 2025 10:02:55 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed spaces and CRLF
>
> src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 78:
> 
>> 76:    * <p>For more information about creating and using the AOT artifacts, and detailed
>> 77:    * specification of the corresponding JVM command-line options, please refer
>> 78:    * to <a href="https://openjdk.org/jeps/483">483</a> and <a href="https://openjdk.org/jeps/514">514</a>.
> 
> One more late nit: these links have just the raw number in the link text. Better to have:
> 
> * to <a href="https://openjdk.org/jeps/483">JEP 483</a> and <a href="https://openjdk.org/jeps/514">JEP 514</a>.

My original suggestion was to say `please refer to JEPs <a href=...>483</a> and <a href=...>514</a>`, but this is fine, too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2586511793

From macarte at openjdk.org  Wed Dec  3 22:29:24 2025
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 3 Dec 2025 22:29:24 GMT
Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache
 creation [v15]
In-Reply-To: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
Message-ID: <HiF5EwAj4DlTEOa85zqXgd2RbgbQjLNayJ6925N00ZU=.34ad1757-d497-4166-b9c7-745c8d82d228@github.com>

> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
> 
> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
> 
> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
> 
> TRUE
> FALSE
> 
> Passes tier1 on linux (x64) and windows (x64)

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

  Incorporate feedback into documentation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28010/files
  - new: https://git.openjdk.org/jdk/pull/28010/files/6cd920da..8b0e27f2

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

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

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

From iklam at openjdk.org  Mon Dec  8 17:59:58 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 8 Dec 2025 17:59:58 GMT
Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache
 creation [v15]
In-Reply-To: <HiF5EwAj4DlTEOa85zqXgd2RbgbQjLNayJ6925N00ZU=.34ad1757-d497-4166-b9c7-745c8d82d228@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <HiF5EwAj4DlTEOa85zqXgd2RbgbQjLNayJ6925N00ZU=.34ad1757-d497-4166-b9c7-745c8d82d228@github.com>
Message-ID: <zRzo1bngRxh42bVMgTw_XPwiMuStUUGRxw19k44oygc=.c8dcb7e7-8a7f-4c11-81fe-cd600b907b72@github.com>

On Wed, 3 Dec 2025 22:29:24 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
>> 
>> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
>> 
>> TRUE
>> FALSE
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporate feedback into documentation

Looks good to me.

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

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28010#pullrequestreview-3553358656

From macarte at openjdk.org  Mon Dec  8 18:29:02 2025
From: macarte at openjdk.org (Mat Carter)
Date: Mon, 8 Dec 2025 18:29:02 GMT
Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache
 creation [v15]
In-Reply-To: <zRzo1bngRxh42bVMgTw_XPwiMuStUUGRxw19k44oygc=.c8dcb7e7-8a7f-4c11-81fe-cd600b907b72@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <HiF5EwAj4DlTEOa85zqXgd2RbgbQjLNayJ6925N00ZU=.34ad1757-d497-4166-b9c7-745c8d82d228@github.com>
 <zRzo1bngRxh42bVMgTw_XPwiMuStUUGRxw19k44oygc=.c8dcb7e7-8a7f-4c11-81fe-cd600b907b72@github.com>
Message-ID: <b1flBZPs6DeW7CEg1ggPW93o2IJQkO0d9pRba3J1wE0=.0663df75-cba3-47bd-8b3b-44287f84706a@github.com>

On Mon, 8 Dec 2025 17:57:38 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Looks good to me.

Thanks for the review and the documentation Ioi (I've updated the CSR); once Mark approves my updates based on his change requests we should be good to go.

Note that serviceability retargeted to jdk27 (they discussed this with me), this works for me although I know there's a process if we do want to hit JDK26 (given that we missed the first gate), let me know if there's consensus for pushing into JDK26

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

PR Comment: https://git.openjdk.org/jdk/pull/28010#issuecomment-3628441123

From iklam at openjdk.org  Mon Dec  8 19:50:57 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 8 Dec 2025 19:50:57 GMT
Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache
 creation [v15]
In-Reply-To: <HiF5EwAj4DlTEOa85zqXgd2RbgbQjLNayJ6925N00ZU=.34ad1757-d497-4166-b9c7-745c8d82d228@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <HiF5EwAj4DlTEOa85zqXgd2RbgbQjLNayJ6925N00ZU=.34ad1757-d497-4166-b9c7-745c8d82d228@github.com>
Message-ID: <gUrT62X5ijdwfI_xFMDo8BwIOdLrjXxvFjwwiySZ8d4=.12beb30d-4922-4321-a49b-1abfb11f73fb@github.com>

On Wed, 3 Dec 2025 22:29:24 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
>> 
>> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
>> 
>> TRUE
>> FALSE
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporate feedback into documentation

I think it's OK to integrate into the mainline (for 27) once you get an approval from Mark.

For JDK 26, I think we can following this process:
- https://openjdk.org/jeps/3#Late-Enhancement-Request-Process

I'll try to update the JBS issue with a justification.

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

PR Comment: https://git.openjdk.org/jdk/pull/28010#issuecomment-3628741594

From mr at openjdk.org  Wed Dec 10 18:20:00 2025
From: mr at openjdk.org (Mark Reinhold)
Date: Wed, 10 Dec 2025 18:20:00 GMT
Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache
 creation [v15]
In-Reply-To: <HiF5EwAj4DlTEOa85zqXgd2RbgbQjLNayJ6925N00ZU=.34ad1757-d497-4166-b9c7-745c8d82d228@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <HiF5EwAj4DlTEOa85zqXgd2RbgbQjLNayJ6925N00ZU=.34ad1757-d497-4166-b9c7-745c8d82d228@github.com>
Message-ID: <0-DIQXf7yQXROjQZ82p1StLcHJiN4WwJU5A-uW1CVqw=.437dde89-0136-4afe-8641-8580abbf0697@github.com>

On Wed, 3 Dec 2025 22:29:24 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
>> 
>> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
>> 
>> TRUE
>> FALSE
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporate feedback into documentation

Marked as reviewed by mr (Lead).

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

PR Review: https://git.openjdk.org/jdk/pull/28010#pullrequestreview-3563912082

From duke at openjdk.org  Wed Dec 10 18:41:32 2025
From: duke at openjdk.org (duke)
Date: Wed, 10 Dec 2025 18:41:32 GMT
Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache
 creation [v15]
In-Reply-To: <HiF5EwAj4DlTEOa85zqXgd2RbgbQjLNayJ6925N00ZU=.34ad1757-d497-4166-b9c7-745c8d82d228@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <HiF5EwAj4DlTEOa85zqXgd2RbgbQjLNayJ6925N00ZU=.34ad1757-d497-4166-b9c7-745c8d82d228@github.com>
Message-ID: <abyii1o4tj07P6jyBf8GJK4rgSj0_1LAg8hr-tjM71M=.0baff849-cfac-4dd4-ab40-f85392471cf7@github.com>

On Wed, 3 Dec 2025 22:29:24 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
>> 
>> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
>> 
>> TRUE
>> FALSE
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporate feedback into documentation

@macarte 
Your change (at version 8b0e27f26b94eb3f9e0c18b542f54da85e784121) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/28010#issuecomment-3638450580

From macarte at openjdk.org  Wed Dec 10 18:52:05 2025
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 10 Dec 2025 18:52:05 GMT
Subject: jmx-dev Integrated: 8369736 - Add management interface for AOT
 cache creation
In-Reply-To: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
Message-ID: <0BIvIWfOQcKWZkhKpzxB6uJQC3caaKvqEeBzi7WU5b4=.b7c9874b-c5c8-4fec-ab7b-28df8457d88a@github.com>

On Tue, 28 Oct 2025 01:17:57 GMT, Mat Carter <macarte at openjdk.org> wrote:

> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
> 
> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
> 
> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
> 
> TRUE
> FALSE
> 
> Passes tier1 on linux (x64) and windows (x64)

This pull request has now been integrated.

Changeset: 413f852b
Author:    Mat Carter <macarte at openjdk.org>
Committer: Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/413f852bdb4767b2a1c29431144616668888138d
Stats:     335 lines in 10 files changed: 332 ins; 0 del; 3 mod

8369736: Add management interface for AOT cache creation

Reviewed-by: mr, iklam, kevinw

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

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

From iklam at openjdk.org  Wed Dec 10 19:18:07 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 10 Dec 2025 19:18:07 GMT
Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache
 creation [v15]
In-Reply-To: <HiF5EwAj4DlTEOa85zqXgd2RbgbQjLNayJ6925N00ZU=.34ad1757-d497-4166-b9c7-745c8d82d228@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <HiF5EwAj4DlTEOa85zqXgd2RbgbQjLNayJ6925N00ZU=.34ad1757-d497-4166-b9c7-745c8d82d228@github.com>
Message-ID: <IT6BSYlxvqy2lOZon0SewMkGwdEIlCwONU488cI5adU=.137c96b4-20f5-48f4-8793-22a932f61ed4@github.com>

On Wed, 3 Dec 2025 22:29:24 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
>> 
>> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
>> 
>> TRUE
>> FALSE
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporate feedback into documentation

FYI, I've added a request to include this in JDK 26.

- https://bugs.openjdk.org/browse/JDK-8369736?focusedId=14840372&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14840372

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

PR Comment: https://git.openjdk.org/jdk/pull/28010#issuecomment-3638593964

From dholmes at openjdk.org  Wed Dec 10 21:05:53 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 10 Dec 2025 21:05:53 GMT
Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache
 creation [v15]
In-Reply-To: <HiF5EwAj4DlTEOa85zqXgd2RbgbQjLNayJ6925N00ZU=.34ad1757-d497-4166-b9c7-745c8d82d228@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <HiF5EwAj4DlTEOa85zqXgd2RbgbQjLNayJ6925N00ZU=.34ad1757-d497-4166-b9c7-745c8d82d228@github.com>
Message-ID: <X13ctyRpg3UL3UD_kvGh7OtXqeX7M4rH75L12fhwmro=.925e29a0-a26b-446d-b010-9912ecd80943@github.com>

On Wed, 3 Dec 2025 22:29:24 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
>> 
>> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
>> 
>> TRUE
>> FALSE
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporate feedback into documentation

This change has broken the "since" checker test: tools/sincechecker/modules/jdk.management/JdkManagementCheckSince.java

src/jdk.management/jdk/management/HotSpotAOTCacheMXBean.java:44 class: jdk.management.HotSpotAOTCacheMXBean: `@since` version: 26; should be: 27
src/jdk.management/jdk/management/HotSpotAOTCacheMXBean.java:92 method: boolean jdk.management.HotSpotAOTCacheMXBean.endRecording(): `@since` version: 26; should be: 27
java.lang.Exception: The `@since` checker found 2 problems

Bug being filed

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

PR Comment: https://git.openjdk.org/jdk/pull/28010#issuecomment-3638949417

From kvn at openjdk.org  Wed Dec 10 21:30:09 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 10 Dec 2025 21:30:09 GMT
Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache
 creation [v15]
In-Reply-To: <HiF5EwAj4DlTEOa85zqXgd2RbgbQjLNayJ6925N00ZU=.34ad1757-d497-4166-b9c7-745c8d82d228@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <HiF5EwAj4DlTEOa85zqXgd2RbgbQjLNayJ6925N00ZU=.34ad1757-d497-4166-b9c7-745c8d82d228@github.com>
Message-ID: <LEJm3sKWe3Rkb-JadJ1BgoqpLZWiDc2psjfkHVNgdH0=.c2ca2cc8-fa90-4355-8f27-4b190812f596@github.com>

On Wed, 3 Dec 2025 22:29:24 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
>> 
>> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
>> 
>> TRUE
>> FALSE
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporate feedback into documentation

At least current code will be simple to backport to 26.

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

PR Comment: https://git.openjdk.org/jdk/pull/28010#issuecomment-3639029804

From iklam at openjdk.org  Thu Dec 11 05:09:57 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 11 Dec 2025 05:09:57 GMT
Subject: jmx-dev RFR: 8373464: Test JdkManagementCheckSince.java fails after
 JDK-8369736
Message-ID: <2QUaD1L1yTcQsGraXQfQmRh6goBaMg7AGmul1gTtHBw=.c25883a6-c1bb-489f-b43b-025cfa34ba42@github.com>

Please review this small fix and the plan of action for backporting JDK-8369736 to JDK 26.

(JDK-8369736 is under https://openjdk.org/jeps/3#Late-Enhancement-Request-Process)

**Background**

The "actually introduced version" for `HotSpotAOTCacheMXBean` is found using the `ct.sym` file (JdkManagementCheckSince.java  uses test/jdk/tools/sincechecker/SinceChecker.java, which doesn't read `ct.sym` directly, but uses `JavacTool` with `--release N`, which in turn loads `ct.sym`)


$ unzip -l ./images/jdk/lib/ct.sym | grep HotSpotAOTCacheMXBean.sig
      167 2025-12-11 03:16 R/jdk.management/jdk/management/HotSpotAOTCacheMXBean.sig


"R" is JDK 27 ("1" is JDK 1, "A" is JDK 10, "B" is JDK 11, etc ...)

In comparison, `VirtualThreadSchedulerMXBean` was first introduced in "O" = JDK 24, and its API has not changed since)


$ unzip -l ./images/jdk/lib/ct.sym | grep VirtualThreadSchedulerMXBean.sig
      313 2025-12-11 03:16 OPQR/jdk.management/jdk/management/VirtualThreadSchedulerMXBean.sig


Note that if an API has evolved over time, we may have several `.sig` files:


$ unzip -l ./images/jdk/lib/ct.sym | grep util/Vector.sig
     3058 2025-12-11 03:16 8/java.base/java/util/Vector.sig
     3182 2025-12-11 03:16 9A/java.base/java/util/Vector.sig
     3272 2025-12-11 03:16 BCDEFGHIJKLMNOPQR/java.base/java/util/Vector.sig


`ct.sym` is generated from files in [src/jdk.compiler/share/data/symbols](https://github.com/openjdk/jdk/tree/master/src/jdk.compiler/share/data/symbols)


$ cd src/jdk.compiler/share/data/symbols
$ grep VirtualThreadSchedulerMXBean *
jdk.management-O.sym.txt:class name jdk/management/VirtualThreadSchedulerMXBean


Because `HotSpotAOTCacheMXBean` is not listed in any of the `.sym.txt` files, it's added as version "R" in `ct.sym`


$ grep HotSpotAOTCacheMXBean * | wc
      0 0 0


**Proposed plan of action**

1. In the mainline, update HotSpotAOTCacheMXBean.java to use `@since 27` (this PR) to fix the current test failure in the mainline.

2. When backporting HotSpotAOTCacheMXBean.java to JDK 26 (with approval), it should have `@since 26`.

3. After JDK 26 is finalized, update the mainline:
    - Add HotSpotAOTCacheMXBean to `jdk.management-Q.sym.txt`
    - Update HotSpotAOTCacheMXBean.java to use `@since 26`.

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

Commit messages:
 - 8373464: Test JdkManagementCheckSince.java fails after JDK-8369736

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

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

From dholmes at openjdk.org  Thu Dec 11 06:04:22 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 11 Dec 2025 06:04:22 GMT
Subject: jmx-dev RFR: 8373464: Test JdkManagementCheckSince.java fails
 after JDK-8369736
In-Reply-To: <2QUaD1L1yTcQsGraXQfQmRh6goBaMg7AGmul1gTtHBw=.c25883a6-c1bb-489f-b43b-025cfa34ba42@github.com>
References: <2QUaD1L1yTcQsGraXQfQmRh6goBaMg7AGmul1gTtHBw=.c25883a6-c1bb-489f-b43b-025cfa34ba42@github.com>
Message-ID: <aDWl3g6qJJIyjlO6abNt9Pe8gnRN0huHSfbA5wGHEMg=.82b91cb4-c720-4edf-965f-6c7adc34b0ed@github.com>

On Thu, 11 Dec 2025 05:01:21 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Please review this small fix and the plan of action for backporting JDK-8369736 to JDK 26.
> 
> (JDK-8369736 is under https://openjdk.org/jeps/3#Late-Enhancement-Request-Process)
> 
> **Background**
> 
> The "actually introduced version" for `HotSpotAOTCacheMXBean` is found using the `ct.sym` file (JdkManagementCheckSince.java  uses test/jdk/tools/sincechecker/SinceChecker.java, which doesn't read `ct.sym` directly, but uses `JavacTool` with `--release N`, which in turn loads `ct.sym`)
> 
> 
> $ unzip -l ./images/jdk/lib/ct.sym | grep HotSpotAOTCacheMXBean.sig
>       167 2025-12-11 03:16 R/jdk.management/jdk/management/HotSpotAOTCacheMXBean.sig
> 
> 
> "R" is JDK 27 ("1" is JDK 1, "A" is JDK 10, "B" is JDK 11, etc ...)
> 
> In comparison, `VirtualThreadSchedulerMXBean` was first introduced in "O" = JDK 24, and its API has not changed since)
> 
> 
> $ unzip -l ./images/jdk/lib/ct.sym | grep VirtualThreadSchedulerMXBean.sig
>       313 2025-12-11 03:16 OPQR/jdk.management/jdk/management/VirtualThreadSchedulerMXBean.sig
> 
> 
> Note that if an API has evolved over time, we may have several `.sig` files:
> 
> 
> $ unzip -l ./images/jdk/lib/ct.sym | grep util/Vector.sig
>      3058 2025-12-11 03:16 8/java.base/java/util/Vector.sig
>      3182 2025-12-11 03:16 9A/java.base/java/util/Vector.sig
>      3272 2025-12-11 03:16 BCDEFGHIJKLMNOPQR/java.base/java/util/Vector.sig
> 
> 
> `ct.sym` is generated from files in [src/jdk.compiler/share/data/symbols](https://github.com/openjdk/jdk/tree/master/src/jdk.compiler/share/data/symbols)
> 
> 
> $ cd src/jdk.compiler/share/data/symbols
> $ grep VirtualThreadSchedulerMXBean *
> jdk.management-O.sym.txt:class name jdk/management/VirtualThreadSchedulerMXBean
> 
> 
> Because `HotSpotAOTCacheMXBean` is not listed in any of the `.sym.txt` files, it's added as version "R" in `ct.sym`
> 
> 
> $ grep HotSpotAOTCacheMXBean * | wc
>       0 0 0
> 
> 
> **Proposed plan of action**
> 
> 1. In the mainline, update HotSpotAOTCacheMXBean.java to use `@since 27` (this PR) to fix the current test failure in the mainline.
> 
> 2. When backporting HotSpotAOTCacheMXBean.java to JDK 26 (with approval), it should have `@since 26`.
> 
> 3. After JDK 26 is finalized, update the mainline:
>     - Add HotSpotAOTCacheMXBean to `jdk.management-Q.sym.txt`
>     - Update HotSpotAOTCacheMXBean.java to use `@since 26`.

Good and trivial. Thanks for fixing.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28760#pullrequestreview-3565842150

From shade at openjdk.org  Thu Dec 11 06:48:23 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 11 Dec 2025 06:48:23 GMT
Subject: jmx-dev RFR: 8373464: Test JdkManagementCheckSince.java fails
 after JDK-8369736
In-Reply-To: <2QUaD1L1yTcQsGraXQfQmRh6goBaMg7AGmul1gTtHBw=.c25883a6-c1bb-489f-b43b-025cfa34ba42@github.com>
References: <2QUaD1L1yTcQsGraXQfQmRh6goBaMg7AGmul1gTtHBw=.c25883a6-c1bb-489f-b43b-025cfa34ba42@github.com>
Message-ID: <PM464vgLgd5Y5w52D6Jns7D8v8ZDYlB2imgA--jZIAk=.533bece6-a20d-4fa6-a2fa-cf95be6b8932@github.com>

On Thu, 11 Dec 2025 05:01:21 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Please review this small fix and the plan of action for backporting JDK-8369736 to JDK 26.
> 
> (JDK-8369736 is under https://openjdk.org/jeps/3#Late-Enhancement-Request-Process)
> 
> **Background**
> 
> The "actually introduced version" for `HotSpotAOTCacheMXBean` is found using the `ct.sym` file (JdkManagementCheckSince.java  uses test/jdk/tools/sincechecker/SinceChecker.java, which doesn't read `ct.sym` directly, but uses `JavacTool` with `--release N`, which in turn loads `ct.sym`)
> 
> 
> $ unzip -l ./images/jdk/lib/ct.sym | grep HotSpotAOTCacheMXBean.sig
>       167 2025-12-11 03:16 R/jdk.management/jdk/management/HotSpotAOTCacheMXBean.sig
> 
> 
> "R" is JDK 27 ("1" is JDK 1, "A" is JDK 10, "B" is JDK 11, etc ...)
> 
> In comparison, `VirtualThreadSchedulerMXBean` was first introduced in "O" = JDK 24, and its API has not changed since)
> 
> 
> $ unzip -l ./images/jdk/lib/ct.sym | grep VirtualThreadSchedulerMXBean.sig
>       313 2025-12-11 03:16 OPQR/jdk.management/jdk/management/VirtualThreadSchedulerMXBean.sig
> 
> 
> Note that if an API has evolved over time, we may have several `.sig` files:
> 
> 
> $ unzip -l ./images/jdk/lib/ct.sym | grep util/Vector.sig
>      3058 2025-12-11 03:16 8/java.base/java/util/Vector.sig
>      3182 2025-12-11 03:16 9A/java.base/java/util/Vector.sig
>      3272 2025-12-11 03:16 BCDEFGHIJKLMNOPQR/java.base/java/util/Vector.sig
> 
> 
> `ct.sym` is generated from files in [src/jdk.compiler/share/data/symbols](https://github.com/openjdk/jdk/tree/master/src/jdk.compiler/share/data/symbols)
> 
> 
> $ cd src/jdk.compiler/share/data/symbols
> $ grep VirtualThreadSchedulerMXBean *
> jdk.management-O.sym.txt:class name jdk/management/VirtualThreadSchedulerMXBean
> 
> 
> Because `HotSpotAOTCacheMXBean` is not listed in any of the `.sym.txt` files, it's added as version "R" in `ct.sym`
> 
> 
> $ grep HotSpotAOTCacheMXBean * | wc
>       0 0 0
> 
> 
> **Proposed plan of action**
> 
> 1. In the mainline, update HotSpotAOTCacheMXBean.java to use `@since 27` (this PR) to fix the current test failure in the mainline.
> 
> 2. When backporting HotSpotAOTCacheMXBean.java to JDK 26 (with approval), it should have `@since 26`.
> 
> 3. After JDK 26 is finalized, update the mainline:
>     - Add HotSpotAOTCacheMXBean to `jdk.management-Q.sym.txt`
>     - Update HotSpotAOTCacheMXBean.java to use `@since 26`.

Looks good.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28760#pullrequestreview-3565967297

From kevinw at openjdk.org  Thu Dec 11 07:49:23 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 11 Dec 2025 07:49:23 GMT
Subject: jmx-dev RFR: 8373464: Test JdkManagementCheckSince.java fails
 after JDK-8369736
In-Reply-To: <2QUaD1L1yTcQsGraXQfQmRh6goBaMg7AGmul1gTtHBw=.c25883a6-c1bb-489f-b43b-025cfa34ba42@github.com>
References: <2QUaD1L1yTcQsGraXQfQmRh6goBaMg7AGmul1gTtHBw=.c25883a6-c1bb-489f-b43b-025cfa34ba42@github.com>
Message-ID: <7GQhrscxHF0C0xzLbt6r_x20JbKiKQ_0eesIiJ24Sok=.e855e891-c2d7-4c64-8bdf-7c5ea853e2d1@github.com>

On Thu, 11 Dec 2025 05:01:21 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Please review this small fix and the plan of action for backporting JDK-8369736 to JDK 26.
> 
> (JDK-8369736 is under https://openjdk.org/jeps/3#Late-Enhancement-Request-Process)
> 
> **Background**
> 
> The "actually introduced version" for `HotSpotAOTCacheMXBean` is found using the `ct.sym` file (JdkManagementCheckSince.java  uses test/jdk/tools/sincechecker/SinceChecker.java, which doesn't read `ct.sym` directly, but uses `JavacTool` with `--release N`, which in turn loads `ct.sym`)
> 
> 
> $ unzip -l ./images/jdk/lib/ct.sym | grep HotSpotAOTCacheMXBean.sig
>       167 2025-12-11 03:16 R/jdk.management/jdk/management/HotSpotAOTCacheMXBean.sig
> 
> 
> "R" is JDK 27 ("1" is JDK 1, "A" is JDK 10, "B" is JDK 11, etc ...)
> 
> In comparison, `VirtualThreadSchedulerMXBean` was first introduced in "O" = JDK 24, and its API has not changed since)
> 
> 
> $ unzip -l ./images/jdk/lib/ct.sym | grep VirtualThreadSchedulerMXBean.sig
>       313 2025-12-11 03:16 OPQR/jdk.management/jdk/management/VirtualThreadSchedulerMXBean.sig
> 
> 
> Note that if an API has evolved over time, we may have several `.sig` files:
> 
> 
> $ unzip -l ./images/jdk/lib/ct.sym | grep util/Vector.sig
>      3058 2025-12-11 03:16 8/java.base/java/util/Vector.sig
>      3182 2025-12-11 03:16 9A/java.base/java/util/Vector.sig
>      3272 2025-12-11 03:16 BCDEFGHIJKLMNOPQR/java.base/java/util/Vector.sig
> 
> 
> `ct.sym` is generated from files in [src/jdk.compiler/share/data/symbols](https://github.com/openjdk/jdk/tree/master/src/jdk.compiler/share/data/symbols)
> 
> 
> $ cd src/jdk.compiler/share/data/symbols
> $ grep VirtualThreadSchedulerMXBean *
> jdk.management-O.sym.txt:class name jdk/management/VirtualThreadSchedulerMXBean
> 
> 
> Because `HotSpotAOTCacheMXBean` is not listed in any of the `.sym.txt` files, it's added as version "R" in `ct.sym`
> 
> 
> $ grep HotSpotAOTCacheMXBean * | wc
>       0 0 0
> 
> 
> **Proposed plan of action**
> 
> 1. In the mainline, update HotSpotAOTCacheMXBean.java to use `@since 27` (this PR) to fix the current test failure in the mainline.
> 
> 2. When backporting HotSpotAOTCacheMXBean.java to JDK 26 (with approval), it should have `@since 26`.
> 
> 3. After JDK 26 is finalized, update the mainline:
>     - Add HotSpotAOTCacheMXBean to `jdk.management-Q.sym.txt`
>     - Update HotSpotAOTCacheMXBean.java to use `@since 26`.

Marked as reviewed by kevinw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28760#pullrequestreview-3566144079

From iklam at openjdk.org  Thu Dec 11 14:36:34 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 11 Dec 2025 14:36:34 GMT
Subject: jmx-dev RFR: 8373464: Test JdkManagementCheckSince.java fails
 after JDK-8369736
In-Reply-To: <aDWl3g6qJJIyjlO6abNt9Pe8gnRN0huHSfbA5wGHEMg=.82b91cb4-c720-4edf-965f-6c7adc34b0ed@github.com>
References: <2QUaD1L1yTcQsGraXQfQmRh6goBaMg7AGmul1gTtHBw=.c25883a6-c1bb-489f-b43b-025cfa34ba42@github.com>
 <aDWl3g6qJJIyjlO6abNt9Pe8gnRN0huHSfbA5wGHEMg=.82b91cb4-c720-4edf-965f-6c7adc34b0ed@github.com>
Message-ID: <u6BnHqNWnu0RXEHAtFITGFgFW7AmgdouL4wmHIvRUwA=.b8d1a2e5-7bbc-4bf7-a8d3-a3fcd2e70300@github.com>

On Thu, 11 Dec 2025 06:01:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review this small fix and the plan of action for backporting JDK-8369736 to JDK 26.
>> 
>> (JDK-8369736 is under https://openjdk.org/jeps/3#Late-Enhancement-Request-Process)
>> 
>> **Background**
>> 
>> The "actually introduced version" for `HotSpotAOTCacheMXBean` is found using the `ct.sym` file (JdkManagementCheckSince.java  uses test/jdk/tools/sincechecker/SinceChecker.java, which doesn't read `ct.sym` directly, but uses `JavacTool` with `--release N`, which in turn loads `ct.sym`)
>> 
>> 
>> $ unzip -l ./images/jdk/lib/ct.sym | grep HotSpotAOTCacheMXBean.sig
>>       167 2025-12-11 03:16 R/jdk.management/jdk/management/HotSpotAOTCacheMXBean.sig
>> 
>> 
>> "R" is JDK 27 ("1" is JDK 1, "A" is JDK 10, "B" is JDK 11, etc ...)
>> 
>> In comparison, `VirtualThreadSchedulerMXBean` was first introduced in "O" = JDK 24, and its API has not changed since)
>> 
>> 
>> $ unzip -l ./images/jdk/lib/ct.sym | grep VirtualThreadSchedulerMXBean.sig
>>       313 2025-12-11 03:16 OPQR/jdk.management/jdk/management/VirtualThreadSchedulerMXBean.sig
>> 
>> 
>> Note that if an API has evolved over time, we may have several `.sig` files:
>> 
>> 
>> $ unzip -l ./images/jdk/lib/ct.sym | grep util/Vector.sig
>>      3058 2025-12-11 03:16 8/java.base/java/util/Vector.sig
>>      3182 2025-12-11 03:16 9A/java.base/java/util/Vector.sig
>>      3272 2025-12-11 03:16 BCDEFGHIJKLMNOPQR/java.base/java/util/Vector.sig
>> 
>> 
>> `ct.sym` is generated from files in [src/jdk.compiler/share/data/symbols](https://github.com/openjdk/jdk/tree/master/src/jdk.compiler/share/data/symbols)
>> 
>> 
>> $ cd src/jdk.compiler/share/data/symbols
>> $ grep VirtualThreadSchedulerMXBean *
>> jdk.management-O.sym.txt:class name jdk/management/VirtualThreadSchedulerMXBean
>> 
>> 
>> Because `HotSpotAOTCacheMXBean` is not listed in any of the `.sym.txt` files, it's added as version "R" in `ct.sym`
>> 
>> 
>> $ grep HotSpotAOTCacheMXBean * | wc
>>       0 0 0
>> 
>> 
>> **Proposed plan of action**
>> 
>> 1. In the mainline, update HotSpotAOTCacheMXBean.java to use `@since 27` (this PR) to fix the current test failure in the mainline.
>> 
>> 2. When backporting HotSpotAOTCacheMXBean.java to JDK 26 (with approval), it should have `@since 26`.
>> 
>> 3. After JDK 26 is finalized, update the mainline:
>>     - Add HotSpotAOTCacheMXBean to `jdk.management-Q.sym.txt`
>>     - Update HotSpotAOTCacheMXBean.java to use `@since 26`.
>
> Good and trivial. Thanks for fixing.

Thanks @dholmes-ora @shipilev @kevinjwalls for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/28760#issuecomment-3642210642

From iklam at openjdk.org  Thu Dec 11 14:36:36 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 11 Dec 2025 14:36:36 GMT
Subject: jmx-dev Integrated: 8373464: Test JdkManagementCheckSince.java
 fails after JDK-8369736
In-Reply-To: <2QUaD1L1yTcQsGraXQfQmRh6goBaMg7AGmul1gTtHBw=.c25883a6-c1bb-489f-b43b-025cfa34ba42@github.com>
References: <2QUaD1L1yTcQsGraXQfQmRh6goBaMg7AGmul1gTtHBw=.c25883a6-c1bb-489f-b43b-025cfa34ba42@github.com>
Message-ID: <gdiiJ2nIFvD6P1ZVToMWLV9zUMLu4oYu4nwBtdBlA1c=.da64255e-e006-4000-b024-81b8c4ca60b8@github.com>

On Thu, 11 Dec 2025 05:01:21 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Please review this small fix and the plan of action for backporting JDK-8369736 to JDK 26.
> 
> (JDK-8369736 is under https://openjdk.org/jeps/3#Late-Enhancement-Request-Process)
> 
> **Background**
> 
> The "actually introduced version" for `HotSpotAOTCacheMXBean` is found using the `ct.sym` file (JdkManagementCheckSince.java  uses test/jdk/tools/sincechecker/SinceChecker.java, which doesn't read `ct.sym` directly, but uses `JavacTool` with `--release N`, which in turn loads `ct.sym`)
> 
> 
> $ unzip -l ./images/jdk/lib/ct.sym | grep HotSpotAOTCacheMXBean.sig
>       167 2025-12-11 03:16 R/jdk.management/jdk/management/HotSpotAOTCacheMXBean.sig
> 
> 
> "R" is JDK 27 ("1" is JDK 1, "A" is JDK 10, "B" is JDK 11, etc ...)
> 
> In comparison, `VirtualThreadSchedulerMXBean` was first introduced in "O" = JDK 24, and its API has not changed since)
> 
> 
> $ unzip -l ./images/jdk/lib/ct.sym | grep VirtualThreadSchedulerMXBean.sig
>       313 2025-12-11 03:16 OPQR/jdk.management/jdk/management/VirtualThreadSchedulerMXBean.sig
> 
> 
> Note that if an API has evolved over time, we may have several `.sig` files:
> 
> 
> $ unzip -l ./images/jdk/lib/ct.sym | grep util/Vector.sig
>      3058 2025-12-11 03:16 8/java.base/java/util/Vector.sig
>      3182 2025-12-11 03:16 9A/java.base/java/util/Vector.sig
>      3272 2025-12-11 03:16 BCDEFGHIJKLMNOPQR/java.base/java/util/Vector.sig
> 
> 
> `ct.sym` is generated from files in [src/jdk.compiler/share/data/symbols](https://github.com/openjdk/jdk/tree/master/src/jdk.compiler/share/data/symbols)
> 
> 
> $ cd src/jdk.compiler/share/data/symbols
> $ grep VirtualThreadSchedulerMXBean *
> jdk.management-O.sym.txt:class name jdk/management/VirtualThreadSchedulerMXBean
> 
> 
> Because `HotSpotAOTCacheMXBean` is not listed in any of the `.sym.txt` files, it's added as version "R" in `ct.sym`
> 
> 
> $ grep HotSpotAOTCacheMXBean * | wc
>       0 0 0
> 
> 
> **Proposed plan of action**
> 
> 1. In the mainline, update HotSpotAOTCacheMXBean.java to use `@since 27` (this PR) to fix the current test failure in the mainline.
> 
> 2. When backporting HotSpotAOTCacheMXBean.java to JDK 26 (with approval), it should have `@since 26`.
> 
> 3. After JDK 26 is finalized, update the mainline:
>     - Add HotSpotAOTCacheMXBean to `jdk.management-Q.sym.txt`
>     - Update HotSpotAOTCacheMXBean.java to use `@since 26`.

This pull request has now been integrated.

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

8373464: Test JdkManagementCheckSince.java fails after JDK-8369736

Reviewed-by: dholmes, shade, kevinw

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

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

From iklam at openjdk.org  Thu Dec 11 19:13:27 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 11 Dec 2025 19:13:27 GMT
Subject: jmx-dev [jdk26] RFR: 8369736: Add management interface for AOT
 cache creation
Message-ID: <7ZxAR7KNBo848aKmFEchA-IWSCSPyWIqxaGmjwNa-hs=.03784452-ec97-4109-a6a9-660762c682c4@github.com>

Hi all,

This pull request contains a backport of commit [413f852b](https://github.com/openjdk/jdk/commit/413f852bdb4767b2a1c29431144616668888138d) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Mat Carter on 10 Dec 2025 and was reviewed by Mark Reinhold, Ioi Lam and Kevin Walls.

Thanks!

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

Commit messages:
 - Backport 413f852bdb4767b2a1c29431144616668888138d

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

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

From kvn at openjdk.org  Thu Dec 11 20:45:49 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 11 Dec 2025 20:45:49 GMT
Subject: jmx-dev [jdk26] RFR: 8369736: Add management interface for AOT
 cache creation
In-Reply-To: <7ZxAR7KNBo848aKmFEchA-IWSCSPyWIqxaGmjwNa-hs=.03784452-ec97-4109-a6a9-660762c682c4@github.com>
References: <7ZxAR7KNBo848aKmFEchA-IWSCSPyWIqxaGmjwNa-hs=.03784452-ec97-4109-a6a9-660762c682c4@github.com>
Message-ID: <sNLYYomBlkex9IsLGTFYdarT-EKDghteHWm1uiu6rcs=.b830c2e2-0f23-46bf-bc3d-16aa108f08d1@github.com>

On Thu, 11 Dec 2025 19:05:17 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [413f852b](https://github.com/openjdk/jdk/commit/413f852bdb4767b2a1c29431144616668888138d) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Mat Carter on 10 Dec 2025 and was reviewed by Mark Reinhold, Ioi Lam and Kevin Walls.
> 
> Thanks!

Good

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28772#pullrequestreview-3569226381

From iklam at openjdk.org  Fri Dec 12 14:33:14 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 12 Dec 2025 14:33:14 GMT
Subject: jmx-dev [jdk26] RFR: 8369736: Add management interface for AOT
 cache creation
In-Reply-To: <sNLYYomBlkex9IsLGTFYdarT-EKDghteHWm1uiu6rcs=.b830c2e2-0f23-46bf-bc3d-16aa108f08d1@github.com>
References: <7ZxAR7KNBo848aKmFEchA-IWSCSPyWIqxaGmjwNa-hs=.03784452-ec97-4109-a6a9-660762c682c4@github.com>
 <sNLYYomBlkex9IsLGTFYdarT-EKDghteHWm1uiu6rcs=.b830c2e2-0f23-46bf-bc3d-16aa108f08d1@github.com>
Message-ID: <_kA4bTDICP0GPkKHWYobWxOKJ4XXQDkOonFi7Zr_GlY=.742b2034-8086-48d0-803b-874428cd8214@github.com>

On Thu, 11 Dec 2025 20:43:11 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Hi all,
>> 
>> This pull request contains a backport of commit [413f852b](https://github.com/openjdk/jdk/commit/413f852bdb4767b2a1c29431144616668888138d) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>> 
>> The commit being backported was authored by Mat Carter on 10 Dec 2025 and was reviewed by Mark Reinhold, Ioi Lam and Kevin Walls.
>> 
>> Thanks!
>
> Good

Thanks @vnkozlov for the review
Passed tiers 1 - 4 and builds-tier-5

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

PR Comment: https://git.openjdk.org/jdk/pull/28772#issuecomment-3646707792

From iklam at openjdk.org  Fri Dec 12 14:36:42 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 12 Dec 2025 14:36:42 GMT
Subject: jmx-dev [jdk26] Integrated: 8369736: Add management interface for
 AOT cache creation
In-Reply-To: <7ZxAR7KNBo848aKmFEchA-IWSCSPyWIqxaGmjwNa-hs=.03784452-ec97-4109-a6a9-660762c682c4@github.com>
References: <7ZxAR7KNBo848aKmFEchA-IWSCSPyWIqxaGmjwNa-hs=.03784452-ec97-4109-a6a9-660762c682c4@github.com>
Message-ID: <qFwM_ybl67eTZMO_XCyFNisH7fP40fWYjNg3IABJVF8=.93f68a4b-45cb-403a-9184-be8c50c36efb@github.com>

On Thu, 11 Dec 2025 19:05:17 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [413f852b](https://github.com/openjdk/jdk/commit/413f852bdb4767b2a1c29431144616668888138d) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Mat Carter on 10 Dec 2025 and was reviewed by Mark Reinhold, Ioi Lam and Kevin Walls.
> 
> Thanks!

This pull request has now been integrated.

Changeset: d9bc8221
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d9bc82216842bf521ccb7c451b4b411adb0cf3cc
Stats:     335 lines in 10 files changed: 332 ins; 0 del; 3 mod

8369736: Add management interface for AOT cache creation

Reviewed-by: kvn
Backport-of: 413f852bdb4767b2a1c29431144616668888138d

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

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

From iklam at openjdk.org  Fri Dec 12 23:37:20 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 12 Dec 2025 23:37:20 GMT
Subject: jmx-dev RFR: 8373441: Remove DCmdFactory::_enabled [v2]
In-Reply-To: <XE188S-C6EdTA2PRsdsQTi4Z550PW6DNpL3awvANazU=.1b0cd4d1-56cd-491a-b80c-8e2bafcc78ca@github.com>
References: <XE188S-C6EdTA2PRsdsQTi4Z550PW6DNpL3awvANazU=.1b0cd4d1-56cd-491a-b80c-8e2bafcc78ca@github.com>
Message-ID: <AjjRyNcaMQOA-qcgilZVf5STbEMEmWAoBy3_BidW48k=.15d682e2-f8b6-4e4d-8fc2-f482e117b6b2@github.com>

> The `DCmdFactory::_enabled` is always set to `true` and there doesn't seem to be a reason to set it to `false`.
> 
> This PR removes this field and simplified the creation of `DCmdFactory` objects.
> 
> The related `_hidden` field is also currently not used, but may be used in the future when deprecating DCmds, so we leave it unchanged.
> 
> Note that now `jmm_GetDiagnosticCommandInfo()` always set `dcmdInfo::enabled` to `true` to be compatible with Java code.

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

  @kevinjwalls comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28794/files
  - new: https://git.openjdk.org/jdk/pull/28794/files/8a047713..98176aa7

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

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

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

From iklam at openjdk.org  Fri Dec 12 23:37:22 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 12 Dec 2025 23:37:22 GMT
Subject: jmx-dev RFR: 8373441: Remove DCmdFactory::_enabled [v2]
In-Reply-To: <OWIvuqKJUCvJjq598wQrZ8oqDMV7m-EQMEi1Yyh7t6A=.6dcc1d69-f3e7-4a77-9cd9-cc7b9882502e@github.com>
References: <XE188S-C6EdTA2PRsdsQTi4Z550PW6DNpL3awvANazU=.1b0cd4d1-56cd-491a-b80c-8e2bafcc78ca@github.com>
 <OWIvuqKJUCvJjq598wQrZ8oqDMV7m-EQMEi1Yyh7t6A=.6dcc1d69-f3e7-4a77-9cd9-cc7b9882502e@github.com>
Message-ID: <5L7tLI0Xi70wDBou7BLE4TNtcUQRdlKRPUEjsM_77mE=.823865fb-28f1-4879-8e05-a811b24cf590@github.com>

On Fri, 12 Dec 2025 16:53:33 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> The Java API has "enabled" handled in src/jdk.management/share/classes/com/sun/management/internal/DiagnosticCommandInfo.java (and read in src/jdk.management/share/classes/com/sun/management/internal/DiagnosticCommandImpl.java)
> 
> In the public API docs we do specify a Descriptor for diagnostic commands:
> 
> https://docs.oracle.com/en/java/javase/25/docs/api/jdk.management/com/sun/management/DiagnosticCommandMBean.html dcmd.enabled boolean True if the diagnostic command is enabled, false otherwise
> 
> dcmd.enabled is already not very meaningful as it's always true, but if it becomes truly meaningless, it needs thought on whether it stays, maybe with a comment that it is always true, or can be removed.
> 
> The Java api deals with remote connections, so interactions between JDK versions need considering. If dcmd.enabled is not found, if a client app ever checks this Descriptor, does the app think it's not enabled?
> 
> Maybe it stays in the Descriptor for compatibility reasons, but can be removed from DiagnosticCommandInfo.
> 
> This could be a follow up issue if we aren't doing it now.

For compatibility reasons, I don't want to touch the Java APIs in this PR. I updated the comments in DiagnosticCommandMBean.java to say


 *     <th scope="row">dcmd.enabled</th><td>boolean</td>
 *     <td>This field is always true -- diagnostic commands cannot be disabled.</td>

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

PR Comment: https://git.openjdk.org/jdk/pull/28794#issuecomment-3648510642

From dholmes at openjdk.org  Mon Dec 15 06:13:55 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 15 Dec 2025 06:13:55 GMT
Subject: jmx-dev RFR: 8373441: Remove DCmdFactory::_enabled [v2]
In-Reply-To: <AjjRyNcaMQOA-qcgilZVf5STbEMEmWAoBy3_BidW48k=.15d682e2-f8b6-4e4d-8fc2-f482e117b6b2@github.com>
References: <XE188S-C6EdTA2PRsdsQTi4Z550PW6DNpL3awvANazU=.1b0cd4d1-56cd-491a-b80c-8e2bafcc78ca@github.com>
 <AjjRyNcaMQOA-qcgilZVf5STbEMEmWAoBy3_BidW48k=.15d682e2-f8b6-4e4d-8fc2-f482e117b6b2@github.com>
Message-ID: <ppwkDYos68jcWO3LlFPFjyVqNdjvA56mPWgSG6Zkf5Q=.07a2fd74-2c98-426e-ae8a-92db8e7031b1@github.com>

On Fri, 12 Dec 2025 23:37:20 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The `DCmdFactory::_enabled` is always set to `true` and there doesn't seem to be a reason to set it to `false`.
>> 
>> This PR removes this field and simplified the creation of `DCmdFactory` objects.
>> 
>> The related `_hidden` field is also currently not used, but may be used in the future when deprecating DCmds, so we leave it unchanged.
>> 
>> Note that now `jmm_GetDiagnosticCommandInfo()` always set `dcmdInfo::enabled` to `true` to be compatible with Java code.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @kevinjwalls comments

If we are just changing the implementation then I guess this would be okay. But it seems the API for this allows for specific DCmds to be disabled (how?) - or at least intended for it to be possible. As per the doc:
> When the set of diagnostic commands currently supported by the Java Virtual Machine is modified, the DiagnosticCommandMBean emits a [Notification](https://docs.oracle.com/javase/8/docs/api/javax/management/Notification.html?is-external=true) with a [type](https://docs.oracle.com/javase/8/docs/api/javax/management/Notification.html?is-external=true#getType--) of[ "jmx.mbean.info.changed"](https://docs.oracle.com/javase/8/docs/api/javax/management/MBeanInfo.html#info-changed) and a [userData](https://docs.oracle.com/javase/8/docs/api/javax/management/Notification.html?is-external=true#getUserData--) that is the new MBeanInfo.

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

PR Comment: https://git.openjdk.org/jdk/pull/28794#issuecomment-3653521831

From iklam at openjdk.org  Mon Dec 15 20:28:17 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 15 Dec 2025 20:28:17 GMT
Subject: jmx-dev RFR: 8373441: Remove DCmdFactory::_enabled [v2]
In-Reply-To: <ppwkDYos68jcWO3LlFPFjyVqNdjvA56mPWgSG6Zkf5Q=.07a2fd74-2c98-426e-ae8a-92db8e7031b1@github.com>
References: <XE188S-C6EdTA2PRsdsQTi4Z550PW6DNpL3awvANazU=.1b0cd4d1-56cd-491a-b80c-8e2bafcc78ca@github.com>
 <AjjRyNcaMQOA-qcgilZVf5STbEMEmWAoBy3_BidW48k=.15d682e2-f8b6-4e4d-8fc2-f482e117b6b2@github.com>
 <ppwkDYos68jcWO3LlFPFjyVqNdjvA56mPWgSG6Zkf5Q=.07a2fd74-2c98-426e-ae8a-92db8e7031b1@github.com>
Message-ID: <q4BmjvrFm3_ALV5EhJ_J59ZEiE_JnntbioCSk4zdArI=.a79e7fb2-40aa-4710-b3e5-dd43fbfd1238@github.com>

On Mon, 15 Dec 2025 06:11:22 GMT, David Holmes <dholmes at openjdk.org> wrote:

> If we are just changing the implementation then I guess this would be okay. But it seems the API for this allows for specific DCmds to be disabled (how?) - or at least intended for it to be possible. As per the doc:
> 
> > When the set of diagnostic commands currently supported by the Java Virtual Machine is modified, the DiagnosticCommandMBean emits a [Notification](https://docs.oracle.com/javase/8/docs/api/javax/management/Notification.html?is-external=true) with a [type](https://docs.oracle.com/javase/8/docs/api/javax/management/Notification.html?is-external=true#getType--) of[ "jmx.mbean.info.changed"](https://docs.oracle.com/javase/8/docs/api/javax/management/MBeanInfo.html#info-changed) and a [userData](https://docs.oracle.com/javase/8/docs/api/javax/management/Notification.html?is-external=true#getUserData--) that is the new MBeanInfo.

The above paragraph is about new commands being added:


int DCmdFactory::register_DCmdFactory(DCmdFactory* factory) {
  MutexLocker ml(DCmdFactory_lock, Mutex::_no_safepoint_check_flag);
  factory->_next = _DCmdFactoryList;
  _DCmdFactoryList = factory;
  if (_send_jmx_notification && !factory->_hidden
      && (factory->_export_flags & DCmd_Source_MBean)) {
    DCmdFactory::push_jmx_notification_request();
  }
  return 0; // Actually, there's no checks for duplicates
}


Which will eventually cause `DiagnosticCommandImpl::createDiagnosticFrameworkNotification()` to be called by HotSpot to dispatch the `Notification`.

I checked older source code like JDK 8, which has a `DCmdFactory::set_enabled()` method but there are no callers. If there had been a way to disable commands dynamically, that has been lost for a very long time.

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

PR Comment: https://git.openjdk.org/jdk/pull/28794#issuecomment-3657448785

From dholmes at openjdk.org  Tue Dec 16 05:45:53 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 16 Dec 2025 05:45:53 GMT
Subject: jmx-dev RFR: 8373441: Remove DCmdFactory::_enabled [v2]
In-Reply-To: <AjjRyNcaMQOA-qcgilZVf5STbEMEmWAoBy3_BidW48k=.15d682e2-f8b6-4e4d-8fc2-f482e117b6b2@github.com>
References: <XE188S-C6EdTA2PRsdsQTi4Z550PW6DNpL3awvANazU=.1b0cd4d1-56cd-491a-b80c-8e2bafcc78ca@github.com>
 <AjjRyNcaMQOA-qcgilZVf5STbEMEmWAoBy3_BidW48k=.15d682e2-f8b6-4e4d-8fc2-f482e117b6b2@github.com>
Message-ID: <e9HrWI-CsO0LmVSwLPp43Gpn0dexy5aMDXT7ChJwpy0=.5106b6d0-9e20-4239-92c9-8522ec01974c@github.com>

On Fri, 12 Dec 2025 23:37:20 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The `DCmdFactory::_enabled` is always set to `true` and there doesn't seem to be a reason to set it to `false`.
>> 
>> This PR removes this field and simplified the creation of `DCmdFactory` objects.
>> 
>> The related `_hidden` field is also currently not used, but may be used in the future when deprecating DCmds, so we leave it unchanged.
>> 
>> Note that now `jmm_GetDiagnosticCommandInfo()` always set `dcmdInfo::enabled` to `true` to be compatible with Java code.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @kevinjwalls comments

For the history see 

https://bugs.openjdk.org/browse/JDK-7104647?focusedId=12336354&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12336354

The "enabled" capability came from the JRockit jrcmd tool:

https://docs.oracle.com/cd/E13150_01/jrockit_jvm/jrockit/geninfo/diagnos/ctrlbreakhndlr.html

> "You can enable or disable any diagnostic command using the system property -Djrockit.ctrlbreak.enable<name>=<true|false>, where name is the name of the diagnostic command."

But as far as I can see the DCmd framework never specified a mechanism for disabling a DCmd. @fparain may recall more details.

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

PR Comment: https://git.openjdk.org/jdk/pull/28794#issuecomment-3658938216

From fparain at openjdk.org  Tue Dec 16 15:28:21 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 16 Dec 2025 15:28:21 GMT
Subject: jmx-dev RFR: 8373441: Remove DCmdFactory::_enabled [v2]
In-Reply-To: <AjjRyNcaMQOA-qcgilZVf5STbEMEmWAoBy3_BidW48k=.15d682e2-f8b6-4e4d-8fc2-f482e117b6b2@github.com>
References: <XE188S-C6EdTA2PRsdsQTi4Z550PW6DNpL3awvANazU=.1b0cd4d1-56cd-491a-b80c-8e2bafcc78ca@github.com>
 <AjjRyNcaMQOA-qcgilZVf5STbEMEmWAoBy3_BidW48k=.15d682e2-f8b6-4e4d-8fc2-f482e117b6b2@github.com>
Message-ID: <_vX0iZx2pk5puYThVOlJ3CL8Cv2fketux6_yupud8sc=.be19dfc6-f9ac-40fc-9b8e-5477ec093a5b@github.com>

On Fri, 12 Dec 2025 23:37:20 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The `DCmdFactory::_enabled` is always set to `true` and there doesn't seem to be a reason to set it to `false`.
>> 
>> This PR removes this field and simplified the creation of `DCmdFactory` objects.
>> 
>> The related `_hidden` field is also currently not used, but may be used in the future when deprecating DCmds, so we leave it unchanged.
>> 
>> Note that now `jmm_GetDiagnosticCommandInfo()` always set `dcmdInfo::enabled` to `true` to be compatible with Java code.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @kevinjwalls comments

The "enabled" capability probably fall in the category of features that were initially implemented to emulate JRockit jrcmd  tool but were finally not integrated in HotSpot (I remember another feature like that, to execute an user shell script when some events were triggered).
I don't remember having used or debugged this enable/disable feature. It looks that dead code that have been here for too long. Thank you for having found it and cleaned it up.

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

PR Comment: https://git.openjdk.org/jdk/pull/28794#issuecomment-3661116214

From fparain at openjdk.org  Tue Dec 16 15:40:25 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 16 Dec 2025 15:40:25 GMT
Subject: jmx-dev RFR: 8373441: Remove DCmdFactory::_enabled [v2]
In-Reply-To: <AjjRyNcaMQOA-qcgilZVf5STbEMEmWAoBy3_BidW48k=.15d682e2-f8b6-4e4d-8fc2-f482e117b6b2@github.com>
References: <XE188S-C6EdTA2PRsdsQTi4Z550PW6DNpL3awvANazU=.1b0cd4d1-56cd-491a-b80c-8e2bafcc78ca@github.com>
 <AjjRyNcaMQOA-qcgilZVf5STbEMEmWAoBy3_BidW48k=.15d682e2-f8b6-4e4d-8fc2-f482e117b6b2@github.com>
Message-ID: <PSey24d8vzoiGbajbdvA6NJC3rogA2JSJ094bFILFBU=.ae2b5f7b-ebbc-40b5-bf97-17719df9c40e@github.com>

On Fri, 12 Dec 2025 23:37:20 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The `DCmdFactory::_enabled` is always set to `true` and there doesn't seem to be a reason to set it to `false`.
>> 
>> This PR removes this field and simplified the creation of `DCmdFactory` objects.
>> 
>> The related `_hidden` field is also currently not used, but may be used in the future when deprecating DCmds, so we leave it unchanged.
>> 
>> Note that now `jmm_GetDiagnosticCommandInfo()` always set `dcmdInfo::enabled` to `true` to be compatible with Java code.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @kevinjwalls comments

LGTM

More context: https://openjdk.org/jeps/137

> 1-1 Overview
> 
> The diagnostic command framework is fully implemented in native code and relies on HotSpot's internal exception mechanism. The rationale for a pure native implementation is to be able to execute diagnostic commands even in critical situations like an out-of-memory condition. All diagnostic commands are registered in a single list, and two flags control the way a user can interact with them. The hidden flag prevents a diagnostic command from appearing in the list of available commands returned by the help command. However, it's still possible to get the detailed help message for a hidden command with the help <command name> syntax, but it requires knowing the name of the hidden command. The second flag is enabled and it controls whether a command can be invoked or not. When listed with the help commands, disabled commands appear with a [disabled] label in their descriptions. If the user tries to invoke a disabled command, an error message is returned and the command is not run. This
  error message can be customized on a per-command basis. The framework just provides these two flags with their semantics; it doesn't provide any policy or mechanism to set or modify these flags. These actions will be delegated to the JVM or specific diagnostic commands.

The diagnostic command framework was developed at the same time we had requests to implement "Commercial features", the "enabled" flag might also have been intended to guard those commercial features (gone now).

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

Marked as reviewed by fparain (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28794#pullrequestreview-3583740017
PR Comment: https://git.openjdk.org/jdk/pull/28794#issuecomment-3661165228

From kevinw at openjdk.org  Tue Dec 16 20:46:46 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 16 Dec 2025 20:46:46 GMT
Subject: jmx-dev RFR: 8373441: Remove DCmdFactory::_enabled [v2]
In-Reply-To: <AjjRyNcaMQOA-qcgilZVf5STbEMEmWAoBy3_BidW48k=.15d682e2-f8b6-4e4d-8fc2-f482e117b6b2@github.com>
References: <XE188S-C6EdTA2PRsdsQTi4Z550PW6DNpL3awvANazU=.1b0cd4d1-56cd-491a-b80c-8e2bafcc78ca@github.com>
 <AjjRyNcaMQOA-qcgilZVf5STbEMEmWAoBy3_BidW48k=.15d682e2-f8b6-4e4d-8fc2-f482e117b6b2@github.com>
Message-ID: <adui1hf3MwZvlgT-cy3RamKYJeVPbtt-yoAXSL6jMLU=.0694d9b5-7d9f-44e4-9f9a-a9315be4d121@github.com>

On Fri, 12 Dec 2025 23:37:20 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The `DCmdFactory::_enabled` is always set to `true` and there doesn't seem to be a reason to set it to `false`.
>> 
>> This PR removes this field and simplified the creation of `DCmdFactory` objects.
>> 
>> The related `_hidden` field is also currently not used, but may be used in the future when deprecating DCmds, so we leave it unchanged.
>> 
>> Note that now `jmm_GetDiagnosticCommandInfo()` always set `dcmdInfo::enabled` to `true` to be compatible with Java code.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @kevinjwalls comments

Marked as reviewed by kevinw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28794#pullrequestreview-3584868873

From kevinw at openjdk.org  Tue Dec 16 20:46:47 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 16 Dec 2025 20:46:47 GMT
Subject: jmx-dev RFR: 8373441: Remove DCmdFactory::_enabled [v2]
In-Reply-To: <PSey24d8vzoiGbajbdvA6NJC3rogA2JSJ094bFILFBU=.ae2b5f7b-ebbc-40b5-bf97-17719df9c40e@github.com>
References: <XE188S-C6EdTA2PRsdsQTi4Z550PW6DNpL3awvANazU=.1b0cd4d1-56cd-491a-b80c-8e2bafcc78ca@github.com>
 <AjjRyNcaMQOA-qcgilZVf5STbEMEmWAoBy3_BidW48k=.15d682e2-f8b6-4e4d-8fc2-f482e117b6b2@github.com>
 <PSey24d8vzoiGbajbdvA6NJC3rogA2JSJ094bFILFBU=.ae2b5f7b-ebbc-40b5-bf97-17719df9c40e@github.com>
Message-ID: <H8hznVoJQw6E6O09lymKyUYKc5PJSIf9vxV-C2419xg=.6275c817-e470-40ac-8b5c-803fb14950dc@github.com>

On Tue, 16 Dec 2025 15:36:31 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @kevinjwalls comments
>
> More context: https://openjdk.org/jeps/137
> 
>> 1-1 Overview
>> 
>> The diagnostic command framework is fully implemented in native code and relies on HotSpot's internal exception mechanism. The rationale for a pure native implementation is to be able to execute diagnostic commands even in critical situations like an out-of-memory condition. All diagnostic commands are registered in a single list, and two flags control the way a user can interact with them. The hidden flag prevents a diagnostic command from appearing in the list of available commands returned by the help command. However, it's still possible to get the detailed help message for a hidden command with the help <command name> syntax, but it requires knowing the name of the hidden command. The second flag is enabled and it controls whether a command can be invoked or not. When listed with the help commands, disabled commands appear with a [disabled] label in their descriptions. If the user tries to invoke a disabled command, an error message is returned and the command is not run. Thi
 s error message can be customized on a per-command basis. The framework just provides these two flags with their semantics; it doesn't provide any policy or mechanism to set or modify these flags. These actions will be delegated to the JVM or specific diagnostic commands.
> 
> The diagnostic command framework was developed at the same time we had requests to implement "Commercial features", the "enabled" flag might also have been intended to guard those commercial features (gone now).

Thanks @fparain Frederic for the extra context.  Had wondered if this feature had ever been used, particularly all the mechanism around the possible JMX Notification.  After this change, we may look at whether it should be removed also.

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

PR Comment: https://git.openjdk.org/jdk/pull/28794#issuecomment-3662306936

From iklam at openjdk.org  Tue Dec 16 23:20:26 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 16 Dec 2025 23:20:26 GMT
Subject: jmx-dev RFR: 8373441: Remove DCmdFactory::_enabled [v2]
In-Reply-To: <H8hznVoJQw6E6O09lymKyUYKc5PJSIf9vxV-C2419xg=.6275c817-e470-40ac-8b5c-803fb14950dc@github.com>
References: <XE188S-C6EdTA2PRsdsQTi4Z550PW6DNpL3awvANazU=.1b0cd4d1-56cd-491a-b80c-8e2bafcc78ca@github.com>
 <AjjRyNcaMQOA-qcgilZVf5STbEMEmWAoBy3_BidW48k=.15d682e2-f8b6-4e4d-8fc2-f482e117b6b2@github.com>
 <PSey24d8vzoiGbajbdvA6NJC3rogA2JSJ094bFILFBU=.ae2b5f7b-ebbc-40b5-bf97-17719df9c40e@github.com>
 <H8hznVoJQw6E6O09lymKyUYKc5PJSIf9vxV-C2419xg=.6275c817-e470-40ac-8b5c-803fb14950dc@github.com>
Message-ID: <vQrQ9PNZaSzfCfw4AZQe8pnUGIAB5FvAOncqzxguvlo=.9f26b5e8-a211-4856-b110-b0d220cc8880@github.com>

On Tue, 16 Dec 2025 20:43:14 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> More context: https://openjdk.org/jeps/137
>> 
>>> 1-1 Overview
>>> 
>>> The diagnostic command framework is fully implemented in native code and relies on HotSpot's internal exception mechanism. The rationale for a pure native implementation is to be able to execute diagnostic commands even in critical situations like an out-of-memory condition. All diagnostic commands are registered in a single list, and two flags control the way a user can interact with them. The hidden flag prevents a diagnostic command from appearing in the list of available commands returned by the help command. However, it's still possible to get the detailed help message for a hidden command with the help <command name> syntax, but it requires knowing the name of the hidden command. The second flag is enabled and it controls whether a command can be invoked or not. When listed with the help commands, disabled commands appear with a [disabled] label in their descriptions. If the user tries to invoke a disabled command, an error message is returned and the command is not run. Th
 is error message can be customized on a per-command basis. The framework just provides these two flags with their semantics; it doesn't provide any policy or mechanism to set or modify these flags. These actions will be delegated to the JVM or specific diagnostic commands.
>> 
>> The diagnostic command framework was developed at the same time we had requests to implement "Commercial features", the "enabled" flag might also have been intended to guard those commercial features (gone now).
>
> Thanks @fparain Frederic for the extra context.  Had wondered if this feature had ever been used, particularly all the mechanism around the possible JMX Notification.  After this change, we may look at whether it should be removed also.

Thanks @kevinjwalls @fparain @kevinjwalls for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/28794#issuecomment-3662832242

From iklam at openjdk.org  Tue Dec 16 23:20:27 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 16 Dec 2025 23:20:27 GMT
Subject: jmx-dev Integrated: 8373441: Remove DCmdFactory::_enabled
In-Reply-To: <XE188S-C6EdTA2PRsdsQTi4Z550PW6DNpL3awvANazU=.1b0cd4d1-56cd-491a-b80c-8e2bafcc78ca@github.com>
References: <XE188S-C6EdTA2PRsdsQTi4Z550PW6DNpL3awvANazU=.1b0cd4d1-56cd-491a-b80c-8e2bafcc78ca@github.com>
Message-ID: <RxByniX_b6rPrJESSqHi8WN2TJ1LdVqZJIfkBxNUjrM=.c1747871-bc12-45fa-9b42-56c1975b0d8f@github.com>

On Fri, 12 Dec 2025 14:54:52 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The `DCmdFactory::_enabled` is always set to `true` and there doesn't seem to be a reason to set it to `false`.
> 
> This PR removes this field and simplified the creation of `DCmdFactory` objects.
> 
> The related `_hidden` field is also currently not used, but may be used in the future when deprecating DCmds, so we leave it unchanged.
> 
> Note that now `jmm_GetDiagnosticCommandInfo()` always set `dcmdInfo::enabled` to `true` to be compatible with Java code.

This pull request has now been integrated.

Changeset: 3f077102
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3f07710270dbe7268f21828dff20e2eb810b1e70
Stats:     102 lines in 7 files changed: 4 ins; 25 del; 73 mod

8373441: Remove DCmdFactory::_enabled

Reviewed-by: kevinw, fparain, jsjolen

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

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