RFR: Application pacing precision fixes

[Roman Kennke]

Looks good. Thanks!

Roman


> 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
>