15 Posts getaggt mit "Speicher"

V8 hat ein hartes Limit für seine Heap-Größe. Dies dient als Schutzmechanismus gegen Anwendungen mit Speicherlecks. Wenn eine Anwendung dieses harte Limit erreicht, führt V8 eine Reihe von Notfall-Garbage-Collections durch. Wenn die Garbage-Collections nicht helfen, Speicher freizugeben, stoppt V8 die Ausführung und meldet einen Speicherfehler. Ohne das harte Limit könnte eine undichte Anwendung den gesamten Systemspeicher beanspruchen und die Leistung anderer Anwendungen beeinträchtigen.

Der Speicherverbrauch ist eine wichtige Dimension im Bereich der Leistungsabstimmung virtueller JavaScript-Maschinen. In den letzten Monaten hat das V8-Team den Speicherverbrauch mehrerer Websites analysiert und dabei signifikant reduziert, die als repräsentativ für moderne Webentwicklungsmuster betrachtet wurden. In diesem Blogpost stellen wir die Arbeitslasten und Werkzeuge vor, die wir in unserer Analyse verwendet haben, erläutern Speicheroptimierungen im Garbage Collector und zeigen, wie wir den von V8 analysierten Speicherverbrauch beim Parser und bei den Compilern reduziert haben.

In einem früheren Blogpost haben wir das Problem von Rucklern vorgestellt, die durch Garbage Collection verursacht werden und ein flüssiges Surfen beeinträchtigen. In diesem Blogpost stellen wir drei Optimierungen vor, die die Grundlage für einen neuen Garbage Collector in V8 mit dem Codenamen Orinoco bilden. Orinoco basiert auf der Idee, dass die Implementierung eines überwiegend parallelen und gleichzeitig arbeitenden Garbage Collectors ohne strikte Generationengrenzen die Ruckler bei der Garbage Collection und den Speicherverbrauch reduziert, während gleichzeitig eine hohe Durchsatzrate erhalten bleibt. Statt Orinoco als separaten Garbage Collector hinter einem Flag zu implementieren, haben wir uns entschieden, die Funktionen von Orinoco schrittweise auf die V8 Hauptentwicklung einzuführen, um den Benutzern sofort Vorteile zu bieten. Die drei in diesem Beitrag diskutierten Funktionen sind paralleles Kompaktieren, parallele Verarbeitung des Remembered Sets und schwarze Allokation.

Jank, oder anders gesagt sichtbares Stocken, kann bemerkt werden, wenn Chrome nicht in der Lage ist, einen Frame innerhalb von 16,66 ms zu rendern (was die Bewegung mit 60 Frames pro Sekunde unterbricht). Zum jetzigen Zeitpunkt wird der Großteil der V8-Garbage-Collection-Arbeiten auf dem Haupt-Rendering-Thread ausgeführt, siehe Abbildung 1, was häufig zu Jank führt, wenn zu viele Objekte verwaltet werden müssen. Jank zu eliminieren war für das V8-Team schon immer eine hohe Priorität (1, 2, 3). Dieser Artikel diskutiert einige Optimierungen, die zwischen Chrome 41 und Chrome 46 implementiert wurden und die Garbage-Collection-Pausen signifikant reduzieren, was zu einer besseren Benutzererfahrung führt.

Die JavaScript-Performance bleibt einer der zentralen Werte von Chrome, insbesondere wenn es darum geht, eine flüssige Benutzererfahrung zu ermöglichen. Ab Chrome 41 nutzt V8 eine neue Technik, um die Reaktionsfähigkeit von Webanwendungen zu erhöhen, indem aufwendige Speicherverwaltungsoperationen in kleinen, sonst ungenutzten Leerlaufzeiten verborgen werden. Dadurch können Webentwickler mit flüssigerem Scrolling und geschmeidigen Animationen mit deutlich weniger Rucklern aufgrund von Speicherbereinigung rechnen.