RFR: Set ShenandoahMaxCSetFactor >50% to unclutter dense heaps better
Roman Kennke
rkennke at redhat.com
Fri Aug 24 14:35:22 UTC 2018
Good!
Am 24. August 2018 16:13:18 MESZ schrieb Aleksey Shipilev <shade at redhat.com>:
>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
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
More information about the shenandoah-dev
mailing list