Servlet Garden

JVM上で動かすダイナミック言語のためのアーキテクチャを検討し、プロトタイプを作成するための”The Da Vinci Machine Project”(http://openjdk.java.net/projects/mlvm/)が始動したようです。プロジェクトが発足したアナウンスはマクロソフトのLang.NET Symposiumで行われたらしいのですが、そのときの模様がJohn Rose氏のブログBravo for the dynamic runtime!で紹介されています。
勝手に和訳第4弾はこのブログです。

==================

John Rose: Bravo for the dynamic runtime!

今週、Sunから何人かがLang.NET Symposiumに参加してきました。シンポジウムは実に技術的な内容のもので、一つの部屋が埋まらないほどの参加者しか集まりませんでした。このため、プレゼンテーションと話合いはN-3: Nerd-to-Nerd Networking(訳注：おたくとおたくの情報交換会(?))とでも言えるようなきめの細かい演習となりました。ときには参加者が率直にアイディアを出してくれることすらありました。ブラボー、Anders, Jim, Erik, Gilad, Pelo, Jeffrey。主催者はSunからやってきた三人を親切に迎え入れてくれました：ここで、Dan IngallsがLively Kernalについて説明し、Charles Nutterと私がダ・ビンチ・マシンプロジェクトを紹介しました。

カンファレンスの中心となっているのはもちろんマクロソフトのCommon Language Runtimeで、特にDynamic Language Runtimeと、Jim Huguninのアンコールだったものですが、CLR(Common Language Runtime)の上にダイナミック言語が張り付けられた状態だったところから、再利用可能なロジックを取り出したIronPythonでした。(訳注：IronRubyのアンコールでIronPythonか?)

なぜ私が急にマイクロソフトのテクノロジーに興味が湧いたかですか？理由は2,3あります。まず、DLR(IronPythonとIronRubyを含む)はわれわれがプログラミング言語設計のルネッサンスあるいは再生期にいるという別の方向からの証拠になっているからです。とあるきっかけのために、人々は繰り返し、大幅に違うプログラミング言語を考え出しています。そのときには、注目してくれる人がいることを期待して、あるいはそういう人達を取り込もうとしています。おそらく”とあるきっかけ”とはよりよいツールを求めるため、より優秀なランタイムを作るため、できるだけ少ないCPU cycles(計算量)で済ませるため、そしてオープンソース化の動きが入り交じったものでしょう。

このような新しい事情はとても古い発想に面白いほど強く結び付いてきています。(“とても古い”といってもコンピューティングの世界ではという意味で、50年以内の話です。)どういうわけか、いくつかの基本概念はすでに初期の段階で作り上げられています。ここで私が指しているのは、構文(具象、抽象、”糖衣”)、データ構造(手続的、オブジェクト指向的、関数的、シンボリック、リレーショナルを含む)、探求的プログラミング(訳注： exploratory programming. APIなどの機能を調べるために書くちょっとしたプログラム。参照)のアイディア、プログラム、データ、テキスト間での完全な変換、宣言型表記や命令型表記、辞書的スコープや動的スコープにメッセージに基づくスコープ、最大限の言語や最小限の言語あるいは拡張的な言語、クロージャ、継続、リフレクション、ガベージコレクション、キャッシング、遅延評価、などです。(こんなに長く、味気もなく並べてすみません。この羅列を改善してくれるようなちょうどよいレトロスペクティブな(振り返りの)調査を行っているところへの参照を教えてもらえるとうれしいです。)Peter Landinのような人達は1960年代にすでにプログラミング言語の概観を描いていました。これは今でも驚くほど有用なので、わずかにカテゴリが変わった程度です。

(付記: シンポジウムはデータ駆動型プログラミングやXMLの利点といった他のことについてのレクチャをして終わりました。最終的に現在盛ん言われているXMLとJSONのメリットは何かについての意見交換になりました。これは私にとっては新しいものです。意見交換が強健性と簡潔性について言及されなくなってきたところで、私は堂々と”S式だ!”と提案しました。50年の歴史を持つLispのシンタックスでおそらく一番強健で、標準的で簡潔だと思っています。)

歴史のための歴史の話はじつにに楽しいと思いますが、私が本当に興味をもっているのは古いテーマにおける新しい変化を観測することです。つまり、ここまでのところはまったく古い用語という観点からRubyのような新しい言語を特徴づける(C言語のシンタックスで記述するLispのように)ための情報提供です。休眠状態にあるアイディアが広く実用的に使われるようになるのはとても面白いものです。例えば、Javaはガベージコレクションを普及させていますし、HotSpotはもともとSmalltalkやSelfといった言語で発達したメッセージ最適化技術を採用しています。DLRに関しては、もしこの技術がプログラミング可能なメタオブジェクト・プロトコルにまで拡張できるとしたらとてもおもしろいと思います。

このブログの読者ならご存じだとおもいますが、SunはJVMの能力をダイナミックな言語実装に適用する際に発生する難しい問題を扱うために設計と開発を続けてきました。二つ目に、Redmondで(Microsoftの人達共々)とてもおもしろいと思ったことは、一方でCLR上でDLRを開発しようとしているのと同時に、他方ではJVM上にダ・ビンチ・マシンを開発しようとしていたまさにその事実です。私の順番はJimが話して間もなくまわってきたのですが、(そのとき言いましたが)やろうと思っていたほど説明しませんでした。というのはJimがDLRに関して非常に似通ったアーキテクチャの解説をすでにおこなっていたからです。JVM上での動的な呼出しを行うにあたり私がやっているのは、Smalltalk、Self、CLOSといった言語でかつて採用されていたアイディアを適用しただけであることは承知でしたが、同僚(や競合相手)がそういったアイディアの実用性を証明するのに一生懸命になっていたことを知って目が覚める思いをしました。

CLR拡張とJVM拡張の違いは興味深いので書き留めておこうと思います。彼ら特にCLRにうまい改良を加えたりはせずに、完全にCLRの上位層だけ行っています。一方、我々はJVMとライブラリも同時に開発しています。私はJVMに集中的に取り組んできましたが、Charles NutterはJVMに適合するようにJRubyを再構築する素晴らしい作業を続けてきました。JRubyに関する作業はツリー構造内を渡り歩いて解析する方法から、JVMが最適化するのに好ましいバイトコードのたぐいを吐き出すコンパイラ方式にJRubyを改造することになりました。我々がやっているのはあたかも大陸横断鉄道を作るかのようなもので、西からJVMの鉄道を敷き、東からJRubyを敷いているかのようです。我々は今年、黄金の犬釘(訳注:鉄道が完成するときに最後に打ち込む犬釘のこと)を打とうとしているところです。

アプローチの方法に違いがあるのは、ひとつは、マイクロソフトのCLR JITが開発過程で表面に現れてこないという点です。CLR JITの最適化レベルはJavaのJITが一番最初に行っていた程度の初歩的なものです。CLRの場合、その程度のパフォーマンス向上が現在動いているコードが許容できる範囲内なのです。CLRにはインライン・インタフェース呼出しの概念も、ダイナミックなプロファイルを行うコンパイルの概念もありません。このため、DLRが能力を発揮できるのはDLR自身が管理できる小さなcallサイトオブジェクトの中だけに限られています。オンラインの型情報をインラインに使えるような、また、巨大なバイトコードの巻物でも最適化できるようなVMに素晴らしいコンパイラがあるということがどれほど驚くべきことかということをわれわれSunの人間は(その場にいた人たちもまた)新たに認識しました。

また、DLRと我々のものとでは、我々の設計(訳注:参照)にはメソッドのガードとターゲットがあるのに対して、彼らの設計にはテストとガードがあるという違いもあります。(CLOSの呼出しプロトコルは関数と適用可能なメソッドの識別に言及しています。)このようなシステムは全て、既知のメソッド(up-call)が一つ以上のターゲットメソッドを利用してcallサイトを配備し、各ターゲットメソッドには引数テストのルールが関連付けられています。

ここでの違いは何でしょうか?DLRの既知のメソッドは抽象シンタックス・ツリーのペアとしてターゲットとテストを表現しています。この抽象シンタックス・ツリーはDLRの下位層が新しいバージョンのcallサイトをコンパイルするためにひとつ前のASTと結合するものです。ダ・ビンチ・マシンの設計ではガードとターゲットをメソッド・ハンドルを呼び出すひと塊の振舞にまとめます。ダイナミックな呼出しサイトにはこのようなハンドルの小さな集まりがあります。(現在、JRubyはJVMの上位レベルでこのパターンをシミュレートしています。)JVMのインタープリタはそれぞれをひたむきに実行し、成功することを期待して、また、ガードのロジックが失敗に終わった場合に投げられるはずの小さな例外をさばきながらふるいにかけていくことになります。

いずれはJITの影響が現われ始め、callサイトの状態を監視し、callサイトを見ているメソッド・ハンドルに基づいてうまく最適化された決定木を生成することになります。(メソッド・ハンドルは不変なので、もしその方がいいのなら、その構造を完全にインライン化できます。)JVMにとっては軽い処理なので、JVMになら例外を使ってcallサイトの構成を行う余裕があります。私はCLRのアーキテクチャでは例外を単なる”goto”ジャンプ命令にコンパイルするのがほとんど不可能であることをRedmondは知って驚きました。これは彼らのJITがあまり最適化を行わないばかりではなく、CLRの例外がJavaよりもかなり複雑なセマンテックスになっていることが理由でした。HotspotはJVM98パフォーマンス競争以来、例外を最適化しつづけています。これで思い出したのですが:すなわちJavaの生態系においては競争はなんとも偉大だということです。Hotspotは適当な標準ベンチマークのおかげで、また他のJVMとの競争によって現在のように速くなっています。

この話からは金についての別のメタファが思い起こされます：Redmondでは(上記のように)Hotspotや他のJVM上に構築されているシステムはパフォーマンスの金鉱脈の上にあるのだということがわかりました。DLR上のIronPythonはCLR JITのあまりよくないパフォーマンス・プロファイルに付いているしわを”アイロンがけして(iron)”伸ばすために困難であっても優秀な働きをしなければならない一方で、”皮肉にも(irony)”Hostspotはすでに10年近くもの間、高度に動的なプログラムをすでに最適化してきているのです。JRubyはすでにJIT最適化という金鉱脈をコツコツと叩いていて、ベンチマークでパフォーマンスのよさを証明してきています。オリジナルのC言語で記述されたバージョンのRubyよりも素晴らしい数値さえ出ています。単にここからよくなれるだけです。(Jim、みなさん、治金学上の語呂合わせを許してくれると願っています。私の中のスコットランド人の血が安っぽい笑いが好きだというだけです。)

私がマクロソフトのDLRにわくわく感を持つ理由のうち最後の一つは、利用者がCLR上に登場してくる様々な新しい言語を喜んで使ってくれるので、そういう態度を見てうれしいと感じられるところです。プラットフォームが強固でCPUサイクルも少ないので、今こそ、そのような言語が台頭してくる時です。しかし、想像できるとは思いますが、私はJVMの利用者にはさらにうれしさを感じます。彼らもまた、解放的なオープンソースコミュニティの中で灼けるように熱くて速いJava仮想マシン上で新しい言語を喜んで使ってくれるからです。SunのHotpostで始めている(と願っています)はずです。

ブラボー、言語設計の新しい黄金時代、そして、ハイレベル言語のルネッサンス！

This entry was posted on Tuesday, February 5th, 2008 at 6:31 pm and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.