JP4116877B2 - ヒープサイズ自動最適化処理方法，ヒープサイズ自動最適化装置およびそのプログラム - Google Patents
ヒープサイズ自動最適化処理方法，ヒープサイズ自動最適化装置およびそのプログラム Download PDFInfo
- Publication number
- JP4116877B2 JP4116877B2 JP2002378194A JP2002378194A JP4116877B2 JP 4116877 B2 JP4116877 B2 JP 4116877B2 JP 2002378194 A JP2002378194 A JP 2002378194A JP 2002378194 A JP2002378194 A JP 2002378194A JP 4116877 B2 JP4116877 B2 JP 4116877B2
- Authority
- JP
- Japan
- Prior art keywords
- size
- heap
- heap size
- time
- information
- 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
Description
【０００１】
【発明の属する技術分野】
本発明は，ガベージコレクション（Garbage Collection）を実装するコンピュータシステムにおいて，最適なヒープサイズを求めるためのヒープサイズ自動最適化処理方法に関するものである。
【０００２】
以下では，ガベージコレクションをＧＣと記す。ここで，ＧＣを実装するコンピュータシステムとして，例えば，ＪＶＭ（Java Virtual Machine：Ｊａｖａ（登録商標）仮想マシン）がある。本明細書では，ＧＣを実装するコンピュータシステムとしてＪＶＭの例を用いて説明するが，本発明を適用できるシステムは，ＪＶＭに限られない。
【０００３】
【従来の技術】
一般に，ヒープサイズの見積りの技術に関して，Ｊａｖａのように動的にメモリを確保するプログラムでは，必要となるメモリ量の見積り（予測）が難しいとされていた（例えば，非特許文献１参照）。
【０００４】
コンピュータによるアプリケーションの処理能力を表すもののうち，ＧＣによって影響を受けるものとしては，スループットと応答性能とがある。ここで，スループットとは，単位時間内にアプリケーションが処理する仕事量のことである。また，応答性能とは，ユーザによる入力からユーザへの出力までの時間の均一度であり，均一であるほど応答性能はよいものとされる。
【０００５】
ＧＣの間は，ユーザプログラムが停止している。ＧＣの起動頻度が高いと，そのたびにユーザプログラムが停止するため，スループットは低下する。したがって，スループットを向上させるには，スループットを低下させる要因であるＧＣの起動頻度を少なくするために，ヒープサイズを大きくとることが望ましい。
【０００６】
一方，応答性能を向上させるには，１回のＧＣの処理コストを小さくするために，ヒープサイズを小さくすることが望ましい。これは，１回のＧＣの処理コストが大きいとＧＣによってヒープがブロックされ，システムが停止してしまう時間が延びてしまうためである。ユーザからのトランザクションがあったときに，ＧＣ中でなければすぐに応答可能であるが，ＧＣ中であればＧＣが終了するまで応答不可能となる。１回のＧＣの処理コストが大きいと，ＧＣ中であった場合となかった場合とでユーザへ応答するまで時間が不均一となるため，応答性能は低下する。
【０００７】
以上のような問題に対処するため，従来は，スループットを向上させるためには，ヒープサイズを大きくとることを考慮することで解決してきた。また，応答性能を向上させるためには，なるべくヒープサイズを小さくとることで解決してきた。しかし，これら相反する条件を同時に解決することは不可能であり，実際の運用において必要かつ最適なヒープサイズを求めることはきわめて困難であった。
【０００８】
そのため，従来はヒープ不足が発生したときにはヒープサイズを増やし，膨大なヒープサイズによるＧＣ性能劣化のため応答性能が悪化したときにはヒープサイズを減らし，そのたびに再起動を繰り返すしかなかった。
【０００９】
また，従来の技術として，頻繁にＧＣを繰り返してオブジェクトのドラッグ時間（最終アクセスからＧＣで回収されるまでの無駄にヒープを使用する時間）を短くする技術があった（例えば，非特許文献２参照）。この技術は，タイムラグ（ここでは，ドラッグ時間のこと）を短くするための技術であり，ＪＶＭ上のＪａｖａアプリケーション側で対処する技術である。しかし，頻繁に起動するＧＣは処理的な負担が大きく，極端にスループットを低下させてしまうという問題があった。
【００１０】
【非特許文献１】
ジェイムズ・ノーブル，チャールズ・ウィアー著，安藤慶一訳，「省メモリプログラミング メモリ制限のあるシステムのためのソフトウェアパターン集」，ピアソン・エデュケーション，p.269
【非特許文献２】
Ran Shaham,Elliot K.Kolodner,and Mooly Sagiv.,"On the Effectiveness of GC in Java." ,The 2000 International Symposium on Memory Management(ISMM'00),October 2000
【００１１】
【発明が解決しようとする課題】
以上のような従来の方法では，任意のＪａｖａアプリケーションを実行するときに，スループットと応答性能との双方のバランスをみて最適となる妥協点を自動的に求めることはできなかった。また，ヒープサイズの見積りの精度も悪く，最適なヒープサイズを見積もるまでには何度も試行を繰り返す必要があり，作業コストが膨大にかかってしまっていた。
【００１２】
本発明は，上記問題点の解決を図り，ＧＣを実装するコンピュータシステム（ＪＶＭ等）において，スループットと応答性能とのバランスから，最適なヒープサイズを自動的に求めることができるヒープサイズ自動最適化手段を提供することを目的とする。
【００１３】
【課題を解決するための手段】
本発明は，上記目的を達成するため，最適な応答性能となる点を求めるために，生存しているオブジェクト（ルートから到達可能なオブジェクト）を確保するための最低必要なヒープサイズを求め，応答性能を極端に悪化させない程度にスループットを向上させるために，オブジェクトの寿命をプロファイルして，例えば大半のオブジェクトが１回のＧＣで回収される（回収可能率が向上する）というような予め定められた基準またはスループット性能（不要オブジェクトの回収率）を優先するとか応答性能（ヒープ使用効率）を優先するとかいったオペレータが指定した基準に基づいてＧＣインターバルを調整し，最適なヒープサイズを求めることを特徴とする。
【００１４】
具体的には，ガベージコレクション（ＧＣ）を実装するコンピュータシステムにおいて，全オブジェクトの寿命や固有情報のプロファイリングデータを分析することで最適なヒープサイズを求めるため，ロギング処理部，分析処理部，見積り処理部を持つ。ロギング処理部は，オブジェクトの寿命情報とサイズ情報とを収集する。分析処理部は，オブジェクトの寿命をもとに任意の時点で生存するオブジェクトのサイズを積み重ねることで，各時点の必要ヒープサイズを求める。必要ヒープサイズを時系列にそって推移させ，システム全体での最低必要なヒープサイズを求める。さらに見積り処理部では，最低必要ヒープサイズを上回る範囲で，ＧＣによるゴミとなったオブジェクトの回収率と，システム全体で比較的最も多くのヒープサイズを占める寿命に合わせたＧＣインターバルとのバランスをみて最適なヒープサイズを求める。
【００１５】
プロファイリングデータは，全オブジェクトでなくとも一部または一定期間のオブジェクトを対象としてもよい。寿命の単位は，実際の時間でも延べ割当てサイズ（オブジェクト生成時の総割当て量〜終了時の総割当て量を寿命とする）でもよい。すなわち，寿命の時間の尺度を，実際の時間〔秒〕を単位にしても延べ割当てサイズ〔ｂｙｔｅ〕を単位にしてもよい。
【００１６】
以上のロギング処理部，分析処理部，見積り処理部による処理は，コンピュータとソフトウェアプログラムとによって実現することができ，そのプログラムをコンピュータ読み取り可能な記録媒体に記録することも，ネットワークを通して提供することも可能である。
【００１７】
【発明の実施の形態】
本発明の実施の形態を説明するに先立ち，実施の形態の説明中で用いている言葉の意味について簡単に説明する。
「応答性能」：ユーザの入力からユーザへの出力時間の均一度。均一であるほど応答性能はよい。
「スループット性能」：単位時間内にアプリケーションが処理する仕事量。
「オブジェクト寿命」：オブジェクトが生成されてからオブジェクトの最終アクセスまでの時間（ここで時間とは，実際の時間または延べ割当てサイズ）。
「真のオブジェクト寿命」：オブジェクトが生成されてからそのオブジェクトに対し到達不能になるまでの時間。
「活動中ヒープサイズ」：ある一時点での，生成されてからアクセスされなくなるまでのオブジェクトの総量。
「指定ヒープサイズ」：システムに指定したヒープサイズ。
「使用ヒープサイズ」：ある一時点での，実際にヒープに存在するオブジェクトの総量。
「必要ヒープサイズ」：ある一時点での，オブジェクト生成から到達不能になるまでのオブジェクトの総量。
「到達不能オブジェクト」：ルートから到達できないオブジェクト。システムが不要とみなし次のＧＣで回収対象となるオブジェクト。
「プロファイル」：システム内の情報をロギング・分析すること。
「ドラッグ時間」：オブジェクトの最終アクセスからオブジェクトが回収されるまでの無駄にヒープを使用する時間。
「スレッドローカル」：あるオブジェクトを生成したスレッド以外のスレッドからアクセスされないこと。
【００１８】
図１は，本発明の実施の形態に係るヒープサイズ自動最適化装置の構成例を示す。本実施の形態におけるヒープサイズ自動最適化装置１は，ＣＰＵおよびメモリなどからなるコンピュータであり，ソフトウェアプログラム等によって構成されるロギング処理部１０，分析処理部２０，見積り処理部３０を備えている。ロギング処理部１０は，プロファイル情報ロギングルーチン１１を備え，分析処理部２０は，データ整理部２１，ソート部２２，可視化部２３を備える。
【００１９】
ロギング処理部１０は，オブジェクトの生成時，オブジェクトへのアクセス時，ＧＣの開始時・終了時，メソッドの呼出し時・復帰時などに，プロファイル情報ロギングルーチン１１により，オブジェクトのアドレス，サイズ，スレッド番号，タイムスタンプ等のレコードをプロファイル情報格納域４０に記録する。ここで記録されたレコードをプロファイル情報という。
【００２０】
分析処理部２０は，ロギング処理部１０で収集されたプロファイル情報を分析し，オブジェクトごとにアドレス，サイズ，生成スレッド，生成時刻，最終アクセス時刻，ＧＣ経験回数，スレッドスコープ等のオブジェクト情報を生成し，これをもとに，各オブジェクトの寿命を算出するとともに，生存するオブジェクトのサイズを積算することにより，各時点における必要ヒープサイズを算出する処理を行う。
【００２１】
分析処理部２０のデータ整理部２１は，プロフィル情報格納域４０から読み込んだプロファイル情報をオブジェクトごとにまとめてオブジェクト情報を生成し，オブジェクト情報格納域５０に格納する処理を行う。ソート部２２は，オブジェクト情報格納域５０に格納されたオブジェクト情報を，種々の条件によりソートし，必要ヒープサイズデータ６０やオブジェクト寿命特性７０を算出する。可視化部２３は，分析結果としての必要ヒープサイズデータ６０やオブジェクト寿命特性７０等のデータをグラフ化するなどして，目に見える形に編集し，ディスプレイやプリンタに出力する。図中の８０は必要／使用ヒープサイズのグラフ，９０はオブジェクト寿命分布のグラフである。
【００２２】
見積り処理部３０は，分析処理部２０でのプロファイル情報の分析結果から，スループット性能および応答性能のバランスから予め定められた基準に従って，最適な指定ヒープサイズを自動的に見積もる。このとき，最適な指定ヒープサイズを決定する基準をユーザに指定させ，その基準に従って最適な指定ヒープサイズを自動的に見積もってもよい。
【００２３】
図２は，本実施の形態におけるヒープサイズ自動最適化処理フローチャートである。まず，ロギング処理部１０は，プロファイル情報ロギングルーチン１１によって，オブジェクトの生成，オブジェクトのアクセス，ＧＣ開始／終了，オブジェクトの生存情報，メソッド呼出し／復帰等に関するレコードをログに記録し，そのログをプロファイル情報格納域４０に出力する（ステップＳ１）。
【００２４】
分析処理部２０は，データ整理部２１によって，プロファイル情報格納域４０のログに記録されたレコードをｏｂｊ構造体を用いてオブジェクトごとに整理し，オブジェクト情報としてオブジェクト情報格納域５０に出力する（ステップＳ２）。また，分析処理部２０は，ソート部２２によって，オブジェクト情報格納域５０のオブジェクト情報をソートし，必要ヒープサイズデータ６０，オブジェクト寿命特性７０を得る（ステップＳ３）。さらに，分析処理部２０は，可視化部２３によって，必要ヒープサイズデータ６０から必要／使用ヒープサイズのグラフ８０を，オブジェクト寿命特性７０からオブジェクト寿命分布のグラフ９０を作成し出力する（ステップＳ４）。
【００２５】
見積り処理部３０は，分析処理部２０で得られたプロファイル情報の分析結果（必要ヒープサイズデータ６０，オブジェクト寿命特性７０など）から，最適な指定ヒープサイズを自動的に見積もる（ステップＳ５）。
【００２６】
図３は，本実施の形態におけるプロファイル情報の収集契機とデータレコードの例を示す図である。特に図３（Ａ）は，オブジェクトの生成から回収までの流れとＧＣとの関係およびプロファイル情報の収集契機を示している。また，図３（Ｂ）は，図３（Ａ）の流れの中でログに記録されるレコードの形式（データレコード形式）の例を示している。図３において，“ｏｂｊ”は，それぞれ個々のオブジェクトを表している。
【００２７】
ロギング処理部１０により，プロファイル情報のレコードがログされる契機は，オブジェクトの生成時（レコードＲ１），オブジェクトのアクセス時（レコードＲ２），ＧＣの開始・終了時（レコードＲ３，Ｒ６），ＧＣ処理時におけるオブジェクトの生存確認時（レコードＲ４，Ｒ５），オブジェクトのメソッド呼出し時（レコードＲ７），呼び出したメソッドからの復帰時（レコードＲ８）である。この他に，プロファイル期間の開始時および終了時にもログデータが出力される。
【００２８】
図３（Ａ）において，オブジェクトが生成されるとレコードＲ１がログに記録され，そのオブジェクトに参照または更新のアクセスがあるとレコードＲ２がログに記録され，以後，最終アクセスまで繰り返される。オブジェクトの生成からそのオブジェクトへの最終アクセスまでの時間をアクティブ時間（active time ）という。
【００２９】
オブジェクトへの最終アクセス後にルートから到達できなくなると，そのオブジェクトは到達不能（到達不能オブジェクト）となり，次のＧＣで回収される。オブジェクトへの最終アクセスからそのオブジェクトがＧＣにより回収されるまでの時間をドラッグ時間（drag time ）という。
【００３０】
ＧＣの開始時，終了時にそれぞれレコードＲ３，Ｒ６をログに記録し，ＧＣによって回収されない（ＧＣ後も生存する）オブジェクトのレコードＲ４，Ｒ５をログに記録する。あるＧＣの開始時刻から次のＧＣの開始時刻までをＧＣインターバルという。
【００３１】
図３（Ｂ）において，ｏｂｊ−生成（レコードＲ１）は，オブジェクトが生成されたときに記録されるレコードを示す。このとき，生成されたオブジェクトのアドレス，サイズ，そのオブジェクトを生成したスレッドのスレッド番号，生成された時刻を示すタイムスタンプ等の情報がログに記録される。本実施の形態では，オブジェクトを識別するための情報としてアドレスを用いているが，他の識別情報を記録してもよい。
【００３２】
ｏｂｊ−アクセス（レコードＲ２）は，オブジェクトのアクセスがあったときに記録されるレコードを示す。このとき，アクセスがあったオブジェクトのアドレス，サイズ，そのオブジェクトにアクセスしたスレッドのスレッド番号，アクセス時刻を示すタイムスタンプ等の情報がログに記録される。
【００３３】
ＧＣ−開始（レコードＲ３），ＧＣ−終了（レコードＲ６）は，それぞれＧＣの開始時，ＧＣの終了時に記録されるレコードを示す。ＧＣの開始や終了の時刻を示すタイムスタンプ，ＧＣ終了直後の使用ヒープサイズ等の情報がログに記録される。時間の尺度が延べ割当てサイズ（単位は［ｂｙｔｅ］）である場合には，ＧＣ終了時のタイムスタンプは不要である。
【００３４】
ここで，延べ割当てサイズについて説明する。延べ割当てサイズは，生成されたオブジェクトのサイズを生成時刻順に累積したものである。生成されたオブジェクトのサイズを生成時刻順に累積したものは，時間の進行とともに単調増加する。この性質を時間の進行の表現に利用したものが，延べ割当てサイズである。延べ割当てサイズは，オブジェクトの生成により常に増加する値であり，ＧＣ後もリセットされない。したがって，寿命（時間）の尺度を，実際の時間としても，また延べ割当てサイズにしても，実質的には変わりはない。ただし，ＧＣインターバルを定める場合などに，ヒープの使用効率を重視するときには，時間の間隔がヒープの使用量に応じて相対的に定まる延べ割当てサイズを尺度としたほうが好ましい。一方，応答性能などを実時間で保証する必要があるシステム等では，実際の時間を尺度としたほうが好ましい。
【００３５】
例えば，延べ割当てサイズが０［ｂｙｔｅ］の状態から，
(1) オブジェクトＡ（サイズａ［ｂｙｔｅ］）の生成
(2) オブジェクトＢ（サイズｂ［ｂｙｔｅ］）の生成
(3) オブジェクトＡへのアクセス
(4) ＧＣの開始・終了
(5) オブジェクトＣ（サイズｃ［ｂｙｔｅ］）の生成
の順で実行されたとき，それぞれの時刻を延べ割当てサイズで表現すると，
(1) オブジェクトＡの生成時刻・・・・・・０［ｂｙｔｅ］
(2) オブジェクトＢの生成時刻・・・・・・ａ［ｂｙｔｅ］
(3) オブジェクトＡへのアクセス時刻・・・ａ＋ｂ［ｂｙｔｅ］
(4) ＧＣの開始時刻・終了時刻・・・・・・ａ＋ｂ［ｂｙｔｅ］
(5) オブジェクトＣの生成時刻・・・・・・ａ＋ｂ［ｂｙｔｅ］
となる。
【００３６】
図３（Ｂ）において，ｏｂｊ−生存（移動時）（レコードＲ４），ｏｂｊ−生存（レコードＲ５）は，ＧＣ中に，ＧＣ後も生存する（ＧＣによって回収されない）オブジェクトが確認されたときに記録されるレコードを示す。生存するオブジェクトは，ＧＣによって，その位置が移動する場合としない場合がある。ＧＣによってオブジェクトの位置が移動する場合には，そのオブジェクトの移動元アドレス，移動先アドレス，サイズ等のレコードがログに記録され，ＧＣによってオブジェクトの位置が移動しない場合には，そのオブジェクトのアドレス，サイズ等のレコードがログに記録される。
【００３７】
ｍｅｔｈｏｄ−呼出し（レコードＲ７），ｍｅｔｈｏｄ−復帰（レコードＲ８）は，メソッドの呼出し／復帰があるときに記録されるレコードを示す。このとき，メソッドの呼出し／復帰が行われるスレッドのスレッド番号，メソッドに入ったとき／メソッドから抜けたときの時刻を示すタイムスタンプ，そのメソッド名等のレコードがログに記録される。後述するように，これらの情報を解析することにより，オブジェクト生成時のメソッドを知ることができるようになり，どのメソッドがヒープに負担をかけているかが分かるようになる。
【００３８】
分析処理部２０は，各オブジェクトの寿命を知るために，ＧＣによって回収されたオブジェクトについて，図３のように記録されたオブジェクト生成時やオブジェクトアクセス時のプロファイル情報を分析する。
【００３９】
ここで，オブジェクトの寿命とは，実際にはオブジェクトが生成されてから到達不能になるまでの期間のことをいい，時間または延べ割当てサイズの尺度で表現される。ところが，オブジェクトの到達不能点でのレコードの記録がないため，到達不能点までのオブジェクトの寿命をプロファイル情報から直接的には得ることができない。そこで，本実施の形態では，オブジェクトの生成点から最終アクセスまでをオブジェクトの寿命（以下，単に「オブジェクト寿命」という）とし，オブジェクトが生成されてから到達不能になるまでの真のオブジェクトの寿命（以下，「真のオブジェクト寿命」という）は，オブジェクト寿命から以下で説明するように推定する。
【００４０】
ＧＣ直後の総生存オブジェクトサイズをＳg とし，ＧＣ直後の活動中ヒープサイズをＳa とすると，ドラッグ時間中の到達可能オブジェクトを示す最終アクセス点から到達不能点までの期間は，
の式で概算することができる。
【００４１】
（式１）において，ＧＣ直後の総生存オブジェクトサイズ（Ｓg ）は，ＧＣ直後に生成点から到達不能点までの間の状態にあるオブジェクトの総サイズであり，ＧＣ直後の活動中ヒープサイズ（Ｓa ）は，ＧＣ直後に生成点から最終アクセス点までの状態にあるオブジェクトの総サイズである。ＧＣ直後のドラッグ時間中の総オブジェクトサイズは，ＧＣ直後に最終アクセス点から到達不能点までの間の状態にあるオブジェクトの総サイズである。
【００４２】
ＧＣ直後の活動中ヒープサイズ（Ｓa ）に対するＧＣ直後の総生存オブジェクトサイズ（Ｓg ）の値をドラッグ係数（Ｋ）とし，
Ｋ＝Ｓg ／Ｓa （式２）
の式で求める。
【００４３】
必要ヒープサイズは，前述したようにある時点での生成点から到達不能点までの状態にあるオブジェクトの総サイズを示し，その時点での生成点から最終アクセス点までの状態にあるオブジェクトの総サイズである活動中ヒープサイズと，（式２）で求めたドラッグ係数（Ｋ）とから，
必要ヒープサイズ＝活動中ヒープサイズ×Ｋ （式３）
の式で求められる。ここで，ＧＣ直後の必要ヒープサイズは，ＧＣ直後の総生存オブジェクトサイズ（Ｓg ）と同値である。
【００４４】
図４は，本実施の形態における活動中ヒープサイズＳat，必要ヒープサイズＳgt，使用ヒープサイズＳu および指定ヒープサイズＳr の時間変化の例を説明する図である。図中，実線で描かれた曲線は活動中ヒープサイズＳatを示し，波線で描かれた曲線は必要ヒープサイズＳgtを示す。のこぎり型の点線は使用ヒープサイズＳu を示し，上部の実線で描かれた直線は指定ヒープサイズＳr を示す。使用ヒープサイズＳu が指定ヒープサイズＳr に達したときに，ＧＣが実行される。
【００４５】
ＧＣが行われるごとに，ＧＣ直後の活動中ヒープサイズ（Ｓa ）とＧＣ直後の総生存オブジェクトサイズ（Ｓg ）との比からドラッグ係数（Ｋ）が求められ（（式２）参照），その後の各時刻における活動中ヒープサイズＳatにドラッグ係数（Ｋ）を乗じることにより（（式３）参照），各時刻における必要ヒープサイズＳgtが計算される。
【００４６】
ここで，ドラッグ係数（Ｋ）を求める式は（式２）に限らない。例えば，時刻ｔ1 におけるＧＣ直後の活動中ヒープサイズとＧＣ直後の総生存オブジェクトサイズとをそれぞれＳa1，Ｓg1とし，時刻ｔ2 におけるＧＣ直後の活動中ヒープサイズとＧＣ直後の総生存オブジェクトサイズとをそれぞれＳa2，Ｓg2としたとき，時刻ｔn におけるドラッグ係数（Ｋn ）を，
の式で求めることもできる。
【００４７】
図４において，二点破線で示されているのが必要ヒープサイズの最大値であり，この値を最低必要なヒープサイズＳm とする。指定ヒープサイズＳr は，最低必要なヒープサイズＳm まで縮小することが可能である。指定ヒープサイズＳr が最低必要なヒープサイズＳm に近いほどＧＣインターバルが短くなり，頻繁にＧＣが行われるようになる。指定ヒープサイズＳr が最低必要なヒープサイズＳm から遠いほどＧＣインターバルが長くなり，１回のＧＣの開始から終了までの時間が長くなる。
【００４８】
分析処理部２０は，以上の（式２）または（式４）によるドラッグ係数（ＫまたはＫn ）を，オブジェクトの生成点から最終アクセスまでのオブジェクト寿命に乗じることにより，真のオブジェクト寿命を推定する。
【００４９】
図５は，本実施の形態におけるオブジェクトの寿命によるヒープサイズの調整を説明する図である。図５に示すグラフでは，横軸に延べオブジェクトサイズをとり，縦軸にオブジェクトの寿命をとっている。各オブジェクトを寿命の短い順にソートし，オブジェクトの寿命と延べオブジェクトサイズとの関係をプロットしたものが，図５に示す曲線（オブジェクト寿命分布曲線という）である。図５のグラフで一番右側にある“死なないオブジェクト”は，ＧＣで回収されないオブジェクトであり，分析処理部２０によってその寿命を求めることができないため，無視する。
【００５０】
ここで，延べオブジェクトサイズ（以下，単に延べサイズという）は，寿命の短い順に各オブジェクトのサイズを加えていったものである。例えば，
オブジェクトＡ：寿命２０［ｂｙｔｅ］，サイズａ［ｂｙｔｅ］
オブジェクトＢ：寿命２５０［ｂｙｔｅ］，サイズｂ［ｂｙｔｅ］
オブジェクトＣ：寿命４８［ｂｙｔｅ］，サイズｃ［ｂｙｔｅ］
というオブジェクトがあったときに，これらのオブジェクトを寿命の短い順に並べると，オブジェクトＡ，Ｃ，Ｂの順になり，それらの延べオブジェクトサイズは，
オブジェクトＡ：延べサイズａ［ｂｙｔｅ］
オブジェクトＣ：延べサイズａ＋ｃ［ｂｙｔｅ］
オブジェクトＢ：延べサイズａ＋ｃ＋ｂ［ｂｙｔｅ］
となる。
【００５１】
図５のグラフにおいて，中ほどにある縦の太線は，オブジェクト寿命分布曲線上で，オブジェクト寿命がＧＣインターバルの長さになる延べオブジェクトサイズを示し，その太線より左にある（寿命の短い）オブジェクトは２回目のＧＣを経験させずに回収できることを示している。プロファイルされたオブジェクトの総サイズに対する太線の位置の延べサイズの割合を回収可能率という。
【００５２】
ＧＣインターバルを長くとると，図５において太線の位置がより右の位置となり，より寿命の長いオブジェクトも２回目のＧＣを経験させずに回収することができるようになる。１回のＧＣの開始から終了までの時間が長くなるが，ＧＣを行う頻度が低くなるため，スループットが向上する。
【００５３】
ＧＣインターバルを短くとると，図５において太線の位置がより左側の位置となり，回収されるまで２回以上のＧＣを経験するオブジェクトが増えることになる。ＧＣの頻度が高くなるが，１回のＧＣの開始から終了までの時間が短くなるため，応答性能が向上する。
【００５４】
見積り処理部３０は，分析処理部２０でのプロファイル情報の分析結果から，最適な指定ヒープサイズＳr を自動的に見積もる。このとき，最適な指定ヒープサイズを決定する基準は，システムまたはアプリケーション開発者があらかじめ定めておくことができる。また，最適な指定ヒープサイズを決定する基準をアプリケーションのユーザに指定させ，その基準に従って最適な指定ヒープサイズを自動的に見積もってもよい。
【００５５】
例えば，ユーザによる最適な指定ヒープサイズを決定する基準の指定が，ＧＣインターバルを決定するための基準であれば，図５に示すようなオブジェクトの寿命の分布をもとに，最適なタイミングでＧＣを行うためのＧＣインターバル（以下，最適なＧＣインターバルという）を決定する。
【００５６】
次に，決定された最適なＧＣインターバルから，最適な指定ヒープサイズを求める。例えば，プロファイル時のＧＣインターバルの２倍の値が最適なＧＣインターバルであるならば，単純にプロファイル時の指定ヒープサイズを２倍の値に増やしたものが最適な指定ヒープサイズとなる。同様に，プロファイル時のＧＣインターバルの半分が最適なＧＣインターバルであるならば，プロファイル時の指定ヒープサイズの半分が最適な指定ヒープサイズとなる。
【００５７】
ここで，以上の本実施の形態によるヒープサイズの最適化による効果を，前述の非特許文献２との比較により，考察する。
【００５８】
前述の非特許文献２のように，頻繁にＧＣを繰り返してドラッグ時間を短くすることで，
“生成点から到達不能点までの時間”≒“生成点から回収点までの時間”
とし，“生成点から到達不能点までの時間”を近似値で求める方法があるが，頻繁に起動するＧＣは処理的な負担が大きく，極端にスループットを低下させてしまう。それに対し，本発明による実施の形態では，ＧＣの起動回数を必要以上に増加させることはないので極端にスループットが低下することはない。
【００５９】
さらに，オブジェクトプロファイル技術に関しては，前述の非特許文献２では，プロファイル手段として，オブジェクトの生成時やオブジェクトへのアクセス時の情報を，そのオブジェクト内にプロファイル用フィールドを持たせてそこに収集しているため，プロファイル処理がヒープ管理へ影響を与えてしまい，指定ヒープサイズと実際の使用可能なヒープサイズとが異なってしまう。それに対し，本発明による実施の形態では，オブジェクトの生成時やオブジェクトへのアクセス時の情報を，その機会にオブジェクトを識別するためのアドレスとともに別領域へ格納するため，使用可能なヒープサイズに影響を与えずに済む。
【００６０】
また，付加的なプロファイル情報として，メソッド呼出し・復帰に関する情報（図３（Ｂ）におけるｍｅｔｈｏｄ−呼出し，ｍｅｔｈｏｄ−復帰のレコード（レコードＲ７，Ｒ８））を追加することにより，どのメソッドがヒープに負担をかけているかを知ることができる。
【００６１】
図６は，本発明の実施の形態におけるヒープに負担をかけているメソッドの調査を説明する図である。図６（Ａ）は，メソッドによるオブジェクト生成およびメソッドの呼出し・復帰の状況を示す図であり，図６（Ｂ）は，図６（Ａ）における各メソッドとそれらのメソッドが生成するオブジェクトとの関係を時系列で表したものである。メソッドの呼出し時・復帰時のタイムスタンプを記録することにより，どのメソッドがオブジェクトを生成したかを容易に知ることができる。
【００６２】
図６（Ａ）において，メソッドｘｘｘは，オブジェクトＡを生成し，メソッドｙｙｙを呼び出す。メソッドｙｙｙは，オブジェクトＤを生成し，メソッドｚｚｚを呼び出す。メソッドｚｚｚは，オブジェクトＧを生成し，メソッドｙｙｙに復帰する。メソッドｙｙｙは，オブジェクトＥを生成し，メソッドｘｘｘに復帰する。メソッドｘｘｘは，オブジェクトＢを生成し，メソッドｙｙｙ２を呼び出す。メソッドｙｙｙ２は，オブジェクトＦを生成し，メソッドｘｘｘに復帰する。メソッドｘｘｘは，オブジェクトＣを生成する。
【００６３】
このような図６（Ａ）の状況において，スレッド番号，メソッド名とともにメソッド呼出し時・復帰時のタイムスタンプをログに出力することにより図６（Ｂ）のような生成されたオブジェクトの時間的順序を得ることができ，図６（Ｂ）からオブジェクト生成時のメソッドを知ることができる。これにより，どのメソッドがヒープに負担をかけているのかを容易に調査できるようになる。
【００６４】
また，オブジェクトを生成したスレッドの情報（スレッド番号等）と，オブジェクトにアクセスしたスレッドの情報（スレッド番号等）とを，ログに記録することにより，そのオブジェクトがスレッドローカルなオブジェクトであるか，スレッドグローバルなオブジェクトであるかを知ることができる。
【００６５】
以下，図１に示すヒープサイズ自動最適化装置１の構成および動作をさらに詳しく説明する。
【００６６】
図７は，本実施の形態におけるロギング処理を示す図である。ロギング処理部１０のプロファイル情報ロギングルーチン１１は，Ｊａｖａスレッド１００上でメソッドの呼出し・復帰が行われたとき（ステップＳ１０１），オブジェクトが生成されたとき（ステップＳ１０２），オブジェクトの参照・更新（オブジェクトへのアクセス）があったとき（ステップＳ１０３）に，図３（Ｂ）に示すデータレコード形式でレコードをログに記録し，そのログをプロファイル情報格納域４０に出力する。
【００６７】
Ｊａｖａスレッド１００上でオブジェクトが生成されるとき（ステップＳ１０２）に，ヒープが不足したならば（ステップＳ１０４），ＧＣを起動する。
【００６８】
プロファイル情報ロギングルーチン１１は，ＧＣスレッド１１０上でＧＣが開始されたとき（ステップＳ１１１），ＧＣにおいて生存オブジェクトが確認されたとき（ステップＳ１１２），ＧＣが終了したとき（ステップＳ１１３）に，それぞれ図３（Ｂ）に示すデータレコード形式でレコードをログに記録し，そのログをプロファイル情報格納域４０に出力する。
【００６９】
ここで，プロファイル情報格納域４０が保有する情報量を小さくするために，プロファイル情報（ログに記録するレコード）を間引くことも可能である。例えば，アドレスをキーにして公平にサンプリングすることができるように，
（（Ｒａｔｉｏ＞９９‖Ｒａｔｉｏ＜１）‖
（ｉｎｔ（（ａｄｄｒ＋１）×Ｒａｔｉｏ／１００）
−ｉｎｔ（ａｄｄｒ×Ｒａｔｉｏ／１００）） （式５）
の式が成立つときにロギングするようにすればよい。（式５）において，“‖”は，ｏｒを示す。ｉｎｔ（Ｘ）は，Ｘの整数部分を表す。ａｄｄｒはオブジェクトのアドレスを表し，Ｒａｔｉｏは，何％の割合でレコードをロギングするかの比を表す。例えば，Ｒａｔｉｏ＝５０（％）のとき，２回に１回の割合でレコードがロギングされることになる。Ｒａｔｉｏ＝３０（％）なら，１０回に３回の割合でレコードがロギングされる。
【００７０】
また，システムを起動したときから常時すべてのプロファイル情報を採取するのではなく，ある期間のみ採取するようにしてもよい。実際にプロファイルを常時行うことにより得られるレコードの量は膨大なものであり，すべてを蓄積することは困難である。したがって，ある一定期間に限ってプロファイルを行う機能を設けることが望ましい。そこで，例えばプロファイル開始／終了コマンドにより，プロファイル情報の採取期間を指定することができるようにする。
【００７１】
図８に，アプリケーション実行途中からプロファイルを開始するときの例を示す。アプリケーション実行中の途中からプロファイルを開始するときには，プロファイルの開始時点において使用ヒープサイズＳu や必要ヒープサイズの初期値Ｓg0を把握する必要がある。そこで，プロファイル開始時には，強制的にＧＣを起動する。これにより，ロギング開始以前に生成されていたオブジェクトの総サイズがわかる。その後，プロファイル終了までの間に生成／回収されたオブジェクトに関してプロファイル情報を収集する。プロファイル開始時と同様に，プロファイル終了時にも強制的にＧＣを起動する。これによって，必要ヒープサイズＳgtを逆算できるようになり，採取期間の前後の状態によらずに，ロギング開始から終了までの間の必要ヒープサイズＳgtを求めることが可能になる。
【００７２】
なお，図３では説明を省略したが，プロファイルをアプリケーションの実行途中で開始し実行途中で終了する場合には，そのプロファイル期間の開始時および終了時に，プロファイル−開始（レコードＲ９），プロファイル−終了（レコードＲ１０）のレコードをタイムスタンプ等の情報を付加してログに記録する。
【００７３】
ロギング処理部１０が収集したプロファイル情報には，１つのオブジェクトについてオブジェクトの生成，オブジェクトのアクセス等，複数のレコードが存在する。そこで，それらの情報をオブジェクトごとにまとめるために，分析処理部２０において，データ整理部２１は，オブジェクトごとにその情報を格納するためのｏｂｊ構造体を用意する。そして，プロファイル情報格納域４０からログを取得し，そのログからレコードを取り出して該当するオブジェクトのｏｂｊ構造体に記録し，そのｏｂｊ構造体をオブジェクト情報格納域５０に格納する。ここで，ｏｂｊ構造体が持つ情報をオブジェクト情報という。
【００７４】
図９は，本実施の形態におけるデータ整理部２１の処理を示す図である。図９（Ａ）はデータ整理処理の流れを示し，図９（Ｂ）はｏｂｊ構造体の例を示す。図９（Ｃ）はオブジェクト生成時，オブジェクトアクセス時，ＧＣ時に更新されるｏｂｊ構造体のデータ部のメンバを示す。図９（Ｄ）はｏｂｊ構造体の推移を示す。
【００７５】
データ整理部２１は，図９（Ａ）に示すように，プロファイル情報格納域４０に格納されているレコードが終了するまで（ステップＳ２０２），プロファイル情報格納域４０に格納されたログから，１レコードを取り出す処理（ステップＳ２００）と，取り出したレコードに対する処理とを繰り返す（ステップＳ２０１）。
【００７６】
図９（Ａ）のステップＳ２０１におけるレコードに対する処理において，オブジェクトごとにプロファイル情報を整理するために，オブジェクトごとに図９（Ｂ）に示すようなｏｂｊ構造体が用意される。図９（Ｂ）の例のｏｂｊ構造体において，ヘッダ部の“ｌｅｆｔ”，“ｒｉｇｈｔ”，“ｐａｒｅｎｔ”，“ｂａｌａｎｃｅ”は，常にバランスの取れた２分木（ＡＶＬバランス木）を構成するための情報である。
【００７７】
データ部において，“ａｄｄｒ”はオブジェクトのアドレスを示し，“ｓｉｚｅ”はオブジェクトのサイズを示し，“ｎｅｗ＿ｔｈｒｅａｄ”はオブジェクトを生成したスレッドを示す。“ｎｅｗ＿ｔｉｍｅ”はオブジェクトが生成された時刻を示し，“ｌａｓｔ＿ｔｉｍｅ”はオブジェクトへの最終アクセスの時刻を示す。“ａｇｅ”はオブジェクトが経験したＧＣの回数を示す。“ｉｓ＿ｇｌｏｂａｌ”はオブジェクトにアクセスしたスレッドがオブジェクトを生成したスレッドと違うかどうか（スレッドスコープ）を示す。
【００７８】
図９（Ｃ）に示すように，ｏｂｊ構造体のうち，オブジェクト生成時（ｎｅｗ）に更新されるメンバは“ａｄｄｒ”，“ｓｉｚｅ”，“ｎｅｗ＿ｔｈｒｅａｄ”，“ｎｅｗ＿ｔｉｍｅ”である。また，オブジェクトアクセス時（ａｃｃ）に更新されるメンバは“ｌａｓｔ＿ｔｉｍｅ”，“ｉｓ＿ｇｌｏｂａｌ”である。ＧＣ時（ＧＣ）に更新されるメンバは“ａｇｅ”である。
【００７９】
図９（Ｄ）に示すように，ｏｂｊ構造体は，“生存オブジェクト”，“ＧＣ待ちオブジェクト”，“回収済オブジェクト”の３つの状態を推移し，各ｏｂｊ構造体は，「生存オブジェクト集合」，「ＧＣ待ちオブジェクト集合」，「回収済オブジェクト集合」の３つの集合のいずれかの状態にある。
【００８０】
以下，図９（Ａ）のステップＳ２０１におけるレコード処理について，その例を説明する。ここでは，図３（Ｂ）に示すレコードごとに説明する。
【００８１】
レコードＲ１（ｏｂｊ−生成）の場合：
(1) プロファイル情報格納域４０のログからｏｂｊ−生成時のレコード（アドレス，サイズ，スレッド番号，タイムスタンプ）を取り出す。
(2) 「回収済オブジェクト集合」から空のｏｂｊ構造体を１つ取り出す。空のｏｂｊ構造体がない場合には，新規に用意する。
(3) 取り出した空のｏｂｊ構造体に“ａｄｄｒ”，“ｓｉｚｅ”，“ｎｅｗ＿ｔｈｒｅａｄ”，“ｎｅｗ＿ｔｉｍｅ”を設定し，そのｏｂｊ構造体を「生存オブジェクト集合」に登録する。
【００８２】
レコードＲ２（ｏｂｊ−アクセス）の場合：
(1) プロファイル情報格納域４０のログからｏｂｊ−アクセス時のレコード（アドレス，サイズ，スレッド番号，タイムスタンプ）を取り出す。
(2) 「生存オブジェクト集合」から該当するｏｂｊ構造体を取り出す。
(3) ｏｂｊ構造体の“ｌａｓｔ＿ｔｉｍｅ”を更新し，取り出されたレコードのスレッド番号がオブジェクト生成時のスレッド番号である“ｎｅｗ＿ｔｈｒｅａｄ”と異なる場合には，“ｉｓ＿ｇｌｏｂａｌ”に「真」を設定する。取り出されたレコードのスレッド番号が匿名番号であった場合には，“ｉｓ＿ｇｌｏｂａｌ”は更新せず，“ｎｅｗ＿ｔｈｒｅａｄ”を更新する。
【００８３】
レコードＲ３（ＧＣ−開始）の場合：
(1) プロファイル情報格納域４０のログからＧＣ−開始のレコード（タイムスタンプ）を取り出し，オブジェクト情報格納域５０に出力する。
(2) 「生存オブジェクト集合」の全ｏｂｊ構造体を「ＧＣ待ちオブジェクト集合」に移す。
【００８４】
レコードＲ４，Ｒ５（ｏｂｊ−生存（移動時），ｏｂｊ−生存）の場合：
(1) プロファイル情報格納域４０のログからｏｂｊ−生存（移動時）のレコード（移動元アドレス，移動先アドレス，サイズ）またはｏｂｊ−生存のレコード（アドレス，サイズ）を取り出す。
(2) 「ＧＣ待ちオブジェクト集合」から該当するｏｂｊ構造体を取り出し，“ａｇｅ”に１を加えて，そのｏｂｊ構造体を「生存オブジェクト集合」に登録する。プロファイル開始時のＧＣでは，「生存オブジェクト集合」にｏｂｊ構造体が存在しないため，「回収済オブジェクト集合」から空のｏｂｊ構造体を１つ取り出し（空のｏｂｊ構造体がない場合には，新規に用意し），“ｎｅｗ＿ｔｉｍｅ”にプロファイルの開始時刻を，“ｎｅｗ＿ｔｈｒｅａｄ”に匿名番号を設定し，取り出されたレコードにより“ａｄｄｒ”，“ｓｉｚｅ”を設定し，そのｏｂｊ構造体を「生存オブジェクト集合」に登録する。
【００８５】
レコードＲ６（ＧＣ−終了）の場合：
(1) プロファイル情報格納域４０のログからＧＣ−終了のレコード（タイムスタンプ，ＧＣ直後の使用ヒープサイズ）を取り出し，オブジェクト情報格納域５０に出力する。
(2) 「ＧＣ待ちオブジェクト集合」に残ったすべてのｏｂｊ構造体が持つオブジェクト情報を，オブジェクト情報格納域５０に出力する。
(3) オブジェクト情報格納域５０にオブジェクト情報を出力したｏｂｊ構造体を，「回収済オブジェクト集合」に移し，再利用可能にしておく。
【００８６】
レコードＲ７（ｍｅｔｈｏｄ−呼出し）の場合：
(1) プロファイル情報格納域４０のログからｍｅｔｈｏｄ−呼出しのレコード（スレッド番号，タイムスタンプ，メソッド名）を取り出し，オブジェクト情報格納域５０に出力する。
【００８７】
レコードＲ８（ｍｅｔｈｏｄ−復帰）の場合：
(1) プロファイル情報格納域４０のログからｍｅｔｈｏｄ−復帰のレコード（スレッド番号，タイムスタンプ，メソッド名）を取り出し，オブジェクト情報格納域５０に出力する。
【００８８】
分析処理部２０において，ソート部２２は，オブジェクト情報格納域５０から，オブジェクトごとに整理されたオブジェクト情報（“ａｄｄｒ”，“ｓｉｚｅ”，“ｎｅｗ＿ｔｈｒｅａｄ”，“ｎｅｗ＿ｔｉｍｅ”，“ｌａｓｔ＿ｔｉｍｅ”，“ａｇｅ”，“ｉｓ＿ｇｌｏｂａｌ”等）を入力し，それらのオブジェクト情報を様々な条件でソートすることにより，必要ヒープサイズの推移やオブジェクト寿命の特性などをプロファイルする。
【００８９】
図１０は，本実施の形態におけるオブジェクト情報の例を示す図である。各ｏｂｊ構造体は，オブジェクトごとに整理された“ａｄｄｒ”，“ｓｉｚｅ”，“ｎｅｗ＿ｔｈｒｅａｄ”，“ｎｅｗ＿ｔｉｍｅ”，“ｌａｓｔ＿ｔｉｍｅ”，“ａｇｅ”，“ｉｓ＿ｇｌｏｂａｌ”のオブジェクト情報を持っている。以下，この図１０の例に示す３つオブジェクトのオブジェクト情報をソートする例を説明する。
【００９０】
図１１は，本実施の形態における使用ヒープサイズおよび活動中ヒープサイズの推移を調査するためのソート例を示す図である。
【００９１】
まず，ソートする前に，図１０の各オブジェクト情報を図１１（Ａ）のように生成時の情報と最終アクセス時の情報の２つのレコードに分ける。図１１（Ａ）において，ａｄｄｒ欄にはオブジェクト情報の“ａｄｄｒ”を記録する。ｔｉｍｅ欄には，生成時の情報の場合にはオブジェクト情報の“ｎｅｗ＿ｔｉｍｅ”を，最終アクセス時の場合にはオブジェクト情報の“ｌａｓｔ＿ｔｉｍｅ”を記録する。ｔｏｔａｌ’欄は使用ヒープサイズを求めるための情報の記録欄であり，生成時の情報の場合にはオブジェクト情報の“ｓｉｚｅ”を，最終アクセス時の場合には０を記録する。ｍａｘ’欄は活動中ヒープサイズを求めるための情報の記録欄であり，生成時の情報の場合にはオブジェクト情報の“ｓｉｚｅ”を，最終アクセス時の場合にはオブジェクト情報の“ｓｉｚｅ”の符号をマイナスにしたものを記録する。
【００９２】
図１１（Ｂ）は，図１１（Ａ）をｔｉｍｅ欄の値が昇順になるようにソートした結果を示している。図１１（Ｃ）は，図１１（Ｂ）のｔｏｔａｌ’欄とｍａｘ’欄とについて時系列順に計上したものを，それぞれｔｏｔａｌ欄とｍａｘ欄に記録したものである。図１１（Ｃ）において，ｔｏｔａｌ欄は使用ヒープサイズの推移を示し，ｍａｘ欄は，活動中ヒープサイズの推移を示している。
【００９３】
ここで，図１１（Ｃ）の例には記録されていないが，途中でＧＣが発生したときには，使用ヒープサイズ（ｔｏｔａｌ）から回収されたオブジェクトサイズ分を差し引くか，または，ＧＣ直後の使用ヒープサイズにリセットする。オブジェクト情報格納域５０に格納されたＧＣ開始時・終了時のタイムスタンプのデータを，図１１（Ａ）〜（Ｃ）中でソートするデータとして盛り込んでもよい。
【００９４】
以上の使用ヒープサイズ，活動中ヒープサイズ等の推移の情報は，必要ヒープサイズデータ６０に記録される。また，図１１（Ｃ）において，各活動中ヒープサイズの値（ｍａｘ欄の値）に，前述のドラッグ係数（Ｋ，Ｋn ）を乗じることにより，必要ヒープサイズの推移を確認することができる。このようにして得られた必要ヒープサイズの推移の情報を，使用ヒープサイズ，活動中ヒープサイズ等の推移の情報とともに必要ヒープサイズデータ６０に記録してもよい。
【００９５】
このとき，データ量を削減するために，複数レコードの中から代表するレコードのみを出力することも可能である。例えば，データ量を１／１０に圧縮したいならば，時系列に並ぶ１０レコードのうち必要ヒープサイズが最も大きいレコードのみを出力すればよい。圧縮比率は，必要ヒープサイズデータ６０のサイズによって自由に変えることができる。
【００９６】
図１２は，本実施の形態におけるオブジェクト寿命特性を得るためのソート例を示す図である。ａｄｄｒ欄にはオブジェクト情報の“ａｄｄｒ”が記録され，ｓｉｚｅ欄にはオブジェクト情報の“ｓｉｚｅ”が記録される。ｌｏｎｇｅｖｉｔｙ欄はオブジェクト寿命の記録欄であり，オブジェクト情報の“ｎｅｗ＿ｔｉｍｅ”と“ｌａｓｔ＿ｔｉｍｅ”との差が記録される。図１２では，ｌｏｎｇｅｖｉｔｙ欄が昇順になるようにソートされている。
【００９７】
図１２において，各オブジェクト寿命の値（ｌｏｎｇｅｖｉｔｙ欄の値）に，前述のドラッグ係数（Ｋ，Ｋn ）を乗じることにより，各オブジェクトの真のオブジェクト寿命を得ることができる。各オブジェクトのオブジェクト寿命と真のオブジェクト寿命とは，オブジェクト寿命特性７０に記録される。このとき，オブジェクト寿命または真のオブジェクト寿命のいずれか一つを記録するようにしてもよい。
【００９８】
このとき，データ量を削減するために，複数レコードの中から代表する１レコードのみを出力することも可能である。例えば，データ量を１／１０に圧縮したいならば，寿命が短い順に１０レコード目のレコードのみを出力すればよい。このようにすれば，隣り合ったレコードの寿命長が近い値であるため，等間隔で間引くことができる。圧縮比率は，オブジェクト寿命特性７０のサイズによって自由に変えることができる。
【００９９】
以上の図１１，図１２の例では，オブジェクト情報のうち“ｎｅｗ＿ｔｈｒｅａｄ”，“ａｇｅ”，“ｉｓ＿ｇｌｏｂａｌ”のデータを使用していないが，これらのデータは別の観点でのオブジェクトの傾向を掴む場合に使用する。また，オブジェクト情報格納域５０に格納されたメソッド呼出し時・復帰時のスレッド番号，タイムスタンプ，メソッド名等のデータも使用していないが，これらのデータも別の観点での傾向を掴む場合に使用する。必要なときには，これらのデータもソートするデータとして盛り込むことが可能である。
【０１００】
分析処理部２０において，可視化部２３は，必要ヒープサイズデータ６０，オブジェクト寿命特性７０を入力し，それぞれを表計算ソフトウェアなどで用いられている手法を利用してグラフ化する。必要ヒープサイズデータ６０から必要／使用ヒープサイズのグラフ８０が作成され，オブジェクト寿命特性７０からオブジェクト寿命分布のグラフ９０が作成される。このとき，グラフ化を容易にするため，必要な情報が損なわれない範囲内で，データ量（レコード数）を削減してもよい。
【０１０１】
図１３は，本実施の形態における必要／使用ヒープサイズのグラフの例を示す図である。図１３では，使用ヒープサイズと必要ヒープサイズの推移がグラフ化されているが，それに限らない。例えば，使用ヒープサイズと活動中ヒープサイズの推移をグラフ化してもよいし，使用ヒープサイズと活動中ヒープサイズと必要ヒープサイズの推移をグラフ化してもよい。また，図１３の例では時間の尺度として延べ割当て量（延べ割当サイズ）［Ｍｂｙｔｅ］が用いられているが，実際の時間［秒］を用いてもよい。
【０１０２】
図１３において，使用ヒープサイズの頂点が指定ヒープサイズであり，そこに使用ヒープサイズが達するとＧＣが実行される。この図では，８［Ｍｂｙｔｅ］ぐらいに指定ヒープサイズが設定されている。
【０１０３】
図１４は，本実施の形態におけるオブジェクト寿命分布のグラフの例（１）を示す図である。各オブジェクトが寿命長でソートされ，寿命が短い順に，オブジェクトの延べサイズと寿命との関係がプロットされている。図１４の例では，寿命の尺度として延べ割当サイズ［Ｍｂｙｔｅ］が用いられているが，実際の時間［秒］を用いてもよい。また，オブジェクトの寿命としては，オブジェクト寿命を用いてもよいし，真のオブジェクト寿命を用いてもよい。
【０１０４】
図１５は，本実施の形態におけるオブジェクト寿命分布のグラフの例（２）を示す図である。図１５のグラフは，図１４のグラフを視覚的に分かりやすくするために，縦軸を対数目盛りにしたものである。延べサイズが４［Ｍｂｙｔｅ］以上のデータのみをプロットしている。縦軸を対数目盛りで表示するか否かは，メニューなどにより選択することができる。
【０１０５】
見積り処理部３０は，分析処理部２０で得られたプロファイル情報の分析結果から，最低必要なヒープサイズ（Ｓm ），プロファイル時のＧＣインターバル（Ｉr ），最適なＧＣインターバル（Ｉi ）を求め，それらの求められた値とプロファイル時の指定ヒープサイズ（Ｓr ）とから最適な指定ヒープサイズ（Ｓi ）を自動的に見積もる。
【０１０６】
図１６は，本実施の形態における見積り処理フローチャートである。図１６の例は，最適な指定ヒープサイズを決定する基準が回収可能率で指定された場合の例である。
【０１０７】
まず，必要ヒープサイズデータ６０から，必要ヒープサイズの最大値である最低必要なヒープサイズ（Ｓm ）を求める（ステップＳ３０１）。このとき，例えば，各時刻の活動中ヒープサイズにドラッグ係数（Ｋ，Ｋn ）を乗じて得られた必要ヒープサイズが必要ヒープサイズデータ６０に記録されていれば，その最大値を最低必要なヒープサイズ（Ｓm ）とし，必要ヒープサイズが必要ヒープサイズデータ６０に記録されていなければ，活動中ヒープサイズの最大値にドラッグ係数（Ｋ，Ｋn ）を乗じて得られた値を最低必要なヒープサイズ（Ｓm ）とする。
【０１０８】
次に，オブジェクト情報格納域５０に格納されているＧＣ開始時・終了時のタイムスタンプから，プロファイル時のＧＣインターバル（Ｉr ）を求める（ステップＳ３０２）。このとき，例えば，プロファイル期間中のＧＣインターバルの平均値などを求め，それをプロファイル時のＧＣインターバル（Ｉr ）とすればよい。
【０１０９】
次に，ユーザから指定された最適な指定ヒープサイズを決定する基準と，オブジェクト寿命特性７０とから，最適なＧＣインターバル（Ｉi ）を求める（ステップＳ３０３）。
【０１１０】
例えば，ユーザから指定された回収可能率が８０％（寿命の短いオブジェクトから延べサイズで８０％のオブジェクトが２回目のＧＣを経験しない）であったなら，オブジェクト寿命特性７０で寿命が短いオブジェクトから延べサイズで８０％目にあたるオブジェクトのデータを抽出し，そのオブジェクトの寿命長を最適なＧＣインターバル（Ｉi ）とする。
【０１１１】
このとき，例えば，各オブジェクトのオブジェクト寿命にドラッグ係数（Ｋ，Ｋn ）を乗じて得られた真のオブジェクト寿命がオブジェクト寿命特性７０に記録されていれば，寿命が短いオブジェクトから延べサイズで８０％目に当たるオブジェクトの真のオブジェクト寿命を最適なＧＣインターバル（Ｉi ）とし，真のオブジェクト寿命がオブジェクト寿命特性７０に記録されていなければ，寿命が短いオブジェクトから延べサイズで８０％目にあたるオブジェクトのオブジェクト寿命にドラッグ係数（Ｋ，Ｋn ）を乗じて得られた値を最適なＧＣインターバル（Ｉi ）とすればよい。
【０１１２】
次に，プロファイル時の指定ヒープサイズ（Ｓr ）と，ステップＳ３０２で求めたプロファイル時のＧＣインターバル（Ｉr ）と，ステップＳ３０３で求めた最適なＧＣインターバル（Ｉi ）とから，
Ｓi ＝Ｓr ×Ｉi ／Ｉr （式６）
の式で，最適な指定ヒープサイズ（Ｓi ）を求める（ステップＳ３０４）。ここで，プロファイル時の指定ヒープサイズ（Ｓr ）に関しては，予めプロファイル時にその値を記録しておけばよい。
【０１１３】
ステップＳ３０１で求めた最低必要なヒープサイズ（Ｓm ）よりステップＳ３０４で求めた最適な指定ヒープサイズ（Ｓi ）の方が小さければ（ステップＳ３０５），ステップＳ３０１で求めた最低必要なヒープサイズ（Ｓm ）を最適な指定ヒープサイズ（Ｓi ）とする（ステップＳ３０６）。そうでなければ，ステップＳ３０４で求めたＳi を最適な指定ヒープサイズとする。
【０１１４】
本実施の形態におけるヒープサイズ自動最適化装置１により得られた情報は，ディスプレイ等により，ユーザに提示される。以下，ユーザに情報を提示する画面の例を図面を用いて説明する。
【０１１５】
図１７は，本実施の形態におけるユーザ提示する情報のメニュー画面の例を示す。図１７のメニュー画面では，最適ヒープサイズ，プロファイルデータ，オブジェクトデータ，オブジェクトリスト，メソッドリストの各メニュー項目ボタンから表示したい情報を選択することができる。
【０１１６】
図１８は，本実施の形態における最適ヒープサイズ画面の例を示す図である。図１８において，必要／使用ヒープサイズの部分（画面左側上部）には，そのグラフ８０と必要ヒープサイズデータ６０とが表示されている。また，オブジェクト寿命分布の部分（画面左側下部）には，そのグラフ９０とオブジェクト寿命特性７０が表示されている。ここで，必要ヒープサイズデータ６０やオブジェクト寿命特性７０のデータを選択することにより，必要／使用ヒープサイズのグラフやオブジェクト寿命分布のグラフの選択されたデータに該当する部分に敷居線を表示させることができる。
【０１１７】
画面の右側中央部は，ユーザが最適な指定ヒープサイズを決定する基準を指定する部分であり，選択された基準によって自動的に見積もられた最適な指定ヒープサイズの値が，右側下部の最適ヒープサイズの部分に表示される。
【０１１８】
最適な指定ヒープサイズを決定する基準を指定する部分において，「最大ＧＣ期待回数」を選択すると，すべてのオブジェクトに指定された回数を越えたＧＣを経験させないように最適なＧＣインターバルが決定され，それをもとに最適な指定ヒープサイズが自動的に見積もられる。
【０１１９】
最適な指定ヒープサイズを決定する基準を指定する部分において，「最低ヒープサイズ」を選択すると，最低必要なヒープサイズが最適な指定ヒープサイズであるとして自動的に見積もられる。
【０１２０】
最適な指定ヒープサイズを決定する基準を指定する部分において，「推奨ヒープサイズ」を選択すると，スループットと応答性能とのバランスがよい状態になるようにシステムが予め定めた最適な指定ヒープサイズを自動的に見積もる。ここでは，大半のオブジェクト（例えば９０％）のオブジェクトが１回だけＧＣを経験するような指定ヒープサイズになるように，見積り値が決定される。
【０１２１】
最適な指定ヒープサイズを決定する基準を指定する部分において，「スループット重視」を選択すると，スループットを重視して最適な指定ヒープサイズを見積もる。例えば，指定されたレベルのスループットを実現するのに最適なＧＣインターバルが決定され，それをもとに最適な指定ヒープサイズが自動的に見積もられる。
【０１２２】
最適な指定ヒープサイズを決定する基準を指定する部分において，「レスポンス重視」を選択すると，レスポンス（応答性能）を重視して最適な指定ヒープサイズを見積もる。例えば，指定されたレベルのレスポンスを実現するのに最適なＧＣインターバルが決定され，それをもとに最適な指定ヒープサイズが自動的に見積もられる。
【０１２３】
図１９は，本実施の形態におけるプロファイルデータ画面の例を示す図である。図１９に示す画面において，１行目から２３行目まではオブジェクト生成時，オブジェクトアクセス時のプロファイルデータ（プロファイル情報）の例であり，２４行目はＧＣ開始時のプロファイルデータの例であり，２５行目から２９行目がＧＣ後も生存するオブジェクトのプロファイルデータの例である。一番左の番号は，レコードを識別するために順に振られた番号である。図１９では，時刻は延べ割当てサイズで記載されている。
【０１２４】
１行目から２３行目において，左から２列目のデータはそのレコードが何のレコードであるかを示し，図１９の例では，“ｎｅｗ”がオブジェクト生成時のレコードであることを示し，“ｐｕｔｆｉｅｌｄ”，“ｇｅｔｆｉｅｌｄ”がオブジェクトアクセス（更新／参照）時のレコードであることを示す。次のコロンに続くデータは，オブジェクトのアドレスを示し，括弧内はオブジェクトのサイズを示す。次のデータは，オブジェクト生成時，オブジェクトアクセス時のスレッド番号であり，一番右側のデータはタイムスタンプである。
【０１２５】
２４行目において，左から２列目のデータはＧＣが開始されたことを示す。左から３列目のデータは，ＧＣ開始時のタイムスタンプを示す。２５行目から２９行目において，左から２列目のデータ（“ｍｏｖｅ”）は，ＧＣ後も生存するオブジェクトの移動を示し，次のコロンに続くデータは移動元アドレスを，一番右側のデータは移動先アドレスを示す。
【０１２６】
図２０は，本実施の形態におけるオブジェクトデータ画面の例を示す図である。図２０において，オブジェクトごとのオブジェクトデータ（オブジェクト情報）は，オブジェクト番号で識別される。また，オブジェクトごとに，サイズ（“ｓｉｚｅ”に該当），スレッドＩＤ（“ｎｅｗ＿ｔｈｒｅａｄ”に該当），生成時刻（“ｎｅｗ＿ｔｉｍｅ”に該当），最終アクセス時刻（“ｌａｓｔ＿ｔｉｍｅ”に該当），寿命，ＧＣ経験数（“ａｇｅ”に該当），スコープ（“ｉｓ＿ｇｌｏｂａｌ”に該当），オブジェクト名のデータを持つ。
【０１２７】
ここで，スコープ（“ｉｓ＿ｇｌｏｂａｌ”に該当）欄において，“Ｌ”はスレッドローカルを示し，“Ｇ”は，スレッドグローバルを示す。このデータから，そのオブジェクトがスレッドローカルなオブジェクトであるか，スレッドグローバルなオブジェクトであるかを容易に知ることができる。
【０１２８】
図２１は，本実施の形態におけるオブジェクトリスト画面の例を示す図である。図２１において，画面左部分が用意されているクラスのリストであり，そのリストからクラスを選択することによって，そのクラスから生成された（インスタンス化された）オブジェクトを知ることができる。画面右部分が，選択されたクラスから生成されたオブジェクトのリストを表示する部分である。
【０１２９】
図２２は，本実施の形態におけるメソッドリスト画面の例を示す図である。図２２において，画面左部分が用意されているメソッドのリスト部分であり，そのリストからメソッドを選択することにより，そのメソッドによって生成されたオブジェクト，そのメソッドによってアクセスされたオブジェクトを知ることができる。
【０１３０】
図２２において，画面右側上部分が選択されたメソッドにより生成されたオブジェクトのリストを表示する部分であり，画面右側下部分が選択されたメソッドによりアクセスされたオブジェクトのリストを表示する部分である。これらのデータから，どのメソッドがヒープに負担をかけているかを容易に知ることができる。
【０１３１】
以上の本実施の形態の特徴を列挙すると，以下の通りとなる。
【０１３２】
（付記１）ガベージコレクションを実装するコンピュータシステムにおけるヒープサイズ自動最適化処理方法であって，
少なくともオブジェクトの生成時，オブジェクトのアクセス時およびガベージコレクション時に，オブジェクトの寿命を算出するための，生成したオブジェクトまたは生存しているオブジェクトの識別情報，サイズ情報または時間情報に関するプロファイルデータを収集し記録する第１の過程と，
前記記録されたプロファイルデータを分析し，各オブジェクトの寿命を算出するとともに，生存するオブジェクトのサイズを積算することにより，各時点における必要ヒープサイズを算出する第２の過程と，
前記第２の過程で算出した各オブジェクトの寿命に関する寿命特性および必要ヒープサイズの情報をもとに，スループット性能および応答性能のバランスから予め定められた基準またはオペレータから指定された基準に基づいて目的とするヒープサイズを決定する第３の過程とを有する
ことを特徴とするヒープサイズ自動最適化処理方法。
【０１３３】
（付記２）付記１に記載のヒープサイズ自動最適化処理方法において，
メソッドの呼出し時およびメソッドの復帰時のプロファイルデータを収集し記録する第４の過程と，
前記第１の過程と前記第４の過程によって記録されたプロファイルデータをもとに，各メソッドが生成するオブジェクトおよび各メソッドがアクセスするオブジェクトに関する情報を生成し出力する第５の過程とを有する
ことを特徴とするヒープサイズ自動最適化処理方法。
【０１３４】
（付記３）付記１または付記２記載のヒープサイズ自動最適化処理方法において，
前記第１の過程のオブジェクト生成時のプロファイルデータとして，オブジェクトを生成したスレッドのスレッド番号を記録し，かつオブジェクトアクセス時のプロファイルデータとして，オブジェクトにアクセスしたスレッドのスレッド番号を記録し，
前記オブジェクトを生成したスレッドのスレッド番号と，前記オブジェクトにアクセスしたスレッドのスレッド番号とから，各オブジェクトがスレッドローカルなオブジェクトであるかスレッドグローバルなオブジェクトであるかを示す情報を生成する過程を有する
ことを特徴とするヒープサイズ自動最適化処理方法。
【０１３５】
（付記４）付記１から付記３までのいずれかに記載のヒープサイズ自動最適化処理方法において，
前記第２の過程における分析では，前記記録されたプロファイルデータから，各オブジェクトごとに１つのオブジェクト構造体を割り当て，同じオブジェクトに関する複数のデータを１つのデータにまとめて処理する
ことを特徴とするヒープサイズ自動最適化処理方法。
【０１３６】
（付記５） 付記１から付記４までのいずれかに記載のヒープサイズ自動最適化処理方法において，
前記第１の過程によるプロファイルデータの収集の開始および終了を指示する過程と，
プロファイルデータの収集の開始および終了の際に，ガベージコレクションを起動する過程とを有する
ことを特徴とするヒープサイズ自動最適化処理方法。
【０１３７】
（付記６）ガベージコレクションを実装するコンピュータシステムにおけるヒープサイズ自動最適化装置であって，
少なくともオブジェクトの生成時，オブジェクトのアクセス時およびガベージコレクション時に，オブジェクトの寿命を算出するための，生成したオブジェクトまたは生存しているオブジェクトの識別情報，サイズ情報または時間情報に関するプロファイルデータを収集し記録するロギング処理部と，
前記記録されたプロファイルデータを分析し，各オブジェクトの寿命を算出するとともに，生存するオブジェクトのサイズを積算することにより，各時点における必要ヒープサイズを算出する分析処理部と，
前記分析処理部で算出した各オブジェクトの寿命に関する寿命特性および必要ヒープサイズの情報をもとに，スループット性能および応答性能のバランスから予め定められた基準またはオペレータから指定された基準に基づいて目的とするヒープサイズを決定する見積り処理部とを備える
ことを特徴とするヒープサイズ自動最適化装置。
【０１３８】
（付記７）ガベージコレクションを実装するコンピュータシステムにおけるヒープサイズ自動最適化処理方法をコンピュータに実行させるためのプログラムであって，
少なくともオブジェクトの生成時，オブジェクトのアクセス時およびガベージコレクション時に，オブジェクトの寿命を算出するための，生成したオブジェクトまたは生存しているオブジェクトの識別情報，サイズ情報または時間情報に関するプロファイルデータを収集し記録する処理と，
前記記録されたプロファイルデータを分析し，各オブジェクトの寿命を算出するとともに，生存するオブジェクトのサイズを積算することにより，各時点における必要ヒープサイズを算出する処理と，
前記算出した各オブジェクトの寿命に関する寿命特性および必要ヒープサイズの情報をもとに，スループット性能および応答性能のバランスから予め定められた基準またはオペレータから指定された基準に基づいて目的とするヒープサイズを決定する処理とを，
コンピュータに実行させるためのヒープサイズ自動最適化プログラム。
【０１３９】
（付記８）ガベージコレクションを実装するコンピュータシステムにおけるヒープサイズ自動最適化処理方法をコンピュータに実行させるためのプログラムを記録した記録媒体であって，
少なくともオブジェクトの生成時，オブジェクトのアクセス時およびガベージコレクション時に，オブジェクトの寿命を算出するための，生成したオブジェクトまたは生存しているオブジェクトの識別情報，サイズ情報または時間情報に関するプロファイルデータを収集し記録する処理と，
前記記録されたプロファイルデータを分析し，各オブジェクトの寿命を算出するとともに，生存するオブジェクトのサイズを積算することにより，各時点における必要ヒープサイズを算出する処理と，
前記算出した各オブジェクトの寿命に関する寿命特性および必要ヒープサイズの情報をもとに，スループット性能および応答性能のバランスから予め定められた基準またはオペレータから指定された基準に基づいて目的とするヒープサイズを決定する処理とを，
コンピュータに実行させるためのプログラムを記録したことを特徴とするヒープサイズ自動最適化プログラムの記録媒体。
【０１４０】
【発明の効果】
以上説明したように，本発明によって，ＧＣを実装するコンピュータシステムにおいて任意のアプリケーションを実行するときに，オブジェクトの寿命をプロファイル分析することにより，ＧＣによる不要オブジェクトの回収率（スループット性能）とヒープ使用効率（応答性能）の両面から，最適なヒープサイズを自動的に見積もることが可能となる。
【０１４１】
さらに，メソッド呼出し時・復帰時における付加的なプロファイル情報をロギングすることにより，どのメソッドで生成されたオブジェクトなのかという情報や，スレッドローカルなオブジェクトか否かなどという情報を得ることもできる。この情報をもとに，ヒープへの負荷調整の観点で，アプリケーションを最適化することが可能となる。
【図面の簡単な説明】
【図１】本発明の実施の形態に係るヒープサイズ自動最適化装置の構成例を示す図である。
【図２】本実施の形態におけるヒープサイズ自動最適化処理フローチャートである。
【図３】プロファイル情報の収集契機とデータレコードの例を示す図である。
【図４】本発明における活動中ヒープサイズ，必要ヒープサイズ，使用ヒープサイズおよび指定ヒープサイズの時間変化の例を説明する図である。
【図５】オブジェクトの寿命によるヒープサイズの調整を説明する図である。
【図６】本発明の実施の形態におけるヒープに負担をかけているメソッドの調査を説明する図である。
【図７】本実施の形態におけるロギング処理を示す図である。
【図８】アプリケーション実行途中からプロファイルを開始するときの例を示す図である。
【図９】本実施の形態におけるデータ整理処理を示す図である。
【図１０】本実施の形態におけるオブジェクト情報の例を示す図である。
【図１１】本実施の形態における使用ヒープサイズおよび活動中ヒープサイズの推移を調査するためのソート例を示す図である。
【図１２】本実施の形態におけるオブジェクト寿命特性を得るためのソート例を示す図である。
【図１３】本実施の形態における必要／使用ヒープサイズのグラフの例を示す図である。
【図１４】本実施の形態におけるオブジェクト寿命分布のグラフの例（１）を示す図である。
【図１５】本実施の形態におけるオブジェクト寿命分布のグラフの例（２）を示す図である。
【図１６】本実施の形態における見積り処理フローチャートである。
【図１７】本実施の形態におけるユーザ提示する情報のメニュー画面の例を示す図である。
【図１８】本実施の形態における最適ヒープサイズ画面の例を示す図である。
【図１９】本実施の形態におけるプロファイルデータ画面の例を示す図である。
【図２０】本実施の形態におけるオブジェクトデータ画面の例を示す図である。
【図２１】本実施の形態におけるオブジェクトリスト画面の例を示す図である。
【図２２】本実施の形態におけるメソッドリスト画面の例を示す図である。
【符号の説明】
１ ヒープサイズ自動最適化装置
１０ ロギング処理部
１１ プロファイル情報ロギングルーチン
２０ 分析処理部
２１ データ整理部
２２ ソート部
２３ 可視化部
３０ 見積り処理部
４０ プロファイル情報格納域
５０ オブジェクト情報格納域
６０ 必要ヒープサイズデータ
７０ オブジェクト寿命特性
８０ 必要／使用ヒープサイズのグラフ
９０ オブジェクト寿命分布のグラフ
【発明の属する技術分野】
本発明は，ガベージコレクション（Garbage Collection）を実装するコンピュータシステムにおいて，最適なヒープサイズを求めるためのヒープサイズ自動最適化処理方法に関するものである。
【０００２】
以下では，ガベージコレクションをＧＣと記す。ここで，ＧＣを実装するコンピュータシステムとして，例えば，ＪＶＭ（Java Virtual Machine：Ｊａｖａ（登録商標）仮想マシン）がある。本明細書では，ＧＣを実装するコンピュータシステムとしてＪＶＭの例を用いて説明するが，本発明を適用できるシステムは，ＪＶＭに限られない。
【０００３】
【従来の技術】
一般に，ヒープサイズの見積りの技術に関して，Ｊａｖａのように動的にメモリを確保するプログラムでは，必要となるメモリ量の見積り（予測）が難しいとされていた（例えば，非特許文献１参照）。
【０００４】
コンピュータによるアプリケーションの処理能力を表すもののうち，ＧＣによって影響を受けるものとしては，スループットと応答性能とがある。ここで，スループットとは，単位時間内にアプリケーションが処理する仕事量のことである。また，応答性能とは，ユーザによる入力からユーザへの出力までの時間の均一度であり，均一であるほど応答性能はよいものとされる。
【０００５】
ＧＣの間は，ユーザプログラムが停止している。ＧＣの起動頻度が高いと，そのたびにユーザプログラムが停止するため，スループットは低下する。したがって，スループットを向上させるには，スループットを低下させる要因であるＧＣの起動頻度を少なくするために，ヒープサイズを大きくとることが望ましい。
【０００６】
一方，応答性能を向上させるには，１回のＧＣの処理コストを小さくするために，ヒープサイズを小さくすることが望ましい。これは，１回のＧＣの処理コストが大きいとＧＣによってヒープがブロックされ，システムが停止してしまう時間が延びてしまうためである。ユーザからのトランザクションがあったときに，ＧＣ中でなければすぐに応答可能であるが，ＧＣ中であればＧＣが終了するまで応答不可能となる。１回のＧＣの処理コストが大きいと，ＧＣ中であった場合となかった場合とでユーザへ応答するまで時間が不均一となるため，応答性能は低下する。
【０００７】
以上のような問題に対処するため，従来は，スループットを向上させるためには，ヒープサイズを大きくとることを考慮することで解決してきた。また，応答性能を向上させるためには，なるべくヒープサイズを小さくとることで解決してきた。しかし，これら相反する条件を同時に解決することは不可能であり，実際の運用において必要かつ最適なヒープサイズを求めることはきわめて困難であった。
【０００８】
そのため，従来はヒープ不足が発生したときにはヒープサイズを増やし，膨大なヒープサイズによるＧＣ性能劣化のため応答性能が悪化したときにはヒープサイズを減らし，そのたびに再起動を繰り返すしかなかった。
【０００９】
また，従来の技術として，頻繁にＧＣを繰り返してオブジェクトのドラッグ時間（最終アクセスからＧＣで回収されるまでの無駄にヒープを使用する時間）を短くする技術があった（例えば，非特許文献２参照）。この技術は，タイムラグ（ここでは，ドラッグ時間のこと）を短くするための技術であり，ＪＶＭ上のＪａｖａアプリケーション側で対処する技術である。しかし，頻繁に起動するＧＣは処理的な負担が大きく，極端にスループットを低下させてしまうという問題があった。
【００１０】
【非特許文献１】
ジェイムズ・ノーブル，チャールズ・ウィアー著，安藤慶一訳，「省メモリプログラミング メモリ制限のあるシステムのためのソフトウェアパターン集」，ピアソン・エデュケーション，p.269
【非特許文献２】
Ran Shaham,Elliot K.Kolodner,and Mooly Sagiv.,"On the Effectiveness of GC in Java." ,The 2000 International Symposium on Memory Management(ISMM'00),October 2000
【００１１】
【発明が解決しようとする課題】
以上のような従来の方法では，任意のＪａｖａアプリケーションを実行するときに，スループットと応答性能との双方のバランスをみて最適となる妥協点を自動的に求めることはできなかった。また，ヒープサイズの見積りの精度も悪く，最適なヒープサイズを見積もるまでには何度も試行を繰り返す必要があり，作業コストが膨大にかかってしまっていた。
【００１２】
本発明は，上記問題点の解決を図り，ＧＣを実装するコンピュータシステム（ＪＶＭ等）において，スループットと応答性能とのバランスから，最適なヒープサイズを自動的に求めることができるヒープサイズ自動最適化手段を提供することを目的とする。
【００１３】
【課題を解決するための手段】
本発明は，上記目的を達成するため，最適な応答性能となる点を求めるために，生存しているオブジェクト（ルートから到達可能なオブジェクト）を確保するための最低必要なヒープサイズを求め，応答性能を極端に悪化させない程度にスループットを向上させるために，オブジェクトの寿命をプロファイルして，例えば大半のオブジェクトが１回のＧＣで回収される（回収可能率が向上する）というような予め定められた基準またはスループット性能（不要オブジェクトの回収率）を優先するとか応答性能（ヒープ使用効率）を優先するとかいったオペレータが指定した基準に基づいてＧＣインターバルを調整し，最適なヒープサイズを求めることを特徴とする。
【００１４】
具体的には，ガベージコレクション（ＧＣ）を実装するコンピュータシステムにおいて，全オブジェクトの寿命や固有情報のプロファイリングデータを分析することで最適なヒープサイズを求めるため，ロギング処理部，分析処理部，見積り処理部を持つ。ロギング処理部は，オブジェクトの寿命情報とサイズ情報とを収集する。分析処理部は，オブジェクトの寿命をもとに任意の時点で生存するオブジェクトのサイズを積み重ねることで，各時点の必要ヒープサイズを求める。必要ヒープサイズを時系列にそって推移させ，システム全体での最低必要なヒープサイズを求める。さらに見積り処理部では，最低必要ヒープサイズを上回る範囲で，ＧＣによるゴミとなったオブジェクトの回収率と，システム全体で比較的最も多くのヒープサイズを占める寿命に合わせたＧＣインターバルとのバランスをみて最適なヒープサイズを求める。
【００１５】
プロファイリングデータは，全オブジェクトでなくとも一部または一定期間のオブジェクトを対象としてもよい。寿命の単位は，実際の時間でも延べ割当てサイズ（オブジェクト生成時の総割当て量〜終了時の総割当て量を寿命とする）でもよい。すなわち，寿命の時間の尺度を，実際の時間〔秒〕を単位にしても延べ割当てサイズ〔ｂｙｔｅ〕を単位にしてもよい。
【００１６】
以上のロギング処理部，分析処理部，見積り処理部による処理は，コンピュータとソフトウェアプログラムとによって実現することができ，そのプログラムをコンピュータ読み取り可能な記録媒体に記録することも，ネットワークを通して提供することも可能である。
【００１７】
【発明の実施の形態】
本発明の実施の形態を説明するに先立ち，実施の形態の説明中で用いている言葉の意味について簡単に説明する。
「応答性能」：ユーザの入力からユーザへの出力時間の均一度。均一であるほど応答性能はよい。
「スループット性能」：単位時間内にアプリケーションが処理する仕事量。
「オブジェクト寿命」：オブジェクトが生成されてからオブジェクトの最終アクセスまでの時間（ここで時間とは，実際の時間または延べ割当てサイズ）。
「真のオブジェクト寿命」：オブジェクトが生成されてからそのオブジェクトに対し到達不能になるまでの時間。
「活動中ヒープサイズ」：ある一時点での，生成されてからアクセスされなくなるまでのオブジェクトの総量。
「指定ヒープサイズ」：システムに指定したヒープサイズ。
「使用ヒープサイズ」：ある一時点での，実際にヒープに存在するオブジェクトの総量。
「必要ヒープサイズ」：ある一時点での，オブジェクト生成から到達不能になるまでのオブジェクトの総量。
「到達不能オブジェクト」：ルートから到達できないオブジェクト。システムが不要とみなし次のＧＣで回収対象となるオブジェクト。
「プロファイル」：システム内の情報をロギング・分析すること。
「ドラッグ時間」：オブジェクトの最終アクセスからオブジェクトが回収されるまでの無駄にヒープを使用する時間。
「スレッドローカル」：あるオブジェクトを生成したスレッド以外のスレッドからアクセスされないこと。
【００１８】
図１は，本発明の実施の形態に係るヒープサイズ自動最適化装置の構成例を示す。本実施の形態におけるヒープサイズ自動最適化装置１は，ＣＰＵおよびメモリなどからなるコンピュータであり，ソフトウェアプログラム等によって構成されるロギング処理部１０，分析処理部２０，見積り処理部３０を備えている。ロギング処理部１０は，プロファイル情報ロギングルーチン１１を備え，分析処理部２０は，データ整理部２１，ソート部２２，可視化部２３を備える。
【００１９】
ロギング処理部１０は，オブジェクトの生成時，オブジェクトへのアクセス時，ＧＣの開始時・終了時，メソッドの呼出し時・復帰時などに，プロファイル情報ロギングルーチン１１により，オブジェクトのアドレス，サイズ，スレッド番号，タイムスタンプ等のレコードをプロファイル情報格納域４０に記録する。ここで記録されたレコードをプロファイル情報という。
【００２０】
分析処理部２０は，ロギング処理部１０で収集されたプロファイル情報を分析し，オブジェクトごとにアドレス，サイズ，生成スレッド，生成時刻，最終アクセス時刻，ＧＣ経験回数，スレッドスコープ等のオブジェクト情報を生成し，これをもとに，各オブジェクトの寿命を算出するとともに，生存するオブジェクトのサイズを積算することにより，各時点における必要ヒープサイズを算出する処理を行う。
【００２１】
分析処理部２０のデータ整理部２１は，プロフィル情報格納域４０から読み込んだプロファイル情報をオブジェクトごとにまとめてオブジェクト情報を生成し，オブジェクト情報格納域５０に格納する処理を行う。ソート部２２は，オブジェクト情報格納域５０に格納されたオブジェクト情報を，種々の条件によりソートし，必要ヒープサイズデータ６０やオブジェクト寿命特性７０を算出する。可視化部２３は，分析結果としての必要ヒープサイズデータ６０やオブジェクト寿命特性７０等のデータをグラフ化するなどして，目に見える形に編集し，ディスプレイやプリンタに出力する。図中の８０は必要／使用ヒープサイズのグラフ，９０はオブジェクト寿命分布のグラフである。
【００２２】
見積り処理部３０は，分析処理部２０でのプロファイル情報の分析結果から，スループット性能および応答性能のバランスから予め定められた基準に従って，最適な指定ヒープサイズを自動的に見積もる。このとき，最適な指定ヒープサイズを決定する基準をユーザに指定させ，その基準に従って最適な指定ヒープサイズを自動的に見積もってもよい。
【００２３】
図２は，本実施の形態におけるヒープサイズ自動最適化処理フローチャートである。まず，ロギング処理部１０は，プロファイル情報ロギングルーチン１１によって，オブジェクトの生成，オブジェクトのアクセス，ＧＣ開始／終了，オブジェクトの生存情報，メソッド呼出し／復帰等に関するレコードをログに記録し，そのログをプロファイル情報格納域４０に出力する（ステップＳ１）。
【００２４】
分析処理部２０は，データ整理部２１によって，プロファイル情報格納域４０のログに記録されたレコードをｏｂｊ構造体を用いてオブジェクトごとに整理し，オブジェクト情報としてオブジェクト情報格納域５０に出力する（ステップＳ２）。また，分析処理部２０は，ソート部２２によって，オブジェクト情報格納域５０のオブジェクト情報をソートし，必要ヒープサイズデータ６０，オブジェクト寿命特性７０を得る（ステップＳ３）。さらに，分析処理部２０は，可視化部２３によって，必要ヒープサイズデータ６０から必要／使用ヒープサイズのグラフ８０を，オブジェクト寿命特性７０からオブジェクト寿命分布のグラフ９０を作成し出力する（ステップＳ４）。
【００２５】
見積り処理部３０は，分析処理部２０で得られたプロファイル情報の分析結果（必要ヒープサイズデータ６０，オブジェクト寿命特性７０など）から，最適な指定ヒープサイズを自動的に見積もる（ステップＳ５）。
【００２６】
図３は，本実施の形態におけるプロファイル情報の収集契機とデータレコードの例を示す図である。特に図３（Ａ）は，オブジェクトの生成から回収までの流れとＧＣとの関係およびプロファイル情報の収集契機を示している。また，図３（Ｂ）は，図３（Ａ）の流れの中でログに記録されるレコードの形式（データレコード形式）の例を示している。図３において，“ｏｂｊ”は，それぞれ個々のオブジェクトを表している。
【００２７】
ロギング処理部１０により，プロファイル情報のレコードがログされる契機は，オブジェクトの生成時（レコードＲ１），オブジェクトのアクセス時（レコードＲ２），ＧＣの開始・終了時（レコードＲ３，Ｒ６），ＧＣ処理時におけるオブジェクトの生存確認時（レコードＲ４，Ｒ５），オブジェクトのメソッド呼出し時（レコードＲ７），呼び出したメソッドからの復帰時（レコードＲ８）である。この他に，プロファイル期間の開始時および終了時にもログデータが出力される。
【００２８】
図３（Ａ）において，オブジェクトが生成されるとレコードＲ１がログに記録され，そのオブジェクトに参照または更新のアクセスがあるとレコードＲ２がログに記録され，以後，最終アクセスまで繰り返される。オブジェクトの生成からそのオブジェクトへの最終アクセスまでの時間をアクティブ時間（active time ）という。
【００２９】
オブジェクトへの最終アクセス後にルートから到達できなくなると，そのオブジェクトは到達不能（到達不能オブジェクト）となり，次のＧＣで回収される。オブジェクトへの最終アクセスからそのオブジェクトがＧＣにより回収されるまでの時間をドラッグ時間（drag time ）という。
【００３０】
ＧＣの開始時，終了時にそれぞれレコードＲ３，Ｒ６をログに記録し，ＧＣによって回収されない（ＧＣ後も生存する）オブジェクトのレコードＲ４，Ｒ５をログに記録する。あるＧＣの開始時刻から次のＧＣの開始時刻までをＧＣインターバルという。
【００３１】
図３（Ｂ）において，ｏｂｊ−生成（レコードＲ１）は，オブジェクトが生成されたときに記録されるレコードを示す。このとき，生成されたオブジェクトのアドレス，サイズ，そのオブジェクトを生成したスレッドのスレッド番号，生成された時刻を示すタイムスタンプ等の情報がログに記録される。本実施の形態では，オブジェクトを識別するための情報としてアドレスを用いているが，他の識別情報を記録してもよい。
【００３２】
ｏｂｊ−アクセス（レコードＲ２）は，オブジェクトのアクセスがあったときに記録されるレコードを示す。このとき，アクセスがあったオブジェクトのアドレス，サイズ，そのオブジェクトにアクセスしたスレッドのスレッド番号，アクセス時刻を示すタイムスタンプ等の情報がログに記録される。
【００３３】
ＧＣ−開始（レコードＲ３），ＧＣ−終了（レコードＲ６）は，それぞれＧＣの開始時，ＧＣの終了時に記録されるレコードを示す。ＧＣの開始や終了の時刻を示すタイムスタンプ，ＧＣ終了直後の使用ヒープサイズ等の情報がログに記録される。時間の尺度が延べ割当てサイズ（単位は［ｂｙｔｅ］）である場合には，ＧＣ終了時のタイムスタンプは不要である。
【００３４】
ここで，延べ割当てサイズについて説明する。延べ割当てサイズは，生成されたオブジェクトのサイズを生成時刻順に累積したものである。生成されたオブジェクトのサイズを生成時刻順に累積したものは，時間の進行とともに単調増加する。この性質を時間の進行の表現に利用したものが，延べ割当てサイズである。延べ割当てサイズは，オブジェクトの生成により常に増加する値であり，ＧＣ後もリセットされない。したがって，寿命（時間）の尺度を，実際の時間としても，また延べ割当てサイズにしても，実質的には変わりはない。ただし，ＧＣインターバルを定める場合などに，ヒープの使用効率を重視するときには，時間の間隔がヒープの使用量に応じて相対的に定まる延べ割当てサイズを尺度としたほうが好ましい。一方，応答性能などを実時間で保証する必要があるシステム等では，実際の時間を尺度としたほうが好ましい。
【００３５】
例えば，延べ割当てサイズが０［ｂｙｔｅ］の状態から，
(1) オブジェクトＡ（サイズａ［ｂｙｔｅ］）の生成
(2) オブジェクトＢ（サイズｂ［ｂｙｔｅ］）の生成
(3) オブジェクトＡへのアクセス
(4) ＧＣの開始・終了
(5) オブジェクトＣ（サイズｃ［ｂｙｔｅ］）の生成
の順で実行されたとき，それぞれの時刻を延べ割当てサイズで表現すると，
(1) オブジェクトＡの生成時刻・・・・・・０［ｂｙｔｅ］
(2) オブジェクトＢの生成時刻・・・・・・ａ［ｂｙｔｅ］
(3) オブジェクトＡへのアクセス時刻・・・ａ＋ｂ［ｂｙｔｅ］
(4) ＧＣの開始時刻・終了時刻・・・・・・ａ＋ｂ［ｂｙｔｅ］
(5) オブジェクトＣの生成時刻・・・・・・ａ＋ｂ［ｂｙｔｅ］
となる。
【００３６】
図３（Ｂ）において，ｏｂｊ−生存（移動時）（レコードＲ４），ｏｂｊ−生存（レコードＲ５）は，ＧＣ中に，ＧＣ後も生存する（ＧＣによって回収されない）オブジェクトが確認されたときに記録されるレコードを示す。生存するオブジェクトは，ＧＣによって，その位置が移動する場合としない場合がある。ＧＣによってオブジェクトの位置が移動する場合には，そのオブジェクトの移動元アドレス，移動先アドレス，サイズ等のレコードがログに記録され，ＧＣによってオブジェクトの位置が移動しない場合には，そのオブジェクトのアドレス，サイズ等のレコードがログに記録される。
【００３７】
ｍｅｔｈｏｄ−呼出し（レコードＲ７），ｍｅｔｈｏｄ−復帰（レコードＲ８）は，メソッドの呼出し／復帰があるときに記録されるレコードを示す。このとき，メソッドの呼出し／復帰が行われるスレッドのスレッド番号，メソッドに入ったとき／メソッドから抜けたときの時刻を示すタイムスタンプ，そのメソッド名等のレコードがログに記録される。後述するように，これらの情報を解析することにより，オブジェクト生成時のメソッドを知ることができるようになり，どのメソッドがヒープに負担をかけているかが分かるようになる。
【００３８】
分析処理部２０は，各オブジェクトの寿命を知るために，ＧＣによって回収されたオブジェクトについて，図３のように記録されたオブジェクト生成時やオブジェクトアクセス時のプロファイル情報を分析する。
【００３９】
ここで，オブジェクトの寿命とは，実際にはオブジェクトが生成されてから到達不能になるまでの期間のことをいい，時間または延べ割当てサイズの尺度で表現される。ところが，オブジェクトの到達不能点でのレコードの記録がないため，到達不能点までのオブジェクトの寿命をプロファイル情報から直接的には得ることができない。そこで，本実施の形態では，オブジェクトの生成点から最終アクセスまでをオブジェクトの寿命（以下，単に「オブジェクト寿命」という）とし，オブジェクトが生成されてから到達不能になるまでの真のオブジェクトの寿命（以下，「真のオブジェクト寿命」という）は，オブジェクト寿命から以下で説明するように推定する。
【００４０】
ＧＣ直後の総生存オブジェクトサイズをＳg とし，ＧＣ直後の活動中ヒープサイズをＳa とすると，ドラッグ時間中の到達可能オブジェクトを示す最終アクセス点から到達不能点までの期間は，
【００４１】
（式１）において，ＧＣ直後の総生存オブジェクトサイズ（Ｓg ）は，ＧＣ直後に生成点から到達不能点までの間の状態にあるオブジェクトの総サイズであり，ＧＣ直後の活動中ヒープサイズ（Ｓa ）は，ＧＣ直後に生成点から最終アクセス点までの状態にあるオブジェクトの総サイズである。ＧＣ直後のドラッグ時間中の総オブジェクトサイズは，ＧＣ直後に最終アクセス点から到達不能点までの間の状態にあるオブジェクトの総サイズである。
【００４２】
ＧＣ直後の活動中ヒープサイズ（Ｓa ）に対するＧＣ直後の総生存オブジェクトサイズ（Ｓg ）の値をドラッグ係数（Ｋ）とし，
Ｋ＝Ｓg ／Ｓa （式２）
の式で求める。
【００４３】
必要ヒープサイズは，前述したようにある時点での生成点から到達不能点までの状態にあるオブジェクトの総サイズを示し，その時点での生成点から最終アクセス点までの状態にあるオブジェクトの総サイズである活動中ヒープサイズと，（式２）で求めたドラッグ係数（Ｋ）とから，
必要ヒープサイズ＝活動中ヒープサイズ×Ｋ （式３）
の式で求められる。ここで，ＧＣ直後の必要ヒープサイズは，ＧＣ直後の総生存オブジェクトサイズ（Ｓg ）と同値である。
【００４４】
図４は，本実施の形態における活動中ヒープサイズＳat，必要ヒープサイズＳgt，使用ヒープサイズＳu および指定ヒープサイズＳr の時間変化の例を説明する図である。図中，実線で描かれた曲線は活動中ヒープサイズＳatを示し，波線で描かれた曲線は必要ヒープサイズＳgtを示す。のこぎり型の点線は使用ヒープサイズＳu を示し，上部の実線で描かれた直線は指定ヒープサイズＳr を示す。使用ヒープサイズＳu が指定ヒープサイズＳr に達したときに，ＧＣが実行される。
【００４５】
ＧＣが行われるごとに，ＧＣ直後の活動中ヒープサイズ（Ｓa ）とＧＣ直後の総生存オブジェクトサイズ（Ｓg ）との比からドラッグ係数（Ｋ）が求められ（（式２）参照），その後の各時刻における活動中ヒープサイズＳatにドラッグ係数（Ｋ）を乗じることにより（（式３）参照），各時刻における必要ヒープサイズＳgtが計算される。
【００４６】
ここで，ドラッグ係数（Ｋ）を求める式は（式２）に限らない。例えば，時刻ｔ1 におけるＧＣ直後の活動中ヒープサイズとＧＣ直後の総生存オブジェクトサイズとをそれぞれＳa1，Ｓg1とし，時刻ｔ2 におけるＧＣ直後の活動中ヒープサイズとＧＣ直後の総生存オブジェクトサイズとをそれぞれＳa2，Ｓg2としたとき，時刻ｔn におけるドラッグ係数（Ｋn ）を，
【００４７】
図４において，二点破線で示されているのが必要ヒープサイズの最大値であり，この値を最低必要なヒープサイズＳm とする。指定ヒープサイズＳr は，最低必要なヒープサイズＳm まで縮小することが可能である。指定ヒープサイズＳr が最低必要なヒープサイズＳm に近いほどＧＣインターバルが短くなり，頻繁にＧＣが行われるようになる。指定ヒープサイズＳr が最低必要なヒープサイズＳm から遠いほどＧＣインターバルが長くなり，１回のＧＣの開始から終了までの時間が長くなる。
【００４８】
分析処理部２０は，以上の（式２）または（式４）によるドラッグ係数（ＫまたはＫn ）を，オブジェクトの生成点から最終アクセスまでのオブジェクト寿命に乗じることにより，真のオブジェクト寿命を推定する。
【００４９】
図５は，本実施の形態におけるオブジェクトの寿命によるヒープサイズの調整を説明する図である。図５に示すグラフでは，横軸に延べオブジェクトサイズをとり，縦軸にオブジェクトの寿命をとっている。各オブジェクトを寿命の短い順にソートし，オブジェクトの寿命と延べオブジェクトサイズとの関係をプロットしたものが，図５に示す曲線（オブジェクト寿命分布曲線という）である。図５のグラフで一番右側にある“死なないオブジェクト”は，ＧＣで回収されないオブジェクトであり，分析処理部２０によってその寿命を求めることができないため，無視する。
【００５０】
ここで，延べオブジェクトサイズ（以下，単に延べサイズという）は，寿命の短い順に各オブジェクトのサイズを加えていったものである。例えば，
オブジェクトＡ：寿命２０［ｂｙｔｅ］，サイズａ［ｂｙｔｅ］
オブジェクトＢ：寿命２５０［ｂｙｔｅ］，サイズｂ［ｂｙｔｅ］
オブジェクトＣ：寿命４８［ｂｙｔｅ］，サイズｃ［ｂｙｔｅ］
というオブジェクトがあったときに，これらのオブジェクトを寿命の短い順に並べると，オブジェクトＡ，Ｃ，Ｂの順になり，それらの延べオブジェクトサイズは，
オブジェクトＡ：延べサイズａ［ｂｙｔｅ］
オブジェクトＣ：延べサイズａ＋ｃ［ｂｙｔｅ］
オブジェクトＢ：延べサイズａ＋ｃ＋ｂ［ｂｙｔｅ］
となる。
【００５１】
図５のグラフにおいて，中ほどにある縦の太線は，オブジェクト寿命分布曲線上で，オブジェクト寿命がＧＣインターバルの長さになる延べオブジェクトサイズを示し，その太線より左にある（寿命の短い）オブジェクトは２回目のＧＣを経験させずに回収できることを示している。プロファイルされたオブジェクトの総サイズに対する太線の位置の延べサイズの割合を回収可能率という。
【００５２】
ＧＣインターバルを長くとると，図５において太線の位置がより右の位置となり，より寿命の長いオブジェクトも２回目のＧＣを経験させずに回収することができるようになる。１回のＧＣの開始から終了までの時間が長くなるが，ＧＣを行う頻度が低くなるため，スループットが向上する。
【００５３】
ＧＣインターバルを短くとると，図５において太線の位置がより左側の位置となり，回収されるまで２回以上のＧＣを経験するオブジェクトが増えることになる。ＧＣの頻度が高くなるが，１回のＧＣの開始から終了までの時間が短くなるため，応答性能が向上する。
【００５４】
見積り処理部３０は，分析処理部２０でのプロファイル情報の分析結果から，最適な指定ヒープサイズＳr を自動的に見積もる。このとき，最適な指定ヒープサイズを決定する基準は，システムまたはアプリケーション開発者があらかじめ定めておくことができる。また，最適な指定ヒープサイズを決定する基準をアプリケーションのユーザに指定させ，その基準に従って最適な指定ヒープサイズを自動的に見積もってもよい。
【００５５】
例えば，ユーザによる最適な指定ヒープサイズを決定する基準の指定が，ＧＣインターバルを決定するための基準であれば，図５に示すようなオブジェクトの寿命の分布をもとに，最適なタイミングでＧＣを行うためのＧＣインターバル（以下，最適なＧＣインターバルという）を決定する。
【００５６】
次に，決定された最適なＧＣインターバルから，最適な指定ヒープサイズを求める。例えば，プロファイル時のＧＣインターバルの２倍の値が最適なＧＣインターバルであるならば，単純にプロファイル時の指定ヒープサイズを２倍の値に増やしたものが最適な指定ヒープサイズとなる。同様に，プロファイル時のＧＣインターバルの半分が最適なＧＣインターバルであるならば，プロファイル時の指定ヒープサイズの半分が最適な指定ヒープサイズとなる。
【００５７】
ここで，以上の本実施の形態によるヒープサイズの最適化による効果を，前述の非特許文献２との比較により，考察する。
【００５８】
前述の非特許文献２のように，頻繁にＧＣを繰り返してドラッグ時間を短くすることで，
“生成点から到達不能点までの時間”≒“生成点から回収点までの時間”
とし，“生成点から到達不能点までの時間”を近似値で求める方法があるが，頻繁に起動するＧＣは処理的な負担が大きく，極端にスループットを低下させてしまう。それに対し，本発明による実施の形態では，ＧＣの起動回数を必要以上に増加させることはないので極端にスループットが低下することはない。
【００５９】
さらに，オブジェクトプロファイル技術に関しては，前述の非特許文献２では，プロファイル手段として，オブジェクトの生成時やオブジェクトへのアクセス時の情報を，そのオブジェクト内にプロファイル用フィールドを持たせてそこに収集しているため，プロファイル処理がヒープ管理へ影響を与えてしまい，指定ヒープサイズと実際の使用可能なヒープサイズとが異なってしまう。それに対し，本発明による実施の形態では，オブジェクトの生成時やオブジェクトへのアクセス時の情報を，その機会にオブジェクトを識別するためのアドレスとともに別領域へ格納するため，使用可能なヒープサイズに影響を与えずに済む。
【００６０】
また，付加的なプロファイル情報として，メソッド呼出し・復帰に関する情報（図３（Ｂ）におけるｍｅｔｈｏｄ−呼出し，ｍｅｔｈｏｄ−復帰のレコード（レコードＲ７，Ｒ８））を追加することにより，どのメソッドがヒープに負担をかけているかを知ることができる。
【００６１】
図６は，本発明の実施の形態におけるヒープに負担をかけているメソッドの調査を説明する図である。図６（Ａ）は，メソッドによるオブジェクト生成およびメソッドの呼出し・復帰の状況を示す図であり，図６（Ｂ）は，図６（Ａ）における各メソッドとそれらのメソッドが生成するオブジェクトとの関係を時系列で表したものである。メソッドの呼出し時・復帰時のタイムスタンプを記録することにより，どのメソッドがオブジェクトを生成したかを容易に知ることができる。
【００６２】
図６（Ａ）において，メソッドｘｘｘは，オブジェクトＡを生成し，メソッドｙｙｙを呼び出す。メソッドｙｙｙは，オブジェクトＤを生成し，メソッドｚｚｚを呼び出す。メソッドｚｚｚは，オブジェクトＧを生成し，メソッドｙｙｙに復帰する。メソッドｙｙｙは，オブジェクトＥを生成し，メソッドｘｘｘに復帰する。メソッドｘｘｘは，オブジェクトＢを生成し，メソッドｙｙｙ２を呼び出す。メソッドｙｙｙ２は，オブジェクトＦを生成し，メソッドｘｘｘに復帰する。メソッドｘｘｘは，オブジェクトＣを生成する。
【００６３】
このような図６（Ａ）の状況において，スレッド番号，メソッド名とともにメソッド呼出し時・復帰時のタイムスタンプをログに出力することにより図６（Ｂ）のような生成されたオブジェクトの時間的順序を得ることができ，図６（Ｂ）からオブジェクト生成時のメソッドを知ることができる。これにより，どのメソッドがヒープに負担をかけているのかを容易に調査できるようになる。
【００６４】
また，オブジェクトを生成したスレッドの情報（スレッド番号等）と，オブジェクトにアクセスしたスレッドの情報（スレッド番号等）とを，ログに記録することにより，そのオブジェクトがスレッドローカルなオブジェクトであるか，スレッドグローバルなオブジェクトであるかを知ることができる。
【００６５】
以下，図１に示すヒープサイズ自動最適化装置１の構成および動作をさらに詳しく説明する。
【００６６】
図７は，本実施の形態におけるロギング処理を示す図である。ロギング処理部１０のプロファイル情報ロギングルーチン１１は，Ｊａｖａスレッド１００上でメソッドの呼出し・復帰が行われたとき（ステップＳ１０１），オブジェクトが生成されたとき（ステップＳ１０２），オブジェクトの参照・更新（オブジェクトへのアクセス）があったとき（ステップＳ１０３）に，図３（Ｂ）に示すデータレコード形式でレコードをログに記録し，そのログをプロファイル情報格納域４０に出力する。
【００６７】
Ｊａｖａスレッド１００上でオブジェクトが生成されるとき（ステップＳ１０２）に，ヒープが不足したならば（ステップＳ１０４），ＧＣを起動する。
【００６８】
プロファイル情報ロギングルーチン１１は，ＧＣスレッド１１０上でＧＣが開始されたとき（ステップＳ１１１），ＧＣにおいて生存オブジェクトが確認されたとき（ステップＳ１１２），ＧＣが終了したとき（ステップＳ１１３）に，それぞれ図３（Ｂ）に示すデータレコード形式でレコードをログに記録し，そのログをプロファイル情報格納域４０に出力する。
【００６９】
ここで，プロファイル情報格納域４０が保有する情報量を小さくするために，プロファイル情報（ログに記録するレコード）を間引くことも可能である。例えば，アドレスをキーにして公平にサンプリングすることができるように，
（（Ｒａｔｉｏ＞９９‖Ｒａｔｉｏ＜１）‖
（ｉｎｔ（（ａｄｄｒ＋１）×Ｒａｔｉｏ／１００）
−ｉｎｔ（ａｄｄｒ×Ｒａｔｉｏ／１００）） （式５）
の式が成立つときにロギングするようにすればよい。（式５）において，“‖”は，ｏｒを示す。ｉｎｔ（Ｘ）は，Ｘの整数部分を表す。ａｄｄｒはオブジェクトのアドレスを表し，Ｒａｔｉｏは，何％の割合でレコードをロギングするかの比を表す。例えば，Ｒａｔｉｏ＝５０（％）のとき，２回に１回の割合でレコードがロギングされることになる。Ｒａｔｉｏ＝３０（％）なら，１０回に３回の割合でレコードがロギングされる。
【００７０】
また，システムを起動したときから常時すべてのプロファイル情報を採取するのではなく，ある期間のみ採取するようにしてもよい。実際にプロファイルを常時行うことにより得られるレコードの量は膨大なものであり，すべてを蓄積することは困難である。したがって，ある一定期間に限ってプロファイルを行う機能を設けることが望ましい。そこで，例えばプロファイル開始／終了コマンドにより，プロファイル情報の採取期間を指定することができるようにする。
【００７１】
図８に，アプリケーション実行途中からプロファイルを開始するときの例を示す。アプリケーション実行中の途中からプロファイルを開始するときには，プロファイルの開始時点において使用ヒープサイズＳu や必要ヒープサイズの初期値Ｓg0を把握する必要がある。そこで，プロファイル開始時には，強制的にＧＣを起動する。これにより，ロギング開始以前に生成されていたオブジェクトの総サイズがわかる。その後，プロファイル終了までの間に生成／回収されたオブジェクトに関してプロファイル情報を収集する。プロファイル開始時と同様に，プロファイル終了時にも強制的にＧＣを起動する。これによって，必要ヒープサイズＳgtを逆算できるようになり，採取期間の前後の状態によらずに，ロギング開始から終了までの間の必要ヒープサイズＳgtを求めることが可能になる。
【００７２】
なお，図３では説明を省略したが，プロファイルをアプリケーションの実行途中で開始し実行途中で終了する場合には，そのプロファイル期間の開始時および終了時に，プロファイル−開始（レコードＲ９），プロファイル−終了（レコードＲ１０）のレコードをタイムスタンプ等の情報を付加してログに記録する。
【００７３】
ロギング処理部１０が収集したプロファイル情報には，１つのオブジェクトについてオブジェクトの生成，オブジェクトのアクセス等，複数のレコードが存在する。そこで，それらの情報をオブジェクトごとにまとめるために，分析処理部２０において，データ整理部２１は，オブジェクトごとにその情報を格納するためのｏｂｊ構造体を用意する。そして，プロファイル情報格納域４０からログを取得し，そのログからレコードを取り出して該当するオブジェクトのｏｂｊ構造体に記録し，そのｏｂｊ構造体をオブジェクト情報格納域５０に格納する。ここで，ｏｂｊ構造体が持つ情報をオブジェクト情報という。
【００７４】
図９は，本実施の形態におけるデータ整理部２１の処理を示す図である。図９（Ａ）はデータ整理処理の流れを示し，図９（Ｂ）はｏｂｊ構造体の例を示す。図９（Ｃ）はオブジェクト生成時，オブジェクトアクセス時，ＧＣ時に更新されるｏｂｊ構造体のデータ部のメンバを示す。図９（Ｄ）はｏｂｊ構造体の推移を示す。
【００７５】
データ整理部２１は，図９（Ａ）に示すように，プロファイル情報格納域４０に格納されているレコードが終了するまで（ステップＳ２０２），プロファイル情報格納域４０に格納されたログから，１レコードを取り出す処理（ステップＳ２００）と，取り出したレコードに対する処理とを繰り返す（ステップＳ２０１）。
【００７６】
図９（Ａ）のステップＳ２０１におけるレコードに対する処理において，オブジェクトごとにプロファイル情報を整理するために，オブジェクトごとに図９（Ｂ）に示すようなｏｂｊ構造体が用意される。図９（Ｂ）の例のｏｂｊ構造体において，ヘッダ部の“ｌｅｆｔ”，“ｒｉｇｈｔ”，“ｐａｒｅｎｔ”，“ｂａｌａｎｃｅ”は，常にバランスの取れた２分木（ＡＶＬバランス木）を構成するための情報である。
【００７７】
データ部において，“ａｄｄｒ”はオブジェクトのアドレスを示し，“ｓｉｚｅ”はオブジェクトのサイズを示し，“ｎｅｗ＿ｔｈｒｅａｄ”はオブジェクトを生成したスレッドを示す。“ｎｅｗ＿ｔｉｍｅ”はオブジェクトが生成された時刻を示し，“ｌａｓｔ＿ｔｉｍｅ”はオブジェクトへの最終アクセスの時刻を示す。“ａｇｅ”はオブジェクトが経験したＧＣの回数を示す。“ｉｓ＿ｇｌｏｂａｌ”はオブジェクトにアクセスしたスレッドがオブジェクトを生成したスレッドと違うかどうか（スレッドスコープ）を示す。
【００７８】
図９（Ｃ）に示すように，ｏｂｊ構造体のうち，オブジェクト生成時（ｎｅｗ）に更新されるメンバは“ａｄｄｒ”，“ｓｉｚｅ”，“ｎｅｗ＿ｔｈｒｅａｄ”，“ｎｅｗ＿ｔｉｍｅ”である。また，オブジェクトアクセス時（ａｃｃ）に更新されるメンバは“ｌａｓｔ＿ｔｉｍｅ”，“ｉｓ＿ｇｌｏｂａｌ”である。ＧＣ時（ＧＣ）に更新されるメンバは“ａｇｅ”である。
【００７９】
図９（Ｄ）に示すように，ｏｂｊ構造体は，“生存オブジェクト”，“ＧＣ待ちオブジェクト”，“回収済オブジェクト”の３つの状態を推移し，各ｏｂｊ構造体は，「生存オブジェクト集合」，「ＧＣ待ちオブジェクト集合」，「回収済オブジェクト集合」の３つの集合のいずれかの状態にある。
【００８０】
以下，図９（Ａ）のステップＳ２０１におけるレコード処理について，その例を説明する。ここでは，図３（Ｂ）に示すレコードごとに説明する。
【００８１】
レコードＲ１（ｏｂｊ−生成）の場合：
(1) プロファイル情報格納域４０のログからｏｂｊ−生成時のレコード（アドレス，サイズ，スレッド番号，タイムスタンプ）を取り出す。
(2) 「回収済オブジェクト集合」から空のｏｂｊ構造体を１つ取り出す。空のｏｂｊ構造体がない場合には，新規に用意する。
(3) 取り出した空のｏｂｊ構造体に“ａｄｄｒ”，“ｓｉｚｅ”，“ｎｅｗ＿ｔｈｒｅａｄ”，“ｎｅｗ＿ｔｉｍｅ”を設定し，そのｏｂｊ構造体を「生存オブジェクト集合」に登録する。
【００８２】
レコードＲ２（ｏｂｊ−アクセス）の場合：
(1) プロファイル情報格納域４０のログからｏｂｊ−アクセス時のレコード（アドレス，サイズ，スレッド番号，タイムスタンプ）を取り出す。
(2) 「生存オブジェクト集合」から該当するｏｂｊ構造体を取り出す。
(3) ｏｂｊ構造体の“ｌａｓｔ＿ｔｉｍｅ”を更新し，取り出されたレコードのスレッド番号がオブジェクト生成時のスレッド番号である“ｎｅｗ＿ｔｈｒｅａｄ”と異なる場合には，“ｉｓ＿ｇｌｏｂａｌ”に「真」を設定する。取り出されたレコードのスレッド番号が匿名番号であった場合には，“ｉｓ＿ｇｌｏｂａｌ”は更新せず，“ｎｅｗ＿ｔｈｒｅａｄ”を更新する。
【００８３】
レコードＲ３（ＧＣ−開始）の場合：
(1) プロファイル情報格納域４０のログからＧＣ−開始のレコード（タイムスタンプ）を取り出し，オブジェクト情報格納域５０に出力する。
(2) 「生存オブジェクト集合」の全ｏｂｊ構造体を「ＧＣ待ちオブジェクト集合」に移す。
【００８４】
レコードＲ４，Ｒ５（ｏｂｊ−生存（移動時），ｏｂｊ−生存）の場合：
(1) プロファイル情報格納域４０のログからｏｂｊ−生存（移動時）のレコード（移動元アドレス，移動先アドレス，サイズ）またはｏｂｊ−生存のレコード（アドレス，サイズ）を取り出す。
(2) 「ＧＣ待ちオブジェクト集合」から該当するｏｂｊ構造体を取り出し，“ａｇｅ”に１を加えて，そのｏｂｊ構造体を「生存オブジェクト集合」に登録する。プロファイル開始時のＧＣでは，「生存オブジェクト集合」にｏｂｊ構造体が存在しないため，「回収済オブジェクト集合」から空のｏｂｊ構造体を１つ取り出し（空のｏｂｊ構造体がない場合には，新規に用意し），“ｎｅｗ＿ｔｉｍｅ”にプロファイルの開始時刻を，“ｎｅｗ＿ｔｈｒｅａｄ”に匿名番号を設定し，取り出されたレコードにより“ａｄｄｒ”，“ｓｉｚｅ”を設定し，そのｏｂｊ構造体を「生存オブジェクト集合」に登録する。
【００８５】
レコードＲ６（ＧＣ−終了）の場合：
(1) プロファイル情報格納域４０のログからＧＣ−終了のレコード（タイムスタンプ，ＧＣ直後の使用ヒープサイズ）を取り出し，オブジェクト情報格納域５０に出力する。
(2) 「ＧＣ待ちオブジェクト集合」に残ったすべてのｏｂｊ構造体が持つオブジェクト情報を，オブジェクト情報格納域５０に出力する。
(3) オブジェクト情報格納域５０にオブジェクト情報を出力したｏｂｊ構造体を，「回収済オブジェクト集合」に移し，再利用可能にしておく。
【００８６】
レコードＲ７（ｍｅｔｈｏｄ−呼出し）の場合：
(1) プロファイル情報格納域４０のログからｍｅｔｈｏｄ−呼出しのレコード（スレッド番号，タイムスタンプ，メソッド名）を取り出し，オブジェクト情報格納域５０に出力する。
【００８７】
レコードＲ８（ｍｅｔｈｏｄ−復帰）の場合：
(1) プロファイル情報格納域４０のログからｍｅｔｈｏｄ−復帰のレコード（スレッド番号，タイムスタンプ，メソッド名）を取り出し，オブジェクト情報格納域５０に出力する。
【００８８】
分析処理部２０において，ソート部２２は，オブジェクト情報格納域５０から，オブジェクトごとに整理されたオブジェクト情報（“ａｄｄｒ”，“ｓｉｚｅ”，“ｎｅｗ＿ｔｈｒｅａｄ”，“ｎｅｗ＿ｔｉｍｅ”，“ｌａｓｔ＿ｔｉｍｅ”，“ａｇｅ”，“ｉｓ＿ｇｌｏｂａｌ”等）を入力し，それらのオブジェクト情報を様々な条件でソートすることにより，必要ヒープサイズの推移やオブジェクト寿命の特性などをプロファイルする。
【００８９】
図１０は，本実施の形態におけるオブジェクト情報の例を示す図である。各ｏｂｊ構造体は，オブジェクトごとに整理された“ａｄｄｒ”，“ｓｉｚｅ”，“ｎｅｗ＿ｔｈｒｅａｄ”，“ｎｅｗ＿ｔｉｍｅ”，“ｌａｓｔ＿ｔｉｍｅ”，“ａｇｅ”，“ｉｓ＿ｇｌｏｂａｌ”のオブジェクト情報を持っている。以下，この図１０の例に示す３つオブジェクトのオブジェクト情報をソートする例を説明する。
【００９０】
図１１は，本実施の形態における使用ヒープサイズおよび活動中ヒープサイズの推移を調査するためのソート例を示す図である。
【００９１】
まず，ソートする前に，図１０の各オブジェクト情報を図１１（Ａ）のように生成時の情報と最終アクセス時の情報の２つのレコードに分ける。図１１（Ａ）において，ａｄｄｒ欄にはオブジェクト情報の“ａｄｄｒ”を記録する。ｔｉｍｅ欄には，生成時の情報の場合にはオブジェクト情報の“ｎｅｗ＿ｔｉｍｅ”を，最終アクセス時の場合にはオブジェクト情報の“ｌａｓｔ＿ｔｉｍｅ”を記録する。ｔｏｔａｌ’欄は使用ヒープサイズを求めるための情報の記録欄であり，生成時の情報の場合にはオブジェクト情報の“ｓｉｚｅ”を，最終アクセス時の場合には０を記録する。ｍａｘ’欄は活動中ヒープサイズを求めるための情報の記録欄であり，生成時の情報の場合にはオブジェクト情報の“ｓｉｚｅ”を，最終アクセス時の場合にはオブジェクト情報の“ｓｉｚｅ”の符号をマイナスにしたものを記録する。
【００９２】
図１１（Ｂ）は，図１１（Ａ）をｔｉｍｅ欄の値が昇順になるようにソートした結果を示している。図１１（Ｃ）は，図１１（Ｂ）のｔｏｔａｌ’欄とｍａｘ’欄とについて時系列順に計上したものを，それぞれｔｏｔａｌ欄とｍａｘ欄に記録したものである。図１１（Ｃ）において，ｔｏｔａｌ欄は使用ヒープサイズの推移を示し，ｍａｘ欄は，活動中ヒープサイズの推移を示している。
【００９３】
ここで，図１１（Ｃ）の例には記録されていないが，途中でＧＣが発生したときには，使用ヒープサイズ（ｔｏｔａｌ）から回収されたオブジェクトサイズ分を差し引くか，または，ＧＣ直後の使用ヒープサイズにリセットする。オブジェクト情報格納域５０に格納されたＧＣ開始時・終了時のタイムスタンプのデータを，図１１（Ａ）〜（Ｃ）中でソートするデータとして盛り込んでもよい。
【００９４】
以上の使用ヒープサイズ，活動中ヒープサイズ等の推移の情報は，必要ヒープサイズデータ６０に記録される。また，図１１（Ｃ）において，各活動中ヒープサイズの値（ｍａｘ欄の値）に，前述のドラッグ係数（Ｋ，Ｋn ）を乗じることにより，必要ヒープサイズの推移を確認することができる。このようにして得られた必要ヒープサイズの推移の情報を，使用ヒープサイズ，活動中ヒープサイズ等の推移の情報とともに必要ヒープサイズデータ６０に記録してもよい。
【００９５】
このとき，データ量を削減するために，複数レコードの中から代表するレコードのみを出力することも可能である。例えば，データ量を１／１０に圧縮したいならば，時系列に並ぶ１０レコードのうち必要ヒープサイズが最も大きいレコードのみを出力すればよい。圧縮比率は，必要ヒープサイズデータ６０のサイズによって自由に変えることができる。
【００９６】
図１２は，本実施の形態におけるオブジェクト寿命特性を得るためのソート例を示す図である。ａｄｄｒ欄にはオブジェクト情報の“ａｄｄｒ”が記録され，ｓｉｚｅ欄にはオブジェクト情報の“ｓｉｚｅ”が記録される。ｌｏｎｇｅｖｉｔｙ欄はオブジェクト寿命の記録欄であり，オブジェクト情報の“ｎｅｗ＿ｔｉｍｅ”と“ｌａｓｔ＿ｔｉｍｅ”との差が記録される。図１２では，ｌｏｎｇｅｖｉｔｙ欄が昇順になるようにソートされている。
【００９７】
図１２において，各オブジェクト寿命の値（ｌｏｎｇｅｖｉｔｙ欄の値）に，前述のドラッグ係数（Ｋ，Ｋn ）を乗じることにより，各オブジェクトの真のオブジェクト寿命を得ることができる。各オブジェクトのオブジェクト寿命と真のオブジェクト寿命とは，オブジェクト寿命特性７０に記録される。このとき，オブジェクト寿命または真のオブジェクト寿命のいずれか一つを記録するようにしてもよい。
【００９８】
このとき，データ量を削減するために，複数レコードの中から代表する１レコードのみを出力することも可能である。例えば，データ量を１／１０に圧縮したいならば，寿命が短い順に１０レコード目のレコードのみを出力すればよい。このようにすれば，隣り合ったレコードの寿命長が近い値であるため，等間隔で間引くことができる。圧縮比率は，オブジェクト寿命特性７０のサイズによって自由に変えることができる。
【００９９】
以上の図１１，図１２の例では，オブジェクト情報のうち“ｎｅｗ＿ｔｈｒｅａｄ”，“ａｇｅ”，“ｉｓ＿ｇｌｏｂａｌ”のデータを使用していないが，これらのデータは別の観点でのオブジェクトの傾向を掴む場合に使用する。また，オブジェクト情報格納域５０に格納されたメソッド呼出し時・復帰時のスレッド番号，タイムスタンプ，メソッド名等のデータも使用していないが，これらのデータも別の観点での傾向を掴む場合に使用する。必要なときには，これらのデータもソートするデータとして盛り込むことが可能である。
【０１００】
分析処理部２０において，可視化部２３は，必要ヒープサイズデータ６０，オブジェクト寿命特性７０を入力し，それぞれを表計算ソフトウェアなどで用いられている手法を利用してグラフ化する。必要ヒープサイズデータ６０から必要／使用ヒープサイズのグラフ８０が作成され，オブジェクト寿命特性７０からオブジェクト寿命分布のグラフ９０が作成される。このとき，グラフ化を容易にするため，必要な情報が損なわれない範囲内で，データ量（レコード数）を削減してもよい。
【０１０１】
図１３は，本実施の形態における必要／使用ヒープサイズのグラフの例を示す図である。図１３では，使用ヒープサイズと必要ヒープサイズの推移がグラフ化されているが，それに限らない。例えば，使用ヒープサイズと活動中ヒープサイズの推移をグラフ化してもよいし，使用ヒープサイズと活動中ヒープサイズと必要ヒープサイズの推移をグラフ化してもよい。また，図１３の例では時間の尺度として延べ割当て量（延べ割当サイズ）［Ｍｂｙｔｅ］が用いられているが，実際の時間［秒］を用いてもよい。
【０１０２】
図１３において，使用ヒープサイズの頂点が指定ヒープサイズであり，そこに使用ヒープサイズが達するとＧＣが実行される。この図では，８［Ｍｂｙｔｅ］ぐらいに指定ヒープサイズが設定されている。
【０１０３】
図１４は，本実施の形態におけるオブジェクト寿命分布のグラフの例（１）を示す図である。各オブジェクトが寿命長でソートされ，寿命が短い順に，オブジェクトの延べサイズと寿命との関係がプロットされている。図１４の例では，寿命の尺度として延べ割当サイズ［Ｍｂｙｔｅ］が用いられているが，実際の時間［秒］を用いてもよい。また，オブジェクトの寿命としては，オブジェクト寿命を用いてもよいし，真のオブジェクト寿命を用いてもよい。
【０１０４】
図１５は，本実施の形態におけるオブジェクト寿命分布のグラフの例（２）を示す図である。図１５のグラフは，図１４のグラフを視覚的に分かりやすくするために，縦軸を対数目盛りにしたものである。延べサイズが４［Ｍｂｙｔｅ］以上のデータのみをプロットしている。縦軸を対数目盛りで表示するか否かは，メニューなどにより選択することができる。
【０１０５】
見積り処理部３０は，分析処理部２０で得られたプロファイル情報の分析結果から，最低必要なヒープサイズ（Ｓm ），プロファイル時のＧＣインターバル（Ｉr ），最適なＧＣインターバル（Ｉi ）を求め，それらの求められた値とプロファイル時の指定ヒープサイズ（Ｓr ）とから最適な指定ヒープサイズ（Ｓi ）を自動的に見積もる。
【０１０６】
図１６は，本実施の形態における見積り処理フローチャートである。図１６の例は，最適な指定ヒープサイズを決定する基準が回収可能率で指定された場合の例である。
【０１０７】
まず，必要ヒープサイズデータ６０から，必要ヒープサイズの最大値である最低必要なヒープサイズ（Ｓm ）を求める（ステップＳ３０１）。このとき，例えば，各時刻の活動中ヒープサイズにドラッグ係数（Ｋ，Ｋn ）を乗じて得られた必要ヒープサイズが必要ヒープサイズデータ６０に記録されていれば，その最大値を最低必要なヒープサイズ（Ｓm ）とし，必要ヒープサイズが必要ヒープサイズデータ６０に記録されていなければ，活動中ヒープサイズの最大値にドラッグ係数（Ｋ，Ｋn ）を乗じて得られた値を最低必要なヒープサイズ（Ｓm ）とする。
【０１０８】
次に，オブジェクト情報格納域５０に格納されているＧＣ開始時・終了時のタイムスタンプから，プロファイル時のＧＣインターバル（Ｉr ）を求める（ステップＳ３０２）。このとき，例えば，プロファイル期間中のＧＣインターバルの平均値などを求め，それをプロファイル時のＧＣインターバル（Ｉr ）とすればよい。
【０１０９】
次に，ユーザから指定された最適な指定ヒープサイズを決定する基準と，オブジェクト寿命特性７０とから，最適なＧＣインターバル（Ｉi ）を求める（ステップＳ３０３）。
【０１１０】
例えば，ユーザから指定された回収可能率が８０％（寿命の短いオブジェクトから延べサイズで８０％のオブジェクトが２回目のＧＣを経験しない）であったなら，オブジェクト寿命特性７０で寿命が短いオブジェクトから延べサイズで８０％目にあたるオブジェクトのデータを抽出し，そのオブジェクトの寿命長を最適なＧＣインターバル（Ｉi ）とする。
【０１１１】
このとき，例えば，各オブジェクトのオブジェクト寿命にドラッグ係数（Ｋ，Ｋn ）を乗じて得られた真のオブジェクト寿命がオブジェクト寿命特性７０に記録されていれば，寿命が短いオブジェクトから延べサイズで８０％目に当たるオブジェクトの真のオブジェクト寿命を最適なＧＣインターバル（Ｉi ）とし，真のオブジェクト寿命がオブジェクト寿命特性７０に記録されていなければ，寿命が短いオブジェクトから延べサイズで８０％目にあたるオブジェクトのオブジェクト寿命にドラッグ係数（Ｋ，Ｋn ）を乗じて得られた値を最適なＧＣインターバル（Ｉi ）とすればよい。
【０１１２】
次に，プロファイル時の指定ヒープサイズ（Ｓr ）と，ステップＳ３０２で求めたプロファイル時のＧＣインターバル（Ｉr ）と，ステップＳ３０３で求めた最適なＧＣインターバル（Ｉi ）とから，
Ｓi ＝Ｓr ×Ｉi ／Ｉr （式６）
の式で，最適な指定ヒープサイズ（Ｓi ）を求める（ステップＳ３０４）。ここで，プロファイル時の指定ヒープサイズ（Ｓr ）に関しては，予めプロファイル時にその値を記録しておけばよい。
【０１１３】
ステップＳ３０１で求めた最低必要なヒープサイズ（Ｓm ）よりステップＳ３０４で求めた最適な指定ヒープサイズ（Ｓi ）の方が小さければ（ステップＳ３０５），ステップＳ３０１で求めた最低必要なヒープサイズ（Ｓm ）を最適な指定ヒープサイズ（Ｓi ）とする（ステップＳ３０６）。そうでなければ，ステップＳ３０４で求めたＳi を最適な指定ヒープサイズとする。
【０１１４】
本実施の形態におけるヒープサイズ自動最適化装置１により得られた情報は，ディスプレイ等により，ユーザに提示される。以下，ユーザに情報を提示する画面の例を図面を用いて説明する。
【０１１５】
図１７は，本実施の形態におけるユーザ提示する情報のメニュー画面の例を示す。図１７のメニュー画面では，最適ヒープサイズ，プロファイルデータ，オブジェクトデータ，オブジェクトリスト，メソッドリストの各メニュー項目ボタンから表示したい情報を選択することができる。
【０１１６】
図１８は，本実施の形態における最適ヒープサイズ画面の例を示す図である。図１８において，必要／使用ヒープサイズの部分（画面左側上部）には，そのグラフ８０と必要ヒープサイズデータ６０とが表示されている。また，オブジェクト寿命分布の部分（画面左側下部）には，そのグラフ９０とオブジェクト寿命特性７０が表示されている。ここで，必要ヒープサイズデータ６０やオブジェクト寿命特性７０のデータを選択することにより，必要／使用ヒープサイズのグラフやオブジェクト寿命分布のグラフの選択されたデータに該当する部分に敷居線を表示させることができる。
【０１１７】
画面の右側中央部は，ユーザが最適な指定ヒープサイズを決定する基準を指定する部分であり，選択された基準によって自動的に見積もられた最適な指定ヒープサイズの値が，右側下部の最適ヒープサイズの部分に表示される。
【０１１８】
最適な指定ヒープサイズを決定する基準を指定する部分において，「最大ＧＣ期待回数」を選択すると，すべてのオブジェクトに指定された回数を越えたＧＣを経験させないように最適なＧＣインターバルが決定され，それをもとに最適な指定ヒープサイズが自動的に見積もられる。
【０１１９】
最適な指定ヒープサイズを決定する基準を指定する部分において，「最低ヒープサイズ」を選択すると，最低必要なヒープサイズが最適な指定ヒープサイズであるとして自動的に見積もられる。
【０１２０】
最適な指定ヒープサイズを決定する基準を指定する部分において，「推奨ヒープサイズ」を選択すると，スループットと応答性能とのバランスがよい状態になるようにシステムが予め定めた最適な指定ヒープサイズを自動的に見積もる。ここでは，大半のオブジェクト（例えば９０％）のオブジェクトが１回だけＧＣを経験するような指定ヒープサイズになるように，見積り値が決定される。
【０１２１】
最適な指定ヒープサイズを決定する基準を指定する部分において，「スループット重視」を選択すると，スループットを重視して最適な指定ヒープサイズを見積もる。例えば，指定されたレベルのスループットを実現するのに最適なＧＣインターバルが決定され，それをもとに最適な指定ヒープサイズが自動的に見積もられる。
【０１２２】
最適な指定ヒープサイズを決定する基準を指定する部分において，「レスポンス重視」を選択すると，レスポンス（応答性能）を重視して最適な指定ヒープサイズを見積もる。例えば，指定されたレベルのレスポンスを実現するのに最適なＧＣインターバルが決定され，それをもとに最適な指定ヒープサイズが自動的に見積もられる。
【０１２３】
図１９は，本実施の形態におけるプロファイルデータ画面の例を示す図である。図１９に示す画面において，１行目から２３行目まではオブジェクト生成時，オブジェクトアクセス時のプロファイルデータ（プロファイル情報）の例であり，２４行目はＧＣ開始時のプロファイルデータの例であり，２５行目から２９行目がＧＣ後も生存するオブジェクトのプロファイルデータの例である。一番左の番号は，レコードを識別するために順に振られた番号である。図１９では，時刻は延べ割当てサイズで記載されている。
【０１２４】
１行目から２３行目において，左から２列目のデータはそのレコードが何のレコードであるかを示し，図１９の例では，“ｎｅｗ”がオブジェクト生成時のレコードであることを示し，“ｐｕｔｆｉｅｌｄ”，“ｇｅｔｆｉｅｌｄ”がオブジェクトアクセス（更新／参照）時のレコードであることを示す。次のコロンに続くデータは，オブジェクトのアドレスを示し，括弧内はオブジェクトのサイズを示す。次のデータは，オブジェクト生成時，オブジェクトアクセス時のスレッド番号であり，一番右側のデータはタイムスタンプである。
【０１２５】
２４行目において，左から２列目のデータはＧＣが開始されたことを示す。左から３列目のデータは，ＧＣ開始時のタイムスタンプを示す。２５行目から２９行目において，左から２列目のデータ（“ｍｏｖｅ”）は，ＧＣ後も生存するオブジェクトの移動を示し，次のコロンに続くデータは移動元アドレスを，一番右側のデータは移動先アドレスを示す。
【０１２６】
図２０は，本実施の形態におけるオブジェクトデータ画面の例を示す図である。図２０において，オブジェクトごとのオブジェクトデータ（オブジェクト情報）は，オブジェクト番号で識別される。また，オブジェクトごとに，サイズ（“ｓｉｚｅ”に該当），スレッドＩＤ（“ｎｅｗ＿ｔｈｒｅａｄ”に該当），生成時刻（“ｎｅｗ＿ｔｉｍｅ”に該当），最終アクセス時刻（“ｌａｓｔ＿ｔｉｍｅ”に該当），寿命，ＧＣ経験数（“ａｇｅ”に該当），スコープ（“ｉｓ＿ｇｌｏｂａｌ”に該当），オブジェクト名のデータを持つ。
【０１２７】
ここで，スコープ（“ｉｓ＿ｇｌｏｂａｌ”に該当）欄において，“Ｌ”はスレッドローカルを示し，“Ｇ”は，スレッドグローバルを示す。このデータから，そのオブジェクトがスレッドローカルなオブジェクトであるか，スレッドグローバルなオブジェクトであるかを容易に知ることができる。
【０１２８】
図２１は，本実施の形態におけるオブジェクトリスト画面の例を示す図である。図２１において，画面左部分が用意されているクラスのリストであり，そのリストからクラスを選択することによって，そのクラスから生成された（インスタンス化された）オブジェクトを知ることができる。画面右部分が，選択されたクラスから生成されたオブジェクトのリストを表示する部分である。
【０１２９】
図２２は，本実施の形態におけるメソッドリスト画面の例を示す図である。図２２において，画面左部分が用意されているメソッドのリスト部分であり，そのリストからメソッドを選択することにより，そのメソッドによって生成されたオブジェクト，そのメソッドによってアクセスされたオブジェクトを知ることができる。
【０１３０】
図２２において，画面右側上部分が選択されたメソッドにより生成されたオブジェクトのリストを表示する部分であり，画面右側下部分が選択されたメソッドによりアクセスされたオブジェクトのリストを表示する部分である。これらのデータから，どのメソッドがヒープに負担をかけているかを容易に知ることができる。
【０１３１】
以上の本実施の形態の特徴を列挙すると，以下の通りとなる。
【０１３２】
（付記１）ガベージコレクションを実装するコンピュータシステムにおけるヒープサイズ自動最適化処理方法であって，
少なくともオブジェクトの生成時，オブジェクトのアクセス時およびガベージコレクション時に，オブジェクトの寿命を算出するための，生成したオブジェクトまたは生存しているオブジェクトの識別情報，サイズ情報または時間情報に関するプロファイルデータを収集し記録する第１の過程と，
前記記録されたプロファイルデータを分析し，各オブジェクトの寿命を算出するとともに，生存するオブジェクトのサイズを積算することにより，各時点における必要ヒープサイズを算出する第２の過程と，
前記第２の過程で算出した各オブジェクトの寿命に関する寿命特性および必要ヒープサイズの情報をもとに，スループット性能および応答性能のバランスから予め定められた基準またはオペレータから指定された基準に基づいて目的とするヒープサイズを決定する第３の過程とを有する
ことを特徴とするヒープサイズ自動最適化処理方法。
【０１３３】
（付記２）付記１に記載のヒープサイズ自動最適化処理方法において，
メソッドの呼出し時およびメソッドの復帰時のプロファイルデータを収集し記録する第４の過程と，
前記第１の過程と前記第４の過程によって記録されたプロファイルデータをもとに，各メソッドが生成するオブジェクトおよび各メソッドがアクセスするオブジェクトに関する情報を生成し出力する第５の過程とを有する
ことを特徴とするヒープサイズ自動最適化処理方法。
【０１３４】
（付記３）付記１または付記２記載のヒープサイズ自動最適化処理方法において，
前記第１の過程のオブジェクト生成時のプロファイルデータとして，オブジェクトを生成したスレッドのスレッド番号を記録し，かつオブジェクトアクセス時のプロファイルデータとして，オブジェクトにアクセスしたスレッドのスレッド番号を記録し，
前記オブジェクトを生成したスレッドのスレッド番号と，前記オブジェクトにアクセスしたスレッドのスレッド番号とから，各オブジェクトがスレッドローカルなオブジェクトであるかスレッドグローバルなオブジェクトであるかを示す情報を生成する過程を有する
ことを特徴とするヒープサイズ自動最適化処理方法。
【０１３５】
（付記４）付記１から付記３までのいずれかに記載のヒープサイズ自動最適化処理方法において，
前記第２の過程における分析では，前記記録されたプロファイルデータから，各オブジェクトごとに１つのオブジェクト構造体を割り当て，同じオブジェクトに関する複数のデータを１つのデータにまとめて処理する
ことを特徴とするヒープサイズ自動最適化処理方法。
【０１３６】
（付記５） 付記１から付記４までのいずれかに記載のヒープサイズ自動最適化処理方法において，
前記第１の過程によるプロファイルデータの収集の開始および終了を指示する過程と，
プロファイルデータの収集の開始および終了の際に，ガベージコレクションを起動する過程とを有する
ことを特徴とするヒープサイズ自動最適化処理方法。
【０１３７】
（付記６）ガベージコレクションを実装するコンピュータシステムにおけるヒープサイズ自動最適化装置であって，
少なくともオブジェクトの生成時，オブジェクトのアクセス時およびガベージコレクション時に，オブジェクトの寿命を算出するための，生成したオブジェクトまたは生存しているオブジェクトの識別情報，サイズ情報または時間情報に関するプロファイルデータを収集し記録するロギング処理部と，
前記記録されたプロファイルデータを分析し，各オブジェクトの寿命を算出するとともに，生存するオブジェクトのサイズを積算することにより，各時点における必要ヒープサイズを算出する分析処理部と，
前記分析処理部で算出した各オブジェクトの寿命に関する寿命特性および必要ヒープサイズの情報をもとに，スループット性能および応答性能のバランスから予め定められた基準またはオペレータから指定された基準に基づいて目的とするヒープサイズを決定する見積り処理部とを備える
ことを特徴とするヒープサイズ自動最適化装置。
【０１３８】
（付記７）ガベージコレクションを実装するコンピュータシステムにおけるヒープサイズ自動最適化処理方法をコンピュータに実行させるためのプログラムであって，
少なくともオブジェクトの生成時，オブジェクトのアクセス時およびガベージコレクション時に，オブジェクトの寿命を算出するための，生成したオブジェクトまたは生存しているオブジェクトの識別情報，サイズ情報または時間情報に関するプロファイルデータを収集し記録する処理と，
前記記録されたプロファイルデータを分析し，各オブジェクトの寿命を算出するとともに，生存するオブジェクトのサイズを積算することにより，各時点における必要ヒープサイズを算出する処理と，
前記算出した各オブジェクトの寿命に関する寿命特性および必要ヒープサイズの情報をもとに，スループット性能および応答性能のバランスから予め定められた基準またはオペレータから指定された基準に基づいて目的とするヒープサイズを決定する処理とを，
コンピュータに実行させるためのヒープサイズ自動最適化プログラム。
【０１３９】
（付記８）ガベージコレクションを実装するコンピュータシステムにおけるヒープサイズ自動最適化処理方法をコンピュータに実行させるためのプログラムを記録した記録媒体であって，
少なくともオブジェクトの生成時，オブジェクトのアクセス時およびガベージコレクション時に，オブジェクトの寿命を算出するための，生成したオブジェクトまたは生存しているオブジェクトの識別情報，サイズ情報または時間情報に関するプロファイルデータを収集し記録する処理と，
前記記録されたプロファイルデータを分析し，各オブジェクトの寿命を算出するとともに，生存するオブジェクトのサイズを積算することにより，各時点における必要ヒープサイズを算出する処理と，
前記算出した各オブジェクトの寿命に関する寿命特性および必要ヒープサイズの情報をもとに，スループット性能および応答性能のバランスから予め定められた基準またはオペレータから指定された基準に基づいて目的とするヒープサイズを決定する処理とを，
コンピュータに実行させるためのプログラムを記録したことを特徴とするヒープサイズ自動最適化プログラムの記録媒体。
【０１４０】
【発明の効果】
以上説明したように，本発明によって，ＧＣを実装するコンピュータシステムにおいて任意のアプリケーションを実行するときに，オブジェクトの寿命をプロファイル分析することにより，ＧＣによる不要オブジェクトの回収率（スループット性能）とヒープ使用効率（応答性能）の両面から，最適なヒープサイズを自動的に見積もることが可能となる。
【０１４１】
さらに，メソッド呼出し時・復帰時における付加的なプロファイル情報をロギングすることにより，どのメソッドで生成されたオブジェクトなのかという情報や，スレッドローカルなオブジェクトか否かなどという情報を得ることもできる。この情報をもとに，ヒープへの負荷調整の観点で，アプリケーションを最適化することが可能となる。
【図面の簡単な説明】
【図１】本発明の実施の形態に係るヒープサイズ自動最適化装置の構成例を示す図である。
【図２】本実施の形態におけるヒープサイズ自動最適化処理フローチャートである。
【図３】プロファイル情報の収集契機とデータレコードの例を示す図である。
【図４】本発明における活動中ヒープサイズ，必要ヒープサイズ，使用ヒープサイズおよび指定ヒープサイズの時間変化の例を説明する図である。
【図５】オブジェクトの寿命によるヒープサイズの調整を説明する図である。
【図６】本発明の実施の形態におけるヒープに負担をかけているメソッドの調査を説明する図である。
【図７】本実施の形態におけるロギング処理を示す図である。
【図８】アプリケーション実行途中からプロファイルを開始するときの例を示す図である。
【図９】本実施の形態におけるデータ整理処理を示す図である。
【図１０】本実施の形態におけるオブジェクト情報の例を示す図である。
【図１１】本実施の形態における使用ヒープサイズおよび活動中ヒープサイズの推移を調査するためのソート例を示す図である。
【図１２】本実施の形態におけるオブジェクト寿命特性を得るためのソート例を示す図である。
【図１３】本実施の形態における必要／使用ヒープサイズのグラフの例を示す図である。
【図１４】本実施の形態におけるオブジェクト寿命分布のグラフの例（１）を示す図である。
【図１５】本実施の形態におけるオブジェクト寿命分布のグラフの例（２）を示す図である。
【図１６】本実施の形態における見積り処理フローチャートである。
【図１７】本実施の形態におけるユーザ提示する情報のメニュー画面の例を示す図である。
【図１８】本実施の形態における最適ヒープサイズ画面の例を示す図である。
【図１９】本実施の形態におけるプロファイルデータ画面の例を示す図である。
【図２０】本実施の形態におけるオブジェクトデータ画面の例を示す図である。
【図２１】本実施の形態におけるオブジェクトリスト画面の例を示す図である。
【図２２】本実施の形態におけるメソッドリスト画面の例を示す図である。
【符号の説明】
１ ヒープサイズ自動最適化装置
１０ ロギング処理部
１１ プロファイル情報ロギングルーチン
２０ 分析処理部
２１ データ整理部
２２ ソート部
２３ 可視化部
３０ 見積り処理部
４０ プロファイル情報格納域
５０ オブジェクト情報格納域
６０ 必要ヒープサイズデータ
７０ オブジェクト寿命特性
８０ 必要／使用ヒープサイズのグラフ
９０ オブジェクト寿命分布のグラフ
Claims (5)
- オブジェクトが格納されるヒープ領域に対するガベージコレクションの機能を実装するコンピュータシステムのコンピュータが実行するヒープサイズ自動最適化処理方法であって，
少なくともオブジェクトの生成時，オブジェクトのアクセス時およびガベージコレクション時に，オブジェクトの生成点から最終アクセスまでの期間であるオブジェクトの寿命を算出するための，生成したオブジェクトまたは生存しているオブジェクトのサイズ情報または時間情報が付加されたサイズ情報に関するプロファイルデータを収集し記録する第１の過程と，
前記記録されたプロファイルデータを分析し，前記サイズ情報を生成順に累積した延べ割当てサイズまたは前記時間情報を尺度として，オブジェクトの生成点から最終アクセスまでの期間を算出することにより各オブジェクトの寿命を算出するとともに，前記サイズ情報からガベージコレクション直後にオブジェクトの生成点から最終アクセスまでの状態にあるオブジェクトの総サイズを算出して予め定めた係数を積算することにより，各時点における必要ヒープサイズを算出する第２の過程と，
最適な指定ヒープサイズを決定する基準として指定された，回収可能率，最大ガベージコレクション期待回数，スループット重視またはレスポンス重視の少なくともいずれかの基準を含む，ガベージコレクションインターバルを決定するための基準と，前記第２の過程で算出した各オブジェクトの寿命とに基づいて，前記基準を満たすガベージコレクションインターバルを算出し，前記第２の過程で算出した必要ヒープサイズと前記基準を満たすガベーベジコレクションインターバルとから目的とするヒープサイズを決定する第３の過程とを有する
ことを特徴とするヒープサイズ自動最適化処理方法。 - 請求項１に記載のヒープサイズ自動最適化処理方法において，
前記第２の過程における前記予め定めた係数は，ガベージコレクション直後の総生存オブジェクトサイズの値を，ガベージコレクション直後にオブジェクトの生成点から最終アクセスまでの状態にあるオブジェクトの総サイズで割った値である
ことを特徴とするヒープサイズ自動最適化処理方法。 - 請求項１または請求項２に記載のヒープサイズ自動最適化処理方法において，
メソッドの呼出し時およびメソッドの復帰時のプロファイルデータを収集し記録する第４の過程と，
前記第１の過程と前記第４の過程によって記録されたプロファイルデータをもとに，各メソッドが生成するオブジェクトおよび各メソッドがアクセスするオブジェクトに関する情報を生成し出力する第５の過程とを有する
ことを特徴とするヒープサイズ自動最適化処理方法。 - オブジェクトが格納されるヒープ領域に対するガベージコレクションの機能を実装するコンピュータシステムにおけるヒープサイズ自動最適化装置であって，
少なくともオブジェクトの生成時，オブジェクトのアクセス時およびガベージコレクション時に，オブジェクトの生成点から最終アクセスまでの期間であるオブジェクトの寿命を算出するための，生成したオブジェクトまたは生存しているオブジェクトのサイズ情報または時間情報が付加されたサイズ情報に関するプロファイルデータを収集し記録するロギング処理部と，
前記記録されたプロファイルデータを分析し，前記サイズ情報を生成順に累積した延べ割当てサイズまたは前記時間情報を尺度として，オブジェクトの生成点から最終アクセスまでの期間を算出することにより各オブジェクトの寿命を算出するとともに，前記サイズ情報からガベージコレクション直後にオブジェクトの生成点から最終アクセスまでの状態にあるオブジェクトの総サイズを算出して予め定めた係数を積算することにより，各時点における必要ヒープサイズを算出する分析処理部と，
最適な指定ヒープサイズを決定する基準として指定された，回収可能率，最大ガベージ コレクション期待回数，スループット重視またはレスポンス重視の少なくともいずれかの基準を含む，ガベージコレクションインターバルを決定するための基準と，前記分析処理部で算出した各オブジェクトの寿命とに基づいて，前記基準を満たすガベージコレクションインターバルを算出し，前記分析処理部で算出した必要ヒープサイズと前記基準を満たすガベージコレクションインターバルとから目的とするヒープサイズを決定する見積り処理部とを備える
ことを特徴とするヒープサイズ自動最適化装置。 - オブジェクトが格納されるヒープ領域に対するガベージコレクションの機能を実装するコンピュータシステムにおけるヒープサイズ自動最適化処理方法をコンピュータに実行させるためのプログラムであって，
少なくともオブジェクトの生成時，オブジェクトのアクセス時およびガベージコレクション時に，オブジェクトの生成点から最終アクセスまでの期間であるオブジェクトの寿命を算出するための，生成したオブジェクトまたは生存しているオブジェクトのサイズ情報または時間情報が付加されたサイズ情報に関するプロファイルデータを収集し記録する処理と，
前記記録されたプロファイルデータを分析し，前記サイズ情報を生成順に累積した延べ割当てサイズまたは前記時間情報を尺度として，オブジェクトの生成点から最終アクセスまでの期間を算出することにより各オブジェクトの寿命を算出するとともに，前記サイズ情報からガベージコレクション直後にオブジェクトの生成点から最終アクセスまでの状態にあるオブジェクトの総サイズを算出して予め定めた係数を積算することにより，各時点における必要ヒープサイズを算出する処理と，
最適な指定ヒープサイズを決定する基準として指定された，回収可能率，最大ガベージコレクション期待回数，スループット重視またはレスポンス重視の少なくともいずれかの基準を含む，ガベージコレクションインターバルを決定するための基準と，前記算出した各オブジェクトの寿命とに基づいて，前記基準を満たすガベージコレクションインターバルを算出し，前記算出した必要ヒープサイズと前記基準を満たすガベージコレクションインターバルとから目的とするヒープサイズを決定する処理とを，
コンピュータに実行させるためのヒープサイズ自動最適化プログラム。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002378194A JP4116877B2 (ja) | 2002-12-26 | 2002-12-26 | ヒープサイズ自動最適化処理方法，ヒープサイズ自動最適化装置およびそのプログラム |
| US10/738,179 US7415491B2 (en) | 2002-12-26 | 2003-12-17 | Method and apparatus for optimizing heap size, and program and program recording medium thereof |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002378194A JP4116877B2 (ja) | 2002-12-26 | 2002-12-26 | ヒープサイズ自動最適化処理方法，ヒープサイズ自動最適化装置およびそのプログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004206644A JP2004206644A (ja) | 2004-07-22 |
| JP4116877B2 true JP4116877B2 (ja) | 2008-07-09 |
Family
ID=32677419
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002378194A Expired - Fee Related JP4116877B2 (ja) | 2002-12-26 | 2002-12-26 | ヒープサイズ自動最適化処理方法，ヒープサイズ自動最適化装置およびそのプログラム |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US7415491B2 (ja) |
| JP (1) | JP4116877B2 (ja) |
Families Citing this family (35)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR100626368B1 (ko) * | 2003-08-25 | 2006-09-20 | 삼성전자주식회사 | 가비지 콜렉션 벤치마킹 방법 |
| US8204931B2 (en) | 2004-12-28 | 2012-06-19 | Sap Ag | Session management within a multi-tiered enterprise network |
| US20060143256A1 (en) | 2004-12-28 | 2006-06-29 | Galin Galchev | Cache region concept |
| US7434206B2 (en) * | 2005-03-10 | 2008-10-07 | Hewlett-Packard Development Company, L.P. | Identifying memory leaks in computer systems |
| US8589562B2 (en) | 2005-04-29 | 2013-11-19 | Sap Ag | Flexible failover configuration |
| JP4996073B2 (ja) * | 2005-07-13 | 2012-08-08 | 富士通株式会社 | 世代別ガベージコレクションプログラム |
| JP2007086838A (ja) * | 2005-09-20 | 2007-04-05 | National Institute Of Advanced Industrial & Technology | ゼロガベージコレクション通信仲介装置 |
| US7500077B2 (en) * | 2005-12-09 | 2009-03-03 | International Business Machines Corporation | Use of region-oriented memory profiling to detect heap fragmentation and sparse memory utilization |
| US7467278B2 (en) * | 2006-05-08 | 2008-12-16 | International Business Machines Corporation | Memory tuning for garbage collection and central processing (CPU) utilization optimization |
| US20080162709A1 (en) * | 2006-12-27 | 2008-07-03 | International Business Machines Corporation | System for processing application protocol requests |
| US9311082B2 (en) | 2006-12-29 | 2016-04-12 | Sap Se | System and method for processing graph objects |
| US7725505B2 (en) * | 2006-12-29 | 2010-05-25 | Sap Ag | System and method for measuring memory consumption differences between objects within an object-oriented programming environment |
| US8640086B2 (en) * | 2006-12-29 | 2014-01-28 | Sap Ag | Graphical user interface system and method for presenting objects |
| US8001336B2 (en) * | 2007-03-02 | 2011-08-16 | International Business Machines Corporation | Deterministic memory management in a computing environment |
| US7908454B2 (en) * | 2007-06-26 | 2011-03-15 | Microsoft Corporation | Application-specific heap management |
| US20090013017A1 (en) * | 2007-07-03 | 2009-01-08 | Branda Steven J | Methods, Systems, and Computer Program Products for Optimizing Virtual Machine Memory Consumption |
| US8185880B2 (en) * | 2007-10-04 | 2012-05-22 | International Business Machines Corporation | Optimizing heap memory usage |
| US8095766B2 (en) * | 2008-04-07 | 2012-01-10 | International Business Machines Corporation | Method and system for approximating object sizes in an object-oriented system |
| US8407681B2 (en) * | 2008-05-23 | 2013-03-26 | International Business Machines Corporation | System and method for changing variables at runtime |
| US8301672B2 (en) * | 2008-09-22 | 2012-10-30 | Advanced Micro Devices, Inc. | GPU assisted garbage collection |
| US8473900B2 (en) * | 2009-07-01 | 2013-06-25 | Advanced Micro Devices, Inc. | Combining classes referenced by immutable classes into a single synthetic class |
| US8583783B1 (en) * | 2009-08-18 | 2013-11-12 | Sprint Communications Company L.P. | Method and system for adaptive recovery of heap memory |
| JP4959781B2 (ja) * | 2009-12-22 | 2012-06-27 | インターナショナル・ビジネス・マシーンズ・コーポレーション | オブジェクト生成地点記録方法およびプログラム |
| US8327109B2 (en) * | 2010-03-02 | 2012-12-04 | Advanced Micro Devices, Inc. | GPU support for garbage collection |
| US8522216B2 (en) | 2010-05-04 | 2013-08-27 | Oracle International Corporation | Memory leak detection |
| US8504878B2 (en) * | 2010-05-04 | 2013-08-06 | Oracle International Corporation | Statistical analysis of heap dynamics for memory leak investigations |
| JP5476208B2 (ja) | 2010-05-12 | 2014-04-23 | インターナショナル・ビジネス・マシーンズ・コーポレーション | リクエスト処理システム、方法及びプログラム |
| JP5478368B2 (ja) * | 2010-06-03 | 2014-04-23 | 日本電信電話株式会社 | メモリ消費量測定方法及びメモリ消費量測定プログラム |
| CN102253854A (zh) * | 2011-07-26 | 2011-11-23 | 华为技术有限公司 | 业务处理方法和Java虚拟机 |
| US20130144568A1 (en) | 2011-08-31 | 2013-06-06 | Rodrigo A. Palma-Amestoy | System and Method for Variable Detection in Objects |
| CN103197973A (zh) * | 2012-01-05 | 2013-07-10 | 中兴通讯股份有限公司 | 一种移动终端及其管理方法 |
| JP5809613B2 (ja) * | 2012-09-10 | 2015-11-11 | 日本電信電話株式会社 | 仮想マシンチューニング値計算装置および仮想マシンチューニング値計算方法 |
| CA2848683C (en) | 2014-04-10 | 2022-07-05 | Ibm Canada Limited - Ibm Canada Limitee | Working set adjustment in a managed environment |
| US9430153B2 (en) * | 2014-10-22 | 2016-08-30 | International Business Machines Corporation | Garbage collection and other management of memory heaps |
| CN108845864B (zh) * | 2018-06-27 | 2020-11-03 | 北京京东尚科信息技术有限公司 | 一种基于spring框架的JVM垃圾回收方法和装置 |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5566321A (en) * | 1993-12-13 | 1996-10-15 | Cray Research, Inc. | Method of managing distributed memory within a massively parallel processing system |
| US6049810A (en) * | 1997-04-23 | 2000-04-11 | Sun Microsystems, Inc. | Method and apparatus for implementing a write barrier of a garbage collected heap |
| US5845298A (en) * | 1997-04-23 | 1998-12-01 | Sun Microsystems, Inc. | Write barrier system and method for trapping garbage collection page boundary crossing pointer stores |
| US6199075B1 (en) * | 1997-05-30 | 2001-03-06 | Sun Microsystems, Inc. | Method and apparatus for generational garbage collection of a heap memory shared by multiple processors |
| US6728852B1 (en) * | 2000-06-30 | 2004-04-27 | Sun Microsystems, Inc. | Method and apparatus for reducing heap size through adaptive object representation |
| US6795836B2 (en) * | 2000-12-29 | 2004-09-21 | International Business Machines Corporation | Accurately determining an object's lifetime |
-
2002
- 2002-12-26 JP JP2002378194A patent/JP4116877B2/ja not_active Expired - Fee Related
-
2003
- 2003-12-17 US US10/738,179 patent/US7415491B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US7415491B2 (en) | 2008-08-19 |
| US20040133759A1 (en) | 2004-07-08 |
| JP2004206644A (ja) | 2004-07-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4116877B2 (ja) | ヒープサイズ自動最適化処理方法，ヒープサイズ自動最適化装置およびそのプログラム | |
| US7325234B2 (en) | System and method for monitoring computer application and resource utilization | |
| US6804691B2 (en) | Method for optimization of memory usage for a computer program | |
| US8825721B2 (en) | Time-based object aging for generational garbage collectors | |
| KR101600129B1 (ko) | 애플리케이션 효율 엔진 | |
| JPWO2009008279A1 (ja) | コンピュータシステム、管理装置、及びコンピュータシステム管理方法 | |
| JP6674471B2 (ja) | メモリの外部断片化の原因を決定するための方法、システム、コンピュータ・プログラム製品およびコンピュータ・プログラム | |
| US10102046B2 (en) | In-memory data analytic system that provides an integrated tracking mechanism for explicit memory resources | |
| JP6432333B2 (ja) | 情報処理装置、データ処理方法、およびデータ処理プログラム | |
| JP2008226179A (ja) | 業務プロセス推定プログラム、業務プロセス推定方法および業務プロセス推定装置 | |
| WO2015146100A1 (ja) | 負荷推定システム、情報処理装置、負荷推定方法、及び、プログラムを記憶する記憶媒体 | |
| US20050289307A1 (en) | Method and system for determining memory usage of a heap | |
| CN114546590A (zh) | Java虚拟机堆内存集合对象监测方法及内存溢出分析方法 | |
| US7162605B2 (en) | Method and system for obtaining memory usage information for a heap when a peak live count is updated | |
| US20180018129A1 (en) | Storage monitoring system and monitoring method therefor | |
| JP3642772B2 (ja) | コンピュータ装置及びプログラム実行方法 | |
| JP7243134B2 (ja) | 入力操作の作業効率管理装置、入力操作の作業効率管理方法、及び、入力操作の作業効率管理プログラム | |
| CN113157212A (zh) | Flash存储方法、装置、智能穿戴设备及存储介质 | |
| US20080282020A1 (en) | Determination of sampling characteristics based on available memory | |
| EP4354304A2 (en) | Method and system for estimating garbage collection suspension contributions of individual allocation sites | |
| JP6515510B2 (ja) | バッチジョブ処理装置、システム、バッチジョブ処理方法およびプログラム | |
| JP6681484B2 (ja) | 計算機運用管理システムおよび方法 | |
| CN115509492A (zh) | 软件需求评估方法及装置 | |
| CN117009698A (zh) | 多需求的用户端页面更新方法、装置、设备及介质 | |
| JP2022108373A (ja) | 情報処理装置、情報処理方法、およびシステム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050112 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050114 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070904 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20071105 |
|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20071105 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20071204 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080204 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20080212 |
|
| 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: 20080415 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080418 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110425 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 4116877 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110425 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110425 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120425 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130425 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140425 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |