Hacker News Reader

That's right, but you can bump-allocate a new 6K and copy over. It's a lot faster than falling through to a general-purpose malloc implementation.

View on HN

That’s not obviously true. Page sized and page aligned allocation is pretty fast in Go. Having a generational GC where all pointers are movable could have systemic impact in the performance of the whole program.

If it were fast enough, then caching stacks wouldn't be a win. Bump allocation is like 6 instructions.

The idea that generational GC would not be a win does not match the experience of any other language. Generational GC is virtually always a win for languages like Go. This is just another reason why Go should adopt it.

It's possible. Go has been replaying the entire history of GC research at about 2.5x forward speed. They should intercept the state of the art eventually.

Isn't it a win because the goroutine now starts with 4K of stack instead of 2K? This makes the stack large enough, such that the stack doesn't have to expanded on every request.

Reply on news.ycombinator.com