I've been running a few hundred nodes with Shenandoah on Java 17 for the last year, and while I can say it's been mostly nice it still has some issues. While pause times are definitely better than G1 (typically < 3ms), Shenandoah isn't generational, so there's quite a bit of overhead from GC when the allocation rate is high. Shenandoah achieves low pause time by throttling the allocator (pacing). Since we allocate a *ton* during compaction, we need to use huge heaps to compensate. I've seen pacing take up 35% of CPU time when profiling a cluster with perf issues.
<mildly off topic rant> Generational ZGC should be a significant improvement, but it's not a silver bullet. I'd classify it as more of a crutch to mitigate the excessive allocation found in our read and compaction paths. Addressing a small handful of unnecessary allocations would allow us to run much smaller heaps while also reducing pause time (both median and at the tail) and significantly overall throughput. Every allocation results in a CPU stall, inflates the side of the live set and adds overhead to every collection. I love the improvements in new collectors but I've found that people sometimes massively overestimate what they can do for us and use it as an excuse to abdicate from responsible memory management. See CASSANDRA-20428 [1] for an example of an allocation in the hot path that if we addressed would *massively* improve pause times and throughput. To the future, newer JDK's have off heap Arenas [2], Memory Segments, Memory Layouts and Structured access [3]. Leaning into that would allow us to almost completely eliminate every single on-heap allocation, giving us the ability to run C* on tiny heaps and have practically zero GC. If we did that the collector an operator picks wouldn't matter at all, because the collector would almost never run. Feel free to branch this into a new discussion if you want to go down this rabbit hole with me :) </mildly off topic rant> Jon [1] https://issues.apache.org/jira/browse/CASSANDRA-20428 [2] https://docs.oracle.com/en/java/javase/21/core/memory-segments-and-arenas.html [3] https://docs.oracle.com/en/java/javase/21/core/memory-layouts-and-structured-access.html On Tue, Nov 11, 2025 at 7:29 AM Josh McKenzie <[email protected]> wrote: > > - [Must have] Minimum JDK21 support on 4.1 and higher > > Is this purely due to genZGC? While it's playing very nicely so far, I > would expect the gap between tuned G1 and genZGC to be less than tuned CMS > and genZGC. > > @Jon Haddad - got any insight on the above (CMS vs. G1 vs. shenandoah vs. > genZGC)? > > fwiw - I think backporting the ability to run on JDK21 (or any newer JDK > tbh) should be pretty simple and a favorable cost/benefit. Just want to > explore if it's just the GC in the new JDK or something else at runtime > people are looking for. > > On Fri, Oct 31, 2025, at 2:14 PM, Jaydeep Chovatia wrote: > > > - [Must have] Minimum JDK21 support on 4.1 and higher > - > > >
