第12章  実行

初期クラスまたはインタフェースのmainメソッドを実行しようとすると、ロードされていない(つまり、Java Virtual Machineに現在このクラスまたはインタフェースのバイナリ表現が含まれていない)ことが検出されます。 次に、Java仮想マシンがクラス・ローダーを使用して、このようなバイナリ表現を見つけようとします。 この処理に失敗した場合は、エラーがスローされます。 このロード・プロセスは、§12.2で詳しく説明されています。

クラスまたはインタフェースがロードされたら、mainメソッドを呼び出す前に初期化する必要があります。 初期クラスは、すべてのクラスおよびインタフェースと同様に、初期化する前にリンクする必要があります。 リンクには、検証、準備および(オプションの)解決が含まれます。 リンクについては、§12.3で詳しく説明されています。

検証では、初期クラスまたはインタフェースのロードされた表現が正しいシンボルテーブルで整形式であることを確認します。 検証では、初期クラスまたはインタフェースを実装するコードが、Javaプログラミング言語およびJava Virtual Machineのセマンティック要件に準拠していることもチェックされます。 検証中に問題が検出されると、エラーがスローされます。 検証については、§12.3.1で詳しく説明されています。

準備には、静的ストレージと、Java仮想マシンの実装によって内部的に使用されるデータ構造(メソッド表など)の割当てが含まれます。 準備については、§12.3.2で詳しく説明されています。

解決とは、最初のクラスまたはインタフェースからほかのクラスおよびインタフェースへのシンボリック参照をチェックするプロセスであり、前述のほかのクラスおよびインタフェースをロードして、参照が正しいことを確認するプロセスです。

解決の手順は、初期リンケージの時点ではオプションです。 実装では、再帰的に参照されるクラスおよびインタフェースからすべてのシンボリック参照を解決するポイントに至るまで、非常に早期にリンクされているクラスまたはインタフェースからシンボリック参照を解決できます。 (この解決により、これらのロードおよびリンクの手順でエラーが発生する可能性があります。) この実装の選択肢は、C言語の単純な実装で長年使用されてきた「静的」リンクに似ています。 (これらの実装では、コンパイルされたプログラムは、通常、プログラムで使用されるライブラリルーチンへの完全に解決されたリンクを含む、完全にリンクされたバージョンのプログラムを含む「a.out」ファイルとして表されます。 これらのライブラリ・ルーチンのコピーは、a.outファイルに含まれています。)

かわりに、実装では、シンボリック参照がアクティブに使用されている場合にのみ解決するように選択されます。この戦略のすべてのシンボリック参照に対する一貫した使用は、「最も遅い」解決になります。 この場合、初期クラスまたはインタフェースに別のクラスへのいくつかのシンボリック参照があった場合、これらの参照がプログラムの実行中に使用されなかった場合は、それらの参照が一度に1つずつ解決されるか、またはまったく解決されない可能性があります。

解決が実行される際の唯一の要件は、解決中に検出されたエラーが、プログラムのある時点でスローされることです。そこでは、エラーに関与するクラスまたはインタフェースへの直接的または間接的なリンクが必要なプログラムにより、アクションが実行されます。 前述の静的実装例の選択を使用すると、初期クラスまたはインタフェースで記述されたクラスまたはインタフェース、あるいはさらに再帰的に参照されたクラスおよびインタフェースがプログラムの実行前に、ロードおよびリンケージエラーが発生する可能性があります。 「最も遅い」解決を実装したシステムでは、不正なシンボリック参照がアクティブに使用されている場合にのみ、これらのエラーがスローされます。

解決プロセスは、§12.3.3で詳しく説明されています。

この段階では、Java Virtual Machineは依然として初期クラスまたはインタフェースのmainメソッドを実行しようとしています。 これは、クラスまたはインタフェースが初期化されている場合にのみ許可されます(§12.4.1)。

初期化は、任意のクラス変数イニシャライザおよび初期クラスまたはインタフェースの静的イニシャライザをテキスト順で実行することで構成されます。 ただし、初期化する前に、直接スーパークラスを初期化し、直接スーパークラスの直接スーパークラスを再帰的に初期化する必要があります。 最も単純なケースでは、初期クラスは暗黙的な直接スーパークラスとしてObjectを持ちます。クラスObjectがまだ初期化されていない場合は、初期クラスまたはインタフェースを初期化する前に初期化する必要があります。 クラスObjectにはスーパークラスがないため、再帰はここで終了します。

初期クラスにスーパークラスとして別のクラスSuperがある場合は、初期クラスの前にSuperを初期化する必要があります。 これには、Superのロード、検証および準備が必要です(まだ実行されていない場合)。また、実装によっては、Superなどのシンボリック参照を再帰的に解決する場合もあります。

したがって、初期化によって、ロード、リンク、および初期化エラーが発生する可能性があります。これには他のクラスやインタフェースに関連するエラーも含まれます。

初期化プロセスは、§12.4で詳しく説明されています。

最後に、初期クラスまたはインタフェース(他の結果ロード、リンクおよび初期化が発生した可能性がある間)の初期化が完了すると、初期クラスまたはインタフェースで宣言または継承されたmainメソッドが呼び出されます。

特定のクラスで宣言または継承されるmainメソッドは、次のいずれかの場合に候補のmainメソッドです。

初期クラスまたはインタフェースの候補のmainメソッドは、次のルールを適用したかのように呼び出されます。

クラスには、同じシグネチャ(§8.4.2)を持つstaticメソッドとインスタンス・メソッドの両方を含めることはできません。

起動する候補のmainメソッドがない場合、またはインスタンスのmainメソッドの起動時に初期クラスのインスタンスの作成に失敗した場合、実行は失敗します。この場合、実装の正確な動作はこの仕様の範囲外です。

ロード・プロセスは、クラスClassLoaderとそのサブクラスによって実装されます。 クラスClassLoaderのメソッドdefineClassは、classファイル形式(§1.4)でバイナリ表現からClassオブジェクトを構築するために使用できます。

ClassLoaderのサブクラスが異なると、異なるロード・ポリシーを実装できます。 特に、クラス・ローダーは、クラスおよびインタフェースのバイナリ表現をキャッシュしたり、予想される使用状況に基づいてそれらをプリフェッチしたり、関連するクラスのグループをまとめてロードしたりできます。 たとえば、クラス・ローダーによって古いバージョンがキャッシュされるため、新しくコンパイルされたバージョンのクラスが見つからない場合、これらのアクティビティは実行中のアプリケーションに対して完全に透過的でない可能性があります。 ただし、プリフェッチやグループ・ロードを行わずに発生した可能性があるプログラム内のポイントでのみロード・エラーを反映するのはクラス・ローダーの責任です。

クラスのロード中にエラーが発生した場合、LinkageErrorクラスの次のいずれかのサブクラスのインスタンスが、要求されたクラスまたはインタフェースを(直接的または間接的に)使用するプログラム内の任意の時点でスローされます。

ロードには新しいデータ構造の割当てが含まれるため、OutOfMemoryErrorで失敗する可能性があります。

正常に動作するクラス・ローダーは、次の特性を有しています。

悪意のあるクラス・ローダーは、これらの特性に違反している可能性があります。 ただし、Java仮想マシンがこれを防ぐため、型システムのセキュリティが損なわれることはありません。

これらの問題の詳細は、The Java Virtual Machine Specification、 Java SE 26 EditionおよびDynamic Class Loading in the Java Virtual MachineのSheng LiangおよびGilad BrachaによるProceedings of OOPSLA '98(ACM SIGPLAN Notices、 Volume 33、 Number 10、 October 1998、 pages 36-44)を参照してください。 Javaプログラミング言語の設計の基本原則は、ClassLoaderなどの機密システム・クラスの実装によっても、Javaプログラミング言語で記述されたコードによってランタイム・タイプ・システムを逆転できないことです。

検証により、クラスまたはインタフェースのバイナリ表現が構造的に正しいことが保証されます。 たとえば、すべての命令に有効な操作コードがあること、すべての分岐命令が命令の途中ではなく、ほかの命令の先頭に分岐すること、すべてのメソッドに構造的に正しい署名が提供されること、およびすべての命令が Java Virtual Machineの型規則に従うことを検査します。

検証中にエラーが発生すると、次のクラスLinkageErrorのサブクラスのインスタンスが、そのクラスが検証される原因となったプログラム内のポイントでスローされます。

準備では、クラスまたはインタフェースのstaticフィールド(クラス変数および定数)を作成し、それらのフィールドをデフォルト値に初期化します(§4.12.5)。 この場合、ソース・コードの実行は必要ありません。静的フィールドの明示的なイニシャライザは、準備ではなく初期化(§12.4)の一部として実行されます。

Java Virtual Machineの実装では、準備時に追加のデータ構造を事前計算して、後でクラスまたはインタフェースの操作をより効率的にすることができます。 特に有用なデータ構造の1つは、「メソッド表」または他のデータ構造で、呼出し時にスーパークラスを検索することなく、クラスのインスタンスでメソッドを呼び出すことができます。

クラスまたはインタフェースのバイナリ表現は、他のクラスおよびインタフェースとそのフィールド、メソッドおよびコンストラクタを、他のクラスおよびインタフェースのバイナリ名(§13.1)を使用して象徴的に参照します。 フィールドおよびメソッドの場合、これらのシンボリック参照には、フィールドまたはメソッドがメンバーであるクラスまたはインタフェースの名前と、フィールドまたはメソッド自体の名前、および適切な型情報が含まれます。

シンボリック参照を使用するには事前に解決を実施する必要があり、そのときにシンボリック参照が正しいことが確認され、通常は、参照が繰り返し使用される場合にさらに効率的に処理できる直接参照に置換されます。

解決中にエラーが発生すると、エラーがスローされます。 通常、これはクラスIncompatibleClassChangeErrorの次のサブクラスの1つのインスタンスになりますが、IncompatibleClassChangeErrorの他のサブクラスのインスタンスでも、クラスIncompatibleClassChangeError自体のインスタンスでもかまいません。 このエラーは、シンボリック参照を使用するプログラム内の任意の時点で、直接的または間接的にスローされる可能性があります。

また、LinkageErrorのサブクラスであるUnsatisfiedLinkErrorは、実装が見つからないnativeメソッドをクラスが宣言している場合にスローされます。 このエラーは、Java Virtual Machine (§12.3)の実装によってどの種類の解決戦略が使用されているかに応じて、メソッドが使用された場合、またはそれ以前の場合に発生します。

クラスまたはインタフェースTは、次のいずれかが最初に出現する直前に初期化されます。

クラスが初期化されると、そのスーパークラスは初期化されます(以前に初期化されていない場合)。また、デフォルト・メソッド(§9.4.3)を宣言するスーパーインタフェース(§8.1.5)も初期化されます(まだ初期化されていない場合)。 インタフェースを初期化しても、そのスーパーインタフェースは初期化されません。

staticフィールドへの参照(§8.3.1.1)は、実際に宣言するクラスまたはインタフェースのみを初期化します。ただし、サブクラス、サブインタフェースまたはインタフェースを実装するクラスの名前を介して参照できます。

クラスClassおよびパッケージjava.lang.reflectで特定のリフレクティブ・メソッドを呼び出すと、クラスまたはインタフェースの初期化も行われます。

クラスまたはインタフェースは、その他の状況では初期化されません。

コンパイラは、インタフェース内に合成デフォルト・メソッド(明示的にも暗黙的にも宣言されていないデフォルト・メソッド)を生成できることに注意してください(§13.1)。 このようなメソッドは、インタフェースを初期化する必要があることを示さないソース・コードにもかかわらず、インタフェースの初期化をトリガーします。

目的は、クラスまたはインタフェースに一貫性のある状態にする初期化子のセットがあり、この状態が他のクラスによって観測される最初の状態になることです。 staticイニシャライザおよびクラス変数イニシャライザは、テキストの順序で実行され、これらのクラス変数がスコープ(§8.3.3)内にある場合でも、使用後にテキストで宣言されるクラス内で宣言されたクラス変数を参照することはできません。 この制限は、コンパイル時にほとんどの循環または不正な形式の初期化を検出するように設計されています。

初期化コードが無制限であるという事実により、初期化式が評価される前に、クラス変数の値が初期デフォルト値のままである場合にクラス変数の値を観察できる例を構築できますが、このような例は実際にはまれです。 (このような例は、インスタンス変数の初期化のためにも構成できます(§12.5)。) Javaプログラミング言語のフルパワーは、これらのイニシャライザで使用できます。プログラマは慎重に行う必要があります。 この機能はコード・ジェネレータに余分な負担をかけますが、Javaプログラミング言語が同時であるため、この負担はどのような場合でも発生します(§12.4.2)。

class Super {
    static { System.out.print("Super "); }
}
class One {
    static { System.out.print("One "); }
}
class Two extends Super {
    static { System.out.print("Two "); }
}
class Test {
    public static void main(String[] args) {
        One o = null;
        Two t = new Two();
        System.out.println((Object)o == (Object)t);
    }
}

Super Two false

class Super {
    static int taxi = 1729;
}
class Sub extends Super {
    static { System.out.print("Sub "); }
}
class Test {
    public static void main(String[] args) {
        System.out.println(Sub.taxi);
    }
}

1729

interface I {
    int i = 1, ii = Test.out("ii", 2);
}
interface J extends I {
    int j = Test.out("j", 3), jj = Test.out("jj", 4);
}
interface K extends J {
    int k = Test.out("k", 5);
}
class Test {
    public static void main(String[] args) {
        System.out.println(J.i);
        System.out.println(K.j);
    }
    static int out(String s, int i) {
        System.out.println(s + "=" + i);
        return i;
    }
}

1
j=3
jj=4
3

Javaプログラミング言語はマルチスレッドであるため、クラスまたはインタフェースの初期化には慎重な同期が必要です。これは、他のスレッドが同時に同じクラスまたはインタフェースを初期化しようとしている可能性があるためです。 また、クラスまたはインタフェースの初期化は、そのクラスまたはインタフェースの初期化の一部として再帰的に要求される可能性もあります。たとえば、クラス Aの変数イニシャライザは、無関係クラス Bのメソッドを呼び出します。このメソッドは、次にクラス Aのメソッドを呼び出します。 Java Virtual Machineの実装では、次の手順を使用して、同期および再帰的な初期化を処理します。

このプロシージャは、Classオブジェクトがすでに検証および準備されており、Classオブジェクトに次の4つの状況のいずれかを示す状態が含まれていることを前提としています。

クラスまたはインタフェースCごとに、一意の初期化ロックLCがあります。 CからLCへのマッピングは、Java Virtual Machine実装の判断に任されます。 Cを初期化する手順は次のとおりです。

実装では、ステップ1 (およびステップ4/5のリリース)のロック取得を消去することで、クラスの初期化がすでに完了していることを確認できます。ただし、メモリー・モデルの観点では、ロックが取得された場合に存在し、最適化の実行時にまだ存在する前の順序がすべて存在する場合です。

コード・ジェネレータでは、クラスまたはインタフェースの初期化可能なポイントを保持し、前述した初期化プロシージャの呼出しを挿入する必要があります。 この初期化プロシージャが正常に完了し、Classオブジェクトが完全に初期化され、使用する準備ができている場合、初期化プロシージャの起動が不要になり、コードから除外されることがあります。たとえば、このプロシージャにパッチを適用するか、コードを再生成します。

コンパイル時分析では、関連するクラスおよびインタフェースのグループの初期化順序を決定できる場合に、生成されたコードからクラスまたはインタフェースが初期化されているという多くのチェックを排除できる場合があります。 ただし、このような分析では、同時実行性および初期化コードが制限されていないことを完全に考慮する必要があります。

すべてのオブジェクトは、到達可能、ファイナライザ到達可能または到達不可の2つの属性によって特徴付けられます。また、未ファイナライズ、ファイナライズ可能またはファイナライズ済の場合もあります。

到達可能オブジェクトは、任意のライブ・スレッドからの潜在的な継続計算でアクセスできる任意のオブジェクトです。

finalizer-reachableオブジェクトは、なんらかの参照チェーンを介してファイナライズ可能オブジェクトからアクセスできますが、ライブ・スレッドからはアクセスできません。

到達不能オブジェクトは、いずれの方法でも到達できません。

ファイナライズされていないオブジェクトでは、ファイナライザが自動的に呼び出されることはありません。

finalizedオブジェクトは、ファイナライザを自動的に呼び出しました。

ファイナライズ可能オブジェクトではファイナライザが自動的に呼び出されることはありませんが、Java Virtual Machineでは最終的にファイナライザが自動的に呼び出される場合があります。

オブジェクトoは、コンストラクタがoでObjectのコンストラクタを起動し、呼出しが正常に完了するまで(つまり、例外をスローせずに)ファイナライズできません。 オブジェクトのフィールドへのすべての事前ファイナライズ書込みは、そのオブジェクトのファイナライズから参照できる必要があります。 さらに、そのオブジェクトのフィールドの事前ファイナライズ読取りでは、そのオブジェクトのファイナライズが開始された後に発生する書込みは表示されない場合があります。

プログラムの変換を最適化することで、到達可能なオブジェクトの数が、到達可能とみなされるオブジェクトの数より少なくなるように設計できます。 たとえば、Javaコンパイラまたはコード・ジェネレータでは、nullに使用されなくなった変数またはパラメータを設定して、そのようなオブジェクトの記憶域をより早く再利用可能にすることができます。

この別の例は、オブジェクトのフィールドの値がレジスタに格納される場合に発生します。 プログラムは、オブジェクトではなくレジスタにアクセスし、オブジェクトに再度アクセスすることはありません。 これは、オブジェクトがゴミであることを意味します。 この種の最適化が許可されるのは、参照がスタック上にある場合のみであり、ヒープには格納されないことに注意してください。

class Foo {
    private final Object finalizerGuardian = new Object() {
        protected void finalize() throws Throwable {
            /* finalize outer Foo object */
        }
    }
}

メモリー・モデル(§17.4)は、ファイナライザで実行されるアクションをコミットできるタイミングを決定できる必要があります。 この項では、ファイナライズとメモリー・モデルの相互作用について説明します。

各実行には、diというラベルの付いた到達可能性決定ポイントが多数あります。 各アクションは、come-before diまたはcomes-after diのいずれかです。 明示的に記載されている場合を除き、この項で説明する事前注文は、メモリー・モデル内の他のすべての順序付けとは無関係です。

rが、書込みwおよびrがdiの前に来る読取りの場合は、wがdiの前に来る必要があります。

xおよびyが同じ変数またはモニターに対する同期アクションであり、so(x、 y) (§17.4.4)およびyがdiより前である場合は、xがdiより前である必要があります。

到達可能性決定ポイントごとに、一部のオブジェクト・セットは到達不可としてマークされ、それらのオブジェクトの一部のサブセットは最終可能としてマークされます。 これらの到達可能性決定ポイントは、java.lang.refパッケージのAPIドキュメントに記載されているルールに従って、参照がチェック、エンキューおよびクリアされるポイントでもあります。

diポイントで確実に到達可能とみなされるオブジェクトは、次のルールの適用によって到達可能であることが示されるオブジェクトのみです。

オブジェクトXがdiでアクセス不可としてマークされている場合、次のようになります。

アクションaは、次のうち少なくとも1つに該当する場合にのみ、Xをアクティブに使用します。

オブジェクトXがdiでファイナライズ可能としてマークされている場合、次のようになります。