RFR: LRU/Generational should catchup with allocations happening after trigger

[Aleksey Shipilev]

So I have been wondering why new partial heuristics miss so many new objects in pure allocation
tests. Then it struck me that we have a window between the partial GC *trigger* detected by
ShenandoahConcurrentThread, and the actual partial GC happening.

If both are targeting the same percentage of young/old regions, that means some allocations will
slip away! E.g. ShConcThread sees mutator allocated 400 MB, and our threshold is 400 MB, triggers
the GC, but when GC finally hits, the application had managed to allocate another 50 MB, which will
slip away.

The solution appears to be polling the same "allocated" value the trigger used, and act based on
that, which implicitly captures those allocations:
  http://cr.openjdk.java.net/~shade/shenandoah/partial-catchup/webrev.01/

See how beautiful the cycles are now in pure allocation workloads, they don't need any non-partial
cycles to clean up anymore (these are from fastdebug builds, this is why two-digit pause times):

  http://cr.openjdk.java.net/~shade/shenandoah/partial-catchup/generational-before.log
  http://cr.openjdk.java.net/~shade/shenandoah/partial-catchup/generational-after.log

  http://cr.openjdk.java.net/~shade/shenandoah/partial-catchup/lru-before.log
  http://cr.openjdk.java.net/~shade/shenandoah/partial-catchup/lru-after.log

It also improves testing time, because we don't have lots of floating garbage we need to verify with
partial heuristics.

Testing: hotspot_gc_shenandoah

Thanks,
-Aleksey