Microsoft Research、ケンブリッジ大学、プリンストン大学の研究者たちが.NETをフォークし、ランタイムで手動メモリ管理をサポートするAPIを追加して、そのアプローチとパフォーマンス改善に関する詳細を"Project Snowflake: Non-blocking Safe Manual Memory Management in .NET"として公開した。
Project Snowflakeは、.NETに手動メモリ管理を導入することで、ある種のアプリケーションにおいて有用と考えられる改善を実現する試みだ。C#/.NETなど最近のプログラミング言語は、ガベージコレクションを使ってオブジェクト管理に関するプログラマの労力を軽減することにより、開発生産性、プログラムの安定性、メモリ安全性およびセキュリティ面でのメリットを実現している。一方でガベージコレクションには、ほとんどのケースでは認識されないものの、特定の状況では問題となり得るようなパフォーマンス上のコストが伴う。Snowflakeの研究者たちは、100GB単位のヒープメモリを必要とするデータ解析やストリーム処理を、手動メモリ管理の恩恵を受けるものとして挙げている。
Snowflakeでは、通常はGC機構を使用して、必要な状況で手動メモリ管理を使用可能にするという、手動メモリ管理とガベージコレクションによる管理の併用を提案している。ランタイムに導入された変更は、既存アプリケーションには影響を与えずに、マルチスレッドアプリケーションのパフォーマンスを向上する。Snowflakeは"任意のプログラムロケーションにおいて、個々のオブジェクトのアロケーションとデアロケーションを可能にすると同時に、手動で管理されるオブジェクトに対して、並行アクセスの存在を含む完全な型安全性と時間的安全性を保証する"。
このプロジェクトでは、オブジェクトのOwnerとSheildという2つの大きな概念を新たに導入して、CoreCLRおよびCoreFXレベルでAPIとして実装している。Ownerは手動ヒープ内にアロケートされたオブジェクトへのユニークな参照を保持する、スタックないしヒープ上のロケーションである。OwnerはShieldから取得する。Sheildは、手動オブジェクトが複数のスレッドからアクセスされた場合に、デアロケーションを回避する目的で導入された概念だ。Sheildは、使用中の最後のスレッドがデアロケートした場合にのみ、オブジェクトがヒープから削除されることを保証する。論文ではこれを詳しく説明している。
私たちのソリューションは ... ロックフリーなデータ構造に関する研究から発展したテクニックである、ハザードポインタにヒントを得ています。これらOwnerロケーションのひとつを通じて手動オブジェクトにアクセスするスレッドの意図を、スレッドローカル状態(TLS)で公開するメカニズムを導入しました。この登録は、オブジェクトをデアロケーションから保護するためのシールド(Sheild)の生成と考えることができます。登録を行なったスレッドに対して、手動オブジェクトへの直接アクセス(メソッドの呼び出しやフィールドの変更など)を許可すると同時に、(同一または別の)スレッドがそのオブジェクトの解放とメモリ再利用を行なうことを禁止します。クライアントのコードで、このオブジェクトへのアクセスが不要になれば、Sheildの破棄が可能になります。これによって、このオブジェクトへの参照がTLSから削除されます。Shieldが破棄された後は、そのShieldから取得したオブジェクトへの直接アクセスは安全ではありません。このShileの破棄に続いて、実際のデアロケーションが実行可能になるからです。
論文では、いくつかのシナリオにおいて、Snowflakesを使用することによるパフォーマンス上のメリットを測定したテストの結果が、GCとの比較として紹介されている。それによると、"ピーク時で3倍の節約、ランタイム時で2倍の改善"という、良好な結果が得られている。これは、非常に大きなオブジェクトプールでは、GCがオブジェクトグラフを走査してメモリを解放するために多くの時間を要するからだ。
Microsoftは、Snowflakeのテクノロジを.NETに採用するかどうかについて詳しく触れていないが、将来のヴァージョンの.NETで、非侵入型の安全なメカニズムを考慮した同様な仕組みが導入される可能性はある。
この記事を評価
- 編集者評
- 編集長アクション