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

Srinivas Ramakrishna ysr1729 at gmail.com
Tue Jan 21 17:15:46 UTC 2014

On Tue, Jan 21, 2014 at 1:38 AM, Thomas Schatzl <thomas.schatzl at oracle.com>wrote:

.... I can imagine this was how the non-generational G1 worked initially too. It did not work out to have the expected performance, or at least it has been shown extremely beneficial for a few reasons to by default collect the nursery regions. Probably mainly because G1 would select the regions it recently allocated into anyway.

As you mention, Shenandoah will/should likely also automatically do the same too. Again, note that young gen in G1 is really mostly about selecting the "best" regions for reclamation. You may notice most code in G1 is only interested in the collection set, not the young gen. > > As an aside, I have no bias for generational collectors but I have seen > > places where having a continuously running collector would have been very > > advantageous. For example, I had one case we had a hard 16ms time budget on > > bursts of fixed units of work. In that case the work could be completed in 5 > > or 6 ms which left 10ms for GC (should it decide to run and undoubtably > > would have run in the middle of the 5-6ms burst of work) but we could never > > get the collector to run consistently in under 10ms without risking an OOME. > > I’m pretty convinced that continuous collection policy would have helped us > > meet that goal and we had plenty of CPU to throw at the problem so…. I think another problem related to hardware is memory, not so much CPU. As you mention, there are typically always enough CPUs to throw at the problem. Increasing the amount of memory starting from a certain threshold gets comparatively expensive, and managing to have good memory bandwidth (at good latency) even more so. Others probably have more insight into that. I have exactly the same sentiments. In my experience, much Java code today is highly generational, and the increased headroom requirements of Shenandoah would limit its applicability at the ultra-large end of the heap size spectrum, especially when the allocation and death rates are very high. It seems to me that any collector that wants to support ultra-high allocation and death rates would have to be generational, to be competitive. On the other hand, Shenandoah might be targeting a different market where very low pause-times are more important, the object allocation and death rates are relatively moderate, and adding memory is still cheap because programs typically do not need very large heaps.

Echoing Thomas, and as mentioned in another email, I'd suggest that we might also want to explore a hybrid/generational version of Shenandoah, with a scavenging young generation collector and Shenandoah running in the old generation.

-- ramki -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20140121/b41c32a9/attachment.htm>

More information about the hotspot-gc-dev mailing list