速報 : Boehm GC version 6.0α1
遠藤 敏夫
ある日の GC mailing list
From: "Boehm, Hans" <[email protected]>
Date: Thu, 15 Jun 2000 15:54:29 -0700
Subject: [gclist] New garbage collector versions
….. Both concurrent marking and concurrent allocation/sweeping is supported. I believe the algorithm is similar in spirit to the work by Endo, Taura, Yonezawa et al at the University of Tokyo.
Boehm 自らが GC の並列化を始めた
Boehm GC って何
Boehm らによる free な GC ライブラリ Solaris, Linux, IRIX, Windows... Gc.a をリンクすると、 C/C++ プログラムから利用
可能 GC_malloc() 関数でメモリ確保 → 後でいらなくなっ
たら勝手に解放
Boehm GC の系譜
逐次版 ( 以下、 BGC5 と呼ぶ ) と並列版 (BGC6) を平行 maintainance
Boehm GC 4.10
Boehm GC 5.1
Boehm GC 6.0
SGC 0.x
並列化並列化
影響Boehm
Endo
BGC6 追加機能 (SGC と同じ )
並列 memory allocate 複数ユーザスレッドからの allocate 要求に対して
( ほとんどの場合 ) 並列に処理 並列 mark phase
複数の GC スレッドが並列にマークを行うことにより、 GC 時間を短縮
BGC6 設計方針と現状
既存バージョンからの差分を少なく保つ ソース 20000 行のうち 2000 行程度の変更 ( 無関係
な個所も含む数字なので、実質 1000 行程度か? ) SGC の変更箇所は数えられないくらい広範囲
ターゲットは小規模共有メモリマシン あくまで気楽な並列化であり、大規模マシンで性
能がでなくてもよい。ここが SGC との違い
現状 : 今は Linux のみで稼動
各 GC 実装の比較
BGC 6 SGCBGC 5
並列 malloc
並列 mark
並列 sweep
Incremental GC
maintainance
速度 ( 小規模 )
速度 ( 大規模 )
× ○ ○
× ○ ○
× × ○
○ × ×
- △ ×
× △ ○
× × ○
以下の発表の流れ
BGC5/BGC6/SGC のしくみの違い Allocate スレッドモデル GC
BGC6 と SGC の性能比較 → SGC の圧勝
BGC5 の allocate
Free list 探索
成功終了
Reclaim list 探索 成功終了
Heap block freelist 探索
成功終了
GC
Allocate 要求ここで lock
BGC6 の allocate
Free list を各スレッドローカルに持たせ、ロックを減らす
F.l. 探索
Reclaim list 探索
Heap block freelist 探索
GC
ここで lock
SGC の allocate
Reclaim list もスレッドローカルに →ソース変更量はより多いが、 false sharing が減るはず
F.l. 探索
Heap block freelist 探索
GC
R.l. 探索
ここで lock
BGC5 のスレッドモデル
GC 要求を行った (=allocate 失敗検出した ) スレッドが一人で GC GC 中は他スレッドを、シグナルなどで停止しておく
マーク途中でメモリを書き換えられるとまずいので
ユー
ザス
レッ
ド
時間GC 要求
( 非 Incremental 設定のときの図 )
BGC6 のスレッドモデル
GC 並列度を前もって指定可能 ( 環境変数 GC_NPROCS) GC_NPROCS-1 個の GC スレッドが裏で稼動 GC 要求者 + GC スレッドで並列に GC 処理 SGC もほぼ同様
ユー
ザス
レッ
ド
時間GC スレッド
逐次 mark アルゴリズム (1)
データ構造 各オブジェクトごとにマークビット 処理経過を覚えるマークスタック
mark phase の目的 ルートからたどれる全オブジェクトのマークビットを立てる
G
H
D EMark stack
Root R
A
B C
F
HeapRRAABBCC
逐次 mark アルゴリズム (2)
Root をマークスタックに push
while ( マークスタックが空でない )
マークスタックからエントリを一つ pop → o
for (i = 0; i < (o のサイズ ); o++)
if (o[i] がポインタ && マークビットが 0)
o[i] のマークビット = 1
o[i] をマークスタックに push
オブジェクトグラフ中に枝別れが多ければ、マークスタックに積まれる仕事量は多くなる → mark 処理の並列性
マークスタックを各 GC スレッドに持たせるのが自然な並列化
BGC6 の並列 mark(1)
データ構造 唯一のグローバルマークスタック (GMS) GC スレッド毎のローカルマークスタック (LMS)
各スレッドは自分の LMS を用いて仕事をする
Globalmark stack
localmark stacklocal
mark stack
BGC6 の並列 mark(2)
初期状態 GMS にルート push / 全 LMS は空
スレッドが GMS から仕事を盗む条件 自分の LMS が空のとき。最大 5 つ仕事を盗む
スレッドが GMS に仕事を返す条件 自分の LMS に仕事が 2K 以上あるとき。全部返す GMS が空、かつ、休んでいるスレッドが 1 個以上いる
とき。 LMS内容の上半分を返す 終了条件
GMS, 全 LMS が空なら mark phase 終了
BGC6 の並列 mark(3)
詳細事項 マークビットのテスト・更新に compare&swap命令
SGC と同じ busy なスレッドを数えるカウンタ利用
ボトルネックになりうるので SGC では非採用 仕事を返すとき GMS にロックをかける 仕事を盗むときはロックなし
長所 : 待ち時間が少ない 短所 : 複数スレッドが同じ仕事をして無駄がでるかも
SGC の並列 mark(1)
データ構造 GC スレッド毎のローカルマークスタック (LMS)
のみ
localmark stacklocal
mark stack
SGC の並列 mark(2)
初期状態 LMS のどれかにルート push
スレッドが仕事を盗む条件 自分の LMS が空のとき。他のどれかの LMS から、底の仕事 1 つ盗む
盗む対象にロックが必要。しかし待たされる可能性は低い
終了条件 全 LMS が空なら mark phase 終了
SGC の並列 mark(3)
詳細事項 マークビット扱いについては BGC6 と同じ ボトルネックを起こさない終了判定アルゴリズム採用
busy カウンタではなく、あるスレッドが全員の LMS をチェック。巻き戻し対応。
仕事を盗むとき、相手 LMS にロックをかける BGC6 の GMS に比べれば、待たされる可能性は少ない
BGC6/SGC 性能の比較 ( いい加減 )
スレッド数が多い時の性能は SGC に遠く及ばず、頭打ち
(BGC6 のメインターゲットである、 ) スレッドが 8 以下のときでも SGC の勝ち
0
1
2
3
4
5
6
7
0 10 20 30
# GC threads
spee
dup BGC6
BGC6- lockSGC
SGC16倍•Enterprise 10000•アプリは N-Body•マーク時間のみ計測•遠藤が Solaris に移植した BGC6 利用
まとめ
Boehm GC Ver.6 は並列 allocate/mark 対応 SGC よりかなり遅く、まだ技術的には未成熟
Global mark stack廃止だけでも、かなりの効果が得られるのでは?
それよりも、世の中が GC の scalability に注目しだした事実が重要
SGC は 3年前からやっていた!
Boehm’s page: http://www.hpl.hp.com/personal/Hans_Boehm/gc/
性能予測モデルとの関連
性能予測モデルで、 BGC6 と SGC の違いを捉えられるか? → 今はできない。
現在捉えることのできる要因は メモリコンテンションによる待ち時間 オブジェクトグラフのクリティカルパスによる不均衡
ロックなどの要因を捉える必要 オブジェクトグラフと仕事移動戦略から、 GMSへ
のアクセス頻度を予測することは果たして可能か?