JDK-8012547 : Code cache flushing can get stuck without completing reclamation of memory
- Type: Bug
- Component: hotspot
- Sub-Component: compiler
- Affected Version: hs24,hs25
- Priority: P4
- Status: Resolved
- Resolution: Fixed
- OS: generic
- CPU: generic
- Submitted: 2013-04-17
- Updated: 2014-10-09
- Resolved: 2013-04-29
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 | Other |
|---|---|
8Fixed  |
hs25Fixed |
Description
In methods scan_stacks there is a check with an early return that may prevent the sweeper from restarting. The comment describes that the intention is to prevent early return when flushing is in progress. A call to should_compile_jobs() is used for deciding that. That is a faulty indication since compilations is active during normal flushing, and it's not until the final emergency flushing that compilations are actually stopped. This causes the reclamation of flushed methods to be unnecessarily slow.