JSR-292 の草案レビューが発表される

作者 R.J. Lorimer, 翻訳者 岡田 英久 投稿日 2008年6月12日 午前8時38分

コミュニティ

Java

トピック

言語設計,

JCP Standards,

アナウンス,

動的言語,

パフォーマンス&スケーラビリティ

タグ

JVM,

言語,

JCP

John Rose 氏(source)の発表によると、JSR-292(source) の草案レビューが JavaOne のすぐ後に続いてリリースされた(source)。JSR-292(source) は Java 仮想マシンに invokedynamic 命令を定義しようとするものだ。

InfoQ は昨年 10 月、invokedynamic のような技術の試験台といえる Da Vinci Machine プロジェクト(source)の発表に際して JSR-292 について触れている(参考記事)。

JSR-292 のスペックリードで MLVM を支える第一人者でもある John Rose 氏は、JVM を動的言語からよりアクセスしやすくすることに関して、自分のブログで定期的な議論を行っている。Rose 氏は JSR-292 提案の理由を次のように述べている(source)。

なぜ新しい呼び出し用バイトコードが必要か。その答えは、呼び出しサイト（呼び出し用バイトコードのインスタンス）が有用で、なおかつ、呼び出しのための既存の方法は Java 言語と密接にむすびついているため、JVM にそもそも備わっている機能を他の言語が完全に利用することはできないからである。主に次のような制約がある。

• レシーバの型が呼び出しサイトの解決された型と一致しなければならない
• 呼び出しターゲットをラップするアダプタを作成する一般的な方法がない（これはひとつ前の項目から必然的に導かれる）
• 呼び出しサイトはリンクされなければならない。つまり解決されたメソッドは常に先に存在していなければならない
• シンボリックな呼び出し名は、実際のメソッドの名前である（ひとつ前の項目から必然的に導かれる）
• 引数のマッチングは暗黙的な強制なしに正確である（これも同様に導かれる）
• リンクの解決を逆にすることはできない（目に見えないところで最適化の解決は変更されるが）

動的言語の実装者はこれらの制限をどう扱うかに多くのエネルギーと時間を費やしている。Java 言語によって制約をうけている JVM の呼び出しバイトコードを使って、他言語における呼び出しをシミュレートしているのである。

同エントリで彼は、JSR-292 チームが提案しているソリューションについても述べている。

これらの要求に対する私たちのソリューションは三つのステップからなる。最初のステップでは、振る舞いの単位であるメソッドを管理するための簡単で汎用的な方法としてメソッドハンドル(source)を導入する。メソッドハンドルは、直接呼び出すことが可能だ（メソッドは本来そうあるべきだが）。次に、invokedynamic 命令を定義する。この命令は、リンク状態を表わすマシンワードである、呼び出しサイトのターゲットメソッドのハンドルを必要とする。最後に、リンク状態の管理や呼び出しサイトのためのターゲットメソッドハンドルの生成を行うコア Java API を定義する。これらの API は JVM に適切な最適化の機会を提供することもできることに注意してほしい。

草案レビューが発表されたことで 2008 年 8 月 17 日まで 90 日間にわたる JSR のレビュー期間がはじまる。レビュー期間中に情報を得たり、JSR にフィードバックを提供する場合、次のような方法がある。

• JSR-292 オブザーバメーリングリスト(source)に参加する
• JVM Languages(source) Google グループに参加する
• John Rose 氏のブログ(source)と MLVM のホームページ(source)をチェックする

InfoQ は今後も JSR-292 を追跡し、Java コミュニティ(source)に最新情報を提供していくつもりだ。


原文はこちらです：     http://www.infoq.com/news/2008/05/jsr_292_edr

• 次へ >