15 Posts getaggt mit "Speicher"

Dieser Blog-Beitrag wurde von José Dapena Paz (Igalia) verfasst, mit Beiträgen von Jason Williams (Bloomberg), Ashley Claymore (Bloomberg), Rob Palmer (Bloomberg), Joyee Cheung (Igalia) und Shu-yu Guo (Google).

In diesem Beitrag über V8-Heap-Snapshots werde ich über einige von Bloomberg-Ingenieuren entdeckte Leistungsprobleme sprechen und wie wir diese gelöst haben, um die JavaScript-Speicheranalyse schneller als je zuvor zu machen.

Das Problem​

Bloomberg-Ingenieure arbeiteten daran, ein Speicherleck in einer JavaScript-Anwendung zu diagnostizieren. Es trat mit Out-Of-Memory-Fehlern auf. Für die getestete Anwendung war das V8-Heap-Limit auf etwa 1400 MB konfiguriert. Normalerweise sollte der Garbage Collector von V8 in der Lage sein, die Heap-Nutzung unter diesem Limit zu halten, daher deuteten die Fehler darauf hin, dass es wahrscheinlich ein Leck gab.

Es ist absolut unsinnig, 64-Bit-Zeiger zu verwenden, wenn ich ein Programm kompiliere, das weniger als 4 Gigabyte RAM benötigt. Wenn solche Zeigerwerte in einer Struktur erscheinen, verschwenden sie nicht nur die Hälfte des Speichers, sondern verbrauchen effektiv die Hälfte des Caches.

– Donald Knuth (2008)

Speichersicherheit in Chrome ist eine ständige Bemühung zum Schutz unserer Nutzer. Wir experimentieren ständig mit verschiedenen Technologien, um böswilligen Akteuren einen Schritt voraus zu sein. In diesem Geist handelt dieser Beitrag von unserer Reise der Nutzung von Heap-Scanning-Technologien zur Verbesserung der Speichersicherheit von C++.

Während der Titel dieses Beitrags möglicherweise darauf hinweist, tief in eine Sammlung von Büchern über Ölpfannen – ein Thema mit überraschend viel Literatur, wenn man Konstruktionstechniken für Pfannen berücksichtigt – einzutauchen, schauen wir stattdessen genauer auf Oilpan, einen C++ Garbage Collector, der seit V8 v9.4 als Bibliothek über V8 bereitgestellt wird.

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.

Ende 2018 starteten wir ein Projekt namens V8 Lite, das darauf abzielte, den Speicherverbrauch von V8 drastisch zu reduzieren. Ursprünglich war dieses Projekt als separater Lite-Modus von V8 gedacht, der speziell für mobile Geräte mit geringem Speicher oder Embedding-Anwendungsfälle konzipiert wurde, bei denen es mehr auf reduzierten Speicherverbrauch als auf Durchsatzgeschwindigkeit ankommt. Im Verlauf dieser Arbeit stellten wir jedoch fest, dass viele der Speicheroptimierungen, die wir für diesen Lite-Modus vorgenommen hatten, auch auf das reguläre V8 übertragen werden konnten, wodurch alle V8-Benutzer profitieren konnten.

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.

Das Debuggen von Speicherlecks in Chrome 66 ist jetzt deutlich einfacher geworden. Die Chrome DevTools können jetzt C++ DOM-Objekte verfolgen und schnappschussartig erfassen sowie alle erreichbaren DOM-Objekte von JavaScript mit ihren Referenzen anzeigen. Diese Funktion ist einer der Vorteile des neuen C++-Tracing-Mechanismus des V8-Garbage-Collectors.

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.

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.