11 Posts getaggt mit "Interna"

Der endstufige optimierende Compiler von V8, Turbofan, ist bekanntlich einer der wenigen großflächig eingesetzten Produktions-Compiler, die Sea of Nodes (SoN) verwenden. Jedoch haben wir vor fast 3 Jahren begonnen, Sea of Nodes loszuwerden und stattdessen auf eine traditionellere Control-Flow Graph (CFG) Intermediate Representation (IR) zurückzugreifen, die wir Turboshaft genannt haben. Mittlerweile nutzt der gesamte JavaScript-Backend von Turbofan Turboshaft, und WebAssembly verwendet Turboshaft in seiner gesamten Pipeline. Zwei Teile von Turbofan benutzen weiterhin Sea of Nodes: die eingebaute Pipeline, die wir langsam durch Turboshaft ersetzen, und die Frontend-Pipeline von JavaScript, die wir durch Maglev, eine weitere auf CFG basierende IR, ersetzen. In diesem Blogbeitrag erklären wir die Gründe, die uns dazu geführt haben, vom Meer der Knoten wegzugehen.

Ab Version v8.8 wird V8 mit einer neuen experimentellen nicht-backtracking RegExp-Engine ausgeliefert (zusätzlich zur bestehenden Irregexp-Engine), die garantiert, dass die Ausführung in linearer Zeit in Bezug auf die Größe der Eingabestrings erfolgt. Die experimentelle Engine ist hinter den unten erwähnten Feature-Flags verfügbar.

In der Vergangenheit haben wir bereits über die Müllsammlung für JavaScript, das Document Object Model (DOM) und wie dies alles in V8 implementiert und optimiert wird, geschrieben. Nicht alles in Chromium ist jedoch JavaScript, da der größte Teil des Browsers und seiner Blink-Rendering-Engine, in die V8 eingebettet ist, in C++ geschrieben wurde. JavaScript kann verwendet werden, um mit dem DOM zu interagieren, das dann von der Rendering-Pipeline verarbeitet wird.

Es gibt ein Sprichwort unter Entwicklern, dass der schnellste Code derjenige ist, der gar nicht ausgeführt wird. Ebenso ist der schnellste kompilierte Code derjenige, der nicht kompiliert werden muss. Das WebAssembly-Code-Caching ist eine neue Optimierung in Chrome und V8, die versucht, die Code-Kompilierung zu vermeiden, indem der vom Compiler erzeugte native Code zwischengespeichert wird. Wir haben geschrieben über wie Chrome und V8 in der Vergangenheit JavaScript-Code cachen und beste Praktiken, um von dieser Optimierung zu profitieren. In diesem Blog-Beitrag beschreiben wir die Funktionsweise des WebAssembly-Code-Caches in Chrome und wie Entwickler ihn nutzen können, um das Laden von Anwendungen mit großen WebAssembly-Modulen zu beschleunigen.

Array.prototype.sort gehörte zu den letzten eingebauten Funktionen, die in selbst gehostetem JavaScript in V8 implementiert wurden. Die Portierung bot uns die Möglichkeit, mit verschiedenen Algorithmen und Implementierungsstrategien zu experimentieren und sie schließlich stabil zu machen in V8 v7.0 / Chrome 70.

V8 v6.9 beinhaltet Liftoff, einen neuen Basis-Compiler für WebAssembly. Liftoff ist standardmäßig auf Desktop-Systemen aktiviert. Dieser Artikel erläutert die Motivation für die Einführung einer weiteren Kompilierungsstufe und beschreibt die Implementierung und Leistung von Liftoff.

Codeabdeckung liefert Informationen darüber, ob und optional wie oft bestimmte Teile einer Anwendung ausgeführt wurden. Sie wird häufig verwendet, um festzustellen, wie gründlich eine Testsuite eine bestimmte Codebasis prüft.

Warum ist das nützlich?​

Als JavaScript-Entwickler finden Sie sich möglicherweise oft in einer Situation wieder, in der die Codeabdeckung nützlich sein könnte. Zum Beispiel:

• Interessiert an der Qualität Ihrer Testsuite? Ein großes Legacy-Projekt umgestalten? Die Codeabdeckung kann Ihnen genau zeigen, welche Teile Ihrer Codebasis abgedeckt sind.
• Möchten Sie schnell wissen, ob ein bestimmter Teil der Codebasis erreicht wurde? Anstatt mit console.log für printf-ähnliches Debugging oder durch manuelles Durchlaufen des Codes zu instrumentieren, kann die Codeabdeckung Live-Informationen darüber anzeigen, welche Teile Ihrer Anwendungen ausgeführt wurden.
• Oder optimieren Sie vielleicht auf Geschwindigkeit und möchten wissen, auf welche Bereiche Sie sich konzentrieren sollten? Ausführungszähldaten können heiße Funktionen und Schleifen aufzeigen.

In diesem Beitrag möchten wir den CodeStubAssembler (CSA) vorstellen, eine Komponente in V8, die ein äußerst nützliches Werkzeug bei der Erreichung einiger großer Leistungssteigerungen Erfolge in den letzten V8-Versionen war. Der CSA hat auch die Fähigkeit des V8-Teams, JavaScript-Funktionen auf niedriger Ebene schnell und zuverlässig zu optimieren, erheblich verbessert, was die Entwicklungsgeschwindigkeit des Teams erhöhte.

Proxys sind seit ES2015 ein integraler Bestandteil von JavaScript. Sie ermöglichen das Abfangen grundlegender Operationen an Objekten und die Anpassung ihres Verhaltens. Proxys sind ein Kernbestandteil von Projekten wie jsdom und der Comlink RPC-Bibliothek. Kürzlich haben wir viel Aufwand in die Verbesserung der Leistung von Proxys in V8 investiert. Dieser Artikel beleuchtet allgemeine Muster zur Leistungsverbesserung in V8 und speziell für Proxys.

Vor ungefähr drei Monaten trat ich dem V8-Team (Google München) als Praktikant bei und habe seitdem am VM Deoptimizer gearbeitet — etwas völlig Neues für mich, das sich als interessantes und herausforderndes Projekt erwies. Der erste Teil meines Praktikums konzentrierte sich auf die Verbesserung der VM aus Sicherheitsaspekten. Der zweite Teil konzentrierte sich auf Leistungsverbesserungen. Nämlich auf das Entfernen einer Datenstruktur, die zum Entlinken zuvor deoptimierter Funktionen verwendet wurde und während der Garbage Collection zu einem Leistungsengpass wurde. Dieser Blog-Beitrag beschreibt diesen zweiten Teil meines Praktikums. Ich werde erklären, wie V8 früher deoptimierte Funktionen entlinkte, wie wir dies geändert haben und welche Leistungsverbesserungen erzielt wurden.