これらは私が掘り起こすことができた詳細です。JavaScriptは通常VMで解釈および実行されると見なされますが、ソースを直接マシンコードにコンパイルする傾向がある最近のインタープリターでは、これは実際には当てはまりません（IEを除く）。
Chrome：V8エンジン
V8にはコンパイルキャッシュがあります。これは、最大5つのガベージコレクションのソースのハッシュを使用して、コンパイルされたJavaScriptを格納します。つまり、2つの同一のソースコードは、どのように含まれているかに関係なく、メモリ内のキャッシュエントリを共有します。このキャッシュは、ページが再ロードされてもクリアされません。
ソース
更新-2015年3月19日
Chromeチームは、JavaScriptのストリーミングとキャッシングに関する新しい手法の詳細をリリースしました。
- スクリプトストリーミング
スクリプトストリーミングは、JavaScriptファイルの解析を最適化します。[...]
Chromeはバージョン41以降、ダウンロードが開始されるとすぐに、非同期スクリプトと遅延スクリプトを別のスレッドで解析します。つまり、ダウンロードが完了してからわずか数ミリ秒で解析が完了し、ページの読み込みが10％も速くなります。
- コードキャッシング
通常、V8エンジンはアクセスのたびにページのJavaScriptをコンパイルし、プロセッサーが理解できる命令に変換します。コンパイルされたコードはコンパイル時のマシンの状態とコンテキストに大きく依存するため、ユーザーがページから移動すると、このコンパイルされたコードは破棄されます。
Chrome 42では、コンパイルされたコードのローカルコピーを保存する高度な手法が導入されているため、ユーザーがページに戻ったときに、ダウンロード、解析、およびコンパイルの手順をすべてスキップできます。これにより、すべてのページ読み込みで、Chromeはコンパイル時間の約40％を回避でき、モバイルデバイスの貴重なバッテリーを節約できます。
Opera：キャラカンエンジン
実際には、これは、ソースコードが最近コンパイルされた他のプログラムのソースコードと同じであるスクリプトプログラムをコンパイルしようとするときはいつでも、コンパイラーからの以前の出力を再利用し、コンパイル手順を完全にスキップすることを意味します。このキャッシュは、ニュースサービスからの異なるニュース記事など、同じサイトからページごとにロードする典型的なブラウジングシナリオで非常に効果的です。
したがって、JavaScriptはページの再読み込み時にキャッシュされます。同じスクリプトに対する2つの要求は、再コンパイルにつながりません。
ソース
Firefox：SpiderMonkeyエンジン
SpiderMonkeyはNanojit、JITコンパイラをネイティブバックエンドとして使用します。マシンコードをコンパイルするプロセスはここにあります。要するに、ロードされたスクリプトを再コンパイルするように見えます。しかし、私たちはよく見とるの内部でNanojit我々をより高いレベルの監視ことがわかりjstracerコンパイルを追跡するために使用され、に利益を提供し、コンパイル時に3つの段階を経て移行することができますNanojit：
トレースモニターの初期状態は監視です。これは、spidermonkeyがバイトコードを解釈していることを意味します。spidermonkeyが後方ジャンプバイトコードを解釈するたびに、モニターはジャンプ先のプログラムカウンター（PC）値がジャンプされた回数を記録します。この数は、PCのヒットカウントと呼ばれます。特定のPCのヒットカウントがしきい値に達すると、ターゲットはホットと見なされます。
モニターは、ターゲットPCがホットであると判断すると、フラグメントのハッシュテーブルを調べて、そのターゲットPCのネイティブコードを保持するフラグメントがあるかどうかを確認します。そのようなフラグメントが見つかると、実行モードに移行します。それ以外の場合は、記録モードに移行します。
つまりhot、コードのフラグメントの場合、ネイティブコードがキャッシュされます。再コンパイルする必要がないことを意味します。これらのハッシュされたネイティブセクションがページの更新間で保持されるかどうかは明確にされていません。しかし、そうだと思います。誰かがこれを裏付ける証拠を見つけることができれば、それは素晴らしいことです。
編集：Mozilla開発者のBoris Zbarskyが、Geckoはまだコンパイル済みスクリプトをキャッシュしないと述べていることが指摘されています。このSOの答えから取られた。
Safari：JavaScriptCore / SquirelFishエンジン
この実装の最良の答えはすでに他の誰かによって与えられていると思います。
現在、バイトコード（またはネイティブコード）をキャッシュしていません。これは
私たちが検討したオプションですが、現在、コード生成は
JS実行時間のごく一部（<2％）であるため
、現時点ではこれを追求していません。
これは、Safariの主要開発者であるMaciej Stachowiakによって書かれました。だから私たちはそれが真実であると考えることができると思います。
私は他の情報を見つけることができませんでしたが、あなたは、最新の速度の向上について詳しく読むことができるSquirrelFish Extremeエンジンここでは、あるいはソースコードを閲覧し、ここであなたは冒険を感じている場合。
IE：チャクラエンジン
この分野のIE9のJavaScriptエンジン（チャクラ）に関する現在の情報はありません。誰か知っていることがあればコメントしてください。
これは非常に非公式ですが、IEの古いエンジン実装では、Eric Lippert（JScriptのMS開発者）がブログの返信で次のように述べています。
JScript Classicは、JScript Classicプログラムが実行される前に、コードの完全な構文チェック、完全な解析ツリーの生成、およびバイトコードの生成という意味で、コンパイルされた言語のように機能します。次に、バイトコードインタープリターを介してバイトコードを実行します。その意味で、JScriptはJavaと同じくらい「コンパイル」されています。違いは、JScriptでは独自のバイトコードを永続化または検査できないことです。また、バイトコードはJVMバイトコードよりもはるかに高レベルです。JScriptクラシックバイトコード言語は解析ツリーの線形化に過ぎませんが、JVMバイトコードは明らかに低レベルのスタックマシンでの動作を目的としています。
これは、バイトコードが永続化されないため、バイトコードがキャッシュされないことを示唆しています。