(57)【要約】【課題】  複数のソフトウェア・モジュールを組み合わせて動作させる組込みシステムにおいて、メモリ空間をモジュールごとに分割する手法によるメモリ資源の枯渇を低減するとともに、メモリ枯渇の原因となるモジュールの特定を容易にする。【解決手段】  複数のソフトウェア・モジュールを実行する計算機に適用されるメモリ管理方法であって、ソフトウェア・モジュールの実行に用いる計算機のメモリ領域を複数領域に分割し、ソフトウェア・モジュール群をソフトウェア・モジュール間の依存関係の強度を用いて複数グループに分割し、前記分割されたメモリ領域と前記分割されたソフトウェア・モジュールのグループとの対応づけに従ってメモリ確保を実施するようにした。【選択図】  図１
2009134379.tif 000002
【特許請求の範囲】
【請求項１】
複数のソフトウェア・モジュールを実行する計算機に適用されるメモリ管理方法であって、
ソフトウェア・モジュールの実行に用いる計算機のメモリ領域を複数領域に分割し、
ソフトウェア・モジュール群をソフトウェア・モジュール間の依存関係の強度を用いて複数グループに分割し、
前記分割されたメモリ領域と前記分割されたソフトウェア・モジュールのグループとの対応づけに従ってメモリ確保を実施することを特徴とするメモリ管理方法。
【請求項２】
請求項１に記載のメモリ管理方法であって、
前記モジュール間の依存関係の強度は、モジュールのコード内にある他のモジュールの呼び出し箇所の数により求めることを特徴とするメモリ管理方法。
【請求項３】
請求項１に記載のメモリ管理方法であって、
前記モジュール間の依存関係の強度は、ソフトウェア・モジュールの開発ベンダ情報を用いて求めることを特徴とするメモリ管理方法。
【請求項４】
請求項１に記載のメモリ管理方法であって、
前記モジュール間の依存関係の強度は、各ソフトウェア・モジュールに持たせる重要度に応じてもとめることを特徴とするメモリ管理方法。
【請求項５】
請求項１に記載のメモリ管理方法であって、
前記メモリ確保量を、メモリ確保を要求するソフトウェア・モジュールごとに累積加算することを特徴とするメモリ管理方法。
【請求項６】
請求項１に記載のメモリ管理方法であって、
ソフトウェア・モジュールを構成するプログラムコードを、モジュール内でのみ利用されるコードと、他のモジュールに提供されるコードに分類し、メモリ確保を要求するコードの分類に応じて、メモリ確保量を累積加算することを特徴とするメモリ管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は計算機システムにおけるメモリ資源の管理方法に関し、特に組込み機器と呼ばれるようなメモリ資源の少ない計算機システム向けのメモリ資源管理方法に関する。
【背景技術】
【０００２】
近年、情報家電や携帯電話などの、いわゆる組込み機器と呼ばれる情報処理機器の機能が加速度的に増大している。ユーザ要求の高度化、メーカー間の競争、ネットワークへの対応などの要因が、機能増大が進む原因となっている。これらの機能増大に対応するために、組込み機器に搭載されるソフトウェアも複雑化しており、合わせてソフトウェアの動作に用いられるメモリ資源の管理も複雑化している。
【０００３】
例えば、各機能要素を実現するソフトウェア・モジュール（以下モジュールと呼称する）を複数組み合わせて全体機能を実現する組込み機器では、モジュールが相互にメモリ資源を奪い合い、メモリ資源が枯渇し、動作停止などの障害に結び付くケースが生じうる。このようなメモリ資源障害は、開発作業を慎重に進めることで回避されるが、開発に必要な時間と経費の増加につながり、大きな問題となっている。
【０００４】
また、組込み機器のネットワーク接続の進展により、組込み機器がモジュールを受信し、受信したモジュールを実行するシステム事例が増加している。例えばネットワークなどを介してソフトウェア部品をやりとりすることで様々な機器の機能を容易に変更することを目指したプラットフォーム技術であるOSGiは、各家庭に設置されたホームゲートウェイにモジュールを配信するための規格を定めている。一般に、このようなシステムにより配信されるモジュールは多様であり、モジュールのメモリ使用量も様々である。このため、メモリ資源を大量に使うモジュールが配信されて実行されると、組込み機器の持つメモリ資源が枯渇する可能性がある。
【０００５】
上記のような問題に対処する方法として、モジュール単位の使用メモリ量を監視および制御する方法が多数知られている。代表的な方法として、メモリ枯渇時にモジュールを停止してメモリ資源を取り戻す方法や、モジュール単位のメモリ上限を設けて一定量以上のメモリ使用を許さない方法などがある。
【０００６】
例えば特許文献１では、OSGiの定めるモジュールである「OSGiバンドル」を対象に、モジュールの停止によるメモリ資源を回収する方法を開示している。
【０００７】
また、非特許文献１では、メモリ領域を分割し、分割領域とモジュールを対応づけることで、各モジュールが使用するメモリ量を制限する方法を示している。詳しくは、共有されるメモリ専用の分割領域を一つ設け、共有するメモリの量を制限する方法を示している。この方法では、共有するメモリはどのモジュールからも使用されていないと定義され、各モジュールとは独立して監視と制御を行う。
【０００８】
【特許文献１】特開2005-505832号公報
【非特許文献１】Godmar Back, Wilson C. Hsiegh, Jay Lepreau. Processes in KaffeOS: Isolation, Resource Management, and Sharing in Ｊａｖａ（登録商標）. USENIX Symposium OSDI 2000, Oct. 23-25, 2000.
【発明の開示】
【発明が解決しようとする課題】
【０００９】
しかしながら、モジュールによっては、複数のモジュールが相互にメモリ領域を共有することがあり、メモリ量の監視と制御を難しくしている。前述のOSGiは、Ｊａｖａ（登録商標）実行環境を用いて実現されるプログラム実行環境であるが、OSGiバンドルが、相互にＪａｖａ（登録商標）オブジェクトを共有する仕掛けを用意している。この場合、共有されるＪａｖａ（登録商標）オブジェクト（メモリ）を、どのOSGiバンドル（モジュール）によって使用されていると定義するか、という問題が生じる。
【００１０】
一つの定義方法は、相互に共有しているメモリもそれぞれのモジュールが使用していると定義して計測する方法である。また、別の定義方法は、いずれか一つのモジュールがそのメモリを使用しており、他のモジュールはそのメモリを使用していないとして計測する方法である。
【００１１】
非特許文献１の示す従来技術は、モジュール数の増加に伴って、メモリ空間を細かく分割しなければならない。メモリ空間の細分化は、各分割領域に空き領域を発生させ、メモリの使用効率を下げる。
【００１２】
また、複数モジュールが共有するメモリのために、さらにメモリ空間を分割する必要がある。細分化された分割領域に跨ってメモリ片が参照関係を持つため、不要メモリの自動解放など、メモリ解放の仕組みが複雑になるという課題がある。
【００１３】
複雑化をさけるためにメモリ空間の分割数を少なくすると、複数のモジュールが一つの分割メモリ領域を利用することになり、モジュールを単位とするメモリ使用量の監視・制御ができない。これによりモジュールが増えていくと、特定の分割メモリ領域においてメモリ枯渇が発生した場合に、メモリ枯渇の原因と考えられるモジュールがより多くなり、本当の原因となっているモジュールの特定が難しくなるという問題が生じる。
【００１４】
また、モジュールが複数のベンダから提供される場合には、原因調査を担当するベンダを決定できないという問題が生じる。
【００１５】
本発明の目的は、上記課題を解決し、複数のソフトウェア・モジュールを組み合わせて動作させる組込みシステムにおいて、各モジュールのメモリ使用量の使用効率の向上や、メモリ枯渇の原因となるモジュールの特定が容易なメモリ管理機構を提供することにある。
【課題を解決するための手段】
【００１６】
上記課題を解決するために、本発明の計算機システムは、計算機システム内部に、メモリ分割手段、モジュール群分割手段、メモリ分割とモジュール群分割との対応づけに従ってメモリの確保を実施するメモリ確保手段、累積メモリ確保量計測手段を設ける。モジュール群分割手段を、モジュール間依存関係情報を収集する手段、分割候補を生成する手段、およびモジュールの持つ使用メモリ量、依存モジュール、提供元ベンダ、ユーザ契約内容などの属性を用いて分割候補を評価する分割評価手段から構成する。
【００１７】
そして、ソフトウェア・モジュールの実行に用いる計算機のメモリ領域を複数領域に分割し、ソフトウェア・モジュール群をソフトウェア・モジュール間の依存関係の強度を用いて複数グループに分割し、前記分割されたメモリ領域と前記分割されたソフトウェア・モジュールのグループとの対応づけに従ってメモリ確保を実施して、複数のソフトウェア・モジュールのメモリ管理をおこなうようにした。
【００１８】
上記手段により、分割されたメモリ領域のいずれかが枯渇したときに、枯渇の原因となったモジュールは、依存関係を持つ複数モジュールのうちのいずれかであることが分かる。また、各モジュールの累積メモリ確保量を用いて、枯渇直前にメモリを確保しているモジュールを検知できる。これにより、メモリ枯渇の原因となるモジュールの特定を支援し、原因調査を担当するベンダの決定を促すことができる。
【発明の効果】
【００１９】
以上に述べたように、本発明の示すメモリ管理方法によって、分割されたメモリ領域のいずれかが枯渇したときに、枯渇の原因となったモジュールは、依存関係を持つ複数モジュールのうちのいずれかであることが分かる。
【００２０】
また、各モジュールの累積メモリ確保量を用いて、枯渇直前にメモリを確保しているモジュールを検知できる。これにより、メモリ枯渇の原因となるモジュールの特定を支援し、原因調査を担当するベンダの決定を促すことができる。
【００２１】
これにより、複数のソフトウェア・モジュールを実行する計算機システムのメモリ資源障害の発生を低減でき、開発期間の短縮や信頼性の向上をはかることができる。
【発明を実施するための最良の形態】
【００２２】
以下、本発明を実現する実施例を、図１から図１２を用いて説明する。以下に示す実施形態はあくまで例であり、上述の手段を持つ適用形態であれば、本例との相違があっても発明の効果を享受できる。
【実施例１】
【００２３】
図１に本発明を実現するシステムの全体構成を示す。以下、その構成を説明する。
本システムは、モジュール配布装置101、ソフトウェア実行装置102、資源量監視装置104などから構成される。これらの装置は、インターネットなどのネットワークを通じて結線され、相互に情報をやり取りする。
【００２４】
ソフトウェア実行装置102は、ネットワークを介してモジュール配布装置101からモジュールを受信し、そのモジュールを実行する。ソフトウェア実行装置102は、実行時の使用メモリ量などの計算機資源の利用量を、適宜資源量監視装置104に送信する。資源量監視装置104は、モジュールやソフトウェア実行装置の管理者や開発者に、資源量を表示する。
【００２５】
モジュール配布装置101は、モジュール送信部111を持つとともに、複数のモジュール112を保持している。モジュール送信部111はソフトウェア実行装置102からの要求などに応じて、モジュール112をソフトウェア実行装置102に送信する。
【００２６】
ソフトウェア実行装置102は、モジュール受信部122を持つ。モジュール受信部122はモジュール112を受信すると、モジュール記憶部129に保存する。受信するモジュール112は複数ある。モジュール記憶部129は、予めソフトウェア実行装置102の出荷時にモジュールを記憶しておいてもよい。たとえば、実行ログを収集するモジュールや、基本的な通信プロトコルを実装するモジュールなどは、出荷時に組み込まれる。
【００２７】
ここで、モジュール配布装置101は、複数あってもよい。たとえば、ソフトウェア実行装置102にモジュールを提供するサービスベンダが複数ある場合などには、ベンダ毎にモジュール配布装置101を用意する。モジュールの配布方法は、本実施例に示すネットワーク経由の例にとどまらない。ソフトウェア実行装置102がDVDなどの記憶媒体を読み取る機能を持ち、モジュールを記録した記憶媒体の挿入と読み取りにより、モジュールを受信してもよい。
【００２８】
ソフトウェア実行装置102は、実行条件120、ソフトウェア・モジュール実行環境121、モジュール記憶部129を持つ。実行条件120は、二次記憶上に保持され、ソフトウェア・モジュール環境121の実行に必要なパラメータを保持する。ソフトウェア・モジュール環境121は、メモリなどの一次記憶上にプログラムコードとして保持され、演算装置により実行される。モジュール記憶部129は、二次記憶を用いてモジュール112を保持する。二次記憶に保持された情報は、ソフトウェア実行装置102の電源遮断された時にも継続して保持される。
【００２９】
ソフトウェア・モジュール実行環境121は、モジュール受信部122、モジュール管理部123、モジュール間依存解決部124、モジュール群分割部125、メモリ管理部126、メモリ確保量計測部127を持つ。
【００３０】
モジュール管理部123は、モジュール記憶部129に記憶されたモジュール112の、実行状態を管理する。モジュール112を必要に応じてロードし、ソフトウェア・モジュール実行環境121内に、実行状態モジュール128として保持する。実行状態モジュール128の実施する処理の組み合わせにより、ソフトウェア実行装置102は目的の機能を実現する。
【００３１】
モジュール管理部123は、モジュール112のロードに先立ち、モジュール間依存解決部124に、モジュール間の依存関係を調査するように依頼する。ここでは各モジュール112が、他のモジュールに提供する機能、および、他のモジュールに呼び出す機能に関する情報を持っている例を示す。モジュール間依存解決部124は、モジュール112の各々を調べ、これらの情報からモジュール間の依存関係を調査し、依存関係を、モジュール間依存グラフ130として出力する。
【００３２】
モジュール群分割部125は、モジュール間依存グラフ130を入力とし、モジュール群を複数のグループに分割する。分割判定には、モジュールの持つ、「メモリ使用量」「ベンダ」などの属性と、モジュール間の依存関係を用いる。分割は、「同一ベンダの提供するモジュールを同じグループとする」「別のグループに分けられるモジュール間の依存関係を最小化する」「各グループのモジュールが使用するメモリの想定量を一定値以下とする」「基本的な機能を提供するモジュールを一つの同じグループとする」などの方針に基づいて決定される。分割の結果は、モジュール・分割メモリ対応131に保持する。
【００３３】
メモリ管理部126はメモリ資源132を管理する。メモリ管理部126は、実行状態モジュール128による要求を受けて、メモリ確保およびメモリ解放を実施する。メモリ資源132の持つメモリ領域は、実行条件120の内容に従って複数に分割される。各モジュールが使用する分割メモリ領域は、モジュール・分割メモリ対応131によって対応付けられる。
【００３４】
メモリ管理部126は、メモリ確保の要求に応じてモジュール・分割メモリ対応131を参照し、メモリ資源132の分割メモリ領域を特定し、当該分割メモリ領域に対してメモリの確保を試みる。メモリの確保に成功した場合は、メモリ確保量計測部127にメモリ確保に関する情報を伝達し、要求元の実行状態モジュール128にメモリ資源を提供する。メモリ確保量計測部127は、メモリ確保の結果を、メモリ使用量記録133に記録する。
【００３５】
資源量送信部134は、一定時間経過や、資源量監視装置104からの要求などに応じ、メモリ使用量記録133を読みだし、資源量監視装置104の持つ資源量受信部143へ送信する。資源量受信部143の受信した情報は、資源量情報142に記録、蓄積され、資源量表示部141により、開発者や管理者に供される。
【００３６】
以下、図２〜図８を用いて、本実施例にて用いるデータ構造を示す。
図２に、実行条件120のデータ構造を示す。実行条件120は、メモリ資源132の分割に用いられる「メモリ分割条件」、モジュール間の依存関係の強さを算出する「モジュール依存強度計算式」、モジュール群をグループに分割する際に用いる「モジュール群分割評価値計算式」、ソフトウェア実行装置102を提供するベンダを示す「システムベンダ名」などを持つ。メモリ分割条件は、分割されたメモリ領域のサイズなどの情報から構成される。
【００３７】
図３に、モジュール112の構成例を示す。本実施例では、モジュール112は、モジュール名とバージョン番号を持ち、これらの情報によりソフトウェア実行装置102内にて、一意に特定可能とする例を示す。モジュール112は、合わせてコード、メモリサイズ、ベンダ名、提供名前空間、導入名前空間、などの情報を持つ。
【００３８】
コード集合は、モジュールの持つ機能を実現するプログラムコードである。コード集合は計算機が実行するコード（命令列）の集合であり、各コードには名前が付与されている。この名前はいずれかの名前空間に所属している。
【００３９】
名前空間は、プログラムの構成要素につける名前の衝突を避けながら、名前の記述を容易にするための概念であり、プログラムの構成要素全体を、部分空間に分割する役割を持つ。ここでは、コード集合の分割に名前空間を用いる例を示す。
【００４０】
メモリサイズは、当該モジュールが動作するために必要とするメモリサイズの指標である。最小限必要なサイズ、動作時の平均サイズ、上限サイズなどの複数の値を持たせても良い。これらの値は、別途計測した値を、配布時に記入しておく。
【００４１】
ベンダ名は当該モジュールを開発した開発ベンダを特定するための情報である。各モジュールが持つベンダ名を比較することで、同じベンダから提供されたモジュールか、異なるベンダから提供されたモジュールかを判定する。ベンダ名をシステムベンダ名と比較することで、当該モジュールの重要度を判定する。システムベンダ名と一致する場合は、ソフトウェア実行装置102の基本機能を担うモジュールであり、重要度の高いモジュールとして取り扱う。
【００４２】
提供名前空間は、当該モジュールが他のモジュールに提供する機能範囲を特定するための情報である。一方、導入名前空間は、当該モジュールが、別のモジュールから導入する機能を特定するための情報である。
【００４３】
各モジュールが動作時に用いるコード集合は、他のモジュールに提供されるコードと、他のモジュールから導入するコード、および、提供もせず導入もされないコードに分けられる。他のモジュールに提供されるコード集合と他のモジュールから導入するコード集合の特定に、名前空間を用いる。
【００４４】
図４は、モジュール間依存グラフ130が保持する、モジュール間の依存関係を示す模式図である。四角形はモジュールを示し、矢印はモジュール間の依存関係を示す。たとえば、モジュール112b、112c、112dの三つのモジュールは、モジュール112aに依存している。点線で示した境界線は、モジュール群のグループ分けを示す。
【００４５】
図５は、モジュール間依存グラフ130のデータ構造を示す。テーブルの各行が、一つの依存関係を示す。「依存元モジュール」、および「依存先モジュール」により、依存関係にあるモジュールを特定している。ここでは、図４に示した関係と同様に、モジュール112b、112c、112dが、モジュール112aに依存する例を示している。
【００４６】
「ベンダ関係」は、依存元モジュールと、依存先モジュールが、同一ベンダにより提供されたものか、それとも異なるベンダにより提供されたものかどうかを示す。「呼出箇所数」は、依存元モジュールのコード内にある、依存先モジュールのコードを呼び出す箇所の数を示す。図５には、モジュール112bの持つコード内に、モジュール112aのコードを呼び出す箇所が３か所あることを示している。結合強度は、モジュール間の依存関係の強度を、所定の定義に従って算出した値である。ここでは、以下の算出式を用いた例を示す。
【００４７】
結合強度＝呼出箇所数＋（ベンダが同一であれば１０）
＋（双方がシステムベンダの提供するモジュールであれば１０）
上記の算出式は、実行条件120によって保持される。結合強度は、モジュール群をグループに分割する処理に使われる。この算出式の例は、「呼出箇所数の多いモジュールを同じグループとする」「同一ベンダのモジュールを同じグループとする」「システムベンダの提供するモジュールを同じグループとする」という分割方針を示している。
【００４８】
図６に、モジュール・分割メモリ対応131のデータ構造を示す。このデータ構造は、モジュール群を、いくつかのグループに分ける。たとえば、グループ112aと112bは、同じグループに所属している。
【００４９】
図７に、メモリ資源132の構造を図示する。本実施例では、メモリ資源132は二つの領域701、および702に分割される。各モジュールによるメモリ確保は、分割領域701もしくは702のどちらか一方に対して実施される。本例では二つに分割する例を示すが、３つ以上の領域に分割してもよい。
【００５０】
図８に、メモリ使用量記録133のデータ構造を示す。本データ構造は、各モジュールによるメモリ使用量を記録する。ただし、各モジュールの持つプログラムコードを、名前空間を用いて「モジュール内利用」コード、および「他モジュール提供」コードに分割し、各々のコードによって要求されるメモリ使用量を記録する。
【００５１】
モジュール112bが、モジュール112aの機能を利用する場合、モジュール112bは、モジュール112aが他モジュールに提供するコードを呼び出す。呼び出されたコードにより確保されたメモリは、「モジュール=112a」、および「名前空間種別=他モジュール提供」により確定する行の「累積確保メモリ量」に加算される。
【００５２】
本実施例では、メモリ解放時に累積確保メモリ量を減算しない。減算機能を追加しないことにより、複雑化と処理負担を避ける。各モジュールの正確なメモリ利用量は計測できないが、累積確保メモリ量の時間変化を監視することにより、各モジュールによるメモリ使用の傾向を観測できる。例えば、メモリ枯渇の直前にメモリを確保しているバンドルを特定し、優先して調査するモジュールを選別できる。
【００５３】
図９〜図１２を用いて、本実施例における処理手順を示す。
図９はソフトウェア実行装置102の起動処理を示す。各処理を以下にしめす。
処理９０１：電源投入などを契機として、ソフトウェア実行装置102が起動する。
処理９０２：モジュール間依存解決部124は、モジュール記憶部129に記憶されたモジュール群112を解析し、モジュール間依存グラフ130を生成する。
処理９０３：モジュール群分割部125は、モジュール間依存グラフ130を参照し、最適なモジュール群のグループ分け（分割）を決定する。結果は、モジュール・分割メモリ対応131に記録される。
処理９０４：モジュール管理部123は、モジュール群112を一次記憶上にロードし、実行状態モジュール128を準備する。
処理９０５：モジュール管理部123は、モジュール群112に処理開始を指示する。
【００５４】
ここに示した処理手順例では、起動処理の一環として処理９０２、処理９０３が実行される手順を示したが、処理９０２、処理９０３は、モジュール受信部122がモジュールを受信した時や、一定時間が経過した時など、別の契機に実行されてもよい。
【００５５】
図１０を用いて、モジュール間依存解決処理902の詳細処理手順を示す。以下に各処理の内容を説明する。
処理１００１：モジュール記憶部129の保持するモジュール112の中から、処理対象とするモジュールを一つ選択する。このモジュールをＸと呼ぶ。
処理１００２：モジュールＸの持つデータ構造（図２）を調べ、「導入名前空間」を読み込む。導入名前空間は、複数あってもよい。
処理１００３：モジュール記憶部129の保持するモジュール112を全て調べ、「提供名前空間」が処理９０２にて読み込んだ名前空間と一致するモジュールを検索する。見つかったモジュールを、モジュールＹと呼ぶ。モジュールＹは、複数個存在しうる。
処理１００４：モジュールＹが一つも無い場合は処理１００６に進み、一つ以上ある場合は、処理１００５に進む。
処理１００５：モジュールＸとモジュールＹの情報から、モジュール依存グラフ130（図４）に行を追加する。依存元モジュールにモジュールＸ、依存先モジュールにモジュールＹを設定する。モジュールＹが2つ以上ある場合は、モジュールＹの個数に応じて、追加行も２つ以上となる。ベンダ関係は、モジュールＸとモジュールＹのベンダ名比較により決定される。呼出箇所数は、モジュールＸのコード内のモジュールＹコード呼出箇所数をカウントし、設定される。結合強度は、定義式に応じて算出される。
処理１００６：モジュール記憶部129の保持するモジュール112全てに対して処理１００２〜処理１００５を完了した場合は、モジュール間依存解決処理802を終了する。そうでない場合は、処理１００１に進む。
【００５６】
図１１を用いて、最適モジュール分割処理903の詳細処理手順を示す。最適モジュール分割処理は、いわゆるグラフ分割問題の一種であり、多数の解法が知られている。以下、単純な解法である局所探索法を適用した例を示すが、本発明は、別の解法を用いても良い。
【００５７】
以下に図１１の各処理の詳細を説明する。
処理１１０１：モジュール群分割候補を生成する。このとき、分割するグループの数は、メモリ資源132の分割数と同じ数とする。初回はランダムに分割する。二回目以降の生成においては、前回評価した候補の一部をランダムに変更し、新しい候補とする。
処理１１０２：生成したモジュール群分割候補を評価する。評価は、予め定義された算式による評価値を用いる。例えば以下のような算出式を用いる。
【００５８】
評価値＝（各グループのモジュール数最大値）−（各グループのモジュール数最小値）
＋（グループを跨る依存関係の結合強度合計）
この算出式は、各分割にほぼ同数のモジュールが含まれること、および、依存関係の強いモジュール同士を、同じ分割に含めることを、分割の方針とした場合の算出式であり、評価値が小さいほど、良い分割となる。各モジュールのメモリ使用量や、モジュールの重要度などを用いる算出式でもよい。
【００５９】
処理１１０３：以前に実行した処理１１０２により算出された評価値の最小値と、直近の処理１１０２の実行により算出された評価値を比較する。直近の評価値のほうが小さければ、処理１１０４に進む。そうでなければ、処理１１０５に進む。
処理１１０４：処理１１０１で生成した分割候補１１０１を、モジュール・分割メモリ対応131に保存する。
処理１１０５：最適分割の探索を継続する場合は、処理１１０１に進む。所定の繰り返し回数を超えるなどして、探索を打ち切る場合は最適モジュール分割処理903を終了する。
【００６０】
図１２を用いて、メモリ確保処理の処理手順を示す。実行状態モジュール128が、必要に応じてメモリ管理部126に要求することで、メモリ確保処理が開始される。以下に各処理の詳細をしめす。
処理１２０１：メモリ確保を要求した実行状態モジュール128に対応するモジュール112を調べ、要求したコードの属するモジュールと、名前空間を特定する。
処理１２０２：特定されたモジュールと、モジュール・分割メモリ対応131から、対応する分割メモリ領域を特定する。
処理１２０３：メモリ資源132の持つ分割メモリ領域のうち、処理１２０２にて特定された分割メモリ領域に対し、メモリ確保を試みる。
処理１２０４：メモリ確保に失敗した場合は処理１２０６に進み、成功した場合は処理１２０５に進む。
処理１２０５：特定しておいたモジュールと名前空間を用いて、メモリ使用量記録133の行を特定し、その行の累積確保メモリ量に、処理１２０３にて確保したメモリサイズを加算する。
処理１２０６：メモリ確保に失敗したことを、実行状態モジュール128に通知する。
【００６１】
本実施例では、メモリ資源に限定した例を示しているが、二次記憶領域など、定量的に分割可能な資源であれば、本発明に示す管理方法を適用可能である。
【００６２】
本実施例では、モジュール間依存解決処理や、モジュール分割処理を、ソフトウェア・モジュール実行装置102が実行する例を示しているが、別の計算機によりこれらの処理を実行し、実行結果をソフトウェア・モジュール実行装置102が用いる構成を取ることも可能である。
【図面の簡単な説明】
【００６３】
【図１】実施例におけるシステム構成例を示す図である。
【図２】実行条件120のデータ構成例を示す図である。
【図３】モジュール112のデータ構成例を示す図である。
【図４】モジュール間の依存関係を示す模式図である。
【図５】モジュール間依存グラフ130のデータ構成例を示す図である。
【図６】モジュール・分割メモリ対応131のデータ構成例を示す図である。
【図７】メモリ資源132の構成例を示す図である。
【図８】メモリ使用量記録133のデータ構成例を示す図である。
【図９】ソフトウェア実行装置102の起動処理手順例を示す図である。
【図１０】モジュール間依存解決処理902の処理手順例を示す図である。
【図１１】モジュール分割処理903の処理手順例を示す図である。
【図１２】メモリ確保処理の手順例を示す図である。
【符号の説明】
【００６４】
101・・・モジュール配布装置、102・・・ソフトウェア実行装置、104・・・資源量監視装置、120・・・実行条件、121・・・ソフトウェア・モジュール実行環境、122・・・モジュール受信部、123・・・モジュール管理部、124・・・モジュール間依存解決部、125・・・モジュール群分割部、126・・・メモリ管理部、127・・・メモリ確保量計測部、128・・・実行状態モジュール、130・・・モジュール間依存グラフ、131・・・モジュール・分割メモリ対応、132・・・メモリ資源、133・・・メモリ使用量記録、134・・・資源量送信部、141・・・資源量表示部、142・・・資源量情報、143・・・資源量受信部
【図１】
2009134379.tif 000003
【図２】
2009134379.tif 000004
【図３】
2009134379.tif 000005
【図４】
2009134379.tif 000006
【図５】
2009134379.tif 000007
【図６】
2009134379.tif 000008
【図７】
2009134379.tif 000009
【図８】
2009134379.tif 000010
【図９】
2009134379.tif 000011
【図１０】
2009134379.tif 000012
【図１１】
2009134379.tif 000013
【図１２】
2009134379.tif 000014