Les objets JavaScript dans V8 sont alloués sur un tas géré par le collecteur de déchets de V8. Dans des articles de blog précédents, nous avons déjà parlé de la manière dont nous réduisons les temps de pause de la collecte des déchets (plus d'une fois) et la consommation de mémoire. Dans ce billet, nous introduisons le Scavenger parallèle, l'une des dernières fonctionnalités d'Orinoco, le collecteur de déchets principalement concurrent et parallèle de V8, et discutons des décisions de conception et des approches alternatives que nous avons mises en œuvre en cours de route.

Dans cet article, nous souhaitons présenter le CodeStubAssembler (CSA), un composant de V8 qui s'est avéré être un outil très utile pour atteindre certains grands gains de performance au cours des dernières versions de V8. Le CSA a également considérablement amélioré la capacité de l'équipe V8 à optimiser rapidement les fonctionnalités JavaScript à un niveau bas avec un haut degré de fiabilité, ce qui a amélioré la vitesse de développement de l'équipe.

La performance du JavaScript a toujours été importante pour l'équipe V8, et dans cet article, nous souhaitons discuter d'un nouveau Web Tooling Benchmark que nous avons récemment utilisé pour identifier et corriger certains goulots d'étranglement en termes de performance dans V8. Vous connaissez peut-être déjà l'engagement fort de V8 envers Node.js, et ce benchmark prolonge cet engagement en exécutant spécifiquement des tests de performance basés sur des outils courants de développement construits sur Node.js. Les outils du Web Tooling Benchmark sont les mêmes que ceux utilisés aujourd'hui par les développeurs et concepteurs pour créer des sites web modernes et des applications basées sur le cloud. Dans le prolongement de nos efforts continus pour nous concentrer sur la performance réelle plutôt que sur des benchmarks artificiels, nous avons créé le benchmark en utilisant le code réel que les développeurs exécutent quotidiennement.

Tous les six semaines, nous créons une nouvelle branche de V8 dans le cadre de notre processus de sortie. Chaque version est dérivée du maître Git de V8 juste avant une étape Beta de Chrome. Aujourd’hui, nous sommes ravis d’annoncer notre nouvelle branche, V8 version 6.3, qui est en beta jusqu’à sa sortie en coordination avec Chrome 63 Stable dans les semaines à venir. V8 v6.3 est remplie de toutes sortes de nouveautés pour les développeurs. Cet article fournit un aperçu de certains points forts en prévision de la sortie.

Les proxies sont une partie intégrante de JavaScript depuis ES2015. Ils permettent d'intercepter les opérations fondamentales sur les objets et de personnaliser leur comportement. Les proxies constituent une partie centrale de projets comme jsdom et la bibliothèque RPC Comlink. Récemment, nous avons investi beaucoup d'efforts pour améliorer les performances des proxies dans V8. Cet article met en lumière les modèles généraux d'amélioration des performances dans V8 et pour les proxies en particulier.

Il y a environ trois mois, j’ai rejoint l’équipe V8 (Google Munich) en tant que stagiaire et depuis, j’ai travaillé sur le Deoptimizer de la VM — quelque chose de totalement nouveau pour moi qui s’est avéré être un projet intéressant et stimulant. La première partie de mon stage s’est concentrée sur l’amélioration de la sécurité de la VM. La deuxième partie portait sur les améliorations des performances. Notamment, sur la suppression d’une structure de données utilisée pour délier les fonctions précédemment désoptimisées, ce qui était un goulot d’étranglement de performance durant la collecte des ordures. Cet article de blog décrit cette deuxième partie de mon stage. J’expliquerai comment V8 délait les fonctions désoptimisées auparavant, comment nous avons changé cela et quelles améliorations de performance ont été obtenues.

En JavaScript, un objet alloué s'échappe s'il est accessible depuis l'extérieur de la fonction actuelle. Normalement, V8 alloue de nouveaux objets sur le tas JavaScript, mais en utilisant l'analyse d'évasion, un compilateur optimisant peut déterminer quand un objet peut être traité de manière spéciale parce que sa durée de vie est prouvée comme étant liée à l'activation de la fonction. Lorsque la référence à un objet nouvellement alloué n'échappe pas à la fonction qui le crée, les moteurs JavaScript n'ont pas besoin d'allouer explicitement cet objet sur le tas. Ils peuvent plutôt traiter efficacement les valeurs de l'objet comme des variables locales à la fonction. Cela permet à son tour toutes sortes d'optimisations comme stocker ces valeurs sur la pile ou dans des registres, ou dans certains cas, optimiser complètement les valeurs. Les objets qui s'échappent (plus précisément, les objets dont on ne peut pas prouver qu'ils ne s'échappent pas) doivent être alloués sur le tas.

Les objets JavaScript peuvent avoir des propriétés arbitraires associées à eux. Les noms des propriétés d'objet peuvent contenir n'importe quel caractère. L'un des cas intéressants que le moteur JavaScript peut choisir d'optimiser concerne les propriétés dont les noms sont purement numériques, plus précisément les indices de tableau.

Toutes les six semaines, nous créons une nouvelle branche de V8 dans le cadre de notre processus de publication. Chaque version est déviée du maître Git de V8 juste avant un jalon Chrome Beta. Aujourd'hui, nous sommes ravis d'annoncer notre dernière branche, Version 6.2 de V8, qui est en version bêta jusqu'à sa publication en coordination avec Chrome 62 Stable dans quelques semaines. V8 v6.2 est rempli de toutes sortes de nouveautés à destination des développeurs. Cet article offre un aperçu de certains points forts en anticipation de la publication.

Dans cet article, nous souhaitons expliquer comment V8 gère les propriétés JavaScript en interne. Du point de vue de JavaScript, seules quelques distinctions sont nécessaires pour les propriétés. Les objets JavaScript se comportent principalement comme des dictionnaires, avec des clés de type chaîne de caractères et des objets arbitraires comme valeurs. Cependant, la spécification traite différemment les propriétés indexées par des entiers et les autres propriétés durant l'itération. En dehors de cela, les différentes propriétés se comportent principalement de la même manière, indépendamment du fait qu'elles soient indexées par des entiers ou non.