RFR: 8300002: Performance regression caused by non-inlined hot methods due to post call noop instructions

[Sergey Kuksenko]

On Thu, 12 Jan 2023 06:08:53 GMT, Erik Österlund <eosterlund at openjdk.org> wrote:

>> 8300002: Performance regression caused by non-inlined hot methods due to post call noop instructions
>
> src/hotspot/share/opto/bytecodeInfo.cpp line 183:
> 
>> 181:     // Not hot.  Check for medium-sized pre-existing nmethod at cold sites.
>> 182:     if (callee_method->has_compiled_code() &&
>> 183:         callee_method->inline_instructions_size() > inline_small_code_size) {
> 
> I do have to wonder if the actual problem is that this method is considered not hot by the InlineFrequenceRatio heuristic above. We are in the else clause and there is a comment saying this isn't hot. But obviously it was. Your approach tweaks the not hot path to still allow inlining, but I do wonder if it's the hot method detection scheme that could need some love. Just a thought...

It's not hot (by C2 meaning way). 
But if non-inlining causes 2x times performance regression -> that is a "hot" by performance meaning.
Here is the key issue - methods became non-inlined by "already compiled to large/medium method".
But it happened only because noop instructions were added. 
Common sense says that adding noops shouldn't change inline decisions.

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

PR: https://git.openjdk.org/jdk/pull/11958