technology原文はこちら。IBM).https://blog.openj9.org/2020/01/09/free-your-jvm-from-the-jit-with-jitserver-technology/最先端のJava仮想マシン(JVM)は、Javaアプリケーションのスループットを向上させるために、ジャストインタイム(JIT)コンパイラを採用しています。JITコンパイラはコストがかかります。CPUとメモリの面でリソースを消費するため、Javaアプリケーションの円滑な実行を妨げる可能性があります。動的コンパイルの利点をすべて維持し、その欠点を取り除くことができればいいと思いませんか?これこそがまさにJITServerテクノロジーが提案していることです。JVMでは、JITコンパイラをJVMから切り離し、それをローカルかリモート・マシン上で独立したプロセスで実行するようにしました。Swarmのような既製のオーケストレーターでインテリジェントに管理できます。around?見かけ上、JITServerはコンパイルのオーバーヘッドをある場所から別の場所に移動させますが、そのようなコンパイル統合戦略で以下のような利点を得ることができます。クライアントJVMでのコンパイルによるメモリ消費の急増が解消され、メモリ不足が発生する可能性が減ります。JITコンパイラがJavaアプリケーションからCPUサイクルを盗まないため、パフォーマンスの不調を解消し、サービス品質(QoS)を向上させ、より高速なスタートアップ/ランプアップ・エクスペリエンスにつながる可能性があります。ユーザーはJITコンパイルの予測不可能な影響を無視でき、JavaアプリケーションのCPU/メモリ・ニーズだけに集中できるため、アプリケーション・リソースのプロビジョニングが大幅に簡素化されます。コンテナのサイジングは、Javaアプリケーションのリソース使用量のみに基づいて行うことができ、結果として、より小さなコンテナ、増加したアプリケーション密度、および全体的なコストの削減につながります。JITのバグによるコンパイル時のクラッシュでJVMがダウンすることがなくなるため、アプリケーションの堅牢性が向上します。JITServerのコンテナインスタンスの数(およびそのサイズ)は、Javaアプリケーションとは独立してスケールアップ・ダウン(訳注:本来ならスケールアウト・インですが、原文に従って訳しています)増減できるため、コンパイルに費やされるリソースのコントロールの幅が広がります。1台のJITServerで数十台(数百台ではないにしても)のJVMのコンパイルニーズを満たすことができる点は言及すべきポイントです。N個のクライアントJVMからのリクエストが時間の経過とともにずれる典型的な使用パターンでは、サーバでのメモリ消費量はN倍に増加することはありません。catch?お察しの通り、全てがよい、というわけではありません。デメリットについては明言しておきたいと思います。このテクノロジーの最大の課題は、ネットワーク・レイテンシです。完璧な世界では、クライアントJVMがコンパイルリクエストを発行し、JITServerがコンパイルされたメソッド本体を返します。実際には、コンパイルプロセスの間、JITServerはクライアントに多くのクエリを送信し、実行時の環境(クラス、メソッド、フィールド、プロファイリング情報、クラス階層など)について問い合わせています。JITServerは、前後のネットワーク通信を減らすために積極的なキャッシングを採用していますが、要求された情報は実行時に変更される可能性があるため、キャッシングは部分的にしか有効ではありません。そのため、一方ではネットワークのレイテンシによりコンパイルに時間がかかっていますが、他方ではJVMがJITのコンパイルにCPUサイクルやメモリを使わなくなっています。これらは拮抗する効果であり、最終的な結果は環境に依存します。アプリケーションがコンパイルの必要性と比較して、自由に使えるCPUとメモリのリソースが十分にある場合は、JITコンパイラを内蔵した従来のJVMの方がまだ良いでしょう。逆に、CPUとメモリに制約のある環境で多くのメソッドをコンパイルする必要がある場合は、JITServerテクノロジーをぜひ試してみてください。itこの記事を書いている時点では、JITServerテクノロジーはプレビューとして提供されており、x86-64上のLinux上のJava8/11でサポートされています(ZとPowerシステム上のLinuxのサポートは近日中に予定されています!)。我々は以下のLinuxディストリビューションで機能をテストしています。他の最新のLinuxディストリビューションでも同じように動作することを期待しています。7.6JITServerテクノロジーを使ってJDKを構築したい方のために、このブログの付録Aに詳細な手順を記載しました。(https://adoptopenjdk.net/)から入手可能なOpenJ9のビルドには、JITServerテクノロジーが組み込まれています。したがって、適切なコマンドラインオプションを使用するだけで、3つの異なるペルソナを切り替えることができます。AdoptOpenJDKhttps://adoptopenjdk.net/OpenJ9を通常のJVMとして起動するためのであれば、何も特別なことをする必要はありません。通常通りJavaコマンドを使用してください。サーバが利用できない場合、クライアントは素のJVMで動作することに注意してください。コマンドを使用します。水面下では、着信するコンパイルリクエストをリッスンするJVMを起動します。以下のコマンドラインオプションを使ってさらにJITServerやクライアントJVMプロセスを構成できます。ソケット操作のタイムアウト値(ミリ秒単位)を指定デフォルト値は、JITServerで30000ms、クライアントJVMで2000msネットワークレイテンシが大きい場合、クライアントJVMの設定値を増やす必要がある。encryption?その通りですね。1.0.xまたは1.1.xを使用して暗号化できます。暗号化を有効化するには、サーバーで秘密鍵と証明書を指定してください。-XX:JITServerSSLCert=cert.pemそして、クライアントで証明書を使います。キーと自己署名証明書を生成するには以下のようにしてください。CN)は、証明書を使用するホストのFQDNである必要があります(クライアントと同じマシン上でサーバーを実行する予定であれば、CNはlocalhostでなければなりません)。オーバーヘッドが発生し、コンパイルのレイテンシが増加することに注意してください。したがって、これを使用しないことができるかどうかを検討してください。クライアントとサーバーの間で交換される情報は、Javaクラス(バイトコード、クラス/メソッド/フィールド名、クラス階層)とプロファイリング情報に限定され、Javaヒープに保存されるユーザーデータは一切含まれないことを知っておくと便利です(静的なfinalフィールドは例外です)。サーバーで暗号化を有効にした場合、JITServerは暗号化されたリクエストのみを受け入れます。別のインスタンスを起動する必要があります。テクノロジープレビューは、JITコンパイルの負の影響からの救済をもたらします。ネットワークレイテンシが合理的である限り、このテクノロジーは、リソースに制約のある環境で実行されている多くのクラス/メソッドを持つJavaアプリケーションにとって非常に有用であることを証明するでしょう。したがって、これはコンテナサイズを縮小し、アプリケーションの密度を向上させ、全体的なコストを削減する効果的な方法になるでしょう。このテクノロジーの性能評価は、近日中に後続のブログで行う予定です。7.3以上が必要です)。オプションを付けることを除き、ビルドプロセスは素のOpenJ9のビルドプロセスと同じです。コメントをキャンセルコメントを入力してください。以下に詳細を記入するか、アイコンをクリックしてログインしてください。アカウントを使ってコメントしています。アカウントを使ってコメントしています。新しいコメントがついたらメールで通知。Inside現在40人フォロワーがいます。購読管理このバーを折りたたむ%d人のブロガーが「いいね」をつけました。