Green Tea Garbage Collector の今：Go言語のコアチームによる試行錯誤の過程と共にメモリ管理最適化の実装を読み解く
オブジェクトの状態を未走査（White）・処理中（Gray）・走査済（Black）で管理する古典的なアルゴリズム
並行処理によってチューニングされているものの、以下のような課題に対応できていない
現在のハードウェアトレンドとの乖離
DRAM クロックは CPU クロック速度と比べて停滞している（メモリウォール） 空間的局所性
GC がポインタを辿る際に、物理的に離れたメモリアドレス間を頻繁に移動しうる
時間的局所性
同じメモリ領域への複数回アクセスが、GC サイクル全体にわたって分散しうる
その場合、キャッシュされたデータを再利用できない
現在のアルゴリズムでは、NUMA アーキテクチャのような不均一なメモリトポロジを認識できない メモリアクセスコストが均一であると仮定しているため、遠隔の NUMA ノードへのアクセス時最適化に非対応
「メモリ中心」か「プロセッサ中心」かという、GC の設計思想レベルの時代との変遷
現行の GC は、明確に プロセッサ 中心の設計に基づいて設計されている 局所性の欠如を犠牲にしても、すべての CPU コアを最大限に活用し、積極的に並列化することを最優先としている ハードウェアの進化によって、この優位性と トレードオフ が逆転し性能への影響が顕著になった Green Tea GC のコンセプト
個々のオブジェクトではなく、メモリブロック（スパン（8KiB））を処理単位とする 「メモリ内で近いオブジェクトを一緒に処理する GC を作りたい」というモチベーション
これにより、コア数増加や小さいオブジェクトを大量の処理する実装に対して特に有効
warning.icon 厳密には、今のところ 512 Byte 以下のオブジェクトしかない場合のみ対象
これ以上は従来の GC アルゴリズムで処理
従来の GC アルゴリズムの延長にあるもの
GC Worker も専用に実装
以下のようなメリットにより、結果として CPU コスト（特に スキャンループ）を削減できる オブジェクト単位のポインタ追跡はランダムアクセスが起きやすいが、スパン内の線形走査は近接アクセスが多い
CPU プリフェッチ
スパン内のオブジェクトメタデータも保有しているので、事実上ゼロコストでプリフェッチ
キュー競合の現象
スパンを一度だけ enqueue する設計で操作回数を削減しつつ、グローバルキュー操作の競合も低減 スパン内に複数オブジェクトがない場合は、従来の方が圧倒的に高速
Raft を思い出した radish-miyazaki.icon v1.26 のマイルストーンに含まれており、安定化に向けて開発が進行中
Green Tea のためというよりかは、純粋な SIMD サポート
スパンベースという都合上恩恵を受けられる
Green Tea はグローバルキューが使われないようになる？
参考