Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8047263 | 8u25 | Nils Eliasson | P3 | Resolved | Fixed | b03 |
JDK-8046379 | 8u20 | Nils Eliasson | P3 | Resolved | Fixed | b19 |
JDK-8053387 | emb-8u26 | Nils Eliasson | P3 | Resolved | Fixed | b17 |
This bug may prevent methods that have been deoptimized from being recompiled at the proper level.
In remove_osr_nmethod we are trying to find the highest comp level by iterating though all linked osr-nmethods. But the code fails to take into account that the chained OSR-nmethods may belong to any nmethod in that class, not just that nmethod (as is the case for non-OSR nmethods.)
This bug has been present since the integration of tiered compilation.
Impact: May cause loss of performance
Likelihood: Unknown, but probably not uncommon in scenarios with lots of deopts.
Workaround: Turn of tiered-compilation, but that will probably hurt performance even more.
In remove_osr_nmethod we are trying to find the highest comp level by iterating though all linked osr-nmethods. But the code fails to take into account that the chained OSR-nmethods may belong to any nmethod in that class, not just that nmethod (as is the case for non-OSR nmethods.)
This bug has been present since the integration of tiered compilation.
Impact: May cause loss of performance
Likelihood: Unknown, but probably not uncommon in scenarios with lots of deopts.
Workaround: Turn of tiered-compilation, but that will probably hurt performance even more.
- backported by
-
JDK-8046379 OSR methods may not be recompiled at proper compilation level after deoptimization
-
- Resolved
-
-
JDK-8047263 OSR methods may not be recompiled at proper compilation level after deoptimization
-
- Resolved
-
-
JDK-8053387 OSR methods may not be recompiled at proper compilation level after deoptimization
-
- Resolved
-
- blocks
-
JDK-8007270 Make IsMethodCompilable test work with tiered
-
- Resolved
-