RyuJIT in-lining policy: factor in the benefit of eliminating an address exposed obj-ref local  #7201

Consider the following methods and call chain from BinaryTrees benchmark.

      internal static TreeNode bottomUpTree( int item, int depth ) {
         TreeNode t;
         ChildTreeNodes(out t, item, depth - 1);
         return t;
      }
        static void ChildTreeNodes( out TreeNode node, int item, int depth ) {
         node = new TreeNode(item);
         if ( depth > 0 ) {
            ChildTreeNodes(out node.left, 2 * item - 1, depth - 1);
            ChildTreeNodes(out node.right, 2 * item, depth - 1);
         }
      }
      internal int itemCheck() {
         if ( right == null ) return item;
         else return item + left.itemCheck() - right.itemCheck();
      }

Main() -> bottomUpTree() -> ChildTreeNodes()

Legacy inlining policy inlines bottomUpTree() in Main() but considers not profitable to in-line ChildTreeNodes(). As a result, Main() methods ends up with an addr exposed local, which is updated by ChildTreeNode() using a writebarrier since it cannot reason about its out-param. Further the addr-exposed local is pointing to the root of the binary tree. If the Main() method is such that it calls bottomUpTree() many times, it will end up with that many addr-exposed, untracked gc-ref locals on stack. That is unused objects get held up and will not be freed while executing within Main(), as a result of which GC would have to do more work, which in turn impacts execution perf. This precisely happens with BinaryTrees benchmark.

With Model in-lining policy it so happens that even ChildTreeNodes() gets in-lined when called inside a doubly nested loop and benchmark gets the benefit eliminating untracked local and unnecessary write-barrier. The observation here is it seems beneficial to factor in eliminating an addr-exposed obj-ref local at a call site to determine whether it is profitable to in-line a call at a particular call site.
category:cq
theme:inlining
skill-level:expert
cost:medium