JP2005100402A - オブジェクト指向プログラムのための領域ベースのメモリ管理 - Google Patents

Abstract

【課題】 参照されるオブジェクトを含む領域を動的に発見することができるシステムを提供すること。
【解決手段】 オブジェクト指向プログラムが、指定された領域内でオブジェクトを作成するように修正され、メモリ割り当て解除が、領域全体に対して同時に起こるようにする。内容、および領域の間の関連づけが、プログラムコードの分析から作成される１つまたは複数の形状グラフによって記述される。形状グラフによって格納される領域関連づけメタデータは、領域ベースのメモリ管理を行わせ、渡される各オブジェクトに対するメソッドに１つの領域のみが渡されることを要求する。
【選択図】 図１

Description

本発明は、概して、オブジェクト指向プログラムのためのメモリ管理に関する。

様々なプログラミング言語、たとえばＭＬ、Ｃ＃、およびＪａｖａ（登録商標）は、メモリの割り当てがプログラマによって制御されることを可能にするが割り当て解除（ｄｅ−ａｌｌｏｃａｔｉｏｎ）をランタイム機構によって自動的に実施するように構成される。こうしたランタイムシステムの大多数は、ガベージコレクタ（ｇａｒｂａｇｅ ｃｏｌｌｅｃｔｏｒ）を利用し、このガベージコレクタは、もはや使用されていないオブジェクトを見つけ、そのメモリを割り当て解除し再利用するために、実行中にオブジェクト参照を追跡する。しかし、ほとんどのガベージコレクションシステムは、欠陥による被害を被っている。こうした欠陥の主なものは、ランタイム実行コスト、ならびに、オブジェクトのメモリが再要求（ｒｅｃｌａｉｍｅ）され得るときと、ガベージコレクタがオブジェクトを見つけようとするときとの間の時間のずれがもたらされることである。

代案として、一部のシステムは、領域ベースのメモリ管理システムを利用する。領域ベースの方式では、領域は、メモリ中で、配置されるオブジェクトに対して割り振られ、メモリの割り当て解除は、オブジェクトレベルではなく領域全体に対して起こる。領域ベースのメモリ管理は、ランタイム環境が追跡しなければならないメモリ割り当ての回数を減らすことによってオーバーヘッドを削減し、ガベージコレクタが少しずつ行うであろうメモリの割り当て解除を統合する。領域の有用性の一例は、メソッドに対する呼出しが行われると、そのメソッドが、実行のためにデータ構造を作成するが、戻るときにそうしたデータ構造を削除することである。この状況において、このメソッドによって使われる各領域は、メソッドが呼び出されたときに作成され、次いで、メソッドが戻される時点で削除されることができる。

領域の数は通常、割り振られるオブジェクトの総数より少ないので、領域ベースのメモリ管理を用いるランタイムシステムは、領域内のオブジェクトに対する参照数のみを記録すればよい。このことは、参照カウントがゼロに達したとき、ランタイムシステムがただちに領域を割り当て解除することを可能にする。このことは、ガベージコレクションに関わる、絶えず行われる検索を回避し、メモリの再利用に対する時間のずれを低減する。

しかし、従来の領域ベースのメモリ管理システムは、それ自体の、追加のオーバーヘッドコストをもたらす。多くの既存システムは、コンパイル時に、領域が割り振られまたは割り当て解除されるときを正確に決定する。静的に決定されるこのメモリ管理を容易にするために、こうしたシステムの一部は、領域の割り当ておよび割り当て解除を、後入れ先出し（すなわちスタック）モデルに強制的に入れる。しかし、このタイプのシステムは、領域が割り当て解除されることができる順序を厳しく制限することにより、メモリ割り当て効率を低下させる。

他の既存システムでは、割り当ての順序は設定されないが、追加のオーバーヘッドコストが引き起こされる。というのは、メソッドにおいて使われることができるオブジェクトをどの領域が含もうとも、メソッドに渡されるオブジェクトは、その領域とともに渡されることをシステムが要求するからである。こうしたシステムの１つが、ＲｅｇＪａｖａ、すなわちＣｈｒｉｓｔｉａｎｓｅｎおよびＶｅｌｓｃｈｏｗによるＪａｖａ（登録商標）言語の拡張であり、オブジェクトがメソッドに渡されるときに、オブジェクトのクラスのすべてのサブクラスが知られており、ソースコードにおいて注釈がつけられることを要求する。このことは、コンパイル時に、渡されるオブジェクトによって参照される可能性のあるすべての領域が、呼び出されたメソッドに渡されることができることを保証するために行われる。サブクラスは、そのスーパークラスが含まないフィールドを頻繁に含むので、このことは、多くの領域が、所与のスーパークラスのオブジェクトによって参照される可能性があることを意味する。このことは、メソッドのパラメータとして多数の領域が渡されるという結果を生じ得る。この追加の引渡しは、使用可能なレジスタの数を超過し、より多くのオーバーヘッドをランタイムスタックに追加し、したがって、領域ベースのシステムによってもたらされる効率を低下させ、またはなくしてしまう可能性がある。

米国特許第６，０１４，５１８号明細書、Steensgaard, ”Terminating Polymorphic Type Inference Program Analysis” Erik Ruf, "Effective Synchronization Removal for Java（登録商標）" (2000)

必要とされるのは、参照されるオブジェクトを含む領域を動的に発見することができるシステムである。

形状グラフ（ｓｈａｐｅ ｇｒａｐｈｓ）を利用する領域ベースのメモリ管理システムが説明される。一実施形態では、メモリを複数の領域に区分し、１つまたは複数の形状グラフを使用することによって、オブジェクトが与えられると、そのオブジェクトを含む領域が見つけられることができるメモリ管理システムが記述される。別の実施形態では、領域ベースのメモリ管理システム用のオブジェクト指向プログラムをコンパイルする方法が記述される。この方法は、ソースコードを受け取り、次いで、コードに対してポイント先分析（ｐｏｉｎｔｓ−ｔｏ ａｎａｌｙｓｉｓ）を実施して、１つまたは複数の形状グラフを作成する。この方法は、実行されることができるコードを生成する前に、オブジェクト作成および領域削除に形状グラフを使用するための手段を追加する。

さらに別の実施形態では、コンピュータに、領域ベースのメモリ管理システム用のプログラムをコンパイルさせる命令を含むコンピュータ可読媒体が記述される。こうした命令は、コンピュータに、ソースコードを受け取らせ、コードに対するポイント先分析を実施させて、１つまたは複数の形状グラフを作成させ、実行されることができるコードを生成する前に、オブジェクト作成および領域削除に形状グラフを使用するための手段（ｉｎｓｔｒｕｍｅｎｔａｔｉｏｎ）を追加させる。

本発明の追加の特徴および利点が、添付の図面を参照して進行する、実施形態の以下の詳細な説明から明らかになるであろう。

以下の説明は、形状グラフを使用する、領域ベースのメモリ管理システムのための技術およびシステムを対象とする。こうしたシステムおよび技術は、コンパイル時に、オブジェクト指向プログラム用に１つまたは複数の形状グラフの作成を可能にする。こうしたグラフは、領域作成、および領域におけるオブジェクトの割り当て用のテンプレートを記述するメタデータを提供する。形状グラフは、プログラムが、グラフを分析し、そのグラフを用いて領域内にオブジェクトを配置すること、および領域を作成しアクセスすることを可能にする手段とともに、コンパイルされたプログラムに含められる。このことは、参照カウントによる割り当て解除方式と組み合わされることによって、現在の技術において存在するものより、少ないパラメータ渡し、およびより少ない使用上の限定を伴う、メモリ領域のより効率的な使用をもたらす。領域ベースのメモリ管理システムは、ガベージコレクタと組み合わされて、メモリ割り当て解除の効率を向上させることもできる。

（１．例示的な実施形態)
図１は、形状グラフを利用する、領域ベースのメモリ管理システムの一実装形態を示す。図示した実施形態は、オブジェクト指向プログラムコード１５０を受け入れて、コンパイルされたプログラム１６０にコンパイルするコンパイラ１００を示す。代替実装形態では、オブジェクト指向プログラムコードは、Ｊａｖａ（登録商標）ソースコード、Ｃ＃ソースコード、ＭＬソースコード、または他のソースコードを含むことができる。さらに、図示した実施形態は、１つのプログラムコードのコンパイルを示すが、別の実装形態では、多くの別個のコードまたはライブラリを含むコードが使われることができる。コンパイルされたプログラム１６０は、実行可能コード１６５および１つまたは複数の形状グラフ１７０を含み、次いで、複数の領域を備えるメモリ１４０を含む実行コンピュータ１３０によって実行されることができる。

図示した実施形態において、コンパイラ１００は、従来のコンパイルコンポーネント（図示せず）に加え、実行コンピュータ１３０における領域ベースのメモリ管理を容易にするための２つのモジュールを備える。図に示す、こうしたモジュールの一方が、形状グラフジェネレータ１１０であり、ジェネレータ１１０は、オブジェクト指向コード１５０を分析して、領域ベースのシステムにおける以降の実行を容易にするために、コンパイルされたプログラム１６０に含まれる少なくとも１つの形状グラフ１７０を作成するソフトウェアを備える。図に示す、コンパイラ１００の他方のモジュールは、メモリ管理コードジェネレータ１２０である。一実施形態では、このモジュールは、オブジェクト指向プログラムコード１５０を分析するとともに、領域およびオブジェクトの割り当て、領域の間の関連づけ、ならびに領域の位置決めなど、領域ベースのメモリ管理活動を容易にするための追加手段を、コンパイルされたプログラム１６０の実行可能コード１６５に挿入するソフトウェアを備える。一実装形態では、形状グラフジェネレータおよびメモリ管理手段ジェネレータは、別個のソフトウェアモジュールを備えるのではなく、コンパイラ１００に組み込まれる。一実装形態では、メモリ管理コードジェネレータ１２０は、オブジェクト指向プログラムコード１５０にコードを直接追加する。別の実装形態では、ジェネレータ１２０は、既にコンパイルされているプログラム１６０の実行可能コード１６５を実行のために使用可能にする前に、実行可能コード１６５にマシンコードまたはバイトコードを直接挿入する。

（２．形状グラフを含む、領域ベースのメモリの例）
図２は、領域ベースのメモリ１４０を使用する例示的なコンピュータ１３０を示すブロック図を示す。図に示す実施形態において、メモリは、それぞれが様々なオブジェクト２３０を含む３つの領域２１０を備える。図２が示すように、領域ベースのメモリシステムに含まれるオブジェクトは、オブジェクト２３０をつなぐ細い矢印によって示されるように、他のオブジェクトへの参照を含むことができる。たとえば、図２の領域ａにあるオブジェクトＣは、領域βにあるオブジェクトＤへの参照、および領域ｅにあるオブジェクトＥへの参照の両方を含む。さらに、オブジェクトＡも、オブジェクトＤへの参照を含み、オブジェクトＢは、オブジェクトＦへの参照を含む。一実装形態では、こうした参照は、オブジェクトＡ、Ｂ、およびＣに含まれるフィールドを含む。あるいは、オブジェクトへの参照は、メソッドすなわち関数のローカル変数中に保持されることもできる。平易にするために、本明細書で使用する「フィールド」という用語は、概して、オブジェクトクラスにおいて記述されるフィールドだけでなく、グローバル変数およびローカル変数を含むどのオブジェクト参照も指す。

図２は、太い矢印２４０によって示される、領域２１０の間の関連づけも示す。図に示す例において、こうした関連づけは、領域内に含まれるオブジェクトの間に参照が存在することを表す。したがって、領域ａ内のオブジェクトが、領域ｅ内のオブジェクトへの参照を含むので、この２つの領域は、関連づけを共有する。好ましい実施形態では、こうした関連づけは、実際には、コンピュータ１３０において別個のエンティティとして保持されるのではなく、１つまたは複数の形状グラフ中に保有され、こうした形状グラフは、領域とともに保持されて、コンピュータ１３０が、オブジェクトを配置し、領域の関連づけを作成することを可能にする。したがって、この例では、形状グラフ２５０が、領域ａとともに保持され、このことは、領域ａが、図に示す他の２つの領域に含まれるオブジェクトを有することを示す。図に示す例は、領域ａとの関連づけにおいて１つの形状グラフ２５０を保持することを示すが、代替実装形態では、複数の形状グラフが保持されることができる。図に示す例では、形状グラフ２５０は、領域ａとともに保持されるが、別の実装形態では、形状グラフは、メモリ領域２１０とは別個に保持される。あるいは、可能なすべての領域の間の関連づけを記述するグローバル形状グラフが保存されることもできる。

形状グラフ２５０は、領域を表すノードと、領域の間の関連づけを示す、ノードの間の有向エッジとを含むことにより、オブジェクト参照に基づいて領域の間の関連づけを保持するメタデータを含む。一実装形態では、形状グラフのエッジは、参照名を表す。一例として、形状グラフ２５０は、領域ａ内のオブジェクト中の、「エージ（ａｇｅ）」と呼ばれるフィールドによって参照されるどのオブジェクトも、「エージ」エッジによってつなげられるａノードおよびβノードを含むことによって、領域βに含まれるという、情報を含むことができる。代替実装形態では、形状グラフは、オブジェクトタイプ、参照の保護レベルなど、異なる情報または付加情報によって、または、一義的なフィールド識別子を使用することによって、領域を関連づけることができる。一実装形態では、形状グラフは、ノードおよびエッジを記述するデータ構造として保持される。代替実装形態では、領域の間の関連づけを保持するメタデータを含む限り、異なるデータ構造が使われることができる。

一実施形態では、領域は、プログラムの実行中に、形状グラフ１７０中の情報に基づいて、割り振られ、互いに関連づけられる。この割り当ておよび関連づけは、形状グラフを、ランタイムの領域作成および関連づけ用のテンプレートとして用いることによって実施される。一実装形態では、領域は、その領域が最初に使われる実行中に作成される。別の実装形態では、ある領域が作成されるとき、その領域が、形状グラフの到達可能な部分集合中に記述される場合、その部分集合中で表される他のすべての領域も作成される。

図２は、実行プログラム２６０において実行されるランタイム形状グラフハンドラモジュール２７０も示し、モジュール２７０は、形状グラフ２５０を分析して、領域の関連づけを判定し、オブジェクトを正しく割り当て、領域の割り当ておよび割り当て解除を実現することができる。たとえば、コンピュータ１３０におけるプログラム実行中のある特定の時点において、オブジェクトＤがまだ作成されていない場合、形状グラフハンドラモジュール２７０は、メモリ領域βを作成し、オブジェクトＤが作成されるときに領域β内にオブジェクトＤを割り振ることができる。図示した実施形態において、形状グラフハンドラ２７０は、実行プログラム２６０内部に別個のモジュールを備える。別の実装形態では、個別のランタイム環境が存在せず、形状グラフハンドラの関数は、コンパイル時に、コンパイルされたプログラム１６０に含められる。さらに別の実装形態では、形状グラフハンドラは、実行プログラムが実行されるランタイム環境に組み込まれる。

（３．形状グラフの作成）
図３は、一実施形態における、形状グラフを利用する、領域ベースのメモリ管理を使用するプログラムを作成する処理を示す。代替実装形態では、図３に表される処理は、変更されることができる。すなわち、ブロックは、異なる順序で実施され、結合され、または下位ブロックに分割されることができる。処理は、ブロック３１０で始まり、ここで、プログラムコード１５０が分析されて、１つまたは複数の形状グラフ１７０を作成する。形状グラフの作成処理は、図４、５、および６に関連してより詳細に説明される。図３の処理は、ブロック３２０に進み、ここで、コンピュータ１３０がランタイム時に形状グラフを使用することを可能にするための手段が、メモリ管理コードジェネレータ１２０によってオブジェクト指向プログラムコード１５０に追加される。次に、ブロック３３０で、実行可能コードが、修正されたオブジェクト指向プログラムコード１５０から生成される。最後に、ブロック３４０で、ブロック３１０の処理で作成された形状グラフ１７０が、ブロック３３０の処理で生成された実行可能コード１６５とともに含められて、完成した、コンパイルされたプログラム１６０を作成する。

図４は、形状グラフを作成するために形状グラフジェネレータ１１０によって実施される、図３のブロック３１０の処理の一例を示す。代替実装形態では、図４に表される処理は、変更されることができる。すなわち、ブロックは、異なる順序で実施され、結合され、または下位ブロックに分割されることができる。一実施形態では、図４の処理は、非特許文献１（「Ｒｕｆ」）による、位置決め同期のための文脈依存型ポイント先分析の変更版である。代替実装形態は、文脈依存または文脈非依存である、異なる形状グラフ作成処理を利用することができる。以下で説明する処理は、「メソッド」という用語を使用するが、処理は、他の用語、たとえば「関数」を使用するプログラミング言語にも適用されることが理解されよう。代替実施形態では、特許文献１（「Ｓｔｅｅｎｓｇａａｒｄ」）に記述されているのと同様の種類のポイント先分析アルゴリズムが使用される。

処理は、ブロック４１０で始まり、ここで、静的コールグラフを計算するためにプログラムが分析される。このグラフは、すべてのメソッドに関して、そのメソッドによってどのメソッドが呼び出されるかを示す。後続ブロックは、形状グラフのノードおよびエッジがそこから作成されるエイリアスセットの作成および処理に関わる。Ｒｕｆに記述されているエイリアスセットとは、フィールド名から他のエイリアスセットへのマッピングに伴う１組のオブジェクト参照を表すのに用いられるデータ構造である。一実装形態では、フィールド名は、プログラムコード１５０において使われる際にエイリアスセットによって表されるオブジェクトのフィールドに由来する。

フィールドから他のエイリアスセットへのマッピングの格納に加え、エイリアスセットは、Ｒｕｆによって詳述されている、既存エイリアスセットを結合する単一化（ｕｎｉｆｉｃａｔｉｏｎ）動作をサポートする。単一化動作は、プログラムコード１５０に含まれるステートメントに従って実施される。オブジェクト指向プログラムを分析する間、図４の処理は、エイリアスセットの作成および単一化を利用して、プログラムにおいてオブジェクト参照を一体となって表すエイリアスセット群を生じさせる。オブジェクト指向プログラムを分析した後、図４の処理は、プログラムにおけるすべてのオブジェクト参照を一体となって表すエイリアスセット群を作成済みである。エイリアスセットのマッピングによって定義される連結エッジを用いて、エイリアスセットから形状グラフノードを作成することにより、形状グラフが作成される。異なる実装形態では、形状グラフは、形状グラフの有向グラフ性が保持される限り、様々なデータ構造において保持されることができる。

Ｒｕｆは、非特許文献１において、エイリアスセットの正式な使用法および構成の１つを記述しているが、Ｒｕｆに記述されるエイリアスセットは、形状グラフの作成に必要とされない付加データを含む。したがって、一実装形態では、エイリアスセットは、フィールドマップと、エイリアスセットが参照するオブジェクト参照の１つが、グローバル変数から到達されることができるかどうかという指示とのみを含む。一例として、「名称」および「エージ」というフィールドを有するオブジェクトに対する参照用のエイリアスセットは、＜＜

＞，ｎｏ＞を含むことができ、ａ_１およびａ_２は、それぞれオブジェクトの「名称」および「エージ」フィールドによって行われる参照を表す他のエイリアスセットであり、「ｎｏ」は、変数が、静的グローバル変数から到達されることができないことを示す。一実装形態では、グローバルな到達可能性情報は、形状グラフを作成するために保有されるが、実行には必要とされない。したがって、一実装形態では、到達可能性情報は、形状グラフの最終的な作成の前に破棄されることができる。

ブロック４２０に進むと、エイリアスセットが、オブジェクト指向プログラムコード中の各オブジェクト参照に対して計算される。Ｒｕｆによって記述されるエイリアスセットは、最初に空のフィールドマップを有して作成されるので、ブロック４２０において各フィールドに対して作成されるエイリアスセットは、空になるように作成される。処理は、ブロック４３０に進み、ここで、ブロック４１０で作成された静的コールグラフが、１組の強結合（ｓｔｒｏｎｇｌｙ−ｃｏｎｎｅｃｔｅｄ）コンポーネントに分割され、こうしたコンポーネントは、個々に分析されることになる。この処理は、形状グラフジェネレータモジュール１１０が、プログラムコード１５０をより小さいセグメントにおいて分析し、メソッドと、強結合コンポーネント中で参照されないフィールドとを無視することを可能にし、分析効率を向上させる。別の実装形態では、コールグラフは、強結合コンポーネントに分割されない。さらに、ブロック４３０で、強結合コンポーネントは、順序通りに配置される。好ましい実装形態では、この配置は、上昇式のトポロジカル順序で行われるが、他の実装形態では、他の順序づけが使用されることができる。

次に、ブロック４４０で、プログラムコード１５０中のステートメントに基づいて、エイリアスセットを作成し単一化するために、第１の強結合コンポーネントが分析される。この分析処理は、図５および６に関して後でより詳細に説明される。第１の強結合コンポーネントが分析された後、処理は、判断ブロック４６０に進み、ここで、形状グラフジェネレータ１１０は、それ以外の強結合コンポーネントがあるかどうか判定する。強結合コンポーネントがある場合、処理は、ブロック４５０に進み、ここで、次の強結合コンポーネントが分析され、処理が繰り返される。それ以外の強結合コンポーネントがない場合、処理はブロック４７０に進み、ここで、ブロック４４０および４５０の分析によって修正され充実されたエイリアスセットが、形状グラフに変換される。一実装形態では、グローバルな到達可能性に関する、エイリアスセットに含まれる情報は、形状グラフの作成前に破棄される。次いで、処理が終了する。

図５は、コンパイラ１００の形状グラフジェネレータ１１０によって実施される、プログラムコード１５０の強結合コンポーネント（「ＳＣＣ」）を分析して、形状グラフを作成する、図４のブロック４４０および４５０の処理の一例を示す。代替実装形態では、図５に表される処理は、変更されることができる。すなわち、ブロックは、異なる順序で実施され、結合され、または下位ブロックに分割されることができる。処理は、ブロック５０５で始まり、ここで、分析されている強結合コンポーネント中の各メソッドに対して、メソッドの初期コンテキストが作成される。Ｒｕｆが述べているように、メソッドのコンテキストとは、＜＜ｆ_０，．．．，ｆ_ｎ＞，ｒ，ｅ＞の形の組であり、ｆ_ｉ、ｒ、およびｅはそれぞれ、そのメソッドに対する、メソッドの呼出し側によって受け取られる仮（ｆｏｒｍａｌ）の値、戻り値、および例外値に対応するエイリアスセットである。代替実装形態では、複数の例外値が使われてもよく、例外値が全く使われなくてもよい。メソッドのコンテキストは、呼び出されたメソッド中で作成されたエイリアスセットが、メソッドが呼び出されたコンテキスト用に作成されたエイリアスセットによって体系的に反映されることを可能にするために作成され、より完全で文脈依存である形状グラフテンプレート分析を行う。次に、ＳＣＣ中の各メソッドが分析される。

処理はブロック５１０に進み、ここで、分析された第１のメソッド中の各パラメータ変数が、メソッドのコンテキストにある、その対応するエイリアスセットに関連づけられる。処理は次いで、ブロック５１５で、第１のステートメントを分析して、そのステートメント中で実施される処理を決定する。Ｒｕｆが述べているように、ステートメントが、参照変数を変更し、値を処理し、またはメソッドを呼び出す場合、エイリアスセットは、単一化される必要があり得る。次に、判断ブロック５２０で、形状グラフテンプレートジェネレータ１１０は、分析されたステートメントがメソッド呼出しであるかどうか判定する。メソッド呼出しである場合、処理はブロック５２５に進み、ここで、エイリアスセットの単一化が、特定のメソッド呼出し規則に従って実施される。メソッド呼出しを介してエイリアスセットを単一化する処理は、図６の処理に関連して、後でより詳細に説明される。

ただし、判断ブロック５２０で、ステートメントがメソッド呼出しでないと判定された場合、処理はブロック５３０に進み、ここで、エイリアスセットは、エイリアスセット分析規則に従って単一化される。一例として、ｖ_０およびｖ_１がローカルなオブジェクト参照であり、ｆがフィールド名であるステートメントｖ_０＝ｖ_１．ｆが遭遇される場合、単一化が起こる。与えられた例では、規則は、ｖ_０に関連づけられたエイリアスセットと、ｖ_１に対するエイリアスセット中のｆによってマッピングされるエイリアスセットとを単一化させる。この単一化の具体的な影響は、ｖ_０への参照を、ｖ_１のｆフィールドからの参照と同じエイリアスセットに導かせることである。その後、形状グラフが実行時に使われるとき、ｖ_０変数によって参照されるオブジェクト、およびｖ_１のｆフィールドによって参照されるオブジェクトは、同じ領域に割り振られる。分析規則一覧の一例は、Ｒｕｆにおいて見られることができる。

ステートメントタイプに関わらず、処理は次いで、判断ブロック５４０に進み、ここで、形状グラフジェネレータは、現在分析されているメソッドに、他のステートメントが存在するかどうか判定する。他のステートメントが存在する場合、処理はブロック５５０に進み、ここで、メソッド中の次のステートメントが分析される。メソッド中にそれ以上のステートメントがない場合、処理は判断ブロック５４５に進み、ここで、形状グラフジェネレータは、ＳＣＣ中に他のメソッドが存在するかどうか判定する。存在する場合、処理はブロック５５５に進み、ここで、次のメソッド中のパラメータ変数が、そのメソッドのメソッドコンテキストにあるエイリアスセットに関連づけられる。ただし、ＳＣＣ中にそれ以上のメソッドがない場合、図５の処理は終わる。

図６は、コンパイラ１００の形状グラフジェネレータ１１０によって実施される、メソッド呼出しによるエイリアスセットの単一化またはインスタンス化を実施する、図５のブロック５２５の処理の一例を示す。一実装形態では、図６で表される処理を受けるメソッド呼出しは、特別に定義されたクラスメソッドだけでなく、コンストラクタメソッドおよびデストラクタメソッドも含む。代替実装形態では、図６に表される処理は、変更されることができる。すなわち、ブロックは、異なる順序で実施され、結合され、または下位ブロックに分割されることができる。処理は、ブロック６１０で始まり、ここで、サイトのコンテキストがメソッド呼出しに対して作成される。サイトのコンテキストは、メソッドのコンテキストと同じ＜＜ｆ_０，．．．，ｆ_ｎ＞，ｒ，ｅ＞の形をとるが、ｆ_ｉは、呼出し側から受け取られ、または呼出し側に戻される値を表すのではなく、呼ばれる側に送られる実際の値を表し、ｒおよびｅは、呼ばれる側によって戻される値を表す。

次に、判断ブロック６２０で、形状グラフジェネレータ１１０は、メソッド呼出しが再帰的であるかどうか判定する。呼出しが再帰的でない場合、処理はブロック６３０に進み、ここで、呼び出されたメソッドに対するメソッドコンテキストの新しいインスタンスが作成される。一実装形態では、新しいメソッドコンテキストの作成は、元のエイリアスセットと同形のエイリアスセットを有するメソッドコンテキストを作成する。この実装形態において、新しいインスタンスにおいて使用される同形エイリアスセットは、コピーされる元のエイリアスセットがグローバル変数から使用可能でない限り、そのエイリアスセットからなる新しく作成されるインスタンスである。この場合、元のエイリアスセットは、新しいメソッドコンテキストのインスタンスにおいて使用される。次に、ブロック６４０で、サイトコンテキストの各エイリアスセットを、新しいメソッドコンテキスト中の、それと対応するエイリアスセットと単一化することによって、サイトコンテキストが、メソッドコンテキストの新しいインスタンスと単一化される。メソッドコンテキストの新しいインスタンスの作成は、文脈依存分析を可能にする。この単一化の後、処理は終わる。代替実装形態では、ブロック６３０および６４０によって記述される処理の効果は、Ｓｔｅｅｎｓｇａａｒｄにおいて論じられているのと同様の種類の多様型推論を用いるインスタンス化処理によって達成される。

ただし、ブロック６５０で、メソッド呼出しが再帰的である場合、呼出しサイトのコンテキストは、新しいメソッドコンテキストを作成することなく、呼び出されたメソッドに対する既存のメソッドコンテキストと単一化される。一実装形態では、再帰的なメソッド呼出しの異なる処理は、文脈非依存性をもたらすが、この処理は、再帰的な呼出しに対する固定点が到達されるまで、ＳＣＣ全体に渡って反復しなければならないという実行コストを防ぐ。この単一化の後、処理は終わる。代替実装形態では、ブロック６５０によって記述される処理の効果は、Ｓｔｅｅｎｓｇａａｒｄにおいて論じられているのと同様の種類の多様型推論を用いるインスタンス化処理によって達成される。

（４．領域作成およびオブジェクトの割り当てに対する形状グラフの効果の例）
図７ａおよび７ｂは、一般的な形状グラフによる、領域に格納されるオブジェクトの２つの例を示す。図に示す例では、形状グラフは、別個のエンティティとして示されるのではなく、図に示す、領域をつなぐエッジによって示される。両方の例が導出される形状グラフは、以下のコードの分析から作成される。

こうした２つの例は、プログラムの実行に依存する、領域内に配置されるオブジェクトのタイプおよび数の違いを示す。このコード例の、可能な２つの実行は、引数の長さによってパラメータ化される。コードの分析は、図７ａおよび７ｂが示すように、５つのメモリ領域を作成するためのテンプレートを含む形状グラフを作成する。第１のメモリ領域、すなわち領域７００は、実行後は常に、ローカルフィールド「ｔａｂｌｅ」によって参照されるＴａｂｌｅオブジェクトを含む。第２のメモリ領域、すなわち領域７１０は、領域７００のＴａｂｌｅの「Ｏｎｅ」フィールドによって参照されるＰａｉｒオブジェクトを常に含む。

ただし、領域７２０は、異なるタイプのオブジェクトを含むこともできる。形状グラフは、領域７２０を、領域７００のオブジェクトの「ｔｗｏ」フィールドによって参照されるオブジェクトを含むものとして記述する。しかし、図７ａ、および図７ｂが示すコードのように、コードのある実行では、Ｐａｉｒオブジェクトが領域７２０内に割り振られ、コードの別の実行では、Ｔｒｉｐｌｅオブジェクトが、領域７２０内に配置される。ＴｒｉｐｌｅがＰａｉｒのサブクラスであり、図７ａのＰａｉｒまたは図７ｂのＴｒｉｐｌｅが、最終的には領域７００内のオブジェクトの「ｔｗｏ」フィールドによって参照されるので、この配置が行われる。したがって、図７ａおよび７ｂが示すように、領域は、異なるクラスのオブジェクトを含むことができる。図７ａおよび７ｂは、一実装形態では、分析が、パブリックフィールドとプライベートフィールドの間の違いを形状グラフに組み込まないことも示している。「Ｏｎｅ」フィールドはパブリックフィールドであり、「ｔｗｏ」フィールドはプライベートフィールドであるが、両方ともオブジェクトを参照するので、両方とも形状グラフに含められる。

領域７００および７１０の場合のように、図７ａおよび７ｂ両方が形成されるための形状グラフは、領域７３０を、領域７２０のオブジェクトの「ｌｅｆｔ」フィールドによって参照されるオブジェクトを含むものとして記述し、領域７４０を、領域７２０内のオブジェクトの「ｒｉｇｈｔ」フィールドによって参照されるオブジェクトを含むものとして記述する。ただし、領域７４０は、プログラムの実行に応じて異なる内容をもつことができる。図７ａは、プログラム引数の長さが１より大きい場合のプログラム実行を示し、「ｔｗｏ」フィールドは、「ｌｅｆｔ」フィールドおよび「ｒｉｇｈｔ」フィールドのみをもつＰａｉｒオブジェクトを参照する。したがって、領域７４０には、「ｒｉｇｈｔ」によって参照されるただ１つのオブジェクトしかない。対照的に、図７ｂでは、「ｔｗｏ」フィールドは、Ｔｒｉｐｌｅオブジェクトを参照し、Ｔｒｉｐｌｅオブジェクトは、Ｐａｉｒの「ｌｅｆｔ」フィールドおよび「ｒｉｇｈｔ」フィールドを含むだけでなく、「ｍｉｄｄｌｅ」フィールドをさらに含む。また、図７ａおよび７ｂ用のテンプレートを提供する形状グラフは、「ｍｉｄｄｌｅ」フィールドおよび「ｒｉｇｈｔ」フィールド両方によって参照されるオブジェクトは同じ領域に含まれるべきであると規定するので、図７ｂにおいて、領域７４０は、「ｍｉｄｄｌｅ」フィールドおよび「ｒｉｇｈｔ」フィールドによって参照される２つのオブジェクトを含む。

図に示す例において、形状グラフは、「ｍｉｄｄｌｅ」フィールドおよび「ｒｉｇｈｔ」フィールド両方の参照先を、別個の領域に置くのではなく、同じ領域にあるものとして記述する。一実装形態では、この配置は、形状グラフ作成に関して、Ｒｕｆによって論じられたエイリアスセットの使用の必然的な結果である。図７ａおよび７ｂの例におけるこの結果の原因は、メインメソッドにおける「ｓｈａｒｅｄ」参照の存在である。プログラムの、可能な２つの実行の下で、「ｓｈａｒｅｄ」は、領域７２０内のＰａｉｒオブジェクトの「ｒｉｇｈｔ」フィールドまたは領域７２０内のＴｒｉｐｌｅオブジェクトの「ｍｉｄｄｌｅ」フィールドのいずれかに割り当てられることができる。「ｒｉｇｈｔ」フィールドへの割当ての結果、「ｓｈａｒｅｄ」フィールドおよび「ｒｉｇｈｔ」フィールドによって参照されるオブジェクトは、同じ領域になければならない。同様に、「ｍｉｄｄｌｅ」フィールドへの割当ての結果、「ｓｈａｒｅｄ」フィールドおよび「ｍｉｄｄｌｅ」フィールドによって参照されるオブジェクトは、同じ領域になければならない。ただし、オブジェクトが終始一貫して使用可能であるようにするために、フィールド「ｓｈａｒｅｄ」は、１つの領域内のオブジェクトのみを参照する。したがって、上記のコード例の場合、「ｍｉｄｄｌｅ」および「ｒｉｇｈｔ」によって参照されるオブジェクトを同じ領域に置く形状グラフが作成される。

（５．形状グラフを使用する手段）
図８は、メモリ管理コードジェネレータ１２０によってブロック３２０で実施される、形状グラフを使用するための手段を追加する処理の一実装形態を記述する。代替実装形態では、図８に表される処理は、変更されることができる。すなわち、ブロックは、異なる順序で実施され、結合され、または下位ブロックに分割されることができる。一実装形態において図８の処理によって追加される手段は、コンパイルに先立って、メソッド呼出しやインラインコードなどのソースコードとして追加されることができる。あるいは、手段は、コンパイルがそれに対して開始され、または完了している、たとえばバイトコードやマシンコードの形のコードに追加される。さらに、何らかの手段を含めることは、新しいコードの追加だけでなく、既存プログラムコードの処理または変換を伴う場合がある。一実装形態は、領域および形状グラフ処理ルーチンを、実行プログラム２６０の形状グラフハンドラ２７０に統合するが、他の実装形態では、ルーチンは、概してオブジェクト指向プログラムのコードに組み込まれる。

処理は、ブロック８１０で始まり、ここで、領域作成手段が追加される。一実装形態では、手段は、グローバル形状グラフを受け入れ、形状グラフのどの領域が必要とされるかという指示に基づいて、領域を割り振る。別の実装形態では、領域を記述するのに必要な形状グラフのセクションのみが、領域作成手段に与えられる。さらに、様々な実装形態が、実行中の別々のときに領域を作成することができる。一実装形態では、形状グラフの到達可能な部分集合に対応する全領域が同時に作成される。別の実装形態では、領域は、プログラムからの必要に応じて作成される。

領域作成手段は、一実装形態では、形状グラフにおいて強結合である領域の組を同時に作成する手段も含むことができる。一実装形態では、どの領域がプログラムの実行中に依然として使われているかを追跡するのに、参照カウンタが用いられるので、この同時作成手段は有用である。強結合の組中の各領域ごとに別個のカウンタが保有される場合、プログラムの実行中に、その組に含まれないどの領域からの参照も存在しないという状況が起こり得るが、その組の強結合性により、内部では参照が依然として存在し得る。したがって、領域用の参照カウンタは、プログラムのそれ以外の部分と比較して、その組が「非活動（ｄｅａｄ）」状態であり、その組に含まれないどのオブジェクトによっても再度参照されることができないとしても、ゼロになることはない。ゼロにならないカウンタは、領域を割り当て解除し、そのメモリをシステムに返すのではなく、領域を活動（ａｌｉｖｅ）状態に人工的に保つ。したがって、一実装形態では、形状グラフが、１組の強結合領域を記述していると判定された場合、すべての領域を、別個にではなく同時に作成する手段が追加される。別の実装形態では、上述した問題を回避するために、参照カウンタに関連して異なる手段が有用だとしても、強結合領域の組は同時に作成されない。別の実装形態では、ポイント先グラフ中の強結合コンポーネントは、形状グラフ中の単一のノードに削減され、このことは、形状グラフが有向非循環グラフであることを保証する。

処理は次いで、ブロック８２０に進み、ここで、プログラムが領域参照をカウントすることを可能にする手段が追加される。一実装形態では、この手段は、すべての領域用の参照カウント変数の作成を伴う。別の実装形態では、強結合領域の組に対する参照カウント変数は、強結合の組に含まれない領域からの参照のみをカウントする単一のカウントに組み合わされる。強結合領域の組に対して単一のカウントを使うことは、その組の中の領域における参照を無視することによって、上述した問題を防止する。あるいは、単一のカウントは、実行中の各時点において強結合である、強結合の組の各部分集合に対して保有されることができる。より大きい強結合の組の部分集合が、ランタイム中に参照によってリンクされると、カウントは、単一のカウントに併合されることができる。

領域に対する参照カウントに加え、ブロック８２０で、メモリ管理コードジェネレータ１２０は、参照カウントを増分し減分するための手段も追加する。一実装形態では、コードは、参照が作成される前に、参照が作成される領域に対して参照カウントを増加するために追加される。したがって、オブジェクトへの参照が作成される度に、そのオブジェクトの領域用の参照カウントが、１ずつ増加される。減分手段の一実装形態では、コンパイル時に、メモリ管理コードジェネレータ１２０によって、いつ参照カウントが減分されることができるか判定するために、最終使用分析がコードに対して実施される。別の実装形態では、参照カウンタを減分する手段は、領域、およびその領域に含まれるオブジェクトを割り当て解除するための手段をさらに含む。さらに、上述した実装形態では、領域の強結合の組から、領域におけるオブジェクトへの参照の追加は、増分を行うための、組全体に対する単一のカウントを生じさせることもでき、カウントの合併も引き起こすことができる。

ブロック８３０で、オブジェクト割り当て手段がプログラムに追加される。一実装形態では、この手段は、オブジェクト割り当てルーチンまたはメソッドを含み、このルーチンまたはメソッドは、領域、およびオブジェクトのタイプまたはサイズの指示を受け、領域内でオブジェクトを割り振る。

ブロック８４０で、フィールド設定手段が追加される。一実装形態では、この手段は、２つの既存領域およびフィールドの指示を受け、フィールドに対応するエッジを第２の領域に設定することによって、形状グラフによって提供されるテンプレートを投入（ｐｏｐｕｌａｔｅ）するルーチンまたはメソッドを含む。この手段は、プログラムが必要と思うときに、実行中にゆっくり作成される領域が、既に存在する領域に関連づけられることを可能にする。この関連づけは、新しいオブジェクトを参照するフィールドの設定、およびより古い領域内のオブジェクトを参照するための、新しいオブジェクト中のフィールドの設定の両方に対して行われることができる。

ブロック８５０で、領域がルックアップされることを可能にする手段が追加される。ルックアップは、複数のやり方で行われることができる。一実装形態では、領域、およびその領域内でオブジェクトによって使用されるフィールドの指示が与えられると、与えられたフィールドによって参照されるオブジェクトを含む領域を見つけるルックアップルーチンまたはメソッドが用いられる。

別の実装形態では、領域が、特定の状況において見つけられ、そうすることによって、ブロック８４０に関連して上述したフィールド設定ルーチンが使われることができるようにするための追加手段が追加される。具体的には、これは、入力オブジェクトを受け取り、入力オブジェクトを含む領域から到達可能な領域内に新しいオブジェクトを作成するメソッドに対して行われる。新しいオブジェクトを含む領域が、入力オブジェクトを含む領域からのみ間接的に到達可能であるという状況がある。したがって、プログラムが、ランタイム時に、形状グラフから入力オブジェクトを含む領域を識別し、入力オブジェクトを含む領域から新しいオブジェクトを含む領域までの１つのパスまたは複数のパスを確立するのに必要な領域および領域エッジを作成する間、新しいオブジェクトの領域を見つけるために形状グラフをトラバース（ｔｒａｖｅｒｓｅ）することを可能にする手段が追加される。この手段は、この特定の例に限定されない。すなわち、形状グラフをトラバースし、直接には使用可能でない領域への参照を解決するのに手段の追加を必要とするプログラムコードの構造に応じて、他の状況が起こり得る。

ブロック８５０の別の実装形態において、メソッドの実行中に領域が見つけられることを可能にするための手段が追加される。一実装形態では、この手段は、オブジェクトを与えられると、そのオブジェクトが含まれる領域を提供する異なるルックアップルーチンを含む。領域は、領域内のオブジェクトから直接見つけられることができるので、この実装形態は、プログラムが、使用可能な形状グラフの削減された組を用いて実行されることを可能にする。したがって、オブジェクトは、追加パラメータをもたないメソッドに渡されることができる。ただし、この実装形態は、ランタイムメモリ中にオブジェクトと領域の間の多くの関連づけを保有する必要があるので、追加のオーバーヘッドをもたらす場合がある。

あるいは、オブジェクトと領域の間のすべての関連づけを追跡するのではなく、別の実装形態は、オブジェクトがメソッドに渡されるとき、形状グラフを使って、そうしたオブジェクトを含む領域を見つける。これは、オブジェクトがメソッドに渡されるとき、そのオブジェクト用の領域が、形状グラフを用いて見つけられ、同様にそのメソッドに渡されるようにする手段を追加することによって行われ、領域が、メソッド実行中に正しく保持されることを可能にする。これは、多くの領域が各オブジェクトとともに渡されている点で、ＣｈｒｉｓｔｉａｎｓｅｎおよびＶｅｌｓｃｈｏｗによって述べられている技術と似ている。しかし、本明細書において述べる技術では、渡されるオブジェクトごとに、多くとも１つの領域が渡されるので、ＣｈｒｉｓｔｉａｎｓｅｎおよびＶｅｌｓｃｈｏｗの技術において必然的に含まれるオーバーヘッドが大幅に削減される。さらに、メソッドの入力オブジェクトを含む領域のみを渡すことは、コンテキストから外れた領域情報が、メソッドに組み込まれることを防止し、そうすることによって、メソッドを調べているプログラマが、そのメソッドを呼び出しているメソッドも、そのメソッドが呼び出しているメソッドも参照することなく、メソッドを調べることを可能にする。

一実装形態では、引数オブジェクト区域を含む領域は、メソッド呼出しを行うとき、常に引数オブジェクトとともに渡される。別の実装形態では、領域は、オブジェクト指向コードの分析が、引数オブジェクトの領域において、または引数オブジェクトの領域から到達可能な領域において、オブジェクトを割り振る可能性があると識別したメソッドにのみ渡される。別の実装形態では、領域は、１つまたは複数の引数領域、あるいは引数オブジェクトの領域から到達可能な１つまたは複数の領域を割り当て解除する可能性があると分析が識別したメソッドにも渡される。

一実装形態では、グローバルに保持される形状グラフは、全メソッド呼出しに対するものであるとみなされる。別の実装形態では、グローバル形状グラフの部分グラフが、図２に示すように領域に関連づけられ、そうすることによって、形状グラフの必要な部分のみが、メソッド呼出しの前に調べられるようになる。

（６．計算機環境）
上述したコンパイラ１００および実行コンピュータ１３０（図１）は、一般的ないくつかの例として、様々な形式（パーソナル、ワークステーション、サーバ、可搬型、ラップトップ、タブレット、または他のモバイル型）のコンピュータ、分散計算機ネットワーク、およびウェブサービスを含む、様々な計算装置および環境のいずれにおいても実装されることができる。コンパイラ１００およびランタイム環境２６０は、図９に示すようなコンピュータまたは他の計算機環境内で実行される、ハードウェア回路、ならびにコンパイル用ソフトウェアまたはランタイムソフトウェアにおいて実装されることができる。

図９は、説明した技術が実装されることができる適切な計算機環境９００を一般化した例を示す。計算機環境９００は、本発明の使用または機能の範囲に対するどのような限定を示すことも意図されない。というのは、本発明は、多様な汎用または専用計算機環境において実装されることができるからである。

図９を参照すると、計算機環境９００は、少なくとも１つの処理装置９１０およびメモリ９２０を含む。図９において、最も基本的なこの構成９３０は、破線内に含まれる。処理装置９１０は、コンピュータ実行可能命令を実行し、実プロセッサでも仮想プロセッサでもよい。多重処理システムでは、処理能力を向上するために、複数の処理装置がコンピュータ実行可能命令を実行する。メモリ９２０は、揮発性メモリ（たとえば、レジスタ、キャッシュ、ＲＡＭ）、不揮発性メモリ（たとえば、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリなど）、またはこの２つの何らかの組合せでよい。一実装形態では、メモリ９２０は、コンパイラ１００またはランタイム環境２６０を実装するソフトウェア９８０を格納する。

計算機環境は、追加の機能を有することもできる。たとえば、計算機環境９００は、記憶装置９４０、１つまたは複数の入力装置９５０、１つまたは複数の出力装置９６０、および１つまたは複数の通信接続９７０を含む。バス、コントローラ、またはネットワークなどの相互接続機構（図示せず）が、計算機環境９００のコンポーネントを相互接続する。一般に、オペレーティングシステムソフトウェア（図示せず）が、計算機環境９００において実行される他のソフトウェアのための動作環境を提供し、計算機環境９００のコンポーネントの活動を調整する。

記憶装置９４０は、取外し可能でも固定型でもよく、磁気ディスク、磁気テープまたはカセット、ＣＤ−ＲＯＭ、ＣＤ−ＲＷ、ＤＶＤ、あるいは情報を格納するのに使われることができるとともに計算機環境９００においてアクセスされることができる他のどの媒体も含む。一実装形態では、記憶装置９４０は、コンパイルおよびランタイムソフトウェア用の命令を格納する。

入力装置（群）９５０（たとえば、装置接続機構１００における制御ポイントとして作用する装置用の入力装置）は、キーボード、マウス、ペン、またはトラックボールなどのタッチ式入力装置、音声入力装置、走査装置、あるいは計算機環境９００への入力を実現する別の装置でよい。音声用には、入力装置（群）９５０は、音声入力をアナログまたはデジタルの形で受け入れるサウンドカードまたは類似の装置でも、計算機環境に音声サンプルを提供するＣＤ−ＲＯＭリーダでもよい。出力装置（群）９６０は、ディスプレイ、プリンタ、スピーカ、ＣＤライタ、または計算機環境９００からの出力を実現する別の装置でよい。

通信接続（群）９７０は、別の計算エンティティへの、通信媒体を介した通信を可能にする。こうした通信媒体は、コンピュータ実行可能命令、音声／映像または他の媒体情報、あるいは他のデータなどの情報を、変調データ信号の形で伝える。変調データ信号とは、情報を信号にエンコードするような方式で設定または変更される信号特性の１つまたは複数を有する信号である。限定ではなく例として、通信媒体は、電気、光学、ＲＦ、赤外線、音響、または他のキャリアを有して実現される有線または無線技術を含む。

本明細書における領域ベースのメモリ管理技術は、コンピュータ可読媒体という一般的な状況において説明されることができる。コンピュータ可読媒体は、計算機環境においてアクセスされることができる、利用可能などの媒体でもよい。限定ではなく例として、計算機環境９００の場合、コンピュータ可読媒体は、メモリ９２０、記憶装置９４０、通信媒体、および上記のどの組合せも含む。

本明細書における技術は、コンピュータ実行可能命令、たとえば計算機環境において、ターゲットである実プロセッサまたは仮想プロセッサ上で実行される、プログラムモジュールに含まれるコンピュータ実行可能命令という一般的な状況で説明されることができる。概して、プログラムモジュールは、特定のタスクを実施し、または特定の抽象データタイプを実装する、ルーチン、プログラム、ライブラリ、オブジェクト、クラス、コンポーネント、データ構造などを含む。プログラムモジュールの機能は、様々な実施形態での要望に応じて、組み合わされることも、プログラムモジュールの間に振り分けられることもできる。プログラムモジュール用のコンピュータ実行可能命令は、ローカルまたは分散計算機環境において実行されることができる。

提示として、詳細な説明は、計算機環境におけるコンピュータ動作を記述するのに、「判定する」、「作成する」、および「分析する」のような用語を用いている。こうした用語は、コンピュータによって実施される動作を高度に抽象化したものであり、人間によって実施される行為と混同されるべきではない。こうした用語に対応する実際のコンピュータ動作は、実装形態に応じて変わる。

本発明の原理が適用されることができる可能な多くの実施形態を鑑み、本発明として、このようなすべての実施形態が添付の特許請求の範囲およびその等価物の範囲および精神内であり得ると主張する。

形状グラフを利用する、領域ベースのメモリ管理システムの一実装形態を示すブロック図である。 形状グラフを使用する、領域ベースのメモリ管理環境においてプログラムを実行する例示的なコンピュータを示すブロック図である。 領域ベースのメモリ管理のために形状グラフを利用するオブジェクト指向プログラムを作成し実行する処理を示すフローチャートである。 領域ベースのメモリ管理のために形状グラフを利用するオブジェクト指向プログラムを作成する追加処理を示すフローチャートである。 領域ベースのメモリ管理のために形状グラフを利用するオブジェクト指向プログラムを作成する追加処理を示すフローチャートである。 領域ベースのメモリ管理のために形状グラフを利用するオブジェクト指向プログラムを作成する追加処理を示すフローチャートである。 一般的な形状グラフに基づく、メモリ領域におけるオブジェクトの例示的な格納を示すブロック図である。 一般的な形状グラフに基づく、メモリ領域におけるオブジェクトの例示的な格納を示すブロック図である。 領域ベースのメモリ管理のために形状グラフを利用するオブジェクト指向プログラムに手段を追加する処理を示すフローチャートである。 図１の領域ベースのメモリ管理システムを実装する、適切な計算機環境を示すブロック図である。

符号の説明

１００ コンパイラ
１１０ 形状グラフジェネレータ
１２０ メモリ管理コードジェネレータ
１３０ 実行コンピュータ
１５０ オブジェクト指向プログラムコード
１６０ コンパイルされたプログラム
１６５ 実行可能コード
１７０ 形状グラフ（群）
１４０ メモリ
２６０ 実行プログラム
２７０ ランタイム形状グラフハンドラ
９００ 計算機環境
９１０ 処理装置
９２０ メモリ
９４０ 記憶装置
９５０ 入力装置（群）
９６０ 出力装置（群）
９７０ 通信接続（群）
９８０ ソフトウェア（コンパイラソフトウェアまたはランタイム環境）

Claims (20)

1. 複数のオブジェクトを含むオブジェクト指向プログラムを実行するメモリを管理するシステムであって、
   各領域が少なくとも１つのオブジェクトを含む複数の領域に区分されたコンピュータ可読メモリと、
   前記領域の間の関係を記述する少なくとも１つの領域形状グラフであって、前記関係は、前記領域に含まれるオブジェクトの間の参照に少なくとも部分的に基づく領域形状グラフとを備え、
   目標オブジェクトへの参照が与えられると、前記目標オブジェクトを含む前記領域は、前記少なくとも１つの領域形状グラフからの情報を用いることによって識別されることができることを特徴とするシステム。
2. 前記少なくとも１つの領域形状グラフは、エッジによって連結された複数のノードを含み、
   各ノードは、メモリ中の領域を表し、
   各エッジは、ある領域の前記オブジェクトと、別の領域の前記オブジェクトとの間の１つまたは複数の参照を表すことを特徴とする請求項１に記載のシステム。
3. 前記形状グラフからの情報を用いることは、
   前記目標オブジェクトへの参照を有するオブジェクトを含む、メモリ中の第１の領域を識別すること、
   前記識別された第１の領域を表す、前記少なくとも１つの形状グラフ中の第１のノードを識別すること、
   前記目標オブジェクトへの前記参照を表す前記識別された第１のノードから導かれる前記エッジを識別すること、
   前記識別されたエッジから導かれる第２のノードを識別すること、および
   前記第２のノードによって、前記目標オブジェクトを含む前記領域として表される前記領域を識別することを含むことを特徴とする請求項２に記載のシステム。
4. 各領域は、それに関連づけられた形状グラフを有し、各形状グラフは、それが関連づけられた前記領域とともに格納されることを特徴とする請求項１に記載のシステム。
5. 領域に対して、前記領域に含まれるオブジェクトが前記領域外のどのフィールドによっても参照されないときを判定し、
   このような判定を行うと、前記領域を削除するように構成されたメモリ管理ソフトウェアモジュールをさらに備えることを特徴とする請求項１に記載のシステム。
6. オブジェクトが参照されないときを判定するように構成されることは、
   各領域ごとに、前記領域に含まれるオブジェクトに対して行われる参照数のカウントを保有し、
   領域に対する前記カウントがゼロであると判定すると、前記領域に含まれるオブジェクトが、他のどのフィールドによっても参照されないと判定するように構成されることを含むことを特徴とする請求項５に記載のシステム。
7. ガベージコレクタをさらに備えることを特徴とする請求項５に記載のシステム。
8. 少なくとも１つの形状グラフは、領域の総数より少ないことを特徴とする請求項１に記載のシステム。
9. メソッドに渡されるすべてのオブジェクトに対して、多くとも１つの領域パラメータがメソッドに渡されることを特徴とする請求項１に記載のシステム。
10. 領域ベースのメモリ管理を利用するシステムにおいて実行されるように構成されたオブジェクト指向プログラムをコンパイルする方法であって、
    オブジェクト指向プログラム用のソースコードを受け取るステップと、
    前記ソースコードに対してポイント先分析を実施して、前記プログラム用の領域関連づけメタデータを含む少なくとも１つのデータ構造を作成するステップと、
    前記プログラムに手段を追加するステップであって、前記手段は、
    前記データ構造中の情報に基づいて、領域内にオブジェクトを作成させ、
    領域内のオブジェクトが前記領域外のどのフィールドによっても参照されないという判定が行われると、前記領域内の全オブジェクトの削除を引き起こすように構成されるステップと、
    前記プログラムをコンパイルするステップと
    を含むことを特徴とする方法。
11. 領域関連づけメタデータを含む前記データ構造は、形状グラフを含むことを特徴とする請求項１０に記載の方法。
12. ポイント先分析を実施するステップは、
    前記オブジェクト指向プログラムのメソッドに含まれるステートメントに基づいて、パラメータ用のエイリアスセットを作成するステップと、
    前記プログラムのメソッドに含まれるステートメントに基づいて、前記エイリアスセットを単一化するステップと、
    エイリアスセットによって定義されるノード、およびエイリアスセットの間のフィールドマッピングによって定義されるエッジを有する少なくとも１つの形状グラフを作成するステップと、
    前記形状グラフの前記ノードを、可能なメモリ領域に関連づけるステップと
    を含むことを特徴とする請求項１１に記載の方法。
13. 前記追加される手段は、
    形状グラフを与えられると領域を作成する領域作成コードと、
    領域およびオブジェクト情報を与えられると、特定の領域内にオブジェクトを割り振るオブジェクト割り当てコードと、
    領域およびフィールドの識別子を与えられると、そのフィールドによって参照される前記領域を識別する領域ルックアップコードとを少なくとも部分的に含むことを特徴とする請求項１１に記載の方法。
14. 前記追加される手段は、２つの領域と、一方の領域内のオブジェクトを参照する他方の領域内のオブジェクトからのフィールドへの参照とを与えられると、前記フィールドに対応するエッジを介して、前記２つの領域に対応する前記ノードを連結する前記形状グラフを設定するフィールド設定コードをさらに含むことを特徴とする請求項１３に記載の方法。
15. 領域ベースのメモリ管理を利用することは、
    各領域または領域の組用に、その領域または組に含まれる前記オブジェクトに対して行われる参照数のカウントを保有すること、および
    １つの領域または領域の組用の前記カウントがゼロであると判定すると、前記領域または組を削除することを少なくとも部分的に含み、
    前記追加される手段は、
    １つの領域または領域の組を与えられると、その領域または組用に保有された前記カウントを増加させる増分コードと、
    １つの領域または領域の組を与えられると、その領域または組用に保有された前記カウントを減少させる減分コードとをさらに含むことを特徴とする請求項１３に記載の方法。
16. 命令を含むコンピュータ可読媒体であって、前記命令は、実行されると、領域ベースのメモリ管理を利用するシステムにおいて実行されるオブジェクト指向プログラムをコンピュータにコンパイルさせ、前記コンパイルは、
    オブジェクト指向プログラム用のソースコードを受け取る処理と、
    前記ソースコードに対してポイント先分析を実施して、前記プログラム用の少なくとも１つの形状グラフテンプレートを作成する処理と、
    前記プログラムに手段を追加する処理であって、前記手段は、
    前記形状グラフテンプレートに基づいて、領域内にオブジェクトを作成させ、
    領域内のオブジェクトが前記領域外のどのオブジェクトによっても参照されないという判定が行われると、前記領域内の全オブジェクトの削除を引き起こすように構成される処理と、
    前記プログラムをコンパイルする処理を実施することによって行われることを特徴とするコンピュータ可読媒体。
17. ポイント先分析を実施する処理は、
    前記オブジェクト指向プログラムのメソッドに含まれるステートメントに基づいて、パラメータ用のエイリアスセットを作成すること、
    前記プログラムのメソッドに含まれるステートメントに基づいて、前記エイリアスセットを単一化すること、
    エイリアスセットによって定義されるノード、およびエイリアスセットの間のフィールドマッピングによって定義されるエッジを有する少なくとも１つの形状グラフを作成すること、及び、
    前記形状グラフの前記ノードを、可能なメモリ領域に関連づけることを含むことを特徴とする請求項１６に記載のコンピュータ可読媒体。
18. 前記追加される手段は、
    形状グラフを与えられると領域を作成する領域作成コードと、
    領域およびオブジェクト情報を与えられると、特定の領域内にオブジェクトを割り振るオブジェクト割り当てコードと、
    領域およびフィールドの識別子を与えられると、そのフィールドによって参照される前記領域を識別する領域ルックアップコードとを少なくとも部分的に含むことを特徴とする請求項１６に記載のコンピュータ可読媒体。
19. 前記追加される手段は、２つの領域と、一方の領域内のオブジェクトを参照する他方の領域内のオブジェクトからのフィールドへの参照とを与えられると、前記フィールドに対応するエッジを介して、前記２つの領域に対応する前記ノードを連結する前記形状グラフを設定するフィールド設定コードをさらに含むことを特徴とする請求項１８に記載のコンピュータ可読媒体。
20. 領域ベースのメモリ管理を利用することは、
    各領域または領域の組用に、その領域または組に含まれる前記オブジェクトに対して行われる参照数のカウントを保有すること、および
    １つの領域または領域の組用の前記カウントがゼロであると判定すると、前記領域または組を削除することを少なくとも部分的に含み、
    前記追加される手段は、
    １つの領域または領域の組を与えられると、その領域または組用に保有された前記カウントを増加させる増分コードと、
    １つの領域または領域の組を与えられると、その領域または組用に保有された前記カウントを減少させる減分コードとをさらに含むことを特徴とする請求項１８に記載のコンピュータ可読媒体。

Images