2 ms·
>Not according to the transactional collector proposal. That's hardly the end all of Go GC development, also as I understand it's not even certain it will be u
by gribbly 10y ago
>Not according to the transactional collector proposal.
That's hardly the end all of Go GC development, also as I understand it's not even certain it will be used in a Go release as it depends on it actually showing the benefits aren't just theorethical.
>Whether generational GC works is something we've had over 30 years to figure out, and the answer has consistently been a resounding "yes, it works, and works well".
This was not about generational GC's 'working' or not, it was if it is the best solution for the typical workloads of Go applications.
- tptacek 10y agoSpeaking as someone who works in Go full-time and really likes it: kind of the whole point of Go is that it's workloads are very much like every other language.
- gribbly 10y agoI figured the wide use of goroutines would be the cause for different choices in Go's GC compared to other GC's for languagues not sharing that characteristic. From what I understand, the upcoming transactional collector is written directly with Go's goroutines in mind.
- pcwalton 10y ago> From what I understand, the upcoming transactional collector is written directly with Go's goroutines in mind. I'm pretty skeptical that it will produce wins over a traditional generational GC. At best the "transactional hypothesis" will roughly approximate the generational hypothesis, without the primary benefit that truly generational GC gives you, namely bump allocation in the nursery. Time will tell.