GCが止まらない

GCが止まらない
We want the pauseless GC

nari/中村成洋
ネットワーク応用通信研究所

GCが止まらない - We want the pauseless GC Powered by Rabbit 0.6.5

自己紹介

✓ nari/中村成洋です
✓ @nari3, id:authorNari

✓ 島根在住

2/154

自己紹介

✓ Rubyコミッタ
✓ NaCl勤務

3/154

自己紹介

✓ GC歴 3.5年（駆け出し）
✓ GC界の中で最弱
✓ アイス工場歴 3年

4/154

GC本を知ってる人
ノシ

2人ですか！
素晴らしい！

今日のタイムテーブル

「古くて新しい
ガベージコレクション
の世界」

GCの歴史は古い

✓ GC本は400ページ以上ある
✓ まだまだ書き足りていない

✓ 奥が深い世界

16/154

（拍手）
ﾊﾟﾁﾊﾟﾁ

記念に１つどうですか？

20/154

ということで、
今回はGC本の話を…

ということで、
今日は何の話をするか

ハードウェアサポート

アジェンダ

✓ 止まらないGCへの妄想
✓ GCのジレンマ
✓ ハードウェアサポート
✓ まとめ

32/154

× : GCへの止まらない妄想

○ : 「止まらないGC」への妄想

止まらないとは？

✓ GCによるアプリの停止時間が無
視できる範囲
✓ Pauseless GC、RealTimeGCとか
呼ばれる

38/154

近未来では
さらに重要になる

根拠(1)

✓ メニーコア時代がもうすぐ
✓ 空いているコアにGCを乗っけたい
よね

41/154

根拠(2)
✓ 容量の増加
✓ より富豪的なプログラミングが可
能に
✓ 尻ぬぐいはGCがする
✓ 単純なアルゴリズムでは停止時
間が酷いことになる
42/154

ほとんどの言語処理系の
GCは結構ダメダメ

現実

✓ 容量増加＝停止時間悪化
✓ 空いているCPUをうまく使えない
GC

45/154

アジェンダ

✓ まとめ

49/154

止めないために
どうする？

止めないために

✓ マルチスレッドプログラミング
✓ アプリケーション（ミューテータ）
✓ GCスレッド

✓ アプリケーションと並行してGC
✓ Concurrent(並行)GC

52/154

マルチスレッド
プログラミングだって..orz

マルチスレッド
プログラミングといえば

✓ 生産性を著しく下げるバグで有名
✓ しかも、デバッグが困難

✓ 難しい
✓ とにかく罠が多いことで有名
54/154

前提知識

✓ tracing gcの問題
✓ 参照カウントは関係ない

✓ tracing gcって何？

56/154

tracing gc

✓ rootから辿って何かの処理を行う
GC
✓ root = tracingの起点となるオブジェクト

57/154

tracing gc

✓ M&S
✓ rootから辿って(tracing)マーク付け

58/154

tracing gc

✓ copying
✓ rootから辿ってコピー

59/154

M&Sの例(1)

60/154

M&Sの例(2)

61/154

M&Sの例(3)

62/154

M&Sのマーク完了

63/154

M&S

✓ M&Sにおいてはマークがtracing
✓ マーク完了後はスイープ
✓ スイープはヒープ内を走査するだけで
OK

64/154

M&S並行化の問題とは？

M&S(1)

66/154

M&S(2):ミューテータ登場＆書
き換え

67/154

M&S(3):GCは処理を続ける

68/154

M&S(4):トレース漏れ！！

69/154

GCは完全でなければならない

✓ トレース漏れGC ＝不良GC
✓ 生存中のオブジェクトを削除しちゃう
✓ バグ！

✓ 一部の不良GCのために善良な
GCが不当な扱いを受ける
72/154

例えば、根拠のない悪口

メモリリークしていても…。

「よくわかりませんが、たぶ
んGCが悪さしているんだと
思います」

不当な扱いを受ける
GC…。

同期

✓ ミューテータの変更にGCは同期
しなければならない
✓ 双方、気を遣い合う感じ

79/154

同期方法は大まかに二つ

✓ ライトバリア
✓ リードバリア（詳細は割愛）

80/154

ライトバリア

✓ ミューテータのオブジェクトに対す
る書き込み時を記録
✓ 記録集合（remembered set)

✓ 記憶集合もrootsとして扱う

82/154

M&S(1)

83/154

M&S(2):ミューテータ登場＆書
き換え

84/154

M&S(3):GCは処理を続ける

85/154

M&S(4):記憶集合もトレース

86/154

問題なし…と思いきや

ライトバリアの問題点

✓ オブジェクト単位だと粒度が細か
すぎ
✓ ミューテータに負担が掛かる
✓ ライトバリアによる実行時間の悪化

88/154

そこで
「カードマーキング」
ですよ

カードマーキング(1)

90/154

カードマーキング(2)

91/154

メリット

✓ ライトバリアの範囲をオブジェクト
単位からカード単位へ
✓ 書き込みがないカード：「クリーン」
✓ 書き込みがあったカード：「ダーティ」

92/154

メリット

✓ 書き込みの局所性を期待できる
（コンパクションによるもの）
✓ ミューテータへの負担を軽減

93/154

デメリット

✓ 範囲が広すぎる
✓ 死んでいるものが生きていると見なさ
れる可能性が高い

94/154

デメリット

✓ GCがもたつくと全部「ダーティ」に
なる恐れがある
✓ つまり、完全な並行化が難しい

95/154

ある程度並行なGC
Mostly Concurrent GC(Java6）

(1)単純にマーク（並行）

98/154

(2)マーク終了後、ミューテータ
停止

99/154

(3)マークされたカード内を再ト
レース

100/154

(4)ミューテータ再開

101/154

(5)スイープ（並行）

102/154

Mostly Concurrent GC

✓ マークフェーズ中に生成したオブ
ジェクトはマーク
✓ 同期もまぁまぁ速い
✓ 性能もいいけど

103/154

結局、GCで止まってるじゃ
ないすか！！

返事がない
ただの屍のようだ

コ、コレが現実か！！

問題点まとめ

✓ ミューテータとGCの同期が大変
✓ ミューテータによる変更記録の粒
度問題
✓ 細かくすると遅い（ライトバリア）
✓ 広くすると終わらない（カードマーキン
グ）

108/154

苦渋の決断

✓ 一度止めてさっとトレースを終わら
せる

109/154

アジェンダ

✓ まとめ

110/154

逆にこう考えてみよう

ライトバリアが
「超速かったら」
どうなのよ？

ハードウェアサポートの予
感！！

TAO

✓ 竹内郁雄先生らによって実装
✓ TAO/ELIS
✓ 今日はELIS復活祭らしい

116/154

TAO

✓ TAOはSILENTの機械語
✓ LISPの方言

117/154

TAO

Lisp と Prolog と
Smalltalk と C をゴタ混
ぜにしたプログラミング
言語だが見掛けも骨組
みもやっぱり Lisp
[「マルチパラダイム言語 TAO - 竹内郁雄」より引用]

118/154

SILENT
✓ 記号処理計算機
✓ LISPマシン

✓ 軽量プロセス管理
✓ 水平型マイクロプログラムが書け
る
✓ TAO
119/154

軽量プロセス

✓ すべてのプロセスはTAOで動作
✓ アプリケーションもプロセスに載る

120/154

GC

✓ アプリケーションのプロセスが使
用するメモリを管理
✓ 計8つのGCプロセス（軽量）が常
に走る
✓ OSレベルでのGC

121/154

8つのGCプロセス

✓ main marker
✓ post marker
✓ 6つの sweeper
✓ データ種別毎

122/154

それぞれの役割

✓ main marker
✓ rootのマークをひたすら行うプロセス

✓ post marker
✓ ライトバリアで見つけたオブジェクトの
マークをひたすら行うプロセス

123/154

それぞれの役割

✓ sweeper
✓ 上記マークが終わったらスイープ

124/154

スケジューリング
✓ GCプロセスのスケジューリングは
OSで管理
✓ 優先度あり
✓ GCを急がなきゃ行けないときは優先度
あげたり

✓ メモリが枯渇した場合は全部止め
る
125/154

重要な点

✓ 非停止であること
✓ ハードリアルタイム（厳格な実時間）を
実現
✓ ※ソフトリアルタイム（まぁまぁ実時間）
ではない

126/154

ライトバリア

✓ マイクロプログラムのサブルーチ
ンで実装
✓ car、cdrへの書き込み時に動作

✓ 非常に高速
127/154

結果

✓ 反応遅延が100マイクロ秒
✓ （ミリ秒じゃない）

✓ GCよる遅れはほとんど感じられな
いということ

128/154

なぜこれほどの性能が
でるのか？

考察(1)

✓ OSとGCの関係性
✓ GC自体が効率的なスケジューリング方
針を持っている
✓ 軽量プロセス機能を十分に発揮
✓ OS,GC,言語がべったりとくっついてい
る

130/154

考察(2)

✓ ライトバリアが速い
✓ オブジェクト（セル）単位
✓ ハードウェアサポートのお陰

131/154

考察(3)

✓ GCがシンプル
✓ mark sweepのみ
✓ コンパクション、世代別などがない
✓ フラグメンテーション問題はアロケータである程
度カバー

132/154

その他、様々なテクニック

詳細は論文で

✓ Lisp can be "Hard" Real Time
✓ http://www.franz.com/services/
conferences_seminars/jlugm00/
conference/Talk14_takeuchi.pdf

134/154

Pauseless GC
✓ 「VEGA」と呼ばれる独自プロ
セッサ
✓ JVMのGC
✓ Cliff Click博士主導
✓ Sun => Azul
✓ HotSpotのJITコンパイラ設計
136/154

ハードウェアサポート
✓ リードバリアをハードウェアサポー
ト
✓ リードバリア用の命令がプロセッサに組
み込んである

✓ 詳細は以下（日本語）
✓ http://www.nminoru.jp/~nminoru/java/
cms/pauseless_gc.html
137/154

ハードウェアサポートの問
題点

MRI

✓ Pauseless GCの技術がオープン
ソース化
✓ MRI(Managed Runtime Initiative)
✓ Azul△

141/154

MRI

✓ 様々なプロセッサにハードウェアサ
ポートの技術を広げた
✓ JITの拡張
✓ CPUの仮想化技術を使用

142/154

まだ理解してない…orz

ハードウェアサポートまとめ

ハードウェアサポートまとめ
✓ GCの並行化は同期を以下に速く
するかが課題
✓ 同期処理部分をハードウェアサ
ポート
✓ 夢の止まらないGCへ
✓ MRIの動向に注目しましょう
146/154

アジェンダ

✓ まとめ

147/154

まとめ

✓ GCの並行化は大事
✓ 色々問題がある
✓ ハードウェアサポートで解決

148/154

「やりすぎ」だと思う人
（拍手）

謝辞
CSNagoyaのみなさまに感
謝

ご静聴ありがとうございます

GCが止まらない

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Mehr von Narihiro Nakamura

Mehr von Narihiro Nakamura (20)

GCが止まらない