"OSGi標準仕様に基づくバンドルが利用するメモリを管理するメモリ管理装置において、1以上のバンドルを有するバンドル群に利用が許可されたメモリ量の情報を記憶手段から読み出して、当該メモリ量と同じ大きさのヒープ領域を確保する要求を行うメモリ管理バンドルと、自機のヒープ領域から前記ヒープ領域を確保し、前記バンドル群が利用するメモリ領域を、当該ヒープ領域に割り当てるJava仮想マシンと、を有することを特徴とするメモリ管理装置。OSGi標準仕様に基づくバンドルが利用するメモリを管理するメモリ管理方法において、コンピュータにより、1以上のバンドルを有するバンドル群に利用が許可されたメモリ量の情報を記憶手段から読み出して、当該メモリ量と同じ大きさのヒープ領域を確保する要求を行う第1ステップと、自機のヒープ領域から前記ヒープ領域を確保し、前記バンドル群が利用するメモリ領域を、当該ヒープ領域に割り当てる第2ステップと、を有することを特徴とするメモリ管理方法。前記バンドル群は、複数のバンドル群であって、前記第2ステップは、各バンドル群がそれぞれ利用するメモリ領域を、各バンドル群に対してそれぞれ確保されたヒープ領域にそれぞれ割り当てることを特徴とする請求項2記載のメモリ管理方法。前記バンドル群は、あるスレッドにおいて呼び出し呼び出される関係を有する複数のバンドル群であって、前記第2ステップは、全てのバンドル群が利用するメモリ領域を、最初に呼び出しを行ったバンドル群に対して確保されたヒープ領域に割り当てることを特徴とする請求項2記載のメモリ管理方法。前記バンドル群は、あるスレッドにおいてバンドルの有する機能の提供利用の関係を有する機能提供バンドル群および機能利用バンドル群であって、前記第2ステップは、前記機能提供バンドル群が利用するメモリ領域を、前記機能利用バンドル群に対して確保されたヒープ領域に割り当てることを特徴とする請求項2記載のメモリ管理方法。前記機能提供バンドル群は、機能を提供するプラットフォーム事業者により生成されたバンドル群であり、前記機能利用バンドル群は、機能を利用するサービス事業者により生成されたバンドル群である、又は、前記機能提供バンドル群は、機能を提供するサービス事業者により生成されたバンドル群であり、前記機能利用バンドル群は、機能を利用するサービス事業者により生成されたバンドル群であることを特徴とする請求項5記載のメモリ管理方法。前記ヒープ領域で使用されているメモリ消費量を計算するステップを更に有することを特徴とする請求項2乃至6のいずれかに記載のメモリ管理方法。請求項2乃至7のいずれかに記載の各ステップをコンピュータに実行させることを特徴とするメモリ管理プログラム。従来の技術では、バンドルOSGiFWJavaVMがヒープ領域を共有するため、あるEntityでOOMエラーが発生してメモリが解放されない場合、その他のEntityもその時点以降、新たにメモリを確保することができなくなり、結果的に全てのシステムが停止してしまう可能性がある。特に課題となるのは、複数の事業者が従来の技術を用いて、1つのシステムを共有して同時にサービスを提供するような場合である。例えば、プラットフォーム事業者以下、PF事業者は、JavaVMやOSGiFWなどのシステムの基盤となる部分をプラットフォームシステムとして提供し、サービス事業者以下、SP事業者は、自身が開発したバンドルをPF事業者が提供するプラットフォームシステム上で動作させることでサービスを提供することを想定する。この時、あるSP事業者の作成するバンドルがバグ等により想定以上のメモリを消費すると、バグがなければ正常に動作可能であったはずの他のEntityまで動作できなくなってしまう。他のEntityとは、JavaVM,OSGiFW,他のバンドル等である。つまり、正常な動作をしているはずのJavaVM上で動作する全てのEntityPF事業者の提供するシステムやSP事業者のバンドルが、1つのSP事業者のバンドルのバグによって動作不能になることが発生する。また、前述したように、OSGiにおいてはバンドルやOSGiFWなどの構成要素が連携している。連携した時に消費されるメモリは、呼び出し元とクラス提供とのどちらのメモリ消費量としてカウントするかといった定義は、OSGiやJavaの仕様では定められていない非特許文献1,非特許文献2参照。定義が決まっていないため、バンドルのメモリ消費量の計測もできない。本発明は、上記課題を鑑みてなされたものであり、その課題とするところは、メモリ消費量を任意の単位で制限することにある。請求項1記載のメモリ管理装置は、OSGi標準仕様に基づくバンドルが利用するメモリを管理するメモリ管理装置において、1以上のバンドルを有するバンドル群に利用が許可されたメモリ量の情報を記憶手段から読み出して、当該メモリ量と同じ大きさのヒープ領域を確保する要求を行うメモリ管理バンドルと、自機のヒープ領域から前記ヒープ領域を確保し、前記バンドル群が利用するメモリ領域を、当該ヒープ領域に割り当てるJava仮想マシンと、を有することを特徴とする。本発明によれば、バンドル群が利用するメモリ領域を、当該バンドル群に利用が許可されたメモリ量と同じ大きさで確保されたヒープ領域に割り当てるため、バンドル群が消費するメモリ消費量を任意の単位で制限できる。請求項2記載のメモリ管理方法は、OSGi標準仕様に基づくバンドルが利用するメモリを管理するメモリ管理方法において、コンピュータにより、1以上のバンドルを有するバンドル群に利用が許可されたメモリ量の情報を記憶手段から読み出して、当該メモリ量と同じ大きさのヒープ領域を確保する要求を行う第1ステップと、自機のヒープ領域から前記ヒープ領域を確保し、前記バンドル群が利用するメモリ領域を、当該ヒープ領域に割り当てる第2ステップと、を有することを特徴とする。本発明によれば、バンドル群が利用するメモリ領域を、当該バンドル群に利用が許可されたメモリ量と同じ大きさで確保されたヒープ領域に割り当てるため、バンドル群が消費するメモリ消費量を任意の単位で制限できる。請求項3記載のメモリ管理方法は、請求項2記載のメモリ管理方法において、前記バンドル群は、複数のバンドル群であって、前記第2ステップは、各バンドル群がそれぞれ利用するメモリ領域を、各バンドル群に対してそれぞれ確保されたヒープ領域にそれぞれ割り当てることを特徴とする。本発明によれば、各バンドル群がそれぞれ利用するメモリ領域を、各バンドル群に対してそれぞれ確保されたヒープ領域にそれぞれ割り当てるため、メモリ消費量をバンドル群単位でカウントでき、当該カウント方法によってメモリ消費量を制限できる。請求項4記載のメモリ管理方法は、請求項2記載のメモリ管理方法において、前記バンドル群は、あるスレッドにおいて呼び出し呼び出される関係を有する複数のバンドル群であって、前記第2ステップは、全てのバンドル群が利用するメモリ領域を、最初に呼び出しを行ったバンドル群に対して確保されたヒープ領域に割り当てることを特徴とする。本発明によれば、全てのバンドル群が利用するメモリ領域を、最初に呼び出しを行ったバンドル群に対して確保されたヒープ領域に割り当てるため、メモリ消費量をスレッド単位でカウントでき、当該カウント方法によってメモリ消費量を制限できる。請求項5記載のメモリ管理方法は、請求項2記載のメモリ管理方法において、前記バンドル群は、あるスレッドにおいてバンドルの有する機能の提供利用の関係を有する機能提供バンドル群および機能利用バンドル群であって、前記第2ステップは、前記機能提供バンドル群が利用するメモリ領域を、前記機能利用バンドル群に対して確保されたヒープ領域に割り当てることを特徴とする。本発明によれば、機能提供バンドル群が利用するメモリ領域を、機能利用バンドル群に対して確保されたヒープ領域に割り当てるため、メモリ消費量を機能利用バンドル群単位でカウントでき、当該カウント方法によってメモリ消費量を制限できる。請求項6記載のメモリ管理方法は、請求項5記載のメモリ管理方法において、前記機能提供バンドル群は、機能を提供するプラットフォーム事業者により生成されたバンドル群であり、前記機能利用バンドル群は、機能を利用するサービス事業者により生成されたバンドル群である、又は、前記機能提供バンドル群は、機能を提供するサービス事業者により生成されたバンドル群であり、前記機能利用バンドル群は、機能を利用するサービス事業者により生成されたバンドル群であることを特徴とする。請求項7記載のメモリ管理方法は、請求項2乃至6のいずれかに記載のメモリ管理方法において、前記ヒープ領域で使用されているメモリ消費量を計算するステップを更に有する。本発明によれば、請求項2乃至6のいずれかに記載されたヒープ領域で使用されているメモリ消費量を計算するため、制限対象毎にメモリ消費量を計測できる。請求項8記載のメモリ管理プログラムは、請求項2乃至7のいずれかに記載の各ステップをコンピュータに実行させることを特徴とする。本発明によれば、メモリ消費量を任意の単位で制限することができる。以下、本発明を実施する一実施の形態について図面を用いて説明する。但し、本発明は多くの異なる様態で実施することが可能であり、本実施の形態の記載内容に限定して解釈すべきではない。メモリ管理装置の構成についてまず、メモリ管理装置1の構成について説明する。図1は、本実施の形態に係るメモリ管理装置の構成を示す図である。このメモリ管理装置1は、OSGi標準仕様に基づくバンドルが利用確保消費するメモリを管理する装置であって、OS上で動作するJavaVM10と、JavaVM上でバンドルの実行環境を提供するOSGiFW11と、OSGiFW上でJavaプログラムとして動作する複数のオーナーバンドル12および複数のSPバンドルセット13とで主に構成される。なお、図2に示すように、PF事業者が作成するバンドルをオーナーバンドル12とし、SP事業者がサービスを提供するために作成するバンドルをSPバンドル131とする。また、1以上のバンドルで構成されるバンドル群をバンドルセットとし、SP事業者が作成するSPバンドル群をSPバンドルセット13、PF事業者がプラットフォームシステムとして作成するJavaVM10とOSGiFW11とオーナーバンドル12とをPFセット14とする。PFセット14は本実施の形態において1つであり、SPバンドルセット13は複数考えられる。JavaVM10には、従来技術にない標準外の機能を備えている図1の改造部等参照。また、JavaVM10に独自のAPIを持たせ、JavaVM10に所定の情報後述を設定するために、メモリ管理バンドル12aをオーナーバンドル12の1つとして用意する。メモリ管理バンドル12aは、1つのバンドルセットを構成するバンドルの情報以下、バンドルセット情報と、そのバンドルセットに利用許可されるメモリ量以下、バンドルセットメモリ量との情報を、通信ネットワークを介して接続されたサーバ3等から取得して記憶手段に一旦記憶し、当該記憶手段から読み出して取得する機能を有する。ここで、バンドルセット情報とは、OSGi仕様で定められるBundle-SymbolicNameとBundle-Versionとによってバンドルを一意に識別した識別子であり、識別したバンドルが1つ以上指定される。なお、サーバ3は、図3に示すように、メモリ管理装置1とは別装置として外部に設置されており、メモリ管理装置1と通信を行う。バンドルセット情報等の受け渡しはXMLファイル等の様々な方法が考えられる。なお、バンドルセット情報等については、サーバ3と通信を行い取得するのではなく、自機の記憶手段に予め保持しておき読み出すのでもよい。また、メモリ管理バンドル12aは、バンドルセット情報およびバンドルセットメモリ量を取得した後、JavaVM10が提供する第1API後述を通じて、JavaVM10に対して、取得したバンドルセットメモリ量と同じ大きさの分割ヒープ領域を生成する要求を行い、生成された分割ヒープ領域を識別するID以下、ヒープIDを取得する機能を有する。また、メモリ管理バンドル12aは、あるバンドルセットに属するバンドルがOSGiFW上にインストールされRESOLVEイベントを受信した際に、そのバンドルのクラスローダオブジェクトをOSGi標準APIおよびJava標準API以下、標準APIを通じて取得し、JavaVM10が提供する第2API後述を通じて、JavaVM10に対して、バンドルクラスローダオブジェクトとヒープIDとを組にした情報を送信する機能を有する。JavaVM10は、外部設計として、第1APIおよび第2APIを有する。第1APIは、バンドルセットメモリ量を引数に取り、指定されたバンドルセットメモリ量を持つ分割ヒープ領域を新規に生成して、その生成された分割ヒープ領域のヒープIDを返す機能を有する。第2APIは、クラスローダオブジェクトとヒープIDとを引数に取り、指定されたクラスローダオブジェクトからロードされるバンドルが確保消費するメモリ領域を、指定されたヒープIDの分割ヒープ領域から確保する要求を受け付ける機能を有する。一方、JavaVM10は、内部設計として、クラスローダオブジェクトに対してヒープIDを設定可能なデータ構造が追加されている。第1APIが呼び出された時には、分割ヒープ領域を生成する機能を有する。第2APIが呼び出された時には、指定されたクラスローダオブジェクトのデータ構造に、指定されたヒープIDを設定する機能を有する。また、指定されたヒープIDの分割ヒープ領域に、バンドルが確保消費するメモリ領域を割り当てる機能、又は、ヒープ選択アルゴリズム後述によりヒープIDを決定し、決定されたヒープIDの分割ヒープ領域に、バンドルが確保消費するメモリ領域を割り当てる機能を有する。なお、分割ヒープ領域内でメモリ不足の場合例えば、SPバンドルセット毎に必要なメモリ量が確保できない場合には、分割ヒープ領域ごとにOOMエラーを発生させる。メモリ管理装置の動作について次に、メモリ管理装置1の動作について説明する。なお、理解を容易にするため、以降では、SPバンドルセット13のSPバンドル131を例に用いて説明する。また、その場合におけるバンドルセット情報を、SPバンドルセット情報と記載する。最初に、メモリ管理バンドル12aが、通信ネットワークを介して接続された外部のサーバ3から、SPバンドルセット情報とSPバンドルセットメモリ量とを取得するS1。次に、S1の後、S1で取得対象であったSPバンドルセット13のSPバンドル131がメモリ管理装置1にインストールされRESOLVEイベントを受信した際に、メモリ管理バンドル12aは、JavaVM10の第1APIを呼び出して、S1で取得したSPバンドルセットメモリ量の大きさの分割ヒープ領域を生成する要求を行い、生成された分割ヒープ領域に対して設定されたヒープIDを取得するS2。このとき、JavaVM10は、OSから割り当てられた1つのヒープ領域を分割して、上記SPバンドルセットメモリ量と同じの大きさの分割ヒープ領域を生成し、ヒープIDを返すS2’。S2,S2’の後、メモリ管理バンドル12aは、インストールされたSPバンドル131のクラスローダオブジェクトを標準APIを利用して取得し、取得したクラスローダオブジェクトと、S2で取得したヒープIDとを指定してJavaVM10の第2APIを呼び出すS3。最後に、JavaVM10は、S3で指定されたヒープIDの分割ヒープ領域、又は、採用するヒープ選択アルゴリズム後述に基づいて決定されたヒープIDの分割ヒープ領域に、インストールされたSPバンドル131が確保消費するメモリ領域を割り当てるS4。これより、SPバンドル131は、割り当てられた分割ヒープ領域を用いて自身のプログラムを実行する。以上より、SPバンドルセット13に利用許可されたバンドルセットメモリ量と同じ大きさの分割ヒープ領域を生成し、生成された分割ヒープ領域、又は、ヒープ選択アルゴリズムに基づいて決定された分割ヒープ領域に、SPバンドルセット13のSPバンドル131が確保消費するメモリ領域を割り当てるので、SPバンドル131が消費するメモリ消費量を任意の単位で制限できる。また、分割ヒープ領域を生成するので、従来技術では1つだったヒープ領域を複数持たせることができる。また、割り当てられる分割ヒープ領域を、ヒープ選択アルゴリズムに基づいて決定するので、制限する単位を変更できる。また、第2APIで設定する情報は、ヒープ選択アルゴリズムで参照される。テーブルなどの検索を行うことなく、スタックからポインタ参照で辿れる情報のみを利用しているので、プログラム動作中のメモリ割当における速度低下を低減できる。また、特に、ヒープ選択アルゴリズムに基づいて決定された分割ヒープ領域にSPバンドル131が消費するメモリ領域を割り当てるので、PFセット14やSPバンドルセット13が消費するヒープ領域を、ヒープアルゴリズムの効果の単位で制限することが可能になる。なお、本実施の形態では、サーバ3から取得されるバンドルセット情報等のバンドル、JavaVM10に対して生成要求される分割ヒープ領域のバンドル、クラスローダからロードされるバンドル、メモリ領域が割り当てられて確保消費されるバンドル等の全てについて、前述したようにSPバンドル131を例に用いて説明したが、これはあくまでも一例である。SPバンドル131に代えて、又は加えて、1以上のバンドルを有するバンドル群であるSPバンドルセット13やPFセット14、PFセット14に含まれるオーナーバンドルを用いることも可能である。また、本実施の形態では、1つのヒープ領域を分割して分割ヒープ領域を生成する方法を例に説明したが、これはあくまでも一例である。SPバンドルセットメモリ量と同じ大きさのヒープ領域を新たに生成する方法や、元々のヒープ領域を分割する方法も利用できる。すなわち、利用が許可されたメモリ量と同じ大きさのヒープ領域を自機のヒープ領域から確保して、そのヒープ領域にバンドル群が利用するメモリ領域を割り当てるのであれば、どのような方法も採用できる。ヒープ選択アルゴリズム次に、ヒープ選択アルゴリズムについて説明する。前述したように、メモリ割当を分割ヒープ領域に行う際、メモリ割当を行うヒープIDを選択するヒープ選択アルゴリズムによって、どの単位でメモリ消費量を制限できるかが変化することになる。本実施の形態では、一例として、4つのヒープ選択アルゴリズムについて説明する。ここで、PFセット14とSPバンドルセット13との関係性を考える。PFセット14とSPバンドルセット13とのどちらがクラス提供側呼び出し側になるのかは、以下の4通り2×2通りが考えられる。象限a呼び出し側:PFセット。クラス提供側:PFセット。象限b呼び出し側:SPバンドルセットYSP_Y。クラス提供側:PFセット。象限c呼び出し側:PFセット。クラス提供側:SPバンドルセットXSP_X。象限d呼び出し側:SPバンドルセットSP_Y。クラス提供側:SPバンドルセットSP_X。なお、象限bと象限cとについては、PFセットにとってはいずれもSPバンドルセットであるので、SPバンドルセットはXでもYでも良いが、ここでは便宜上区別している。それら各象限についてスタックで表すと、それぞれ、図4~図7に示すようなスタックになる。これらを表で表すと、図8に示すようになる。また、後述する各ヒープ選択アルゴリズムにおいて、どの分割ヒープ領域が選択されるかを表す具体的な例として、図9Aaに示すように、一番下のスタックをスタック[0]のPFセットのスタックとして積み重なったスタックを用いる。なお、各スタック内の模様は、各スタックすなわち、各クラスで消費されるメモリ領域が、SPバンドルセット1以下、SP_BS1,SPバンドルセット2以下、SP_BS2,PFセットのどのメモリ消費量としてカウントされるかを表す。また、各スタック内の文字は、各スタックを生成したクラスの提供元を表す。すなわち、JavaVM上で動作するあるスレッドにおける、図9Aaのスタックについて言えば、スタック[0]においてPFセットのクラス、以下省略がSP_BS1のクラス、以下省略を呼び出してスタック[1]とし、スタック[1]のSP_BS1がPFセットを呼び出してスタック[2]とし、スタック[2]のPFセットがPFセットを呼び出してスタック[3]とし、スタック[3]のPFセットがSP_BS2を呼び出してスタック[4]とし、スタック[4]のSP_BS2がSP_BS1を呼び出してスタック[5]とし、スタック[5]のSP_BS1がPFセットを呼び出してスタック[6]としている。そして、最後に呼び出された一番上のスタック[6]から処理が順次行われる。以下、ヒープ選択アルゴリズムを説明する前に、用語の定義を行う。定数を大文字、変数の頭文字は小文字で表すここでの定数は、1回のヒープ選択アルゴリズムにおいて代入がない値を指す。ヒープ選択アルゴリズムは、最終的にメモリ割当を行うヒープIDである変数heapIDを決定するためのアルゴリズムである。クラスローダに設定されているヒープIDをCL_HEAPIDとする。PFセットのCL_HEAPIDをHEAPID_PFとする。SPバンドルセットのCL_HEAPIDをHEAPID_SPとする。各スタックにて処理が行われるクラスのCL_HEAPIDをSTACK_HEAPIDとする。スタックを1つずつ下に辿っていくにあたり、現在調べているスタックを表す変数をcurStackとする。heapIDを決定するために一時的に利用する変数をcurheapIDとする。各スレッドの一番上のスタックをTOPSTACKとする。curStackがスレッドを下まで辿り、最後のスタックの次を指定した場合、Nullを指すとする。ヒープメモリの確保はスレッドの一番上のスタックで実行されるので、ヒープ選択アルゴリズムは、常にTOPSTACKにおいてメモリ割当が必要となる度に実行される。<第1ヒープ選択アルゴリズム>第1ヒープ選択アルゴリズムの動作を示すフローチャートを図10に示す。なお、以下説明する全てのヒープ選択アルゴリズムの主体は、JavaVM10である。TOPSTACKのSTACK_HEAPIDをheapIDとするS101。すなわち、図9Abに示すように、各スタックのクラスが確保消費するメモリ領域を、各スタックのクラスに対してそれぞれ生成された分割ヒープ領域にそれぞれ割り当てるようにしている。以上より、各スタックのクラスが確保消費するメモリ領域を、各スタックのクラスに対してそれぞれ生成された分割ヒープ領域にそれぞれ割り当てるので、呼び出し元に関わらず、実装クラスのセット単位すなわち、PFセットやSPバンドルセットのバンドル群単位でメモリ消費量をカウントでき、当該カウント方法によってメモリ消費量を制限できる。<第2ヒープ選択アルゴリズム>第2ヒープ選択アルゴリズムの動作を示すフローチャートを図11に示す。第2ヒープ選択アルゴリズムは、スタックを1つずつ下に辿り、呼び出し元となるスタックを探索するアルゴリズムである。各スタックは、あるスレッドにおいて呼び出し呼び出される関係にある。最初に、curStackにTOPSTACKを代入するS201。次に、curStackがNullならばS204に進み、それ以外であればS203に進むS202。次に、curStackを1つ下のスタックにするS203。最後に、curStackのSTACK_HEAPIDをheapIDとするS204。つまり、TOPSTACKの呼び出し元スタックを、その呼び出し元スタックの呼び出し元スタックを...と繰り返して呼び出し元を辿っていく。結果的に、スレッドの一番下のスタックのクラスローダに設定されているヒープIDを参照する。すなわち、全てのスタックのクラスが確保消費するメモリ領域を、最初に呼び出しを行ったスタックのクラスに対して生成された分割ヒープ領域に割り当てるようにしている。なお、このアルゴリズムを実行すると、スタックの例としては図9Acに示すようになる。例えば、スタック[6]が確保消費するメモリ領域が、どのようにカウントされるかを以下説明する。スタック[6]を呼び出したのはスタック[5]であり、スタック[5]を呼び出したのはスタック[4]である。スタック[4]を呼び出したのはスタック[3]であり、スタック[3]を呼び出したのはスタック[2]である。スタック[2]を呼び出したのはスタック[1]であり、スタック[1]を呼び出したのはスタック[0]である。スタック[0]には呼び出し元がないため、結果的にスタック[6]のメモリ消費量はスタック[0]が呼び出したとカウントされ、スタック[0]のPFセットのメモリ消費量としてカウントされる。スタック[6]の処理が行われた後、スタック[6]はスレッドからなくなりスタック[5]がTOPSTACKになる。スタック[5]~[0]でも同様の処理が行われるので、全て、スタック[0]が呼び出したメモリとカウントされる。以上より、全てのスタックのクラスが確保消費するメモリ領域を、最初に呼び出しを行ったスタックのクラスに対する分割ヒープ領域に割り当てるので、メモリ消費量をスレッド単位でカウントでき、当該カウント方法によってメモリ消費量を制限できる。<第3ヒープ選択アルゴリズム>第3ヒープ選択アルゴリズムの動作を示すフローチャートを図12に示す。第3ヒープ選択アルゴリズムは、TOPSTACKでメモリ割当が起こるたびに分割ヒープを選択するアルゴリズムである。最初に、heapIDにHEAPID_PFを代入するS301。次に、curStackにTOPSTACKを代入するS302。次に、curheapIDにSTACK_HEAPIDを代入するS303。次に、curheapIDがHEAPID_PFならばS305に進み、それ以外であればS306に進むS304。次に、heapIDがHEAPID_SPならばheapIDに入っている値が本アルゴリズムによって選択された分割ヒープ領域として処理を終了し、それ以外であればS306に進むS305。次に、heapIDにcurheapIDを代入するS306。次に、curStackを1つ下のスタックにするS307。最後に、curStackがNullならばheapIDに入っている値が本アルゴリズムによって選択された分割ヒープ領域として処理を終了し、そうでないならばS303に戻るS308。つまり、バンドルの有する機能提供者であるPF事業者によって生成されたPFセットと、機能利用者であるSP事業者によって生成されたSPバンドルセット間の関係において、メモリ消費量は呼び出しクラス提供に関わらず、機能を利用しているSPバンドルセットのメモリ消費量としてカウントされる。すなわち、機能を提供するPFセット機能提供バンドル群が確保消費するメモリ領域を、機能を利用するSPバンドルセット機能利用バンドル群に対して生成された分割ヒープ領域に割り当てるようにしている。なお、システムの基盤となるPFセットが、SPバンドルセットを利用することによってPFセットのための機能を実現することはあり得ない。例えば、象限bの例として、PFの共通的な機能としてPFセットがHttpServiceを実装したバンドルを提供することが考えられる。SPバンドルはHttpServiceを取得し、呼び出すことによりPFセットの提供するHttpServiceの機能を利用する。また、象限cの代表例は、OSGi仕様で定義されるBundleActivatorstartの呼び出しである。呼び出すのはOSGiFW、つまりPFセットであるが、SPバンドルがクラス提供した理由は、PFセットが提供するSPバンドルを対象端末上で起動する機能を利用する為である。どのような場合においても、象限cは、背景技術で説明した通りコールバック型、つまりクラス提供側であるSPバンドルセットが機能を利用する形となる。但し、象限aやd、つまりPFセットがPFセットを呼び出した場合や、SPバンドルセットがSPバンドルセットを呼び出した場合は、機能の提供利用によらず、呼び出したSPバンドルセットのメモリ消費量とカウントする。呼び出し元クラス提供スタックの関係を表すと、図13に示すようになる。この図は、2つのスタックの関係において、上のスタッククラス提供スタックで消費されたメモリが、呼び出し元スタックとクラス提供スタックどちらのスタックにカウントされるかを示している。ここで、スタックが複数積み重なった例を、図9Adを用いて説明する。まず、PFセットのクラスにあたるスタック[6]で消費されるメモリ量は、呼び出し元スタック[5]がSPバンドルセット1なので、呼び出し元スタック[5]が消費したメモリ量としてカウントされる象限b。SPバンドルセット1であるスタック[5]で消費されるメモリ量は、呼び出し元スタック[4]がSPバンドルセット2なので、呼び出し元スタック[4]で消費されるメモリとしてカウントされる象限d。スタック[4]で消費されるメモリ量は、呼び出元スタック[3]がPFセットなので、クラス提供スタック[4]で消費されるメモリ量とカウントされる象限c。よって、スタック[4]~[6]において消費されるメモリ量は、スタック[4]に該当するクラスを提供するSPバンドルセット2が消費するメモリ量としてカウントされる。同様に、スタック[3]で消費されるメモリ量は、呼び出し元スタック[2]がPFセットなので、呼び出し元スタック[2]の消費メモリとカウントとされる象限a。スタック[2]で消費されるメモリ量は、呼び出し元スタック[1]がSPバンドルセット1なので、呼び出し元スタック[1]の消費メモリとカウントとされる象限b。スタック[1]で消費されるメモリ量は、呼び出し元スタック[0]がPFセットなので、クラス提供スタック[1]で消費されるメモリ量とカウントされる象限c。よって、スタック[1]~[3]において消費されるメモリ量は、スタック[1]に該当するクラスを提供するSPバンドルセット1が消費するメモリ量としてカウントされる。最後に、スタック[0]で消費されるメモリ量は、呼び出し元スタックが存在しないので、クラス提供スタックであるスタック[0]が消費しているメモリ量とカウントとする。よって、スタック[0]で消費されるメモリ量は、スタック[0]に該当するクラスを提供するPFセットが消費するメモリ量としてカウントされる。以上より、機能を提供するPFセットが確保消費するメモリ領域を、機能を利用するSPバンドルセットに対する分割ヒープ領域に割り当てるので、メモリ消費量を、機能を利用するバンドルセット単位でカウントでき、当該カウント方法によってメモリ消費量を制限できる。<第4ヒープ選択アルゴリズム>第3ヒープ選択アルゴリズムでは、機能の提供利用の関係について、機能を提供するPFセットと機能を利用するSPバンドルセットとを用いて説明した。一方、同関係はSPバンドルセット同士にもあるため、第4ヒープ選択アルゴリズムではその場合について説明する。以下説明する第4ヒープ選択アルゴリズムを実現するために、メモリ管理バンドル12aおよびJavaVM10に対して以下の機能を追加する。メモリ管理バンドル12aは、SPバンドル131のクラスが機能の提供利用どちらを行うクラスかの情報を入手する機能を更に有する。また、JavaVM10が提供する第3API後述を通じて、JavaVM10に対して、クラスごとに機能の提供利用CallBackFlag、以下、CBFを設定する要求を行う機能を更に有する。JavaVM10は、外部設計として、クラスオブジェクトとCBFとを引数に取り、指定されたクラスが機能を提供するクラスか機能を利用するクラスかをJavaVM10に設定する第3APIを有する。内部設計として、クラスオブジェクトのデータ構造にCBFを設定できるデータ構造を用意し、第3APIが呼び出された時に、指定されたクラスオブジェクトのデータ構造に指定されたCBFを設定する機能を有する。このような機能を有する際のメモリ管理装置1の動作について以下説明する。最初に、メモリ管理バンドル12aが、通信ネットワークを介して接続された外部のサーバ3から、SPバンドルセット情報とSPバンドルセットメモリ量とを取得すると共に、当該取得対象であるSPバンドルセット13のSPバンドル131のクラスにセットするCBFを取得するS11。次に、S11の後、S11で取得対象であったSPバンドルセット13のSPバンドル131がメモリ管理装置1にインストールされRESOLVEイベントを受信した際に、メモリ管理バンドル12aは、JavaVM10の第1APIを呼び出して、S11で取得したSPバンドルセットメモリ量の大きさの分割ヒープ領域を生成する要求を行い、生成された分割ヒープ領域に対して設定されたヒープIDを取得するS12。このとき、JavaVM10は、OSから割り当てられた1つのヒープ領域を分割して、上記SPバンドルセットメモリ量と同じの大きさの分割ヒープ領域を生成し、ヒープIDを返すS12’。S12,S12’の後、メモリ管理バンドル12aは、インストールされたSPバンドル131のクラスローダオブジェクトを標準APIを利用して取得し、取得したクラスローダオブジェクトとS12で取得したヒープIDとを指定してJavaVM10の第2APIを呼び出すS13。また、S13で取得したクラスローダオブジェクトとS11で取得したCBFとを指定し、第3APIを呼び出すS14。最後に、JavaVM10は、S14で指定されたクラスオブジェクトのデータ構造にS14で指定されたCBFを設定した後に、後述する第4ヒープ選択アルゴリズムに基づいて決定されたヒープIDの分割ヒープ領域に、インストールされたSPバンドル131が確保消費するメモリ領域を割り当てるS15。CBFは、そのクラスがクラスの提供利用どちらのクラスかを表している。機能提供クラスがSPバンドルセットから呼び出され、機能提供クラスのスタックで消費されたメモリは、呼び出したSPバンドルセットの消費メモリとカウントする。一方、機能利用クラスがSPバンドルセットから呼び出され、機能利用クラスのスタックで消費されたメモリは、呼び出したSPバンドルセットのメモリ消費量とカウントする。すなわち、機能を提供するSPバンドルセット機能提供バンドル群が確保消費するメモリ領域を、機能を利用するSPバンドルセット機能利用バンドル群に対して生成された分割ヒープ領域に割り当てるようにしている。第4ヒープ選択アルゴリズムの動作を示すフローチャートを図14に示す。第4ヒープ選択アルゴリズムは、TOPSTACKでメモリ割当が起こるたびに分割ヒープを選択する。なお、CUR_CBFはcurStackのクラスのCBFを表し、last_CBFは、curStackの1つ上のスタックのクラスのCBFを表す。最初に、heapIDにHEAPID_PFに代入するS401。次に、curStackにTOPSTACKを代入するS402。次に、last_CBFに機能提供を代入するS403。次に、curheapIDにSTACK_HEAPIDを代入するS404。次に、curheapIDがHEAPID_PFならばS410に進み、そうでないならばS406に進むS405。次に、curheapIDがheapIDと同じならばS410に進み、そうでないならばS407に進むS406。次に、heapIDがHEAPID_PFならばS409に進み、そうでないならばS408に進むS407。次に、lastCBFが機能利用ならば処理を終了し、そうでないならばS409に進むS408。次に、heapIDにcurheapIDを代入するS409。次に、last_CBFにCUR_CBFを代入するS410。次に、curStackを1つ下のスタックにするS411。最後に、curStackがNullでならば処理を終了し、そうでないならばS403に戻るS412。呼び出し元クラス提供スタックの関係を表すと、図15に示すようになる。ここで、スタックが複数積み重なった例を、図9Be,fを用いて説明する。まず、スタック[5]が機能利用クラスである図9Beにおいてどのようにカウントされるかを説明する。PFセットのクラスにあたるスタック[6]で消費されるメモリ量は、呼び出し元スタック[5]がSPバンドルセット1なので、呼び出し元スタック[5]が消費したメモリ量としてカウントされる象限b。SPバンドルセット1であるスタック[5]で消費されるメモリ量は、呼び出し元スタックがSPバンドルセット2であり、機能利用クラスであるので、クラス提供スタック[5]で消費されるメモリとしてカウントされる象限d。なお、スタック[4]~スタック[0]については第3ヒープ選択アルゴリズムと同様である。次に、スタック[5]が機能提供クラスである図9Bfにおいてどのようにカウントされるかを説明する。PFセットのクラスにあたるスタック[6]で消費されるメモリ量は、呼び出し元スタック[5]がSPバンドルセット1なので、呼び出し元スタック[5]が消費したメモリ量としてカウントされる象限b。SPバンドルセット1であるスタック[5]で消費されるメモリ量は、呼び出し元スタックがSPバンドルセット2であり、機能提供クラスであるので、呼び出したSPバンドルセット2で消費されるメモリとしてカウントされる象限d。なお、スタック[4]~スタック[0]については第3ヒープ選択アルゴリズムと同様である。以上より、機能を提供するSPバンドルセットが確保消費するメモリ領域を、機能を利用するSPバンドルセットに対する分割ヒープ領域に割り当てるので、第3ヒープ選択アルゴリズムの効果に加えて、SPバンドルセット同士の呼び出しにおいても、機能の提供利用によってメモリ消費量のカウント先を変更でき、メモリ消費量を更に制限できる。また、JavaVM10にクラスオブジェクトのデータ構造にCBFを設定できるデータ構造を用意しているので、クラスごとに機能の提供利用を判別することができる。メモリ消費量の計測について次に、JavaVM10におけるメモリ消費量の計測方法について説明する。メモリ消費量を計測するために、JavaVM10に対して、以下の機能を追加する。JavaVM10は、外部設計として、ヒープIDを引数に取り、分割ヒープ領域のメモリ量を計算する第4APIを更に有する。また、内部設計として、第4APIが呼び出された時に、指定されたヒープIDの空きメモリ量を返す機能を有する。以下、分割ヒープ領域のメモリ消費量を計測する方法を説明する。最初に、JavaVM10は、GCを行うS21。例えば、第4APIが呼び出される前に、第4APIを呼び出すプログラム側でSystem.gcなどでGCを行う方法も考えられる。ここでGCは、分割ヒープ領域毎に行うか、ヒープ領域全体に行うかは問わない。次に、S21の後、メモリ管理バンドル12aから送信されたヒープIDを取得し、当該ヒープIDの分割ヒープ領域における消費メモリや残りの利用可能メモリを計算するS22。最後に、S22で計算した消費メモリや利用可能メモリをメモリ管理バンドル12aに返すS23。なお、GCとは、プログラムが動的に確保したメモリ領域のうち、不要になった領域を自動的に解放する処理をいう。以上より、分割ヒープ領域単位でメモリ消費量を計測できる。生成済みの分割ヒープ領域の削除について次に、生成済みの分割ヒープ領域の削除方法について説明する。分割ヒープ領域を削除するために、JavaVM10に対して、以下の機能を追加する。JavaVM10は、外部設計として、ヒープIDを引数に取り、分割ヒープ領域を削除する第5APIを更に有する。また、内部設計として、第5APIが呼び出された時に、指定されたヒープIDの分割ヒープ領域を削除する機能を有する。以上より、削除対象の分割ヒープ領域が解放される。実施例<PFセットからSPバンドルセットへの呼び出しにおける実施例>第3,第4ヒープ選択アルゴリズムにおいて、SPバンドルセット1以下、SP1が、SPバンドルセット2以下、SP2を呼び出す例を考える。SP2の内部でPFセットを呼び出すと、図16に示すようなスタックになる場合がある。このようなスタック構造になるPFセットのクラスには、例えばAccessController.doPrivilegedなどがある。このようなクラスには、第4ヒープ選択アルゴリズムで説明したCBFを機能提供に設定し、第4ヒープ選択アルゴリズムを適用する。以上より、スタック[3]からスタック[4]への呼び出しは、第4ヒープ選択アルゴリズムにおいてはSP2のメモリ消費量とカウントされることになる。この例において、SP1がSP2の機能を利用している場合には、スタック[2]~スタック[4]の呼び出しは、SP1がSP2の機能を利用するために行われていることになる。つまり、スタック[2]~[4]で消費されたメモリ量は、機能を利用しているSP1のメモリ消費量とカウントされることが望ましく、それを実現することができる。<PFセットを詳細に分割する実施例>ブートストラップクラスローダからロードされるクラスを、JavaVMのクラスとみなし、システムクラスローダからロードされるクラスを、OSGiFWのクラスとみなす。それぞれのクラスローダオブジェクトの構造体に別のヒープIDを設定し、第1ヒープ選択アルゴリズムを用いる。以上より、同一クラスローダからロードされるクラスごとにメモリ消費量を制限できる。特に、第1ヒープ選択アルゴリズムではPFセットは1つとしたが、PFセットをJavaVMとOSGiFWとに分割できる。<スレッドとヒープIDとを結び付ける実施例>JavaVM10に、内部設計として、スレッドに対してヒープIDを設定することができるデータの構造体を追加する。この場合、図17に示す第5ヒープ選択アルゴリズムを用いる。このアルゴリズムは、スレッドに設定されたヒープIDの分割ヒープを選択するようにしている。スレッドが立てられる際、スレッドを立てるクラスのクラスローダオブジェクトのヒープIDを、立てるスレッドの構造体に設定する。以上より、基本的には、第2ヒープ選択アルゴリズムを用いた場合と同一の効果が得られるが、スタックを下に辿る動作を不要とするので、第2ヒープ選択アルゴリズムを用いた場合よりも高速にメモリ割当を行うヒープIDを決定できる。<ヒープメモリ管理方式の実施例>分割ヒープ領域のメモリ値の設定方式は複数の方式が考えられる。メモリ値自由設定方式では、メモリ値を自由に設定することができる。メモリ値を自由に設定することができるので、効率的にメモリを利用することができる。また、ブロック化ヒープ方式は、固定サイズの分割ヒープを予め複数用意しておく方式であり、メモリ値自由設定方式と比べて、ヒープメモリの再生成のオーバーヘッドがないという利点がある。<GCの実施例>GCは、分割ヒープ領域毎に行う方式とヒープ領域全体で行う方式とが考えられる。分割ヒープ領域毎に行う方式は、ヒープ領域全体で行う方式と比較して、ある分割ヒープ領域で頻繁にGCが起こる場合でも、他のヒープ領域は影響を受けることなく動作することができる。一方、ヒープ領域全体で行う方式は、分割ヒープ領域毎で行う方式と比較して、以下の利点がある。第1分割ヒープ領域の次にすぐに第2分割ヒープ領域のGCが発生する等、異なる分割ヒープ領域で頻繁にGCが起こるような状況においては、参照されているオブジェクトをルートから探索する動作が頻繁に起こってしまいオーバーヘッドになる。しかし、ヒープ領域全体でGCを行う場合には、一度に全てのオブジェクトを探索するためこのような、オーバーヘッドがなくなるという利点がある。"