(57)【特許請求の範囲】
【請求項１】
プロセッサと、メモリとを有するコンピュータのメモリ管理方法であって、
オブジェクトを含む少なくとも一つのスレッドを有するプログラムが、前記コンピュータ内の前記プロセッサで実行されることにより、前記メモリに第２メモリ領域を確保し、
前記プログラムの実行に応じて第１メモリ領域に前記オブジェクトを格納し、
前記第１メモリ領域に格納された前記オブジェクトを、前記第２メモリ領域に移動し、
前記プログラムからの前記第２メモリ領域の解放指示に応じて、前記スレッドの以降の実行で必要なオブジェクトが、前記第２メモリ領域に存在するか否かを判断し、
前記判断の結果、前記スレッドの以降の実行に必要なオブジェクトが前記第２メモリ領域に存在しない場合、前記第２メモリ領域を解放し、
前記スレッドの以降の実行に必要なオブジェクトが前記第２メモリ領域に存在する場合、前記第２メモリ領域に存在する、前記スレッドの以降の実行に必要なオブジェクトを前記解放指示の対象外のメモリ領域に移動させ、前記第２メモリ領域を解放するメモリ管理方法。
【請求項２】
請求項１に記載のメモリ管理方法であって、
前記第１メモリ領域におけるガベージコレクションの発生に応じて、前記第１メモリ領域に格納された前記オブジェクトを、前記第２メモリ領域に移動するメモリ管理方法。
【請求項３】
請求項１又は２に記載のメモリ管理方法であって、前記解放指示の対象外の前記メモリ領域が、ガベージコレクションの対象であるメモリ管理方法。
【請求項４】
請求項１から３の何れか一項に記載のメモリ管理方法であって、
前記解放指示の対象外の前記メモリ領域は、前記第１メモリ領域を含むメモリ管理方法。
【請求項５】
請求項１から４の何れか一項に記載のメモリ管理方法であって、
前記スレッドの以降の実行に必要なオブジェクトは、前記解放指示の対象外の前記メモリ領域に格納されたオブジェクトから参照されるものであるメモリ管理方法。
【請求項６】
請求項１から５の何れか一項に記載のメモリ管理方法であって、
前記解放指示の対象外の前記メモリ領域に移動したオブジェクトが参照するオブジェクトが前記第２メモリ領域に存在するとき、該参照されるオブジェクトも前記解放指示の対象外の前記メモリ領域へ移動するメモリ管理方法。
【請求項７】
請求項１から６の何れか一項に記載のメモリ管理方法であって、
前記プログラムによる指示に応答して、前記第２メモリ領域に存在する前記オブジェクトを前記解放指示の対象外の前記メモリ領域に移動するメモリ管理方法。
【請求項８】
オブジェクトを含む少なくとも一つのスレッドを有するプログラムが、コンピュータ内のプロセッサにより実行されることにより前記コンピュータ内に確保される第２メモリ領域を提供するメモリと、
前記プログラムの実行に応じて前記オブジェクトが格納される第１メモリ領域と、
前記プログラムによる前記第２メモリ領域の解放指示に応答して、前記スレッドの以降の実行に必要なオブジェクトが前記第２メモリ領域に存在するか否かをチェックし、
前記チェックの結果、前記スレッドの以降の実行に必要なオブジェクトが前記第２メモリ領域に存在しないとき、前記第２メモリ領域を解放し、
前記チェックの結果、前記スレッドの以降の実行に必要なオブジェクトが前記第２メモリ領域に存在するとき、前記第２メモリ領域に存在する、前記スレッドの以降の実行に必要なオブジェクトを前記解放指示の対象外のメモリ領域へ移動し、前記第２メモリ領域を解放する前記プロセッサとを有するコンピュータ。
【請求項９】
請求項８に記載のコンピュータであって、前記プロセッサは、
前記第１メモリ領域におけるガベージコレクションの発生に応じて、前記第１メモリ領域に格納された前記オブジェクトを、前記第２メモリ領域に移動するコンピュータ。
【請求項１０】
請求項８又は９に記載のコンピュータであって、前記解放指示の対象外のメモリ領域が、ガベージコレクションの対象であるコンピュータ。
【請求項１１】
請求項８から１０の何れか一項に記載のコンピュータであって、
前記解放指示の対象外のメモリ領域は、前記第１メモリ領域を含むコンピュータ。
【請求項１２】
請求項８から１１の何れか一項に記載のコンピュータであって、
前記スレッドの以降の実行に必要なオブジェクトは、前記解放指示の対象外の前記メモリ領域に格納されたオブジェクトから参照されるものであるコンピュータ。
【請求項１３】
請求項８から１２の何れか一項に記載のコンピュータであって、前記プロセッサは、
前記解放指示の対象外の前記メモリ領域に移動したオブジェクトが参照するオブジェクトが前記第２メモリ領域に存在するとき、該参照されるオブジェクトも前記解放指示の対象外の前記メモリ領域へ移動するコンピュータ。
【請求項１４】
請求項８から１３の何れか一項に記載のコンピュータであって、前記プロセッサは、
前記プログラムによる指示に応答して、前記第２メモリ領域に存在する前記オブジェクトを前記解放指示の対象外の前記メモリ領域に移動するコンピュータ。
【請求項１５】
オブジェクトを含む少なくとも一つのスレッドを有するプログラムであって、
コンピュータに、
前記プログラムの指示に応じて第２メモリ領域を確保させる第１の手順と、
前記プログラムの実行に応じて第１メモリ領域に前記オブジェクトを格納させる第２の手順と、
前記第１メモリ領域に格納された前記オブジェクトを、前記第２メモリ領域に移動させる第３の手順と、
前記プログラムからの前記第２メモリ領域の解放指示に応じて、前記スレッドの以降の実行で必要なオブジェクトが、前記第２メモリ領域に存在するか否かを判断させる第４の手順と、
前記判断の結果、前記スレッドの以降の実行に必要なオブジェクトが前記第２メモリ領域に存在しない場合、前記第２メモリ領域を解放させる第５の手順と、
前記スレッドの以降の実行に必要なオブジェクトが前記第２メモリ領域に存在する場合、前記第２メモリ領域に存在する、前記スレッドの以降の実行に必要なオブジェクトを前記解放指示の対象外のメモリ領域に移動させ、前記第２メモリ領域を解放させる第６の手順と、を実行させるプログラム。
【請求項１６】
請求項１５に記載のプログラムであって、
前記第１メモリ領域におけるガベージコレクションの発生に応じて、前記第３の手順を実行させるプログラム。
【請求項１７】
請求項１５又は１６に記載のプログラムであって、
前記第６の手順で、ガベージコレクションの対象であり、前記解放指示の対象外の前記メモリ領域に、前記スレッドの以降の実行に必要なオブジェクトを移動させ、前記第２メモリ領域を解放させるプログラム。
【請求項１８】
請求項１５から１７の何れか一項に記載のプログラムであって、
前記第６の手順で、前記第１メモリ領域を含む、前記解放指示の対象外の前記メモリ領域に、前記スレッドの以降の実行に必要なオブジェクトを移動させ、前記第２メモリ領域を解放させるプログラム。
【請求項１９】
請求項１５から１８の何れか一項に記載のプログラムであって、
前記第４の手順で、前記第２メモリ領域以外に格納されたオブジェクトから参照されるオブジェクトを、前記スレッドの以降の実行に必要オブジェクトとして、前記第２メモリ領域に存在するか否かを判断させるプログラム。
【請求項２０】
請求項１５から１９の何れか一項に記載のプログラムであって、
前記第６の手順で、
前記解放指示の対象外の前記メモリ領域に移動させたオブジェクトが参照するオブジェクトが前記第２メモリ領域に存在するとき、該参照されるオブジェクトも前記解放指示の対象外の前記メモリ領域へ移動させ、前記第２メモリ領域を解放させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータにおけるメモリ管理方法、そのコンピュータ及びプログラムに関するものである。
【背景技術】
【０００２】
コンピュータプログラムを開発する上で、プログラムで利用するメモリ領域の確保・解放処理はプログラム開発者の手を煩わせる項目のうちの1つであり、プログラム不良を起こしやすい項目であることが知られている。例えば、一般的なプログラミング言語であるC/C++言語では、プログラムの実行で必要なメモリ領域の確保や解放処理をユーザが明示的に記述する必要があり、これに起因するプログラム不良が多発している。プログラム不良の例としては、確保したメモリ領域のデータを回収（削除）し忘れで発生するメモリリーク（プログラム作成者の意図に反して利用可能なメモリ領域が徐々に減少する現象）や、解放済みメモリ領域に対する不正な参照が挙げられる。プログラム開発者は、メモリの利用状態を常に気に留めながらプログラムを開発しなければならないが、複数人によるプログラム開発や、プログラムコードの肥大化によって、全てのメモリの確保・解放処理を完全に把握することは困難になりつつある。
【０００３】
これを解決する手段として、プログラム中でのメモリ管理を自動化するガベージコレクタの利用が挙げられる。ガベージコレクタを利用してメモリ管理する言語処理系の1つであるJava（Javaは、米国  Sun Microsystem，Inc．の商標である。）には、プログラム実行時のメモリ確保用API（Application Program Interface）は用意されているが、解放用APIは存在しない。すなわち、Javaプログラム（以下、単にプログラムと呼ぶことがある。）開発者はメモリ領域の確保は明示する必要があるが、確保したメモリ領域の解放処理は記述する必要がない。プログラム実行の過程で確保したメモリ領域は、プログラムを実行するJava仮想マシンに実装されたガベージコレクタが解放する。ガベージコレクタが実行する機能がガベージコレクション(以下、GC)である。すなわちGCとは、プログラムが動的に確保したメモリ領域のうち、不要になったデータを回収し、その領域を自動的に解放する機能である。
【０００４】
GCでは、実装方式にもよるが、基本的に全てのJavaプログラム実行スレッドを停止させて、不要なデータを回収する。Java仮想マシンがGCを起動する（GC機能を有するガベージコレクタを実行する）のは、プログラム上で生成されるデータ(オブジェクト)を格納（単に、生成と呼ぶことがある。）するJavaヒープメモリの使用量がある閾値を超えた時である。プログラム実行によるメモリ使用量をユーザが見積もるのは困難であり、この閾値を越えるタイミングを予見することも難しい。よって、この閾値を越えたことによるGCの起動をユーザが予見することも困難であるため、GCの起動によりプログラムの実行は不定期に停止することになる。さらに、Java仮想マシンにおけるGCの実装方式として採用されていることが多い世代別ガベージコレクションでは、短時間で終了するGCと、長時間の停止を要するGCが発生するが、次にどちらのGCが発生するかを予見することは困難である。長時間停止するGCが発生することを予見できれば、実行環境（Java仮想マシン）の負荷が小さいときに明示的にGCを発生させることによって、予期しない長時間停止を避けることも可能であるが、上記のようにどの程度の時間を要するGCがいつ発生するのかは、ユーザにとって不明である。
【０００５】
近年、Javaシステム（Java言語で記述したプログラムをJava仮想マシン上で実行するシステム）がサーバや、携帯電話やカー・ナビゲーション・システムのような組み込み分野で用いられるようになってきた。しかし、これらの分野で予期しないGCの起動によるプログラム停止が発生するとシステム全体の応答がなくなることが問題になっており、これを解決する方法が開発されている［非特許文献１］、［非特許文献２］。
【０００６】
GCによるプログラムの停止を避けるため、例えばリアルタイム処理に特化したJavaの仕様 Real Time Specification for Java (以下、RTSJ)では、Scoped MemoryというGC対象外の外部メモリ領域を設定できる。一連のプログラム処理で生成するデータを、GCの対象であるJavaヒープメモリ内ではなく、プログラムで明示的に確保したScoped Memory内に生成することで、Javaヒープメモリの枯渇によるGCを発生しにくくしている。一連のプログラム処理終了後はScoped Memoryに生成されたデータは不要となるが、これをGCで不要データを回収するのではなく、Scoped Memoryごと削除（データを削除して利用可能な領域として確保しておくのではなく、領域を削除してしまい、領域を使いたいときは改めて領域を確保する）する。以下、このようなメモリ領域の削除を「解放」と呼ぶ。
【０００７】
どのようなメモリ管理手法を用いるにしても、プログラムの実行に必要なデータはメモリ中に残存させなければならない。ガベージコレクタを用いたメモリ管理手法では、レジスタや実行時スタックといったルートセットと呼ばれる箇所から参照可能な全てのデータを実行に必要なデータとして扱うことで、プログラムの以降の実行に必要なデータと不要なデータを識別する。
【０００８】
一方、RTSJのようなGC対象外のメモリ領域設定によるGC回避手法を用いる場合、プログラムの実行結果が不正にならないよう、プログラミングAPIに一定の制約を課しており、実行時にこれに違反しないかどうかをチェックするオーバヘッドが発生する。ここで「一定の制約」とはScoped Memory存続のための制約や、データ間参照の制限である。RTSJにおけるScoped Memoryは、Javaプログラムで生成した1つ以上のスレッドがenterメソッドやexecuteInAreaメソッドで指示されたスコープ、すなわちある区間（プログラムの所定のステップから他の所定のステップまで）を実行中にのみ存在できるメモリ領域であり、全てのスレッドがこのスコープを抜けた場合は自動的に解放される。よって、Scoped Memoryを存続させるためには、1つ以上のスレッドがこのスコープを実行中でなければならず、テンポラリ的なデータ領域という位置づけとなっている。
【０００９】
ScopedMemoryの解放処理では、Scoped Memory内部のデータについて何も処理を行わずに解放するが、これを実現するため当該スコープ内で生成するデータに関する参照関係に制限［非特許文献１］［非特許文献２］がある。
【００１０】
図11(a)に示すメモリ領域とデータ配置を例に説明する。図11(a)は、GCの対象であるJavaヒープメモリ110上にデータ1102-1と1102-2、GCの対象外として確保されたScoped Memory1101上にデータ1103-1と1103-2がある。データ1102-1とデータ1103-2とがデータ1103-1を、またデータ1103-2がデータ1102-2を参照している様子を示している。これはRTSJとしては不正なメモリ状態である。図11(a)では、データ1102-1からデータ1103-1への参照を矢印1104で、データ1103-2からデータ1103-1への参照を矢印1105-1、データ1103-2からデータ1102-2への参照を矢印1105-2で示している。このScoped Memory1101を、内部データ1103-1、1103-2ごと解放したとすると、メモリ領域とデータの状態は図11(b)に示すようになる。
【００１１】
図11(b)に示すように、データ1102-1の参照先は既に解放された不正なメモリ領域であり、この状態でプログラムの実行を続行しても正しく動作しない。RTSJではこのような状態を防ぐため、スコープスタックというスタック的な概念を導入している。スコープスタックでは、深い位置にあるスコープで生成されたデータから浅い位置にあるスコープで生成されたデータを参照できないという制限を設け、図11(a)の参照1104のような参照をそもそも生成できないようにしている。(よって、図11(a)は不正な状態ということである。) この制限に従えば、あるScoped Memoryに対してデータを生成するスコープを実行するスレッドが1つもなくなった時点で、このScoped Memoryを解放しても、プログラムの実行には影響がないことを保証できる。
【００１２】
例えば、図11(a)において、まずJavaヒープメモリ上にデータ(1102-1と1102-2)が生成されるスコープの実行を開始したとすると、この情報がスコープスタックに格納される。その後、Scoped Memoryが生成され、1つ以上のスレッドが当該Scoped Memoryに対するenterメソッド及びexecuteInAreaメソッドで指示されたスコープの区間の実行を開始した時点で、スコープスタックにこのスコープの情報が追加された状態を仮定する。この時点でスコープスタックには、スタックの深い位置に「Javaヒープメモリにデータを生成するスコープ」という情報が格納されており、浅い位置に「Scoped Memoryにデータを生成するスコープ」という情報が格納されていることになる。
【００１３】
RTSJにおけるデータ間の参照関係に関する制限に照らすと、図11(a)のデータ1102-1からデータ1103-1に対する参照は、スコープスタック上で深い位置にあるスコープで生成されたデータから浅い位置にあるスコープで生成されたデータに対する参照であるため、これを生成することはできない。一方、図11(a)のデータ1103-2からデータ1103-1に対する参照1105-1やデータ1102-2に対する参照1105-2は、スコープスタック上で浅い位置にあるスコープで生成されたデータ同士や、深い位置にあるスコープで生成されたデータに対する参照であるため生成可能である。全スレッドがこのScoped Memoryに対してデータを生成するスコープから脱した時点で、Scoped Memory内のデータを参照することができなくなるため、本メモリ領域を解放しても、プログラムの実行に影響を与えることはない。
【先行技術文献】
【非特許文献】
【００１４】
【非特許文献１】Angelo Corsaro and Ron K. Cytron, Efficient Memory-Reference Checks for Real-time Java, Proceedings of the 2003 Conference on Languages, Compilers, and Tools for Embedded Systems, 2003.
【非特許文献２】F.Pizlo, J.M.Fox, D.Holmes and J.Vitek, Real-Time Java Scoped Memory: Design Patterns and Semantics, Proceedings of the Seventh IEEE Internal Symposium on Object-Oriented Real-Time Distributed Computing, 2004.
【発明の概要】
【発明が解決しようとする課題】
【００１５】
ガベージコレクションによってメモリ管理を行うJavaシステムのようなシステムにおいて、ガベージコレクションの対象外の、プログラムから明示的に確保可能なメモリ領域を利用できる場合に、そのメモリ領域の存続及び使用する際のデータ間の参照関係の制約事項は、このメモリ領域の利便性を著しく損ねている。つまり、プログラムから明示的に確保したメモリが存続する条件として、そのメモリ領域に対してデータを生成する区間を1つ以上のスレッドが実行中である必要があるが、この条件はプログラミングに著しい制約を課している。また、データ間の参照関係の制限のため、ユーザは常にデータ間の参照関係に留意しながらプログラミングする必要があるが、プログラム規模の肥大化や、ユーザプログラム上で記述されていない暗黙的データ生成の発生により、メモリ領域上の参照関係の完全な把握は極めて困難である。実行時のチェックにより、この制約に違反する参照関係が発生した際は、例外処理(Exception)が発生し、プログラムは正常に実行されないことがある。
【００１６】
また、上記制約事項に関する実行時チェックにより、このようなメモリ領域を使わない場合のプログラムの実行性能に対して、著しい性能低下が発生する点も問題である。
【課題を解決するための手段】
【００１７】
本発明および実施の形態の説明に際して、メモリ領域（単にメモリまたは領域とも言う。）の「解放」の意味を明らかにしておく。メモリ領域の解放とは、メモリ上の所定位置に確保された所定容量の領域またはその領域にあるデータをプログラムから認識できないようにすることである。したがって、解放後のメモリ領域へのプログラムからのアクセスは不正（アクセス）となる。メモリ領域の解放後に、新たにメモリ領域を必要とする場合は、新たにメモリ領域を生成（確保）する。このメモリ領域の解放に対して、メモリ上の所定位置に確保された所定容量の領域に格納されているデータを回収して、新たなデータの格納場所として利用可能にする場合がある。このデータの回収機能がガベージコレクションである。
【００１８】
本発明の態様の一つは、コンピュータ内のプロセッサにより実行されるプログラムによりメモリ領域を確保し、プログラムの実行に応じて確保したメモリ領域にデータを格納する。プログラムによる確保したメモリ領域の解放の指示に応答して、プログラムの以降の実行に必要なデータが解放を指示されたメモリ領域に存在するか否かをチェックする。チェックの結果、プログラムの以降の実行に必要なデータ（オブジェクト）が解放を指示されたメモリ領域に存在しないとき、解放を指示されたメモリ領域を解放するメモリ管理方法である。
【００１９】
本発明の他の態様は、メモリとプロセッサを有するコンピュータであり、次のように構成される。メモリには、ガベージコレクションによって管理される第一の領域、およびプログラムの実行に応じて、確保され、データが格納され、解放される第二の領域とを設ける。プロセッサは、プログラムの実行に伴う第二の領域の解放の指示に応答して、プログラムの以降の実行に必要なデータが第二の領域に存在するとき、そのデータを第一の領域へ移動する。
【発明の効果】
【００２０】
本発明によって、プログラムの実行に制約を与えずに、プログラムが確保したメモリ領域を解放できる。
【図面の簡単な説明】
【００２１】
【図１】実施例のコンピュータの構成例である。
【図２】外部ヒープメモリを生成、利用（データ生成）、解放するプログラム例である。
【図３】外部ヒープメモリにデータを生成、移動する例である。
【図４】外部ヒープメモリ上の不要データを回収する例である。
【図５】外部ヒープメモリ上にデータを移動させる契機を指定した例である。
【図６】外部ヒープメモリの解放の様子の例である。
【図７】外部ヒープメモリの解放処理である。
【図８】外部ヒープメモリの解放の様子の例である。
【図９】外部ヒープメモリの解放時に必要データが残存している場合に例外を発生させるよう指示する例である。
【図１０】外部ヒープメモリの解放時に必要データが残存している場合の動作を指定した場合の解放処理である。
【図１１】Scoped Memoryへのデータを生成する例である。
【発明を実施するための形態】
【００２２】
本発明を実施するための最良の形態は、プロセッサにより実行されるプログラムによりメモリ領域を確保し、プログラムの実行に応じて確保したメモリ領域にデータを格納する（オブジェクトを生成する）。プログラムによる確保したメモリ領域の解放の指示に応答して、プログラムの以降の実行に必要なデータが解放を指示されたメモリ領域に存在するか否かをチェックする。チェックの結果、プログラムの以降の実行に必要なデータ（オブジェクト）が解放を指示されたメモリ領域に存在しないとき、解放を指示されたメモリ領域を解放する。
【００２３】
チェックの結果、プログラムの以降の実行に必要なデータが解放を指示されたメモリ領域に存在するとき、そのデータを、解放を指示されたメモリ領域とは異なるメモリ領域へ移動する。プログラムの実行に必要なデータをメモリ領域とは異なるメモリ領域へ移動し、異なるメモリ領域はガベージコレクションが実行される。
【００２４】
本発明の他の態様は、メモリとプロセッサを有するコンピュータであり、次のように構成される。メモリには、ガベージコレクションによって管理される第一の領域、およびプログラムの実行に応じて、確保され、データが格納され、解放される第二の領域とを設ける。プロセッサは、プログラムの実行に伴う第二の領域の解放の指示に応答して、プログラムの以降の実行に必要なデータが第二の領域に存在するとき、そのデータを第一の領域へ移動する。これにより、プログラムの実行性能の低下を招かないコンピュータを実現できる。
【実施例１】
【００２５】
本発明に係るメモリ管理方法の一実施形態について、図面を用いて説明する。なお、本実施例はJavaシステム（Java言語で記述されたプログラムがJava仮想マシン（実行環境とも言う。）上で実行されているシステム）を対象として説明するが、ガベージコレクション機能を有する他のシステムにおいても有効である。
【００２６】
図1は、本実施例のコンピュータ101の構成を示す図である。コンピュータ101は、各処理を実行するプロセッサ（CPU）102と、プロセッサ102上でJava仮想マシン（Java VM）105が実行するJavaプログラム104、Java仮想マシン105が用いるJavaヒープメモリ110、外部ヒープメモリ111-1〜3を含むメモリ103を含んでいる。外部ヒープメモリ111はJavaプログラム104に記述された外部ヒープメモリ生成文の実行に応じて生成される。なお、Javaプログラム104はメモリ103上ではなく、外部記憶装置112に格納されていることもある。
【００２７】
Javaプログラム104には、所要の処理に加えて、外部ヒープメモリを生成、外部ヒープメモリへのデータの格納（オブジェクトの生成）、外部ヒープメモリの解放といった記述がなされており、これをJava仮想マシン105が実行することで、外部ヒープメモリ111が生成され、利用され、解放される。一方、Javaヒープメモリ110はJava仮想マシン105によって、ガベージコレクション等のメモリ管理がなされ、Javaプログラム104からはメモリ管理できない。
【００２８】
Javaプログラム104を実行するため、Java仮想マシン105はプログラム読込み部106でJavaプログラム104を読み込み、外部ヒープメモリ111を生成する文を実行した際には外部ヒープ生成部107で外部ヒープメモリ111を生成し、Javaプログラム104に記述された外部ヒープメモリ111へのデータ生成区間（所定のステップから他の所定のステップ）において、外部ヒープメモリ111へのデータ生成部によって外部ヒープメモリ111内にデータを生成する。また、Javaプログラム104上で外部ヒープメモリ111の解放が明示的に指示された場合は、外部ヒープ解放部109において、実行に必要なデータのうち外部ヒープメモリ111上にあるデータを解放対象外メモリ領域に移動させてから外部ヒープメモリ111を解放する。
【００２９】
外部ヒープメモリ111を生成、外部ヒープメモリ111へのデータ生成、外部ヒープメモリ111の解放のための記述を含んだJavaプログラム104の例を図2に示す。図2における、各行左の数値は行番号であり、実際のプログラムには記述されていない。2行目の文201は、外部ヒープメモリ111を生成（確保）する記述であり、4行目のenterメソッドから6行目のexitメソッドまでの処理202において生成したデータは、外部メモリ111上に直接生成（格納）されるか、最初はJavaヒープメモリ110上に生成し、8行目の文204にあるcommitChangesメソッドで外部メモリ111に明示的に移動させることも可能である。ここでは、区間が4行目から6行目である。この区間の処理202中で直接外部ヒープメモリ111中にデータを生成すると、処理202中でデータの全てを外部ヒープメモリ111に生成してしまうので、すぐに不要となるデータも外部ヒープメモリ111に生成されてしまい、外部ヒープメモリ111のメモリ領域の利用効率が悪くなる。これに対して、Javaヒープメモリ110にデータを生成した上で、必要なデータを外部ヒープメモリ111に移動することで、メモリ領域の利用効率の悪化に対する対策となる。
【００３０】
プログラム上で外部ヒープメモリ111へのデータの移動を指示するcommitChangesメソッドは、引数に移動対象メモリのインスタンスを指定するだけでなく、移動するデータを明示することも可能である。図2の例では、移動対象の外部ヒープメモリemが指定されているだけであるので、ヒープメモリemへの移動対象となっているデータの全てを移動する。ちなみに、その他の部分（202の区間外）で生成されたデータはJavaヒープメモリ110上に生成される。図2中9行目に示すように、外部ヒープメモリ111上に生成されたデータを任意の処理で利用した後、外部ヒープメモリ111上のデータが不要となった際には、図2中11行目の文203のように外部ヒープメモリemの解放を指示する。なお、図2中9行目の任意の処理における外部ヒープメモリemの利用にあたっては、プログラム上の制限や実行時の参照関係の調査は存在しない。
【００３１】
図3、図4、および図5に他のプログラム例を示す。図3は、enter/exitメソッドで外部ヒープメモリ111へのデータ生成を指示するのではなく、4行目の文301に示すように既存のデータ（オブジェクト）を外部ヒープメモリemに移動させるmoveObjectメソッドや、6行目の文302に示すように生成するデータのクラスを指定して外部ヒープメモリem内に直接データを生成するnewInstanceメソッドを用いて、外部ヒープメモリemを利用している。
【００３２】
また、図4の文401に示すように、外部ヒープメモリemの不要データ（オブジェクト）の回収を指示するcompactメソッドを実行し、外部ヒープメモリemの空き領域を増やすこともできる。
【００３３】
図4の12行目に示す任意の処理で外部ヒープメモリemにさらにデータを移動させるような場合には、あらかじめ11行目の文401に示すcompactメソッドを実行することによって、移動可能なデータ量を増やすことができる。
【００３４】
図5は、commitChangesメソッドでデータの移動を明示するのではなく、enterメソッドの引数としてCommitMode.MOVE_ON_GCを与えることによって、処理501内で生成されたデータは、Javaヒープメモリ110でのGCの発生を契機として、外部ヒープメモリemに移動する例である。Javaヒープメモリ110でのGCで、プログラムの以降の実行に必要なデータと判断されたデータで、かつ処理501内で生成されたデータが外部ヒープメモリemに移動するため、不要なデータが移動しにくく、外部メモリ領域emを有効に利用することができる。
【００３５】
外部ヒープメモリ111の解放処理は、図1の外部ヒープ解放部109で実行される。この際、外部ヒープメモリ111上にあるデータがJavaプログラム104の実行に必要である場合を考慮しなければならない。例えば、図6(a)のようなメモリ103上のデータ配置である。図6(a)は、Javaヒープメモリ110上にデータ601-1と601-2、外部ヒープメモリ111上にデータ602-1と602-2があり、データ601-1とデータ602-2がデータ602-1を、またデータ602-2がデータ601-2を参照している様子を示している。図6(a)では、データ601-1からデータ602-1への参照を矢印603で、データ602-2からデータ602-1への参照を矢印604-1、データ602-2からデータ601-2への参照を矢印604-2で示している。この状態から外部メモリ111を解放すると、このメモリ上のデータ602-1と602-2を削除したことになり、データ602-2からの参照である604-1及び604-2がなくなってもJavaプログラム104の実行に問題は生じない。しかし、参照603については図6(b)に示すようにデータ601-1が参照するデータが不正なメモリ領域を参照することになり、Javaプログラム104は正しく動作しない。
【００３６】
このような場合には、Javaプログラム104の処理を続行できないという例外処理（プログラムに本来想定されていなかったエラーが発生した際に、エラーに対応して実行される処理）を実行する方法もあるが、Javaプログラム104を正常に続行させたい場合は、解放対象である外部ヒープメモリ111の解放前にデータ602-1を解放対象ではないJavaヒープメモリ110上に移動させ、データ間の参照関係を修正することによって、外部ヒープメモリ111を解放後も正しくJavaプログラム104の実行を続けることができる。
【００３７】
Javaプログラム104の正常な実行を保証する処理を含む外部ヒープ解放部109の処理を図7に示す。処理701において、解放対象外のメモリ領域のデータから解放対象メモリ領域のデータへの参照の有無を調査する。処理702においてその有無を判断し、参照がある場合は処理703において、その参照先データを解放対象外メモリに移動させる。その際、移動したデータへの移動元に対する他のデータからの参照を移動先に修正する。処理704において、処理703で移動させたデータが参照するデータを調べ、処理705においてその参照先データが解放対象メモリ内かどうかを判断し、解放対象メモリ内である場合は対象データをその参照先データとして処理703から実行する。逆に、解放対象メモリ外を参照している場合は処理701に戻り、解放対象メモリ領域のデータへの参照の調査を続ける。
【００３８】
全ての解放対象外メモリ領域のデータに対して処理701を適用しても、解放対象メモリのデータへの参照が見つからない場合は、処理702から処理706に進み、対象メモリを解放する。ここで、解放対象メモリ領域は複数であってもよく、その場合は処理701〜705を実行後、処理706で一度に複数の領域を解放する。処理701で調べる解放対象外メモリのデータから解放対象メモリのデータへの参照関係は、GCにおいてプログラムの実行に必要なデータを検出するためにGCルートと呼ばれる場所から指されるデータからたどるデータ間参照関係の一部である可能性がある。よって、この参照関係で参照可能なデータを解放対象外メモリ領域に移動させておけば、GCにおいて実行に必要と判断されるデータは少なくとも移動していることが保証されるため、解放対象メモリの解放後もプログラムの実行を安全に続行することができる。
【００３９】
図7に示す解放処理を図8(a)に適用すると、まず解放対象外メモリ（Javaヒープ）110上のデータ801-1から解放対象メモリ（外部ヒープ）111上のデータ802-1への参照803が見つかる。よって、処理703においてデータ802-1を解放対象外メモリ110上に移動させてデータ806とし、データ801-1からの参照803を参照807に示すように修正する。データ802-1がデータ806となることにより、参照808が新たに生じる。本処理703後のメモリ上のデータ配置を示したのが図8(b)である。
【００４０】
次に、処理703において移動させたデータの移動元データ802-1から参照するデータを処理704において調べると、参照804をたどることでデータ802-2の存在がわかる。処理705において、データ802-2の所在を確認すると解放対象メモリ111内であることが分かるため、対象データを802-2に変更して処理703を実行する。図8(c)は2回目の処理703の処理後の様子であり、データ802-2が移動してデータ809となり、図8(b)におけるデータ806からデータ802-2への参照808が、参照810として修正されている。また、図8(b)におけるデータ802-2からデータ801-2への参照805は、データ802-2が移動して809となったことによって、参照811となる。
【００４１】
図8(c)の状態で、再度処理704及び705を実行するが、データ802-2から参照するデータ801-2は解放対象外メモリ110にあるため、処理701に戻る。2回目の処理701では解放対象メモリへの参照は発見できないため、処理702から処理706に進み、外部ヒープメモリ111を解放する。図8(c)より、外部ヒープメモリ111に対する参照は存在しないため、このメモリ領域111を解放してもプログラムの実行において問題は生じない。また、データ802-2からデータ801-2への参照を表す805については、参照元データ802-2が解放対象外メモリ上のデータから参照されないため、その存在がJavaプログラムのその後の実行に影響を及ぼすことはない。
【００４２】
プログラムによって明示的に確保されたメモリ領域の解放処理において、解放対象メモリ内に実行に必要なデータがある場合に、実行に必要なデータを移動させるのではなく、例外処理を実行することもできる。この場合、実行に必要なデータが残存していることを発見した時点で必ず例外処理を実行させることもできるし、領域解放を明示するreclaimメソッドの実行時の動作を図9の文901中のsetReclamationActionメソッドのように指定することもできる。文901では、領域解放時に実行に必要なデータが解放領域内に残存している場合は例外を発生させるという指示である。なお、setReclamationActionメソッドの引数には、例外を発生させる「EXCEPTION」の他に、実行に必要なデータをJavaヒープメモリに移動させる「MOVE_TO_JAVA_HEAP」を記述することができる。
【００４３】
setReclamationActionを利用可能な場合の領域解放処理を図10に示す。処理701で解放対象外メモリ領域内のデータから解放対象メモリ領域内のデータへの参照の有無を調べ、存在する場合は処理702より処理1001に移る。処理1001では、setReclamationActionメソッドでセットされた処理を調べ、EXCEPTIONが指定されていた場合は処理1002において例外を発行し、そうでない場合、つまりJavaヒープメモリ110に必要データを移動させるよう指示されていた場合は図7の処理703に移行する。参照が存在しない場合は処理706で解放対象メモリは解放される。
【００４４】
以上の処理により、Javaプログラム上での記述の制限なく、外部ヒープメモリ111の生成、利用、および解放を安全に実行できる。
【符号の説明】
【００４５】
１０１…コンピュータ、１０２…プロセッサ、１０３…メモリ、１０４…Ｊａｖａプログラム、１０５…Ｊａｖａ仮想マシン、１０６…Ｊａｖａプログラム読込み部、１０７…外部ヒープ生成部、１０８…外部ヒープへのデータ生成部、１０９…外部ヒープ解放部、１１０…Ｊａｖａヒープメモリ、１１１…外部ヒープメモリ、１１２…外部記憶装置。
【図１】
0005564540.tif 000002
【図２】
0005564540.tif 000003
【図３】
0005564540.tif 000004
【図４】
0005564540.tif 000005
【図５】
0005564540.tif 000006
【図６】
0005564540.tif 000007
【図７】
0005564540.tif 000008
【図８】
0005564540.tif 000009
【図９】
0005564540.tif 000010
【図１０】
0005564540.tif 000011
【図１１】
0005564540.tif 000012