全体ミーティング (9/12)

全体ミーティング (9/12)

村田　雅之

今日の内容• 修士論文について– Deterministic Parallel Copying Garbage Collection

• 先日の発表と基本的には同じになります

並列プログラムの非決定性• スレッドの実行順序により結果が非決定

的になること– バグの原因になる– デバッグが困難である

非決定性の例

x = 3Thread2Thread 1

x = 4

x = 8

x=x+1;

x=x*2;


x = 6

x = 7x=x+1;

x=x*2;

非決定性の例


x = 4

x = 8

x=x+1;

x=x*2;


x = 6

x = 7x=x+1;

x=x*2;

非決定的

ガベージコレクション (GC)

• 不要なメモリ領域を再利用するアルゴリズム

• GC の実行はユーザプログラムの性能に影響を与えるので高速化したい

• 並列化すれば高速化が期待できる

並列 GC の難しさ• 実装が難しい• GC の正しさの検証は複雑– 必要なデータがすべてコピーされるか、等

• 並列化すると検証はもっと難しくなる– 前述の非決定性が絡む

本研究の目標• 並列 GC の決定性を保証する– GC の実装の正しさの証明を難しくする一因と

なる非決定性を排除できる

本研究で提案する手法• 並列 GC のアルゴリズムを考える• 決定性を検証できる型システムを適用す

る

DPJ (Deterministic Parallel Java)

• Type and Effect System for Deterministic Parallel Java– Bocchino Jr. らが提案 (2009)

• 型システムを用いて静的に決定性を検証• 実装が公開されている– http://dpj.cs.uiuc.edu/

DPJ の型システムの特徴• Region– ヒープ領域を分割する– 一つのスレッドからしかアクセスしないよう

にする– 配列を分割して別の region に配置することも

可能• Effect– スレッドの region へのアクセスを表す型情報

Region

• ヒープを分割しデータを配置する– 図では変数 x を region A に変数 y を region B に

配置• ひとつの region に複数のスレッドが同時

にアクセスしないよう型システムで保証する– 決定性を保証できる

yx

region A region Bヒープ

配列の分割• 配列を分割してそれぞれを別の region に

配置することができる

region A

配列の分割• 配列を分割してそれぞれを別の region に

配置することができる

region A0 region A1

y = x + 1;

Effect

• プログラム中の文のregion へのアクセスを表す型情報

• 例

yx

region A region B

A を読む、 B に書く

型検査による決定性の検証• 各スレッドの effect が異なる region へのも

のになっていることを型検査で確かめる– 各スレッドが違うデータにアクセスしていれ

ば実行順序は結果に影響しない

検証の例• 配列に書き込みを行う– 2 つの区間に分けて並列処理

• 配列は region A に配置されている

配列

region A並列実行 { write(i,j); write(k,l);}

二つの文を並列実行する

Region を分割しなかったとき• ともに「 A に書く」という effect を持つ– 同じ region に並列にアクセスする

• 型検査によりエラーとなる– 決定性は保証されないregion A 並列実行 {

write(i,j); write(k,l);}

A に書く

A に書く

並列実行 { write(i,j); write(k,l);}

Region を分割したとき• 並列実行されるスレッドが別の region への

effect を持つ• 型検査を通る– 決定性が保証される

region A0A0 に書く

A1 に書く

region A1

本研究で行ったこと• 並列コピー GC のアルゴリズムを考えた– 逐次のコピー GC のアルゴリズムを拡張する

• DPJ の型検査によって決定性を検証した

コピー GC

• ヒープを二つにわけて埋まってきたら必要なものだけコピーすることで GC を行う– プログラムは普段は一方を使用– 必要なもの = root から到達可能なもの

From

To

並列コピー GC のアルゴリズムcopy(from,to){ if(from,to が十分短ければ ){ 逐次コピー GC を行う }else{ from,to を分割並列実行 { // 再帰呼び出し copy(from の前半 , to の前半 ); copy(from の後半 , to の後半 ); } 返ってきた結果を統合 }}終了後にデフラグ

copy(from,to){ if(from,to が十分短ければ ){ 逐次コピー GC を行う }else{ from,to を分割並列実行 { // 再帰呼び出し copy(from の前半 , to の前半 ); copy(from の後半 , to の後半 ); } 返ってきた結果を統合 }}終了後にデフラグ

並列コピー GC のアルゴリズム

STEP 1大きなヒープの分割

2 つを並列実行する


並列コピー GC のアルゴリズムSTEP 2各区間についてコピー GC をする



STEP 3分割した結果をひとつにまとめる



STEP 4データを移動させて隙間を減らす

4 つのステップ1. ヒープを分割する2. 分割したヒープそれぞれで並列にコピー

GC3. 分割した結果をまとめる4. データの移動

STEP 1: ヒープの分割• 大きなヒープをあるサイズ以下になるまで

並列かつ再帰的に分割– 分割したヒープをそれぞれ別の region に配置

することで決定的な並列実行ができる

• 十分小さくなったら逐次コピー GC を行う

STEP 2: 逐次コピー GC

• 基本的には逐次アルゴリズムと同様• ただし分割された region の外へのポイン

タは後回しにする

例 : STEP 1 ヒープの分割

From

To

• ヒープを 2 分割するケース

例 : STEP 1 ヒープの分割

From0

To0

• From, To をそれぞれ 2 分割し別の region とする

From1

To1

例 : STEP 2逐次コピー GC

• 2 つに分けた region で並列にコピー GC を行う

From0

To0

From1

To1

例 : STEP 2逐次コピー GC

• ただし、 region の外へのポインタがあればそれを記憶して後で追跡するFrom0

To0

From1

To1

STEP 3: 分割した region の統合• 後回しにしていた、 region の外へのポイ

ンタを再び追跡する

• 統合前の状態

例 : STEP3分割した region の統合

From0

To0

From1

To1

• Region が統合される


From

To

• 後回しにしていたポインタから新たに到達可能になるデータをコピー


From

To

• ここでは新しいデータは前から詰めていく– 空き領域をリストで管理している


From

To

• これで必要なデータのコピーが終わる


From

To

まだ不満なこと• ヒープを分割するのでデータが連続して

配置されない

From

To

隙間が空いている

STEP 4: デフラグを行う• データを移動して間を詰める–末尾に大きく連続した空き領域ができる

• 本研究では単純な方法をとる– 後ろの断片から順にできるだけ前に移動

デフラグをするメリット• 単純なメモリ管理ができる– データをうしろに配置していくだけ– 逐次のコピー GC で可能だったこと

例 : STEP4デフラグ

• このような状態のヒープがあるときを考える


• 一番うしろから動かそうとする–末尾の空き領域を大きくしたいので


• 移動可能な空き領域を前から探していく– この場合一番最初で見つかる


• 移動可能な領域を移動する– 移動を並列化することで高速化する


• 以上の手続きをできるだけ繰り返す

デフラグの注意点• データを移動させると間違った場所を指

すポインタが生まれる

もともとのポインタ

デフラグの注意点• データを移動させると間違った場所を指

すポインタが生まれる

間違ったポインタ

データを移動した

間違ったポインタの修正• データ移動の履歴を記憶しておいて移動後

に間違ったポインタを修正する– 修正は並列に行うことで高速化する

後でポインタを修正する

この移動の情報を覚えておいて

このアルゴリズムの決定性の検証

• DPJ言語でこのアルゴリズムを記述する• DPJ の型検査により決定性が検証される

実験• 本研究の並列 GC の正しさを確認する–単純なデータについて確認

• 性能を測定する– スケーラビリティ– デフラグの効果

• 環境– 6-core Opteron 2.80 GHz * 2 (12 コア ), 64GB RAM– Linux, Java 1.6.0 update 18, DPJ version 1.7.0

本研究の並列 GC の正しさの確認

• 単純なモデルについて結果を検証– すべてコピーされることが予想されるヒープ

にこのアルゴリズムを適用する

• 実際にすべてのデータがコピーされていることを確認

• 形式的検証は難しいのでできなかった

性能測定• スケーラビリティ• デフラグの効果

• ヒープの仮想的なモデルを作成• そのモデルについてコピー GC を行う

ヒープの仮想的モデル• 2 つのポインタを持つオブジェクトを配置• ポインタは一定距離より近いところを指

す–局所性がある

• サイズは 230 (= 1G)

スケーラビリティの評価• 実行時間を計測– ヒープを 16 分割して GC を行う–約 40% が生きているデータ–ワーカースレッドの数を 1 から 12 まで変化さ

せる

• 環境– 6-core Opteron 2.80 GHz * 2 (12 コア ), 64GB RAM– Linux, Java 1.6.0 update 18, DPJ version 1.7.0

実験結果• 逐次コピー GC に対して 3.2倍速い– 12 スレッド使用時

• 1 スレッドの場合に対して 7.3倍速い

1 2 3 4 5 60

0.5

1

1.5

2

2.5

3

3.5

ParallelSequential

Number of worker threads

Spee

d to

seq

uenti

al a

lgor

ithm

実験結果 ( コピーとデフラグ )

• コピーの速度は 12 スレッドで 5.5倍– 1 スレッドの時に対して– 分割区間外へのポインタで並列性が下がる

• デフラグの速度は 11.3倍

1 2 3 4 5 6 7 8 9 10 11 120

10000000

20000000

30000000

40000000

50000000

60000000

CopyingDefrag


Tim

e (s

ec)

コピー GC とデフラグの時間• コピーは分割すると速くなる– 16 分割までは特に

• 12 cores なので• デフラグは分割が増えると非常に重くなる

1 2 4 8 16 32 64 128 2560

10000000

20000000

30000000

40000000

50000000

60000000

70000000

DefragCopying

Number of divided regions

Tim

e (s

ec)

条件を変えてみたとき• ポインタがさしている距離を広くする–範囲外へのポインタが増える

実験結果• 速度が伸びない– 12 スレッド使って 1.5倍弱

1 2 4 6 8 120

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

ParallelSequential


Spee

d to

sequ

entia

l alg

orith

m

実験結果• コピーの並列性が低いためと考えられる

1 2 4 6 8 120

2

4

6

8

10

12

14

CopyDefrag


Spee

dup

さらに別のケース• ワーカースレッドの数と分割数をあわせ

る

• 1, 2, 4, 8, 12 スレッドで実験– 12 のときのみ 16 分割

結果• 8 スレッドで 3倍弱– 12 スレッドでも同じくらい• 16 分割のため遅くなる

1 2 3 4 50

0.5

1

1.5

2

2.5

3

3.5

ParallelSequential


Spee

d to

sequ

entia

l

結果• コピーだけなら 4.5倍程度• デフラグの時間はあまり変わっていない–問題は複雑になるがスレッド数が増えるた

め？

1 2 3 4 50

5000000

10000000

15000000

20000000

25000000

30000000

35000000

40000000

45000000

50000000

CopyDefrag


Tim

e (s

ec)

ヒープの長さを変えてみたとき• だいたい線型• 並列コピー部分は増えにくい

1 2 4 8 16 32 64 128 256 512 102410000

100000

1000000

10000000

100000000

CopyingDefragTotalSequential

Size of Heap (M)

Tim

e (s

ec)

ヒープの長さを変えてみたとき• 逐次と並列の時間の関係が変わっている–キャッシュの効果？

1 2 4 8 16 32 64 128 256 512 102410000

100000

1000000

10000000

100000000

CopyingDefragTotalSequential

Size of Heap (M)

Tim

e (s

ec)

デフラグの効果• すべての空き領域に対する末尾にある空き領域の割合– 理想的には 100%

• 生きているデータの割合と分割区間数を変化– 20, 40, 60%– 1, 2, 4, 8, … , 256 分割

末尾にある空き領域

測定結果• 20, 40% では約 9 割の空き領域が末尾にあ

る• 60% では非常に悪い– 使用領域＞空き領域のためデータ移動が困難

1 2 4 8 16 32 64 128 2560

10

20

30

40

50

60

70

80

90

100

20%40%60%


Ratio

of f

ree

spac

es a

t the

tail

(%)

測定結果• 分割を増やしたところで改善している• ピースが小さくなって移動が容易になるた

め

1 2 4 8 16 32 64 128 2560

10

20

30

40

50

60

70

80

90

100

20%40%60%


Ratio

of f

ree

spac

es a

t the

tail

(%)

関連研究 : GC の形式的検証• Automated Verification of Practical Garbage

Collectors.– Hawblitzel and Petrank, 2009– 正しさや安全性に関する条件式を含めて GC

のアルゴリズムを記述する

– そこから得られた条件式を Theorem Prover を用いて解くことで性質を検証する

– 並列 GC の決定性については扱わない

関連研究 : 並列 GC

• Parallel Garbage Collection for Shared Memory Multiprocessors – Flood et al., 2001– ヒープを分割して行う並列コピー GC– ヒープ分割による隙間はそのまま– 8 コアで 5倍前後の高速化• 条件の差異のため単純比較はできない

– 決定性についての考察はされていない

Future Works

• 並列 GC の検証に形式的な証明を与える• アルゴリズムの改善– コピー GC の速度向上– デフラグの効果を高める–現実的な構造のヒープについて効果的か？

並列 GC の形式的検証• 決定性を検証して、逐次環境での正しさを

検証すれば並列 GC の正しさの検証になる– 並列環境と逐次環境の結果は決定的

• 本研究の並列アルゴリズムは決定的なのであとは逐次環境での形式的検証が必要

まとめ• 並列なコピー GC のアルゴリズムを考えた• そのアルゴリズムに DPJ の型検査を適用し

決定性を検証した• 単純なモデルについては正しさを確認し

た• 性能測定を行った– 12 コアで逐次コピー GC より 3.2倍速い

全体ミーティング (9/12)

Documents