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
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
