On Tue, 25 Nov 2025 01:01:19 GMT, Mat Carter <[email protected]> wrote:
>> Add jcmd AOT.end_recording diagnostic command. When this command is issued, >> a targeted JVM that is 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 command will report back to the user one of the following messages >> depending on the state of the JVM: >> >> - AOT.end_recording is unsupported when VM flags -XX:AOTMode=record or >> -XX:AOTCacheOutput=<file> are missing >> - Recording has already ended. >> - Error: Failed to end recording. >> - Recording ended successfully. >> >> It follows that issues the command to a JVM that is recording, twice in >> succession, should (baring internal errors) would produce the following two >> responses: >> >> - Recording ended successfully. >> - Recording has already ended. >> >> Passes tier1 on linux (x64) and windows (x64) > > Mat Carter has updated the pull request incrementally with one additional > commit since the last revision: > > Check exit value in tests Looking good I think. A possible general issue is that the AOT implementation of the dumping may write mesages on tty-> but they are not captured by the jcmd. Not too much of an issue for a training run as presumably the app is being monitored by whoever asks for the endRecording() to happen. I think the plan for now would be: should the jcmd fail, you check the app output for possibly more detail. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27965#issuecomment-3575650962
