速報: Boehm GC version 6.0α1

速報 : Boehm GC version 6.0α1

遠藤 敏夫

ある日の GC mailing list

From: "Boehm, Hans" <hans_boehm@hp.com>

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へ

のアクセス頻度を予測することは果たして可能か？