Visualizing Go's Green Tea Garbage Collector and Its Heap Behavior
Watching Go's new garbage collector move through the heap
I explore how Go 1.26's default Green Tea garbage collector organizes memory by grouping objects of similar sizes, contrasting this with C#'s more scattered approach. Using custom tools, I visualize the heap to demonstrate Go's non-moving allocation strategy and highlight a specific challenge where sparse pages remain unreclaimed, revealing both the efficiency and limitations of this new collector.
Go's non-moving collector cannot reclaim sparse pages.
- nomorewords
This was very interesting, but the ending was a bit abrupt. I was under the impression that there was something more that I was missing under the subscribe banner.
But to the point of the article - are there cases in which manually moving objects around to compact them in a specific area is done with golang? I don't use golang that much, and I'm sure that there are very strong arguments for not compacting the heap post-GC, but I've always wondered how it avoids crashing in the 0.0001% of cases in which heap is defragmented in such a way that there's no way to allocate a new large object
- okzgn
Excellent optimization technique: manually copying objects to a new slice so they don't prevent the GC from releasing memory by sitting right in the middle of a page it intends to free.
- owaislone
For anyone interested in this - https://www.youtube.com/watch?v=gPJkM95KpKo