新しいGC Epsilon。 Javaにはガベージコレクションがない場合があります。 ショック。 センセーション

こんにちは、紳士さん！ 最後の日が近づいていることをお知らせします。 Javaの世界は、Javaの代わりにRustを安全に、またはRustの代わりにJavaを安全に使用できる程度に進化したようです。 血まみれのディテールがあなたを待っています。



有名なインターネット活動家のアレクセイ・シピレフは最近、以下を投稿しました ：



「HotSpotにGCを実装せずに、すべての5秒レイテンシベンチマークを獲得してみませんか。 100 GBのヒープは10秒間存続するのに十分です。」



クールで素晴らしいジョーク-私たちは考えて食べに行きました。 そして、キッチンから戻った後、彼らはすぐにすべてのグッズを飲み込んだ。スクリーンショットがそこに現れたからだ！











まあ、私たちは皆、フォトショップの方法を知っていますよね？



そして

コードが登場

そして、物事は急激に変化し始めました。 シプリーフが何かを一般に公開すると、1か月後にはすでにインタビューでそれについて質問することになっています 。



震える指で、javanetを開くと、...

JEP：Epsilon GC：任意の低オーバーヘッドのガベージ（非）コレクター

次に、そこに書かれていることを簡単に繰り返します。 私は正確な翻訳をするのが面倒でした、文法の戦士は通過して元を読むことができます:)

なんてこった、バリモア？

この機能では、GCは新しいメモリの割り当てのみを考慮し、スマートガベージコレクション戦略をスコアリングできます。 使用可能なヒープが終了するとすぐに、JVM停止手順が開始されます。

目標

割り当て可能なメモリの量を制限して、完全にパッシブなGC実装を提供します。 その見返りとして、このようなGCのパフォーマンスで最も低いオーバーヘッドが得られます。 実装は、他のGCに影響を与えたり、JVMに大きな違いを生じさせたりするべきではありません。

やる気

ハブラーのトピックの作家の権利について、私は少し推測します。 実際、すべての企業がGoogleであるとは限りません。 誰かが最小限の実用的な製品を作りたいと思って、その開発の世話をするだけです。 おそらく将来的には、すべてをより高度なプラットフォームで書き直す必要があります。 おそらく開発者は早くお金を使い果たします。 これを行うには、G1のような巨大なプロジェクトをすぐにプロジェクトにドラッグする必要はありません。



さて、冗談はさておき、本文をさらに進めましょう！ Epsilonのようなものが実際に役立つ場合が少なくとも4つあると想定されています。



まず、Epsilonを使用すると、他のより高度なGCを比較できます。これは、アセンブリメカニズム自体によって導入されたバグの発見と検出に役立ちます。



第二に、真のBaytebo （これは呪いではなく用語です！）Javaアプリケーションの場合、このようなGCは単に置き換えられません。 次のティーポットまたはスマートトイレのファームウェアを書いていると想像してください。ガベージコレクションの実際はアプリケーションのバグと見なされます。ガベージコレクションの代わりに、フォールする方が賢明です。スマートバランサーは他のノード/ VMの負荷を不均衡にします バランスの取れたVMのネットワークを使用して、トイレは何を準備する必要がありますか？わかりやすくするために、トイレを置き換えます。 さらに、イプシロンを使用すると、不必要な障壁を取り除くことができます-ケーキのハイライトは完璧なパフォーマンスです。



第三に、OpenJDK自体をテストするために、このメモリの負荷不変量をテストするために、割り当てられたメモリを制限する手段があると便利です。 現在、このようなデータはMXBeanから取得されるか、GCログによって解析されます。 GCが限られた数の割り当てのみをサポートしている場合、これはOpenJDK開発者のテストを本当に簡単にします。 （ほとんどの場合、この記事の読者はOpenJDK開発者ではありませんが、次のインタビューでOpenJDKに合格することができます。）



第4に、これはVM-GCインターフェースの絶対最小値を確立するのに役立ち、その動作の正確さの証明として役立ちます。 たとえば、 JDK-8163329（「GCインターフェース」）の場合に有用なもの（参照により、テキストの壁、希望者はHabrに翻訳できます）。

詳細

ユーザーにとって、Epsilonは-XX：+ UnlockExperimentalVMOptions -XX：+ UseEpsilonGCを使用して接続された他のOpenJDK GCのように見えます。



Epsilonは、単一の連続したメモリに線形的にメモリを割り当てます。 これにより、VMの既存のコードを再利用できるロックフリーTLAB（スレッドローカルアロケーションバッファ）の最も単純なコードを使用できます。 TLABを発行すると、プロセスの常駐メモリを実際に割り当てられた量に維持できます。 この状況では、メモリとTLABの大きな部分の割り当てはそれほど変わらないため、同じコードで処理されます。



Epsilonは実際のアセンブリサイクルを行わないため、Epsilonで使用される一連のバリアは完全に空です。したがって、Epsilonはオブジェクトのグラフ、オブジェクトのマーキング、オブジェクトのコピー、その他すべての不要なジャンクについて気にしません。 筋金入り、パフォーマンスのみ！



ランタイムインターフェイスの唯一の重要な部分はEpsilonがTLABを発行する場所であるため、そのパフォーマンスは主にTLABのサイズに依存します。 任意の大きなTLABと任意の大きなヒープがあるため、パフォーマンスオーバーヘッドは任意の小さな正の数であるため、Epsilonという名前になります。 Golangの作成者とユーザーは、green望の的で緑色に変わり始め、一般的な髪を引きちぎることがあります。



ヒップが終了すると、TLABを発行することはできなくなり、何らかの方法で回復することは不可能になります。あきらめてエラーレポートを印刷するだけです。 ここでは、他のGCが行うことと同様のことができます。

• 重みのある説明でOutOfMemoryErrorをスローする
• 束をダンプします（いつものように、-XXでオンにします：+ HeapDumpOnOutOfMemoryError
• JVMをドロップし、オプションで何らかの外部アクション（通常、-XX：OnError = ...）を実行することは困難です。たとえば、デバッガーの起動、監視システムへの通知、または少なくともSportlotoへの手紙の書き込みなどです。

プロトタイプは軽負荷でテストされ、高負荷で落下する予定でした。

UFOがそれを拾うまで、コードはまだそこにあります ： http : //cr.openjdk.java.net/~shade/epsilon/

代替案

代替手段はありません。 少なくとも、すべての障壁が削減されました。 真剣に。



真にユニークなGCとの出会いから得られる喜びと幸福感が、Epsilonで使用されている薬物の幸福感と似ており、似たようなフィット感を生み出すことを願っています。



いずれにせよ、バリアに問題がない場合、シリアルまたはパラレル（古い）GCは同様のパフォーマンスプロファイルを提供できます-もちろん、ガベージコレクションが開始されないように構成できる場合（たとえば、巨大な若いgen値の設定、オフ適応ヒューリスティックなど）。 選択肢の数を考えると、機能することを保証するのは困難です。



Shenandoahなどの最新のGCをさらに改善すると、完全にノーオペレーションのGCに比べてオーバーヘッドが無視できるほど小さいレベルまで減少する可能性があります。 これが発生した場合でも、Epsilonを内部機能/ストレステストに使用できます（引退時に内部GCテストを実行したい場合）。

それも機能しますか？ まったく合法ですか？

従来のテストはnafigを必要とせず、Epsilonには適していません。 それらのほとんどは、あなたが任意の量のゴミを投げることができると信じています。 したがって、Epsilonをテストするには、新しいテストを実行する必要があります。メモリ割り当てが少ないタスクで動作することを確認する必要があります。ヒープが使い果たされると、とにかくではなく、予測どおりに低下します。 hotspot / gc / epsilonにある新しい十分なjtregテストの正確性を検証します。



Epsilonの開発中に実行される1回限りのチェックは、インタープリターC1およびC2のパフォーマンス特性を示唆するのに十分です。 開発の最初から現在の実装はより安定しており、スターリニストコンクリートバンカーを強化したため、さらにテストする必要はありません。

リスクと仮定

ユーティリティとサポートのコスト。 とにかく誰もそれを必要としないので、この実装はろうそくの価値がないと仮定することができます。 一方、経験に基づいて、多くのJavaエコシステムプレーヤーは、独自のカスタムJVMからGCを削除する実験を行いました。 したがって、既製のノーオペレーションGCがある場合、これはコミュニティのこの部分に役立ちます。 まあ、または少なくとも、まだ主流ではないときにノーオペレーションGCを使用したことを誇りに思うことができます。 実装の全体的な低コストを考えると、リスクは最小限です。



国民の期待。 このガベージコレクターが実際にガベージを収集しないことを考えると、誰かがこれを危険な慣行と考えるかもしれません。 本番環境でイプシロンを誤ってオンにすると、ヒープがオーバーフローした直後に、不快なニュースが表示されます。 著者は、機能が実験的フラグの下で実行されている間、つまり-XX：+ UnlockExperimentalVMOptionsが必要な間、実際のリスクはないと想定しています。



実装の複雑さ。 一般に、他のサブシステムでは、コードを当初の予想よりも変更する必要がある状況を想像できます。たとえば、コンパイラーや特定のプラットフォームのバックエンドなどです。 一方、プロトタイプは、最初からのそのようなすべての変更が厳密に分離されたことを示しています。 これが本当のリスクであることが判明した場合、上記のJDK-8163329（「GCインターフェース」）が役立ちます。

依存関係

外部コードの変更回数を減らすため、この作業はJDK-8163329（「GCインターフェイス」）に依存しています。 一般的なコードの変更が最小限であれば、GCインターフェイスを変更する必要はありません。

おわりに

正直なところ、私はこれをすべて書くのにとても疲れています。 ここに置いておいてください。 力があなたと共にありますように！ ガベージコレクションのないJavaで、新しい明るい未来に必要になります。



PS：Shipilevにはこの投稿へのリンクがあり、彼はあなたをフォローしています、ユーザー名