From alanb at openjdk.org Mon Nov 3 11:05:05 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 3 Nov 2025 11:05:05 GMT Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache creation [v4] In-Reply-To: References: Message-ID: On Wed, 29 Oct 2025 21:07:51 GMT, Mat Carter 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: > > Updated test based on comments src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 104: > 102: * > 103: * > 104: * @return {@code true} if a recording was in progress and has been ended successfully; {@code false} otherwise. Someone is bound to ask what happens if the "endRecording" operation is performed concurrently and there is recording in progress. Does one or all return true? I don't think it matters, the bigger issue here is that returning false means the recording has already ended or it failed. If it failed, why did it fail? I realize the intention is to add some properties and further operations to this MXBean but I think it would be good to think through if starting with a boolean returning operation is going to be problematic in the future. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2486085650 From alanb at openjdk.org Mon Nov 3 11:05:07 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 3 Nov 2025 11:05:07 GMT Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache creation [v4] In-Reply-To: References: <3DZMFG5pUixBip4O18gylfQpcCOTFxcwwVTWahRMBYo=.c9cb089e-6031-4b77-bb4a-775ed6cac818@github.com> Message-ID: <8XzXNt3iOeijZtZWB_zdMoWLPadJkgEbmaoqZQjEH1A=.a9fca7c1-9e42-4209-b21f-08af5554d344@github.com> On Wed, 29 Oct 2025 18:47:13 GMT, Mat Carter wrote: >> I see that now - fixing .... > > I also removed the nested {@code ..} from within the as that also caused an issue Good. You can move the example to a snippet too and that will allow the `
` tags to go away.

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

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

From egahlin at openjdk.org  Mon Nov  3 11:46:04 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 3 Nov 2025 11:46:04 GMT
Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache
 creation [v4]
In-Reply-To: 
References: 
 
Message-ID: <3w1fRC9HqhTnBzUPCsGGsw0q8H-wcY-km96h5W0S3To=.28f02299-e10b-4a20-a407-1a208e764a75@github.com>

On Wed, 29 Oct 2025 21:07:51 GMT, Mat Carter  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:
> 
>   Updated test based on comments

Can this be done using a diagnostic command, e.g. AOT.stop? It would allow the recording to be stopped from jcmd and the DiagnosticCommandMBean, without the need for a separate MXBean.

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

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

From macarte at openjdk.org  Mon Nov  3 20:08:22 2025
From: macarte at openjdk.org (Mat Carter)
Date: Mon, 3 Nov 2025 20:08:22 GMT
Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache
 creation [v4]
In-Reply-To: <3w1fRC9HqhTnBzUPCsGGsw0q8H-wcY-km96h5W0S3To=.28f02299-e10b-4a20-a407-1a208e764a75@github.com>
References: 
 
 <3w1fRC9HqhTnBzUPCsGGsw0q8H-wcY-km96h5W0S3To=.28f02299-e10b-4a20-a407-1a208e764a75@github.com>
Message-ID: 

On Mon, 3 Nov 2025 11:42:16 GMT, Erik Gahlin  wrote:

> Can this be done using a diagnostic command, e.g. AOT.stop? It would allow the recording to be stopped from jcmd and the DiagnosticCommandMBean, without the need for a separate MXBean.

Thank you for the suggestion

To answer your first question, we do have a diagnostic command (AOT.end_recording) and it would precede the AOT MXBean into mainline and it's PR is here: https://github.com/openjdk/jdk/pull/27965

The longer goal for this MXBean is to provide additional methods that would aid in monitoring (isRecording, currentRecordingLength etc.), however we decided to reduce the scope of the MXBean for main line while we continue to test the monitoring functionality in leyden/premain

Historically the diagnostic command came after the MXBean in leyden/premain, however I decided to implement the diagnostic command with the necessary JVM hooks first to simplify review

So technically we could delay this PR and still have the required functionality in mainline, I'd like to hear from the other reviewers on this matter

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

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

From heidinga at openjdk.org  Mon Nov  3 21:35:01 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Mon, 3 Nov 2025 21:35:01 GMT
Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache
 creation [v4]
In-Reply-To: 
References: 
 
 
Message-ID: <6LpN0Ae8kfDApFOPUYrbdqz2fRh8HVvvbCa8kiEEFS0=.31761484-c4c1-428c-9974-d2bdec3b587d@github.com>

On Mon, 3 Nov 2025 11:01:23 GMT, Alan Bateman  wrote:

>> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated test based on comments
>
> src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 104:
> 
>> 102:        *
>> 103: * >> 104: * @return {@code true} if a recording was in progress and has been ended successfully; {@code false} otherwise. > > Someone is bound to ask what happens if the "endRecording" operation is performed concurrently and there is recording in progress. Does one or all return true? I don't think it matters, the bigger issue here is that returning false means the recording has already ended or it failed. If it failed, why did it fail? I realize the intention is to add some properties and further operations to this MXBean but I think it would be good to think through if starting with a boolean returning operation is going to be problematic in the future. I see a couple of cases for when `endRecording` is called: 1) Within the same process to generate a cache - given the api will only return `true` to one caller, that caller is the only one who can be responsible for taking further action (copying the cache somewhere, etc). Already ended or failed makes no difference operationally. 2) From a monitoring process - again only the successful case matters. All failures (already ended or failed) are indistinguishable. No further action can be taken by the observer. It's only the success case that matters ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2487912197 From egahlin at openjdk.org Tue Nov 4 13:29:59 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 4 Nov 2025 13:29:59 GMT Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache creation [v4] In-Reply-To: References: Message-ID: On Wed, 29 Oct 2025 21:07:51 GMT, Mat Carter 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: > > Updated test based on comments > To answer your first question, we do have a diagnostic command (AOT.end_recording) and it would precede the AOT MXBean into mainline and its PR is here: #27965 Ah, I didn't know that. (I don?t have a strong opinion on this, but for consistency you might want the jcmd commands for AOT recording to use the same naming convention for starting, stopping, and checking the status of a recording as JFR: JFR.start, JFR.stop, JFR.check, JFR.dump and JFR.configure, where applicable. Initially, we had start_recording, but we later shortened it to start to avoid unnecessary typing) > The longer goal for this MXBean is to provide additional methods that would aid in monitoring (isRecording, currentRecordingLength etc.), however we decided to reduce the scope of the MXBean for main line while we continue to test the monitoring functionality in leyden/premain > > Historically the diagnostic command came after the MXBean in leyden/premain, however I decided to implement the diagnostic command with the necessary JVM hooks first to simplify review Ok. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28010#issuecomment-3486004039 From mr at openjdk.org Wed Nov 5 21:55:02 2025 From: mr at openjdk.org (Mark Reinhold) Date: Wed, 5 Nov 2025 21:55:02 GMT Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache creation [v4] In-Reply-To: References: Message-ID: On Wed, 29 Oct 2025 21:07:51 GMT, Mat Carter 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: > > Updated test based on comments Changes requested by mr (Lead). src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 78: > 76: * specification of the corresponding JVM command-line options, please refer > 77: * to https://openjdk.org/jeps/483 and https://openjdk.org/jeps/514. > 78: * Please don't use bare URLs. Change these to ... please refer to JEPs 483 and 514. ------------- PR Review: https://git.openjdk.org/jdk/pull/28010#pullrequestreview-3424599728 PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2496294936 From kevinw at openjdk.org Thu Nov 13 14:29:16 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 13 Nov 2025 14:29:16 GMT Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v10] In-Reply-To: References: Message-ID: On Wed, 29 Oct 2025 18:08:31 GMT, Jonas Norlinder wrote: >> Hi all, >> >> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding. >> >> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem. >> >> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM. >> >> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Fix phohensee review comments Looks good. Just a question on whether we really need to specify the GCs in the tests. I was hoping we can not do this, it seems like more to maintain that should be automatic as long as we do test batches with the different collectors. Do we need available GCs as specified in the tests get run on every test, or can we afford to let that be decided by the framework? (There might be some tests where we do want to make sure they run with all GCs regardless of what jtreg command runs, but I would hope that is a small set.) ------------- Marked as reviewed by kevinw (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27537#pullrequestreview-3460067101 From djelinski at openjdk.org Thu Nov 13 14:37:43 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 13 Nov 2025 14:37:43 GMT Subject: jmx-dev RFR: 8353738: Update TLS unit tests to not use certificates with MD5 signatures [v5] In-Reply-To: References: Message-ID: On Fri, 31 Oct 2025 15:02:42 GMT, Matthew Donovan 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 incrementally with one additional commit since the last revision: > > changed line wrapping Can you convert or remove the `IPAddressDNSIdentities` test as well? test/jdk/javax/net/ssl/HttpsURLConnection/CriticalSubjectAltName.java line 36: > 34: * @library /test/lib > 35: * @modules java.base/sun.security.x509 java.base/sun.security.util > 36: * @run main/othervm CriticalSubjectAltName TLSv1.2 MD5withRSA as far as I could tell, this test doesn't verify any functionality that would require a specific key type, it's simply using MD5 because that was the popular choice in 2008. Do we need to keep using MD5, or can we make it use whatever key type is the default? test/jdk/javax/net/ssl/HttpsURLConnection/CriticalSubjectAltName.java line 39: > 37: > 38: /* > 39: * This test depends on binary keystore, crisubn.jks and trusted.jks. Because Peease remove the crisubn.jks and trusted.jks files from this directory, they aren't used anywhere else. test/jdk/javax/net/ssl/HttpsURLConnection/CriticalSubjectAltName.java line 157: > 155: ks.setCertificateEntry("Trusted Cert", trustedCert); > 156: > 157: Certificate[] chain = new Certificate[] {serverCert, trustedCert}; (probably preexisting) you can remove the trusted cert from the chain; real servers usually don't send it. test/jdk/javax/net/ssl/HttpsURLConnection/CriticalSubjectAltName.java line 190: > 188: void doClientSide() throws Exception { > 189: > 190: if (!serverReady.await(SERVER_WAIT_SECS, TimeUnit.SECONDS)) { I'd remove the time limit, it only causes trouble when people increase test concurrency and timeout factors. test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java line 1: > 1: /* This might be preexisting, but this file is identical to `test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IPAddressIPIdentities.java` now. Can we remove one? test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IdentitiesBase.java line 104: > 102: CertificateBuilder.KeyUsage.KEY_ENCIPHERMENT) > 103: .addBasicConstraintsExt(false, false, -1) > 104: .addExtension(CertificateBuilder.createIPSubjectAltNameExt(true, "127.0.0.1")) I assume you verified that the DNSIdentities customization overwrites the SAN configured here, but I'd feel more confident if this line were moved to customizeServerCert in IPIdentities test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IdentitiesBase.java line 119: > 117: CertificateBuilder.KeyUsage.NONREPUDIATION, > 118: CertificateBuilder.KeyUsage.KEY_ENCIPHERMENT) > 119: .addExtension(CertificateBuilder.createIPSubjectAltNameExt(true, "127.0.0.1")) Same here. ------------- PR Review: https://git.openjdk.org/jdk/pull/27342#pullrequestreview-3459883168 PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2523546617 PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2523539070 PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2523561169 PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2523555451 PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2523677717 PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2523705701 PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2523706426 From macarte at openjdk.org Thu Nov 13 17:52:32 2025 From: macarte at openjdk.org (Mat Carter) Date: Thu, 13 Nov 2025 17:52:32 GMT Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache creation [v5] In-Reply-To: References: Message-ID: > 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: Adding test to validate using DiagnosticCommand MBean to invoke AOT.end_recording ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28010/files - new: https://git.openjdk.org/jdk/pull/28010/files/d48a200f..bff7cb74 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28010&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28010&range=03-04 Stats: 129 lines in 1 file changed: 129 ins; 0 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 Thu Nov 13 18:04:04 2025 From: macarte at openjdk.org (Mat Carter) Date: Thu, 13 Nov 2025 18:04:04 GMT Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache creation [v6] In-Reply-To: References: Message-ID: > 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: Revert "Adding test to validate using DiagnosticCommand MBean to invoke AOT.end_recording" Commit was intended for parent branch (that this branch is based on) This reverts commit bff7cb7408554232c13a57bba10b67a9fd19b811. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28010/files - new: https://git.openjdk.org/jdk/pull/28010/files/bff7cb74..6a100586 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28010&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28010&range=04-05 Stats: 129 lines in 1 file changed: 0 ins; 129 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 Thu Nov 13 18:58:53 2025 From: macarte at openjdk.org (Mat Carter) Date: Thu, 13 Nov 2025 18:58:53 GMT Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache creation [v7] In-Reply-To: References: Message-ID: > 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 changes from the CSR ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28010/files - new: https://git.openjdk.org/jdk/pull/28010/files/6a100586..b97a799f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28010&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28010&range=05-06 Stats: 67 lines in 1 file changed: 4 ins; 13 del; 50 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 Thu Nov 13 19:55:24 2025 From: macarte at openjdk.org (Mat Carter) Date: Thu, 13 Nov 2025 19:55:24 GMT Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache creation [v8] In-Reply-To: References: Message-ID: > 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: Remove single whitespace ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28010/files - new: https://git.openjdk.org/jdk/pull/28010/files/b97a799f..f4a4af61 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28010&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28010&range=06-07 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 dfuchs at openjdk.org Fri Nov 14 10:10:01 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 14 Nov 2025 10:10:01 GMT Subject: jmx-dev RFR: 8353738: Update TLS unit tests to not use certificates with MD5 signatures [v5] In-Reply-To: References: Message-ID: On Thu, 13 Nov 2025 14:32:33 GMT, Daniel Jeli?ski wrote: >> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision: >> >> changed line wrapping > > test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IdentitiesBase.java line 104: > >> 102: CertificateBuilder.KeyUsage.KEY_ENCIPHERMENT) >> 103: .addBasicConstraintsExt(false, false, -1) >> 104: .addExtension(CertificateBuilder.createIPSubjectAltNameExt(true, "127.0.0.1")) > > I assume you verified that the DNSIdentities customization overwrites the SAN configured here, but I'd feel more confident if this line were moved to customizeServerCert in IPIdentities If there is an alternative SAN for IPv4 loopback address there should be one for the IPv6 loopback too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2526848102 From duke at openjdk.org Fri Nov 14 11:11:43 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Fri, 14 Nov 2025 11:11:43 GMT Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v10] In-Reply-To: References: Message-ID: On Wed, 29 Oct 2025 18:08:31 GMT, Jonas Norlinder wrote: >> Hi all, >> >> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding. >> >> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem. >> >> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM. >> >> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Fix phohensee review comments Thanks Kevin! > Just a question on whether we really need to specify the GCs in the tests. I think it is required for the shutdown test and we need to keep them all. However, we may omit this for the trivial API test. Would that be a reasonable compromise? I'd suggest to keep Epsilon and G1 for `TestGetTotalGcCpuTime`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3532230611 From duke at openjdk.org Fri Nov 14 11:29:48 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Fri, 14 Nov 2025 11:29:48 GMT Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v11] In-Reply-To: References: Message-ID: > Hi all, > > This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding. > > `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem. > > FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM. > > Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug. Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: Reduce GC coverage for trivial API test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27537/files - new: https://git.openjdk.org/jdk/pull/27537/files/44f5d864..8fd1ee09 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27537&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27537&range=09-10 Stats: 36 lines in 1 file changed: 0 ins; 36 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27537.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27537/head:pull/27537 PR: https://git.openjdk.org/jdk/pull/27537 From kevinw at openjdk.org Fri Nov 14 12:11:11 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 14 Nov 2025 12:11:11 GMT Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v10] In-Reply-To: References: Message-ID: On Fri, 14 Nov 2025 11:08:40 GMT, Jonas Norlinder wrote: > I think it is required for the shutdown test and we need to keep them all. However, we may omit this for the trivial API test. Would that be a reasonable compromise? I'd suggest to keep Epsilon and G1 for `TestGetTotalGcCpuTime`. OK that's great to cut it down a bit, thanks. I meant I think we need to remove all the specific GCs from that test, and let the test harness run with the variety of collectors. If test/jdk/java/lang/management/MemoryMXBean/TestGetTotalGcCpuTime.java specifies those two, doesn't it only run with those two? We want most code to be tested with a variety of collectors, we should get that if we just say nothing. 8-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3532441029 From kevinw at openjdk.org Fri Nov 14 14:52:16 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 14 Nov 2025 14:52:16 GMT Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v11] In-Reply-To: References: Message-ID: On Fri, 14 Nov 2025 11:29:48 GMT, Jonas Norlinder wrote: >> Hi all, >> >> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding. >> >> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem. >> >> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM. >> >> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Reduce GC coverage for trivial API test Or, if we don't want to remove the GC specifics and go with what the framework sets, then we should revert that last delete, sorry, otherwise with will just not be run with all GCs. I was thinking it was more efficient to say nothing in the test, but can leave this to be done with specifics in the test if you like. 8-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3533138317 From duke at openjdk.org Fri Nov 14 21:21:16 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Fri, 14 Nov 2025 21:21:16 GMT Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v12] In-Reply-To: References: Message-ID: > Hi all, > > This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding. > > `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem. > > FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM. > > Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug. Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: Revert "Reduce GC coverage for trivial API test" This reverts commit 8fd1ee093066138c9aa5602dcac0e7db1916db6b. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27537/files - new: https://git.openjdk.org/jdk/pull/27537/files/8fd1ee09..97978d04 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27537&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27537&range=10-11 Stats: 36 lines in 1 file changed: 36 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27537.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27537/head:pull/27537 PR: https://git.openjdk.org/jdk/pull/27537 From duke at openjdk.org Fri Nov 14 21:23:22 2025 From: duke at openjdk.org (duke) Date: Fri, 14 Nov 2025 21:23:22 GMT Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v11] In-Reply-To: References: Message-ID: On Fri, 14 Nov 2025 11:29:48 GMT, Jonas Norlinder wrote: >> Hi all, >> >> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding. >> >> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem. >> >> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM. >> >> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Reduce GC coverage for trivial API test @JonasNorlinder Your change (at version 97978d04c241061cd0fdf656748bfe08da88017a) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3534600306 From kevinw at openjdk.org Mon Nov 17 10:45:34 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 17 Nov 2025 10:45:34 GMT Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v12] In-Reply-To: References: Message-ID: <4qjsyzSPqc8GERYbwMkCVTvoa547lAHi2in0d1MotCY=.7f7d0fcd-bc20-49e6-833a-3ec2404006f8@github.com> On Fri, 14 Nov 2025 21:21:16 GMT, Jonas Norlinder wrote: >> Hi all, >> >> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding. >> >> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem. >> >> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM. >> >> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Revert "Reduce GC coverage for trivial API test" > > This reverts commit 8fd1ee093066138c9aa5602dcac0e7db1916db6b. Marked as reviewed by kevinw (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27537#pullrequestreview-3472086274 From duke at openjdk.org Mon Nov 17 10:45:36 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Mon, 17 Nov 2025 10:45:36 GMT Subject: jmx-dev Integrated: 8368527: JMX: Add an MXBeans method to query GC CPU time In-Reply-To: References: Message-ID: On Sat, 27 Sep 2025 11:18:58 GMT, Jonas Norlinder wrote: > Hi all, > > This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding. > > `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem. > > FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM. > > Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug. This pull request has now been integrated. Changeset: 812add27 Author: Jonas Norlinder Committer: Kevin Walls URL: https://git.openjdk.org/jdk/commit/812add27abdc70bc52ca105bc9430494a6491ecd Stats: 305 lines in 12 files changed: 302 ins; 1 del; 2 mod 8368527: JMX: Add an MXBeans method to query GC CPU time Reviewed-by: phh, kevinw ------------- PR: https://git.openjdk.org/jdk/pull/27537 From pchilanomate at openjdk.org Wed Nov 19 19:06:34 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 19 Nov 2025 19:06:34 GMT Subject: jmx-dev RFR: 8364343: ThreadSnapshotFactory::get_thread_snapshot() crashes without JVMTI agent [v2] In-Reply-To: References: Message-ID: > 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 would be to place extra overhead on the thread requesting to disable transitions (e.g. by usi ng a safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so I believe this approach is simpler. > > - 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 unmount cases, and a... Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: Add fixes to DumpThreadsWithEliminatedLock.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28361/files - new: https://git.openjdk.org/jdk/pull/28361/files/70f96a7d..976486cd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28361&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28361&range=00-01 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 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 Wed Nov 19 19:06:37 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 19 Nov 2025 19:06:37 GMT Subject: jmx-dev RFR: 8364343: ThreadSnapshotFactory::get_thread_snapshot() crashes without JVMTI agent [v2] In-Reply-To: References: Message-ID: On Wed, 19 Nov 2025 13:50:44 GMT, Alan Bateman wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: >> >> Add fixes to DumpThreadsWithEliminatedLock.java > > src/java.base/share/classes/java/lang/VirtualThread.java line 1390: > >> 1388: } >> 1389: >> 1390: // -- JVM TI support -- > > We'll need to update is comment as it no longer only for JVMTI. > > This might be a good place for a block comment to define "transitions" covering the changing of thread identity the continuation mount/unmount, and how the notification to the VM support JVMTI and handshakes. Maybe I could contribute a block comment to include here? That would be great. > src/java.base/share/native/libjava/VirtualThread.c line 38: > >> 36: { "startFinalTransition", "()V", (void *)&JVM_VirtualThreadEnd }, >> 37: { "startTransition", "(Z)V", (void *)&JVM_VirtualThreadStartTransition }, >> 38: { "endTransition", "(Z)V", (void *)&JVM_VirtualThreadEndTransition }, > > I wonder if JVM_VirtualThreadStart and JVM_VirtualThreadEnd should be renamed to have EndFirstTransition and StartFinalTransaction in the names so it's easy to follow through from the Java code down to MountUnmountDisabler::start_transition/end_transition. 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 > test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreadsWhenParking.java line 94: > >> 92: }); >> 93: } >> 94: // wait for all virtual threads to start so all have a non-empty stack > > This reminds me the loom repo has a small update to to the DumpThreadsWithEliminatedLock.java test to ensure that the virtual thread starts execution before doing the thread dump. This was noticed with test-repeat runs of the new test to ensure it was stable. Added the fixes to `DumpThreadsWithEliminatedLock.java` from the loom repo. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2543217770 PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2543212884 PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2543215701 From macarte at openjdk.org Wed Nov 19 22:40:54 2025 From: macarte at openjdk.org (Mat Carter) Date: Wed, 19 Nov 2025 22:40:54 GMT Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache creation [v8] In-Reply-To: <8XzXNt3iOeijZtZWB_zdMoWLPadJkgEbmaoqZQjEH1A=.a9fca7c1-9e42-4209-b21f-08af5554d344@github.com> References: <3DZMFG5pUixBip4O18gylfQpcCOTFxcwwVTWahRMBYo=.c9cb089e-6031-4b77-bb4a-775ed6cac818@github.com> <8XzXNt3iOeijZtZWB_zdMoWLPadJkgEbmaoqZQjEH1A=.a9fca7c1-9e42-4209-b21f-08af5554d344@github.com> Message-ID: On Mon, 3 Nov 2025 11:01:56 GMT, Alan Bateman wrote: >> I also removed the nested {@code ..} from within the as that also caused an issue > > Good. You can move the example to a snippet too and that will allow the `
` tags to go away.

In the latest CSR the code snippet was removed

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

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

From pchilanomate at openjdk.org  Thu Nov 20 20:52:05 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 20 Nov 2025 20:52:05 GMT
Subject: jmx-dev RFR: 8364343:
 ThreadSnapshotFactory::get_thread_snapshot() crashes without JVMTI agent
 [v3]
In-Reply-To: 
References: 
Message-ID: 

> 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 tra
 nsitions (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 unm...

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

  Add Alan's comment in VirtualThread

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28361/files
  - new: https://git.openjdk.org/jdk/pull/28361/files/976486cd..205ae77b

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

  Stats: 12 lines in 1 file changed: 11 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  Thu Nov 20 20:55:22 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 20 Nov 2025 20:55:22 GMT
Subject: jmx-dev RFR: 8364343:
 ThreadSnapshotFactory::get_thread_snapshot() crashes without JVMTI agent
 [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 19 Nov 2025 19:03:13 GMT, Patricio Chilano Mateo  wrote:

>> src/java.base/share/classes/java/lang/VirtualThread.java line 1390:
>> 
>>> 1388:     }
>>> 1389: 
>>> 1390:     // -- JVM TI support --
>> 
>> We'll need to update is comment as it no longer only for JVMTI. 
>> 
>> This might be a good place for a block comment to define "transitions" covering the changing of thread identity the continuation mount/unmount, and how the notification to the VM support JVMTI and handshakes.  Maybe I could contribute a block comment to include here?
>
> That would be great.

Thanks, added the suggested comment.

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

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

From dholmes at openjdk.org  Thu Nov 20 22:16:18 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 20 Nov 2025 22:16:18 GMT
Subject: jmx-dev RFR: 8364343:
 ThreadSnapshotFactory::get_thread_snapshot() crashes without JVMTI agent
 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 20 Nov 2025 20:52:05 GMT, Patricio Chilano Mateo  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:
> 
>   Add Alan's comment in VirtualThread

As this involves a fairly significant design change I suggest updating the JBS issue to have a more informative title e.g. "Virtual Thread transition management needs to be independent of JVM TI"

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

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

From pchilanomate at openjdk.org  Thu Nov 20 23:10:48 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 20 Nov 2025 23:10:48 GMT
Subject: jmx-dev RFR: 8364343: Virtual Thread transition management
 needs to be independent of JVM TI [v4]
In-Reply-To: 
References: 
Message-ID: 

> 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:

  Rename VM methods for endFirstTransition/startFinalTransition

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28361/files
  - new: https://git.openjdk.org/jdk/pull/28361/files/205ae77b..10534b33

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

  Stats: 20 lines in 8 files changed: 0 ins; 0 del; 20 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  Thu Nov 20 23:10:49 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 20 Nov 2025 23:10:49 GMT
Subject: jmx-dev RFR: 8364343: Virtual Thread transition management
 needs to be independent of JVM TI [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 20 Nov 2025 22:14:15 GMT, David Holmes  wrote:

> As this involves a fairly significant design change I suggest updating the JBS issue to have a more informative title e.g. "Virtual Thread transition management needs to be independent of JVM TI"
>
Yes, that's better. Updated.

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

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

From pchilanomate at openjdk.org  Thu Nov 20 23:10:52 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 20 Nov 2025 23:10:52 GMT
Subject: jmx-dev RFR: 8364343: Virtual Thread transition management
 needs to be independent of JVM TI [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 19 Nov 2025 19:01:18 GMT, Patricio Chilano Mateo  wrote:

>> src/java.base/share/native/libjava/VirtualThread.c line 38:
>> 
>>> 36:     { "startFinalTransition",     "()V",  (void *)&JVM_VirtualThreadEnd },
>>> 37:     { "startTransition",          "(Z)V", (void *)&JVM_VirtualThreadStartTransition },
>>> 38:     { "endTransition",            "(Z)V", (void *)&JVM_VirtualThreadEndTransition },
>> 
>> I wonder if JVM_VirtualThreadStart and JVM_VirtualThreadEnd should be renamed to have EndFirstTransition and StartFinalTransaction in the names so it's easy to follow through from the Java code down to MountUnmountDisabler::start_transition/end_transition.
>
> 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.

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

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

From dholmes at openjdk.org  Fri Nov 21 01:00:58 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 21 Nov 2025 01:00:58 GMT
Subject: jmx-dev RFR: 8364343: Virtual Thread transition management
 needs to be independent of JVM TI [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 20 Nov 2025 23:10:48 GMT, Patricio Chilano Mateo  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:
> 
>   Rename VM methods for endFirstTransition/startFinalTransition

Hi Patricio, this is another significant piece of work. I have taken an initial pass through trying to digest the main parts - can't comment on the C2 code or the Java side. I have made a few minor comments/suggestions.

Thanks

src/hotspot/share/prims/jvm.cpp line 3668:

> 3666:   if (!DoJVMTIVirtualThreadTransitions) {
> 3667:     assert(!JvmtiExport::can_support_virtual_threads(), "sanity check");
> 3668:     return;

Does this not still need checking somewhere?

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

> 160:   // be executed once we go back to Java. If this is an unmount, the handshake that the
> 161:   // disabler executed against this carrier thread already provided the needed synchronization.
> 162:   // This matches the release fence in xx_enable_for_one()/xx_enable_for_all().

Subtle. Do we have comments where the fences are to ensure people realize the fence is serving this purpose?

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

> 275: 
> 276:   // Start of the critical region. Prevent future memory
> 277:   // operations to be ordered before we read the transition flag.

Does this refer to `java_lang_Thread::is_in_VTMS_transition(_vthread())`? If so perhaps that should internally perform the `load_acquire`?

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

> 276:   // Start of the critical region. Prevent future memory
> 277:   // operations to be ordered before we read the transition flag.
> 278:   // This matches the release fence in end_transition().

Suggestion:

  // This pairs with the release fence in end_transition().

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

> 305:   // Block while some mount/unmount transitions are in progress.
> 306:   // Debug version fails and prints diagnostic information.
> 307:   for (JavaThreadIteratorWithHandle jtiwh; JavaThread *jt = jtiwh.next(); ) {

This looks very odd, having an assignment in the loop condition check and no actual loop-update expression.

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

> 314:   // operations to be ordered before we read the transition flags.
> 315:   // This matches the release fence in end_transition().
> 316:   OrderAccess::acquire();

Surely the use of the iterator already provides the necessary ordering guarantee here as well. ?

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

> 325:   // End of the critical section. Prevent previous memory operations to
> 326:   // be ordered after we clear the clear the disable transition flag.
> 327:   // This matches the equivalent acquire fence in start_transition().

Suggestion:

  // This pairs with the acquire in start_transition().

I just realized you are using "fence" to describe release and acquire memory barrier semantics. Given we have an operation `fence` I find this confusing for the reader - especially when we also have a `release_store_fence` operation which might be confused with "release fence".

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

> 368:   assert(VTMSTransition_lock->owned_by_self() || SafepointSynchronize::is_at_safepoint(), "Must be locked");
> 369:   assert(_global_start_transition_disable_count >= 0, "");
> 370:   AtomicAccess::store(&_global_start_transition_disable_count, _global_start_transition_disable_count + 1);

Suggestion:

  AtomicAccess::inc(&_global_start_transition_disable_count);

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

> 374:   assert(VTMSTransition_lock->owned_by_self() || SafepointSynchronize::is_at_safepoint(), "Must be locked");
> 375:   assert(_global_start_transition_disable_count > 0, "");
> 376:   AtomicAccess::store(&_global_start_transition_disable_count, _global_start_transition_disable_count - 1);

Suggestion:

  AtomicAccess::dec(&_global_start_transition_disable_count);

src/hotspot/share/runtime/mountUnmountDisabler.hpp line 52:

> 50:   // parameter is_SR: suspender or resumer
> 51:   MountUnmountDisabler(bool exlusive = false);
> 52:   MountUnmountDisabler(oop thread_oop);

What does the comment mean here?

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

PR Review: https://git.openjdk.org/jdk/pull/28361#pullrequestreview-3490207826
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2547887801
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2548145054
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2548157390
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2548150552
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2548160373
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2548161340
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2548168223
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2548169846
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2548170787
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2548174392

From dholmes at openjdk.org  Fri Nov 21 01:01:00 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 21 Nov 2025 01:01:00 GMT
Subject: jmx-dev RFR: 8364343: Virtual Thread transition management
 needs to be independent of JVM TI [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 20 Nov 2025 20:52:05 GMT, Patricio Chilano Mateo  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:
> 
>   Add Alan's comment in VirtualThread

src/hotspot/share/classfile/javaClasses.cpp line 1757:

> 1755:   jint* addr = java_thread->field_addr(_VTMS_transition_disable_count_offset);
> 1756:   int val = AtomicAccess::load(addr);
> 1757:   AtomicAccess::store(addr, val + 1);

Suggestion:

  AtomicAccess::inc(addr);

src/hotspot/share/classfile/javaClasses.cpp line 1764:

> 1762:   jint* addr = java_thread->field_addr(_VTMS_transition_disable_count_offset);
> 1763:   int val = AtomicAccess::load(addr);
> 1764:   AtomicAccess::store(addr, val - 1);

Suggestion:

  AtomicAccess::dec(addr);

src/hotspot/share/opto/runtime.hpp line 740:

> 738:     return vthread_transition_Type();
> 739:   }
> 740: 

I do not know C2 but this looks really strange - 4 different functions all return the same thing. ???

src/hotspot/share/runtime/handshake.cpp line 374:

> 372:     JavaThread* target = java_lang_Thread::thread(carrier_thread);
> 373:     assert(target != nullptr, "");
> 374:     // Technically there is need for a ThreadsListHandle since the target

Suggestion:

    // Technically there is no need for a ThreadsListHandle since the target

?

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

> 145:       MonitorLocker ml(VTMSTransition_lock);
> 146:       while (is_start_transition_disabled(current, vth())) {
> 147:         ml.wait(200);

I see a lot of timed-waits throughout this code. Is that because we poll rather than synchronizing properly? All this potential busy-waiting is surely going to cause performance glitches.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2547864726
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2547863852
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2547884313
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2547900707
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2547963241

From dholmes at openjdk.org  Fri Nov 21 01:04:59 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 21 Nov 2025 01:04:59 GMT
Subject: jmx-dev RFR: 8364343: Virtual Thread transition management
 needs to be independent of JVM TI [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 21 Nov 2025 00:35:38 GMT, David Holmes  wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename VM methods for endFirstTransition/startFinalTransition
>
> src/hotspot/share/runtime/mountUnmountDisabler.cpp line 162:
> 
>> 160:   // be executed once we go back to Java. If this is an unmount, the handshake that the
>> 161:   // disabler executed against this carrier thread already provided the needed synchronization.
>> 162:   // This matches the release fence in xx_enable_for_one()/xx_enable_for_all().
> 
> Subtle. Do we have comments where the fences are to ensure people realize the fence is serving this purpose?

I also forgot to suggest a wording change: say "pairs with" rather than "matches". Reading back through I realize now I have misunderstood many of these comments.

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

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

From dholmes at openjdk.org  Fri Nov 21 01:26:21 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 21 Nov 2025 01:26:21 GMT
Subject: jmx-dev RFR: 8364343: Virtual Thread transition management
 needs to be independent of JVM TI [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 20 Nov 2025 23:10:48 GMT, Patricio Chilano Mateo  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:
> 
>   Rename VM methods for endFirstTransition/startFinalTransition

> we follow the classic Dekker pattern for the required synchronization. 

My understanding is that Dekker requires a "full fence" between the accesses, not just ordering memory barriers.  The two variables involved must be published to all readers for the algorithm to work.

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

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

From alanb at openjdk.org  Fri Nov 21 11:35:57 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 21 Nov 2025 11:35:57 GMT
Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache
 creation [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 13 Nov 2025 19:55:24 GMT, Mat Carter  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:
> 
>   Remove single whitespace

I went through the plumbing to check the registration with the platform MBeanServer and everything looks okay (and consistent with how the other JDK-specific management interfaces are setup and registered).

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.

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

PR Comment: https://git.openjdk.org/jdk/pull/28010#issuecomment-3562626766
PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2549470742

From alanb at openjdk.org  Fri Nov 21 12:04:29 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 21 Nov 2025 12:04:29 GMT
Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache
 creation [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 13 Nov 2025 19:55:24 GMT, Mat Carter  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:
> 
>   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?

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.

test/hotspot/jtreg/runtime/cds/appcds/aotCache/HotSpotAOTCacheMXBeanTest.java line 92:

> 90:                 }
> 91:                 out.shouldNotContain("HotSpotAOTCacheMXBean is not available");
> 92:                 out.shouldNotContain("IOException occurred!");

Have you considering have the child terminate with an exception so the exit status is non-0. If you get a success status then the output should have the expected strings. A non-0 would failure, and the test fails.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2549496991
PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2549513596
PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2549518555

From mdonovan at openjdk.org  Fri Nov 21 19:51:57 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Fri, 21 Nov 2025 19:51:57 GMT
Subject: jmx-dev RFR: 8353738: Update TLS unit tests to not use
 certificates with MD5 signatures [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 13 Nov 2025 13:49:55 GMT, Daniel Jeli?ski  wrote:

>> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   changed line wrapping
>
> test/jdk/javax/net/ssl/HttpsURLConnection/CriticalSubjectAltName.java line 36:
> 
>> 34:  * @library /test/lib
>> 35:  * @modules java.base/sun.security.x509 java.base/sun.security.util
>> 36:  * @run main/othervm CriticalSubjectAltName TLSv1.2 MD5withRSA
> 
> as far as I could tell, this test doesn't verify any functionality that would require a specific key type, it's simply using MD5 because that was the popular choice in 2008. Do we need to keep using MD5, or can we make it use whatever key type is the default?

It was suggested to keep test cases for TLS 1.2/MD5 as well as updating for TLS 1.3. If the TLS 1.2/MD5 isn't adding anything here I can remove it.

> test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java line 1:
> 
>> 1: /*
> 
> This might be preexisting, but this file is identical to `test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IPAddressIPIdentities.java` now. Can we remove one?

I compared the two files from before I updated IPIdentities and they are identical. I removed IPIdentities.java

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2550794961
PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2550797069

From mdonovan at openjdk.org  Fri Nov 21 19:51:58 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Fri, 21 Nov 2025 19:51:58 GMT
Subject: jmx-dev RFR: 8353738: Update TLS unit tests to not use
 certificates with MD5 signatures [v5]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Fri, 14 Nov 2025 10:04:07 GMT, Daniel Fuchs  wrote:

>> test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IdentitiesBase.java line 104:
>> 
>>> 102:                         CertificateBuilder.KeyUsage.KEY_ENCIPHERMENT)
>>> 103:                 .addBasicConstraintsExt(false, false, -1)
>>> 104:                 .addExtension(CertificateBuilder.createIPSubjectAltNameExt(true, "127.0.0.1"))
>> 
>> I assume you verified that the DNSIdentities customization overwrites the SAN configured here, but I'd feel more confident if this line were moved to customizeServerCert in IPIdentities
>
> If there is an alternative SAN for IPv4 loopback address there should be one for the IPv6 loopback too.

> I assume you verified that the DNSIdentities customization overwrites the SAN configured here, but I'd feel more confident if this line were moved to customizeServerCert in IPIdentities

Yes, they are overwritten, extensions are stored as a Map between extention id and the extension.

> If there is an alternative SAN for IPv4 loopback address there should be one for the IPv6 loopback too.

I added the IPV6 loopback.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2550800219

From mdonovan at openjdk.org  Fri Nov 21 20:14:53 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Fri, 21 Nov 2025 20:14:53 GMT
Subject: jmx-dev RFR: 8353738: Update TLS unit tests to not use
 certificates with MD5 signatures [v6]
In-Reply-To: 
References: 
Message-ID: 

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

 - 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
 - fixed indents and copyright year
 - Merge branch 'master' into update-md5-certs
 - ... and 1 more: https://git.openjdk.org/jdk/compare/c70734d2...6579bc79

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27342/files
  - new: https://git.openjdk.org/jdk/pull/27342/files/1aaf4247..6579bc79

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

  Stats: 300342 lines in 2569 files changed: 194979 ins; 65676 del; 39687 mod
  Patch: https://git.openjdk.org/jdk/pull/27342.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27342/head:pull/27342

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

From sspitsyn at openjdk.org  Sat Nov 22 09:00:49 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 22 Nov 2025 09:00:49 GMT
Subject: jmx-dev RFR: 8364343: Virtual Thread transition management
 needs to be independent of JVM TI [v4]
In-Reply-To: 
References: 
 
Message-ID: <6WDKeD8iQTXDPhR0ohPvA6KVufW0uXHBmyZ5oOWfYWI=.44d63e7f-fbdb-47b6-8b36-f0d0cb35fb91@github.com>

On Thu, 20 Nov 2025 23:10:48 GMT, Patricio Chilano Mateo  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:
> 
>   Rename VM methods for endFirstTransition/startFinalTransition

src/hotspot/share/runtime/javaThread.cpp line 1173:

> 1171: bool JavaThread::java_suspend(bool register_vthread_SR) {
> 1172: #if INCLUDE_JVMTI
> 1173:   // Suspending a JavaThread in VTMS transition or disabling VTMS transitions can cause deadlocks.

Q: I wonder if the `#if INCLUDE_JVMTI` and `#endif` can be removed here.

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!

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

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

From sspitsyn at openjdk.org  Sat Nov 22 09:00:50 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 22 Nov 2025 09:00:50 GMT
Subject: jmx-dev RFR: 8364343: Virtual Thread transition management
 needs to be independent of JVM TI [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 20 Nov 2025 22:55:35 GMT, David Holmes  wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add Alan's comment in VirtualThread
>
> src/hotspot/share/runtime/mountUnmountDisabler.cpp line 147:
> 
>> 145:       MonitorLocker ml(VTMSTransition_lock);
>> 146:       while (is_start_transition_disabled(current, vth())) {
>> 147:         ml.wait(200);
> 
> I see a lot of timed-waits throughout this code. Is that because we poll rather than synchronizing properly? All this potential busy-waiting is surely going to cause performance glitches.

The timeouts are for reliability purposes only. Technically, they are not needed and can be removed after this code becomes stable. The `wait()` calls are inside while loop which rechecks the loop-ending conditions.

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

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

From sspitsyn at openjdk.org  Sat Nov 22 09:00:52 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 22 Nov 2025 09:00:52 GMT
Subject: jmx-dev RFR: 8364343: Virtual Thread transition management
 needs to be independent of JVM TI [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 21 Nov 2025 00:52:05 GMT, David Holmes  wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename VM methods for endFirstTransition/startFinalTransition
>
> src/hotspot/share/runtime/mountUnmountDisabler.hpp line 52:
> 
>> 50:   // parameter is_SR: suspender or resumer
>> 51:   MountUnmountDisabler(bool exlusive = false);
>> 52:   MountUnmountDisabler(oop thread_oop);
> 
> What does the comment mean here?

This comment is stale now and must be removed. The parameter `is_SR` is being replaced with the `exclusive`.

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

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

From sspitsyn at openjdk.org  Sat Nov 22 09:15:49 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 22 Nov 2025 09:15:49 GMT
Subject: jmx-dev RFR: 8364343: Virtual Thread transition management
 needs to be independent of JVM TI [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 20 Nov 2025 23:10:48 GMT, Patricio Chilano Mateo  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:
> 
>   Rename VM methods for endFirstTransition/startFinalTransition

I've completed my first pass trough this update, and it looks pretty solid in general.
I'm going to make another pass next week.

src/hotspot/share/prims/jvm.cpp line 3682:

> 3680: JVM_ENTRY(void, JVM_VirtualThreadEndTransition(JNIEnv* env, jobject vthread, jboolean is_mount))
> 3681:   oop vt = JNIHandles::resolve_external_guard(vthread);
> 3682:   MountUnmountDisabler::end_transition(thread, vt, is_mount, false /*is_thread_start*/);

The `JVM_VirtualThread*` functions have been nicely simplified.

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

PR Review: https://git.openjdk.org/jdk/pull/28361#pullrequestreview-3496249775
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2552682664

From djelinski at openjdk.org  Mon Nov 24 12:23:31 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 24 Nov 2025 12:23:31 GMT
Subject: jmx-dev RFR: 8353738: Update TLS unit tests to not use
 certificates with MD5 signatures [v6]
In-Reply-To: 
References: 
 
Message-ID: <8bHfiZThBv6oNAn_y-trnWR-LqxZRAXgDdHEbdtOQ4E=.7527f68f-9a7a-4140-b4fb-2bdb0e2573fd@github.com>

On Fri, 21 Nov 2025 20:14:53 GMT, Matthew Donovan  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 11 additional commits since the last revision:
> 
>  - 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
>  - fixed indents and copyright year
>  - Merge branch 'master' into update-md5-certs
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/904578e0...6579bc79

Please convert the IPAddressDNSIdentities test as well. It's expecting a handshake failure, but now it's passing for the wrong reasons. Other than that, LGTM.

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

PR Comment: https://git.openjdk.org/jdk/pull/27342#issuecomment-3570521948

From mdonovan at openjdk.org  Mon Nov 24 17:22:39 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Mon, 24 Nov 2025 17:22:39 GMT
Subject: jmx-dev RFR: 8353738: Update TLS unit tests to not use
 certificates with MD5 signatures [v7]
In-Reply-To: 
References: 
Message-ID: 

> 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/cd9e5e5a...ea9c2dce

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27342/files
  - new: https://git.openjdk.org/jdk/pull/27342/files/6579bc79..ea9c2dce

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

  Stats: 1138 lines in 16 files changed: 412 ins; 630 del; 96 mod
  Patch: https://git.openjdk.org/jdk/pull/27342.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27342/head:pull/27342

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

From macarte at openjdk.org  Tue Nov 25 01:04:37 2025
From: macarte at openjdk.org (Mat Carter)
Date: Tue, 25 Nov 2025 01:04:37 GMT
Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache
 creation [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 5 Nov 2025 21:48:41 GMT, Mark Reinhold  wrote:

>> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated test based on comments
>
> src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 78:
> 
>> 76:        *  specification of the corresponding JVM command-line options, please refer
>> 77:        * to https://openjdk.org/jeps/483 and https://openjdk.org/jeps/514.
>> 78:        *
> 
> Please don't use bare URLs. Change these to
> 
> ... please refer to JEPs 483 and
> 514.

fixed

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

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

From kevinw at openjdk.org  Tue Nov 25 12:07:18 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 25 Nov 2025 12:07:18 GMT
Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache
 creation [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 13 Nov 2025 19:55:24 GMT, Mat Carter  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:
> 
>   Remove single whitespace

src/jdk.management/share/classes/com/sun/management/internal/HotSpotAOTCacheImpl.java line 48:

> 46:     }
> 47: 
> 48:     public boolean endRecording(){

trivial missing space nit (){

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

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

From kevinw at openjdk.org  Tue Nov 25 12:13:41 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 25 Nov 2025 12:13:41 GMT
Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache
 creation [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 13 Nov 2025 19:55:24 GMT, Mat Carter  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:
> 
>   Remove single whitespace

src/jdk.management/share/classes/com/sun/management/internal/PlatformMBeanProviderImpl.java line 192:

> 190:                 HotSpotAOTCacheMXBean impl = this.impl;
> 191:                 if (impl == null) {
> 192:                     this.impl = impl = new HotSpotAOTCacheImpl(ManagementFactoryHelper.getVMManagement());

This assignment is unusual.  Are we trying to avoid a synchronized block? Other nameToMBeanMap() methods are like:
	return Collections.singletonMap(ManagementFactory.MEMORY_MXBEAN_NAME, ManagementFactoryHelper.getMemoryMXBean());
	
..where the ManagementFactoryHelper.getMemoryMXBean() method is synchronized and creates the impl if needed.

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

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

From alanb at openjdk.org  Tue Nov 25 12:26:32 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 25 Nov 2025 12:26:32 GMT
Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache
 creation [v8]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 25 Nov 2025 12:10:02 GMT, Kevin Walls  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/com/sun/management/internal/PlatformMBeanProviderImpl.java line 192:
> 
>> 190:                 HotSpotAOTCacheMXBean impl = this.impl;
>> 191:                 if (impl == null) {
>> 192:                     this.impl = impl = new HotSpotAOTCacheImpl(ManagementFactoryHelper.getVMManagement());
> 
> This assignment is unusual.  Are we trying to avoid a synchronized block? Other nameToMBeanMap() methods are like:
> 	return Collections.singletonMap(ManagementFactory.MEMORY_MXBEAN_NAME, ManagementFactoryHelper.getMemoryMXBean());
> 	
> ..where the ManagementFactoryHelper.getMemoryMXBean() method is synchronized and creates the impl if needed.

I don't see a correctly issue with this. Maybe in the future we will be able to use LazyConstant here.

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

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

From pchilanomate at openjdk.org  Tue Nov 25 19:58:40 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 25 Nov 2025 19:58:40 GMT
Subject: jmx-dev RFR: 8364343: Virtual Thread transition management
 needs to be independent of JVM TI [v3]
In-Reply-To: 
References: 
 
 
Message-ID: <-MtOiSQVDvlQD7sbfeBiqF00_ZN9_aNt3zd2LZLljyo=.eeabb717-359d-4420-89aa-ed1b305beee5@github.com>

On Thu, 20 Nov 2025 22:17:53 GMT, David Holmes  wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add Alan's comment in VirtualThread
>
> src/hotspot/share/classfile/javaClasses.cpp line 1757:
> 
>> 1755:   jint* addr = java_thread->field_addr(_VTMS_transition_disable_count_offset);
>> 1756:   int val = AtomicAccess::load(addr);
>> 1757:   AtomicAccess::store(addr, val + 1);
> 
> Suggestion:
> 
>   AtomicAccess::inc(addr);

Same here.

> src/hotspot/share/classfile/javaClasses.cpp line 1764:
> 
>> 1762:   jint* addr = java_thread->field_addr(_VTMS_transition_disable_count_offset);
>> 1763:   int val = AtomicAccess::load(addr);
>> 1764:   AtomicAccess::store(addr, val - 1);
> 
> Suggestion:
> 
>   AtomicAccess::dec(addr);

I?d prefer to leave it as a plain store to avoid the unnecessary extra fence.

> src/hotspot/share/opto/runtime.hpp line 740:
> 
>> 738:     return vthread_transition_Type();
>> 739:   }
>> 740: 
> 
> I do not know C2 but this looks really strange - 4 different functions all return the same thing. ???

We need to define them because the `GEN_C2_STUB` macro will look for the type of the C function based on its name (`C2_STUB_TYPEFUNC(name)`), otherwise we get a compilation failure. The four C functions have the same type though so they all return `_vthread_transition_Type`.

> src/hotspot/share/runtime/handshake.cpp line 374:
> 
>> 372:     JavaThread* target = java_lang_Thread::thread(carrier_thread);
>> 373:     assert(target != nullptr, "");
>> 374:     // Technically there is need for a ThreadsListHandle since the target
> 
> Suggestion:
> 
>     // Technically there is no need for a ThreadsListHandle since the target
> 
> ?

Yes, fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2561198741
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2561198549
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2561200538
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2561202212

From pchilanomate at openjdk.org  Tue Nov 25 19:58:34 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 25 Nov 2025 19:58:34 GMT
Subject: jmx-dev RFR: 8364343: Virtual Thread transition management
 needs to be independent of JVM TI [v5]
In-Reply-To: 
References: 
Message-ID: <8QdmTglMpQwGWG0QeQLbeduPrF1qZkah-9RzQwSOQuY=.fa030def-7674-48e3-bc25-23358009ed87@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:

  David's comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28361/files
  - new: https://git.openjdk.org/jdk/pull/28361/files/10534b33..b54594c4

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

  Stats: 46 lines in 4 files changed: 18 ins; 1 del; 27 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 Nov 25 19:58:43 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 25 Nov 2025 19:58:43 GMT
Subject: jmx-dev RFR: 8364343: Virtual Thread transition management
 needs to be independent of JVM TI [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 20 Nov 2025 22:26:26 GMT, David Holmes  wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   David's comments
>
> src/hotspot/share/prims/jvm.cpp line 3668:
> 
>> 3666:   if (!DoJVMTIVirtualThreadTransitions) {
>> 3667:     assert(!JvmtiExport::can_support_virtual_threads(), "sanity check");
>> 3668:     return;
> 
> Does this not still need checking somewhere?

The check for `DoJVMTIVirtualThreadTransitions` was moved to the `JVMTIStartTransition\JVMTIEndTransition` classes, but I guess you refer to the assert: I missed to move it. Added now too.

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

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

From pchilanomate at openjdk.org  Tue Nov 25 19:58:45 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 25 Nov 2025 19:58:45 GMT
Subject: jmx-dev RFR: 8364343: Virtual Thread transition management
 needs to be independent of JVM TI [v3]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Sat, 22 Nov 2025 08:37:39 GMT, Serguei Spitsyn  wrote:

>> src/hotspot/share/runtime/mountUnmountDisabler.cpp line 147:
>> 
>>> 145:       MonitorLocker ml(VTMSTransition_lock);
>>> 146:       while (is_start_transition_disabled(current, vth())) {
>>> 147:         ml.wait(200);
>> 
>> I see a lot of timed-waits throughout this code. Is that because we poll rather than synchronizing properly? All this potential busy-waiting is surely going to cause performance glitches.
>
> The timeouts are for reliability purposes only. Technically, they are not needed and can be removed after this code becomes stable. The `wait()` calls are inside while loop which rechecks the loop-ending conditions.

I tried to minimize the changes with respect to the current code so I kept the timed-waits. As Serguei points out we should be able to remove this particular one. As for the ones executed by the disablers, we could make them poll for the transition bits in a loop with backoff, similar to how we do it in safepoint and handshake cases. But I agree with Serguei we should do it in a separate bug once the code is stable.

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

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

From pchilanomate at openjdk.org  Tue Nov 25 19:58:47 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 25 Nov 2025 19:58:47 GMT
Subject: jmx-dev RFR: 8364343: Virtual Thread transition management
 needs to be independent of JVM TI [v4]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Fri, 21 Nov 2025 01:01:48 GMT, David Holmes  wrote:

>> src/hotspot/share/runtime/mountUnmountDisabler.cpp line 162:
>> 
>>> 160:   // be executed once we go back to Java. If this is an unmount, the handshake that the
>>> 161:   // disabler executed against this carrier thread already provided the needed synchronization.
>>> 162:   // This matches the release fence in xx_enable_for_one()/xx_enable_for_all().
>> 
>> Subtle. Do we have comments where the fences are to ensure people realize the fence is serving this purpose?
>
> I also forgot to suggest a wording change: say "pairs with" rather than "matches". Reading back through I realize now I have misunderstood many of these comments.

Changed to `pairs with`. I rewrote the comments so hopefully?they are more clear now. I also added a comment in `VirtualThread.mount/unmount` where the memory barriers should be.

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

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

From pchilanomate at openjdk.org  Tue Nov 25 19:58:53 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 25 Nov 2025 19:58:53 GMT
Subject: jmx-dev RFR: 8364343: Virtual Thread transition management
 needs to be independent of JVM TI [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 21 Nov 2025 00:42:32 GMT, David Holmes  wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename VM methods for endFirstTransition/startFinalTransition
>
> src/hotspot/share/runtime/mountUnmountDisabler.cpp line 277:
> 
>> 275: 
>> 276:   // Start of the critical region. Prevent future memory
>> 277:   // operations to be ordered before we read the transition flag.
> 
> Does this refer to `java_lang_Thread::is_in_VTMS_transition(_vthread())`? If so perhaps that should internally perform the `load_acquire`?

Yes, but that would also call for doing the same with `JavaThread::_is_in_VTMS_transition` for the `VTMS_transition_disable_for_all` case, and also have the pairing release stores by the virtual thread in `end_transition` on those same addresses, otherwise it would be confusing. And same with the other side, i.e doing load_acquire by the virtual thread of `_VTMS_transition_disable_count` and `_global_start_transition_disable_count` on `start_transition` and release store by the disabler when enabling transitions again. But I wanted to avoid unnecessary barriers in the virtual thread transition side, so I kept them as plain load/stores with separate memory barriers when necessary.

> src/hotspot/share/runtime/mountUnmountDisabler.cpp line 307:
> 
>> 305:   // Block while some mount/unmount transitions are in progress.
>> 306:   // Debug version fails and prints diagnostic information.
>> 307:   for (JavaThreadIteratorWithHandle jtiwh; JavaThread *jt = jtiwh.next(); ) {
> 
> This looks very odd, having an assignment in the loop condition check and no actual loop-update expression.

Yes, from what I see this same construct is used in many places. Seems this is valid because a pointer used in a boolean context evaluates to false if nullptr and true if non-null. :)

> src/hotspot/share/runtime/mountUnmountDisabler.cpp line 316:
> 
>> 314:   // operations to be ordered before we read the transition flags.
>> 315:   // This matches the release fence in end_transition().
>> 316:   OrderAccess::acquire();
> 
> Surely the use of the iterator already provides the necessary ordering guarantee here as well. ?

We still need it because we need to prevent reordering of loads from the critical section with loads of `jt->is_in_VTMS_transition()`.

> src/hotspot/share/runtime/mountUnmountDisabler.cpp line 327:
> 
>> 325:   // End of the critical section. Prevent previous memory operations to
>> 326:   // be ordered after we clear the clear the disable transition flag.
>> 327:   // This matches the equivalent acquire fence in start_transition().
> 
> Suggestion:
> 
>   // This pairs with the acquire in start_transition().
> 
> I just realized you are using "fence" to describe release and acquire memory barrier semantics. Given we have an operation `fence` I find this confusing for the reader - especially when we also have a `release_store_fence` operation which might be confused with "release fence".

Right, I changed it now to use the terms acquire and release barrier respectively.

> src/hotspot/share/runtime/mountUnmountDisabler.cpp line 370:
> 
>> 368:   assert(VTMSTransition_lock->owned_by_self() || SafepointSynchronize::is_at_safepoint(), "Must be locked");
>> 369:   assert(_global_start_transition_disable_count >= 0, "");
>> 370:   AtomicAccess::store(&_global_start_transition_disable_count, _global_start_transition_disable_count + 1);
> 
> Suggestion:
> 
>   AtomicAccess::inc(&_global_start_transition_disable_count);

I?d prefer to leave it as a plain store to avoid the unnecessary extra fence.

> src/hotspot/share/runtime/mountUnmountDisabler.cpp line 376:
> 
>> 374:   assert(VTMSTransition_lock->owned_by_self() || SafepointSynchronize::is_at_safepoint(), "Must be locked");
>> 375:   assert(_global_start_transition_disable_count > 0, "");
>> 376:   AtomicAccess::store(&_global_start_transition_disable_count, _global_start_transition_disable_count - 1);
> 
> Suggestion:
> 
>   AtomicAccess::dec(&_global_start_transition_disable_count);

Same here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2561208616
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2561210899
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2561216984
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2561219344
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2561219842
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2561220292

From pchilanomate at openjdk.org  Tue Nov 25 19:59:38 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 25 Nov 2025 19:59:38 GMT
Subject: jmx-dev RFR: 8364343: Virtual Thread transition management
 needs to be independent of JVM TI [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 21 Nov 2025 01:23:17 GMT, David Holmes  wrote:

> > we follow the classic Dekker pattern for the required synchronization.
> 
> My understanding is that Dekker requires a "full fence" between the accesses, not just ordering memory barriers. The two variables involved must be published to all readers for the algorithm to work.
>
No need to argue too much about this one because `StoreLoad` is implemented as a full fence so we can easily change it, but from reading the definitions in `OrderAccess` my understanding was that technically it should be enough. The `StoreStore` comment clarifies the meaning of word `completes` (used later in `StoreLoad`) as `the effect on memory of Store1 is made visible to other processors`.

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

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

From pchilanomate at openjdk.org  Tue Nov 25 20:10:56 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 25 Nov 2025 20:10:56 GMT
Subject: jmx-dev RFR: 8364343: Virtual Thread transition management
 needs to be independent of JVM TI [v6]
In-Reply-To: 
References: 
Message-ID: 

> 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:

  Remove INCLUDE_JVMTI macro

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28361/files
  - new: https://git.openjdk.org/jdk/pull/28361/files/b54594c4..4c598ad4

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

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 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 Nov 25 20:11:00 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 25 Nov 2025 20:11:00 GMT
Subject: jmx-dev RFR: 8364343: Virtual Thread transition management
 needs to be independent of JVM TI [v4]
In-Reply-To: <6WDKeD8iQTXDPhR0ohPvA6KVufW0uXHBmyZ5oOWfYWI=.44d63e7f-fbdb-47b6-8b36-f0d0cb35fb91@github.com>
References: 
 
 <6WDKeD8iQTXDPhR0ohPvA6KVufW0uXHBmyZ5oOWfYWI=.44d63e7f-fbdb-47b6-8b36-f0d0cb35fb91@github.com>
Message-ID: 

On Sat, 22 Nov 2025 07:52:40 GMT, Serguei Spitsyn  wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename VM methods for endFirstTransition/startFinalTransition
>
> src/hotspot/share/runtime/javaThread.cpp line 1173:
> 
>> 1171: bool JavaThread::java_suspend(bool register_vthread_SR) {
>> 1172: #if INCLUDE_JVMTI
>> 1173:   // Suspending a JavaThread in VTMS transition or disabling VTMS transitions can cause deadlocks.
> 
> Q: I wonder if the `#if INCLUDE_JVMTI` and `#endif` can be removed here.

Yes, removed.

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

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

From pchilanomate at openjdk.org  Tue Nov 25 20:11:03 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 25 Nov 2025 20:11:03 GMT
Subject: jmx-dev RFR: 8364343: Virtual Thread transition management
 needs to be independent of JVM TI [v4]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Sat, 22 Nov 2025 08:22:34 GMT, Serguei Spitsyn  wrote:

>> src/hotspot/share/runtime/mountUnmountDisabler.hpp line 52:
>> 
>>> 50:   // parameter is_SR: suspender or resumer
>>> 51:   MountUnmountDisabler(bool exlusive = false);
>>> 52:   MountUnmountDisabler(oop thread_oop);
>> 
>> What does the comment mean here?
>
> This comment is stale now and must be removed. The parameter `is_SR` is being replaced with the `exclusive`.

Right, removed.

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

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

From pchilanomate at openjdk.org  Tue Nov 25 22:59:59 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 25 Nov 2025 22:59:59 GMT
Subject: jmx-dev RFR: 8364343: Virtual Thread transition management
 needs to be independent of JVM TI [v7]
In-Reply-To: 
References: 
Message-ID: 

> 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:

  keep preexisting rebind order for mount

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28361/files
  - new: https://git.openjdk.org/jdk/pull/28361/files/4c598ad4..dee2b843

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

  Stats: 3 lines in 1 file changed: 2 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 coleenp at openjdk.org  Wed Nov 26 00:01:00 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 26 Nov 2025 00:01:00 GMT
Subject: jmx-dev RFR: 8364343: Virtual Thread transition management
 needs to be independent of JVM TI [v7]
In-Reply-To: 
References: 
 
Message-ID: <0e65HV5RscFZN_q4JGzXA7k5jlT7gw7klerMqbfz4GU=.598cedb2-fd53-458b-9047-4d712661cbe4@github.com>

On Tue, 25 Nov 2025 22:59:59 GMT, Patricio Chilano Mateo  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:
> 
>   keep preexisting rebind order for mount

First read through, mostly questions and plea for comments.    This is a nice refactoring and cleanup of some very difficult code.  You don't have to do the renaming that I requested now if you don't want to.

src/hotspot/share/classfile/javaClasses.cpp line 1688:

> 1686: int java_lang_Thread::_jvmti_thread_state_offset;
> 1687: int java_lang_Thread::_VTMS_transition_disable_count_offset;
> 1688: int java_lang_Thread::_is_in_VTMS_transition_offset;

Since you're renaming these anyway, can we drop the VTMS part?  Just call it vthread_transition_disable_count_offset and is_in_vthread_transition_offset?  There are other VTMS named things that aren't these flags but they can stay.  Maybe migrate other names at some future point.

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

> 3044: }
> 3045: 
> 3046: bool LibraryCallKit::inline_native_vthread_start_transition(address funcAddr, const char* funcName, bool is_final_transition) {

Would it be helpful to add a comment above this to say what this does? This is supposed to match some non-intrinsic code and might be helpful if you referenced that here.

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?

src/hotspot/share/prims/jvmtiEnv.cpp line 1827:

> 1825: JvmtiEnv::ClearAllFramePops(jthread thread) {
> 1826:   ResourceMark rm;
> 1827:   MountUnmountDisabler disabler(thread);

Not for this change but I thought JVMTI had some xml code that generated prefixes for these functions.  This seems like something that could be unified somewhere tbd.

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?

src/hotspot/share/runtime/javaThread.cpp line 1152:

> 1150: bool JavaThread::is_in_VTMS_transition() const {
> 1151:   return AtomicAccess::load(&_is_in_VTMS_transition);
> 1152: }

Is the JavaThread version always the same as the java_lang_Thread::is_in_VTMS_transition(threadOop()) value?

src/hotspot/share/runtime/mountUnmountDisabler.hpp line 34:

> 32: 
> 33: class MountUnmountDisabler : public AnyObj {
> 34:   static volatile int _global_start_transition_disable_count;

Can you describe this variable - when is it set and why is there a global disabler? What does it mean to have 'n' active disablers?

A comment at the beginning of MountUnmountDisabler to say something of the effect that during virtual thread mounting and unmounting, JVMTI and operations that need to examine thread state need to be disabled.  Or is it the converse?  During JVMTI and operations that examine the state of threads, virtual thread mounting and unmounting must wait until these operations are complete.  This class is for the latter right?

src/hotspot/share/runtime/mutexLocker.cpp line 52:

> 50: Mutex*   JvmtiThreadState_lock        = nullptr;
> 51: Monitor* EscapeBarrier_lock           = nullptr;
> 52: Monitor* VTMSTransition_lock          = nullptr;

oh you could drop the name VTMS and call it VThreadTransitionLock can't you?

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

PR Review: https://git.openjdk.org/jdk/pull/28361#pullrequestreview-3507302896
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2561864174
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2561876549
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2561897865
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2561904709
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2561910057
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2561926510
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2561943253
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2561945493

From coleenp at openjdk.org  Wed Nov 26 00:01:01 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 26 Nov 2025 00:01:01 GMT
Subject: jmx-dev RFR: 8364343: Virtual Thread transition management
 needs to be independent of JVM TI [v7]
In-Reply-To: <0e65HV5RscFZN_q4JGzXA7k5jlT7gw7klerMqbfz4GU=.598cedb2-fd53-458b-9047-4d712661cbe4@github.com>
References: 
 
 <0e65HV5RscFZN_q4JGzXA7k5jlT7gw7klerMqbfz4GU=.598cedb2-fd53-458b-9047-4d712661cbe4@github.com>
Message-ID: 

On Tue, 25 Nov 2025 23:32:40 GMT, Coleen Phillimore  wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   keep preexisting rebind order for mount
>
> src/hotspot/share/runtime/javaThread.cpp line 1152:
> 
>> 1150: bool JavaThread::is_in_VTMS_transition() const {
>> 1151:   return AtomicAccess::load(&_is_in_VTMS_transition);
>> 1152: }
> 
> Is the JavaThread version always the same as the java_lang_Thread::is_in_VTMS_transition(threadOop()) value?

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).

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

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

From coleenp at openjdk.org  Wed Nov 26 00:01:03 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 26 Nov 2025 00:01:03 GMT
Subject: jmx-dev RFR: 8364343: Virtual Thread transition management
 needs to be independent of JVM TI [v4]
In-Reply-To: <6WDKeD8iQTXDPhR0ohPvA6KVufW0uXHBmyZ5oOWfYWI=.44d63e7f-fbdb-47b6-8b36-f0d0cb35fb91@github.com>
References: 
 
 <6WDKeD8iQTXDPhR0ohPvA6KVufW0uXHBmyZ5oOWfYWI=.44d63e7f-fbdb-47b6-8b36-f0d0cb35fb91@github.com>
Message-ID: 

On Sat, 22 Nov 2025 08:43:07 GMT, Serguei Spitsyn  wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename VM methods for endFirstTransition/startFinalTransition
>
> 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.

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

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

From coleenp at openjdk.org  Wed Nov 26 00:01:06 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 26 Nov 2025 00:01:06 GMT
Subject: jmx-dev RFR: 8364343: Virtual Thread transition management
 needs to be independent of JVM TI [v4]
In-Reply-To: 
References: 
 
 
 
Message-ID: <6kxaoFZTU2CYGKZpONDliyxGikpxbLMaxUtuqENnlq4=.4e48b44a-522f-4568-b4da-96b0184e5afc@github.com>

On Tue, 25 Nov 2025 19:50:06 GMT, Patricio Chilano Mateo  wrote:

>> src/hotspot/share/runtime/mountUnmountDisabler.cpp line 307:
>> 
>>> 305:   // Block while some mount/unmount transitions are in progress.
>>> 306:   // Debug version fails and prints diagnostic information.
>>> 307:   for (JavaThreadIteratorWithHandle jtiwh; JavaThread *jt = jtiwh.next(); ) {
>> 
>> This looks very odd, having an assignment in the loop condition check and no actual loop-update expression.
>
> Yes, from what I see this same construct is used in many places. Seems this is valid because a pointer used in a boolean context evaluates to false if nullptr and true if non-null. :)

This could be a simple cleanup of all these occurrences later.

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

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

From dholmes at openjdk.org  Wed Nov 26 07:32:52 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 26 Nov 2025 07:32:52 GMT
Subject: jmx-dev RFR: 8364343: Virtual Thread transition management
 needs to be independent of JVM TI [v3]
In-Reply-To: <-MtOiSQVDvlQD7sbfeBiqF00_ZN9_aNt3zd2LZLljyo=.eeabb717-359d-4420-89aa-ed1b305beee5@github.com>
References: 
 
 
 <-MtOiSQVDvlQD7sbfeBiqF00_ZN9_aNt3zd2LZLljyo=.eeabb717-359d-4420-89aa-ed1b305beee5@github.com>
Message-ID: 

On Tue, 25 Nov 2025 19:45:08 GMT, Patricio Chilano Mateo  wrote:

>> src/hotspot/share/classfile/javaClasses.cpp line 1764:
>> 
>>> 1762:   jint* addr = java_thread->field_addr(_VTMS_transition_disable_count_offset);
>>> 1763:   int val = AtomicAccess::load(addr);
>>> 1764:   AtomicAccess::store(addr, val - 1);
>> 
>> Suggestion:
>> 
>>   AtomicAccess::dec(addr);
>
> I?d prefer to leave it as a plain store to avoid the unnecessary extra fence.

But it isn't then an atomic update.

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

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

From dholmes at openjdk.org  Wed Nov 26 07:35:49 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 26 Nov 2025 07:35:49 GMT
Subject: jmx-dev RFR: 8364343: Virtual Thread transition management
 needs to be independent of JVM TI [v4]
In-Reply-To: <6kxaoFZTU2CYGKZpONDliyxGikpxbLMaxUtuqENnlq4=.4e48b44a-522f-4568-b4da-96b0184e5afc@github.com>
References: 
 
 
 
 <6kxaoFZTU2CYGKZpONDliyxGikpxbLMaxUtuqENnlq4=.4e48b44a-522f-4568-b4da-96b0184e5afc@github.com>
Message-ID: 

On Tue, 25 Nov 2025 23:53:40 GMT, Coleen Phillimore  wrote:

>> Yes, from what I see this same construct is used in many places. Seems this is valid because a pointer used in a boolean context evaluates to false if nullptr and true if non-null. :)
>
> 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.

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

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

From kevinw at openjdk.org  Wed Nov 26 12:04:49 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 26 Nov 2025 12:04:49 GMT
Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache
 creation [v8]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Tue, 25 Nov 2025 12:22:21 GMT, Alan Bateman  wrote:

>> src/jdk.management/share/classes/com/sun/management/internal/PlatformMBeanProviderImpl.java line 192:
>> 
>>> 190:                 HotSpotAOTCacheMXBean impl = this.impl;
>>> 191:                 if (impl == null) {
>>> 192:                     this.impl = impl = new HotSpotAOTCacheImpl(ManagementFactoryHelper.getVMManagement());
>> 
>> This assignment is unusual.  Are we trying to avoid a synchronized block? Other nameToMBeanMap() methods are like:
>> 	return Collections.singletonMap(ManagementFactory.MEMORY_MXBEAN_NAME, ManagementFactoryHelper.getMemoryMXBean());
>> 	
>> ..where the ManagementFactoryHelper.getMemoryMXBean() method is synchronized and creates the impl if needed.
>
> I don't see a correctly issue with this. Maybe in the future we will be able to use LazyConstant here.

Sure, I'm just pointing out that we have a load of existing nameToMBeanMap() methods that do things differently.
OK I now see this one is doing what the new VirtualThreadSchedulerMXBean did.

The others are different: commonly the nameToMBeanMap() methods in PlatformMBeanProviderImpl.java are synchronized, or they call a getXXMXBean() method which is synchronized.

Maybe these old methods don't need to be synchronized, if this all gets done at startup in PlatformMBeanProviderImpl init(), the mbeans will always be created once.

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

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

From alanb at openjdk.org  Wed Nov 26 12:25:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 26 Nov 2025 12:25:53 GMT
Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache
 creation [v8]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Wed, 26 Nov 2025 12:01:40 GMT, Kevin Walls  wrote:

>> I don't see a correctness issue with this. Maybe in the future we will be able to use LazyConstant here.
>
> Sure, I'm just pointing out that we have a load of existing nameToMBeanMap() methods that do things differently.
> OK I now see this one is doing what the new VirtualThreadSchedulerMXBean did.
> 
> The others are different: commonly the nameToMBeanMap() methods in PlatformMBeanProviderImpl.java are synchronized, or they call a getXXMXBean() method which is synchronized.
> 
> Maybe these old methods don't need to be synchronized, if this all gets done at startup in PlatformMBeanProviderImpl init(), the mbeans will always be created once.

The older code pre-dates unmodifiable maps (JEP 269), it could be modernized some time.

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

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

From kevinw at openjdk.org  Wed Nov 26 12:54:50 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 26 Nov 2025 12:54:50 GMT
Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache
 creation [v8]
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: <9nPLu2Fgp-9WizodN4foJP6NA0IvpQGyghqUI-LlzYI=.6560feb6-3c80-4e87-9e85-8c66de78df02@github.com>

On Wed, 26 Nov 2025 12:23:26 GMT, Alan Bateman  wrote:

>> Sure, I'm just pointing out that we have a load of existing nameToMBeanMap() methods that do things differently.
>> OK I now see this one is doing what the new VirtualThreadSchedulerMXBean did.
>> 
>> The others are different: commonly the nameToMBeanMap() methods in PlatformMBeanProviderImpl.java are synchronized, or they call a getXXMXBean() method which is synchronized.
>> 
>> Maybe these old methods don't need to be synchronized, if this all gets done at startup in PlatformMBeanProviderImpl init(), the mbeans will always be created once.
>
> The older code pre-dates unmodifiable maps (JEP 269), it could be modernized some time.

Thanks yes would be good to do that some time.
It looks like an effort with the older accesors to enforce that they are singletons.  That may not be important for all the mxbeans.

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

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

From macarte at openjdk.org  Wed Nov 26 16:26:04 2025
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 26 Nov 2025 16:26:04 GMT
Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache
 creation [v9]
In-Reply-To: 
References: 
Message-ID: 

> 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 with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - Merge branch 'master' into JDK-8369736
 - Remove single whitespace
 - Incorporate changes from the CSR
 - Revert "Adding test to validate using DiagnosticCommand MBean to invoke AOT.end_recording"
   Commit was intended for parent branch (that this branch is based on)
   
   This reverts commit bff7cb7408554232c13a57bba10b67a9fd19b811.
 - Adding test to validate using DiagnosticCommand MBean to invoke AOT.end_recording
 - Updated test based on comments
 - Merge branch 'JDK-8369736' of https://github.com/macarte/jdk into JDK-8369736
 - Update src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java
   
   Co-authored-by: Dan Heidinga 
 - Update src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java
   
   Co-authored-by: Dan Heidinga 
 - Wording and format changes
 - ... and 5 more: https://git.openjdk.org/jdk/compare/c028369d...a12bfa03

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

Changes: https://git.openjdk.org/jdk/pull/28010/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28010&range=08
  Stats: 433 lines in 11 files changed: 338 ins; 0 del; 95 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 Nov 26 20:30:12 2025
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 26 Nov 2025 20:30:12 GMT
Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache
 creation [v10]
In-Reply-To: 
References: 
Message-ID: <4yg-7y-d9fzKeFZwZm1KNF6xn2tXGk8y8QaUCk6ly0w=.d0a6ba6b-81a6-482c-9af6-fe3584f2de1d@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 changes to aotMetaspace from dependent commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28010/files
  - new: https://git.openjdk.org/jdk/pull/28010/files/a12bfa03..576418a6

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

  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 macarte at openjdk.org  Wed Nov 26 20:35:11 2025
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 26 Nov 2025 20:35:11 GMT
Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache
 creation [v11]
In-Reply-To: 
References: 
Message-ID: 

> 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

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

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

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

  Stats: 93 lines in 2 files changed: 0 ins; 0 del; 93 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 pchilanomate at openjdk.org  Wed Nov 26 22:34:37 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 26 Nov 2025 22:34:37 GMT
Subject: jmx-dev RFR: 8364343: Virtual Thread transition management
 needs to be independent of JVM TI [v8]
In-Reply-To: 
References: 
Message-ID: 

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

 - More changes from Coleen's review
 - Drop VTMS from names

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28361/files
  - new: https://git.openjdk.org/jdk/pull/28361/files/dee2b843..623bc518

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

  Stats: 203 lines in 16 files changed: 41 ins; 0 del; 162 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  Wed Nov 26 22:44:17 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 26 Nov 2025 22:44:17 GMT
Subject: jmx-dev RFR: 8364343: Virtual Thread transition management
 needs to be independent of JVM TI [v9]
In-Reply-To: 
References: 
Message-ID: 

> 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:

  missing to initialize _is_disabler_at_start

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

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

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

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 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  Wed Nov 26 22:44:18 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 26 Nov 2025 22:44:18 GMT
Subject: jmx-dev RFR: 8364343: Virtual Thread transition management
 needs to be independent of JVM TI [v3]
In-Reply-To: 
References: 
 
 
 <-MtOiSQVDvlQD7sbfeBiqF00_ZN9_aNt3zd2LZLljyo=.eeabb717-359d-4420-89aa-ed1b305beee5@github.com>
 
Message-ID: 

On Wed, 26 Nov 2025 07:29:37 GMT, David Holmes  wrote:

>> I?d prefer to leave it as a plain store to avoid the unnecessary extra fence.
>
> But it isn't then an atomic update.

Only the disablers write to this counter while holding `VThreadTransition_lock` (verified in the assert above). But we still need to use `AtomicAccess` for the store because it can be concurrently read by the virtual thread.

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

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

From pchilanomate at openjdk.org  Wed Nov 26 22:51:55 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 26 Nov 2025 22:51:55 GMT
Subject: jmx-dev RFR: 8364343: Virtual Thread transition management
 needs to be independent of JVM TI [v7]
In-Reply-To: <0e65HV5RscFZN_q4JGzXA7k5jlT7gw7klerMqbfz4GU=.598cedb2-fd53-458b-9047-4d712661cbe4@github.com>
References: 
 
 <0e65HV5RscFZN_q4JGzXA7k5jlT7gw7klerMqbfz4GU=.598cedb2-fd53-458b-9047-4d712661cbe4@github.com>
Message-ID: 

On Tue, 25 Nov 2025 23:10:43 GMT, Coleen Phillimore  wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   keep preexisting rebind order for mount
>
> src/hotspot/share/classfile/javaClasses.cpp line 1688:
> 
>> 1686: int java_lang_Thread::_jvmti_thread_state_offset;
>> 1687: int java_lang_Thread::_VTMS_transition_disable_count_offset;
>> 1688: int java_lang_Thread::_is_in_VTMS_transition_offset;
> 
> Since you're renaming these anyway, can we drop the VTMS part?  Just call it vthread_transition_disable_count_offset and is_in_vthread_transition_offset?  There are other VTMS named things that aren't these flags but they can stay.  Maybe migrate other names at some future point.

I dropped VTMS from all names.

> src/hotspot/share/opto/library_call.cpp line 3046:
> 
>> 3044: }
>> 3045: 
>> 3046: bool LibraryCallKit::inline_native_vthread_start_transition(address funcAddr, const char* funcName, bool is_final_transition) {
> 
> Would it be helpful to add a comment above this to say what this does? This is supposed to match some non-intrinsic code and might be helpful if you referenced that here.

Added a comment.

> 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.

> src/hotspot/share/runtime/mountUnmountDisabler.hpp line 34:
> 
>> 32: 
>> 33: class MountUnmountDisabler : public AnyObj {
>> 34:   static volatile int _global_start_transition_disable_count;
> 
> Can you describe this variable - when is it set and why is there a global disabler? What does it mean to have 'n' active disablers?
> 
> A comment at the beginning of MountUnmountDisabler to say something of the effect that during virtual thread mounting and unmounting, JVMTI and operations that need to examine thread state need to be disabled.  Or is it the converse?  During JVMTI and operations that examine the state of threads, virtual thread mounting and unmounting must wait until these operations are complete.  This class is for the latter right?

Added a comment for the class and this counter.

> src/hotspot/share/runtime/mutexLocker.cpp line 52:
> 
>> 50: Mutex*   JvmtiThreadState_lock        = nullptr;
>> 51: Monitor* EscapeBarrier_lock           = nullptr;
>> 52: Monitor* VTMSTransition_lock          = nullptr;
> 
> oh you could drop the name VTMS and call it VThreadTransitionLock can't you?

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2566661560
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2566662105
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2566663466
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2566666104
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2566666238

From pchilanomate at openjdk.org  Wed Nov 26 22:51:58 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 26 Nov 2025 22:51:58 GMT
Subject: jmx-dev RFR: 8364343: Virtual Thread transition management
 needs to be independent of JVM TI [v9]
In-Reply-To: <0e65HV5RscFZN_q4JGzXA7k5jlT7gw7klerMqbfz4GU=.598cedb2-fd53-458b-9047-4d712661cbe4@github.com>
References: 
 
 <0e65HV5RscFZN_q4JGzXA7k5jlT7gw7klerMqbfz4GU=.598cedb2-fd53-458b-9047-4d712661cbe4@github.com>
Message-ID: <9R5lVpD1GBtUw9g9Bc5X7wSEI2a-oFM2Q29HUmyqSmc=.5fb087cf-4305-4bf1-b730-8a3bda7fbe9a@github.com>

On Tue, 25 Nov 2025 23:27:47 GMT, Coleen Phillimore  wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   missing to initialize _is_disabler_at_start
>
> 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.

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

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

From pchilanomate at openjdk.org  Wed Nov 26 22:51:59 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 26 Nov 2025 22:51:59 GMT
Subject: jmx-dev RFR: 8364343: Virtual Thread transition management
 needs to be independent of JVM TI [v7]
In-Reply-To: 
References: 
 
 <0e65HV5RscFZN_q4JGzXA7k5jlT7gw7klerMqbfz4GU=.598cedb2-fd53-458b-9047-4d712661cbe4@github.com>
 
Message-ID: 

On Tue, 25 Nov 2025 23:45:14 GMT, Coleen Phillimore  wrote:

>> src/hotspot/share/runtime/javaThread.cpp line 1152:
>> 
>>> 1150: bool JavaThread::is_in_VTMS_transition() const {
>>> 1151:   return AtomicAccess::load(&_is_in_VTMS_transition);
>>> 1152: }
>> 
>> Is the JavaThread version always the same as the java_lang_Thread::is_in_VTMS_transition(threadOop()) value?
>
> 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.

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

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