AOTとJITの違いはアンドロイド

Question

マシュマロでは、ARTにARTが追加されました。 Android Nから、別のコンパイラJITがAOTに加えて追加されました。

私の質問は、AOTコンパイラ固有のジョブ/機能とJITコンパイラのジョブ/機能とは何ですか。

Answer 1

コンパイラは、パフォーマンスコードを生成するために情報とリソースの2つのことが必要です。

JITコンパイラには、AOTコンパイラよりも多くの情報が用意されています。静的解析は一般的なケースでは不可能です（プログラムについて知りたいことはほとんどありませんが、Halting ProblemまたはRice's Receptionのいずれかに減らすことができます）。 JITコンパイラにはこの問題はありません。プログラムを静的に解析する必要はなく、実行時に動的に解析することができます。

さらに、JITコンパイラには、最適化されていない最も重要なものであるAOTコンパイラでは使用できない手法があります。さて、あなたはパフォーマンスのために重要ではないと思うかもしれません。さて、最適化を解除できれば、実際には無効な最適化を行うことで過度に攻撃的になることがあります（多態的であってもなくてもよいメソッド呼び出しをインライン展開するなど）、間違っていると判明した場合その後、非インライン化されたケースに逆最適化を戻します（たとえば）。

しかし、リソースの問題があります.AOTコンパイラは、必要なだけの時間をとり、必要なだけのメモリを使用できます。 JITコンパイラは、ユーザーが現在使用したいプログラムからリソースを奪う必要があります。

通常、問題はありません。今日のマシンは非常に馬鹿げて圧倒されているため、JITの処分には常に十分なリソースがあります。特に、JITは多くの新しいコードが一度にシステムに導入されると、ほとんどのリソースを使用するため、通常はプログラムの起動時やプログラムがフェーズ間で移行するときに使用されます（たとえば、構成ファイルの解析からオブジェクトグラフ、または設定を完了してから実際の作業を開始するまで）、通常はプログラム自体がその多くのリソースを使用していません（特にプログラムの起動時）。 Azul JCAは良い例です。最大の構成で864個のコアと768個のGiByte RAMを搭載しています（実際には数年前の技術であり、かなりの期間販売されていないことに注意してください）。 Azulの測定によれば、JITは非常に難しい作業をしているときに、おそらく50コアを使用します。これは、プログラム、システム、およびGCのために残っている800以上のコアです。

しかし、あなたの典型的なAndroidデバイスには1000コアとTiByte RAMがありません。また、ユーザは、WhatsAppを開始すると、今すぐメッセージを書きたいと思う非常にインタラクティブでレイテンシに敏感です。 JITがウォームアップしたときの500msecではありません。 NOW。

これがAOTを魅力的にする理由です。また、JITコンパイルでは実行中のプログラムからリソースを奪うだけでなく、バ​​ッテリ電源も必要になるため、プログラムが実行されるたびにAOTコンパイラがその電力予算を一度費やす必要があります。アプリがインストールされています。

アップルのようにコンパイルをアプリストアや開発者に押しつけることはできますが、アップルは考えられるターゲットプラットフォームのほうがずっと限られているという利点があります。デバイスのAOTコンパイルは、Androidにとって妥当なトレードオフのようです。

Answer 2

AndroidのJavaクラスはDEXバイトコードに変換されます。 DEXバイトコード形式は、ARTまたはDalvikランタイム経由でネイティブマシンコードに変換されます。

Dalvikは、JIT（Just in time）コンパイルベースのエンジンです。 Android 4.4（kitkat）からDalvikを使用するには、 という欠点がありました。ARTは で、Android 5.0（Lollipop）からは がDalvikに完全に置き換えられました。 Android 7.0では、コード実行時のJIT（Just-In-Time） コンパイラがAndroidランタイム（ART）に追加され、常に実行中のAndroidアプリのパフォーマンスが改善されます。

（ART一方のDalvikは時間だけでJITを（使用）コンパイルは、AOTを使用しています（事前に）コンパイル。）

ジャスト・タイム（JIT）：

のDalvik付きJITコンパイラは、アプリケーションが実行されるたびに、Dalvikバイトコードの一部を機械コードに動的に変換します。実行が進むにつれ、より多くのバイトコードがコンパイルされ、キャッシュされます。 JITはコードの一部のみをコンパイルするので、メモリフットプリントが小さくなり、デバイスの物理的なスペースが少なくなります。

事前（AOT）の：

ARTを控え-のタイムコンパイラが装備されています。アプリケーションのインストール段階では、DEXバイトコードを機械コードに静的に変換し、デバイスのストレージに保存します。これは、アプリケーションがデバイスにインストールされたときに発生するワンタイムイベントです。

アンドロイドNは、ハイブリッドランタイムが含まれています

解釈されるバイトコードがあり、インストール時に、コンパイルされませんし、アプリケーションがすぐに開始することができ、 。 ARTには新しい、より速い通訳があり、新しいJITが付いていますが、JIT情報は保持されません。 代わりに、実行中にコードがプロファイリングされ、結果のデータが保存されます。 ARTの

利点：

• アプリは、インストール中に行わDEXのバイトコード変換として高速に実行。
• ネイティブコードが直接実行されるため、アプリケーションの起動時間が短縮されます。
• 行ごとに解釈されるバイトコードに使用される電力が節約されるため、バッテリ性能が向上します。
• 改善されたガベージコレクタ。 ARTの

欠点：

• アプリケーションのインストールが原因DEXのより多くの時間がかかりますが、インストール時にマシンコードへの変換をバイトコード。

• インストール時に生成されたネイティブマシンコードが内部ストレージに格納されるため、より多くの内部ストレージが必要です。