ARM Jazelle DBX / RCT

組み込み業界の人には当たり前のことかもしれないが...

ARM9*, ARM11* には Jazelle という Java bytecode 実行の機能がある。2001 頃に出てきたのが Jazelle DBX でこれは Hardware で Java bytecodeを実行する機能。もともとあった 32-bit の（ネイティブ）な ARM の命令、機能は若干劣るがコンパクトな 16-bit 系の Thumb に次ぐ第３の実行モードで、モデルによって異なるが、140 から 145 のバイトコードはプロセッサの命令として実行される。残りは特殊な命令でトラップ？させて ARM ネイティブ命令でエミュレートする。
エミュレートが必要となるのは普通のアプリケーションの 5% 程度。

また、新しいバイトコードへの対応は、とりあえず、このエミュレートをソフト的に追加することでできてしまう。

Jazelle DBX をサポートするプロセッサでは 'Branch-and-eXchange-to-Java'命令で Java state に入る。プロセッサの Current Processor State Register (CPSR) に java mode のフラグを持ち、いくつかの ARM register は stack pointer, java operand stack top 4, local variable に使われる。スタックマシンで、あまり多くのスタックを扱う命令がないことから、４つをレジスタに割り振ることで格段に早くなるといわれると、納得だ。

Sun HotSpot VM の Interpreter は operand stack のトップをレジスタに持たせるようになっているが、ここだけ見ると、その４倍だ。（もっとも、HotSpot VM はレジスタに持たせているデータがほかにたくさんあるのだが。）また、java code 実行中にネイティブの割り込みを受けられ、すぐにネイティブ OS で処理して、java code に復帰できる。

組み込みの世界でも Dynamic Compilation (ARM は Dynamic AdaptiveCompilation (DAC) と呼ぶ)はあるようだが、それはJazelle DBX のような高速な interpreter (相当の、素の bytecode 実行)がないとなかなか厳しい。それがなければ、compile がおきるまで、とても遅かったり、それを嫌って、すべて compile するとメモリが大量に必要になってしまう。

世の中の KVM, CVM, Aplix JBlend (for Jazelle), ARM JTEK 等のJ2ME 実装は Jazelle 機能を使って動いているらしい。

2005 年には Jazelle RCT (Runtime Compilation Target) がリリースされる。White Paper をよく読むと、これもなかなか興味深いものだ。Jazelle DBX は java only だが Jazelle RCT は他の managed runtime にも応用可能。16-bit 環境の Thumb を発展させた Thumb-2 に基づき Thumb-EE (Execution Environment?) を提供している。Thumb-EE では 16-bit, 32-bit の state を切り替える必要がなくなり、これらの命令が混在でき、さらに managed runtime の compiled code がよく使う操作を 16-bit 命令として提供しているので、コンパクトな compiled code の生成が可能になっている。従来の 32-bit 命令で作っていた compiled code は元のバイトコードの２〜８倍に達するのに、Thumb-EE では 10% 程度の増加ですむ。また、Null Pointer check, Array Index check の命令もあり、例外ケースではその co-processor の HandlerBase 相対で見つかるハンドラにオーバーヘッドなく、飛ばすこともできる。コードサイズがコンパクトなので、Dynamic Compilation でInlining も小さなコストで行える。HB{L} #handler 命令では設定しておいた最大 256 のハンドラに処理を移すこともでき、飛び先には複雑なidiv, fadd, lmul, athrow のような複雑なバイトコード処理をこの仕組みで呼び出すようにもできる。HotSpot interpreter も似たようなことをソフトウェアでやっていた気がする。Thum/Thum-2 の 16-bit 命令は基本的に R0-R7 を使い、R8 以降へのアクセスは Thumb-EE で追加された compiled code に便利な命令でアクセスできる。また R9 は current stack, R10 は constant pool といった dedicated use で java object 操作がシンプルに書きやすくなっている。

多くの携帯端末で使われているようでもあるが、DoCoMo のホームページでjazelle を引いても何もでてこないのはちょっと残念。KVM では少しでてくるけど。

Sumsung とか家電メーカーは Jazelle のライセンシーになって Blu-ray (BD-J)向けのチップとかも作っていくらしい。

CPU emulator の QEMU では Jazelle は実装されていないようで、残念である。

Jazelle DBX/RCT のような試みは PC, Server 向けのプロセッサでやっても面白そうだけど、見かけないな〜。（知らないだけ？）

Android の Dalvik VM は register base の VM で java bytecode に一手間加えた独自中間コードを使っているらしく、その時点で jazelle DBX の適用はありえない。Android G1 の CPU は Qualcomm の MSM7K で一応 ARM11 の jazelle機能は載っているようだが...

iPhone はというと ARM11 系 ARM1176JZF-S をベースにしたもので、こちらもjazelle はあるようなのだが...

ハードウェア機能があるのであれば、それを引き出す VM を誰か作ってもよさそうなものだが、そういうのはないんだろうか？

ただ、とある記事に「今後新たに登場するARM11アーキテクチャでは，Jazelle DBXは使われなくなるので問題はないだろう」といった一文があって引っかかる。なにか制約なり、限界が明らかになって、ARM が見放していくってことでないといいけれど...それとも、もっとよい代替手段があるのだろうか？