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

Zhengyu Gu zgu at openjdk.org
Tue Oct 22 17:15:17 UTC 2024


On Wed, 9 Oct 2024 03:26:30 GMT, Liang Mao <lmao 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 478 commits:
>> 
>>  - Fix merge error
>>  - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux
>>  - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux
>>  - Merge branch 'shenandoah/master' into great-genshen-pr-redux
>>  - Merge
>>  - 8341099: GenShen: assert(HAS_FWD == _heap->has_forwarded_objects()) failed: Forwarded object status is sane
>>    
>>    Reviewed-by: kdnilsen
>>  - 8341485: GenShen: Make evac tracker a non-product feature and confine it to generational mode
>>    
>>    Reviewed-by: kdnilsen, ysr
>>  - Merge
>>  - 8341042: GenShen: Reset mark bitmaps for unaffiliated regions when preparing for a cycle
>>    
>>    Reviewed-by: kdnilsen
>>  - 8339616: GenShen: Introduce new state to distinguish promote-in-place phase as distinct from concurrent evacuation
>>    
>>    Reviewed-by: kdnilsen, shade, ysr
>>  - ... and 468 more: https://git.openjdk.org/jdk/compare/b9db74a6...4db1e0e1
>
> Congratulations! Good to see the great progress. I just built this PR for some testing and found something unexpected. I ran the genshen VS shenandoah(default) with jbb2015 on aarch64 N2 with 8 cores and Xmx8g. The critical-jOPS of genshen(5373) is behind shenandoah(6027). Do I miss something on the options?
> ```java -Xmx8g -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCHeuristics=adaptive -XX:ShenandoahGCMode=generational -Xlog:gc*  -XX:MetaspaceSize=1g   -jar specjbb2015.jar -m COMPOSITE```

> @mmyxym , Thank you for testing this out! I apologize for not responding to your comment sooner. We run specjbb2015 regularly in our integration pipeline. We see a slight improvement with the generational mode; certainly no regression:
> 
> ```
> Shen: RUN RESULT: hbIR (max attempted) = 4701, hbIR (settled) = 3934, max-jOPS = 3620, critical-jOPS = 2375
> Gen:  RUN RESULT: hbIR (max attempted) = 3934, hbIR (settled) = 3295, max-jOPS = 4013, critical-jOPS = 2470
> Shen: RUN RESULT: hbIR (max attempted) = 4701, hbIR (settled) = 3934, max-jOPS = 3667, critical-jOPS = 2397
> Gen:  RUN RESULT: hbIR (max attempted) = 4701, hbIR (settled) = 3934, max-jOPS = 3996, critical-jOPS = 2414
> ```
> 
> These results were produced with these arguments:
> 
> ```
> -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticV
> MOptions -XX:-TieredCompilation -XX:-ShenandoahPacing -XX:+AlwaysPreTouch -XX:+DisableExplicitGC -Xmx10g -Xms10g -XX:ShenandoahGCMode=generational
> ```
> 
> These runs executed on a Graviton2 host with 4 cores, 16G. I'll run again on a host with more cores and with your exact command line parameters.

What's the reason to disable tiered compilation?

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

PR Comment: https://git.openjdk.org/jdk/pull/21273#issuecomment-2429827638


More information about the serviceability-dev mailing list