Distilling the Real Cost of Production Garbage Collectors · HackerPapers discussions

Distilling the Real Cost of Production Garbage Collectors — mentioned by yvdriess

Thu, 26 Feb 2026 20:48:21 GMT

The problem is that there is no baseline for measuring GC overhead. You cannot turn it off, you can only replace and compare with different strategies. For example sbrk is technically a noop GC, but that also has overhead and impact because it will not compact objects and give you bad cache behavior. (It illustrates the OP's point that it is not enough to measure pauses, sbrk has no pauses but gets outperformed easily.) You could stop collecting performance counters around GC phases, but you even if you are not measuring the CPU still runs through its instructions, causing the second order…

Paper and discussion history. A mention is not an endorsement.

Distilling the Real Cost of Production Garbage Collectors — mentioned by pkolaczk

Wed, 10 Aug 2022 06:03:16 GMT

That's a common wisdom, but there is little if any evidence to support it. True GC costs are simply more hidden and harder to measure. A malloc/free pair might be slightly slower than Java's new (not by much really - go measure), but invoking `new` is not the only cost of GC. https://arxiv.org/abs/2112.07880 Also modern low pause GCs have way higher CPU overhead than the old STW ones. Try to set a low pause GC pause target to 0.1 ms or set the heap limit to 110% of live memory and see what happens to CPU consumption. Last time I tried, the app didn't even start - got OOM nearly instantly.…

Paper and discussion history. A mention is not an endorsement.

Distilling the Real Cost of Production Garbage Collectors — HN submission

Thu, 16 Dec 2021 19:39:37 GMT

An Empirical Lower Bound on the Overheads of Production Garbage Collectors

15 points; 0 discussion replies on HN. Paper and source history. A submission is not an endorsement.