16 articles tagués avec « mémoire »

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.

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)

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

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.

Dans le passé, nous avons déjà écrit des articles sur la collecte des ordures pour JavaScript, le modèle objet document (DOM), et comment tout cela est implémenté et optimisé dans V8. Cependant, tout n'est pas JavaScript dans Chromium, car la majeure partie du navigateur et de son moteur de rendu Blink, où V8 est intégré, est écrite en C++. JavaScript peut être utilisé pour interagir avec le DOM, qui est ensuite traité par la chaîne de rendu.

Il existe une bataille constante entre mémoire et performance. En tant qu'utilisateurs, nous souhaitons que les choses soient rapides tout en consommant le moins de mémoire possible. Malheureusement, améliorer la performance se fait généralement au détriment de la consommation de mémoire (et vice versa).

Fin 2018, nous avons lancé un projet nommé V8 Lite, visant à réduire drastiquement la consommation de mémoire de V8. Initialement, ce projet était conçu comme un mode Lite distinct de V8, destiné spécifiquement aux appareils mobiles à faible mémoire ou aux cas d'utilisations embarqués privilégiant la réduction de l'utilisation de la mémoire plutôt que la vitesse d'exécution. Cependant, au cours de ce travail, nous avons réalisé que bon nombre des optimisations mémoire que nous avions conçues pour ce mode Lite pouvaient être intégrées au V8 ordinaire, bénéficiant ainsi à tous les utilisateurs de V8.

Au cours des dernières années, le collecteur d'ordures (GC) de V8 a beaucoup évolué. Le projet Orinoco a transformé un collecteur d'ordures séquentiel stop-the-world en un collecteur principalement parallèle et concurrent avec une solution de repli incrémentale.

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.

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.