RFR: 8335358: [premain] Explore alternative ways to trigger the end of training run [v3]

[Mat Carter]

On Wed, 11 Sep 2024 22:24:53 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> AOT training can be ended using either
>> 
>> - -XX: AOTEndTrainingOnMethodEntry =Hello.someMethod [same syntax as CompileOnly]
>> - -XX: AOTEndTrainingOnMethodEntry =Hello.someMethod,Hello.someOtherMethod,count=42
>> - jcmd <pid> AOT.end_training
>> 
>> supports arm64 and x64
>> 
>> note: the AOTEndTrainingOnMethodEntry is ignored when CDSPreImage is specified; this is needed as the phase2 forked java process is passed all phase1 flags along with the -XX:CDSPreImage, but we don't want to run the trigger code in this phase (there may be a better way to handle this state or simply remove the flag from the forked process)
>> 
>> JBS Issue: https://bugs.openjdk.org/browse/JDK-8335358
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   another missing include that impacts some build configurations

src/hotspot/share/interpreter/interpreterRuntime.cpp line 1163:

> 1161:   ResourceMark rm(current);
> 1162:   methodHandle m (current, last_frame.method());
> 1163:   if(m->is_end_training_trigger()) {

unlike c1 and c2, we need to check the method flag here, as the generated code is used for many methods and so has to be included in all interpreter methods

src/hotspot/share/runtime/sharedRuntime.cpp line 1415:

> 1413: 
> 1414: JRT_BLOCK_ENTRY(void, SharedRuntime::end_training_check_c2(JavaThread* current))
> 1415: {

this and the _c1 method don't need to check the method flag to see if its a 'trigger', this is because we checked that on code generation which predicates the call to these methods

-------------

PR Review Comment: https://git.openjdk.org/leyden/pull/21#discussion_r1757405331
PR Review Comment: https://git.openjdk.org/leyden/pull/21#discussion_r1757404258