RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v6]

[Y. Srinivas Ramakrishna]

On Wed, 13 Nov 2024 10:51:48 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 503 commits:
>> 
>>  - Merge openjdk/jdk tip into great-genshen-pr-redux
>>  - Merge remote-tracking branch 'jdk/master' into merge-latest
>>  - Merge remote-tracking branch 'jdk/master' into merge-latest
>>  - Merge
>>  - 8342861: GenShen: Old generation in unexpected state when abandoning mixed gc candidates
>>    
>>    Reviewed-by: kdnilsen
>>  - 8342734: GenShen: Test failure gc/shenandoah/TestReferenceRefersToShenandoah.java#generational
>>    
>>    Reviewed-by: ysr
>>  - 8342919: GenShen: Fix whitespace
>>    
>>    Reviewed-by: xpeng, kdnilsen
>>  - 8342927: GenShen: Guarantee slices of time for coalesce and filling
>>    
>>    Reviewed-by: kdnilsen
>>  - 8342924: GenShen: Problem list gc/shenandoah/TestReferenceRefersToShenandoah.java
>>    
>>    Reviewed-by: kdnilsen, ysr
>>  - 8342848: Shenandoah: Marking bitmap may not be completely cleared in generational mode
>>    
>>    Reviewed-by: wkemper
>>  - ... and 493 more: https://git.openjdk.org/jdk/compare/1c448347...19b25bc3
>
> src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp line 474:
> 
>> 472:     // elision safe.
>> 473:     return;
>> 474:   }
> 
> Why is this safe for Shenandoah? I suspect it needs `CardTableBarrierSet::on_slowpath_allocation_exit` to work. `G1BarrierSetC2` gets it by subclassing `CardTableBarrierSetC2`. But `ShenandoahBarrierSetC2` does not. Should it?

Good question. I'm tracking at https://bugs.openjdk.org/browse/JDK-8344593 , and will follow up there.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1849318244