近代的なハードを使いこなすAzulガーベッジ・コレクター
Azul Systems社のZingというJava環境のGCの解説
http://www.infoq.com/articles/azul_gc_in_detail
GCはハードの進歩についていけていない
- 10年前、1GBのヒープは大きいとされていた
- 今日、通常のサーバでも256GB+24-48コアを装備
- この期間にメモリは100倍以上になったにもかかわらず一般的にGCが管理するHeapは二倍にしかなっていない
GCの働き
- Heap内で生きているオブジェクトを識別する
- 死んでいるオブジェクトのリソースを回復
- relocation/compaction: 定期的に生きているオブジェクトを動かして連続した領域を確保
ゴミ収集モード： 「Stop-the-world」か並列処理 (Parallelism and Concurrency)
- Stop-the-worldはアプリケーションを止めて作業をする
- 並列GCはアプリケーションが動いている間にバックグラウンドで作業する
(どれだけアプリが止るかの違いだと思う)
反応性 (Responsiveness and Sensitivity)
Stop-the-world GCだとレスポンスは当然悪くなる。あまり知られていないが、部分的並列と殆ど並列CGでも場合によってはレスポンスが悪くなる。スケーラビリティーと反応性はGCの頻度とその間に起きる処理に影響される。
- Live set size: 生きているオブジェクトのヒープにおいてしめる割合
- Heap size: Live set sizeにかかわらず、絶対的なメモリサイズが影響する場合もある
- Fragmentation and compaction: 断片化されたメモリをまとめる作業がGCの一番時間のかかる部分。断片化のパターンがパフォーマンスに影響を与える。
- Mutation rate: プログラムがどれだけの頻度でreferenceを更新するか
- 一般的にアプリケーションのロードに比例
- 次から次へと更新されるreferenceをについていかなければならないのでGCの負荷も高くなる
- Number of weak or soft references: hotspotを始めとするVMはweak/soft referenceはアプリを止めないと回復できない。なので、これらが多いとGCの負荷も増える
- Object lifetime: オブジェクトの生存パターン
以上の要因に左右されないパフォーマンスを持つGCが理想的だが、現状はそうではない。
ZingプラットフォームのAzulGCは以上の要因に影響をあまりうけないように開発された。
- 「guaranteed single-pass marker」によりmutation rateに影響をうけない
- compactionを並列で行う
- weak・soft referenceも並列処理で回復する
これで記事の1/3ぐらい。この後、Azul GCのアルゴリズムの解説、そして既存GCとの比較をしている。Java GCパフォーマンスに関心のある方は原文を…
このAzul GCだと
そうだ。
