JDK-8062913 : Bad tiered level transitions
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9
  • Priority: P4
  • Status: Closed
  • Resolution: Not an Issue
  • Submitted: 2014-11-05
  • Updated: 2015-10-08
  • Resolved: 2015-10-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9Resolved
Related Reports
Relates :  
JDK-8056071 - compiler/whitebox/IsMethodCompilableTest.java fails with 'method() is not compilable after 3 iterations'
Description
While working on JDK-8056071 I added verification code to the AdvancedThresholdPolicy to check that all transitions are meaningful, i.e. no transition
- to the same level
- from level 1 and 4
- from level 3 to 2

The current implementation violates this assertion:

# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/opt/jprt/T/P1/091408.tohartma/s/hotspot/src/share/vm/runtime/advancedThresholdPolicy.cpp:221), pid=13436, tid=47676587804416
#  assert(comp_level != max_task->comp_level() && comp_level != CompLevel_simple && comp_level != CompLevel_full_optimization && !(comp_level == CompLevel_full_profile && max_task->comp_level() == CompLevel_limited_profile)) failed: Bad transition of 'com.sun.tools.javac.code.Types.isSubtypeUncheckedInternal(Lcom/sun/tools/javac/code/Type;Lcom/sun/tools/javac/code/Type;Lcom/sun/tools/javac/util/Warner;)Z' from 2 to 2
#
# JRE version: Java(TM) SE Runtime Environment (9.0) (build 1.9.0-internal-fastdebug-201411050914.tohartma.8056071-b00)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (1.9.0-internal-fastdebug-201411050914.tohartma.8056071-b00 mixed mode linux-amd64 compressed oops)
# Core dump written. Default location: /opt/jprt/T/P1/091408.tohartma/s/hotspot/build/linux-x86_64/testoutput/JTwork/compiler/7119644/TestIntDoubleVect/core or core.13436
#
# An error report file with more information is saved as:
# /opt/jprt/T/P1/091408.tohartma/s/hotspot/build/linux-x86_64/testoutput/JTwork/compiler/7119644/TestIntDoubleVect/hs_err_pid13436.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
#
Comments
Looked at this again and I think Igor is right. Closing this as "not an issue".
08-10-2015
You cannot determine the level of the caller by doing "comp_level = max_method->code()->comp_level()" - by the time you're looking at it the method might have been replaced, while the OSRing thread can be executing at any previous level. You need to walk the stack to determine the real nmethod that is calling back for the OSR. Also, 3 to 2 could be a legit transition. 2 is faster than 3, and if the method is already profiled, I believe that can happen.
05-11-2014
From the log files it looks like as if there are both transitions from 2 to 2 and (rarely) transitions from 3 to 2.
05-11-2014