VMかCPUか、ハイパーバイザーか

思考の流れメモ 仮想化 与太話

碌にコードが書けない自分がこんなことを言うのは正気の沙汰ではないけれど、JRuby KaigiのTLやJRuby Hacking Guideのプレゼン資料で思い出したCharles Nutterの日本語JRuby: 今のJVMに欠けている物を読み返して、SunとともにJVMも「ごくろうさん」なのではないか、という思いにとらわれた。
自分がそう思うということは、すでにJavaの周辺ではずーーーーーーっと前から、よりよいVMについての代替案が模索されていたに違いない。
Virtual Machineであるからには、Real Machineの変化に応じて世代交代してもいいのではないかと思う。ソフトウェアの世界では互換性大事だが、マルチコアと仮想化、分散処理を意識してCPUの世界が変化しているこのタイミングならば、新しい分野にフィットしたVMがしがらみ抜きでニッチをせしめる可能性が無くは無い。そして、そのVMというものが、JVMと同じような構成であるとも限らない。
自分が最も注目している（自分が興味あるからであって、世の中の主流になると予想しているわけではない）のは、マイクロカーネルの極地ともいえるXen、Xen(Hyper-Vか)のドライバドメインを豊富なベンダーリソースで充実させるMicrosoftの力、そして、軽量プロセスを実現するErlang VM(同様のものならなんでもいいが)だ。クラウド側のサービスは、これをベースにして再構成していけないものだろうかと夢想している。その時に、仮想化されたゲストOSが壁になる、というのはちょっとダサい。サービス単位でプロセスのグルーピングができて、それらの相互作用をゼロにできる、ということを誰だって望んでいるわけで、kernelモジュールのコピーがプロセスグループ毎にあって欲しい等とは思っていないはずだ。だから、ドライバドメイン(通常はDom-0だが、別ドメインでも構わない)にはカーネルの大部分の実体も集約したい。（KVMがそういう方向なのか、どうかはよくわかっていない）

(追記)GoogleのAndroidを「勉強」したいとはあまり思わない

互換性はそれなりに意識されているみたいだから。
検索エンジンを支える巨大データセンターではどうなんだろう。とは思うが、読んでしまうとなんもすることが残って無いことに気づいてしまうからな。近寄らない。万が一、自分一人が再発明の無駄をしたところで人類には何の被害もない。そして、少なくとも自分は楽しい。これ大事。

ところで、プロセスのまとまりでうんちゃらっていう例：lxc

LXC: Linux コンテナー・ツール
今はどれくらい使われてるんだろう。

（さらに迷走）プロセスの操作について

forkって、プロセスの生きたままのmarshallingではないかという思いにとらわれつつある。live migrationができるなら、それをプロセス単位でやれるにはどうするか、、いや、IOというかworldがOSそのものだから、OSのmigrationになっちゃうんだよ、というのが今の縛り。それを変えられるだろうか？
手元のLinux(kernel 2.6.x)で　lsof -p xxxx (TCPsocketを開いているrubyのコード)の結果が以下のようだったとして、forkはこれも持っていくわけだ。今のLinuxだとcopy on writeだから、複製といったって、差異がでるまではコードとワークエリアのコピーは始まらないし、memory上にマップされたDLLなども、本尊がドライバドメイン上に1個あれば済む話だ。（「同じ名前で」いろんなバージョンのライブラリを使い分けたい、とかいう話はありそうだが、それを同一のドライバドメインちうかハイパーバイザーでホストするのはVMwareでOS分けてやってくださいという気持ち）*1

# lsof -p xxxxx
COMMAND   PID   USER   FD   TYPE DEVICE    SIZE   NODE NAME
ruby    xxxxx ore  cwd    DIR  253,0    4096 689902 /home/ore
ruby    xxxxx ore  rtd    DIR  253,0    4096      2 /
ruby    xxxxx ore  txt    REG  253,0    5780 178344 /usr/bin/ruby
ruby    xxxxx ore  mem    REG  253,0   45288 720966 /lib/libcrypt-2.5.so
（ライブラリんところは略）
ruby    xxxxx ore  mem    REG  253,0  208352 721141 /lib/libm-2.5.so
ruby    xxxxx ore  mem    REG  253,0   46680 720935 /lib/libnss_files-2.5.so
ruby    xxxxx ore    0u   CHR  136,0              2 /dev/pts/0 (deleted)
ruby    xxxxx ore    1u   CHR  136,0              2 /dev/pts/0 (deleted)
ruby    xxxxx ore    2u   CHR  136,0              2 /dev/pts/0 (deleted)
ruby    xxxxx ore    3u  IPv4 725793            TCP *:xxxxxx (LISTEN)

以下、あんまり迷走しているので、まとまることがあったら書こう。

まずやるべきは、実装のネタ・妄想ではなくて、テストケース、traitをはっきりさせることだ。その結果、JVMでオッケーということにもなるだろう。

追記：後で読む

［速報］VMworld 2010、クラウド時代の新たなスタックが登場し、OSは消えていく － Publickey
結局のところメインフレームやんか！というオチは「今回は」ナシにしてほしいもんだ。単なる野次馬としての意見。

追記：こんなものの上で何動かしたいか

シナプスとかかしら。いやそれならもっとふさわしいものがあるような気がするが、やりたいこと優先ということでｗ

*1:追記：考えてみると、プロセスグループごとにOSの諸々をくっつけちゃっても、コードの本尊は1個で、コンテキストとデータがきちんと仮想化されてればいいのだという話だと思う。ドライバドメインで全部やるとしたら、ドライバドメインのコードが仮想化の負担を負うことになるだけだ。だからOSが仮想化の単位であっても、それほど無駄は無く実装可能な気がしてきた。もし、ドライバドメインに丸投げするメリットがあるとすれば、ドライバが仮想化されることによって、ゲストOS：プロセス群側ではドライバi/fが効率良く書ける可能性があることかな。