# HG changeset patch
# User Doug Simon <doug.simon@oracle.com>
# Date 1402677753 -7200
# Node ID c7db9dc736947e368c22e7c675567e97f58bd51c
# Parent  5d84706642ce67cc9dfc7d0e7a712fd1a36bcd37
disabled dialing C1 compilation back to partial profiling when Graal is the top tier compiler

diff -r 5d84706642ce -r c7db9dc73694 src/share/vm/runtime/advancedThresholdPolicy.cpp
--- a/src/share/vm/runtime/advancedThresholdPolicy.cpp	Fri Jun 13 18:41:45 2014 +0200
+++ b/src/share/vm/runtime/advancedThresholdPolicy.cpp	Fri Jun 13 18:42:33 2014 +0200
@@ -345,6 +345,17 @@
       if (common(p, method, CompLevel_full_profile, disable_feedback) == CompLevel_full_optimization) {
         next_level = CompLevel_full_optimization;
       } else if ((this->*p)(i, b, cur_level)) {
+#ifdef COMPILERGRAAL
+        // Since Graal takes a while to warm up, its queue inevitably backs up during
+        // early VM execution. As of 2014-06-13, Graal's inliner assumes that the root
+        // compilation method and all potential inlinees have mature profiles (which
+        // includes type profiling). If it sees immature profiles, Graal's inliner
+        // can perform pathologically bad (e.g., causing OutOfMemoryErrors due to
+        // exploring/inlining too many graphs). Since a rewrite of the inliner is
+        // in progress, we simply disable the dialing back heuristic for now and will
+        // revisit this decision once the new inliner is completed.
+        next_level = CompLevel_full_profile;
+#else
         // C1-generated fully profiled code is about 30% slower than the limited profile
         // code that has only invocation and backedge counters. The observation is that
         // if C2 queue is large enough we can spend too much time in the fully profiled code
@@ -358,6 +369,7 @@
         } else {
           next_level = CompLevel_full_profile;
         }
+#endif
       }
       break;
     case CompLevel_limited_profile: