Ein kürzlich erschienener Artikel über WebAssembly Garbage Collection (WasmGC) erklärt auf hoher Ebene, wie der Garbage Collection (GC) Vorschlag darauf abzielt, die Unterstützung von Programmiersprachen mit Garbage Collection in Wasm zu verbessern, was angesichts ihrer Beliebtheit sehr wichtig ist. In diesem Artikel werden wir uns mit den technischen Details befassen, wie GC-Sprachen wie Java, Kotlin, Dart, Python und C# nach Wasm portiert werden können. Es gibt tatsächlich zwei Hauptansätze:

Control-flow-Integrität (CFI) ist eine Sicherheitsfunktion, die darauf abzielt, Exploits daran zu hindern, den Kontrollfluss zu kapern. Die Idee ist, dass selbst wenn ein Angreifer es schafft, den Speicher eines Prozesses zu manipulieren, zusätzliche Integritätsprüfungen verhindern können, dass er beliebigen Code ausführt. In diesem Blogbeitrag möchten wir unsere Arbeit zur Aktivierung von CFI in V8 vorstellen.

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.

Wir veröffentlichen WebAssembly-Tail-Calls in V8 v11.2! In diesem Beitrag geben wir einen kurzen Überblick über diesen Vorschlag, demonstrieren einen interessanten Anwendungsfall für C++-Koroutinen mit Emscripten und zeigen, wie V8 Tail Calls intern behandelt.

Was ist Tail Call Optimization?​

Ein Aufruf befindet sich in Tail-Position, wenn er die letzte Anweisung ist, die vor der Rückkehr aus der aktuellen Funktion ausgeführt wird. Compiler können solche Aufrufe optimieren, indem sie den Aufrufer-Frame verwerfen und den Aufruf durch einen Sprung ersetzen.

Dies ist besonders nützlich für rekursive Funktionen. Betrachten Sie beispielsweise diese C-Funktion, die die Elemente einer verketteten Liste summiert:

int sum(List* list, int acc) {
  if (list == nullptr) return acc;
  return sum(list->next, acc + list->val);
}

Mit einem regulären Aufruf verbraucht dies 𝒪(n) Stapelspeicherplatz: Jedes Element der Liste fügt einen neuen Frame auf dem Aufrufstapel hinzu. Mit einer ausreichend langen Liste könnte dies sehr schnell den Stapel überlaufen lassen. Durch den Ersatz des Aufrufs durch einen Sprung verwandelt die Tail-Call-Optimierung diese rekursive Funktion effektiv in eine Schleife, die 𝒪(1) Stapelspeicherplatz verwendet:

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)

Historisch gesehen gab es für jeden neuen Veröffentlichungszweig von V8 einen Blogbeitrag. Sie haben vielleicht bemerkt, dass es seit v9.9 keinen Veröffentlichungs-Blogbeitrag mehr gab. Ab v10.0 stellen wir die Veröffentlichungs-Blogbeiträge für jeden neuen Zweig ein. Aber keine Sorge, alle Informationen, die Sie bisher über Veröffentlichungs-Blogbeiträge erhalten haben, sind weiterhin verfügbar! Lesen Sie weiter, um zu erfahren, wo Sie diese Informationen zukünftig finden können.

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++.

Klassenfelder wurden in V8 seit v7.2 eingeführt, und private Klassenmethoden wurden seit v8.4 verfügbar. Nachdem die Vorschläge 2021 die Stufe 4 erreicht hatten, begann die Arbeit an der Verbesserung der Unterstützung für die neuen Klassenfeatures in V8 - bis dahin gab es zwei Hauptprobleme, die ihre Akzeptanz beeinträchtigten:

Alle vier Wochen erstellen wir einen neuen Zweig von V8 als Teil unseres Veröffentlichungsprozesses. Jede Version wird direkt vor einem Chrome-Beta-Meilenstein aus dem Hauptzweig von V8 Git abgezweigt. Heute freuen wir uns, unseren neuesten Zweig V8 Version 9.9 anzukündigen, der bis zu seiner Veröffentlichung in Abstimmung mit Chrome 99 Stable in einigen Wochen in der Beta ist. V8 v9.9 ist vollgepackt mit allerlei Entwickler-Neuerungen. Dieser Beitrag bietet eine Vorschau auf einige der Highlights in Erwartung der Veröffentlichung.

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.