V8 v6.9 inclut Liftoff, un nouveau compilateur de base pour WebAssembly. Liftoff est désormais activé par défaut sur les systèmes de bureau. Cet article détaille la motivation d'ajouter un autre niveau de compilation et décrit l’implémentation et les performances de Liftoff.
Les fonctions intégrées de V8 (builtins) consomment de la mémoire dans chaque instance de V8. Le nombre de fonctions intégrées, leur taille moyenne et le nombre d'instances de V8 par onglet de navigateur Chrome ont considérablement augmenté. Ce billet de blog décrit comment nous avons réduit la taille médiane du tas V8 par site web de 19% au cours de l'année dernière.
Cet article décrit la technique de collecte des déchets appelée marquage concurrent. Cette optimisation permet à une application JavaScript de continuer son exécution pendant que le collecteur d’ordures balaie le tas pour trouver et marquer les objets vivants. Nos benchmarks montrent que le marquage concurrent réduit le temps passé à marquer sur le thread principal de 60 % à 70 %. Le marquage concurrent est la dernière pièce du puzzle du projet Orinoco — le projet qui remplace progressivement l'ancien collecteur d'ordures par le nouveau collecteur d'ordures principalement concurrent et parallèle. Le marquage concurrent est activé par défaut dans Chrome 64 et Node.js v10.
V8 utilise la mise en cache du code pour mettre en cache le code généré pour les scripts fréquemment utilisés. À partir de Chrome 66, nous mettons en cache plus de code en générant le cache après l'exécution au niveau supérieur. Cela conduit à une réduction de 20 à 40 % du temps d'analyse et de compilation lors du premier chargement.
TL;DR : La désérialisation paresseuse a récemment été activée par défaut dans V8 v6.4, réduisant en moyenne la consommation de mémoire de V8 de plus de 500 KB par onglet de navigateur. Lisez la suite pour en savoir plus !
Mais d'abord, revenons un peu en arrière et voyons comment V8 utilise les instantanés de tas pour accélérer la création de nouveaux isolats (qui correspondent approximativement à un onglet de navigateur dans Chrome). Mon collègue Yang Guo a donné une bonne introduction à ce sujet dans son article sur les instantanés de démarrage personnalisés :
La couverture de code fournit des informations sur si, et éventuellement à quelle fréquence, certaines parties d'une application ont été exécutées. Elle est couramment utilisée pour déterminer dans quelle mesure une suite de tests examine une base de code particulière.
En tant que développeur JavaScript, vous pouvez souvent vous retrouver dans une situation où la couverture de code pourrait être utile. Par exemple :
console.log pour un debugging de style printf ou de passer manuellement à travers le code, la couverture de code peut afficher des informations en direct sur quelles parties de vos applications ont été exécutées.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.
Dans un article de blog précédent, nous avons introduit le problème du jank causé par la collecte des déchets interrompant une expérience de navigation fluide. Dans cet article, nous présentons trois optimisations qui posent les bases d'un nouveau ramasse-miettes dans V8, nommé Orinoco. Orinoco repose sur l'idée qu'implémenter un ramasse-miettes majoritairement parallèle et concurrent sans frontières générationnelles strictes réduira le jank causé par la collecte des déchets et la consommation mémoire tout en fournissant un haut débit. Au lieu d'implémenter Orinoco derrière un drapeau comme un ramasse-miettes distinct, nous avons décidé de déployer les fonctionnalités d'Orinoco de manière incrémentale dans la version principale de V8 pour en faire bénéficier immédiatement les utilisateurs. Les trois fonctionnalités discutées dans cet article sont le compactage parallèle, le traitement parallèle de l'ensemble mémorisé, et l'allocation en noir.
Les performances de JavaScript continuent d'être l'un des aspects clés des valeurs de Chrome, notamment lorsqu'il s'agit d'offrir une expérience fluide. À partir de Chrome 41, V8 utilise une nouvelle technique pour augmenter la réactivité des applications web en cachant les opérations coûteuses de gestion de la mémoire dans de petits morceaux de temps inactif autrement inutilisés. En conséquence, les développeurs web devraient s'attendre à un défilement plus fluide et à des animations légères avec des saccades considérablement réduites dues à la collecte des déchets.