JP2002506253A - リソースの透過的なガーベッジ・コレクション - Google Patents

リソースの透過的なガーベッジ・コレクション

Info

Publication number
JP2002506253A
JP2002506253A JP2000534955A JP2000534955A JP2002506253A JP 2002506253 A JP2002506253 A JP 2002506253A JP 2000534955 A JP2000534955 A JP 2000534955A JP 2000534955 A JP2000534955 A JP 2000534955A JP 2002506253 A JP2002506253 A JP 2002506253A
Authority
JP
Japan
Prior art keywords
program
execution
code
modifying
automatically
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.)
Pending
Application number
JP2000534955A
Other languages
English (en)
Inventor
マイケル エフ. スペルタス
Original Assignee
ゲオデジック システムズ インク.
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 ゲオデジック システムズ インク. filed Critical ゲオデジック システムズ インク.
Publication of JP2002506253A publication Critical patent/JP2002506253A/ja
Pending legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/46Multiprogramming arrangements
    • G06F9/50Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G06F9/5016Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals the resource being the 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/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
    • YGENERAL 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
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10STECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00Data processing: database and file management or data structures
    • Y10S707/99951File or database maintenance
    • Y10S707/99956File allocation
    • Y10S707/99957Garbage collection

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Stored Programmes (AREA)
  • Devices For Executing Special Programs (AREA)

Abstract

(57)【要約】 プログラムによって使用される非メモリ・リソース(413)をガーベッジ・コレクタ(401、601)に透過的に登録し、それにより、非メモリ・リソースを使用したプログラムが終了したときに非メモリ・リソースを解放する技法。この技法は、実行があるリソースを使用することをプログラムから自動的に判定し、次いで、このリソースが登録されるようにプログラムの動作を自動的に修正する(603)。このリソースを用いたプログラムが終了したときに、このリソースを解放しなければならないかどうかをレジストリから判定することができる。

Description

【発明の詳細な説明】
【0001】 関連出願の相互参照 本特許出願は、1998年3月3日に出願されたSpertusの米国仮特許出願第60/076
626号「Garbage collection of resources」の優先権を主張する。
【0002】 発明の背景 1.発明の分野 本発明は、全般的にはコンピュータ・プログラムの実行中にコンピュータ・プ
ログラムによって使用されるリソースの管理に関し、特に、リソース・リークの
防止に関する。リソース・リークが起こるのは、あるリソースを使用したプログ
ラムが終了したが、プログラムがこのリソースを解放せず、他のプログラムがこ
のリソースを使用できないときである。
【0003】 2.従来技術の説明:図1および図2 コンピュータ・システム上で実行されるプログラムは、コンピュータ・システ
ムから与えられるリソースを使用する。リソースには、メモリと、ファイルや入
出力装置などの非メモリ・リソースが含まれる。多くの場合、非メモリ・リソー
スへのアクセスはオペレーティング・システムによって行われ、オペレーティン
グ・システム自体が、これらのリソースを表すデータ構造を維持する。
【0004】 リークはこれらのリソースのどれに対しても起こる可能性がある。メモリ・リ
ークは、ガーベッジ・コレクタ、すなわち、あるプログラムによって割り付けら
れたが、もはやそのプログラムによって使用されておらず、したがって、他のプ
ログラムによって使用できるように解放することができるメモリの有無を検査す
るプログラムによって、ずっと前から対処されている。ガーベッジ・コレクタの
商業的に成功した例には、Geodesic Systems,Inc.によって製造されているGrea
t Circle(登録商標)ガーベッジ・コレクタがある。このガーベッジ・コレクタ
の概要は、1999年2月22日にhttp://www.geodesic.com/greatcircle/overvi
ew.html.で公開された。Great Circleガーベッジ・コレクタは、それと共に実行
されるように特定的にコード化されたプログラムだけでなく、それと共に実行さ
れるようににコード化されていないプログラムについても作用し、したがって、
レガシー・プログラム、すなわち、依然として有用であるがガーベッジ・コレク
タなど新しいプログラムを利用するように経済的に再実装することのできないプ
ログラムと共に使用することができる。
【0005】 非メモリ・リソースはガーベッジ・コレクタに対する問題を有している。図1 にその理由が示されている。この図は、コンピュータ・システムで実行される、
C++などのオブジェクト指向プログラミング言語で書かれたプログラムを示し ている。オブジェクト指向プログラミング言語では、プログラムがオブジェクト
、すなわち、クラスに属するエンティティを操作する。オブジェクトが属するク
ラスは、そのクラスに対して実行することのできる一定の1組の演算を定義する 。図1は、このようなプログラムが通常どのように実現されるかを示している。 このプログラムのコード107は、メイン・プログラム用のコード111と、メイン・
プログラム・コード111およびコード113によって使用されるオブジェクトのクラ
スに対する演算用のコード113とから成る。クラスNのオブジェクト用の1組のコ ードが115に示されている。クラスに関して定義される演算にはクラスのオブジ ェクトを構築するのに必要な処置を実行するコンストラクタ演算117と、クラス のオブジェクト用の記憶域が解放される前に行う必要のあるあらゆる処理を実行
するデストラクタ演算119が含まれる。デストラクタ演算はファイナライザ演算 、すなわち、ガーベッジ・コレクタがオブジェクトの記憶域を回収する前に実行
しなければならない演算の一例である。
【0006】 クラスNの単一のオブジェクトが121に示されている。このオブジェクトは2つ の部分、すなわち、オブジェクトのクラスに関して定義されている演算の指定子
123と、これらの演算が実行されるデータ125とを有している。クラスNのオブジ ェクトの場合、データはフォント記述子、すなわち、プログラムによって使用さ
れるフォントを指定するためにオペレーティング・システムから与えられる値を
含んでいる。フォント記述子127は、129に示されているオペレーティング・シス
テム・フォント・エンジンから与えられる関数を使用するクラスNの演算によっ て使用される。文字コード、サイズ指定、およびフォント記述子121が与えられ ると、フォント・エンジン129は、指定されたフォントで指定されたサイズの文 字の表現を生成することができる。このような表現の生成を加速するために、フ
ォント・エンジン129は、そのアドレス空間105に記憶されているフォントのレン
ダリング131を作成する。レンダリングが作成された後、フォント・エンジン129
は、レンダリング内を参照することによってこの表現を見つけることができる。
フォント記述子およびそれに関するレンダリングは非メモリ・リソースの例であ
る。レンダリングは特に大きく、オペレーティング・システムを効率的に操作す
るには、プログラムがもはやレンダリング131を必要としなくなったときにレン ダリング131を解放する必要がある。以下の議論は主として、非メモリ・リソー スに関する議論であり、特に指示がないかぎり、「リソース」の参照は、非メモ
リ・リソースの参照として理解されたい。
【0007】 クラスのデストラクタの1つの機能は、オブジェクトが破壊されたときに、オ ブジェクトによって使用されているすべてのリソースが解放されるようにするこ
とである。したがって、クラスN115のオブジェクトのデストラクタ119は、フォ ント記述子127およびそれに関連するレンダリング131を他のプログラムによって
使用できるように解放できることをフォント・エンジン129に示す、オペレーテ ィング・システムの呼出しを含む。もちろん、プログラマがオブジェクト121を 明示的に解放することを忘れた場合、このオブジェクトのデストラクタが実行さ
れることはなく、オブジェクト121だけでなく、フォント記述子127およびレンダ
リング131がリークする。
【0008】 図1を見るとわかるように、オブジェクト121がもはや使用されていないことを
ガーベッジ・コレクタに検出させ、オブジェクト121を解放しただけでは、非メ モリ・リソースがリークする問題は解決されない。ガーベッジ・コレクタは、オ
ブジェクト121のメモリを解放することができるが、一般にオブジェクト121のク
ラスやそのメモリの内容について知ることができないので、オブジェクト121の メモリを解放するときにデストラクタ119を実行することはなく、また、フォン ト・エンジン129が判定できるかぎり、フォント記述子127とレンダリング131は 共に依然として使用されている。
【0009】 従来技術のガーベッジ・コレクタでは、この問題は、オブジェクトが解放され
るときにデストラクタを実行する必要があることをガーベッジ・コレクタに明示
的に示す登録関数を設けることによって解決されている。プログラマが、オブジ
ェクトが解放されるときにデストラクタを実行しなければならないオブジェクト
を割り付けるプログラムを書くとき、オブジェクトを割り付けるコードはこの登
録関数を含む。図2にこのようなコードの2つの例が示されている。201の最初の 例は、Cで書かれている。プログラマは、あるオブジェクトが解放されるときに 実行する必要があるnoisyCleanup関数を書いている。205で、malloc関数を使用 してオブジェクトipが割り付けられており、この関数呼出しのすぐ後の207で、 プログラマはgcDeclareFinalizer登録関数を呼び出している。この関数は、オブ
ジェクトおよびクリーンナップ関数を引数としてとり、クリーンナップ関数にガ
ーベッジ・コレクタ(この場合、Great Circleガーベッジ・コレクタ)を登録す
る。
【0010】 登録の結果として、ガーベッジ・コレクタによって維持されている登録テーブ
ル209内のオブジェクト用のエントリが作成される。テーブル内の各登録エント リ(RTE)211は2つの情報項目、すなわち、割り付けられたときにこのエントリ が作成されたオブジェクトを指し示すオブジェクト・ポインタ213と、このオブ ジェクトのクラスのデストラクタ119を指し示すファイナライザ・ポインタ215を
指定する。ガーベッジ・コレクタは、オブジェクトを解放する前に、登録テーブ
ル209を探索し、このオブジェクトを指し示すポインタ213を含むRTE211があるか
どうか調べる。 ガーベッジ・コレクタは、RTE211を見つけた場合、このオブジ ェクトを解放する前にこのエントリ内のファイナライザ・ポインタ215によって 指定されているコードを実行する。
【0011】 引き続き図2を参照すると、217は、オブジェクトを登録することをC++プロ グラマがどのように指定するかを示している。C++はオブジェクト指向言語で あるので、プログラマは、オブジェクトのファイナライザをオブジェクトのクラ
ス定義の一部として指定しなければならない。219の#includeコンパイラ指令は
、登録演算gcCleanupに関するクラス情報を含むファイル「gct.h」をこのファイ
ルに含め、ここで名前gcCleanupが見えるようにすることを指定する。221の文は
、クラスAの定義にgcCleanupを追加し、このクラスに対してgcCleanupを定義す る。クラスAについては、gcCleanupからの継承によってクラスAのファイナライ ザがクラスAのデストラクタ、すなわち〜A()として指定される。〜A()は、c
leanup actionが現われる場所に書かれるあらゆるコードとして定義される。こ のコードの結果として、プログラム実行時にクラスAのオブジェクトが割り付け られるたびに、このオブジェクトが登録テーブル209に登録され、ファイナライ ザ・ポインタ215が、〜Aに関して定義されている処置を行うコードを指し示す。
【0012】 ガーベッジ・コレクタがメモリ・リークを防止するだけでなく非メモリ・リソ
ース・リークも防止するにはどうしたらよいかという問題は登録によって解決さ
れるが、現在実施されている登録には以下の2つの問題がある。 ・登録を指定するコードは、プログラムが書かれるときにそのプログラム内にな
ければならないので、ガーベッジを回収するためにレガシー・プログラムと共に
使用されるガーベッジ・コレクタは、オブジェクトを登録することができず、し
たがって、オブジェクト用のファイナライゼーション・コードを実行することが
できない。 ・プログラマがガーベッジ・コレクタと共に実行される新しいコードを書いてい
る場合でも、プログラマは依然として、オブジェクトが解放される前にファイナ
ライゼーションを必要とするあらゆるオブジェクトのクラス定義に登録コードを
含めることを覚えていなければならない。 非メモリ・リソースのガーベッジ・コレクションをプログラマから見て既存のメ
モリ・ガーベッジ・コレクションと同程度に自動的なものにする技法が必要であ
る。このような技法は、レガシー・コードを用いた非メモリ・リソースのガーベ
ッジ・コレクションを可能にするだけでなく、 プログラマが新しいプログラム を書く際に注意を払う負担からプログラマを解放する。本発明の目的はそのよう
な技法を提供することである。
【0013】 発明の概要 本発明の技法は、プログラムを調べることにより、プログラムがあるリソース
を使用することを自動的に判定し、次いで、プログラムが実行されたときにレジ
ストリ内にこのリソース用のエントリが作成されるようにプログラムの動作を自
動的に修正する。プログラムの実行がもはやこのリソースを必要としないことが
判定されると、レジストリ内のエントリは、このリソースを解放する必要がある
ことを示す。
【0014】 本発明の技法を使用して、オブジェクトに関連付けされたファイナライザが実
行されるようにすることができる。この技法は、プログラムが実行されることに
より、プログラムがあるオブジェクトを使用することを自動的に判定し、次いで
、プログラムが実行されたときにレジストリ内にファイナライザの用エントリが
作成されるようにプログラムの動作を自動的に修正する。プログラムの実行がも
はやこのオブジェクトを必要としないことが判定されると、エントリは、このオ
ブジェクトを解放すると共にファイナライザを実行する必要があることを示す。
ファイナライザが頻繁に使用されるのは例えば、オブジェクトに関連付けされた
リソースを解放するときである。
【0015】 プログラムの動作の修正は常に、プログラムの実行中の任意の時点で行うこと
ができる。プログラムの動作を修正する1つの方法として、実行時にオブジェク トまたはリソースを割り付けることを必要とする関数の呼出しを、レジストリ内
にエントリを作成し、次いで最初に意図された関数を呼び出す登録関数の呼出し
で置き換える方法がある。
【0016】 この技法は、ガーベッジ・コレクタと共に使用できるので特に有利である。ガ
ーベッジ・コレクタは、プログラムの動作を修正するのに必要な処置を実行し、
もはやプログラムによって使用されないオブジェクトを解放するとき、レジスト
リ内にそのオブジェクトのエントリがある場合にそのオブジェクトのファイナラ
イザを実行する。
【0017】 本発明の当業者には、以下に示す詳細な説明および図面を詳しく調べたときに
、他の目的および利点が明らかになると思われる。
【0018】 図面中の参照符号は3つ以上の数字を有し、右2桁は、残りの数字によって示さ
れる図面中の参照符号である。したがって、参照符号203を有する項目は、図2中
の項目203として現われる。
【0019】 詳細な説明 以下の詳細な説明ではまず、ガーベッジ・コレクタに関する非メモリ・リソー
スの自動登録の概念的な概要について述べ、次に、Microsoft Corporationによ って製造されているWindows(登録商標)ブランドのオペレーティング・システ ムの下で実行されるプログラムと共に使用できる好ましい態様について詳しく説
明する。
【0020】 概要:図3および図4 従来技術では、ガーベッジ・コレクションに関するオブジェクトを登録する場
合、プログラマが、この登録を行うコードを自分のプログラムに明確に追加する
必要がある。本発明は、登録を行う必要なコードを自動的に、すなわち、プログ
ラマがプログラムのソース・コードを変更する必要なしに追加する。本発明の態
様では、ソース・コードをコンパイルまたは解釈することができる点にプログラ
マが到達する時点と、オブジェクトが実際に割り付けられる時点との間の任意の
点でコードを追加することができる。コードは、コンパイル前工程中あるいはコ
ンパイル自体の間にソース・コードに追加することができ、リンキングの前また
は後にオブジェクト・コードに追加することができ、ローディングの前あるいは
実行中に実行可能コードに追加することができる。コードはインラインで追加す
ることも、あるいは登録関数の呼出しの形で追加することもできる。コードが解
釈されると、インタプリタが、オブジェクトが実際に割り付けられるときに、登
録を行うコードを追加することができ、あるいはインタプリタのコードを登録を
行うように修正することができる。
【0021】 図3は、登録を行うコードがどのように追加されるかを概略的に示している。 図3のフローチャートは、好ましい態様ではガーベッジ・コレクタの構成要素で あるプログラムによって実行される。他の態様では、このプログラムは、ガーベ
ッジ・コレクタを含んでいたシステムで実行すべきコードを書くプログラミング
・システムの構成要素であるか、あるいは場合によってはスタンドアロン・プロ
グラムであってよい。プログラムは、図4に示されているように動作する。プロ グラムは、非メモリ・リソースが必要とされるオブジェクトを割り付ける関数を
見つける(309)まで分析中のコードを探索する。プログラムは、そのような関 数を見つけると、ガーベッジ・コレクタの登録をこの関数に追加する(311)。 プログラムは、ループ397で示されているように、もはやそのような割付け関数 が見つからなくなる(305)までこの処理を繰り返し、見つからなくなった時点 で終了する。プログラムが非メモリ・リソースを割り付ける関数を見つけること
ができるのは、現代のオブジェクト指向プログラミング・システムでは非メモリ
・リソースがオブジェクト・クラス・ライブラリによって表されるからである。
非メモリ・リソースを使用する任意のオブジェクトのクラスは、そのオブジェク
トを作成するコンストラクタ関数と、非メモリ・リソースを解放するデストラク
タ関数とを含み、プログラムは、このようなクラスに属するオブジェクトのコン
ストラクタ関数およびデストラクタ関数のリストを維持するだけでよい。コンス
トラクタのリスト上にある関数が見つかったときはいつでも、その関数によって
実行される処置に登録が追加され、この登録はオブジェクトのデストラクタをオ
ブジェクトのファイナライザとして登録する。プログラムが実行される環境でプ
ログラムが表される方法と、登録コードが挿入される段階とに応じて、コンスト
ラクタ関数およびデストラクタ関数は、名前で認識するか、あるいはデータ構造
内の位置で認識するか、あるいは関数を表すポインタで認識することができる。
【0022】 フローチャート301に示されている技法は、コンパイルされるのではなく解釈 されるプログラムに適用することもできる。このようなプログラムを用いた場合
、各関数呼出しは、インタプリタで受け取られたときに調べられる。リスト上の
関数に一致する関数呼出しが見つかると、登録用のコードが命令ストリームに挿
入される。この技法を使用すると、解釈されるものが機械命令であるときでも登
録用のコードを挿入することができる。インタプリタを用いて同じ目的を達成す
る他の方法には、命令ストリームにコードを挿入するのではなく、インタプリタ
に登録を実行させる方法がある。
【0023】 図4は、非メモリ・リソースを使用するオブジェクトを自動的に登録するよう になされたガーベッジ・コレクタ401を示している。メモリ・コレクション構成 要素403はガーベッジ・コレクション・メモリ用に使用される。メモリ・アナラ イザ405は、プログラムのメモリ内のどのオブジェクトが現在、プログラムによ って使用されているかを判定するプログラムを実行することによって、現在使用
されているメモリを分析する。このようなオブジェクトはマーク付けされ、マー
ク付けされたオブジェクトのリスト407が作成される。次いで、ガーベッジ・コ レクタは、プログラムに属するメモリをスキャンし、解放関数411を使用して、 マークされておらず、したがって未使用のオブジェクトを解放する。
【0024】 非メモリ・リソース・コレクション構成要素413は、非メモリ・リソースを使 用するオブジェクトを自動的に登録すると共に、このようなオブジェクトが解放
される前にそのファイナライザ関数を実行する。登録コード・インサータ415は 、フローチャート301の処理を実行するコードである。登録コード・インサータ4
15は、そうする際に、関数リスト416、すなわち、非メモリ・リソースを使用す ることのできるオブジェクトのコンストラクタ関数およびデストラクタ関数のリ
ストを使用する。登録コード・インサータ415によって挿入される登録コードは4
17に示されている。登録コードがオブジェクトの登録テーブル・エントリをどの
ように作成するかは、プログラミング環境と、登録コードが挿入される時点とに
依存する。残りの構成要素は、登録テーブル419、すなわち、登録テーブル209の
インプリメンテーションと、登録テーブル419でオブジェクトのエントリ211を見
つけ、次いで、そのエントリ内のファイナライザ・ポインタ215によって指定さ れている関数を実行する登録テーブル・リーダ421である。
【0025】 ガーベッジ・コレクタ401の動作は以下のとおりである。非メモリ・リソース を使用することのできるオブジェクトの割付けが完了する前のある時点で、登録
コード・インサータ415が、オブジェクトのコンストラクタ用のコードに登録コ ード417を追加する。上記で指摘したように、登録コードは、プログラマが、こ のコードを使用中のプログラミング・システムによって自動的に処理されるよう
に条件付けた後の任意の時点で追加することができる。追加された登録コードを
有するコンストラクタ関数を使用してオブジェクトが割り付けられると、その結
果として、そのオブジェクトに属する非メモリ・リソースを解放するために実行
する必要のあるコードをファイナライザ・ポインタ215が指定するエントリ211が
テーブル419内に作成される。メモリ・アナライザ405が、このオブジェクトがも
はやプログラムによって使用されないことを判定した後、ガーベッジ・コレクタ
401は、このオブジェクトを指し示すポインタを用いて登録テーブル・リーダ421
を呼び出す。登録テーブル・リーダ421は、このオブジェクトのエントリ211を見
つけ、ファイナライザ・ポインタ215によって指定されている関数を実行させる 。登録テーブル・リーダ421は、エントリ211を無効化し、それによって他のオブ
ジェクトを登録できるようにすることもできる。ファイナライゼーション関数は
、メモリ・アナライザ405がこのオブジェクトがもはや使用されないことを判定 する時点と、解放関数411がこのオブジェクトを解放する時点との間のある時点 で実行される。
【0026】 好ましい態様の詳細な説明:図5から図7 以下で説明する好ましい態様は、Microsoft Corporationによって製造されて いるWindowsブランドのオペレーティング・システムの下で実行されるコード、 およびリソースを表すオブジェクトを定義する特定の1組のクラスと共に使用す ることが意図されている。好ましい態様を実施するために使用される技法は、Wi
ndows環境固有の技法であり、上記の特定の1組のクラスについての詳細な知識を
利用したものである。しかし、当業者にはただちにわかるように、このような技
法およびその変形例は、他のプログラミング環境および実行環境で使用すること
ができ、他の組のクラスと共に使用することができる。
【0027】 Windowsベースのオペレーティング・システムでは、他の多数のオペレーティ ング・システムと同様に、多数のユーザ・プログラムによって使用されるユーテ
ィリティ・プログラム用のコードは、1つまたは複数のダイナミック・リンク・ ライブラリ、すなわちDLLに含まれている。例えば、オブジェクト指向プログラ ミング環境のシステム・リソースを表すオブジェクトのクラス定義用のコードは
、1つまたは複数のそのようなDLLに含まれている。同様に、プログラムの実行中
に使用されるガーベッジ・コレクタ用のコードも1つまたは複数のそのようなDLL
に含まれている。プログラムの実行の開始時に、Windowsローダは、プログラム を、ローダが使用するDLLと動的に組み合わせ、実行可能なイメージを得て、コ ンピュータ・システムのメモリに記憶する。この実行可能なイメージは、コンピ
ュータ・システムによって実際に実行される。
【0028】 Windowsオペレーティング・システムによって実行できる準備の整ったコード は、高移植性実行可能ファイル・フォーマット、またはPEフォーマットである。
このファイル・フォーマットの説明は、Randy Kath著「The portable executabl
e file format from top to bottom」1993年に記載されている。この論文は、19
98年にMicrosoft Visual C++ 6.0 Standard Editionに添付されたMicrosoft m
sdnライブラリのディスク2上で発表された。図5は、ガーベッジ・コレクタと共 に実行されるプログラムのPEフォーマット・ファイル503を示している。PEファ イル503には、プログラムによって呼び出される各インポート関数についてのiデ
ータ・エントリ(IDE)507を含む.idataセクション505が含まれている。インポ ート関数とは、.idataセクション505が属するファイルに含まれていない関数で ある。もちろん、DLLを使用するプログラムによって呼び出される、DLLから得ら
れた関数はすべて、インポート関数である。IDE507は、インポート関数を名前で
識別し、すなわち、この関数を含むDLLファイル511およびDLLファイル内の関数 を、IDE内の情報を使用して見つけることができる。IDE507は、関数のポインタ 用の空間506も含んでいる。以下に説明するように、ローダはプログラムを実行 する前にポインタを追加しておく。
【0029】 図5に示されているIDE507は、リソース・コンストラクタ名505、すなわち、DL
L511内のリソース・コンストラクタ・コード513を指定するために使用される名 前を含んでいる。名前505の次に、ポインタ用の空間506がある。DLL511は、オペ
レーティング・システムから与えられるリソースのクラス定義を含んでいる。DL
Lファイル自体はPEファイルであり、したがって、他のDLLファイル内の関数の呼
出し用の.idataセクション505を含んでいる。インポート関数の呼出しはすべて 、この関数のIDE507を介して行われる。
【0030】 プログラム503を実行する際、オペレーティング・システムのローダ構成要素 は、プログラム503用のファイルと、プログラムの.idataセクション505内に指定
されている関数を含むDLLをリンクし、プログラムを実行するプロセスのアドレ ス空間内に単一の実行可能イメージを作成する。実行可能イメージは515に示さ れている。プログラムをガーベッジ・コレクタと共に使用する際、実行可能イメ
ージは、少なくともプログラム503、DLL511、およびガーベッジ・コレクタ用のD
LL519を含んでいる。ガーベッジ・コレクタ用のDLL519には、登録コード・イン サータ415、関数リスト416、および登録コード417自体が含まれている。ローダ は、実行可能イメージを作成する際、実行可能イメージ内のインポート関数用の
コードの位置を指し示すポインタを、PEファイル503の.idataセクション505内の
関数の名前およびDLL内の関数の名前に追加する。したがって、.idataセクショ ン505は、RC名509を含むだけでなく、実行可能イメージ内のリソース・コンスト
ラクタ513のコードを指し示すRCポインタ517も含んでいる。
【0031】 好ましい態様では、プログラムをガーベッジ・コレクタと共に使用する際、ユ
ーザがガーベッジ・コレクタを開始し、次いでガーベッジ・コレクタがプログラ
ムを開始する。プログラムがガーベッジ・コレクタと共に実行されるように書か
れていない場合、ガーベッジ・コレクタは、プログラムを開始する前に、実行可
能イメージの.idataセクションおよびガーベッジ・コレクタDLL以外の実行可能 イメージのDLLを修正する。この修正により、メモリ割付け関数やメモリ解放関 数など、ガーベッジ・コレクションに関する結果を有する関数を指し示す.idata
セクション505内のポインタが、ガーベッジ・コレクタDLL内のこれらの関数の修
正バージョンを指し示すポインタで置き換えられる。ここで使用される.idataセ
クションを修正する一般的な技法については、「????」という論文で詳しく
論じられている。
【0032】 好ましい態様では、.idataセクションを修正する技法は、非メモリ・リソース
を使用することのできるオブジェクトが登録テーブル419に登録されるようにす るときにもガーベッジ・コレクタによって使用される。実行がガーベッジ・コレ
クタによって開始されるプログラム503は、ガーベッジ・コレクタにとって重要 なリソースのクラス定義を含む特定の1組のDLLにリンクされ、関数リスト416は このようなリソースのコンストラクタの名前を含んでいる。実際の修正は、登録
コード・インサータ415によって行われる。登録コード・インサータ415はプログ
ラム503の.idataセクション505と、実行可能イメージ515内のガーベッジ・コレ クタDLL以外の、プログラム503のDLLとをスキャンする。登録コード・インサー タ415は、1つのリソース・コンストラクタのRC名505を含むIDE507を見つけると 、リソース・コンストラクタを指し示すポインタ517を登録コード417を指し示す
ポインタで置き換える。
【0033】 この場合のガーベッジ・コレクタの修正の結果は図6の601に示されている。ID
E507は、前にリソース・コンストラクタ503を指し示すポインタを含んでいたが 、現在ではガーベッジ・コレクタDLL519内の登録コード417を指し示す登録コー ド・ポインタ603を含んでいる。好ましい態様では、登録コード417は、当該の各
リソース・コンストラクタ用の登録コードを含んでおり、登録コード・ポインタ
603は、リソース・コンストラクタ名505によって示されるリソース・コンストラ
クタに関する登録を行う登録コード417の部分を指し示す。実行可能イメージ内 のすべてのDLL内の非メモリ・リソースを使用するコンストラクタを指し示すポ インタにも同じことが当てはまる。
【0034】 インポート関数の呼出しがすべて、.idataセクション505内のIDE507を通じて 行われ、かつWindowsオペレーティング・システムによって実行プログラムがそ れ自体の実行可能イメージ515を修正することができるので、前述の修正技法がW
indowsオペレーティング・システム環境で有効であることに留意されたい。イン
ポート関数の呼出しに対するこのような制限がない環境では、登録コード・イン
サータ415が実行可能イメージの本体内でそのような呼出しを見つける必要があ り、実行プログラムがそれ自体の実行可能イメージ515を修正するのを禁止する 環境では、登録コード・インサータ415がリンキングの前にDLL内でそのような呼
出しを見つける必要がある。このような場合にはもちろん、インサータ415は、 リソース・コンストラクタの名前による呼出しを、登録コード417の名前による 呼出しで置き換える。しかし、これらの変形例を用いた場合、どの変形例の場合
でも、変化するのは技法よりもむしろ、探索する必要のある実効可能イメージま
たはプログラム・ファイルの面積と、探索および置換を行わなければならない時
間である。
【0035】 ガーベッジ・コレクタは、前述のように実行可能イメージ515を修正した後、 プログラム503の実行を開始する。プログラム503またはDLLがリソース・コンス トラクタを呼び出すと、修正済みのIDE507がこの呼出しを登録コード417の呼出 しに変換する。図7は、登録コード417が実行されるときに何が起こるかを示して
いる。登録コード417の呼出しは、リソース・コンストラクタがオブジェクトを 構築するリソース用のコードの部分717にアクセスする。このコードの部分717は
、リソース・コンストラクタ505の名前と、リソースを表すオブジェクトのデス トラクタの名前719の両方を含んでいる。
【0036】 Windowsオペレーティング・システムは、DLLファイルのハンドルとこのファイ
ル内のある関数の名前とが与えられたときに、実行可能イメージ515内のこの関 数の位置を指し示すポインタを返す関数721を含んでいる。部分717はまず、OSシ
ステム721を使用して、リソース・コンストラクタ513を指し示すポインタを得る
。部分717は、このポインタを使用してリソース・コンストラクタ513を呼び出す
。リソース・コンストラクタ513は、リソース・オブジェクト711を構築し、登録
コード417を指し示すオブジェクト・ポインタ713を返す。部分717は次いで、Rdn
ame719をOS関数721と共に使用して、このオブジェクトのデストラクタ関数を指 し示すポインタを得る。部分717は、オブジェクト713を指し示すポインタとデス
トラクタ715を指し示すポインタの両方を有しているので、このオブジェクトお よびデストラクタ用の登録テーブル・エントリ211(i)を作成する。部分717は 、そうした後、オブジェクト・ポインタ713をプログラム503に返す。プログラム
503の観点からすると、登録コードの部分717の呼出しの結果は、リソース・コン
ストラクタを呼び出した場合とまったく同じである。
【0037】 関連するオブジェクトのコンストラクタの呼出しを登録関数の呼出しで置き換
えるのに必要な情報と、登録関数がこのオブジェクト用のエントリを登録テーブ
ル419内に作成する必要があるという情報とを得るために好ましい態様で使用さ れる技法が、Windowsオペレーティング・システムによって与えられるプログラ ム実行環境固有の技法であることに留意されたい。他の実行環境では、他の技法
を使用して情報を得ることができる。例えば、呼出しリダイレクションは、コー
ドがソース・コードから実行可能イメージに進む際のより早い段階で行うか、あ
るいは呼出しを実際に実行するときに行うことができる。
【0038】 同様に、コンストラクタを指し示すポインタを得るために使用される技法とデ
ストラクタを指し示すポインタを得るために使用される技法はそれぞれ異なる技
法でよい。例えば、ポインタを与えるオペレーティング・システム関数がない場
合、ガーベッジ・コレクタは、コンストラクタおよびデストラクタの名前をそれ
らのポインタに関係付けるガーベッジ・コレクタ自体のテーブルを構築する必要
がある。いくつかのプログラミング環境では、オブジェクト自体から情報を得る
ことができる。例えば、コンストラクタ・ポインタおよびデストラクタ・ポイン
タがすべてのオブジェクトにおいて一定の場所にある場合、ガーベッジ・コレク
タはそれらのポインタをこれらの一定の位置から得ることができる。さらに、プ
ログラミング環境が、プログラムが実行されるときにオブジェクトのクラス情報
をどの程度利用可能にするかに応じて、ガーベッジ・コレクタはこのクラス情報
を使用して必要なポインタを得ることができる。
【0039】 好ましい態様のガーベッジ・コレクタは、マーク・アンド・スィープ・インク
リメント・ガーベッジ・コレクタである。このようなガーベッジ・コレクタでは
、現在プログラムによって使用されているオブジェクトがマーク付けされ、使用
されていないオブジェクトがスィープされ、すなわち解放される。オブジェクト
のデストラクタは、オブジェクト自体が解放される前の任意の時点で実行するこ
とができる。好ましい態様では、ガーベッジ・コレクタはスィープの直後にデス
トラクタを実行する。ガーベッジ・コレクタはそうする場合に登録テーブル・リ
ーダ421を実行し、登録テーブル・リーダ421は好ましい態様では、有効な各RTE2
11を順次取り出し、オブジェクト・ポインタ713によって指定されているオブジ ェクトが使用中としてマーク付けされているかどうかを判定する。このオブジェ
クトがこのようにマーク付けされていない場合、テーブル・リーダ421は、エン トリ内のデストラクタ・ポインタ715によって指定されているデストラクタを呼 び出す。デストラクタが呼び出された後、テーブル・リーダ421はテーブル・エ ントリ211を無効化し、他のオブジェクトによって使用できるようにする。
【0040】 プログラム・コード503は、そのコードが本来、ガーベッジ・コレクタと共に 使用されるようには書かれていないレガシー・コードであるためか、あるいはい
つオブジェクトを解放するかに関する厳密な制御が必要であるために、オブジェ
クトを明示的に解放することができる。このようなプログラムに対処するために
、ガーベッジ・コレクタは前述の技法を使用して、オペレーティング・システム
の未使用関数をガーベッジ・コレクタ自体の未使用関数で置き換える。この未使
用関数は登録テーブル419を調べ、解放中のオブジェクトがテーブル内にエント リ211を有しているかどうかを判定する。エントリを有している場合、未使用関 数はこのオブジェクトのデストラクタ・コードを実行する。未使用関数は、登録
テーブル419を調べる動作を高速化するために、ハッシングなどの探索技法を使 用することができる。
【0041】 結論 上記の詳細な説明では、ガーベッジ・コレクタがオブジェクトを解放する前に
デストラクタを実行できるように、ガーベッジ・コレクタによって解放される前
にデストラクタ関数を実行することを必要とするオブジェクトを自動的に登録す
るための、現在発明者に知られている最良の態様について詳しく説明した。本明
細書で開示した自動登録技法は、自分のプログラムに登録関数を含める負担から
プログラマを解放するだけでなく、レガシー・プログラムに対してリソース・ガ
ーベッジ・コレクションを行い、それによってリソース・リークを防止すること
も可能にする。本明細書に記載された自動登録技法が、資源のデストラクタに限
らず、オブジェクトが解放される前にファイナライザを実行する必要のあるあら
ゆる状況で使用できることに、さらに留意されたい。
【0042】 好ましい態様は、Windowsブランドのオペレーティング・システムによって与 えられる環境で実施され、実際にこの環境のある特徴を利用しているが、当業者
には、本明細書で開示された自動登録技法がWindowsブランドのオペレーティン グ・システムに限らず、プログラムの実行があるリソースまたはオブジェクトを
使用するものであり、かつこの実行がそのリソースまたはオブジェクトを使用し
て終了したことを判定することが可能なあらゆる環境で、環境に必要な変形を施
したうえで使用できることが、ただちに明らかになると思われる。
【0043】 上記のすべての理由で、詳細な説明は、すべての点で例示的なものとみなすべ
きであり、制限的なものとみなすべきはなく、本明細書で開示された本発明の範
囲は、詳細な説明から決定するのではなく、特許法によって許容される全範囲に
おいて解釈された特許請求の範囲から決定されるべきである。
【図面の簡単な説明】
【図1】 オブジェクト指向プログラムおよびリソース・リーク問題を示す
図である。
【図2】 従来技術のオブジェクト登録技法を示す図面である。
【図3】 自動登録のフローチャートである。
【図4】 自動登録を行うガーベッジ・コレクタのブロック図である。
【図5】 WindowsPEフォーマットおよびDLLと、リンキングを示す図である
【図6】 ガーベッジ・コレクタが実行可能なイメージをどのように修正す
るかを示す図である。
【図7】 あるオブジェクトのコンストラクタが呼出されるときに登録コー
ドが登録テーブル419内にそのオブジェクト用のエントリをどのように作成する かを示す図である。

Claims (47)

    【特許請求の範囲】
  1. 【請求項1】 プログラムの実行によって使用されるリソースを、該リソー スがもはや実行によって必要とされなくなったときに解放する方法であって、以
    下の工程を含む方法: 実行が該リソースを必要とすることをプログラムから自動的に判定する工程; 実行によってレジストリ内にリソース用のエントリが作成されるようにプログ
    ラムの動作を自動的に修正する工程;および 該リソースを用いて実行が終了したことを実行の状態から自動的に判定し、次
    いでレジストリが該リソースの解放を示したときに該リソースを解放する工程。
  2. 【請求項2】 プログラムの動作を修正する工程が、修正されたコードが実 行されることによって動作が修正されるようにプログラムのコードを自動的に修
    正する工程を含む、請求項1記載の方法。
  3. 【請求項3】 以下の工程を含む、請求項2記載の方法: プログラム内の実行にリソースを供給するリソース供給関数の呼出しを検出す
    る工程を含む、実行が該リソースを使用することをプログラムから自動的に判定
    する工程;および 呼出しが実行されるときに該リソース用のエントリが作成されるように、呼出
    しを含むコードを修正する工程を含む、プログラムのコードを自動的に修正する
    工程。
  4. 【請求項4】 呼出しを含むコードを修正する工程が、リソース供給関数の 呼出しを実行時にエントリが作成されリソース供給関数が実行されるエントリ作
    成関数の呼出しで置き換える工程を含む、請求項3記載の方法。
  5. 【請求項5】 プログラムの動作を修正する工程が、プログラムの実行中の 任意の時点で行われる、請求項1〜4のいずれか一項記載の方法。
  6. 【請求項6】 リソースがオブジェクトに関連付けされる、請求項1〜4のい ずれか一項記載の方法であって、以下の工程を含む方法: プログラムのコードを自動的に修正する工程において、プログラムのコードが
    実行によりオブジェクトが作成されるときにエントリが作成されるように自動的
    に修正される工程;および 該リソースを用いた実行が終了したかどうかを自動的に判定する工程において
    、実行がもはや該オブジェクトを使用しないときに該リソースを用いた実行が終
    了したと判定される工程。
  7. 【請求項7】 プログラムの実行がガーベッジ・コレクタを含む環境で起こ る、請求項6記載の方法であって、 リソースを用いた実行が終了したかどうかを自動的に判定する工程において、
    該ガーベッジ・コレクタが、実行がもはや該オブジェクトを使用しないことを判
    定し、該オブジェクトを解放する前に該リソースを解放する方法。
  8. 【請求項8】 ガーベッジ・コレクタが、実行がリソースを使用することを プログラムから自動的に判定する工程と、プログラムの動作を自動的に修正する
    工程とを実行する、請求項7記載の方法。
  9. 【請求項9】 ガーベッジ・コレクタが、実行がリソースを使用することを プログラムから自動的に判定する工程と、プログラムの実行中の任意の時点でプ
    ログラムの動作を自動的に修正する工程とを実行する、請求項8記載の方法。
  10. 【請求項10】 コンピュータ・システム内で実行されたときに、請求項8記 載の方法の工程を実行するコードを含む、データを記憶する装置。
  11. 【請求項11】 コンピュータ・システム内で実行されたときに、請求項1〜4
    のいずれか一項記載の方法の工程を実行するコードを含む、データを記憶する装
    置。
  12. 【請求項12】 プログラムの実行が、もはやオブジェクトを必要としなくな
    ったときに該オブジェクトに関連付けされたファイナライザを実行する方法であ
    って、以下の工程を含む方法: 実行が該オブジェクトを使用することをプログラムから自動的に判定する工程
    ; 実行によってレジストリ内にファイナライザ用のエントリが作成されるように
    プログラムの動作を自動的に修正する工程;および 該オブジェクトを用いて実行が終了したことを実行の状態から自動的に判定す
    ると共に、ファイナライザを実行する必要があることをエントリから自動的に判
    定し、次いで該オブジェクトを解放すると共にファイナライザを実行する工程。
  13. 【請求項13】 プログラムの動作を修正する工程が、修正されたコードが実
    行されることによって動作が修正されるように、プログラムのコードを自動的に
    修正する工程を含む、請求項12記載の方法。
  14. 【請求項14】 以下の工程を含む、請求項13記載の方法: オブジェクトを作成するオブジェクト作成関数の呼出しを検出する工程を含む
    、実行が該オブジェクトを使用することをプログラムから自動的に判定する工程
    ;および 呼出しが実行されるときにファイナライザ用のエントリが作成されるように、
    呼出しを含むコードを修正する工程を含む、プログラムのコードを自動的に修正
    する工程。
  15. 【請求項15】 呼出しを含むコードを修正する工程が、オブジェクト作成関
    数の呼出しを、実行時にエントリが作成されオブジェクト作成関数が実行される
    エントリ作成関数の呼出しで置き換える工程を含む、請求項14記載の方法。
  16. 【請求項16】 プログラムの動作を修正する工程が、プログラムの実行中の
    任意の時点で行われる、請求項12〜15のいずれか一項記載の方法。
  17. 【請求項17】 プログラムの実行がガーベッジ・コレクタを含む環境で起こ
    る、請求項12〜15のいずれか一項記載の方法であって、 オブジェクトを用いた実行が終了したかどうかを自動的に判定しする工程にお
    いて、ガーベッジ・コレクタが、実行がもはや該オブジェクトを使用しないこと
    を判定し、該オブジェクトを解放する前にファイナライザを実行する方法。
  18. 【請求項18】 ガーベッジ・コレクタが、実行がオブジェクトを使用するこ
    とをプログラムから自動的に判定する工程と、プログラムの動作を自動的に修正
    する工程とを実行する、請求項17記載の方法。
  19. 【請求項19】 ガーベッジ・コレクタが、実行がオブジェクトを使用するこ
    とをプログラムから自動的に判定する工程と、プログラムの実行中の任意の時点
    でプログラムの動作を自動的に修正する工程とを実行する、請求項18記載の方法
  20. 【請求項20】 コンピュータ・システム内で実行されたときに、請求項18記
    載の方法の工程を実行するコードを含む、データを記憶する装置。
  21. 【請求項21】 コンピュータ・システム内で実行されたときに、請求項12〜
    15のいずれか一項記載の方法の工程を実行するコードを含む、データを記憶する
    装置。
  22. 【請求項22】 プログラムの実行によって使用されるリソースを、実行が該
    リソースをもはや必要としなくなったときに解放されるように自動的に登録する
    方法であって、以下の工程を含む方法: 実行が該リソースを使用することをプログラムから自動的に判定する工程;お
    よび 実行によってレジストリ内にリソース用のエントリが作成されるようにプログ
    ラムの動作を自動的に修正し、該エントリを用いた実行が終了したときに、該リ
    ソースを解放する必要があることを該エントリを使用して判定する工程。
  23. 【請求項23】 プログラムの動作を修正する工程が、修正されたコードが実
    行されることによって動作が修正されるようにプログラムのコードを自動的に修
    正する工程を含む、請求項22記載の方法。
  24. 【請求項24】 以下の工程を含む、請求項23記載の方法: プログラム内の実行に該リソースを供給するリソース供給関数の呼出しを検出
    する工程を含む、実行がリソースを使用することをプログラムから自動的に判定
    する工程;および 呼出しが実行されるときに該リソース用のエントリが作成されるように呼出し
    を含むコードを修正する工程を含む、プログラムのコードを自動的に修正する工
    程。
  25. 【請求項25】 呼出しを含むコードを修正する工程が、リソース供給関数の
    呼出しを実行時にエントリが作成されリソース供給関数が実行されるエントリ作
    成関数の呼出しで置き換える工程を含む、請求項24記載の方法。
  26. 【請求項26】 プログラムの動作を修正する工程が、プログラムの実行中の
    任意の時点で行われる、請求項22〜25のいずれか一項記載の方法。
  27. 【請求項27】 リソースがオブジェクトに関連付けされる、請求項22〜25の
    いずれか一項記載の方法であって、 プログラムのコードを自動的に修正する工程において、実行によりオブジェク
    トが作成されるときにエントリが作成されるように、プログラムのコードが自動
    的に修正される方法。
  28. 【請求項28】 プログラムの実行が、ガーベッジ・コレクタを含む環境で起
    こり、 ガーベッジ・コレクタが、実行がリソースを使用することをプログラムから自
    動的に判定する工程と、プログラムの動作を自動的に修正する工程とを実行する
    、請求項27記載の方法。
  29. 【請求項29】 ガーベッジ・コレクタが、実行がリソースを使用することを
    プログラムから自動的に判定する工程と、プログラムの実行中の任意の時点でプ
    ログラムの動作を自動的に修正する工程とを実行する、請求項28記載の方法。
  30. 【請求項30】 コンピュータ・システム内で実行されたときに、請求項28記
    載の方法の工程を実行するコードを含む、データを記憶する装置。
  31. 【請求項31】 コンピュータ・システム内で実行されたときに、請求項22〜
    25のいずれか一項記載の方法の工程を実行するコードを含む、データを記憶する
    装置。
  32. 【請求項32】 オブジェクトに関連付けされたファイナライザを、プログラ
    ムの実行がもはや該オブジェクトを必要としなくなったときに実行されるように
    自動的に登録する方法であって、以下の工程を含む方法: 実行が該オブジェクトを使用することをプログラムから自動的に判定する工程
    ;および 実行によってレジストリ内にファイナライザ用のエントリが作成されるように
    プログラムの動作を自動的に修正し、該オブジェクトを用いた実行が終了したと
    きに、該オブジェクトを解放すると共にファイナライザを実行する必要があるこ
    とを該エントリを使用して判定する工程。
  33. 【請求項33】 プログラムの動作を修正する工程が、修正されたコードが実
    行されることによって動作が修正されるように、プログラムのコードを自動的に
    修正する工程を含む、請求項32記載の方法。
  34. 【請求項34】 以下の工程を含む、請求項33記載の方法: オブジェクト作成関数の呼出しを検出する工程を含む、実行が該オブジェクト
    を使用することをプログラムから自動的に判定する工程;および 呼出しが実行されるときにファイナライザ用のエントリが作成されるように呼
    出しを含むコードを修正する工程を含む、プログラムのコードを自動的に修正す
    る工程。
  35. 【請求項35】 呼出しを含むコードを修正する工程が、オブジェクト作成関
    数の呼出しを、実行時にエントリが作成されオブジェクト作成関数が実行される
    エントリ作成関数の呼出しで置き換える工程を含む、請求項34記載の方法。
  36. 【請求項36】 プログラムの動作を修正する工程が、プログラムの実行中の
    任意の時点で行われる、請求項32〜35のいずれか一項記載の方法。
  37. 【請求項37】 プログラムの実行が、ガーベッジ・コレクタを含む環境で起
    こり、 該ガーベッジ・コレクタが、実行がオブジェクトを使用することをプログラム
    から自動的に判定する工程と、プログラムの動作を自動的に修正する工程とを実
    行する、請求項32〜35のいずれか一項記載の方法。
  38. 【請求項38】 ガーベッジ・コレクタが、実行がオブジェクトを使用するこ
    とをプログラムから自動的に判定する工程と、プログラムの実行中の任意の時点
    でプログラムの動作を自動的に修正する工程とを実行する、請求項37記載の方法
  39. 【請求項39】 コンピュータ・システム内で実行されたときに、請求項37記
    載の方法の工程を実行するコードを含む、データを記憶する装置。
  40. 【請求項40】 コンピュータ・システム内で実行されたときに、請求項32〜
    35のいずれか一項記載の方法の工程を実行するコードを含む、データを記憶する
    装置。
  41. 【請求項41】 オブジェクトがプログラムの実行時に割り付けられ、ファイ
    ナライザが該オブジェクトを解放するときに実行される、オブジェクトに関連付
    けされたファイナライザを自動的に実行するガーベッジ・コレクタであって、 以下の特徴を備え、それによってガーベッジ・コレクタを用いた実行について
    プログラムを書く必要がなくなるガーベッジ・コレクタ: ファイナライゼーション・コードの実行を必要とするオブジェクトをオブジェ
    クトのレジストリに登録するレジスタ; 該オブジェクトが割り付けられるときにレジスタが該オブジェクトをレジスト
    リに登録するように、実行の前にプログラムを自動的に修正するプログラム・モ
    デファイア;および レジストリが該オブジェクトのメモリから解放することを示したときにオブジ
    ェクトのメモリを解放すると共にファイナライザを実行するレジストリ・リーダ
  42. 【請求項42】 オブジェクトが割り付けられるときに、プログラムが該オブ
    ジェクトのコンストラクタ関数を実行し、 プログラム・モデファイアが、コンストラクタ関数の呼出しを検出し、コンス
    トラクタ関数の呼出しをレジスタの呼出しで置き換え、 該レジスタが、該オブジェクトを登録すると共にコンストラクタ関数を呼び出
    す、請求項41記載のガーベッジ・コレクタ。
  43. 【請求項43】 プログラム・モデファイアが、プログラムの実行中の任意の
    点でプログラムを修正する、請求項41または42記載のガーベッジ・コレクタ。
  44. 【請求項44】 プログラム・モデファイアが、プログラムがコンパイルされ
    た後でプログラムを修正する、請求項41または42記載のガーベッジ・コレクタ。
  45. 【請求項45】 プログラム・モデファイアが、プログラムがコンパイルされ
    る前にプログラムを修正する、請求項41または42記載のガーベッジ・コレクタ。
  46. 【請求項46】 オブジェクトが非メモリ・リソースを表し、 該オブジェクトが作成されたときに、少なくとも場合によってはリソースが割
    り付けられ、 ファイナライザが、割り付けられた該リソースを解放する、請求項41または42
    記載のガーベッジ・コレクタ。
  47. 【請求項47】 コンピュータ・システム内で実行されたときに、請求項41ま
    たは42記載のガーベッジ・コレクタを実現するコードを含む、データを記憶する
    装置。
JP2000534955A 1998-03-03 1999-03-02 リソースの透過的なガーベッジ・コレクション Pending JP2002506253A (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US7662698P 1998-03-03 1998-03-03
US60/076,626 1998-03-03
PCT/US1999/004528 WO1999045481A1 (en) 1998-03-03 1999-03-02 Transparent garbage collection of resources

Publications (1)

Publication Number Publication Date
JP2002506253A true JP2002506253A (ja) 2002-02-26

Family

ID=22133226

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2000534955A Pending JP2002506253A (ja) 1998-03-03 1999-03-02 リソースの透過的なガーベッジ・コレクション

Country Status (5)

Country Link
US (1) US6584478B1 (ja)
EP (1) EP1058897A4 (ja)
JP (1) JP2002506253A (ja)
CA (1) CA2321787C (ja)
WO (1) WO1999045481A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005531050A (ja) * 2002-05-07 2005-10-13 オラクル・インターナショナル・コーポレイション オブジェクトをプログラミングするための簡略化されたメモリの割当ての取消

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2421591C (en) 2000-09-13 2011-08-23 Geodesic Systems, Incorporated Conservative garbage collectors that can be used with general memory allocators
US7747943B2 (en) * 2001-09-07 2010-06-29 Microsoft Corporation Robust anchoring of annotations to content
US7243301B2 (en) 2002-04-10 2007-07-10 Microsoft Corporation Common annotation framework
US7069279B1 (en) * 2002-11-04 2006-06-27 Savaje Technologies, Inc. Timely finalization of system resources
US7469324B2 (en) * 2005-01-07 2008-12-23 Azul Systems, Inc. System and method for concurrent compacting self pacing garbage collection using loaded value and access barriers
US7299384B1 (en) 2004-08-17 2007-11-20 Symantec Operating Corporation Fixing prematurely freed objects
US7426718B2 (en) * 2005-03-21 2008-09-16 Microsoft Corporation Overriding constructors to provide notification in order to detect foreign code
US7607122B2 (en) * 2005-06-17 2009-10-20 Microsoft Corporation Post build process to record stack and call tree information
GB0512809D0 (en) * 2005-06-23 2005-08-03 Ibm Arrangement and method for garbage collection in a computer system
EP2137622B1 (de) * 2007-04-18 2018-07-11 Siemens Aktiengesellschaft Verfahren und datenverarbeitungssystem zur rechnergestützten performanzanalyse eines datenverarbeitungssystems
US20080281887A1 (en) * 2007-05-10 2008-11-13 Nokia Corporation Application specific garbage collection system
US8073882B2 (en) 2007-07-11 2011-12-06 Mats Stefan Persson Method, system and computer-readable media for managing software object handles in a dual threaded environment
JP5215779B2 (ja) * 2008-09-01 2013-06-19 キヤノン株式会社 情報処理装置及び情報処理方法
EP2383647A1 (en) * 2010-04-27 2011-11-02 Tixel GmbH Networking system call data division for zero copy operations
US8848402B2 (en) * 2012-05-25 2014-09-30 Chicony Power Technology Co., Ltd. Power factor correction apparatus
US9747088B2 (en) * 2013-04-22 2017-08-29 Embarcadero Technologies, Inc. Automatic reference counting
US20150128117A1 (en) * 2013-11-07 2015-05-07 Netronome Systems, Inc. Linker that statically allocates non-memory resources at link time
US10180902B2 (en) 2015-06-30 2019-01-15 International Business Machines Corporation Pauseless location and object handle based garbage collection
US10176093B2 (en) 2015-06-30 2019-01-08 International Business Machines Corporation Pauseless location and object handle based garbage collection
US9734053B2 (en) * 2015-06-30 2017-08-15 International Business Machines Corporation Garbage collection handler to update object pointers

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07507887A (ja) * 1991-11-20 1995-08-31 パークプレイス・システムズ・インコーポレイテッド ポストモーテム最終化方法

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5535390A (en) * 1994-07-22 1996-07-09 Hildebrandt; Thomas H. Method for reusing temporaries and reclaiming shared memory
US5581696A (en) * 1995-05-09 1996-12-03 Parasoft Corporation Method using a computer for automatically instrumenting a computer program for dynamic debugging
US5778378A (en) * 1996-04-30 1998-07-07 International Business Machines Corporation Object oriented information retrieval framework mechanism
US6081665A (en) * 1997-12-19 2000-06-27 Newmonics Inc. Method for efficient soft real-time execution of portable byte code computer programs
US6381738B1 (en) * 1999-07-16 2002-04-30 International Business Machines Corporation Method for optimizing creation and destruction of objects in computer programs

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07507887A (ja) * 1991-11-20 1995-08-31 パークプレイス・システムズ・インコーポレイテッド ポストモーテム最終化方法

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
GARY AITKEN: "C++からJavaへの移行", DDJ, vol. 第5巻,第7号, JPN6008020353, 1 July 1996 (1996-07-01), JP, pages 27 - 33, ISSN: 0001033463 *
MIKE SPERTUS: "C++とガベージコレクション", DDJ, vol. 第7巻,第3号, JPN6008020345, 1 March 1998 (1998-03-01), JP, pages 109 - 114, ISSN: 0001033461 *
とどそふと: "研究Java 第2章 Java言語仕様", C MAGAZINE 第8巻 第5号, vol. 第8巻,第5号, JPN6008020349, 1 May 1996 (1996-05-01), JP, pages 33 - 46, ISSN: 0001033462 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005531050A (ja) * 2002-05-07 2005-10-13 オラクル・インターナショナル・コーポレイション オブジェクトをプログラミングするための簡略化されたメモリの割当ての取消

Also Published As

Publication number Publication date
CA2321787A1 (en) 1999-09-10
US6584478B1 (en) 2003-06-24
WO1999045481A1 (en) 1999-09-10
EP1058897A1 (en) 2000-12-13
CA2321787C (en) 2007-05-15
EP1058897A4 (en) 2005-11-23

Similar Documents

Publication Publication Date Title
JP2002506253A (ja) リソースの透過的なガーベッジ・コレクション
US6093216A (en) Method of run-time tracking of object references in Java programs
US6253215B1 (en) Method, apparatus, and article of manufacture for facilitating resource management for applications having two types of program code
US6760905B1 (en) Lazy compilation of template-generated classes in dynamic compilation execution environments
US6484188B1 (en) Optimization of garbage collection code in the context of raw native interface function calls in the java programming language
CN106663019B (zh) 处理值类型
US5920876A (en) Performing exact garbage collection using bitmaps that identify pointer values within objects
US7076773B2 (en) Object oriented apparatus and method for allocating objects on an invocation stack in a dynamic compilation environment
US6115782A (en) Method and apparatus for locating nodes in a carded heap using a card marking structure and a node advance value
US6898611B1 (en) Declarative pinning
US5900001A (en) Method and apparatus for optimizing exact garbage collection using a bifurcated data structure
US6192517B1 (en) Method, apparatus, and product for improved garbage collection in a memory system through the removal of reference conflicts
JP4571710B2 (ja) ディスパッチテーブル構造のための方法と装置
CA2267477C (en) Packaging memory image files
US7225439B2 (en) Combining write-barriers within an inner loop with fixed step
US6842759B2 (en) Single-instance class objects across multiple JVM processes in a real-time system
EP0620522A2 (en) High performance dynamic linking through caching
US20060026183A1 (en) Method and system provide concurrent access to a software object
US6701520B1 (en) Preventing garbage collection of objects in object oriented computer programming languages
US5915255A (en) Method and apparatus for referencing nodes using links
US5911144A (en) Method and apparatus for optimizing the assignment of hash values to nodes residing in a garbage collected heap
US20030220952A1 (en) Method and system for the garbage collection of shared data
WO2000016196A1 (en) Method and apparatus for finding bugs related to garbage collection in a virtual machine
US6944637B2 (en) Reduced size objects headers
US6275985B1 (en) Method and apparatus for developing an application that implements garbage collection efficiently by combining proxy objects with compiler support

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20060301

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20080428

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20080725

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20080806

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20080828

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20081001

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20081029

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090116