MemLab: Automatización de la Detección de Fugas de Memoria y Análisis de Heap

Hola a todos. Mi nombre es Liang. Trabajo en Meta, centrándome en la infraestructura de aplicaciones web y el rendimiento. Hoy daré una introducción a MemoryLab, una herramienta que construí y de código abierto para automatizar la detección de fugas de memoria en JavaScript y el análisis de montones. En Meta, una aplicación web A-B de mayor escala ha demostrado que los aumentos en el uso de memoria del lado del cliente pueden afectar significativamente la velocidad, la capacidad de respuesta, la tasa de fallos, el compromiso del usuario y, en algunos casos, incluso los ingresos de una aplicación web. MemoryLab es un marco de código abierto de Meta que automatiza la detección de memoria para aplicaciones JavaScript. También expone una potente API para recorrer instantáneas de montones, para que puedas construir análisis personalizados adaptados a tu aplicación. De fábrica, viene con herramientas CLI que prueban patrones comunes de memoria y antipatrón, y te ayudan a depurar problemas rápidamente.

Y más recientemente, hemos estado avanzando en flujos de trabajo asistidos por IA con el servidor MCP que permite a herramientas como Cloud Code razonar directamente sobre gráficos de montones. Entonces, el objetivo aquí es simple. Llevar la depuración de memoria de un proceso manual y pesado en expertos a algo automatizado, escalable, y mucho más accesible. Para profundizar en cada parte, comenzaré con la automatización de la detección de memoria. Primero necesitamos averiguar qué es una fuga de memoria. Una fuga de memoria es esencialmente un subconjunto de memoria que ha sido asignado, y se suponía que debía liberarse en algún momento, pero de alguna manera no lo fue. Entonces, la clase más amplia de estas fugas puede detectarse utilizando un enfoque de diferenciación de tres instantáneas. MemoryLab automatiza el proceso.

Para ilustrar mejor la idea, aquí usaré algunas animaciones. Supongamos que queremos encontrar fugas de memoria en la ruta B de una aplicación real. MemoryLab comienza visitando una ruta diferente, por ejemplo, la ruta A, y realiza un seguimiento de todos los objetos asignados en la ruta A, luego navega el navegador a la ruta objetivo B donde queremos encontrar fugas de memoria. Durante la navegación, algunos objetos de la ruta A se desalojan, y algunos nuevos objetos se asignan en la ruta B. Finalmente, MemoryLab navega fuera de la ruta objetivo B. Puede navegar a una ruta diferente, por ejemplo, la ruta C, o puede volver a la ruta A nuevamente. Ahora, algunos de esos objetos creados en la ruta B serán desalojados, pero algunos permanecerán vivos. Y, por supuesto, la ruta C creará algunos nuevos objetos, pero en este ejemplo realmente no nos importa ya que queremos encontrar fugas de memoria introducidas en la ruta B. Y como se destaca en la sección naranja de las diapositivas, la parte interesante son los objetos asignados en la ruta objetivo B pero que aún permanecen vivos incluso después de navegar fuera de ella. Así que hemos reducido el espacio de búsqueda, pero aún así este es un superconjunto de fugas de memoria. Para obtener fugas de memoria reales, utilizamos algunas reglas específicas del dominio para filtrar el superconjunto. Por ejemplo, la mayoría de los nodos de fibra rojos asignados desde una página deberían desalojarse después de algunas navegaciones de limpieza. Así que MemoryLab identifica todos los nodos de fibra y elementos DOM separados del superconjunto. Filtramos aún más la lista buscando nodos de fibra que mantienen vivos los elementos DOM separados.

Así que después de refinar la lista incorporando el conocimiento específico del dominio, obtenemos una lista de objetos filtrados. Ahora que la detección de memoria está hecha, el paso final es facilitar el proceso de depuración de memoria generando informes accionables. MemoryLab recorre automáticamente el montón y genera informes que explican por qué el objeto sigue vivo en la memoria. Lo hace mostrando una cadena de referencia desde la ruta del recolector de basura hasta estos objetos filtrados. Bajo el capó, MemoryLab decodifica y escanea el trabajo a las instantáneas del montón. Desde los objetos filtrados, MemoryLab busca una ruta razonable hacia la ruta del recolector de basura siguiendo ciertas reglas predefinidas para hacer que los árboles de retención sean legibles y accionables.

Los árboles de retención son cadenas de referencia desde la ruta GC hasta el objeto filtrado, y este gráfico aquí es una vista simplificada del GSHeap. En realidad, una instantánea del montón generalmente contiene millones de objetos del montón y decenas de millones de referencias entre esos objetos del montón. Estas instantáneas pueden exponer los metadatos de optimización internos de la VM y referencias específicas de implementación que son invisibles para el código JavaScript. Estos bordes pueden parecer retenedores, pero no son necesariamente referencias creadas por desarrolladores o fugas reales de la aplicación. Así que usamos Heuristic para ajustar el algoritmo de búsqueda de trazas para que la traza esté equilibrada entre ser corta y razonable para los desarrolladores.

Y el usuario puede seguir la cadena de referencia paso a paso y averiguar por qué esos objetos filtrados siguen vivos en la memoria. Muy a menudo, una sola ejecución puede detectar miles de objetos filtrados, pero esas fugas son casi siempre causadas por no más de unos pocos errores o causas raíz. Sería abrumador mostrar miles de trazas de fugas a los usuarios. Idealmente, solo queremos mostrar una traza de fuga representativa de cada causa raíz. Por ejemplo, aquí hay tres trazas de fuga causadas por el mismo error. Como puedes ver aquí, la cadena de referencia se ve más o menos igual, cada una con una pequeña variación. Entonces, ¿cómo juntamos trazas de fuga similares? Aquí es donde la agrupación de trazas de fuga podría ser de gran ayuda.

Desarrollamos un modelo híbrido que combina heurísticas y algoritmos de machine learning para agrupar trazas de fugas de memoria. Las fugas de memoria con trazas de retención similares se agrupan juntas. Para cada grupo, solo presentamos una de las trazas representativas para reducir la cantidad de trabajo de depuración. Finalmente, MemoryLab muestra la traza de retención representativa del grupo de cada fuga de memoria.

Y así es como se ve la salida en la terminal. En un formato similar al trazado de retención de Chrome DevTools. Con la IA hoy en día, es fácil copiar y pegar la traza en chat.bt o cloud code para obtener una explicación clara de esta cadena de referencia. En el repositorio de GitHub de MemoryLab, también tenemos archivos de habilidades para explicar la traza de retención de fugas de memoria. Con ese modelo mental en mente, trabajemos en cómo usar la API de MemoryLab para definir interacciones de la aplicación donde quieras encontrar fugas de memoria.

Para lograr eso, solo necesitamos crear un archivo JavaScript con tres callbacks usando la API de PubTier, indicando a MemoryLab cómo navegar por tu aplicación y qué interacción puede desencadenar la fuga. Llamamos a este archivo un archivo de escenario de prueba de MemoryLab. Y luego pasamos el archivo de escenario de prueba a las herramientas de línea de comandos de MemoryLab. MemoryLab realizará el análisis del montón de memoria que mostré anteriormente, e informará sobre fugas de memoria y trazas de retención para depuración. El primer callback en el archivo de escenario de prueba especifica la URL de carga inicial de la página.

MemoryLab abre una página web en un navegador sin cabecera y comienza a rastrear objetos asignando el montón de JavaScript. El segundo callback define la interacción donde queremos encontrar fugas de memoria. Dentro del callback, especificamos que queremos hacer clic en el botón del hotel usando la API de PubTier y el selector CSS. Todos esos son APIs estándar y bien documentadas. Bajo el capó, MemoryLab rastreará objetos asignados y liberados durante la interacción. De manera similar, en el último callback, especificamos que queremos hacer clic en un botón para navegar fuera del estado objetivo.

El segundo segmento de memoria contiene fugas de memoria que están resaltadas en la sección naranja del montón en las diapositivas. Con nuestro detector de fugas en construcción, MemoryLab verificará y filtrará esos objetos no liberados que son asignados por la interacción objetivo. Después de ejecutar el escenario de prueba, MemoryLab generará y agrupará trazas de fugas que muestran por qué y cómo los objetos filtrados aún se mantienen vivos en la memoria. El sitio de documentación de MemoryLab tiene más información sobre el uso e interpretación de los resultados.

Ahora hablemos sobre la API de MemoryLab. Además del proceso de detección de fugas predefinido y callbacks, MemoryLab también proporciona diferentes callbacks para personalizar la interacción del navegador y el proceso de detección de fugas de memoria. Por ejemplo, puedes usar la API de MemoryLab para redefinir cómo identificar fugas de memoria proporcionando una implementación de callback de filtro de fugas en el escenario de prueba por definición. El callback será llamado para cada objeto asignado pero no liberado en la interacción objetivo. Tu implementación del callback puede devolver verdadero o falso para decidir si este objeto debe considerarse como una fuga de memoria.

Para cada una de las fugas de memoria identificadas por tu implementación, MemoryLab generará la traza de fuga y la colocará en una traza representativa de clúster candidata para el resultado final. MemoryLab también pasará la referencia del gráfico del montón como un argumento al callback. La referencia es una representación del gráfico del montón orientada a objetos intuitiva de todo el montón de JavaScript, incluidos los objetos nativos y las referencias añadidas por el motor. El primer argumento de un callback es una referencia al objeto potencialmente filtrado en el gráfico del montón. Con esos argumentos, el detector de fugas autodefinido puede recorrer el montón usando la API que MemoryLab proporciona. Como ejemplo, nuestro detector de fugas incorporado sigue la cadena de retorno de un árbol ReactFibre para recorrer todo el árbol Fibre y verifica si el nodo Fibre está desconectado del árbol ReactFibre.

El programa bajo prueba probablemente tendrá un problema de memoria y por lo tanto su tamaño de montón podría no ser trivial. Queremos ser eficientes en memoria mientras proporcionamos una API de recorrido del montón orientada a objetos fácil de usar. Así que los nodos del gráfico están diseñados para ser virtuales y sus nodos están desconectados. Y cuando recorremos el montón, MemoryLab construye un gráfico justo a tiempo. Por ejemplo, al entrar en el callback, solo se construyen los nodos del gráfico correspondientes a los argumentos. Y cuando intentas consultar otros nodos, por ejemplo, los referentes de los objetos filtrados, MemoryLab creará esos nodos de entrada bajo demanda. Dado que esos nodos virtuales están desconectados, simplemente podemos establecer una referencia a ahora después de usar esos objetos del montón bajo demanda. Así que el nodo de entrada puede ser recolectado por el recolector de basura.

También puedes tomar instantáneas del montón manualmente desde Chrome DevTools, guardarlas en un disco y usar el paquete npm de MemoryLab para cargarlas, analizarlas y analizarlas programáticamente. Y nuevamente, puedes usar la API del gráfico del montón de MemoryLab para recorrer y definir tu propio analizador de montón. MemoryLab también proporciona algunos análisis de montón predefinidos a través de herramientas de línea de comandos. La CLI de MemoryLab proporciona diferentes comandos de análisis de montón. Por ejemplo, el análisis de objetos sin límites muestra qué objetos siguen creciendo con el tiempo al analizar una secuencia de instantáneas del montón. Y la aplicación de ejemplo bajo análisis mostrada en las diapositivas tiene un objeto con el aumento de tamaño de 12 kilobytes a 27 megabytes. Esto es algo que vale la pena investigar al optimizar el uso de memoria. Y puedes usar el comando de traza de MemoryLab para obtener la traza del retenedor de objetos. Hay otros comandos de CLI predefinidos de MemoryLab para encontrar anti-caminos comunes. Aquí, no mostraré todos ellos debido a la limitación de tiempo. MemoryLab también proporciona una herramienta CLI interactiva para explorar instantáneas del montón. Esto podría ser útil cuando la instantánea está en un servidor remoto, estás conectado por SSH y quieres inspeccionarlo rápidamente de forma remota. Puedes integrar MemoryLab con tu pipeline CICD interno y ejecutarlo regularmente para detectar fugas de memoria.

Como se compartió en la publicación del blog de ingeniería de Meta, esta es nuestra interfaz de usuario interna que muestra una leak trace detectada por nuestra ejecución regular interna. Esto es esencialmente una cadena de referencia desde la GC root en la parte superior de la interfaz de usuario hasta el objeto filtrado en la parte inferior de la interfaz de usuario. Le dice a los desarrolladores por qué y cómo el objeto filtrado sigue vivo en la memoria en una interfaz de usuario interactiva. Y el ámbito de función de cada objeto en la cadena de referencia se puede interactuar y mostrar su estructura interna y contenido.

El proceso de depuración es sencillo. Solo sigue la cadena de referencia un paso a la vez y eventualmente encontraremos la referencia que debería establecerse ahora para liberar el objeto retenido. Y también puedes agregar todas las leak trace representativas para dar una vista resumida. Con MemoryLab podemos encontrar optimización de memoria que lleva a ganancias significativas.

Aquí hay un ejemplo de optimización que hicimos con mi colega de Meta Benoit Durand en la versión anterior de React hace unos años. React construye un árbol de fibra para renderizar componentes. Para esta presentación, puedes ignorar la estructura del árbol de fibra y solo pensar en él como una estructura de datos interna que React usa para renderizar. Y el árbol de fibra del componente es referenciado por el host root en la parte superior. La instancia del componente React de sus nodos de fibra correspondientes se referencia entre sí.

Y todos los nodos de fibra están conectados en el árbol de fibra de React. Así que las instancias de componentes de React, los elementos del DOM y el árbol de fibra de React forman un grafo fuertemente conectado. Lo que significa que si obtienes referencia a cualquiera de los nodos en el grafo, puedes alcanzar o retener cualquier otro nodo. Idealmente, otras partes del GSTP solo están referenciando la raíz del host. Así que cuando los componentes menos importantes se montan en la versión anterior de React, simplemente rompe la conexión entre la raíz del host y el resto del árbol de fibra. Así que todo el árbol de fibra puede ser recolectado por el recolector de basura una vez que los componentes están montados.

En este caso, no hay fuga de memoria. Pero si el código de la aplicación almacena en caché referencias adicionales a la instancia del componente o a un elemento del DOM separado, la cantidad del árbol de fibra no puede ser recolectada por el recolector de basura. Dado que es un grafo fuertemente conectado, cada nodo en el grafo también se filtrará. Como ejemplo, si un archivo JS exporta la instancia del componente React que fue renderizada en una ruta anterior. Dado que la exportación de la instancia está a nivel de módulo, no se liberará y, por lo tanto, toda la cantidad de árboles de fibra se filtrará.

Este es solo un ejemplo simple para ilustración. Hay muchas maneras inesperadas en que la lógica de la aplicación puede mantener tales referencias. En Meta encontramos que una fuga singular de React a menudo causa la fuga de toda su ruta. Esto significa que a medida que navegas a otras páginas, mantendremos la mayoría de las páginas anteriores vivas en la memoria, lo que lleva a enormes fugas de memoria.

No son solo las estructuras de datos de React las que se mantenían vivas. Por hooks y sus closures, esto a menudo mantenía vivos todo tipo de objetos de producto. Y en algunas situaciones, ni siquiera era necesario filtrar el código del producto. La limpieza de React no siempre era inmediata y, por lo tanto, aún se filtraba todo el árbol de fibra de las rutas anteriores.

Así que añadimos la optimización en React introduciendo un recorrido completo del árbol de fibra en nuestro montaje para hacer una limpieza más agresiva. Esto permite que el recolector de basura haga un mejor trabajo al limpiar un árbol de fibra sin límites. Y también cualquier fuga de memoria accidental se limita a un tamaño de fuga más pequeño.

Para medir todas estas mejoras, en realidad realizamos pruebas A-B en Facebook.com y el número de bloqueos automáticos de memoria en el navegador se redujo en un 50% debido a esa optimización. Y sorprendentemente, el recorrido completo no ralentizó la página. La memoria en realidad mejoró ligeramente el rendimiento de la página y observamos mejoras significativas en muchas otras métricas.

MemoryLab también incluye una herramienta en el navegador llamada MemoryLens para visualizar fugas de memoria directamente en la capa de depuración de la interfaz de usuario de la página web. La herramienta es un módulo JS que ejecuta la aplicación. Monitorea los cambios en el árbol DOM y la fibra de React. Y MemoryLens resalta el contorno de los componentes de React filtrados cuando sus elementos DOM se separan del árbol DOM pero aún se mantienen vivos en la memoria. También adjunta un ID de memoria especial a cada elemento DOM, lo que facilita vincularlos de nuevo a la vista en las instantáneas de heap.

También puedes buscar rápidamente el ID de memoria en las herramientas de desarrollo de Chrome cuando ves un contorno de componente filtrado y su ID en la capa de depuración de la interfaz de usuario. Tenemos más detalles en la página de documentación de MemoryLab para una guía completa de MemoryLens. Finalmente, un modelo de lenguaje grande y la codificación AI son bastante poderosos en estos días. Así que quiero hablar un poco sobre cómo MemoryLab con AI puede hacer que la detección de memoria, el análisis de memoria, y la depuración de memoria sean aún más fáciles.

En el repositorio de GitHub de MemoryLab, hemos añadido archivos de habilidades enseñando a AI cómo usar correctamente las herramientas de MemoryLab y las APIs de MemoryLab. Por ejemplo, puedes proporcionar archivos de habilidades a Meta-AI, ChattBot o CloudCode, pidiéndoles que escriban un archivo de escenario de prueba de MemoryLab para una aplicación web. También puedes copiar y pegar los resultados de detección de fugas con esas herramientas AI, pidiéndoles que expliquen o solucionen la fuga de memoria basada en la salida de MemoryLab. También puedes pedir a AI que te ayude a crear un plugin de analizador personalizado para una optimización avanzada de memoria usando la API de MemoryLab.

Finalmente, quiero presentar el paquete del servidor MCP de MemoryLab. Esto te permite pedir a herramientas de codificación AI como CloudCode que investiguen fugas de memoria en instantáneas de heap de JavaScript de manera más precisa. El servidor MCP carga instantáneas de heap solo una vez en un proceso local con estado y proporciona todas las herramientas MCP que AI necesita para consultar instantáneas de heap como un grafo de heap. Con los servidores MCP, AI puede recorrer y explorar el grafo de heap tanto como quiera y hacerlo de una manera más confiable y eficiente. En lugar de analizar la instantánea de heap en bruto desde cero para cada análisis de seguimiento y solicitudes, también te ahorrará muchos tokens cuando la instantánea de heap sea enorme.

Con el servidor MMP, puedes pedir a AI todo tipo de preguntas. Por ejemplo, carga instantáneas de heap en esta ubicación y dime qué está usando más memoria. ¿Por qué este nodo de fibra sigue vivo? ¿Hay más fugas de memoria y oportunidades de optimización de memoria? ¿Puedes crear un commit de código para solucionar esta fuga de memoria, etc.? El servidor MCP también admite una herramienta de evaluación que permite a AI escribir el código de análisis de heap usando la API de MemoryLab y ejecutarlo en un entorno sandbox. Así que AI puede hacer un análisis de heap muy avanzado basado en solicitudes simples. Por ejemplo, con el servidor MCP puedes dar a AI solicitudes como encontrar formas inconsistentes de objetos o clases ocultas que desperdician memoria. AI podrá encontrar ejemplos de diferentes órdenes de inserción de propiedades que causan la polimorfismo de diferentes formas para la misma clase de objetos. Es una herramienta bastante poderosa para ayudarnos a solucionar muchos problemas de memoria en Meta de un solo golpe. Te recomendamos encarecidamente que lo pruebes.

Bien, ese es el final de mi presentación. Más demostraciones, documentación, enlaces, recursos están disponibles en el repositorio de GitHub de MemoryLab. Gracias por escuchar.