CLRとJVMにおける動的言語

作者 Charles Humble , 翻訳者 沼田 暁子 投稿日 2008年2月22日

セクション

デベロップメント

トピック

Jython ,

JRuby ,

IronRuby ,

Ruby ,

IronPython ,

Java ,

動的言語 ,

Python ,

.NET ,

言語 ,

プログラミング

共有 |

先ごろ、複数のSunのエンジニアがLang .NET Symposiumに参加した。John Rose氏とCharles Nutter氏は、.NETの開発者が大部分をしめる来場者に対し、SunのDa Vinci Machineプロジェクト(source)を紹介した。このプロジェクトは表面的にはMicrosoftのDynamic Language Runtime(source)（DLR）と類似しており、どちらのプロジェクトも、それぞれの仮想マシンでの動的言語のサポート改善を目指している。しかし、その問題に対するアプローチはかなり異なる。

DLR は、その大部分がJim Hugunin氏が作成したIronPythonに基づくもので、もっと簡単に.NETのCLR上で動的言語を実装するために設計されたライブラリやツールである。DLRは、（言語にとらわれない表現木による）コンパイラやインタプリタ生成、（動的呼び出しサイトの自動更新による）素早い動的実行、言語間でのメソッドのディスパッチや型システムのサポートのための機能を提供している。DLRの作業の大部分は、その基礎となっているCLRはほとんど変更せずに、DLRの上部のライブラリ群として行われた。

Da Vinciプロジェクトの範囲はもっと広く、動的言語と関数型言語の両方を対象としている。JSR-292に基づいて進められており、SunのリファレンスJVMの実験用ブランチの一つである。この仮想マシンには、Javaではない言語をJavaそのものに匹敵するレベルの性能で効率的に実行できるように、いくつかの拡張機能のプロトタイプが作成されるだろう。動的実行の実装は、重要なサブプロジェクトである。言語のコンパイラに対し、Javaではない呼び出しサイトのコンパイルを可能にするメカニズムを提供するが、これは実行時に呼び出しサイトのリンケージを決定する言語固有のハンドラによる。リンケージは動的引数の型に影響を受けやすい場合があり、時間とともに更新されたり破棄されるだろう。他にも、もっと小さなサブプロジェクト(source)があり、（新しい末尾呼び出しのバイトコードのプレフィックスによる）末尾呼び出しや末尾再帰のサポート追加や、（新しいタグ付きタプルの署名文字列を使った）タプルなどがある。その意図は、少なくともDa Vinci Machineのいくつかの機能で、Java SE 7 の仮想マシン仕様の一部を形にすることである。

シンポジウムへの参加に関するブログ記事の中で(source)John Rose氏は、JVMとCLRにおける新しいプログラミング言語への関心の高まりについて語っている。

「（IronPython やIronRubyを含む）DLRは、私達がプログラミング言語設計の、ある種の再生あるいは復活の時期にいることを示しています。何らかの理由で、人々は再び大々的ににプログラミング言語を考案していますが、関心を持ってもらうことを期待していますし、時には関心を持たれることもあります。私は「何らかの理由」というのは、より優れたツールや、もっと高いレベルの実行環境、もっとコストのかからないCPUサイクル、そしてオープンソースの動向が組み合わされたものだと思います。」

Rose氏はまた、Da Vinci MachineとDLRの類似点についても書いている。

CLR上のDLRとJVM上のDa Vinci Machineとの間には特筆すべき平行進化の事例があります... 私が作成しているJVMでの動的実行では、SmalltalkやSelf、CLOSで実証されているアイデアを適用していたことは自覚していましたが、同業者（であり競争相手）がこうしたアイデアの実用性の証明に忙しかったと知り、勇気付けられました。」

DLR はCLRそのものの変更を最小限にして実装されているため、DLRに対する開発の大半は、CLRとは離れたところで動的言語の性能を上げることに重点が置かれていた。Rose氏の主張によると、JVMのJITでは既にかなり積極的な最適化技術がサポートされているので、これはJavaの世界では重要ではない。Charles Nutter氏も、同じような意見を、このシンポジウム参加について書いたブログ記事(source)で述べている。

 「CLR には、JVMが備えているのと同じレベルの動的最適化が（まだ）ありません。特に、JITでは既にサポートされている、コードのデオプティマイズは今のところサポートされておらず、コードの最適化方法を検討する際に、型の情報が必ずしも含まれているとは限りません（時々？めったにない？）。ですから、動的言語の性能を出すためには、単に余分な作業をしなければならないのです。早くにJITできて、決して変更されないと当てにすることができる静的な呼び出しパスはありません。そのサイトから呼び出されるのはずっと同じコードであることが検証可能な形でわかっているので、呼び出しサイトを特定のメソッドの本体に結びつけることはできません。そして結局それは、プロファイリングやルールを構築した呼び出しサイトの自動更新、そして集められた情報に基づいたターゲットのセットを使い、そのような機能をあなた自身が実装しなければならないことを意味しています。」

もちろん、どちらのアプローチもそれぞれ長所と短所がある。Microsoftがとったライブラリのアプローチでは、市場に出すまでにかかる時間が短く、そして修正したものはCLRとは別に出荷することができる。Sunのアプローチはすでに優れた性能を出している（Da Vinciが無くても、JRubyは既にオリジナルのCコードのバージョンのRubyよりも優れたベンチマークの性能を示している）が、開発のサイクルはかなり長くかかっている。

原文はこちらです：http://www.infoq.com/news/2008/02/Da-Vinci-and-the-DLR