JDK-8260941 : Remove the conc_scan parameter for CardTable
- Type: Enhancement
- Component: hotspot
- Sub-Component: gc
- Affected Version: 17
- Priority: P4
- Status: Resolved
- Resolution: Fixed
- Submitted: 2021-02-02
- Updated: 2025-01-16
- Resolved: 2021-02-12
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 17 |
|---|
17 b10Fixed  |
Related Reports
|
Relates :
|
|
|
Relates :
|
|
|
Relates :
|
|
|
Relates :
|
Description
The conc_scan parameter for CardTable affects code generation, adding necessary memory barriers in some paths. The only collector after CMS removal enabling it is G1, i.e. enabling CardTableBarrierSet::card_mark_must_follow_store(); however lots of code generation uses CardTable::scanned_concurrently() directly. Initial results just overriding CardTableBarrierSet::card_mark_must_follow_store() for G1 (and removing CardTable::scanned_concurrently()) seems to result in wrongly generated code - i.e. CardTable::scanned_concurrently() may be used incorrectly in some places. Investigate and see if conc_scan from the card table can be removed.
Comments
|