(57)【特許請求の範囲】
【請求項１】
ＯＳＧｉ標準仕様に基づくバンドルが利用するメモリを管理するメモリ管理装置において、
１以上のバンドルを有するバンドル群に利用が許可されたメモリ量の情報を記憶手段から読み出して、当該メモリ量と同じ大きさのヒープ領域を確保する要求を行うメモリ管理バンドルと、
自機のヒープ領域から前記ヒープ領域を確保し、前記バンドル群が利用するメモリ領域を、当該ヒープ領域に割り当てるＪａｖａ仮想マシンと、を有し、
前記バンドル群を複数備え、当該複数のバンドル群は、あるスレッドにおいて呼び出し・呼び出される関係を有し、
前記メモリ管理バンドルは、
最初に呼び出しを行ったバンドル群のみについて前記要求を行い、当該バンドル群以外のバンドル群については前記要求を行わず、
前記Ｊａｖａ仮想マシンは、
全てのバンドル群が利用するメモリ領域を、最初に呼び出しを行ったバンドル群に対して確保されたヒープ領域に割り当てることを特徴とするメモリ管理装置。
【請求項２】
ＯＳＧｉ標準仕様に基づくバンドルが利用するメモリを管理するメモリ管理装置において、
１以上のバンドルを有するバンドル群に利用が許可されたメモリ量の情報を記憶手段から読み出して、当該メモリ量と同じ大きさのヒープ領域を確保する要求を行うメモリ管理バンドルと、
自機のヒープ領域から前記ヒープ領域を確保し、前記バンドル群が利用するメモリ領域を、当該ヒープ領域に割り当てるＪａｖａ仮想マシンと、を有し、
前記バンドル群を複数備え、当該複数のバンドル群は、あるスレッドにおいてバンドルの有する機能の提供・利用の関係を有する機能提供バンドル群および機能利用バンドル群であって、
前記メモリ管理バンドルは、
前記機能利用バンドル群のみについて前記要求を行い、前記機能提供バンドル群については前記要求を行わず、
前記Ｊａｖａ仮想マシンは、
前記機能提供バンドル群が利用するメモリ領域を、前記機能利用バンドル群に対して確保されたヒープ領域に割り当てることを特徴とするメモリ管理装置。
【請求項３】
ＯＳＧｉ標準仕様に基づくバンドルが利用するメモリを管理するメモリ管理方法において、
コンピュータにより、
１以上のバンドルを有するバンドル群に利用が許可されたメモリ量の情報を記憶手段から読み出して、当該メモリ量と同じ大きさのヒープ領域を確保する要求を行う第１ステップと、
自機のヒープ領域から前記ヒープ領域を確保し、前記バンドル群が利用するメモリ領域を、当該ヒープ領域に割り当てる第２ステップと、を有し、
前記バンドル群を複数備え、当該複数のバンドル群は、あるスレッドにおいて呼び出し・呼び出される関係を有し、
前記第１ステップは、
最初に呼び出しを行ったバンドル群のみについて前記要求を行い、当該バンドル群以外のバンドル群については前記要求を行わず、
前記第２ステップは、
全てのバンドル群が利用するメモリ領域を、最初に呼び出しを行ったバンドル群に対して確保されたヒープ領域に割り当てることを特徴とするメモリ管理方法。
【請求項４】
ＯＳＧｉ標準仕様に基づくバンドルが利用するメモリを管理するメモリ管理方法において、
コンピュータにより、
１以上のバンドルを有するバンドル群に利用が許可されたメモリ量の情報を記憶手段から読み出して、当該メモリ量と同じ大きさのヒープ領域を確保する要求を行う第１ステップと、
自機のヒープ領域から前記ヒープ領域を確保し、前記バンドル群が利用するメモリ領域を、当該ヒープ領域に割り当てる第２ステップと、を有し、
前記バンドル群を複数備え、当該複数のバンドル群は、あるスレッドにおいてバンドルの有する機能の提供・利用の関係を有する機能提供バンドル群および機能利用バンドル群であって、
前記第１ステップは、
前記機能利用バンドル群のみについて前記要求を行い、前記機能提供バンドル群については前記要求を行わず、
前記第２ステップは、
前記機能提供バンドル群が利用するメモリ領域を、前記機能利用バンドル群に対して確保されたヒープ領域に割り当てることを特徴とするメモリ管理方法。
【請求項５】
前記機能提供バンドル群は、機能を提供するプラットフォーム事業者により生成されたバンドル群であり、前記機能利用バンドル群は、機能を利用するサービス事業者により生成されたバンドル群である、又は、
前記機能提供バンドル群は、機能を提供するサービス事業者により生成されたバンドル群であり、前記機能利用バンドル群は、機能を利用するサービス事業者により生成されたバンドル群であることを特徴とする請求項４記載のメモリ管理方法。
【請求項６】
前記ヒープ領域で使用されているメモリ消費量を計算するステップを更に有することを特徴とする請求項３乃至５のいずれかに記載のメモリ管理方法。
【請求項７】
請求項３乃至６のいずれかに記載の各ステップをコンピュータに実行させることを特徴とするメモリ管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＯＳＧｉ標準仕様に基づくバンドルが利用するメモリを管理する技術に関する。
【背景技術】
【０００２】
〔ＯＳＧｉについて〕
ＯＳＧｉは、ソフトウェアのモジュール化技術である。ＯＳＧｉ標準仕様に基づくソフトウェアモジュールは、バンドルと呼ばれている。
【０００３】
システムアーキテクチャとしては、図１８に示すように、動作端末のＯＳ（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］、平成23年3月18日検索、＜URL : http://java.sun.com/docs/books/jvms/second_edition/html/VMSpecTOC.doc.html＞
【非特許文献２】「OSGi Alliance」、［Online］、平成23年4月1日検索、＜URL : http://www.osgi.org/Specifications/HomePage＞
【発明の概要】
【発明が解決しようとする課題】
【００２１】
従来の技術では、バンドル・ＯＳＧｉＦＷ・ＪａｖａＶＭがヒープ領域を共有するため、あるＥｎｔｉｔｙでＯＯＭエラーが発生してメモリが解放されない場合、その他のＥｎｔｉｔｙもその時点以降、新たにメモリを確保することができなくなり、結果的に全てのシステムが停止してしまう可能性がある。
【００２２】
特に課題となるのは、複数の事業者が従来の技術を用いて、１つのシステムを共有して同時にサービスを提供するような場合である。
【００２３】
例えば、プラットフォーム事業者（以下、ＰＦ事業者）は、ＪａｖａＶＭやＯＳＧｉＦＷなどのシステムの基盤となる部分をプラットフォームシステムとして提供し、サービス事業者（以下、ＳＰ事業者）は、自身が開発したバンドルをＰＦ事業者が提供するプラットフォームシステム上で動作させることでサービスを提供することを想定する。
【００２４】
この時、あるＳＰ事業者の作成するバンドルがバグ等により想定以上のメモリを消費すると、バグがなければ正常に動作可能であったはずの他のＥｎｔｉｔｙまで動作できなくなってしまう。他のＥｎｔｉｔｙとは、ＪａｖａＶＭ，ＯＳＧｉＦＷ，他のバンドル等である。
【００２５】
つまり、正常な動作をしているはずのＪａｖａＶＭ上で動作する全てのＥｎｔｉｔｙ（ＰＦ事業者の提供するシステムやＳＰ事業者のバンドル）が、１つのＳＰ事業者のバンドルのバグによって動作不能になることが発生する。
【００２６】
また、前述したように、ＯＳＧｉにおいてはバンドルやＯＳＧｉＦＷなどの構成要素が連携している。連携した時に消費されるメモリは、「呼び出し元」と「クラス提供」とのどちらのメモリ消費量としてカウントするかといった定義は、ＯＳＧｉやＪａｖａの仕様では定められていない（非特許文献１，非特許文献２参照）。定義が決まっていないため、バンドルのメモリ消費量の計測もできない。
【００２７】
本発明は、上記課題を鑑みてなされたものであり、その課題とするところは、メモリ消費量を任意の単位で制限することにある。
【課題を解決するための手段】
【００２８】
請求項１記載のメモリ管理装置は、ＯＳＧｉ標準仕様に基づくバンドルが利用するメモリを管理するメモリ管理装置において、１以上のバンドルを有するバンドル群に利用が許可されたメモリ量の情報を記憶手段から読み出して、当該メモリ量と同じ大きさのヒープ領域を確保する要求を行うメモリ管理バンドルと、自機のヒープ領域から前記ヒープ領域を確保し、前記バンドル群が利用するメモリ領域を、当該ヒープ領域に割り当てるＪａｖａ仮想マシンと、を有し、前記バンドル群を複数備え、当該複数のバンドル群は、あるスレッドにおいて呼び出し・呼び出される関係を有し、前記メモリ管理バンドルは、最初に呼び出しを行ったバンドル群のみについて前記要求を行い、当該バンドル群以外のバンドル群については前記要求を行わず、前記Ｊａｖａ仮想マシンは、全てのバンドル群が利用するメモリ領域を、最初に呼び出しを行ったバンドル群に対して確保されたヒープ領域に割り当てることを特徴とする。
【００２９】
本発明によれば、バンドル群が利用するメモリ領域を、当該バンドル群に利用が許可されたメモリ量と同じ大きさで確保されたヒープ領域に割り当てるため、バンドル群が消費するメモリ消費量を任意の単位で制限できる。
【００３０】
請求項２記載のメモリ管理装置は、ＯＳＧｉ標準仕様に基づくバンドルが利用するメモリを管理するメモリ管理装置において、１以上のバンドルを有するバンドル群に利用が許可されたメモリ量の情報を記憶手段から読み出して、当該メモリ量と同じ大きさのヒープ領域を確保する要求を行うメモリ管理バンドルと、自機のヒープ領域から前記ヒープ領域を確保し、前記バンドル群が利用するメモリ領域を、当該ヒープ領域に割り当てるＪａｖａ仮想マシンと、を有し、前記バンドル群を複数備え、当該複数のバンドル群は、あるスレッドにおいてバンドルの有する機能の提供・利用の関係を有する機能提供バンドル群および機能利用バンドル群であって、前記メモリ管理バンドルは、前記機能利用バンドル群のみについて前記要求を行い、前記機能提供バンドル群については前記要求を行わず、前記Ｊａｖａ仮想マシンは、前記機能提供バンドル群が利用するメモリ領域を、前記機能利用バンドル群に対して確保されたヒープ領域に割り当てることを特徴とする。
【００３４】
請求項３記載のメモリ管理方法は、ＯＳＧｉ標準仕様に基づくバンドルが利用するメモリを管理するメモリ管理方法において、コンピュータにより、１以上のバンドルを有するバンドル群に利用が許可されたメモリ量の情報を記憶手段から読み出して、当該メモリ量と同じ大きさのヒープ領域を確保する要求を行う第１ステップと、自機のヒープ領域から前記ヒープ領域を確保し、前記バンドル群が利用するメモリ領域を、当該ヒープ領域に割り当てる第２ステップと、を有し、前記バンドル群を複数備え、当該複数のバンドル群は、あるスレッドにおいて呼び出し・呼び出される関係を有し、前記第１ステップは、最初に呼び出しを行ったバンドル群のみについて前記要求を行い、当該バンドル群以外のバンドル群については前記要求を行わず、前記第２ステップは、全てのバンドル群が利用するメモリ領域を、最初に呼び出しを行ったバンドル群に対して確保されたヒープ領域に割り当てることを特徴とする。
【００３５】
本発明によれば、全てのバンドル群が利用するメモリ領域を、最初に呼び出しを行ったバンドル群に対して確保されたヒープ領域に割り当てるため、メモリ消費量をスレッド単位でカウントでき、当該カウント方法によってメモリ消費量を制限できる。
【００３６】
請求項４記載のメモリ管理方法は、ＯＳＧｉ標準仕様に基づくバンドルが利用するメモリを管理するメモリ管理方法において、コンピュータにより、１以上のバンドルを有するバンドル群に利用が許可されたメモリ量の情報を記憶手段から読み出して、当該メモリ量と同じ大きさのヒープ領域を確保する要求を行う第１ステップと、自機のヒープ領域から前記ヒープ領域を確保し、前記バンドル群が利用するメモリ領域を、当該ヒープ領域に割り当てる第２ステップと、を有し、前記バンドル群を複数備え、当該複数のバンドル群は、あるスレッドにおいてバンドルの有する機能の提供・利用の関係を有する機能提供バンドル群および機能利用バンドル群であって、前記第１ステップは、前記機能利用バンドル群のみについて前記要求を行い、前記機能提供バンドル群については前記要求を行わず、前記第２ステップは、前記機能提供バンドル群が利用するメモリ領域を、前記機能利用バンドル群に対して確保されたヒープ領域に割り当てることを特徴とする。
【００３７】
本発明によれば、機能提供バンドル群が利用するメモリ領域を、機能利用バンドル群に対して確保されたヒープ領域に割り当てるため、メモリ消費量を機能利用バンドル群単位でカウントでき、当該カウント方法によってメモリ消費量を制限できる。
【００３８】
請求項５記載のメモリ管理方法は、請求項４記載のメモリ管理方法において、前記機能提供バンドル群は、機能を提供するプラットフォーム事業者により生成されたバンドル群であり、前記機能利用バンドル群は、機能を利用するサービス事業者により生成されたバンドル群である、又は、前記機能提供バンドル群は、機能を提供するサービス事業者により生成されたバンドル群であり、前記機能利用バンドル群は、機能を利用するサービス事業者により生成されたバンドル群であることを特徴とする。
【００３９】
請求項６記載のメモリ管理方法は、請求項３乃至５のいずれかに記載のメモリ管理方法において、前記ヒープ領域で使用されているメモリ消費量を計算するステップを更に有する。
【００４０】
本発明によれば、請求項３乃至５のいずれかに記載されたヒープ領域で使用されているメモリ消費量を計算するため、制限対象毎にメモリ消費量を計測できる。
【００４１】
請求項７記載のメモリ管理プログラムは、請求項３乃至６のいずれかに記載の各ステップをコンピュータに実行させることを特徴とする。
【発明の効果】
【００４２】
本発明によれば、メモリ消費量を任意の単位で制限することができる。
【図面の簡単な説明】
【００４３】
【図１】メモリ管理装置の構成を示す図である。
【図２】メモリ管理装置の構成を説明する図である。
【図３】外部サーバを有するメモリ管理システムの構成を示す図である。
【図４】象限ａのスタックを示す図である。
【図５】象限ｂのスタックを示す図である。
【図６】象限ｃのスタックを示す図である。
【図７】象限ｄのスタックを示す図である。
【図８】象限ａ〜ｄのスタックの関係を示す表である。
【図９Ａ】各ヒープ選択アルゴリズム説明時に参照されるスタックの具体例を示す図である。
【図９Ｂ】各ヒープ選択アルゴリズム説明時に参照されるスタックの具体例を示す図である。
【図１０】第１ヒープ選択アルゴリズムの動作を示すフローチャートである。
【図１１】第２ヒープ選択アルゴリズムの動作を示すフローチャートである。
【図１２】第３ヒープ選択アルゴリズムの動作を示すフローチャートである。
【図１３】呼び出し元・クラス提供スタックの関係を示す表である。
【図１４】第４ヒープ選択アルゴリズムの動作を示すフローチャートである。
【図１５】呼び出し元・クラス提供スタックの関係を示す表である。
【図１６】ＰＦセットの呼び出し関数の一例を示す図である。
【図１７】第５ヒープ選択アルゴリズムの動作を示すフローチャートである。
【図１８】ＯＳＧｉのシステムアーキテクチャを示す図である。
【図１９】ＯＳＧｉサービスによるバンドル間の連携を示す図である。
【図２０】バンドル機能の提供・利用を示す図である。
【図２１】バンドル機能の利用・提供を示す図である。
【図２２】メモリ割当を説明する図である。
【図２３】ＪａｖａＶＭのスタック構造を説明する図である。
【発明を実施するための形態】
【００４４】
以下、本発明を実施する一実施の形態について図面を用いて説明する。但し、本発明は多くの異なる様態で実施することが可能であり、本実施の形態の記載内容に限定して解釈すべきではない。
【００４５】
〔メモリ管理装置の構成について〕
まず、メモリ管理装置１の構成について説明する。
【００４６】
図１は、本実施の形態に係るメモリ管理装置の構成を示す図である。このメモリ管理装置１は、ＯＳＧｉ標準仕様に基づくバンドルが利用（確保・消費）するメモリを管理する装置であって、ＯＳ上で動作するＪａｖａＶＭ１０と、ＪａｖａＶＭ上でバンドルの実行環境を提供するＯＳＧｉＦＷ１１と、ＯＳＧｉＦＷ上でＪａｖａプログラムとして動作する複数のオーナーバンドル１２および複数のＳＰバンドルセット１３とで主に構成される。
【００４７】
なお、図２に示すように、ＰＦ事業者が作成するバンドルをオーナーバンドル１２とし、ＳＰ事業者がサービスを提供するために作成するバンドルをＳＰバンドル１３１とする。
【００４８】
また、１以上のバンドルで構成されるバンドル群をバンドルセットとし、ＳＰ事業者が作成するＳＰバンドル群をＳＰバンドルセット１３、ＰＦ事業者がプラットフォームシステムとして作成するＪａｖａＶＭ１０とＯＳＧｉＦＷ１１とオーナーバンドル１２とをＰＦセット１４とする。ＰＦセット１４は本実施の形態において１つであり、ＳＰバンドルセット１３は複数考えられる。
【００４９】
ＪａｖａＶＭ１０には、従来技術にない標準外の機能を備えている（図１の改造部等参照）。また、ＪａｖａＶＭ１０に独自のＡＰＩを持たせ、ＪａｖａＶＭ１０に所定の情報（後述）を設定するために、メモリ管理バンドル１２ａをオーナーバンドル１２の１つとして用意する。
【００５０】
メモリ管理バンドル１２ａは、１つのバンドルセットを構成するバンドルの情報（以下、バンドルセット情報）と、そのバンドルセットに利用許可されるメモリ量（以下、バンドルセットメモリ量）との情報を、通信ネットワークを介して接続されたサーバ３等から取得して記憶手段に一旦記憶し、当該記憶手段から読み出して取得する機能を有する。
【００５１】
ここで、バンドルセット情報とは、ＯＳＧｉ仕様で定められるＢｕｎｄｌｅ−ＳｙｍｂｏｌｉｃＮａｍｅとＢｕｎｄｌｅ−Ｖｅｒｓｉｏｎとによってバンドルを一意に識別した識別子であり、識別したバンドルが１つ以上指定される。
【００５２】
なお、サーバ３は、図３に示すように、メモリ管理装置１とは別装置として外部に設置されており、メモリ管理装置１と通信を行う。バンドルセット情報等の受け渡しはＸＭＬファイル等の様々な方法が考えられる。なお、バンドルセット情報等については、サーバ３と通信を行い取得するのではなく、自機の記憶手段に予め保持しておき読み出すのでもよい。
【００５３】
また、メモリ管理バンドル１２ａは、バンドルセット情報およびバンドルセットメモリ量を取得した後、ＪａｖａＶＭ１０が提供する第１ＡＰＩ（後述）を通じて、ＪａｖａＶＭ１０に対して、取得したバンドルセットメモリ量と同じ大きさの分割ヒープ領域を生成する要求を行い、生成された分割ヒープ領域を識別するＩＤ（以下、ヒープＩＤ）を取得する機能を有する。
【００５４】
また、メモリ管理バンドル１２ａは、あるバンドルセットに属するバンドルがＯＳＧｉＦＷ上にインストールされＲＥＳＯＬＶＥイベントを受信した際に、そのバンドルのクラスローダオブジェクトをＯＳＧｉ標準ＡＰＩおよびＪａｖａ標準ＡＰＩ（以下、標準ＡＰＩ）を通じて取得し、ＪａｖａＶＭ１０が提供する第２ＡＰＩ（後述）を通じて、ＪａｖａＶＭ１０に対して、バンドルクラスローダオブジェクトとヒープＩＤとを組にした情報を送信する機能を有する。
【００５５】
ＪａｖａＶＭ１０は、外部設計として、第１ＡＰＩおよび第２ＡＰＩを有する。第１ＡＰＩは、バンドルセットメモリ量を引数に取り、指定されたバンドルセットメモリ量を持つ分割ヒープ領域を新規に生成して、その生成された分割ヒープ領域のヒープＩＤを返す機能を有する。
【００５６】
第２ＡＰＩは、クラスローダオブジェクトとヒープＩＤとを引数に取り、指定されたクラスローダオブジェクトからロードされるバンドルが確保（消費）するメモリ領域を、指定されたヒープＩＤの分割ヒープ領域から確保する要求を受け付ける機能を有する。
【００５７】
一方、ＪａｖａＶＭ１０は、内部設計として、クラスローダオブジェクトに対してヒープＩＤを設定可能なデータ構造が追加されている。第１ＡＰＩが呼び出された時には、分割ヒープ領域を生成する機能を有する。第２ＡＰＩが呼び出された時には、指定されたクラスローダオブジェクトのデータ構造に、指定されたヒープＩＤを設定する機能を有する。
【００５８】
また、指定されたヒープＩＤの分割ヒープ領域に、バンドルが確保（消費）するメモリ領域を割り当てる機能、又は、ヒープ選択アルゴリズム（後述）によりヒープＩＤを決定し、決定されたヒープＩＤの分割ヒープ領域に、バンドルが確保（消費）するメモリ領域を割り当てる機能を有する。
【００５９】
なお、分割ヒープ領域内でメモリ不足の場合（例えば、ＳＰバンドルセット毎に必要なメモリ量が確保できない場合）には、分割ヒープ領域ごとにＯＯＭエラーを発生させる。
【００６０】
〔メモリ管理装置の動作について〕
次に、メモリ管理装置１の動作について説明する。なお、理解を容易にするため、以降では、ＳＰバンドルセット１３のＳＰバンドル１３１を例に用いて説明する。また、その場合におけるバンドルセット情報を、ＳＰバンドルセット情報と記載する。
【００６１】
最初に、メモリ管理バンドル１２ａが、通信ネットワークを介して接続された外部のサーバ３から、ＳＰバンドルセット情報とＳＰバンドルセットメモリ量とを取得する（Ｓ１）。
【００６２】
次に、Ｓ１の後、Ｓ１で取得対象であったＳＰバンドルセット１３のＳＰバンドル１３１がメモリ管理装置１にインストールされＲＥＳＯＬＶＥイベントを受信した際に、メモリ管理バンドル１２ａは、ＪａｖａＶＭ１０の第１ＡＰＩを呼び出して、Ｓ１で取得したＳＰバンドルセットメモリ量の大きさの分割ヒープ領域を生成する要求を行い、生成された分割ヒープ領域に対して設定されたヒープＩＤを取得する（Ｓ２）。
【００６３】
このとき、ＪａｖａＶＭ１０は、ＯＳから割り当てられた１つのヒープ領域を分割して、上記ＳＰバンドルセットメモリ量と同じの大きさの分割ヒープ領域を生成し、ヒープＩＤを返す（Ｓ２’）。
【００６４】
Ｓ２，Ｓ２’の後、メモリ管理バンドル１２ａは、インストールされたＳＰバンドル１３１のクラスローダオブジェクトを標準ＡＰＩを利用して取得し、取得したクラスローダオブジェクトと、Ｓ２で取得したヒープＩＤとを指定してＪａｖａＶＭ１０の第２ＡＰＩを呼び出す（Ｓ３）。
【００６５】
最後に、ＪａｖａＶＭ１０は、Ｓ３で指定されたヒープＩＤの分割ヒープ領域、又は、採用するヒープ選択アルゴリズム（後述）に基づいて決定されたヒープＩＤの分割ヒープ領域に、インストールされたＳＰバンドル１３１が確保（消費）するメモリ領域を割り当てる（Ｓ４）。これより、ＳＰバンドル１３１は、割り当てられた分割ヒープ領域を用いて自身のプログラムを実行する。
【００６６】
以上より、ＳＰバンドルセット１３に利用許可されたバンドルセットメモリ量と同じ大きさの分割ヒープ領域を生成し、生成された分割ヒープ領域、又は、ヒープ選択アルゴリズムに基づいて決定された分割ヒープ領域に、ＳＰバンドルセット１３のＳＰバンドル１３１が確保（消費）するメモリ領域を割り当てるので、ＳＰバンドル１３１が消費するメモリ消費量を任意の単位で制限できる。
【００６７】
また、分割ヒープ領域を生成するので、従来技術では１つだったヒープ領域を複数持たせることができる。
【００６８】
また、割り当てられる分割ヒープ領域を、ヒープ選択アルゴリズムに基づいて決定するので、制限する単位を変更できる。
【００６９】
また、第２ＡＰＩで設定する情報は、ヒープ選択アルゴリズムで参照される。テーブルなどの検索を行うことなく、スタックからポインタ参照で辿れる情報のみを利用しているので、プログラム動作中のメモリ割当における速度低下を低減できる。
【００７０】
また、特に、ヒープ選択アルゴリズムに基づいて決定された分割ヒープ領域にＳＰバンドル１３１が消費するメモリ領域を割り当てるので、ＰＦセット１４やＳＰバンドルセット１３が消費するヒープ領域を、ヒープアルゴリズムの効果の単位で制限することが可能になる。
【００７１】
なお、本実施の形態では、サーバ３から取得されるバンドルセット情報等のバンドル、ＪａｖａＶＭ１０に対して生成要求される分割ヒープ領域のバンドル、クラスローダからロードされるバンドル、メモリ領域が割り当てられて確保（消費）されるバンドル等の全てについて、前述したようにＳＰバンドル１３１を例に用いて説明したが、これはあくまでも一例である。
【００７２】
ＳＰバンドル１３１に代えて、又は加えて、１以上のバンドルを有するバンドル群であるＳＰバンドルセット１３やＰＦセット１４、ＰＦセット１４に含まれるオーナーバンドルを用いることも可能である。
【００７３】
また、本実施の形態では、１つのヒープ領域を分割して分割ヒープ領域を生成する方法を例に説明したが、これはあくまでも一例である。ＳＰバンドルセットメモリ量と同じ大きさのヒープ領域を新たに生成する方法や、元々のヒープ領域を分割する方法も利用できる。
【００７４】
すなわち、利用が許可されたメモリ量と同じ大きさのヒープ領域を自機のヒープ領域から確保して、そのヒープ領域にバンドル群が利用するメモリ領域を割り当てるのであれば、どのような方法も採用できる。
【００７５】
〔ヒープ選択アルゴリズム〕
次に、ヒープ選択アルゴリズムについて説明する。
【００７６】
前述したように、メモリ割当を分割ヒープ領域に行う際、メモリ割当を行うヒープＩＤを選択するヒープ選択アルゴリズムによって、どの単位でメモリ消費量を制限できるかが変化することになる。本実施の形態では、一例として、４つのヒープ選択アルゴリズムについて説明する。
【００７７】
ここで、ＰＦセット１４とＳＰバンドルセット１３との関係性を考える。ＰＦセット１４とＳＰバンドルセット１３とのどちらがクラス提供側・呼び出し側になるのかは、以下の４通り（２×２通り）が考えられる。
【００７８】
象限ａ）呼び出し側  ：ＰＦセット。
【００７９】
クラス提供側：ＰＦセット。
【００８０】
象限ｂ）呼び出し側  ：ＳＰバンドルセットＹ（ＳＰ＿Ｙ）。
【００８１】
クラス提供側：ＰＦセット。
【００８２】
象限ｃ）呼び出し側  ：ＰＦセット。
【００８３】
クラス提供側：ＳＰバンドルセットＸ（ＳＰ＿Ｘ）。
【００８４】
象限ｄ）呼び出し側  ：ＳＰバンドルセット（ＳＰ＿Ｙ）。
【００８５】
クラス提供側：ＳＰバンドルセット（ＳＰ＿Ｘ）。
【００８６】
なお、象限ｂと象限ｃとについては、ＰＦセットにとってはいずれもＳＰバンドルセットであるので、ＳＰバンドルセットはＸでもＹでも良いが、ここでは便宜上区別している。
【００８７】
それら各象限についてスタックで表すと、それぞれ、図４〜図７に示すようなスタックになる。これらを表で表すと、図８に示すようになる。
【００８８】
また、後述する各ヒープ選択アルゴリズムにおいて、どの分割ヒープ領域が選択されるかを表す具体的な例として、図９Ａ（ａ）に示すように、一番下のスタックをスタック［０］のＰＦセットのスタックとして積み重なったスタックを用いる。
【００８９】
なお、各スタック内の模様は、各スタック（すなわち、各クラス）で消費されるメモリ領域が、ＳＰバンドルセット１（以下、ＳＰ＿ＢＳ１），ＳＰバンドルセット２（以下、ＳＰ＿ＢＳ２），ＰＦセットのどのメモリ消費量としてカウントされるかを表す。また、各スタック内の文字は、各スタックを生成したクラスの提供元を表す。
【００９０】
すなわち、ＪａｖａＶＭ上で動作するあるスレッドにおける、図９Ａ（ａ）のスタックについて言えば、スタック［０］においてＰＦセット（のクラス、以下省略）がＳＰ＿ＢＳ１（のクラス、以下省略）を呼び出してスタック［１］とし、スタック［１］のＳＰ＿ＢＳ１がＰＦセットを呼び出してスタック［２］とし、スタック［２］のＰＦセットがＰＦセットを呼び出してスタック［３］とし、スタック［３］のＰＦセットがＳＰ＿ＢＳ２を呼び出してスタック［４］とし、スタック［４］のＳＰ＿ＢＳ２がＳＰ＿ＢＳ１を呼び出してスタック［５］とし、スタック［５］のＳＰ＿ＢＳ１がＰＦセットを呼び出してスタック［６］としている。そして、最後に呼び出された一番上のスタック［６］から処理が順次行われる。
【００９１】
以下、ヒープ選択アルゴリズムを説明する前に、用語の定義を行う。定数を大文字、変数の頭文字は小文字で表す（ここでの定数は、１回のヒープ選択アルゴリズムにおいて代入がない値を指す）。ヒープ選択アルゴリズムは、最終的にメモリ割当を行うヒープＩＤである変数ｈｅａｐＩＤを決定するためのアルゴリズムである。
【００９２】
クラスローダに設定されているヒープＩＤをＣＬ＿ＨＥＡＰＩＤとする。ＰＦセットのＣＬ＿ＨＥＡＰＩＤをＨＥＡＰＩＤ＿ＰＦとする。ＳＰバンドルセットのＣＬ＿ＨＥＡＰＩＤをＨＥＡＰＩＤ＿ＳＰとする。各スタックにて処理が行われるクラスのＣＬ＿ＨＥＡＰＩＤをＳＴＡＣＫ＿ＨＥＡＰＩＤとする。
【００９３】
スタックを１つずつ下に辿っていくにあたり、現在調べているスタックを表す変数をｃｕｒＳｔａｃｋとする。ｈｅａｐＩＤを決定するために一時的に利用する変数をｃｕｒｈｅａｐＩＤとする。各スレッドの一番上のスタックをＴＯＰＳＴＡＣＫとする。
【００９４】
ｃｕｒＳｔａｃｋがスレッドを下まで辿り、最後のスタックの次を指定した場合、Ｎｕｌｌを指すとする。
【００９５】
ヒープメモリの確保はスレッドの一番上のスタックで実行されるので、ヒープ選択アルゴリズムは、常にＴＯＰＳＴＡＣＫにおいてメモリ割当が必要となる度に実行される。
【００９６】
＜第１ヒープ選択アルゴリズム＞
第１ヒープ選択アルゴリズムの動作を示すフローチャートを図１０に示す。なお、以下説明する全てのヒープ選択アルゴリズムの主体は、ＪａｖａＶＭ１０である。
【００９７】
ＴＯＰＳＴＡＣＫのＳＴＡＣＫ＿ＨＥＡＰＩＤをｈｅａｐＩＤとする（Ｓ１０１）。
【００９８】
すなわち、図９Ａ（ｂ）に示すように、各スタックのクラスが確保（消費）するメモリ領域を、各スタックのクラスに対してそれぞれ生成された分割ヒープ領域にそれぞれ割り当てるようにしている。
【００９９】
以上より、各スタックのクラスが確保（消費）するメモリ領域を、各スタックのクラスに対してそれぞれ生成された分割ヒープ領域にそれぞれ割り当てるので、呼び出し元に関わらず、実装クラスのセット単位（すなわち、ＰＦセットやＳＰバンドルセットのバンドル群単位）でメモリ消費量をカウントでき、当該カウント方法によってメモリ消費量を制限できる。
【０１００】
＜第２ヒープ選択アルゴリズム＞
第２ヒープ選択アルゴリズムの動作を示すフローチャートを図１１に示す。第２ヒープ選択アルゴリズムは、スタックを１つずつ下に辿り、呼び出し元となるスタックを探索するアルゴリズムである。各スタックは、あるスレッドにおいて呼び出し・呼び出される関係にある。
【０１０１】
最初に、ｃｕｒＳｔａｃｋにＴＯＰＳＴＡＣＫを代入する（Ｓ２０１）。
【０１０２】
次に、ｃｕｒＳｔａｃｋがＮｕｌｌならばＳ２０４に進み、それ以外であればＳ２０３に進む（Ｓ２０２）。
【０１０３】
次に、ｃｕｒＳｔａｃｋを１つ下のスタックにする（Ｓ２０３）。
【０１０４】
最後に、ｃｕｒＳｔａｃｋのＳＴＡＣＫ＿ＨＥＡＰＩＤをｈｅａｐＩＤとする（Ｓ２０４）。
【０１０５】
つまり、ＴＯＰＳＴＡＣＫの呼び出し元スタックを、その呼び出し元スタックの呼び出し元スタックを…と繰り返して呼び出し元を辿っていく。結果的に、スレッドの一番下のスタックのクラスローダに設定されているヒープＩＤを参照する。
【０１０６】
すなわち、全てのスタックのクラスが確保（消費）するメモリ領域を、最初に呼び出しを行ったスタックのクラスに対して生成された分割ヒープ領域に割り当てるようにしている。
【０１０７】
なお、このアルゴリズムを実行すると、スタックの例としては図９Ａ（ｃ）に示すようになる。例えば、スタック［６］が確保（消費）するメモリ領域が、どのようにカウントされるかを以下説明する。
【０１０８】
スタック［６］を呼び出したのはスタック［５］であり、スタック［５］を呼び出したのはスタック［４］である。スタック［４］を呼び出したのはスタック［３］であり、スタック［３］を呼び出したのはスタック［２］である。スタック［２］を呼び出したのはスタック［１］であり、スタック［１］を呼び出したのはスタック［０］である。
【０１０９】
スタック［０］には呼び出し元がないため、結果的にスタック［６］のメモリ消費量はスタック［０］が呼び出したとカウントされ、スタック［０］のＰＦセットのメモリ消費量としてカウントされる。
【０１１０】
スタック［６］の処理が行われた後、スタック［６］はスレッドからなくなりスタック［５］がＴＯＰＳＴＡＣＫになる。スタック［５］〜［０］でも同様の処理が行われるので、全て、スタック［０］が呼び出したメモリとカウントされる。
【０１１１】
以上より、全てのスタックのクラスが確保（消費）するメモリ領域を、最初に呼び出しを行ったスタックのクラスに対する分割ヒープ領域に割り当てるので、メモリ消費量をスレッド単位でカウントでき、当該カウント方法によってメモリ消費量を制限できる。
【０１１２】
＜第３ヒープ選択アルゴリズム＞
第３ヒープ選択アルゴリズムの動作を示すフローチャートを図１２に示す。第３ヒープ選択アルゴリズムは、ＴＯＰＳＴＡＣＫでメモリ割当が起こるたびに分割ヒープを選択するアルゴリズムである。
【０１１３】
最初に、ｈｅａｐＩＤにＨＥＡＰＩＤ＿ＰＦを代入する（Ｓ３０１）。
【０１１４】
次に、ｃｕｒＳｔａｃｋにＴＯＰＳＴＡＣＫを代入する（Ｓ３０２）。
【０１１５】
次に、ｃｕｒｈｅａｐＩＤにＳＴＡＣＫ＿ＨＥＡＰＩＤを代入する（Ｓ３０３）。
【０１１６】
次に、ｃｕｒｈｅａｐＩＤがＨＥＡＰＩＤ＿ＰＦならばＳ３０５に進み、それ以外であればＳ３０６に進む（Ｓ３０４）。
【０１１７】
次に、ｈｅａｐＩＤがＨＥＡＰＩＤ＿ＳＰならばｈｅａｐＩＤに入っている値が本アルゴリズムによって選択された分割ヒープ領域として処理を終了し、それ以外であればＳ３０６に進む（Ｓ３０５）。
【０１１８】
次に、ｈｅａｐＩＤにｃｕｒｈｅａｐＩＤを代入する（Ｓ３０６）。
【０１１９】
次に、ｃｕｒＳｔａｃｋを１つ下のスタックにする（Ｓ３０７）。
【０１２０】
最後に、ｃｕｒＳｔａｃｋがＮｕｌｌならばｈｅａｐＩＤに入っている値が本アルゴリズムによって選択された分割ヒープ領域として処理を終了し、そうでないならばＳ３０３に戻る（Ｓ３０８）。
【０１２１】
つまり、（バンドルの有する）機能提供者であるＰＦ事業者によって生成されたＰＦセットと、機能利用者であるＳＰ事業者によって生成されたＳＰバンドルセット間の関係において、メモリ消費量は呼び出し・クラス提供に関わらず、機能を利用しているＳＰバンドルセットのメモリ消費量としてカウントされる。
【０１２２】
すなわち、機能を提供するＰＦセット（機能提供バンドル群）が確保（消費）するメモリ領域を、機能を利用するＳＰバンドルセット（機能利用バンドル群）に対して生成された分割ヒープ領域に割り当てるようにしている。
【０１２３】
なお、システムの基盤となるＰＦセットが、ＳＰバンドルセットを利用することによってＰＦセットのための機能を実現することはあり得ない。
【０１２４】
例えば、象限ｂの例として、ＰＦの共通的な機能としてＰＦセットがＨｔｔｐＳｅｒｖｉｃｅを実装したバンドルを提供することが考えられる。ＳＰバンドルはＨｔｔｐＳｅｒｖｉｃｅを取得し、呼び出すことによりＰＦセットの提供するＨｔｔｐＳｅｒｖｉｃｅの機能を利用する。
【０１２５】
また、象限ｃの代表例は、ＯＳＧｉ仕様で定義されるＢｕｎｄｌｅＡｃｔｉｖａｔｏｒ＃ｓｔａｒｔの呼び出しである。呼び出すのはＯＳＧｉＦＷ、つまりＰＦセットであるが、ＳＰバンドルがクラス提供した理由は、ＰＦセットが提供する「ＳＰバンドルを対象端末上で起動する機能」を利用する為である。
【０１２６】
どのような場合においても、象限ｃは、背景技術で説明した通りコールバック型、つまりクラス提供側であるＳＰバンドルセットが機能を利用する形となる。
【０１２７】
但し、象限ａやｄ、つまりＰＦセットがＰＦセットを呼び出した場合や、ＳＰバンドルセットがＳＰバンドルセットを呼び出した場合は、機能の提供利用によらず、呼び出したＳＰバンドルセットのメモリ消費量とカウントする。
【０１２８】
呼び出し元・クラス提供スタックの関係を表すと、図１３に示すようになる。この図は、２つのスタックの関係において、上のスタック（クラス提供スタック）で消費されたメモリが、呼び出し元スタックとクラス提供スタックどちらのスタックにカウントされるかを示している。
【０１２９】
ここで、スタックが複数積み重なった例を、図９Ａ（ｄ）を用いて説明する。まず、ＰＦセットのクラスにあたるスタック［６］で消費されるメモリ量は、呼び出し元スタック［５］がＳＰバンドルセット１なので、呼び出し元スタック［５］が消費したメモリ量としてカウントされる（象限ｂ）。
【０１３０】
ＳＰバンドルセット１であるスタック［５］で消費されるメモリ量は、呼び出し元スタック［４］がＳＰバンドルセット２なので、呼び出し元スタック［４］で消費されるメモリとしてカウントされる（象限ｄ）。
【０１３１】
スタック［４］で消費されるメモリ量は、呼び出元スタック［３］がＰＦセットなので、クラス提供スタック［４］で消費されるメモリ量とカウントされる（象限ｃ）。
【０１３２】
よって、スタック［４］〜［６］において消費されるメモリ量は、スタック［４］に該当するクラスを提供するＳＰバンドルセット２が消費するメモリ量としてカウントされる。
【０１３３】
同様に、スタック［３］で消費されるメモリ量は、呼び出し元スタック［２］がＰＦセットなので、呼び出し元スタック［２］の消費メモリとカウントとされる（象限ａ）。
【０１３４】
スタック［２］で消費されるメモリ量は、呼び出し元スタック［１］がＳＰバンドルセット１なので、呼び出し元スタック［１］の消費メモリとカウントとされる（象限ｂ）。
【０１３５】
スタック［１］で消費されるメモリ量は、呼び出し元スタック［０］がＰＦセットなので、クラス提供スタック［１］で消費されるメモリ量とカウントされる（象限ｃ）。
【０１３６】
よって、スタック［１］〜［３］において消費されるメモリ量は、スタック［１］に該当するクラスを提供するＳＰバンドルセット１が消費するメモリ量としてカウントされる。
【０１３７】
最後に、スタック［０］で消費されるメモリ量は、呼び出し元スタックが存在しないので、クラス提供スタックであるスタック［０］が消費しているメモリ量とカウントとする。
【０１３８】
よって、スタック［０］で消費されるメモリ量は、スタック［０］に該当するクラスを提供するＰＦセットが消費するメモリ量としてカウントされる。
【０１３９】
以上より、機能を提供するＰＦセットが確保（消費）するメモリ領域を、機能を利用するＳＰバンドルセットに対する分割ヒープ領域に割り当てるので、メモリ消費量を、機能を利用するバンドルセット単位でカウントでき、当該カウント方法によってメモリ消費量を制限できる。
【０１４０】
＜第４ヒープ選択アルゴリズム＞
第３ヒープ選択アルゴリズムでは、機能の提供・利用の関係について、機能を提供するＰＦセットと機能を利用するＳＰバンドルセットとを用いて説明した。
【０１４１】
一方、同関係はＳＰバンドルセット同士にもあるため、第４ヒープ選択アルゴリズムではその場合について説明する。
【０１４２】
以下説明する第４ヒープ選択アルゴリズムを実現するために、メモリ管理バンドル１２ａおよびＪａｖａＶＭ１０に対して以下の機能を追加する。
【０１４３】
メモリ管理バンドル１２ａは、ＳＰバンドル１３１のクラスが機能の提供・利用どちらを行うクラスかの情報を入手する機能を更に有する。また、ＪａｖａＶＭ１０が提供する第３ＡＰＩ（後述）を通じて、ＪａｖａＶＭ１０に対して、クラスごとに機能の提供・利用（Call Back Flag、以下、ＣＢＦ）を設定する要求を行う機能を更に有する。
【０１４４】
ＪａｖａＶＭ１０は、外部設計として、クラスオブジェクトとＣＢＦとを引数に取り、指定されたクラスが機能を提供するクラスか機能を利用するクラスかをＪａｖａＶＭ１０に設定する第３ＡＰＩを有する。内部設計として、クラスオブジェクトのデータ構造にＣＢＦを設定できるデータ構造を用意し、第３ＡＰＩが呼び出された時に、指定されたクラスオブジェクトのデータ構造に指定されたＣＢＦを設定する機能を有する。
【０１４５】
このような機能を有する際のメモリ管理装置１の動作について以下説明する。
【０１４６】
最初に、メモリ管理バンドル１２ａが、通信ネットワークを介して接続された外部のサーバ３から、ＳＰバンドルセット情報とＳＰバンドルセットメモリ量とを取得すると共に、当該取得対象であるＳＰバンドルセット１３のＳＰバンドル１３１のクラスにセットするＣＢＦを取得する（Ｓ１１）。
【０１４７】
次に、Ｓ１１の後、Ｓ１１で取得対象であったＳＰバンドルセット１３のＳＰバンドル１３１がメモリ管理装置１にインストールされＲＥＳＯＬＶＥイベントを受信した際に、メモリ管理バンドル１２ａは、ＪａｖａＶＭ１０の第１ＡＰＩを呼び出して、Ｓ１１で取得したＳＰバンドルセットメモリ量の大きさの分割ヒープ領域を生成する要求を行い、生成された分割ヒープ領域に対して設定されたヒープＩＤを取得する（Ｓ１２）。
【０１４８】
このとき、ＪａｖａＶＭ１０は、ＯＳから割り当てられた１つのヒープ領域を分割して、上記ＳＰバンドルセットメモリ量と同じの大きさの分割ヒープ領域を生成し、ヒープＩＤを返す（Ｓ１２’）。
【０１４９】
Ｓ１２，Ｓ１２’の後、メモリ管理バンドル１２ａは、インストールされたＳＰバンドル１３１のクラスローダオブジェクトを標準ＡＰＩを利用して取得し、取得したクラスローダオブジェクトとＳ１２で取得したヒープＩＤとを指定してＪａｖａＶＭ１０の第２ＡＰＩを呼び出す（Ｓ１３）。
【０１５０】
また、Ｓ１３で取得したクラスローダオブジェクトとＳ１１で取得したＣＢＦとを指定し、第３ＡＰＩを呼び出す（Ｓ１４）。
【０１５１】
最後に、ＪａｖａＶＭ１０は、Ｓ１４で指定されたクラスオブジェクトのデータ構造にＳ１４で指定されたＣＢＦを設定した後に、後述する第４ヒープ選択アルゴリズムに基づいて決定されたヒープＩＤの分割ヒープ領域に、インストールされたＳＰバンドル１３１が確保（消費）するメモリ領域を割り当てる（Ｓ１５）。
【０１５２】
ＣＢＦは、そのクラスがクラスの提供・利用どちらのクラスかを表している。機能提供クラスがＳＰバンドルセットから呼び出され、機能提供クラスのスタックで消費されたメモリは、呼び出したＳＰバンドルセットの消費メモリとカウントする。
【０１５３】
一方、機能利用クラスがＳＰバンドルセットから呼び出され、機能利用クラスのスタックで消費されたメモリは、呼び出したＳＰバンドルセットのメモリ消費量とカウントする。
【０１５４】
すなわち、機能を提供するＳＰバンドルセット（機能提供バンドル群）が確保（消費）するメモリ領域を、機能を利用するＳＰバンドルセット（機能利用バンドル群）に対して生成された分割ヒープ領域に割り当てるようにしている。
【０１５５】
第４ヒープ選択アルゴリズムの動作を示すフローチャートを図１４に示す。第４ヒープ選択アルゴリズムは、ＴＯＰＳＴＡＣＫでメモリ割当が起こるたびに分割ヒープを選択する。なお、ＣＵＲ＿ＣＢＦはｃｕｒＳｔａｃｋのクラスのＣＢＦを表し、ｌａｓｔ＿ＣＢＦは、ｃｕｒＳｔａｃｋの１つ上のスタックのクラスのＣＢＦを表す。
【０１５６】
最初に、ｈｅａｐＩＤにＨＥＡＰＩＤ＿ＰＦに代入する（Ｓ４０１）。
【０１５７】
次に、ｃｕｒＳｔａｃｋにＴＯＰＳＴＡＣＫを代入する（Ｓ４０２）。
【０１５８】
次に、ｌａｓｔ＿ＣＢＦに機能提供を代入する（Ｓ４０３）。
【０１５９】
次に、ｃｕｒｈｅａｐＩＤにＳＴＡＣＫ＿ＨＥＡＰＩＤを代入する（Ｓ４０４）。
【０１６０】
次に、ｃｕｒｈｅａｐＩＤがＨＥＡＰＩＤ＿ＰＦならばＳ４１０に進み、そうでないならばＳ４０６に進む（Ｓ４０５）。
【０１６１】
次に、ｃｕｒｈｅａｐＩＤがｈｅａｐＩＤと同じならばＳ４１０に進み、そうでないならばＳ４０７に進む（Ｓ４０６）。
【０１６２】
次に、ｈｅａｐＩＤがＨＥＡＰＩＤ＿ＰＦならばＳ４０９に進み、そうでないならばＳ４０８に進む（Ｓ４０７）。
【０１６３】
次に、ｌａｓｔＣＢＦが機能利用ならば処理を終了し、そうでないならばＳ４０９に進む（Ｓ４０８）。
【０１６４】
次に、ｈｅａｐＩＤにｃｕｒｈｅａｐＩＤを代入する（Ｓ４０９）。
【０１６５】
次に、ｌａｓｔ＿ＣＢＦにＣＵＲ＿ＣＢＦを代入する（Ｓ４１０）。
【０１６６】
次に、ｃｕｒＳｔａｃｋを１つ下のスタックにする（Ｓ４１１）。
【０１６７】
最後に、ｃｕｒＳｔａｃｋがＮｕｌｌでならば処理を終了し、そうでないならばＳ４０３に戻る（Ｓ４１２）。
【０１６８】
呼び出し元・クラス提供スタックの関係を表すと、図１５に示すようになる。
【０１６９】
ここで、スタックが複数積み重なった例を、図９Ｂ（ｅ），（ｆ）を用いて説明する。まず、スタック［５］が機能利用クラスである図９Ｂ（ｅ）においてどのようにカウントされるかを説明する。
【０１７０】
ＰＦセットのクラスにあたるスタック［６］で消費されるメモリ量は、呼び出し元スタック［５］がＳＰバンドルセット１なので、呼び出し元スタック［５］が消費したメモリ量としてカウントされる（象限ｂ）。
【０１７１】
ＳＰバンドルセット１であるスタック［５］で消費されるメモリ量は、呼び出し元スタックがＳＰバンドルセット２であり、機能利用クラスであるので、クラス提供スタック［５］で消費されるメモリとしてカウントされる（象限ｄ）。なお、スタック［４］〜スタック［０］については第３ヒープ選択アルゴリズムと同様である。
【０１７２】
次に、スタック［５］が機能提供クラスである図９Ｂ（ｆ）においてどのようにカウントされるかを説明する。
【０１７３】
ＰＦセットのクラスにあたるスタック［６］で消費されるメモリ量は、呼び出し元スタック［５］がＳＰバンドルセット１なので、呼び出し元スタック［５］が消費したメモリ量としてカウントされる（象限ｂ）。
【０１７４】
ＳＰバンドルセット１であるスタック［５］で消費されるメモリ量は、呼び出し元スタックがＳＰバンドルセット２であり、機能提供クラスであるので、呼び出したＳＰバンドルセット２で消費されるメモリとしてカウントされる（象限ｄ）。なお、スタック［４］〜スタック［０］については第３ヒープ選択アルゴリズムと同様である。
【０１７５】
以上より、機能を提供するＳＰバンドルセットが確保（消費）するメモリ領域を、機能を利用するＳＰバンドルセットに対する分割ヒープ領域に割り当てるので、第３ヒープ選択アルゴリズムの効果に加えて、ＳＰバンドルセット同士の呼び出しにおいても、機能の提供・利用によってメモリ消費量のカウント先を変更でき、メモリ消費量を更に制限できる。
【０１７６】
また、ＪａｖａＶＭ１０にクラスオブジェクトのデータ構造にＣＢＦを設定できるデータ構造を用意しているので、クラスごとに機能の提供・利用を判別することができる。
【０１７７】
〔メモリ消費量の計測について〕
次に、ＪａｖａＶＭ１０におけるメモリ消費量の計測方法について説明する。メモリ消費量を計測するために、ＪａｖａＶＭ１０に対して、以下の機能を追加する。
【０１７８】
ＪａｖａＶＭ１０は、外部設計として、ヒープＩＤを引数に取り、分割ヒープ領域のメモリ量を計算する第４ＡＰＩを更に有する。また、内部設計として、第４ＡＰＩが呼び出された時に、指定されたヒープＩＤの空きメモリ量を返す機能を有する。
【０１７９】
以下、分割ヒープ領域のメモリ消費量を計測する方法を説明する。
【０１８０】
最初に、ＪａｖａＶＭ１０は、ＧＣを行う（Ｓ２１）。例えば、第４ＡＰＩが呼び出される前に、第４ＡＰＩを呼び出すプログラム側でＳｙｓｔｅｍ．ｇｃ（）などでＧＣを行う方法も考えられる。ここでＧＣは、分割ヒープ領域毎に行うか、ヒープ領域全体に行うかは問わない。
【０１８１】
次に、Ｓ２１の後、メモリ管理バンドル１２ａから送信されたヒープＩＤを取得し、当該ヒープＩＤの分割ヒープ領域における消費メモリや残りの利用可能メモリを計算する（Ｓ２２）。
【０１８２】
最後に、Ｓ２２で計算した消費メモリや利用可能メモリをメモリ管理バンドル１２ａに返す（Ｓ２３）。
【０１８３】
なお、ＧＣとは、プログラムが動的に確保したメモリ領域のうち、不要になった領域を自動的に解放する処理をいう。
【０１８４】
以上より、分割ヒープ領域単位でメモリ消費量を計測できる。
【０１８５】
〔生成済みの分割ヒープ領域の削除について〕
次に、生成済みの分割ヒープ領域の削除方法について説明する。分割ヒープ領域を削除するために、ＪａｖａＶＭ１０に対して、以下の機能を追加する。
【０１８６】
ＪａｖａＶＭ１０は、外部設計として、ヒープＩＤを引数に取り、分割ヒープ領域を削除する第５ＡＰＩを更に有する。また、内部設計として、第５ＡＰＩが呼び出された時に、指定されたヒープＩＤの分割ヒープ領域を削除する機能を有する。
【０１８７】
以上より、削除対象の分割ヒープ領域が解放される。
【０１８８】
〔実施例〕
＜ＰＦセットからＳＰバンドルセットへの呼び出しにおける実施例＞
第３，第４ヒープ選択アルゴリズムにおいて、ＳＰバンドルセット１（以下、ＳＰ１）が、ＳＰバンドルセット２（以下、ＳＰ２）を呼び出す例を考える。
【０１８９】
ＳＰ２の内部でＰＦセットを呼び出すと、図１６に示すようなスタックになる場合がある。このようなスタック構造になるＰＦセットのクラスには、例えばＡｃｃｅｓｓＣｏｎｔｒｏｌｌｅｒ．ｄｏＰｒｉｖｉｌｅｇｅｄ（）などがある。
【０１９０】
このようなクラスには、第４ヒープ選択アルゴリズムで説明したＣＢＦを機能提供に設定し、第４ヒープ選択アルゴリズムを適用する。
【０１９１】
以上より、スタック［３］からスタック［４］への呼び出しは、第４ヒープ選択アルゴリズムにおいてはＳＰ２のメモリ消費量とカウントされることになる。この例において、ＳＰ１がＳＰ２の機能を利用している場合には、スタック［２］〜スタック［４］の呼び出しは、ＳＰ１がＳＰ２の機能を利用するために行われていることになる。
【０１９２】
つまり、スタック［２］〜［４］で消費されたメモリ量は、機能を利用しているＳＰ１のメモリ消費量とカウントされることが望ましく、それを実現することができる。
【０１９３】
＜ＰＦセットを詳細に分割する実施例＞
ブートストラップクラスローダからロードされるクラスを、ＪａｖａＶＭのクラスとみなし、システムクラスローダからロードされるクラスを、ＯＳＧｉＦＷのクラスとみなす。それぞれのクラスローダオブジェクトの構造体に別のヒープＩＤを設定し、第１ヒープ選択アルゴリズムを用いる。
【０１９４】
以上より、同一クラスローダからロードされるクラスごとにメモリ消費量を制限できる。特に、第１ヒープ選択アルゴリズムではＰＦセットは１つとしたが、ＰＦセットをＪａｖａＶＭとＯＳＧｉＦＷとに分割できる。
【０１９５】
＜スレッドとヒープＩＤとを結び付ける実施例＞
ＪａｖａＶＭ１０に、内部設計として、スレッドに対してヒープＩＤを設定することができるデータの構造体を追加する。この場合、図１７に示す第５ヒープ選択アルゴリズムを用いる。
【０１９６】
このアルゴリズムは、スレッドに設定されたヒープＩＤの分割ヒープを選択するようにしている。スレッドが立てられる際、スレッドを立てるクラスのクラスローダオブジェクトのヒープＩＤを、立てるスレッドの構造体に設定する。
【０１９７】
以上より、基本的には、第２ヒープ選択アルゴリズムを用いた場合と同一の効果が得られるが、スタックを下に辿る動作を不要とするので、第２ヒープ選択アルゴリズムを用いた場合よりも高速にメモリ割当を行うヒープＩＤを決定できる。
【０１９８】
＜ヒープメモリ管理方式の実施例＞
分割ヒープ領域のメモリ値の設定方式は複数の方式が考えられる。
【０１９９】
メモリ値自由設定方式では、メモリ値を自由に設定することができる。メモリ値を自由に設定することができるので、効率的にメモリを利用することができる。
【０２００】
また、ブロック化ヒープ方式は、固定サイズの分割ヒープを予め複数用意しておく方式であり、メモリ値自由設定方式と比べて、ヒープメモリの再生成のオーバーヘッドがないという利点がある。
【０２０１】
＜ＧＣの実施例＞
ＧＣは、分割ヒープ領域毎に行う方式とヒープ領域全体で行う方式とが考えられる。
【０２０２】
分割ヒープ領域毎に行う方式は、ヒープ領域全体で行う方式と比較して、ある分割ヒープ領域で頻繁にＧＣが起こる場合でも、他のヒープ領域は影響を受けることなく動作することができる。
【０２０３】
一方、ヒープ領域全体で行う方式は、分割ヒープ領域毎で行う方式と比較して、以下の利点がある。第１分割ヒープ領域の次にすぐに第２分割ヒープ領域のＧＣが発生する等、異なる分割ヒープ領域で頻繁にＧＣが起こるような状況においては、参照されているオブジェクトをルートから探索する動作が頻繁に起こってしまいオーバーヘッドになる。しかし、ヒープ領域全体でＧＣを行う場合には、一度に全てのオブジェクトを探索するためこのような、オーバーヘッドがなくなるという利点がある。
【符号の説明】
【０２０４】
１…メモリ管理装置
１０…ＪａｖａＶＭ（Ｊａｖａ仮想マシン）
１１…ＯＳＧｉＦＷ
１２…オーナーバンドル
１２ａ…メモリ管理バンドル
１３…ＳＰバンドルセット
１３１…ＳＰバンドル
１４…ＰＦセット
Ｓ１〜Ｓ４，Ｓ１１〜Ｓ１５，Ｓ１０１，Ｓ２０１〜Ｓ２０４，Ｓ３０１〜Ｓ３０８，Ｓ４０１〜Ｓ４１２，Ｓ５０１…ステップ
【図１】
0005684633.tif 000002
【図２】
0005684633.tif 000003
【図３】
0005684633.tif 000004
【図４】
0005684633.tif 000005
【図５】
0005684633.tif 000006
【図６】
0005684633.tif 000007
【図７】
0005684633.tif 000008
【図８】
0005684633.tif 000009
【図９Ａ】
0005684633.tif 000010
【図９Ｂ】
0005684633.tif 000011
【図１０】
0005684633.tif 000012
【図１１】
0005684633.tif 000013
【図１２】
0005684633.tif 000014
【図１３】
0005684633.tif 000015
【図１４】
0005684633.tif 000016
【図１５】
0005684633.tif 000017
【図１６】
0005684633.tif 000018
【図１７】
0005684633.tif 000019
【図１８】
0005684633.tif 000020
【図１９】
0005684633.tif 000021
【図２０】
0005684633.tif 000022
【図２１】
0005684633.tif 000023
【図２２】
0005684633.tif 000024
【図２３】
0005684633.tif 000025