[9] RFR (XXS): 8049528: Method marked w/ @ForceInline isn't inlined with "executed < MinInliningThreshold times" message

[Vladimir Ivanov]

Roland, thanks for review.

>> http://cr.openjdk.java.net/~vlivanov/8049528/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8049528
>>
>> There's a missing case for @ForceInline in InlineTree::should_not_inline, so sometimes inlining fails w/  "executed < MinInliningThreshold times".
>>
>> The fix is to add missed check.
>>
>> Testing: manual (no inlining failures in the log), octane (no regresssions).
>
> Then:
>   259   if (!callee_method->force_inline()) {
>
> is useless.
Yes, you are right. Updated webrev in place.

> If it doesn’t affect performance why do we want to make that change? Isn’t there a risk that more inlining would exhaust the inlining budget and cause a performance degradation?
It doesn't affect performance on octane, but it can either improve or 
degrade performance w.r.t. our current inlining heuristics. More 
inlining could worsen the performance, but partial inlining of compiled 
lambda form chains could worsen it as well.

For chains of @ForceInline methods, inlining decision should be taken 
either before inlining the chain or after. The whole chain should be 
either inlined as a whole or not inlined at all.

What I want to fix with this change is to make @ForceInline consistent - 
the annotation should be always respected.

For example, I saw noticeable performance improvement w/ this fix while 
prototyping alternative version of guardWithTest JSR292 combinator 
(which has larger bytecode size than default one).

Unstable performance properties w.r.t. MethodHandle chains length 
already exists and this change doesn't worsen the situation, just makes 
the result more predictable.

Best regards,
Vladimir Ivanov

>
> Roland.
>