JP6273294B2 - 共有およびマネージド・メモリー統一アクセス - Google Patents

Description

[0001] コンピューターのオペレーティング・システムの性能は、当該オペレーティング・システムが所与の時間間隔にわたって維持することができる入力／出力（Ｉ／Ｏ）動作の最大レートによって特徴付けられることが多い（「Ｉ／Ｏ性能」とも呼ばれる）。その結果、オペレーティング・システムは、Ｉ／Ｏ性能を高めるために、種々の周知のメカニズムを採用する。

[0002] オペレーティング・システムは、従前より、アンマネージド言語(unmanaged language)（アセンブリ言語、Ｃ、Ｃ＋＋のような）を使用して書かれる。アンマネージド言語は、システム・プログラマーに、どのようにメモリーを操作するかについて非常に細かい制御を行わせる。未チェック・ポインター(unchecked pointer)の使用は、オペレーティング・システムのオーバーヘッドを最小限にし、スループット向上またはレイテンシ短縮を可能にするために使用することができる。これら未チェック・ポインターの使用の欠点は、作成し推論することが難しく、ソフトウェアの信頼性低下やセキュリティの脆弱さに繋がる。

[0003] マネージド・プログラミング言語(managed programming language)でソフトウェアを書くと、非常に正確であるという利点および開発時間の効率の良さが得られる。これらのマネージド言語は、プログラマーが多くの種類のソフトウェア欠陥を作るのを防止し、ソフトウェア品質の向上、および開発時間の短縮に繋がる。オペレーティング・システムの正確さは、信頼性があり安全な計算体験を提案する(deliver)ために肝要な成分である。したがって、マネージド言語を使用してオペレーティング・システムを作成することは、説得力のある提案である。何故なら、オペレーティング・システムの信頼性を向上させることができ、開発コストを削減することができるからである。

[0004] これらの利益を得るために、マネージド・プログラミング言語は、プログラマーによって草稿されたソース・コードと物理コンピューター・システムの生の機械リソースとの間に、抽象レイヤを挿入する。この抽象レイヤは、一般に、プログラマーが書くことを許されるものを制約する役割を果たし、そうすることによって、全カテゴリーの潜在的欠陥を排除する。生憎、この抽象レイヤは、作成されるソフトウェアの性能を阻害するおそれがあるオーバーヘッドを招く。その結果、マネージド言語は、正確さの欠陥と性能の欠陥の折り合いを付けるという共通の仮定がある。したがって、マネージド言語で書かれたソフトウェアは、多くの場合、アンマネージド言語で書かれたソフトウェアよりも、本質的に遅いと見なされる。

[0005] マネージド・コード・オペレーティング・システムに影響を及ぼす特有の問題は、データーがシステム全域にわたって移動するときに、レイヤ間でデーターをコピーすることが本質的に必要なことである。これは、システムの別個のコンポーネントが異なる分離コンテキスト(isolation context)内に存在し、これらの分離コンテキストを解析する(break out of)明白なメカニズムがないという事実によって、誘発される。

[0006] 本明細書において説明する少なくとも１つの実施形態によれば、システムは、マネージド・メモリーを有し、多数の計算エンティティが、各々、このマネージド・メモリーにおいて、対応するエンティティ特定マネージド・メモリー部分を有し、これにはガベージ・コレクションが起こる。インミュータブル・バッファが、マネージド・メモリーの外側に配置される。所与の計算エンティティに対して、対応するマネージド・メモリー部分は、特定の計算エンティティによってアクセスすることができるが、それら自体のエンティティ特定マネージド・メモリー部分を有する他の多数の計算エンティティによってはアクセスすることができない、１つ以上のエンティティ特定オブジェクトを収容する。

[0007] エンティティ特定マネージド・メモリー部分の１つ以上に対して、この部分は共有メモリーに対する参照も含む。一実施形態では、この共有メモリーは、インミュータブル・バッファであってもよい。この参照は、ガベージ・コレクターによって無視されるような構造に作られるが、この参照は、マネージド・メモリー部分における通常のオブジェクトのように現れることができる。例えば、恐らく、参照はアレイ・エレメントである。しかしながら、ガベージ・コレクターは、他のオブジェクトとこの参照との間で区別することができる。一例として、ガベージ・コレクターは、このアレイ内のアドレスを探すことができ、そのアドレスがマネージド・メモリーの外側にある位置である場合、ガベージ・コレクターは、この参照に対してガベージ・コレクションを実行しない。

[0008] したがって、統一メモリー・アクセス・モデルが可能になり、計算エンティティがマネージド・メモリーにおいて正規のオブジェクトにアクセスするための方法が、計算エンティティが共有メモリーにアクセスする様相と同様になる。この摘要は、特許請求する主題の主要な特徴や必須の特徴を特定することを意図するのではなく、特許請求する主題の範囲を判断するときに補助として用いられることを意図するのでもない。

[0009] 以上で挙げたそして他の利点および特徴を得ることができる様態について説明するために、種々の実施形態の更に特定的な説明を、添付図面を参照して行う。これらの図面は見本の実施形態のみを描画し、したがって本発明の範囲を限定するように解釈すべきでないことを理解した上で、添付図面の使用により、更に具体的にそして詳細に実施形態について説明する(described and explained)。
図１は、本明細書において説明する実施形態を採用することができる計算システムを抽象的に示す。 図２は、インミュータブル・バッファを設ける方法のフローチャートを示す。 図３Ａは、バッファに収容する(populate)プロセスが行われる環境を示す。 図３Ｂは、収容されたバッファをインミュータブルにする環境を示す。 図４は、インミュータブル・バッファを使用する方法のフローチャートを示す。 図５は、異なる計算エンティティがインミュータブル・バッファに対して異なるビューを有する環境を示す。 図６は、インミュータブル・データーを計算エンティティ間で伝える方法のフローチャートを示す。 図７は、データーのストリームがストリーム・ソースからストリーム・バッファに供給され、次いでバッファからストリーム・コンシューマーに供給される、ストリーミング環境を示す。 図８は、第２計算エンティティが、第１計算エンティティのキャッシュを通じてキャッシュを取得する環境を示す。 図９は、第２計算エンティティが最初に第１計算エンティティによってサポートされるキャッシュから読み出す方法のフローチャートを示す。 図１０は、第２計算エンティティが次に第１計算エンティティによってサポートされるキャッシュから読み出す方法のフローチャートを示す。 図１１は、第１計算エンティティ（またはバッキング・キャッシュ）が削除を実行する方法のフローチャートを示す。 図１２は、マネージド・コード・システムの一例を示す。 図１３は、通常のマネージド・バイト・アレイを示す。このアレイは、その内部を指し示す２つの別個のスパンを有し、アプリケーションがアレイの複数の部分を異なる型として見なすことを可能にする。

[0024] 本明細書において説明する実施形態によれば、マネージド・オペレーティング・システムにおいてゼロ−コピー入力／出力（Ｉ／Ｏ）セマンティクスを促進するメカニズムについて説明する。このようなメカニズムの一部は、マネージド・コード・オペレーティング・システムにおいてだけでなく、アンマネージド・コード・オペレーティング・システムにおいても使用することができる。これらのメカニズムは、更に一層ゼロ−コピーＩ／Ｏセマンティクスを促進するために、その内の１つ、一部、または全部でさえも組み合わせることができるので、相互に排他的ではない。

[0025] 「ゼロ−コピー」とは、データーをコピーする必要なく、メモリーに書き込まれ多くの抽象レイヤを伝搬することによって、このデーターがシステムに入ることを可能にするように設計されたアーキテクチャーを指す。ゼロ−コピー・アーキテクチャーは、データー・コピーが行われないことを保証するのではない。むしろ、これは、殆どのＩ／Ｏ動作を、コピーすることなく、行うことができることを保証するメカニズムを、単に適所に置くに過ぎない。この説明および特許請求の範囲では、「メモリー」とは、任意のランダム・アクセス・メモリーと定め、通例揮発性メモリーであるが、不揮発性部分を含むこともでき、あるいは、恐らくは、全体的に不揮発性であってもよい。この説明および特許請求の範囲では、「メモリー」とは、計算システムの主要記憶媒体と定め、計算システムのマイクロプロセッサーにアクセス可能な、そしてグラフィクス・コントローラのようなハードウェア・デバイスまたはネットワーク・インターフェース・コントローラに、ＤＭＡ（直接メモリー・アクセス）メカニズムを介して、アクセス可能な、個々にアドレス可能な位置で構成される。

[0026] 最初に、共有データーのインミュータブル・バッファを使用するインミュータブル共有可能ゼロ−コピー・バルク・データー・メカニズムについて説明する。このようなメカニズムは、コピーすることなく、計算システム全域にわたるデーターの大きなバッファの転送を可能にする。このメカニズムは、更に、効率的なリソース利用を可能にするための完全なフロー制御によって、全て完全なゼロ−コピー・セマンティクスを維持しつつ、計算システム内におけるデーター・ストリームの共有使用に拡張される。マネージド・コード・システムの現在のタイプ・セーフの方が、これらのメカニズムの即座実現を可能にするが、アンマネージド・コード・システムにおけるこれらのメカニズムの使用も同様に採用することができる。

[0027] 第２に、ゼロ−コピー・キャッシングのメカニズムについて説明する。このようなゼロ−コピー・キャッシングは、アンマネージド・コード・システムおよびマネージド・コード・システム双方において採用することができる。ゼロ−コピー・キャッシングは、キャッシュに入るデーター、およびキャッシュから戻されるデーターに対するゼロ−コピー・セマンティクスを特徴とする汎用キャッシング・アーキテクチャーを作成することを可能にする。

[0028] 第３に、マネージド・コード・システムがインミュータブル・バッファまたは共有データーを採用するか否かには関わらず、これらのシステムの性能を更に高める様々なメカニズムについて説明する。このようなマネージド・コード・メカニズムは、均一メモリー・アクセスおよびタイプ・セーフ型キャスト(type-safe type casting) を含む。均一メモリー・アクセスは、マネージド・コードが、一貫性があり組立可能な手法を使用して、マネージド・メモリーおよびアンマネージド・メモリー（Ｉ／Ｏバッファに使用される）双方に均一にアクセスすることを可能にする。タイプ−セーフ型キャストは、マネージド・コードが、完全なタイプ・セーフを維持しつつ、メモリーの所与の領域を別個の型として見ることを可能にするために、ポインター・キャスティング(pointer casting)を実行することを可能にする。

[0029] 計算システムの予備的論述について図１に関して説明する。次いで、以上で列挙したメカニズムを、図２〜図１３に関して、以上で示した順序で説明する。

[0030] 計算システムは、現在、増々多種多様な形態を取りつつある。計算システムは、例えば、ハンドヘルド・デバイス、アプライアンス、ラップトップ・コンピューター、デスクトップ・コンピューター、メインフレーム、分散型計算システム、または従来では計算システムとは見なされていなかったデバイスであってもよい。この説明および特許請求の範囲では、「計算システム」という用語は、少なくとも１つの物理的かつ有形プロセッサーと、このプロセッサーによって実行することができるコンピューター実行可能命令を有することができる物理的かつ有形メモリーとを含む任意のデバイスまたはシステム（あるいはその組み合わせ）を含むように、広義に定められることとする。メモリーは、任意の形態を取ることができ、計算システムの性質および形態に依存してもよい。計算システムは、ネットワーク環境にわたって分散されてもよく、更に多数の要素計算システムを含んでもよい。

[0031] 図１に示すように、その最も基本的な構成において、計算システム１００は、少なくとも１つの処理ユニット１０２と、コンピューター読み取り可能媒体１０４とを含む。コンピューター読み取り可能媒体１０４は、概念的に、物理システム・メモリーを含むと考えることができ、揮発性、不揮発性、またはこれら２つの何らかの組み合わせであってもよい。また、コンピューター読み取り可能媒体１０４は、概念的に、不揮発性大容量ストレージも含む。計算システムが分散される場合、処理、メモリー、および／または記憶能力も同様に分散されてよい。

[0032] 本明細書において使用する場合、「実行可能モジュール」または「実行可能コンポーネント」という用語は、計算システム上で実行することができるソフトウェア・オブジェクト、ルーティング(routing)、またはメソッドを指すことができる。本明細書において説明する異なるコンポーネント、モジュール、エンジン、およびサービスは、計算システム上で実行するオブジェクトまたはプロセスとして（例えば、別個のスレッドとして）実装することができる。このような実行可能モジュールは、マネージド環境において実行される場合、マネージド・コードにすることができ、マネージド環境ではタイプ・セーフが強制され、プロセスはそれら自体の別個のメモリー・オブジェクトが割り当てられる。このような実行可能モジュールは、ＣまたはＣ＋＋のようなネーティブ・コードで著作された実行可能モジュールの場合、アンマネージド・コードであってもよい。

[0033] 以下に続く説明では、１つ以上の計算システムによって実行されるアクトを参照しながら、実施形態について説明する。このようなアクトがソフトウェアで実現される場合、そのアクトを実行する関連計算システムの１つ以上のプロセッサーは、コンピューター実行可能命令を実行したことに応答して、計算システムの動作を命令する。例えば、このようなコンピューター実行可能命令は、コンピューター・プログラム製品を形成する１つ以上のコンピューター読み取り可能媒体上に具体化することができる。このような動作の一例は、データーの操作を伴う。コンピューター実行可能命令（および操作されるデーター）は、計算システム１００のメモリー１０４に格納することができる。また、計算システム１００は、通信チャネル１０８も内蔵することができ、通信チャネル１０８は、計算システム１００が、例えば、ネットワーク１１０を通じて、他のプロセッサーと通信することを可能にする。

[0034] 以下で更に詳しく論ずるように、本明細書において説明する実施形態は、例えば、１つ以上のプロセッサーおよびシステム・メモリーのようなコンピューター・ハードウェアを含む特殊目的または汎用コンピューターを含むまたは利用することができる。また、本明細書において説明する実施形態は、コンピューター実行可能命令および／またはデーター構造を搬送または格納するために、物理コンピューター読み取り可能媒体および他のコンピューター読み取り可能媒体も含む。このようなコンピューター読み取り可能媒体は、汎用または特殊目的コンピューター・システムによってアクセスすることができる、任意の入手可能な媒体とすることができる。コンピューター実行可能命令を格納するコンピューター読み取り可能媒体は、物理記憶媒体である。コンピューター実行可能命令を搬送するコンピューター読み取り可能媒体は、送信媒体である。つまり、一例として、そして限定ではなく、本発明の実施形態は、少なくとも２つの全く異なる種類のコンピューター読み取り可能媒体、即ち、コンピューター記憶媒体および送信媒体を含むことができる。

[0035] コンピューター記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭまたは他の光ディスク・ストレージ、磁気ディスク・ストレージまたは他の磁気記憶デバイス、あるいはコンピューター実行可能命令またはデーター構造の形態で所望のプログラム・コード手段を格納するために使用することができ、汎用または特殊目的コンピューターによってアクセスすることができる任意の他の有形記憶媒体を含む。

[0036] 「ネットワーク」とは、コンピューター・システムおよび／またはモジュールおよび／または他の電子デバイス間における電子データーの移送を可能にする１つ以上のデーター・リンクと定められる。ネットワークまたは他の通信接続（ハードワイヤ、ワイヤレス、あるいはハードワイヤまたはワイヤレスの組み合わせ）を介して情報がコンピューターに転送または供給されるとき、このコンピューターがこの接続を送信媒体と見なすことは適正である。送信媒体は、所望のプログラム・コード手段をコンピューター実行可能命令またはデーター構造の形態で搬送するために使用することができ、汎用または特殊目的コンピューターによってアクセスすることができるネットワークおよび／またはデーター・リンクを含むことができる。以上のものの組み合わせも、コンピューター読み取り可能媒体の範囲内に含まれる。

[0037] 更に、種々のコンピューター・システム・コンポーネントに到達したとき、コンピューター実行可能命令またはデーター構造の形態であるプログラム・コード手段を自動的に送信媒体からコンピューター記憶媒体に（またはその逆）に転送することができる。例えば、ネットワークまたはデーター・リンクを介して受信されたコンピューター実行可能命令またはデーター構造は、ネットワーク・インターフェース・コントローラ（例えば、「ＮＩＣ」）内にあるＲＡＭにバッファすることができ、次いで最終的にコンピューター・システムのＲＡＭおよび／またはコンピューター・システムにおける、もっと揮発性が少ないコンピューター記憶媒体に転送することができる。このように、コンピューター記憶媒体は、送信媒体も利用する（または主に利用する場合であっても）コンピューター・システム・コンポーネントに含むことができることは、理解されてしかるべきである。

[0038] コンピューター実行可能命令は、例えば、命令およびデーターを含み、プロセッサーにおいて実行されると、汎用コンピューター、特殊目的コンピューター、または特殊目的処理デバイスに、一定の機能または機能の一群を実行させる。コンピューター実行可能命令は、例えば、バイナリー、アセンブリ言語のような中間フォーマット命令、またはソース・コードであってもよい。主題について、構造的特徴および／または方法論的アクトに特定な文言で説明したが、添付する特許請求の範囲において定められる主題は必ずしも説明した特徴や以上で説明したアクトには限定されないことは理解されてしかるべきである。逆に、説明した特徴およびアクトは、特許請求の範囲を実現する形態例として開示される。

[0039] 当業者は、多くのタイプのコンピューター・システム構成を有するネットワーク計算環境において本発明が実施されてもよいことを認めよう。多くのタイプのコンピューター・システム構成には、パーソナル・コンピューター、デスクトップ・コンピューター、ラップトップ・コンピューター、メッセージ・プロセッサー、ハンドヘルド・デバイス、マルチプロセッサー・システム、マイクロプロセッサー・ベースまたはプログラマーブル消費者用電子機器、ネットワークＰＣ、ミニコンピューター、メインフレーム・コンピューター、移動体電話機、ＰＤＡ、ページャー、ルーター、スイッチ等が含まれる。本発明は、分散型システム環境において実施することもでき、ネットワークを介してリンクされたローカルおよびリモート・コンピューター・システム（ハードワイヤ結合データー・リンク、ワイヤレス・データー・リンク、またはハードワイヤ結合およびワイヤレス・データー・リンクの組み合わせのいずれかによって）、双方ともタスクを実行する。分散型システム環境では、プログラム・モジュールはローカルおよびリモート双方のメモリー記憶デバイスに配置されてもよい。
インミュータブル共有可能ゼロ−コピー・バルク・データー
[0040] ゼロ−コピーをサポートするための主要な課題は、システムにおける異なるレイヤ間のコピー動作として定義される、従前のシステムにおけるＩ／Ｏインターフェースであった。リード・アプリケーション・プログラム・インターフェース（ＡＰＩ）は、アプリケーション・バッファを入力として受け入れ、あるデーター・ソースからのデーターでそれを満たす。同様に、ライトＡＰＩもアプリケーション・バッファを取得し、その内容を何らかのデーター・ターゲットに書き込む。リード／ライトＡＰＩのセマンティクスは、バッファの境界合せ(alignment)、割り当て空間、および保持に対する完全な自由をアプリケーションに付与する。この単純なモデルは、このモデルが不連続バッファを表現することも、データー・コピー動作の回数を減らすこともできないという、様々な本質的な欠点(limitation)を有する。

[0041] 多くのオペレーティング・システムは、メモリー・マッピングされたファイルを、ファイル・システムのバッファ・キャッシュにおけるページをアプリケーションと共有するため、そしてリード／ライト・インターフェースに関連するコピー動作を回避するためのメカニズムとしてサポートする。ネットワーク・トラフィックを高速化するためにファイル・メモリー−マッピングを使用して、データーを直接ファイル・システムのバッファ・キャッシュから送る特殊なＡＰＩがネットワーク・インターフェースに追加されている。

[0042] メモリー・マップ・ファイル抽象化は、バッファの基礎をなす境界合わせおよびスパース・レイアウトを隠すサポートを欠き、アプリケーションに、仮想マッピングおよび論理データー・ビューを直接処理し管理することを要求する。例えば、オフセット１０におけるファイルにアクセスするアプリケーションは、正しいアドレスを導き出すために、マッピング・ベース仮想アドレスに対してポインターの算術演算(pointer-arithmetic)を適用する必要がある。ファイルがマッピングされたままそれを拡張するには、アプリケーションが、アドレス空間において必ずしも連続でないかもしれない追加のビューを管理しなければならず、アプリケーションによってクロス・ビュー・アクセス(cross view access)を処理する必要がある。

[0043] メモリー・マップ・ファイルを介するデーター・コピーを回避することには、他の欠点がある。メモリー・マップ・ファイルとリード／ライト動作との間でセマンティックの一貫性を確保するためには、Ｉ／Ｏ、メモリー、およびファイル・システム間において複雑な調整が必要となる。メモリー・マップＩ／Ｏでは、同期完了のオーバーヘッドが負わされる。何故なら、ファイル領域にマッピングする仮想アドレスにおけるページ・フォールト・ミスが、物理メモリーにおいてそのページが入手可能になるまで、スレッドを停止させるからである。

[0044] コピー−オン−ライト仮想メモリー技法も、コピー動作のコストを隠すために使用されている。これらのコピー−オン−ライト技法は、アプリケーションが入力バッファを適切に修正することは希であるという仮定に基づいて、アプリケーションおよびバッファ・キャッシュ・ページのエイリアスを作る。これは、ファイル・システムに、コピーせずに同じ物理ページをキャッシュする機会を与える。あるワークロードでは、この最適化は、特に、アプリケーションおよびストレージ・スタックが異なる保護ドメインにあるときに、かなりの複雑さを犠牲にしてコピー動作を回避することができる。仮想メモリー・ページ−リマッピングのような他の技法は、アプリケーション・バッファが適正に境界分けされているとき、一定の条件の下で、ネットワーク受信経路には有用である。

[0045] 図２は、インミュータブル・バッファを設ける方法２００のフローチャートを示す。図３Ａは、バッファに収容する(populate)プロセスが行われる環境３００Ａを示す。図３Ｂは、収容されたバッファをインミュータブルにする環境３００Ｂを示す。したがって、これより図２の方法２００について、図３Ａおよび図３Ｂを頻繁に参照しながら説明する。環境３００Ａおよび３００Ｂは、図１の計算システム１００内において出現することができるが、そうでなければならないのではない。環境３００Ａおよび３００Ｂは、分散されても、１つの計算システム上に配置されてもよい。

[0046] バッファに収容するために使用されようとするソース・データーに、最初に取得する側の計算エンティティがアクセスする（アクト２１０）。このソース・データーは任意のデーターでよいが、一実施形態では、ソース・データーは、生成するためにかなりの計算リソースを必要とする大量のバルク・データーを含む。この説明および特許請求の範囲において、「計算エンティティ」とは、計算システム内においてデーターを処理することができる任意のコンポーネント、モジュール、メソッド、関数、プロセス、プロセッサー、またはその任意の組み合わせである。このような計算エンティティは、分散されても、１つのコンピューター上に存在してもよい。

[0047] 取得側の計算エンティティは、ソース・データーの全部または一部を生成することができる（アクト２１１）。代わりにまたは加えて、取得側の計算エンティティは、ソース・データーの全部または一部をデーター・ソースから取得してもよい（アクト２１２）。例えば、図３Ａを参照すると、取得側の計算エンティティ３２０は、ソース・データー３１１をデーター・ソース３１０から取得する（矢印３０１で表されるように）。データー・ソースは、例えば、ネットワーク、またはディスクのような不揮発性記憶デバイスでもよい。

[0048] 取得側計算エンティティは、バッファも取得する（アクト２２０）。このバッファ取得（２２０）は、ソース・データーの取得（アクト２１０）と並列に示されている。これは、本明細書において説明する原理の最も広い態様では、どちらのアクトも最初に行われる必要がないからである。しかしながら、あるシステムでは、一方が他方の前に必要とされる場合もあり、および／またはこれらのアクトが少なくとも部分的に同時に行われることもあり得る。図３Ａを参照すると、取得側の計算エンティティ３２０は、この取得側計算エンティティが次いでバッファ３３０にデーターを収容するのに限って、バッファ３３０を取得する。

[0049] 取得側計算エンティティがソース・データーを生成するか、またはソース・データーをデーター・ソースから受けるか、あるいは双方かには関係なく、取得側の計算エンティティは、バッファにデーターを収容する（アクト２３０）。図３Ａを参照すると、例えば、取得側の計算エンティティ３２０は、データー３１１をバッファ３３０に収容する（矢印３０２によって表されるように）。

[0050] 次いで、バッファをインミュータブルに分類する（アクト２４０）。図３Ｂは、図３Ａの環境３００Ａと同様であるが、データー３１１がバッファ３３０内に確保されて(secured)示されることを除く、環境３００Ｂを示す。バッファ３３０は、陰影が付いた境界３３１を有することが示され、抽象的に、このバッファ３３０がインミュータブルであることを表す。この分類は、インミュータブル・バッファ（例えば、図３Ｂにおけるバッファ３３０）内に収容されたデーター（例えば、データー３１１）が、このインミュータブル・バッファの寿命の間変化することから保護し、更にインミュータブル・バッファが、当該インミュータブル・バッファの寿命の間その物理アドレスが変化させられるのを保護する。このインミュータブルな特性のために、インミュータブルなデーターへのアクセスは、衝突のリスクなく、任意の数の計算エンティティに与えることができる。何故なら、これらの計算エンティティの各々は単にデーターを観察することしかできないからである。

[0051] ネーティブ言語環境（ＣまたはＣ＋＋のような）では、このインミュータブル性は、プロセッサーが一定の範囲のメモリーに書き込むのを制限するように、プロセッサーのメモリー管理ユニット（ＭＭＵ）に書き込むことによって得ることができる。これは、非常に高負荷(expensive)になるおそれがあり、メモリー・アクセスに対する制約は、さほど細かくなく、多くの場合比較的大きなページ・レベルで行われる。更に、これは、高負荷な動作になるおそれがあり、ページ・レベルよりも小さい粒度で異なるレベルからのデーターを隠すために、コピーが行われる状況を避けられない。

[0052] マネージド環境（マネージド・ランタイムを含む環境）では、メモリーをインミュータブルであると宣言し、インミュータブル性を施行するためにソフトウェアが使用される。更に、メモリー・バッファの寿命は、使用カウントによって維持することができる。使用カウントは、メモリーへの新たなポインターがエンティティに与えられると増加し、メモリーへのポインターがもはやエンティティによって使用されなくなったときに減少する。使用カウンターがゼロに戻ると、バッファには到達できなくなり、メモリー・マネージャによって取り戻すことができる。一実施形態では、カーネルが、メモリーにアクセスする許可を異なるエンティティに付与し、使用カウンターを維持するが、マネージド・ランタイムは、インミュータブル・メモリー上にビューを設け、インミュータブル性を施行し、データーに対する制約を課する。マネージド環境に関しては、更に図１２に関して以下で説明する。

[0053] 図４は、インミュータブル・バッファを使用する方法のフローチャートを示す。最初に、ビュー・コンポーネントがインミュータブル・バッファ上にフレキシブル・ビューを設け（アクト４０１）、次いでこのビューを適宜インミュータブル・バッファの異なるコンシューマー(consumer)に提供する（アクト４０２）。次いで、計算エンティティは、そのそれぞれのビューを介してのみ、インミュータブル・バッファにアクセスすることができる（アクト４０３）。例えば、図５の環境５００を参照すると、第１計算エンティティ５０１が第１ビュー５１１を介してインミュータブル・バッファ３３０にアクセスし（矢印５２１によって表されるように）、第２計算エンティティ５０２が第２ビュー５１２を介してインミュータブル・バッファ３３０にアクセスする（矢印５２２によって表されるように）。楕円５１３は、これが単にこれら２つの計算エンティティ５０１および５０２よりも多くの間継続できることを示す。ビュー５１１および５１２は、異なるビューであってもよいが、同じビューであってもよい。それには関係なく、ビュー・コンポーネント５２０は、基礎をなすインミュータブル・バッファ３３０の異なるビューを提供することができる。この説明では、「第１」および「第２」という用語は、単に、１つの品目を他から区別するために使用されるのであり、いずれの種類の順列、優先順位、位置、または重要性も全く暗示しない。

[0054] ある実施形態では、インミュータブル・バッファからのデーターを消費する計算エンティティが、保護またはプロセス境界の異なる側にある場合がある。例えば、図５は、計算エンティティ５０１および５０２が、それらそれぞれのビュー５１１および５１２を介してデーターを消費し、これらが実際に境界５３０によって分けられていることを示す。例えば、計算エンティティ５０１および５０２は、別個のプロセスであってもよく、その場合、境界５３０はプロセス間の境界を示す。また、境界５３０は保護境界であってもよく、その場合、一方はコピーすることなくデーターを他方に直接供給することはできない。例えば、計算エンティティ５０１がオペレーティング・システム内部のカーネル・コンポーネントであるのでもよく、一方計算エンティティ５０２は、アプリケーション・コンポーネントのような、ユーザ・モード・コンポーネントであるのでもよい。

[0055] 通例、データーは、データーがコピーされなければ、プロセスおよび保護境界を跨いで共有されることはない。このようなコピーは、かなりの量の計算リソースを要する可能性があり、特に、コピーされるデーターの量が非常に多い場合、またはデーターの異なる部分がこのような境界を跨いで頻繁に共有されようとする場合である。本明細書において説明する原理は、コピーすることなくプロセスおよび保護境界を跨いでデーターを共有するための便利で柔軟性のあるメカニズムを提供する。これによって、オペレーティング・システムの性能を向上させる。

[0056] ビュー・プロバイダー５２０によって提供されるビューは、きめ細かくすることができる。例えば、インミュータブル・バッファから読み出されようとしているインミュータブル・データーがネットワーク・データーであると仮定する。プロトコル・スタックの種々のレイヤは、各々、このネットワーク・データーの異なる部分に関心があるかもしれない。ネットワーク・レベルのコンポーネント（インターネット・プロトコル・コンポーネントのような）は、ネットワーク・レベルのヘッダに関心があるかもしれず、一方アプリケーション・レベルのコンポーネントは単に生のペイロードに関心があるかもしれない。これら２つのレイア間では、異なるコンポーネントがネットワーク・データーの異なる部分に関心がある。

[0057] 本明細書において説明する原理は、ネットワーク・データーをコピーする必要なく、ネットワーク・データーの処理にも効果的に応用することができる。例えば、プロトコル・スタックの最も低いレベルは、ネットワーク・パケット全体を見ることができるのでもよい。この最低レベルでは、このパケットの最も外側のヘッダを処理し、ビュー定義を、プロトコル・スタックにおける次に高いレベルのコンポーネントに戻すことができる。ビュー定義は、最も外側のパケット以外のネットワーク・パケットの全体的な範囲を定める。第２コンポーネントは、このビュー定義をビュー・プロバイダー５２０に供給し、ビュー・プロバイダー５２０はこのビューを第２コンポーネントに供給する。このように、最も低いコンポーネントはパケット全体を見るが、次のコンポーネントは、同じパケットを、最も外側のヘッダを除いて、見ることになる。これは、データーを全くコピーすることなく行われた。代わりに、データーはインミュータブル・バッファ内部に留まっていた。これは、最も高いアプリケーション・レイヤに、パケットのペイロードのみを定めるビュー定義が供給されるまで、繰り返すことができる。

[0058] 図６は、インミュータブル・データーを計算エンティティ間で伝達する方法６００のフローチャートを示す。第１計算エンティティがビュー定義にアクセスし（アクト６０１）、このビュー定義をビュー・プロバイダーに供給する（アクト６０２）。次いで、ビュー・プロバイダーはビューを第１計算エンティティに供給する（アクト６０３）。第１計算エンティティがそのロジックを実行した後（アクト６０４）、次いで他のビュー定義を次の計算エンティティに供給し（アクト６０５）、この計算エンティティが、インミュータブル・バッファからのデーターを処理することになる。次いで、次の計算エンティティがこの方法６００を繰り返すことができ、このように、本プロセスは、システムの多数のレイヤにわたって継続することができる。

[0059] 以上、ゼロ−コピーの様態でバッファ／ストリームを消費することについて説明したが、以上で説明した原理は、データー生成器(data producer)によるバッファおよびストリームの生成にも適用することができる。データー生成器の場合も、アプリケーションがそれ自体のバッファ（別個に割り当てられた）を送る、または書き込み可能なビュー（スパン）をそれ自体の内部バッファに供給するようにデーター生成器に求める柔軟性がある。これは、潜在的に、コピーを排除するだけでなく、半分満たされたバッファを送る必要性を解消することによって、バッファの利用度を高める。
ゼロ−コピー・データー・ストリーミング
[0060] オペレーティング・システムを介したバルク・データーの移動は、多くの場合、ストリーム・アーキテクチャーを使用してモデル化される。ストリームは、データー・ソースとデーター・コンシューマーとの間の論理的導管を表し、ソースによって生成されたデーターをその宛先に配信することを可能にする。ストリームは、通例、生成側と消費側との間におけるスループットの不調和に対処するために、バッファリングを実施する。

[0061] 例えば、図７は、データーのストリーム７１１がストリーム・ソース７１０からストリーム・バッファ７２０に供給され（矢印７０１で表されるように）、次いでバッファ７２０からストリーム・コンシューマー７３０に供給される（矢印７０２で表されるように）ストリーミング環境７００を示す。また、環境７００は、フロー制御を実行するストリーム・マネージャ７４０も含む。ストリーム・マネージャ７４０は、ストリーム部分をストリーム・コンシューマー７３０にバッファ７２０から、ストリーム・コンシューマー７３０にとって満足できるレートで供給させる（矢印７０２によって表されるように）。更に、ストリーム・マネージャ７３０は、ストリーム・バッファ７２０内のストリーム部分の量が少なすぎてストリーム・コンシューマー７３０がストリーミング部分を使い果たすおそれがあることや、多すぎてストリーミング・バッファ７２０の不要なメモリー量が占有されることがないことを保証するために、ストリームの前に適正なリードを実行する（矢印７０１によって表されるように）。また、ストリーム・マネージャ７４０は、ストリーム部分が一旦消費されたらストリーム部分によって占有されるメモリーが取り戻せるように、ストリーム・バッファ７２０内部のストリーム部分の寿命も管理する。

[0062] ストリームは、多くの場合、論理的に多数のプロセスおよび／または保護境界を交差する。例えば、アプリケーションがデーターをファイルから読み出すとき、データーは、保護モードのデバイス・ドライバの制御下で、物理ディスクから読み出されることが多い。次いで、データーはファイル・システム・レイヤを通過し、次いで最終的にアプリケーション・コードに利用可能になる。多くの場合、レイヤの交差は、データーのコピーを伴う可能性があり、性能および電力消費に影響を及ぼす。

[0063] しかしながら、以上で説明したゼロ−コピー・インミュータブル・バッファの原理は、ストリーム・バッファ（ストリーム・バッファ７２０のような）を定式化するためにも使用でき、プロセスまたは保護境界を跨いでストリーム部分をコピーする必要性が解消される。

[0064] 具体的には、ストリームにおける多数のストリーム部分の各々に、インミュータブル・バッファ（図２〜図６に関して説明したもののような）が形成されると仮定する。更に、図２の方法ならびに図３Ａおよび図３Ｂのプロセスが、ストリーム部分が受信される毎に、１つのストリーム部分を収容する関連インミュータブル・バッファを作成するために実行されると仮定する。

[0065] このようなインミュータブル・バッファは、ストリーム部分を含む、あらゆるデーターを、システムの異なるレイヤおよびコンポーネントを通過することを可能にし、更に、図５および図６における一般データーに関して説明したように、データーのコピーを必要とせずに、各々がそれ自体の特定のビューをデーターに対して有することを可能にする。その場合のストリーム・バッファ７２０は、単に、インミュータブル・バッファの集合体であり、各々には、データーとして対応するストリーム部分が収容されている。各ストリーム部分が消費されると、対応するインミュータブル・バッファのメモリーが取り戻されることが許される。このように、本明細書において説明した原理を使用して、ゼロ−コピー・データー・ストリーミングが可能になる。
ゼロ−コピー・キャッシング
[0066] キャッシングは、いずれのオペレーティング・システムのＩ／Ｏサブシステムでも重要な一面である。データー・アクセス・パターンはクラスター化される傾向にあり、同じデーターが多数回引き出されることが多いという事実を利用することによって、レイテンシが低減され、有効スループットが高められる。従前のキャッシングは、オペレーティング・システムの様々なレイヤにおけるメモリーの専用プールを、各々、直交保持および交換方針(orthogonal retention and replacement policies)によって独立して管理させることによって行われる。キャッシュからデーターにアクセスすると、キャッシュ・バッファの外側からアプリケーション・バッファにデーターをコピーすることが必要になることが多い。

[0067] 図２〜図６に関して先に説明した原理は、プロセス間および保護境界を跨いでインミュータブル・バッファの共有を可能にする。保護境界を通る関数コールを置くことはできず、むしろ逆に、境界を跨ぐ通信には、遙かに高負荷なプロセス間通信または保護境界交差通信を使用しなければならない。

[0068] これらの原理は、キャッシュを実装するために使用することができる。直接メモリー・アクセス（ＤＭＡ）動作からのデーター・フローのように、データーはシステム内にインミュータブル・バッファ（図３Ａ、図３Ｂ、および図５のインミュータブル・バッファ３３０のような）として導入される。インミュータブル・バッファは、新たなデーターを伝えるためにシステム中を循環することができ、そして同時に後の再使用のために、キャッシュに速写する(snapshot)することができる。後にデーターの要求が出たときに、同じインミュータブル・バッファをキャッシュから引き出して再使用することができ、基礎的データーをコピーすることも、実際にはアクセスすることさえも不要である。これは、著しい効率の向上に繋がる。

[0069] 計算エンティティが、インミュータブル・バッファ内の基礎的データーに基づくキャッシュを保持するとき、この計算エンティティは、インミュータブル・バッファ内の基礎的データーに対して「強い」参照を有し、インミュータブル・バッファのデーターにアクセスするためにこの強い参照を使用することができる。参照を修飾するための「強い」という用語の使用は、以下で使われる「柔らかい」および「弱い」と称されるものから、この参照を区別するために使用されるに過ぎない。同様に、参照を修飾するための「弱い」および「柔らかい」という用語の使用も、参照を互いに、そして強い参照から区別するために使用されるに過ぎない。

[0070] 任意のエンティティがキャッシュ内のインミュータブル・バッファに対して強い参照を有する限り、このインミュータブル・バッファおよびそのデーターは、強い参照を有するエンティティ毎に強い参照の少なくとも持続期間だけ存在し続けることが保証される。インミュータブル・バッファに対する「柔らかい」参照は、最初に柔らかい参照を強い参照に変換しなくては、インミュータブル・バッファからのデーターをアクセスするためには使用することができない。一旦データー・アクセスが完了したなら、強い参照を柔らかい参照に変換することができる。

[0071] 柔らかい参照は、メモリー管理ヒントの形態として使用することもできる。所与のインミュータブル・バッファに対して、いずれの計算エンティティによっても柔らかい参照しかなく、システムが少ないメモリーで実行している場合、システムは、そのインミュータブル・バッファをバッキングする(back)メモリーを取り戻すことを選択してもよい。これが行われた場合、柔らかい参照を強い参照に変換する次の試みは失敗する。バッファの内容は失われ、計算エンティティは、データー・ソースから、他のインミュータブル・バッファの内容を再度生成しなければならない。

[0072] この柔らかい参照は、システムにおけるキャッシュのサイズを調整するために高い精度を必要とせずに、キャッシュにできるだけ多くのシステム・メモリーを使用する貴重な方法である。例えば、キャッシュは、そのデーターの大部分を、強い参照ではなく、柔らかい参照として保持することを選択することができる。すると、他のプロセスのメモリー使用が大きく妨害して(spike)、システムを低メモリー状態に追いやる可能性がある。すると、システムは素早く反応し、どれ位のメモリーをどのプロセスに与えるかについて全く選択する必要なく、これらの柔らかい参照からメモリーを解放することができる。

[0073] また、計算エンティティは、所与のインミュータブル・バッファに「弱い」参照を保持することもできる。柔らかい参照と同様、弱い参照も、インミュータブル・バッファ内のデーターへのアクセスを許すためには、「強い」参照に変換されなければならない。また、強い参照も弱い参照に変換することもできる。弱い参照は、これらのバッファに対するメモリー管理の第２の形態を与える。これは、弱い参照を保持する計算エンティティに、そのバッファによって使用されるメモリーを引き受けさせる(charge)ことなく、インミュータブル・バッファに対する潜在的に可能なアクセスを保持するために使用される。所与のインミュータブル・バッファに対して任意のプロセスによる弱い参照しかない場合、基礎をなすバッファを直ちに解放することができる。

[0074] インミュータブル・バッファへの弱い参照は、インミュータブル・バッファに対して強い参照を有する他のプロセスからインミュータブル・バッファに対する強い参照を引き出すために必要とされる、プロセス間および保護境界交差通信のコストを軽減するために使用することができる。即ち、弱い参照のキャッシュは、他の計算エンティティ（例えば、他のプロセス）からこれらのバッファを引き出すコストを軽減するために、既に当該他の計算エンティティによってキャッシュされていても、１つの計算エンティティ（例えば、１つのプロセス）において作成することができる。

[0075] 図９は、第２計算エンティティが、第１計算エンティティによってサポートされるキャッシュから最初に読み出す方法９００のフローチャートを示す。図１０は、第２計算エンティティが、第１計算エンティティによってサポートされるキャッシュから次に読み出す方法１０００のフローチャートを示す。方法９００および１０００は、併せて、第２計算エンティティが、第１計算エンティティによって保持されるキャッシュに基づいて、ローカル・キャッシュを構築することを可能にする。方法９００および１０００は、図８の環境８００のコンテキストで実行することができ、図８を頻繁に参照しながら説明する。

[0076] 最初に図８の環境８００を参照すると、第１計算エンティティ８１０は、インミュータブル・バッファ８０１によってサポートされるデーターのキャッシュ８１１を有する。また、第２計算エンティティ８２０は、インミュータブル・バッファからデーターを取得するためにある。また、第２計算エンティティ８２０は、インミュータブル・バッファ８０１から導き出したデーターのキャッシュ８１２を維持するためにある。しかしながら、キャッシュ８１２は、存在を中止する前に、第２計算エンティティからの解放コマンドを待たなくてもよいという意味で、弱いキャッシュである。つまり、第２計算エンティティ８２０は、そのキャッシュ８１２が解放されるときに、制御しない。

[0077] 境界８３０（プロセッサー間または保護境界）が、第１計算エンティティ８１０と第２計算エンティティ８２０との間にある。実施態様の一例では、第１計算エンティティがファイル・システムであり、第２計算エンティティが、ファイル・システムによって供給されるファイルを提供するおよび／または処理するウェブ・サーバーであると仮定する。

[0078] 第１計算エンティティがキャッシュ（例えば、ファイル・システムの場合におけるファイル・キャッシュ）を取得するとき、第１計算エンティティは、データーに対してより速くそしてより多くのローカル・アクセスを得る（したがって、「キャッシュ」と呼ばれる）だけでなく、このキャッシュをサポートするインミュータブル・バッファに対して強い参照を取得する。強い参照は、少なくとも第１計算システムが強い参照を保持し続ける限り（そして、潜在的に、他のエンティティもそのインミュータブル・バッファに対する強い参照を保持する場合には、更に長く）、インミュータブル・バッファ（およびそのデーター）が存在し続けることの保証を与える。この状態において、図９の説明に入る。図９は、第２計算エンティティ（例えば、第２計算エンティティ８２０）が、第１計算エンティティ（例えば、第１計算エンティティ８１０）によってサポートされるキャッシュ（例えば、キャッシュ８１１）から最初に読み取る方法９００を示す。

[0079] 第２計算エンティティは、第１計算エンティティと通信して、インミュータブル・データーに対して強い参照を得る（アクト９０１）。これは、プロセス間または保護境界交差通信であり、したがって高負荷な通信となる。しかしながら、これは、キャッシュをサポートするインミュータブル・バッファが存在し続ける限り要求される唯一の境界交差通信であろう。例えば、ウェブ・サーバーが、キャッシュ内に収容されているファイルを求める第１要求を受けたと仮定する。この初期要求は、ウェブ・サーバーにこの初期通信を行わせ、ファイル・システムからのインミュータブル・バッファに対して強い参照を得させることができる。この強い参照を使用して、第２計算エンティティはインミュータブル・バッファからデーターを読み出すことができる（アクト９０２）。キャッシュからデーターを読み出すときまたは読み出した後、第２計算エンティティは、インミュータブル・バッファに対する強い参照を、インミュータブル・バッファに対する弱い参照に降格する（アクト９０３）。

[0080] 図１０は、第２計算エンティティのキャッシュがデーターを有していない場合に、第２計算エンティティが、第１計算エンティティによってサポートされるキャッシュから次に読み出す方法１０００のフローチャートを示す。キャッシュに対する弱い参照がなおも存在している間に、キャッシュから読み出す要求を受けると（アクト１００１）、第２計算エンティティは、インミュータブル・バッファがなおも存在するか否か判定を行う（判断ブロック１００２）。インミュータブル・バッファがなおも存在する場合（判断ブロック１００２において「Ｙｅｓ」）、第２計算エンティティは、インミュータブル・バッファに対するその弱い参照を強い参照に変換し（アクト１０１１）、バッファから読み出し（アクト１０１２）（そしてそのデーターをローカル・キャッシュ８１２にローカルにキャッシュする）、その後この強い参照を再度弱い参照に変換する（アクト１０１３）。これは、第１計算エンティティとのプロセス間または保護境界交差通信も実行することなく行われる。逆に、第２計算エンティティは、単に、インミュータブル・バッファに対するビューを取得し、インミュータブル・バッファから読み出す。

[0081] インミュータブル・バッファが既に存在しない場合（判断ブロック１００２において「Ｎｏ」）、第１計算エンティティとのプロセス間または保護境界交差通信を実行することによって、第１計算エンティティにデーターを再取得させ、新たなインミュータブル・バッファを作成し直させる（アクト１０２１）。次いで、方法９００に戻り、第２計算エンティティは、次いで、新たなインミュータブル・バッファに対して強い参照を得て（アクト９０１）、バッファから読み出す（アクト９０２）ことができる。

[0082] つまり、第２計算エンティティは、第１計算エンティティの強いキャッシュ（第１計算エンティティの制御により適所に残るもの）から導き出される弱いキャッシュ（第２計算エンティティが弱いキャッシュを使用して行われる前に、再構築しなければならないかもしれないもの）を有すると見なすことができる。他の強いキャッシュの上にこの第２の「弱い」キャッシュを構築すると、バッキング・キャッシュに対する置換（または削除）方針に伴う何らかの問題が生じる。削除(eviction)とは、より頻繁に使用されるデーター（即ち、「ホット」データー）のために余裕を持たせるために、余り使用されないデーター（即ち、「コールド」データー）をキャッシュから除去（即ち、削除）するメカニズムを指す。削除は、一定の項目のデーターがアクセスされる頻度に関する統計に基づく。弱いキャッシュ８１２および強いキャッシュ８１１は、データーに対する異なる要求を受けるので、キャッシュ部分のアクセス頻度に関しては、全く異なる統計を有する。

[0083] 具体的には、弱いキャッシュ８１２は、バッキング・キャッシュ８１１に逆戻りする前に、最初に第２計算エンティティ８２０による要求に応じる(serve)ために使用される。この弱いキャッシュは、このように、ホット・データーに対する初期の参照を殆ど吸収して、それらの有用性をバッキング・キャッシュ８１１に隠す。つまり、バッキング・キャッシュ８１１が新たな項目を求める要求を受けて、これにアドレスしないとき、バッキング・キャッシュは、弱いキャッシュ８１２の統計にしたがって「ホット」であるデーターを、弱いキャッシュ８１２に未だ保持されている項目と置き換えさせてもよい。この置換によって、基礎をなすバッファに対する最後の存続していた強い／柔らかい参照を除去し、弱いキャッシュにおいて弱い参照に対応するバッファを解放することができる。すると、この弱いキャッシュに逆らってその項目を求める次の要求は、失敗する。

[0084] 本明細書において説明する実施形態によれば、この問題には、ホット・データーの有用性（弱いキャッシュ８１２から見た場合の）をバッキング・キャッシュ８１１に伝えることによって対処する。本システムは、このメカニズムを、第２計算エンティティがデーターに対する弱い参照をデーターに対する強い参照に変換するときの副作用として、提供することができる。本システムは、基礎をなすバッファ毎にこれが発生する回数を数え、この回数をバッファ自体についてのメタデーター・プロパティとして露出する。次いで、バッキング・キャッシュはこの値を問い合わせ、任意の２つの時点の間で行われた参照の回数を判定することができる。この情報は、バッキング・キャッシュの置換アルゴリズムによって、その項目を双方のキャッシュにおいて生かしておくために使用することができる。

[0085] 図１１は、第１計算エンティティ（またはバッキング・キャッシュ）が削除を実行する方法１１００のフローチャートを示す。最初に、バッキング・キャッシュは、削除の候補を識別するためにそれ自体の統計を使用する（アクト１１０１）。次いで、第１バッキング・キャッシュは、弱いキャッシュの第２統計と、これらの識別された候補について協議する（アクト１１０２）。次いで、第２統計が、識別された候補から頻度が高い方のアクセスを示す場合、その識別された候補が当面はキャッシュ内部に保持できるように、第２統計と協議した後、識別された候補に関する削除判断を遂行する（アクト１１０３）。

[0086] これら最初の３つの概念（即ち、インミュータブル共有可能ゼロ−コピー・バルク・データー、ゼロ−コピー・ストリーミング、およびゼロ−コピー・キャッシング）は、マネージド・コード・システムだけでなく、アンマネージド・コード・システムにおいても適用することができる。しかしながら、マネージド・システムによって供給されるビューは、非マネージド・システムのそれよりも素早く、そして遙かにきめ細かく作成することができるので、本原理は、マネージド・システムと最も効果的に使用することができる。

[0087] 図１２は、マネージド・コード・システムの一例１２００を示す。マネージド・システム１２００は、マネージド・メモリー１２０１を含む。マネージド・システム１２００は、多数のマネージド・コード・コンポーネント１２３０を有し、各々、エンティティ特定メモリーに対する排他的アクセスを有する。例えば、実行中のマネージド・コード・コンポーネント１２３０は、７つのコンポーネント１２３１〜１２３７を含むことが示されているが、楕円１２３８は、この数の大きな柔軟性を表す。例えば、コンポーネント１２３１〜１２３７はプロセスであってもよい。

[0088] ７つの実行中のコンポーネント１２３１〜１２３７の各々は、対応するエンティティ特定メモリー１２１１〜１２１７を有する。マネージド・コンポーネントは、他のエンティティ特定メモリーのエンティティ特定メモリーにアクセスすることはできない。つまり、対応するマネージド・コンポーネントだけが当該エンティティ特定メモリーにアクセスできるように、エンティティ特定メモリー間に分離保護がある。例えば、コンポーネント１２３１はエンティティ特定メモリー部分１２１１にアクセスするが、エンティティ特定メモリー部分１２１２〜１２１７にはアクセスしない。コンポーネント１２３２は、エンティティ特定メモリー部分１２１２にアクセスするが、エンティティ特定メモリー部分１２１１やエンティティ特定メモリー部分１２１３〜１２１７にはアクセスしない等である。

[0089] マネージド・コード・メモリー１２１０は、共有メモリー１２１９も含む。この共有メモリー１２１９は、図３Ａ、図３Ｂ、および図５のインミュータブル・バッファ３３０の一例である。即ち、以上で説明した原理は、マネージド・コード・システムに全く頼らない。しかしながら、本明細書において説明した最後の２つの概念は、マネージド環境に限定される。図１２のいくつかの他のエレメントについて、これら最後の２つの概念（即ち、均一メモリー・アクセスおよびタイプ−セーフ・タイプキャスティング）の説明に関して説明する。
均一メモリー・アクセス
[0090] マネージド言語環境におけるメモリーは、潜在的に非常に動的なものである。オブジェクトは、ヒープから割り当てられ、ガベージ・コレクターによって管理される。図１２を参照すると、マネージド・システム１２００はガベージ・コレクター１２２１を含む。発見的方法に基づいて、ガベージ・コレクターは、規則的に、以前に使用された空間を取り戻すためにオブジェクトを一緒に纏めることによって、ヒープの保守を実行する。オブジェクトを一緒に纏めるとは、オブジェクトのメモリー・アドレスが本質的に不安定であり、ガベージ・コレクターによる変化を受けることを暗示する。ガベージ・コレクターは、特定のコード生成パターン、およびオペレーティング・システムからのサポートに依存して、アプリケーション−レベル・コードに透過的な方法でオブジェクトを移動させることができる。

[0091] オペレーティング・システムのＩ／Ｏサブシステムは、大量のデーターをシステム・メモリーにわたってシャッフルする役割を担う。読み出すとき、データーは、通例、外部デバイスから取得され、デバイス自体によって管理されるＤＭＡ動作によって、最小限のプロセッサーとの相互作用によって、メモリーに入力される。同様に、データーを書き出すとき、ＤＭＡメモリー動作が自動的にメモリーの内容を読み出すことができる。

[0092] ＤＭＡ動作は、動作中にリロケートされるメモリーの内容と争うことはできない。そうするには、プロセッサーとデバイスとの間できめの細かい調整が必要となり、性能および電力効率に劇的に影響する。この制約の結果、マネージド・オペレーティング・システムにおいてＤＭＡをサポートするためには、２つの広い選択肢がある。

[0093] ガベージ・コレクターに、指定されたオブジェクトをリロケートしないように命令するために、メモリーの領域に対して特殊なピンニング動作が使用される。これによって、ＤＭＡ動作は、実行している間、影響を受けるメモリーの一貫したスナップショットを見ることができる。

[0094] ＤＭＡ動作は、ガベージ・コレクションの対象でない特殊なメモリー領域において行われる。

[0095] 第１の手法は、ガベージ・コレクターの効率を著しく阻害する可能性がある。何故なら、メモリーのピンニング領域を扱うと、コンパクション・プロセスを複雑にし、その効率を低下させるからである。第２の手法は、この問題を回避するが、過剰なメモリー・コピーを招き易い可能性がある。何故なら、通常のメモリー領域と特殊なＤＭＡ相容(DMA-friendly)メモリー領域との間でデーターを転送する特殊化されたロジックを必要とするからである。

[0096] 統一メモリー・アクセス・アーキテクチャーは、通常のマネージド・メモリーかまたは特殊なＤＭＡ相容メモリー領域かには関係なく、メモリーを参照する系統的な方法を送り出す。これは、プログラマーがＤＭＡ相容メモリー領域におけるデーターを直接完全に安全な方法で操作することを可能にし、オブジェクトをピンニングする必要性も、通常のメモリーとＤＭＡ相容メモリーとの間でコピーする必要性も回避する。

[0097] マネージド言語環境では、バルク・データーは通例アレイに保持される。マネージド言語環境（例えば、マネージド・システム１２００）は、直接アレイを理解し、個々のアレイ・エレメントへのアクセスを許可し、プログラマーがアレイの境界を超えないことを保証する。言語環境によって管理されることにより、アレイはマネージド・ヒープ内に位置するように制限される。

[0098] 図１２のマネージド・システム１２００では、インミュータブル・バッファ１２１９がマネージド・ヒープの外側に位置し、したがって、通常の状況下では、マネージド・プログラムから直接アクセスできない。Ｉ／Ｏメモリーからのリードおよびライトは、通常、伝統的なＩ／Ｏパッケージを使用し、明示的なリードおよびライト動作によって行われ、マネージド・ヒープにおける通常メモリーとＩ／Ｏメモリーとの間における暗黙的なコピーを誘発する。

[0099] マネージド・システムは、マネージド・コード・コンポーネントからインミュータブル・バッファ１２１９に直接アクセスするメカニズムを提供する抽象(abstraction)（ここでは「スパン」と呼ぶ）を含む。図１２を参照すると、マネージド・メモリー部分１２１１は、抽象的に表されたスパン抽象１２４０を含む、種々のオブジェクトを含む。スパンは、アレイが作用する様相(how arrays work)に非常に似た様態で、Ｉ／Ｏバッファの任意の領域への直接アクセスを与えるために形成することができる。更に、スパンは、マネージド・メモリーを参照するために構成することができる。スパンの上に構築されるソフトウェア抽象は、したがって、スパンの基礎をなすメモリーの位置に対して不可知論的であることができる。これは、究極的な組立構想を提供し、マネージド・メモリー（例えば、メモリー部分１２１１〜１２１８）またはインミュータブル・バッファ１２１９に対して動作する自然な方法(in a naturel way)で、抽象を設計することを可能にする。

[0100] スパンは、当該スパンに対して基礎をなすストレージと相互作用することによって作成される。例えば、インミュータブル・バッファ１２１９は、スパンによって直接制御されるインミュータブル・バッファを参照するスパンを戻すメソッド・コールを供給することができる。同様に、アレイは、それらまたはそれらの一部を指し示すスパンを戻すメソッドを供給する。一旦スパンが具現化されると、通常のマネージド言語においてアレイが使用されるように、全域で渡され広く使用することができる。

[0101] スパンに伴う特異な微妙さは、基礎をなすストレージの寿命管理に関係する。マネージド・プログラミング環境の主要な利点の１つは、ガベージ・コレクターが、オブジェクトがもはや参照されず、そのストレージを再利用できるときを検出する役割を担うことにある。これは、例えば、アレイがもはや有用でないときに発生することである。

[0102] スパンの基礎をなすメモリーが通常のガベージ・コレクト・ヒープ(garbage collected heap)の外側にあるとき、そのメモリーの寿命は、作成されたスパンがそのメモリーを参照する場合、メモリー・バッファ自体よりも長く生存しないように、注意深く管理されなければならない。これは、基礎をなすメモリーにおいて参照カウンターを使用する、またはスパン自体の寿命を制限することによってというように、多数の方法で準備することができる。

[0103] 一実施形態では、スパン・オブジェクトは、それが表すメモリーの領域への特殊注釈ポインター(specially-annotated pointer)を保持する。ガベージ・コレクターは、これらの特殊ポインターを理解し、これらを特別に扱う。ガベージ・コレクション動作の間、ガベージ・コレクターが特殊ポインターに遭遇した場合、このポインターが保持するアドレスを考慮する。ガベージ・コレクターが、ポインターがマネージド・ヒープの外側を指し示すことを検出した場合、ガベージ・コレクターはこのポインターから先ではポインターを完全に無視する。逆に、このポインターがマネージド・ヒープ以内の点であることが発見された場合、ガベージ・コレクターはこのポインターをマネージド・オブジェクトに対する参照として扱い、したがって自動的にポインターの値を調節し、その結果、元のオブジェクトがリロケートされる。

[0104] スパンは、他のスパンの副領域を表すために作成することができる。これは、スパンを、コピーを行うことなく、安全にしかも安価な方法で、より大きなメモリー領域からチャンクを取り除く非常に便利な方法にする。結果的に得られるスパンは、他のスパンのメモリーの部分集合にエイリアスされる(aliased)のであっても、他のいずれのスパンとも同様に見える。
タイプ−セーフ型キャスト
[0105] マネージド・プログラミング言語の主要な役割は、プログラムがメモリーにおいて任意のアドレスを取り込みそれをオブジェクトとして操作することを防止するタイプ・セーフを強制することである。例えば、図１２のマネージド・システム１２００は、タイプ・セーフを保証するタイプ・ストリーム１２２２を含む。全てのオブジェクトは明示的に取得され、各オブジェクトのアドレスは、ガベージ・コレクター（例えば、ガベージ・コレクター１２２１）によって厳しく制御される。このようなシステムでは、ガベージ・コレクターの直接制御下にないメモリーは、アプリケーション・コードによって直接使用することができない。代わりに、メモリーは、それが使用できるようになる前に、特殊メモリーから逆にガベージ・コレクターによって制御されるメモリーにコピーされなければならなくなる。

[0106] ＤＭＡ動作によってシステムに入るおよびシステムから出るデーター・フローのように、ＤＡＭデバイスによって操作されるデーターは通例ある固有の形状を有する。例えば、ＤＭＡを介してデーターを書き出すとき、ガベージ・コレクト・ヒープにおけるあるデーター構造は、通例、書き出す必要があるデーターを保持する。次いで、「シリアル化」ステップを使用して、データーをこれらの構造からＤＭＡ動作に必要とされる形状に転記する。このシリアル化ステップは、厄介で、エラーが起こりやすく、非効率的である。シリアル化およびディシリアル化は、通常、マネージド・プログラミング言語の重要部分である。

[0107] スパン抽象を利用することにより、汎用モデルが、プログラマーがオブジェクト指向セマンティクスを使用してＤＭＡメモリー領域と直接対話処理することを可能にする。特殊な型キャスト・サポートが、プログラマーがＤＭＡメモリー領域をオブジェクトとして見ること、したがって自然な方法でメモリーに対して直接リードおよびライトを行うことを可能にし、効率を最大限高め、正確さを向上させ、プログラマーの作業を簡略化する。このモデルは、単なるＤＭＡメモリーを超えて拡張し、通常のガベージ・コレクト・メモリーに対する拡張型キャスト・セマンティックスも同様にサポートする。

[0108] タイプ・セーフを維持するために、任意の型間で型キャストを許すことは可能でも、望ましくもない。代わりに、この拡張型キャストに関わらせることができる１組の許可された型に制限する特定の規則が存在する。この規則は、しかしながら、かなり広義であり、通常ＤＡＭ動作に関与する種類のデーターに対して完全に作用することになる。

[0109] マネージド・プログラミング言語では、メモリーが割り当てられるときはいつでも、それに所与の型が割り当てられる。この型は、メモリーのブロックの異なる部分の意味、およびそのメモリーのブロックに対して実行することができる動作を決定する。この型は、メモリーがインナクティブになり、ガベージ・コレクション・プロセスによってリサイクルされるまで、そのメモリーのブロックに対して変化させることはできない。常に、言語環境は、メモリーのブロックを割り当て、型を決定し、そしてリサイクルする役割を担う。

[0110] 型キャストは、あるメモリーを、マネージド環境によって知られる型以外の型として扱う能力である。型キャストは、ネーティブ・プログラミング言語では極普通であるが、マネージド言語は一般に型キャストを提供しない。代わりに、マネージド環境は、１つの型の値を他の型にコピーすることを可能にする型変換メカニズムを備える。例えば、整数値を浮動小数値に変換することができる。しかしながら、これは常にコピーによって行われ、元のメモリー位置は不変のまま残る。

[0111] 本明細書において説明した原理にしたがって、型キャストを、マネージド言語における汎用機能(facility)として導入する。以下で説明するように、タイプ・セーフが保存されることを確保するために、制約を適用する。

[0112] マネージド・オペレーティング・システムでは、Ｉ／Ｏ動作に使用されるメモリーは、ピンニングされたオブジェクトであるか、またはＩ／Ｏ専用のメモリーの領域でなければならない。先に説明したように、移動を防止するためにメモリーにおいてオブジェクトをピンニングするのは、高負荷になり、ガベージ・コレクト環境において多くの問題を招く。本明細書において説明した原理は、インミュータブル・バッファを装った専用Ｉ／Ｏメモリーを使用する（図３Ａ、図３Ｂ、および図５のインミュータブル・バッファ３３０のような）。

[0113] Ｉ／Ｏメモリーは、マネージド・メモリー・サブシステムの範囲の外側にある。マネージド環境は、このメモリーの型を制御せず、したがって、この種のメモリーにマネージド・プログラムから直接アクセスするのは不可能である。代わりに、明示的なコールを使用してこのメモリーに対してリードおよびライトを可能にするために、通常、特殊な接続（即ち、グルー）コードが使用される。これらのＩ／Ｏバッファ内にあるいずれの種類の構造化データーにアクセスするにも、途方もなく非効率的なコードを必要とするか、またはＩ／Ｏメモリーから通常のマネージド・メモリーにデーターをコピーする必要があり、これも非効率的である。

[0114] ネットワーク・デバイスから取得されたインミュータブル・バッファについて考える。このバッファには、ネットワーキング・プロトコル情報を保持するＴＣＰヘッダがある。基本的に、ＴＣＰヘッダにおけるデーターをマネージド・プログラミング言語において使用できるようにするには、２つの方法がある。以下の表は、双方の手法および各々に含まれるステップを示す。

[0115] 使用可能なＴＣＰヘッダ・オブジェクトを得るのは、型キャストを用いる場合、従前の手法を用いるよりもかなり速くなる。新たな手法は、ネーティブ・オペレーティング・システムにおいて発生することを模擬し、ポインター・マス(pointer math)が可能であり、この種のシナリオでは頻繁に利用される。ポインター・マスは、マネージド・プログラミング言語では利用できないが、タイプ−セーフ型キャストは同様の機能性を送り出す。

[0116] 従前の手法には変形が可能であるが、多少オーバーヘッドが生ずる。例えば、問題のメモリー・バッファは直接プログラマーに利用可能であり、したがってリード／ライト・メソッドを使用するよりも効率的にアクセスすることができることが可能である。しかしながら、その場合、プログラマーは、バイトのシーケンスを上位のオブジェクトに変える役割も担うことは変わりなく、厄介であり、エラーが起きやすく、十分に機能しない。

[0117] 型キャストを可能にし、タイプ・セーフが保存されることを保証するのは、型キャストが、それを許すように設計された型でのみ可能であるということである。型キャストにあずかる(participate in)ためには、型は、１）値型（参照型ではなく）であり、２）型キャストをサポートする他の型のみで構成され、３）参照で構成されず、４）特定のメモリー・レイアウトを使用して定義され、５）そのフィールドのいずれにおいてもいずれのビット・パターンも容認する。

[0118] これらの制約は、型キャストに使用されるためには、型は他のオブジェクトに対する参照を含むことができないことを意味する。したがって、これらの制約は、ＴＣＰヘッダおよび広い１組の他のこのようなデーター構造というようなデーター・フォーマットを表すために定義される型の特性を完全に記述することになる。

[0119] 前述のように、タイプ−セーフ型キャストは、マネージド・メモリー環境の範囲の外側に位置するＩ／Ｏバッファのリードおよびライトを行うために使用することができ、更にマネージド・メモリーを異なる型として見るために使用することができる。具体的には、この技法は、代わりに、バイトのアレイを１つ以上のもっと豊富な型のインスタンスとして見るのに有用である。

[0120] 図１３は、通常のマネージド・バイト・アレイを示す。このアレイは、その内部を指し示す２つの別個のスパンを有し、アプリケーションがアレイの複数の部分を異なる型として見なすことを可能にする。このように、任意の数のスパンを作成することができ、各々が別個の型を有する。スパンは、自由に重複することができ、潜在的にメモリーの同じ領域を異なる型として参照する可能性がある。

[0121] モデルの信頼性にとって、そのフィールドのいずれにおいてもいずれのビット・パターンも容認しなければならないという規則は重要である。型キャストを使用するとき、他の場合では正常に見えるオブジェクトのインスタンスが、型コンストラクター(type constructor)を実行させずに、環境に導入される。通常、コンストラクターは、入力引数の有効性判断を実行し、オブジェクトを構成する１組の許された値に最終的に制限する役割を果たす。しかし、型キャストを用いると、メモリーの既存のスパンを、あたかも異なる型であるかのように見ることによって、無からオブジェクトを作成することが可能になる。

[0122] マネージド・ヒープ内の別個のオブジェクトにデーターをコピーするという従前の手法は、データーがマネージド・オブジェクトのコンストラクターにプッシュされたかのように、データーの有効性を判断する機会を与える。これが意味するのは、実世界システムには、無効なバージョンのマネージド・オブジェクトがシステム内部に存在しないということであり、コンストラクターは、有効なバージョンのみを作成できることを保証する。これは、あらゆるビット・パターンが現れる可能性がある型キャストとは対照的である。意味的に無効な値がある場合、オブジェクト構成が行われないので、これらを検出することはできない。

[0123] 正確さの問題に対する解決手段は、追加の抽象レイヤをソフトウェアに導入することである。具体的には、再度ＴＣＰヘッダを読み出す例を挙げると、開発者が２つの別個の型、RawTcpHeaderおよびValidTcpHeaderを定義したことを想像することができる。

[0124] 入力バッファにおけるデーターは、RawTcpHeaderに変換された(cast)型である。このオブジェクトを仮定すると、AcquireValidTcpHeaderメソッドを呼び出すことができる。このメソッドは、RawTcpHeaderにおけるフィールドの有効性を確認し、ValidTcpHeaderの新たなインスタンスを戻す。これは、RawTcpHeaderの回りで普通のラッパーとして動作し、ホルダーに、保証された有効なヘッダを得たことを伝える。これは全て、コピーなしで行われ、ValidTcpHeader値型であるパススルー・オブジェクト(pass-through object)が作成されるだけである。

[0125] 本発明は、その主旨や本質的な特性から逸脱することなく、他の特定形態においても具体化することができる。説明した実施形態は、あらゆる観点においても、限定ではなく例示としてのみ見なされるものとする。したがって、本発明の範囲は、以上の説明ではなく、添付した特許請求の範囲によって示される。特許請求の範囲の意味および均等の範囲に該当するあらゆる変更は、その範囲に含まれるものとする。

Claims (10)

1. 各々、マネージド計算エンティティに対応する複数のマネージド・メモリー部分を有するマネージド・メモリーと、
   前記マネージド・メモリーの外側に位置するインミュータブル・バッファであって、前記複数のマネージド・メモリー部分の内特定のマネージド・メモリー部分が、前記対応する特定のマネージド計算エンティティにはアクセス可能であるが、他の計算エンティティにはアクセス可能でない１つ以上のガベージ・コレクト可能オブジェクトを含み、前記特定のマネージド・メモリー部分が、前記インミュータブル・バッファに対する１つ以上の参照も含む、インミュータブル・バッファと、
   前記特定のマネージド・メモリー部分における前記１つ以上のガベージ・コレクト可能オブジェクトを管理するように構成され、更に前記インミュータブル・バッファに対する前記１つ以上の参照に対しては何のアクションも実行しないように構成されたガベージ・コレクション・コンポーネントと、
   を含む、システム。
2. 請求項１記載のシステムにおいて、前記マネージド・メモリーがマネージド・ヒープである、システム。
3. 請求項１記載のシステムにおいて、前記インミュータブル・バッファが、当該インミュータブル・バッファの寿命の間そのデーターが変化させられることから保護される、システム。
4. 請求項１記載のシステムにおいて、前記インミュータブル・バッファが、当該インミュータブル・バッファの寿命の間その物理アドレスが変化させられることから保護される、システム。
5. 請求項１記載のシステムにおいて、前記１つ以上の参照の少なくとも１つがアレイ・エレメントである、システム。
6. 請求項１記載のシステムにおいて、前記１つ以上の参照の少なくとも１つが、前記インミュータブル・バッファの少なくとも一部のアドレスを含む、システム。
7. 請求項１記載のシステムにおいて、前記特定のマネージド・メモリー部分が、第１マネージド・メモリー部分であり、前記特定の計算エンティティが、前記複数の計算エンティティの内第１計算エンティティであり、
   前記複数のマネージド・メモリー部分の内第２マネージド・メモリー部分が、前記対応する第２計算エンティティにはアクセス可能であるが、他の計算エンティティにはアクセス可能でない１つ以上のガベージ・コレクト可能オブジェクトを含み、前記第２マネージド・メモリー部分も、前記インミュータブル・バッファに対する１つ以上の参照を含む、システム。
8. ガベージ・コレクションの実行方法であって、
   特定の計算エンティティに対応する特定のマネージド・メモリー部分を検討する(review)アクトであって、マネージド・メモリーが、複数のマネージド・メモリー部分を含み、各マネージド・メモリー部分が計算エンティティに対応する、アクトと、
   検討するときに、複数のオブジェクトを発見するアクトであって、前記特定のマネージド・メモリー部分が、前記マネージド・メモリーの外側にあるインミュータブル・バッファに対する参照を含む、アクトと、
   前記参照を発見したときに、前記参照が前記マネージド・メモリーの外側にある項目に対応すると判定するアクトと、
   前記判定するアクトの結果、前記参照に対応する前記項目に対してガベージ・コレクションを実行するのを控えるアクトと、
   を含む、方法。
9. 請求項８記載の方法において、前記マネージド・メモリーの他のマネージド・メモリー部分も、前記マネージド・メモリーの外側にある前記項目に対する参照を含む、方法。
10. 請求項８記載の方法であって、更に、前記マネージド・メモリー部分の外側にある項目を参照しないオブジェクトに対してガベージ・コレクションを実行するアクトを含む、方法。

Images