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

[Vladimir Ivanov]

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

Marked as reviewed by vlivanov (Reviewer).

The patch looks well-justified to me, but it feels like the focus is on a symptom and not the root cause. 

> These methods show up prominently on Leyden profiles, as compilation policy asks these properties for methods very often during compile task selection

That's the consequence of poor scaling properties `CompilationPolicy::select_task()` demonstrates. Each `CompileQueue::get()` call involves a linear pass over the whole compile queue (implemented as linked list) recomputing event rate each time. The longer the queue, the more time it takes to select next task to compile. And Leyden greatly exarcebates the problem by aggressively submitting compilation tasks based on training data.

FTR heavy lock contention on `MethodCompileQueue_lock` was another symptom of the very same problem. Proper fix would be to reimplement how compilation task prioritization is implemented.

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

PR Review: https://git.openjdk.org/jdk/pull/23634#pullrequestreview-2618599459
PR Comment: https://git.openjdk.org/jdk/pull/23634#issuecomment-2660065664