uCosminexus Application Runtime - Cosminexus Developer's Kit for Java 機能解説・リファレンス

3021-3-K02

前書き

対象製品

●適用OS：Red Hat Enterprise Linux 7（AMD/Intel 64），Red Hat Enterprise Linux 8（AMD/Intel 64）

P-9W43-9M11 uCosminexus Application Runtime with Java for Apache Tomcat 01-00

このプログラムプロダクトのほかにもこのマニュアルをご利用になれる場合があります。詳細は「リリースノート」でご確認ください。

輸出時の注意

本製品を輸出される場合には、外国為替及び外国貿易法の規制並びに米国輸出管理規則など外国の輸出関連法規をご確認の上、必要な手続きをお取りください。

なお、不明な場合は、弊社担当営業にお問い合わせください。

商標類

HITACHI，Cosminexus，uCosminexusは，株式会社 日立製作所の商標または登録商標です。

Apache Tomcatは，Apache Software Foundationの米国およびその他の国における登録商標または商標です。

Linuxは，Linus Torvalds氏の日本およびその他の国における登録商標または商標です。

Microsoftは，マイクロソフト 企業グループの商標です。

OracleおよびJavaは，オラクルおよびその関連会社の登録商標です。

Red Hat Enterprise Linux is a registered trademark of Red Hat, Inc. in the United States and other countries.

Red Hat Enterprise Linuxは，米国およびその他の国におけるRed Hat, Inc.の登録商標です。

UNIXは，The Open Groupの登録商標です。

Windowsは，マイクロソフト 企業グループの商標です。

その他記載の会社名，製品名などは，それぞれの会社の商標もしくは登録商標です。

This product includes software developed by the Apache Software Foundation (http://www.apache.org/).

Java is a registered trademark of Oracle and/or its affiliates.

発行

2022年 7月 3021-3-K02

著作権

All Rights Reserved. Copyright (C) 2022, Hitachi, Ltd.

奥付

マニュアル発行元

株式会社 日立製作所

〒100‒8280　東京都千代田区丸の内一丁目6番6号

はじめに

uCosminexus Application Runtime with Java for Apache Tomcatは，日立独自の拡張機能を備えたJava実行環境とJDKを提供するCosminexus Developer's Kit for Javaを同梱しています。

このマニュアルでは，Cosminexus Developer's Kit for Javaについて，日立独自の拡張機能の概要，提供機能を利用したメモリチューニングとトラブルシューティングの方法を解説しています（第1編　解説編）。また，Cosminexus Developer's Kit for Javaが提供する各機能の詳細や使い方を説明しています（第2編　リファレンス編）。

なお，このマニュアルでは，Cosminexus Developer's Kit for Javaを「日立JavaVM」と呼んでいます。また，関連マニュアルである「uCosminexus Application Runtime for Apache Tomcat ユーザーズガイド」を「uCosminexus Application Runtime ユーザーズガイド」と表記しています。

対象読者

uCosminexus Application Runtime with Javaをご利用のお客様で，次に該当する方を対象としています。

クラウドまたはオンプレミス環境に構築する業務システム（アプリケーションサーバシステム）を対象に，日立JavaVMを利用して，信頼性確保に関するアプリケーションの機能（稼働監視，障害検知，保守資料収集）を設計，開発する人。

日立JavaVMを利用して開発したアプリケーションサーバシステムの運用管理，保守を担当する人。

このマニュアルで使用する記号

このマニュアルで使用している記号を，次のように定義します。

記号

意　味

　｜

横に並べられた複数の項目に対する項目間の区切りを示し，「または」を意味します。

（例）　A｜B

　AまたはBを指定することを示します。

{ 　 }

この記号で囲まれている複数の項目のうちから1つを選択することを示します。項目が横に並べられ，記号｜で区切られている場合は，そのうちの1つを選択します。

（例）　｛A｜B｜C｝

　A，BまたはCのどれかを指定することを示します。

［　］

この記号で囲まれている項目は省略してもよいことを示します。複数の項目が横に並べて記述されている場合には，すべてを省略するか，記号｛ ｝と同じくどれか1つを選択します。

（例1）　［A］

　「何も指定しない」か「Aを指定する」ことを示します。

（例2）　［B｜C］

　「何も指定しない」か「BまたはCを指定する」ことを示します。

…

記述が省略されていることを示します。

（例）　ABC…

　ABCの後ろに記述があり，その記述が省略されていることを示します。

<　>

この記号で囲まれている項目は，該当する要素やファイルなどを指定したり，該当する要素が表示されたりすることを示します。

（例1）　<プロパティ>

　プロパティを記述します。またはプロパティが表示されます。

（例2）　<ファイル名>

　ファイル名を指定します。

...

この記号の直前に示す記号を繰り返し，複数個指定できることを示します。

（例）　<プロパティ>...

　プロパティは複数個，繰り返して指定できます。

第1編　解説編

1　概要

Cosminexus Developer's Kit for Java（以降，「日立JavaVM」と呼びます）は，日立独自の拡張機能を備えたJava実行環境とJDKを提供しています。

この章では，日立JavaVMの拡張機能の概要と，日立JavaVMを利用する場合のシステム構築，運用のポイントについて説明します。

1.1　日立JavaVMの提供機能の概要

日立JavaVMは，アプリケーションサーバシステムの安定稼働を支援する拡張機能を備えています。拡張機能の利用によって，システムの処理性能を高めるためのチューニングに使用する情報や，障害発生時の調査・分析といったトラブルシューティングに使用する各種情報を取得できます。

ヒント

uCosminexus Application Runtime with Javaが提供する日立Java VMは，Java SE 11に準拠しています。対応するOracle社製のJDKバージョンは，JDK 11です。

1.1.1　日立JavaVMの特長

日立JavaVMを利用すると，標準のJavaVMと比較して，より多く詳細な粒度でトラブルシューティングに役立つ情報を取得できます。万一の障害発生時でも，取得した各種情報を基に迅速な問題解決につなげることができます。

日立JavaVMでは，スレッドダンプ出力時，日立独自に拡張された情報（拡張スレッドダンプ情報）を取得できます。拡張スレッドダンプ情報の活用によって，トラブルの切り分けや原因個所の特定，要因調査を容易に実施できます。

日立JavaVMでは，アプリケーション実行時のメモリ使用量を把握するために必要となる情報（拡張verbosegc情報※）をJavaVMログファイルに出力します。この情報を基に，処理性能に影響を及ぼす要因を特定し，適切なチューニングを実施することで，システムの可用性向上を図れます。さらに，日立JavaVMでは，トラブルの要因分析やシステムの状態確認に利用できる情報も，JavaVMログファイルに出力されるログから取得できます。

注※

GC（ガーベージコレクション）実行時の各領域の詳細なメモリサイズが出力されます。

1.1.2　拡張機能の概要

日立JavaVMが提供する拡張機能の概要を次の表に示します。

各機能の詳細は，「4.　日立JavaVMの機能詳細」を参照してください。

表1‒1　日立JavaVMが提供する機能

機能

概要

クラス別統計機能

クラスごとに，参照関係にあるクラスのインスタンスの情報（クラス別統計情報）を拡張スレッドダンプに出力できます。

インスタンス統計機能※

クラスごとに，クラスのインスタンスの数やインスタンスの合計サイズを拡張スレッドダンプに出力できます。

STATICメンバ統計機能※

クラスごとに，staticメンバが持つインスタンスの合計サイズを拡張スレッドダンプに出力できます。

参照関係情報出力機能※

指定したクラスのインスタンスの参照関係を，先頭から順番に拡張スレッドダンプに出力できます。

統計前のGC選択機能※

クラス別統計情報の出力前に実行する処理を選択できます。

Tenured領域内不要オブジェクト統計機能※

Tenured領域内で不要となったオブジェクトを特定できます。

Tenured増加要因の基点オブジェクトリスト出力機能※

Tenured領域内不要オブジェクト統計機能を使って特定した，不要なオブジェクトの基点となるオブジェクトの情報を拡張スレッドダンプに出力できます。

クラス別統計情報解析機能

拡張スレッドダンプファイルに出力されたクラス別統計情報をCSV形式で出力できます。

Survivor領域の年齢分布情報出力機能

CopyGC実行時に，Survivor領域の使用状況が調査できます。この情報は，メモリサイズのチューニングに使用できます。

JITコンパイル時のCヒープ確保量の上限値設定機能

JITコンパイルで使用するCヒープのサイズに上限値を設定できます。上限値を超えた場合は，JITコンパイルが中止され，以降のコンパイルはインタプリタ方式で実行されます。これによって，JavaVMの強制終了を防ぎ，システムの停止を抑止できます。

スレッド数の上限値設定機能

使用できるスレッド数に上限値を設定できます。あらかじめ使用するスレッド数の上限を把握し，その数を基にCヒープに割り当てるメモリサイズを決定することで，Cヒープ不足の発生を防止します。

ファイナライズ滞留解消機能

ファイナライズ処理の滞留を解消し，OS資源の解放遅れなどの発生を抑止できます。

ログファイルの非同期出力機能

ログのファイル出力を非同期で実行できます。ログのファイル出力処理を専用で実行するスレッドを用意し，ログ出力以外の処理を実行するスレッドと処理のタイミングを合わせることなく，ログファイルを出力できます。

圧縮オブジェクトポインタ機能

Javaアプリケーションによって作成されるJavaオブジェクトのサイズを圧縮することで，Javaアプリケーションのメモリ使用効率を向上できます。

注※

クラス別統計情報を出力するクラス別統計機能の一つです。

1.2　システム構築・運用のポイント

ここでは，日立JavaVMを利用してアプリケーションサーバシステムを構築および運用する際に必要な作業のポイントと注意事項について説明します。

1.2.1　システム構築のポイント

(1)　インストールとセットアップ

日立JavaVMを利用するために，次の作業を実施します。

uCosminexus Application Runtime with Javaのインストール

uCosminexus Application Runtime with Javaを，マニュアル「uCosminexus Application Runtime ユーザーズガイド」の手順に従って導入対象の環境へインストールします。uCosminexus Application Runtime with Javaをインストールすることで，日立JavaVMがインストールされます。

日立JavaVMを使用するための設定

日立JavaVMを使用してトラブルシューティングを行うには，JavaVM起動オプションの設定や，導入対象の環境（アプリケーション基盤）に応じた設定が必要です。マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してデフォルトの設定値を確認してください。

Java実行環境として日立JavaVMを使用するには，アプリケーションサーバシステムを動作させる前に，設定を実施してください。

(2)　メモリチューニングによるシステム処理性能の確保

日立JavaVMを適用したシステムの処理性能を高めるには，基盤となるJavaVM自体のチューニングを適切に実施する必要があります。

特に，GC（ガーベージコレクション）の仕組みを考慮した上で，適切なメモリ管理ができるようにチューニングすることで，システムの処理性能が向上します。GCの挙動はメモリ管理方式によって変わるため，システムの要件に合わせて適切なメモリ管理方式を選択してください。日立JavaVMでは，2つのメモリ管理方式（SerialGC，G1GC）を選択できます。

日立JavaVMによるメモリ管理の仕組みとメモリチューニングの方法は，「2.　メモリチューニング」を参照してください。

1.2.2　システム運用のポイント

(1)　トラブルシューティング

日立JavaVMを利用して運用中のアプリケーションサーバシステムに障害が発生した場合，障害からの速やかな回復が最も重要な事項です。さらに障害を繰り返し発生させないためには，原因究明も必要です。トラブルシューティングでは，発生したトラブルの内容に応じて，日立JavaVMから出力された情報（資料）を活用し，原因の切り分けや発生要因の特定などを行います。日立JavaVMを利用したトラブルシューティングの詳細は，「3.　トラブルシューティング」を参照してください。

ヒント

「3.　トラブルシューティング」では，システム運用時に発生する代表的なトラブルに対して確認が必要な資料を示し，原因究明の手順を解説しています。システムの運用を開始する前に，該当の資料や手順の流れを確認しておくことをお勧めします。

(2)　サポートサービスの利用

ご契約のサポートサービスに応じて，日立JavaVMに関する技術情報や改良版の提供などのサービスを利用できます。詳細については，マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

1.2.3　システム運用の注意事項

日立JavaVMを利用してシステムを運用する場合の注意事項について説明します。

(1)　一時ファイルに関する注意事項

日立JavaVMは，ほかのプロセスとの通信のため，次のディレクトリに一時ファイルを作成して使用します。

/tmp/hsperfdata_<ユーザ名>/<プロセスID>

このため，日立JavaVMを正常に動作させるには，/tmpに書き込み権限が必要となります。なお，作成された一時ファイルやディレクトリのアクセス権を変更したり，JavaVM起動中に一時ファイルを削除したりする場合の動作は保証しません。

2　メモリチューニング

この章では，日立JavaVMによるメモリ管理の仕組みとメモリチューニングの方法について説明します。

2.1　GCとJavaVMのメモリ管理

システムの処理性能を高めるには，基盤となるJavaVM自体のチューニングを適切に実施する必要があります。

ここでは，GC（ガーベージコレクション）とJavaVMでのメモリ管理の仕組みの概要について説明します。

2.1.1　GCとJavaVMのメモリ管理の概要

JavaVMのチューニングの目的は，システムの処理性能の向上です。特に，GCの仕組みを考慮した上で，適切なメモリ管理ができるようにチューニングすることで，システムの処理性能が向上します。GCの挙動はメモリ管理方式によって変わるため，システムの要件に合わせて適切なメモリ管理方式を選択してください。日立JavaVMでは，次の2つのメモリ管理方式を選択できます。

表2‒1　各メモリ管理方式の特長

項番

メモリ管理方式

特長

1

SerialGC

スループットを重視するシステムに適している。

GCには長い時間が掛かるGC（FullGC）と，短い時間で終わるGC（CopyGC）がある。GCの時間を制御できない。

メモリサイズのチューニングをすることで，FullGCの発生回数を減少できる。

2

G1GC

大規模なメモリを使用するシステムやレスポンスを重視するシステムに適している。

項番1の方式と比較してスループットが低い。

GCには長い時間が掛かるGC（FullGC）と，短い時間で終わるGC（YoungGC，MixedGC）がある。YoungGCとMixedGCのGCの目標時間を指定できる。

メモリサイズのチューニングに加え，GCを行うスレッド数を増やすことで，FullGCの発生回数を減少できる。

SerialGCについては「2.2　SerialGCの仕組みとJavaVMのメモリチューニング」を，G1GCについては「2.3　G1GCの仕組みとJavaVMのメモリチューニング」を参照してください。

2.1.2　プロセスごとに使用するメモリの見積もり

アプリケーションサーバの各プロセスで使用するメモリの使用量の見積もりについて説明します。

(1)　アプリケーションサーバが使用する仮想メモリの使用量の見積もり

ここでは，仮想メモリの使用量の見積もり方法について説明します。なお，仮想メモリの使用量の計算式に使用しているJavaVM起動時のオプションの詳細については，「2.2.1(5)　SerialGC使用時のJavaVMで使用するメモリ空間の構成とJavaVMオプション」を参照してください。

(a)　仮想メモリの使用量の計算式

仮想メモリの使用量（単位：メガバイト）の計算式を次に示します。

アプリケーションサーバの仮想メモリの使用量＝A＋B＋C＋（D＋22＋E）×F＋H

（凡例）

A：Javaヒープサイズ

初期値は，JavaVM起動時の-Xmsオプションに指定した値です。この値は，アプリケーションサーバ起動中に，最大でJavaVM起動時の-Xmxオプションに指定した値まで拡張されます。

B：Metaspace領域サイズ

初期値は，JavaVMが割り当てた値です。この値は，アプリケーションサーバ起動中に，最大でJavaVM起動時の-XX:MaxMetaspaceSizeオプションに指定した値まで拡張されます。

C：ネイティブプログラム使用領域サイズ

ネイティブプログラム使用領域サイズの値について，次の表に示します。

表2‒2　ネイティブプログラム使用領域サイズの値

OS種別

使用領域サイズの値（単位：メガバイト）

Linux

300

D：アプリケーションサーバのスレッド数

アプリケーションサーバが使用するスレッド数です。アプリケーションサーバが使用するスレッド数については，マニュアル「uCosminexus Application Runtime ユーザーズガイド」のリソースの見積もりに関する説明を参照してください。

E：G1GC使用時のスレッド数

G1GCを使用する場合に作られるスレッドです。SerialGCを使用する場合は作られません。G1GCを使用する場合は，論理CPU数の3倍の値にしてください。

F：スタック領域サイズ

JavaVM起動時の-Xssオプションに指定した値です。

H：コードキャッシュ領域の最大サイズ

JavaVM起動時の-XX:ReservedCodeCacheSizeオプションに指定した値です。

(b)　仮想メモリの使用量を計算する場合の注意事項

ネイティブプログラム使用領域サイズの値は変動します。値が変動するのは次のような場合です。

ORBのトレースサイズを変更した場合

JDBCドライバの使用領域サイズの値を変更した場合

使用する製品のネイティブライブラリ使用領域サイズの値を変更した場合

このような場合，製品ごとのメモリ使用量をネイティブプログラム使用領域サイズの値に加えてください。製品ごとのメモリ使用量は，使用する製品のドキュメントに従って算出してください。

アプリケーションサーバの標準構成で使用する仮想メモリの使用量は，使用するソフトウェア製品の影響で，見積もり値よりも大きくなる場合があります。その場合の増加分については，仮想メモリの使用量の値に加えてください。増加分のメモリ使用量は，使用するソフトウェア製品のドキュメントに従い，製品ごとのメモリ使用量を算出してください。

Linuxの場合，メモリのスワップファイルが不足すると，システムがスローダウンします。仮想メモリの上限値を，実メモリサイズ分指定することをお勧めします。

2.2　SerialGCの仕組みとJavaVMのメモリチューニング

ここでは，SerialGCの仕組みとJavaVMのメモリチューニングの方法について説明します。

2.2.1　SerialGCの仕組み

SerialGCの仕組みについて説明します。

(1)　SerialGCの概要

GCは，プログラムが使用し終わったメモリ領域を自動的に回収して，ほかのプログラムが利用できるようにするための技術です。

GCの実行中は，プログラムの処理が停止します。このため，GCを適切に実行できるかどうかが，システムの処理性能に大きく影響します。

プログラムの中でnewによって作成されたJavaオブジェクトは，JavaVMが管理するメモリ領域に格納されます。Javaオブジェクトが作成されてから不要になるまでの期間を，Javaオブジェクトの寿命といいます。

Javaオブジェクトには，寿命の短いオブジェクトと寿命の長いオブジェクトがあります。サーバサイドで動作するJavaアプリケーションの場合，リクエストやレスポンス，トランザクション管理などで，多くのJavaオブジェクトが作成されます。これらのJavaオブジェクトは，その処理が終わると不要になる，寿命が短いオブジェクトです。一方，アプリケーションの動作中使用され続けるJavaオブジェクトは，寿命が長いオブジェクトです。

効果的なGCを実行するためには，寿命の短いオブジェクトに対してGCを実行して，効率良くメモリ領域を回収することが必要です。また，繰り返し使用される寿命の長いオブジェクトに対する不要なGCを抑止することが，システムの処理性能の低下防止につながります。これを実現するのが，世代別GCです。

世代別GCでは，Javaオブジェクトを，寿命が短いオブジェクトが格納されるNew領域と，寿命が長いオブジェクトが格納されるTenured領域に分けて管理します。New領域はさらに，newによって作成されたばかりのオブジェクトが格納されるEden領域と，1回以上のGCの対象になり，回収されなかったオブジェクトが格納されるSurvivor領域に分けられます。New領域内で一定回数以上のGCの対象になったJavaオブジェクトは，長期間必要なJavaオブジェクトと判断され，Tenured領域に移動します。

世代別GCで管理するメモリ空間とJavaオブジェクトの概要を次の図に示します。

図2‒1　世代別GCで管理するメモリ空間とJavaオブジェクトの概要

SerialGCの世代別GCで実行されるGCには，次の2種類があります。

CopyGC

Eden領域とSurvivor領域を対象にしたGCです。Javaオブジェクトの作成によって，Eden領域を使い切ると発生します。

FullGC

Tenured領域も含む，JavaVM固有領域全体を対象にしたGCです。Tenured領域を一定サイズまで使うと発生します。

一般的に，CopyGCの方が，FullGCよりも短い時間で処理できます。

次に，GCの処理について，あるJavaオブジェクト（オブジェクトA）を例にして説明します。

Eden領域で実行される処理

オブジェクトAの作成後，1回目のCopyGCが実行された時点で使用されていない場合，オブジェクトAは破棄されます。

1回目のCopyGCが実行された時点で使用されていた場合，オブジェクトAはEden領域からSurvivor領域に移動します。

Survivor領域で実行される処理

Survivor領域に移動したオブジェクトAは，そのあと何回かCopyGCが実行されると，Survivor領域からTenured領域に移動します。移動する回数のしきい値は，JavaVMオプションやJavaヒープの利用状況によって異なります。「図2-1」では，しきい値をn回としています。

Survivor領域への移動後，n回目未満のCopyGCが実行された時点でオブジェクトAが使用されていなかった場合，オブジェクトAはそのCopyGCで破棄されます。

Tenured領域で実行される処理

オブジェクトAがTenured領域に移動した場合，そのあとのCopyGCでオブジェクトAが破棄されることはありません。CopyGCは，Eden領域とSurvivor領域だけを対象としているためです。

このようにしてオブジェクトが移動することで，Tenured領域の使用サイズは増加します。Tenured領域を一定サイズまで使うと，FullGCが発生します。

JavaVMのチューニングでは，JavaVMオプションでそれぞれのメモリ空間のサイズや割合を適切に設定することで，不要なオブジェクトがTenured領域に移動することを抑止します。これによって，FullGCが頻発することを防ぎます。

(2)　オブジェクトの寿命と年齢の関係

オブジェクトがCopyGCの対象になった回数をオブジェクトの年齢といいます。

オブジェクトの寿命と年齢の関係を次の図に示します。

図2‒2　オブジェクトの寿命と年齢の関係

アプリケーションが開始して初期化処理が完了したあとで，何度かのCopyGCが実行されると，長期間必要になる寿命の長いオブジェクトはTenured領域に移動します。このため，アプリケーションの開始後しばらくすると，Javaヒープの状態は安定し，作成されるJavaオブジェクトとしては，寿命が短いオブジェクトが多くなります。特に，New領域のチューニングが適切にできている場合，Javaヒープが安定したあとの大半のオブジェクトは，1回目のCopyGCで回収される，寿命が短いオブジェクトになります。

(3)　CopyGCの仕組み

JavaVMでは，CopyGCの対象になるNew領域のメモリ空間を，Eden領域，Survivor領域に分けて管理します。さらに，Survivor領域は，From空間とTo空間に分けられます。From空間とTo空間は，同じメモリサイズです。

New領域の構成を次の図に示します。

図2‒3　New領域の構成

Eden領域は，newによって作成されたオブジェクトが最初に格納される領域です。プログラムでnewが実行されると，Eden領域のメモリが確保されます。

Eden領域がいっぱいになると，CopyGCが実行されます。CopyGCでは，次の処理が実行されます。

Eden領域，およびSurvivor領域のFrom空間にあるJavaオブジェクトのうち，使用中のJavaオブジェクトが，Survivor領域のTo空間にコピーされます。使用されていないJavaオブジェクトは破棄されます。

Survivor領域のTo空間とFrom空間が入れ替わります。

この結果，Eden領域とTo空間は空になり，使用中のオブジェクトはFrom空間に存在することになります。

CopyGC実行時に発生するオブジェクトの移動を次の図に示します。

図2‒4　CopyGC実行時に発生するオブジェクトの移動

このようにして，使用中のオブジェクトは，CopyGCが発生するたびに，From空間とTo空間を行ったり来たりします。ただし，寿命の長いオブジェクトを行き来させ続けると，コピー処理の負荷などが問題になります。これを防ぐために，From空間とTo空間でJavaオブジェクトを入れ替える回数にしきい値を設定して，年齢がしきい値に達したJavaオブジェクトはTenured領域に移動させるようにします。

(4)　オブジェクトの退避

年齢がしきい値に達していないJavaオブジェクトがTenured領域に移動することを，退避といいます。退避は，CopyGC実行時にEden領域およびFrom空間で使用中のオブジェクトが多くなり，移動先であるTo空間のメモリサイズが不足する場合に発生します。この場合，To空間に移動できなかったオブジェクトが，Tenured領域に移動します。

オブジェクトの退避を次の図に示します。

図2‒5　オブジェクトの退避

オブジェクトの退避が発生した場合，Tenured領域に本来格納されないはずの寿命の短いオブジェクトが格納されます。これが繰り返されると，CopyGCで回収されるはずのオブジェクトがメモリ空間に残っていくため，Javaヒープのメモリ使用量が増加していき，最終的にはFullGCが発生します。

オブジェクトの退避が発生した場合のメモリ使用量の変化について，次の図に示します。

図2‒6　オブジェクトの退避が発生した場合のメモリ使用量の変化

FullGCでは，システムが数秒から数十秒停止することがあります。

したがって，メモリ空間の構成とメモリサイズを検討するときには，オブジェクトの退避が発生しないように，Eden領域とSurvivor領域のバランスを検討する必要があります。

(5)　SerialGC使用時のJavaVMで使用するメモリ空間の構成とJavaVMオプション

ここでは，SerialGC使用時のJavaVMで使用するメモリ空間の構成と，JavaVMオプションについて説明します。

JavaVMでは，JavaVM固有領域とOS固有領域という，2種類のメモリ空間を使用します。

JavaVMで使用するメモリ空間の構成を次の図に示します。なお，図中の番号は，「表2-3　JavaVMメモリ空間のサイズや割合などを指定するJavaVMオプション」の項番と対応しています。

図2‒7　JavaVMで使用するメモリ空間の構成

それぞれの領域について説明します。なお，Eden領域，Survivor領域，およびTenured領域を合わせた領域を，Javaヒープといいます。

Eden領域

newによって作成されたJavaオブジェクトが最初に格納される領域です。

Survivor領域

New領域に格納されていたJavaオブジェクトのうち，CopyGC実行時に破棄されなかったJavaオブジェクトが格納される領域です。Survivor領域は，From空間とTo空間で構成されます。From空間とTo空間のサイズは同じです。

Tenured領域

長期間必要であると判断されたJavaオブジェクトが格納される領域です。Survivor領域で指定回数を超えてCopyGCの実行対象となり，破棄されなかったJavaオブジェクトが，この領域に移動されます。

Metaspace領域

ロードされたclassなどの情報が格納される領域です。

ただし，圧縮オブジェクトポインタ機能が有効な場合，Metaspace領域内にCompressed Class Spaceという領域が作成されます。この領域に，Javaヒープ内のオブジェクトから参照されるクラス情報が配置されます。そして，それ以外のメソッド情報などがCompressed Class Space以外のMetaspace領域に配置されます。圧縮オブジェクトポインタ機能については，「4.15　圧縮オブジェクトポインタ機能」を参照してください。

Cヒープ領域

JavaVM自身が使用する領域です。JNIで呼び出されたネイティブライブラリでも使用されます。

例えば，次のような領域があります。

コードキャッシュ領域

JITコンパイルによって生成されたJITコンパイルコードが格納される領域です。

JavaVMは，呼び出し回数やループ回数が多いJavaメソッドをJITコンパイルして実行することで，処理を高速化します。

メモ

コードキャッシュ領域の最大サイズについて

コードキャッシュ領域の最大サイズは，ReservedCodeCacheSizeオプションに指定します。

ReservedCodeCacheSizeオプションには，デフォルト値以上の値を指定してください。Java HotSpot VMのオプションのデフォルト値については，マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

また，コードキャッシュ領域が枯渇していた場合，または枯渇するおそれがある場合は，コードキャッシュ領域の拡張を検討してください。

コードキャッシュ領域を拡張する場合は，次の点に注意してください。

JITコンパイルコードのサイズは計算で見積もることができません。そのため，Javaアプリケーション実行環境でコードキャッシュ領域の使用量を実測し，システムが使用するコードキャッシュ領域（64ビット版で最大2メガバイト）の使用量を考慮した上で，コードキャッシュ領域の最大サイズを見積もってください。

仮想メモリの使用量の見積もりについては，「2.1.2　プロセスごとに使用するメモリの見積もり」を参照してください。

スタック領域

Javaスレッドのスタック領域です。

それぞれの領域のサイズや割合などを指定するJavaVMオプションを次の表に示します。なお，表の項番は，「図2-7」と対応しています。

表2‒3　JavaVMメモリ空間のサイズや割合などを指定するJavaVMオプション

項番

オプション名

オプションの意味

1

-Xmx<size>

Javaヒープの最大サイズを設定します。

2

-Xms<size>

Javaヒープの初期サイズを設定します。

3

-XX:MaxMetaspaceSize=<size>

Metaspace領域の最大サイズを設定します。

4

-XX:MetaspaceSize=<size>

Metaspace領域の初期サイズを設定します。

5

-Xmn<size>

New領域の初期値および最大値を設定します。

6

-Xss<size>

1スレッド当たりのスタック領域の最大サイズを設定します。

7

-XX:ReservedCodeCacheSize=<size>

JavaVMが使用する領域のうち，コードキャッシュ領域の最大サイズを設定します。

8

-XX:NewRatio=<value>

New領域に対するTenured領域の割合を設定します。

<value>が2の場合は，New領域とTenured領域の割合が，1:2になります。

9

-XX:SurvivorRatio=<value>

Survivor領域のFrom空間とTo空間に対するEden領域の割合を設定します。

<value>に8を設定した場合は，Eden領域，From空間，To空間の割合が，8:1:1になります。

10

-XX:TargetSurvivorRatio=<value>

CopyGC実行後のSurvivor領域内でJavaオブジェクトが占める割合の目標値を設定します。

11

-XX:MaxTenuringThreshold=<value>

CopyGC実行時に，From空間とTo空間でJavaオブジェクトを入れ替える回数の最大値を設定します。

設定した回数を超えて入れ替え対象になったJavaオブジェクトは，Tenured領域に移動されます。

注　<size>の単位はバイトです。

重要

Javaヒープ領域，Metaspace領域，Compressed Class Space，Cヒープ領域のどれかが不足するとOutOfMemoryが発生し，メモリ不足が解消されないかぎり正常に稼働できない状態が長く続くことになります。

これに対して，OutOfMemory発生時のシステムへの影響を小さくするために，次のオプションを使用できます。

-XX:+HitachiOutOfMemoryAbort（OutOfMemory発生時強制終了機能）

OutOfMemory発生時強制終了機能は，Javaヒープ不足やMetaspace領域不足，Compressed Class Space不足などが原因でOutOfMemoryが発生した場合に，アプリケーションを強制終了するための機能です。Javaヒープ領域，Metaspace領域，Compressed Class Space，Cヒープ領域のメモリ不足によってOutOfMemoryが発生したときに，アプリケーションを強制終了します。

アプリケーションサーバの自動再起動や待機系システムへの自動切り替えなどの仕組みを前提として，アプリケーションサーバプロセスの生存を監視している場合には，このオプションを有効にすることで，正常な状態への回復を促す効果があります。

オプションの詳細については，「-XX:[+|-]HitachiOutOfMemoryAbort（強制終了オプション）」を参照してください。

(6)　GCの発生とメモリ空間の関係

GCは，メモリ空間の使用状況に応じて発生します。ここでは，GCが発生するタイミングについて説明します。

重要

RMIを使ってリモートオブジェクトの登録や参照をすると，定期的にGCが発生することがあります。GCが発生するタイミングは，次のどちらかのプロパティにミリ秒単位で指定できます。デフォルトは3600000ミリ秒（1時間）です。

sun.rmi.dgc.client.gcIntervalプロパティ

sun.rmi.dgc.server.gcIntervalプロパティ

GCが発生するタイミングを変更する場合は，どちらかのプロパティにミリ秒単位で任意の値を指定してください。なお，指定できる値の範囲は，1〜Long.MAX_VALUE-1です。詳細は，Webページ（https://docs.oracle.com/javase/6/docs/technotes/guides/rmi/sunrmiproperties.html）を参照してください。

(a)　CopyGCが発生するタイミング

CopyGCは，次のタイミングで発生します。

Eden領域へのアロケーションで空き領域が不足した場合

jheapprofコマンドに-copygcオプションを指定して実行した場合

(b)　FullGCが発生するタイミング

FullGCは，次のタイミングで発生します。

New領域（Eden領域とSurvivor領域の合計）で使用しているメモリサイズがTenured領域の最大値に対する未使用メモリサイズを上回っている状態の時に，Eden領域へのアロケーションで空き領域が不足した場合

重要

上記のタイミングで必ずFullGCが発生するわけではありません。この状況になった場合，FullGCを発生させる必要があるかどうかについては，過去のCopyGCでのTenured領域への移動量の実績値に基づいて，JavaVMが決定します。

CopyGCの実施の結果，New領域（Eden領域とSurvivor領域の合計）からTenured領域へのオブジェクトの移動に失敗した場合

New領域とTenured領域のそれぞれの未使用メモリサイズを上回るメモリサイズ（Javaオブジェクトのサイズ）のアロケーション要求があった場合

CopyGCの実施の結果，次のどちらかの状態になった場合

確保済みTenured領域の未使用メモリサイズが10,000バイトを下回った場合

CopyGC実施時のTenured領域へのオブジェクトの移動によって，確保済みTenured領域の拡張が発生した場合

java.lang.System.gc()メソッドが実行された場合

Metaspace領域にアロケーションしたいメモリサイズが確保済みMetaspace領域の未使用メモリサイズを上回る場合

javagcコマンドを実行した場合

jheapprofコマンドを実行した場合

JavaVMのチューニングでは，主に1.と3.の発生を抑えることを検討します。

メモ

FullGCが発生した場合の要因は，拡張verbosegc情報を使用して確認できます。FullGC発生時に要因を確認する方法については，「2.2.8　拡張verbosegc情報を使用したFullGCの要因の分析方法」を参照してください。

2.2.2　Javaヒープのチューニング

SerialGC使用時のJavaヒープのチューニングについて説明します。

一般的に，FullGCの方が，CopyGCよりも長い処理時間を要します。

GCの実行中はプログラムの処理が停止するため，FullGCの発生はシステムの処理性能に大きな影響を与えます。このため，New領域へのCopyGCの実施によって適切にメモリを回収して，Javaヒープ全体を対象とするFullGCの発生をできるだけ抑止することが，システムの停止回数の削減や，処理性能向上につながります。これを実現するためには，JavaVMオプションでそれぞれのメモリ空間のサイズや割合を適切に設定することが必要です。

これらを考慮した上で，JavaVMのチューニングは，次の2点を目的として実施します。

FullGCをできるだけ発生させないこと

FullGCの頻発を抑止し，不要なCopyGCを発生させないこと

理想的なメモリ使用量と経過時間の関係を次の図に示します。

図2‒8　理想的なメモリ使用量と経過時間の関係

この図の場合は，寿命の短いオブジェクトはすべてCopyGCによって回収できていて，オブジェクトの昇格や退避が発生しません。このため，CopyGC実行後のメモリサイズが一定です。これによって，FullGCが発生しない，安定した状態での運用を実現できます。

JavaVMのチューニングでは，この状態を理想として，JavaVMの使用するメモリ空間の各領域で使用するメモリサイズを見積もってチューニングします。

ヒント

チューニングの目安

「図2-8」では，FullGCを一度も発生させない理想的な例を示しましたが，現実的にはFullGCが1回発生する間にCopyGCが10〜20回程度発生することを目安にして，チューニングしてください。

なお，Javaヒープのチューニングをした段階でJavaアプリケーションのテストを実施してください。Javaヒープのメモリを適切に見積もってもFullGCが頻発する場合は，Survivor領域があふれているなど，チューニングに問題がないか確認してください。

(1)　Javaヒープのメモリサイズの見積もり

JavaVMのチューニングでは，JavaVM固有領域の各領域のメモリサイズを適切に見積もる必要があります。

見積もりのポイントになるメモリサイズは次のとおりです。

Javaヒープ全体のメモリサイズ

Tenured領域のメモリサイズ

Survivor領域のメモリサイズ

Eden領域のメモリサイズ

このほか，Metaspace領域も，必要に応じて見積もります。

CopyGC後の生存オブジェクトのサイズがSurvivor領域のサイズよりも大きい場合，Survivor領域があふれ，1度のCopyGCの実行でTenured領域に昇格するオブジェクトが発生します。また，Survivor領域のサイズが小さい場合に，Survivor領域の使用率が上がってくると，本来短寿命（CopyGC間隔以下，またはCopyGC間隔の1〜2倍程度の寿命）のJavaオブジェクトが，数回のCopyGCの実行でTenured領域に昇格してしまいます。

ヒント

次に示す問題が確認できた場合は，Survivor領域の不足が原因でFullGCが発生しています。なお，拡張verbosegc情報とは，起動時に-XX:+HitachiVerboseGCオプションを設定しておくと，GC発生時にJavaVMログファイルに出力される情報です。

Tenured領域の増加要因が短寿命オブジェクトであると特定された場合

拡張verbosegc情報で，CopyGC時のSurvivor領域あふれが確認できた場合

-XX:+HitachiVerboseGCPrintTenuringDistribution指定時に出力される拡張verbosegc情報で，オブジェクトの昇格年齢が常に１であることが観測できた場合

これらの問題を回避するためには，-XX:SurvivorRatioオプションの設定値を小さくして，Eden領域とSurvivor領域の割合を最適化する必要があります。

このことを考慮し，見積もりでは，まず，Tenured領域のメモリサイズとNew領域のメモリサイズを算出して，それらを基にJavaヒープ全体のメモリサイズを算出します。

メモリサイズを見積もる順序を次の図に示します。図中の番号の順番で見積もりを実施します。

図2‒9　メモリサイズを見積もる順序

見積もり手順を示します。なお，番号は図中の番号と対応しています。

Tenured領域で使用するメモリサイズを見積もります。

見積もり方法については，「2.2.3　Javaヒープ内のTenured領域のメモリサイズの見積もり」を参照してください。

Survivor領域で使用するメモリサイズを見積もります。

見積もり方法については，「2.2.4(1)　Javaヒープ内のSurvivor領域のメモリサイズの見積もり」を参照してください。

Eden領域で使用するメモリサイズを見積もります。

見積もり方法については，「2.2.4(2)　Javaヒープ内のEden領域のメモリサイズの見積もり」を参照してください。

2.と3.の合計として，New領域全体のメモリサイズを算出します。

一定期間存在するオブジェクトの扱いを検討して，必要なメモリサイズをTenured領域またはNew領域のメモリサイズに追加します。

検討方法については，「2.2.5　Javaヒープ内に一定期間存在するオブジェクトの扱いの検討」を参照してください。

1.，4.および5.の合計として，Javaヒープ全体のメモリサイズを算出します。

必要に応じてMetaspace領域のメモリサイズを見積もります。

見積もり方法については，「2.2.7　Javaヒープ内のMetaspace領域のメモリサイズの見積もり」を参照してください。

(2)　Javaヒープのメモリサイズの設定方法

見積もったメモリサイズは，「2.2.1(5)　SerialGC使用時のJavaVMで使用するメモリ空間の構成とJavaVMオプション」で説明したオプションで指定します。それぞれの領域のメモリサイズの設定方法を次に示します。

Javaヒープ全体のメモリサイズ

-Xmx<size>オプションで最大サイズを指定して，-Xms<size>オプションで初期サイズを指定します。

Tenured領域のメモリサイズ

-XX:NewRatio=<value>オプションで，Javaヒープ全体に対する，Tenured領域とNew領域の分割比を指定します。例えば，「-XX:NewRatio=5」とした場合には，-Xmx<size>オプションで指定したメモリサイズが，次のように分割されます。

New領域のメモリサイズ：Tenured領域のメモリサイズ = 1：5

Survivor領域のメモリサイズとEden領域のメモリサイズ

-XX:SurvivorRatio=<value>オプションで，New領域全体に対する，Survivor領域とEden領域の分割比を指定します。なお，分割比は，Survivor領域のFrom空間およびTo空間に対してEden領域を何倍確保するかの数値で指定します。例えば，「-XX:SurvivorRatio=2」とした場合には，-XX:NewRatio=<value>オプションで決まったNew領域のメモリサイズが，次のように分割されます。

Eden領域のメモリサイズ：From空間のメモリサイズ：To空間のメモリサイズ＝2：1：1

Metaspace領域のメモリサイズ

-XX:MaxMetaspaceSize=<size>オプションで最大サイズを指定して，-XX:MetaspaceSize=<size>オプションで初期サイズを指定します。

(3)　Javaヒープのメモリサイズの使用状況の確認方法

それぞれのメモリサイズは，アプリケーションを実際に動作させて，メモリ使用量を測定しながらチューニングしていきます。日立JavaVMでは，-XX:+HitachiVerboseGCオプションを指定してアプリケーションを起動することで，GC実行時の各領域の詳細なメモリサイズを拡張verbosegc情報として出力できます。この出力内容を基にチューニングを実施してください。

拡張verbosegc情報として出力できる主な内容を次に示します。

GCの発生日時

GC種別

GC情報※1

GC経過時間

Eden情報※1

Survivor情報※1

Tenured情報※1

Metaspace領域情報※1

GC要因内容※２

注※1

各領域について，GC前後のメモリサイズおよび使用メモリサイズが出力されます。

注※2

-XX:+HitachiVerboseGCPrintCauseオプションが指定されている場合に出力されます。

拡張verbosegc情報の出力例とFullGCの要因分析方法については，「2.2.8　拡張verbosegc情報を使用したFullGCの要因の分析方法」を参照してください。また，オプションについては，「-XX:[+|-]HitachiVerboseGC（拡張verbosegc情報出力オプション）」を参照してください。

なお，日立JavaVMでは，javagcコマンドを使用して，任意のタイミングでFullGCを発生させることもできます。この場合，-vオプションを指定することで，拡張verbosegc情報と同じ内容を出力できます。javagcコマンドの詳細については，「javagc（GCの強制発生）」を参照してください。

2.2.3　Javaヒープ内のTenured領域のメモリサイズの見積もり

SerialGC使用時のTenured領域のメモリサイズの見積もりについて説明します。

Tenured領域のメモリサイズは，次のように見積もります。

Tenured領域のメモリサイズ
＝アプリケーションで必要なメモリサイズ＋New領域のメモリサイズ

ここでは，アプリケーションで必要なメモリサイズの算出方法について説明します。また，見積もったメモリサイズにNew領域のメモリサイズを追加する理由についても説明します。

(1)　アプリケーションで必要なメモリサイズの算出

Tenured領域のメモリサイズは，アプリケーションが最低限必要とするメモリサイズから見積もります。必要なメモリサイズが確保できない場合，OutOfMemoryErrorが発生してJavaVMが停止します。

アプリケーションが必要とするメモリサイズは，FullGC実行時の拡張verbosegc情報で，FullGC実行後に使用しているメモリサイズを確認することで判断できます。これは，FullGC実行後にJavaヒープ全体から不要なオブジェクトをすべて削除した状態のメモリサイズが，アプリケーションが必要とするメモリサイズに近いと考えられるためです。

FullGC実行時の拡張verbosegc情報の出力例を次に示します。

…
[VGC]<Wed May 11 23:12:05 2005>[Full GC 31780K->30780K(32704K), 0.2070500secs][DefNew::Eden: 3440K->1602K(3456K)][DefNew::Survivor:58K->0K(64K)][Tenured: 28282K->29178K(29184K)][Metaspace:3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:ObjAllocFail][User: 0.0156250 secs][Sys: 0.0312500 secs]
…

「Full GC」に続いて出力されている情報のうち，GCの実行後の情報「->30780K」を確認します。ここでは，FullGC実行後に，30,780キロバイトのメモリサイズを必要としていることが分かります。

何回分かのFullGCの拡張verbosegc情報を集め，GC実行後のメモリサイズがいちばん大きい情報を，アプリケーションが必要とするメモリサイズであると判断してください。

(2)　Javaヒープ内のNew領域のメモリサイズを追加する理由

Tenured領域のメモリサイズには，アプリケーションが最低限必要とするメモリサイズに，New領域分のメモリサイズを追加することをお勧めします。これは，Tenured領域の未使用メモリサイズがNew領域の使用メモリサイズを下回ることによって，FullGCが頻発するのを防ぐためです。

通常，Eden領域がいっぱいになると，CopyGCが発生します。このとき，Eden領域とSurvivor領域のFrom空間に存在する使用中のJavaオブジェクトが，Survivor領域のTo空間に移動しようとします。このとき，Tenured領域の未使用領域がEden領域とSurvivor領域で使用中のメモリサイズよりも小さいと，New領域のすべてのJavaオブジェクトが昇格した場合に，JavaオブジェクトをTenured領域に移動できなくなります。そこでJavaVMは，FullGCを発生させ，Tenured領域の未使用メモリサイズを増やそうとします。

これを防ぐために，Tenured領域には，アプリケーションが必要とするメモリサイズに加えて，New領域分のメモリサイズを追加してください。

考え方を次の図に示します。

図2‒10　New領域のメモリサイズを追加する理由の考え方

オブジェクトが昇格できないおそれがあるためFullGCが発生する例

Tenured領域のメモリの空き領域（アプリケーションで必要なメモリ領域以外の領域）がNew領域のメモリサイズよりも小さいため，Eden領域およびFrom空間からの移動オブジェクトが多い場合，オブジェクトの昇格に対応できないおそれがあります。この場合，FullGCが発生します。

オブジェクトが確実に昇格できる例

Tenured領域のメモリの空き領域（アプリケーションで必要なメモリ領域以外の領域）がNew領域と同じサイズ分確保してあるため，Eden領域およびFrom空間からの移動オブジェクトが多い場合も，オブジェクトの昇格に対応できます。

なお，New領域のメモリサイズの見積もりについては，「2.2.4　Javaヒープ内のNew領域のメモリサイズの見積もり」で説明します。

ヒント

拡張verbosegc情報などで確認したときに，CopyGCが発生しないでFullGCが頻発している場合，New領域からの退避オブジェクトに対してTenured領域のメモリサイズが小さいことが考えられます。New領域のサイズを増やした場合などにこの状態になることがあります。必要に応じて，Tenured領域のメモリサイズを見直してください。また，New領域内のEden領域とSurvivor領域の関係もあわせて見直してください。

2.2.4　Javaヒープ内のNew領域のメモリサイズの見積もり

SerialGC使用時のNew領域のメモリサイズの見積もりについて説明します。

New領域のメモリサイズは，次のように見積もります。

New領域のメモリサイズ
＝Survivor領域のメモリサイズ＋Eden領域のメモリサイズ

ここでは，Survivor領域およびEden領域のメモリサイズを見積もる方法について説明します。

(1)　Javaヒープ内のSurvivor領域のメモリサイズの見積もり

Survivor領域のメモリサイズは，実際にアプリケーションを動作させて，Survivor領域の使用状況を確認しながらチューニングしていきます。

チューニングの流れを次に示します。

アプリケーションでのリクエストおよびレスポンス処理に使用するメモリサイズを見積もり，それをSurvivor領域のメモリサイズに指定して，アプリケーションを実行します。

このとき，チューニングで使用する情報を出力するために，-XX:+HitachiVerboseGCPrintTenuringDistributionオプションを指定して起動します。

Survivor領域に割り当てられているメモリサイズと，アプリケーション実行時に実際に使用されているメモリ使用量から，メモリ使用率を確認します。

メモリ使用率が100%に近い場合，CopyGC実行時にNew領域およびSurvivor領域のFrom空間の使用中オブジェクトがTo空間に入り切らなくなり，オブジェクトの退避が発生します。この場合は，Survivor領域を増やすことを検討してください。

Survivor領域のオブジェクトの年齢分布を確認します。

Survivor領域のメモリサイズを増やしたり，昇格するためのしきい値を上げたりすることで，オブジェクトが昇格するのが遅くなります。寿命の長いオブジェクトをSurvivor領域に格納し続けるのは，性能を低下させる要因になります。

逆に，Survivor領域のメモリサイズを減らしたり，昇格するためのしきい値を下げたりすることで，オブジェクトが昇格するのが早くなります。ただし，寿命の短いオブジェクトが昇格するのは，FullGCの発生頻度を増やす要因になります。

Survivor領域のメモリサイズと昇格のしきい値は，この2つのバランスを取るように検討してください。

それぞれのチューニング作業について説明します。

(a)　リクエストおよびレスポンス処理に使用するメモリサイズの見積もり

Survivor領域は，寿命の短いオブジェクトを格納する領域です。サーバサイドで動作するアプリケーションの場合，リクエストやレスポンスを処理するために使われている，寿命の短いオブジェクトを格納する領域と考えることができます。このため，Survivor領域のメモリサイズの見積もりでは，ある時点で存在する寿命が短いオブジェクトの最大サイズ，つまり，ある時点でのリクエストやレスポンスの処理に使用するメモリの最大サイズを考えます。例えば，ステートレスなサーブレットで構成されたアプリケーションの場合，Survivor領域のメモリサイズを，「1つのリクエスト処理で使用する最大メモリサイズ×リクエストの同時実行数」と考えることができます。

(b)　メモリ使用率の確認

「(a)リクエスト/レスポンス処理に使用するメモリサイズの見積もり」で見積もった値をSurvivor領域のメモリサイズとして設定して，アプリケーションを実行します。実行時に使用されるメモリ使用量から，Survivor領域に割り当てたメモリサイズに対するメモリ使用率を確認します。

メモ

Survivor領域のメモリサイズは，直接は指定できません。

Survivor領域のメモリサイズを指定する場合は，まず，-XmxオプションでJavaヒープの最大サイズを指定して，-XX:NewRatio=<value>によってJavaヒープのメモリサイズをNew領域とTenured領域で分ける割合を指定した上で，-XX:SurvivorRatio=<value>オプションによって，Eden領域との割合を指定する必要があります。

メモリ使用率は，拡張verbosegc情報で確認できます。

CopyGC実行時の拡張verbosegc情報の出力例を次に示します。

…
[VGC]<Wed May 11 23:12:05 2005>[GC 27340K->27340K(32704K), 0.0432900 secs][DefNew::Eden: 3440K->0K(3456K)][DefNew::Survivor: 58K->64K(64K)][Tenured: 23841K->27282K(29184K)][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:ObjAllocFail][User: 0.0156250 secs][Sys: 0.0312500 secs]
…

「DefNew::Survivor: 58K->64K(64K)」は，「GC実行前のメモリサイズ->GC実行後のメモリサイズ（割り当てられているメモリサイズ）」を意味します。この場合，64キロバイトのSurvivor領域中64キロバイトがすでに使用されていて，使用率は100%になります。これは，CopyGCで，To空間のメモリサイズが不足し，Javaオブジェクトの退避が行われたことを示しています。退避では，Tenured領域に本来格納されないはずの寿命の短いオブジェクトが格納され，FullGCの発生頻度を増やす要因になります。このような場合は，Survivor領域のメモリサイズを増やすことを検討してください。新しいSurvivor領域のメモリサイズは次のように見積もります。

新しいSurvivor領域のメモリサイズ
＝現在のSurvivor領域のメモリサイズ＋退避されたJavaオブジェクトの合計サイズ

「退避されたJavaオブジェクトの合計サイズ」は，GC実行後のTenured領域メモリの増加サイズで近似できます。この例では，「Tenured: 23841K->27282K(29184K)」が，Tenured領域メモリの増加サイズを示していて，27,282キロバイト−23,841キロバイト＝3,441キロバイトとなります。

(c)　オブジェクトの年齢分布の確認と見積もり

Survivor領域のオブジェクトの年齢分布を確認し，寿命の長いオブジェクトが存在し続けていないか，または寿命の短いオブジェクトが昇格していないかを確認します。オブジェクトの年齢分布は，-XX:+HitachiVerboseGCPrintTenuringDistributionオプションの出力結果で確認できます。

起動時に-XX:+HitachiVerboseGCPrintTenuringDistributionオプションを指定すると，Survivor領域の使用状況がCopyGC発生のタイミングでJavaVMログファイルに出力されます。出力例を次に示します。

[PTD]<Wed May 28 11:45:23 2008>[Desired survivor:5467547 bytes][New  threshold:3][MaxTenuringThreshold:31][age1:1357527][age2:1539661]

「New threshold:」に続けて出力されているのが，次のCopyGCで昇格するJavaオブジェクトの最低の年齢です。例の場合は，次回のCopyGCで，年齢が3歳以上のJavaオブジェクトが昇格します。「age<数値>:」に続けて出力されているのが，Survivor領域で1歳からその年齢までのJavaオブジェクトが使用しているメモリサイズの累計です。例の場合は，1歳のJavaオブジェクトのメモリサイズが1,357,527バイト，1歳と2歳のJavaオブジェクトのメモリサイズの累計が1,539,661バイトであることを示しています。また，累計から逆算することで，2歳のJavaオブジェクトのメモリサイズが182,134(1,539,661-1,357,527)バイトであることが分かります。一般的に，Survivor領域のオブジェクトの年齢分布は次の図に示すグラフのようになります。

図2‒11　Survivor領域のオブジェクトの年齢分布

グラフの「サイズ」は，ある「年齢」のJavaオブジェクトの合計のサイズです。また，「累計サイズ」は，ある「年齢」までのJavaオブジェクトの合計のサイズです。

このグラフでは，Survivor領域のJavaオブジェクトが占めるサイズが，年齢が上がるに連れて減少しています。また，1歳年齢が上がったときに減少するサイズは年齢が若いほど大きくなります。このことから，次のことが分かります。

若い年齢のJavaオブジェクトほど，Survivor領域中に占めるサイズが大きい

若い年齢のJavaオブジェクトほど，GCで回収されやすい

この例では，6歳以上のJavaオブジェクトはほとんどCopyGCで回収されていません。そのため，Javaオブジェクトの昇格のしきい値が7歳以上の場合，回収される可能性が低いJavaオブジェクトに対してCopyGCを行うことになり，性能を低下させる要因になります。逆に，Javaオブジェクトの昇格のしきい値が2歳以下の場合，CopyGCで回収される可能性の高いオブジェクトが昇格することになり，FullGCの発生が増す要因になります。この例では，昇格のしきい値を5〜6歳程度とするのが，バランスの取れたしきい値となります。

グラフの傾きはシステムによって異なるため，Survivor領域のオブジェクトの年齢分布を確認し，システムごとの最適な昇格年齢を決定することが重要です。

メモ

Javaオブジェクトの昇格のしきい値は，CopyGCごとに動的に変更され，-XX:MaxTenuringThreshold=<value>オプションと，Survivor領域のメモリサイズおよび-XX:TargetSurvivorRatio=<value>オプションに設定した値を基に決まります。-XX:MaxTenuringThreshold=<value>は，昇格のしきい値の最大の年齢です。Javaオブジェクトの年齢がこの値を超えると，必ず昇格します。-XX:TargetSurvivorRatio=<value>は，Survivor領域のメモリ使用率の目標値です。JavaVMは，Survivor領域のメモリ使用率が，できるだけこの値に近くなるように，昇格のしきい値を決定します。具体的には，CopyGCが終了したときの1歳からn歳までのJavaオブジェクトの累計サイズが，目標の使用率となるnを探し，次のCopyGCの昇格のしきい値をnにします。-XX:TargetSurvivorRatio=<value>のデフォルト値は50%です。Survivor領域のメモリ使用率が大きいほどSurvivor領域を有効に利用できますが，Survivor領域の空きに余裕がなくなるため，オブジェクトの退避が発生しやすくなります。

(2)　Javaヒープ内のEden領域のメモリサイズの見積もり

Eden領域のメモリサイズは，CopyGCを発生させる間隔に影響します。Eden領域のメモリサイズを大きく取ると，CopyGCの発生間隔が長くなります。なお，CopyGCに掛かる時間は，使用中のオブジェクトの個数に影響され，Eden領域のメモリサイズにはあまり影響されません。このため，CopyGCが頻発しないように，Eden領域のメモリサイズを十分に確保することが，性能向上には効果的です。

2.2.5　Javaヒープ内に一定期間存在するオブジェクトの扱いの検討

これまでの説明は，オブジェクトの寿命に応じて，それぞれの領域に次のように格納することを前提としてきました。

アプリケーションの動作に必要な寿命の長いオブジェクトは，Tenured領域に格納する。

リクエスト処理やレスポンス処理などの寿命の短いオブジェクトは，New領域に格納する。

しかし，寿命が中間的な一定期間使用されるオブジェクトがあります。このようなオブジェクトは，寿命は長くありませんが，何回かのCopyGCの対象になります。

メモリサイズの見積もりでは，これらのオブジェクトを，New領域，Tenured領域のどちらかに格納することを前提として，見積もりをする必要があります。

ここでは，それぞれの特徴を示します。アプリケーションの種類や目的に応じて，どちらかのメモリサイズを増加させるように見積もりをしてください。

(1)　Javaヒープ内のNew領域に格納する方法

一定期間存在するオブジェクトをNew領域で管理する方法です。New領域のメモリサイズに，これらの一定期間存在するオブジェクト分のメモリサイズを追加して見積もります。

New領域サイズを大きくしてオブジェクトのTenured領域への移動を抑止することによって，FullGCの発生も抑止できます。ただし，CopyGC実行時にNew領域内にある使用中オブジェクトの数が増えるため，New領域内でのコピー処理に時間が掛かり，1回当たりのCopyGC実行時間は長くなります。CopyGCの実行時間がFullGC実行時間よりも長くなるような場合は，メモリサイズの再見積もりが必要です。また，メモリ空間のサイズ設定によっては，本来CopyGCで回収されるはずの寿命の短いオブジェクトが使用する領域が不足して，Tenured領域への退避が発生するおそれがあります。この場合は，最終的にはFullGCが発生してしまいます。

なお，一定期間存在するオブジェクトをNew領域で管理できているかどうかは，拡張verbosegc情報で確認できます。実際にアプリケーションを動作させて，出力された拡張verbosegc情報で，CopyGC発生後のTenured領域のメモリサイズが大幅に増えていないことを確認してください。

New領域での管理に失敗している場合，システムの処理性能が大幅に低下していることがあります。また，New領域で管理できるオブジェクトの最大の年齢には限界があります（限界はプラットフォームやバージョンによって異なります。詳細は，マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照し，Java HotSpot VMの-XX:MaxTenuringThreshold=<value>オプションのデフォルト値に関する説明を確認してください）。New領域で管理できていないことが分かった場合は，一定期間存在するオブジェクトは，Tenured領域に格納して管理することを検討してください。Tenured領域で管理する方法については，「2.2.5(2)　Javaヒープ内のTenured領域に格納する方法」を参照してください。

(2)　Javaヒープ内のTenured領域に格納する方法

New領域で管理するオブジェクトの最大の年齢は，-XX:MaxTenuringThreshold=<value>オプションで指定できます。例えば，「-XX:MaxTenuringThreshold=2」を指定しておけば，3回目のCopyGCの対象になったオブジェクトは，すべてTenured領域に移動します。

この方法を使用すると，CopyGCの対象になるオブジェクトが少なくなり，実行時間が短縮できます。ただし，多くのオブジェクトがTenured領域に移動するため，Tenured領域がいっぱいになった段階でFullGCが発生します。システムを安定して動作させるためには，システムに掛かる負荷が低いときなどに，FullGCを強制的に発生させてください。FullGCを強制的に発生させるには，次の方法があります。

プログラム内でSystem.gc()メソッドを呼び出す

javagcコマンドを実行する

javagcコマンドの詳細については，「javagc（GCの強制発生）」を参照してください。

2.2.6　Javaヒープの最大サイズ/初期サイズの決定

Tenured領域およびNew領域の見積もりができたら，それらを基にJavaヒープの最大サイズと初期サイズを決定します。

Javaヒープの最大サイズは，次のように決定します。

Javaヒープの最大サイズ
＝Tenured領域のメモリサイズ＋New領域のメモリサイズ

Javaヒープのメモリサイズを設定する場合，まず，-Xmxオプションに，拡張領域のサイズも含む，Javaヒープ領域の最大サイズを指定します。次に，-Xmsオプションに，Javaヒープ領域の初期サイズを指定します。なお，-Xmsオプションに指定するサイズは，-Xmxオプションに指定したサイズよりも小さくする必要があります。

JavaVMは，起動時に，-Xmsオプションで指定された分のメモリ領域をJavaヒープ領域として確保します。そのあと，アプリケーション実行中に-Xmsオプションで指定した以上のメモリ領域が必要になった場合に，-Xmxオプションで指定したサイズになるまで，ヒープ領域を追加して割り当てていきます。逆に，アプリケーションの中で不要なメモリ領域が発生した場合は，-Xmsオプションで指定したサイズまで，Javaヒープ領域として確保している領域を減らしていきます。

なお，システムの安定稼働のためには，-Xmxオプションと-Xmsオプションには同じ値を指定することをお勧めします。

2.2.7　Javaヒープ内のMetaspace領域のメモリサイズの見積もり

SerialGC使用時のMetaspace領域のメモリサイズの見積もりについて説明します。Metaspace領域は，ロードされたclassなどが格納される領域です。

Metaspace領域のメモリサイズは，「2.2.1(5)　SerialGC使用時のJavaVMで使用するメモリ空間の構成とJavaVMオプション」で示したとおり，-Xmxオプションで指定したメモリサイズ（Javaヒープ）とは別に確保されます。

Java HotSpot VMのオプションのデフォルト値については，マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

次に，アプリケーションサーバを例にMetaspace領域の使用量の見積もり方法を示します。

Metaspace領域の使用量の見積もり方法

Metaspace領域でのメモリ使用量は，大体，ロードされるクラスファイルの合計サイズになります。

Metaspace領域のメモリサイズは，-XX:MaxMetaspaceSize=<size>オプション，および-XX:MetaspaceSize=<size>オプションで指定します。これらのオプションのデフォルト値については，マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。なお，アプリケーションのインポート時に一時的にMetaspace領域の使用量が増加する場合があります。

Metaspace領域は，JavaVM上で動作するプログラムのすべてのクラスファイルのサイズの総和から見積もることができます。例えば，Tomcatの場合，アプリケーションのクラスファイル，Tomcatが提供するクラスファイル，JDKが提供するクラスファイルのサイズの総和です。なお，JDKが提供するクラスファイルのサイズは約130メガバイトです。

メモ

開発環境でのソフト参照によるMetaspace領域の圧迫の解消方法

アプリケーションサーバでは，ソフト参照の影響によって，アプリケーションをアンデプロイしたときにMetaspace領域の解放が遅延することがあります。このため，開発環境などでアプリケーションのデプロイおよびアンデプロイを繰り返した場合，Metaspace領域の解放遅延が原因で，Metaspace領域が圧迫されることがあります。ソフト参照によるMetaspace領域の圧迫は，次のオプションを指定すると解消できます。

-XX:SoftRefLRUPolicyMSPerMB=0

-XX:SoftRefLRUPolicyMSPerMBオプションに0を指定すると，すべてのソフト参照が無効になります。ソフト参照は，性能向上のためのキャッシュとして使用されることが多いため，このオプションの指定によってアプリケーションの性能が劣化するおそれがあります。このため，このオプションは，開発環境でMetaspace領域が圧迫された場合にだけ指定してください。

メモ

Metaspace領域の特殊なチューニングの考え方

Metaspace領域はオプションに設定された値のメモリを必ず使用するわけではありません。実際には，実行に必要なサイズのメモリだけ使用します。

Metaspace領域のOutOfMemoryErrorの発生リスクを下げる

見積もり時に想定していなかったMetaspace領域の使用量の増加によって，OutOfMemoryErrorが発生するリスクを下げるためには，見積もり値にバッファを持たせた値を-XX:MaxMetaspaceSizeと-XX:CompressedClassSpaceSizeに設定してください。Metaspace領域の使用量がこの値を超えるまではMetaspace領域のOutOfMemoryErrorは発生しません。

Metaspace領域に起因するFullGCの発生リスクを下げる

見積もり時に想定していなかったMetaspace領域の使用量の増加によって，Metaspace領域に起因するFullGCが発生するリスクを下げるためには，見積もり値にバッファを持たせた値を-XX:MetaspaceSize，-XX:MaxMetaspaceSize，-XX:CompressedClassSpaceSizeに設定してください。Metaspace領域の使用量がこの値を超えるまではMetaspace領域に起因するFullGCは発生しません。

2.2.8　拡張verbosegc情報を使用したFullGCの要因の分析方法

SerialGC使用時の拡張verbosegc情報を使用したFullGCの要因の分析方法について説明します。拡張verbosegc情報は，JavaVMオプションである-XX:+HitachiVerboseGCオプションを指定することによって出力できる日立JavaVMのログ情報です。チューニングに役立つ情報のほか，障害要因の分析にも役立つ情報が出力されます。

チューニング実行時に拡張verbosegc情報を参照することで，次の情報を確認できます。

GC実行前と実行後の各領域の使用メモリサイズ

GCが発生した要因

また，-XX:+HitachiVerboseGCとほかのJavaVMオプションを組み合わせることによって，さらに詳細な情報が出力できます。-XX:+HitachiVerboseGCオプション，およびそのほかのJavaVM拡張オプションの詳細については，「5.2　日立JavaVM拡張オプションの詳細」を参照してください。

(1)　拡張verbosegc情報の出力形式の概要

拡張verbosegc情報は，CopyGCが発生した場合と，FullGCが発生した場合に出力されます。

CopyGCが発生すると，GCの種類として「GC」と出力されます。また，FullGCが発生すると，GCの種類として「Full GC」と出力されます。種類に続いて，それぞれの領域の「＜GC前のメモリサイズ＞->＜GC後のメモリサイズ＞（＜確保済み領域サイズ＞）」が出力されます。

以降に，FullGCが発生した場合の拡張verbosegc情報の出力例を示します。拡張verbosegc情報には，ほかにもGCの発生要因やGCスレッドのCPU時間も出力されます。

拡張verbosegc情報の出力形式の詳細，およびそれぞれのオプションの詳細については，「5.　日立JavaVM起動オプション」を参照してください。

(2)　FullGC発生時の拡張verbosegc情報の出力例

ここでは，FullGCの発生時の拡張verbosegc情報の出力例を示します。

(a)　New領域メモリサイズに対してTenured領域が不足した場合

New領域（Eden領域とSurvivor領域の合計）で使用しているメモリサイズがTenured領域の最大値に対する未使用メモリサイズを上回った場合の，拡張verbosegc情報の出力例を次に示します。太字の部分がFullGC発生の要因を示す個所です。

…
[VGC]<Wed May 11 23:12:05 2005>[GC 27340K->27340K(32704K), 0.0432900 secs][DefNew::Eden: 3440K->0K(3456K)][DefNew::Survivor: 58K->58K(64K)][Tenured: 23841K->27282K(29184K)][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:ObjAllocFail][User: 0.0156250 secs][Sys: 0.0312500 secs]
[VGC]<Wed May 11 23:12:05 2005>[Full GC 30780K->30780K(32704K), 0.2070500 secs][DefNew::Eden: 3440K->1602K(3456K)][DefNew::Survivor: 58K->0K(64K)][Tenured: 27282K->29178K(29184K)][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:ObjAllocFail][User: 0.0156250 secs][Sys: 0.0312500 secs]
…

この出力例からは，次のことが分かります。

New領域で使用しているメモリサイズ（3440K＋58K＝3498K）が，Tenured領域の最大値に対する未使用メモリサイズ（29184K−27282K＝1902K）を上回りました。

FullGCの要因は，オブジェクトアロケーションの失敗です。

(b)　CopyGC時にTenured領域へのオブジェクトの移動に失敗した場合

CopyGCの実施の結果，New領域（Eden領域とSurvivor領域の合計）からTenured領域へのオブジェクトの移動に失敗した場合の，拡張verbosegc情報の出力例を次に示します。太字の部分がFullGC発生の要因を示す個所です。

…
[VGC]<Thu Oct 20 11:04:42 2011>[GC 26418K->26418K (29696K), 0.0000000 secs][DefNew::Eden:8188K->8188K(8192K)][DefNew::Survivor: 1021K->1021K(1024K)][Tenured:17208K->17208K (20480K)][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:ObjAllocFail][User: 0.0000000 secs][Sys: 0.0000000 secs][IM: 877K, 1104K, 0K][TC: 9][DOE: 0K, 0]
[VGC]<Thu Oct 20 11:04:42 2011>[Full GC 26418K->6450K(29696K), 0.0156250 secs][DefNew::Eden:8188K->0K(8192K)][DefNew::Survivor:1021K->0K(1024K)][Tenured:17208K->6450K(20480K)][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:PromotionFail][User: 0.0156250 secs][Sys: 0.0000000 secs][IM: 925K, 1104K, 0K][TC: 9][DOE: 0K, 0]

この出力例からは，次のことが分かります。

FullGCの要因は，CopyGCによる，New領域からTenured領域へのオブジェクトの移動の失敗です。

(c)　オブジェクトアロケーション時にTenured領域が不足した場合

アロケーションしたいメモリサイズ（newで作成するJavaオブジェクトのサイズ）がTenured領域の未使用メモリサイズを上回る場合の，拡張verbosegc情報の出力例を次に示します。太字の部分がFullGC発生の要因を示す個所です。

…
[VGC]<Wed May 11 23:53:18 2005>[GC 28499K->28490K(32704K), 0.0540590 secs][DefNew::Eden: 808K->0K(3456K)][DefNew::Survivor: 64K->62K(64K)][Tenured: 27626K->28428K(29184K)][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:ObjAllocFail][User: 0.0156250 secs][Sys: 0.0312500 secs]
[VGC]<Wed May 11 23:53:18 2005>[Full GC 28490K->8959K(32704K), 0.1510380 secs][DefNew::Eden: 0K->0K(3456K)][DefNew::Survivor: 62K->0K(64K)][Tenured: 28428K->8959K(29184K)][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:ObjAllocFail][User: 0.0156250 secs][Sys: 0.0312500 secs]
…

この出力例からは，次のことが分かります。

Tenured領域の未使用メモリサイズ（29184K−28428K＝756K）を上回るメモリサイズのJavaオブジェクトを，newで作成しようとしました。

FullGCの要因は，オブジェクトアロケーションの失敗です。

(d)　Tenured領域の未使用メモリサイズが10,000バイトを下回った場合

CopyGC実施の結果，確保済みTenured領域の未使用メモリサイズが10,000バイトを下回った場合の，拡張verbosegc情報の出力例を次に示します。太字の部分がFullGC発生の要因を示す個所です。

…
[VGC]<Fri May 25 15:21:33 2007>[GC 15436K->15416K(19840K), 0.0111825 secs][DefNew::Eden: 4413K->0K(4416K)][DefNew::Survivor: 512K->509K(512K)][Tenured: 10511K->14906K(14912K)][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:ObjAllocFail][User: 0.0000000 secs][Sys: 0.0000000 secs]
[VGC]<Fri May 25 15:21:33 2007>[Full GC 15416K->8622K(19840K), 0.0284614 secs][DefNew::Eden: 0K->0K(4416K)][DefNew::Survivor: 509K->0K(512K)][Tenured: 14906K->8622K(14912K)][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:ObjAllocFail][User: 0.0312500 secs][Sys: 0.0000000 secs]
…

この出力例からは，次のことが分かります。

1行目のCopyGCでNew領域からTenured領域にオブジェクトが移動したことによって，Tenured領域の使用済みメモリサイズが10,511キロバイトから14,906キロバイトに増加しました。これによって，確保済みTenured領域の未使用メモリサイズが14,912キロバイト−14,906キロバイト＝6キロバイトとなり，10,000バイト（約10キロバイト）を下回りました。

1行目のCopyGCの原因は，オブジェクトアロケーションの失敗です。1行目のCopyGCと2行目のFullGCは，Javaプログラムに制御が戻る前に連続して発生します。

(e)　CopyGC実施時にTenured領域の拡張が発生した場合

CopyGC実施時のTenured領域へのオブジェクトの移動によって，確保済みTenured領域の拡張が発生した場合の，拡張verbosegc情報の出力例を次に示します。太字の部分がFullGC発生の要因を示す個所です。

…
[VGC]<Fri May 25 15:42:00 2007>[GC 12745K->10151K(15872K), 0.0048346 secs][DefNew::Eden: 4416K->0K(4416K)][DefNew::Survivor: 137K->512K(512K)][Tenured: 8192K->9639K(10944K)][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:ObjAllocFail][User: 0.0156250 secs][Sys: 0.0000000 secs]
[VGC]<Fri May 25 15:42:00 2007>[GC 14563K->14536K(19072K), 0.0104957 secs][DefNew::Eden: 4412K->0K(4416K)][DefNew::Survivor: 512K->510K(512K)][Tenured: 9639K->14026K(14144K)][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:ObjAllocFail][User: 0.0156250 secs][Sys: 0.0000000 secs]
[VGC]<Fri May 25 15:42:00 2007>[Full GC 14536K->8610K(19072K), 0.0287254 secs][DefNew::Eden: 0K->0K(4416K)][DefNew::Survivor: 510K->0K(512K)][Tenured: 14026K->8610K(14144K)][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:ObjAllocFail][User: 0.0312500 secs][Sys: 0.0000000 secs]
…

この出力例からは，次のことが分かります。

2行目のCopyGCでNew領域からTenured領域へのオブジェクトが移動したことによって，Tenured領域が最低でも14,026キロバイト以上必要になりました。このため，確保済みTenured領域サイズが10,944キロバイトから14,144キロバイトに拡張されました。

2行目のCopyGCの原因は，オブジェクトアロケーションの失敗です。2行目のCopyGCと3行目のFullGCは，Javaプログラムに制御が戻る前に連続して発生します。

(f)　java.lang.System.gc()メソッドが実行された場合

アプリケーション内でjava.lang.System.gc()メソッドが実行された場合の，拡張verbosegc情報の出力例を次に示します。太字の部分がFullGC発生の要因を示す個所です。

…
[VGC]<Mon Apr 18 20:36:29 2005>[Full GC 330K->150K(3520K), 0.0387690 secs][DefNew::Eden: 330K->0K(2048K)][DefNew::Survivor: 0K->0K(64K)][Tenured: 0K->150K(1408K)][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:System.gc][User: 0.0156250 secs][Sys: 0.0312500 secs]
…

この出力例からは，次のことが分かります。

FullGCの要因は，アプリケーション内でのjava.lang.System.gc()メソッド呼び出しです。

(g)　Metaspace領域へのオブジェクトアロケーションに失敗した場合

Metaspace領域にアロケーションしたいメモリサイズが確保済みMetaspace領域の未使用メモリサイズを上回る場合の，拡張verbosegc情報の出力例を次に示します。太字の部分がFullGC発生の要因を示す個所です。

…
[VGC]<Wed Jan 07 01:56:13 2015>[Full GC 11273K->6037K(15872K), 0. 0060004 secs][DefNew::Eden: 442K->0K(4416K)][DefNew::Survivor: 512K->0K(512K)][Tenured: 10319K->6037K(10944K)][Metaspace: 22811K(24520K, 24576K)->22811K(24520K, 24576K)][class space: 10758K(10988K, 11008K)->10758K(10988K, 11008K)][cause:MetaspaceAllocFail][User: 0.0312002 secs][Sys: 0.0000000 secs]
…

この出力例からは，次のことが分かります。

Metaspace領域にアロケーションしようとしたメモリサイズが，確保済みMetaspace領域の未使用メモリサイズ（24576キロバイト−22811キロバイト＝1765キロバイト）を上回りました。

FullGCの要因は，Metaspace領域のアロケーションの失敗です。

(h)　javagcコマンド実行によるFullGCが発生した場合

javagcコマンドを実行した場合の，拡張verbosegc情報の出力例を次に示します。太字の部分がFullGC発生の要因を示す個所です。

…
[VGC]<Mon Apr 18 21:46:50 2005>[Full GC 369K->189K(3520K), 0.0403010 secs][DefNew::Eden: 369K->0K(2048K)][DefNew::Survivor: 0K->0K(64K)][Tenured: 0K->189K(1408K)][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:JavaGC Command][User: 0.0156250 secs][Sys: 0.0312500 secs]
…

この出力例からは，次のことが分かります。

FullGCの要因は，javagcコマンド実行です。

(i)　jheapprofコマンド実行によるFullGCが発生した場合

jheapprofコマンドを実行した場合の，拡張verbosegc情報の出力例を次に示します。太字の部分がFullGC発生の要因を示す個所です。

…
[VGC]<Mon Apr 18 21:46:50 2005>[Full GC 369K->189K(3520K), 0.0403010 secs][DefNew::Eden: 369K->0K(2048K)][DefNew::Survivor: 0K->0K(64K)][Tenured: 0K->189K(1408K)][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:JHeapProf Command][User: 0.0156250 secs][Sys: 0.0312500 secs]
…

この出力例からは，次のことが分かります。

FullGCの要因は，jheapprofコマンド実行です。

2.3　G1GCの仕組みとJavaVMのメモリチューニング

ここでは，G1GCの仕組みとJavaVMのメモリチューニングの方法について説明します。

2.3.1　G1GCの仕組み

G1GCの仕組みを説明します。

(1)　G1GCの概要

GCは，プログラムが使用し終わったメモリ領域を自動的に回収して，ほかのプログラムが利用できるようにするための技術です。

GCの実行中は，プログラムの処理が停止します。このため，GCを適切に実行できるかどうかが，システムの処理性能に大きく影響します。

プログラムの中でnewによって作成されたJavaオブジェクトは，JavaVMが管理するメモリ領域に格納されます。Javaオブジェクトが作成されてから不要になるまでの期間を，Javaオブジェクトの寿命といいます。

Javaオブジェクトには，寿命の短いオブジェクトと寿命の長いオブジェクトがあります。サーバサイドで動作するJavaアプリケーションの場合，リクエストやレスポンス，トランザクション管理などで，多くのJavaオブジェクトが作成されます。これらのJavaオブジェクトは，その処理が終わると不要になる，寿命が短いオブジェクトです。一方，アプリケーションの動作中使用され続けるJavaオブジェクトは，寿命が長いオブジェクトです。

効果的なGCを実行するためには，寿命の短いオブジェクトに対してGCを実行して，効率良くメモリ領域を回収することが必要です。また，繰り返し使用される寿命の長いオブジェクトに対する不要なGCを抑止することが，システムの処理性能の低下防止につながります。これを実現するのが，世代別GCです。

世代別GCでは，Javaオブジェクトを，寿命が短いオブジェクトが格納されるNew領域と，寿命が長いオブジェクトが格納されるTenured領域に分けて管理します。New領域はさらに，newによって作成されたばかりのオブジェクトが格納されるEden領域と，1回以上のGCの対象になり，回収されなかったオブジェクトが格納されるSurvivor領域に分けられます。New領域内で一定回数以上のGCの対象になったJavaオブジェクトは，長期間必要なJavaオブジェクトと判断され，Tenured領域に移動します。

世代別GCで管理するメモリ空間とJavaオブジェクトの概要を次の図に示します。

図2‒12　世代別GCで管理するメモリ空間とJavaオブジェクトの概要

G1GCの世代別GCで実行されるGCには，次の3種類があります。

YoungGC

Eden領域とSurvivor領域を対象にしたGCです。Javaオブジェクトの作成によって，Eden領域を使い切ると発生します。

MixedGC

Eden領域とSurvivor領域とTenured領域の一部を対象にしたGCです。Concurrent Markingと呼ばれるオブジェクトの解析処理に基づき発生します。Javaオブジェクトの作成によって，Eden領域を使い切ると発生します。

FullGC

Tenured領域も含む，JavaVM固有領域全体を対象にしたGCです。Tenured領域やMetaspace領域，Humongous領域を新たに確保できないと発生します。

一般的に，YoungGCとMixedGCの方が，FullGCよりも短い時間で処理できます。

次に，GCの処理について，あるJavaオブジェクト（オブジェクトA）を例にして説明します。

Eden領域で実行される処理

オブジェクトAの作成後，1回目のYoungGCまたはMixedGCが実行された時点で使用されていない場合，オブジェクトAは破棄されます。

1回目のYoungGCまたはMixedGCが実行された時点で使用されていた場合，オブジェクトAはEden領域からSurvivor領域に移動します。

Survivor領域で実行される処理

Survivor領域に移動したオブジェクトAは，そのあと何回かYoungGCまたはMixedGCが実行されると，Survivor領域からTenured領域に移動します。移動する回数のしきい値は，JavaVMオプションやJavaヒープの利用状況によって異なります。「図2-12」では，しきい値をn回としています。

Survivor領域への移動後，n回目未満のYoungGCまたはMixedGCが実行された時点でオブジェクトAが使用されていなかった場合，オブジェクトAはそのYoungGCまたはMixedGCで破棄されます。

Tenured領域で実行される処理

オブジェクトAがTenured領域に移動した場合，そのあとのYoungGCでオブジェクトAが破棄されることはありません。YoungGCは，Eden領域とSurvivor領域だけを対象としているためです。MixedGCが発生した場合は，Tenured領域内の一部のオブジェクトが破棄されます。

MixedGCで破棄されるオブジェクトの数よりも，Tenured領域に移動するオブジェクトの数が多い場合，Tenured領域の使用サイズは増加します。新たにTenured領域を確保できなくなると，FullGCが発生します。

JavaVMのチューニングでは，JavaVMオプションでそれぞれのメモリ空間のサイズや割合を適切に設定することで，不要なオブジェクトがTenured領域に移動することを抑止します。これによって，FullGCが頻発することを防ぎます。

(2)　オブジェクトの寿命と年齢の関係

オブジェクトがYoungGCまたはMixedGCの対象になった回数をオブジェクトの年齢といいます。

オブジェクトの寿命と年齢の関係を次の図に示します。

図2‒13　オブジェクトの寿命と年齢の関係

アプリケーションが開始して初期化処理が完了したあとで，何度かのYoungGCまたはMixedGCが実行されると，長期間必要になる寿命の長いオブジェクトはTenured領域に移動します。このため，アプリケーションの開始後しばらくすると，Javaヒープの状態は安定し，作成されるJavaオブジェクトとしては，寿命が短いオブジェクトが多くなります。特に，New領域のチューニングが適切にできている場合，Javaヒープが安定したあとの大半のオブジェクトは，1回目のYoungGCまたはMixedGCで回収される，寿命が短いオブジェクトになります。

(3)　New領域を対象としたGCの仕組み

JavaVMでは，YoungGCまたはMixedGCの対象になるNew領域のメモリ空間を，Eden領域，Survivor領域に分けて管理します。さらに，Survivor領域は，From空間とTo空間に分けられます。From空間とTo空間は，同じメモリサイズです。

New領域の構成を次の図に示します。

図2‒14　New領域の構成

Eden領域は，newによって作成されたオブジェクトが最初に格納される領域です。プログラムでnewが実行されると，Eden領域のメモリが確保されます。

Eden領域がいっぱいになると，YoungGCまたはMixedGCが実行され，次の処理が実行されます。

Eden領域およびSurvivor領域のFrom空間にあるJavaオブジェクトのうち，使用中のJavaオブジェクトが，Survivor領域のTo空間にコピーされます。使用されていないJavaオブジェクトは破棄されます。

Survivor領域のTo空間とFrom空間が入れ替わります。

この結果，Eden領域とTo空間は空になり，使用中のオブジェクトはFrom空間に存在することになります。

YoungGCまたはMixedGC実行時に発生するオブジェクトの移動を次の図に示します。

図2‒15　CopyGC実行時に発生するオブジェクトの移動

このようにして，使用中のオブジェクトは，YoungGCまたはMixedGCが発生するたびに，From空間とTo空間を行ったり来たりします。ただし，寿命の長いオブジェクトを行き来させ続けると，移動処理の負荷などが問題になります。これを防ぐために，From空間とTo空間でJavaオブジェクトを入れ替える回数にしきい値を設定して，年齢がしきい値に達したJavaオブジェクトはTenured領域に移動させるようにします。

(4)　オブジェクトの退避

年齢がしきい値に達していないJavaオブジェクトがTenured領域に移動することを，退避といいます。退避は，YoungGCまたはMixedGC実行時にEden領域およびFrom空間で使用中のオブジェクトが多くなり，移動先であるTo空間のメモリサイズが不足する場合に発生します。この場合，To空間に移動できなかったオブジェクトが，Tenured領域に移動します。

図2‒16　オブジェクトの退避

オブジェクトの退避が発生した場合，Tenured領域に本来格納されないはずの寿命の短いオブジェクトが格納されます。これが繰り返されると，YoungGCまたはMixedGCで回収されるはずのオブジェクトがメモリ空間に残っていくため，Javaヒープのメモリ使用量が増加していき，最終的にはFullGCが発生します。

オブジェクトの退避が発生した場合のメモリ使用量の変化について，次の図に示します。

図2‒17　オブジェクトの退避が発生した場合のメモリ使用量の変化

FullGCでは，システムが数秒から数十秒停止することがあります。

したがって，メモリ空間の構成とメモリサイズを検討するときには，オブジェクトの退避が発生しないように，Eden領域とSurvivor領域のバランスを検討する必要があります。

(5)　メモリ空間とリージョンの関係

G1GCで管理するJavaヒープ領域は，オブジェクトの寿命が短いオブジェクトが格納されるNew領域と，寿命が長いオブジェクトが格納されるTenured領域に分けて管理します。このうちNew領域はさらに2つの領域に分けて管理されており，作成されたばかりのオブジェクトが格納されるEden領域と，1回以上のGCの対象になり，回収されなかったオブジェクトが格納されるSurvivor領域に分けられます。New領域内で一定回数以上のGCの対象になったオブジェクトは，寿命が長いオブジェクトと判断され，Tenured領域に移動します。

アプリケーション実行中のG1GCで管理するメモリ空間の構成を次の図に示します。なお，Eden領域，Survivor領域，Tenured領域，Free領域を合わせた領域をJavaヒープ領域といいます。

図2‒18　アプリケーション実行中のG1GCで管理するメモリ空間の構成

G1GCでは，Tenured領域があらかじめ割り当てられていません。Tenured領域にオブジェクトを移動させる場合，Free領域のリージョンをTenured領域に割り当ててオブジェクトを移動します。また，G1GCではGC後にNew領域に対して拡張や縮小をします（以降，リサイズと表記します）。リサイズでNew領域を拡張する場合は，Free領域のリージョンに割り当て，縮小する場合はNew領域のリージョンを回収し，Free領域に割り当てます。サイズの大きなオブジェクトを作成する場合は，Humongous領域にオブジェクトが格納されます。

各領域の用途を次に示します。

New領域

寿命が短いオブジェクトが格納される領域です。Eden領域とSurvivor領域から構成されます。GC後に次のGCに向けてリサイズされます。詳細については，「(8)　YoungGC」を参照してください。

Eden領域

作成されたオブジェクトが最初に格納される領域です。

Survivor領域

New領域に格納されていたオブジェクトのうち，GC実行時に回収されなかったオブジェクトが格納される領域です。Survivor領域はFrom空間とTo空間で構成されます。From空間とTo空間は同じサイズです。

Tenured領域

寿命が長いオブジェクトが格納される領域です。Survivor領域で指定回数を超えてGC実行対象になり，回収されなかったオブジェクトが移動します。

Humongous領域

Tenured領域の一部でサイズの大きなオブジェクトを格納する領域です。Humongous領域のオブジェクトは，FullGCまたはConcurrent Cleanupで回収されます。Concurrent Cleanupの詳細については，「(9)　Concurrent Marking（CM）」を参照してください。

Free領域

New領域やTenured領域に割り当てられていない領域です。Tenured領域のリージョンが足りなくなった場合やGC後のNew領域をリサイズする場合に，New領域やTenured領域に割り当てられます。

Metaspace領域

ロードされたclassなどの情報を格納する領域です。なお，Metaspace領域はリージョン単位で管理されていません。Metaspace領域のオブジェクトはFullGCでだけ回収されます。

「図2-18」はJavaヒープ領域の各領域を連続領域として表現していますが，実際には各領域は連続領域として確保されていません。G1GCではJavaヒープ領域をリージョンと呼ばれるブロック単位で管理しており，次の図のように領域が分散して確保されています。

図2‒19　実際のメモリ空間の構造

ここではそれぞれの領域のリージョンを領域名＋リージョンと表記します。例えば，Eden領域のリージョンをEdenリージョン，New領域のリージョンはNewリージョンと表記します。

(6)　リージョンの使われ方

オブジェクトが作成されると，最初にEdenリージョンに格納されます。1つのオブジェクトのサイズが，リージョンサイズの半分を超えている大きいオブジェクト※の場合は，1つのオブジェクトに対し，連続した複数のリージョンが割り当てられ格納されます。連続した複数のリージョンはFree領域から確保され，Humongous領域に割り当てられます。Humongous領域はFullGCまたはConcurrent Cleanupでだけ回収の対象となるため，サイズの大きなオブジェクトが多数作成されるような場合には，G1GCは不向きとなります。詳細については，「2.3.2(3)(a)　FullGCの発生を抑止する考え方」を参照してください。

また，1つのリージョンのサイズは，起動時にJavaヒープ領域の初期サイズの比率から求められ，起動中は固定です。1つのリージョンの最小サイズは1MBであり，最大サイズは32MBです。

注※

ここでいうサイズの大きな1つのオブジェクトとは，多数のインスタンスフィールドを持つオブジェクトや長大な配列を持つオブジェクトのことを指します。リージョンのサイズが1MBの場合，512KBを超えるようなオブジェクトを指し，例えば約13万個のint型のインスタンスフィールドを持つようなオブジェクトや約50万個の要素数のバイト配列を持つオブジェクトなどが当てはまります。

リージョンの使用から回収までの流れを次の図に示します。

図2‒20　リージョンの使われ方

この図はリージョンの使われ方を示した図です。図の1.〜4.の処理の詳細を次に示します。

オブジェクト作成時

オブジェクトが作成される場合，Edenリージョンにオブジェクトを格納します。サイズの大きなオブジェクトを作成する場合は，FreeリージョンをHumongousリージョンに割り当てオブジェクトを格納します。Edenリージョンに空き領域がなくなると，新しいEdenリージョンにオブジェクトを格納し，Humongousリージョンに空き領域がなくなると，新たにFreeリージョンからHumongousリージョンを割り当て，オブジェクトを格納します。

GC時の選択処理

GCの要件を満たすと，実行するGC方式の基準に従って，対象とするリージョンを選択します。

GC時のEvacuation

回収の対象となったリージョン内で使用中のオブジェクトは，ほかのリージョンにコピーされます。この処理をEvacuationといいます。Evacuation後のリージョンは，使用済みのオブジェクトとコピー済みである不要となったオブジェクトだけ格納されているため，リージョン単位で回収されます。

GC後

回収されたリージョンはFreeリージョンとなり，再利用されます。

(7)　G1GCで実行されるGC

G1GCの世代別GCで実行されるGCには，次の3種類があります。

YoungGC

New領域を対象とするGCです。YoungGCにはYoungGC(normal)とYoungGC中にマーキングをするYoungGC(initial-mark)があります。詳細については，「(8)　YoungGC」を参照してください。なお，単にYoungGCと表記した場合，YoungGC(normal)とYoungGC(initial-mark)の両方に当てはまる事項となります。また，YoungGC(normal)とYoungGC(initial-mark)を区別して表す場合は，“(normal)”と“(initial-mark)”を明記します。ただし，ログファイルのGC種別にはYoungGC(normal)はYoungGCという種別で出力します。YoungGCはJavaオブジェクトの作成によって，Eden領域を使い切ると発生します。

MixedGC

New領域とTenured領域を対象とするGCです。Tenuredリージョンは目標停止時間に合わせて部分的な範囲を対象とします。詳細については，「(10)　MixedGC」を参照してください。MixedGCはYoungGC同様，Javaオブジェクトの作成によって，Eden領域を使い切ると発生しますが，Concurrent Markingと呼ばれるオブジェクトが使用中かどうかの解析処理の結果に基づいて発生します。詳細については，「2.3.1(9)　Concurrent Marking（CM）」を参照してください。そのため，解析が十分にされていない場合や解析の結果MixedGCの効果が低いと予測される場合は，YoungGC(normal)が発生します。

FullGC

Tenured領域やMetaspace領域，Humongous領域を含む，JavaVM固有領域全体を対象にしたGCです。詳細については，「(11)　FullGC」を参照してください。Tenured領域やMetaspace領域，Humongous領域を確保できなかった場合に発生します。

それぞれのGCが対象とする領域をまとめると次の図となります。

図2‒21　各GCの対象範囲

また，各GCの状態遷移図を次の図に示します。

図2‒22　各GCの状態遷移図

YoungGC(normal)実行後，Concurrent Marking（CM）が実行されておらず，Tenured領域の使用率がJavaヒープ領域の45%を超えた場合は，次のGCではYoungGC(initial-mark)を実行する状態に遷移します。

YoungGC(normal)実行後，CMが実行されておらず，Tenured領域の使用率がJavaヒープ領域の45%以下の場合は，次のGCもYoungGC(normal)を実行する状態のままです。

YoungGC(initial-mark)実行後，次のGCではYoungGC(normal)とCMを並行して実行する状態に遷移します。

CMが実行中の場合は，YoungGC(normal)を実行する状態のままです。

CM終了直後のYoungGC(normal)で予測回収率が10%を超えている場合，次のGCではMixedGCを実行する状態に遷移します。

予測回収率が10%以下の場合，次のGCもYoungGC(normal)を実行する状態のままです。

MixedGC実行後，予測回収率が10%を超えている場合，次のGCではMixedGCを実行する状態のままです。

MixedGC実行後，予測回収率が10%以下の場合，次のGCではYoungGC(normal)を実行する状態に遷移します。

ただし，次の場合GCの状態に関係なく，条件を満たすと対応するGCを実行します。

YoungGCまたは，MixedGCを実行しても空き領域を確保できなかった場合，FullGCを実行します。FullGC実行後はYoungGC(normal)を実行する状態に遷移します。

サイズの大きなオブジェクトを確保時，CMが実行されておらず，Tenured領域の使用サイズと確保するオブジェクトのサイズの合計がJavaヒープ領域の45%を超えている場合，YoungGC(initial-mark)を実行します。

次に，G1GCの処理の流れについて，Javaオブジェクトを例にして説明します。

図2‒23　G1GCの流れ

YoungGC

この図のようにNew領域に割り当てたリージョンに空きがなくなるとYoungGCが発生します。YoungGCでは使用中のオブジェクトはSurvivor領域に割り当てたリージョンに移動し，使用済みのオブジェクトはリージョンごと解放します。また，SerialGCのCopyGCと同様，YoungGC発生時に使用中のオブジェクトはSurvivor領域に割り当てたリージョン間を移動し続け，ある一定の回数を移動するとTenured領域に割り当てたリージョンに移動します。YoungGC後，上の図のようにGCに掛かった時間から，次のGCに掛かる時間を予測し，New領域のサイズを変更します。この図の場合は，予測した時間よりGCに掛かる時間が長いため，New領域を縮小した場合の例です。

MixedGC

Tenured領域の使用率が増加すると，MixedGCが発生します。MixedGCではNew領域に割り当てたリージョンに加えて，目標停止時間内に収まる範囲で，一部のTenured領域に割り当てたリージョンをGCの対象とします。この一部のTenured領域に割り当てたリージョンは，アプリケーションと並行して実行しているオブジェクトが使用中かどうかの解析情報に基づき，解放されるサイズが大きいと予測されるリージョンから優先してGCの対象となります。そのため，オブジェクトの情報解析が十分にされていない場合や解析の結果MixedGCの効果が低い場合は，MixedGCは発生しません。

FullGC

Javaヒープ内のリージョンに空きがなくなり，MixedGCが発生しない場合，Javaヒープ全体を対象としてFullGCが発生します。

(8)　YoungGC

YoungGCの流れを次の図に示します。

図2‒24　YoungGCの流れ

(a)　実行契機

YoungGC(normal)

Eden領域にオブジェクトを確保できなかった場合に発生します。また，サイズの大きなオブジェクトをHumongous領域に確保できなかった場合にも発生します。

YoungGC(initial-mark)

直前に実行されたYoungGC(normal)終了時に，Tenured領域の使用サイズがJavaヒープ領域の45%を超えていた場合，1.の実行契機を満たすとYoungGC(initial-mark)が実行されます。また，サイズの大きなオブジェクトを確保時，Tenured領域の使用サイズとオブジェクトの確保サイズの合計サイズがJavaヒープ領域の45%を超えた場合，YoungGC(initial-mark)が実行されます。

(b)　対象範囲

New領域

(c)　処理内容

YoungGCが発生するとシングルスレッドでリージョンの選択処理をし，そのあとマルチスレッドでEvacuationをします。

YoungGCのEvacuationではEden領域とFrom空間内の使用中オブジェクトをTo空間またはTenured領域に移動し，Eden領域とFrom空間を回収します。移動や回収の仕組みはCopyGCの仕組みと同じです。CopyGCの詳細については，「2.2.1(3)　CopyGCの仕組み」を参照してください。

YoungGCでは，これまでに発生したGCのGC停止時間の統計から予測をし，次回のGCの予測停止時間が目標停止時間内に収まるようにNew領域のサイズを変更します。

New領域は最小サイズと最大サイズが存在し，その範囲内でリサイズをします。New領域は全GCで対象となるため，GC停止時間はNew領域が最小サイズの場合に掛かるGC停止時間より短くすることはできません。

CMが終了後のYoungGCでは，予測回収サイズがJavaヒープ領域の10%を超えていた場合，次回のGCをMixedGCにするか判定します。次回のGCにMixedGCが選択された場合，Tenuredリージョンを多く対象とするように予測してNew領域のサイズを変更します。

YoungGC(initial-mark)のEvacuationではEvacuation中にローカル変数や使用中のオブジェクトから直接参照されているオブジェクトにマーク付けをします。このマーキングの結果は，Concurrent Markingに利用されます。Concurrent Markingの処理の詳細については，「(9)　Concurrent Marking（CM）」を参照してください。

(d)　処理結果

Eden領域：オブジェクトが回収され，空になります。GC後リサイズされます。

Survivor領域：From空間のオブジェクトが回収され，空になります。GC後リサイズされます。

Tenured領域：長期間必要と判断されたオブジェクトがTenured領域に移動します。

Humongous領域：変化はありません。

Metaspace領域：変化はありません。

Free領域：GC後のリサイズによって，増減します。

(e)　アプリケーションの停止の有無

停止します。

(f)　ほかのGCとの関係

CM：YoungGC中に実行されません。

MixedGC：YoungGC中に実行されません。

FullGC：YoungGC中に実行要件を満たすと，YoungGCを中止して実行されます。

(g)　補足

関連オプション

Evacuationをするスレッド数は-XX:ParallelGCThreadsオプションで変更できます。スレッド数を増やすとYoungGCに掛かる時間が小さくなります。また，オプションを指定しない場合，スレッド数は-XX:ParallelGCThreadsオプションのデフォルト値が用いられます。-XX:ParallelGCThreadsオプションについては，「5.4　日立JavaVMで指定できるJava HotSpot VMのオプション」の「表5-9　指定できるJava HotSpot VMのオプション」にある「-XX:ParallelGCThreads」を参照してください。

確認方法

YoungGCの確認はログ上のGCの種別が“YoungGC”または“YoungGC(initial-mark)”であることから確認できます。また，New領域のリサイズはEden領域のサイズ変化とSurvivor領域のサイズ変化から確認できます。

[VG1]<Wed Jun 12 11:21:10 2013>[Young GC 899070K/899072K(1048576K)->501755K/501760K(1048576K), 0.0931560 secs][Status:-][G1GC::Eden: 389120K(389120K)->0K(397312K)][G1GC::Survivor: 41984K->41984K][G1GC::Tenured: 459776K->459776K][G1GC::Humongous: 2048K->2048K][G1GC::Free: 609536K->607232K][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:G1EvacuationPause][RegionSize: 1024K][Target: 0.2000000 secs][Predicted: 0.2495800 secs][TargetTenured: 0K][Reclaimable: 0K(0.00%)][User: 0.0156250 secs][Sys: 0.0312500 secs][IM: 729K, 928K, 0K][TC: 509][DOE: 16K, 171][CCI: 2301K, 49152K, 2304K]

このログの場合GC前のNew領域のサイズは389120K＋41984K＝431104Kであり，GC後のNew領域のサイズは397312K＋41984K＝439296Kであるため，New領域が拡張されたことが分かります。ログの記述内容や詳細に関しては，「-XX:[+|-]HitachiVerboseGC（拡張verbosegc情報出力オプション）」を参照してください。

(9)　Concurrent Marking（CM）

Concurrent Markingの流れを次の図に示します。

図2‒25　Concurrent Markingの流れ

(a)　実行契機

CMは大きく次の5つの処理から構成されます。それぞれの実行契機について示します。なお，1.〜5.の表記はこの図の1.〜5.に対応しています。

Concurrent Root Region Scan：

YoungGC(initial-mark)終了後，実行されます。

Concurrent Mark：

1.の終了後，1.に続けて実行されます。

Remark：

2.の終了後，アプリケーションを停止できるタイミングで実行されます。

Cleanup：

3.の終了後，アプリケーションを停止できるタイミングで実行されます。

Concurrent Cleanup：

4.の終了後，4.に続けて実行されます。

(b)　対象範囲

New領域，Tenured領域およびHumongous領域

(c)　処理内容

CMは大きく次の5つの処理から構成されます。それぞれの処理の詳細を示します。

Concurrent Root Region Scan：

ローカル変数や使用中のオブジェクトから直接参照されているSurvivor領域内のオブジェクトにマークを付ける処理です。マルチスレッドで実行されます。

Concurrent Mark：

YoungGC(initial-mark)のマーキングと1.のマーキングでマークを付けたオブジェクトが参照しているオブジェクトにマークを付ける処理です。マルチスレッドで実行されます。

Remark：

2.のマーキング中に参照関係が変化したオブジェクトのマークを付け直す処理です。マルチスレッドで実行されます。

Cleanup：

リージョンごとに使用中オブジェクトの合計サイズを求める処理です。また，次のCMに備え，マークの初期化もします。マルチスレッドで実行されます。

Concurrent Cleanup：

使用中のオブジェクトが1つも存在しないリージョンを回収する処理です。シングルスレッドで実行されます。

(d)　処理結果

Eden領域：

使用中のオブジェクトに対応した領域にマークが付きます。

5.の処理でEdenリージョンが回収された場合，領域サイズが減少します。

Survivor領域：

使用中のオブジェクトに対応した領域にマークが付きます。

5.の処理でSurvivorリージョンが回収された場合，領域サイズが減少します。

Tenured領域：

使用中のオブジェクトに対応した領域にマークが付きます。

5.の処理でTenuredリージョンが回収された場合，領域サイズが減少します。

Humongous領域：

使用中のオブジェクトに対応した領域にマークが付きます。

5.の処理でHumongousリージョンが回収された場合，領域サイズが減少します。

Metaspace領域：

変化はありません。

Free領域：

使用中のオブジェクトが1つも存在しないリージョンを回収した場合，領域サイズが増加します。

(e)　アプリケーションの停止の有無

Concurrent Root Region Scan：

CMスレッドで，アプリケーションを停止しないで実行されます。

Concurrent Mark：

CMスレッドで，アプリケーションを停止しないで実行されます。

Remark：

VMスレッドで，アプリケーションを停止して実行されます。

Cleanup：

VMスレッドで，アプリケーションを停止して実行されます。

Concurrent Cleanup：

CMスレッドで，アプリケーションを停止しないで実行されます。

アプリケーションは停止しませんが，4.の処理の終了から5.の処理が終了するまでの間にFullGCや新しいリージョンの確保がされた場合，5.の処理が終了するまで，YoungGC(normal)やFullGCや新しいリージョンの確保の処理を待たせます。

(f)　ほかのGCとの関係

注　CMの処理中はYoungGC(initial-mark)は発生しません。

Concurrent Root Region Scan：

YoungGC(normal)：実行されません。

MixedGC：実行されません。

FullGC：実行されません。

Concurrent Mark：

YoungGC(normal)：2.の処理中に実行された場合，2.の処理を中断します。YoungGC(normal)が終了すると，再開されます。

MixedGC：実行されません。

FullGC：2.の処理中に実行された場合，2.の処理を中止します。途中結果は破棄されます。

Remark：

YoungGC(normal)：実行されません。

MixedGC：実行されません。

FullGC：実行されません。

Cleanup：

YoungGC(normal)：実行されません。

MixedGC：実行されません。

FullGC：実行されません。

Concurrent Cleanup：

YoungGC(normal)：5.の処理中に実行された場合，5.の処理が終了するまでYoungGC(normal)を待機させます。

MixedGC：実行されません。

FullGC：5.の処理中に実行された場合，5.の処理が終了するまでFullGCを待機させます。

(g)　補足

関連オプション

CMをするスレッド数は-XX:ConcGCThreadsオプションで指定できます。CMをするスレッド数を増やすとスループットが低下します。-XX:ConcGCThreadsオプションを指定しなかった場合，スレッド数は-XX:ConcGCThreadsオプションのデフォルト値となります。詳細については，「5.4　日立JavaVMで指定できるJava HotSpot VMのオプション」の「表5-9　指定できるJava HotSpot VMのオプション」にある「-XX:ConcGCThreads」を参照してください。

確認方法

Concurrent Root Region Scan，Concurrent Mark，Concurrent Cleanupの確認はログの先頭に［VCM］の識別子が付いていることから確認できます。Concurrent Markのログのイメージを次に示します。

[VCM]<Wed Jul 31 11:45:23 2013>[Concurrent Mark Start][User: 0.0000000 secs][Sys: 0.0000000 secs]
[VCM]<Wed Jul 31 11:45:31 2013>[Concurrent Mark End][User: 0.0321549 secs][Sys: 0.0129454 secs]

VCMのログが複数行にわたるため，CMログは開始時にStart，終了時にEndが出力されます。複数行に渡る場合，CPU使用時間はEndのログにStartからEndまでの処理時間が出力され，Startのログは0が出力されます。

ログの記述内容や詳細に関しては，「-XX:[+|-]HitachiVerboseGC（拡張verbosegc情報出力オプション）」を参照してください。

またRemark，Cleanupの処理は処理中にアプリケーションを停止するため，VG1ログに出力されます。Remark，Cleanupの処理はGCログのGC種別が“CM Remark”，“CM Cleanup”という出力から判断できます。

(10)　MixedGC

MixedGCの処理の流れを次の図に示します。

図2‒26　MixedGCの処理の流れ

(a)　実行契機

予測回収サイズがJavaヒープ領域の10%を超えている場合，次のGCにMixedGCが予約されます。その判定はCM終了直後のYoungGC(normal)終了時，またはMixedGCの終了時にされます。

(b)　対象範囲

New領域とTenured領域の一部

(c)　処理内容

MixedGCが発生すると，シングルスレッドでリージョンの選択処理を，マルチスレッドでEvacuationを実行します。

MixedGCではNew領域をGC対象とし，予測停止時間が目標停止時間に収まる範囲でTenured領域を部分的にGC対象に追加します。

MixedGCのEvacuationでは，New領域に対してはYoungGCのEvacuationと同じ処理をします。詳細については，「(8)　YoungGC」を参照してください。

GC対象に追加したTenured領域に対しては，Tenuredリージョン内の使用中のオブジェクトを別のTenuredリージョンに詰め直します。

MixedGC後も予測回収サイズがJavaヒープ領域の10%を超えている場合，継続してMixedGCが選択され，要件を満たしていない場合，通常のYoungGCが実行されます。

(d)　処理結果

Eden領域：

オブジェクトが回収され，空になります。GC後リサイズされます。

Survivor領域：

From空間のオブジェクトが回収され，空になります。GC後リサイズされます。

Tenured領域：

長期間必要と判断されたオブジェクトがTenured領域に移動します。GC対象に追加された領域のオブジェクトが回収されます。

Humongous領域：

変化はありません。

Metaspace領域：

変化はありません。

Free領域：

GC後のリサイズによって，増減します。

(e)　アプリケーションの停止の有無

停止します。

(f)　ほかのGCとの関係

CM：MixedGC中に実行されません。

YoungGC：MixedGC中に実行されません。

FullGC：MixedGC中に実行要件を満たすと，MixedGCを中止して実行されます。

(g)　補足

関連オプション

Evacuationをするスレッド数は-XX:ParallelGCThreadsオプションで変更できます。スレッド数を増やすとMixedGCに掛かる時間が小さくなります。また，オプションを指定しない場合，スレッド数はOSが認識しているCPU数が用いられます。-XX:ParallelGCThreadsオプションについては，「5.4　日立JavaVMで指定できるJava HotSpot VMのオプション」の「表5-9　指定できるJava HotSpot VMのオプション」にある「-XX:ParallelGCThreads」を参照してください。

確認方法

MixedGCの確認はログのGCの種別の“Mixed GC”から確認できます。また，TargetTenuredの項目からMixedGCで選択されたTenured領域のサイズを確認できます。オブジェクトの予測回収サイズに関してはReclaimableの項目から確認できます。ログの記述内容や詳細に関しては，「-XX:[+|-]HitachiVerboseGC（拡張verbosegc情報出力オプション）」を参照してください。

[VG1]<Wed Jun 12 11:21:10 2013>[Mixed GC 899070K/899072K(1048576K)->501742K/501760K(1048576K), 0.0931560 secs][Status:-][G1GC::Eden: 389120K(389120K)->0K(397312K)][G1GC::Survivor: 41984K->41984K][G1GC::Tenured: 459776K->459776K][G1GC::Humongous: 2048K->2048K][G1GC::Free: 609536K->607232K][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:G1EvacuationPause][RegionSize: 1024K][Target: 0.2000000 secs][Predicted: 0.2495800 secs][TargetTenured: 2048K][Reclaimable: 17703K(1.69%)][User: 0.0156250 secs][Sys: 0.0312500 secs][IM: 729K, 928K, 0K][TC: 509][DOE: 16K, 171][CCI: 2301K, 49152K, 2304K]

(11)　FullGC

FullGCの流れを次の図に示します。

図2‒27　FullGCの流れ

(a)　実行契機

Free領域がなくなり，Evacuationのコピー先が確保できなかった場合やHumongous領域が確保できなかった場合に実行されます。また，Metaspace領域の空き領域がなくなった場合やSystem.gc()が呼ばれた場合も実行されます。

(b)　対象範囲

New領域，Tenured領域，Humongous領域およびMetaspace領域

(c)　処理内容

FullGCはシングルスレッドでアプリケーションスレッドを停止して実行されます。

FullGCが発生すると目標停止時間に関係なく，GCが終了するまでアプリケーションを停止します。

FullGCの処理はSerialGCのFullGCと同じ処理です。FullGCを実行しても領域が確保できなかった場合は，OutOfMemoryが発生します。詳細については，「2.2.1　SerialGCの仕組み」を参照してください。

一般的に，YoungGCやMixedGCの方がFullGCに比べて短い時間で処理できます。

(d)　処理結果

Eden領域：オブジェクトが回収され，空になります。

Survivor領域：使用中のオブジェクトがTenured領域に移動し，空になります。

Tenured領域：使用中のオブジェクトが詰め直されます。

Humongous領域：使用中のオブジェクトが詰め直されます。

Metaspace領域：使用中のオブジェクトが詰め直されます。

Free領域：回収されたリージョンによって増加します。

(e)　アプリケーションの停止の有無

停止します。

(f)　ほかのGCとの関係

CM：FullGC中は実行されません。

YoungGC：FullGC中は実行されません。

MixedGC：FullGC中は実行されません。

(g)　補足

確認方法

FullGCの確認はログ上のGCの種別が“FullGC”であることから確認できます。また，FullGCではこれから実行するGCに対して予測をしないため，予測停止時間や予測回収サイズは0で表示されます。

[VG1]<Wed Jan 15 12:51:32 2014>[Full GC 130443K/131072K(131072K)->55462K/56320K(131072K), 2.3265610 secs][Status:-][G1GC::Eden: 0K(43008K)->0K(43008K)][G1GC::Survivor: 0K->0K][G1GC::Tenured: 131072K->56320K][G1GC::Humongous: 0K->0K][G1GC::Free: 0K->74752K][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:ObjAllocFail][RegionSize: 1024K][Target: 0.2000000 secs][Predicted: 0.0000000 secs][TargetTenured: 0K][Reclaimable: 0K(0.00%)][User: 2.1700000 secs][Sys: 0.0000000 secs][IM: 277185K, 261856K, 44544K][TC: 1168][DOE: 0K, 0][CCI: 5808K, 49152K, 5952K]

2.3.2　G1GCのチューニング

G1GCのチューニング方法について説明します。システム構築時にチューニングを実施し，システム要件を満たしていることを確認してから本番環境に適用してください。

Javaヒープ領域のサイズに関係するオプションの一覧を次の表に示します。なお，表の項番1〜8は「図2-28」の番号と対応しています。

表2‒4　Javaヒープ領域内の各領域とMetaspace領域のサイズを指定するオプション

項番

オプション名

オプションの意味

1

-Xms<size>

Javaヒープの初期サイズを設定します。※1

2

-Xmx<size>

Javaヒープの最大サイズを設定します。※1

3

-XX:NewSize=<value>

New領域の最小サイズを設定します。※2

4

-XX:MaxNewSize=<value>

New領域の最大サイズを設定します。※2

5

-XX:NewRatio=<value>

Javaヒープ領域に対するNew領域の割合を設定します。※2

<value>が2の場合は，New領域とTenured領域の割合が，1:2になります。

6

-XX:SurvivorRatio=<value>

New領域に対するSurvivor領域で最大に取ることができる領域サイズの割合を設定します。

Survivor領域の最大で取ることができる領域サイズは次の式で求められます。

(Survivor領域のサイズ)※3=(New領域のサイズ)/SurvivorRatio

7

-XX:MetaspaceSize=<size>

Metaspace領域の初期サイズを設定します。※4

8

-XX:MaxMetaspaceSize=<size>

Metaspace領域の最大サイズを設定します。※4

注※1

-Xmsと-Xmxの値は同じ値を指定することを推奨します。

注※2

項番3〜5のオプションを指定した場合，New領域のリサイズが制限され，目標停止時間内にGC停止時間を抑えようとするG1GCのメリットを損なうため，G1GCでは指定しないことを推奨します。また，項番3〜5のオプションを指定しなかった場合，New領域の初期サイズはJavaヒープの初期サイズ×0.2のサイズが確保され，Eden領域の初期サイズはSurvivorRatioのデフォルト値である8に従って割り当てられます。

注※3

Survivor領域のサイズとはTo空間またはFrom空間のサイズを指します。To空間とFrom空間の合計サイズではないことに注意してください。

注※4

-XX:MetaspaceSizeと-XX:MaxMetaspaceSizeの値は同じ値を指定することを推奨します。

図2‒28　Javaヒープ領域内の各領域とMetaspace領域のサイズとオプションの対象範囲

G1GCのチューニングに利用するオプションを次の表に示します。各オプションの詳細については，「5.4　日立JavaVMで指定できるJava HotSpot VMのオプション」の各オプションの説明を参照してください。

表2‒5　G1GCのチューニングオプション

項番

オプション名

デフォルト値

オプションの意味

1

-XX:MaxGCPauseMillis=<value>

200

目標停止時間[ms]

2

-XX:ParallelGCThreads=<value>

CPU数※

（OSが認識しているCPU数）

Evacuationの処理をするスレッド数

3

-XX:ConcGCThreads=<value>

(ParallelGCThreads + 2) / 4

CM処理をするスレッド数

注※

実行環境のCPU数によって計算式が異なります。

(1)　チューニングの流れ

チューニングの全体の流れを次の図に示します。

図2‒29　チューニングの全体の流れ

次から，それぞれのチューニングの詳細を説明します。

(2)　初期検証

初期検証の流れを次の図に示します。

図2‒30　初期検証の流れ

G1GCを有効にしてシステムの検証をします。検証の結果，システム要件を満たしている場合でも，FullGCの発生傾向がないかどうかを確認します。システム要件を満たしていない場合は，「(3)　FullGCの発生を抑止するチューニング」へ進んでください。

検証中にFullGCが発生していない場合でも，システムを長期間動かすことで，将来FullGCが発生する場合があります。そのため，FullGCの発生傾向がないかどうかを確認します。

FullGCの発生傾向のイメージを次の図に示します。

図2‒31　FullGCの発生傾向のイメージ

この図は検証中のGC後の使用量をグラフにしたイメージです。この図のようにMixedGCが発生していても，Javaヒープ使用量が長期的には単調増加している場合，FullGCの発生傾向があります。

システム要件を満たしている場合でも，FullGCの発生傾向があった場合，検証時間を延ばしFullGCを発生させ，FullGCが発生してもシステム要件が満たしているかどうかを確認します。FullGCを発生させた結果，システム要件を満たさなくなった場合は，FullGCの発生を抑止するチューニングをします。また，検証時間を延ばすことができない場合は，FullGCが発生していなくても，FullGCの発生を抑止するチューニングをし，FullGCの発生傾向をなくしてください。FullGCの発生を抑止するチューニングについては，「(3)　FullGCの発生を抑止するチューニング」を参照してください。

(3)　FullGCの発生を抑止するチューニング

(a)　FullGCの発生を抑止する考え方

FullGCの発生を抑止するチューニングの流れを次の図に示します。

図2‒32　FullGCの発生を抑止するチューニングの流れ

FullGCはTenured領域の使用サイズが増加し続け，Freeリージョンが確保できなくなった場合実行されます。

FullGCの発生を抑止するチューニングのイメージを次の図に示します。

図2‒33　FullGCの発生を抑止するチューニングのイメージ

FullGCの発生を抑止するには，Tenured領域の使用サイズの増加を防ぐ必要があります。そのため，FullGCの発生を抑止するには次の2つの方法が考えられます。

Tenured領域へ移動するオブジェクト数を減らす

Tenured領域内で不要なオブジェクトを回収する

Survivor領域あふれが発生している場合は1の方法で，発生していない場合は2の方法でチューニングしてください。1の方法の詳細については，「(c)　Survivor領域のサイズチューニング」を，2の方法の詳細については，「(d)　MixedGCで選択されるリージョンを増やすチューニング」を参照してください。チューニングをした場合，再度システムの検証をし，要件を満たしているか確認してください。

(b)　サイズの大きなオブジェクトが多数作成されている場合

1つのオブジェクトのサイズが大きいオブジェクトが多数作成される場合，連続した領域が確保できないで，FullGCが実行される場合があります。G1GCではメモリをリージョンで管理しているため，オブジェクトのサイズが大きいオブジェクトが多数作成されるシステムには不向きです。オブジェクトのサイズが大きいオブジェクトが多数作成されることによって，FullGCが発生している場合は，アプリケーションの改修をしてください。

サイズの大きなオブジェクトはログの「Humongous」の項目から確認できます。

[VG1]<Wed Jan 15 12:51:32 2014>[Full GC 130443K/131072K(131072K)->55462K/56320K(131072K), 2.3265610 secs][Status:-][G1GC::Eden: 0K(43008K)->0K(43008K)][G1GC::Survivor: 0K->0K][G1GC::Tenured: 131072K->56320K][G1GC::Humongous: 1024K->0K][G1GC::Free: 0K->74752K][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:ObjAllocFail][RegionSize: 1024K][Target: 0.2000000 secs][Predicted: 0.0000000 secs][TargetTenured: 0K][Reclaimable: 0K(0.00%)][User: 2.1700000 secs][Sys: 0.0000000 secs][IM: 277185K, 261856K, 44544K][TC: 1168][DOE: 0K, 0][CCI: 5808K, 49152K, 5952K]

(c)　Survivor領域のサイズチューニング

Tenured領域へ移動するオブジェクト数を減らす方法は，Survivor領域にオブジェクトが存在する間に，オブジェクトを回収する方法です。Survivor領域の空き領域がなくなると，本来寿命の短いオブジェクトがSurvivor領域あふれによる退避でTenured領域に昇格します。そのため，Survivor領域を大きくすることで，寿命の短いオブジェクトをSurvivor領域で回収し，Tenured領域への移動量を減らします。

ログに次のように「to exhausted」が出力されている場合，Survivor領域あふれが発生しています。この場合Survivor領域を大きくするために，-Xmxオプションまたは-XX:SurvivorRatioオプションでチューニングをしてください。

[VG1]<Wed Jun 12 11:21:10 2013>[Young GC 899070K/899072K(1048576K)->501755K/501760K(1048576K), 0.0931560 secs][Status:to exhausted][G1GC::Eden: 389120K(389120K)->0K(397312K)][G1GC::Survivor: 41984K->41984K][G1GC::Tenured: 459776K->459776K][G1GC::Humongous: 2048K->2048K][G1GC::Free: 609536K->607232K][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:G1EvacuationPause][RegionSize: 1024K][Target: 0.2000000 secs][Predicted: 0.2495800 secs][TargetTenured: 0K][Reclaimable: 0K(0.00%)][User: 0.0156250 secs][Sys: 0.0312500 secs][IM: 729K, 928K, 0K][TC: 509][DOE: 16K, 171][CCI: 2301K, 49152K, 2304K]

チューニングに用いるオプション名とチューニング方法を次に示します。

-Xmxオプション

指定する値を大きくすることで，Javaヒープ領域のサイズが大きくなります。Javaヒープ領域全体のサイズが大きくなることで，Survivor領域のサイズも大きくなります。ただし，Javaヒープ領域の最大サイズを大きくすると，New領域がリサイズされる範囲の最小値と最大値が大きくなります。これによって最小停止時間が大きくなるため，チューニングをしたあとに再度システム要件を満たしているか検証してください。

-XX:SurvivorRatioオプション

指定する値を小さくすることで，予約したNew領域のうち，Survivor領域に割り当てる割合を大きくします。ただし，この方法はEden領域がチューニング前に比べて小さくなるため，YoungGCやMixedGCが発生しやすくなる副作用があります。そのため，チューニングをしたあとに再度システム要件を満たしているか検証してください。

重要

Survivor領域を大きくする方法として-XX:NewRatioや-XX:NewSize，-XX:MaxNewSizeオプションを使ってNew領域のサイズを大きくする方法もあります。しかし，この場合GC後のNew領域のリサイズが制限されるため，New領域のサイズを変更するオプションの指定は推奨しません。

(d)　MixedGCで選択されるリージョンを増やすチューニング

MixedGCで対象とするリージョンを増やすには，1度のMixedGCの対象リージョンを増やす方法と，MixedGCの発生頻度を上げて対象リージョン延べ数を増やす方法があります。1度のMixedGCの対象リージョン数を増やす方法はレスポンスが低下し，対象リージョンの延べ数を増やす方法はスループットが低下します。システム要件にあわせてチューニング方法を選択してください。

-XX:MaxGCPauseMillisオプション

指定する値を大きくすることで，目標停止時間が大きくなります。MixedGCではNew領域とTenured領域の一部を対象としてGCをします。Tenured領域はNew領域を選択しても予測停止時間に対して目標停止時間に余裕がある場合に選択されます。そこで，目標停止時間を大きくすることで，1度のMixedGCで選択されるTenuredリージョンの数が増えます。ただし，この方法はGC停止時間が長くなるため，レスポンスが低下します。

-XX:ConcGCThreadsオプション

指定する値を大きくすることで，CMをするスレッド数が増えます。MixedGCが実行されるためには，CMが終了している必要があります。そのため，CMをするスレッド数を増やし，CMの終了間隔を短くします。これによってMixedGCの発生回数が増え，MixedGCで選択されるリージョンの延べ数が増えます。ただし，この方法では，アプリケーションスレッドと並行して処理をするスレッド数が増えるため，スループットが低下します。

また，CMスレッド数はEvacuationをするスレッド数より多い値を指定できません。そのため，-XX:ConcGCThreadsオプションとあわせて，-XX:ParallelGCThreadsオプションの値も大きくする必要があります。

(4)　最悪レスポンス時間を短くするチューニング

最悪レスポンス時間を短くするチューニングの流れを次の図に示します。

図2‒34　最悪レスポンス時間を短くするチューニングの流れ

このチューニングは，GCによるアプリケーションの停止時間を短くすることで，最悪レスポンス時間を短くする方法です。そのため，レスポンス時間のうち，GCによるアプリケーションの停止時間が占める割合が大きい場合に有用です。GCによるアプリケーションの停止時間は，VG1ログのgc_timeの項目から取得できます。

VG1ログの詳細については，「-XX:[+|-]HitachiVerboseGC（拡張verbosegc情報出力オプション）」を参照してください。

最悪レスポンス時間を短くするには，GCによるアプリケーションの停止時間を短くする必要があります。G1GCでは停止時間を指定することができるため，指定する値を小さくすることで最悪レスポンス時間を短くします。

-XX:MaxGCPauseMillisオプション

指定する値を小さくすることで，目標停止時間が短くなり，最悪レスポンス時間が短くなります。ただし，この方法ではGC回数が多くなりスループットが低下します。そのため，最悪レスポンス時間を短くするチューニングをした場合，再度システム要件を満たしているか検証してください。また，G1GCではどのGCでもNew領域をGCの対象とするため，New領域の回収に掛かる時間以下にはGC時間を抑えられません。それ以上GC停止時間を短くできないGC停止時間を最小停止時間と呼びます。目標停止時間を短くしても最悪レスポンス時間が短くならない場合は，ログのGC停止時間を確認してください。

GC停止時間は次のログの太字の部分から確認できます。

[VG1]<Wed Jun 12 11:21:10 2013>[Young GC 899070K/899072K(1048576K)->501755K/501760K(1048576K), 0.0931560 secs][Status:-][G1GC::Eden: 389120K(389120K)->0K(397312K)][G1GC::Survivor: 41984K->41984K][G1GC::Tenured: 459776K->459776K][G1GC::Humongous: 2048K->2048K][G1GC::Free: 609536K->607232K][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:G1EvacuationPause][RegionSize: 1024K][Target: 0.2000000 secs][Predicted: 0.2495800 secs][TargetTenured: 0K][Reclaimable: 0K(0.00%)][User: 0.0156250 secs][Sys: 0.0312500 secs][IM: 729K, 928K, 0K][TC: 509][DOE: 16K, 171][CCI: 2301K, 49152K, 2304K]

目標時間を短くしてもGCの停止時間が短くなっていない場合は，最小停止時間に達しています。また，目標時間を最小停止時間に近づけ過ぎると，目標停止時間を超えたときの超え幅が大きくなり，最悪レスポンス時間が長くなる場合があります。目標停止時間を短くしてもシステム要件を満たせない場合は，チューニングではシステム要件を満たせません。その場合は，アプリケーションを改修してください。

(5)　スループットを向上させるチューニング

スループットを向上させるチューニングの流れを次の図に示します。

図2‒35　スループットを向上させるチューニングの流れ

スループットを向上させるためには，GCの発生回数を減らす必要があります。YoungGCやMixedGCは割り当てられたEden領域を使い切ると発生します。そこで，New領域を大きくすることでEden領域を大きくし，GCの発生回数を減らします。New領域を大きくするためには，-Xmxオプションまたは-XX:GCMaxPauseMillisオプションを用いてチューニングをします。

-Xmxオプション

指定する値を大きくすることで，Javaヒープ領域の最大サイズを大きくします。Javaヒープ領域の最大サイズが大きくなることで，New領域も大きくなります。

-XX:MaxGCPauseMillisオプション

指定する値を大きくすることで，目標停止時間が長くなります。YoungGCでは目標停止時間内に収まる範囲で，できるだけ大きくNew領域を取るため，目標停止時間を長くすることで，New領域も大きくなります。

スループットを向上させるチューニングをしてもスループットが向上しない場合は，New領域のサイズがリサイズされる範囲の最大サイズに達していることが考えられます。ログのEden領域＋Survivor領域の値の変化からリサイズがされているか確認してください。ログの確認方法の詳細については，「2.3.1(8)　YoungGC」を参照してください。なお，スループットを向上させるチューニングをするとレスポンスが低下する場合があるため，チューニング後は性能の再検証をする必要があります。

3　トラブルシューティング

この章では，発生する代表的なトラブルについて，日立JavaVMが生成した資料の確認が必要となるケースと，原因究明の手順について説明します。さらにアプリケーションサーバシステムで発生する代表的なトラブルについても説明します。

3.1　JavaVMでのトラブルシューティング

ここでは，JavaVMのトラブルの原因の切り分けに使用する資料と，代表的なトラブル事象の原因の切り分けの方法について説明します。

JavaVMを実行しているプロセスで想定されるトラブルには，次に示す種別があります。

プロセスダウン

JavaVMを実行しているプロセスが異常終了します。

プロセスハングアップ（無応答）

JavaVMを実行しているプロセスの応答が返らなくなります。

スローダウン

JavaVMを実行しているプロセスの応答は返りますが，応答時間が長くなります。

OutOfMemory（メモリ不足）

メモリ不足によって，プロセスが終了します。

トラブル種別ごとに取得する資料を，次の表に示します。

表3‒1　トラブル種別ごとの取得資料一覧

項番

資料の種類

トラブル種別

プロセスダウン

プロセスハングアップ

（無応答）

スローダウン

OutOfMemory

（メモリ不足）

1

エラーリポートファイル

○

−

−

○※

2

coreダンプ／スタックトレースファイル

○

○※

○

○※

3

JavaVMのスレッドダンプファイル

−

○

○

○

4

JavaVMログファイル

○

○

○

○

5

標準出力と標準エラー出力

○

○

○

○

（凡例）

○：取得します。

−：取得しません。

注※

発生個所によっては資料が取得できない場合があります。

資料の説明と取得方法を次の表に示します。

表3‒2　資料の説明と取得方法

項番

資料の種類

説明

取得方法の参照先

1

エラーリポートファイル

JavaVMがダウンした場合に出力されます。

3.1.1(1)

2

coreダンプ／スタックトレースファイル

プロセスのメモリイメージがダンプ出力されます。

また，ダンプからスレッドのスタック状態が出力されます。

3.1.1(2)

3

JavaVMのスレッドダンプファイル

JavaVMの稼働情報やスレッドのスタック状態が出力されます。

3.1.1(3)

4

JavaVMログファイル

JavaVMのGC活動情報を含むトラブルシュート情報がJavaVMログファイルに出力されます。

3.1.1(4)

5

標準出力と標準エラー出力

JavaVMのメッセージやエラーメッセージが出力されます。

※

注※

お客さまが使用するシステムの取得方法に従ってください。

取得した資料を使用して，トラブルの原因を判別します。資料の詳細内容については，それぞれ次の表に示す個所を参照してください。

表3‒3　調査方法の参照先

項番

資料の種類

説明

1

エラーリポートファイル

「7.4　日立JavaVMが出力するメッセージログ（標準出力およびエラーリポートファイル）」を参照してください。

2

coreダンプ／

スタックトレースファイル

※

3

JavaVMのスレッドダンプファイル

「7.1　日立JavaVMのスレッドダンプ」を参照してください。

4

JavaVMログファイル

「7.3　JavaVMログ（JavaVMログファイル）」を参照してください。

5

標準出力と標準エラー出力

※

注※

保守員が使用する資料ですが，トラブルの原因を判別できることがあります。「3.1.2　トラブル事象別の原因切り分け方法」参照してください。

3.1.1　資料の取得方法

トラブルの原因の切り分けに使用する資料の取得方法について説明します。

(1)　エラーリポートファイル

JavaVMが出力するエラーリポートファイルの取得について説明します。

JavaVMでクラッシュが発生した場合，JavaVMはデバッグ情報を標準出力とエラーリポートファイルに出力します。エラーリポートファイルが出力されるタイミングを次に示します。

JNIの中でシグナルが発生したとき

JavaVMでCヒープ不足が発生したとき

JavaVMで予期しないシグナルが発生したとき

JavaVMでInternal Error（内部論理エラー）が発生したとき

ただし，エラーリポートファイルの作成時にシグナルやメモリ不足が発生した場合，このファイルは作成されません。

エラーリポートファイルの出力先および出力ファイル名は，次のとおりです。

<カレントディレクトリ>/hs_err_pid<JavaプロセスのプロセスID>.log

メモ

Cヒープが不足した場合，次の順序でメッセージ出力およびcoreダンプの生成が実行されます。必要な情報を取得してください。

Cヒープ不足を示すメッセージログが，エラーリポートファイルおよび標準出力に出力されます。

1.の実行中にメモリ不足が発生した場合，メッセージが標準出力に出力されます。

簡易メッセージの出力処理中にさらにメモリ不足が発生した場合，メッセージおよびエラーログファイルの出力処理を中止して，coreダンプを生成します。

重要

クラッシュが発生した場合やCヒープ不足時に標準出力に出力されるJavaVMの情報は，-XX:+StandardLogToHitachiJavaLogオプションを指定しても日立JavaVMログファイルに出力されません。コンソールにだけ出力されます。

-XX:+StandardLogToHitachiJavaLogオプションについては，「-XX:[+|-]StandardLogToHitachiJavaLog（標準出力のログファイル出力オプション）」を参照してください。

(2)　coreダンプ／スタックトレースファイル

coreダンプの取得について，説明します。

プロセスがダウンした場合，OSによって出力されたcoreダンプを取得します。

coreダンプを取得したあとに，coreダンプからスタックトレースファイルを取得する場合は，javatraceコマンドを実行してください。スタックトレース情報は，JavaVMの異常終了の原因を究明するために必要な情報です。

コマンド詳細については，「javatrace（トレース情報の収集）」を参照してください。

javatraceコマンドの実行形式を次に示します。

javatrace <coreダンプのファイル名称> <coreダンプを生成した実行ファイルの名称>

JavaVMが異常終了して，「core.<プロセスID>」というファイル名称でcoreダンプが作成されているときにこのコマンドを実行すると，実行結果として，カレントディレクトリに「javatrace.log」というファイルが出力されます。スタックトレースファイルの出力先は，<coreダンプを生成した実行ファイルの名称>にパス名を指定することで，出力先を変更できます。

JavaVMが異常終了してcoreダンプが作成されたときに出力されるメッセージの例を，次に示します。実行するjavatraceコマンド文字列がメッセージ内に表示されます。文字列内のcoreは，core.<プロセスID>とします。

:
# You can get further information from javatrace.log file generated
# by using javatrace command.
# usage: javatrace core-file-name loadmodule-name [out-file-name] [-l(library-name)...]
# Please use javatrace command as follows and submit a bug report
# to Hitachi with javatrace.log file:
# [/opt/Cosminexus/jdk/bin/javatrace core /opt/Cosminexus/jdk/bin/java]

また，実行中のJavaプロセスでcoreダンプとスレッドダンプを同時に取得できます。実行中のJavaプロセスでcoreダンプとスレッドダンプを同時に取得する場合は，javacoreコマンドを実行してください。コマンド詳細については，「javacore（coreファイルとスレッドダンプの取得）」を参照してください。

javacore -p <JavaプロセスのプロセスID>

プロセスIDの取得方法は，「(3)　JavaVMのスレッドダンプファイル」の「参考」を参照してください。

上記の形式でコマンドを実行すると，次のメッセージが出力されます。

send SIGQUIT to 8662: ? (y/n)

「y」を入力すると，実行中のJavaプログラムのカレントディレクトリに，"javacore<プロセスID>.<出力日時>.core"（core ダンプ），および"javacore<プロセスID>.<出力日時>.txt"（スレッドダンプ）が出力されます。「n」を入力すると，coreダンプおよびスレッドダンプを取得しないでコマンドの実行を終了します。

coreダンプおよびスレッドダンプを取得すると，実行中のJavaプログラムには，次のメッセージが出力されます。

Now generating core file (javacore8662.030806215140.core)...
done
:
Writing Java core to javacore8662.030806215140.txt... OK

重要

次のシェルコマンドを実行して，coreダンプファイルサイズの上限値を無制限にしてください。

csh（Cシェル）の場合

limit coredumpsize　unlimit

sh（標準シェル）およびkshの場合

ulimit -c unlimited

また，これらの設定に加え，シェルコマンドを実行して，ファイルサイズの上限値を無制限にしておくことをお勧めします。

csh（Cシェル）の場合

limit filesize unlimit

sh（標準シェル）およびkshの場合

ulimit -f unlimited

(3)　JavaVMのスレッドダンプファイル

スレッドダンプファイルを取得する方法について説明します。

スレッドダンプファイルを取得するには，killコマンドを実行します。

kill -3 <JavaプロセスのプロセスID>

時間の経過に応じた各スレッドの状態遷移を確認するときには，目安として3秒おきに10回程度実行します。

スレッドダンプファイルの出力先および出力ファイル名は，次のとおりです。

<カレントディレクトリ>/javacore<プロセスID>.<出力日時>※.txt

注※

出力日時の形式はYYMMDDhhmmssです。

YY：年（西暦で下2桁），MM：月（2桁），DD：日（2桁）

hh：時間（24時間表記），mm：分（2桁），ss：秒（2桁）

スレッドダンプファイルは，出力先を変更できます。

出力先を変更する場合は，JAVACOREDIR環境変数に出力先を指定してください。JAVACOREDIR環境変数の詳細については，「5.6　日立JavaVMで使用する環境変数の詳細」を参照してください。

メモ

コマンドに指定するプロセスIDは，次の方法で取得できます。

ps -ef | grep <識別名>

スレッドダンプを取得するプロセスの識別ができるように，プロセス起動時のオプションに識別可能な任意の名称（-D“<識別名>”）を指定してください。

任意の識別名（JavaServer01）でスレッドダンプを取得する例を示します。

$ java -DJavaServer01 A-Server &
$ ps -ef | grep JavaServer01
root     24249 24165 99 14:45 pts/1    00:17:57 java -DJavaServer01 A-Server
：
$ kill -3 24249

なお，スレッドダンプには，コマンドラインが出力されています。コマンドライン中の-D“<識別名>”で，どのサーバのスレッドダンプであるかを判別できます。

Fri Jul 19 13:27:07 2019

Full thread dump Java HotSpot(TM) 64-Bit Server VM (11+28-CDK0987-20190712 mixed mode)
/opt/Cosminexus/jdk/bin/java -D[Server:server-one] -Xms64m -Xmx512m -server …

System Properties
：

(4)　JavaVMログファイル

JavaVMログファイルを取得するための設定について説明します。

JavaVMログとは，製品が標準のJavaVMに追加した拡張オプションを使用して取得できるログです。標準のJavaVMよりも，多くのトラブルシュート情報が取得できます。このファイルには，JavaVMのGCのログも出力されます。

JavaVMログファイルの出力先および出力ファイル名は，次のとおりです。カレントディレクトリに「javalogxx.log」という名称で出力されます。xxは01から始まる2桁の通番です。

<カレントディレクトリ>/javalogxx.log

JavaVMログファイルは，出力先およびファイル名を変更できます。

出力先を変更する場合は，-XX:HitachiJavaLog:＜ディレクトリおよびファイル名称＞オプションを指定してください。指定した出力先に指定したファイル名称で出力されます。

-XX:HitachiJavaLogオプションの詳細については，「5.2　日立JavaVM拡張オプションの詳細」を参照してください。

(5)　OS稼働情報

次に示すコマンドを実行してCPU利用率およびメモリ使用量を取得します。60秒間隔で取得することを推奨します。取得間隔を長くすると，情報の取得による性能劣化を少なくできますが，情報の精度が低下することがあります。

vmstat -n <実行間隔(秒)> <繰り返し回数>
top -d <実行間隔(秒)> -n <繰り返し回数>
sar -A <実行間隔(秒)> <繰り返し回数>

3.1.2　トラブル事象別の原因切り分け方法

事象別に原因の切り分け方法を説明します。

プロセスダウン

プロセスハングアップ（無応答）

プロセススローダウン

OutOfMemoryError障害

(1)　プロセスダウン

JavaVMを実行しているプロセスがダウンをしたときの原因を切り分ける方法を説明します。

ここでの説明で使用する資料について，取得方法の参照先は次のとおりです。

取得情報

参照先

エラーリポートファイル

「3.1.1(1)　エラーリポートファイル」

coreダンプ／

スタックトレースファイル

「3.1.1(2)　coreダンプ／スタックトレースファイル」

(a)　調査の流れ

プロセスがダウンをしたときに，原因を切り分けるための調査の流れを次の図に示します。

図3‒1　プロセスダウン時の調査の流れ

【調査ポイント】

ダウンした個所を特定し，該当モジュールの提供元に調査を依頼します。

【有効な資料】

エラーリポートファイル

coreダンプ／スタックトレースファイル

エラーリポートファイルを解析し，ダウンした個所を特定します。

ユーザのモジュール内と特定できた場合は，ダウン原因がないかどうかを見直します。

サードベンダ製品と特定できた場合は，製品提供元に調査を依頼します。

特定できない場合は，保守員に調査を依頼します。

coreファイルが出力されている場合は，スタックトレースの情報を取得します。

保守員に調査を依頼するときの資料です。

(b)　エラーリポートファイルの解析

エラーリポートファイルを解析します。

【解析のポイント】

ポイント1

JavaVM以外で異常終了（ダウンしたフレームの種別）

ポイント2

ダウンしたライブラリとライブラリ内の位置

ポイント3

ダウン原因の例外コード

ポイント4

ネイティブメソッドが呼び出されたJavaプログラムのファイル名と行番号

この例では，ダウンしたライブラリは/home/jdk/APS/User.soで，ダウンしたライブラリ内の位置は「0x91」です。

/home/jdk/APS/User.soの提供元に調査を依頼します。

エラーリポートファイルでの確認点

JavaVM以外の異常終了かどうか確認する場合について説明します。

【解析のポイント】のポイント1に示すフレームの種別が“C”の場合は，「JavaVM以外の異常終了」を示します。“C”ではない場合（“V”や“j”などがある）は，JavaVMのフレームです。フレームの種別を次に示します。

表3‒4　フレームの種別

フレームの種別

フレーム

C

ネイティブのCフレーム

J

Cフレーム以外のフレーム（コンパイルされたJavaのフレームも含む）

j

インタプリタで実行されるJavaのフレーム

V

JavaVMのフレーム

v

JavaVMが生成したスタブのフレーム

スタックトレースの情報の解析

JavaVMが異常終了してcoreダンプが出力された場合，異常終了した原因の究明に必要なネイティブ関数の情報（スタックトレース情報）を，javatraceコマンドで取得できます。全スレッドのスタックトレース情報が出力されます。ダウンしたライブラリの提供元が解析する資料は，ダウンしたモジュールを特定するための参考情報となることがあります。

【解析のポイント】

ポイント1

ダウンしたライブラリとダウンした関数と個所

ポイント2

ダウンした関数の呼び出し元

この例では「Java_User_UserNameCheck関数」，「get_name関数」，「Index_check関数」の順で呼び出され「Index_check関数」で異常が発生しています。

(2)　プロセスハングアップ（無応答）

JavaVMを実行しているプロセスがハングアップしたときの原因を切り分ける方法を説明します。

ここでの説明で使用する資料について，取得方法の参照先は次のとおりです。

取得情報

参照先

CPU利用率

「3.1.1(5)　OS稼働情報」

スレッドダンプ

「3.1.1(3)　JavaVMのスレッドダンプファイル」

coreダンプ

「3.1.1(2)　coreダンプ／スタックトレースファイル」

(a)　調査の流れ

プロセスがハングアップをしたときに，原因を切り分けるための調査の流れを次の図に示します。

図3‒2　プロセスハングアップ時の調査の流れ

【調査ポイント】

該当するプロセスのCPU使用率と突き合わせて，原因を推定し，スレッドダンプで特定します。

【有効な資料】

OS稼働情報

スレッドダンプ

CPU利用率の調査をします。

該当するプロセスのCPU利用率の調査をします。

100%に近い場合は，無限ループや再帰呼び出しに陥っている可能性が高いです。

0%に近い場合は，次の2点が考えられます。

プロセスから応答が返ってこない

デッドロック

この場合「プロセスから応答が返ってこない」の方が多くみられます。

スレッドダンプを取得します。

JavaVM自身がハングアップしているとスレッドダンプが取得できない場合があります。

スレッドダンプが取得できた場合は，スレッドダンプを解析しハングアップしたモジュールを特定し，モジュールの提供元に調査依頼をします。

スレッドダンプが取得できない場合は，javacoreコマンドでcoreダンプを取得して，保守員に調査依頼をします。

coreダンプ取得時，ヒープ領域が大きいプロセスでは，プロセスの動作を一時的に停滞させることがあるので注意してください。

(b)　スレッドダンプ（プロセス無応答）の解析例

ネイティブメソッドの実行応答が返ってこないため，ハングアップが発生している例を次の図に示します。

【解析のポイント】

スレッドダンプを複数回取得して時系列で観察し，それぞれのスレッドダンプでtid（スレッドID）が同じスレッドのスタックトレースを比較調査します。

ポイント1

スレッド属性がrunnableの場合，このスレッドは実行可能状態にあります。

このスレッドがCPU利用率の増加に関与しています（wait for monitor entryである場合はCPU利用率を増加させません）。

ポイント2

複数のスレッドダンプファイルで，同じtidのスレッド属性がすべてrunnableです。長時間にわたって実行中となっている可能性があります。

ポイント3

複数のスレッドダンプファイルで，同じtidのスレッドがすべて同じ場所を実行中です。

この例では，Native Method実行の応答が返ってこないためハングアップが発生している可能性が高いです。

(c)　スレッドダンプ（デッドロック）の解析例

デッドロックが発生しているスレッドダンプの例を次の図に示します。

【解析のポイント】

ポイント1

スレッド属性がrunnableの場合，このスレッドは実行可能状態にあります。

このスレッドはデッドロックとは無関係です。

ポイント2

スレッド属性がwait for monitor entryの場合，このスレッドはロックの取得待ちであることを示しています。

デッドロックを起こしているスレッドである可能性があります。

ポイント3

スレッドがロックを取得していて，かつポイント2でスレッドのロック取得待ちである場合，デッドロックを起こしているスレッドである可能性が高いです。

ポイント2，3に当てはまるスレッドに対し，ロックしているオブジェクトのアドレスを突き合わせながらデッドロックを検出します。

この例の場合，Thread-1は，＜0x00002aaaaf886648＞のロックを取得して，＜0x00002aaaaf886628＞の取得待ちを示します。一方，Thread-0は，＜0x00002aaaaf886628＞のロックを取得していて，かつ＜0x00002aaaaf886648＞の取得待ちとなっています。Thread-1とThread-0がデッドロックしていることが分かります。

(d)　スレッドダンプ（無限ループ）の解析例

無限ループが発生しているスレッドダンプの例を次の図に示します。

【解析のポイント】

スレッドダンプを複数回取得して時系列で観察し，それぞれのスレッドダンプでtid（スレッドID）が同じスレッドのスタックトレースを比較調査します。

ポイント1

スレッド属性がrunnableの場合，このスレッドは実行可能状態にあります。このスレッドがCPU利用率の増加に関与しています（wait for monitor entryである場合はCPU利用率を増加させません）。

ポイント2

複数のスレッドダンプファイルで，同じtidのスレッド属性がすべてrunnableです。長時間にわたって実行中となっている可能性があります。

ポイント3

同一メソッド内の特定の行が複数回繰り返し実行されているような場合，無限ループの可能性があります。

(e)　スレッドダンプ（無限ループ）のローカル変数情報による解析例

プログラムがローカル変数に作成したカウンタの使い方を誤ったために，無限ループが発生しているスレッドダンプの例を次の図に示します。

【解析のポイント】

スレッドダンプを複数回取得して時系列で観察し，それぞれのスレッドダンプでtid（スレッドID）が同じスレッドでループカウンタなどのループ処理に影響するローカル変数の値を確認します。

ポイント1

プログラムで，ループの動作に関与するローカル変数を確認します。

ポイント2

スレッドダンプに出力されている，該当するローカル変数の値を確認します。

この例では，ローカル変数countの値が増えてループ処理が抜けることを期待したプログラムにもかかわらず，countの値が減少しています。

(3)　プロセススローダウン

JavaVMを実行しているプロセスがスローダウンをしたときの原因を切り分ける方法を説明します。

ここでの説明で使用する資料取得方法の参照先は次のとおりです。

取得情報

参照先

JavaVMログファイル

「3.1.1(4)　JavaVMログファイル」

スレッドダンプ

「3.1.1(3)　JavaVMのスレッドダンプファイル」

coreダンプ

「3.1.1(2)　coreダンプ／スタックトレースファイル」

CPU利用率

「3.1.1(5)　OS稼働情報」

(a)　調査の流れ

プロセスがスローダウンをしたときに，原因を切り分けるための調査の流れを次の図に示します。

図3‒3　プロセススローダウン時の調査の流れ

【調査ポイント】

拡張verbosegc情報とスレッドダンプで特定します。

【有効な資料】

JavaVMログファイル（拡張verbosegc情報）

スレッドダンプ

coreダンプ

OS稼働情報

拡張verbosegc情報で，FullGCが多発していないかどうかを確認します。

拡張verbosegc情報はJavaVMログファイルに出力されます。

GCが原因の場合は，メモリリークを調査します。

メモリリークがない場合はメモリの設定変更の対処をします。

GCが原因ではない場合は，スレッドダンプを解析し，問題個所を特定します。

スレッドダンプの解析の結果，スローダウンをしている個所がネイティブメソッドの場合，さらにcoreダンプの解析をします。

coreダンプの解析の結果，スローダウンをしたモジュールを特定し，各モジュールの開発元に調査を依頼します。

サードベンダ製品を含めて問題個所を特定できない場合は，保守員に調査依頼をします。

メモリリークの調査方法は，OutOfMemory障害の時と同じ方法を用います。

スレッドダンプの調査方法は，プロセスハングアップの時と同じ方法を用います。

(4)　OutOfMemoryError障害

OutOfMemoryError障害が発生したときの原因を切り分ける方法を説明します。

資料取得方法の参照先は，次のとおりです。

取得情報

参照先

JavaVMログファイル

「3.1.1(4)　JavaVMログファイル」

メモリ使用量

「3.1.1(5)　OS稼働情報」

スレッドダンプ

「3.1.1(3)　JavaVMのスレッドダンプファイル」

coreダンプ

「3.1.1(2)　coreダンプ／スタックトレースファイル」

(a)　調査の流れ

OutOfMemoryError障害が発生したときに，原因を切り分けるための調査の流れを次の図に示します。

図3‒4　OutOfMemory障害の調査の流れ

【調査ポイント】

該当する症状に応じて切り分けたあと，メモリ量の変化を調査します。

【有効な資料】

JavaVMログファイル

OS稼働情報

症状の切り分けをします。

メモリ不足が発生すると標準出力にOutOfMemoryErrorが出現します。標準出力に出力されるメッセージに詳細が記述される場合があるため，そちらを参照し症状の切り分けをします。

メモリ使用量の変化を調査します。

症状が「Cヒープ不足」または「スレッドが生成できない」場合には，OS稼働情報を使ってメモリ使用量の変化を調査します。症状が「Javaヒープ不足」および「Metaspace不足」の場合には，JavaVMログの拡張verbosegc情報を使ってメモリ使用量の変化を調整します。

メモリ使用量の変化を観察した結果，メモリリークではない場合は，設定変更による対処をします。

設定変更による対処ができない場合は，メモリ使用量の多いモジュールを特定し，モジュールの提供元に調査依頼をします。

メモリリークの場合は，メモリリークしているモジュールを特定します。

サードベンダ製品を含めてリークが見当たらない場合は，保守員に調査依頼をします。

(b)　メッセージによる症状の切り分け

Javaヒープ，Metaspaceが確保できなかった場合

各メモリ領域が不足した場合のメッセージの例を示します。

Javaヒープが確保できなかった場合

JavaVMログファイルの詳細情報に“Java Heap”と出力されます。

Metaspaceが確保できなかった場合

JavaVMログファイルの詳細情報に“Meta Space”と出力されます。

Cヒープが確保できなかった場合

Cヒープが確保できなかった場合のメッセージの例を示します。

JavaVMのネイティブライブラリ（JNI）内でCヒープが確保できなかった場合

JavaVMログファイルの詳細情報に“C Heap”と出力されます。

ネイティブライブラリ（java.awt.font）内でC ヒープが確保できなかった場合

標準出力でjava.lang.OutOfMemoryErrorが出力されます。エラーリポートファイルとcoreダンプが出力されます。エラーリポートファイルの内容は，標準出力にも出力されます。

JavaVM自身がCヒープの確保ができなかった場合

OutOfMemoryError例外の詳細情報に“requested xxx bytes”と出力されます。

ユーザプログラム内でOutOfMemoryErrorを発生させた場合

ユーザプログラム内でOutOfMemoryErrorを発生させた場合のメッセージの例を示します。

ユーザプログラム内で明示的にOutOfMemoryErrorを発生させた場合，またはユーザのネイティブライブラリ（JNI）内でCヒープが確保できなかった場合など，JavaVMがOutOfMemoryError発生要因を特定できないとき，JavaVMログファイルの詳細情報に“Unknown”と出力されます。

(c)　各使用量の分析

Javaヒープ使用量の分析

Javaヒープ使用量を分析した例を示します。

FullGC時に，Javaヒープ使用量（DefNewとTenured）を確認するときの例です。

この例では，“Tenured”のFullGC後の値が15780K→31566K→47026K→50566Kと増えていることが確認できます。

Metaspace使用量の分析

Metaspace使用量を分析した例を示します。

FullGC時に，Metaspace使用量（Metaspaceの値）を確認するときの例です。

この例では，“Metaspace”のFullGC後の値が5599K→7372K→7886K→8286Kと増えていることが確認できます。

Cヒープ使用量の分析

JavaVMを実行しているプロセスのメモリ使用量を分析します。

OSの稼働情報からメモリ使用量の増加状況を確認します。

(d)　スレッドダンプによるローカル変数情報の解析例

プログラムがローカル変数に設定する値を誤ったために，OutOfMemoryが発生しているスレッドダンプの例を次の図に示します。

【解析のポイント】

スレッドダンプを取得して，領域を確保する処理に関与するローカル変数の値を確認します。

ポイント1

プログラムで，領域を確保する処理に関与するローカル変数を確認します。

ポイント2

スレッドダンプに出力されている，該当するローカル変数の値を確認します。

この例では，ローカル変数newcountの値である268443242（約250MB）または，それ以上の値でbyte領域を確保しています。

(e)　設定変更による対処

設定を変更することで対処できる場合は，症状とシステムの状況に応じて対処をします。

表3‒5　症状と対処

症状

システムの状況

対処

Javaヒープ不足

FullGC直前のJavaヒープ使用量がJavaヒープの最大値に到達した。

FullGC後もOld領域に空きがない。

Javaヒープの最大値（-Xmx）を大きくする。

Metaspace不足

FullGC後もMetaspaceに空きがない。

FullGCが頻発する。

Metaspaceの最大値（-XX:MaxMetaspaceSize）を大きくする。

Cヒープ不足

Cヒープ使用量が使用可能なメモリ使用量に到達した。

Cヒープ使用量がカーネルパラメタの上限値に達した。

OSのシステムメモリを大きくする。

不要なプロセスを停止する。

生成されたスレッド数が多く，スレッドスタックで使用するメモリ量（Cヒープ使用量）が上限値に達した。

OSのシステムメモリを大きくする。

スレッドスタックサイズ（-Xss）を小さくする。

3.1.3　保守員調査依頼時の提供情報

保守員に調査依頼をする場合に，保守員に提供する情報を示します。

次の内容をできる限り正確に提供してください。

トラブルの現象とトラブルが発生した時期

トラブルが発生する直前に発生した操作

また，次の情報も提供してください。

使用しているシステムの情報

OSとそのバージョン，メモリ，CPU（プロセッサ数）

使用しているJavaVMのバージョン・リビジョン（パッチ）

トラブル種別ごとの取得資料

表3‒6　トラブル種別ごとの取得資料一覧

項番

資料の種類

トラブル種別

プロセスダウン

プロセスハングアップ

（無応答）

スローダウン

OutOfMemory

（メモリ不足）

1

エラーリポートファイル

○

−

−

○※

2

coreダンプ／スタックトレースファイル

○

○※

○

○※

3

JavaVMのスレッドダンプファイル

−

○

○

○

4

JavaVMログファイル

○

○

○

○

5

標準出力と標準エラー出力

○

○

○

○

（凡例）

○：取得します。

−：取得しません。

注※

発生個所によっては資料が取得できない場合があります。

アプリケーションサーバをお使いの場合，アプリケーションサーバが出力するトラブルシューティングの資料

3.2　システムで発生する代表的なトラブル

アプリケーションサーバシステムの運用では，ログインできない，応答が返らない，通常1〜2秒で終了する処理が10秒以上掛かるなど，業務に支障をきたすような問題（トラブル）が発生することがあります。これらのトラブルを繰り返し発生させないようにするためには原因究明が必要となります。この原因究明の過程で，JavaVMが生成した資料の確認が必要となるケースがあります。ここでは，アプリケーションサーバで発生する代表的なトラブルを示し，そのトラブルに対して，JavaVMが生成した資料の確認が必要となるケースを説明します。なお，JavaVMが生成した資料とその確認方法の詳細については，「3.1　JavaVMでのトラブルシューティング」を参照してください。

アプリケーションサーバで発生する代表的なトラブルの定義を次の表に示します。

表3‒7　アプリケーションサーバで発生する代表的なトラブルの定義

項番

トラブルの種類

定義

1

OutOfMemory

（アプリケーションサーバの）プロセスのメモリが不足し，処理が継続できない現象。

2

プロセスダウン

アプリケーションサーバのプロセスが消滅してしまう現象。

3

トランザクションタイムアウト

アプリケーションサーバ上で管理されるトランザクションが開始されてから終了するまでの想定時間内に処理が終了しない現象。

4

プロセスハングアップ

アプリケーションサーバのプロセスは存在しているが，アプリケーションサーバの動作が停止しているように見える現象。

5

スローダウン

応答時間が通常より長くなっている現象。

6

リクエストタイムアウト

Webサーバが，アプリケーションサーバにリクエストを送信してから，応答を受け取るまでの想定時間内に処理が終了しない現象。

アプリケーションサーバで発生する代表的な各トラブルについて，JavaVMが生成した資料の確認が必要となるケースを，次の表に示します。資料の確認方法は，「3.1.2　トラブル事象別の原因切り分け方法」で説明しています。

表3‒8　JavaVMが生成した資料の確認が必要となるケース

項番

トラブルの種類

調査の進め方

JavaVM生成資料の確認方法参照先

1

OutOfMemory

アプリケーションサーバのサーバ稼働ログで，「java.lang.OutOfMemoryError」のメッセージを確認した場合，JavaVMが生成した資料を取得して調査を進めます。

「3.1.2(4)　OutOfMemoryError障害」

2

プロセスダウン

アプリケーションサーバのプロセスダウンが発生した場合，JavaVMが生成した資料を取得して調査を進めます。

「3.1.2(1)　プロセスダウン」

3

トランザクションタイムアウト

トランザクションタイムアウトが発生したことは，アプリケーションサーバのサーバ稼働ログのメッセージから確認できます。その上で，アプリケーションサーバのサーバ稼働ログをさらに詳細に確認して，タイムアウトの原因の可能性が高い個所を特定することで原因究明を進めていきます。この過程で，アプリケーションのサーバ稼働ログの出力不足などによって，どこの処理で時間が掛かっているのか特定できない場合は，現象を再現させた上で，JavaVMが生成した資料を取得することで問題個所を特定できる可能性があります。

「3.1.2(3)　プロセススローダウン」

4

プロセスハングアップ

アプリケーションサーバのプロセスは存在しているが，アプリケーションサーバのサーバ稼働ログでアプリケーションが動作している様子が見られない場合，JavaVMが生成した資料を取得することで問題個所を特定できる可能性があります。

「3.1.2(2)　プロセスハングアップ（無応答）」

5

スローダウン

FullGC実行時間の影響によって現象が発生している可能性があります。JavaVMが生成した資料を取得して確認します。

「3.1.2(3)　プロセススローダウン」

6

リクエストタイムアウト

トランザクションタイムアウトが発生しておらず，リクエストタイムアウトが発生する場合，パラメタ設定に問題がないか確認します。具体的には，Webサーバ側に設定するリクエストタイムアウトの設定値は，アプリケーションサーバ側に設定するトランザクションタイムアウトの設定値より十分大きな値を設定する必要があります。それでも問題が解決しない場合，インフラ設計を見直し，受け付けたリクエストがリクエストタイムアウト時間以内に処理できるように流量設計を行い，パラメタのチューニングを検討します。

−

（凡例）

−：該当なし

ここで説明した代表的な障害に当てはまらない場合，出力されたメッセージや収集したトラブルシューティングのための情報を確認して調査します。

第2編　リファレンス編

4　日立JavaVMの機能詳細

日立JavaVMを使用すると，障害時の資料やチューニングで使用する情報を取得できます。この章では，日立JavaVMが提供する機能について説明します。

4.1　日立JavaVMの機能の概要

アプリケーションサーバのプロセスは，JavaVM上で実行されます。

日立JavaVMで提供している機能を次に示します。

クラス別統計機能

インスタンス統計機能※1

STATICメンバ統計機能※1

参照関係情報出力機能※1

統計前のGC選択機能※1

Tenured領域内不要オブジェクト統計機能※1

Tenured増加要因の基点オブジェクトリスト出力機能※1

クラス別統計情報解析機能※²

Survivor領域の年齢分布情報出力機能

JITコンパイル時のCヒープ確保量の上限値設定機能

スレッド数の上限値設定機能

ファイナライズ滞留解消機能

ログファイルの非同期出力機能

圧縮オブジェクトポインタ機能

注※1

クラス別統計情報を出力するクラス別統計機能の一つです。

注※2

クラス別統計情報解析機能を使うと，拡張スレッドダンプファイルに出力されたクラス別統計情報をCSV形式で出力できます。

ヒント

クラス別統計機能のTenured領域内不要オブジェクト統計機能を実行した場合，次に示す機能は無効となります。

インスタンス統計機能

STATICメンバ統計機能

統計前のGC選択機能

日立JavaVMでは，障害発生時の要因分析やシステムの状態確認に利用できるよう，ログの出力内容が拡張されています。このログは，日立JavaVMのJavaVMログファイルに出力され，標準のJavaVMよりも，多くのトラブルシュート情報が取得できます。さらに，このログ（拡張verbosegc情報）を利用して適切なチューニングを実施することで，システムの可用性向上が図れます。日立JavaVMのJavaVMログファイルについては，「7.3　JavaVMログ（JavaVMログファイル）」を参照してください。日立JavaVMのチューニングについては，「2.　メモリチューニング」を参照してください。

次節以降で，日立JavaVMの各機能について説明します。

日立JavaVMの機能を使用する際の注意事項については，「4.16　日立JavaVMの機能使用時の注意事項」を参照してください。また，Oracle社のJDKとの非互換性については，「4.17　Oracle社のJDKと日立が提供するJDKとの非互換性」を参照してください。

4.2　クラス別統計機能

ここでは，クラス別統計機能について説明します。

クラス別統計機能を使用すると，クラスごとに，参照関係にあるクラスのインスタンスの情報を拡張スレッドダンプに出力できます。

4.2.1　クラス別統計機能の概要

各クラスのインスタンスが持つメンバの配下にあるすべてのインスタンスのサイズを，クラスごとに統計情報として拡張スレッドダンプに出力できます。この統計情報をクラス別統計情報といいます。クラス別統計情報を複数回出力すると，GCによるJavaオブジェクトの変化や，寿命が短いJavaオブジェクトの状態，クラスごとのサイズの変化，Javaオブジェクトの親子関係などを調査できます。これらの情報は，1トランザクション当たりのメモリ使用量の測定や，メモリリークの検出などに利用できます。

クラス別統計情報は，次に示す機能によって出力されます。

インスタンス統計機能

STATICメンバ統計機能

参照関係情報出力機能

統計前のGC選択機能

Tenured領域内不要オブジェクト統計機能

Tenured増加要因の基点オブジェクトリスト出力機能

各機能については，「4.2.2　クラス別統計機能を前提とする機能」を参照してください。

また，クラス別統計機能では，Javaヒープ（Eden領域，Survivor領域およびTenured領域を合わせたもの）にあるインスタンスを統計対象とします。クラス別統計情報の出力方法については，「4.2.3　クラス別統計情報の出力」を参照してください。

メモ

拡張スレッドダンプは，デフォルトで出力されるように設定されています。拡張スレッドダンプを取得するための方法については，「3.1.1(3)　JavaVMのスレッドダンプファイル」を参照してください。出力情報については，「7.1　日立JavaVMのスレッドダンプ」を参照してください。

また，クラス別統計情報は，CSV形式に出力することもできます。クラス別統計情報をCSV形式で出力する方法については，「4.9　クラス別統計情報解析機能」を参照してください。

4.2.2　クラス別統計機能を前提とする機能

クラス別統計機能を前提とする機能の種類と概要を次の表に示します。

表4‒1　クラス別統計機能を前提とする機能の種類と概要

種類

概要

参照先

インスタンス統計機能

クラスごとに，クラスのインスタンスがメンバとして持つインスタンスの合計サイズを出力します。

4.3

STATICメンバ統計機能

各クラスのstaticメンバが持つインスタンスの合計サイズを出力します。

4.4

参照関係情報出力機能

指定したクラス（インスタンス）をメンバに持つクラスの参照関係を出力します。

4.5

統計前のGC選択機能

クラス別統計情報を出力する前に，GCを実行するかどうかを選択できます。この機能は，jheapprofコマンド実行時にオプションで指定します。デフォルトの設定では，クラス別統計情報を出力する前にFullGCが実行されます。

4.6

Tenured領域内不要オブジェクト統計機能

Tenured領域内で不要となったオブジェクトを特定します。

4.7

Tenured増加要因の基点オブジェクトリスト出力機能

Tenured領域内不要オブジェクト統計機能を使って特定した，不要オブジェクトの基点となるオブジェクトの情報を出力します。

4.8

これらの機能のうち，インスタンス統計機能，STATICメンバ統計機能，参照関係情報出力機能，およびTenured増加要因の基点オブジェクトリスト出力機能は，クラス別統計機能の実行時に有効になります。

統計前のGC選択機能は，クラス別統計機能を実行する際に設定できます。クラス別統計情報の調査目的に合わせて選択してください。詳細は，「4.6.2　GCの選択の指針」を参照してください。

4.2.3　クラス別統計情報の出力

ここでは，クラス別統計情報を出力する方法について説明します。

クラス別統計情報を拡張スレッドダンプに出力するには，jheapprofコマンドを利用します。クラス別統計情報を出力したいJavaプロセスや，参照関係情報を出力したいクラスを指定して，jheapprofコマンドを実行します。

jheapprofコマンド実行時には，次の指定ができます。

クラス別統計情報を取得する前にGCを実行するかどうかの指定

次に，jheapprofコマンドの実行形式と実行例，および各指定方法について説明します。

(1)　jheapprofコマンドの実行形式と実行例

jheapprofコマンドの実行形式と実行例を次に示します。jheapprofコマンドの詳細については，「jheapprof（クラス別統計情報付き拡張スレッドダンプの出力）」を参照してください。

実行形式

jheapprof [-f|-i] [-explicit|-noexplicit] [-class <クラス名>] [-fullgc|-copygc|-nogc] [-garbage|-nogarbage] [-rootobjectinfo|-norootobjectinfo] [-rootobjectinfost <サイズ>] [-force] -p <プロセスID>

注　-explicit, -noexplicitは使用できません。

実行例

ここでは，プロセスIDが2463のJavaプロセスのクラス別統計情報を出力します。

-pオプションに，クラス別統計情報を出力したいJavaプロセスのプロセスIDを指定して，jheapprofコマンドを実行します。

% jheapprof -p 2463

jheapprofコマンドで-fオプションを省略している場合，次の確認メッセージが表示されます。

プロセスIDを確認するメッセージが次の形式で表示されます。

send SIGQUIT to 2463: ? (y/n)

yを入力します。

クラス別統計情報付き拡張スレッドダンプが出力されます。実行中のJavaプログラムでは次のメッセージが出力されます。

Writing Java core to javacore2463.030806215140.txt... OK

実行中のJavaプログラムは，カレントディレクトリにクラス別統計情報付き拡張スレッドダンプ（javacore<プロセスID>.<日時>.txt）を作成し，プログラムを継続します。

(2)　GCの実行有無を指定する場合

クラス別統計情報を出力する前に，GCを実行するかどうかを選択できます。この機能を統計前のGC選択機能といいます。クラス別統計情報を出力する前に，GCを実行するかどうかは，jheapprofコマンドに次のどれかのオプションを指定して実行します。

-fullgc

FullGCを実行してから，クラス別統計情報を出力します。

-copygc

CopyGCを実行してから，クラス別統計情報を出力します。

-nogc

GCを実行しないで，クラス別統計情報を出力します。

統計前のGC選択機能については，「4.6　統計前のGC選択機能」を参照してください。なお，Tenured領域内不要オブジェクト統計機能を実行する場合，統計前のGC選択機能は実行できません。

4.2.4　クラス別統計情報出力時の注意事項

クラス別統計情報出力時の注意事項について説明します。

起動中のJavaプロセスに対して，-copygcオプションを設定したjheapprofコマンドを実行すると，統計前にCopyGCを実行しようとします。この場合に，Tenured領域の空き容量が足りないと，CopyGCが実行できないときがあります。

CopyGCが実行できない場合，JavaVM起動オプションに-XX:+HitachiVerboseGCを指定していても，GCが発生したときの拡張verbosegc情報は出力されません。なお，クラス別統計情報を含む拡張スレッドダンプは，GC実行時と同様に出力されます。

JavaVM起動時に，-XX:+PrintGCDetailsが指定されたJavaプロセスに対して，-copygcオプションを設定したjheapprofコマンドを実行すると，統計前にCopyGCを実行します。この場合，-XX:+PrintGCDetailsの指定によって出力されるGC情報には，「Full GC」と出力されます。

4.3　インスタンス統計機能

ここでは，インスタンス統計機能について説明します。

インスタンス統計機能は，クラス別統計情報を出力する機能の一つです。クラスごとに，クラスのインスタンスの数やインスタンスの合計サイズが出力できます。

インスタンス統計機能はjheapprofコマンドを使用して出力します。jheapprofコマンドの実行形式と実行例については，「4.2.3　クラス別統計情報の出力」を参照してください。

4.3.1　インスタンス統計機能の概要

インスタンス統計機能は，アプリケーションのメモリリークの調査で使用します。

インスタンス統計機能では，classAのインスタンス→classAのメンバ変数（クラスはclassB）→classBのインスタンス→...とインスタンスの参照関係を調べ，ほかのインスタンスへの参照を持たないインスタンスのサイズをそのインスタンスをメンバに持つクラスに再帰的に加算します。つまり，インスタンス統計機能では，各クラスのインスタンスが参照しているインスタンスの合計サイズが出力されます。

メモリリークの原因を調査する場合は，次のように，メモリリークを調査したいアプリケーションの処理の前後でインスタンス統計機能を実行し，1.と3.のインスタンス数やインスタンスの合計サイズの差分を取り，その増加量を見てメモリリークの原因となっているクラスを特定します。

インスタンス統計機能を実行します。

メモリリークを調査したいアプリケーションの処理を実行します。

インスタンス統計機能を実行します。

なお，インスタンス統計機能は，各クラスのインスタンスが参照しているすべてのインスタンスのサイズを再帰的に加算するため，各クラスのインスタンスだけのサイズ（参照しているインスタンスのサイズを含まないサイズ）を調べることはできません。

統計対象ごとの出力結果について，次の図に示すインスタンス構造を例に説明します。

図4‒1　インスタンス構造の例

インスタンスa1，b1，b2，およびc1がクラス別統計情報の対象となります。

統計対象ごとのインスタンス数とインスタンスの合計サイズを次の表に示します。

表4‒2　統計対象ごとのインスタンス数とインスタンスの合計サイズ

統計対象

クラスA

クラスB

クラスC

インスタンス数

合計サイズ※

インスタンス数

合計サイズ※

インスタンス数※

合計サイズ※

Javaヒープ

1

121

2

21

1

1

注※　合計サイズは，インスタンスの合計サイズを示します。単位はバイトです。

各クラスのインスタンスの合計サイズの算出式を次に示します。

クラスAの場合：a1+b1+b2+c1

クラスBの場合：b1+b2+c1

クラスCの場合：c1

インスタンス統計機能では，基点となるオブジェクトから次の順序に従って参照されるオブジェクトの参照関係を調べます。基点となるオブジェクトは，ほかの参照関係で調べられていないオブジェクトが該当します。1.，2.は調査の優先順を示します。

Javaヒープ内のアドレスの低い順

Metaspace領域内のアドレスの低い順

参照先のオブジェクトが調査済みの場合は，分岐点まで戻って参照関係を調べます。

また，参照先のオブジェクトがほかの参照関係の基点となるオブジェクトである場合は，参照先オブジェクトとして扱います。すべての基点となるオブジェクトがなくなるまで参照関係を調べます。

インスタンス統計機能の場合，インスタンス数には各クラスのインスタンス数が出力されます。インスタンスの合計サイズには，次の内容が出力されます。

基点となるオブジェクトのサイズは，該当するクラスに加算されます。参照先のオブジェクトのサイズは，該当するクラスに加算され，さらに基点となるオブジェクト，および該当するクラスまでの参照関係にあるすべてのオブジェクトの該当するクラスにも加算されます。

4.3.2　インスタンス統計機能で出力するクラス別統計情報

インスタンス統計機能で出力するクラス別統計情報の出力形式，出力項目および出力例について説明します。

(1)　出力形式と出力項目

インスタンス統計機能で出力するクラス別統計情報の出力形式を次に示します。

出力形式

Java Heap Profile
-----------------------
________________Size__Instances__Class________________
   <total_size>       <Instance_count>   <class_name>
   <total_size>       <Instance_count>   <class_name>
...

出力項目

出力形式で示した各項目について説明します。

表4‒3　出力項目（インスタンス統計機能）

出力項目

意味

<total_size>

インスタンスの合計サイズがバイト単位で出力されます。

<Instance_count>

インスタンスの数が出力されます。

<class_name>

クラス名が出力されます。

(2)　出力例

インスタンス統計機能で出力するクラス別統計情報の出力例を，次のソースを例にして説明します。

public class instance {
  public static void main(String args[]) {
    classA cls_a = new classA();
    try {
      Thread.sleep(20000);
    } catch (Exception e) {}
  }
}
class classA {
  classB a1;
  classC a2;
  classA() {
    a1 = new classB();
    a2 = new classC();
  }
}
class classB {
  classD b1;
  String b2;
  classB() {
    b1 = new classD();
    b2 = null;
  }
}
class classC {
  String c1, c2;
  classC() {
    c1 = null;
    c2 = null;
  }
}
class classD {
  String d1, d2;
  classD() {
    d1 = null;
    d2 = null;
  }
}

このソースの場合の，インスタンス構造を次の図に示します。

図4‒2　インスタンス構造（インスタンス統計機能）

このようなインスタンス構造の場合，インスタンス統計機能では，次のように各クラスのサイズを加算します。

classAのサイズ：a1+a2+ b1+b2+ c1+c2+ d1+d2

classBのサイズ：b1+b2+ d1+d2

classCのサイズ：c1+c2

classDのサイズ：d1+d2

インスタンス統計機能の出力結果を次の図に示します。

図4‒3　出力結果（インスタンス統計機能）

4.4　STATICメンバ統計機能

ここでは，STATICメンバ統計機能について説明します。

STATICメンバ統計機能は，クラス別統計情報を出力する機能の一つです。クラスごとに，staticメンバが持つインスタンスの合計サイズが出力できます。

STATICメンバ統計機能はjheapprofコマンドを使用して出力します。jheapprofコマンドの実行形式と実行例については，「4.2.3　クラス別統計情報の出力」を参照してください。

4.4.1　STATICメンバ統計機能の概要

STATICメンバ統計機能は，インスタンス統計機能と同様に，アプリケーションのメモリリークの調査で使用します。

インスタンス統計機能と異なる点は，インスタンス統計機能が最初に取り出したインスタンスの非staticフィールドから参照しているインスタンスのサイズを再帰的に加算するのに対し，STATICメンバ統計機能は最初に取り出したインスタンスのstaticフィールド（クラスのstaticフィールド）から参照しているインスタンスのサイズを再帰的に加算するという点です。これによって，各クラスのstaticメンバが持つインスタンスの合計サイズを得ることができます。ただし，最初に取り出すインスタンス以外では，インスタンス統計機能およびSTATICメンバ統計機能共に，インスタンスの非staticメンバを基に参照関係を調べます。

インスタンス統計機能とSTATICメンバ統計機能の違いについては，「4.4.2(2)　出力例」を参照してください。

メモリリークの原因を調査する場合は，次のように，メモリリークを調査したいアプリケーションの処理の前後でSTATICメンバ統計機能を実行し，1.と3.のインスタンス数やインスタンスの合計サイズの差分を取り，その増加量を見てメモリリークの原因となっているクラスを特定します。

STATICメンバ統計機能を実行します。

メモリリークを調査したいアプリケーションの処理を実行します。

STATICメンバ統計機能を実行します。

なお，STATICメンバ統計機能は，各クラスのstaticフィールドが参照しているインスタンスのサイズを再帰的に加算するため，各クラスのインスタンスだけのサイズ（参照しているインスタンスのサイズを含まないサイズ）の合計を調べることはできません。

STATICメンバ統計機能では，基点となるオブジェクトから参照関係を調べます。基点となるオブジェクトは，JavaVMが持つすべてのクラスのSTATICメンバが参照し，ほかの参照関係で調べられていないオブジェクトが該当します。

また，参照先のオブジェクトが調査済みの場合は，分岐点まで戻って参照関係を調べます。すべての基点となるオブジェクトがなくなるまで参照関係を調べます。

STATICメンバ統計機能の場合，インスタンス数とインスタンスの合計サイズには，次の内容が出力されます。

参照関係にあるすべてのオブジェクトのサイズとオブジェクト数を基点となるオブジェクトに合計します。この値を基点となるオブジェクトが参照しているSTATICメンバを持つクラスに合計して統計値とします。

4.4.2　STATICメンバ統計機能で出力するクラス別統計情報

STATICメンバ統計機能で出力するクラス別統計情報の出力形式，出力項目および出力例について説明します。

(1)　出力形式と出力項目

STATICメンバ統計機能で出力するクラス別統計情報の出力形式を次に示します。

出力形式

Java Heap Dump Static Profile
-----------------------
________________Size__Instances__Class________________
   <total_size>       <Instance_count>   <class_name>
   <total_size>       <Instance_count>   <class_name>
...

出力項目

出力形式で示した各項目について説明します。

表4‒4　出力項目（STATICメンバ統計機能）

出力項目

意味

<total_size>

インスタンスの合計サイズがバイト単位で出力されます。

<Instance_count>

インスタンスの数が出力されます。

<class_name>

クラス名が出力されます。

(2)　出力例

STATICメンバ統計機能で出力するクラス別統計情報の出力例を，次のソースを例にして説明します。

public class static_instance {
  public static void main(String args[]) {
    classA cls_a;
    classB cls_b;
    classC cls_c;

    cls_a = new classA();
    cls_b = new classB();
    cls_c = new classC();
    cls_b.cls_c = cls_c;
    cls_a.cls_b = cls_b;

    try {
      Thread.sleep(20000);
    } catch (Exception e) {}
  }
}
class classA {
  static classB cls_b;
}
class classB {
  classC cls_c;
}
class classC {
}

STATICメンバ統計機能の出力結果を次の図に示します。

図4‒4　出力結果（STATICメンバ統計機能）

また，上記のソースの場合，インスタンス統計機能とSTATICメンバ統計機能では，参照関係に違いがあります。インスタンス統計機能とSTATICメンバ統計機能の参照関係の相違を次の図に示します。

図4‒5　インスタンス統計機能とSTATICメンバ統計機能の参照関係の相違

それぞれ機能の参照関係は次のようになっています。

インスタンス統計機能の参照関係

インスタンスAのインスタンス変数 cls_b → インスタンスBのインスタンス変数 cls_c → インスタンスC

STATICメンバ統計機能の参照関係

クラスAのクラス変数cls_b → インスタンスBのインスタンス変数cls_c → インスタンスC

4.5　参照関係情報出力機能

ここでは，参照関係情報出力機能について説明します。

参照関係情報出力機能は，指定したクラスのインスタンスの参照関係が先頭から順番に出力できます。

4.5.1　参照関係情報出力機能の概要

jheapprofコマンドの-classオプションに指定したクラスのインスタンスがどのクラスから参照されているかを，インスタンスの参照関係の先頭から順番に出力します。

指定したクラスのインスタンスが複数ある場合は，該当するすべてのインスタンスが出力されます。同じ名前のインスタンスが複数ある場合でも，インスタンス名のあとに次の情報が出力されるため，別のインスタンスかどうか識別できます。

インスタンスのアドレス

インスタンスが所属している領域名称

参照関係情報出力機能では，基点となるオブジェクトから次の順序に従って参照されるオブジェクトの参照関係を調べます。基点となるオブジェクトは，ほかの参照関係で調べられていないオブジェクトが該当します。

Javaヒープ内のアドレスの低い順

参照先のオブジェクトが-classオプションで指定したクラスの場合，参照関係情報には，基点となるオブジェクトから-classオプションで指定したクラスのオブジェクトまでの参照関係が出力されます。参照先のオブジェクトが調査済みの場合は，分岐点まで戻って参照関係を調べます。参照先のオブジェクトがほかの参照関係の基点となるオブジェクトである場合は，参照先オブジェクトとして扱います。すべての基点となるオブジェクトがなくなるまで参照関係を調べます。

また，jheapprofコマンドで-staticrootオプションを指定すると，staticフィールドを基点とした参照関係情報出力機能が有効になります。この機能は，参照関係情報出力機能を前提としています。staticフィールドを基点とした参照関係情報出力機能では，参照関係情報出力機能が出力する参照関係情報に，staticフィールドを基点とした参照関係情報を追加して出力します。この出力情報は，staticフィールドを基点とした参照関係によるメモリリークの原因を究明するために使用します。

メモリリーク状態の参照関係の例を次に示します。

図の参照関係のインスタンス「d/Cd」にstaticフィールドを基点とした参照関係情報出力機能を実行すると，次の参照関係情報が出力されます。

この情報を基に，リーク対策として，次のフィールドの参照をクリアします。このことで，「d/Cd」はGCで回収されるため，メモリリークを解消することができます。

インスタンス「c/Cc」のインスタンスフィールド「id1」

クラス「Ca」のstaticフィールド「sd1」

参照関係情報出力機能の参照関係情報については，「4.5.2　参照関係情報出力機能で出力するクラス別統計情報」を，staticフィールドを基点とした参照関係情報については，「4.5.3　staticフィールドを基点とした参照関係情報出力機能で出力するクラス別統計情報」を参照してください。

4.5.2　参照関係情報出力機能で出力するクラス別統計情報

参照関係情報出力機能で出力するクラス別統計情報の出力形式，出力項目および出力例について説明します。

(1)　出力形式と出力項目

参照関係情報出力機能で出力するクラス別統計情報の出力形式を次に示します。

出力形式

Reference of class <オプション指定クラス名>
--------------------------------------------※
<クラス名>(<アドレス>)[<領域名称>]
  <クラス名>(<アドレス>)[<領域名称>]
    <オプション指定クラス名>(<アドレス>)[<領域名称>]
------
<クラス名>(<アドレス>)[<領域名称>]
  java.lang.ref.Finalizer<<繰り返し数> times>
    <クラス名>(<アドレス>)[<領域名称>]
      <クラス名>(<アドレス>)[<領域名称>]
        <オプション指定クラス名>(<アドレス>)[<領域名称>]
------
...

注※

<オプション指定クラス名>の文字数に19を加算した数の「-（ハイフン）」が出力されます。

出力項目

出力形式で示した各項目について説明します。

表4‒5　出力項目（参照関係情報出力機能）

出力項目

意味

<クラス名>

jheapprofコマンドの-classオプションに指定したクラスのインスタンスが参照するクラスの名称が出力されます。

<アドレス>

インスタンスのアドレスが出力されます。

<領域名称>

インスタンスが所属する領域が出力されます。

Eden：Eden領域を示します。

Survivor：Survivor領域を示します。

Tenured：Tenured領域を示します。

<オプション指定クラス名>

jheapprofコマンドの-classオプションに指定したクラス名が出力されます。

java.lang.ref.Finalizer

finalize()メソッドを持つクラスで生成するjava.lang.ref.Finalizerのオブジェクトを1つにまとめて出力することを示します。

<繰り返し数>

Finalizerインスタンスの参照が連続した回数が出力されます。

(2)　出力例

参照関係情報出力機能で出力するクラス別統計情報の出力例を，次のソースを例にして説明します。

public class instance2 {
  public static void main(String args[]) {
    classA cls_a1 = new classA();    classA cls_a2 = new classA();
    classB cls_b1 = new classB();    classB cls_b2 = new classB();
    classC cls_c1 = new classC();    classC cls_c2 = new classC();
    classC cls_c3 = new classC();    classC cls_c4 = new classC();
    cls_a1.cls_a = cls_a2;    cls_a1.cls_b = cls_b1;
    cls_a1.cls_c = cls_c1;    cls_a2.cls_b = cls_b2;
    cls_b1.cls_c = cls_c2;    cls_b2.cls_c = cls_c3;
    cls_c1.cls_c = cls_c4;
    try {
      Thread.sleep(20000);
    } catch (Exception e) {}
  }
}
class classA {
  classA cls_a;
  classB cls_b;
  classC cls_c;

  classA() {
    classB cls_b;
  }
}
class classB {
  classC cls_c;
}
class classC {
  classC cls_c;
}

インスタンス構造を次の図に示します。

図4‒6　インスタンス構造（参照関係情報出力機能）

参照関係情報出力機能の出力結果を次の図に示します。この場合，jheapprofコマンドに引数「-class <クラス名>」を指定して実行します。

図4‒7　出力結果（参照関係情報出力機能）

classAのアドレスは，すべて同じアドレス（0x10766840）になっています。したがって，classAはすべて同じインスタンスであることが分かります。一方，(1)と(4)のclassBは，アドレスが異なっているので，別のインスタンスであることが分かります。

なお，GCの発生によってインスタンスのメモリ上の配置が変化します。そのため，アドレスおよび領域名称は，出力するたびに変化する場合があります。

4.5.3　staticフィールドを基点とした参照関係情報出力機能で出力するクラス別統計情報

staticフィールドを基点とした参照関係情報出力機能で出力するクラス別統計情報の出力形式，出力項目および出力例について説明します。

(1)　出力形式と出力項目

出力形式

staticフィールドを基点とした参照関係情報出力機能で出力するクラス別統計情報の出力形式を次に示します。

Reference of class <オプション指定クラス名> from static field
-------------------------------------------------------------※1
static field <staticフィールド宣言クラス名>※2.<staticフィールド名>※2
<クラス名>(<アドレス>)[<領域名称>]
  <クラス名>(<アドレス>)[<領域名称>]
    <オプション指定クラス名>(<アドレス>)[<領域名称>]
------
...

注※1

<オプション指定クラス名>の文字数に37を加算した数の「-（ハイフン）」が出力されます。

注※2

参照関係の基点を示します。

出力項目

出力形式で示した各項目について説明します。

表4‒6　出力項目（staticフィールドを基点とした参照関係情報出力機能）

出力項目

意味

<staticフィールド宣言クラス名>

基点となるstaticフィールドを宣言しているクラス名が出力されます。

<staticフィールド名>

基点となるstaticフィールドの名称が出力されます。

<クラス名>

jheapprofコマンドの-classオプションに指定したクラスのインスタンスを参照する，インスタンスのクラスの名称が出力されます。

<アドレス>

インスタンスのアドレスが出力されます。

<領域名称>

インスタンスが所属する領域が出力されます。

Eden：Eden領域を示します。

Survivor：Survivor領域を示します。

Tenured：Tenured領域を示します。

<オプション指定クラス名>

jheapprofコマンドの-classオプションに指定したクラス名が出力されます。

(2)　出力例

staticフィールドを基点とした参照関係情報出力機能で出力するクラス別統計情報の出力例を，次のソースを例にして説明します。

import JP.co.Hitachi.soft.jvm.MemoryArea.*;
public class static_reference {
  public static void main(String args[]) {
   try {
      classA cls_a1 = new classA();
      classB cls_b1 = new classB();
      classB cls_b2 = new classB();
      classC cls_c1 = new classC();
      classC cls_c2 = new classC();
      classC cls_c3 = new classC();
      BasicExplicitMemory emem = new BasicExplicitMemory();
      classC cls_c4 = (classC)emem.newInstance(classC.class);
      cls_a1.s_cls_a = cls_a1;
      cls_a1.s_cls_b = cls_b1;
      cls_a1.s_cls_c = cls_c1;
      cls_a1.cls_b = cls_b2;
      cls_b1.cls_c = cls_c2;
      cls_b2.cls_c = cls_c3;
      cls_c1.cls_c = cls_c4;
      Thread.sleep(20000);
    } catch (Exception e) {e.printStackTrace();}
  }
}
class classA {
  static classA s_cls_a;
  static classB s_cls_b;
  static classC s_cls_c;
  classB cls_b;
}
class classB {
  classC cls_c;
}
class classC {
  classC cls_c;
  public classC(){
  }
}

インスタンス構造を次の図に示します。

図4‒8　インスタンス構造（staticフィールドを基点とした参照関係情報出力機能）

staticフィールドを基点とした参照関係情報出力機能の出力結果を次の図に示します。この場合，jheapprofコマンドに引数「-class <クラス名> -staticroot」を指定して実行します。

図4‒9　出力結果（staticフィールドを基点とした参照関係情報出力機能）

4.5.4　staticフィールドを基点とした参照関係情報出力時の注意事項

jheapprofコマンドの実行時間は，staticフィールドを基点とした参照関係情報出力機能を有効にすると，staticフィールドを基点とした参照関係情報出力機能が無効な場合に比べて，参照関係情報出力機能の実行時間分長くなります。

4.6　統計前のGC選択機能

ここでは，統計前のGC選択機能について説明します。

統計前のGC選択機能を使用すると，クラス別統計情報の出力前に実行する処理を選択できます。

4.6.1　統計前のGC選択機能の概要

クラス別統計機能を実行すると，拡張スレッドダンプへクラス別統計情報が出力できます。統計前のGC選択機能では，クラス別統計情報を出力する前に実施する処理を選択できます。調査目的に合わせて，実施する処理を選択することで，Javaオブジェクトのさまざまな変化の様子をクラス別統計情報に取得できます。

統計前のGC選択機能を使用する場合，jheapprofコマンドの引数で実行する処理を指定します。クラス別統計機能実行前に実施できる処理とjheapprofコマンドの引数を次の表に示します。

表4‒7　クラス別統計機能実行前に実施できる処理とjheapprofコマンドの引数

処理の種類

処理内容

jheapprofコマンドの引数

FullGCの実行

Tenured領域も含む，JavaVM固有領域全体を対象に，使用済みのオブジェクトを回収します。

-fullgc

CopyGCの実行

Eden領域およびSurvivor領域だけを対象に，使用済みのオブジェクトを回収します。

-copygc

GCを実行しない

使用済みのオブジェクトがあっても回収しません。

-nogc

なお，JavaVM起動オプションで-XX:+HitachiVerboseGCおよび-XX:+HitachiVerboseGCPrintCauseを指定している場合にクラス別統計機能を実行すると，拡張verbosegc情報に次の情報が出力されます。

GC種別

拡張スレッドダンプにGCが発生した要因

これらの情報は，jheapprofコマンドに指定する引数によって，出力される情報が異なります。jheapprofコマンドの引数と出力情報の関係を次の表に示します。

表4‒8　jheapprofコマンドの引数と出力情報の関係

jheapprofコマンドの引数

GC種別

GCが発生した要因

-fullgc

FullGC

JHeapProf Command

-copygc

GC

JHeapProf Command

4.6.2　GCの選択の指針

統計前のGC選択機能で，どの処理を指定するかは，出力されるクラス別統計情報の調査目的によって異なります。

ここでは，調査目的に合わせて，処理を選択する指針について説明します。

統計前のGC選択機能で選択できる処理は，jheapprofコマンドの引数で指定します。処理は，どのオブジェクトを調査対象とするか，クラス別統計情報をどのような調査で使用するかによって選択します。

処理の選択の指針を次の表に示します。

表4‒9　処理の選択の指針

処理

（jheapprofコマンドの引数）

調査対象

クラス別統計情報の調査方法の例

FullGCの実行

（-fullgc）

FullGCによるオブジェクトの変化

FullGCによって，使用済みのオブジェクトが回収されるため，Javaヒープのメモリリークの原因となるオブジェクトを特定できます。

CopyGCの実行

（-copygc）

CopyGCによるオブジェクトの変化

CopyGCによって，Tenured領域へ移動する寿命の長いオブジェクトを特定できます。この情報から，FullGCの発生頻度が増大する原因となるオブジェクトを特定できます。

GCは実行しない

（-nogc）※

GCの実行で回収されてしまう短寿命オブジェクト

使用済みのオブジェクトを含むすべてのオブジェクトの情報が出力されます。CopyGCが多発している場合などに，その原因となるメモリ占有率の高いオブジェクト（超大オブジェクト）を特定できます。

注※

jheapprofコマンドの引数に-nogcを指定した場合，すべての寿命の短いオブジェクトの情報が出力されるため，ログの出力量が増加します。

4.7　Tenured領域内不要オブジェクト統計機能

ここでは，Tenured領域内不要オブジェクト統計機能について説明します。

Tenured領域内不要オブジェクト統計機能は，クラス別統計情報を出力する機能の一つです。Tenured領域内不要オブジェクト統計機能を使用すると，Tenured領域内で不要となったオブジェクトを特定できます。

Tenured領域内不要オブジェクト統計機能を使用する場合は，jheapprofコマンドの引数に-garbageを指定します。jheapprofコマンドの詳細については，「jheapprof（クラス別統計情報付き拡張スレッドダンプの出力）」を参照してください。

4.7.1　Tenured領域内不要オブジェクト統計機能の概要

Tenured領域内不要オブジェクト統計機能では，Tenured領域内に蓄積された不要となったオブジェクトだけを特定して，スレッドダンプファイルに出力します。Tenured領域内不要オブジェクト統計機能の仕組みについて説明します。

(1)　不要なオブジェクトのサイズの出力

CopyGCの繰り返しによって，長寿命オブジェクトがTenured領域に蓄積します。蓄積した長寿命オブジェクトのうち，時間が経過して用途を失ったオブジェクトは，不要なオブジェクトとなってTenured領域内に残ります。その後，メモリがいっぱいになったタイミングでFullGCが発生します。CopyGCの発生からFullGCの発生までのTenured領域の使用量は，Tenured領域内不要オブジェクト統計機能，およびインスタンス統計機能で確認できます。

Tenured領域内不要オブジェクト統計機能，およびインスタンス統計機能を使って特定できる内容を次の図に示します。

図4‒10　Tenured領域内不要オブジェクト統計機能，およびインスタンス統計機能を使って特定できる内容

統計前GCを実施しないでインスタンス統計機能を実行した場合，この図の3.のサイズが出力されます。このサイズは，この図の1.に該当するTenured領域内で不要となったオブジェクトのサイズ，およびこの図の2.に該当するTenured領域内で使用中のオブジェクトを含んだTenured領域内のメモリ使用状況になります。

一方，Tenured領域内不要オブジェクト統計機能を実行した場合は，この図の2.の使用中のオブジェクトを除いたTenured領域内のメモリ使用状況（この図の1.に該当）を出力できます。Tenured領域内不要オブジェクト統計機能を使うことで，Tenured領域の増加要因となる不要となったオブジェクトを特定できるため，FullGCを抑止できます。

(2)　不要なオブジェクトの参照関係の確認

Tenured領域内不要オブジェクト統計機能では，基点となるオブジェクトはTenured領域内のアドレスの低い順に検索されます。検索されたオブジェクトの中でも，ほかの参照関係で調べられていないオブジェクトが基点となるオブジェクトになります。

参照先のオブジェクトが調査済みの場合は，分岐点まで戻って参照関係を調べます。また，参照先のオブジェクトがほかの参照関係の基点となるオブジェクトである場合は，参照先オブジェクトとして扱います。すべての基点となるオブジェクトがなくなるまで参照関係を調べます。

Tenured領域内不要オブジェクト統計機能の場合，インスタンス数，およびインスタンスサイズの合計が出力されます。インスタンス数は該当するクラスを加算します。インスタンスの合計サイズには次の内容が出力されます。

基点となるオブジェクトのサイズは，該当するクラスに加算されます。参照先のオブジェクトのサイズは，該当するクラスに加算され，さらに基点となるオブジェクト，および該当するクラスまでの参照関係にあるすべてのオブジェクトの該当するクラスにも加算されます。

なお，Tenured領域内不要オブジェクト統計機能を実行した場合，インスタンス統計機能，STATICメンバ統計機能，および統計前のGC選択機能は無効となります。

Tenured領域内の不要オブジェクトによる参照関係の例を示します。

図4‒11　Tenured領域内の不要なオブジェクトによる参照関係の例

この図の参照関係について説明します。

インスタンス数

classA：a1が存在するため1

classB：b1，b2の2つが存在するため2

classC：c1，c2の2つが存在するため2

インスタンスサイズの合計

classA：classAのインスタンス（a1）と，その参照先のインスタンス（b1，b2，c1，c2）のサイズを合計した122

classB：classBのインスタンス（b1，b2）と，その参照先のインスタンス（c1，c2）のサイズを合計した22

classC：classCのインスタンス（c1，c2）を合計した2

Tenured領域内不要オブジェクト統計機能を実行して，「図4-11」の参照関係の情報を出力した場合の出力例を次に示します。

Garbage Profile
---------------
________________Size__Instances__Class________________
                 122          1 A
                  22          2 B
                   2          2 C

4.7.2　Tenured領域内不要オブジェクト統計機能で出力するクラス別統計情報

Tenured領域内不要オブジェクト統計機能で出力するクラス別統計情報の出力形式，出力項目および出力例について説明します。

(1)　出力形式と出力項目

Tenured領域内不要オブジェクト統計機能で出力するクラス別統計情報の出力形式を次に示します。

出力形式

Garbage Profile
-----------------------
________________Size__Instances__Class________________
            <サイズ>       <個数>          <クラス名>
            <サイズ>       <個数>          <クラス名>...

出力項目

出力形式で示した各項目について説明します。

表4‒10　出力項目（Tenured領域内不要オブジェクト統計機能）

出力項目

意味

<サイズ>

インスタンスの合計サイズがバイト単位で出力されます。

<個数>

インスタンスの数が出力されます。

<クラス名>

クラス名が出力されます。

(2)　出力例

Tenured領域内不要オブジェクト統計機能で出力するクラス別統計情報の出力例を示します。

Garbage Profile
---------------
________________Size__Instances__Class________________
            35234568      10648 java.util.HashMap
             5678900      10668 [Ljava.util.HashMap$Entry;
             4456788       7436 java.util.HashMap$Entry
             4321000        200 java.util.WeakHashMap
             1234568        190 [Ljava.util.WeakHashMap$Entry
              454400          4 java.util.WeakHashMap$Entry
                   0          0 java.lang.Class
…

4.7.3　Tenured領域内不要オブジェクト統計機能の実行に関する注意事項

Tenured領域内不要オブジェクト統計機能の注意事項を次に示します。

(1)　Tenured領域内不要オブジェクト統計機能をFullGC直後に実行した場合の注意事項

Tenured領域内不要オブジェクト統計機能をFullGC直後に実行すると，統計対象のTenured領域内の不要なオブジェクトが回収されている状態で統計処理を実行します。そのため，クラス別統計情報中のインスタンスサイズの合計，およびインスタンス数が小さくなり，不要なオブジェクトが効果的に特定されません。不要なオブジェクトを効果的に特定するためには，次の説明に沿ってTenured領域内不要オブジェクト統計機能を実行してください。なお，Tenured領域内不要オブジェクト統計機能の実行について，FullGCの発生のタイミングが判明している場合と，判明していない場合に分けて説明します。

(a)　FullGCが発生するタイミングが判明している場合

Tenured領域内不要オブジェクト統計機能をFullGCの直前に実行すると，統計対象であるTenured領域内の不要オブジェクトの数が多い状態で統計処理が実行されます。そのため，クラス別統計情報中のインスタンスサイズの合計，およびインスタンス数が大きくなり，不要なオブジェクトを効果的に特定できます。

(b)　FullGCが発生するタイミングが判明していない場合

クラス別統計情報中のインスタンスサイズの合計，およびインスタンス数をできるだけ大きくし，不要なオブジェクトを効果的に特定する方法を示します。

FullGCの発生のタイミングを知るためにJavaVM起動時に拡張verbosegc情報を出力するオプション-XX:+HitachiVerboseGCを設定します。オプションを指定することでGCの情報を取得できます。

JavaVMに対してTenured領域内不要オブジェクト統計機能を一定の間隔で実行します。それによって，GCの情報と，複数のクラス別統計情報を取得できます。

拡張verbosegc情報からFullGCの日時を取得できるため，FullGCにより近いクラス別統計情報を選択します。FullGCに近いクラス別統計情報は，統計対象であるTenured領域内の不要なオブジェクトの数が多い状態で統計処理された情報です。

(2)　統計結果に関する注意事項

次の図のような参照関係の場合を例に統計結果に関する注意事項を説明します。

図4‒12　参照関係の例（統計結果に関する注意事項）

この図で，a1が最も下位のアドレスとした場合，a1を基点となるオブジェクトとして，a1→b1→c1という参照関係で統計処理を実行します。このとき，b1またはc1を基点となるオブジェクトとしている場合，Tenured領域内不要オブジェクト統計機能，およびTenured増加要因の基点オブジェクトリスト機能の統計結果には，意図したとおりの結果が出力できません。

(3)　統計対象とならないオブジェクトに関する注意事項

次の図のようにTenured領域のオブジェクト（a1およびc1）が，Tenured領域以外のオブジェクト（b1）と参照関係がある場合を例に，統計対象とならないオブジェクトに関する注意事項を説明します。

図4‒13　参照関係の例（統計対象とならないオブジェクト）

この図の場合，Tenured領域以外のオブジェクト（b1）は統計対象とはなりません。しかし，クラスBのインスタンスサイズの合計には，参照先のTenured領域のオブジェクト（c1）のサイズが加算されます。

(4)　複数のオブジェクトから参照関係がある場合の注意事項

次の図のように複数の参照元（c1およびd1）から1つのオブジェクト（b1）を参照している参照関係がある場合を例に，複数のオブジェクトから参照関係がある場合の注意事項を説明します。

図4‒14　参照関係の例（複数のオブジェクトから参照関係がある場合）

この図の場合，Tenured領域内不要オブジェクト統計機能を実行すると，その参照元が属している参照関係の基点となるオブジェクト（c1およびa1）のうち，アドレスが最も低位である基点となるオブジェクトから統計処理が実行されます。そのため，アドレスが最も低位のオブジェクトがa1で，基点となるオブジェクトがc1である場合，Tenured領域内不要オブジェクト統計機能，およびTenured増加要因の基点オブジェクトリスト機能の統計結果には，意図したとおりの結果が出力できません。

(5)　統計値の増加に関する注意事項

オプション-XX:+HitachiAutoExplicitMemoryを指定したJavaプロセスに対して，Tenured領域内不要オブジェクト統計機能，およびTenured増加要因の基点オブジェクトリスト出力機能を実行すると，次に示すような現象が発生する場合があります。

Tenured領域内不要オブジェクト統計機能で出力されるクラス別統計情報のうち，float型の配列型（クラス名に[Fと出力される情報）のインスタンスサイズの合計，およびインスタンス数の統計値が，本来の統計値よりも大きくなります。クラス別統計情報の出力例を次に示します。

Garbage Profile
---------------
________________Size__Instances__Class________________
            43861400     473859 [F
                   0          0 java.util.Collections$EmptyMap
                   0          0 sun.security.util.Debug
                   0          0 java.nio.ByteOrder

Tenured増加要因の基点オブジェクトリスト出力機能で出力されるTenured増加要因の基点オブジェクトリストに，float型の配列型（クラス名に[Fと出力される情報）が出力されることでインスタンスサイズの合計の統計値が，本来の統計値よりも大きくなります。Tenured増加要因の基点オブジェクトリストの出力例を次に示します。

Garbage Profile Root Object Information
---------------------------------------
*, [F # 43861400

4.8　Tenured増加要因の基点オブジェクトリスト出力機能

ここでは，Tenured増加要因の基点オブジェクトリスト出力機能について説明します。

Tenured増加要因の基点オブジェクトリスト出力機能は，クラス別統計情報を出力する機能の一つです。Tenured増加要因の基点オブジェクトリスト出力機能は，Tenured領域内不要オブジェクト統計機能を使って特定した，不要なオブジェクトの基点となるオブジェクトの情報を出力できます。

Tenured増加要因の基点オブジェクトリスト出力機能を使用する場合は，jheapprofコマンドの引数に-rootobjectinfoを指定します。jheapprofコマンドの詳細については，「jheapprof（クラス別統計情報付き拡張スレッドダンプの出力）」を参照してください。

4.8.1　Tenured増加要因の基点オブジェクトリスト出力機能の概要

Tenured増加要因の基点オブジェクトリスト出力機能では，Tenured領域内不要オブジェクト統計機能を使って特定した，不要なオブジェクトの基点となるオブジェクトの情報をリストにしてスレッドダンプファイルに出力します。

また，Tenured増加要因の基点オブジェクトリスト出力機能は，Tenured領域内不要オブジェクト統計機能が前提になります。

Tenured増加要因の基点オブジェクトリスト出力機能の仕組みについて説明します。

(1)　基点となるオブジェクトのリスト出力

Tenured増加要因の基点オブジェクトリスト出力機能は，Tenured領域内不要オブジェクト統計機能の処理のあとに続けて実行されます。Tenured領域内不要オブジェクト統計機能で実行する処理については，「4.7.1　Tenured領域内不要オブジェクト統計機能の概要」を参照してください。

Tenured増加要因の基点オブジェクトリスト出力機能は，Tenured領域内のアドレスの低い順にオブジェクトを検索します。検索したオブジェクトの中で，すでに参照関係で調べられているオブジェクト，および不要なオブジェクトのクラス情報を取得して，出力候補リストに保存します。

出力候補リストに保存した情報をインスタンスサイズの合計でソートし，合計サイズがjheapprofコマンドの-rootobjectinfostオプションで指定した値以上のクラス情報だけが出力されます。

(2)　不要なオブジェクトの参照関係の確認

Tenured増加要因の基点オブジェクトリスト出力機能を実行して基点となるオブジェクトを取得する際の，Tenured領域内の不要オブジェクトによる参照関係の例を示します。

インスタンス数

classA：a1が存在するため1

classB：b1，b2の2つが存在するため2

classC：c1，c2の2つが存在するため2

インスタンスサイズの合計

classA：classAのインスタンス（a1）と，その参照先のインスタンス（b1，b2，c1，c2）のサイズを合計した122

classB：classBのインスタンス（b1，b2）と，その参照先のインスタンス（c1，c2）のサイズを合計した22

classC：classCのインスタンス（c1，c2）を合計した2

図4‒15　Tenured領域内の不要なオブジェクトによる参照関係の例

Tenured領域内不要オブジェクト統計機能を実行してこの図のような参照関係の情報を取得した場合に，Tenured増加要因の基点オブジェクトリスト出力機能で取得する情報を次に示します。

基点オブジェクト：a1

基点オブジェクトのクラス：A

基点オブジェクトのクラスAのインスタンスサイズの合計：122

「図4-15」の参照関係の情報をTenured増加要因の基点オブジェクトリスト出力機能を実行して出力した場合の出力例を次に示します。

Garbage Profile Root Object Information
---------------------------------------
*, A # 122

4.8.2　Tenured増加要因の基点オブジェクトリスト出力機能で出力するクラス別統計情報

Tenured増加要因の基点オブジェクトリスト出力機能で出力するクラス別統計情報の出力形式，および出力項目について説明します。

出力形式

Garbage Profile Root Object Information
---------------------------------------
*, <クラス名> # <サイズ>
…

出力項目

出力形式で示した各項目について説明します。

表4‒11　出力項目（Tenured領域内不要オブジェクト統計機能）

出力項目

意味

<クラス名>

Tenured増加要因となった基点となるオブジェクトのクラス名が出力されます。

<サイズ>

Tenured領域内不要オブジェクト統計機能のクラス別統計情報から取得したインスタンスサイズの合計がバイト単位で出力されます。

4.9　クラス別統計情報解析機能

ここでは，クラス別統計情報解析機能について説明します。

クラス別統計情報解析機能を使用すると，クラス別統計情報で取得した情報をCSV形式で出力できます。

4.9.1　クラス別統計情報解析機能の概要

jheapprofanalyzerコマンド（クラス別統計情報解析機能）を実行することで，クラス別統計情報の付いた複数の拡張スレッドダンプファイルを入力ファイルとして，クラスごとのインスタンスの合計サイズ，およびクラスごとのインスタンス数を時系列に出力します。出力されるファイルは，CSV形式で出力されます。

クラス別統計情報として取得した情報を基に，クラス別統計情報解析機能を実行してCSV形式に出力する場合の流れを次に示します。

図4‒16　クラス別統計情報解析機能を実行してCSV形式に出力する場合の流れ

クラス別統計情報解析機能では，インスタンスの合計サイズが大きいインスタンスの情報を出力して，そのインスタンスのメモリ使用量だけを確認することもできます。インスタンスの合計サイズが大きいものだけを出力する場合には-DJP.co.Hitachi.soft.jvm.tools.jheapprofanalyzer.thresholdにしきい値を指定し，jheapprofanalyzerコマンドに指定して実行します。jheapprofanalyzerコマンドの詳細については，「jheapprofanalyzer（クラス別統計情報解析ファイルのCSV出力）」を参照してください。

4.9.2　クラス別統計情報解析機能の出力例

クラス別統計情報解析機能の入力ファイル，出力ファイル，および出力形式について説明します。

(1)　入力ファイル

クラス別統計情報解析機能で使用する入力ファイルは，クラス別統計情報を出力した拡張スレッドダンプファイルです。

(2)　出力ファイル

クラス別統計情報解析機能で出力するファイルは，クラスごとのインスタンスの合計サイズを出力したファイル，およびクラスごとのインスタンス数を出力したファイルの2種類です。出力ファイルはカレントディレクトリに次のファイル名で作成されます。

表4‒12　出力ファイルのファイル名

出力ファイルの種類

出力ファイルのファイル名の例

インスタンス合計サイズファイル

JheapprofAnalyzer_size_nnn.csv

インスタンス数ファイル

JheapprofAnalyzer_num_nnn.csv

（凡例）

nnn：ファイルの分割番号が出力されます。分割番号の範囲は001〜999です。

列が201列を超える場合は出力ファイルが分割されます。また，999ファイルを超えた場合は，001に戻りファイルは書き換えられます。

分割する列数は，201列（クラス名1列＋値200列）を超えた場合とし，出力形式は分割したファイルも同じになります。

(3)　出力形式

クラス別統計情報解析機能で出力されるファイルの出力形式を次の図に示します。なお，インスタンス合計サイズ，およびインスタンス数が出力されたCSVファイルの出力形式は同じです。

図4‒17　クラス別統計情報解析機能で出力されるファイルの出力形式

クラス名と値，および値と値の間はコンマで区切ります。また，行の最後は値（空白も含む）で終了します。

クラス名の出力順はランダムです。値は入力ファイルの先頭行にある日付を基に，日付の古いものから横に並びます。同じ日付の入力ファイルがある場合はランダムに連続して横に並びます。

メモ

クラス別統計情報解析機能を複数回実行すると，処理途中のクラスが消滅したり追加されたりする場合があります。また，該当するクラスがない場合の値には0が出力されます。次の図のクラス情報の例を使用して説明します。

図4‒18　クラス情報の例

上記のようなクラス情報の場合で，-DJP.co.Hitachi.soft.jvm.tools.jheapprofanalyzer.thresholdのしきい値を0にしたときの出力結果は次の図のようになります。

図4‒19　クラス別統計情報解析機能の出力例

インスタンス合計サイズの最大値は0〜2⁶³-1，インスタンス数の最大値は0〜2³¹-1です。1つの入力ファイルに同じクラス名がある場合は，インスタンスサイズの合計が加算されます。また，インスタンス数も加算されます。加算されたことによって，それぞれの最大値を超えた場合は，指定した最大値が出力されます。なお，1つのクラスについて，すべての入力ファイルで該当するクラスの情報がない，またはしきい値未満の場合は，そのクラスの情報は出力されません。

4.9.3　クラス別統計情報解析機能の注意事項

クラス別統計情報解析機能を使用する場合，jheapprofanalyzerコマンド実行中に入力ファイルの更新，および削除の操作はしないでください。クラス別統計情報解析機能は，日付を取得するとき，およびデータを読み込むときの2回ファイルを開きます。そのため，コマンド実行中に入力ファイルの更新，および削除の操作をした場合の結果は保証されません。

4.10　Survivor領域の年齢分布情報出力機能

ここでは，Survivor領域の年齢分布情報出力機能について説明します。

Survivor領域の年齢分布情報出力機能を使用すると，CopyGC実行時に，Survivor領域の使用状況が調査できます。この情報は，メモリサイズのチューニングに使用できます。

4.10.1　Survivor領域の年齢分布情報出力機能の概要

日立JavaVMでは，多くのトラブルシュート情報が取得できるように，ログの出力内容が標準のJavaVMよりも拡張されています。このJavaVMログは，日立JavaVMのJavaVMログファイルに出力されます。Survivor領域の年齢分布情報出力機能は，CopyGC実行時，日立JavaVMのJavaVMログファイルに，Survivor領域のJavaオブジェクトの年齢分布情報を出力できる機能です。この情報を使用すると，Survivor領域のオブジェクトの使用状況が調査でき，Survivor領域のメモリサイズのチューニングができます。Survivor領域のメモリサイズのチューニングについては，「2.2.4(1)　Javaヒープ内のSurvivor領域のメモリサイズの見積もり」を参照してください。

Survivor領域の年齢分布情報出力機能は，Survivor領域の年齢分布情報に加えて日時も出力できます。また，出力先がJavaVMログファイルなので，ほかのログとの同期が取れます。

日立JavaVMのJavaVMログファイルについては，「7.3　JavaVMログ（JavaVMログファイル）」を参照してください。また，日立JavaVMのチューニングについては，「2.　メモリチューニング」を参照してください。

4.10.2　Survivor領域の年齢分布情報の出力形式と出力例

Survivor領域の年齢分布情報は，CopyGC発生時に，CopyGCのログのあとに続けて出力されます。Survivor領域の年齢分布情報の出力形式と出力例を次に示します。

出力形式

[PTD]<date>[Desired survivor:size bytes][New threshold:value][MaxTenuringThreshold: max_value][age1:total_age1][age2:total_age2]...[agen:total_agen]

説明

PTD：Survivor領域の年齢情報であることを示す識別子

date：GCが発生した日時（-XX:+HitachiVerboseGCPrintDate（拡張verbosegc情報日付出力オプション）を指定した場合だけ出力）※1

size：Survivor領域のサイズ（単位：バイト）

value：次回のGC発生時にTenured領域へ移動するオブジェクトの年齢のしきい値

max_value：-XX:MaxTenuringThresholdの指定値※2

total_age1：1歳のオブジェクトが使用しているメモリサイズの合計（単位：バイト）

total_age2：1歳から2歳までのオブジェクトが使用しているメモリサイズの合計（単位：バイト）

total_agen：1歳からn歳までのオブジェクトが使用しているメモリサイズの合計（単位：バイト）※3

注

-XX:+HitachiCommaVerboseGCを指定している場合は，次の形式で出力されます。

PTD,date,size,value,max_value,total_age1,total_age2,...,total_agen

注※1

対応するCopyGCのログと同じ時刻が表示されます。

注※2

-XX:MaxTenuringThresholdの指定値には，CopyGC実行時に，From空間とTo空間でJavaオブジェクトを入れ替える回数のしきい値を設定します。

注※3

存在するオブジェクトを最小年齢から最大年齢まで順番に表示します。表示されるオブジェクトの最大年齢がmax_valueの値に近いと，寿命の長いオブジェクトが存在することを示します。

出力例

[VGC]<Wed May 28 11:45:23 2008>[GC 648K->136K(1984K), 0.0013020 secs][DefNew::Eden: 512K->0K(512K)][DefNew::Survivor: 0K->0K(64K)][Tenured: 136K->136K(1408K)][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:ObjAllocFail][User: 0.0000000 secs][Sys: 0.0000000 secs]
[PTD]<Wed May 28 11:45:23 2008>[Desired survivor:5467547 bytes][New  threshold:30][MaxTenuringThreshold:31][age1:1357527][age2:1539661]

この出力例では，次の内容が確認できます。

出力契機は，2008年5月28日(水)11時45分23秒に発生したCopyGCです。

Survivor領域のメモリサイズは5,467,547バイトです。Survivor領域のオブジェクトは2歳までです。1歳のオブジェクトが使用しているメモリサイズは1,357,527バイト，1歳から2歳までのオブジェクトが使用しているメモリサイズは1,539,661バイトです。

4.10.3　実行環境での設定

Survivor領域の年齢分布情報出力機能を使用する場合，次の設定が必要です。

指定するオプションを次に示します。

-XX:+HitachiVerboseGCPrintTenuringDistribution

Survivor領域の年齢分布情報を日立JavaVMのJavaVMログファイルへ出力します。デフォルト値は，マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

4.10.4　Survivor領域の年齢分布情報出力機能使用時の注意事項

Survivor領域の年齢分布情報出力機能を使用すると，CopyGC実行時のログが使用しない場合に比べて倍以上に増えます。この機能は，Survivor領域のチューニング時だけに使用することをお勧めします。

4.11　JITコンパイル時のCヒープ確保量の上限値設定機能

JavaVMがサポートしているJust In Time方式でのコンパイル（JITコンパイル）では，コンパイル実行中にCヒープを使用します。処理数が多いメソッドや大量のメソッドに対してJITコンパイルを実行した場合，コンパイル処理のために確保されるCヒープのサイズも多大になり，Cヒープ不足が発生することがあります。この場合，JavaVMの強制終了やアプリケーションサーバの異常終了などのトラブルが発生して，システムが全面停止してしまうおそれがあります。

このような問題の発生を防止するために，JITコンパイルで使用するCヒープのサイズに上限値を設定できます。上限値を超えた場合は，JITコンパイルが中止され，以降のコンパイルはインタプリタ方式で実行されます。これによって，JavaVMの強制終了を防ぎ，システムの停止を抑止できます。

JITコンパイル時のCヒープ確保量の上限は，-XX:HitachiJITCompileMaxMemorySizeオプションで指定します。-XX:HitachiJITCompileMaxMemorySizeオプションの詳細は，「-XX:HitachiJITCompileMaxMemorySize（JITコンパイル時の確保メモリ上限値指定オプション）」を参照してください。

4.12　スレッド数の上限値設定機能

アプリケーションで使用するスレッド数が多くなると，Cヒープで使用するメモリ使用量が増加します。メモリ使用量の増加に伴いCヒープ不足が発生した場合，JavaVMの強制終了，アプリケーションサーバの異常終了などのトラブルが発生して，システムが全面停止してしまうおそれがあります。

このような問題の発生を防止するために，使用できるスレッド数に上限値を設定できます。あらかじめ使用するスレッド数の上限を把握し，その数を基にCヒープに割り当てるメモリサイズを決定することで，Cヒープ不足の発生を防止します。なお，設定した上限値を超えたスレッドが生成された場合は，例外がスローされます。アプリケーションでこの例外をキャッチして，適切な対処をすることで，システムの停止を抑止できます。

スレッド数の上限は，-XX:HitachiThreadLimitオプションで指定します。-XX:HitachiThreadLimitオプションの詳細は，「-XX:HitachiThreadLimit（スレッド数の上限値指定オプション）」を参照してください。

4.13　ファイナライズ滞留解消機能

ここでは，ファイナライズ滞留解消機能について説明します。ファイナライズ滞留解消機能を使用すると，ファイナライズ処理の滞留を解消でき，OS資源の解放遅れなどの発生を抑止できます。

4.13.1　ファイナライズ滞留解消機能の概要

finalize()メソッドでOS資源の解放処理を定義しているアプリケーションでは，ファイナライズ処理が滞留して，OS資源の解放遅れが発生することがあります。ファイナライズ滞留解消機能を使用すると，JavaVM内でファイナライズ処理が滞留している状態を検知して，滞留しているファイナライズ処理を解消します。

ファイナライズ滞留解消機能では，ファイナライズ滞留を検知するために，Java起動時にFinalizerThreadを監視するファイナライズ処理監視スレッドを生成します。FinalizerThreadは，Java実行時に常に1つあり，オブジェクトのfinalize()メソッドを1つずつ処理するスレッドです。

ファイナライズ処理監視スレッドでは，FinalizerThreadで処理しているオブジェクトを定期的に監視します。次の条件を満たす場合，ファイナライズ処理が滞留していると見なして，新たにファイナライズスレッドを生成します。

FinalizerThreadでオブジェクトのファイナライズ処理が進んでいない。

ファイナライズキューにオブジェクトがある。

FinalizerThreadとファイナライズスレッドの両方で，ファイナライズ処理を実行して，滞留しているファイナライズ処理の解消を促します。なお，ファイナライズスレッドは，ファイナライズキューが空になると終了します。

4.13.2　ファイナライズ滞留解消機能の出力情報

ファイナライズ滞留解消機能では，次に示すタイミングでメッセージを標準出力に出力します。

ファイナライズ処理の滞留を検知して，ファイナライズスレッドを新たに生成する場合

生成したファイナライズスレッドが終了した場合

それぞれのタイミングで出力するメッセージの形式と出力例を次に示します。

ファイナライズ処理の滞留を検知して，ファイナライズスレッドを新たに生成する場合

ファイナライズ処理の滞留を検知して，ファイナライズスレッドを新たに生成する場合に出力されるメッセージの形式を次に示します。

# FinalizerWatcherThread: Create: create secondary finalizer thread. [queue length = queue] <date>

説明

queue：ファイナライズキューの要素数

date：ファイナライズスレッドを新たに生成した日時

出力例を次に示します。

# FinalizerWatcherThread: Create: create secondary finalizer thread. [queue length = 128] <Mon May 26 18:00:36 JST 2008>

生成したファイナライズスレッドが終了した場合

生成したファイナライズスレッドが終了した場合に出力されるメッセージの形式を次に示します。

# FinalizerWatcherThread: Finish: secondary finalizer thread is finished. <date>

説明

date：生成したファイナライズスレッドが終了した日時

出力例を次に示します。

# FinalizerWatcherThread: Finish: secondary finalizer thread is finished.  <Mon May 26 20:12:26 JST 2008>

4.13.3　ファイナライズ滞留解消機能の実行環境での設定

ファイナライズ滞留解消機能を使用する場合，次の設定が必要です。

JavaVMのプロパティに指定するオプションを次に示します。

-DJP.co.Hitachi.soft.jvm.autofinalizer=true

ファイナライズ滞留解消機能を有効にします。この機能を有効にすると，Java起動時に監視スレッドを生成します。デフォルト値はtrueのため，無効にする場合はfalseを指定してください。

プロパティのオプションの詳細は，「5.3　日立JavaVMで使用するプロパティ」を参照してください。

4.13.4　ファイナライズ滞留解消機能の注意事項

ファイナライズ滞留解消機能を使用する場合の注意事項を次に示します。

JavaVMのプロパティの値は，Java起動時に参照されます。このため，JavaVM実行中にjava.lang.System.setProperty()メソッドなどで，JavaVMのプロパティの値を変更しても，ファイナライズ滞留解消機能は有効になりません。

JavaVMのプロパティに同一のオプションが複数指定された場合，最後に指定されたオプションの値が有効になります。

ファイナライズ滞留解消機能では，ファイナライズの滞留を監視するための常駐スレッドを1つ生成します。また，ファイナライズの滞留を検知すると，滞留を解消するためのスレッドを1つ生成します。ファイナライズの滞留が発生してもシステムに影響しない場合は，「-DJP.co.Hitachi.soft.jvm.autofinalizer=false」を指定して，ファイナライズ滞留解消機能を無効にすることで，ファイナライズの滞留を監視するスレッドとファイナライズの滞留を解消するスレッドの生成を抑止できます。

4.14　ログファイルの非同期出力機能

ここではログファイルの非同期出力機能について説明します。

4.14.1　ログファイルの非同期出力機能の概要

この機能は，ログのファイル出力を非同期でできるように変更する機能です。ここに記載している「非同期」とは，ログのファイル出力処理を専用でするスレッドを用意することで，ログのファイル出力以外の処理を実行するスレッドとは処理のタイミングを合わせることなく，ログをファイルに出力していくことを指します。ここでは，例として，GC発生時に出力されるログファイルについて説明します。

GCの実行中は，プログラムの処理が停止します。日立JavaVMログファイル機能では，GCを実行しているスレッドが，GCの情報のログファイル出力処理もしているため，GCの情報をログファイルに出力する処理が完了するまで次の処理へ進むことができません。

そこで，この機能を有効にすることによって，GC情報のログファイル出力処理は専用のスレッドが実行するようになります。そのため，それ以外の処理を実行するスレッドがGC情報のログファイル出力処理の完了を待つことによる処理の遅延を削減することができます。

しかし，この機能を使用することでログの一部が欠けるおそれがあります。この機能は，一時的にログをバッファにためておき，その後ログファイルへ出力するという処理をしています。ログの出力量が非常に多い場合や，ファイル入出力処理が極端に遅い場合に，一部のログが出力されないおそれがあります。そのため，GCによるプログラムの処理の停止時間として100msec以下を達成するようなチューニングをしている場合は，この機能の使用を推奨します。一方で，100msec以下を達成するようなチューニングをしていない場合には，この機能の使用は推奨しません。

4.14.2　ログファイルの非同期出力機能の対象ログファイル

この機能の対象とするファイルを次に示します。

日立JavaVMのJavaVMログファイル

4.14.3　ログファイルの非同期出力機能のエラーケース

ファイルへのI/O処理速度より，バッファへの書き込み処理速度が速い場合，バッファがラウンドしてログが出力されない場合があります。

バッファがラウンドしてログが出力されなかった場合の出力様式

[ASY]<skip_count> log is skipped.

skip_count：バッファがラウンドして出力できなかった場合のスキップした行数

この機能で使用するログに出力する専用のスレッドの生成に失敗した場合は，次のメッセージを標準出力に出力し，JavaVMを起動しません。

JavaVMログファイル用のスレッドの生成に失敗

Error occurred during initialization of VM
Could not create thread for VM: Asynchronous javalog thread creation failed. thread_count threads exist.

thread_count: 存在するスレッド数

4.14.4　ログファイルの非同期出力機能の注意事項

ログファイルの非同期出力機能の使用時，-XX:HitachiOutOfMemoryStackTraceLineSizeまたは-XX:HitachiJavaClassLibTraceLineSizeオプションに4096より大きな値を指定した場合は，オプションの値として4096が指定されたものとして動作します。その場合の動作の詳細については，「5.2　日立JavaVM拡張オプションの詳細」を参照してください。

4.14.5　ログファイルの非同期出力機能のメモリ所要量

ログファイルの非同期出力機能は，新たにバッファとスレッドを生成します。この機能が有効の場合，新たに生成されたバッファとスレッドはJavaVM終了時まで生存します。したがって，ログファイルの非同期出力機能を使用することでバッファとスレッド用にメモリを消費します。メモリ消費量を次に説明します。

まず，バッファのメモリ消費量を次に示します。

（ログ1行分のサイズ = 4096バイト）×（バッファにためこめる行数 = 1024行）= 4メガバイト

また，スレッドのメモリ消費量は-Xssオプションに指定された値です。

表4‒13　プラットフォームごとの-Xssのデフォルト値

プラットフォーム

-Xssのデフォルト値

Linux

1メガバイト

4.15　圧縮オブジェクトポインタ機能

ここでは，圧縮オブジェクトポインタ機能について説明します。

4.15.1　圧縮オブジェクトポインタ機能の概要

圧縮オブジェクトポインタ機能は，Javaアプリケーションによって作成されるJavaオブジェクトのサイズを圧縮することで，Javaアプリケーションのメモリ使用効率を向上させる機能です。この機能を有効にすることによって，アプリケーションサーバ上で動作しているJavaアプリケーション実行中での，Javaヒープ領域の使用量を少なくできます。

圧縮オブジェクトポインタ機能は，-XX:+UseCompressedOopsを指定することで有効にできます。UseCompressedOopsオプションの詳細については，「5.2　日立JavaVM拡張オプションの詳細」を参照してください。

この機能を有効にすると，実行時のメモリ使用量とJavaVMの実行性能が変化する場合があります。また，JavaVM実行時のOS環境の違いによっても，この機能有効時のJavaVMの実行性能が変動します。

4.15.2　圧縮オブジェクトポインタ機能の前提条件

Javaヒープ領域の設定サイズの総和が32GB未満のときに有効です。設定サイズが32GB以上の場合は，-XX:+UseCompressedOopsを指定しても，この機能は無効となります。

圧縮オブジェクトポインタ機能が有効となるヒープ領域サイズ指定値

　(-Xmxオプションの指定値) < 32GB

4.15.3　圧縮オブジェクトポインタ機能の注意事項

この機能を有効にすることによって，Javaアプリケーション実行時のJavaヒープ領域の使用量が減少し，その変化量はJavaアプリケーションに依存します。もし，この機能を有効にしたことによるメモリ使用量の変化を問題視する場合は，この機能をOFFにしてください。

この機能を有効にすることによって，Javaアプリケーション実行時のスループットなどの実行性能に影響を与える場合があるのでご注意ください。この機能が実行性能に影響する点は，次の2点です。

(a)JavaVMが扱うデータ（Javaオブジェクト）サイズが減少し，より効率的なメモリアクセスができる（性能向上要因）

(b)JavaVMがJavaオブジェクトのサイズを圧縮するための計算が必要となる（性能低下要因）

(a)(b)の2点の要因から，この機能有効時，JavaVM実行時の性能が変化することになります。また，(b)については，JavaVM起動時のOS環境の違いによって，計算方法（詳細は次の（補足））も変化し実行性能に影響します。もし，この機能を有効にしたことによる性能の変化を問題視する場合は，この機能をOFFにしてください。

（補足）Javaオブジェクトのサイズの圧縮について

圧縮オブジェクトポインタ機能有効時，JavaVMはJavaオブジェクトのサイズを圧縮して管理しますが，その圧縮方法（以降，モードと呼びます）は複数存在します。JavaVMは起動時に，その実行環境状況によってどのモードを選択するかを決定します。以降，JavaVMは起動時に選択したモードを適用して，Javaオブジェクトのサイズを圧縮します。

どのモードを選択するかの条件は，次の2つとなります。

1. Javaヒープ領域の指定値

2. 1.のヒープ領域が仮想アドレス空間のどこに割り当てられるか

そのため，JavaVM起動時のヒープ領域サイズの指定値を変更した場合，または，同一OS上で動作しているほかのプロセスやライブラリのロード状況によっては，JavaVM起動ごとに異なるモードが適用されます。

どのモードが選択されるかは，実際にヒープ領域が仮想メモリ空間上のどこに割り当てられるかに依存するため，特定の圧縮モードが常に適用されるようにこの機能を有効とすることは困難です。この機能を無効・有効とした場合だけ性能の差異が発生するだけでなく，この機能を有効とした場合も，JavaVMの起動ごとに性能の差異が発生する場合もあることにご注意ください。

参考として圧縮オブジェクトポインタ機能有効時にJavaVMが選択できる各モードについて，選択条件と圧縮方法の概要を次の表※に示します。

表4‒14　圧縮オブジェクトポインタ機能のモード一覧

モード

選択条件

概要説明

モード1

Javaヒープ領域の総サイズが4GB未満であり，仮想アドレス空間上，Javaヒープ領域が4GBよりも低位側に存在する場合

最も簡単な計算方法で，Javaオブジェクトのサイズを圧縮します。

モード2

モード1の適用ができないで，仮想アドレス空間上，そのヒープ領域が32GBよりも低位側に存在する場合

モード1の次に簡単な計算方法によってJavaオブジェクトのサイズを圧縮します。

モード3

モード1とモード2が適用できなかった場合

これらモードのうち，最も複雑な方法でJavaオブジェクトの圧縮をします。

注※

表に示した内容はJavaVMの内部処理を参考として示したものです。以降のJDKのアップデートや修正によって予告なく変更される場合があります。

4.16　日立JavaVMの機能使用時の注意事項

日立JavaVMの機能を使用する際の注意事項について説明します。

SIGXFSZシグナル受信時の動作について

JavaVMがSIGXFSZシグナルを受信した場合，次のメッセージを標準出力に出力して処理を継続します。

Java HotSpot(TM) 64-Bit Server VM warning: File size limit exceeded.

ただし，ファイルサイズの上限を超える場合は，ファイルへ書き込みません。

SIGXCPUシグナル受信時の動作について

JavaVMがSIGXCPUシグナルを受信した場合，次のメッセージを標準出力に出力して処理を継続します。

Java HotSpot(TM) 64-Bit Server VM warning: CPU time limit exceeded.

フォントに関するメッセージについて

Xサーバのようにコンソール以外のリモート端末上で，GUIのアプリケーションを起動する際，次のようなメッセージが出力される場合があります。

Warning: Cannot convert string
"-monotype-arial-regular-r-normal--*-140-*-*-p-*-iso8859-1" to type FontStruct

この場合，xfsコマンドでフォントサーバを起動し，Xサーバ側でxsetコマンドを使用してフォントパスにフォントサーバを指定すると回避できます。その際，フォントサーバの設定ファイルに不足しているフォントパスが指定されていることを確認してください。

4.17　Oracle社のJDKと日立が提供するJDKとの非互換性

ここでは，Oracle社のJDKと日立が提供するJDKとの非互換性について説明します。

4.17.1　デフォルトで選択されるメモリ管理方式

Oracle社のJDK 9以降では，デフォルトで選択されるメモリ管理方式はガベージファースト・コレクタ（G1GC）に変更されました。しかし，日立が提供するメモリ管理方式は，シリアルガベージコレクタ（SerialGC）であることに注意してください。

4.17.2　ランタイムイメージ

ランタイムイメージの作成および再構成はサポートしていません。また，ランタイムイメージを作成するjlinkコマンドは同梱していません。

4.17.3　モジュール関連オプション

モジュールに関連したオプションで，サポートしていないオプションまたは制限事項のあるオプションがあります。

(1)　サポートしていないオプション

次に示すオプションはサポートしていません。

--limit-modules

--module（または-m）

--patch-module

--upgrade-module-path

各オプションの詳細は，次のWebページを参照してください。

https://docs.oracle.com/en/java/javase/11/tools/java.html

(2)　制限事項のあるオプション

次に示すオプションには制限事項があります。これらのオプションには，更新対象モジュールにJDK内モジュール※を指定しないでください。

--add-exports

--add-opens

--add-reads

注※

JDK内モジュールとは，次のWebページに記載されているすべてのモジュールです。

https://docs.oracle.com/javase/jp/11/docs/api/index.html

各オプションの詳細は，次のWebページを参照してください。

https://docs.oracle.com/en/java/javase/11/tools/java.html

制限事項の対象となる使用例を次に示します。

（使用例1）

--add-exports=java.base/jdk.internal.jimage=my.module

更新対象にjava.baseモジュールを指定しないでください。

（使用例2）

--add-opens=java.base/jdk.internal.jimage=my.module

更新対象にjava.baseモジュールを指定しないでください。

（使用例3）

--add-reads=java.logging=my.module

更新対象にjava.loggingモジュールを指定しないでください。

5　日立JavaVM起動オプション

この章では，日立JavaVM起動オプションについて説明します。

日立JavaVMではJavaVM起動オプションとして，Java HotSpot VMのオプションのほか，日立固有の拡張オプションを指定できます。ここでは，拡張オプションの詳細，および日立JavaVMで指定できるJava HotSpot VMのオプションについて説明します。

5.1　日立JavaVM拡張オプションの一覧

日立JavaVMは，日立固有の拡張オプションを使用できます。

日立JavaVM拡張オプションの一覧を，次の表に示します。

重要

指定できるオプションについて

日立JavaVMで指定できるオプションは，javaコマンドに対してオプション指定なしで起動した場合に表示されるオプションと，javaコマンドに対して-Xか-XXか-XX:+Hitachiオプションを指定したときに表示されるオプションだけです。それ以外のオプションを指定した場合，動作は保証しません。

次の表の「関連情報」とは，指定したキーに関する情報の参照先です。

表5‒1　日立JavaVM拡張オプションの一覧

分類

オプション名称

概要

関連情報

一覧表示オプション

-XX:+Hitachi

日立JavaVM拡張オプションの一覧を表示します。

拡張スレッドダンプ機能オプション

-XX:[+|-]HitachiThreadDump

拡張スレッドダンプ情報を出力するかどうかを指定します。

-XX:[+|-]HitachiThreadDumpToStdout

標準出力にスレッドダンプを出力するかどうかを指定します。

-XX:[+|-]HitachiThreadDumpWithHashCode

スレッド情報にハッシュコードを出力するかどうかを指定します。

-XX:[+|-]HitachiThreadDumpWithCpuTime

スレッド情報にユーザCPU時間とカーネルCPU時間を出力するかどうかを指定します。

-XX:[+|-]HitachiThreadDumpWithBlockCount

スレッド情報に処理をブロックした回数と待ち状態になった回数を出力するかどうかを指定します。

JavaVMログファイルオプション

-XX:HitachiJavaLog※1

ログファイル名のプリフィックスを指定します。

-XX:HitachiJavaLogFileSize※1

1ファイルの最大ファイルサイズを指定します。

-XX:[+|-]HitachiJavaLogNoMoreOutput※1

ログファイル作成時に，入出力エラーが発生した場合の動作について指定します。

-XX:HitachiJavaLogNumberOfFile※1

作成するログファイルの最大ファイル数を指定します。

-XX:[+|-]JavaLogAsynchronous

ログファイルの非同期出力機能を有効にします。

-XX:[+|-]StandardLogToHitachiJavaLog

日立JavaVMの標準出力と標準エラー出力の内容を，JavaVMログファイルに出力するかどうかを指定します。

詳細時間出力オプション

-XX:[+|-]HitachiOutputMilliTime

ミリ秒までの時間を出力するかどうかを指定します。

拡張verbosegc機能オプション

-XX:[+|-]HitachiVerboseGC※2

GCが発生したときの拡張verbosegc情報を出力するかどうかを指定します。

-XX:[+|-]HitachiCommaVerboseGC

拡張verbosegc情報をCSV形式で出力するかどうかを指定します。

-XX:HitachiVerboseGCIntervalTime

拡張verbosegc情報を出力する時間の間隔を指定します。

-XX:[+|-]HitachiVerboseGCPrintCause

GCの要因内容を出力するかどうかを指定します。

-XX:[+|-]HitachiVerboseGCPrintDate

拡張verbosegc情報に日付を出力するかどうかを指定します。

-XX:[+|-]HitachiVerboseGCCpuTime

GCのプロセッサ時間を出力するかどうかを指定します。

-XX:[+|-]HitachiVerboseGCPrintTenuringDistribution

GC発生時にJavaVMログファイルへSurvivor領域のオブジェクトの年齢分布を出力します。

-XX:[+|-]HitachiVerboseGCPrintJVMInternalMemory

日立JavaVM内部で管理しているヒープ情報をJavaVMログファイルへ出力するかどうかを指定します。

-XX:[+|-]HitachiVerboseGCPrintThreadCount

Javaスレッドの数を監視するために，Javaスレッドの数をJavaVMログファイルに出力するかどうかを指定します。

-XX:[+|-]HitachiVerboseGCPrintDeleteOnExit

java.io.File.deleteOnExit()を呼び出したことによって日立JavaVMが確保した累積のヒープサイズとメソッドの呼び出し回数をJavaVMログファイルに出力するかどうかを指定します。

コードキャッシュ領域情報出力機能オプション

-XX:[+|-]PrintCodeCacheInfo

コードキャッシュ領域の使用量を出力するかどうか，また，使用量がしきい値に達したことを知らせるメッセージを出力するかどうかを指定します。

「7.3.3　コードキャッシュ領域に関するログの内容」

-XX:CodeCacheInfoPrintRatio

コードキャッシュ領域の使用量がしきい値に達したことを知らせるメッセージを出力する契機となる，コードキャッシュ領域の使用率を指定します。

-XX:[+|-]PrintCodeCacheFullMessage

JavaメソッドがJITコンパイルの対象になった場合，コードキャッシュ領域が枯渇していたときにメッセージを出力するかどうかを指定します。

「7.3.3　コードキャッシュ領域に関するログの内容」

OutOfMemoryError発生時の拡張機能オプション

-XX:[+|-]HitachiOutOfMemoryCause※2

OutOfMemoryError発生時の発生要因種別を出力するかどうかを指定します。

-XX:[+|-]HitachiOutOfMemoryStackTrace※2

OutOfMemoryError発生時のスタックトレースを出力するかどうかを指定します。

-XX:HitachiOutOfMemoryStackTraceLineSize

OutOfMemoryError発生時に出力するスタックトレースの1行の文字数を指定します。

-XX:[+|-]HitachiOutOfMemorySize※2

OutOfMemoryError発生時に要求したメモリのサイズを出力します。

-XX:[+|-]HitachiOutOfMemoryAbort

OutOfMemoryError発生時，メッセージとメモリダンプを出力して強制終了するかどうかを指定します。

-XX:[+|-]HitachiOutOfMemoryAbortThreadDump

OutOfMemoryError発生時にスレッドダンプを出力かどうかを指定します。

-XX:[+|-]HitachiOutOfMemoryAbortThreadDumpWithJHeapProf

-XX:+HitachiOutOfMemoryAbortThreadDumpで出力するスレッドダンプログファイルにクラス別統計情報を出力します。

-XX:[+|-]HitachiOutOfMemoryHandling

OutOfMemoryハンドリング機能を有効にするかどうかを指定します。

-XX:HitachiOutOfMemoryHandlingMaxThrowCount

OutOfMemoryハンドリング機能を有効にした場合の，Javaヒープ不足またはMetaspace，Compressed Class Space不足が原因のOutOfMemory発生回数合計値の1時間当たりの上限値を指定します。

クラスライブラリトレース機能オプション

-XX:[+|-]HitachiJavaClassLibTrace※2

クラスライブラリのスタックトレースを出力するかどうかを指定します。

-XX:HitachiJavaClassLibTraceLineSize

クラスライブラリのスタックトレースの1行の文字数を指定します。

ローカル変数情報出力機能オプション

-XX:[+|-]HitachiLocalsInThrowable

例外発生時のスタックトレースに，ローカル変数情報を出力するかどうかを指定します。

-XX:[+|-]HitachiLocalsInStackTrace

スレッドダンプ出力時のスタックトレースに，ローカル変数情報を出力するかどうかを指定します。

「7.5　JavaVMスタックトレース情報」

-XX:[+|-]HitachiLocalsSimpleFormat

ローカル変数情報出力を，簡易フォーマットにするかどうかを指定します。

「7.5　JavaVMスタックトレース情報」

-XX:[+|-]HitachiTrueTypeInLocals

ローカル変数情報出力時に，ローカル変数オブジェクトの実際の型名を文字列として出力するかどうかを指定します。

「7.5　JavaVMスタックトレース情報」

-XX:HitachiCallToString

ローカル変数情報出力時に，ローカル変数オブジェクトの変数値を文字列として出力するかどうかを指定します。

「7.5　JavaVMスタックトレース情報」

システムリソース解除オプション

-XX:[+|-]HitachiFullCore

システムリソースRLIMIT_COREの設定を変更するかどうかを指定します。

リソースの上限値指定オプション

-XX:HitachiJITCompileMaxMemorySize

JITコンパイル時に確保するメモリの上限値を指定します。

-XX:HitachiThreadLimit

スレッド数の上限値を指定します。

JITコンパイラ稼働継続機能オプション

-XX:[+|-]JITCompilerContinuation

JITコンパイラ稼働継続機能を有効にするかどうかを指定します。

圧縮オブジェクトポインタ機能オプション

-XX:[+|-]UseCompressedOops

圧縮オブジェクトポインタ機能を有効にするかどうかを設定します。

「4.15　圧縮オブジェクトポインタ機能」

（凡例）

空欄：関連情報はありません。

注※1

JavaVMログファイルについての設定です。

注※2

次のオプションを指定した場合，JavaVMログファイルが出力されます。

-XX:+HitachiOutOfMemoryStackTrace

-XX:+HitachiOutOfMemoryCause

-XX:+HitachiOutOfMemorySize

-XX:+HitachiVerboseGC

-XX:+HitachiJavaClassLibTrace

5.2　日立JavaVM拡張オプションの詳細

日立JavaVM拡張オプションの詳細について説明します。

なお，本文中では，次のJavaプログラムを例として使用しています。

Javaプログラム例1

class Example1 {
    public static void main(String[] args) {
        Example1 e1 = new Example1();
        Object obj = new Object();
        e1.method(1, 'Q', obj);  // 5行目
    }

    void method(int l1, char l2, Object l3) {
        float l4 = 4.0f;
        boolean l5 = true;
        double l6 = Double.MAX_VALUE; // double型の最大値
        Object[] l7 = new Object[10];

        try {
          <例外発生!>  // 15行目
        } catch (Exception e) {
          e.printStackTrace();
        }
    }
}

Javaプログラム例2

class Example2 {
    public static void main(String[] args) {
        Example2 e2 = new Example2();
        e2.method();  // 4行目
    }

    synchronized void method() {
        int l1 = 1;
        float l2 = 2.0f;
        String l3 = "local 3";
        Character l4 = new Character('X');
        Object l5 = new Thread();
        Object[] l6 = new Thread[10];

        <ここでスレッドダンプ出力!>  // 15行目
    }
}

Javaプログラム例3

class Example3 {
    public static void main(String[] args) {
        Example3 e3 = new Example3();
        e3.method();  // 4行目
    }

    void method() {
        String l1 = "local 1";
        StringBuffer l2 = new StringBuffer(l1);
        l2.append(" + local 2");
        Boolean l3 = new Boolean(false);
        Character l4 = new Character('X');
        Long l5 = new Long(Long.MIN_VALUE);  // long型の最小値
        Object l6 = new Thread();
        Object[] l7 = new Thread[10];

        try {
          <例外発生!>  // 18行目
        } catch (Exception e) {
          e.printStackTrace();
        }
    }

    public String toString() {
        return "I am an Example3 instance.";
    }
}

-XX:+Hitachi（一覧表示オプション）

形式

-XX:+Hitachi

説明

日立JavaVM拡張オプションを一覧表示します。

このオプションは，Javaプログラムを実行しません。また，アプリケーションサーバの起動オプションに指定した場合，アプリケーションサーバは起動されません。

-XX:[+|-]HitachiThreadDump（拡張スレッドダンプ情報出力オプション）

形式

-XX:+HitachiThreadDump

-Xrsオプションが指定されていない場合，スレッドダンプ出力時に拡張スレッドダンプ情報を出力します。

-XX:-HitachiThreadDump

スレッドダンプ出力時に標準のスレッドダンプ情報を出力します。

説明

拡張スレッドダンプ情報を出力するかどうかを指定します。

スレッドダンプは，標準出力，および次に示すファイルに出力されます。

デフォルト値

マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

スレッドダンプ出力先

デフォルトの出力先は，JavaVM実行時のカレントディレクトリです。環境変数JAVACOREDIRを指定することで，出力先を変更することができます。

スレッドダンプ出力ファイル名

javacore<プロセス番号>.<YYMMDDhhmmss>※.txt

注※

YY：年（西暦で下2桁），MM：月（2桁），DD：日（2桁）

hh：時間（24時間表記），mm：分（2桁），ss：秒（2桁）

スレッドダンプ情報の構成を，次に示します。

表5‒2　スレッドダンプ情報の構成

出力情報

内容

ヘッダ

スレッドダンプを開始した日付および時刻，JavaVMバージョン情報，起動コマンドラインを出力します。

システム設定

次の情報を出力します。

JDKの実行環境のインストールディレクトリ

JDKを構成するライブラリのインストールディレクトリ

システムクラスパス

Javaコマンドオプション

動作環境

次の情報を出力します。

ホスト名

OSバージョン

CPU情報

リソース情報

Javaヒープ情報

Javaヒープの各世代のメモリ使用状況を出力します。

JavaVM内部メモリマップ情報

JavaVM自身の確保しているメモリの領域情報を出力します。

JavaVM内部メモリサイズ情報

JavaVM自身の確保しているメモリのサイズ情報を出力します。

アプリケーション情報

次の情報を出力します。

シグナルハンドラ

環境変数

カレントディレクトリ情報

ライブラリ情報

ローディングされているライブラリの情報を出力します。

スレッド情報

<スレッド1>

:

<スレッドn>

スレッドごとにスレッド情報を出力します。現存する全スレッドのスタックトレースを出力します。

Javaモニタダンプ※

Javaモニタオブジェクトの一覧を表示します。スレッド間の排他待ちの状況を確認できます。

JNIグローバル参照情報

JavaVMが保持しているJNIのグローバル参照の数を出力します。

JNIグローバル参照は，次の場合に作成されます。

JavaVMが自身の起動や実行のために必要な場合。

JNIがサポートするNewGlobalRef関数を発行した場合。

フッタ

スレッドダンプを終了した日付および時刻を出力します。

注※　notify待ちの一覧が表示されない場合があります。

出力形式

ヘッダ

EEE MMM dd hh:mm:ss yyyy※

Full thread dump Java HotSpot(TM) <VM type>※ (25.20-b23-CDK0970-<ビルド日> mixed mode)
<起動コマンドライン>
…

注※

EEEは曜日，MMMは月，ddは日を表します。また，hhは時間，mmは分，ssは秒，yyyyは年（西暦）を表します。

<VM type>はClient VM，Server VMまたは64-Bit Server VMのどれかを表します。

システム設定

System Properties
-----------------
Java Home Dir  : <JDK実行環境インストールディレクトリ>
Java DLL Dir   : <JDKを構成するライブラリのインストールディレクトリ>
Sys Classpath  : <システムクラスパス>
User Args      :
<Javaコマンドオプション1>
<Javaコマンドオプション2>
…

動作環境

Operating Environment
---------------------
Host    : <ホスト名>:<IPアドレス>
OS      : <OSバージョン>
CPU     : <CPU種別>, <利用可能CPU数/システム全体のCPU数>

Resource Limits -
         RLIMIT_CPU     :<プロセスで使用可能な秒数>
         RLIMIT_FSIZE   :<最大ファイルサイズ(単位：バイト)>
         RLIMIT_DATA    :<malloc可能なサイズ(単位：バイト)>
         RLIMIT_STACK   :<スタックの最大サイズ(単位：バイト)>
         RLIMIT_CORE    :<coreの最大サイズ(単位：バイト)>
         RLIMIT_RSS     :<プロセスの常駐サイズ(単位：バイト)>
         RLIMIT_AS      :<プロセストータルの利用可能メモリ(単位：バイト)>
         RLIMIT_NOFILE  :<最大のファイルディスクリプタ値>

Javaヒープ情報（SerialGCを使用している場合）

Heap Status
-----------
def new generation   max <最大の容量>, total <現在の容量>, used <使用中メモリ> (<最大の容量に対する使用率>% used/max, <現在の容量に対する使用率>% used/total)
                     [<領域先頭アドレス>, <コミット済み領域の末尾アドレス>, <予約済み領域の末尾アドレス>)
  eden space <現在の容量>,  <使用率>% used [<領域先頭アドレス>, <使用中領域の先頭アドレス>, <予約済み領域の末尾アドレス>)
  from space <現在の容量>,   <使用率>% used [<領域先頭アドレス>, <使用中領域の先頭アドレス>, <予約済み領域の末尾アドレス>)
  to   space <現在の容量>,   <使用率>% used [<領域先頭アドレス>, <使用中領域の先頭アドレス>, <予約済み領域の末尾アドレス>)
tenured generation   max <最大の容量>, total <現在の容量>, used <使用中メモリ> (<最大の容量に対する使用率>% used/max, <現在の容量に対する使用率>% used/total)
                      [<領域先頭アドレス>, <コミット済み領域の末尾アドレス>, <予約済み領域の末尾アドレス>)
   the space <現在の容量>,  <使用率>% used [<領域先頭アドレス>, <使用中領域の先頭アドレス>, <次の空きブロックの先頭アドレス>, <予約済み領域の末尾アドレス>)
Metaspace       max<最大の容量>, capacity <コミット済みの領域からフリー領域を除いたメモリサイズ>, committed <コミット済みのメモリサイズ>, reserved <予約済みのメモリサイズ>, used <使用中メモリ> (<最大の容量に対する使用率>% used/max, <現在の容量に対する使用率>% used/total)
  class space    max <最大の容量>, capacity <コミット済みの領域からフリー領域を除いたメモリサイズ>, committed <コミット済みのメモリサイズ>, reserved <予約済みのメモリサイズ>, used <使用中メモリ> (<最大の容量に対する使用率>% used/max, <現在の容量に対する使用率>% used/committed)
                      [<領域先頭アドレス>, <使用中領域の先頭アドレス>, <コミット済み領域の末尾アドレス>, <予約済み領域の末尾アドレス>)

注

容量およびメモリサイズの単位はキロバイトです。

Javaヒープ情報（G1GCを使用している場合）

Heap Status
-----------
garbage-first heap   total <現在の容量>, used <使用中のメモリ> [<領域先頭アドレス>, <コミット済みの末尾アドレス>, <予約済み領域のアドレス>)
  region size <1リージョンのサイズ>, <New領域の使用中リージョン数> young (<New領域の使用中メモリ>), <Survivor領域の使用中リージョン数> survivors (<Survivor領域の使用中メモリ>)
 Metaspace       max <最大の容量>, capacity <コミット済みの領域からフリー領域を除いたメモリサイズ>, committed <コミット済みのメモリサイズ>, reserved <予約済みのメモリサイズ>, used <使用中メモリ> (<最大の容量に対する使用率>% used/max, <現在の容量に対する使用率>% used/committed)
  class space    max <最大の容量>, capacity <コミット済みの領域からフリー領域を除いたメモリサイズ>, committed <コミット済みのメモリサイズ>, reserved <予約済みのメモリサイズ>, used <使用中メモリ> (<最大の容量に対する使用率>% used/max, <現在の容量に対する使用率>% used/committed)
                [<領域先頭アドレス>, <使用中領域の先頭アドレス>, <コミット済み領域の末尾アドレス>, <予約済み領域の末尾アドレス>)

JavaVM内部メモリマップ情報

JVM Internal Memory Map
-----------------------
<メモリ確保関数>:address = <開始アドレス> - <終了アドレス> (size:<サイズ>)

注

<メモリ確保関数>：mmap()かmalloc()のどちらかが出力されます。

<開始アドレス>：メモリ領域の開始アドレスが16進で出力されます。

<終了アドレス>：メモリ領域の終了アドレスが16進で出力されます。

<サイズ>：確保しているメモリ領域のサイズが出力されます（単位：バイト）。

JavaVM内部メモリサイズ情報

JVM Internal Memory Status
--------------------------
  Heap Size      :<確保しているメモリサイズ>※
  Alloc Size     :<使用中のメモリサイズ>※
  Free Size      :<未使用のメモリサイズ>※

注※

単位：バイト

アプリケーション環境

Application Environment
-----------------------
Signal Handlers -※1
  SIGHUP         :<シグナルハンドラ情報>
  SIGINT         :<シグナルハンドラ情報>
…
  SIGSOUND       :<シグナルハンドラ情報>
  SIGSAK         :<シグナルハンドラ情報>

Signal Handlers -※2
シグナル種別： [シグナルハンドラアドレス], sa_mask[0]=シグナルマスク, sa_flags=特殊フラグ
…

Environment Variables -
<環境変数>=<値>
…
Current Directory -
  /opt/Cosminexus/CC/server/…

注※1

次の情報が表示されます。

シグナルハンドラがインストールされている場合は，そのアドレス。

SIG_DFLである場合は，default。

SIG_IGNである場合は，ignored。

注※2

次の情報が表示されます。

シグナル種別には，/usr/include/sys/signal.hに定義されているシグナル名。

シグナルハンドラアドレスには，シグナルハンドラのアドレスが16進数で出力されます。ライブラリ名＋オフセットという形式で表示されることもあります。

シグナルマスクには，sigaction()で取り出せる構造のsa_maskフィールド値が16進数で出力されます。

特殊フラグには，sigaction()で取り出せる構造のsa_flagsフィールド値が16進数で出力されます。

ライブラリ情報

Loaded Libraries
----------------
Dynamic libraries :
<開始アドレス>-<終了アドレス>   <コマンド>
<開始アドレス>-<終了アドレス>   <ライブラリ>
…

スレッド情報

-----------
"<スレッド名>" <daemon> prio=<優先度> jid=<ハッシュ値> tid=<スレッドID> nid=<nativeID> <status> [<開始アドレス>...<終了アドレス>]
    java.lang.Thread.State: <スレッドの現在のステータス>
    stack=[<スタック開始アドレス>..<YellowPageアドレス>..<RedPageアドレス>..<スタック終了アドレス>]
    [user cpu time=<ユーザー時間>ms, kernel cpu time=<カーネル時間>ms] [blocked count=<ブロック回数>, waited count=<待機回数>]
         at <クラス名>.<メソッド名>(<メソッド情報>)
…

出力内容を説明します。

<スレッド名>

Threadクラスのコンストラクタに指定されたスレッド名称が出力されます。

<daemon>：デーモンスレッドである場合に，"daemon"と出力されます。

<優先度>：Thread#setPriorityで設定された優先度が出力されます。

<ハッシュ値>：System.identityHashCode()を呼び出して得られる値と同一の値が8桁の16進数で出力されます。

<スレッドID>：スレッドオブジェクトのメモリ上のアドレス。

<nativeID>：OSレベルのスレッドID。

<status>：スレッドの状態。

runnable：実行中または実行可能なスレッド

in Object.wait()，waiting for monitor entryまたはwaiting on condition：モニタロック待ちのスレッド

sleeping：中断状態のスレッド

<開始アドレス>：Javaフレームの最高位スタックアドレスが16進数で出力されます。

<終了アドレス>：JavaLockのある最高位スタックアドレスが16進数で出力されます。

<ユーザー時間>：スレッド開始からのユーザー時間がミリ秒単位で出力されます。

<カーネル時間>：スレッド開始からのカーネル時間がミリ秒単位で出力されます。

<ブロック回数>：スレッド開始から，処理がブロックされた回数が出力されます。

<待機回数>：スレッド開始から，処理が待ち状態になった回数が出力されます。

<スレッドの現在のステータス>

スレッドの現在のステータスを表すメッセージが出力されます。メッセージの内容はjava.lang.Thread.State列挙型に対応します。

<スタック開始アドレス>

スタック開始アドレスが16進数で出力されます。

<YellowPageアドレス>

スタックYellowガードページ先頭アドレスが16進数で出力されます。

<RedPageアドレス>

スタックRedガードページ先頭アドレスが16進数で出力されます。

<スタック終了アドレス>

スタック終了アドレスが16進数で出力されます。

<クラス名>

クラス名が出力されます。

<メソッド名>

メソッド名が出力されます。

<メソッド情報>

次のメソッド情報が出力されます。

Native Method

ネイティブメソッドの場合に出力されます。

ファイル名：行番号

Javaメソッドで行番号付きでコンパイルされている場合に出力されます。

Unknown Source

Javaメソッドで行番号なしでコンパイルされている場合に出力されます。

Javaモニタダンプ

Java monitor
------------
<ロックオブジェクト>@<ハッシュコード> <オーナー情報>
   <待機状態>:<待機スレッド数>
      <待機スレッド情報>

出力内容を説明します。

<ロックオブジェクト>

ロック対象オブジェクトのクラス名が出力されます。

<ハッシュコード>

Object.hashCodeで得られるハッシュコードが出力されます。

<オーナー情報>

owner "<スレッド名>"<スレッドID>

オーナーがある場合に出力されます。

no owner

オーナーがない場合に出力されます。

<待機状態>

... waiting to enter

メソッド実行待ちの場合に出力されます。

... waiting to be notified

通知待ちの場合に出力されます。

<待機スレッド数>

スレッド数が出力されます。

<待機スレッド情報>

「"<スレッド名>" <スレッドID>」の形式で出力されます。

JNIグローバル参照数の情報

JNI Information
---------------
JNI global references: <JNIグローバル参照数>

出力内容を説明します。

<JNIグローバル参照数>

JavaVMが保持しているグローバル参照の数が出力されます。

注

JNIグローバル参照はJavaVMの内部でも再利用されるため，JNIがサポートするDeleteGlobalRef関数を発行してJNIグローバル参照を削除しても，数値は減少しません。また，NewGlobalRef関数を発行してJNIグローバル参照を新規作成しても，JavaVMが再利用したJNIグローバル参照を割り当てた場合は数値は増加しません。

拡張スレッドダンプ情報との比較を，次に示します。

表5‒3　標準スレッドダンプと拡張スレッドダンプの出力情報の比較

出力情報

標準スレッドダンプ

拡張スレッドダンプ

ヘッダ

×

○

システム設定

×

○

動作環境

×

○

Javaヒープ情報

×

○

JavaVM内部メモリマップ情報

×

○

JavaVM内部メモリサイズ情報

×

○

アプリケーション環境

×

○

ライブラリ情報

×

○

スレッド情報

○

○※1

Javaモニタダンプ

×

○

JNIグローバル参照数の情報

○

○

フッタ

×

○

スレッドダンプ出力先

標準出力

標準出力※2

JavaVMログファイル

（凡例）

○：出力されます。

×：出力されません。

注※1

スタックの開始および終了のアドレス情報などが出力されます。

注※2

-XX:+HitachiThreadDumpToStdoutオプションが指定された場合に出力されます。

注意事項

環境変数JAVACOREDIRで指定したディレクトリへの出力に失敗した場合，カレントディレクトリに出力されます。

カレントディレクトリへの出力に失敗した場合，標準エラー出力に出力されます。なお，この場合，スレッドダンプは標準出力に出力されません。

次に示すオプションの[+|-]指定が「-」の場合，スレッド情報の一部が出力されないのでご注意ください。

オプション名称

出力されない情報

-XX:[+|-]HitachiThreadDumpWithHashCode

<ハッシュ値>

-XX:[+|-]HitachiThreadDumpWithCpuTime

<ユーザー時間>，<カーネル時間>

-XX:[+|-]HitachiThreadDumpWithBlockCount

<ブロック回数>，<待機回数>

-XX:[+|-]HitachiThreadDumpToStdout（拡張スレッドダンプ標準出力抑止オプション）

形式

-XX:+HitachiThreadDumpToStdout

拡張スレッドダンプを標準出力およびスレッドダンプ出力ファイルに出力します。

-XX:-HitachiThreadDumpToStdout

拡張スレッドダンプを標準出力に出力しません。スレッドダンプ出力ファイルだけに出力します。

説明

拡張スレッドダンプを標準出力へ出力するかどうかを指定します。

このオプションの指定に関係なく，次のメッセージは出力されます。また，拡張スレッドダンプはJavaVMログファイルへ出力されます。

Writing Java core to <ファイル名（フルパス）>... OK

デフォルト値

マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

前提オプション

-XX:+HitachiThreadDump

-XX:[+|-]HitachiThreadDumpWithHashCode（拡張スレッドダンプハッシュコード出力オプション）

形式

-XX:+HitachiThreadDumpWithHashCode

拡張スレッドダンプのスレッド情報にハッシュコードを出力します。

-XX:-HitachiThreadDumpWithHashCode

拡張スレッドダンプのスレッド情報にハッシュコードを出力しません。

説明

拡張スレッドダンプのスレッド情報にハッシュコードを出力するかどうかを指定します。

なお，ハッシュコードは，Javaプログラムを実行しているスレッドに対して出力されます。JavaVMの内部動作用スレッドに対しては出力されません。

デフォルト値

マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

前提オプション

-XX:+HitachiThreadDump

-XX:[+|-]HitachiThreadDumpWithCpuTime（拡張スレッドダンプCPU利用時間出力オプション）

形式

-XX:+HitachiThreadDumpWithCpuTime

拡張スレッドダンプのスレッド情報に，スレッド開始からのユーザーCPU時間とカーネルCPU時間を出力します。

-XX:-HitachiThreadDumpWithCpuTime

拡張スレッドダンプのスレッド情報に，スレッド開始からのユーザーCPU時間とカーネルCPU時間を出力しません。

説明

拡張スレッドダンプのスレッド情報に，ユーザーCPU時間とカーネルCPU時間を出力するかどうかを指定します。

なお，ユーザーCPU時間とカーネルCPU時間は，Javaプログラムを実行しているスレッドに対して出力されます。JavaVMの内部動作用スレッドに対しては出力されません。

デフォルト値

マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

前提オプション

-XX:+HitachiThreadDump

-XX:[+|-]HitachiThreadDumpWithBlockCount（拡張スレッドダンプブロック回数出力オプション）

形式

-XX:+HitachiThreadDumpWithBlockCount

拡張スレッドダンプのスレッド情報に，スレッドが処理をブロックした回数と待ち状態になった回数を出力します。

-XX:-HitachiThreadDumpWithBlockCount

拡張スレッドダンプのスレッド情報に，スレッドが処理をブロックした回数と待ち状態になった回数を出力しません。

説明

拡張スレッドダンプのスレッド情報に，スレッドが処理をブロックした回数と待ち状態になった回数を出力するかどうかを指定します。

なお，ハッシュコードは，Javaプログラムを実行しているスレッドに対して出力されます。JavaVMの内部動作用スレッドに対しては出力されません。

デフォルト値

マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

前提オプション

-XX:+HitachiThreadDump

-XX:HitachiJavaLog（ログファイル名のプリフィックス指定オプション）

形式

-XX:HitachiJavaLog:<文字列>

説明

JavaVMログファイルのプリフィックスおよびログファイルの出力先ディレクトリを指定します。

デフォルト値

マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

前提オプション

次のどれかを指定します。

-XX:+HitachiVerboseGC

-XX:+HitachiOutOfMemoryStackTrace

-XX:+HitachiOutOfMemoryCause

-XX:+HitachiOutOfMemorySize

-XX:+HitachiJavaClassLibTrace

-XX:+JITCompilerContinuation

引数

<文字列>

プリフィックスおよびパスを指定します。次の3種類の指定ができます。

プリフィックスを指定する場合

ログファイル名は，<文字列>??.log（??は01〜99の通し番号）で生成されます。例えば，<文字列>に"Samp"を指定すると，ログファイル名はSamp01.logになります。このオプションを指定しない場合，<文字列>には，"javalog"が設定されます。また，ログファイルはカレントディレクトリに出力されます。

パスを指定する場合

<文字列>にディレクトリを指定した場合，そのディレクトリにファイルが作成されます。ログファイル名は，<文字列>javalog??.log（??は01〜99の通し番号）で生成されます。

パスとプリフィックスを同時に指定する場合

<文字列>にディレクトリとプリフィックスを指定した場合，そのディレクトリにファイルが作成されます。ログファイル名は，<文字列>??.log（??は01〜99の通し番号）で生成されます。例えば，<文字列>に"d:¥temp¥Samp"を指定すると，d:¥tempディレクトリに，Samp01.logが生成されます。

-XX:HitachiJavaLogFileSize（最大ログファイルサイズ指定オプション）

形式

-XX:HitachiJavaLogFileSize=<整数値>

説明

ログファイルの単純増加を防ぐため，1ファイルの最大ファイルサイズを指定します。最大ファイルサイズを超えた場合は，そのファイルへの出力は行いません。オプションの指定がない場合は，256キロバイトが設定されます。

デフォルト値

マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

前提オプション

次のどれかを指定します。

-XX:+HitachiVerboseGC

-XX:+HitachiOutOfMemoryStackTrace

-XX:+HitachiOutOfMemoryCause

-XX:+HitachiOutOfMemorySize

-XX:+HitachiJavaClassLibTrace

-XX:+JITCompilerContinuation

引数

<整数値>

1024〜2147483647の範囲で整数値（単位：バイト）を指定します。範囲外の値が指定された場合は1024が設定されます。負の値を指定した場合はエラーとなります。

-XX:[+|-]HitachiJavaLogNoMoreOutput（ログファイル入出力エラー発生時指定オプション）

形式

-XX:+HitachiJavaLogNoMoreOutput

ログファイル出力時にファイル入出力エラーが発生した場合，次のメッセージを標準エラー出力に出力し，ログ情報の出力を停止します。

Java logfile output failed.(errno=<エラーとなった入出力関数名>:<エラー番号>)

-XX:-HitachiJavaLogNoMoreOutput

ログファイル出力時にファイル入出力エラーが発生した場合，次のメッセージを標準エラー出力に出力し，ログ情報の出力先を標準エラー出力に変更して出力を継続します。

Java logfile output failed.(errno=<エラーとなった入出力関数名>:<エラー番号>) Changing output to stderr

説明

ログファイル作成時に入出力エラーが発生した場合に，ログ情報の出力方法について指定します。なお，どちらを指定した場合も，JavaVMの処理は継続されます。

デフォルト値

マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

前提オプション

次のどれかを指定します。

-XX:+HitachiVerboseGC

-XX:+HitachiOutOfMemoryStackTrace

-XX:+HitachiOutOfMemoryCause

-XX:+HitachiOutOfMemorySize

-XX:+HitachiJavaClassLibTrace

-XX:+JITCompilerContinuation

-XX:HitachiJavaLogNumberOfFile（最大ログファイル数指定オプション）

形式

-XX:HitachiJavaLogNumberOfFile=<整数値>

説明

ログファイルの単純増加を防ぐため，作成する最大ファイル数を指定します。最大ファイル数を超えた場合は，再度最初に作成したファイルへ出力を開始します。オプションの指定がない場合は，4が設定されます。

デフォルト値

マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

前提オプション

次のどれかを指定します。

-XX:+HitachiVerboseGC

-XX:+HitachiOutOfMemoryStackTrace

-XX:+HitachiOutOfMemoryCause

-XX:+HitachiOutOfMemorySize

-XX:+HitachiJavaClassLibTrace

引数

<整数値>

1〜99の範囲で指定します。100以上の値が指定された場合は99が，0以下の値が指定された場合は1が設定されます。負の値を指定した場合はエラーとなります。

-XX:[+|-]JavaLogAsynchronous

形式

-XX:+JavaLogAsynchronous

ログファイルの非同期出力機能を有効にします。

-XX:-JavaLogAsynchronous

ログファイルの非同期出力機能を無効にします。

説明

ログファイルの非同期出力機能の有効，無効を指定します。

ログファイルの非同期出力機能使用時，-XX:HitachiOutOfMemoryStackTraceLineSizeオプション，または-XX:HitachiJavaClassLibTraceLineSizeオプションに，4096より大きな値を指定した場合は，出力するスタックトレース1行の文字数に4096バイトが指定されたものとして動作します。

指定したバイト数が確保できない場合は警告メッセージが出力され，スタックトレースは出力されません。また，1行の文字数が指定した文字数を超えた場合，「at」以降の文字列の前半部分を削除して，指定された文字数分出力します。

デフォルト値

マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

-XX:[+|-]StandardLogToHitachiJavaLog（標準出力のログファイル出力オプション）

形式

-XX:+StandardLogToHitachiJavaLog

JavaVMの標準出力と標準エラー出力の内容をJavaVMログファイルに出力します。

-XX:-StandardLogToHitachiJavaLog

JavaVMの標準出力と標準エラー出力の内容をJavaVMログファイルに出力しません。日立JavaVMを起動したコンソールだけに出力します。

説明

この機能を有効にした場合，JavaVMの標準出力と標準エラー出力の内容をJavaVMログファイルにもあわせて出力します。

デフォルト値

マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

出力形式

[id] <date> stdout

出力内容を次に説明します。

id

識別子。

標準出力の場合は[STO]が出力され，標準エラー出力の場合は[STE]が出力されます。

date

ログ出力開始時間。

-XX:+HitachiOutputMilliTimeオプションが指定されている場合は，ミリ秒単位まで出力されます。

stdout

標準出力または標準エラー出力のメッセージ内容です。

出力されたメッセージの内容が次の場合，上記の出力形式とは異なる形式で出力されます。

出力されたメッセージ文字列が2,000バイトを超えていて，かつ文字列の最後に改行（¥n）がある場合，次の行に空行が出力されます。

出力対象のメッセージ文字列の途中に改行がある場合，改行したあとのメッセージには識別子やログ出力開始時間は出力されません。

出力例

[STO]<Fri Jul 19 11:35:33 2019>VM option '+StandardLogToHitachiJavaLog'
[STO]<Fri Jul 19 11:35:33 2019>VM option '+PrintVMOptions'
[STE]<Fri Jul 19 11:35:33 2019>Invalid initial young generation size: -Xmn0k

注意事項

JavaVMログファイル出力時にエラーが発生した場合，標準エラー出力に出力されるエラーメッセージは，JavaVMログファイルには出力されません。

-XX:[+|-]HitachiOutputMilliTime（詳細時間出力オプション）

形式

-XX:+HitachiOutputMilliTime

JavaVMログファイルに出力する日時に，ミリ秒まで出力します。

-XX:-HitachiOutputMilliTime

JavaVMログファイルに出力する日時に，秒まで出力します。

説明

ミリ秒までの時間を出力するかどうかを指定します。

デフォルト値

マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

前提オプション

次のどれかを指定します。

-XX:+HitachiVerboseGC

-XX:+HitachiOutOfMemoryStackTrace

-XX:+HitachiOutOfMemoryCause

-XX:+HitachiOutOfMemorySize

-XX:+HitachiJavaClassLibTrace

-XX:+JITCompilerContinuation

出力例

拡張verbosegc情報の出力

[VGC]<Wed Mar 17 00:45:55.068 2004>(Skip Full:0,Copy:0)[Full GC 149K->149K(1984K), 0.0786038 secs][DefNew::Eden: 264K->0K(512K)][DefNew::Survivor: 0K->63K(64K)][Tenured: 85K->149K(1408K)][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)]

OutOfMemoryError発生時の出力

[OOM][Thread: 0x00957820]<Wed Mar 17 00:47:00.662 2004>[java.lang.OutOfMemory Error :(C Heap) :340]

クラスライブラリトレースの出力

[CLT][Thread: 0x00286348]<Wed Mar 17 00:47:00.662 2004>
[CLT][Thread: 0x00286348] at java.lang.Shutdown.halt0(Native Method)
[CLT][Thread: 0x00286348] at java.lang.Shutdown.halt(Shutdown.java:145)

JITコンパイラ稼働継続機能（JITコンパイル失敗情報）

[JCC][Thread: 0x05432c00]<Thu Nov 15 17:10:40.347 2012>[Method: chosa_cmp.func(Ljava/lang/String;)V][Fail: 3][JITCT: 1]

-XX:[+|-]HitachiVerboseGC（拡張verbosegc情報出力オプション）

形式

-XX:+HitachiVerboseGC

GCが発生した場合，拡張verbosegc情報をJavaVMログファイルに出力します。

GCの内部領域であるEden，Survivor，Tenured，Metaspace種別の情報を拡張verbosegc情報として出力します。

-XX:-HitachiVerboseGC

GCが発生した場合，拡張verbosegc情報をJavaVMログファイルに出力しません。

説明

GCが発生したときの拡張verbosegc情報を出力するかどうかを指定します。

デフォルト値

マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

出力形式（SerialGCを使用している場合）

[id] <date> (Skip Full:full_count, Copy:copy_count) [gc_kind gc_info, gc_time secs][Eden: eden_info][Survivor: survivor_info][Tenured: tenured_info][Metaspace: metaspace_info][class space: class_space_info][cause:cause_info] [User: user_cpu secs] [Sys: system_cpu secs][IM: jvm_alloc_size, mmap_total_size, malloc_total_size][TC: thread_count][DOE: doe_alloc_size, called_count][CCI: cc_used_sizeK, cc_max_sizeK, cc_infoK]

出力内容を次に説明します。

id

VGC（JavaVMログファイル識別子）。

date

GC開始日時。

-XX:-HitachiVerboseGCPrintDateオプションが指定された場合，出力されません。

full_count

full GC情報出力をスキップした回数。

-XX:HitachiVerboseGCIntervalTimeオプションが指定された場合に出力されます。

copy_count

copy GC情報出力をスキップした回数。

-XX:HitachiVerboseGCIntervalTimeオプションが指定された場合に出力されます。

gc_kind

GC種別。"FullGC"，"GC"が出力されます。

gc_info

GC情報。次の形式で出力されます。

<GC前の領域長> -> <GC後の領域長> (<領域サイズ>)

gc_time

GC経過時間。

Eden

エデンの種別。"DefNew::Eden"または"ParNew::Eden"が出力されます。

eden_info

Eden情報。次の形式で出力されます。

<GC前の領域長> -> <GC後の領域長> (<領域サイズ>)

Survivor

Survivorの種別。"DefNew:: Survivor"または"ParNew::Survivor"が出力されます。

survivor_info

Survivor情報。次の形式で出力されます。

<GC前の領域長> -> <GC後の領域長> (<領域サイズ>)

Tenured

Tenuredの種別。"Tenured"が出力されます。

tenured_info

Tenured情報。次の形式で出力されます。

<GC前の領域長> -> <GC後の領域長> (<領域サイズ>)

metaspace_info

Metaspace領域の情報。次の形式で出力されます。

<GC前の使用サイズ>(<GC前のcapacityサイズ>, <GC前のcommitサイズ>) -> <GC後の使用サイズ>(<GC後のcapacityサイズ>, <GC後のcommitサイズ>)

class_space_info

Compressed Class Spaceの情報。次の形式で出力されます。

<GC前の使用サイズ>(<GC前のcapacityサイズ>, <GC前のcommitサイズ>) -> <GC後の使用サイズ>(<GC後のcapacityサイズ>, <GC後のcommitサイズ>)

-XX:-UseCompressedOopsオプションが指定された場合，出力されません。

cause_info

GC要因内容。

-XX:-HitachiVerboseGCPrintCauseオプションが指定された場合，出力されません。

user_cpu

GCスレッドがユーザーモードで費やしたCPU時間。単位は秒です。

CPU時間取得に失敗した場合，[User: unknown]のように，"unknown"と表示されます。

-XX:-HitachiVerboseGCCpuTimeオプションが指定された場合，出力されません。

system_cpu

GCスレッドがカーネルモードで費やしたCPU時間。単位は秒です。

CPU時間取得に失敗した場合，[Sys: unknown]のように，"unknown"と表示されます。

-XX:-HitachiVerboseGCCpuTimeオプションが指定された場合，出力されません。

jvm_alloc_size

JavaVM内部で管理している領域のうち，現在使用中の領域のサイズ（mmap_total_sizeとmalloc_total_sizeの合計サイズのうち，現在使用中の領域のサイズ）。

-XX:-HitachiVerboseGCPrintJVMInternalMemoryオプションが指定された場合，出力されません。

mmap_total_size

JavaVM内部で管理している領域のうち，mmapで割り当てたCヒープの総サイズ。

-XX:-HitachiVerboseGCPrintJVMInternalMemoryオプションが指定された場合，出力されません。

malloc_total_size

JavaVM内部で管理している領域のうち，mallocで割り当てたCヒープの総サイズ。

-XX:-HitachiVerboseGCPrintJVMInternalMemoryオプションが指定された場合，出力されません。

thread_count

Javaスレッドの数。

-XX:-HitachiVerboseGCPrintThreadCountオプションが指定された場合，出力されません。

doe_alloc_size

java.io.File.deleteOnExit()を呼び出して確保した累積のヒープサイズ。

-XX:-HitachiVerboseGCPrintDeleteOnExitオプションが指定された場合，出力されません。

called_count

java.io.File.deleteOnExit()の呼び出し回数。

-XX:-HitachiVerboseGCPrintDeleteOnExitオプションが指定された場合，出力されません。

cc_used_size

GC発生時のコードキャッシュ領域の使用サイズ。単位はキロバイトです。

-XX:-PrintCodeCacheInfoオプションが指定された場合，出力されません。

cc_max_size

コードキャッシュ領域の最大サイズ。単位はキロバイトです。

-XX:-PrintCodeCacheInfoオプションが指定された場合，出力されません。

cc_info

保守情報。

-XX:-PrintCodeCacheInfoオプションが指定された場合，出力されません。

出力形式（G1GCを使用している場合）

VG1ログ

[id]<date>[gc_kind gc_info, gc_time secs][Status: gc_status][G1GC:Eden: eden_info][G1GC:Survivor: survivor_info][G1GC:Tenured: tenured_info][G1GC:Humongous: humongous_info][G1GC:Free: free_info][Metaspace: metaspace_info][class space: class_space_info][cause:cause_info][RegionSize: region_size][Target: target_time secs][Predicted: predicted_time secs][TargetTenured: target_size][Reclaimable: reclaimable_info][User: user_cpu secs] [Sys: system_cpu secs][IM: jvm_alloc_size, mmap_total_size, malloc_total_size][TC: thread_count][DOE: doe_alloc_size, called_count][CCI: cc_used_sizeK, cc_max_sizeK, cc_infoK]

出力内容を次に説明します。

id

VG1（JavaVMログファイル識別子）。

date

GC開始日時。

-XX:-HitachiVerboseGCPrintDateオプションが指定された場合，出力されません。

gc_kind

GC種別。“Full GC”, “Mixed GC”, “Young GC”, “Young GC(initial-mark)”, “CM Remark”, “CM Cleanup”のどれかが出力されます。

gc_info

GC情報。次の形式で出力されます。

<GC前の領域サイズ>/<GC前の領域サイズ(リージョン換算)>(<GC前の領域サイズ>) -> <GC後の領域サイズ>/<GC前の領域サイズ(リージョン換算)>(<GC後の領域サイズ>)

リージョン換算とは領域サイズを1リージョンのサイズで切り上げ，1リージョンのサイズの倍数で表した値です。

gc_time

GC経過時間。

gc_status

GCの状態。“-”, “to exhausted”が出力されます。

eden_info

Eden情報。次の形式で出力されます。

<GC前の領域サイズ(リージョン換算)>(<GC前の最大領域サイズ(リージョン換算)>) -> <GC後の領域サイズ(リージョン換算)>(<GC後の最大領域サイズ(リージョン換算)>)

リージョン換算とは領域サイズを1リージョンのサイズで切り上げ，1リージョンのサイズの倍数で表した値です。

survivor_info

Survivor情報。次の形式で出力されます。

<GC前の領域サイズ(リージョン換算)> -> <GC後の領域サイズ(リージョン換算)>

リージョン換算とは領域サイズを1リージョンのサイズで切り上げ，1リージョンのサイズの倍数で表した値です。

tenured_info

Tenured情報。次の形式で出力されます。

<GC前の領域サイズ(リージョン換算)> -> <GC後の領域サイズ(リージョン換算)>

リージョン換算とは領域サイズを1リージョンのサイズで切り上げ，1リージョンのサイズの倍数で表した値です。

humongous_info

Humongous情報。次の形式で出力されます。

<GC前の領域サイズ(リージョン換算)> -> <GC後の領域サイズ(リージョン換算)>

リージョン換算とは領域サイズを1リージョンのサイズで切り上げ，1リージョンのサイズの倍数で表した値です。

free_info

Free情報。次の形式で出力されます。

<GC前の領域サイズ(リージョン換算)> -> <GC後の領域サイズ(リージョン換算)>

リージョン換算とは領域サイズを1リージョンのサイズで切り上げ，1リージョンのサイズの倍数で表した値です。

metaspace_info

Metaspace領域の情報。次の形式で出力されます。

<GC前の使用サイズ>(<GC前のcapacityサイズ>, <GC前のcommitサイズ>) -> <GC後の使用サイズ>(<GC後のcapacityサイズ>, <GC後のcommitサイズ>)

class_space_info

Compressed Class Spaceの情報。次の形式で出力されます。

<GC前の使用サイズ>(<GC前のcapacityサイズ>, <GC前のcommitサイズ>) -> <GC後の使用サイズ>(<GC後のcapacityサイズ>, <GC後のcommitサイズ>)

-XX:-UseCompressedOopsオプションが指定された場合，出力されません。

cause_info

GC要因内容。

-XX:-HitachiVerboseGCPrintCauseオプションが指定された場合，出力されません。

region_size

1リージョンのサイズです。

単位はキロバイトです。

target_time

GCによるアプリケーション停止時間の目標時間です。

単位は秒です。

predicted_time

JavaVMが予測したGCによるアプリケーション停止時間です。

単位は秒です。

なお，GC種別が“Full GC”,“CM Remark”,“CM Cleanup”のときは予測をしないため，0が出力されます。

target_size

Mixed GCでGC対象となったTenured領域のサイズです。

単位はキロバイト。

なお，GC種別が”Mixed GC”以外のときは，0が出力されます。

reclaimable_info

Mixed GCで回収されるTenured領域の予測回収サイズ情報。次の形式で出力されます。

<予測回収サイズ>（<予測回収率>）

なお，予測回収サイズ情報はCM終了直後のYoung GCまたはMixed GCだけ出力されます。それ以外の場合，予測を行わないため，0が出力されます。

user_cpu

GCスレッドがユーザーモードで費やしたCPU時間。単位は秒です。

CPU時間取得に失敗した場合，[User: unknown]のように，"unknown"と表示されます。

-XX:-HitachiVerboseGCCpuTimeオプションが指定された場合，出力されません。

system_cpu

GCスレッドがカーネルモードで費やしたCPU時間。単位は秒です。

CPU時間取得に失敗した場合，[Sys: unknown]のように，"unknown"と表示されます。

-XX:-HitachiVerboseGCCpuTimeオプションが指定された場合，出力されません。

jvm_alloc_size

JavaVM内部で管理している領域のうち，現在使用中の領域のサイズ（mmap_total_sizeとmalloc_total_sizeの合計サイズのうち，現在使用中の領域のサイズ）。

-XX:-HitachiVerboseGCPrintJVMInternalMemoryオプションが指定された場合，出力されません。

mmap_total_size

JavaVM内部で管理している領域のうち，mmapで割り当てたCヒープの総サイズ。

-XX:-HitachiVerboseGCPrintJVMInternalMemoryオプションが指定された場合，出力されません。

malloc_total_size

JavaVM内部で管理している領域のうち，mallocで割り当てたCヒープの総サイズ。

-XX:-HitachiVerboseGCPrintJVMInternalMemoryオプションが指定された場合，出力されません。

thread_count

Javaスレッドの数。

-XX:-HitachiVerboseGCPrintThreadCountオプションが指定された場合，出力されません。

doe_alloc_size

java.io.File.deleteOnExit()を呼び出して確保した累積のヒープサイズ。

-XX:-HitachiVerboseGCPrintDeleteOnExitオプションが指定された場合，出力されません。

called_count

java.io.File.deleteOnExit()の呼び出し回数。

-XX:-HitachiVerboseGCPrintDeleteOnExitオプションが指定された場合，出力されません。

cc_used_size

GC発生時のコードキャッシュ領域の使用サイズ。単位はキロバイトです。

-XX:-PrintCodeCacheInfoオプションが指定された場合，出力されません。

cc_max_size

コードキャッシュ領域の最大サイズ。単位はキロバイトです。

-XX:-PrintCodeCacheInfoオプションが指定された場合，出力されません。

cc_info

保守情報。

-XX:-PrintCodeCacheInfoオプションが指定された場合，出力されません。

VCM

[id]<date>[cm_event][User: user_cpu secs][Sys: sys_cpu secs]

id

VCM（JavaVMログファイル識別子）。

date

CM開始日時。

-XX:-HitachiVerboseGCPrintDateオプションが指定された場合，出力されません。

cm_event

CM種別。"Concurrent Root Region Scan Start"，"Concurrent Root Region Scan End "，"Concurrent Mark Start"，"Concurrent Mark End"，"Concurrent Mark Stop"，"Concurrent Cleanup Start"，"Concurrent Cleanup End"のどれかが出力されます。

user_cpu

全CMスレッドがユーザーモードで費やしたCPU時間。単位は秒です。

-XX:-HitachiVerboseGCCpuTime指定時は出力されません。

CPU時間取得に失敗した場合，[User: unknown]のように，"unknown"と表示されます。

CMの状態がStartの場合，0が出力されます。

sys_cpu

全CMスレッドがカーネルモードで費やしたCPU時間。単位は秒です。

-XX:-HitachiVerboseGCCpuTime指定時は出力されません。

CPU時間取得に失敗した場合，[Sys: unknown]のように，"unknown"と表示されます。

CMの状態がStartの場合，0が出力されます。

出力例

SerialGCを使用している場合

-XX:HitachiVerboseGCIntervalTimeオプションが指定されている場合

[VGC]<Wed Mar 17 00:42:30 2004>(Skip Full:0,Copy:0)[Full GC 149K->149K(1984K), 0.0786038 secs][DefNew::Eden: 264K->0K(512K)][DefNew::Survivor: 0K->63K(64K)][Tenured: 85K->149K(1408K)][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:System.gc][User: 0.0156250 secs][Sys: 0.0312500 secs][IM: 729K, 928K, 0K][TC: 509][DOE: 16K, 170][CCI: 2301K, 49152K, 2304K]

G1GCを使用している場合

VG1ログ

[VG1]<Thu Oct 02 10:38:56.193 2014>[Full GC 753K/2048K(8192K)->678K/1024K(8192K), 0.0097901 secs][Status:-][G1GC::Eden: 1024K(2048K)->0K(2048K)][G1GC::Survivor: 0K->0K][G1GC::Tenured: 1024K->1024K][G1GC::Humongous: 0K->0K][G1GC::Free: 6144K->7168K] [Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)] [cause:System.gc][RegionSize: 1024K][Target: 0.2000000 secs][Predicted: 0.0000000 secs][TargetTenured: 0K][Reclaimable: 0K(0.00%)][User: 0.0000000 secs][Sys: 0.0000000 secs][IM: 20459K, 21920K, 0K][TC: 35][DOE: 0K, 0][CCI: 1172K, 245760K, 2496K]

VCMログ

[VCM]<Wed Jul 24 11:45:20 2013>[Concurrent Root Region Scan Start][User: 0.0000000 secs][Sys: 0.0000000 secs]
[VCM]<Wed Jul 24 11:45:20 2013>[Concurrent Root Region Scan End][User: 0.0126134 secs][Sys: 0.0146961 secs]
[VCM]<Wed Jul 24 11:45:20 2013>[Concurrent Mark Start][User: 0.0000000 secs][Sys: 0.0000000 secs]
[VCM]<Wed Jul 24 11:45:34 2013>[Concurrent Mark End][User: 0.0156250 secs][Sys: 0.2495800 secs]

-XX:[+|-]HitachiCommaVerboseGC（CSV出力オプション）

形式

-XX:+HitachiCommaVerboseGC

拡張verbosegc情報の出力を，CSVファイルで取得できるようにコンマ形式で出力します。

拡張verbosegc情報に出力される括弧（丸括弧()，角括弧[]，山括弧<>）およびコロン（:）をすべて削除し，コンマ（,）で区切った数値または文字列を出力します。

-XX:-HitachiCommaVerboseGC

拡張verbosegc情報を通常形式で出力します。

説明

拡張verbosegc情報をCSV形式で出力するかどうかを指定します。

デフォルト値

マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

前提オプション

-XX:+HitachiVerboseGC

出力形式（SerialGCを使用している場合）

-XX:-HitachiVerboseGCIntervalTimeオプションが指定されている場合の出力内容を次に説明します。

id, date, full_count, copy_count, inc_count, gc_kind, gc_info, gc_time, eden_info, survivor_info,tenured_info, metaspace_info, classspace_info, cause_info, user_cpu, system_cpu, jvm_alloc_size, mmap_total_size, malloc_total_size, thread_count, doe_alloc_size, called_count, cc_used_size, cc_max_size, cc_info

id

JavaVMログファイル識別子。

date

GC開始日時。-XX:-HitachiVerboseGCPrintDateオプションが指定された場合，出力されません。

full_count

full GC情報出力をスキップした回数。

-XX:HitachiVerboseGCIntervalTimeオプションが指定された場合に出力されます。

copy_count

copy GC情報出力をスキップした回数。

-XX:HitachiVerboseGCIntervalTimeオプションが指定された場合に出力されます。

inc_count

0を表示。

-XX:HitachiVerboseGCIntervalTimeオプションが指定された場合に出力されます。

gc_kind

GC種別。"FullGC"または"GC"が出力されます。

gc_info

GC情報。次の形式で出力されます。単位はキロバイトです。

<GC前の領域長>,<GC後の領域長>,<領域サイズ>

gc_time

GC経過時間。単位は秒です。

eden_info

Eden情報。次の形式で出力されます。単位はキロバイトです。

<GC前の領域長>,<GC後の領域長>,<領域サイズ>

survivor_info

Survivor情報。次の形式で出力されます。単位はキロバイトです。

<GC前の領域長>,<GC後の領域長>,<領域サイズ>

tenured_info

Tenured情報。次の形式で出力されます。単位はキロバイトです。

<GC前の領域長>,<GC後の領域長>,<領域サイズ>

metaspace_info

Metaspace領域の情報。次の形式で出力されます。単位はキロバイトです。

<GC前の使用サイズ>,<GC前のcapacityサイズ>,<GC前のcommitサイズ>,<GC後の使用サイズ>,<GC後のcapacityサイズ>,<GC後のcommitサイズ>

classspace_info

Compressed Class Space情報。次の形式で出力されます。単位はキロバイトです。

<GC前の使用サイズ>,<GC前のcapacityサイズ>,<GC前のcommitサイズ>,<GC後の使用サイズ>,<GC後のcapacityサイズ>,<GC後のcommitサイズ>

cause_info

GC要因番号。

-XX:-HitachiVerboseGCPrintCauseオプションが指定された場合，出力されません。

なお，GC要因番号については，「-XX:[+|-]HitachiVerboseGCPrintCause（GC要因内容出力オプション）」を参照してください。

user_cpu

GCスレッドがユーザーモードで費やしたCPU時間。単位は秒です。

CPU時間の取得に失敗した場合は"unknown"と表示されます。

-XX:-HitachiVerboseGCCpuTimeオプションが指定された場合，出力されません。

system_cpu

GCスレッドがカーネルモードで費やしたCPU時間。単位は秒です。

CPU時間の取得に失敗した場合は"unknown"と表示されます。

-XX:-HitachiVerboseGCCpuTimeオプションが指定された場合，出力されません。

jvm_alloc_size

JavaVM内部で管理している領域のうち，現在使用中の領域のサイズ（mmap_total_sizeとmalloc_total_sizeの合計サイズのうち，現在使用中の領域のサイズ）。単位はキロバイトです。

-XX:-HitachiVerboseGCPrintJVMInternalMemoryオプションが指定された場合，出力されません。

mmap_total_size

JavaVM内部で管理している領域のうち，mmapで割り当てたCヒープの総サイズ。単位はキロバイトです。

-XX:-HitachiVerboseGCPrintJVMInternalMemoryオプションが指定された場合，出力されません。

malloc_total_size

JavaVM内部で管理している領域のうち，mallocで割り当てたCヒープ総サイズ。単位はキロバイトです。

-XX:-HitachiVerboseGCPrintJVMInternalMemoryオプションが指定された場合，出力されません。

thread_count

Javaスレッドの数。

-XX:-HitachiVerboseGCPrintThreadCountオプションが指定された場合，出力されません。

doe_alloc_size

java.io.File.deleteOnExit()を呼び出して確保した累積のヒープサイズ。単位はキロバイトです。

-XX:-HitachiVerboseGCPrintDeleteOnExitオプションが指定された場合，出力されません。

called_count

java.io.File.deleteOnExit()の呼び出し回数。

-XX:-HitachiVerboseGCPrintDeleteOnExitが指定された場合，出力されません。

cc_used_size

GC発生時のコードキャッシュ領域の使用サイズ。単位はキロバイトです。

-XX:-PrintCodeCacheInfoオプションが指定された場合，出力されません。

cc_max_size

コードキャッシュ領域の最大サイズ。単位はキロバイトです。

-XX:-PrintCodeCacheInfoオプションが指定された場合，出力されません。

cc_info

保守情報。

-XX:-PrintCodeCacheInfoオプションが指定された場合，出力されません。

-XX:+HitachiVerboseGCPrintTenuringDistributionオプションが指定されている場合の出力内容を次に説明します。

id, date, size, value, max_value, total_age1, total_age2, total_agen

出力内容については，「-XX:[+|-]HitachiVerboseGCPrintTenuringDistribution（Survivor領域の年齢分布出力オプション）」を参照してください。

出力形式（G1GCを使用している場合）

VG1ログ

id, date, gc_kind, gc_info, gc_time, gc_status, eden_info, survivor_info,tenured_info, humongous_info, free_info, metaspace_info, classspace_info, cause_info, region_size, target_time, predicted_time, target_size, reclaimable_info, user_cpu, system_cpu, jvm_alloc_size, mmap_total_size, malloc_total_size, thread_count, doe_alloc_size, called_count, cc_used_size, cc_max_size, cc_info

id

JavaVMログファイル識別子。

date

GC開始日時。-XX:-HitachiVerboseGCPrintDateオプションが指定された場合，出力されません。

gc_kind

GC種別。“Full GC”，“Mixed GC”，“Young GC”, “Young GC(initial-mark)”, “CM Remark”, “CM Cleanup”のどれかが出力されます。

gc_info

GC情報。次の形式で出力されます。単位はキロバイトです。

<GC前の領域サイズ>,<GC前の領域サイズ(リージョン換算)>,<GC前の領域サイズ>,<GC後の領域サイズ>,<GC前の領域サイズ(リージョン換算)>,<GC後の領域サイズ>

リージョン換算とは領域サイズを1リージョンのサイズで切り上げ，1リージョンのサイズの倍数で表した値です。

gc_time

GC経過時間。

gc_status

GCの状態。“-”, “to exhausted”が出力されます。

eden_info

Eden情報。次の形式で出力されます。

<GC前の領域サイズ(リージョン換算)>,<GC前の最大領域サイズ(リージョン換算)>,<GC後の領域サイズ(リージョン換算)>,<GC後の最大領域サイズ(リージョン換算)>

リージョン換算とは領域サイズを1リージョンのサイズで切り上げ，1リージョンのサイズの倍数で表した値です。

survivor_info

Survivor情報。次の形式で出力されます。

<GC前の領域サイズ(リージョン換算)>,<GC後の領域サイズ(リージョン換算)>

リージョン換算とは領域サイズを1リージョンのサイズで切り上げ，1リージョンのサイズの倍数で表した値です。

tenured_info

Tenured情報。次の形式で出力されます。

<GC前の領域サイズ(リージョン換算)>,<GC後の領域サイズ(リージョン換算)>

リージョン換算とは領域サイズを1リージョンのサイズで切り上げ，1リージョンのサイズの倍数で表した値です。

humongous_info

Humongous情報。次の形式で出力されます。

<GC前の領域サイズ(リージョン換算)>,<GC後の領域サイズ(リージョン換算)>

リージョン換算とは領域サイズを1リージョンのサイズで切り上げ，1リージョンのサイズの倍数で表した値です。

free_info

Free情報。次の形式で出力されます。

<GC前の領域サイズ(リージョン換算)>,<GC後の領域サイズ(リージョン換算)>

リージョン換算とは領域サイズを1リージョンのサイズで切り上げ，1リージョンのサイズの倍数で表した値です。

metaspace_info

Metaspace領域の情報。次の形式で出力されます。単位はキロバイトです。

<GC前の使用サイズ>,<GC前のcapacityサイズ>,<GC前のcommitサイズ><GC後の使用サイズ>,<GC後のcapacityサイズ>,<GC後のcommitサイズ>

classspace_info

Compressed Class Space情報。次の形式で出力されます。単位はキロバイトです。

<GC前の使用サイズ>,<GC前のcapacityサイズ>,<GC前のcommitサイズ><GC後の使用サイズ>,<GC後のcapacityサイズ>,<GC後のcommitサイズ>

cause_info

GC要因番号。

-XX:-HitachiVerboseGCPrintCauseオプションが指定された場合，出力されません。

なお，GC要因番号については，「-XX:[+|-]HitachiVerboseGCPrintCause（GC要因内容出力オプション）」を参照してください。

region_size

1リージョンのサイズです。

単位はキロバイトです。

target_time

GCによるアプリケーション停止時間の目標時間です。

単位は秒です。

predicted_time

JavaVMが予測したGCによるアプリケーション停止時間です。

単位は秒です。

なお，GC種別が“Full GC”, “CM Remark”, “CM Cleanup”のときは予測をしないため，0が出力されます。

target_size

Mixed GCでGC対象となったTenured領域のサイズです。

単位はキロバイト。

なお，GC種別が“Mixed GC”以外のときは，0が出力されます。

reclaimable_info

Mixed GCで回収されるTenured領域の予測回収サイズ情報。次の形式で出力されます。

<予測回収サイズ>（<予測回収率>）

なお，予測回収サイズ情報はCM終了直後のYoung GCまたはMixed GCだけ出力されます。それ以外の場合，予測を行わないため，0が出力されます。

user_cpu

GCスレッドがユーザーモードで費やしたCPU時間。単位は秒です。

CPU時間の取得に失敗した場合は"unknown"と表示されます。

-XX:-HitachiVerboseGCCpuTimeオプションが指定された場合，出力されません。

system_cpu

GCスレッドがカーネルモードで費やしたCPU時間。単位は秒です。

CPU時間の取得に失敗した場合は"unknown"と表示されます。

-XX:-HitachiVerboseGCCpuTimeオプションが指定された場合，出力されません。

jvm_alloc_size

JavaVM内部で管理している領域のうち，現在使用中の領域のサイズ（mmap_total_sizeとmalloc_total_sizeの合計サイズのうち，現在使用中の領域のサイズ）。単位はキロバイトです。

-XX:-HitachiVerboseGCPrintJVMInternalMemoryオプションが指定された場合，出力されません。

mmap_total_size

JavaVM内部で管理している領域のうち，mmapで割り当てたCヒープの総サイズ。単位はキロバイトです。

-XX:-HitachiVerboseGCPrintJVMInternalMemoryオプションが指定された場合，出力されません。

malloc_total_size

JavaVM内部で管理している領域のうち，mallocで割り当てたCヒープ総サイズ。単位はキロバイトです。

-XX:-HitachiVerboseGCPrintJVMInternalMemoryオプションが指定された場合，出力されません。

thread_count

Javaスレッドの数。

-XX:-HitachiVerboseGCPrintThreadCountオプションが指定された場合，出力されません。

doe_alloc_size

java.io.File.deleteOnExit()を呼び出して確保した累積のヒープサイズ。単位はキロバイトです。

-XX:-HitachiVerboseGCPrintDeleteOnExitオプションが指定された場合，出力されません。

called_count

java.io.File.deleteOnExit()の呼び出し回数。

-XX:-HitachiVerboseGCPrintDeleteOnExitが指定された場合，出力されません。

cc_used_size

GC発生時のコードキャッシュ領域の使用サイズ。単位はキロバイトです。

-XX:-PrintCodeCacheInfoオプションが指定された場合，出力されません。

cc_max_size

コードキャッシュ領域の最大サイズ。単位はキロバイトです。

-XX:-PrintCodeCacheInfoオプションが指定された場合，出力されません。

cc_info

保守情報。

-XX:-PrintCodeCacheInfoオプションが指定された場合，出力されません。

-XX:+HitachiVerboseGCPrintTenuringDistributionオプションが指定されている場合の出力内容を次に説明します。

id, date, size, value, max_value, total_age1, total_age2, total_agen

出力内容については，「-XX:[+|-]HitachiVerboseGCPrintTenuringDistribution（Survivor領域の年齢分布出力オプション）」を参照してください。

VCMログ

id,date,cm_event,user_cpu,sys_spu

id

VCM（JavaVMログファイル識別子）。

date

CM開始日時。

-XX:-HitachiVerboseGCPrintDateオプションが指定された場合，出力されません。

cm_event

CM種別。"Concurrent Root Region Scan Start"，"Concurrent Root Region Scan End"，"Concurrent Mark Start"，"Concurrent Mark End"，"Concurrent Mark Stop"，"Concurrent Cleanup Start"，"Concurrent Cleanup End"のどれかが出力されます。

user_cpu

全CMスレッドがユーザーモードで費やしたCPU時間。単位は秒です。

-XX:-HitachiVerboseGCCpuTime指定時は出力されません。

CPU時間取得に失敗した場合，"unknown"と表示されます。

CMの状態がStartの場合，0が出力されます。

sys_cpu

全CMスレッドがカーネルモードで費やしたCPU時間。単位は秒です。

-XX:-HitachiVerboseGCCpuTime指定時は出力されません。

CPU時間取得に失敗した場合，"unknown"と表示されます。

CMの状態がStartの場合，0が出力されます。

出力例

SerialGCを使用している場合

-XX:HitachiVerboseGCIntervalTimeオプションが指定されている場合

VGC,Fri Jan 23 21:37:50 2004,11,41,0,GC,16886,16886,65088,0.0559806,
4094,0,4096,447,447,448,12345,16439,60544,1116,1116,4096,0,0.0312500, 0.0156250,729,928,0,509,2167,2054,2301,49152,2304
VGC,Fri Jan 23 21:37:55 2004,6,24,0,Full GC,65082,65082,65088,0.4294532,
4094,4094,4096,447,447,448,60541,60541,60544,1116,1116,4096,0,0.0156250, 0.0312500,729,928,0,509,16,170,2301,49152,2304
…

-XX:+HitachiVerboseGCPrintTenuringDistributionオプションが指定されている場合

PTD,Wed May 28 11:45:23 2008,5467547,30,31,1357527,1539661

G1GCを使用している場合

VG1ログ

VG1,Thu Oct 02 10:38:54.920 2014,Full GC,753,2048,8192,678,1024,8192,0.0064767,-,1024,2048,0,2048,0,0,1024,1024,0,0,6144,7168,3634,3634,4492,3634,3634,4492,356,356,388,356,356,388,1,1024,0.2000000,0.0000000,0,0,0.00,0.0000000,0.0000000,20459,21920,0,35,0,0,1171,245760,2496

VCMログ

VCM,Fri Jul 26 21:35:50 2013,Concurrent Mark Start,0.0000000,0.0000000
VCM,Fri Jul 26 21:35:50 2013,Concurrent Mark End,0.0124532,0.0245698

-XX:HitachiVerboseGCIntervalTime（拡張verbosegc情報出力間隔指定オプション）

形式

-XX:HitachiVerboseGCIntervalTime=<整数値>

説明

拡張verbosegc情報を出力する時間（秒）の間隔を指定します。

オプションを指定した場合

拡張verbosegc情報をGCごとに出力するのではなく，指定された時間を超えた次のGCを出力します。このとき，前回の出力から今回の出力までの間に発生した，次に示すGCの回数も出力します。これらは必ず出力されます。

表5‒4　回数を出力するGCの一覧

文字列

意味

Full

FullGCをスキップした回数

Copy

CopyGCをスキップした回数

オプションを指定しない場合

0秒が設定され，GC発生ごとに拡張verbosegc情報を出力します。

デフォルト値

マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

前提オプション

-XX:+HitachiVerboseGC

引数

<整数値>

0〜2147483647の範囲の整数値（単位：秒）を指定します。範囲外の値が指定された場合は0が設定されます。負の値を指定した場合はエラーとなります。

-XX:[+|-]HitachiVerboseGCPrintCause（GC要因内容出力オプション）

形式

-XX:+HitachiVerboseGCPrintCause

GCの要因内容を，拡張verbosegc情報の行末に出力します。

-XX:-HitachiVerboseGCPrintCause

拡張verbosegc情報を通常形式で出力します。

説明

GCの要因内容を出力するかどうかを指定します。

デフォルト値

マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

前提オプション

-XX:+HitachiVerboseGC

-XX:+HitachiCommaVerboseGCオプションが指定されている場合は，次に示す要因番号が出力されます。

表5‒5　GC要因一覧

要因番号

要因内容

説明

SerialGC使用時の要因

G1GC使用時の要因

0

ObjAllocFail

G1GC未使用時，オブジェクトの割り付け失敗によってGCが発生しました。G1GC使用時，Evacuationを実施してもオブジェクト割り付け領域が確保できなかったのでGCが発生しました。

○

○

1

System.gc

java.lang.System.gcメソッド呼び出しによってGCが発生しました。

○

○

3

DelayedGC

JNIやJVMTIによって保留されていたGCが起動されました。

○

○

4

JavaGC Command

javagcコマンドによってGCが発生しました。

○

○

6

JHeapProf Command

jheapprofコマンドによってGCが発生しました。

○

−

10

JVMTIForceGC

JVMTI関数ForceGarbageCollection()によってGCが発生しました。

○

○

11

PromotionFail

CopyGCの昇格失敗によってGCが発生しました。

○

−

14

G1HumAllocFail

Humongous領域へのオブジェクト割り当て失敗によってGCが発生しました。

−

○

15

G1EvacuationPause

オブジェクト割り当て失敗によってGCが発生しました。

−

○

16

Concurrent Marking

アプリケーションを停止して実行するCM処理が発生しました。

−

○

17

EvacuationFail

Evacuation失敗によってGCが発生しました。

−

○

18

MetaspaceAllocFail

Metaspaceの領域確保失敗によってGCが発生しました。

○

○

19

LastMetaspaceGC

MetaspaceのOutOfMemoryを出す前に行う最後のGCが発生しました。

○

○

（凡例）

○：該当します。

−：該当しません。

出力例

[VGC]<Wed Mar 17 00:42:30 2004>(Skip Full:0,Copy:0)[Full GC 149K->149K(1984K), 0.0786038 secs][DefNew::Eden: 264K->0K(512K)][DefNew::Survivor: 0K->63K(64K)][Tenured: 85K->149K(1408K)][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:System.gc]

-XX:[+|-]HitachiVerboseGCPrintDate（拡張verbosegc情報日付出力オプション）

形式

-XX:+HitachiVerboseGCPrintDate

拡張verbosegc情報の各出力行の先頭にGC開始日時を出力します。

-XX:-HitachiVerboseGCPrintDate

拡張verbosegc情報の各出力行の先頭にGC開始日時を出力しません。

説明

拡張verbosegc情報にGC開始日時を出力するかどうかを指定します。

デフォルト値

マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

前提オプション

-XX:+HitachiVerboseGC

-XX:[+|-]HitachiVerboseGCCpuTime（拡張verbosegc情報CPU利用時間出力オプション）

形式

-XX:+HitachiVerboseGCCpuTime

拡張verbosegc情報に，GCの開始から終了までで，GC実行スレッドのユーザーモードおよびカーネルモードに費やされたプロセッサ時間を出力します。

-XX:-HitachiVerboseGCCpuTime

拡張verbosegc情報に，GCの開始から終了までで，GC実行スレッドのユーザーモードおよびカーネルモードに費やされたプロセッサ時間を出力しません。

説明

拡張verbosegc情報にCPU利用時間を出力するかどうかを指定します。

デフォルト値

マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

前提オプション

-XX:+HitachiVerboseGC

出力例

[VGC]<Thu Oct 02 10:38:53.658 2014>(Skip Full:1,Copy:0)[Full GC 770K->682K(8064K), 0.0050003 secs][DefNew::Eden: 88K->0K(2304K)][DefNew::Survivor: 0K->0K(256K)][Tenured: 681K->682K(5504K)] [Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)] [cause:System.gc][User: 0.0000000 secs][Sys: 0.0000000 secs]

-XX:[+|-]HitachiVerboseGCPrintTenuringDistribution（Survivor領域の年齢分布出力オプション）

形式

-XX:+HitachiVerboseGCPrintTenuringDistribution

Survivor領域の年齢分布をJavaVMログファイルへ出力します。

-XX:-HitachiVerboseGCPrintTenuringDistribution

Survivor領域の年齢分布をJavaVMログファイルへ出力しません。

説明

Survivor領域の年齢分布をJavaVMログファイルへ出力するかどうかを指定します。

デフォルト値

マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

前提オプション

-XX:+HitachiVerboseGC

関連オプション

-XX:+HitachiVerboseGCPrintDate

-XX:+HitachiCommaVerboseGC

出力形式

[id]<date>[Desired survivor:size bytes][New threshold:value][MaxTenuringThreshold: max_value][age1:total_age1][age2:total_age2]…[agen:total_agen]

出力内容を次に説明します。

id

PTD（JavaVMログファイル識別子）。

date

GC開始日時。

size

GC後のSurvivor領域内オブジェクト目標サイズ。

value

次のCopyGCでTenured領域に昇格するJavaオブジェクトの年齢のしきい値。

この値は，-XX:MaxTenuringThreshold=<value>オプションと，Survivor領域のメモリサイズ，および，-XX:TargetSurvivorRatio=<value>オプションに設定した値を基に，CopyGCごとに動的に設定されます。

value値以上の年齢のJavaオブジェクトが，次のCopyGCでTenured領域に昇格します。

max_value

CopyGCでTenured領域に昇格するJavaオブジェクトの年齢のしきい値（value値）の最大値（MaxTenuringThresholdオプションの指定値）。

value値は，CopyGCごとに動的に設定されますが，max_value値を超えることはありません。

また，年齢がmax_value値以上のJavaオブジェクトは，次のCopyGCで，必ず，Tenured領域に昇格します。

total_age1

1歳のオブジェクトのバイト数の合計。

total_age2

1歳から2歳までのオブジェクトのバイト数の合計。

total_agen

1歳からn歳までのオブジェクトのバイト数の合計。

nがmax_valueに近ければ寿命の長いオブジェクトが存在するということになります。

出力例

[PTD]<Wed Jan 28 17:47:10 2009>[Desired survivor:32768 bytes][New threshold:30][MaxTenuringThreshold:30][age1:6872][age2:9632][age3:25632]

-XX:[+|-]HitachiVerboseGCPrintJVMInternalMemory（Cヒープ情報出力オプション）

形式

-XX:+HitachiVerboseGCPrintJVMInternalMemory

JavaVM内部で管理しているヒープ情報をJavaVMログファイルへ出力します。

-XX:-HitachiVerboseGCPrintJVMInternalMemory

JavaVM内部で管理しているヒープ情報をJavaVMログファイルへ出力しません。

説明

JavaVM内部で管理しているヒープ情報をJavaVMログファイルに出力するかどうかを指定します。

Cヒープ領域のうち，次の2種類の方法で取得したヒープ領域は，JavaVM内部で管理する方式で管理されています。

mmapで取得したCヒープ領域

mallocで取得したCヒープ領域

-XX:+HitachiVerboseGCPrintJVMInternalMemoryオプションを有効にした場合，mmapで取得したCヒープの総サイズ（mmap_total_size）と，mallocで取得したCヒープの総サイズ（malloc_total_size）を出力できます。また，これらの割り当て済みの領域のうち，使用中の領域のサイズの合計値（jvm_alloc_size）も出力できます。

デフォルト値

マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

前提オプション

-XX:+HitachiVerboseGC

出力形式

[id] <date> (Skip Full:full_count, Copy:copy_count, Inc:inc_count) [gc_kind gc_info, gc_time secs][Eden: eden_info][Survivor: survivor_info][Tenured: tenured_info] [Metaspace: metaspace_info][class space: class_space_info][cause:cause_info] [User: user_cpu secs][Sys: system_cpu secs][IM: jvm_alloc_size, mmap_total_size, malloc_total_size][TC: thread_count][DOE: doe_alloc_size, called_count]

出力内容を次に示します。なお，ここでは，-XX:+HitachiVerboseGCPrintJVMInternalMemoryオプションによって出力される項目について説明します。ここで説明している以外の項目については，「-XX:[+|-]HitachiVerboseGC（拡張verbosegc情報出力オプション）」の出力形式の説明を参照してください。

jvm_alloc_size

JavaVM内部で管理している領域のうち，現在使用中の領域のサイズ（mmap_total_sizeとmalloc_total_sizeの合計サイズのうち，現在使用中の領域のサイズ）。

mmap_total_size

JavaVM内部で管理している領域のうち，mmapで割り当てたCヒープの総サイズ。

malloc_total_size

JavaVM内部で管理している領域のうち，mallocで割り当てたCヒープの総サイズ。

出力例

[VGC]<Wed Jan 27 13:03:36 2010>(Skip Full:0,Copy:0)[GC 489K->152K(3520K), 0.0156080 secs][DefNew::Eden: 489K->0K(2048K)][DefNew::Survivor: 0K->63K(64K)][Tenured: 0K->88K(1408K)][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)] [cause:ObjAllocFail][IM: 729K, 928K, 0K][TC: 509][DOE: 16K, 170]

-XX:[+|-]HitachiVerboseGCPrintThreadCount（スレッド数の出力オプション）

形式

-XX:+HitachiVerboseGCPrintThreadCount

Javaスレッドの数を出力します。

-XX:-HitachiVerboseGCPrintThreadCount

Javaスレッドの数を出力しません。

説明

Javaスレッドの数を監視するために，Javaスレッドの数をJavaVMログファイルに出力するかどうかを指定します。

スレッドは，スタックに使用するためのメモリをCヒープとして個々で確保します。このため，スレッド数が多くなると，Cヒープの確保量もスレッド数に比例して多くなります。-XX:+HitachiVerboseGCPrintThreadCountオプションを指定することで，Javaスレッドの数を監視できるようになり，Cヒープの確保量の把握ができるようになります。

デフォルト値

マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

前提オプション

-XX:+HitachiVerboseGC

出力形式

[id] <date> (Skip Full:full_count, Copy:copy_count, Inc:inc_count) [gc_kind gc_info, gc_time secs][Eden: eden_info][Survivor: survivor_info][Tenured: tenured_info][Metaspace: metaspace_info][class space: class_space_info][cause:cause_info] [User: user_cpu secs][Sys: system_cpu secs][IM: jvm_alloc_size, mmap_total_size, malloc_total_size][TC: thread_count][DOE: doe_alloc_size, called_count]

出力内容を次に示します。なお，ここでは，-XX:+HitachiVerboseGCPrintThreadCountオプションによって出力される項目について説明します。ここで説明している以外の項目については，「-XX:[+|-]HitachiVerboseGC（拡張verbosegc情報出力オプション）」の出力形式の説明を参照してください。

thread_count

Javaスレッドの数。

出力例

[VGC]<Wed Jan 27 13:03:36 2010>(Skip Full:0,Copy:0)[GC 489K->152K(3520K), 0.0156080 secs][DefNew::Eden: 489K->0K(2048K)][DefNew::Survivor: 0K->63K(64K)][Tenured: 0K->88K(1408K)][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:ObjAllocFail][IM: 729K, 928K, 0K][TC: 509]

-XX:[+|-]HitachiVerboseGCPrintDeleteOnExit（java.io.File.deleteOnExit()が使用するヒープサイズの出力オプション）

形式

-XX:+HitachiVerboseGCPrintDeleteOnExit

java.io.File.deleteOnExit()を呼び出して確保した累積のヒープサイズと，メソッドの呼び出し回数を出力します。

-XX:-HitachiVerboseGCPrintDeleteOnExit

java.io.File.deleteOnExit()を呼び出して確保した累積のヒープサイズと，メソッドの呼び出し回数を出力しません。

説明

java.io.File.deleteOnExit()を呼び出したことによってJavaVMが確保した累積のヒープサイズとメソッドの呼び出し回数を，JavaVMログファイルに出力するかどうかを指定します。

java.io.File.deleteOnExit()は，呼び出すたびに指定されたファイルのパス情報をヒープに確保しますが，確保した領域はプロセスの終了まで解放しないため，メモリの圧迫につながるおそれがあります。-XX:+HitachiVerboseGCPrintDeleteOnExitオプションを指定すると，JavaVMがjava.io.File.deleteOnExit()を呼び出して確保したヒープサイズをログに出力して監視できるようになります。また，java.io.File.deleteOnExit()の呼び出し状況を把握するための補助的な情報として，メソッドの呼び出し回数も同時に出力できます。

出力した情報は，障害発生時，java.io.File.deleteOnExit()の呼び出しによって確保されたヒープサイズを把握してメモリ不足の原因を調査するために役立てられます。また，運用開始前の開発やテスト段階で，java.io.File.deleteOnExit()の呼び出しによって確保したヒープサイズの増加の推移を確認して，運用時にメモリを圧迫する予兆がないかを事前確認するためにも利用できます。

なお，エラーが発生した場合は，エラーメッセージが出力されます。

デフォルト値

マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

前提オプション

-XX:+HitachiVerboseGC

出力形式

JavaVMログファイルの出力形式を次に示します。

[id] <date> (Skip Full:full_count, Copy:copy_count, Inc:inc_count) [gc_kind gc_info, gc_time secs][Eden: eden_info][Survivor: survivor_info][Tenured: tenured_info] [Metaspace: metaspace_info][class space: class_space_info][cause:cause_info] [User: user_cpu secs][Sys: system_cpu secs][IM: jvm_alloc_size, mmap_total_size, malloc_total_size][TC: thread_count][DOE: doe_alloc_size, called_count]

出力内容を次に示します。なお，ここでは，-XX:+HitachiVerboseGCPrintDeleteOnExitオプションによって出力される項目について説明します。ここで説明している以外の項目については，「-XX:[+|-]HitachiVerboseGC（拡張verbosegc情報出力オプション）」の出力形式の説明を参照してください。

doe_alloc_size

java.io.File.deleteOnExit()を呼び出して確保した累積のヒープサイズ。

called_count

java.io.File.deleteOnExit()の呼び出し回数。

エラーが発生した場合のエラーメッセージの出力形式を次に示します。

[DOE]<date>Error occurred during processing of java.io.File.deleteOnExit's heap size output function. (<保守情報>)
[DOE]java.io.File.deleteOnExit's heap size output function stopped.

エラーメッセージの出力内容を次に示します。

DOE

java.io.File.deleteOnExit()のヒープサイズ出力機能でエラーが発生したことを示す識別子。

date

エラーが発生した日時。

出力例

JavaVMログファイルの出力例を次に示します。

[VGC]<Wed Jan 27 13:03:36 2010>(Skip Full:0,Copy:0)[GC 489K->152K(3520K), 0.0156080 secs][DefNew::Eden: 489K->0K(2048K)][DefNew::Survivor: 0K->63K(64K)][Tenured: 0K->88K(1408K)][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:ObjAllocFail][IM: 729K, 928K, 0K] [TC: 509][DOE: 16K, 170]

エラーメッセージの出力例を次に示します。

[DOE]<Wed Jan 27 13:03:36 2010> Error occurred during processing of java.io.File.deleteOnExit's heap size output function. (FindClass:java.lang.String)
[DOE]java.io.File.deleteOnExit's heap size output function stopped.

注意事項

次の場合は，java.io.File.deleteOnExit()を呼び出しても累積のヒープサイズ，メソッドの呼び出し回数がカウントされません。

java.io.File.deleteOnExit()を呼び出した場合にSecurityException例外が発生したとき（この例外はセキュリティマネージャのSecurityManager.checkDelete()がファイルへの削除アクセスを許可しない場合に発生します。この場合，メソッドの入り口で例外が挙がり，ヒープは確保されません）。

アプリケーションサーバのバッチアプリケーション実行基盤で作成されたアプリケーションから呼び出した場合。

同一のパス名文字列で作成したFileインスタンスを使用してjava.io.File.deleteOnExit()を呼び出したとき。

この機能が出力するヒープサイズを確認する際には，次の点に注意してください。

java.io.File.deleteOnExit()が確保するヒープの種類はJavaヒープです。

ヒープサイズはキロバイト単位で出力され，1キロバイト未満は切り捨てられます。java.io.File.deleteOnExit()の1回の呼び出しで確保するヒープサイズは，ファイルパスの長さに応じて数十バイトから100バイト程度であるため，呼び出しごとにヒープサイズの出力結果が増加しないことがあります。この場合，メソッドの呼び出し回数からメソッドの実行を確認できます。

-XX:[+|-]PrintCodeCacheInfo（コードキャッシュ領域情報出力オプション）

形式

-XX:+PrintCodeCacheInfo

コードキャッシュ領域の使用量を出力します。

また，コードキャッシュ領域の使用量がしきい値に達したことを知らせるメッセージを出力します。

-XX:-PrintCodeCacheInfo

コードキャッシュ領域の使用量を出力しません。

また，コードキャッシュ領域の使用量がしきい値に達したことを知らせるメッセージを出力しません。

説明

コードキャッシュ領域の使用量を出力するかどうか，また，使用量がしきい値に達したことを知らせるメッセージをJavaVMログファイルに出力するかどうかを指定します。

コードキャッシュ領域については，「2.2.1(5)　SerialGC使用時のJavaVMで使用するメモリ空間の構成とJavaVMオプション」を参照してください。

このオプションを有効にすると，GC発生時，コードキャッシュ領域の使用量が拡張verbosegc情報に出力されます。また，コードキャッシュ領域の使用量がしきい値に達したとき，メッセージが出力されます。

しきい値は「コードキャッシュ領域の最大サイズ×-XX:CodeCacheInfoPrintRatioオプションの値÷100」です。

-XX:-HitachiVerboseGCオプションを指定している場合でも，javagcコマンドの-vオプションや-sオプションによって出力する拡張verbosegc情報には，コードキャッシュ領域の使用量が出力されます。

デフォルト値

マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

前提オプション

-XX:+HitachiVerboseGC

関連オプション

-XX:+HitachiCommaVerboseGC

-XX:CodeCacheInfoPrintRatio

出力形式

コードキャッシュ領域の使用量の出力形式を次に示します。

[id] <date> (Skip Full:full_count, Copy:copy_count, Inc:inc_count) [gc_kind gc_info, gc_time secs][Eden: eden_info][Survivor: survivor_info][Tenured: tenured_info] [Metaspace: metaspace_info][class space: class_space_info][cause:cause_info] [User: user_cpu secs][Sys: system_cpu secs][IM: jvm_alloc_size, mmap_total_size, malloc_total_size][TC: thread_count][DOE: doe_alloc_size, called_count][CCI: cc_used_sizeK, cc_max_sizeK, cc_infoK]

出力内容を次に示します。なお，ここでは，-XX:+PrintCodeCacheInfoオプションによって出力される項目について説明します。ここで説明している以外の項目については，「-XX:[+|-]HitachiVerboseGC（拡張verbosegc情報出力オプション）」の出力形式の説明を参照してください。

cc_used_size

GC発生時のコードキャッシュ領域の使用サイズ。単位はキロバイトです。

cc_max_size

コードキャッシュ領域の最大サイズ。単位はキロバイトです。

cc_info

保守情報。

コードキャッシュ領域の使用量がしきい値に達したことを知らせるメッセージの出力形式を次に示します。

[cc_id]<cc_date>CodeCache usage has exceeded the threshold.[cc_used_sizeK, cc_max_sizeK, cc_infoK]

メッセージの出力内容を次に示します。

cc_id

CCI（JavaVMログファイル識別子）。

cc_date

JITコンパイルを実行した日時。

cc_used_size

JITコンパイル後のコードキャッシュ領域の使用サイズ。単位はキロバイトです。

cc_max_size

コードキャッシュ領域の最大サイズ。単位はキロバイトです。

cc_info

保守情報。

出力例

コードキャッシュ領域の使用量の出力例を次に示します。

[VGC]<Wed Mar 17 00:42:30 2004>(Skip Full:0,Copy:0)[Full GC 149K->149K(1984K), 0.0786038 secs][DefNew::Eden: 264K->0K(512K)][DefNew::Survivor: 0K->63K(64K)][Tenured: 85K->149K(1408K)][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:System.gc][User: 0.0156250 secs][Sys: 0.0312500 secs][IM: 729K, 928K, 0K][TC: 509][DOE: 16K, 170][CCI: 2301K, 49152K, 2304K]

コードキャッシュ領域の使用量がしきい値に達したことを知らせるメッセージの出力例を次に示します。

[CCI]<Wed Dec 26 14:27:53 2012>CodeCache usage has exceeded the threshold.[39358K, 49152K, 39360K]

注意事項

コードキャッシュ領域の使用量がしきい値に達した状態で推移している場合，JavaメソッドがJITコンパイルされてもメッセージは出力されません。

一方，コードキャッシュ領域の使用量がしきい値未満まで下がったあと，JavaメソッドがJITコンパイルされたことによって再びコードキャッシュ領域の使用量がしきい値に達した場合には，メッセージが出力されます。

システムが使用するコードキャッシュ領域は最大2メガバイトです。そのため，システムのコードキャッシュ領域の使用量によっては，コードキャッシュ領域を最大サイズまで使用していない場合でも，コードキャッシュ領域が枯渇することがあります。

また，コードキャッシュ領域の使用量のしきい値に大きな値を指定している場合，メッセージを出力する前にコードキャッシュ領域が枯渇する場合があります。コードキャッシュ領域が枯渇する前にメッセージを出力したいときは，「コードキャッシュ領域の最大サイズ−しきい値」の値が4メガバイト以上になるように，「-XX:CodeCacheInfoPrintRatio（コードキャッシュ領域使用率指定オプション）」の値を指定してください。

-XX:CodeCacheInfoPrintRatio（コードキャッシュ領域使用率指定オプション）

形式

-XX:CodeCacheInfoPrintRatio=<整数値>

説明

コードキャッシュ領域の使用量がしきい値に達したことを知らせるメッセージを出力する契機となる，コードキャッシュ領域の使用率を指定します。

ここで指定した使用率を基に，次の計算式でしきい値が計算されます。

コードキャッシュ領域の最大サイズ×-XX:CodeCacheInfoPrintRatioオプションの値÷100

コードキャッシュ領域については，「2.2.1(5)　SerialGC使用時のJavaVMで使用するメモリ空間の構成とJavaVMオプション」を参照してください。

デフォルト値

マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

前提オプション

-XX:+PrintCodeCacheInfo

引数

<整数値>

0〜100の範囲で整数値（単位：％）を指定します。範囲外の値が指定された場合は80が設定されます。

-XX:[+|-]PrintCodeCacheFullMessage（コードキャッシュ領域枯渇メッセージ出力オプション）

形式

-XX:+PrintCodeCacheFullMessage

JavaメソッドがJITコンパイルの対象になった場合，コードキャッシュ領域が枯渇していたときにメッセージを出力します。メッセージは一度だけ出力されます。

-XX:-PrintCodeCacheFullMessage

JavaメソッドがJITコンパイルの対象になった場合，コードキャッシュ領域が枯渇してもメッセージを出力しません。

説明

JavaメソッドがJITコンパイルの対象になった場合，コードキャッシュ領域が枯渇していたときに，メッセージをJavaVMログファイルに出力するかどうかを指定します。

コードキャッシュ領域については，「2.2.1(5)　SerialGC使用時のJavaVMで使用するメモリ空間の構成とJavaVMオプション」を参照してください。

デフォルト値

マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

前提オプション

-XX:+HitachiVerboseGC

出力形式

メッセージの出力形式を次に示します。

[cc_id]<cc_date>CodeCache is full. Compiler has been disabled.[cc_used_sizeK, cc_max_sizeK, cc_infoK]

メッセージの出力内容を次に示します。

cc_id

CCI（JavaVMログファイル識別子）。

cc_date

JavaメソッドがJITコンパイルの対象になった日時。

cc_used_size

JavaメソッドがJITコンパイルの対象になったときのコードキャッシュ領域の使用サイズ。単位はキロバイトです。

cc_max_size

コードキャッシュ領域の最大サイズ。単位はキロバイトです。

cc_info

保守情報。

出力例

メッセージの出力例を次に示します。

[CCI]<Wed Dec 26 14:38:29 2012>CodeCache is full. Compiler has been disabled.[49151K, 49152K, 49152K]

注意事項

システムが使用するコードキャッシュ領域は最大2メガバイトです。そのため，システムのコードキャッシュ領域の使用量によっては，コードキャッシュ領域を最大サイズまで使用していない場合でも，コードキャッシュ領域が枯渇することがあります。

-XX:[+|-]HitachiOutOfMemoryCause（例外発生要因種別出力オプション）

形式

-XX:+HitachiOutOfMemoryCause

OutOfMemoryError発生時に，例外発生要因種別をJavaVMログファイルに出力します。-XX:+HitachiOutOfMemoryStackTraceオプションが指定されている場合は，このオプションも設定されます。

出力される要因種別を次に示します。

表5‒6　例外発生要因種別一覧

項番

要因メッセージ

説明

1

C Heap

Cヒープ確保時の例外

2

Java Heap

Javaヒープ確保時の例外

3

Meta Space

Metaspace領域確保時の例外

4

Compressed Class Space

Compressed Class Space確保時の例外

5

Unknown

上記例外を特定できない場合

6

Thread Limit

スレッド数の上限値設定機能（-XX:HitachiThreadLimitオプション）を指定した場合に，作成したスレッド数が指定した上限値を超えたときの例外

-XX:-HitachiOutOfMemoryCause

OutOfMemoryError発生時に，例外発生要因種別をJavaVMログファイルに出力しません。

説明

OutOfMemoryError発生時の発生要因種別を出力するかどうかを指定します。

デフォルト値

マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

出力例

スレッド数の上限値設定機能（HitachiThreadLimitオプション）を指定していて，作成したスレッド数が指定した上限値を超えた結果，OutOfMemoryErrorをスローする場合の例を示します。

[OOM][Thread: 0x00062fd0]<Tue Dec 2 16:42:39 2003>[java.lang.OutOfMemoryError :(C Heap) : unable to create thread : 340 threads exist]

-XX:[+|-]HitachiOutOfMemoryStackTrace（スタックトレース出力オプション）

形式

-XX:+HitachiOutOfMemoryStackTrace

OutOfMemoryError発生時に，例外情報とスタックトレースをJavaVMログファイルに出力します。

スタックトレースは1スタックごとにバッファに格納し，コード変換したあとに出力します。スタックトレースの出力は，OutOfMemoryErrorがスローされるたびに行われるため，OutOfMemoryErrorをキャッチして再スローした場合には複数回出力されます。なお，スレッド作成時にOutOfMemoryErrorとなった場合は，スタックトレースは出力されません。

-XX:-HitachiOutOfMemoryStackTrace

OutOfMemoryError発生時に，スタックトレースをJavaVMログファイルに出力しません。

説明

OutOfMemoryError発生時に，例外情報とスタックトレースをJavaVMログファイルに出力するかどうかを指定します。

デフォルト値

マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

出力形式

[id] [Thread:thread_id]<date>[java.lang.OutOfMemoryError : requested size bytes (cause) : reason : thread_count threads exist]
[id] [Thread:thread_id] stack_trace

出力内容を次に説明します。

id

OOM（JavaVMログファイル識別子）。

thread_id

スレッドID（スレッドダンプに出力されているtid）。

date

OutOfMemory例外発生日時。

size

確保しようとしたメモリのサイズ（単位：バイト）が出力されます。-XX:-HitachiOutOfMemorySizeオプションが指定されている場合，出力されません。

なお，次の場合は要求したメモリサイズが取り出せません。これらの場合は，サイズとして「unknown」が出力されます。

Javaのメモリ確保機能を使用しないで，明示的にOutOfMemoryErrorをスローした場合

標準クラスライブラリによってスローされるものも含みます。例えば，「throw new OutOfMemoryError();」などの処理によってスローされた場合，メモリサイズは出力できません。

クラスロード時のverifierによってOutOfMemoryErrorが発生した場合

cause

例外発生要因種別。ただし，-XX:-HitachiOutOfMemoryCauseオプションが指定されている場合は出力されません。例外発生要因種別については，「-XX:[+|-]HitachiOutOfMemoryCause（例外発生要因種別出力オプション）」を参照してください。

reason

例外発生理由。スレッドの作成に失敗した場合に出力されます。

thread_count

OutOfMemoryError発生時のスレッド数。作成に失敗したスレッド数も含みます。

stack_trace

スタックトレース。

出力例

[OOM][Thread: 0x00062fd0] <Wed Mar 17 00:41:17 2004>[java.lang.OutOfMemoryError :requested 400000 bytes.(C Heap): unable to create thread : 1500 threads exist]
[OOM][Thread: 0x00062fd0] at java.lang.Thread.start(Native Method)
[OOM][Thread: 0x00062fd0] at sub1.<init>(Thread0012.java:22)
[OOM][Thread: 0x00062fd0] at Thread0012.test01(Thread0012.java:73)
[OOM][Thread: 0x00062fd0] at Thread0012.main(Thread0012.java:57)

注意事項

JavaVM自身で作成するスレッドが，メモリ不足によってスレッドの作成に失敗した場合は，例外情報だけが出力されます。スタックトレースは出力されません。

-XX:HitachiOutOfMemoryStackTraceLineSize（スタックトレース行サイズ指定オプション）

形式

-XX:HitachiOutOfMemoryStackTraceLineSize=<整数値>

説明

OutOfMemoryError発生時に，出力するスタックトレース1行の文字数をバイト数で指定します。オプションの指定がない場合は，1024バイトが設定されます。指定したバイト数が確保できない場合は警告メッセージが出力され，スタックトレースは出力されません。また，1行の文字数が指定した文字数を超えた場合，「at」以降の文字列の前半部分を削除して，指定された文字数分出力します。

デフォルト値

マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

前提オプション

-XX:+HitachiOutOfMemoryStackTrace

引数

<整数値>

1024〜2147483647の範囲で整数値（単位：バイト）を指定します。範囲外の値が指定された場合は1024が設定されます。負の値を指定した場合はエラーとなります。

注意事項

非同期ログ出力（-XX:+JavaLogAsynchronous）が有効な場合，-XX:HitachiOutOfMemoryStackTraceLineSizeに4096より大きな値を指定しても，4096が設定されます。

-XX:[+|-]HitachiOutOfMemorySize（メモリサイズ出力オプション）

形式

-XX:+HitachiOutOfMemorySize

OutOfMemoryError発生時に，要求したメモリサイズをバイト単位で出力します。

-XX:+HitachiOutOfMemoryStackTraceオプションが指定されている場合は，このオプションも設定されます。

-XX:-HitachiOutOfMemorySize

OutOfMemoryError発生時に，要求したメモリサイズを出力しません。

説明

OutOfMemoryError発生時に要求したメモリのサイズを出力します。

デフォルト値

マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

出力例

[OOM][Thread: 0x00062fd0]<Tue Dec 2 16:42:39 2003>[java.lang.OutOfMemoryError :　 requested 1024 bytes. (Java Heap) : 20 threads exist]

注意事項

次の場合，要求したメモリサイズが取り出せません。

Javaのメモリ確保機能を使用してなくて，明示的にOutOfMemoryErrorをスローした（Java SEクラスライブラリがスローするものを含みます）場合。

例:throw new OutOfMemoryError();

クラスロード時のverifierがOutOfMemoryErrorを発生させた場合。

[OOM][Thread: 0x00062fd0]<Tue Dec 2 16:42:39 2003>[java.lang.OutOfMemoryError :　 requested size unknown. (Unknown) : 10 threads exist]

-XX:[+|-]HitachiOutOfMemoryAbort（強制終了オプション）

形式

-XX:+HitachiOutOfMemoryAbort

OutOfMemoryError発生時にメモリダンプを出力して，強制終了します。

-XX:-HitachiOutOfMemoryAbort

OutOfMemoryError発生時に強制終了しません。

説明

次の原因でOutOfMemoryErrorが発生した場合，標準出力にメッセージを，カレントディレクトリにメモリダンプまたはcoreダンプを出力して強制終了します。

Javaヒープ不足の場合

Metaspace領域不足の場合

Compressed Class Space不足の場合

Java SEクラスライブラリ中でのCヒープ不足の場合

なお，JavaVM処理中にCヒープ不足となった場合には，このオプションの指定に関係なく，強制停止します。

強制終了時の終了コード

強制終了した場合のJavaVMの終了コードは6です。

なお，UNIXのシェル（shやcshなど）上で実行したとき，終了コードは0x80が加算されて0x86となります。

デフォルト値

マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

出力例

java.lang.OutOfMemoryError occurred.
JavaVM aborted because of specified -XX:+HitachiOutOfMemoryAbort options.

注意事項

-XX:+HitachiOutOfMemoryStackTraceオプションが指定されている場合は，JavaVMログファイルにスタックトレースを出力したあとに終了します。

このオプションが指定されている場合，java.io.File.deleteOnExitメソッドやjava.lang.Runtime.addShutdownHookメソッドで登録している，JavaVM終了時の処理は実行されないで強制終了します。

-XX:[+|-]HitachiOutOfMemoryAbortThreadDump（スレッドダンプ出力オプション）

形式

-XX:+HitachiOutOfMemoryAbortThreadDump

OutOfMemoryError発生時にスレッドダンプを出力します。

-XX:+HitachiOutOfMemoryAbortオプションが指定されている場合に，このオプションは指定できます。

-XX:-HitachiOutOfMemoryAbortThreadDump

OutOfMemoryError発生時にスレッドダンプを出力しません。

説明

OutOfMemoryError発生時にスレッドダンプを出力します。ただし，Java SEクラスライブラリでCヒープ不足の場合は，スレッドダンプの出力による再度のCヒープ不足発生を避けるため，スレッドダンプは出力しません。

スレッドダンプの出力先は環境変数JAVACOREDIR，または-XX:+HitachiThreadDumpToStdoutオプションで指定します。

デフォルト値

マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

前提オプション

-XX:+HitachiOutOfMemoryAbort

-XX:+HitachiThreadDump

-XX:[+|-]HitachiOutOfMemoryAbortThreadDumpWithJHeapProf（クラス別統計情報出力オプション）

形式

-XX:+HitachiOutOfMemoryAbortThreadDumpWithJHeapProf

-XX:+HitachiOutOfMemoryAbortThreadDumpで出力するスレッドダンプログファイルにクラス別統計情報を出力します。

-XX:-HitachiOutOfMemoryAbortThreadDumpWithJHeapProf

-XX:+HitachiOutOfMemoryAbortThreadDumpで出力するスレッドダンプログファイルにクラス別統計情報を出力しません。

説明

-XX:+HitachiOutOfMemoryAbortThreadDumpで出力するスレッドダンプログファイルにクラス別統計情報を出力するかどうかを指定します。

デフォルト値

マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

前提オプション

-XX:+HitachiOutOfMemoryAbort

-XX:+HitachiOutOfMemoryAbortThreadDump

-XX:+HitachiThreadDump

注意事項

-XX:+HitachiOutOfMemoryAbortThreadDumpWithJHeapProfオプションはOutOfMemory発生時に出力されるスレッドダンプに，クラス別統計情報を出力するためのオプションです。G1GCを使用した場合，クラス別統計機能が使用できないため，このオプションも使用できません。G1GC使用時にこのオプションを指定した場合，スレッドダンプは出力されますが，クラス別統計情報は出力されません。

-XX:[+|-]HitachiOutOfMemoryHandling（OutOfMemoryハンドリングオプション）

形式

-XX:+HitachiOutOfMemoryHandling

OutOfMemoryハンドリング機能を有効にします。

-XX:-HitachiOutOfMemoryHandling

OutOfMemoryハンドリング機能を無効にします。

説明

OutOfMemoryハンドリング機能を有効にするかどうかを指定します。

OutOfMemoryハンドリング機能は，OutOfMemory発生時強制終了機能（-XX:+HitachiOutOfMemoryAbort）と組み合わせて使用します。OutOfMemory発生時強制終了機能が無効（-XX:-HitachiOutOfMemoryAbort）になっている場合，OutOfMemoryハンドリング機能は無効になります。

OutOfMemoryハンドリング機能を有効にした場合，OutOfMemory発生時にOutOfMemoryErrorスロー条件が判定されます。具体的には，次に示す処理を実行中にJavaヒープ不足やMetaspace領域，Compressed Class Space不足が原因のOutOfMemoryが発生した場合に，アプリケーションサーバの実行を継続するかどうかが判定されます。

Webコンテナ上のWebアプリケーション（Servlet／JSP）が実行中のリクエスト処理

EJBクライアントアプリケーションから呼び出されたEnterprise Beanが実行中の処理

Message-driven Beanが実行中の処理

Timer Serviceから呼び出されたEnterprise Beanが実行中の処理

判定の結果，アプリケーションサーバの実行が継続される場合は，java.lang.OutOfMemoryErrorがスローされて，OutOfMemoryが発生したリクエスト処理だけが中止されます。

JavaVMは，判定結果によって次のように動作します。ただし，Webアプリケーションでjava.lang.OutOfMemoryErrorをキャッチしている場合は，その処理に従います。

OutOfMemoryErrorスロー条件を満たしている場合

java.lang.OutOfMemoryErrorをスローして，OutOfMemoryが発生したリクエスト処理だけを中止します。

OutOfMemoryErrorスロー条件を満たしていない場合

OutOfMemory発生時強制終了機能によって，JavaVMを強制終了します。

OutOfMemoryErrorスロー条件を次に示します。なお，OutOfMemoryErrorスロー条件に合致しない場合，OutOfMemory発生時強制終了機能によって，JavaVMは強制終了します。

OutOfMemoryErrorスロー条件

OutOfMemoryが発生した場合に，次に示す条件すべてに該当するとき，JavaVMはOutOfMemoryErrorスロー条件を満たしているものと判定して，異常終了しないでjava.lang.OutOfMemoryErrorをスローします。

Javaヒープ不足，またはMetaspace領域，Compressed Class Space不足が原因のOutOfMemoryである。

Webコンテナ上のWebアプリケーション（Servlet／JSP）が実行中のリクエスト処理，EJBクライアントアプリケーションから呼び出されたEnterprise Beanが実行中の処理，Message-driven Beanが実行中の処理，またはTimer Serviceから呼び出されたEnterprise Beanが実行中の処理で発生したOutOfMemoryである。

OutOfMemoryErrorスロー除外条件に該当しない。

OutOfMemoryErrorスロー除外条件

今回のOutOfMemoryが発生した時刻から過去1時間以内のJavaヒープ不足が原因のOutOfMemoryの発生回数とMetaspace領域，Compressed Class Space不足が原因のOutOfMemoryの発生回数の合計値（今回のOutOfMemoryを含む）が，-XX:HitachiOutOfMemoryHandlingMaxThrowCountオプション値に指定した値よりも大きい。

OutOfMemory発生時強制終了機能とOutOfMemoryハンドリング機能のOutOfMemory発生要因ごとの動作を次の表に示します。OutOfMemoryハンドリング機能が有効かどうかは，OutOfMemoryの発生原因がJavaヒープ不足またはMetaspace領域，Compressed Class Space不足の場合の動作に影響します。

表5‒7　OutOfMemory発生時強制終了機能とOutOfMemoryハンドリング機能のOutOfMemory発生要因ごとの動作

OutOfMemory発生要因

OutOfMemory発生時強制終了機能の対象となるかどうか

（OutOfMemory発生時の動作※1）

OutOfMemoryハンドリング機能の対象となるかどうか

（OutOfMemory発生時の動作）

Javaヒープ不足

対象になります

（JavaVMは強制終了します）。

対象になります

（判定結果に従って動作します※2）。

Metaspace領域不足

対象になります

（JavaVMは強制終了します）。

対象になります

（判定結果に従って動作します※2）。

Compressed Class Space不足

対象になります

（JavaVMは強制終了します）。

対象になります

（判定結果に従って動作します※2）。

Cヒープ不足

対象になります

（JavaVMは強制終了します）。

対象になりません

（JavaVMは強制終了します※3）。

Unknown

対象になりません

（java.lang.OutOfMemoryErrorがスローされます）。

対象になりません

（java.lang.OutOfMemoryErrorがスローされます）。

Thread Limit

対象になりません

（java.lang.OutOfMemoryErrorがスローされます）。

対象になりません

（java.lang.OutOfMemoryErrorがスローされます）。

注※1　OutOfMemoryハンドリング機能は無効（-XX:-HitachiOutOfMemoryHandling）の場合の動作です。

注※2　OutOfMemoryErrorスロー条件を満たしている場合，java.lang.OutOfMemoryErrorがスローされます。OutOfMemoryErrorスロー条件を満たしていない場合，OutOfMemory発生時強制終了機能の処理に移行して，JavaVMは強制終了します。

注※3　OutOfMemory発生時強制終了機能によって，JavaVMは強制終了します。

また，OutOfMemoryハンドリング機能が有効な場合，Javaヒープ不足，およびMetaspace領域，Compressed Class Space不足が原因のOutOfMemory発生時にOutOfMemoryの発生頻度に関する情報がJavaVMログファイルに出力されます。

デフォルト値

マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

前提オプション

-XX:+HitachiOutOfMemoryAbort

出力形式

[id][Thread: thread_id]<date>[Handling: oom_count(max_oom_count)]

出力内容を次に説明します。

id

OMH（JavaVMログファイル識別子）。

thread_id

スレッドID（スレッドダンプに出力されているtid）。

date

OutOfMemoryをハンドリングした日時。

oom_count

今回のOutOfMemoryが発生した時刻から過去1時間以内の，Javaヒープ不足が原因のOutOfMemoryの発生回数とMetaspace領域，Compressed Class Space不足が原因のOutOfMemoryの発生回数の合計値（今回のOutOfMemoryを含む）。

ただし，今回のOutOfMemoryも含めて，1時間以内の発生回数の合計値が3601を超えた場合でも，出力項目の最大値は3601になります。

max_oom_count

-XX:HitachiOutOfMemoryHandlingMaxThrowCountオプションに指定した値。

出力例

[OMH][Thread: 0x00927f48]<Tue Aug 24 19:02:19 2010>[Handling: 1(60)]

注意事項

OutOfMemoryハンドリング機能は，OutOfMemoryの根本原因を解決したり，OutOfMemory発生によるアプリケーションサーバの終了を確実に回避したりする機能ではありません。また，OutOfMemory発生後にアプリケーションサーバの実行を継続できることを確実に保証する機能でもありません。この機能は，ユーザープログラム処理の問題による突発的なOutOfMemoryが発生した場合に，アプリケーションサーバの終了を一時的に防ぐための機能です。

java.lang.OutOfMemoryErrorは，OutOfMemoryハンドリング機能の設定に関係なく，ヒープが枯渇している場合に発生します。java.lang.OutOfMemoryErrorが発生した場合には，アプリケーションサーバをできるだけ速やかに再起動して回復すること，そのあとでOutOfMemoryの根本原因を解決することを推奨します。

なお，java.lang.OutOfMemoryErrorをスローすることによって，リソースのリークやロックなどが発生し，アプリケーションサーバに予期しない動作が発生するおそれがあります。このため，この機能を有効にしている場合にOutOfMemoryが発生したときには，適切なタイミングでアプリケーションサーバを再起動する運用にしてください。また，アプリケーションサーバに予期しない動作が発生することを避けたい場合は，この機能を無効にしてください。この場合，突発的なOutOfMemoryが発生したときには，アプリケーションサーバは終了します。

この機能を有効にした場合に，予期しない動作になってしまったときは，アプリケーションサーバを再起動してください。また，その後の運用ではこの機能を無効にしてください。

OutOfMemoryハンドリング機能が有効な場合，OutOfMemory発生時強制終了機能が有効（-XX:+HitachiOutOfMemoryAbort）でも，jspやServletでの処理中にOutOfMemoryが発生したときは，強制終了しないでJava SEの仕様どおりにjava.lang.OutOfMemoryErrorがスローされます。

そのため，例えば，finally節を使用して適切にリソースを解放していないようなときには，リソースの解放漏れなどが発生することがあります。

このような問題を避けて，従来どおり強制終了させたい場合は，OutOfMemoryハンドリング機能を無効にしてください。

-XX:HitachiOutOfMemoryHandlingMaxThrowCount（最大発生回数の設定オプション）

形式

-XX:HitachiOutOfMemoryHandlingMaxThrowCount=<整数値>

説明

OutOfMemoryハンドリング機能を有効にした場合の，Javaヒープ不足またはMetaspace領域，Compressed Class Space不足が原因のOutOfMemory発生回数合計値の1時間当たりの上限値を指定します。

このオプションで指定した値は，OutOfMemoryErrorスロー除外条件の判定で使用されます。

Javaヒープ不足またはMetaspace領域，Compressed Class Space不足が原因のOutOfMemoryが発生した場合，次のように処理が実行されます。

今回のOutOfMemoryが発生した時刻から過去1時間以内のJavaヒープ不足が原因のOutOfMemoryの発生回数とMetaspace領域，Compressed Class Space不足が原因のOutOfMemoryの発生回数の合計値（今回のOutOfMemoryを含む）が，このオプションに指定した上限値よりも大きい場合，OutOfMemoryErrorはスローされません。OutOfMemory発生時強制終了機能（-XX:+HitachiOutOfMemoryAbort）の処理に移行して，JavaVMは強制終了します。

このオプションの値として0を指定した場合は，OutOfMemoryが発生したときに必ずOutOfMemory発生時強制終了機能の処理に移行して，JavaVMは強制終了します。

このオプションの値として3600を指定した場合は，OutOfMemoryErrorスロー除外条件の判定が実行されません。この場合，OutOfMemoryが発生したときにOutOfMemoryErrorスロー除外条件以外のOutOfMemoryErrorスロー条件を満たしている場合，必ずjava.lang.OutOfMemoryErrorがスローされます。

デフォルト値

マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

前提オプション

-XX:+HitachiOutOfMemoryHandling

引数

<整数値>

Javaヒープ不足またはMetaspace領域，Compressed Class Space不足が原因のOutOfMemory発生回数合計値の1時間当たりの上限値を指定します。

0〜3600（3601〜2⁶³-1の場合は3600として扱います）。

注意事項

自然数以外の値が指定された場合は，定義していないオプションを指定した場合と同様の動作になります。

-XX:[+|-]HitachiJavaClassLibTrace（クラスライブラリのスタックトレース出力オプション）

形式

-XX:+HitachiJavaClassLibTrace

クラスライブラリのスタックトレースを出力します。

-XX:-HitachiJavaClassLibTrace

クラスライブラリのスタックトレースを出力しません。

説明

次に示すシステム全体に影響を与えるメソッドが使用された場合，これらのAPIのスタックトレースを，JavaVMログファイルへ出力します。

java.lang.System.gc

java.lang.System.exit

java.lang.System.runFinalizersOnExit

java.lang.Runtime.exit

java.lang.Runtime.halt

java.lang.Runtime.runFinalizersOnExit

デフォルト値

マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

出力形式

[id] [Thread:thread_id]<date>
[id] [Thread:thread_id] stack_trace

出力内容を次に説明します。

id：

CLT（JavaVMログファイル識別子）。

thread_id：

スレッドID（スレッドダンプに出力されているtid）。

date：

クラスライブラリ使用日時。

stack_trace：

スタックトレース。

出力例1

[CLT][Thread: 0x00062fd0]<Mon Sep 27 12:10:03 2004>
[CLT][Thread: 0x00062fd0] at at java.lang.Shutdown.halt0(Native Method)
[CLT][Thread: 0x00062fd0] at java.lang.Shutdown.halt(Shutdown.java:145)
[CLT][Thread: 0x00062fd0] - locked <0x100101a0> (a java.lang.Shutdown$Lock)
[CLT][Thread: 0x00062fd0] at java.lang.Shutdown.exit(Shutdown.java:222)
[CLT][Thread: 0x00062fd0] - locked <0x1413c0a0> (a java.lang.Class)
[CLT][Thread: 0x00062fd0] at java.lang.Terminator$1.handle(Terminator.java:35)
[CLT][Thread: 0x00062fd0] at sun.misc.Signal$1.run(Signal.java:195)
[CLT][Thread: 0x00062fd0] at java.lang.Thread.run(Thread.java:534)

出力例2

[CLT][Thread: 0x009c4000]<Tue Oct 09 15:36:18 2012>
[CLT][Thread: 0x009c4000] at java.lang.Runtime.outputJavaClassLibTrace(Native Method)
[CLT][Thread: 0x009c4000] at java.lang.Runtime.runFinalizersOnExit(Runtime.java:378)
[CLT][Thread: 0x009c4000] at java.lang.System.runFinalizersOnExit(System.java:978)
[CLT][Thread: 0x009c4000] at Program.main(Program.java:8)

-XX:HitachiJavaClassLibTraceLineSize（クラスライブラリのスタックトレース行サイズ指定オプション）

形式

-XX:HitachiJavaClassLibTraceLineSize=<整数値>

説明

-XX:+HitachiJavaClassLibTraceオプションを指定した場合に出力される，クラスライブラリのスタックトレースの1行の文字数をバイト数で指定します。

デフォルト値

マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

前提オプション

-XX:+HitachiJavaClassLibTrace

引数

<整数値>

1024〜2147483647の範囲で整数値（単位：バイト）を指定します。範囲外の値が指定された場合は1024が設定されます。

出力例

[CLT][Thread: 0x00286c58]<Thu Oct 21 14:56:24 2004>
[CLT][Thread: 0x00286c58] at java.lang.Runtime.gc(Native Method)
[CLT][Thread: 0x00286c58] at java.lang.System.gc(System.java:737)
[CLT][Thread: 0x00286c58] at mple.func_012345678〜省略〜xyz(Sample.java:9)
[CLT][Thread: 0x00286c58] at Sample.main(Sample.java:5)

1行の文字数が指定したバイト数を超える場合，「at」以降の文字列の前半部分が削除されます。出力例の場合，4行目のSampleの前半が削除されてmpleとなります。

-XX:[+|-]HitachiLocalsInThrowable（例外発生時のローカル変数情報収集オプション）

形式

-XX:+HitachiLocalsInThrowable

スタックトレース中のメソッドのローカル変数情報を出力します。

ただし，java.lang.StackOverflowError発生時には，このオプションは無視されます。

-XX:-HitachiLocalsInThrowable

スタックトレース中のメソッドのローカル変数情報を出力しません。

説明

java.lang.Throwable.fillInStackTraceメソッド実行時に，スタックトレース中のメソッドのローカル変数情報を収集します。

デフォルト値

マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

出力形式

    locals:
      name: <name>
      type: <type>
      value: <value>
…

出力内容を次に示します。

1行目に「locals:」という見出しが出力されます。

2行目以降は，収集可能であった各ローカル変数について，次の情報が1行ずつ出力されます。

変数名

型名（基本型名，クラス名または配列型名）

変数値を表現する文字列

なお，各ローカル変数の出力内容は，空行で区切られています。

<name>：

ローカル変数名。

メソッドに渡される引数の場合は，変数名に続いて[arg***]（***は引数番号）が表示されます。

<type>：

ローカル変数の型名（基本型名，クラス名または配列型名）。

<value>：

ローカル変数の値を表現する文字列。

基本型：

値をそのまま文字列化したもの

クラスまたは配列型：

変数値がnullの場合：(null)

それ以外の場合：<オブジェクトの存在するアドレス>

値表現の最大文字列長は64です。これを超える場合は64文字目までを出力したあと，「...」という文字列が出力されます。クラスまたは配列型の場合，次の追加オプションを指定することでより詳細な表現が追加できます。

-XX:+HitachiLocalsSimpleFormat

-XX:+HitachiTrueTypeInLocals

-XX:HitachiCallToString

出力例

Javaプログラム例1を使用した出力例を，次に示します。

すべてのローカル変数情報が出力される場合

  at Example1.method(Example1.java:15)
    locals:
      name: this
      type: Example1
      value: <0x922f42d0>

      name: l1 [arg1]
      type: int
      value: 1

      name: l2 [arg2]
      type; char
      value: 'Q'

      name: l3 [arg3]
      type: java.lang.Object
      value: <0xaf112f08>

      name: l4
      type: float
      value: 4.000000

      name: l5
      type: boolean
      value: true

      name: l6
      type: double
      value: 1.79769E+308

      name: l7
      type: java.lang.Object[]
      value: <0x922f42d8>

  at Example1.main(Example1.java:5)
    locals:
…

ローカル変数情報が存在しない場合

-gオプションまたは-g:varsオプションを付加しないでclassファイルを生成した場合

-gオプションまたは-g:varsオプションを付加して生成したclassファイルの，nativeメソッドの場合

  at Example1.method(Example1.java:15)
    locals:
      name: this
      type: Example1
      value: <0x922f42d0>

      name: [arg1]
      type: int
      value: 1

      name: [arg2]
      type; char
      value: 'Q'

      name: [arg3]
      type: java.lang.Object
      value: <0xaf112f08>

  at Example1.main(Example1.java:5)
    locals:
…

注意事項

ローカル変数情報を完全に収集するためには，javacでclassファイルを生成する際に，-gオプションまたは-g:varsオプションを付加してclassファイル内にローカル変数情報を埋め込んでおく必要があります。-gオプションまたは-g:varsオプションを付加しないで作成されたclassファイルについては，収集可能な範囲でローカル変数情報が出力されます。

-gオプションまたは-g:varsオプションを付加して生成されたclassファイルでも，nativeメソッドの場合はローカル変数情報が存在しません。

JITコンパイラがメソッドをJITコンパイルする際，最適化の一環として，不要と判断したローカル変数を除去することがあります。

（例）int not_used = 12345といった宣言および初期化以降未使用のローカル変数

この場合，例外発生時点のローカル変数情報には，次の値が出力されます。

型名

出力情報

boolean型

false

char型

'¥0'

byte型

short型

int型

long型

float型

double型

0

クラス型

配列型

(null)

制御構造が複雑で行数が多いメソッドのローカル変数情報を出力する場合，解析に時間が掛かるため，例外発生時の例外オブジェクト生成処理に時間が掛かることがあります。

java.lang.ThreadクラスのgetStackTraceメソッドを使用して取得した，カレントスレッドのスタックトレースにローカル変数情報を出力するためには，例外発生時のスタックトレースにローカル変数情報を出力する，例外発生時のローカル変数情報収集オプション（-XX:+HitachiLocalsInThrowable）が必要になります。

-XX:[+|-]HitachiLocalsInStackTrace（スレッドダンプ出力時のローカル変数出力オプション）

形式

-XX:+HitachiLocalsInStackTrace

スレッドダンプ出力時のスタックトレースに，ローカル変数情報を出力します。

-XX:-HitachiLocalsInStackTrace

スレッドダンプ出力時のスタックトレースに，ローカル変数情報を出力しません。

説明

スレッドダンプ出力時のスタックトレースに，各メソッドのローカル変数情報を追加して出力します。ローカル変数情報の出力内容については，「-XX:[+|-]HitachiLocalsInThrowable（例外発生時のローカル変数情報収集オプション）」を参照してください。

デフォルト値

マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

出力例

Javaプログラム例2を使用した出力例を，次に示します。

-XX:+HitachiLocalsSimpleFormatオプションおよび-XX:+HitachiTrueTypeInLocalsオプションが指定されている場合

"main" prio=1 tid=0xb6e88d20 nid=0xb7492080 runnable [bfffb000..bfffb474]
        at Example2.method(Example2.java:15)
        - locked <0xab040550> (a Example2)
          locals:
            (Example2) this = <0xab040550> (Example2)
            (int) l1 = 1
            (float) l2 = 2.000000
            (java.lang.String) l3 = <0xaf112cc0> (java.lang.String)
            (java.lang.Character) l4 = <0xab040698> (java.lang.Character)
            (java.lang.Object) l5 = <0xab0407c8> (java.lang.Thread)
            (java.lang.Object[]) l6 = <0xab0408b8> (java.lang.Thread[])
        at Example2.main(Example2.java:4)
          locals:
            (java.lang.String[]) args [arg1] = <0xab040540> (java.lang.String[])
            (Example2) e2 = <0xab040550> (Example2)

注意事項

ローカル変数情報を完全に収集するためには，javacでclassファイルを生成する際に，-gオプションまたは-g:varsオプションを付加してclassファイル内にローカル変数情報を埋め込んでおく必要があります。-gオプションまたは-g:varsオプションを付加しないで作成されたclassファイルについては，収集可能な範囲でローカル変数情報が出力されます。

一般にスタックトレース情報の収集を行うスレッドと収集対象のスレッドは一致しません。このため，情報収集を行うためには，対象スレッドを停止させる必要があり，toStringメソッドを呼び出すことはできません。このため，-XX:HitachiCallToStringオプションの指定は無効になります。

制御構造が複雑で行数が多いメソッドのローカル変数情報を出力する場合，解析に時間が掛かるため，拡張スレッドダンプの出力やスレッドスタックトレースの取得に時間が掛かることがあります。

-XX:[+|-]HitachiLocalsSimpleFormat（ローカル変数情報の出力フォーマット変更オプション）

形式

-XX:+HitachiLocalsSimpleFormat

ローカル変数情報出力を，簡易フォーマットで出力します。

-XX:-HitachiLocalsSimpleFormat

ローカル変数情報出力を，通常フォーマットで出力します。

説明

ローカル変数情報の出力フォーマットを，1変数1行で出力する簡易出力フォーマットに変更します。

デフォルト値

マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

前提オプション

-XX:+HitachiLocalsInThrowable

-XX:+HitachiLocalsInStackTrace

出力形式

    locals:
      (type) name = value
      (type) name = value
…

type，nameおよびvalueの出力内容については，「-XX:[+|-]HitachiLocalsInThrowable（例外発生時のローカル変数情報収集オプション）」を参照してください。

出力例

Javaプログラム例1を使用した出力例を，次に示します。

  at Example1.method(Example1.java:15)
    locals:
      (Example1) this = <0x922f42d0>
      (int) l1 [arg1] = 1
      (char) l2 [arg2] = 'Q'
      (java.lang.Object) l3 [arg3] = <0xaf112f08>
      (float) l4 = 4.000000
      (boolean) l5 = true
      (double) l6 = 1.79769E+308
      (java.lang.Object[]) l7 = <0x922f42d8>
  at Example1.main(Example1.java:5)
    locals:
…

-XX:[+|-]HitachiTrueTypeInLocals（ローカル変数情報の実型名出力オプション）

形式

-XX:+HitachiTrueTypeInLocals

ローカル変数情報に，実際のオブジェクト型名を出力します。

-XX:-HitachiTrueTypeInLocals

ローカル変数情報に，実際のオブジェクト型名を出力しません。

説明

ローカル変数情報収集時に，クラスまたは配列型のローカル変数について，実際に代入されているオブジェクトの型名を出力します。変数値を表現する文字列の後ろの丸括弧内に表示されます。

なお，ローカル変数に格納されているクラスまたは配列型のオブジェクトがJavaVM内部のオブジェクトの場合は，"internal type"と出力されます。

デフォルト値

マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

前提オプション

-XX:+HitachiLocalsInThrowable

-XX:+HitachiLocalsInStackTrace

出力例

Javaプログラム例3を使用した出力例を，次に示します。

-XX:+HitachiLocalsSimpleFormatオプションおよび-XX:HitachiCallToString=fullが指定されている場合

  at Example3.method(Example3.java:18)
    locals:
      (Example3) this = <0xaa07db58> "I am an Example3 instance." (Example3)
      (java.lang.String) l1 = <0xae173a28> "local 1" (java.lang.String)
      (java.lang.StringBuffer) l2 = <0xaa07dca0> "local 1 + local 2" (java.lang.StringBuffer)
      (java.lang.Boolean) l3 = <0xaa07de18> "false" (java.lang.Boolean)
      (java.lang.Character) l4 = <0xaa07df68> "X" (java.lang.Character)
      (java.lang.Long) l5 = <0xaa07e078> "-9223372036854775808" (java.lang.Long)
      (java.lang.Object) l6 = <0xaa07e1a8> "Thread[Thread-0,5,main]" (java.lang.Thread)
      (java.lang.Object[]) l7 = <0xaa07e298> "[Ljava.lang.Thread;@26e431" (java.lang.Thread[])
  at Example3.main(Example3.java:4)
    locals:
…

-XX:HitachiCallToString（ローカル変数情報出力オプション）

形式

-XX:HitachiCallToString=<適用範囲>

説明

<適用範囲>に該当するクラスのローカル変数オブジェクトに対して取得したStringオブジェクトの文字列を，変数値を表現する文字列として出力します。

なお，ローカル変数に格納されているオブジェクトがない場合，またはJavaVM内部のオブジェクトの場合は，出力されません。

デフォルト値

マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

前提オプション

-XX:+HitachiLocalsInThrowable

引数

<適用範囲>

minimalまたはfullを指定します。

minimal：

java.langパッケージ内の次に示すクラスが対象になります。

String

StringBuffer

Boolean

Byte

Character

Short

Integer

Long

Float

Double

なお，空文字（""）を指定した場合も，minimalと同じです。

full：

すべてのクラスおよび配列型が対象になります。

出力例

Javaプログラム例3を使用した出力例（簡易出力フォーマット）を，次に示します。

-XX:HitachiCallToString=minimalの場合

  at Example3.method(Example3.java:18)
    locals:
      (Example3) this = <0xaa07db58>
      (java.lang.String) l1 = <0xae173a28> "local 1"
      (java.lang.StringBuffer) l2 = <0xaa07dca0> "local 1 + local 2"
      (java.lang.Boolean) l3 = <0xaa07de18> "false"
      (java.lang.Character) l4 = <0xaa07df68> "X"
      (java.lang.Long) l5 = <0xaa07e078> "-9223372036854775808"
      (java.lang.Object) l6 = <0xaa07e1a8>
      (java.lang.Object[]) l7 = <0xaa07e298>
  at Example3.main(Example3.java:4)
    locals:
…

-XX:HitachiCallToString=fullの場合

  at Example3.method(Example3.java:18)
    locals:
      (Example3) this = <0xaa07db58> "I am an Example3 instance."
      (java.lang.String) l1 = <0xae173a28> "local 1"
      (java.lang.StringBuffer) l2 = <0xaa07dca0> "local 1 + local 2"
      (java.lang.Boolean) l3 = <0xaa07de18> "false"
      (java.lang.Character) l4 = <0xaa07df68> "X"
      (java.lang.Long) l5 = <0xaa07e078> "-9223372036854775808"
      (java.lang.Object) l6 = <0xaa07e1a8> "Thread[Thread-0,5,main]"
      (java.lang.Object[]) l7 = <0xaa07e298> "[Ljava.lang.Thread;@26e431"
  at Example3.main(Example3.java:4)
    locals:
…

注意事項

ローカル変数情報を完全に収集するためには，javacでclassファイルを生成する際に，-gオプションまたは-g:varsオプションを付加してclassファイル内にローカル変数情報を埋め込んでおく必要があります。-gオプションまたは-g:varsオプションを付加しないで作成されたclassファイルについては，収集可能な範囲でローカル変数情報が出力されます。

このオプションを指定して，AWTまたはSwingを利用したJavaのプログラムを実行する場合，<適用範囲>には「minimal」を指定してください。<適用範囲>に「full」を指定すると，プログラムが正しく動作しません。

ユーザプログラムでの例外発生時の原因調査時に限り，<適用範囲>に「full」を指定してください。この機能は，例外オブジェクト生成時，ローカル変数オブジェクトのtoString()メソッドを呼び出す仕様です。toString()メソッドの呼び出しによって，原因調査に有用な情報が得られる反面，本来とは異なるタイミングでtoString()メソッドを呼び出すことで，製品やユーザプログラムが正しく動作しない場合があるためです。

-XX:[+|-]HitachiFullCore（システムリソース解除オプション）

形式

-XX:+HitachiFullCore

システムリソースRLIMIT_COREを強制的に最大値に引き上げて，障害発生時にユーザーリミットを無視してcoreファイルを作成します。

-XX:-HitachiFullCore

システムリソースRLIMIT_COREは変更しません。

説明

システムリソースRLIMIT_COREの設定を変更するかどうかを指定します。

デフォルト値

マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

-XX:HitachiJITCompileMaxMemorySize（JITコンパイル時の確保メモリ上限値指定オプション）

形式

-XX:HitachiJITCompileMaxMemorySize=<整数値>

説明

JITコンパイル時に確保するCヒープのメモリサイズの上限値を指定します。JITコンパイルによって確保するCヒープのメモリが指定値を超えた場合，JavaVMログファイルにログを出力するとともに，以降のJITコンパイルを抑制します。JITコンパイル処理の対象となっていたJavaメソッドは，以降，インタプリタでだけ実行されるようになります。なお，JITコンパイルが抑制された場合でも，JavaVMは強制終了しないで，処理を続行します。

0を指定した場合，JITコンパイル時に確保するメモリは上限値で制限されません。

なお，JITコンパイルはJavaVMの内部スレッド（JITコンパイラスレッド）で実行されます。JITコンパイラスレッドは2つあるため，このオプションで指定した上限値を2で割った値が，1つのJITコンパイラスレッドに対する上限値となります。

また，このオプションで上限値を設定した場合も，実際に使用できるCヒープがそれよりも少ないときには，上限値に達する前にCヒープ不足が発生することがあります。この場合，JavaVMは強制終了します。

デフォルト値

マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

前提オプション

-server

引数

<整数値>

JITコンパイル時に確保するメモリの上限値を指定します。単位はバイトです。単位文字として，「k」（キロ），「m」（メガ），「g」（ギガ）も指定できます。指定できる範囲は次のとおりです。範囲外の値を指定した場合は，0が指定されます。

0〜2⁶⁴-1（18446744073709551615）

0を指定した場合は，JITコンパイル時に確保するメモリは上限値で制限されません。JITコンパイル中にCヒープ不足が発生した場合，JavaVMは強制終了します。

出力形式

[id][Thread: thread_id]<date>["thread_name" exceeded max memory size.]
[current_sizeK->new_sizeK/limit_size_per_threadK/limit_sizeK]
[compile_target][byte_code_size]

出力内容を次に説明します。

id

JMS（JavaVMログファイル識別子）。

thread_id

JITコンパイルを抑制したJITコンパイラスレッドのスレッドID。

date

JITコンパイルを抑制した日時。

-XX:+HitachiOutputMilliTimeオプションが指定された場合，ミリ秒単位で出力されます。

thread_name

JITコンパイルを抑制したJITコンパイラスレッドのスレッド名。

current_size

JITコンパイルを抑制したJITコンパイラスレッドの，現在のメモリ確保サイズ（単位：キロバイト）。

new_size

JITコンパイルを抑制したJITコンパイラスレッドの，現在のメモリ確保サイズと追加で確保しようとしたサイズの合計値（単位：キロバイト）。

limit_size_per_thread

1つのJITコンパイラスレッドの上限値（単位：キロバイト）。

limit_size

JITコンパイラスレッド全体の上限値（単位：キロバイト）。

compile_target

JITコンパイル処理の対象となっていたJavaメソッド。

byte_code_size

JITコンパイル処理の対象となっていたJavaメソッドのバイトコードのサイズ（単位：バイト）。

出力例

オプションとして「-XX:HitachiJITCompileMaxMemorySize=536870912」を指定して，1つのJITコンパイラスレッドに対して262145キロバイトのCヒープを確保した場合に，上限値に達したときの出力例を示します。

[JMS][Thread: 0x03bf1150]<Wed Feb 24 14:33:58 2010>["CompilerThread0" exceeded  max memory size.][262143K->262145K/262144K/524288K][test1.func][213]

注意事項

JITコンパイル時に確保するメモリが，このオプションで指定した上限値を超えて，JITコンパイルが抑制されると，アプリケーションのスループットが低下します。

自然数以外の値が指定された場合は，定義していないオプションを指定した場合と同様の動作になります。

-XX:[+|-]JITCompilerContinuation（JITコンパイラ稼働継続機能オプション）

形式

-XX:+JITCompilerContinuation

JITコンパイラ稼働継続機能を有効にします。

-XX:-JITCompilerContinuation

JITコンパイラ稼働継続機能を無効にします。

説明

JITコンパイラ稼働継続機能を有効にするかどうかを指定します。

JITコンパイルがアプリケーションを構成するメソッドの論理矛盾で失敗しても，アプリケーションを正常に継続できるようにするためには，この機能を有効にすることをお勧めします。

JITコンパイラ稼働継続機能を有効にした場合，JITコンパイルがアプリケーションを構成するメソッドの論理矛盾で失敗しても，JavaVMはJavaVMログファイルにこの機能のログを出力して，処理を続行します。この場合，JITコンパイルに失敗したメソッドでは，以降のコンパイルはインタプリタ方式で実行されるようになります。アプリケーションを構成しているメソッドのうち，JITコンパイルに失敗したメソッド以外のメソッドはJITコンパイルで実行されるため，アプリケーションは正常に継続されます。ただし，JITコンパイルが6回以上失敗すると，JavaVMはエラーリポートファイル，およびメモリダンプまたはcoreダンプを出力して，強制終了します。

JITコンパイラ稼働継続機能を無効にした場合，JITコンパイルがアプリケーションを構成するメソッドの論理矛盾で失敗すると，JavaVMはエラーリポートファイル，およびメモリダンプまたはcoreダンプを出力して，強制終了します。

デフォルト値

マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

前提オプション

-server

-XX:+HitachiVerboseGC

出力形式

[id]

注

[id]以降にはJITコンパイラ稼働継続機能のログが出力されます。

出力内容を次に説明します。

id：

JCC（JavaVMログファイル識別子）。

出力例

[JCC][Thread: 0x05432c00]<Thu Nov 15 17:10:40 2012>[Method: jit_sample.func()V][Fail: 3][JITCT: 1]
[JCC][Thread: 0x05432c00][PC: 0x083aff9a][Lib: D:¥work¥jdk¥bin¥server¥jvm.dll+0x3aff9a][VM: Java HotSpot(TM) Server VM (20.8-b03-CDK0950-20121115 mixed mode windows-x86 )]
[JCC][Thread: 0x05432c00][EAX=0x00000000, EBX=0x00618128, ECX=0x00000000, EDX=0x05485340]
[JCC][Thread: 0x05432c00][ESP=0x0566d3c0, EBP=0x0566d3c4, ESI=0x00618278, EDI=0x00000000]
[JCC][Thread: 0x05432c00][EIP=0x083aff9a, EFLAGS=0x00010202]
[JCC][Thread: 0x05432c00][siginfo: read 0x00000000]
[JCC][Thread: 0x05432c00][Unlock: MethodCompileQueue_lock]
[JCC][Thread: 0x05432c00][NewJITCT: 0x05438800][JITCT: 2]
[JCC][Thread: 0x05432c00][Free: "ResourceArea" 524288 bytes.]
[JCC][Thread: 0x05432c00][stop]
[JCC][Fail: 1][date: Thu Nov 15 10:10:40 2012][Method: jit_sample.func1(Ljava/lang/String;)V][PC: 0x083ff00a][Lib: D:¥work¥jdk¥bin¥server¥jvm.dll+0x3ff00a]
[JCC][Fail: 2][date: Thu Nov 15 11:11:16 2012][Method: jit_sample.func2()V][PC: 0x083afe3a][Lib: D:¥work¥jdk¥bin¥server¥jvm.dll+0x3afe3a]

-XX:[+|-]UseCompressedOops（圧縮オブジェクトポインタ機能で使用するJavaオプション）

形式

-XX:+UseCompressedOops

圧縮オブジェクトポインタ機能を有効にします。

-XX:-UseCompressedOops

圧縮オブジェクトポインタ機能を無効にします。

説明

圧縮オブジェクトポインタ機能の有効，無効を指定します。圧縮オブジェクトポインタ機能は，Javaオブジェクトのサイズを圧縮して管理することで，JavaVM実行時のJavaヒープ領域の使用サイズを削減します。

この機能を有効にするには，次の条件を満たしていることが前提となります。

Javaヒープ領域，Metaspace領域の指定サイズの合計値が32ギガバイト未満であること

JavaVM起動時，Javaヒープ領域，Metaspace領域の指定サイズの合計値が，32ギガバイト以上の場合は，JavaVMは次のメッセージを標準出力に出力し，圧縮オブジェクトポインタ機能を無効とします。

Java HotSpot(TM) 64-Bit Server VM warning: Max heap size too large for Compressed Oops

デフォルト値

マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

-XX:HitachiThreadLimit（スレッド数の上限値指定オプション）

形式

-XX:HitachiThreadLimit=<整数値>

説明

スレッド数の上限値を指定します。スレッド数の上限値が指定値を超えた場合に，OutOfMemoryError例外がスローされます。ただし，JavaVMが起動する前に上限値を超えた場合，例外はスローされません。また，スレッド数には，アプリケーションがJNIなどを使用してJavaVMの管理外の範囲で作成したスレッド数は含みません。0を指定した場合，上限値は設定されません。

なお，-XX:+HitachiOutOfMemoryAbortオプションと同時に指定した場合，このオプションの機能によってOutOfMemoryError例外がスローされた場合，JavaVMの強制終了は実行されません。

また，-XX:+HitachiOutOfMemoryStackTraceオプションと同時に指定した場合，例外メッセージがJavaVMログファイルに出力されます。

デフォルト値

マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

引数

<整数値>

スレッド数の上限値を0〜2147483647の範囲で整数値（単位：スレッド数）を指定します。範囲外の値が指定された場合は0が設定されます。負の値を指定した場合はエラーとなります。

出力形式

Could not create "name" thread. Threadlimit Exceeded. num threads exist.

このメッセージは，java.lang.Throwable.getMessage()で取得できます。また，メッセージ全体が半角128文字以上になった場合は，メッセージの末尾が省略されます。

name

作成に失敗したスレッド名。

num

現時点でのスレッド数。

-XX:+HitachiOutOfMemoryStackTraceオプションが指定されている場合，JavaVMログファイルに例外情報とスタックトレースを出力できます。例外発生要因種別は，"Thread Limit"となります。例外発生要因種別については，「-XX:[+|-]HitachiOutOfMemoryCause（例外発生要因種別出力オプション）」を参照してください。

出力例

Could not create "Thread-1" thread. Threadlimit Exceeded. 9 threads exist.

この例は，mainスレッドによってjava.lang.Thread.startが呼び出され，この機能によって例外をスローした場合に，java.lang.Throwable.getMessage()でメッセージを取り出したメッセージの例です。

注意事項

上限値に小さな値を設定すると，起動前に例外をスローします。アプリケーションサーバが使用するスレッド数より小さな値を設定しないでください。

アプリケーションサーバが使用するスレッド数については，マニュアル「uCosminexus Application Runtime ユーザーズガイド」のリソースの見積もりに関する説明を参照してください。

5.3　日立JavaVMで使用するプロパティ

日立JavaVMで使用するプロパティの一覧を，次の表に示します。

表5‒8　日立JavaVMで使用するプロパティの一覧

分類

オプション名称

概要

関連情報

日立JavaVMで使用するプロパティ

JP.co.Hitachi.soft.jvm.autofinalizer

ファイナライズ滞留解消機能の有効または無効を設定します。

「4.13　ファイナライズ滞留解消機能」

JP.co.Hitachi.soft.jvm.autofinalizer

形式

JP.co.Hitachi.soft.jvm.autofinalizer={true|false}

説明

ファイナライズ滞留解消機能の有効，無効を指定します。

true，false以外の値が設定された場合，デフォルト値になります。

デフォルト値

JP.co.Hitachi.soft.jvm.autofinalizer=true

出力例

ファイナライズ処理の滞留を検知して，ファイナライズ処理監視スレッドを新たに生成する場合

# FinalizerWatcherThread: Create: create secondary finalizer thread.
[queue length = 128] <Mon May 26 18:00:36 JST 2008>

生成したファイナライズ処理監視スレッドが終了した場合

# FinalizerWatcherThread: Finish: secondary finalizer thread is finished.
<Mon May 26 20:12:26 JST 2008>

5.4　日立JavaVMで指定できるJava HotSpot VMのオプション

日立JavaVMの利用時に指定できるJava HotSpot VMのオプション，およびオプションを指定する際の注意事項について説明します。

指定できるJava HotSpot VMのオプションを次の表に示します。

各オプションのデフォルト値は，マニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。

表5‒9　指定できるJava HotSpot VMのオプション

オプション名

内容

指定可能値

-D<property>

JavaVMのシステムプロパティを指定します。

入力は制限されません。

-agentlib:<libname>[=<options>]

ネイティブエージェントライブラリ<libname>をロードします。

入力は制限されません。

-verbose:<情報種別>

<情報種別>に指定した情報を出力します。<情報種別>に指定できる値を示します。

class：

クラスがロードされるたびにクラスに関する情報を出力します。

gc：

GCイベントが発生するたびに報告します。

jni：

ネイティブメソッドの使用およびそのほかのJava Native Interface（JNI）アクティビティに関する情報を報告します。

指定できる文字列を次に示します。

class

gc

jni

-Xloggc:<ファイル>

-verbose:gcと同様にGCイベントが発生するたびに報告しますが，そのデータを<ファイル>に記録します。-verbose:gcを指定したときに報告される情報のほかに，報告される各イベントの先頭に，最初のGCイベントからの経過時間（秒単位）が付け加えられます。

入力は制限されません。

-Xms<size>

Javaヒープの初期サイズを設定します。

自然数の値を次に示す単位を使って指定します。

キロ「k」

メガ「m」

ギガ「g」

テラ「t」

なお，大文字・小文字は区別されません。

-Xmx<size>

Javaヒープの最大サイズを設定します。

自然数の値を次に示す単位を使って指定します。

キロ「k」

メガ「m」

ギガ「g」

テラ「t」

なお，大文字・小文字は区別されません。

-Xmn<size>

New領域の初期値および最大値を設定します。

自然数の値を次に示す単位を使って指定します。

キロ「k」

メガ「m」

ギガ「g」

テラ「t」

なお，大文字・小文字は区別されません。

-Xss<size>

1スタック領域の最大サイズを設定します。

自然数の値を次に示す単位を使って指定します。

キロ「k」

メガ「m」

ギガ「g」

テラ「t」

なお，大文字・小文字は区別されません。

-Xprof

このオプションを指定した場合，実行中のプログラムのプロファイルを生成し，プロファイリングデータを標準出力に出力します。このオプションは，プログラム開発用のユーティリティとして提供されています。本番稼働システムでの使用を目的としたものではありません。

−

-Xrunhprof[:<suboption>=<value>,...]

CPU，ヒープ，またはモニタのプロファイリングを有効にします。-Xrunhprofの後ろにコロン「:」を指定して「<suboption>=<value>」を記述します。「<suboption>=<value>」はコンマ「,」で区切って複数指定できます。

サブオプションとそのデフォルト値のリストを取得するには，コマンドjava-Xrunhprof:helpを実行します。

任意の文字列を指定します。

<suboption>には「=」および「,」は指定できません。

また，<value>には「,」は指定できません。

-XX:NewRatio=<value>

New領域に対するTenured領域の割合を指定します。

<value>が2の場合は，New領域とTenured領域の割合が，1:2になります。

「New領域の使用中サイズ≧Tenured領域の空き領域サイズ」になるとFullGCが発生します。このオプションに1を設定すると，FullGCが多発するので注意してください。

自然数の値を指定します。

-XX:MetaspaceSize=<size>

Metaspace領域の初期サイズを指定します。

自然数の値を次に示す単位を使って指定します。

キロ「k」

メガ「m」

ギガ「g」

テラ「t」

なお，大文字・小文字は区別されません。

-XX:MaxMetaspaceSize=<size>

Metaspace領域の最大サイズを指定します。

自然数の値を次に示す単位を使って指定します。

キロ「k」

メガ「m」

ギガ「g」

テラ「t」

なお，大文字・小文字は区別されません。

-XX:CompressedClassSpaceSize

Compressed Class Spaceの最大サイズを指定します。

自然数の値を次に示す単位を使って指定します。

キロ「k」

メガ「m」

ギガ「g」

なお，大文字・小文字は区別されません。

-XX:SurvivorRatio=<value>

New::Survivor領域のFrom空間とTo空間に対するNew::Eden領域の割合を指定します。

<value>に8を設定した場合は，New::Eden領域，From空間，To空間の割合が，8:1:1になります。

自然数の値を指定します。

-XX:TargetSurvivorRatio=<value>

GC実行後のNew::Survivor領域内でJavaオブジェクトが占める割合の目標値（0〜100（単位：%））を指定します。

自然数の値を指定します。

-XX:MaxTenuringThreshold=<value>

CopyGC実行時に，From空間とTo空間でJavaオブジェクトを入れ替える回数のしきい値を指定します。指定した回数を超えて入れ替え対象になったJavaオブジェクトは，Tenured領域に移動されます。

このオプションの有効範囲は，0〜デフォルト値です。範囲外の値を指定した場合，しきい値を超えた場合にTenured領域へ移動する機能は無効になります。

自然数の値を指定します。

-XX:[+|-]UseSerialGC※

-XX:+UseSerialGC

SerialGCを実行します。

-XX:-UseSerialGC

SerialGCを実行しません。

指定できる文字を次に示します。

プラス「+」

マイナス「-」

-XX:[+|-]UseG1GC

-XX:+UseG1GC

G1GCを実行します。

-XX:-UseG1GC

G1GCを実行しません。

指定できる文字を次に示します。

プラス「+」

マイナス「-」

-XX:ParallelGCThreads

G1GCのEvacuationを並列実行するスレッドの数を指定します。-XX:+UseG1GCを指定したときに有効になります。なお，このオプションは，デフォルト値で使用することを推奨します。変更する場合は，実際にJavaVMを動作させて測定した値を基に，最適な値を算出してから変更してください。

JavaVM起動時に，このオプションに指定した数のEvacuation処理用のスレッドが作成され，処理が実行されます。

このオプションの指定を省略した場合のデフォルト値は次のとおりです。

実行環境の論理CPU数が8以下の場合は，CPU数になります。

実行環境の論理CPU数が9以上の場合は，「8＋(CPU数−8)×(5÷8)」（小数点以下は切り捨て）の値になります。

例えば，4CPUの場合は，「ParallelGCThreads＝4」でデフォルト値は4になります。また，72CPUの場合は，「ParallelGCThreads＝8＋(72−8)×(5÷8)＝48」で48になります。

このオプションに0を指定した場合は，デフォルト値が使用されます。

指定時には，次の点に注意してください。

このオプションの値を大きくすると，Evacuation用のスレッド数が増え，Evacuationに割り当てられるリソースが増加します。そのため，値を大きくするとスループットが低下する可能性があります。このオプションの値を変更した場合，性能の要件を満たしているか確認をしてください。

実行環境で作成できるスレッド数を超える値を指定した場合は，JavaVM起動時にEvacuation処理用のスレッドの作成に失敗するため，JavaVMを起動できません。

自然数の値を指定します。

-XX:ConcGCThreads

G1GCのConcurrent Markingの処理を並列実行するスレッドの数を指定します。

-XX:+UseG1GCを指定したときに有効になります。なお，このオプションは，デフォルト値で使用することを推奨します。変更する場合は，実際にJavaVMを動作させて測定した値を基に，最適な値を算出してから変更してください。

JavaVM起動時に，このオプションに指定した数のConcurrent Marking処理用のスレッドが作成され，処理が実行されます。

このオプションの指定を省略した場合のデフォルト値は次のとおりです。

Max( (ParallelGCThreads + 2)/4 , 1)

Max(A,B)はAとBのうち，大きい値を取ることを意味します。また，ParallelGCThreadsは-XX:ParallelGCThreadsの値を意味します。

このオプションに0を指定した場合はデフォルト値が使用されます。

指定時には次の点に注意してください。

実行環境で作成できるスレッド数を超える値を指定した場合は，JavaVM起動時にConcurrent Marking処理用のスレッドの作成に失敗するため，JavaVMを起動できません。

Concurrent Marking処理用スレッドのスレッド数はEvacuation処理用のスレッド数を超えて作成することはできません。Evacuation処理用のスレッド数を超えて指定した場合，メッセージが標準出力に出力されJavaVMの起動に失敗します。

自然数の値を指定します。

-XX:MaxGCPauseMillis

G1GCのGCによるアプリケーション停止時間の目標時間を[ms]の単位で指定できます。

-XX:+UseG1GCを指定したときに有効になります。

このオプションに0を指定した場合は，メッセージが標準出力に出力されJavaVMの起動に失敗します。

このオプションに100以下の値を指定する場合，ログファイルの非同期出力機能（-XX: +JavaLogAsynchronous）を使用することを推奨します。

自然数の値を指定します。

-XX:ReservedCodeCacheSize

コードキャッシュ領域の最大サイズを指定します。

自然数の値を次に示す単位を使って指定します。

キロ「k」

メガ「m」

ギガ「g」

なお，大文字・小文字は区別されません。

（凡例）

−：該当なし

注※

-XX:[+|-]UseSerialGCオプションと-XX:[+|-]UseG1GCオプションの指定の組み合わせごとに実行される処理を次に示します。

表5‒10　-XX:[+|-]UseSerialGCオプションと-XX:[+|-]UseG1GCオプションの指定の組み合わせごとの処理

-XX:[+|-]UseSerialGCオプションの指定

-XX:[+|-]UseG1GCオプションの指定

実行される処理

指定なし

指定なし

SerialGCを実行

-XX:+UseSerialGC

-XX:+UseG1GC

プロセスの起動に失敗

-XX:+UseSerialGC

-XX:-UseG1GC

SerialGCを実行（デフォルトと同様）

-XX:-UseSerialGC

-XX:-UseG1GC

-XX:-UseSerialGC

-XX:+UseG1GC

G1GCを実行

重要

デバッグまたはプロファイリング用オプションについて

JavaVMオプションの-Xprofや-Xdebug，JVMTIエージェントのhprofやjdwp（-agentlib:<libname>などで指定）は，プログラムの開発用ユーティリティとして提供されているものです。システムの運用では指定しないようにしてください。

GCの指定について

アプリケーションサーバのGCは，SerialGC（UseSerialGC）とG1GC（UseG1GC）を選択できます。この2つのGCを同時に指定しないようにしてください。同時に指定した場合は，Javaプロセスが起動できません。

5.5　日立JavaVMで使用する環境変数の一覧

日立JavaVMで使用する環境変数の一覧を，次の表に示します。

表5‒11　日立JavaVMで使用する環境変数の一覧

分類

環境変数

説明

日立JavaVMで使用する環境変数

JAVACOREDIR

スレッドダンプファイルの出力先ディレクトリを指定します。

5.6　日立JavaVMで使用する環境変数の詳細

日立JavaVMで使用する環境変数の詳細について説明します。

JAVACOREDIR

形式

setenv JAVACOREDIR <スレッドダンプファイルの出力先ディレクトリ>

説明

スレッドダンプファイルを出力する場合の，出力先ディレクトリを指定します。

デフォルト値

デフォルトではJAVACOREDIRは未設定です。

スレッドダンプ出力先

デフォルトでは，スレッドダンプファイルはカレントディレクトリに出力されます。

前提オプション

-XX:+HitachiThreadDump

指定例

スレッドダンプを/home/user/threaddumpに出力します。

setenv JAVACOREDIR /home/user/threaddump

注意事項

JAVACOREDIRで指定したディレクトリへのスレッドダンプファイルの出力に失敗した場合は，カレントディレクトリにスレッドダンプファイルを出力します。

カレントディレクトリへの出力も失敗した場合は，標準エラー出力だけにスレッドダンプを出力します。この場合は，標準出力にはスレッドダンプは出力されません。

6　日立JavaVMで使用するコマンド

この章では，日立JavaVMで使用するコマンドの入力形式，機能などについて説明します。

なお，日立JavaVMは，Java SE 11に準拠しています。JDK 11で使用できるコマンドについては，Oracle社が提供しているJDK 11のドキュメントを参照してください。

6.1　コマンドの文法の記述形式

6.1.1　記述形式の詳細

コマンドの文法の記述形式と使用する記号について説明します。

(1)　記述形式

コマンドの文法について次の形式で説明します。なお，各コマンドは，アルファベットの順に説明します。

形式

コマンドの入力形式を示します。

機能

コマンドの機能について説明します。

引数

コマンドの引数およびオプションについて説明します。

出力形式

コマンドの出力形式を示します。

入力例・出力例

コマンドの入力例および出力例を示します。

戻り値

コマンドの戻り値について説明します。

注意事項

コマンドを実行する上での注意事項について説明します。

メモ

各コマンドの説明では，上記の項目のうち必要な項目についてだけ説明しています。また，上記の項目以外に，各コマンドの固有情報を記載している場合があります。

(2)　使用する記号

コマンドの文法は次の表に示す記号および構文要素を使用して記述します。

表6‒1　文法で使用している記号

記号

意　味

　｜

横に並べられた複数の項目に対する項目間の区切りを示し，「または」を意味します。

（例）　A｜B

　AまたはBを指定することを示します。

{ 　 }

この記号で囲まれている複数の項目のうちから1つを選択することを示します。項目が横に並べられ，記号｜で区切られている場合は，そのうちの1つを選択します。

（例）　｛A｜B｜C｝

　A，BまたはCのどれかを指定することを示します。

［　］

この記号で囲まれている項目は省略してもよいことを示します。複数の項目が横に並べて記述されている場合には，すべてを省略するか，記号｛ ｝と同じくどれか1つを選択します。

（例1）　［A］

　「何も指定しない」か「Aを指定する」ことを示します。

（例2）　［B｜C］

　「何も指定しない」か「BまたはCを指定する」ことを示します。

…

記述が省略されていることを示します。

（例）　ABC…

　ABCの後ろに記述があり，その記述が省略されていることを示します。

<　>

この記号で囲まれている項目は，該当する要素やファイルなどを指定したり，該当する要素が表示されたりすることを示します。

（例1）　<プロパティ>

　プロパティを記述します。またはプロパティが表示されます。

（例2）　<ファイル名>

　ファイル名を指定します。

...

この記号の直前に示す記号を繰り返し，複数個指定できることを示します。

（例）　<プロパティ>...

　プロパティは複数個，繰り返して指定できます。

表6‒2　文法で使用している構文要素

構文要素

定義

英字

A〜Z　a〜z

英小文字

a〜z

英大文字

A〜Z

数字

0〜9

英数字

A〜Z　a〜z　0〜9

記号

!　"　#　$　%　&　'　(　)　+　,　_　・　.　/　:　;　<　=　>　@　[　]　^　−　｛　｝　￣　タブ　空白

注　すべて半角文字を使用してください。

6.2　コマンドの入力形式

6.2.1　入力形式の詳細

コマンドの入力形式を次に示します。

コマンド名称 [オプション…]

各項目について説明します。なお，コマンドプロンプトを「$」，コマンド名称を「cmd」と表記します。

(1)　コマンド名称

実行するコマンドのファイル名を指定します。

空白を含むパスを指定してコマンドを実行する場合，パス全体を""で囲む必要があります。

誤った指定例：$ /opt/program path/bin/command

正しい指定例：$ "/opt/program path/bin/command"

(2)　引数

引数には，オプションも含まれます。オプションの入力形式および指定規則を次に示します。

(a)　オプションの入力形式

オプションは，「-」（ハイフン）で始まる文字列です。オプションの入力形式には，オプション引数を指定しない形式と，1個のオプション引数を指定する形式があります。

オプション引数を指定しない形式

$ cmd -オプションフラグ

1個のオプション引数を指定する形式

$ cmd -オプションフラグ<スペースまたはタブ>オプション引数

（凡例）

オプションフラグ

1文字の半角英数字です。大文字と小文字が区別されます。

オプション引数

オプションフラグに対する引数です。

(b)　オプションの指定規則

オプションフラグは，1つの「-」（ハイフン）にまとめて指定できません。

誤った指定例：$ cmd -abc

正しい指定例：$ cmd -a -b -c

オプション引数を必要とするオプションフラグのオプション引数は，省略できません。

オプションフラグとオプション引数の間には，スペースまたはタブが必要です。

誤った指定例：$ cmd -afile

正しい指定例：$ cmd -a file

同じオプションフラグは，複数指定できません。

誤った指定例：$ cmd -a 1 -a 2

オプション引数に空白を含む場合，オプション引数全体を""で囲む必要があります。

誤った指定例：$ cmd -a file 1

正しい指定例：$ cmd -a "file 1"

6.3　日立JavaVMで使用するコマンドの一覧

日立JavaVMで使用するコマンドの一覧を，次の表に示します。

表6‒3　日立JavaVMで使用するコマンドの一覧

コマンド名称

分類

概要

car_tar_gz

coreアーカイブ機能

coreファイルと関連するライブラリなどをgzipコマンドでまとめて，1つのアーカイブファイルに出力します。

car_tar_Z

coreアーカイブ機能

coreファイルと関連するライブラリなどをcompressコマンドでまとめて，1つのアーカイブファイルに出力します。

javacore

coreファイルの取得

スレッドダンプの取得

coreファイルとスレッドダンプを同時に取得します。

javagc

FullGCの強制発生

メモリリーク，システム障害およびアプリケーションのデバッグのために，任意のタイミングでFullGCを発生させます。

javatrace

トレース情報の収集

coreファイルからスタックトレース情報を収集します。

jheapprof

クラス別統計情報付き拡張スレッドダンプの出力

クラス別統計情報をスレッドダンプ中に出力します。

jheapprofanalyzer

クラス別統計情報解析ファイルのCSV出力

クラス別統計情報解析ファイルをCSV形式で出力します。

6.4　日立JavaVMで使用するコマンドの詳細

日立JavaVMで使用するコマンドの入力形式，機能などを次に示します。

コマンドの格納先

日立JavaVMで使用するコマンドは，次のディレクトリに格納されています。

<JDKのインストールディレクトリ>/bin/

car_tar_gz（coreアーカイブ機能）

形式

car_tar_gz [-i <実行ファイル名>] [-f] [-s|-S] [<coreファイル名>] > <出力ファイル名>

機能

coreファイルと関連するライブラリなどをまとめて，1つのアーカイブファイルに出力します。car_tar_gzコマンドはgzipコマンドを使用して圧縮します。

引数

-i <実行ファイル名>

実行ファイル名を指定します。

-f

パス名付きでライブラリなどのファイルを取得します。

-s

出力するアーカイブファイルのサイズ（単位：バイト）を報告します。

この場合，アーカイブファイルは出力されません。

-S

アーカイブファイルを作成するための，シェルスクリプトを出力します。

このオプションを指定する場合，<出力ファイル名>には，シェルスクリプト名を指定してください。

出力されたシェルスクリプトを実行すると，アーカイブファイルが出力されます。

<coreファイル名>

coreファイル名を指定します。省略した場合，"core"が指定されます。

<出力ファイル名>

アーカイブファイル，またはシェルスクリプトのファイル名を指定します。

入力例

アーカイブファイルを作成する場合

car_tar_gz -f core.8326 > corefile.tar.gz

アーカイブファイルのサイズを調べる場合

car_tar_gz -s core.8326

シェルスクリプトからアーカイブファイルを作成する場合

シェルスクリプトを作成します。

car_tar_gz -S core.8326 > collect_cores.csh

シェルスクリプトに実行権を付与します。

chmod +x ./collect_cores.csh

シェルスクリプトを実行して，アーカイブファイルを作成します。

./collect_cores.csh > corefile.tar.gz

戻り値

0：

正常終了しました。

1：

異常終了しました。

出力メッセージ

次のメッセージを出力した場合，正常なアーカイブファイルは出力されません。

表6‒4　car_tar_gzコマンドで出力されるエラーメッセージ

項番

エラーメッセージ

説明

1

usage: car_tar_gz [ -i executable-file ] [ -f ] [ -s | -S ] [ core-file ]

コマンドの引数が不正です。

2

car_tar_gz: inner error!

car_tar_gzコマンドの内部エラーです。

3

car_tar_gz: cannot create temporary name

一時的に使用するファイルが作成できません。

カレントディレクトリにある，ファイルcar_exec??（??は00〜99）を削除するか，移動してください。

4

car_tar_gz: 〜 : file not found

ファイルが見つかりません。

coreファイルおよび-iオプションで指定した実行ファイルを確認してください。

5

car_tar_gz: 〜 : not supported platform

サポートしていないOSです。

注意事項

カレントディレクトリに書き込み権限が必要です。

同じディレクトリ下で，同じcoreファイルまたは作成時間が同じcoreファイルに対して，car_tar_Zコマンドおよびcar_tar_gzコマンドは同時に実行できません。

システムにtarコマンドおよびgzipコマンドがインストールされている必要があります。

car_tar_gzコマンド実行中に強制終了した場合，カレントディレクトリにcar_tar_gzコマンドが作成した一時的なファイルやディレクトリが残ります。

一時的に作成されるファイル：car_exec??（??は，00〜99）

一時的に作成されるディレクトリ：carYYMMDDhhmm/（YYMMDDhhmmは，coreファイルの作成年月日時分）

car_tar_Z（coreアーカイブ機能）

形式

car_tar_Z [-i <実行ファイル名>] [-f] [-s|-S] [<coreファイル名>] > <出力ファイル名>

機能

coreファイルと関連するライブラリなどをまとめて，1つのアーカイブファイルに出力します。car_tar_Zコマンドはcompressコマンドを使用して圧縮します。

引数

-i <実行ファイル名>

実行ファイル名を指定します。

-f

パス名付きでライブラリなどのファイルを取得します。

-s

出力するアーカイブファイルのサイズ（単位：バイト）を報告します。

この場合，アーカイブファイルは出力されません。

-S

アーカイブファイルを作成するための，シェルスクリプトを出力します。

このオプションを指定する場合，<出力ファイル名>には，シェルスクリプト名を指定してください。

出力されたシェルスクリプトを実行すると，アーカイブファイルが出力されます。

<coreファイル名>

coreファイル名を指定します。省略した場合，"core"が指定されます。

<出力ファイル名>

アーカイブファイル，またはシェルスクリプトのファイル名を指定します。

入力例

アーカイブファイルを作成する場合

car_tar_Z -f core.8326 > corefile.tar.Z

アーカイブファイルのサイズを調べる場合

car_tar_Z -s core.8326

シェルスクリプトからアーカイブファイルを作成する場合

シェルスクリプトを作成します。

car_tar_Z -S core.8326 > collect_cores.csh

シェルスクリプトに実行権を付与します。

chmod +x ./collect_cores.csh

シェルスクリプトを実行して，アーカイブファイルを作成します。

./collect_cores.csh > corefile.tar.Z

戻り値

0：

正常終了しました。

1：

異常終了しました。

出力メッセージ

次のメッセージを出力した場合，正常なアーカイブファイルは出力されません。

表6‒5　car_tar_Zコマンドで出力されるエラーメッセージ

項番

エラーメッセージ

説明

1

usage: car_tar_Z [ -i executable-file ] [ -f ] [ -s | -S ] [ core-file ]

コマンドの引数が不正です。

2

car_tar_Z: inner error!

car_tar_Zコマンドの内部エラーです。

3

car_tar_Z: cannot create temporary name

一時的に使用するファイルが作成できません。

カレントディレクトリにある，ファイルcar_exec??（??は00〜99）を削除するか，移動してください。

4

car_tar_Z: 〜 : file not found

ファイルが見つかりません。

coreファイルおよび-iオプションで指定した実行ファイルを確認してください。

5

car_tar_Z: 〜 : not supported platform

サポートしていないOSです。

注意事項

カレントディレクトリに書き込み権限が必要です。

同じディレクトリ下で，同じcoreファイルまたは作成時間が同じcoreファイルに対して，car_tar_Zコマンドおよびcar_tar_gzコマンドは同時に実行できません。

システムにtarコマンドおよびcompressコマンドがインストールされている必要があります。

car_tar_Zコマンド実行中に強制終了した場合，カレントディレクトリにcar_tar_Zコマンドが作成した一時的なファイルやディレクトリが残ります。

一時的に作成されるファイル：car_exec??（??は，00〜99）

一時的に作成されるディレクトリ：carYYMMDDhhmm/（YYMMDDhhmmは，coreファイルの作成年月日時分）

javacore（coreファイルとスレッドダンプの取得）

形式

javacore [-i|-f] [-force] -p <プロセスID>

機能

コマンド実行時のcoreファイルとスレッドダンプを同時に取得します。

引数

-i

coreファイルおよびスレッドダンプの出力処理の実行を確認するメッセージが表示されます。表示されたメッセージに対してyまたはnを入力します。このとき，yを入力するとスレッドダンプが出力されます。nを入力すると，何も出力しないで処理を終了します。省略した場合，-fオプションが指定されないかぎり，このオプションは有効です。

-f

-iオプションを無効にします。省略した場合，-iオプションが有効になります。

-force

Javaプロセスが作成する/tmp/hsperfdata_<ユーザ名>/<プロセスID>ファイルの有無の確認をしないで，-pオプションで指定したプロセスIDのJavaプロセスに対してcoreを出力させます。

-p <プロセスID>

<プロセスID>には，coreファイルとスレッドダンプを取得するJavaプログラムのプロセスIDを指定します。

戻り値

0：

正常終了しました。

1：

異常終了しました。

2：

一定時間内にcore生成処理終了の応答がありませんでした。

入力例

-fオプションを省略してjavacoreコマンドを実行します。

javacore -p 8326

coreファイルおよびスレッドダンプの出力処理の実行を確認するメッセージが表示されます。

send SIGQUIT to 8326:?(y/n)

coreファイルおよびスレッドダンプを取得する場合はyを，取得しない場合はnを入力します。

send SIGQUIT to 8326:?(y/n)y

coreファイルおよびスレッドダンプを取得すると，実行中のJavaプログラムでは次のメッセージが出力されます。

Now generating core file (javacore8662.030806215140.core)...
done

(スレッドダンプを出力)

Writing Java core to javacore8662.030806215140.txt... OK

実行中のJavaプログラムは，カレントディレクトリに次のファイルを作成し，プログラムを継続します。

coreファイル

javacore<プロセスID>.<日時>.core

スレッドダンプ

javacore<プロセスID>.<日時>.txt

出力メッセージ

次のエラーメッセージまたは警告メッセージを出力した場合，coreファイルやスレッドダンプは取得されません。

表6‒6　javacoreコマンドで出力されるエラーメッセージ

項番

エラーメッセージ

説明

1

usage: javacore [-f|-i] [-force] -p process-id

コマンドの引数が不正です。

2

javacore: can't create work file at /tmp, this request canceled

/tmpに参照および書き込み権限がありません。

3

javacore: illegal option --<オプション>

コマンドの引数に指定した<オプション>が不正です。

4

javacore: unexpected error occurred:<エラー原因>

コマンド実行中に予期しないエラーが発生しました。

5

javacore: please delete <削除できなかったファイル名> in <削除できなかったファイルのフルパス>

コマンド終了時にjavacoreコマンドの内部処理で作成したファイルを削除できませんでした。<削除できなかったファイルのフルパス>にある，削除できなかったファイルを削除してください。

6

<プロセスID>: No such process

javacoreコマンドの引数に指定した<プロセスID>に該当するプロセスがありません。または，javacoreコマンドで指定した<プロセスID>に該当するプロセスがJavaプロセス以外でした。

7

<プロセスID>: Not owner

実行ユーザは，コマンドの引数に指定した<プロセスID>に該当するプロセスのオーナーではありません。

8

<プロセスID>: Now processing previous request, this request canceled

コマンドの引数に指定した<プロセスID>のプロセスが現在coreを生成中です。

9

<プロセスID>: Timeout occurred. Java process not responding.

コマンドの引数に指定した<プロセスID>に該当するプロセスから，一定時間内にcore出力処理終了の応答がありませんでした。

注意事項

javacoreコマンドは，SIGQUITシグナルを指定されたプロセスに送信します。誤ってJavaプログラム以外を指定すると，ほかのプログラムが停止することがあります。

同じJavaプロセスに対して，同時にjavacoreコマンドは実行できません。前回のjavacoreコマンドによるcore出力処理が終了したあとに実行してください。

JavaVMプロセスが，スレッドダンプ取得要求に反応しないで無応答状態になっている場合には，javacoreコマンドによるcoreファイルも取得できません。この場合は，kill -6コマンドの実行によって，JavaVMプロセスを強制停止させてcoreファイルを取得してください。

Linuxの場合，gdbのgcoreコマンドでcoreを生成します。gdbがインストールされていない場合には，次のエラーメッセージが標準出力に出力されます。

Error occurred in generating core file, gdb not found.

また，インストールされているgdbのバージョンが古い場合には，次のエラーメッセージが標準出力に出力されます。

Error occurred in generating core file, gdb version 5.2 or later needed.

javacoreコマンドは，実行時に，/tmp/hsperfdata_<ユーザ名>/<プロセスID>ファイルを使用します。該当するファイルが存在しない場合は，javacore コマンドによるcoreファイルの出力はできません。ただし，-forceオプションを指定した場合，/tmp/hsperfdata_<ユーザ名>/<プロセスID>ファイルの有無の確認をしないで，-pオプションで指定したプロセスIDのJavaプロセスに対してcoreを出力させます。

javagc（GCの強制発生）

形式

javagc [-i|-f] [-v] [-s] [-force] [-ehgc] -p <プロセスID>

機能

メモリリーク，システム障害およびアプリケーションのデバッグのために，プロセスIDが<プロセスID>のJavaプロセスに対して，任意のタイミングでFullGCを発生させます。

Javaプロセスとの通信にはSIGQUITシグナルを使用します。コマンドを実行すると，コマンドの処理内容をユーザに確認します。n（発生させない，実行しない，または送信しない）と回答した場合には，コマンドの処理は実行されません（戻り値が1となります）。この確認動作は，-fオプションを指定することで省略できます。

<プロセスID>のJavaプロセスが通常の要因で発生するCopyGCやFullGCを実行中の場合は，その終了を待ってからコマンドを実行します。

引数

-i

次に示すコマンドの処理内容をユーザに確認します。

GCを発生させるためにSIGQUITシグナルを送信させるかどうか

このオプションより前に指定した，-fオプションを無効にします。

-f

次に示すコマンドの処理内容をユーザに確認しません。

GCを発生させるためにSIGQUITシグナルを送信させるかどうか

このオプションより前に指定した，-iオプションを無効にします。

-v

-XX:+HitachiVerboseGCオプションの指定がなくても，JavaVMログファイル作成の規則に従ってJavaVMログファイルを作成して，拡張verbosegc情報を出力します。

その際，以下のオプション値も反映した内容の拡張verbosegc情報を出力します。

-XX:+HitachiVerboseGCPrintDate

-XX:+HitachiVerboseGCPrintCause

-XX:+HitachiVerboseGCCpuTime

-XX:+HitachiCommaVerboseGC

-s

標準出力に拡張verbosegc情報を出力します。

その際，以下のオプション値も反映した内容の拡張verbosegc情報を出力します。

-XX:+HitachiVerboseGCPrintDate

-XX:+HitachiVerboseGCPrintCause

-XX:+HitachiVerboseGCCpuTime

-XX:+HitachiCommaVerboseGC

-force

Javaプロセスが作成する/tmp/hsperfdata_<ユーザ名>/<プロセスID>ファイルの有無の確認をしないで，-pオプションで指定したプロセスIDのJavaプロセスに対してGCを実行します。

-ehgc

このオプションは使用できません。

-p <プロセスID>

FullGCを実行したいプロセスIDを指定します。

日立JavaVM拡張オプションについては，次の個所を参照してください。

「5.1　日立JavaVM拡張オプションの一覧」

「5.2　日立JavaVM拡張オプションの詳細」

戻り値

0：

正常終了しました。

1：

異常終了しました。

2：

一定時間内にGC処理終了の応答がありませんでした。

入力例

-iオプションを指定してjavagcコマンドを実行します。

javagc -i -v -p 8326

プロセスIDの確認メッセージが表示されます。

send SIGQUIT to 8326:?(y/n)

SIGQUITシグナルを送信させる場合はyを，送信させない場合はnを入力します。

send SIGQUIT to 8326:?(y/n)y

出力例

[VGC]<Wed Mar 17 00:42:30 2004>(Skip Full:0,Copy:0)[Full GC 149K->149K(1984K), 0.0786038 secs][DefNew::Eden: 264K->0K(512K)][DefNew::Survivor: 0K->63K(64K)][Tenured: 85K->149K(1408K)][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:JavaGC Command]

出力メッセージ

表6‒7　javagcコマンドで出力されるメッセージ

項番

メッセージ

説明

1

javagc [-f|-i][-v][-s] [-force] [-ehgc] -p process-id

javagcコマンドへの引数の指定が間違っています。

2

javagc: illegal option--<オプション>

javagcコマンドに指定した<オプション>が不正です。

3

<プロセスID>: No such process

javagcコマンドの引数に指定した<プロセスID>に該当するプロセスがありません。または，javagcコマンドで指定した<プロセスID>に該当するプロセスがJavaプロセス以外でした。

4

<プロセスID>: Not owner

実行ユーザは，javagcコマンドの引数に指定した<プロセスID>に該当するプロセスのオーナーではありません。

5

<プロセスID>: Now processing previous request, this request canceled

javagcコマンドの引数に指定した<プロセスID>に該当するプロセスは，前回のjavagcコマンドによるGCを実行中です。javagcコマンドによるGC実行要求はキャンセルされます。

6

javagc: can't create work file at /tmp, this request canceled

/tmpに参照および書き込み権限がないため，GC要求ファイルが作成できません。javagcコマンドによるGC実行要求はキャンセルされます。

7

javagc: unexpected error occurred:<エラー原因>

javagcコマンド実行中に予期しないエラーが発生しました。

<エラー原因>には，例えば下記のような表示がされます。

作業用メモリ確保に失敗した場合

malloc systemcall fail (errno=Y)

オブジェクトのクローズに失敗した場合

close systemcall fail (errno=Y)

8

<プロセスID>: Timeout occurred. Java process not responding.

javagcコマンドの引数に指定した<プロセスID>に該当するプロセスから，一定時間内にGC処理終了の応答がありませんでした。

9

javagc : please delete <削除できなかったファイル名> in <削除できなかったファイルのフルパス>

javagcコマンドを終了したときに，内部ファイルを削除できませんでした。削除できなかったファイルのフルパスにある，削除できなかったファイルを削除してください。

10

<プロセスID>: Failed to retry GC. Java process is GC locked.

javagcコマンドに引数に指定した<プロセスID>に該当するプロセスが，GC実行が抑止された状態で，GC処理が実行できませんでした。

注意事項

同じJavaプロセスに対して，同時にjavagcコマンドは実行できません。前回のjavagcコマンドによるGC処理が終了してから実行してください。前回のGC処理が終了している場合は，JavaVMログファイルに出力される拡張verbosegc機能のGCの要因に"JavaGC Command"が出力されます。

javagcコマンドはSIGQUITシグナルを指定されたプロセスIDに送信します。誤ってJavaプロセス以外のプロセスIDを指定すると，ほかのプログラムが停止することがあります。

javagcコマンド実行時に，/tmp/hsperfdata_<ユーザ名>/<プロセスID>ファイルを使用します。該当するファイルが存在しない場合は，javagcコマンドによるGCの要求はできません。ただし，-forceオプションを指定した場合，/tmp/hsperfdata_<ユーザ名>/<プロセスID>ファイルの有無の確認をしないで，-pオプションで指定したプロセスIDのJavaプロセスに対してGCを発生させます。

javatrace（トレース情報の収集）

形式

javatrace <coreファイル名> <実行ファイル名> [<出力ファイル名>] [-l <ライブラリファイル名> ...]

機能

coreファイルからスタックトレース情報を取得します。

このコマンドは，JavaVMが異常終了してcoreファイルを生成した場合，その異常終了の原因究明に必要な情報を取得するために実行するコマンドです。プロセスダウン時の詳細要因などが調査できます。

引数

<coreファイル名>

coreファイル名を指定します。

<実行ファイル名>

coreファイルを生成した実行ファイル名を指定します。

<出力ファイル名>

出力ファイル名を指定します。

省略した場合は，カレントディレクトリの"javatrace.log"に出力されます。

-l <ライブラリファイル名>

使用したライブラリファイルを指定します。

共用ライブラリが絶対パスで実行ファイルに取り込まれている場合は，自動的に読み込まれるため，指定する必要はありません。

戻り値

0：

正常終了しました。

1：

異常終了しました。

入力例

JavaVMが異常終了してcoreファイルを生成した場合，次のメッセージが表示されます。このメッセージ内のjavatraceコマンドの文字列を実行します。

なお，このメッセージは，異常終了時に生成されるエラーリポートファイル（hs_err_pid<プロセスID>.log）にも出力されます。

  ：
# You can get further information from javatrace.log file generated
# by using javatrace command.
# usage: javatrace core-file-name loadmodule-name [out-file-name] [-l(library-name)...]
# Please use javatrace command as follows and submit a bug report
# to Hitachi with javatrace.log file:
# [/opt/Cosminexus/jdk/bin/javatrace core /opt/Cosminexus/CC/server/bin/cjstartsv]
#

coreファイル名がcoreの場合

<JDKインストールディレクトリ>/bin/javatrace core <JDKインストールディレクトリ>/bin/java

OSによっては実際に出力されるcoreファイル名がcore.<プロセスID>になる場合があります。その場合は，実際に出力されたcoreファイル名をjavatraceの引数に指定してください。

coreファイル名がcore.<プロセスID>の場合

<JDKインストールディレクトリ>/bin/javatrace core.8326 <JDKインストールディレクトリ>/bin/java

出力メッセージ

次のエラーメッセージまたは警告メッセージを出力した場合，スタックトレース情報は出力されません。

表6‒8　javatraceコマンドで出力されるエラーメッセージ

項番

エラーメッセージ

説明

1

usage : javatrace core-file-name loadmodule-name [out-filename] [-llibrary-name...]

javatraceコマンドへの引数の指定が間違っています。

2

javatrace: Cannot open file-name :No such file or directory

<出力ファイル>で指定したファイル以外のファイル（file-name）が見つかりません。

3

javatrace: Cannot open file-name : Permission denied

ファイル（file-name）の読み込みが許可されていません。

4

javatrace : Cannot create file-name : Already exist

<出力ファイル>に指定したファイル（file-name）がすでに存在しています。

5

* unknown core type(XXXXXXX) ignored.

<coreファイル名>で指定したファイルは，coreファイルではありません。

6

* ERROR : file-name, unknown magic(0xXXXX)

<実行ファイル名>で指定したファイルは，実行ファイルではありません。

7

WARNING : core file may not match loadmodule (core file from 'loadmodule-name')

<実行ファイル名>で指定した実行ファイルと，<coreファイル名>で指定したcoreファイルから取り出した実行ファイル（loadmodule-name）が一致していません。

8

javatrace : Bad argument : argument-name is directory

指定したファイル（file-name）はディレクトリです。

9

* ERROR : library-name open : No such file or directory

実行ファイルが取り込んだ共用ライブラリ（library-name）が見つかりません。共用ライブラリが相対パスで取り込まれている場合には，-lオプションで共用ライブラリを明示的に指定する必要があります。

10

javatrace : illegal option -- x

誤ったオプション文字（x）が指定されています。

11

javatrace : Cannot create file-name : Permission denied

<出力ファイル>で指定したファイル（file-name）の出力先に書き込み権限がありません。

注意事項

javatraceコマンドはcoreファイルが生成されたマシンで実行してください。

JavaVMが異常終了した場合に標準出力とエラーリポートファイルに出力されるメッセージで，javatraceコマンドの第2引数が，次のように絶対パスのロードモジュール名になっていないことがあります。

#
# You can get further information from javatrace.log file generated
# by using javatrace command.
# usage: javatrace core-file-name loadmodule-name [out-file-name] [-l(library-name)...]
# Please use javatrace command as follows and submit a bug report
# to Hitachi with javatrace.log file:
# [/opt/Cosminexus/jdk/bin/javatrace /users/Java/core ../java]
#

その場合は，javatraceコマンドの第2引数に指定するロードモジュール名を，絶対パスに変換してから実行してください。

jheapprof（クラス別統計情報付き拡張スレッドダンプの出力）

形式

jheapprof [-i|-f] [-class <クラス名>] [-staticroot|-nostaticroot]
          [-explicit|-noexplicit] [-fullgc|-copygc|-nogc]
          [-garbage|-nogarbage] [-rootobjectinfo|-norootobjectinfo]
          [-rootobjectinfost <値> ] [-force] -p <プロセスID>

機能

引数に指定したプロセスIDのJavaプロセスについて，クラス別統計情報を含んだ拡張スレッドダンプを出力します。

引数

-i

クラス別統計情報付き拡張スレッドダンプの出力処理の実行を確認するメッセージが表示されます。表示されたメッセージに対してyまたはnを入力します。このとき，yを入力すると，クラス別統計情報を含んだ拡張スレッドダンプが出力されます。nを入力すると，何も出力しないで処理を終了します。省略した場合，-fオプションが指定されないかぎり，このオプションは有効です。

-f

-iオプションを無効にします。省略した場合，-iオプションが有効になります。

-class <クラス名>

<クラス名>に指定したクラス（インスタンス）をメンバに持つクラスの構造を一覧にしてスレッドダンプ中に出力します。

-staticroot

staticフィールドを基点とした参照関係情報出力機能を有効にし，staticフィールドを基点とした参照関係情報を出力します。省略した場合，-nostaticrootオプションが指定されない限り，このオプションは有効です。

このオプションの前提は，-classオプションです。-classオプションの指定がない場合，このオプションは無効になります。

なお，このオプションとnostaticrootオプションを同時に指定している場合，最後に指定しているオプションが有効になります。

-nostaticroot

staticフィールドを基点とした参照関係情報出力機能を無効にします。省略した場合，-staticrootオプションが有効になります。

なお，このオプションと-staticrootオプションを同時に指定している場合，最後に指定しているオプションが有効になります。

-explicit

このオプションは使用できません。

-noexplicit

このオプションは使用できません。

-fullgc

統計する前に実行するGCにFullGCを設定します。省略した場合，-copygcオプションや-nogcオプションが指定されないかぎり，このオプションは有効です。なお，このオプションと-copygcオプションまたは-nogcオプションを同時に指定している場合，最後に指定しているオプションが有効になります。

-copygc

統計する前に実行するGCにCopyGCを設定します。このオプションと-nogcオプションを省略した場合，-fullgcオプションが有効になります。

なお，このオプションと-fullgcオプションまたは-nogcオプションを同時に指定している場合，最後に指定しているオプションが有効になります。

-nogc

統計する前にGCを実行しません。このオプションと-copygcオプションを省略した場合，-fullgcオプションが有効になります。なお，このオプションと-fullgcオプションまたは-copygcオプションを同時に指定している場合，最後に指定しているオプションが有効になります。

-garbage

Tenured領域内不要オブジェクト統計機能が有効になり，Tenured領域内の不要なオブジェクトを統計対象としたクラス別統計情報を出力します。また，インスタンス統計機能とSTATICメンバ統計機能は無効になります。省略した場合，-nogarbageオプションが有効になります。統計前GC選択機能については，-fullgcオプション，-copygcオプションが無効になり，-nogcオプションは有効になります。このため，統計処理前にGCを実行しません。なお，このオプションと-nogarbage オプションを同時に指定している場合，最後に指定しているオプションが有効になります。

-nogarbage

Tenured領域内不要オブジェクト統計機能が無効になります。そのため，Tenured領域内の不要なオブジェクトを統計対象としたクラス別統計情報は出力しません。省略した場合，-garbageオプションが指定されないかぎり，このオプションは有効です。なお，このオプションと-garbageオプションを同時に指定している場合，最後に指定しているオプションが有効になります。

-rootobjectinfo

Tenured増加要因の基点オブジェクトリスト出力機能が有効になり，Tenured増加要因の基点オブジェクトリストを出力します。

このオプションは，-garbageオプションが有効であることが前提です。そのため，-nogarbageオプションを有効にすると，このオプションは無効になります。省略した場合，-norootobjectinfoオプションが指定されないかぎり，このオプションは有効です。なお，このオプションと-norootobjectinfoオプションを同時に指定している場合，最後に指定しているオプションが有効になります。

-norootobjectinfo

Tenured増加要因の基点オブジェクトリスト出力機能が無効になります。そのため，Tenured増加要因の基点オブジェクトリストは出力しません。省略した場合，-rootobjectinfoオプションが有効になります。なお，このオプションと-rootobjectinfoオプションを同時に指定している場合，最後に指定しているオプションが有効になります。

-rootobjectinfost <値>

Tenured増加要因の基点オブジェクトリストの情報量を調節します。インスタンスサイズの合計が，指定した<値>以上のクラス情報だけが，Tenured増加要因の基点オブジェクトリストに出力されます。省略した場合，0が設定されます。

このオプションは，-rootobjectinfoオプションが有効であることが前提です。そのため，-norootobjectinfoオプションを有効にすると，このオプションは無効になります。<値>には0以上の自然数を指定できます。自然数以外や，文字列を指定した場合は，引数の指定に誤りがあるという内容のエラーメッセージが出力されて終了します。

-force

Javaプロセスが作成する/tmp/hsperfdata_<ユーザ名>/<プロセスID>ファイルの有無の確認をしないで，-pオプションで指定したプロセスIDのJavaプロセスに対して拡張スレッドダンプの出力を要求します。

-p <プロセスID>

<プロセスID>には，クラス別統計情報を出力するJavaプログラムのプロセスIDを指定します。

戻り値

0：

正常終了しました。

1：

異常終了しました。

2：

一定時間内にクラス別統計情報出力処理終了の応答がありませんでした。

入力例

-fオプションを省略してjheapprofコマンドを実行します。

% jheapprof -p 2463

プロセスIDの確認メッセージが表示されます。

send SIGQUIT to 2463: ? (y/n)

SIGQUITシグナルを送信させる場合はyを，送信させない場合はnを入力します。

send SIGQUIT to 2463: ? (y/n)y

クラス別統計情報付き拡張スレッドダンプを出力すると，実行中のJavaプログラムでは次のメッセージが出力されます。

Writing Java core to javacore2463.030806215140.txt... OK

実行中のJavaプログラムは，カレントディレクトリにクラス別統計情報付き拡張スレッドダンプ（javacore<プロセスID>.<日時>.txt）を作成し，プログラムを継続します。

出力形式

クラス別統計情報の出力形式については，「4.9　クラス別統計情報解析機能」を参照してください。

出力メッセージ

次のエラーメッセージまたは警告メッセージが出力された場合，クラス別統計情報付き拡張スレッドダンプは出力されません。

表6‒9　jheapprofコマンドで出力されるメッセージ

項番

エラーメッセージ

説明

1

usage: jheapprof [-f|-i] [-class classname] [-staticroot|-nostaticroot] [-explicit|-noexplicit] [-fullgc|-copygc|-nogc] [-garbage|-nogarbage] [-rootobjectinfo|-norootobjectinfo] [-rootobjectinfost size] [-force] -p process-id

jheapprofコマンドへの引数の指定が間違っています。

2

jheapprof: illegal option -- <オプション>

jheapprofコマンドに指定した<オプション>が不正です。

3

<プロセスID>: Now processing previous request, this request canceled

jheapprofコマンドの引数に指定した<プロセスID>に該当するプロセスが現在クラス別統計情報の出力中です。

4

<プロセスID>: No such process

jheapprofコマンドの引数に指定した<プロセスID>に該当するプロセスがありません。または，jheapprofコマンドで指定した<プロセスID>に該当するプロセスがJavaプロセス以外でした。

5

<プロセスID>: Not owner

jheapprofコマンドの引数に指定した<プロセスID>のプロセスのオーナーではありません。

6

jheapprof: can't create work file at /tmp , this request canceled

一時ファイル用ディレクトリに参照・書き込み権限がない場合，クラス別統計情報付き拡張スレッドダンプを出力できません。クラス別統計情報付き拡張スレッドダンプの出力要求はキャンセルされます。

7

jheapprof: please delete <削除できなかったファイル名> in <削除できなかったファイルのフルパス>

jheapprofコマンドを終了したときに，内部ファイルを削除できませんでした。削除できなかったファイルのフルパスにある，削除できなかったファイルを削除してください。

8

jheapprof: unexpected error occurred: <エラー原因>

jheapprofコマンド実行中に予期しないエラーが発生しました。

<エラー原因>には，例えば下記のような表示がされます。

作業用メモリ確保に失敗した場合

malloc systemcall fail (errno=Y)

オブジェクトのクローズに失敗した場合

close systemcall fail (errno=Y)

9

<プロセスID>: Timeout occurred. Java process not responding

jheapprofコマンドの引数に指定した<プロセスID>に該当するプロセスから，一定時間内にクラス別統計情報出力処理終了の応答がありませんでした。

注意事項

jheapprofコマンドはプログラムの開発用ユーティリティとして提供されているものです。システムの運用では使用しないでください。

同じJavaプロセスに対して，同時にjheapprofコマンドは実行できません。前回のjheapprofコマンドによるクラス別統計情報が拡張スレッドダンプに出力されたあとに実行してください。

引数に指定したプロセスIDのJavaプロセスオーナーではないユーザがこのコマンドを実行すると，メッセージが出力されて，処理は終了します。ただし，ユーザがrootである場合は，処理を継続します。

jheapprofコマンドは，SIGQUITシグナルを指定されたプロセスに送信します。誤ってJavaプログラム以外を指定すると，ほかのプログラムが停止することがあります。

jheapprofコマンド実行時に，/tmp/hsperfdata_<ユーザ名>/<プロセスID>ファイルを使用します。該当するファイルが存在しない場合，jheapprofコマンドによるクラス別統計情報出力はできません。

G1GCを使用中にjheapprofコマンドを使用した場合，次のエラーメッセージを出力してスレッドダンプを出力しません。

jheapprof: can't use jheapprof and g1gc at the same time.

クラス別統計情報を取得するため，jheapprofコマンド実行中のJavaプロセスは，ほかの処理をすべて停止して処理を実行します。

jheapprofanalyzer（クラス別統計情報解析ファイルのCSV出力）

形式

jheapprofanalyzer [-J <オプション名>] [<ファイル名> ...]

機能

クラス別統計情報解析ファイルをCSV形式で出力します。

クラス別統計情報解析ファイルで使用する入力ファイルについては，「4.9　クラス別統計情報解析機能」を参照してください。

引数

-J <オプション名>

<オプション名>には，次のオプションを指定できます。また，次のオプション以外を指定した場合は，動作保証の対象外となります。

-Xms

メモリ割り当てプールの初期サイズをバイト数で指定します。

-Xmx

メモリ割り当てプールの最大サイズをバイト数で指定します。

-DJP.co.Hitachi.soft.jvm.tools.jheapprofanalyzer.threshold=num

num: インスタンス合計サイズのしきい値を設定します。範囲は0〜2⁶³-1 （Long.MAX_VALUE）です。インスタンス合計サイズがnum以上のクラスだけ出力します。デフォルト値は，1024です。

<ファイル名>

クラス別統計情報付き拡張スレッドダンプファイルを指定できます。ファイル名称の規定は，特にありません。また，ファイルの指定は，順不同であり，数に制限はありません。

戻り値

0：

正常終了しました。

1以上：

異常終了しました。

入力例

jheapprofanalyzer -J-Xms1024m -J-Xmx1024m -J-DJP.co.Hitachi.soft.jvm.tools.jheapprofanayzer.threshold=5000
javacore22356.080523161703.txt  javacore22356.080523161711.txt

出力形式

クラス別統計情報解析ファイルの出力形式については，「4.9　クラス別統計情報解析機能」を参照してください。

出力メッセージ

次のエラーメッセージが出力された場合，クラス別統計情報解析ファイルは出力されません。また，次のエラーメッセージ以外が出力された場合は，デフォルトの例外処理となります。

表6‒10　jheapprofanalyzerコマンドで出力されるエラーメッセージ

項番

エラーメッセージ

説明

出力後の動作

1

usage: jheapprofanalyzer [options] file...

where options include:

-J-Xms<size> set initial Java heap size

-J-Xmx<size> set maximum Java heap size

-J-DJP.co.Hitachi.soft.jvm.tools.jheapprofanalyzer.threshold=<num> set instance total size threshold

JheapprofAnalyzerクラスへの引数の指定が間違っています。

(a)

2

JheapprofAnalyzer: Illegal property value<num>. Default is assumed.

JP.co.Hitachi.soft.jvm.tools.jheapprofanalyzer.thresholdの<num>に数字以外を指定しました。または<num>が範囲外となっています。

(b)

3

JheapprofAnalyzer: can't open input file<ファイル名>

ディレクトリに<ファイル名>がありません。または，別の原因でファイルを開けません。

(c)

4

JheapprofAnalyzer: can't read input file<ファイル名>

<ファイル名>の読み込みに失敗しました。

(c)

5

JheapprofAnalyzer: Illegal input file format<ファイル名>

<ファイル名>は，クラス別統計情報付き拡張スレッドダンプファイルではありません。

(c)

6

JheapprofAnalyzer: can't open output file<ファイル名>

出力ファイルが開けません。

エラーの原因として，次の状態が考えられます。

出力ファイルがディレクトリとなっています。

出力ファイルがありません。

別の原因で出力ファイルを開けません。

(a)

7

JheapprofAnalyzer: can't write output file<ファイル名>

<ファイル名>の書き込みに失敗しました。

(a)

（凡例）

(a)：エラーとなり処理を終了します。

(b)：デフォルトを仮定して処理を続行します。

(c)：処理を続行し，指定したすべての入力ファイルのエラーチェックをします。

注意事項

クラス別統計情報解析機能では，日付を取得するときと，データを読み込むときにファイルを開きます。そのため，コマンド実行中に入力ファイルの更新および削除の操作をした場合の結果は保証されません。

7　トラブルシューティングに使用する資料の詳細

この章では，トラブルシューティングで使用するログやトレース情報について説明します。

7.1　日立JavaVMのスレッドダンプ

日立JavaVMのスレッドダンプを調査すると，システムのデッドロックなどのJavaプログラムレベルでのトラブル要因の調査が容易になります。

出力される情報の種類は，アプリケーションサーバの起動時に指定しているオプションによって異なります。起動オプションについては「5.　日立JavaVM起動オプション」を，起動オプションのデフォルト値についてはマニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。また，日立JavaVMの資料取得の方法については，「3.　トラブルシューティング」を参照してください。

7.1.1　スレッドダンプ情報の構成

日立JavaVMのスレッドダンプ情報の構成を次の表に示します。

表7‒1　スレッドダンプ情報の構成

出力情報

内容

ヘッダ

日付，JavaVMバージョン情報，起動コマンドラインを出力します。

システム設定

次の情報を出力します。

JDKの実行環境のインストール場所を表すJavaホームパス

JDKを構成するライブラリのインストールディレクトリを表すJava DLLパス

システムクラスパス

Javaコマンドオプション

動作環境

次の情報を出力します。

ホスト名

OSバージョン

CPU情報

リソース情報

Javaヒープ情報

Javaヒープの各世代のメモリ使用状況を出力します。

JavaVM内部メモリマップ情報

JavaVM自身の確保しているメモリの領域情報を出力します。

JavaVM内部メモリサイズ情報

JavaVM自身の確保しているメモリのサイズ情報を出力します。

アプリケーション環境

次の情報を出力します。

シグナルハンドラ

環境変数

ライブラリ情報

ローディングされているライブラリの情報を出力します。

スレッド情報

<スレッド1>

:

<スレッドn>

スレッドごとにスレッド情報を出力します。

Javaモニタダンプ※

Javaモニタオブジェクトの一覧を表示します。

JNIグローバル参照情報

JavaVMが保持しているJNIのグローバル参照の数を出力します。

クラス別統計情報

jheapprofコマンドで指定したJavaプロセスのクラスごとに次の情報を出力します。

インスタンスがメンバとして持つインスタンスの合計サイズ，およびインスタンスの参照関係

staticメンバが持つインスタンスの合計サイズ

Tenured領域の増加原因となるオブジェクトのクラス，およびインスタンスの合計サイズ

フッタ

スレッドダンプが終了した時刻を表示します。

注※　notify待ちの一覧が表示されないことがあります。

日立JavaVMのスレッドダンプ情報の詳細については，「-XX:[+|-]HitachiThreadDump（拡張スレッドダンプ情報出力オプション）」を参照してください。なお，クラス別統計情報については，「4.2　クラス別統計機能」を参照してください。

7.2　日立JavaVMのGCログ

GCのログは，JavaVMログファイルに出力されます。

詳細については，「7.3　JavaVMログ（JavaVMログファイル）」を参照してください。

7.3　JavaVMログ（JavaVMログファイル）

JavaVMログファイルは，日立JavaVMが標準のJavaVMに追加した拡張オプションを使用して出力されます。このログを取得するためには，対象のアプリケーションサーバを起動するときに必要なオプションを指定しておく必要があります。

7.3.1　JavaVMログファイルを出力するオプション

JavaVMログファイルを出力するオプションを次に示します。

-XX:+HitachiOutOfMemoryStackTrace

OutOfMemoryError発生時にスタックトレースを出力するオプションです。なお，このオプションを指定した場合に同時に指定される，-XX:+HitachiOutOfMemorySizeおよび-XX:+HitachiOutOfMemoryCauseが指定された場合も，JavaVMログファイルが出力されます。

-XX:+HitachiVerboseGC

GCが発生したときの拡張verbosegc情報を出力するオプションです。拡張verbosegc情報の取得については，「7.3.2　拡張verbosegc情報の取得」を参照してください。

-XX:+HitachiJavaClassLibTrace

System.gc()，System.exit()，Runtime.exit()，またはRuntime.halt()のどれかのAPIを実行したときに，これらのAPIの呼び出しトレースを出力するオプションです。

なお，-XX:HitachiJavaClassLibTraceLineSizeオプションを指定している場合，出力されるトレースは，指定した文字数（バイト数）以内で出力されます。1行の文字数が指定した値を超える場合は，「at」以降の文字列の前半部分が削除されて，指定した文字数分出力されます。

-XX:+JITCompilerContinuation

JITコンパイラ稼働継続機能を有効にするオプションです。JITコンパイルがアプリケーションを構成するメソッドの論理矛盾で失敗すると，JITコンパイラ稼働継続機能のログがJavaVMログファイルに出力されます。

それぞれのオプションを指定した場合の出力内容の詳細については，次の個所を参照してください。

「-XX:[+|-]HitachiOutOfMemoryStackTrace（スタックトレース出力オプション）」

「-XX:[+|-]HitachiVerboseGC（拡張verbosegc情報出力オプション）」

「-XX:[+|-]HitachiJavaClassLibTrace（クラスライブラリのスタックトレース出力オプション）」

「-XX:[+|-]JITCompilerContinuation（JITコンパイラ稼働継続機能オプション）」

7.3.2　拡張verbosegc情報の取得

次の表に示すオプションを指定すると，拡張verbosegc情報を取得できます。拡張verbosegc情報からは，そのサーバで必要とするJavaヒープ領域サイズ，Metaspace領域サイズなどを見積もるための情報が取得できます。なお，Javaログには，OutOfMemoryError発生時のスタックトレースも出力されます。

表7‒2　拡張verbosegc情報の取得を指定するオプション

オプション

意味

-XX:+HitachiVerboseGC

拡張verbosegc情報を出力するかどうかを指定します。GCの内部領域であるEden，Survivor，Tenured，Metaspace領域種別ごとに情報を出力します。デフォルトでは出力されません。-XX:+HitachiVerboseGCと指定すると拡張verbosegc情報が出力され，-XX:-HitachiVerboseGCと指定すると拡張verbosegc情報は出力されません。

-XX:+HitachiVerboseGCPrintDate

拡張verbosegc情報を出力するログの各行の先頭に，ログを出力した日付を表示するかどうかを指定します。

-XX:+HitachiVerboseGCCpuTime

GCの開始から終了までの間で，GCの実行スレッドのユーザモードおよびカーネルモードに費やされた時間だけを表示するか，GCの開始から終了までの実時間を表示するかを指定します。

-XX:HitachiVerboseGCIntervalTime=<時間間隔>

-XX:+HitachiVerboseGCに対する出力時間の間隔を数値（単位：秒）で指定します。時間間隔のデフォルト値は0（GC発生のたびに出力）です。なお，時間間隔を指定すると，その時間間隔の間に発生したGC回数も表示されます。

-XX:+HitachiVerboseGCPrintCause

拡張verbosegc情報を出力するログに，GCが発生した原因を表示するかどうかを指定します。

-XX:+HitachiCommaVerboseGC

拡張verbosegc情報を出力するログをCSV形式で出力するかどうかを指定します。CSV形式で出力する場合，拡張verbosegc情報の括弧「( )」「[ ]」「< >」や，区切り「:」はすべて省略され，数値または文字列が「,」で区切られて出力されます。

-XX:+HitachiVerboseGCPrintTenuringDistribution

Survivor領域の年齢分布情報を出力するかどうかを指定します。デフォルトでは出力されません。出力形式や出力情報については，「4.10　Survivor領域の年齢分布情報出力機能」を参照してください。

-XX:+HitachiVerboseGCPrintJVMInternalMemory

JavaVM内部で管理しているヒープ情報をJavaVMログファイルに出力するかどうかを指定します。

-XX:+HitachiVerboseGCPrintThreadCount

Javaスレッドの数を監視するために，Javaスレッドの数をJavaVMログファイルに出力するかどうかを指定します。

-XX:+HitachiVerboseGCPrintDeleteOnExit

java.io.File.deleteOnExit()を呼び出したことによってJavaVMが確保した累積のヒープサイズとメソッドの呼び出し回数を，JavaVMログファイルに出力するかどうかを指定します。

-XX:+PrintCodeCacheInfo

コードキャッシュ領域の使用量を出力するかどうか，また，使用量がしきい値に達したことを知らせるメッセージを出力するかどうかを指定します。

ログファイルの出力形式と出力例を次に示します。

出力形式

[id] <date> (Skip Full:full_count, Copy:copy_count) [gc_kind gc_info, gc_time secs][Eden: eden_info][Survivor: survivor_info][Tenured: tenured_info][Metaspace: metaspace_info][class space: class_space_info]  [cause:cause_info] [User: user_cpu secs] [Sys: system_cpu secs][IM: jvm_alloc_size, mmap_total_size, malloc_total_size][TC: thread_count][DOE: doe_alloc_size, called_count][CCI: cc_used_sizeK, cc_max_sizeK, cc_infoK]

説明

id：JavaVMログファイル識別子

JavaVMログファイル識別子を次の表に示します。この識別子は，ログをログの内容（機能）ごとにフィルタリングして調査する場合に利用できます。

表7‒3　JavaVMログファイル識別子

識別子

ログの内容

CCI

コードキャッシュ領域情報

CLT

クラスライブラリのスタックトレース

JCC

JITコンパイル失敗情報

JMS

JITコンパイルを抑制したJITコンパイラスレッドに関する情報

OMH

OutOfMemoryの発生頻度に関する情報

OOM

OutOfMemoryError発生時の例外情報とスタックトレース

PTD

Survivor領域の年齢分布情報

VGC

拡張verbosegc情報

date：日時

full_count：FullGCをスキップした回数（-XX:HitachiVerboseGCIntervalTimeを指定した場合だけ）

copy_count ：CopyGCをスキップした回数（-XX:HitachiVerboseGCIntervalTimeを指定した場合だけ）

gc_kind：GC種別（Full GCまたはGC）

gc_info：GC情報（GC前の領域長 -> GC後の領域長(領域サイズ)）

(例)　264K->0K(512K)

gc_time：GC経過時間（単位：秒）

eden_info：Eden情報

survivor_info：Survivor情報

tenured_info：Tenured情報

metaspace_info：Metaspace領域情報

class_space_info：CompressedClassSpace情報

cause_info：GCの原因

user_cpu secs：GCスレッドがユーザモードに費やしたCPU時間（単位：秒）

system_cpu secs：GCスレッドがカーネルモードに費やしたCPU時間（単位：秒）

jvm_alloc_size：JavaVM内部で管理している領域のうち，現在使用中の領域のサイズ（mmap_total_sizeとmalloc_total_sizeの合計サイズのうち，現在使用中の領域のサイズ）（-XX:+HitachiVerboseGCPrintJVMInternalMemoryを指定した場合だけ）

mmap_total_size：JavaVM内部で管理している領域のうち，mmapで割り当てたCヒープの総サイズ（-XX:+HitachiVerboseGCPrintJVMInternalMemoryを指定した場合だけ）

malloc_total_size：JavaVM内部で管理している領域のうち，mallocで割り当てたCヒープの総サイズ（-XX:+HitachiVerboseGCPrintJVMInternalMemoryを指定した場合だけ）

thread_count：Javaスレッドの数（-XX:+HitachiVerboseGCPrintThreadCountを指定した場合だけ）

doe_alloc_size：java.io.File.deleteOnExit()を呼び出して確保した累積のヒープサイズ（-XX:+HitachiVerboseGCPrintDeleteOnExitを指定した場合だけ）

called_count：java.io.File.deleteOnExit()の呼び出し回数（-XX:+HitachiVerboseGCPrintDeleteOnExitを指定した場合だけ）

cc_used_size：GC時のコードキャッシュ領域の使用サイズ（単位：キロバイト）（-XX:+PrintCodeCacheInfoを指定した場合だけ）

cc_max_size：コードキャッシュ領域の最大サイズ（単位：キロバイト）（-XX:+PrintCodeCacheInfoを指定した場合だけ）

cc_info：保守情報（-XX:+PrintCodeCacheInfoを指定した場合だけ）

出力例

-XX:+HitachiCommaVerboseGCオプションを指定した場合の出力例を次に示します。

VGC,Fri Jan 23 21:37:50 2004,11,41,0,GC,16886,16886,65088,0.0559806,
4094,0,4096,447,447,448,12345,16439,60544,1116,1116,4096,0,0.0312500, 0.0156250,729,928,0,509,2167,2054,2301,49152,2304
VGC,Fri Jan 23 21:37:55 2004,6,24,0,Full GC,65082,65082,65088,0.4294532,
4094,4094,4096,447,447,448,60541,60541,60544,1116,1116,4096,0,0.0156250, 0.0312500,729,928,0,509,16,170,2301,49152,2304

7.3.3　コードキャッシュ領域に関するログの内容

JavaVMは，呼び出し回数やループ回数が多いJavaメソッドをJITコンパイルして実行することで，処理の高速化を行います。JITコンパイルによって生成されたJITコンパイルコードは，コードキャッシュ領域に配置されます。

通常，コードキャッシュ領域のサイズはデフォルト値で問題ありません。しかし，実行環境やJavaアプリケーションの規模によっては，コードキャッシュ領域のサイズがデフォルト値では枯渇する場合があります。

コードキャッシュ領域が枯渇すると，JavaVMはJITコンパイルを実行できなくなり，Javaアプリケーションの実行で十分な性能が得られないおそれがあります。この場合は，「-XX:[+|-]PrintCodeCacheInfo（コードキャッシュ領域情報出力オプション）」や「-XX:[+|-]PrintCodeCacheFullMessage（コードキャッシュ領域枯渇メッセージ出力オプション）」を有効にして，コードキャッシュ領域の使用量や出力されるメッセージを監視するようにしてください。

これらのオプションについては，「-XX:[+|-]PrintCodeCacheInfo（コードキャッシュ領域情報出力オプション）」および「-XX:[+|-]PrintCodeCacheFullMessage（コードキャッシュ領域枯渇メッセージ出力オプション）」を参照してください。

(1)　コードキャッシュ領域の使用量がしきい値に達したことを知らせるメッセージの出力内容

コードキャッシュ領域の使用量がしきい値に達したことを知らせるメッセージの出力形式を次に示します。

[cc_id]<cc_date>CodeCache usage has exceeded the threshold.[cc_used_sizeK, cc_max_sizeK, cc_infoK]

出力項目について次に示します。

出力項目

説明

cc_id

CCI（JavaVMログファイル識別子）が出力されます。

cc_date

JITコンパイルを実行した日時が出力されます。

cc_used_size

JITコンパイル後のコードキャッシュ領域の使用サイズが出力されます（単位：キロバイト）。

cc_max_size

コードキャッシュ領域の最大サイズが出力されます（単位：キロバイト）。

cc_info

保守情報が出力されます。

(2)　コードキャッシュ領域が枯渇したことを知らせるメッセージの出力内容

コードキャッシュ領域が枯渇したことを知らせるメッセージの出力形式を次に示します。

[cc_id]<cc_date>CodeCache is full. Compiler has been disabled.[cc_used_sizeK, cc_max_sizeK, cc_infoK]

出力項目について次に示します。

出力項目

説明

cc_id

CCI（JavaVMログファイル識別子）が出力されます。

cc_date

JavaメソッドがJITコンパイルの対象になった日時が出力されます。

cc_used_size

JavaメソッドがJITコンパイルの対象になったときのコードキャッシュ領域の使用サイズが出力されます（単位：キロバイト）。

cc_max_size

コードキャッシュ領域の最大サイズが出力されます（単位：キロバイト）。

cc_info

保守情報が出力されます。

7.4　日立JavaVMが出力するメッセージログ（標準出力およびエラーリポートファイル）

日立JavaVMでクラッシュが発生した場合，日立JavaVMによってデバッグ情報が標準出力とエラーリポートファイルに出力されます。

エラーリポートファイルに出力されるのは，次の場合です。

JNIの中でのシグナルが発生したとき

JavaVMでCヒープ不足が発生したとき

JavaVMで予期しないシグナルが発生したとき

JavaVMでInternal Error（内部論理エラー）が発生したとき

ここでは，次の場合のメッセージログの出力内容について説明します。

表7‒4　日立JavaVMが出力するメッセージログ

メッセージの種類

出力先

JNIの中でのシグナルが発生した場合，またはJavaVMでのメッセージ※

標準出力

エラーリポートファイル

Cヒープが不足した場合のメッセージ※

標準出力

エラーリポートファイル

Internal Errorが発生した場合のメッセージ※

標準出力

エラーリポートファイル

スレッド作成に失敗した場合のメッセージ※

標準出力

注※　日立JavaVM独自の出力先または出力内容があります。

なお，スレッド作成に失敗した場合のメッセージは，標準出力だけに出力されます。

7.4.1　シグナルが発生した場合

シグナルが発生した場合，次に示す項目がログ出力されます。出力内容には，日立JavaVMとして拡張された内容が含まれます。

異常終了位置とシグナル種別※

時間情報※

カレントスレッド情報

スタックトレース

シグナル情報の格納先アドレス※

シグナル情報

siginfo情報※

レジスタ情報

スタックの先頭から格納されている情報

スレッド情報

VMの状態

メモリ情報※

Javaヒープの使用状況※

Card tableマップアドレスの表示

Polling pageアドレスの表示

Large pages 確保失敗情報

CodeCache情報

Event情報

ライブラリ

コマンドおよびVMパラメタ※

環境変数

登録済みシグナルハンドラ

マシン情報※

システム名，CPU，実メモリ，およびVM情報

javatrace起動コマンドのコマンドライン※

注※　製品で拡張された出力内容です。

それぞれの出力内容について説明します。

(1)　異常終了位置とシグナル種別

異常終了時の状態に応じて，次のどちらかの内容が出力されます。この内容は，日立JavaVMで拡張された出力内容です。

(a)　シグナルを検出した場合

次のメッセージが出力されます。

#
# A fatal error has been detected by the Java Runtime Environment:

次の内容が出力されます。

シグナルを検出した場合の出力内容

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  <発生したシグナル名>　(<シグナル番号>) at pc=<PCアドレス>, pid=<プロセスID>, tid=<スレッドID>
#
# JRE version: <jreバージョン情報>
# Java VM: Java HotSpot(TM) <VM種別> (<Oracleバージョン情報>-<日立バージョン情報>-<ビルド年月日> mixed mode, <オプション情報>, <GC種別>, <OS名>-<CPU種別>)
# Problematic frame:
# <種別コード>  [<シグナルが発生したライブラリ名>＋<オフセット>]
#

注

シグナルが発生した関数名が取り出せた場合，「<シグナルが発生したライブラリ名>＋<オフセット>」に続いて，その関数名とオフセットが表示されることがあります。

(b)　内部論理エラーが発生した場合

次の内容が出力されます。

内部論理エラーが発生した場合の出力内容

#
#  Internal Error (<ファイル名>:<行数> または，Internal Errorのコード), pid=<プロセスID>, tid=<スレッドID>
#  <内部論理エラー種別>: 内部論理エラーメッセージ
#
#  JRE version: <jreバージョン情報>
#  Java VM: Java HotSpot(TM) <VM種別> (<Oracleバージョン情報>-<日立バージョン情報>-<ビルド年月日> mixed mode, <オプション情報>, <GC種別>, <OS名>-<CPU種別>)
#
#　<coreファイル情報>

注

Internal Errorには，ファイル名および行数の組み合わせ，またはInternal Errorのコードが出力されます。<内部論理エラー種別>には，発生した内部論理エラーの種類によって，"fatal error"，"guarantee(<論理式>) failed"，または"Error"のどれかが出力されます。

(2)　時間情報

次の内容が出力されます。この内容は，日立JavaVMで拡張された出力内容です。

Time: <実行日付> elapsed time: <実行時間> seconds <(実行時間 形式出力)>

注

実行日付の例を次に示します。

例：「Wed Aug 25 14:55:04 2004」

秒単位だけでは実行時間が把握しづらいため，<(実行時間 形式出力)>ではユーザが読みやすいように，(DAYS HOURS MINS SECS)フォーマットで出力します。

(例) elapsed time: 900 seconds (0d 0h 15m 0s)

(3)　カレントスレッド情報

スレッドの種類に応じて次の3種類の情報が出力されます。

Current thread (<アドレス>):  <スレッド名> "<スレッド名称>" [_<状態>, id=<スレッドID>, stack(<開始アドレス>,<終了アドレス>)]

または
Current thread (<アドレス>):  <スレッド名> [_id=<スレッドID>, stack(<開始アドレス>,<終了アドレス>)]

または
Current thread is native thread

(4)　スタックトレース

次の内容が出力されます。ただし，Current threadがJavaThread以外の場合は出力されません。

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
 <スタックトレース>
：

(5)　シグナル情報の格納先アドレス

次の内容が出力されます。この内容は，日立JavaVMで拡張された出力内容です。

siginfo address: <アドレス>, context address: <アドレス>

(6)　シグナル情報

次の内容が出力されます。

siginfo: si_signo= <発生したシグナル番号> (<発生したシグナル名>), si_code: <番号> (<シグナル理由種別>)[, si_errno: <番号>] (, si_pid: <プロセスID> [(current process) | (invalid)] , si_uid: <ユーザID> [, si_status: <終了値またはシグナル番号>]) | (, si_addr: <アドレス>) | (, si_band: <SIGPOLLのバンド番号>)

(7)　siginfo情報

次の内容が出力されます。この内容は，日立JavaVMで拡張された出力内容です。

siginfo structure dump (location: <siginfoのアドレス>)
<siginfoのアドレス> <siginfoのアドレス> <siginfoのアドレス> <siginfoのアドレス>
：
<siginfoのアドレス> <siginfoのアドレス> <siginfoのアドレス> <siginfoのアドレス>

注

<siginfoのアドレス>は16進数で出力されます。

(8)　レジスタ情報

次の内容が出力されます。ただし，内部論理エラーの場合は出力されません。

Registers:<レジスタ情報>
：

注

BSPレジスタの値がデバッガ（gdb）の値と異なって出力されます。これは，デバッガではBSPの指すバッキングストア領域の内容を出力しており，BSPの指す位置を修正しているためです。

(9)　スタックの先頭から格納されている情報

次の内容が出力されます。ただし，内部論理エラーの場合は出力されません。

Top of Stack: (sp=<スタックポインタのアドレス>)
<アドレス>:   <格納されている内容>
：

注

<格納されている内容>は16進数で出力されます。

(10)　スレッド情報

次の内容が出力されます。

Threads class SMR info:
_java_thread_list=<スレッドリストアドレス>, length=<スレッドリスト長>, elements={
<スレッドアドレス1>, <スレッドアドレス2>, <スレッドアドレス3>, <スレッドアドレス4>
：
}
_to_delete_list=<スレッドリストアドレス>, length=<スレッドリスト長>, elements={
<スレッドアドレス1>, <スレッドアドレス2>, <スレッドアドレス3>, <スレッドアドレス4>,
：
}
next-> <スレッドリストアドレス>, length=<スレッドリスト長>, elements={
<スレッドアドレス1>, <スレッドアドレス2>, <スレッドアドレス3>, <スレッドアドレス4>,
：
}

Java Threads: ( => current thread )
  <アドレス> JavaThread “スレッド名称“　[<状態>, id=<スレッドID>, stack(<開始アドレス>,<終了アドレス>)]
：
=><アドレス> JavaThread “スレッド名称“　[<状態>, id=<スレッドID>, stack(<開始アドレス>,<終了アドレス>)]

Other　Threads:
  <アドレス> <スレッド名> [stack(<開始アドレス>,<終了アドレス>)] [id=<スレッドID>]
：

(11)　VMの状態

次の内容が出力されます。

VM state:<現在の状態>

VM Mutex/Monitor currently owned by a thread: <mutexs/moniter>

注

この情報に続いて，ロック情報が出力される場合があります。

(12)　メモリ情報

次の内容が出力されます。この内容は，日立JavaVMで拡張された出力内容です。

Memory :
<メモリ確保関数>:address<開始アドレス> - <終了アドレス>(size:<サイズ>)
        ：

        Heap Size:<確保しているメモリサイズ>
        Alloc Size:<使用中のメモリサイズ>
        Free Size:<未使用のメモリサイズ>

<メモリ確保関数>は，mmap()またはmalloc()のどちらかです。アドレスは16進数で表示されます。

各種メモリサイズの単位はバイトです。

(13)　Javaヒープの使用状況

次の内容が出力されます。この内容は，日立JavaVMで拡張された出力内容です。

Heap※
<Javaヒープ情報>

注※

見出し部分は拡張スレッドダンプとエラーリポートファイルで次のように異なります。

拡張スレッドダンプの場合

Heap Status

-----------

エラーリポートファイルの場合

Heap

(14)　Card tableマップアドレスの表示

次の内容が出力されます。

Card table byte_map: [<アドレス>,<アドレス>] _byte_map_base: <アドレス>

(15)　Polling pageアドレスの表示

次の内容が出力されます。

Polling page: <アドレス>

(16)　Large pages 確保失敗情報

mmap()関数でのメモリ確保に失敗した場合に，失敗回数が出力されます。

Large page allocation failures have occurred　<回数> times

(17)　CodeCache情報

次の内容が出力されます。

SegmentedCodeCacheオプションがONの場合

CodeHeap 'non-nmethods': size=<全体サイズ> used=<使用済みサイズ> max_used=<最大サイズ> free=<空きサイズ>
 bounds [<bottom>, <commit addr>, <reserve addr>]
CodeHeap 'profiled nmethods': size=<全体サイズ> used=<使用済みサイズ> max_used=<最大サイズ> free=<空きサイズ>
 bounds [<bottom>, <commit addr>, <reserve addr>]
CodeHeap 'non-profiled nmethods': size=<全体サイズ> used=<使用済みサイズ> max_used=<最大サイズ> free=<空きサイズ>
 bounds [<bottom>, <commit addr>, <reserve addr>]
 total_blobs=<CodeBlobの総数> nmethods=<nmethodsの総数> adapters=<adapterの総数>
 compilation: <enabled/disabled>
          stopped_count=<コンパイラ停止回数>, restarted_count=<コンパイラ再開回数>
 full_count=<コードキャッシュ領域が枯渇した回数>

SegmentedCodeCacheオプションがOFFの場合

CodeCache: size=<全体サイズ> used=<使用済みサイズ> max_used=<最大サイズ> free=<空きサイズ>
 bounds [<bottom>, <commit addr>, <reserve addr>]
 total_blobs=<CodeBlobの総数> nmethods=<nmethodsの総数> adapters=<adapterの総数>
 compilation: <enabled/disabled>
          stopped_count=<コンパイラ停止回数>, restarted_count=<コンパイラ再開回数>
 full_count=<コードキャッシュ領域が枯渇した回数>

(18)　Event情報

イベントバッファの内容がすべて出力されます。

<イベント種別名> (<イベント数> events):
<イベントレコード>
　　：

イベント情報はリングバッファで管理していて，イベント種別ごとに保持するイベント数の最大値は10です。イベント数が0の場合は<イベントレコード>には"No events"が出力されます。

出力できる<イベント種別>の出力例を次に示します。

Compilation events

JITコンパイル情報

Compilation events (10 events):
Event: 0.923 Thread 0x00002aaab2f01800  389    b        java.io.FileOutputStream::write (12 bytes)
Event: 0.923 Thread 0x00002aaab2f01800 nmethod 389 0x00002aaaac3ea490 code [0x00002aaaac3ea5e0, 0x00002aaaac3ea668]
　　：

GC Heap History

before GC，after GC情報

GC Heap History (4 events):
Event: 23.719 GC heap before
{Heap before GC invocations=0 (full 0):
 def new generation   max 154880K, total 9664K, used 345K (0.2% used/max, 3.6% used/total)
　　：

Deoptimization events

Deopt情報

Deoptimization events (10 events):
Event: 0.818 Thread 0x00002aaaaba7e000 Uncommon trap 24 fr.pc 0x00002aaaac3d1eec
Event: 0.818 Thread 0x00002aaaaba7e000 Uncommon trap 54 fr.pc 0x00002aaaac3d0dd8
　　：

Classes redefined

クラス再定義情報

Classes redefined (3 events):
Event: 0.297 Thread 0x000000517b7b2800 redefined class name=foo.Foo, count=1
Event: 0.303 Thread 0x000000517b7b2800 redefined class name=foo.Foo, count=2
Event: 0.310 Thread 0x000000517b7b2800 redefined class name=foo.Foo, count=3
　　：

Internal exceptions

internal exception情報

Internal exceptions (2 events):
Event: 0.025 Thread 0x00002aaaaba7e000 Threw 0x00000000db606140 at /hotspot/src/share/vm/prims/jni.cpp:4008
Event: 0.061 Thread 0x00002aaaaba7e000 Threw 0x00000000db649980 at /hotspot/src/share/vm/prims/jvm.cpp:1167
　　：

Events

クラスローダ情報など

Events (10 events):
Event: 0.080 loading class 0x00002aaab302e990
Event: 0.080 loading class 0x00002aaab302e990 done
Event: 4.286 Executing VM operation: EnableBiasedLocking
Event: 4.286 Executing VM operation: EnableBiasedLocking done
　　：

(19)　ライブラリ

次の内容に続いて，ローディングされているライブラリの一覧が出力されます。

Dynamic libraries:
<ライブラリ>
：

(20)　コマンドおよびVMパラメタ

次の内容が出力されます。この内容は，日立JavaVMで拡張された出力内容です。

Command : <コマンドライン>

Java Home Dir   : <JDK実行環境インストールディレクトリ>
Java DLL Dir    : <JDKのライブラリインストールディレクトリ>
Sys Classpath   : <システムクラスパス>
User Args       :
<コマンドオプション1>
<コマンドオプション2>
：

(21)　環境変数

次の内容が出力されます。

Environment Variables:
<環境変数=値>
：

(22)　登録済みシグナルハンドラ

次の内容が出力されます。

Signal Handlers:
<シグナル種別>：
 [<シグナルハンドラアドレス>], sa_mask[0]=<シグナルマスク>, sa_flags=<特殊フラグ>
：
Changed Signal Handlers -
<シグナル種別>： [<シグナルハンドラアドレス>], sa_mask[0]=<シグナルマスク>, sa_flags=<特殊フラグ>
：

出力内容の意味は次のとおりです。

<シグナル種別>：/usr/include/sys/signal.hに定義されているシグナル名です。

<シグナルハンドラアドレス>：シグナルハンドラのアドレスが16進で出力された値です。「ライブラリ名＋オフセット」という形式で表示されることもあります。

<シグナルマスク>：sigaction()で取り出せる構造のsa_maskフィールド値が16進で出力された値です。

<特殊フラグ>：sigaction()で取り出せる構造のsa_flagsフィールド値が16進で出力された値です。

(23)　マシン情報

次の内容が出力されます。この内容は，日立JavaVMで拡張された出力内容です。

Host: <ホスト名>:<IPアドレス>

注

<IPアドレス>には複数のIPアドレスが表示されることがあります。

(24)　システム名，CPU，実メモリ，およびVM情報

次の内容が出力されます。

OS: <OSバージョン>

[uname:<uname出力>]
[libc:<libcのバージョン番号>]
[rlimit:<リミット値>]
[load average:<ロードアベレージ>]
[/proc/meminfo:</proc/meminfoの内容>]

CPU: <利用可能CPU数>[,<CPU種別>]

Memory: <実メモリ情報>

vm_info: <VM情報>

(25)　javatrace起動コマンドのコマンドライン

次の内容が出力されます。この内容は，日立JavaVMで拡張された出力内容です。

# You can get further information from javatrace.log file generated
# by using javatrace command.
# usage: javatrace core-file-name loadmodule-name [out-file-name] [-l(library-name)...]
# Please use javatrace command as follows and submit a bug report
# to Hitachi with javatrace.log file:
#[<インストールディレクトリ>/bin/javatrace <coreファイル>  <ロードモジュール>]

7.4.2　Cヒープが不足した場合

Cヒープが不足した場合，次の順序でメッセージ出力およびダンプ出力，またはcoreダンプの生成が実行されます。

Cヒープ不足を示すメッセージログが，エラーリポートファイルおよび標準出力に出力されます。

1.の実行中にメモリ不足が発生した場合，簡易メッセージが標準出力に出力されます。

簡易メッセージの出力処理中にさらにメモリ不足が発生したときに，メッセージおよびエラーログファイルの出力処理を中止して，coreダンプを生成します。

それぞれの出力形式を次に示します。

(1)　Cヒープ不足を示すメッセージログの出力内容

Cヒープ不足を示すメッセージログの出力形式を次に示します。この形式は，エラーリポートファイルと標準出力で共通です。

Exception in thread <ThreadName> java.lang.OutOfMemoryError: requested <n> bytes [for <message>].

Memory Status
-------------
  maximum size of data segment
      soft(current) limit :getrlimit(RLIMIT_DATA)で取得したソフトリミット値 kbytes (16進数)
      hard limit          :getrlimit(RLIMIT_DATA)で取得したハードリミット値 kbytes (16進数)
  current end of the heap :sbrk(0)によって取得した値
  JVM allocation size by malloc :JavaVMが割り当てたメモリサイズ kbytes (16進数)
  malloc information
      total space in arena            :mallinfo.arenaの値
      number of ordinary blocks       :mallinfo.ordblksの値
      number of small blocks          :mallinfo.smblksの値
      number of holding blocks        :mallinfo.hblksの値
      space in holding block headers  :mallinfo.hblkhdの値
      space in small blocks in use    :mallinfo.usmblksの値
      space in free small blocks      :mallinfo.fsmblksの値
      space in ordinary blocks in use :mallinfo.uordblksの値
      space in free ordinary blocks   :mallinfo.fordblksの値
      cost of enabling keep option    :mallinfo.keepcostの値

Heap Status
-----------
<Javaヒープ情報>
-----------
Stack Trace
-----------
<スタックトレース>
-----------

JVM Internal Memory Status
--------------------------
<独自メモリ管理機能で管理している領域情報>

このようなメッセージが出力された場合は，Cヒープを減らすなど，適切な対策をしてください。

出力項目について次に示します。

表7‒5　 Cヒープが不足した場合のメッセージログの出力項目

出力項目

説明

ThreadName

Thread#getName()メソッドで取り出せるスレッド名称が出力されます。

n

メモリ確保要求サイズが出力されます。

message

保守員による調査に必要な内部メッセージが出力されます。出力されない場合もあります。

Javaヒープ情報

Javaヒープの使用状況が出力されます。

スタックトレース

メモリ不足の発生したスレッドがJava コードを実行しているスレッドである場合に，スタックトレースが出力されます。

コンパイル処理のようなJavaVMの内部処理を実行するスレッドでメモリ不足が発生した場合には出力されません。

(2)　メモリ不足を示すメッセージの出力内容

Cヒープ不足を示すメッセージログが出力されている間にさらにメモリ不足が発生した場合は，処理の続行ができません。この場合は，次の形式の簡易メッセージが標準出力に出力されます。

java.lang.OutOfMemoryError:requested <n> bytes for <message>

出力項目について次に示します。

表7‒6　メモリ不足が発生した場合の簡易メッセージの出力項目

出力項目

説明

n

メモリ確保要求サイズが出力されます。

message

保守員による調査に必要な内部メッセージが出力されます。

(3)　coreダンプの生成を示すメッセージの出力内容

簡易メッセージの出力処理中にさらにメモリ不足が発生した場合，メッセージおよびエラーログファイルの出力処理を中止して，coreダンプを生成します。coreダンプが生成されると，次の形式のメッセージが標準出力に出力されます。

Can't create logs because of memory shortage.
Insufficient memory for malloc. JVM generates core file

7.4.3　Internal Errorが発生した場合

JavaVM内部の論理エラーであるInternal Errorが発生した場合，次の情報が出力されます。

異常終了位置とシグナル種別

時間情報※

カレントスレッド情報

シグナル情報の格納先アドレス※

スレッド情報

VMの状態

メモリ情報※

ヒープ情報※

Card tableマップアドレス

Polling pageアドレス

Large pages 確保失敗情報

CodeCache情報

Event情報

ライブラリ

コマンド・VMパラメタ※

環境変数

登録済みシグナルハンドラ

マシン情報※

システム名，CPU，実メモリ，およびVM情報

javatrace起動コマンドのコマンドライン※

注※　製品で拡張された出力内容です。

それぞれの情報の出力形式については，「7.4.1　シグナルが発生した場合」を参照してください。

7.4.4　スレッド作成に失敗した場合

メモリ不足（OutOfMemoryError）などが発生して新しくスレッドを作成できなかった場合，その時点でのスレッド数が，標準出力に出力されます。ここには，作成に失敗したスレッド数も含まれます。

メモリ不足などによってスレッドの作成に失敗した場合の出力例を次に示します。

java.lang.OutOfMemoryError:unable to create new native thread.1200 threads exist.
…

JavaVM起動時にスレッド作成に失敗した場合の出力例を次に示します。

Error occurred during initialization of VM
Could not create thread for VM:VM Thread.5 threads exist.

7.5　JavaVMスタックトレース情報

ここでは，スタックトレースに出力される情報のうち，日立JavaVMで拡張された内容について説明します。

サーバやアプリケーションでトラブルが発生した場合，トラブル発生までのスタックトレースの内容を確認することで，トラブル発生の要因を調査できます。

スタックトレースは，次のどれかのタイミングで出力されます。

アプリケーションサーバまたはアプリケーションで例外が発生した場合

バッチサーバまたはバッチアプリケーションで例外が発生した場合

JavaVMのスレッドダンプが出力された場合

日立JavaVMでは，サーバを起動するときのオプションの指定によって，スタックトレースにJavaメソッドのローカル変数についての情報を出力できます。例外発生時にJavaメソッドに定義されていたローカル変数の情報は，トラブルの要因を分析するために有効です。

なお，ここで対象にするローカル変数とは，メソッドに渡される引数およびインスタンスメソッドでの呼び出しの対象になるオブジェクト（this）のことです。ローカル変数情報には，これらのローカル変数の変数名，型名，およびローカル変数の値が出力されます。なお，型名は，基本形名，クラス名（インタフェース名を含みます）または配列形名のことです。

スタックトレースにローカル変数情報を出力するためのオプションを，次の表に示します。起動オプションについては「5.　日立JavaVM起動オプション」を，起動オプションのデフォルト値についてはマニュアル「uCosminexus Application Runtime ユーザーズガイド」を参照してください。また，日立JavaVMの資料取得の方法については，「3.　トラブルシューティング」を参照してください。

表7‒7　スタックトレースにローカル変数情報を出力するためのオプション

起動オプション

スタックトレースを出力するタイミング

同時に指定できるオプション

-XX:+HitachiLocalsInThrowable

サーバまたはアプリケーション内で例外が発生したとき※

-XX:+HitachiLocalsSimpleFormat

-XX:+HitachiTrueTypeInLocals

-XX:HitachiCallToString=<適用範囲指定>

-XX:+HitachiLocalsInStackTrace

JavaVMのスレッドダンプを出力したとき

-XX:+HitachiLocalsSimpleFormat

-XX:+HitachiTrueTypeInLocals

注※　ただし，発生した例外が「java.lang.StackOverflowError」または「java.lang.OutOfMemoryError」の場合，スタックトレースにローカル変数は出力されません。

以降に，それぞれのオプションを指定した場合に出力される内容について，例を基に説明します。それぞれのオプションを指定したときに出力される項目の詳細については，次の個所を参照してください。

「-XX:[+|-]HitachiLocalsInThrowable（例外発生時のローカル変数情報収集オプション）」

「-XX:[+|-]HitachiLocalsInStackTrace（スレッドダンプ出力時のローカル変数出力オプション）」

7.5.1　-XX:+HitachiLocalsInThrowableオプションが指定されている場合

java.lang.Throwable.printStackTraceメソッドで出力されるスタックトレース情報の1スタックフレーム情報ごとに，そのスタックフレームに対応するメソッド内のローカル変数情報が挿入されて出力されます。

(1)　標準の形式および簡易出力フォーマットでの出力例

ローカル変数を出力するための機能として，-XX:+HitachiLocalsInThrowableオプションだけを指定している場合の出力例です。

Javaプログラムの例と，それに対するスタックトレース内のローカル変数情報の出力例を示します。

Javaプログラムの例1

class Example1 {
    public static void main(String[] args) {
        Example1 e1 = new Example1();
        Object obj = new Object();
        e1.method(1, 'Q', obj); // e1.methodメソッドを実行します（5行目）。
    }

    void method(int l1, char l2, Object l3) {
        float l4 = 4.0f;
        boolean l5 = true;
        double l6 = Double.MAX_VALUE;
        Object[] l7 = new Object[10];

        try {
          <例外発生!> // methodメソッドの処理内で例外が発生した場合の処理です（15行目）。
        } catch (Exception e) {
          e.printStackTrace(); // スタックトレース情報を出力します（17行目）。
        }
    }
}

出力例を次に示します。

この例は，Javaプログラムの例1の5行目で実行したe1.methodメソッドの処理内で例外が発生したときに，17行目のe.printStackTraceメソッドによって出力されるスタックトレース情報です。

図7‒1　Javaプログラムの例1に対するローカル変数情報の出力例（-gオプションまたは-g:varsオプションを指定して作成されたclassファイルの場合）

出力内容について説明します。

スタックトレースを出力する処理を実行したメソッドの情報が出力されます。この例では，Javaプログラム1の15行目で例外が発生したときのスタックトレース情報が出力されることを示しています。

ローカル変数情報として，インスタンスメソッドの呼び出しの対象になるオブジェクトについての情報が出力されます。この例の場合は，Javaプログラムの例1の3行目で作成したExample1クラスのオブジェクトのクラス名とアドレスが出力されます。

ローカル変数情報として，methodメソッドの引数として指定されたローカル変数の値についての情報が出力されます。変数名の後ろの[arg*]は，何番目のメソッド引数かを示す情報です。Javaプログラムの例1の5行目でe1.methodメソッドを実行したときに指定された値が出力されます。

なお，l1およびl2は基本型（int型およびchar型）の変数なので実際の値が出力されます。l3はjava.lang.Objectクラス型の変数なので，アドレスで出力されます。

ローカル変数情報として，methodメソッド内のローカル変数のうち，メソッド引数として指定した以外のローカル変数の値についての情報が出力されます。

なお，l4〜l6は基本型（float型，boolean型およびdouble型）の変数なので実際の値が出力されます。l7はjava.lang.Objectクラス型の変数なので，アドレスで出力されます。

次に，-XX:+HitachiLocalsSimpleFormatオプションを指定した場合の，簡易出力フォーマットでの出力例を示します。なお，出力内容の説明は，標準の形式と同じです。

図7‒2　-XX:+HitachiLocalsSimpleFormatオプションを指定した場合の出力例

また，javacコマンド実行時に，-gオプションまたは-g:varsオプションを指定しなかった場合，ローカル変数情報がないため，出力内容が次のように制限されます。これらは，nativeメソッドを実行した場合も同様です。

出力できるローカル変数が，メソッドに渡される引数とインスタンスメソッド呼び出し対象オブジェクト（this）だけになります。

メソッドに渡される引数は，変数名が出力されません。引数番号だけが出力されます。

nativeメソッドの場合，ローカル変数の値としてnativeメソッドを呼び出した時点での値が出力されます。nativeメソッドの実行結果を反映した出力結果にはなりません。

ローカル変数情報がない場合の，Javaプログラムの例1に対する出力例を次に示します。ここでは，簡易出力フォーマットでの出力例を示します。

図7‒3　ローカル変数情報がない場合の出力例（簡易出力フォーマット）

「図7-2」に比べて，次の違いがあります。

メソッドに渡される引数（l1〜l3）の変数名が出力されません。

メソッド呼び出し時点の値が出力されるため，メソッド内で設定されたローカル変数についての情報（l4〜l7）が出力されません。

(2)　クラスまたは配列型の変数を文字列として出力する場合の出力例

出力するローカル変数がクラスまたは配列型の場合，アドレスだけの値表現ではトラブルシューティングに必要な情報が取得できない場合があります。このとき，-XX:HitachiCallToStringオプションの指定をしておくと，クラスまたは配列型の変数の値を文字列で取得できます。オプションには，適用範囲として，minimalまたはfullが指定できます。

-XX:HitachiCallToString=minimalオプションが指定されている場合は，java.langパッケージ内のクラスのうち，String，StringBuffer，Boolean，Byte，Character，Short，Integer，Long，Float，またはDoubleが対象になります。-XX:HitachiCallToString=fullオプションが指定されている場合は，すべてのクラスが対象になります。

次に，Javaプログラムの例と，-XX:HitachiCallToStringオプションが指定されている場合の出力例を示します。なお，ここでは簡易出力フォーマットで示します。

Javaプログラムの例2

class Example2 {
    public static void main(String[] args) {
        Example2 e2 = new Example2();
        e2.method();// e2.methodメソッドを実行します（4行目）。
    }

    void method() {
        String l1 = "local 1";
        StringBuffer l2 = new StringBuffer(l1);
        l2.append(" + local 2");
        Boolean l3 = new Boolean(false);
        Character l4 = new Character('X');
        Long l5 = new Long(Long.MIN_VALUE);
        Object l6 = new Thread();
        Object[] l7 = new Thread[10];

        try {
          <例外発生!> // methodメソッドの処理内で例外が発生した場合の処理です（18行目）。
        } catch (Exception e) {
          e.printStackTrace(); // スタックトレース情報を出力します（20行目）。
        }
    }

    public String toString() {
        return "I am an Example2 instance.";
    }
}

-XX:HitachiCallToString=minimalオプションを指定した場合の出力例を次に示します。

この例は，Javaプログラムの例1の4行目で実行したe2.methodメソッドの処理内で例外が発生したときに，20行目のe.printStackTraceメソッドによって出力されるスタックトレース情報です。

図7‒4　-XX:HitachiCallToString=minimalオプションを指定した場合の出力例（簡易出力フォーマット）

出力内容について説明します。

クラス型のローカル変数のうち，文字列を出力する適用対象のクラスの型のローカル変数情報です。アドレスに続いて，文字列に変換した値が出力されます。

クラス型のローカル変数のうち，文字列を出力する適用対象外のクラスの型のローカル変数情報です。アドレスだけが出力されます。

次に，-XX:HitachiCallToString=fullオプションを指定した場合の出力例を示します。

図7‒5　-XX:HitachiCallToString=fullオプションを指定した場合の出力例（簡易出力フォーマット）

「図7-4」に比べて，次の違いがあります。

minimalを指定した場合に適用対象外のクラスだったjava.lang.Objectクラスおよびjava.lang.Objectクラスの配列のローカル変数（l6およびl7）に対しても，文字列が出力されます。

ただし，次の場合は，文字列は出力されないで，アドレスだけが出力されます。

ローカル変数の値がnullだった場合

文字列で出力するときに再度例外が発生して，正常に値が得られなかった場合

重要

ローカル変数情報で出力するオブジェクトは，ほかのスレッドで並行して操作していることがあります。このため，このオプションを指定して出力した文字列は，実際に例外が発生したときのオブジェクトに対応する情報とは異なっているおそれがあります。

(3)　クラスまたは配列型の変数の実際の型名を出力する場合の出力例

出力するローカル変数がクラスまたは配列型の場合，変数の型名と実際に代入されている値の型名が異なる場合があります。例えば，クラスの継承関係やインタフェースの実装関係によっては，異なる型名の値が変数に代入されます。

この場合に，-XX:+HitachiTrueTypeInLocalsオプションの指定によって，クラスまたは配列型の変数に実際に代入されている値の型名を追記して取得できます。

取得した文字列は，値表現の末尾に半角スペース1文字分が追記され，( )で囲まれて出力されます。このとき，出力文字列長に制限はありません。

次に，-XX:+HitachiTrueTypeInLocalsオプションが指定されている場合の出力例を示します。ここでは簡易出力フォーマットで示します。実行するプログラムは，Javaプログラムの例2です。また，この例は，-XX:HitachiCallToString=minimalオプションが指定されている場合の例です。

図7‒6　-XX:+HitachiTrueTypeInLocalsオプションを指定した場合の出力例（簡易出力フォーマット）

出力内容について説明します。

変数の型名はjava.lang.Objectクラスまたはjava.lang.Objectクラスの配列ですが，実際に代入されている値の型名はjava.lang.Threadクラスおよびjava.lang.Threadクラスの配列であることが出力されています。

なお，-XX:+HitachiTrueTypeInLocalsオプションは，-XX:HitachiCallToString=fullオプションとも同時に指定できます。

7.5.2　-XX:+HitachiLocalsInStackTraceオプションが指定されている場合

スレッドダンプ内のスタックトレース情報の1スタックフレーム情報ごとに，そのスタックフレームに対応するメソッド内のローカル変数情報が挿入されて，出力されます。

出力形式および出力内容は，-XX:+HitachiLocalsInThrowableが指定されている場合に標準出力に出力される内容と同じです。

ただし，-XX:+HitachiLocalsInStackTraceオプションでは，次のオプションの指定は無効になります。

-XX:HitachiCallToStringオプション

Javaプログラムの例と，それに対するスタックトレース内のローカル変数情報の出力例を示します。

Javaプログラムの例3

class Example3 {
    public static void main(String[] args) {
        Example3 e3 = new Example3();
        e3.method();
    }

    synchronized void method() {
        int l1 = 1;
        float l2 = 2.0f;
        String l3 = "local 3";
        Character l4 = new Character('X');
        Object l5 = new Thread();
        Object[] l6 = new Thread[10];

        <ここでスレッドダンプ出力!>
    }
}

出力例を次に示します。この例は，次の場合の例です。

-gオプションまたは-g:varsオプションを指定して作成されたclassファイルである

-XX:+HitachiLocalSimpleFormatオプションを指定している

-XX:+HitachiTrueTypeInLocalsオプションを指定している

図7‒7　Javaプログラムの例3に対するローカル変数情報の出力例

8　アプリケーション実装時の注意事項

この章では，日立JavaVMを利用してアプリケーションを実装する際のJDKに関する注意事項について説明します。

8.1　アプリケーション実装時の注意事項

ここでは，アプリケーション実装時のJDKに関する注意事項について説明します。

URLClassLoaderでのクラスのローディングについて

URLClassLoader経由でjarファイルからクラスをローディングする場合，ローディング処理中にJavaVMの内部で作成されるオブジェクトが，JavaVM終了時まで削除されないことがあります。適宜，Javaアプリケーションを再起動してください。

メソッド長の上限について

JavaVMの仕様によって，1メソッドのバイトコードは，64キロバイト以内にする必要があります。

64キロバイトを超えると，クラスファイル生成時にエラーとなるか，またはクラスのロード時にjava.lang.LinkageError例外が発生します。

また，64キロバイト以内であっても，非常に複雑で行数が多い場合は，次のような弊害が発生することがあります。

GC処理の実行に非常に時間が掛かる。

JITコンパイルに非常に時間が掛かる。

JITコンパイルに非常に多くのメモリを消費する。

さらに，ローカル変数情報出力機能が有効な場合は，次の弊害も発生することがあります。

拡張スレッドダンプの出力に時間が掛かる。

スレッドスタックトレースの取得に時間が掛かる。

例外発生時の例外オブジェクト生成処理に時間が掛かる。

そのため，Javaソース上の1メソッドの行数は，コメントや空行を除いて，およそ500行以内にすることをお勧めします。

ファイルディスクリプタのクローズについて

java.lang.Runtime.exec()，およびjava.lang.ProcessBuilder.start()で起動した子プロセスは，Process.getInputStream，getErrorStream，またはgetOutputStreamのそれぞれのメソッドで取り出したストリームを通じてプロセス間通信をします。

親プロセスでは，これらのメソッドを使わない場合でも3つのファイルディスクリプタを消費することに注意してください。

ファイルディスクリプタをクローズするのは次の場合です。

Processオブジェクトのファイナライズが完了した場合

Process.destroy()を呼び出した場合

これらストリームに対して明示的にclose()メソッドを呼び出した場合

システムプロパティjava.library.pathについて

システムプロパティjava.library.pathには，ユーザのネイティブライブラリの検索パスを指定します。デフォルト値を次に示します。

JDK下のネイティブライブラリのディレクトリ，環境変数LD_LIBRARY_PATHの設定値，"/usr/lib64:/lib64:/lib:/usr/lib"

java.net.Socket.connect()のタイムアウトについて

java.net.Socket.connect()でのソケットの接続が，OSに設定されているTCP通信のタイムアウト値によってタイムアウトすることがあります。TCP通信のタイムアウト値になると，java.net.Socket.connect()に指定したタイムアウト値よりも前でも，タイムアウト値を指定していないときでも，接続がタイムアウトします。

TCP通信のタイムアウト値でタイムアウトした場合，次の詳細メッセージを含むjava.net.ConnectException例外がスローされます。

メッセージの内容

Connection timed out: connect [errno=10060, syscall=select]

TCP通信のタイムアウトについては，OSのドキュメントを参照してください。

クラスロードのタイミングについて

Javaでのクラスファイルのメモリへの読み込み（クラスロード処理）は，プログラムの実行中に，そのクラスが初めて必要となったタイミングで実行されます。そのため，ある処理の初回実行でクラスロードの回数が多くなると，2回目以降と比較して，処理時間が長くなることがあります。この場合，処理の実行に必要なクラスを事前にロードすることで，処理時間が改善します。

異なるOS間で発生する文字化けについて

文字コードのUnicodeへのマッピングは，OSによって異なることがあります。このため，次の場合に文字化けが発生することがあります。文字化けが発生する代表的な文字には，—，〜，‖，−，¢，£，¬があります。

UTF-8などのUnicodeのエンコーディングを使用して，異なるOS間で上記文字データを受け渡す場合

上記文字を含む文字列リテラルがあるソースプログラムから作成したクラスファイルを，異なるOS上でリコンパイルしないでそのまま実行する場合

Java APIで使用するファイルについて

Java APIで使用するポリシーファイルや，ログイン構成ファイルなどのコンフィグレーションファイルは，UTF-8エンコーディング方式でエンコーディングする必要があります。

JNI関数で文字列操作をする場合のUTF-8エンコーディングについて

JNIの場合，次の文字列操作をする関数で使用するエンコーディングは，標準UTF-8ではなく，Modified UTF-8です。

NewStringUTF

GetStringUTFLength

GetStringUTFChars

ReleaseStringUTFChars

GetStringUTFRegion

if文の判定でジャンプできる長さの上限について

JavaVMの仕様によって，if文の判定でジャンプできる長さは32キロバイトまでです。ジャンプ先が32キロバイトを超える場合は，java.lang.LinkageErrorとなります。

java.nio.channels.FileChannelクラスのmap，transferFrom，およびtransferToメソッドについて

mapメソッドでは，2ギガバイトを超えるファイルはサポートしていません。

また，transferFromおよびtransferToメソッドでのcount指定では，2ギガバイト以上の値はサポートしていません。

スレッドのスタックサイズについて

JNI関数AttachCurrentThread()などを使用して，ネイティブスレッドをJavaVMに接続する場合は，-Xssオプションの指定値よりも大きなスタックサイズのスレッドで接続してください。

JavaプロセスがSSL/TLS通信のクライアントとして動作する場合の注意点について

SSL/TLSを使った通信相手のプロトコルを変更した場合，通信に失敗するおそれがあります。

通信相手（サーバ）側で使用できるSSL/TLSプロトコルバージョンを変更したあと，クライアント側のJavaプロセスを再起動しないでSSL/TLSを使った通信をしようとした場合，クライアント側のJavaプロセスで例外が発生して通信に失敗するおそれがあります。

これは，既知の接続先に対して以前接続に成功したプロトコルの情報がクライアント側に残っていると，そのプロトコルバージョンでSSL/TLS通信を試みる，という挙動によるものです。

通信相手が使用できるSSL/TLSプロトコルバージョンを変更する場合は，クライアント側のJavaプロセスを再起動してください。

また，通信相手（サーバ）側で使用できるSSL/TLSプロトコルバージョンを変更したあと，クライアント側のJavaプロセスを再起動しないで通信が失敗した場合は，対象のJavaプロセスを再起動してください。

forkシステムコールについて

JNIやJVMTIで呼び出されるネイティブメソッド，またはネイティブコードで，fork()システムコール発行だけで現行プロセスのコピーの子プロセスを生成，または実行した場合，その親子プロセスの動作は保証できません。fork()システムコール発行による子プロセス生成後は，必ずexec()システムコールで新規プログラムをローディングしてから起動してください。また，Java環境下で子プロセスを生成する場合には，Javaクラスライブラリのjava.lang.Runtime.exec()メソッドを使用することをお勧めします。

シグナルについて

JNIやJVMTIで呼び出されるネイティブメソッド，またはネイティブコードで，次のシグナルに対してシグナルハンドラを登録した場合，動作は保証しません。

SIGHUP，SIGINT，SIGQUIT，SIGILL，SIGFPE，SIGBUS，SIGSEGV，SIGPIPE，SIGTERM，SIGUSR2，SIGCHLD，SIGXCPU，SIGXFSZ，（_SIGRTMAX-2）番のシグナル

システムライブラリ関数やシステムコール呼び出し中のシグナル受信について

システムライブラリ関数やシステムコール呼び出し中に，次のシグナルを受信することがあります。

SIGHUP，SIGINT，SIGQUIT，SIGILL，SIGFPE，SIGBUS，SIGSEGV，SIGPIPE，SIGTERM，SIGUSR2，SIGCHLD，SIGXCPU，SIGXFSZ，（_SIGRTMAX-2）番のシグナル

システムライブラリ関数やシステムコールを呼び出す場合，該当する関数の処理が，これらのシグナル受信によって中断されて，エラーリターン（errno値にEINTRが設定されるなど）することがあります。この場合は，適切な処置（例えば，再実行など）を実施してください。

JNIプログラム中で使用できないライブラリについて

JavaVM内で管理している情報が更新されて不正な情報となる場合があるため，JNIプログラム中で次のライブラリは使用できません。

setjmp()

longjmp()

_setjmp()

_longjmp()

sigsetjmp()

siglongjmp()

Windowsとの文字データの受け渡しについて

Windowsとの文字データの受け渡しをする場合には，エンコーディングにMS932，windows-31j，cswindows31jのどれかを指定してください。

Shift_JISやSJISを指定すると，次の文字が不正な文字コードに変換されます。

生成できるスレッド数の上限値について

システム全体で生成できるスレッド数の上限は，/proc/sys/kernel/threads-maxです。また，1ユーザ当たりの生成できるスレッド数の上限は，/etc/security/limits.confのnprocの値（ulimit -uと同じ）となります。システムに応じて，これらの値を調整してください。

通知待ちのモニタ数について

JVMTIインタフェースを使用して取得した，通知待ちのモニタ情報が不正となる場合があります。

半角カタカナについて

JIS X 201で制定されている文字のうち，半角カタカナはJavaSEのAPIを使用したGUIの実装では利用できません。

java.security.SecureRandomクラスについて

/dev/randomファイルがあるプラットフォームでは，SecureRandomクラスの一部のAPIで/dev/randomファイルからOSが生成した乱数を取得します。/dev/randomファイルから乱数を取得するのは，次の条件がすべて重なる場合です。

java.security.egdプロパティまたはjava.securityファイル中のsecurerandom.sourceにfile:/dev/random/を指定する

SecureRandomクラスのgenerateSeed()メソッドまたはgetSeed()メソッドを呼び出す

OSの乱数生成速度には限度があります。このため，短い間隔で乱数の取得処理を実行すると，OSによる乱数生成完了まで処理が完了しないので注意してください。

java.io.tmpdirプロパティについて

java.io.tmpdirプロパティには，書き込み権限があり，かつ存在するディレクトリを指定してください。java.io.tmpdirプロパティの初期値は/tmpです。

また，Java RMIの動的クラスローディング機能やJava APIのjava.io.File.createTempFile()では，java.io.tmpdirプロパティで指定されたディレクトリに一時ファイルを作成します。これらの機能を正常に動作させるため，JavaVMプロセス起動中は一時ファイルの作成先を削除しないでください。

デフォルトエンコーディングについて

アプリケーションサーバのデフォルトエンコーディングを次に示します。

LANGがCまたはPOSIXのとき：US-ASCII（別名ASCII）

LANGがjp_JP，jp_JP.eucJP，ja_JP.ujis，japanese，japanese.eucのどれかのとき：x-euc-jp-linux（別名EUC_JP_LINUX）

LANGがja_JP.utf8のとき：UTF-8（別名UTF8）

付録

付録A　このマニュアルの参考情報

このマニュアルを読むに当たっての参考情報を示します。

付録A.1　関連マニュアル

関連マニュアルを次に示します。必要に応じてお読みください。

表記

マニュアル名

資料番号

uCosminexus Application Runtime ユーザーズガイド

uCosminexus Application Runtime for Apache Tomcat ユーザーズガイド

3021-3-K01

付録A.2　このマニュアルでの表記

サービス名，製品名，機能名などの名称を，次のように表記しています。

表記

サービス名，製品名，機能名など

GC

ガーベージコレクションの略。プログラムが動作中に確保したメモリ領域のうち，不要になった領域を自動的に解放する機能です。

アプリケーションサーバ

アプリケーションの実行環境です。

Linux

Red Hat Enterprise Linux 7（AMD/Intel 64）

Red Hat Enterprise Linux 7.1 （AMD/Intel 64）以降

Red Hat Enterprise Linux 8（AMD/Intel 64）

Red Hat Enterprise Linux 8.1 （AMD/Intel 64）以降

Tomcat

Apache Tomcat

uCosminexus Application Runtime

uCosminexus Application Runtime with Java for Apache Tomcat

uCosminexus Application Runtimeサポートサービス

OSS Support Service with uCosminexus Application Runtime with Java for Apache Tomcat

Windows

Microsoft Windows

クラス別統計

日立クラス別統計

日立JavaVM

Cosminexus Developer's Kit for Java

保守員

uCosminexus Application Runtimeサポートサービスの契約に基づくお問い合わせ窓口のことです。

付録A.3　英略語

このマニュアルで使用している英略語を次に示します。

英略語

英字での表記

API

Application Programming Interface

ASCII

American Standard Code for Information Interchange

AWT

Abstract Window Toolkit

CPU

Central Processing Unit

CSV

Comma Separated Value

DLL

Dynamic Link Library

EUC

Extended UNIX Code

GC

Garbage Collection

CM

Concurrent Marking

GUI

Graphical User Interface

I/O

Input/Output

ID

Identifier

IP

Internet Protocol

JAR

Java Archive

Java SE

Java Platform, Standard Edition

JavaVMまたはJVM

Java Virtual Machine

JDBC

Java Database Connectivity

JDBC

JDK

Java Development Kit

JDK

JIS

Japanese Industrial Standards

JMS

Java Message Service

JNI

Java Native Interface

JSP

JavaServer Pages

JSP

JST

Japan Standard Time

JVMTI

Java Virtual Machine Tool Interface

ORB

Object Request Broker

OS

Operating System

RMI

Remote Method Invocation

SSL

Secure Sockets Layer

TCP

Transmission Control Protocol

TLS

Transport Layer Security

UTF-8

8-bit UCS Transformation Format

VM

Virtual Machine

付録A.4　KB（キロバイト）などの単位表記について

1KB（キロバイト），1MB（メガバイト），1GB（ギガバイト），1TB（テラバイト）はそれぞれ1,024バイト，1,024²バイト，1,024³バイト，1,024⁴バイトです。

索引

記号

-XX:[+|-]HitachiCommaVerboseGC[1]

-XX:[+|-]HitachiFullCore[1]

-XX:[+|-]HitachiJavaClassLibTrace[1]

-XX:[+|-]HitachiJavaLogNoMoreOutput[1]

-XX:[+|-]HitachiLocalsInStackTrace[1]

-XX:[+|-]HitachiLocalsInThrowable[1]

-XX:[+|-]HitachiLocalsSimpleFormat[1]

-XX:[+|-]HitachiOutOfMemoryAbort[1]

-XX:[+|-]HitachiOutOfMemoryAbortThreadDump[1]

-XX:[+|-]HitachiOutOfMemoryAbortThreadDumpWithJHeapProf[1]

-XX:[+|-]HitachiOutOfMemoryCause[1]

-XX:[+|-]HitachiOutOfMemoryHandling[1]

-XX:[+|-]HitachiOutOfMemorySize[1]

-XX:[+|-]HitachiOutOfMemoryStackTrace[1]

-XX:[+|-]HitachiOutputMilliTime[1]

-XX:[+|-]HitachiThreadDump[1]

-XX:[+|-]HitachiThreadDumpToStdout[1]

-XX:[+|-]HitachiThreadDumpWithBlockCount[1]

-XX:[+|-]HitachiThreadDumpWithCpuTime[1]

-XX:[+|-]HitachiThreadDumpWithHashCode[1]

-XX:[+|-]HitachiTrueTypeInLocals[1]

-XX:[+|-]HitachiVerboseGC[1]

-XX:[+|-]HitachiVerboseGCCpuTime[1]

-XX:[+|-]HitachiVerboseGCPrintCause[1]

-XX:[+|-]HitachiVerboseGCPrintDate[1]

-XX:[+|-]HitachiVerboseGCPrintDeleteOnExit[1]

-XX:[+|-]HitachiVerboseGCPrintJVMInternalMemory[1]

-XX:[+|-]HitachiVerboseGCPrintTenuringDistribution[1]

-XX:[+|-]HitachiVerboseGCPrintThreadCount[1]

-XX:[+|-]JavaLogAsynchronous[1]

-XX:[+|-]JITCompilerContinuation[1]

-XX:[+|-]PrintCodeCacheFullMessage[1]

-XX:[+|-]PrintCodeCacheInfo[1]

-XX:[+|-]StandardLogToHitachiJavaLog[1]

-XX:[+|-]UseCompressedOops[1]

-XX:+Hitachi[1]

-XX:+HitachiJavaClassLibTrace[1]

-XX:+HitachiLocalsInStackTraceオプションが指定されている場合[1]

-XX:+HitachiLocalsInThrowableオプションが指定されている場合[1]

-XX:+HitachiOutOfMemoryAbort（OutOfMemory発生時強制終了機能）[1]

-XX:+HitachiOutOfMemoryStackTrace[1]

-XX:+HitachiVerboseGC[1]

-XX:+JITCompilerContinuation[1]

-XX:CodeCacheInfoPrintRatio[1]

-XX:HitachiCallToString[1]

-XX:HitachiJavaClassLibTraceLineSize[1]

-XX:HitachiJavaLog[1]

-XX:HitachiJavaLogFileSize[1]

-XX:HitachiJavaLogNumberOfFile[1]

-XX:HitachiJITCompileMaxMemorySize[1]

-XX:HitachiOutOfMemoryHandlingMaxThrowCount[1]

-XX:HitachiOutOfMemoryStackTraceLineSize[1]

-XX:HitachiThreadLimit[1]

-XX:HitachiVerboseGCIntervalTime[1]

C

car_tar_gz[1]

car_tar_Z[1]

Card tableマップアドレス[1]

CodeCache情報[1]

Concurrent Marking（CM）[1]

CopyGC[1]

coreアーカイブ機能[1]、[2]

coreダンプ／スタックトレースファイル[1]

coreダンプ／スタックトレースファイル

取得方法[1]

coreダンプの生成を示すメッセージの出力内容[1]

coreファイルとスレッドダンプの取得[1]

Cヒープが不足した場合[1]

Cヒープが不足した場合のメッセージログの出力項目[1]

Cヒープ不足を示すメッセージログの出力内容[1]

Cヒープ領域[1]

E

Eden領域[1]、[2]

Event情報[1]

F

Free領域[1]

FullGC[1]、[2]、[3]

G

G1GC[1]

G1GCの仕組み[1]

G1GCのチューニング[1]

GCの強制発生[1]

GCの選択の指針[1]

H

Humongous領域[1]

I

Internal Errorが発生した場合[1]

J

javacore[1]

JAVACOREDIR[1]

javagc[1]

javatrace[1]

javatrace起動コマンドのコマンドライン[1]

JavaVM固有領域[1]

JavaVMスタックトレース情報[1]

JavaVMのスレッドダンプファイル[1]

取得方法[1]

JavaVMログ（JavaVMログファイル）[1]

JavaVMログファイル[1]

取得方法[1]

JavaVMログファイルを出力するオプション[1]

Javaオブジェクトの寿命[1]、[2]

Javaヒープ[1]

Javaヒープの使用状況[1]

Javaヒープのチューニング[1]

jheapprof[1]

jheapprofanalyzer[1]

JITコンパイル[1]

JP.co.Hitachi.soft.jvm.autofinalizer[1]

L

Large pages 確保失敗情報[1]

M

Metaspace領域[1]、[2]

MixedGC[1]、[2]

N

New領域[1]

O

OS稼働情報

取得方法[1]

OS固有領域[1]

OutOfMemory（アプリケーションサーバ）[1]

OutOfMemory（メモリ不足）[1]

OutOfMemoryError障害

各使用量の分析[1]

スレッドダンプによるローカル変数情報の解析例[1]

設定変更による対処[1]

調査の流れ[1]

メッセージによる症状の切り分け[1]

OutOfMemoryError障害（JavaVM）[1]

P

Polling pageアドレス[1]

S

SerialGC[1]

SerialGCの仕組み[1]

siginfo情報[1]

STATICメンバ統計機能[1]

STATICメンバ統計機能で出力するクラス別統計情報[1]

Survivor領域[1]、[2]

Survivor領域の年齢分布情報出力機能[1]

Survivor領域の年齢分布情報出力機能使用時の注意事項[1]

Survivor領域の年齢分布情報出力機能の概要[1]

Survivor領域の年齢分布情報の出力形式と出力例[1]

T

Tenured増加要因の基点オブジェクトリスト出力機能[1]

Tenured領域[1]、[2]

Tenured領域内不要オブジェクト統計機能[1]

Tenured領域内不要オブジェクト統計機能で出力するクラス別統計情報[1]

Tenured領域内不要オブジェクト統計機能の概要[1]

Tenured領域内不要オブジェクト統計機能の実行に関する注意事項[1]

V

VMの状態[1]

Y

YoungGC[1]、[2]

あ

圧縮オブジェクトポインタ機能[1]

い

異常終了位置とシグナル種別[1]

インスタンス統計機能[1]

インスタンス統計機能で出力するクラス別統計情報[1]

え

エラーリポートファイル[1]

取得方法[1]

お

オブジェクトの年齢[1]、[2]

か

拡張verbosegc情報[1]

拡張verbosegc情報の取得[1]

拡張verbosegc情報の取得を指定するオプション[1]

カレントスレッド情報[1]

環境変数[1]

く

クラス別統計機能[1]

クラス別統計機能を前提とする機能[1]

クラス別統計情報[1]

クラス別統計情報解析機能[1]

クラス別統計情報解析ファイルのCSV出力[1]

クラス別統計情報付き拡張スレッドダンプの出力[1]

クラス別統計情報の出力[1]

クラスまたは配列型の変数の実際の型名を出力する場合の出力例[1]

クラスまたは配列型の変数を文字列として出力する場合の出力例[1]

こ

コードキャッシュ領域[1]

コードキャッシュ領域に関するログの内容[1]

コマンドおよびVMパラメタ[1]

さ

参照関係情報出力機能[1]

参照関係情報出力機能で出力するクラス別統計情報[1]

し

時間情報[1]

シグナル情報[1]

シグナル情報の格納先アドレス[1]

システム名，CPU，実メモリ，およびVM情報[1]

す

スタックトレース[1]

スタックトレースにローカル変数情報を出力するためのオプション[1]

スタックの先頭から格納されている情報[1]

スタック領域[1]

スレッド作成に失敗した場合[1]

スレッド情報[1]

スレッドダンプ情報の構成[1]

スローダウン[1]

スローダウン（アプリケーションサーバ）[1]

せ

世代別GC[1]、[2]

と

統計前のGC選択機能[1]

統計前のGC選択機能の概要[1]

登録済みシグナルハンドラ[1]

トラブルシューティング

JavaVM[1]

アプリケーションサーバ[1]

トラブルシューティングに使用する資料の詳細[1]

トランザクションタイムアウト（アプリケーションサーバ）[1]

トレース情報の収集[1]

ひ

日立JavaVMが出力するメッセージログ[1]

日立JavaVMが出力するメッセージログ（標準出力およびエラーリポートファイル）[1]

日立JavaVMで使用するコマンド[1]

日立JavaVMで使用するコマンドの一覧[1]

日立JavaVMで使用するコマンドの詳細[1]

日立JavaVMのGCログ[1]

日立JavaVMの機能詳細[1]

日立JavaVMの機能の概要[1]

日立JavaVMのスレッドダンプ[1]

標準出力と標準エラー出力[1]

標準の形式および簡易出力フォーマットでの出力例[1]

ふ

ファイナライズ滞留解消機能[1]

プロセススローダウン

調査の流れ[1]

プロセススローダウン（JavaVM）[1]

プロセスダウン[1]

エラーリポートファイルの解析[1]

調査の流れ[1]

プロセスダウン（JavaVM）[1]

プロセスダウン（アプリケーションサーバ）[1]

プロセスハングアップ（アプリケーションサーバ）[1]

プロセスハングアップ（無応答）[1]

スレッドダンプ（デッドロック）の解析例[1]

スレッドダンプ（プロセス無応答）の解析例[1]

スレッドダンプ（無限ループ）の解析例[1]

スレッドダンプ（無限ループ）のローカル変数情報による解析例[1]

調査の流れ[1]

プロセスハングアップ（無応答）（JavaVM）[1]

ほ

保守員調査依頼時の提供情報[1]

ま

マシン情報[1]

め

メモリ情報[1]

メモリ不足を示すメッセージの出力内容[1]

ら

ライブラリ[1]

り

リクエストタイムアウト（アプリケーションサーバ）[1]

れ

レジスタ情報[1]

ろ

ローカル変数[1]

ローカル変数情報[1]

ログファイルの非同期出力機能[1]