Go 1.26 ships Green Tea GC by default — and you can watch it work

Go 1.25 introduced a new garbage collector called Green Tea, and Go 1.26 promoted it to the default. The collector is designed for cache-friendliness, and its behavior can be observed directly with perf and by visualizing the heap. Go’s allocator, a descendant of tcmalloc, groups objects into size classes and packs same-sized objects into contiguous spans of 8KiB pages, so even a randomized mix of small, medium, and large allocations ends up neatly segregated by size in the address space.

A short demo program allocates 100 objects of three sizes, then walks the address space printing a character per 32 bytes to render an ASCII map of the heap. Running it before and after a forced collection produces identical layouts, illustrating Go’s defining trait: it never moves live objects. The same experiment written in C# behaves differently, because .NET uses a compacting collector that relocates objects during collection.

That non-moving design is also Go’s persistent weakness. Because the collector can’t relocate live objects to consolidate them, memory can fragment into sparse pages — pages holding only a few live objects that the runtime cannot reclaim or hand back. The article probes exactly this failure mode, showing where Green Tea’s cache wins pay off and where the underlying non-moving architecture still leaves memory stranded.