JP4407956B2 - 情報処理方法および情報処理装置 - Google Patents

Description

本発明は、情報処理技術に関し、特に一の情報処理システムを複数の区画に分割して処理を行う情報処理方法、およびそれを適用する情報処理装置に関する。

近年、１つの情報処理装置において複数のプロセスを実行するマルチタスクシステムの技術が一般化している。これにより、テレビ受像、コンピュータゲーム実行、動画再生、電子メール送受信などを含む複数の機能を、一の装置で並行して提供することのできる情報処理装置が広く一般に浸透しつつある。マルチタスクシステムは各プロセスを時分割し、プロセッサのタイムスライスに割り当てて順次実行していくことにより、複数のプロセスを並列に処理する。さらに複数のプロセスを、例えば対応するアプリケーションソフトウェアごとに区分けし、区分ごとにオペレーティングシステム（Operation System、以降、ＯＳと呼ぶ）を起動してプロセスの制御を行う技術も提供されている。これにより、一の装置が対応できるソフトウェアの多様化が実現されている。

複数のプロセスを並列に処理するためには、ＣＰＵ時間のみならずメモリや外部記憶装置、入出力機器など、情報処理装置が有するリソースの割り当てを、各プロセスに対して行う。情報処理装置全体を制御するＯＳは、プロセスの処理状況や、他のプロセスとの相対的な優先度などに基づき、リソースの割り当てを行う。

各プロセスの所要リソースは、プロセスの実行中に変動することがあり得る。例えばあるプロセスの演算量が増加し、割り当てられたＣＰＵ時間では処理に遅延が生じる事態が発生し得る。この場合、当該プロセスは、ＣＰＵ時間の追加割り当てを情報処理装置全体を制御するＯＳに要求する。要求されたＯＳは、他のプロセスとの調整を行い、ＣＰＵ時間の割り当てをし直すなどの処理を行う。

しかしながらリソースの追加割り当てに係る、プロセス／ＯＳ間の通信や、複数のプロセスから発行された割り当て要求をＯＳが処理するための処理待ち行列などに起因して、オーバーヘッドが生じる。このオーバーヘッドは、情報処理装置で処理されるプロセスの数が増加するほど顕著になっていくことを、本発明者は認識した。

本発明はこのような課題に鑑みてなされたものであり、その目的はプロセスに対するリソースの追加割り当てに係るオーバーヘッドを抑制することのできる技術を提供することにある。

本発明のある態様は情報処理方法に関する。この情報処理方法は、複数の実行空間を生成するステップと、複数の実行空間に対して装置のリソース割り当てを行うステップと、実行空間のそれぞれにおいて一以上のプロセスを起動するステップと、実行空間に対して割り当てられたリソースの中から、当該実行空間において起動したプロセスに対してリソース割り当てを行うステップと、を含むことを特徴とする。

「プロセス」とは、ある目的を達成するためにプログラムされたソフトウェアまたはそれに含まれる情報処理の内容をいい、ソフトウェアと対応してもよいし、入出力制御やユーザが指定したコマンドなどソフトウェアよりも小さい単位と対応してもよく、何らかの処理または機能の単位に対応すればよい。「実行空間」とは、一以上のプロセスが実行される環境をいい、プロセスそのものであってもよいし、プロセスを実行するために必要なＯＳが含まれていてもよい。また、例えばソフトウェア単位や機能単位、制御に必要なＯＳ単位など、所定の論理的な要因によって区分けしたプロセスのまとまりでよい。「リソース」はメモリ量やＣＰＵ時間など量的あるいは時間的に分割できるハードウェアの量的、時間的概念、または装置に接続されるデバイスなどハードウェアそのもの、のいずれか、または双方を含んでいてもよい。したがって「リソースの割り当て」は、量的、時間的に分割された部分を割り当てる場合と、ハードウェアにアクセスするためのアクセス情報を与える場合と、のいずれかまたは双方を含んでよい。

本発明の別の態様は情報処理装置に関する。この情報処理装置は、複数の実行空間を生成する情報処理装置であって、情報処理装置全体のリソースを管理し、複数の実行空間に対してリソースの割り当てを行う第一リソース管理部と、複数の実行空間にそれぞれ設けられ、所属する実行空間に対して第一リソース管理部が割り当てたリソースを管理し、所属する実行空間において処理される一以上のプロセスに対しリソースの割り当てを行う第二リソース管理部と、を備えることを特徴とする。

なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システム、コンピュータプログラムなどの間で変換したものもまた、本発明の態様として有効である。

本発明によれば、プロセスへのリソース割り当てを効率的に行うことができる。

最初に本実施の形態の概要を述べる。本実施の形態は、複数の実行空間のそれぞれにおいて一以上のプロセスが処理される形態の情報処理装置において実現される。実行空間は例えばゲーム、ウェブブラウザ、音楽編集、などといったソフトウェアごとに生成され、プロセスは、例えばゲームの実行空間であれば画像処理、音声処理などといった、ソフトウェアを実行するための所定の処理単位で生成される。複数のプロセスを並列処理するために、情報処理装置が備えるメモリ量、ＣＰＵ時間などのリソースが各プロセスに割り当てられる。本実施の形態におけるリソース割り当ては、まず実行空間に対して行われる。そして、実行空間に割り当てられたリソースの中から、その実行空間に属するプロセスに対してリソース割り当てが行われる。

さらに本実施の形態では、あるプロセスがリソース割り当てを要求した際、まず当該プロセスが属する実行空間内でリソース割り当て可否に関する１次判定を行う。次に、必要に応じて実行空間の外でリソース割り当て可否に関する２次判定を行う。２次判定は実行空間単位で行われる。具体的には、実行空間に対して一意に定められた認証用のＩＤに基づき、各実行空間ごとにあらかじめ設定されたリソースの割り当て制限情報を参照することによって、実行空間に対するリソース割り当て可否が判定される。認証用のＩＤやリソースの割り当て制限情報は、ソフトウェアの一部としてプログラムとともに記憶されているものを、当該ソフトウェアに対応する実行空間を生成する際に読み込んでおく。

２次判定の結果、リソースの割り当てが可能とされたら、実行空間に対してリソースの割り当てを行う。実行空間に１度に割り当てるリソースの量は、あらかじめ実行空間ごとに設定されたリソース量の単位で行う。一度実行空間に割り当てられたリソースは、余剰分が生じても実行空間内で確保しておく。これにより、その後に同実行空間に属するプロセスがリソース割り当てを要求した際、実行空間内で確保しておいたリソースによって当該要求が充足すれば、リソース割り当て処理を実行空間内の通信のみで解決することができる。

リソース割り当ての可否判定を階層的に行うことにより、ある実行空間において不正なプロセスがリソースの割り当て要求を行っても、まず当該実行空間内での割り当て処理が行われるため、他の実行空間に対するリソース割り当てに与える影響を防止できる。例え不正なプロセスが、実行空間を制御するプロセスになり代わり、リソース割り当てを不正に要求しても、実行空間ごとに設定された割り当て制限により、過剰な割り当てを防止できる。これにより不正なプロセスによって装置のリソースが占拠され、他の実行空間のプロセスの進捗に影響を与える事態を防止できる。なお、不正なプロセスが他のプロセスになり代わり要求などを行うことを、以後、「成りすまし」とも呼ぶ。

また上述の如く、実行空間内で確保したリソースによって、プロセスのリソース割り当て要求を解決できる場合があるため、実行空間外部との通信や、割り当て要求に対する処理の待ち行列などに起因するオーバーヘッドを抑制することができる。

以降、本実施の形態を具体的に説明する。図１は本実施の形態に係る情報処理装置１００の全体構成を示す。情報処理装置１００はアプリケーションやＯＳのプログラムを処理するプロセッサ１０、ユーザからの指示入力や演算結果の出力を行う入出力装置６０、マシンコードやデータを一時記憶するメモリ７０、およびソフトウェアのプログラムやデータを記憶する外部記憶装置８０を備え、バス９０を介して相互にデータの授受を行っている。入出力装置６０にはデバイス６２ａ、６２ｂとして、キーボード、マウス、ゲームコントローラ、マイクなどの入力装置、プリンタ、表示装置などの出力装置のいずれか、または組み合わせが含まれる。なおデバイス６２の数は２つに限定されない。外部記憶装置８０にはハードディスク８２や、図示しないフラッシュメモリなど、情報処理装置１００のオン／オフに関わらずデータを保持する記憶装置のいずれかが含まれる。

プロセッサ１０には第１実行空間２０ａから第ｎ実行空間２０ｃまでのｎ個の実行空間２０、および情報処理装置１００全体を統括的に制御するシステム制御部５０が含まれる。第１実行空間２０ａには、第１実行空間２０ａに属するプロセスを１つ以上処理する第１プロセス処理部３０ａ、第１実行空間２０ａ内のリソース割り当てやプロセス実行のための各種制御、および第１実行空間２０ａ外の機能ブロックとの通信などを制御する第１実行空間制御部４０ａが含まれる。以降、第２実行空間２０ｂから第ｎ実行空間２０ｃまでのそれぞれの実行空間にも同様に、第２プロセス処理部３０ｂ〜第ｎプロセス処理部３０ｃ、第２実行空間制御部４０ｂ〜第ｎ実行空間制御部４０ｃが含まれる。以後、第１から第ｎの複数の実行空間、プロセス処理部、および実行空間制御部のうち、いずれかの実行空間、プロセス処理部、および実行空間制御部の符号として、単に２０、３０、および４０を用いる場合もある。

図１では実行空間２０を機能としての側面からプロセッサ１０の中に含めたが、各実行空間２０およびシステム制御部５０はハードウェア的には入出力装置６０、メモリ７０あるいは外部記憶装置８０をそれぞれ含めた概念としてよく、さらに図示しないその他のＬＳＩをも構成要素としてよい。また、各実行空間２０およびシステム制御部５０の機能は、ソフトウェア的にはメモリ７０にロードされたアプリケーションやＯＳのプログラムなどによって実現される。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組合せによっていろいろな形で実現できることは当業者には理解されるところであり、いずれかに限定されるものではない。また図１ではプロセッサ１０をわかり易さのために１つの矩形で示しているが、プロセッサ１０の個数を１つに限定するものではなく、例えば複数のサブプロセッサ１０を有するマルチプロセッサ構成としたり、メインプロセッサとグラフィックプロセッサを有する構成としてもよい。さらにバス９０は接続されるそれぞれのハードウェアに対して専用のバスを有する構成でもよい。

実行空間２０はユーザによるアプリケーションの起動などによって発生する。例えばシステム制御部５０は、ユーザによる入出力装置６０からの起動指示などの要求信号を検出すると、外部記憶装置８０からメモリ７０にＯＳコード、プログラム、パラメータなどを読み込む。そして、実行に必要なＣＰＵ時間、メモリ７０の使用量などのリソース割り当てを行うことにより、実行空間２０を形成する。実行空間制御部４０はシステム制御部５０より割り当てられたリソースを、アプリケーション実行のために発生させたプロセスに割り当てる。これによりプロセス処理部３０は割り当てられたＣＰＵ時間に各プロセスの処理を行い、メモリ７０などへのアクセスを必要に応じて行う。

実行中のプロセスに、その進捗に応じてリソースの追加割り当ての必要性が生じた場合、プロセス処理部３０は実行空間制御部４０に対し新たなリソース割り当て要求を行う。実行空間制御部４０はまず、当該実行空間２０に確保しているリソースを確認し、要求を充足できればそれをプロセスに割り当てる。確保しているリソースに不足があればシステム制御部５０に対しリソース追加の要求を行う。そして所定の確認作業が行われた後、システム制御部５０は実行空間２０に対しリソースの追加割り当てを行う。リソースの割り当て手法については後述する。

図２はシステム制御部５０と第１実行空間２０ａのより詳細な構成を示す。第２実行空間２０ｂから第ｎ実行空間２０ｃまでの実行空間２０も、第１実行空間２０ａと同様の構成を有するが図示を省略している。第１プロセス処理部３０ａが処理する第Ａプロセス３２Ａ、第Ｂプロセス３２Ｂから第Ｎプロセス３２Ｎは、例えば１つのゲームを構成する画像処理のプロセスと音声処理のプロセスなどである。以降、第１から第Ｎの複数のプロセスのうちいずれかのプロセスの符号として単に３２と記載する場合もある。第１実行空間制御部４０ａは、第１実行空間２０ａが生成された際の、第１実行空間２０ａ内のリソース確保および起動するプログラムについての初期化処理を行うローカル初期化部４２、プロセス３２のいずれかがリソースの割り当てを要求した際、要求元のプロセス３２の名前を解決するローカル名前管理部４４、プロセス３２へのリソースの割り当ての実行可否の判定およびその後の処理、第１実行空間２０ａ全体のリソース管理を行うローカルリソース管理部４６を含む。

システム制御部５０は、実行空間２０の生成および初期化処理を行うグローバル初期化部５２、実行空間２０がリソースの割り当てを要求した際、要求元の実行空間２０の名前を解決するグローバル名前管理部５４、実行空間２０へのリソース割り当ての実行可否の判定およびその後の処理、情報処理装置１００全体のリソース管理を行うグローバルリソース管理部５６を含む。各機能ブロックは後述する手順に従い、必要に応じてメモリ７０およびハードディスク８２に対しデータの読み出しおよび書き込みを行う。

次に上述の構成による動作について説明する。なお、各種パラメータやテーブルについては、後に具体例を示して詳述する。図３は情報処理装置１００の起動時の動作の流れを示すフローチャートである。ユーザが起動入力などを行うと、まずシステム制御部５０は外部記憶装置８０から起動に必要なプログラム、パラメータなどをメモリ７０に読み込み、所定のＯＳプログラムを実行する（Ｓ１０）。ここでは必要に応じて読み込んだプログラムやパラメータの正当性を、電子署名の認証などにより検証する。ＯＳプログラムの実行の一部として、システム制御部５０のグローバル初期化部５２は、Ｓ１０で読み込んだパラメータのうち、生成すべき実行空間２０の情報を含むシステム初期化パラメータに基づき、所定個数の実行空間２０を生成する（Ｓ１２）。このとき各実行空間２０には、実行空間暫定ＩＤが、生成された順に付与される。さらにグローバル初期化部５２は、各実行空間２０において、ローカル初期化部４２、ローカル名前管理部４４、およびローカルリソース管理部４６を含む実行空間制御部４０を起動する（Ｓ１４）。この際、グローバル初期化部５２はローカル初期化部４２に、当該実行空間２０の初期確保リソース量や追加で確保できるリソース量の単位を含む実行空間初期化パラメータと、当該実行空間２０内で起動すべきプログラムの情報を示す起動プログラムリストを与える。実行空間初期化パラメータと起動プログラムリストは、Ｓ１０で読み込んだシステム初期化パラメータに含まれる情報である。

次にグローバル初期化部５２は、同じシステム制御部５０のグローバル名前管理部５４に、起動した実行空間２０の実行空間暫定ＩＤと、Ｓ１０で読み込んだシステム初期化パラメータに示される実行空間認証ＩＤとを与える。ここで実行空間認証ＩＤはあらかじめ定められた、実行空間２０に対応するソフトウェアの固定的ＩＤである。グローバル名前管理部５４は各実行空間２０の実行空間暫定ＩＤと実行空間認証ＩＤとを対応づけた実行空間名前テーブルを作成し、メモリ７０に保存する（Ｓ１６）。またグローバル初期化部５２は、グローバルリソース管理部５６に、Ｓ１０で読み込んだシステム初期化パラメータに含まれるリソース割り当ての制限情報を与える。グローバルリソース管理部５６はその情報をもとに、後に各実行空間２０に割り当てるリソースを管理するためのグローバルリソース管理テーブルを作成し、メモリ７０に保存する（Ｓ１８）。

Ｓ１４で起動した実行空間制御部４０のローカル初期化部４２は、グローバル初期化部５２より取得した実行空間初期化パラメータに基づき、初期に確保すべきリソース量をローカルリソース管理部４６に与え、ローカルリソース管理部４６はそのリソースを確保する手続きを行う（Ｓ２０）。手続きの詳細については後述する。リソース確保後、ローカルリソース管理部４６は、ローカル初期化部４２から与えられた、実行空間初期化パラメータに含まれる、追加で確保できるリソース量の単位と、Ｓ２０で確保したりソース量とを示すローカルリソース管理テーブルを作成し、メモリ７０に保存する（Ｓ２２）。

ローカル初期化部４２はさらに、Ｓ１４でグローバル初期化部５２より取得した起動プログラムリストに基づき、起動すべきプログラムを起動することにより各プロセス３２を生成する（Ｓ２４）。このとき各プロセス３２には、起動した順にプロセスＩＤが付与される。次にローカル初期化部４２は、ローカル名前管理部４４に、起動したプロセス３２のプロセスＩＤと、起動プログラムリストから取得できるプログラム認証ＩＤとを与える。ここでプログラム認証ＩＤは、実行空間認証ＩＤと同様、あらかじめ定められたプログラム固有のＩＤである。ローカル名前管理部４４は各プロセス３２のプロセスＩＤとプログラム認証ＩＤとを対応づけたプロセス名前テーブルを作成し、メモリ７０に保存する（Ｓ２６）。またローカル初期化部４２は、ローカルリソース管理部４６に、起動プログラムリストから取得できるリソース割り当ての制限に係る情報を与える。ローカルリソース管理部４６はその情報をもとに後に各プロセス３２に割り当てるリソースを管理するためのプロセスリソース管理テーブルを作成し、メモリ７０に保存する（Ｓ２８）。以上で情報処理装置１００の起動時の処理を終了する。

図４は上述の処理によって取得されるパラメータと作成されるテーブルとの相互関係を示す図である。図３のフローチャートに示したステップの符号のうち、図４中のパラメータの取得やテーブルの作成に対応するステップの符号を括弧内に示している。また図２に示した機能ブロックのうち、生成された各テーブルを参照する機能ブロックを図の右端に示している。まず、図３のＳ１０においてシステム制御部５０が読み込むシステム初期化パラメータ１０２には、生成すべき実行空間２０の実行空間認証ＩＤ１０４のリストと、それぞれの実行空間２０に割り当て可能なリソースの量または種類を示す割り当て可能リソース情報１０６と、実行空間２０が初期に確保すべきリソース量および追加で確保できるリソース量の単位（以後、「追加リソース単位」と呼ぶ）を含む実行空間初期化パラメータ２００と、実行空間２０内で起動すべきプログラムのプログラム認証ＩＤのリストと、それぞれのプログラムが利用可能なリソースの量または種類と、各プログラムのバイナリコードを含む、起動プログラムリスト２２０が含まれる。システム初期化パラメータ１０２に含まれる各パラメータの値は、各実行空間２０の発生元であるソフトウェアに付加された情報であり、例えばＣＤ−ＲＯＭ（Compact Disc Read Only Memory）にプログラムとともに記憶されているものを、メモリ７０にテーブルとして読み込んでおく。

実行空間認証ＩＤ１０４は図３のＳ１４で各実行空間２０に生成順に付与される実行空間暫定ＩＤ１３２と対応づけられ、Ｓ１６で実行空間名前テーブル１３０を構成する。実行空間名前テーブル１３０はグローバル名前管理部５４が参照し、リソース割り当て要求の発行元である実行空間２０の名前を解決する。実行空間認証ＩＤ１０４はさらに、システム初期化パラメータ１０２に含まれる割り当て可能リソース情報１０６と、後述する手続きにより実行空間２０に実際に割り当てられたリソースの情報である対実行空間割り当て済みリソース１４２とに対応づけられ、図３のＳ１８でグローバルリソース管理テーブル１４０を構成する。グローバルリソース管理テーブル１４０はシステム制御部５０のグローバルリソース管理部５６が参照し、実行空間２０が要求するリソース割り当て可否の判定に用いられる。対実行空間割り当て済みリソース１４２は初期値は図３のＳ２０、すなわち実行空間２０へのリソースの初期割り当ての段階で取得できるが、実行空間２０に対するリソース割り当ての変更があるたびに更新される。

システム初期化パラメータ１０２に含まれる実行空間初期化パラメータ２００は、上述の対実行空間割り当て済みリソース１４２と対応づけられ、図３のＳ２２で実行空間制御部４０が参照するローカルリソース管理テーブル１５０を構成する。ローカルリソース管理テーブル１５０はローカルリソース管理部４６が参照し、システム制御部５０へリソース要求を行うかどうかの判定と、要求する場合のリソース要求量の指定に用いられる。

システム初期化パラメータ１０２の起動プログラムリスト２２０に含まれるプログラム認証ＩＤは、同じく起動プログラムリスト２２０に含まれる、各プログラムを実行するプロセス３２の利用可能リソース情報と、後述する手続きにより各プロセス３２に実際に割り当てられたリソースの情報である対プロセス割り当て済みリソース１６２と、に対応づけられ、図３のＳ２８でプロセスリソース管理テーブル１６０を構成する。プロセスリソース管理テーブル１６０もローカルリソース管理部４６が参照し、プロセス３２が要求するリソース割り当ての可否判定に用いられる。対プロセス割り当て済みリソース１６２はプロセス３２に対するリソース割り当ての変更があるたびに更新される。さらにプログラム認証ＩＤは、図３のＳ２４で対応するプロセス３２を起動したときに起動順に付与されるプロセスＩＤ１７２と対応づけられ、図３のＳ２６でプロセス名前テーブル１７０を構成する。プロセス名前テーブル１７０はローカル名前管理部４４が参照し、リソース割り当て要求の発行元であるプロセス３２の名前を解決する。

次に、各テーブルの具体的な構造例を示す。図５はシステム初期化パラメータ１０２を記述するテーブルの構造例を示す。システム初期化パラメータテーブル１０２Ａは、実行空間認証ＩＤ欄１０４Ａ、メモリ量上限欄１０８Ａ、ＣＰＵ時間上限欄１１０Ａ欄、利用可能デバイスＩＤ欄１１２Ａ、ハードディスク容量上限欄１１４Ａ、実行空間初期化パラメータ欄２００Ａ、起動プログラムリスト欄２２０Ａを含む。

実行空間認証ＩＤ欄１０４Ａには、図４で示した、各実行空間２０の実行空間認証ＩＤ１０４が記述される。実行空間認証ＩＤ１０４は上述のとおり実行空間２０の発生元であるソフトウェアに付加され、ソフトウェアなどに対し一意的に決定される固定的なＩＤである。メモリ量上限欄１０８Ａ、ＣＰＵ時間上限欄１１０Ａ、利用可能デバイスＩＤ欄１１２Ａ、およびハードディスク容量上限欄１１４Ａには、それぞれの実行空間２０に対して割り当てられるメモリ量の上限、割り当てられるＣＰＵ時間の上限、実行空間２０が利用できるデバイス６２のＩＤ、および実行空間２０に対して割り当てられるハードディスク容量の上限がそれぞれ記述される。これらのパラメータは、図４で示した割り当て可能リソース情報１０６に含まれる。

メモリ量上限、ＣＰＵ時間上限、ハードディスク容量上限の値は、ソフトウェアの作成段階での検証実験などによって最適な値を取得する。デバイスＩＤは、デバイス６２に対し一意的に定められる固定的なＩＤである。利用可能なデバイス６２は、例えば自動車レースゲームを実行する実行空間２０であれば、方向指示ボタン式のコントローラとハンドル式のコントローラ、といった具合に、ソフトウェアの内容などによってこれも作成段階で決定する。なお図５の例では外部記憶装置８０をハードディスク８２で代表させたが、図示しないフラッシュメモリなど実行空間２０がアクセス可能な外部記憶装置８０であればハードディスク８２に限定されない。以降の説明ではハードディスク８２を例に説明する。

実行空間初期化パラメータ欄２００Ａには、図４で示した実行空間初期化パラメータ２００、すなわち初期確保リソース量および追加リソース単位が格納されたファイルの名前が記述される。または、初期確保リソース量および追加リソース単位を直接記述してもよい。図６は実行空間初期化パラメータ欄２００Ａに記述されたファイル、例えば「Ｐａｒａｍ＿Ａ」ファイルに格納されたテーブルの構造例を示す。実行空間初期化パラメータテーブル２００Ｂは、初期確保メモリ量欄２０２、追加確保メモリ量単位欄２０４、初期確保ＣＰＵ時間欄２０６、追加確保ＣＰＵ時間単位欄２０８を含む。初期確保メモリ量欄２０２および初期確保ＣＰＵ時間欄２０６にそれぞれ記述される初期確保メモリ量および初期確保ＣＰＵ時間は、実行空間２０の生成時に、当該実行空間２０が最初に確保すべきメモリ量およびＣＰＵ時間である。初期確保の処理は、図３に示す情報処理装置１００の起動時の手順ではＳ２０のステップに相当する。追加確保メモリ量単位欄２０４および追加確保ＣＰＵ時間単位欄２０８にそれぞれ記述される追加確保メモリ量単位および追加確保ＣＰＵ時間単位は、メモリ量またはＣＰＵ時間の追加割り当てを行う手続きにおいて参照される。詳細は後に述べるが、実行空間２０に対するメモリ量およびＣＰＵ時間の追加割り当ては、追加確保メモリ量単位または追加確保ＣＰＵ時間単位の自然数倍の量にて行われる。なお、実行空間初期化パラメータテーブル２００Ｂに記述される値も、ソフトウェア作成段階における検証実験などによって最適値が取得される。

図５に戻り、システム初期化パラメータテーブル１０２Ａの起動プログラムリスト欄２２０Ａには、図４で示した起動プログラムリスト２２０を格納するファイルの名前が記述される。または、起動プログラムリスト２２０を直接記述してもよい。図７は起動プログラムリスト欄２２０Ａに記述されたファイル、例えば「Ｐｒｇ＿Ｌｉｓｔ＿Ａ」ファイルに格納されたリストの構造例を示す。起動プログラムリスト２２０には、実行空間２０の発生元であるソフトウェアを構成するプログラムの情報を格納したプログラムファイルのファイル名が記述されるプログラムファイル名欄２２２が含まれる。

図８は起動プログラムファイル名欄２２２に記述されたプログラムファイル、例えば「ｐｒｇ１」ファイルに格納されたデータの構造例を示すテーブルである。プログラム情報テーブル２２２Ａは、プログラム認証ＩＤ欄２２４、メモリ量上限欄２２６、利用可能デバイスＩＤ欄２２８、ハードディスク使用可否欄２３０、およびコード欄２３２を含む。プログラム認証ＩＤ欄２２４には、プログラムに対し一意的に定められる固定的ＩＤであるプログラム認証ＩＤが記述される。メモリ量上限欄２２６および利用可能デバイスＩＤ欄２２８には、当該プログラムに対応するプロセス３２に対し割り当てられるメモリ量の上限と、利用可能なデバイス６２のＩＤが記述される。これらのパラメータは、システム初期化パラメータテーブル１０２Ａにおいて実行空間２０ごとに設定されたメモリ量上限および利用可能デバイスを、処理されるプログラムごと切り分けたものであり、ソフトウェアの作成段階で決定される。ハードディスク使用可否欄２３０には、当該プログラムに対応するプロセス３２がハードディスク８２を使用できるか否かを識別する文字列等が記述される。ハードディスク８２の使用可否はプログラムの内容等によってソフトウェアの作成段階で決定される。コード欄２３２にはプログラム本体として、バイナリ化されたコードが記述される。

なおプロセス３２に割り当て可能なＣＰＵ時間の上限は、ＯＳが一般的に提供する、ＣＰＵ時間の割り当て制御の機能を利用することにより設定可能なため、図８のプログラム情報テーブル２２２ＡにおいてはＣＰＵ時間の上限欄は設けていない。但しＣＰＵ時間上限欄をさらに設けて、本実施の形態におけるグローバルリソース管理部５６の管理対象とすることもできる。

図９は図３のＳ１６で生成される実行空間名前テーブル１３０の構造例を示す。実行空間名前テーブル１３０は、実行空間暫定ＩＤ欄１３２Ａおよび実行空間認証ＩＤ欄１０４Ａを含む。実行空間暫定ＩＤ欄１３２Ａに記述される実行空間暫定ＩＤ１３２は、図３のＳ１２で実行空間２０を生成した際に順次付与されるＩＤである。実行空間認証ＩＤ欄１０４Ａに記述される実行空間認証ＩＤ１０４は、図４で示したシステム初期化パラメータテーブル１０２Ａの実行空間認証ＩＤ欄１０４Ａに記述された値に対応する。グローバル名前管理部５４はそれらのＩＤを対応づけて実行空間名前テーブル１３０を生成する。

図１０は図３のＳ１８で生成されるグローバルリソース管理テーブル１４０の構造例を示す。グローバルリソース管理テーブル１４０は、実行空間認証ＩＤ欄１０４Ａ、メモリ量上限欄１０８Ａ、現割り当てメモリ量欄１４４、ＣＰＵ時間上限欄１１０Ａ、現割り当てＣＰＵ時間欄１４６、利用可能デバイスＩＤ欄１１２Ａ、およびハードディスク容量上限欄１１４Ａを含む。実行空間認証ＩＤ欄１０４Ａに記述される実行空間認証ＩＤ１０４は、図４で示したシステム初期化パラメータテーブル１０２Ａの実行空間認証ＩＤ欄１０４Ａに記述された実行空間認証ＩＤ１０４である。メモリ量上限欄１０８Ａ、ＣＰＵ時間上限欄１１０Ａ、利用可能デバイスＩＤ欄１１２Ａ、およびハードディスク容量上限欄１１４Ａに記述された値は、同じくシステム初期化パラメータテーブル１０２Ａのメモリ量上限欄１０８Ａ、ＣＰＵ時間上限欄１１０Ａ、利用可能デバイスＩＤ欄１１２Ａ、およびハードディスク容量上限欄１１４Ａに記述された値である。現割り当てメモリ量欄１４４および現割り当てＣＰＵ時間欄１４６には、図３のＳ２０でそれぞれの実行空間２０に割り当てたメモリ量およびＣＰＵ時間の初期値、あるいは、後述するようにそれらの追加割り当てを行った場合は追加後の値が記述される。

図１１は図３のＳ２２で生成されるローカルリソース管理テーブル１５０の構造例を示す。ローカルリソース管理テーブル１５０は、現確保メモリ量欄１５４、追加確保メモリ量単位欄２０４、現確保ＣＰＵ時間欄１５６、および追加確保ＣＰＵ時間単位欄２０８を含む。追加確保メモリ量単位欄２０４と追加確保ＣＰＵ時間単位欄２０８に記述される値はそれぞれ、図６で示した実行空間初期化パラメータテーブル２００Ｂの追加確保メモリ量単位欄２０４、および追加確保ＣＰＵ時間単位欄２０８にて設定された値である。現確保メモリ量欄１５４、および現確保ＣＰＵ時間欄１５６の値は、図３のＳ２０でそれぞれの実行空間２０が確保したメモリ量およびＣＰＵ時間の初期値、あるいは、後述するようにそれらの追加確保を行った場合は追加後の値が記述される。これらの値は、グローバルリソース管理テーブル１４０の現割り当てメモリ量欄１４４および現割り当てＣＰＵ時間欄１４６に記述された値に対応する。

図１２は図３のＳ２８で生成されるプロセスリソース管理テーブル１６０の構造例を示す。プロセスリソース管理テーブル１６０は、プログラム認証ＩＤ欄２２４、現割り当てメモリ量欄１６４、メモリ量上限欄２２６、現割り当てＣＰＵ時間欄１６６、利用可能デバイスＩＤ欄２２８、およびハードディスク使用可否欄２３０を含む。プログラム認証ＩＤ欄２２４に記述されるプログラム認証ＩＤは、図８で示したプログラム情報テーブル２２２Ａのプログラム認証ＩＤ欄２２４に記述されたプログラム認証ＩＤに対応する。メモリ量上限欄２２６、利用可能デバイスＩＤ欄２２８、およびハードディスク使用可否欄２３０には同じくプログラム情報テーブル２２２Ａの、メモリ量上限欄２２６、利用可能デバイスＩＤ欄２２８、およびハードディスク使用可否欄２３０にて設定された値が記述される。なお利用可能デバイスＩＤ欄２２８における「−」は利用可能デバイスがないことを表し、ハードディスク使用可否欄２３０における「−」はハードディスク８２の使用不可を表している。現割り当てメモリ量欄１６４と現割り当てＣＰＵ時間欄１６６の値は、後述する手続きにより、実行空間２０内の各プロセス３２へメモリ量およびＣＰＵ時間の割り当てを行った際の割り当て後の値である。

なおプロセスリソース管理テーブル１６０には、各プロセス３２に割り当てられたメモリ７０の物理アドレスなど、上述のパラメータ以外の、リソース管理に必要なパラメータを含めてよいが、ここでは説明を省略する。

図１３は図３のＳ２６で生成されるプロセス名前テーブル１７０の構造例を示す。プロセス名前テーブル１７０は、プロセスＩＤ欄１７２Ａおよびプログラム認証ＩＤ欄２２４を含む。プロセスＩＤ欄１７２Ａに記述されるプロセスＩＤ１７２は、図３のＳ２４で各プロセス３２を生成した際に順次付与される値である。プログラム認証ＩＤ欄２２４に記述されるプログラム認証ＩＤは、図８で示したプログラム情報テーブル２２２Ａのプログラム認証ＩＤ欄２２４に記述されたプログラム認証ＩＤである。ローカル名前管理部４４はそれらの値を対応づけてプロセス名前テーブル１７０を生成する。

次に図３のＳ２０において実行空間２０に対しリソースの初期割り当てを行う手続きについて説明する。図１４は実行空間２０にメモリ量またはＣＰＵ時間を割り当てる手順について示すフローチャートである。この手順は、情報処理装置１００の起動時の初期割り当て時のみならず、実行空間２０に属するプロセス処理に追加のリソースが必要となった際にも同様に行われる。まずローカルリソース管理部４６は、グローバルリソース管理部５６に対し、メモリ量またはＣＰＵ時間の割り当て要求を行う（Ｓ３０）。要求には実行空間初期化パラメータ２００に設定された、実行空間２０の初期確保リソース量のうち、メモリ量またはＣＰＵ時間の値が含まれる。図６に示した実行空間初期化パラメータテーブル２００Ｂに、さらに初期確保デバイスＩＤ欄や初期確保ハードディスク容量欄を設けることにより、ローカルリソース管理部４６は情報処理装置１００の起動時に、デバイスやハードディスク容量の割り当て要求をさらに行うようにしてもよい。以後の説明ではメモリ量またはＣＰＵ時間の要求について説明する。

ここでシステム制御部５０は情報処理装置１００に対してＯＳの役割を果たす。複数の実行空間２０ａ〜２０ｃの実行の切り替えもシステム制御部５０が提供する機能である。そしてローカルリソース管理部４６がグローバルリソース管理部５６に割り当て要求の通信を行う際、ローカルリソース管理部４６はシステム制御部５０が提供する通信機能を呼び出すため、システム制御部５０は通信機能を呼び出した実行空間２０を特定することができる。結果としてグローバルリソース管理部５６はＳ３０において割り当て要求を行った実行空間２０の実行空間暫定ＩＤ１３２を識別することができる。グローバルリソース管理部５６はグローバル名前管理部５４に対し、実行空間暫定ＩＤ１３２に基づき問い合わせを行い、要求元の実行空間２０の実行空間認証ＩＤ１０４を取得する（Ｓ３２）。

続いてグローバルリソース管理部５６は、実行空間認証ＩＤ１０４に基づきグローバルリソース管理テーブル１４０を参照し、要求される割り当てによって要求元の実行空間２０のメモリ量またはＣＰＵ時間の割り当て上限を超えないか確認を行う（Ｓ３４）。割り当て上限を超えていなければ（Ｓ３４のＹ）、グローバルリソース管理テーブル１４０の現割り当てメモリ量または現割り当てＣＰＵ時間を、割り当てを行った後の値に更新し（Ｓ３６）、スケジュールの更新やアドレスの確保などの割り当て処理を行い、ローカルリソース管理部４６に許可を発行する（Ｓ３８）。要求が割り当て上限を超える場合は（Ｓ３４のＮ）、割り当て拒否としてローカルリソース管理部４６にエラーを返し（Ｓ４０）終了する。なお割り当て可否判定を行うＳ３４のステップは、図３のＳ２０においてリソースの初期割り当てを行う際には常に「Ｙ」となるが、追加割り当ての際には「Ｙ」と「Ｎ」に分岐する。

ローカルリソース管理部４６は、Ｓ３０の割り当て要求に対し、メモリ量またはＣＰＵ時間の割り当てが行われたか、エラーが返されたかを確認する（Ｓ４２）。割り当てが行われていれば（Ｓ４２のＹ）、ローカルリソース管理テーブル１５０の現確保メモリ量または現確保ＣＰＵ時間を割り当て後の値に更新して（Ｓ４４）終了し、エラーであれば（Ｓ４２のＮ）、そのまま終了する。

実行空間２０に属するプロセス処理に追加のリソースが必要となった際は、図１４の手順の前段階として、プロセス３２からローカルリソース管理部４６に対し、メモリ量またはＣＰＵ時間の割り当て要求がなされる。そして当該実行空間２０で確保済みのメモリ量またはＣＰＵ時間によってその要求が充足される場合は、図１４の手続きを行う必要がなくなる。

図１５は上述のようにプロセス３２に対してメモリ量またはＣＰＵ時間を割り当てる際の手順を示すフローチャートである。まずプロセス３２は、プロセス３２自体が生成された際、または所要メモリ量や所要ＣＰＵ時間が不足した場合に、同じ実行空間２０に属するローカルリソース管理部４６に対し、メモリ量またはＣＰＵ時間の割り当て要求を行う（Ｓ５０）。要求には所要のメモリ量またはＣＰＵ時間の値が含まれる。ローカルリソース管理部４６は所属する実行空間２０内で処理されているプロセス３２の割り当て要求を受け付ける。ここでローカルリソース管理部４６を含む実行空間制御部４０は実行空間２０に対してＯＳの役割を果たす。複数のプロセス３２Ａ〜３２Ｎの実行の切り替えも実行空間制御部４０が提供する機能である。そしてプロセス３２がローカルリソース管理部４６に割り当て要求の通信を行う際、プロセス３２は実行空間制御部４０が提供する通信機能を呼び出すため、実行空間制御部４０は通信機能を呼び出したプロセス３２を特定することができる。結果としてローカルリソース管理部４６はＳ５０において割り当て要求を行ったプロセス３２のプロセスＩＤ１７２を識別することができる。ローカルリソース管理部４６はローカル名前管理部４４に対しプロセスＩＤ１７２に基づき問い合わせを行い、要求元のプロセス３２のプログラム認証ＩＤを取得する（Ｓ５２）。

続いてローカルリソース管理部４６は、プログラム認証ＩＤに基づきプロセスリソース管理テーブル１６０を参照し、割り当てによって要求元のプロセス３２のメモリ量またはＣＰＵ時間の割り当て上限を超えないか確認を行う（Ｓ５４）。割り当て上限を超えている場合（Ｓ５４のＮ）、ローカルリソース管理部４６は割り当て拒否としてプロセス３２にエラーを返す（Ｓ６０）。割り当て上限を超えない場合（Ｓ５４のＹ）、ローカルリソース管理部４６は続いてローカルリソース管理テーブル１５０を参照し、要求されている割り当てが実行空間２０における現確保メモリ量または現確保ＣＰＵ時間で充足するか確認を行う（Ｓ５６）。

現確保メモリ量または現確保ＣＰＵ時間では要求に対し不足する場合（Ｓ５６のＮ）、ローカルリソース管理部４６はグローバルリソース管理部５６に対し、メモリ量またはＣＰＵ時間の割り当て要求を行う（Ｓ３０）。これは図１４のＳ３０のステップと同様である。但しこの場合の要求に含まれるメモリ量またはＣＰＵ時間の要求値は、プロセス３２が要求したメモリ量またはＣＰＵ時間以上であり、かつ、ローカルリソース管理テーブル１５０に記述された追加確保メモリ量単位または追加確保ＣＰＵ時間単位の自然数倍の値となる。以降、グローバルリソース管理部５６における処理手順は、図１４のＳ３２からＳ４０と同様である。

そしてローカルリソース管理部４６は、グローバルリソース管理部５６から新たなメモリ量またはＣＰＵ時間が割り当てられたかを確認する（Ｓ４２）。割り当てられていれば（Ｓ４２のＹ）、ローカルリソース管理テーブル１５０の現確保メモリ量欄１５４または現確保ＣＰＵ時間欄１５６の値を更新する（Ｓ４４）。新たな割り当てがなされなければ（Ｓ４２のＮ）、割り当て拒否としてプロセス３２に対しエラーを返す（Ｓ６２）。

実行空間２０の現確保メモリ量または現確保ＣＰＵ時間が要求に対し十分である場合（Ｓ５６のＹ）、および、グローバルリソース管理部５６へ割り当て要求を行い実行空間２０に新たにメモリ量またはＣＰＵ時間を確保した場合（Ｓ４２のＹ）、ローカルリソース管理部４６は、Ｓ５０においてプロセス３２が要求した分だけのメモリ量またはＣＰＵ時間をプロセス３２に割り当てる。具体的には、プロセスリソース管理テーブル１６０のうち、要求元のプロセス３２に対応する現割り当てメモリ量欄１６４または現割り当てＣＰＵ時間欄１６６の欄を更新し（Ｓ５８）、プロセス３２に対し割り当て許可通知を送信するなどの割り当て処理を行う（Ｓ６４）。プロセス３２が要求に対する許可、不許可の結果を検知して（Ｓ６６）、本割り当て処理は終了する。プロセス３２への許可通知に係るＳ６４およびＳ６６のステップにおいては、実際にはメモリアドレスの通知やスケジュールの更新などの処理を適宜行ってよい。

図１４および図１５で説明したように、本実施の形態では、実行空間２０に対するメモリ量およびＣＰＵ時間の割り当ては、あらかじめ設定された初期確保量、または追加リソース単位で行われる。そのため、実行空間２０に割り当てられたメモリ量またはＣＰＵ時間は、要求元のプロセス３２の要求値以上となり、発生した余剰分は実行空間２０内でそのまま確保する。そして、次に当該実行空間２０内のプロセス３２においてメモリ量またはＣＰＵ時間が不足したときに、まず実行空間２０内で確保したメモリ量またはＣＰＵ時間によって割り当てが可能であるか否かを確認する。可能であれば実行空間２０内部の処理のみで割り当てを完了させることができる。そのため、実行空間２０外部との通信回数が減り、かつ、割り当て要求に対応する処理の負荷を分散させることができる。結果として割り当て処理に係るオーバーヘッドを軽減することができる。

次に情報処理装置１００のリソースのうち、デバイス６２の割り当てを行う手続きについて説明する。デバイス６２は、図６で示した実行空間初期化パラメータテーブル２００Ｂには記述されていない。この場合は、情報処理装置１００の起動時には実行空間２０にメモリ量およびＣＰＵ時間のみを割り当ててプロセス３２を生成し、後に各プロセス３２からの要求によって実行空間２０にデバイス６２の割り当てを行うことになる。一方、起動時に実行空間２０が確保すべきデバイス６２のデバイスＩＤを実行空間初期化パラメータテーブル２００Ｂに含めることにより、プロセス３２の生成前に実行空間２０にデバイス６２をも割り当てるようにしてもよい。この場合は、以下に述べるデバイス６２の割り当て手続きのうち、図１８に示す、ローカルリソース管理部４６からグローバルリソース管理部５６への割り当て要求を先に行うことになる。以下では、プロセス３２からローカルリソース管理部４６への割り当て要求、ローカルリソース管理部４６からグローバルリソース管理部５６への割り当て要求、という順序で説明する。

図１６はプロセス３２に対してデバイス６２を割り当てる際の手順を示すフローチャートである。この手順はプロセス３２生成時にデバイス６２を割り当てる場合、または処理の途中でデバイス６２へのアクセスが必要となった場合に行われる。まずプロセス３２は同じ実行空間２０に属するローカルリソース管理部４６に対し、デバイス６２の割り当て要求を行う（Ｓ７０）。要求には所要のデバイス６２のデバイスＩＤが含まれる。ローカルリソース管理部４６は所属する実行空間２０内で処理されているプロセス３２の割り当て要求を受け付ける。ここでは要求の授受を行う通信によって、要求元のプロセス３２のプロセスＩＤ１７２が識別される。ローカルリソース管理部４６はローカル名前管理部４４に対しプロセスＩＤ１７２に基づき問い合わせを行い、要求元のプロセス３２のプログラム認証ＩＤを取得する（Ｓ７２）。続いてローカルリソース管理部４６は、プログラム認証ＩＤに基づきプロセスリソース管理テーブル１６０を参照し、要求されたデバイス６２のデバイスＩＤが要求元のプロセス３２の利用可能デバイスＩＤ欄２２８に含まれているか確認を行う（Ｓ７４）。含まれていなければ（Ｓ７４のＮ）割り当て拒否としてプロセス３２にエラーを返す（Ｓ７８）。

要求されたデバイスＩＤが利用可能デバイスＩＤ欄２２８に含まれていた場合（Ｓ７４のＹ）、ローカルリソース管理部４６は続いてデバイス管理テーブルを参照し、要求されたデバイス６２のアクセッサが存在するか確認する（Ｓ７６）。デバイス管理テーブルは、以前に実行空間２０に割り当てられたデバイス６２のデバイスＩＤと、割り当て時に取得したアクセッサとを対応づけたテーブルである。ここでアクセッサとはデバイス６２にアクセスするのに必要なパラメータおよびデータのセットのことであり、例えばデバイス操作を行うための専用の通信ハンドラーなどである。本実施の形態では実行空間２０が一旦取得したデバイス６２のアクセッサをそのまま確保しておくことにより、次に同じ実行空間２０内のプロセス３２が同一のデバイス６２を必要とした際は、再度そのアクセッサを用いる。デバイス管理テーブルの構造例については後述する。

デバイス管理テーブルに、要求されたデバイス６２のデバイスＩＤが存在しない場合は（Ｓ７６のＮ）、過去に当該デバイス６２へのアクセスが確立されなかったとして、ローカルリソース管理部４６はグローバルリソース管理部５６に対し、デバイス６２の割り当て要求を行う（Ｓ８０）。グローバルリソース管理部５６はこの要求を受け付け、要求元の実行空間２０への割り当てが可能であればローカルリソース管理部４６に対しアクセッサを返し、不可能であればエラーを返す。グローバルリソース管理部５６に対するデバイス割り当ての要求手続きについては図１８で詳述する。ローカルリソース管理部４６はグローバルリソース管理部５６からアクセッサを取得したら（Ｓ８２のＹ）、デバイスＩＤと取得したアクセッサとを対応づけてデバイス管理テーブルを更新する（Ｓ８６）。アクセッサが取得できなければ（Ｓ８２のＮ）、デバイス６２の割り当て拒否としてプロセス３２に対しエラーを返す（Ｓ８４）。

プロセス３２が要求したデバイス６２のアクセッサが元々取得されていた場合（Ｓ７６のＹ）、および、グローバルリソース管理部５６へ要求して実行空間２０に新たなアクセッサを取得した場合（Ｓ８２のＹ）、ローカルリソース管理部４６はプロセス３２に対しアクセッサを通知する（Ｓ８８）。そしてプロセス３２がデバイス割り当て要求の許可または不許可の結果を検知して（Ｓ９０）、一連の処理が終了する。割り当てが許可されたプロセス３２は取得したアクセッサに基づき随時デバイス６２にアクセスを行う。

図１７は図１６のＳ７６において参照され、Ｓ８６において更新される、デバイス管理テーブルの構造例を示す。デバイス管理テーブル２５０はデバイスＩＤ欄２５２およびアクセッサ欄２５４を含む。実行空間２０にデバイス６２の割り当てがなされると、当該デバイス６２のデバイスＩＤがデバイスＩＤ欄２５２に、取得したアクセッサがアクセッサ欄２５４に記述される。したがってプロセス３２が要求したデバイス６２のデバイスＩＤがデバイスＩＤ欄２５２に存在すれば、そのデバイス６２は当該実行空間２０に割り当て済みであることがわかる。デバイス管理テーブル２５０はローカルリソース管理部４６がローカルリソース管理テーブル１５０などとともに管理し、メモリ７０などに格納される。

次に図１６のＳ８０からＳ８６に示した、ローカルリソース管理部４６によるデバイス割り当て確保の手続きについて詳述する。図１８は実行空間２０にデバイス６２の割り当てを行う手順について示すフローチャートである。まずローカルリソース管理部４６は、グローバルリソース管理部５６に対し、デバイス６２の割り当て要求を行う（Ｓ８０）。このステップは図１６のＳ８０に対応する。要求には、要求するデバイス６２のデバイスＩＤが含まれる。要求の授受を行う通信によって、要求元の実行空間２０の実行空間暫定ＩＤ１３２が識別される。グローバルリソース管理部５６はグローバル名前管理部５４に対し実行空間暫定ＩＤ１３２に基づき問い合わせを行い、要求元の実行空間２０の実行空間認証ＩＤ１０４を取得する（Ｓ９２）。続いてグローバルリソース管理部５６は、実行空間認証ＩＤ１０４に基づきグローバルリソース管理テーブル１４０を参照し、要求されたデバイス６２のデバイスＩＤが要求元の実行空間２０の利用可能デバイスＩＤ欄１１２Ａに含まれているか確認を行う（Ｓ９４）。含まれていれば（Ｓ９４のＹ）、当該デバイス６２にアクセスするためのアクセッサを生成し、ローカルリソース管理部４６に与える（Ｓ９６）。含まれていなければ、割り当て拒否としてローカルリソース管理部４６にエラーを返す（Ｓ９８）。

ローカルリソース管理部４６は、グローバルリソース管理部５６よりアクセッサを取得できればデバイス管理テーブル２５０を更新して（Ｓ８６）終了する。アクセッサを取得できなかった場合（Ｓ８２のＮ）はそのまま終了する。こうして実行空間２０に対するデバイス割り当て処理を完了する。図１８のＳ８２およびＳ８６は図１６のＳ８２およびＳ８６と対応するステップである。なお、図１８はローカルリソース管理部４６からグローバルリソース管理部５６へのデバイス割り当て要求の手続きを示しているため、Ｓ８２のＮおよびＳ８６の次のステップを「終了」としているが、この手続きの前段階として、プロセス３２からのデバイス割り当て要求がある場合は、図１６に示したとおりプロセス３２への結果通知を行う処理を続行する。

図１６および図１８に示したとおり本実施の形態では、一度アクセスを確立したデバイス６２へのアクセッサを、実行空間２０内でそのまま確保する。そして同実行空間２０内のプロセス３２が次にデバイス６２へのアクセスを要求した際、まず実行空間２０内で、当該デバイス６２とのアクセスが以前に確立しているかを確認する。確立していれば、実行空間２０内部の処理のみで割り当てを完了させることができる。そのため、メモリ量やＣＰＵ時間の場合と同様、実行空間２０外部との通信回数が減り、かつ、割り当て要求に対応する処理の負荷を分散させることができる。結果として割り当て処理に係るオーバーヘッドを軽減することができる。

次に情報処理装置１００のリソースのうち、ハードディスク８２の容量を割り当てを行う手続きについて説明する。ハードディスク８２もデバイス６２と同様、図６で示した実行空間初期化パラメータテーブル２００Ｂには記述されていない。したがって以下の説明では、プロセス３２からの要求によってハードディスク８２の容量割り当てを行う場合を述べる。一方、デバイス６２同様、起動時に実行空間２０が確保すべきハードディスク容量を実行空間初期化パラメータテーブル２００Ｂに含め、プロセス３２の生成前に実行空間２０にハードディスク容量を割り当てるようにしてもよい。この場合は、以下に述べるハードディスク容量の割り当て手続きのうち、図２１および図２３に示す、ローカルリソース管理部４６からグローバルリソース管理部５６への割り当て要求を先に行うことになる。

図１９はプロセス３２に対してハードディスク容量を割り当てる際の手順を示すフローチャートである。この手順はプロセス３２生成時にハードディスク容量を割り当てる場合、処理の途中でハードディスク８２へのアクセスが必要となった場合、またはハードディスク容量が不足した場合に行われる。まずプロセス３２は同じ実行空間２０に属するローカルリソース管理部４６に対し、ハードディスク容量の割り当て要求を行う（Ｓ１００）。ローカルリソース管理部４６は所属する実行空間２０内で処理されているプロセス３２の割り当て要求を受け付ける。ここでは要求の授受を行う通信によって、要求元のプロセス３２のプロセスＩＤ１７２が識別される。ローカルリソース管理部４６はローカル名前管理部４４に対しプロセスＩＤ１７２に基づき問い合わせを行い、要求元のプロセス３２のプログラム認証ＩＤを取得する（Ｓ１０２）。続いてローカルリソース管理部４６は、プログラム認証ＩＤに基づきプロセスリソース管理テーブル１６０を参照し、要求元のプロセス３２がハードディスク８２の使用を許可されているかをハードディスク使用可否欄２３０にて確認する（Ｓ１０４）。ハードディスク８２の使用が不可であった場合は（Ｓ１０４のＮ）、ローカルリソース管理部４６はハードディスク８２の割り当て拒否としてプロセス３２にエラーを返す（Ｓ１０８）。

ハードディスク８２の利用が可能であったら（Ｓ１０４のＹ）、ローカルリソース管理部４６は続いてハードディスク管理テーブルを参照し、ハードディスク８２のアクセッサが存在するか確認する（Ｓ１０６）。ハードディスク管理テーブルは、以前に実行空間２０にハードディスク容量の割り当てがなされた際に取得したアクセッサを記憶したテーブルである。本実施の形態では実行空間２０に一旦割り当てられたハードディスク領域へのアクセッサをそのまま確保しておくことにより、次に同じ実行空間２０内のプロセス３２がハードディスク８２へのアクセスを必要とした際は、再度そのアクセッサを用いる。ハードディスク管理テーブルの構造例については後述する。

ハードディスク管理テーブルにハードディスク８２へのアクセッサが存在しない場合、あるいはハードディスク管理テーブルそのものが存在しない場合（Ｓ１０６のＮ）、ローカルリソース管理部４６はグローバルリソース管理部５６に対し、ハードディスク８２のマウント要求、および必要であればハードディスク容量の割り当て要求を行う（Ｓ１１０）。グローバルリソース管理部５６はこの要求を受け付け、要求元の実行空間２０に対し、必要ならハードディスク容量の割り当てを行い、ハードディスク８２のマウントが完了すればローカルリソース管理部４６に対し生成したアクセッサを返し、不可能であればエラーを返す。グローバルリソース管理部５６に対するマウントおよび割り当て要求の手続きについては図２１および図２３で詳述する。ローカルリソース管理部４６はグローバルリソース管理部５６からアクセッサを取得したら（Ｓ１１２のＹ）、ハードディスク管理テーブルにアクセッサを書き込む（Ｓ１１４）。アクセッサが取得できなければ（Ｓ１１２のＮ）、ハードディスク容量の割り当て拒否としてプロセス３２に対しエラーを返す（Ｓ１１６）。

プロセス３２に割り当てるハードディスク領域へのアクセッサが元々取得されていた場合（Ｓ１０６のＹ）、および、グローバルリソース管理部５６へ要求して新たなアクセッサを取得した場合（Ｓ１１２のＹ）、ローカルリソース管理部４６はプロセス３２に対しアクセッサを通知する（Ｓ１１８）。そしてプロセス３２がハードディスク容量割り当て要求の許可または不許可の結果を検知して（Ｓ１２０）、一連の処理が終了する。割り当てが許可されたプロセス３２は取得したアクセッサに基づき随時ハードディスク８２にアクセスを行う。

図２０は図１９のＳ１０６において参照され、Ｓ１１４において更新される、ハードディスク管理テーブルの構造例を示す。ハードディスク管理テーブル２６０はハードディスクアクセッサ欄２６２を含む。実行空間２０にハードディスク領域の割り当てがなされると、取得したアクセッサがハードディスクアクセッサ欄２６２に記述される。したがってハードディスクアクセッサ欄２６２にアクセッサが存在すれば、当該実行空間２０にハードディスク８２の領域が割り当て済みであることがわかる。ハードディスク管理テーブル２６０はローカルリソース管理部４６がローカルリソース管理テーブル１５０やデバイス管理テーブル２５０などとともに管理し、メモリ７０などに格納される。

次に図１９のＳ１１０からＳ１１４に示した、ローカルリソース管理部４６によるハードディスク８２のマウントまたはハードディスク容量の割り当て要求の手続きについて詳述する。図２１は実行空間２０にハードディスク８２のマウントを行う手順について示すフローチャートである。図１９のＳ１０６において実行空間２０がハードディスク８２とのアクセスを確立していなかった場合（Ｓ１０６のＮ）、ローカルリソース管理部４６はまず、グローバルリソース管理部５６に対しハードディスク８２のマウント要求を行う。これは、それまでの情報処理装置１００による処理において、当該実行空間２０にハードディスク容量の割り当てが行われていた場合に、ハードディスク８２内の同一レコードにアクセスする必要があるためである。例えば進捗状況の情報をセーブして処理を終了したゲームを再開するために、セーブされた情報を読み出す場合がこれに相当する。このため、まず最初にマウント要求を行ってハードディスク８２内に該当レコードがあるか確認し、あればその領域をマウントすることになる。

まずローカルリソース管理部４６は、グローバルリソース管理部５６に対し、ハードディスク８２のマウント要求を行う（Ｓ１３０）。このステップは図１９のＳ１１０のマウント要求に対応する。ここでは要求の授受を行う通信によって、要求元の実行空間２０の実行空間暫定ＩＤ１３２が識別される。グローバルリソース管理部５６はグローバル名前管理部５４に対し実行空間暫定ＩＤ１３２に基づき問い合わせを行い、要求元の実行空間２０の実行空間認証ＩＤ１０４を取得する（Ｓ１３２）。続いてグローバルリソース管理部５６は、実行空間認証ＩＤ１０４に基づきハードディスク８２内部に格納されているハードディスク内部管理テーブルを参照し、要求元の実行空間２０に対応するレコードが存在するか確認を行う（Ｓ１３４）。ハードディスク内部管理テーブルは、実行空間２０に割り当てられたハードディスク領域の容量と、その先頭アドレスとを、実行空間認証ＩＤ１０４に対応づけたテーブルである。前述のとおり、実行空間２０内の各プロセス３２は情報処理装置１００の電源のオン／オフに関わらず、同一レコードにアクセスする必要があるため、ハードディスク内部管理テーブルは情報処理装置１００の電源をオフしても失われることのないように、ハードディスク８２自体に格納される。ハードディスク内部管理テーブルの構造例については後述する。

ハードディスク内部管理テーブルに、対応するレコードが存在する場合は（Ｓ１３４のＹ）、当該領域にアクセスするためのアクセッサを生成し、ローカルリソース管理部４６に与える（Ｓ１３６）。存在しなければ（Ｓ１３４のＮ）、ローカルリソース管理部４６に対し、実行空間２０へのハードディスク容量の割り当てが行われていない旨の通知を行う（Ｓ１３８）。

ハードディスク容量の未割り当て通知を受け取らなかったら（Ｓ１４０のＮ）、ローカルリソース管理部４６はグローバルリソース管理部５６が生成したアクセッサを取得し（Ｓ１４２）、ハードディスク管理テーブル２６０にアクセッサを書き込む（Ｓ１１４）。このステップは図１９のＳ１１４に対応する。一方、ローカルリソース管理部４６が、ハードディスク８２の未割り当て通知を受け取った場合は（Ｓ１４０のＹ）、ハードディスク容量の割り当てのための処理を行う（Ｓ１４４）。このステップは実際にはローカルリソース管理部４６とグローバルリソース管理部５６との協働で行われるが、具体的な手順については図２３に示し、図２１ではわかり易さのためにひとつのステップで示している。

Ｓ１４４のハードディスク容量割り当て処理の結果、実行空間２０にハードディスク容量が割り当てられたら（Ｓ１４６のＹ）、ローカルリソース管理部４６は再度ハードディスク８２のマウント要求を行う（Ｓ１３０）。その後は上述と同様の手順を経て、最終的にローカルリソース管理部４６は、ハードディスク８２へアクセスするためのアクセッサをグローバルリソース管理部５６から取得する。ハードディスク容量の割り当てがなされなかった場合は（Ｓ１４６のＮ）、一連の手続きを終了する。ここでＳ１１４およびＳ１４６のＮの後の「終了」としたステップは、ハードディスク８２のマウントに係る手続きを終了したことを意味しており、この手続きの前段階として、プロセス３２からのハードディスク容量割り当て要求がある場合は、図１９に示したとおりプロセス３２への結果通知を行う処理を続行する。具体的には、Ｓ１１４のステップの後は図１９のＳ１１４のステップの後と同様、アクセッサの通知処理を行う（Ｓ１１８）。一方Ｓ１４６のＮの後は、アクセッサが取得できなかったとして、図１９のＳ１１６に示すとおり割り当て拒否のエラーをプロセス３２に返す。

図２２は図２１のＳ１３４において参照されるハードディスク内部管理テーブルの構造例を示す。ハードディスク内部管理テーブル２７０は、実行空間認証ＩＤ欄１０４Ａ、割り当て済み容量欄２７２、および先頭アドレス欄２７４を含む。実行空間認証ＩＤ欄１０４Ａには、ハードディスク容量を割り当て済みの実行空間２０の実行空間認証ＩＤ１０４が、割り当て済み容量欄２７２には、各実行空間２０に割り当てたハードディスク領域の容量が、先頭アドレス欄２７４には各実行空間２０に割り当てたハードディスク領域の先頭アドレスが記述される。実行空間２０にハードディスク容量の新規割り当てを行った場合は、ハードディスク内部管理テーブル２７０の行が追加され、ハードディスク容量を追加で割り当てた場合は割り当て済み容量欄２７２などが適宜更新される。ハードディスク内部管理テーブル２７０は前述のとおり、ハードディスク８２内に格納される。なおハードディスク内部管理テーブル２７０には、ハードディスク８２の領域管理を行うための、先頭アドレス以外のパラメータを含めてよい。

図２３は実行空間２０へのハードディスク容量の割り当て処理の手順について示すフローチャートである。この処理は、図２１に示したように、先にマウント処理の試行を行ってからＳ１４４のステップとして行ってもよいし、単独で実行し、後から図２１のマウント処理を行ってもよい。後者は、新規ソフトウェア起動時の初期処理のように、あらかじめハードディスク容量の割り当てが行われていないことがわかっている場合に行われる。また、すでに割り当てられたハードディスク容量があるが、追加で割り当てが必要となった場合も、本図のハードディスク容量割り当て処理をまず行う。

まずローカルリソース管理部４６は、グローバルリソース管理部５６に対し、ハードディスク８２の割り当て要求を行う（Ｓ１５０）。このステップは図１９のＳ１１０の割り当て要求に対応する。要求の授受を行う通信によって、要求元の実行空間２０の実行空間暫定ＩＤ１３２が識別される。グローバルリソース管理部５６はグローバル名前管理部５４に対し実行空間暫定ＩＤ１３２に基づき問い合わせを行い、要求元の実行空間２０の実行空間認証ＩＤ１０４を取得する（Ｓ１５２）。続いてグローバルリソース管理部５６は、実行空間認証ＩＤ１０４に基づきハードディスク８２内部に格納されているハードディスク内部管理テーブル２７０を参照し、要求元の実行空間２０に対応するレコードが存在するか確認を行う（Ｓ１５４）。本図のハードディスク容量割り当て処理を、図２１に示したマウント処理の一部として行う場合、図２３のＳ１５２およびＳ１５４は図２１のＳ１３２およびＳ１３４と同じ処理のため、適宜省略してよい。

該当レコードが存在する場合、すなわちローカルリソース管理部４６からの要求が、ハードディスク容量の追加割り当て要求であった場合は（Ｓ１５４のＹ）、同じハードディスク内部管理テーブル２７０を参照し、要求元の実行空間２０に割り当て済みの容量を、割り当て済み容量欄２７２より取得する（Ｓ１５６）。次にグローバルリソース管理部５６はグローバルリソース管理テーブル１４０のハードディスク容量上限欄１１４Ａから、要求元の実行空間２０の、ハードディスク容量の割り当て上限を取得し、割り当て済みの容量が割り当て上限未満であるか確認する（Ｓ１５８）。割り当て済みの容量が割り当て上限以上であった場合（Ｓ１５８のＮ）、それ以上の割り当てはできないため、割り当て拒否としてローカルリソース管理部４６に対しエラーを返す（Ｓ１６０）。

要求元の実行空間２０に割り当て済みのハードディスク容量が割り当て上限未満であった場合（Ｓ１５８のＹ）、または、ローカルリソース管理部４６からの割り当て要求が新規であった場合（Ｓ１５４のＮ）、グローバルリソース管理部５６はハードディスク８２内に格納されている空き容量管理テーブルを参照し、割り当てられる空き容量がハードディスク８２に残っているかを確認する（Ｓ１６２）。空き容量管理テーブルは、ハードディスク８２の空き領域の容量と空き領域の先頭アドレスを記述したテーブルであり、ハードディスク内部管理テーブル２７０とともにハードディスク８２内に格納される。空き容量管理テーブルの構造例については後述する。割り当てられる容量がハードディスク８２に残っていなかったら（Ｓ１６２のＮ）、グローバルリソース管理部５６は割り当て拒否としてローカルリソース管理部４６に対しエラーを返す。割り当てられる容量が存在したら（Ｓ１６２のＹ）、割り当てる領域を決定し、ローカルリソース管理部４６にその情報を通知するなどの割り当て処理を行う（Ｓ１６６）。割り当てる容量は、ローカルリソース管理部４６が割り当て要求に含めてもよいし、グローバルリソース管理部５６において適宜決定してもよい。続いてグローバルリソース管理部５６は、ハードディスク８２にアクセスを行い、ハードディスク内部管理テーブル２７０および空き容量管理テーブルに含まれるパラメータのうち変更したパラメータを更新する（Ｓ１６８）。

ローカルリソース管理部４６は、グローバルリソース管理部５６から送信される、割り当てられたハードディスク容量に関する情報またはエラーを検知し（Ｓ１７０）、一連の処理を終了する。ここで「終了」とはハードディスク容量の割り当て処理の終了を意味している。したがって、図２１のＳ１４４、すなわちマウント処理の一部として本図の処理を行った場合は、「終了」に変わり図２１のＳ１４６の割り当て完了の判定を行い、割り当てが行われている場合は（Ｓ１４６のＹ）、Ｓ１３０のマウント要求を引き続き行う。単独で本図のハードディスク容量割り当て処理を行った場合も、割り当てが成功した場合は図２１のマウント処理を行う。そしてグローバルリソース管理部５６において生成されたアクセッサをローカルリソース管理部４６が取得することによって、実行空間２０のハードディスク８２へのアクセスが確立する。

図２４は図２３のＳ１６２で参照され、Ｓ１６８で更新される、空き容量管理テーブルの構造例を示している。空き容量管理テーブル２８０は、空き容量欄２８２および先頭アドレス欄２８４を含む。空き容量欄２８２にはハードディスク８２の空き領域の容量が、先頭アドレス欄２８４には空き領域の先頭アドレスが記述される。空き容量管理テーブル２８０は、実行空間２０に対しハードディスク容量の割り当てが行われた際、適宜更新される。なお空き容量管理テーブル２８０には、ハードディスク８２の領域管理を行うための、先頭アドレス以外のパラメータを含めてよい。

図１９、図２１、および図２３に示したとおり本実施の形態では、一度アクセスを確立したハードディスク８２へのアクセッサを、実行空間２０内でそのまま確保する。そして同実行空間２０内のプロセス３２が次にハードディスク８２へのアクセスを要求した際、まず実行空間２０内で、以前にアクセスが確立しているかを確認する。確立していれば、実行空間２０内部の処理のみで割り当てを完了させることができる。そのため、メモリ量やＣＰＵ時間、デバイスの場合と同様、実行空間２０外部との通信回数が減り、かつ、割り当て要求に対応する処理の負荷を分散させることができる。結果として割り当て処理に係るオーバーヘッドを軽減することができる。

以上の処理により各実行空間２０および各プロセス３２へ割り当てられたリソースは、実行空間２０またはプロセス３２が消滅した際に、グローバルリソース管理部５６またはローカルリソース管理部４６に返却される。ここで「消滅」とは、例えばあるゲームプレイが終了し、それを実行していた実行空間２０が不要となったり、ゲーム内であるステージが終了した際、そのステージを処理していたプログラムが終了となる等の場合に相当する。リソースの「返却」処理は、まずグローバルリソース管理部５６またはローカルリソース管理部４６が、実行空間２０またはプロセス３２が消滅したことを検知する。そしてそれぞれ、グローバルリソース管理テーブル１４０またはプロセスリソース管理テーブル１６０から、消滅した実行空間２０またはプロセス３２に対応する行を削除する。さらにハードディスク内部管理テーブル２７０や空き容量管理テーブル２８０を適宜更新するなどして、返却されたリソースを他の実行空間２０や他のプロセス３２に割り当て可能な状態とする。

また、実行空間２０に割り当てられたリソースのうち、上述のようにプロセス３２が消滅するなどして余剰となり、所定の期間使用されなかったリソースは、実行空間２０からグローバルリソース管理部５６へ返却するようにしてもよい。図２５はこのような場合に実行空間２０に割り当てられたリソースを返却する処理の手順を示すフローチャートである。ローカルリソース管理部４６は、対応する実行空間２０に割り当てられ、プロセス３２に割り当てられていない状態のリソース、すなわち余剰リソースの時間変化を監視する（Ｓ１８０）。余剰リソースは、ローカルリソース管理テーブル１５０、デバイス管理テーブル２５０、およびハードディスク管理テーブル２６０と、プロセスリソース管理テーブル１６０との差分から取得できる。そしてあるリソースが所定の期間余剰リソースの状態であり続けた場合、それを不使用リソースと判定し（Ｓ１８２のＹ）、当該不使用リソースの返却を行う旨の通知をグローバルリソース管理部５６に対して行う（Ｓ１８４）。リソースがメモリ容量またはＣＰＵ時間の場合、Ｓ１８２の判定は所定量以上のリソースが所定の期間余剰リソースであり続けることを条件とし、条件を満たす場合は当該所定量を返却する。ここで所定の期間や所定量は、ソフトウェアごとにその作成段階で設定してよい。

ローカルリソース管理部４６はさらにローカルリソース管理テーブル１５０、デバイス管理テーブル２５０、またはハードディスク管理テーブル２６０のうち返却したリソースに対応する管理テーブルから返却分を削除する（Ｓ１８６）。グローバルリソース管理部５６はグローバルリソース管理テーブル１４０、ハードディスク内部管理テーブル２７０、または空き容量管理テーブル２８０のうち返却されたリソースに対応する管理テーブルを適宜更新する（Ｓ１８８）。なお、Ｓ１８０の余剰リソース監視のステップは、実行空間２０が存在する間は続けられる（Ｓ１８２のＮ）。また不使用リソースの返却がなされた後も別のリソースの監視は続行する。以上の手順により、実行空間２０に割り当てられたリソースは使用状況によっては返却され、他の実行空間に使用可能となるため、リソース割り当ての無駄が抑えられ、より効率的なリソース使用が実現できる。

これまでの説明で行われるリソース割り当て処理は、システム初期化パラメータ１０２において設定された、情報処理装置１００の起動時に生成すべき実行空間２０、およびそれに属するプロセス３２に対して行われた。以下では、システム初期化パラメータ１０２で設定した各種パラメータを、情報処理装置１００の起動後に変更する場合について説明する。具体的には実行空間２０の追加、実行するプログラムの追加、リソースの追加、およびリソースの割り当て制限の変更を行った場合について説明する。

情報処理装置１００の起動後に実行空間２０を追加する場合とは、例えばユーザがゲームを行っている最中に、ウェブブラウザを立ち上げた場合などである。このときはグローバル初期化部５２に対し、追加起動実行空間パラメータを与える。これは例えば、ユーザの入力によりウェブブラウザの実行要求を検知したグローバル初期化部５２が、外部記憶装置８０に格納されたウェブブラウザのソフトウェアのファイルから、該当パラメータをメモリ７０に読み出すことにより行われる。図２６は追加起動実行空間パラメータを記述する、追加起動実行空間パラメータテーブルの構造例を示す。追加起動実行空間パラメータテーブル３００は、図５に示したシステム初期化パラメータテーブル１０２Ａと同じ構造を有する。ただしそれぞれの欄には、追加される実行空間２０についての値のみが記述される。

グローバル初期化部５２は、読み込んだ追加起動実行空間パラメータテーブル３００に含まれる各パラメータに基づき、図３のＳ１２からＳ１８の処理、すなわち情報処理装置１００の起動時にグローバル初期化部５２が行うのと同様の処理を行う。ただし実行空間名前テーブル１３０およびグローバルリソース管理テーブル１４０は情報処理装置１００の起動時に既に作成されているため、Ｓ１６およびＳ１８のステップは、それぞれのテーブルに、追加する実行空間２０に対応する行を追加する処理となる。そして追加で起動した実行空間２０においてローカル初期化部４２は、同じく図３のＳ２０からＳ２８の処理、すなわち情報処理装置１００の起動時にローカル初期化部４２が行うのと同様の処理を行う。ただしローカルリソース管理テーブル１５０、プロセス名前テーブル１７０、およびプロセスリソース管理テーブル１６０は情報処理装置１００の起動時に既に作成されているため、Ｓ２２、Ｓ２６、およびＳ２８のステップは、それぞれのテーブルに、追加する実行空間２０に含まれるプロセス３２に対応する行を追加する処理となる。その後は、情報処理装置１００の起動時に生成された実行空間２０と同様に、そのリソース管理がなされる。

情報処理装置１００の起動後に、生成済みの実行空間２０にプロセス３２を追加する場合とは、例えばユーザがゲームを行っているときに、最初は音声なしの設定にしていたものを、途中から音声有りの設定に変更した場合などである。このときはローカル初期化部４２に対し、追加するプロセス３２のプログラムファイルを与える。これは例えば、実行空間２０を制御するＯＳによる指示やユーザの入力などにより、新たなプロセス３２の実行要求を検知したローカル初期化部４２が、外部記憶装置８０などに格納されたソフトウェアのファイルから該当するプログラムファイルをメモリ７０に読み出すことにより行われる。上記の例では、ユーザの入力により音声処理の実行要求を検知したローカル初期化部４２が、ゲームのファイルから音声処理プログラムのプログラムファイルを読み出す。プログラムファイルの構造は、図８に示したプログラム情報テーブル２２２Ａと同じである。

ローカル初期化部４２は、読み込んだプログラムファイルに基づき、図３のＳ２４からＳ２８の処理、すなわち情報処理装置１００の起動時にローカル初期化部４２が行う処理の一部と同様の処理を行う。ただし実行空間２０を追加する場合と同様、プロセス名前テーブル１７０およびプロセスリソース管理テーブル１６０には、追加するプロセス３２に対応する行を追加する。その後は、実行空間２０に元々存在したプロセス３２と同様に、リソース管理がなされる。

情報処理装置１００の起動後にリソース自体を追加する場合とは、例えばユーザがカーレースのゲームを行っているときに、最初はボタン式のコントローラを使用していたものを、途中からハンドル式のコントローラに変更した場合などである。このときはグローバル初期化部５２に対し追加リソース情報を与える。これは例えば、ユーザの入力などによりリソースの変更を検知したグローバル初期化部５２が、外部記憶装置８０などに格納されたソフトウェアのファイルから該当する情報をメモリ７０に読み出すことにより行われる。上記の例では、コントローラの変更を検知したグローバル初期化部５２が、ゲームのファイルからハンドル式コントローラの追加リソース情報を読み出す。または、リソースを追加した際に当該リソースを制御するＯＳに対しユーザが設定した情報を、リソース追加を検知したグローバル初期化部５２が読み出すことにより行われる。または、リソース追加を検知したグローバル初期化部５２が、ユーザに対して設定入力を促すことによって追加リソース情報を直接取得するようにしてもよい。

図２７は追加リソースとしてデバイス６２を追加した場合の、追加リソース情報の構造例を示している。追加デバイス情報テーブル３１０は、実行空間認証ＩＤ欄１０４Ａおよびデバイス利用可否欄３１２を含む。この例は、「０ｘ１４」なるデバイスＩＤを有するデバイス６２を追加した場合を示している。各実行空間２０が当該デバイス６２を利用できるか否かを識別する文字列が、デバイス利用可否欄３１２に記述される。本図の場合、「○」がデバイス利用可、「×」がデバイス利用不可を示している。図２８は追加リソースとしてメモリ量を追加した場合の、追加リソース情報の構造例を示している。追加メモリ量情報テーブル３２０は、実行空間認証ＩＤ欄１０４Ａおよび追加メモリ量欄３２２を含む。メモリ量を追加することによって、各実行空間２０に対する割り当てメモリ量上限を増加させることができる。追加メモリ量欄３２２には、各実行空間２０に対するメモリ量の上限の増加分が記述される。

グローバル初期化部５２は追加リソース情報テーブルに基づき、グローバルリソース管理テーブル１４０を更新する。例えばデバイス６２の追加であれば、追加デバイス情報テーブル３１０に基づき、グローバルリソース管理テーブル１４０の利用可能デバイスＩＤ欄１１２Ａに、追加したデバイス６２のデバイスＩＤを追加する。メモリ容量の追加であれば、追加メモリ量情報テーブル３２０に基づき、グローバルリソース管理テーブル１４０のメモリ量上限欄１０８Ａに増加分を加算する。同様の追加リソース情報テーブルを、各プログラムに対しても設定し、それをローカル初期化部４２が読み出すことにより、プロセスリソース管理テーブル１６０に反映させてもよい。グローバルリソース管理テーブル１４０またはプロセスリソース管理テーブル１６０の更新後は、各実行空間２０または各プロセス３２にリソースを割り当てる際、更新された各テーブルによって割り当て可否が判定される。

情報処理装置１００の起動後に、実行空間２０またはプロセス３２に対するリソース割り当て制限の変更を行う場合とは、例えばユーザがゲームを行っているときに、最初は標準的な画素数の画像表示設定だったものを、高精細画像設定に切り替えたため、割り当てるメモリ量の上限を増加させる場合などである。このときはグローバルリソース管理部５６またはローカルリソース管理部４６に対し、利用可能リソース変更情報を与える。これは例えば、ユーザの入力などにより画像品質などの設定の変更を検知したグローバル初期化部５２が、外部記憶装置８０などに格納されたソフトウェアのファイルから設定後の状況に対応する利用可能リソース変更情報をメモリ７０に読み出すことにより行われる。または、画像品質の設定変更などを行った際、ユーザに利用可能リソース変更情報の設定入力を促してもよい。または、別の実行空間２０の生成や停止を検知したシステム制御部５０が、あらかじめ設定しておいた実行空間２０ごとの優先度などに基づき利用可能リソース変更情報を自ら生成するようにしてもよい。

図２９はグローバルリソース管理部５６が取得する利用可能リソース変更情報の構造例を示す。グローバルリソース変更情報テーブル３３０は、実行空間認証ＩＤ欄１０４Ａ、メモリ量上限追加量欄３３２、ＣＰＵ時間上限追加量欄３３４、利用可能追加デバイスＩＤ欄３３６、およびハードディスク容量上限追加量欄３３８を含む。これらの欄は、図１０に示したグローバルリソース管理テーブル１４０の、実行空間認証ＩＤ欄１０４Ａ、メモリ量上限欄１０８Ａ、ＣＰＵ時間上限欄１１０Ａ、利用可能デバイスＩＤ欄１１２Ａ、およびハードディスク容量上限欄１１４Ａにそれぞれ対応する。グローバルリソース変更情報テーブル３３０には、グローバルリソース管理テーブル１４０に記述された、各実行空間２０に対するメモリ量上限、ＣＰＵ時間上限、利用可能デバイスＩＤ、およびハードディスク容量上限からの変化分が記述される。各値の先頭に「＋」または「−」を付加することにより、それぞれのリソースの追加または減縮を識別する。グローバルリソース管理部５６は、グローバルリソース変更情報テーブル３３０に基づき、グローバルリソース管理テーブル１４０を更新する。その後は、各実行空間２０にリソースを割り当てる際、更新されたグローバルリソース管理テーブル１４０によって、割り当て可否が判定される。

図３０はローカルリソース管理部４６が取得する利用可能リソース変更情報の構造例を示す。ローカルリソース変更情報テーブル３４０は、プログラム認証ＩＤ欄２２４、メモリ量上限追加量欄３４２、利用可能追加デバイスＩＤ欄３４４、およびハードディスク使用可否欄２３０を含む。これらの欄は、図１２に示したプロセスリソース管理テーブル１６０の、プログラム認証ＩＤ欄２２４、メモリ量上限欄２２６、利用可能デバイスＩＤ欄２２８、およびハードディスク使用可否欄２３０にそれぞれ対応する。ローカルリソース変更情報テーブル３４０には、プロセスリソース管理テーブル１６０に記述された、各プロセス３２に対する割り当てメモリ量上限と利用可能デバイスＩＤからの変化分、およびハードディスク使用の可否が記述される。メモリ量上限および利用可能デバイスＩＤの先頭に「＋」または「−」を付加することにより、それぞれのリソースの追加または減縮が識別される。ローカルリソース管理部４６は、ローカルリソース変更情報テーブル３４０に基づき、プロセスリソース管理テーブル１６０を更新する。その後は、各プロセス３２にリソースを割り当てる際、更新されたプロセスリソース管理テーブル１６０によって、割り当て可否が判定される。

次に実行空間認証ＩＤ１０４およびプログラム認証ＩＤの構成例について説明する。実行空間認証ＩＤ１０４およびプログラム認証ＩＤは、どちらも１６ビットから６４ビット程度の所定のデータ量を有し、それぞれ所定の複数のフィールドによって構成される。実行空間認証ＩＤ１０４は例えば、バージョン情報フィールド、機種情報フィールド、リージョンコードフィールド、実行空間ＯＳ情報フィールド、ベンダ情報フィールドなどによって構成される。バージョン情報フィールドはＩＤの体系のバージョン情報などを表す。製品情報フィールドはソフトウェアを実行する情報処理装置１００の機種などを表す。リージョンコードフィールドはソフトウェアのリージョンコードを表す。実行空間ＯＳ情報フィールドはソフトウェアの実行制御を行うため実行空間２０にて起動されるＯＳ情報などを表す。ベンダフィールドは実行主体となるソフトウェアの製造会社などを表す。機種情報フィールド、実行空間ＯＳ情報フィールド、およびベンダ情報フィールドに設定されるコードを標準化して一元管理することにより、実行空間認証ＩＤ１０４は一意的に定められる。

プログラム認証ＩＤは例えば、バージョン情報フィールド、リージョンコードフィールド、ベンダ情報フィールド、プログラム識別コードフィールドなどによって構成される。バージョン情報フィールド、リージョンコードフィールド、およびベンダ情報フィールドは実行空間認証ＩＤ１０４について上述したのと同様のフィールドである。プログラム識別コードフィールドはソフトウェアの製造会社においてプログラムを識別するためのフィールドであり、製造会社において管理される。これにより、プログラム認証ＩＤも一意的に定めることができる。

以上述べた本実施形態において、プロセス３２が行うリソースの割り当て要求は、まず同一の実行空間２０におけるローカルリソース管理部４６に対して行われる。ローカルリソース管理部４６は、図１５、図１６および図１９に示したように、まず、要求発行元のプロセス３２のプログラム認証ＩＤを取得する（Ｓ５２、Ｓ７２、およびＳ１０２）。そしてプログラム認証ＩＤに基づいて取得した割り当て制限の範囲内でのみ、リソースの割り当てを許可する（Ｓ５４、Ｓ７４のＹ、およびＳ１０４Ｙ）。したがって不正者が生成したプロセス（以下、不正プロセスと呼ぶ。）が過剰にリソース割り当てを要求しても、制限以上の割り当ては拒否されるため、正常に処理されている他のプロセス３２および他の実行空間２０には影響が及ばない。ここで不正者とはネットワーク経由の侵入、コンピュータウィルス、不正部分を含むプログラムなどの不正要因のことである。

さらに不正プロセスが実行空間２０の制御プロセス、例えばローカルリソース管理部４６に成りすましたとしても、本実施の形態の構成によれば不正プロセスによるリソースの占有などを防止でき、結果として、不正プロセスが他の実行空間２０に及ぼす悪影響を最小限に止めることができる。以下にそのメカニズムについて説明する。

まず、ある実行空間２０のローカルリソース管理部４６に成りすました不正プロセスが、グローバルリソース管理部５６にリソース割り当て要求を行った場合を考える。図１４、図１８および図２３に示したとおり、グローバルリソース管理部５６は、要求発行元の実行空間２０の実行空間認証ＩＤ１０４を取得する（Ｓ３２、Ｓ９２、およびＳ１５２）。ここで実行空間認証ＩＤ１０４は、要求受信時に自動的に識別される実行空間暫定ＩＤ１３２に基づき取得される。したがって、不正プロセスが別の実行空間２０のローカルリソース管理部４６に成りすますことはできない。そして実行空間認証ＩＤ１０４ごとにあらかじめ設定されている割り当て制限の範囲内でのみ、割り当てを許可する（Ｓ３４のＹ、Ｓ９４のＹ、またはＳ１５８のＹ）。したがって不正プロセスが過剰なリソース割り当て要求を行っても、制限範囲内でのリソース確保しかできず、正常に動作している他の実行空間２０などに対する影響が少ない。

さらに不正プロセスの動作として、他の実行空間２０のローカルリソース管理部４６に対し不正なリソース割り当て要求を行う場合が考えられる。これは、ローカルリソース管理部４６の機能、すなわち、同じ実行空間２０内のプロセス３２からの要求に対し、実行空間２０内に確保しておいたリソースを充当する機能を利用した不正が考えられるためである。そのため本実施の形態では、ローカルリソース管理部４６が、所属する実行空間２０内部の通信による要求のみを受け付けるように設定する。不正プロセスが他の実行空間２０のローカルリソース管理部４６に発行したりソース割り当て要求は、実行空間２０をまたいだ通信によるため、上述の設定によって該要求は無視される。したがって、不正プロセスが他の実行空間２０に割り当てられたリソースを横取りするのを防止することができる。

さらに不正プロセスが、デバイス６２、ハードディスク８２またはＯＳなどの低レベルの機能に直接リソース割り当ての要求を行う場合が考えられる。そのため本実施の形態では、このような低レベルに属する機能が、グローバルリソース管理部５６からの所定の通信による要求のみを受け付けるように設定を行う。例えばカーネル内部の通信による要求のみを受け付けるようにする。そして各実行空間２０内で処理されているプロセス３２は、この通信を行えないように設定しておく。これにより、低レベル機能に対する不正プロセスのリソース割り当て要求は不可能となり、不正プロセスが過剰にリソースを確保するのを防止することができる。

さらに安全性を高めるため、リソース割り当て可否の判定の根拠となるテーブルの改ざんを防止する方策を付加してもよい。具体的には、システム初期化パラメータテーブル１０２Ａ、実行空間初期化パラメータテーブル２００Ｂ、起動プログラムリストテーブル２２０Ｂ、プログラムファイル、追加起動実行空間パラメータテーブル３００、グローバルリソース変更情報テーブル３３０、ローカルリソース変更情報テーブル３４０などに対して改ざん防止策を講じる。例えばこれらのテーブルに対して電子署名またはＭＡＣ（Message Authentication Code）を施す。これにより、リソース割り当てに関する設定そのものを改ざんされることによって、不正な割り当て可否判定が行われるのを防止することができ、不正プロセスによる過剰なリソース確保に対する安全性が増す。

以上述べた本実施の形態によれば、実行空間に固有のＩＤである実行空間認証ＩＤを設定し、実行空間認証ＩＤごとにリソース割り当ての制限を設ける。これにより、不正プロセスがローカルリソース管理部など実行空間を制御するプロセスに成りすまし、リソース割り当てを要求したとしても、制限以上の割り当てを行うことがないため、他の実行空間に割り当てるべきリソースを占有されることがなくなる。また、本実施の形態では、プロセス単位および実行空間単位の２段階でリソース割り当ての可否判定を行う。実行空間ごとにリソース割り当て可否の判定を行う際、要求元の実行空間認証ＩＤは、要求の授受に使用した通信によって識別される実行空間暫定ＩＤによって自動的に判明する。したがって例えば同じプログラムが２つの実行空間で処理されていて、一方のプログラムを処理するプロセスが不正プロセスになったとしても、他方のプログラムを処理するプロセスに成りすますことはできない。たとえ不正プロセスが所属する実行空間のローカルリソース管理部に成りすましたとしても、他の実行空間のローカルリソース管理部に成りすますことはできない。結果として、不正プロセスがリソースを確保できる範囲は、最大でも所属する実行空間へのリソース割り当て上限までとなり、他の実行空間に対する影響を抑制することができる。

また本実施の形態では、メモリ量やＣＰＵ時間を各実行空間に余分に確保しておく。また一度アクセスを確立したデバイスやハードディスクのアクセッサは、プロセスによるアクセスが終了しても実行空間にそのまま確保しておく。これにより、プロセスがリソースの割り当て要求を行った際、実行空間に確保したりソースで充足すれば実行空間内部で割り当て処理が完了するため、全体として実行空間外部との通信回数が減り、かつ、割り当て要求に対応する処理の負荷を分散させることができる。結果として割り当て処理に係るオーバーヘッドを軽減することができる。一方で、所定期間、使用のなかったリソースは実行空間から返却されるため、割り当ての無駄を抑制し、効率のよいリソース利用が実現される。

さらに本実施の形態におけるリソース管理処理は、ソフトウェアファイルなどに含まれる情報を読み込むことによって自動的に実行される。また、情報処理装置の起動後にリソース関連の設定に変更が生じても、変更後の状況を表す基本的なパラメータをソフトウェアファイルなどから追加で読み込むだけで、変更前からの移行が円滑に行われる。したがってユーザは本実施の形態の処理をことさら意識せずとも、安全かつ効率的なリソース管理を臨機応変に行うことができる。

以上、本発明を実施の形態をもとに説明した。上記実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

例えば本実施の形態ではグローバル初期化部５２、グローバル名前管理部５４、グローバルリソース管理部５６の機能が、アプリケーションのプログラムを処理する実行空間２０より低レベルに属するシステム制御部５０に含まれていたが、実行空間２０と同じレベルに制御用の実行空間を発生させ、上述の機能を制御用の実行空間において実現するようにしてもよい。この場合も、本実施の形態と同様の効果を得ることができる。

また、あるゲームの専用コントローラなど、特定の実行空間のみがアクセスすることが明らかなデバイスは、不正プロセスに占有されたとしても他の実行空間への影響はない。また、他の実行空間の使用可能デバイスには含まれないため、他の実行空間の不正プロセスがこのデバイスを占有することはできない。したがって本実施の形態で説明した２段階の割り当て可否判定を行う必要がない。このような場合は、ローカルリソース管理部４６における割り当ての判定処理を省略してもよい。このときプロセス３２から割り当て要求を受け付けたローカルリソース管理部４６は、要求元のプロセス３２のプログラム認証ＩＤとともにグローバルリソース管理部５６に割り当て要求を行う。そしてグローバルリソース管理部５６が、ローカルリソース管理部４６より送られたプログラム認証ＩＤと、要求元の実行空間２０の実行空間認証ＩＤ１０４とに基づき、要求元のプロセス３２に対する割り当て可否の判定を直接行うようにしてもよい。このように、リソースの性質に応じて割り当て可否判定の階層を変化させることによって、本実施の形態と同様の安全性を確保しつつ、より効率のよい判定処理を行うことができる。

本実施の形態における情報処理装置の全体構成を示すブロック図である。 本実施の形態におけるシステム制御部と実行空間の構成を示すブロック図である。 本実施の形態における情報処理装置の起動時の処理手順を示すフローチャートである。 本実施の形態における情報処理装置のリソース割り当て処理にかかるパラメータとテーブルとの相互関係を模式的に示す図である。 本実施の形態におけるシステム初期化パラメータテーブルの構造例を示す図である。 本実施の形態における実行空間初期化パラメータテーブルの構造例を示す図である。 本実施の形態における起動プログラムリストの構造例を示す図である。 本実施の形態におけるプログラムファイルのデータ構造例を示す図である。 本実施の形態における実行空間名前テーブルの構造例を示す図である。 本実施の形態におけるグローバルリソース管理テーブルの構造例を示す図である。 本実施の形態におけるローカルリソース管理テーブルの構造例を示す図である。 本実施の形態におけるプロセスリソース管理テーブルの構造例を示す図である。 本実施の形態におけるプロセス名前テーブルの構造例を示す図である。 本実施の形態において実行空間にメモリ量またはＣＰＵ時間を割り当てる手順について示すフローチャートである。 本実施の形態においてプロセスにメモリ量またはＣＰＵ時間を割り当てる手順について示すフローチャートである。 本実施の形態においてプロセスにデバイスを割り当てる手順について示すフローチャートである。 本実施の形態におけるデバイス管理テーブルの構造例を示す図である。 本実施の形態において実行空間にデバイスを割り当てる手順について示すフローチャートである。 本実施の形態においてプロセスにハードディスクを割り当てる手順について示すフローチャートである。 本実施の形態におけるハードディスク管理テーブルの構造例を示す図である。 本実施の形態において実行空間にハードディスクのマウントを行う手順について示すフローチャートである。 本実施の形態におけるハードディスク内部管理テーブルの構造例を示す図である。 本実施の形態において実行空間にハードディスクを割り当てる手順について示すフローチャートである。 本実施の形態における空き容量管理テーブルの構造例を示す図である。 本実施の形態において実行空間に割り当てられた不使用リソースを返却する手順について示すフローチャートである。 本実施の形態における追加起動実行空間パラメータテーブルの構造例を示す図である。 本実施の形態における追加デバイス情報テーブルの構造例を示す図である。 本実施の形態における追加メモリ量情報テーブルの構造例を示す図である。 本実施の形態におけるグローバルリソース変更情報テーブルの構造例を示す図である。 本実施の形態におけるローカルリソース変更情報テーブルの構造例を示す図である。

符号の説明

１０ プロセッサ、 ２０ 実行空間、 ３０ プロセス処理部、 ３２ プロセス、 ４０ 実行空間制御部、 ４２ ローカル初期化部、 ４４ ローカル名前管理部、 ４６ ローカルリソース管理部、 ５０ システム制御部、 ５２ グローバル初期化部、 ５４ グローバル名前管理部、 ５６ グローバルリソース管理部、 ６０ 入出力装置、 ６２ デバイス、 ７０ メモリ、 ８０ 外部記憶装置、 ８２ ハードディスク、 １００ 情報処理装置 １０２ システム初期化パラメータ、 １０４ 実行空間認証ＩＤ、 １３０ 実行空間名前テーブル、 １３２ 実行空間暫定ＩＤ、 １４０ グローバルリソース管理テーブル、 １５０ ローカルリソース管理テーブル、 １６０ プロセスリソース管理テーブル、 １７０ プロセス名前テーブル、 １７２ プロセスＩＤ。

Claims (2)

1. 複数の実行空間を生成する情報処理装置であって、
   前記情報処理装置全体のリソースを管理し、前記複数の実行空間に対して前記リソースの割り当てを行う第一リソース管理部と、
   前記複数の実行空間にそれぞれ設けられ、所属する実行空間に対して前記第一リソース管理部が割り当てたリソースを管理し、所属する実行空間において処理される一以上のプロセスに対しリソースの割り当てを行う第二リソース管理部と、を備え、
   前記第二リソース管理部は、所属する実行空間において処理されるプロセスからのリソースの割り当て要求を受け付け、前記実行空間に対して割り当てられた前記リソースから当該実行空間において処理されるプロセスに割り当て済みの前記リソースを差し引いた余剰リソースにより前記要求が充足すれば、前記余剰リソースの中から前記プロセスに対して前記リソースの割り当てを行い、
   前記余剰リソースにより前記要求が充足しない場合、前記第一リソース管理部に前記リソースの追加割り当て要求を行い、前記余剰リソースと前記追加割り当て要求の結果得られた追加リソースとの中から前記プロセスに対して前記リソースの割り当てを行い、
   前記第一リソース管理部が前記実行空間に対して行うリソースの割り当てに関して、前記実行空間に対応するソフトウェアに対しあらかじめ設定された制限情報と、前記ソフトウェアに対しあらかじめ付与されている、ソフトウェア固有の固定的識別情報と、を対応づけた制限情報テーブルを記憶装置から読み出す初期処理部と、
   前記第二リソース管理部からのリソースの追加割り当て要求の信号に含まれ当該信号の授受に使用された通信によって識別される、前記第二リソース管理部の所属する前記実行空間の暫定的識別情報を、前記実行空間の固定的識別情報に変換することにより要求元実行空間の認証を行う識別情報管理部と、をさらに備え、
   前記第一リソース管理部は、前記実行空間に対して前記リソースの追加割り当てを行う際、前記識別情報管理部から取得した前記実行空間の固定的識別情報に基づき前記制限情報テーブルを参照することにより、前記制限情報に含まれる、前記リソースの割り当て可能範囲を取得し、前記割り当て可能範囲内でリソースの追加割り当てを行うことを特徴とする情報処理装置。
2. 前記第一リソース管理部は、前記実行空間に対して前記リソースの追加割り当てを行う際、前記実行空間の固定的識別情報に基づき前記制限情報テーブルを参照することにより、前記制限情報に含まれる、前記リソースの追加量の単位である追加単位を取得し、前記追加単位の自然数倍の量のリソースの追加割り当てを行うことを特徴とする請求項１に記載の情報処理装置。

Images