11 publicaciones etiquetados con "memoria"

Esta publicación en el blog ha sido escrita por José Dapena Paz (Igalia), con contribuciones de Jason Williams (Bloomberg), Ashley Claymore (Bloomberg), Rob Palmer (Bloomberg), Joyee Cheung (Igalia) y Shu-yu Guo (Google).

En esta publicación sobre instantáneas de montón de V8, hablaré sobre algunos problemas de rendimiento encontrados por ingenieros de Bloomberg, y cómo los solucionamos para que el análisis de memoria de JavaScript sea más rápido que nunca.

El problema​

Los ingenieros de Bloomberg estaban trabajando en diagnosticar una fuga de memoria en una aplicación de JavaScript. Estaba fallando con errores de Falta de Memoria. Para la aplicación probada, el límite del montón de V8 estaba configurado en aproximadamente 1400 MB. Normalmente, el colector de basura de V8 debería poder mantener el uso del montón por debajo de ese límite, por lo que los fallos indicaban que probablemente había una fuga.

Es absolutamente idiota tener punteros de 64 bits cuando compilo un programa que usa menos de 4 gigabytes de RAM. Cuando tales valores de puntero aparecen dentro de una estructura, no solo desperdician la mitad de la memoria, sino que también efectivamente descartan la mitad de la caché.

– Donald Knuth (2008)

La seguridad de memoria en Chrome es un esfuerzo continuo para proteger a nuestros usuarios. Constantemente experimentamos con diferentes tecnologías para estar un paso adelante de los actores maliciosos. En este espíritu, esta publicación trata sobre nuestro camino usando tecnologías de análisis de heap para mejorar la seguridad de memoria de C++.

En el pasado ya hemos escrito bastante sobre la recolección de basura para JavaScript, el modelo de objetos del documento (DOM) y cómo todo esto está implementado y optimizado en V8. Sin embargo, no todo en Chromium es JavaScript, ya que la mayor parte del navegador y su motor de renderizado Blink, donde V8 está integrado, están escritos en C++. JavaScript puede usarse para interactuar con el DOM, que luego es procesado por la tubería de renderizado.

A finales de 2018 iniciamos un proyecto llamado V8 Lite, con el objetivo de reducir drásticamente el uso de memoria de V8. Inicialmente, este proyecto fue concebido como un modo Lite separado de V8 específicamente orientado a dispositivos móviles con poca memoria o casos de uso en integradores que priorizan el ahorro de memoria sobre la velocidad de ejecución. Sin embargo, en el proceso de este trabajo, nos dimos cuenta de que muchas de las optimizaciones de memoria que habíamos hecho para este modo Lite podrían trasladarse al V8 regular, beneficiando a todos sus usuarios.

En los últimos años, el recolector de basura (GC) de V8 ha cambiado mucho. El proyecto Orinoco ha transformado un recolector de basura secuencial que detenía completamente la ejecución en un recolector mayormente paralelo y concurrente con retroceso incremental.

Hace aproximadamente tres meses, me uní al equipo de V8 (Google Munich) como pasante y desde entonces he estado trabajando en el Desoptimizador de la máquina virtual, algo completamente nuevo para mí que resultó ser un proyecto interesante y desafiante. La primera parte de mi pasantía se enfocó en mejorar la seguridad de la máquina virtual. La segunda parte se centró en mejoras de rendimiento, específicamente en la eliminación de una estructura de datos utilizada para la desvinculación de funciones previamente desoptimizadas, que representaba un cuello de botella de rendimiento durante la recolección de basura. Esta publicación describe esta segunda parte de mi pasantía. Explicaré cómo V8 solía desvincular funciones desoptimizadas, cómo cambiamos esto y qué mejoras de rendimiento se obtuvieron.

V8 tiene un límite máximo en el tamaño de su heap. Esto actúa como una salvaguarda contra aplicaciones con fugas de memoria. Cuando una aplicación alcanza este límite máximo, V8 realiza una serie de recolecciones de basura como último recurso. Si estas recolecciones no ayudan a liberar memoria, V8 detiene la ejecución y reporta un error de falta de memoria. Sin este límite, una aplicación con fugas de memoria podría consumir toda la memoria del sistema, afectando el rendimiento de otras aplicaciones.

El consumo de memoria es una dimensión importante en el espacio de compensación de rendimiento de las máquinas virtuales de JavaScript. En los últimos meses, el equipo de V8 analizó y redujo significativamente el consumo de memoria de varios sitios web identificados como representativos de los patrones modernos de desarrollo web. En esta publicación de blog presentamos las cargas de trabajo y las herramientas que utilizamos en nuestro análisis, describimos las optimizaciones de memoria en el recolector de basura y mostramos cómo reducimos la memoria consumida por el analizador y los compiladores de V8.

En una entrada de blog anterior, presentamos el problema del jank causado por la recolección de basura, que interrumpe una experiencia de navegación fluida. En esta entrada de blog introducimos tres optimizaciones que establecen las bases para un nuevo recolector de basura en V8, llamado Orinoco. Orinoco se basa en la idea de implementar un recolector de basura mayormente paralelo y concurrente sin límites generacionales estrictos, lo que reducirá el jank de la recolección de basura y el consumo de memoria, mientras proporciona un alto rendimiento. En lugar de implementar Orinoco detrás de una bandera como un recolector de basura separado, decidimos enviar las características de Orinoco de manera incremental en la rama principal de V8 para beneficiar a los usuarios de inmediato. Las tres características discutidas en esta publicación son compactación paralela, procesamiento paralelo del conjunto recordado y asignación negra.