JPWO2005001695A1 - ガーベジコレクションシステム - Google Patents
ガーベジコレクションシステムInfo
- Publication number
- JPWO2005001695A1 JPWO2005001695A1 JP2005511067A JP2005511067A JPWO2005001695A1 JP WO2005001695 A1 JPWO2005001695 A1 JP WO2005001695A1 JP 2005511067 A JP2005511067 A JP 2005511067A JP 2005511067 A JP2005511067 A JP 2005511067A JP WO2005001695 A1 JPWO2005001695 A1 JP WO2005001695A1
- Authority
- JP
- Japan
- Prior art keywords
- thread
- pointer
- memory
- selection
- garbage collection
- 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.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
- G06F12/023—Free address space management
- G06F12/0253—Garbage collection, i.e. reclamation of unreferenced memory
- G06F12/0269—Incremental or concurrent garbage collection, e.g. in real-time systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
- G06F9/4488—Object-oriented
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
- Y10S707/99953—Recoverability
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99956—File allocation
- Y10S707/99957—Garbage collection
Abstract
Description
このような言語を用いて記述されたAPは、不要となったオブジェクトに対応するメモリ領域を自動的に解放するガーベジコレクション(GC)機構を備える実行環境上で動かされる。
GC機構は、APの実行に際して動的に確保されたオブジェクトに対応するメモリ領域がどこからも参照されていない状態になっていることを検出してそのメモリ領域を解放し再利用可能状態にする。
マルチスレッド構成のAPにおいて、各スレッドは、それぞれスタック領域と対応し、動作過程において、スタック領域内にデータを格納したり、格納したデータを参照したり、オブジェクトを生成したりする。オブジェクトを生成した場合には通常はスタック領域内にそのオブジェクトのポインタ、つまりそのオブジェクトのメモリ内における所在位置を指し示すデータ(以下、「オブジェクトポインタ」という。)が格納され、スレッドからのオブジェクトへのアクセスはそのオブジェクトポインタを参照することによりなされる。また、通常、オブジェクトの領域内にも、他のオブジェクトへのオブジェクトポインタが格納される。
ある時点においてAPにより参照されている全てのオブジェクトは、APの各スレッドに対応する各スタック領域内に含まれるオブジェクトポインタから、直接、又は1以上のオブジェクト内のオブジェクトポインタを媒介にして、辿ることができる。
これに対応してGC機構は、基本的に、ある時点においてスタック領域内のオブジェクトポインタから辿れなくなっているオブジェクトに対応するメモリ領域を不要なものとして解放対象にする。
従来のGC方式として知られているマークアンドスイープ方式は、特定のオブジェクトポインタから辿れる全てのオブジェクトにマークを付けていく処理を行った後に、全てのオブジェクトを走査して、マークの付いていないオブジェクトに対応するメモリ領域を解放する方式である。
このマークアンドスイープ方式のGCをマルチスレッド構成のAPの実行時に行う場合に、GCの迅速性を最優先して単純に、全スレッドを停止してから、各スレッドに対応するスタック領域内のオブジェクトポインタから辿れる全てのオブジェクトにマークを付与する処理を行い、その後に全スレッドの停止を解除して、マークの付いていないオブジェクトの解放を行うとするならば、次の問題が生じる。
即ち、APの全スレッドが停止している期間が長期化する可能性があり、この場合に、ユーザの操作等に対して一切反応を示せず、例えばコンピュータのディスプレイの表示内容は変化しないままとなり、ユーザを戸惑わせてしまうという問題である。
この問題を解決する方式として、日本国の特許第3027845号公報には、このマークアンドスイープを用いたGCを、マルチスレッド構成のAPを全く停止することなく実行する方式が提案されている。
この方式は、ルートノードなるオブジェクトから辿れる全てのオブジェクト及びスレッド毎の各スタック領域内のオブジェクトポインタから辿れる全てのオブジェクトに対してマークを付与する第1処理を行い、その第1処理中に、APのスレッド(以下、「APスレッド」という。)の動作によりオブジェクトへのオブジェクトポインタが移動した場合にそのオブジェクトを表すデータをマークスタックなる領域に積んでおき、そのマークを付与する処理が完了した段階で、更にマークスタックから辿れる全てのオブジェクトに対してマークを付与する第2処理を行い、最後に、マークされていないオブジェクトに対応するメモリ領域を解放するものである。
しかしながら、上述のAPを全く停止せずにマークを付与する方式では、APスレッドの動作によってスタック領域内のデータが変化するため、第1処理中、スタック領域内のオブジェクトポインタから辿れるオブジェクトに対してマークを付与する処理の一部が無駄となる可能性がある。
例えば、GCを行うスレッドが、APの1つのスタック領域内のオブジェクトポインタ(ここでは、「オブジェクトポインタA」と名付ける。)を検出して、そのオブジェクトポインタAから辿れるオブジェクトに対してマークを付与する処理(ここでは、「処理A」と名付ける。)を実行している間に、そのスタック領域に対応するAPスレッドが、オブジェクトポインタA或いはそれらのオブジェクト内の1又は複数のオブジェクトポインタを、コピーしてスタック領域に新たに格納する動作をしたならば、GCを行うスレッドはその処理Aの終了後にいずれ、再び処理Aと一部重複する処理を行う、或いはその重複防止のためのチェック処理をわざわざ行うことになり、これが無駄となる。この処理の無駄は、GCの開始から完了までに要するCPU時間を無駄に増加させることにつながり、CPUの利用効率を低下させる。
上記目的を達成するために、本発明に係るGCシステムは、複数スレッドで構成されるオブジェクト指向プログラムの実行過程において不要になったオブジェクトに対応するメモリ領域を解放するGCシステムであって、複数スレッドそれぞれを順に選択する選択手段と、選択されたスレッドについて、当該スレッドの実行を停止して、当該スレッドからオブジェクトポインタの参照を通じてアクセス可能であるオブジェクトを検出して当該検出したオブジェクトを非解放対象として管理して、当該スレッドの実行を再開するという手順からなる検査処理を実施する検査手段と、前記選択手段による前記選択が開始された後において、実行中のスレッドによりオブジェクトポインタが処理対象にされたことを検知した場合には、当該オブジェクトポインタが指すオブジェクトを非解放対象として管理する検知手段と、前記複数スレッド全てについて前記検査処理が完了した後において、非解放対象として管理されているオブジェクト以外のオブジェクトに対応するメモリ領域を、解放する解放手段とを備えることを特徴とする。
ここで、オブジェクトポインタがスレッドにより処理対象にされるということは、CPUによるスレッドの処理過程においてオブジェクトポインタを処理対象とする命令が実行されるということを意味する。
また、オブジェクトを非解放対象として管理するとは、例えばそのオブジェクトポインタをfromテーブルからtoテーブルに移行する後述の方法等により、マーク付与を実現することをいう。
これにより、APスレッドからスタック内やオブジェクト内のオブジェクトポインタを介して辿ることができるオブジェクトについての非解放対象としての指定の過程つまりマーク付与の過程においては、そのAPスレッドを停止させているため、そのAPスレッドが動作することに起因してスタック領域内のデータが変化するという事態が起こらないため、その過程におけるマーク付与が無駄になる危険性はなくなり、この点についてはCPUの利用効率低下を防止できる。
また、これにより、全てのAPスレッドを停止して上述のマーク付与を行っているのではないため、APの全スレッドが停止している期間の長期化が防止できる。なお、全APスレッドを停止させないことによるオブジェクトへの参照状態の変化に対しては、実行中のスレッドによりオブジェクトポインタが処理対象とされたことを監視して対応しているため、いずれかのスレッドからアクセス可能なオブジェクトについては必ず非解放対象として管理されることになる。
また、前記検知手段は、前記検知を、実行中のスレッドについて未だ検査処理がなされていない場合に限り行い、前記検知手段は、前記検知をした場合に、当該実行中のスレッドにより処理対象にされたオブジェクトポインタ、及び当該オブジェクトポインタから辿ることのできるオブジェクト内のオブジェクトポインタを、当該スレッドに対応する作業用メモリ領域に保存する検出部と、前記検査手段によりスレッドの実行が停止されている間に、当該スレッドに対応する作業用メモリ領域内のオブジェクトポインタから辿ることのできるオブジェクトを非解放対象として管理する管理部とを有することとしてもよい。
これにより、スレッドが後述する参照処理の対象とされるまでの間だけ、つまり、スレッドが、そのスレッドに対応するスタック内等に格納されているオブジェクトポインタが指すオブジェクトへのマーク付与に相当する処理の対象とされるまでの間だけ、インタプリタによるそのスレッドの実行時にオブジェクトポインタがスレッドによる処理対象とされたことを検出して作業用メモリ領域、即ちオブジェクト参照情報のメモリ領域に格納する処理を行うため、一旦スレッドが参照処理の対象とされた後は、そのスレッドはインタプリタによる実行時に、その検出がない分だけ、より高速に動作するようになる。
また、前記検査処理は、選択された当該スレッドに対応するスタック内のオブジェクトポインタが指すオブジェクトを、前記アクセス可能であるとして検出した際において、検出した当該オブジェクトが既に非解放対象として管理されておらず、かつ、当該オブジェクト内にオブジェクトポインタがあるときに限り、当該オブジェクトポインタが指すオブジェクトを更に前記アクセス可能であるとして検出する手順を、繰り返し行うことを内容とする処理であり、前記選択手段は、最初の選択後は、前記検査手段により前記検査処理が行われた後において前記複数スレッドのうち前記検査処理を実施されていないスレッドがある限り更なる選択を行い、前記選択手段は、各スレッドに関する情報を参照し、所定のスレッド選定条件に基づき、前記選択を行うこととしてもよい。
これにより、既に非管理対象として管理されたオブジェクトの配下のオブジェクトを重複的に検出のための処理の対象とすることを防止することができる。また、この重複的に検出のための処理を行わない仕組みにより、参照処理の対象として早期に選択されたスレッドより、遅く選択されたスレッドの方が参照処理に係る時間が短縮される可能性が高まるので、各スレッドに要求される応答性能に鑑みて、予めスレッド選定条件を定めておくことで、各スレッドが適切な応答性能を発揮して実行されるようにある程度制御することができるようになる。
また、前記スレッド選定条件は、スレッド状態がwait状態であるスレッドをスレッド状態がwait状態以外であるスレッドよりも早期に選択することを示す条件を含み、前記選択手段は、前記選択を行う時点でwait状態のスレッドがある限り、当該wait状態のスレッドを選択することとしてもよい。
これにより、Wait状態のスレッドを停止することになるため、現在動作しているAPスレッドに対する悪影響の発生が抑えられる。
また、前記スレッド選定条件は、スレッド優先度のスレッド優先度の低いスレッドをスレッド優先度の高いスレッドよりも早期に選択することを示す条件を含むこととしてもよい。
これにより、スレッド優先度の高いスレッドは、参照処理が短時間でなされる可能性が高くなり、実行性能の低下がある程度防止されるようになる。
また、前記スレッド選定条件は、スレッドに対応するスタックサイズが小さいスレッドをスタックサイズが大きいスレッドよりも早期に選択することを示す条件を含むこととしてもよい。
これにより、スレッドからアクセス可能なオブジェクトへのオブジェクトポインタを格納するスタックの有効範囲が小さい程、参照処理に要する時間は短くなる傾向にあることに鑑みれば、各スレッドの停止時間をある程度均等化する効果が得られ、特定のスレッドの応答性が他と比べて際立って悪くなるという事態がある程度回避できるようになる。
また、前記ガーベジコレクションシステムは、メモリ管理ユニット(MMU)を用いてメモリを管理するメモリ管理機構を備え、オブジェクトを生成する必要がある度に、前記メモリ管理機構により当該オブジェクトに対応するメモリ領域を確保し、前記解放手段は、前記メモリ管理機構を介して、メモリ領域の解放を行うこととしてもよい。
これにより、MMUを用いるメモリ管理機構により確保されているC言語その他によるプログラムのデータ領域等と同等の位置付けで、オブジェクトに対するメモリ領域が確保されるため、仮に、特定のヒープ領域を独自に管理してそのヒープ領域内の一部をオブジェクトに対するメモリ領域として確保するような制御を行うこととした場合と比べて、オブジェクトの生成前から無用に大きなヒープ領域を確保しておく必要がない点、そのヒープ領域についてのメモリコンパクション処理をする必要がない点等といった有利な効果が得られる。
図2は、オブジェクトとオブジェクトポインタとの関係を例示する図である。
図3は、fromテーブル及びtoテーブルを示す図である。
図4Aは、参照処理前のfromテーブルの状態を示す図である。
図4Bは、参照処理後のfromテーブル及びtoテーブルの状態を示す図である。
図5は、スレッド情報、スタック及びオブジェクト参照情報を示す図である。
図6は、参照処理とAPスレッドの状態との関係を示す図である。
図7は、スレッド選定条件の内容を示す図である。
図8は、GC制御処理を示すフローチャートである。
図9は、対象スレッド決定処理を示すフローチャートである。
図10は、共有オブジェクト参照処理を示すフローチャートである。
図11は、対象スレッド参照処理を示すフローチャートである。
図12は、参照処理を示すフローチャートである。
図13は、命令実行処理を示すフローチャートである。
図14は、オブジェクトチェーン追跡処理を示すフローチャートである。
図15は、本発明の実施形態2に係るGCシステムの機能ブロック図である。
図16は、スレッド情報及びスタックを示す図である。
図17は、実施形態2におけるGC制御処理を示すフローチャートである。
図18は、実施形態2における命令実行処理を示すフローチャートである。
図19は、従来のJava実行環境により管理されたJavaオブジェクトと、C言語のプログラムにおけるデータとのメモリ配置を示す図である。
以下、本発明の実施形態1に係るガーベジコレクション(GC)システムについて図面を用いて説明する。
<1−1.構成>
図1は、本発明の実施形態1に係るGCシステムの機能ブロック図である。
GCシステム10は、CPU、メモリ等を備えたコンピュータにおいてメモリに格納された制御プログラムがCPUによって実行されることにより実現され、マルチスレッド制御を行う一般のオペレーティングシステム(OS:Operating System)及びいわゆる仮想マシンを含み、Java言語等で作成されたアプリケーションプログラムの実行環境として位置づけられるシステムである。
GCシステム10は、図1に示すように、インタプリタ部100、オブジェクト管理部200、スレッド管理部300及びGC部400を備える。
ここで、インタプリタ部100は、基本的にインタプリタであってAPを実行する機能を担い、命令実行部110及びオブジェクト参照検出部120を有する。
オブジェクト管理部200は、オブジェクトを管理する機能を担い、fromテーブル221、toテーブル222等に対応するメモリ領域であるオブジェクト管理情報記憶部210、オブジェクト生成部230及びテーブル切替部240を有する。
なお、fromテーブル221は、GC開始前において存在する全オブジェクトに対する全オブジェクトポインタを格納するものと位置づけられるテーブルであり、toテーブル222は、マークアンドスイープ方式でのマーク付与がなされたオブジェクトに対するオブジェクトポインタを格納するために利用されるテーブルである。これらのテーブルについては後に詳細に説明する。
スレッド管理部300は、マルチスレッド制御を実現し、スレッドを管理する機能を担うものであり、スレッド制御部310と、APスレッド毎に、スレッド情報320、オブジェクト参照情報330及びスタック340に対応するメモリ領域を有する。
なお、スレッド情報320は、GC処理全体の開始時点でONにされそのAPスレッドに対しての参照処理が終了するとOFFにされるGCフラグを含む。参照処理は、オブジェクトへのマーク付与に相当する処理であり、オブジェクトを参照するためにスタック内等に格納されているオブジェクトポインタと同一内容のオブジェクトポインタをfromテーブルからtoテーブルに移動することを主内容とする処理である。
GC部400は、基本的にいわゆるガーベジコレクタに相当し、GC制御部410、スレッド選定条件記憶部420、参照処理部430及び解放部440を有する。このGC部400を中心として行われるGCは、基本的にマークアンドスイープ方式を用い、参照処理の対象となるAPスレッドを順番に選択して、選択したAPスレッドを停止させて参照処理を行ってからその停止を解除する方式のものである。
インタプリタ部100における命令実行部110は、APスレッドを構成する命令列を逐次解釈して実行し、命令がオブジェクトの生成命令である場合にはオブジェクト生成部230にオブジェクトを生成させる機能を有する。
オブジェクト参照検出部120は、GCフラグがONである場合に限って、命令実行部110により実行されるスレッド内の命令が、オブジェクトのオブジェクトポインタを処理対象とする命令であるときに、そのオブジェクトポインタを、オブジェクト参照情報330のメモリ領域の中に格納する機能を有する。
オブジェクト管理部200におけるオブジェクト生成部230は、いわゆるクラスファイル等のオブジェクトの定義情報を参照して、従来のOSのメモリ管理機構に対して、オブジェクトに必要な量のメモリ領域の確保を要求することを通じて、メモリ内にオブジェクトを生成する機能を有する。なお、GCシステム10は、メモリ管理ユニット(MMU)を利用して物理的なメモリを論理アドレス空間に対応付け、メモリの確保及び解放を管理する従来のOSのメモリ管理機構をも含んでおり、このメモリ管理機構は、ある量のメモリ領域の確保が要求されると、論理アドレス空間内の未使用領域のうち、要求された量のメモリ領域を確保したものとして管理し、その確保したメモリ領域の先頭アドレスを返却する機能を有している。従って、オブジェクト生成部230は、メモリ管理機構を通じて、オブジェクトに対応する論理アドレス空間内の領域を確保することにより、メモリ内にオブジェクトを生成する。
なお、この論理アドレス空間には、インタプリタ部100により実行される、Java言語等で作成されたAPにおけるオブジェクト以外に、インタプリタ部100を介さず従来の一般的なOSの直接制御下で実行されるプログラムのデータ、つまり例えばコンパイラ等により既に実行形式にされているプログラムに係るデータ(以下、「Nativeデータ」という。)も配置される。このインタプリタ部100を介さずに実行可能な形式のプログラムが、Nativeデータを配置するために従来のOSのメモリ管理機構を通じてメモリ領域を確保し、そこにNativeデータを配置するのと同様の仕組みで、オブジェクト生成部230により生成されるオブジェクトについてのメモリ領域の確保はなされる。
かかるNativeデータやそれに係るプログラムは、GCシステム10の特徴となるGCの動作とは直接関係しないので、ここでは詳しい説明を省略する。
なお、上述したAPスレッドとは、インタプリタ部100を介して実行されるAPの実行単位となるスレッドをいい、つまりNativeデータに係るプログラムの実行単位となるスレッド以外のスレッドをいう。また、ここでいうオブジェクトにはNativeデータは含まれない。
テーブル切替部240は、fromテーブルを指すものとして用いられているポインタとtoテーブルを指すものとして用いられているポインタとを交換することにより、瞬時にfromテーブルの内容とtoテーブルの内容とを交換したに等しい効果を生じさせる機能を有する。
スレッド管理部300におけるスレッド制御部310は、マルチスレッド制御を行い、APを構成する各APスレッド及びGC処理のスレッドを含む各スレッドを並列的に実行する。即ち、スレッド制御部310は、微小時間毎に各スレッドを切り替えて実行する。なお、スレッド管理部300は、Nativeデータに係るプログラムのスレッドも並列的に実行するが、このマルチスレッド制御の機能は、基本的に従来のOS等が有する機能であり、GCシステム10の特徴となるGCの動作とは直接関係しないので、ここでは、主に、APスレッド及びGC処理のスレッドにのみ着目して説明する。
GC部400におけるスレッド選定条件記憶部420は、参照処理を行う対象となるAPスレッドを選択するための条件を示すスレッド選定条件を記憶しているメモリ領域である。
参照処理部430は、参照処理を行う機能を有し、解放部440は、マーク付与がなされていないオブジェクトの解放、即ち、GCの終了段階においてfromテーブル221に残存しているオブジェクトポインタが指すオブジェクトに対応するメモリ領域を解放する機能を有する。このメモリ領域の解放は、オブジェクトポインタつまりオブジェクトの論理アドレスを指定して、MMUを利用した従来のOSのメモリ管理機構に対する解放要求を行うことにより実現される。なお、GCシステム10に含まれる従来のOSのメモリ管理機構は、論理アドレスを指定した解放要求に対して、その論理アドレスと対応付けて管理している確保領域を、新たにメモリを確保する必要がある際に割り当てることができる未使用領域として管理する。
また、GC制御部410は、GC制御処理を実行する機能を有する。即ち、GC制御部410は、スレッド選定条件を参照することにより、参照処理の対象にするAPスレッドを1つ選定し、選択したAPスレッドについて、スレッド制御部310にそのAPスレッドを停止させてから、参照処理部430にそのAPスレッドに対応するスタック及びオブジェクト参照情報に基づいて参照処理を行わせ、その後にスレッド制御部310に選択したAPスレッドの停止を解除させてから、次のAPスレッドの選択を行うという手順を、未処理のAPスレッドが存在しなくなるまで繰り返してから、解放部440に、マーク付与がなされていないオブジェクトの解放を行わせる機能を有する。
<1−2.データ>
以下、GCシステム10において取り扱われるデータについて説明する。
図2は、オブジェクトとオブジェクトポインタとの関係を例示する図である。
同図では、オブジェクトポインタを、小さい塗り潰し円で表現している。
オブジェクトを指すつまりメモリ500に対応する論理アドレス空間に配置されたオブジェクトの所在位置を指すオブジェクトポインタは、オブジェクト内、スタック内、又は共有オブジェクト管理情報353内に存在し得る。ここで、共有オブジェクト管理情報353は、APの実行環境としての仮想マシンにおいて必要なため確保されているオブジェクト群に対するオブジェクトポインタ群を含むデータである。
図2の例では、共有オブジェクト管理情報353内のあるオブジェクトポインタがオブジェクト201cを指している。
また、APスレッド351に対応するスタック内のあるオブジェクトポインタは、オブジェクト201aを指しており、つまり、オブジェクト201aのメモリアドレスを内容としており、また別のオブジェクトポインタは、オブジェクト201dを指している。従って、APスレッド351は、実行中にこれらのオブジェクトポインタを参照することによりオブジェクト201a、オブジェクト201dにアクセス可能な状態である。
また、APスレッド352に対応するスタック内のあるオブジェクトポインタは、オブジェクト201bを指しており、オブジェクト201b内のデータとして、オブジェクト201eを指すオブジェクトポインタが含まれている。従って、APスレッド352は、これらのオブジェクトポインタを辿ることによりオブジェクト201eにアクセス可能な状態である。
また、図2は、インタプリタ部100を介して実行されるJava言語等で作成されたAPに対応するオブジェクト201a〜201e以外にも、同じくOSのメモリ管理機構により領域が確保されたものであるNativeデータ501a〜501dがメモリ500内に混在していることをも表している。即ち、オブジェクト201a〜201eは、まとめて、ある種のヒープ領域中に置かれているのではなく、各Nativeデータと同様に、OSのメモリ管理機構によりそれぞれ個別に領域が割り当てられている。
なお、図2には示さなかったが、スレッド情報320、スタック340及びオブジェクト参照情報330もメモリ500内に確保されるものであり、また、オブジェクト管理情報記憶部210は、メモリ500中の一部に相当する。なお、インタプリタ部100を介して実行されるAPのプログラム部分や、Nativeデータにアクセスするプログラム部分は、読み書き可能なメモリ(RAM)中に置かれるものとしても、読み出しだけ可能なメモリ(ROM)に置かれるものとしてもよい。
図3は、fromテーブル及びtoテーブルを示す図である。
メモリ500内のオブジェクト管理情報記憶部210内に、オブジェクトポインタ又はnull値を十分な数だけ格納するための2つのテーブルが設けられており、また、fromテーブルポインタ211及びtoテーブルポインタ212が存在する。fromテーブルポインタ211は、その2つのテーブルのうち一方を指すポインタであり、toテーブルポインタ212は、他方を指すポインタである。ここでは、現時点でfromテーブルポインタ211が指しているテーブルをfromテーブルと称しており、toテーブルポインタ212が指しているテーブルをtoテーブルと称している。
fromテーブル221は、GC開始時点においては、その時に存在する全オブジェクトに対する全オブジェクトポインタを格納している。
また、toテーブル222は、参照処理の過程でfromテーブル221内から移動してオブジェクトポインタを格納するテーブルである。なお、fromテーブル221中のオブジェクトポインタがtoテーブル222へと移動されるときには、そのオブジェクトポインタが格納されていたfromテーブル221内の位置にあたるメモリ内容はnull値にされる。
図4A及び図4Bは、参照処理によるfromテーブル及びtoテーブルの内容の変化を示すための図であり、図4Aは参照処理開始前の状態を示し、図4Bは参照処理後の状態を示す。
図4Aでは、参照処理開始前におけるfromテーブル221xは、objA202a、objB202b、objC202cのそれぞれのオブジェクトを指すオブジェクトポインタを含んでいる。なお、図4A及び図4Bでは、各オブジェクトとNativeデータとがメモリ500内に混在していることをも表現している。
その後にAPスレッド354を対象として参照処理が行われた場合には、APスレッド354のスタック内に含まれているオブジェクトポインタと同値のものがfromテーブルからtoテーブルに移動され、その結果として図4Bに示す状態になる。fromテーブル221yでは、objA202aを指していたオブジェクトポインタの存在した場所と、objC202cを指していたオブジェクトポインタの存在した場所との両方がnull値に更新されており、toテーブル222yには、objA202aを指すオブジェクトポインタと、objC202cを指すオブジェクトポインタとが格納されている。
図5は、スレッド情報、スタック及びオブジェクト参照情報を示す図である。
スレッド情報320は、APスレッド毎に、そのスレッド生成時に生成され、そのAPスレッドについての情報を含むものであり、具体的には、状態321、優先度322、スタックポインタ323、GC開始時スタックポインタ324、GCフラグ325、オブジェクト参照情報先頭ポインタ326及びオブジェクト参照情報カレントポインタ327を含む。なお、APスレッド生成時には、スレッド情報320のメモリ領域のみならずスタック340のメモリ領域も確保される。
スレッド情報320における状態321は、マルチスレッド制御のためのスレッド状態を示す情報であり、wait状態、run状態、ready状態等の別を示す。
優先度322は、スレッドの優先度を示す情報であり、優先度は例えばスレッド生成時にAPからの指定を受けて定まる。なお、マルチスレッド制御において優先度が高いスレッドがready状態であればそれより優先度の低いスレッドよりも優先的にrun状態にされる。
スタックポインタ323は、該当のスレッドについてのスタック内における現在の有効なデータ範囲の終端を示すものである。なお、マルチスレッド制御において、スレッドがrun状態から、他の状態つまり停止した状態に切り替えられる際に、それまでスタックポインタを指す所定レジスタに格納されていた値がこのスタックポインタ323に格納され、スレッドがrun状態に切り替えられる際に、このスタックポインタ323内の値がその所定レジスタに設定される。
GC開始時スタックポインタ324は、GC開始時におけるスタック内における有効なデータ範囲の終端を示すものである。
GCフラグ325は、GC処理全体の開始時点でONにされ、そのAPスレッドに対しての参照処理が終了するとOFFにされる。
オブジェクト参照情報先頭ポインタ326は、該当APスレッドに対応するオブジェクト参照情報のメモリ領域の先頭を示すものであり、APスレッド生成の際のそのメモリ領域確保時に設定される。
また、オブジェクト参照情報カレントポインタ327は、該当APスレッドに対応するオブジェクト参照情報のメモリ領域において、オブジェクト参照検出部120が次にオブジェクトポインタを格納すべき位置を示す情報であり、オブジェクト参照検出部120よって参照及び更新される。
図6は、参照処理とAPスレッドの状態との関係を示す図である。
GCスレッド356は、GC制御部410によるGCを実行するスレッドであり、GCとして各APスレッドを順番に対象として参照処理を行う。ここでは、APスレッド355a、APスレッド355b、APスレッド355cの順に参照処理が行われる場合の例を示している。
APスレッド355aは、参照処理がなされた後の状態であり、実行中である。ここでいう実行中は、sleep状態つまり停止状態ではないことであり、各瞬時においてはrun状態やready状態等と変化し得る。
APスレッド355bは、参照処理がなされているところの状態であり、停止している。参照処理は、APスレッドを強制的に停止状態にして、スタック及びオブジェクト参照情報を参照して行われる。
APスレッド355cは、参照処理が未だなされていない状態であり、実行中である。
図7は、スレッド選定条件の内容を示す図である。
スレッド選定条件421は、どのAPスレッドを優先して参照処理の対象とするかの判断基準となる情報であり、スレッド状態422、スレッド優先度423及びスタックサイズ424から構成される。
スレッド状態422は、どの状態のAPスレッドを優先するかを示す情報であり、図7の例はwait状態のAPスレッドを、run状態等のAPスレッドより優先する旨を示している。
スレッド優先度423は、APスレッドについて定められている優先度の高いものを参照処理の対象として優先的に選定するか、又は低いものを優先的に選定するかを示す情報であり、図7の例では優先度の低いものを優先的に選定する旨を示している。
また、スタックサイズ424は、APスレッドに対応するスタック領域の有効範囲の大きさが、大きいところのAPスレッドを優先的に選定するか、又は小さいところのAPスレッドを優先的に選定するかを示す情報であり、図7の例ではスタック領域の有効範囲の大きさが小さいものを優先的に選定する旨を示している。
<1−3.動作>
以下、GCシステム10の動作について説明する。
図8は、GC制御処理を示すフローチャートである。
GC制御処理は、タイマーに基づき一定周期で行われる。
GC制御部410は、最初に、fromテーブルポインタ211とtoテーブルポインタ212の内容を交換することにより、fromテーブルとtoテーブルとの内容を切り替える(ステップS11)。これにより、現在解放されていない全てのオブジェクトを指す全てのオブジェクトポインタがfromテーブルに格納されている状態になる。
続いて、GC制御部410は、スレッド制御部310に全APスレッドを停止させ(ステップS12)、全APスレッドについてのスレッド情報中のGCフラグ325をONにし、現在のスタックポインタをスレッド情報中のGC開始時スタックポインタ324に設定し(ステップS13)、スレッド制御部310に全APスレッドの停止を解除させる(ステップS14)。ステップS13においては、更に、APスレッド毎に、オブジェクト参照情報のメモリ領域を確保し、そのメモリ領域の先頭を指すポインタをオブジェクト参照情報先頭ポインタ326及びオブジェクト参照情報カレントポインタ327に設定する。
なお、スレッド制御部310は、従来のOSのマルチスレッド制御機構と同様の方式によりスレッドの停止及び停止解除を行う。このスレッドの停止は、スレッドを停止状態、即ちsleep状態にする制御であり、スレッドの停止解除とは、sleep状態を解除して、ready状態に戻す制御である。
ステップS14に続いて、GC制御部410は、共有オブジェクト管理情報353内のオブジェクトポインタを辿ることで到達するオブジェクトに対するマーク付与を行うための共有オブジェクト参照処理を行い(ステップS15)、GC未処理スレッドつまり未だ参照処理の対象として選定されていないAPスレッドが存在するか否かを判定する(ステップS16)。なお、共有オブジェクト参照処理については後述する。
ステップS16においてGC未処理スレッドが存在すると判定した場合には、GC制御部410は、参照処理の対象となるAPスレッドを決定するための対象スレッド決定処理を行い(ステップS17)、スレッド制御部310にその決定したAPスレッドを停止させ(ステップS18)、その決定したAPスレッドに関しての参照処理を内容とする対象スレッド参照処理を実行し(ステップS19)、その決定したAPスレッドのGCフラグ325をOFFにし(ステップS20)、スレッド制御部310にその決定したAPスレッドの停止を解除させて(ステップS21)、再度、ステップS16の判定に戻る。なお、対象スレッド決定処理及び対象スレッド参照処理については、後述する。また、ステップS20の直後に、GC制御部410は、対象のAPスレッドに対応するオブジェクト参照情報のメモリ領域を解放する。
また、ステップS16において、GC未処理スレッドが存在しないと判定した場合には、GC制御部410は、解放部440にマーク付与がなされていないオブジェクトを解放させ(ステップS22)、GC制御処理を終える。ステップS22においては、解放部440は、参照処理によってtoテーブルにオブジェクトポインタが移行されていないところのオブジェクト、つまりfromテーブルに残存しているオブジェクトポインタが指すオブジェクトに対応するメモリ領域を解放する。この解放は、オブジェクト生成部230が、オブジェクト生成のためにオブジェクトに割り当てるためのメモリ領域を、MMUを利用したOSのメモリ管理機構に基づき確保することに対応し、その確保されたメモリ領域の解放を意味する。なお、この解放されたメモリ領域は、メモリ管理機構により、新たにオブジェクトやNativeデータの格納域として割り当てられ得るようになる。
図9は、対象スレッド決定処理を示すフローチャートである。
GC制御部410は、スレッド選定条件記憶部420内のスレッド選定条件421を参照して、対象スレッド決定処理を行う。
まず、GC制御部410は、各APスレッドに対応するスレッド情報を参照して、状態321がwait状態のAPスレッドを検索する(ステップS31)。この検索結果のスレッド数を判定し(ステップS32)、1であれば、その検索結果のAPスレッドを参照処理の対象スレッドとして決定し(ステップS37)、対象スレッド決定処理を終える。
また、ステップS32において検索結果のスレッド数が0であれば、GC制御部410は、スレッドの優先度322が最も低いAPスレッドを検索し(ステップS33)、検索結果のスレッド数は1か否かを判定する(ステップS35)。また、ステップS32において検索結果のスレッド数が2以上であれば、検索結果のAPスレッドの中から更に絞り込むため、スレッドの優先度322が最も低いAPスレッドを検索し(ステップS34)、検索結果のスレッド数は1か否かを判定する(ステップS35)。
ステップS35においてスレッド数が1と判定した場合には、GC制御部410は、その検索結果のAPスレッドを参照処理の対象スレッドとして決定し(ステップS37)、対象スレッド決定処理を終える。
また、ステップS35において、検索結果のスレッド数が1でないと判定した場合、即ち、最も低い優先度のAPスレッドが複数存在した場合には、GC制御部410は、検索結果のAPスレッドの中からスタックサイズが最小のAPスレッドを検索し(ステップS36)、スタックサイズが最小のAPスレッドを参照処理の対象スレッドとして決定し(ステップS37)、対象スレッド決定処理を終える。
図10は、共有オブジェクト参照処理を示すフローチャートである。
GC制御部410は、オブジェクトポインタ群を含む共有オブジェクト管理情報353の先頭のオブジェクトポインタに着目して(ステップS41)、参照処理部430に参照処理(ステップS42)を行わせることにより、APの実行環境としての仮想マシンにおいて必要なため確保されているオブジェクト群全てにマーク付与を行う。
図11は、対象スレッド参照処理を示すフローチャートである。
GC制御部410は、対象スレッドに対応するスレッド情報中のGC開始時スタックポインタ324が指す位置に着目し(ステップS51)、参照処理部430に参照処理(ステップS52)を行わせることにより、スタック領域内のオブジェクトポインタから辿ることのできる全てのオブジェクトへのマーク付与を行う。なお、GC制御処理(図8参照)の開始時点と、この対象スレッド参照処理を開始する時点は異なるため、GC開始時スタックポインタ324が指す位置とそれに続く各位置の内容は、GC開始時点とは異なっているが、後続するステップS53及びステップS54によって、GC開始以後に、対象スレッドの動作によって変化したオブジェクトポインタから辿ることのできる全てのオブジェクトへのマーク付与が行われるので、過剰にマーク付与をする場合はあり得るが、参照されているにも関わらずマーク付与が漏れるという事態は生じない。
続いて、GC制御部410は、オブジェクト参照情報先頭ポインタ326の指す位置に着目し(ステップS53)、参照処理部430に参照処理(ステップS54)を行わせ、対象スレッド参照処理を終える。
図12は、参照処理を示すフローチャートである。
参照処理部430は、着目されているメモリ位置から、オブジェクトポインタを検索し(ステップS61)、オブジェクトポインタを検出したか否かを判定し(ステップS62)、検出した場合にはその検出したオブジェクトポインタと同値のオブジェクトポインタがfromテーブルに存在するか否かを判定し(ステップS64)、fromテーブルに存在すれば、fromテーブルからtoテーブルにそのオブジェクトポインタをコピーして、fromテーブル内のそのオブジェクトポインタが存在していた位置にnull値を記録し(ステップS66)、そのオブジェクトポインタが指すオブジェクトのデータ先頭に着目し(ステップS67)、再度ステップS61に戻る。
また、ステップS64において、fromテーブルにはそのオブジェクトポインタが存在しないと判定した場合には、既にfromテーブルからtoテーブルに移されているため、参照処理部430は、着目している位置の次の位置に着目し(ステップS65)、再度ステップS61に戻る。ステップS65及びステップS61の組み合わせにより、共有オブジェクト管理情報353内のオブジェクトポインタを次々と検索することや、スタック内のオブジェクトポインタを次々と検索することや、オブジェクト参照情報内のオブジェクトポインタを次々と検索することや、あるオブジェクト内のデータメンバとしてのオブジェクトポインタを次々と検索すること等が実現される。
また、ステップS62においてオブジェクトポインタを検出できなかったと判定した場合には、参照処理部430は、着目位置がオブジェクト内であるか否かを判定する(ステップS63)。なお、オブジェクトポインタを検出できなかったというのは、着目位置が共有オブジェクト管理情報353内であればその共有オブジェクト管理情報353内においてオブジェクトポインタを検出できなかったということであり、着目位置がスタック内であればスタック内においてオブジェクトポインタを検出できなかったということであり、着目位置がオブジェクト参照情報内であればそのオブジェクト参照情報内においてオブジェクトポインタを検出できなかったということであり、着目位置がオブジェクト内であればそのオブジェクト内においてオブジェクトポインタを検出できなかったということである。
ステップS63において着目位置がオブジェクト内であると判定した場合には、参照処理部430は、そのオブジェクト内に着目前の着目位置の次位置に着目し(ステップS68)、再度ステップS61に戻る。このステップS68によって、参照処理部430は、ステップS67によってオブジェクト内に着目する前に着目していたオブジェクトポインタの次の位置に着目することになる。
また、ステップS63において着目位置がオブジェクト内ではないと判定した場合には、参照処理部430は、参照処理を終える。
図13は、命令実行処理を示すフローチャートである。
インタプリタ部100における命令実行部110は、run状態にされたAPスレッドにおけるプログラム中の命令記述を逐次解釈して実行する命令実行処理を行う。
まず、命令実行部110は、APスレッドの現在の実行位置における命令を解釈して実行し(ステップS71)、オブジェクト参照検出部120は、そのAPスレッドに対応するスレッド情報中のGCフラグ325がONであるか否かを判定し(ステップS72)、ONでなければ、命令実行部110が次の命令の解釈実行を行う(ステップS71)。
ステップS72において、GCフラグ325がONであると判定した場合には、オブジェクト参照検出部120は、ステップS71において命令実行部110により実行された命令が、オブジェクトポインタを処理対象とする命令であったか否かを判定し(ステップS73)、オブジェクトポインタを処理対象とする命令でなかったならば、命令実行部110が次の命令の解釈実行を行う(ステップS71)。なお、オブジェクトポインタを処理対象とする命令とは、スタック内のオブジェクトポインタをオブジェクト内にコピーする演算を指示内容とする命令や、オブジェクト内のオブジェクトポインタを他のオブジェクト内にコピーする演算を指示内容とする命令である。
ステップS73において、オブジェクトポインタを処理対象とする命令であったと判定した場合には、オブジェクト参照検出部120はそのオブジェクトポインタと同値のものがオブジェクト参照情報領域に既に格納済みであるか否かを判定し(ステップS74)、格納済みである場合には、命令実行部110が次の命令の解釈実行を行う(ステップS71)。
ステップS74において、そのオブジェクトポインタと同値のものがオブジェクト参照情報のメモリ領域に格納済みでない場合には、オブジェクト参照検出部120は、そのオブジェクトポインタを、オブジェクト参照情報カレントポインタ327が指すオブジェクト参照情報中の位置に格納し(ステップS75)、そのオブジェクトポインタの指すオブジェクトに着目して、オブジェクトチェーン追跡処理(ステップS76)を行い、その後は命令実行部110が次の命令の解釈実行を行う(ステップS71)。
なお、ステップS71における実行対象とされる命令がオブジェクトを生成する命令である場合には、命令実行部110は、オブジェクト生成部230にオブジェクトの生成を指示し、これを受けてオブジェクト生成部230は、オブジェクトを生成するとともにそのオブジェクトを指すオブジェクトポインタをAPスレッドに対して返却し、そのオブジェクトポインタのコピーをtoテーブル内に設定する。
図14は、オブジェクトチェーン追跡処理を示すフローチャートである。
オブジェクト参照検出部120は、着目しているオブジェクトに未着目のオブジェクトポインタが存在するか否かを判定し(ステップS81)、存在する場合には、その未着目の1つのオブジェクトポインタに着目し(ステップS82)、その着目したオブジェクトポインタをオブジェクト参照情報のメモリ領域に格納し(ステップS83)、その着目したオブジェクトポインタの指すオブジェクトに着目して更にオブジェクトチェーン処理(ステップS81〜S84)を行う(ステップS84)。なお、オブジェクトポインタをオブジェクト参照情報のメモリ領域に格納したときには、オブジェクト参照検出部120は、オブジェクト参照情報カレントポインタをそのオブジェクトポインタのサイズ分だけ進める。
また、ステップS81において、着目しているオブジェクトに未着目のオブジェクトポインタが存在していないと判定した場合には、オブジェクト参照検出部120は、オブジェクトチェーン追跡処理を終える。
従って、この命令実行処理及びオブジェクトチェーン追跡処理によって、GCフラグ325がONである場合において、オブジェクトポインタが処理対象とされたときにはそのオブジェクトポインタから辿ることのできるオブジェクトポインタはいずれもオブジェクト参照情報のメモリ領域に格納されることになる。
なお、APスレッドによるオブジェクトポインタを処理対象とする演算の実行によって、そのオブジェクトポインタで指されていたオブジェクトにそのAPスレッドからアクセスすることが不可能な状態となった場合、つまり、APスレッドの動作により、(a)オブジェクトポインタがクリアされた場合、(b)オブジェクトポインタが他の内容に更新された場合、或いは、(c)オブジェクトポインタがスタック領域の有効範囲内に存在する場合においてスタックポインタの変更がなされてスタック領域の有効範囲外となりAPスレッドから基本的にアクセス不能となった場合にも、そのAPスレッドによって予めそのオブジェクトポインタが他のAPスレッドからはアクセス可能な場所にコピーされていたならば、そのオブジェクトポインタで指されるオブジェクトにはマーク付与が必要となるので、そのために、上述したステップS72〜S76、ステップS81〜S84の処理が行われる。
<2.実施形態2>
以下、本発明の実施形態2に係るGCシステムについて図面を用いて説明する。
実施形態2に係るGCシステムは、APスレッドを順次停止して参照処理を行う点で、実施形態1に係るGCシステム10と基本的に同様である。ただし、実施形態2に係るGCシステムは、主に、APスレッド毎にオブジェクト参照情報やGCフラグを有するのではなくシステム全体でまとめてオブジェクト参照情報やGCフラグを有する点や、スレッド情報の内容を一般的なマルチスレッド制御に要する程度に縮小している点が、GCシステム10と異なる。
図15は、本発明の実施形態2に係るGCシステムの機能ブロック図である。
図15に示すGCシステム20の構成要素のうち、実施形態1で示したGCシステム10と同様の構成要素については、図1と同じ符号を付しており、ここではGCシステム20に特有の点を中心に説明する。なお、特に説明しない点については、GCシステム20はGCシステム10と同様である。
GCシステム20は、図15に示すように、インタプリタ部1100、オブジェクト管理部200、スレッド管理部1300及びGC部1400を備える。
ここで、インタプリタ部1100は、基本的にインタプリタであってAPを実行する機能を担い、命令実行部110及びオブジェクト参照検出部1120を有する。
スレッド管理部1300は、マルチスレッド制御を行いスレッドを管理する機能を担い、スレッド制御部310と、APスレッド毎に、スレッド情報1320及びスタック340に対応するメモリ領域を有する。なお、スレッド情報1320は、図16に示すように状態321、優先度322及びスタックポインタ323を含むものである。
GC部1400は、基本的にいわゆるガーベジコレクタに相当し、GC制御部1410と、スレッド選定条件記憶部420と、参照処理部1430と、解放部440と、オブジェクト参照情報1450及びGCフラグ1460に対応するメモリ領域とを有する。
インタプリタ部1100におけるオブジェクト参照検出部120は、GCフラグ1460がONである場合に限って、命令実行部110により実行されるAPスレッド内の命令が、オブジェクトのオブジェクトポインタを処理対象とする命令であるときに、そのオブジェクトポインタを、オブジェクト参照情報1450のメモリ領域の中に格納する機能を有する。
GC部1400を中心として行われるGCは、基本的にマークアンドスイープ方式を用い、参照処理の対象となるAPスレッドを順番に選択して、選択したAPスレッドを停止させて参照処理を行ってからその停止を解除する方式のものである。
GC部1400における参照処理部1430は、スタック及びオブジェクト参照情報1450を参照することにより参照処理を行う機能を有する。オブジェクト参照情報1450は、GCシステム10におけるオブジェクト参照情報と同様にオブジェクトポインタを内容とする情報であるが、APスレッド毎に存在するのではない。このオブジェクト参照情報1450のメモリ領域には、全APスレッドについてのオブジェクト参照検出部1120により、オブジェクトポインタが命令の処理対象とされた場合にそのオブジェクトポインタが格納される。なお、スレッド情報1320、スタック340、オブジェクト参照情報1450、GCフラグ1460は、オブジェクトやNativeデータと同様に、オブジェクト管理情報記憶部210を含むメモリに格納される。
また、GC制御部1410は、図17に示すGC制御処理を実行する機能を有する。
図17は、実施形態2におけるGC制御処理を示すフローチャートである。なお、このフローチャート中の処理ステップのうち、実施形態1のGC制御処理と同様のものについては、図8と同じ符号を付して示している。
このGC制御処理は、タイマーに基づき一定周期で行われる。
GC制御部1410は、最初に、fromテーブルポインタ211とtoテーブルポインタ212の内容を交換することにより、fromテーブルとtoテーブルとの内容を切り替え(ステップS11)、GCフラグ1460をONにする(ステップS111)。
ステップS111に続いて、GC制御部1410は、共有オブジェクト管理情報353内のオブジェクトポインタを辿ることで到達するオブジェクトに対するマーク付与を行うための共有オブジェクト参照処理を行い(ステップS15)、GC未処理スレッドつまり未だ参照処理の対象として選定されていないAPスレッドが存在するか否かを判定する(ステップS16)。
ステップS16においてGC未処理スレッドが存在すると判定した場合には、GC制御部1410は、参照処理の対象となるAPスレッドを決定するための対象スレッド決定処理を行い(ステップS17)、スレッド制御部310にその決定したAPスレッドを停止させ(ステップS18)、その決定したAPスレッドに対応するスタックポインタの位置に着目して(ステップS112)、参照処理部1430に参照処理(図12参照)を実行させ(ステップS113)、スレッド制御部310にその決定したAPスレッドの停止を解除させて(ステップS21)、再度、ステップS16の判定に戻る。
また、ステップS16において、GC未処理スレッドが存在しないと判定した場合には、GC制御部1410は、スレッド制御部310に全APスレッドを停止させ(ステップS114)、オブジェクト参照情報1450のメモリ領域の先頭位置に着目し(ステップS115)、参照処理部1430に参照処理を実行させ(ステップS116)、GCフラグ1460をOFFにし(ステップS117)、スレッド制御部310に全APスレッドの停止を解除させ(ステップS118)、解放部440にマーク付与がなされていないオブジェクトを解放させ(ステップS22)、GC制御処理を終える。
ここで、インタプリタ部1100によりなされる命令実行処理について簡単に説明する。
図18は、実施形態2における命令実行処理を示すフローチャートである。
同図に示すように、この命令実行処理は、図13で示した命令実行処理からステップS76を削除したものと基本的に等しい。
まず、命令実行部110は、APスレッドの現在の実行位置における命令を解釈して実行し(ステップS71)、オブジェクト参照検出部1120は、GCフラグ1460がONであるか否かを判定し(ステップS72)、ONでなければ、命令実行部110が次の命令の解釈実行を行う(ステップS71)。
ステップS72において、GCフラグ325がONであると判定した場合には、オブジェクト参照検出部1120は、ステップS71において命令実行部110により実行された命令が、オブジェクトポインタを処理対象とする命令であったか否かを判定し(ステップS73)、オブジェクトポインタを処理対象とする命令でなかったならば、命令実行部110が次の命令の解釈実行を行う(ステップS71)。
ステップS73において、オブジェクトポインタを処理対象とする命令であったと判定した場合には、オブジェクト参照検出部1120はそのオブジェクトポインタと同値のものがオブジェクト参照情報領域に既に格納済みであるか否かを判定し(ステップS74)、格納済みである場合には、命令実行部110が次の命令の解釈実行を行う(ステップS71)。
ステップS74において、そのオブジェクトポインタと同値のものがオブジェクト参照情報のメモリ領域に格納済みでない場合には、オブジェクト参照検出部1120は、そのオブジェクトポインタを、オブジェクト参照情報中の位置に格納し(ステップS75)、その後は命令実行部110が次の命令の解釈実行を行う(ステップS71)。
このようにしてGC制御部1410は、スレッド選定条件を参照することにより、参照処理の対象にするAPスレッドを1つ選定し、選択したAPスレッドについて、スレッド制御部310にそのAPスレッドを停止させてから、参照処理部1430にそのAPスレッドに対応するスタックに基づいて参照処理を行わせ、その後にスレッド制御部310に選択したAPスレッドの停止を解除させてから、次のAPスレッドの選択を行うという手順を、未処理のAPスレッドが存在しなくなるまで繰り返し、その後、スレッド制御部310に全APスレッドを停止させ、参照処理部1430にオブジェクト参照情報に基づいて参照処理を行わせて、スレッド制御部310に全APスレッドの停止を解除させて、解放部440に、マーク付与がなされていないオブジェクトの解放を行わせる。
<3.考察>
以下、上述の本発明に係るGCシステムが管理するオブジェクトと、従来のJava実行環境におけるガーベジコレクタ等により扱われるオブジェクト(以下、特に「Javaオブジェクト」という。)とのメモリ領域の差異について簡単に対比説明を行う。
上述の実施形態1、2に示した本発明に係るGCシステムでは、プログラマに確保したメモリの解放を意識させないようなJava言語等のオブジェクト指向言語により作成されたAPを実行する際におけるオブジェクトの生成時のメモリ確保と、GC処理におけるそのオブジェクトに対応するメモリの解放とを、MMUを利用した従来のOSのメモリ管理機構を通じて行う。これにより、オブジェクトに対して確保されるメモリ領域は、Nativeデータ、つまり他の言語、例えばC言語等、により作成されたプログラムのデータに対して確保されるメモリ領域と、論理アドレス空間において混在する。図3では、この混在するイメージを表現している。
これに対して、従来のJava実行環境により管理されたJavaオブジェクトと、ここではC言語のプログラムにおけるデータ(以下、「Cデータ」という。)とのメモリにおける存在状況を示した図が図19である。
図19に示すように、各C言語のプログラム953、954は、Cデータ921、922のためのメモリ領域をOSのメモリ管理機構を通じて、ランダムアクセスメモリ(RAM)900内に確保する。
また、各Javaプログラム951、952から生成される各Javaオブジェクト911〜913は、1つのヒープ領域910内に確保され、そのヒープ領域910内での配置の管理は、OSによってではなく、ガーベジコレクタ950を含むJava実行環境によって行われる。このため、Java実行環境は、まずOSのメモリ管理機構を通じてヒープ領域を確保しておいて、オブジェクトを生成する際には、そのヒープ領域内の一領域をそのオブジェクトに対して割り当てる。このヒープ領域は、他の言語のプログラムが利用できるメモリ量を減らしてしまう。
また、Java実行環境は、オブジェクトを解放する場合には、ヒープ領域内のそのオブジェクトに割り当てられていた領域を、新たにオブジェクトに対して割り当てられ得る未使用領域として管理するが、ヒープ領域内において断片化した全未使用領域を連続させるためのいわゆるメモリコンパクション処理を随時行う必要がある。
なお、この点、実施形態1、2に示した本発明に係るGCシステムでは、ヒープ領域の確保及びその内部の管理を行うのではなく、オブジェクトに対するメモリ割り当てを直接的に、MMUを利用した従来のOSのメモリ管理機構を通じて行っているため、当然ながらヒープ領域内のメモリコンパクション等は不要となる。
<4.補足>
以上、本発明に係るGCシステムについて、実施形態1、2に基づいて説明したが、本発明は、勿論これらの実施形態に限られない。以下、実施形態の変形に関して説明する。
(1)スレッド選定条件は、スレッド状態、スレッド優先度、スタックサイズという3つの条件をこの順に優先適用されることとしたが、条件数や適用順序等は、これに限定されることはなく、また、例えばスレッド優先度が高いものを条件にしたりスタックサイズが大きいものを条件にしたりしてもよい。
但し、実施形態において示したようにスレッド状態がwait状態のAPスレッドを参照処理対象と選定することは、現在動作しているAPに対する悪影響が少ないという効果につながる。また、参照処理(図12)のアルゴリズムにより、あるAPスレッドに対する参照処理にかかる時間は、参照処理を先に行うAPスレッドより後に行うAPスレッドの方が比較的短くなるため、実施形態において示したようにスレッド優先度が低いものを早めに参照処理対象と選定するようにしておくことで、即応性の求められるところのスレッド優先度の高いAPスレッドの停止時間を短くし得るという効果が生じる。また、同様の理由と、スタックサイズが大きいほど参照処理には時間がかかるという理由とから、対応するスタックサイズの小さいAPスレッドから順に参照処理を行うようにすることで、同じスレッド優先度のAPスレッド間である程度等しくなるようにAPスレッドの停止時間を分散できるという効果が生じる。
(2)実施形態では、GC制御処理がタイマーに基づき一定周期で行われることとしたが、これに限定されることはなく、APに割り当てられる空きメモリの量が所定量より少なくなった場合にGC制御処理を行うようにしてもよい。
(3)実施形態で示したオブジェクト参照情報のメモリ領域は、連続した物理アドレスで表されるメモリ領域であってもよいし、オブジェクトポインタの格納に際して必要が生じた度に一定量のメモリ領域を追加的に確保してその確保した複数の断続的なメモリ領域を論理アドレス上で連続しているように扱うこととしてもよい。
(4)実施形態1で示したGCシステムにおいては、インタプリタによる命令実行処理中に、GCフラグがONであればオブジェクトポインタを処理対象としたときにオブジェクト参照情報のメモリ領域にそのオブジェクトポインタを保存する処理を行っておくこととし、命令実行処理中では、そのオブジェクトポインタと同値のものをfromテーブルからtoテーブルに移行することを内容とする参照処理を行わずインタプリタによる命令実行の高速性を保つようにしたが、命令実行処理中にその参照処理を行うこととしてもよい。
(5)実施形態では共有オブジェクト管理情報内のオブジェクトポインタから辿ることのできるオブジェクトへのポインタは参照処理によってfromテーブルからtoテーブルに移行されることとしたが、参照処理を行わなくても、共有オブジェクト管理情報によって管理されているオブジェクトは解放部による解放対象から除外しさえすればよい。
(6)実施形態で示したGCシステムは、コンピュータ上に実装されるのみならず、CPUを備える携帯端末、家電機器等において実装されることとしてもよい。
(7)実施形態で示したスレッド制御部は、微小時間毎に各スレッドを切り替えて実行することにより各スレッドを並列的に実行、つまり擬似的に並列実行することとしたが、各スレッドをマルチプロセッサにおける複数のプロセッサエレメントによって実際に並列実行することとしてもよい。
(8)実施形態では、オブジェクト生成部により生成される各オブジェクトは、従来のOSのメモリ管理機構により、各Nativeデータと同等に、論理アドレス空間にメモリが割り当てられるものであることとしたが、各オブジェクトは、論理アドレス空間におけるひとかたまりのヒープ領域内に、それぞれメモリが割り当てられるように、特別の管理を行うこととしてもよい。この特別の管理は、ヒープ領域を、従来のOSのメモリ管理機構により確保し、オブジェクトの生成に対応してその内部の未割当領域を各オブジェクトに割り当て、オブジェクトの解放に対応してその内部の領域を未割当領域と定めることにより実現される。この特別の管理をする場合において、更に、ヒープ領域内において断片化した全未割当領域を連続させるためのいわゆるメモリコンパクション処理を随時行う必要がある。なお、このことから、ヒープ領域を利用する方式は、上述の<3.考察>において示したように必ずしも最適なものではない。
(9)実施形態で示したGCシステムは従来のOSのメモリ管理機構を含んでいることとしたが、GCシステムの外部に、そのGCシステムの基盤環境として、MMUを用いてメモリを管理する従来のOSのメモリ管理機構が存在することとし、GCシステムはメモリの確保及び解放をその外部のメモリ管理機構を通じて行うこととしてもよい。
(10)実施形態で示したGCシステムの各機能を実現させるための各種処理(図8〜図14、図17、図18参照)をCPUに実行させるためのプログラムを、記録媒体に記録し又は各種通信路等を介して、流通させ頒布することもできる。このような記録媒体には、ICカード、光ディスク、フレキシブルディスク、ROM等がある。流通、頒布されたプログラムは、CPUを備える装置におけるCPUで読み取り可能なメモリ等に格納されることにより利用に供され、そのCPUがそのプログラムを実行することにより実施形態で示したGCシステムの各機能が実現される。
Claims (14)
- 複数スレッドで構成されるオブジェクト指向プログラムの実行過程において不要になったオブジェクトに対応するメモリ領域を解放するガーベジコレクションシステムであって、
複数スレッドそれぞれを順に選択する選択手段と、
選択されたスレッドについて、当該スレッドの実行を停止して、当該スレッドからオブジェクトポインタの参照を通じてアクセス可能であるオブジェクトを検出して当該検出したオブジェクトを非解放対象として管理して、当該スレッドの実行を再開するという手順からなる検査処理を実施する検査手段と、
前記選択手段による前記選択が開始された後において、実行中のスレッドによりオブジェクトポインタが処理対象にされたことを検知した場合には、当該オブジェクトポインタが指すオブジェクトを非解放対象として管理する検知手段と、
前記複数スレッド全てについて前記検査処理が完了した後において、非解放対象として管理されているオブジェクト以外のオブジェクトに対応するメモリ領域を、解放する解放手段とを備える
ことを特徴とするガーベジコレクションシステム。 - 前記検知手段は、前記検知を、実行中のスレッドについて未だ検査処理がなされていない場合に限り行い、
前記検知手段は、
前記検知をした場合に、当該実行中のスレッドに処理対象にされたオブジェクトポインタ、及び当該オブジェクトポインタから辿ることのできるオブジェクト内のオブジェクトポインタを、当該スレッドに対応する作業用メモリ領域に保存する検出部と、
前記検査手段によりスレッドの実行が停止されている間に、当該スレッドに対応する作業用メモリ領域内のオブジェクトポインタから辿ることのできるオブジェクトを非解放対象として管理する管理部とを有する
ことを特徴とする請求の範囲第1項記載のガーベジコレクションシステム。 - 前記検査処理は、
選択された当該スレッドに対応するスタック内のオブジェクトポインタが指すオブジェクトを、前記アクセス可能であるとして検出した際において、
検出した当該オブジェクトが既に非解放対象として管理されておらず、かつ、当該オブジェクト内にオブジェクトポインタがあるときに限り、当該オブジェクトポインタが指すオブジェクトを更に前記アクセス可能であるとして検出する手順を、
繰り返し行うことを内容とする処理であり、
前記選択手段は、最初の選択後は、前記検査手段により前記検査処理が行われた後において前記複数スレッドのうち前記検査処理を実施されていないスレッドがある限り更なる選択を行い、
前記選択手段は、各スレッドに関する情報を参照し、所定のスレッド選定条件に基づき、前記選択を行う
ことを特徴とする請求の範囲第2項記載のガーベジコレクションシステム。 - 前記スレッド選定条件は、スレッド状態がwait状態であるスレッドをスレッド状態がwait状態以外であるスレッドよりも早期に選択することを示す条件を含み、
前記選択手段は、前記選択を行う時点でwait状態のスレッドがある限り、当該wait状態のスレッドを選択する
ことを特徴とする請求の範囲第3項記載のガーベジコレクションシステム。 - 前記スレッド選定条件は、スレッド優先度のスレッド優先度の低いスレッドをスレッド優先度の高いスレッドよりも早期に選択することを示す条件を含む
ことを特徴とする請求の範囲第4項記載のガーベジコレクションシステム。 - 前記スレッド選定条件は、スレッドに対応するスタックサイズが小さいスレッドをスタックサイズが大きいスレッドよりも早期に選択することを示す条件を含む
ことを特徴とする請求の範囲第5項記載のガーベジコレクションシステム。 - 前記ガーベジコレクションシステムは、メモリ管理ユニット(MMU)を用いてメモリを管理するメモリ管理機構を備え、オブジェクトを生成する必要がある度に、前記メモリ管理機構により当該オブジェクトに対応するメモリ領域を確保し、
前記解放手段は、前記メモリ管理機構を介して、メモリ領域の解放を行う
ことを特徴とする請求の範囲第6項記載のガーベジコレクションシステム。 - 前記スレッド選定条件は、スレッドに対応するスタックサイズが小さいスレッドをスタックサイズが大きいスレッドよりも早期に選択することを示す条件を含む
ことを特徴とする請求の範囲第3項記載のガーベジコレクションシステム。 - 前記スレッド選定条件は、スレッド優先度のスレッド優先度の低いスレッドをスレッド優先度の高いスレッドよりも早期に選択することを示す条件を含む
ことを特徴とする請求の範囲第3項記載のガーベジコレクションシステム。 - 前記ガーベジコレクションシステムは、メモリ管理ユニット(MMU)を用いてメモリを管理するメモリ管理機構を利用するものであり、オブジェクトを生成する必要がある度に、前記メモリ管理機構により当該オブジェクトに対応するメモリ領域を確保し、
前記解放手段は、前記メモリ管理機構を介して、メモリ領域の解放を行う
ことを特徴とする請求の範囲第1項記載のガーベジコレクションシステム。 - コンピュータ上において複数スレッドで構成されるオブジェクト指向プログラムの実行過程において不要になったオブジェクトに対応するメモリ領域を解放するガーベジコレクション方法であって、
複数スレッドそれぞれを順に選択する選択ステップと、
選択されたスレッドについて、当該スレッドの実行を停止して、当該スレッドからオブジェクトポインタの参照を通じてアクセス可能であるオブジェクトを検出して当該検出したオブジェクトを非解放対象として管理して、当該スレッドの実行を再開するという手順からなる検査処理を実施する検査ステップと、
前記選択ステップによる前記選択が開始された後において、実行中のスレッドによりオブジェクトポインタが処理対象にされたことを検知した場合には、当該オブジェクトポインタが指すオブジェクトを非解放対象として管理する検知ステップと、
前記複数スレッド全てについて前記検査処理が完了した後において、非解放対象として管理されているオブジェクト以外のオブジェクトに対応するメモリ領域を、解放する解放ステップとを含む
ことを特徴とするガーベジコレクション方法。 - 前記コンピュータは、メモリ管理ユニット(MMU)を用いてメモリを管理するメモリ管理機構を利用するものであって、オブジェクト指向プログラムの実行過程においてオブジェクトを生成する必要がある度に、前記メモリ管理機構により当該オブジェクトに対応するメモリ領域を確保するものであり、
前記解放ステップは、前記メモリ管理機構を介して、メモリ領域の解放を行う
ことを特徴とする請求の範囲第11項記載のガーベジコレクション方法。 - 複数スレッドで構成されるオブジェクト指向プログラムの実行過程において不要になったオブジェクトに対応するメモリ領域を解放するガーベジコレクション処理をコンピュータに実行させるためのコンピュータプログラムであって、
前記ガーベジコレクション処理は、
複数スレッドそれぞれを順に選択する選択ステップと、
選択されたスレッドについて、当該スレッドの実行を停止して、当該スレッドからオブジェクトポインタの参照を通じてアクセス可能であるオブジェクトを検出して当該検出したオブジェクトを非解放対象として管理して、当該スレッドの実行を再開するという手順からなる検査処理を実施する検査ステップと、
前記選択ステップによる前記選択が開始された後において、実行中のスレッドによりオブジェクトポインタが処理対象にされたことを検知した場合には、当該オブジェクトポインタが指すオブジェクトを非解放対象として管理する検知ステップと、
前記複数スレッド全てについて前記検査処理が完了した後において、非解放対象として管理されているオブジェクト以外のオブジェクトに対応するメモリ領域を、解放する解放ステップとを含む
ことを特徴とするコンピュータプログラム。 - 前記コンピュータは、メモリ管理ユニット(MMU)を用いてメモリを管理するメモリ管理機構を利用するものであって、オブジェクト指向プログラムの実行過程においてオブジェクトを生成する必要がある度に、前記メモリ管理機構により当該オブジェクトに対応するメモリ領域を確保するものであり、
前記解放ステップは、前記メモリ管理機構を介して、メモリ領域の解放を行う
ことを特徴とする請求の範囲第13項記載のコンピュータプログラム。
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2003187690 | 2003-06-30 | ||
JP2003187690 | 2003-06-30 | ||
PCT/JP2004/009043 WO2005001695A1 (ja) | 2003-06-30 | 2004-06-21 | ガーベジコレクションシステム |
Publications (2)
Publication Number | Publication Date |
---|---|
JPWO2005001695A1 true JPWO2005001695A1 (ja) | 2006-08-10 |
JP4569926B2 JP4569926B2 (ja) | 2010-10-27 |
Family
ID=33549730
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2005511067A Expired - Fee Related JP4569926B2 (ja) | 2003-06-30 | 2004-06-21 | ガーベジコレクションシステム |
Country Status (8)
Country | Link |
---|---|
US (1) | US7395285B2 (ja) |
EP (1) | EP1659496B1 (ja) |
JP (1) | JP4569926B2 (ja) |
KR (1) | KR101004483B1 (ja) |
CN (1) | CN100437515C (ja) |
AT (1) | ATE479942T1 (ja) |
DE (1) | DE602004028945D1 (ja) |
WO (1) | WO2005001695A1 (ja) |
Families Citing this family (22)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7174354B2 (en) * | 2002-07-31 | 2007-02-06 | Bea Systems, Inc. | System and method for garbage collection in a computer system, which uses reinforcement learning to adjust the allocation of memory space, calculate a reward, and use the reward to determine further actions to be taken on the memory space |
US7600223B2 (en) * | 2004-10-25 | 2009-10-06 | Microsoft Corporation | Abstracted managed code execution |
JP4769946B2 (ja) * | 2007-02-05 | 2011-09-07 | 国立大学法人京都大学 | メモリ管理方法、メモリ管理装置、及びメモリ管理プログラムが記録されている記録媒体 |
CN101599039B (zh) * | 2008-06-03 | 2011-11-02 | 华为技术有限公司 | 嵌入式c语言环境下异常处理方法及装置 |
US8316064B2 (en) | 2008-08-25 | 2012-11-20 | Emc Corporation | Method and apparatus for managing data objects of a data storage system |
US8291192B2 (en) * | 2008-10-30 | 2012-10-16 | Kyocera Document Solutions, Inc. | Memory management system |
US20100153675A1 (en) * | 2008-12-12 | 2010-06-17 | Microsoft Corporation | Management of Native Memory Usage |
CN101866298B (zh) * | 2009-04-14 | 2013-08-07 | 上海科泰世纪科技有限公司 | 线程托管对象的方法 |
CN102209016B (zh) * | 2010-03-29 | 2014-02-26 | 成都市华为赛门铁克科技有限公司 | 一种数据处理方法、装置和数据处理系统 |
CN101894049A (zh) * | 2010-07-14 | 2010-11-24 | 中兴通讯股份有限公司 | 一种自适应回收垃圾对象的系统及方法 |
CN102023891A (zh) * | 2010-12-20 | 2011-04-20 | 复旦大学 | 基于Java虚拟机的并发垃圾收集器框架 |
US8527560B2 (en) * | 2011-03-29 | 2013-09-03 | Microsoft Corporation | Conservative garbage collecting with concurrent marking and concurrent sweeping for memory management |
US9430164B1 (en) | 2013-02-08 | 2016-08-30 | Emc Corporation | Memory efficient sanitization of a deduplicated storage system |
US9317218B1 (en) | 2013-02-08 | 2016-04-19 | Emc Corporation | Memory efficient sanitization of a deduplicated storage system using a perfect hash function |
JP6078515B2 (ja) * | 2014-11-13 | 2017-02-08 | 京セラドキュメントソリューションズ株式会社 | 電子機器およびプログラム |
US9852046B1 (en) * | 2015-05-07 | 2017-12-26 | Cadence Design Systems, Inc. | Method and system for automated debugging memory allocation and memory release |
CN105739466B (zh) * | 2016-02-29 | 2018-09-04 | 广西升禾环保科技股份有限公司 | 具有垃圾监控功能的用于卫生的运营作业系统 |
CN108459898B (zh) * | 2017-02-20 | 2022-01-14 | 阿里巴巴集团控股有限公司 | 一种资源回收方法及装置 |
US10459656B1 (en) * | 2018-06-25 | 2019-10-29 | International Business Machines Corporation | Method and apparatus to represent activation frame for pause-less garbage collection |
WO2020237621A1 (en) * | 2019-05-31 | 2020-12-03 | Intel Corporation | Avoidance of garbage collection in high performance memory management systems |
CN113449316B (zh) * | 2020-03-27 | 2023-07-18 | 武汉瓯越网视有限公司 | 一种程序的加密解密方法、装置和可读存储介质 |
US11580017B2 (en) * | 2020-04-27 | 2023-02-14 | Silicon Motion, Inc. | Method and apparatus and computer program product for preparing logical-to-physical mapping information for host side |
Family Cites Families (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5930807A (en) * | 1997-04-23 | 1999-07-27 | Sun Microsystems | Apparatus and method for fast filtering read and write barrier operations in garbage collection system |
JP3027845B2 (ja) * | 1997-11-21 | 2000-04-04 | オムロン株式会社 | プログラム制御装置および方法 |
US6317756B1 (en) * | 1998-10-07 | 2001-11-13 | International Business Machines Corporation | On-the-fly garbage collector |
US6317119B1 (en) * | 1998-11-13 | 2001-11-13 | Creative Technology Ltd | Speed-compensated joystick |
GB9825102D0 (en) * | 1998-11-16 | 1999-01-13 | Insignia Solutions Plc | Computer system |
US6763370B1 (en) * | 1998-11-16 | 2004-07-13 | Softricity, Inc. | Method and apparatus for content protection in a secure content delivery system |
SE9903890L (sv) * | 1999-10-28 | 2001-02-12 | Appeal Virtual Machines Ab | Förfarande för att effektivisera en databehandlingsprocess vid användning av en virtuell maskin och där ett skräpsamlingsförfarande används |
US6505275B1 (en) * | 2000-07-24 | 2003-01-07 | Sun Microsystems, Inc. | Method for scalable memory efficient thread-local object allocation |
US6745310B2 (en) * | 2000-12-01 | 2004-06-01 | Yan Chiew Chow | Real time local and remote management of data files and directories and method of operating the same |
US20030023655A1 (en) * | 2001-07-26 | 2003-01-30 | Stepan Sokolov | Method and apparatus to facilitate suspending threads in a platform-independent virtual machine |
KR100737345B1 (ko) * | 2006-03-28 | 2007-07-09 | 한국전자통신연구원 | 점진적인 가비지 콜렉션 수행 시에 순환적 가비지의 회수방법 및 장치 |
-
2004
- 2004-06-21 US US10/541,029 patent/US7395285B2/en not_active Expired - Fee Related
- 2004-06-21 JP JP2005511067A patent/JP4569926B2/ja not_active Expired - Fee Related
- 2004-06-21 EP EP04746512A patent/EP1659496B1/en not_active Not-in-force
- 2004-06-21 CN CNB2004800077351A patent/CN100437515C/zh not_active Expired - Fee Related
- 2004-06-21 DE DE602004028945T patent/DE602004028945D1/de active Active
- 2004-06-21 AT AT04746512T patent/ATE479942T1/de not_active IP Right Cessation
- 2004-06-21 KR KR1020057013843A patent/KR101004483B1/ko active IP Right Grant
- 2004-06-21 WO PCT/JP2004/009043 patent/WO2005001695A1/ja active Application Filing
Non-Patent Citations (3)
Title |
---|
CSNG199700288004, 湯浅 太一, "ごみ集めの基礎と最近の動向", 情報処理, 199411, 第35巻 第11号, P.1006−1013, JP, 社団法人情報処理学会 * |
JPN6010021993, Tamar Domani, Gal Goldshtein, et.al, "Thread−Local Heaps for Java", International Symposium on Memory Management 2002, 20020620, P.76−87, US, Association for Computing Machinery * |
JPN6010021995, 湯浅 太一, "ごみ集めの基礎と最近の動向", 情報処理, 199411, 第35巻 第11号, P.1006−1013, JP, 社団法人情報処理学会 * |
Also Published As
Publication number | Publication date |
---|---|
JP4569926B2 (ja) | 2010-10-27 |
EP1659496B1 (en) | 2010-09-01 |
EP1659496A1 (en) | 2006-05-24 |
US7395285B2 (en) | 2008-07-01 |
CN100437515C (zh) | 2008-11-26 |
KR20060023950A (ko) | 2006-03-15 |
KR101004483B1 (ko) | 2010-12-31 |
ATE479942T1 (de) | 2010-09-15 |
CN1761949A (zh) | 2006-04-19 |
EP1659496A4 (en) | 2008-11-26 |
WO2005001695A1 (ja) | 2005-01-06 |
US20060074988A1 (en) | 2006-04-06 |
DE602004028945D1 (de) | 2010-10-14 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP4569926B2 (ja) | ガーベジコレクションシステム | |
US6839726B2 (en) | Apparatus, method, and program for implementing garbage collection suitable for real-time processing | |
US7010555B2 (en) | System and method for compacting a computer system heap | |
JP3027845B2 (ja) | プログラム制御装置および方法 | |
US6192517B1 (en) | Method, apparatus, and product for improved garbage collection in a memory system through the removal of reference conflicts | |
JP5147280B2 (ja) | 異機種マルチプロセッサ・システムにおけるガーベッジ・コレクションのためのシステムおよび方法 | |
US7089272B1 (en) | Specializing write-barriers for objects in a garbage collected heap | |
US20040187102A1 (en) | Combining write-barriers within an inner loop with fixed step | |
US8074025B2 (en) | Method and system for copying live entities of source blocks identified by source list for selected destination block to selected destination block of memory heap | |
JP2000222281A (ja) | マルチスレッド仮想マシン内におけるメモリ・アロケ―ションの方法及び装置 | |
US8397045B2 (en) | Memory management device, memory management method, and memory management program | |
JP4265610B2 (ja) | プログラム制御装置、プログラム制御方法、およびプログラム記録媒体 | |
US8966212B2 (en) | Memory management method, computer system and computer readable medium | |
US20090037501A1 (en) | Method and system for managing memory for a program using area | |
US20040186863A1 (en) | Elision of write barriers for stores whose values are in close proximity | |
JP4333676B2 (ja) | プログラム制御装置、プログラム制御方法、およびプログラム記録媒体 | |
US8176286B2 (en) | Memory recycling in computer systems | |
KR101634118B1 (ko) | 메모리 관리 장치 및 방법 | |
JP3826626B2 (ja) | プログラム制御装置、プログラム制御方法、およびプログラム記録媒体 | |
CN114051610A (zh) | 基于arena的存储器管理 | |
JP4345748B2 (ja) | メモリ割当装置、メモリ割当方法、およびプログラム記録媒体 | |
KR101950759B1 (ko) | 저장 장치의 메모리 컨트롤러가 수행하는 가비지 컬렉션 방법 및 메모리 컨트롤러 | |
JPH08153037A (ja) | シーケンシャル領域におけるデータ管理方式 | |
KR20030094658A (ko) | 자동화된 동적 메모리 관리 기반의 시스템 환경에서어플리케이션이 직접 동적 메모리를 관리하는 방법 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050523 |
|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20070424 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090223 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090223 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20100427 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20100614 |
|
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: 20100713 |
|
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20100803 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130820 Year of fee payment: 3 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 4569926 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
LAPS | Cancellation because of no payment of annual fees |