OSからコンテクストスイッチを廃する

Microsoft Research Singularity Project
一日に100回以上もMarshal.RelelaseComObject(hoge);なんてコードを書いていると、頭がおかしくなってきて、ついつい先のこととか考えてしまいます。
これから、マルチコア、それを通り越してエニィコアとマイクロプロセッサのコア数が爆発的に増えていくのはいいのですが、コア数が増えるほど限りあるメモリバス帯域や、L2, L3キャッシュをその多数のコアで奪い合うことになります。したがって、コア数分リニアに性能が上がっていくわけではなく、それらがボトルネックになり、どこかで性能向上の上限が来ます。ただ、この性能向上の上限はキャッシュの使用方法を効率化させることで遅らせることは可能だと思います。(少なくともメモリバス速度の向上よりは望みがあります）
キャッシュの効率化の方法にはもちろんハードウェア的な手当てもありますが、ソフトウェアを変えていくことで、効率化を図ることが可能なはずです。
今のオペレーティングシステム、特にプリエンティブマルチタスクでタスク管理を行うOSは、マイクロプロセッサが提供するタスク切り替えの支援機能、具体的には各レジスタ値、プログラムカウンタ値を退避し、退避したものを復活させる機能を使ってマルチタスク管理を行っています。これを(乱暴に言えば)コンテキストスイッチと言います。そしてこのコンテキストスイッチが行われた時に物理的な参照アドレスがたいていの場合大きくジャンプするので、ほとんどの場合キャッシュ破壊が起こります。これはシングルプロセッサや、複数シングルプロセッサによるSMP構成のシステムでは致し方ない無駄なのですが、マルチコアの場合には致し方ないとはいえ、複数のコアでキャッシュを共有している以上より深刻なコストになります。
つまり現状のOSを使う限り、できる限りタスク切り替えがないほうがマルチコアでは実行効率が良いということになりわけですが、せっかくコア数が増えたのに、たくさんタスクを動かすと効率が悪くなるというのもなんとなく納得しがたい話です。
ということで、効率化妨げる大きな要因がコンテキストスイッチにあるのだとしたら、それを廃してしまおうという考え方も出てきます。特に最近は何らかの仮想マシン上でアプリケーションが実行されることが多く、プロセッサネイティブなコードでアプリケーションを書く場合に比べ、タスクスケジューリングや実行単位の粒度に自由度があります。(仕掛けが作りやすい)この自由度を利用して、プロセッサからみた場合には大きな一つのプロセスとしてOSと仮想マシンを合わせたものを動作させて、仮想マシンにマルチタスク管理をさせることで、コンテキストスイッチをさせずにマルチタスク管理をさせようという考え方が出てきました。これが、上のリンクで紹介されているSingularity Projectです。
Singularity Projectではこの大きな塊としてのCLR+Alphaがプロセッサ上の1プロセスとして動作し、この中で.NETのアプリケーションをマルチタスクで動作せていて、このNETアプリケーションはAppDomain単位で実行単位(Singularityでのプロセス)として管理されることになります。通常のWindowsアプリケーションではいまいち掴みどころのなかった(何のためにあるのかよくわからなかった)AppDomainがここでは本来の目的を果たしています。
ということで、SingularityがこのままWindows hogehogeになることはまずないと思いますが、OSの進化の方向としてはハードウェアの抽象化だけでなく、プロセッサさえ抽象化し、その中でマルチコア、エニィコアの世界、あるいはフリーランチの無い世界においてもアプリケーション実行効率の向上を実現させていくのではないでしょうか。