<aside> 💡
Go 1.25
JSON evolution in Go: from v1 to v2
Green Tea GC: How Go Stopped Wasting 35% of Your CPU Cycles
</aside>
Go 1.25’s experimental garbage collector stops CPU stalls by organizing memory into neighborhoods instead of random object jumping
Your Go application is performing well, handling requests efficiently. But there’s a performance issue you might not be aware of- the garbage collector is wasting 35% of CPU cycles waiting for memory access. Every time the GC jumps between objects scattered across RAM, your CPU sits idle while data is retrieved from memory
Green Tea GC, Go’s experimental new garbage collector reduces this waste by upto 50%. The garbage collector is available as an experiment in the upcoming Go 1.25, expected to be released in August 2025.
Before we dive into how Green Tea works, here’s a quick refresher on Garbage Collectors -
Any program typically allocates objects on two types of memories, Stack and Heap. Stack memory is generally easy to manage and clean (references are dropped along with frames after the work is done), while some other objects like constants live on the Heap.
In the early days of programming, programmers used to manage memory on their own (remember malloc from C?). This meant that if the memory wasn’t freed after use, it lead to memory leaks and if you freed twice, a crash.
Then came Garbage Collectors, popularized by languages like Java, JS (V8). The idea was novel, instead of allocating and deallocating by hand, the runtime would manage the memory instead.
The compiler can also figure out which objects go to the heap, which objects stay on the stack. This is called Escape Analysis.
Early Garbage Collection algorithms were quite naive like “Stop The World”. STW completely halts the execution of the program to run a collection cycle. This guarantees that new objects are not allocated or the references are not changed when the collector is running.
But this meant that the program pauses for long duration, sometimes even for seconds(!) when the GC is running. This was a cause for concern in high availability applications like web servers.
Concurrent Garbage Collectors allow for garbage collection to occur at the same time when the application is running, minimizing pauses and improving performance, especially in real-time systems. They are designed to reduce “stop-the-world” pauses, where the application is halted entirely for garbage collection.
But these have a higher CPU overhead and implementation complexity — if this runs for a longer duration one cannot guarantee prohibition of new object allocations or reference changes.