Un article récent sur WebAssembly Garbage Collection (WasmGC) explique à un niveau général comment la proposition de Garbage Collection (GC) vise à mieux prendre en charge les langages à GC dans Wasm, ce qui est très important compte tenu de leur popularité. Dans cet article, nous entrerons dans les détails techniques sur la manière dont les langages à GC tels que Java, Kotlin, Dart, Python et C# peuvent être portés sur Wasm. Il existe en fait deux approches principales :

L'intégrité du flux de contrôle (CFI) est une fonctionnalité de sécurité visant à empêcher les attaques exploitant les détournements de flux de contrôle. L'idée est que même si un attaquant parvient à corrompre la mémoire d'un processus, des vérifications d'intégrité supplémentaires peuvent les empêcher d'exécuter du code arbitraire. Dans cet article de blog, nous souhaitons discuter de notre travail pour activer le CFI dans V8.

Cet article de blog a été rédigé par José Dapena Paz (Igalia), avec les contributions de Jason Williams (Bloomberg), Ashley Claymore (Bloomberg), Rob Palmer (Bloomberg), Joyee Cheung (Igalia) et Shu-yu Guo (Google).

Dans cet article sur les instantanés de tas V8, je vais parler de certains problèmes de performance rencontrés par les ingénieurs de Bloomberg et comment nous les avons résolus pour rendre l'analyse mémoire JavaScript plus rapide que jamais.

Le problème​

Les ingénieurs de Bloomberg travaillaient sur le diagnostic d'une fuite mémoire dans une application JavaScript. Elle échouait avec des erreurs de type Out-Of-Memory. Pour l'application testée, la limite du tas V8 était configurée autour de 1400 Mo. Normalement, le ramasse-miettes de V8 devrait pouvoir maintenir l'utilisation du tas en dessous de cette limite, de sorte que les échecs indiquent probablement une fuite.

Nous intégrons les appels en queue de WebAssembly dans V8 v11.2 ! Dans cet article, nous donnons un aperçu de cette proposition, présentons un cas d’utilisation intéressant pour les coroutines C++ avec Emscripten, et montrons comment V8 gère les appels en queue en interne.

Qu'est-ce que l'optimisation des appels en queue ?​

Un appel est dit être en position de queue si c'est la dernière instruction exécutée avant de retourner de la fonction actuelle. Les compilateurs peuvent optimiser ces appels en supprimant la pile de l'appelant et en remplaçant l’appel par un saut.

Cela est particulièrement utile pour les fonctions récursives. Par exemple, prenez cette fonction C qui additionne les éléments d'une liste chaînée :

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

Avec un appel classique, cela consomme un espace de pile de 𝒪(n) : chaque élément de la liste ajoute un nouveau cadre à la pile d'appels. Avec une liste assez longue, cela peut rapidement provoquer un débordement de pile. En remplaçant l'appel par un saut, l'optimisation des appels en queue transforme efficacement cette fonction récursive en une boucle utilisant un espace de pile de 𝒪(1) :

Il est absolument idiot d'avoir des pointeurs 64 bits lorsque je compile un programme qui utilise moins de 4 gigaoctets de RAM. Lorsque de telles valeurs de pointeur apparaissent à l'intérieur d'une structure, elles ne font pas seulement perdre la moitié de la mémoire, elles jettent effectivement la moitié du cache.

– Donald Knuth (2008)

Historiquement, il y avait un article de blog pour chaque nouvelle branche de version de V8. Vous avez peut-être remarqué qu'il n'y a pas eu d'article de blog sur les versions depuis la v9.9. À partir de la v10.0, nous abandonnons les articles de blog sur les versions pour chaque nouvelle branche. Mais ne vous inquiétez pas, toutes les informations auxquelles vous étiez habitué via les articles de blog sur les versions sont toujours disponibles ! Lisez la suite pour découvrir où trouver ces informations à l'avenir.

La sécurité mémoire dans Chrome est un effort perpétuel pour protéger nos utilisateurs. Nous expérimentons constamment différentes technologies pour devancer les acteurs malveillants. Dans cet esprit, cet article évoque notre démarche d'utilisation des technologies d'analyse du tas afin d'améliorer la sécurité mémoire de C++.

Les champs de classe ont été introduits dans V8 à partir de la version v7.2 et les méthodes privées de classe depuis la version v8.4. Après que les propositions ont atteint le stade 4 en 2021, des travaux ont commencé pour améliorer le support des nouvelles fonctionnalités des classes dans V8 - jusque-là, deux problèmes principaux affectaient leur adoption :

Toutes les quatre semaines, nous créons une nouvelle branche de V8 dans le cadre de notre processus de publication. Chaque version est dérivée du Git principal de V8 juste avant une étape bêta de Chrome. Aujourd'hui, nous sommes heureux d'annoncer notre nouvelle branche, V8 version 9.9, qui est en phase bêta jusqu'à sa sortie coordonnée avec Chrome 99 Stable dans quelques semaines. V8 v9.9 est rempli de toutes sortes de nouveautés pour les développeurs. Cet article fournit un aperçu de certains des points forts en prévision de la sortie.

Bien que le titre de cet article puisse laisser entendre une plongée approfondie dans une collection de livres sur les bacs à huile – ce qui, étant donné les normes de construction des bacs, est un sujet étonnamment riche en littérature – nous examinons plutôt de plus près Oilpan, un ramasse-miettes C++ qui est hébergé via V8 en tant que bibliothèque depuis V8 v9.4.