Garbage First

ectoというツールから更新チャレンジ。
何故か、MovableTypeのバージョンを上げてから新しいエントリが作れなくなっていたんだけど、
このエントリが入るならXMLRPCの口からなら登録できるということだな。
→やっぱ使えんからWebから整形(2009/05/16)
久々の更新。 プライベートも色々あったものの、
まとめると長そうだからまた今度にしよう。
今日は、Javaに導入される新しいGarbageCollection方式に注目。
リソースの後始末を考えなくてもよい怠け者のためのお掃除機能であるGC。
気がつけばGCの方式には、結構色んなものが増えていた。
とは、言うモノの7年前の世代別GC以降はパラダイムが違うようなものは出てきていないと思う。
今回、前々からJDK7で導入予定ってことになっていた新方式のGCが
JDK6u14のEarlyAccess版で試せるようになっているらしいので試してみることにした。

というオプションで有効になる。
jvisualvm で、VisualGCのプラグインを入れるとGCの様子がGUIで確認できるが
このGCはまだ対応していないためか中身をみることができない。
名前は、Garbage First(G1) という。
世代別のGCだとNewGenerationとOldGenerationに
ヒープの領域を区切ってしまうため、
そのサイジングがチューニングのポイントになったりする。
G1では、ヒープに固定的な区切りは設けない。
その代わりに、ヒープをいくつかの領域(Region)に分けて管理する。
一回のGCで対象になるのは、これらの領域のウチの一部になる。
いわば、動的に領域の世代を決めているようなもの。
この領域の選択は、GCの効果が高い領域を選ぶようになっている。
その選択のためにライトバリアを利用しているらしい
と、どっかで見た記憶があるがどこか忘れた。ググって出てきたのは、コレか。(PDF)
要は、何人かで公園を監視していてゴミの多い場所を見つけてて
GCのときに、そこからゴミ拾いをするような感じらしい。
でもって、GCのやり方はCopyingGCと同じで生きているオブジェクトを
Compactionするんでヒープのフラグメントも避けられる、とか。
G1では、各所に出てくるが”realtime goal”を実現することが
大きなメリットであると強調されている。
つまり、応答性の改善だ。
今まで、ConcurrentMarkSweepと並列Stop-the-world Collecterを使って
頑張っていた停止時間のコントロールをGCアルゴリズムそのものを変えて
改善しようということのようだ。
上のPDFでは、その応答性能を出すためにどうするか書かれているはず
なんだけど詳しく読んでない。
考え方からすると、より効率よくGarbageを集められそうなので
メモリ確保量も、以前より少なくても動きそうな感じはする。
しかし、メモリ管理というよりはエクステントを使った
ファイルシステムのように見えるなぁ。
しばらく、自分の環境で使ってみて評価するつもり。
最近プライベートな環境は全てMacに移行しているのでそっちで試せないのは寂しいところ。
P.S.
MacOSX の EarlyAccess版がSunのupdate13ベースになった。
SnowLeopardには載ってくるかな？