Goroutine Leak Profiles
14 points by olex
14 points by olex
I have always thought that a go in a perfect world would garbage collect goroutines instead of leaking them.
If go were a completely different language based on structured concurrency that would be pretty easy, but because go went the exact opposite way and removed all notions of attachments it’s not that simple: goroutines are never linked to GC roots, nor do they even need to interact with the rest of the program per se, you could have a goroutine whose entire job is to make network calls to various services.
The explanation of a leak profiler is about what I’d expect for how you might garbage collect goroutines, and that’s a non trivial addition to the GC: find goroutines which are blocked on a synchronisation construct of which they’re the only GC root. But (as noted in the limitations section) this requires being able to recognise synchronisation primitives, as well as those synchronisation primitives being between goroutines and entirely within the system.