アプリケーション仮想化ソフトウェアとは、アプリケーション仮想マシンと、それらを実装するソフトウェアの両方を指します。アプリケーション仮想マシンは通常、アプリケーションバイトコードをさまざまなコンピューター アーキテクチャやオペレーティング システムで移植可能に実行するために使用されます。アプリケーションは通常、インタープリターまたはジャストインタイム コンパイル(JIT) を使用してコンピューター上で実行されます。特定の仮想マシンには複数の実装が存在することが多く、それぞれが異なる機能セットをカバーしています。
仮想マシンの比較
- JavaScriptマシンは含まれていません。それらを見つけるには、 ECMAScript エンジンのリストを参照してください。
この表は、仮想マシン設計の効率化を意図した要素をまとめたものであり、実装に存在する機能のリストではありません。
仮想マシン命令は、主にスタック マシン、レジスタ マシン、またはメモリ マシンと呼ばれるランダム アクセス マシンなどの計算の主なモデルを使用して、ローカル変数内のデータを処理します。これらの 3 つの方法を使用する理由は、解釈、コンパイル、セキュリティの検証の容易さなど、仮想マシンと物理マシンのさまざまなトレードオフによるものです。
これらのポータブル仮想マシンのメモリ管理は、物理マシンよりも高い抽象レベルで対処されます。一般的なJava 仮想マシン(JVM) などの一部の仮想マシンは、仮想マシンがポインター参照をトレースできるようにすることで安全な自動メモリ管理を要求し、マシン命令がメモリへのポインターを手動で構築できないようにアドレスに関係しています。LLVM などの他の仮想マシンは、従来の物理マシンに似ており、ポインターを直接使用および操作できます。共通中間言語(CIL) は、その中間のハイブリッドを提供し、メモリの制御された使用 (安全な自動メモリ管理を可能にする JVM など) と、型の境界と権限に違反する可能性のある直接的なポインター操作を可能にする「安全でない」モードの両方を可能にします。
コード セキュリティとは、一般に、ポータブル仮想マシンが、規定された一連の機能のみを提供しながらコードを実行する能力を指します。たとえば、仮想マシンは、コードが特定の関数またはデータ セットにアクセスすることのみを許可する場合があります。自動メモリ管理を可能にし、仮想マシンがタイプセーフなデータ アクセスを保証できるようにするポインターに対する同じ制御は、コード フラグメントがメモリの特定の要素のみにアクセスでき、仮想マシン自体をバイパスできないようにするために使用されます。その他のセキュリティ メカニズムは、コード検証、スタック検証、およびその他の方法として、その上に重ねられます。
インタプリタを使用すると、仮想命令で作成されたプログラムを、ネイティブ マシン命令への潜在的にコストのかかるコンパイルなしで、すぐにロードして実行できます。実行可能な仮想マシンはすべてインタプリタ可能であるため、ここでの列の指定は、設計に効率的なインタプリタ (一般的な使用) の規定が含まれているかどうかを示します。
ジャストインタイム コンパイル(JIT) とは、通常はプログラムの実行直前または実行中に、できるだけ遅いタイミングでネイティブ命令にコンパイルする方法を指します。JIT の課題は、仮想マシンの設計というよりも実装に関するものですが、最近の設計では効率化を支援するための考慮が始められています。最も単純な JIT 方式では、オフライン コンパイラと同様に、コード フラグメントにコンパイルするだけです。ただし、コンパイルされたコード フラグメントを実行時にのみ認識されるパラメーターに特化する、より複雑な方式が採用されることがよくあります (「適応型最適化」を参照)。
事前コンパイル(AOT) とは、プリコンパイラを使用して、プログラムの実行中に変更されないネイティブ命令セットを生成する、より古典的な方法を指します。積極的なコンパイルと最適化には時間がかかるため、プリコンパイルされたプログラムは、実行に JIT のみを使用するプログラムよりも速く起動する場合があります。JVM 実装では、ネイティブ コード フラグメントが JIT によって生成されるまで、最初に解釈して起動時間を短縮することで、この起動コストを軽減しています。
共有ライブラリは、実行中の複数のプログラム間でネイティブ コードのセグメントを再利用する機能です。最近のオペレーティング システムでは、これは通常、仮想メモリを使用して、メモリ保護によって互いに保護されている異なるプロセス間で共有ライブラリを含むメモリ ページを共有することを意味します。興味深いことに、適応型最適化などの積極的な JIT 手法では、プロセス間やプログラムの連続実行間での共有に適さないコード フラグメントが生成されることが多く、プリコンパイルされた共有コードの効率と適応的に特化したコードの利点との間でトレードオフが必要になります。たとえば、CIL には効率的な共有ライブラリを可能にするための設計規定がいくつか存在しますが、その代償として、より特化した JIT コードが犠牲になる可能性があります。OS X上の JVM 実装では、共有ライブラリの利点の一部を提供するために Java Shared Archive [3]を使用しています。
アプリケーション仮想マシン実装の比較
上記のポータブル仮想マシンに加えて、仮想マシンは、通常はインタープリタによって、個々のスクリプト言語の実行モデルとして使用されることがよくあります。この表には、上記のポータブル仮想マシンとスクリプト言語仮想マシンの両方の特定の仮想マシン実装がリストされています。
参照
- アプリケーション仮想化
- 言語バインディング
- 外部関数インターフェース
- 呼び出し規約
- 名前のマングリング
- アプリケーション プログラミング インターフェイス(API)
- アプリケーションバイナリインターフェース(ABI)
- プラットフォーム仮想化ソフトウェアの比較
- ECMAScript エンジンのリスト
- Webアセンブリ
参考文献
- ^ 「Java Community Process(SM) プログラム - JSR: Java 仕様要求 - 詳細 JSR# 292」。Jcp.org。2013年 7 月 4 日閲覧。
- ^ 「JITRewrite – Parrot」。Trac.parrot.org 。 2013年7月4日閲覧。
- ^ OS X での Java 共有アーカイブの使用に関する Apple のドキュメント
- ^ LLVM コンパイラ インフラストラクチャ、Wayback Machineに 2012-07-31 にアーカイブ、ohloh.net、2011 年 11 月 30 日
- ^ Valgrind、ohloh.net、2011年11月30日。
