(57)【特許請求の範囲】
【請求項１】
アプリケーションを生成するアプリケーション生成手段を複数備え、複数のアプリケーションが実行可能で、かつ、該複数のアプリケーションでメモリ領域が共有されるアプリケーション実行装置におけるメモリ領域を管理するメモリ管理装置であって、
前記アプリケーション生成手段のメモリ使用量として、該アプリケーション生成手段が生成したアプリケーションが使用中の前記メモリ領域の量を、前記複数のアプリケーション生成手段ごとにメモリ使用量を管理するメモリサイズ管理表に記録するメモリサイズ記録手段と、
前記メモリサイズ管理表で、前記メモリ使用量が所定のしきい値を超える前記アプリケーション生成手段に、メモリ使用量がしきい値を超えた旨を通知するメモリ監視手段と、
を備え、
前記アプリケーション生成手段は、前記メモリ監視手段からメモリ使用量がしきい値を超えた旨を通知されると、前記生成したアプリケーションを閉塞するか、警告を発する、
メモリ管理装置。
【請求項２】
前記メモリサイズ記録手段は、前記アプリケーションがメモリ領域に割り当てられたとき、及び、前記アプリケーションがメモリ領域から開放されたとき、前記メモリサイズ管理表の該アプリケーションを生成したアプリケーション生成手段のメモリ使用量を更新する、
請求項１に記載のメモリ管理装置。
【請求項３】
前記メモリサイズ記録手段は、前記アプリケーション実行装置にて前記アプリケーションが前記メモリ領域に割り当てられると、前記メモリサイズ管理表における該割り当てられたアプリケーションを生成した前記アプリケーション生成手段のメモリ使用量を、前記メモリ領域に割り当てられたメモリサイズ分だけ加算する、
請求項２に記載のメモリ管理装置。
【請求項４】
前記メモリサイズ記録手段は、前記アプリケーション実行装置にて前記アプリケーションに割り当てられていたメモリ領域が回収されると、前記メモリサイズ管理表における該メモリ領域が回収されたアプリケーションを生成した前記アプリケーション生成手段のメモリ使用量から、前記メモリ領域から回収されたメモリサイズ分だけ減算する、
請求項２又は３に記載のメモリ管理装置。
【請求項５】
前記アプリケーション実行装置がＪａｖａ仮想マシンであり、前記アプリケーション生成手段が、オブジェクト生成元のクラスをロードする該Ｊａｖａ仮想マシンのクラスローダである、
請求項２乃至４の何れか一に記載のメモリ管理装置。
【請求項６】
前記メモリサイズ記録手段は、Java Virtual Machine Tool Interfaceを用いて、前記Ｊａｖａ仮想マシンから、該Ｊａｖａ仮想マシンにて前記オブジェクトに割り当てられたメモリ領域のサイズ、及び、前記オブジェクト破棄時に前記メモリ領域からガベージコレクション処理により回収されたメモリ領域のサイズと、前記オブジェクトの生成元のクラスを識別する情報とを取得し、該取得した情報に基づいて前記メモリサイズ管理表を更新する、
請求項５に記載のメモリ管理装置。
【請求項７】
アプリケーションを生成するアプリケーション生成手段を複数備え、複数のアプリケーションが実行可能で、かつ、該複数のアプリケーションでメモリ領域が共有されるアプリケーション実行装置と、
前記アプリケーション実行装置における前記アプリケーション生成手段のメモリ使用量として、該アプリケーション生成手段が生成したアプリケーションが使用中の前記メモリ領域の量を、前記複数のアプリケーション生成手段ごとにメモリ使用量を管理するメモリサイズ管理表に記録するメモリサイズ記録手段と、
前記メモリサイズ管理表で、前記メモリ使用量が所定のしきい値を超える前記アプリケーション実行装置内のアプリケーション生成手段に、メモリ使用量がしきい値を超えた旨を通知するメモリ監視手段と、
を備え、
前記アプリケーション生成手段は、前記メモリ監視手段からメモリ使用量がしきい値を超えた旨を通知されると、前記生成したアプリケーションを閉塞するか、警告を発する、
メモリ管理システム。
【請求項８】
アプリケーションを生成するアプリケーション生成手段を複数備え、複数のアプリケーションが実行可能で、かつ、該複数のアプリケーションでメモリ領域を共有する機能を持つコンピュータにおけるメモリ領域を管理する方法であって、
前記コンピュータが、前記アプリケーション生成手段のメモリ使用量として、該アプリケーション生成手段が生成したアプリケーションが使用中の前記メモリ領域の量を、前記複数のアプリケーション生成手段ごとにメモリ使用量を管理するメモリサイズ管理表に記録するステップと、
前記コンピュータが、前記メモリサイズ管理表で、前記メモリ使用量が所定のしきい値を超える前記アプリケーション生成手段に、メモリ使用量がしきい値を超えた旨を通知するステップと、
前記コンピュータが、前記アプリケーション生成手段にメモリ使用量がしきい値を超えた旨が通知されると、該アプリケーション生成手段が生成したアプリケーションを閉塞するか、警告を発するステップと、
を有するメモリ管理方法。
【請求項９】
前記コンピュータが、前記アプリケーションがメモリ領域に割り当てられたとき、及び、前記アプリケーションがメモリ領域から開放されたとき、前記メモリサイズ管理表の該アプリケーションを生成したアプリケーション生成手段のメモリ使用量を更新するステップをさらに有する、
請求項８に記載のメモリ管理方法。
【請求項１０】
前記更新するステップでは、前記コンピュータが、前記アプリケーションが前記メモリ領域に割り当てられると、前記メモリサイズ管理表における該割り当てられたアプリケーションを生成した前記アプリケーション生成手段のメモリ使用量を、前記メモリ領域に割り当てられたメモリサイズ分だけ加算する、
請求項９に記載のメモリ管理方法。
【請求項１１】
前記更新するステップでは、前記コンピュータが、前記アプリケーションに割り当てられていたメモリ領域が回収されると、前記メモリサイズ管理表における該メモリ領域が回収されたアプリケーションを生成した前記アプリケーション生成手段のメモリ使用量から、前記メモリ領域から回収されたメモリサイズ分だけ減算する、
請求項９又は１０に記載のメモリ管理方法。
【請求項１２】
前記コンピュータは、Ｊａｖａ仮想マシン上で前記アプリケーションを実行し、前記アプリケーション生成手段は、オブジェクト生成元のクラスをロードする該Ｊａｖａ仮想マシンのクラスローダである、
請求項９乃至１１の何れか一に記載のメモリ管理方法。
【請求項１３】
前記更新するステップでは、前記コンピュータが、Java Virtual Machine Tool Interfaceを用いて、前記Ｊａｖａ仮想マシンから、該Ｊａｖａ仮想マシンにて前記オブジェクトに割り当てられたメモリ領域のサイズ、及び、前記オブジェクト破棄時に前記メモリ領域からガベージコレクション処理により回収されたメモリ領域のサイズと、前記オブジェクトの生成元のクラスを識別する情報とを取得し、該取得した情報に基づいて前記メモリサイズ管理表を更新する、
請求項１２に記載のメモリ管理方法。
【請求項１４】
アプリケーションを生成するアプリケーション生成手段を複数備え、複数のアプリケーションが実行可能で、かつ、該複数のアプリケーションでメモリ領域を共有する機能を持つコンピュータに、
前記アプリケーション生成手段のメモリ使用量として、該アプリケーション生成手段が生成したアプリケーションが使用中の前記メモリ領域の量を、前記複数のアプリケーション生成手段ごとにメモリ使用量を管理するメモリサイズ管理表に記録する処理と、
前記メモリサイズ管理表で、前記メモリ使用量が所定のしきい値を超える前記アプリケーション生成手段に、メモリ使用量がしきい値を超えた旨を通知する処理と、
前記アプリケーション生成手段にメモリ使用量がしきい値を超えた旨が通知されると、該アプリケーション生成手段が生成したアプリケーションを閉塞するか、警告を発する処理と、
を実行させるプログラム。
【請求項１５】
前記コンピュータに、前記アプリケーションがメモリ領域に割り当てられたとき、及び、前記アプリケーションがメモリ領域から開放されたとき、前記メモリサイズ管理表の該アプリケーションを生成したアプリケーション生成手段のメモリ使用量を更新する処理をさらに実行させる、
請求項１４に記載のプログラム。
【請求項１６】
前記更新する処理では、前記アプリケーションが前記メモリ領域に割り当てられると、前記メモリサイズ管理表における該割り当てられたアプリケーションを生成した前記アプリケーション生成手段のメモリ使用量を、前記メモリ領域に割り当てられたメモリサイズ分だけ加算する、
請求項１５に記載のプログラム。
【請求項１７】
前記更新する処理では、前記アプリケーションに割り当てられていたメモリ領域が回収されると、前記メモリサイズ管理表における該メモリ領域が回収されたアプリケーションを生成した前記アプリケーション生成手段のメモリ使用量から、前記メモリ領域から回収されたメモリサイズ分だけ減算する、
請求項１５又は１６に記載のプログラム。
【請求項１８】
前記コンピュータは、Ｊａｖａ仮想マシン上で前記アプリケーションを実行し、前記アプリケーション生成手段は、オブジェクト生成元のクラスをロードする該Ｊａｖａ仮想マシンのクラスローダである、
請求項１５乃至１７の何れか一に記載のプログラム。
【請求項１９】
前記更新する処理では、Java Virtual Machine Tool Interfaceを用いて、前記Ｊａｖａ仮想マシンから、該Ｊａｖａ仮想マシンにて前記オブジェクトに割り当てられたメモリ領域のサイズ、及び、前記オブジェクト破棄時に前記メモリ領域からガベージコレクション処理により回収されたメモリ領域のサイズと、前記オブジェクトの生成元のクラスを識別する情報とを取得し、該取得した情報に基づいて前記メモリサイズ管理表を更新する、
請求項１８に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、メモリ管理装置、システム、方法、及び、プログラムに関し、更に詳しくは、複数のアプリケーションが実行可能で、かつ、複数のアプリケーションでメモリ領域が共有されるアプリケーション実行装置におけるメモリ領域を管理するメモリ管理装置、システム、方法、及び、プログラムに関する。
【背景技術】
【０００２】
Ｊａｖａ（登録商標）仮想マシン（Ｊａｖａ  ＶＭ：Java Virtual Machine）と呼ばれるアプリケーション実行装置がある。Ｊａｖａ  ＶＭは、オブジェクトをヒープと呼ばれるメモリ領域に格納する。Ｊａｖａ  ＶＭは、オブジェクトを生成する際に、ヒープのメモリ領域を確保する。オブジェクトが不用になると、ガベージコレクタにより、確保していたヒープのメモリ領域を回収する。これにより、回収したメモリ領域を、別のオブジェクトにて再利用することができる。Ｊａｖａ  ＶＭ及びガベージコレクション処理は、例えば、特許文献１に記載されている。
【０００３】
Java Platform, Enterprise Edition（Ｊａｖａ  ＥＥ）仕様に準拠するアプリケーションサーバでは、複数のアプリケーションを、単一のＪａｖａ  ＶＭ上で動作させることが可能である。このため、Ｊａｖａ  ＥＥのアプリケーションサーバでは、各アプリケーションが独立して動作するように、アプリケーションをロードするクラスローダをアプリケーションごとに分ける実装方法が一般的である。別々のクラスローダでアプリケーションをロードすることで、互いのクラスデータが干渉しないようにすることができる。
【特許文献１】特開２００２−２５９１４６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ところで、Ｊａｖａ  ＶＭにて、複数あるアプリケーションのいずれかに、メモリリークの不具合が発生すると、そのアプリケーションはヒープメモリを大量に確保することになる。Ｊａｖａ  ＥＥ仕様に準拠するアプリケーションサーバでは、ヒープメモリの領域は、Ｊａｖａ  ＶＭ内で１つしかなく、すべてのアプリケーションで同じ領域を使用している。このため、何れかのアプリケーションにメモリリークがあると、ヒープ不足により、他のアプリケーションが動作できなくなるという問題が発生する。
【０００５】
特許文献１は、資源提供時に、要求元アプリケーションの識別子と、提供した資源とを組にしてテーブルに保存し、アプリケーション終了時に、終了したアプリケーションの識別子に対応する資源をテーブルから特定し、特定した資源を開放するものである。特許文献１は、資源回収をカーネルによらずに実行するアプリケーション実行装置を提供することを目的としており、上記問題を解消する技術ではない。つまり、特許文献１では、クラス単位で、複数のアプリケーションが実行可能で、かつ、複数のアプリケーションでオブジェクトをロードするメモリ領域が共有されるアプリケーション実行装置にて、メモリリーク発生時に、他のアプリケーションに与える影響を抑制することはできない。
【０００６】
本発明は、複数のアプリケーションが実行可能で、かつ、複数のアプリケーションでオブジェクトをロードするメモリ領域が共有されるアプリケーション実行装置にて、メモリリーク発生時に、他のアプリケーションに与える影響を抑制できるメモリ管理装置、システム、方法、及び、プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
上記目的を達成するために、本発明のメモリ管理装置は、アプリケーションを生成するアプリケーション生成手段を複数備え、複数のアプリケーションが実行可能で、かつ、該複数のアプリケーションでメモリ領域が共有されるアプリケーション実行装置におけるメモリ領域を管理するメモリ管理装置であって、前記アプリケーション生成手段のメモリ使用量として、該アプリケーション生成手段が生成したアプリケーションが使用中の前記メモリ領域の量を、前記複数のアプリケーション生成手段ごとにメモリ使用量を管理するメモリサイズ管理表に記録するメモリサイズ記録手段と、前記メモリサイズ管理表で、前記メモリ使用量が所定のしきい値を超える前記アプリケーション生成手段に、メモリ使用量がしきい値を超えた旨を通知するメモリ監視手段と、を備え、前記アプリケーション生成手段は、前記メモリ監視手段からメモリ使用量がしきい値を超えた旨を通知されると、前記生成したアプリケーションを閉塞するか、警告を発する、ことを特徴とする。
【０００８】
本発明のメモリ管理システムは、アプリケーションを生成するアプリケーション生成手段を複数備え、複数のアプリケーションが実行可能で、かつ、該複数のアプリケーションでメモリ領域が共有されるアプリケーション実行装置と、前記アプリケーション実行装置における前記アプリケーション生成手段のメモリ使用量として、該アプリケーション生成手段が生成したアプリケーションが使用中の前記メモリ領域の量を、前記複数のアプリケーション生成手段ごとにメモリ使用量を管理するメモリサイズ管理表に記録するメモリサイズ記録手段と、前記メモリサイズ管理表で、前記メモリ使用量が所定のしきい値を超える前記アプリケーション実行装置内のアプリケーション生成手段に、メモリ使用量がしきい値を超えた旨を通知するメモリ監視手段と、を備え、前記アプリケーション生成手段は、前記メモリ監視手段からメモリ使用量がしきい値を超えた旨を通知されると、前記生成したアプリケーションを閉塞するか、警告を発する、ことを特徴とする。
【０００９】
本発明のメモリ管理方法は、アプリケーションを生成するアプリケーション生成手段を複数備え、複数のアプリケーションが実行可能で、かつ、該複数のアプリケーションでメモリ領域を共有する機能を持つコンピュータにおけるメモリ領域を管理する方法であって、前記コンピュータが、前記アプリケーション生成手段のメモリ使用量として、該アプリケーション生成手段が生成したアプリケーションが使用中の前記メモリ領域の量を、前記複数のアプリケーション生成手段ごとにメモリ使用量を管理するメモリサイズ管理表に記録するステップと、前記コンピュータが、前記メモリサイズ管理表で、前記メモリ使用量が所定のしきい値を超える前記アプリケーション生成手段に、メモリ使用量がしきい値を超えた旨を通知するステップと、前記コンピュータが、前記アプリケーション生成手段にメモリ使用量がしきい値を超えた旨が通知されると、該アプリケーション生成手段が生成したアプリケーションを閉塞するか、警告を発するステップと、を有することを特徴とする。
【００１０】
本発明のプログラムは、アプリケーションを生成するアプリケーション生成手段を複数備え、複数のアプリケーションが実行可能で、かつ、該複数のアプリケーションでメモリ領域を共有する機能を持つコンピュータに、前記アプリケーション生成手段のメモリ使用量として、該アプリケーション生成手段が生成したアプリケーションが使用中の前記メモリ領域の量を、前記複数のアプリケーション生成手段ごとにメモリ使用量を管理するメモリサイズ管理表に記録する処理と、前記メモリサイズ管理表で、前記メモリ使用量が所定のしきい値を超える前記アプリケーション生成手段に、メモリ使用量がしきい値を超えた旨を通知する処理と、前記アプリケーション生成手段にメモリ使用量がしきい値を超えた旨が通知されると、該アプリケーション生成手段が生成したアプリケーションを閉塞するか、警告を発する処理と、を実行させることを特徴とする。
【発明の効果】
【００１１】
本発明のメモリ管理装置、システム、方法、及び、プログラムは、複数のアプリケーションが実行可能で、かつ、複数のアプリケーションでオブジェクトをロードするメモリ領域が共有されるアプリケーション実行装置にて、メモリリーク発生時に、他のアプリケーションに与える影響を抑制できる。
【発明を実施するための最良の形態】
【００１２】
以下、図面を参照し、本発明の実施の形態を詳細に説明する。図１は、本発明の一実施形態のメモリ管理システムを示している。メモリ管理システムは、アプリケーション実行装置であるＪａｖａ  ＶＭ１００と、メモリ管理装置を構成するヒープサイズ監視手段（メモリ監視手段）１０４、及び、ヒープサイズ記録手段（メモリサイズ記録手段）１０５とを有する。Ｊａｖａ  ＶＭ１００は、Ｊａｖａプログラムが動作する仮想計算機であり、クラスローダ１０１、ヒープ割り当て手段１０２、ガベージコレクタ１０３、ヒープメモリ１０７を有する。Ｊａｖａ  ＶＭ１００及びメモリ管理装置内の各部の機能は、コンピュータ上で所定プログラムを実行することにより実現可能である。
【００１３】
クラスローダ１０１は、図示しないオブジェクト生成部がオブジェクトを生成する際に、ユーザプログラムなどからクラスをロードする。図１では、クラスローダ１０１を１つだけ図示しているが、Ｊａｖａ  ＶＭは、複数のクラスローダを有する。ヒープ割り当て手段１０２は、生成されたオブジェクトに対して、ヒープメモリ１０７の領域を割り当てる。ガベージコレクタ１０３は、オブジェクト破棄時に、ヒープメモリ１０７にてオブジェクトに割り当てられていた領域を回収する。
【００１４】
メモリ管理装置は、Ｊａｖａ  ＶＭ１００から、ヒープメモリ１０７の割り当て状況を取得する。Ｊａｖａ  ＶＭ１００からの情報収集には、Java Virtual Machine Tool Interface（ＪＶＭＴＩ）を用いる。ヒープ割り当て手段１０２は、領域割り当て時に、クラス識別子とオブジェクトサイズ（ヒープメモリ１０７に確保したメモリサイズ）とを指定して、ＪＶＭＴＩコールバックメソッド１０８を呼び出す。また、ガベージコレクタ１０３は、オブジェクトがガベージコレクトされる際に、クラスの識別子とオブジェクトサイズとを指定してＪＶＭＴＩコールバックメソッド１０８を呼び出す。
【００１５】
ＪＶＭＴＩコールバックメソッド１０８は、ヒープ割り当て手段１０２からの呼び出しを受けると、受け取ったクラス識別子からオブジェクトのクラスローダを特定し、クラスローダの識別子とオブジェクトサイズとをヒープサイズ記録手段１０５に通知して、ヒープサイズ管理表（メモリサイズ管理表）１０６の更新を要求する。また、ＪＶＭＴＩコールバックメソッド１０８は、ガベージコレクタ１０３からの呼び出しを受けると、受け取ったクラス識別子からオブジェクトのクラスローダを特定し、クラスローダの識別子とオブジェクトサイズとをヒープサイズ記録手段１０５に通知して、ヒープサイズ管理表１０６の更新を要求する。
【００１６】
ヒープサイズ管理表１０６は、クラスローダの識別子と、そのクラスローダから生成されたオブジェクトが使用中のヒープメモリ１０７のメモリサイズとを対応付けて記憶している。ヒープサイズ記録手段１０５は、ヒープメモリ１０７で使用中のメモリサイズを、クラスローダ単位で、ヒープサイズ管理表１０６に記録する。ヒープサイズ記録手段１０５は、オブジェクトがヒープ割り当て手段１０２によりヒープメモリ１０７に割り当てられたとき、及び、オブジェクトがヒープメモリ１０７から開放されガベージコレクタ１０３がヒープメモリ１０７を回収したとき、ＪＶＭＴＩコールバックメソッド１０８からクラスローダの識別子とオブジェクトサイズとを受け取り、ヒープサイズ管理表１０６を更新する。
【００１７】
ヒープサイズ記録手段１０５は、ＪＶＭＴＩコールバックメソッド１０８がヒープ割り当て手段１０２から呼び出された場合は、ヒープサイズ管理表１０６の対応するクラスローダのカラムの値に、通知されたオブジェクトサイズの値を加える。また、ヒープサイズ記録手段１０５は、ＪＶＭＴＩコールバックメソッド１０８がガベージコレクタ１０３から呼び出された場合は、ヒープサイズ管理表１０６の対応するクラスローダのカラムの値から、通知されたオブジェクトサイズの値を減算する。
【００１８】
ヒープサイズ記録手段１０５は、ヒープサイズ管理表１０６の更新後、メモリサイズとクラスローダの識別子とを、ヒープサイズ監視手段１０４に渡す。ヒープサイズ監視手段１０４は、メモリサイズとしきい値とを比較する。ヒープサイズ監視手段１０４は、ヒープサイズ管理表１０６にて使用中のメモリサイズがしきい値を超えるクラスローダがあるときは、クラスローダの識別子にて識別されるクラスローダに対して、メモリサイズがしきい値を超えたことを通知する。
【００１９】
図２に、メモリ管理装置の動作手順を示す。ヒープサイズ記録手段１０５は、ＪＶＭＴＩコールバックメソッド１０８からの通知を受けて動作を開始する。ヒープサイズ記録手段１０５は、ＪＶＭＴＩコールバックメソッド１０８から通知されたクラスローダが、ヒープサイズ管理表１０６にキーとして存在するか否かを判断する（ステップＳ１）。存在しない場合は、ヒープサイズ管理表１０６にクラスローダをキーとしたエントリを新たに作成し、データを０に初期化する（ステップＳ２）。
【００２０】
ヒープサイズ記録手段１０５は、ヒープサイズ管理表１０６から、クラスローダをキーとしてデータを取得する（ステップＳ３）。ヒープサイズ記録手段１０５は、オブジェクト生成か、オブジェクト破棄かを判断する（ステップＳ４）。ステップＳ４では、ヒープサイズ記録手段１０５は、ＪＶＭＴＩコールバックメソッド１０８がヒープ割り当て手段１０２から呼び出された場合は、オブジェクト生成と判断し、ＪＶＭＴＩコールバックメソッド１０８がガベージコレクタ１０３から呼び出されたときは、オブジェクト破棄と判断する。
【００２１】
ヒープサイズ記録手段１０５は、ステップＳ４でオブジェクト生成と判断すると、ステップＳ３で取得したデータに、ＪＶＭＴＩコールバックメソッド１０８から通知されたオブジェクトサイズを加える（ステップＳ５）。ヒープサイズ記録手段１０５は、ステップＳ４でオブジェクト破棄と判断したときは、ステップＳ３で取得したデータから、ＪＶＭＴＩコールバックメソッド１０８から通知されたオブジェクトサイズを減算する（ステップＳ６）。ヒープサイズ記録手段１０５は、ステップＳ５で加算したデータ、又は、ステップＳ６で減算したデータを、ヒープサイズ管理表１０６に格納し、ヒープサイズ管理表１０６を更新する（ステップＳ７）。
【００２２】
ヒープサイズ記録手段１０５は、クラスローダの識別子と、ステップＳ７でヒープサイズ管理表１０６に格納したデータとを、ヒープサイズ監視手段１０４に通知する。ヒープサイズ監視手段１０４は、格納されたデータと、所定のしきい値とを比較する（ステップＳ８）。ヒープサイズ監視手段１０４は、格納されたデータが、しきい値以下であると判断すると、処理を終了する。ヒープサイズ監視手段１０４は、格納されたデータが、しきい値を超えると判断すると、受け取ったクラスローダ識別子にて識別されるクラスロードに、しきい値を超えた旨を通知する（ステップＳ９）。通知を受けたクラスローダは、アプリケーションを閉塞させる。或いは、アプリケーションを閉塞させずに、アラームを発生してもよい。
【００２３】
以下、具体例を用いて説明する。図３（ａ）に、クラスローダ１０１が生成するインスタンス（オブジェクト）を示し、（ｂ）及び（ｃ）に、ヒープサイズ管理表１０６のデータ例を示す。ここでは、図３（ａ）に示すように、クラスローダ１０１（クラスローダＡＬｏａｄｅｒ）が、クラスＡのインスタンスＡａとインスタンスＡｂとを生成する場合を考える。インスタンスＡａとインスタンスＡｂのメモリサイズは、６０バイトであるとする。ヒープサイズ監視手段１０４におけるしきい値は１００バイトに設定されているとする。
【００２４】
ヒープ割り当て手段１０２は、インスタンスＡａを生成する際に、ヒープメモリ１０７から６０バイトの領域を確保し、クラスＡのクラス識別子とオブジェクトのメモリサイズ「６０」とを指定して、ＪＶＭＴＩコールバックメソッド１０８を呼び出す。ＪＶＭＴＩコールバックメソッド１０８は、クラスＡのクラス識別子からＡＬｏａｄｅｒを得て、ＡＬｏａｄｅｒとメモリサイズ６０とを指定してヒープサイズ記録手段１０５に対してヒープサイズ管理表１０６の更新を要求する。
【００２５】
ヒープサイズ記録手段１０５は、図２のステップＳ１でクラスローダＡＬｏａｄｅｒをキーとしてヒープサイズ管理表１０６を検索する。エントリが存在しない場合は、ステップＳ２に移行し、ヒープサイズ管理表１０６に、ＡＬｏａｄｅｒをキーとしたエントリを新たに作成し、データを０に初期化する（図３（ｂ）の初期化状態）。ヒープサイズ記録手段１０５は、ステップＳ３でデータ「０」を取得する。
【００２６】
ヒープサイズ記録手段１０５は、ステップＳ４で、ＪＶＭＴＩコールバックメソッド１０８からの通知がオブジェクト生成であるか否かを判断する。ヒープサイズ記録手段１０５は、通知がオブジェクト生成であるので、ステップＳ４からステップＳ５に移行し、ステップＳ３で取得した、ヒープサイズ管理表１０６のＡＬｏａｄｅｒをキーとしたエントリのデータ「０」に、メモリサイズ「６０」を加算し、ステップＳ７で、ヒープサイズ管理表１０６に格納する（図３（ｂ）のインスタンスＡａ生成後）。
【００２７】
ヒープサイズ記録手段１０５は、ステップＳ７でヒープサイズ管理表１０６に格納したデータ「６０」をヒープサイズ監視手段１０４に渡す。ヒープサイズ監視手段１０４は、ステップＳ８で、格納されたデータ「６０」としきい値「１００」とを比較する。この値は、しきい値を超えていないので、図２の処理を終了する。
【００２８】
続いて、ヒープ割り当て手段１０２は、インスタンスＡｂを生成する際に、ヒープメモリ１０７から６０バイトの領域を確保し、クラスＡのクラス識別子とオブジェクトのメモリサイズ「６０」とを指定して、ＪＶＭＴＩコールバックメソッド１０８を呼び出す。ＪＶＭＴＩコールバックメソッド１０８は、クラスＡのクラス識別子からＡＬｏａｄｅｒを得て、ＡＬｏａｄｅｒとメモリサイズ６０とを指定してヒープサイズ記録手段１０５に対してヒープサイズ管理表１０６の更新を要求する。
【００２９】
ヒープサイズ記録手段１０５は、ステップＳ１でクラスローダＡＬｏａｄｅｒをキーとしてヒープサイズ管理表１０６を検索する。クラスローダＡＬｏａｄｅｒをキーとするエントリは存在するので、ヒープサイズ記録手段１０５は、ステップＳ３で、ヒープサイズ管理表１０６のＡＬｏａｄｅｒをキーとしたエントリのデータ「６０」を取得する。
【００３０】
ヒープサイズ記録手段１０５は、ステップＳ４で、ＪＶＭＴＩコールバックメソッド１０８からの通知がオブジェクト生成であるか否かを判断する。ヒープサイズ記録手段１０５は、通知がオブジェクト生成であるので、ステップＳ４からステップＳ５に移行し、ステップＳ３で取得した、ヒープサイズ管理表１０６のＡＬｏａｄｅｒをキーとしたエントリのデータ「６０」に、メモリサイズ「６０」を加算し、ステップＳ７で、ヒープサイズ管理表１０６に格納する（図３（ｂ）のインスタンスＡｂ生成後）。
【００３１】
ヒープサイズ記録手段１０５は、ステップＳ７でヒープサイズ管理表１０６に格納したデータ「１２０」をヒープサイズ監視手段１０４に渡す。ヒープサイズ監視手段１０４は、ステップＳ８で、格納されたデータ「１２０」としきい値「１００」とを比較する。この値は、しきい値を超えているので、ヒープサイズ監視手段１０４は、ステップＳ９で、クラスローダ１０１に、しきい値を超えた旨を通知する。クラスローダ１０１には、あらかじめ通知を受けた際にすべき動作が設定されている。クラスローダ１０１は、ヒープメモリ１０７におけるメモリサイズがしきい値を超えた旨の通知を受けると、設定にしたがって、例えば、アプリケーションを閉塞させる。
【００３２】
引き続き、Ｊａｖａ  ＶＭ１００が、クラスローダ１０１によってロードされるクラスＡのインスタンスＡａを生成した後に、そのインスタンスが破棄され、ガベージコレクタ１０３によってヒープメモリ１０７の領域が回収された後に、インスタンスＡｂを生成する場合を説明する。
【００３３】
ヒープ割り当て手段１０２は、インスタンスＡａを生成する際に、ヒープメモリ１０７から６０バイトの領域を確保し、クラスＡのクラス識別子とオブジェクトのメモリサイズ「６０」とを指定して、ＪＶＭＴＩコールバックメソッド１０８を呼び出す。ＪＶＭＴＩコールバックメソッド１０８は、クラスＡのクラス識別子からＡＬｏａｄｅｒを得て、ＡＬｏａｄｅｒとメモリサイズ６０とを指定してヒープサイズ記録手段１０５に対してヒープサイズ管理表１０６の更新を要求する。
【００３４】
ヒープサイズ記録手段１０５は、ステップＳ１でクラスローダＡＬｏａｄｅｒをキーとしてヒープサイズ管理表１０６を検索する。エントリが存在しない場合は、ステップＳ２に移行し、ヒープサイズ管理表１０６に、ＡＬｏａｄｅｒをキーとしたエントリを新たに作成し、データを０に初期化する（図３（ｃ）の初期状態）。ヒープサイズ記録手段１０５は、ステップＳ３でデータ「０」を取得する。
【００３５】
ヒープサイズ記録手段１０５は、ステップＳ４で、ＪＶＭＴＩコールバックメソッド１０８からの通知がオブジェクト生成であるか否かを判断する。ヒープサイズ記録手段１０５は、通知がオブジェクト生成であるので、ステップＳ４からステップＳ５に移行し、ステップＳ３で取得した、ヒープサイズ管理表１０６のＡＬｏａｄｅｒをキーとしたエントリのデータ「０」に、メモリサイズ「６０」を加算し、ステップＳ７で、ヒープサイズ管理表１０６に格納する（図３（ｃ）のインスタンスＡａ生成後）。
【００３６】
ヒープサイズ記録手段１０５は、ステップＳ７でヒープサイズ管理表１０６に格納したデータ「６０」をヒープサイズ監視手段１０４に渡す。ヒープサイズ監視手段１０４は、ステップＳ８で、格納されたデータ「６０」としきい値「１００」とを比較する。この値は、しきい値を超えていないので、図２の処理を終了する。
【００３７】
次に、インスタンスＡａが破棄されると、ガベージコレクタ１０３は、インスタンスＡａに割り当てられていたヒープメモリ１０７の６０バイトの領域を回収する。ガベージコレクタ１０３は、クラスＡのクラス識別子とオブジェクトのメモリサイズ６０とを指定して、ＪＶＭＴＩコールバックメソッド１０８を呼び出す。ＪＶＭＴＩコールバックメソッド１０８は、クラスＡのクラス識別子からＡＬｏａｄｅｒを得て、ＡＬｏａｄｅｒと６０とを指定して、ヒープサイズ記録手段１０５に対してヒープサイズ管理表１０６の更新を要求する。
【００３８】
ヒープサイズ記録手段１０５は、ステップＳ１でクラスローダＡＬｏａｄｅｒをキーとしてヒープサイズ管理表１０６を検索する。クラスローダＡＬｏａｄｅｒをキーとするエントリは存在するので、ヒープサイズ記録手段１０５は、ステップＳ３で、ヒープサイズ管理表１０６のＡＬｏａｄｅｒをキーとしたエントリのデータ「６０」を取得する。
【００３９】
ヒープサイズ記録手段１０５は、ステップＳ４で、ＪＶＭＴＩコールバックメソッド１０８からの通知がオブジェクト生成であるか否かを判断する。ヒープサイズ記録手段１０５は、通知がオブジェクト破棄であるので、ステップＳ４からステップＳ６に移行し、ステップＳ３で取得した、ヒープサイズ管理表１０６のＡＬｏａｄｅｒをキーとしたエントリのデータ「６０」から、メモリサイズ「６０」を減算し、ステップＳ７で、ヒープサイズ管理表１０６に格納する（図３（ｃ）のインスタンスＡａ破棄後）。
【００４０】
ヒープサイズ記録手段１０５は、ステップＳ７でヒープサイズ管理表１０６に格納したデータ「０」をヒープサイズ監視手段１０４に渡す。ヒープサイズ監視手段１０４は、ステップＳ８で、格納されたデータ「０」としきい値「１００」とを比較する。この値は、しきい値を超えていないので、図２の処理を終了する。
【００４１】
続いて、ヒープ割り当て手段１０２は、インスタンスＡｂを生成する際に、ヒープメモリ１０７から６０バイトの領域を確保し、クラスＡのクラス識別子とオブジェクトのメモリサイズ「６０」とを指定して、ＪＶＭＴＩコールバックメソッド１０８を呼び出す。ＪＶＭＴＩコールバックメソッド１０８は、クラスＡのクラス識別子からＡＬｏａｄｅｒを得て、ＡＬｏａｄｅｒとメモリサイズ６０とを指定してヒープサイズ記録手段１０５に対してヒープサイズ管理表１０６の更新を要求する。
【００４２】
ヒープサイズ記録手段１０５は、ステップＳ１でクラスローダＡＬｏａｄｅｒをキーとしてヒープサイズ管理表１０６を検索する。クラスローダＡＬｏａｄｅｒをキーとするエントリは存在するので、ヒープサイズ記録手段１０５は、ステップＳ３で、ヒープサイズ管理表１０６のＡＬｏａｄｅｒをキーとしたエントリのデータ「０」を取得する。
【００４３】
ヒープサイズ記録手段１０５は、ステップＳ４で、ＪＶＭＴＩコールバックメソッド１０８からの通知がオブジェクト生成であるか否かを判断する。ヒープサイズ記録手段１０５は、通知がオブジェクト生成であるので、ステップＳ４からステップＳ５に移行し、ステップＳ３で取得した、ヒープサイズ管理表１０６のＡＬｏａｄｅｒをキーとしたエントリのデータ「０」に、メモリサイズ「６０」を加算し、ステップＳ７で、ヒープサイズ管理表１０６に格納する（図３（ｃ）のインスタンスＡｂ生成後）。
【００４４】
ヒープサイズ記録手段１０５は、ステップＳ７でヒープサイズ管理表１０６に格納したデータ「６０」をヒープサイズ監視手段１０４に渡す。ヒープサイズ監視手段１０４は、ステップＳ８で、格納されたデータ「６０」としきい値「１００」とを比較する。この値は、しきい値を超えていないので、図２の処理を終了する。
【００４５】
本実施形態では、ヒープサイズ記録手段１０５を用いて、クラスローダごとに、インスタンス生成時にヒープメモリ１０７に割り当てられたヒープサイズをヒープサイズ管理表１０６に記録する。ヒープサイズ監視手段１０４は、ヒープサイズ管理表１０６にて、ヒープサイズがしきい値を超えたとき、ヒープサイズがしきい値を超えたクラスローダに対して、しきい値を超えた旨を通知する。
【００４６】
本実施形態では、ヒープサイズ管理表にて、アプリケーションのクラスローダ単位に、使用メモリサイズを管理している。このようにすることで、複数のＷｅｂアプリケーションのうちの１つにメモリリークの不具合があったときに、そのアプリケーションをロードするクラスローダに対して、ヒープメモリ１０７の使用量がしきい値を超えた旨を通知することができる。この通知を受けたクラスローダが、アプリケーションを停止することで、他のアプリケーションの動作に影響を与えずに、しきい値を超えてヒープメモリ１０７を使用しているアプリケーションを停止することができる。これにより、アプリケーションをＪａｖａ  ＶＭ１００上で動作させるアプリケーションサーバにて、一のアプリケーションのメモリリークが他のアプリケーションに与える影響を抑制することができる。
【００４７】
また、本実施形態では、ヒープサイズ記録手段１０５は、ガベージコレクタ１０３により、ヒープメモリ１０７の領域が回収されたときは、ヒープサイズ管理表１０６から、回収されたオブジェクトのサイズを減算する。このようにすることで、ガベージコレクションによってヒープが回収された場合でも、クラスローダ単位で、ヒープメモリ１０７の使用量を正確に把握できる。従って、オブジェクトを生成し、その後、ガベージコレクションによってヒープが回収され、その更に後のオブジェクトが生成されたケース（図３（ｃ）では、アプリケーションの正常な運用が可能ある。
【００４８】
なお、上記実施形態では、アプリケーション実行装置が、Ｊａｖａ  ＶＭである例を説明した。アプリケーション実行装置は、これに限定されるものではなく、複数のアプリケーションが実行可能で、かつ、複数のアプリケーションでオブジェクトをロードするメモリ領域が共有される他のアプリケーション実行装置にも適用可能である。
【００４９】
以上、本発明をその好適な実施形態に基づいて説明したが、本発明のメモリ管理装置、システム、方法、及び、プログラムは、上記実施形態にのみ限定されるものではなく、上記実施形態の構成から種々の修正及び変更を施したものも、本発明の範囲に含まれる。
【産業上の利用可能性】
【００５０】
本発明は、Ｊａｖａで動作するアプリケーションサーバプログラムの用途に適用することができる。
【図面の簡単な説明】
【００５１】
【図１】本発明の一実施形態のメモリ管理システムを示すブロック図。
【図２】メモリ管理装置の動作手順を示すブロック図。
【図３】（ａ）は、クラスローダが生成するインスタンスを示す図、（ｂ）及び（ｃ）に、ヒープサイズ管理表のデータ例を示す図。
【符号の説明】
【００５２】
１００：Ｊａｖａ  ＶＭ
１０１：クラスローダ
１０２：ヒープ割り当て手段
１０３：ガベージコレクタ
１０４：ヒープサイズ監視手段
１０５：ヒープサイズ記録手段
１０６：ヒープサイズ管理表
１０７：ヒープメモリ
１０８：ＪＶＭＴＩコールバックメソッド
【図１】
0005157537.tif 000002
【図２】
0005157537.tif 000003
【図３】
0005157537.tif 000004