JDK-7058689 : Tiered: Reprofiling doesn't happen in presence of level 4 OSR methods
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 7
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2011-06-23
  • Updated: 2011-11-25
  • Resolved: 2011-09-30
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 7 JDK 8 Other
7u2 b04Fixed 8Fixed hs22Fixed
Related Reports
Relates :  
Description
When we deopt from a C2-compiled method and request reprofiling (we're at level 0 at this point) natually we would want to start reprofiling in the interpreter and queue up a level 3 compile and continue profiling at level 3 when it arrives. However, when we decide to which level to switch we check the max comp level of OSR version of the method. If a this level is 4 and there's been more than one profiled invocation we would choose to compile at level 4. This is to avoid deopt loops when we deopt and switch to a higher level OSR method.

So, need to handle the situation differently. The solution is to check whether a OSR would be possible at all at the moment (by calling the transition function with a loop predicate), and then checking what OSR methods are currently available.

Comments
EVALUATION See main CR
30-08-2011

EVALUATION http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6f6e91603a45
08-07-2011

EVALUATION http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6f6e91603a45
07-07-2011

EVALUATION http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/6f6e91603a45
01-07-2011

EVALUATION See description.
23-06-2011