(57)【特許請求の範囲】
【請求項１】
ソフトウェアプラットフォーム上で動作するバンドルが利用するメモリを管理するメモリ管理装置であって、
メモリの管理単位でグループを作成し、グループ毎に利用できるメモリ量の制限値を設定し、前記バンドルをインストールする際に、当該バンドルのクラスローダオブジェクトに前記グループを設定する設定手段と、
前記バンドルあるいは前記ソフトウェアプラットフォームのクラスローダオブジェクトがメモリを要求したときに、メモリを要求した前記バンドルあるいは前記ソフトウェアプラットフォームのクラスローダオブジェクトに設定されたグループを要求メモリ量のカウント先として選択する選択手段と、
前記選択手段が選択したグループにすでに割り当てられたメモリの合計値であるメモリ消費量積算値に前記要求メモリ量を加えた予想積算値と当該グループに設定された制限値とを比較し、前記予想積算値が前記制限値以下の場合は、ヒープ領域から前記要求メモリ量のメモリを割り当てるとともに、当該グループの前記メモリ消費量積算値に前記要求メモリ量を加えて前記メモリ消費量積算値を更新し、前記予想積算値が前記制限値を超えた場合はエラーを発生する割当手段と、
を有することを特徴とするメモリ管理装置。
【請求項２】
ソフトウェアプラットフォーム上で動作するバンドルが利用するメモリを管理するメモリ管理装置であって、
メモリの管理単位でグループを作成し、グループ毎に利用できるメモリ量の制限値を設定し、前記バンドルをインストールする際に、当該バンドルのクラスローダオブジェクトに前記グループを設定する設定手段と、
前記バンドルあるいは前記ソフトウェアプラットフォームのクラスローダオブジェクトがメモリを要求したときに、メモリを要求した前記バンドルあるいは前記ソフトウェアプラットフォームの呼び出し元を辿り、最初の呼び出し元となるバンドルあるいは前記ソフトウェアプラットフォームが属するグループを要求メモリ量のカウント先として選択する選択手段と、
前記選択手段が選択したグループにすでに割り当てられたメモリの合計値であるメモリ消費量積算値に前記要求メモリ量を加えた予想積算値と当該グループに設定された制限値とを比較し、前記予想積算値が前記制限値以下の場合は、ヒープ領域から前記要求メモリ量のメモリを割り当てるとともに、当該グループの前記メモリ消費量積算値に前記要求メモリ量を加えて前記メモリ消費量積算値を更新し、前記予想積算値が前記制限値を超えた場合はエラーを発生する割当手段と、
を有することを特徴とするメモリ管理装置。
【請求項３】
ソフトウェアプラットフォーム上で動作するバンドルが利用するメモリを管理するメモリ管理装置であって、
メモリの管理単位でグループを作成し、グループ毎に利用できるメモリ量の制限値を設定し、前記バンドルをインストールする際に、当該バンドルのクラスローダオブジェクトに前記グループを設定する設定手段と、
前記バンドルあるいは前記ソフトウェアプラットフォームのクラスローダオブジェクトがメモリを要求したときに、メモリを要求した前記バンドルあるいは前記ソフトウェアプラットフォームの呼び出し元を辿り、前記ソフトウェアプラットフォームに呼び出されたバンドルが属するグループを要求メモリ量のカウント先として選択する選択手段と、
前記選択手段が選択したグループにすでに割り当てられたメモリの合計値であるメモリ消費量積算値に前記要求メモリ量を加えた予想積算値と当該グループに設定された制限値とを比較し、前記予想積算値が前記制限値以下の場合は、ヒープ領域から前記要求メモリ量のメモリを割り当てるとともに、当該グループの前記メモリ消費量積算値に前記要求メモリ量を加えて前記メモリ消費量積算値を更新し、前記予想積算値が前記制限値を超えた場合はエラーを発生する割当手段と、
を有することを特徴とするメモリ管理装置。
【請求項４】
ソフトウェアプラットフォーム上で動作するバンドルが利用するメモリを管理するメモリ管理装置であって、
メモリの管理単位でグループを作成し、グループ毎に利用できるメモリ量の制限値を設定し、前記バンドルをインストールする際に、当該バンドルのクラスローダオブジェクトに前記グループを設定する設定手段と、
前記バンドルに機能提供フラグあるいは機能利用フラグを設定する機能設定手段と、
前記バンドルあるいは前記ソフトウェアプラットフォームのクラスローダオブジェクトがメモリを要求したときに、メモリを要求した前記バンドルあるいは前記ソフトウェアプラットフォームの呼び出し元を辿り、前記ソフトウェアプラットフォームに呼び出されたバンドルが属するグループ、又は、機能利用フラグが設定されたバンドルが属するグループを要求メモリ量のカウント先として選択する選択手段と、
前記選択手段が選択したグループにすでに割り当てられたメモリの合計値であるメモリ消費量積算値に前記要求メモリ量を加えた予想積算値と当該グループに設定された制限値とを比較し、前記予想積算値が前記制限値以下の場合は、ヒープ領域から前記要求メモリ量のメモリを割り当てるとともに、当該グループの前記メモリ消費量積算値に前記要求メモリ量を加えて前記メモリ消費量積算値を更新し、前記予想積算値が前記制限値を超えた場合はエラーを発生する割当手段と、
を有することを特徴とするメモリ管理装置。
【請求項５】
ソフトウェアプラットフォーム上で動作するバンドルが利用するメモリを管理するメモリ管理装置であって、
メモリの管理単位でグループを作成し、グループ毎に利用できるメモリ量の制限値を設定し、前記バンドルをインストールする際に、当該バンドルのクラスローダオブジェクトに前記グループを設定する設定手段と、
前記バンドルあるいは前記ソフトウェアプラットフォームによりスレッドが立てられるときに、当該スレッドを立てる前記バンドルあるいは前記ソフトウェアプラットフォームのクラスローダオブジェクトに設定されたグループを当該スレッドのグループとして設定するスレッド設定手段と、
前記バンドルあるいは前記ソフトウェアプラットフォームのクラスローダオブジェクトがメモリを要求したときに、メモリを要求した前記バンドルあるいは前記ソフトウェアプラットフォームが属するスレッドに設定されたグループを要求メモリ量のカウント先として選択する選択手段と、
前記選択手段が選択したグループにすでに割り当てられたメモリの合計値であるメモリ消費量積算値に前記要求メモリ量を加えた予想積算値と当該グループに設定された制限値とを比較し、前記予想積算値が前記制限値以下の場合は、ヒープ領域から前記要求メモリ量のメモリを割り当てるとともに、当該グループの前記メモリ消費量積算値に前記要求メモリ量を加えて前記メモリ消費量積算値を更新し、前記予想積算値が前記制限値を超えた場合はエラーを発生する割当手段と、
を有することを特徴とするメモリ管理装置。
【請求項６】
ソフトウェアプラットフォーム上で動作するバンドルが利用するメモリを管理するメモリ管理方法であって、
コンピュータによる、
メモリの管理単位でグループを作成し、グループ毎に利用できるメモリ量の制限値を設定するステップと、
前記バンドルをインストールする際に、当該バンドルのクラスローダオブジェクトに前記グループを設定するステップと、
前記バンドルあるいは前記ソフトウェアプラットフォームのクラスローダオブジェクトがメモリを要求したときに、メモリを要求した前記バンドルあるいは前記ソフトウェアプラットフォームのクラスローダオブジェクトに設定されたグループを要求メモリ量のカウント先として選択するステップと、
前記選択するステップで選択したグループにすでに割り当てられたメモリの合計値であるメモリ消費量積算値に前記要求メモリ量を加えた予想積算値と当該グループに設定された制限値とを比較するステップと、
前記予想積算値が前記制限値以下の場合は、ヒープ領域から前記要求メモリ量のメモリを割り当てるとともに、当該グループの前記メモリ消費量積算値に前記要求メモリ量を加えて前記メモリ消費量積算値を更新するステップと、
前記予想積算値が前記制限値を超えた場合は、エラーを発生するステップと、
を有することを特徴とするメモリ管理方法。
【請求項７】
ソフトウェアプラットフォーム上で動作するバンドルが利用するメモリを管理するメモリ管理方法であって、
コンピュータによる、
メモリの管理単位でグループを作成し、グループ毎に利用できるメモリ量の制限値を設定するステップと、
前記バンドルをインストールする際に、当該バンドルのクラスローダオブジェクトに前記グループを設定するステップと、
前記バンドルあるいは前記ソフトウェアプラットフォームのクラスローダオブジェクトがメモリを要求したときに、メモリを要求した前記バンドルあるいは前記ソフトウェアプラットフォームの呼び出し元を辿り、最初の呼び出し元となるバンドルあるいは前記ソフトウェアプラットフォームが属するグループを要求メモリ量のカウント先として選択するステップと、
前記選択するステップで選択したグループにすでに割り当てられたメモリの合計値であるメモリ消費量積算値に前記要求メモリ量を加えた予想積算値と当該グループに設定された制限値とを比較するステップと、
前記予想積算値が前記制限値以下の場合は、ヒープ領域から前記要求メモリ量のメモリを割り当てるとともに、当該グループの前記メモリ消費量積算値に前記要求メモリ量を加えて前記メモリ消費量積算値を更新するステップと、
前記予想積算値が前記制限値を超えた場合は、エラーを発生するステップと、
を有することを特徴とするメモリ管理方法。
【請求項８】
ソフトウェアプラットフォーム上で動作するバンドルが利用するメモリを管理するメモリ管理方法であって、
コンピュータによる、
メモリの管理単位でグループを作成し、グループ毎に利用できるメモリ量の制限値を設定するステップと、
前記バンドルをインストールする際に、当該バンドルのクラスローダオブジェクトに前記グループを設定するステップと、
前記バンドルあるいは前記ソフトウェアプラットフォームのクラスローダオブジェクトがメモリを要求したときに、メモリを要求した前記バンドルあるいは前記ソフトウェアプラットフォームの呼び出し元を辿り、前記ソフトウェアプラットフォームに呼び出されたバンドルが属するグループを要求メモリ量のカウント先として選択するステップと、
前記選択するステップで選択したグループにすでに割り当てられたメモリの合計値であるメモリ消費量積算値に前記要求メモリ量を加えた予想積算値と当該グループに設定された制限値とを比較するステップと、
前記予想積算値が前記制限値以下の場合は、ヒープ領域から前記要求メモリ量のメモリを割り当てるとともに、当該グループの前記メモリ消費量積算値に前記要求メモリ量を加えて前記メモリ消費量積算値を更新するステップと、
前記予想積算値が前記制限値を超えた場合は、エラーを発生するステップと、
を有することを特徴とするメモリ管理方法。
【請求項９】
ソフトウェアプラットフォーム上で動作するバンドルが利用するメモリを管理するメモリ管理方法であって、
コンピュータによる、
メモリの管理単位でグループを作成し、グループ毎に利用できるメモリ量の制限値を設定するステップと、
前記バンドルをインストールする際に、当該バンドルのクラスローダオブジェクトに前記グループを設定するステップと、
前記バンドルに機能提供フラグあるいは機能利用フラグを設定するステップと、
前記バンドルあるいは前記ソフトウェアプラットフォームのクラスローダオブジェクトがメモリを要求したときに、メモリを要求した前記バンドルあるいは前記ソフトウェアプラットフォームの呼び出し元を辿り、前記ソフトウェアプラットフォームに呼び出されたバンドルが属するグループ、又は、機能利用フラグが設定されたバンドルが属するグループを要求メモリ量のカウント先として選択するステップと、
前記選択するステップで選択したグループにすでに割り当てられたメモリの合計値であるメモリ消費量積算値に前記要求メモリ量を加えた予想積算値と当該グループに設定された制限値とを比較するステップと、
前記予想積算値が前記制限値以下の場合は、ヒープ領域から前記要求メモリ量のメモリを割り当てるとともに、当該グループの前記メモリ消費量積算値に前記要求メモリ量を加えて前記メモリ消費量積算値を更新するステップと、
前記予想積算値が前記制限値を超えた場合は、エラーを発生するステップと、
を有することを特徴とするメモリ管理方法。
【請求項１０】
ソフトウェアプラットフォーム上で動作するバンドルが利用するメモリを管理するメモリ管理方法であって、
コンピュータによる、
メモリの管理単位でグループを作成し、グループ毎に利用できるメモリ量の制限値を設定するステップと、
前記バンドルをインストールする際に、当該バンドルのクラスローダオブジェクトに前記グループを設定するステップと、
前記バンドルあるいは前記ソフトウェアプラットフォームがスレッドを立てるときに、当該スレッドを立てる前記バンドルあるいは前記ソフトウェアプラットフォームの属するグループを当該スレッドに設定するステップと、
前記バンドルあるいは前記ソフトウェアプラットフォームのクラスローダオブジェクトがメモリを要求したときに、メモリを要求した前記バンドルあるいは前記ソフトウェアプラットフォームが属するスレッドに設定されたグループを要求メモリ量のカウント先として選択するステップと、
前記選択するステップで選択したグループにすでに割り当てられたメモリの合計値であるメモリ消費量積算値に前記要求メモリ量を加えた予想積算値と当該グループに設定された制限値とを比較するステップと、
前記予想積算値が前記制限値以下の場合は、ヒープ領域から前記要求メモリ量のメモリを割り当てるとともに、当該グループの前記メモリ消費量積算値に前記要求メモリ量を加えて前記メモリ消費量積算値を更新するステップと、
前記予想積算値が前記制限値を超えた場合は、エラーを発生するステップと、
を有することを特徴とするメモリ管理方法。
【請求項１１】
メモリが要求されて生成されたオブジェクトに、当該メモリの消費量のカウント先として選択されたグループを識別するグループＩＤを付与するステップと、
指定されたグループＩＤが付与された前記オブジェクトのサイズを合計し、当該グループＩＤが示すグループのメモリ消費量を求めるステップと、
を有することを特徴とする請求項６乃至１０のいずれかに記載のメモリ管理方法。
【請求項１２】
請求項６乃至１１のいずれかに記載の各ステップをコンピュータに実行させることを特徴とするメモリ管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＯＳＧｉ標準仕様に基づくバンドルが利用するメモリを管理する技術に関する。
【背景技術】
【０００２】
〔ＯＳＧｉについて〕
ＯＳＧｉ（Open Services Gateway interactive）は、ソフトウェアのモジュール化技術である。ＯＳＧｉ標準仕様に基づくソフトウェアモジュールは、バンドルと呼ばれている。
【０００３】
システムアーキテクチャとしては、図１６に示すように、動作端末のＯＳ（Operating System）上でＪａｖａＶＭ（Java（登録商標） Virtual Machine：Ｊａｖａ仮想マシン）が１つのプロセスとして動作し、ＪａｖａＶＭ上でバンドルの実行環境であるＯＳＧｉＦＷ（OSGi Framework）が動作する。このＯＳＧｉＦＷ上で複数のバンドルを動作させることができる。ＯＳＧｉＦＷおよびバンドルは、Ｊａｖａプログラムである。
【０００４】
ＪａｖａプログラムをＪａｖａＶＭ上で動作させるには、まず、Ｊａｖａ言語で書かれたソースコードを、ＪａｖａＶＭが解釈できるバイナリファイルであるクラスファイルにコンパイルする。ＪａｖａＶＭは、そのクラスファイルを解釈し、プログラムを実行する。
【０００５】
バンドルは、クラスファイルや画像ファイル等のプログラムの実行に必要なファイルの集合である。ＯＳＧｉ仕様では、複数のバンドルが連携する仕組み、つまり、あるバンドルが提供するクラスファイルを別のバンドルが呼び出すことができる仕組みを定めている。
【０００６】
その１つがＯＳＧｉサービスによる連携である。具体的には、図１７に示すように、バンドルＡが、Ｊａｖａインターフェイスで定義されるサービスＳの実装クラスを提供し、生成したオブジェクトをＯＳＧｉサービスとしてＯＳＧｉＦＷのサービスレジストリに登録する。バンドルＢは、サービスレジストリに登録されている当該ＯＳＧｉサービスを取得し、そのオブジェクトが持つサービスＳのメソッドを呼び出すことができる。
【０００７】
その他、パッケージのＩｍｐｏｒｔ・Ｅｘｐｏｒｔによる連携などがある。
【０００８】
〔機能の提供・利用について〕
多くのＯＳＧｉサービスは、図１８に示すように、ＯＳＧｉサービスを登録したバンドルＣが、サービスＳを通じてバンドルＤに機能を提供する形態である。
【０００９】
例えば、ＯＳＧｉ仕様で定められたＨｔｔｐＳｅｒｖｉｃｅでは、バンドルＣがＨｔｔｐＳｅｒｖｉｃｅの実装クラスを提供してサービス登録することにより、ＨＴＴＰサーバへのＪａｖａＳｅｒｖｌｅｔ登録機能などを他のバンドルに提供する。バンドルＤは、ＨｔｔｐＳｅｒｖｉｃｅを取得し、呼び出すことにより、バンドルＣが提供するクラスのＨｔｔｐＳｅｒｖｉｃｅの機能を利用する。
【００１０】
一方、コールバック型の呼び出しの場合、機能の提供と利用が逆になる。例として、図１９に示すように、ある情報を管理するバンドルＥと、その情報が変更された時点で通知して欲しいバンドルＦが存在する場合における、イベント通知が挙げられる。
【００１１】
この場合、バンドルＦが、イベントリスナＬとなるＯＳＧｉサービスの実装クラスを提供してサービスレジストリにサービス登録し、バンドルＥがイベント通知すべきタイミングになると、登録された当該ＯＳＧｉサービスを取得してコールバックする。
【００１２】
つまり、イベント通知という機能を提供するのは呼び出しを行うバンドルＥであり、クラスを提供するバンドルＦはその機能を利用していることになる。
【００１３】
このような機能の提供・利用の関係は、バンドル同士の連携以外にも、バンドルとＯＳＧｉＦＷ、バンドルとＪａｖａＶＭなどにもある。
【００１４】
〔ＪａｖａＶＭについて〕
従来の技術では、バンドル・ＯＳＧｉＦＷ・ＪａｖａＶＭ自体が動作するために必要なメモリは、ＪａｖａＶＭが、ＯＳから割り当てられた１つのヒープメモリ（ヒープ領域）から確保する。具体的には、例えば、あるスレッドで呼び出されたバンドルが利用（確保・消費）するメモリは、１つのヒープ領域から確保される。以下、メモリ割当という表現で説明する場合もある。
【００１５】
また、ＪａｖａＶＭ上で動作するスレッドにおいて、メモリ割当は、図２０に示すように、常に、各スレッドの一番上のスタック（TOPSTACK）で発生する。ＪａｖａＶＭ仕様としては、オブジェクトには特定の構造体を規定していない。システムのＥｎｔｉｔｙであるバンドル・ＯＳＧｉＦＷ・ＪａｖａＶＭは、１つのヒープ領域を共有する。
【００１６】
メモリ割当時に必要なメモリ量が確保できないとＧＣ（Garbage Collection）が行われ、その時点で参照されていないオブジェクトのメモリ領域は解放される。ＧＣが行われても必要なメモリ量が確保できない場合には、ＯＯＭ（Out Of Memory）エラーが発生する。ＯＯＭエラーを捕捉し、対処する処理が各Ｅｎｔｉｔｙで適切にされていない場合、そのＥｎｔｉｔｙは動作をしなくなる可能性がある。
【００１７】
本発明では、「必要なメモリ量が確保できない場合」とは、ＧＣが行われても必要なメモリ量が確保できない場合を指す。
【００１８】
また、図２１に示すように、ＪａｖａＶＭのスタック構造は、一般的に、（１）呼び出し元スタックによる呼び出しが契機になり、（２）クラス提供スタック内の処理においてメモリ割当が行われる。
【先行技術文献】
【非特許文献】
【００１９】
【非特許文献１】「The Java Virtual Machine Specification、3.5.3 Heap, 4.1 The ClassFile Structure」、［Online］、平成24年2月8日検索、＜URL : http://java.sun.com/docs/books/jvms/second_edition/html/VMSpecTOC.doc.html＞
【非特許文献２】「OSGi Alliance」、［Online］、平成24年2月8日検索、＜URL : http://www.osgi.org/Specifications/HomePage＞
【発明の概要】
【発明が解決しようとする課題】
【００２０】
従来の技術では、バンドル・ＯＳＧｉＦＷ・ＪａｖａＶＭがヒープ領域を共有するため、あるＥｎｔｉｔｙでＯＯＭエラーが発生してメモリが解放されない場合、その他のＥｎｔｉｔｙもその時点以降、新たにメモリを確保することができなくなり、結果的に全てのシステムが停止してしまう可能性がある。
【００２１】
特に課題となるのは、複数の事業者が従来の技術を用いて、１つのシステムを共有して同時にサービスを提供するような場合である。
【００２２】
例えば、プラットフォーム（Ｐｌａｔｆｏｒｍ）事業者（以下、「ＰＦ事業者」と称する）は、ＪａｖａＶＭやＯＳＧｉＦＷなどのシステムの基盤となる部分をプラットフォームシステムとして提供し、サービス（Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｄｅｒ）事業者（以下、「ＳＰ事業者」と称する）は、自身が開発したバンドルをＰＦ事業者が提供するプラットフォームシステム上で動作させることでサービスを提供することを想定する。
【００２３】
この時、あるＳＰ事業者の作成するバンドルがバグ等により想定以上のメモリを消費すると、そのバグがなければ正常に動作可能であったはずのＪａｖａＶＭ、ＯＳＧｉＦＷ、および他のバンドルなどの他のＥｎｔｉｔｙまで動作できなくなってしまう。つまり、正常な動作をしているはずのＪａｖａＶＭ上で動作する全てのＥｎｔｉｔｙ（ＰＦ事業者の提供するシステムやＳＰ事業者のバンドル）が、１つのＳＰ事業者のバンドルのバグによって動作不能になることが発生する。
【００２４】
また、前述したように、ＯＳＧｉにおいてはバンドルやＯＳＧｉＦＷなどの構成要素が連携している。連携した時に消費されるメモリは、「呼び出し元」と「クラス提供」とのどちらのメモリ消費量としてカウントするかといった定義は、ＯＳＧｉやＪａｖａの仕様では定められていない（非特許文献１、非特許文献２参照）。定義が決まっていないため、バンドルのメモリ消費量の計測もできない。
【００２５】
本発明は、上記課題を鑑みてなされたものであり、その課題とするところは、メモリ消費量を任意の単位で制限することを目的とする。
【課題を解決するための手段】
【００２６】
第１の本発明に係るメモリ管理装置は、ソフトウェアプラットフォーム上で動作するバンドルが利用するメモリを管理するメモリ管理装置であって、メモリの管理単位でグループを作成し、グループ毎に利用できるメモリ量の制限値を設定し、前記バンドルをインストールする際に、当該バンドルのクラスローダオブジェクトに前記グループを設定する設定手段と、前記バンドルあるいは前記ソフトウェアプラットフォームのクラスローダオブジェクトがメモリを要求したときに、メモリを要求した前記バンドルあるいは前記ソフトウェアプラットフォームのクラスローダオブジェクトに設定されたグループを要求メモリ量のカウント先として選択する選択手段と、前記選択手段が選択したグループにすでに割り当てられたメモリの合計値であるメモリ消費量積算値に前記要求メモリ量を加えた予想積算値と当該グループに設定された制限値とを比較し、前記予想積算値が前記制限値以下の場合は、ヒープ領域から前記要求メモリ量のメモリを割り当てるとともに、当該グループの前記メモリ消費量積算値に前記要求メモリ量を加えて前記メモリ消費量積算値を更新し、前記予想積算値が前記制限値を超えた場合はエラーを発生する割当手段と、を有することを特徴とする。
【００２７】
第２の本発明に係るメモリ管理方法は、ソフトウェアプラットフォーム上で動作するバンドルが利用するメモリを管理するメモリ管理方法であって、コンピュータによる、メモリの管理単位でグループを作成し、グループ毎に利用できるメモリ量の制限値を設定するステップと、前記バンドルをインストールする際に、当該バンドルのクラスローダオブジェクトに前記グループを設定するステップと、前記バンドルあるいは前記ソフトウェアプラットフォームのクラスローダオブジェクトがメモリを要求したときに、メモリを要求した前記バンドルあるいは前記ソフトウェアプラットフォームのクラスローダオブジェクトに設定されたグループを要求メモリ量のカウント先として選択するステップと、前記選択するステップで選択したグループにすでに割り当てられたメモリの合計値であるメモリ消費量積算値に前記要求メモリ量を加えた予想積算値と当該グループに設定された制限値とを比較するステップと、前記予想積算値が前記制限値以下の場合は、ヒープ領域から前記要求メモリ量のメモリを割り当てるとともに、当該グループの前記メモリ消費量積算値に前記要求メモリ量を加えて前記メモリ消費量積算値を更新するステップと、前記予想積算値が前記制限値を超えた場合は、エラーを発生するステップと、を有することを特徴とする。
【００２８】
上記メモリ管理方法において、前記バンドルあるいは前記ソフトウェアプラットフォームのクラスローダオブジェクトがメモリを要求したときに、メモリを要求した前記バンドルあるいは前記ソフトウェアプラットフォームの呼び出し元を辿り、最初の呼び出し元となるバンドルあるいは前記ソフトウェアプラットフォームが属するグループを要求メモリ量のカウント先として選択することを特徴とする。
【００２９】
上記メモリ管理方法において、前記バンドルあるいは前記ソフトウェアプラットフォームのクラスローダオブジェクトがメモリを要求したときに、メモリを要求した前記バンドルあるいは前記ソフトウェアプラットフォームの呼び出し元を辿り、前記ソフトウェアプラットフォームに呼び出されたバンドルが属するグループを要求メモリ量のカウント先として選択することを特徴とする。
【００３０】
上記メモリ管理方法において、前記バンドルに機能提供フラグあるいは機能利用フラグを設定しておき、前記バンドルあるいは前記ソフトウェアプラットフォームのクラスローダオブジェクトがメモリを要求したときに、メモリを要求した前記バンドルあるいは前記ソフトウェアプラットフォームの呼び出し元を辿り、前記ソフトウェアプラットフォームに呼び出されたバンドルが属するグループ、又は、機能利用フラグが設定されたバンドルが属するグループを要求メモリ量のカウント先として選択することを特徴とする。
【００３１】
上記メモリ管理方法において、前記バンドルあるいは前記ソフトウェアプラットフォームがスレッドを立てるときに、当該スレッドを立てる前記バンドルあるいは前記ソフトウェアプラットフォームの属するグループを当該スレッドに設定しておき、前記バンドルあるいは前記ソフトウェアプラットフォームのクラスローダオブジェクトがメモリを要求したときに、メモリを要求した前記バンドルあるいは前記ソフトウェアプラットフォームが属するスレッドに設定されたグループを要求メモリ量のカウント先として選択することを特徴とする。
【００３２】
上記メモリ管理方法において、メモリが要求されて生成されたオブジェクトに、当該メモリの消費量のカウント先として選択されたグループを識別するグループＩＤを付与するステップと、指定されたグループＩＤが付与された前記オブジェクトのサイズを合計し、当該グループＩＤが示すグループのメモリ消費量を求めるステップと、を有することを特徴とする。
【００３３】
第３の本発明に係るメモリ管理プログラムは、上記メモリ管理方法の各ステップをコンピュータに実行させることを特徴とする。
【発明の効果】
【００３４】
本発明によれば、メモリ消費量を任意の単位で制限することができる。
【図面の簡単な説明】
【００３５】
【図１】本実施の形態におけるメモリ管理装置の構成を示す図である。
【図２】象限ａ〜ｄの呼び出し関係を示す表である。
【図３】グループ選択アルゴリズム説明時に参照されるスタックの例を示す図である。
【図４】第１グループ選択アルゴリズムの動作を示すフローチャートである。
【図５】第１グループ選択アルゴリズム実行時の各スタックのリソース消費量の割り当て状況を示す図である。
【図６】第２グループ選択アルゴリズムの動作を示すフローチャートである。
【図７】第２グループ選択アルゴリズム実行時の各スタックのリソース消費量の割り当て状況を示す図である。
【図８】第３グループ選択アルゴリズムの動作を示すフローチャートである。
【図９】象限ａ〜ｄの呼び出し関係とメモリ消費量のカウント先を示す表である。
【図１０】第３グループ選択アルゴリズム実行時の各スタックのリソース消費量の割り当て状況を示す図である。
【図１１】第４グループ選択アルゴリズムの動作を示すフローチャートである。
【図１２】象限ａ〜ｄの呼び出し関係とメモリ消費量のカウント先を示す表である。
【図１３】第４グループ選択アルゴリズム実行時の各スタックのリソース消費量の割り当て状況を示す図である。
【図１４】ＰＦセットの呼び出し関数の一例を示す図である。
【図１５】第５グループ選択アルゴリズムの動作を示すフローチャートである。
【図１６】ＯＳＧｉのシステムアーキテクチャを示す図である。
【図１７】ＯＳＧｉサービスによるバンドル間の連携を示す図である。
【図１８】バンドル機能の提供・利用を示す図である。
【図１９】バンドル機能の利用・提供を示す図である。
【図２０】メモリ割当を説明する図である。
【図２１】ＪａｖａＶＭのスタック構造を説明する図である。
【発明を実施するための形態】
【００３６】
以下、本発明を実施する一実施の形態について図面を用いて説明する。但し、本発明は多くの異なる様態で実施することが可能であり、本実施の形態の記載内容に限定して解釈すべきではない。
【００３７】
〔メモリ管理装置の構成について〕
まず、本実施の形態におけるメモリ管理装置１の構成について説明する。
【００３８】
図１は、メモリ管理装置１の構成を示す図である。メモリ管理装置１は、演算処理装置、記憶装置等を備えたコンピュータにより構成して、各部の処理がプログラムによって実行されるものとする。このプログラムはメモリ管理装置１が備える記憶装置に記憶されており、磁気ディスク、光ディスク、半導体メモリ等の記録媒体に記録することも、ネットワークを通して提供することも可能である。
【００３９】
本実施の形態におけるメモリ管理装置１は、ＯＳ上で動作するＪａｖａＶＭ１０と、ＪａｖａＶＭ１０上でバンドルの実行環境を提供するＯＳＧｉＦＷ１１と、ＯＳＧｉＦＷ１１上でＪａｖａプログラムとして動作するリソース管理バンドル１２ａとで構成され、ＪａｖａＶＭ１０とＯＳＧｉＦＷ１１で構成されたソフトウェアプラットフォーム上で動作するバンドルが利用（確保・消費）するリソースを管理する装置である。
【００４０】
ＰＦ事業者が作成するバンドルをオーナーバンドル１２とし、ＳＰ事業者がサービスを提供するために作成するバンドルをＳＰバンドル１３１とする。また、１以上のバンドルで構成されるバンドル群をバンドルセットとし、ＳＰ事業者が作成するバンドルセットをＳＰバンドルセット１３、ＰＦ事業者がプラットフォームシステムとして作成する、ＪａｖａＶＭ１０、ＯＳＧｉＦＷ１１、およびオーナーバンドル１２をＰＦセット１４とする。ＰＦセット１４は本実施の形態において１つであり、ＳＰバンドルセット１３は複数考えられる。
【００４１】
ＪａｖａＶＭ１０は、ＯＳから受け取ったリソースを用いて、ＯＳＧｉＦＷ１１、オーナーバンドル１２、およびＳＰバンドル１３１などのソフトウェアを動作させる。本実施の形態におけるＪａｖａＶＭ１０は、独自の改造部を有し、ソフトウェアを動作させるにあたって、リソースを管理する単位であるグループを作成してグループＩＤを付与し、グループ毎にメモリ消費量の制限値を設定してメモリ消費量を管理する。
【００４２】
また、クラスローダオブジェクトによりクラスがロードされてオブジェクトが生成される際に割り当てられるメモリをどのグループのメモリ消費量としてカウントするかを判定し、メモリ消費量をカウントするグループのメモリ消費量の合計が制限値を超えた場合にはエラーを発生させる。割り当てるメモリの消費量をどのグループのメモリ消費量としてカウントするかを判定するグループ選択アルゴリズムは任意に定めることができる。グループ選択アルゴリズムを変えることによって、どの単位でメモリ消費量を制限できるかが変化する。グループ選択アルゴリズムの具体例については後述する。
【００４３】
これらの機能を実現するために、ＪａｖａＶＭ１０は、クラスローダオブジェクトにグループＩＤを設定できるデータ構造、オブジェクト毎に、そのオブジェクトが属するグループＩＤを保持するデータ構造、および、グループ毎に、そのグループのメモリ消費量としてカウントされたメモリ消費量を合計したメモリ消費量積算値とそのグループに設定されたメモリ消費量の制限値を保持する領域を持つ。また、ＪａｖａＶＭ１０は、これらを設定するためのＡＰＩを備える。
【００４４】
ＯＳＧｉＦＷ１１は、バンドルのインストール、バンドル間の連携機能などをサポートする。本実施の形態におけるＯＳＧｉＦＷ１１は、ＳＰバンドル１３１がインストールされた際に、リソース管理バンドル１２ａに対してＲｅｓｏｌｖｅｄイベントを一番最初にコールバックする独自の改造部を有する。
【００４５】
リソース管理バンドル１２ａは、オーナーバンドル１２の一つであり、ＳＰバンドルセット１３毎にグループＩＤを割り振ってメモリ消費量の制限値をＪａｖａＶＭ１０に設定し、ＳＰバンドル１３１がインストールされた際に、インストールされたＳＰバンドル１３１のクラスローダオブジェクトにグループＩＤを設定する。具体的には、リソース管理バンドル１２ａは、１つのＳＰバンドルセット１３を構成するＳＰバンドル１３１の情報（以下、「バンドルセット情報」と称する）とＳＰバンドルセット１３に利用許可されるメモリ量（以下、「バンドルセットメモリ量」と称する）を入手し、入手したバンドルセット情報にＪａｖａＶＭ１０から得たグループＩＤを関連付け、グループＩＤとバンドルセットメモリ量をＪａｖａＶＭ１０に対して通知し、バンドルセットメモリ量をそのグループのメモリ消費量の制限値として設定する。
【００４６】
また、ＳＰバンドル１３１がインストールされてリソース管理バンドル１２ａがＲｅｓｏｌｖｅｄイベントを受信した際に、インストールされたＳＰバンドル１３１のクラスローダオブジェクトをＪａｖａ／ＯＳＧｉの標準ＡＰＩを通じて取得し、ＳＰバンドル１３１のクラスローダオブジェクトとそのＳＰバンドル１３１が属するＳＰバンドルセット１３に関連付けたグループＩＤを組みにした情報をＪａｖａＶＭ１０に通知し、ＳＰバンドル１３１のクラスローダオブジェクトにグループＩＤを設定する。
【００４７】
バンドルセット情報とは、ＯＳＧｉ仕様で定められるＢｕｎｄｌｅ−ＳｙｍｂｏｌｉｃＮａｍｅとＢｕｎｄｌｅ−Ｖｅｒｓｉｏｎとによってバンドルを一意に識別した識別子であり、識別したＳＰバンドル１３１が１つ以上指定される。バンドルセット情報とバンドルセットメモリ量は、メモリ管理装置１とは別装置として外部に設置されたサーバ３から入手する。バンドルセット情報等の受け渡しはＸＭＬファイル等の様々な方法が考えられる。なお、バンドルセット情報等については、メモリ管理装置１自身の記憶手段に予め保持しておいてもよい。
【００４８】
〔メモリ管理装置の動作について〕
次に、メモリ管理装置１の動作について説明する。
【００４９】
以下、メモリ管理装置１が行う、リソースを管理する単位であるグループを作成してグループ毎にメモリ消費量の制限値を設定する処理と、クラスをロードしてオブジェクトを生成する際にメモリを割り当てる処理について説明する。
【００５０】
まず、グループを作成してグループ毎にメモリ消費量の制限値を設定する処理について説明する。
【００５１】
リソース管理バンドル１２ａは、通信ネットワークを介して接続された外部のサーバ３から、バンドルセット情報とバンドルセットメモリ量とを取得しておく。
【００５２】
ＳＰバンドル１３１がＯＳＧｉＦＷ１１にインストールされ、リソース管理バンドル１２ａがＯＳＧｉＦＷ１１からＲｅｓｏｌｖｅｄイベントを受信すると、インストールされたＳＰバンドル１３１の属するＳＰバンドルセット１３に関連付けるグループＩＤをＪａｖａＶＭ１０から取得する。このとき、ＪａｖａＶＭ１０は、新規にグループを作成してグループＩＤを付与し、グループＩＤをリソース管理バンドル１２ａに返信する。
【００５３】
そして、リソース管理バンドル１２ａは、インストールされたＳＰバンドル１３１のクラスローダオブジェクトを取得し、取得したクラスローダオブジェクトと上記のグループＩＤをＪａｖａＶＭ１０に通知する。ＪａｖａＶＭ１０は、通知されたクラスローダオブジェクトにグループＩＤを設定する。
【００５４】
また、リソース管理バンドル１２ａは、上記のグループＩＤとインストールされたＳＰバンドル１３１のＳＰバンドルセット１３のバンドルセットメモリ量をＪａｖａＶＭ１０に通知する。ＪａｖａＶＭ１０は、通知されたグループＩＤに通知されたバンドルセットメモリ量をメモリ消費量の制限値として設定する。
【００５５】
ＯＳＧｉＦＷ１１は、ＳＰバンドル１３１がインストールされた際、一番最初にリソース管理バンドル１２ａをコールバックするので、インストールされたＳＰバンドル１３１がリソース確保を行う前にグループＩＤを設定できる。
【００５６】
続いて、生成されるオブジェクトにメモリを割り当てる処理について説明する。
【００５７】
クラスローダオブジェクトによりクラスがロードされてオブジェクトが生成されるときには、後述するグループ選択アルゴリズムによって、オブジェクトの呼び出し関係に基づいてグループが選択され、生成されるオブジェクトにグループＩＤが設定される。オブジェクトを生成するために必要なメモリを割り当てる際に、設定されたグループＩＤについて、そのグループのメモリ消費量の合計が制限値を超えないかチェックを行う。以下、メモリ消費量のチェックの方法について説明する。
【００５８】
選択されたグループのメモリ消費量積算値に生成されるオブジェクトのサイズを加算した値が、グループのメモリ消費量の制限値以下の場合は、メモリの割り当ては成功とし、メモリ消費量積算値にオブジェクトのサイズを加算してメモリ消費量積算値を更新し、ヒープ領域からオブジェクトのサイズ分のメモリを割り当ててオブジェクトを生成する。
【００５９】
選択されたグループのメモリ消費量積算値に生成されるオブジェクトのサイズを加算した値が、グループのメモリ消費量の制限値より大きい場合は、ＧＣを実行し、参照されていないオブジェクトのメモリを解放した後、選択されたグループのＧＣ後のメモリ消費量積算値に生成されるオブジェクトのサイズを加算してメモリを割り当てるか否か判定する。ＧＣを実行してもメモリ消費量積算値にオブジェクトのサイズを加算した値がメモリ消費量の制限値を超える場合は、ＯＯＭエラーを発生させる。メモリ消費量積算値にオブジェクトのサイズを加算した値がメモリ消費量の制限値以下の場合は、メモリの割り当ては成功とし、ＧＣ後のメモリ消費量積算値にオブジェクトのサイズを加算してメモリ消費量積算値を更新し、ヒープ領域からオブジェクトのサイズ分のメモリを割り当ててオブジェクトを生成する。
【００６０】
以上説明したように、本実施の形態によれば、１以上のＳＰバンドル１３１で構成されるバンドル群をＳＰバンドルセット１３とし、ＳＰバンドルセット１３毎にグループを構成してグループＩＤを付与し、グループ毎にメモリ消費量積算値をカウントするとともに、グループ毎にメモリ消費量の制限値を設定することにより、グループ毎にメモリ消費量を任意の単位で制限することが可能となる。
【００６１】
グループ毎のメモリ消費量の制限を値ではなく、実際にグループ毎にヒープ領域を分割して複数保持する方法も考えられる。しかしながら、この方法では、グループ毎のヒープ領域の割り当てサイズを変更する際にヒープ領域の再構成が必要となり、既にヒープ領域に確保したオブジェクトの移動が発生する可能性がある。そのため、ＪａｖａＶＭ起動中に柔軟に分割したヒープ領域を変更することは困難である。本実施の形態では、グループ毎のメモリ消費量の制限を制限値として単に値で保持しているので、メモリ割り当て時にメモリ消費量が制限値を超えるか否か参照するだけで済み、さらに、ヒープ領域に確保したオブジェクトの移動を発生させることなく、グループ毎の制限値を柔軟に変更することができる。
【００６２】
なお、上記では、ＳＰバンドルセット１３のメモリ消費量を制限することについて説明したが、もちろんＰＦセット１４にも同様にグループＩＤを付与してメモリ消費量を制限することも可能である。
【００６３】
また、上記では、ＳＰバンドル１３１について説明したが、オーナーバンドル１２がインストールされた場合についても同様に適用可能である。
【００６４】
〔グループ選択アルゴリズム〕
次に、グループ選択アルゴリズムについて説明する。
【００６５】
メモリの割り当てを行う際、割り当てるメモリの消費量をカウントするグループを選択するアルゴリズムを変えることによって、どの単位（例えば、スレッド単位、バンドル単位など）でメモリ消費量を制限できるかが変化することになる。本実施の形態では、一例として、４つのグループ選択アルゴリズムについて説明する。
【００６６】
ここで、ＰＦセットとＳＰバンドルセットとの関係性を考える。ＰＦセットとＳＰバンドルセットとのどちらがクラス提供側・呼び出し元になるのかは、以下の４通り（２×２通り）が考えられる。
【００６７】
象限ａ）クラス提供側：ＰＦセット  呼び出し元  ：ＰＦセット
象限ｂ）クラス提供側：ＰＦセット  呼び出し元  ：ＳＰバンドルセットＹ
象限ｃ）クラス提供側：ＳＰバンドルセットＸ  呼び出し元  ：ＰＦセット
象限ｄ）クラス提供側：ＳＰバンドルセットＸ  呼び出し元  ：ＳＰバンドルセットＹ
なお、象限ｂと象限ｃについては、ＰＦセットにとってはいずれもＳＰバンドルセットであるので、ＳＰバンドルセットはＳＰバンドルセットＸ（ＳＰ＿Ｘ）でもＳＰバンドルセットＹ（ＳＰ＿Ｙ）でも良いが、ここではクラス提供側をＳＰ＿Ｘ、呼び出し元をＳＰ＿Ｙとして便宜上区別している。
【００６８】
図２は、上記の各象限について呼び出し関係を示す表である。表の内部は、呼び出し元のスタックとクラス提供側のスタックを表しており、下の枠が呼び出し元のスタック、上の枠がクラス提供側のスタックを示す。
【００６９】
図３は、後述するグループ選択アルゴリズムの説明時に参照されるスタックの例を示す図であり、ＪａｖａＶＭ１０が実行するあるスレッドについて、一番下のスタックをスタック［０］のＰＦセットのスタックとして積み重なった様子を示す。図３中の枠内の数字が各スタックの番号を示し、番号順に呼び出されたものである。また、枠内の文字が各スタックを作成したクラスの提供元を示す。図３中の枠外の上向き矢印は、呼び出しの流れを示し、矢印横のａ〜ｄは、呼び出し関係がどの象限に該当するのかを示している。例えば、スタック［０］のＰＦセットのクラスがスタック［１］のＳＰバンドルセット１（以下、「ＳＰ＿ＢＳ１」と称する）のクラスを呼び出している。この場合、ＰＦセットが呼び出し元でＳＰ＿ＢＳ１がクラス提供側となるので、象限ｃに該当する。なお、後述の具体例では、図３の枠外右側の○印から矢印を延ばしてメモリ消費量のカウント先を示す。
【００７０】
以下、グループ選択アルゴリズムを説明する前に、用語の定義を行う。定数を大文字、変数の頭文字は小文字で表す。ここでの定数は、１回のグループ選択アルゴリズムの処理において変化しない値を指す。グループＩＤを意味する定数としては、ＰＦセットのクラスローダオブジェクトに設定されているグループＩＤを示すＧＲＯＵＰＩＤ＿ＰＦ、各スタックにて処理が行われるクラスのクラスローダオブジェクトに設定されているグループＩＤを示すＳＴＡＣＫ＿ＧＲＯＵＰＩＤがある。グループＩＤを代入する変数としては、最終的にメモリ消費量をカウントするグループを示す変数ｇｒｏｕｐＩＤ、ｇｒｏｕｐＩＤを決定するために一時的に利用するｃｕｒＧｒｏｕｐＩＤがある。また、各スレッドの一番上のスタックをＴＯＰＳＴＡＣＫとし、呼び出し元として処理中のスタックを指す変数をｃｕｒＳｔａｃｋとする。以下で説明するグループ選択アルゴリズムは、ｃｕｒＳｔａｃｋをＴＯＰＳＴＡＣＫから順に下まで辿って処理を行うが、一番下のスタック［０］の次を指定した場合、ｃｕｒＳｔａｃｋはＮｕｌｌを指すものとする。
【００７１】
メモリの割り当てはスレッドの一番上のスタックで実行されるので、グループ選択アルゴリズムは、常にＴＯＰＳＴＡＣＫにおいてメモリの割り当てが必要となる度に実行される。
【００７２】
以下、各グループ選択アルゴリズムについて説明する。なお、以下説明する全てのグループ選択アルゴリズムの主体は、ＪａｖａＶＭ１０である。
【００７３】
＜第１グループ選択アルゴリズム＞
第１グループ選択アルゴリズムの動作を示すフローチャートを図４に示す。
【００７４】
第１グループ選択アルゴリズムでは、ＴＯＰＳＴＡＣＫのＳＴＡＣＫ＿ＧＲＯＵＰＩＤをｇｒｏｕｐＩＤとする（Ｓ１０１）。
【００７５】
すなわち、図５に示すように、各スタックのクラスのメモリ消費量を、各スタックのクラスに対してそれぞれ設定されたグループでカウントする。
【００７６】
以上より、各スタックのクラスのメモリ消費量を、各スタックのクラスに対してそれぞれ設定されたグループに割り当てるので、呼び出し元に関わらず、実装クラスのセット（ＰＦセットやＳＰバンドルセット）単位でメモリ消費量を制限できる。
【００７７】
＜第２グループ選択アルゴリズム＞
第２グループ選択アルゴリズムの動作を示すフローチャートを図６に示す。第２グループ選択アルゴリズムは、スタックを１つずつ下に辿り、最初の呼び出し元となるスタックを探索するアルゴリズムである。
【００７８】
ｃｕｒＳｔａｃｋにＴＯＰＳＴＡＣＫを代入し（Ｓ２０１）、ｃｕｒＳｔａｃｋが一番下のスタックを指すまで、ｃｕｒＳｔａｃｋを１つずつ下のスタックにずらしていく（Ｓ２０２，Ｓ２０３）。
【００７９】
そして、ｃｕｒＳｔａｃｋのＳＴＡＣＫ＿ＧＲＯＵＰＩＤをｇｒｏｕｐＩＤとする（Ｓ２０４）。
【００８０】
すなわち、全てのスタックのメモリ消費量を、最初に呼び出しを行ったスタック［０］のクラスに対して設定されたグループに割り当てるようにしている。
【００８１】
図７に、第２グループ選択アルゴリズムを実行した際の各スタックのメモリ消費量の割り当て状況を示す。図７に示すように、あるスレッドの全てのスタックのメモリ消費量は、一番下のスタック［０］に割り当てられる。ここで、スタック［６］のメモリ消費量がどのようにカウントされるかを説明する。スタック［６］を呼び出したのはスタック［５］であり、スタック［５］を呼び出したのはスタック［４］である。スタック［４］を呼び出したのはスタック［３］であり、スタック［３］を呼び出したのはスタック［２］である。スタック［２］を呼び出したのはスタック［１］であり、スタック［１］を呼び出したのはスタック［０］である。スタック［０］には呼び出し元がないため、結果的にスタック［６］のメモリ消費量は、スタック［０］のＰＦセットのメモリ消費量としてカウントされる。スタック［６］の処理が行われた後、スタック［６］はスレッドからなくなりスタック［５］がＴＯＰＳＴＡＣＫになる。スタック［５］〜［０］でも同様の処理が行われるので、全て、スタック［０］のＰＦセットのメモリ消費量としてカウントされる。
【００８２】
以上より、全てのスタックのクラスのメモリ消費量を、最初に呼び出しを行ったスタックのクラスに対して設定されたグループに割り当てるので、ソース消費量をスレッド単位で制限できる。
【００８３】
＜第３グループ選択アルゴリズム＞
第３グループ選択アルゴリズムの動作を示すフローチャートを図８に示す。第３グループ選択アルゴリズムは、ＴＯＰＳＴＡＣＫでメモリが要求されるたびに、要求されたメモリ消費量を割り当てるグループを選択する。
【００８４】
まず、初期値として、ｇｒｏｕｐＩＤにＧＲＯＵＰＩＤ＿ＰＦを代入し（Ｓ３０１）、ｃｕｒＳｔａｃｋにＴＯＰＳＴＡＣＫを代入して以下の処理を行う（Ｓ３０２）。
【００８５】
ｃｕｒＧｒｏｕｐＩＤにｃｕｒＳｔａｃｋの指すスタックのグループＩＤを代入する（Ｓ３０３）。
【００８６】
ｃｕｒＧｒｏｕｐＩＤがＧＲＯＵＰＩＤ＿ＰＦであって（Ｓ３０４のＹＥＳ）、ｇｒｏｕｐＩＤがＧＲＯＵＰＩＤ＿ＰＦでない場合（Ｓ３０５のＮＯ）、つまり、呼び出し元がＰＦセットでクラス提供側がＳＰバンドルセットの象限ｃの場合は、そのときのｇｒｏｕｐＩＤの値、つまり、クラス提供側のスタックのＳＰバンドルセットのグループを選択されたグループとして処理を終了する。
【００８７】
ｃｕｒＧｒｏｕｐＩＤがＧＲＯＵＰＩＤ＿ＰＦでない場合（Ｓ３０４のＮＯ）、あるいは、ｃｕｒＧｒｏｕｐＩＤがＧＲＯＵＰＩＤ＿ＰＦであって（Ｓ３０４のＹＥＳ）、ｇｒｏｕｐＩＤがＧＲＯＵＰＩＤ＿ＰＦである場合（Ｓ３０５のＹＥＳ）、つまり、象限ａ，ｂ，ｄの場合は、ｇｒｏｕｐＩＤにｃｕｒＧｒｏｕｐＩＤの値を代入し（Ｓ３０６）、ｃｕｒＳｔａｃｋが指すスタックを一つ下げる（Ｓ３０７）。
【００８８】
そして、ｃｕｒＳｔａｃｋがＮｕｌｌでなければＳ３０３に戻り（Ｓ３０８のＮＯ）、ｃｕｒＳｔａｃｋがＮｕｌｌであれば（Ｓ３０８のＹＥＳ）、そのときにｇｒｏｕｐＩＤの値を選択されたグループとして処理するを終了する。
【００８９】
システムの基盤となるＰＦセットが、ＳＰバンドルセットを利用することによってＰＦセットのための機能を実現することはあり得ない。それ故に、機能を提供するＰＦセットのメモリ消費量を、機能を利用するＳＰバンドルセットに対して設定されたグループに割り当てる。つまり、機能提供者であるＰＦ事業者によって生成されたＰＦセットと、機能利用者であるＳＰ事業者によって生成されたＳＰバンドルセット間の関係において、ＰＦセットのメモリ消費量は呼び出し元・クラス提供側に関わらず、機能を利用しているＳＰバンドルセットのメモリ消費量としてカウントする。
【００９０】
例えば、ＳＰバンドルセットがＰＦセットを呼び出す象限ｂの例としては、、ＰＦセットがＨｔｔｐＳｅｒｖｉｃｅを実装したバンドルを提供し、ＳＰバンドルセットがＨｔｔｐＳｅｒｖｉｃｅを取得して呼び出すことにより、ＰＦセットの提供するＨｔｔｐＳｅｒｖｉｃｅの機能を利用する例が考えられる。
【００９１】
また、ＰＦセットがＳＰバンドルセットを呼び出す象限ｃの例としては、ＯＳＧｉ仕様で定義されるＢｕｎｄｌｅＡｃｔｉｖａｔｏｒ＃ｓｔａｒｔの呼び出しがある。呼び出すのはＯＳＧｉＦＷ、つまりＰＦセットであるが、ＳＰバンドルセットがクラス提供した理由は、ＰＦセットが提供する「ＳＰバンドルを対象端末上で起動する機能」を利用する為である。どのような場合においても、象限ｃは、背景技術で説明した通りコールバック型、つまりクラス提供側であるＳＰバンドルセットが機能を利用する形となる。
【００９２】
なお、象限ａや象限ｄ、つまりＰＦセットがＰＦセットを呼び出した場合や、ＳＰバンドルセットがＳＰバンドルセットを呼び出した場合は、機能の提供利用によらず、呼び出したＳＰバンドルセットのメモリ消費量としてカウントする。
【００９３】
呼び出し元・クラス提供側のスタックの関係を表すと、図９に示すようになる。この図は、２つのスタックの関係において、上のクラス提供側のスタックのメモリ消費量が、どちらのスタックにおいてカウントされるかを示している。○印から延びる矢印の先がメモリ消費量がカウントされるスタックを示している。同図に示すように、メモリ消費量の割り当て先は、象限ｃでは上のクラス提供側のスタック、象限ａ，ｂ，ｄでは下の呼び出し元のスタックとなっている。
【００９４】
図１０に、第３グループ選択アルゴリズムを実行した際の各スタックのメモリ消費量の割り当て状況を示す。以下、各スタックのメモリ消費量がどのようにカウントされるのかを説明する。
【００９５】
まず、ＰＦセットであるスタック［６］のメモリ消費量は、呼び出し元のスタック［５］がＳＰ＿ＢＳ１なので、呼び出し元のスタック［５］のメモリ消費量としてカウントされる（象限ｂ）。
【００９６】
ＳＰ＿ＢＳ１であるスタック［５］のメモリ消費量は、呼び出し元のスタック［４］がＳＰ＿ＢＳ２なので、呼び出し元のスタック［４］のメモリ消費量としてカウントされる（象限ｄ）。
【００９７】
スタック［４］のメモリ消費量は、呼び出元のスタック［３］がＰＦセットなので、クラス提供側のスタック［４］のメモリ消費量としてカウントされる（象限ｃ）。
【００９８】
よって、スタック［４］〜［６］におけるメモリ消費量は、スタック［４］つまりＳＰ＿ＢＳ２のメモリ消費量としてカウントされる。
【００９９】
同様に、スタック［３］のメモリ消費量は、呼び出し元のスタック［２］がＰＦセットなので、呼び出し元のスタック［２］のメモリ消費量としてカウントとされる（象限ａ）。
【０１００】
スタック［２］のメモリ消費量は、呼び出し元のスタック［１］がＳＰ＿ＢＳ１なので、呼び出し元のスタック［１］のメモリ消費量としてカウントとされる（象限ｂ）。
【０１０１】
スタック［１］のメモリ消費量は、呼び出し元のスタック［０］がＰＦセットなので、クラス提供側のスタック［１］のメモリ消費量としてカウントされる（象限ｃ）。
【０１０２】
よって、スタック［１］〜［３］におけるメモリ消費量は、スタック［１］つまりＳＰ＿ＢＳ１のメモリ消費量としてカウントされる。
【０１０３】
最後に、スタック［０］のメモリ消費量は、呼び出し元のスタックが存在しないので、スタック［０］つまりＰＦセットのメモリ消費量としてカウントとされる。
【０１０４】
以上より、機能を提供するＰＦセットのメモリ消費量を、機能を利用するＳＰバンドルセットに対して設定されたグループに割り当てるので、機能を利用するバンドルセット単位でメモリ消費量を制限できる。
【０１０５】
＜第４グループ選択アルゴリズム＞
第３グループ選択アルゴリズムでは、機能の提供・利用の関係について、機能を提供するのはＰＦセットと機能を利用するのはＳＰバンドルセットとしてグループを選択した。一方、機能の提供・利用の関係はＳＰバンドルセット同士にもあるため、第４グループ選択アルゴリズムではＳＰバンドルセット同士の機能の提供・利用の関係を考慮する。
【０１０６】
第４グループ選択アルゴリズムの動作を示すフローチャートを図１１に示す。第４グループ選択アルゴリズムは、ＴＯＰＳＴＡＣＫでメモリが要求されるたびに、要求されたメモリ消費量を割り当てるグループを選択する。
【０１０７】
なお、第４グループ選択アルゴリズムを用いるにあたり、ＪａｖａＶＭ１０は、クラスローダオブジェクトのデータ構造にＣＴＦ（Ｃｌａｓｓ  Ｔｙｐｅ  Ｆｌａｇ：クラスが「機能提供」か「機能利用」を示すフラグ）を設定できるデータ構造を用意し、指定されたクラスローダオブジェクトのデータ構造に指定されたＣＴＦを設定する機能を有する。特に指定のない場合、ＰＦセットのクラスローダオブジェクトのＣＴＦは「機能利用」とする。以下では、ＣＵＲ＿ＣＴＦはｃｕｒＳｔａｃｋのクラスのＣＴＦを表し、ｌａｓｔ＿ＣＴＦには、初期値以外では、ｃｕｒＳｔａｃｋより上のスタックで、一番ｃｕｒＳｔａｃｋに近いＳＰバンドルセットのスタックに付与されているＣＴＦが代入される。また、ｇｒｏｕｐＩＤには、初期値以外では、ｃｕｒＳｔａｃｋより上のスタックで、一番ｃｕｒＳｔａｃｋに近いＳＰバンドルセットに設定されたグループＩＤが代入される。
【０１０８】
まず、初期値として、ｇｒｏｕｐＩＤにＧＲＯＵＰＩＤ＿ＰＦを代入し（Ｓ４０１）、ｃｕｒＳｔａｃｋにＴＯＰＳＴＡＣＫを代入して以下の処理を行う（Ｓ４０２）。
【０１０９】
ｌａｓｔ＿ＣＴＦに「機能提供」を代入し（Ｓ４０３）、ｃｕｒＧｒｏｕｐＩＤにｃｕｒＳｔａｃｋの指すスタックのグループＩＤを代入する（Ｓ４０４）。
【０１１０】
ｃｕｒＧｒｏｕｐＩＤがＧＲＯＵＰＩＤ＿ＰＦである場合に（Ｓ４０５のＹＥＳ）、ｃｕｒＧｒｏｕｐＩＤがｇｒｏｕｐＩＤと異なり（Ｓ４０６のＮＯ）、ＣＵＲ＿ＣＴＦが「機能利用」である場合は（Ｓ４０７のＹＥＳ）、そのときのｇｒｏｕｐＩＤの値を選択されたグループとして処理を終了する。一方、ｃｕｒＧｒｏｕｐＩＤがｇｒｏｕｐＩＤと同じであるか（Ｓ４０６のＹＥＳ）、ＣＵＲ＿ＣＴＦが「機能利用」でない場合は（Ｓ４０７のＮＯ）、Ｓ４１２に進み、１つ下のスタックについて処理を続ける。
【０１１１】
ｃｕｒＧｒｏｕｐＩＤがＧＲＯＵＰＩＤ＿ＰＦでない場合に（Ｓ４０５のＮＯ）、ｃｕｒＧｒｏｕｐＩＤがｇｒｏｕｐＩＤと異なり（Ｓ４０８のＮＯ）、ｌａｓｔ＿ＣＴＦが「機能利用」である場合は（Ｓ４０９のＹＥＳ）、そのときのｇｒｏｕｐＩＤの値を選択されたグループとして処理を終了する。一方、ｃｕｒＧｒｏｕｐＩＤがｇｒｏｕｐＩＤと同じであるか（Ｓ４０８のＹＥＳ）、ｌａｓｔ＿ＣＴＦが「機能利用」でない場合は（Ｓ４０９のＮＯ）、ｇｒｏｕｐＩＤ、ｌａｓｔ＿ＣＴＦを更新して（Ｓ４１０，Ｓ４１１）、Ｓ４１２に進み、１つ下のスタックについて処理を続ける。なお、ｃｕｒＧｒｏｕｐＩＤがｇｒｏｕｐＩＤと同じ場合は（Ｓ４０８のＹＥＳ）、Ｓ４１０でｇｒｏｕｐＩＤを更新する必要がないのでＳ４１１に進む。
【０１１２】
１つ下のスタックについて処理を続ける場合、ｃｕｒＳｔａｃｋが指すスタックを１つ下げて（Ｓ４１２）、ｃｕｒＳｔａｃｋがＮｕｌｌでなければＳ４０４に戻り（Ｓ４１３のＮＯ）、ｃｕｒＳｔａｃｋがＮｕｌｌであれば（Ｓ４１３のＹＥＳ）、そのときのｇｒｏｕｐＩＤの値を選択されたグループとして処理を終了する。
【０１１３】
各象限の呼び出し関係とメモリ消費量のカウント先を示すと、図１２に示すようになる。第３グループ選択アルゴリズムとは、象限ｄ、つまり、ＳＰバンドルセットがＳＰバンドルセットを呼び出した際のメモリ消費量の割り当て先が異なる。第４グループ選択アルゴリズムでは、呼び出し元・クラス提供側のスタックの関係が象限ｄの場合、クラス提供側のスタックのＣＴＦの値によってメモリ消費量の割り当て先が変わる。具体的には、クラス提供側のスタックのＣＴＦが「機能利用」である場合（象限ｄの左側）、クラス提供側のスタックにメモリ消費量が割り当てられ、クラス提供側のスタックのＣＴＦが「機能提供」である場合（象限ｄの右側）、呼び出し元のスタックにメモリ消費量が割り当てられる。
【０１１４】
図１３に、第４グループ選択アルゴリズムを実行した際の各スタックのメモリ消費量の割り当て状況を示す。図１３（ａ）は、スタック［５］が機能利用クラスであった場合の割り当て状況であり、図１３（ｂ）は、スタック［５］が機能提供クラスであった場合の割り当て状況である。
【０１１５】
まず、スタック［５］が機能利用クラスである図１３（ａ）においてどのようにカウントされるかを説明する。
【０１１６】
ＰＦセットであるスタック［６］のメモリ消費量は、呼び出し元のスタック［５］がＳＰ＿ＢＳ１なので、呼び出し元のスタック［５］のメモリ消費量としてカウントされる（象限ｂ）。
【０１１７】
ＳＰ＿ＢＳ１であるスタック［５］のメモリ消費量は、呼び出し元のスタック［４］がＳＰ＿ＢＳ２であり、機能利用クラスであるので、クラス提供側のスタック［５］のメモリ消費量としてカウントされる（象限ｄ）。
【０１１８】
なお、スタック［４］〜スタック［０］については第３グループ選択アルゴリズムで説明した例と同様である。
【０１１９】
続いて、スタック［５］が機能提供クラスである図１３（ｂ）においてどのようにカウントされるかを説明する。
【０１２０】
ＰＦセットであるスタック［６］のメモリ消費量は、呼び出し元のスタック［５］がＳＰ＿ＢＳ１なので、呼び出し元のスタック［５］のメモリ消費量としてカウントされる（象限ｂ）。
【０１２１】
ＳＰ＿ＢＳ１であるスタック［５］のメモリ消費量は、呼び出し元のスタック［４］がＳＰ＿ＢＳ２であり、機能提供クラスであるので、呼び出し元のスタック［４］のメモリ消費量としてカウントされる（象限ｄ）。
【０１２２】
なお、スタック［４］〜スタック［０］については第３グループ選択アルゴリズムで説明した例と同様である。
【０１２３】
以上より、スタックの状況が象限ｄの場合に、機能を提供するＳＰバンドルセットのメモリ消費量を、機能を利用するＳＰバンドルセットのメモリ消費量としてカウントするので、第３グループ選択アルゴリズムの効果に加えて、ＳＰバンドルセット同士の呼び出しにおいても、機能の提供・利用によってリソース消費量のカウント先を変更できる。
【０１２４】
なお、上記の第４グループ選択アルゴリズムを実現するために、リソース管理バンドル１２ａおよびＪａｖａＶＭ１０に対して以下の機能を追加する。
【０１２５】
リソース管理バンドル１２ａは、ＳＰバンドル１３１のクラスが機能の提供・利用どちらを行うクラスかの情報をサーバ３等から入手し、ＪａｖａＶＭ１０に対して、ＳＰバンドル１３１のクラス毎にＣＴＦを設定する機能を有する。ＪａｖａＶＭ１０は、クラスローダオブジェクトにＣＴＦを設定できるデータ構造を用意し、クラスローダオブジェクトに指定されたＣＴＦを設定する機能を有する。
【０１２６】
以下、オブジェクトにＣＴＦを設定する処理について説明する。
【０１２７】
リソース管理バンドル１２ａは、バンドルセット情報とバンドルセットメモリ量に加えて、バンドルセット情報に含まれるＳＰバンドル１３１のクラスにセットするＣＴＦを取得しておく。
【０１２８】
ＳＰバンドル１３１がＯＳＧｉＦＷ１１にインストールされ、リソース管理バンドル１２ａがＯＳＧｉＦＷ１１からＲｅｓｏｌｖｅｄイベントを受信すると、インストールされたＳＰバンドル１３１の属するＳＰバンドルセット１３に関連付けるグループＩＤをＪａｖａＶＭ１０から取得する。続いて、インストールされたＳＰバンドル１３１のクラスローダオブジェクトを取得し、取得したクラスローダオブジェクトとグループＩＤをＪａｖａＶＭ１０に通知し、さらに、取得したクラスローダオブジェクトと該当するＣＴＦをＪａｖａＶＭ１０に通知する。ＪａｖａＶＭ１０は、通知されたクラスローダオブジェクトにグループＩＤ、ＣＴＦを設定する。
【０１２９】
以上説明したように、本実施の形態によれば、メモリ消費量をカウントするグループをグループ選択アルゴリズムに基づいて決定することにより、グループ選択アルゴリズムを変更することで、メモリ消費量を制限する単位を変更できる。具体的には、第１グループ選択アルゴリズムを用いた場合は、実装クラスのセット単位でメモリ消費量を制限でき、第２グループ選択アルゴリズムを用いた場合は、スレッド単位でメモリ消費量を制限できる。また、第３，４グループ選択アルゴリズムを用いた場合は、機能を利用するバンドルセット単位でメモリ消費量を制限できる。その結果、複数のＳＰ事業者が１つのシステムを共有して同時にサービスを提供するような場合において、協調して動作する種々のＳＰバンドルのメモリ消費量を、どのグループ（ＳＰ事業者）でカウントするかを柔軟に決定できる。
【０１３０】
また、グループ選択アルゴリズムは、スタックからポインタ参照で辿れる情報のみを利用しているので、メモリ割り当て時の速度低下を低減できる。
【０１３１】
〔メモリ消費量の計測について〕
次に、本実施の形態におけるメモリ管理装置１のメモリ消費量の計測方法について説明する。ＪａｖａＶＭ１０は、指定されたグループに割り当てられたメモリ消費量の合計を返す機能を有する。ＪａｖａＶＭ１０は、グループＩＤが指定されてそのグループのメモリ消費量の問い合わせがあると、まず、ＧＣを行う。あるいは、メモリ消費量の問い合わせの前に、問い合わせるプログラム側でＳｙｓｔｅｍ．ｇｃ（）などを用いてＧＣを行うものでもよい。ここでは、ＧＣは、グループＩＤ毎に行うか、ヒープ領域全体で行うかは問わない。
【０１３２】
ＧＣ後に、指定されたグループＩＤを持つＧＣ対象とならなかったオブジェクトのサイズを合計し、その合計値を指定されたグループのメモリ消費量として返却する。
【０１３３】
以上より、グループＩＤ単位でメモリ消費量を計測できる。
【０１３４】
〔グループの削除について〕
次に、グループの削除について説明する。ＪａｖａＶＭ１０は、指定されたグループＩＤに該当するグループを削除する機能を有する。
【０１３５】
ＪａｖａＶＭ１０は、削除対象のグループＩＤが指定されると、そのグループＩＤが付与されているオブジェクトに対する参照がなくなった時点で指定されたグループＩＤを削除する。これにより、グループの削除が可能となる。
【０１３６】
〔実施例〕
以下、本実施の形態におけるいくつかの実施例を説明する。
【０１３７】
＜ＰＦセットからＳＰバンドルセットへの呼び出しにおける実施例＞
第３，４グループ選択アルゴリズムにおいて、ＳＰバンドルセット１（以下、ＳＰ１）が、ＳＰバンドルセット２（以下、ＳＰ２）を呼び出す例を考える。
【０１３８】
ＳＰ２の内部でＰＦセットを呼び出すと、図１４に示すように、ＳＰバンドルがＰＦセットを呼び出した際、ＰＦセットの処理で再度ＳＰバンドルが呼び出される場合がある。このようなスタック構造になるＰＦセットのクラスには、例えばＡｃｃｅｓｓＣｏｎｔｒｏｌｌｅｒ．ｄｏＰｒｉｖｉｌｅｇｅｄ（）などがある。このようなクラスには、ＣＴＦを「機能提供」に設定し、第４グループ選択アルゴリズムを適用する。
【０１３９】
以上より、スタック［３］からスタック［４］への呼び出しは、第４グループ選択アルゴリズムにおいてはスタック［３］のＳＰ２のメモリ消費量とカウントされることになる。この例において、ＳＰ１がＳＰ２の機能を利用している場合には、スタック［２］〜スタック［４］の呼び出しは、ＳＰ１がＳＰ２の機能を利用するために行われていることになる。つまり、スタック［２］〜［４］に割り当てられたメモリは、機能を利用しているＳＰ１のメモリ消費量としてカウントされることが望ましく、それを実現することができる。
【０１４０】
＜ＰＦセットを詳細に分割する実施例＞
ブートストラップクラスローダからロードされるクラスを、ＪａｖａＶＭ１０のクラスとみなし、システムクラスローダからロードされるクラスを、ＯＳＧｉＦＷ１１のクラスとみなす。それぞれのクラスローダオブジェクトの構造体に別のグループＩＤを設定し、第１グループ選択アルゴリズムを用いる。
【０１４１】
以上より、同一クラスローダからロードされるクラスごとにメモリ消費量を制限できる。特に、第１グループ選択アルゴリズムではＰＦセット１４は１つとしたが、ＰＦセット１４をＪａｖａＶＭ１０とＯＳＧｉＦＷ１１とに分割できる。
【０１４２】
＜スレッドとグループＩＤとを結び付ける実施例＞
スレッドとグループＩＤとを結び付ける場合、ＪａｖａＶＭ１０に、スレッドに対してグループＩＤを設定することができるデータの構造体を追加し、図１５に示す第５グループ選択アルゴリズムを用いる。
【０１４３】
第５グループ選択アルゴリズムは、スレッドに設定されたグループＩＤを選択するようにしている（Ｓ５０１）。スレッドが立てられる際、スレッドを立てるクラスのクラスローダオブジェクトに設定されたグループＩＤを、立てるスレッドの構造体に設定する。
【０１４４】
以上より、基本的には、第２グループ選択アルゴリズムを用いた場合と同一の効果が得られるが、スタックを下に辿る動作を不要とするので、第２グループ選択アルゴリズムを用いた場合よりも高速にグループＩＤを決定できる。
【０１４５】
＜ＧＣ複数方式の実施例＞
ＧＣは、グループＩＤ毎に行う方式とヒープ領域全体で行う方式とが考えられる。
【０１４６】
グループ毎に行う方式は、ヒープ領域全体で行う方式と比較して、あるグループＩＤで頻繁にＧＣが起こる場合でも、他のグループＩＤは影響を受けることなく動作することができる。
【０１４７】
一方、ヒープ領域全体で行う方式は、グループＩＤ毎で行う方式と比較して、以下の利点がある。異なるグループＩＤで頻繁にＧＣが起こるような状況においては、参照されているオブジェクトをルートから探索する動作が頻繁に起こってしまいオーバーヘッドになる。しかし、ヒープ領域全体でＧＣを行う場合には、一度に全てのオブジェクトを探索するためこのような、オーバーヘッドがなくなるという利点がある。
【０１４８】
＜複数の制限値の実施例＞
これまでは、グループにはメモリ使用量の制限値を１つだけ設定していたが、本実施例では、グループにメモリ使用量の制限値を２つ設定する。制限値のひとつをＳｏｆｔＬｉｍｉｔ、もうひとつをＨａｒｄＬｉｍｉｔとする。ここでＳｏｆｔＬｉｍｉｔ＜ＨａｒｄＬｉｍｉｔである。また、ＪａｖａＶＭ１０は、グループＩＤ毎に、ＧＣ終了時にＧＣ対象とならなかったオブジェクトに割り当てられたメモリ消費量の合計であるキャッシュメモリ消費量積算値を保持する。
【０１４９】
メモリを割り当てる際、選択されたグループのキャッシュメモリ消費量積算値がＳｏｆｔＬｉｍｉｔを超過していた場合、メモリの割り当てが失敗したとして、ＧＣを実行せずにＯＯＭエラーを発生させる。
【０１５０】
選択されたグループのキャッシュメモリ消費量積算値がＳｏｆｔＬｉｍｉｔを超過していない場合は、ＨａｒｄＬｉｍｉｔをメモリ消費量の制限値として、制限値が１つの場合と同様の処理を行う。具体的には、選択されたグループのメモリ消費量積算値に生成されるオブジェクトのサイズを加算した値が、ＨａｒｄＬｉｍｉｔ以下の場合は、メモリの割り当ては成功とし、選択されたグループのメモリ消費量積算値に生成されるオブジェクトのサイズを加算した値が、ＨａｒｄＬｉｍｉｔより大きい場合は、ＧＣを実行し、選択されたグループの新たなメモリ消費量積算値に生成されるオブジェクトのサイズを加算してメモリを割り当てるか否か判定する。ＧＣを実行してもメモリ消費量積算値にオブジェクトのサイズを加算した値がＨａｒｄＬｉｍｉｔを超える場合は、ＯＯＭエラーを発生させる。
【０１５１】
特定のグループのＳＰバンドルが短時間の間にメモリ消費量の制限値までリソースを消費し、ＧＣによって解放されるような実装をしている場合、メモリ消費量の制限値が１つであればＧＣが頻発し、結果として、ＪａｖａＶＭ全体の処理速度が低下する可能性がある。本実施例を用いることで、ＳｏｆｔＬｉｍｉｔ＜該当グループＩＤのキャッシュメモリ消費量積算量であった場合、ＧＣをする前にＯＯＭエラーが発生するので、ＧＣの頻発を抑えることが可能となり、結果として、処理速度の低下を抑制できる。
【０１５２】
＜ＰＦセットに制限値を設定する実施例＞
ＰＦセット１４のリソース消費は、ＪａｖａＶＭ１０の起動から始まる。よって、ＪａｖａＶＭ１０が起動後、リソース管理バンドル１２ａが起動してＰＦセット１４のメモリ消費量の制限値を設定した後では、ＰＦセット１４に対して制限したい制限値を超過している可能性がある。
【０１５３】
そこで、ＪａｖａＶＭ１０起動時に起動オプションとしてＰＦセット１４に対する制限値を設定する。
【０１５４】
以上より、ＰＦセット１４に対して制限値を確実に設定することができ、ＰＦセット１４の制限値超過を防ぐことが可能となる。
【符号の説明】
【０１５５】
１…メモリ管理装置
１０…ＪａｖａＶＭ（Ｊａｖａ仮想マシン）
１１…ＯＳＧｉＦＷ
１２…オーナーバンドル
１２ａ…リソース管理バンドル
１３…ＳＰバンドルセット
１３１…ＳＰバンドル
１４…ＰＦセット
【図１】
0005357989.tif 000002
【図２】
0005357989.tif 000003
【図３】
0005357989.tif 000004
【図４】
0005357989.tif 000005
【図５】
0005357989.tif 000006
【図６】
0005357989.tif 000007
【図７】
0005357989.tif 000008
【図８】
0005357989.tif 000009
【図９】
0005357989.tif 000010
【図１０】
0005357989.tif 000011
【図１１】
0005357989.tif 000012
【図１２】
0005357989.tif 000013
【図１３】
0005357989.tif 000014
【図１４】
0005357989.tif 000015
【図１５】
0005357989.tif 000016
【図１６】
0005357989.tif 000017
【図１７】
0005357989.tif 000018
【図１８】
0005357989.tif 000019
【図１９】
0005357989.tif 000020
【図２０】
0005357989.tif 000021
【図２１】
0005357989.tif 000022