Transcript マークフェーズ
高いヒープ使用率で高速な
インクリメンタルGC
2005年8月4日
東京大学
白井達也、遠藤敏夫、田浦健次朗、近山隆
1
背景
プログラムの大規模化
メモリの解放の明示は大きな負担
⇒GC(メモリの自動管理)が重要
GCの性能指標
総実行時間(スループット)
停止時間
ヒープサイズ
これらはトレードオフの関係
2
GC性能のトレードオフ
総実行時間とヒープサイズのトレードオフ
=ヒープ使用率の増加に伴うスループットの低下
Mark Sweep(MS)では一度のMSサイクルで回収できる
ごみの量が減少し、サイクル数が増加
Reference Counting(RC)ではサイクルのごみを解放す
る場合は同様の性質を持つ
Mark Sweepをインクリメンタルにする(IMS)と大きく
低下
ヒープに余裕を残して動作させる必要があるため
アプリケーションが使用するメモリサイズの数倍の
ヒープを用意する必要がある
3
3つの性能が全て重要な場合
オンラインゲームサーバ
レスポンスは重要
スループットがユーザ数に直結
メモリが数GB必要なら数倍のヒープは困難
携帯端末
レスポンスとスループットは使いやすさに直結
物理メモリ量が限られている
4
本研究の貢献
ヒープが小さいときのスループットの低下
を抑えたインクリメンタルGCを設計
RCとIMSを用いたハイブリッドGC
ヒープ使用率が高いときはIMSよりRCの方が
スループットが高い
IMSのマーク量制御に工夫
性能モデルを用いて理論的に評価
JikesRVMに実装してベンチマークで評価
5
発表の流れ
背景
本研究の貢献
基本的なGC
提案手法
コストの見積もり
実験と評価
まとめ
6
発表の流れ
背景
本研究の貢献
基本的なGC
IMS
RC
提案手法
コストの見積もり
実験と評価
まとめ
7
IMSアルゴリズム
停止時間の短いMark Sweep GC
マーク量の制御は重要
アプリケーションの処理とマーク処理を交互に行う
メモリに空きがある時からマークを始める
マークが遅すぎるとメモリ不足になる
マークが早すぎるとGC回数が増えすぎる
合計マーク量は前もって分からない
一般にマーク終了と同時にヒープを使い切る制御は
できない
8
一般的なIMSのマーク量制御
ヒープ占有量
ヒープ占有量がし Heap
きい値を超えたら
Heap×(k-1)/k
マーク開始
1allocateにつき
使用量
kマーク(傾き一定)
解放量
マーク量
一定の傾きkで増加
IMS開始
1サイクル
IMS終了
マーク
コスト
allocate clock
9
IMSのコストが増大する場合
ヒープが小さいとき
GC回数が増大
MSでもIMSでも起こる
RCとの組合わせ
により解決
早すぎるマーク
GC終了が早すぎ、一度
のGCで回収できるごみ
が少ない
GC回数が増大
RCと組合わせた場
合でも悪化を防ぐ
10
RC
参照回数を数えて、0になったら解放
スループットはヒープ使用率によらない
ただし、単独では循環参照を解放できない
循環参照のごみの解放は2つの手法に分かれる
Cycle Detection ([Lins,1992]など)
循環内部の参照を除く
バックアップGC
時々トレースGCを走らせて解放
本研究では
こちらを採用
11
バックアップGC
MSにより解放
([Weizenbaum, 1969] など)
メモリ不足になったらMSを走らせる
×最大停止時間はMSの停止による
IMSにより解放
([DeTreville, 1990] など)
○停止時間が短い
×スループットの評価は
ほとんどない
本研究ではこちらを採用
1
1
1
1
2
1
1
12
発表の流れ
背景
本研究の貢献
基本的なGC
提案手法
コストの見積もり
実験と評価
まとめ
13
コスト削減の方針
ヒープサイズが小さいときのコストの上昇を抑える
ヒープ使用率が高いときはRCを導入した方がコスト
は少ないのでは?
IMSのコストは「ヒープ使用率」に伴い増加
RCのコストは「参照の更新」と「解放したオブジェクト数」に
比例(ヒープ使用率によらない)
⇒ 循環参照ではないごみはRCに解放してもらい、
IMSをバックアップGCとして用いるハイブリッドGC
IMSのコストにも注意
マーク量の制御に工夫
14
RCとIMSのハイブリッドGC
RC と IMS が並行に
走る
RCが参照回数を維
持し、0になったら解
放
ヒープ占有率がしき
い値を超えたらIMS
がマーク開始
IMSのマーク中もRC
による解放を行う
スイープでは循環ご
みも解放
1
12
1
2
1
1
1
0
1
0
1
参照削除
参照削除 参照削除
マーク
マーク終了
RCより解放
ス循環のごみは
イープして循
マーク中でも
環ごみを解放
解放できない
RCにより解放
マークフェーズ
マーク開始前
スイープ
15
単純なマークで生じる問題
1 allocate につきk マー
クの場合
IMSサイクルをよく見て
みると・・・
○ マークフェーズに入るまで
は長い
× マークフェーズ中はヒープ
占有量が増えていないの
にマークを進めてしまう
⇒ IMS回数が増えすぎる
この静的制御を行うハ
イブリッドGCをS-Hybrid
と呼ぶ
30
占有量(S-Hybrid)
マーク量(S-Hybrid)
25
メモリ[MB]
20
15
10
5
0
0
50
100
150
200
250
allocate[MB]
16
ハイブリッドGCにおけるマーク量制御
要件
メモリ不足になる前にマークを終了する
IMS回数をできるだけ少なくする
RCがヒープの空き容量を増やすことに注目!
マークの最中にRCの解放がある
空き容量が増えたときはマークをさぼってよい
17
動的マーク量制御の提案
D-Hybrid GCの制御方法
最大未マーク量
空き容量
Heap
空き容量を定期的に監視
最大未マーク量/空き容量 ≦ k (定数) ヒープ占有量
を満たす最小の量をマーク
Heap×(k-1)/k
最大未マーク量=
(ヒープサイズ-マーク済み量) 使用量
特徴
占有量が増えなければマークを進めない
RCの解放がなく占有量が急激に増えても
メモリ不足にならずに間に合う
マーク量
IMS開始
IMS終了
18
D-Hybrid GCの利点
S-Hybridよりもヒープをたくさん利用
S-Hybridよりも1サイクルが長い
実行全体のサイクル数が減少
1サイクルのコストはあまり変わらないため、実行全体での
コストが減少
占有量(S-Hybrid)
35 マーク量(S-Hybrid)
30 占有量(D-Hybrid)
メモリ[MB]
25
マーク量(D-Hybrid)
20
15
10
5
0
0
50
100
150
allocate[MB]
200
250
19
停止時間の保証
一度の停止でのマーク
最大30msマークを行い、マークしたオブジェクトの子を
MSバッファに記録する
スイープ
Lazy sweepを行う(未実装)
最大停止時間を制限できる
現状では一度にスイープを行っている
停止時間はヒープサイズに比例
RC処理
更新情報をRCバッファに記録し、一定回数(20000)の
更新ごとに最大30msの処理を行う
20
発表の流れ
背景
本研究の貢献
基本的なGC
提案手法
コストの見積もり
実験と評価
まとめ
21
コストの見積もり(1)
性能モデルによりIMS、S-Hybrid、D-Hybridのコストを比較
コストの見積もり
コスト = mark + sweep + RC
アプリ全体を通した合計コスト
仮定
循環参照の割合が実行を通して一定 (c)
ヒープ使用率が実行を通して一定 (e)
予測
ヒープ使用率が高いとき D-Hybrid GC はコストの増加
が少ない
22
コストの見積もり(2)
コスト
循環参照=0.3
k=4
m:s:r=3:1:9
m:マーク
s :スイープ
r :RCの解放
IMS
S-Hybrid
D-Hybrid
20%程度のメモリ削減
1
1.5
2
2.5
ヒープサイズ/生存オブジェクト
3
ヒープ使用率 大
23
発表の流れ
背景
本研究の貢献
基本的なGC
提案手法
コストの見積もり
実験と評価
まとめ
24
実験
Jikes RVM (IBM) にIMS、S-Hybrid、D-Hybridを実装
評価したGC
(停止GC)
(基にしたGC)
(単純マーク制御)
(提案手法)
ベンチマーク
MS, GenMS
RC, IMS
S-Hybrid
D-Hybrid
SPECjvm98
( _213_jack, _228_javac )
_213_javac
27
0.35
( antlr, jython, ps )
_228_jack
9
~0.02
antlr
13
0.2
jython
13
~0.02
ps
21
~0.02
DaCapo
評価
最小ヒープ 循環参照の
[MB]
ベンチマーク
割合
停止時間
総実行時間
25
停止時間 (_228_jack, 16MB)
GC
MS
GenMS
IMS
RC
S-Hybrid
D-Hybrid
平均[ms]
1089
52.2
17
31.2
26.3
30.5
最大[ms]
1102
1109
32.1
30.4
105
110
最大停止時間が長い
停止時間が短い
26
実行時間 (1)
循環参照が少ないアプリ
IMS
RC
S-Hybrid
D-Hybrid
200
150
100
50
0
1
3
5
ヒープサイズ/生存オブジェクト
_228_jack
3000
IMS
RC
S-Hybrid
D-Hybrid
2500
2000
1500
1000
1000
total time[s]
total time[s]
250
total time[s]
800
600
400
500
200
0
0
1
3
5
ヒープサイズ/生存オブジェクト
jython
IMS
RC
S-Hybrid
D-Hybrid
1
3
5
ヒープサイズ/生存オブジェクト
ps
ヒープ使用率が高いときはIMSやS-HybridよりD-Hybridの方が速い
ヒープサイズ/生存オブジェクト=3~4で逆転
27
実行時間 (2)
循環参照が多いアプリ
250
IMS
RC
S-Hybrid
D-Hybrid
total time[s]
200
150
50
0
1
2
3
4
ヒープサイズ/生存オブジェクト
_213_javac
200
150
100
100
IMS
RC
S-Hybrid
D-Hybrid
300
250
total time[s]
50
0
1
3
5
ヒープサイズ/生存オブジェクト
antlr
RCはメモリ不足により実行不可能になる
IMSとの差は比較的小さいが、D-Hybridの方が速い
S-Hybridは非常に遅い
28
停止GCとの比較
total time[s]
80
150
60
40
100
20
0
1
3
5
7
ヒープサイズ/生存オブジェクト
_228_jack
MS
GenMS
D-Hybrid
200
total time[s]
MS
GenMS
D-Hybrid
100
50
0
1
3
5
7
9
ヒープサイズ/生存オブジェクト
antlr
GenMSが一番速い
MSとGenMSは停止時間が長い
D-Hybrid GCをmajor GCとして用いることが考えられる
29
発表の流れ
背景
本研究の貢献
基本的なGC
提案手法
コストの見積もり
実験と評価
まとめ
30
まとめ
ヒープ使用率が高い時のスループットの低下を
抑えたGCを設計、実装
コストモデルを用いて性能を予測
RCとIMSのハイブリッドGC
IMSのマーク量の動的制御
メモリを20%程度削減
ベンチマークでの比較
停止時間は100ms程度に抑えられた
ヒープサイズ/生存オブジェクト=3~4以下でD-Hybrid
の方がIMSよりも速くなった
31
今後の課題
Lazy Sweepの実装
Generational GCへの拡張
IMSとD-Hybridを使い分ける
ヒープ使用率が低いときはRC処理を行わない
マーク中に参照回数を数え、スイープ後に生存オブ
ジェクトが多ければRC処理を開始する
ヒープ使用率が低いときはIMSと同じ、ヒープ使用率
が高いときはD-Hybridと同じスループットを得られる
32