RFR: Set ShenandoahMaxCSetFactor >50% to unclutter dense heaps better
Aleksey Shipilev
shade at redhat.com
Fri Aug 24 14:13:18 UTC 2018
Before the refactoring for allocation rate, this option was at 75%:
http://hg.openjdk.java.net/shenandoah/jdk/rev/846a1f988366#l1.19
It was like that for a reason. LRUFragger survives on very dense heap more reliably when this option
is restored at >50%. Other benchmarks are not affected, because they have enough headroom to never
hit the max-cset.
diff -r 1278eeea1a96 src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp
--- a/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp Thu Aug 23 11:33:51 2018 -0400
+++ b/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp Fri Aug 24 16:10:13 2018 +0200
@@ -178,14 +178,16 @@
experimental(uintx, ShenandoahLearningSteps, 5, \
"Number of GC cycles to run in order to learn application " \
"and GC performance for adaptive heuristics.") \
range(0,100) \
\
- experimental(uintx, ShenandoahMaxCSetFactor, 25, \
+ experimental(uintx, ShenandoahMaxCSetFactor, 60, \
"Maximum amount of free space to reserve for collection set "\
"allocations. Larger values make GC more aggressive, while " \
"leaving less headroom for application to allocate in. " \
+ "For dense heaps, should be more than 50 to clean up more " \
+ "space than application allocates in left-over heap. " \
"In percents of free space available.") \
range(0,100) \
\
experimental(uintx, ShenandoahAllocSpikeFactor, 5, \
"The amount of heap space to reserve for absorbing the " \
Testing: tier1_gc_shenandoah, benchmarks, LRUFragger
Thanks,
-Aleksey
More information about the shenandoah-dev
mailing list