| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8083471 | emb-9 | Igor Ignatyev | P2 | Resolved | Fixed | b40 |
| JDK-8129140 | 8u65 | Igor Ignatyev | P2 | Resolved | Fixed | b02 |
| JDK-8066885 | 8u60 | Igor Ignatyev | P2 | Closed | Fixed | b20 |
| JDK-8137695 | emb-8u65 | Unassigned | P2 | Resolved | Fixed | b02 |
| JDK-8129664 | emb-8u60 | Igor Ignatyev | P2 | Resolved | Fixed | b20 |
Essence of issue is that in gc and in other areas we have stress tests that spawn a lot of threads. This results in more deoptimization with -XX:+DeoptimizeALot in the following way: more threads => more calls of runtime methods defined through macroses IRT_ENTRY, IRT_ENTRY_NO_ASYNC, JRT_ENTRY, JRT_ENTRY_NO_ASYNC and JRT_BLOCK => more calls of InterfaceSupport::deoptimizeAll() in ~VMEntryWrapper() destructor => test timeouts. Test determines number of threads based on host properties, so it's not convenient to address issue using DeoptimizeALotInterval. It would be useful if we have a key that would let us set DeoptimizeALotInterval proportional to number of threads.
Consider making determining DeoptimizeALotInterval depending of threads number to be a default behavior.
Consider making determining DeoptimizeALotInterval depending of threads number to be a default behavior.
- backported by
-
JDK-8083471 make DeoptimizeALot dependent on number of threads
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Closed
-
- relates to
-
JDK-8031719 ConcurrentAssociateTest, FJExceptionTableLeak, and ToArrayOpTest timeout
-
- Closed
-
(1 relates to)