dmikurube
commented
1 year ago その他参考文献など (時系列はぐちゃぐちゃです)
- https://hacks.mozilla.org/2019/08/the-baseline-interpreter-a-faster-js-interpreter-in-firefox-70/
- https://www.cs.cornell.edu/courses/cs6120/2020fa/blog/tracemonkey/
- https://zon8.re/posts/jsc-internals-part2-the-llint-and-baseline-jit/
- https://blog.mozilla.org/javascript/2013/04/05/the-baseline-compiler-has-landed/
- https://docs.google.com/document/d/11T2CRex9hXxoJwbYqVQ32yIPMh0uouUZLdyrtmMoL44/preview
- https://wingolog.org/archives/2013/04/18/inside-full-codegen-v8s-baseline-compiler
こういう背景があるので、「方式の説明はほどほどに、話題になったエンジンの固有名詞 (*Monkey とか) と、当時のベンチマークの紹介程度に留めておいたほうがいいような気はしますね」と提案した次第です。
piroor
このあたり https://twitter.com/dmikurube/status/1631476823883386881 の会話から、とりあえずわかる範囲で書き起こしてみます。そのあたりの詳細まで踏み込む「文案」として書きくだせるほどには、私も { 知らない | 覚えていない } ので、指摘という範囲に留まりますが…。
"Baseline JIT"
まず "Baseline JIT" という用語・表現とその説明についてですが、この "Baseline" というのは「個別の判断を行わずにほどほどの最適化度合いでとにかく幅広くコンパイルしてしまう『Baseline 方式』」という「特定の方式」のことではないと思います。
「その後の実行時情報を使った実行時最適化をかけ始める前に、読み込んだ直後に実行時情報なしでとりあえずかけるコンパイル」「その後の実行時最適化をかける前の、その処理系の最適化プロセスにおける、文字通りの "baseline"」というような意味合いでしょうか。
「×× 方式」という表現を使うなら、たとえば「V8 のバージョン x.y はその Baseline (JIT) として ×× 方式を採用している」というような使い方になると思います。
もっとも、実行時情報がない以上は、あまり多種多様な方式があるわけではなさそうですが。とはいえ "V8 is replacing its baseline JIT with an interpreter" みたいな表現をされた例もあります ↓
https://www.reddit.com/r/javascript/comments/3ggjai/v8_is_replacing_its_baseline_jit_with_an/
その "Baseline" の後に、しばらく実行を経たあとで行われるような「実行寺情報を使った実行時最適化をともなう JIT コンパイル」一般のことは、あまり特定の定まった用語がある認識はないですが、だいたい "optimizing JIT compile" とか、日本語なら「(実行時) 最適化 JIT コンパイル」とか呼ばれているものと思います。
"Tracing (Trace) JIT"
記事中で "Baseline JIT" と対比する形で "Trace (Tracing) JIT" の説明として述べられている「インタープリタでの実行を監視して統計情報を収集し、特に高い頻度で実行される箇所を選択的に高い最適化度合いでコンパイルする」というのは、どちらかといえば "Tracing JIT" ではなく、上の「実行時最適化 JIT コンパイル」の一般的な説明に当たります。
では "Tracing JIT" はなにかといえば、この「最適化 JIT コンパイル」の中の「一方式」です。
(ちょっと間違いを含みそうな説明ですがすごく大雑把に言うと) それまで最適化 JIT コンパイルといえば、メソッド単位の実行回数などを見てメソッド単位でコンパイルする "Method JIT" が主でした。 "Tracing JIT" は Method JIT のようなメソッド境界にこだわらず、コードが実際に実行されたパス (trace) に沿ってコンパイルする方式のことです。
Method JIT も Tracing JIT も、どちらも「インタープリタでの実行を監視して統計情報を収集し、特に高い頻度で実行される箇所を選択的に高い最適化度合いでコンパイルする」方式なので、これを Tracing JIT の説明として当てはめるのは適切ではないと思います。
V8 は実際どうだったのか
という話になると、特に時系列をともなう歴史においては、正直よく覚えていません。最初期の V8 は「Baseline JIT コンパイラである "full-codegen" しか持たない (実行時最適化 JIT コンパイルはしない)」方式だったような気もしますが、少なくともその後に (それでも今からすればだいぶ昔に) 入った Crankshaft は「実行時最適化 JIT コンパイラ」の一種ですね。大枠としては Method JIT に分類されるんじゃなかったかと思います。
https://blog.chromium.org/2010/12/new-crankshaft-for-v8.html
で、上の Tracing JIT の説明を読むとわかると思うのですが Method JIT と Tracing JIT はそんなにきっちり切り分けられるものでもありません。「基本線は Method JIT なんだけどちょっと Tracing JIT 的な要素も取り入れている」ようなものもありますし、すでに近年はそんな感じが主流じゃないかな、と思います。
とはいえ、最初に Tracing JIT を搭載した Firefox とその論文なんかが出たころは、まだ Tracing JIT は、提案はされていても研究レベルが主だったように思います。 Firefox が Tracing JIT の実用レベル・大規模な初期の適用例だったこともあって、コンパイラ業界でも、たしかにわりと衝撃的に驚きを持って迎えられていたような記憶があります。
Tracing JIT はダメだったのか
みたいな話になると、いまだに結論は出ていないし、部分的な要素としてはすでに各種のエンジンに入っていたりもするので、なんとも言えないんじゃないでしょうか。
JIT コンパイル技術が初期に発展したのは特に Java VM においてで、特にサーバサイドにおいてのことでした。サーバサイドでは一般にプロセスが長寿命になりがちなので、リソースを JIT コンパイルに割く意義が大きかったという背景があったと考えられます。
ブラウザの文脈になると、一つのページを開いている時間はサーバプロセスに比べれば短くなりがちなので、あまりコストを割かずにほどほどの最適化で済ませたほうがいいね、みたいな背景はあるかもしれません。そのあたりは論文なんかもいろいろあさらないと、最近の議論もわからないなあ、と思います。