Bump allocation in the nursery <i>is</i> a huge advantage. There&#x27;s a reason why fast Go code goes out of its way to avoid allocations (notice that the benchmark tool contains an allocation profiler), and it&#x27;s because allocations are expensive when you don&#x27;t have a generational GC. If you do have a generational GC, then allocations are incredibly cheap: just a pointer bump and check. It&#x27;s like 4 or 5 instructions compared to the dozens in a typical malloc. With that kind of collector, you don&#x27;t have to spend nearly as much time tuning your program to avoid allocations. <i>This</i> is the reason why Java has been slow to add value types: when you have a bump allocator, they really aren&#x27;t needed as much (which is not to say they aren&#x27;t needed at all).<p>In the HotSpot VM, you can tune the GC to get any type of max garbage collection pause you want (-XX:MaxGCPauseMillis). This is basic functionality that <i>any</i> concurrent garbage collector supports. The downside, of course, is that pauses will happen more frequently, reducing throughput. That is why just saying &quot;it&#x27;s under 10 ms, so it&#x27;s really fast&quot; is very misleading: when your GC is interruptible, you can of course get any max pause time you want. But the GC may not be able to keep up with your allocation rate, and it may start being invoked too often. That&#x27;s why you need to not just look at latency, but throughput--something that sound bites won&#x27;t capture.