はい、BEA JRockit クラス ライブラリは Sun のクラス ライブラリと完全互換です。

動的な最適化は他のコード生成と並行して行われます。つまり、アプリケーションの実行と衝突することはありません。コード生成のためのリソースが不足しないように、大部分のコードは最適化されません。

PAE (Physical Address Extension) は、物理メモリをプロセスの仮想メモリ アドレス空間にマップすることを可能にします。一度にマップできるのは 2GB だけです (/3GB オプションを指定した場合は 3GB)。つまり、物理アドレス空間のいろいろな部分をマップするためには、仮想アドレス空間を再利用する必要があるのです。したがって、それ以上のメモリを通常のポインタで単純にアドレッシングすることはできません。そのため、通常の Java ヒープではうまくいきません。通常の Java ヒープでは 32 ビットのポインタを使ってオブジェクトを参照し、いつでも仮想アドレス空間内の全ヒープを必要とします。

PAE はマッピングとメモリ アクセスを共同で制御できるアプリケーションで効果を発揮します。PAE は現時点では Java にあまり適していません。とはいえ、ネイティブのデータベース ドライバなら、データのキャッシュに PAE を使用することも考えられます。これを実現したい場合は、どうやって実現するかをいろいろなデータベース ベンダと相談するとよいでしょう。JNI を使ってネイティブ データベース API の上に独自の「DB アクセス レイヤ」を置くことで、カスタム キャッシュを作成するという方法もあるでしょう。

豊富な物理メモリを利用する方法としては、このほかに複数の Java プロセスを使用するというやり方もあります (Windows の各プロセスはプライベートなアドレス空間用に 2GB の物理メモリを取得できます)。

より大きな Java ヒープが必要なときは、64 ビット版の BEA JRockit、つまり Windows Server 2003 または Linux 用の Itanium バージョンが必要になります。

BEA JRockit 5.0 では、スレッドの優先順位のあるプラットフォームのうちでサポートしているのは Windows (IA32 と Itanium の両方) だけです。Linux 上ではサポートされていません。

適用されるのは Windows プラットフォームだけであるとはいえ、Sun のデフォルト動作では、すべてのプラットフォームについて Java からのすべてのスレッド優先順位変更要求を無視することが BEA JRockit に求められます。IA32 または Itanium Windows を実行している場合は、フラグ -XXusethreadpriorities を渡すことで優先順位変更要求の無視をやめるように JVM をコンフィグレーションすることができます。ただし、このフラグはすべてのプラットフォームで有効であるのに、Windows でしか意味を持ちません。

優先順位変更要求はデフォルトでは無視されます。なぜなら、優先順位変更要求が不適切に適用された場合、アプリケーションの動作は変更前より悪くなるからです。あるスレッドに設定した優先順位が高すぎる場合、そのスレッドはリソースを過剰に消費することになり、パフォーマンスに深刻な影響を及ぼします。それに対し、設定した優先順位が低すぎると、優先順位の逆転が起こるおそれがあります。優先順位の逆転が起きると、優先順位の高いスレッドは優先順位の低いスレッドによるロックを待つので、いつまでも実行されず、その一方で、優先順位の高いスレッドがすべての CPU 時間を獲得するので、優先順位の低いスレッドにはロックを解除する機会がいつまでも与えられない、という状況が生じます。そのため、優先順位を設定したり使用したりするのは熟練プログラマに限るべきです。