RFR: Make control loop more responsive under allocation pressure

[Aleksey Shipilev]

http://cr.openjdk.java.net/~shade/shenandoah/control-loop-faster/webrev.01/

These are bits and pieces for allocation pacing work.

Current control interval is 10 ms, which is not really enough for smaller heaps. Some math: suppose
we allocate at 20 GB/sec (my desktop pulls that off easily), then we allocate 200 MB while control
loop is catching up. Adaptive target for free space is set to 3% by default, which means those 3%
could be consumed by allocations without control loop noticing, when heap is smaller than 200 / 3% =
6.7 GB.

Making the default control interval 1 ms cuts those figures to 20 MB "slack" and 670 MB min heap.

This has the potential to increase overheads. Current ShConcThread takes 0.3% of logical CPU on my
desktop when GC is idle, and blindly setting the control interval to 1 ms balloons it up to 1.5%. To
avoid this, we are implementing the time-based exponential backoff: during the active phases we
would do quicker polls, and during idle phases we will decay to longer sleep.

Testing: hotspot_gc_shenandoah, eyeballing peak allocation tests

Thanks,
-Aleksey