JDK-8220240 : Refactor shared dirty card queue
- Type: Enhancement
- Component: hotspot
- Sub-Component: gc
- Priority: P4
- Status: Resolved
- Resolution: Fixed
- Submitted: 2019-03-06
- Updated: 2019-03-28
- Resolved: 2019-03-22
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 13 |
|---|
13 b14Fixed  |
Related Reports
|
Relates :
|
|
|
Relates :
|
|
|
Relates :
|
|
|
Relates :
|
Description
After JDK-8219613, there is only one remaining use of a shared dirty card queue. All other uses of dirty card queues are thread-local in one way or another (in the G1ThreadLocalData, or in some local object such as a G1ParScanThreadState or a thread-local closure object). That remaining use (in G1RemSet::refine_card_concurrently) still needs a shared queue. However, having one class which supports both the normal thread-local usage and that one shared usage makes the code more complicated and less performant than need be. The shared case should be separated out into its own class.