JavaScriptエンジンの基本：一般的なフォームとインラインキャッシュ。 パート1

こんにちは友人。 4月末に、新しいコース「情報システムセキュリティ」を開始します。 そして今、私たちはあなたと記事の翻訳を共有したいと思います。それはもちろんコースにとって非常に役立つでしょう。 元の記事はこちらにあります 。

この記事では主要な基盤について説明します。これらはすべてのJavaScriptエンジンに共通であり、エンジンの作成者（ BenedictおよびMatias ）が取り組んでいるV8だけに共通するものではありません。 JavaScript開発者として、JavaScriptエンジンの動作をより深く理解することは、効率的なコードを記述する方法を見つけるのに役立つと言えます。

注 ：記事を読むよりもプレゼンテーションを見たい場合は、このビデオをご覧ください 。 そうでない場合は、スキップして読み進めてください。

パイプライン（パイプライン）JavaScriptエンジン

それはすべて、JavaScriptコードを書くという事実から始まります。 その後、JavaScriptエンジンはソースコードを処理し、抽象構文ツリー（AST）として提示します。 構築されたASTに基づいて、インタプリタは最終的に作業に取り掛かり、バイトコードの生成を開始できます。 いいね！ これは、エンジンがJavaScriptコードを実行する瞬間です。



より高速に実行するために、プロファイリングデータとともに最適化コンパイラにバイトコードを送信できます。 最適化コンパイラは、プロファイリングデータに基づいて特定の仮定を行い、高度に最適化されたマシンコードを生成します。

ある時点で仮定が間違っていることが判明した場合、最適化コンパイラーはコードを最適化解除し、インタープリターステージに戻ります。

JavaScriptエンジンのインタープリターパイプライン/コンパイラー

ここで、JavaScriptコードを実行するパイプラインの部分、つまりコードが解釈および最適化される部分、および主要なJavaScriptエンジン間のいくつかの違いを詳しく見てみましょう。

すべての中心にあるのは、インタープリターと最適化コンパイラーを含むパイプラインです。 インタープリターは最適化されていないバイトコードを迅速に生成し、最適化コンパイラーはより長く動作しますが、出力は高度に最適化されたマシンコードを持ちます。



次は、ChromeとNode.jsで使用されるJavaScriptエンジンであるV8の動作を示すパイプラインです。



V8のインタープリターはIgnitionと呼ばれ、バイトコードの生成と実行を担当します。 バイトコードの処理中に次のステップで実行を高速化するために使用できるプロファイリングデータを収集します。 たとえば、関数が頻繁に起動する場合、関数がhotになると、生成されたバイトコードとプロファイリングデータがTurboFan、つまり最適化コンパイラに転送され、プロファイリングデータに基づいて高度に最適化されたマシンコードが生成されます。



たとえば、FirefoxとSpiderNodeで使用されるMozillaのSpiderMonkey JavaScriptエンジンは、少し異なる動作をします。 1つではなく、2つの最適化コンパイラがあります。 インタープリターは、最適化されたコードを生成する基本コンパイラー（ベースラインコンパイラー）に最適化されます。 IonMonkeyコンパイラは、コード実行中に収集されたプロファイリングデータに加えて、大幅に最適化されたコードを生成できます。 投機的最適化が失敗した場合、IonMonkeyはベースラインコードに戻ります。



Chakra-EdgeおよびNode-ChakraCoreで使用されるMicrosoftのJavaScriptエンジンは、非常によく似た構造を持ち、2つの最適化コンパイラーを使用します。 インタプリタはSimpleJITで最適化されます（JITは「Just-In-Timeコンパイラ」の略語で、多少最適化されたコードを生成します。プロファイリングデータとともに、FullJITはさらに最適化されたコードを作成できます。



SafariおよびReact Nativeで使用されるAppleのJavaScriptエンジンであるJavaScriptCore（略してJSC）には、一般に3つの異なる最適化コンパイラがあります。 LLIntはベースコンパイラに最適化された低レベルインタープリタであり、ベースコンパイラはDFG（データフローグラフ）コンパイラに最適化され、すでにFTL（Faster Than Light）コンパイラに最適化されています。

一部のエンジンには、他のエンジンよりも多くの最適化コンパイラがあるのはなぜですか？ 妥協がすべてです。 インタープリターはバイトコードをすばやく処理できますが、バイトコードだけでは特に効率的ではありません。 一方、最適化コンパイラは少し長く動作しますが、より効率的なマシンコードを生成します。 これは、コードを迅速に取得する（インタープリター）か、最大のパフォーマンスでコードを待機して実行する（コンパイラーを最適化する）間の妥協点です。 一部のエンジンは、時間と効率の異なる特性を持ついくつかの最適化コンパイラを追加することを選択します。これにより、この妥協ソリューションを最適に制御し、内部デバイスの追加の複雑さのコストを理解できます。 別のトレードオフはメモリ使用量です;より良い理解のためにこの記事をチェックしてください 。

インタプリタパイプラインとさまざまなJavaScriptエンジンのコンパイラの最適化の主な違いを調べました。 これらの高度な違いにもかかわらず、すべてのJavaScriptエンジンは同じアーキテクチャを備えています。すべてのパーサーと、ある種のインタープリター/コンパイラパイプラインを備えています。

JavaScriptオブジェクトモデル

JavaScriptエンジンの共通点と、JavaScriptオブジェクトのプロパティへのアクセスを高速化するために使用するトリックを見てみましょう。 すべてのメインエンジンが同様の方法でそれを行うことがわかります。

ECMAScript仕様では、 プロパティ属性に一致する文字列キーを持つ辞書としてすべてのオブジェクトを定義しています。



[[Value]]に加えて、仕様では次のプロパティを定義しています。

• [[Writable]]は、プロパティを再割り当てできるかどうかを決定します。
• [[Enumerable]]は、プロパティがfor-inループで表示されるかどうかを決定します。
• [[Configurable]]は、プロパティを削除できるかどうかを決定します。

表記[[ ]]は奇妙に見えますが、それは仕様がJavaScriptのプロパティを記述する方法です。 Object.getOwnPropertyDescriptor APIを使用して、JavaScriptの特定のオブジェクトおよびプロパティのこれらのプロパティ属性を引き続き取得できます。

 const object = { foo: 42 }; Object.getOwnPropertyDescriptor(object, 'foo'); // → { value: 42, writable: true, enumerable: true, configurable: true } 

それがJavaScriptがオブジェクトを定義する方法です。 配列はどうですか？

配列は特別なオブジェクトと考えることができます。 唯一の違いは、配列に特別なインデックス処理があることです。 ここで、配列インデックスはECMAScript仕様の特別な用語です。 JavaScriptでは、配列内の要素の数に制限があります（最大2³²− 1）。 配列インデックスは、この範囲の利用可能なインデックス、つまり0〜2³²-2の整数値です。

別の違いは、配列にはlength魔法のプロパティがあることlength 。

 const array = ['a', 'b']; array.length; // → 2 array[2] = 'c'; array.length; // → 3 

この例では、作成時の配列の長さは2です。 次に、別の要素をインデックス2に割り当てると、長さが自動的に増加します。

JavaScriptは、オブジェクトだけでなく配列も定義します。 たとえば、配列インデックスを含むすべてのキーは、文字列として明示的に表されます。 配列の最初の要素はキー「0」の下に保存されます。



lengthプロパティは、列挙不可能で構成不可能であることが判明した単なる別のプロパティです。

要素が配列に追加されるとすぐに、JavaScriptはlengthプロパティの[[Value]]プロパティの属性を自動的に更新します。



一般的に、配列はオブジェクトと同様に動作すると言えます。

プロパティへのアクセスの最適化

JavaScriptでのオブジェクトの定義方法がわかったので、JavaScriptエンジンを使用してオブジェクトを効率的に操作する方法を見てみましょう。

日常生活では、プロパティへのアクセスが最も一般的な操作です。 エンジンがこれを迅速に行うことは非常に重要です。

 const object = { foo: 'bar', baz: 'qux', }; // Here, we're accessing the property `foo` on `object`: doSomething(object.foo); // ^^^^^^^^^^ 

フォーム

JavaScriptプログラムでは、同じプロパティキーを多くのオブジェクトに割り当てることは非常に一般的な方法です。 彼らはそのようなオブジェクトは同じ形をしていると言います。

 const object1 = { x: 1, y: 2 }; const object2 = { x: 3, y: 4 }; // `object1` and `object2` have the same shape. 

また、通常のメカニズムは、同じ形式のオブジェクトのプロパティへのアクセスです。

 function logX(object) { console.log(object.x); // ^^^^^^^^ } const object1 = { x: 1, y: 2 }; const object2 = { x: 3, y: 4 }; logX(object1); logX(object2); 

これを知っているJavaScriptエンジンは、その形状に基づいてオブジェクトのプロパティへのアクセスを最適化できます。 仕組みをご覧ください。

プロパティxとyを持つオブジェクトがあり、先ほど説明した辞書のデータ構造を使用するとします。 それぞれの属性を指すキー文字列が含まれています。



object.y,などのプロパティにアクセスするobject.y, 、JavaScriptエンジンはキー'y'でJSObjectを検索し、このクエリに一致するプロパティ属性をロードして、最終的に[[Value]]返します。

しかし、これらのプロパティ属性はメモリのどこに保存されますか？ JSObjectの一部として保存する必要がありますか？ これを行うと、後でこのフォームのオブジェクトがさらに表示されます。その場合、プロパティ名は同じフォームのすべてのオブジェクトに対して繰り返されるため、JSObject自体のプロパティと属性の名前を含む完全なディクショナリを保存するのはスペースの無駄です。 これにより、多くの重複が発生し、メモリが誤って割り当てられます。 最適化のために、エンジンはオブジェクトの形状を個別に保存します。



このShapeは、 [[Value]]を除くすべてのプロパティ名と属性が含まれます。 代わりに、フォームにはJSObject内のオフセット値が含まれているため、JavaScriptエンジンは値を探す場所を知っています。 共通のフォームを持つ各JSObjectは、フォームの特定のインスタンスを示します。 これで、各JSObjectは、オブジェクトに固有の値のみを保存する必要があります。



利点は、オブジェクトがたくさんあるとすぐに明らかになります。 それらが1つのフォームを持っている場合、フォームとプロパティに関する情報を一度だけ保存するため、それらの数は重要ではありません。

JavaScriptエンジンはすべて、フォームを最適化の手段として使用しますが、フォームに直接名前を付けるわけではありません。

1. アカデミックドキュメントでは、それらを非表示クラス（JavaScriptクラスに類似）と呼びます。
2. V8ではそれらをマップと呼びます。
3. チャクラはそれらをタイプと呼びます。
4. JavaScriptCoreはそれらを構造体と呼びます。
5. SpiderMonkeyはそれらをShapesと呼びます。

この記事では、引き続きそれらをshapesと呼びます。

遷移チェーンとツリー

特定の形状のオブジェクトがあり、新しいプロパティを追加した場合はどうなりますか？ JavaScriptエンジンは新しいフォームをどのように定義しますか？

 const object = {}; object.x = 5; object.y = 6; 

フォームは、JavaScriptエンジンで遷移チェーンと呼ばれるものを作成します。 以下に例を示します。



オブジェクトには最初はプロパティがなく、空のフォームに対応しています。 次の式は、値5の'x'プロパティをこのオブジェクトに追加し、エンジンは'x'プロパティを含むフォームに移動し、値5は最初のオフセット0でJSObjectに追加されます。次の行は'y'プロパティを追加し、次にエンジン'x'と'y'両方をすでに含んでおり、値6をオフセット1でJSObjectに追加するフォーム

注 ：プロパティが追加される順序は、フォームに影響します。 たとえば、{x：4、y：5}は{y：5、x：4}とは異なる形式になります。

フォームごとにプロパティテーブル全体を保存する必要さえありません。 代わりに、各フォームは、そこに含めようとしている新しいプロパティのみを知る必要があります。 たとえば、この場合、「x」に関する情報を後者の形式で保存する必要はありません。これは、チェーンの初期段階で検出できるためです。 これが機能するために、フォームは以前のフォームとマージされます。



JavaScriptコードでoxを記述する場合、JavaScriptは、 'x'プロパティをすでに持っているフォームを検出するまで、遷移チェーンに沿って'x'プロパティを探します。

しかし、遷移チェーンを作成できない場合はどうなりますか？ たとえば、2つの空のオブジェクトがあり、それらに異なるプロパティを追加するとどうなりますか？

 const object1 = {}; object1.x = 5; const object2 = {}; object2.y = 6; 

この場合、ブランチが表示され、遷移チェーンの代わりに、遷移ツリーが取得されます。



空のオブジェクトaを作成し、プロパティ'x'追加します。 その結果、単一の値と2つのフォームを含むJSObjectがあります：空と単一の'x'プロパティを持つフォーム。

2番目の例は、空のオブジェクトbがあるという事実から始まりますが、別のプロパティ'y'を追加します。 その結果、ここではフォームの2つのチェーンを取得しますが、最終的には3つのチェーンを取得します。

これは、常に空のフォームで開始するということですか？ 必ずしもそうではありません。 エンジンは、すでにプロパティが含まれているobject literal最適化を使用します。 空のオブジェクトリテラルで始まるxを追加するか、既にx含むオブジェクトリテラルがあるとします。

 const object1 = {}; object1.x = 5; const object2 = { x: 6 }; 

最初の例では、空のフォームから始め、先ほど見たようにxも含むチェーンに移動します。

object2の場合、空のオブジェクトとトランジションで開始するのではなく、最初からxがすでにあるオブジェクトを直接作成するのが理にかなっています。



プロパティ'x'を含むオブジェクトのリテラルは、最初から'x'を含むフォームで始まり、空のフォームは事実上スキップされます。 これは（少なくとも）V8とSpiderMonkeyが行うことです。 最適化により、遷移チェーンが短縮され、リテラルからオブジェクトを組み立てやすくなります。

Reactのアプリケーションの驚くべき多態性に関するBenedictのブログ投稿では、このような微妙な点がパフォーマンスにどのように影響するかについて説明しています。

さらに、プロパティ'x' 、 'y' 、 'z'を持つ3次元オブジェクトのポイントの例が表示されます。

 const point = {}; point.x = 4; point.y = 5; point.z = 6; 

前に理解したように、メモリ内に3つのフォームを持つオブジェクトを作成します（空のフォームはカウントしません）。 たとえば、プログラムでpoint.xを記述する場合、このオブジェクトの'x'プロパティにアクセスするには、JavaScriptエンジンはリンクされたリストに従う必要があります。一番上に。



特に、オブジェクトの多くのプロパティを使用して頻繁に行う場合、非常に遅くなります。 プロパティの滞留時間はO(n) 。つまり、オブジェクトのプロパティの数と相関する線形関数です。 プロパティ検索を高速化するために、JavaScriptエンジンはShapeTableデータ構造を追加します。 ShapeTableは、キーがフォームに特定の方法でマップされ、目的のプロパティを生成する辞書です。



ちょっと待って、今度は辞書検索に戻ります...これはまさにフォームを最初に置いたときの最初のものです！ では、なぜフォームさえ気にするのでしょうか？
実際、フォームはインラインキャッシュと呼ばれる別の最適化に貢献します。

記事の第2部でインラインキャッシュまたはICの概念について説明します。4月9日に有名なウイルスアナリストおよび非常勤教師であるAlexander Kolesnikovが開催する無料のオープンウェビナーに招待します。