Jump to content 日本-日本語
日本HPホーム 製品 & サービス サポート & ドライバー ソリューション ご購入方法
≫  お問い合わせ

製品とサービス  >  ソフトウェアとOS  >  HP- UX Developer Edge

Javaのかなめ、
「ガベージ・コレクション」をやさしく学ぶ・後編

HP-UX/Integrityサーバー お問い合せ
コンテンツに進む
Javaのかなめ、「ガベージ・コレクション」をやさしく学ぶ・後編
Javaのかなめ、「ガベージ・コレクション」をやさしく学ぶ・後編
4種類のGCポリシー
Concurrent Mark-Sweep Collectorのメカニズム

Concurrent Mark-Sweep Collectorのメカニズム

「Concurrent Mark-Sweep Collector(以下、CMS)」は、上述した3種類のGCポリシーに共通する弱点である「メジャーGCによるアプリケーション停止時間」を大幅に短縮するGCポリシーである。メジャーGCにおけるマーク&スイープ処理の大半をアプリケーション・スレッドと並行(concurrent)して実行するのが、CMSのミソである。JVMオプションは「-XX:+UseConcMarkSweepGC」だ。

Concurrent Mark-Sweep Collectorのスレッド動作
図3:Concurrent Mark-Sweep Collectorのスレッド動作

上図は、CMSにおけるメジャーGCのスレッドの動作である。この図が示すように、同GCポリシーでは「Initial Mark」、「Concurrent Mark」、「Parallel Remark」、および「Concurrent Sweep」の4段階の処理が実行される。

Initial Markでは、マーク処理の起点となるオブジェクトに対してマーク付けが行われる。この処理はシングルスレッドで実行され、JVMのすべてのアプリケーションを一時停止する必要があるものの、ごくわずかな時間で終了するためにアプリケーション動作への影響はほとんどない。

つづくConcurrent Markでは、Initial Markでマークが付けられたオブジェクトを起点にオブジェクト間の参照を次々とたどり、Old領域内のすべての使用中オブジェクトにマークを付ける。この作業はシングルスレッドで実施されるが、アプリケーション・スレッドと並行して実行されるため、アプリケーションの動作が停止することはない。

次のParallel Remarkでは、アプリケーションを一時停止し、Concurrent Mark実行中のアプリケーション処理によって生じた変化分について追加のマーク付けを行う。ただし、Old領域全体のわずかな部分で済むため、ごく短時間の一時停止で済む。

最後のConcurrent Sweepは、マーク処理によって判明した使用済みオブジェクトを削除する。この作業もシングルスレッド動作であるが、アプリケーションを一時停止せずに並行して実施される。

以上が、CMSの動作メカニズムである。では実際にどのようなタイミングでGCが実行されるのか、見てみよう。

Concurrent Mark-Sweep Collectorの動作例
図4:Concurrent Mark-Sweep Collectorの動作例

この図は、時間の経過にともなうヒープ使用量の変化をHPjmeterを使ってグラフ化した図である。ここで、頻繁に繰り返されている水色および青色の三角印は、マイナーGCを表している。またマイナーGCと並行して、数字の「2」から「3」の部分ではCMSのConcurrent Markが実行され、また「3」から「5」の部分ではConcurrent Sweepが実行され、ヒープ使用量が大きく下がっていることが分かるだろう。

またCMSでは、マーク処理やスイープ処理の最中にも、従来通りのマイナーGCが実行される。もっとも、CMSの場合はFrom領域とTo領域がデフォルトで極端に小さく設定されているため、オブジェクトのほとんどはEden領域からすぐにOld領域へと移動する。これは世代別GCの本来の目的からは外れたふるまいだが、CMSではOld領域のGC(メジャーGC)によるアプリケーションへの影響がわずかであるため、逆にFrom/To領域を使用しない方がパフォーマンスを向上できるのである。

CMSの利用が適しているのは、ヒープ・サイズが大きく通常のメジャーGCでは長時間を要してしまうケースや、メジャーGCによるアプリケーションの一時停止が許容できないような用途である。JVMのリアルタイム性が向上するため、インタラクティブなアプリケーションにも向いているだろう。

GC設定を自動化する「エルゴノミクス」とは

ここまで見てきたとおり、HotSpot VMのGCのメカニズムは複雑だ。よって、例えばYoung領域やOld領域のサイズ設定をはじめ、GCポリシーの選択などの最適解を導くのは容易ではない。この複雑なGCのふるまいと個々のアプリケーションの特性を十分に理解し、最適な構成や設定値をチューニングする必要が生じるのである。

そこでJ2SE 5.0では、こうしたGCチューニングの面倒さを解消する新機能「エルゴノミクス」が導入された。エルゴノミクスとは、JVMの実行環境に応じて、GC設定をできるだけ自動的に最適化する機能である。

まずJVMは、それが動作するシステムがサーバクラス・マシン(豊富なCPUとメモリを備えたマシン)か否かを判定する。具体的には、2個以上のCPUおよび2GB以上のメモリを搭載したマシンをサーバクラス・マシンと判定する。

サーバクラス・マシンと判断された場合、GCポリシーとしてはParallel Collectorがデフォルトで選択される。また初期ヒープ・サイズは搭載メモリ量の1/64の大きさに設定され、最大ヒープ・サイズは同じく1/4の大きさ(最大1GB)に設定される。例えばメモリを4GB搭載したマシンならば、初期ヒープ・サイズは64MB、最大ヒープ・サイズは1GBとなる。また、Young領域のEden領域およびFrom/To領域のサイズも適切に設定される。

J2SE 5.0以降のHotSpot VMでは、こうしたエルゴノミクスによる自動調節が働くため、以前のような手取り足取りのJVMチューニングを行わずとも一定のパフォーマンスを引き出せる仕組みになっている。

以上、今回はJava HotSpot VMのガベージ・コレクションについて、そのおおまかな動作メカニズムを紹介した。バージョン・アップを追うごとに大きく進化するGCの能力をフルに引き出す上で、お役立ていただきたい。

トップへ 戻る    

その他のコラム(特集)もお読み下さい

 
 

本ページの内容は執筆時の情報に基づいており、異なる場合があります。

お問い合わせ

ご購入前のお問い合わせ


ご購入後のお問い合わせ

オンラインサポート
製品の標準保証でご利用いただける無償のサービスです。

ショールーム

ショールーム 導入をご検討のお客様へ
業務アプリケーションの継続・標準化・開発性とシステム担当者様、システム開発者様が抱える悩み・疑問に対する解決策実体験して頂けます。
印刷用画面へ
プライバシー ご利用条件・免責事項 ウェブマスターに連絡