Watching Go's new garbage collector move through the heap

Go’s memory cleanup got a glow-up, but commenters are stuck on the weird ending and DIY fixes

TLDR: Go’s newer memory cleanup system is now the default, and it can improve some programs — but it still struggles to reclaim scattered leftover space. In the comments, readers were split between “cool demo,” “why did the article end like that,” and “are we seriously hand-cleaning memory now?”

Go, the programming language loved for being fast and practical, just made its memory cleanup system the default in newer versions — and the article walked readers through a visual demo showing how pieces of data sit in memory before and after cleanup. The big reveal? In some cases, the cleanup is better, but it still has an awkward limitation: it can leave behind half-empty chunks it can’t fully tidy up. That’s the kind of detail that gets performance obsessives leaning in — and the comments immediately turned into a mix of curiosity, skepticism, and comedy.

The loudest reaction was not even about the code at first — it was about the ending. Multiple readers called it strangely cut off, saying it felt like the article got yanked away by a subscribe banner right when things were getting juicy. One commenter basically said, “Wait, that’s it?” and others echoed the same baffled energy. So yes, the garbage collector wasn’t the only thing leaving leftovers.

Then came the real nerd drama: should developers manually move data around to help Go free memory better? One commenter dropped a gloriously cursed “optimization technique” — copying objects into a new list so old memory pages can finally be released — which is either a clever hack or the kind of thing that makes purists stare into the void. Another pushed back with a practical “aren’t we just wasting time then?” Meanwhile, someone else skipped the debate entirely and posted a YouTube link, the universal comment-section move for “I’m not explaining this, watch homework.”

Key Points

  • Go 1.25 introduced the Green Tea garbage collector, and Go 1.26 made it the default.
  • The article states that Go allocates objects by size class into contiguous spans made of one or more 8 KiB pages.
  • It identifies a residual limitation of Go’s non-moving garbage collector: sparse pages cannot always be reclaimed.
  • The article presents pseudocode and a Go program that allocate 32-byte, 64-byte, and 128-byte objects, record their heap addresses, and print a textual heap map.
  • The Go example shows that forcing garbage collection with `runtime.GC()` does not move objects, so the heap layout remains the same across passes.

Hottest takes

"a bit abrupt" — nomorewords
"manually copying objects to a new slice" — okzgn
"aren’t we just wasting time" — extra-AI
Made with <3 by @siedrix and @shesho from CDMX. Powered by Forge&Hive.