RFR: 8350086: Inline hot Method accessors for faster task selection [v3]

[Aleksey Shipilev]

On Fri, 14 Feb 2025 15:12:50 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> These methods show up prominently on Leyden profiles, as compilation policy asks these properties for methods very often during compile task selection:
>>  - `Method::invocation_count`
>>  - `Method::backedge_count`
>>  - `Method::highest_comp_level`
>> 
>> We can move the definitions for these methods to method.inline.hpp to make them eligible for better inlining.
>> 
>> `interpreter_invocation_count()` method is a bit weird, looks like a leftover from [JDK-8251462](https://bugs.openjdk.org/browse/JDK-8251462). Removing it would prompt more cleanups and renamings in `ciMethod`, so I would leave it for future enhancement.
>> 
>> Additional testing: 
>>  - [x] Spot-checked Leyden profiles, methods are now fully inlined into hot `CompilerBroker` methods
>>  - [x] Ad-hoc Leyden benchmarks show minor improvements (< 1%) for time spent in compiler threads
>
> Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - One more include for Minimal VM
>  - Turn declarations proper inline

Thank you for reviews! 

Yes, the core of the problem is potentially quadratic behavior in task selection, like Vladimir describes. We had this problem in Leyden for SCC tasks: https://github.com/openjdk/leyden/pull/17 -- so it does not apply to SC loaded methods anymore. I agree it would be great to resolve the task selection problem at its core; unfortunately, my crude attempts at doing so failed, because tiered policy is quite fiddly. It does not mean we would not try again, it just means it would take a bit more time. Meanwhile, we can address little inefficiencies without solving the core issue.

To that extent, I would spin this more positively: now that Leyden is able to shift away the bulk of C2 compilations away, the little inefficiencies in normal compilation paths show up in those runs. The inefficiency is also in mainline, but it would be obscured by the heavy compilations that would follow the task selection.

So I think these kind of inlining improvements stand well on their own, and are still worth doing.

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

PR Comment: https://git.openjdk.org/jdk/pull/23634#issuecomment-2660812463