RFR (XS) 8241435: Shenandoah: avoid disabling pacing with "aggressive"

Roman Kennke rkennke at redhat.com
Mon Mar 23 12:25:26 UTC 2020


Hi Aleksey,

This looks ok to me!

Thank you!
Roman

> RFE:
>   https://bugs.openjdk.java.net/browse/JDK-8241435
> 
> Deeper testing of JDK-8241139 shows that GCLockerWithShenandoah.java reliably fails in release, and
> always with aggressive heuristics. Investigation shows that application manages to outpace the GC
> every time, and then fail with OOME too early. We should consider keep pacing enabled even in
> aggressive mode. This is the day 1 issue with pacing implementation.
> 
> Fix:
> 
> --- a/src/hotspot/share/gc/shenandoah/heuristics/shenandoahAggressiveHeuristics.cpp     Mon Mar 23
> 12:25:29 2020 +0100
> +++ b/src/hotspot/share/gc/shenandoah/heuristics/shenandoahAggressiveHeuristics.cpp     Mon Mar 23
> 12:53:32 2020 +0100
> @@ -33,13 +33,10 @@
> 
>  ShenandoahAggressiveHeuristics::ShenandoahAggressiveHeuristics() : ShenandoahHeuristics() {
>    // Do not shortcut evacuation
>    SHENANDOAH_ERGO_OVERRIDE_DEFAULT(ShenandoahImmediateThreshold, 100);
> 
> -  // Aggressive runs with max speed for allocation, to capture races against mutator
> -  SHENANDOAH_ERGO_DISABLE_FLAG(ShenandoahPacing);
> -
>    // Aggressive evacuates everything, so it needs as much evac space as it can get
>    SHENANDOAH_ERGO_ENABLE_FLAG(ShenandoahEvacReserveOverflow);
> 
>    // If class unloading is globally enabled, aggressive does unloading even with
>    // concurrent cycles.
> 
> 
> Testing: hotspot_gc_shenandoah {fastdebug,release}
> 



More information about the shenandoah-dev mailing list