Graal：実生活での新しいJVM JVMコンパイラの使用方法

ノボシビルスクで開催されたメインのシベリアJava会議JBreak-2018で 、 Twitterのクリスチャン・タリンジャーがGraalの使用に関する実際の経験を共有しました。 会社（Peter-Service）はワーキンググループ全体を会議に送り、全体としてこのレポートを聞くようになりました。 当然のことながら、Graalはまだ大胆で潜在的に危険な実験であると考えられています（ただし、JDK 10に入る可能性は非常に高いです）。 この斬新さが戦闘で現れることを知ることは非常に興味深いことでした-そしてどこでもではなく、そのようなレベルの発展において。







Christian Talingerは、10年以上にわたってJava仮想マシンを扱ってきました。彼の専門知識の重要なスキルは、JITコンパイラーだけです。 Graalを紹介し、Twitterのプロダクション環境で現在の（かなり活発なChrisによる）使用を開始したのはクリスチャンでした。 そして、タリンジャーによると、この革新は鉄資源を節約することで会社にかなりの金額を節約します。



JBreak主催者とのこのインタビューでは、Christianが基本を明快に説明しています。Graalとは何か、それを管理する方法です。 しかし、ノボシビルスクのレポートはより実践志向でした。その主なタスクは、観客にGraalとの作業を簡単かつ無痛に開始する方法と、それをやる価値がある理由を示すことでした。



そもそも-結局のところ、いくつかの理論的な紹介。 それでは、JITジャストインタイムコンパイラとは何ですか？ Javaプログラムを実行するには、いくつかの手順を実行する必要があります。まず、JVMの命令でソースコード-バイトコードをコンパイルし、次にこのバイトコードをJVMで実行します。 ここで、JVMはインタープリターとして機能します。 JITコンパイラは、Javaアプリケーションの作業を高速化するために作成されました。プログラム実行のプロセスでバイトコードを低レベルのマシン命令に変換することにより、起動するバイトコードの最適化に取り組んでいます。



HotSpot / OpenJDKは、C ++で実装された2レベルのJITコンパイルを使用します。 これらはC1およびC2（クライアントおよびサーバーとも呼ばれます）です。 デフォルトでは、これらは連携して動作します。最初に、C1を使用して表面的で迅速な最適化が実行され、次にC2を使用して最もホットなメソッドがさらに最適化されます。



Java 9では、 JEP-243はJavaコンパイラをJVMに埋め込むためのメカニズムを実装しました。 そして、これは動的コンパイラー-JVMCI（Java Virtual Machine Compiler Interface）です。 実際、このメカニズムはGraalをサポートしています。 Java 9 Graalは、 JEP-295 -JVMでのAOTコンパイル（Ahead-of-time）の一部としてすでに利用可能であったことを言わなければなりません。 確かに、AOTコンパイルメカニズムはGraalをコンパイラとして使用しますが、このJEPでは、JDKへのGraalコードの最初の統合はLinux / x64プラットフォーム内でのみ想定されていると述べています。



したがって、Graalを試すには、ADKとJMVCIでJDKを使用する必要があります。 さらに、MacOSまたはWindowsプラットフォームで実行する必要がある場合は、Java 10のリリースを待つ必要があります（対応するチケットではJDK-8172670修正バージョンがトップ10に入れられます）。







ここで、Christianは、現在のJDKディストリビューションではGraalのバージョンが控えめに言っても時代遅れであるという事実（1年前またはそれより若い）にリスナーの注意を向けました。 しかしここでは、Java 9のモジュール性が役立ちます。おかげで、Graalソースから最新バージョンを収集し、コマンド--upgrade-module-pathを使用してJVMに埋め込むことができます。 Graalの開発はモジュールシステムよりもずっと前に開始されたため、特別なツールを使用してそれを構築します。mxは、モジュールJavaシステムをある程度繰り返します。 このツールはPython 2.7で実行され、すべてのリンクはGitHubのGraalリポジトリにあります 。

つまり、まずmxをデフレートしてインストールし、次にGraalをデフレートし、mxを介してモジュールにアセンブルします。これにより、JDKの元のモジュールが置き換えられます。



一見、これらの操作は複雑で時間がかかるように見えるかもしれませんが、実際にはこの特性はそれほどひどいものではありません。 そして、原則として、JDKまたは新しいJDKでパッチがリリースされるのを待たずにGraalバージョンを置き換える機能は、個人的には便利なようです。 少なくともクリスチャンは、彼自身がクラウドのマシンでこれらすべてをライブで収集する方法を示しました。 True、Truffleのアセンブル中にエラーが発生しました-マシンにいくつかの追加の依存関係をインストールする必要がありました。 しかし、Graalは正しく組み立てられて、この形式で使用されました（ここから、Truffleについて完全に忘れることができると結論付けられます：Graalは完全に独立しています）。



次に：JVMがGraalの使用を開始するには、さらに3つのフラグを設定する必要があります。

-XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler -XX:-EnableJVMCI
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Graalは基本的に通常のJavaアプリケーションであるため、作業用にコンパイルして準備する必要があります（いわゆるブートストラップ）。 「オンデマンド」モードでは、これはアプリケーションの起動と並行して発生します。この場合、GraalはC1を使用してコードを最適化します。



アプリケーションを開始する前に明示的に初期化を開始するオプションもあります。このシナリオでは、Graalに自身を最適化するように指示することもできます。 ただし、これには通常、はるかに時間がかかり、大きな利点はありません。 grailはC1 / C2より少し長く初期化され、より多くのクラスをコンパイルする必要があるため、より積極的に空きプロセッサパワーを使用します。 しかし、これらの違いはそれほど大きくなく、実質的に平準化され、アプリケーションの初期化中に一般的なノイズで失われます。

さらに、GraalはJavaで記述されているため、ヒープを使用して初期化します（C1 / C2の場合、mallocを介してのみメモリも使用されます）。 メインメモリの消費量は、アプリケーションの開始時です。 GraalとC1 / C2は両方とも、コンパイル時に無料のカーネルを使用します。 Grailのメモリ消費は、GCログを有効にすることで監視できます（現在、アプリケーションのメインヒップからGraalを初期化するヒップの分離はありません）。



さて、私たちはそれをすべて設定する方法を学びました-今こそその理由を理解する時です。 Graalを使用する利点は何ですか？



クリスチャンは実用的な例を使用してこの質問に答えました。 彼はScalaで書かれた1つのプロジェクトからいくつかのベンチマークを開始しました。1つはCPUを積極的に使用しており、もう1つはより積極的にメモリを操作していました。 CPUで動作するベンチマークでは、Graalを使用していると、開始時間が長くなったために平均して1秒間顕著な低下が見られました（ベンチマーク自体が完了するまでに5秒かかりました）。 しかし、2番目のベンチマークでは、Graalは非常に良い結果を示しました-C1 / C2の〜28に対して〜20秒。 そして、これは、Christianが指摘したように、Scala Graalを使用した例は（Scalaによって生成されたバイトコードの動的構造のため）うまく機能していません。 つまり、純粋なJavaアプリケーションの場合、すべてがさらに改善されることを期待できます。



さらに、GCログを表示するとき、Graalを使用すると、アプリケーションが生成するガベージコレクションがはるかに少ない（約2倍）ことは明らかでした。 これは、ヒープ上に作成されるオブジェクトの数を最適化できる、より効率的なエスケープ分析によるものです。







私が聞いたことに対する個人的な印象を要約すると、このレポートは私にとって非常に包括的なものであり、「緊急にGraalに行く」という精神で広告メッセージを一切伝えなかったと言えます。 魔法の薬がなく、すべてが常に実際のアプリケーションによって決定されることは明らかです。クリスチャン自身は、特定の値はもちろん特定のベンチマークに依存することを認めています。 いずれにせよ、Grailを試すことにした人は、科学的な突く方法を使用し、実行して（おそらく）バグを見つける必要があります（さらに編集してからGraalリポジトリのプルリクエストに記入する方が良いでしょう）。



しかし、全体的に、マイクロサービスとステートレスアプリケーションの使用に向かう現在の傾向、そしてその結果、Young Genのよりアクティブな（そして正しい）アプリケーションに向かう傾向により、Graalは非常に良さそうです。



そのため、プロジェクトをわずかな血でJava 9に翻訳できる（またはゼロから作成する）場合は、間違いなくGraalを試してみます。 そして、例えば、レポートの重点が特にJITコンパイラーとしてのGraalに重点を置いていることさえ嬉しかったです。一般に、普通のJava開発者はそれをその品質で（つまり、Truffelなどなしで）必要とするからですGraalVM。Oracleが最近、JVMに基づいたさまざまな言語の開発およびランタイム用のフレームワークに統合しました。 メモリコストをテストし、標準のC1 / C2とGraalの違いがどれほど顕著かを確認するのは興味深いでしょう。 一方、最近ではかなりの量のメモリがアプリケーションに割り当てられており、その主な量は起動時に消費されますが（今日は通常、アプリケーション自体を既に起動しているのは通常コンテナの初期化と開始です）、これらの数値は明らかに、いずれの場合でもそれほど重要ではありません。



ここから、レポートからプレゼンテーションをダウンロードできます。



実のところ、私は個人的に非常に興味を持ったので、Christianが行ったすべてのステップを繰り返すつもりですが、Javaベンチマークスイートを直接実行しようとします（たとえば、DaCapoとSPECjvm2008-私はJavaベンチマークがあまり得意ではないので、感謝します）誰かがコメントまたは馬力でより適切なオプションを提案します）。 さて、作業の詳細に近い-単純なWebアプリケーション（たとえば、SpringBoot + Jetty + PostgreSQL）をスケッチし、負荷がかかった状態でドライブして、数値を比較してみます。 結果をコミュニティと共有することを約束します。