@ITのニュースで見たのですが、日立が「Full GCの起きないアプリケーションサーバ」を発売するそうです。それはすごい。
@IT News Insightより、
「Cosminexus Version 8」発表
日立がアプリサーバ新版、Full GC回避し「世界を止めない」
私は、Java関係の研修で、たまにJavaのJVMオプションによるチューニングとかGCの動作なんかについて扱うこともあるのですが、Full GCの発生によるStop The Worldを回避するには、ヒープメモリの最大値(-Xmx)を増やすとか、オブジェクトリークを最小限にするよう（いらなくなったらすぐGCにかかるように）コーディングを工夫するとか、複数CPUマシンならコンカレントコレクタ(-XX:+UseConcMarkSweepGC)を使ってGCをアプリケーションスレッドと並列で走らせるとか、いくつかの方策が考えられると思うのですが、このアプリサーバはJVMの基本的な仕組みに手を入れる形で解決を試みているのですね。特定のオブジェクトを、ヒープとは別のメモリに格納するというのは、かなり大胆な発想といえそうです。
記事ではセッションオブジェクトに注目しているようですが、確かに、同時ユーザー数が多ければ、セッションオブジェクトの量もそれにつれて多くなりますので、比較的小さい容量に設定することが多いYoung世代（記事ではNew領域）はすぐに溢れ、Tenured世代（記事ではOld領域）に多くのオブジェクトが溜まっていくことが考えられます。Tenured世代はコンカレントコレクタなどの特殊な方式を使わない限りは、Tenured全体が溢れてFull GCが起こるまでは消費量が減ることはありません。オブジェクトが溢れるまでじっと待ちつづけるのではなく、ユーザーがログアウトして不要になったセッションオブジェクトを、その時々で消去していくことができれば、確かに、Full GCは起こりにくくなると言えそうです。非常にアグレッシブな方法ですね。
あとは、私のヘボな思いつきですと、Young世代の大きさを（-Xmnとかで）かなり大きくしておいて、マイナーコレクションをたくさん発生させて凌ぐ（マイナーコレクションの実施コストはFull GCと比べて格段に少ないので、多少回数が多くても、Full GCに比べればコストは少ないのでは？と思う）とか、セッションオブジェクト自体をプーリングして一定数以上のオブジェクトが作られないようにするとか（とはいえセッションオブジェクト自体を再利用したところで、セッションオブジェクト内に格納しているデータを初期化していたら、結局、それまで使っていた情報が不要オブジェクトとして溜まっていきそうなのでダメっぽいですかね）、ありそうですけど・・・。
日立のこのアプリサーバは、そういうチューニング的なことをしなくても、ただただ普通にコードを組むだけで、Full GCを回避してくれる、面倒見のいいアプリサーバを目指しているのでしょうね。