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