第2章 Java Virtual Machineの構造

Java Virtual Machineの整数型の値は、次のとおりです。

浮動小数点型は floatおよび doubleで、IEEE 754標準(JLS§1.7)で規定されているように、IEEE 754値および演算の32ビットbinary32および64ビットbinary64浮動小数点形式と概念的に関連付けられています。

Java SE 15以降では、Java Virtual Machineは2019バージョンのIEEE 754 Standardを使用します。 Java SE 15より前は、Java Virtual Machineは1985バージョンのIEEE 754 Standardを使用していました。ここで、binary32形式は単一形式と呼ばれ、binary64形式はdouble形式と呼ばれていました。

IEEE 754には、符号と大きさで構成される正と負の数だけでなく、正と負のゼロ、正と負の 無限、および特殊な Not-a-Number値(以降は NaN)も含まれています。 NaN値は、ゼロで除算するなど、特定の無効な操作の結果を表すために使用されます。 float型とdouble型の両方のNaN定数は、Float.NaNおよびDouble.NaNとして事前定義されています。

浮動小数点型の有限非ゼロ値は、すべて s ⋅ m ⋅ 2^{(e - N + 1)}の形式で表すことができます。ここでは:

一部の値は、この形式で複数の方法で表すことができます。 たとえば、浮動小数点型の値vが、s、mおよびeの特定の値を使用してこの形式で表される場合、mが偶数であり、eが2^K-1未満であった場合は、mを停止し、eを1増やして、同じ値vの2番目の表現を生成できます。

この形式での表現は、正規化(m ≥ 2^N-1の場合)と呼ばれ、それ以外の場合、表現は非正規と呼ばれます。 浮動小数点型の値がm ≥ 2^N-1のように表現できない場合、その大きさは最小正規化値の大きさを下回るため、その値は非正規値であるとみなされます。

floatおよびdoubleのパラメータNおよびK (および導出パラメータE_minおよびE_max)の制約を表2.3.2-Aにまとめます。

NaNを除き、浮動小数点値は順序付けされます。 最小から最大まで配置すると、負の無限大、負の有限非ゼロ値、正と負のゼロ、正の有限非ゼロ値、正の無限大になります。

IEEE 754では、binary32およびbinary64浮動小数点形式ごとに複数の異なる NaN値を使用できます。 ただし、Java SE Platformでは、通常、特定の浮動小数点型のNaN値が単一の正規値に縮小されたかのように扱われるため、この仕様は通常、任意のNaNを正規値として参照します。

IEEE 754では、非 NaN引数を持つ浮動小数点演算が NaN結果を生成する可能性があります。 IEEE 754は一連の NaNビットパターンを指定しますが、NaN結果を表すためにどの特定の NaNビットパターンが使用されるかは指定しません。これはハードウェアアーキテクチャーに任されます。 プログラマは、遡及診断情報など、エンコードする様々なビット・パターンを持つNaNを作成できます。 これらのNaN値は、floatおよびdoubleのFloat.intBitsToFloatおよびDouble.longBitsToDoubleメソッドでそれぞれ作成できます。 逆に、NaN値のビット・パターンを検査するために、Float.floatToRawIntBitsおよびDouble.doubleToRawLongBitsメソッドをそれぞれfloatおよびdoubleに使用できます。

正のゼロと負のゼロの比較は等しくなりますが、それらを区別できる他の操作があります。たとえば、1.0を0.0で除算すると正の無限大になりますが、1.0を-0.0で除算すると負の無限大になります。

NaNは順序付けられていないため、数値等価に対する数値比較およびテストでは、オペランドのいずれかまたは両方がNaNの場合、値がfalseになります。 特に、値自体に対する数値等価性のテストは、値がNaNの場合にのみ、値falseを持ちます。 いずれかのオペランドがNaNの場合、数値不等式のテストは値trueを持ちます。

returnAddress型は、Java Virtual Machineのjsr、retおよびjsr_w命令で使用されます(§jsr、§ret、§jsr_w)。 returnAddress型の値は、Java Virtual Machine命令のopコードへのポインタです。 数値プリミティブ型とは異なり、returnAddress型はどのJavaプログラミング言語型にも対応せず、実行中のプログラムでは変更できません。

Java Virtual Machineではboolean型が定義されていますが、サポートは制限されています。 boolean値に対する操作専用のJava Virtual Machine命令はありません。 かわりに、boolean値を操作するJavaプログラミング言語の式は、Java Virtual Machineのintデータ型の値を使用するようにコンパイルされます。

Java Virtual Machineは、boolean配列を直接サポートします。 newarray命令(§newarray)により、boolean配列を作成できます。 boolean型の配列は、byte配列命令baloadおよびbastore (§baload、§bastore)を使用してアクセスおよび変更されます。

OracleのJava Virtual Machine実装では、Javaプログラミング言語のboolean配列は、boolean要素ごとに8ビットを使用して、Java Virtual Machineのbyte配列としてエンコードされます。

Java Virtual Machineでは、1を使用してboolean配列コンポーネントをエンコードし、trueおよび0を表現してfalseを表します。 Javaプログラミング言語のboolean値がコンパイラによってJava Virtual Machineタイプintの値にマップされる場合、コンパイラは同じエンコーディングを使用する必要があります。

Java Virtual Machineは、多数の実行スレッドを一度にサポートできます(JLS§17)。 各Java Virtual Machineスレッドには、独自のpc (プログラム・カウンタ)レジスタがあります。 どの時点においても、各Java Virtual Machineスレッドは単一のメソッドのコード、つまりそのスレッドの現在のメソッド(§2.6)を実行しています。 そのメソッドがnativeでない場合、pcレジスタには現在実行されているJava Virtual Machine命令のアドレスが含まれます。 スレッドによって現在実行されているメソッドがnativeの場合、Java Virtual Machineのpcレジスタの値は未定義です。 Java Virtual Machineのpcレジスタの幅は、特定のプラットフォームでreturnAddressまたはネイティブ・ポインタを保持するのに十分です。

各Java Virtual Machineスレッドには、スレッドと同時に作成されたプライベートなJava Virtual Machineスタックがあります。 Java Virtual Machineスタックには、フレームが格納されます(§2.6)。 Java Virtual Machineスタックは、Cのような従来の言語のスタックに似ています。Cスタックは、ローカル変数と部分的な結果を保持し、メソッドの呼出しとリターンで役割を果たします。 Java Virtual Machineスタックは、プッシュ・フレームとポップ・フレーム以外は直接操作されないため、フレームが割り当てられることがあります。 Java Virtual Machineスタックのメモリーは連続している必要はありません。

Java®仮想マシン仕様の最初のエディションでは、Java Virtual MachineスタックはJavaスタックと呼ばれていました。

この仕様では、Java Virtual Machineスタックを固定サイズにするか、計算で必要とされるとおりに動的に拡張および縮小できます。 Java Virtual Machineスタックのサイズが固定の場合、各Java Virtual Machineスタックのサイズは、そのスタックの作成時に個別に選択できます。

Java Virtual Machineの実装では、プログラマまたはユーザーがJava Virtual Machineスタックの初期サイズを制御できるだけでなく、Java Virtual Machineスタックの動的な拡張または縮小の場合は、最大サイズと最小サイズを制御できます。

Java Virtual Machineスタックには、次の例外条件が関連付けられています。

Java Virtual Machineには、すべてのJava Virtual Machineスレッド間で共有されるヒープがあります。 ヒープは、すべてのクラス・インスタンスおよび配列のメモリーが割り当てられるランタイム・データ領域です。

ヒープは仮想マシンの起動時に作成されます。 オブジェクトのヒープ・ストレージは、自動ストレージ管理システム(ガベージ・コレクタ)によって再利用されます。オブジェクトの割当ては明示的に解除されません。 Java Virtual Machineでは、特定のタイプの自動ストレージ管理システムは想定されず、実装者のシステム要件に従ってストレージ管理手法を選択できます。 ヒープは、固定サイズの場合もあれば、計算で要求されるとおりに拡張される場合もあり、より大きなヒープが不要になった場合は縮小される場合もあります。 ヒープのメモリーは連続している必要はありません。

Java Virtual Machine実装は、ヒープの初期サイズをプログラマまたはユーザーが制御できるだけでなく、ヒープを動的に拡張または縮小できる場合は、最大および最小のヒープ・サイズを制御できます。

ヒープには、次の例外条件が関連付けられます。

Java Virtual Machineには、すべてのJava Virtual Machineスレッド間で共有されるメソッド領域があります。 メソッド領域は、従来の言語のコンパイル済コードの格納領域、またはオペレーティング・システム・プロセスのテキスト・セグメントに類似しています。 ランタイム定数プール、フィールドおよびメソッド・データなどのクラスごとの構造、およびクラスおよびインタフェースの初期化およびインスタンス初期化(§2.9)で使用される特別なメソッドを含むメソッドおよびコンストラクタのコードが格納されます。

方法領域は仮想マシンの起動時に作成されます。 メソッド領域は論理的にヒープの一部ですが、単純な実装ではガベージ・コレクションまたは圧縮のいずれも選択しない場合があります。 この仕様では、コンパイル済コードの管理に使用されるメソッド領域またはポリシーの場所は指定されません。 メソッド領域は固定サイズの場合もあれば、計算によって必要に応じて拡張される場合もあり、より大きなメソッド領域が不要になった場合は縮小される場合があります。 メソッド領域のメモリーは連続している必要はありません。

Java Virtual Machine実装では、プログラマまたはユーザーがメソッド領域の初期サイズを制御できるだけでなく、メソッド領域のサイズが変化した場合に、メソッド領域の最大サイズと最小サイズを制御できます。

メソッド領域には、次の例外条件が関連付けられています。

実行時定数プールは、classファイル(§4.4)内のconstant_pool表のクラスごとまたはインタフェースごとのランタイム表現です。 これには、コンパイル時に認識される数値リテラルから、実行時に解決する必要があるメソッドおよびフィールド参照まで、様々な種類の定数が含まれています。 ランタイム定数プールは、従来のプログラミング言語のシンボルテーブルと同様の関数を提供しますが、一般的なシンボルテーブルよりも広い範囲のデータが含まれています。

各実行時定数プールは、Java Virtual Machineのメソッド領域(§2.5.4)から割り当てられます。 クラスまたはインタフェースの実行時定数プールは、Java Virtual Machineによってクラスまたはインタフェースが作成されたときに構築されます(§5.3)。

次の例外条件は、クラスまたはインタフェースの実行時定数プールの構成に関連付けられます。

ランタイム定数プールの構成については、§5 (Loading、 Linking、 and Initializing)を参照してください。

Java Virtual Machineの実装では、Cスタックと呼ばれる従来のスタックを使用して、nativeメソッド(Javaプログラミング言語以外の言語で記述されたメソッド)をサポートできます。 ネイティブ・メソッド・スタックは、Cなどの言語でのJava Virtual Machineの命令セットのインタプリタの実装でも使用できます。 nativeメソッドをロードできず、それ自体が従来のスタックに依存しないJava Virtual Machine実装は、ネイティブ・メソッド・スタックを提供する必要はありません。 指定した場合、ネイティブ・メソッド・スタックは通常、各スレッドの作成時にスレッドごとに割り当てられます。

この仕様により、ネイティブ・メソッド・スタックを固定サイズにするか、計算で必要とされるとおりに動的に拡張および縮小できます。 ネイティブ・メソッド・スタックのサイズが固定の場合、各ネイティブ・メソッド・スタックのサイズは、そのスタックの作成時に個別に選択できます。

Java Virtual Machine実装では、プログラマまたはユーザーがネイティブ・メソッド・スタックの初期サイズを制御できるだけでなく、サイズが変化するネイティブ・メソッド・スタックの場合は、メソッド・スタックの最大サイズと最小サイズを制御できます。

ネイティブ・メソッド・スタックには、次の例外条件が関連付けられます。

各フレーム(§2.6)には、その局所変数と呼ばれる変数の配列が含まれています。 フレームのローカル変数配列の長さは、コンパイル時に決定され、フレームに関連付けられたメソッドのコードとともに、クラスまたはインタフェースのバイナリ表現で提供されます(§4.7.3)。

単一のローカル変数は、int、float、referenceまたはreturnAddress型の値を保持できます。 ローカル変数のペアは、long型またはdouble型の値を保持できます。

ローカル変数は、索引付けによって対処されます。 最初のローカル変数のインデックスは0です。 整数がゼロからローカル変数配列のサイズより1小さい場合にのみ、その整数がローカル変数配列への索引とみなされます。

long型またはdouble型の値は、連続する2つのローカル変数を占有します。 このような値は、より小さい索引を使用してのみ対処できます。 たとえば、索引nのローカル変数配列に格納されたdouble型の値は、索引nおよびn+1を持つローカル変数を実際に占有しますが、索引n+1のローカル変数はロードできません。 に保存できます。 ただし、これを行うと、ローカル変数nの内容が無効になります。

Java Virtual Machineでは、nを偶数にする必要はありません。 直感的な用語では、long型とdouble型の値をローカル変数配列に64ビット整列させる必要はありません。 実装者は、値用に予約された2つのローカル変数を使用して、そのような値を表す適切な方法を自由に決定できます。

Java Virtual Machineでは、ローカル変数を使用してメソッドの起動時にパラメータを渡します。 クラス・メソッドの起動時に、すべてのパラメータがローカル変数0から始まる連続したローカル変数で渡されます。 インスタンス・メソッドの呼出しでは、ローカル変数0が常に使用され、インスタンス・メソッドが呼び出されるオブジェクト(Javaプログラミング言語のthis)への参照が渡されます。 その後、すべてのパラメータは、ローカル変数1から始まる連続したローカル変数で渡されます。

各フレーム(§2.6)には、そのオペランド・スタックと呼ばれる最後の先入れ先出し(LIFO)スタックが含まれています。 フレームのオペランドスタックの最大深度はコンパイル時に決定され、フレームに関連付けられたメソッドのコードとともに提供されます(§4.7.3)。

コンテキストによって明確である場合、現在のフレームのオペランドスタックを単にオペランドスタックと呼びます。

オペランドスタックは、それを含むフレームが作成されると空になります。 Java Virtual Machineは、ローカル変数またはフィールドからオペランド・スタックに定数または値をロードする命令を提供します。 その他のJava Virtual Machine命令は、オペランド・スタックからオペランドを取り出して操作し、結果をオペランド・スタックにプッシュして戻します。 オペランド・スタックは、メソッドに渡されるパラメータを準備したり、メソッド結果を受信するためにも使用されます。

たとえば、iadd命令(§iadd)は、2つのint値を加算します。 追加するint値は、前の手順でプッシュされたオペランド・スタックの上位2つの値である必要があります。 両方のint値がオペランド・スタックからポップされます。 追加され、合計がオペランド・スタックに押し戻されます。 サブ計算をオペランド・スタックにネストすると、包含する計算で使用できる値になります。

オペランド・スタックの各エントリは、long型またはdouble型の値を含む、任意のJava Virtual Machine型の値を保持できます。

オペランドスタックからの値は、その型に適した方法で操作する必要があります。 たとえば、2つのint値をプッシュしてからlongとして処理したり、2つのfloat値をプッシュしてからiadd命令で追加することはできません。 少数のJava Virtual Machine命令(dup命令(§dup)およびswap (§swap))は、特定の型に関係なくランタイム・データ領域をRAW値として動作します。これらの命令は、個々の値を変更または分割するために使用できないような方法で定義されます。 オペランド・スタック操作に対するこれらの制限は、classファイル検証(§4.10)によって施行されます。

任意の時点で、オペランド・スタックに深さが関連付けられており、longまたはdouble型の値は深さに2つの単位を寄与し、他の型の値は1つの単位を寄与します。

各フレーム(§2.6)には、現在のメソッドのタイプに対する実行時定数プール(§2.5.5)への参照が含まれ、メソッド・コードの動的リンクをサポートします。 メソッドのclassファイル・コードは、呼び出されるメソッドと、シンボリック参照を介してアクセスされる変数を参照します。 動的リンクは、これらのシンボリック・メソッド参照を具象メソッド参照に変換し、必要に応じてクラスをロードして、まだ定義されていないシンボルを解決し、これらの変数の実行時位置に関連付けられたストレージ構造内の適切なオフセットに変数アクセスを変換します。

メソッドと変数のこの遅延バインディングにより、メソッドがこのコードを壊す可能性が低くなる他のクラスが変更されます。

メソッド呼出しは、例外(§2.10)がJava Virtual Machineから直接、または明示的なthrow文を実行した結果としてスローされない場合に、通常どおりに完了します。 現在のメソッドの呼出しが正常に完了した場合は、呼出し元メソッドに値が返されます。 これは、呼び出されたメソッドが戻り命令の1つ(§2.11.8)を実行するときに起こります。その選択は、返される値のタイプ(ある場合)に適している必要があります。

この場合、現在のフレーム(§2.6)を使用して、呼出し元の状態(ローカル変数およびオペランド・スタックを含む)をリストアし、呼出し元のプログラム・カウンタを適切に増やして、メソッド呼出し命令をスキップします。 その後、そのフレームのオペランド・スタックにプッシュされた戻り値(ある場合)を使用して、起動メソッドのフレーム内で正常に実行が続行されます。

メソッド内のJava Virtual Machine命令の実行によってJava Virtual Machineが例外をスローし(§2.10)、その例外がメソッド内で処理されない場合、メソッド呼出しは突然完了します。 また、athrow命令(§athrow)を実行すると、例外が明示的にスローされ、現在のメソッドで例外が捕捉されないと、メソッド呼出しが突然完了します。 突然完了するメソッド呼出しは、呼出し元に値を戻しません。

クラスには、インスタンス初期化メソッドが0個以上あり、通常はJavaプログラミング言語で記述されたコンストラクタに対応します。

次のすべてに該当する場合、メソッドはインスタンス初期化メソッドです。

クラスでは、<init>という名前のvoid以外のメソッドはインスタンス初期化メソッドではありません。 インタフェースでは、<init>という名前のメソッドはインスタンス初期化メソッドではありません。 このようなメソッドは、Java Virtual Machine命令(§4.4.2、§4.9.2)によって起動できず、フォーマット・チェック(§4.6、§4.8)によって拒否されます。

インスタンス初期化メソッドの宣言と使用は、Java Virtual Machineによって制約されます。 この宣言では、メソッドのaccess_flags項目およびcode配列が制約されます(§4.6、§4.9.2)。 インスタンス初期化メソッドは、初期化されていないクラス・インスタンス(§4.10.1.9)のinvokespecial命令によってのみ起動できます。

<init>という名前はJavaプログラミング言語の有効な識別子ではないため、Javaプログラミング言語で記述されたプログラムで直接使用することはできません。

クラスまたはインタフェースには、最大1つのクラスまたはインタフェース初期化メソッドがあり、そのメソッドを起動するJava Virtual Machineによって初期化されます(§5.5)。

次のすべてに該当する場合、メソッドはクラスまたはインタフェースの初期化メソッドです。

classファイル内の<clinit>という名前の他のメソッドは、クラスまたはインタフェース初期化メソッドではありません。 これらは、Java Virtual Machine自体によって呼び出されることはなく、Java Virtual Machine命令(§4.9.1)によって呼び出されることもなく、フォーマット・チェック(§4.6、§4.8)によって拒否されることもあります。

<clinit>という名前はJavaプログラミング言語の有効な識別子ではないため、Javaプログラミング言語で記述されたプログラムで直接使用することはできません。

次のすべてに当てはまる場合、メソッドは署名多相です。

Java Virtual Machineは、invokevirtual命令(§invokevirtual)内の署名多相メソッドに特別な処理を行い、メソッド・ハンドルの起動を有効にしたり、java.lang.invoke.VarHandleのインスタンスによって参照される変数へのアクセスを有効にします。

メソッド・ハンドルは、動的に厳密に型指定され、基礎となるメソッド、コンストラクタ、フィールドまたは同様の低レベル操作(§5.4.3.5)への直接実行可能な参照であり、引数または戻り値の変換はオプションです。 java.lang.invoke.VarHandleのインスタンスは、staticフィールド、非staticフィールド、配列要素、オフヒープ・データ構造のコンポーネントなど、変数または変数のファミリに対して動的に厳密に型指定された参照です。 詳細は、Java SE Platform APIのjava.lang.invokeパッケージを参照してください。

do {
    atomically calculate pc and fetch opcode at pc;
    if (operands) fetch operands;
    execute the action for the opcode;
} while (there is more to do);

Java Virtual Machine命令セット内のほとんどの命令は、実行する操作に関する型情報をエンコードします。 たとえば、iload命令(§iload)は、ローカル変数の内容(intである必要がある)をオペランドスタックにロードします。 fload命令(§fload)は、float値でも同じことを行います。 この2つの命令は同一の実装を持つことができますが、異なるopcodeを持ちます。

型付き命令の大部分の場合、命令タイプはopcodeニーモニックでは、int操作の場合はi、longの場合はl、shortの場合はs、byteの場合はb、charの場合はc、floatの場合はf、doubleの場合はd、referenceの場合はaという文字で明示的に表されます。 型があいまいでない命令の中には、ニーモニックに型文字がないものがあります。 たとえば、arraylengthは常に、配列であるオブジェクトに対して動作します。 gotoなどの一部の命令は、無条件制御転送であり、型付きオペランドでは動作しません。

Java Virtual Machineの1バイトのOPコード・サイズを考慮すると、OPコードへのエンコーディング・タイプは、その命令セットの設計に圧力をかけることになります。 各型付き命令がJava Virtual Machineのすべてのランタイム・データ型をサポートしている場合、1バイトで表されるよりも多くの命令があります。 かわりに、Java Virtual Machineの命令セットによって、特定の操作に対するタイプ・サポートのレベルが低下します。 つまり、命令セットは意図的に直交的ではありません。 必要に応じて、サポートされていないデータ型とサポートされているデータ型を変換するために、個別の命令を使用できます。

表2.11.1-Aに、Java Virtual Machineの命令セットでの型サポートの概要を示します。 型情報を持つ特定の命令は、opcode列の命令テンプレートのTを型列の文字で置き換えることによって作成されます。 一部のインストラクション・テンプレートおよびタイプのタイプ列が空白の場合、そのタイプの操作をサポートするインストラクションは存在しません。 たとえば、int型のiloadのロード命令がありますが、byte型のロード命令はありません。

表2.11.1-Aのほとんどの手順には、整数型byte、charおよびshortのフォームがありません。 boolean型のフォームはありません。 型byteおよびshortの値がオペランド・スタックにロードされるたびに、符号拡張によってint型の値に暗黙的に変換されます。 同様に、boolean型およびchar型の値がオペランド・スタックにロードされるたびに、int型の値にゼロ拡張によって暗黙的に変換されます。 したがって、元々boolean型、byte型、char型およびshort型の変数に格納された値に対するほとんどの操作は、計算型intの値を操作する命令によって正しく実行されます。

Java Virtual Machineのストレージ・タイプとJava Virtual Machineの計算タイプとのマッピングは、表2.11.1-Bにまとめます。

popやswapなどの特定のJava Virtual Machine命令は、型に関係なくオペランド・スタックで動作しますが、このような命令は、表2.11.1-Bに示されているように、特定のカテゴリの計算型の値にのみ使用するように制約されます。

ロードおよび格納命令は、Java Virtual Machineフレーム(§2.6)のローカル変数(§2.6.1)とオペランド・スタック(§2.6.2)の間で値を転送します。

オブジェクトのフィールドや配列の要素にアクセスする命令(§2.11.5)もオペランドスタックとの間でデータを転送します。

iload_<n>、iload_0、iload_1、iload_2およびiload_3 (iload_<n>の場合)のメンバーを含む命令のファミリを示す、前述の手順のニーモニック。 このような命令ファミリは、1つのオペランドを取る追加の汎用命令(iload)の特殊化です。 特殊な命令の場合、オペランドは暗黙的であり、格納またはフェッチする必要はありません。 それ以外の場合、セマンティクスは同じです(iload_0は、オペランド 0を持つ iloadと同じことを意味します)。 山カッコ間の文字は、その命令ファミリの暗黙オペランドのタイプを指定します。<n>の場合は負でない整数、<i>の場合はint、<l>の場合はlong、<f>の場合はfloat、<d>の場合はdoubleです。

命令ファミリのこの表記は、この仕様全体で使用されます。

算術命令は、通常、オペランドスタック上の2つの値の関数である結果を計算し、その結果をオペランドスタックにプッシュバックします。 算術命令には、整数値を操作する命令と浮動小数点値を操作する命令の2種類があります。 これらの各種類の算術命令は、Java Virtual Machineの数値型に特化されています。 byte、shortおよびchar型の値(§2.11.1)またはboolean型の値に対する整数演算の直接的なサポートはありません。これらの演算は、int型で動作する命令によって処理されます。 整数命令と浮動小数点命令は、オーバーフローおよびゼロ除算での動作も異なります。 算術命令は次のとおりです。

整数および浮動小数点値(JLS§4.2.2、JLS§4.2.4)に対するJavaプログラミング言語演算子のセマンティクスは、Java Virtual Machine命令セットのセマンティクスによって直接サポートされます。

Java Virtual Machineでは、整数データ型に対する操作中のオーバーフローは示されません。 例外をスローできる整数演算は、整数除算命令(idivおよびldiv)と整数余剰命令(iremおよびlrem)のみで、除数がゼロの場合はArithmeticExceptionをスローします。

Java Virtual Machineは、浮動小数点データ型に対する操作中にオーバーフローまたはアンダーフローを示しません。 つまり、浮動小数点命令によって、Java Virtual Machineが実行時例外をスローすることはありません(IEEE 754浮動小数点例外と混同しないでください)。 オーバーフローする演算は符号付き無限大を生成し、アンダーフローする演算は非正規値または符号付きゼロを生成し、数学的に一意の結果が定義されていない演算は NaNを生成します。 NaNをオペランドとするすべての数値演算は、結果として NaNを生成します。

long型(lcmp)の値を比較すると、符号付き比較が実行されます。

浮動小数点型の値(dcmpg、dcmpl、fcmpg、fcmpl)の比較は、IEEE 754の非シグナリング比較を使用して実行されます。

型変換命令では、Java Virtual Machineの数値型間の変換が可能です。 これらは、ユーザー・コードに明示的な変換を実装したり、Java Virtual Machineの命令セットに正統性の欠如を軽減するために使用できます。

Java Virtual Machineでは、次の拡張数値変換が直接サポートされます。

拡大する数値変換命令は、i2l、i2f、i2d、l2f、l2dおよびf2dです。 これらのopコードのニーモニックは、型付き命令の命名規則および「to」を意味する2のパンニングの使用により、単純です。 たとえば、i2d命令は、int値をdoubleに変換します。

拡大する数値の変換では、数値の全体の大きさに関する情報は失われません。 実際、intからlongおよびintからdoubleへの変換では、情報がまったく失われず、数値は正確に保持されます。 floatからdoubleへの変換は、数値を正確に保持します。

intからfloatへの変換、またはlongからfloatへの変換、またはlongからdoubleへの変換では、精度が失われる可能性があります。つまり、値の最下位ビットの一部が失われる可能性があります。結果の浮動小数点値は、丸めから最も近い丸めポリシー(§2.8)を使用して、整数値の正しい丸めバージョンです。

精度が失われる可能性があるにもかかわらず、数値変換を拡張しても、Java Virtual Machineが実行時例外をスローすることはありません(IEEE 754浮動小数点例外と混同しないでください)。

intからlongへの数値の拡大変換では、int値の2つの補数表現に符号を付けて、より広い書式を塗りつぶします。 charの数値変換を整数型に拡大すると、char値の表現が拡張され、より広い書式になります。

数値変換の拡大は、整数型byte、charおよびshortからint型には存在しません。 §2.11.1に記載されているように、byte、charおよびshort型の値は内部的にint型に拡大され、これらの変換は暗黙的に行われます。

Java Virtual Machineでは、次の数値の絞込み変換も直接サポートされます。

数値変換命令は、i2b、i2c、i2s、l2i、f2i、f2l、d2i、d2l、および d2fです。 数値変換を絞り込むと、符号が異なる値、大きさが異なる値、またはその両方になるため、精度が失われる可能性があります。

intまたはlongの数値を整数型Tに絞り込むと、nの最下位ビット以外のすべてのビットが破棄されます。ここで、nは、型Tを表すために使用されるビット数です。 これにより、結果の値が入力値と同じ符号を持たない場合があります。

浮動小数点値を整数型Tに絞り込む数値変換(Tはintまたはlong)では、浮動小数点値は次のように変換されます。

doubleからfloatへの数値の縮小変換は、IEEE 754に従って動作します。 結果は、最も近い丸めポリシー(§2.8)を使用して正しく丸められます。 floatとして表すには小さすぎる値は、float型の正または負のゼロに変換されます。floatとして表すには大きすぎる値は、正または負の無限大に変換されます。 double NaNは、常にfloat NaNに変換されます。

オーバーフロー、アンダーフロー、または精度の損失が発生する可能性があるにもかかわらず、数値型間の変換を絞り込むと、Java Virtual Machineはランタイム例外をスローしません(IEEE 754浮動小数点例外と混同しないでください)。

クラス・インスタンスと配列はどちらもオブジェクトですが、Java Virtual Machineでは、異なる命令セットを使用してクラス・インスタンスと配列を作成および操作します。

オペランド・スタックの直接操作には、pop、pop2、dup、dup2、dup_x1、dup2_x1、dup_x2、dup2_x2、swapの命令が多数用意されています。

制御転送命令は、条件付きまたは無条件に、制御転送命令に続く命令以外の命令でJava Virtual Machineの実行を続行します。 これらを次に示します。

Java Virtual Machineには、int型およびreference型のデータと比較して条件付き分岐する一連の異なる命令があります。 また、null参照をテストする個別の条件付き分岐命令があるため、nullの具体的な値を指定する必要はありません(§2.4)。

boolean、byte、charおよびshort型のデータの比較に関する条件分岐は、int比較命令(§2.11.1)を使用して実行されます。 long、floatまたはdouble型のデータの比較に関する条件分岐は、データを比較し、比較のint結果を生成する命令(§2.11.3)を使用して開始されます。 後続のint比較命令は、この結果をテストし、条件付きブランチに影響を与えます。 intの比較に重点を置いているため、Java Virtual Machineでは、int型の条件分岐命令が豊富に補完されています。

すべてのint条件付き制御転送命令は、署名付き比較を実行します。

次の5つの手順でメソッドを呼び出します。

戻り型で区別されるメソッド戻り命令は、ireturn (戻り型boolean、byte、char、shortおよびintに使用)、lreturn、freturn、dreturnおよびareturnです。 また、return命令は、void、インスタンス初期化メソッドおよびクラスまたはインタフェース初期化メソッドとして宣言されたメソッドから戻すために使用されます。

例外は、athrow命令を使用してプログラム的にスローされます。 例外は、異常な状態を検出した場合に、様々なJava Virtual Machine命令によってスローすることもできます。

Java Virtual Machineでは、単一の同期構成(モニター)によって、メソッド内のメソッドと一連の命令の同期がサポートされます。

メソッド・レベルの同期は、メソッドの呼出しおよび戻り値の一部として暗黙的に実行されます(§2.11.8)。 synchronizedメソッドは、実行時定数プールのmethod_info構造体(§4.6)で、メソッド呼出し命令によってチェックされるACC_SYNCHRONIZEDフラグによって区別されます。 ACC_SYNCHRONIZEDが設定されているメソッドを呼び出すと、実行スレッドはモニターに入り、メソッド自体を呼び出して、メソッド呼出しが正常に完了するか突然完了するかをモニターを終了します。 実行中のスレッドがモニターを所有している間は、ほかのスレッドがモニターに入ることはできません。 synchronizedメソッドの起動中に例外がスローされ、synchronizedメソッドが例外を処理しない場合、そのメソッドのモニターは、例外がsynchronizedメソッドから再スローされる前に自動的に終了します。

一連の命令の同期は、通常、Javaプログラミング言語のsynchronizedブロックをエンコードするために使用されます。 Java Virtual Machineには、このような言語構成をサポートするためのmonitorenterおよびmonitorexit命令が用意されています。 synchronizedブロックを適切に実装するには、Java Virtual Machine (§3.14)をターゲットとするコンパイラからの協力が必要です。

構造化ロックは、メソッドの起動時に、特定のモニターのすべての終了がそのモニターの前のエントリと一致する状況です。 Java Virtual Machineに送信されたすべてのコードが構造化ロックを実行する保証がないため、Java Virtual Machineの実装は許可されますが、構造化ロックを保証する次の2つのルールの両方を適用する必要はありません。 Tをスレッドとし、Mをモニターにします。 次に、

synchronizedメソッドの呼出し時にJava Virtual Machineによって自動的に実行されるモニター・エントリおよび終了は、呼出しメソッドの呼出し中に発生するとみなされます。