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

[Aleksey Shipilev]

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

Thanks,
-Aleksey