RFR: Set ShenandoahMaxCSetFactor >50% to unclutter dense heaps better
Aleksey Shipilev
shade at redhat.com
Fri Aug 31 19:09:49 UTC 2018
On 08/24/2018 04:13 PM, Aleksey Shipilev wrote:
> 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
For the record, this is obsoleted by evac-reserve work:
http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-August/007270.html
...so I retract this RFR without pushing.
-Aleksey
More information about the shenandoah-dev
mailing list