Denoのコードを読んでみました。
\nRust に入門したばかりで基礎知識が足らず四苦八苦していますが、Deno のプロセスが起動してから TypeScript のコードが実行されるまでの仕組みについて愚直に読んでみたメモです。
コア内部を理解するには非公式ガイド（以下ガイド）がとても参考になります。
\n\n\n\n
Deno のディレクトリ構成やレイヤー分けについてはRepo StructureとInfrastructureを一読し、リポジトリの構造をざっくり把握してからコードを読み始めるとより捗ると思います。
\nまた、すでにmizchiさんがDeno のコードを読んだメモを上げてました。そちらもとても参考になりました。
\nまず Deno のビルドツールについて軽く触れます。
\nDeno ではgnという Node.js でおなじみの gyp の次期バージョンをビルドツールに用いています。
\n\nWhat is GN?\nGN is a meta-build system that generates NinjaBuild files. It’s meant to be faster and simpler than GYP. It outputs only Ninja build files.
\n\n
コードを読む上でビルド設定のすべてを理解する必要はありませんが、これを読まないと次に実行されるコードがわからない、このコードがどこから出現したかわからないってことが結構あるので、必要に応じてビルド設定も併せて読むと読み進められると思います。
\ndenoコマンドを実行したときに真っ先に実行されるファイルはsrc/main.rsです。ビルドツールでdenoコマンドを生成する際のエントリポイントとしてsrc/main.rsが指定されています。
\n
\nrust_executable(\"deno\") {\n source_root = \"src/main.rs\"main.rs の詳細に入る前にmain関数のアウトラインを整理し、用語の補足をしてから次に進みます。またガイドのRust main() Entry Pointにも説明があるので併せてご覧ください。
--helpオプションをチェックし、あればヘルプを表示して終了Arc<IsolateState>インスタンスを生成snapshot::deno_snapshotで V8 スナップショットを取得tokio_util::initで Tokio を初期化denoMain();を評価するという流れになっています。用語を補足してから詳細を読み進めます。すでに知ってる方は先へお進み下さい。
\nロガーや--help周りはコード量も少ないしシンプルなので解説は割愛します。またイベントループに関してはかなり長くなると判断したので本記事では割愛します。イベントループについてはガイドのisolate.event_loop()にて詳しく説明されているのでそちらを参照して下さい。
Isolate は V8 が提供している API の１つです。
\nDeno にこれをラップした isolate.rs などがありますが、末端までコードを読むと結局は V8 の Isolate を操作しています。
\n\nIsolate\nAn isolate is a concept of an instance in V8. In Blink, isolates and threads are in 1:1 relationship. One isolate is associated with the main thread. One isolate is associated with one worker thread. An exception is a compositor worker where one isolate is shared by multiple compositor workers.
\n\n
\n\n— VM よりコンテナよりもさらに軽量な分離技術、V8 の Isolate を用いてサーバレスコンピューティングを提供する Cloudflare Workers － Publickey
\n
V8 には生成された Isolate Context の状態をシリアライズしておき、それをデシリアライズして利用することでオーバーヘッドを削減し Isolate Context の生成を高速化する スナップショットの機能があります。
\nNode.js でも V8 スナップショットを使用してプロセスの起動を高速化する RFC が#17058にて議論されています。
\nその Issue のより詳細な資料Speeding up Node.js startup using V8 snapshotによると V8 スナップショットを使うことで、プロセスの起動時間を最大で２桁倍高速化できる見立てがあるようです。
\n\n「このタイプの callback 関数があるから、この Object を用意して、この値を設定して」とやっていくのは効率が良くありません。「一通り定義したらこれだけのメモリが必要で、こんなレイアウトになってるから」という感じにできないでしょうか？\nそこで我々は V8 が用意してくれていた Snapshot の機能を使って効率化することにしました。ちなみに純粋な V8 でも同様に Context を作る度に Math などの Built-in object を作るのが非効率ということで、この Snapshot 機能を作ったという背景があります。
\n\n
Arc って名前から全くピンとこなかったのですが、Atomically Reference Counted の略だそうです。
\nAtomic がついてないシングルスレッド版のrcという crate もあるようです。
\n\nA thread-safe reference-counting pointer. ‘Arc’ stands for ‘Atomically Reference Counted’.
\n\n
\n\nスレッドをまたいで参照を共有するために、Rust は
\nArc<T>というラッパ型を提供しています。— 並行性
\n
私もきちんと理解できていないので引用だけにとどめます。
\ntokio 周りは読み飛ばしてもコードの流れは追えます。どの処理で・どんな単位で並列化/多重化してるかについてしっかり読む場合は tokio と Futures の理解が必要になります。
\n\nTokio is an event-driven, non-blocking I/O platform for writing asynchronous applications with the Rust programming language.
\n\n
\n\nfutures::{Future, Stream} で実装された非同期かつゼロコストなグリーンスレッドを使ってネットワークプログラミングするためのフレームワーク
\n\n
それでは main のアウトラインに沿って詳細を読んでいきます。
\nまずコマンドライン引数のパース周りの処理はsrc/flags.rsにあります。
\nパース処理は、まず V8 用のオプションのパースから実行されます。v8_set_flags関数です。この関数で V8 用のオプションとそれ以外（Deno の引数）を分離し、V8 用の引数はlibdeno/api.cc のdeno_set_v8_flagsに渡し、Deno 用の引数は後続の処理に引き継ぎます。
\nlibdeno::deno_set_v8_flags が定義されているのはlibdeno/api.ccです。
\n
void deno_set_v8_flags(int* argc, char** argv) {\n v8::V8::SetFlagsFromCommandLine(argc, argv, true);\n}C++で定義された関数を Rust から呼び出すための FFI の定義がsrc/libdeno.rsに書かれています。
\n\n
extern \"C\" {\n pub fn deno_init();\n pub fn deno_v8_version() -> *const c_char;\n pub fn deno_set_v8_flags(argc: *mut c_int, argv: *mut *mut c_char);V8 のオプションか否かを判定する方法はコメントによるとlibdeno::deno_set_v8_flags内部で呼び出されているv8::V8::SetFlagsFromCommandLineの内部に書かれており、引数で渡したコマンドラインオプションのうち、V8 が解釈できたオプションだけ取り除かれるという破壊的操作になってるようですようです。
\n
// deno_set_v8_flags(int* argc, char** argv) mutates argc and argv to remove\n // flags that v8 understands.\n // First parse core args, then convert to a vector of C strings.V8 が解釈できなかった残りのオプションのパース処理は Rust のgetoptsという crate をラップした独自関数を用いています getopts は予期しないオプションが渡されたときにエラー扱いになるのですが、そのエラーを自前でハンドルするためにラップしたset_recognized_flagsという関数を使用しています。“better solution welcome!”だそうです。なお Deno に指定可能なオプションはset_flags関数を読めばわかります。
\n
// getopts doesn't allow parsing unknown options so we check them\n // one-by-one and handle unrecognized ones manually\n // better solution welcome!Arc<IsolateState>インスタンスを生成isolate::IsolateState::newはsrc/isolate.rsに定義されていますが、これ自体はただの構造体を初期化してるだけだったので詳細を割愛。
snapshot::deno_snapshotはsrc/snapshot.rsに定義されています。
\n
pub fn deno_snapshot() -> deno_buf {\n #[cfg(not(feature = \"check-only\"))]\n let data =\n include_bytes!(concat!(env!(\"GN_OUT_DIR\"), \"/gen/snapshot_deno.bin\"));\n // The snapshot blob is not available when the Rust Language Server runs\n // 'cargo check'.\n #[cfg(feature = \"check-only\")]\n let data = vec![];\n\n unsafe { deno_buf::from_raw_parts(data.as_ptr(), data.len()) }\n}{GN_OUT_DIR}/gen/snapshot_deno.binというファイルから V8 スナップショットを取得しています。このファイルは gn でビルドする時に生成されているようです。環境変数GN_OUT_DIRの値はデバッグビルドした環境ではtarget/debugになってました。
スナップショットを生成するビルドタスクは\nBUILD.gn のsnapshot(\"snapshot_deno\")に定義があります。snapshotというテンプレートはlibdeno/deno.gniに定義されていました。.gniは GN のビルド設定を別ファイルに定義して import できるようにしたものだそうです。
\n\nYou can import .gni files into the current scope with the import function.
\n\n
libdeno/deno.gniの中にtool = \"//libdeno:snapshot_creator\"と指定があるように、V8 スナップショットを生成するファイルはlibdeno/snapshot_create.ccです。main 関数に渡される引数はビルド定義を読んでみると第一引数が出力先（gen/snapshot_deno.bin）のパス、第二引数が スナップショットを取りたい js（bundle/main.js）のパスになっていました。\nmain 関数の内部処理としては、deno_executeで与えられた js（bundle/main.js）を実行した結果の Isolate Context の スナップショットをdeno_get_snapshotで取得し、指定されたパス（gen/snapshot_deno.bin）に保存するという感じです。
\n
inputs = [\n invoker.source_root,\n ]\n\n outputs = [\n snapshot_out_bin,\n ]\n args = rebase_path(outputs, root_build_dir) +\n rebase_path(inputs, root_build_dir)なお前触れなく登場したbundle/main.jsとはrollupで生成された Deno の TypeScript のコード bundle した生成物です。
$ head -n5 target/debug/gen/bundle/main.js\nvar denoMain = (function () {\n 'use strict';\n\n var runner = /*#__PURE__*/Object.freeze({\n get Runner () { return Runner; }ここからさらにビルド周りを深追いしていくと submodule になっているdenoland/chromium_buildなどの別リポジトリにたどり着くのですが、ビルドプロセスを深堀りしすぎると本筋から逸脱するのでこれぐらいにします。
\nisolate::Isolate::newもIsolateStateと同じくsrc/isolate.rsに定義されています。
\n渡している引数は上の行で生成した V8 snapshot、２つ上の行で生成した IsolateState、opt::dispatchの３つです。opt::dispatchに関してはひとまずこちらを参照。後々denoMain関数を実行するあたりでまた出てきます。
\n\n第三引数の dispatch ってなんだ、と思ったらコメントに色々書いてある。
\n\n
\njs からの来る諸々を Rust で捌いてる部分っぽく見える。
isolate::Isolate::newのアウトラインは、
libdeno::deno_init()で初期化libdeno::deno_configのインスタンスを生成deno_configをdeno_newに渡してlibdeno_isolateのインスタンスを生成という感じになっています。
\nlibdeno::deno_init()は V8 の初期化をしています。
deno_newはlibdeno/api.ccに定義されています。
\n先程のスナップショットを生成する処理でも登場しており、そのときはwill_snapshotが 1、load_snapshotがdeno::empty_bufになっていました。今回はdeno_newにwill_snapshotを 0、load_snapshotに生成された スナップショットを指定しています。それぞれの値の違いによる処理の分岐はこのあたりを見れば明らかかと思います。
\n
Deno* deno_new(deno_config config) {\n if (config.will_snapshot) {\n return deno_new_snapshotter(config);\n }\n deno::DenoIsolate* d = new deno::DenoIsolate(config);\n v8::Isolate::CreateParams params;\n params.array_buffer_allocator = d->array_buffer_allocator_;\n params.external_references = deno::external_references;\n\n if (config.load_snapshot.data_ptr) {\n params.snapshot_blob = &d->snapshot_;\n }スナップショットを用いてV8::Isolateのインスタンスを作ってスコープ設定して…とわちゃわちゃやってますが、このあたりは V8 自体の説明になってしまうので割愛します。この記事とガイドにて丁寧な解説されているので理解の助けになると思います。
\n\n\n
\n\nThere are 2 important functions/constructors used in deno_new that might not be immediately clear: DenoIsolate and InitializeContext. It turns out DenoIsolate serves more or less as a collection of Isolate information. Instead, InitializeContext is the more interesting one.
\n\n
denoMain関数を実行\n
// Setup runtime.\n isolate\n .execute(\"denoMain();\")\n .unwrap_or_else(print_err_and_exit);ここですね。isolate.execute自体はごくシンプルで、内部でibdeno::deno_executeを読んでるだけです。
\n\nCString って C にわたす FFI 呼ぶときによく見るやつだ。 実質
\n\nlibdeno::deno_execute()へのファサードになっている。
\n\nThe only interesting function we care in this section is libdeno::deno_execute. We can find its actual definition in libdeno/api.cc again:
\n\n
deno_executeは スナップショット作るところで１度登場していますが、そこでは読み飛ばしたので詳しく読んでみます。V8 Context を作ってdeno::Executeに渡してます。
deno::Executeはlibdeno/binding.ccに定義されています。
\nおおまかな流れとしては渡された文字列をv8::Script::Compileでコードをコンパイルし、エラーがなければLocal<Script>->Run(context)でコードを実行して、エラーチェックして終わりです。
\n
bool Execute(v8::Local<v8::Context> context, const char* js_filename,\n const char* js_source) {\n auto* isolate = context->GetIsolate();\n v8::Isolate::Scope isolate_scope(isolate);\n v8::HandleScope handle_scope(isolate);\n v8::Context::Scope context_scope(context);\n\n auto source = v8_str(js_source, true);\n auto name = v8_str(js_filename, true);\n\n v8::TryCatch try_catch(isolate);\n\n v8::ScriptOrigin origin(name);\n\n auto script = v8::Script::Compile(context, source, &origin);\n\n if (script.IsEmpty()) {\n DCHECK(try_catch.HasCaught());\n HandleException(context, try_catch.Exception());\n return false;\n }\n\n auto result = script.ToLocalChecked()->Run(context);\n\n if (result.IsEmpty()) {\n DCHECK(try_catch.HasCaught());\n HandleException(context, try_catch.Exception());\n return false;\n }\n\n return true;\n}まとめると、isolate.execute(\"denoMain();\")はdenoMain();という文字列（JavaScript のコード）を V8 でコンパイルして実行しています。
\nいきなりdenoMain関数を呼び出してますがdenoMainとはどこから来たのでしょうか。これまでのコードでは denoMain 関数を定義するようなコードは登場しませんでした。おそらく V8 スナップショットから復元されています。
\nあらかじめdenoMainの関数定義を含んだ bundle/main.js を実行した結果をスナップショットとして保存し、それを使って Isolate を復元しているのでdenoMain関数が呼べるようになっています。
\n\n前触れなく登場している
\nbundle/main.jsとは、js の bundler の１つであるrollupで生成されたdenoMain関数を含む deno の js レイヤのコードです。
引用したこのあたりです。demoMain 関数を呼び出せる仕組みがわかったので denoMain について詳しく読んでみます。
\n\n
export default function denoMain() {\n\n要はここまでやって v8 が起動していることがわかった。じゃあどういうスクリプトが起動しているのか。
\n\n
やっと Deno の TypeScript のレイヤにたどり着けました。といっても実際には rollup で bundle された JavaScript が実行されており TypeScript を直接実行しているわけではありません。
\ndenoMain関数が定義されているjs/main.tsは大きく分けて３パートに分かれています。
denoMainは（コマンドライン）引数を処理して、sendStartをコールするなどの然るべき初期化を行います。
\nsendStartはsendSyncという関数を用いて js レイヤの初期化が開始したことを C++レイヤへ通知しています。
\ncompilerMainはここでは呼び出されていません。関数定義だけして window オブジェクトのプロパティにセットしています。この関数は後々 ts をコンパイルするところで再び登場します。
\n
libdeno.recv(handleAsyncMsgFromRust);denoMain 関数の冒頭にあるlibdeno.recvとhandleAsyncMsgFromRustは、イベントリスナとイベントハンドラのようなものです。
libdenoオブジェクト\n\nFirst, we tell libdeno, which is the exposed API from the middle-end, that whenever there is a message sent from the Rust side, please forward the buffer to a function called handleAsyncMsgFromRust. Then, a Start message is sent to Rust side, signaling that we are starting and receiving information including the current working directory, or cwd. We then decide whether the user is running a script, or using the REPL. If we have an input file name, Deno would then try to let the runner, which contains the TypeScript compiler, to try running the file (going deep into its definition, you’ll eventually find a secret eval/globalEval called somewhere). denoMain only exits when the runner finish running the file.
\n\n
denoMain の中にlibdenoという名前空間的なオブジェクトが登場しますが、このオブジェクトの定義はjs/libdeno.tsには存在しません。どこかで事前に作られています。
\nlibdeno オブジェクトはlibdeno/api.ccのdeno_new関数の内部処理で読み飛ばしたInitializeContextにて C++から V8 を直接操作して生成されています。
\n
auto deno_val = v8::Object::New(isolate);\n CHECK(global->Set(context, deno::v8_str(\"libdeno\"), deno_val).FromJust());これでlibdenoという空オブジェクトを作成し、その中にprint, recv, sendメソッドの実装をセットしています。
\n
auto print_tmpl = v8::FunctionTemplate::New(isolate, Print);\n auto print_val = print_tmpl->GetFunction(context).ToLocalChecked();\n CHECK(deno_val->Set(context, deno::v8_str(\"print\"), print_val).FromJust());\n\n auto recv_tmpl = v8::FunctionTemplate::New(isolate, Recv);\n auto recv_val = recv_tmpl->GetFunction(context).ToLocalChecked();\n CHECK(deno_val->Set(context, deno::v8_str(\"recv\"), recv_val).FromJust());\n\n auto send_tmpl = v8::FunctionTemplate::New(isolate, Send);\n auto send_val = send_tmpl->GetFunction(context).ToLocalChecked();\n CHECK(deno_val->Set(context, deno::v8_str(\"send\"), send_val).FromJust());見ての通りこの３つの実装は C++で定義されており、V8 を操作して C++の関数ポインタを js 側に露出しています。
\nprintはここで定義されており、ざっくりまとめるとSTDOUTもしくはSTDERRのどちらかに渡された引数を fwrite している。要は printf 的なものです。
\nrecvはここに定義されており、ざっくりまとめると渡された引数を関数としてキャストし、DenoIsolate のrecv_プロパティにコールバック関数としてセットしています。
\nsendはここに定義されています。src/isolate.rsの中でdeno_new関数の中で渡しているdeno_configのrecv_cbがDenoIsolateに渡っており、結果的にpre_dispatchという Rust の関数が呼び出されます。
\nという C++（Rust）レイヤとやりとりするためのlibdenoオブジェクトが定義されていました。
Send に関してはガイドの説明も併せて参照してください。
\n\n\nThe Send function get args and invoke the recvcb . Notice that the recvcb is defined in the Rust code.
\n\n
denoMainが実行され、Deno ランタイムの準備が整いました。
\n再び Rust の main 関数に話題を戻し、次はファイルパスがコマンドライン引数として与えられてるときisolate.execute_modが呼び出されるあたりを読みます。
\nこれまでも FFI で C++, Rust, js と複数レイヤをまたぐコードが多かったですが、ここから先も複雑かつ長いので、休憩しつつ読まれるといいと思います。
\n
// Execute input file.\n if isolate.state.argv.len() > 1 {\n let input_filename = &isolate.state.argv[1];\n isolate\n .execute_mod(input_filename, should_prefetch)\n .unwrap_or_else(print_err_and_exit);\n }isolate.execute_modはsrc/isolate.rsに定義されています。
\nisolate.executeと同じ要領でdeno_execute(filename, ファイルの中身)と実行するのかと思いましたが、違いました。内部で呼び出されているcode_fetch_and_maybe_compileという関数とlibdeno::deno_execute_modが気になります。まずcode_fetch_and_maybe_compileから読んでみます。
\n
/// Executes the provided JavaScript module.\n pub fn execute_mod(\n &self,\n js_filename: &str,\n is_prefetch: bool,\n ) -> Result<(), JSError> {\n let out =\n code_fetch_and_maybe_compile(&self.state, js_filename, \".\").unwrap();\n\n let filename = CString::new(out.filename.clone()).unwrap();\n let filename_ptr = filename.as_ptr() as *const i8;\n\n let js_source = CString::new(out.js_source().clone()).unwrap();\n let js_source = CString::new(js_source).unwrap();\n let js_source_ptr = js_source.as_ptr() as *const i8;\n\n let r = unsafe {\n libdeno::deno_execute_mod(\n self.libdeno_isolate,\n self.as_raw_ptr(),\n filename_ptr,\n js_source_ptr,\n if is_prefetch { 1 } else { 0 },\n )\n };\n if r == 0 {\n let js_error = self.last_exception().unwrap();\n return Err(js_error);\n }\n Ok(())\n }code_fetch_and_maybe_compileはsrc/isolate.rsに定義されています。
\n
fn code_fetch_and_maybe_compile(\n state: &Arc<IsolateState>,\n specifier: &str,\n referrer: &str,\n) -> Result<CodeFetchOutput, DenoError> {\n let mut out = state.dir.code_fetch(specifier, referrer)?;１行目のstate.dir.code_fetchは型定義を読んでみるとdeno_dir::DenoDirというメソッドです。src/deno_dir.rsに定義されています。DenoDir#code_fetchのアウトラインとしては、
resolve_moduleでモジュールのファイルパス（か URL）を解決get_source_codeで/https?/で始まるならfetch_remote_source、それ以外ならfetch_local_sourceを使用して TypeScript のコードを取得filter_shebangで shebang を取り除いてload_cacheでコンパイル後の JavaScript とその Source Map を手に入れるとなっております。
\nここから先resolve_moduleやそれ以外の箇所でspecifier、referrerという変数がよく登場します。specifierはモジュールの名前・パス解決の処理全般で、import fromに記載した文字列（もしくはコマンドライン引数で与えたファイルパス）を現しています。referrerは import が記載されているファイルの絶対パス（もしくは URL）と念頭に置いておくとコードが読みやすいと思います。
\nget_source_codeにてローカルかリモートかにかかわらず返却されているCodeFetchOutput型の構造は以下のとおりです。
module_name: specifierfilename: 解決できたファイル名（もしくは URL）media_type: msg::MediaType::TypeScript、msg::MediaType::JavaScript、msg::MediaType::Json、msg::MediaType::Unknownのいずれかsource_code: ファイル内容maybe_output_code: （fetch_local_sourceの場合常に None）maybe_source_map: （fetch_local_sourceの場合常に None）ローカルのファイルパスを解決するfetch_local_sourceの面白い挙動としては、ファイル名.mimeというファイルがもし置かれていれば、そのメディアタイプとして解釈する挙動になっています。ローカルファイルでこれをわざわざやる必要は無さそうですが、リモートのファイルとを取ってくるときに Content-Type ヘッダの値を格納しておくという使い方をしています。
\nなお.mimeファイルがなければファイルの拡張子ごとにあらかじめ定義されているタイプとして解釈します。例えば.tsは TypeScript として解釈します。
リモートの URL を解決するfetch_remote_sourceではソースを HTTP GET してきて、URL 末尾の拡張子に対応するメディアタイプと、レスポンスヘッダのContent-Typeヘッダを比較し、もし食い違っていたら前述の.mimeタイプを作成し拡張子よりもContent-Typeの値をリスペクトするという処理になってます。
\n
eprint!(\"Downloading {}...\", &module_name); // no newline\n let maybe_source = http_util::fetch_sync_string(&module_name);\n if let Ok((source, content_type)) = maybe_source {\n eprintln!(\"\"); // next line\n match p.parent() {\n Some(ref parent) => fs::create_dir_all(parent),\n None => Ok(()),\n }?;\n deno_fs::write_file(&p, &source, 0o666)?;\n // Remove possibly existing stale .mime file\n // may not exist. DON'T unwrap\n let _ = std::fs::remove_file(&media_type_filename);\n // Create .mime file only when content type different from extension\n let resolved_content_type = map_content_type(&p, Some(&content_type));\n let ext = p\n .extension()\n .map(|x| x.to_str().unwrap_or(\"\"))\n .unwrap_or(\"\");\n let media_type = extmap(&ext);\n if media_type == msg::MediaType::Unknown\n || media_type != resolved_content_type\n {\n deno_fs::write_file(&mt, content_type.as_bytes(), 0o666)?\n }コードを取得するための HTTP クライアントはhyperというものを利用していました。低レベルだけど高速に動作する HTTP クライアントのようです。例えばリダイレクトのフォローを自前で書かないといけないくらいシンプルなクライアントです。コードにも TODO が書かれているんですが、現在のコードでは最大リダイレクト数が設定されておらず、リダイレクトループが発生するとハングするコードになってます。
\n\n
// TODO(kevinkassimo): consider set a max redirection counter\n // to avoid bouncing between 2 or more urlsTypeScript のコードの取得は完了しました。次に V8 で実行できるように JavaScript にコンパイルする必要があります。\ncode_fetch_and_maybe_compileのDenoDir::code_fetchを読みきったので続きを読んでいきます。
\n
fn code_fetch_and_maybe_compile(\n state: &Arc<IsolateState>,\n specifier: &str,\n referrer: &str,\n) -> Result<CodeFetchOutput, DenoError> {\n let mut out = state.dir.code_fetch(specifier, referrer)?;\n if (out.media_type == msg::MediaType::TypeScript\n && out.maybe_output_code.is_none())\n || state.flags.recompile\n {\n debug!(\">>>>> compile_sync START\");\n out = compile_sync(state, specifier, &referrer).unwrap();\n debug!(\">>>>> compile_sync END\");\n }\n Ok(out)\n}わかりやすくログが出てますが、compile_syncが ts を js にコンパイルする関数ですね。compile_syncの中身も追います。
\n
pub fn compile_sync(\n parent_state: &Arc<IsolateState>,\n specifier: &str,\n referrer: &str,\n) -> Option<CodeFetchOutput> {\n let req_msg = req(specifier, referrer);\n\n let compiler = lazy_start(parent_state);\n\n let send_future = resources::worker_post_message(compiler.rid, req_msg);\n send_future.wait().unwrap();\n\n let recv_future = resources::worker_recv_message(compiler.rid);\n let res_msg = recv_future.wait().unwrap().unwrap();\n\n let res_json = std::str::from_utf8(&res_msg).unwrap();\n CodeFetchOutput::from_json(res_json)\n}内部で呼び出されているlazy_startと、更にその中でコールされているworker::spawnも追います。
\n
fn lazy_start(parent_state: &Arc<IsolateState>) -> Resource {\n let mut cell = C_RID.lock().unwrap();\n let rid = cell.get_or_insert_with(|| {\n let resource =\n workers::spawn(parent_state.clone(), \"compilerMain()\".to_string());\n resource.rid\n });\n Resource { rid: *rid }\n}\n
pub fn spawn(\n state: Arc<IsolateState>,\n js_source: String,\n) -> resources::Resource {\n // TODO This function should return a Future, so that the caller can retrieve\n // the JSError if one is thrown. Currently it just prints to stderr and calls\n // exit(1).\n // let (js_error_tx, js_error_rx) = oneshot::channel::<JSError>();\n let (p, c) = oneshot::channel::<resources::Resource>();\n let builder = thread::Builder::new().name(\"worker\".to_string());\n let _tid = builder\n .spawn(move || {\n let (worker, external_channels) = Worker::new(&state);\n\n let resource = resources::add_worker(external_channels);\n p.send(resource.clone()).unwrap();\n\n tokio_util::init(|| {\n (|| -> Result<(), JSError> {\n worker.execute(\"denoMain()\")?;\n worker.execute(\"workerMain()\")?;\n worker.execute(&js_source)?;\n worker.event_loop()?;\n Ok(())\n })().or_else(|err: JSError| -> Result<(), JSError> {\n eprintln!(\"{}\", err.to_string());\n std::process::exit(1)\n }).unwrap();\n });\n\n resource.close();\n }).unwrap();\n\n c.wait().unwrap()\n}worker::spawn の中worker.executeにてdenoMain(), workerMain(), 引数で渡されたコードを実行するようになっています。引数で渡されたコードは何かというとlazy_startを見ての通りcompilerMain()です。
\nWorker は main 関数で生成された V8 Isolate とは隔離された別の Isolate を生成しています。この Isolate もまたスナップショットから復元されているので高速です。\nこれら３つの関数が実行されたあとに、req 関数で生成したspecifierとreferrerを worker に送信し、TypeScript のコンパイルを実行します。
次にcompilerMainの定義を追ってみます。
\n
// provide the \"main\" function that will be called by the privilaged side when\n// lazy instantiating the compiler web worker\nwindow.compilerMain = function compilerMain() {\n // workerMain should have already been called since a compiler is a worker.\n const encoder = new TextEncoder();\n const decoder = new TextDecoder();\n compiler.recompile = startResMsg.recompileFlag();\n log(`recompile ${compiler.recompile}`);\n window.onmessage = ({ data }: { data: Uint8Array }) => {\n const json = decoder.decode(data);\n const lookup = JSON.parse(json) as CompilerLookup;\n\n const moduleMetaData = compiler.compile(lookup.specifier, lookup.referrer);\n\n const responseJson = JSON.stringify(moduleMetaData);\n const response = encoder.encode(responseJson);\n postMessage(response);\n };\n};Compiler の compile メソッドはjs/compiler.tsに定義されています。コードがやや長いので引用はしません。
\n大まかな処理内容としては、typescriptモジュールを使ってコンパイルしたり型検査したりしてます。JSON に関してはjsonEsmTemplateという薄いラッパーを噛ませて独自コンパイルしています。それ以外（TypeScript, JavaScript）に関しては、LanguageService のgetEmitOutputを用いてソースマップとコンパイル後の JavaScript を入手し、その後に型検査 etc を実行しもしエラーがあれば異常終了、エラーがなければ JavaScript にソースマップをくっつけてキャッシュに書き込んで完了という処理になっています。
\n検査する項目は独自に絞って処理の高速化を図っています。このやり方のほうが 3 倍ほど通常の検査より高速だそうです。
\n
// Get the relevant diagnostics - this is 3x faster than\n // `getPreEmitDiagnostics`.\n const diagnostics = [\n // TypeScript is overly opinionated that only CommonJS modules kinds can\n // support JSON imports. Allegedly this was fixed in\n // Microsoft/TypeScript#26825 but that doesn't seem to be working here,\n // so we will ignore complaints about this compiler setting.\n ...service\n .getCompilerOptionsDiagnostics()\n .filter(diagnostic => diagnostic.code !== 5070),\n ...service.getSyntacticDiagnostics(fileName),\n ...service.getSemanticDiagnostics(fileName)\n ];なお TypeScript の LanguageService の詳しい説明は公式の wikiにあったのでそちらを参照して下さい。
\nJavaScript へのコンパイルが完了し、ようやく指定されたモジュールを実行できるようになりました。最後にlibdeno::deno_execute_modを読みます。libdeno::deno_execute_modはlibdeno/api.ccに定義されています。実質的な処理はdeno::ExecuteModに書いてあります。deno::ExecuteModはlibdeno/binding.ccに定義されています。V8 で JavaScript のコードを実行するくだりはdeno::Executeのときに書いた説明を参照して下さい。
\n
auto maybe_module = CompileModule(context, js_filename, source);\n\n if (maybe_module.IsEmpty()) {\n DCHECK(try_catch.HasCaught());\n HandleException(context, try_catch.Exception());\n return false;\n }\n DCHECK(!try_catch.HasCaught());\n\n auto module = maybe_module.ToLocalChecked();\n auto maybe_ok = module->InstantiateModule(context, ResolveCallback);\n if (maybe_ok.IsNothing()) {\n return false;\n }\n\n CHECK_EQ(v8::Module::kInstantiated, module->GetStatus());\n\n if (resolve_only) {\n return true;\n }\n\n auto result = module->Evaluate(context);ここまでの内容で、deno コマンドを実行し、TypeScript が実行されるまでの処理が追えたと思います。
\n$ cat tests/002_hello.ts\nconsole.log(\"Hello World\");\n\n$ ./target/debug/deno tests/002_hello.ts\nHello World実行されるすべての行を網羅したわけではありませんが、ビルドプロセスも含めて一連の流れを追えたと思います。Rust、C++、TypeScript とレイヤをまたぐ処理がかなり多いので、わかってしまえばすんなり読めますが、初見はかなり大変でした。
\nC++は V8 以外の処理をなるべく書かず意図的に Rust 側に寄せているように感じました。Rust で書いたほうが自分の足を撃ちにくいプログラムになると思うので、これが功を奏すのかどうか、1~2 年後が楽しみです。
記事内ではあまり触れてませんが、コードを読んでる過程で TODO や FIXME コメントが大量に見つかったので、Deno コアに対するコントリビュートのネタは、コード読むとたくさん見つかると思います。
\n他にも Worker の実装、セキュリティモデルの実装、TypeScript 製の外部モジュールの依存解決、イベントループや TaskQueue 関連の Node.js との差異、ビルドプロセスの詳細など、まだまだ読みたい Deno のコードがあるので、読んで理解できたら記事書きます。
","timeToRead":47,"frontmatter":{"title":"Dive into Deno：プロセス起動からTypeScriptが実行されるまで","tags":["JavaScript","TypeScript","Rust","Deno"],"date":"January 19, 2019","featuredImage":null}}},"pageContext":{"slug":"/code-reading-of-deno-boot-process/","previous":{"fields":{"slug":"/benchmark-of-lazy-frame-loading/"},"frontmatter":{"title":"ChromeのBlink LazyLoadを有効にしたらページのロード時間が約10倍早くなった","tags":["JavaScript","Google Chrome"]}},"next":{"fields":{"slug":"/what-benefit-of-intl-number-format/"},"frontmatter":{"title":"Intl.NumberFormatでゼロ埋めや％表記などの数値表現を楽に実装する","tags":["JavaScript","Node.js"]}}}}, "staticQueryHashes": ["2585454260","2954598359"]}