V8 JavaScript Engine libraries.cc Part 2

昨日の続き。
libraries.ccで定義されている関数がどこで使われているかを調査。
(JavaScriptコードをv8エンジンではどう使っているのか)一番気になるGetRawScriptSource()がターゲット。
■GetRawScriptSource()
1.void Deserializer::ReadChunk() @ serializer.cc
data = source_->Get();の結果がkNativesStringResourceの場合に実行される。
その戻り値を利用してNativesExternalStringResourceクラスのインスタンス生成。
2.Handle<String> Bootstrapper::NativesSourceLookup() @ bootstrapper.cc
heap->natives_source_cache()->get(index)->IsUndefined()がtrueならば実行される(ただし、Natives::GetRawScriptSource())。
※　indexはint型引数。
※　NativeSourceLookup()はbool Genesis::CompileBuiltin() @ bootstrapper.ccから実行され、戻り値がCompileNative()に渡される。
3.bool Genesis::CompileExperimentalBuiltin() @ bootstrapper.cc
ExperimentalNatives::GetRawScriptSource()限定だが実行され、その結果がfactory->NewStringFromAscii()に渡され、その結果がCompileNative()に渡される。
4.void Shell::InstallUtilityScript() @ d8.cc
GetRawScriptSource()の引数として与えられる値は以下の通り。
i::NativesCollection<i::D8>::GetIndex("d8");
"d8"と言う時点でbuiltinではなく、d8固有の機能をインストールしているはず。

ちなみにNativesとExperimentalNativesは以下の通りnatives.hで定義されている。NativeCollectionクラスの定義も同じファイルで定義されている。

typedef NativesCollection<CORE> Natives;
typedef NativesCollection<EXPERIMENTAL> ExperimentalNatives;

以上の事から、以下の２点が今後の調査ポイントになりそう。

• Deserializer::ReadChunk()でNativesExternalStringResourceオブジェクトを作る事の意味
• Bootstrapper::NativesSourceLookup()でCompileNative()にJavaScriptソースコードが渡された後の処理

あと、libraries.ccに生成された整数値の羅列を解析（と言う程のものではないが、char型データとしてファイル出力）して、目視確認すると以下の事をやっている事は分かった。

• コメント行は全て改行のみに変換
• ローカル変数名を１文字のアルファベットに変換

つまりは、データ化した時のサイズを小さくする事が目的の変換が施されている様子。
依然として関数名の先頭に％が記述されている変則的な記法は残っている。。。

とりあえず今日はここまで。