JDK-8036913 : make DeoptimizeALot dependent on number of threads
- Type: Enhancement
- Component: hotspot
- Sub-Component: compiler
- Affected Version: 9
- Priority: P2
- Status: Resolved
- Resolution: Fixed
- Submitted: 2014-03-07
- Updated: 2015-09-29
- Resolved: 2014-11-02
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.
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 8 | JDK 9 |
|---|---|
8u60Fixed  |
9 b40Fixed |
Related Reports
|
Relates :
|
Description
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.
Comments
|