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