JP5281452B2 - メモリ管理方法、コンピュータ、及び、メモリ管理プログラム - Google Patents

メモリ管理方法、コンピュータ、及び、メモリ管理プログラム Download PDF

Info

Publication number
JP5281452B2
JP5281452B2 JP2009073646A JP2009073646A JP5281452B2 JP 5281452 B2 JP5281452 B2 JP 5281452B2 JP 2009073646 A JP2009073646 A JP 2009073646A JP 2009073646 A JP2009073646 A JP 2009073646A JP 5281452 B2 JP5281452 B2 JP 5281452B2
Authority
JP
Japan
Prior art keywords
data
memory
target
management method
heap memory
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2009073646A
Other languages
English (en)
Other versions
JP2010225033A (ja
JP2010225033A5 (ja
Inventor
元樹 小幡
博泰 西山
昌彦 足立
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2009073646A priority Critical patent/JP5281452B2/ja
Priority to US12/607,622 priority patent/US8898404B2/en
Publication of JP2010225033A publication Critical patent/JP2010225033A/ja
Publication of JP2010225033A5 publication Critical patent/JP2010225033A5/ja
Application granted granted Critical
Publication of JP5281452B2 publication Critical patent/JP5281452B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02Addressing or allocation; Relocation
    • G06F12/0223User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/023Free address space management
    • G06F12/0253Garbage collection, i.e. reclamation of unreferenced memory
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02Addressing or allocation; Relocation
    • G06F12/08Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Memory System (AREA)
  • Devices For Executing Special Programs (AREA)

Description

本発明は、コンピュータプログラムにおけるメモリ管理の技術に関する。
コンピュータプログラムを開発する上で、プログラム実行時に利用するメモリ領域の確保・解放処理は、プログラム開発者の手を煩わせる項目のうちの1つであり、プログラム(動作)不良を起こしやすい項目であることが知られている。例えば、一般的なプログラミング言語であるC/C++言語では、プログラムの実行に必要なメモリ領域の確保や解放処理をユーザが明示的に記述する必要があり、これに起因するプログラム不良が多発している。
プログラム不良の例としては、確保したメモリ領域の解放し忘れで発生するメモリリークや、解放済みメモリ領域に対する不正な参照(参照先に本来参照すべきデータが存在しないこと )が挙げられる。プログラム開発者は、メモリの利用状態を常に気に留めながらプログラムを開発しなければならないが、複数人でのプログラム開発や、プログラムコードの肥大化によって、全てのメモリの確保・解放処理を正確に記述するのは困難になりつつある。
これを解決する手段として、プログラム中でのメモリ管理を自動化するガベージコレクタの利用が挙げられる。ガベージコレクタを利用したメモリ管理を行う言語処理系の1つであるJava(登録商標)には、プログラム実行時のメモリ確保用API(Application Program Interface)は用意されているが、解放用APIは存在しない。プログラム実行の過程で確保したメモリ領域の解放は、Javaプログラムを実行するJava仮想マシンに実装されたガベージコレクタが行っている。そして、ガベージコレクタが実行するガベージコレクション(以下、「GC」ともいう。)では、全てのJavaプログラム実行スレッドを停止させて、不要なデータを回収する実装形態をとることが多い。
Java仮想マシンがGCを起動するのは、Javaプログラム上で生成されるデータ(Javaオブジェクト)を格納するJavaヒープメモリの使用量がある閾値を超える直前であるが、プログラム実行によるメモリ使用量をユーザが見積もるのは困難であり、この閾値を越えるタイミングを予見することも難しい。よって、この閾値を越えたことによるGCの起動をユーザが予見することも困難であるため、実行中のプログラムは不定期に停止することになる。
さらに、Java仮想マシンにおけるGCの実装方式として採用されていることが多い世代別ガベージコレクションでは、停止が短時間で済むGCと、長時間の停止を要するGCが発生するが、次にどちらのGCが発生するかを予見することは困難である。近年、Javaシステムがサーバサイドや組み込み分野(産業機器や家電製品など)で用いられるようになってきたが、予期しないGCによる長時間のプログラム停止が発生するとシステム全体の応答がなくなることが問題視されるようになってきている。
本問題を解決する方法が、例えば、非特許文献1,2に開示されている。これらの非特許文献1,2に開示されている方法では、Java仮想マシンによるGCの対象であるヒープメモリ(以下、「Javaヒープメモリ」という。)の他に、GCの対象外であるヒープメモリ(以下、「外部ヒープメモリ」という。)を有する。外部ヒープメモリとは、プログラムによりメモリ管理が可能なメモリ領域である。すなわち、外部ヒープメモリの確保、オブジェクトの生成及び外部ヒープメモリの解放は、プログラマによるプログラムのソースコード中への記述に従う。
非特許文献1の開示技術における外部ヒープメモリ領域の解放処理では、そのメモリ領域を低オーバヘッドで解放するために、確保したメモリ領域に生成するデータの参照関係に制限を設けている。この制限は、外部ヒープメモリにおいてデータを生成するスレッドが1つもなくなった時点で、このメモリ領域をデータごと解放しても、プログラムの実行には影響がないことを保証するためのものである。このように、プログラムによりメモリ領域管理が可能な領域、すなわちJava仮想マシンによるGCの対象外である外部ヒープメモリを用い、データの参照関係に制限を設けることにより、Javaプログラム実行スレッドの長時間停止の発生を抑制しているが、この制約事項は外部ヒープメモリの利便性を著しく損ねている。
また、データ間の参照関係の制限のため、ユーザは常にデータ間の参照関係に留意しながらプログラミングを行う必要があるが、プログラム規模の肥大化や、ユーザプログラム上で記述されていない暗黙的データ生成(ユーザが記述していないプログラムによるデータ生成 )の発生により、メモリ上の参照関係の完全な把握は極めて困難であると言える。また、上記制約事項に関する実行時のチェックにより、この制約に違反する参照関係が発生した際は、「例外処理(Exception)」が発生し、プログラムは正常に実行されないことが多い上、本チェック処理により外部ヒープメモリを使わない場合のプログラムの実行性能と比較して、著しい性能低下が発生する点も問題である。
このような問題に対処するために、非特許文献2の開示技術では、オブジェクト間の参照関係に制限を設けずに、外部ヒープメモリ領域を利用できるようにしている。非特許文献1の開示技術における参照関係の制約事項は、外部ヒープメモリ領域の解放を安全に行うためである。一方、非特許文献2の開示技術では、外部ヒープメモリ領域を解放する際、解放対象メモリ領域内のデータと解放対象外メモリ領域のデータとの参照関係を調査し、解放対象メモリ領域における後の実行に必要なデータを解放対象外メモリに移動させる。これによって、その解放対象メモリ領域の解放がプログラムの実行に支障をきたさないことを保証した上で、解放対象メモリ領域を解放する。これにより、データ間の参照関係を気にすることなく外部ヒープメモリ用APIを利用できる他、参照関係の調査はメモリ領域解放時のみとなるため、実行時チェックのオーバヘッドも生じない。
図13は、外部ヒープメモリをAPIで利用する場合のプログラムを示す図である。図13に示すプログラムは、Listクラスのデータを生成し、このデータからObjクラスのデータo1、o2を参照可能とする例である。元のプログラムでは、Listクラスのデータ生成はコメントアウトされている行1301で示す実行文にあるようにnew演算子を用いるが、外部ヒープメモリを利用するために、行1302及び行1303で示すような実行文に変更している。
行1302は外部ヒープメモリの生成指示の実行文であり、ここでは、ReferenceExplicitMemoryクラスのデータを生成すると共にGC対象外である外部ヒープメモリを生成する。そして、次の行1303で示す実行文において、生成した外部ヒープメモリに対してListクラスのデータを生成している。また、生成した外部ヒープメモリの解放(削除)の指示の実行文を行1304で示す。行1304で示す実行文が実行されると、行1302で示す実行文によって生成した外部ヒープメモリが解放される。その際、外部ヒープメモリ内データに対して、解放対象の外部ヒープメモリ以外の領域からの参照がある場合、参照されているデータ群を解放対象外のメモリに移動させてから解放する。
なお、外部ヒープメモリへのデータの配置方法は2種類ある。1つはプログラム上のある区間内で生成されるデータを全て外部ヒープメモリに配置する方法であり、もう1つは外部ヒープメモリに関連付けた(配置のための関連付けを行った)データから参照可能なデータのみを外部ヒープメモリに配置する方法である。図13に示すのは、後者の参照関係を利用してデータを配置するタイプの外部ヒープメモリを利用するための記述である。行1303に示す外部ヒープメモリへのデータ生成文を、行1302で示す実行文によって生成した外部ヒープメモリへの関連付けと見なす。
図17は、図13の行1305で示す実行文を実行する直前のメモリとデータのイメージを示す図である。行1302で示す実行文によって生成した外部ヒープメモリ112内に、行1303で示す実行文によって生成したListクラスのデータli(符号1701)が配置されている。また、Javaヒープメモリ111内にObjクラスのデータo1(符号1702),o2(符号1703)が生成されており、その他のデータとして、で示すデータE(符号1704−1),F(1704−2)も配置されているものとする。データ間の矢印1705はデータ間の参照関係を表す。この状態で、図13の行1305で示す実行文を実行すると、データo1(符号1702)とo2(符号1703)は外部ヒープメモリ112に関連付けたデータli(符号1701)から参照可能となる。この様子を図18に示す。
図18では、データli(符号1701)からデータo1(符号1702),o2(符号1703)への参照を矢印1801,1802で示している。この後、ある契機によって、データo1(符号1702),o2(符号1703)を外部ヒープメモリ112に移動させる。ある契機としてはGCやメモリ使用量の閾値超過などが考えられる。データo1,o2の移動後のイメージを図19に示す。外部ヒープメモリ112に関連付けられているデータli(符号1701)から参照可能なデータo1とデータo2が符号1901と符号1902として示すように外部ヒープメモリ112に移動している。ここで、行1304に示す外部ヒープメモリ112の解放のための実行文を実行することを考える。図19に示す状態のまま外部ヒープメモリ112を解放してその内部データを削除してしまうと、データF(符号1704−2)からデータo2(符号1902)への参照が不正となってしまい、後の実行結果を保証することができない。
そこで、矢印1707のようなJavaヒープメモリ111(解放対象外メモリ)から外部ヒープメモリ112(解放対象メモリ)への参照がある場合は、外部ヒープメモリ112(解放対象メモリ)内の被参照データo2(符号1902)をJavaヒープメモリ111(解放対象外メモリ)に移動(コピー)させる。移動(コピー)させた後の様子を図20に示す。図20においては、図19におけるデータo2(符号1902)をデータo2’(符号2001)に移動(コピー)させ、データF(符号1704−2)からの参照の矢印1707も新たに矢印2002としている。データo2(符号1902)とデータo2’(符号2001)は同一のデータであるため、データF(符号1704−2)からデータo2’(符号2001)への参照は、データF(符号1704−2)から元のデータo2(符号1902)への参照と同様であり、外部ヒープメモリ112ごとデータli(符号1701),o1(符号1901)及びo2(符号1902)を削除しても、後の実行結果に影響がないことを保証できる。
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仮想マシンの評価、第7回情報科学技術フォーラム(FIT2008)、2008年
外部ヒープメモリへのデータ配置方法として、外部ヒープメモリに関連付けたデータ(例えば図19のデータli(符号1701))から参照可能なデータ(例えば図19のデータo1(符号1901))を配置するタイプの外部ヒープメモリを利用する際には専用APIを記述する必要があるが、APIを適切に記述するには、プログラムの構造やオブジェクト配置の把握が必要であり、プログラム開発期間の長期化を招く恐れがある。特に、外部ヒープメモリの解放記述に関しては、後の実行で必要である可能性があるデータを、GC対象メモリ領域を含めた解放対象外領域に移動させるため、不適切な箇所に記述を行うと解放対象領域内のデータの多くが解放対象外領域に流出し、結果として長時間停止を要するGCを誘発する恐れがある。
また、APIを記述したとしても、そのAPIに対応していない処理系で利用することができず、ポータビリティの低下を招く。さらに、ソースプログラムが配布されていない場合や、ライセンスなどの制約によりプログラムの改変が不可能な場合は、外部ヒープメモリを利用することができないため、適用可能プログラムが少なくなってしまう。
本発明は、前記問題に鑑みてなされたものであり、長時間のプログラム停止を伴うガベージコレクションを行わず、かつ、追加のAPIを用いないメモリ管理を実現することを課題とする。
本発明は、コンピュータ内のプロセッサにより実行されるプログラムによって、ガベージコレクションの対象となる対象メモリと、ガベージコレクションの対象とならない対象外メモリと、の領域を確保可能なメモリの管理を行うメモリ管理方法である。
対象外メモリに配置されたデータに対して、当該対象外メモリ以外に配置されたデータからの参照があると判定したときでも、当該対象外メモリに配置された全データのうちの参照関係の起点データに対して、当該対象外メモリ以外に配置されたデータからの参照がないと判定した場合、当該対象外メモリを解放可能と判定することを特徴とする。
その他の手段については後記する。
本発明によれば、長時間のプログラム停止を伴うガベージコレクションを行わず、かつ、追加のAPIを用いないメモリ管理 を実現することができる。
本実施形態のコンピュータと外部記憶装置の構成図である。 Javaのサンプルプログラムの例を示す図である。 起点データ及びデータ生成メソッド情報の外部入力ファイルへの記述例を示す図である。 起点データ及びデータ生成メソッド情報の起動オプションへの記述例を示す図である。 起点データ及びデータ生成メソッド情報の外部入力ファイル及び起動オプションからの読み込みアルゴリズムのフローチャートを示す図である。 外部ヒープメモリ解放可否判定アルゴリズムのフローチャートを示す図である。 Javaヒープメモリと外部ヒープメモリへのデータ配置例を示す図である。 ガベージコレクション対象領域の分割を伴うデータ必要性判定アルゴリズムのフローチャートを示す図である。 Javaヒープメモリと外部ヒープメモリへのデータ配置例を示す図である。 図9のデータ配置例に図8のフローチャートを適用した後のデータ配置を示す図である。 ガベージコレクション対象領域の分割を伴うデータ必要性判定を効率的に実施するアルゴリズムのフローチャートを示す図である。 Javaヒープメモリと外部ヒープメモリへのデータ配置例を示す図である。 外部ヒープメモリをAPIで利用する場合のプログラムを示す図である。 Javaヒープメモリと外部ヒープメモリへのデータ配置例を示す図である。 ガベージコレクション対象領域の分割を伴うデータ必要性判定で必要データの移動を伴うアルゴリズムのフローチャートを示す図である。 図14のデータ配置例に図15のフローチャートを適用した後のデータ配置を示す図である。 図13の行1305で示す実行文を実行する直前のメモリとデータのイメージを示す図である。 図17の状態から図13の行1305で示す実行文を実行した後のメモリとデータのイメージを示す図である。 図18の状態からデータo1,o2を外部ヒープメモリに移動した後のメモリとデータのイメージを示す図である。 図19の状態からデータo2をJavaヒープメモリに移動した(コピーした)後のメモリとデータのイメージを示す図である。
本発明に係るメモリ管理方法などを実施するための形態(以下、実施形態という。)について、図面を用いて説明する。なお、複数の図面にわたっての同一の構成や処理には同一の符号を付し、重複する説明を適宜省略する。また、本実施形態はJava言語に対して本発明を適用した場合の説明となっているが、ガベージコレクション機能を有する他の言語に対しても有効である。
図1に示すように、コンピュータ101は、各処理を実行するプロセッサ102と、メモリ103とを備えている。
Java仮想マシン105は、外部ヒープメモリ生成情報取得部106、外部ヒープメモリ生成部107、不要データ判定部108、外部ヒープメモリ解放判定部109、外部ヒープメモリ解放部110を備えている。
メモリ103には、プロセッサ102上で実行されるJava仮想マシン105が実行するJavaプログラム104が格納され、Java仮想マシン105が用いるGC対象メモリ領域であるJavaヒープメモリ111、GC対象外メモリである外部ヒープメモリ112(112−1,2,3)が確保(生成)される。
外部ヒープメモリ112は、Javaプログラム104上に記述された外部ヒープメモリ生成文、もしくはJava仮想マシン105に含まれる外部ヒープメモリ生成情報取得部106で取得した情報を元に生成した外部ヒープメモリ生成バイトコードを実行した回数分だけ生成される。なお、Javaプログラム104はメモリ103上ではなく、コンピュータ101に接続された外部記憶装置113に記録されていてもよい。Javaプログラム104には、通常の処理(本発明の特徴以外の処理)のみが記述されているか、外部ヒープメモリ112の生成と外部ヒープメモリ112へのデータの関連付けの記述が加えられている。通常の処理記述のみである場合は、外部ヒープメモリ生成情報取得部106において、外部ヒープメモリ生成箇所及び関連付けるデータの情報を取得する。以後、外部ヒープメモリ112に関連付けたデータを「参照関係上の起点データ」もしくは単に「起点データ」と記述する。
Javaプログラム104を実行するため 、Javaプログラム104をコンパイルして生成されたバイトコードを読み込んだJava仮想マシン105は、外部ヒープメモリ生成情報取得部106によって外部ヒープ生成情報を読み込み、外部ヒープメモリを生成するバイトコードが実行された際には外部ヒープメモリ生成部107によって外部ヒープメモリ112を生成する。Java仮想マシン105は、外部ヒープメモリ112に関連付けた参照関係上の起点データから参照可能となるデータを、外部ヒープメモリ112に直接生成するか、GC対象メモリであるJavaヒープメモリ111に生成した後、数回のGCを経ても参照関係が保たれている場合は外部ヒープメモリ112に移動させることによって、外部ヒープメモリ112にデータを配置する。
Javaプログラム104の実行中、Java仮想マシン105は不要データ判定部108によって、GC対象メモリであるJavaヒープメモリ111における不要データを他データへの参照を持たない別データに変換する。さらに、Java仮想マシン105は、外部ヒープメモリ解放判定部109を実行し、外部ヒープメモリ112に関して、外部ヒープメモリ112内の全データもしくは外部ヒープメモリ112に関連付けた起点データへの参照が無い場合は、その外部ヒープメモリ112を解放可能と判定し、外部ヒープメモリ解放部110によって解放する。その際、Javaヒープメモリ111(解放対象外メモリ)から外部ヒープメモリ112(解放対象メモリ)への参照がある場合は、直接及び間接的に参照可能なデータ群をJavaヒープメモリ111(解放対象外メモリ)に移動させることによって、後の実行結果に影響が出ないようにする。
図2に示すサンプルプログラム201を参照して、外部ヒープメモリ生成情報取得部106について説明する。サンプルプログラム201にはtestパッケージに属するSampleクラス202が記述されており、クラス内にfooメソッド203が記述されている。fooメソッド203内では、行204で示す文においてHashMapクラスのデータを生成し、attributesフィールド205から参照させる処理が行われる。
ここでは、このHashMapのデータを外部ヒープメモリ112に関連付けて起点データとしたいとする。その方法として、起点データとしたいデータのクラス名と、そのデータを生成するメソッド名を、Java仮想マシン105が読み込み可能な場所、例えば別のファイルに図3の符号301の箇所に示すような形で記述しておき、これをJava仮想マシン105の実行時に読み込ませる。本ファイルには、外部ヒープメモリ112に関する起点データのクラス名、当該データを生成するメソッド名の順で、括弧の内部に「,」で区切って記述する。サンプルプログラム201を例とすると、起点データのクラスjava.util.HashMapを符号302の箇所に示すように記述し、本データを生成するtestパッケージに属するSampleクラス内のfooメソッドを符号303の箇所に示すように記述する。
この記述を読み込んだJava仮想マシン105は、行204で示す処理文を実行する際、外部ヒープメモリ112を1つ生成するとともにHashMapデータも生成し、生成した外部ヒープメモリ112に生成したHashMapデータが関連付けられていると認識する。なお、この記述はJava仮想マシン105の起動オプション(以下、単に「オプション」ともいう。)としてもよく、図4にその例を示す。
図4は、Java仮想マシン105でSampleクラスにあるmainメソッドを動作させるための記述に対する、外部ヒープメモリ生成情報指示オプション−eheap_create(符号401)として、起点データのクラス名を符号402の箇所に示すように、そのデータを生成するメソッド名を符号403の箇所に示すように記述した例である。起点データ及び当該データの生成メソッド名はサンプルプログラム201を例としている。
ここで、図3、図4に示す起点データと当該データを生成するメソッドの情報をJava仮想マシン105に読み込む外部ヒープメモリ生成情報取得部106の処理を図5に示す。なお、処理501〜509はJava仮想マシン105の起動直後であり、まだJava仮想マシンの通常の処理(処理510)は開始されていないとする。
まず、処理501で、図3に示すような外部ヒープメモリ生成情報を記述したファイルがあるか否かを調べる。ある場合(処理501でYes)は、処理502で、まず1行読み、処理503でフォーマットを確認してエラーがあるか否かを判定する。エラーがなければ(処理503でNo)、処理504で、括弧内の最初の「,」までの情報を起点データ(のクラス名)として登録し、処理505で、「,」の後の情報を起点データの生成メソッドとして登録する。
その後、処理506で、未処理のデータ(行)があるか否かを判定し、ある場合(Yes)は処理502に戻り、ない場合(No)は処理508に進む。
処理503でエラーがあった場合(Yes)は、処理507でエラー処理を行い、ファイルの読み込みなしで処理508に進む。
処理508で、図4に示すような外部ヒープメモリ生成情報を記述したオプションが指定されているかどうかを調べ、ある場合(Yes)は処理509で記述されている情報を起点データのクラス名と当該データを生成するメソッド名の情報として登録する。処理508でNoの後、あるいは、処理509の後、処理510で、通常のJava仮想マシン105の処理を開始する。
次に、外部ヒープメモリ解放判定部109について説明する。図6に示すように、まず、処理601で、全ての利用可能メモリ、すなわち、Javaヒープメモリ111と外部ヒープメモリ112内データからの参照先がどの領域なのかを調べる。処理602で、外部ヒープメモリ112を1つ選択し、処理603で、処理601で調べた結果から、選択した外部ヒープメモリ112内のデータへの参照が1つでもあるかを調べる。
ない場合(処理603でNo)は処理605に進み、選択している外部ヒープメモリ112を解放可能扱いとする。ある場合(処理603でYes)は処理604に進み、選択している外部ヒープメモリ112に関連付けた起点データへの参照があるか否かを調べ、無ければ(No)処理605に進み、選択している外部ヒープメモリ112を解放可能扱いとする。ある場合(処理604でNo)は処理606で未処理の外部ヒープメモリ112があるか否かを調べ、ある場合(Yes)は処理602に戻り、一連の処理を繰り返す。全ての外部ヒープメモリ112に対する判定処理が終了した時点(処理606でNo)で、処理を終了する。
なお、図6の処理の実行契機は、例えば、GCや、外部ヒープメモリ112のサイズの合計値が所定の閾値を超えた場合、あるいは、メモリ103の利用可能領域に対する使用割合が所定の閾値を超えた場合とすればよい。図7を用いて、図6の処理を実施した場合のメモリ103におけるデータの配置例について説明する。図7に示すメモリイメージでは、GC対象メモリ領域であるJavaヒープメモリ111に加えて、2つの外部ヒープメモリ112−1,112−2が既に確保されている。また、Javaヒープメモリ111内にはデータA,B,C(符号701,702,703)が配置されている。外部ヒープメモリ112−1には、データR1,1,2,3(符号704,706,705,714)、外部ヒープメモリ112−2には、データR2,4(符号707,708)が配置されているものとする。
外部ヒープメモリ112−1に関連付けた参照関係上の起点データはデータR1(符号704)であり、外部ヒープメモリ112−2に関する起点データはデータR2(符号707)である。なお、矢印709〜713はデータ間の参照関係を表す。このような状況下で、まず、処理601で全メモリ内のデータの参照先を調べる。その結果、図7における矢印709〜713で示すような参照関係が把握できる。
次に、処理602で外部ヒープメモリを1つ選択するが、ここでは外部ヒープメモリ112−1を選択したとする。処理603で、外部ヒープメモリ112−1の外部データから外部ヒープメモリ112−1の内部データへの参照有無を調べると、矢印710に示すデータA(符号701)からデータR1(符号704)への参照が検出されるので(Yes)、処理604に進む。
処理604で、領域外からの起点データR1への参照を調べるが、先に述べた矢印710がこれに該当するため、処理606でYes→処理602と進んで、次の外部ヒープメモリ112−2を選択する。再び、処理603を実行すると、外部ヒープメモリ112−2内のデータR2(符号707)とデータ4(符号708)には、外部からの参照が存在しないため(No)、処理605に進み、外部ヒープメモリ112−2は解放可能扱いとする。これら一連の処理により、2つの外部ヒープメモリ112−1,2のうち、外部ヒープメモリ112−2が解放可能扱いとなる。
なお、処理の重さを軽減するため、処理603と処理604はどちらか一方だけとしてもよい。参照の有無に関する調査である処理603と処理604のうち、処理604における「起点データへの参照の有無の調査」によって、解放可能と見なす外部ヒープメモリ112を多くするためには、起点データ、例えば、図7におけるデータR1(符号704)とデータR2(符号707)のようなデータへの参照を少なくすることが求められる。しかし、これらの起点データを参照するデータ、例えば図7におけるデータAからの参照の必要性を判定するためには、データAが今後の実行で必要であるか否かの判定が必要である。
もし、データAがGC対象メモリ領域、例えばJavaヒープメモリ111に存在し、長時間のJavaプログラムの停止によるGCによってのみデータの必要性を判定できる領域に配置されている場合、外部ヒープメモリ112の利用によって長時間停止を要するGCが非常に発生しにくい状況にあるため、データAの必要性の判定が長期間行われないことが予想される。一般的なJava仮想マシンで採用されている世代別GC手法においては、Javaヒープメモリ111をNew領域とOld領域に分割してGC時間の軽減を図っているが、2領域のうちのOld領域は先に述べた長時間停止を要するGCを発生させなければデータの必要性の判定ができない領域である。
このような問題を解決するための方法、すなわちOld領域のような長時間停止を要するGCを発生させなければデータの必要性を判定することができない領域を複数の領域に分割し、分割した領域ごとにその内部データの必要性を判定する不要データ判定部108について説明する。図8に示すように、まず、処理801で、GC対象領域(Javaヒープメモリ111)を複数の領域に分割する。分割サイズはJava仮想マシン105のオプションや外部入力ファイルで指定するものとする。
処理802で、分割した領域を1つ選択し、その領域内のデータに対して、処理803〜807に示すデータの必要性判定処理を行う。処理803で、選択している領域外のデータから領域内のデータへの参照を調べ、参照可能な領域内データに印をつける。次に、処理804で、領域内で印がついたデータから参照可能な領域内の印がついていないデータに印をつける処理を行う。これらの処理803と処理804を実行することで、選択した領域以外のデータから直接もしくは間接的に参照可能な領域内データに印がつけられる。処理805では、選択領域内データのうち、無印のデータの情報を収集する。
処理806で、無印のデータがあるか否かを判定し、ある場合(Yes)は処理807で無印のデータを他データへの参照を持たない別データに変換する。処理805で抽出された無印のデータは、他のどのデータからも参照できないデータであり、少なくとも後の実行には必要のないデータであることが確定するため、処理807で別データに変換しても問題ない。処理806でNoの後、あるいは、処理807の後、処理8071で当該判定を終了する。
次に、処理808で、未処理の領域があるか否かを調べ、ある場合(Yes)は処理802に戻り、無い場合(No)は、GC対象領域に対するデータの必要性判定処理(図8の処理)を終了する。図8の処理によって、データ間の不必要な参照を除去することができ、結果として外部ヒープメモリ112に関連付けた起点データへの参照が除去されることが期待できる。なお、処理807では、不要と判定できたデータを、参照を持たない別データに変換すると述べたが、データ自体は変換せずに、他データへの参照を持つ場所に、どのデータも参照していないことを示すデータを代入する方法や、参照自体に不要な参照であるという属性を持たせ、使用時にその情報を利用するという方法を用いてもよい。
また、図8の処理はいつ実行しても構わないが、GC終了時やメモリ使用量に関する閾値を実際の使用量が超えた場合に実施するといったケースが実用的であると考えられる。閾値としては、外部ヒープメモリ112のサイズの合計値や、メモリ103の利用可能領域に対する使用割合などが考えられる。
図9を用いて、図8の処理を実施した場合のメモリ103におけるデータの配置例について説明する。図9に示すように、Javaヒープメモリ111と外部ヒープメモリ112があり、符号901〜907はデータ、矢印908〜911はデータ間の参照関係を表す。なお、データB(符号902)は、他領域のデータである他データ913(例えばメモリ103上のスタックフレームやレジスタなどのGCルートと呼ばれる部分や他の外部ヒープメモリ112)からの参照(矢印914)があると仮定する。
まず、処理801に従い、GC対象領域であるJavaヒープメモリ111を分割する。ここでは、Javaヒープメモリ111を3領域に分割する。図9では、符号912−1を領域1、符号912−2を領域2、符号912−3を領域3としている。
次に、処理802に従い、分割した領域を1つ選択するが、ここでは領域1(符号912−1)を選択したとする。処理803に進み、領域1内のデータAに対する領域1以外の領域のデータからの参照を調べる。結果として、データAは他領域のデータから全く参照されていないため、他データから参照されていることを示す印は付加されない。よって、処理804は実行されず、処理805、806に進み、データAには印がついていないので処理807に進む。この時点で、データAはどのデータからも参照されていないため、データAを他データへの参照、すなわちデータR3(符号904)への参照のない別データに置き換える。これで領域1の処理は終了し、領域2(符号912−2)と領域3(符号912−3)に対して、同様の処理を行う。
領域2にはデータが存在しないため、領域3の処理を行うと、処理803でデータBに印が付加され、処理804でデータCに印が付加される。処理805では、領域3内のデータBとCの双方とも印がついているため、無印のデータはないということになり、処理を終了する。この時点でのデータ配置のイメージを図10に示す。データA(図9における符号901)がデータA’(符号1001)となり、図9における矢印909の参照がなくなっていることがわかる。もし、図9の時点で外部ヒープメモリ解放判定部109の処理(図6の処理)を実行しても、データA(符号901)からデータR3(符号904)への参照(矢印909)が存在するため(処理603,604のいずれもYes)、外部ヒープメモリ112を解放することはできない。しかし、図10の状態で、外部ヒープメモリ解放判定部109の処理(図6の処理)を実行すると、起点データR3への参照がないため(処理603,604の少なくともいずれかでNo→処理605)、外部ヒープメモリ112を解放可能と判定することができる。
図8の処理方法では、分割したGC対象領域全てが処理対象となる。しかし、図8に示す不要データ判定部108の処理は図6に示す外部ヒープメモリ解放判定部109のアルゴリズムを効果的に適用するための処理であり、各外部ヒープメモリ112に関連付けた起点データ(例えば、図7のデータR1(符号704)やデータR2(符号707)、図9のデータR3(符号904))を参照するデータ(すなわち、図7のデータA(符号701)や図9のデータA(符号901))が配置されている箇所の不要データ判定を行えばよい。
このデータA(符号701)やデータA(符号901)が配置されている箇所の情報は、図3〜5に示した外部ヒープメモリ112に関連付けるオブジェクトの生成時に得ることができる。図3を例にすると、起点データは符号302の箇所に示すようにHashMapクラスのデータであり、本データが生成されるのは、符号303の箇所に示すようにSampleクラスのtestメソッドであるが、その際にこのSampleクラスのデータ配置を覚えておき、図8に示す不要データ判定部108の処理時に利用すればよい。
図11にそのアルゴリズムのフローチャートを示す。図8のフローチャートとの違いは、処理802における分割された領域の1つの選択を、処理1101に示すように起点データを参照するデータが存在する領域の選択とした点である。これに伴い、処理808も、処理1102に示すように起点データへの参照を持つ領域で未処理の領域があるか否かを判定するようにしている。これらについて、図12を用いて説明する。
図12では、図9と比較して、Javaヒープメモリ111内のデータ配置が異なっている。領域3(符号912−3)にデータA(符号1201)があり、そのデータAからデータR3(符号904)への参照(矢印1205)が存在する。また、データB(符号1202)、データC(符号1203)が領域1(符号912−1)に、データD(符号1204)が領域2(符号912−2)にあるものとする。
データR3(符号904)の生成時に、これを参照(矢印1205)するデータA(符号1201)の配置情報をJava仮想マシン105が保持しているものとして、図11のフローチャートの処理を適用する。処理1101で、領域1〜3中の起点データ(R3(符号904))への参照を持つデータがある場所は領域3(符号912−3)のみであるため、領域3を選択する。処理803〜8071を実行すると、データAへの参照は存在しないため、データA(符号1201)を、データAからデータR3への参照(矢印1205)が無い別データに変換することができる。そして、処理1102で、起点データ(R3(符号904))への参照を持つデータが存在する領域はない(No)と判定でき、処理を終了する。
この状態で図6に示す外部ヒープメモリ解放判定部109のフローチャートの処理を適用すると、外部ヒープメモリ112は解放可能と判定(処理603,604の少なくともいずれかでNo→処理605)することができる。もし、図8に示すフローチャートの処理を適用した場合、領域1,2に存在するデータB〜Dへの参照も調べることになるが、図11のフローチャートの処理を適用するとこのような領域を調べなくてよく、効率がよい。
図8に示す処理803〜8071では、ガベージコレクション対象メモリを分割した小領域において、ある領域内のデータと、それと異なる領域内のデータとが相互参照状態にある場合、それらのデータの必要性の判定を行っても、不必要とは判定されない。例えば図14にように、ガベージコレクション対象であるJavaヒープメモリ111を符号912−1〜912−3に示すように3分割した領域にデータA(符号1401)とデータB(符号1402)があり、それぞれ領域1と領域3に配置されているとする。また、その他のデータ(符号1403〜1405)と参照(矢印1407,1408)については、図示の通りである。
この状態に対して、図8に示すフローチャートの処理を適用した場合、まず、領域1内データに対する参照を調べると、領域3のデータBからデータAへの参照(矢印1409)が検出されるため、データAは後の実行で必要であると判定される(処理803で印がつけられる)。次に、領域3内データに対する参照を調べると、領域1のデータAからデータBへの参照(矢印1410)が検出されるため、データBも後の実行で必要と判定される(処理803で印がつけられる)。
しかし、データAをデータBと同一の領域に、もしくはデータBをデータAと同一の領域に移動させると、データAとデータBに対する領域外からの参照は存在しないため、両データを不必要なデータと判定できる(処理803で印がつけられない)。結果として、データAからデータR4への参照(矢印1406)を除去できるため、外部ヒープメモリ112を解放可能と判定できる。このように、相互参照状態にあるデータが異なる領域に存在するとデータの必要性判定の正確性が著しく低下するが、同一領域に存在するようにするとデータの必要性判定がより正確に行えることがわかる。そのアルゴリズムのフローチャートを図15に示す。
図15に示すフローチャートは、図8のフローチャートと比較して、処理807が処理1501に置き換えられている点で異なる。処理807は不必要と判定できたデータを他への参照を持たないデータに変換する処理だが、処理1501では、処理803及び処理804で印をつけたデータがメモリ103上で連続になるように移動させる処理を行う。その結果として、相互参照状態にあるデータが近くに配置されるようになり、同一領域に配置されやすくなる。図14の状態に対して図15に示すフローチャートの処理を適用した後のメモリ103のイメージを図16に示す。
図16におけるJavaヒープメモリ111は、メモリ103の空間上、左側が低位アドレス、右側が高位アドレスとし、図15の処理1501では印を付加されたオブジェクトを低位アドレス側に移動させるものとする。図16においては、データAとデータBの間にはデータは存在しないため、データBが符号1601で示すように低位アドレス側に移動し、データAと同じ領域1内に配置される。この状態で図8の不要データ判定を実行すると、データA及びデータBに対する参照は存在しないため、両データとも参照を持たない別データに変換する(処理807を実行する)ことができる。結果として、参照(矢印1406)を除去することができ、外部ヒープメモリ解放判定部109による処理(図6の処理)を実行すると、この外部ヒープメモリ112を解放可能と判定できる。
このように、本実施形態に係るメモリ管理方法によれば、ガベージコレクションによってメモリ103の管理を行う場合、外部ヒープメモリ112に関連付けたデータへの参照が不要と判定できた場合、その外部ヒープメモリ112を解放可能と見なすことによって、ソースプログラムへの修正なしで、外部ヒープメモリ112を利用可能にすることができる。その際、外部ヒープメモリ112を効率的に解放可能とするため、ガベージコレクション対象のJavaヒープメモリ111を複数の領域に分割し、分割した領域ごとにデータの必要性を判定し、後の実行で全く必要ないと判定できたデータからの参照を不要な参照と見なすことで、結果として外部ヒープメモリ112への参照を積極的に減少させ、解放可能な外部ヒープメモリ112を増加させることができる。
そして、外部ヒープメモリ112の解放処理を、オプションや外部入力ファイルで与えられた外部ヒープメモリ112の生成及び関連付けるデータの情報を併用して自動化することによって、ソースプログラムへのAPI記述無しで外部ヒープメモリ112が利用可能となるため、プログラム開発期間の短縮や、プログラムミスによる長時間GCの誘発阻止を期待できる。また、外部ヒープメモリ112を適用したいアプリケーションのプログラム修正が許されていない場合や、プログラムが存在しない場合においても、APIの記述無しに外部ヒープメモリ112を利用可能とすることによって、ポータビリティを保持したまま、より多くのプログラムに外部ヒープメモリ112を適用することができる。
以上で実施形態の説明を終えるが、本発明の態様はこれらに限定されるものではない。具体的な構成や処理について、本発明の主旨を逸脱しない範囲で適宜変更が可能である。
101…コンピュータ
102…プロセッサ
103…メモリ
104…Javaプログラム
105…Java仮想マシン
106…外部ヒープメモリ生成情報取得部
107…外部ヒープメモリ生成部
108…不要データ判定部
109…外部ヒープメモリ解放判定部
110…外部ヒープメモリ解放部
111…Javaヒープメモリ
112…外部ヒープメモリ
113…外部記憶装置

Claims (14)

  1. コンピュータ内のプロセッサにより実行されるプログラムによって、ガベージコレクションの対象となる対象メモリと、ガベージコレクションの対象とならない対象外メモリと、の領域を確保可能なメモリの管理を行うメモリ管理方法であって、
    前記対象外メモリに配置されたデータに対して、当該対象外メモリ以外に配置されたデータからの参照があると判定したときでも、
    当該対象外メモリに配置された全データのうちの参照関係の起点データに対して、当該対象外メモリ以外に配置されたデータからの参照がないと判定した場合、
    当該対象外メモリを解放可能と判定する
    ことを特徴とするメモリ管理方法。
  2. 請求項1のメモリ管理方法において、前記対象外メモリに配置したデータの情報を、前記プログラムの起動オプションまたは外部入力ファイルを用いて取得する
    ことを特徴とするメモリ管理方法。
  3. 請求項1のメモリ管理方法において、前記対象外メモリに関する解放可能か否かの判定を、前記ガベージコレクションの終了時に行う
    ことを特徴とするメモリ管理方法。
  4. 請求項1のメモリ管理方法において、前記対象外メモリに関する解放可能か否かの判定を、前記プログラムの起動オプションまたは外部入力ファイルに記述されたメモリ使用量に関する閾値を実際の前記メモリの使用量が超えた場合に行う
    ことを特徴とするメモリ管理方法。
  5. 請求項1のメモリ管理方法において、前記対象外メモリに関して、配置された全データのうちの参照関係の起点データに対して、当該対象外メモリ以外に配置されたデータからの参照がないと判定した場合、当該メモリを解放可能と判定するとき、
    前記起点データを参照するデータが当該対象外メモリ以外に配置されていた場合、当該データの必要性を判定し、当該データを必要性がないと判定したとき、当該データから前記起点データへの参照をないものと見なし、当該対象外メモリを解放可能と判定する
    ことを特徴とするメモリ管理方法。
  6. 請求項5のメモリ管理方法において、前記必要性の判定を、前記ガベージコレクションの終了時に行う
    ことを特徴とするメモリ管理方法。
  7. 請求項5のメモリ管理方法において、前記必要性の判定を、前記プログラムの起動オプションまたは外部入力ファイルに記述されたメモリ使用量に関する閾値を実際の前記メモリの使用量が超えた場合に行う
    ことを特徴とするメモリ管理方法。
  8. 請求項5のメモリ管理方法において、当該データの必要性を判定するとき、
    前記対象メモリの領域を2つ以上の領域に分割し、分割領域ごとに、他の分割領域のデータからの参照について調べ、直接的もしくは間接的に参照される可能性があるデータ以外のデータを必要性がないと判定する
    ことを特徴とするメモリ管理方法 。
  9. 請求項8のメモリ管理方法において、前記分割領域のうち、前記対象外メモリに配置されたデータを参照するデータが配置されている領域を、前記必要性を調べる領域として選択する
    ことを特徴とするメモリ管理方法。
  10. 請求項8のメモリ管理方法において、前記対象メモリの領域を2つ以上の領域に分割する際の分割領域のサイズを、前記プログラムの起動オプションまたは外部入力ファイルに記述している
    ことを特徴とするメモリ管理方法。
  11. 請求項8のメモリ管理方法において、前記対象メモリの領域を2つ以上の領域に分割した後、相互参照関係にある2つのデータが異なる分割領域に存在する場合に、少なくともいずれかのデータを移動することで、当該2つのデータが同一の分割領域にあるようにする
    ことを特徴とするメモリ管理方法。
  12. 請求項1のメモリ管理方法であって、前記プログラムの起動オプションまたは外部入力ファイルの情報を読み込み、その結果を用いて前記対象外メモリの領域を生成する
    ことを特徴とするメモリ管理方法。
  13. ガベージコレクションの対象となる対象メモリと、ガベージコレクションの対象とならない対象外メモリと、の領域を確保可能なメモリと、
    前記対象外メモリに配置されたデータに対して、当該対象外メモリ以外に配置されたデータからの参照があると判定したときでも、
    当該対象外メモリに配置された全データのうちの参照関係の起点データに対して、当該対象外メモリ以外に配置されたデータからの参照がないと判定した場合、
    当該対象外メモリを解放可能と判定するプロセッサと、
    を備えることを特徴とするコンピュータ。
  14. コンピュータ内のプロセッサに、ガベージコレクションの対象となる対象メモリと、ガベージコレクションの対象とならない対象外メモリと、の領域を確保可能なメモリの管理を行うメモリ管理方法を実行させるためのメモリ管理プログラムであって、
    前記対象外メモリに配置されたデータに対して、当該対象外メモリ以外に配置されたデータからの参照があると判定したときでも、
    当該対象外メモリに配置された全データのうちの参照関係の起点データに対して、当該対象外メモリ以外に配置されたデータからの参照がないと判定した場合、
    当該対象外メモリを解放可能と判定する処理を、前記プロセッサに実行させるためのメモリ管理プログラム。
JP2009073646A 2009-03-25 2009-03-25 メモリ管理方法、コンピュータ、及び、メモリ管理プログラム Active JP5281452B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2009073646A JP5281452B2 (ja) 2009-03-25 2009-03-25 メモリ管理方法、コンピュータ、及び、メモリ管理プログラム
US12/607,622 US8898404B2 (en) 2009-03-25 2009-10-28 Memory management method and computer

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2009073646A JP5281452B2 (ja) 2009-03-25 2009-03-25 メモリ管理方法、コンピュータ、及び、メモリ管理プログラム

Publications (3)

Publication Number Publication Date
JP2010225033A JP2010225033A (ja) 2010-10-07
JP2010225033A5 JP2010225033A5 (ja) 2011-09-29
JP5281452B2 true JP5281452B2 (ja) 2013-09-04

Family

ID=42785564

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2009073646A Active JP5281452B2 (ja) 2009-03-25 2009-03-25 メモリ管理方法、コンピュータ、及び、メモリ管理プログラム

Country Status (2)

Country Link
US (1) US8898404B2 (ja)
JP (1) JP5281452B2 (ja)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5391422B2 (ja) 2009-09-01 2014-01-15 株式会社日立製作所 メモリ管理方法、計算機システム及びプログラム
JP5618796B2 (ja) 2010-12-02 2014-11-05 株式会社日立製作所 計算機、計算機の制御方法及びプログラム
JP5509164B2 (ja) * 2011-08-18 2014-06-04 株式会社日立製作所 計算機、管理方法及びプログラム
US20140337597A1 (en) * 2012-03-02 2014-11-13 Hitachi, Ltd. Computer, program, and memory management method
US11579855B2 (en) * 2017-12-15 2023-02-14 Microsoft Technology Licensing Llc Reduced memory consumption of compiler-transformed asynchronous methods
US10884641B2 (en) 2019-04-16 2021-01-05 Paypal, Inc. Low latency gateway for an asynchronous orchestration engine using direct memory

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4989132A (en) * 1988-10-24 1991-01-29 Eastman Kodak Company Object-oriented, logic, and database programming tool with garbage collection
US6081665A (en) * 1997-12-19 2000-06-27 Newmonics Inc. Method for efficient soft real-time execution of portable byte code computer programs
US7340494B1 (en) * 2004-03-12 2008-03-04 Sun Microsystems, Inc. Garbage-first garbage collection
US7962707B2 (en) * 2005-07-06 2011-06-14 Honeywell International Inc. Apparatus and method for deterministic garbage collection of a heap memory
JP5064134B2 (ja) 2007-08-03 2012-10-31 株式会社日立製作所 メモリ管理方法およびその方法を用いるコンピュータ

Also Published As

Publication number Publication date
US8898404B2 (en) 2014-11-25
US20100250629A1 (en) 2010-09-30
JP2010225033A (ja) 2010-10-07

Similar Documents

Publication Publication Date Title
Würthinger et al. Dynamic code evolution for Java
JP5064134B2 (ja) メモリ管理方法およびその方法を用いるコンピュータ
JP5281452B2 (ja) メモリ管理方法、コンピュータ、及び、メモリ管理プログラム
JP4917138B2 (ja) オブジェクト最適配置装置、オブジェクト最適配置方法、及びオブジェクト最適配置プログラム
JP5618796B2 (ja) 計算機、計算機の制御方法及びプログラム
US8443178B2 (en) Operating system image shrinking apparatus and method and computer readable tangible medium storing a program for operating system image shrinking
Würthinger et al. Unrestricted and safe dynamic code evolution for Java
US8397045B2 (en) Memory management device, memory management method, and memory management program
EP3577565B1 (en) Garbage collector
US20150128147A1 (en) Modified jvm with multi-tenant application domains and memory management
JP5380695B2 (ja) メモリ管理方法、計算機システム及びメモリ管理プログラム
US20080040407A1 (en) Identification of a cause of an allocation failure in a java virtual machine
Fulton et al. Compilation techniques for real-time Java programs
Lengauer et al. Where has all my memory gone? determining memory characteristics of product variants using virtual-machine-level monitoring
JP5564540B2 (ja) メモリ管理方法、コンピュータ及びプログラム
JP5199975B2 (ja) メモリ管理方法、メモリ管理プログラム、及び、情報処理装置
JP5756549B2 (ja) 記憶領域管理方法、計算機システム及びプログラム
WO2011104889A1 (ja) 計算機システム、メモリ管理方法及びメモリ管理プログラム
Stilkerich et al. A practical getaway: Applications of escape analysis in embedded real-time systems
US11106522B1 (en) Process memory resurrection: running code in-process after death
Fluet et al. Implementation and performance evaluation of a safe runtime system in Cyclone
US20230236835A1 (en) Cooperative garbage collection barrier elision
Geffken et al. Side effect monitoring for Java using bytecode rewriting
Sarcar Memory Management
Sasada Gradual write-barrier insertion into a Ruby interpreter

Legal Events

Date Code Title Description
A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110811

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20110811

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20130215

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20130226

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20130418

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20130514

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20130524

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

Ref document number: 5281452

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150