.netは100年の計。で、JavaVMは？
JavaVM自体は、良くできています。好きです。AOTアセンブラやバイトコードVMとオブジェクトエンジンを作ったり、Javaバイトコードをはき出すオレオレコンパイラを作るくらいには好きです。
けど、全体的に16bitの呪縛(methodやinterfaceに16bit決めうちのところが結構ある)や32bitの呪縛(実はJavaのポインタやフィールドは32bit。doubleやlongを使うときには「特例扱い」しなくちゃならない)が大きくて、不定長命令のくせに32bitアラインしなくちゃならない命令があったり(lookupswitchとtableswitch)、巨大なJavaのプログラムというのは動かしづらかったりします。
もちろん、Javaもコンポーネント同士がプロセス間通信でやりとりをするという前提があるのであれば、VMインスタンスを複数持つことで巨大なJavaのプログラムを作ることはできるのですが、あんまりRPC強力じゃないのが残念なところ。
何よりも、「一つのVMインスタンスですべてのプログラムを動かす」JavaOSみたいなものを作るとすると、それは組み込み用の小さいOSにならざるを得ず、たとえばメインフレームみたいなものは作れないです。
その点、.net FrameworkのCLRで動くメインフレームなんてものは容易に作れます。IBMのAS/400を考えると何ら珍しいことじゃないんですけど。
で、重要なこととして、速度方面でのムーアの法則は少し遅くなってきましたが、コンピュータシステムと見たときの全体のムーアの法則は相変わらず有り続けているので、今のメインフレームが次の世代のPCレベルに落ち、さらに組み込みに落ちる日はそんなに遠くないと思われるのです。今のUnix like OSの組み込みへの使われ具合を見ていると、わずか10年前には「ワークステーション用の高度なOS」としてオーバーヘッドが大きい環境と思われていたのが嘘のようです。
今のコンピュータが死に絶える2038年(Unix like OS。Windows由来のOSは2036年)までに次の時代の覇権を争うとしても、その頃にはJavaは「組み込み用の小さいシステムに最適な小回りのきくVM」としては残っているかもしれませんが、少なくとも「メインフレームに使えるVM」としては残ってる可能性は少ないです。その点、CLRはまかり間違うと「メインフレームから組み込みまで全部カバーするVM」になっている可能性があります。
もちろん、そのためには乗り越えなければならない壁はいろいろありますが、まだ20年あります。20年あれば、ムーアの法則が「24ヶ月でトランジスタ数が倍に」と低く見積もっても現在の1024(2^10)倍の性能になり、これは一次記憶で言うとボリュームゾーンのbit数が10増え42bitくらい、性能で言うとDMIPSみたいな指標がT(10^12)からZ(10^21)のサブ単位になることを示しています。
今で32bitですでにいっぱいいっぱいのJavaは今のバイトコードとオブジェクト構造を保持し続ける限りすでにもう限界といえます。これが100年だと1.13e15(2^50)倍。一次記憶のデータ構造で言うと82(32+50)bitくらいでしょうか。なので、今のうちに128bitに手を出しておくのは100年の計としては重要だと思えるのです。
……その前にOracleがJavaを手放しそうな気はするけど。OracleのターゲットはIAサーバーからメインフレームだろうしなぁ。
(追記)
ぐはぁ、ゴスリングさんがOracle辞めてるよ。
JavaのイニシアチブをOracleが取らなくなって、HotSpotJavaVMの開発が止まって、Javaの仕様策定がボランティアベースになって、徐々に下火という未来が一気に見えた気がする。「Javaは6位の頃が一番勢いがあったよね」とか。
Javaという仕様を保守するボランティア団体が凄い強い権力を行使しないとまずいことになるような。IBMやHPやBEAの独自JavaVMが独自拡張の果てにみんなJavaを見捨てるという悪夢のような未来が(ちなみに、これにはOHAもかなり荷担してるんだよなぁ。Dalvikは「JavaVMではない」ので)。
