On Thu, 23 Oct 2025 23:57:21 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:
>
> - Error! Not a recording run
> - Error! Not recording
> - Recording ended successfully
> - Error! Failed to end recording
>
> 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
> - Error! Not recording
>
> Passes tier1 on linux (x64) and windows (x64)
src/hotspot/share/cds/aotMetaspace.cpp line 963:
> 961: bool AOTMetaspace::is_recording_preimage_static_archive() {
> 962: if (CDSConfig::is_dumping_preimage_static_archive()) {
> 963: return _preimage_static_archive_dumped == 0;
Do we need to use an acquiring load here? i.e. can the read here and the
cmpxchg below happen in different threads?
n.b. I'm not just thinking about the behaviour when this patch makes the DCmd
available but also what happens when we supplement it with the MXBean interface
to end recordings.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2468726557
