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