| Oracle® JRockit JDKリリース・ノート リリースR28 B61445-04 |
|
 前 |
この章では、Oracle JRockit JDK R28に存在する既知の問題を示します。
オブジェクトが割り当てられると、JRockit JVM 1.6.0によって最終処理可能なオブジェクトが登録されます。
Java言語仕様(JLS)では、java.lang.Objectクラスの<init>メソッドの実行が正常に完了してから、オブジェクトが登録される必要があります。
SPARCプラットフォームで64-bit圧縮参照を使用すると、JRockit JVMがクラッシュすることがあります。
回避策
-XXcompressedRefs:size=4GBオプションを使用して、より低い圧縮参照サイズを指定します。問題が解消されない場合は、-XXcompressedRefs:enable=falseオプションを指定して、圧縮参照を無効にします。
あるいは、-Xmxオプションの値を3GB未満の値に変更することもできます。
-XXcompressedRefsおよび-Xmxオプションの詳細は、『Oracle JRockitコマンドライン・リファレンス』を参照してください。
Javaプログラムで使用されるアクティブ・モニターの数が多すぎる(4,194,304)場合(つまり、待機/通知または競合同期の実行対象となるオブジェクトが多すぎる場合)、JVMの内部モニター・インデックスがオーバーフローすることがあります。これは、大規模ヒープを使用しており、ガベージ・コレクションがほとんど実行されない場合によく起こります。これが起こると、アクティブなオブジェクト・モニターの数がオーバーフローした旨のエラーが発生し、JVMがクラッシュします。
Windowsプラットフォームでは、(すべてのUTF8文字列を出力する)jrcmdコマンドprint_utf8poolを使用してもUnicode文字を正常に処理できません。
Oracle JRockitでHPROFヒープ・ダンプの書込み中に複数のJava Out of Memory例外が検出されると、ヒープ・ダンプの内容が破損することがあります。
JRockit JVMと他のJVMの間でIIOPを介してjava.math.BigDecimalオブジェクトをシリアライズすると、IOExceptionがスローされます。この非互換性は修正されました。現在、JRockit JVM R28は他のJVMとの互換性はありますが、R27より古いリリースとの互換性はありません。したがって、JRockit JVMのR27リリースとR28リリースの間でIIOPを介してjava.math.BigDecimalオブジェクトをシリアライズすることはできません。
CPUソケット数が2個を超える最新のx86システム(Nehalem-EXなど)で、タイミングの安定性の問題が起こる場合があります。
Fast Timeを無効化(-XX:-UseFastTimeコマンドライン・オプションを使用)することで、問題が解決する場合があります。
R28.0では、JMAPIメソッドcom.bea.jvm.ProfilingSystem.newConstructorProfileEntry()が、UnapplicableMethodExceptionをスローするように変更されました。この例外が実際にスローされることはありませんが、この追加により古いコードのコンパイル・エラーが発生します。また、例外宣言を削除しても、コンパイルの問題が発生します。このため、この例外は将来のバージョンでも残ります。
WindowsでJRockit JVMを実行中に、次のメッセージが表示される場合があります。
[WARN ][osal ] could not enumerate processors (1) error=-1073738824 [WARN ][osal ] Failed to init system load counters
この問題は、Windowsのプロセッサ・パフォーマンス・カウンタ(PerfOS)が無効な場合に起こります。
このメッセージが表示された場合、CPUロード・イベントがJRockitフライト・レコーダに記録されず、JRockit Mission Controlコンソールに表示されません。
回避策: Microsoft Extensible Counter Listツール(exctrlst.exe)を使用して、WindowsのPerfOSカウンタを有効にします。このツールは、次の場所でダウンロードできます: http://download.microsoft.com/download/win2000platform/exctrlst/1.00.0.1/nt5/en-us/exctrlst_setup.exe
Oracle JRockitがOELまたはOVMで実行している場合、OELで修正が必要です。次にOVMのOELでJRockitを実行するための最低限の要件を示します。
OVM 2.1.2
OEL 4.7 ia32
パッチが必要です。OELの準仮想化カーネルのバージョンは、2.6.9-78.0.13.0.1.1.ELxenU以降である必要があります。
OEL 4.7 x64
GAビットは正常に動作します
OEL 5.3 ia32およびx64
GAビットは正常に動作します
Oracle JRockitは、ハードウェアと準仮想化バージョン、およびOEL 4とOEL 5をサポートします。
ナーサリが小さすぎると、昇格が行われないまま、Oracle JRockitが若いコレクションを次々とトリガーする場合があります。この現象は-Xverbose:memdbgの出力に、若いコレクションの連続発生とオブジェクト昇格数0として現れます。若いコレクションが非常に短い時間(0ミリ秒に近い数値)で実行されるのも、この状況を示しています。
回避策:
ナーサリ・サイズを増やします。ナーサリ・サイズを-Xgcprio:throughputで自動的に設定している場合は、手動で-Xnsを大きな値に設定して、オーバーライドできます。
Linuxカーネルのバグのため、特定のSSE2レジスタは、シグナル・ハンドラから返された後に正しくリストアされない場合があります。この問題は、Javaコードでの誤った浮動小数点値などの不明な動作といて現れます。
回避策:
この問題は、メインライン・カーネル・バージョン2.6.xxで修正されています。Unbreakable Linux Networkで、OEL 4およびOEL 5のパッチをRPMとして入手できます。通常のカーネル・アップグレード手順に従って修正を得ます。
古いカーネルの場合は、-XX:+UseMembarForTransitionsコマンドライン・オプションを使用します。
一部の最新のLinuxシステム(SLES 11など)で、ランダム化アドレス空間を使用すると、スタックの展開に関連するクラッシュが生じる場合があります。
回避策:
Linuxでは、カーネル構成コマンドsysctl -w kernel.randomize_va_space=0を使用すると、これらのクラッシュを排除できる場合があります。
Oracle JRockitでは、JVMコマンドライン・オプション-XX:+TrustPThreadStackInfoを使用すると、これらのクラッシュを排除できます。フラグはデフォルトではfalseです。
Solarisでラージ・ページを使用すると、長い休止時間が生じることがあります。これらの休止は、初めてページにアクセスする際に起こります。
回避策:
コマンドライン・オプション-XX:-UseLargePagesForHeapを使用して、ラージ・ページを無効にします。
Oracle JRockit JVM上で浮動小数点演算の集中するプログラムを実行すると、不正が生じる場合があります。これはLinuxカーネルのバグにより、タスクを切り替える際に一部のCPUレジスタが保存されないために起こります。OEL 4および5のパッチを入手できます。OEL 4の場合は、OEL 4.8と更新済のカーネル(2.6.9-89.0.18.0.1.EL以降)が必要です。OEL 5の場合は、更新済のカーネル(2.6.18-164.9.1.0.1.el5以降)が必要です。修正はOEL 5.5に含まれています。Novellでも修正を入手できます(BugZilla番号573478)。SLES 9 SP4、SLES 10 SP2およびSP3、およびSLES 11の修正が利用可能です。この問題はRedHatにも報告されています(BugZilla番号547893)。この修正の利用については、RedHatのサポートに問い合わせてください。
Oracle JRockitは、Windows Server 2008およびWindows Server 2008 R2での64を超える論理プロセッサをサポートしません。
Solaris/SPARCでは、classblockメモリーの予約のために、非常に多くのクラス(ほぼ100000)をロードするとOracle JRockitがメモリー不足になる場合があります。
回避策:
次のコマンドライン・オプションを使用します。
-XX:+UnlockDiagnosticVMOptions -XX:MaxClassBlockMemory=xxM
-XX:MaxClassBlockMemoryのデフォルト値は50MBで、妥当な値は約75MBです。
