実行時コンパイラによる Java 仮想マシンの分散オブジェクト対応 ∗
首藤 一幸

村岡 洋一

{shudoh,muraoka}@muraoka.info.waseda.ac.jp

早稲田大学 理工学部

1

中間言語を利用せずにプロセッサのレジスタを有効に活用するのは難しい。shuJIT と同様にほぼ 直接コード 生成を行う JIT TYA[4] では複数のバイトコード 命令をまたいで利用できているレジスタはひとつだけである。shuJIT では複数のレジスタを利用するため、stack states という考え方を導入した(図 1)。コード 生成を高速に行うため、あらかじめ各バイトコード 命令とそれぞれの stack states に応じたネイティブコード が用意してある。

はじめにJava 仮想マシン (JVM) は 、実行時に Java バイ
トコード をプロセッサのネイティブコード に変換する Just In Time コンパイラ (JIT) を持つことが一般的である。通常、JIT にはバイトコード の高速実行しか期待されていない。JIT は JVM の仕様通りの動作をするネイティブコード を生成する必要がある。
生成されたネイティブ コード の動作がすなわちJVM の動作なので 、JIT がバイトコード の解釈を決めていると言える。JIT が生成するコード を変更できれば 、JVM によるバイトコード の解釈を変えられる。
我々は JIT のこの性質を利用して分散透明な分散オブジェクトシステム JITDO(Just In Time Distributed Object) を研究、開発し ている。JITDO
は 、通常の JVM ではローカルな操作となるバイトコード 命令を、ネットワークの先の遠隔オブジェクトに対する操作が可能なネイティブコード にコンパイルする。操作対象のオブジェクトが遠隔オブジェクトであった場合、その操作は遠隔の JVM にリダイレクトされる。
プログラマは、遠隔オブジェクトの生成、遠隔メソッド 呼び出しを、ローカルオブジェクトに対する通常の文法で行える。また、既存のシステム [3][5]では行えなかったフィールド アクセスも行える。つまり、遠隔オブジェクトをローカルオブジェクトとほぼ同様に扱える。

2

Making a cache of stack top on registers
stackTYA (JIT for Linux)’s Method
topEAX
memory.....

registershuJIT’s Method
memorymemorymemory.....
state 0EDX
memorymemory.....
state 1ECX
EDX
memory.....
state 2ECX
memorymemory.....
state 3EDX
ECX
memory.....
state 4

図 1: stack statesCaﬀeineMark 3.0[1] で 、バイトコード インタプ
リタ、TYA 、shuJIT の性能を比較し た。環境はPentium with MMX tech./233MHz 、Linux 2.0.36 、Linux 用 JDK 1.1.7v1a である。TYA と同等以上の項目が多いが 、メソッド 呼び出し性能が String 、Method にあらわれている。





shuJIT – x86 用 JITJITDO は、我々が開発した shuJIT[2] を元に開発されている。shuJIT は Sun の JVM(JDK,JRE)、
Linux および FreeBSD、Intel x86 プロセッサ用のJIT コンパイラである。
JIT はプログラムの実行中にコンパイルを行うのでコンパイル時間の短さも重要である。shuJIT は中間言語への変換を行わない。3 パスのコンパイルでほぼ直接バイトコード をネイティブコードに変換する。


 

   

図 2: shuJIT の性能評価

3∗ Adaptation of Java Virtual Machine

for Distributed Object with Just In Time Compiler
Kazuyuki SHUDO, Yoichi MURAOKA
School of Science and Engineering, Waseda Univ.

構造

既存システムでは、遠隔オブジェクトの代理オブジェクトがローカルに存在し 、遠隔オブジェクトと1

5signature(セレクタ) が同じ メソッド を持ち、メソッド 呼び出しを遠隔オブジェクトに中継する。JITDO
では中継されるのはメソッド 呼び出しではなくバイトコード 命令である。メソッド 呼び出し 、フィールド アクセスなど オブジェクトに対する操作を行うバ
イトコード 命令が 、JITDO が生成したネイティブコード によって遠隔オブジェクトに中継される。

bytecode
instructions

AnObject

ProxyObject

現在実装を進めていて、ごく簡単なプログラムが動いている段階である。
JITDO は既存システムより分散透明である。遠隔オブジェクトの生成を通常の Java 言語の文法で行え、フィールド アクセスが可能で、遠隔参照と実際の遠隔オブジェクトの型の不一致がない。
反面、ローカルオブジェクトの操作が遅くなることが予想される。操作対象のオブジェクトがローカルか遠隔の判断がオブジェクトへの操作ごとに動的に為されるためである。
オブジェクトの位置を実行時に判断するから実行速度が低下する。現在のプ ログラミング インタ
フェースではオブジェクト生成先 JVM は Java プ
ログラム中で指定されるので 、Java プログラムをコンパイルする際に静的に前処理を行い、遠隔オブジェクトの操作を適当なコード に展開してし まう手法も考えられる。しかしこの手法にはバイトコードの量が爆発しかねないという問題がある。メソッドの引数それぞれについて遠隔、ローカル双方を考慮し 、組合せご との展開結果を用意する必要がある。
Java のコンパイル単位であるクラスについてこの組合せ数は爆発し得る。インライン展開で軽減できるものの本質的な解決にはならない。
オブジェクト生成先 JVM を Java プログラムの外から動的に変更、制御することを計画している。
JVM ごとのメモリ使用量を調整するといった応用が考えられる。この場合オブジェクトの存在場所の動的な判断が必要であり、静的な前処理では対応できない。

The Netex)getfield

RequestManager

Native Codegenerated by JITDO
Illusion

AnObject

Remote of remote object
Object

現状および他手法との比較

RemoteObject

図 3: オブジェクトに対する操作のリダ イレクトJITDO は 、操作対象オブジェクトがローカルオブジェクトなのか代理オブジェクトなのかを判断して挙動を変えるネイティブコード を生成する。次の各バイトコード 命令について、通常の JIT とは 異なるコード を生成する必要がある。
• オブジェクトの生成– 配列以外 – new– 配列  – newarray, anewarray• アクセス– フィールド – putfield, getfield– 配列  – [ilfdabcsa]aload, [ilfdabcsa]astore• メソッド 呼び出し –invoke{virtual,special,interface}• 型チェック – checkcast, instanceof

6

まとめ

遠隔オブジェクトがさもローカルに存在するかのように見せるため、オブジェクトの型をチェックする命令の挙動も変える必要がある。
現在の設計では配列  は遠隔オブジェクトにはせず、必ずローカルオブジェクトとしている。配列を遠隔オブジェクトとしたい局面もあるので、妥当な制御法を考えている。

我々が設計、実装している分散オブジェクトシス
テム JITDO について、ベースとしている shuJITのコード 生成手法と性能、JITDO の構造とプログ
ラミング インタフェースを述べ、既存システムや他の手法との比較を行った。
今後は実装、性能評価を進めていく。

4

参考文献

プログラミングインタフェース[1] CaﬀeineMark 3.0.
http://www.pendragonsoftware.com/pendragon/cm3/.

通常の Java 言語に加えて唯一必要なのは 、オブジェクトの生成先 JVM を指定する手段である。
VMAddress addr =new VMAddress("foo.bar.com", 10000);
JitdoController.setInstantiationVM(addr);
その時点で制御を握っているスレッド に生成先JVM が対応付けられる。以後、このスレッド からのオブジェクト生成はここで指定した JVM 上で行われる。

[2] shuJIT: JIT compiler for
http://www.shudo.net/jit/.

Sun

JVM/x86.

[3] Sun Microsystems. JavaT M Remote Method Invocation Specification, 1997.
[4] TYA Archive. http://tya.home.ml.org/.
[5] ObjectSpace:
Products:
Voyager.
http://www.objectspace.com/products/Voyager/.

2