いまさらな話だが、なぜ仮想化か？何を仮想化するか
私以外の読者の方へ：以下、丸っきりの与太話で、建設的じゃなくてすみません。でも、自分にとっては散逸してほしくないメモなので、とりあえずここに置いてあります。*1
仮想化は、マルチタスクOSの仮想メモリの機能が誕生したときからあったと考えてもいいかもしれない。もともと、メモリ空間をタスクごとにカプセル化して保護する機能だった。*2
今話題になっているのは、カプセル化の枠としてOSという単位で考えたもの。隔絶されているから、異種のOSが共存しても問題ない。
他にもカプセル化の単位はいろいろあるだろう、プロセス単位、ユーザ単位、サービス単位。
OS毎でカプセル化する必然性は無いのだろう。現在話題の仮想化を「実際のタスクとのセマンティックギャップが大きすぎる」という批判をどこかで読んだ気がするが、確かにそういう面もあるかもしれない。
タスクが実行されるメモリ空間にとっては、プログラムのロードをしてくれたあとは資源アクセス用のAPIがあればいいだけだ。資源を共有するためにOSがある。すると、資源管理のスコープとして、現在のOSの単位というのはちょうどいい。programmerの持つOS固有のノウハウの蓄積とサーバのidentity(namespace)というcontextを共有できる。その点では、OSごとの仮想化というのは、悪くないworking setかもしれない。しかし、OSのFull Systemを共有すれば無駄もあるはず。
ならば、仮想化は、contextの境界を自由に設定できれば、もっとスマートにならないかしら。もっとgenericな文化を設定できて、workingセットをプログラマが明示的に検索(発見プロセスはOSが提供)して設定すればいいんじゃないかしら？
それが新しいOS(資源仮想化システム)上のプログラミング規範にならないだろうか？
うーん、多分ほとんど変わらないかもだな。あるとすれば、システム管理関係のコードがばっさり減るということだろうか。
どうでもいい与太話
メモリ内部はみんな別世界なのだ。あるタスクが実行する環境を仮想化して、他のプロセスから隔絶するのがOSの役目。
しかるに、スレッドという技術は、共有の境目をあいまいにしている。いや、全部共有してるんだ！という言い方もできるかもしれないが、固有のcomputationをするには固有の環境があるはずで、その境界をどう設定するかは並列処理の粒度（パフォーマンスの考察の基準だろう）を考えたりするうえで肝のはず。
本来、並列処理の開始に際してcopy on writeをOSがまじめにやれば、固有の環境と、プロセス間通信する部分だけを明示的にとりだして書いて、安全かつ粒度が明示的な並列処理ができてもいいはずだ。明示的に書くところをサボらせたら、結局プログラマのためにならないかもしれない。
