JEP 189: Shenandoah: An Ultra-Low-Pause-Time Garbage Collector (original) (raw)

Andrew Dinn adinn at redhat.com
Tue Jan 21 09:23:42 UTC 2014

On 20/01/14 20:53, Krystal Mok wrote:

Thanks for your answers. The point on using more threads to slow down mutators / speed up collectors is interesting.

Implementing a suitable scheduling algorithm (based on whatever heuristics) is going to be a very 'interesting' challenge but it does promise a gradual decrease in mutator throughput rather than simply dropping off the edge of a cliff.

Azul's collector uses a heuristic to predict when to start its GC cycle but -- as of last time I checked with Gil Tene -- that only extends to decreasing or increasing the amount of time spent in mutation+collection relative to the amount of time spent in mutation alone i.e. collection is started in the latter N% of mutation time where N% is predicted to be enough time to complete the cycle given the current burn rate, head room and expected collection time as monitored over the last few GCs.

Obviously that only helps up until the point where mutation+collection time = 100% of mutation time, at which point you have to hope the GC can keep up -- that or just add more memory (Gil's suggestion and one which has a lot to recommend it). However, if this limit case does need to be dealt with then heuristics which either i) vary the collector thread count or ii) modify the timeslice or frequency of collector threads look like a possible remedy.

What I was asking was mostly from a completeness perspective on the algorithm, not that the stop-the-world fallback will really happen in normal scenarios. It seems to me that, the way Shenandoah does concurrent evacuation through Brooks-style barrier will lead to it needing more headroom, and when there's not enough headroom it'll need to make sure it can handle all cases, right?

I believe Christine has already answered this in the affirmative.

regards,

Andrew Dinn

Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters (USA), Paul Hickey (Ireland)

More information about the hotspot-gc-dev mailing list