(57)【要約】【課題】プログラム実行中のある時点でのメモリ消費が問題視されるに至った原因を特定するための情報を保持し、該情報をユーザに提示する方法が求められている。【解決手段】本発明は、プログラムによるメモリ消費の状況を提示可能なコンピュータ・システムにおいて、上記プログラム中の上記メモリ消費の発生原因を突き止める方法を提供する。該方法は、記憶部から、オブジェクトの生成にかかわる第１のコールパスを取得するステップと、上記記憶部から、上記オブジェクトへの接続にかかわる第２のコールパスを取得するステップと、上記取得された第１及び第２のコールパスの共通部分を求めるステップであって、上記共通部分が上記プログラム中の上記発生原因を示す、上記求めるステップとを含む。本発明はまた、上記プログラム中の上記メモリ消費の発生原因を突き止めるコンピュータ・システム及びコンピュータ・プログラムを提供する。【選択図】図１Ｃ
2010277421.tif 000002
【特許請求の範囲】
【請求項１】
プログラムによるメモリ消費の状況を提示可能なコンピュータ・システムにおいて、前記プログラム中の前記メモリ消費の発生原因を突き止める方法であって、
記憶部から、オブジェクトの生成にかかわる第１のコールパスを取得するステップと、
前記記憶部から、前記オブジェクトへの接続にかかわる第２のコールパスを取得するステップと、
前記取得された第１及び第２のコールパスの共通部分を求めるステップであって、前記共通部分が前記プログラム中の前記発生原因を示す、前記求めるステップと
を含む、前記方法。
【請求項２】
前記コンピュータ・システムが、コールパスと該コールパスに対応するＩＤとの組を含む対応表を有し、
前記第１のコールパスを取得するステップにおいて、前記第１のコールパスの代わりに第１のＩＤが取得され、
前記第２のコールパスを取得するステップにおいて、前記第２のコールパスの代わりに第２のＩＤが取得され、
前記求めるステップが、前記対応表から、前記取得された第１のＩＤに対応する第１のコールパス及び前記取得された第２のＩＤに対応する第２のコールパスをそれぞれ求めるステップをさらに含み、それによって、前記求めるステップにおいて、前記求められた第１及び第２のコールパスの共通部分が求められる、
請求項１に記載の方法。
【請求項３】
前記第１のコールパスを取得するステップにおいて、前記第１のコールパスの代わりに第１のＩＤが取得され、
前記第２のコールパスを取得するステップにおいて、前記第２のコールパスの代わりに第２のＩＤが取得され、
前記共通部分を求めるステップの前に、前記プログラムの実行時における呼び出しの関係を表す第３のコールパスからＩＤを算出するステップと、
前記算出されたＩＤと前記取得された第１のＩＤとが一致する場合、前記第３のコールパスを第１のコールパスとし、前記算出されたＩＤと前記取得された第２のＩＤとが一致する場合、前記第３のコールパスを前記取得された第２のコールパスとするステップと
をさらに含む、請求項１に記載の方法。
【請求項４】
前記第１のＩＤを取得するステップにおいて、該第１のＩＤが前記オブジェクトに対応付けられた前記記憶部の領域から取得される、請求項２に記載の方法。
【請求項５】
前記第２のＩＤを取得するステップにおいて、該第２のＩＤが、前記オブジェクトが接続する他のオブジェクトに対応付けられた前記記憶部の領域から取得される、請求項４に記載の方法。
【請求項６】
前記第２のＩＤを取得するステップにおいて、該第２のＩＤが前記オブジェクトに対応付けられた前記記憶部の領域から取得される、請求項４に記載の方法。
【請求項７】
前記共通部分に含まれる最新のコールが、前記プログラム中の前記発生原因を示す、請求項１に記載の方法。
【請求項８】
前記第１のコールパス及び前記第２のコールパスを取得するステップの前に、
前記オブジェクトがアクティブであるかどうかを判定するステップをさらに含み、
前記アクティブであることに応じて、前記第１のコールパスを取得するステップ及び前記第２のコールパスを取得するステップが実行される、請求項１に記載の方法。
【請求項９】
前記求められた共通部分を表示部に表示するステップをさらに含む、請求項１に記載の方法。
【請求項１０】
前記表示するステップが、前記オブジェクトが他の１つのオブジェクトからのみ参照されている場合、前記オブジェクトと前記他の１つオブジェクトとを合併させて表示するステップを含む、請求項９に記載の方法。
【請求項１１】
プログラムによるメモリ消費の状況をユーザに提示するコンピュータ・システムにおいて、前記プログラム中の上記メモリ消費の発生原因を突き止めることを可能にする方法であって、
前記プログラムが実行され、該プログラムのオブジェクトを生成するコード実行に至ることに応じて、記憶部に、前記オブジェクトの生成にかかわる第１のコールパスに対応する第１のＩＤを格納するステップと、
前記プログラムが実行され、該プログラムの前記オブジェクトを接続するコード実行に至ることに応じて、前記記憶部に、前記オブジェクトへの接続にかかわる第２のコールパスに対応する第２のＩＤを格納するステップと
を含み、
前記第１のＩＤに対応する第１のコールパス及び前記第２のＩＤに対応する第２のコールパスの共通部分が前記プログラム中の前記発生原因を示す、前記方法。
【請求項１２】
前記第１のＩＤを格納するステップにおいて、前記第１のＩＤの代わりに第１のコールパスが格納され、
前記第２のＩＤを格納するステップにおいて、前記第２のＩＤの代わりに第２のコールパスが格納され、
前記第１のコールパス及び前記第２のコールパスの共通部分が前記プログラム中の前記発生原因を示す、請求項１１に記載の方法。
【請求項１３】
前記第１のＩＤ及び前記第２のＩＤが、確率的呼び出し文脈技法によって作成される、請求項１１に記載の方法。
【請求項１４】
前記コンピュータ・システムが、コールパスと該コールパスに対応するＩＤとの組を含む対応表を有し、
前記第１のコールパスを格納するステップが、前記第１のコールパスと前記第１のＩＤとの組を前記対応表に登録するステップをさらに含み、
前記第２のコールパスを格納するステップが、前記第２のコールパスを前記第２のＩＤとの組を前記対応表に登録するステップをさらに含む、請求項１１に記載の方法。
【請求項１５】
前記第１のＩＤを格納するステップにおいて、該第１のＩＤが前記オブジェクトに対応付けられた前記記憶部の領域に格納され、又は
前記第２のＩＤを格納するステップにおいて、該第２のＩＤが、前記オブジェクトが接続する他のオブジェクトに対応付けられた前記記憶部の領域に格納される、請求項１１に記載の方法。
【請求項１６】
前記第２のＩＤを格納するステップにおいて、前記第２のＩＤが前記オブジェクトに対応付けられた前記記憶部の領域に格納される、請求項１１に記載の方法。
【請求項１７】
前記第１のコールパスを格納するステップが、前記オブジェクトを生成するコード中の位置及び前記オブジェクトのデータ型の少なくとも１を格納するステップをさらに含み、
前記第２のコールパスを格納するステップが、前記オブジェクトを接続するコード中の位置及び前記オブジェクトのデータ型の少なくとも１を格納するステップをさらに含む、請求項１１に記載の方法。
【請求項１８】
プログラムによるメモリ消費の状況を提示可能であり、前記プログラム中の前記メモリ消費の発生原因を突き止めるためのコンピュータ・システムであって、
記憶部から、オブジェクトの生成にかかわる第１のコールパス及び該オブジェクトへの接続にかかわる第２のコールパスを取得する取得部と、
前記取得された第１及び第２のコールパスの共通部分を求める計算部であって、前記共通部分が前記プログラム中の前記発生原因を示す、前記計算部と
を含む、前記コンピュータ・システム。
【請求項１９】
プログラムによるメモリ消費の状況を提示可能なコンピュータ・システムにおいて、前記プログラム中の前記メモリ消費の発生原因を突き止める方法であって、
前記プログラムが実行され、該プログラムのオブジェクトを生成するコード実行に至ることに応じて、記憶部に、前記オブジェクトの生成にかかわる第１のコールパス又は該第１のコールパスに対応する第１のＩＤを格納するステップと、
前記プログラムが実行され、該プログラムの前記オブジェクトを接続するコード実行に至ることに応じて、前記記憶部に、前記オブジェクトへの接続にかかわる第２のコールパス又は該第２のコールパスに対応する第２のＩＤを格納するステップと、
前記記憶部から、前記格納された第１のコールパス、又は前記格納された第１のＩＤに対応する第１のコールパスを取得するステップと、
前記記憶部から、前記格納された第２のコールパス、又は前記格納された第２のＩＤに対応する第２のコールパスを取得するステップと、
前記取得された第１及び第２のコールパスの共通部分を求めるステップであって、前記共通部分が前記プログラム中の前記発生原因を示す、前記求めるステップと、
前記求められた共通部分を表示部に表示するステップと
を含む、前記方法。
【請求項２０】
コンピュータ・システムに、請求項１〜１７及び１９のいずれか一項に記載の方法の各ステップを実行させることを含む、コンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プログラム中のメモリ消費の発生原因を突き止める方法、並びにそのコンピュータ・システム及びコンピュータ・プログラムに関する。
【背景技術】
【０００２】
プログラムのパフォーマンスを調整する目的のために、ユーザが該プログラムによるメモリ消費の実行プロファイルをとる場合がある。上記場合に、ユーザは、あるメモリ消費が上記プログラム中の何に起因しているかを特定したいと考えることがよくある。なぜならば、上記特定ができれば、パフォーマンス上の問題となっているメモリ消費を減らすために、ユーザは該メモリ消費の原因となっているプログラムロジックに対して集中して対策を立てやすいからである。
【０００３】
ユーザが、例えばプロファイラによる従来の実行プロファイル手法を用いることにより、プログラム実行中のある時点でのメモリ消費が問題視されているオブジェクトを生成するに至ったメソッドを突き止めること、及び該メソッドの呼び出し元のメソッドを根元まで突き止めることは容易である。例えばＪａｖａ（商標）の場合、ユーザは、Ｊａｖａ（商標）２  ＳＥ  ６．０に付属しているhprofというプロファイラを用いて、例えばプログラム中のオブジェクトを生成している箇所において、該オブジェクトのＩＤ及び該箇所に至るまでのメソッド呼び出しスタックを記録させる。該記録により、ユーザは、問題視されうるオブジェクトのＩＤ及び該オブジェクトを生成するに至るまでのメソッドについての呼び出しスタックを得ることができる。
【０００４】
しかし、上記従来の実行プロファイル手法では、ユーザは、上記問題視されているオブジェクトがプログラムの実行中にメモリ上になぜ居残り、そして問題視されるに至ったのかについて分からない。つまり、ユーザは、例えば「メモリ上に居残り続けるようなテーブルに、オブジェクトを登録してしまった。」という上記問題視されるに至った原因を、上記記録から求めることができない。
【０００５】
下記特許文献１に記載の手法では、サーバへのリクエスト処理中に生成されたオブジェクトについて、該リクエストのＩＤ及び上記生成に至るまでのメソッド呼び出しスタックが記録される。そして、上記リクエストの処理が終了しているにもかかわらずメモリ上に居残っているオブジェクトがある場合、該オブジェクトがメモリリークの疑いのあるオブジェクトとされる。該オブジェクトは、該オブジェクトの生成に至るまでの上記記録されたメソッド呼び出しスタックとともに提示される。特許文献１は、上記従来の実行プロファイル手法と対応する。
【０００６】
下記非特許文献１は、確率的呼び出し文脈（Probabilistic Calling Context、以下、ＰＣＣ）と呼ばれる技法を記載する。ＰＣＣは、実行プロファイル取得時のオーバヘッドを数パーセントに抑えて実現するための技法として知られている。ＰＣＣは、ある２つの呼び出し文脈が高い確率で同じであることを検証することを目的とする。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００８−１３４７０９号公報
【非特許文献】
【０００８】
【非特許文献１】Bond, M. D., McKinley, K. S., Probabilistic Calling Context, In Proceedings of OOPSLA 2007, the 22nd Annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications, Montreal, Quebec, Canada, pp.97-112, October 21-25, 2007.
【発明の概要】
【発明が解決しようとする課題】
【０００９】
従来の実行プロファイル手法では、ユーザは、プログラム実行中のある時点でのメモリ消費が問題視されているオブジェクトが、なぜプログラムの実行中にメモリ上に居残りそして問題視されるに至ったのかは分からない。よって、上記問題視されるに至った原因を特定するための情報を保持し、該情報をユーザに提示する方法が求められている。
【課題を解決するための手段】
【００１０】
本発明は、プログラムによるメモリ消費の状況を提示可能なコンピュータ・システムにおいて、上記プログラム中の上記メモリ消費の発生原因を突き止める方法を提供する。該方法は、コンピュータ・システムに下記ステップを実行させることを含む。該ステップは、
記憶部から、オブジェクトの生成にかかわる第１のコールパスを取得するステップと、
上記記憶部から、上記オブジェクトへの接続にかかわる第２のコールパスを取得するステップと、
上記取得された第１及び第２のコールパスの共通部分を求めるステップであって、上記共通部分が上記プログラム中の上記発生原因を示す、上記求めるステップと
を含む。
【００１１】
本発明の１つの実施態様では、上記コンピュータ・システムが、コールパスと該コールパスに対応するＩＤとの組を含む対応表を有し、
上記第１のコールパスを取得するステップにおいて、上記第１のコールパスの代わりに第１のＩＤが取得され、
上記第２のコールパスを取得するステップにおいて、上記第２のコールパスの代わりに第２のＩＤが取得され、
上記求めるステップが、上記対応表から、上記取得された第１のＩＤに対応する第１のコールパス及び上記取得された第２のＩＤに対応する第２のコールパスをそれぞれ求めるステップをさらに含み、それによって、上記求めるステップにおいて、上記求められた第１及び第２のコールパスの共通部分が求められる。
【００１２】
本発明の１つの実施態様では、上記第１のコールパスを取得するステップにおいて、上記第１のコールパスの代わりに第１のＩＤが取得され、
上記第２のコールパスを取得するステップにおいて、上記第２のコールパスの代わりに第２のＩＤが取得される。また、上記方法は、コンピュータ・システムにさらに下記ステップを実行させることを含む。該ステップは、
上記共通部分を求めるステップの前に、上記プログラムの実行時における呼び出しの関係を表す第３のコールパスからＩＤを算出するステップと、
上記算出されたＩＤと上記取得された第１のＩＤとが一致する場合、上記第３のコールパスを第１のコールパスとし、上記算出されたＩＤと上記取得された第２のＩＤとが一致する場合、上記第３のコールパスを上記取得された第２のコールパスとするステップと
をさらに含む。
【００１３】
本発明の１つの実施態様では、上記第１のＩＤを取得するステップにおいて、該第１のＩＤが上記オブジェクトに対応付けられた上記記憶部の領域から取得される。
【００１４】
本発明の１つの実施態様では、上記第２のＩＤを取得するステップにおいて、該第２のＩＤが、上記オブジェクトが接続する他のオブジェクトに対応付けられた上記記憶部の領域から取得される。
【００１５】
本発明の１つの実施態様では、上記第２のＩＤを取得するステップにおいて、該第２のＩＤが上記オブジェクトに対応付けられた上記記憶部の領域から取得される。本発明の１つの実施態様では、該領域は、上記オブジェクトが接続する他のオブジェクトに関する領域である。
【００１６】
本発明の１つの実施態様では、上記共通部分に含まれる最新のコールが、上記プログラム中の上記発生原因を示す。
【００１７】
本発明の１つの実施態様では、上記方法は、コンピュータ・システムにさらに下記ステップを実行させることを含む。該ステップは、上記第１のコールパス及び上記第２のコールパスを取得するステップの前に、
上記オブジェクトがアクティブであるかどうかを判定するステップをさらに含み、
上記アクティブであることに応じて、上記第１のコールパスを取得するステップ及び上記第２のコールパスを取得するステップが実行される。
【００１８】
本発明の１つの実施態様では、上記方法は、コンピュータ・システムにさらに下記ステップを実行させることを含む。該ステップは、上記求められた共通部分を表示部に表示するステップを含む。
【００１９】
本発明の１つの実施態様では、上記表示するステップが、上記オブジェクトが他の１つのオブジェクトからのみ参照されている場合、上記オブジェクトと上記他の１つオブジェクトとを合併させて表示するステップを含む。
【００２０】
本発明はまた、プログラムによるメモリ消費の状況をユーザに提示するコンピュータ・システムにおいて、上記プログラム中の上記メモリ消費の発生原因を突き止めることを可能にする方法を提供する。該方法は、コンピュータ・システムに下記ステップを実行させることを含む。該ステップは、
上記プログラムが実行され、該プログラムのオブジェクトを生成するコード実行に至ることに応じて、記憶部に、上記オブジェクトの生成にかかわる第１のコールパスに対応する第１のＩＤを格納するステップと、
上記プログラムが実行され、該プログラムの上記オブジェクトを接続するコード実行に至ることに応じて、上記記憶部に、上記オブジェクトへの接続にかかわる第２のコールパスに対応する第２のＩＤを格納するステップと
を含む。ここで、上記第１のＩＤに対応する第１のコールパス及び上記第２のＩＤに対応する第２のコールパスの共通部分が上記プログラム中の上記発生原因を示す。
【００２１】
本発明の１つの実施態様では、上記第１のＩＤを格納するステップにおいて、上記第１のＩＤの代わりに第１のコールパスが格納され、
上記第２のＩＤを格納するステップにおいて、上記第２のＩＤの代わりに第２のコールパスが格納され、
上記第１のコールパス及び上記第２のコールパスの共通部分が上記プログラム中の上記発生原因を示す。
【００２２】
本発明の１つの実施態様では、上記第１のＩＤ及び上記第２のＩＤが、確率的呼び出し文脈技法によって作成される。
【００２３】
本発明の１つの実施態様では、上記コンピュータ・システムが、コールパスと該コールパスに対応するＩＤとの組を含む対応表を有し、
上記第１のコールパスを格納するステップが、上記第１のコールパスと上記第１のＩＤとの組を上記対応表に登録するステップをさらに含み、
上記第２のコールパスを格納するステップが、上記第２のコールパスを上記第２のＩＤとの組を上記対応表に登録するステップをさらに含む。
【００２４】
本発明の１つの実施態様では、上記第１のＩＤを格納するステップにおいて、該第１のＩＤが上記オブジェクトに対応付けられた上記記憶部の領域に格納される。
【００２５】
本発明の１つの実施態様では、上記第２のＩＤを格納するステップにおいて、該第２のＩＤが、上記オブジェクトが接続する他のオブジェクトに対応付けられた上記記憶部の領域に格納される。
【００２６】
本発明の１つの実施態様では、上記第２のＩＤを格納するステップにおいて、該第２のＩＤが上記オブジェクトに対応付けられた上記記憶部の領域に格納される。
【００２７】
本発明の１つの実施態様では、上記第１のコールパスを格納するステップが、上記オブジェクトを生成するコード中の位置及び上記オブジェクトのデータ型の少なくとも１を格納するステップをさらに含み、
上記第２のコールパスを格納するステップが、上記オブジェクトを接続するコード中の位置及び上記オブジェクトのデータ型の少なくとも１を格納するステップをさらに含む。
【００２８】
本発明はまた、プログラムによるメモリ消費の状況を提示可能なコンピュータ・システムにおいて、上記プログラム中の上記メモリ消費の発生原因を突き止める方法を提供する。該方法は、コンピュータ・システムに下記ステップを実行させることを含む。該ステップは、
上記プログラムが実行され、該プログラムのオブジェクトを生成するコード実行に至ることに応じて、記憶部に、上記オブジェクトの生成にかかわる第１のコールパス又は該第１のコールパスに対応する第１のＩＤを格納するステップと、
上記プログラムが実行され、該プログラムの上記オブジェクトを接続するコード実行に至ることに応じて、上記記憶部に、上記オブジェクトへの接続にかかわる第２のコールパス又は該第２のコールパスに対応する第２のＩＤを格納するステップと、
上記記憶部から、上記格納された第１のコールパス、又は上記格納された第１のＩＤに対応する第１のコールパスを取得するステップと、
上記記憶部から、上記格納された第２のコールパス、又は上記格納された第２のＩＤに対応する第２のコールパスを取得するステップと、
上記取得された第１及び第２のコールパスの共通部分を求めるステップであって、上記共通部分が上記プログラム中の上記発生原因を示す、上記求めるステップと、
上記求められた共通部分を表示部に表示するステップと
を含む。
【００２９】
本発明はまた、コンピュータ・システムに、上記のいずれか一つに記載の方法の各ステップを実行させることを含むコンピュータ・プログラムを提供する。
【００３０】
本発明はまた、プログラムによるメモリ消費の状況を提示可能であり、上記プログラム中の上記メモリ消費の発生原因を突き止めるための上記コンピュータ・システムを提供する。該コンピュータ・システムは、
記憶部から、オブジェクトの生成にかかわる第１のコールパス及び該オブジェクトへの接続にかかわる第２のコールパスを取得する取得部と、
上記取得された第１及び第２のコールパスの共通部分を求める計算部であって、上記共通部分が上記プログラム中の上記発生原因を示す、上記計算部と
を含む。
【００３１】
本発明の１つの実施態様では、上記コンピュータ・システムが、コールパスと該コールパスに対応するＩＤとの組を含む対応表を有し、
上記取得部が、上記第１のコールパスの代わりに第１のＩＤを取得し、及び
上記第２のコールパスの代わりに第２のＩＤを取得し、
上記計算部が、上記対応表から、上記取得された第１のＩＤに対応する第１のコールパス及び上記取得された第２のＩＤに対応する第２のコールパスをそれぞれ求める。それによって、上記求められた第１及び第２のコールパスの共通部分が求められる。
【００３２】
本発明の１つの実施態様では、上記取得部が、上記第１のコールパスの代わりに第１のＩＤを取得し、及び上記第２のコールパスの代わりに第２のＩＤをする。また、上記コンピュータ・システムが、共通部分を求める前に、上記プログラムの実行時における呼び出しの関係を表す第３のコールパスからＩＤを算出する作成部を含む。上記計算部は、上記算出されたＩＤと上記取得された第１のＩＤとが一致する場合、上記第３のコールパスを第１のコールパスとし、上記算出されたＩＤと上記取得された第２のＩＤとが一致する場合、上記第３のコールパスを上記取得された第２のコールパスとする。
【００３３】
本発明の１つの実施態様では、上記取得部は、上記第１のＩＤを上記オブジェクトに対応付けられた上記記憶部の領域から取得する。
【００３４】
本発明の１つの実施態様では、上記取得部は、上記第２のＩＤを、上記オブジェクトが接続する他のオブジェクトに対応付けられた上記記憶部の領域から取得する。
【００３５】
本発明の１つの実施態様では、上記取得部は、上記第２のＩＤを、上記オブジェクトに対応付けられた上記記憶部の領域から取得する。本発明の１つの実施態様では、該領域は、前記オブジェクトが接続する他のオブジェクトに関する領域である。
【００３６】
本発明の１つの実施態様では、上記コンピュータ・システムは、
上記オブジェクトがアクティブであるかどうかを判定する判定部をさらに含み、
上記取得部は、上記アクティブであることに応じて、上記第１のコールパス及び上記第２のコールパスを取得する。
【００３７】
本発明の１つの実施態様では、上記コンピュータ・システムは、上記求められた共通部分を表示する表示部をさらに含む。
【００３８】
本発明の１つの実施態様では、上記表示部が、上記オブジェクトが他の１つのオブジェクトからのみ参照されている場合、上記オブジェクトと上記他の１つオブジェクトとを合併させて表示する。
【００３９】
本発明はまた、プログラムによるメモリ消費の状況をユーザに提示し、上記プログラム中の上記メモリ消費の発生原因を突き止めることを可能にするコンピュータ・システムを提供する。該コンピュータ・システムは、
上記プログラムが実行され、該プログラムのオブジェクトを生成するコード実行に至ることに応じて、記憶部に、上記オブジェクトの生成にかかわる第１のコールパス又は該第１のコールパスに対応する第１のＩＤを格納し、及び上記プログラムが実行され、該プログラムの上記オブジェクトを接続するコード実行に至ることに応じて、上記記憶部に、上記オブジェクトへの接続にかかわる第２のコールパス又は該第２のコールパスに対応する第２のＩＤを格納する格納部と、
を含む。ここで、上記第１及び第２のコールパスの共通部分、又は上記第１のＩＤに対応する第１のコールパス及び上記第２のＩＤに対応する第２のコールパスの共通部分が上記プログラム中の上記発生原因を示す。
【００４０】
本発明の１つの実施態様では、上記コンピュータ・システムが、コールパスと該コールパスに対応するＩＤとの組を含む対応表を有し、
上記コンピュータ・システムが、上記第１のコールパスと上記第１のＩＤとの組、及び上記第２のコールパスを上記第２のＩＤとの組を対応表に登録する。
【００４１】
本発明の１つの実施態様では、上記第１のＩＤが、上記オブジェクトに対応付けられた上記記憶部の領域に格納される。
【００４２】
本発明の１つの実施態様では、上記第２のＩＤが、上記オブジェクトが接続する他のオブジェクトに対応付けられた上記記憶部の領域に格納される。
【００４３】
本発明の１つの実施態様では、上記第２のＩＤが、上記オブジェクトに対応付けられた上記記憶部の領域に格納される。本発明の１つの実施態様では、該領域は、前記オブジェクトが接続する他のオブジェクトに関する領域である。
【００４４】
本発明の１つの実施態様では、上記格納部が、上記オブジェクトを生成するコード中の位置及び上記オブジェクトのデータ型の少なくとも１を格納する。本発明の１つの実施態様では、上記格納部がまた、上記オブジェクトを接続するコード中の位置及び上記オブジェクトのデータ型の少なくとも１を格納する。
【発明の効果】
【００４５】
本発明の実施態様によれば、例えばプロファイラを用いてプログラムによるメモリの消費状況が提示される場合に、メモリ消費発生の原因となっているプログラム中の因子が、従来の実行プロファイル手法を使用した場合に比べより限定して提示される。
【図面の簡単な説明】
【００４６】
【図１Ａ】本発明の実施態様における、プログラムによるメモリ消費の状況を提示するための情報を記憶部に格納するシステムが有する機能を図示する機能ブロック図の例を示す。
【図１Ｂ】本発明の実施態様における、プログラムによるメモリ消費の状況を提示するシステムが有する機能を図示する機能ブロック図の例を示す。
【図１Ｃ】本発明の実施態様における、図１Ａに示すシステムがＪａｖａ（商標）プログラム実行系上で構成される場合の構成図の例を示す。
【図１Ｄ】本発明の実施態様における、図１Ｃに示す生成文脈表及び接続文脈表の例を示す。
【図１Ｅ】本発明の実施態様における、図１Ｃに示す滞留因子表の例を示す。
【図１Ｆ】本発明の実施態様における、図１Ｃに示すヒープメモリ上のオブジェクトの構成例を示す。
【図２】本発明の実施態様における、図１Ａ及び図１Ｂに示すシステム上で実行される処理の概要を説明するための図を示す。
【図３Ａ】図１Ａに示すオブジェクトを生成するnewオペレーションについての本発明の実施態様におけるフローチャートの例、及び従来の実施態様におけるフローチャートの例を示す。
【図３Ｂ】図１Ａに示すオブジェクトを接続するputfieldオペレーションについての本発明の実施態様におけるフローチャートの例、及び従来の実施態様におけるフローチャートの例を示す。
【図４】本発明の実施態様における、図１Ｃに記載の３つの表を作成する方法を説明するための図を示す。
【図５Ａ】本発明の実施態様における、図１Ｃに示す滞留因子表を作成する処理のフローチャートの例を示す。
【図５Ｂ】本発明の実施態様における、図５Ａのステップ５０４の処理の詳細なフローチャートの例を示す。
【図５Ｃ】本発明の実施態様における、図５Ａのステップ５０５の処理の詳細なフローチャートの例を示す。
【図６Ａ】本発明の実施態様における、図１Ａに示す対応表を作成するフローチャートの例を示す。
【図６Ｂ】本発明の実施態様における、図６Ａのステップ６０２の処理の詳細なフローチャートの例を示す。
【図７Ａ】本発明の実施態様における、メモリ消費の発生原因の、図１Ｂに示す表示部における表示例を示す。
【図７Ｂ】本発明の実施態様における、図７Ａに示す表示例において、ユーザがオブジェクト群を示す箱の合併の動作を行った場合の例を示す。
【図７Ｃ】本発明の実施態様における、図７Ａに示す表示例において、ユーザが呼び出し文脈の合併の動作を行った場合の例を示す。
【図７Ｄ】本発明の実施態様における、ツールによるソースコード中の滞留原因の提示例及びユーザによる修正の様子を示す。
【図８】本発明の実施態様における、図１Ａ〜図１Ｂに示すシステムのハードウェアのブロック図を示す。
【発明を実施するための形態】
【００４７】
本発明の実施態様において、「プログラム」とは、オブジェクトを取り扱うことが可能なプログラム言語で作成されたプログラムである。該プログラムは、上記オブジェクトを参照可能な記憶域に割り付ける処理系で実行される。上記参照可能な記憶域は、例えばヒープメモリであるがこれに限定されない。プログラムは、例えばオブジェクト指向言語を含む。プログラムは、例えばＪａｖａ（商標）、Ｃ＃、Ｃ＋＋又はＲｕｂｙで作成されうるが、これらに限定されない。また、上記処理系は、例えばＪａｖａ（商標）仮想マシン（ＪＶＭ）又はＭｉｃｒｏｓｏｆｔ（商標）.ＮＥＴ  Ｆｒａｍｅｗｏｒｋであるが、これらに限定されない。
【００４８】
本発明の実施態様において、「オブジェクト」とは、データ間の参照関係を保持することができるデータ構造をもつデータである。該データは、例えば配列、構造体及びオブジェクト指向型言語におけるオブジェクトであるがこれらに限定されない。オブジェクトは、参照可能な記憶域に割り付けられる。オブジェクトは、プログラム上の抽象化された手続きの対象を具体化したものである。プログラム上の抽象化された手続きの対象とは、例えばクラスであるがこれに限定されない。上記具体化とは、例えば上記クラスに対応するデータ領域を用意することである。オブジェクトは、上記プログラムの実行時に記憶域に割り付けられる。プログラムの実行時に割り付けられる記憶域は上記参照可能な記憶域と同じであってもよく又は異なっていてもよく、例えばヒープメモリであるがこれに限定されない。
【００４９】
本発明の実施態様において、「オブジェクトの生成」とは、オブジェクトに対応するデータ領域を用意することをいう。オブジェクトの生成は、オブジェクトを上記記憶域に割り付ける処理のことをいう。
オブジェクトの生成は、例えばＪａｖａ（商標）のソースコードにおいて、newメソッド及びcreateメソッドによって記述されるがこれらに限定されない。オブジェクトの生成はまた、例えばＪａｖａ（商標）のバイトコードにおいて、newオペレーションによって実行されるがこれに限定されない。
【００５０】
本発明の実施態様において、「オブジェクトへの接続」とは、オブジェクトＸが他のオブジェクトＹから参照されることをいう。オブジェクトへの接続は、例えばオブジェクトＸにオブジェクトＹを指す情報を格納する又はオブジェクトＹにオブジェクトＸを指す情報を格納する処理のことをいう。上記オブジェクトを指す情報とは、例えばオブジェクトが割り付けられた記憶域を指すポインタであるがこれに限定されない。ここで、上記格納先は、それぞれのオブジェクトが割り当てられた記憶域でもよいし、それぞれのオブジェクトに対応付けられた記憶域でもよい。
オブジェクトへの接続は、例えばＪａｖａ（商標）のソースコードにおいて、オブジェクトＸに含まれるメソッド又は変数にオブジェクトＹを渡すことを記述することによって実現されるがこれに限定されない。オブジェクトへの接続はまた、例えばＪａｖａ（商標）のバイトコードにおいて、putfield、putstatic又はaastoreオペレーションによって実行されるが、これらに限定されない。
【００５１】
本発明の実施態様において、「オブジェクトがアクティブ」とは、プログラム実行中のある時点において、オブジェクトが有効であることをいう。プログラム実行中のある時点において、オブジェクトが使用されている場合、該オブジェクトはアクティブでありうる。また、一般的なガーベジコレクション（ＧＣ）では、アクティブ・オブジェクトとガベージ・オブジェクトとが判別される。アクティブなオブジェクトは、上記判別においてアクティブ・オブジェクトに判別されるオブジェクトである。一方、ガベージ・オブジェクトは、上記判別においてアクティブ・オブジェクトに判別されないオブジェクトである。
【００５２】
本発明の実施態様において、「コールパス」とは、プログラムにおける階層的な呼び出しの関係についての情報である。コールパスは、プログラム中のある処理に注目した場合の、該処理が実行されるまでに呼び出されたコールの流れを表す。コールは、サブルーチン、メソッド及び呼び出しともいう。またコールパスは、文脈又は呼び出し文脈ともいう。
【００５３】
プログラムにおいて、例えば、第１のメソッド内で第２のメソッドが呼び出され、第２のメソッド内で第３のメソッド及び第４のメソッドが呼び出されるとする。また、第３のメソッドでは、第１の処理が実行され、第４のメソッドでは、第２の処理が実行されるとする。
上記プログラムの例では、第１の処理に注目した場合のコールパス（以下、コールパスＡ）は、「第１のメソッド→第２のメソッド→第３のメソッド→第１の処理」である。第２の処理に注目した場合のコールパス（以下、コールパスＢ）は、「第１のメソッド→第２のメソッド→第４のメソッド→第２の処理」である。
「コールパスの共通部分」とは、コールパス間で共通する部分である。例えば、上記コールパスＡと上記コールパスＢとの共通部分は、「第１のメソッド→第２のメソッド」、「第１のメソッド」及び「第２のメソッド」の何れかである。
「共通部分に含まれる最新のコール」とは、上記共通部分の中で、最も直近に実行されたコールである。例えば、上記コールパスＡと上記コールパスＢとの共通部分に含まれる最新のコールは、「第２のメソッド」である。
【００５４】
本発明の実施態様において、「コールパスに対応するＩＤ」とは、コールパスと対応付けられた値である。コールパスに対応するＩＤからコールパスが特定される。該特定は、例えばコールパスに対応するＩＤとコールパスとの組を記載する対応表が参照されることによって実行される。コールパスに対応するＩＤは、例えば後述のＰＣＣ  ＩＤであるがこれに限定されない。
【００５５】
本発明の実施態様において、「プログラムの解析結果」とは、コールに注目してプログラムを解析した結果である。
【００５６】
以下、図面に従って、本発明の実施態様を説明する。本実施態様は、本発明の好適な態様を説明するためのものであり、本発明の範囲をここで示すものに限定する意図はないことを理解されたい。また、以下の図を通して、特に断らない限り、同一の符号は、同一の対象を指す。
【００５７】
図１Ａは、本発明の実施態様における、プログラムによるメモリ消費の状況を提示するための情報を記憶部に格納するシステムが有する機能を図示する機能ブロック図の例を示す。
コンピュータ・システム（１０１）は、記憶部（図示せず）、第１の格納部（１１２）、第２の格納部（１１３）及び作成部（１１４）を含む。
記憶部（図示せず）は、例えばメモリ（１０２）又は補助記憶装置である。
【００５８】
メモリ（１０２）は、アプリケーションが自由に利用できる記憶領域を有する主記憶装置である。上記記憶領域には、プログラム（１０３）、履歴データ（１０４）及び少なくとも１のオブジェクト（１０５ａ、１０５ｂ、・・・、１０５ｎ）が格納されうる。上記記憶領域には、オブジェクトに対応付けられた領域（１０６ａ、１０６ｂ、・・・、１０６ｎ）が用意される。また、上記記憶領域には、対応表（１１１）が格納されてもよい。
なお、上記記憶領域の一部は、メモリ（１０２）とは異なる補助記憶装置の記憶領域であってもよい。補助記憶装置は、例えばハードディスクドライブ、ソリッドステートドライブであるが、これに限定されない。
【００５９】
プログラム（１０３）は、メモリ消費状況が監視される対象のプログラムである。プログラム（１０３）は、オブジェクトを生成する処理及びオブジェクトとオブジェクトとを接続する処理を含む。プログラム（１０３）は、コンピュータ・システム（１０１）によって、メモリ（１０２）内に読み込まれ、そして中央演算処理装置（ＣＰＵ）で実行される。
【００６０】
履歴データ（１０４）は、プログラム（１０３）における、サブルーチンの呼び出しの履歴、オブジェクトを生成する処理の実行の履歴及びオブジェクトとオブジェクトとを接続する処理の実行の履歴が記録されたデータである。履歴データ（１０４）は、プログラム（１０３）の実行時にメモリ（１０２）上に保存される。なお、履歴データ（１０４）は、例えばログファイルとして、記憶部（図示せず）に保存されてもよい。
【００６１】
オブジェクト（１０５ａ、１０５ｂ、・・・、１０５ｎ）は、オブジェクトを生成する処理ごとに、メモリ（１０２）にそれぞれ割り付けられる、構造をもつデータである。オブジェクト（１０５ａ、１０５ｂ、・・・、１０５ｎ）は、オブジェクトを解放する処理又はガーベジコレクションによりメモリから解放されうる。
【００６２】
オブジェクトに対応付けられた領域（１０６ａ、１０６ｂ、・・・、１０６ｎ）は、オブジェクトにかかわるコールパスについての情報が格納される記憶領域である。オブジェクトに対応付けられた領域（１０６ａ、１０６ｂ、・・・、１０６ｎ）は、オブジェクト（１０５ａ、１０５ｂ、・・・、１０５ｎ）ごとに記憶領域に割り当てられる。オブジェクトに対応付けられた領域（１０６ａ、１０６ｂ、・・・、１０６ｎ）は、オブジェクト（１０５ａ、１０５ｂ、・・・、１０５ｎ）それぞれが割り付けられた領域の一部であってもよい。オブジェクトに対応付けられた領域（１０６ａ、１０６ｂ、・・・、１０６ｎ）には、第１のコールパス（１０７）、第１のＩＤ（１０８）、第２のコールパス（１０９）及び第２のＩＤ（１１０）が格納されうる。
【００６３】
第１のコールパス（１０７）は、プログラム（１０３）において、オブジェクトを生成するコード実行に至る呼び出しの流れを表す情報である。該情報は、例えばプログラム（１０３）又は履歴データ（１０４）に含まれうる。
第１のＩＤ（１０８）は、第１のコールパス（１０７）と１対１で対応するＩＤである。該ＩＤは、例えばＰＣＣを利用することによって作成されるＰＣＣ  ＩＤであるが、これに限定されない。
第２のコールパス（１０９）は、プログラム（１０３）において、オブジェクト（１０５ａ）が他のオブジェクト（１０５ｂ）に接続する又接続されるところのコード実行に至る呼び出しの流れを表す情報である。該情報は、例えば履歴データ（１０４）に含まれ又はプログラム（１０３）に記述されうる。
第２のＩＤ（１１０）は、第２のコールパス（１０９）と１対１で対応するＩＤである。該ＩＤは、例えばＰＣＣ  ＩＤであるが、これに限定されない。
【００６４】
対応表（１１１）は、コールパスとＩＤとの対応を表す。対応表（１１１）は、コールパスと該コールパスに対応するＩＤとの組を含む。対応表（１１１）は、ユーザによって作成されてもよいし、プログラム（１０３）の実行中に履歴データ（１０４）として残されてもよいし、プログラム（１０３）に対して任意のロジックが実行されることによって作成されてもよい。任意のロジックは、例えば、ＰＣＣを用いて、コールパスから該コールパスに対応するＰＣＣ  ＩＤを求めるロジックである。例えば、作成部（１１４）が、上記任意のロジックを実行する。なお、対応表（１１１）は、例えばテキストファイルとして、記憶部（図示せず）に保存されてもよい。
【００６５】
第１の格納部（１１２）は、プログラム（１０３）において、オブジェクトを生成するコード実行に至ることに応じて、作成部（１１４）からＩＤを取得する。第１の格納部（１１２）は、上記取得したＩＤを第１のＩＤ（１０８）として、オブジェクトに対応付けられた領域（１０６ａ、１０６ｂ、・・・、１０６ｎ）に格納する。第１の格納部（１１２）は、上記ＩＤを取得することに換えて又は取得することとともに、プログラム（１０３）又は履歴データ（１０４）からコールパスを取得してもよい。第１の格納部（１１２）は、上記取得したコールパスを第１のコールパス（１０７）として、オブジェクトと対応付けられた領域（１０６ａ、１０６ｂ、・・・、１０６ｎ）に格納してもよい。
ここで、オブジェクトに対応付けられた領域（１０６ａ、１０６ｂ、・・・、１０６ｎ）がオブジェクト（１０５ａ、１０５ｂ、・・・、１０５ｎ）に含まれる場合、第１のコールパス（１０７）又は第１のＩＤ（１０８）の少なくとも１つは、オブジェクト（１０５ａ、１０５ｂ、・・・、１０５ｎ）の例えばオブジェクト・ヘッダに格納されるがこれに限定されない。
【００６６】
第２の格納部（１１３）は、プログラム（１０３）において、オブジェクトを接続するコード実行に至ることに応じて、作成部（１１４）からＩＤを取得する。第２の格納部（１１３）は、上記取得したＩＤを第２のＩＤ（１１０）として、オブジェクトに接続される他のオブジェクトに対応付けられた領域又はオブジェクトに対応付けられた領域の少なくとも１の領域（以下、接続に関する領域）に格納する。例えばオブジェクト（１０５ａ）がオブジェクト（１０５ｂ）に接続される場合、第２の格納部（１１３）は、上記取得したＩＤを第２のＩＤ（１１０）として、オブジェクト（１０５ａ）に対応付けられた領域（１０６ａ）又はオブジェクト（１０５ｂ）に対応付けられた領域（１０６ｂ）の少なくとも１に格納する。第２の格納部（１１３）は、上記ＩＤを取得することに換えて又は取得することとともに、プログラム（１０３）又は履歴データ（１０４）からコールパスを取得してもよい。第２の格納部（１１３）は、上記取得したコールパスを第２のコールパス（１０９）として、接続に関する領域に格納してもよい。
ここで、例えばオブジェクト（１０５ａ）がオブジェクト（１０５ｂ）に接続される上記例において、オブジェクトに対応付けられた領域（１０６ａ）がオブジェクト（１０５ａ）に含まれ且つオブジェクトに対応付けられた領域（１０６ｂ）がオブジェクト（１０５ｂ）に含まれる場合、第２のコールパス（１０９）又は第２のＩＤ（１１０）の少なくとも１つは、オブジェクト（１０５ａ）の例えばオブジェクト・ヘッダに格納されるか又はオブジェクト（１０５ｂ）の例えばフィールド・ヘッダに格納されるがこれに限定されない。
【００６７】
作成部（１１４）は、プログラム（１０３）又は履歴データ（１０４）からコールパスを取得し、該コールパスに対応するＩＤを作成する。作成部（１１４）は、例えばプログラム（１０３）又は履歴データ（１０４）に対して任意のロジックを使用することで、上記ＩＤを作成してもよい。任意のロジックは、例えばＰＣＣを用いたロジックである。作成部（１１４）は、取得したコールパスと作成したＩＤとの組を対応表（１１１）に格納してもよい。作成部（１１４）は、第１の格納部（１１２）又は第２の格納部（１１３）からの要求に応じて、作成したＩＤを第１の格納部（１１２）又は第２の格納部（１１３）に送信する。
【００６８】
図１Ｂは、本発明の実施態様における、プログラムによるメモリ消費の状況を提示するシステムが有する機能を図示する機能ブロック図の例を示す。
コンピュータ・システム（１２１）は、メモリ（１０２）、第１の取得部（１２２）、第２の取得部（１２３）、作成部（１１４）、計算部（１２４）、表示部（１２５）及び判定部（１２６）を含む。
コンピュータ・システム（１２１）は、図１Ａで説明したコンピュータ・システム（図１Ａ、１０１）と同一の機能を含むコンピュータ・システム、又はコンピュータ・システム（図１Ａ、１０１）とメモリ（１０２）を共有する若しくはメモリ（１０２）に含まれるデータが例えば複製されることによって同一に保たれるコンピュータ・システムである。また、メモリ（１０２）及び作成部（１１４）は、図１Ａで説明した通りである。
コンピュータ・システム（１２１）による処理は、コンピュータ・システム（１０１）による処理と並行して又はコンピュータ・システム（１０１）による処理が終了した後に実行される。
【００６９】
第１の取得部（１２２）は、オブジェクトに対応付けられた領域（１０６ａ、１０６ｂ、・・・、１０６ｎ）から、第１のコールパス（１０７）又は第１のＩＤ（１０８）の少なくとも１つ（以下、第１のコールパスに関する情報）を取得する。そして、第１の取得部（１２２）は、上記取得した第１のコールパスに関する情報を計算部（１２４）に送信する。なお、上記取得は、判定部（１２６）から通知されるアクティブなオブジェクトについてのみ実行されてもよい。
【００７０】
第２の取得部（１２３）は、オブジェクトに対応付けられた領域（１０６ａ、１０６ｂ、・・・、１０６ｎ）から、第２のコールパス（１０９）又は第２のＩＤ（１１０）の少なくとも１つ（以下、第２のコールパスに関する情報）を取得する。そして、第２の取得部（１２３）は、上記取得した第２のコールパスに関する情報を計算部（１２４）に送信する。なお、上記取得は、判定部（１２６）から通知されるアクティブなオブジェクトについてのみ実行されてもよい。
【００７１】
計算部（１２４）は、上記送信された第１のコールパスに関する情報に第１のＩＤ（１０８）が含まれる場合、第１のＩＤ（１０８）を第１のコールパス（１０７）に変換する。計算部（１２４）はまた、第２のコールパスに関する情報に第２のＩＤ（１１０）が含まれる場合、第２のＩＤ（１１０）を第２のコールパス（１０９）に変換する。計算部（１２４）は、第１のＩＤ（１０８）と組のコールパス及び第２のＩＤ（１１０）と組のコールパスを対応表（１１１）から検索することによって上記変換を実行する。また、上記変換の別の態様として、計算部（１２４）は、作成部（１１４）にＩＤを作成させてもよい。計算部（１２４）は、作成されたＩＤと第１のＩＤ（１０８）又は第２のＩＤ（１１０）とが一致する場合に、作成元のコールパスを第１のコールパス（１０７）又は第２のコールパス（１０９）とすることで、上記変換を実行する。
次に、計算部（１２４）は、第１のコールパスに関する情報に含まれる第１のコールパス（１０７）又は上記変換された第１のコールパス（１０７）と、第２のコールパスに関する情報に含まれる第２のコールパス（１０９）又は上記変換された第２のコールパス（１０９）との共通部分を求める。計算部（１２４）は、該求めた共通部分を表示部（１２５）に送信する。計算部（１２４）は、第１のコールパス（１０７）及び第２のコールパス（１０９）の少なくとも１つをさらに表示部（１２５）に送信してもよい。
【００７２】
表示部（１２５）は、上記送信された共通部分又は該共通部分に含まれる最新のコールを、プログラム（１０３）におけるメモリ消費の発生原因として、例えばモニタに表示する。表示部（１２５）は、例えば計算部（１２４）から送信されうる第１のコールパス（１０７）、計算部（１２４）から送信されうる第２のコールパス（１０９）、プログラム（１０３）及び履歴データ（１０４）の少なくとも１つに含まれる情報を利用して、上記メモリ消費の発生原因を特定するためのユーザインタフェースを提供しうる。上記ユーザインタフェースにおいて、例えばオブジェクトを表示する場合、表示部（１２５）は、１つのオブジェクトＡからのみ参照されるオブジェクトＢをオブジェクトＡと合併させて表示しうる。
【００７３】
判定部（１２６）は、履歴データ（１０４）又はオブジェクト（１０５ａ、１０５ｂ、・・・、１０５ｎ）を参照し、アクティブなオブジェクトを求める。判定部（１２６）は、上記求めたアクティブなオブジェクトを第１の取得部（１２２）及び第２の取得部（１２３）に通知する。
上記通知を受けた第１の取得部（１２２）及び第２の取得部（１２３）は、アクティブなオブジェクトについての上記第１のコールパスに関する情報及び上記第２のコールパスに関する情報を取得しうる。
【００７４】
図１Ｃは、本発明の実施態様における、図１Ａに示すシステムがＪａｖａ（商標）プログラム実行系上で構成される場合の構成図の例を示す。なお、図１Ｃ中の楕円（１４１）で囲まれた範囲は、図１Ｂに示されたシステムにおける処理に対応する。図１Ｃ中の楕円（１４１）で囲まれた範囲については、後述の図１Ｄ及び図１Ｅの説明で述べる。
上記構成図では、従来のＪａｖａ（商標）プログラム実行系に加えて、実行プロファイル取得のためのコンポーネント及び該コンポーネントによって得られる表が追加されている。上記コンポーネントは、呼び出しスタック追跡部（１３３）、オブジェクト生成記録部（１３４）及びオブジェクト間接続記録部（１３５）である。上記表は、生成文脈表（１３８）、滞留因子表（１４０）及び接続文脈表（１３９）である。
【００７５】
アプリケーション・プログラム（１３１）は、メモリ消費の状況が調査されるプログラムである。アプリケーション・プログラム（１３１）は、例えばＪａｖａ（商標）バイトコードである。アプリケーション・プログラム（１３１）は、図１Ａにおけるプログラム（１０３）に対応する。
プログラム実行環境（１３２）は、コンピュータ・システムがアプリケーション・プログラム（１３１）を実行するために必要な環境である。プログラム実行環境（１３２）は、例えばＪＶＭ（Ｊａｖａ（商標）  Ｖｉｒｔｕａｌ  Ｍａｃｈｉｎｅ）である。プログラム実行環境（１０１）は、図１Ａのコンピュータ・システム（１０１）と対応する。
ヒープメモリ（１３６）は、アプリケーション・プログラム（１３１）に割り当てられたメモリ領域である。ヒープメモリ（１３６）には、例えばアプリケーション・プログラム（１３１）によって生成されるオブジェクトが記録される。ヒープメモリ（１３６）は、図１Ａにおけるメモリ（１０２）に対応する。上記記録されるオブジェクトは、図１Ａにおけるオブジェクト（１０５ａ〜１０５ｎ）に対応する。
【００７６】
呼び出しスタック追跡部（１３３）は、下記オブジェクト生成記録部（１３４）及びオブジェクト間接続記録部（１３５）による呼び出しスタックの記録を高速に実行させるためのコンポーネントである。ここで、呼び出しスタックの記録とは、図１Ａにおける履歴データ（１０４）に対応する。
呼び出しスタック追跡部（１３３）は、図１Ａにおける作成部（１１４）に対応する。呼び出しスタック追跡部（１３３）は、例えば確率的呼び出し文脈技法（ＰＣＣ）を用いて、メソッド呼び出しの過程を表す呼び出し文脈（コールパス）に対応するＩＤ（以下、呼び出し文脈ＩＤ）を作成する。上記作成は、アプリケーション・プログラム（１３１）上でメソッド呼び出しが実行されることに応じて行われる。
【００７７】
呼び出しスタック追跡部（１３３）が、上記ＰＣＣを用いて、呼び出し文脈ＩＤを作成する手順を以下に示す。
ステップ１．呼び出しスタック追跡部（１３３）は、メソッド実装ごとにＩＤを振る。該ＩＤは、例えばメモリ中の該メソッドの呼び出しコード先頭のアドレスでもよい。該アドレスをＩＤとする場合、上記ＩＤを振るための特別な処理は必要なく、自動でＩＤが得られる。
ステップ２．呼び出しスタック追跡部（１３３）は、呼び出し文脈ＩＤとして使用される変数（以下、Ｃ）を０で初期化する。
ステップ３．呼び出しスタック追跡部（１３３）は、アプリケーション・プログラム（１３１）上でメソッド呼び出しが実行されるごとに、Ｃの値を例えばスタックに積んで保全する。呼び出しスタック追跡部（１３３）はまた、古いＣ（以下、Ｃｏ）の値を用いて新しいＣ（以下、Ｃｎ）の値を計算する。例えば上記メソッド呼び出しが実行されたメソッドの実装ごとに振られたＩＤをＭとする場合、Ｃｎは、「Ｃｎ＝３＊Ｃｏ＋Ｍ」とする。
上記ステップ１〜ステップ３によって、呼び出し文脈ＩＤが作成される。
【００７８】
ここで、呼び出し文脈（コールパス）の実装のバリエーションとして、例えばオブジェクト生成時の呼び出し文脈（第１のコールパス）にオブジェクト生成のコード中の位置、例えばＪＶＭのプログラムカウンタが含まれてもよい。さらに、オブジェクト生成時の呼び出し文脈（第１のコールパス）にオブジェクトの型が含まれてもよい。プログラムカウンタ又はオブジェクトの型が含まれることにより、プログラム実行時のオブジェクト生成のオーバヘッドが若干増える。一方で呼び出し文脈（コールパス）を利用するプログラムにおいて、該利用が容易になる。また、オブジェクト間接続時の呼び出し文脈（第２のコールパス）に対しても、上記プログラムカウンタ又はオブジェクトの型の少なくとも１つが含まれてもよい。呼び出し文脈（コールパス）に例えばプログラムカウンタが含まれる場合の例では、例えば上記ＰＣＣにおけるメソッド実装ごとに振られるＩＤを、プログラムカウンタごとに振られるごとにＩＤとすることで、プログラム内の複数個所にあるメソッド呼び出しが区別されうる。
【００７９】
オブジェクト生成記録部（１３４）は、アプリケーション・プログラム（１３１）上でのオブジェクト生成処理の実行をフックする。該オブジェクトの生成処理は、例えばnewオペレーションである。オブジェクト生成記録部（１３４）は、上記フックすることに応じて、呼び出しスタック追跡部（１３３）から呼び出し文脈ＩＤを取得する。オブジェクト生成記録部（１３４）は、上記取得した呼び出し文脈ＩＤを、上記フックしたオブジェクト生成処理によって生成されたオブジェクトのオブジェクト・ヘッダに埋め込む。オブジェクト生成記録部（１３４）は、図１Ａにおける、第１の格納部（１１２）に対応する。
【００８０】
オブジェクト間接続記録部（１３５）は、アプリケーション・プログラム（１３１）上でのオブジェクト間接続処理の実行をフックする。上記オブジェクト間接続処理は、例えばputfield、putstatic又はaastoreオペレーションである。オブジェクト間接続記録部（１３５）は、上記フックすることに応じて、呼び出しスタック追跡部（１３３）から呼び出し文脈ＩＤを取得する。オブジェクト間接続記録部（１３５）は、上記取得した呼び出し文脈ＩＤを、上記フックしたオブジェクト接続処理によって接続される先のオブジェクトのオブジェクト・ヘッダ又は接続元のオブジェクトのフィールド・ヘッダに埋め込む。オブジェクト間接続記録部（１３５）は、図１Ａにおける、第２の格納部（１１３）に対応する。
【００８１】
なお、呼び出しスタック追跡部（１３３）は、上記構成に含まれていなくてもよい。含まれていない場合、コンピュータ・システムは、例えばオブジェクト生成処理又はオブジェクト間接続処理をフックすることに応じて、呼び出しスタック（履歴データ）を遡って呼び出し文脈（コールパス）を作成しうる。ただし、呼び出しスタック追跡部（１３３）を含む場合に比べて、アプリケーション・プログラム（１３１）の実行コストは高くなる。
【００８２】
図１Ｄは、本発明の実施態様における、図１Ｃに示す生成文脈表及び接続文脈表の例を示す。
生成文脈表（１５１）及び接続文脈表（１５２）は、ヒープメモリ（１３６）の内容がダンプされたメモリダンプ（１３７）から作成される。ここで、メモリダンプ（１３７）は、図１Ｂにおけるオブジェクト（１０５ａ〜１０５ｎ）の状態及びプログラム（１０３）の実行状態をダンプしたものである。
生成文脈表（１５１）は、オブジェクトを特定できるデータ（以下、オブジェクトＩＤ）と、該オブジェクトの生成に至る文脈（第１のコールパス）と対応する第１のＩＤ（以下、生成文脈ＩＤ）との組が格納される表である。なお、生成文脈表（１５１）には、オブジェクトＩＤと、第１のコールパスとの組が格納されてもよい。オブジェクトＩＤは、例えばオブジェクトのメモリ上のアドレスが使用されるがこれに限定されない。生成文脈ＩＤは、例えばＰＣＣにおけるＰＣＣ  ＩＤが使用されるがこれに限定されない。
【００８３】
接続文脈表（１５２）は、上記オブジェクトＩＤと、該オブジェクトの接続に至る文脈（第２のコールパス）と対応する第２のＩＤ（以下、接続文脈ＩＤ）との組が格納される表である。接続文脈ＩＤは、例えばＰＣＣにおけるＰＣＣ  ＩＤが使用されるがこれに限定されない。なお、生成文脈表（１５１）には、オブジェクトＩＤと、第２のコールパスとの組が格納されてもよい。
【００８４】
対応表（１５３）は、上記生成文脈ＩＤ及び上記接続文脈ＩＤ（以下、文脈ＩＤ）と文脈（コールパス）との組が格納される表である。該文脈（コールパス）は、サブルーチン呼び出しの関係が分かるようなデータである。例えば、対応表（１５３）の１レコード目の文脈（コールパス）「a()→b()→d()→e()→f()・・・」は、a()というサブルーチンの中でb()というサブルーチンが呼び出され、b()というサブルーチンの中でd()というサブルーチンが呼び出され、・・・という関係が分かるデータを示す。対応表（１５３）は、生成文脈ＩＤ又は接続文脈ＩＤに対応する文脈（コールパス）を求めるために使用される。例えば、生成文脈表（１５１）において、オブジェクトＩＤが「０ｘＡＢＣＤ５６７８」、「０ｘＡＢＣＤ０３９４」、「０ｘＡＢＣＤ４５８５」及び「０ｘＡＢＣＤ４３３３」のオブジェクト（以下、４つのオブジェクト）に対応する生成文脈ＩＤは、全て「１２３４」である。また、対応表（１５３）において、文脈ＩＤが「１２３４」に対応する文脈（コールパス）は、「a()→b()→d()→e()→f()・・・」である。よって、上記４つのオブジェクトは全て、「a()→b()→d()→e()→f()・・・」という文脈を経て生成されたオブジェクトであることが求められる。なお、上記生成文脈ＩＤ及び上記接続文脈ＩＤに、上記文脈（コールパス）がそのまま使用されてもよい。上記文脈（コールパス）がそのまま使用される場合、コンピュータ・システム（図１Ｂ、１２１）は、対応表（１５３）を必要としない。対応表（１５３）は、図１Ｂにおける、対応表（１１１）に対応する。
【００８５】
図１Ｅは、本発明の実施態様における、図１Ｃに示す滞留因子表の例を示す。
滞留因子表（１６１）は、上記オブジェクトＩＤと、該オブジェクトについての滞留因子との組が格納される表である。滞留因子表（１６１）にはまた、上記生成文脈ＩＤ及び上記接続文脈ＩＤが含まれていてもよい。
上記滞留因子は、オブジェクトの生成に至る文脈（第１のコールパス）と、該オブジェクトの接続に至る文脈（第２のコールパス）との最上位のサブルーチンからの共通部分の文脈（コールパス）である。滞留因子は、生成文脈表（１５１）、接続文脈表（１５２）及び対応表（１５３）から求められる。例えばオブジェクトＩＤが「０ｘＣＤ５６７８」のオブジェクトの場合、最初に生成文脈表（１５１）から生成文脈ＩＤ「１２３４」が、接続文脈表（１５２）から接続文脈ＩＤ「５６７８」が求められる。次に対応表（１５３）から生成文脈ＩＤ「１２３４」に対応する文脈（コールパス）「a()→b()→d()→e()→f()・・・」及び接続文脈ＩＤ「５６７８」に対応する文脈（コールパス）「a()→b()→g()→h()→i()・・・」が求められる。そして、文脈（コールパス）「a()→b()→d()→e()→f()・・・」及び文脈（コールパス）「a()→b()→g()→h()→i()・・・」の最上位のサブルーチンからの共通部分の文脈（コールパス）である「a()→b()」が求められる。よって、オブジェクトＩＤ「０ｘＣＤ５６７８」に対応する滞留因子「a()→b()」が求められる。
【００８６】
図１Ｆは、本発明の実施態様における、図１Ｃに示すヒープメモリ上のオブジェクトの構成例を示す。
該オブジェクトは、図１Ａ及び図１Ｂにおけるオブジェクト（１０５ａ、１０５ｂ、・・・、１０５ｎ）のオブジェクトの１つに対応する。また、該オブジェクトは、オブジェクトに対応付けられた領域（１０６ａ、１０６ｂ、・・・、１０６ｎ）を含むとする。
オブジェクト（１７１）は、オブジェクト・ヘッダ（１７２）及びフィールド・スロット（１７３）を備えている。
オブジェクト・ヘッダ（１７２）には、メタ情報として、例えばオブジェクトの型を表すクラスに関する情報（１７４）及びガーベジコレクションに関する情報（１７５）が格納されうる。オブジェクト・ヘッダ（１７２）には、呼び出し文脈ＩＤがさらに埋め込まれうる。
フィールド・スロット（１７３）はさらに、フィールド・ヘッダ（１７８）及びフィールド本体（１７９）に分けられる。フィールド・ヘッダ（１７８）には、呼び出し文脈ＩＤが埋め込まれうる。フィールド・本体（１７９）には、例えばオブジェクト（１７１）が参照する他のオブジェクトを指すポインタ又はオブジェクト（１７９）で管理される値が格納される。
【００８７】
オブジェクト生成時に呼び出し文脈ＩＤが埋め込まれるエリア（１７６）をＣＴ＠ｎｅｗ部（以下、生成文脈ヘッダともいう）とし、オブジェクト間接続時に呼び出し文脈ＩＤが埋め込まれるエリア（１７７又は１７８）をＣＴ＠ｓｅｔ部（以下、接続ヘッダともいう）とする。なお、オブジェクト間接続時に呼び出し文脈ＩＤが埋め込まれるエリアとして、オブジェクト・ヘッダ上のエリア（１７７）及びフィールド・ヘッダ上のエリア（１７８）が用意されているが、本発明の実施態様の実装時においては、呼び出し文脈ＩＤは、どちらか一方のエリアに埋め込まれればよい。オブジェクト・ヘッダ上のエリア（１７７）に埋め込む実装では、コンピュータ・システムは、オブジェクト間接続時に、接続先のオブジェクトのオブジェクト・ヘッダ上のエリア（１７７）に呼び出し文脈ＩＤを埋め込む。なお、接続先のオブジェクトとは、フィールドから参照する先のオブジェクトのことである。フィールド・ヘッダ上のエリア（１７８）に埋め込む実装では、コンピュータ・システムは、オブジェクト間接続時に接続元のオブジェクトのフィールド・ヘッダ上のエリア（１７８）に呼び出し文脈ＩＤを埋め込む。なお、図２以降では、フィールド・ヘッダ上のエリア（１７８）に埋め込む実装を採用した場合を例として説明する。
【００８８】
図２は、本発明の実施態様における、図１Ａ及び図１Ｂに示すシステム上で実行される処理の概要を説明するための図を示す。
なお、図２以降では、プログラム（１０３）がＪａｖａ（商標）言語で記載されているとした場合を例として説明する。また、上記Ｊａｖａ（商標）言語におけるメソッドが、呼び出し（コール）に対応する。
図２は、「void m(){ Object o = factory.create(); hashmap.put(key,o); }」という実装のメソッドm()（２０４）を例とした場合における、メソッド又はオペレーション（２０３〜２１１）とメモリ（２２１）上のオブジェクト（２２２〜２２５）とを表す。なお、メソッドm()は、最上位のメソッドa()（２０３）において呼び出されるメソッドとする。
メソッドm()（２０４）は、factory.create()（２０５）及びhashmap.put()（２１０）の２つのメソッドの呼び出しを含む。上記２つのメソッドは汎用的なメソッドであり、メソッドm()（２０４）以外の例えばメソッドn()（２０８）からも呼び出されうる。
factory.create()（２０５）は、その実装内でオブジェクトを生成する機能を有すメソッドである。よって、factory.create()（２０５）内に含まれるメソッド又はオペレーション（２０６、２０７及び２０９）の呼び出しには、オブジェクトを生成する処理である例えばnewオペレーション（２０７）が含まれうる。
hashmap.put()（２１０）は、ハッシュマップに値を設定する機能を有すメソッドである。よって、hashmap.put()（２１０）内に含まれるメソッド又はオペレーション（２１１）には、ハッシュマップオブジェクトに他のオブジェクトを接続するオペレーションが含まれうる。
【００８９】
オブジェクト（２２２）は、ハッシュマップを表す。オブジェクト（２２２）には、メソッド又はオペレーション（２１１）によって他のオブジェクト（２２３）が接続される。オブジェクト（２２２）には、上記接続時に、オブジェクト（２２３）についての接続文脈ＩＤが埋め込まれる。また、図示はしていないが、例えばメソッドn()（２０８）にhashmap.put()（２１０）の呼び出しが含まれ且つメソッドn()に含まれるnewオペレーション（図示せず）によって生成されたオブジェクト（２２４）がオブジェクト（２２２）に接続する場合、オブジェクト（２２２）には、上記接続時に、オブジェクト（２２４）についての接続文脈ＩＤが埋め込まれる。
オブジェクト（２２３）は、newオペレーション（２０７）によって生成されたオブジェクトを示す。オブジェクト（２２３）には、上記生成時に、生成文脈ＩＤが埋め込まれる。
【００９０】
生成文脈（２０１）は、factory.create()（２０５）内で生成されるオブジェクト（２２３）の生成に至る呼び出しの流れを示す。
接続文脈（２０２）は、オブジェクト（２２３）がオブジェクト（２２２）に接続されるまでの呼び出しの流れを示す。
【００９１】
本発明の実施態様によれば、あるオブジェクトがメモリ上に滞留している原因が、従来技術に比べてより詳細に絞られる。ここで、従来技術では、オブジェクト生成に至る呼び出し文脈（以下、生成文脈）のみを利用して、上記原因が求められる。本発明の実施態様では、生成文脈に加えて、オブジェクトが他のオブジェクトに接続されるまでの呼び出しの流れ（以下、接続文脈）も利用される。
【００９２】
以下では、オブジェクト（２２３）が滞留しているオブジェクトであるして説明する。
従来技術の態様では、生成文脈（２０１）のみが利用されることによって、上記原因が求められる。該原因が求められることによって、コンピュータ・システムは、メモリ消費の原因となっている可能性のあるメソッドとして、メソッド（２０３〜２０６）を提示しうる。
一方、本発明の実施態様では、生成文脈（２０１）に加えて接続文脈（２０２）も利用されることによって、上記原因が求められる。該原因が求められることによって、コンピュータ・システムは、メモリ消費の原因となっている可能性のあるメソッドとして、生成文脈（２０１）と接続文脈（２０２）との交わる範囲内のメソッド（２０３及び２０４）を提示しうる。
【００９３】
従来技術による提示では、例えば汎用的に使用されうるfactory.create()（２０５）が提示されるために、ユーザはメモリ消費の原因を絞りきれない。
一方、本発明の実施態様による提示では、factory.create()（２０５）がメモリ消費の原因となりうるメソッドから外される。本発明の実施態様による提示では、さらに、上記交わる範囲内に含まれる中で最終的に呼ばれているメソッドであって、根のメソッドａ()（２０３）から最も遠いメソッドm()（２０４）が、メモリ消費の原因となっている可能性が特に高いメソッドとして提示されうる。それによって、ユーザは、hashmap.put()（２１０）を呼ぶメソッドm()（２０４）がメモリ消費の原因であると絞り込むことができるようになる。
【００９４】
図２で示される概要の処理は、図１Ａに示すシステムで実行される「実行プロファイル取得」ステップと、図１Ｂに示すシステムで実行される「メモリ消費因子表示」ステップとで構成される。
実行プロファイル取得ステップでは、コンピュータ・システムは、オブジェクトが生成されたこと及びオブジェクトが接続されたことを実行プロファイル情報としてメモリ上に残す。実行プロファイル取得ステップでは、以下の２つの情報が実行プロファイル情報としてメモリ上に残される。
・第１の情報：オブジェクトを生成しているコード実行に至る呼び出し文脈（第１のコールパス）又は該文脈に対応するＩＤ（第１のＩＤ）
・第２の情報：オブジェクトを他のオブジェクトのフィールド変数などに代入している実行に至る呼び出し文脈（第２のコールパス）又は該文脈に対応するＩＤ（第２のＩＤ）
上記第１の情報をメモリ上に残す処理の詳細は図３Ａの説明において、上記第２の情報をメモリ上に残す処理の詳細は図３Ｂの説明において、それぞれ述べる。
【００９５】
メモリ消費因子表示ステップでは、コンピュータ・システムは、上記残された実行プロファイル情報からプログラム実行時のある実行状態におけるメモリ消費の要因を求める。そして、コンピュータ・システムは、該要因を表示部に任意の方法で表示する。
上記要因は、プログラムのある実行状態におけるメモリのスナップショットに含まれるオブジェクトについて求められうる。コンピュータ・システムは、上記第１の情報によって表わされる文脈と上記第２の情報によって表わされる文脈との最上位のサブルーチンから続く共通部分の文脈を、上記オブジェクトによるメモリ消費の責任部分としてユーザに提示する。
上記要因を求める処理の概要は図４の説明において、該処理の詳細は図５Ａ〜図５Ｃの説明において、それぞれ述べる。
【００９６】
上記実行プロファイル取得ステップでは、第１の情報及び第２の情報をメモリ上に残す処理が追加される分、実行プロファイル取得ステップによるプログラムのオーバヘッドが大きくなる。そこで、該オーバヘッドを数パーセントにおさえて本発明の実施態様を実現するために、例えばＰＣＣとして広く知られている方法が本発明の実施態様に適用されてもよい。
ＰＣＣが適用される場合、上記実行プロファイル取得ステップにおいて、ＰＣＣ  ＩＤが第１の情報としてメモリ上に残される。また、上記メモリ消費因子表示ステップにおいて、上記ＰＣＣ  ＩＤから呼び出し文脈（コールパス）を復元するための対応表が作成され、該対応表により、オブジェクトを生成しているコード実行に至る呼び出し文脈（第１のコールパス）及びオブジェクトを他のオブジェクトのフィールド変数などに代入している実行に至る呼び出し文脈（第２のコールパス）が復元される。
上記対応表を作成する処理の詳細は図６Ａ及び図６Ｂの説明において述べる。
【００９７】
図３Ａは、図１Ａに示すオブジェクトを生成するnewオペレーションについての本発明の実施態様におけるフローチャートの例、及び従来の実施態様におけるフローチャートの例を示す。本発明の実施態様では、上記newオペレーションにおいて、第１の情報がメモリ上に残される。
フローチャート（３００）及びフローチャート（３１０）はともに、Ｊａｖａ（商標）バイトコード上で「new Ｃ」が実行される場合のフローチャートである。フローチャート（３００）は、従来の実施態様におけるnewオペレーションのフローチャートである。フローチャート（３１０）は、本発明の実施態様におけるnewオペレーションのフローチャートである。
【００９８】
フローチャート（３００）における各ステップの処理を以下に示す。
ステップ３０１は、従来の実施態様における、newオペレーションの開始を表す。
ステップ３０２では、コンピュータ・システムは、クラスＣからインスタンスオブジェクトを生成する。
ステップ３０４は、従来の実施態様における、newオペレーションの終了を表す。
【００９９】
フローチャート（３１０）における各ステップの処理を以下に示す。
ステップ３１１は、本発明の実施態様における、newオペレーションの開始を表す。
ステップ３１２では、コンピュータ・システムは、クラスＣからインスタンスオブジェクトを生成する。
ステップ３１３では、コンピュータ・システムは、呼び出し文脈ＩＤ（第１のＩＤ）を上記生成されたオブジェクトのオブジェクト・ヘッダのＣＴ＠ｎｅｗ部に記録する。
ステップ３１４は、本発明の実施態様における、newオペレーションの終了を表す。
フローチャート（３１０）では、フローチャート（３００）の各処理に加えて、ステップ３１３の処理が追加されている。
【０１００】
図３Ｂは、図１Ａに示すオブジェクトを接続するputfieldオペレーションについての本発明の実施態様におけるフローチャートの例、及び従来の実施態様におけるフローチャートの例を示す。本発明の実施態様では、例えば上記putfieldオペレーションにおいて、第２の情報がメモリ上に残される。
フローチャート（３２０）は、従来の実施態様のおけるputfieldオペレーションのフローチャートである。フローチャート（３３０）は、本発明の実施態様におけるputfieldオペレーションのフローチャートである。フローチャート（３２０）及びフローチャート（３３０）はともに、Ｊａｖａ（商標）バイトコード上で「putfield Ｆ」が実行される場合のフローチャートである。なお、第１のオブジェクトがフィールドＦを有し、第２のオブジェクトが設定値Ｘを有するとする。
【０１０１】
フローチャート（３２０）における各ステップの処理を以下に示す。
ステップ３２１は、従来の実施態様における、putfieldオペレーションの開始を表す。
ステップ３２４では、コンピュータ・システムは、第１のオブジェクトのフィールドＦに、第２のオブジェクトの設定値Ｘを代入する。
ステップ３２５は、従来の実施態様における、putfieldオペレーションの終了を表す。
【０１０２】
フローチャート（３３０）における各ステップの処理を以下に示す。
ステップ３３１は、本発明の実施態様における、putfieldオペレーションの開始を表す。
ステップ３３２では、コンピュータ・システムは、第１のオブジェクトのフィールドＦが参照型のフィールドかどうかを判定する。ここで、参照型のフィールドとは、オブジェクトを指す値、例えばオブジェクトへのポインタが入るフィールドである。参照型のフィールドではないフィールドとは、例えばオブジェクトを指す値ではない整数値が入るフィールドである。第１のオブジェクトのフィールドＦが参照型のフィールドであることに応じて、該処理はステップ３３３に進む。参照型のフィールドではないことに応じて、該処理はステップ３３４に進む。
ステップ３３３では、コンピュータ・システムは、呼び出し文脈ＩＤ（第２のＩＤ）を第１のオブジェクトのフィールドＦのＣＴ＠ｓｅｔ部又は第２のオブジェクトのオブジェクト・ヘッダのＣＴ＠ｓｅｔ部に記録する。該記録の終了に応じて、該処理はステップ３３４に進む。
ステップ３３４では、コンピュータ・システムは、第１のオブジェクトのフィールドＦに、第２のオブジェクトの設定値Ｘを代入する。該代入の終了に応じて、該処理はステップ３３５に進む。
ステップ３３５は、本発明の実施態様における、putfieldオペレーションの終了を表す。
フローチャート（３３０）ではフローチャート（３２０）の各処理に加え、ステップ３３２及びステップ３３３の処理が追加されている。
【０１０３】
図４は、本発明の実施態様における、図１Ｃに記載の３つの表を作成する方法を説明するための図を示す。
呼び出し関係図（４００）は、プログラムの実行の様子を模式的に示す図である。角丸四角（４０１〜４０８）は、メソッド又はオペレーションを表す。矢印は、メソッド間の又はメソッドとオペレーションとの間の親子関係を表す。親子関係とは、親のメソッドで実行される処理の１つに、子のメソッド呼び出し又はオペレーション実行が含まれるという関係である。
呼び出し関係図（４００）には、putfield又はaastoreオペレーション（４０５）が実行されるまでの呼び出しの流れ（接続文脈）及び、newオペレーション（４０８）が実行されるまでの呼び出しの流れ（生成文脈）が示されている。上記接続文脈は、「a()（４０１）→b()（４０２）→s_1()（４０３）→・・・→s_n()（４０４）」である。上記生成文脈は、「a()（４０１）→b()（４０２）→f_1()（４０６）→・・・→f_n()（４０７）」である。
【０１０４】
オブジェクト関係図（４１０）は、メモリ上のオブジェクトの状態を表現した図である。なお、丸（４１１〜４１８）はルート又はオブジェクトを表す。矢印は、オブジェクト間の接続を表す。例えば、オブジェクト（４１７）は、オブジェクト（４１６）に接続している。上記接続において、オブジェクト（４１６）は接続元のオブジェクトであり、オブジェクト（４１７）は接続先のオブジェクトである。また、接続元のないオブジェクトは、ルート（４１１）に接続される。ルートは、例えば、実行スタック又はクラス変数を表す。
【０１０５】
newオペレーション（４０８）からオブジェクトＥ１〜Ｅ３（４１３〜４１５）それぞれへの矢印は、newオペレーションとオブジェクトＥ１〜Ｅ３（４１３〜４１５）とが対応関係にあることを表す。対応関係とは、例えば参照関係が、例えばオブジェクトＥ１〜Ｅ３（４１３〜４１５）のヘッダに残されていることである。
putfield又はaastoreのオペレーション（４０５）からオブジェクトＨ（４１２）への矢印は、putfield又はaastoreのオペレーション（４０５）の対象となるオブジェクトがオブジェクトＨ（４１２）であることを示す。
【０１０６】
以下では、オブジェクトＥ１（４１３）を滞留しているオブジェクトとした場合に、上記滞留の原因を求める例を示す。
１．コンピュータ・システムは、ダンプされたオブジェクト（４１２〜４１８）について、一般的なガーベジコレクションと同様の処理を行う。該処理により、オブジェクト（４１２〜４１８）はガベージ・オブジェクトとアクティブ・オブジェクトとに判別される。
上記ガーベジコレクションと同様の処理では、コンピュータ・システムは、例えば実行スタック又はクラス変数をルートとする上記オブジェクト関係図（４１０）において、該ルートから到達しうるオブジェクト全てにマークをつける。そして、コンピュータ・システムは、上記マークのついているオブジェクトをアクティブ・オブジェクトと判断し、マークのついてないオブジェクトをガベージ・オブジェクトと判断する。
２．上記判断において、オブジェクトＥ１（４１３）がアクティブ・オブジェクトの場合、コンピュータ・システムは、オブジェクトＥ１（４１３）のＣＴ＠ｎｅｗ部及びオブジェクトＥ１を（４１３）を参照しているオブジェクトＨ（４１２）のフィールド・ヘッダのＣＴ＠ｓｅｔ部それぞれから、呼び出し文脈ＩＤを取得する。上記判断において、オブジェクトＥ１（４１３）がガベージ・オブジェクトの場合、コンピュータ・システムは、オブジェクトＥ１（４１３）を滞留しているオブジェクトではないと判断し、該処理を終了する。
３．コンピュータ・システムは、上記取得した呼び出し文脈ＩＤから、実際の呼び出し文脈（コールパス）を復元する。コンピュータ・システムは、上記取得した呼び出し文脈ＩＤを使用して対応表を検索することで、上記実際の呼び出し文脈（コールパス）を復元しうる。また、上記復元の別の態様として、コンピュータ・システムは、例えばＰＣＣを用いたロジックでプログラムに含まれる呼び出し文脈に対応するＩＤを作成し、取得した呼び出し文脈ＩＤと該作成されたＩＤとが一致する場合に、作成元の呼び出し文脈を上記実際の呼び出し文脈（コールパス）として復元しうる。
コンピュータ・システムは、オブジェクトＥ１（４１３）のＣＴ＠ｎｅｗ部から取得した呼び出し文脈ＩＤを復元し、生成文脈「a()→b()→f_1()→・・・→f_n()」を得る。また、コンピュータ・システムは、オブジェクトＨ（４１２）のフィールド・ヘッダのＣＴ＠ｓｅｔ部から取得した呼び出し文脈ＩＤを復元し、接続文脈「a()→b()→s_1()→・・・→s_n()」を得る。
４．コンピュータ・システムは、上記生成文脈及び上記接続文脈から、最上位の親（以下、大元）の呼び出しからの共通部分「a()→b()」を取り出す。そして、コンピュータ・システムは、上記共通部分「a()→b()」をオブジェクトＥ１（４１３）の滞留因子とする。
【０１０７】
図５Ａは、本発明の実施態様における、図１Ｃに示す滞留因子表を作成する処理のフローチャートの例を示す。
ステップ５０１は、滞留因子表を作成する処理の開始を表す。
ステップ５０２では、コンピュータ・システムは、実行メモリをダンプする。該ダンプの終了に応じて、該処理はステップ５０３に進む。
ステップ５０３では、コンピュータ・システムは、上記ダンプされたメモリ（以下、ダンプメモリ）に対して、ガーベジコレクション相当の処理を行う。該処理により、コンピュータ・システムは、アクティブ・オブジェクトの集合をダンプメモリより取り出す。該取り出しの終了に応じて、該処理はステップ５０４に進む。
ステップ５０４では、コンピュータ・システムは、上記取り出した集合を使用して、生成文脈表及び接続文脈表（以下、文脈表）を作成する。該作成については、図５Ｂの説明で詳しく述べる。文脈表の作成終了に応じて、該処理はステップ５０５に進む。
ステップ５０５では、コンピュータ・システムは、作成された文脈表から、滞留因子を求め、該求めた滞留因子を滞留因子表に登録する。該登録については、図５Ｃの説明で詳しく述べる。上記登録の終了に応じて、該処理はステップ５０６に進む。
ステップ５０６は、滞留因子表を作成する処理の終了を表す。
コンピュータ・システムは、滞留因子表を、任意の方法で例えばモニタに表示する。該表示により、ユーザにメモリ消費の原因となりうる例えばメソッドが提示されうる。
【０１０８】
図５Ｂは、本発明の実施態様における、図５Ａのステップ５０４の処理の詳細なフローチャートの例を示す。
ステップ５１１は、図５Ａのステップ５０４の開始を示す。
ステップ５１２では、コンピュータ・システムは、ステップ５０３において取り出されたアクティブ・オブジェクトの集合から、アクティブ・オブジェクトを１つ取り出す。該取り出しの終了に応じて、該処理はステップ５１３に進む。
ステップ５１３では、コンピュータ・システムは、上記取り出したアクティブ・オブジェクトのオブジェクト・ヘッダのＣＴ＠ｎｅｗ部から呼び出し文脈ＩＤ（生成文脈ＩＤ）を取得する。そして、コンピュータ・システムは、取得した生成文脈ＩＤとアクティブ・オブジェクトを表すＩＤ（オブジェクトＩＤ）との組を生成文脈表に追加する。上記生成文脈表への追加の終了に応じて、該処理はステップ５１４に進む。
ステップ５１４は、接続文脈表への登録処理を表す。該登録処理では、ステップ５１５〜ステップ５１９が実行される。
【０１０９】
ステップ５１５は、オブジェクトごとの接続文脈表への登録処理の開始を示す。
ステップ５１６では、コンピュータ・システムは、ステップ５１２において取り出されたアクティブ・オブジェクト内にあるフィールドを１つ選択する。該選択の終了に応じて、該処理はステップ５１７に進む。
ステップ５１７では、コンピュータ・システムは、上記選択したフィールドのフィールド・ヘッダのＣＴ＠ｓｅｔ部から呼び出し文脈ＩＤ（接続文脈ＩＤ）を取得する。そして、コンピュータ・システムは、取得した接続文脈ＩＤとオブジェクトＩＤとの組を接続文脈表に追加する。上記接続文脈表への追加の終了に応じて、該処理はステップ５１８に進む。
ステップ５１８では、コンピュータ・システムは、取り出されたアクティブ・オブジェクト内に選択されていないフィールドがまだ残っているかどうかを判定する。上記選択されていないフィールドが残っていることに応じて、該処理はステップ５１６に戻る。上記選択されていないフィールドが残っていないことに応じて、該処理はステップ５１９に進む。
ステップ５１９は、オブジェクトごとの接続文脈表への登録処理の終了を示す。引き続き、該処理はステップ５２０に進む。
【０１１０】
ステップ５２０では、コンピュータ・システムは、集合から取り出していないアクティブ・オブジェクトがまだあるかどうかを判定する。集合から取り出していないアクティブ・オブジェクトがあることに応じて、該処理はステップ５１２に戻る。集合から取り出していないアクティブ・オブジェクトがないことに応じて、該処理はステップ５２１に進み終了する。
ステップ５２１は、図５Ａのステップ５０４の終了を示す。
【０１１１】
図５Ｃは、本発明の実施態様における、図５Ａのステップ５０５の処理の詳細なフローチャートの例を示す。
ステップ５３１は、図５Ａのステップ５０５の開始を示す。
ステップ５３２では、コンピュータ・システムは、生成文脈表から、生成文脈ＩＤとオブジェクトＩＤとの組を１件取り出す。該取り出しの終了に応じて、該処理はステップ５３３に進む。
ステップ５３３では、コンピュータ・システムは、接続文脈表から、上記取り出したオブジェクトＩＤに対応する接続文脈ＩＤを取り出す。該取り出しの終了に応じて、該処理はステップ５３４に進む。
ステップ５３４では、コンピュータ・システムは、ステップ５３２において取り出された生成文脈ＩＤに対応する生成文脈とステップ５３３において取り出された接続文脈ＩＤに対応する接続文脈とを対応表から取得する。次に、コンピュータ・システムは、生成文脈及び接続文脈の根からの共通部分（滞留因子）を求める。コンピュータ・システムは、該滞留因子とオブジェクトＩＤとの組を滞留因子表に追加する。該追加の終了に応じて、該処理はステップ５３５に進む。
ステップ５３５では、コンピュータ・システムは、生成文脈表から取り出していない組がまだあるかどうかを判定する。生成文脈表から取り出していない組があることに応じて、該処理はステップ５３２に戻る。生成文脈表から取り出していない組がないことに応じて、該処理はステップ５３６に進み終了する。
ステップ５３６は、図５Ａのステップ５０５の終了を示す。
【０１１２】
図６Ａは、本発明の実施態様における、図１Ａに示す対応表を作成するフローチャートの例を示す。
上記フローチャートの処理では、コンピュータ・システムは、プログラム（図１Ａ、１０３）を解析し、プログラム（１０３）上で構成される文脈（コールパス）それぞれについて、呼び出し文脈ＩＤを再計算する。そして、コンピュータ・システムは、上記文脈（コールパス）と再計算された呼び出し文脈ＩＤとを対応付け、対応表に登録する。また、コンピュータ・システムは、上記解析しきれない文脈（コールパス）を、呼び出し文脈ＩＤが不明の文脈（コールパス）とする。
図６Ａに示すフローチャートは、注目する呼び出しごとに実行される。図６Ａに示すフローチャートはまた、呼び出しの実装中に別の呼び出しが含まれる場合、該別の呼び出しを注目する呼び出しとして再帰的に実行されうる。該再帰的な実行において、最初に注目される呼び出しは、プログラム（１０３）に含まれる呼び出しのうち、最上位の呼び出しとする。
なお、上記対応表は、メモリ消費因子を表示するときより前であれば、どのタイミングで作成されてもよい。
【０１１３】
ステップ６０１は、文脈復元処理の開始を示す。
ステップ６０２では、注目する呼び出しについての文脈（コールパス）を対応表（呼び出し文脈情報テーブル）に登録する。該登録については、図６Ｂの説明で詳しく述べる。上記登録の終了に応じて、該処理はステップ６０３に進む。
ステップ６０３では、コンピュータ・システムは、上記注目する呼び出しの深さが閾値を超えているかどうかを判定する。上記注目する呼び出しの深さとは、プログラム（１０３）上の階層的な呼び出しの関係における、最上位の呼び出しから見た注目する呼び出しの位置である。上記深さは、最上位の呼び出し（１層目の呼び出し）を例えば深さ１とする場合、最上位の呼び出しの実装内（メソッドの実装内）に含まれる呼び出し（２層目の呼び出し）は深さ２、２層目の呼び出しの実装内に含まれる呼び出し（３層目の呼び出し）は深さ３、・・・、ｎ−１層目の呼び出しの実装内（メソッドの実装内）に含まれる呼び出し（ｎ層目の呼び出し）は深さｎと表わされうる。
また、上記閾値は、ユーザによって任意に設定しうる値である。ユーザは、上記閾値を、例えば５と設定する。
上記判定において、上記注目する呼び出しの深さが閾値を超えていることに応じて、該処理はステップ６０８に進む。上記注目する呼び出しの深さが閾値を超えていないことに応じて、該処理はステップ６０４に進む。
ステップ６０４では、コンピュータ・システムは、注目している呼び出しの実装（メソッドの実装）に含まれる呼び出し候補を抽出する。該抽出の終了に応じて、該処理はステップ６０５に進む。
ステップ６０５では、コンピュータ・システムは、上記抽出された呼び出し候補のうちの１つを取り出す。該取り出しの終了に応じて、該処理はステップ６０６に進む。
ステップ６０６では、コンピュータ・システムは、上記取り出した呼び出し候補を注目する呼び出しとして、再帰的に文脈復元処理を実行する。該実行の終了に応じて、該処理はステップ６０７に進む。
ステップ６０７では、コンピュータ・システムは、ステップ６０５において取り出されていない呼び出し候補があるかどうかを判定する。取り出されていない呼び出し候補があることに応じて、該処理はステップ６０５に戻る。取り出されていない呼び出し候補がないことに応じて、該処理はステップ６０８に進む。
ステップ６０８は、文脈復元処理の終了を示す。
【０１１４】
図６Ｂは、本発明の実施態様における、図６Ａのステップ６０２の処理の詳細なフローチャートの例を示す。
ステップ６１１は、図６Ａのステップ６０２の開始を示す。
ステップ６１２では、コンピュータ・システムは、注目する呼び出しの（コールパス）についての呼び出し文脈ＩＤを算出する。該算出の終了に応じて、該処理はステップ６１３に進む。
ステップ６１３では、コンピュータ・システムは、対応表に上記算出した呼び出し文脈ＩＤのエントリがあるかどうかを判定する。エントリがあることに応じて、該処理はステップ６１５に進む。エントリがないことに応じて、該処理はステップ６１４に進む。
ステップ６１５では、コンピュータ・システムは、対応表に上記算出した呼び出し文脈ＩＤと注目する呼び出しについての文脈（コールパス）との組を登録する。なお、上記算出した呼び出し文脈ＩＤは、対応表を検索する場合のキーである。上記登録の終了に応じて、該処理はステップ６１５に進む。
ステップ６１５は、呼び出し文脈情報処理の終了を示す。該終了に応じて、該処理はステップ６０３に進む。
【０１１５】
図６Ａ及び図６Ｂのフローチャートでは、深さ優先で上記組が対応表に登録される。ここで、上記組は、例えば幅優先で登録されてもよいし、又は所与の時間の間に探索された組であってもよい。幅優先で登録する場合、図６Ａ及び図６Ｂのフローチャートでは、コンピュータ・システムは、階層ごとに呼び出しの数をカウントする。そして、ステップ６０３において、上記カウントが所与の閾値を超える場合、該処理はステップ６０８に進む。一方、上記カウントが所与の閾値を超えない場合、該処理はステップ６０４に進む。
【０１１６】
図７Ａは、本発明の実施態様における、メモリ消費の発生原因の、図１Ｂに示す表示部における表示例を示す。
本発明の実施態様では、コンピュータ・システムは、滞留因子表（図１Ｃ、１４０）とメモリダンプ（図１Ｃ、１３７）とを用いて、例えば図７Ａに示すレイアウトの表示例を表示する。
該表示例には、オブジェクト群を示す箱（７０１）及び木構造（７０２）が含まれる
箱（７０１）は、同じ滞留因子により滞留している同じ型のオブジェクト群を表す。箱（７０１）の横の長さは、オブジェクトによる消費メモリの大きさに対応する。同じ滞留因子により滞留している同じ型のオブジェクト群及び消費メモリの大きさは、滞留因子表をもとに、同じ滞留因子に紐付けられたオブジェクト群を、型により仕分けることにより得られる。また、オブジェクト生成のコード中の位置又はオブジェクトの型（以下、追加情報）がオブジェクトに対応付けられて格納されている場合、コンピュータ・システムは、上記追加情報を使用して上記仕分けることも可能である。
木構造（７０２）は、上記オブジェクト群の滞留の原因と推定される呼び出し文脈を木状に整理したものである。図中の破線矢印は、あるメモリ部分の消費の原因と推定される呼び出し文脈を示す矢印である。例えば破線矢印（７０３）は、String オブジェクト（７０７）の責を負う部分が、newName()に至るパスであることを示す。
なお、オブジェクト間接続を使用していない従来技術においては、上記newName()より下層の呼び出しである、例えばString()が、オブジェクト生成の責任を負う可能性を否定できない。よって、本発明の実施態様による表示例では、従来技術のよる表示よりも、滞留の原因がより絞り込まれて表示されている。
【０１１７】
箱（７０１）に含まれる共通の型のオブジェクト及び、木構造（７０２）に含まれる各呼び出しの共通部分は、プログラムロジックによって自動で又はユーザにより手動で合併又は分割が可能である。コンピュータ・システムは、例えば他のプログラム解析で得られる情報又はユーザからの入力をもとに、上記表示例における、例えば上記オブジェクト群又は上記呼び出し文脈のユーザへの見せ方を変更してもよい。例えば、上記表示例では、既に上記他のプログラム解析で得られる情報をもとに、Stringオブジェクト（７０４）に内包している配列オブジェクト（７０９）及びStringオブジェクト（７０８）が合併（compound）されて表示されている。また、上記表示例では、ByteBuffer オブジェクト（７０５）に内包している配列オブジェクト（７１０）が合併されて表示されている。
コンピュータ・システムは、上記合併すべきかどうかを一般的には自動的に判断できない。よって、コンピュータ・システムは、上記合併の操作をユーザに許すための機能を備えていてもよい。上記機能を備えるために、コンピュータ・システムは、上記合併の可能性を求める。上記合併の可能性は、オブジェクト間の参照関係から得ることができる。コンピュータ・システムは、あるオブジェクトＡが単一のオブジェクトＢからのみ参照されている場合、上記オブジェクトＡとオブジェクトＢとは合併可能であると判断する。
合併の動作を許す別の単純な方法では、コンピュータ・システムは、ある滞留因子に紐付けられた特定の型のオブジェクト群の各オブジェクトＣを参照しているオブジェクトＤが全て同一の滞留因子に紐付けられた同じ型である場合に、同じ滞留因子により滞留している同じ型のオブジェクト群を含む箱を合併可能な箱とみなす。また、コンピュータ・システムは、上記合併可能になるように、上記箱を分割して表示してもよい。
【０１１８】
図７Ｂは、本発明の実施態様における、図７Ａに示す表示例において、ユーザがオブジェクト群を示す箱の合併の動作を行った場合の例を示す。
図７Ａに示す表示例において、ユーザは、配列オブジェクト（７０６）及びStringオブジェクト（７０７）の上部に表示されている「＋」を例えばクリックすることによって、配列オブジェクト（７０６）及びStringオブジェクト（７０７）を合併して表示しうる。上記合併された結果、配列オブジェクト（７０６）及びStringオブジェクト（７０７）を合併したStringオブジェクト（７１１）が表示されうる。
【０１１９】
図７Ｃは、本発明の実施態様における、図７Ａに示す表示例において、ユーザが呼び出し文脈の合併の動作を行った場合の例を示す。
呼び出し文脈の共通部分は合併が可能である。図７Ａに示す表示例において、ユーザは、doXML()の下部に表示されている「−」を例えばクリックすることで、コンピュータ・システムは、doXML()よりも下層の呼び出しを合併して表示しうる。上記合併された結果、木構造（７０２）上の上記下層の呼び出しは、例えば、非表示になる。また、上記合併により、箱（７０１）が再構築され表示されうる。図７Ｃの表示例では、Stringオブジェクト（７０４）及びStringオブジェクト（７０５）が合併して表示されている。また、Stringオブジェクト（７０４）及びStringオブジェクト（７０５）それぞれに内包しているオブジェクト（７０８〜７１０）も合併して表示されている。
【０１２０】
以下では、図７Ａ〜図７Ｃの表示が実装されたプロファイラを使用して、プログラムを改善する例を示す。まず、上記プロファイラにおいて、上記プログラム実行中の状態についての図７Ａの表示がモニタにされたとする。
１．ユーザは、配列オブジェクト（７０６）とStringオブジェクト（７０７）とを見て、経験や知識から、配列オブジェクト（７０６）とStringオブジェクト（７０７）とはまとめて扱うべきだと考える。よって、ユーザは、合併の操作を行い、モニタには、図７Ｂの表示がされる。
２．ユーザは、Stringオブジェクト（７１１）の破線矢印で指された呼び出し文脈を確認し、滞留因子が、main()→doXML()→newName()であることを知る。よって、ユーザは、例えばツールによりナビゲートされるなりして、プログラムのソースコードのnewName()の定義を見る。
３．上記ツールは、生成文脈と接続文脈との共通文脈直後の各メソッドから、newName()中のどのメソッド呼び出しの組がメモリ滞留の原因と判定し、上記メモリ滞留の原因であるメソッド呼び出しをユーザに示す。ここで、例えば同じメソッドが違う場所で呼ばれているように、同一のメソッドについて複数呼び出し箇所がある場合もありえる。上記複数呼び出し箇所がある場合は、上記ツールは、例えば全ての呼び出し個所を提示する。
４．ユーザは、上記提示により、例えば利用しているキャッシュが利用すべきＧＣを阻害しないキャッシュと違うことに素早く気づき、ソースコードを修正しうる。
【０１２１】
図７Ｄは、本発明の実施態様における、ツールによるソースコード中の滞留原因の提示例及びユーザによる修正の様子を示す。
ツールにより、ソースコード（７２１）が表示されうる。該表示において、メモリ滞留の原因となりうるオブジェクト生成（７２３）及びオブジェクトの接続（７２４）が例えば太字で強調されて提示されうる。ユーザは、該提示により、利用している第１のキャッシュ（map）が利用すべきＧＣを阻害しない第２のキャッシュ（weakrefmap）でないことに気づく。
ユーザは、ソースコード（７２１）中の第１のキャッシュ（map）を利用している個所を、第２のキャッシュ（weakrefmap）を利用するように修正する。
該修正により、修正されたソースコード（７２２）が得られる。
本発明の実施態様を実装しないプロファイラが使用される場合、ユーザは、メモリ滞留の原因となりうるオブジェクト生成であるFactory.create()（７２３）を求めるために、呼ばれているメソッドを延々と調べる必要があった。よって、ユーザは、ソースコード（７２１）中のFactory.create()（７２３）の特定が困難であった。
しかしながら、上記ソースコード（７２１）が本発明に実施態様によって提示されることにより、ユーザは、メモリ滞留の原因であるFactory.create()（７２３）にすばやくあたりを付けられるようになっている。
【０１２２】
図８は、本発明の実施態様における、図１Ａ〜図１Ｂに示すシステムのハードウェアのブロック図を示す。
コンピュータ・システム（８０１）は、ＣＰＵ（８０２）とメイン・メモリ（８０３）と含み、これらはバス（８０４）に接続されている。ＣＰＵ（８０２）は好ましくは、３２ビット又は６４ビットのアーキテクチャに基づくものであり、例えばインテル社のＸｅｏｎ（商標）シリーズ、Ｃｏｒｅ（商標）シリーズ、Ａｔｏｍ（商標）シリーズ、Ｐｅｎｔｉｕｍ（商標）シリーズ、Ｃｅｌｅｒｏｎ（商標）シリーズ、ＡＭＤ社のＰｈｅｎｏｍ（商標）シリーズ、Ａｔｈｌｏｎ（商標）シリーズ、Ｔｕｒｉｏｎ（商標）シリーズ又はＳｅｍｐｒｏｎ（商標）を使用することができる。バス（８０４）には、ディスプレイ・コントローラ（８０５）を介して、ＬＣＤモニタなどのディスプレイ（８０６）が接続される。ディスプレイ（８０６）は、コンピュータ・システムの管理のために、通信回線を介してネットワークに接続されたコンピュータ・システムについての情報と、そのコンピュータ・システム上で動作中のソフトウェアについての情報を、適当なグラフィック・インターフェースで表示するために使用される。バス（８０４）にはまた、ＩＤＥ又はＳＡＴＡコントローラ（８０７）を介して、ハードディスク又はシリコン・ディスク（８０８）と、ＣＤ−ＲＯＭ、ＤＶＤドライブ又はＢＤドライブ（８０９）が接続される。
【０１２３】
ハードディスク（８０８）には、オペレーティング・システム、Ｊ２ＥＥなどのＪａｖａ（商標）処理環境を提供するプログラム、その他のプログラム及びデータが、メイン・メモリにロード可能に記憶されている。
【０１２４】
ＣＤ−ＲＯＭ、ＤＶＤ又はＢＤドライブ（８０９）は、必要に応じて、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ又はＢＤからプログラムをハードディスクに追加導入するために使用される。バス（８０４）にはさらに、キーボード・マウスコントローラ（８１０）を介して、キーボード（８１１）及びマウス（８１２）が接続されている。
【０１２５】
通信インタフェース（８１４）は、例えばイーサネット（商標）・プロトコルに従う。通信インタフェース（８１４）は、通信コントローラ（８１３）を介してバス（８０４）に接続され、コンピュータ・システム及び通信回線（８１５）を物理的に接続する役割を担い、コンピュータ・システムのオペレーティング・システムの通信機能のＴＣＰ／ＩＰ通信プロトコルに対して、ネットワーク・インターフェース層を提供する。なお、通信回線は、有線ＬＡＮ環境、或いは例えばＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎなどの無線ＬＡＮ接続規格に基づく無線ＬＡＮ環境であってもよい。
【図１Ａ】
2010277421.tif 000003
【図１Ｂ】
2010277421.tif 000004
【図１Ｃ】
2010277421.tif 000005
【図１Ｄ】
2010277421.tif 000006
【図１Ｅ】
2010277421.tif 000007
【図１Ｆ】
2010277421.tif 000008
【図２】
2010277421.tif 000009
【図３Ａ】
2010277421.tif 000010
【図３Ｂ】
2010277421.tif 000011
【図４】
2010277421.tif 000012
【図５Ａ】
2010277421.tif 000013
【図５Ｂ】
2010277421.tif 000014
【図５Ｃ】
2010277421.tif 000015
【図６Ａ】
2010277421.tif 000016
【図６Ｂ】
2010277421.tif 000017
【図７Ａ】
2010277421.tif 000018
【図７Ｂ】
2010277421.tif 000019
【図７Ｃ】
2010277421.tif 000020
【図７Ｄ】
2010277421.tif 000021
【図８】
2010277421.tif 000022