On Wed, 29 Oct 2025 21:07:51 GMT, Mat Carter <[email protected]> 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
