Green Tea Garbage Collector の今 (Go⾔語のコアチームによる試⾏錯誤の過程と共にメモリ管理最適化の実装を読み解く) zchee (⽩⽯ 耕⼀)｜株式会社Gaudiy 

Agenda ● Introduction ○ ⾃⼰紹介 ○ 対象となる⽅ ● Green Tea GCとは ● 背景 ● 現在 ● 未来 ● まとめ 

Introduction 

⾃⼰紹介 Name: ⽩⽯ 耕⼀ a.k.a. zchee Company: 株式会社Gaudiy Position: Architect 

対象となる⽅ ● Goのランタイム実装や内部構造に興味がある⽅ ● GoのGCの変遷について興味がある⽅ ● CPUやメモリ管理に興味がある⽅ 

Green Tea GCとは？ 

● Goの新しいGC ○ Go 1.25からGOEXPERIMENT=greenteagcで実験的に利⽤可能 ● @mknyszekによって2025/05/03にproposalが提出された ○ https://github.com/golang/go/issues/73581 Green Tea GCとは？ 出典：Go 1.25 Release Notes — “New experimental garbage collector” 

⼀⾔でいえば 「メモリ内で近いオブジェクトを⼀緒に処理するGC」 コア数増加や⼩さいオブジェクトを⼤量に処理する実装に対して特に有効。 ● なぜこのような特性をもつGCを開発したのか？ ● どういった試⾏錯誤を経て今のGCのアルゴリズムになったのか？ ● どういう将来を⾒越しているのか？ 主題：なぜこのGreen Tea GCになったのか？ 

過去 

従来（Tri-color Parallel Marking） ● オブジェクトの状態を、未⾛査(White)‧処理中(Gray)‧⾛査済(Black)で管理 する古典的なアルゴリズム 

● オブジェクトの状態を、未⾛査(White)‧処理中(Gray)‧⾛査済(Black)で管理 する古典的なアルゴリズム ● Goが得意とする並列処理によってチューニングされているものの、本質的な 課題に対処できない 課題 ● 現代（未来）のハードウェアトレンドとの乖離 ● 局所性の⽋如 ● Processor vs MemoryというGCの設計思想レベルの時代との変遷 Tri-color Parallel Marking 

現代（未来）のハードウェアトレンドとの乖離 ● CPUとDRAMの性能ギャップ ○ 現代のCPUクロック速度向上と⽐較して、DRAMクロックは停滞している（メモリウォール） Forget Moore's law: Hot and slow DRAM is a major roadblock to exascale and beyond | Extremetech 

● 空間的局所性 ○ GCがポインタを辿る際に、物理的に離れたメモリアドレス間を頻繁に移動しうる ○ そのため、CPUキャッシュミスが頻発し、低速なDRAMへのアクセスが多発する ● 時間的局所性 ○ 同じメモリ領域への複数回のアクセスが、GCサイクル全体にわたって分散しうる ○ その場合、キャッシュされたデータの再利⽤ができない ● トポロジへの⾮対応 ○ 現⾏のGCアルゴリズムは、NUMAアーキテクチャのような不均⼀なメモリトポロジを認識で きない ○ メモリアクセスコストが均⼀であると仮定しているため、遠隔のNUMAノードへのアクセス時 最適化などに⾮対応 局所性の⽋如 

並列GCアルゴリズムの「プロセッサ中⼼」と「メモリ中⼼」の思想 ● 現⾏のGCは、明確に「プロセッサ中⼼」の思想に基づいて設計されている ○ メモリアクセスパターン（局所性の⽋如）を犠牲にしても、すべてCPUコアを最⼤限に活⽤し て積極的に並列化することを最優先にしている ● ハードウェアの進化によって、この優位性とトレードオフが逆転し性能への 影響が顕著になった GCの設計思想レベルの時代との変遷 

現在 

Green Tea GC 

Green Tea GCのコンセプト ● 個々のオブジェクトではなく、メモリブロック「スパン (8KiB)」 を処理単位とす る ○ 厳密には今のところSmall Object Span（8KiBのSpan＆<= 512Bオブジェクト）のみが対象 ○ それ以上の⼤きさのオブジェクトは従来のGCアルゴリズムで処理 ● 従来のGCアルゴリズムの延⻑にあるもの ● GC Worker（Queue）も専⽤に実装 ○ goroutineのスケジューラーで既に実績のあるwork-stealing runqueueに基づいている ● Workerがスパンを処理（enqueue -> dequeue間）するまでに、隣接したオブジェ クトが複数格納されていると想定し、それらをまとめてスキャンする楽観的アルゴ リズム 

なにが良くなるのか？ スパンベースのスキャンに変わることにより、メモリの局所性が向上 ● ランダムアクセスの減少 ○ オブジェクト単位のポインタ追跡はアクセスが⾶びやすいが、スパン内の直線⾛査は近接アクセスが多い ● CPUプリフェッチ ○ スパン内のオブジェクトメタデータも保有(co-location)しているため、事実上ゼロコストでプリフェッチ ● キュー競合の減少 ○ スパンを⼀度だけenqueueする設計で操作回数を劇的に削減しつつ、グローバルキュー操作の競合も低減 ↓ 結果として、GCのCPUコスト（特にスキャンループ）を削減できる 

● スパン内に複数オブジェクトがあるときは効率なことは分かったが、 スパンに1つしかオブジェクトがないケースもある ○ この場合はスパン内を⾛査するアルゴリズムではむしろ遅くなってしまうのではないか？ ↓ Green Tea GCではこのケースに特化した最適化も⾏っている スパン内に複数オブジェクトがないときは？ 

● Representative （代表）オブジェクトとgchit flagを導⼊することによってス パンに属するオブジェクトが1つしかないときはO(1)でオブジェクトにアク セスできるように単⼀オブジェクト時の最適化をしている 単⼀オブジェクト最適化 

単⼀オブジェクト最適化 obj0 obj1 obj2 obj3 obj4 代表オブジェクトやhit flagがない場合、 すべてスキャンする必要がある 代表オブジェクト ＝obj3 ＆hit flag falseの場合 obj3直接スキャンすれば終わり 

● 例として、スパンがdequeueされる際の最⼤局所性の検証 ○ FIFO ○ LIFO ○ Sparsest-first ■ 疎 ○ Densest-first ■ 密 ○ Random ○ Address-ordered ● FIFOが⼀番オブジェクトが密にスパンに格納される事を検証し採⽤ Go teamも試⾏錯誤の末にGreen Tea GCを設計している 

● Local span queueはSPMC（single-producer multi-consumer）ring buffer で実装 ○ sync.Poolから着想を得ている ○ 後述 ● SPSC‧MPMC queueの参考 ○ github.com/puzpuzpuz/xsync - Concurrent data structures for Go. Go teamも試⾏錯誤の末にGreen Tea GCを設計している 

ベンチマーク (⾮公式) メトリクス Classic GC Green Tea GC 変化 Notes 合計GC CPU時間 27.35s 21.33s -22.0% ~22% less CPU → more efficient 最終ヒープサイズ 4.12 GB 3.80 GB -7.8% ~8% smaller heap, faster memory release p95 ポーズ時間 0.23 ms 0.20 ms 0% Almost same p99 ポーズ時間 0.92 ms 1.84 ms +100% Greentea shows rarer but longer pauses Go 1.25 Greentea GC vs Classic: HydrAIDE 1M Swamp Test Shows +22% CPU Efficiency, -8% Memory 

性能評価1 ● 従来のGCと⽐較して ○ GCのCPU時間: -22% ○ ヒープ使⽤量: -8% ○ アプリケーション全体実⾏時間: -5.6% ● スパン単位でのスキャンにより、SIMD最適化への道が開かれた 結論: CPUバウンドなワークロードで⼤きな効果を発揮 

● p99のGC停⽌時間 (ポーズタイム) が倍増 (例: 0.92ms → 1.84ms) ● 平均的な応答性能 (p50, p95) はほぼ変わらない 結論: 「予測可能な低レイテンシ」から「⾼いスループットと、時折発⽣するテー ルレイテンシ」への特性のシフト 性能評価2 

未来 

● ロードマップ: Go 1.26のマイルストーンに既に含まれており、安定化に向け 開発が進⾏中 ● SIMD (AVX512) の活⽤によるハードウェアレベルでの⾼速化も検討 ○ golang/goに dev.simd branchがある ○ simd packageの導⼊、AVX 512の公式サポートが実装進⾏中 ○ Green Tea GCの為という側⾯ではなく純粋なSIMDサポート ■ しかし、スパンベースという特性上、恩恵を受けられる 未来 

と、思ってたら！ 2025/09/27にマージされた！ ● runtime: use scan kernels in scanSpan [green tea] ○ This is an extra 15-20% faster over the current sparse span scanning when AVX512+GFNI is available and there's sufficient density. ● このCL後にbleve-indexのベンチマークを再度検証したところ、性能向上が⾒られたとの事 未来 

さらに以下も同⽇にマージ ● runtime: eliminate global span queue [green tea] ○ This change removes the locked global span queue and replaces the fixed-size local span queue with a variable-sized local span queue. The variable-sized local span queue grows as needed to accomodate local work. With no global span queue either, GC workers balance work amongst themselves by stealing from each other. 未来 

まとめ 

まとめ ● Green Tea GCは、現在‧今後予測される様々なパフォーマンス低下に対応するためのGoの 戦略的進化 ● スパンベース のアプローチにより、GCのCPU効率を⼤幅に改善 ● 未だ実験的機能だが、Goのパフォーマンスを左右する重要な⼀歩 コードレベルで追いたい⽅は、src/runtime/mgcmark_greenteagc.go 辺りがコア実装です 

Join us! 弊社Gaudiyでは他にも様々な分野のテックブログを発信しています。興味ある方はぜひ以 下のQRコードからアクセスしてみてくださいー採用も絶賛募集中でーす 採用ページ Zenn Techblog 

ご清聴ありがとうございました