アプリケーションの開発

トラブルシューティング

他の JVM から BEA JRockit 1.4.2 JVM に切り替える手順は比較的簡単で通常は問題ありませんが、切り替え中または切り替え後にいくつかの既知の問題が発生する可能性があります。この節では、それらの問題について説明し、簡単な回避策を示します。発生する可能性のある問題は以下のとおりです。

アプリケーションが動作しない

Java アプリケーションが BEA JRockit JVM 上で動作しません。どこに問題があるのでしょうか。

BEA JRockit JVM 上でのアプリケーションの実行に関する問題の多くは、誤った環境変数または非標準の起動オプションが原因です。

まず、環境変数が正しく設定されていることを確認してください。JAVA_HOME 環境変数が、BEA JRockit JVM をインストールしたディレクトリなどに正しく設定されていることと、PATH 環境変数で、java.exe の各バージョンが格納されているすべてのディレクトリの "%JAVA_HOME%¥bin" が設定されていることを確認してください。アプリケーションを Windows サービスとして実行する場合は、これらの環境変数をシステム全体で設定していることが重要です。次の手順に従います。

[スタート] メニューを開いて、[設定｜コントロールパネル｜システム] を選択します。

[詳細] タブを選択します。

[環境変数] をクリックします。

システム全体の環境変数を設定するには、このダイアログボックスの下部の [システム環境変数] で編集する必要があります。

アプリケーションをスクリプトから起動することがよくあります。起動スクリプトに java に対する非標準の起動オプションが含まれていないことを確認してください。標準および非標準オプションの詳細については、『BEA JRockit JVM チューニングガイド』を参照してください。

アプリケーションの起動が遅い

BEA JRockit JVM ではアプリケーションの起動により時間がかかるのはなぜですか。

Java プログラムは Java コンパイラによってバイトコードにコンパイルされます。Sun JVM などの多くの JVM は、このバイトコードを実行するたびに解釈します。一方、BEA JRockit JVM ではコード生成技術を使用して、バイトコードからネイティブマシンコードを生成します。これは Just-In-Time (JIT) コンパイルとも呼ばれます。このコード生成手順では、実行の前の初期時間が長くなります。通常、それ以降のコードの実行速度は、バイトコードを解釈する場合よりも速くなります。BEA JRockit JVM は、一般に長時間にわたって動作するサーバアプリケーションに向けて最適化されています。時間の経過と共にコード生成のパフォーマンス上の利点を比較すると、初期時間がかかるというデメリットは取るに足りないものになります。

プロセスカウンタが初期化されない

BEA JRockit の実行時に、コンソールから JRockit に接続しようとした場合や、プログラムが CPU ロードカウンタにアクセスしようとした場合に、NotAvailableException が発生することがあります。

プロセスカウンタが初期化されないことが時々あります。これは、Windows のセキュリティ設定において、Performance Data Helper (PDH。オペレーティングシステムからパフォーマンスの指標を取得する Windows API) プロセスカウンタを読み取れない場合、または何らかの理由により PDH プロセスカウンタが無効になっている場合にのみ発生します。この状態では、プロセスカウンタを参照することができず、エラーが送出されます。次のメッセージが表示されます。

[JRockit] WARNING:  Could not initialize the virtualbytes counter, some
functionality in jrockit.management.Memory will not be available.Message
was: failed to  create counter query.String was: (null)¥Virtual Bytes

[JRockit] WARNING:  Could not initialize the JVM process load counter, CPU
load generated by the JVM will not be available.Message was: failed to create
counter query.String was: (null)¥% Processor Time

プロセスカウンタがオフになる理由は不明ですが、このような状況に遭遇した場合は、以下のサイトの指示に従ってプロセスカウンタをオンに戻してください。

http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/
exctrlst-o.asp

それでも問題を解決できない場合は、セキュリティ設定をチェックして、JVM プロセスを実行しているのと同じユーザとして Windows の perfmon ツールを使用し、そのパフォーマンスカウンタを読み取ることができるかどうかを確認してください。

メモリの消費量が多い

BEA JRockit JVM 上で実行するとアプリケーションがメモリをより多く消費するのはなぜですか。

Java プログラミング言語では、ガベージコレクション (GC) というメカニズムに依存して、使用されなくなったメモリを解放します。C++ プログラミング言語の delete 演算子や C プログラミング言語の free 関数に相当するものはありません。Java 仮想マシンにはガベージコレクタが含まれている必要があります。ガベージコレクタは、参照されていないオブジェクトを見つける作業を行い、場合によってはそのファイナライザを呼び出して、オブジェクトの状態を保持するために使用されているメモリを解放します。

BEA JRockit JVM のガベージコレクタについては、『JRockit SDK ユーザーズガイド』の「BEA JRockit メモリ管理システムの使い方」で説明されています。一般に、BEA JRockit JVM のガベージコレクションの実装では、メモリ使用率が高くなるのと引き換えに、速度や、プログラム全体の中断 (システム全体のロックが要求される) を最小限に抑えることを実現しています。

HotSpot と比べてパフォーマンスが低い

BEA JRockit JVM を使用する、特定のタスクのスクリプトまたはプログラムがあります。Sun JVM の HotSpot を使用する場合よりも速度が遅くなるのはなぜですか。

これは前述の「アプリケーションの起動が遅い」に関連している可能性があります。スクリプトまたはその他のプログラムで多数の Java プロセスを起動することがあります。その場合、BEA JRockit JVM では起動時にコード生成によるデメリットがあるため、Sun JVM に比べてパフォーマンスが低下することがあります。多数の Java プロセスを起動して短時間だけ実行する場合は、このデメリットが大きくなる可能性があります。

ランダムに現れるバグ

アプリケーションを BEA JRockit JVM 上で実行すると、Sun JVM 上で実行する場合には起きないバグがランダムに発生するのはなぜですか。

アプリケーションで同期化のバグが発生している可能性があります。JVM を切り替えるときにそのようなバグが現れるのは珍しいことではありません。JVM 仕様と Java 言語仕様では、最適化の余地が多く残されており、最適化によって、共有データへの同期化されないアクセスや、異なる JVM 上での異なる動作が引き起こされることがあります。

詳細については、以下を参照してください。

http://java.sun.com/docs/books/jls/second_edition/html/memory.doc.html

http://java.sun.com/docs/books/vmspec/2nd-edition/html/Threads.doc.html

HotSpot では送出されないエラーを BEA JRockit JVM が送出する

Sun JVM は送出しないのに、BEA JRockit JVM は IllegalAccessError、ClassFormatError、IncompatibleClassChangeError、または他の LinkageError 例外を送出するのはなぜですか。

検証では、クラスまたはインタフェースのバイナリ表現が構造的に正しいことを確認します。たとえば、すべての命令に有効なオペレーションコードがあること、各分岐命令が、他の命令の途中ではなく、命令の開始点に分岐していること、どのメソッドにも構造的に正しいシグネチャがあること、すべての命令が Java プログラミング言語の型の規定に従っていることなどをチェックします。

検証中にエラーが発生すると、クラスの検証を引き起こしたプログラム内のポイントで、LinkageError クラスの以下のようなサブクラスのインスタンスが送出されます。

例 : JTidy を使用すると IllegalAccessError が送出される

Apache Software Foundation の JTidy の初期のバージョンでは、コンパイラは外部のクラスに属しているプライベート変数への参照を誤ってインライン処理していました。BEA JRockit JVM は Sun JVM よりも厳密な検証を行うため、例外が送出されました。古い Tidy.jar は、正しくコンパイルされる新しいバージョンで置き換える必要があります。

開発モードでパフォーマンスが低下する

WebLogic Server を開発モードで実行する場合、BEA JRockit JVM の速度が遅くなるのはなぜですか。

WebLogic Server を開発モードで起動する場合、BEA JRockit JVM はデフォルトで -Xdebug オプションで起動されます。このため BEA JRockit JVM の実行に若干のオーバーヘッドが伴います。

注意 : このオプションは診断を目的として用意されたものなので、プロダクション環境では使用しないでください。

BEA JRockit JVM が Jakarta Tomcat を Windows サービスとして実行しない

BEA JRockit JVM で、Jakarta Tomcat を Windows サービスとして実行できません。どこに問題があるのでしょうか。

この問題に簡単に答えると次のようになります。jk_nt_service を使用している場合、Sun JVM の場合に必要な手順をすべて行います。次に、wrapper.properties ファイルで、Sun JVM の非標準の -Xrs 起動オプションを、BEA JRockit JVM の非標準の -Xnohup オプションに変更します。以下の回答では、これについてもう少し詳しく説明します。

最初に、前述の「Java アプリケーションが BEA JRockit JVM 上で動作しません。どこに問題があるのでしょうか」の環境変数に関するタスクをすべて完了していることを確認してください。

ほとんどのユーザは、jk_nt_service Windows サービスラッパーを使用して、Jakarta Tomcat などの Java アプリケーションを Windows サービスとして実行します (http://members.ozemail.com.au/~lampante/howto/tomcat/iisnt/ を参照)。Windows サービスとして何を使用するかに関係なく、非標準の起動オプションを使用していないことを確認する必要があります。jk_nt_service を使用する場合、起動は次のように定義されます。
<tomcat install dir>¥conf¥jk¥wrapper.properties

3 つのプロパティ wrapper.tomcat_home、wrapper.java_home および wrapper.cmd_line が正しく設定されていることを確認します。

wrapper.tomcat_home には Tomcat のインストールディレクトリを設定する必要があります。
wrapper.java_home は JAVA_HOME 環境変数と同じ値に設定されていなければなりません。
プロパティ wrapper.cmd_line は起動コマンドを定義します。このドキュメントの執筆時点において、BEA JRockit JVM の場合は、このプロパティを次のように設定します。

wrapper.cmd_line=$(wrapper.javabin) -Xnohup -Djava.security.policy=="$(wrapper.tomcat_policy)" -Dtomcat.home="$(wrapper.tomcat_home)" -classpath $(wrapper.class_path) $(wrapper.startup_

通常、このコマンドには、ユーザがログオフするときに JVM が停止しないようにするための非標準の起動オプションを指定します。この非標準のオプションは、BEA JRockit JVM の場合は -Xnohup、Sun JVM の場合は -Xrs です。

その他のよくある質問

Java 仮想マシンとは何ですか。

Java 仮想マシン仕様では次のように説明されています。

「Java 仮想マシンは Java および Java 2 プラットフォームの土台となるものです。ハードウェアやオペレーティングシステムからの独立性、小さいサイズのコンパイル済みコード、悪意あるプログラムからのユーザの保護などを実現する技術のコンポーネントです。」

Sun JVM と BEA JRockit JVM の違いは何ですか。

最もよく知られた JVM は Sun の実装です。Sun JVM は HotSpot と呼ばれます。Sun JVM は、Sun の Java Development Kit (JDK) および Java Runtime Environment (JRE) に付属しています。

BEA Systems の BEA JRockit JVM は、サーバサイドアプリケーションに向けて、信頼性とパフォーマンスのために最適化されています。これを実現するために、BEA JRockit JVM では、コード生成、ホットスポットの検出、コードの最適化、高度なガベージコレクションアルゴリズム、オペレーティングシステムとの緊密な統合などの技術を使用しています。

BEA JRockit JVM ではアプリケーションを異なる方法で記述する必要がありますか。

いいえ。他の JVM の場合と BEA JRockit JVM の場合とで、アプリケーションを異なる方法で記述する必要はありません。ただし、BEA JRockit JVM 上で適切に動作するように、アプリケーションを適切に設計および実装してください。