RFR: Traversal pacing is too aggressive: live data is way lower than free

[Roman Kennke]

> Found this when following up why Traversal is slower than normal concurrent in the weekly runs. With
> new pacing scheme, we count "live" as progress for both mark and traversal. But most of the time,
> live << free, which means tax is significantly less than 1 (i.e. for each N bytes of GC progress we
> can allocate much more than N bytes of new data). I removed the line below from setup_for_mark, but
> not here:
> 
> diff -r cd4b0242a177 src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp
> --- a/src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp	Mon Jul 09 09:48:44 2018 +0200
> +++ b/src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp	Mon Jul 09 10:26:04 2018 +0200
> @@ -134,21 +134,20 @@
>  void ShenandoahPacer::setup_for_traversal() {
>    assert(ShenandoahPacing, "Only be here when pacing is enabled");
> 
>    size_t live = update_and_get_progress_history();
>    size_t free = _heap->free_set()->available();
> 
>    size_t non_taxable = free * ShenandoahPacingCycleSlack / 100;
>    size_t taxable = free - non_taxable;
> 
>    double tax = 1.0 * live / taxable; // base tax for available free space
> -  tax = MAX2<double>(1, tax);        // never allocate more than GC collects during the cycle
>    tax *= 1.1;                        // additional surcharge to help unclutter heap
> 
>    restart_with(non_taxable, tax);
> 
>    log_info(gc, ergo)("Pacer for Traversal. Expected Live: " SIZE_FORMAT "M, Free: " SIZE_FORMAT
>                       "M, Non-Taxable: " SIZE_FORMAT "M, Alloc Tax Rate: %.1fx",
>                       live / M, free / M, non_taxable / M, tax);
>  }
> 
>  /*
> 
> Testing: tier1_gc_shenandoah, specjbb with traversal

Looks good, thanks!
Roman