JP2009211654A - メモリ管理装置、システム、方法、及び、プログラム - Google Patents

Abstract

【課題】一のアプリケーションにメモリリークの不具合が発生した際でも、メモリ領域を共有する他のアプリケーションに与える影響を抑制できるメモリ管理装置を提供する。
【解決手段】ヒープサイズ管理表１０６は、ヒープメモリ１０７の使用量を、オブジェクト生成元のクラスローダ１０１単位で管理する。ヒープサイズ記録手段１０５は、ヒープメモリ１０７におけるメモリ使用量を、クラスローダ１０１単位で、ヒープサイズ管理表１０６に記録する。ヒープサイズ監視手段１０４は、ヒープサイズ管理表１０６で、メモリ使用量が所定のしきい値を超えるクラスローダがあるとき、そのクラスローダに、メモリ使用量がしきい値を超えた旨を通知する。
【選択図】図１

Description

本発明は、メモリ管理装置、システム、方法、及び、プログラムに関し、更に詳しくは、複数のアプリケーションが実行可能で、かつ、複数のアプリケーションでメモリ領域が共有されるアプリケーション実行装置におけるメモリ領域を管理するメモリ管理装置、システム、方法、及び、プログラムに関する。

Ｊａｖａ（登録商標）仮想マシン（Ｊａｖａ ＶＭ：Java Virtual Machine）と呼ばれるアプリケーション実行装置がある。Ｊａｖａ ＶＭは、オブジェクトをヒープと呼ばれるメモリ領域に格納する。Ｊａｖａ ＶＭは、オブジェクトを生成する際に、ヒープのメモリ領域を確保する。オブジェクトが不用になると、ガベージコレクタにより、確保していたヒープのメモリ領域を回収する。これにより、回収したメモリ領域を、別のオブジェクトにて再利用することができる。Ｊａｖａ ＶＭ及びガベージコレクション処理は、例えば、特許文献１に記載されている。

Java Platform, Enterprise Edition（Ｊａｖａ ＥＥ）仕様に準拠するアプリケーションサーバでは、複数のアプリケーションを、単一のＪａｖａ ＶＭ上で動作させることが可能である。このため、Ｊａｖａ ＥＥのアプリケーションサーバでは、各アプリケーションが独立して動作するように、アプリケーションをロードするクラスローダをアプリケーションごとに分ける実装方法が一般的である。別々のクラスローダでアプリケーションをロードすることで、互いのクラスデータが干渉しないようにすることができる。
特開２００２−２５９１４６号公報

ところで、Ｊａｖａ ＶＭにて、複数あるアプリケーションのいずれかに、メモリリークの不具合が発生すると、そのアプリケーションはヒープメモリを大量に確保することになる。Ｊａｖａ ＥＥ仕様に準拠するアプリケーションサーバでは、ヒープメモリの領域は、Ｊａｖａ ＶＭ内で１つしかなく、すべてのアプリケーションで同じ領域を使用している。このため、何れかのアプリケーションにメモリリークがあると、ヒープ不足により、他のアプリケーションが動作できなくなるという問題が発生する。

特許文献１は、資源提供時に、要求元アプリケーションの識別子と、提供した資源とを組にしてテーブルに保存し、アプリケーション終了時に、終了したアプリケーションの識別子に対応する資源をテーブルから特定し、特定した資源を開放するものである。特許文献１は、資源回収をカーネルによらずに実行するアプリケーション実行装置を提供することを目的としており、上記問題を解消する技術ではない。つまり、特許文献１では、クラス単位で、複数のアプリケーションが実行可能で、かつ、複数のアプリケーションでオブジェクトをロードするメモリ領域が共有されるアプリケーション実行装置にて、メモリリーク発生時に、他のアプリケーションに与える影響を抑制することはできない。

本発明は、複数のアプリケーションが実行可能で、かつ、複数のアプリケーションでオブジェクトをロードするメモリ領域が共有されるアプリケーション実行装置にて、メモリリーク発生時に、他のアプリケーションに与える影響を抑制できるメモリ管理装置、システム、方法、及び、プログラムを提供することを目的とする。

上記目的を達成するために、本発明のメモリ管理装置は、複数のアプリケーションが実行可能で、かつ、複数のアプリケーションでメモリ領域が共有されるアプリケーション実行装置におけるメモリ領域を管理するメモリ管理装置であって、前記メモリ領域の使用量を、アプリケーションの生成元ごとにメモリ使用量を管理するメモリサイズ管理表に記録するメモリサイズ記録手段と、前記メモリサイズ管理表で、前記メモリ使用量が所定のしきい値を超える前記アプリケーションの生成元に、メモリ使用量がしきい値を超えた旨を通知するメモリ監視手段とを備えることを特徴とする。

本発明のメモリ管理システムは、複数のアプリケーションが実行可能で、かつ、複数のアプリケーションでメモリ領域が共有されるアプリケーション実行装置と、前記アプリケーション実行装置における前記メモリ領域の使用量を、アプリケーションの生成元ごとにメモリ使用量を管理するメモリサイズ管理表に記録するメモリサイズ記録手段と、前記メモリサイズ管理表で、前記メモリ使用量が所定のしきい値を超える前記アプリケーション実行装置内のアプリケーションの生成元に、メモリ使用量がしきい値を超えた旨を通知するメモリ監視手段とを備えることを特徴とする。

本発明のメモリ管理方法は、コンピュータを用い、複数のアプリケーションが実行可能で、かつ、複数のアプリケーションでメモリ領域が共有されるアプリケーション実行装置におけるメモリ領域を管理する方法であって、前記コンピュータが、前記メモリ領域の使用量を、アプリケーションの生成元ごとにメモリ使用量を管理するメモリサイズ管理表に記録するステップと、前記コンピュータが、前記メモリサイズ管理表で、前記メモリ使用量が所定のしきい値を超える前記アプリケーションの生成元に、メモリ使用量がしきい値を超えた旨を通知するステップとを有することを特徴とする。

本発明のプログラムは、コンピュータに、複数のアプリケーションが実行可能で、かつ、複数のアプリケーションでメモリ領域が共有されるアプリケーション実行装置におけるメモリ領域を管理する処理を実行させるプログラムであって、前記コンピュータに、前記メモリ領域の使用量を、アプリケーションの生成元ごとにメモリ使用量を管理するメモリサイズ管理表に記録する処理と、前記メモリサイズ管理表で、前記メモリ使用量が所定のしきい値を超える前記アプリケーションの生成元に、メモリ使用量がしきい値を超えた旨を通知する処理とを実行させることを特徴とする。

本発明のメモリ管理装置、システム、方法、及び、プログラムは、複数のアプリケーションが実行可能で、かつ、複数のアプリケーションでオブジェクトをロードするメモリ領域が共有されるアプリケーション実行装置にて、メモリリーク発生時に、他のアプリケーションに与える影響を抑制できる。

以下、図面を参照し、本発明の実施の形態を詳細に説明する。図１は、本発明の一実施形態のメモリ管理システムを示している。メモリ管理システムは、アプリケーション実行装置であるＪａｖａ ＶＭ１００と、メモリ管理装置を構成するヒープサイズ監視手段（メモリ監視手段）１０４、及び、ヒープサイズ記録手段（メモリサイズ記録手段）１０５とを有する。Ｊａｖａ ＶＭ１００は、Ｊａｖａプログラムが動作する仮想計算機であり、クラスローダ１０１、ヒープ割り当て手段１０２、ガベージコレクタ１０３、ヒープメモリ１０７を有する。Ｊａｖａ ＶＭ１００及びメモリ管理装置内の各部の機能は、コンピュータ上で所定プログラムを実行することにより実現可能である。

クラスローダ１０１は、図示しないオブジェクト生成部がオブジェクトを生成する際に、ユーザプログラムなどからクラスをロードする。図１では、クラスローダ１０１を１つだけ図示しているが、Ｊａｖａ ＶＭは、複数のクラスローダを有する。ヒープ割り当て手段１０２は、生成されたオブジェクトに対して、ヒープメモリ１０７の領域を割り当てる。ガベージコレクタ１０３は、オブジェクト破棄時に、ヒープメモリ１０７にてオブジェクトに割り当てられていた領域を回収する。

メモリ管理装置は、Ｊａｖａ ＶＭ１００から、ヒープメモリ１０７の割り当て状況を取得する。Ｊａｖａ ＶＭ１００からの情報収集には、Java Virtual Machine Tool Interface（ＪＶＭＴＩ）を用いる。ヒープ割り当て手段１０２は、領域割り当て時に、クラス識別子とオブジェクトサイズ（ヒープメモリ１０７に確保したメモリサイズ）とを指定して、ＪＶＭＴＩコールバックメソッド１０８を呼び出す。また、ガベージコレクタ１０３は、オブジェクトがガベージコレクトされる際に、クラスの識別子とオブジェクトサイズとを指定してＪＶＭＴＩコールバックメソッド１０８を呼び出す。

ＪＶＭＴＩコールバックメソッド１０８は、ヒープ割り当て手段１０２からの呼び出しを受けると、受け取ったクラス識別子からオブジェクトのクラスローダを特定し、クラスローダの識別子とオブジェクトサイズとをヒープサイズ記録手段１０５に通知して、ヒープサイズ管理表（メモリサイズ管理表）１０６の更新を要求する。また、ＪＶＭＴＩコールバックメソッド１０８は、ガベージコレクタ１０３からの呼び出しを受けると、受け取ったクラス識別子からオブジェクトのクラスローダを特定し、クラスローダの識別子とオブジェクトサイズとをヒープサイズ記録手段１０５に通知して、ヒープサイズ管理表１０６の更新を要求する。

ヒープサイズ管理表１０６は、クラスローダの識別子と、そのクラスローダから生成されたオブジェクトが使用中のヒープメモリ１０７のメモリサイズとを対応付けて記憶している。ヒープサイズ記録手段１０５は、ヒープメモリ１０７で使用中のメモリサイズを、クラスローダ単位で、ヒープサイズ管理表１０６に記録する。ヒープサイズ記録手段１０５は、オブジェクトがヒープ割り当て手段１０２によりヒープメモリ１０７に割り当てられたとき、及び、オブジェクトがヒープメモリ１０７から開放されガベージコレクタ１０３がヒープメモリ１０７を回収したとき、ＪＶＭＴＩコールバックメソッド１０８からクラスローダの識別子とオブジェクトサイズとを受け取り、ヒープサイズ管理表１０６を更新する。

ヒープサイズ記録手段１０５は、ＪＶＭＴＩコールバックメソッド１０８がヒープ割り当て手段１０２から呼び出された場合は、ヒープサイズ管理表１０６の対応するクラスローダのカラムの値に、通知されたオブジェクトサイズの値を加える。また、ヒープサイズ記録手段１０５は、ＪＶＭＴＩコールバックメソッド１０８がガベージコレクタ１０３から呼び出された場合は、ヒープサイズ管理表１０６の対応するクラスローダのカラムの値から、通知されたオブジェクトサイズの値を減算する。

ヒープサイズ記録手段１０５は、ヒープサイズ管理表１０６の更新後、メモリサイズとクラスローダの識別子とを、ヒープサイズ監視手段１０４に渡す。ヒープサイズ監視手段１０４は、メモリサイズとしきい値とを比較する。ヒープサイズ監視手段１０４は、ヒープサイズ管理表１０６にて使用中のメモリサイズがしきい値を超えるクラスローダがあるときは、クラスローダの識別子にて識別されるクラスローダに対して、メモリサイズがしきい値を超えたことを通知する。

図２に、メモリ管理装置の動作手順を示す。ヒープサイズ記録手段１０５は、ＪＶＭＴＩコールバックメソッド１０８からの通知を受けて動作を開始する。ヒープサイズ記録手段１０５は、ＪＶＭＴＩコールバックメソッド１０８から通知されたクラスローダが、ヒープサイズ管理表１０６にキーとして存在するか否かを判断する（ステップＳ１）。存在しない場合は、ヒープサイズ管理表１０６にクラスローダをキーとしたエントリを新たに作成し、データを０に初期化する（ステップＳ２）。

ヒープサイズ記録手段１０５は、ヒープサイズ管理表１０６から、クラスローダをキーとしてデータを取得する（ステップＳ３）。ヒープサイズ記録手段１０５は、オブジェクト生成か、オブジェクト破棄かを判断する（ステップＳ４）。ステップＳ４では、ヒープサイズ記録手段１０５は、ＪＶＭＴＩコールバックメソッド１０８がヒープ割り当て手段１０２から呼び出された場合は、オブジェクト生成と判断し、ＪＶＭＴＩコールバックメソッド１０８がガベージコレクタ１０３から呼び出されたときは、オブジェクト破棄と判断する。

ヒープサイズ記録手段１０５は、ステップＳ４でオブジェクト生成と判断すると、ステップＳ３で取得したデータに、ＪＶＭＴＩコールバックメソッド１０８から通知されたオブジェクトサイズを加える（ステップＳ５）。ヒープサイズ記録手段１０５は、ステップＳ４でオブジェクト破棄と判断したときは、ステップＳ３で取得したデータから、ＪＶＭＴＩコールバックメソッド１０８から通知されたオブジェクトサイズを減算する（ステップＳ６）。ヒープサイズ記録手段１０５は、ステップＳ５で加算したデータ、又は、ステップＳ６で減算したデータを、ヒープサイズ管理表１０６に格納し、ヒープサイズ管理表１０６を更新する（ステップＳ７）。

ヒープサイズ記録手段１０５は、クラスローダの識別子と、ステップＳ７でヒープサイズ管理表１０６に格納したデータとを、ヒープサイズ監視手段１０４に通知する。ヒープサイズ監視手段１０４は、格納されたデータと、所定のしきい値とを比較する（ステップＳ８）。ヒープサイズ監視手段１０４は、格納されたデータが、しきい値以下であると判断すると、処理を終了する。ヒープサイズ監視手段１０４は、格納されたデータが、しきい値を超えると判断すると、受け取ったクラスローダ識別子にて識別されるクラスロードに、しきい値を超えた旨を通知する（ステップＳ９）。通知を受けたクラスローダは、アプリケーションを閉塞させる。或いは、アプリケーションを閉塞させずに、アラームを発生してもよい。

以下、具体例を用いて説明する。図３（ａ）に、クラスローダ１０１が生成するインスタンス（オブジェクト）を示し、（ｂ）及び（ｃ）に、ヒープサイズ管理表１０６のデータ例を示す。ここでは、図３（ａ）に示すように、クラスローダ１０１（クラスローダＡＬｏａｄｅｒ）が、クラスＡのインスタンスＡａとインスタンスＡｂとを生成する場合を考える。インスタンスＡａとインスタンスＡｂのメモリサイズは、６０バイトであるとする。ヒープサイズ監視手段１０４におけるしきい値は１００バイトに設定されているとする。

ヒープ割り当て手段１０２は、インスタンスＡａを生成する際に、ヒープメモリ１０７から６０バイトの領域を確保し、クラスＡのクラス識別子とオブジェクトのメモリサイズ「６０」とを指定して、ＪＶＭＴＩコールバックメソッド１０８を呼び出す。ＪＶＭＴＩコールバックメソッド１０８は、クラスＡのクラス識別子からＡＬｏａｄｅｒを得て、ＡＬｏａｄｅｒとメモリサイズ６０とを指定してヒープサイズ記録手段１０５に対してヒープサイズ管理表１０６の更新を要求する。

ヒープサイズ記録手段１０５は、図２のステップＳ１でクラスローダＡＬｏａｄｅｒをキーとしてヒープサイズ管理表１０６を検索する。エントリが存在しない場合は、ステップＳ２に移行し、ヒープサイズ管理表１０６に、ＡＬｏａｄｅｒをキーとしたエントリを新たに作成し、データを０に初期化する（図３（ｂ）の初期化状態）。ヒープサイズ記録手段１０５は、ステップＳ３でデータ「０」を取得する。

ヒープサイズ記録手段１０５は、ステップＳ４で、ＪＶＭＴＩコールバックメソッド１０８からの通知がオブジェクト生成であるか否かを判断する。ヒープサイズ記録手段１０５は、通知がオブジェクト生成であるので、ステップＳ４からステップＳ５に移行し、ステップＳ３で取得した、ヒープサイズ管理表１０６のＡＬｏａｄｅｒをキーとしたエントリのデータ「０」に、メモリサイズ「６０」を加算し、ステップＳ７で、ヒープサイズ管理表１０６に格納する（図３（ｂ）のインスタンスＡａ生成後）。

ヒープサイズ記録手段１０５は、ステップＳ７でヒープサイズ管理表１０６に格納したデータ「６０」をヒープサイズ監視手段１０４に渡す。ヒープサイズ監視手段１０４は、ステップＳ８で、格納されたデータ「６０」としきい値「１００」とを比較する。この値は、しきい値を超えていないので、図２の処理を終了する。

続いて、ヒープ割り当て手段１０２は、インスタンスＡｂを生成する際に、ヒープメモリ１０７から６０バイトの領域を確保し、クラスＡのクラス識別子とオブジェクトのメモリサイズ「６０」とを指定して、ＪＶＭＴＩコールバックメソッド１０８を呼び出す。ＪＶＭＴＩコールバックメソッド１０８は、クラスＡのクラス識別子からＡＬｏａｄｅｒを得て、ＡＬｏａｄｅｒとメモリサイズ６０とを指定してヒープサイズ記録手段１０５に対してヒープサイズ管理表１０６の更新を要求する。

ヒープサイズ記録手段１０５は、ステップＳ１でクラスローダＡＬｏａｄｅｒをキーとしてヒープサイズ管理表１０６を検索する。クラスローダＡＬｏａｄｅｒをキーとするエントリは存在するので、ヒープサイズ記録手段１０５は、ステップＳ３で、ヒープサイズ管理表１０６のＡＬｏａｄｅｒをキーとしたエントリのデータ「６０」を取得する。

ヒープサイズ記録手段１０５は、ステップＳ４で、ＪＶＭＴＩコールバックメソッド１０８からの通知がオブジェクト生成であるか否かを判断する。ヒープサイズ記録手段１０５は、通知がオブジェクト生成であるので、ステップＳ４からステップＳ５に移行し、ステップＳ３で取得した、ヒープサイズ管理表１０６のＡＬｏａｄｅｒをキーとしたエントリのデータ「６０」に、メモリサイズ「６０」を加算し、ステップＳ７で、ヒープサイズ管理表１０６に格納する（図３（ｂ）のインスタンスＡｂ生成後）。

ヒープサイズ記録手段１０５は、ステップＳ７でヒープサイズ管理表１０６に格納したデータ「１２０」をヒープサイズ監視手段１０４に渡す。ヒープサイズ監視手段１０４は、ステップＳ８で、格納されたデータ「１２０」としきい値「１００」とを比較する。この値は、しきい値を超えているので、ヒープサイズ監視手段１０４は、ステップＳ９で、クラスローダ１０１に、しきい値を超えた旨を通知する。クラスローダ１０１には、あらかじめ通知を受けた際にすべき動作が設定されている。クラスローダ１０１は、ヒープメモリ１０７におけるメモリサイズがしきい値を超えた旨の通知を受けると、設定にしたがって、例えば、アプリケーションを閉塞させる。

引き続き、Ｊａｖａ ＶＭ１００が、クラスローダ１０１によってロードされるクラスＡのインスタンスＡａを生成した後に、そのインスタンスが破棄され、ガベージコレクタ１０３によってヒープメモリ１０７の領域が回収された後に、インスタンスＡｂを生成する場合を説明する。

ヒープ割り当て手段１０２は、インスタンスＡａを生成する際に、ヒープメモリ１０７から６０バイトの領域を確保し、クラスＡのクラス識別子とオブジェクトのメモリサイズ「６０」とを指定して、ＪＶＭＴＩコールバックメソッド１０８を呼び出す。ＪＶＭＴＩコールバックメソッド１０８は、クラスＡのクラス識別子からＡＬｏａｄｅｒを得て、ＡＬｏａｄｅｒとメモリサイズ６０とを指定してヒープサイズ記録手段１０５に対してヒープサイズ管理表１０６の更新を要求する。

ヒープサイズ記録手段１０５は、ステップＳ１でクラスローダＡＬｏａｄｅｒをキーとしてヒープサイズ管理表１０６を検索する。エントリが存在しない場合は、ステップＳ２に移行し、ヒープサイズ管理表１０６に、ＡＬｏａｄｅｒをキーとしたエントリを新たに作成し、データを０に初期化する（図３（ｃ）の初期状態）。ヒープサイズ記録手段１０５は、ステップＳ３でデータ「０」を取得する。

ヒープサイズ記録手段１０５は、ステップＳ４で、ＪＶＭＴＩコールバックメソッド１０８からの通知がオブジェクト生成であるか否かを判断する。ヒープサイズ記録手段１０５は、通知がオブジェクト生成であるので、ステップＳ４からステップＳ５に移行し、ステップＳ３で取得した、ヒープサイズ管理表１０６のＡＬｏａｄｅｒをキーとしたエントリのデータ「０」に、メモリサイズ「６０」を加算し、ステップＳ７で、ヒープサイズ管理表１０６に格納する（図３（ｃ）のインスタンスＡａ生成後）。

ヒープサイズ記録手段１０５は、ステップＳ７でヒープサイズ管理表１０６に格納したデータ「６０」をヒープサイズ監視手段１０４に渡す。ヒープサイズ監視手段１０４は、ステップＳ８で、格納されたデータ「６０」としきい値「１００」とを比較する。この値は、しきい値を超えていないので、図２の処理を終了する。

次に、インスタンスＡａが破棄されると、ガベージコレクタ１０３は、インスタンスＡａに割り当てられていたヒープメモリ１０７の６０バイトの領域を回収する。ガベージコレクタ１０３は、クラスＡのクラス識別子とオブジェクトのメモリサイズ６０とを指定して、ＪＶＭＴＩコールバックメソッド１０８を呼び出す。ＪＶＭＴＩコールバックメソッド１０８は、クラスＡのクラス識別子からＡＬｏａｄｅｒを得て、ＡＬｏａｄｅｒと６０とを指定して、ヒープサイズ記録手段１０５に対してヒープサイズ管理表１０６の更新を要求する。

ヒープサイズ記録手段１０５は、ステップＳ１でクラスローダＡＬｏａｄｅｒをキーとしてヒープサイズ管理表１０６を検索する。クラスローダＡＬｏａｄｅｒをキーとするエントリは存在するので、ヒープサイズ記録手段１０５は、ステップＳ３で、ヒープサイズ管理表１０６のＡＬｏａｄｅｒをキーとしたエントリのデータ「６０」を取得する。

ヒープサイズ記録手段１０５は、ステップＳ４で、ＪＶＭＴＩコールバックメソッド１０８からの通知がオブジェクト生成であるか否かを判断する。ヒープサイズ記録手段１０５は、通知がオブジェクト破棄であるので、ステップＳ４からステップＳ６に移行し、ステップＳ３で取得した、ヒープサイズ管理表１０６のＡＬｏａｄｅｒをキーとしたエントリのデータ「６０」から、メモリサイズ「６０」を減算し、ステップＳ７で、ヒープサイズ管理表１０６に格納する（図３（ｃ）のインスタンスＡａ破棄後）。

ヒープサイズ記録手段１０５は、ステップＳ７でヒープサイズ管理表１０６に格納したデータ「０」をヒープサイズ監視手段１０４に渡す。ヒープサイズ監視手段１０４は、ステップＳ８で、格納されたデータ「０」としきい値「１００」とを比較する。この値は、しきい値を超えていないので、図２の処理を終了する。

続いて、ヒープ割り当て手段１０２は、インスタンスＡｂを生成する際に、ヒープメモリ１０７から６０バイトの領域を確保し、クラスＡのクラス識別子とオブジェクトのメモリサイズ「６０」とを指定して、ＪＶＭＴＩコールバックメソッド１０８を呼び出す。ＪＶＭＴＩコールバックメソッド１０８は、クラスＡのクラス識別子からＡＬｏａｄｅｒを得て、ＡＬｏａｄｅｒとメモリサイズ６０とを指定してヒープサイズ記録手段１０５に対してヒープサイズ管理表１０６の更新を要求する。

ヒープサイズ記録手段１０５は、ステップＳ１でクラスローダＡＬｏａｄｅｒをキーとしてヒープサイズ管理表１０６を検索する。クラスローダＡＬｏａｄｅｒをキーとするエントリは存在するので、ヒープサイズ記録手段１０５は、ステップＳ３で、ヒープサイズ管理表１０６のＡＬｏａｄｅｒをキーとしたエントリのデータ「０」を取得する。

ヒープサイズ記録手段１０５は、ステップＳ４で、ＪＶＭＴＩコールバックメソッド１０８からの通知がオブジェクト生成であるか否かを判断する。ヒープサイズ記録手段１０５は、通知がオブジェクト生成であるので、ステップＳ４からステップＳ５に移行し、ステップＳ３で取得した、ヒープサイズ管理表１０６のＡＬｏａｄｅｒをキーとしたエントリのデータ「０」に、メモリサイズ「６０」を加算し、ステップＳ７で、ヒープサイズ管理表１０６に格納する（図３（ｃ）のインスタンスＡｂ生成後）。

ヒープサイズ記録手段１０５は、ステップＳ７でヒープサイズ管理表１０６に格納したデータ「６０」をヒープサイズ監視手段１０４に渡す。ヒープサイズ監視手段１０４は、ステップＳ８で、格納されたデータ「６０」としきい値「１００」とを比較する。この値は、しきい値を超えていないので、図２の処理を終了する。

本実施形態では、ヒープサイズ記録手段１０５を用いて、クラスローダごとに、インスタンス生成時にヒープメモリ１０７に割り当てられたヒープサイズをヒープサイズ管理表１０６に記録する。ヒープサイズ監視手段１０４は、ヒープサイズ管理表１０６にて、ヒープサイズがしきい値を超えたとき、ヒープサイズがしきい値を超えたクラスローダに対して、しきい値を超えた旨を通知する。

本実施形態では、ヒープサイズ管理表にて、アプリケーションのクラスローダ単位に、使用メモリサイズを管理している。このようにすることで、複数のＷｅｂアプリケーションのうちの１つにメモリリークの不具合があったときに、そのアプリケーションをロードするクラスローダに対して、ヒープメモリ１０７の使用量がしきい値を超えた旨を通知することができる。この通知を受けたクラスローダが、アプリケーションを停止することで、他のアプリケーションの動作に影響を与えずに、しきい値を超えてヒープメモリ１０７を使用しているアプリケーションを停止することができる。これにより、アプリケーションをＪａｖａ ＶＭ１００上で動作させるアプリケーションサーバにて、一のアプリケーションのメモリリークが他のアプリケーションに与える影響を抑制することができる。

また、本実施形態では、ヒープサイズ記録手段１０５は、ガベージコレクタ１０３により、ヒープメモリ１０７の領域が回収されたときは、ヒープサイズ管理表１０６から、回収されたオブジェクトのサイズを減算する。このようにすることで、ガベージコレクションによってヒープが回収された場合でも、クラスローダ単位で、ヒープメモリ１０７の使用量を正確に把握できる。従って、オブジェクトを生成し、その後、ガベージコレクションによってヒープが回収され、その更に後のオブジェクトが生成されたケース（図３（ｃ）では、アプリケーションの正常な運用が可能ある。

なお、上記実施形態では、アプリケーション実行装置が、Ｊａｖａ ＶＭである例を説明した。アプリケーション実行装置は、これに限定されるものではなく、複数のアプリケーションが実行可能で、かつ、複数のアプリケーションでオブジェクトをロードするメモリ領域が共有される他のアプリケーション実行装置にも適用可能である。

以上、本発明をその好適な実施形態に基づいて説明したが、本発明のメモリ管理装置、システム、方法、及び、プログラムは、上記実施形態にのみ限定されるものではなく、上記実施形態の構成から種々の修正及び変更を施したものも、本発明の範囲に含まれる。

本発明は、Ｊａｖａで動作するアプリケーションサーバプログラムの用途に適用することができる。

本発明の一実施形態のメモリ管理システムを示すブロック図。 メモリ管理装置の動作手順を示すブロック図。 （ａ）は、クラスローダが生成するインスタンスを示す図、（ｂ）及び（ｃ）に、ヒープサイズ管理表のデータ例を示す図。

符号の説明

１００：Ｊａｖａ ＶＭ
１０１：クラスローダ
１０２：ヒープ割り当て手段
１０３：ガベージコレクタ
１０４：ヒープサイズ監視手段
１０５：ヒープサイズ記録手段
１０６：ヒープサイズ管理表
１０７：ヒープメモリ
１０８：ＪＶＭＴＩコールバックメソッド

Claims (19)

1. 複数のアプリケーションが実行可能で、かつ、複数のアプリケーションでメモリ領域が共有されるアプリケーション実行装置におけるメモリ領域を管理するメモリ管理装置であって、
   前記メモリ領域の使用量を、アプリケーションの生成元ごとにメモリ使用量を管理するメモリサイズ管理表に記録するメモリサイズ記録手段と、
   前記メモリサイズ管理表で、前記メモリ使用量が所定のしきい値を超える前記アプリケーションの生成元に、メモリ使用量がしきい値を超えた旨を通知するメモリ監視手段とを備えるメモリ管理装置。
2. 前記メモリサイズ記録手段は、前記アプリケーションがメモリ領域に割り当てられたとき、及び、前記アプリケーションがメモリ領域から開放されたとき、前記メモリサイズ管理表を更新する、請求項１に記載のメモリ管理装置。
3. 前記メモリサイズ記録手段は、前記アプリケーション実行装置にて前記アプリケーションが前記メモリ領域に割り当てられると、前記メモリサイズ管理表における前記割り当てられたアプリケーションの生成元のメモリ使用量を、前記メモリ領域に割り当てられたメモリサイズ分だけ加算する、請求項１又は２に記載のメモリ管理装置。
4. 前記メモリサイズ記録手段は、前記アプリケーション実行装置にて前記アプリケーションに割り当てられていたメモリ領域が回収されると、前記メモリサイズ管理表における前記開放されたアプリケーションの生成元のメモリ使用量から、前記メモリ領域から回収されたメモリサイズ分だけ減算する、請求項１乃至３の何れか一に記載のメモリ管理装置。
5. 前記アプリケーション実行装置がＪａｖａ仮想マシンであり、前記アプリケーション生成元が、オブジェクト生成元のクラスをロードするクラスローダである、請求項１乃至４の何れか一に記載のメモリ管理装置。
6. 前記メモリサイズ記録手段は、Java Virtual Machine Tool Interfaceを用いて、前記Ｊａｖａ仮想マシンから、該Ｊａｖａ仮想マシンにて前記オブジェクトに割り当てられたメモリ領域のサイズ、及び、前記オブジェクト破棄時に前記メモリ領域からガベージコレクション処理により回収されたメモリ領域のサイズと、前記オブジェクトの生成元のクラスを識別する情報とを取得し、該取得した情報に基づいて前記メモリサイズ管理表を更新する、請求項５に記載のメモリ管理装置。
7. 複数のアプリケーションが実行可能で、かつ、複数のアプリケーションでメモリ領域が共有されるアプリケーション実行装置と、
   前記アプリケーション実行装置における前記メモリ領域の使用量を、アプリケーションの生成元ごとにメモリ使用量を管理するメモリサイズ管理表に記録するメモリサイズ記録手段と、
   前記メモリサイズ管理表で、前記メモリ使用量が所定のしきい値を超える前記アプリケーション実行装置内のアプリケーションの生成元に、メモリ使用量がしきい値を超えた旨を通知するメモリ監視手段とを備えるメモリ管理システム。
8. コンピュータを用い、複数のアプリケーションが実行可能で、かつ、複数のアプリケーションでメモリ領域が共有されるアプリケーション実行装置におけるメモリ領域を管理する方法であって、
   前記コンピュータが、前記メモリ領域の使用量を、アプリケーションの生成元ごとにメモリ使用量を管理するメモリサイズ管理表に記録するステップと、
   前記コンピュータが、前記メモリサイズ管理表で、前記メモリ使用量が所定のしきい値を超える前記アプリケーションの生成元に、メモリ使用量がしきい値を超えた旨を通知するステップとを有するメモリ管理方法。
9. 前記コンピュータは、前記アプリケーション実行装置にて、前記アプリケーションがメモリ領域に割り当てられたとき、及び、前記アプリケーションがメモリ領域から開放されたとき、前記メモリサイズ管理表を更新するステップを実行する、請求項８に記載のメモリ管理方法。
10. 前記コンピュータは、前記アプリケーション実行装置にて前記アプリケーションが前記メモリ領域に割り当てられると、前記メモリサイズ管理表を更新するステップで、前記メモリサイズ管理表における前記割り当てられたアプリケーションの生成元のメモリ使用量を、前記メモリ領域に割り当てられたメモリサイズ分だけ加算する、請求項８又は９に記載のメモリ管理方法。
11. 前記コンピュータは、前記アプリケーション実行装置にて前記アプリケーションに割り当てられていたメモリ領域が回収されると、前記メモリサイズ管理表を更新するステップで、前記メモリサイズ管理表における前記開放されたアプリケーションの生成元のメモリ使用量から、前記メモリ領域から回収されたメモリサイズ分だけ減算する、請求項８乃至１０の何れか一に記載のメモリ管理方法。
12. 前記アプリケーション実行装置がＪａｖａ仮想マシンであり、前記アプリケーション生成元が、オブジェクト生成元のクラスをロードするクラスローダである、請求項８乃至１１の何れか一に記載のメモリ管理方法。
13. 前記コンピュータは、前記メモリサイズ管理表を更新するステップでは、Java Virtual Machine Tool Interfaceを用いて、前記Ｊａｖａ仮想マシンから、該Ｊａｖａ仮想マシンにて前記オブジェクトに割り当てられたメモリ領域のサイズ、及び、前記オブジェクト破棄時に前記メモリ領域からガベージコレクション処理により回収されたメモリ領域のサイズと、前記オブジェクトの生成元のクラスを識別する情報とを取得し、該取得した情報に基づいて前記メモリサイズ管理表を更新する、請求項１２に記載のメモリ管理方法。
14. コンピュータに、複数のアプリケーションが実行可能で、かつ、複数のアプリケーションでメモリ領域が共有されるアプリケーション実行装置におけるメモリ領域を管理する処理を実行させるプログラムであって、前記コンピュータに、
    前記メモリ領域の使用量を、アプリケーションの生成元ごとにメモリ使用量を管理するメモリサイズ管理表に記録する処理と、
    前記メモリサイズ管理表で、前記メモリ使用量が所定のしきい値を超える前記アプリケーションの生成元に、メモリ使用量がしきい値を超えた旨を通知する処理とを実行させるプログラム。
15. 前記コンピュータに、前記アプリケーション実行装置にて、前記アプリケーションがメモリ領域に割り当てられたとき、及び、前記アプリケーションがメモリ領域から開放されたとき、前記メモリサイズ管理表を更新する処理を実行させる、請求項１４に記載のプログラム。
16. 前記メモリサイズ管理表を更新する処理では、前記アプリケーション実行装置にて前記アプリケーションが前記メモリ領域に割り当てられると、前記メモリサイズ管理表における前記割り当てられたアプリケーションの生成元のメモリ使用量を、前記メモリ領域に割り当てられたメモリサイズ分だけ加算する、請求項１４又は１５に記載のプログラム。
17. 前記メモリサイズ管理表を更新する処理では、前記アプリケーション実行装置にて前記アプリケーションに割り当てられていたメモリ領域が回収されると、前記メモリサイズ管理表における前記開放されたアプリケーションの生成元のメモリ使用量から、前記メモリ領域から回収されたメモリサイズ分だけ減算する、請求項１４乃至１６の何れか一に記載のプログラム。
18. 前記アプリケーション実行装置がＪａｖａ仮想マシンであり、前記アプリケーション生成元が、オブジェクト生成元のクラスをロードするクラスローダである、請求項１４乃至１７の何れか一に記載のプログラム。
19. 前記メモリサイズ管理表を更新する処理では、Java Virtual Machine Tool Interfaceを用いて、前記Ｊａｖａ仮想マシンから、該Ｊａｖａ仮想マシンにて前記オブジェクトに割り当てられたメモリ領域のサイズ、及び、前記オブジェクト破棄時に前記メモリ領域からガベージコレクション処理により回収されたメモリ領域のサイズと、前記オブジェクトの生成元のクラスを識別する情報とを取得し、該取得した情報に基づいて前記メモリサイズ管理表を更新する、請求項１８に記載のプログラム。

Images