Cosminexus Day

2008年11月18日、株式会社日立製作所（以下、日立）が主催する「HITACHI Open Middleware World 2008 Autumn―Cosminexus DAY―」（⁠以下Cosminexus Day）が東京・六本木で開催されました。ここでは、セッション「Inside Java VM ～先進のメモリ管理技術とは～」の話題を中心に、イベントの模様を振り返ります。

SOAプラットフォームCosminexus

Cosminexusは、日立のSOA（Service OrientedArchitecture）プラットフォームです。SOAに基づき、人の持つ知識・ノウハウとシステムの融合を加速することを特長としており、Cosminexus Dayでもそれに沿ったセミナーやワークショップが多数開かれました。

実践例や先進技術紹介など5コースのセミナー

当日は、午前に特別講演や基調講演、午後からはセミナーが主体となりました。セミナーは大きく分けて、実践例を中心とする「実践！SOA⁠」⁠、構築・運用手法を解説する「SOA構築と運用の勘所⁠」⁠、最新技術を紹介する「先端技術活用講座⁠」⁠、適用事例が中心の「Cosminexus適用事例⁠」⁠、認定技術者が対象の「Cosminexus V8研修」の5コースです。このうち「先端技術活用講座」でのJava VM（Virtual Machine）メモリ管理に関するセッションを、このあと詳しく紹介します。

また、ランチタイムには「1時間でわかるCosminexus Day！」と題する早わかり解説が設けられたほか、パートナー企業を含む製品やソリューションが展示され、それらの解説が聞けるワークショップにも多くの人が集まりました。すべてのセミナー修了後には、日立ソフトボール部の監督や選手も出席し、サインボールなどが当たる抽選会もあり、会場は大いに盛り上がっていました。

Inside Java VM～先進のメモリ管理技術とは～

Cosminexus Dayでは、「⁠Inside Java VM ～先進のメモリ管理技術とは～」と題し、株式会社日立製作所ソフトウェア事業部 第2APソフト設計部 担当部長の中島恵氏によるセッションが開かれました。Java VMのメモリ管理にはどのような問題点があるのかを詳解するとともに、その解決策を紹介するもので、具体的には、Java VMがWebシステムのボトルネックになることを回避するFullGCレスを実現するしくみがCosminexus V8でどのように実現されているかを紹介するものでした。以降、その概要を紹介します。

Java VMのメモリ管理がボトルネックに

Webシステムが参照・更新するデータのサイズは、肥大化する一方で、どのようにシステムの安定稼働を実現していくかが大きな課題となっています。CPUの64ビット化でメモリ容量の増加は可能ですが、根本的な解決にはなりません。メモリ領域サイズの増大に伴って、Java VMのメモリ管理機能であるガベージコレクション（GC）による停止が長時間化するため、システムの性能劣化に陥ってしまうからです。そのため、こうしたGCに起因する問題を解消する新しい手法が必要になってきます。

Java VMにおけるGCのしくみ

解決策を探るために、まずはJava VMにおけるGCのしくみを詳しく見てみましょう。GCとは、Java VMが管理するメモリ領域（ヒープ領域）のうち使用済みの領域を破棄し、使用中の領域を整理して空き領域を作る動作です。Javaプロセスのメモリ領域にはJavaアプリが使用するJavaヒープ、クラスなどのメタ情報を格納するPermヒープ、Java VMやCプログラムが使用するCヒープ、スレッドごとに保持するスレッドスタックの4種類があります。このうち、GCの対象となるのはJavaヒープとPermヒープであり、パフォーマンスに大きく影響するのはJavaヒープに対するGCです。

さらに、Javaヒープは、New領域とOld領域に分けられます。New領域には、できたてのインスタンスを配置するEden領域と使用中のインスタンスを配置するSurvivor領域があります。Old領域には年齢の古いインスタンスを配置する業務プログラム使用領域、J2EEサーバが使用する領域、New領域用の退避領域があります（図1⁠）⁠。

Copy GCとFull GC

GCにはCopy GCとFull GCの2種類があります。Copy GCはNew領域のみを対象に使用済みのインスタンスをすべて削除する動作です。Eden領域がいっぱいになると発生し、使用中のインスタンスは隣の領域へ移動します。New領域で最も古いインスタンスはOld領域に移されます。一方のFull GCは、すべての領域を対象に使用済みのインスタンスをすべて削除する動作です。Old領域の業務プログラム使用領域がいっぱいになると発生します（図2⁠）⁠。

ここで問題になるのが、GCの実行に要する時間です。500M～1Gバイトのデータで比較した場合、Copy GCは0.01～0.7秒程度しかかかりませんが、Full GCでは1～数十秒も要してしまいます。Full GCは特に時間がかかり、Javaヒープのサイズ増加に比例して実行時間は増加します。またFull GCの実行中は業務処理が停止してしまうため、このボトルネックを解消する必要があります。

大胆な発想転換でボトルネックを解消

GCのボトルネック解消には、ノーマルGCやパラレルGC、コンカレントGCなど、従来からさまざまなアルゴリズムが存在しました。しかし、これらはいずれも根本的な解決策にはなりませんし、アルゴリズムの複雑化によりコントロール不可となってユーザの負担が増加してしまうという問題があります。

そこで、根本的に解決するために発想を大胆に転換し、メモリ領域を1つの枠組みで管理することにそもそも無理があるのではないかという発想から生まれたのが、新しいメモリ管理方式である「明示管理ヒープ方式」（⁠Eヒープ方式）です。

「Eヒープ領域」の利用によりFull GCの発生を抑止

Cosminexus V8では、Full GCによるボトルネックを解消するために、New領域およびOld領域に格納されるインスタンスの違いに着目しました。前述のようにNew領域には短命なインスタンスが格納され、Old領域にはセッション情報など長命なインスタンスが格納されます。Old領域に格納されたセッション情報はログオフ後も残存し蓄積するため、Full GCを発生させる原因となってしまいます。

Eヒープ方式ではセッションオブジェクトをGCの対象外である「Eヒープ領域」という新しい領域に格納するため、Full GCの発生を抑止します。これにより、業界初（日立調べ）のFull GCレスを実現しています（図3⁠）⁠。

以前の方式では、Old領域に格納していたセッションプールやスレッドプールといったJavaアプリのオブジェクトプールを、Eヒープ方式ではEヒープ領域に配置します。このため、Old領域にはセッション情報が蓄積しないため、Full GCレスが可能になります。

アプリの変更なしに利用可能なEヒープ方式

CosminexusにおけるEヒープ方式の優れている点として、既存アプリの変更なしに利用できることが挙げられます。具体的には、まずJavaアプリでのセッション生成時にCosminexusがセッションの割り当てとEヒープ領域の確保を実行します。以降、オブジェクトの生成およびセッションへのオブジェクト格納において、インスタンス生成時はまずNew領域に対して実行し、これを高速で処理できるCopy GCでEヒープ領域に移動します。Eヒープ領域に移動されるセッションオブジェクトはNew領域で関連付け情報を付加されるため、アプリ側ではヒープ方式を意識する必要がありません。

なおセッションの終了時には、CosminexusがEヒープ領域を削除します。Eヒープ領域を削除する場合、その削除する領域に共通データなど使用中のデータが存在すると、単純な削除では領域外参照によるアベンド（異常終了）が発生してしまいます。Eヒープ方式では、領域削除時に使用中オブジェクトを自動的に検出し、Javaヒープ領域へ移動します。このため、Full GCに頼らずにEヒープ領域を削除しても問題なく動作可能であり、Javaシステムの特長の一つであるメモリアクセスの堅牢性を確保しています。

極小のオーバヘッドにより処理性能への影響も微小

次に気になるのは、従来方式と比べたオーバヘッドの増加です。結論から述べると、Eヒープ方式によるオーバヘッド増加はほぼ気にならないレベルと言えます。

Eヒープ方式ではCopy GCを使用し、Copy GCの実行時にEヒープ領域への移動候補の解析と、Javaヒープ領域かEヒープ領域かの移動先判定を行っています。

これによるオーバヘッドは従来のCopy GCと比べて最大30%増加しますが、Copy GCの処理時間はもともと数十～数百ミリ秒と極小のため、実質的に処理性能への影響はほとんどありません。日立が試算した例では、従来方式で0.253秒だった平均Copy GC時間がEヒープ方式では0.328秒に30%増加し、処理件数は54万8819件から54万5486件へと0.61%の劣化でした。つまり、処理性能への影響は1%未満に留まっています（表1⁠）⁠。

独自開発のJava VMにより各種プラットフォームでFull GCレス

Eヒープ方式によるFull GCレスは、Cosminexus V8の大きな特長となっています。Cosminexus V8では、セッションオブジェクトの自動Eヒープ化を備えたJavaEEサーバとEヒープ領域を追加したJava VMとの密な連携により、業務アプリの変更なしにFull GCレスを実現しました。CosminexusではV5から全プラットフォームに独自Java VMを開発しており、OSやハードウェアの垣根を越え、CosminexusがサポートするすべてのプラットフォームでFull GCレスを実現可能にしています。