-
Enhancement
-
Resolution: Fixed
-
P4
-
17
-
b10
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.
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.
- relates to
-
JDK-8261655 [PPC64] Build broken after JDK-8260941
-
- Resolved
-
-
JDK-8307150 RISC-V: Remove remaining StoreLoad barrier with UseCondCardMark for Serial/Parallel GC
-
- Resolved
-
-
JDK-8234534 Simplify CardTable code after CMS removal
-
- Resolved
-
-
JDK-8261309 Remove remaining StoreLoad barrier with UseCondCardMark for Serial/Parallel GC
-
- Resolved
-
(1 links to)