JP5064134B2 - メモリ管理方法およびその方法を用いるコンピュータ - Google Patents

Description

本発明は、コンピュータにおけるメモリ管理方法およびそのコンピュータに関するものである。

コンピュータプログラムを開発する上で、プログラムで利用するメモリ領域の確保・解放処理はプログラム開発者の手を煩わせる項目のうちの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)が発生し、プログラムは正常に実行されないことがある。

また、上記制約事項に関する実行時チェックにより、このようなメモリ領域を使わない場合のプログラムの実行性能に対して、著しい性能低下が発生する点も問題である。

本発明および実施の形態の説明に際して、メモリ領域（単にメモリまたは領域とも言う。）の「解放」の意味を明らかにしておく。メモリ領域の解放とは、メモリ上の所定位置に確保された所定容量の領域またはその領域にあるデータをプログラムから認識できないようにすることである。したがって、解放後のメモリ領域へのプログラムからのアクセスは不正（アクセス）となる。メモリ領域の解放後に、新たにメモリ領域を必要とする場合は、新たにメモリ領域を生成（確保）する。このメモリ領域の解放に対して、メモリ上の所定位置に確保された所定容量の領域に格納されているデータを回収して、新たなデータの格納場所として利用可能にする場合がある。このデータの回収機能がガベージコレクションである。

本発明の態様の一つは、コンピュータ内のプロセッサにより実行されるプログラムによりメモリ領域を確保し、プログラムの実行に応じて確保したメモリ領域にデータを格納する。プログラムによる確保したメモリ領域の解放の指示に応答して、プログラムの以降の実行に必要なデータが解放を指示されたメモリ領域に存在するか否かをチェックする。チェックの結果、プログラムの以降の実行に必要なデータ（オブジェクト）が解放を指示されたメモリ領域に存在しないとき、解放を指示されたメモリ領域を解放するメモリ管理方法である。

本発明の他の態様は、メモリとプロセッサを有するコンピュータであり、次のように構成される。メモリには、ガベージコレクションによって管理される第一の領域、およびプログラムの実行に応じて、確保され、データが格納され、解放される第二の領域とを設ける。プロセッサは、プログラムの実行に伴う第二の領域の解放の指示に応答して、プログラムの以降の実行に必要なデータが第二の領域に存在するとき、そのデータを第一の領域へ移動する。

本発明によって、プログラムの実行に制約を与えずに、プログラムが確保したメモリ領域を解放できる。

本発明を実施するための最良の形態は、プロセッサにより実行されるプログラムによりメモリ領域を確保し、プログラムの実行に応じて確保したメモリ領域にデータを格納する（オブジェクトを生成する）。プログラムによる確保したメモリ領域の解放の指示に応答して、プログラムの以降の実行に必要なデータが解放を指示されたメモリ領域に存在するか否かをチェックする。チェックの結果、プログラムの以降の実行に必要なデータ（オブジェクト）が解放を指示されたメモリ領域に存在しないとき、解放を指示されたメモリ領域を解放する。

チェックの結果、プログラムの以降の実行に必要なデータが解放を指示されたメモリ領域に存在するとき、そのデータを、解放を指示されたメモリ領域とは異なるメモリ領域へ移動する。プログラムの実行に必要なデータをメモリ領域とは異なるメモリ領域へ移動し、異なるメモリ領域はガベージコレクションが実行される。

本発明の他の態様は、メモリとプロセッサを有するコンピュータであり、次のように構成される。メモリには、ガベージコレクションによって管理される第一の領域、およびプログラムの実行に応じて、確保され、データが格納され、解放される第二の領域とを設ける。プロセッサは、プログラムの実行に伴う第二の領域の解放の指示に応答して、プログラムの以降の実行に必要なデータが第二の領域に存在するとき、そのデータを第一の領域へ移動する。これにより、プログラムの実行性能の低下を招かないコンピュータを実現できる。

本発明に係るメモリ管理方法の一実施形態について、図面を用いて説明する。なお、本実施例は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の生成、利用、および解放を安全に実行できる。

実施例のコンピュータの構成例である。 外部ヒープメモリを生成、利用（データ生成）、解放するプログラム例である。 外部ヒープメモリにデータを生成、移動する例である。 外部ヒープメモリ上の不要データを回収する例である。 外部ヒープメモリ上にデータを移動させる契機を指定した例である。 外部ヒープメモリの解放の様子の例である。 外部ヒープメモリの解放処理である。 外部ヒープメモリの解放の様子の例である。 外部ヒープメモリの解放時に必要データが残存している場合に例外を発生させるよう指示する例である。 外部ヒープメモリの解放時に必要データが残存している場合の動作を指定した場合の解放処理である。 Scoped Memoryへのデータを生成する例である。

符号の説明

101…コンピュータ、102…プロセッサ、103…メモリ、104…Javaプログラム、105…Java仮想マシン、106…Javaプログラム読込み部、107…外部ヒープ生成部、108…外部ヒープへのデータ生成部、109…外部ヒープ解放部、110…Javaヒープメモリ、111…外部ヒープメモリ、112…外部記憶装置。

Claims (27)

1. オブジェクトを含む少なくとも一つのスレッドを有するプログラムが、コンピュータ内のプロセッサにより実行されることにより前記コンピュータ内にメモリ領域を確保し、
   前記プログラムの実行に応じて前記メモリ領域に前記オブジェクトを格納し、
   前記プログラムによる前記メモリ領域の解放の指示に応答して、前記少なくとも一つのスレッドの以降の実行に必要なオブジェクトが前記解放を指示された前記メモリ領域に存在するか否かをチェックし、
   前記チェックの結果、前記少なくとも一つのスレッドの以降の実行に必要なオブジェクトが前記メモリ領域に存在しないとき、前記解放を指示されたメモリ領域を解放し、
   前記チェックの結果、前記少なくとも一つのスレッドの以降の実行に必要なオブジェクトが前記メモリ領域に存在するとき、前記オブジェクトを前記解放が指示されたメモリ領域とは異なるメモリ領域へ移動するメモリ管理方法。
2. 請求項１のメモリ管理方法において、前記チェックの結果、前記少なくとも一つのスレッドの以降の実行に必要なオブジェクトが前記メモリ領域に存在するとき、前記プログラムにより指示された動作を実行するメモリ管理方法。
3. 請求項２のメモリ管理方法において、前記指示された動作の実行は例外処理の実行であるメモリ管理方法。
4. 請求項１〜３のいずれか一項に記載のメモリ管理方法において、前記異なるメモリ領域はガベージコレクションの対象であるメモリ管理方法。
5. 請求項４に記載のメモリ管理方法において、
   前記異なるメモリ領域のガベージコレクションの発生に応じて、前記オブジェクトを前記解放が指示されたメモリ領域とは異なるメモリ領域へ移動するメモリ管理方法。
6. 請求項１から５のいずれか一項に記載のメモリ管理方法において、前記少なくとも一つのスレッドの以降の実行に必要なオブジェクトは前記解放を指示されたメモリ領域外のオブジェクトから参照されているオブジェクトであるメモリ管理方法。
7. 請求項１から６のいずれか一項に記載のメモリ管理方法において、前記移動したオブジェクトが参照するオブジェクトが前記メモリ領域に存在するとき、該参照されるオブジェクトも前記異なるメモリ領域へ移動するメモリ管理方法。
8. 請求項１から７のいずれか一項に記載のメモリ管理方法において、前記プログラムによる指示に応答して、前記オブジェクトを前記メモリ領域とは異なるメモリ領域へ移動するメモリ管理方法。
9. 請求項１〜８の何れか一項に記載のメモリ管理方法において、
   前記メモリ領域及び前記異なるメモリ領域の少なくとも一方が、不揮発性記録媒体に設けられるメモリ管理方法。
10. オブジェクトを含む少なくとも一つのスレッドを有するプログラムが、コンピュータ内のプロセッサにより実行されることにより前記コンピュータ内に確保されたメモリ領域と、
    前記メモリ領域とは異なるメモリ領域と、
    前記プログラムの実行に応じて前記メモリ領域に前記オブジェクトを格納し、
    前記プログラムによる前記メモリ領域の解放の指示に応答して、前記少なくとも一つのスレッドの以降の実行に必要なオブジェクトが前記解放を指示された前記メモリ領域に存在するか否かをチェックし、
    前記チェックの結果、前記少なくとも一つのスレッドの以降の実行に必要なオブジェクトが前記メモリ領域に存在しないとき、前記解放を指示されたメモリ領域を解放し、
    前記チェックの結果、前記少なくとも一つのスレッドの以降の実行に必要なオブジェクトが前記メモリ領域に存在するとき、前記オブジェクトを前記解放が指示されたメモリ領域とは異なるメモリ領域へ移動する制御部とを有するコンピュータ。
11. 請求項１０に記載のコンピュータにおいて、前記制御部が、前記チェックの結果、前記少なくとも一つのスレッドの以降の実行に必要なオブジェクトが前記メモリ領域に存在するとき、前記プログラムにより指示された動作を実行するコンピュータ。
12. 請求項１１に記載のコンピュータにおいて、前記指示された動作の実行は例外処理の実行であるコンピュータ。
13. 請求項１０〜１２のいずれか一項に記載のコンピュータにおいて、前記異なるメモリ領域はガベージコレクションの対象であるコンピュータ。
14. 請求項１３に記載のコンピュータにおいて、
    前記制御部が、
    前記異なるメモリ領域のガベージコレクションの発生に応じて、前記オブジェクトを前記解放が指示されたメモリ領域とは異なるメモリ領域に移動するコンピュータ。
15. 請求項１０から１４のいずれか一項に記載のコンピュータにおいて、前記少なくとも一つのスレッドの以降の実行に必要なオブジェクトが、前記解放を指示されたメモリ領域外のオブジェクトから参照されているオブジェクトであるコンピュータ。
16. 請求項１０から１５のいずれか一項に記載のコンピュータにおいて、
    前記制御部が、
    前記移動したオブジェクトが参照するオブジェクトが前記メモリ領域に存在するとき、該参照されるオブジェクトも前記異なるメモリ領域へ移動するコンピュータ。
17. 請求項１０から１６のいずれか一項に記載のコンピュータにおいて、
    前記制御部が、
    前記プログラムによる指示に応答して、前記オブジェクトを前記メモリ領域とは異なるメモリ領域へ移動するコンピュータ。
18. 請求項１０〜１９の何れか一項に記載のコンピュータにおいて、
    前記メモリ領域及び前記異なるメモリ領域の少なくとも一方が、不揮発性記録媒体に設けられるコンピュータ。
19. オブジェクトを含む少なくとも一つのスレッドを有するプログラムであって、
    コンピュータに、
    前記プログラムの指示に応じてメモリ領域を確保する手順と、
    前記プログラムの実行に応じて前記メモリ領域に前記オブジェクトを格納する手順と、
    前記プログラムによる前記メモリ領域の解放の指示に応答して、前記少なくとも一つのスレッドの以降の実行に必要なオブジェクトが前記解放を指示された前記メモリ領域に存在するか否かをチェックする手順と、
    前記チェックの結果、前記少なくとも一つのスレッドの以降の実行に必要なオブジェクトが前記メモリ領域に存在しないとき、前記解放を指示されたメモリ領域を解放する手順と、
    前記チェックの結果、前記少なくとも一つのスレッドの以降の実行に必要なオブジェクトが前記メモリ領域に存在するとき、前記オブジェクトを前記解放が指示されたメモリ領域とは異なるメモリ領域へ移動する手順とを実行させるプログラム。
20. 請求項１９のプログラムにおいて、
    前記チェックする手順の結果、前記少なくとも一つのスレッドの以降の実行に必要なオブジェクトが前記メモリ領域に存在するとき、前記プログラムにより指示された動作を実行する手順を実行させるプログラム。
21. 請求項２０に記載のプログラムにおいて、
    前記指示された動作の実行は例外処理の実行であるプログラム。
22. 請求項１９〜２１のいずれか一項に記載のプログラムにおいて、
    前記チェックの結果、前記少なくとも一つのスレッドの以降の実行に必要なオブジェクトが前記メモリ領域に存在するとき、ガベージコレクションの対象であって、前記解放が指示されたメモリ領域とは異なるメモリ領域に、前記オブジェクトを移動する手順を実行させるプログラム。
23. 請求項２２に記載のプログラムにおいて、
    前記異なるメモリ領域のガベージコレクションの発生に応じて、前記オブジェクトを前記解放が指示されたメモリ領域とは異なるメモリ領域へ移動させる手順を実行させるプログラム。
24. 請求項１９から２３のいずれか一項に記載のプログラムにおいて、前記少なくとも一つのスレッドの以降の実行に必要なオブジェクトには、前記解放を指示されたメモリ領域外のオブジェクトから参照されているオブジェクトが含まれるプログラム。
25. 請求項１９から２３のいずれか一項に記載のプログラムにおいて、前記移動したオブジェクトが参照するオブジェクトが前記メモリ領域に存在するとき、該参照されるオブジェクトも前記異なるメモリ領域へ移動する手順を実行させるプログラム。
26. 請求項１９から２３のいずれか一項に記載のプログラムにおいて、前記少なくとも一つのスレッドを有するプログラムによる指示に応答して、前記オブジェクトを前記メモリ領域とは異なるメモリ領域へ移動する手順を実行させるプログラム。
27. 請求項１９〜２３の何れか一項に記載のプログラムにおいて、
    前記メモリ領域及び前記異なるメモリ領域の少なくとも一方を、不揮発性記録媒体に確保する手順を実行させるプログラム。

Images