IBM JDK5.0の詳細 第3話

デベロッパワークスでの連載だが、もう第3話が掲載された。

IBM - Japan

週1回をきっちり守るペースだ。
私のほうが忙しくてついていけない。

この連載ではもう少しJDK5.0でこうなったという記述をしてもらいたいのだが、残念ながら以前からある機能も合わせてIBM独自のウリを説明する感じに仕上がっている。

今回の記事はグラフも多く、見所がある。

とりあえず、拾ったのはココ。
verbose GCの出力が正式なXML記述になった。
JDK1.4ではXMLにも見えないこともないタグっぽい記述だった。

先日のJavaOneTokyoでSystem.gcJVMのオプションで明示的に禁止すべきだという意見がSunのパフォーマンス担当から聞かれたが、IBMもそれと同じことを書いている。

Forced garbage collections are not recommended, and so if elements are present in the verbose GC, consider rewriting the application to avoid interfering with the garbage collection routines or disabling explicit invocation of garbage collection with the -Xdisableexplicitgc command-line parameter.

Sunもそろそろdeprecatedにしてしまったら良いと思う。

さて、注目すべきはデフォルトになれなかった世代別GCなのだが、

On both measures, the gencon policy outperforms the optthruput policy. The gencon policy does better for two reasons. The first, obvious, one is that because the performance metric takes account of both response time and throughput, the gencon policy's combination of good throughput and good response times is likely to be a winner. The second reason is harder to quantify. The pattern of object creation and object death in this application benefits from the gencon policy's absence of fragmentation and rapid collections of sparsely populated nurseries. Other applications with similar performance criteria but different patterns of object creation might perform best with the optthruput policy.

なんというべきだろう。

デフォルトになれなかったからこそ、IBMユーザはJDK5.0からこのgenconを一度は試してみるべきになるのだろうか。

実はまだ読みきれていないのであまり書くべきではないが、Sunのクラスライブラリがimmutableを好み、細かなオブジェクトがどんどん回収されることを期待しているのだから、どんなプログラムでもgenconのほうが良いということにはならないのだろうか?
Brian氏がオブジェクトのライフタイムに気をつけるべきだと説明し、immutableは性能に問題がないと解説するのは世代別GCが前提である。
今回の連載ではHeapがフラグメンテーションを起こす場合、Compactionはrareであるべきだと書いてある。それが良く起こる場合、genconを試せと書いてある。しかしフラグメントが起こらない状況というのは余程アプリが要求するヒープ量が少なく、かつ用意できるヒープが十分に大きく、M&Sだけでこと足りる場合のみではないのだろうか。
最近、32Bit環境でのJ2EEではヒープが足りないということを痛感している。これは日本のSI現場では何でもIDにしてしまい、ほぼ全てのデータがStringであるというヒープ消費量の視点では劣悪な環境のせいだと考えている。
あるプロジェクトでインスタンス量の統計をプロファイラで見てみたらCharの配列が文句なしの容量で1位だった。*1そのうちの半分以上がGCの対象となっている。つまりimmutableなStringに対し、0をパディングしたり、スペースをパディングする度に新しいStringが作られてはフラグメンテーションを起こしているのである。
私は日本の現場でこそ世代別GCのほうが良いのではないかと思う。

*1:Stringはjavaパッケージがフィルタされているため直接表示されなかった