- 
    Enhancement 
- 
    Resolution: Fixed
- 
     P4 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)
        
     
        