280 likes | 445 Views
高いヒープ使用率の下で高速な インクリメンタル GC の設計と実装. 2005.2.16 電子情報工学科 4 年 近山・田浦研究室 30384 白井達也. 背景. メモリ管理の明示は煩雑 Garbage Collection ( GC) メモリの解放を自動的に行う GC のコスト スループット ⇒ 総実行時間 停止時間 ⇒ 対話プログラムの反応時間. 本研究の目的. 停止時間が短い スループットが安定している ヒープ使用率の増加に伴うスループットの低下を抑える. 今後の流れ. 基本的な GC アルゴリズム 本研究の GC 手法 コストモデル
E N D
高いヒープ使用率の下で高速なインクリメンタルGCの設計と実装高いヒープ使用率の下で高速なインクリメンタルGCの設計と実装 2005.2.16 電子情報工学科4年 近山・田浦研究室 30384 白井達也
背景 • メモリ管理の明示は煩雑 Garbage Collection(GC) • メモリの解放を自動的に行う • GCのコスト • スループット ⇒ 総実行時間 • 停止時間 ⇒ 対話プログラムの反応時間
本研究の目的 • 停止時間が短い • スループットが安定している • ヒープ使用率の増加に伴うスループットの低下を抑える
今後の流れ • 基本的なGCアルゴリズム • 本研究のGC手法 • コストモデル • 実装 • 実験と評価 • まとめと今後の課題
Reference Count GC(RC) • 手法 • オブジェクトから参照されている数(参照回数)を数える • ポインタが更新されたら参照回数も更新し、0になったら解放する • 長所 • 停止時間が短い • 効率が ヒープ使用率 によらない • 短所 • 循環参照を解放できない local or global variables root root 1 A 2 D 1 B 2 0 1 E F C
Mark Sweep GC(MS) • 手法 • rootからたどれたオブジェクトをmarkする • ヒープをsweepしてmarkされていないオブジェクトを解放 • 長所 • 循環参照のごみを 解放できる • 短所 • 停止時間が長い • ヒープ使用率が 高いと効率が悪くなる local or global variables root root T A T D F B F T F C E F
Incremental Mark Sweep GC(IMS) • MSの停止時間を短くする • 手法 • ユーザプログラムがメモリをallocateするたびに、少しずつmarkを行う
markの調整(1) • オブジェクトのallocateに対してmarkを進める • allocate : mark = 1 : k • ヒープがなくなる前にmarkを終わらせる • メモリ占有率が しきい値(k-1)/k を超えたらmarkを開始する
メモリ占有率 1サイクル IMS開始 IMS終了 markの調整(2) Heap (k-1)/k 使用率 allocate clock
Incremental Mark-Sweep GC(IMS) • 長所 • 停止時間が短い • 短所 • 使用率が高いと効率が悪くなる • ポインタ更新ごとの処理など、MSより効率が悪い
本研究の貢献 • 以下の要件を満たすGCを提案し、実装した 1.循環参照のごみも解放する 2.停止時間が短い 3.ヒープ使用率の上昇に伴う効率の低下を 抑える • コストモデルを設計し、従来の手法よりスループットが向上することを求めた
基本方針 • RCとIMSを併用する • 参照回数を維持し、0になったら解放する • メモリ占有率がしきい値を超えたらmarkを始め、mark終了後にsweepを行う • Mark量の動的な制御 • Mark中にRCによる解放が起こるため、markを行うタイミングを動的に制御して無駄なサイクルを無くし、効率を向上させる
1サイクル Mark量を静的に設定した場合 RCによる解放 Heap (k-1)/k 使用率 Mark量は一定 allocate clock Mark開始
1サイクル Mark量を動的に制御した場合 Heap (k-1)/k 使用率 空き容量とmark量をもとに次の停止のmark量を制御する allocate clock
Mark量の動的な制御 • ヒープが足りなくなる前にmarkを終わらせる • mark, sweepのサイクル数を減らす • RCによってヒープに十分余裕ができたときはmarkを行わない 1.IMSはヒープ使用率が(k-1)/kになったらmarkを 開始する 2.ヒープの空き容量と未mark量の比が k を 上回ったらmarkを行う ※ k はallocate量とmark量の比
コストモデル(1) • 仕事量の見積もり • コストの種類 = mark、 sweep、 RC • 総コスト = 1サイクルのコスト × サイクル数 • パラメータ • 循環参照の割合 (c) • allocate量とmark量の比 (k) • 1オブジェクトのmarkコスト (m) sweepコスト (s) RCのコスト (r) • 使用率(e)
コストモデル(2) m:s:r=3:1:9 循環参照=0.3 k=4 使用率が高くてもコストの増加が抑えられている
実装 • Jikes RVMのメモリ管理モジュール(JMTk)に実装 • JMTk : 50000行程度 • GC制御用に書き換えた部分が6000行程度 • MS, RC などが既に実装されている • 実装したGC • Incremental mark sweep GC • 停止時間の短いRC • Mark量を動的に制御したハイブリッドGC
実装上の問題 • 一方のGCバッファ内のオブジェクトを他方のGCが解放してしまう IMS IMS RC RC 解放 オブジェクト 解放済み バッファに記録したときのオブジェクトではない
IMSによるRCバッファへの影響 • 現象 • RCバッファ内のオブジェクトをsweepで解放 • 解決手法 • Sweepの前にRCの処理を行い、RCバッファのオブジェクトを無くす
RCによるIMSバッファへの影響 • 現象 • IMSバッファ内のオブジェクトの参照回数が0になって解放 • 解決手法 • Markしたオブジェクトは解放しない ※ Markされた後、そのサイクル中に参照回数が0になったオブジェクトは次のサイクルで解放される
評価 • 環境 • CPU : Intel Xeon 3.2GHz • メモリ : 2GB • OS : Debian Linux • VMのコンパイル • baseコンパイル (adaptiveコンパイルより2~3倍遅い) • プログラム • SPECjvm98 の _228_jack(使用メモリ9MB、循環参照5%未満) • SPECjvm98 の _213_javac(使用メモリ30MB、循環参照30%) • 評価 • 停止時間 • 実行時間(いろいろなヒープサイズで実行)
停止時間 • _228_jack (ヒープサイズ30MB)
停止時間 • _213_javac (ヒープサイズ60MB, RCのみ80MB)
_228_jack の実行時間(循環参照5%未満) 実行時間が増加している 実行時間の増加が抑えられている
_213_javacの実行時間(循環参照30%) 実行時間の増加が抑えられている 実行時間が増加している
まとめ • Mark量を動的に制御するハイブリッドGCを実装し、評価を行った • 平均停止時間は30ms程度、最大停止時間がsweepによる120msに収まった • メモリが小さい時でもスループットの低下が抑えられた • コストモデルを提案し、使用率が高いときにmark量を動的に制御するハイブリッドGCが有利になることを確かめた
今後の課題 • Lazy Sweep • Sweepの停止時間を短くする • ヒープ使用率が低い時の対応 • ヒープ使用率が低い時はRCの処理を止めることで、IMSと同じ性能にできる • mark時に参照回数を数える