8370203 - Add jcmd AOT.end_recording diagnostic command

[macarte]

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)

---

Progress

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

Issues

• JDK-8370203: Add jcmd AOT.end_recording diagnostic command (Enhancement - P4)
• JDK-8370204: Add jcmd AOT.end_recording diagnostic command (CSR)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 27965

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

Using diff file

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

Using Webrev

Link to Webrev Comment

[bridgekeeper]

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

[openjdk]

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

[openjdk]

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

• hotspot-runtime
• 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]

Webrevs

• 00: Full (2f09c157)

[adinn]

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.

[macarte]

I think it's okay, as ending the recording is controlled by the cmpxchg, even if two threads think the recording is still going on, only one call to end the recording will work, and if the threads both check whether the recording has completed they will both see that it has (regardless of which thread 'won')

[AlanBateman]

Is there an error recorded or anything further that could be included for the error case?

[macarte]

There is not, currently, the aotMetaspace method throws an exception if something goes wrong. I added this line in case the flow in aotMetaspace changes. The logic here is that if we asked the recording to stop, but it's still recording then we report to the user that 'we failed to stop the recording'