このスクリプトでは、e-docs マニュアルの検索に必要な Google 検索の URL を出力します。
このスクリプトでは、e-docs マニュアルに必要なバナーを出力します。
このスクリプトでは、e-docs マニュアルの検索に必要な Google 検索のパラメータを出力します。
リリース ノート
Oracle JRockit JVM R27.6.0 での変更点 」を参照してください。
このリリースの新機能および改善事項
Eclipse IDE との統合 」を参照するか、Mission Control を開いてヘルプ システムを起動してください。
http://dev2dev.bea.com/jrockit/tools.html で公開されます (利用できる場合)。
-Xverbose :refobj が追加されています。このモジュールは、info レベルでは、ガベージ コレクションごとに java.lang.ref.Reference オブジェクトに関する低オーバーヘッド情報を提供します。このモジュールは、debag レベルでは、以前の -Xverbose:referents モジュールの info レベルの出力に相当する情報を出力します。
-XpauseTarget 値を 1 ミリ秒から設定できるようになりました。ただし、実際の休止対象は、アプリケーションのサイズと動作やハードウェアによって異なります。
-XlargePagesexitOnFailure=false を使用してこの動作をオーバーライドし、JVM を強制的に終了できるようになっています。次のように指定します。
リリース ノート
BEA JRockit Mission Control
図 2-4 は、出荷時の状態のパフォーマンスがリリースを経てどのように向上したかを示しています。R27.1 から R27.2 にかけて最も大きく向上しているのは、Java SE 6 対応の JRockit が導入された時期と一致しているためです。R27.3 ではさらに改良されています。
図 2-5 を参照)。
http://java.sun.com/javase/6/docs/index.html
Attach API のサポート
http://edocs.bea.com/jrockit/geninfo/diagnos/aboutjrockit.html#wp1083571
System.nanoTime() メソッドは、各プラットフォームで使用できる最適な時間単位を常に使用するように改良されました。System.nanoTime() メソッドの詳細については、BEA JRockit 診断ガイド nanoTime() および currentTimeMillis() によるタイミング
-XXallocPrefetch および -XXallocRedoPrefetch オプションを指定して有効にしていましたが、デフォルトで有効になりました。これにより、パフォーマンスが最大 40% 向上する可能性があります。
注意 : Intel Xeon サーバでこの機能の効果を十分に上げるには、コンピュータの BIOS でハードウェア プリフェッチを無効にすることをお勧めします。
-Xgcprio:throughput) で、ナーサリ サイズ設定のヒューリスティックが改良されました。これは、アプリケーションのスループットの向上につながります。
-XXgcThreads オプションのデフォルトのコンフィグレーションが改良されました。その結果、待ち時間の影響を受けやすいアプリケーションに関する、出荷時の状態での動作が改善されます。ほとんどの場合、このオプションを手動でチューニングする必要はなくなります。
図 2-6 は、BEA JRockit R27.1 リリースと R27.2 リリースのベンチマークの比較を示しています。この場合、さまざまな起動オプションで JVM がチューニングされています。
図 2-7 は、新しく改良された出荷時の動作でのパフォーマンスの向上を示しています。出荷時の状態のパフォーマンスは約 70% 向上しています。
図 2-8 は、その効果を図で示したものです。
-Xverboseverbosity set=referents=info を使用します。
表 2-1 に示すコマンドライン オプションが更新されました。すべてのコマンドライン オプションの詳細な説明については、 リファレンス マニュアル を参照してください。
BEA JRockit Mission Control リリース ノート
-Xmanagement:ssl=false,authenticate=false,port=7091 を使用します。詳細については、『BEA JRockit コマンドライン リファレンス』の「-Xmanagement
http://java.sun.com/javase/6/docs/technotes/guides/attach/index.html
診断ガイド
図 2-9 を参照してください。
図 2-10 を参照してください。Oracle JRockit R26.4 と R27.1 を比較しています。
-XXtlaSize 図 2-11 を参照してください。Oracle JRockit R26.4 と R27.1 を比較しています。
リファレンス マニュアル にある個別の説明を参照してください (以下のリストで目的のオプション名をクリックします)。
リファレンス マニュアル にある個別の説明を参照してください (表 2-2 でオプション名をクリックします)。
表 2-3 に、Oracle JRockit JVM R27.6.3 で行われた変更点を示します。
64 ビット Windows Vista/2008 で、管理者実行レベルをリクエストするための実行可能な64 ビット JRockit インストーラが正常に表示されます。
この問題は CR363487 から追跡されています。
Oracle JRockit Mission Control 3.1.0 および Oracle JRockit Real Time 3.1.0 以降は、各製品インストール ディレクトリが Oracle ホームとしても機能し、Oracle セントラル インベントリに追加の製品を登録できます。セントラル インベントリには同一のホスト上にインストールされたすべての Oracle 製品に関する情報が格納され、Oracle Universal Installer を実行することで管理できます。
Linux の複合ウィンドウ マネージャで JRockit JDK インストールがアプリケーションを実行した場合、以下のエラー メッセージが生成されて失敗する可能性があります。
この問題は Oracle JRockit 5.0 R27.6.3 および Oracle JRockit 6 R27.6.3 で修正されています。
この問題は CR349882 から追跡されています。
Oracle JRockit Mission Control 3.1.0 および Oracle JRockit Real Time 3.1.0 以降は、デモ プログラムとサンプル プログラム、および Java プラットフォームのソース コードがデフォルトでインストールされなくなりました。 これらはオプション コンポーネントとして、別々に選択してインストール必要があります。
表 2-4 に、Oracle JRockit JVM R27.6.2 で行われた変更点を示します。
特定の XSLT/XSL 変換で ClassCastExceptions が発生する場合があります。この問題は修正されています。
表 2-5 に、Oracle JRockit JVM R27.6.1 で行われた変更点を示します。
JVM プロセスのメモリが不足している場合、ファイルの圧縮中に、記録の最後で JRA によって JVM がクラッシュすることがあります。この問題は解決され、JRA はエラー メッセージを出力します。
xmn レジスタを応用した 3D 表示は時折 JVM がクラッシュする原因となります。この問題は修正されています。
圧縮する範囲が縮小された場合、外部圧縮はヒープ部分を圧縮できません。この問題は修正されています。
64 ビット プラットフォームで
java/lang/StringBuffer.lastIndexOf() メソッドの最適化されたコードを実行した場合、Oracle JRockit バージョン R27.5 および R27.6 はクラッシュします。コンパイラはこのメソッドの壊れたコードを生成しません。
Oracle JRockit は時折、メソッドの最適化中にクラッシュして、これによりスタック トレースが
removePhi を指します。この問題は修正されています。
JarInputStream を使用して
rt.jar 配布から Manifest を読み込んだ場合、特定の
rt.jar 配布に
NULL を返します。この問題は修正されています。
Oracle JRockit は、固定されたオブジェクトのガベージ コレクション ヒープがナーサリ保持領域の近くに割り当てられたため、内部データ構造が破損し、クラッシュしていました。この問題は修正されています。
Oracle JRockit の最適化コンパイラは欠落のある x86 コードを生成します。これはメソッド呼び出しの浮動小数点応答値で動作する Java コードに誤った結果をもたらします。この問題は修正されています。
複雑な制御フロー (大量の JSP など) で大きなメソッドをコンパイルする場合、 Oracle JRockit の最適化コンパイラは大量のメモリを消費します。32 ビット プラットフォームでは、OutOfMemory エラーになります。この問題は修正されています。
JRockit Mission Control は名前の無いスレッドを含んだ LAT 記録を開けませんでした。この問題は修正されています。
表 2-6 に、Oracle JRockit JVM R27.6.0 で行われた変更点を示します。
完全に圧縮した場合、ヒープ内のすべてのリファレンスが圧縮したセットに格納されるようにします。圧縮したセットを限定した場合、ポインターが多過ぎて圧縮処理をスキップする必要となります。この問題は修正されています。
JRockit JVM の以前のリリースでは、共通スーパークラスを共有する複数のアンロード型のクラス階層をアンロードするまたは同じインタフェースをインプリメントすると、休止時間が長くなる可能性があります。この問題は R27.6 で修正された。
テクニカル ライセンス チェックが削除されました。
JRockit JVM を Sparc システム上の WebLogic Event Server で実行すると、
cgStoreMetaInfo がクラッシュし、スロットのスケジュールに遅れたという確認済みの問題を示します。スロットのスケジューリング遅延という問題は修正され、システムはクラッシュしなくなりました。
JRockit JVM の以前のバージョンでは、動的初期化用の呼び出しチェーンのデバッガ内に停止したスレッドは、クラスを初期化するメソッドのタイプを受信するための論理変数情報を読み込むときに、クラッシュする可能性があります。この問題は修正されています。
java.lang.management.CompilationMXBean.getTotalCompilationTime() を呼び出すと、0 を返していました。この問題は修正されています。
Linux IA32 のためにビルドした実行中の JRockit JVM に Memory Leak Detector を接続する場合、JVM の処理を一度に約 1020 ファイル ディスクリプターのために使用すると、JVM がクラッシュする可能性があります。この問題は修正されています。
JRockit JVM では、
Agent_OnAttachから返されるエラー コードが正常に処理されません。エラーが返された場合、JVM が中断されます。この問題は修正されています。
ACLs (Access Control Lists) on the per-user <
TEMP>\hsperfdata_<user> ディレクトリは、管理者権限のあるユーザがそのディレクトリを削除することができるように設定します。これは、JRockit JVM の Windows バージョンのみに影響します。詳細については、『
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5073453 』を参照してください。
同じインタフェースを実施する多くのクラス (~10,000) を同時にアンロードした場合、インタフェースからこれらを未登録するために長い時間が掛かります。この問題は修正されています。
アクティブなオブジェクト モニタの最大数を 4,194,304 まで増えました。
ナーサリ サイズは、約 0 になるまでに圧縮していました。若いコレクションは、古いコレクションを生成しなくても、スペースを再要求しないようにします。これにより、JRockit JVM は若いコレクションのみ生成して行きます。この問題は修正されています。
Rockit JVM の以前のバージョンから R27.4 にアップグレードした後、クラス ローダの動作が変更することがありました。
CLASSPATH に
$Inner クラスが存在しなかった場合、
NoClassDefFoundError がスローされました。この問題は修正されています。
一部のオペレティング システムのオペレティング システム バグは、
pthread_createの呼び出し時点で送信された場合、シグナルがなくなる可能性があります。これにより、JRockit JVM をハングする可能性があります。この問題は、
pthread_createを呼び出す時にこれらのシグナルをブロックすることにより修正されています。
JRockit JVM の以前のバージョンでは、システム クロックを再設定すると、期待したより長い時間スリープするように
Thread.sleep を呼び出す可能性があります。この問題は修正されています。
RHEL 5 および Asianux 3.0 に対応する CJK (中国語、日本語、韓国語) の新規
fontconfig.properties ファイルは、Oracle JRockit JDK 6 から Oracle JRockit JDK 5.0 に修正をバックポーティングすることによって修正されています。これは、
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=2149631で Sun が報告した問題の修正のバックポーティングです。
JRockit JVM の R27.1 から R27.5 までの以前のバージョンでは、SPARC上、スロットのスケジュールに遅れると、ガベージ コレクションのときにクラッシュされます。この問題は修正されています。
JRockit JVM は、
DetachCurrentThreadを呼び出せずに終了する JNI スレッドを処理する時により堅牢です。JVM は、これらのスレッドを検出し、無視するよになりました。JRockit JVM は、この問題を発生した時にデベロッパに問題を通知するよう警告メッセージを表示します。ただし、
DetachCurrentThread を呼び出さないと、JNI API が違反されます。JRockit JVM が堅牢になっていても、API がこのように違反されると、JVM の安定性を保証することはできません。
表 2-7 に、このバージョンの BEA JRockit JVM で行われた変更点を示します。
以前のバージョンの Oracle JRockit では、JRA 記録でのガベージ コレクションの [
GC 前のヒープ使用量 ] の値が不正確でした。これは、実際には進行中のコレクションの [
GC 後のヒープ使用量 ] が表示されていたためです。この問題は修正されています。
Oracle JRockit では、2 つ以上の異なる文字列オブジェクトの連結を含むメソッドの最適化中にクラッシュが発生することが時折ありました。この問題は修正されています。
関数
_irTypesIsExactClass のバグにより、コードの最適化でクラッシュが発生していました。この問題は修正されています。
Oracle JRockit では、
java.nio チャネル セレクタの使用中に、Windows でソケットが
CLOSE_WAIT 状態のままになることが時折ありました。この問題は修正されています。
2 つのスレッドから互いに
getThreadInfo または
getStackTrace を呼び出すと、Oracle JRockit でデッドロックが発生します。この問題は修正されています。
コマンドライン オプション
-XlargePages でパラメータ
exitonfailure=false を使用すると、十分に大規模なページを取得できない場合に、デフォルトの動作をオーバーライドし、JVM を強制的に終了させることができるようになりました。次のようにしています。
-XlargePages:exitOnFailure=true
閉じられたインフレータでインフレートを呼び出すと、BEA JRockit がクラッシュし、コア ファイルが作成されることがありました。現在、JRockit では代わりに NullPointerException が送出されます。
(エリアス verboserefs を持つ) 冗長モジュール
referents は、新しい
refobj モジュールで置き換えられました。
-Xverbose :refobj を使用すると、参照オブジェクトに関して、より簡単でパフォーマンスの点で負荷の小さい統計が提供されます。出力内容は、
-Xverbose:refobj=debug によって提供されていた以前の referents モジュールの詳細な出力と似ています。この出力は、以前の referents モジュールと同様に、パフォーマンスの点で非常に負荷が大きいことに注意してください。
以前の referents モジュールを使用すると、
refobj=debug に変換されます。
クラッシュ ダンプの概要にメモリ システムの詳細情報が含まれるようになりました。
ヒープを拡大するべきときに Oracle JRockit でメモリ不足エラーを発生させる、ヒープ拡大に対するヒューリスティックの手違いが修正されました。
クラッシュ ファイルから Oracle JRockit ドキュメントへの直接リンクが追加されました。Oracle JRockit がクラッシュした場合、このリンクをクリックするとトラブルシューティングのためのドキュメントを開くことができます。
スタックトレースの出力コードのバグにより、スタックトレースの出力中に一定の条件の下で Oracle JRockit がクラッシュしました。これは、
-Xverbose:exceptions=debug を使用して WebLogic Server を起動したときに恒常的に発生していました。この問題は修正されています。
JVMTI を介して RetransformClasses を呼び出すと、エラー コード
JVMTI_ERROR_INVALID_CLASS_FORMAT によって失敗することがありました。この問題は修正されています。
JMAPI 呼び出し
com.bea.jvm.GarbageCollector.hasCompaction() は誤った値を返していました。この問題は修正されています。
Oracle JRockit が
-Xcheck:jni で起動され、JVMTI コールバック関数に渡されたスレッド参照が JNI 呼び出しで使用された場合、JVM はエラー
[ERROR][native ] Invalid reference で終了します。この問題は修正されています。
-Xgcreport フラグで生成されるレポートでは、ガベージ コレクションの休止時間がガベージ コレクション自体よりも長く表示される場合があります。この問題は解決されています。
最小休止対象の制限が 5 ミリ秒未満に引き下げられました。実際の最小休止対象は、実行中のアプリケーションによります。
空のバッファに対して
java.nio.MappedByteBuffer の
isLoaded()、
load()、または
force() メソッドを呼び出すと、IOException が送出されます。この問題は修正されています。
R27.5 では、例外スタック トレースの生成では、例外が非同期的に生成されたか (NullPointerException、StackOverflowError など)、遅延スタック トレースが有効になっているかに関係なく、常に完全なスタック トレースを含むように変更されています。
この結果、冗長モジュール stackoverflow は非推奨となり、現在は操作できません。このモジュールは次回の主要リリースで完全に削除される予定です。
BEA JRockit R27.3.1 を使用している顧客には、
AssertionError: unused が送出されることがあります。これは、ClassLoader に渡されるクラス/パッケージ名の形式が正しくないためです。
com.bea.MyClass の代わりに
com/bea/MyClass が渡されていました。この問題は修正されています。
BEA JRockit 5.0 Update 14 R27.5.0 では、Itanium 上の Linuxin および 64 ビット Xeon/AMD64 上の Linux に対して Sun PKCS#11 プロバイダ (
http://java.sun.com/j2se/1.5.0/docs/guide/security/p11guide.htm l) のサポートが追加されました (Sun バグ ID 6467921)。
R27.1 のクラスバイトの前処理機能では、再帰的前処理が許可されるように変更されました。つまり、クラスの前処理を現在実行し、これによって新しいクラスをロードしているクラス前処理プログラムのインスタンスが、新しいクラスバイトで再帰的に呼び出されることになります。これによって、27.1 よりも以前の動作に依存する既存の前処理プログラムではエラーが発生することがあります。R27.5 では、元の状態に戻されています。現在では、クラスの前処理を実行しているスレッドは、既存の前処理プログラム自体によって作成された型の前処理を確認なしにすべて拒否します。
遅延ロック解除によって発生する大量の保留のために、Windows IA64 を実行している Oracle JRockit ユーザは度々 GetThreadContext バグを経験していました。BEA JRockit R27.5 の Java 6 バージョンでは、IA64 を除くすべてのプラットフォームと、確定的ガベージ コレクタを除くすべてのガベージ コレクション方式について、遅延ロック解除がデフォルトで有効になっています。以前のリリースでは、コマンドライン オプション
-XXlazyUnlocking を使用して遅延ロック解除を有効にできます。
ガベージ コレクションの前またはガベージ コレクション中にヒープがいっぱいになった場合に、静的コンカレント ガベージ コレクタが緊急アクションとしてパラレル マークまたはスイープ フェーズを使用すると、ガベージ コレクションの方式が正しく報告されるようになりました。
-XXdisableGcHeuristics を指定すると、静的コンカレント ガベージ コレクタでの緊急パラレル マークまたはスイープを含め、すべての方式変更が無効になります。
R27 でに、
can_retransform_classes 機能を持つ JVMTI エージェントが、ロードされるクラスのバイト コードを置き換えた場合、必ずメモリ リークが発生するというバグがありました。これは、JRockit Management API (JMapi) を介して実行されるバイト コードの前処理にも影響を与えます。このバグは、R27.5 で修正されました。
JRA/LAT 記録を開始するとき、または Memleak を開くときに、JRockit Mission Control 3.0 が JRockit R27.3.0 からのライセンス エラーを適切に検出しませんでした。この問題は修正されています。
-XXcompactSetLimit は常に優先される用になりました。ただし、これは圧縮領域外部の参照にのみ適用されます。圧縮領域内部の参照の数は、このフラグによって制限されません。
レジスタ割り当てコードによって Oracle JRockit がまれにクラッシュすることがありました。この問題は修正されています。
Oracle JRockit では、現在のプラットフォームのアドレス空間よりも大きなメモリ サイズを受け入れません。つまり実際に、32 ビット システムでは、
-Xmx、
-Xms、および
-Xns に指定する値は 4 GB を越えることはできず、越えた場合には Oracle JRockit が起動しなくなります。
zip ファイル (Windows) または tar.gz (Linux) ファイルとして、www.beasys.co.jp
表 2-8 に示した CR の修正プログラムが含まれています。
メモリの割り当て時に Oracle JRockit がクラッシュすることがまれにありました。これは、
mmAllocObjectOrArray への呼び出しによって、TLA がフェッチしたのとまったく同じサイズの
largeObjectlimit バイトを割り当てようとしたときのみ発生しました。
アサーションの無効化は、ClassLoader が管理するアサーションには機能しませんでした。このため、デバッグ モードで WLS を起動するとアサーション エラーが発生する場合がありました。この原因は、ClassLoader に誤ったクラス/パッケージ名が指定されていることでした。この問題は修正されています。
注意 : この問題は Oracle JRockit R27.3.1 CP では解決されていますが、 R27.4 では未解決です。2008 年の始めにリリースが計画されている Oracle JRockit R27.5 では解決される予定です。
Oracle JRockit R27.3.1 の一般に確認済みのすべてのセキュリティ問題のパッチが既に作成され移植されています。この修正は、BEA セキュリティ勧告 BEA07-177.00 および BEA07-178.00 のセキュリティ問題に対応します。
AquaLogic Service Bus SFTP テストを実行しているときに、BEA JRockit は通常のコア ダンプを作成していました。この問題は、同じ to-array に対して arraycopy を実行する、同時に使用できない 2 つのコード パスの最適化にエラーがある可能性がある場合に発生していました。
BEA JRockit は、一部の Solaris 環境で、ソケット、コア、およびハードウェア スレッドの数を検出できない場合がありました。そのため、JVM が起動時に中止され、次のエラー メッセージが表示されていました。
[ERROR] Fatal error in JRockit during memory setup phase.
この状況は、使用可能なすべてのプロセッサのサブセットに関連するローカル ゾーンで発生する場合があります。この問題は解決されています。
mmListAddLast においてシステム クラッシュが発生することがありました。この問題は修正されています。
表 2-9 に、このバージョンの BEA JRockit JVM で行われた変更点を示します。
JMAPI 呼び出し
com.bea.jvm.GarbageCollector.hasCompaction() は誤った値を返していました。この問題は修正されています。
JVM が
-Xcheck:jni で起動され、JVMTI コールバック関数に渡されたスレッド参照が JNI 呼び出しで使用された場合、JVM はエラー
[ERROR][native ] Invalid reference で終了します。この問題は修正されています。
以前のバージョンの Oracle JRockit では、
JVMTI_HEAP_OBJECT_TAGGED と
JVMTI_HEAP_OBJECT_UNTAGGED を指定して JVMTI 関数
IterateOverHeap を呼び出すと、
JVMTI_HEAP_OBJECT_EITHER を指定して
IterateOverHeap を呼び出したときよりも多くのオブジェクトが報告されることがありました。この問題は修正されています。
リフレクションを使用して次のポインタを変更すると、ファントム参照オブジェクトの処理時にメモリ リークが発生していました。この問題は、このバージョンの Oracle JRockit で修正されています。
OS がスレッドの中断に失敗して、Oracle JRockit がクラッシュしたり、
EXCEPTION_ACCESS_VIOLATION エラーが送出されたりすることがありました。この問題は修正されています。
以前のバージョンのOracle JRockit では、JVM がレイテンシ分析記録やパーク イベントの記録を実行しているときでもハングできました。この問題は修正されています。
以前のバージョンの Oracle JRockit では、
java.lang.management.ThreadInfo API および JVMTI 関数
GetOwnedMonitorStackDepthInfo と
GetOwnedMonitorInfo は、JNI 関数
MonitorEnter を呼び出して入力されたモニタを返しませんでした。この問題は修正されています。
大きな配列の割り当てが失敗すると、JVMTI ResourceExhausted イベントが送信されないことがありました。この問題は修正されています。
以前のバージョンの Oracle JRockit では、
jvmtiHeapReferenceCallback コールバック関数が間違った
class_tag パラメータで呼び出される場合がありました。この問題は修正されています。
以前のバージョンの Oracle JRockit では、JVMTI 関数
FollowReferences と
IterateThroughHeap は
klass パラメータを考慮していませんでした。この問題は修正されています。
以前のバージョンの Oracle JRockit では、JVMTI 関数
GetClassVersionNumbers はプリミティブおよび配列クラスの
JVMTI_ERROR_ABSENT_INFORMATION を返しませんでした。この問題は修正されています。
AquaLogic Service Bus SFTP テストを実行しているときに、Oracle JRockit は通常のコア ダンプを作成していました。この問題は、同じ to-array に対して arraycopy を実行する、同時に使用できない 2 つのコード パスの最適化にエラーがある可能性がある場合に発生していました。
Oracle JRockit は、-128 ～ 127 の間でボックス化された整数のユニークな参照で、Java 言語仕様の要件によるエラーになることがなくなりました。
デフォルトでは、AMD の opteron アーキテクチャで割り当てのプリフェッチが有効になっています。
Oracle JRockit は、一部の Solaris 環境で、ソケット、コア、およびハードウェア スレッドの数を検出できない場合がありました。そのため、JVM が起動時に中止され、次のエラー メッセージが表示されていました。
[ERROR] Fatal error in JRockit during memory setup phase.
この状況は、使用可能なすべてのプロセッサのサブセットに関連するローカル ゾーンで発生する場合があります。この問題は解決されています。
JVMTI ClassPrepare イベントは、以前はクラスの初期化順序に依存していたため、ユーザー クラスの階層設計に従っていました。R27.4 では、ClassPrepare が常に仕様に従って送信されるように変更されました。
jrockit.ext.GCControl.forceGCToExit(boolean enabled)
jrockit.ext.GCControl.fullGC()
を含む、サポートされていない実験的な API GCControl が削除されました。
呼び出しのプロファイリングは、SPECjbb2005 ベンチマークを含む多くの作業負荷に大きなメリットをもたらす最適化機能です。Oracle JRockit R27.1 までは、コマンドライン オプション
-XXaggressive を使用してこの機能を有効化できましたが、R27.1 ではフラグから削除されました。Oracle JRockit R27.4 以降では、コマンドライン オプション
-XXcallProfiling を使用して呼び出しのプロファイリングを有効化できます。
接続フレームワークのバグ (Sun バグ #6559427) のため、Mission Control は、ローカルで実行中の JVM (Mission Control と同じマシンで実行する JVM) に対してポーリングを行うたびに、ローカルで実行中の JVM ごとに複数のハンドルをリークしていました。この問題は R27.4 で修正されています。
リンクされたリストが破損しているために、リフレクションによって次のポインタが変更され、オブジェクトのリークが発生することがありました。この問題は修正されています。
このバージョンの Oracle JRockit には、以下に示す 2 つの新しい Long perf 変数があります。
jrockit.gc.oc.compactionInternalCount jrockit.gc.oc.compactionExternalCount.
これらの変数は、それぞれ内部および外部の圧縮の数をカウントします。両方を合計すると、既存の
jrockit.gc.oc.compaction.no の値になります。
R27.4 の内部コード生成フレームワークを再び書き込むことによって、Oracle JRockit をクラッシュする確認済みバグはなくなっています。
Oracle JRockit では、ループが正しく最適化されず、配列のすべての要素に同じ負の値を割り当てる場合があります。
Linux または solaris 上で〔Ctrl〕+〔c〕を押してアプリケーションを適切にシャットダウンした場合、実際にはすぐに終了して、ディスクやデータベースに保存されていない実行時データが失われる危険性があります。これは、Oracle JRockit がシャットダウン フックに使用される SIGINT シグナル ハンドラを登録できないために発生します。
この問題が発生した場合、BEA のダウンロード ページから、更新された R27.3.1 バージョンの製品をダウンロードしてください。
この問題は Windows 上で実行しているアプリケーションには適用されません。
表 2-11 に、このバージョンの Oracle JRockit JVM で行われた変更点を示します。
jrcmd に関するドキュメント (以下の URL) には、
jrcmd の確認済みの制限に関する情報が示されています。
デフォルトの優先 TLA サイズ (
-XXtlaSize ) が変更されました。詳細については、BEA JRockit コマンドラインの
BEA JRockit コマンドライン リファレンス を参照してください。
非常に大きなメソッドを最適化しているときに、スタック オーバーフローが原因で JRockit がクラッシュする可能性がありました。この問題は修正されています。
-Xcheck:jni コマンドライン オプションを使用したときに JRockit で予期しないエラーが発生しました。JNI を使用して配列割り当てのダウンキャスト (Object のサブクラスの配列を Object の配列に要素として割り当てること、例 :
set [byte -> [[Object)) を行う場合、JRockit で誤検出が生じます。
JRockit は非常に大きな jsp クラスをロードできない場合があり、次のようなエラーが発生しました。
java.lang.ClassFormatError: <class> : illegal attribute
このエラーは、JRockit で
SourceDebugExtension 属性に関する 65536 の制限を使用したために発生していました。この制限は削除されています。
ガベージ コレクタ モード
-XgcPrio:pausetime では、
-Xgc:gencon の場合と同じサイズ (ハードウェア スレッド数の 10MB 倍) の固定ナーサリを使用するようになりました。
パラレル ガベージ コレクタを使用しているときに、時間制限に達したために退避が中断された場合、退避領域が 2 倍になりました。このバグが原因で、パラレル ガベージ コレクタ中に不要に長い休止時間が発生する可能性がありました。この問題は修正されています。
max_frame_count パラメータが
0 (ゼロ) の場合、JVMTI 関数
GetAllStackTraces は
JVMTI_ERROR_ILLEGAL_ARGUMENT を返していました。この問題は修正されています。
オブジェクトを保持しているスレッドが呼び出し中に終了した場合、JVMTI 関数
GetObjectMonitorUsage は
JVMTI_ERROR_THREAD_NOT_ALIVE を返す可能性がありました。仕様に準拠するために、代わりに
JVMTI_ERROR_NONE を返して
info_ptr->owner を
NULL に設定するように変更されました。
JRockit では、ZIP 標準で許可されている長さの名前を処理するようになりました。zip ファイルでのエントリ名の長さは最大 512 バイトという以前の制限はなくなりました。
仮想メモリ領域内の 4 GB 目の領域で、JRockit がすべての空きメモリを見つけられない場合がありました。このバグは 64 ビット Linux プラットフォームで発生し、最大 Java ヒープ サイズが約 3 ～ 4 GB である場合、
OutOfMemoryErrors を引き起こす可能性がありました。この問題は修正されています。
JMAPI
getProcessAffinity/suggestProcessAffinity は、2.3.4 より古いバージョンの GLIBC を使用する Linux システムで実行する場合に、正常に動作するようになりました。
休止時間の測定値は、R27.3 と以前のバージョンの JRockit (JRockit R27.2 は除く) とで比較できるようになりました。
PAE 拡張を使用し、4GB 以上の RAM がインストールされている 32 ビットマシンで、JRockit は物理 RAM の正確な容量を報告するようになりました。
スレッドローカル領域サイズ (
-XXtlaSize) の 18 倍未満のナーサリ サイズ (
-
Xns ) を指定した場合に、JRockit がハングしなくなりました。
Mercury Profiler ツールはこのリリースで削除されました。
Linux ia64 で
java.nio の
EPollSelectorProvider を使用できるようになりました。
注意 : EPollSelectorProvider は、システム プロパティ java.nio.channels.spi.SelectorProvider が sun.nio.ch.EPollSelectorProvider に設定されている場合にのみ使用されます。
JRockit R27.1 および R27.2 で、一部の MBean を実行しようとすると、クラスパスに指定されていても、一部のクラスが見つからない可能性がありました。この問題は修正されています。
以前は、まれに、(ヒープが断片化されている場合に) ヒープの大きな部分から大きなオブジェクトを移動しようとすると、外部圧縮が原因で非常に長い休止時間が発生していました。この問題は修正されています。
JDK 5 から JDK 1.4 にバックポートされた (Enum が使用される) 一部のクラスで、JRockit は誤った
serialVersionUID を計算しなくなりました。1.4 の場合に
serialVersionUID を計算するときは、Enum が適切に無視されるようになりました (Enum は 1.4 仕様の一部ではない)。
-Xmanagement フラグが更新されました。
引数を指定しないで起動した場合は、ローカルのインメモリ コネクタが起動されます。
以下の場合には、リモート コネクタが起動されます。
ssl オプションが
false に設定されている場合を除いて、リモート コネクタはデフォルトで SSL を使用します。
実行中の JRE のタイム ゾーン データ (tzdata) のバージョンを確認するには、以下を実行します。
デフォルトの
TLA サイズが大幅に増やされて、16MB ヒープでは 2K、2GB ヒープでは 256K まで増えました。
このリリースでは、実行時に (静的ガベージ コレクタ用の) ナーサリ サイズを更新するための新しいヒューリスティックを提供しています。
Windows XP では、
TotalGarbageCollectionTime の値がミリ秒単位で表示されるようになりました。
シングル CPU コンピュータで JDI によるシングルステップが速くなり、使いやすくなりました。
JRockit は
HyperThreading (HT) が有効になっているかどうかの検出に失敗しなくなりました。つまり、最適でない数のガベージ コレクション スレッドを起動することがなくなりました。
-Xns (ナーサリ サイズ) が設定されていて、
-Xms (初期ヒープ サイズ) が設定されていない場合は、初期ヒープ サイズが最大ヒープ サイズより大きくならない限り、初期ヒープ サイズはナーサリ サイズの 2 倍以上になります。
表 2-12 に、このバージョンの Oracle JRockit JVM で行われた変更点を示します。
JRA がクラスのアンロードを処理できなかったため、問題が発生していました。この状況は修正されました。
Oracle JRockit では、Java デッドロックの誤検出が生じなくなりました。
BEA JRockit R27.1 での退行が原因で
-Xverbose 出力がバッファされたため、遅延が発生していました。出力は遅延しなくなりました。
Windows 上の JDK 6 の
javaw ランチャでは、クラスパスのワイルドカードをサポートします。これは、
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6510337 で Sun から報告された問題に関する修正のバックポートです。
クラス パラメータが NULL の場合、JNI メソッド
ToReflectedMethod がクラッシュしました。この問題は修正されています。
メソッド
java.util.concurrent.atomic.AtomicReferenceArray.compareAndSet が呼び出されると、BEA JRockit がクラッシュする場合がありました。この問題は修正されています。
BEA JRockit のバイト コード検証は、JRockit の厳密なバイト コード検証により
ClassFormatErrors が送出されていた場合について緩和された。
配列をコピーしているときに、ガベージ コレクションのためにスレッドが中断されると、ガベージ コレクションが長く休止する可能性がありました。この問題は修正されています。
Windows 上の JRockit で、揮発性の静的変数の設定にリフレクションが使用されると、JRockit がクラッシュしました。この問題は修正されています。
jstat ツール (
/bin ディレクトリ内) がカウンタを使用すると、未解決のシンボルに関するエラー メッセージが生成されました。この問題は修正され、
jstat は廃止されたカウンタを使用しなくなりました。
-Xgcprio :throughput によって使用される、ナーサリ サイズを設定し、ガベージ コレクタ方式を選択するためのヒューリスティックが改良されました。
jvmtiObjectReferenceCallback 関数の
referrer_index 引数が、
-1 に設定すべき場合に必ずしも設定されていませんでした。この問題は修正されています。
ia64 で
jrcmd ユーティリティに、9 文字より長いユーザ名に関する問題がありました。この問題は修正されています。
BEA JRockit のメソッド プロファイラのタイミング カウンタは富士通の SPARC 実装 SPARC64 で使用できなくなった。JRockit がこのプラットフォームで誤ったタイミング データ (負の数) を使用する場合があったためである。
GarbageCollector クラスの
getNurserySize() メソッドが記述どおりに動作するようになりました。つまり、JVM が (ナーサリのない) シングルスペース ガベージ コレクタを実行している場合、
NotAvailableException が送出されます。以前は、メソッドが
0 (ゼロ) を返していました。
JVM がシングルスペース ガベージ コレクタを実行している場合、メソッド
setNurserySize() は
NotAvailableException を送出します。
新しいコマンドライン オプション
-XX:MaximumNurseryPercentage は、最近の古いコレクション後の使用可能なヒープの空き領域の割合まで、ナーサリの最大サイズを制限します。デフォルト値は 95% です。
JRA がまだ実際には記録を開始していないが起動状態にある場合に、JRA の記録を停止するために Ctrl-Break ハンドラを送信できるようになりました。JRA が起動したところである場合は、記録が実際に停止されるまでにわずかな遅延が生じる可能性があります。
以前は、JRA が実際に記録を開始する前に Ctrl-Break ハンドラを送信して JRA を停止すると、以下のエラー メッセージが生成されていました。
Error: No JRA recording running.
Linux 環境でスレッド名が使用できない問題が修正されました。
genpar および
singlepar パラメータが
-Xgc オプションに追加されました。これらのパラメータを指定して
-Xgc オプションを使用すると、パラメータ
genparpar および
singleparpar を指定して
-XXsetgc オプションを使用する場合と同じになります。
オプション
-XlargePages が追加されました。このオプションは
-XXlargePages に代わるものですが、下位互換性を保つために古いコマンドライン オプションも保持されます。
TLA の最小サイズと優先サイズ、大きなオブジェクトの制限、最小ブロック サイズの間で、常に次のような関係が自動的に維持されます。
これらのオプションを複数設定する場合は、使用する値がこれらの条件を満たしていることを確認してください。1 つのオプションのみを設定すると、他のオプションは必要に応じて、それぞれの値が有効になるように適応します。
メモリ管理のチューニングを目的として、主に TLA サイズのパラメータを設定し、大きなオブジェクトの制限や最小ブロック サイズは BEA JRockit に自動的に調整させることをお勧めします。デフォルトでは、大きなオブジェクトの制限は、(1) TLA の最小サイズ、(2) TLA の優先サイズを 2 で割った値のうち、小さい方の値に設定されます。デフォルトの最小ブロック サイズは 2k です。
Memory Leak Detector で、割り当てスタック トレースの最初の 20 フレームのみを取得するという制限がなくなりました。
-Xverbose :referents (または、
-Xverbose :verboserefs) を使用すると、古い世代のガベージ コレクションごとのすべての参照オブジェクトと、参照オブジェクトが指しているリファレントが出力されます。以前のバージョンの BEA JRockit では、オプション
-Djrockit.verboserefs でこの動作を指定していました。
表 2-13 に、このバージョンの Oracle JRockit JVM で行われた変更点を示します。
最適化されたメソッドを null オブジェクトに対して呼び出すと、予期された動作のとおりに
NullPointerException が送出されるようになりました。
これまでの windows 向け jrockit インストーラでは、[Install Public JRE] オプションが 32 ビット Windows にしか選択できなかった。このオプションが、Windows 64 ビット JRockit バージョン (x86-64 および Itanium) でもサポートされるようになりました。
コマンドライン オプション
-Xverbose:gcpause が改善されました。詳細については、
Oracle JRockit コマンドライン リファレンス の「
-Xverbose」を参照してください。
JRockit R27.1 以降では、古い
LinuxThreads ライブラリを使う Linux バージョンはサポートされません。Red Hat AS 2.1、SuSE ES 8.0 など、標準 2.4 カーネルに基づくディストリビューションがこれに該当します。サポート対象リリースの詳細については、『
サポート対象のコンフィグレーション 』を参照してください。
32 ビットと 64 ビットの BEA JRockit JDK/JRE を Windows x86_64 に両方同時にインストールすることが可能になりました。
>this< ポインタをそれ自身のオブジェクトに格納する不正なマシン コードが Java コードに生成される問題が修正されました。これは、まれに Java 変数が 0 に設定される原因となっていました。
"system" スレッド グループの内部 jvm スレッドでは、
isDaemon() および
getPriority() の値が不正だった。この問題は修正されています。
メモリの断片化が進んでいる状態で JRockit を起動すると、ダンプ ファイルを作成する段階で JRockit がクラッシュしました。この問題は修正されています。
java.lang.StackTraceElement の動作が変更され、Sun のリファレンス実装の動作と同じになりました。以前のリリースでは、このメソッドによって生成される文字列にメソッド シグネチャが含まれましたが、新しいバージョンは次のドキュメントの説明どおりに動作します。
この変更は
Throwable.printStackTrace() の動作にも影響を与えます。このメソッドの実行結果にはメソッド シグネチャが含まれなくなります。
Thread.sleep(...) または
Object.wait(...) で開始した長期のスレッド スリープはスリープ時間が
0x3FFFFFFF ミリ秒 (約 12.4 日) より長い場合、途中で終了することがありました。この問題は修正されています。
Java SE 5.0 バージョンの JRockit R27.1 で使用される JVMTI API のバージョンは 1.1 です。このバージョンは、
GetVersionNumber API 関数を使って確認できます。JVMTI 1.1 の一部の機能は Java SE 5.0 バージョンの JRockit で使用できません。
以前は、内部デッドロックがまれに発生することがありました。スレッド ダンプのスタック トレース中に、クラスのローディングが必要な呼び出しが行われるのがデッドロックの原因でした。
Windows プラットフォーム用の BEA スタンドアロン インストーラのファイル名が変更されました。対象オペレーティング システムのプラットフォーム部分の表記が "win" から "windows" に変わった。
コマンドライン オプションの検証が厳密になったため、不正なコマンドライン オプションを使うと、これまでより詳細なエラー メッセージや警告が出力されます。詳細については、
Oracle JRockit リファレンス マニュアル を参照。
String.indexOf() を呼び出すメソッドのコンパイル中に、まれに JRockit がクラッシュすることがありました。この問題は修正されています。
アプリケーションから大量の例外が送出されたときに JRockit コード最適化処理のバグが原因でクラッシュが発生していましたが、この問題は修正されました。
-Xverbose からのデフォルトの出力に、モジュールに加えてログ レベルも追加されました。このデフォルト設定を変更するには、
-XverboseDecorations を使用します。
JMAPI 関数
JVM.getProcessAffinity() が Linux で正常に動作するようになりました。
内部関数
handlersMatchExceptForUnlockHandler で JRockit がクラッシュするバグが修正されました。
RSA シグネチャ検証に見つかったセキュリティの脆弱性 (Sun Alert ID 102686) が Sun JDK 1.4.2_13 で修正され、これが JRockit 1.4.2_12 R27.1.0 にも反映されました。
RSA シグネチャ検証に見つかったセキュリティの脆弱性 (Sun Alert ID 102686) が Sun JDK 5.0 update 9 で修正され、これが JRockit 5.0 update 8 R27.1.0 にも反映された。
TotalGCTime が正確な値を示すように修正されました。
以前は、JRockit Management API および WLS コンソールを通して誤った値が表示される場合がありました。
正常時の制御フローと例外時の制御フローが javac の規則に従わないバイトコードをコンパイルすると JRockit がクラッシュしていましたが、この問題は修正されました。BEA で確認した限り、このようなバイトコードを生成するバイトコード難読化ツールは少数です。
コマンドライン オプション
-Xmanagement の動作が、このリリースで変更されました。
R27 では JRCMD が書き直され、それにともなって
<jre>/bin/jrcmd ランチャが削除されました (
<jdk>/bin/jrcmd は残っている)。つまり、JRCMD ツールを使用できるのは、JRockit JRE をインストールした場合ではなく、完全な JRockit JDK をインストールした場合だけになりました。
「シリアライゼーションにおけるセキュリティの脆弱性」の問題 (Sun Alert ID 102731) が Sun JDK 1.4.2_13 で修正され、これが JRockit 1.4.2_12 R27.1 にも反映されました。
表 2-14 に、確認済みの問題を示します。これらは JRockit JDK のパフォーマンスに影響を与える場合があります。
シグナル処理の競合によって JRockit JVM がクラッシュする。
JRockit JVM を OS シグナルに依存するネイティブ ライブラリと一緒に使用すると、Oracle JRockit とネイティブ ライブラリの間でシグナル処理の競合が発生し、クラッシュすることがあります。
環境変数
LD_PRELOAD を次のように設定します。
export LD_PRELOAD=$JROCKIT_HOME/jre/lib/i386/libjsig.so
この競合は、Oracle Engineering で IBM の MQSeries ネイティブ ドライバを使用していて確認されました。ネイティブ コードに依存するほかのライブラリでも発生する可能性があります。
Oracle JRockit が OEL または OVM で実行している場合、OEL で修正が必要です。 次に OVM の OEL で JRockit を実行するための最低限の要件を示します。
JRockit はハードウェアと準仮想化バージョン、および OEL 4 と OEL 5 をサポートします。
注意 : この問題もバグ 8324323 で追跡しています。
32 ビット JRockit インスタンスの 64 ビット マシンで実行した場合、
JVMFactory.getJVM().getMachine().getPhysicalMemory().getUsedMemory() は 0 を返します。
Oracle JRockit Mission Control 3.1.0 および Oracle JRockit Real Time 3.1.0 以降は、各製品インストール ディレクトリが Oracle ホームとしても機能し、Oracle セントラル インベントリに追加の製品を登録できます。セントラル インベントリには同一のホスト上にインストールされたすべての Oracle 製品に関する情報が格納され、Oracle Universal Installer を実行することで管理できます。
ときどき、Eclipse で、捕捉されなかった
java.lang.ClassCastException のスローをデバグするときに、デバグされた JVM がクラッシュする可能性があります。
JRockit JVM は、
java.math.BigDecimal オブジェクトを IIOP 上にシリアライズ化するときに Sun HotSpot で対応しません。
Windows 上の
java.util.zip.ZipFile コンストラクタに 256 文字以上の長さのファイル（パスも含む）を入力することに失敗し、ファイルが存在しても、j
ava.io.FileNotFoundException を送出します。
JRockit JVM は、AES 暗号化コードを実行するときに、
pkcs11_softtoken.so ネイティブ ライブラリでクラッシュする可能性があります。これは、Solaris の バージョン 10.4 とその以前のバージョンにあるバグによるものです。Solaris 10.5 でバグは修正されています。
64-ビット Windows Vista/2008 の問題により、標準フォルダに 64-ビット JRockit JVM をインストールしようとすると、インストーラは指定したフォルダに書き込むことができないというメッセージが表示されることがあります。ただし、その他のフォルダ(インストーラが
書き込み可能な フォルダ) にインストールするようにするとファイルがコピーされます。その後、インストーラがアンインストール情報を書き込もうとして失敗します。その結果、アンインストーラが操作しなくて、インストールに失敗します。
ファイルを右クリックし、
Run as administrator を選択して、JRockit JDK をインストールします。
注意 : この問題は Oracle JRockit R27.6 で修正されています。
実行中の Linux IA32 対応 JRockit JVM ビルド（バージョン R26.3 から R27.5 ）に 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 」を参照します。
Windows Vista x64 上に、JRockit JVM の 32-ビット バージョンを使用して、SSE2-有効プラットフォーム (Pentium 4 またはそれ以降、AMD Opteron、Athlon 64 2003 または以降のプロセッサ) 上に Java 浮動小数点アプリケーションをデバグするとき、ローカル浮動小数点変数の値が誤る可能性があります。これは、Windows Vista x64 のバグによるものです。このバグは、Windows Vista x64 SP1 で修正されています。
Oracle JRockit JVM R27.4 とリリースされた JRockit Mission Control では、JRA 記録内のガベージコレクションの [
GC 前のヒープ使用量 ] に表示される値は不正です。表示される値は、実際には進行中のコレクションの [
GC 後のヒープ使用量 ] の値でした。これは、Oracle JRockit JVM R27.5 で修正されます。
一部のシステムでは、ユーザごとの
hsperfdata_<user> ディレクトリの ACL によって、管理上の問題が発生する場合があります。一例として、管理者特権を持つユーザはこのディレクトリのファイルを削除できるが、ディレクトリ自体を削除できないという問題があります。
管理者としてログインし、ディレクトリを削除する前に
cacls コマンドを使用して ACL を変更します。
特定の条件の下で、JRockit JVM は早期にメンバ変数のガベージ コレクションを実行することがまれにあります。これによって、ハングやクラッシュなどの誤動作が引き起こされます。
Java プログラムがあまりにも多く (現在は 2097151) のアクティブなモニタを (つまり、多数のオブジェクトに対して待機/通知または競合同期化を実行することによって) 使用した場合、JVM の内部モニタ インデックスがオーバーフローすることがあります。これは、大規模なヒープを使用したり、ガベージ コレクションがほとんど発生しないときに、起こりやすくなります。これが起こると、"アクティブなオブジェクト モニタの数がオーバーフローしています" というエラーが発生して JVM がクラッシュします。
Linux で複合ウィンドウ マネージャ上で JRockit JDK をインストールしたりアプリケーションを使用したりすると、"
xcb_xlib.c:50: xcb_xlib_unlock: assertion 'c->xlib.lock' failed." というエラー メッセージが表示されて失敗します。これはネイティブ Sun JDK ライブラリの既知の問題によるものです。
Sun バグ 6532373 を参照してください。
この問題の回避策については、「
CR349882 の回避策 」を参照してください。
注意 : この問題は Oracle JRockit 5.0 R27.6.3 および Oracle JRockit 6 R27.6.3 で修正されています。
IA64 (
-XXhpm) でハードウェア パフォーマンス カウンタと共に JRockit JVM を実行中に Java の問題をデバッグすると、例外が発生する可能性があります。これは、ハードウェア パフォーマンス カウンタの実装がシグナルを使用して JVM との通信を行い、デバッガ エージェントの実装 (JDWP) がこれを正しく処理できないためです。
デバッグ中はハードウェア パフォーマンス カウンタを無効にします。
JRockit JDK では、Management console からアクセス可能な Mbean を
bea.jrockit.management ドメインで公開します。これらの MBean は独自のものであるため、いつでも変更される可能性があります。これらの MBean には他の JMX ベースのツールから直接アクセスできますが、このような直接アクセスは Oracle ではサポートしていません。
最大アドレス空間 (4 GB) より最大ヒープ サイズを大きくして JRockit JVM を linux ia32 上で起動した場合、エラー メッセージが生成されて正しく終了する代わりに JVM がクラッシュすることがあります。
空のバッファに対して
java.nio.MappedByteBuffer の
isLoaded()、
load()、または
force() メソッドを呼び出すと、確認なく制御が戻るのではなく、IOException が送出されます。これは、IntelliJ IDEA IDE に影響することが確認されています。
スレッド レイテンシ ログ テーブルのイベント情報のクリップボードへのコピーが正しく行われません。ヘッダ情報のみがコピーされます。この問題は、JRockit JVM R27.5.0 に含まれる Mission Control で修正される予定です。
JRA レイテンシ記録の一部のイベントで、スレッド ID がゼロに設定されています。具体的には、
JVM Event Wait->Signalling thread、
Java Synchronization->Last holder thread、および
Java Synchronization->Holder thread に適用されます。
JRockit JDK 1.4.2 の実行中に、
class パラメータの後に追加パラメータを付加してコマンドライン オプション
-Xmanagement を使用すると、間違ったエラー メッセージを受け取ることがあります。たとえば、次のように指定した場合です。
java -Xmanagement:class=foo,ssl=false Hello
この場合、次のようなエラー メッセージが表示されます。
Unknown parameter class
class パラメータの後に、任意のパラメータを指定することはできないため、この場合の正しいエラー メッセージは次のようになります。
Unknown parameter ssl
詳細については、
-Xmanagementのマニュアル を参照してください。
JRockit Management API (JMAPI) を使用するプログラムのコンパイルに JRockit JDK の Java SE 6 バージョンの
javac を使用すると、「パッケージ
com.bea.jvm は存在しません」というエラー メッセージが表示されます。
<jrockit_home>\lib\ct.sym ファイルを削除 (または名前変更) してから、再コンパイルしてください。 javac を使用してください。
JRA の記録で、割り当てられた TLA (スレッド ローカル領域) の数および TLA の優先サイズ (バイト単位) が記録されます。JRA GUI では、記録中にこれらの値を乗算して TLA に割り当てられたバイト数を取得します。ただし、実際に使用されている TLA のサイズは、報告されたサイズ (優先サイズは優先サイズにすぎません。断片化により TLA が小さくなることがあります) よりも若干小さく、GUI に出力される値は大きく見積もられていることがあります。
Mission Control の [注意] タブでコメントが保存された場合、JRA 記録のレイテンシ データがディスクから消去されます。レイテンシ以外のデータはそのまま使用できますが、「
Warning! Error(s) when reading JRA-recording」というメッセージが表示されます。
レイテンシ データが含まれる記録を操作する場合は、Mission Control の [注意] タブを使用しないでください。
-XXcompactSetLimit フラグが必ずしも圧縮セットを制限するとは限りません。圧縮は、一部の状況 (通常は、ヒープ全体が外部圧縮用に処理される前の初期圧縮時) において、指定された上限を超えることがあります。
Mission control を使用して Jra 記録を開始したときに、記録が開始されず、「Could not delete file」というエラー メッセージが表示される場合があります。この問題は、記録のファイル名が以前に開始した記録とまったく同じである場合に起こります。
JRA 記録ウィザードで、各記録にユニークな名前を付けるか、Mission Control を閉じてから再起動します。
set_filename ハンドラが、コマンド バッチ実行用の出力を更新しません。
set_filename コマンドを発行します。
Red Hat Enterprise Linux 5.0 on x86_64 で glibc の
dladdr() 呼び出しに関する確認済みの問題があり、グラフィカル アプリケーションを実行するときに不明な動作またクラッシュが起きる可能性がありました。Red Hat Errata RHBA-2007:0619-3 について、「
http://rhn.redhat.com/errata/RHBA-2007-0619.html」を参照します。この問題は、Red Hat Enterprise Linux 5.1 で修正されています。
休止時間の測定方法に関して、R27.2 で退行が生じました。休止時間は jrockit Runtime Analyzer ツール、および
Mark:Final:StopThreads 休止部分の冗長ログで確認できますが、以前のバージョンの JRockit JVM よりも休止時間が長くなったように見えます。つまり、休止時間の測定は、R27.2 と JRockit JVM の以前のリリースとの間で比較できない。実際の休止時間は変更されていません。
注意 : この問題は BEA JRockit R27.3 で修正されています。
スレッドローカル領域のサイズ (
-XXtlasize) の 18 倍未満のナーサリ サイズ (
-xns ) を指定すると、JRockit JVM がエラーを出力しないでハングする。
指定されたナーサリ サイズを増やすか (
-Xns を使用)、TLA の最小サイズを減らします。
JRockit R27.1 の時点で、TLA サイズを指定する形式が変更され、TLA の最小サイズと優先サイズの両方を指定するようになりました。以前の方法では、
-XXtlaSize:<size> によって最小サイズと優先サイズの両方が設定されました。優先 TLA サイズを設定するには、
-XXtlaSize:preferred を使用します (例 :
-XXtlaSize:preferred=64k)。
注意 : この問題は BEA JRockit R27.3 で修正されています。
32 ビット JMV を使用し、最大ヒープ サイズを 4GB より大きな値に設定している場合、JRockit JVM は 4GB を超えない範囲でできる限り大きなヒープを割り当てます。その結果、ヒープがすべてのアドレス空間を占有してしまい、JVM が内部メモリ不足エラーを送出する可能性があります。
この状況が発生した場合は、ヒープを 4GB より小さい値に減らします。
Linux ia64 および JRockit 5.0 R27.2 では
java.nio の
EPollSelectorProvider を使用できません。システム プロパティ
java.nio.channels.spi.SelectorProvider を
sun.nio.ch.EPollSelectorProvider に設定した場合にのみ、
EPollSelectorProvider が使用されます。
注意 : この問題は BEA JRockit R27.3 で修正されています。
JRA の記録中はコード ガベージ コレクションが無効になるため、まれな状況において、記録中にネイティブ メモリの使用量が増える可能性があります。非常に長時間の記録 (数時間または数日間) を実行しているか、短期間の記録を連続して実行している場合に、多数のクラスをロードすると、この状況が起きることがあります。
回避策としては、記録を複数回実行し、JRA の実行の間隔を一定時間 (数分間が適当) 取って、JVM がコード ガベージ コレクションを実行できるようにします。
Solaris 10 で、
getrusage が誤った値を次々に返すというバグが原因で、ページ フォールトのすべての出力に誤った値が表示されます。たとえば、
-Xverbose:memory を使用した場合に、このような出力が表示されることがあります。
この Solaris バグは「“6288308, Uninitialized struct causes getrusage(3C) to return bogus data (構造体が初期化されていないために getrusage(3C) が誤ったデータを返す)」で特定されています。Sun によると、バグ 6288308 の修正を含む最初のカーネル パッチは 118833-24 です。
http://sunsolve.sun.com/search/document.do?assetkey=urn:cds:docid:1-21-118833-24-1 を参照してください。
Sun の J2SE 5.0 update 11 で確認済みの問題により、
PrinterJob.printDialog() がサブスレッドから呼び出されると BEA JRockit がダンプする可能性がある。BEA では、IA32 アーキテクチャで Windows Vista を使用した場合にのみ、このバグを特定しています。この確認済みの問題は 5.0 update 11 で修正され、JRockit R27.3 で対応する予定。
Windows 上の JDK 6 に含まれている新しいランチャ
java-rmi.exe が想定どおりに動作しません。この問題は、Sun の元のバグ レポート (
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6512052 ) でも報告されています。
配列をコピーしているときにガベージ コレクションのためにスレッドが中断されると、ガベージ コレクションで長時間の休止が起きる場合があります。休止時間がときどき長くなる場合は、この問題の可能性があります。この問題は 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 のバージョンについては、『
サポート対象のコンフィグレーション 』ドキュメントを参照してください。
JRockit JDK を Windows Server 2003 の Itanium バージョン上に使用し、Java アプリケーションが高システム負荷のときに不意にハングする場合、JVM がオペレーティング システム バグをトリガしたことを意味します。OS レベルで、このバグは、Windows
GetThreadContext 関数を呼び出すと、JRockit JVM がブロックするために発生します。Microsoft がナレッジ ベース記事を送られます。この記事には、この問題の修正方法について指示します。「
http://support.microsoft.com/kb/947504 」参照してください。
ia64 で 9 文字を超える長さのユーザ名を使うと、
jrcmd ユーティリティで問題が発生することがあります。この問題は他のプラットフォームでは発生しません。この問題は BEA JRockit R27.2 で修正されました。
最大ヒープ サイズ (
-Xmx) より大きい最小 tla サイズ (
-XXtlaSize:min=x) を指定して JRockit JMV を起動した場合、JRockit は起動時にデッドロックし、実行されなくなります。
最小 TLA サイズを最大ヒープ サイズより小さくします。通常、TLA サイズはヒープ サイズを大幅に下回る値にする必要があります。
R27.1 では、
GarbageCollector クラスの JMAPI メソッド
getNurserySize() がドキュメントの説明どおりに動作しない。ドキュメントの記述によると、JMV で実行中のガベージ コレクタがナーサリを使用しない場合にこのメソッドは
NotAvailableException を送出します。実際には、
0 を返します。この問題は R27.2 で修正されました。
送出される例外に基づいてナーサリが使われたかどうかをチェックしている場合は、
NotAvailableException を捕捉するだけでなく、メソッドからの戻り値もチェックして
0 が返されたかどうかを確認することで、この問題を回避できます。例外が送出されるか、
0 が返されるのは、ナーサリが使用されないことを意味します。
JRA 記録が含まれるファイルは JRockit Mission Control にドラッグ アンド ドロップできます。ただし、複数のファイルをドロップすると、ファイルを開くためのタブに実際のファイル名ではなく「JRA Editor」と表示されることがある。
ファイルのタブを選択してから実際にファイルを読み込むと、ラベルの表示が正しいファイル名に設定されます。
ナーサリが小さすぎると、昇格が行われないまま若いコレクションが次々とトリガされて JRockit がスタックする場合がある。この現象は
-Xverbose:memdbg の出力に、若いコレクションの連続発生とオブジェクト昇格数 0 として現れます。若いコレクションが非常に短い時間 (0 ミリ秒に近い数値) で実行されるのも、この状況を示しています。
ナーサリ サイズを増やします。ナーサリ サイズを
-Xgcprio:throughput で自動的に設定している場合は、手動で
-Xns を大きな値に設定して、オーバーライドできます。
Red Flag 5.0 で
wait() 呼び出しに関する確認済みの問題があり、この OS バージョンを使用する RedFlag ユーザにとって不明な動作またクラッシュが起きる可能性がありました。この問題は AsianUX 2.0 SP1 (Red Flag 5.0 はその一部) で修正されているため、OS をアップグレードしてこの問題を解決することを強くお勧めします。
4 Gb に近いヒープ サイズが設定されていて、多数のクラスがあるアプリケーションでは、JMV 内部構造と Java ヒープの両方がプロセスの 4 GB メモリ空間を共有しようとした場合に、メモリ不足に陥るおそれがあります。この問題が発生した場合は、
-Xmx オプションを使用するか、
-XXcompressedRefs=0 オプションを使って圧縮参照を無効にして、Java ヒープ サイズを増やすか減らす。
Red Hat Enterprise Linux 4.0 で
-XXmme オプションを使用するには、Red Hat Enterprise Linux 4.0 QU4 以降のリリースをインストールする必要がある。それ以外の場合、クラッシュが散発的に発生する可能性があります。
5.0 Update 7 で、Sun は以前からあった誤りを修正するため、
javax.xml.namespace.QName() クラスの
serialVersionUID を変更しました。元のバグ レポートについては、以下に示した Sun のバグ データベースの CR6267224 を参照してください。
古い互換値を使用するには、次のシステム プロパティを設定します。
com.sun.xml.namespace.QName.useCompatibleSerialVersionUID=1.0
CR349882 で説明した確認済みの問題の回避策を示します。
patch_java.sh (コード リスト 2-1 ) を解凍済みの JDK または JRE に適用します。
コード リスト 2-1 patch_java.sh のサンプル
*.bin が、上記と同じエラー メッセージが表示され、すぐに失敗する場合は、インストーラ プログラムを手動で解凍して、次のパッチ (コード リスト 2-2 ) を内部 JRE に適用し、パッチ適用済みの JRE を使用して GUI モードで手動でインストーラを起動することで、問題を回避できます。
コード リスト 2-2 patch_and_run_installer.sh のサンプル
