|
|
|
シグナル処理の競合によって BEA JRockit がクラッシュする
BEA JRockit を OS シグナルに依存するネイティブ ライブラリと一緒に使用すると、BEA JRockit とネイティブ ライブラリの間でシグナル処理の競合が発生し、クラッシュすることがあります。
環境変数 LD_PRELOAD を次のように設定します。
export LD_PRELOAD=$JROCKIT_HOME/jre/lib/i386/libjsig.so
この競合は、BEA Engineering で IBM の MQSeries ネイティブ ドライバを使用していて確認されました。ネイティブ コードに依存するほかのライブラリでも発生する可能性があります。
|
|
Linux IA32 のためにビルドした実行中の JRockit JVM に Memory Leak Detector を接続する場合、JVM の処理を一度に約 1020 ファイル ディスクリプターのために使用すると、JVM がクラッシュする可能性があります。このことは、ディスクリプターの制限は、1024 以上に ( ulimit コマンドを使用して) 設定されている場合のみ発生します。
現在の時点で、少ないファイルディスクリプターが使用中の場合、JVM を起動時に、Memory Leak Detector を起動することができます。このために、JVM コマンド ラインで -Djrockit.memleak.port=12345 を追加しておきます。
JRockit Mission Control を使用して、JRockit ブラウザで、カスタム JMX サービス URL service:jmx:mlp:// localhost : 12345 とカスタム接続を作成します。(必要に応じて、 localhost および port 12345 を置き換えます。) この接続を使用して、JRockit Mission Control 内の Memory Leak Detector をこの JVM に一回接続することができます。(JVM を再起動せずに)
多くのファイル記述子を使用すると、Java アプリケーションのリソース リークが発生する可能性があることを示します。常に、開いたファイルとソケットを閉じ必要があります。ファイル 記述子など、非 Java リソースを解放するためにガベージ コレクションおよびオブジェクト ファイナライズに依存する必要はありません。詳細については、「 Too Many Open Files」を参照します。以下を参照します。
|
|
Red Flag Linux の一部である Asianux に対する新しい明示的なフォント サポートが用意されています。これは、BEA JRockit R26.3.0 が Asianux 互換の Linux ディストリビューションを正しく識別するために、ファイル /etc/asianux-release の存在と内容に依存しているためです。このファイルが存在しない場合、JRockit JDK または JRE は、 /etc/redhat-release の検索に戻り、代わりに、Red Hat 互換のフォント サポートを含む Red Hat Linux 互換ディストリビューションを識別します。
JRockit 1.4.2 では、Asianux に対するフォント サポートは、Red Hat Linux のフォント サポートと、Chinese LANG=zh_CN.GB2312 ロケールに対応した Red Flag Advanced Server 4.1 (以降) 用の追加パッチに基づいています。そのため、Red Flag Advanced Server 4.1 (以降) において JRockit 1.4.2 R26.3.0 以降で Chinese zh_CN ロケールを使用するときに、Red Flag Advanced Server 4.1 (以降) にファイル /etc/asianux-release が含まれていない場合、BEA JRockit は想定された Asianux 固有の font.properties.zh_CN.Asianux ファイルの代わりに、Red Hat 固有の font.properties.zh_CN.Redhat ファイルをロードします。そのため、JVM が誤ったパスのフォントをロードしようとしたときに失敗し、予期せぬ動作をする可能性があります。
Red Flag Advanced Server 4.1 および Red Flag Advanced Server 4.1 (SP1) では、ファイル /etc/asianux-release はデフォルトではインストールされない可能性があります。その場合は、以下のいずれかの回避策を適用できます。
- オプションの RPM パッケージ asianux-release がある場合は、インストールする。この解決策の方が適しています。Red Flag Advanced Server 4.1 (SP1) では、オプション パッケージ asianux-release がインストール済みのオプション パッケージ redflag-release と衝突する可能性がありますが、asianux-release パッケージをインストールする前に redflag-release パッケージをアンインストールしても、redflag-release パッケージと並行して asianux-release パッケージを強制インストールしてもかまいません。
- 手動で <jdk>/jre/lib/font.properties.zh_CN.Redhat の内容を <jdk>/jre/lib/font.properties.zh_CN.Asianux の内容で置き換える。
|
|
配列をコピーしているときにガベージ コレクションのためにスレッドが中断されると、ガベージ コレクションで長時間の休止が起きる場合があります。休止時間がときどき長くなる場合は、この問題の可能性があります。この問題は BEA JRockit R27.2 で修正されています。
|
|
Linux/IA64 でデフォルトの X11 AWT の代わりに Motif AWT を使用するよう明示的に要求し、 glibc-2.3.4 より古いバージョンの GLIBC と一緒に Linux を実行した場合、ファイル <jre>/lib/ia64/motif21/libmawt.so が GLIBC >= 2.3.4 へのリンケージを要求するため、この操作は UnsatisfiedLinkError により失敗する可能性があります。
サポート対象の Linux のバージョンについては、「 サポート対象のコンフィグレーション」ドキュメントを参照してください。
|
|
RedFlag 5.0 で wait() に関する確認済みのバグがあり、この OS バージョンを使用する RedFlag ユーザにとって不明な動作が起きる可能性があります。
|
|
BEA JRockit 26.4 では、シングル スペース ガベージ コレクタによるガベージ コレクションの後で、JRA の記録が常にヒープ使用率を 0 と報告します。 -Xverbose :memory および -Xverbose:memdbg を使用すると、ガベージ コレクション後の正確なヒープ使用率が出力されます。
|
|
同じマシンで他の JVM ベンダによる Java プロセスが実行されている場合、jrcmd ツールがマシン上のすべての BEA JRockit プロセスを発見できない可能性があります。この問題を解決するパッチについては、BEA JRockit サポートまでお問い合わせください。
|
|
Thread.sleep(...) および Object.wait(...) で開始された長期のスレッド スリープはスリープ時間が 0x3FFFFFFF ミリ秒 (約 12.4 日) より長い場合、途中で終了することがあります。
|
|
BEA WebLogic Platform 8.1 SP5 を 8.1 SP6 にアップグレードし、BEA JRockit R26 SP3 で実行すると、パフォーマンスが最大 10% 退行する可能性があります。
この退行を回避するには、コマンドライン オプション -XXtlaSize:
<default 2kB> および -XXlargeObjectLimit:
<default 2kB> を設定してメモリ負荷の高いアプリケーションのパフォーマンスを改善します。
|
|
BEA JRockit メモリ リーク ツールのタイプ グラフでタイプを展開すると、BEA JRockit がハングして応答しなくなり、その間も CPU リソースが消費されることがあります。この問題は BEA JRockit R26.2 で生じた退行の 1 つでした。
注意 : |
この問題は R26.4 で修正されました。 |
|
|
リフレクション (たとえば、 java.lang.Class.newInstance() ) により割り当てられたオブジェクトが Memory Leak Detector ツールの割り当てスタック トレースに表示されません。
|
|
競合がない状況、すなわち java.util.Random オブジェクトが 1 つのスレッドでしか使われていない状況を想定して java.util.Random.next() の同期コードは最適化されました。この最適化の欠点は、オブジェクトが複数の同時スレッドで濃密に使われていると、逆にパフォーマンスが低下することです。ユーティリティ メソッド java.lang.Math.random() を使用しているとき、これがよく起こります。
これを回避するには、 java.lang.Math.random() を呼び出す代わりに、新しい java.util.Random オブジェクトを生成します。
|
|
Null ポインタ例外が最初の catch ブロックをバイパスして次のブロックでキャッチされます。
“ return x.y; ” (変数 x は Null を指す) の直後の catch ブロックは Null ポインタ例外をキャッチしません。この例外は、その次の catch ブロックでキャッチされます。
|
|
-Xgc
:gencon を使用すると、まれに BEA JRockit R26.3.0 がクラッシュすることがあります。すべてのプラットフォームが影響を受けます。
別のガベージ コレクタを使用するか、BEA JRockit R26.4.0 にアップグレードします。
|
|
Linux の一部のバージョンでは、ライブラリ関数 exit() と _exit() が必ずしも呼び出し元プロセスを終了しません。これが原因で SLES 8 での停止処理中に BEA JRockit がハングします。
|
|
java.lang.String.getBytes(String charsetName) に Null 引数が渡されると、BEA JRockit 1.4.2 R26.2 と R26.3 は java.lang.NullPointerException を送出しますが、BEA JRockit 1.4.2 R24 は送出しませんでした。この動作は仕様ではありませんが、BEA JRockit 1.4.2 R26.2 または R26.3 で XML メッセージングと共に TIBCO を実行しているとき、この変更により問題が起こる可能性があります。
注意 : |
この問題は R26.4 で修正されました。 |
|
|
JVMTI Java デバッガを使用しているとき、ときどきブレークポイントがヒットしないことがあります。この問題は、すべての R26 バージョンで起こる可能性があります。
BEA JRockit の起動時にオプション -XXnoCodeGC を指定します。
注意 : |
-XXnoCodeGC はもっぱらトラブルシューティングで使うことを想定しており、本番で使うことは推奨されておらず、サポートもされていません。 |
|
|
ByteBuffer.allocateDirect() で割り当てたバッファが、アプリケーションから破棄しても解放されず、C ヒープ メモリのリークを引き起こします。
注意 : |
この問題は R26.4 で修正されました。 |
|
|
メソッドの最適化中に BEA JRockit がクラッシュします。この問題は次のスタック トレースにより確認できます。
at renameVar+36()@... at irCompactVars+240()@... at ssaConvertTo+2356()@... ...
このクラッシュは Sparc 上の Solaris プラットフォームでのみ確認されていますが、他のプラットフォームでも問題になる可能性があります。
optfile を使用し、クラッシュの原因となるメソッドを取り除きます。
|
|
NPTL の代わりに LinuxThreads を実行する以前の Linux ディストリビューションで、停止時に BEA JRockit がハングすることがあります。
|
|
アタッチされていないスレッドから JVMTI の関数を呼び出すと BEA JRockit がクラッシュします。
注意 : |
この問題は R26.4 で修正されました。 |
|
|
R26.3.0 より前の BEA JRockit リリースにはオーストラリア夏時間調整 (2006 年) 用の修正が含まれていません。 パッチについては、 BEA サポートまでお問い合わせください。
|
|
java.nio.channels.SelectionKey.OP_CONNECT を使用すると BEA JRockit が永久にブロックされます。
注意 : |
この問題は BEA JRockit R26.4 で修正されました。 |
|
|
Linux IA32 上の BEA JRockit R26.0.0 では、オブジェクトを割り当てるためのメモリ設定の段階で問題が発生する場合があります。これは次の出力で示され、その後、BEA JRockit が終了します。
[JRockit] ERROR: Fatal error in JRockit during memory setup phase. Try to reduce the heap size using -Xmx:<size>m, i.e. “-Xmx:16m”. Could not create the Java virtual machine.
-Xmx の値をいろいろ変えて、正しくセットアップされるヒープ サイズを探します。
注意 : |
これが問題とされるのは R26.0.0 です。リリース R26.1.0 以降では、この問題は修正されています。 |
|
|
IA64 RedFlag 4.1 はプログラムがクラッシュすると、壊れたコア ファイルを生成します。これは RF41/IA64 で BEA JRockit の技術者が顧客の問題を解決できないことを意味します。
|
|
java.net.PlainSocketImpl.initProto() (通常、最初の Socket または ServerSocket を生成するとき呼び出される) におけるハングが原因で起動に時間がかかります。
BEA JRockit 5.0 R26 では、IPv4 よりも IPv6 を優先的に使うようにネットワーク スタックが設定されます。
ネットワーク スタックを初期化する際、ネットワーク コードはソケットを固有のループバック インタフェースに接続してデータ構造をセットアップします。この接続が (ファイアウォールなど) でブロックされると、初期化コードはソケットのタイムアウトを待ち、その後、システムは IPv4 を使うように機能後退します。
-Djava.net.preferIPv4Stack=true (代わりに IPv4 を強制的に使わせる) を設定するか、IPv6 を完全に無効にします。適切な修正は、ローカルホスト間で IPv6 トラフィックを許可するというものです。
|
|
JRockit 1.4.2 R26 で、 java.lang.reflect.Array.set(Object array, int index, Object value) は、value が Null のとき array が基本型かチェックせずに常に NullPointerException を送出します。
この問題に対するパッチは、BEA サポートから入手できます。
|
|
XML ファイルで USER_INSTALL_DIR にデフォルトのインストール パス以外のパスが設定されていると、サイレント モードの BEA JRockit が正しくインストールされません。
インストール時にレジストリが正しく設定されず、 .jar ファイルの関連付けが失敗します。 Java.exe と Javaw.exe の 2 ファイルがどちらも %SystemRoot%¥System32 にコピーされません。
注意 : |
この問題は R26.3 で修正されました。 |
|
|
x64 の Linux オペレーティング システムのバグが原因で、BEA JRockit は pthread_once システム コールから起動されるとクラッシュします。
RHEL 4.0 QU3 または SUSE 9.0 SP3 をインストールします。
|
|
HP OpenView Java 診断プロファイリング エージェントを実行すると BEA JRockit R26.0.0 がクラッシュすることがあります。
注意 : |
この問題は R26.3.0 で修正されました。 |
|
|
まれに、 Ctrl-Break ハンドラまたは Management Console/MAPI によるスタック ダンプでロックに関する正しい情報が出力されないことがあります。
ある方法 (inlining) で最適化されたメソッドがロックを取得したとき、このロックは当該フレームだけでなく隣接フレームでも取得済みと表示されることがあります。スタック ダンプ自体を実行するとき、これは BEA JRockit によるロックの扱いに影響しません。
|
|
Windows x64 および Itanium 上では、BEA JRockit JRE コンソール モード インストーラを使用してすでにインストールされている BEA JRockit を削除しようとした場合に、アンインストール処理が中断し、次のメッセージが表示されます。
A fatal error has occurred. This application will terminate.
アンインストール情報は削除されますが、ほとんどのファイルおよびレジストリ設定はマシン上に残されます。
BEA JRockit JRE を完全にアンインストールする方法 :
グラフィカル モードでインストーラを実行し、応答が求められたら [ Remove previous and reinstall] をクリックします。JRockit JRE が再びインストールされます。(ファイルおよびレジストリ設定を含めて) JRockit JRE を完全にアンインストールするために、グラフィカル アンインストール手順を使用します。
|
|
一部のフォント ファイルにおける TrueType フォントの処理に関する問題が原因で、 java.awt.Font.getXXX() メソッドが呼び出され、その結果、 IllegalArgumentException が送出されることがあります。
この問題は、Sun JDK 5.0 Update 4 で見つかった問題として、バグ #6349101 ( http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6349101) で Sun にすでに報告されています。この問題は理論的にはすべてのプラットフォームで発生する可能性があります。この問題は、RedFlag Linux Advanced Server 5.0 上に RPM パッケージ ttfonts-zh_TW-5.0-2AX.noarch.rpm がインストールされていて、ユーザが中国語ロケールのフォントを要求したときに発生することが確認されています。
パッケージ ttfonts-zh_TW-5.0-2AX をアンインストールしてください。この操作を行うことで問題を解決できますが、これらのフォントがシステムから削除されるので、中国語のテキストを表示しようとしたときに別の問題が発生する可能性があります。この操作を行う場合は、削除されるフォントが使用されている部分をシステムで使用可能な別のフォントに置き換える必要があります。
注意 : |
この問題はリリース R26.3.0 で修正されましたが、このリリースには Itanium バージョンが含まれていないので、R26.0.0 Itanium バージョンでは現在も既知の問題となっています。 |
|
|
Linux 上で仮想メモリの使用量を制限するために ulimit -v を使用する際に、制限値をあまりに低く設定すると、BEA JRockit がクラッシュする可能性があります。BEA JRockit の x86_64 バージョンでは、起動時にコンパイル済みのコードのアドレスが予約されるので、設定値を大きくする必要があります。BEA では、 ulimit -v 設定を使用しないことをお勧めします。
|
|
BEA JRockit は十分な仮想メモリ (アドレス空間) がないと適切に実行できません。使用可能な仮想メモリを増やしてもメモリ消費は増えません。Linux では、使用可能な仮想メモリ量を通常 ulimit -v <amount> コマンドで変更することができます。
アドレス空間を制限しない設定がデフォルトで、これが推奨されています。このデフォルトを変更すると BEA JRockit のアドレス空間が足りなくなるおそれがあり、その場合、BEA JRockit は直ちに終了します。
BEA JRockit の起動に最低限必要な仮想メモリ量は次のとおりです。
IA64 の場合 : 88 MB
IA32 の場合 : 61 MB
x64 の場合 : 1100 MB
注意 : |
BEA JRockit の起動時の仮想メモリ量が上記の値の 2 倍より少ない場合、警告が表示されます。これは推奨されておらず、実際の Java アプリケーションを実行したとき問題が生じる可能性があります。 |
|
|
一部のアプリケーションでは、 -Xgcprio
:throughput (デフォルト) および -Xgcprio:pausetime モードで実行したときに、ナーサリ サイズ自動設定ヒューリスティックに問題が発生する可能性があります。その結果、ガベージ コレクションが頻繁にトリガされます。
-Xns
:<size> を使用して手動でナーサリ サイズを設定するか、または静的ガベージ コレクタを選択します。
ヒープ サイズ自動設定ヒューリスティックがすべてのアプリケーションに最適というわけではありません。ガベージ コレクションが頻繁に行われることを原因とする問題がアプリケーションにあり、ヒープが最大ヒープ サイズまで拡張されていない場合は、初期ヒープ サイズ ( -Xms :<size>) を増やすことで、パフォーマンスを向上させることができます。
|
|
BEA JRockit を Windows 上の埋め込みサービスとして実行する場合 (たとえば、Jakarta Tomcat サービス ラッパー) は、 <path-to-jdk>/jre/bin ディレクトリを PATH 変数に追加する必要があります。
|
|
Windows x64 に 32 ビット JRE をインストールした場合、 java.exe ファイルと javaw.exe ファイルは system32 フォルダではなく syswow64 フォルダにコピーされます。
これは、Windows x64 上で実行される 32 ビット アプリケーションで期待される動作です。
|
|
Windows ia32 BEA JRockit パッケージに同梱の "jrcmd" ユーティリティは Windows x64 では正常に機能しません。代わりに、"jrcmd" ユーティリティ (BEA JRockit の Windows x64 パッケージに同梱) を使用してください。
|
|
スレッドの優先順位は Windows プラットフォーム上でのみサポートされます。
|
|
Windows XP x64 で JRA 記録を実行すると、Windows 2003 Server で実行された JRA 記録が正しく表示されません。BEA JRockit の現在の実装では、この 2 つのオペレーティング システムのバージョン情報を区別することができません。
注意 : |
これは R26.0 と R26.1 で問題になります。 |
|
|
RHEL4 などの「gamin」ファイル変更モニタ実装を使用する Linux ディストリビューションでは、Java アプリケーション (たとえば Eclipse) がハングすることがあります。これは、gamin のシグナル処理にバグがあるためです。
libjsig.so ライブラリをロードして、「シグナル チェーン」を使用します。そのためには、BEA JRockit を起動する前に、 > export LD_PRELOAD=$JDK_HOME/jre/lib/i386/libjsig.so を実行します。
|
|
ガベージ コレクション方式が変更されたときに BEA JRockit のナーサリ プールを無効にできます。Java 2 Platform SE API ドキュメントによると、無効化されたプールは null を返すことがあります。したがって、プログラマは、 MemoryPoolMXBean#getUsage() および MemoryPoolMXBean#getPeakUsage() からいつでも null が返される可能性があることを想定する必要があります。
MemoryMonitor デモと VerboseGC デモでは null のチェックが行われていないので、 NullPointerExceptions が送出される可能性があります。
|
|
ナーサリを持つ BEA JRockit で VerboseGC デモ ( ¥demo¥management¥VerboseGC¥VerboseGC.jar ) を実行すると、 NullPointerExcecption が送出される場合があります。
Java 2 Platform Standard Edition 5.0 の API 仕様によると、 MemoryPoolMxBean の getUsage() メソッドは、メモリ プールが有効でない場合 (たとえばナーサリを使って BEA JRockit を実行したとき) に null を返すことがあります。
この有効性チェックはデモに含まれておらず、 NullPointerException の原因となります。
|
|
Windows では、問題のあるコードを構造化例外処理 (SEH) で捕捉できます。Microsoft C コンパイラでは、次のような特殊な構造が許可されます。
__try { // 失敗する可能性がある何らかの処理を行う } __except (filterException()) { // エラーを処理する }
これは SEH ハンドラで、 __try ブロック内のコードが失敗した場合 (たとえば不正なアドレスへの読み取り/書き込みが行われた場合) に呼び出されます。
ただし、64 ビット Windows (IA64 および x64) では、JRockit は、ベクトル化例外ハンドラ (vectored exception handler) と呼ばれる新しい例外処理機能を使用します。ベクトル化例外ハンドラは、SEH ハンドラが呼び出される前に呼び出されます。JRockit ベクトル化例外ハンドラによってネイティブ コード内にエラーが検出された場合、BEA JRockit はクラッシュ ダンプを生成します。
この影響として、BEA JRockit から呼び出されるネイティブ コードで 64 ビット Windows の SEH を使用することはできません。ベクトル化例外ハンドラを自分でインストールしてチェーンの先頭に追加するか、または IsBadReadPtr() を使用してハンドラへの読み取り/書き込みを行う前にメモリをテストしてください。
|
|
RHEL3u6 以前と RHEL4u2 以前で fork() による新プロセスの生成が失敗することがあります。その結果、 Runtime.exec() がエラーとなる可能性があります。この問題は RHEL3u7 と RHEL4u3 で修正されました。
この問題の Red Hat Issue Tracker ケース番号は 77560 です。Redhat の public bugzilla で、これは入手できません。
|
|
SLES 8.0、RFAS 4.1、RHEL 3.0 QU4 以前を実行している場合、深刻な IO 問題が発生する可能性があります。
|
|
このリリースには、Windows 向けの IPv6 のサポートが、サポートされない機能として含まれています。
|