JMP on Kaffe

JMP は JVMPI を用いているが、最近の Kaffe も JVMPI を提供している。このエントリ http://gnu.wildebeest.org/diary/index.php?p=104 によると2005年7月中旬以降のバージョンで JMP が動くようになったらしい。
まず Kaffe をコンパイルする際に configure に --enable-jvmpi を指定する。また、Kaffe には GC が kaffe-gc と boehm-gc の2種類あるが、boehm-gc の方は JVMPI に対応していない。デフォルトでは kaffe-gc が選択されるので問題はない。さらに、Kaffe のスレッドシステムとして unix-jthreads と unix-pthreads の2種類があるが、JMP はユーザレベルスレッドである unix-jthreads では動かない。デフォルトでは unix-pthreads が選択されるので、これまた問題なし。

次に、Kaffe の jvmpi.h や jni_md.h は Sun JDK とは内容がバイナリコンパチでないようなので、Kaffe 専用に JMP をコンパイルしてインストールする必要がある。コンパイルの仕方は前と同じで、環境変数 JAVA_HOME に Kaffe をインストールしたディレクトリを指定する。ライブラリの名前を自動で変える方法が見つからなかったので、前の libjmp.so と同じディレクトリにはインストールできない。私は別のディレクトリにインストールしておいて、LD_LIBRARY_PATH を切り替えて使用することにした。

実行する際には、Sun や IBM JDK と全く同じように -Xrunjmp を指定すればよい。SPECjvm98 の _201_compress を走らせるとこんな感じ。

一応快適に走っているのだが、ヒープのダンプが取れないようなので不便な点はある。

compress は数メガバイトの大きな byte 配列の「割り当て→（解放）」を繰り返し、それ以外のメモリ割り当てがほとんど無いアプリケーションである。解放に（）が付いているのは Java だから明示的な解放は無いけど unreachable になる、という意味。Kaffe の場合を詳しく調べてみると、本来解放可能なはずの byte 配列がすぐに解放されずに GC を何回か生き残っている。これはおそらく conservative GC のせいだと思う。結局は解放されているのでメモリリークとまでは言えないが、Kaffe を真面目に使おうとすると甚だ不安な点である。

Sun JDK で compress を走らせると、byte 配列が解放可能になると次の GC でちゃんと解放されている。