Go's Green Tea GC Is Already in Production at Google — Here's Why That Matters
Source: go
Go 1.25 quietly shipped something worth paying attention to: a new experimental garbage collector called Green Tea, enabled via GOEXPERIMENT=greenteagc at build time. The headline number is a reduction of up to 40% in time spent in the GC for certain workloads, with many workloads seeing around 10%. The Go team has already rolled it out internally at Google, which is a stronger signal than “experimental” might imply.
The full technical writeup is on the Go blog, based on Michael Knyszek’s GopherCon 2025 talk. It’s worth reading in full if you care about runtime internals.
How Go’s GC Actually Works
To appreciate what Green Tea changes, it helps to understand what the existing GC is doing. Go uses a concurrent, tri-color mark-and-sweep collector. The runtime traces the heap starting from roots (globals, goroutine stacks), marks reachable objects, and then sweeps unreachable ones back into free lists.
The key concept here is the distinction between objects and spans. An object is a single allocated Go value on the heap. A span is a contiguous range of memory pages that holds objects of the same size class. The existing GC tracks liveness at the object level — it needs to know which individual objects are alive before it can reclaim anything.
What Green Tea Changes
Green Tea shifts some of the tracking from the object level to the span level. Instead of recording fine-grained per-object metadata, it reasons about which spans are worth scanning in the first place. This reduces the overhead of the mark phase and cuts down on the bookkeeping the GC has to do on every allocation.
The practical effect is less time burning CPU cycles on GC work that doesn’t directly free memory. For workloads with lots of short-lived small allocations — which describes a wide range of web services and data pipelines — this is a meaningful win.
Should You Try It Now?
If you’re running Go services in production, yes, it’s worth benchmarking. The flag is straightforward:
GOEXPERIMENT=greenteagc go build ./...The Go team is explicit that not every workload benefits equally, and some see minimal improvement. That’s why they want real-world feedback before flipping it on by default in Go 1.26. If your service shows a meaningful improvement, they want to hear about it on the existing Green Tea issue. If something breaks, file a new issue.
The fact that this is already running at Google’s scale gives me confidence it’s not going to surprise you with correctness bugs. The risk here is performance variance, not heap corruption.
The Bigger Picture
Go’s GC has historically been one of the more conservative parts of the runtime — the team has been cautious about trading latency predictability for throughput. Green Tea seems to thread that needle well: better average-case throughput without sacrificing the low-pause-time guarantees that make Go appealing for latency-sensitive services.
A 40% reduction in GC overhead for some workloads is not a small thing. If the broad rollout data holds up, making this the default in 1.26 seems like an easy call.