JVM Spec Chap 5
5.1: JVM が、symbolic reference を class/interface のバイナリから取り出す方法
5.2: loading, linking, initialization の手順
5.3: loading 詳細
5.4: linking 詳細
5.5: initialization 詳細
5.6: ネイティブ実装をバインドする方法
5.7: exit
5.1 Run-Time Constant Pool
run-time constant pool は、class/interface ごとに作られる
run-time constant pool には以下のエントリーが格納される
symbolic reference: リンク時に解決されるやつら
static constants
run-time constant pool のエントリーには loadable なものとそうでないものがある
loadable とは
ldc.* 命令 で、スタックに push できる
static arguments to bootstrap methods になれる（？）
loadable な constant_pool のエントリーから作られるエントリーが loadable
5 種類ある
5.2 Startup
JVM は、bootstrap class loader か、user-defined class loader で、 initial class/interface を作ることで動き出す。
1. link initial class/interface
2. initialize it
3. public static void main(String[]) を実行
main を実行すると、必要なクラスのリンクなどが起こるらしい
initial class/interface の決定方法は実装依存でよい。
5.3 Creation and Loading
class/interface の作成とは、その method area （実装依存）を作ること
class/interface は、それを参照する外部の class/interface によって作成されることもある
reflection とかのライブラリによって作成されることもある
class/interface が配列ではないときは、class loader がバイナリ表現を読み込んで作成する
配列の時は、（バイナリ表現がないので）JVM が作成する
user-defined class loader について書かれているが、飛ばす
実行時には、class/interface は、binary name とそれを読み込んだ（？）class loader のペアによって識別される
class/interface は、package name と 読み込んだ class loader のペアで識別される run-time package に所属する
default class loader と user-define class loader に同じクラスがあると、 default が優先されるらしい？
エラーについて
class loading 時にエラーが出たとき、LinkageError
class loader が ClassNotFoundException を出したとき、 NoClassDefFoundError でラップする
5.3.1. Loading Using the Bootstrap Class Loader
1. JVM は読み込むべきクラスの initiating loader として bootstrap class loader がすでに登録されているか確認
2. されていないとき、クラスの名前 N を引数に bootstrap loader を起動して、クラスを探す
ないとき ClassNotFoundException
クラスは、階層的ファイルシステムで管理されることが一般的だが、実装依存
user-defined は省略
5.3.3. Creating Array Classes
1. JVM は読み込むべき配列の要素のクラスの initiating loader として bootstrap class loader がすでに登録されているか確認、されていれば終わり
2. 要素が reference type なら、Sec 5.3 同様にやる
3. 要素のクラスと、次元数から新しい配列クラスを作る
5.3.4 Loading Constraints
5.3.5 Deriving a Class from a class File Representation
5.4 Linking
Linking a class or interface はそのクラスと親クラスの verifying と preparing
resolution of symbolic reference は optional
JVM が linking を実行するタイミングは、以下の条件を満たせばいつでもよい
linking 前に class or interface が completely loaded
initialization 前に class or interface が completely verified and prepared
linkage で発生したエラーが、その linkage を起こす action で throw されること
例えば、symoblic reference の resolution は、それが使われるときに遅延評価されてもよいし、verified のタイミングで評価されてもよい
どちらにせよ、エラーは symbolic reference が使われるタイミングで投げられる必要がある
5.4.1 Verification
クラスのバイナリ表現が section 4 で提示された制約を満たしていることを確認
verification 中に 他のクラスの load が必要なことがあるらしい
が、そのクラスは verified, prepared である必要はない
とりあえず適当に実装するなら無視しておいてよさそう...
5.4.2 Preparation
static field の作成と、初期化
この段階での初期化は jvm code 実行不要なものだけで、explicit な初期化は initialization でやる
なんかクラスに課すべきいくつかの制約が書かれている
5.4.3 Resolution
ここを書け！！！
5.4.4 Access Control
以下が書かれている
あるクラス C が別のクラス D にアクセスできる条件
あるクラス R のメソッドがクラス d にアクセスできる条件
5.4.5 Method overriding
override が起こるときの条件が書いている
5.5 Initialization
class or interface が初期化される条件が列挙されている
初期化前に、class or interface は linked, verified, prepared, resolved (optional) されている必要がある
JVM は、マルチスレッド下における、初期化の synchronization と、初期化関数が再帰的に呼ばれる状況の対策に責任を持つ
Class オブジェクトは状態を表す変数を持つ必要があるらしい（状態は4つある）
各クラスは、unique initialization lock LC を持つ必要があるらしい
初期化の 10 ステップが列挙されている
5.6 Binding Native Method Implementations
binding は、native メソッドを実装している java 以外で書かれた関数が JVM に integrated されるプロセスのこと。
（5.4 の link との言葉の混乱をさけるために、linking ではなく binding と呼ぶ）
5.7 Java Virtual Machine Exit
Runtime.exit, System.exit, Runtime.halt が呼ばれて、それが security manager に許可されたとき JVM は終了する
JNI では別途決まっている