Fix issue 21159: prevent endless inlining of field dispatchers.

runtime/vm/flow_graph_inliner.cc

Index: runtime/vm/flow_graph_inliner.cc
===================================================================
--- runtime/vm/flow_graph_inliner.cc	(revision 41152)
+++ runtime/vm/flow_graph_inliner.cc	(working copy)
@@ -47,8 +47,7 @@
 DEFINE_FLAG(int, inlining_hotness, 10,
     "Inline only hotter calls, in percents (0 .. 100); "
     "default 10%: calls above-equal 10% of max-count are inlined.");
-DEFINE_FLAG(bool, inline_recursive, true,
-    "Inline recursive calls.");
+DEFINE_FLAG(bool, inline_recursive, false, "Inline recursive calls.");
 DEFINE_FLAG(int, max_inlined_per_depth, 500,
     "Max. number of inlined calls per depth");
 DEFINE_FLAG(bool, print_inlining_tree, false, "Print inlining tree");
@@ -764,11 +763,12 @@
             &call_data->caller, &function, call_data->call);
         return false;
       }
-
       if (function.IsInvokeFieldDispatcher() ||
           function.IsNoSuchMethodDispatcher()) {
         // Append call sites to the currently processed list so that dispatcher
         // methods get inlined regardless of the current depth.
+        // Need a throttling mechanism for recursive inlining.
+        ASSERT(!FLAG_inline_recursive);
         inlining_call_sites_->FindCallSites(callee_graph,
                                             0,

[zerny-google, 2014/10/20 11:28:21]

DBC: It seems this issue is caused by ignoring the inlining depth. We could
separate the general depth threshold from the recursive depth threshold (I
recall talking about this, but not implementing it, since, at the time, the
general depth achieved mostly the same thing.)

[Florian Schneider, 2014/10/20 14:01:56]

I agree that a separate threshold for recursive inlining would be the best if we
do want to inline recursive call-sites. Dispatchers should always be inlined,
since they are so small. 

                                             &inlined_info_);