RFR: Application pacing precision fixes

[Aleksey Shipilev]

http://cr.openjdk.java.net/~shade/shenandoah/pacing-precision/webrev.01/

This resolves a few important issues in pacing implementation.

 *) Evac pacing used live data as the guidance for cset evacuation progress. Since there is no
allocation allowed in cset, we can just make use of SH::used, and get more smooth pacing. Smoothness
is improved because most regions in cset are 100% used, but liveness deviates very much in
single-digit percents. At that point, bitmap scans (looking for marked objects) have substantial
costs, so liveness becomes bad proxy for GC progress. We also want to report progress before yielding.

 *) Update-refs pacing used live_data to report progress, *but* the pacing baseline was SH::used!
Which means this phase had the potential to underestimate the GC progress. Then, update-ref-ing the
regions that are allocating means it could overestimate the GC progress, because it would report
recent allocations too as "progress". It is unknown which way this balance tips. New code takes
"used at update-refs start" for each region as the GC progress guidance. This also makes update-refs
pacing similar to evac pacing.

 *) Mark pacing is all over the place. Assuming the entire heap is live makes pacing very
aggressive, especially in cases where heap is mostly dead. This is the only place where we have to
use live-data as the proxy for GC progress. But to get the idea about the relative GC progress, we
have to know how much live data there is in the heap. I tried a few things (e.g. manual thresholds,
etc.), but recording history seems more reliable. The same thing applies to Traversal.

This whole thing significantly improve response times with long GC cycles.

Testing: tier3_gc_shenandoah, benchmarks

Thanks,
-Aleksey