But I’m only arguing that the Go GC design is suboptimal. I’m not trying to argue that it doesn’t work at all. My problem is that people don’t realize that it’s suboptimal. We’re forgetting all the lessons we learned in the ‘90s, which is tragic.
-
-
Your criticism of Go would be more interesting if you chatted with the team. rlh@ proposed a generational collector years ago, and has been trialling it in parallel with ROC for the past year. E.g. https://go-review.googlesource.com/c/go/+/105367
1 reply 0 retweets 2 likes -
Replying to @davidcrawshaw @pcwalton and
He and Austin have been distracted by a fact that has changed since the 90s: server tail latency matters so much Go customers are willing to throw away huge amounts of CPU to remove it. Hence generational is low priority, and the focus has been low pause. It's customer driven.
3 replies 1 retweet 6 likes -
If you had a properly architected generational GC, you’d sacrifice a *tiny* amount of latency for huge throughput gains. Bump allocation in the nursery is such a huge benefit it’s virtually never worth throwing it away. That’s why Azul’s ultra-low-latency GC is generational.
1 reply 0 retweets 0 likes -
Azul and Baker (who sat a few desks away from me in NYC) have discussed these issues with them. I'm sure you've heard the escape analysis argument, but that's why bump allocation is lower priority. It's still on the list, gri@ complained about it in a dart comparison years ago.
1 reply 0 retweets 0 likes -
Then it sounds like we agree that concurrent generational GC is the way to go!
1 reply 0 retweets 0 likes -
As long as all your global and per-thread pauses are sub-100-microseconds, sure. I don't personally have much need for generational though I agree there are some programs that need it. I certainly don't think Go is broken for putting it off.
2 replies 0 retweets 1 like -
Replying to @davidcrawshaw @pcwalton and
I have other GC concerns, that I would happily sacrifice generational and other features for. How will GC scale in a 1000 core programs with a relatively-flat 100 TB heap? We may reach a point where even a nominal STW is too expensive. Do we have to segment heaps at some point?
3 replies 0 retweets 1 like -
Before you can imagine that a lot of other things have to change in Go. It's current concurrency model, for example, would need substantial retrofitting. By that time we'd probably be justified in demanding Go support multiple collectors and tunable strategies.
1 reply 0 retweets 0 likes -
The implementation would need tweaking, but I do not believe the presented concurrency semantics need to change. What matters are process-global synchronization points that can't be sharded behind the scenes. Widely-sharable heap may have to. (*May* This is hand-waving theory.)
2 replies 0 retweets 1 like
Yeah, I think it’d be instructive to look at languages like CUDA, which already has to deal with this kind of thing (threadgroup local vs. thread local vs. global). As is often the case, game/GPU devs are beyond us in the “normal” software world :)
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.