HotSpotとJRockitの合併の理由
この決定は、コスト削減によるものです。 Oracleは、両方のJVMに対する顧客の要件は基本的に同じであり、ユーザーは両方の製品で同じことを見たいと考えていると述べました。 これらの目標を達成するために、両方のJVMの開発者は、EscapeAnalysisと予測可能なガベージコレクター（HotSpotのGarbage FirstとJRockitのDeterministic GC）など、同じアイデアを独自に思いつきます。 では、なぜ仕事を複製するように頼むのですか？
基礎としてどのJVMを使用しますか？
各決定にはそれぞれ長所と短所があります。 現時点では、HotSpotの長所は、幅広い使用領域、大規模な顧客ベース、高い耐障害性とパフォーマンスと考えることができます。 JRockitは、LinuxおよびWindows上のOracle製品のスタックの最適化、ソフトリアルタイムソリューションの利用可能性、およびOSなしのベアメタルで実行するためのバージョン（もちろん、任意の特殊なハードウェア上）で際立っています。
驚くべきことに、どのような種類のJVMをベースとするかについて長い議論がありました。 その結果、HotSpotを支持して決定が下されましたが、議論は技術的ではありませんでした。 その理由は、HotSpotに基づいて作成されたOpenJDKの存在、HotSpotに取り組んでいるエンジニアの数（JRockitに取り組んでいるエンジニアは、新しい共通JDKで子孫の機能を実装します）、IBM、HP、および他の企業がHotSpotを変更するために発行したライセンスです。 悲しいニュースもあります-すべてのマージがOpenJDKに分類されるわけではありません。 合併の最初の結果はJava 7ですでに見られます。たとえば、PermGenをそこでCヒープに転送することはすでに計画されています。 2年以内にすべての合併作業を完了する予定です。
最新の仮想マシンの要件
最新の仮想マシンの要件は何ですか？ 1つ目はスケーラビリティです。 仮想マシンは、携帯電話からメインフレームまで、さまざまなマシンで実行する必要があります。大量のメモリを操作し、多数のハードウェアストリーム（〜10000）で効率的に作業し、メモリトポロジを考慮に入れる必要があります。 2つ目は速度です。 仮想マシンは、生産性が高く、予測可能（JIT、GC）であり、迅速に起動し、フットプリントが小さい必要があります。
HotSpotの最新ニュースと最適化
NUMA割り当て。 作業が行われるプロセッサに近いメモリにオブジェクトを作成できます。 ストリームがオブジェクトを作成し、より多く動作する可能性が高いため、利益は一見の価値があります。 さまざまなテストで、25〜300％のパフォーマンスの向上が示されました。
文字列を使用した作業の最適化。 さまざまなアプリケーションが文字列でうまく機能することは秘密ではありません。Pramでなくても、さまざまなライブラリメソッドが文字列を作成します。 たとえば、文字列のマージ（-XX：+ OptimizeStringConcat）、文字列のコピー、文字列圧縮（-XX：+ UseCompressedStrings、6u21pでのみ使用可能、無効）などの最適化が行われました。これにより、可能であれば、バイトの配列に文字を格納できます。同じ文字列キャッシュ（XX：+ UseStringCache）。
圧縮ポインタ。 JVMが利益を上げると判断した場合、自動的にオンになります。 ただし、-XX：+ UseCompressedOopsパラメーターを使用して有効にすることができます。 この圧縮は、位置合わせ中に失われるスペースを減らすのに役立つシフトにより発生します。 このオプションを使用すると、最大32 GBのメモリで作業できます。 彼らは、32ビットJVMよりもさらに速く動作すると言います。
ごみモミ。 バージョン6u14以降、-XX：+ UseG1GCパラメーターで有効にできます。 このコレクターは既に非常に安定して動作していますが、パフォーマンスのマイナーな問題があるため、まだ終了していません（スパイクが発生します）。
ステップのコンパイル。 迅速に起動するために、JVMはクライアントJITコンパイラーで起動します。しばらくすると、コンパイラーはサーバーのコンパイラーに変更されます。
ええと、もちろん、すでに非常に多くの場合、筋肉のEscapeAnalysisとより効率的な配列のコピーがあります。
JRockitの利点
JRockitの前面では、信頼性と予測可能性を強調できます。 一貫したスレッド中断モデルを使用します。 強力なJITコンパイラ。 テスト用のAPIと一連の十分なテスト（HotSpotは私が知る限り非常に不足しています）。 サンプリングコンパイラ。
JRockitには、サポートとデバッグのための非常に強力なツールキットがあります。 JVMで発生したすべてを記録するいわゆる「フライトレコーダー」の存在と、異常な状況がいつ発生したかを理解するのに役立つデコードを区別できます。 現在の状態を監視するために、HotSpot用のVisual VMよりもはるかに強力に見えるMission Controlのようなツールがあります。 ネイティブメモリを追跡し、JITを微調整することもできます。 ポインタ圧縮モードでは、JRockitはすでに64GBに対応できます。 ガベージコレクターは、HotSpotよりも平均で30％少なくなります。
オラクルは現在、どのJVMを使用することを推奨していますか？
LinuxまたはWindowsでOracleスタックを使用している場合は、JRockitを使用することをお勧めします。 他のすべての場合-HotSpot。
どの機能が転送されますか？
オラクルは、新しい統合JVMでMission Controlを利用できるようにしたいと考えています。 PermGenをネイティブメモリ（Cヒープ）に変換します。 コピーせずにI / Oを作成します。特定の処理フェーズでGCオブジェクトの移動を禁止するメカニズムを実装する必要があります。 ガベージコレクタとコンパイラを管理するためのAPIを作成します。 断片化されたメモリを操作する機能を追加します。 ベアメタルで実行できるようにします。 そしてもちろん、休止の予測可能性の観点からのガベージコレクタの改善。
共同JVMの開発の見通し
オラクルは統合にとどまるつもりはありませんが、ある観点では、NUMAのさらなる発展としてNUMAが極端になっていることを期待できます。 さらに予測可能なG1。 1つのJVMで複数のアプリケーションを実行する機能と、効果的に対話するオプションの機能。 履歴データと予備編集に関する人間工学。 アイデアは、以前の起動時に収集されたデータと、アプリケーションの起動時にアプリケーションを使用することです。 また、JVMによって割り当てられたリソースが変更される可能性がある場合に、クラスター/クラウドでJVMを効率的に使用する可能性に取り組む予定です。 異種GPUプロセッサをサポートする可能性も検討されています。
結論として、スピーカーは標準スライドを示しました。このスライドでは、すべての内容は変更可能なオラクルの現在の計画であり、何も約束していません。 彼はまた、JVM開発戦略を担当するOracle従業員のブログへのリンクを推奨しました。