VM経由のアプリ実行

昔からバイトコードVMという考え方が結構お気に入りだったりしてはいたのですが、MSIL(.Net Frameworkで使っているバイトコード)経由でアプリを動かしたりしていると、結構いろいろと思うところが出てきます。
Javaもかなり気に入っている環境なのですが、今回はMSILの話だけで。

動いているプログラムって、本来実現する必要のあるアルゴリズムの記述以外に、結構無関係なコードが含まれてしまっていると思います。それは、最適化のための工夫だったり、OSのスケーラビリティを確保するためのお約束だったり、ハードウェアの設計に由来するものだったりと、無意味なものではないのですが、アルゴリズムのシンプルさとは無関係です。
ここで、バイトコードVMによってかなりの処理が抽象化できるのであれば、その手の「お約束」をVMコードのレベルでそもそも書かなくても良くなって、結果としてバイナリのサイズとか、最適化のためのコストとかが削減されるんだろうな、と。
それどころか、CPUや動作する環境（これは、インストール後であっても変わり得るはず）によって最適化の方法論を変えれば、「今求められてるベネフィット」に最も適した形でアプリケーションを動かせるとまで思っています。
VMによるデメリットもたしかに皆無ではありません。でも、トータルのコストとしてはシステムが大きくなるにつれて低くなると思っています。
たとえば、JITによるネイティブコードへの変換もそれ自体はコンパイラの容量や、コンパイルに使うCPU時間などのせいでかなりコスト高には見えますが、CPU時間はJITされたコードのキャッシングと共有で減らすことができますし、コンパイラに必要な容量も、アプリケーションが増えてくれば、個々のアプリケーションによる削減分で相殺されるでしょうし。
ただ、この発想は、「個々のVM上のアプリが増えてくる」ことによってやっと意味をなすので、VM上のアプリが微々たる量しかない状態ではたいしてメリットはありません。なので、できることならばOS上で動くアプリの大半が（できれば全部が）VM上で駆動する、というか、OS自体がバイトコードVMだとそのおいしさを最大限吸えるよね、という方向に環境を持っていく形になります。
まさにMicrosoftが開発環境としてManagedコードの.Net Frameworkを盛大に推していて、既存の開発環境を駆逐しちゃいそうな勢いなのは、この辺を狙ってるんだろうなぁ、という思惑が見えてきます。

実際、制限されたWindows Mobileという環境でアプリを作っていると切実に感じます。自分のアプリは結構小さめに作ってある(あ、国際化環境を入れたり、DLLに分けるとかやってるので、CABファイルは大きくなってますが(^^;))のに、実行するためのオーバーヘッドはそこそこ大きくなっちゃってて、これはきっと他のアプリも.Net Compact Framework上で動くようにすれば、きっともっと効率的に動くだろうな、といつも思うのです。
これは、Zaurus上でJ2MEPPで作っていたころとはだいぶ違った感触です。Zaurus上でのJavaは、しょせんアプリごとに立ち上げ直さなくちゃならない環境で、共有することによって効率が良くなるというものでもないですし、よしんば共有できるつくりになっていたとしても、どうせJ2MEPP上で動くアプリなんかほとんど存在しない状態でしたから、意識として「しょせんRun Anywhereを実現するためのネイティブの代用品」としか見ていませんでした。
それにくらべ、多分、Microsoftとしては、Windows Mobileからはネイティブコードを駆逐しちゃって、MSIL上のアプリだけが動くような状態にまで持っていきたいんじゃないのかとまで思います。提供されているディフォルトのアプリケーションをみる限りでは、まだまだたどりつけなさそうですけど。

ええと、論点がなんかとっ散らかってきましたが(^^;)、結論としては、

みんな怖がらずに.Net Compact Framework入れようよ

ということを言いたかったのでした。
いや、容量的な問題とかでけっこう.Net Compact Framework 2.0を入れたがらない人がいるようなので。
きっとその先に「約束された未来」って奴が広がっている……といいなぁ(^^;)（最後の最後で言いきれない(^^;)）