Low-Latency, High-Throughput Garbage Collection [pdf]
Thanks. Just finished reading the whole paper.<p>Thoughts in no particular order:<p>• A very impressive tour de force. To implement a GC in OpenJDK is hard, to come in competitive with G1 out of the gate doubly so. The approach is a very clever hybrid of both classical GC and RC techniques. They aimed to reinvigorate GC research and appear to have achieved this goal.<p>• Although advertised as low latency their pause times are comparable to G1. SOTA low latency collection is now &lt;1msec and still falling. Their benchmarks don&#x27;t really show this because they appear to be overdriving both ZGC and Shenandoah, which then totally collapse (e.g. &gt;800msec pauses) due to the lack of generational collection making it hard for them to keep up with high allocation rates. This is an acknowledged limitation which at least the ZGC developers are working on removing, probably Shenandoah devs too, but the authors only mention this in one sentence right at the end.<p>In fairness they obviously cannot benchmark against unreleased versions of ZGC, but equally, I was expecting&#x2F;hoping to see benchmarks run at allocation rates that ZGC&#x2F;Shenandoah are actually rated for today. What they&#x27;re mostly proving here is that you need generational collection to handle high throughputs on allocation heavy benchmarks like lusearch, rather than anything special about LXR specifically.<p>• It would have been nice to see a deeper dive of heap overheads and locality. Traditionally the place RC gets used is in consumer electronics &#x2F; desktop apps, where you need very stable memory locality and predictable heap management overheads to avoid swapping&#x2F;spikeyness. What they&#x27;re doing here is sort of half-GC, half-RC and it&#x27;s not really clear to what extent this would make LXR more appropriate for things like desktop apps. It&#x27;d be interesting to see a benchmark of &quot;normal&quot; apps like IntelliJ where the host OS is deliberately pushed into swapping, then seeing if there&#x27;s a major performance gap. In theory LXR should win because objects don&#x27;t move around as much but they don&#x27;t seem to have tested that.<p>• Relatedly, the question I&#x27;m left with is this: OK, you&#x27;ve got roughly similar perf to G1 but with fewer features. That&#x27;s kind of impressive from a coding perspective <i>but</i> from an end user perspective, where&#x27;s the competitive advantage? The opening discussion mentions simplicity in the first paragraph, but no LOC comparisons are provided so it&#x27;s not obvious that LXR is&#x2F;would be simpler than G1 when feature parity is achieved. It mentions LXR will provide &quot;sufficient responsiveness&quot; without concurrent evacuation, but the whole reason ZGC&#x2F;Shenandoah were developed was because for some use cases G1 level pause times - even though they&#x27;re usually quite low - were not considered sufficient.<p>Overall I&#x27;m wondering if the OpenJDK guys will really want to merge this. For the generic good throughput, reasonably-but-not-insanely-low-pauses market they have G1 which is mature and feature complete. For the markets like HFT where they need pauses so low they may well not exist, but aren&#x27;t spamming the collector, they have ZGC. Soon they&#x27;ll have generational ZGC which will ramp the throughput capabilities of ZGC significantly and should prevent collapses like those in the paper, whilst still maintaining sub-1msec pause times.<p>Integrating and maintaining a new GC is a big effort because they touch so many parts of the system. Without some obviously killer advantage, it may require external maintenance. Maybe better ergonomics on desktop systems where much of the app is paged out can provide this?