Ein schnelles Starten von JavaScript ist entscheidend für eine reaktionsschnelle Web-App. Selbst mit den fortgeschrittenen Optimierungen von V8 können Parsing und Kompilierung von kritischem JavaScript während des Startvorgangs weiterhin Leistungseinbußen verursachen. Wenn bekannt ist, welche JavaScript-Funktionen während der initialen Skriptkompilierung kompiliert werden sollen, kann dies das Laden von Webseiten beschleunigen.

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.

Bei V8 streben wir ständig danach, die Leistung von JavaScript zu verbessern. Im Rahmen dieser Bemühungen haben wir kürzlich die JetStream2-Benchmark-Suite geprüft, um Leistungseinbrüche zu beseitigen. Dieser Beitrag beschreibt eine spezifische Optimierung, die eine signifikante Verbesserung von 2.5x im async-fs-Benchmark ergab und zu einem spürbaren Anstieg der Gesamtpunktzahl beitrug. Die Optimierung wurde durch den Benchmark inspiriert, aber solche Muster finden sich auch im echten Code.

Die JavaScript Promise Integration (JSPI) API ermöglicht es WebAssembly-Anwendungen, die für synchronen Zugriff auf externe Funktionen geschrieben wurden, reibungslos in einer Umgebung zu arbeiten, in der diese Funktionen tatsächlich asynchron sind.

Die JavaScript Promise Integration (JSPI) API von WebAssembly hat eine neue API, verfügbar ab der Chrome-Version M126. Wir sprechen über die Änderungen, wie man sie mit Emscripten verwendet und was der Fahrplan für JSPI ist.

JSPI ist eine API, die es Anwendungen, die sequentielle APIs verwenden, ermöglicht, auf asynchrone Web-APIs zuzugreifen. Viele Web-APIs arbeiten mit JavaScript-Promise-Objekten: Statt die angeforderte Operation sofort auszuführen, geben sie ein Promise zur Ausführung zurück. Andererseits stammen viele Anwendungen, die in WebAssembly kompiliert wurden, aus der C/C++-Welt, die von APIs dominiert wird, bei denen der Aufrufer blockiert, bis die Operation abgeschlossen ist.

Nach fast drei Jahren seit dem ersten Entwurfsdokument und hunderten von CLs in der Zwischenzeit hat die V8 Sandbox — eine leichtgewichtige, prozessinterne Sandbox für V8 — nun einen Punkt erreicht, an dem sie nicht mehr als experimentelles Sicherheitsfeature betrachtet wird. Ab heute ist die V8 Sandbox im Chrome Vulnerability Reward Program (VRP) enthalten. Während es noch einige Probleme gibt, die gelöst werden müssen, bevor sie zu einer starken Sicherheitsgrenze wird, ist die Aufnahme in das VRP ein wichtiger Schritt in diese Richtung. Chrome 123 könnte daher als eine Art "Beta"-Release für die Sandbox angesehen werden. Dieser Blog-Beitrag nutzt die Gelegenheit, um die Motivation hinter der Sandbox zu erläutern, zeigt, wie sie verhindert, dass Speicherbeschädigungen in V8 sich innerhalb des Host-Prozesses ausbreiten, und erklärt letztlich, warum sie ein notwendiger Schritt zur Speichersicherheit ist.

Die JavaScript Promise Integration (JSPI) API von WebAssembly tritt mit der Chrome-Version M123 in einen Origin Trial ein. Das bedeutet, dass Sie testen können, ob Sie und Ihre Nutzer von dieser neuen API profitieren können.

JSPI ist eine API, die es ermöglicht, sogenannten sequenziellen Code – der in WebAssembly kompiliert wurde – auf Web-APIs zuzugreifen, die asynchron sind. Viele Web-APIs sind in Bezug auf JavaScript Promises gestaltet: Anstatt die angeforderte Operation sofort auszuführen, geben sie ein Promise zurück, das dies tun wird. Wenn die Aktion schließlich ausgeführt wird, ruft der Task-Runner des Browsers alle Callbacks mit dem Promise auf. JSPI bindet sich in diese Architektur ein und ermöglicht einer WebAssembly-Anwendung, angehalten zu werden, wenn das Promise zurückgegeben wird, und wieder aufgenommen zu werden, wenn das Promise erfüllt wird.

Haben Sie sich jemals gefragt, woher undefined, true und andere zentrale JavaScript-Objekte stammen? Diese Objekte sind die Atome eines jeden benutzerdefinierten Objekts und müssen zuerst vorhanden sein. V8 nennt sie unbewegliche, unveränderliche Wurzeln, und sie befinden sich in ihrem eigenen Heap – dem schreibgeschützten Heap. Da sie ständig verwendet werden, ist ein schneller Zugriff entscheidend. Und was könnte schneller sein, als ihre Speicheradresse zur Kompilierungszeit korrekt zu erraten?

Willkommen in der spannenden Welt von V8, wo Geschwindigkeit nicht nur ein Feature, sondern eine Lebensweise ist. Während wir uns von 2023 verabschieden, ist es Zeit, die beeindruckenden Errungenschaften zu feiern, die V8 in diesem Jahr erreicht hat.

Durch innovative Leistungsoptimierungen erweitert V8 weiterhin die Grenzen des Möglichen in der sich ständig weiterentwickelnden Weblandschaft. Wir haben einen neuen Mitteltier-Compiler eingeführt und mehrere Verbesserungen an der Top-Tier-Compiler-Infrastruktur, der Laufzeitumgebung und dem Garbage Collector implementiert, was zu signifikanten Geschwindigkeitsgewinnen auf allen Ebenen geführt hat.

In Chrome M117 haben wir einen neuen optimierenden Compiler eingeführt: Maglev. Maglev liegt zwischen unseren bestehenden Sparkplug- und TurboFan-Compilern und übernimmt die Rolle eines schnellen optimierenden Compilers, der schnell genug guten Code generiert.

Bis 2021 hatte V8 zwei Hauptausführungsstufen: Ignition, den Interpreter; und TurboFan, den auf Spitzenleistung fokussierten optimierenden Compiler von V8. Alle JavaScript-Code wird zunächst in Ignition-Bytecode kompiliert und durch Interpretation ausgeführt. Während der Ausführung verfolgt V8, wie sich das Programm verhält, einschließlich der Verfolgung von Objektformen und -typen. Sowohl die Metadaten der Laufzeitausführung als auch der Bytecode werden in den optimierenden Compiler eingespeist, um hochleistungsfähigen, oft spekulativen Maschinencode zu generieren, der deutlich schneller läuft als der Interpreter.