Hacker News Reader

Comment by pcwalton | Hacker News Reader

This is a case in which generational GC can help. If you allocate goroutine stacks in the nursery, then you can use a bump allocator, which makes the throughput extremely fast. Throughput of allocation matters just as much as latency does!

(By the way, Rust used to cache thread stacks back when it had M:N threading, because we found that situations like this arose a lot.)

View on HN

You can't bump-allocate 6K contiguous to an existing 2K allocation, and Go currently requires the stack to be contiguous.

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.

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.

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.

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.

It might make allocation a bit faster, but is this really where performance was lost?

I guess for the runtime it is more expensive to copy the stack contents (so nearly 2K) and e.g. update pointers in it (a simple memcpy might not be enough).

Reply on news.ycombinator.com