-
Bug
-
Resolution: Fixed
-
P4
-
7
-
b04
-
generic
-
generic
-
Not verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2212538 | 8 | Igor Veresov | P4 | Resolved | Fixed | b01 |
JDK-2212539 | hs22 | Igor Veresov | P4 | Closed | Fixed | b01 |
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.
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.
- backported by
-
JDK-2212538 Tiered: Reprofiling doesn't happen in presence of level 4 OSR methods
- Resolved
-
JDK-2212539 Tiered: Reprofiling doesn't happen in presence of level 4 OSR methods
- Closed
- relates to
-
JDK-7066339 Tiered: policy should make consistent decisions about osr levels
- Closed