Loading article…
コンピューティングにおいて、ジャストインタイム( JIT )コンパイル(動的変換またはランタイムコンパイルとも呼ばれる) [1] は、プログラムの実行前ではなく実行時に (コンピュータコードを) コンパイルすることです。[ 2 ]これはソースコード変換で構成される場合もありますが、より一般的にはバイトコードからマシンコードへの変換であり、その後マシンコードが直接実行されます。 JIT コンパイラを実装するシステムは通常、実行中のコードを継続的に分析し、コンパイルまたは再コンパイルによって得られる速度向上がそのコードのコンパイルのオーバーヘッドを上回るコード部分を特定します。
JIT コンパイルは、機械語への変換に対する 2 つの従来のアプローチ、事前コンパイル (AOT)と解釈を組み合わせたもので、両方の利点と欠点を兼ね備えています。[2]大まかに言えば、JIT コンパイルは、コンパイルされたコードの速度と解釈の柔軟性、インタープリタのオーバーヘッド、コンパイルとリンク(解釈だけではない) の追加オーバーヘッドを組み合わせたものです。JIT コンパイルは動的コンパイルの一種で、動的再コンパイルやマイクロアーキテクチャ固有の高速化などの適応型最適化を可能にします。 [注 1] [3]解釈と JIT コンパイルは、ランタイム システムが遅延バインディングデータ型を処理し、セキュリティ保証を実施できる ため、動的プログラミング言語に特に適しています。
歴史
最も古い JIT コンパイラは、一般に1960 年のJohn McCarthyによるLISPの研究に帰せられます。 [4]彼の独創的な論文Recursive functions of symbolic expression and their computing by machine, Part Iでは、実行時に翻訳される関数について言及しており、これによりコンパイラの出力をパンチ カードに保存する必要がなくなりました[5] (ただし、これはより正確には「コンパイル アンド ゴー システム」と呼ばれます)。別の初期の例はKen Thompsonによるもので、1968 年にテキスト エディタQEDでのパターン マッチングで、正規表現の最初のアプリケーションの 1 つを示しました。[6] Thompson は速度を重視し、互換タイム シェアリング システム上のIBM 7094コードに JIT することで正規表現のマッチングを実装しました。[4]解釈からコンパイルされたコードを導き出す影響力のある手法は、1970 年にJames G. Mitchellによって開拓され、実験的な言語LC²に実装されました。[7] [8]
Smalltalk (1983年頃) は、JIT コンパイルの新しい側面を開拓しました。たとえば、マシン コードへの変換はオンデマンドで行われ、結果は後で使用するためにキャッシュされます。メモリが不足すると、システムはこのコードの一部を削除し、再び必要になったときに再生成します。[2] [9] Sun のSelf言語はこれらの手法を大幅に改善し、一時は世界最速の Smalltalk システムとなり、最適化された C [10]の半分の速度を達成しましたが、完全にオブジェクト指向の言語でした。
SunはSelfを放棄したが、研究はJava言語に引き継がれた。「ジャストインタイムコンパイル」という用語は、製造業の用語「ジャストインタイム」から借用され、Javaによって普及した。James Goslingは1993年からこの用語を使用している。 [11]現在、JITingはJava仮想マシンのほとんどの実装で使用されており、HotSpotはこの研究基盤に基づいて構築され、広範囲に使用されている。
HP プロジェクト Dynamo は、バイトコード形式とマシンコード形式が同じ実験的な JIT コンパイラであり、システムはPA-8000マシンコードを最適化しました。[12]直感に反して、これにより速度が向上し、場合によっては 30% 向上しました。これは、これによりマシンコードレベルでの最適化が可能になったためです。たとえば、キャッシュの使用率を向上させるためのコードのインライン化、動的ライブラリの呼び出しの最適化、従来のコンパイラでは実行できないその他の多くのランタイム最適化などです。[13] [14]
2020年11月、PHP 8.0でJITコンパイラが導入されました。[15] 2024年10月、CPythonで実験的なJITコンパイラが導入されました。[16]
デザイン
バイトコード コンパイル システムでは、ソース コードはバイトコードと呼ばれる中間表現に変換されます。バイトコードは特定のコンピュータのマシン コードではなく、コンピュータ アーキテクチャ間で移植可能です。バイトコードは 仮想マシン によって解釈されるか、仮想マシン上で実行されます。JIT コンパイラは、バイトコードを多数のセクション (まれに全体) で読み取り、マシン コードに動的にコンパイルして、プログラムの実行速度を向上させます。これは、ファイルごと、関数ごと、または任意のコード フラグメントごとに実行できます。コードは実行時にコンパイルされ (そのため、「ジャストインタイム」と呼ばれます)、キャッシュされて後で再コンパイルすることなく再利用できます。
対照的に、従来の解釈型仮想マシンは、バイトコードを解釈するだけで、一般にパフォーマンスははるかに低くなります。一部の解釈型仮想マシンは、最初にバイトコードにコンパイルするステップを踏まずにソースコードを解釈しますが、パフォーマンスはさらに低くなります。静的にコンパイルされたコードまたはネイティブ コードは、配置前にコンパイルされます。動的コンパイル環境は、実行中にコンパイラを使用できる環境です。JIT 技術を使用する一般的な目標は、バイトコード解釈の利点を維持しながら、静的コンパイルのパフォーマンスに到達するかそれを上回ることです。元のソース コードを解析して基本的な最適化を実行する「重労働」の多くは、多くの場合、配置前のコンパイル時に処理されます。バイトコードからマシン コードへのコンパイルは、ソースからコンパイルするよりもはるかに高速です。配置されたバイトコードは、ネイティブ コードとは異なり、移植可能です。解釈型バイトコードのようにランタイムがコンパイルを制御するため、安全なサンドボックスで実行できます。バイトコードからマシン コードへのコンパイラは、移植可能なバイトコード コンパイラがすでに多くの作業を行っているため、作成が簡単です。
JITコードは一般的にインタープリタよりもはるかに優れたパフォーマンスを提供します。さらに、多くの最適化が実行時にのみ実行可能なため、静的コンパイルよりも優れたパフォーマンスを提供する場合もあります。[17] [18]
- コンパイルは、アプリケーションが実行される対象の CPU とオペレーティング システム モデルに合わせて最適化できます。たとえば、JIT は、 CPU がSSE2ベクター CPU 命令をサポートしていることを検出すると、その命令を選択できます。静的コンパイラでこのレベルの最適化の特殊性を得るには、対象となるプラットフォーム/アーキテクチャごとにバイナリをコンパイルするか、または 1 つのバイナリ内にコードの部分の複数のバージョンを含める必要があります。
- システムは、プログラムが実際にその環境でどのように実行されているかに関する統計情報を収集し、最適なパフォーマンスが得られるように再配置および再コンパイルすることができます。ただし、一部の静的コンパイラは、プロファイル情報を入力として受け取ることもできます。
- システムは、動的リンクの利点を失うことなく、また静的コンパイラやリンカーに固有のオーバーヘッドなしに、グローバルなコード最適化 (ライブラリ関数のインライン化など) を実行できます。具体的には、グローバルなインライン置換を実行する場合、静的コンパイル プロセスで実行時チェックが必要になり、オブジェクトの実際のクラスがインライン化されたメソッドをオーバーライドした場合に仮想呼び出しが発生するようにする必要があります。また、配列アクセスの境界条件チェックをループ内で処理する必要がある場合があります。ジャストインタイム コンパイルでは、多くの場合、この処理をループ外に移動できるため、速度が大幅に向上します。
- これは静的にコンパイルされたガベージコレクション言語でも可能ですが、バイトコード システムでは、実行されたコードをより簡単に再配置して、キャッシュをより有効に活用できます。
JIT は実行時にネイティブ バイナリ イメージをレンダリングして実行する必要があるため、真のマシン コード JIT では実行時にデータを実行できるプラットフォームが必要となり、ハーバード アーキテクチャベースのマシンではこのような JIT の使用は不可能になります。同じことは、特定のオペレーティング システムや仮想マシンにも当てはまります。ただし、特殊なタイプの「JIT」は、物理マシンの CPU アーキテクチャではなく、生のマシン コードの制限が優先される最適化された VM バイトコードを対象としている可能性があります。特に、そのバイトコードの VM が最終的に JIT をネイティブ コードに活用する場合はそうです。[19]
パフォーマンス
JIT は、入力コードの読み込みとコンパイルに時間がかかるため、アプリケーションの初期実行時にわずかな遅延から顕著な遅延を引き起こします。この遅延は、「起動時間遅延」または「ウォームアップ時間」と呼ばれることもあります。一般に、JIT が実行する最適化が多ければ多いほど、生成されるコードは良くなりますが、初期遅延も増加します。したがって、JIT コンパイラは、コンパイル時間と生成するコードの品質の間でトレードオフを行う必要があります。起動時間には、JIT コンパイルに加えて、IO バウンド操作の増加が含まれる場合があります。たとえば、Java 仮想マシン(JVM) のrt.jarクラス データ ファイルは40 MB であり、JVM はこのコンテキスト的に巨大なファイル内で大量のデータを探す必要があります。[20]
Sun のHotSpot Java 仮想マシンで使用されている最適化の 1 つは、解釈と JIT コンパイルを組み合わせることです。アプリケーション コードは最初に解釈されますが、JVM はどのバイトコードシーケンスが頻繁に実行されるかを監視し、それらをハードウェア上で直接実行できるようにマシン コードに変換します。数回しか実行されないバイトコードの場合、これによりコンパイル時間が節約され、初期の待ち時間が短縮されます。頻繁に実行されるバイトコードの場合、最初の低速解釈フェーズの後、JIT コンパイルを使用して高速で実行されます。さらに、プログラムはほとんどの時間をコードの一部を実行するのに費やしているため、コンパイル時間の短縮は重要です。最後に、最初のコード解釈中に、コンパイル前に実行統計を収集できるため、より優れた最適化を実行できます。[21]
適切なトレードオフは状況によって変わる可能性があります。たとえば、Sun の Java 仮想マシンには、クライアントとサーバーの 2 つの主要モードがあります。クライアント モードでは、最小限のコンパイルと最適化が実行され、起動時間が短縮されます。サーバー モードでは、広範なコンパイルと最適化が実行され、起動時間を犠牲にしてアプリケーションの実行後にパフォーマンスが最大化されます。他の Java ジャストインタイム コンパイラは、メソッドの実行回数の実行時測定値とメソッドのバイトコード サイズを組み合わせて、コンパイルのタイミングを決定するヒューリスティックとして使用しています。[22] さらに別のコンパイラでは、実行回数とループの検出を組み合わせて使用しています。[23]一般に、短時間実行のアプリケーションでは、長時間実行のアプリケーションよりも、どのメソッドを最適化すべきかを正確に予測することははるかに困難です。[24]
MicrosoftのNative Image Generator (Ngen) は、初期遅延を減らすもう 1 つのアプローチです。[25] Ngen は、共通中間言語イメージのバイトコードをマシンのネイティブ コードに事前コンパイル (または「事前 JIT」) します。その結果、実行時のコンパイルは不要になります。Visual Studio 2005に同梱されている.NET Framework 2.0は、インストール直後にすべての Microsoft ライブラリ DLL で Ngen を実行します。事前 JIT により、起動時間を短縮できます。ただし、生成されるコードの品質は JIT されたコードほど良くない可能性があります。これは、プロファイル ガイド最適化を使用せずに静的にコンパイルされたコードが、極端な場合には JIT コンパイルされたコードほど良くならないのと同じ理由です。つまり、たとえばインライン キャッシュを駆動するためのプロファイリング データが不足しているのです。[26]
AOT (Ahead-of-Time) コンパイラと JIT コンパイラ ( Excelsior JET ) またはインタープリター ( GNU Compiler for Java ) を組み合わせた Java 実装も存在します。
JIT コンパイルは、短い初期ウォームアップ期間の後にパフォーマンスが向上した定常状態に入るという目標を、確実に達成できるとは限りません。[27] [28] Barrett ら (2017) は、8 つの異なる仮想マシンで、仮想マシン実装者が最適化ターゲットとして一般的に使用する 6 つの広く使用されているマイクロベンチマークを測定し、単一のプロセス実行内で繰り返し実行しました。[29] Linuxでは、プロセス実行の 8.7% ～ 9.6% がパフォーマンスの定常状態に到達できず、16.7% ～ 17.9% がウォームアップ期間後にパフォーマンスが低下した定常状態に入り、特定のベンチマークを実行している特定の仮想マシンの 56.5% の組み合わせが、複数の実行にわたってパフォーマンスの定常非低下を一貫して確認できませんでした (つまり、少なくとも 1 つの実行が定常状態に到達できなかったか、定常状態でパフォーマンスが低下しました) 。（2022）は、代わりにHotSpot仮想マシンに焦点を当てましたが、はるかに幅広いベンチマークを使用し、[31]プロセス実行の10.9％が安定したパフォーマンス状態に到達できず、ベンチマークの43.5％が複数の実行にわたって一貫して安定した状態に到達しなかったことを発見しました。[32]
安全
JIT コンパイルは基本的に実行可能データを使用するため、セキュリティ上の課題や悪用される可能性があります。
JIT コンパイルの実装は、ソース コードまたはバイト コードをマシン コードにコンパイルして実行することです。これは通常、メモリ内で直接行われます。JIT コンパイラは、通常の事前コンパイルのように、マシン コードをディスクに出力してから別のプログラムとしてコードを呼び出すのではなく、マシン コードを直接メモリに出力してすぐに実行します。最新のアーキテクチャでは、実行可能空間保護のために問題が発生します。任意のメモリは実行できません。そうしないと、潜在的なセキュリティ ホールになります。したがって、メモリは実行可能としてマークする必要があります。セキュリティ上の理由から、これはコードがメモリに書き込まれた後に実行され、読み取り専用としてマークされる必要があります。書き込み可能/実行可能なメモリはセキュリティ ホールです ( W^Xを参照)。[33]たとえば、Firefox の Javascript 用 JIT コンパイラは、Firefox 46 のリリース バージョンでこの保護を導入しました。[34]
JIT スプレーは、ヒープ スプレーに JIT コンパイルを使用するコンピューター セキュリティ エクスプロイトの一種です。結果のメモリは実行可能になり、実行をヒープに移動できる場合はエクスプロイトが可能になります。
用途
JIT コンパイルは一部のプログラムに適用できますが、特定の機能、特に正規表現などの動的な機能に使用することも可能です。たとえば、テキスト エディターでは、実行時に提供された正規表現をマシン コードにコンパイルして、マッチングを高速化できます。パターンは実行時にのみ提供されるため、これを事前に行うことはできません。最近のランタイム環境の多くは、高速コード実行のために JIT コンパイルに依存しており、これにはJavaのほとんどの実装やMicrosoftの.NETが含まれます。同様に、多くの正規表現ライブラリでは、バイトコードまたはマシン コードへの正規表現の JIT コンパイル機能を備えています。JIT コンパイルは、マシン コードをある CPU アーキテクチャから別の CPU アーキテクチャに変換するために、一部のエミュレーターでも使用されます。
JIT コンパイルの一般的な実装は、最初にバイトコード (仮想マシンコード)への AOT コンパイル (バイトコード コンパイル) を行い、次にバイトコードを解釈するのではなく、マシン コードへの JIT コンパイル (動的コンパイル) を行うことです。これにより、コンパイルによる遅延は発生しますが、解釈に比べて実行時のパフォーマンスが向上します。JIT コンパイラは、インタープリタと同様に継続的に変換しますが、コンパイルされたコードをキャッシュすることで、特定の実行中に同じコードを実行する際の遅延を最小限に抑えます。プログラムの一部のみがコンパイルされるため、実行前にプログラム全体をコンパイルする場合よりも遅延が大幅に少なくなります。
参照
注記
- ^ 事前コンパイラーは特定のマイクロアーキテクチャーもターゲットにできますが、その点における AOT と JIT の違いは移植性にあります。JIT は実行時に現在実行中の CPU に合わせてコードをレンダリングできますが、AOT は、一般化されたマイクロアーキテクチャーのサブセットを最適化する代わりに、ターゲット CPU を事前に知っておく必要があります。このようなコードは、他の CPU タイプではパフォーマンスが劣るだけでなく、まったく不安定になる可能性があります。
参考文献
- ^ 言語、コンパイラ、ランタイムシステム、ミシガン大学、コンピュータサイエンスおよびエンジニアリング、 2018年3月15日閲覧
- ^ abc エイコック2003年。
- ^ 「JIT は CPU を活用しますか?」David Notario の WebLog 。2018年 12 月 3 日閲覧。
- ^ ab Aycock 2003、2. JIT コンパイル手法、2.1 Genesis、p. 98。
- ^ McCarthy, J. (1960 年 4 月). 「記号式の再帰関数と機械による計算、パート I」. Communications of the ACM . 3 (4): 184–195. CiteSeerX 10.1.1.111.8833 . doi :10.1145/367177.367199. S2CID 1489409.
- ^ トンプソン 1968年。
- ^ Aycock 2003、2. JIT コンパイル手法、2.2 LC²、p. 98–99。
- ^ Mitchell, JG (1970). 「柔軟で効率的な対話型プログラミングシステムの設計と構築」
{{cite journal}}:ジャーナルを引用するには|journal=(ヘルプ)が必要です - ^ Deutsch, LP; Schiffman, AM (1984). 「Smalltalk-80 システムの効率的な実装」(PDF) 。第11 回 ACM SIGACT-SIGPLAN シンポジウム「プログラミング言語の原理 - POPL '84」の議事録。pp. 297–302。doi :10.1145/800017.800542。ISBN 0-89791-125-3. S2CID 3045432。2004年6月18日にオリジナル（PDF）からアーカイブ。
- ^ “97-pep.ps”. research.sun.com . 2006年11月24日時点のオリジナルよりアーカイブ。2022年1月15日閲覧。
- ^ Aycock 2003、2.14 Java、p.107、脚注13。
- ^ 「Dynamo: 透過的な動的最適化システム」。Vasanth Bala、Evelyn Duesterwald、Sanjeev Banerjia。PLDI '00 プログラミング言語の設計と実装に関する ACM SIGPLAN 2000 会議の議事録。1 ～ 12 ページ。DOI 10.1145/349299.349303。2012 年 3 月 28 日閲覧
- ^ John Jannotti. 「HPのDynamo」. Ars Technica . 2013年7月5日閲覧。
- ^ 「HP Dynamo プロジェクト」。2002 年 10 月 19 日時点のオリジナルよりアーカイブ。2016 年 4 月 12 日閲覧。
{{cite web}}: CS1 maint: unfit URL (link) - ^ Tung, Liam (2020年11月27日). 「プログラミング言語PHP 8がリリースされました。この新しいJITコンパイラーはパフォーマンスの向上を示しています」ZDNet。2020年11月28日閲覧。
- ^ 「What's New In Python 3.13」。Pythonドキュメント。2024年 11 月 27 日閲覧。
- ^ Croce, Louis. 「Just in Time Compilation」（PDF）。コロンビア大学。2018年5月3日時点のオリジナル（PDF）からアーカイブ。
- ^ 「JIT コンパイルと AOT コンパイルの利点は何ですか」 。Stack Overflow。2010年 1 月 21 日。
- ^ 「JIT ベースの言語を Webassembly にコンパイルする」。Stack Overflow。2018年 12 月 4 日閲覧。
- ^ Haase, Chet (2007 年 5 月)。「Consumer JRE: Leaner, Meaner Java Technology」。Sun Microsystems。2007年 7 月 27 日閲覧。
- ^ 「Java HotSpot パフォーマンス エンジン アーキテクチャ」。Oracle.com。2013年 7 月 5 日閲覧。
- ^ Schilling, Jonathan L. (2003 年 2 月). 「最も単純なヒューリスティックが Java JIT コンパイラーで最善である可能性がある」(PDF) . SIGPLAN Notices . 38 (2): 36–46. doi :10.1145/772970.772975. S2CID 15117148. 2015 年 9 月 24 日のオリジナル(PDF)からアーカイブ。
- ^ 菅沼敏夫、安江敏明、川人基博、小松秀明、中谷俊夫、「Java ジャストインタイムコンパイラのための動的最適化フレームワーク」、オブジェクト指向プログラミング、システム、言語、およびオブジェクト指向プログラミングに関する第 16 回 ACM SIGPLAN カンファレンスの議事録出願(OOPSLA '01)、180 ～ 195 ページ、2001 年 10 月 14 ～ 18 日。
- ^ Matthew Arnold、Michael Hind、Barbara G. Ryder、「選択的最適化の実証的研究」、並列コンピューティングのための言語とコンパイラに関する第 13 回国際ワークショップの議事録 - 改訂論文、pp. 49-67、2000 年 8 月 10 日～12 日。
- ^ 「ネイティブ イメージ ジェネレーター (Ngen.exe)」。 Msdn2.microsoft.com。 2006 年 12 月 5 日。2013 年 7 月 5 日に取得。
- ^ Sweeney, Arnold (2005 年2 月)。「仮想マシンにおける適応型最適化の調査」(PDF)。IEEEの議事録。92 (2): 449–466。2016年 6 月 29 日のオリジナル(PDF)からアーカイブ。
- ^ バレットら 2017年、3頁。
- ^ Traini et al. 2022、p.1。
- ^ バレットら2017年、5-6頁。
- ^ バレットら2017年、12-13頁。
- ^ トレイニら。 2022、p. 17-23。
- ^ トレイニら。 2022、p. 26-29。
- ^ 「JIT のやり方 – 入門」、Eli Bendersky、2013 年 11 月 5 日午前 5 時 59 分
- ^ De Mooij、1 月、「Firefox で有効になった W^X JIT コード」。ヤン・デ・モーイ。2016 年5 月 11 日に取得。
文献
- Barrett, Ed; Bolz-Tereick, Carl Friedrich; Killick, Rebecca; Mount, Sarah; Tratt, Laurence (2017 年 10 月 12 日)。「仮想マシンのウォームアップは熱くなったり冷たくなったりする」。ACMプログラミング言語に関する議事録。1 : 1–27。arXiv : 1602.00602。doi : 10.1145/3133876。S2CID 1036324。
- Traini, Luca; Cortellessa, Vittorio ; Di Pompeo, Daniele; Tucci, Michele (2022 年 9 月 30 日)。「Java ソフトウェアの定常状態パフォーマンスの効果的な評価に向けて: そこに到達したのか?」。経験的ソフトウェア エンジニアリング。28。arXiv : 2209.15369。doi : 10.1007 / s10664-022-10247 -x。S2CID 252668652 。
- Aycock, J. ( 2003 年 6 月)。「ジャストインタイムの簡単な歴史」。ACMコンピューティング調査。35 (2): 97–113。CiteSeerX 10.1.1.97.3985。doi : 10.1145 /857076.857077。S2CID 15345671 。
- Thompson, K. (1968). 「プログラミングテクニック: 正規表現検索アルゴリズム」Communications of the ACM . 11 (6): 419–422. doi : 10.1145/363347.363387 . S2CID 21260384.
外部リンク
- 無料のオンラインコンピュータ辞書
- Mozilla Nanojit Archived 2012-05-09 at the Wayback Machine : マシンコードを出力する、小さなクロスプラットフォームの C++ ライブラリ。Mozilla TamarinおよびSpiderMonkey Javascript エンジンの JIT として使用されます。
- VTune パフォーマンス アナライザーを使用したランタイム生成および解釈されたコードのプロファイリング