2007-08-04 (Sat)
▲ VM魂
LL魂へ行ってきた。どのセッションも興味深 かったが特にVM魂 について感想をまとめてみる。
DLR
.NetのDLRは、Python、JavaScript、RubyなどDLR上に実装した他のLLとのバイ ディングを提供し、たとえばRubyからPythonのライブラリを呼び出したり、相 互に資産を活用することができるようになるそうだ。なるほど。本当に実現す ると素晴らしいシステム。もしからしたらWebサービスやJSONを使わなくても システム間連携できるようになるのかもしれない。
しかしライブラリは往々にして特定の言語のために実装する。JavaScript用に 書かれたライブラリが果たしてRubyにとって使いやすいものか。また、ターゲッ トの言語のトリックに強く依存しているライブラリ*1 も多い。
言語間の連携ではRhinoの例で紹介されていたようにセマンティックギャップを 埋めるため専用のインターフェースを実装する*2 必要があったり、世の中にCのライブラリを呼び出すためのたくさんのwrapper ライブラリが存在していることから考えて、DLRが実現しようとしている壮大さ に思いを馳せたのであった。
VMを使う利点
VMを使う利点として「.NetやJavaのクラスがシームレスに呼び出せる」など利 用者の視点が強調されていた。他に実装側のとしてのメリットもあると思った。 JavaVMのようにプラットフォームを抽象化するVM が存在することで*3 CPUやOSに依存するプラットフォーム依存のコードを書かずに多様な環境で動 作できるのは実装が楽になるメリットのひとつ。
しかし、これに関連してJRubyのIOライブラリ周りで悩んでいるのがCRubyのプ ラットフォームによる挙動の違いだ。CRubyは、Unixで動かしたときとWindows で動かしたときと、さらにWindowsでもCygwinでコンパイルしたときと、微妙 に動きが異なる部分がある。たとえば改行コードやパスセパレータなど。
これらを厳密にJRuby側でも合わせようとするとせっかくVMが隠蔽したプラッ トフォームの差異を、また剥き出しにしてやるようなプログラムが必要になる。 JavaなのにWindowsではこう動けとかそんな感じ。
そんなわけでせっかく書かずにすんだプラットフォーム依存のコードを、再び 持ち込む話になってしまうのでVMを使った場合でも、「何の上で動くVM」をター ゲットにするかある程度しぼりこんだほうがよさそう。JRubyの場合はそれが Unix上のJavaVMなんだろう。
