{"slug": "zgc", "name": "ZGC", "category": "other", "category_name": "Other software", "description": "", "recommenders": 5, "commenters": 7, "warners": 0, "score": 5.008, "rising": 0.69, "first": "2026-02-26", "latest": "2026-10-27", "why": "you probably want ZGC (or Shenandoah) because latency is more important than throughput.", "why_is_quote": true, "has_verdict": false, "sentiment": {"recommend": 6, "neutral": 0, "compare": 2, "warn": 0}, "spark": [0, 0, 0, 1, 0, 0, 1, 2, 0, 1, 0, 1], "listed": true, "loved": [], "caveat": "", "short_quote": "you probably want ZGC (or Shenandoah) because latency is more important than throughput.", "kind": "", "icon": true, "domain": "openjdk.org", "github_repo": null, "official_url": "https://wiki.openjdk.org/display/zgc", "pricing": "", "aliases": ["ZGC"], "verdict": null, "praise": [{"label": "", "summary": "", "quotes": [{"id": 804187360, "item_id": 50261710, "url": "https://news.ycombinator.com/item?id=50261710", "by": "cogman10", "date": "2026-10-27", "version": null, "stance": "recommend", "quote": "now they are pretty much best in class", "excerpt": "So, I'd grant that it'd probably be a JEP for java (the initial JIT) but not that every change to the JIT would result in a new JEP. Java's JIT, hotspot, was integrated right before they started the JEP process. The JEP for the JIT would likely be pretty boring like \"It's a JIT, it does this, in some applications we see this sort of speed up\". Much like the AOT JEP https://openjdk.org/jeps/514 The Java governance all", "context": "", "use_case": "", "switched_from": "", "story": "Python's experimental JIT to be removed"}, {"id": 788679984, "item_id": 49292499, "url": "https://news.ycombinator.com/item?id=49292499", "by": "pron", "date": "2026-08-13", "version": null, "stance": "recommend", "quote": "ZGC for interactive applications where latency matters a lot", "excerpt": "> you just do all that manual work with environment variables You really don't anymore. For the past several years, Java's GCs mostly pick the right settings automatically, except for heap size, which will be taken care of soon (https://openjdk.org/jeps/8377305). The reason heap size isn't automatic is that with moving collectors it determines the CPU/RAM tradeoff, and doing that in a more natural way isn't trivial, ", "context": "", "use_case": "", "switched_from": "", "story": "JDK 27 G1/Parallel/Serial GC Changes"}, {"id": 787635713, "item_id": 49227232, "url": "https://news.ycombinator.com/item?id=49227232", "by": "pron", "date": "2026-08-08", "version": null, "stance": "recommend", "quote": "ZGC, probably the world's most sophisticated moving collector", "excerpt": "> I've written two separate moving collectors for dynamic language runtimes, as well as done significant work in realtime 3D graphics That's nice. I have ~25 years of experience with large C++ software, including hard and soft realtime systems, and I now work on the JVM. > I mean .. sure, but, a copying GC eats somewhere on the order of 10% of your total memory bandwidth just copying shit around Good moving collector", "context": "", "use_case": "", "switched_from": "", "story": "Show HN: Wyzer Programming Language"}, {"id": 779095600, "item_id": 48693475, "url": "https://news.ycombinator.com/item?id=48693475", "by": "pron", "date": "2026-06-26", "version": null, "stance": "recommend", "quote": "it will automatically get to enjoy that amazing GC", "excerpt": "https://www.taylorfrancis.com/books/mono/10.1201/9781003595366/garbage-collector-erik-\u00f6sterlund Note that this is a pretty new technology. The first production-quality \"pauseless\" moving collector was released in 2010 by Azul, but it was proprietary. The first open source implementation (that was also generational) was in JDK 21 (https://openjdk.org/jeps/439), i.e. it's less than three years old. The book I linked to", "context": "", "use_case": "Automatic memory management", "switched_from": "", "story": "The Garbage Collection Handbook: The Art of Automatic Memory Management (2nd Ed)"}, {"id": 779059744, "item_id": 48691234, "url": "https://news.ycombinator.com/item?id=48691234", "by": "quotemstr", "date": "2026-06-26", "version": null, "stance": "recommend", "quote": "ZGC is extremely good work.", "excerpt": "ZGC is extremely good work. https://wiki.openjdk.org/spaces/zgc/pages/34668579/Main > ZGC performs all expensive work concurrently, without stopping the execution of application threads for more than a millisecond. It is suitable for applications which require low latency. Pause times are independent of the heap size that is being used. ZGC works well with heap sizes from a few hundred megabytes to 16TB. Go's GC is a", "context": "", "use_case": "", "switched_from": "", "story": "Gossamer: a Rust-flavoured language with real goroutines and pause-free memory"}]}], "caveats": [], "who": [], "tags": [], "use_cases": ["low-latency java gc", "automatic memory management", "jvm garbage collection"], "compared": [], "makers": [], "threads": [{"url": "https://news.ycombinator.com/item?id=49289101", "title": "JDK 27 G1/Parallel/Serial GC Changes", "mentions": 2}, {"url": "https://news.ycombinator.com/item?id=50257419", "title": "Python's experimental JIT to be removed", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=49695331", "title": "High-performance garbage collection for C++", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=49209385", "title": "Show HN: Wyzer Programming Language", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=48680370", "title": "The Garbage Collection Handbook: The Art of Automatic Memory Management (2nd Ed)", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=48690231", "title": "Gossamer: a Rust-flavoured language with real goroutines and pause-free memory", "mentions": 1}], "sentiment_by_month": {"2025-11": {}, "2025-12": {}, "2026-01": {}, "2026-02": {"recommend": 1}, "2026-03": {}, "2026-04": {}, "2026-05": {"recommend": 1}, "2026-06": {"recommend": 2}, "2026-07": {}, "2026-08": {"recommend": 1, "compare": 1}, "2026-09": {"compare": 1}, "2026-10": {"recommend": 1}}, "versions": [], "version_unnamed": 0, "family_ref": null, "runs_on": null, "lines": [], "quotes": [{"id": 804187360, "item_id": 50261710, "url": "https://news.ycombinator.com/item?id=50261710", "by": "cogman10", "date": "2026-10-27", "version": null, "stance": "recommend", "quote": "now they are pretty much best in class", "excerpt": "So, I'd grant that it'd probably be a JEP for java (the initial JIT) but not that every change to the JIT would result in a new JEP. Java's JIT, hotspot, was integrated right before they started the JEP process. The JEP for the JIT would likely be pretty boring like \"It's a JIT, it does this, in some applications we see this sort of speed up\". Much like the AOT JEP https://openjdk.org/jeps/514 The Java governance all", "context": "", "use_case": "", "switched_from": "", "story": "Python's experimental JIT to be removed"}, {"id": 795444801, "item_id": 49715300, "url": "https://news.ycombinator.com/item?id=49715300", "by": "pebal", "date": "2026-09-15", "version": null, "stance": "compare", "quote": "On binary-trees at depth 21, ZGC is ahead on one thread (2.5 s vs 4.5 s)", "excerpt": "I've spent the last few years on a library-only collector for C++ (SGCL, https://github.com/pebal/sgcl), also non-moving, so a few data points on the \"can it compete\" question. Disclosure up front: my project, and measured so far only on Apple Silicon/macOS, one machine, nothing tuned. On the sweep: it's true that a non-moving collector's sweep is proportional to the number of dead objects, and a moving one's isn't. ", "context": "", "use_case": "", "switched_from": "", "story": "High-performance garbage collection for C++"}, {"id": 788696320, "item_id": 49293520, "url": "https://news.ycombinator.com/item?id=49293520", "by": "hedora", "date": "2026-08-13", "version": null, "stance": "compare", "quote": "suggests they\u2019re still off by an order of magnitude", "excerpt": "Does it provide hard latency bounds like Azul does (did?), and are they lower than disk/network latencies on modern hardware? I moved to c++/rust years ago because those languages do, and tens of milliseconds matter for network services. At the time Java could pause for 10\u2019s of seconds, which was 1000x worse than waiting for a spinning disk to seek. These days, disks are 100s micros to single digit millis, so I guess", "context": "moved to C++/Rust for latency-sensitive network services", "use_case": "low-latency Java GC", "switched_from": "", "story": "JDK 27 G1/Parallel/Serial GC Changes"}, {"id": 788679984, "item_id": 49292499, "url": "https://news.ycombinator.com/item?id=49292499", "by": "pron", "date": "2026-08-13", "version": null, "stance": "recommend", "quote": "ZGC for interactive applications where latency matters a lot", "excerpt": "> you just do all that manual work with environment variables You really don't anymore. For the past several years, Java's GCs mostly pick the right settings automatically, except for heap size, which will be taken care of soon (https://openjdk.org/jeps/8377305). The reason heap size isn't automatic is that with moving collectors it determines the CPU/RAM tradeoff, and doing that in a more natural way isn't trivial, ", "context": "", "use_case": "", "switched_from": "", "story": "JDK 27 G1/Parallel/Serial GC Changes"}, {"id": 787635713, "item_id": 49227232, "url": "https://news.ycombinator.com/item?id=49227232", "by": "pron", "date": "2026-08-08", "version": null, "stance": "recommend", "quote": "ZGC, probably the world's most sophisticated moving collector", "excerpt": "> I've written two separate moving collectors for dynamic language runtimes, as well as done significant work in realtime 3D graphics That's nice. I have ~25 years of experience with large C++ software, including hard and soft realtime systems, and I now work on the JVM. > I mean .. sure, but, a copying GC eats somewhere on the order of 10% of your total memory bandwidth just copying shit around Good moving collector", "context": "", "use_case": "", "switched_from": "", "story": "Show HN: Wyzer Programming Language"}, {"id": 779095600, "item_id": 48693475, "url": "https://news.ycombinator.com/item?id=48693475", "by": "pron", "date": "2026-06-26", "version": null, "stance": "recommend", "quote": "it will automatically get to enjoy that amazing GC", "excerpt": "https://www.taylorfrancis.com/books/mono/10.1201/9781003595366/garbage-collector-erik-\u00f6sterlund Note that this is a pretty new technology. The first production-quality \"pauseless\" moving collector was released in 2010 by Azul, but it was proprietary. The first open source implementation (that was also generational) was in JDK 21 (https://openjdk.org/jeps/439), i.e. it's less than three years old. The book I linked to", "context": "", "use_case": "Automatic memory management", "switched_from": "", "story": "The Garbage Collection Handbook: The Art of Automatic Memory Management (2nd Ed)"}, {"id": 779059744, "item_id": 48691234, "url": "https://news.ycombinator.com/item?id=48691234", "by": "quotemstr", "date": "2026-06-26", "version": null, "stance": "recommend", "quote": "ZGC is extremely good work.", "excerpt": "ZGC is extremely good work. https://wiki.openjdk.org/spaces/zgc/pages/34668579/Main > ZGC performs all expensive work concurrently, without stopping the execution of application threads for more than a millisecond. It is suitable for applications which require low latency. Pause times are independent of the heap size that is being used. ZGC works well with heap sizes from a few hundred megabytes to 16TB. Go's GC is a", "context": "", "use_case": "", "switched_from": "", "story": "Gossamer: a Rust-flavoured language with real goroutines and pause-free memory"}, {"id": 769689217, "item_id": 48105576, "url": "https://news.ycombinator.com/item?id=48105576", "by": "munksbeer", "date": "2026-05-12", "version": null, "stance": "recommend", "quote": "you just rely on ZGC to do its thing, and it works", "excerpt": "Disclaimer: I love writing production systems in Java. I was a C++ programmer for 10 years before moving to Java about 15 years ago. Java offers a virtually all in one package when writing large systems. You have a single language where you can write code that doesn't care to be the fastest possible, and you just rely on ZGC to do its thing, and it works. Or you can write GC free code with a mostly quite performant S", "context": "", "use_case": "", "switched_from": "", "story": "If AI Writes Your Code, Why Use Python?"}, {"id": 754627616, "item_id": 47164226, "url": "https://news.ycombinator.com/item?id=47164226", "by": "noelwelsh", "date": "2026-02-26", "version": null, "stance": "recommend", "quote": "you probably want ZGC (or Shenandoah) because latency is more important than throughput.", "excerpt": "There are a few ways of looking at this: - Purely on the JVM, you probably want ZGC (or Shenandoah) because latency is more important than throughput. - On Erlang / the BEAM VM, each thread gets its own private heap, so GC is a per thread operation. If the request doesn't spill over the heap then GC would never need to run during a request handler and all memory could be reclaimed when the handler finishes. - There c", "context": "", "use_case": "JVM garbage collection", "switched_from": "", "story": "Dissecting the CPU-Memory Relationship in Garbage Collection (OpenJDK 26)"}]}