RFR: 8369736 - Add management interface for AOT cache creation [v4]
Alan Bateman
alanb at openjdk.org
Mon Nov 3 11:05:05 UTC 2025
On Wed, 29 Oct 2025 21:07:51 GMT, Mat Carter <macarte at openjdk.org> 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
src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 104:
> 102: * </pre></blockquote>
> 103: *
> 104: * @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.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2486085650
More information about the serviceability-dev
mailing list