Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
GC_Qiita
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
Yporon
October 05, 2025
790
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
GC_Qiita
Qiita用のGC解説スライド
Yporon
October 05, 2025
More Decks by Yporon
See All by Yporon
Goから学ぶGC -Green Tea GCによる次世代最適化-
yuporon
0
650
LT会資料_アーキテクチャ
yuporon
0
19
Featured
See All Featured
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
28
3.7k
Leadership Guide Workshop - DevTernity 2021
reverentgeek
1
390
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
33
5.2k
What’s in a name? Adding method to the madness
productmarketing
PRO
24
4.2k
Building Applications with DynamoDB
mza
96
7.2k
Impact Scores and Hybrid Strategies: The future of link building
tamaranovitovic
0
450
Accessibility Awareness
sabderemane
1
240
AI in Enterprises - Java and Open Source to the Rescue
ivargrimstad
0
1.5k
Building Better People: How to give real-time feedback that sticks.
wjessup
370
20k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
133
20k
Bioeconomy Workshop: Dr. Julius Ecuru, Opportunities for a Bioeconomy in West Africa
akademiya2063
PRO
1
400
[Rails World 2026] Durable orchestration on Rails: from continuation to workflow
palkan
1
690
Transcript
G r e e n T e a G C
へ G O か ら 学 ぶ G C
アーキテクチャユニットぽいかっこいい 発表したいなあ
GCについて語ればそれっぽいかもしれない
必死に勉強して作りました 優しい目で見てください
はじめに わからん!ってなったら止めてもらっても大丈夫です 質問はSlackにお願いします なんとなくGCのイメージ掴めたらそれでOKです 40枚くらいあるので頑張ってついてきてください
お品書き GCとは 現在のGoのGC実装 Green Tea GCのアプローチ Ruby/PythonのGC まとめ
GCってなんなん
GCとは GC = Garbage Collection 不要になったメモリを自動で回収する仕組み
メモリを回収しないとどうなるの? 使い終わったメモリが解放されず、どんどん蓄積 →メモリリーク Out of Memory (OOM) エラーでプログラム強制終了 メモリ不足でスワップ(ディスクI/O)が発生 アプリケーションのパフォーマンス低下
GCの目的 安全性 メモリリークやダングリングポインタの回避 セキュリティリスクの低減 開発効率の向上 malloc/freeの対応管理から解放 コードがシンプルになり、メモリ管理のバグを減らせる 安定性 ランタイムによる最適化で性能が安定 サービス品質の向上
GoにおけるGCの仕組み Concurrent Mark & Sweepを採用
GCの簡単なアルゴリズム紹介
GCについての前提知識 ルートセット オブジェクトが到達可能か(生存しているか)を判定 するための始点 基本的にメモリのスタック領域 他にも、グローバル変数・静的変数・実行中のゴルー チンなど
GCについての前提知識 スタック・ヒープ プログラムのメモリ空間 ス タ ッ ク : 関 数
の 実 行 に 必 要 な 一 時 的 な デ ー タ を 格 納。自動管理で高速 ヒ ープ : 動 的 に 確 保 さ れ る 大 き な デ ー タ を 格 納 。 GC が必要で低速
GCについての前提知識 STW(Stop The World) GC実行中にアプリケーションを一時停止すること GC 中 に オ ブ
ジ ェ ク ト が 変 更 さ れ る と、 正 確 な 判 定 が できない すべてを停止させて「スナップショット」を取る必要 がある
GCについての前提知識 Write Barrier(書き込みバリア) 並 行 GC 中 に、 ア プ
リ が オ ブ ジ ェ ク ト を 変 更 し た 際 に GCに通知する仕組み 詳しくは、Tri-color Markingの解説に合わせて説明 します
メモリ構造とGC ルートセット プログラムのメモリ空間 スタック (Stack) main() 関数 config *Config →
ヒープ上のConfigオブジェクト count int = 42 (プリミティブ値) users []User → ヒープ上の配列 processData() 関数 data *Data → ヒープ上のDataオブジェクト temp string = "processing" ← 現在の実行位置 スタックの特徴 • 関数の呼び出し順に積み重なる(LIFO) • 関数終了時に自動的に解放 • 高速アクセス・サイズ制限あり(通常数MB) • ローカル変数・引数・戻り先アドレスを格納 ヒープ (Heap) Config オブジェクト host: "localhost" port: 8080 db: *Database []User 配列 [0]: {name: "Alice"} [1]: {name: "Bob"} [2]: {name: "Carol"} Data オブジェクト id: 12345 content: "..." next: *Data Database オブジェクト connection: "..." pool: [...] 未参照 (ガベージ) OldData 未参照 (ガベージ) TempBuffer ヒープの特徴 • 動的にメモリを確保(new, make, malloc等) • 大きなデータ構造やオブジェクトを格納 • GCまたは手動での解放が必要 • スタックより低速だが、サイズ制限が緩い 🎯 ルートセット(GC Roots ) - ガベージコレクションの起点 1. スタック上の参照 • 実行中の関数のローカル変数 • 関数の引数 • 一時変数 例: config, users, data 2. グローバル/ 静的変数 • プログラム全体で共有 • クラスの静的フィールド • シングルトンインスタンス 例: globalCache, logger 3. レジスタ/ 実行コンテキスト • CPU レジスタ内の参照 • 実行中のスレッド状態 • Goの場合:Goroutineスタック 現在処理中の値 ⚡ なぜ重要? • これらから到達可能 = 生存 • 到達不可能 = ガベージ • GCの正確性を保証 循環参照も正しく判定可能
Mark & Sweep
None
Tri-color Marking
None
Concurrent Mark & Sweep Tri-color Concurrent Parallel Mark&Sweep この表現の方がわかりやすいかも、並列でMarkを行う Initial
Mark ルートセットを灰色にマーク Write Barrierを有効化 Concurrent Mark gcBgMarkWorkerが並列でヒープ領域をマーキング アプリケーションと同時実行
Concurrent Mark & Sweep Mark Termination マーキング完了処理 Write Barrier無効化 Concurrent
Sweep(並行実行) 未マークオブジェクトを解放 バックグラウンドで実行
現状のGCの課題感 メモリアクセスが非効率な場合がある
現状のGCの課題感 オブジェクトベースでメモリを探索するため、キャッ シュが効かない。DRAMへのアクセス待ちが増えて遅 くなる GCサイクルの中で同じ領域を分散してアクセスするた め、キャッシュに載せても再利用できず無駄になる 現行 GC は NUMA
などメモリトポロジを考慮してい ないため、遠いメモリにアクセスして遅延が発生
現状のGCの課題感 キャッシュヒット率が低い 再利用できない 遠いメモリに触りにいく
ハードウェアトレンドとのミスマッチ CPUの進化 コア数は増加し続けている(8, 16, 64コア...) 処理能力は向上 メモリの進化 速度向上は緩やか CPU-メモリ速度差は年々拡大(Memory Wall問題)
時代のハードウェアに最適化されていない?
None
GreenTeaGCのアプローチ 🍵 オブジェクト単位ではなくメモリブロック(スパン)単 位でスキャンする
None
GreenTeaGCのアプローチ 🍵 従来のアルゴリズムの延長にある そ の 上 で 、 オ ブ
ジ ェ ク ト 単 位 で は な く メ モ リ ブ ロ ッ ク (スパ ン)を処理単位とする 512バイトを超える大きなオブジェクトは、従来のア ルゴリズムで処理 1回のスキャンで得られるポインタ数が多く、スキャ ンごとのオーバーヘッドを容易に償却できるため
何が良くなるのか?
何が良くなるのか スパ ン単位での連続スキャンにより空間的局所性が向上 メモリ全体を飛び回る無駄なアクセスが削減される キャッシュヒット率の向上 スキャン効率の向上 CPUサイクルの無駄なメモリアクセス待ちを削減 同一スパ ンへの再訪問を削減 メモリトポロジー最適化
8KiB境界アライメント ローカルメモリ優先アクセス
何が良くなるのか 空間的局所性:スパ ン単位スキャンでキャッシュ効率向上 時間的効率性:再訪問削減でCPU待ち時間削減 ハードウェア最適化:NUMA対応で物理配置を考慮
GreenTea GCの今後 https://github.com/golang/go/milestone/373 マイルストーンにGreenTeaGCについての記述あり デフォルト化は未定 https://github.com/golang/go/issues/73581
RubyとPythonのGC(参考) Ruby 世代別Mark & Sweep インクリメンタルGCでSTWを分割(Ruby 2.2以降) Ruby 3.1以降は3世代GC Python
参照カウント + サイクル検出 即座にメモリ解放されるが、refcount操作のオーバーヘ ッドあり
まとめ
まとめ GCの基礎 不要メモリの自動回収で安全・効率的な開発を実現 GoのGC実装 Concurrent Mark & Sweep(低レイテンシー) Green Tea
GC オブジェクト単位ではなくメモリブロック(スパ ン) 単位でスキャンする 今後はGreen Tea GCの実用化に期待
参考文献 https://github.com/golang/go/issues/73581 https://go.dev/doc/go1.25 https://qiita.com/gold- kou/items/4431d3dd41606d41732b https://www.dolthub.com/blog/2025-09-26-greentea- gc-with-dolt/ https://speakerdeck.com/zchee/the-current-status- of-green-tea-gc https://siddharthav.medium.com/green-tea-garbage-
collector-63233aa5a9b5
みんなもGoを書こう
次はアセンブリについて 発表しようかなと思ってます
ありがとうございました T H A N K Y O U