JP2013205911A - データ参照元特定システム及びその特定方法、並びにそのコンピュータ・プログラム - Google Patents

Abstract

【課題】参照先のオブジェクトのサイズが小さいか、もしくはオブジェクトの個数が少ない場合でもメモリリークの直接の原因となる参照元のオブジェクトを特定するシステム等を提供する。
【解決手段】アプリケーションの実行に伴って更新される、記憶領域におけるプログラムおよび元プログラムであるオブジェクト群の参照関係を表す参照情報群３に含まれるデータに基づいて、前記オブジェクト群を前記元プログラム読み込み機能を基準にしてグループ化するグループ化部１と、前記アプリケーションの終了に伴って破棄済みとマーキングされた破棄済みの元プログラム読み込み機能を基準にして、前記グループ化された情報に基づいてグループ化したグループに対して、該グループの外部から参照する参照元を特定する参照元特定部２とを有する。
【選択図】 図１

Description

本発明は、例えばメモリリークの原因となる情報の参照元を調べる情報処理の技術分野に関する。

今日、企業の業務や、社会生活で必要なサービスは、例えば通信ネットワークを介したアプリケーション（Ａｐｐｌｉｃａｔｉｏｎ；以下、アプリケーションもしくは、「ＡＰ」と称する）サーバによって提供されるようになっている。そして、ユーザは、利用可能な情報端末から、通信ネットワークを介してＡＰサーバにアクセスすることによって企業の業務ソフトウェアやインターネットサービスを利用することができる。

そしてこれらのサービスを提供するＡＰサーバにおいて動作するソフトウェアは、取り扱うさまざまな種類のデータとそのデータに関連するコードを一体的に扱うオブジェクト指向のプログラム言語を用いて開発したＡＰが用いられている。

例えばＪａｖａ（登録商標。以下、同様） Ｅｎｔｅｒｐｒｉｓｅ Ｅｄｉｔｉｏｎ（Ｊａｖａの企業用機能セット。以下、単に「Ｊａｖａ」もしくは、「Ｊａｖａ＿ＥＥ」と略称する。）に準拠したＡＰサーバは、自身に有するＪａｖａ Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ（Ｊａｖａ 仮想マシン。以下、「Ｊａｖａ＿ＶＭ」と略称する）において、複数のアプリケーションを独立に動作させることができる。

そのため、ＡＰサーバは、何れかのＡＰを必要に応じて配備する。これにより、そのＡＰは、ＡＰサーバの管理下に置かれると共に、不要となったＡＰは、ＡＰサーバから、その配備を取り外すことにより、そのＡＰはＡＰサーバの管理下から除外される。

つまり、ＡＰサーバは、あるＡＰを配備すると、そのＡＰ専用のクラスローダと呼ばれるプログラムの元となる元プログラムを読み込むための元プログラム読み込み機能を個別に生成すると共にそのＡＰに関連付ける。そしてＡＰサーバは、そのＡＰに関連付けされた元プログラム読み込み機能であるクラスローダを利用して、ＡＰを構成する元プログラムであるクラスや、プログラムであるオブジェクトを、ＡＰサーバが有するＪａｖａ＿ＶＭのメモリ領域に動的に配備（つまりロード）する。

ここでクラスとは、Ｊａｖａ＿ＶＭにおいて複数のデータ型の組み合わせを定義すると共に、その定義したデータ型に基づいて確保したメモリ領域において動作するオブジェクトを生成する元となる設計図である。また、オブジェクトとは、設計図であるクラスを基に、Ｊａｖａ＿ＶＭが有するメモリ領域において動作するデータとそのデータに関連するコードを一体的に構成したプログラムの実体である。

そして、ＡＰサーバは、メモリに展開されたクラスやオブジェクトとからなるＡＰを実行状態にすると共に、リクエストの受け付けを開始する。なお、リクエストとは、ＡＰサーバからＡＰを実行するためのＡＰサーバへの要求である。

すなわち、図２に示す、背景技術としてのＡＰサーバのソフトウェア構成を示す図にあるように、ＡＰサーバ２０は、動作させたいＡＰ１をクラスローダ２１に配備することによってＡＰ１と関連付けると共に、ＡＰ１を構成するクラス２２とオブジェクト２１とを図示していないメモリ上に展開することによってＡＰ１を動作させる。

ここで、クラスローダの生成について、図３を用いて具体的に説明する。Ｊａｖａ＿ＥＥに準拠したＡＰサーバには、配備されたＡＰが共通に利用する共通クラスローダ群２−１が存在する。共通クラスローダ群２−１は少なくとも一つ以上のクラスローダで構成されており、基本的には親子関係をもつ階層構造を有している。

なお、ＡＰサーバは、Ｏｐｅｎ Ｓｅｒｖｉｃｅｓ Ｇａｔｅｗａｙ ｉｎｉｔｉａｔｉｖｅ（以下、「ＯＳＧｉ」と略称する）のフレームワークに代表されるようなネットワーク状に結合した構造を有している場合もある。

ＡＰサーバに対してＡＰを配備すると、ＡＰサーバは、配備したＡＰをロードするための専用のクラスローダを、共通クラスローダ群２−１の子のクラスローダとして生成し、ＡＰに関連付ける。

図３では、ＡＰサーバに３つのＡＰが配備されている状況を示しており、各ＡＰごとに専用のクラスローダ２−２、２−３、２−４を有している。

また、ＡＰサーバはＡＰを停止状態にするか、あるいは配備を取り外すか、もしくはリクエストの受け付けを行わないようにすることによって、そのＡＰの動作を取りやめることもできる。

そして、ＡＰサーバはＡＰの動作を取りやめる際に、ＡＰに関連付けているクラスローダがもはや不要となるので、ＡＰサーバによってメモリ領域などの対応するリソースを解放するために、そのクラスローダに対して破棄処理を実施すると共に、破棄済みの旨をマーキングする。

そして、ＡＰサーバは、ＡＰを構成するクラスやオブジェクトに対する参照を切断すると共に、それらをガベージコレクション（Ｇａｒｂａｇｅ Ｃｏｌｌｅｃｔｉｏｎ；以下、「ＧＣ」と称する）の対象とする。

ここで、ＧＣの対象にするとは、メモリに存在するクラスやオブジェクトの参照関係を示す参照先を矢印で示す有向グラフにおいて、ＧＣルートと呼ばれている参照元を矢印の起点とする有向グラフの開始地点からの到達を到達不能にすることである。

ＧＣの対象について、図４を用いて具体的に説明する。図４に示す３−１と３−２は、ＧＣルートを示している。３−３がＧＣルートから有向グラフを辿って到達可能な範囲を示している。

ここで、クラスやオブジェクトがＧＣの対象になるということは、クラスやオブジェクトのプログラムに用いる変数の値にＮｕｌｌ（すなわち変数の値が無いことを意味する）を代入したり、実行中のスレッドを停止したりすることで、３−１、３−２、３−３から到達不能にすることである。

そして、３−４のように３−１、３−２、３−３と全く関わりを持たなくなった孤立した参照関係を有する部分グラフはＧＣの対象となる。また３−５は３−３と結合しているが、辺の矢印の向きが３−５から３−３に向かうもののみであり、３−１、３−２、３−３からは到達不能なので、ＧＣの対象である。

しかしながら、ＡＰは、ＡＰサーバがＡＰを停止するか、配備の取り外しか、もしくはリクエストの受付を行わないようにしようとしても、ＡＰの不具合等によりそのＡＰを構成するクラスやオブジェクトがＧＣルートから到達不能にならない（すなわち、到達することができてしまう）場合がある。

そのような場合は、ＡＰを構成するクラスやオブジェクトが意図せずにメモリに残存し続けることになり、このような現象をメモリリークと呼ぶ。このメモリリークを放置しておくとメモリ領域が枯渇する恐れがあり、ＡＰサーバおよびＡＰの動作異常に繋がる。

そのために、Ｊａｖａのアプリケーションにおいて、メモリリークの原因を特定するためには、起動時にＪａｖａ＿ＶＭから共通的なメモリ領域であるヒープ領域が割り当てられたのちに、Ｊａｖａ＿ＶＭの実行中にはヒープダンプと呼ばれるＡＰを実行する際に必要となる参照関連のデータをファイルとして取得すると共に、そのファイル内容を解析することにより参照元を辿ることができる。

つまり、ヒープとは、ＡＰサーバが動的に確保したオブジェクトを格納するメモリ領域である。

またヒープダンプとは、そのメモリ領域のデータの内容を表示した一覧であり、例えばＧＣルートと、クラスをロードしたクラスローダと、クラスと、クラスが生成したオブジェクトとを表すＩＤやアドレス情報およびこれらのオブジェクトの参照関係の情報が保持されている。

そして、クラスやオブジェクトの参照関係を調べるためにはこれらの情報を入力として解析する必要がある。

ここで、データとして取り扱うクラスローダ、クラス、オブジェクトおよびオブジェクトの一種であるＧＣルート（すなわちＧＣの開始点）を表すＩＤやアドレス情報を総称する際には、単に「オブジェクト」もしくは「オブジェクト群」と呼ぶ場合がある。

また、プログラムとしてのオブジェクトは「プログラム」もしくは「プログラムオブジェクト」と呼ぶこととする。

上述したような問題を解決するため、特許文献１に記載の技術は、Ｊａｖａ＿ＶＭで発生するメモリリークの原因を、オブジェクトの参照関係を辿ることにより、メモリリークが発生する危険性を検出することで原因箇所を特定しやすくする技術を開示する。

また、特許文献２に記載の技術は、データ領域に設定する状態規則に反するデータを見つけ、そのデータに設定する参照規則に反する参照関係からメモリリークを検出する技術を開示する。

特開２００５−３０１６６０号公報 特開２００７−００４４１３号公報

特許文献１に記載の技術は、メモリ領域にある複数のデータ相互間の参照関係について、先の時刻と後の時刻におけるその差分データに重み付けをすることによりメモリリークの原因を特定しようとしている。

しかしながら、特許文献１に記載の技術は、各データのサイズに応じて重みの値を変えると共に、参照先のデータの重み値を参照元のデータの重み値に加算する。これによりメモリリークが発生する可能性があるデータを検出するので、係る技術によればメモリリークを検出することはできるが、メモリリークの直接の原因となる参照元の特定はできないという課題がある。

また、特許文献２に記載の技術は、データタイプと格納先領域（つまり短期間かもしくは長期間かの世代別ヒープ領域）と同一クラスのデータの数の条件とからなる状態規則および、参照条件(クラスのクラスローダへの他のオブジェクトからの参照数)に応じて異常な参照関係であるか否かを判断しようとしている。

しかしながら、特許文献２に記載の技術は、リーク対象メモリの記憶領域に、状態規則に反する場合に記憶する参照状態の情報データを追加、保存するので、さらなるメモリリーク量の増大を招くこととなり、ＡＰサーバ、またはＡＰで使用できるメモリ総量を減少させる。つまり、係る技術では結果的にさらなるメモリリークの状態となる可能性がある。

また、ヒープダンプからメモリリークを特定するための一般的な手段は、以下の二つである。一つ目は、あるオブジェクトから到達可能なオブジェクトのサイズの総合計が巨大なものを特定する。二つ目は、あるクラスのオブジェクトの個数が大量であるものを特定する。つまり、一般的な手段においてメモリリークを検出するためには、リークしているオブジェクトのサイズや個数が異常と判断できる程度の大きさが必要である。

上述した一般的な技術では、長時間かけてサイズの小さい参照先オブジェクトへ少しずつメモリの参照がリークするような場合には、テスト環境のような比較的稼働時間が短い環境では検出が困難であり、正確な分析が不十分なままシステムの運用に移行する可能性がある。

また、実際の運用環境では２４時間、３６５日稼働することも珍しくはなく、このような潜在的な不具合がある場合には、最終的にメモリ枯渇に陥ることにより、動作が困難になる可能性がある。

本発明の主たる目的は、上述した課題を解決するために、参照先のオブジェクトのサイズが小さいか、もしくはオブジェクトの個数が少ない場合でもメモリリークの直接の原因となる参照元のオブジェクトを特定するシステム等を提供することにある。

本発明は、上述した課題の解決を目的としてなされた。即ち、本発明に係るデータ参照元特定システム等は、アプリケーションの配備に伴って元プログラム読み込み機能を生成すると共に該元プログラム読み込み機能を用いて前記アプリケーションを構成するオブジェクト群であるプログラムおよびその元プログラムとが記憶領域に生成して実行される情報処理装置において、アプリケーションの実行に伴って更新される、記憶領域における前記オブジェクト群の参照関係を表す参照情報群に含まれるデータに基づいて、前記オブジェクト群を前記元プログラム読み込み機能を基準にしてグループ化するグループ化部と、
前記アプリケーションの終了に伴って破棄済みとマーキングされた破棄済みの元プログラム読み込み機能を基準にして、前記グループ化された情報に基づいてグループ化したグループに対して、該グループの外部から参照する参照元を特定する参照元特定部とを有する。

なお、同目的は、上記構成を有するデータ参照元特定方法をコンピュータによって実現するコンピュータ・プログラム、およびそのコンピュータ・プログラムが格納されている、コンピュータ読み取り可能な記憶媒体によっても達成される。

本発明によれば、参照先のオブジェクトのサイズが小さいか、もしくは個数が少ない場合でもメモリリークの直接の原因となる参照元のオブジェクトを特定することができる。

本発明の第１の実施形態に係るデータ参照元特定システムの概要を示すブロック図である。 背景技術としてのＡＰサーバのソフトウェア構成を示す図である。 背景技術としてのＪａｖａ＿ＥＥに準拠したＡＰサーバのクラスローダの関係を示す図である。 背景技術としてのＪａｖａ＿ＥＥに準拠したＧＣの到達範囲を示す図である。 本発明の第２の実施形態に係る破棄済みクラスローダと、ＧＣルートから到達不能になる条件を説明する図である。 本発明の第２の実施形態に係る破棄済みクラスローダへのグループ外から参照する例を説明する図である。 本発明の第２の実施形態に係るデータ参照元特定システムの機能を概念的に示すブロック図である。 本発明の第２の実施形態に係るヒープダンプテーブルの図である。 本発明の第２の実施形態に係るグループ化テーブルの図である。 本発明の第２の実施形態に係るグループ外からの参照を表すテーブル図である。 本発明の第２の実施形態に係るグループ化モジュールの動作を示すフローチャートである。 本発明の第２の実施形態に係る参照探索モジュールの動作を示すフローチャートである。 本発明の第２の実施形態に係るグループ化モジュール動作前のグループ化テーブル図である。 本発明の第２の実施形態に係るグループ化モジュール動作の際に、種別がクラスローダの場合のグループ化テーブル図である。 本発明の第２の実施形態に係るグループ化モジュール動作の際に、種別がクラスの場合のグループ化テーブル図である。 本発明の第２の実施形態に係るグループ化モジュール動作の際に、種別がその他のクラスの場合のグループ化テーブル図である。 本発明の第２の実施形態に係るグループ化モジュール動作の際に、種別がオブジェクトの場合のグループ化テーブル図である。 本発明の第２の実施形態に係るグループ化モジュール動作の際に、種別がその他のオブジェクトの場合のグループ化テーブル図である。 本発明の第４の実施形態に係るデータの参照元を特定するコンピュータ・プログラムを説明する図である。

以下、本発明を実施する形態について図面を参照して詳細に説明する。

＜第１の実施形態＞
本発明の第１の実施形態の構成について説明する。図１は、本発明の第１の実施形態に係るデータ参照元特定システムの概要を示すブロック図である。

本実施形態のデータ参照元特定システム１０は、グループ化部１と、参照元特定部２と、参照情報群３とからなる。

また、図２は背景技術としてのアプリケーション（以下、「ＡＰ」と称する）サーバのソフトウェア構成を示す図である。本背景技術のＡＰサーバ２０は、プログラム２３の設計図である元プログラム２２を読み込む、元プログラム読込み機能２１と、元プログラム２２と、プログラム２３とを有する。

図１に示す、グループ化部１は、データ参照元特定システム１０が動作する際の図示していないメモリにある情報の一部を記憶する参照情報群３の情報に基づいて、元プログラム読込み機能２１を基準として、元プログラム２２と、プログラム２３とをグループ化する。

ここで、参照情報群３とは、ＡＰサーバ２０において、図示していないメモリにある元プログラム読込み機能２１と、元プログラム２２およびプログラム２３を識別するためのＩＤやアドレス情報を、外部装置もしくは運用管理者による自動もしくは手動による指示によって取り込まれる情報群のことである。

参照元特定部２は、参照情報群３に基づいて、何れかのアプリケーションの終了に伴って破棄されることにより“破棄済み”とマーキングされた元プログラム読み込み機能２１を基準として、上述したグループ化部１によってグループ化された元プログラム２２とプログラム２３とを含む破棄済み元プログラム読み込み機能のグループをそのグループの外部から参照する参照元のプログラムの識別子（すなわち、ＩＤ）やアドレス情報を特定する。

また、破棄済みの元プログラム読み込み機能２１を基準としてグループ化されたグループの元プログラム２２やプログラム２３が占有するＡＰサーバのメモリ資源を解放する図示していないメモリ開放機能が参照するその参照元のプログラムのＩＤやアドレス情報をも特定する。

なお、参照情報群３におけるグループ化対象である元プログラム読み込み機能２１と、元プログラム２２と、プログラム２３および図示していないメモリ開放機能の参照開始点からの参照に関するＩＤやアドレス情報は、説明の便宜上「グループ化対象データ」と称することとする。

また、参照情報群３は、本データ参照元特定システム１０に有することを限定しているわけではなく、本データ参照元特定システム１０を含むＡＰサーバが有していてもかまわない。

次に、本実施形態のデータ参照元特定システム１０の動作について説明する。本データ参照元特定システム１０は、図示していない外部装置もしくは、運用管理者によって自動もしくは手動によって起動されると共に、その動作に応じて図示していないメモリにある、プログラムである元プログラム読み込み機能２１と、元プログラム２２と、プログラム２３および、図示していないメモリ開放機能の参照を開始するオブジェクト群を識別するためのＩＤやアドレス情報である参照情報群３を生成または更新する。

そして、本データ参照元特定システム１０のグループ化部１は、生成または更新された参照情報群３のデータに基づいて、上述した元プログラム読み込み機能２１と、元プログラム２２と、プログラム２３および図示していないメモリ開放機能の参照開始点を表すＩＤやアドレス情報からなるグループ化対象データを、当該プログラム２３が属する当該元プログラム２２を読み込んだ元プログラム読み込み機能２１を基準にしてグループ化する。

そして、本データ参照元特定システム１０の参照元特定部２は、何れかのアプリケーションの終了に伴って、図示していない破棄済みとマーキングされた破棄済みの元プログラム読み込み機能を基準にして前記グループ化された際の情報に基づいてグループ化したグループに対して、そのグループの外部から参照する参照元を特定する。

上述したグループ分けによって、参照先の元プログラムやプログラムのサイズや個数に依らずに、ＡＰサーバ２０に配備されたアプリケーションを停止あるいは取り外した際に、破棄済みとマーキングされた元プログラム読み込み機能２１である破棄済み元プログラム読み込み機能のグループをそのグループの外部から直接的に参照する元プログラム２２およびプログラム２３を特定することができる。

また、グループの外部から直接的に参照することができる参照元は、破棄済み元プログラム読み込み機能が有する元プログラム２２およびプログラム２３が占有するＡＰサーバのメモリ資源を解放するメモリ資源解放機能の参照開始点からの参照をもその参照元として特定することができる。

すなわち本実施形態によれば、参照元のプログラムを直接的に特定することができるので、参照先のプログラムのサイズが小さいか、もしくは個数が少ない場合でもメモリリークの直接の原因となる参照元のプログラムを特定することができるという効果を奏することができる。

また、本実施形態によれば、参照先のプログラムのサイズが小さいか、もしくは個数が少ない場合でもメモリリークの直接の原因となる参照元のプログラムを効率的に特定することができるので、例えば開発や評価途上での長時間動作試験などを実施しなくてもメモリリークを容易に検出することができるという効果を奏することができる。

さらに、本実施形態によれば、ＡＰにおける複数の時点での参照情報群を比較して元プログラムやプログラムの増減を観察する必要がなく、ある時点での単一の参照情報を用いるだけでメモリリークの参照元のプログラムを特定することができるという効果を奏することができる。

つまり、本実施形態によれば、参照先のプログラムのサイズが小さいか、もしくはプログラムの個数が少ない場合でもメモリリークの直接の原因となる参照元のプログラムを特定することができるという効果を奏することができる。

以上、本発明の第１の実施形態として、上述した構成および動作を例に説明したが、本発明は、必ずしも係る構成や動作には限定されない。

＜第２の実施形態＞
次に、第１の実施形態を基本とする本発明の第２の実施形態について図７を参照してその構成を説明する。図７は第２の実施形態に係るデータ参照元特定システムの機能を概念的に示すブロック図である。本ブロック図は、第２の実施形態のデータ参照元特定システムにおける課題を解決するために以下の３つの主要なモジュールからなる。

すなわち、破棄済みクラスローダ探索モジュール６−３は、参照情報群３であるヒープダンプ６−２を入力として破棄済みクラスローダを探索するモジュールである。

また、グループ化モジュール６−４は、破棄済みクラスローダの一覧およびヒープテーブル６−２を入力として破棄済みクラスローダのグループとそれ以外のグループとをグループ分けすると共にグループ化テーブル６−７を生成するモジュールである。

そして、参照探索モジュール６−５は、ヒープダンプ６−２と、グループ化テーブル６−７を入力として、そのうちの破棄済みクラスローダのグループへの参照を示すグループ外からの参照テーブル６−８を生成すると共にその参照元を見つけるモジュールである。

ここで、モジュールとは、例えば本データ参照元特定システム１０のアプリケーションソフトウェアを構成する個々の処理機能である。また、これらのモジュールは、例えば後述する図１９に示すようなコンピュータのハードウェア資源において実行される。

なお、第１の実施形態で説明した図２における元プログラム読み込み機能２１と、元プログラム２２と、プログラム２３は、第２の実施形態においては、それぞれクラスローダ、クラス、オブジェクトと呼ぶこととする。

ここで、図５および図６を参照して上述した主要モジュールのうち、まず、破棄済みクラスローダの探索についてその概要から説明する。本実施形態に係るデータ参照元特定システム１０であるＡＰサーバは、何れかのＡＰの停止などに伴って、不要となったクラスローダのリソース解放処理を行う。そして係るＡＰサーバは、当該不要となったクラスローダを“破棄済み”とマーキングする。

本実施形態では、クラスローダが破棄済みとマーキングされることと、クラスローダがＧＣルートから到達不能になる以下の２つ条件を利用する。すなわち、
条件１は、そのクラスローダを直接的に参照するクラスやオブジェクトが存在しないこと、そして、
条件２は、そのクラスローダがロードしたクラス、およびそのクラスのオブジェクトがＧＣルートから到達不能であること。
である。

上記条件について、図５を用いて詳細に説明する。図５は、本実施形態における破棄済みクラスローダと、ＧＣルートから到達不能になる条件を説明する図である。上述した条件１は、ＧＣの対象となって参照を切断するためには、ＧＣルートから到達不能である必要がある。

しかし、クラスローダＸは、ＧＣルートαから４−１、４−２という経路で到達可能であるため、４−１あるいは４−２またはその両方の参照を切断する必要がある。また、上述した条件２は、ソースコード上には現れないが、Ｊａｖａ＿ＶＭが実行時にヒープダンプテーブルに追加する暗黙的な参照が存在するために必要になる条件である。

ここで、暗黙の参照は具体的には二つあり、一つはクラスに対して、そのクラスをロードしたクラスローダへの暗黙の参照を追加することである。もう一つはオブジェクトに対して、そのオブジェクトのクラスへの暗黙の参照を追加することである。

暗黙の参照は、図５に示すように破線で示している。クラスＡは、ＧＣルートαから４−１、４−３という経路で到達可能であり、なおかつクラスAからクラスローダＸへの暗黙の参照４−４が存在するため、クラスローダＸが連鎖的に到達可能となる。

また、クラスCのオブジェクト４−８は、ＧＣルートαから４−１、４−５という経路で到達可能であり、なおかつオブジェクト４−８からクラスCへの暗黙の参照４−６と、クラスCからクラスローダＸへの暗黙の参照４−７が存在するため、クラスローダＸが連鎖的に到達可能となる。従ってこれらの参照を切断する必要がある。

本実施形態では、クラスローダが破棄済みとマーキングされているにもかかわらず、上述した条件１および条件２を暗黙の参照も含めて満たしていない場合にメモリリークが発生していると判断する。そして、本実施形態では、上記条件を満たしていない事を判別するために、クラスローダを基準にして、そのクラスローダによってロードされたクラスと、そのクラスのオブジェクトをグループ化する。

また、破棄済みのクラスローダのグループについてグループ外からグループ内への参照がある場合、これはＧＣの対象になっていないオブジェクトから、ＧＣの対象になるべきオブジェクト、すなわち破棄済みのクラスローダの配下に存在するオブジェクトを参照していることを意味する。

上述したグループ化および、グループ外からの参照について図６を用いてさらに詳細に説明する。図６は、本実施形態に係る破棄済みクラスローダへのグループ外から参照する例を説明する図である。

図６に図示していないＡＰサーバは、クラスローダＣＬＹにおいて、グループ化したクラスやオブジェクトのグループ５−１のクラスローダＣＬＹが、破棄済みである旨のマーキングをしておらず、またＧＣの対象ではないものとする。

これに対し、ＡＰサーバは、クラスローダＣＬＸにおいて、そのクラスローダＣＬＸを基準にしてグループ化されたクラスやオブジェクトのグループ５−２のクラスローダＣＬＸが破棄済みである旨のマーキングをしているために、ＧＣの対象にするべきものである。

しかしながら、図６に示すような以下の６つのケースにおいて、それらの参照をたどることにより、ＧＣルート（つまり、図６に示すＧＣＲ０とＧＣＲ１）からクラスローダＣＬＸに到達可能であり、クラスローダＣＬＸは、破棄済みにも関わらずＧＣの対象にできないという矛盾が生じる。すなわち、
１．グループ外からの参照であるＧＣルートＧＣＲ０から、クラスローダＣＬＸへの参照５−３が存在することにより、ＧＣルートＧＣＲ０から直接到達可能である。

２．グループ外からの参照であるＧＣルートＧＣＲ０からクラスＣＸ０への参照５−４が存在することにより、参照５−４、暗黙的な参照５−５という経路でＧＣルートＧＣＲ０から到達可能である。

３．グループ外からの参照であるＧＣルートＧＣＲ０からオブジェクトＯＸ０への参照５−６が存在することにより、参照５−６、暗黙的な参照５−７、暗黙的な参照５−５という経路でＧＣルートＧＣＲ０から到達可能である。

４．グループ外からの参照であるオブジェクトＯＹ４からクラスローダＣＬＸへの参照５−１０が存在することにより、参照５−８、参照５−９、参照５−１０という経路でＧＣルートＧＣＲ１から到達可能である。

５．グループ外からの参照であるオブジェクトＯＹ５からクラスＣＸ３への参照５−１２が存在することにより、参照５−８、参照５−１１、参照５−１２、暗黙的な参照５−１３という経路でＧＣルートＧＣＲ１から到達可能である。

６．グループ外からの参照であるオブジェクトＯＹ６からオブジェクトＯＸ６への参照５−１４が存在することにより、参照５−８、参照５−１４、暗黙的な参照５−１５、暗黙的な参照５−１３という経路でＧＣルートＧＣＲ１から到達可能である。

なお、図４の３−４に示すように、参照がグループ内に閉じていれば、本本発明の実施形態が特定しようとするメモリリークに該当することはない。

つまり、第１の実施形態本のデータ参照元特定システム１０のグループ化部１および、後述する本実施形態のグループ化モジュール６−４において、上述した特性を利用してグループ分けを行う。

なお、図７に示す、本実施形態のグループ化モジュール６−４と、参照探索モジュール６−５およびヒープダンプ６−２は、それぞれ第１の実施形態のグループ化部１と、参照元特定部２と、参照情報群３とに対応する。

引き続き、本発明の第２の実施形態について図７乃至図１８を参照してさらに詳細に説明する。図７は、本発明の第２の実施形態に係るデータ参照元特定システムの機能を概念的に示すブロック図である。

本実施形態のデータ参照元特定システム１０は、図示していないＡＰサーバにより破棄済みとマーキングされたクラスローダを探し出し、このクラスローダによってロードされたクラスおよびそのオブジェクトをグループ化すると共に、このグループ外からの参照を見つけることによってメモリリークの直接の原因となる参照を特定するシステムである。

本発明の第２の実施形態の構成は、図７において以下の構成からなる。

入力装置６−１は、本実施形態のデータ参照元特定システム１０を始動する指令を発生するユーザインタフェースである、例えばキーボード（Ｋｅｙ Ｂｏａｒｄ；以下、「ＫＢ」と略称する）やマウスあるいは、本データ参照元特定システム１０に接続する外部装置等である。

次に、ヒープダンプ６−２（つまり、図８に示すヒープダンプテーブル図に対応する。以下、同様）は、図示していないＪａｖａ＿ＶＭがメモリ領域に生成したヒープダンプである。具体的には、図８に示す本実施形態に係るヒープダンプテーブル図にあるように、このテーブルにはＪａｖａ＿ＶＭにおけるＧＣルートと、クラスローダと、クラスと、オブジェクトおよびとの参照先を表す情報とが関連付けされた状態で格納されている。

つまり、上述したオブジェクトの一種であるＧＣルートと、クラスローダと、クラスおよび、オブジェクトにＩＤ（つまりメモリアドレスなどのアドレス情報）を割り振り、オブジェクトＩＤ間の関係性を記録したテーブルがＪａｖａ＿ＶＭが備えるヒープダンプテーブルである。

以下、図８に示すヒープダンプテーブルの６つの列について個々に説明する。すなわち、
１）オブジェクトＩＤ（ＩＤは、すなわち識別子を意味する）は、レコードが示すオブジェクトを識別するＩＤである。

ここで、レコードとは、データを格納する図８に示すヒープダンプテーブルの様な表における各行ごとの個々の登録データを指す。

２）種別は、そのレコードが保持するデータの種類であり、ＧＣルート、クラスローダ、クラス、オブジェクトがある。

３）クラスのオブジェクトＩＤは、そのオブジェクトが属するクラスを示すオブジェクトＩＤである。種別がオブジェクトの場合だけ値が存在する。
なお、種別がオブジェクト以外であれば、ｎ／ａ（ｎｏｔ ａｐｐｌｉｃａｂｌｅ、すなわち、“該当せず”。以下、同様）と記載する。

４）クラスローダのオブジェクトＩＤは、そのクラスをロードしたクラスローダを示すオブジェクトＩＤである。種別がクラスの場合だけ値が存在する。

５）参照先のオブジェクトＩＤは、そのオブジェクトのクラスに直接宣言された変数であるフィールド等が参照しているオブジェクトのオブジェクトＩＤである。ここでフィールドとは、クラスの変数の中身のことである。また、図８に示すヒープダンプテーブルの参照先のオブジェクトＩＤ欄にあるように、参照先のオブジェクトＩＤの個数は０個以上の参照を保持できるものとする。

６）破棄済みか？欄は、そのクラスローダが破棄済みであるか否かを示す。レコードの種別がクラスローダの場合だけ値が存在する。

次に、図７に示すデータ参照元特定システムの機能を概念的に示すブロック図において、破棄済みクラスローダ探索モジュール６−３は、ヒープダンプ６−２を入力とし、ＡＰサーバにより破棄済みとマーキングされたクラスローダを探索し、その一覧を出力するモジュールである。

また、グループ化モジュール６−４は、上述したヒープダンプ６−２と、破棄済みクラスローダ探索モジュールの出力である破棄済みクラスローダの一覧を入力とし、破棄済みクラスローダによってロードされたクラスおよびそのオブジェクトをその破棄済みクラスローダを基にグループ化すると共に、図９に示すようなグループ化テーブル６−７を出力するモジュールである。

また、参照探索モジュール６−５は、ヒープダンプ６−２と、グループ化テーブル６−７を入力とすることによって、グループ外のオブジェクトからグループ内に入ってくる参照元を特定すると共に、図１０に示すようなグループ外からの参照を表すテーブル６−８を出力するモジュールである。

また、出力装置６−６は、本実施形態に係るデータ参照元特定システム１０における処理結果を出力する装置である。本出力装置６−６は、例えば液晶ディスプレイやファイルシステムにおけるファイルや、本データ参照元特定システム１０の外部に接続する外部装置等である。

また、グループ化テーブル６−７は、グループ化モジュール６−４の出力結果であり、破棄済みクラスローダによってロードされたクラスおよびそのオブジェクトをグループ化したテーブルである。その具体的な内容について図９に示す。図９は、本実施形態に係るグループ化テーブル図である。

そして図１０に示す、グループ外からの参照テーブル６−８は、グループ化モジュール６−４によって破棄済みクラスローダを基にグループ化したグループ化対象オブジェクトに対して、他の破棄済みではないクラスローダを基にグループ化したグループ化対象オブジェクトからの参照履歴を記録したテーブルである。

続いて、図７、図１１、図１２を用いて本データ参照元特定システム１０の動作についての説明を行う。

まず、図７に示す、本実施形態に係るデータ参照元特定システムの機能を概念的に表すブロック図に示す、入力装置６−１において、本データ参照元特定システムを始動させるための指令を発生する。指令は例えば外部装置による自動や、ＫＢやマウスなどを用いて手動により入力装置６−１から入力する。

本データ参照元特定システム１０は、自装置であるＡＰサーバによって破棄済みとマーキングされたクラスローダを探索するために、ヒープダンプ６−２を入力とし、破棄済みクラスローダ探索モジュール６−３の処理を実行する。そして、その破棄済みクラスローダ探索モジュール６−３は、破棄済みクラスローダの一覧（不図示）を出力する。

また、グループ化モジュール６−４は、ヒープダンプ６−２と上述した破棄済みクラスローダの一覧を入力として呼び出される。

そして、グループ化モジュール６−４は、破棄済みクラスローダを含むクラスローダによって、ロードされたクラスおよびそのオブジェクトをグループ化すると共に、グループ化テーブル６−７を出力する。

そして、参照探索モジュール６−５は、ヒープダンプ６−２（つまり、図８）に示すレコードの「参照先のオブジェクトＩＤ」が、グループ化テーブル６−７（つまり、図９）に示す「配下のオブジェクトＩＤ」に一致するオブジェクトを特定すると共に、グループ外からの参照テーブル６−８（つまり、図１０）に登録する。

すなわち、破棄したはずのクラスローダの配下のオブジェクトを、グループ外から参照先にしていることが直接的に判るわけである。

出力装置６−６は液晶ディスプレイや、ファイルシステムにおけるファイル、もしくは外部のプログラムモジュールなどであり、入力であるグループ外からの参照テーブル６−８を出力装置６−６の種類に応じて出力する。

引き続き、図７に示すデータ参照元特定システムのブロック図におけるグループ化モジュール６−４のグループ分けの動作について、図１１を用いて詳しく説明する。図１１は本実施形態に係るグループ化モジュールの動作を示すフローチャートである。

グループ化モジュール６−４は、ヒープダンプ６−２と、破棄済みクラスローダ探索モジュール６−３からの破棄済みクラスローダの一覧の入力に応じて、開始（ステップＳ１０−１）より始まる。グループ化モジュール６−４は、入力であるヒープダンプ６−２の未処理のレコードがなくなるまで繰り返す（ステップＳ１０−２、Ｓ１０−８）。

グループ化モジュール６−４は、レコードに対する繰り返し処理が開始されると、まず、ヒープダンプ６−２より未処理のレコードを取得する（つまり、図８に示す“行”を１行ごとに取得する。ステップＳ１０−３）。ここで、取得したレコードを説明の便宜上、“ＲＥＣＯＲＤ”と表現する。次にレコードの「種別」を、図８に示す「種別」から判別する（ステップＳ１０−４）。

グループ化モジュール６−４は、レコードの種別がオブジェクトの場合は、そのオブジェクトに関連するクラスローダを特定するために、ＲＥＣＯＲＤの中の「クラスのオブジェクトＩＤ」からクラスを特定（ステップＳ１０−５）すると共に、さらに特定されたクラスのレコードに存在する「クラスローダのオブジェクトＩＤ」を基に、グループ化テーブル６−７にＲＥＣＯＲＤを追加登録する（ステップＳ１０−６）。

グループ化モジュール６−４は、グループ化テーブル６−７に登録する情報として、「クラスローダのオブジェクトＩＤ」列と、「配下のオブジェクトＩＤ」列の２つの列に対して、それぞれ以下の値をとる。「クラスローダのオブジェクトＩＤ」の値は、前述の手順で取得した「クラスローダのオブジェクトＩＤ」の値である。また、「配下のオブジェクトＩＤ」の値は、そのＲＥＣＯＲＤが持つ「オブジェクトＩＤ」の値である。

次に、グループ化モジュール６−４は、レコードの種別がクラスの場合には、そのＲＥＣＯＲＤの情報をグループ化テーブル６−７に追加登録する（ステップＳ１０−６）。

そして、グループ化モジュール６−４は、グループ化テーブル６−７に登録する情報として、「クラスローダのオブジェクトＩＤ」列と、「配下のオブジェクトＩＤ」列の２つの列に対してそれぞれ以下の値をとる。「クラスローダのオブジェクトＩＤ」の値は、ＲＥＣＯＲＤ中の「クラスローダのオブジェクトＩＤ」の値である。また、「配下のオブジェクトＩＤ」の値は、そのＲＥＣＯＲＤが持つ「オブジェクトＩＤ」の値である。

次に、グループ化モジュール６−４は、レコードの種別がクラスローダの場合には、そのＲＥＣＯＲＤの情報をグループ化テーブル６−７に登録する（ステップＳ１０−７）。

そして、グループ化モジュール６−４は、グループ化テーブル６−７に登録する情報として「クラスローダのオブジェクトＩＤ」列と、配下のオブジェクトＩＤ」列の２つの列に対してそれぞれ以下の値をとる。「クラスローダのオブジェクトＩＤ」の値は、ＲＥＣＯＲＤ中の「オブジェクトＩＤ」の値である。また、「配下のオブジェクトＩＤ」の値もそのＲＥＣＯＲＤが持つ「オブジェクトＩＤ」の値である。

そして、グループ化モジュール６−４は、レコードの種別がオブジェクトでもクラスでもない、例えばＧＣルートなどのその他の場合には、何も処理を実施せずに図１１に示すステップＳ１０−８からステップＳ１０−２の間においてヒープダンプテーブル６−８の未処理レコードがなくなるまで繰り返し実施する。

グループ化モジュール６−４は、未処理のレコードがなくなると処理が完了し（１０−９）、グループ化テーブル６−７すなわち、図９のグループ化テーブルを出力する。

続いてグループ化モジュール６−４は、ヒープダンプ６−２とグループ化テーブル６−７とを入力として参照探索モジュール６−５を呼び出す。

ここで、上述したグループ化モジュール６−４の実際の挙動について、図８に示すヒープダンプテーブル図のデータに基づいて、図１１に示すグループ化モジュールの動作を示すフローチャートを用いてさらに具体的に説明する。

まず、グループ化モジュール６−４が動作する前は、出力結果であるグループ化テーブル６−７は、図１３に示す本実施形態に係るグループ化モジュールが動作する前のグループ化テーブル図に示すように空の状態である。

グループ化モジュール６−４は、動作を開始すると（ステップＳ１０−１）、入力であるヒープダンプ６−２のレコードに対する繰り返し処理（ステップＳ１０−２、ステップＳ１０−８）を実施する。

次に、グループ化モジュール６−４は、ヒープダンプ６−２より、最初の行であるレコードを取得する（ステップＳ１０−３）。レコードはオブジェクトＩＤがＧＣＲ０であるレコードである。グループ化モジュール６−４は、このレコードの種別を判別すると（ステップＳ１０−４）、種別はＧＣルートであるため、「その他」の分岐を辿り、再度ループを繰り返す（ステップＳ１０−８）。次のオブジェクトＩＤがＧＣＲ１であるレコードも同様である。

グループ化モジュール６−４は、ヒープダンプ６−２より、次の行であるレコードを取得する（ステップＳ１０−３）。取得レコードは「オブジェクトＩＤ」がＣＬＸであるレコードである。

グループ化モジュール６−４は、このレコードの種別を判別すると（ステップＳ１０−４）、種別はクラスローダであるため、グループ化テーブル６−７に登録する情報として、「クラスローダのオブジェクトＩＤ」には、このレコードの「オブジェクトＩＤ」であるＣＬＸを追加登録すると共に、「配下のオブジェクトＩＤ」にもこのレコードの「オブジェクトＩＤ」であるＣＬＸを追加登録する(ステップＳ１０−７)。

この時点でのグループ化テーブル６−７を図１４に示す。図１４は、本実施形態に係るグループ化モジュール動作の際に、種別がクラスローダの場合のグループ化テーブル図である。

グループ化モジュール６−４は、繰り返し処理（ステップＳ１０−２）を実施することにより、ヒープダンプ６−２より次のレコードを取得する(ステップＳ１０−３)。取得レコードは「オブジェクトＩＤ」がＣＸ０であるレコードである。

グループ化モジュール６−４は、このレコードの種別を判別すると（ステップＳ１０−４）、種別はクラスであるため、グループ化テーブル６−７に登録する情報として、「クラスローダのオブジェクトＩＤ」には、このレコードの「クラスローダのＩＤ」であるＣＬＸを追加登録すると共に、「配下のオブジェクトＩＤ」には、レコードのオブジェクトＩＤであるＣＸ０を追加登録する（ステップＳ１０−６）。

この時点でのグループ化テーブル６−７を図１５に示す。図１５は、本実施形態に係るグループ化モジュール動作の際に、種別がクラスの場合のグループ化テーブル図である。

グループ化モジュール６−４は、続く３つのレコードも種別がクラスのレコードであるため、同様の処理を実施する。この時点でのグループ化テーブル６−７を図１６に示す。

図１６は、本実施形態に係るグループ化モジュール動作の際、種別がその他のクラスの場合のグループ化テーブル図である。

グループ化モジュール６−４は、引き続き、繰り返し処理（ステップＳ１０−２）を実施することにより、ヒープダンプ６−２より、次のレコードを取得する（ステップＳ１０−３）。取得レコードは「オブジェクトＩＤ」がＯＸ０であるレコードである。

グループ化モジュール６−４は、このレコードの種別を判別すると（ステップＳ１０−４）、種別はオブジェクトであるため、クラスローダを特定するためにこのレコードの「クラスのオブジェクトＩＤ」の値であるＣＸ０が指し示すレコードを参照する（ステップＳ１０−５）。そのＣＸ０が指し示すレコードの「クラスローダのオブジェクトＩＤ」はＣＬＸである。

そのため、グループ化テーブル６−７に登録する情報として、「クラスローダのオブジェクトＩＤ」には、上記手順で取得したＣＬＸを追加登録すると共に、「配下のオブジェクトＩＤ」には、レコードのオブジェクトＩＤであるＯＸ０を追加登録する（ステップＳ１０−６）。

この時点でのグループ化テーブル６−７を図１７に示す。図１７は、本実施形態に係るグループ化モジュール動作の際に、種別がオブジェクトの場合のグループ化テーブル図である。

続く３つのレコードも種別がオブジェクトのレコードであるため、同様の処理を実施する。この時点でのグループ化テーブル６−７を図１８に示す。図１８は本実施形態に係るグループ化モジュール動作の際に、種別がその他のオブジェクトの場合のグループ化テーブル図である。

以降のレコードにも同様の繰り返し処理を実施すると、最終的に図９に示すグループ化テーブルとなり、処理を終了する（ステップＳ１０−９）。

次に、図７に示す、本実施形態に係るデータ参照元特定システムの機能を概念的に示すブロック図における参照探索モジュール６−５の動作について、図１２を用いて詳細に説明する。図１２は、本実施形態に係る参照探索モジュールの動作を示すフローチャートである。これを用いて破棄済みクラスローダを基準にしてグループ化したクラスやオブジェクトを含むオブジェクト群をそのグループの外部から参照するその参照元を探索する。

参照探索モジュール６−５の動作は、開始より始まる（ステップＳ１１−１）。参照探索
モジュール６−５は、入力であるヒープダンプ６−２の未処理の行がなくなるまで処理を繰り返す（ステップＳ１１−２、ステップＳ１１−１２）。

参照探索モジュール６−５は、ヒープダンプ６−２のレコードに対する繰り返し処理を開始すると、まずヒープダンプ６−２より未処理のヒープダンプのレコードを取得する（ステップＳ１１−３）。

ここで、取得したヒープダンプのレコードを説明の便宜上、ＲＥＣＯＲＤと表現する。

続いて、参照探索モジュール６−５は、入力であるグループ化テーブル６−７の未処理のレコードがなくなるまで処理を繰り返す（ステップＳ１１−４、ステップＳ１１−１１)。

参照探索モジュール６−５は、グループ化テーブル６−７のレコードに対する繰り返し処理を開始すると、まずグループ化テーブル６−７より未処理のレコードを取得する（ステップＳ１１−５）。ここで、取得したグループ化テーブル６−７のレコードを説明の便宜上、ＧＲＯＵＰＥＤ_ＲＥＣＯＲＤと表現する。

そして、参照探索モジュール６−５は、次の条件式Ａに示す、３つの条件を全て満たすか否かを確認する（ステップＳ１１＿６）。すなわち、
条件１は、ＧＲＯＵＰＥＤ_ＲＥＣＯＲＤの「クラスローダのオブジェクトＩＤ」で示されるクラスローダが破棄済みである。

条件２は、ＲＥＣＯＲＤの「オブジェクトＩＤ」がＧＲＯＵＰＥＤ_ＲＥＣＯＲＤの「配下のオブジェクトＩＤ」のどれとも一致しない。そして、
条件３は、ＲＥＣＯＲＤの「参照先のオブジェクトＩＤ」とＧＲＯＵＰＥＤ_ＲＥＣＯＲＤの「配下のオブジェクトＩＤ」とが一致する。
である。

ここで「参照先のオブジェクトＩＤ」は、図８に示すヒープダンプテーブルのＲＥＣＯＲＤであり、「クラスローダのオブジェクトＩＤ」と「配下のオブジェクトＩＤ」は、図９に示すグループ化テーブルのＧＲＯＵＰＥＤ_ＲＥＣＯＲＤである。

そして参照探索モジュール６−５は、条件式Ａに示す上記条件が全て満たされた場合（ＹＥＳ：ステップＳ１１＿６）、グループ外からの参照テーブル６−８に、以下の通りの行を追加登録する（ステップＳ１１＿７）。すなわち、
（１）「クラスローダのオブジェクトＩＤ」の列の値は、ＧＲＯＵＰＥＤ_ＲＥＣＯＲＤの「クラスローダのオブジェクトＩＤ 」の値とする。
（２）「参照元のオブジェクトＩＤ」の列の値は、ＲＥＣＯＲＤの「オブジェクトＩＤ」の値とする。

ただし、ＲＥＣＯＲＤの「参照先のオブジェクトＩＤ」に複数の参照先が含まれている場合には、上記の（２）については、上述した条件３を満たす参照のみを書きこむ。
（３）「参照先のオブジェクトＩＤ」の列の値は、ＲＥＣＯＲＤの「参照先のオブジェクトＩＤ」の値とする。

参照探索モジュール６−５は、条件式Ａに示す上記条件の何れかが満たされない場合（ＮＯ：ステップＳ１１＿６）、繰り返し処理（ステップ１１−１１）を実施する。

そして、図７に示す、データ参照元特定システムの機能を概念的に示すブロック図における参照探索モジュール６−５は、ステップＳ１１−２とステップＳ１１−４の繰り返しを終了すると処理を終了し、グループ外からの参照テーブル６−８を出力する（ステップＳ１１＿１２、ステップＳ１１−１３）。

なお、グループ外からの参照テーブルの一例は図１０であり、図６に示す、破棄済みクラスローダへのグループ外から参照する例を説明する図における５−３、５−４、５−６、５−１０、５−１２、５−１４の参照を示している。

そして、図７に示すブロック図における参照探索モジュール６−５は、グループ外からの参照テーブル６−８を入力として、出力装置を呼び出す。

上述したように、本実施形態に係るデータ参照元特定システムでは、破棄済みクラスローダ探索モジュール６−３と、グループ化モジュール６−４と、参照探索モジュール６−５とを用いることにより、グループ外からの参照テーブル６−８を得ることが出来る。

それによって、参照先のオブジェクトのサイズや、そのオブジェクトの個数に依らずに、クラスローダを基準としてグループ化したオブジェクトのうちの破棄済みクラスローダのグループをそのグループ外から参照するその参照元のオブジェクトを特定することができる。

すなわち本実施形態によれば、参照元のオブジェクトを直接的に特定することができるので、参照先のオブジェクトのサイズが小さいか、もしくは個数が少ない場合でもメモリリークの直接の原因となる参照元のオブジェクトを特定することができるという効果を奏することができる。

また、本実施形態によれば、参照先のオブジェクトのサイズが小さいか、もしくは個数が少ない場合でもメモリリークの直接の原因となる参照元のオブジェクトを効率的に特定することができるので、例えば開発や評価途上での長時間動作試験などを実施しなくてもメモリリークを容易に検出することができるという効果を奏することができる。

さらに、本実施形態によれば、ＡＰにおける複数の時点でのヒープダンプを比較してクラスやオブジェクトの増減を観察する必要がなく、ある時点での単一のヒープダンプを用いるだけでメモリリークの参照元のオブジェクトを特定することができるという効果を奏することができる。

つまり、本実施形態によれば、参照先のオブジェクトのサイズが小さいかもしくはオブジェクトの個数が少ない場合でもメモリリークの直接の原因となる参照元のオブジェクトを特定することができるという効果を奏することができる。

以上、本発明の第２の実施形態として、上述した構成および動作を例に説明したが、本発明は、必ずしも係る構成や動作には限定されない。

＜第３の実施形態＞
次に、第１および第２の実施形態を基本とする、応用例である第３の実施形態について図６および図７を参照して説明する。

第３の実施形態は、図７に示す第２の実施形態に係るデータ参照元特定システムの機能を概念的に示すブロック図における破棄済みクラスローダ探索モジュール６−３に対して、破棄済みとマーキングしたクラスローダにのみ依存（すなわち、参照）するクラスローダに対して、そのクラスローダが明示的に破棄済みとマーキングされていなくても破棄済みと見なすように処理を変更した点が、第２の実施形態と異なる。そのため説明の便宜上、このクラスローダを見なし破棄済みクラスローダと呼ぶこととする。

そして、以下の説明において、第２の実施形態で説明した図６乃至図１８と同じ動作をする箇所は説明を省略すると共に、本実施形態における上述した相違点を中心に、構成と動作および効果を説明する。

第２の実施形態に係るデータ参照元特定システムでは、参照探索モジュール６−５は、見なし破棄済みクラスローダのグループへの参照がリーク（すなわち、明示的に破棄済みとはマーキングしてはいないが引き続き参照される）している場合、そのリークの原因となる外部からの参照は、見なし破棄済みクラスローダのグループから破棄済みクラスローダのグループへの参照として現れることとなる。

例えば、図６に示す、破棄済みクラスローダＣＬＸへのグループ外からの参照を示す図において、ＣＬＶ（不図示）という、見なし破棄済みクラスローダのグループのオブジェクトＯＶ（不図示）から、ＯＸ４への参照があった場合を考える。

参照探索モジュール６−５は、ＣＬＶは見なし破棄済みクラスローダであるので、そのＣＬＶのクラスローダを基準にしてグループ化したオブジェクト群のうちのオブジェクトＯＶを参照する別のグループのクラスローダであるＣＬＷ（不図示）のオブジェクト群があったとした場合、そのオブジェクト群は、実質的にＯＸ４を参照しているので、リークの元であることが判る。

上述したように、本実施形態に係るデータ参照元特定システムにおいては、リークの原因となる外部からの参照は、見なし破棄済みクラスローダのグループへの参照として現れるため、メモリリークの原因となる参照元の特定をより正確に行うことが可能となる。

すなわち本実施形態によれば、参照元のオブジェクトを直接的に特定することができるので、参照先のオブジェクトのサイズが小さいか、もしくは個数が少ない場合でもメモリリークの原因となる参照元のオブジェクトを特定することができるという効果を奏することができる。

また、本実施形態によれば、参照先のオブジェクトのサイズが小さいか、もしくは個数が少ない場合でもメモリリークの原因となる参照元のオブジェクトを効率的に特定することができるので、例えば開発や評価途上での長時間動作試験などを実施しなくてもメモリリークを容易に検出することができるという効果を奏することができる。

さらに、本実施形態によれば、ＡＰにおける複数の時点でのヒープダンプを比較してクラスやオブジェクトの増減を観察する必要がなく、ある時点での単一のヒープダンプを用いるだけでメモリリークの参照元のオブジェクトを特定することができるという効果を奏することができる。

加えて、破棄済みクラスローダにのみ依存するクラスローダが破棄済みと明示していなくても破棄済みと見なすことにより、メモリリークの原因となるグループ外から参照する参照元を正確に特定することが可能になるという追加の効果を奏することができる。

つまり、本実施形態によれば、参照先のオブジェクトのサイズが小さいかもしくはオブジェクトの個数が少ない場合でもメモリリークの原因となる参照元のオブジェクトを特定することができるという効果を奏することができる。

以上、本発明の第３の実施形態として、上述した構成および動作を例に説明したが、本発明は、必ずしも係る構成や動作には限定されない。

＜第４の実施形態＞
次に、第２および第３の実施形態を基本とする、第４の実施形態について図１９を用いて説明する。図１９は、第４の実施形態に係るデータの参照元を特定するコンピュータ・プログラムを説明する図である。

本実施形態は、情報処理装置１００において、図７に示す第２の実施形態に係るデータ参照元特定システムの機能を概念的に示すブロック図における各機能を、情報処理装置１００が有するＣｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ（以下、「ＣＰＵ」と略称する）１０１と、そのＣＰＵ１０１において動作するソフトウェアであるＯｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ（以下、「ＯＳ」と略称する）ならびにコンピュータ・プログラムであるアプリケーションソフト（以下、「アプリ」と略称する）とが協働することにより制御する。

そのため、以下の説明において、第２および第３の実施形態で説明した、図６乃至図１８に示す各ブロック図と、各フローチャート図および、各テーブルにおいて同じ構成や、同じ動作をする箇所は、説明を省略すると共に、本実施形態における上述した相違点を中心に、構成と動作および効果を説明する。

図１９に示す情報処理装置１００は、ＣＰＵ１０１と、ＣＰＵ１０１において動作するＯＳならびにアプリと、メモリ１０２と、読書き可能な不揮発性記憶媒体であるストレージ１０８と、コンピュータ・プログラムや各種のテーブルなどのデータやファイルを記録する記録媒体１０９と、ＫＢならびにマウスなどの入力デバイス１１１、モニタに表示をする出力デバイス１１０とからなる。

また、本情報処理装置１００の図示していない外部装置と通信するための通信インタフェース１１２および、外部装置との間でデータ転送を行うための高速データバス１１３とを有している。ここで、通信インタフェース１１２は、例えば有線や無線などの企業のイントラネットや、一般公共のインターネットなどの今では一般的な通信インタフェースを用いることができる。また、高速データバス１１３は、外部装置との間でデータ通信が可能なバスであればよい。

なお、図１９に記載している例えば、チップセットや入出力コントローラは、ＣＰＵ１０１やメモリ１０２と共に情報処理装置１００を構成するデバイスであり、ＣＰＵ１０１と協働するＯＳやアプリによってストレージ１０８と、記憶媒体１０９と、入力デバイス１１１と、出力デバイス１１０と、通信インタフェース１１２および高速データバス１１３などの周辺機能デバイスを制御するための集積回路である。

また、メモリ１０２には、アプリの一部である本来の処理を行うプログラム１０５と、例えばＪａｖａ＿ＶＭが動作する際に生成する情報を格納するヒープ領域１０３（すなわち、図１に示す、参照情報群３や、図２に示す参照情報群２４に対応）と、参照元特定プログラム１０４（すなわち、図７に示す、第２の実施形態に係るデータ参照元特定システムの機能を概念的に示すブロック図の各処理に対応）と、グループ化テーブル１０６（すなわち、図７に示すグループ化テーブル６−７）と、グループ外からの参照テーブル１０７（すなわち、図７に示すグループ外からの参照テーブル６−８に対応）とを有している。

ここで、プログラム１０５は、本情報処理装置１００が、本来処理するプログラムであり、参照元特定プログラム１０４は、本実施形態で説明する本来処理するプログラム１０５におけるメモリリークの直接の原因となる参照元を特定するコンピュータ・プログラムである。

そして本情報処理装置１００を、通信インタフェース１１２もしくは、高速データバス１１３を用いて図示していない外部装置から自動もしくは、入力デバイス１１１を用いて手動によって起動すると、ストレージ１０８からメモリ１０２にアプリの一部であるプログラム１０５および、参照元特定プログラム１０４とが読み込まれる。

なお、初期には、アプリおよびアプリの一部であるプログラム１０５や参照元特定プログラム１０４は、自動もしくは手動によって記憶媒体１０９か、通信インタフェース１１２もしくは高速データバス１１３を経て本情報処理装置１００のストレージ１０８に格納することが可能である。

そして、メモリ１０２における、参照元特定プログラム１０４は、破棄済みクラスローダ特定部１１６と、グループ化部１１７と、参照元特定部１１８と、入出力処理部１１９とを有する。また、入出力処理部１１９は例えば、外部装置やデータやファイルを操作する高速データバス１１３や記録媒体１０９のほか、入力デバイス１１１や出力デバイス１１０なども制御する。

つまり、本情報処理装置１００によるデータ参照元特定システムを実現するために、上述した図７乃至図１８に示す各機能ブロックの動作説明図と、各テーブルと、各モジュール機能のフローチャートの動作とを、実現可能なアプリつまりコンピュータ・プログラムとして供給する。

そして、そのコンピュータ・プログラムを本情報処理装置１００によるデータ参照元の特定方法として用意した上記ＣＰＵ１０１および協働するＯＳならびにアプリの一部であるプログラム１０５と参照元特定プログラム１０４とをメモリ１０２に読み出して実行することによって達成する。

なお、本実施形態における破棄済みクラスローダ特定部１１６と、グループ化部１１７と、参照元特定部１１８とは、第２および第３の実施形態における破棄済みクラスローダ探索モジュール６−３と、グループ化モジュール６−４と、参照探索モジュール６−５にそれぞれ対応する。

そのため、具体的な動作については、第２の実施形態および、第３の実施形態において図６乃至図１８を用いて説明しているので本実施形態での説明は省略する。

上述したように、例えばサーバや、ワークステーション（Ｗｏｒｋ Ｓｔａｔｉｏｎ；以下「ＷＳ」と略称する）などの汎用の情報処理装置１００を用いて、メモリ１０２に参照元特定プログラム１０４を読込むと共に、本来実行するプログラムと共にその処理を実行するにより、本来実行するプログラムにおけるメモリリークの直接の原因となるデータの参照元を特定することができる。

また、本情報処理装置１００は、情報処理装置と記載したが、通信インタフェース１１２や、高速データバス１１３を介して、例えば企業のイントラネットやインターネットに接続する外部装置である他の情報処理装置と接続することにより、それらの情報処理装置に対してアプリケーションサービスを提供することが可能な情報処理システムとも見なすことができる。

なお、本実施形態における情報処理装置１００は、説明の都合上、図２に示すようなＪａｖａ＿ＶＭ環境におけるＪａｖａプログラムによるＡＰサーバの動作を基に説明したが、図２に示すように、ＯＳの種類には限定されない。

また、本実施形態における情報処理装置１００は、Ｊａｖａ＿ＶＭ環境に限定せずに、何れかのＯＳと協働する何れかのＪａｖａ＿ＶＭ環境のようなミドルウェアを用いて実現してもかまわない。

また、本実施形態で説明したメモリリークの直接の原因となる参照元を特定するコンピュータ・プログラムである参照元特定プログラム１０４は、上述したようなＪａｖａ＿ＶＭ環境や同様のミドルウェアが有するプログラムもしくは、本来動作するプログラム１０５に含まれるように構成してもよい。

すなわち本実施形態によれば、参照元のオブジェクトを直接的に特定することができるので、参照先のオブジェクトのサイズが小さいか、もしくは個数が少ない場合でもメモリリークの直接の原因となる参照元のオブジェクトを特定することができるという効果を奏することができる。

また、本実施形態によれば、参照先のオブジェクトのサイズが小さいか、もしくは個数が少ない場合でもメモリリークの直接の原因となる参照元のオブジェクトを効率的に特定することができるので、例えば開発や評価途上での長時間動作試験などを実施しなくてもメモリリークを容易に検出することができるという効果を奏することができる。

さらに、本実施形態によれば、ＡＰにおける複数の時点でのヒープダンプを比較してクラスやオブジェクトの増減を観察する必要がなく、ある時点での単一のヒープダンプを用いるだけでメモリリークの参照元のオブジェクトを特定することができるという効果を奏することができる。

加えて、例えばサーバやＷＳなどの汎用の情報処理装置を用いて、そこに上述した参照元を特定するコンピュータ・プログラムを読込むと共にその処理を実行するにより、メモリリークの直接の原因となる参照元を容易に特定することができるので、信頼性の高いＡＰサービスを提供することができるという効果を奏することができる。

つまり、本実施形態によれば、参照先のオブジェクトのサイズが小さいかもしくはオブジェクトの個数が少ない場合でもメモリリークの直接の原因となる参照元のオブジェクトを特定することができるという効果を奏することができる。

以上、本発明の第４の実施形態として、上述した構成および動作を例に説明したが、本発明は、必ずしも係る構成や動作には限定されない。

なお、上述した実施形態及びその変形例の一部又は全部は、以下の付記のようにも記載されうる。しかしながら、上述した実施形態及びその変形例により例示的に説明した本発明は、以下には限らない。即ち、
（付記１）
アプリケーションの配備に伴って元プログラム読み込み機能を生成すると共に該元プログラム読み込み機能を用いて前記アプリケーションを構成するオブジェクト群であるプログラムおよびその元プログラムとが記憶領域に生成して実行される情報処理装置において、アプリケーションの実行に伴って更新される、記憶領域における前記オブジェクト群の参照関係を表す参照情報群に含まれるデータに基づいて、前記オブジェクト群を前記元プログラム読み込み機能を基準にしてグループ化するグループ化部と、
前記アプリケーションの終了に伴って破棄済みとマーキングされた破棄済みの元プログラム読み込み機能を基準にして、前記グループ化された情報に基づいてグループ化したグループに対して、該グループの外部から参照する参照元を特定する参照元特定部とを有すること特徴とするデータ参照元特定システム。
（付記２）
前記グループ化部は、前記参照情報群の更新データに基づいて、前記プログラムおよび前記元プログラムとを、前記元プログラムを読み込んだ前記元プログラム読み込み機能を基準にしてグループ分けすると共に、グループ分けの状態を表すグループ化情報を保持することを特徴とする付記１に記載のデータ参照元特定システム。
（付記３）
前記参照元特定部は、前記参照情報群の更新データおよび前記グループ化部における前記元プログラム読み込み機能を基準にしてグループ分けした際のグループ化情報に基づいて、前記グループ化された破棄済みの元プログラム読み込み機能のグループに対して該グループの外部から参照する参照元を特定することを特徴とする付記１もしくは付記２に記載のデータ参照元特定システム。
（付記４）
前記グループ化部は、前記破棄済みの元プログラム読み込み機能である破棄済みのクラスローダを、前記参照情報群を参照することにより特定する破棄済みクラスローダ探索モジュールと、
前記参照情報群であるヒープダンプテーブルと、前記特定された破棄済みのクラスローダの一覧とを基にグループ分けすると共に、グループ化情報であるグループ化テーブルを生成するグループ化モジュールとを含むことを特徴とする付記１もしくは付記２に記載のデータ参照元特定システム。
（付記５）
前記グループ化モジュールは、前記ヒープダンプテーブルおよび前記破棄済みクラスローダの一覧に基づいて、ヒープダンプテーブルに含まれるレコードの種別が前記オブジェクトの場合には、該オブジェクトが属する前記クラスのオブジェクトＩＤを基にクラスのレコードを特定すると共に、特定したクラスローダのオブジェクトＩＤを基にグループ化テーブルにレコードを追加登録し、前記種別が前記クラスの場合には、その特定したクラスローダのオブジェクトＩＤを基にグループ化テーブルにレコードを追加登録し、前記種別が前記クラスローダの場合には、前記オブジェクトＩＤを基にグループ化テーブルにレコードの情報を追加登録し、前記種別がメモリ資源を解放するメモリ資源解放機能であるガベージコレクションを含むその他の場合には、何も処理をしないグループ分けを行うと共にグループ化テーブルを生成することを特徴とする付記４に記載のデータ参照元特定システム。
（付記６）
前記参照探索モジュールは、前記ヒープダンプテーブルおよび前記グループ化テーブルに基づいて、該グループ化テーブルのレコードに対して、グループドレコードの「クラスローダのオブジェクトＩＤ」で示される前記クラスローダが破棄済みでかつ、レコードの「オブジェクトＩＤ」が前記グループドレコードの「配下のオブジェクトＩＤ」の何れにも一致しないでかつ、前記レコードの「参照先のオブジェクトＩＤ」と前記グループドレコードの「配下のオブジェクトＩＤ」が一致する条件を満たした場合に、グループ外からの参照テーブルに対して、「クラスローダのオブジェクトＩＤ」の列には、前記グループドレコードの「クラスローダのオブジェクトＩＤ」の値を、「参照元のオブジェクトＩＤ」の列には、前記レコードの「オブジェクトＩＤ」の値を、そして「参照先のオブジェクトＩＤ」の列には、前記レコードの「参照先のオブジェクトＩＤ」の値をそれぞれ追加登録することにより、グループ外からの参照テーブルを生成すると共に、グループ外から参照する参照元を探索することを特徴とする付記４に記載のデータ参照元特定システム。
（付記７）
前記データ参照元特定システムは、前記破棄済みとマーキングされたクラスローダのオブジェクト群が占有するメモリ資源を解放するガベージコレクションの参照開始点からの参照をも参照元としてグループ分けすることにより、その参照元を特定することを特徴とする付記５に記載のデータ参照元特定システム。
（付記８）
前記グループ化モジュールは、明示的に破棄済みとマーキングされていなくとも前記破棄済みのクラスローダにのみ依存するクラスローダを前記破棄済みのクラスローダと見なしてグループ分けするとともに、前記グループ化テーブルを生成することを特徴とする付記１、付記２、付記４、もしくは付記５の何れかに記載のデータ参照元特定システム。
（付記９）
前記ヒープダンプテーブルに含まれる情報には、ガベージコレクションの参照開始点からの参照および暗黙の参照とを含むことを特徴とする付記４乃至付記８に記載のデータ参照元特定システム。
（付記１０）
アプリケーションの配備に伴って元プログラム読み込み機能を生成すると共に該元プログラム読み込み機能を用いて前記アプリケーションを構成するオブジェクト群であるプログラムおよびその元プログラムとが記憶領域に生成して実行される情報処理装置において、
アプリケーションの実行に伴って更新される、記憶領域におけるオブジェクト群の参照関係を表す参照情報群に含まれるデータに基づいて、前記オブジェクト群を前記元プログラム読み込み機能を基準にしてグループ化し、
前記アプリケーションの終了に伴って破棄済みとマーキングされた破棄済みの元プログラム読み込み機能を基準にして、前記グループ化された情報に基づいてグループ化したグループに対して、該グループの外部から参照する参照元を特定する
ことを特徴とするデータ参照元特定方法。
（付記１１）
アプリケーションの配備に伴って元プログラム読み込み機能を生成すると共に該元プログラム読み込み機能を用いて前記アプリケーションを構成するオブジェクト群であるプログラムおよびその元プログラムとが記憶領域に生成して実行される情報処理装置を制御するコンピュータ・プログラムであって、そのコンピュータ・プログラムにより、
アプリケーションの実行に伴って更新される、記憶領域における前記オブジェクト群の参照関係を表す参照情報群に含まれるデータに基づいて、前記オブジェクト群を前記元プログラム読み込み機能を基準にしてグループ化するグループ化機能と、
前記アプリケーションの終了に伴って破棄済みとマーキングされた破棄済みの元プログラム読み込み機能を基準にして前記グループ化された情報に基づいてグループ化したグループに対して、該グループの外部から参照する参照元を特定する機能とを、
コンピュータに実現させることを特徴とするコンピュータ・プログラム。

本発明は、上述した各実施形態には限定されず、メモリの消費が増加するメモリリークの直接の原因となる参照元のデータを特定する情報処理システム等におけるアプリケーションの開発や評価および運用管理などに適用可能である。

１ グループ化部
２ 参照元特定部
３ 参照情報群
１０ データ参照元特定システム
１００ 情報処理装置
１０１ ＣＰＵ
１０２ メモリ
１０３ ヒープ領域
１０４ 参照元特定プログラム
１０５ プログラム
１０６ グループ化テーブル
１０７ グループ外からの参照テーブル
１０８ ストレージ
１０９ 記録媒体
１１０ 出力デバイス
１１１ 入力デバイス
１１２ 通信インタフェース
１１３ 高速データバス
１１６ 破棄済みクラスローダ特定部
１１７ グループ化部
１１８ 参照元特定部
１１９ 入出力処理部

Claims (10)

1. アプリケーションの配備に伴って元プログラム読み込み機能を生成すると共に該元プログラム読み込み機能を用いて前記アプリケーションを構成するオブジェクト群であるプログラムおよびその元プログラムとが記憶領域に生成して実行される情報処理装置において、アプリケーションの実行に伴って更新される、記憶領域における前記オブジェクト群の参照関係を表す参照情報群に含まれるデータに基づいて、前記オブジェクト群を前記元プログラム読み込み機能を基準にしてグループ化するグループ化部と、
   前記アプリケーションの終了に伴って破棄済みとマーキングされた破棄済みの元プログラム読み込み機能を基準にして、前記グループ化された情報に基づいてグループ化したグループに対して、該グループの外部から参照する参照元を特定する参照元特定部とを有すること特徴とするデータ参照元特定システム。
2. 前記グループ化部は、前記参照情報群の更新データに基づいて、前記プログラムおよび前記元プログラムとを、前記元プログラムを読み込んだ前記元プログラム読み込み機能を基準にしてグループ分けすると共に、グループ分けの状態を表すグループ化情報を保持することを特徴とする請求項１に記載のデータ参照元特定システム。
3. 前記参照元特定部は、前記参照情報群の更新データおよび前記グループ化部における前記元プログラム読み込み機能を基準にしてグループ分けした際のグループ化情報に基づいて、前記グループ化された破棄済みの元プログラム読み込み機能のグループに対して該グループの外部から参照する参照元を特定することを特徴とする請求項１もしくは請求項２に記載のデータ参照元特定システム。
4. 前記グループ化部は、前記破棄済みの元プログラム読み込み機能である破棄済みのクラスローダを、前記参照情報群を参照することにより特定する破棄済みクラスローダ探索モジュールと、
   前記参照情報群であるヒープダンプテーブルと、前記特定された破棄済みのクラスローダの一覧とを基にグループ分けすると共に、グループ化情報であるグループ化テーブルを生成するグループ化モジュールとを含むことを特徴とする請求項１もしくは請求項２に記載のデータ参照元特定システム。
5. 前記グループ化モジュールは、前記ヒープダンプテーブルおよび前記破棄済みクラスローダの一覧に基づいて、ヒープダンプテーブルに含まれるレコードの種別が前記オブジェクトの場合には、該オブジェクトが属する前記クラスのオブジェクトＩＤを基にクラスのレコードを特定すると共に、特定したクラスローダのオブジェクトＩＤを基にグループ化テーブルにレコードを追加登録し、前記種別が前記クラスの場合には、その特定したクラスローダのオブジェクトＩＤを基にグループ化テーブルにレコードを追加登録し、前記種別が前記クラスローダの場合には、前記オブジェクトＩＤを基にグループ化テーブルにレコードの情報を追加登録し、前記種別がメモリ資源を解放するメモリ資源解放機能であるガベージコレクションを含むその他の場合には、何も処理をしないグループ分けを行うと共にグループ化テーブルを生成することを特徴とする請求項４に記載のデータ参照元特定システム。
6. 前記参照探索モジュールは、前記ヒープダンプテーブルおよび前記グループ化テーブルに基づいて、該グループ化テーブルのレコードに対して、グループドレコードの「クラスローダのオブジェクトＩＤ」で示される前記クラスローダが破棄済みでかつ、レコードの「オブジェクトＩＤ」が前記グループドレコードの「配下のオブジェクトＩＤ」の何れにも一致しないでかつ、前記レコードの「参照先のオブジェクトＩＤ」と前記グループドレコードの「配下のオブジェクトＩＤ」が一致する条件を満たした場合に、グループ外からの参照テーブルに対して、「クラスローダのオブジェクトＩＤ」の列には、前記グループドレコードの「クラスローダのオブジェクトＩＤ」の値を、「参照元のオブジェクトＩＤ」の列には、前記レコードの「オブジェクトＩＤ」の値を、そして「参照先のオブジェクトＩＤ」の列には、前記レコードの「参照先のオブジェクトＩＤ」の値をそれぞれ追加登録することにより、グループ外からの参照テーブルを生成すると共に、グループ外から参照する参照元を探索することを特徴とする請求項４に記載のデータ参照元特定システム。
7. 前記データ参照元特定システムは、前記破棄済みとマーキングされたクラスローダのオブジェクト群が占有するメモリ資源を解放するガベージコレクションの参照開始点からの参照をも参照元としてグループ分けすることにより、その参照元を特定することを特徴とする請求項５に記載のデータ参照元特定システム。
8. 前記グループ化モジュールは、明示的に破棄済みとマーキングされていなくとも前記破棄済みのクラスローダにのみ依存するクラスローダを前記破棄済みのクラスローダと見なしてグループ分けするとともに、前記グループ化テーブルを生成することを特徴とする請求項１、請求項２、請求項４、もしくは請求項５の何れかに記載のデータ参照元特定システム。
9. アプリケーションの配備に伴って元プログラム読み込み機能を生成すると共に該元プログラム読み込み機能を用いて前記アプリケーションを構成するオブジェクト群であるプログラムおよびその元プログラムとが記憶領域に生成して実行される情報処理装置において、
   アプリケーションの実行に伴って更新される、記憶領域におけるオブジェクト群の参照関係を表す参照情報群に含まれるデータに基づいて、前記オブジェクト群を前記元プログラム読み込み機能を基準にしてグループ化し、
   前記アプリケーションの終了に伴って破棄済みとマーキングされた破棄済みの元プログラム読み込み機能を基準にして、前記グループ化された情報に基づいてグループ化したグループに対して、該グループの外部から参照する参照元を特定する
   ことを特徴とするデータ参照元特定方法。
10. アプリケーションの配備に伴って元プログラム読み込み機能を生成すると共に該元プログラム読み込み機能を用いて前記アプリケーションを構成するオブジェクト群であるプログラムおよびその元プログラムとが記憶領域に生成して実行される情報処理装置を制御するコンピュータ・プログラムであって、そのコンピュータ・プログラムにより、
    アプリケーションの実行に伴って更新される、記憶領域における前記オブジェクト群の参照関係を表す参照情報群に含まれるデータに基づいて、前記オブジェクト群を前記元プログラム読み込み機能を基準にしてグループ化するグループ化機能と、
    前記アプリケーションの終了に伴って破棄済みとマーキングされた破棄済みの元プログラム読み込み機能を基準にして前記グループ化された情報に基づいてグループ化したグループに対して、該グループの外部から参照する参照元を特定する機能とを、
    コンピュータに実現させることを特徴とするコンピュータ・プログラム。

Images