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