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

[Roland Westrelin]

>> 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.

Why not make a similar change to InlineTree::should_inline()? Shouldn’t it always return true if callee_method->force_inline() is true?

Roland.