8369736 - Add management interface for AOT cache creation #28010

macarte · 2025-10-28T01:17:57Z

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)

Progress

Change must be properly reviewed (1 review required, with at least 1 Reviewer)
Change must not contain extraneous whitespace
Commit message must refer to an issue
Change requires CSR request JDK-8369737 to be approved

Issues

JDK-8369736: Add management interface for AOT cache creation (Enhancement - P3)
JDK-8369737: Add management interface for AOT cache creation (CSR)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/28010/head:pull/28010
$ git checkout pull/28010

Update a local copy of the PR:
$ git checkout pull/28010
$ git pull https://git.openjdk.org/jdk.git pull/28010/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 28010

View PR using the GUI difftool:
$ git pr show -t 28010

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/28010.diff

Using Webrev

Link to Webrev Comment

bridgekeeper · 2025-10-28T01:18:55Z

👋 Welcome back macarte! A progress list of the required criteria for merging this PR into pr/27965 will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2025-10-28T01:19:22Z

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

openjdk · 2025-10-28T01:20:19Z

@macarte The following labels will be automatically applied to this pull request:

hotspot
jmx
serviceability

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command.

mlbridge · 2025-10-28T01:26:34Z

Webrevs

src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java

test/hotspot/jtreg/runtime/cds/appcds/aotCache/HotSpotAOTCacheMXBeanTest.java

src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java

…eMXBean.java Co-authored-by: Dan Heidinga <[email protected]>

…-8369736

openjdk · 2025-10-29T18:47:59Z

⚠️ @macarte This pull request contains merges that bring in commits not present in the target repository. Since this is not a "merge style" pull request, these changes will be squashed when this pull request in integrated. If this is your intention, then please ignore this message. If you want to preserve the commit structure, you must change the title of this pull request to Merge <project>:<branch> where <project> is the name of another project in the OpenJDK organization (for example Merge jdk:master).

AlanBateman · 2025-11-03T11:01:23Z

src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java

+       * }
+       * </pre></blockquote>
+       *
+       * @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:

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.

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

egahlin · 2025-11-03T11:42:16Z

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.

macarte · 2025-11-03T20:06:05Z

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 its PR is here: #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

egahlin · 2025-11-04T13:26:59Z

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.

mbreinhold · 2025-11-05T21:48:41Z

src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java

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


Please don't use bare URLs. Change these to

... please refer to JEPs <a href="https://openjdk.org/jeps/483">483</a> and <a href="https://openjdk.org/jeps/514">514</a>.

…nd_recording

…ke AOT.end_recording" Commit was intended for parent branch (that this branch is based on) This reverts commit bff7cb7.

AlanBateman · 2025-11-21T11:32:10Z

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

AlanBateman · 2025-11-21T11:33:40Z

src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java

+   * @return {@code true} if a recording was in progress and has been ended
+   * successfully; {@code false} otherwise.
+   */
+   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.

AlanBateman · 2025-11-21T11:44:02Z

test/hotspot/jtreg/runtime/cds/appcds/aotCache/HotSpotAOTCacheMXBeanTest.java

+ * @summary Sanity test for HotSpotAOTCache MXBean
+ * @requires vm.cds.write.archived.java.heap
+ * @library /test/jdk/lib/testlibrary /test/lib
+ *          /test/hotspot/jtreg/runtime/cds/appcds/aotCache/test-classes


Is test-classes used?

AlanBateman · 2025-11-21T11:50:58Z

test/hotspot/jtreg/runtime/cds/appcds/aotCache/HotSpotAOTCacheMXBeanTest.java

+import jdk.test.lib.helpers.ClassFileInstaller;
+import jdk.test.lib.process.OutputAnalyzer;
+
+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.

AlanBateman · 2025-11-21T11:53:04Z

test/hotspot/jtreg/runtime/cds/appcds/aotCache/HotSpotAOTCacheMXBeanTest.java

+                    out.shouldContain("Failed to stop recording");
+                }
+                out.shouldNotContain("HotSpotAOTCacheMXBean is not available");
+                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.

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

kevinjwalls · 2025-11-25T12:10:02Z

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

+            public Map<String, HotSpotAOTCacheMXBean> nameToMBeanMap() {
+                HotSpotAOTCacheMXBean impl = this.impl;
+                if (impl == null) {
+                    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 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.

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.

openjdk-notifier · 2025-11-26T02:07:24Z

The parent pull request that this pull request depends on has now been integrated and the target branch of this pull request has been updated. This means that changes from the dependent pull request can start to show up as belonging to this pull request, which may be confusing for reviewers. To remedy this situation, simply merge the latest changes from the new target branch into this pull request by running commands similar to these in the local repository for your personal fork:

git checkout JDK-8369736
git fetch https://git.openjdk.org/jdk.git master
git merge FETCH_HEAD
# if there are conflicts, follow the instructions given by git merge
git commit -m "Merge master"
git push

openjdk · 2025-11-26T02:09:01Z

@macarte this pull request can not be integrated into master due to one or more merge conflicts. To resolve these merge conflicts and update this pull request you can run the following commands in the local repository for your personal fork:

git checkout JDK-8369736
git fetch https://git.openjdk.org/jdk.git master
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge master"
git push

macarte added 3 commits October 23, 2025 16:55

8370203 - Adding JCmd AOT.end_recording

39f4eb4

Sort headers correctly

efbfe5b

8369736 - Adding HotSpotAOTCache MXBean

ff1d9fe

Removed extra functionality

74537ff

openjdk bot added csr Pull request needs approved CSR before integration serviceability [email protected] jmx [email protected] hotspot [email protected] labels Oct 28, 2025

Removed whitespace

d58c514

openjdk bot added the rfr Pull request is ready for review label Oct 28, 2025

AlanBateman reviewed Oct 28, 2025

View reviewed changes

src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java Outdated Show resolved Hide resolved

AlanBateman reviewed Oct 28, 2025

View reviewed changes

DanHeidinga reviewed Oct 28, 2025

View reviewed changes

macarte and others added 4 commits October 28, 2025 11:55

Update src/jdk.management/share/classes/jdk/management/HotSpotAOTCach…

993f618

…eMXBean.java Co-authored-by: Dan Heidinga <[email protected]>

Update src/jdk.management/share/classes/jdk/management/HotSpotAOTCach…

2285a68

…eMXBean.java Co-authored-by: Dan Heidinga <[email protected]>

Wording and format changes

59ed2e0

Merge branch 'JDK-8369736' of https://github.com/macarte/jdk into JDK…

abd6b0d

…-8369736

Updated test based on comments

d48a200

AlanBateman reviewed Nov 3, 2025

View reviewed changes

mbreinhold suggested changes Nov 5, 2025

View reviewed changes

openjdk bot removed the csr Pull request needs approved CSR before integration label Nov 11, 2025

Adding test to validate using DiagnosticCommand MBean to invoke AOT.e…

bff7cb7

…nd_recording

macarte added 2 commits November 13, 2025 09:56

Revert "Adding test to validate using DiagnosticCommand MBean to invo…

6a10058

…ke AOT.end_recording" Commit was intended for parent branch (that this branch is based on) This reverts commit bff7cb7.

Incorporate changes from the CSR

b97a799

macarte requested a review from mbreinhold November 13, 2025 18:53

openjdk bot removed the rfr Pull request is ready for review label Nov 13, 2025

Remove single whitespace

f4a4af6

openjdk bot added the rfr Pull request is ready for review label Nov 13, 2025

AlanBateman reviewed Nov 21, 2025

View reviewed changes

kevinjwalls reviewed Nov 25, 2025

View reviewed changes

src/jdk.management/share/classes/com/sun/management/internal/HotSpotAOTCacheImpl.java Outdated Show resolved Hide resolved

kevinjwalls reviewed Nov 25, 2025

View reviewed changes

openjdk-notifier bot changed the base branch from pr/27965 to master November 26, 2025 02:07

openjdk bot added merge-conflict Pull request has merge conflict with target branch and removed rfr Pull request is ready for review labels Nov 26, 2025

Merge branch 'master' into JDK-8369736

a12bfa0

openjdk bot removed the merge-conflict Pull request has merge conflict with target branch label Nov 26, 2025

macarte added 2 commits November 26, 2025 12:25

Incorporate changes to aotMetaspace from dependent commit

576418a

Fixed spaces and CRLF

0086e0e

openjdk bot added the rfr Pull request is ready for review label Nov 26, 2025

8369736 - Add management interface for AOT cache creation #28010

Are you sure you want to change the base?

8369736 - Add management interface for AOT cache creation #28010

Conversation

macarte commented Oct 28, 2025 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Issues

Reviewing

Uh oh!

bridgekeeper bot commented Oct 28, 2025

Uh oh!

openjdk bot commented Oct 28, 2025

Uh oh!

openjdk bot commented Oct 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mlbridge bot commented Oct 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

openjdk bot commented Oct 29, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

egahlin commented Nov 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

macarte commented Nov 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

egahlin commented Nov 4, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AlanBateman commented Nov 21, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AlanBateman Nov 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

openjdk-notifier bot commented Nov 26, 2025

Uh oh!

openjdk bot commented Nov 26, 2025

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

7 participants

macarte commented Oct 28, 2025 •

edited by openjdk bot

Loading

openjdk bot commented Oct 28, 2025 •

edited

Loading

mlbridge bot commented Oct 28, 2025 •

edited

Loading

egahlin commented Nov 3, 2025 •

edited

Loading

macarte commented Nov 3, 2025 •

edited

Loading

AlanBateman Nov 25, 2025 •

edited

Loading