38 Posts getaggt mit "Internals"

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.

Dies ist der zweite Teil unserer Serie, die erklärt, wie V8 JavaScript so schnell wie möglich parst. Der erste Teil erklärte, wie wir den Scanner von V8 beschleunigt haben.

Das Parsen ist der Schritt, bei dem Quellcode in eine Zwischenrepräsentation umgewandelt wird, die von einem Compiler (in V8 der Bytecode-Compiler Ignition) verwendet wird. Parsen und Kompilieren erfolgen auf dem kritischen Pfad des Webseitenstarts, und nicht alle Funktionen, die an den Browser übermittelt werden, werden während des Starts sofort benötigt. Auch wenn Entwickler solchen Code mit asynchronen und verzögerten Skripten zurückstellen können, ist das nicht immer machbar. Darüber hinaus liefern viele Webseiten Code, der nur von bestimmten Funktionen verwendet wird, die ein Benutzer während eines einzelnen Durchlaufs der Seite möglicherweise überhaupt nicht aufruft.

Code-Caching (auch bekannt als Bytecode-Caching) ist eine wichtige Optimierung in Browsern. Es reduziert die Startzeit häufig besuchter Websites, indem es das Ergebnis von Parsing + Kompilierung zwischenspeichert. Die meisten beliebten Browser implementieren eine Form des Code-Cachings, und Chrome bildet da keine Ausnahme. Tatsächlich haben wir bereits darüber geschrieben, und gesprochen, wie Chrome und V8 kompilierten Code in der Vergangenheit zwischenspeichern.

Um ein JavaScript-Programm auszuführen, muss der Quelltext verarbeitet werden, damit V8 ihn verstehen kann. V8 beginnt damit, den Quelltext in einen abstrakten Syntaxbaum (AST) zu parsen, eine Menge von Objekten, die die Programmstruktur darstellen. Dieser AST wird von Ignition zu Bytecode kompiliert. Die Leistung dieser Parse- und Kompilierungsphasen ist entscheidend: V8 kann keinen Code ausführen, bevor die Kompilierung abgeschlossen ist. In dieser Blogserie konzentrieren wir uns auf das Parsing und die Arbeit, die in V8 geleistet wurde, um einen blitzschnellen Parser bereitzustellen.

V8 v7.4 unterstützt nun die JavaScript-Ausführung ohne Zuordnung ausführbaren Speichers zur Laufzeit.

In seiner Standardkonfiguration basiert V8 stark auf der Fähigkeit, zur Laufzeit ausführbaren Speicher zuzuweisen und zu ändern. Beispielsweise erstellt der TurboFan-Optimierungskompilierer nativen Code für häufig aufgerufene JavaScript (JS)-Funktionen just-in-time, und die meisten regulären JS-Ausdrücke werden vom irregexp-Motor in nativen Code kompiliert. Die Erstellung ausführbaren Speichers zur Laufzeit ist ein Teil dessen, was V8 schnell macht.

Im Laufe der letzten Jahre hat sich der V8-Müllsammler (GC) stark verändert. Das Orinoco-Projekt hat einen sequentiellen Stop-the-World-Müllsammler in einen überwiegend parallelen und gleichzeitigen Sammler mit inkrementellem Fallback verwandelt.

V8-Funktionen (Builtins) verbrauchen Speicher in jeder Instanz von V8. Die Anzahl der Builtins, deren durchschnittliche Größe und die Anzahl der V8-Instanzen pro Chrome-Browser-Tab haben erheblich zugenommen. Dieser Blog-Beitrag beschreibt, wie wir die mediane V8-Heap-Größe pro Website im vergangenen Jahr um 19 % reduziert haben.

Dieser Beitrag beschreibt die Garbage-Collection-Technik namens gleichzeitiges Markieren. Die Optimierung ermöglicht einer JavaScript-Anwendung, die Ausführung fortzusetzen, während der Garbage Collector den Heap scannt, um lebende Objekte zu finden und zu markieren. Unsere Benchmarks zeigen, dass gleichzeitiges Markieren die auf dem Hauptthread verbrachte Zeit beim Markieren um 60%–70% reduziert. Gleichzeitiges Markieren ist das letzte Puzzlestück des Orinoco-Projekts — das Projekt zum schrittweisen Austausch des alten Garbage Collectors mit dem neuen überwiegend gleichzeitigen und parallelen Garbage Collector. Gleichzeitiges Markieren ist in Chrome 64 und Node.js v10 standardmäßig aktiviert.

V8 verwendet Code-Caching, um den generierten Code für häufig verwendete Skripte zu speichern. Ab Chrome 66 speichern wir mehr Code, indem wir den Cache nach der Top-Level-Ausführung generieren. Dies führt zu einer Reduktion der Parsing- und Kompilierungszeit um 20–40 % während des ersten Ladevorgangs.