It's not about fragmentation. It's about allocation throughput.
> Bump allocation is efficient and fast in single threaded programs but almost all Go applications are multi threaded and it would require locks there. Go is using thread local caches for allocation, that's why there is no point in using bump allocation.
No production bump allocator takes locks!
> This was mentioned many times by the Go team.
Yes, and my view is that they're coming to incorrect conclusions.
> Golang have value types (which Java do not have atm, but Valhalla is coming) and allocate on the stack based on escape analysis (which gets better with time).
1. .NET has value types, and in that runtime the generational hypothesis certainly holds and therefore .NET has a generational garbage collector.
2. Java HotSpot has escape analysis too (and the generational hypothesis still holds). It's primarily for SROA and related optimizations, though, not for allocation performance. That's because, unlike Go, HotSpot allocation is already fast.
> This means that adding generational GC would not benefit Go as much as you think.
I have yet to see any evidence that bump allocation in the nursery would not help Go.
> Go GC main focus is very low latency, not throughput and handling huge heaps with a lot of generations is not so easy with HotSpot.
And for most applications, balancing throughput and latency is more desirable than trading tons of throughput for low latency.
> In many cases you need to tune GC in Java because of that.
The default GC in Java HotSpot has one main knob, just as Go does. Actually, the knob is better in Java, because "max pause time" is easier to understand than SetGCPercent.
