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

[Ashutosh Mehra]

On Thu, 14 Nov 2024 19:57:14 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 not recording
>> 
>> JBS Issue: https://bugs.openjdk.org/browse/JDK-8335358
>
> Mat Carter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 43 additional commits since the last revision:
> 
>  - Enhanced upcall system testing options (based on PR feedback)
>  - Removing unused includes
>  - Remove cds include, no longer required after refactor
>  - merge issue
>  - fix merge issues
>  - Update other platforms
>  - Merge branch 'premain' into macarte-endtraining
>  - Merge pull request #2 from macarte/macarte-endtraining-refactor
>    
>    Macarte endtraining refactor
>  - minor edits
>  - small changes based on PR review
>  - ... and 33 more: https://git.openjdk.org/leyden/compare/4af49dbe...9c3cdf78

src/hotspot/share/cds/cdsConfig.cpp line 675:

> 673: 
> 674: bool CDSConfig::is_dumping_preimage_static_archive_with_triggers() {
> 675:   return _is_dumping_static_archive && CacheDataStore != nullptr && CDSPreimage == nullptr && !FLAG_IS_DEFAULT(AOTEndTrainingOnMethodEntry);

This can be replaced with `is_dumping_preimage_static_archive() && !FLAG_IS_DEFAULT(AOTEndTrainingOnMethodEntry)`

src/hotspot/share/cds/cdsEndTrainingUpcall.hpp line 33:

> 31: 
> 32: #include "code/codeBlob.hpp"
> 33: #include "code/vmreg.hpp"

umm...do we need all these includes here? I think some may be redundant.
Same applies to runtimeUpcallNop.hpp.

src/hotspot/share/runtime/runtimeUpcallNop.cpp line 45:

> 43: bool RuntimeUpcallNop::filter_method_callback(MethodDetails& methodDetails)
> 44: {
> 45:   return false;

Shouldn't this be returning true to enable it for all methods as per the documentation for AddRuntimeUpcallsNOP in globals.hpp?

src/hotspot/share/runtime/runtimeUpcalls.cpp line 96:

> 94:   // which upcalls to call, but it would be more efficient than the current implementation as we'd avoid the
> 95:   // method matching and simply map bits to indexes.
> 96: 

Another way to speed it up is to store a hashset of Method pointers in each RuntimeUpcallInfo when `RuntimeUpcalls::mark_for_upcalls` is called for the method. Then the method matching can be replaced with a  lookup in the hashset.

src/hotspot/share/runtime/runtimeUpcalls.hpp line 39:

> 37: };
> 38: 
> 39: typedef void (*RuntimeUpcall)(JavaThread* current);

Not needed for the AOTEndTrainingOnMethodEntry option, but I think passing the method as the argument for which upcall is being done could be beneficial.

src/hotspot/share/runtime/runtimeUpcalls.hpp line 65:

> 63: 
> 64: public:
> 65:   static RuntimeUpcallInfo* Create(const char* upcallName, const RuntimeUpcall upcall, const RuntimeUpcallMethodFilterCallback methodFilter) {

I think the convention is to always use lower case for methods, so probably s/Create/create

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

PR Review Comment: https://git.openjdk.org/leyden/pull/21#discussion_r1838771681
PR Review Comment: https://git.openjdk.org/leyden/pull/21#discussion_r1838771772
PR Review Comment: https://git.openjdk.org/leyden/pull/21#discussion_r1838777872
PR Review Comment: https://git.openjdk.org/leyden/pull/21#discussion_r1838772148
PR Review Comment: https://git.openjdk.org/leyden/pull/21#discussion_r1838784474
PR Review Comment: https://git.openjdk.org/leyden/pull/21#discussion_r1838772055