Heuristics for inlining in OpenJ9

• getSymbolAndFindInlineTargets contains a bunch of methods that we shouldn't inline.
  • supressInliningRecognizedInitialCallee Methods we don't inline due to heuristics
  • checkInlineableWithoutInitialCalleeSymbol Don't inline interfaces
  • checkIfTargetInlineable
    • TR_J9VMBase::checkInlineableTarget This first if statement controls inlining of a large class of JSR292 methods, which we want to consider ONLY in certain cases in early rounds of inlining... Always choose to inline these methods; the first two are small getters, and the last three are single-level "leaf" handles Last round of inlining, no more JSR292 methods (other than the above two things, to which we always say yes) We're in JSR292 Inlining rounds, and we are ourselves an archetype specimen, so we can inline other archetype specimina whenever we see fit // We are a hot method that isn't an archetype specimen, and we're in JSR292 inlining, // but because we're hot (or greater) we are allowed to inline JSR292 methods whenever we see fit We are in first rounds of inlining, we are warm or below, and we are not an archetype specimen ourselves... No inlining of JSR292 methods. // If we aren't in the last round of inlining, don't inline anything that didn't fall into the above category // If we are an AOT cold compile, don't inline We are trying to inline a non-JSR292 method, and we are in the last round of inlining, but we are a shareable thunk, so say NO // Except for do and undo customization logic which we still want to inline... // Don't inline methods that are going to be reduced in ilgen or UnsafeFastPath /DAA Intrinsic methods will get reduced if intrinsics are on, so don't consider it as a target // dont inline methods that contain the NumberFormat pattern // this is because we want to catch the opportunity with stringpeepholes // and stringpeepholes runs before inliner. so if the calleemethod contained // the pattern and it got inlined, we would never find the pattern
• applyPolicyToTargets high level sieve that also checks the number of parameter slots.
• TR_MultipleCallTargetInliner::exceedsSizeThreshold checks against several size heuristics.
  • polymorphic callee sizes
  • polymorphic root size
  • // we need to be conservative about inlining potentially highly polymorphic interface calls for // functional frameworks like scala - we limit this to hot and above // if the callsite is highly polymorphic but the following conditions are meet, still inline the callee // 1. the compiling method is sorching // 2. the callee is scorching OR queued for veryhot/scorching compile
  • frequency heuristics
  • reduce size if your args are consts
  • MIN_FAN_IN_SIZE
  • In JIT, having low caller information is equivalent to lack of information. We want to exclude only cases where we know we have alot of fan-in
  • adjustFanInSizeInExceedsSizeThreshold
• TR_InlinerBase::exceedsSizeThreshold also checks other options and looks for constant arguments.
• inlineCallTarget inline depth
• doCorrectnessAndSizeChecksForInlineCallTarget number of inlined sites, node counts, loops