Warum ist o2.foo ein AssignmentExpression?​

o2.foo sieht nicht wie eine AssignmentExpression aus, da es keine Zuweisung gibt. Warum ist es trotzdem eine AssignmentExpression?

Die Spezifikation erlaubt tatsächlich eine AssignmentExpression sowohl als Argument als auch auf der rechten Seite einer Zuweisung. Zum Beispiel:

function simple(a) {
  console.log('Das Argument war ' + a);
}
simple(x = 1);
// → Gibt „Das Argument war 1“ aus.
x;
// → 1

…und…

x = y = 5;
x; // 5
y; // 5

o2.foo ist eine AssignmentExpression, die nichts zuweist. Dies ergibt sich aus den folgenden Produktionsregeln der Grammatik, jede nimmt den "einfachsten" Fall bis zur letzten:

Eine AssignmentExpression muss keine Zuweisung enthalten, sie kann auch einfach eine ConditionalExpression sein:

AssignmentExpression : ConditionalExpression

(Es gibt auch andere Produktionsregeln, aber hier zeigen wir nur die relevante.)

Eine ConditionalExpression muss keine Bedingung (a == b ? c : d) enthalten, sie kann auch einfach eine ShortcircuitExpression sein:

ConditionalExpression : ShortCircuitExpression

Und so weiter:

ShortCircuitExpression : LogicalORExpression

LogicalORExpression : LogicalANDExpression

LogicalANDExpression : BitwiseORExpression

BitwiseORExpression : BitwiseXORExpression

BitwiseXORExpression : BitwiseANDExpression

BitwiseANDExpression : EqualityExpression

EqualityExpression : RelationalExpression

RelationalExpression : ShiftExpression

Alle sechs Wochen erstellen wir einen neuen Zweig von V8 als Teil unseres Veröffentlichungsprozesses. Jede Version wird direkt vor einem Chrome Beta-Meilenstein vom Git-Master-Zweig von V8 abgezweigt. Heute freuen wir uns, unseren neuesten Zweig, V8 Version 8.1, anzukündigen, der sich bis zu seiner Veröffentlichung in Abstimmung mit Chrome 81 Stable in mehreren Wochen in der Beta-Phase befindet. V8 v8.1 ist vollgepackt mit allerlei Entwicklerfreundlichem. Dieser Beitrag bietet eine Vorschau auf einige der Highlights zur Vorbereitung auf die Veröffentlichung.

Alle Episoden

In diesem Artikel nehmen wir eine einfache Funktion in der Spezifikation und versuchen, die Notation zu verstehen. Los geht's!

Vorwort​

Auch wenn Sie JavaScript kennen, kann das Lesen der Sprachspezifikation, der ECMAScript-Sprachspezifikation, kurz ECMAScript-Spezifikation, ziemlich einschüchternd sein. Zumindest so habe ich mich gefühlt, als ich sie das erste Mal gelesen habe.

Es ist endlich da. Bei jeder V8-Veröffentlichung, alle sechs Wochen, wenn wir im Rahmen unseres Veröffentlichungsprozesses verzweigen, taucht die Frage auf, was passieren wird, wenn V8 Version 8 erreicht. Werden wir eine Party feiern? Werden wir einen neuen Compiler ausliefern? Werden wir Versionen 8 und 9 überspringen und einfach für immer bei einer V8-Version X bleiben? Schließlich, nach über 10 Jahren Arbeit, zu unserem 100. Blogbeitrag, freuen wir uns, unseren neuesten Branch zu präsentieren: V8 Version 8.0 V8, und wir können diese Frage endlich beantworten:

Emscripten hat sich immer zuerst auf das Kompilieren für das Web und andere JavaScript-Umgebungen wie Node.js konzentriert. Aber da WebAssembly beginnt, ohne JavaScript verwendet zu werden, entstehen neue Anwendungsfälle, und deshalb haben wir daran gearbeitet, eigenständige Wasm-Dateien aus Emscripten zu generieren, die nicht auf die Emscripten-JavaScript-Laufzeit angewiesen sind! Dieser Beitrag erklärt, warum das interessant ist.

Alle sechs Wochen erstellen wir einen neuen Branch von V8 im Rahmen unseres Veröffentlichungsprozesses. Jede Version wird direkt vor einem Chrome-Beta-Meilenstein aus dem Git-Master von V8 heraus getrackt. Heute freuen wir uns, unseren neuesten Branch V8 Version 7.9 anzukündigen, der bis zur Veröffentlichung in Koordination mit Chrome 79 Stable in einigen Wochen in der Beta-Phase ist. V8 v7.9 ist vollgepackt mit allerlei Entwickler-freundlichen Extras. Dieser Beitrag gibt einen Vorgeschmack auf einige Highlights als Vorfreude auf die Veröffentlichung.

In der Standardkonfiguration kompiliert V8 reguläre Ausdrücke beim ersten Ausführen in nativen Code. Im Rahmen unserer Arbeit an JIT-less V8 haben wir einen Interpreter für reguläre Ausdrücke eingeführt. Das Interpretieren von regulären Ausdrücken hat den Vorteil, weniger Speicher zu verwenden, geht jedoch mit einem Leistungseinbußen einher. In diesem Blog-Beitrag beschreiben wir, wie wir die Vorteile des Interpretierens von regulären Ausdrücken nutzen und die Nachteile mindern.

Alle sechs Wochen erstellen wir einen neuen Branch von V8 im Rahmen unseres Veröffentlichungsprozesses. Jede Version wird direkt vor einem Chrome-Beta-Meilenstein von V8’s Git-Master verzweigt. Heute freuen wir uns, unseren neuesten Branch anzukündigen, V8 Version 7.8, der sich in der Beta-Phase befindet, bis er in einigen Wochen zusammen mit Chrome 78 Stable veröffentlicht wird. V8 v7.8 ist vollgepackt mit verschiedenen Verbesserungen für Entwickler. Dieser Beitrag bietet eine Vorschau auf einige Highlights als Vorgeschmack auf die Veröffentlichung.

Ende 2018 starteten wir ein Projekt namens V8 Lite, das darauf abzielte, den Speicherverbrauch von V8 drastisch zu reduzieren. Ursprünglich war dieses Projekt als separater Lite-Modus von V8 gedacht, der speziell für mobile Geräte mit geringem Speicher oder Embedding-Anwendungsfälle konzipiert wurde, bei denen es mehr auf reduzierten Speicherverbrauch als auf Durchsatzgeschwindigkeit ankommt. Im Verlauf dieser Arbeit stellten wir jedoch fest, dass viele der Speicheroptimierungen, die wir für diesen Lite-Modus vorgenommen hatten, auch auf das reguläre V8 übertragen werden konnten, wodurch alle V8-Benutzer profitieren konnten.

Zuvor haben wir diskutiert, wie JavaScript-Engines Objekt- und Array-Zugriffe durch die Verwendung von Shapes und Inline-Caches optimieren, und wir haben untersucht, wie Engines den Prototyp-Property-Zugang beschleunigen. Dieser Artikel beschreibt, wie V8 optimale Speicherrepräsentationen für verschiedene JavaScript-Werte auswählt und wie sich dies auf die Shape-Maschine auswirkt – all dies hilft, eine jüngste V8-Leistungsgrenze im React-Kern zu erklären.