RFR: Make control loop more responsive under allocation pressure

Roman Kennke rkennke at redhat.com
Thu Mar 8 14:21:26 UTC 2018


Am 08.03.2018 um 12:18 schrieb 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
> 


Ok



More information about the shenandoah-dev mailing list