blame?原文はこちら。Imageが変換してくれます。生成される実行可能ファイルは素早く始動し、実行時のメモリ使用量も非常に少ないため、リソースの制約があったり高価だったりする場合、そして定期的にサービスをスケールアップ・ダウンするような環境にとって理想的です。これらのパフォーマンスの利点は、アプリケーションのコードを事前にコンパイルし、アプリケーションのいくつかのクラスを事前に初期化することで得られます。そのため、アプリケーションが起動したときには有用な作業を行う準備ができており、バイトコードの読み込み、解釈、JITコンパイラでのコンパイルなどをするためのインフラストラクチャを必要としません。Imageでビルドされた実行ファイルはスタンドアロンであり実行のためにJVMに依存しないということです。それはガベージコレクタのような必要なランタイムコンポーネントが同じバイナリに組み込まれているためです。事前に初期化されたヒープデータとアプリケーション全体のコンパイルされたコードが含まれているため、バイナリは通常、JARファイルよりも大きくなります。Dashboardを紹介します。これはWebベースの可視化ツールで、メソッドのコンパイル、到達性、クラスの使い勝手、プロファイリングデータ、事前初期化されたヒープデータ、静的解析結果などの情報を把握するのに役立ちます。言い換えれば、どのクラス、パッケージ、および事前初期化されたオブジェクトが実行ファイルに含まれているのか、特定のパッケージが占有するスペースはどのくらいか、どのクラスのオブジェクトがヒープの大部分を占めているのかを監視できます。これらのデータはすべて、アプリケーションを最適化してバイナリをさらに小さくする方法を理解するのに非常に役立ちます。UIダッシュボードのインターフェイスは簡単なものです。dataボタンがあり、Helpタブをクリックすると左側のメニューが開き、メイン・ウィンドウが表示されます。ダッシュボードには3つの可視化フォーマットがあり、以下で見ていきます。プリコンパイルされたパッケージとクラスのサイズを表示します。事前初期化されたヒープ上にどのオブジェクトがあるかを表示します。Dashboardは、ネイティブイメージビルダーによってダンプされたレポートファイルから、イメージの詳細を含むデータを可視化します。Format)」の拡張子(.bgv)のファイルしか受け付けていません。可視化のために取得したいデータタイプに応じて、ネイティブイメージを作成する際に特定のフラグを渡す必要があります。ダンプファイルのパスを定義します。利用可能なすべてのデータをダンプします。actionダッシュボードの適用性を実証するために、同期スレッドと非同期スレッドの実行を行うマルチスレッドのデモアプリケーションをサンプルとして使います。Dashboardhttps://github.com/graalvm/graalvm-demos/tree/master/multithreading-demoこのサンプル・アプリのビジネス・ロジックは単純で、あまり重要ではありません。それはいくつかのスレッドを起動し、すべてのスレッドがまったく同じ整数の配列をループし、疑似乱数のストリームを生成します。かかった時間を計算します。このデモは2個のサブプロジェクトで構成されており、それぞれMacenでビルドされています。Oversizedに取りかかります。全ての依存関係と共にソースを実行可能JARファイルにパッケージします。macOS)ベースでプロジェクトをテストしています。11ベースのGraalVMの場合大きな違いはありませんが少々異なる可能性があります。いえ、この記事の主要ポイントはそういった環境にも当てはまります。ビルダーhttps://www.graalvm.org/reference-manual/native-image/#install-native-imageアプリケーションをクローンしてビルドし、実行してください。実行するためにこの構成を使うと、ビルドによりdumpfileoversized.bgvが生成されます。Dashboardにアップロードしてプログラムの改善点を探すために使います。timeビルド後、multithreading-image-oversizedイメージを実行し、実行ファイルとJARファイルとのファイルサイズの差を比較できます。増加したことがわかります。これは、ネイティブイメージビルダが必要なすべてのランタイムパーツをパッケージ化し、ビルド中にいくつかのデータを事前初期化し、それを実行ファイルに書き出しているからです。ないので、起動時間はほとんどゼロになります。dumpfileoversized.bgvファイルは、診断データをすべての形式で収集するようにビルドを設定したため、29Mものファイルサイズになっています。Javaアプリケーションによってはダンプファイルのサイズが大きくなる可能性があり、その場合は診断情報を別途書くのは筋にかなっています。イメージヒープの内訳をダンプします。-メソッドごとのコードサイズの内訳をダンプします。ポイント間の分析情報をダンプします。デフォルトでは、ダンプをBGV形式で生成します。print形式でもダンプできますが、その場合はコマンドラインで明示的に指定する必要があります。ファイルを小さくするために、空白のないJSON形式でダンプします。人間が読めるJSON形式でダンプします。BGV形式でのダンプを行わず、ダンプを上記の両形式で生成します(コロンの後の”-“に注意してください)。Dashboardにロードして、ネイティブイメージに何が含まれ、全体的なサイズに何が寄与しているかを確認しましょう。Breakdownツールは、プリコンパイルされたコードが結局ネイティブイメージでどうなっているのか、どのJavaパッケージがそのサイズに最も関与しているのかを調べるためのツールです。このツールは、イメージに含まれていたパッケージ、クラス、メソッドの内訳を表示します。パッケージのサイズは、ネイティブイメージのサイズに比例します。その代わりに、ネイティブイメージの内部にどのようなコンテンツがパッケージ化されているかを知るには、-H:+PrintUniverseを実行して、テキスト出力を観察する必要があります。viewダッシュボードUIでパッケージの四角形をクリックすると、ダッシュボードが選択したパッケージグループに「ズームイン」するので、パッケージのサイズをさらに調べることができます。上図はmultithreading-image-oversizedのイメージを示しています。一見すると、画像の大部分がcom.fasterxmlというパッケージ(約3Mのサイズ)で構成されていることがわかります。何かを最適化しようとしているのであれば、最大のボトルネックから始めるのが理にかなっており、ダッシュボードの可視化はどこから始めるべきかを特定するのに非常に役立ちます。Breakdownを使用します。このツールは、ネイティブイメージのヒープに含まれる様々なクラスの事前割り当て済みオブジェクトのサイズを視覚的にまとめたものです。事前割り当て済みオブジェクトは、ネイティブ・イメージのビルド中に事前に割り当てられたオブジェクトで、実行ファイルのデータ・セクションに格納されます。実行時に直接メモリにロードされます。あるメソッドがなぜネイティブイメージに含まれたのか、そのメソッド呼び出しのシーケンス、そしてそのメソッドが将来的に含まれる可能性を避けるためにそれを中断できるかどうかを調べることができます。探索は、entry-pointに到達するまで再帰的にグラフを展開します。Breakdownヒストグラムのリーフタイルからのみアクセス可能です。DashboardはGitHub上のgraalvm.orgのウェブサイトと一緒にホストされており、すべての可視化ロジックはオフラインでクライアントサイドのHTMLページで行われます。ダンプファイルのサイズがブラウザで定義されたメモリ制限を超える場合、クライアントサイドの処理は少し問題になるかもしれません。Points-To分析は、特に大量のデータを生成する可能性があるため、興味のあるポイントがコードサイズの内訳である場合は、完全なデータダンプを読み込むのではなく、個々のコードサイズやヒープデータ診断データを使うとよいでしょう。Codeを使用していてPointTo-SourceLine拡張機能がインストールされている場合は、Points-to-Explorerから開いているワークスペースでソース行に素早く移動できます。ソース行情報を持つすべてのノードは、ファイルを開くようにプロンプトが出ます。data前章で、生成された実行ファイルの中でcom.fasterxmlパッケージが比較的大きなスペースを取ることを指摘しました。コードを微調整することで、イメージサイズを改善しましょう。パーサーを使用して、ユーザーの入力値の代わりに使用されるいくつかのデフォルト値の設定ファイルをロードしています。これらの設定値はデモの目的のためのもので、非常にシンプルに作られており、起動時にのみ使用されます。圧縮することができない場合は、アプリケーションのコードを変更して、より軽量な構造体を使用するか、設定用のプロパティファイルを使用するか、依存関係を削除するか、単純化するのが最善の方法でしょう。クラスを含めないようにする、というものです。Improvedには、変更済みのコードが入っています。ディレクトリを変更し、Mavenでビルドしましょう、数値が大きく変わりました。サイズも小さくなりました。この引数により、ネイティブイメージビルダーがイメージビルド時にすべてのクラスを初期化するように指示していたので、上記のパッケージは実行時に使用する必要がありません。これにより、実行ファイルの全体的なサイズが小さくなりました。最終的にこれらの定数がヒープ空間に直接ロードされると、リソースからconfig.jsonファイルを含める必要がなくなり、イメージサイズがさらに改善されます。native-imageでビルドされた実行ファイルにどのコードやどのデータがコンパイルされたかという情報を可視化するための興味深い選択肢です。サイズに寄与している最大のコンポーネントを迅速に特定し、最適化プロセスをガイドします。リリースとは別に、定期的に更新されています。ダッシュボードで何か問題が発生した場合や、未解決の質問がある場合は、SlackやGitHubで気軽に共有してください。Gupaloまで直接ご連絡ください。Dashboardは、GraalVMチームが最近内部で積極的に使用しており、その有用性を証明しています。お試しいただき、あなたのアプリケーションのためのインサイトを得て洞察を得てください。質問やフィードバックをお寄せください。コメントをキャンセルコメントを入力してください。以下に詳細を記入するか、アイコンをクリックしてログインしてください。アカウントを使ってコメントしています。アカウントを使ってコメントしています。新しいコメントがついたらメールで通知。Inside現在40人フォロワーがいます。購読管理このバーを折りたたむ%d人のブロガーが「いいね」をつけました。