"分散型コンピューティングシステムであって、ハードウェア、ソフトウェア、または両方を使用して、1つ以上の動作の実行を促進するように構成される、1つ以上のリソースと、少なくとも、前記リソースのサブセットによって動作されるように構成される、2つ以上の処理デバイスと、を備え、前記1つ以上のリソースは、1つ以上のコードレットの制御下、動作を実行するように構成される、システム。前記リソースのうちの少なくとも1つは、少なくとも1つの処理デバイス上における1つ以上のコードレットの実行をスケジューリングするように構成される、スケジューラを備える、請求項1に記載のシステム。少なくとも1つのスケジューラは、特定のロケールと関連付けられた1つ以上のリソースと関連付けられる、請求項2に記載のシステム。少なくとも1つのスケジューラは、ロケールの階層内のロケールと関連付けられていない、請求項3に記載のシステム。前記システム内のロケールは、階層に編成され、前記階層の所与のレベルにおいてロケールと関連付けられたスケジューラは、前記階層のより高いレベルにおける親スケジューラからワークを要求するように構成される、請求項3に記載のシステム。前記システム内のロケールは、階層に編成され、前記階層の所与のレベルにおいてロケールと関連付けられたスケジューラは、前記階層内の異なる位置における他のスケジューラからワークを要求するように構成される、請求項3に記載のシステム。前記システム内のロケールは、階層に編成され、前記階層の所与のレベルにおいてロケールと関連付けられたスケジューラは、同一の前記階層の所与のレベルにおける1つ以上の兄弟スケジューラと相互作用し、ワークを要求する、ワークを提供する、または両方を行うように構成される、請求項3に記載のシステム。提供は、順番を譲る、またはそれらが後に再開され得るように、その状態をメモリに書き込み、その実行を終了させることのいずれかによって、前記1つ以上のコードレットが、それ自体の実行を保留するように行われる、請求項1から7の何れか1項に記載のシステム。前記1つ以上のコードレットのうちの少なくとも1つは、さらなるコードレットを参照する、請求項1から8の何れか1項に記載のシステム。前記1つ以上のコードレットのうちの少なくとも1つは、異種型の処理デバイス上で起動可能である、請求項1から9の何れか1項に記載のシステム。前記1つ以上のコードレットのうちの少なくとも1つは、前記1つ以上のコードレットのうちの少なくとも1つを前記異種型の処理デバイス上で起動可能にするために、複数の形態の起動フォークおよび複数の形態のキャンセルフォークの少なくとも一方を含む、請求項10に記載のシステム。前記システム内のオブジェクトをカテゴリ化するように構成される、階層型システムをさらに備える、請求項1から11の何れか1項に記載のシステム。1つ以上のノードレットが、提供され、前記ノードレットのうちの少なくとも1つは、複数のリソースへのアクセスを提供するように構成される、請求項1から12の何れか1項に記載のシステム。前記システムは、1つ以上のプログラムレットの使用をサポートするように構成される、請求項1から13の何れか1項に記載のシステム。1つ以上の処理デバイスに、ハードウェア、ソフトウェア、または両方を使用して、1つ以上の動作の実行を促進するように構成される、1つ以上のリソースを動作させる段階と、前記1つ以上のリソースを、1つ以上のコードレットの制御下、動作を実行するように構成する段階と、を実行させるためのプログラムであって、前記ハードウェアは、2つ以上の処理デバイスを含み、前記ハードウェア、ソフトウェア、または両方は、分散型コンピューティングシステムの一部であるプログラム。さらに、前記リソースのうちの少なくとも1つを、スケジューラとして動作し、少なくとも1つの処理デバイス上での1つ以上のコードレットの実行をスケジューリングするように構成する段階を実行させる、請求項15に記載のプログラム。少なくとも1つのスケジューラは、特定のロケールと関連付けられた1つ以上のリソースと関連付けられる、請求項16に記載のプログラム。少なくとも1つのスケジューラは、ロケールの階層内のロケールと関連付けられていない、請求項17に記載のプログラム。前記分散型コンピューティングシステム内のロケールは、階層に編成され、前記階層の所与のレベルにおいてロケールと関連付けられたスケジューラは、前記階層のより高いレベルにおける親スケジューラからワークを要求するように構成される、請求項17に記載のプログラム。前記分散型コンピューティングシステム内のロケールは、階層に編成され、前記階層の所与のレベルにおいてロケールと関連付けられたスケジューラは、前記階層内の異なる位置における他のスケジューラからワークを要求するように構成される、請求項17に記載のプログラム。前記分散型コンピューティングシステム内のロケールは、階層に編成され、前記階層の所与のレベルにおいてロケールと関連付けられたスケジューラは、同一の前記階層の所与のレベルにおける1つ以上の兄弟スケジューラと相互作用し、ワークを要求する、ワークを提供する、または両方を行うように構成される、請求項17に記載のプログラム。前記1つ以上のコードレットが、順番を譲る、またはそれらが後に再開され得るように、その状態をメモリに書き込み、その実行を終了させることのいずれかによって、それ自体の実行を保留することを可能にする段階を実行させる、請求項15から21の何れか1項に記載のプログラム。前記1つ以上のコードレットのうちの少なくとも1つは、さらなるコードレットを参照する、請求項15から22の何れか1項に記載のプログラム。さらに、前記システム内のオブジェクトをカテゴリ化するように構成される、階層型システムをサポートする段階を実行させる、請求項15から23の何れか1項に記載のプログラム。さらに、複数のリソースへのアクセスを提供するように構成される、1つ以上のノードレットの使用をサポートする段階を実行させる、請求項15から24の何れか1項に記載のプログラム。さらに、1つ以上のプログラムレットの使用をサポートする段階を実行させる、請求項15から25の何れか1項に記載のプログラム。分散型コンピューティングの方法であって、ハードウェア、ソフトウェア、または両方を使用して、1つ以上の動作の実行を促進するように構成される、1つ以上のリソースを動作させることと、前記1つ以上のリソースを、1つ以上のコードレットの制御下、動作を実行するように構成することと、を備え、前記ハードウェアは、2つ以上の処理デバイスを含み、前記ハードウェア、ソフトウェア、または両方は、分散型コンピューティングシステムの一部である、方法。前記リソースのうちの少なくとも1つは、スケジューラを備え、前記方法はさらに、前記スケジューラによって、少なくとも1つの処理デバイス上での1つ以上のコードレットの実行をスケジューリングすることを備える、請求項27に記載の方法。少なくとも1つのスケジューラは、特定のロケールと関連付けられた1つ以上のリソースと関連付けられる、請求項28に記載の方法。少なくとも1つのスケジューラは、ロケールの階層内のロケールと関連付けられていない、請求項29に記載の方法。前記システム内のロケールは、階層に編成され、前記方法はさらに、前記階層の所与のレベルにおけるロケールと関連付けられたスケジューラによって、前記階層のより高いレベルにおける親スケジューラからワークを要求することを備える、請求項29に記載の方法。前記システム内のロケールは、階層に編成され、前記方法はさらに、前記階層の所与のレベルにおけるロケールと関連付けられたスケジューラによって、前記階層内の異なる位置における他のスケジューラからワークを要求することを備える、請求項29に記載の方法。前記システム内のロケールは、階層に編成され、前記方法はさらに、前記階層の所与のレベルにおけるロケールと関連付けられたスケジューラによって、同一の前記階層の所与のレベルにおける1つ以上の兄弟スケジューラと相互作用し、ワークを要求する、ワークを提供する、または両方を行うことを備える、請求項29に記載の方法。前記1つ以上のコードレットが、順番を譲る、またはそれらが後に再開され得るように、その状態をメモリに書き込み、その実行を終了させることのいずれかによって、それ自体の実行を保留することを可能にすることをさらに備える、請求項27から33の何れか1項に記載の方法。前記1つ以上のコードレットのうちの少なくとも1つは、さらなるコードレットを参照する、請求項27から34の何れか1項に記載の方法。前記1つ以上のコードレットのうちの少なくとも1つは、異種型の処理デバイス上で起動可能にされる、請求項27から35の何れか1項に記載の方法。前記1つ以上のコードレットのうちの少なくとも1つは、前記1つ以上のコードレットのうちの少なくとも1つを前記異種型の処理デバイス上で起動可能にするために、複数の形態の起動フォークおよび複数の形態のキャンセルフォークの少なくとも一方を含む、請求項36に記載の方法。前記システム内のオブジェクトをカテゴリ化するように構成される、階層型システムを実装することをさらに備える、請求項27から37の何れか1項に記載の方法。1つ以上のノードレットを提供することをさらに備え、前記ノードレットのうちの少なくとも1つは、複数のリソースへのアクセスを提供するように構成される、請求項27から38の何れか1項に記載の方法。1つ以上のプログラムレットの使用をサポートすることをさらに備える、請求項27から39の何れか1項に記載の方法。コンピューティングシステムであって、少なくとも1つの処理デバイスと、前記少なくとも1つの処理デバイスに連結される、少なくとも1つのメモリユニットと、を備え、前記少なくとも1つのメモリユニットは、複数のインヘリタンス、複数のインターフェース、および統合型をサポートするように構成される、階層型システムを実装するために、前記少なくとも1つの処理デバイスによって実行可能である命令を含有し、前記階層型システムはさらに、異種アーキテクチャ、プラットフォーム、バイナリインターフェース、またはこれらの何れかの組み合わせを有する、システム間のデータの転送をサポートする。少なくとも1つの処理デバイスに、複数のインヘリタンス、複数のインターフェース、および統合型をサポートするように構成される、階層型システムを実装させるためのプログラムであって、に、前記階層型システムはさらに、異種アーキテクチャ、プラットフォーム、バイナリインターフェース、またはこれらの何れかの組み合わせを有する、システム間のデータの転送をサポートする、プログラム。階層型システムを実装する方法であって、階層構造に従って編成される型の多様性を提供することと、前記型が、複数のインヘリタンス、複数のインターフェース、および統合型をサポートすることを可能にすることと、を備え、前記階層型システムは、異種アーキテクチャ、プラットフォーム、バイナリインターフェース、またはこれらの何れかの組み合わせを有するシステム間のデータの転送をサポートする、方法。分散型コンピューティングシステムでは、単一プログラムが、複数の処理デバイス上で実行されてもよい。図1は、そのようなシステムが、どのように実装され得るかの実施例を示す。ユーザデバイス11は、プログラムが実行されるように準備するために使用されてもよいユーザが、プログラムを書き込むことを可能にすることを含む。ユーザデバイスは、本プログラムの態様を実行するために使用され得る、種々の処理デバイス12a、12b、、12nと通信してもよい。処理デバイスは、相互間において、および/またはユーザデバイス11と相互接続13されてもよい。ユーザデバイスおよび/または処理デバイスのうちの種々のデバイスは、図2に示される実施例等のコンピューティングシステムを備えてもよい。ユーザデバイス11はまた、分散型コンピューティングシステムの一部としての役割を果たし得る、処理デバイスを組み込んでもよいことに留意されたい。また、1つ以上の処理デバイス12a、12b、、12nは、マルチコア中央処理ユニットCPU等、単一プロセッサパッケージ内に含有されてもよいことに留意されたい。図2は、本発明の実施形態の種々の形態および/または一部を実装するために使用され得る、例示的システムを示す。そのようなコンピューティングシステムは、1つ以上のシステムメモリ21に連結され得る、1つ以上のプロセッサ22を含んでもよい。そのようなシステムメモリ21は、例えば、RAM、ROM、または他のそのような機械可読媒体を含んでもよく、システムメモリ21は、例えば、ベーシックI/OシステムBIOS、オペレーティングシステム、プロセッサ22による実行のための命令等を組み込むために使用されてもよい。システムはまた、付加的RAM、ROM、ハードディスクドライブ、または他のプロセッサ可読媒体等、さらなるメモリ23を含んでもよい。プロセッサ22はまた、少なくとも1つの入力/出力I/Oインターフェース24に連結されてもよい。I/Oインターフェース24は、1つ以上のユーザインターフェース、ならびに種々の型のストレージ媒体のためのリーダ、および/またはそこから、例えば、ソフトウェアコードが、得られてもよい、1つ以上の通信ネットワーク例えば、通信インターフェースおよび/またはモデムへの接続を含んでもよい。そのようなコンピューティングシステムは、例えば、その上で、翻訳ソフトウェアを起動し、および/またはエミュレーションシステムを制御する、それを格納する、またはそれとインターフェースをとる、プラットフォームとして使用されてもよい。さらに、FPGA等の他のデバイス/媒体もまた、システムに取り付けられ、それと相互作用してもよい。前述のように、分散型コンピューティングシステムを実装時、検討される必要があり得る、多数の問題が存在する。例えば、1つは、タスクをどのように分散させるか、処理デバイス例えば、図1の12a、12b、、12nおよび/またはユーザデバイス11間のデータの相互作用/交換をどのように配列するか、効率的実行をどのように促進するか、そのようなシステムのためのプログラムの準備をどのように促進するか等を検討する必要があり得る。分散型コンピューティング環境の種々の態様に対応するために、そのような環境のためのランタイムアーキテクチャは、プログラムコンポーネントのためのきめの細かいスケジューリングサービスを提供してもよく、そのために、プログラムは、従来の実行システムおよびC等の関連付けられたプログラミング言語において型変換されたプログラムと異なるように分解されてもよい。したがって、典型的には、主として、スレッドあたり1つのコールスタックを使用する、リエントラント関数を呼び出す複数の独立スレッドから成るネイティブC/Pスレッド実行モデルほとんどの他の命令型言語によって共有されるモデルと、本発明の種々の実施形態において使用され得る実行モデルとの間で区別が行われてもよい。本発明の実施形態は、ランタイムのスケジューリングアルゴリズムに関して、個々に、実行の基本単位を構成し得る、コードレットに基づく実行モデルを使用してもよい。コードレットは、以下を含んでもよい。プログラムの状態を進行させるために、通常状況下、行われるべきタスクの記述。これは、コードレットの起動フォークである。プログラム状態を安全に取り消すために、例外的状況下、行われるべきタスクの随意の記述。これは、コードレットのキャンセルフォークである。該当する場合、コードレットによって予期されるコンテキストフレームの型の記述。コードレットへのコンテキストフレーム入力は、オブジェクト指向言語におけるメソッドにパスされる、implicitthis/selfパラメータに類似する。コンテキストとは、その状況または状態例えば、変数、キャッシュ値等を記録するために、コードレットまたは、一般に、任意のプロシージャによって使用され得る、情報を指す。該当する場合、コードレットによって予期される入力データの型の記述。コードレットは、各フォーク、起動およびキャンセル、ならびにコンテキストおよび入力型の記述のための関数への参照を含有する記述子オブジェクトとして、ランタイム環境内に表現されてもよい。実行を始動すると、コードレットは、そのコンテキストおよび入力への参照、ならびにシステムハードウェアに対してその関係を管理可能にする役割を果たし得る、環境バッファへの参照を受信してもよい。加えて、コードレットは、付加的チェーンコードレット以下参照およびコードレットによって開始されたアクティビティが完了すると、起動されるべき関連付けられたチェーンコンテキストへの参照を受信してもよい。コードレットを起動するために、コードレットインスタンスは、スケジューラスケジューラは、以下にさらに論じられるであろうによって、コードレット、コンテキスト、および入力への参照をレジスタすることによって作動可能となり得る。コードレット参照はまた、様々な作動可能の段階において、部分的コードレットインスタンスを作成するために使用され得る。例えば、ネットワークからの入力を待機するコードレットは、ネットワークインターフェース上のそのコンテキストにレジスタされてもよく、その入力は、データがネットワークから到着すると、コードレットインスタンスを完成するように、後に記入することができる。スケジューラが、実行のためのコードレットを選択すると、そのコードレットは、アクティブとなり、概して、プリエンプションまたはブロッキングを伴わずに、完了するように起動し得る。これは、コードレットが、その実行の持続時間の間、排他的にその処理スレッドを利用し得ることを意味する。コードレットが、従来、ブロッキング例えば、ファイルからの読み取りをもたらすであろう条件に遭遇する場合、任意の不揮発性データをそのコンテキストにスピルし、チェーンコンテキストおよびコードレットを適切なソフトウェアインターフェースにレジスタし、その実行を終了し、制御をランタイムシステムに委譲し得る。registered-forイベントが生じると、レジスタされたチェーンコードレットは、次いで、コンテキストからの状態をアンパックし、以前のコードレットが中断した実行を再開し得る。本機構は、オペレーティングシステムを関与させ得る、鈍重なタスクまたはスレッド切替機構を要求せずに、レイテンシの長い動作が完了する間、コードレットによって使用中のハードウェアリソースが、放棄され、他のワークのために再使用されることを可能にする。本機構はまた、例えば、いくつかのコードレットインスタンスをスケジューラにレジスタすることによって、より多くのコードレットを生成するために使用されることができる。ある場合には、タスクを完了するために、2つ以上のコードレットを使用することが必要であり得る。例えば、ファイルからテキストの一節を読み取ることは、任意の数のブロッキング動作を伴い、それぞれ、コードレットに、そのコンテキストにスピルし、再開のためにレジスタし、終了し、最終的に、再開することを要求し得る。単一目標に向かってワークを行うコードレットのグループは、コードレットコンプレックスと称され得る。典型的には、コンプレックス内の全コードレットは、個々に連続して、またはともに並行してかにかかわらず、同一コンテキストオブジェクトを使用してもよい。コードレットはまた、包括的スーパーコンプレックスの代わりに、タスクのより小さい部分を行う、サブコンプレックスを形成し得る。例えば、コードレットコンプレックスは、ファイルからテキストの一節を読み取るために使用されてもよく、スーパーコンプレックスは、ファイル全体を解析し、そのデータをメモリ内に記憶する間、そのコンプレックスを使用してもよく、スーパー-スーパーコンプレックスは、解析コンプレックスを使用して、アプリケーションコアに投じられる前に、その構成データを作動可能にしてもよい等となる。コンプレックスは、したがって、プログラム構造に及ぼす影響の観点から、高レベルプログラミング言語におけるサブルーチンに類似すると考えられ得る。しかしながら、必ずしも、ほとんどの言語におけるサブルーチンと同一の後入れ先出しLIFO順序要件を被るわけではない。前述のように、コードレットが実行を始動すると、ともにチェーンペアと称され得る、チェーンコードレットおよびコンテキストへの参照が与えられてもよい。これはいくつかのタスクの完了への依存性を示すための単純機構を提供し、典型的には、任意の従来のサブルーチンコールに暗黙的にパスされる、リターンアドレスに関連すると見なされ得る。前述の一節の読取実施例を再考すると、チェーンペアを一節の読取コンプレックスを開始するコードレットにパスすることは、その入力として、新しく読み取られたテキストとともに、一節全体が読み取られた後、チェーンコードレットの作動可能状態をもたらし得る。アクティブコードレット内では、実行モデルは、従来のスタックベースのモデルに類似してもよく、下層プラットフォームがそれをサポートすると仮定すると、コードレットは、関数コールを正常に行い得る。コードレットはまた、ランタイムソフトウェアに明示的に順番を譲ることによって、それ自体の実行を一時的に保留してもよく、これによって、直接、保留されたコードレット内から読み出されるかのように、1つ以上の他のコードレットを同一プログラムスタック上で起動可能にし、その後、スケジューラは、何事もなかったかのように、保留されたコードレットの実行を再開し得る。本発明による、ランタイム環境の実施形態は、従来の関数コールおよび/またはコードレット内での使用のために、スタックベースの例外ハンドリングをサポートしてもよく、加えて、可能であれば、高速かつ単純エラー回復を可能にし得る、双方向例外再開意味論をサポートしてもよい。しかしながら、コードレットは、直接、プログラムスタック上で相互に関連し得ないため、スタックベース機構を使用してコードレット間で例外を伝送することは、不可能であって、純粋なLIFOの順序を有していない可能性が高いであろう。このため、各コードレットは、チェーニングの間、使用することができる、随意のキャンセルフォークを有してもよい。チェーンコードレットは、それを正常に起動する起動フォークを介して、またはそれをキャンセルするキャンセルフォークを介してことによって、対処され得る。キャンセルフォークは、例外をチェーンコードレットに伝送するために使用されてもよく、同様に、スタックベースの例外スローは、例外を発呼側関数に伝送してもよい。チェーンペアは、コードレットのキャンセルフォークにパスされ、エラー回復後、再開のためのサポートを提供してもよく、同様に、チェーンペアは、起動フォークにパスされ、完了をサポートすることができる。本発明の種々の実施形態による、コードレットは、現在普及している関数およびスタックベースの実行モデルに密接に関連してもよく、その拡張機能として作用してもよい。関数とコードレットとの間の主要な差異は、以下である。順序制約LIFOまたは別様にが、相互に対して、コードレットに課されないが、コードレット自体の挙動によって施行されるそれらの制約を除く。リターンアドレスおよび発呼側のスタック/例外フレームポインタの代わりに、コードレットは、チェーンペアを受け取る。チェーンペアは、コードレットがアクティブになった後、随時コードレットの実行または保留の間を含む、トリガされてもよい一方、関数のリターンは、関数自体の実行と重複し得ない。コードレットに課される要件は、関数に課されるものより弱いため、コードレットは、従来の方式のLIFO順序化関数を実装するために使用されてもよい。当然ながら、従来のスタックベースの機構は、主に、その極端に低いオーバーヘッドのため、依然として、有用であり得る。スタック上のデータ配分は、加減動作のみを要求してもよく、関数コールは、典型的には、レジスタ記憶またはスタックプッシュ動作のみを伴ってもよい。このことから、コードレット生成コンパイラが、チェーニングされたコードレットコールをコードレット内LIFO関数コールに変換することは、非コードレット生成コンパイラのインライン化関数コールに非常に類似し得るということになる。コンパイラが、可能であれば、その出力のコードレットおよび関数ベースの形態の両方を生成する場合、また、より低いオーバーヘッドの同期LIFO関数ベースのコールとより高いオーバーヘッドの非同期コードレットベースのコールとの間の静的または動的選択も可能にし得る。本発明の実施形態は、コードレットに対するサポートの提供に加え、静的データフロープログラミングのためのより優れたビルトインサポートを提供する、コードレットの拡張機能である、データレットに対するサポートを提供してもよい。コードレットは、単一コンテキスト、入力、およびチェーンペアを受け取ってもよく、これらのデータが作動可能になるとすぐに、実行されてもよい。データレットは、単一コンテキストおよびチェーンペアを受け取るだけではなく、また、非同期的に、かつ任意の順序で準備され、割り当てられ得る、任意の数の入力を受け取ってもよい。データレットは、コードレット同様に、メモリ内に、ランタイムコンポーネントがデータレットを直接参照することを可能にし得る、関連付けられた記述子を有してもよく、本記述子は、コードレット記述子の全コンポーネント起動/キャンセルフォークへの参照を含む、ならびに全入力およびその型の記述とアプリケーション提供起動およびキャンセルフォーク関数への参照を含んでもよい。データレット挙動は、コードレット挙動を拡張させ得るため、データレットのコードレットアスペクトは、別個の内部起動およびキャンセルフォーク関数を使用して、データレットのための入力を受け取り、準備し、データレット特有の起動/キャンセルフォーク関数を立ち上げてもよい。データレットの内部起動/キャンセルフォークは、以下、その制御フォーク例えば、その制御起動フォークまたは制御キャンセルフォークと称され、アプリケーション特有フォークは、アプリケーションフォークと称される。図10aおよび10bは、コードレットのフォーク図10aとデータレットのフォーク図10bとの間の差異を図示する。入力をデータレットに割り当てる時、入力のための識別子例えば、整数、入力のための値、および入力がもはや必要ではなくなる時に実行されるべきチェーンペアが、データレットの制御起動フォークへの入力として、ともにパスされてもよい。制御起動フォークは、開始に応じて、データレットのアプリケーション起動フォークによる後の使用のための入力を準備する、および/または実行のためのアプリケーション起動またはキャンセルフォークをスケジューリングするために必要な任意のアクションをとってもよい図10c。データレットのキャンセルは、特定のコンテキストのために収集された入力の破棄をもたらしてもよく、データレットのアプリケーションキャンセルフォークは、その結果、コールされてもよい図10d。アプリケーションフォークを開始するために使用される方法にかかわらず、入力がデータレットによって消耗されると、すなわち、アプリケーションフォークが、そのチェーンペアを実行させると、入力とともにパスされた任意のチェーンペアが、ディスパッチされてもよい。本発明の実施形態は、ランタイム内部チェーンペアを制御フォークからアプリケーションフォークにパスし、次いで、チェーンコードレットを使用して、データレット入力をクリーンアップすることによって、本プロセスをもたらしてもよい。いくつかの種々のデータレット挙動は、特に有用であって、論理AND、OR、およびXOR演算子に対応してもよい。ANDベースのデータレットは、全指定された入力が受信され、使用のために準備された後、そのアプリケーション起動フォークを起動し、制御起動フォークに対するコンテキストパラメータを使用して、具体的入力値のキューにマップしてもよく、全入力値が特定のコンテキストに対して収集されると、値は、キューから除かれ、データレットのアプリケーション起動フォークが、開始されてもよい。ORベースのデータレットは、入力の一部または全部が収集される場合、そのアプリケーション起動フォークを起動してもよい。異なる実施形態は、他の挙動の中でもとりわけ、任意の1つの入力が収集されるとすぐに、アプリケーション起動フォークを起動するように選択してもよくXORベースのデータレットと効果的に同じ挙動、いくつかの最小数の入力が収集されるまで、待機してもよく、またはある短い遅延の間、待機し、入力を蓄積させてもよい。XORベースのデータレットは、単一入力が受信されるとすぐに、そのアプリケーション起動フォークを起動し、その単一入力をアプリケーション起動フォークにパスするのみであってもよい。本発明の実施形態は、他のデータレット挙動例えば、時限NOTまたはNORベースのデータレットを実装または提供してもよい。加えて、いくつかの実施形態は、動的に指定された入力リストおよび型を提供してもよい。本発明の種々の実施形態による、システムは、図4に示されるように、大まかに階層線に沿って分割されてもよい。コンピューティングユニバースは、システム41、42、および43等の1つ以上のランタイムシステムを含んでもよい。所与のランタイムシステムは、ホスト411等の1つ以上のホストを含んでもよい。ホストは、ノード4111等の1つ以上の処理ノードを含んでもよい。処理ノード4111は、1つ以上のソフトウェアまたはハードウェアスレッド41111を起動するために使用されてもよい。コードレット実行は、ランタイムシステムによって管理され得る、ハードウェアまたはソフトウェアスレッド上で生じてもよい。これらのスレッドは、それらの間で容易に共有され得る、情報の程度に基づいて、ともにグループ化されてもよい。例えば、キャッシュを共有する2つのスレッドは、ともにグループ化される場合があり、またはホスト上の全コアは、ともにグループ化され得る。これらのグループ化は、分散型プラットフォーム上で実行するソフトウェアの通信特性を記述するために使用され得る、ツリー状の構造またはロケールツリーにネスト化されてもよい。ツリー内の各ロケールは、それぞれ、ロケール内のメモリ空間および処理時間の配分を管理し得る、関連付けられたストレージおよび処理リソースを有してもよい。リーフすなわち、最下レベルかつ子がないロケールのアロケータおよびスケジューラは、その記述されるハードウェアまたはソフトウェア構造内の空間/時間配分を管理し得る一方、より高いレベルのロケールのアロケータおよびスケジューラは、それ自体の配分および/またはその子孫の配分を管理し、潜在的に、子孫のハードウェアおよびソフトウェアリソースの集約を可能にし得る。ロケールは、コンピューティングシステムの境界領域を表し得るため、本発明の実施形態によって提供されるロケールとのソフトウェアインターフェースは、通常、特殊ソフトウェアサポートまたは明示的ハンドリングを要求する、境界を越える、それらの領域間のデータの転送および制御を提供し得る。ロケールは、アドレス空間内データ転送例えば、ポインタ共有およびバルクコピー、ノード内アドレス空間間転送例えば、メモリマッピングを共有して、またはローカルソケットインターフェースを使用して、および/またはノード間転送例えば、ネットワーク/バス相互接続にわたっての明示的パケット/メッセージベースの通信を含む、異種データ転送方法の抽象化を可能にし得る。データ転送に加え、1つのロケール内で実行するコードレットは、ロケールツリー内のその実行範囲を拡大、縮小、または全体的に移動させ得る。これは、プログラムコンポーネントの実行が、明示的または暗黙的に、それに応じて作用が必要となるデータにフォワードされることを可能にし、システムをデータ可用性および配置に動的に反応可能にさせ得る。ロケールを管理するための技法はさらに、システム内の不均一性に関連する問題の管理を支援し得る。将来的コンピューティングシステムは、相当なハードウェア不均一性を呈することが予期されるため、それに良好に対処するための分散型ランタイムシステムを設計することが望ましくあり得る。通信、スケジューリング、およびメモリ配分のために使用される抽象化を統一することによって、本発明の実施形態は、単純明快な実行の分散を可能にし得る。前述のロケールツリーは、利用可能である場合、異種ハードウェアコンポーネントを記述するために拡張されてもよい。例えば、付随メモリを伴うGPUは、具体的にそれを参照する、それ自体のスケジューラおよびアロケータとともに、それ自体のロケールが与えられてもよい。コードレットは、ランタイムに対する高レベル多型オブジェクトとして表され得るため、起動またはキャンセルフォークの複数の形態が、コードレットオブジェクトとともに記憶されてもよく、例えば、1つは、CPUアーキテクチャ用、1つは、GPUアーキテクチャ用であって、ランタイムは、次いで、自動的に、必要に応じて、その形態から選択してもよい。自動的および明示的両方のスケジューリングが、可能となり得るため、プログラムは、コードレットを明示的に特定し、例えば、GPUにスケジューリングする、またはそれおよび適切なワークが利用可能になるのに伴って、ランタイムをGPUにスケジューリングさせるかのいずれかであってもよい。本発明のランタイムシステムの実施形態はまた、典型的には、互換性がない、アーキテクチャの統合を可能にしてもよい。例えば、データは、以下に論じられる、Transferableインターフェース型以下により詳細に論じられるを使用して、リトルエンディアンとビッグエンディアンアーキテクチャとの間、または異なるポインタ形式を伴うアーキテクチャ間を容易に移行され、アーキテクチャの個別のロケール間でデータをポートしてもよい。一方、Transferableの非使用は、オブジェクトをそのアドレス空間に暗黙的に固定可能にし得るが、圧縮ガーベジコレクションを伴うシステムは、依然として、アドレス空間内のオブジェクトを再配置させ得る。データ転送の基礎としてのロケールの使用はまた、ネットワーク化された計算ノード間の境界が、多くの場合、アプリケーションによって軽視されることを可能にして得る。プログラムコンポーネントが、起動するために十分なローカルデータおよび利用可能なメモリ空間を有する限り、そのコンポーネントの実行が生じる場所、またはハードウェアのどの精密な部品上であるかが問題になることは稀であり得る。ランタイムが、通信および実行配置を管理可能となることによって、アプリケーションコンポーネントは、必要に応じて、透過的に移行され、例えば、通信オーバーヘッドを削減し、またはローカル処理またはメモリ負荷を平衡化し得る。ロケール階層は、コードレットスケジューラおよび/または他のソフトウェアリソースによって使用され、ローカリティの概算を導出し、したがって、コードレット実行および/またはコンテキストの配置の判定を支援してもよい。一実施形態では、デフォルト挙動は、協働コードレットが、メモリ内の単一コンテキストブロックを共有することを要求するものであってもよく、これらのコードレットは、理想的には、本コンテキストブロック近傍のいずれかの場所で実行していてもよい。別の実施形態では、より高度な並行コードレットコンプレックスに対して、より大きなシステムリソースの集合にわたって、その実行を分散させることが望ましくあり得る。このため、コンプレックスは、ロケールツリーの上部にオーバーレイされるツリー状構造内に配列され得る、コンテキストのいくつかの層を利用してもよい。図5は、コンテキスト層の実施例を示す。コンテキスト層ツリーのリーフは、コードレットが、最も容易かつ直接、確認する、コンテキストに対応し得る、最も局在したコンテキストブロックを表し得る。あまり局在していないコンテキストブロックは、リーフコンテキストから親ポインタを通して、参照することができる但し、ランタイムシステムの実施形態と互換性があるコードを生成する、プログラミング言語は、これらのポインタを通したより高いレベル層への参照を曖昧にし得る。その結果、多層コンテキスト図5の実施例では、本発明は、これに限定されないが、3層コンテキストは、単一CPUコア内の異なるハードウェアスレッド上で起動するコードレット間で共有されるコンテキスト層、単一NUMAノードまたはホスト上で起動するコードレット間で共有される別の層、およびコンプレックス内の全コードレット間で共有されるさらなる層を提供するために使用することができる。通常単一層プロシージャコンテキストは、直接、コードレット間で共有されてもよいが、いくつかの状況または実施形態では、そこに記憶されたデータを同期させるために、明示的リソース管理コールを使用して、より上層のコンテキストを明示的にフラッシュするために必要であってもよい。典型的実施形態では、より上層のコンテキストは、より下層コンテキストが、未使用となると、自動的にフラッシュされてもよく、そのストレージは、リクレ-ムされる。代替実施形態では、コンテキスト情報の更新は、現在の情報が必要とされるまで、延期されてもよい。本発明を具現化する、ランタイム内で実行する各コードレットは、開始されると、環境バッファが提供されてもよい。環境バッファは、コードレットが、現在、実行中である、ロケール、コードレットコンプレックスの実行ルートに対する最新のホップおよび発信元を指定し得る、原点および送信側ロケール、ならびにルートに対する次のおよび最終ホップを指定し得る、受信側および宛先ロケールへの参照を含有してもよい。環境バッファは、その実行経路をリダイレクトするために、それを使用するコードレットによって修正されてもよい例えば、返信をもたらすために、それを反転させることによって。コードレットの現在の環境バッファは、実行を始動すると、コードレットにパスされることに加え、スレッドローカルメモリ領域内に記憶される、またはスレッドローカルポインタによって参照されてもよい。現在の環境バッファ特に、現在かつ受信側ロケールは、ランタイムによって使用され、配分およびスケジューリング要求が、完了されるべき、ロケールを選択してもよい。したがって、コードレットが、その環境バッファの受信側ポインタを別のスレッドのロケールを参照するように設定する場合、配分された任意のメモリは、デフォルトによって、そのスレッドロケールのアロケータから配分されてもよく、スケジューリングされた任意の他のコードレットは、デフォルトによって、そのスレッドにスケジューリングされてもよい。しかしながら、コードレットはまた、その環境バッファを迂回し、明示的に、そのような動作のための標的ロケールを指定してもよい。本議論では、リソースを参照し、かつ参照されてきた。本願の目的のために、リソースは、プロセスまたはインターフェースを伴う、制御またはデータ依存性が存在し得るものである。すなわち、リソースが、ハードウェアを伴う場合、リソースは、本願の目的のために、そうでないことが指定されない限り例えば、ハードウェアリソース、デバイス等として明示的に説明される、ハードウェア自体ではなく、ハードウェアに対するソフトウェアインターフェース例えば、ハードウェア処理デバイスに対するソフトウェアインターフェースである。リソースは、必ずしも、そのように限定されないが、とりわけ、CPUスレッド/コアに対するインターフェース等の処理リソース;ディスク上のオンまたはオフチップRAMおよびファイルに対するインターフェース等のストレージリソース;ネットワークソケット等の通信リソース;共有データ構造;および実行可能コードを含んでもよい。リソース相互作用は、getおよびput動作の使用を通して生じてもよい。put動作は、データをリソースにプッシュするために使用され、終了すると、その呼び出しプロセスの代わりに、いくつかのユーザ指定チェーンコードレットの実行を生じさせてもよい一方、getは、リソースからデータを抽出するために使用されてもよく、終了すると、ユーザ指定チェーンコードレットの実行を生じさせてもよい。getおよびput動作に与えられるチェーンコードレットは、完了コードレットと称される、または当該動作の完了後のみ、実行するため、関連付けられたチェーンコンテキストとともに、完了ペアと称される。相互作用リソース間のツリー状対話を促進するために、本発明の実施形態は、キーを使用して、リソースとのデータ/制御交換をマークしてもよい。キーは、リソースとの一連の相互作用の状態のための記述子として、またはそのような記述子のためのセレクタすなわち、記述子への直接または間接ポインタとして作用する。各putおよびget動作は、リソースの挙動に従って、キー値を受け取り、および/または生成することができる:put/getのためのヌルキーをパスすることは、新しい対話を開始するために使用されてもよい。そのような動作は、任意の具体的な以前のput/get動作を参照するとみなされないが、リソースの内部状態を暗黙的に参照することができる。put/getからヌルキーを生成することは、いずれの後の動作も、現在の対話が、交換を終了させるために試行されるべきではない、またはその必要がないことを示してもよい。しかしながら、リソースに応じて、以前のput動作にパスされたキーを再び参照することが可能であってもよい。put/getのための非ヌルキーをパスすることは、既存の対話を参照してもよく、キーを生成した以前のものと動作を関連付けてもよい。キーを複数回使用することは、リソースによって可能となる場合、第1のものから分岐する複数の対話を開始してもよい。しかしながら、本挙動は、いくつかの状況に対してのみ適切であり得る。put/getから非ヌルキーを生成することは、後の動作が、現在のものを参照し得ることを示してもよい。それを生成しなかったリソースにキーをパスすることは、エラーをもたらし得、キーは、ランタイム環境内の特定の領域に局在し得る場合がある。図3は、キーパッシングによってサポートされ得る、3種類の対話を図示する。図3において、aによって指定される対話は、単一動作対話であってもよい。本対話では、ヌルキーは、動作入力として示され、ヌルキーは、動作によって生成される。対話bは、順次対話と考えられてもよい。本対話では、ヌルキーは、それに応答してキー1が生成され得る、第1の動作入力として使用されてもよい。キー1は、次いで、第2の動作への入力として使用されてもよく、キー2は、第2の動作によって生成されてもよい。キー2は、次いで、ヌルキーを生成し得る、第3の動作への入力であってもよい。最後に、対話cでは、ヌルキーは、キー1を生成し得る、第1の動作への入力として使用されてもよい。キー1はまた、ヌルキーを生成し得る、さらなる動作への入力として使用されてもよい第1の動作と連続して、または並行のいずれかにおいて。本発明の実施形態は、コードレットコンプレックスコンテキストによって使用されるコンテキストの設定および分解を抽象化し、また、従来のLIFO要求-応答挙動の並列化形態が必要とされる時、コンプレックスを支援し得る、高レベル構成概念をサポートしてもよい。ネイティブ関数コールの使用は、APIコールまたは少量の計算等、共通場所または軽量アクションに対しては、完全に容認可能であり得るが、プログラム内のより大きな関数は、高レベルプロシージャを利用することによって、リソースの観点から実装されてもよい。プロシージャは、任意の他のリソース同様に処理されてもよく、パラメータをプロシージャにputする、および/または関連付けられたリターン値をプロシージャからgetすることができる。本発明の実施形態による、プロシージャは、リソースとみなされ得るため、各プロシージャは、関連付けられた実行可能コードを伴うメモリ内の小リソース記述子として、ランタイムのビュー内に存在する。アクティブに実行中のプロシージャ毎に、前述のように、その状況または状態例えば、変数およびキャッシュ値を記録するために、プロシージャによって使用される、任意の情報を記憶する、関連付けられたコンテキストを有する。putが、プロシージャ上で呼び出されると、新しいプロシージャコンテキストが、プロシージャ起動の開始に備えて、作成されてもよく、そのある部分は、パラメータ入力によって初期化され、ある部分は、リターン値のために留保され、残りは、実行の間、プロシージャ自体の使用のために留保される。コンテキストが作成されると、プロシージャのための任意のエントリコードレットが、起動するようにスケジューリングされてもよく、コードレットは、加えて、発呼側に、putが完了したことを通知するようにスケジューリングされてもよい。発呼側が、プロシージャの出力値を要求するとまたは、出力値が不在の場合は、発呼側が、プロシージャの完了の通知を要求すると、オリジナルputから返され得るキーを使用して、getをプロシージャリソースに発行してもよい。プロシージャが、実行を完了し、出力値を生成すると、該当する場合、値は、前述のget動作から、完了コードレットを介して、発呼側にパスされてもよい。イベントの順序は、プロシージャリソースと相互作用する時、最小限に順次的であることに留意されたい。すなわち、プロシージャコンテキストは、初期put動作後、随時、初期化されてもよく、put完了コードレットは、エントリコードレットが開始された後、随時、実行されてもよく、get動作は、完了コードレットが開始後、随時、開始されてもよく、get完了コードレットは、プロシージャが完了後、随時、開始されてもよい。そのようなランタイムおよび実行モデルに対する拡張機能が、高レベル同時ルーチンとして作用するプロシージャのためのサポートを提供してもよい。具体的にキー指示されたput動作を使用することによって、連続値を実行プロシージャにプッシュすることができ、複数のget動作を使用することによって、値をプルすることができる。これは、チェックポイントを行うことができる、またはそのコンテキストをバージョン化することができる、プロシージャに対して、あるいはプロシージャの実行の特定の分岐が、異なる入力値によって再開することができる場合、特に有用であり得る。また、プロシージャとその発呼側との間に要求-応答相互作用パラダイムを確立するために有用であり得る。本発明の実施形態では、ストレージリソースは、特定のメモリ領域のためのマネージャとして作用してもよい。オブジェクトが、ストレージリソースにputされると、オブジェクトのための空間が、配分されてもよく、オブジェクトは、複製されてもよく、オブジェクトのためのキーが、生成されてもよい。ストレージ空間の要求される量が、利用不可能である場合、putは、要求を直ぐに満たすことが不可能であり得、完全に失敗する、または二次ストレージ装置にフォールバックする場合さえある。ストレージリソース内に記憶されたデータが、それをリソース内に配置したputから生成された対話キーを使用して、アクセス可能であってもよいが、また、アドレス可能メモリにマップされ、アプリケーションが、データがアクセスされ得る、ローカルポインタを得ることを可能にしてもよい。図7は、ストレージリソース、アプリケーションのローカルアドレス空間、およびマッピング要求を満たすために使用されるストレージ-リソース-プライベートアドレス空間の間の関係の概念的略図を示す。直接、所望のリソースにマップする、アドレスを得ることが不可能である場合、記憶されたオブジェクトのローカルコピーが、代わりに、作成されてもよい。本発明のいくつかの実施形態は、マッピングに行われた変更コピーされたオブジェクトを含むを自動的に同期させてもよい。他の実施形態は、変更を同期させるために、ストレージリソースと明示的相互作用を要求してもよい。もはや必要されなくなると、マッピングは、アドレス範囲またはそれと関連付けられたメモリを解放するために破壊されてもよい。マッピングは、加えて、マッピングのためのアクセス許可および/またはキャッシング規範等の選択肢を含み得る、ユーザが、データがどのように使用され、所望のマッピングがどのように行われるべきかを指定することを可能にしてもよい。マップされたデータが、複数のアプリケーションコンポーネント間で共有され得るかどうかに関して、推測的に任意の保証を行うことは不可能であり得ることに留意されたい。すなわち、ストレージリソースが、マップされた範囲のローカルコピーを維持しなければならないことを把握している場合でも、そのローカルコピーは、ローカルに行われる場合、依然として、共有され得る。ストレージリソースは、非ローカルデータをハンドリングするために、便宜的抽象化をもたらし得るが、ユーザコードは、必要ならば、依然として、マッピングローカリティを記録する必要があってもよい。例えば、1つのスレッド上で起動している間、ローカルである、マッピングは、別のスレッド上で起動している間、ローカルでなくてもよい。これは、マッピングのユーザが、異なるスレッドへの再スケジュール間において、マップ解除する、または任意の再スケジュールが、同一スレッド上で生じることを確実にすることのいずれかを必要とし得ることを意味する。直接、実行中のコードレットにアクセス可能なアドレス空間を管理し、かつそれにアクセスするために、コードレットに、そのデータをマップおよびマップ解除することを要求しない、ストレージリソースは、具体的には、アロケータと称されてもよい。前述のように、ロケール毎に、それに付随する任意のメモリおよびその従属メモリを管理し、それとともに、コードレットのコンテキスト、入力、および他の付随的データが、記憶される、関連付けられたアロケータを有する。スレッドのスタック、ヒープ、静的データ、および/またはコードもまた、ストレージリソースとともに保持されてもよい。各コードレットの環境バッファは、配分要求のための適切なアロケータを選択するために使用され得るが、いくつかの実施形態は、他の要因を考慮してもよく、またはある場合には、潜在的に、環境バッファ全体を軽視してもよい。処理リソースは、本発明の実施形態のさらなるコンポーネントを構成してもよい。処理リソースは、概して、get完了コードレットのスケジューリングを可能にしてもよい。例えば、ヌルキーからgetすると、リソースは、次に適合するとみなす時は常時、コードレットをスケジューリングしてもよい。より精密な制御が、必要とされる場合、処理リソースは、putによってプッシュされたジョブ記述を受け取ってもよく、そのputから生じるキーは、1回以上、getによって使用され、より精密なパラメータによってジョブをスケジューリングしてもよい。本発明のいくつかの実施形態では、ある処理リソースは、ハードウェアスレッド毎に作成されてもよく、1つ以上の代表リソースが、その上の層内に作成されてもよい。最も一般的型の処理リソースは、コードレットスケジューラまたは、単にスケジューラであるが、処理リソースはまた、ソフトウェアインターフェースをグラフィック処理ユニットGPU、フィールドプログラマブルゲートアレイFPGA、または他のプロセッサおよびコプロセッサハードウェアに提供してもよい。スレッドレベルスケジューラは、実際には、スケジューリングされたコードレットインスタンスを起動し得るが、より高いレベル例えば、プロセッサホストレベルスケジューラは、コードレットインスタンスおよびスケジューラが、利用可能となるのに伴って、コードレットインスタンスをバッファし、それらをスレッドレベルスケジューラにフォワードするために使用されてもよい。リーフロケールのスケジューラまたは、リーフスケジューラは、スケジューリングされたコードレットのデック両端キューを管理してもよい。それ自体内からロケールにスケジューリングされたコードレットは、典型的には、他のコードレットより優先され、かつより高速のスケジューリング/ディスパッチ経路が与えられてもよい。これは、要件ではないが、速度最適化を支援し得る。非リーフスケジューラは、典型的には、より高速またはより低速経路も伴わずに、より単純なワークデックを管理してもよい。通常動作下、各リーフスケジューラは、ランタイムコアによって繰り返し介入されてもよく、それぞれのスケジューリングデックの先頭におけるコードレットインスタンスをポップオフおよび実行させ得る。リーフスケジューラが、空のデックを有する場合、その親ロケールに対するスケジューラは、コンサルトされ、いくつかのワークをリーフスケジューラに与えるよう依頼される。親のスケジューリングデックに何らかが存在する場合、そのデックの先頭は、ポップオフされ、実行のために、リーフスケジューラにパスされてもよい図9a。そうではない場合、親は、リーフスケジューラの兄弟スケジューラのうちの1つから、ワークのスティールを試みてもよく、成功する場合、兄弟スケジューラの最後尾からそのワークを除去してもよい図9b。兄弟スケジューラが、行うべき任意のワークを有していない場合、親は、その親にコンサルトしてもよく、プロセスは、本様式を継続してもよい。いずれのワークも、リーフスケジューラに対して見つけられ得ない場合、それおよびその関連付けられたスレッドは、より多くのワークが到着するまで、アイドル例えば、低電力状態に置かれてもよい。コードレットは、意図された挙動に応じて、スケジューラのデックの両側にスケジューリングされてもよい。スケジューリングは、典型的には、次にスケジューリングされたものが、最後に実行されるものとなり、ほぼ先入先出FIFOの順序を維持するように、デックの最後にダイレクトされてもよい。しかしながら、スケジューリングはまた、次にスケジューリングされたものが、次に実行されるものとなり、ほぼLIFOの順序を維持するように、デックの先頭にダイレクトされてもよい。後者の形態は、例えば、深い再帰呼び出しが用いられる場合、分岐スケジューリング要求によって、全利用可能なメモリを占有することを回避するために有用であり得る。本発明の異なる実施形態におけるスケジューラは、内部的には、デックベースではなくてもよく、実行するためのコードレットを選択する時、要求順序以外の要因を考慮してもよいことに留意されたい。加えて、いくつかの実施形態のスケジューラは、ヒントと同程度にFIFOおよびLIFO順序化スケジューリング間のアプリケーションベースの区別を扱ってもよく、またはそれを完全に軽視してもよい。例えば、スケジューラは、プログラム要求FIFOまたはLIFO順序を大部分または全体的に無視する、動的スケジューリング決定が、FIFO/LIFO順序を綿密に履行するものより優れた性能をもたらすように、プログラムの挙動に関する予測を動的に行うことが可能であってもよい。本発明の実施形態はさらに、通信および/または同期リソースを含んでもよい。通信リソースは、プログラムの異なる部分間において、データを渡すために使用されてもよく、コードレット、ノードレット等のように、ランタイム抽象化に関与し得る、低レベルストリームまたはメッセージベースの通信インターフェースにわたって、より高いレベルの抽象化を可能にし得る。同期リソースは、セマフォ、バリア等のコードレットベースの実装へのアクセスを提供してもよい。本発明の実施形態による、有用概念の1つは、ノードレットであり得る。ノードレットは、共有サービスを介して、アクセスされ、例えば、いくつかの種類のネットワークソケットにわたって、利用可能となり得る、リソースおよび/またはコードレットの集合である。これは、例えば、共有される必要があり得る、メモリおよびリソースアドレスの管理を促進し、アプリケーションが、ホストとアドレス空間との間のアドレスマッピングを動的に管理する必要性を回避することを可能にし得る。対照的に、ノードレットは、それらをノードレットにレジスタすることによって、具体的パブリックリソースおよびコードレットへのより広範なアクセスを可能にさせ得る。ノードレットは、aサーブされたリソースを初期化し、任意の必要とされるバックグラウンドコードレットコンプレックスを開始し、bエクスポートされたリソースのレジストレーションを管理し、cサーブされたリソースへのアクセスを制御し、dノードレットの使用と関連付けられた補助状態を管理し、eアクセスパターンの最適化を制御し、および/またはfノードレットがシャットダウンされると、サーブされたリソースの初期化を解除してもよい。ノードレットは、ランタイム環境内で明示的に作成および開始されてもよく、または自動的に開始されてもよい例えば、構成ファイル内の動的ライブラリにネーム付けすることによって。ノードレットはまた、明示的にアクセスされると、ネットワークサービスに伴って即時、またはオンデマンドで、開始されてもよい。リソースが、ノードレットにレジスタされると、put/get要求は、遠隔で発行され、それらとローカルに相互作用してもよい。同様に、コードレットが、ノードレットにレジスタされると、遠隔要求によって、ローカルに開始されてもよい。バイトシリアライゼーションは、ある場合には、データ転送のために、必要とされてもよい。多くのリソースは、getおよびputプリミティブに勝る特徴を提供し得るため、ノードレットはまた、適切な型および機能性を伴うプロキシリソースが、ローカル要求を遠隔要求に変換するためにセットアップされ得るように、いくつかの遠隔型イントロスペクション機能を提供してもよい。例えば、ストレージリソースは、ネットワークにわたって提供されることができない、マッピング/マッピング解除関数を提供してもよい。これらの関数は、例えば、遠隔リソース内の実際のストレージを管理するために、転送されたgetおよびputを使用して、その中に挿入された、またはそこから読み出された、オブジェクトのローカルキャッシュを維持し得る、プロキシリソースによって、ローカルにエミュレートされてもよい。ノードレットの実装は、内部リソースおよびコードレットのための外部接続を多重化してもよい。ノードレットは、例えば、整数によって識別され得る、一式のリソース/コードレットの周囲にラッパを提供するとみなされてもよく、それらのリソース/コードレットと特定の方法において相互作用するために、それをダイレクトし得る、間接put/get要求メッセージを受け取ってもよい。ノードレットは、プロキシとして作用するが、その遠隔相手側と同様に見え、遠隔ノードレットにフォワードされるサロゲートとのローカル相互作用を可能にする、サロゲートをローカルに確立することによって、遠隔リソースおよびコードレットへの透過的アクセスを提供してもよい。ノードレットが、get要求メッセージを遠隔要求側から受信すると、要求をローカルリソースにフォワードしてもよく、get動作が完了すると、getの結果が、要求側に返されることができる。ノードレットが、put要求メッセージを受信すると、パラメータをメッセージからプルし、即、適用可能であるサロゲートリソースにputしてもよく、再び、put完了を要求側にフォワードしてもよい。ノードレットが、コードレットを実行するための要求を受信すると、コンテキストおよび入力パラメータを要求メッセージから抽出し、要求されたコードレットをローカルに起動してもよい。すなわち、コードレットが、そのチェーンペアを起動すると、その入力は、要求側にフォワードバックされることができる。実施形態は、要求側のコードレットが、さらなるチェーンコードレットをノードレットのローカル側にトリガバックされ得るように、さらなるチェーンペアのための識別をフォワード可能にしてもよい。本プロセスは、潜在的に、ノードレットの両側のコードレットが、双方向的にデータを交換し続ける場合、無限に繰り返され得る。ノードレットを開始すると、ローカルコードレットおよびリソースは、遠隔要求側が、それらと相互作用し得るように、それにレジスタされてもよい。ノードレットはまた、遠隔リソース/コードレットとローカルサロゲートとの間の関連付けを確立し、それらとの相互作用を提供してもよい。いくつかの実施形態は、遠隔リソース/コードレットのレジストレーションまたは検出およびそれとの関連付けのためのローカルリソース/コードレットの自動検出およびレジストレーションを提供してもよく、実施形態は、アプリケーションに、リソース/コードレットにレジスタし、それと関連付けることを可能にする、またはそれを要求してもよい。図6は、本発明の種々の実施形態による、3つのリソースマッピングを伴うノードレットを示す。ノードレットは、ID1、2、および3のための仮想化されたリソースを提供してもよく、それぞれ、そのputおよびget動作を他のリソースに接続させてもよい。プログラムレットもまた、本発明のいくつかの実施形態において使用されてもよい。プログラムレットは、そのコンポーネントが、抽象形態において、ランタイムソフトウェアに提示され、解釈される、またはネイティブコードに動的にコンパイルされ、本発明の分散型ランタイム環境の実施形態において起動され得る、プログラムとみなされてもよい。プログラムレットは、関与するリソースの場所の推測的知識を伴わずに、接続されたランタイムにわたって、ワークロードの自動分散を可能にしてもよい。すなわち、プログラムレットの抽象プログラム形態は、ランタイムシステムが、プログラムを構造的に操作し、そのデータおよび計算を知的に配列および分散することを可能にし得る。プログラムレットは、ランタイムにおいて、以下の能力を可能にし得る:aデータの大きなチャンクを分割し、それらをランタイムシステム内の他のロケールにプッシュする、b固有並列が、再編成および利用され得るように、長い計算を分割する、cデータおよびコードローカリティを管理する例えば、データの大きなチャンクを分割し、それらを複数のノードにわたって拡散させる;非集計データを合体または統合する;長い計算をノードにわたって、タイミングをとり、スケジューリングする;データを複製、キャッシュ、および共有する;および/またはデータへの変更を伝搬することを含んでもよい、dリソース使用およびオーバーヘッドを追跡し、制限し、および/または優先順位をつける、eガーベッジコレクション、f解釈、動的コード生成、および関連付けられた状態の管理、および/またはアプリケーションの高レベル表現。分散型または多重スレッド化プログラムを作成時、遭遇し得る問題は、特に、配置、移行、および寿命の観点における、データの管理である。本ランタイムシステムの実施形態は、高レベルオブジェクト指向型システムを使用して、これらの懸念に対処することに役立ち、かつランタイムシステム、プログラマ、およびユーザによる、ランタイム動作を支援するための他の拡張機能を提供し得る。型は、それらの型が属するメモリ内のオブジェクトの具体的レイアウトを識別および記述するために使用され得る。型が、オブジェクトに属する場合、そのオブジェクトは、その型のインスタンスと言え得る。本発明の実施形態は、メモリ内のオブジェクトのレイアウトおよびそれらのオブジェクトとの潜在的相互作用を規定し得る、基本型と、基本型が有していなければならない型要件を記述する、統合型とを含む、異なる種々の型を確立し得る。基本型はさらに、オブジェクトのレイアウトおよび全許容される相互作用を完全に記述し得る、具象型と、レイアウトおよび許容される相互作用を部分的に記述し得るしたがって、具象型の一部としてではない限り、インスタンス化することができない、抽象型と、許容される相互作用のみ指定し、さらなる相互作用オーバーヘッドを要求するが、インスタンスオブジェクト内の付加的ストレージオーバーヘッドを要求しなくてもよい、インターフェース型とに分類され得る。実施形態は、型に関する付加的変形例をサポートしてもよい例えば、型の具象連結、結合、およびアレイ、より広い空間であるが、より少ない時間オーバーヘッドを伴う、フォームインターフェース型等。本発明の実施形態では、より基本的区別は、低レベルと高レベル型との間で行われ得る。低レベル型は、固定サイズ整数および実数等のプリミティブ型、アーキテクチャポインタ、ならびにアレイ、記録、および結合型におけるこれらの組み合わせを含んでもよい。対照的に、高レベル型は、メモリ内にある定義の明確であって、解読可能、かつ有限である形式を伴う、オブジェクトを記述する。高レベル型は、オブジェクト指向上位/下位クラス関係の従来の概念を拡張し得る、上位型関係によって、直接、ある数の他の高レベル型に関連し得る。型Tが、上位型の型Sまたは、同等に、Sは、下位型のTであるである場合、型Tと関連付けられた全ストレージおよび相互作用もまた、Sと関連付けられる。すなわち、実際は、これは、型Sのインスタンス毎に、Sによって、Tから継承されるストレージを参照する時に使用され得る、型Tのインスタンスを含有することを意味し得る。上位型/下位型関係に密接に関連するのは、割当可能関係である。型Tが、型Sに割当可能である場合、型Tのオブジェクトを参照するポインタ値は、型Sをポイントする変数に割り当てられてもよく、または換言すると、Sは、Tの上位型またはそれと同一型である。ステートメントSは、Tの下位型であるは、以下、象徴的に、と表され、ステートメントSは、Tに割当可能であるは、と表され得る。否定形態およびもまた、Sが、それぞれ、Tの下位型ではない、またはそれに割当可能ではないことを示すために使用され得る。下位型関係は、推移的であることに留意されたい。したがって、型R、S、およびTに対して、およびである場合、となる。ランタイムシステム内の高レベルオブジェクト毎に、関連付けられた高レベル型を有してもよく、本発明のランタイムシステムの実施形態における型毎に、ランタイム時に、任意のオブジェクトの型を検査するために使用することができる、メモリ内の関連付けられた型記述子オブジェクトを有してもよい。イントロスペクションは、プログラマに、後の検査のために、型の要素にネーム付けし、それをエクスポートする能力を提供する。加えて、第1のクラス型オブジェクトは、コンパイル時言語環境が、ランタイム時、任意に拡張され得る、かつプログラムコンポーネントの移行を簡略化し得るように動的に作成されてもよい。例えば、ホストAが、型Tを使用して、ホストBにワークをオフロードする必要がある場合、ホストBは、型Tのそれ自体のコピーを動的に取得し、再コンパイルまたは再開される必要なく、そのワークを行ってもよい。Bは、潜在的に、必要時、Aにフォワードバックされ得るが、その他の点では、TのホストAのバージョンと同じに見え得る、プロキシ型をさらに作成してもよい。イントロスペクションの別の層が、基本型-as-object層の上部に追加されてもよい。すなわち、各型オブジェクトは、オブジェクトの状態が、言語固有名を使用することによって、ランタイム時、アクセスされ得るように、型要素の記述を含んでもよい。これは、多くのスレッド化または分散型アプリケーションが、従来の二値イメージベースのデバッガが、ハンドリングすることができるものより高いレベルにおいて、デバッグすることを可能にし、アドレス空間とアプリケーションとの間のオブジェクトの機能性の分散を簡略化するのに役立ち得る。型システムの実施形態は、多様性、仮想インヘリタンス、および/またはインターフェース型をサポートし、C、C、およびJava登録商標等のプログラミング言語を使用して、既存のシステムとの完全相互運用性を可能にしてもよい。本発明のランタイムシステムの実施形態はまた、型統合をサポートしてもよく、複数の型が、型結合、交差、否定、および/または減算演算子を使用して、式中で組み合わせられてもよい。本発明の実施形態は、無限数のコンポーネント型を含んでもよいが、それらは、他の型に対して整合され、例えば、遠隔接続の両側が、通信を伴わずに、接続の他方側に向けたパラメータおよびリターン値を型チェックすることを可能にし得る、コンパクト表現を提供し得るため、必ずしも、統合型のインスタンスを作成可能にする能力を含むことが要求されなくてもよい。2つの特殊な高レベル型は、種々の実施形態によるランタイムシステム内に存在し得る、すなわち、AnyおよびVoidである。Anyは、ランタイムによって、インターフェース型として確立され、包括型ワイルドカードとして使用され、汎用セットとして、統合型式に関与し得るように、全他の高レベル型の上位型として作用してもよい。Voidは、全他の型の下位型として作用し、排他的ワイルドカードとして使用され、ヌル空のセットとして、統合型式に関与してもよい。Voidのインスタンスは、必然的に、全他の可能な型のインスタンスを含有するであろうため、型Voidに対する唯一の有効ポインタは、NULLであり得る。これは、任意の型へのポインタに割当可能として、NULLポインタ値を確立することに留意されたい。また、ランタイムソフトウェアの特定の実施形態は、特定のハードウェア/ソフトウェアロケールに対して、NULLポインタをサポートしてもよいことに留意されたい。例えば、小ローカルメモリ内で起動するハードウェアプロセッサコアは、そのNULLに対して、アドレス0を使用してもよいが、そのコア外からは、その同一アドレスは、[例えば]65,536のある倍数としてマップされてもよい。これは、NULLが、代替として、いずれのオブジェクトも全く参照しない、またはコードレットが含有するロケールと関連付けられたメモリ全体を参照することを可能にし得る。型システム内のAny、Void、および他の型間の関係は、図8aに示される。いくつかの実施形態では、型システムは、データパーティション化、コピー、シリアライゼーション、および/またはデシリアライゼーションルーチンの実装を許可、容易化、または向上させ得る。固定幅整数または実数等のプリミティブデータ型は、容易にコピーおよび移行され得るがバイト順にかかわらず、より高いレベル型は、それらと関連付けられた任意の量のコンテキストを有してもよく、それらのいずれも、オブジェクトが、異種アドレス空間間で移動される時、トランスポート、再構築、または破棄される必要がなくてもよい。インターフェース型CopyableおよびTransferableは、これらの目的のために使用されてもよく、Copyableは、同一アドレス空間内のオブジェクトを複製するために有用であり得、Transferableは、オブジェクトをバイトストリームに縮小するシリアル化、またはオブジェクトを生成されたストリームから再構成するデシリアル化ために有用であり得る。加えて、大きなアレイ、セット、またはマップ等のいくつかのオブジェクトを、相互に独立して使用され得る、断片にパーティション化することが望ましくあり得る。そのような構造は、Partitionableを実装し、インデックスとパーティションとの間に関数マッピングが与えられる場合、そのコンポーネントが、異なるリソースに割り当てられる、または異なるホストにプッシュされ得るように、分割されてもよい。Partitionableオブジェクトはまた、全てのインデックスが同一パーティションにマップされ得るように、それらに一定のインデックス-パーティションマッピングを与えることによって、パーティション化されずに残されてもよい。種々の実施形態による、型システムは、統合型の形態において、集合論的結合、交差、減算、および/または否定動作例えば、リソースに対する入力および出力制約を指定するための使用を可能にし得るが、その実装は、完全に記述されなくてもよいため、直接、それ自体、そのような型をインスタンス化可能でなくてもよい。統合型は、ランタイム時の型間の関係を判定するために使用され得る、メモリ内のデータ構造とともに記述されてもよい。統合型は、静的または動的に作成されてもよく、可能である時、縮小およびキャッシュされてもよく、これは、基本型等価チェックのための直接ポインタ比較を可能にし、未使用データ構造の蓄積を回避するのに役立ち得る。集合論的式に基づく型の判定をさらに検討すると、前述のように、は、型によって受け取られたオブジェクトのセットを組み合わせる、またはフィルタリングするために使用されてもよい。例えば、型Tおよび統合型UおよびVに対して、集合論におけるように、となる。同様に、となる。ある型はまた、別の型から減算されてもよい。すなわち、となる。最後に、Anyからの減算に相当する、型否定は、となるような型をもたらす。再び、集合論におけるように、、、、、、、、およびとなる。ドモルガンの法則の応用およびを含む、ブール代数変換は、これらのルールを使用して、統合型で行われ、例えば、型を内部表現のための特定の形態に縮小してもよい。ユーザ構築型は、複数の同じ上位型を含んでもよい。例えば、図8cに示されるように、型Q、R、S、およびTを前提とすると、Tの任意のインスタンスは、RおよびSのそのインスタンス内に各1つずつ、型Qの2つのインスタンスを含まなければならない。本発明の異なる実施形態は、異なる方法において、そのような型内で型変換を行ってもよい。例えば、ランタイムは、RまたはSの個別のインスタンス内に含有されるインスタンスを選択することによる、RまたはSからQへの型変換を除いて、QのRのインスタンスを選択することによって、型TからQに全型変換を実装してもよい。しかしながら、実装仕様にかかわらず、型のデータの実際の構造に関して把握しているプログラムは、依然として、直接、全上位型インスタンスにアクセスしてもよい。前述の型システムは、いくつかの実施形態では、Cプログラミング言語において見られるv-tableアプローチの拡張機能を使用して、実装されてもよい。本アプローチでは、任意の高レベルオブジェクトのメモリイメージは、オブジェクトが有する任意の上位型を含む、オブジェクトの型を記述する、テーブルへのポインタから始まる。加えて、v-tableは、仮想メソッドおよびコードレット実装、ならびに他の型関連データ例えば、その値が、その型に特有であるが、その下位型にはそうではない、型の全インスタンス間で共有される変数へのポインタを含んでもよい。各高レベル型は、それと関連付けられたそのような型データテーブルの1つを有してもよく、その型の全インスタンスは、そのメモリイメージ内でそれを参照してもよい。さらに、このような型テーブルは、本発明のいくつかの実施形態では、統合型式ならびに具象型情報を表すために使用されてもよい。型階層内のポインタ型間で変換時、型変換の種々の形態が、正しいポインタが使用されることを確実にするために使用されてもよい。もたらされる最も単純な型変換は、下位型へのポインタから、上位型へのポインタへの型変換である、アップキャストである。実施例として、図8cからの型を使用すると、型Rへのポインタから型Qへのポインタへの型変換は、アーキテクチャポインタの幅だけ、Rインスタンスのアドレスをオフセットすることによって、または、プログラミング言語内において、適切な上位型インスタンスのアドレスをとることによって例えば、Cにおけるptr->super、行われてもよい。同じことは、型階層内の任意の数のレベルを上方型変換するために行われてもよい。すなわち、TからQの型変換は、TからR、次いで、RからQ、または代替として、TからS、次いで、SからQへの型変換によってもたらされてもよい。上位型から下位型への型変換例えば、QからR、あるいはRまたはSからT、またはダウンキャストは、アップキャストを反転する概して、加算する代わりに、オフセットを減算することによって行われてもよい。下位型の上位型または上位型の下位型への型変換クロスキャスト;例えば、RからS、これは、Tのインスタンス内で行われるは、連続的に、2つの方法を組み合わせることによって行われてもよい例えば、RからQ、そこからS。そのような型変換は、その結果を予測可能なコンパイラによって静的に、または本発明を具現化するソフトウェアによって動的にのいずれかにおいて、適用されてもよい。動的型変換は、各型の型データテーブル内に記憶されたデータを利用して、正しいオフセットを判定し、ポインタに適用してもよい。ランタイムの実施形態は、であるときに、型Sのオブジェクトを型Tに型変換しようとした場合、エラーを生成してもよい例えば、関数リターン値、ネイティブ例外ハンドリング機構、またはコードレットのキャンセルフォークを介して。本発明のランタイムシステムの実施形態における高レベルオブジェクトは、動的に追加、除去、または修正され得、かつオブジェクトとともに移行し得る、それに付随する任意のデータを有してもよい。コンテキストセンシティブおよびコンテキスト非センシティブデータは、オブジェクトに関するサイドバンドコメントとして作用し得る、タグを作成することによって、動的にオブジェクトに付随されてもよい。タグは、特定のオブジェクトが配置されるべき場所、コードレットが起動することが予期され得る時間、あるいはコードレットに対して好ましいまたは有益であり得る、環境への修正等、ランタイムにヒントを提供するために使用されてもよい。それらはまた、オブジェクトの配置または使用履歴の記録等、オブジェクトを使用するアプリケーションコンポーネント間に、第三者通信チャネルをもたらすために使用されてもよい。本発明のランタイムシステムの実施形態の種々の態様は、とりわけ、多くのスレッドおよび/またはノードにわたって、プログラム状態を追跡するために、監視および制御能力とともに実装されてもよい。ランタイムシステムのコンポーネントは、情報が、可能性として、ほぼリアルタイムにおいて、抽出、ログ、集約、表示され得るように、高レベルステータスインターフェースを具備してもよい。スケジューラはまた、例えば、複数のノードにわたって、単一スレッド、スレッドグループ、またはランタイムシステム全体の保留および検査を可能にし得る、集積制御インターフェースを具備してもよい。監視フロントエンドもまた、ランタイムシステムと相互作用するために提供されてもよい。ランタイムシステムの実施形態におけるコンポーネントは、ランタイムへのパブリックインターフェース定義のレジストレーションによって、モニタに可視となってもよい。これは、たとえそうであったとしても、ランタイムシステムに、コンポーネントによって提供されるステータス出力、ならびにそれらの出力内のデータの形式およびデータが集約または収集され得る方法を把握させる役割を果たし得る。ステータスインターフェースは、モニタシステムがそれと相互作用し得る方法を判定するために、前述の型システムに依存し得る。例えば、更新頻度、集約のスタイル、収集のスタイル、フォーマッティング、ラベリング、および/または場所情報等のパラメータが、型インターフェースを通して、提供されてもよい。カウンタ、タイマ、および/または列挙ビットセット等のビルトイン型の好適なセットが、ステータスインターフェースの迅速かつ容易な追加を可能にするために提供されてもよいが、ユーザ構築ステータス型も同様に、追加されてもよい。ランタイムシステムの実施形態におけるオブジェクトは、モニタが、その実行を動的に制御することを可能にし得る、制御オブジェクトをレジスタ可能にしてもよい。例えば、スケジューラは、スケジューリングが、ジョブ間で停止または開始することを可能にし、かつ具体的ジョブをスケジューリングから免除させることを可能にし得る、制御オブジェクトをレジスタしてもよい。試験インターフェースもまた、コンポーネントが、具体的タスクを行うことを可能にし得るように実装され、その結果が検査されてもよい。制御入力は、特殊モニタスレッドにおいて、アプリケーション特有コードの実行を生じさせ得る例えば、コールバック関数を介して、ローカルモニタインターフェースを使用して、促進されてもよい。これは、コールバックと、それらが影響を及ぼすオブジェクトとの間の同期を伴ってもよいが、ほとんどの制御コールバックは、単に、フラグを設定する、または最終的に、制御されたオブジェクトによって見られ得る、情報を上書きしてもよい。監視フロントエンドは、ランタイムシステム内からサーブされるソケットを介して、ランタイムシステムバックエンドに接続してもよい。バックエンドは、レジスタされた型、個々および集約ステータス情報、および/または制御情報への直接アクセスを可能にし、かつ潜在的に、遠隔ノードへの接続、リソースの作成/破壊/それとの相互作用、および/または作動可能ジョブのキル等、基本ランタイムタスクを可能にし得る。いくつかの実施形態では、バックエンドは、デバッガをランタイムシステム上で開始可能にし得る、フックを提供してもよく、したがって、フロントエンドがこれを行う必要性を排除または縮小させ、潜在的に、フロントエンドアクセスが制限され得る、複数の遠隔ノードに、初期化を分散し得る。本発明の種々の実施形態は、適切なインターフェースでラップされ、システムリソース上のコードコンポーネントとして使用される、システムの所与の実装とのリンカ/ローダレベルバイナリ互換性を有する、外部関数を可能にし得る。ランタイムシステム自体は、APIとして使用するためのコードとリンクされ得る、静的または動的ライブラリとして具現化されてもよく、あるいはライブラリにリンクされた実行可能ファイルとして具現化されてもよい。本後者の形態は、ランタイムシステムをオペレーティングシステムによってアプリケーションコンポーネントに適用可能にし、かつランタイムシステムをノードレットおよび/またはプログラムレットと併用するための受動的サービスとして開始可能にし得る。本発明の種々の実施形態は、以下のようにメモリ配分規範を組み込んでもよい。参照によってランタイムインターフェース関数にパスされた値は、ランタイムインターフェースではなく、発呼側によって管理されてもよい。それらは、少なくとも、コールされたインターフェース関数が返すまで、存在したままであってもよく、ランタイムシステムが、そのような値を留保しなければならない場合、それらは、ランタイムシステムによってコピーされ、内部に留保/管理されてもよい。Non-Copyableオブジェクトは、可能である場合、コピーされるのではなく、性能に影響を及ぼさずに、間接的に参照される必要があってもよい。参照によってランタイムインターフェースからコードレットにパスされた入力値は、インターフェースにパスされた値と同様に扱われてもよい。そのような値のためのメモリが、明示的に管理されなければならない場合、チェーンペアは、その入力とともに、コードレットにパスされてもよい。すなわち、チェーンコードレットが起動されると、参照値に対する責任は、入力内で元々パスしたエンティティに返されたとみなされ得る関数コールからのリターンに関して。値が、その時点後に必要とされる場合、入力を受信するコードレットは、入力を例えば、そのコンテキストにコピーしなければならない。参照によってランタイムシステムから返された値は、3つカテゴリのうちの1つに分類され得る:1そのメモリが、もはやアクティブ使用中ではない時に解放される必要がない、静的またはスレッド-ローカルデータ、2含有オブジェクトがこれらのカテゴリの1つに分類され、かつそのデータのストレージが、コンテナの残留寿命に対して配分されたままである限り、含有オブジェクトと関連付けられるデータ、または3明示的に管理されるメモリおよび状態例えば、createおよびdestroyインターフェース関数を介して。本発明が、特に、本明細書に図示および前述されたものに制限されるわけではないことは、当業者によって理解されるであろう。むしろ、本発明の範囲は、本明細書に前述される種々の特徴の組み合わせおよび部分的組み合わせ、ならびに前述の説明を熟読することによって、当業者に想起され、先行技術にはない、修正および変形例の両方を含む。"