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

Aleksey Shipilev shade at redhat.com
Mon Mar 23 11:58:41 UTC 2020


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}

-- 
Thanks,
-Aleksey




More information about the hotspot-gc-dev mailing list