[KongchangAI]
Research· 2 min read· 1,004 words

Go 1.25 Experimental Garbage Collector Green Tea Explained

Go 1.25 Experimental Garbage Collector Green Tea Explained

Go 1.25 introduces experimental garbage collector Green Tea, exploring fundamental GC architecture changes.

Go 1.25 will include an experimental garbage collector called Green Tea, aimed at addressing throughput bottlenecks of the existing concurrent tri-color mark-and-sweep algorithm in high-allocation-rate scenarios. Developers can enable it at compile time with GOEXPERIMENT=greentea without affecting default behavior. The GC may adopt new approaches such as generational collection and region-based memory management, and is expected to bring improvements in high-concurrency, memory-intensive, and latency-sensitive scenarios.

Overview

Go 1.25 will include a brand-new experimental garbage collector — Green Tea. This represents a significant exploration in Go's runtime system, signaling the Go team's continued commitment to innovation in memory management.

Go 1.25 Green Tea Garbage Collector

What Is the Green Tea Garbage Collector

The Evolution of Go's Garbage Collection

Since its inception, Go's garbage collector (GC) has undergone several major iterations:

  • Go 1.0–1.4: Stop-the-world mark-and-sweep, with pause times reaching hundreds of milliseconds
  • Go 1.5: Introduced concurrent tri-color mark-and-sweep algorithm, reducing pause times to the millisecond range
  • Go 1.8+: Continuous optimization of write barriers and scheduling strategies, compressing pause times to the microsecond level
  • Go 1.19: Introduced the soft memory limit GOMEMLIMIT, providing finer-grained memory control

The tri-color mark-and-sweep algorithm is a milestone in modern GC design. It classifies heap objects into three categories: white (unvisited), gray (discovered but children not yet scanned), and black (fully scanned). GC threads run concurrently with user threads, using a write barrier mechanism to ensure correctness during the marking phase. The write barrier is triggered every time the program modifies a pointer, recording changes in reference relationships and preventing the GC from missing live objects. The hybrid write barrier introduced in Go 1.8 greatly simplified this process, compressing the final STW (Stop-The-World) phase to the microsecond level — this is the fundamental reason Go's GC is renowned for its extremely low pause times.

However, the write barrier itself introduces additional CPU overhead, and Go's current GC does not support generational garbage collection — that is, leveraging the observation that "most objects have very short lifetimes" to prioritize collecting young-generation objects and reduce the scope of full-heap scans. This is considered one of the main reasons Go's throughput is limited in high-allocation-rate scenarios. Green Tea is the experimental solution designed to address these deep-rooted bottlenecks.

Green Tea's Design Philosophy and How to Enable It

Green Tea is introduced in Go 1.25 as an experimental garbage collector, currently in the exploration and validation phase. Developers can enable it via the GOEXPERIMENT environment variable to test the new features under real workloads:

GOEXPERIMENT=greentea go build ./...

GOEXPERIMENT is a built-in experimental feature toggle mechanism in the Go toolchain. Unlike runtime environment variables (such as GOGC and GOMEMLIMIT), it takes effect at compile time, directly compiling experimental code paths into the binary. Historically, important features like generics and register-based calling conventions (regabi) were first validated through GOEXPERIMENT — this mechanism is a core engineering practice the Go team uses to balance stability with innovation.

Although the Go team has not yet disclosed the complete technical details of Green Tea, based on industry trends, its likely technical directions include: generational garbage collection, region-based memory management (batch-releasing objects with the same lifetime), and concurrent compaction (reducing memory fragmentation). All these directions point toward more fundamental GC architecture changes than what the existing framework allows.

This gradual introduction strategy is consistent with the Go team's established approach — first releasing as an experimental feature, then deciding whether to make it the default in subsequent versions after thorough community validation and feedback.

Practical Impact of Green Tea on Go Developers

What the Experimental Nature Means

As an experimental feature, Green Tea will not change the default behavior of existing Go programs. Developers must actively opt in to experience the new GC. This design ensures:

  1. Full backward compatibility: No impact if not enabled
  2. Controlled testing scope: Developers can compare old and new GC performance in specific environments
  3. Data-driven decisions: The Go team uses community feedback to guide subsequent development

Scenarios Worth Trying Green Tea

New garbage collectors typically bring noticeable improvements in the following scenarios:

  • High-concurrency services: Scenarios where a large number of goroutines allocate memory simultaneously, causing concentrated GC pressure spikes
  • Memory-intensive applications: Large services with heap memory reaching tens of gigabytes
  • Latency-sensitive systems: Real-time services with strict P99 latency SLA requirements
  • Cloud-native microservices: Containerized applications that need to maximize throughput within limited memory quotas

In cloud-native scenarios, using GOMEMLIMIT in conjunction is particularly important. Before Go 1.19 introduced this feature, GC triggering was primarily controlled by the GOGC parameter (default 100, meaning GC is triggered when the heap grows by 100%), which in containerized environments could easily lead to OOM (Out of Memory) — because the GC might not start reclaiming until memory was close to the limit. GOMEMLIMIT allows setting a soft memory cap (e.g., GOMEMLIMIT=1GiB), causing the GC to reclaim memory more aggressively as it approaches that limit, significantly improving memory predictability. Green Tea's design is expected to work in deep synergy with GOMEMLIMIT, further strengthening this capability.

Go Runtime's Continuous Innovation Path

The Go team has consistently maintained an active exploration mindset regarding runtime optimization. Key improvements in recent versions include:

VersionImprovement
Go 1.19Introduced GOMEMLIMIT soft memory limit
Go 1.20Arena memory allocation experiment
Go 1.22GC scheduling strategy optimization
Go 1.25Green Tea experimental GC

The introduction of Green Tea indicates that the Go team is exploring more fundamental GC architecture changes, rather than merely making incremental optimizations within the existing framework. This is crucial for the long-term development of the entire Go ecosystem.

Summary and Outlook

The emergence of the Green Tea garbage collector reflects Go's continuous pursuit of performance limits. As Go deepens its presence in cloud-native infrastructure, high-frequency trading systems, and large-scale data processing, a more efficient garbage collector will directly benefit the entire ecosystem.

Recommended action items for developers:

  • Follow the technical documentation and benchmark data after Go 1.25's official release
  • Enable Green Tea in non-production environments and compare key business metrics
  • Provide test results as feedback to the Go team and participate in community discussions

For teams pursuing peak performance, getting an early understanding of and testing Green Tea will help you gain an edge when the new GC officially lands.

#Go 1.25#Green Tea garbage collector#Go GC#experimental garbage collector#GOEXPERIMENT#generational GC#Go runtime optimization
Share:

Related articles