JP4170988B2 - 実行環境の危険予測／回避方法，システム，プログラムおよびその記録媒体 - Google Patents
実行環境の危険予測／回避方法，システム，プログラムおよびその記録媒体 Download PDFInfo
- Publication number
- JP4170988B2 JP4170988B2 JP2004571568A JP2004571568A JP4170988B2 JP 4170988 B2 JP4170988 B2 JP 4170988B2 JP 2004571568 A JP2004571568 A JP 2004571568A JP 2004571568 A JP2004571568 A JP 2004571568A JP 4170988 B2 JP4170988 B2 JP 4170988B2
- Authority
- JP
- Japan
- Prior art keywords
- memory
- garbage collection
- risk
- warning
- execution environment
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
- G06F12/023—Free address space management
- G06F12/0253—Garbage collection, i.e. reclamation of unreferenced memory
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
- Y10S707/99953—Recoverability
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99956—File allocation
- Y10S707/99957—Garbage collection
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
- Memory System (AREA)
Description
本発明は，アプリケーションプログラムを安定に運用させるための技術に関し，特に，エンタープライズアプリケーションを構成するクライアント層，中間層，データベース層の３階層システムにおいて，サーバ側に配置される中間層の実行環境の状態をアプリケーションの運用時に監視し，実行環境が危険な状態になることを回避することで，アプリケーションを安定に運用させるための実行環境の危険予測／回避技術に関する。
上記のエンタープライズアプリケーションとしては，主にＪａｖａ（登録商標）を使用したＷｅｂアプリケーションなどがある。
また，上記のエンタープライズアプリケーションの構成には，さらに中間層を２階層に分けた４階層システムもある。
また，上記のサーバ側に配置される中間層の実行環境としては，主にＪａｖａ仮想マシン（Ｊａｖａ Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）などがある。
本発明は，Ｊａｖａのようなガベージコレクションなどのメモリ管理機能をもった実行系を対象としている。
上記のエンタープライズアプリケーションとしては，主にＪａｖａ（登録商標）を使用したＷｅｂアプリケーションなどがある。
また，上記のエンタープライズアプリケーションの構成には，さらに中間層を２階層に分けた４階層システムもある。
また，上記のサーバ側に配置される中間層の実行環境としては，主にＪａｖａ仮想マシン（Ｊａｖａ Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）などがある。
本発明は，Ｊａｖａのようなガベージコレクションなどのメモリ管理機能をもった実行系を対象としている。
以下，説明のためにＪａｖａを例として用いるものとする。
第１図は，Ｊａｖａアプリケーションの運用環境の例を示す図である。第１図の例では，Ｊａｖａアプリケーションの実行環境１０００におけるアプリケーションの運用時のデータが収集され，そのときに収集されたデータを性能分析ツール２０００が分析する。性能分析ツール２０００における分析結果をＪａｖａアプリケーションの実行環境１０００にフィードバックすることにより，最適なＪａｖａアプリケーションの運用環境を構築している。
Ｊａｖａアプリケーションの実行環境１０００において，ＯＳ１０１０の上位層にＪａｖａ仮想マシン１０２０があり，その上位層にアプリケーションサーバ１０３０がある。アプリケーションサーバ１０３０の例として，ＥＪＢ（Ｅｎｔｅｒｐｒｉｓｅ ＪａｖａＢｅａｎｓ）やＳｅｒｖｌｅｔなどを動かすプログラムであるＥＪＢコンテナやＳｅｒｖｌｅｔコンテナなどがある。アプリケーションサーバ１０３０の上位層で，Ｓｅｒｖｌｅｔ，ＪＳＰ（Ｊａｖａ Ｓｅｒｖｅｒ Ｐａｇｅｓ），ＥＪＢ等のアプリケーション１０４０が動作する。Ｗｅｂサーバ１０５０はクライアントからの要求を受け付ける。Ｊａｖａアプリケーションの運用状況を最もよく知っているのは，実行環境１０００の中で最下層に位置して実際にアプリケーションを実行しているＪａｖａ仮想マシン１０２０である。
性能分析ツール２０００において，実行環境１０００から収集されたデータは性能データベース２０１０に蓄積され，蓄積されたデータは分析プログラム２０２０によって解析される。分析結果をモニタリングツール２０３０で表示したり，ドリルダウンツール２０４０でより細かく分析したりする。また，サービスレベル診断２０５０により，クライアントからの要求に対してサーバが決められた時間内に応答しているか，現在のサービスの状態が満たされているかなどを診断する。
第２図は，従来のＪａｖａアプリケーションの運用環境の分析方法の例を示す図である。第２図において，Ｊａｖａアプリケーションを運用するサーバ３０００（Ｊａｖａアプリケーションの実行環境１０００を有するサーバ）から収集されたデータは，性能データベース２０１０を備えるデータ蓄積装置３０１０に蓄積される。性能分析装置３０２０は，データ蓄積装置３０１０に蓄積されたデータを参照し，そのデータを分析プログラム２０２０によって解析する。運用管理者３０３０は，性能分析装置３０２０において，モニタリングツール２０３０により分析結果をグラフ表示したり，ドリルダウンツール２０４０により詳細な分析を行ったり，サービスレベル診断２０５０によりサービスレベルの診断を行う。
エンタープライズアプリケーションの安定運用に関する従来の技術としては，以下のような技術がある。
（第１の従来技術）
サービスの処理性能やサーバ側のシステム性能を運用管理者がモニタリングツールで監視する技術がある。この技術では，測定したデータの分析を行い，しきい値と連携させてトラブルの兆候を予測・検出し，それを運用管理者に通知する。また，測定したデータを分析ツールによって解析することで，運用状況のグラフ化や評価，性能データの詳細な分析（ドリルダウン）を行い，性能低下のボトルネックの特定などを支援する。第２図の例が，この第１の従来技術の例となる。
上記のサービスの処理性能とは，クライアントからの要求に対して何秒間で応答できるかなどである。また，上記のサーバ側のシステム性能とは，ＣＰＵ使用率，メモリ使用量，ネットワーク使用率などである。
第１の従来の技術が記載された文献には，以下のようなものがある。
Ｓｙｓｔｅｍｗａｌｋｅｒ，パフォーマンス管理製品，富士通株式会社，（ＵＲＬ：ｈｔｔｐ：／／ｓｙｓｔｅｍｗａｌｋｅｒ．ｆｕｊｉｔｓｕ．ｃｏｍ／ｊｐ／ｃｏｍ／ｃｏｎｃ／ｐａｆｏ．ｈｔｍｌ） システム管理／Ｔｉｖｏｌｉ，パフォーマンス＆アベイラビリティ製品，日本ＩＢＭ株式会社，（ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ−６．ｉｂｍ．ｃｏｍ／ｊｐ／ｓｏｆｔｗａｒｅ／ｔｉｖｏｌｉ／ｐｒｏｄｕｃｔｓ／ｉｎｄｅｘ．ｈｔｍｌ＃ｐｅｒ） Ｐｒｅｃｉｓｅ／Ｉｎｄｅｐｔｈ ｆｏｒ Ｊ２ＥＥ，日揮情報ソフトウェア株式会社，（ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｊｓｙｓ−ｐｒｏｄｕｃｔｓ．ｃｏｍ／ｐｒｏｄｕｃｔ／ｐｒｅ＿ｉｎｄ＿ｊ２ｅｅ／ｄｏｃｕｍｅｎｔ．ｈｔｍｌ）
第１図は，Ｊａｖａアプリケーションの運用環境の例を示す図である。第１図の例では，Ｊａｖａアプリケーションの実行環境１０００におけるアプリケーションの運用時のデータが収集され，そのときに収集されたデータを性能分析ツール２０００が分析する。性能分析ツール２０００における分析結果をＪａｖａアプリケーションの実行環境１０００にフィードバックすることにより，最適なＪａｖａアプリケーションの運用環境を構築している。
Ｊａｖａアプリケーションの実行環境１０００において，ＯＳ１０１０の上位層にＪａｖａ仮想マシン１０２０があり，その上位層にアプリケーションサーバ１０３０がある。アプリケーションサーバ１０３０の例として，ＥＪＢ（Ｅｎｔｅｒｐｒｉｓｅ ＪａｖａＢｅａｎｓ）やＳｅｒｖｌｅｔなどを動かすプログラムであるＥＪＢコンテナやＳｅｒｖｌｅｔコンテナなどがある。アプリケーションサーバ１０３０の上位層で，Ｓｅｒｖｌｅｔ，ＪＳＰ（Ｊａｖａ Ｓｅｒｖｅｒ Ｐａｇｅｓ），ＥＪＢ等のアプリケーション１０４０が動作する。Ｗｅｂサーバ１０５０はクライアントからの要求を受け付ける。Ｊａｖａアプリケーションの運用状況を最もよく知っているのは，実行環境１０００の中で最下層に位置して実際にアプリケーションを実行しているＪａｖａ仮想マシン１０２０である。
性能分析ツール２０００において，実行環境１０００から収集されたデータは性能データベース２０１０に蓄積され，蓄積されたデータは分析プログラム２０２０によって解析される。分析結果をモニタリングツール２０３０で表示したり，ドリルダウンツール２０４０でより細かく分析したりする。また，サービスレベル診断２０５０により，クライアントからの要求に対してサーバが決められた時間内に応答しているか，現在のサービスの状態が満たされているかなどを診断する。
第２図は，従来のＪａｖａアプリケーションの運用環境の分析方法の例を示す図である。第２図において，Ｊａｖａアプリケーションを運用するサーバ３０００（Ｊａｖａアプリケーションの実行環境１０００を有するサーバ）から収集されたデータは，性能データベース２０１０を備えるデータ蓄積装置３０１０に蓄積される。性能分析装置３０２０は，データ蓄積装置３０１０に蓄積されたデータを参照し，そのデータを分析プログラム２０２０によって解析する。運用管理者３０３０は，性能分析装置３０２０において，モニタリングツール２０３０により分析結果をグラフ表示したり，ドリルダウンツール２０４０により詳細な分析を行ったり，サービスレベル診断２０５０によりサービスレベルの診断を行う。
エンタープライズアプリケーションの安定運用に関する従来の技術としては，以下のような技術がある。
（第１の従来技術）
サービスの処理性能やサーバ側のシステム性能を運用管理者がモニタリングツールで監視する技術がある。この技術では，測定したデータの分析を行い，しきい値と連携させてトラブルの兆候を予測・検出し，それを運用管理者に通知する。また，測定したデータを分析ツールによって解析することで，運用状況のグラフ化や評価，性能データの詳細な分析（ドリルダウン）を行い，性能低下のボトルネックの特定などを支援する。第２図の例が，この第１の従来技術の例となる。
上記のサービスの処理性能とは，クライアントからの要求に対して何秒間で応答できるかなどである。また，上記のサーバ側のシステム性能とは，ＣＰＵ使用率，メモリ使用量，ネットワーク使用率などである。
第１の従来の技術が記載された文献には，以下のようなものがある。
Ｓｙｓｔｅｍｗａｌｋｅｒ，パフォーマンス管理製品，富士通株式会社，（ＵＲＬ：ｈｔｔｐ：／／ｓｙｓｔｅｍｗａｌｋｅｒ．ｆｕｊｉｔｓｕ．ｃｏｍ／ｊｐ／ｃｏｍ／ｃｏｎｃ／ｐａｆｏ．ｈｔｍｌ） システム管理／Ｔｉｖｏｌｉ，パフォーマンス＆アベイラビリティ製品，日本ＩＢＭ株式会社，（ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ−６．ｉｂｍ．ｃｏｍ／ｊｐ／ｓｏｆｔｗａｒｅ／ｔｉｖｏｌｉ／ｐｒｏｄｕｃｔｓ／ｉｎｄｅｘ．ｈｔｍｌ＃ｐｅｒ） Ｐｒｅｃｉｓｅ／Ｉｎｄｅｐｔｈ ｆｏｒ Ｊ２ＥＥ，日揮情報ソフトウェア株式会社，（ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｊｓｙｓ−ｐｒｏｄｕｃｔｓ．ｃｏｍ／ｐｒｏｄｕｃｔ／ｐｒｅ＿ｉｎｄ＿ｊ２ｅｅ／ｄｏｃｕｍｅｎｔ．ｈｔｍｌ）
（第２の従来技術）
処理性能が異なるサーバが混在する環境において，サーブレットやＥＪＢなどのサービスの処理時間を測定し，処理の速いサーバを自動選択してクライアントからの要求を振り分けることで，システム全体としての処理を効率的に行う技術がある。
第２の従来の技術が記載された文献には，以下のようなものがある。
ＩＢＭ ｅＳｅｒｖｅｒ，異機種間ワークロード管理，日本ＩＢＭ株式会社，（ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ−６．ｉｂｍ．ｃｏｍ／ｊｐ／ｓｅｒｖｅｒｓ／ｅｓｅｒｖｅｒ／ａｃ／ｔｅｃｈ／ｉｎｄｅｘ２＿１．ｈｔｍｌ）
処理性能が異なるサーバが混在する環境において，サーブレットやＥＪＢなどのサービスの処理時間を測定し，処理の速いサーバを自動選択してクライアントからの要求を振り分けることで，システム全体としての処理を効率的に行う技術がある。
第２の従来の技術が記載された文献には，以下のようなものがある。
ＩＢＭ ｅＳｅｒｖｅｒ，異機種間ワークロード管理，日本ＩＢＭ株式会社，（ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ−６．ｉｂｍ．ｃｏｍ／ｊｐ／ｓｅｒｖｅｒｓ／ｅｓｅｒｖｅｒ／ａｃ／ｔｅｃｈ／ｉｎｄｅｘ２＿１．ｈｔｍｌ）
（第３の従来技術）
Ｊａｖａのメモリ量を調べるＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）を使ってＪａｖａ仮想マシンが管理しているメモリ（ヒープ）サイズの定期調査を行い，メモリ不足を検出する技術がある。この技術では，メモリの空きがしきい値より不足した場合に，ガベージコレクションを強制実行することにより，メモリの空きの回復を促している。
第３の従来の技術が記載された文献には，以下のようなものがある。
ＷｅｂＬｏｇｉｃ Ｓｅｒｖｅｒ，Ｊａｖａ仮想マシンのチューニング，自動的な低メモリ状態の検出とガベージコレクションの強制，日本ＢＥＡシステムズ株式会社，（ＵＲＬ：ｈｔｔｐ：／／ｅｄｏｃｓ．ｂｅａｓｙｓ．ｃｏ．ｊｐ／ｅ−ｄｏｃｓ／ｗｌｓ／ｄｏｃｓ７０／ｐｅｒｆｏｒｍ／ＪＶＭＴｕｎｉｎｇ．ｈｔｍｌ＃４８９１５９）
Ｊａｖａのメモリ量を調べるＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）を使ってＪａｖａ仮想マシンが管理しているメモリ（ヒープ）サイズの定期調査を行い，メモリ不足を検出する技術がある。この技術では，メモリの空きがしきい値より不足した場合に，ガベージコレクションを強制実行することにより，メモリの空きの回復を促している。
第３の従来の技術が記載された文献には，以下のようなものがある。
ＷｅｂＬｏｇｉｃ Ｓｅｒｖｅｒ，Ｊａｖａ仮想マシンのチューニング，自動的な低メモリ状態の検出とガベージコレクションの強制，日本ＢＥＡシステムズ株式会社，（ＵＲＬ：ｈｔｔｐ：／／ｅｄｏｃｓ．ｂｅａｓｙｓ．ｃｏ．ｊｐ／ｅ−ｄｏｃｓ／ｗｌｓ／ｄｏｃｓ７０／ｐｅｒｆｏｒｍ／ＪＶＭＴｕｎｉｎｇ．ｈｔｍｌ＃４８９１５９）
（第４の従来技術）
Ｊａｖａ仮想マシン・プロファイラインタフェースによりＪａｖａ仮想マシンで発生したイベントを計測し，実行時間の長いメソッド（ボトルネック）の検出や，メモリリークの危険性のあるオブジェクトの検出，デッドロックの危険性のあるスレッドの検出を行う技術がある。
Ｊａｖａ仮想マシン・プロファイラインタフェースにより計測されるイベントには，“ガベージコレクションを開始した／終了した”，“Ｊａｖａのメソッドに入った／終了した”，“オブジェクトを割り当てた／解放した”，“Ｊａｖａスレッドの状態が遷移した”などがある。
しかし，以上のようなエンタープライズアプリケーションの安定運用に関する従来の技術には，以下のような問題があった。
（第１の従来技術の問題点）
第１の従来技術では，様々なデータを採取してそれをグラフなどで表示して監視するモニタリングツールは，トラブル予測と回避のステップに人間の介在を必要とするため，タイムリー性と自律性に欠けていた。特に，ドリルダウンツールで分析する方法ではタイムリー性はまったくなかった。また，データの収集，サービスレベル診断（分析），警告の通知までは自動的に行われていても，警告を受けてからの対処は自動化されていないものが多かった。さらに，データをどのくらい収集していつ分析を行うかなどの条件が，危険性の発見のタイミングに影響していた。
（第２の従来技術の問題点）
第２の従来技術では，処理が自動的に行われているが，それはあくまでサービス時間を計測して負荷分散するロードバランスの仕組みであって，収集した様々なデータを分析して危険の要因を発見する技術ではなかった。
（第３の従来技術の問題点）
第３の従来技術では，処理が自動的に行われているが，トラブルを予測するアルゴリズムに問題があった。Ｊａｖａ仮想マシンのメモリ（ヒープ）不足はトラブルの主要因ではあるが，空き容量としきい値を比較してヒープ不足を検出するだけでは必ずしも正しい判断ができているとはいえない。
ヒープが不足した場合には，Ｊａｖａ仮想マシンは自動的にガベージコレクションを実行してメモリの回復を図るが，上記第３の従来技術では，それより前に強制的なガベージコレクションでメモリの回復を図っている。この技術は，メモリの使用量がしきい値を超えた後に徐々にメモリ使用量が増え，自動的なガベージコレクションが起きるまでに比較的長い時間がかかる場合には，有効かもしれない。
しかし，すべてがこのような状況であるとは限らない。例えば，メモリの絶対量が不足していてガベージコレクションの頻度が高い場合には，強制的にガベージコレクションを起こしてもすぐに次のガベージコレクションが起きてしまい，負荷の高いガベージコレクション処理を何度も行ってしまうことになる。
（第４の従来技術の問題点）
第４の従来技術では，Ｊａｖａ仮想マシン・プロファイラインタフェースで提供されているイベントの発行頻度が非常に高く，そのためにＪａｖａ仮想マシンに余分な負荷をかけてしまっていた。また，あらかじめ決められたインタフェースを使用しているため，危険性の発見に必要な情報がなかったり，できることの自由度が低かったりしていた。ＣＰＵ使用率の高いシーケンスコール（ボトルネック）やメモリリークを見つけるツールにはプロファイラインタフェースを使ったものが多いが，負荷が比較的に高く，これらはアプリケーションの運用時ではなくテストの段階で行われるべきものであった。
以上の従来技術の問題点を解決し，アプリケーションを安定に運用させてミッションクリティカルなシステムを実現するには，異常が発生する前にトラブルの危険を察知して回避する必要がある。そのためには，危険性を発見してから回避するまでに，以下の条件を満たす必要がある。
（１）トラブルを予測するためのデータ採取の負荷を軽くし，アプリケーションの運用に負荷を与えない。
（２）トラブルを予測する判断材料とアルゴリズムには適切なものを用い，より正確な予測を行う。
（３）データの測定からトラブルを予測，通知，回避するまでの処理を，短時間かつタイムリーに行う。さらに，これらのステップは，すべて自動的（自律的）に行われることが望ましい。
本発明は，このような状況に鑑みてなされたものであり，データ採取の負荷を軽くし，適切な判断材料とアルゴリズムとからより正確な危険性の予測を行い，データの測定からトラブルの予測，通知，回避までの処理を，短時間かつタイムリーに行い，それらの処理を自動的に実行することが可能となる技術を提供することを目的とする。
Ｊａｖａ仮想マシン・プロファイラインタフェースによりＪａｖａ仮想マシンで発生したイベントを計測し，実行時間の長いメソッド（ボトルネック）の検出や，メモリリークの危険性のあるオブジェクトの検出，デッドロックの危険性のあるスレッドの検出を行う技術がある。
Ｊａｖａ仮想マシン・プロファイラインタフェースにより計測されるイベントには，“ガベージコレクションを開始した／終了した”，“Ｊａｖａのメソッドに入った／終了した”，“オブジェクトを割り当てた／解放した”，“Ｊａｖａスレッドの状態が遷移した”などがある。
しかし，以上のようなエンタープライズアプリケーションの安定運用に関する従来の技術には，以下のような問題があった。
（第１の従来技術の問題点）
第１の従来技術では，様々なデータを採取してそれをグラフなどで表示して監視するモニタリングツールは，トラブル予測と回避のステップに人間の介在を必要とするため，タイムリー性と自律性に欠けていた。特に，ドリルダウンツールで分析する方法ではタイムリー性はまったくなかった。また，データの収集，サービスレベル診断（分析），警告の通知までは自動的に行われていても，警告を受けてからの対処は自動化されていないものが多かった。さらに，データをどのくらい収集していつ分析を行うかなどの条件が，危険性の発見のタイミングに影響していた。
（第２の従来技術の問題点）
第２の従来技術では，処理が自動的に行われているが，それはあくまでサービス時間を計測して負荷分散するロードバランスの仕組みであって，収集した様々なデータを分析して危険の要因を発見する技術ではなかった。
（第３の従来技術の問題点）
第３の従来技術では，処理が自動的に行われているが，トラブルを予測するアルゴリズムに問題があった。Ｊａｖａ仮想マシンのメモリ（ヒープ）不足はトラブルの主要因ではあるが，空き容量としきい値を比較してヒープ不足を検出するだけでは必ずしも正しい判断ができているとはいえない。
ヒープが不足した場合には，Ｊａｖａ仮想マシンは自動的にガベージコレクションを実行してメモリの回復を図るが，上記第３の従来技術では，それより前に強制的なガベージコレクションでメモリの回復を図っている。この技術は，メモリの使用量がしきい値を超えた後に徐々にメモリ使用量が増え，自動的なガベージコレクションが起きるまでに比較的長い時間がかかる場合には，有効かもしれない。
しかし，すべてがこのような状況であるとは限らない。例えば，メモリの絶対量が不足していてガベージコレクションの頻度が高い場合には，強制的にガベージコレクションを起こしてもすぐに次のガベージコレクションが起きてしまい，負荷の高いガベージコレクション処理を何度も行ってしまうことになる。
（第４の従来技術の問題点）
第４の従来技術では，Ｊａｖａ仮想マシン・プロファイラインタフェースで提供されているイベントの発行頻度が非常に高く，そのためにＪａｖａ仮想マシンに余分な負荷をかけてしまっていた。また，あらかじめ決められたインタフェースを使用しているため，危険性の発見に必要な情報がなかったり，できることの自由度が低かったりしていた。ＣＰＵ使用率の高いシーケンスコール（ボトルネック）やメモリリークを見つけるツールにはプロファイラインタフェースを使ったものが多いが，負荷が比較的に高く，これらはアプリケーションの運用時ではなくテストの段階で行われるべきものであった。
以上の従来技術の問題点を解決し，アプリケーションを安定に運用させてミッションクリティカルなシステムを実現するには，異常が発生する前にトラブルの危険を察知して回避する必要がある。そのためには，危険性を発見してから回避するまでに，以下の条件を満たす必要がある。
（１）トラブルを予測するためのデータ採取の負荷を軽くし，アプリケーションの運用に負荷を与えない。
（２）トラブルを予測する判断材料とアルゴリズムには適切なものを用い，より正確な予測を行う。
（３）データの測定からトラブルを予測，通知，回避するまでの処理を，短時間かつタイムリーに行う。さらに，これらのステップは，すべて自動的（自律的）に行われることが望ましい。
本発明は，このような状況に鑑みてなされたものであり，データ採取の負荷を軽くし，適切な判断材料とアルゴリズムとからより正確な危険性の予測を行い，データの測定からトラブルの予測，通知，回避までの処理を，短時間かつタイムリーに行い，それらの処理を自動的に実行することが可能となる技術を提供することを目的とする。
本発明は，例えばエンタープライズアプリケーションの中間層の実行環境において，メモリ不足の危険性を予測し，その危険を回避するための実行環境の危険予測／回避方法である。この危険予測／回避方法は，ガベージコレクションのイベント発生時に，メモリ状態に関するデータを測定し，測定されたデータからメモリ不足の危険性を予測し，予測されたメモリ不足の危険性に対する警告を他のアプリケーションに通知する。また，予測されたメモリ不足の危険性を回避するために必要なメモリ量を算出し，算出されたメモリ量を通知する。また，メモリ不足の危険性の予測は，ガベージコレクションの種類ごとに対応するアルゴリズムを用いて行う。
具体的には，例えば，エンタープライズアプリケーションの中間層の実行環境としてＪａｖａ仮想マシンを例とした場合，ガベージコレクションのイベント発生時にその発生時刻やメモリ使用量などのデータを測定し，それ以外は定期的にメモリの使用量などを計測する。測定されたデータをもとに，メモリ不足エラー（以下，ＯｕｔＯｆＭｅｍｏｒｙという）の危険性やメモリ不足による性能低下などを予測し，それらの警告を通知する。また，危険性を回避するために必要なメモリ量を計算する。メモリ不足の危険性の予測には，基本的なガベージコレクションに合わせた予測だけではなく，世代型ガベージコレクションなどの特殊なガベージコレクションに合わせた予測も行う。
本発明による実行環境の危険予測／回避方法によれば，ガベージコレクション以外のイベント発生時（例えば，メモリの割り当てのイベント発生時など）にはメモリ使用量などの測定を行わず，主にガベージコレクションのイベント発生時の測定と，必要に応じて比較的長い周期での定期的な測定によって，メモリ使用量などの測定を行うため，アプリケーションの運用に負荷をかけずにデータの測定を行うことができる。また，本発明による実行環境の危険予測／回避方法によれば，予測されたメモリ不足の危険性を回避するために必要なメモリ量を計算し，その計算されたメモリ量を通知するため，アプリケーションの実行環境の状態回復を早く，容易に行うことができる。また，本発明による実行環境の危険予測／回避方法によれば，ガベージコレクションの種類ごとに対応するアルゴリズムによって危険性の判断を行うため，より正確な危険性の判断を行うことができる。
以上のような本発明による実行環境の危険予測／回避方法は，コンピュータとソフトウェアプログラムとによって実現することができ，そのプログラムをコンピュータ読み取り可能な記録媒体に記録することも，ネットワークを通して提供することも可能である。このプログラムは，ハードディスク等の媒体にインストールされ，主記憶装置に展開されてＣＰＵによって実行される。また，記録媒体としては，ＣＤ−ＲＯＭやＤＶＤ等の可搬型記録媒体が考えられる。
具体的には，例えば，エンタープライズアプリケーションの中間層の実行環境としてＪａｖａ仮想マシンを例とした場合，ガベージコレクションのイベント発生時にその発生時刻やメモリ使用量などのデータを測定し，それ以外は定期的にメモリの使用量などを計測する。測定されたデータをもとに，メモリ不足エラー（以下，ＯｕｔＯｆＭｅｍｏｒｙという）の危険性やメモリ不足による性能低下などを予測し，それらの警告を通知する。また，危険性を回避するために必要なメモリ量を計算する。メモリ不足の危険性の予測には，基本的なガベージコレクションに合わせた予測だけではなく，世代型ガベージコレクションなどの特殊なガベージコレクションに合わせた予測も行う。
本発明による実行環境の危険予測／回避方法によれば，ガベージコレクション以外のイベント発生時（例えば，メモリの割り当てのイベント発生時など）にはメモリ使用量などの測定を行わず，主にガベージコレクションのイベント発生時の測定と，必要に応じて比較的長い周期での定期的な測定によって，メモリ使用量などの測定を行うため，アプリケーションの運用に負荷をかけずにデータの測定を行うことができる。また，本発明による実行環境の危険予測／回避方法によれば，予測されたメモリ不足の危険性を回避するために必要なメモリ量を計算し，その計算されたメモリ量を通知するため，アプリケーションの実行環境の状態回復を早く，容易に行うことができる。また，本発明による実行環境の危険予測／回避方法によれば，ガベージコレクションの種類ごとに対応するアルゴリズムによって危険性の判断を行うため，より正確な危険性の判断を行うことができる。
以上のような本発明による実行環境の危険予測／回避方法は，コンピュータとソフトウェアプログラムとによって実現することができ，そのプログラムをコンピュータ読み取り可能な記録媒体に記録することも，ネットワークを通して提供することも可能である。このプログラムは，ハードディスク等の媒体にインストールされ，主記憶装置に展開されてＣＰＵによって実行される。また，記録媒体としては，ＣＤ−ＲＯＭやＤＶＤ等の可搬型記録媒体が考えられる。
第１図は，Ｊａｖａアプリケーションの運用環境の例を示す図である。
第２図は，従来のＪａｖａアプリケーションの運用環境の分析方法の例を示す図である。
第３図は，危険予測／回避システムの構成例を示す図である。
第４図は，設定データの例を示す図である。
第５図は，測定・分析手段を説明する図である。
第６図は，ガベージコレクションの発生間隔とメモリ使用量に関する代表的な３つの状態を示す図である。
第７図は，警告を行うべき状態を説明する図である。
第８図は，世代型ガベージコレクションにおけるガベージコレクションの発生間隔とメモリ使用量に関する状態を説明する図である。
第９図は，溢れ量の測定を説明する図である。
第１０図は，ダイナミックにサイズを変更する世代型ガベージコレクションにおけるガベージコレクションの発生間隔とメモリ使用量に関する状態を説明する図である。
第１１図ないし第１５図は，メモリ使用量測定・分析処理フローチャートである。
第１６図および第１７図は，メモリ使用量測定・分析手段の警告対象となる状態の例を示す図である。
第１８図は，スレッド測定・分析処理フローチャートである。
第１９図は，Ｊａｖａ仮想マシンとアプリケーションサーバとの連携によるＪａｖａ仮想マシンへの処理の振り分けを示す図である。
第２０図は，Ｊａｖａ仮想マシンとアプリケーションサーバとの連携を示す図である。
第２１図は，分析結果通知処理フローチャートである。
第２２図は，コマンド通知処理フローチャートである。
第２３図は，Ｊａｖａ仮想マシン最適制御処理フローチャートである。
第２図は，従来のＪａｖａアプリケーションの運用環境の分析方法の例を示す図である。
第３図は，危険予測／回避システムの構成例を示す図である。
第４図は，設定データの例を示す図である。
第５図は，測定・分析手段を説明する図である。
第６図は，ガベージコレクションの発生間隔とメモリ使用量に関する代表的な３つの状態を示す図である。
第７図は，警告を行うべき状態を説明する図である。
第８図は，世代型ガベージコレクションにおけるガベージコレクションの発生間隔とメモリ使用量に関する状態を説明する図である。
第９図は，溢れ量の測定を説明する図である。
第１０図は，ダイナミックにサイズを変更する世代型ガベージコレクションにおけるガベージコレクションの発生間隔とメモリ使用量に関する状態を説明する図である。
第１１図ないし第１５図は，メモリ使用量測定・分析処理フローチャートである。
第１６図および第１７図は，メモリ使用量測定・分析手段の警告対象となる状態の例を示す図である。
第１８図は，スレッド測定・分析処理フローチャートである。
第１９図は，Ｊａｖａ仮想マシンとアプリケーションサーバとの連携によるＪａｖａ仮想マシンへの処理の振り分けを示す図である。
第２０図は，Ｊａｖａ仮想マシンとアプリケーションサーバとの連携を示す図である。
第２１図は，分析結果通知処理フローチャートである。
第２２図は，コマンド通知処理フローチャートである。
第２３図は，Ｊａｖａ仮想マシン最適制御処理フローチャートである。
第３図は，危険予測／回避システムの構成例を示す図である。第３図において，Ｊａｖａ仮想マシン１とその上位層のアプリケーションサーバ２とは，Ｊａｖａ仮想マシン連携手段３により連携している。
Ｊａｖａ仮想マシン１は，測定・分析手段１０を備える。また，測定・分析手段１０は，メモリ使用量測定・分析手段１１と，スレッド測定・分析手段１２と，設定データ１００とを備える。
アプリケーションサーバ２は，Ｊａｖａ仮想マシン制御手段２０を備える。また，そのＪａｖａ仮想マシン制御手段２０は，Ｊａｖａ仮想マシン最適制御手段２１を備える。
Ｊａｖａ仮想マシン連携手段３は，分析結果通知手段３１と，コマンド通知手段３２とを備える。
第４図は，設定データの例を示す図である。測定・分析手段１０が備える設定データ１００は，第４図に示すように，メモリ使用量測定フラグ１０１，スレッド測定フラグ１０２，ＧＣ発生間隔警告しきい値（ｔｈ１）１０３，ＯｕｔＯｆＭｅｍｏｒｙ警告しきい値Ａ（ｔｈ２）１０４，ＯｕｔＯｆＭｅｍｏｒｙ警告しきい値Ｂ（ｔｈ３）１０５，メモリ不足警告しきい値（ｔｈ４）１０６，メモリ空き回復しきい値（ｔｈ５）１０７，ｎｅｗ世代不足警告しきい値（ｔｈ６）１０８，溢れ量警告しきい値（ｔｈ７）１０９，デッドロック警告しきい値（ｔｈ８）１１０のデータである。なお，上記ＧＣはガベージコレクションを意味する。以下，場合によってガベージコレクションをＧＣと記載する。
設定データ１００におけるこれらの値は，アプリケーションサーバ２がコマンドを発行して設定することができる。また，事前にまたは随時，図示省略した設定用プログラムを用いてシステム管理者等が設定することもできる。
以下，各手段の動作を説明するが，最初に，Ｊａｖａ仮想マシン１内でデータの測定と分析，危険性の予測を行う部分について説明し，次に，分析結果をアプリケーションサーバ２に通知して最適な運用環境になるようにフィードバックする部分について説明する。
本発明では，第３図に示すように，Ｊａｖａ仮想マシン１がその内部に測定・分析手段１０を備える。データの測定・分析，トラブル発生の予測は，Ｊａｖａ仮想マシン１の内部で行われる。よって，本発明では，測定データをデータベースなどに一度出力して分析プログラムによって判断するような第１の従来技術に比べて，データの測定から分析，トラブルの予測までをタイムリーに行うことができる。
第５図は，測定・分析手段を説明する図である。Ｊａｖａ仮想マシン１内の測定・分析手段１０は，定期的に（例えば，数秒間隔に）データを計測する機能１０αと，ガベージコレクションのイベント発生時にデータを計測する機能１０βとの２つのデータ測定機能を持っている。
Ｊａｖａ仮想マシン１で使用されているメモリ（ヒープ）の量は，“メモリの割り当て／解放”のイベント発生時に測定されたものが正確な量である。しかし，イベントの発生頻度は非常に高く，すべてのイベント発生時にデータを測定するとアプリケーションの運用に負荷がかかってしまう。メモリ使用量の分析と危険性の予測は，定期的に取得するデータで行うことが可能であり，“メモリの割り当て／解放”イベント発生時にデータの測定を行う必要はない。
測定・分析手段１０は，アプリケーションの運用に負荷をかけずに正確にデータを測定できるように，測定する項目に応じて２つのデータ測定機能（１０α，１０β）から使用するデータ測定機能を選択する。
第３図に示すように，Ｊａｖａ仮想マシン１内の測定・分析手段１０は，メモリ使用量の測定と分析を行うメモリ使用量測定・分析手段１１と，Ｊａｖａスレッドの測定と分析を行うスレッド測定・分析手段１２とを備える。
まず，メモリ使用量測定・分析手段１１について説明する。メモリ使用量測定・分析手段１１は，Ｊａｖａ仮想マシン内１で，使用メモリ（ヒープ）量の定期的な測定とガベージコレクション発生時の測定とを行い，それらの測定で得られたデータを分析する。分析の結果，メモリ量が不足していてＯｕｔＯｆＭｅｍｏｒｙのエラーが発生する危険性がある場合や，メモリ不足が性能に悪影響を及ぼしている場合などには，そのことへの警告を行う。また，そのときの状態の回復に必要なメモリサイズを見積もる。
メモリ使用量測定・分析手段１１は，Ｊａｖａ仮想マシン１が使用中のメモリ量を，定期的な間隔で測定する。このときの測定間隔は，Ｊａｖａ仮想マシン１を起動するときのオプションや，アプリケーションサーバ２内のＪａｖａ仮想マシン制御手段２０（詳細は後述）からのコマンドにより，設定／変更可能である。また，メモリ使用量測定・分析手段１１は，ガベージコレクションのイベント発生時に，データを測定する。
Ｊａｖａ仮想マシン１は，自分自身の動作状況をよく知っているため，自身内でトラブルの危険性を検出することができる。Ｊａｖａ仮想マシン１内でのトラブルで一番深刻なものは，メモリ（ヒープ）不足である。このメモリ不足によってマシン性能が低下し，ひどい場合には処理が止まってしまうこともある。
また，クライアントからのトランザクションの要求量が予想以上に多くなることがあり，メモリ使用量が当初の見積もりよりもオーバーしてしまうことがある。クライアントからの要求量は刻々と変化するものであり，メモリ使用量も状況に応じて変化するものである。このような場合，前述の第３の従来技術のように測定した使用メモリ量としきい値とを単純に比較するだけでは，メモリ不足の危険性を正確に判断することはできない。よって，状況に応じたもっと適切な判断をする必要がある。
Ｊａｖａのアプリケーションでは，メモリが必要なときに，ｎｅｗ演算子でメモリの獲得が行われる。しかし，Ｊａｖａのアプリケーションではメモリの解放をプログラムに書くことはできず，メモリの解放はＪａｖａ仮想マシン１に任されている。Ｊａｖａ仮想マシン１におけるメモリの解放処理，すなわちガベージコレクションは，マシン性能に対して非常に大きな影響を与える。そのため，状況に合わせた様々な方式のガベージコレクションが研究されており，それぞれのＪａｖａ仮想マシン１によって採用しているガベージコレクションの方式は異なる。
よって，メモリ不足の危険性を判断する方法は，すべてのガベージコレクションに適用できる共通の判定方法に加えて，Ｊａｖａ仮想マシン１ごとに採用されているガベージコレクションに固有の判定方法が必要となる。
メモリ使用量測定・分析手段１１は，測定されたデータを分析し，すべてのガベージコレクションに適用できる共通のメモリ不足の危険性の判断と，各Ｊａｖａ仮想マシン１ごとに採用されたガベージコレクションに固有のメモリ不足の危険性の判断とを行う。また，それぞれの判断結果から，危険な状態に対する警告，状態の回復に必要なメモリ量の計算を行う。
メモリ使用量測定・分析手段１１による基本的なデータの分析，危険な状態に対する警告，状態の回復に必要なメモリ量の計算について説明する。まず，ガベージコレクションの発生間隔とメモリ使用量に関する代表的な３つの状態について，図を用いて説明する。
第６図は，ガベージコレクションの発生間隔とメモリ使用量に関する代表的な３つの状態を示す図である。第６図（Ａ）〜（Ｃ）に示すグラフは，メモリ使用量２００の変化とガベージコレクション２１０の発生をグラフ化して表したものの例であり，ガベージコレクション２１０の発生間隔とメモリ使用量２００に関する代表的な３つの状態を示している。
第６図（Ａ）〜（Ｃ）のグラフでは，縦軸にメモリ量をとっており，横軸に時間をとっている。第６図（Ａ）〜（Ｃ）において，実線はメモリ使用量２００の時間変化を示し，点線は設定されている最大ヒープサイズ２２０を示す。Ｊａｖａ仮想マシン１は，“メモリの割り当て”イベントによりメモリ使用量２００が最大ヒープサイズ２２０を超えそうなときに，ガベージコレクション２１０を実行し，メモリの解放を行う。
第６図（Ａ）は，ガベージコレクション２１０が発生しない安定した状態，あるいは，ガベージコレクション２１０の発生間隔が比較的長く，ガベージコレクション２１０によってメモリの空きが回復する状態を表している。第６図（Ｂ）は，ガベージコレクション２１０の発生間隔が短くなる傾向にあるが，ガベージコレクション２１０によってメモリの空きが回復する状態を表している。第６図（Ｃ）は，ガベージコレクション２１０の発生間隔が短く，ガベージコレクション２１０によってメモリの空きが十分に回復しない状態を表している。第６図（Ｂ）の状態，第６図（Ｃ）の状態が，警告の対象となる。
第７図は，警告を行うべき状態を説明する図である。
第７図（Ａ）は，メモリ不足による性能低下の警告を行うべき状態を示している。第７図（Ａ）では，縦軸にガベージコレクションの発生間隔をとっており，横軸にガベージコレクションの発生を順に等間隔にとっている。この例では，ガベージコレクションの発生間隔が，ＧＣ発生間隔警告しきい値１０３を下回って推移している。
第７図（Ｂ），（Ｃ）は，ＯｕｔＯｆＭｅｍｏｒｙの危険性の警告を行うべき状態を示す図である。第７図（Ｂ），（Ｃ）では，縦軸にメモリ量をとっており，横軸に時間をとっている。第７図（Ｂ）において，太線１０４’は（全容量×ＯｕｔＯｆＭｅｍｏｒｙ警告しきい値Ａ１０４）で求められた値である。また，第７図（Ｃ）において，太線１０５’は（全容量×ＯｕｔＯｆＭｅｍｏｒｙ警告しきい値Ｂ１０５）で求められた値である。
第７図（Ｂ）において，メモリ使用量２００の変化を見ると，ＧＣ２１０によってメモリの空きがほとんど回復していない。ＧＣ２１０後のメモリ使用量２００が太線１０４’を上回っていることから，メモリの使用率（メモリ使用量／全容量）がＯｕｔＯｆＭｅｍｏｒｙ警告しきい値Ａ１０４を上回っていることがわかる。
第７図（Ｃ）において，メモリ使用量２００の変化を見ると，ＧＣ２１０ａ，ＧＣ２１０ｂ，ＧＣ２１０ｃと順に徐々にメモリの空きが回復しなくなってきていることがわかる。また，ＧＣ２１０ｂ後，ＧＣ２１０ｃ後のメモリ使用量２００が太線１０５’を上回っていることから，ＧＣ２１０ｂ後，ＧＣ２１０ｃ後のメモリの使用率がＯｕｔＯｆＭｅｍｏｒｙ警告しきい値Ｂ１０５を上回っていることがわかる。
ここで，ＯｕｔＯｆＭｅｍｏｒｙ警告しきい値Ａ１０４は，ＯｕｔＯｆＭｅｍｏｒｙ警告しきい値Ｂ１０５より大きい値であるものとする。メモリの使用率がＯｕｔＯｆＭｅｍｏｒｙ警告しきい値Ａ１０４を下回っていても，メモリの使用率がＯｕｔＯｆＭｅｍｏｒｙ警告しきい値Ｂ１０５を上回って増加傾向にあれば，ＯｕｔＯｆＭｅｍｏｒｙの危険性があると判断される。
以下の（判断１）〜（判断３）は，メモリ使用量測定・分析手段１１による基本的なガベージコレクションのメモリ不足の危険性の判断ロジックを示している。なお，以下の基本的なガベージコレクションの判断において，使用率とはメモリの全容量に対するメモリ使用量の割合を示す。よって，以下の式（１）のとおりとなる。
使用率＝メモリ使用量／全容量 ・・・式（１）
（判断１）ガベージコレクションの発生間隔を測定し，その発生間隔がＧＣ発生間隔警告しきい値１０３を下回る状態が続いている場合には，メモリ不足で性能が低下していると判断する（第７図（Ａ）参照）。
（判断２）ガベージコレクション後のメモリ使用量を測定し，使用率がＯｕｔＯｆＭｅｍｏｒｙ警告しきい値Ａ１０４を上回っている場合には，ＯｕｔＯｆＭｅｍｏｒｙの危険性があると判断する（第７図（Ｂ）参照）。
（判断３）ガベージコレクション後のメモリ使用量を測定し，使用率が連続して増加傾向にあり，それらがＯｕｔＯｆＭｅｍｏｒｙ警告しきい値Ｂ１０５を上回っている場合には，ＯｕｔＯｆＭｅｍｏｒｙの危険性があると判断する（第７図（Ｃ）参照）。
メモリ使用量測定・分析手段１１は，（判断１）〜（判断３）に示すような基本的なガベージコレクションの危険性の判断結果をもとに，ＯｕｔＯｆＭｅｍｏｒｙの危険性の警告，メモリ不足による性能低下の警告などを行う。
また，メモリ使用量測定・分析手段１１は，状態の回復に必要なメモリ量の計算を行う。例えば，（判断１）〜（判断３）における回復に必要なメモリサイズは，ガベージコレクション後のメモリの空き率（空き率＝１−使用率）がメモリ空き回復しきい値１０７を超えるように計算されたサイズとする。計算は，以下の式（２）を満たすｍ（回復のために追加する容量）を求める計算となる。
（空き容量＋ｍ）／（全容量＋ｍ）
＞メモリ空き回復しきい値１０７ ・・・式（２）
以上，メモリ使用量測定・分析手段１１による基本的なデータの分析，危険な状態に対する警告，状態の回復に必要なメモリ量の計算について説明した。さらに各ガベージコレクションの特徴に合わせて判断の追加・改良を行うことにより，より正確なデータの分析，危険な状態に対する警告，状態の回復に必要なメモリ量の計算を行うことができる。
次に，メモリ使用量測定・分析手段１１による世代型ガベージコレクションの特徴に合わせたデータの分析，危険な状態に対する警告，状態の回復に必要なメモリ量の計算について説明する。
世代型のガベージコレクションは，メモリ（ヒープ）を新世代，旧世代の２つの領域に分けて管理している。Ｊａｖａプログラムのオブジェクトがメモリに割り当てられるときには，まず新世代のメモリに割り当てられる。新世代のメモリがいっぱいになると，新世代のガベージコレクション（以下，ｎｅｗＧＣという）が発生する。ｎｅｗＧＣを何度か経験して残ったオブジェクトは，旧世代のメモリに移動される。旧世代のメモリがいっぱいになるとメモリ全体のガベージコレクション（以下，単にガベージコレクションまたはＧＣという）が発生する。したがって，新世代のメモリ使用量は変化が非常に激しいものとなる。
前述の第３の従来技術に示したＪａｖａのＡＰＩに，全体のメモリ量と空きのメモリ量を求めるＡＰＩがある。しかし，これらのＡＰＩが新世代と旧世代を合わせた合計のメモリ量をデータとして返すような場合には，そのデータをグラフにしても第６図に示すようなグラフにはならない。よって，データを正しく分析することができない。世代型ガベージコレクションの場合には，新世代と旧世代のメモリ使用量を別々に測定してデータを分析する必要がある。
第８図は，世代型ガベージコレクションにおけるガベージコレクションの発生間隔とメモリ使用量に関する状態を説明する図である。第８図（Ａ）〜（Ｃ）に示すグラフは，旧世代，新世代別にメモリ使用量（旧世代２０１，新世代２０２）の変化とガベージコレクション（ＧＣ）２１０，ｎｅｗＧＣ２１１の発生をグラフにしたものの例であり，ガベージコレクション２１０，ｎｅｗＧＣ２１１の発生間隔とメモリ使用量（２０１，２０２）に関する代表的な３つの状態を表している。
第８図（Ａ）〜（Ｃ）のグラフでは，縦軸にメモリ量をとっており，横軸に時間をとっている。第８図（Ａ）〜（Ｃ）において，点線は設定されている最大ヒープサイズ２２０を示し，一点鎖線は新世代と旧世代のメモリの領域の境界２２１を示す。一点鎖線から下の領域が旧世代のメモリの領域となり，一点鎖線から点線（最大ヒープサイズ２２０）までの領域が新世代のメモリの領域となる。各世代における実線は，各世代別のメモリ使用量（２０１，２０２）の時間変化を示す。なお，第８図（Ａ）〜（Ｃ）のそれぞれの状態は，第６図（Ａ）〜（Ｃ）のそれぞれの状態に対応する。
Ｊａｖａ仮想マシン１は，メモリの割り当てイベントにより新世代のメモリ使用量２０２が新世代のメモリ量を超えるとき（第８図では最大ヒープサイズ２２０を超えるとき）に，ｎｅｗＧＣ２１１を実行し，新世代のメモリの解放を行う。また，Ｊａｖａ仮想マシン１は，ｎｅｗＧＣ２１１を何度か経験して新世代のメモリに残っているオブジェクトを旧世代のメモリに移し，旧世代のメモリがいっぱいで新世代のメモリからオブジェクトを移せなくなるときに，メモリ全体のガベージコレクション２１０を実行する。
ｎｅｗＧＣ２１１の発生頻度はメモリ全体のＧＣ２１０の発生頻度より高い。しかし，ＧＣ２１０の処理時間が数秒，場合によっては十数秒であるのに対し，ｎｅｗＧＣ２１１の処理時間は数十ミリ秒程度である。レスポンス時間が重要なアプリケーションでは，できるだけＧＣ２１０が発生しない状態（第８図（Ａ）の状態）を維持するようにする必要がある。
ＧＣ２１０が発生するのは，新世代から旧世代に移動するオブジェクトが多い場合であり，長寿命なオブジェクトが多いケースと，新世代のメモリサイズが小さくて溢れが発生するケース（世代が若くても旧世代に移動させる（溢れ）アルゴリズムを採用している場合など）とがある。ｎｅｗＧＣ２１１時に，新世代のメモリから旧世代のメモリに溢れるオブジェクトのサイズ（以下，溢れ量という）を測定することで，第８図（Ｂ）や第８図（Ｃ）の状態を第８図（Ａ）の状態にするのに必要なメモリ量を見積もることができる。
第９図は，溢れ量の測定を説明する図である。第９図（Ａ）は，ｎｅｗＧＣ２１１で新世代２４０のメモリから旧世代２３０のメモリにオブジェクトが溢れる状態を示しており，ハッチング部分が溢れ量である。ここで，ｎｅｗＧＣ２１１が起きた時刻に新世代２４０のメモリ量が十分にあった（ｎｅｗＧＣ２１１の発生するタイミングが伸びた）ものと仮定し，そのときの状態を第９図（Ｂ）のように表現するものとする。これをｎｅｗＧＣ２１１のたびに繰り返すと第９図（Ｃ）のような状態になる。
第９図（Ｃ）は，実際には４回のｎｅｗＧＣ２１１で溢れたオブジェクトが，新世代２４０のメモリ量が無限に存在し，溢れなかったものと仮定した状態を示している。ｋ回目の溢れ量をｔｋと表すとすると，第９図（Ｃ）の時点で溢れなかったと仮定された溢れ量の合計は，ｔ１＋ｔ２＋ｔ３＋ｔ４となる。もし，新世代２４０の領域に最初から元の量のメモリに加えてｔ１＋ｔ２＋ｔ３＋ｔ４の量のメモリが余計にあったなら，４回のｎｅｗＧＣ２１１までで新世代２４０のメモリから溢れるオブジェクトはない。
さらに，時間が経つにつれて不要となるオブジェクトがあるので，それを考慮して溢れ量を見積もると以下のようになる。例えば，第９図（Ｃ）において，１回目のｎｅｗＧＣ２１１で溢れたオブジェクトが溢れずに４回目のｎｅｗＧＣ２１１の時間まで新世代２４０の領域に残っているものとすると，その一部は不要なオブジェクトになっているはずである。同様に，２回目のｎｅｗＧＣ２１１時に溢れたオブジェクト，３回目のｎｅｗＧＣ２１１時に溢れたオブジェクトの中にも，４回目のｎｅｗＧＣ２１１の時間までに不要となるオブジェクトが存在する。第９図（Ｃ）において，４回目のｎｅｗＧＣ２１１までに溢れなかったものとされたオブジェクトの一部は，４回目のｎｅｗＧＣ２１１までに解放されてもよいはずである。実際には，第９図（Ｃ）は，第９図（Ｄ）のような状態であると考えられる。
第９図（Ｄ）において，１回のｎｅｗＧＣ２１１によるオブジェクトの生存率をｄ，ｋ回目の溢れ量をｘｋと表すとすると，
ｘ１＝ｔ１×ｄ３
ｘ２＝ｔ２×ｄ２
ｘ３＝ｔ３×ｄ１
ｘ４＝ｔ４×ｄ０
となり，溢れ量の累計は，ｘ１＋ｘ２＋ｘ３＋ｘ４となる。よって，新世代２４０のメモリ量がｘ１＋ｘ２＋ｘ３＋ｘ４だけ余分にあれば，溢れを起こさなかったこととなる。
一般的に，ｎ回のｎｅｗＧＣの溢れ量の累計は，以下の式（３）で求められる。式（３）において，ｘｔｏｔａｌは溢れ量の累計を示す。
ｘｔｏｔａｌ＝Σｋ＝１ ｎ（ｔｋ×ｄｎ−ｋ） ・・・式（３）
以下，メモリ使用量測定・分析手段１１による世代型ガベージコレクションの特徴に合わせたメモリ不足の危険性の判断ロジックを示す。世代型ガベージコレクションにおけるメモリ不足の危険性の判断は，前述の（判断１）〜（判断３）に，以下の（判断４）と（判断５）とを加えたものとなる。
なお，以下の世代型ガベージコレクションの判断において，メモリ使用率の計算には，式（１）の代わりに以下の式（４）を用いるものとする。
使用率＝旧世代メモリ使用量／旧世代容量 ・・・式（４）
（判断４）ガベージコレクション後のメモリ使用量を測定し，メモリの使用率がメモリ不足警告しきい値１０６を下回っていても（十分にメモリの空きが回復していても），ＧＣの発生間隔がＧＣ発生間隔警告しきい値１０３を下回っており，新世代のメモリ量の割合（新世代容量／全容量）がｎｅｗ世代不足警告しきい値１０８を下回っている場合には，新世代のメモリサイズが小さすぎることが性能に影響している（ＧＣの発生頻度を高くしている）と判断する。
（判断５）式（３）により溢れ量の累計を毎ｎｅｗＧＣ後に計算し，（溢れ量の累計／旧世代空き容量）が溢れ量警告しきい値１０９を超える場合には，ＯｕｔＯｆＭｅｍｏｒｙの危険性があると判断する。
メモリ使用量測定・分析手段１１は，（判断１）〜（判断３）に示した基本的な判断結果と（判断４），（判断５）に示した世代型ガベージコレクションの特徴に合わせた危険性の判断結果とをもとに，ＯｕｔＯｆＭｅｍｏｒｙの危険性の警告，メモリ不足による性能低下の危険性の警告などを行う。
また，メモリ使用量測定・分析手段１１は，状態の回復に必要なメモリ量の計算を行う。例えば，（判断１）〜（判断３）における回復に必要なメモリサイズは，ガベージコレクション後のメモリの空き率（空き率＝１−使用率）がメモリ空き回復しきい値１０７を超えるように計算されたサイズとする。計算は，以下の式（５）を満たすｍ（回復のために追加する容量）を求める計算となる。
（旧世代空き容量＋ｍ）／（旧世代容量＋ｍ）
＞メモリ空き回復しきい値１０７ ・・・式（５）
また，例えば，（判断５）の場合において，回復に必要な追加メモリ量は，あるＧＣとその次のＧＣとの間に発生したｎｅｗＧＣに対して，式（３）により求められた溢れ量の累計とする。
第８図に示すような世代型ガベージコレクションにおける新世代のメモリの領域と旧世代のメモリの領域との割合を，Ｊａｖａ仮想マシン１を起動するときのオプションで設定できるものがある。また，第８図に示すような世代型ガベージコレクションでは新世代のメモリサイズと旧世代のメモリサイズとを一定にしているが，新世代のメモリサイズと旧世代のメモリサイズとをダイナミックに変更する世代型ガベージコレクションもある。
第１０図は，ダイナミックにサイズを変更する世代型ガベージコレクションにおけるガベージコレクションの発生間隔とメモリ使用量に関する状態を説明する図である。第１０図に示すダイナミックにサイズを変更する世代型ガベージコレクションでは，ガベージコレクション２１０直後のメモリの空き容量を，あらかじめ設定された割合で，新世代のメモリの領域と旧世代のメモリの領域とに分配する。
第１０図（Ａ）〜（Ｃ）は，旧世代，新世代別に，メモリ使用量（旧世代２０１，新世代２０２）の変化とガベージコレクション２１０，ｎｅｗＧＣ２１１の発生とをグラフ化して表した例であり，ガベージコレクション２１０，ｎｅｗＧＣ２１１の発生間隔とメモリ使用量とに関する代表的な３つの状態を表している。
第１０図（Ａ）〜（Ｃ）のグラフでは，縦軸にメモリ量をとっており，横軸に時間をとっている。第１０図（Ａ）〜（Ｃ）において，点線は設定されている最大ヒープサイズ２２０を示し，一点鎖線は新世代と旧世代のメモリの領域の境界２２１を示す。一点鎖線から下の領域が旧世代のメモリの領域となり，一点鎖線から点線（最大ヒープサイズ２２０）までの領域が新世代のメモリの領域となる。各世代における実線は，各世代別のメモリ使用量（２０１，２０２）の時間変化を示す。なお，第１０図（Ａ）〜（Ｃ）のそれぞれの状態は，第６図（Ａ）〜（Ｃ）のそれぞれの状態に対応する。
Ｊａｖａ仮想マシン１は，メモリの割り当てイベントにより新世代のメモリ使用量２０２が新世代のメモリ量を超えるとき（第１０図では最大ヒープサイズ２２０を超えるとき）に，ｎｅｗＧＣ２１１を実行し，新世代のメモリの解放を行う。また，Ｊａｖａ仮想マシン１は，ｎｅｗＧＣ２１１を何度か経験して新世代のメモリに残っているオブジェクトを旧世代のメモリに移す。オブジェクトを新世代のメモリから旧世代のメモリに移した分だけ新世代のメモリが少なくなり，旧世代のメモリが増える。
Ｊａｖａ仮想マシン１は，旧世代のメモリがいっぱいになったときに，メモリ全体のガベージコレクション２１０を実行する。このとき，あらかじめ設定された割合で，ガベージコレクション２１０直後のメモリの空き容量を，新世代のメモリの領域と旧世代のメモリの領域とに分配する。
メモリ使用量測定・分析手段１１によるダイナミックにサイズを変更する世代型ガベージコレクションにおけるメモリ不足の危険性の判断は，前述の（判断１）〜（判断３），（判断５）となる。また，ダイナミックにサイズを変更する世代型ガベージコレクションにおいて，使用率の計算には式（１）を用いる。
メモリ使用量測定・分析手段１１は，（判断１）〜（判断３），（判断５）に示す危険性の判断結果をもとに，ＯｕｔＯｆＭｅｍｏｒｙの危険性の警告，メモリ不足による性能低下の警告などを行う。
また，メモリ使用量測定・分析手段１１は，状態の回復に必要なメモリ量の計算を行う。ダイナミックにサイズを変更する世代型ガベージコレクションにおいて，回復に必要なメモリ量の計算は，先に示した式（２）を改良する。例えば，（判断１）〜（判断３）の場合における回復に必要なメモリサイズは，ガベージコレクション後の全容量に対する旧世代空き容量の割合がメモリ空き回復しきい値１０７を超えるように計算されたサイズとする。計算は，以下の式（６）を満たすｍ（回復のために追加する容量）を求める計算となる。
（旧世代空き容量＋旧世代分配率×ｍ）／（全容量＋ｍ）
＞メモリ空き回復しきい値１０７ ・・・式（６）
また，（判断５）の場合における回復に必要な追加メモリ量は，前述の世代型ガベージコレクションの場合と同じである。
メモリ使用量測定・分析手段１１における処理の例について，第１１図から第１５図のフローチャートを用いて説明する。
第１１図から第１５図のフローチャートにおいて，“非ダイナミック世代型ＧＣ”は，新世代，旧世代のメモリサイズをダイナミックには変更しない世代型ガベージコレクションを示すものとする。また，“ダイナミック世代型ＧＣ”は，ダイナミックにサイズを変更する世代型ガベージコレクションを示すものとする。また，“ＧＣ”はメモリ全体のガベージコレクションを示し，“ｎｅｗＧＣ”は世代型ＧＣにおける新世代のガベージコレクションを示す。
第１１図は，メモリ使用量測定・分析処理フローチャートである。
まず，メモリ使用量測定フラグ１０１がＯＮであるか否かを判定し（ステップＳ１），ＯＮでなければ（ＯＦＦであれば）処理を終了する。
ステップＳ１においてＯＮであれば，ＧＣが発生したか否かを判定し（ステップＳ２），ＧＣが発生していなければステップＳ６に進む。
ステップＳ２においてＧＣが発生していれば，第１２図に示すデータ測定・計算処理を行い（ステップＳ３），第１３図に示すデータ分析・警告処理Ａを行い（ステップＳ４），次いで第１４図に示すデータ分析・警告処理Ｂを行い（ステップＳ５），ステップＳ６に進む。
世代型ＧＣであるか否かを判定し（ステップＳ６），世代型ＧＣでなければ処理を終了する。
ステップＳ６において世代型ＧＣであれば，第１５図に示す世代型ＧＣ固有測定・分析処理を行い（ステップＳ７），処理を終了する。
第１２図は，データ測定・計算処理フローチャートである。
まず，今回のＧＣ発生時刻を測定し（ステップＳ１０），今回のＧＣ発生間隔（今回のＧＣ発生時刻−前回のＧＣ発生時刻）を計算する（ステップＳ１１）。次に，ＧＣ直後のメモリ使用量と空き容量とを測定し（ステップＳ１２），ＧＣ直後のメモリの使用率と空き率（空き率＝１−使用率）とを計算し（ステップＳ１３），処理を終了する。
ここで，ステップＳ１２において，世代型ＧＣの場合には，メモリ全体だけではなく，旧世代のメモリについても測定を行う。また，ステップＳ１３のメモリの使用率の計算において，世代型ＧＣでない場合とダイナミック世代型ＧＣである場合には式（１）を用いて計算を行い，非ダイナミック世代型ＧＣである場合には式（４）を用いて計算を行う。
第１３図は，データ分析・警告処理Ａフローチャートである。
まず“今回の使用率≧ｔｈ２（ＯｕｔＯｆＭｅｍｏｒｙ警告しきい値Ａ１０４）”が成立するか否かを判定し（ステップＳ２０），成立すればステップＳ２６に進む。
ステップＳ２０において成立しなければ，“今回の使用率＞前回の使用率”が成立するか否かを判定し（ステップＳ２１），成立しなければ，メモリの使用率の増加が何回連続したかを数えるためのカウンタｃ１を０とし（ステップＳ２３），処理を終了する。
ステップＳ２１において成立すれば，“今回の使用率＞ｔｈ３（ＯｕｔＯｆＭｅｍｏｒｙ警告しきい値Ｂ１０５）”が成立するか否かを判定し（ステップＳ２２），成立しなければ，メモリの使用率の増加が何回連続したかを数えるためのカウンタｃ１を０とし（ステップＳ２３），処理を終了する。
ステップＳ２２において成立すれば，カウンタｃ１を１インクリメント（ｃ１＝ｃ１＋１）する（ステップＳ２４）。
カウンタｃ１があらかじめ任意に設定された値ｎ１以上であるか否かを判定し（ステップＳ２５），値ｎ１以上であればステップＳ２６に進む。ステップＳ２５において値ｎ１以上でなければ，処理を終了する。
ステップＳ２６では，ＯｕｔＯｆＭｅｍｏｒｙの危険性の警告（警告ｗ１）を行い，回復に必要なメモリ量を計算し（ステップＳ２７），処理を終了する。
このステップＳ２７における回復に必要なメモリ量の計算において，世代型ＧＣでない場合には前記式（２）を満たすｍ（回復のために追加する容量）を求める計算を行い，非ダイナミック世代型ＧＣである場合には前記式（５）を満たすｍ（回復のために追加する容量）を求める計算を行い，ダイナミック世代型ＧＣである場合には前記式（６）を満たすｍ（回復のために追加する容量）を求める計算を行う。
第１４図は，データ分析・警告処理Ｂフローチャートである。
まず“今回のＧＣ発生間隔＜ｔｈ１（ＧＣ発生間隔警告しきい値１０３）”が成立するか否かを判定し（ステップＳ３０），成立しなければ，ＧＣ発生間隔が何回連続でＧＣ発生間隔警告しきい値１０３を下回ったかを数えるカウンタｃ２を０とし（ステップＳ３１），処理を終了する。
ステップＳ３０において成立すれば，カウンタｃ２を１インクリメント（ｃ２＝ｃ２＋１）する（ステップＳ３２）。
カウンタｃ２があらかじめ任意に設定された値ｎ２以上であるか否かを判定し（ステップＳ３３），値ｎ２以上でなければ処理を終了する。
ステップＳ３３において，ｃ２が値ｎ２以上であれば，“今回の使用率≧ｔｈ４（メモリ不足警告しきい値１０６）”が成立するか否かを判定し（ステップＳ３４），成立すれば，メモリ不足による性能低下の警告（警告ｗ２）を行い（ステップＳ３５），回復に必要なメモリ量を計算し（ステップＳ３６），処理を終了する。
このステップＳ３６における回復に必要なメモリ量の計算において，世代型ＧＣでない場合には前記式（２）を満たすｍ（回復のために追加する容量）を求める計算を行い，非ダイナミック世代型ＧＣである場合には前記式（５）を満たすｍ（回復のために追加する容量）を求める計算を行い，ダイナミック世代型ＧＣである場合には前記式（６）を満たすｍ（回復のために追加する容量）を求める計算を行う。
ステップＳ３４において成立しなければ，“空き率≧ｔｈ５（メモリ空き回復しきい値１０７）”であるか否かを判定し（ステップＳ３７），成立しなければ，ＧＣが短い間隔で発生しているとの警告（警告ｗ３）を行い（ステップＳ３８），処理を終了する。
ステップＳ３７において成立すれば，非ダイナミック世代型ＧＣであるか否かを判定し（ステップＳ３９），非ダイナミック世代型ＧＣでなければ，メモリの消費スピードに比べてメモリの絶対量が小さいなどの警告（警告ｗ４）を行い（ステップＳ４０），処理を終了する。
ステップＳ３９において非ダイナミック世代型ＧＣであれば，“新世代容量／全容量＜ｔｈ６（ｎｅｗ世代不足警告しきい値１０８）”が成立するか否かを判定し（ステップＳ４１），成立すれば新世代の割合が小さいとの警告（警告ｗ５）を行い（ステップＳ４２），処理を終了する。
ステップＳ４１において成立しなければ，メモリの消費スピードに比べてメモリの絶対量が小さい，Ｓｕｒｖｉｖｏｒ容量の割合が小さいなどの警告（警告ｗ６）を行い（ステップＳ４３），処理を終了する。
第１５図は，世代型ＧＣ固有測定・分析処理フローチャートである。
まず，ｎｅｗＧＣが発生したか否かを判定し（ステップＳ５０），発生していなければ処理を終了する。
ステップＳ５０においてｎｅｗＧＣが発生していれば，ＧＣ後の最初のｎｅｗＧＣか否かを判定し（ステップＳ５１），最初のｎｅｗＧＣでなければステップＳ５３に進む。ステップＳ５１において最初のｎｅｗＧＣであれば，値ｎを１とし（ステップＳ５２），ステップＳ５３に進む。
ｎｅｗＧＣで新世代から旧世代に溢れたオブジェクトの量を測定し（ステップＳ５３），式（３）を用いて溢れ量の累計を計算する（ステップＳ５４）。
次に，“溢れ量の累計／旧世代空き容量＞ｔｈ７（溢れ量警告しきい値１０９）”が成立するか否かを判定し（ステップＳ５５），成立しなければステップＳ５８に進む。
ステップＳ５５において成立すれば，ＯｕｔＯｆＭｅｍｏｒｙの危険性の警告（警告ｗ１）を行い（ステップＳ５６），ステップＳ５４で計算された溢れ量の累計を回復のために追加するメモリ量とし（ステップＳ５７），ステップＳ５８に進む。
値ｎを１インクリメント（ｎ＝ｎ＋１）し（ステップＳ５８），処理を終了する。
第１６図は，メモリ使用量測定・分析手段の警告対象となる状態の例（１）を示す図である。第１６図（Ａ），（Ｂ）は，それぞれが第１３図の各判断条件に対応している。また，第１６図（Ａ），（Ｂ）のグラフでは，縦軸にメモリ量をとっており，横軸に時間をとっている。
第１６図（Ａ）において，太線１０４’は（全容量×ＯｕｔＯｆＭｅｍｏｒｙ警告しきい値Ａ１０４）で求められた値である。また，第１６図（Ｂ）において，太線１０５’は（全容量×ＯｕｔＯｆＭｅｍｏｒｙ警告しきい値Ｂ１０５）で求められた値である。また，第１６図（Ａ），（Ｂ）において，太線１０７’は（全容量×（１−メモリ空き回復しきい値１０７））で求められた値である。
第１６図（Ａ）は，第１３図のステップＳ２０が成立する場合の例である。第１６図（Ａ）において，メモリ使用量２００の変化を見ると，ＧＣ２１０によってメモリの空きがほとんど回復していない。ＧＣ２１０後のメモリ使用量２００が太線１０４’を上回っていることから，メモリの使用率がＯｕｔＯｆＭｅｍｏｒｙ警告しきい値Ａ１０４を上回っていることがわかる。ＯｕｔＯｆＭｅｍｏｒｙ警告しきい値Ａ１０４は，例えば，９０％〜９５％程度である。
第１６図（Ｂ）は，第１３図のステップＳ２１，ステップＳ２２，ステップＳ２５が同時に成立する場合の例である。第１６図（Ｂ）において，メモリ使用量２００の変化を見ると，ＧＣ２１０α，ＧＣ２１０β，ＧＣ２１０γと順に徐々にメモリの空きが回復しなくなってきていることがわかる。また，ＧＣ２１０β後，ＧＣ２１０γ後のメモリ使用量２００が連続して太線１０５’を上回っていることから，ＧＣ２１０β後，ＧＣ２１０γ後のそれぞれのメモリの使用率がＯｕｔＯｆＭｅｍｏｒｙ警告しきい値Ｂ１０５を上回っていることがわかる。
第１７図は，メモリ使用量測定・分析手段の警告対象となる状態の例（２）を示す図である。第１７図（Ａ）〜（Ｃ）は，それぞれが第１４図の各判断条件に対応している。また，第１７図（Ａ）〜（Ｃ）のグラフでは，縦軸にメモリ量をとっており，横軸に時間をとっている。
第１７図（Ａ）において，太線１０６’は（全容量×メモリ不足警告しきい値１０６）で求められた値である。また，第１７図（Ｃ）において，太線１０８’は（全容量×（１−ｎｅｗ世代不足警告しきい値１０８））で求められた値である。また，第１７図（Ａ）〜（Ｃ）において，太線１０７’は（全容量×（１−メモリ空き回復しきい値１０７））で求められた値である。
第１７図（Ａ）は，第１４図のステップＳ３４が成立する場合の例である。第１７図（Ａ）において，メモリ使用量２００の変化を見ると，ＧＣ２１０によってメモリの空きはある程度回復するが，ＧＣ発生間隔が短くなっている。ＧＣ２１０後のメモリ使用量２００が太線１０６’を上回っていることから，メモリの使用率がメモリ不足警告しきい値１０６を上回っていることがわかる。メモリ不足警告しきい値１０６は，例えば，８０％〜９０％程度である。
第１７図（Ｂ）は，第１４図のステップＳ３７が成立する場合の例であり，世代型ＧＣでない場合の例である。第１７図（Ｂ）において，メモリ使用量２００の変化を見ると，ＧＣ２１０によってメモリの空きは回復している。また，ＧＣ２１０後のメモリ使用量２００が太線１０７’を下回っていることから，メモリの空き率がメモリ空き回復しきい値１０７を上回っていることがわかる。
しかし，ＧＣ発生間隔が短くなっている。これは，メモリの絶対量（最大ヒープサイズ２２０）が小さいなどの理由による。メモリ空き回復しきい値１０７は，例えば，５０％〜６０％程度である。
第１７図（Ｃ）は，第１４図のステップＳ４１が成立する場合の例であり，非ダイナミック世代型ＧＣの場合の例である。第１７図（Ｃ）において，旧世代のメモリ使用量２０１の変化を見ると，ＧＣ２１０によってメモリの空きは回復している。また，ＧＣ２１０後の旧世代のメモリ使用量２０１が太線１０７’を下回っていることから，メモリの空き率がメモリ空き回復しきい値１０７を上回っている。
しかし，ＧＣ発生間隔が短くなっている。また，旧世代のメモリと新世代のメモリの境界２２１が太線１０８’を上回っていることから，メモリの全容量に対する新世代容量の割合がｎｅｗ世代不足警告しきい値１０８を下回っていることがわかる。これは，新世代容量が小さいからである。ｎｅｗ世代不足警告しきい値１０８は，例えば，５％〜１０％程度である。
次に，Ｊａｖａアプリケーションのスレッドがデッドロックを起こしてるか否かを測定・分析し，警告するスレッド測定・分析手段１２について説明する。
Ｊａｖａのスレッドの状態としては，実行中，実行可能状態で待機中，サスペンド中，スリープ中，ロックの解放待ちで待機中などの状態がある。
前述の第４の従来技術で示したように，スレッドの状態遷移は，Ｊａｖａ仮想マシン・プロファイラインタフェースのイベントによって測定することができる。実際に，これらのイベントを分析してスレッドの状態を調べることで，デッドロックしたスレッドを検出する製品がある。
しかし，スレッドの状態遷移は非常に頻繁に起こるものであり，これらのイベントをすべて測定しているとアプリケーションの運用に大きな負荷がかかることとなる。よって，Ｊａｖａ仮想マシン・プロファイラインタフェースのイベントによってスレッドの状態遷移を測定して分析するデッドロックの検出は，開発時に行われるべきものである。
これに対し本システムでは，スレッド測定・分析手段１２が，アプリケーションの運用に負荷がかからない程度の間隔で定期的にスレッドの状態を測定する。また，ロックの解放待ちで待機中のスレッドを記録し，次の測定のときに同じスレッドが再びロックの解放待ちで待機しているか否かを確認する。連続して待機している場合には，その連続回数をカウントする。ロックの解放待ちでの待機状態の連続回数がデッドロック警告しきい値１１０を超えたスレッドが２個以上ある場合には，デッドロックの危険性があると判断する。
これにより，アプリケーションの運用時に，その運用に負荷をかけずにデッドロックの危険性を検出することができる。
第１８図は，スレッド測定・分析処理フローチャートである。
まず，スレッド測定フラグ１０２がＯＮであるか否かを判定し（ステップＳ６０），ＯＮでなければ（ＯＦＦであれば）ステップＳ６８に進む。
ステップＳ６０においてＯＮであれば，すべてのスレッドの状態を測定し（ステップＳ６１），現在ロックの解放待ちで待機中のスレッドを抽出して記録する（ステップＳ６２）。また，すでに記録されていたスレッドのうち，今回抽出されなかったスレッドの記録を削除する（ステップＳ６３）。
今回初めて抽出されたスレッドの待機状態が連続する回数のカウンタ（これを連続カウンタという）を１とし（ステップＳ６４），前回も抽出されたスレッドの連続カウンタを１インクリメントする（ステップＳ６５）。
次に，“連続カウンタ≧ｔｈ８（デッドロック警告しきい値１１０）”を満たすスレッドが２つ以上存在するか否かを判定し（ステップＳ６６），存在しなければステップＳ６８に進む。
ステップＳ６６において存在すれば，デッドロックの危険性があるとの警告（警告ｗ７）を行い（ステップＳ６７），ステップＳ６８に進む。
Ｊａｖａ仮想マシン１の起動時にオプションで，または，アプリケーションサーバ２のＪａｖａ仮想マシン制御手段２０（後述）からコマンドで指定された測定間隔だけ，スレッド状態の測定をスリープし（ステップＳ６８），ステップＳ６０に戻る。
以上のように，本システムでは，スレッドの状態遷移をすべて測定する方法ではなく，定期的な測定により判断を行うアルゴリズムを採用しているため，アプリケーションの運用環境に負荷をかけずに，スレッドのデッドロックの危険性を警告することができる。
次に，Ｊａｖａ仮想マシン１が分析結果を上位層（アプリケーションサーバ２）に通知し，最適な運用環境になるようにフィードバックする技術手段について説明する。
第１９図は，Ｊａｖａ仮想マシンとアプリケーションサーバとの連携によるＪａｖａ仮想マシンへの処理の振り分けを示す図である。第１９図のシステムでは，ＯＳ４の上層に４つのＪａｖａ仮想マシン１ａ〜１ｄがあり，それぞれが測定・分析手段１０ａ〜１０ｄを有している。Ｊａｖａ仮想マシン１ａ〜１ｄの上位層にはアプリケーションサーバ２がある。
各Ｊａｖａ仮想マシン１ａ〜１ｄの起動は，上位層のアプリケーションサーバ２が行っており，各Ｊａｖａ仮想マシン１ａ〜１ｄとアプリケーションサーバ２との間には密接な関係がある。アプリケーションサーバ２は，複数のＪａｖａ仮想マシン１ａ〜１ｄを起動し，各Ｊａｖａ仮想マシン１ａ〜１ｄにクライアントからの要求を振り分け，アプリケーションを処理する。
各Ｊａｖａ仮想マシン１ａ〜１ｄ内の測定・分析手段１０ａ〜１０ｄで行った分析の分析結果は，直接にアプリケーションサーバ２に通知される。アプリケーションサーバ２は，受け取った分析結果の通知をアプリケーションの運用環境にフィードバックし，クライアントからの要求をより適切にＪａｖａ仮想マシン１ａ〜１ｄに振り分ける。
例えば，Ｊａｖａ仮想マシン１ａがアプリケーションサーバ２にメモリ不足でＯｕｔＯｆＭｅｍｏｒｙのエラーになる危険性が高いという通知を送るものとする。アプリケーションサーバ２は，このＪａｖａ仮想マシン１ａへの処理の振り分けを中止し，Ｊａｖａ仮想マシン１ａが現在の手持ちの処理を終わらせたところで，新しいＪａｖａ仮想マシン１ｂ〜１ｄに処理を振り分けることができる。
まず，Ｊａｖａ仮想マシン１とアプリケーションサーバ２とが連携することについて説明する。
第２０図は，Ｊａｖａ仮想マシンとアプリケーションサーバとの連携を示す図である。アプリケーションサーバ２内のＪａｖａ仮想マシン制御手段２０は，Ｊａｖａ仮想マシン１の起動・停止を行い，Ｊａｖａ仮想マシン１にアプリケーションの処理を振り分ける手段である。このＪａｖａ仮想マシン制御手段２０とＪａｖａ仮想マシン１とは，Ｊａｖａ仮想マシン連携手段３により互いに連携している。
Ｊａｖａ仮想マシン連携手段３は，分析結果通知手段３１を備える。この分析結果通知手段３１は，プロセス間通信で直接に分析結果を通知する機能と，ファイルなどの媒体を経由して分析結果を通知する機能とを持つ。
Ｊａｖａ仮想マシン１内の測定・分析手段１０は，分析結果通知手段３１を用いて，Ｊａｖａ仮想マシン制御手段２０に分析結果を送る。
Ｊａｖａ仮想マシン制御手段２０は，分析結果通知手段３１により送られてきた分析結果をもとに，Ｊａｖａ仮想マシン１の起動・停止の制御と，Ｊａｖａ仮想マシンへのアプケーションの処理の振り分けとを行う。ここで，Ｊａｖａ仮想マシン制御手段２０内で，Ｊａｖａ仮想マシン１からの情報をもとに，Ｊａｖａ仮想マシン１の起動・停止やＪａｖａ仮想マシン１へのアプリケーションの振り分けを最適に行う手段は，Ｊａｖａ仮想マシン最適制御手段２１である。
また，Ｊａｖａ仮想マシン連携手段３は，コマンド通知手段３２を備える。このコマンド通知手段３２は，プロセス間通信で直接にコマンドを通知する。
Ｊａｖａ仮想マシン制御手段２０は，コマンド通知手段３２を用いて，測定の種類ごとに測定・分析の開始／中断を指示するコマンド，分析結果の判定に使用するしきい値の設定・変更を指示するコマンド，強制ガベージコレクションを指示するコマンドなどを送付する。例えば，警告が長期間に渡って通知されない場合などには，Ｊａｖａ仮想マシン制御手段２０は，コマンド通知手段３２を用いて，Ｊａｖａ仮想マシン１にメモリ使用量などの測定の中断を指示するコマンドを送付することができる。
第２１図は，分析結果通知処理フローチャートである。ここでは，分析結果通知処理を，Ｊａｖａ仮想マシン１の測定・分析手段１０側の処理と，アプリケーションサーバ２のＪａｖａ仮想マシン制御手段２０側の処理とにわけて説明する。
第２１図（Ａ）は，測定・分析手段１０側の分析結果通知処理フローチャートである。測定・分析手段１０は，警告があるか否かを判定し（ステップＳ７０），警告があれば，分析結果通知手段３１を用いてＪａｖａ仮想マシン制御手段２０に警告を通知する（ステップＳ７１）。このとき回復に必要なメモリ量の情報もあれば，同時に通知する。また，警告は，プロセス間通信で送付してもよいし，ログファイルに出力してもよい。
第２１図（Ｂ）は，Ｊａｖａ仮想マシン制御手段２０側の分析結果通知処理フローチャートである。Ｊａｖａ仮想マシン制御手段２０は，警告を受信したか否かを判定し（ステップＳ８０），警告を受信していれば，その警告をＪａｖａ仮想マシン最適制御手段２１に渡す（ステップＳ８１）。このとき回復に必要なメモリ量の情報も受信していれば，同時に渡す。
第２２図は，コマンド通知処理フローチャートである。ここでは，コマンド通知処理を，アプリケーションサーバ２のＪａｖａ仮想マシン制御手段２０側の処理と，Ｊａｖａ仮想マシン１の測定・分析手段１０側の処理とにわけて説明する。
第２２図（Ａ）は，Ｊａｖａ仮想マシン制御手段２０側のコマンド通知処理フローチャートである。Ｊａｖａ仮想マシン制御手段２０は，測定・分析手段１０への動作環境変更のコマンドがあるか否かを判定し（ステップＳ９０），コマンドがあれば，コマンド通知手段３２を用いて測定・分析手段１０に設定変更のためのコマンドを送付する（ステップＳ９１）。また，コマンドはプロセス間通信で送付する。
ここで，動作環境変更のコマンドの例としては，例えば，以下のようなものがある。
（１）メモリ使用量の測定開始コマンド
（２）メモリ使用量の測定中断コマンド
（３）スレッドの測定開始コマンド
（４）スレッドの測定終了コマンド
（５）しきい値の設定／変更コマンド
（６）強制ガベージコレクションコマンド
第２２図（Ｂ）は，測定・分析手段１０側のコマンド通知処理フローチャートである。測定・分析手段１０は，コマンドを受信したか否かを判定し（ステップＳ１００），コマンドを受信していれば，そのコマンドを実行する（ステップＳ１０１）。
ここで，コマンド実行の例としては，例えば，以下のようなものがある。
（１）メモリ使用量の測定開始／中断コマンドであれば，メモリ使用量測定フラグ１０１をＯＮ／ＯＦＦする。
（２）スレッドの測定開始／終了コマンドであれば，スレッド測定フラグ１０２をＯＮ／ＯＦＦする。
（３）しきい値の設定／変更コマンドであれば，該当するしきい値（１０３〜１１０）を設定／変更する。
（４）強制ガベージコレクションコマンドであれば，Ｊａｖａ仮想マシン１のガベージコレクション処理を呼ぶ。
次に，分析結果をアプリケーションの運用環境にフィードバックすることについて説明する。
Ｊａｖａ仮想マシン１内の測定・分析手段１０での分析結果として，ＯｕｔＯｆＭｅｍｏｒｙの危険性の警告，メモリ不足による性能低下の警告，回復に必要なメモリサイズなどの通知をＪａｖａ仮想マシン制御手段２０に送付する。ここで，Ｊａｖａ仮想マシン１とＪａｖａ仮想マシン制御手段２０とが，プロセス間通信により直接に結合されているものとすると，通知は直ちにアプリケーションサーバ２に届くこととなる。Ｊａｖａ仮想マシン制御手段２０は，通知が届いているか否かを定期的に確認し，通知を受け付けたら直ちにその通知をＪａｖａ仮想マシン最適制御手段２１に渡し，アプリケーションの運用環境にフィードバックする。
例えば，Ｊａｖａ仮想マシン１からＯｕｔＯｆＭｅｍｏｒｙの危険性の警告の通知を受けた場合，Ｊａｖａ仮想マシン最適制御手段２１は，そのＪａｖａ仮想マシン１へのアプリケーション処理の振り分けを止める。そのＪａｖａ仮想マシン１が現在処理中のアプリケーションを終了したら，代替のＪａｖａ仮想マシン１’を立ち上げる。代替のＪａｖａ仮想マシン１’を立ち上げるときには，Ｊａｖａ仮想マシン１から通知された回復に必要なメモリサイズをもとに，代替のＪａｖａ仮想マシン１’の起動時のオプションで最適なメモリサイズを指定する。
また，Ｊａｖａ仮想マシン１からメモリ不足による性能低下の警告の通知を受けた場合，Ｊａｖａ仮想マシン最適制御手段２１は，次回にＪａｖａ仮想マシン１を立ち上げるときに，通知された回復に必要なメモリサイズをもとに，Ｊａｖａ仮想マシン１起動時のオプションで最適なメモリサイズを指定する。メモリ不足による性能低下の警告を出したＪａｖａ仮想マシン１へのアプリケーション処理の振り分けを減らすというフィードバックの方法もある。
スレッドのデッドロックの危険性の警告の通知は，Ｊａｖａ仮想マシン１の起動やアプリケーション処理の振り分け制御にはフィードバックしない。この情報は，アプリケーションサーバ２のログ情報としてファイルに残し，後のアプリケーションの見直しに利用する。
第２３図は，Ｊａｖａ仮想マシン最適制御処理フローチャートである。
まず，警告，回復に必要なメモリサイズを受け取り（ステップＳ１１０），警告の種類を判定する（ステップＳ１１１）。
ステップＳ１１１においてＯｕｔＯｆＭｅｍｏｒｙの危険性の警告（警告ｗ１）であれば，アプリケーションの終了を待って警告の出たＪａｖａ仮想マシン１を終了させる（ステップＳ１１２）。代替のＪａｖａ仮想マシン１’を起動し（ステップＳ１１３），処理を終了する。代替のＪａｖａ仮想マシン１’の起動時には，受け取った回復に必要なメモリサイズをもとに，オプションで最適なメモリサイズを指定する。
ステップＳ１１１においてメモリ不足による性能低下の警告（警告ｗ２）であれば，受け取った回復に必要なメモリサイズを保存し（ステップＳ１１４），処理を終了する。次回のＪａｖａ仮想マシン１の起動時には，保存した回復に必要なメモリサイズをもとに，オプションで最適なメモリサイズを指定する。
ステップＳ１１１においてデッドロックの危険性の警告（警告ｗ７）であれば，デッドロックの危険性の警告をログに記録する（ステップＳ１１５）。その旨を運用管理者に通知し（ステップＳ１１６），処理を終了する。
本システムの効果は，以下のとおりである。本システムでは，メモリの割り当てと解放のすべてを測定する方法ではなく，ガベージコレクションのイベント発生時の測定と，必要に応じてメモリ使用量の定期的な測定とによって判断を行うアルゴリズムを採用しているため，アプリケーションの運用環境に負荷をかけずに，ＯｕｔＯｆＭｅｍｏｒｙの危険性やメモリ不足による性能低下の警告をすることができる。
また，測定したデータを採取して外部プロセスでデータの分析を行う方法では，データの測定から回復に向けたフィードバックまでに時間がかかり，タイムリー性を損なう可能性がある。本システムでは，アプリケーションを動かしているＪａｖａ仮想マシン内にデータを測定・分析する手段があるため，よりタイムリーなフィードバックを行うことができる。
また，本システムでは，各Ｊａｖａ仮想マシンが採用している様々なガベージコレクションに応じて危険性を判断するための改良アルゴリズムを多段的に持っているため，より正確な危険性の判断ができる。
また，単なるＯｕｔＯｆＭｅｍｏｒｙの危険性やメモリ不足による性能低下の警告だけでは，再度同じような状態になる危険性があるが，本システムでは，Ｊａｖａ仮想マシンの最適な運用に必要なメモリ量を合わせて通知するため，回復に向けたより適切なフィードバックを行うことができる。
また，本システムでは，Ｊａｖａ仮想マシンのデータを測定・分析し，危険性を通知する手段と上位層（アプリケーションサーバ）のＪａｖａ仮想マシンを制御する手段とがプロセス間通信により直接つながっており，警告の通知とフィードバックを人が介することなく自動的に行えるため，問題があってから回復を行うまでのタイミングが遅れる危険性が低くなる。
Ｊａｖａ仮想マシン１は，測定・分析手段１０を備える。また，測定・分析手段１０は，メモリ使用量測定・分析手段１１と，スレッド測定・分析手段１２と，設定データ１００とを備える。
アプリケーションサーバ２は，Ｊａｖａ仮想マシン制御手段２０を備える。また，そのＪａｖａ仮想マシン制御手段２０は，Ｊａｖａ仮想マシン最適制御手段２１を備える。
Ｊａｖａ仮想マシン連携手段３は，分析結果通知手段３１と，コマンド通知手段３２とを備える。
第４図は，設定データの例を示す図である。測定・分析手段１０が備える設定データ１００は，第４図に示すように，メモリ使用量測定フラグ１０１，スレッド測定フラグ１０２，ＧＣ発生間隔警告しきい値（ｔｈ１）１０３，ＯｕｔＯｆＭｅｍｏｒｙ警告しきい値Ａ（ｔｈ２）１０４，ＯｕｔＯｆＭｅｍｏｒｙ警告しきい値Ｂ（ｔｈ３）１０５，メモリ不足警告しきい値（ｔｈ４）１０６，メモリ空き回復しきい値（ｔｈ５）１０７，ｎｅｗ世代不足警告しきい値（ｔｈ６）１０８，溢れ量警告しきい値（ｔｈ７）１０９，デッドロック警告しきい値（ｔｈ８）１１０のデータである。なお，上記ＧＣはガベージコレクションを意味する。以下，場合によってガベージコレクションをＧＣと記載する。
設定データ１００におけるこれらの値は，アプリケーションサーバ２がコマンドを発行して設定することができる。また，事前にまたは随時，図示省略した設定用プログラムを用いてシステム管理者等が設定することもできる。
以下，各手段の動作を説明するが，最初に，Ｊａｖａ仮想マシン１内でデータの測定と分析，危険性の予測を行う部分について説明し，次に，分析結果をアプリケーションサーバ２に通知して最適な運用環境になるようにフィードバックする部分について説明する。
本発明では，第３図に示すように，Ｊａｖａ仮想マシン１がその内部に測定・分析手段１０を備える。データの測定・分析，トラブル発生の予測は，Ｊａｖａ仮想マシン１の内部で行われる。よって，本発明では，測定データをデータベースなどに一度出力して分析プログラムによって判断するような第１の従来技術に比べて，データの測定から分析，トラブルの予測までをタイムリーに行うことができる。
第５図は，測定・分析手段を説明する図である。Ｊａｖａ仮想マシン１内の測定・分析手段１０は，定期的に（例えば，数秒間隔に）データを計測する機能１０αと，ガベージコレクションのイベント発生時にデータを計測する機能１０βとの２つのデータ測定機能を持っている。
Ｊａｖａ仮想マシン１で使用されているメモリ（ヒープ）の量は，“メモリの割り当て／解放”のイベント発生時に測定されたものが正確な量である。しかし，イベントの発生頻度は非常に高く，すべてのイベント発生時にデータを測定するとアプリケーションの運用に負荷がかかってしまう。メモリ使用量の分析と危険性の予測は，定期的に取得するデータで行うことが可能であり，“メモリの割り当て／解放”イベント発生時にデータの測定を行う必要はない。
測定・分析手段１０は，アプリケーションの運用に負荷をかけずに正確にデータを測定できるように，測定する項目に応じて２つのデータ測定機能（１０α，１０β）から使用するデータ測定機能を選択する。
第３図に示すように，Ｊａｖａ仮想マシン１内の測定・分析手段１０は，メモリ使用量の測定と分析を行うメモリ使用量測定・分析手段１１と，Ｊａｖａスレッドの測定と分析を行うスレッド測定・分析手段１２とを備える。
まず，メモリ使用量測定・分析手段１１について説明する。メモリ使用量測定・分析手段１１は，Ｊａｖａ仮想マシン内１で，使用メモリ（ヒープ）量の定期的な測定とガベージコレクション発生時の測定とを行い，それらの測定で得られたデータを分析する。分析の結果，メモリ量が不足していてＯｕｔＯｆＭｅｍｏｒｙのエラーが発生する危険性がある場合や，メモリ不足が性能に悪影響を及ぼしている場合などには，そのことへの警告を行う。また，そのときの状態の回復に必要なメモリサイズを見積もる。
メモリ使用量測定・分析手段１１は，Ｊａｖａ仮想マシン１が使用中のメモリ量を，定期的な間隔で測定する。このときの測定間隔は，Ｊａｖａ仮想マシン１を起動するときのオプションや，アプリケーションサーバ２内のＪａｖａ仮想マシン制御手段２０（詳細は後述）からのコマンドにより，設定／変更可能である。また，メモリ使用量測定・分析手段１１は，ガベージコレクションのイベント発生時に，データを測定する。
Ｊａｖａ仮想マシン１は，自分自身の動作状況をよく知っているため，自身内でトラブルの危険性を検出することができる。Ｊａｖａ仮想マシン１内でのトラブルで一番深刻なものは，メモリ（ヒープ）不足である。このメモリ不足によってマシン性能が低下し，ひどい場合には処理が止まってしまうこともある。
また，クライアントからのトランザクションの要求量が予想以上に多くなることがあり，メモリ使用量が当初の見積もりよりもオーバーしてしまうことがある。クライアントからの要求量は刻々と変化するものであり，メモリ使用量も状況に応じて変化するものである。このような場合，前述の第３の従来技術のように測定した使用メモリ量としきい値とを単純に比較するだけでは，メモリ不足の危険性を正確に判断することはできない。よって，状況に応じたもっと適切な判断をする必要がある。
Ｊａｖａのアプリケーションでは，メモリが必要なときに，ｎｅｗ演算子でメモリの獲得が行われる。しかし，Ｊａｖａのアプリケーションではメモリの解放をプログラムに書くことはできず，メモリの解放はＪａｖａ仮想マシン１に任されている。Ｊａｖａ仮想マシン１におけるメモリの解放処理，すなわちガベージコレクションは，マシン性能に対して非常に大きな影響を与える。そのため，状況に合わせた様々な方式のガベージコレクションが研究されており，それぞれのＪａｖａ仮想マシン１によって採用しているガベージコレクションの方式は異なる。
よって，メモリ不足の危険性を判断する方法は，すべてのガベージコレクションに適用できる共通の判定方法に加えて，Ｊａｖａ仮想マシン１ごとに採用されているガベージコレクションに固有の判定方法が必要となる。
メモリ使用量測定・分析手段１１は，測定されたデータを分析し，すべてのガベージコレクションに適用できる共通のメモリ不足の危険性の判断と，各Ｊａｖａ仮想マシン１ごとに採用されたガベージコレクションに固有のメモリ不足の危険性の判断とを行う。また，それぞれの判断結果から，危険な状態に対する警告，状態の回復に必要なメモリ量の計算を行う。
メモリ使用量測定・分析手段１１による基本的なデータの分析，危険な状態に対する警告，状態の回復に必要なメモリ量の計算について説明する。まず，ガベージコレクションの発生間隔とメモリ使用量に関する代表的な３つの状態について，図を用いて説明する。
第６図は，ガベージコレクションの発生間隔とメモリ使用量に関する代表的な３つの状態を示す図である。第６図（Ａ）〜（Ｃ）に示すグラフは，メモリ使用量２００の変化とガベージコレクション２１０の発生をグラフ化して表したものの例であり，ガベージコレクション２１０の発生間隔とメモリ使用量２００に関する代表的な３つの状態を示している。
第６図（Ａ）〜（Ｃ）のグラフでは，縦軸にメモリ量をとっており，横軸に時間をとっている。第６図（Ａ）〜（Ｃ）において，実線はメモリ使用量２００の時間変化を示し，点線は設定されている最大ヒープサイズ２２０を示す。Ｊａｖａ仮想マシン１は，“メモリの割り当て”イベントによりメモリ使用量２００が最大ヒープサイズ２２０を超えそうなときに，ガベージコレクション２１０を実行し，メモリの解放を行う。
第６図（Ａ）は，ガベージコレクション２１０が発生しない安定した状態，あるいは，ガベージコレクション２１０の発生間隔が比較的長く，ガベージコレクション２１０によってメモリの空きが回復する状態を表している。第６図（Ｂ）は，ガベージコレクション２１０の発生間隔が短くなる傾向にあるが，ガベージコレクション２１０によってメモリの空きが回復する状態を表している。第６図（Ｃ）は，ガベージコレクション２１０の発生間隔が短く，ガベージコレクション２１０によってメモリの空きが十分に回復しない状態を表している。第６図（Ｂ）の状態，第６図（Ｃ）の状態が，警告の対象となる。
第７図は，警告を行うべき状態を説明する図である。
第７図（Ａ）は，メモリ不足による性能低下の警告を行うべき状態を示している。第７図（Ａ）では，縦軸にガベージコレクションの発生間隔をとっており，横軸にガベージコレクションの発生を順に等間隔にとっている。この例では，ガベージコレクションの発生間隔が，ＧＣ発生間隔警告しきい値１０３を下回って推移している。
第７図（Ｂ），（Ｃ）は，ＯｕｔＯｆＭｅｍｏｒｙの危険性の警告を行うべき状態を示す図である。第７図（Ｂ），（Ｃ）では，縦軸にメモリ量をとっており，横軸に時間をとっている。第７図（Ｂ）において，太線１０４’は（全容量×ＯｕｔＯｆＭｅｍｏｒｙ警告しきい値Ａ１０４）で求められた値である。また，第７図（Ｃ）において，太線１０５’は（全容量×ＯｕｔＯｆＭｅｍｏｒｙ警告しきい値Ｂ１０５）で求められた値である。
第７図（Ｂ）において，メモリ使用量２００の変化を見ると，ＧＣ２１０によってメモリの空きがほとんど回復していない。ＧＣ２１０後のメモリ使用量２００が太線１０４’を上回っていることから，メモリの使用率（メモリ使用量／全容量）がＯｕｔＯｆＭｅｍｏｒｙ警告しきい値Ａ１０４を上回っていることがわかる。
第７図（Ｃ）において，メモリ使用量２００の変化を見ると，ＧＣ２１０ａ，ＧＣ２１０ｂ，ＧＣ２１０ｃと順に徐々にメモリの空きが回復しなくなってきていることがわかる。また，ＧＣ２１０ｂ後，ＧＣ２１０ｃ後のメモリ使用量２００が太線１０５’を上回っていることから，ＧＣ２１０ｂ後，ＧＣ２１０ｃ後のメモリの使用率がＯｕｔＯｆＭｅｍｏｒｙ警告しきい値Ｂ１０５を上回っていることがわかる。
ここで，ＯｕｔＯｆＭｅｍｏｒｙ警告しきい値Ａ１０４は，ＯｕｔＯｆＭｅｍｏｒｙ警告しきい値Ｂ１０５より大きい値であるものとする。メモリの使用率がＯｕｔＯｆＭｅｍｏｒｙ警告しきい値Ａ１０４を下回っていても，メモリの使用率がＯｕｔＯｆＭｅｍｏｒｙ警告しきい値Ｂ１０５を上回って増加傾向にあれば，ＯｕｔＯｆＭｅｍｏｒｙの危険性があると判断される。
以下の（判断１）〜（判断３）は，メモリ使用量測定・分析手段１１による基本的なガベージコレクションのメモリ不足の危険性の判断ロジックを示している。なお，以下の基本的なガベージコレクションの判断において，使用率とはメモリの全容量に対するメモリ使用量の割合を示す。よって，以下の式（１）のとおりとなる。
使用率＝メモリ使用量／全容量 ・・・式（１）
（判断１）ガベージコレクションの発生間隔を測定し，その発生間隔がＧＣ発生間隔警告しきい値１０３を下回る状態が続いている場合には，メモリ不足で性能が低下していると判断する（第７図（Ａ）参照）。
（判断２）ガベージコレクション後のメモリ使用量を測定し，使用率がＯｕｔＯｆＭｅｍｏｒｙ警告しきい値Ａ１０４を上回っている場合には，ＯｕｔＯｆＭｅｍｏｒｙの危険性があると判断する（第７図（Ｂ）参照）。
（判断３）ガベージコレクション後のメモリ使用量を測定し，使用率が連続して増加傾向にあり，それらがＯｕｔＯｆＭｅｍｏｒｙ警告しきい値Ｂ１０５を上回っている場合には，ＯｕｔＯｆＭｅｍｏｒｙの危険性があると判断する（第７図（Ｃ）参照）。
メモリ使用量測定・分析手段１１は，（判断１）〜（判断３）に示すような基本的なガベージコレクションの危険性の判断結果をもとに，ＯｕｔＯｆＭｅｍｏｒｙの危険性の警告，メモリ不足による性能低下の警告などを行う。
また，メモリ使用量測定・分析手段１１は，状態の回復に必要なメモリ量の計算を行う。例えば，（判断１）〜（判断３）における回復に必要なメモリサイズは，ガベージコレクション後のメモリの空き率（空き率＝１−使用率）がメモリ空き回復しきい値１０７を超えるように計算されたサイズとする。計算は，以下の式（２）を満たすｍ（回復のために追加する容量）を求める計算となる。
（空き容量＋ｍ）／（全容量＋ｍ）
＞メモリ空き回復しきい値１０７ ・・・式（２）
以上，メモリ使用量測定・分析手段１１による基本的なデータの分析，危険な状態に対する警告，状態の回復に必要なメモリ量の計算について説明した。さらに各ガベージコレクションの特徴に合わせて判断の追加・改良を行うことにより，より正確なデータの分析，危険な状態に対する警告，状態の回復に必要なメモリ量の計算を行うことができる。
次に，メモリ使用量測定・分析手段１１による世代型ガベージコレクションの特徴に合わせたデータの分析，危険な状態に対する警告，状態の回復に必要なメモリ量の計算について説明する。
世代型のガベージコレクションは，メモリ（ヒープ）を新世代，旧世代の２つの領域に分けて管理している。Ｊａｖａプログラムのオブジェクトがメモリに割り当てられるときには，まず新世代のメモリに割り当てられる。新世代のメモリがいっぱいになると，新世代のガベージコレクション（以下，ｎｅｗＧＣという）が発生する。ｎｅｗＧＣを何度か経験して残ったオブジェクトは，旧世代のメモリに移動される。旧世代のメモリがいっぱいになるとメモリ全体のガベージコレクション（以下，単にガベージコレクションまたはＧＣという）が発生する。したがって，新世代のメモリ使用量は変化が非常に激しいものとなる。
前述の第３の従来技術に示したＪａｖａのＡＰＩに，全体のメモリ量と空きのメモリ量を求めるＡＰＩがある。しかし，これらのＡＰＩが新世代と旧世代を合わせた合計のメモリ量をデータとして返すような場合には，そのデータをグラフにしても第６図に示すようなグラフにはならない。よって，データを正しく分析することができない。世代型ガベージコレクションの場合には，新世代と旧世代のメモリ使用量を別々に測定してデータを分析する必要がある。
第８図は，世代型ガベージコレクションにおけるガベージコレクションの発生間隔とメモリ使用量に関する状態を説明する図である。第８図（Ａ）〜（Ｃ）に示すグラフは，旧世代，新世代別にメモリ使用量（旧世代２０１，新世代２０２）の変化とガベージコレクション（ＧＣ）２１０，ｎｅｗＧＣ２１１の発生をグラフにしたものの例であり，ガベージコレクション２１０，ｎｅｗＧＣ２１１の発生間隔とメモリ使用量（２０１，２０２）に関する代表的な３つの状態を表している。
第８図（Ａ）〜（Ｃ）のグラフでは，縦軸にメモリ量をとっており，横軸に時間をとっている。第８図（Ａ）〜（Ｃ）において，点線は設定されている最大ヒープサイズ２２０を示し，一点鎖線は新世代と旧世代のメモリの領域の境界２２１を示す。一点鎖線から下の領域が旧世代のメモリの領域となり，一点鎖線から点線（最大ヒープサイズ２２０）までの領域が新世代のメモリの領域となる。各世代における実線は，各世代別のメモリ使用量（２０１，２０２）の時間変化を示す。なお，第８図（Ａ）〜（Ｃ）のそれぞれの状態は，第６図（Ａ）〜（Ｃ）のそれぞれの状態に対応する。
Ｊａｖａ仮想マシン１は，メモリの割り当てイベントにより新世代のメモリ使用量２０２が新世代のメモリ量を超えるとき（第８図では最大ヒープサイズ２２０を超えるとき）に，ｎｅｗＧＣ２１１を実行し，新世代のメモリの解放を行う。また，Ｊａｖａ仮想マシン１は，ｎｅｗＧＣ２１１を何度か経験して新世代のメモリに残っているオブジェクトを旧世代のメモリに移し，旧世代のメモリがいっぱいで新世代のメモリからオブジェクトを移せなくなるときに，メモリ全体のガベージコレクション２１０を実行する。
ｎｅｗＧＣ２１１の発生頻度はメモリ全体のＧＣ２１０の発生頻度より高い。しかし，ＧＣ２１０の処理時間が数秒，場合によっては十数秒であるのに対し，ｎｅｗＧＣ２１１の処理時間は数十ミリ秒程度である。レスポンス時間が重要なアプリケーションでは，できるだけＧＣ２１０が発生しない状態（第８図（Ａ）の状態）を維持するようにする必要がある。
ＧＣ２１０が発生するのは，新世代から旧世代に移動するオブジェクトが多い場合であり，長寿命なオブジェクトが多いケースと，新世代のメモリサイズが小さくて溢れが発生するケース（世代が若くても旧世代に移動させる（溢れ）アルゴリズムを採用している場合など）とがある。ｎｅｗＧＣ２１１時に，新世代のメモリから旧世代のメモリに溢れるオブジェクトのサイズ（以下，溢れ量という）を測定することで，第８図（Ｂ）や第８図（Ｃ）の状態を第８図（Ａ）の状態にするのに必要なメモリ量を見積もることができる。
第９図は，溢れ量の測定を説明する図である。第９図（Ａ）は，ｎｅｗＧＣ２１１で新世代２４０のメモリから旧世代２３０のメモリにオブジェクトが溢れる状態を示しており，ハッチング部分が溢れ量である。ここで，ｎｅｗＧＣ２１１が起きた時刻に新世代２４０のメモリ量が十分にあった（ｎｅｗＧＣ２１１の発生するタイミングが伸びた）ものと仮定し，そのときの状態を第９図（Ｂ）のように表現するものとする。これをｎｅｗＧＣ２１１のたびに繰り返すと第９図（Ｃ）のような状態になる。
第９図（Ｃ）は，実際には４回のｎｅｗＧＣ２１１で溢れたオブジェクトが，新世代２４０のメモリ量が無限に存在し，溢れなかったものと仮定した状態を示している。ｋ回目の溢れ量をｔｋと表すとすると，第９図（Ｃ）の時点で溢れなかったと仮定された溢れ量の合計は，ｔ１＋ｔ２＋ｔ３＋ｔ４となる。もし，新世代２４０の領域に最初から元の量のメモリに加えてｔ１＋ｔ２＋ｔ３＋ｔ４の量のメモリが余計にあったなら，４回のｎｅｗＧＣ２１１までで新世代２４０のメモリから溢れるオブジェクトはない。
さらに，時間が経つにつれて不要となるオブジェクトがあるので，それを考慮して溢れ量を見積もると以下のようになる。例えば，第９図（Ｃ）において，１回目のｎｅｗＧＣ２１１で溢れたオブジェクトが溢れずに４回目のｎｅｗＧＣ２１１の時間まで新世代２４０の領域に残っているものとすると，その一部は不要なオブジェクトになっているはずである。同様に，２回目のｎｅｗＧＣ２１１時に溢れたオブジェクト，３回目のｎｅｗＧＣ２１１時に溢れたオブジェクトの中にも，４回目のｎｅｗＧＣ２１１の時間までに不要となるオブジェクトが存在する。第９図（Ｃ）において，４回目のｎｅｗＧＣ２１１までに溢れなかったものとされたオブジェクトの一部は，４回目のｎｅｗＧＣ２１１までに解放されてもよいはずである。実際には，第９図（Ｃ）は，第９図（Ｄ）のような状態であると考えられる。
第９図（Ｄ）において，１回のｎｅｗＧＣ２１１によるオブジェクトの生存率をｄ，ｋ回目の溢れ量をｘｋと表すとすると，
ｘ１＝ｔ１×ｄ３
ｘ２＝ｔ２×ｄ２
ｘ３＝ｔ３×ｄ１
ｘ４＝ｔ４×ｄ０
となり，溢れ量の累計は，ｘ１＋ｘ２＋ｘ３＋ｘ４となる。よって，新世代２４０のメモリ量がｘ１＋ｘ２＋ｘ３＋ｘ４だけ余分にあれば，溢れを起こさなかったこととなる。
一般的に，ｎ回のｎｅｗＧＣの溢れ量の累計は，以下の式（３）で求められる。式（３）において，ｘｔｏｔａｌは溢れ量の累計を示す。
ｘｔｏｔａｌ＝Σｋ＝１ ｎ（ｔｋ×ｄｎ−ｋ） ・・・式（３）
以下，メモリ使用量測定・分析手段１１による世代型ガベージコレクションの特徴に合わせたメモリ不足の危険性の判断ロジックを示す。世代型ガベージコレクションにおけるメモリ不足の危険性の判断は，前述の（判断１）〜（判断３）に，以下の（判断４）と（判断５）とを加えたものとなる。
なお，以下の世代型ガベージコレクションの判断において，メモリ使用率の計算には，式（１）の代わりに以下の式（４）を用いるものとする。
使用率＝旧世代メモリ使用量／旧世代容量 ・・・式（４）
（判断４）ガベージコレクション後のメモリ使用量を測定し，メモリの使用率がメモリ不足警告しきい値１０６を下回っていても（十分にメモリの空きが回復していても），ＧＣの発生間隔がＧＣ発生間隔警告しきい値１０３を下回っており，新世代のメモリ量の割合（新世代容量／全容量）がｎｅｗ世代不足警告しきい値１０８を下回っている場合には，新世代のメモリサイズが小さすぎることが性能に影響している（ＧＣの発生頻度を高くしている）と判断する。
（判断５）式（３）により溢れ量の累計を毎ｎｅｗＧＣ後に計算し，（溢れ量の累計／旧世代空き容量）が溢れ量警告しきい値１０９を超える場合には，ＯｕｔＯｆＭｅｍｏｒｙの危険性があると判断する。
メモリ使用量測定・分析手段１１は，（判断１）〜（判断３）に示した基本的な判断結果と（判断４），（判断５）に示した世代型ガベージコレクションの特徴に合わせた危険性の判断結果とをもとに，ＯｕｔＯｆＭｅｍｏｒｙの危険性の警告，メモリ不足による性能低下の危険性の警告などを行う。
また，メモリ使用量測定・分析手段１１は，状態の回復に必要なメモリ量の計算を行う。例えば，（判断１）〜（判断３）における回復に必要なメモリサイズは，ガベージコレクション後のメモリの空き率（空き率＝１−使用率）がメモリ空き回復しきい値１０７を超えるように計算されたサイズとする。計算は，以下の式（５）を満たすｍ（回復のために追加する容量）を求める計算となる。
（旧世代空き容量＋ｍ）／（旧世代容量＋ｍ）
＞メモリ空き回復しきい値１０７ ・・・式（５）
また，例えば，（判断５）の場合において，回復に必要な追加メモリ量は，あるＧＣとその次のＧＣとの間に発生したｎｅｗＧＣに対して，式（３）により求められた溢れ量の累計とする。
第８図に示すような世代型ガベージコレクションにおける新世代のメモリの領域と旧世代のメモリの領域との割合を，Ｊａｖａ仮想マシン１を起動するときのオプションで設定できるものがある。また，第８図に示すような世代型ガベージコレクションでは新世代のメモリサイズと旧世代のメモリサイズとを一定にしているが，新世代のメモリサイズと旧世代のメモリサイズとをダイナミックに変更する世代型ガベージコレクションもある。
第１０図は，ダイナミックにサイズを変更する世代型ガベージコレクションにおけるガベージコレクションの発生間隔とメモリ使用量に関する状態を説明する図である。第１０図に示すダイナミックにサイズを変更する世代型ガベージコレクションでは，ガベージコレクション２１０直後のメモリの空き容量を，あらかじめ設定された割合で，新世代のメモリの領域と旧世代のメモリの領域とに分配する。
第１０図（Ａ）〜（Ｃ）は，旧世代，新世代別に，メモリ使用量（旧世代２０１，新世代２０２）の変化とガベージコレクション２１０，ｎｅｗＧＣ２１１の発生とをグラフ化して表した例であり，ガベージコレクション２１０，ｎｅｗＧＣ２１１の発生間隔とメモリ使用量とに関する代表的な３つの状態を表している。
第１０図（Ａ）〜（Ｃ）のグラフでは，縦軸にメモリ量をとっており，横軸に時間をとっている。第１０図（Ａ）〜（Ｃ）において，点線は設定されている最大ヒープサイズ２２０を示し，一点鎖線は新世代と旧世代のメモリの領域の境界２２１を示す。一点鎖線から下の領域が旧世代のメモリの領域となり，一点鎖線から点線（最大ヒープサイズ２２０）までの領域が新世代のメモリの領域となる。各世代における実線は，各世代別のメモリ使用量（２０１，２０２）の時間変化を示す。なお，第１０図（Ａ）〜（Ｃ）のそれぞれの状態は，第６図（Ａ）〜（Ｃ）のそれぞれの状態に対応する。
Ｊａｖａ仮想マシン１は，メモリの割り当てイベントにより新世代のメモリ使用量２０２が新世代のメモリ量を超えるとき（第１０図では最大ヒープサイズ２２０を超えるとき）に，ｎｅｗＧＣ２１１を実行し，新世代のメモリの解放を行う。また，Ｊａｖａ仮想マシン１は，ｎｅｗＧＣ２１１を何度か経験して新世代のメモリに残っているオブジェクトを旧世代のメモリに移す。オブジェクトを新世代のメモリから旧世代のメモリに移した分だけ新世代のメモリが少なくなり，旧世代のメモリが増える。
Ｊａｖａ仮想マシン１は，旧世代のメモリがいっぱいになったときに，メモリ全体のガベージコレクション２１０を実行する。このとき，あらかじめ設定された割合で，ガベージコレクション２１０直後のメモリの空き容量を，新世代のメモリの領域と旧世代のメモリの領域とに分配する。
メモリ使用量測定・分析手段１１によるダイナミックにサイズを変更する世代型ガベージコレクションにおけるメモリ不足の危険性の判断は，前述の（判断１）〜（判断３），（判断５）となる。また，ダイナミックにサイズを変更する世代型ガベージコレクションにおいて，使用率の計算には式（１）を用いる。
メモリ使用量測定・分析手段１１は，（判断１）〜（判断３），（判断５）に示す危険性の判断結果をもとに，ＯｕｔＯｆＭｅｍｏｒｙの危険性の警告，メモリ不足による性能低下の警告などを行う。
また，メモリ使用量測定・分析手段１１は，状態の回復に必要なメモリ量の計算を行う。ダイナミックにサイズを変更する世代型ガベージコレクションにおいて，回復に必要なメモリ量の計算は，先に示した式（２）を改良する。例えば，（判断１）〜（判断３）の場合における回復に必要なメモリサイズは，ガベージコレクション後の全容量に対する旧世代空き容量の割合がメモリ空き回復しきい値１０７を超えるように計算されたサイズとする。計算は，以下の式（６）を満たすｍ（回復のために追加する容量）を求める計算となる。
（旧世代空き容量＋旧世代分配率×ｍ）／（全容量＋ｍ）
＞メモリ空き回復しきい値１０７ ・・・式（６）
また，（判断５）の場合における回復に必要な追加メモリ量は，前述の世代型ガベージコレクションの場合と同じである。
メモリ使用量測定・分析手段１１における処理の例について，第１１図から第１５図のフローチャートを用いて説明する。
第１１図から第１５図のフローチャートにおいて，“非ダイナミック世代型ＧＣ”は，新世代，旧世代のメモリサイズをダイナミックには変更しない世代型ガベージコレクションを示すものとする。また，“ダイナミック世代型ＧＣ”は，ダイナミックにサイズを変更する世代型ガベージコレクションを示すものとする。また，“ＧＣ”はメモリ全体のガベージコレクションを示し，“ｎｅｗＧＣ”は世代型ＧＣにおける新世代のガベージコレクションを示す。
第１１図は，メモリ使用量測定・分析処理フローチャートである。
まず，メモリ使用量測定フラグ１０１がＯＮであるか否かを判定し（ステップＳ１），ＯＮでなければ（ＯＦＦであれば）処理を終了する。
ステップＳ１においてＯＮであれば，ＧＣが発生したか否かを判定し（ステップＳ２），ＧＣが発生していなければステップＳ６に進む。
ステップＳ２においてＧＣが発生していれば，第１２図に示すデータ測定・計算処理を行い（ステップＳ３），第１３図に示すデータ分析・警告処理Ａを行い（ステップＳ４），次いで第１４図に示すデータ分析・警告処理Ｂを行い（ステップＳ５），ステップＳ６に進む。
世代型ＧＣであるか否かを判定し（ステップＳ６），世代型ＧＣでなければ処理を終了する。
ステップＳ６において世代型ＧＣであれば，第１５図に示す世代型ＧＣ固有測定・分析処理を行い（ステップＳ７），処理を終了する。
第１２図は，データ測定・計算処理フローチャートである。
まず，今回のＧＣ発生時刻を測定し（ステップＳ１０），今回のＧＣ発生間隔（今回のＧＣ発生時刻−前回のＧＣ発生時刻）を計算する（ステップＳ１１）。次に，ＧＣ直後のメモリ使用量と空き容量とを測定し（ステップＳ１２），ＧＣ直後のメモリの使用率と空き率（空き率＝１−使用率）とを計算し（ステップＳ１３），処理を終了する。
ここで，ステップＳ１２において，世代型ＧＣの場合には，メモリ全体だけではなく，旧世代のメモリについても測定を行う。また，ステップＳ１３のメモリの使用率の計算において，世代型ＧＣでない場合とダイナミック世代型ＧＣである場合には式（１）を用いて計算を行い，非ダイナミック世代型ＧＣである場合には式（４）を用いて計算を行う。
第１３図は，データ分析・警告処理Ａフローチャートである。
まず“今回の使用率≧ｔｈ２（ＯｕｔＯｆＭｅｍｏｒｙ警告しきい値Ａ１０４）”が成立するか否かを判定し（ステップＳ２０），成立すればステップＳ２６に進む。
ステップＳ２０において成立しなければ，“今回の使用率＞前回の使用率”が成立するか否かを判定し（ステップＳ２１），成立しなければ，メモリの使用率の増加が何回連続したかを数えるためのカウンタｃ１を０とし（ステップＳ２３），処理を終了する。
ステップＳ２１において成立すれば，“今回の使用率＞ｔｈ３（ＯｕｔＯｆＭｅｍｏｒｙ警告しきい値Ｂ１０５）”が成立するか否かを判定し（ステップＳ２２），成立しなければ，メモリの使用率の増加が何回連続したかを数えるためのカウンタｃ１を０とし（ステップＳ２３），処理を終了する。
ステップＳ２２において成立すれば，カウンタｃ１を１インクリメント（ｃ１＝ｃ１＋１）する（ステップＳ２４）。
カウンタｃ１があらかじめ任意に設定された値ｎ１以上であるか否かを判定し（ステップＳ２５），値ｎ１以上であればステップＳ２６に進む。ステップＳ２５において値ｎ１以上でなければ，処理を終了する。
ステップＳ２６では，ＯｕｔＯｆＭｅｍｏｒｙの危険性の警告（警告ｗ１）を行い，回復に必要なメモリ量を計算し（ステップＳ２７），処理を終了する。
このステップＳ２７における回復に必要なメモリ量の計算において，世代型ＧＣでない場合には前記式（２）を満たすｍ（回復のために追加する容量）を求める計算を行い，非ダイナミック世代型ＧＣである場合には前記式（５）を満たすｍ（回復のために追加する容量）を求める計算を行い，ダイナミック世代型ＧＣである場合には前記式（６）を満たすｍ（回復のために追加する容量）を求める計算を行う。
第１４図は，データ分析・警告処理Ｂフローチャートである。
まず“今回のＧＣ発生間隔＜ｔｈ１（ＧＣ発生間隔警告しきい値１０３）”が成立するか否かを判定し（ステップＳ３０），成立しなければ，ＧＣ発生間隔が何回連続でＧＣ発生間隔警告しきい値１０３を下回ったかを数えるカウンタｃ２を０とし（ステップＳ３１），処理を終了する。
ステップＳ３０において成立すれば，カウンタｃ２を１インクリメント（ｃ２＝ｃ２＋１）する（ステップＳ３２）。
カウンタｃ２があらかじめ任意に設定された値ｎ２以上であるか否かを判定し（ステップＳ３３），値ｎ２以上でなければ処理を終了する。
ステップＳ３３において，ｃ２が値ｎ２以上であれば，“今回の使用率≧ｔｈ４（メモリ不足警告しきい値１０６）”が成立するか否かを判定し（ステップＳ３４），成立すれば，メモリ不足による性能低下の警告（警告ｗ２）を行い（ステップＳ３５），回復に必要なメモリ量を計算し（ステップＳ３６），処理を終了する。
このステップＳ３６における回復に必要なメモリ量の計算において，世代型ＧＣでない場合には前記式（２）を満たすｍ（回復のために追加する容量）を求める計算を行い，非ダイナミック世代型ＧＣである場合には前記式（５）を満たすｍ（回復のために追加する容量）を求める計算を行い，ダイナミック世代型ＧＣである場合には前記式（６）を満たすｍ（回復のために追加する容量）を求める計算を行う。
ステップＳ３４において成立しなければ，“空き率≧ｔｈ５（メモリ空き回復しきい値１０７）”であるか否かを判定し（ステップＳ３７），成立しなければ，ＧＣが短い間隔で発生しているとの警告（警告ｗ３）を行い（ステップＳ３８），処理を終了する。
ステップＳ３７において成立すれば，非ダイナミック世代型ＧＣであるか否かを判定し（ステップＳ３９），非ダイナミック世代型ＧＣでなければ，メモリの消費スピードに比べてメモリの絶対量が小さいなどの警告（警告ｗ４）を行い（ステップＳ４０），処理を終了する。
ステップＳ３９において非ダイナミック世代型ＧＣであれば，“新世代容量／全容量＜ｔｈ６（ｎｅｗ世代不足警告しきい値１０８）”が成立するか否かを判定し（ステップＳ４１），成立すれば新世代の割合が小さいとの警告（警告ｗ５）を行い（ステップＳ４２），処理を終了する。
ステップＳ４１において成立しなければ，メモリの消費スピードに比べてメモリの絶対量が小さい，Ｓｕｒｖｉｖｏｒ容量の割合が小さいなどの警告（警告ｗ６）を行い（ステップＳ４３），処理を終了する。
第１５図は，世代型ＧＣ固有測定・分析処理フローチャートである。
まず，ｎｅｗＧＣが発生したか否かを判定し（ステップＳ５０），発生していなければ処理を終了する。
ステップＳ５０においてｎｅｗＧＣが発生していれば，ＧＣ後の最初のｎｅｗＧＣか否かを判定し（ステップＳ５１），最初のｎｅｗＧＣでなければステップＳ５３に進む。ステップＳ５１において最初のｎｅｗＧＣであれば，値ｎを１とし（ステップＳ５２），ステップＳ５３に進む。
ｎｅｗＧＣで新世代から旧世代に溢れたオブジェクトの量を測定し（ステップＳ５３），式（３）を用いて溢れ量の累計を計算する（ステップＳ５４）。
次に，“溢れ量の累計／旧世代空き容量＞ｔｈ７（溢れ量警告しきい値１０９）”が成立するか否かを判定し（ステップＳ５５），成立しなければステップＳ５８に進む。
ステップＳ５５において成立すれば，ＯｕｔＯｆＭｅｍｏｒｙの危険性の警告（警告ｗ１）を行い（ステップＳ５６），ステップＳ５４で計算された溢れ量の累計を回復のために追加するメモリ量とし（ステップＳ５７），ステップＳ５８に進む。
値ｎを１インクリメント（ｎ＝ｎ＋１）し（ステップＳ５８），処理を終了する。
第１６図は，メモリ使用量測定・分析手段の警告対象となる状態の例（１）を示す図である。第１６図（Ａ），（Ｂ）は，それぞれが第１３図の各判断条件に対応している。また，第１６図（Ａ），（Ｂ）のグラフでは，縦軸にメモリ量をとっており，横軸に時間をとっている。
第１６図（Ａ）において，太線１０４’は（全容量×ＯｕｔＯｆＭｅｍｏｒｙ警告しきい値Ａ１０４）で求められた値である。また，第１６図（Ｂ）において，太線１０５’は（全容量×ＯｕｔＯｆＭｅｍｏｒｙ警告しきい値Ｂ１０５）で求められた値である。また，第１６図（Ａ），（Ｂ）において，太線１０７’は（全容量×（１−メモリ空き回復しきい値１０７））で求められた値である。
第１６図（Ａ）は，第１３図のステップＳ２０が成立する場合の例である。第１６図（Ａ）において，メモリ使用量２００の変化を見ると，ＧＣ２１０によってメモリの空きがほとんど回復していない。ＧＣ２１０後のメモリ使用量２００が太線１０４’を上回っていることから，メモリの使用率がＯｕｔＯｆＭｅｍｏｒｙ警告しきい値Ａ１０４を上回っていることがわかる。ＯｕｔＯｆＭｅｍｏｒｙ警告しきい値Ａ１０４は，例えば，９０％〜９５％程度である。
第１６図（Ｂ）は，第１３図のステップＳ２１，ステップＳ２２，ステップＳ２５が同時に成立する場合の例である。第１６図（Ｂ）において，メモリ使用量２００の変化を見ると，ＧＣ２１０α，ＧＣ２１０β，ＧＣ２１０γと順に徐々にメモリの空きが回復しなくなってきていることがわかる。また，ＧＣ２１０β後，ＧＣ２１０γ後のメモリ使用量２００が連続して太線１０５’を上回っていることから，ＧＣ２１０β後，ＧＣ２１０γ後のそれぞれのメモリの使用率がＯｕｔＯｆＭｅｍｏｒｙ警告しきい値Ｂ１０５を上回っていることがわかる。
第１７図は，メモリ使用量測定・分析手段の警告対象となる状態の例（２）を示す図である。第１７図（Ａ）〜（Ｃ）は，それぞれが第１４図の各判断条件に対応している。また，第１７図（Ａ）〜（Ｃ）のグラフでは，縦軸にメモリ量をとっており，横軸に時間をとっている。
第１７図（Ａ）において，太線１０６’は（全容量×メモリ不足警告しきい値１０６）で求められた値である。また，第１７図（Ｃ）において，太線１０８’は（全容量×（１−ｎｅｗ世代不足警告しきい値１０８））で求められた値である。また，第１７図（Ａ）〜（Ｃ）において，太線１０７’は（全容量×（１−メモリ空き回復しきい値１０７））で求められた値である。
第１７図（Ａ）は，第１４図のステップＳ３４が成立する場合の例である。第１７図（Ａ）において，メモリ使用量２００の変化を見ると，ＧＣ２１０によってメモリの空きはある程度回復するが，ＧＣ発生間隔が短くなっている。ＧＣ２１０後のメモリ使用量２００が太線１０６’を上回っていることから，メモリの使用率がメモリ不足警告しきい値１０６を上回っていることがわかる。メモリ不足警告しきい値１０６は，例えば，８０％〜９０％程度である。
第１７図（Ｂ）は，第１４図のステップＳ３７が成立する場合の例であり，世代型ＧＣでない場合の例である。第１７図（Ｂ）において，メモリ使用量２００の変化を見ると，ＧＣ２１０によってメモリの空きは回復している。また，ＧＣ２１０後のメモリ使用量２００が太線１０７’を下回っていることから，メモリの空き率がメモリ空き回復しきい値１０７を上回っていることがわかる。
しかし，ＧＣ発生間隔が短くなっている。これは，メモリの絶対量（最大ヒープサイズ２２０）が小さいなどの理由による。メモリ空き回復しきい値１０７は，例えば，５０％〜６０％程度である。
第１７図（Ｃ）は，第１４図のステップＳ４１が成立する場合の例であり，非ダイナミック世代型ＧＣの場合の例である。第１７図（Ｃ）において，旧世代のメモリ使用量２０１の変化を見ると，ＧＣ２１０によってメモリの空きは回復している。また，ＧＣ２１０後の旧世代のメモリ使用量２０１が太線１０７’を下回っていることから，メモリの空き率がメモリ空き回復しきい値１０７を上回っている。
しかし，ＧＣ発生間隔が短くなっている。また，旧世代のメモリと新世代のメモリの境界２２１が太線１０８’を上回っていることから，メモリの全容量に対する新世代容量の割合がｎｅｗ世代不足警告しきい値１０８を下回っていることがわかる。これは，新世代容量が小さいからである。ｎｅｗ世代不足警告しきい値１０８は，例えば，５％〜１０％程度である。
次に，Ｊａｖａアプリケーションのスレッドがデッドロックを起こしてるか否かを測定・分析し，警告するスレッド測定・分析手段１２について説明する。
Ｊａｖａのスレッドの状態としては，実行中，実行可能状態で待機中，サスペンド中，スリープ中，ロックの解放待ちで待機中などの状態がある。
前述の第４の従来技術で示したように，スレッドの状態遷移は，Ｊａｖａ仮想マシン・プロファイラインタフェースのイベントによって測定することができる。実際に，これらのイベントを分析してスレッドの状態を調べることで，デッドロックしたスレッドを検出する製品がある。
しかし，スレッドの状態遷移は非常に頻繁に起こるものであり，これらのイベントをすべて測定しているとアプリケーションの運用に大きな負荷がかかることとなる。よって，Ｊａｖａ仮想マシン・プロファイラインタフェースのイベントによってスレッドの状態遷移を測定して分析するデッドロックの検出は，開発時に行われるべきものである。
これに対し本システムでは，スレッド測定・分析手段１２が，アプリケーションの運用に負荷がかからない程度の間隔で定期的にスレッドの状態を測定する。また，ロックの解放待ちで待機中のスレッドを記録し，次の測定のときに同じスレッドが再びロックの解放待ちで待機しているか否かを確認する。連続して待機している場合には，その連続回数をカウントする。ロックの解放待ちでの待機状態の連続回数がデッドロック警告しきい値１１０を超えたスレッドが２個以上ある場合には，デッドロックの危険性があると判断する。
これにより，アプリケーションの運用時に，その運用に負荷をかけずにデッドロックの危険性を検出することができる。
第１８図は，スレッド測定・分析処理フローチャートである。
まず，スレッド測定フラグ１０２がＯＮであるか否かを判定し（ステップＳ６０），ＯＮでなければ（ＯＦＦであれば）ステップＳ６８に進む。
ステップＳ６０においてＯＮであれば，すべてのスレッドの状態を測定し（ステップＳ６１），現在ロックの解放待ちで待機中のスレッドを抽出して記録する（ステップＳ６２）。また，すでに記録されていたスレッドのうち，今回抽出されなかったスレッドの記録を削除する（ステップＳ６３）。
今回初めて抽出されたスレッドの待機状態が連続する回数のカウンタ（これを連続カウンタという）を１とし（ステップＳ６４），前回も抽出されたスレッドの連続カウンタを１インクリメントする（ステップＳ６５）。
次に，“連続カウンタ≧ｔｈ８（デッドロック警告しきい値１１０）”を満たすスレッドが２つ以上存在するか否かを判定し（ステップＳ６６），存在しなければステップＳ６８に進む。
ステップＳ６６において存在すれば，デッドロックの危険性があるとの警告（警告ｗ７）を行い（ステップＳ６７），ステップＳ６８に進む。
Ｊａｖａ仮想マシン１の起動時にオプションで，または，アプリケーションサーバ２のＪａｖａ仮想マシン制御手段２０（後述）からコマンドで指定された測定間隔だけ，スレッド状態の測定をスリープし（ステップＳ６８），ステップＳ６０に戻る。
以上のように，本システムでは，スレッドの状態遷移をすべて測定する方法ではなく，定期的な測定により判断を行うアルゴリズムを採用しているため，アプリケーションの運用環境に負荷をかけずに，スレッドのデッドロックの危険性を警告することができる。
次に，Ｊａｖａ仮想マシン１が分析結果を上位層（アプリケーションサーバ２）に通知し，最適な運用環境になるようにフィードバックする技術手段について説明する。
第１９図は，Ｊａｖａ仮想マシンとアプリケーションサーバとの連携によるＪａｖａ仮想マシンへの処理の振り分けを示す図である。第１９図のシステムでは，ＯＳ４の上層に４つのＪａｖａ仮想マシン１ａ〜１ｄがあり，それぞれが測定・分析手段１０ａ〜１０ｄを有している。Ｊａｖａ仮想マシン１ａ〜１ｄの上位層にはアプリケーションサーバ２がある。
各Ｊａｖａ仮想マシン１ａ〜１ｄの起動は，上位層のアプリケーションサーバ２が行っており，各Ｊａｖａ仮想マシン１ａ〜１ｄとアプリケーションサーバ２との間には密接な関係がある。アプリケーションサーバ２は，複数のＪａｖａ仮想マシン１ａ〜１ｄを起動し，各Ｊａｖａ仮想マシン１ａ〜１ｄにクライアントからの要求を振り分け，アプリケーションを処理する。
各Ｊａｖａ仮想マシン１ａ〜１ｄ内の測定・分析手段１０ａ〜１０ｄで行った分析の分析結果は，直接にアプリケーションサーバ２に通知される。アプリケーションサーバ２は，受け取った分析結果の通知をアプリケーションの運用環境にフィードバックし，クライアントからの要求をより適切にＪａｖａ仮想マシン１ａ〜１ｄに振り分ける。
例えば，Ｊａｖａ仮想マシン１ａがアプリケーションサーバ２にメモリ不足でＯｕｔＯｆＭｅｍｏｒｙのエラーになる危険性が高いという通知を送るものとする。アプリケーションサーバ２は，このＪａｖａ仮想マシン１ａへの処理の振り分けを中止し，Ｊａｖａ仮想マシン１ａが現在の手持ちの処理を終わらせたところで，新しいＪａｖａ仮想マシン１ｂ〜１ｄに処理を振り分けることができる。
まず，Ｊａｖａ仮想マシン１とアプリケーションサーバ２とが連携することについて説明する。
第２０図は，Ｊａｖａ仮想マシンとアプリケーションサーバとの連携を示す図である。アプリケーションサーバ２内のＪａｖａ仮想マシン制御手段２０は，Ｊａｖａ仮想マシン１の起動・停止を行い，Ｊａｖａ仮想マシン１にアプリケーションの処理を振り分ける手段である。このＪａｖａ仮想マシン制御手段２０とＪａｖａ仮想マシン１とは，Ｊａｖａ仮想マシン連携手段３により互いに連携している。
Ｊａｖａ仮想マシン連携手段３は，分析結果通知手段３１を備える。この分析結果通知手段３１は，プロセス間通信で直接に分析結果を通知する機能と，ファイルなどの媒体を経由して分析結果を通知する機能とを持つ。
Ｊａｖａ仮想マシン１内の測定・分析手段１０は，分析結果通知手段３１を用いて，Ｊａｖａ仮想マシン制御手段２０に分析結果を送る。
Ｊａｖａ仮想マシン制御手段２０は，分析結果通知手段３１により送られてきた分析結果をもとに，Ｊａｖａ仮想マシン１の起動・停止の制御と，Ｊａｖａ仮想マシンへのアプケーションの処理の振り分けとを行う。ここで，Ｊａｖａ仮想マシン制御手段２０内で，Ｊａｖａ仮想マシン１からの情報をもとに，Ｊａｖａ仮想マシン１の起動・停止やＪａｖａ仮想マシン１へのアプリケーションの振り分けを最適に行う手段は，Ｊａｖａ仮想マシン最適制御手段２１である。
また，Ｊａｖａ仮想マシン連携手段３は，コマンド通知手段３２を備える。このコマンド通知手段３２は，プロセス間通信で直接にコマンドを通知する。
Ｊａｖａ仮想マシン制御手段２０は，コマンド通知手段３２を用いて，測定の種類ごとに測定・分析の開始／中断を指示するコマンド，分析結果の判定に使用するしきい値の設定・変更を指示するコマンド，強制ガベージコレクションを指示するコマンドなどを送付する。例えば，警告が長期間に渡って通知されない場合などには，Ｊａｖａ仮想マシン制御手段２０は，コマンド通知手段３２を用いて，Ｊａｖａ仮想マシン１にメモリ使用量などの測定の中断を指示するコマンドを送付することができる。
第２１図は，分析結果通知処理フローチャートである。ここでは，分析結果通知処理を，Ｊａｖａ仮想マシン１の測定・分析手段１０側の処理と，アプリケーションサーバ２のＪａｖａ仮想マシン制御手段２０側の処理とにわけて説明する。
第２１図（Ａ）は，測定・分析手段１０側の分析結果通知処理フローチャートである。測定・分析手段１０は，警告があるか否かを判定し（ステップＳ７０），警告があれば，分析結果通知手段３１を用いてＪａｖａ仮想マシン制御手段２０に警告を通知する（ステップＳ７１）。このとき回復に必要なメモリ量の情報もあれば，同時に通知する。また，警告は，プロセス間通信で送付してもよいし，ログファイルに出力してもよい。
第２１図（Ｂ）は，Ｊａｖａ仮想マシン制御手段２０側の分析結果通知処理フローチャートである。Ｊａｖａ仮想マシン制御手段２０は，警告を受信したか否かを判定し（ステップＳ８０），警告を受信していれば，その警告をＪａｖａ仮想マシン最適制御手段２１に渡す（ステップＳ８１）。このとき回復に必要なメモリ量の情報も受信していれば，同時に渡す。
第２２図は，コマンド通知処理フローチャートである。ここでは，コマンド通知処理を，アプリケーションサーバ２のＪａｖａ仮想マシン制御手段２０側の処理と，Ｊａｖａ仮想マシン１の測定・分析手段１０側の処理とにわけて説明する。
第２２図（Ａ）は，Ｊａｖａ仮想マシン制御手段２０側のコマンド通知処理フローチャートである。Ｊａｖａ仮想マシン制御手段２０は，測定・分析手段１０への動作環境変更のコマンドがあるか否かを判定し（ステップＳ９０），コマンドがあれば，コマンド通知手段３２を用いて測定・分析手段１０に設定変更のためのコマンドを送付する（ステップＳ９１）。また，コマンドはプロセス間通信で送付する。
ここで，動作環境変更のコマンドの例としては，例えば，以下のようなものがある。
（１）メモリ使用量の測定開始コマンド
（２）メモリ使用量の測定中断コマンド
（３）スレッドの測定開始コマンド
（４）スレッドの測定終了コマンド
（５）しきい値の設定／変更コマンド
（６）強制ガベージコレクションコマンド
第２２図（Ｂ）は，測定・分析手段１０側のコマンド通知処理フローチャートである。測定・分析手段１０は，コマンドを受信したか否かを判定し（ステップＳ１００），コマンドを受信していれば，そのコマンドを実行する（ステップＳ１０１）。
ここで，コマンド実行の例としては，例えば，以下のようなものがある。
（１）メモリ使用量の測定開始／中断コマンドであれば，メモリ使用量測定フラグ１０１をＯＮ／ＯＦＦする。
（２）スレッドの測定開始／終了コマンドであれば，スレッド測定フラグ１０２をＯＮ／ＯＦＦする。
（３）しきい値の設定／変更コマンドであれば，該当するしきい値（１０３〜１１０）を設定／変更する。
（４）強制ガベージコレクションコマンドであれば，Ｊａｖａ仮想マシン１のガベージコレクション処理を呼ぶ。
次に，分析結果をアプリケーションの運用環境にフィードバックすることについて説明する。
Ｊａｖａ仮想マシン１内の測定・分析手段１０での分析結果として，ＯｕｔＯｆＭｅｍｏｒｙの危険性の警告，メモリ不足による性能低下の警告，回復に必要なメモリサイズなどの通知をＪａｖａ仮想マシン制御手段２０に送付する。ここで，Ｊａｖａ仮想マシン１とＪａｖａ仮想マシン制御手段２０とが，プロセス間通信により直接に結合されているものとすると，通知は直ちにアプリケーションサーバ２に届くこととなる。Ｊａｖａ仮想マシン制御手段２０は，通知が届いているか否かを定期的に確認し，通知を受け付けたら直ちにその通知をＪａｖａ仮想マシン最適制御手段２１に渡し，アプリケーションの運用環境にフィードバックする。
例えば，Ｊａｖａ仮想マシン１からＯｕｔＯｆＭｅｍｏｒｙの危険性の警告の通知を受けた場合，Ｊａｖａ仮想マシン最適制御手段２１は，そのＪａｖａ仮想マシン１へのアプリケーション処理の振り分けを止める。そのＪａｖａ仮想マシン１が現在処理中のアプリケーションを終了したら，代替のＪａｖａ仮想マシン１’を立ち上げる。代替のＪａｖａ仮想マシン１’を立ち上げるときには，Ｊａｖａ仮想マシン１から通知された回復に必要なメモリサイズをもとに，代替のＪａｖａ仮想マシン１’の起動時のオプションで最適なメモリサイズを指定する。
また，Ｊａｖａ仮想マシン１からメモリ不足による性能低下の警告の通知を受けた場合，Ｊａｖａ仮想マシン最適制御手段２１は，次回にＪａｖａ仮想マシン１を立ち上げるときに，通知された回復に必要なメモリサイズをもとに，Ｊａｖａ仮想マシン１起動時のオプションで最適なメモリサイズを指定する。メモリ不足による性能低下の警告を出したＪａｖａ仮想マシン１へのアプリケーション処理の振り分けを減らすというフィードバックの方法もある。
スレッドのデッドロックの危険性の警告の通知は，Ｊａｖａ仮想マシン１の起動やアプリケーション処理の振り分け制御にはフィードバックしない。この情報は，アプリケーションサーバ２のログ情報としてファイルに残し，後のアプリケーションの見直しに利用する。
第２３図は，Ｊａｖａ仮想マシン最適制御処理フローチャートである。
まず，警告，回復に必要なメモリサイズを受け取り（ステップＳ１１０），警告の種類を判定する（ステップＳ１１１）。
ステップＳ１１１においてＯｕｔＯｆＭｅｍｏｒｙの危険性の警告（警告ｗ１）であれば，アプリケーションの終了を待って警告の出たＪａｖａ仮想マシン１を終了させる（ステップＳ１１２）。代替のＪａｖａ仮想マシン１’を起動し（ステップＳ１１３），処理を終了する。代替のＪａｖａ仮想マシン１’の起動時には，受け取った回復に必要なメモリサイズをもとに，オプションで最適なメモリサイズを指定する。
ステップＳ１１１においてメモリ不足による性能低下の警告（警告ｗ２）であれば，受け取った回復に必要なメモリサイズを保存し（ステップＳ１１４），処理を終了する。次回のＪａｖａ仮想マシン１の起動時には，保存した回復に必要なメモリサイズをもとに，オプションで最適なメモリサイズを指定する。
ステップＳ１１１においてデッドロックの危険性の警告（警告ｗ７）であれば，デッドロックの危険性の警告をログに記録する（ステップＳ１１５）。その旨を運用管理者に通知し（ステップＳ１１６），処理を終了する。
本システムの効果は，以下のとおりである。本システムでは，メモリの割り当てと解放のすべてを測定する方法ではなく，ガベージコレクションのイベント発生時の測定と，必要に応じてメモリ使用量の定期的な測定とによって判断を行うアルゴリズムを採用しているため，アプリケーションの運用環境に負荷をかけずに，ＯｕｔＯｆＭｅｍｏｒｙの危険性やメモリ不足による性能低下の警告をすることができる。
また，測定したデータを採取して外部プロセスでデータの分析を行う方法では，データの測定から回復に向けたフィードバックまでに時間がかかり，タイムリー性を損なう可能性がある。本システムでは，アプリケーションを動かしているＪａｖａ仮想マシン内にデータを測定・分析する手段があるため，よりタイムリーなフィードバックを行うことができる。
また，本システムでは，各Ｊａｖａ仮想マシンが採用している様々なガベージコレクションに応じて危険性を判断するための改良アルゴリズムを多段的に持っているため，より正確な危険性の判断ができる。
また，単なるＯｕｔＯｆＭｅｍｏｒｙの危険性やメモリ不足による性能低下の警告だけでは，再度同じような状態になる危険性があるが，本システムでは，Ｊａｖａ仮想マシンの最適な運用に必要なメモリ量を合わせて通知するため，回復に向けたより適切なフィードバックを行うことができる。
また，本システムでは，Ｊａｖａ仮想マシンのデータを測定・分析し，危険性を通知する手段と上位層（アプリケーションサーバ）のＪａｖａ仮想マシンを制御する手段とがプロセス間通信により直接つながっており，警告の通知とフィードバックを人が介することなく自動的に行えるため，問題があってから回復を行うまでのタイミングが遅れる危険性が低くなる。
本発明は，エンタープライズアプリケーションを構成するクライアント層，中間層，データベース層の３階層システムにおいて，サーバ側に配置される中間層の実行環境の状態をアプリケーションの運用時に監視し，実行環境が危険な状態になることを回避することで，アプリケーションを安定に運用させるために利用することができる。サーバ側に配置される中間層の実行環境としては，例えば，ガベージコレクションによるメモリ管理機能を持つＪａｖａ仮想マシンなどの実行系がある。
本発明では，Ｊａｖａ仮想マシンなどのデータを測定・分析し，危険性を通知する手段と上位層（アプリケーションサーバ）のＪａｖａ仮想マシンを制御する手段とを連携させ，警告の通知とフィードバックを人手を介することなく自動的に行うことができるため，実行環境におけるメモリ不足の危険性の回避を効率よく行うことができる。
本発明では，Ｊａｖａ仮想マシンなどのデータを測定・分析し，危険性を通知する手段と上位層（アプリケーションサーバ）のＪａｖａ仮想マシンを制御する手段とを連携させ，警告の通知とフィードバックを人手を介することなく自動的に行うことができるため，実行環境におけるメモリ不足の危険性の回避を効率よく行うことができる。
Claims (6)
- 割り当てたメモリの解放をガベージコレクションによって行うプログラム実行環境を有するコンピュータシステムにおける実行環境の危険予測／回避方法であって，
ガベージコレクションのイベント発生時に，ガベージコレクション直後のメモリ使用量を測定する過程と，
前記測定されたメモリ使用量からメモリ不足の危険性を予測する過程と，
メモリの空き容量をＡ，メモリの全容量をＢ，メモリ空き回復しきい値をＴとしたときに，前記予測されたメモリ不足の危険性を回避するために必要なメモリ量ｍを，「（Ａ＋ｍ）／（Ｂ＋ｍ）＞Ｔ」の式を満たすｍを求めることにより算出する過程と，
前記予測されたメモリ不足の危険性に対する警告とそれを回避するために必要なメモリ量を他のアプリケーションに通知する過程とを有する
ことを特徴とする実行環境の危険予測／回避方法。 - 前記メモリ不足の危険性の予測およびそれを回避するために必要なメモリ量の算出を，システムが使用するガベージコレクションの種類ごとに対応するアルゴリズム用いて行う
ことを特徴とする請求の範囲第１項記載の実行環境の危険予測／回避方法。 - 割り当てたメモリの解放をガベージコレクションによって行うプログラム実行環境を有するコンピュータシステムにおける実行環境の危険予測／回避方法であって，
ガベージコレクションのイベント発生時に，ガベージコレクション直後のメモリ使用量を測定する過程と，
前記測定されたメモリ使用量からメモリ不足の危険性を予測する過程と，
前記予測されたメモリ不足の危険性を回避するために必要なメモリ量を算出する過程と，
前記予測されたメモリ不足の危険性に対する警告とそれを回避するために必要なメモリ量を他のアプリケーションに通知する過程と，
定期的にスレッドの状態を測定し，ロックの解放待ちで待機中の状態のスレッドを抽出する過程と，
前記抽出されたロックの解放待ちで待機中の状態のスレッドごとに，連続して抽出された回数をカウントする過程と，
前記連続して抽出された回数があらかじめ指定されたしきい値を上回るスレッドが，２つ以上存在する場合に，デッドロックの危険性があると判断し，警告を出力する過程とを有する
ことを特徴とする実行環境の危険予測／回避方法。 - 割り当てたメモリの解放をガベージコレクションによって行うプログラム実行環境を有するコンピュータシステムにおいて，
ガベージコレクションのイベント発生時に，ガベージコレクション直後のメモリ使用量を測定する手段と，
前記測定されたメモリ使用量からメモリ不足の危険性を予測する手段と，
メモリの空き容量をＡ，メモリの全容量をＢ，メモリ空き回復しきい値をＴとしたときに，前記予測されたメモリ不足の危険性を回避するために必要なメモリ量ｍを，「（Ａ＋ｍ）／（Ｂ＋ｍ）＞Ｔ」の式を満たすｍを求めることにより算出する手段と，
前記予測されたメモリ不足の危険性に対する警告とそれを回避するために必要なメモリ量を他のアプリケーションに通知する手段とを備える
ことを特徴とする実行環境の危険予測／回避システム。 - 割り当てたメモリの解放をガベージコレクションによって行うプログラム実行環境を有するコンピュータシステムにおいて実行環境の危険予測および回避を行うためのプログラムであって，
ガベージコレクションのイベント発生時に，ガベージコレクション直後のメモリ使用量を測定する処理と，
前記測定されたメモリ使用量からメモリ不足の危険性を予測する処理と，
メモリの空き容量をＡ，メモリの全容量をＢ，メモリ空き回復しきい値をＴとしたときに，前記予測されたメモリ不足の危険性を回避するために必要なメモリ量ｍを，「（Ａ＋ｍ）／（Ｂ＋ｍ）＞Ｔ」の式を満たすｍを求めることにより算出する処理と，
前記予測されたメモリ不足の危険性に対する警告とそれを回避するために必要なメモリ量を他のアプリケーションに通知する処理とを，
コンピュータに実行させるための実行環境の危険予測／回避プログラム。 - 割り当てたメモリの解放をガベージコレクションによって行うプログラム実行環境を有するコンピュータシステムにおいて実行環境の危険予測および回避を行うためのプログラムを記録したコンピュータ読み取り可能な記録媒体であって，
ガベージコレクションのイベント発生時に，ガベージコレクション直後のメモリ使用量を測定する処理と，
前記測定されたメモリ使用量からメモリ不足の危険性を予測する処理と，
メモリの空き容量をＡ，メモリの全容量をＢ，メモリ空き回復しきい値をＴとしたときに，前記予測されたメモリ不足の危険性を回避するために必要なメモリ量ｍを，「（Ａ＋ｍ）／（Ｂ＋ｍ）＞Ｔ」の式を満たすｍを求めることにより算出する処理と，
前記予測されたメモリ不足の危険性に対する警告とそれを回避するために必要なメモリ量とを他のアプリケーションに通知する処理とを，
コンピュータに実行させるためのプログラムを記録した
ことを特徴とする実行環境の危険予測／回避プログラムの記録媒体。
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/JP2003/005814 WO2004099985A1 (ja) | 2003-05-09 | 2003-05-09 | 実行環境の危険予測/回避方法,システム,プログラムおよびその記録媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPWO2004099985A1 JPWO2004099985A1 (ja) | 2006-07-13 |
| JP4170988B2 true JP4170988B2 (ja) | 2008-10-22 |
Family
ID=33428596
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2004571568A Expired - Fee Related JP4170988B2 (ja) | 2003-05-09 | 2003-05-09 | 実行環境の危険予測／回避方法，システム，プログラムおよびその記録媒体 |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US7516292B2 (ja) |
| JP (1) | JP4170988B2 (ja) |
| WO (1) | WO2004099985A1 (ja) |
Families Citing this family (135)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4589095B2 (ja) * | 2004-12-14 | 2010-12-01 | 三菱電機株式会社 | プログラム実行装置及びプログラム実行方法及びデータ領域管理プログラム |
| DE602006019401D1 (de) * | 2005-04-18 | 2011-02-17 | Research In Motion Ltd | Zentralisierte speicherverwaltung in drahtlosen endgeräten |
| JP4996073B2 (ja) * | 2005-07-13 | 2012-08-08 | 富士通株式会社 | 世代別ガベージコレクションプログラム |
| US20070061429A1 (en) * | 2005-09-12 | 2007-03-15 | Microsoft Corporation | Optimizing utilization of application resources |
| JP2007087053A (ja) * | 2005-09-21 | 2007-04-05 | Oki Electric Ind Co Ltd | ディスクアレイ制御装置および制御方法 |
| US8234378B2 (en) * | 2005-10-20 | 2012-07-31 | Microsoft Corporation | Load balancing in a managed execution environment |
| US7926071B2 (en) | 2005-10-20 | 2011-04-12 | Microsoft Corporation | Load balancing interfaces |
| WO2008054403A2 (en) * | 2005-11-15 | 2008-05-08 | Probity Laboratories, Llc | Systems and methods for identifying, categorizing, quantifying and evaluating risks |
| JP5167589B2 (ja) * | 2006-02-13 | 2013-03-21 | 富士通株式会社 | アプリケーションサーバ装置および仮想マシンプログラム |
| JP2007226399A (ja) * | 2006-02-22 | 2007-09-06 | Hitachi Ltd | 計算機制御方法、計算機、計算機制御プログラム及び計算機システム |
| CN100426225C (zh) * | 2006-04-21 | 2008-10-15 | 华为技术有限公司 | 一种内存保护方法及其*** |
| US8161544B2 (en) * | 2006-07-19 | 2012-04-17 | Microsoft Corporation | Trusted communications with child processes |
| CN101512488B (zh) * | 2006-08-07 | 2013-11-27 | 甲骨文国际公司 | 在虚拟机环境中提供硬件虚拟化的***和方法 |
| US7475214B2 (en) * | 2006-08-16 | 2009-01-06 | International Business Machines Corporation | Method and system to optimize java virtual machine performance |
| US7730269B2 (en) * | 2006-08-29 | 2010-06-01 | International Business Machines Corporation | Load management to reduce communication signaling latency in a virtual machine environment |
| US7761487B2 (en) * | 2006-12-13 | 2010-07-20 | Computer Associates Think, Inc. | Predicting out of memory conditions using soft references |
| US20080162709A1 (en) * | 2006-12-27 | 2008-07-03 | International Business Machines Corporation | System for processing application protocol requests |
| US8601469B2 (en) * | 2007-03-30 | 2013-12-03 | Sap Ag | Method and system for customizing allocation statistics |
| US8667471B2 (en) * | 2007-03-30 | 2014-03-04 | Sap Ag | Method and system for customizing profiling sessions |
| US20080243970A1 (en) * | 2007-03-30 | 2008-10-02 | Sap Ag | Method and system for providing loitering trace in virtual machines |
| US7904493B2 (en) * | 2007-03-30 | 2011-03-08 | Sap Ag | Method and system for object age detection in garbage collection heaps |
| US8522209B2 (en) * | 2007-03-30 | 2013-08-27 | Sap Ag | Method and system for integrating profiling and debugging |
| US8356286B2 (en) * | 2007-03-30 | 2013-01-15 | Sap Ag | Method and system for providing on-demand profiling infrastructure for profiling at virtual machines |
| US8336033B2 (en) * | 2007-03-30 | 2012-12-18 | Sap Ag | Method and system for generating a hierarchical tree representing stack traces |
| US7937618B2 (en) * | 2007-04-26 | 2011-05-03 | International Business Machines Corporation | Distributed, fault-tolerant and highly available computing system |
| US8775717B2 (en) | 2007-12-27 | 2014-07-08 | Sandisk Enterprise Ip Llc | Storage controller for flash memory including a crossbar switch connecting a plurality of processors with a plurality of internal memories |
| US9727436B2 (en) * | 2008-01-02 | 2017-08-08 | International Business Machines Corporation | Adding a profiling agent to a virtual machine to permit performance and memory consumption analysis within unit tests |
| JP2009238011A (ja) * | 2008-03-27 | 2009-10-15 | Nec Corp | 実行環境の制御方法およびプログラム |
| US8095766B2 (en) * | 2008-04-07 | 2012-01-10 | International Business Machines Corporation | Method and system for approximating object sizes in an object-oriented system |
| US8601166B2 (en) | 2008-05-14 | 2013-12-03 | Nec Corporation | Information processing system and information processing method for generating distribution and synchronization rules in a client/server environment based on operation environment data |
| US7870257B2 (en) * | 2008-06-02 | 2011-01-11 | International Business Machines Corporation | Enhancing real-time performance for java application serving |
| EP2237197A1 (en) * | 2009-03-31 | 2010-10-06 | Siemens Aktiengesellschaft | Method for evaluating key production indicators (KPI) in a manufacturing execution system (MES) |
| US8365041B2 (en) | 2010-03-17 | 2013-01-29 | Sandisk Enterprise Ip Llc | MLC self-raid flash data protection scheme |
| JP5196596B2 (ja) * | 2010-03-19 | 2013-05-15 | Ｎｅｃシステムテクノロジー株式会社 | 障害検知システム、障害検知サーバ、及び、障害検知方法 |
| CA2700217C (en) * | 2010-04-01 | 2011-07-19 | Ibm Canada Limited - Ibm Canada Limitee | Write barrier elision for reference arrays |
| GB2500153A (en) | 2010-11-30 | 2013-09-11 | Ibm | A Method, Computer Program and System to Optimize Memory Management of An Application Running on a Virtual Machine |
| US8909982B2 (en) | 2011-06-19 | 2014-12-09 | Sandisk Enterprise Ip Llc | System and method for detecting copyback programming problems |
| US8910020B2 (en) | 2011-06-19 | 2014-12-09 | Sandisk Enterprise Ip Llc | Intelligent bit recovery for flash memory |
| US8793543B2 (en) | 2011-11-07 | 2014-07-29 | Sandisk Enterprise Ip Llc | Adaptive read comparison signal generation for memory systems |
| US8924815B2 (en) | 2011-11-18 | 2014-12-30 | Sandisk Enterprise Ip Llc | Systems, methods and devices for decoding codewords having multiple parity segments |
| US8954822B2 (en) | 2011-11-18 | 2015-02-10 | Sandisk Enterprise Ip Llc | Data encoder and decoder using memory-specific parity-check matrix |
| US9048876B2 (en) | 2011-11-18 | 2015-06-02 | Sandisk Enterprise Ip Llc | Systems, methods and devices for multi-tiered error correction |
| US8458702B1 (en) | 2012-02-28 | 2013-06-04 | Google Inc. | Method for implementing user space up-calls on java virtual machine before/after garbage collection |
| US9699263B1 (en) | 2012-08-17 | 2017-07-04 | Sandisk Technologies Llc. | Automatic read and write acceleration of data accessed by virtual machines |
| US9753846B2 (en) * | 2012-09-06 | 2017-09-05 | Red Hat, Inc. | Adjusting the operating memory used by a virtual machine during runtime |
| US9418003B2 (en) * | 2012-10-10 | 2016-08-16 | Salesforce.Com, Inc. | System, method and computer program product for conditionally performing garbage collection |
| US9501398B2 (en) | 2012-12-26 | 2016-11-22 | Sandisk Technologies Llc | Persistent storage device with NVRAM for staging writes |
| US9612948B2 (en) | 2012-12-27 | 2017-04-04 | Sandisk Technologies Llc | Reads and writes between a contiguous data block and noncontiguous sets of logical address blocks in a persistent storage device |
| US9239751B1 (en) | 2012-12-27 | 2016-01-19 | Sandisk Enterprise Ip Llc | Compressing data from multiple reads for error control management in memory systems |
| US9454420B1 (en) | 2012-12-31 | 2016-09-27 | Sandisk Technologies Llc | Method and system of reading threshold voltage equalization |
| US9003264B1 (en) | 2012-12-31 | 2015-04-07 | Sandisk Enterprise Ip Llc | Systems, methods, and devices for multi-dimensional flash RAID data protection |
| US9329928B2 (en) | 2013-02-20 | 2016-05-03 | Sandisk Enterprise IP LLC. | Bandwidth optimization in a non-volatile memory system |
| US9214965B2 (en) | 2013-02-20 | 2015-12-15 | Sandisk Enterprise Ip Llc | Method and system for improving data integrity in non-volatile storage |
| US9870830B1 (en) | 2013-03-14 | 2018-01-16 | Sandisk Technologies Llc | Optimal multilevel sensing for reading data from a storage medium |
| US9236886B1 (en) | 2013-03-15 | 2016-01-12 | Sandisk Enterprise Ip Llc | Universal and reconfigurable QC-LDPC encoder |
| US9367246B2 (en) | 2013-03-15 | 2016-06-14 | Sandisk Technologies Inc. | Performance optimization of data transfer for soft information generation |
| US9009576B1 (en) | 2013-03-15 | 2015-04-14 | Sandisk Enterprise Ip Llc | Adaptive LLR based on syndrome weight |
| US9244763B1 (en) | 2013-03-15 | 2016-01-26 | Sandisk Enterprise Ip Llc | System and method for updating a reading threshold voltage based on symbol transition information |
| US9136877B1 (en) | 2013-03-15 | 2015-09-15 | Sandisk Enterprise Ip Llc | Syndrome layered decoding for LDPC codes |
| US9092350B1 (en) | 2013-03-15 | 2015-07-28 | Sandisk Enterprise Ip Llc | Detection and handling of unbalanced errors in interleaved codewords |
| US9170941B2 (en) | 2013-04-05 | 2015-10-27 | Sandisk Enterprises IP LLC | Data hardening in a storage system |
| US10049037B2 (en) | 2013-04-05 | 2018-08-14 | Sandisk Enterprise Ip Llc | Data management in a storage system |
| US9495395B2 (en) * | 2013-04-11 | 2016-11-15 | Oracle International Corporation | Predictive diagnosis of SLA violations in cloud services by seasonal trending and forecasting with thread intensity analytics |
| US9159437B2 (en) | 2013-06-11 | 2015-10-13 | Sandisk Enterprise IP LLC. | Device and method for resolving an LM flag issue |
| TWI573015B (zh) * | 2013-06-19 | 2017-03-01 | 祥碩科技股份有限公司 | 防超時方法及資料處理系統 |
| US9043517B1 (en) | 2013-07-25 | 2015-05-26 | Sandisk Enterprise Ip Llc | Multipass programming in buffers implemented in non-volatile data storage systems |
| US9524235B1 (en) | 2013-07-25 | 2016-12-20 | Sandisk Technologies Llc | Local hash value generation in non-volatile data storage systems |
| US9384126B1 (en) | 2013-07-25 | 2016-07-05 | Sandisk Technologies Inc. | Methods and systems to avoid false negative results in bloom filters implemented in non-volatile data storage systems |
| US9652766B1 (en) * | 2013-08-22 | 2017-05-16 | Amazon Technologies, Inc. | Managing data stored in memory locations having size limitations |
| US9639463B1 (en) | 2013-08-26 | 2017-05-02 | Sandisk Technologies Llc | Heuristic aware garbage collection scheme in storage systems |
| US9235509B1 (en) | 2013-08-26 | 2016-01-12 | Sandisk Enterprise Ip Llc | Write amplification reduction by delaying read access to data written during garbage collection |
| US9442670B2 (en) | 2013-09-03 | 2016-09-13 | Sandisk Technologies Llc | Method and system for rebalancing data stored in flash memory devices |
| US9519577B2 (en) | 2013-09-03 | 2016-12-13 | Sandisk Technologies Llc | Method and system for migrating data between flash memory devices |
| US9158349B2 (en) | 2013-10-04 | 2015-10-13 | Sandisk Enterprise Ip Llc | System and method for heat dissipation |
| US9323637B2 (en) | 2013-10-07 | 2016-04-26 | Sandisk Enterprise Ip Llc | Power sequencing and data hardening architecture |
| US9298608B2 (en) | 2013-10-18 | 2016-03-29 | Sandisk Enterprise Ip Llc | Biasing for wear leveling in storage systems |
| US9442662B2 (en) | 2013-10-18 | 2016-09-13 | Sandisk Technologies Llc | Device and method for managing die groups |
| US9436831B2 (en) | 2013-10-30 | 2016-09-06 | Sandisk Technologies Llc | Secure erase in a memory device |
| US9263156B2 (en) | 2013-11-07 | 2016-02-16 | Sandisk Enterprise Ip Llc | System and method for adjusting trip points within a storage device |
| US9244785B2 (en) | 2013-11-13 | 2016-01-26 | Sandisk Enterprise Ip Llc | Simulated power failure and data hardening |
| US9152555B2 (en) | 2013-11-15 | 2015-10-06 | Sandisk Enterprise IP LLC. | Data management with modular erase in a data storage system |
| US9703816B2 (en) | 2013-11-19 | 2017-07-11 | Sandisk Technologies Llc | Method and system for forward reference logging in a persistent datastore |
| US9520197B2 (en) | 2013-11-22 | 2016-12-13 | Sandisk Technologies Llc | Adaptive erase of a storage device |
| US9280429B2 (en) | 2013-11-27 | 2016-03-08 | Sandisk Enterprise Ip Llc | Power fail latching based on monitoring multiple power supply voltages in a storage device |
| US9520162B2 (en) | 2013-11-27 | 2016-12-13 | Sandisk Technologies Llc | DIMM device controller supervisor |
| US9122636B2 (en) | 2013-11-27 | 2015-09-01 | Sandisk Enterprise Ip Llc | Hard power fail architecture |
| US9250676B2 (en) | 2013-11-29 | 2016-02-02 | Sandisk Enterprise Ip Llc | Power failure architecture and verification |
| US9582058B2 (en) | 2013-11-29 | 2017-02-28 | Sandisk Technologies Llc | Power inrush management of storage devices |
| US9092370B2 (en) | 2013-12-03 | 2015-07-28 | Sandisk Enterprise Ip Llc | Power failure tolerant cryptographic erase |
| US9235245B2 (en) | 2013-12-04 | 2016-01-12 | Sandisk Enterprise Ip Llc | Startup performance and power isolation |
| US9747028B1 (en) * | 2013-12-13 | 2017-08-29 | Amazon Technologies, Inc. | Artificial memory pressure for low memory machine |
| US9129665B2 (en) | 2013-12-17 | 2015-09-08 | Sandisk Enterprise Ip Llc | Dynamic brownout adjustment in a storage device |
| US9549457B2 (en) | 2014-02-12 | 2017-01-17 | Sandisk Technologies Llc | System and method for redirecting airflow across an electronic assembly |
| US9497889B2 (en) | 2014-02-27 | 2016-11-15 | Sandisk Technologies Llc | Heat dissipation for substrate assemblies |
| US9703636B2 (en) | 2014-03-01 | 2017-07-11 | Sandisk Technologies Llc | Firmware reversion trigger and control |
| US9519319B2 (en) | 2014-03-14 | 2016-12-13 | Sandisk Technologies Llc | Self-supporting thermal tube structure for electronic assemblies |
| US9485851B2 (en) | 2014-03-14 | 2016-11-01 | Sandisk Technologies Llc | Thermal tube assembly structures |
| US9348377B2 (en) | 2014-03-14 | 2016-05-24 | Sandisk Enterprise Ip Llc | Thermal isolation techniques |
| US9454448B2 (en) | 2014-03-19 | 2016-09-27 | Sandisk Technologies Llc | Fault testing in storage devices |
| US9448876B2 (en) | 2014-03-19 | 2016-09-20 | Sandisk Technologies Llc | Fault detection and prediction in storage devices |
| US9390814B2 (en) | 2014-03-19 | 2016-07-12 | Sandisk Technologies Llc | Fault detection and prediction for data storage elements |
| US9626400B2 (en) | 2014-03-31 | 2017-04-18 | Sandisk Technologies Llc | Compaction of information in tiered data structure |
| US9390021B2 (en) | 2014-03-31 | 2016-07-12 | Sandisk Technologies Llc | Efficient cache utilization in a tiered data structure |
| US9626399B2 (en) | 2014-03-31 | 2017-04-18 | Sandisk Technologies Llc | Conditional updates for reducing frequency of data modification operations |
| US9697267B2 (en) | 2014-04-03 | 2017-07-04 | Sandisk Technologies Llc | Methods and systems for performing efficient snapshots in tiered data structures |
| US9070481B1 (en) | 2014-05-30 | 2015-06-30 | Sandisk Technologies Inc. | Internal current measurement for age measurements |
| US10656842B2 (en) | 2014-05-30 | 2020-05-19 | Sandisk Technologies Llc | Using history of I/O sizes and I/O sequences to trigger coalesced writes in a non-volatile storage device |
| US10372613B2 (en) | 2014-05-30 | 2019-08-06 | Sandisk Technologies Llc | Using sub-region I/O history to cache repeatedly accessed sub-regions in a non-volatile storage device |
| US9645749B2 (en) | 2014-05-30 | 2017-05-09 | Sandisk Technologies Llc | Method and system for recharacterizing the storage density of a memory device or a portion thereof |
| US10114557B2 (en) | 2014-05-30 | 2018-10-30 | Sandisk Technologies Llc | Identification of hot regions to enhance performance and endurance of a non-volatile storage device |
| US9703491B2 (en) | 2014-05-30 | 2017-07-11 | Sandisk Technologies Llc | Using history of unaligned writes to cache data and avoid read-modify-writes in a non-volatile storage device |
| US8891303B1 (en) | 2014-05-30 | 2014-11-18 | Sandisk Technologies Inc. | Method and system for dynamic word line based configuration of a three-dimensional memory device |
| US9093160B1 (en) | 2014-05-30 | 2015-07-28 | Sandisk Technologies Inc. | Methods and systems for staggered memory operations |
| US10146448B2 (en) | 2014-05-30 | 2018-12-04 | Sandisk Technologies Llc | Using history of I/O sequences to trigger cached read ahead in a non-volatile storage device |
| US10656840B2 (en) | 2014-05-30 | 2020-05-19 | Sandisk Technologies Llc | Real-time I/O pattern recognition to enhance performance and endurance of a storage device |
| US10162748B2 (en) | 2014-05-30 | 2018-12-25 | Sandisk Technologies Llc | Prioritizing garbage collection and block allocation based on I/O history for logical address regions |
| US9652381B2 (en) | 2014-06-19 | 2017-05-16 | Sandisk Technologies Llc | Sub-block garbage collection |
| US9443601B2 (en) | 2014-09-08 | 2016-09-13 | Sandisk Technologies Llc | Holdup capacitor energy harvesting |
| US9537788B2 (en) * | 2014-12-05 | 2017-01-03 | Amazon Technologies, Inc. | Automatic determination of resource sizing |
| CA2876379A1 (en) * | 2014-12-29 | 2016-06-29 | Adam J. Storm | Memory management in presence of asymmetrical memory transfer costs |
| JP6447348B2 (ja) | 2015-05-01 | 2019-01-09 | 富士通株式会社 | ダンプデータ管理プログラム、ダンプデータ管理方法、およびダンプデータ管理装置 |
| US10248561B2 (en) | 2015-06-18 | 2019-04-02 | Oracle International Corporation | Stateless detection of out-of-memory events in virtual machines |
| US10417111B2 (en) | 2016-05-09 | 2019-09-17 | Oracle International Corporation | Correlation of stack segment intensity in emergent relationships |
| US9672062B1 (en) * | 2016-12-01 | 2017-06-06 | Red Hat, Inc. | Batched memory page hinting |
| US10198674B2 (en) * | 2016-12-22 | 2019-02-05 | Canon Kabushiki Kaisha | Method, apparatus and system for rendering a graphical representation within limited memory |
| US10565104B2 (en) | 2017-08-01 | 2020-02-18 | International Business Machines Corporation | System and method to manage and share managed runtime memory for JAVA virtual machine |
| US10579439B2 (en) | 2017-08-29 | 2020-03-03 | Red Hat, Inc. | Batched storage hinting with fast guest storage allocation |
| US10956216B2 (en) | 2017-08-31 | 2021-03-23 | Red Hat, Inc. | Free page hinting with multiple page sizes |
| US10747566B2 (en) | 2017-11-21 | 2020-08-18 | International Business Machines Corporation | Restarting application servers |
| US10474382B2 (en) | 2017-12-01 | 2019-11-12 | Red Hat, Inc. | Fast virtual machine storage allocation with encrypted storage |
| KR20200027204A (ko) * | 2018-09-04 | 2020-03-12 | 삼성전자주식회사 | 전자장치 및 그 제어방법 |
| US10884641B2 (en) | 2019-04-16 | 2021-01-05 | Paypal, Inc. | Low latency gateway for an asynchronous orchestration engine using direct memory |
| US11436141B2 (en) | 2019-12-13 | 2022-09-06 | Red Hat, Inc. | Free memory page hinting by virtual machines |
| US11144369B2 (en) | 2019-12-30 | 2021-10-12 | Bank Of America Corporation | Preemptive self-healing of application server hanging threads |
| CN111831467A (zh) * | 2020-07-21 | 2020-10-27 | 北京思特奇信息技术股份有限公司 | java进程内存溢出自熔断的方法、***和电子设备 |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH0527993A (ja) | 1991-07-24 | 1993-02-05 | Toshiba Corp | デツドロツク検出処理方式 |
| JPH05227993A (ja) * | 1992-02-24 | 1993-09-07 | Nippon Oil & Fats Co Ltd | 抗酸化活性測定方法 |
| JP3027845B2 (ja) * | 1997-11-21 | 2000-04-04 | オムロン株式会社 | プログラム制御装置および方法 |
| JP3795669B2 (ja) * | 1998-04-28 | 2006-07-12 | 富士通株式会社 | メモリ管理装置およびメモリ管理プログラムを記憶した記憶媒体 |
| JP2001265650A (ja) * | 2000-03-15 | 2001-09-28 | Omron Corp | メモリリソース使用状況監視装置及びメモリリソース使用状況監視方法 |
| US6542911B2 (en) * | 2001-03-01 | 2003-04-01 | Sun Microsystems, Inc. | Method and apparatus for freeing memory from an extensible markup language document object model tree active in an application cache |
-
2003
- 2003-05-09 JP JP2004571568A patent/JP4170988B2/ja not_active Expired - Fee Related
- 2003-05-09 WO PCT/JP2003/005814 patent/WO2004099985A1/ja active Application Filing
-
2005
- 2005-06-29 US US11/170,217 patent/US7516292B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JPWO2004099985A1 (ja) | 2006-07-13 |
| WO2004099985A1 (ja) | 2004-11-18 |
| US20050240641A1 (en) | 2005-10-27 |
| US7516292B2 (en) | 2009-04-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4170988B2 (ja) | 実行環境の危険予測／回避方法，システム，プログラムおよびその記録媒体 | |
| JP4920391B2 (ja) | 計算機システムの管理方法、管理サーバ、計算機システム及びプログラム | |
| US8886866B2 (en) | Optimizing memory management of an application running on a virtual machine | |
| US7171668B2 (en) | Automatic data interpretation and implementation using performance capacity management framework over many servers | |
| US7730364B2 (en) | Systems and methods for predictive failure management | |
| US8365183B2 (en) | System and method for dynamic resource provisioning for job placement | |
| US7761487B2 (en) | Predicting out of memory conditions using soft references | |
| US7203746B1 (en) | System and method for adaptive resource management | |
| US11526386B2 (en) | System and method for automatically scaling a cluster based on metrics being monitored | |
| US6662204B2 (en) | Thread control system and method in a computer system | |
| US8660816B2 (en) | Method, system, and computer program product for determining a hang state and distinguishing a hang state from an idle state | |
| US20030014507A1 (en) | Method and system for providing performance analysis for clusters | |
| US20050096877A1 (en) | System and method for determination of load monitoring condition and load monitoring program | |
| JP4761229B2 (ja) | 運用管理装置、運用管理方法ならびにプログラム | |
| JP2009123238A (ja) | 制御装置、計算機システム、制御装置のプロセス制御方法、計算機システムの計算機制御方法、計算機制御プログラムおよびプロセス制御プログラム | |
| JP5821471B2 (ja) | 情報処理装置、プロセス監視方法、プロセス監視プログラム、記録媒体 | |
| JP2007156976A (ja) | 情報処理システム | |
| JP5601587B2 (ja) | プロセス再起動装置、プロセス再起動方法およびプロセス再起動プログラム | |
| JP4408122B2 (ja) | 計算機システム、計算機システムの計算機制御方法および計算機制御プログラム | |
| US11899578B2 (en) | System and method for dynamic selection of a garbage collector for java-based microservices | |
| JP2005182594A (ja) | コンピュータ及びプログラム | |
| CN117806778B (zh) | 资源管理方法、***、设备及介质 | |
| KR20000015430A (ko) | 컴퓨터 시스템의 자동화된 작업 스케쥴러 | |
| CN116915776A (zh) | 数据节点扩容方法、装置、设备及计算机可读存储介质 | |
| JP2002163130A (ja) | コンピュータシステム、コンピュータシステムの診断装置、およびコンピュータ読み取り可能な記憶媒体 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080507 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080707 |
|
| RD03 | Notification of appointment of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7423 Effective date: 20080707 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20080707 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080805 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080807 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110815 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120815 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120815 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130815 Year of fee payment: 5 |
|
| LAPS | Cancellation because of no payment of annual fees |