JP2023551746A - 最小ランタイムでのガベージオブジェクトの蓄積の防止 - Google Patents

Abstract

最小ランタイムでガベージオブジェクトの蓄積を防止するためのコンピューター実装技術。本技術は、割当解除が起こるときにプログラマーが明示的にプログラムする必要がないソースプログラミング言語で書かれたソースコードが、暗黙的な割当解除をほとんどまたはまったくサポートしないランタイム内で実行できるかどうかをチェックすることを含む。同時に、本技術により、最小のランタイムでオブジェクトがタイミング良く割当解除されることが保証される。一態様では、本技術は、参照サイクルの可能性のあるソースコードのデータ型定義を検出すると、ソースコードのプログラマーにコンパイル時アラートを生成すること、またはソースコードのコンパイルを停止することを含む。本技術を用いると、プログラマーは、暗黙的な割当解除をまったく提供しない、または最小限だけサポートする（例えば、参照カウントだけを提供する）最小ランタイムと相互運用するプログラムフラグメントを生成しながら、暗黙的な割当解除エクスペリエンスが提供される。

Description

本開示は、コンピュータープログラミング言語コンパイラに関する。より具体的には、本開示は、最小ランタイムでガベージオブジェクトの蓄積を防止するためのコンピューター実装技術に関する。

コンピューターは、様々なタスクを行うための非常に強力なツールである。コンピュータープログラムは、コンピューターシステムを使用してカスタム処理タスクを達成するための一般的なメカニズムである。一般的なプログラムは、実行可能形式にコンパイルされるようにプログラムされた命令のセット（ソースコード）である。次に、実行可能形式はコンピューターシステムによって実行され、タスクを達成する。例えば、Ｃプログラミング言語命令のセットは、ｘ８６プロセッサ実行可能命令のセットにコンパイルされ得る。次に、プロセッサ実行可能命令のセットは、処理タスクを達成するために、ｘ８６互換プロセッサによって実行され得る。

人間のコンピュータープログラマーによってプログラムされた命令のセットと実行可能形式との間で、コンパイラは通常トランスレータとして使用される。本質的に、コンパイラは、プログラマーが、下層の実行可能フォームの詳細を知ること、またはさらに、それを気にすることから保護する。通常、プログラマーによって作成された全てのプログラム命令は、コンパイラによって変換される。例えば、コンパイラは、下層のコンパイラ実装に関するプログラマーの知識がなくても、データ型のチェック、シンボルテーブルの構築、レジスタの割り当て、及び命令のスケジューリングを行い得る。このように、コンパイラは、低レベルの実行の詳細を心配するプログラマーの認知的負担を軽減する高レベルのプログラミング言語を使用して、より高いレベルで処理タスクを推理し、表現するためのツールをプログラマーに提供する。コンパイラの一般的な構成及び動作は、当技術分野ではよく知られている。例えば、Ａｈｏ，Ａ．，Ｓｅｔｈｉ，Ｒ．，ａｎｄ Ｕｌｌｍａｎ，Ｊ．、「Ｃｏｍｐｉｌｅｒｓ：Ｐｒｉｎｃｉｐｌｅｓ，Ｔｅｃｈｎｉｑｕｅｓ，ａｎｄ Ｔｏｏｌｓ」Ｓｅｃｏｎｄ Ｅｄｉｔｉｏｎ，２００７を参照されたい。

いくつかのコンパイラの目的の１つとして、クロスコンパイルが挙げられる。クロスコンパイラは、１つの入力から２つ以上の出力を生成するコンパイラとして定義され得る。例えば、クロスコンパイラは、人間及びコンピューターの両方が読み取り可能なソースプログラミング言語で書かれたソースコードを入力として受け入れ、１つ以上の実行可能形式のソースコードを出力として生成し得る。例えば、Ｃプログラミング言語のクロスコンパイラを考えてみる。そのようなクロスコンパイラは、Ｃソースコードから、ｘ８６実行可能ファイル（例えば、ＭＩＣＲＯＳＯＦＴ ＷＩＮＤＯＷＳ（登録商標）オペレーティングシステムで構成されたコンピューターでの実行用）、ＡＲＭ実行可能ファイル（例えば、ＡＮＤＲＯＩＤ（登録商標）オペレーティングシステムで構成されたモバイルコンピューティングデバイスでの実行用）、及びＷＡＳＭ実行可能ファイル（例えば、ウェブブラウザアプリケーションによってサポートされた仮想スタックマシンでの実行用）を生成し得る。

また、ソース・トゥ・ソース・コンパイラもある。ソース・トゥ・ソース・コンパイラは、人間及びコンピューターの両方が読み取り可能なソースプログラミング言語で書かれたソースコードを入力として受け入れ、また人間及びコンピューターの両方が読み取り可能な１つ以上のプログラミング言語ターゲットのソースコードを出力するコンパイラとして定義され得る。例えば、ＨＡＸＥコンパイラは、ＨＡＸＥプログラミング言語で書かれたソースコードを、構造的に類似のいくつかのプログラミング言語ターゲットに変換できる。ＨＡＸＥのさらなる情報は、ｈａｘｅ．ｏｒｇインターネットドメインにおいてインターネットで入手できる。

現在、広く使用されているプログラミング言語の多くは、ランタイムの暗黙的なオブジェクトの割当解除をサポートしている。割当解除は、不要なオブジェクトによって占有されたコンピューターのメモリ空間を解放してランタイム操作として定義され得、その結果、その空間を再利用できる。例えば、オブジェクトが不要になった直後、または実行中のプログラムにより、空間が他の目的に必要であると判定されたとき等、空間が最終的に解放される場合、ランタイムに割当解除がタイムリーに行われる。タイミング良く割当解除されないオブジェクトは、メモリ「リーク」と呼ばれることもある。

いくつかのプログラミング言語では明示的なプログラムによる割当解除が必要であるが、他の言語では暗黙的なランタイム割当解除がサポートされる。明示的な割当解除では、コンピュータープログラムはプログラマーによって明示的にプログラムされ、「ｎｅｗ」、「ｍａｌｌｏｃ」、「ｆｒｅｅ」、「ｄｅｌｅｔｅ」等のプログラミング言語操作を使用して、ランタイムオブジェクトのメモリ空間の割り当て及び割当解除が行われる。暗黙的なランタイム割当解除により、プログラマーは、ランタイムオブジェクトのメモリ空間を割り当て及び割当解除するプログラムを明示的にプログラミングする責任から解放される。代わりに、プログラミング言語ランタイムがランタイムオブジェクトをタイムリーに割当解除することを対処する。

ランタイムの暗黙的なオブジェクトの割当解除をサポートするために、プログラミング言語ランタイムは、安全に割当解除できるメモリのオブジェクトを定期的に識別するガベージコレクター、または互いに相互参照しているが、実行中のプログラムの他の部分によって参照していないメモリのオブジェクトのグループを識別するサイクルコレクター等のランタイムメモリ管理サービスを提供し得る。次に、オブジェクトによって占有されたメモリ空間は、他の用途のために解放できる。

また、スマートな参照もある。スマート参照は、メモリアドレスビットを、メモリ領域を割当解除する方法を制御する他のビットと組み合わせる。一種のスマート参照の例として、参照されるオブジェクトを必要とするプログラム要素の数をカウントし続ける参照カウント参照がある。カウントがゼロに達するとき、そのオブジェクトは安全に割当解除され得る。スマート参照は、暗黙的な割当解除のランタイムサポートを提供しないいくつかのプログラミング言語で使用され得る。最新のＣ＋＋プログラミング言語は一例である。

現在、ほとんどのコンピュータープログラマーは、ランタイムに暗黙的な割当解除をサポートするプログラミング言語でのプログラミングに慣れている。残念ながら、ランタイムに暗黙的な割当解除をサポートしないプログラミング言語の多くのものが依然として広く使用されている。そのようなプログラミング言語の例は、Ｃ、Ｃ＋＋、ＯＢＪＥＣＴＩＶＥ－Ｃ、及びＲＵＳＴを含む。広く使用されている全てのプログラミング言語をサポートするように設計されているクロスコンパイラまたはソース・トゥ・ソース・コンパイラは、全てのターゲットがランタイムに暗黙的な割当解除を提供すると想定できない。

本明細書に開示される技術は、この問題及び他の問題に対処する。

このセクションで説明されるアプローチは、追求できたアプローチであるが、必ずしも以前に考案または追求されたアプローチであるとは限らない。したがって、別段の指示がない限り、このセクションに説明されるアプローチのいずれも、単に、このセクションに含まれているという理由だけで先行技術として認定されると想定すべきではない。

これらの技術は、限定としてではなく例として添付の図面に示されており、図中、同様の参照番号は同様の要素を示す。

循環データ構造の第１の例を示す。 ファサードアプローチを使用して、実際には非循環データ構造の見かけ上循環ビューを提供する第１の例を示す。 循環データ構造の第２の例を示す。 ファサードアプローチを使用して、実際には非循環データ構造の見かけ上循環ビューを提供する第２の例を示す。 ファサードアプローチを使用して、実際には非循環データ構造の見かけ上循環ビューを提供する例を示す。 ファサードアプローチを使用して、実際には非循環データ構造の見かけ上循環ビューを提供する例を示す。 ファサードアプローチを使用して、実際には非循環データ構造の見かけ上循環ビューを提供する例を示す。 ファサードアプローチを使用して、実際には非循環データ構造の見かけ上循環ビューを提供する例を示す。 ファサードアプローチを使用して、実際には非循環データ構造の見かけ上循環ビューを提供する例を示す。 ファサードアプローチを使用して、実際には非循環データ構造の見かけ上循環ビューを提供する例を示す。 データ型定義グラフの例を示す。 データ型定義グラフの例を示す。 データ型定義グラフの例を示す。 データ型チェックプロセスのフローチャートである。 データ型チェックプロセスのフローチャートである。 データ型チェックプロセスのフローチャートである。 データ型チェックプロセスのフローチャートである。 データ型チェックプロセスのフローチャートである。 データ型チェックプロセスのフローチャートである。 データ型チェックプロセスのフローチャートである。 データ型チェックプロセスのフローチャートである。 本技術の実施態様で使用され得る例示的な基本的なコンピューティングデバイスのブロック図である。 図８の基本的なコンピューティングデバイスの動作を制御するために採用され得る例示的な基本ソフトウェアシステムのブロック図である。

下記の発明を実施するための形態の「総括」セクションでは、最小ランタイムでガベージオブジェクトの蓄積を防止するための技術の有用な概要を提供する。

いくつかの実施形態では、コンパイラまたはデータ型チェックツールは、プログラミング言語ソースコードのデータ型定義をチェックし、ランタイムに参照サイクルを可能にし得る任意の定義をプログラマーに知らせる。いくつかの実施形態では、コンパイラまたはデータ型チェックツールは、コンピュータープログラムが型定義をどのように使用するかを考慮する。

いくつかの実施形態では、コンパイラまたはデータ型チェックツールは、プログラミング言語ソースコードのデータ型定義のどのプロパティ定義が読み取り専用であるかを考慮する。いくつかの実施形態では、コンパイラまたはデータ型チェックツールは、プログラミング言語ソースコードの明示的なヒントを使用して、プロパティ定義が「定数（ｃｏｎｓｔ）」、「ファイナル（ｆｉｎａｌ）」、もしくは「読み取り専用（ｒｅａｄ－ｏｎｌｙ）」等のキーワード、または注釈を含む読み取り専用であるか、あるいは「変更可能（ｍｕｔａｂｌｅ）」または「書き込み可能（ｗｒｉｔｅａｂｌｅ）」等の逆の意味がある明示的なヒントが欠如しているかどうかを判定する。いくつかの実施形態では、コンパイラまたはデータ型チェックツールは、プロパティ定義を検査して読み取り専用性であることを推論する。例えば、初期値がそのように割り当てられた後にプロパティを設定できたプログラミング言語ソースコードがいずれも設定されないとき、プロパティ定義が読み取り専用性があると推論され得る。いくつかの実施形態では、コンパイラまたはデータ型チェックツールは、必要な読み取り専用性を検出または強制するために、プログラミング言語ソースコードまたは実行可能プログラムに追加命令を挿入する。例えば、追加命令により、プロパティの初期化後のプロパティへの値の割り当てが失敗し得る。

いくつかの実施形態では、コンパイラまたはデータ型チェックツールは、プログラミング言語ソースコードのどのプロパティ定義が、含まれるオブジェクトへの任意の参照前に早期に初期化されるかを考慮する。初期の概念を使用して、オブジェクトがプロパティの初期化中に、オブジェクト自体への参照サイクルを作成することを防止する。早期の初期化は、プロパティを初期化するプログラミング言語ソースの検査に基づいて推論され得る。また、早期の初期化は明示的なヒントにも基づき得る。明示的なヒントにより、例えば、データ型のコンストラクター定義をチェックして、値としての「ｔｈｉｓ」参照の使用と、プロパティの割り当てとの間の時間的関係をチェックする等、初期化を行い得るプログラミング言語ソースコードの他のチェックを生じさせ得る。コンパイラまたはデータ型チェックツールは、必要な読み取り専用性を検出または強制するために、プログラミング言語ソースコードまたは実行可能プログラムに追加命令を挿入し得る。例えば、追加命令により、プロパティを含むオブジェクトへの「ｔｈｉｓ」参照が値として使用された後にプロパティを初期化しようとする試みが失敗し得る。

いくつかの実施形態では、コンパイラまたはデータ型チェックツールは、データ型定義がクローズされているかどうか（例えば、その全てのサブタイプがコンパイラまたはデータ型チェックツールに知られているかどうか）を考慮する。クローズ性は、「ファイナル（ｆｉｎａｌ）」、「クローズド（ｃｌｏｓｅｄ）」、「シールド（ｓｅａｌｅｄ）」等のキーワード、もしくは注釈の存在等のプログラミング言語ソースコードの明示的なヒント、または「オープン（ｏｐｅｎ）」等の逆の意味があるヒントの欠如に基づき得る。クローズ性はコンテキストに基づいて推論され得る。例えば、データ型定義へのアクセスが情報隠蔽メカニズムによって、プログラミング言語ソースコードの一部のモジュールに制限されており、それらのモジュール内のサブタイプのプログラミング言語ソースコードに定義が存在しない場合、クローズ性はデータ型定義に関して推論され得る。また、クローズ性は、一般的なスーパーデータ型に関して推理するためにケースベースの推理で置換することを可能にするためにも使用され得る。

いくつかの実施形態では、コンパイラまたはデータ型チェックツールは、データ型定義が具体的であるかどうかを考慮する（例えば、そのデータ型のサブデータ型の値ではないそのデータ型の値が存在する可能性があるかどうかを考慮する）。具象データ型は、値を記述するには不十分であるが、それから具体的なサブデータ型を導出し得る抽象データ型と対比され得る。具体性は、例えば、「具体的」のようなキーワードもしくは注釈の存在等の明示的なヒント、または「抽象」のようなキーワードもしくは注釈の欠如に基づき得る。具体性は、例えば、オブジェクトを構築するためにプログラミング言語ソースコードのデータ型のユーザーによって、または完全に機能するオブジェクトの構築を妨げるであろう任意の欠落部分がないことによって等、コンテキストに基づいて推論され得る。ランタイムに作成された全ての値は少なくとも１つの具象データ型である必要があるため、コンパイラまたはデータ型チェックツールは、具体的型について参照サイクルの検出に十分であると推理し得る。

いくつかの実施形態では、コンパイラまたはデータ型チェックツールは、潜在的な型包含関係のグラフを構築することによって、潜在的な参照サイクルをチェックする。グラフのいくつかのノードは、プログラミング言語ソースコードで定義されたデータ型に対応し得る。グラフのいくつかのノードは、ジェネリック型パラメーターに関する最悪の場合の仮定に対応し得る。最悪の場合の仮定では、ジェネリック型パラメーターの境界またはデータ型定義の境界が考慮され得る。データ型定義の境界の１つのタイプは、本明細書では、「ｍａｙ－ｎｏｔ－ｒｅｆｅｒｅｎｃｅ」境界と呼ばれる。グラフのいくつかのエッジは、プログラミング言語ソースコードで定義された一方のデータ型がプログラミング言語ソースコードで定義された別のデータ型を参照し得る方法に対応し得る。グラフ要素（例えば、ノード及びエッジ等）は、プロパティ及びデータ型定義の早期性、読み取り専用性、またはクローズ性から導出されたメタデータに関連付けられ得る。いくつかの実施形態では、特定の種類のエッジを有するグラフのサイクルは、プログラミング言語ソースコードの１つ以上のデータ型定義のセットによって可能になる可能な参照サイクルに対応する。

コンパイラまたはデータ型チェックツールによって生成されたアラートは、考えられる参照サイクルの人間可読な記述を含み得る。例えば、記述では、「Ｔｈｉｎｇ型の値は、そのプロパティｏｔｈｅｒＴｈｉｎｇを用いてそれ自体を参照し得る。'ａＴｈｉｎｇ．ｏｔｈｅｒＴｈｉｎｇ＝ａＴｈｉｎｇ；'は、参照サイクルを生じさせるであろう。」のようなことが述べられ得る。そのような記述は、潜在的なタイプの包含関係のグラフのノードまたはエッジに関連付けられたメタデータから導出され得る。記述は、問題を修正する方法（例えば、潜在的な参照サイクルを回避する方法等）に関する提案を含み得る。いくつかの実施形態では、統合開発環境等の外部ツールは、アラート、またはアラートの変更された形式（例えば、アラートのより機械可読な形式）を使用して、プログラマーのユーザーによって選択された提案に基づいてプログラミング言語ソースコードを自動的に変更する。

いくつかの実施形態では、コンパイラまたはデータ型チェックツールは、人間のレビュアーによって安全であるとみなされている潜在的な参照サイクルを無視する。安全であるとみなされている参照サイクルを識別することは、プログラミング言語ソースコードのデータ型定義に関連付けられたヒント、注釈、または他のメタデータに基づき得る。安全であるとみなされている参照サイクルを識別することは、代わりにまたは同様に、関連するプロパティが、コンパイラまたはデータ型チェックツールがデータ型チェックから除外するプログラミング言語ソースコードの「安全でない（ｕｎｓａｆｅ）」フラグメント内にだけ割り当てられていると判定することに基づき得、その結果、参照サイクルを可能にする必要があるデータ型定義を承認できる。

いくつかの実施形態では、分散オブジェクトシステムは、他のコンピューターまたは同じコンピューター上のプロセスによって必要とされるオブジェクトの参照カウントを保持し、非循環コレクション性チェックに依存して、いくつかのタイプのオブジェクト間の参照サイクルを検出する必要をなくす。このコンテキストでは、オブジェクトは他のプロセスに存在するオブジェクトを参照でき、分散システムのプロセスがオブジェクトを必要としなくなったとき、分散システムは、そのオブジェクトを所有していると見なされるシステムのプロセスにメッセージを送信し得る。プロセスの１つが停止もしくは失敗した場合に対処するために、またはプロセスの１つが不正な動作をした場合に対処するために、システムの複数のプロセスによって同じオブジェクトに対して個別の参照カウントが維持され得る。例えば、場合によって、そのオブジェクトを他のプロセスで使用できなくする意図で、参照が２つ未満だったとき、２つの参照がもう必要でないことを主張することによって対処する。

以下の説明では、説明する目的として、本技術の完全な理解を提供するために多くの特有の詳細が述べられている。しかしながら、これらの技術は、これらの特定の詳細がなくても実施され得ることは明らかであろう。他の例では、本技術を不必要に分かりにくくしないように、周知の構造及びデバイスがブロック図の形式で示される。

用語解説
以下の定義は、本技術の開示の理解を助けるために、限定ではなく例示を目的として提供されている。

クライアント：「クライアント」は、タスクをライブラリに委任するコンピューターシステムの一部として定義され得る。

コンパイラ：「コンパイラ」は、人間及びマシンの両方の消費に適切な入力を消費し、１つ以上の出力を生成する。各出力は、入力のコンパイラによる変換である。例えば、入力はソースプログラミング言語で書かれたソースコードであり得る。出力は、入力ソースコードの実行可能形式であり得る。また、出力は、ソースプログラミング言語とは異なるターゲットプログラミング言語の入力ソースコードのソースコード形式であり得る。

クロスコンパイラ：「クロスコンパイラ」は、２つ以上の出力を１つの入力から生成するコンパイラである。

割当解除：「割当解除」という用語は、再利用のために不要なオブジェクトによって占有されたメモリ空間を解放する、実行中のコンピュータープログラムのコンテキストにおけるランタイム操作を指す。

ガベージオブジェクト：「ガベージオブジェクト」は、安全に割当解除できるが、まだ割当解除されていないオブジェクトである。

グラフ：「グラフ」は、エンティティ間のペア関係をモデル化するために使用される数学的構造である。このコンテキストにおけるグラフは、通常、エッジ（リンクまたはラインとも呼ばれる）によって接続される頂点（ノードまたはポイントとも呼ばれる）で構成される。コンピュータープログラムは、ノードオブジェクトを参照するエッジオブジェクトを参照するノードオブジェクトを介する等を含む、様々な異なる方法でグラフを表すことができる。他に考えられる方法は、隣接行列、発生行列、または隣接リストを含む。

ライブラリ：「ライブラリ」は、自動化可能形式でのアルゴリズムまたは複数のアルゴリズムの表現として定義され得る。自動化可能形式の例は、プログラミング言語コードまたはそのコンパイルされたバージョン（例えば、バイトコード、バイナリ実行可能コード等）であり得る。通常、ライブラリは、プロセスまたは複数のプロセスとして実行されるとき、その一部として実行されるプロセス（複数可）を「所有」しない。代わりに、ライブラリは、特定の種類のアルゴリズムタスクをライブラリに委任する大規模システムと一緒に、またはその一部として実行される。例えば、コンピューターネットワーク上のマイクロサービスはライブラリとして見なされ得る。多くの場合、特定のアルゴリズムタスクを削除するために、他のネットワークノード用にマイクロサービスが存在する。

オブジェクト：「オブジェクト」は、コンピュータープログラム内のメッセージに応答し得るランタイムエンティティとして定義され得る。通常、エンティティはコンピューターメモリの領域を占有する。オブジェクトはメッセージに応答し、データ型定義に従って占有メモリ領域のビットを編成し得る。オブジェクトの一例は、オブジェクト指向プログラミング言語によるクラス定義のランタイムインスタンスである。

参照：「参照」とは、コンピュータープログラムがコンピューターメモリのある場所に記憶されたオブジェクトにアクセスすることを可能にするランタイム値である。参照を使用してその場所に記憶されたオブジェクトを取得することは、逆参照と呼ばれることもある。「ポインタ」は参照の一例である。

ランタイム：プログラミング言語の「ランタイム」は、その言語で書かれたコンピュータープログラムの実行をサポートする計算メカニズムを含む。例えば、プログラミング言語のランタイムは、その言語のコンピュータープログラムがコンパイルされるバイトコード命令を理解する仮想マシンを含み得る。ＪＡＶＡ（登録商標）仮想マシン（ＪＶＭ）は、そのようなランタイムの一例にすぎない。ランタイムは、ガベージコレクションまたはサイクルコレクション等の暗黙的な割当解除サービスも提供し得る。しかしながら、全てのランタイムが暗黙的な割当解除サービスを提供するわけではない。さらに、本明細書で使用される「ランタイム」という用語は、コンピュータープログラムが実行されるときの時間を指す。

ターゲット：「ターゲット」は、コンパイラ出力に接続するためにクライアントによって使用されるメカニズムとして定義され得る。プログラミング言語をターゲットにできる。プログラマーは、同じメモリ空間にロードされるライブラリに接続するコードを書く。仮想マシン（ＶＭ）をターゲットにできる。プログラマーは、仮想マシンが実行する種類のバイトコードにコンパイルするコードを書き、インターフェースを介してリンクを使用してＶＭに依存できる。別のプログラムはクライアントになり得る。したがって、プログラム間のメカニズムがターゲットになる。コードは、プロセス間通信（ＩＰＣ）、リモートプロシージャコール（ＲＰＣ）、またはＲＥＳＴｆｕｌネットワークプロトコルを使用して、クライアントプログラムのプロセスの外部で実行されているもの（例えば、ネットワークサービスまたはマイクロサービス等）にメッセージを送信し、応答を含むメッセージがいつ来るかを認識し得る。

総括
コンピュータープログラムに未解決の参照サイクルがあると、ガベージオブジェクトのランタイムに蓄積がもたらされる可能性がある。そのような蓄積により、致命的なプログラム障害が生じ得る。例として、ＰＹＴＨＯＮプログラミング言語を検討する。ＰＹＴＨＯＮランタイムの古いバージョンでは、参照カウントを使用して、割り当てられたメモリを追跡する。特に、ＰＹＴＨＯＮのランタイムオブジェクトは、それを参照しているオブジェクトの数を示す参照カウントを有する。参照カウントがゼロに達するとき、オブジェクトはメモリから解放される。参照カウントは、ほとんどのＰＹＴＨＯＮプログラムで効果的に機能し、ガベージオブジェクトの蓄積を防止できる。しかしながら、「参照（ｒｅｆｅｒｅｎｃｅ）」サイクルがあるとき、参照カウントは失敗する可能性がある。参照サイクルは、オブジェクトが相互に参照するときに発生する。

以下の単純なＰＹＴＨＯＮプログラムを考えてみる。このプログラムは、リストオブジェクトを作成し、リスト自体の要素にリストへの参照を記憶し、その後、リストオブジェクトを削除する。
00: l = []
01: l.append(l)
02: del l

行００のステートメントはリストを作成し、リストの参照カウントを１にインクリメントする。行０１のステートメントは、リストへの参照をリスト自体に追加して、参照サイクルを生成し、リストの参照カウントを２にインクリメントする。行０２のステートメントは、変数'ｌ'によるリストへの参照を削除し、リストの参照カウントを２から１にデクリメントする。参照サイクルのため、行０１のステートメントによって作成された内部に保持される自己参照により、リストには１の参照カウントが残る。したがって、リストは参照カウントだけによって、暗黙的に割当解除されない。そのリストは行０２のステートメントの後で使用できず、割当解除する必要があるため、これは望ましくない。

コンピュータープログラムで参照サイクルを意図的に作成することは、概して、良いプログラミング方法とは考えられていないが、時々、参照サイクルの作成を避けることが困難になり、プログラマーは参照サイクルが作成されることに気づかないこともある。サーバープログラム等の長時間実行されるプログラムの場合、これは、参照カウントが使用できないオブジェクトを割当解除できなかったためにサーバープログラムがメモリ不足になった場合に問題になり、場合によって、致命的になる可能性がある。

この参照カウントの欠点に対処するために、ＰＹＴＨＯＮランタイムのいくつかのバージョンでは、ランタイムに実行中のＰＹＴＨＯＮプログラムで参照サイクルを見つけるガベージコレクターを使用する。参照カウントは、依然として、他のオブジェクトを割当解除するために使用される。それにもかかわらず、オブジェクトの「ファイナライザー（ｆｉｎａｌｉｚｅｒ）」には依然として問題が存在する可能性がある。「ファイナライザー」は、オブジェクトが割当解除されるときに行われる必要がある１つ以上のアクションのセットである。多くの場合、ファイナライザーを使用して、数が制限できるオペレーティングシステムのファイル記述子等、システムリソースを解放する。ＰＹＴＨＯＮのファイナライザーの例は、オブジェクトの「＿＿ｄｅｌ＿＿」メソッド（例えば、特別なＰＹＴＨＯＮ「＿＿ｄｅｌ＿＿」メソッドの実施を提供するクラスのインスタンス）である。

参照カウントでは、オブジェクトの参照カウントがゼロになるとき、オブジェクトが割当解除される前にファイナライザーが呼び出される。しかしながら、ガベージコレクションを使用する場合、特に参照サイクルがあるとき、プログラマーがランタイムのファイナライザーの挙動について推理することがより困難になる。例えば、参照サイクルの２つのオブジェクトの両方にファイナライザーがある場合、どちらのファイナライザーを最初に呼び出す必要があるか？ファイナライザーの１つを呼び出した後、他のファイナライザーが依然としてアクセスする必要があり得るため、オブジェクトを解放できない。この状況に直面して、ＰＹＴＨＯＮランタイムのいくつかのバージョンは、オブジェクトが参照サイクルを作成するファイナライザーを用いて、オブジェクトを割当解除しない。代わりに、オブジェクトは収集不可能なガベージオブジェクトのグローバルリストに追加される。ＰＹＴＨＯＮプログラムは、グローバルリストにアクセスし、間近で、特定のアプリケーションに有用な方法で参照サイクルを明示的に解放するようにプログラムできる。当然ながら、これはプログラマーが最初に参照サイクルを作成できることを認識していることを前提としている。その場合でも、プログラマーはグローバルリストのオブジェクトを割当解除することを注意する必要がある。

前述のＰＹＴＨＯＮの例から明らかなように、ランタイムに暗黙的な割当解除のサポートを追加すると、複雑な問題が発生する可能性がある。ＰＹＴＨＯＮの場合のようにガベージコレクションを追加すると、ＰＹＴＨＯＮランタイムがＣまたはＣ＋＋ランタイム内で実行されるという事実が役に立つことがあった。しかしながら、他のランタイムを組み込み得るＣまたはＣ＋＋ランタイムにサポートを追加するのは簡単ではない。例えば、様々なランタイムが互いの参照を参照として認識し、どのランタイムが割当解除を行うのに担当するかについて一貫して合意する必要がある。

概して、プログラマーの観点から見ると、少なくとも２種類の参照サイクル、つまり、（１）意図された参照サイクル、及び（２）意図されない参照サイクルがある。Ｔｒｅｅ等の再帰的データ型は、意図しない参照サイクルのソースになる可能性がある。例えば、複数のリストのうちのいくつかのリストは、その使用法が注意深くプログラムされている場合、参照サイクルを回避できる。しかしながら、上記のＰＹＴＨＯＮの例で分かるように、多くのプログラミング言語では、ランタイムに単純な参照カウントでは解くことができない参照サイクルが意図せず作成される可能性がある。

本明細書に開示される技術は、これらの問題及び他の問題に対処する。

最小ランタイムでガベージオブジェクトの蓄積を防止するために、コンピューター実装技術が提供されている。本技術は、割当解除が起こるときにプログラマーが明示的にプログラムする必要がないソースプログラミング言語で書かれたソースコードが、暗黙的な割当解除をほとんどまたはまったくサポートしないランタイム内で実行できるかどうかをチェックすることを含む。同時に、本技術により、最小のランタイムでオブジェクトがタイミング良く割当解除されることが保証される。

本技術は、参照サイクルの可能性のあるソースコードのデータ型定義を検出すると、ソースプログラミング言語のソースコードのプログラマーにコンパイル時アラート（例えば、エラーメッセージまたはワーニングメッセージ）を生成すること、またはソースコードのコンパイルを停止することを含む。本技術は、プログラマーは、ソースコードで見かけ上循環であるが、実際には非循環データ型を定義することが可能になるように十分に柔軟性がある。また、本技術は、プログラマーがソースコードで再帰的ではあるが自己参照ではないデータ型を定義することが可能になるように十分な柔軟性もある。本技術を用いると、プログラマーは、暗黙的な割当解除をまったく提供しない、または最小だけサポートする（例えば、参照カウントだけを提供する）最小ランタイムと相互運用するプログラムフラグメントを生成しながら、暗黙的な割当解除エクスペリエンスが提供される。

本技術の他の及びこれらの態様は、例として本技術の原理を示す添付の図面と併せて、以下の詳細な説明から明らかになる。

実際のサイクルのない見かけのサイクル
示されるように、プログラマーは、参照サイクルを可能にする目的で、ソースプログラミング言語でソースコードをプログラムし得る。例えば、プログラマーは、再帰的データ型を定義するためにソースコードをプログラムし得る。再帰的データ型は、その独自のデータ型定義を参照するデータ型である。

例えば、考えられるソースプログラミング言語での以下のデータ型定義を検討する。
00: closed type List<E>;
01: closed concrete type Cons<F> extends List<F> {
02: initial: F;
03: rest: List<F>;
04: }
05: closed concrete type Empty<G> extends List<G> {}

上記のデータ型の定義によれば、初期プロパティはジェネリックデータ型として定義され、残りのプロパティはＣｏｎｓ＜Ｆ＞型の親型であるＬｉｓｔ＜Ｆ＞型として定義される。したがって、Ｃｏｎｓ＜Ｆ＞オブジェクトの初期プロパティ及び残りのプロパティのいずれか一方または両方は、Ｃｏｎｓ＜Ｆ＞オブジェクト自体を参照できる。したがって、Ｃｏｎｓ＜Ｆ＞データ型は再帰的データ型である。

上記のデータ型定義では、クローズキーワードは、データ型の追加のサブデータ型を事後的に指定できる拡張可能なデータ型とは対照的に、データ型のサブデータ型の全てがコンパイラに知られていることを指定する。いくつかの実施態様では、クローズデータ型がデフォルトであるため、クローズデータ型を望む場合、クローズキーワードを指定する必要はない。

別の例として、考えられるソースプログラミング言語でのバイナリツリーの以下のデータ型定義を検討する。
00: closed type Tree<B>;
01: closed concrete type BinaryTree<F> extends Tree<F> {
02: element: F;
03: left: Tree<F>;
04: right: Tree<F>;
05: }
06: closed concrete type Empty <G> extends Tree<G> {}

上記のデータ型定義は、ジェネリックデータ型ＢｉｎａｒｙＴｒｅｅ＜Ｆ＞を値のセットとして定義する。上記の型定義によれば、ＢｉｎａｒｙＴｒｅｅ＜Ｆ＞オブジェクトの左プロパティ及び右プロパティのいずれか一方または両方は、ＢｉｎａｒｙＴｒｅｅ＜Ｆ＞型の値を含み得る。したがって、ＢｉｎａｒｙＴｒｅｅ＜Ｆ＞データ型も再帰的データ型である。

既に述べたように、再帰的データ型のインスタンスはランタイムに参照サイクルに発展する可能性がある。図１は、ランタイムのオブジェクトの循環コレクションの例を示す。例えば、オブジェクトのコレクションは、ツリーまたはグラフのデータ構造を表し得る。楕円はコンピューターメモリのランタイムオブジェクトを表し、有向エッジは一方のオブジェクトから別のオブジェクトへの参照を表す。例えば、オブジェクト１は参照記号ｄによってオブジェクト２を参照する。例示的なコレクションでは、異なる方向の有向エッジによって示されるように、多数の参照サイクルがある。例えば、データオブジェクトのコレクションがツリーデータ構造を表す場合、オブジェクト６からオブジェクト７への参照記号ｕは、オブジェクト７がオブジェクト６のツリー内の最初の子ノードであることを表し得、その場合、参照記号ｖは、オブジェクト７がオブジェクト６のツリー内の最後の子ノードであることを表し得、参照記号ｔは、オブジェクト７がオブジェクト６のツリー内の親ノードであることを表し得る等が挙げられる。

ファサードアプローチ
本技術はファサードアプローチを含む。ファサードアプローチによれば、相互参照するノード及びエッジの分類法によってランタイムにオブジェクト間の関係を表す代わりに、ファサードアプローチを使用して、ランタイムに、オブジェクト間の関係を表すことができる。ファサードアプローチを用いると、オブジェクトのコレクションが、実行中のプログラムには循環（すなわち、見かけ上循環）として見え得るが、そのランタイムの実施態様は実際には非循環である。そのランタイムの実施態様は実際には非循環であるため、自動ガベージコレクターまたは自動サイクルコレクター等の暗黙的なランタイム割当解除サポートは必要ない。代わりに、単純な参照カウントメカニズムを使用して、オブジェクトをタイムリーに割当解除できる。

ソースプログラミング言語のソースコードを、ランタイムに暗黙的なオブジェクト割当解除をサポートしないターゲットプログラミング言語のソースコードに変換するソース・トゥ・ソース・コンパイラは、ファサードアプローチを使用するためにターゲットソースコードを生成できる。そうすることによって、ターゲットプログラミング言語ランタイムは、暗黙的なランタイム割当解除をサポートする必要がなく、オブジェクトをタイムリーに割当解除できる。ファサードアプローチと併せて、ソースプログラミング言語は、プログラマーに暗黙的な割当解除プログラミングエクスペリエンスを提供でき、プログラマーは、オブジェクトを明示的に割り当て及び割当解除するためにソースプログラミング言語でソースコードをプログラミングすることを気にする必要がない。このエクスペリエンスは、ソース・トゥ・ソース・コンパイラの１つ以上のターゲット言語が暗黙的なランタイム割当解除をサポートしない場合でも提供される。プログラマーは、また、ソースプログラミング言語で再帰的データ型を定義することも可能になる。ランタイムには、見かけ上循環しているように見えるが、実際には循環ではないため、参照サイクルはランタイムに作成されない。

ファサードアプローチでは、より大きな分類法が使用される。特に、より大きな分類法は以下のオブジェクトを含む。
・定義されたデータ型のインスタンスである「データ（ｄａｔａ）」オブジェクト、
・データオブジェクト間の関係を収集する「関係（ｒｅｌａｔｉｏｎｓｈｉｐ）」オブジェクト、
・データオブジェクト及び関係オブジェクトをペアにする「グラフ（ｇｒａｐｈ）」オブジェクト、ならびに
・循環しているかのような外観を提示し、データオブジェクト及びグラフオブジェクトの両方を参照する「ファサード」オブジェクト。

ファサードアプローチによれば、プログラムはランタイムにソースプログラミング言語でプログラムされるデータオブジェクトのコレクションにアクセスして変更し、参照サイクルを可能にする。例えば、データオブジェクトのコレクションは、ソースプログラミング言語で定義された再帰的データ型に基づくデータ構造を表し得る。例えば、データ構造は、データ構造のオブジェクトが再帰的データ型のインスタンスであるリスト、ツリー、またはグラフのデータ構造であり得る。

ファサードアプローチは、ファサードオブジェクトを経由して、データオブジェクトのコレクションが非循環性を維持できるランタイムメカニズムを提供する。ファサードオブジェクトを経由して、明らかに循環データオブジェクトのコレクションは、プログラムからは循環に見えるにもかかわらず、実際の非循環性が維持される。非循環性が維持されるため、データオブジェクトのコレクションをタイムリーに割当解除するためにランタイムのガベージコレクションまたは参照サイクルの検出は必要ない。

ファサードアプローチの分類法では、所与のファサードオブジェクトは、最大１つのグラフオブジェクト及び最大１つのデータオブジェクトに対応する。しかしながら、複数のファサードオブジェクトは同じデータオブジェクトに対応し得る。所与のグラフオブジェクトは、１つ以上の関係オブジェクトに対応し得、所与の関係オブジェクトは、１つ以上のデータオブジェクトに対応できる。したがって、所与のグラフオブジェクトは、所与のグラフオブジェクトが対応する１つ以上の関係オブジェクトを介して１つ以上のデータオブジェクトに対応できる。

図２は、図１に示されるオブジェクトの循環コレクションの例に対するファサードアプローチの適用例を示す。図２に確認できるように、オブジェクトの循環コレクションは、ランタイムにオブジェクトの非循環コレクションとして表される。この例では、データオブジェクト１、４、及び６にはファサードオブジェクトだけがあり、データオブジェクト２、３、５、及び７にはファサードオブジェクトがない。ファサードオブジェクトが１つだけあるセットと、同じ下層のデータオブジェクトの複数のファサードオブジェクトを含むセットとを含む、ファサードオブジェクトの異なるセットが可能になる。さらに、ファサードオブジェクトの異なるセットは、データオブジェクトのコレクションに対するプログラムのアクセスパターン及び変更パターンに応じて、実行中のプログラムの過程の異なる時点で、データオブジェクトのコレクションに対して作成され得る。

ランタイムに、コレクションのデータオブジェクトへの参照は、データオブジェクトのファサードオブジェクトを介して行われる。例えば、図２を参照すると、プログラムがファサードオブジェクト６を使用して、参照ｆの他端にあるデータオブジェクト１を要求する場合、データオブジェクト１またはデータオブジェクト１への参照を提供する代わりに、ファサードオブジェクト１がプログラムに提供される。例えば、ファサードオブジェクト１は、ファサードオブジェクト６の計算プロパティの抽象化によって提供され得る。

ランタイムにどのデータオブジェクトが参照の他端にあるかを判定するために、ファサードオブジェクトはグラフオブジェクトを使用し得る。グラフオブジェクトはマップオブジェクトを含み得る。マップオブジェクトは、データオブジェクト関係をオブジェクトとペアにする。例えば、図２のマップオブジェクトは、データオブジェクト６及びデータオブジェクト１を関係オブジェクトＸにマッピングし得る。特に、プログラムがデータオブジェクト６のファサードオブジェクト６を使用して、参照ｆの他端にあるデータオブジェクトを参照するとき、ファサードオブジェクト６はグラフオブジェクト及びマップオブジェクトを使用して、グラフオブジェクトによって参照される関係オブジェクトのどれが、参照ｆを介してデータオブジェクト６とデータオブジェクト１との間の関係を収集しているかを判定する。次に、ファサードオブジェクト６は、ファサードオブジェクト１を作成し得る。その際に、ファサードオブジェクト１は、ファサードオブジェクト６が関係オブジェクトＸを介して取得するデータオブジェクト１を参照するように作成または構成される。ファサードオブジェクト１は、グラフオブジェクトを参照するように作成または構成される。これは図２に示される。次に、データオブジェクト１の代わりにファサードオブジェクト１は、ファサードオブジェクト６によって呼び出しプログラムに返され、データオブジェクトのコレクションの見かけの循環性ではあるが、実際の非循環性が維持される。

マップオブジェクトは様々な方法で構築され得る。例えば、マップオブジェクトは、アレイの各要素がデータオブジェクトのペアに対応し、データオブジェクトのペア間の全ての関係をグループ化する関係オブジェクトを示す２次元アレイを含み得る。例えば、Ｍが２次元アレイの場合、Ｍ［ｘ］［ｙ］は、データオブジェクトｘとデータオブジェクトｙとの間の全ての関係をグループ化する関係オブジェクトを参照する。２次元アレイの代替として、Ｍ［ｘ］［ｙ］は、データオブジェクトｘからデータオブジェクトｙ（またはデータオブジェクトｙからデータオブジェクトｘ）までの全ての関係をグループ化する関係オブジェクトを参照し得る。代替として、マップオブジェクトは、各アレイ要素がデータオブジェクトと、そのデータオブジェクトから他のデータオブジェクトへの全ての関係をグループ化する関係オブジェクトとに対応する１次元アレイを含み得る。例えば、Ｍ［ｘ］は、データオブジェクトｘから他のデータオブジェクトへの全ての関係をグループ化する関係オブジェクトを参照し得る。

データオブジェクトがランタイムにコレクションに追加されるとき、それはグラフオブジェクトに接続され得る。例えば、図３は、図１のデータオブジェクトの循環コレクションを示すが、データオブジェクト４の参照ｗ及びｘを有するデータオブジェクト８が追加されている。参照ｗ及びｘは、図３のオブジェクトの循環コレクションに参照サイクルを作成する。図４は、データオブジェクト８を追加したオブジェクトのコレクションの見かけ上循環コレクションであるが、実際には非循環コレクションの表現を示す。特に、グラフオブジェクトのマップオブジェクトは、データオブジェクト８及びデータオブジェクト４を関係オブジェクトＹにマッピングするように更新され得る。関係オブジェクトＹは、データオブジェクト８とデータオブジェクト４との間のｗ及びｘの関係を収集する。

ファサードアプローチでは、データオブジェクトはグラフオブジェクトを介して別のデータオブジェクトと関係を築くことができる。これは、データオブジェクトを既存のデータ構造に追加する方法に影響をもたらす。例えば、考えられるソースプログラミング言語で以下のソースコードを検討する。
00: let root = BinaryTree("root", Empty, Empty);
01: let left = BinaryTree("left", Empty, Empty);
02: root.left = left;

行００は、上記に説明したＢｉｎａｒｙＴｒｅｅ＜Ｆ＞再帰的データ型のインスタンスとして「ｒｏｏｔ」データオブジェクトを作成する。図５Ａは、ファサードアプローチによる、上記の行００で作成された「ｒｏｏｔ」データオブジェクトの非循環ランタイム表現を示す。変数「ｒｏｏｔ」は、「ｒｏｏｔ」データオブジェクトを直接参照する代わりに、「ｒｏｏｔ」データオブジェクト及び「ｒｏｏｔ」グラフオブジェクトを参照するファサードオブジェクトである。実行のこの時点において、行０１の「ｌｅｆｔ」オブジェクトインスタンスは作成されていない。したがって、「ｒｏｏｔ」関係オブジェクトは、「ｒｏｏｔ」データオブジェクトと「ｌｅｆｔ」オブジェクトとの間の関係をグループ化しない。

行０１は、上記に説明したＢｉｎａｒｙＴｒｅｅ＜Ｆ＞再帰的データ型のインスタンスとして「ｌｅｆｔ」データオブジェクトを作成する。図５Ｂは、ファサードアプローチによる、上記の行０１で作成された「ｌｅｆｔ」データオブジェクトの非循環ランタイム表現を示す。変数「ｌｅｆｔ」は、「ｌｅｆｔ」データオブジェクトを直接参照する代わりに、「ｌｅｆｔ」データオブジェクト及び「ｌｅｆｔ」グラフオブジェクトを参照するファサードオブジェクトであり、「ｌｅｆｔ」グラフオブジェクトは、図５Ａに示されるように「ｒｏｏｔ」データオブジェクトの「ｒｏｏｔ」ファサードオブジェクトが参照する「ｒｏｏｔ」グラフオブジェクトとは異なるグラフオブジェクトであり得る。実行のこの時点において、「ｒｏｏｔ」データオブジェクトと「ｌｅｆｔ」データオブジェクトとの間には依然として関係がない。したがって、「ｌｅｆｔ」データオブジェクトを参照する「ｌｅｆｔ」関係オブジェクトも、「ｒｏｏｔ」オブジェクトと「ｌｅｆｔ」オブジェクトとの間の関係をグループ化しない。「左の関係オブジェクト」は、図５Ａに示されるように、「ｒｏｏｔ」データオブジェクトを参照する「ｒｏｏｔ」関係オブジェクトとは異なる関係オブジェクトであり得る。

行０２は、「ｒｏｏｔ」オブジェクトの左プロパティを「ｌｅｆｔ」データオブジェクトを参照するように設定する。ファサードアプローチがない場合、「ｒｏｏｔ」データオブジェクトの左プロパティは、ランタイムに「ｌｅｆｔ」データオブジェクトを直接参照し得る。しかしながら、ファサードアプローチを用いると、ソースプログラミング言語のソースコードが、暗黙的なランタイム割当解除をサポートしないターゲットプログラミング言語のソースコードにコンパイルされるとき、そのような直接参照が防止される。具体的には、ターゲット言語ソースコードはランタイムにファサードアプローチを実施するようにコンパイルされ、その結果、ターゲット言語ソースコードが実行可能にコンパイルされ実行されるとき、直接参照が防止される。

図５Ｃは、ファサードアプローチによる、「ｒｏｏｔ」データオブジェクトの左プロパティが「ｌｅｆｔ」データオブジェクトを参照するように割り当てられた後の「ｒｏｏｔ」データオブジェクト及び「ｌｅｆｔ」データオブジェクトの非循環ランタイム表現を示す。このとき、ルート及び左側のファサードオブジェクトが同じグラフオブジェクトを共有するようになる。具体的には、「ｌｅｆｔ」ファサードオブジェクトによって参照される「ｌｅｆｔ」グラフオブジェクト（図５Ｂ）は、「ｒｏｏｔ」ファサードオブジェクトによって参照される「ｒｏｏｔ」グラフオブジェクト（図５Ａ）にインポートされる。その際に、「ｌｅｆｔ」ファサードオブジェクトが更新され、「ｒｏｏｔ」グラフオブジェクトを参照し、「ｌｅｆｔ」グラフオブジェクトを参照しなくなる。「ｒｏｏｔ」グラフオブジェクトによって参照される「ｒｏｏｔ」関係オブジェクトは、「ｌｅｆｔ」データオブジェクトを参照するように更新され、左グラフの「ｌｅｆｔ」関係オブジェクトは「ｌｅｆｔ」データオブジェクトから切断される。ここで、左側のグラフの「ｌｅｆｔ」グラフオブジェクトは、その参照カウントがゼロであるとき割当解除され得る。「ｌｅｆｔ」グラフオブジェクトが割当解除されると、「ｌｅｆｔ」グラフオブジェクトの「ｌｅｆｔ」マップオブジェクト及び「ｌｅｆｔ」関係オブジェクトが割当解除され得る。これは、「ｌｅｆｔ」グラフオブジェクトが割当解除された後、それらの参照カウントをゼロにする必要があるためである。「ｒｏｏｔ」グラフオブジェクトの「ｒｏｏｔ」マップオブジェクトは、「ｒｏｏｔ」データオブジェクトが左側の「データオブジェクト」と関係を築き、その関係が「ｒｏｏｔ」関係オブジェクトによってグループ化されることを指定するために更新される。

図５Ｃの非循環表現は、ランタイムに、図５Ｄに示されるように、「ｒｏｏｔ」データオブジェクトの左プロパティが「ｌｅｆｔ」データオブジェクトを直接参照するという概念を表す。

ここで、上記のソースコードに加えて、考えられるソースプログラミング言語で以下のソースコードを検討する。
03: left.right = root;
04: let extra = root;

ファサードアプローチがない場合、上記の行０３の追加のソースコードにより、ランタイムに「ｒｏｏｔ」データオブジェクトと「ｌｅｆｔ」データオブジェクトとの間に参照サイクルが作成される。しかしながら、ファサードアプローチを用いると、参照サイクルを回避できる。これは図５Ｅに示され、図５Ｅは、ファサードアプローチによる、上記の行０３のように、「ｌｅｆｔ」データオブジェクトの右プロパティがファサードオブジェクトを経由して「ｒｏｏｔ」データオブジェクトを参照するように割り当てられた後の「ｒｏｏｔ」データオブジェクト及び「ｌｅｆｔ」データオブジェクトの非循環ランタイム表現を示す。「ｒｏｏｔ」データオブジェクト及び「ｌｅｆｔ」データオブジェクトは、依然として、（１）「ｒｏｏｔ」データオブジェクトの左プロパティを介した「ｒｏｏｔ」データオブジェクトと「ｌｅｆｔ」データオブジェクトとの間の関係、（２）「ｌｅｆｔ」データオブジェクトの右プロパティを介して作成された「ｒｏｏｔ」データオブジェクトと「ｌｅｆｔ」データオブジェクトとの間の関係、の両方をグループ化する「ｒｏｏｔ」関係オブジェクトを共有する。「ｅｘｔｒａ」という名前の変数は、「ｒｏｏｔ」グラフオブジェクト及び「ｒｏｏｔ」データオブジェクトを参照するファサードオブジェクトである。

ここで、上記のソースコードに加えて、考えられるソースプログラミング言語で以下のソースコードを検討する。
05: let super = BinaryTree("root", Empty, Empty);
06: super.left = root;

行０５は、上記に説明したＢｉｎａｒｙＴｒｅｅ＜Ｆ＞再帰的データ型のインスタンスとして「ｓｕｐｅｒ」データオブジェクトを作成する。行０６は、上記の行００で作成された「ｒｏｏｔ」データオブジェクトを参照するように「ｓｕｐｅｒ」データオブジェクトの左プロパティを設定する。ファサードアプローチでは、行０６は、結果として、ランタイムの暗黙的な割当解除をサポートしないターゲット言語の場合、ランタイムに「ｒｏｏｔ」グラフオブジェクトが「ｓｕｐｅｒ」グラフオブジェクトにインポートされ得る。このインポートは図５Ｆに示される。図５Ｆは、ファサードアプローチによる、インポート後の「ｓｕｐｅｒ」、「ｒｏｏｔ」、及び「ｌｅｆｔ」データオブジェクトの非循環表現を示す。「ｒｏｏｔ」及び「ｌｅｆｔ」ファサードオブジェクトは、「ｓｕｐｅｒ」グラフオブジェクトを参照するように更新されている。「ｓｕｐｅｒ」グラフオブジェクト及び「ｓｕｐｅｒ」マップオブジェクトが更新され、「ｒｏｏｔ」関係オブジェクトへの「ｒｏｏｔ」データオブジェクトの左プロパティ（上記の行０２）を介して、「ｒｏｏｔ」データオブジェクトと「ｌｅｆｔ」データオブジェクトとの間の関係がマッピングされる。また、「ｓｕｐｅｒ」グラフオブジェクト及び「ｓｕｐｅｒ」マップオブジェクトも更新され、「ｓｕｐｅｒ」関係オブジェクトへの「ｓｕｐｅｒ」データオブジェクトの左プロパティ（上記の行０６）を介して、「ｓｕｐｅｒ」オブジェクトと「ｒｏｏｔ」データオブジェクトとの間の関係がマッピングされる。ファサードアプローチがない場合でも、行０３が参照サイクルを作成するようにプログラムされている場合でも、非循環性が維持されることに留意されたい。

上記の行０４で「ｒｏｏｔ」データオブジェクトを参照するように割り当てられた「ｅｘｔｒａ」ファサードオブジェクトは、依然として、上記の行０６によってグラフのインポートが生じた後、「ｒｏｏｔ」グラフオブジェクトを参照し得ることに留意されたい。しかしながら、グラフのインポートにより、「ｒｏｏｔ」グラフオブジェクトは「ｒｏｏｔ」関係オブジェクトを参照しなくなる。言い換えれば、「ｅｘｔｒａ」ファサードオブジェクトは、上記の行０６によって生じたグラフのインポートによって「放棄（ａｂａｎｄｏｎｅｄ）」されている。この放棄は図５Ｆに示されている。確認できるように、「ｒｏｏｔ」マップオブジェクトは「ｒｏｏｔ」関係オブジェクトに接続されていない。したがって、上記の行０６以降、ソースプログラミング言語のソースコードプログラマーは、「ｒｏｏｔ」データオブジェクトが別のオブジェクトと築く関係を逆参照するために「ｅｘｔｒａ」ファサードオブジェクトを使用することを試みないことを注意する必要があり得る。例えば、以下の追加のソースコードを検討する。
07: A = root.left;
08: B = extra.left;

ランタイム、図５Ｆに示されるインポート後、結果として、上記の行０２の割り当てにより、変数Ａは「ｌｅｆｔ」データオブジェクトを参照するファサードオブジェクトになるであろう。しかしながら、行０８のステートメントは、「ｅｘｔｒａ」ファサードオブジェクトが図５Ｆに示されるグラフのインポートによって破棄されたため、ランタイムエラーまたはフォールトを生成するであろう。ソースプログラミング言語で慎重にプログラミングすると、グラフのインポートによってファサードオブジェクトが放棄されるのを回避できる。例えば、行０４の余分な変数の作成は省略され、既に作成されている「ｒｏｏｔ」ファサードオブジェクトが代わりに使用され得る。

同じ下層のデータオブジェクト及び同じ下層のグラフオブジェクトを参照する異なるファサードオブジェクトについて、ファサードオブジェクトのメモリアドレスの比較に基づいて同等かどうか適切に比較できない。これは、ファサードオブジェクトが異なるメモリアドレスに記憶されているためである。しかしながら、両方のファサードオブジェクトが同じ下層のデータオブジェクト及び同じ下層のグラフオブジェクトを参照する場合、ファサードオブジェクトは別のファサードオブジェクトと意味的に同じである。ファサードアプローチによれば、ターゲットプログラミング言語（例えば、ＣまたはＣ＋＋）の等価演算子をオーバーライドでき、その結果、２つのファサードオブジェクトが等しいかどうかを比較するとき、それらのファサードオブジェクトが同じ下層のデータオブジェクト及び同じ下層のグラフオブジェクトを参照している場合に演算子が２つのファサードオブジェクトが等しいことを示し、そして、それらのファサードオブジェクトが異なるデータオブジェクトまたは異なるグラフオブジェクトを参照している場合は等しくないことを示す。

データ型定義の可能なサイクルの確認
既に述べたように、データオブジェクトのコレクションにランタイムに参照サイクルが含まれない場合、参照カウントはデータオブジェクトのタイムリーな割当解除に十分である。ガベージコレクションまたはサイクル検出等のより高度な割当解除メカニズムは必要ない。

ランタイムに、データオブジェクトがどのように生成され、どのように変化するかは、ソースプログラミング言語のソースコードのデータ型の定義によって決まる。ソースプログラミング言語は、ランタイムに参照サイクルが発生するのを防止するのに十分な制限をソース内のデータ型定義に課すことができる。

例えば、考えられるソースプログラミング言語での「Ｃｏｎｓ」リストの以下のデータ型定義を検討する。Ｃｏｎｓ＜Ｆ＞データ型は、空であるか、または先頭要素、及び残りの要素を含む別のリストであるテールを有するか、のいずれか一方の再帰的データ型である。
00: closed type List<E>;
01: closed concrete type Cons<F> extends List<F> {
02: head: F;
03: tail: List<F>;
04: }
05: closed concrete type Empty<G> extends List<G> {}

上記のデータ型定義は、ランタイムの参照サイクルの影響を受けやすくなる。例えば、以下の例のように、それ自体でテールを指すように構成されるＣｏｎｓ＜Ｆ＞データオブジェクトを作成することによって、「ウロボロス（ｏｕｒｏｂｏｒｏｓ）」リストを作成できる。
06: let list = Cons(0, Empty);
07: list.tail = list;

本技術の一部によれば、ランタイムの参照サイクルの影響を受けやすいソースプログラミング言語のソースコードのデータ型定義は、ソースコードのコンパイル時に検出される。次に、コンパイラはプログラマーにアラートを発することができる、またはソースコードのコンパイルを停止できる。アラートは、例えば、ユーザーインターフェースに提示されるワーニングメッセージもしくはエラーメッセージ、またはファイルへの出力等であり得る。代わりに、ソースコードの潜在的な参照サイクルを検出してアラートを生成するコンパイラ、専用の型チェックツール、または他のソースコード管理ツールは検出及びアラーティングを行い得る。

概して、データ型定義の潜在的な参照サイクルの検出は、ソースプログラミング言語コンパイラが、関係する各データ型のノードを伴うデータ型定義グラフを作成し、その後、そのデータ型を表すノードに各プロパティのエッジを追加することを含む。上記のＣｏｎｓ＜Ｆ＞型等のジェネリックデータ型の場合、コンパイラはデータ型パラメーターをコンテキスト化する。コンテキスト化は、抽象的データ型定義ではなく、具象データ型定義ごとにグラフを作成することによって達成される。具象データ型定義はランタイムにそのデータ型のデータオブジェクトをインスタンス化するために使用できるが、抽象データ型定義はそこから導出した具象データ型をサポートするためだけに存在する。具象データ型定義ごとのグラフを用いると、コンパイラはデータ型パラメーターを具象データ型定義で定義されたもののコンテキストに変換できるため、ソースプログラミング言語のソースコードのプログラマーが、例えば、複数のリストのうちの１つのリスト等のネストされたデータ構造を定義し、安全に使用することを可能にする。さらに、コンパイラは、データ型パラメーターごとに、データ型パラメーターがバインドし得るデータ型に関する最悪のケースを表す「リミットノード」を作成する。

図６Ａは、上記に定義した具象データ型及びジェネリックデータ型Ｃｏｎｓ＜Ｆ＞のデータ型定義グラフの例である。グラフの実線のエッジは、ランタイムの参照サイクルに関係し得るエッジを表す。そのグラフは、ランタイムに参照サイクルが発生し得る２つの方法を示す。

第１の方法では、エッジ６０２は、Ｃｏｎｓ＜Ｆ＞型のデータオブジェクトが、そのテールプロパティを介してＬｉｓｔ＜Ｆ＞型のデータオブジェクトを指すことができることを表す。エッジ６０４は、Ｌｉｓｔ＜Ｆ＞型のデータオブジェクトがＣｏｎｓ＜Ｆ＞型のデータオブジェクトでもあり得ることを表す。

第２の方法では、ジェネリックデータ型ＦがＴｏｐのような非常にジェネリックデータ型（全てのデータオブジェクトを含む仮想のスーパーデータ型を表す）でインスタンス化された場合、Ｃｏｎｓ＜Ｆ＞型のデータオブジェクトはそのヘッドプロパティを介して、型Ｆのデータオブジェクトを指し得、型Ｆは、Ｃｏｎｓ＜Ｆ＞型のデータオブジェクトへの独自のプロパティ参照を有するいくつかの未知のデータ型であり得る。第２の方法は、図６Ａのエッジ６０６、６０８、及び６１０によって表される。

第１のデータ型の参照サイクルは、データ型定義に２つの余分な情報を含めることを可能にすることによって解決できる。この情報は、ソースプログラミング言語のソースコードのプログラマーが手動で入力できる、ソースコードの静的分析に基づいて推論できる、または、例えば、自動もしくは半自動のデータ型チェックツール等、その情報が自動もしくは半自動ツール等で必要とされるためソースコードに自動的に追加できる。

データオブジェクトのプロパティがランタイムに、そのプロパティを含むデータオブジェクトよりも古いデータオブジェクトだけを指すことができる場合、そのプロパティは参照サイクルには不十分である。したがって、プロパティの初期値がそのプロパティを含むデータオブジェクトよりも古く、プロパティがその初期値から変更できない（例えば、読み取り専用である）とコンパイラによって判定できる場合、そのプロパティは参照サイクルとしては不十分である。

本技術によれば、データオブジェクトのデータ型定義のデータオブジェクトのプロパティに対して、２つのメタプロパティを暗黙的に（例えばデフォルトで）または明示的に（例えばプログラマーによって）定義し得る。
・読み取り専用－「読み取り専用（ｒｅａｄ ｏｎｌｙ）」プロパティは、最初に割り当てられた値から変更できないデータオブジェクトのプロパティである。
・初期－「初期（ｅａｒｌｙ）」プロパティは、単にデータオブジェクトのプロパティを初期化する手段として使用される代わりに、そのプロパティを含むデータオブジェクトへの任意の参照が値として使用される前に、最初に割り当てられる値が判定されるデータオブジェクトのプロパティである。この後者の制限は、コンストラクターでの例外的なケースが回避される。

上記の２つのメタプロパティを用いると、以下の例のように、以下の読み取り専用の初期ヒントを用いて、上記のデータ型定義の例を変更できる。
00: closed type List<E>;
01: closed concrete type Cons<F> extends List<F> {
02: head: F;
03: readonly early tail: List<F>;
04: }
05: closed concrete type Empty<G> extends List<G> {}

コンパイラがコンパイル時にデータ型定義のプロパティが読み取り専用であるかどうかを判定するのに、様々な方法がある。特別な方法は必要ない。１つの方法は、プロパティ定義でプログラマーによって明示的にプログラムされたキーワードヒントに基づいている。キーワードのヒントは、「ｃｏｎｓｔ」、「ｆｉｎａｌ」、「ｒｅａｄｏｎｌｙ」等である。別の方法は、例えば、プロパティ定義に「変更可能（ｍｕｔａｂｌｅ）」または「書き込み可能（ｗｒｉｔｅａｂｌｅ）」キーワードヒントが存在しない等、逆の意味があるキーワードヒントが存在しないことに基づき得る。さらに別の方法は、コンパイラがソースコードの静的分析を実行して、初期値が割り当てられた後にプロパティに値を設定できたソースコードのいずれかが実際に設定されているかどうかを判定することである。そうでない場合、コンパイラはプロパティが読み取り専用であると推論できる。静的分析は、プロパティ定義の明示的なキーワードヒント（例えば「読み取り専用（ｒｅａｄ－ｏｎｌｙ）」）によってトリガーできる。

また、コンパイラは、プロパティが初期化された後のランタイムにプロパティに値が割り当てられないようにする追加命令をコンパイル時に挿入することによって、プロパティを強制的に読み取り専用にすることもできる。さらに、またはその代わりに、追加命令は、プロパティが初期化された後にプロパティに値を割り当てようとするランタイムにおける任意の試行をログに記録し得る（例えば、ランタイム診断ログまたはランタイムプロファイラログに記録する）。

同様に、コンパイラがコンパイル時にプロパティが初期であるかどうかを判定できる様々な方法がある。特別な方法は必要ない。１つの方法は、プロパティ定義のキーワードヒントの有無に基づいている。別の方法は、コンパイラがソースコードを静的に分析して、含まれているデータオブジェクトを値として任意の参照が行われる前にプロパティが初期化されているかを判定することである。静的分析は、プロパティ定義の明示的なキーワードヒント（例えば「初期」）によってトリガーできる。

コンパイラは、また、プロパティを含むデータオブジェクトへの参照が値として使用された後、ランタイムにプロパティが初期化されないようにコンパイル時に追加命令を挿入することによって、プロパティを強制的に初期にすることもできる。さらに、またはその代わりに、追加命令は、プロパティを含むデータオブジェクトへの参照が値として使用された後、ランタイムにプロパティを初期化する任意の試行をログに記録し得る（例えば、ランタイム診断ログまたはランタイムプロファイラログに記録する）。

また、コンパイラがコンパイル時にデータ型がクローズしているかどうかを判定できる様々な方法もある。クローズデータ型は、コンパイル時にあらゆる全てのサブデータ型がコンパイラに知られるデータ型である。コンパイラは、「ファイナル（ｆｉｎａｌ）」、「クローズド（ｃｌｏｓｅｄ）」、「シールド（ｓｅａｌｅｄ）」等のデータ型定義の明示的なキーワードヒントに基づいて、または「オープン（ｏｐｅｎ）」等の反対の意味があるデータ型定義の明示的なキーワードヒントに基づいて、データ型がクローズされているかどうかを判定できる。クローズ性は、コンテキストに基づいたソースコードの静的分析の一部としてコンパイラによって推論され得る。例えば、データ型定義へのアクセスが情報隠蔽メカニズムによっていくつかのモジュールまたはパッケージに制限されており、それらのモジュールまたはパッケージにデータ型のサブデータ型の定義が存在しない場合、コンパイラはそのデータ型がクローズしていると推論できる。

また、コンパイラがコンパイル時にデータ型が具体的であるかどうかを判定できる様々な方法もある。具象データ型は、そのデータ型のサブデータ型のインスタンスではない、その型のデータオブジェクトとして存在する可能性があるデータ型である。具象データ型は、データオブジェクトを定義するには不十分であるが具象サブデータ型を導出し得る抽象データ型とは対照的である。コンパイラは、「具象的（ｃｏｎｃｒｅｔｅ）」等のデータ型定義の明示的なキーワードヒントの存在に基づいて、または「抽象的（ａｂｓｔｒａｃｔ）」等の逆の意味があるデータ型定義の明示的なキーワードヒントの存在に基づいて、データ型が具体的であると判定できる。コンパイラは、データ型のデータオブジェクトを構築するためにソースコードでデータ型を使用する等、ソースコードの静的分析によって、またはデータ型のデータオブジェクトの構築を妨げるようなソースコードのデータ型のデータ型定義に定義要素が存在しないことによって、データ型の具体性を推論し得る。全てのデータオブジェクトは具象データ型である必要があるため、参照サイクルが作成される可能性について具象データ型だけを型チェックするだけで十分である。

図６Ｂは、読み取り専用ヒント及び初期ヒントを使用する上記のデータ型定義のデータ型定義グラフの例である。確認できるように、エッジ６０２及びエッジ６０４は、ここで、対応する参照がランタイムの参照サイクルの作成に関与できないことを反映するために断線している。さらに、テールプロパティのエッジ６０２は、厳密に未満の関係（「＜」）、以下の関係（「＜＝」）を有するようになった。意味的には、データ型定義グラフのサイクルのエッジが以下の関係（「＜＝」）がある場合、エッジによって表されたデータ型定義の一部がランタイムの参照サイクルに対して不十分になる既知の順序付けが存在する。既知の順序付けの１つのタイプは、読み取り専用の初期関係である。例えば、テールプロパティに対する読み取り専用で早期の制限のため、図６Ａのエッジ６０２及びエッジ６０４の潜在的な参照サイクルは、図６Ｂに表されるような潜在的な参照サイクルではなくなっている。データ型がそれ自体の値以下であると主張することに矛盾はないことが認識される。

しかしながら、図６Ｂのエッジ６０６、６０８、及び６１０によって表された潜在的な参照サイクルが依然として存在する。特に、テールプロパティに読み取り専用の初期ヒントが設定されている場合でも、Ｃｏｎｓ＜Ｆ＞データオブジェクトのヘッドプロパティが未知の型Ｆのデータオブジェクトを参照でき、次に、そのデータオブジェクトがＣｏｎｓ＜Ｆ＞データオブジェクトを逆に指すことができたことによって、参照サイクルが作成される。これは、ヘッドプロパティが読み取り専用で早期であっても同様である。この理由として、ヘッドプロパティは、Ｃｏｎｓ＜Ｆ＞データオブジェクトを参照する未知の型Ｆのデータオブジェクトに初期化できたためである。

図６Ｂのエッジ６０６、６０８、及び６１０によって表されたタイプの参照サイクルを防止するには、参照がそれ自体に対するものでない限り、特定のデータ型のデータオブジェクトが同じ特定のデータ型の別のデータオブジェクトを参照できるようにすることが望ましい。例えば、それ自体を参照しない複数のリストのうちの１つのリストを可能にすべきである。さらに、プリミティブデータ型を含むデータオブジェクトも可能にすべきである。例えば、文字列または数値のリストを可能にすべきである。

データオブジェクトのプロパティが任意のデータ型であり得るジェネリックデータ型である等の問題に対処するには、ソースプログラミング言語のソースコードで表現された追加の制限を使用し得る。例えば、以下の「Ｃｏｎｓ」リストのデータ型定義を検討する。
00: closed type List<E ┤ Cons<E>>;
01: closed concrete type Cons<F ┤ Cons<F>> extends List<F> {
02: head: F;
03: readonly early tail: List<F>;
04: }
05: closed concrete type Empty<G ┤ Cons<G>> extends List<G> {}

上記の例では、Ａ ┤ Ｂという表記は、ＡタイプのデータオブジェクトがランタイムにＢタイプのデータオブジェクトを直接参照してはいけないこと、またはＢタイプのデータオブジェクトを直接参照する任意のデータオブジェクトを直接参照してはいけないことを意味する。本技術は、例えばＬｉｓｔ＜Ｎｕｍｂｅｒ＞が有効であるかどうかを判断するとき、この表記に従っている。ソースコードエディタで使用されるフォント合字に応じて、表記はダッシュバーとして書かれ得、シンボルはソースプログラミング言語のソース内で（'┤'）または（'－｜'）として見え得る。他のテキストベースの表記を使用して、「ＡはＢを指してはいけない」という制限を表現し得、本発明はダッシュバー表記に限定されない。

本技術によれば、上記のデータ型定義の結果、Ｃｏｎｓ＜Ｆ＞のデータ型定義はジェネリックで再帰的であり、重要なことに参照サイクルがない。

図６Ｃは、読み取り専用ヒント及び初期ヒントならびに追加情報を使用する上記のデータ型定義のデータ型定義グラフの例である。確認できるように、データ型定義は、Ｃｏｎｓ＜Ｆ＞からの参照で開始し、Ｃｏｎｓ＜Ｆ＞からＣｏｎｓ＜Ｆ＞に戻る'＜'エッジを伴う潜在的な参照サイクルがない。図６Ｂのデータ型定義グラフと図６Ｃのデータ型定義グラフとの違いは、Ｆデータオブジェクトが「Ｔｏｐ ┤ （）」の代わりに「Ｔｏｐ ┤ （Ｃｏｎｓ＜Ｆ＞）」であり得ることである。この制限により、Ｔｏｐ（すなわち、全てのスーパーデータ型）、またはＬｉｓｔ＜Ｆ＞もしくはＣｏｎｓ＜Ｆ＞への「可能性のある（ｍａｙ－ｂｅ）」接続は存在しない。しかしながら、何も参照しないＥｍｐｔｙ＜Ｆ＞が可能になる。

データ型チェックプロセスの例
図７Ａ、図７Ｂ、図７Ｃ、図７Ｄ、図７Ｅ、図７Ｆ、図７Ｇ、図７Ｈは、データ型チェックプロセスの例のフローチャートを含む。データ型チェックプロセスは、ソースコードが具象データ型定義を含む、ソースプログラミング言語のソースコードのコンパイラによって行われ得る。コンパイラは、データ型チェックプロセスを行って、具象データ型定義がランタイムに参照サイクルを可能にしているかどうかを判定し得る。ランタイムに参照サイクルを可能にする具象データ型定義を検出すると、コンパイラはコンパイルプロセスを停止できる、またはアラートを出力できる。アラートは、ユーザーインターフェース（例えば、グラフィカルまたはコマンドライン）、ファイルに、データベースに、またはアラートに適した別のデータコンテナに出力できる。アラートは、型チェックプロセスによって識別された具体的型定義に問題があったことを示すエラーメッセージまたはワーニングメッセージであり得る。例えば、メッセージは、ランタイムの参照サイクルを可能にする具象データ型定義を識別し得る。例えば、識別は、ソースコードファイルの名前及びソースコードファイルの行番号、または、具象データ型定義が定義されているソースコードファイルの行番号のセットもしくはスパンを、エラーまたはワーニングの説明と一緒に含み得る。例えば、説明は「ｍｙｓｏｕｒｃｅ．ｓｒｃの５２行目で定義された具体的型Ｃｏｎｓ＜Ｆ＞は参照サイクルを可能にする。」のような内容が記載され得る。

型チェックプロセスを行うコンパイラは、ソースプログラミング言語のソースコードを１つ以上のターゲットプログラミング言語にコンパイルするソース・トゥ・ソース・コンパイラであり得、１つ以上のターゲットプログラミング言語は、割当解除の最小のランタイムサポート（例えば、非暗黙的な割当解除サービス）を用いた、少なくとも１つのターゲットプログラミング言語を含む。例えば、ターゲットプログラミング言語は、Ｃ、Ｃ＋＋、ＯＢＪＥＣＴＩＶＥ－Ｃ、またはＲＵＳＴのいずれかであり得る。代替として、ソースコードのコンパイラは、ソースコードの中間表現をターゲットプログラミング言語にさらに翻訳することなく、品質管理の目的でソースコードを処理し得る。さらに別の代替として、コンパイラは、ソースプログラミング言語のソースコードを、全てのターゲット言語が暗黙的な割当解除をサポートする１つ以上のターゲットプログラミング言語にコンパイルするソース・トゥ・ソース・コンパイラであり得る。この場合、型チェックは、例えばランタイムのガベージコレクションまたはサイクル検出の必要性を軽減または排除する等の品質管理のために行われ得る。

図７Ａから開始するように、データ型チェックプロセスは、ソースコードで定義された具象データ型Ｃのデータ型チェックグラフ用の未構築ノードの空リストから開始する（７１２）。空リストは、コンピューターストレージ媒体で初期化された適切なリストデータ構造であり得る。実施例として、データ型チェックプロセスの説明では、考えられるソースプログラミング言語で表現された以下のデータ型定義を使用する。
00: closed type List<E ┤ Cons<E>>;
01: closed concrete type Cons<F ┤ Cons<F>> extends List<F> {
02: head: F;
03: readonly early tail: List<F>;
04: }
05: closed concrete type Empty<G ┤ Cons<G>> extends List<G> {}

実施例では、Ｃは具象データ型Ｃｏｎｓ＜Ｆ＞である。

動作７１４において、グラフの具象データ型Ｃのノードを表す要素は未構築ノードリストに追加される。実施例では、具象データ型Ｃｏｎｓ＜Ｆ＞のノードを表す要素は未構築ノードリストに追加され得る。

動作７１６において、未構築ノードリストが空である（すなわち、任意の要素を含まない）であるかどうかを判定する。未構築ノードリストが空でない場合、動作７１８、７２０、７２２、及び７２４は、未構築ノードリスト上の現在のノードに対して行われる。

動作７１８において、未構築ノードリスト上の現在のノードＮが識別される。例えば、現在のノードＮは、未構築ノードリストに最近追加された要素に対応するノードであり得る。実施例では、現在のノードＮは、具象データ型Ｃｏｎｓ＜Ｆ＞に対して追加されたノードであり得る。

動作７２０において、現在のノードＮを表す要素が未構築ノードリストから除去される。実施例では、具象データ型Ｃｏｎｓ＜Ｆ＞の現在のノードＮを表す要素は、未構築ノードリストから除去され得る。

動作７２２は、現在のノードＮによって表されたデータ型を拡張するソースコードで定義されたダイレクトサブデータ型Ｓごとに行われる。サブデータ型は、トレイトベースの継承をサポートするオブジェクト指向プログラミング言語で通常可能になるように、サブクラスまたは子クラスの意味で現在のノードＮによって表されたデータ型を直接拡張し得る。ソースプログラミング言語は、そのようなトレイトベースの継承をサポートし得る。トレイトは、細粒度コード再利用のためのメカニズムを提供する。トレイトは、クラス階層から独立した方法のセットとして定義され得、一連の合成操作によって他のトレイトまたはクラスを構築するために柔軟に使用できる。

動作７２２は、図７Ｂに関してより詳細に示される。実施例では、現在のノードＮがＣｏｎｓ＜Ｆ＞データ型であるとき、動作７２２は、Ｃｏｎｓ＜Ｆ＞データ型を拡張するように定義されたダイレクトサブデータ型が存在しないため、具象データ型Ｃｏｎｓ＜Ｆ＞の任意のダイレクトサブデータ型Ｓに対して行わない場合がある。

動作７２４は、現在のノードＮによって表されたデータ型のプロパティＰごとに行われる。データ型のプロパティ［ＡＳ１２］は、現在のノードＮによって表されたデータ型の定義のソースコードのメンバー変数定義に対応し得る。メンバー変数は、データ型の静的変数またはインスタンス変数であり得る。動作７２４は、図７Ｃに関してより詳細に示される。実施例では、動作７２４は、Ｃｏｎｓ＜Ｆ＞データ型に対して定義されたヘッドプロパティ及びテールプロパティのそれぞれに対して行われ得る。

現在のノードＮに対して動作７１８、７２０、７２２、及び７２４が行われた後、プロセスは動作７１６に戻り、他のノードに対応する未構築ノードリスト上の任意の残りの要素を検討する。動作７１６で未構築ノードリストに要素が残っていない場合、動作７２６において、動作７２０で除去された全てのノードの要素は、図７Ｄに関して下記に説明されるようなさらなる処理のために未構築ノードリストに再び追加される。

既に述べたように、図７Ａの動作７２２は、現在のノードＮによって表されたデータ型を直接拡張するソースコードのサブデータ型Ｓごとに行われる。図７Ｂは動作７２２のフローチャートである。

動作７２８において、現在のダイレクトサブデータ型Ｓがジェネリック型である場合、現在のダイレクトサブデータ型Ｓは、現在のノードＮによって表されたデータ型の型パラメーターを使用して変換される。例えば、「ｃｌａｓｓ Ｓｕｂ＜Ｘ＞はＳｕｐｅｒ＜Ｂａｒ＜Ｘ＞＞を拡張する」等の型関係及び「Ｓｕｐｅｒ＜Ｂａｒ＜Ｂａｚ＞＞」等のスーパー型を所与とすると、変換は、Ｓｕｂの型パラメーターのそれぞれに対する適切なバインディングを見つけることを含み得る。この例では、ＸはＢａｚにバインドされ、Ｓｕｂ＜Ｂａｚ＞がＳｕｐｅｒ＜Ｂａｒ＜Ｂａｚ＞＞を拡張するため、変換されたサブデータ型はＳｕｂ＜Ｂａｚ＞になるであろう。これは、Ｓｕｂ＜Ｘ＞がＳｕｐｅｒ＜Ｂａｒ＜Ｘ＞＞を拡張することが、ＸがＢａｚに置換されたとき、それを反映するため知られており、そして、Ｘにバインドされなくなり、ＸがＢａｚにバインドすることが防止されるであろう。

動作７３０において、現在のダイレクトサブデータ型Ｓのノードを表す要素が未構築ノードリスト上にあるかどうかを判定する。ない場合、動作７３２において、現在のダイレクトサブデータ型Ｓを表すノードに対して要素が作成され、動作７３４において、その要素が未構築ノードリストに追加される。いずれの場合も、具象データ型Ｃのデータ型定義グラフにエッジが追加され（７３６）、エッジは現在のノードＮから現在のダイレクトサブデータ型Ｓのノードまでである。エッジは、現在のノードＮによって表されたデータ型のインスタンスであるデータオブジェクトが、現在のダイレクトサブデータ型Ｓのインスタンスでもあり得るという点で「可能性のある」要件で限定される。

既に述べたように、図７Ａの動作７２４は、ソースコードで定義された現在のノードＮによって表されたデータ型のプロパティＰごとに行われる。図７Ｃは、動作７２４のフローチャートである。実施例では、現在のノードＮがＣｏｎｓ＜Ｆ＞データ型を表す場合、動作７２４がヘッドプロパティ及びテールプロパティのそれぞれに対して行われる。

動作７３８において、現在のプロパティＰのデータ型は、現在のノードＮによって表されたデータ型の型パラメーターを使用して変換される。この実施例では、現在のプロパティＰがＣｏｎｓ＜Ｆ＞データ型のヘッドプロパティであるとき、現在のプロパティＰのデータ型はジェネリック型Ｆである。現在のプロパティがＣｏｎｓ＜Ｆ＞データ型のテールプロパティであるとき、現在のプロパティＰのデータ型はＬｉｓｔ＜Ｆ＞である。

動作７４０において、現在のダイレクトサブデータ型Ｓのノードを表す要素が未構築ノードリスト上にあるかどうかを判定する。ない場合、動作７４２において、現在のプロパティＰのデータ型を表すノードに対して要素が作成される。動作７４４において、その要素が未構築ノードリストに追加される。この実施例では、現在のプロパティＰがＣｏｎｓ＜Ｆ＞データ型のヘッドプロパティであるとき、ジェネリックデータ型Ｆを表すグラフのノードの要素は未構築ノードリストに追加される。現在のプロパティＰがＣｏｎｓ＜Ｆ＞データ型のテールプロパティであるとき、Ｌｉｓｔ＜Ｆ＞データ型を表すグラフのノードの要素が未構築ノードリストに追加される。

動作７４６において、現在のプロパティＰが読み取り専用で初期として定義されている場合がある。実施例では、現在のプロパティＰがＣｏｎｓ＜Ｆ＞データ型のヘッドプロパティであるとき、Ｃｏｎｓ＜Ｆ＞データ型のデータ型定義のプロパティ定義にそのようなキーワードヒントがないため、現在のプロパティＰが読み取り専用でなく初期でないと判定され得る。他方では、現在のプロパティＰがＣｏｎｓ＜Ｆ＞データ型のテールプロパティであるとき、現在のプロパティＰが、Ｃｏｎｓ＜Ｆ＞データ型のテールプロパティに関するプロパティ定義のそのようなキーワードヒントの存在によって読み取り専用で早期であることを判定し得る。

動作７４８において、現在のプロパティＰが読み取り専用で初期である場合、具象データ型Ｃのデータ型定義グラフにエッジが追加され、エッジは、現在のノードＮから現在のプロパティＰのデータ型を表すノードまでである。エッジは「＜＝」要件で限定される。実施例では、現在のプロパティＰがＣｏｎｓ＜Ｆ＞データ型のテールプロパティであるとき、テールプロパティが読み取り専用で初期であるため、「＜＝」要件があるエッジがＣｏｎｓ＜Ｆ＞データ型を表すノードからＬｉｓｔ＜Ｆ＞データ型を表すノードに追加されるであろう。

動作７５０において、現在のプロパティＰが読み取り専用でなく初期でない場合、具象データ型Ｃのデータ型定義グラフにエッジが追加され、エッジは、現在のノードＮから現在のプロパティＰのデータ型を表すノードまでである。この場合、エッジは「＜」要件で限定される。実施例では、現在のプロパティＰがＣｏｎｓ＜Ｆ＞データ型のヘッドプロパティであるとき、ヘッドプロパティが読み取り専用でなく初期でないため、「＜」要件があるエッジがＣｏｎｓ＜Ｆ＞データ型を表すノードからＦデータ型を表すノードに追加されるであろう。

実施例では、Ｃｏｎｓ＜Ｆ＞データ型のヘッドプロパティ及びテールプロパティに対して動作７２４が行われた後、プロセスは動作７１６に戻り、未構築ノードリストが空であるかを判定する。ジェネリックデータ型Ｆ及びＬｉｓｔ＜Ｆ＞データ型の要素が未構築ノードリストに追加されたため、リストは空ではない。これらのノードは動作７２０でリストから除去される。動作７２２は、Ｌｉｓｔ＜Ｆ＞データ型を拡張するダイレクトサブデータ型Ｅｍｐｔｙ＜Ｆ＞を有するため、Ｌｉｓｔ＜Ｆ＞データ型によって行われる。ジェネリックデータ型Ｆを拡張するダイレクトサブデータ型がないため、ジェネリックデータ型Ｆに対して動作７２２は行われない。これらのデータ型には定義されたプロパティがないため、ジェネリックデータ型ＦまたはＬｉｓｔ＜Ｆ＞データ型に対して動作７２４は行われない。Ｌｉｓｔ＜Ｆ＞データ型に対して動作７２２を行った結果として、Ｅｍｐｔｙ＜Ｆ＞データ型のノードがグラフに追加され（動作７３４）、「可能性のある」要件があるエッジがＬｉｓｔ＜Ｆ＞データ型のノードからＥｍｐｔｙ＜Ｆ＞データ型の新しいノードに追加される（動作７３６）。プロセスが再び動作７１６に戻るとき、Ｅｍｐｔｙ＜Ｆ＞データ型を表すノードの要素だけが未構築ノードリストにある。その要素は動作７２０で除去され、Ｅｍｐｔｙ＜Ｆ＞データ型に、それを拡張する任意のダイレクトサブデータ型または任意の定義されたプロパティがないため、動作７２２及び動作７２４はノードに対して行われない。

ここで図７Ｄを参照すると、具象データ型Ｃのデータ型チェックプロセスは、図７Ａ、図７Ｂ、及び図７Ｃのサブプロセスに従って構築された全てのノードの要素が未構築ノードリストに再び追加された後の、図７Ａの動作７２６から得られる未構築ノードのリストを継続する。実施例では、プロセスのこの時点における、Ｅｍｐｔｙ＜Ｆ＞、Ｌｉｓｔ＜Ｆ＞、Ｆ、及びＣｏｎｓ＜Ｆ＞のデータ型のノードがある。これらのノードの要素は、未構築ノードリストに再び追加される。

動作７５２において、未構築ノードリストが空である（すなわち、任意の要素を含まない）であるかどうかを判定する。未構築ノードリストが空でない場合、ノードを構築するために、動作７５４、７５６、及び７５８は、未構築ノードリスト上の現在のノードに対して行われる。

動作７５４において、未構築ノードリスト上の現在のノードＮが識別される。例えば、現在のノードＮは、未構築ノードリストに最近追加された要素に対応するノードであり得る。

動作７５６において、現在のノードＮを表す要素が未構築ノードリストから除去される。

動作７６０、７６２、７６４、７６６、及び７６８は、ソースコードで定義されているように、現在のノードＮによって表されたデータ型が直接拡張する各スーパーデータ型に対して行われ得る。現在のノードＮによって表されたデータ型は、トレイトベースの継承をサポートするオブジェクト指向プログラミング言語で通常可能になるように、スーパークラスまたは親クラスの意味でスーパーデータ型を直接拡張し得る。ソースプログラミング言語は、そのようなトレイトベースの継承をサポートし得る。

動作７６０、７６２、７６４、７６６、及び７６８の目的のために、現在のノードＮを表したデータ型がソースコードで定義されているスーパーデータ型を直接拡張しない場合、そのデータ型は他の全てのデータ型の仮想のスーパーデータ型を表す仮想の「トップ」スーパーデータ型を直接拡張すると考えられる。したがって、少なくとも動作７６８は、トップスーパーデータ型を直接拡張すると考えられる現在のノードＮごとに行われ、動作７４６及び動作７６６は、それぞれ、トップスーパーデータ型に対して一度行われる。

動作７６０において、現在のダイレクトスーパー型Ｔがジェネリックタイプである場合、現在のダイレクトスーパーデータ型Ｔは、現在のノードＮによって表されたデータ型の型パラメーターを使用して変換される。

動作７６２において、現在のダイレクトサブデータ型Ｔのノードを表す要素が未構築ノードリスト上にあるかどうかを判定する。ない場合、動作７６４において、現在のダイレクトスーパーデータ型Ｔを表すノードに対して要素が作成され、動作７６６において、その要素が未構築ノードリストに追加される。いずれの場合も、動作７６８において、具象データ型Ｃのデータ型定義グラフにエッジが追加され、エッジは現在のダイレクトスーパーデータ型Ｔのノードから現在のノードＮまでである。エッジは、現在のダイレクトスーパーデータ型Ｔのインスタンスであるデータオブジェクトが、現在のノードＮによって表されたデータ型のインスタンスでもあり得るという点で「可能性のある」要件で限定される。

現在のノードＮに対して動作７５４、７５６、及び７５８が行われた後、プロセスは動作７５２に戻り、他のノードに対応する未構築ノードリスト上の任意の残りの要素を検討する。動作７５２で未構築ノードリストに要素が残っていない場合、図７Ｄのフローチャートによって示されるサブプロセスが終了する。

実施例では、Ｃｏｎｓ＜Ｆ＞データ型のスーパーデータ型であるＬｉｓｔ＜Ｆ＞のノードが、具象データ型Ｃｏｎｓ＜Ｆ＞のグラフに既にある。動作７６８において、「可能性のある」要件がある、Ｌｉｓｔ＜Ｆ＞のノードからＣｏｎｓ＜Ｆ＞データ型のノードまでグラフにエッジが追加される。また、Ｌｉｓｔ＜Ｆ＞データ型は、Ｅｍｐｔｙ＜Ｆ＞データ型のスーパーデータ型でもある。しかしながら、「可能性のある」要件があるエッジは、Ｌｉｓｔ＜Ｆ＞データ型を拡張するダイレクトサブデータ型を考慮するとき、図７Ｂの動作７３６において、Ｌｉｓｔ＜Ｆ＞のノードからＥｍｐｔｙ＜Ｆ＞データ型のノードに既に追加されている。したがって、動作７６８において、エッジは再度追加する必要はない。また、動作７６８において、「可能性のある」要件があるエッジは、全てのノードのトップスーパーデータ型からジェネリックデータ型Ｆを表すノードに追加される。同様に、動作７６８において、「可能性のある」要件があるエッジは、トップスーパーデータ型ノードから、Ｌｉｓｔ＜Ｆ＞ジェネリックデータ型を表すノードに追加される。

ここで図７Ｅを参照すると、具象データ型Ｃのデータ型チェックプロセスは、図７Ａ、図７Ｂ、図７Ｃ、及び図７Ｄのフローチャートによって示されるサブプロセスの実行が具象データ型Ｃに対して行われた後にそれらが存在するときの、具象データ型Ｃのデータ型定義グラフのノード及びエッジが継続する。

具象データ型Ｃのグラフを構築するこの時点において、グラフはデータ型ノードで構成されているが、リミットノードは構成されていない。グラフのデータ型ノードは、図７Ａ、図７Ｂ、図７Ｃ、及び図７Ｄに関して上記に説明したように、具象データ型Ｃのダイレクトサブデータ型、具象データＣのプロパティのデータ型、及びそれらのダイレクトサブデータ型のスーパーデータ型、それらのプロパティデータ型、ならびに具象データ型Ｃに基づいて作成される。

リミットノードは、非制限データ型ノードをグループ化するために、コンパイラによって具象データ型Ｃのデータ型定義グラフに追加され得る。このコンテキストにおける非制限データ型ノードは、（ａ）コンパイル時に全てのサブデータ型がコンパイラに知られているわけではないという意味での非クローズデータ型、または（ｂ）ジェネリックデータ型、のいずれか一方のデータ型を表すノードである。

動作７７０は、データ型ノードであるグラフの各ノードに対して行われ得る。動作７７２において、現在のデータ型ノードＮによって表されたデータ型が非制限であるかどうかを判定する。「ＮＯ」の場合、動作７７４、７７６、７７８、及び７８０は現在のデータ型ノードＮに対して行われない。「ＹＥＳ」の場合、動作７７４、７７６、７７８、及び７８０は現在のデータ型ノードＮに対して行われる。実施例では、Ｔｏｐ、Ｅｍｐｔｙ＜Ｆ＞、Ｌｉｓｔ＜Ｆ＞、Ｆ、及びＣｏｎｓ＜Ｆ＞データ型のノードは、グラフのデータ型ノードである。このうち、Ｅｍｐｔｙ＜Ｆ＞、Ｌｉｓｔ＜Ｆ＞、Ｆ、及びＣｏｎｓ＜Ｆ＞データ型のノードは、ジェネリックデータ型であるため制限がない。

動作７７４において、現在のデータ型ノードＮによって表されたデータ型の変換されたスーパーデータ型であるデータ型の「ＹＥＳ」セットが判定される。

動作７７６において、現在のデータ型ノードＮによって表されたデータ型に対する制限を参照しない場合がある「ＮＯ」セットが判定される。

動作７７８において、現在のＹＥＳセット及び現在のＮＯセットの組み合わせに関する具象データ型ＣのグラフにリミットノードＬＮが追加されていない場合、リミットノードＬＮが組み合わせ用に作成され、グラフに追加される。

動作７８０において、「可能性のある」要件があるエッジが、現在のデータ型を表すノードＮから現在のＹＥＳ及びＮＯの組み合わせに対するリミットノードＬＮまでグラフに追加される。

ここで図７Ｆを参照すると、具象データ型Ｃのデータ型チェックプロセスは、図７Ａ、図７Ｂ、図７Ｃ、図７Ｄ、及び図７Ｅのフローチャートによって示されるサブプロセスの実行が具象データ型Ｃに対して行われた後にそれらが存在するときの、具象データ型Ｃのデータ型定義グラフのノード及びエッジが継続する。

動作７８２は、グラフの各リミットノードに対して行われる。そして、グラフの各リミットノードに対して、動作７８４は、グラフのデータ型ノードのそれぞれに対して行われる。

動作７８６において、現在のノードＮのデータ型が、現在のリミットノードＬＮに対するＹＥＳセット（図７Ｅの動作７７４）の各データ型のサブデータ型であるかどうかを判定する。そうである場合、プロセスは動作７８８に進む。そうでない場合、図７Ｆのサブプロセスが終了する。

動作７８８において、現在のリミットノードＬＮのＮＯセット（図７Ｅの動作７７６）の任意のデータ型が、現在のノードＮのデータ型のサブデータ型であるかどうかを判定する。そうである場合、図７Ｆのサブプロセスは終了する。そうでない場合、動作７９０において、「＜」未満の要件がある現在のリミットノードＬＮから現在のデータ型ノードＮまでのエッジがグラフに作成される。

ここで図７Ｇを参照すると、具象データ型Ｃのデータ型チェックプロセスは、図７Ａ、図７Ｂ、図７Ｃ、図７Ｄ、図７Ｅ、及び図７Ｆのフローチャートによって示されるサブプロセスの実行が具象データ型Ｃに対して行われた後にそれらが存在するときの、具象データ型Ｃのデータ型定義グラフのノード及びエッジが継続する。

動作７９２において、セットＣＨＡＩＮはエッジの空のセットになるように初期化される。

動作７９４において、セットＶＩＳＩＴＥＤはノードの空のセットになるように初期化される。

動作７９６において、図７Ａ、図７Ｂ、図７Ｃ、図７Ｄ、図７Ｅ、及び図７Ｆのサブプロセスに従ってデータ型定義グラフが生成された具象データ型Ｃから開始するサブプロセスが呼び出される。サブプロセスはグラフの矛盾を探すが、図７Ｈを参照して下記により詳細に説明される。

動作７９８において、タイプチェックプロセス中に検出された任意の問題が報告される。例えば、ソースプログラミング言語で書かれたソースコードで識別された潜在的な参照サイクルごとに、コマンドラインインターフェースもしくはグラフィカルユーザーインターフェース等のコンピューターユーザーインターフェースへの出力、または潜在的な参照サイクルの人間可読な記述を提供するファイルもしくはデータベースへの出力を提供できる。出力は、例えば、「'Ｔｈｉｎｇ'型の値は、そのプロパティ'ｏｔｈｅｒＴｈｉｎｇ'を用いてそれ自体を参照し得る。'ａＴｈｉｎｇ．ｏｔｈｅｒＴｈｉｎｇ＝ａＴｈｉｎｇ；'は、参照サイクルを生じさせるであろう。」のようなテキストになり得る。出力は、潜在的な参照サイクルが検出された具象データ型Ｃのデータ型定義グラフのノードまたはエッジに関連付けられたメタデータから導出され得る。また、出力は、潜在的な参照サイクルを回避する等の問題を修正する方法も提案し得る。出力は統合開発環境（ＩＤＥ）プログラムに入力され、自動的に、または人間のプログラマーによって選択もしくは承認された提案に基づいてソースコードを変更し得る。

ここで図７Ｈを参照すると、図７Ｇのサブプロセスの動作７９６で呼び出された矛盾のサブプロセス探索のフローチャートである。サブプロセスは、現在のノードＮで呼び出される。また、サブプロセスは、再帰的であり得る、または非再帰的であるが同等の方法で実施され得る。矛盾のサブプロセス探索の最初の呼び出しでは、現在のノードＮは、データ型定義グラフが生成された具象データ型Ｃを表すグラフのノードである。

動作８００において、現在のノードＮがＶＩＳＩＴＥＤセットにあるかどうかを判定する。現在のノードＮがＶＩＳＩＴＥＤセットにある場合、矛盾のサブプロセス探索は動作８０２に進む。

動作８０２において、ＣＨＡＩＮセットが「＜」要件があるエッジを含むかどうかを判定する。そうである場合、サブプロセスは動作８０４に進む。

動作８０４において、具象データ型Ｃに関する潜在的な参照サイクル問題が報告される。例えば、ＣＨＡＩＮセットのエッジのセットを使用して問題を報告し、人間可読な問題の説明を導出し得る。

動作８０２において、「＜」要件があるＣＨＡＩＮセットにエッジがない場合、動作８０６において、現在のノードＮがＶＩＳＩＴＥＤセットから除去され、矛盾のサブプロセス探索の現在の呼び出しが戻る／終了する。

動作８００において、現在のノードＮがＶＩＳＩＴＥＤセットにない場合、動作８０８において、現在のノードＮがＶＩＳＩＴＥＤセットに追加される。

動作８１０は、現在のノードＮからのグラフの各エッジに対して行われる。

動作８１２において、ＣＨＡＩＮセットが空である場合、または現在のエッジＥが「＜」もしくは「＜＝」の要件がある場合、動作８１４において、現在のエッジＥがＣＨＡＩＮセットに追加され、矛盾のサブプロセスの探索が再帰的に呼び出され（８１６）、現在のエッジＥのグラフのターゲットノードを再帰呼び出しへの入力ノードとして提供し、再帰呼び出しが戻る／終了するとき、現在のエッジＥは、動作８０６に進む前にＣＨＡＩＮセットの最後から除去される（８１８）。動作８１２において、ＣＨＡＩＮが空でない場合、または現在のエッジＥに「＜」もしくは「＜＝」の要件がない場合、サブプロセスは動作８０６に進む。

利点
証明可能な非循環オブジェクトには多くの利点がある。１つは、ランタイムにオブジェクトをタイムリーに割当解除するには、参照カウントで十分である。別のものは、特定のランタイムメタ操作が簡素化され、信頼性が向上している。そのランタイムメタ操作は、
・ランタイムに２つのオブジェクトを比較して、それらが構造的に等しいかどうかを確認すること（すなわち、２つのオブジェクトが、対応するプロパティ自体が構造的に同等である同じタイプのオブジェクトであると判定すること）と、
・オブジェクトのパーツがメモリでどのように配置されているかに関係なく、ランタイムにオブジェクトのフィンガープリントを取得することと、
・別のコンピューティングプロセスまたはコンピューターに伝送するためにオブジェクトをシリアル化することと、
・オブジェクトを、問題をデバッグしている人間のプログラマーに示すことができる診断フォームに変換することと、を含む。

また、参照サイクルフリーのデータ型定義は、分散コンピューティングシステムにも利点がある。例えば、分散ガベージコレクションは、多くのプロパティ値が、そのプロパティ値を含むオブジェクトとは異なるシステムのコンピューティングノード上にあるとき、分散コンピューティングプロセス間で往復する実質的なプロセス間通信（例えば、データネットワーク）メッセージングを必要とし得る。一方、全てのデータ型が非循環である場合、分散ガベージコレクションを分散参照カウントに置換でき、参照カウントの更新をより少ない数の小さなメッセージにバッチ処理して、そのメッセージはシステムのノードで作動でき、ノードにおけるコンピューティングプロセスによって待機時間が少なくなる。

基本コンピューティングデバイス
本技術は、少なくとも１つのコンピューティングデバイスによって実装され得る。２つ以上のコンピューティングデバイスによる場合、本技術は、パケットデータネットワーク等のネットワークを使用して一緒に結合されたコンピューティングデバイスの組み合わせを使用して全体または部分的に実装され得る。本技術の実施態様で使用されるコンピューティングデバイスは、本技術の一部もしくは全てを行うようにハードワイヤードされ得る、または、本技術の一部もしくは全てを行うように永続的にプログラムされる、少なくとも１つの特定用途向け集積回路（ＡＳＩＣ）もしくはフィールドプログラマブルゲートアレイ（ＦＰＧＡ）等のデジタル電子デバイスを含み得る、または、ファームウェア、メモリ、他のストレージ、もしくはそれらの組み合わせにおけるプログラム命令に従って本技術の一部もしくは全てを行うようにプログラムされた少なくとも１つの汎用ハードウェアプロセッサを含み得る。本技術の実施態様に使用されるコンピューティングデバイスは、また、カスタムのハードワイヤードロジック、ＡＳＩＣ、またはＦＰＧＡとカスタムプログラミングを組み合わせて、本技術の一部または全ても達成し得る。本技術の実施態様で使用されるコンピューティングデバイスは、サーバーコンピューティングデバイス、ワークステーションコンピューティングデバイス、パーソナルコンピューティングデバイス、ポータブルコンピューティングデバイス、ハンドヘルドコンピューティングデバイス、モバイルコンピューティングデバイス、または本技術の一部もしくは全てを実装するためのハードワイヤードロジックもしくはプログラムロジックを組み込む任意の他のコンピューティングデバイスであり得る。

図８は、本技術の実施態様で使用され得る例示的な基本的なコンピューティングデバイスのブロック図である。図８の例では、コンピューティングデバイス８００、ならびにハードウェア、ソフトウェア、またはハードウェア及びソフトウェアの組み合わせにおける本技術の一部または全てを実施するための命令は、本開示でコンピューターアーキテクチャ及びコンピューティングデバイスの実施態様について通信することに関して関係する当業者によって一般的に使用するのと同じ詳細レベルで、例えばボックス及び円として概略的に表される。

コンピューティングデバイス８００は、電子信号経路を通じてコンピューティングデバイス８００のコンポーネント間で情報または命令を通信するためのバスまたは他の通信機構を含み得る入出力（Ｉ／Ｏ）サブシステム８０２を含む。Ｉ／Ｏサブシステム８０２は、Ｉ／Ｏコントローラ、メモリコントローラ、及び少なくとも１つのＩ／Ｏポートを含み得る。電子信号経路は、図面では、例えば、線、一方向の矢印、または双方向の矢印として概略的に表される。

少なくとも１つのハードウェアプロセッサ８０４は、情報及び命令を処理するためにＩ／Ｏサブシステム８０２に結合される。ハードウェアプロセッサ８０４は、例えば、汎用マイクロプロセッサもしくはマイクロコントローラ、または組み込みシステムもしくはグラフィックス処理ユニット（ＧＰＵ）もしくはデジタル信号プロセッサもしくはＡＲＭプロセッサ等の専用マイクロプロセッサを含み得る。プロセッサ８０４は、統合算術論理演算ユニット（ＡＬＵ）を備え得る、または別個のＡＬＵに結合され得る。

コンピューティングデバイス８００は、プロセッサ８０４によって実行されるデータ及び命令を電子的にデジタル的に記憶するためにＩ／Ｏサブシステム８０２に結合される、メインメモリ等の１つ以上のメモリ８０６のユニットを含む。メモリ８０６は、様々な形態のランダムアクセスメモリ（ＲＡＭ）または他の動的ストレージ等の揮発性メモリを含み得る。メモリ８０６は、また、プロセッサ８０４によって実行される命令の実行中、テンポラリ変数または他の中間情報を記憶するために使用され得る。そのような命令は、プロセッサ８０４にアクセス可能な非一時的ストレージ媒体に記憶されるとき、コンピューティングデバイス８００を、命令で指定された動作を行うようにカスタマイズされる専用マシンにレンダリングさせることができる。

コンピューティングデバイス８００は、さらに、プロセッサ８０４のための情報及び命令を記憶するために、Ｉ／Ｏサブシステム８０２に結合された読み取り専用メモリ（ＲＯＭ）８０８または他の静的ストレージ等の不揮発性メモリを含む。ＲＯＭ８０８は、消去可能ＰＲＯＭ（ＥＰＲＯＭ）または電気的消去可能ＰＲＯＭ（ＥＥＰＲＯＭ）等の様々な形式のプログラマブルＲＯＭ（ＰＲＯＭ）を含み得る。永続ストレージ８１０のユニットは、フラッシュメモリ、またはソリッドステートストレージ、磁気ディスク、またはＣＤ－ＲＯＭもしくはＤＶＤ－ＲＯＭ等の光ディスク等の様々な形式の不揮発性ＲＡＭ（ＮＶＲＡＭ）を含み得、情報及び命令を記憶するためのＩ／Ｏサブシステム８０２に結合され得る。ストレージ８１０は、プロセッサ８０４によって実行されるとき、コンピューター実施方法に本技術の一部または全てを実行させる命令及びデータを記憶するために使用され得る非一時的コンピューター可読媒体の例である。

メモリ８０６、ＲＯＭ８０８、またはストレージ８１０にある命令は、モジュール、方法、オブジェクト、関数、ルーチン、または呼び出しとして編成される１つ以上の命令セットを含み得る。命令は、１つ以上のコンピュータープログラム、オペレーティングシステムサービス、またはモバイルアプリを含むアプリケーションプログラムとして編成され得る。命令は、オペレーティングシステムまたはシステムソフトウェア；マルチメディア、プログラミング、または他の機能をサポートする１つ以上のライブラリ；ＴＣＰ／ＩＰ、ＨＴＴＰ、または他の通信プロトコルを実装するためのデータプロトコル命令またはスタック；ＨＴＭＬ、ＸＭＬ、ＪＰＥＧ、ＭＰＥＧ、またはＰＮＧを使用してコード化されたファイルを解釈及びレンダリングするためのファイル処理命令；グラフィカルユーザーインターフェース（ＧＵＩ）、コマンドラインインターフェース、またはテキストユーザーインターフェースのコマンドをレンダリングまたは解釈するためのユーザーインターフェース命令；オフィススイート、インターネットアクセスアプリケーション、設計及び製造アプリケーション、グラフィックスアプリケーション、オーディオアプリケーション、ソフトウェアエンジニアリングアプリケーション、教育アプリケーション、ゲームまたは他のアプリケーション等のアプリケーションソフトウェアを含み得る。その命令は、ウェブサーバー、ウェブアプリケーションサーバー、またはウェブクライアントを実施し得る。命令は、プレゼンテーション層、アプリケーション層、及び構造化照会言語（ＳＱＬ）またはＮｏＳＱＬを使用するリレーショナルデータベースシステム、オブジェクトストア、グラフデータベース、フラットファイルシステム、または他のデータストレージ等のデータストレージ層として編成され得る。

コンピューティングデバイス８００は、Ｉ／Ｏサブシステム８０２を介して、少なくとも１つの出力デバイス８１２に結合され得る。出力デバイス８１２は、デジタルコンピューターディスプレイであり得る。使用され得るディスプレイの例は、タッチスクリーンディスプレイまたは発光ダイオード（ＬＥＤ）ディスプレイまたは液晶ディスプレイ（ＬＣＤ）、または電子ペーパーディスプレイを含む。コンピューティングデバイス８００は、表示デバイスの代わりに、またはそれに加えて、他のタイプの出力デバイス８１２を含み得る。他の出力デバイス８１２の例は、プリンタ、チケットプリンタ、プロッタ、プロジェクタ、サウンドカードまたはビデオカード、スピーカー、ブザーまたは圧電デバイスまたは他の可聴デバイス、ランプまたはＬＥＤまたはＬＣＤインジケータ、触覚デバイス、アクチュエーターまたはサーボを含む。

入力デバイス８１４は、信号、データ、コマンド選択、またはジェスチャをプロセッサ８０４に通信するために、Ｉ／Ｏサブシステム８０２に結合され得る。入力デバイス８１４の例は、タッチスクリーン、マイクロフォン、静止画及びビデオデジタルカメラ、英数字及び他のキー、キーパッド、キーボード、グラフィックタブレット、イメージスキャナ、ジョイスティック、時計、スイッチ、ボタン、ダイヤル、スライド、あるいは力センサー、運動センサー、熱センサー、加速度計、ジャイロスコープ、慣性測定ユニット（ＩＭＵ）センサー等の様々なタイプのセンサー、または、携帯電話もしくはＷｉ－Ｆｉ（登録商標）等の無線、無線周波数（ＲＦ）トランシーバーもしくは赤外線（ＩＲ）トランシーバー及び全地球測位システム（ＧＰＳ）トランシーバー等の様々なタイプのトランシーバーを含む。

別のタイプの入力デバイスは制御デバイス８１６であり、入力機能の代わりに、または入力機能に加えて、カーソル制御、または表示画面上のグラフィカルインターフェースにおけるナビゲーション等の他の自動制御機能を行い得る。制御デバイス８１６は、方向情報及びコマンド選択をプロセッサ８０４に伝達し、ディスプレイ８１２上のカーソルの動きを制御するための、タッチパッド、マウス、トラックボール、またはカーソル方向キーであり得る。入力デバイスは、デバイスが平面内の位置を指定することを可能にする２つの軸、すなわち、第１の軸（例えばｘ）及び第２の軸（例えばｙ）の少なくとも２つの自由度を有し得る。別のタイプの入力デバイスは、ジョイスティック、ワンド、コンソール、ステアリングホイール、ペダル、ギアシフト機構、または他のタイプの制御デバイス等、有線、無線、または光学式の制御デバイスである。入力デバイス８１４は、ビデオカメラ及び深度センサー等の複数の異なる入力デバイスの組み合わせを含み得る。

コンピューティングデバイス８００は、出力デバイス８１２、入力デバイス８１４、及び制御デバイス８１６のうちの１つ以上が省略されたモノのインターネット（ＩｏＴ）デバイスまたは他のコンピューティング機器を備え得る。入力デバイス８１４は、１つ以上のカメラ、動作検出器、温度計、マイクロフォン、地震検出器、他のセンサーまたは検出器、測定デバイスまたはエンコーダーを備え得、出力デバイス８１２は、単線ＬＥＤディスプレイまたは単線ＬＣＤディスプレイ等の専用ディスプレイ、１つ以上のインジケータ、ディスプレイパネル、メーター、バルブ、ソレノイド、アクチュエーター、またはサーボを備え得る。

コンピューティングデバイス８００がモバイルまたはポータブルコンピューティングデバイスであるとき、入力デバイス８１４は、複数のＧＰＳ衛星を三角測量し、コンピューティングデバイス８００の地球物理的場所の緯度経度値等の地理位置情報または位置データを判定及び生成することが可能であるＧＰＳモジュールに結合された全地球測位システム（ＧＰＳ）受信機を備え得る。出力デバイス８１２は、位置報告パケット、通知、パルス信号もしくはハートビート信号、またはコンピューティングデバイス８００の位置を指定する他の反復データ伝送を、単独で、またはホスト８２４もしくはサーバー８３０に向けられた他のアプリケーション特有のデータと組み合わせて生成するためのハードウェア、ソフトウェア、ファームウェア、及びインターフェースを含み得る。

コンピューティングデバイス８００は、カスタマイズされたハードワイヤードロジック、少なくとも１つのＡＳＩＣもしくはＦＰＧＡ、ファームウェア、またはプログラム命令もしくはロジックを使用して、本技術の一部または全てを実装し得、プログラム命令またはロジックは、コンピューティングデバイス８００と組み合わせてロード及び使用されるとき、または実行されるとき、コンピューティングデバイス８００を専用マシンとして動作させるように、起動させるまたはプログラムする。

コンピューティングデバイス８００によって行われた技術は、メインメモリ８０６に含まれる少なくとも１つの命令の少なくとも１つのシーケンスを実行するプロセッサ８０４に応答して行われ得る。そのような命令は、ストレージ８１０等の別のストレージ媒体からメインメモリ８０６に読み取られ得る。メインメモリ８０６に含まれる一連の命令を行うと、プロセッサ８０４は本技術の一部または全てを行う。ハードワイヤード回路は、ソフトウェア命令の代わりに、またはソフトウェア命令と組み合わせて使用され得る。

本明細書で使用される「ストレージ媒体」という用語は、機械を特定の方式で動作させるデータまたは命令を記憶する任意の非一時的コンピューター可読媒体を指す。そのようなストレージ媒体は、不揮発性媒体または揮発性媒体を含み得る。不揮発性媒体は、例えば、ストレージ８１０等の光ディスクまたは磁気ディスクを含む。揮発性メディアは、メモリ８０６等のダイナミックメモリを含む。ストレージ媒体の一般的な形式は、例えば、ハードディスク、ソリッドステートドライブ、フラッシュドライブ、磁気データストレージ媒体、任意の光学的または物理的データストレージ媒体、メモリチップ等を含む。

ストレージメディアは伝送メディアとは異なるが、伝送メディアと組み合わせて使用され得る。伝送メディアは、記憶メディア間の情報の転送に関与する。例えば、伝送媒体は、同軸ケーブル、銅線、及び光ファイバーを含み、Ｉ／Ｏサブシステム８０２のバスを構成するワイヤを含む。伝送媒体は、また、電波及び赤外線データの通信中に生成されたもの等の音響波または光波の形態をとることもできる。

様々な形態の媒体は、実行のために少なくとも１つの命令の少なくとも１つのシーケンスをプロセッサ８０４に搬送することに関与し得る。例えば、命令は最初にリモートコンピューターの磁気ディスクまたはソリッドステートドライブに保存され得る。リモートコンピューターは、その命令を動的メモリにロードし、モデムを使用する光ファイバーまたは同軸ケーブルまたは電話回線等の通信リンクを通じて命令を送信できる。コンピューティングデバイス８００に対してローカルにあるモデムまたはルータは、通信リンク上でデータを受信し、そのデータをコンピューティングデバイス８００によって読み取られるように変換できる。例えば、無線周波数アンテナまたは赤外線検出器等の受信機は、無線または光信号で搬送されるデータを受信でき、適切な回路は、データをバス上に配置する等、データをＩ／Ｏサブシステム８０２に提供できる。Ｉ／Ｏサブシステム８０２はデータをメモリ８０６に搬送し、プロセッサ８０４はメモリ８０６から命令を取り出して実行する。メモリ８０６によって受信された命令は、オプションで、プロセッサ８０４による実行の前または後のいずれか一方で、ストレージ８１０に記憶され得る。

コンピューティングデバイス８００は、また、バス８０２に結合された通信インターフェース８１８も含む。通信インターフェース８１８は、ネットワーク８２２またはインターネット上のパブリックまたはプライベートクラウド等の少なくとも１つの通信ネットワークに直接的または間接的に接続されるネットワークリンク８２０に結合する双方向データ通信を提供する。例えば、通信インターフェース８１８は、イーサネット（登録商標）ネットワーキングインターフェース、総合サービスデジタルネットワーク（ＩＳＤＮ（登録商標））カード、ケーブルモデム、衛星モデム、または対応する通信回線のタイプ（例えばイーサネットケーブルもしくは任意の種類のメタルケーブル、または光ファイバー回線もしくは電話回線）へのデータ通信接続を提供するモデム等であり得る。ネットワーク８２２は、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、キャンパスネットワーク、インターネットワーク、またはそれらの任意の組み合わせを広く表す。通信インターフェース８１８は、互換性のあるＬＡＮへのデータ通信接続を提供するＬＡＮカード、またはセルラー無線電話無線ネットワーキング規格に従ってセルラーデータを送信もしくは受信するために有線で接続されるセルラー無線電話インターフェース、または衛星無線ネットワーキング規格に従ってデジタルデータを送信もしくは受信するために有線で接続される衛星無線インターフェースを備え得る。任意のそのような実施態様では、通信インターフェース６１８は、様々なタイプの情報を表すデジタルデータストリームを搬送する信号経路を通じて、電気信号、電磁信号、または光信号を送信及び受信する。

ネットワークリンク８２０は、通常、例えば衛星、セルラー、Ｗｉ－Ｆｉ（登録商標）、またはＢＬＵＥＴＯＯＴＨ（登録商標）技術を使用して、電気通信、電磁通信、または光データ通信を直接、または少なくとも１つのネットワークを経由して他のデータデバイスに提供する。例えば、ネットワークリンク８２０は、ネットワーク８２２を経由して、ホストコンピューター８２４への接続を提供し得る。

さらに、ネットワークリンク８２０は、ネットワーク８２２を経由した接続、またはインターネットサービスプロバイダ（ＩＳＰ）８２６が運用するインターネットワーキングデバイス及び／もしくはコンピューターを介した他のコンピューティングデバイスへの接続を提供し得る。ＩＳＰ８２６は、インターネット８２８として表された世界規模のパケットデータ通信ネットワークを経由してデータ通信サービスを提供する。サーバーコンピューター８３０はインターネット８２８に接続され得る。サーバー８３０は、ハイパーバイザーの有無にかかわらず任意のコンピューター、データセンター、仮想マシンもしくは仮想コンピューティングインスタンス、またはＤＯＣＫＥＲもしくはＫＵＢＥＲＮＥＴＥＳ等のコンテナ化されたプログラムシステムを実行するコンピューターを広く表す。サーバー８３０はデジタル電子サービスを表し得、これは、２つ以上のコンピューターまたはインスタンスを使用して実装され、ウェブサービスリクエスト、ＨＴＴＰペイロードのパラメーターを伴うユニフォームリソースロケータ（ＵＲＬ）文字列、ＡＰＩコール、アプリサービスコール、または他のサービスコールを伝送することによってアクセス及び使用される。

コンピューティングデバイス８００及びサーバー８３０は、他のコンピューター、処理クラスター、サーバーファーム、あるいはタスクを協働して行う、またはアプリケーションもしくはサービスを協働して実行するコンピューターの他の組織を含む分散コンピューティングシステムの要素を形成し得る。サーバー８３０は、モジュール、方法、オブジェクト、関数、ルーチン、または呼び出しとして編成される１つ以上の命令のセットを含み得る。命令は、１つ以上のコンピュータープログラム、オペレーティングシステムサービス、またはモバイルアプリを含むアプリケーションプログラムとして編成され得る。命令は、オペレーティングシステム及び／またはシステムソフトウェア；マルチメディア、プログラミング、または他の機能をサポートする１つ以上のライブラリ；ＴＣＰ／ＩＰ、ＨＴＴＰ、または他の通信プロトコルを実装するためのデータプロトコル命令またはスタック；ＨＴＭＬ、ＸＭＬ、ＪＰＥＧ、ＭＰＥＧ、またはＰＮＧを使用してコード化されたファイルを解釈またはレンダリングするためのファイル形式処理命令；グラフィカルユーザーインターフェース（ＧＵＩ）、コマンドラインインターフェース、またはテキストユーザーインターフェースのコマンドをレンダリングまたは解釈するためのユーザーインターフェース命令；オフィススイート、インターネットアクセスアプリケーション、設計及び製造アプリケーション、グラフィックスアプリケーション、オーディオアプリケーション、ソフトウェアエンジニアリングアプリケーション、教育アプリケーション、ゲームまたは他のアプリケーション等のアプリケーションソフトウェアを含み得る。サーバー８３０は、プレゼンテーション層、アプリケーション層、及び構造化照会言語（ＳＱＬ）またはＮｏＳＱＬを使用するリレーショナルデータベースシステム、オブジェクトストア、グラフデータベース、フラットファイルシステム、または他のデータストレージ等のデータストレージ層をホストするウェブアプリケーションサーバーを含み得る。

コンピューティングデバイス８００は、ネットワーク、ネットワークリンク８２０、及び通信インターフェース８１８を経由して、メッセージを送信し、プログラムコードを含むデータ及び命令を受信できる。インターネットの例では、サーバー８３０は、インターネット８２８、ＩＳＰ８２６、ローカルネットワーク８２２、及び通信インターフェース８１８を経由して、アプリケーションプログラムに対して要求されたコードを伝送し得る。受信されたコードは、受信されたときにプロセッサ８０４によって実行され得る、または後で実行するためにストレージ８１０または他の不揮発性ストレージに記憶され得る。

基本的なソフトウェアシステム
図９は、図８のコンピューティングデバイス８００の動作を制御するために採用され得る例示的な基本ソフトウェアシステム９００のブロック図である。ソフトウェアシステム９００、ならびにその接続、関係、及び機能を含むそのコンポーネントは、単なる例であることを意図しており、本技術の実装を限定することを意図するものではない。本技術を実装するのに適した他のソフトウェアシステムは、異なる接続、関係、機能を備えたコンポーネントを含む、異なるコンポーネントを有し得る。

ソフトウェアシステム９００は、コンピューターシステム８００の動作を指示するために提供される。システムメモリ（ＲＡＭ）８０６及び固定ストレージ（例えば、ハードディスクまたはフラッシュメモリ）８１０に記憶され得るソフトウェアシステム９００は、カーネルまたはオペレーティングシステム（ＯＳ）９１０を含む。

ＯＳ９１０は、９０２－１、９０２－２、９０２－３...９０２－Ｎとして表されたプロセスの実行の管理、メモリ割り当て、ファイル入出力（Ｉ／Ｏ）、デバイスＩ／Ｏを含むコンピューター操作の低レベルの態様を管理する。１つ以上のアプリケーションプログラムは、システム９００による１つ以上のプロセスとして実行するために「ロード」され得る（例えば、固定ストレージ８１０からメモリ８０６に転送され得る）。また、コンピューティングデバイス８００での使用を意図としたアプリケーションまたは他のソフトウェアは、例えば、インターネットの場所（例えば、ウェブサーバー、アプリストア、または他のオンラインサービス）からダウンロード及びインストールするために、ダウンロード可能なコンピューター実行可能命令のセットとしても記憶され得る。

アプリケーションプログラム命令の実行は、実行中であり、プログラムコード及びその現在のアクティビティから成るコンピュータープログラムのインスタンスの形式でプロセス（例えば、９０２－２）を実施し得る。オペレーティングシステム（ＯＳ）によって、プロセス（例えば、９０２－３）は、命令を同時に実行する複数の実行スレッドで構成され得る。このコンテキストでは、コンピュータープログラムは命令のパッシブなコレクションである一方、プロセス（例えば、９０２－１）はそれらの命令の実際の実行であり得る。いくつかのプロセス（例えば、９０２－１及び９０２－２）は同じプログラムに関連付けられ得る。例えば、同じプログラムのいくつかのインスタンスを開くということは、多くの場合、２つ以上のプロセスが実行されていることを意味する、または、最初は、単一のプロセスとして起動するプログラムは、その後、追加のプロセスをスポーン（例えば、フォーク）し得る。

ＯＳ９１０は、プロセス９０２－１、９０２－２、９０２－３...９０２－Ｎがプロセッサ８０４を共有することを可能にするようにマルチタスクを実施し得る。プロセッサ８０４のそれぞれまたはプロセッサのコアは一度に単一タスクを実行するが、コンピューティングデバイス８００は、各プロセッサが、各タスクが終了することを待機する必要がなく、実行中であるタスク間を切り替えることを可能にするマルチタスクを実施するようにプログラムされ得る。タスクが入出力操作を行うとき、タスクが切り替え可能であることを示すとき、またはハードウェア割り込み時に、切り替えは行われ得る。タイムシェアリングは、コンテキストの切り替えを急速に行って、複数のプロセスが同時に起こるかのように見せることを提供することによって、対話型ユーザーアプリケーションの高速応答が可能になるように実施され得る。セキュリティ及び信頼性のために、ＯＳ９１０は独立したプロセス間の直接通信を防止し得、厳密に仲介及び制御されたプロセス間通信機能を提供する。

いくつかの例では、プロセス９０２－１、９０２－２、９０２－３...９０２－Ｎ、及びそれらのプロセスが実施するアプリケーションプログラムは、アプリケーションコンテナ９４０内で実行され得る。アプリケーションコンテナは、概して、ＯＳ９１０の動作モードであり、ＯＳ９１０では、複数の分離されたユーザー空間インスタンスの存在をＯＳ９１０で実行することを可能にする。アプリケーションコンテナ９４０は、そのようなインスタンスの一例である。インスタンス自体は、代替として、ゾーン、仮想プライベートサーバー、パーティション、仮想環境、仮想カーネル、またはジェイルと呼ばれることもある。アプリケーションコンテナは、ＣＰＵ時間及びストレージメディア空間等の有限のハードウェアコンピューティングリソースをインスタンス間で割り当てることができるメカニズムを提供する。

ソフトウェアシステム９００は、グラフィカル（例えば、「ポイントアンドクリック」または「タッチジェスチャ」）方式でユーザーコマンド及びデータを受信するためのグラフィカルユーザーインターフェース（ＧＵＩ）９１５を含む。次に、これらの入力は、オペレーティングシステム９１０またはプロセス９０２－１、９０２－２、９０２－３...９０２－Ｎからの命令に従ってシステム９００によって処理され得る。次に、ＧＵＩ９１５は、ＯＳ９１０及びプロセス９０２－１、９０２－２、９０２－３...９０２－Ｎ、９０２から操作の結果を表示する役割も果たし、その後、ユーザーは追加の入力を供給し得る、またはセッションを終了し得る（例えば、ログオフする）。

ＯＳ９１０は、コンピューティングデバイス８００のベアハードウェア９２０（例えば、プロセッサ８０４）で直接実行できる。代替として、ハイパーバイザーまたは仮想マシンモニター（ＶＭＭ）９３０は、ベアハードウェア９２０とＯＳ９１０との間に挿入され得る。この構成では、ＶＭＭ９３０は、ＯＳ９１０とコンピューティングデバイス８００のベアハードウェア９２０との間のソフトウェア「クッション」または仮想化層として機能する。

ＶＭＭ９３０は、１つ以上の仮想マシンインスタンス（「ゲストマシン」）をインスタンス化して実行する。各ゲストマシンは、ＯＳ９１０等の「ゲスト」オペレーティングシステムと、ゲストオペレーティングシステムで実行するように設計されたアプリケーション９０２等の１つ以上のアプリケーションとを備える。ＶＭＭ９３０は、ゲストオペレーティングシステムを仮想オペレーティングプラットフォームに提示し、ゲストオペレーティングシステムの実行を管理する。

いくつかの例では、ＶＭＭ９３０は、ゲストオペレーティングシステムがコンピューティングデバイス８００のベアハードウェア９２０で直接起動しているかのように起動することが可能になり得る。これらの例では、ベアハードウェア９２０で直接実行するように構成された同じバージョンのゲストオペレーティングシステムは、また、変更または再構成なしで、ＶＭＭ９３０で実行され得る。言い換えれば、ＶＭＭ９３０は、いくつかの例では、完全なハードウェア及びＣＰＵの仮想化をゲストオペレーティングシステムに提供し得る。

他の例では、ゲストオペレーティングシステムは、ＶＭＭ９３０で実行するように特別に設計または構成され得る。これらの例では、ゲストオペレーティングシステムは、仮想マシンモニターで実行されていることを「認識」する。言い換えれば、ＶＭＭ９３０は、いくつかの例では、パラ仮想化をゲストオペレーティングシステムに提供し得る。

クラウドコンピューティング
本技術は、「クラウドコンピューティング」環境で実装され得る。「クラウドコンピューティング」という用語は、概して、本明細書では、コンピューターネットワーク、サーバー、ソフトウェアアプリケーション、及びサービス等のコンピューティングリソースの共有プールへのオンデマンドアクセスを可能にし、最小の管理労力または最小のサービスプロバイダーとのインタラクションで、リソースの急速なプロビジョニング及びリリースを可能にする、コンピューティングモデルを表すために使用される。

クラウドコンピューティング環境（クラウド環境またはクラウドと呼ばれることもある）は、異なる要件に最適になるように様々な異なる方法で実装できる。例えば、パブリッククラウド環境では、下層のコンピューティングインフラストラクチャは、そのクラウドサービスを他の組織または一般の人々が利用可能になる組織によって所有される。対照的に、プライベートクラウド環境は、概して、単一の組織による、または単一の組織内での使用だけを意図としている。コミュニティクラウドは、コミュニティ内のいくつかの組織によって共有されることを意図とする一方、ハイブリッドクラウドは、データ及びアプリケーションのポータビリティによって一緒にバインドされた２つ以上のタイプのクラウド（例えば、プライベート、コミュニティ、パブリック）を含む。

概して、クラウドコンピューティングモデルは、以前は組織独自の情報技術部門によって提供されていた場合があるその責任の一部を、代わりに、コンシューマー（クラウドのパブリック／プライベートの性質に応じて、組織内または組織外のいずれか一方にいるコンシューマー）による使用のために、クラウド環境内のサービス層として提供することを可能にする。特定の実施態様に応じて、各クラウドサービス層によって、または各クラウドサービス層内で提供されたコンポーネントまたは機能の正確な定義は異なる可能性があるが、一般的な例は、コンシューマーがクラウドインフラストラクチャ上で実行されているソフトウェアアプリケーションを使用するサービス型ソフトウェア（ＳａａＳ）を含む一方、ＳａａＳプロバイダーは下層のクラウドインフラストラクチャ及びアプリケーションを管理または制御する。サービス型プラットフォーム（ＰａａＳ）では、コンシューマーが、ＰａａＳプロバイダーによってサポートされたソフトウェアプログラミング言語及び開発ツールを使用して、その独自のアプリケーションを開発、展開し、そうでなければ制御することができる一方、ＰａａＳプロバイダーはクラウド環境の他の態様（例えば、ランタイム実行環境の下の全てのもの）を管理または制御する。サービス型インフラストラクチャ（ＩａａＳ）では、コンシューマーが、任意のソフトウェアアプリケーション、及び／または準備処理、ストレージ、ネットワーク、及び他の基本コンピューティングリソースを展開及び起動できる一方、ＩａａＳプロバイダーは、下層の物理クラウドインフラストラクチャ（例えば、オペレーティングシステム層の下の全てのもの）を管理または制御する。サービス型データベース（ＤＢａａＳ）では、コンシューマーはクラウドインフラストラクチャ上で実行されているデータベースサーバーまたはデータベース管理システムを使用する一方、ＤｂａａＳプロバイダーは、１つ以上のデータベースサーバーを含む、下層のクラウドインフラストラクチャ、アプリケーション、サーバーを管理または制御する。

本開示の他の態様
文脈上明確に別段の指示がない限り、「または（ｏｒ）」という用語は、（排他的な意味ではなく）包括的な意味で、前述の明細書及び添付の特許請求の範囲で使用され、したがって、例えば、要素のリストを接続するために使用されるとき、「または（ｏｒ）」という用語は、そのリストにある要素の１つ、一部、または全部を意味する。

文脈上明確に別段の指示がない限り、「備える（ｃｏｍｐｒｉｓｉｎｇ）」、「含む（ｉｎｃｌｕｄｉｎｇ）」、「有する（ｈａｖｉｎｇ）」、「に基づく（ｂａｓｅｄ ｏｎ）」、「含む（ｅｎｃｏｍｐａｓｓｉｎｇ）」等の用語は、前述の明細書及び添付の特許請求の範囲で無制限に使用され、追加の要素、機能、行為、または動作を除外するものではない。

文脈上明確に別段の指示がない限り、語句「Ｘ、Ｙ、及びＺのうちの少なくとも１つ」等の接続的言語は、項目、用語等がＸ、Ｙ、もしくはＺ、またはそれらの組み合わせであり得ると伝えることを理解されたい。したがって、そのような接続的言語は、初期設定で、Ｘの少なくとも１つ、Ｙの少なくとも１つ、及びＺの少なくとも１つがそれぞれ存在するという含意が必要であることを意図していない。

文脈上明確に別段の指示がない限り、前述の発明を実施するための形態及び添付の特許請求の範囲で使用されるように、単数形「ａ」、「ａｎ」、及び「ｔｈｅ」は、同様に複数形も含むことが意図される。

文脈上明確に別段の指示がない限り、前述の詳細な説明及び添付の特許請求の範囲において、「第１の」、第２の」等の用語は、いくつかの例では、本明細書では様々な要素を説明するために使用されているが、これらの要素は、これらの用語によって限定すべきではない。これらの用語は、一方の要素を別の要素と区別するためだけに使用される。例えば、第１のコンピューティングデバイスを第２のコンピューティングデバイスと呼ぶことができ、同様に、第２のコンピューティングデバイスを第１のコンピューティングデバイスと呼ぶことができる。第１のコンピューティングデバイス及び第２のコンピューティングデバイスは両方ともコンピューティングデバイスであるが、それらは同じコンピューティングデバイスではない。

前述の明細書では、実施態様ごとに異なり得る多くの特定の詳細を参照して技術を説明している。したがって、明細書及び図面は、限定的な意味ではなく例示的な意味で考えるべきである。

Claims (17)

1. 少なくとも１つのコンピューティングデバイスによって実施される方法であって、
   ライブラリのプログラミング言語ソースコードの具象データ型の定義を検出すること、
   前記具象データ型の定義がランタイムの潜在的な参照サイクルを可能にしているかどうかを判定すること、及び
   前記具象データ型の定義がランタイムに参照サイクルを可能にしていると判定することに基づいて、前記プログラミング言語ソースコードのコンパイルを停止すること、または、前記検出された潜在的な参照サイクルに関するアラートをユーザーインターフェース、ファイル、データベース、もしくは統合開発環境に出力すること、
   を含む、方法。
2. 前記具象データ型の定義がランタイムに潜在的な参照サイクルを可能にするかどうかを判定することは、
   前記プログラミング言語ソースコードの前記具象データ型の定義のプロパティの定義が読み取り専用であるかどうかを判定すること、に基づいている、請求項１に記載の方法。
3. 前記プログラミング言語ソースコードの前記具象データ型の定義の前記プロパティの定義が読み取り専用であるかどうかを判定することは、
   前記プロパティの定義が読み取り専用であることを示す前記プロパティの定義のキーワードを識別すること、または、
   前記プログラミング言語ソースコードの分析に基づいて、前記プロパティに初期値がそのように割り当てられた後に、前記プロパティの値を設定できた前記プログラミング言語ソースコードがいずれも設定を行わないと判定することに基づいて、前記プロパティの定義が読み取り専用であると推論すること、
   に基づいている、請求項２に記載の方法。
4. 前記具象データ型の定義がランタイムに潜在的な参照サイクルを可能にするかどうかを判定することは、
   前記プログラミング言語ソースコードの前記具象データ型の定義のプロパティの定義が早期であるかどうかを判定すること、に基づいている、請求項１～３のいずれか一項に記載の方法。
5. 前記プログラミング言語ソースコードの前記具象データ型の前記プロパティの定義が早期であるかどうかを判定することは、
   前記プロパティの定義が早期であることを示す前記プロパティの定義のキーワードを識別すること、または、
   前記プログラミング言語ソースコードの分析に基づいて、単にデータオブジェクトが前記データオブジェクトのプロパティを初期化するために使用される代わりに、前記プロパティを含むデータオブジェクトへの任意の参照が値として使用される前に、前記プロパティに初期値が割り当てられていると判定することに基づいて、前記具象データ型の定義が早期に行われていると推論すること、
   を含む、請求項４に記載の方法。
6. 前記具象データ型の定義がランタイムに潜在的な参照サイクルを可能にするかどうかを判定することは、
   前記プログラミング言語ソースコードの前記具象データ型の定義がクローズされているかどうかを判定すること、に基づいている、請求項１～３のいずれか一項に記載の方法。
7. 前記プログラミング言語ソースコードの前記具象データ型の定義がクローズしているかどうかを判定することは、
   前記具象データ型の定義がクローズされていることを示す、前記具象データ型の定義でキーワードを識別すること、または、
   前記プログラミング言語ソースコードの静的分析に基づいて、前記具象データ型の定義のサブデータ型の定義が存在しないと判定することに基づいて、前記具象データ型の定義がクローズされていると推論すること、
   に基づいている、請求項６に記載の方法。
8. 前記具象データ型の定義が具体的であることを示す前記具象データ型の定義のキーワードを識別することに基づいて、前記具象データ型の定義が具体的であることを判定することをさらに含む、請求項１～３のいずれか一項に記載の方法。
9. 前記プログラミング言語ソースコードのオブジェクトとして前記具象データ型のインスタンス化を識別することに基づいて、前記具象データ型の定義が具体的であると推論することに基づいて、前記具象データ型の定義が具体的であると判定することをさらに含む、請求項１～３のいずれか一項に記載の方法。
10. 前記具象データ型の定義がランタイムに潜在的な参照サイクルを可能にするかどうかを判定することは、
    前記具象データ型の定義のためのデータ型定義グラフを構築することに基づいており、前記データ型定義グラフは、データ型を表すノードと、ジェネリック型パラメーターに関する最悪の場合の仮定に対応する１つ以上のノードとを含む、請求項１～３のいずれか一項に記載の方法。
11. 前記最悪の場合の仮定は、ジェネリック型パラメーターまたはデータ型定義の境界を考慮する、請求項１０に記載の方法。
12. 前記データ型定義グラフは、一方のデータ型が別のデータ型を参照する方法に対応する１つ以上のエッジを含む、請求項１０に記載の方法。
13. 前記具象データ型の定義がランタイムに潜在的な参照サイクルを可能にするかどうかを判定することは、
    特定の種類のエッジを伴う前記データ型定義グラフのサイクルを検出することに基づいている、請求項１０に記載の方法。
14. 前記アラートは、前記潜在的な参照サイクルの人間可読な記述を含み、
    前記人間可読な記述は、（ａ）前記データ型定義グラフのノードもしくはエッジに関連付けられたメタデータから得られる、または（ｂ）前記潜在的な参照サイクルを回避する方法についての提案を含む、請求項１０に記載の方法。
15. 前記アラートが出力される統合開発環境は、前記アラートを使用して、ユーザーによって選択された提案に基づいて前記プログラミング言語ソースコードを自動的に変更する、請求項１４に記載の方法。
16. （ａ）前記具象データ型の定義に関連付けられたヒント、注釈、もしくはメタデータ、または（ｂ）前記具象データ型の定義が前記プログラミング言語ソースコードの特定の指定された部分内で定義されていると判定することに基づいて、前記潜在的な参照サイクルが安全であるとみなされていることを判定することをさらに含む、請求項１～３のいずれか一項に記載の方法。
17. 分散オブジェクトシステムでは、参照カウントを使用して、前記具象データ型のインスタンスであるオブジェクトを割当解除することをさらに含み、
    前記割当解除されたオブジェクトが複数のコンピューティングプロセスにわたって分散される、請求項１～３のいずれか一項に記載の方法。

Images