JavaScript-Objekte in V8 werden auf einem Heap gespeichert, der vom Müllsammler von V8 verwaltet wird. In früheren Blogposts haben wir bereits darüber gesprochen, wie wir die Pausenzeiten der Müllsammlung reduzieren (mehr als einmal) und den Speicherverbrauch verringern. In diesem Blogbeitrag stellen wir den parallelen Scavenger vor, eine der neuesten Funktionen von Orinoco, V8s überwiegend nebenläufigem und parallel arbeitendem Müllsammler, und diskutieren Designentscheidungen sowie alternative Ansätze, die wir auf dem Weg implementiert haben.

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.

Die JavaScript-Leistung war für das V8-Team schon immer wichtig, und in diesem Beitrag möchten wir einen neuen JavaScript Web Tooling Benchmark vorstellen, den wir kürzlich verwendet haben, um einige Leistungsengpässe in V8 zu identifizieren und zu beheben. Sie wissen möglicherweise bereits über V8s starkes Engagement für Node.js Bescheid, und dieses Benchmark erweitert dieses Engagement, indem es speziell Leistungstests mit gängigen Entwickler-Tools durchführt, die auf Node.js basieren. Die Tools im Web Tooling Benchmark sind dieselben, die von Entwicklern und Designern heute verwendet werden, um moderne Websites und Cloud-basierte Anwendungen zu erstellen. In Fortsetzung unserer laufenden Bemühungen, den Fokus auf realistische Leistung statt auf künstliche Benchmarks zu richten, haben wir das Benchmark mit tatsächlichem Code erstellt, den Entwickler jeden Tag ausführen.

Alle sechs Wochen erstellen wir im Rahmen unseres Veröffentlichungsprozesses einen neuen Branch von V8. Jede Version wird kurz vor einem Chrome-Beta-Meilenstein aus dem Git-Master von V8 abgezweigt. Heute freuen wir uns, unseren neuesten Branch, V8-Version 6.3, anzukündigen, der bis zu seiner Veröffentlichung in Zusammenarbeit mit Chrome 63 Stable in einigen Wochen im Beta-Modus ist. V8 v6.3 ist vollgepackt mit allerlei Entwickler-Features. Dieser Beitrag bietet eine Vorschau auf einige der Highlights in Erwartung der Veröffentlichung.

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.

In JavaScript entweicht ein zugewiesenes Objekt, wenn es von außerhalb der aktuellen Funktion zugänglich ist. Normalerweise weist V8 neue Objekte auf dem JavaScript-Heap zu, aber mithilfe der Escape-Analyse kann ein optimierender Compiler feststellen, wann ein Objekt speziell behandelt werden kann, da seine Lebensdauer nachweislich an die Aktivierung der Funktion gebunden ist. Wenn die Referenz zu einem neu zugewiesenen Objekt die Funktion, die es erstellt, nicht verlässt, müssen JavaScript-Engines das Objekt nicht explizit auf dem Heap zuweisen. Sie können stattdessen die Werte des Objekts effektiv als lokale Variablen der Funktion behandeln. Dies ermöglicht wiederum verschiedene Optimierungen, wie das Speichern dieser Werte auf dem Stack oder in Registern oder in einigen Fällen das vollständige Weglassen der Werte. Objekte, die entweichen (genauer gesagt, Objekte, bei denen nicht bewiesen werden kann, dass sie nicht entweichen), müssen auf dem Heap zugewiesen werden.

JavaScript-Objekte können beliebige Eigenschaften haben, die ihnen zugeordnet sind. Die Namen von Objekteigenschaften können jedes Zeichen enthalten. Einer der interessanten Fälle, die eine JavaScript-Engine optimieren kann, sind Eigenschaften, deren Namen rein numerisch sind, insbesondere Array-Indizes.

Alle sechs Wochen erstellen wir einen neuen Zweig von V8 als Teil unseres Veröffentlichungsprozesses. Jede Version wird direkt vor einem Chrome-Beta-Meilenstein von V8's Git-Master abgezweigt. Heute freuen wir uns, unseren neuesten Branch, V8 Version 6.2, anzukündigen, der bis zur Veröffentlichung in Verbindung mit Chrome 62 Stable in einigen Wochen in der Beta-Phase ist. V8 v6.2 ist vollgepackt mit allerlei Entwicklertools und Funktionen. Dieser Beitrag gibt eine Vorschau auf einige Highlights, um die Veröffentlichung vorwegzunehmen.

In diesem Blogbeitrag möchten wir erklären, wie V8 intern JavaScript-Eigenschaften verarbeitet. Aus JavaScript-Sicht sind nur wenige Unterscheidungen für Eigenschaften notwendig. JavaScript-Objekte verhalten sich meist wie Wörterbücher, mit Zeichenketten als Schlüsseln und beliebigen Objekten als Werten. Die Spezifikation behandelt jedoch während der Iteration ganzzahlig indizierte Eigenschaften anders als andere Eigenschaften. Abgesehen davon verhalten sich die verschiedenen Eigenschaften im Wesentlichen gleich, unabhängig davon, ob sie ganzzahlig indiziert sind oder nicht.