2025/06/14 04:10 Green Tea Garbage Collector
ロボ子、Green Tea Garbage Collectorって知ってるか？
名前は聞いたことがあります。Goの新しいGCの実装ですよね？
そうじゃ！Go 1.25でオプトインの実験機能として利用可能になる予定で、開発者による試用が推奨されてるみたいじゃぞ。
へえ、もうすぐ試せるんですね。既存のGCと何が違うんですか？
既存のGCは、CPUクロックとDRAMクロックの速度差とか、コア数の増加、メモリトポロジーの複雑化を考慮してないらしいんじゃ。メモリのレイテンシとバンド幅が制約されてるのが問題らしい。
なるほど。Green Teaはそこを改善するんですね。
その通り！Green Teaはメモリの位置を考慮した並列マーキングアルゴリズムを使ってるから、GC CPUコストを大幅に削減できるらしいぞ。SIMDアクセラレーションとかの最適化もできるみたいじゃ。
具体的にはどういう設計になっているんですか？
個々のオブジェクトじゃなくて、より大きな連続したメモリーブロック（span）をスキャンするんじゃ。共有ワークキューもspanを追跡するらしい。span内のスキャン対象オブジェクトはspan自体で管理するから、メモリアクセスの局所性が向上するってわけじゃな。
spanを使うことで、効率が上がるんですね。プロトタイプ実装では、small object spanに焦点を当てていると。
そうそう。各spanは、grayビットとblackビットをオブジェクトごとに格納して、スキャン状況を管理するんじゃ。white, gray, blackの3つの状態があるぞ。
スキャン中にsmall objectへのポインタが見つかると、grayビットが設定されて、spanがキューに追加されるんですね。
その通り！Work distributionも工夫されてて、span専用のキューを使って、他のワーカーから直接ワークをスティールできるから、グローバルリストの競合が軽減されるんじゃ。
個々のオブジェクトではなくspanをキューに入れることで、キューに入れるアイテムが減って、キューの競合が低くなるんですね。
FIFO（First-In, First-Out）が、スキャン対象オブジェクトの平均密度が最も高くなることが判明したらしいぞ。
Single-object scan optimizationというのもあるんですね。spanにスキャン対象オブジェクトが1つしかない場合の最適化ですか？
そうじゃ！spanがキューに入れられたときにマークされたオブジェクトをspanのrepresentativeとして追跡して、hitフラグを使って、span全体を処理するかどうかを判断するんじゃ。
なるほど。プロトタイプ評価では、GC負荷の高いマイクロベンチマークで、既存のGo GCと比較して、GC CPUコストが10〜50%削減されたんですね。
コア数が多いほど改善が大きくなって、L1およびL2キャッシュミスも半減したらしいぞ。tile38ベンチマークでは、スループット、レイテンシ、メモリ使用量が大幅に改善されたみたいじゃ。
それはすごいですね！でも、bleve-indexベンチマークでは、パフォーマンスはほぼ変わらなかったんですね。
Green Teaにとってヒープトポロジーが難しかったみたいじゃな。今後の展望としては、SIMDによるスキャンカーネルの高速化とか、Concentrator networkによるポインタ密度の向上と局所性の生成があるみたいじゃ。
Green Tea、これからが楽しみですね！
ほんとじゃな！しかし、Green Teaって名前、お茶請けに羊羹が欲しくなるのじゃ。
博士、GCの話から急に食い意地が…。
⚠️この記事は生成AIによるコンテンツを含み、ハルシネーションの可能性があります。