静的解析、イメージ初期化、ヒープスナップショットによるパフォーマンスの向上

モノリシック構造から分散システムの世界まで、アプリケーション開発は長い道のりを歩んできました。クラウド コンピューティングとマイクロサービス アーキテクチャの大規模な導入により、サーバー アプリケーションの作成方法と展開方法に対するアプローチが大きく変わりました。巨大なアプリケーション サーバーの代わりに、独立した個別にデプロイされたサービスがすぐに実行されるようになりました
必要に応じて。

ただし、このスムーズな機能に影響を与える可能性があるブロック上の新しいプレーヤーは、「コールド スタート」である可能性があります。 コールド スタートは、新しく生成されたワーカーで最初のリクエストが処理されるときに開始されます。この状況では、実際のリクエストを処理する前に、言語ランタイムの初期化とサービス構成の初期化が必要になります。コールド スタートに伴う予測不能性と実行速度の低下は、クラウド サービスのサービス レベル アグリーメントに違反する可能性があります。では、この増大する懸念にどう対処すればよいでしょうか?

ネイティブ イメージ: 起動時間とメモリ フットプリントの最適化

コールド スタートの非効率性に対処するために、ポイントツー分析、ビルド時のアプリケーション初期化、ヒープ スナップショット、および事前の (AOT) コンパイルを含む新しいアプローチが開発されました。このメソッドは閉じた世界の想定の下で動作し、すべての Java クラスが事前に決定されており、ビルド時にアクセスできる必要があります。このフェーズでは、包括的なポイントツー分析により、到達可能なすべてのプログラム要素 (クラス、メソッド、フィールド) が特定され、必須の Java メソッドのみがコンパイルされるようになります。

アプリケーションの初期化コードは、実行時ではなくビルドプロセス中に実行できます。これにより、Java オブジェクトの事前割り当てと複雑なデータ構造の構築が可能になり、実行時に「イメージ ヒープ」を介して利用できるようになります。このイメージ ヒープは実行可能ファイル内に統合されており、アプリケーションの起動時にすぐに使用できるようになります。
ポイントツー分析とスナップショットの反復実行は、安定した状態 (固定点) に達するまで継続され、起動時間とリソース消費の両方が最適化されます。

詳細なワークフロー

私たちのシステムへの入力は Java バイトコードであり、Java、Scala、Kotlin などの言語から生成される可能性があります。このプロセスでは、アプリケーション、そのライブラリ、JDK、および VM コンポーネントを均一に処理して、オペレーティング システムおよびアーキテクチャに固有のネイティブ実行可能ファイル (「ネイティブ イメージ」と呼ばれます) を生成します。構築プロセスには、固定点に到達するまでの反復的なポイントツー分析とヒープ スナップショットが含まれており、登録されたコールバックを通じてアプリケーションがアクティブに参加できるようになります。これらの手順は、総称してネイティブ イメージのビルド プロセスと呼ばれます (図 1)

図 1 – ネイティブイメージのビルドプロセス (出典: redhat.com)

ポイントツー分析

私たちはポイントツー分析を採用して、実行時のクラス、メソッド、フィールドの到達可能性を確認します。ポイントツー分析は、アプリケーションのメイン メソッドなどのすべてのエントリ ポイントから開始され、固定点に到達するまで推移的に到達可能なすべてのメソッドを反復的に走査します (図 2)。

図 2 – 分析のポイント

私たちのポイントツー分析は、コンパイラーのフロントエンドを利用して、Java バイトコードをコンパイラーの高レベル中間表現 (IR) に解析します。続いて、IR はタイプフロー グラフに変換されます。このグラフでは、ノードはオブジェクト タイプで動作する命令を表し、エッジはノード間の指定された使用エッジを示し、定義から使用法までを指します。各ノードは、ノードに到達できる型のリストと null 性情報で構成される型状態を維持します。型状態は使用エッジを通じて伝播します。ノードのタイプ状態が変更されると、この変更はすべての使用法に広められます。重要なのは、型状態は展開のみであるということです。新しいタイプをタイプ状態に追加することはできますが、既存のタイプが削除されることはありません。このメカニズムにより、
分析は最終的には固定点に収束し、終了につながります。

初期化コードの実行

ポイントツー分析は、ローカル固定点に到達したときの初期化コードの実行をガイドします。このコードは、クラス初期化子と、機能インターフェイスを介してビルド時に実行されるカスタム コード バッチという 2 つの別々のソースにその起源があります:

1. クラス初期化子: すべての Java クラスは、静的フィールドを初期化する メソッドで示されるクラス初期化子を持つことができます。開発者は、ビルド時と実行時にどのクラスを初期化するかを選択できます。

2. 明示的コールバック: 開発者は、システムが提供するフックを介してカスタム コードを実装し、分析段階の前、最中、または後に実行できます。

システムと統合するために提供される API は次のとおりです。

パッシブAPI（現在の解析ステータスを問い合わせ）

boolean isReachable(Class<?> clazz);

boolean isReachable(Field field);

boolean isReachable(Executable method);

詳細については、QueryReachabilityAccess を参照してください

アクティブ API (分析ステータス変更のコールバックを登録):

void registerReachabilityHandler(Consumer<DuringAnalysisAccess> callback, Object... elements);

void registerSubtypeReachabilityHandler(BiConsumer<DuringAnalysisAccess, Class<?>> callback, Class<?> baseClass);

void registerMethodOverrideReachabilityHandler(BiConsumer<DuringAnalysisAccess, Executable> callback, Executable baseMethod);

詳細については、BeforeAnalysisAccess を参照してください

このフェーズ中、アプリケーションはオブジェクトの割り当てやより大きなデータ構造の初期化などのカスタム コードを実行できます。重要なのは、初期化コードは現在のポイント先分析状態にアクセスでき、型、メソッド、またはフィールドの到達可能性に関するクエリを可能にすることです。これは、DuringAnalysisAccess によって提供されるさまざまな isReachable() メソッドを使用して実現されます。この情報を活用して、アプリケーションは、アプリケーションの到達可能なセグメントに最適化されたデータ構造を構築できます。

ヒープのスナップショット

最後に、ヒープ スナップショットは、静的フィールドなどのルート ポインターをたどることによってオブジェクト グラフを構築し、到達可能なすべてのオブジェクトの包括的なビューを構築します。次に、このグラフにはネイティブ イメージの
が設定されます。 イメージ ヒープを使用して、アプリケーションの初期状態が起動時に効率的に読み込まれるようにします。

到達可能なオブジェクトの推移的クロージャを生成するために、アルゴリズムはオブジェクト フィールドを走査し、リフレクションを使用して値を読み取ります。 Image Builder は Java 環境内で動作することに注意することが重要です。この走査では、ポイント先分析によって「読み取り」としてマークされたインスタンス フィールドのみが考慮されます。たとえば、クラスに 2 つのインスタンス フィールドがあり、そのうちの 1 つが読み取り済みとしてマークされていない場合、マークされていないフィールドから到達可能なオブジェクトはイメージ ヒープから除外されます。

ポイントトゥ分析によってクラスが以前に識別されていないフィールド値が見つかった場合、そのクラスはフィールド タイプとして登録されます。この登録により、その後のポイントトゥ分析の反復で、新しい型が型フロー グラフ内のすべてのフィールド読み取りおよび推移的な使用に伝播されることが保証されます。

以下のコード スニペットは、ヒープ スナップショットのコア アルゴリズムの概要を示しています。

Declare List worklist := []
Declare Set reachableObjects := []

Function BuildHeapSnapshot(PointsToState pointsToState)
For Each field in pointsToState.getReachableStaticObjectFields()
Call AddObjectToWorkList(field.readValue())
End For

    For Each method in pointsToState.getReachableMethods()
        For Each constant in method.embeddedConstants()
            Call AddObjectToWorkList(constant)
        End For
    End For

    While worklist.isNotEmpty
        Object current := Pop from worklist
        If current Object is an Array
            For Each value in current
                Call AddObjectToWorkList(value)
                Add current.getClass() to pointsToState.getObjectArrayTypes()
            End For
        Else
            For Each field in pointsToState.getReachableInstanceObjectFields(current.getClass())
                Object value := field.read(current)
                Call AddObjectToWorkList(value)
                Add value.getClass() to pointsToState.getFieldValueTypes(field)
            End For
        End If
    End While
    Return reachableObjects
End Function

要約すると、ヒープ スナップショット アルゴリズムは、到達可能なオブジェクトとそのフィールドを体系的に走査することにより、ヒープのスナップショットを効率的に構築します。これにより、関連するオブジェクトのみがイメージ ヒープに含まれるようになり、ネイティブ イメージのパフォーマンスとメモリ フットプリントが最適化されます。

結論

結論として、ヒープ スナップショットのプロセスはネイティブ イメージの作成において重要な役割を果たします。ヒープ スナップショット アルゴリズムは、到達可能なオブジェクトとそのフィールドを系統的に走査することにより、静的フィールドなどのルート ポインターから到達可能なオブジェクトの推移閉包を表すオブジェクト グラフを構築します。このオブジェクト グラフは、イメージ ヒープとしてネイティブ イメージに埋め込まれ、ネイティブ イメージの起動時の初期ヒープとして機能します。

プロセス全体を通じて、アルゴリズムはポイント分析の状態に基づいて、どのオブジェクトとフィールドがイメージ ヒープに含めるのに関連するかを決定します。ポイント先分析によって「読み取り」としてマークされたオブジェクトとフィールドが考慮されますが、マークされていないエンティティは除外されます。さらに、これまでに見たことのない型に遭遇すると、アルゴリズムはそれらを後続のポイント先分析の反復で伝播するために登録します。

全体的に、ヒープ スナップショットは、必要なオブジェクトのみがイメージ ヒープに含まれるようにすることで、ネイティブ イメージのパフォーマンスとメモリ使用量を最適化します。この体系的なアプローチにより、ネイティブ イメージの実行の効率と信頼性が向上します。

以上が静的解析、イメージ初期化、ヒープスナップショットによるパフォーマンスの向上の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。