クラスデータ共有 (CDS) は、J2SE 5.0 の新機能で、Java プログラミング言語アプリケーション (特に小さなアプリケーション) の起動時間を短縮し、フットプリントを少なくすることを目的としています。Sun の提供するインストーラを使用して 32 ビットプラットフォームに JRE をインストールすると、インストーラがシステム jar ファイルから一連のクラスを private 内部表現にロードして、その表現を「共有アーカイブ」と呼ばれるファイルにダンプします。クラスデータ共有は Microsoft Windows 95/98/Me ではサポートされていません。Sun JRE インストーラを使用しない場合は、以下で説明するように、手動で行うこともできます。共有アーカイブはそれ以降の JVM 呼び出し中にメモリーマッピングされるので、これらのクラスをロードするコストが節約され、JVM のこれらのクラス用のメタデータの多くを複数の JVM 処理で共有できます。
J2SE 5.0 ではクラスデータ共有は、Java HotSpot Client VM でのみ、およびシリアルガベージコレクタでのみサポートされます。
CDS を 5.0 リリースに含める主要な動機は、CDS による起動時間の短縮です。CDS では、固定コスト (ある種のコアクラスのロードコスト) がなくなるため、小さなアプリケーションの場合により良い結果が得られます。使用するコアクラスの数に比べてアプリケーションが小さいほど、起動時間の節約比率が大きくなります。
新規 JVM インスタンスのフットプリントコストは、2 つの方法で削減されました。まず、共有アーカイブの一部 (現在は 5 - 6M バイト) が読み取り専用でマップされ、複数の JVM 処理で共有されます。これまでは、このデータは各 JVM インタフェースで複製されていました。2 番目は、共有アーカイブに Java Hotspot VM が使用する形でクラスデータが含まれているため、rt.jar
内のオリジナルクラス情報にアクセスするために使われていたメモリーが必要なくなりました。これらの節約により、同じマシン上でより多くのアプリケーションを同時に実行できます。Microsoft Windows では、処理フットプリント (さまざまなツールで測定) が増えたように見える場合があります。これは、処理のアドレス空間に大量のページがマッピングされるためです。これは、rt.jar
で一部を保持するために必要とされるメモリー量 (Microsoft Windows 内) が減ることで相殺されます。フットプリントの削減は、依然として優先度の高い課題です。
状況によっては、システム管理者が共有アーカイブを手動で再生成する必要があります。これは通常、Solaris 上で、インストールを実行するマシンとは異なるアーキテクチャーのマシンに、ネットワーク経由で Java SE パッケージがインストールされた場合にのみ必要です。これに関係なく、ここで取り上げる再生成に関する説明は、サポートされているすべてのプラットフォームに当てはまります。
共有アーカイブファイルは、JVM の共有ライブラリと同じ場所にあります。Unix プラットフォームでは、jre/lib/[arch]/client/classes.jsa
に格納され、Microsoft Windows プラットフォームでは jre/bin/client/classes.jsa
に格納されます。このファイルがある場合は、再生成を行う前に手動で削除する必要があります。
アーカイブを再生成するには、まず管理者としてログインします。ネットワークに接続した状態で、J2SE インストールと同じアーキテクチャーのマシンにログインし、インストールディレクトリに書き込み可能なアクセス権があることを確認します。次のコマンドを実行します。
java -Xshare:dump
アーカイブが生成されると、診断情報が出力されます。
クラスデータ共有機能は、使用できる条件が整えば自動的に有効になります。次に示すコマンド行オプションは、主に診断とデバッグを行うためのものです。今後のリリースで変更、または削除される可能性があります。
-Xshare:off
-Xshare:on
-Xshare:auto