JDK-8247928 : Refactor G1ConcurrentMarkThread for mark abort
- Type: Enhancement
- Component: hotspot
- Sub-Component: gc
- Affected Version: 16
- Priority: P4
- Status: Resolved
- Resolution: Fixed
- Submitted: 2020-06-19
- Updated: 2020-09-21
- Resolved: 2020-09-10
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 16 |
|---|
16 b16Fixed  |
Related Reports
|
Blocks :
|
Description
JDK-8240556 proposes to "abort" concurrent mark right after initial mark if the gc happens to free enough memory to go below the IHOP threshold. For that it needs to undo any marking work already done in the pause (currently we immediately mark roots from non-Java heap). The current proposed patch for that undoes the marks in the pause, which is a time consuming process, even if done in parallel. For this reason it would be nice if the G1ConcurrentMarkThread could be cleaned up a little to do that bitmap clear concurrently. (Even without that reason, it would be a good cleanup candidate)
Comments
|