Java仮想マシン

Java仮想マシン( JVM ) は、コンピュータがJavaプログラムだけでなく、Java バイトコードにコンパイルされる他の言語で書かれたプログラムも実行できるようにする仮想マシンです。JVM は、 JVM 実装に何が必要かを正式に記述した仕様によって詳細化されています。仕様があることで、異なる実装間での Java プログラムの相互運用性が保証されるため、 Java 開発キット(JDK)を使用するプログラム作成者は、基盤となるハードウェア プラットフォームの特異性を心配する必要がありません。

JVMリファレンス実装は、 OpenJDKプロジェクトによってオープン ソースコードとして開発されており、 HotSpotと呼ばれるJIT コンパイラが含まれています。Oracle から入手できる商用サポート付き Java リリースは、OpenJDKランタイムに基づいています。Eclipse OpenJ9 は、OpenJDK 用の別のオープン ソース JVM です。

Java 仮想マシンは、仕様によって定義された抽象 (仮想) コンピュータです。Java ランタイム環境の一部です。使用されるガベージ コレクションアルゴリズムと Java 仮想マシン命令の内部最適化 (マシン コードへの変換) は指定されていません。この省略の主な理由は、実装者に不必要な制約を与えないようにするためです。Java アプリケーションは、Java 仮想マシンの抽象仕様の具体的な実装内でのみ実行できます。^[2]

Java Platform, Standard Edition (J2SE) 5.0以降、JVM 仕様の変更はJava Community Processの下でJSR 924 として開発されてきました^。[3] 2006 年現在、クラス ファイル形式(JSR 202) ^{[4][アップデート]}に提案された変更をサポートするための仕様変更が、JSR 924 のメンテナンス リリースとして行われています。JVM の仕様はブルー ブック^[5]として公開されており、その序文には次のように書かれています。

この仕様では、Java 仮想マシンを十分に文書化して、互換性のあるクリーンルーム実装を可能にすることを目的としています。Oracle は、Java 仮想マシンの実装が適切に動作することを確認するテストを提供しています。

Oracle の JVM の 1 つは HotSpot という名前で、もう 1 つはBEA Systemsから継承されたJRockitです。Oracle は Java 商標を所有しており、実装スイートが Oracle の仕様と完全に互換性があることを証明するためにその使用を許可する場合があります。

JVM バイトコードの編成単位の 1 つはクラスです。クラス ローダーの実装は、Java クラスファイル形式に準拠するものを認識してロードできる必要があります。実装はクラスファイル以外のバイナリ形式を自由に認識できますが、クラスファイルを認識する必要があります。

クラス ローダーは、次の 3 つの基本的なアクティビティを厳密な順序で実行します。

1. 読み込み: 型のバイナリデータを検索してインポートします
2. リンク: 検証、準備、および（オプションで）解決を実行します
   • 検証: インポートされた型の正確性を確認します
   • 準備: クラス変数にメモリを割り当て、メモリをデフォルト値に初期化する
   • 解決: 型からのシンボリック参照を直接参照に変換します。
3. 初期化: クラス変数を適切な開始値に初期化する Java コードを呼び出します。

一般に、クラス ローダーには、ブートストラップ クラス ローダー、拡張クラス ローダー、システム/アプリケーション クラス ローダーの 3 種類があります。

すべての Java 仮想マシン実装には、信頼できるクラスをロードできるブートストラップ クラス ローダー、および拡張クラス ローダーまたはアプリケーション クラス ローダーが必要です。Java 仮想マシン仕様では、クラス ローダーがクラスを検索する方法は指定されていません。

JVM は、Java 仮想マシン仕様で指定されている特定のデータ型を操作します。データ型は、プリミティブ型 (整数、浮動小数点、long など) と参照型に分類できます^[6]。初期の JVM は32 ビットマシンのみでした。64ビットのおよび型はネイティブでサポートされていますが、各ユニットが 32 ビットであるため、フレームのローカル変数またはオペランドスタックで 2 ユニットのストレージを消費します。、、、および型はすべて符号拡張され(はゼロ拡張)、 型と同様に 32 ビット整数として操作されます。より小さな型には、ロード、格納、および型変換用の型固有の命令がいくつかあるだけです。は 8 ビット値として操作され、 0 は を表し、 1 は​​ を表します。 ( Java 仮想マシン仕様第 2 版でこの問題が明確化されて以来、 は型として扱われていますが、コンパイルされて実行されるコードでは、メソッド シグネチャ内の名前マングルとブール配列の型を除いて、との間にほとんど違いはありません。メソッド シグネチャ内の は としてマングルされ、は としてマングルされます。ブール配列は 型を持ちますが、要素ごとに 8 ビットを使用し、JVM にはブール値を16 ビット配列にパックする組み込み機能がないため、 型を除いて配列と同じように機能し、動作します。その他のすべての用途では、ブール値を操作するすべての命令が を操作するためにも使用されるため、 型は事実上 JVM にとって不明です。) ただし、新しい JVM リリース (OpenJDK HotSpot JVM) は 64 ビットをサポートしているため、64 ビット OS で 32 ビット/64 ビットの JVM を使用できます。Java を 64 ビット環境で実行する主な利点は、アドレス空間が広いことです。これにより、特定の種類の大規模アプリケーションに必要な、はるかに大きな Java ヒープ サイズと Java スレッドの最大数の増加が可能になります。ただし、32 ビット JVM と比較して、64 ビット JVM を使用するとパフォーマンスが低下します。 longdoublebooleanbyteshortcharcharintbooleanbytefalsetruebooleanbooleanbytebooleanZbyteBboolean[]bytebooleanbyte

JVM には、オブジェクトと配列を保存するためのガベージ コレクション ヒープがあります。コード、定数、およびその他のクラス データは、「メソッド領域」に保存されます。メソッド領域は論理的にはヒープの一部ですが、実装ではメソッド領域をヒープとは別に扱う場合があり、たとえばガベージ コレクションを行わない場合があります。各 JVM スレッドには、フレームを保存する独自の呼び出しスタック(わかりやすくするために「Java 仮想マシン スタック」と呼びます)もあります。メソッドが呼び出されるたびに新しいフレームが作成され、そのメソッドが終了するとフレームが破棄されます。

各フレームは、「オペランド スタック」と「ローカル変数」の配列を提供します。オペランド スタックは、オペランドが計算を実行し、呼び出されたメソッドの戻り値を受け取るために使用されます。一方、ローカル変数はレジスタと同じ目的を果たし、メソッドの引数を渡すためにも使用されます。したがって、JVM はスタック マシンとレジスタ マシンの両方です。実際には、HotSpot は、解釈モードで実行されている場合でも、ネイティブ スレッド/呼び出しスタック以外のすべてのスタックを削除します。これは、テンプレート インタープリタが技術的にコンパイラとして機能するためです。

JVM には、次のタスク グループに関する 命令があります。

目的はバイナリ互換性です。各ホストオペレーティング システムには、 JVM とランタイムの独自の実装が必要です。これらの JVM はバイトコードを意味的に同じ方法で解釈しますが、実際の実装は異なる場合があります。バイトコードをエミュレートするよりも複雑なのは、各ホスト オペレーティング システムにマップする必要があるJava コア API を互換性を保ちながら効率的に実装することです。

これらの命令は共通の特定の命令セットアーキテクチャのネイティブ データ型ではなく、抽象化されたデータ型です。

JVM言語とは、Java仮想マシンでホストできる有効なクラスファイルで表現できる機能を持つ言語です。クラスファイルには、Java仮想マシン命令（Javaバイトコード）とシンボルテーブル、およびその他の補助情報が含まれています。クラスファイル形式は、コンパイルされたクラスとインターフェースを表すために使用される、ハードウェアおよびオペレーティングシステムに依存しないバイナリ形式です。^[7]

JVM言語はいくつかあり、JVMに移植された古い言語と完全に新しい言語の両方があります。JRubyとJythonは、それぞれRubyとPythonなどの既存の言語の移植としておそらく最もよく知られています。Javaバイトコードにコンパイルするためにゼロから作成された新しい言語の中では、Clojure、Groovy、Scala、Kotlinが最も人気があるかもしれません。JVM言語の注目すべき特徴は、互いに互換性があることです。たとえば、ScalaライブラリをJavaプログラムで使用したり、その逆を行ったりすることができます。^[8]

Java 7 JVMは、Javaプラットフォーム上でJSR 292: 動的型付け言語のサポート^[9]を実装しています。これは、JVMで動的型付け言語をサポートする新しい機能です。この機能は、JVMを拡張してJava以外の言語をサポートすることを使命とするDa Vinci Machineプロジェクト内で開発されました。 ^{[10] [11]}

Java の基本的な考え方は、ユーザー プログラムがホスト マシンをクラッシュさせたり、ホスト マシン上の他の操作に不適切に干渉したりできないという観点から、Java は本質的に安全であり、信頼できるコードに属する特定のメソッドやデータ構造を、同じ JVM 内で実行される信頼できないコードによるアクセスや破損から保護できるというものです。さらに、配列の末尾にアクセスしたり、初期化されていないポインタを使用したりといった、データの破損や予測できない動作につながることが多い一般的なプログラマー エラーは発生しません。クラス モデル、ガベージ コレクション ヒープ、検証機能など、Java の複数の機能が組み合わさって、この安全性が実現されています。

JVM は、実行前にすべてのバイトコードを検証します。この検証は、主に次の 3 種類のチェックで構成されます。

• ブランチは常に有効な場所にあります
• データは常に初期化され、参照は常に型安全です
• プライベートまたはパッケージプライベートなデータとメソッドへのアクセスは厳格に制御されています

最初の 2 つのチェックは、主にクラスがロードされ、使用可能になったときに行われる検証ステップで行われます。3 つ目のチェックは、クラスのデータ項目またはメソッドが別のクラスによって初めてア​​クセスされるときに、主に動的に実行されます。

検証ツールは、有効なプログラム内の一部のバイトコードシーケンスのみを許可します。たとえば、ジャンプ (分岐) 命令は、同じメソッド内の命令のみをターゲットにできます。さらに、検証ツールは、特定の命令が固定のスタック位置で動作することを確認します。 ^[12]これにより、JIT コンパイラはスタックアクセスを固定のレジスタアクセスに変換できます。このため、JVM がスタックアーキテクチャであるからといって、 JIT コンパイラを使用する場合、レジスタベースアーキテクチャでのエミュレーションの速度が低下するわけではありません。コード検証済みの JVM アーキテクチャでは、JIT コンパイラにとって、ターゲットアーキテクチャのレジスタに割り当てる必要がある架空のレジスタまたは架空のスタック位置を取得するかどうかは重要ではありません。実際、コード検証により、JVM は従来のスタックアーキテクチャとは異なります。従来のスタックアーキテクチャでは、JIT コンパイラによる効率的なエミュレーションはより複雑で、通常はより低速のインタープリタによって実行されます。さらに、デフォルトの JVM が使用するインタープリタは、テンプレート インタープリタと呼ばれる特殊なタイプで、一般的なインタープリタのようにスタックをエミュレートするのではなく、バイトコードをネイティブのレジスタ ベースのマシン言語に直接変換します。^[13]多くの点で、HotSpot インタープリタは真のインタープリタというよりも JIT コンパイラと見なすことができます。つまり、バイトコードがターゲットとするスタック アーキテクチャは実装で実際に使用されるのではなく、レジスタ ベースのアーキテクチャで適切に実装できる中間表現の仕様に過ぎません。スタック アーキテクチャが単なる仕様であり、レジスタ ベースの仮想マシンで実装されている別の例として、共通言語ランタイムがあります。^[14]

バイトコード検証器の元の仕様では、いくつかの点で不完全または不正確な自然言語が使用されていました。JVMを正式なシステムとして指定する試みが数多く行われてきました。これにより、現在のJVM実装のセキュリティをより徹底的に分析し、潜在的なセキュリティ上の脆弱性を防止できます。また、実行中のアプリケーションが安全であることが証明されている場合は、不要な安全性チェックをスキップしてJVMを最適化することもできます。^[15]

仮想マシン アーキテクチャでは、マシン内のコードが実行できるアクションを非常に細かく制御できます。このアーキテクチャでは、コードが「意味的に」正しい、つまり、仮想マシンの外部にあるツールによって実現される (正式な) バイトコード検証プロセスに合格していることが前提となります。これは、リモート ソースからの信頼できないコードを安全に実行できるように設計されており、Java アプレットやその他の安全なコード ダウンロードで使用されるモデルです。バイトコード検証が完了すると、ダウンロードされたコードは制限された「サンドボックス」で実行されます。サンドボックスは、ユーザーを不正なコードや悪意のあるコードから保護するように設計されています。バイトコード検証プロセスに加えて、発行者は、アプレットが安全であることを示すデジタル署名を行う証明書を購入して、ユーザーにサンドボックスから抜け出してローカル ファイル システム、クリップボード、外部のソフトウェア、ネットワークにアクセスするよう 求める許可を与えることができます。

バイトコード検証器の正式な証明はJavacard業界によって行われている（Java Cardバイトコード用組み込み検証器の正式な開発^[16]）

ハードウェア アーキテクチャごとに、異なる Java バイトコードインタープリタが必要です。コンピュータに Java バイトコード インタープリタが搭載されている場合は、任意の Java バイトコード プログラムを実行でき、同じプログラムをそのようなインタープリタが搭載されているどのコンピュータでも実行できます。

Java バイトコードがインタープリタによって実行されると、ネイティブ マシン言語にコンパイルされた同じプログラムの実行よりも常に実行速度が遅くなります。この問題は、 Java バイトコードを実行するためのジャストインタイム (JIT) コンパイラによって軽減されます。JIT コンパイラは、プログラムの実行中に Java バイトコードをネイティブ マシン言語に変換します。プログラムの変換された部分は、解釈されるよりもはるかに速く実行できます。この手法は、頻繁に実行されるプログラムの部分に適用されます。このようにして、JIT コンパイラは全体の実行時間を大幅に短縮できます。

Java プログラミング言語と Java バイトコードの間には、必ずしも関連性はありません。Java で記述されたプログラムは、実際のコンピュータのマシン言語に直接コンパイルでき、Java 以外の言語で記述されたプログラムは、Java バイトコードにコンパイルできます。

Javaバイトコードはプラットフォームに依存せず、安全であるように設計されています。^[17]一部のJVM実装にはインタープリタが含まれておらず、ジャストインタイムコンパイラのみで構成されています。^[18]

Javaプラットフォームの誕生当初、JVMはリッチWebアプリケーションを作成するためのWebテクノロジーとして販売されていました。2018年現在、ほとんどのWebブラウザとWebブラウザをバンドルするオペレーティングシステムにはJavaプラグイン^{[アップデート]}が同梱されておらず、 Flash以外のプラグインのサイドローディングも許可されていません。JavaブラウザプラグインはJDK 9で非推奨になりました。 ^[19]

NPAPI Java ブラウザ プラグインは、HTML ページに埋め込まれたいわゆるJava アプレットをJVM が実行できるように設計されました。プラグインがインストールされているブラウザでは、アプレットは割り当てられたページ上の長方形の領域に描画できます。プラグインには JVM が含まれているため、Java アプレットは Java プログラミング言語に制限されません。JVM をターゲットとする任意の言語をプラグインで実行できます。制限された API セットにより、アプレットはユーザーのマイクや 3D アクセラレーションにアクセスできますが、アプレットは長方形の領域外のページを変更できません。主要な競合テクノロジであるAdob​​e Flash Player も、この点では同じように動作します。

^{[アップデート]}W3Techsによると、2015年6月時点で、JavaアプレットとSilverlightの使用はすべてのウェブサイトでそれぞれ0.1%に減少し、Flashは10.8%に減少しました。^[20]

2016年5月以降、JavaPolyでは、ユーザーが改変されていないJavaライブラリをインポートし、JavaScriptから直接呼び出すことができるようになりました。JavaPolyでは、ユーザーのコンピュータにJavaがインストールされていない場合でも、Webサイトで改変されていないJavaライブラリを使用できます。^[21]

JavaScript の実行速度が継続的に向上し、Web ブラウザーがプラグインのサポートを実装していないモバイル デバイスの使用が増えていることから、 JavaScript へのトランスパイルを通じてそれらのユーザーをターゲットにする取り組みが行われています。ソース コードまたは JVM バイトコードを JavaScript にトランスパイルすることが可能です。

JVM言語間で共通なJVMバイトコードをコンパイルすることで、言語の既存のコンパイラをバイトコードに構築することができます。主なJVMバイトコードからJavaScriptへのトランスパイラは、TeaVM、^[22] Dragome Web SDKに含まれるコンパイラ、^[23] Bck2Brwsr、^[24] j2js-compilerです。^[25]

JVM言語からJavaScriptへの主要なトランスパイラとしては、Google Web Toolkitに含まれるJavaからJavaScriptへのトランスパイラ、Clojurescript（Clojure）、GrooScript（Apache Groovy）、Scala.js（Scala）などがあります。^[26]

• 共通言語ランタイム
• Java仮想マシンのリスト
• JVM言語のリスト
• Java仮想マシンの比較
• アプリケーション仮想化ソフトウェアの比較
• 自動化された例外処理
• Java パフォーマンス
• Javaプロセッサ
• K 仮想マシン(KVM)