Mercurial > hg > graal-compiler
changeset 16107:c7db9dc73694
disabled dialing C1 compilation back to partial profiling when Graal is the top tier compiler
author | Doug Simon <doug.simon@oracle.com> |
---|---|
date | Fri, 13 Jun 2014 18:42:33 +0200 |
parents | 5d84706642ce |
children | 1a6746681b43 |
files | src/share/vm/runtime/advancedThresholdPolicy.cpp |
diffstat | 1 files changed, 12 insertions(+), 0 deletions(-) [+] |
line wrap: on
line diff
--- 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: