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í sobre la detección automatizada de fugas de memoria en JavaScript y el análisis de heap de código abierto. En Meta, una aplicación web a mayor escala ha demostrado que los aumentos en el uso de memoria del lado del cliente pueden impactar significativamente en la velocidad, capacidad de respuesta, tasa de fallos, participación del usuario y, en algunos casos, incluso en los ingresos.

MemoryLab es un marco de trabajo 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 heap, por lo que puedes construir análisis personalizados adaptados a tu aplicación. De fábrica, viene con herramientas CLI que prueban patrones comunes de memoria y anti-patrones y te ayudan a depurar problemas rápidamente. 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 heap. Así que 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 fugas de memoria. Primero necesitamos averiguar qué es una fuga de memoria. Una fuga de memoria es esencialmente un subconjunto de memoria que ha sido asignada, y se suponía que debía ser liberada en algún momento, pero de alguna manera no lo fue. Así que la clase más amplia de estas fugas puede ser detectada usando 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 lleva un registro 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 son desalojados, y algunos nuevos objetos son asignados 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 es el objeto asignado en la ruta objetivo B, pero que aún permanece vivo 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, usamos 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 ser desalojados 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 elementos DOM separados vivos. 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 heap y genera informes que explican por qué el objeto sigue vivo en 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 instantáneas de heap. Desde los objetos filtrados, MemoryLab busca un camino razonable hacia la ruta del recolector de basura siguiendo ciertas rutas 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 del GC hasta el objeto filtrado. Este gráfico aquí es una vista simplificada del heap de GS. En realidad, una instantánea de heap generalmente contiene millones de objetos de heap y decenas de millones de referencias entre esos objetos de heap. Estas instantáneas pueden exponer los metadatos de optimización interna 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 una fuga real de la aplicación. Usamos Heuristic para ajustar el algoritmo de búsqueda de trazas para que la traza esté equilibrada entre ser corta y ser razonable para los desarrolladores. El usuario puede seguir la cadena de referencia paso a paso y averiguar por qué esos objetos filtrados aún se mantienen vivos en 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 filtradas a los usuarios. Idealmente, solo queremos mostrar una traza representativa de fuga 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 agrupamos trazas de fuga similares? Aquí es donde el agrupamiento de trazas de fuga podría ser de gran ayuda.

Desarrollamos un modelo híbrido que combina heurísticas y algoritmos de aprendizaje automático 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 de cada grupo de fugas de memoria. Y así es como se ve la salida en Terminal.

En un formato similar, es la traza de retención en Chrome DevTools. Con la IA hoy en día, es fácil copiar y pegar la traza en chat GVT o cloud code para obtener una explicación clara de esta cadena de referencia. En el repositorio de GitHub de MemoryLab, también tenemos un archivo de habilidades para explicar la traza de retención de fugas de memoria. Con el modelo mental en su lugar, vamos a recorrer cómo usar la API de MemLab para definir interacciones de aplicaciones donde deseas encontrar fugas de memoria.

Para lograr eso, solo necesitamos crear un archivo JavaScript con tres callbacks usando la API de PubTier, indicando a MemLab cómo navegar tu aplicación y qué interacción puede desencadenar la fuga. Llamamos a este archivo un archivo de escenario de prueba de MemLab, y luego pasamos el archivo de escenario de prueba a las herramientas de línea de comandos de MemLab. MemoryLab realizará el análisis del heap de memoria que mostré anteriormente y reportará 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 cabeza y comienza a rastrear objetos asignados en el heap 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. Todas son APIs estándar y bien documentadas. Bajo el capó, MemLab 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 se destacan en la sección naranja del heap en las diapositivas. Sin construir un detector de fugas, 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 fuga, que muestran por qué y cómo los objetos filtrados aún se mantienen vivos en la memoria. Los sitios de documentación de MemoryLab tienen más información sobre el uso e interpretación de los resultados.

Ahora hablemos de la API de MemoryLab. Además del proceso de detección de fugas predefinido y los 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 la definición del archivo de escenario de prueba. El callback se llamará 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 candidato para la salida final.

MemoryLab también pasará la referencia del gráfico de heap como un argumento al callback. La referencia es una representación intuitiva orientada a objetos del gráfico de heap completo de JavaScript incluyendo objetos nativos y referencias añadidas por el motor. El primer argumento de un callback es una referencia al objeto potencialmente filtrado en el gráfico de heap. Con esos argumentos, el detector de fugas autodefinido puede recorrer el heap usando la API que proporciona MemoryLab. Como ejemplo, nuestro detector de fugas de construcción sigue la cadena de retorno de un árbol ReaTaFiber para recorrer todo el árbol de fibras y verifica si el nodo de fibra está desconectado del árbol ReaTaFiber. El programa bajo prueba probablemente tendrá un problema de memoria y por lo tanto su tamaño de heap podría no ser trivial.

Queremos ser eficientes en memoria mientras proporcionamos una API de recorrido de heap orientada a objetos fácil de usar. Así que los nodos del gráfico están diseñados para ser virtuales y estos nodos están desconectados. Cuando recorremos el heap, 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 entrantes bajo demanda. Dado que esos nodos virtuales están desconectados, simplemente podemos establecer la referencia a ahora después de usar esos objetos de heap bajo demanda. Así que el nodo entrante puede ser recolectado como basura.

También puedes tomar instantáneas de heap manualmente desde Chrome DevTools, guardarlas en un disco y usar el paquete npm de MemoryLab para cargarlas programáticamente, analizarlas y parsearlas. Y nuevamente, puedes usar la API de gráfico de heap de MemoryLab para recorrer y definir tu propio analizador de heap. MemoryLab también proporciona algunos análisis de heap predefinidos a través de herramientas de línea de comandos. La CLI de MemoryLab ofrece diferentes comandos de análisis de heap. Por ejemplo, el análisis de objetos sin límite muestra qué objetos siguen creciendo con el tiempo al analizar una secuencia de instantáneas de heap. Y la aplicación de ejemplo bajo análisis mostrada en las diapositivas tiene un objeto con un aumento de tamaño de 12 kilobytes a 27 megabytes. Esto es algo que vale la pena investigar al optimizar el uso de la memoria. Y puedes usar el comando de traza de MemoryLab para obtener la traza del retenedor del objeto. Hay otros comandos predefinidos de la CLI de MemoryLab para encontrar antipaths comunes. Aquí, no mostraré todos debido a la limitación de tiempo.

MemoryLab también proporciona una herramienta CLI interactiva para explorar instantáneas de heap. Esto podría ser útil cuando la instantánea está en un servidor remoto, estás conectado por SSH y quieres inspeccionarla rápidamente de forma remota. Puedes integrar MemoryLab con tu pipeline interno de CICD y ejecutarlo regularmente para detectar las fugas de memoria. Como se compartió en la publicación del blog de ingeniería de Meta, esta es nuestra interfaz interna que muestra una traza de fuga detectada por nuestra ejecución regular interna. Esto es esencialmente una cadena de referencia desde la raíz de GC en la parte superior de la interfaz hasta el objeto filtrado en la parte inferior de la interfaz. Le dice a los desarrolladores por qué y cómo el objeto filtrado sigue vivo en la memoria en una interfaz interactiva. Cada objeto y ámbito de función 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 trazas de fuga representativas para dar una vista resumida. Con MemoryLab, podemos encontrar optimizaciones de memoria que llevan a ganancias significativas. Aquí hay un ejemplo de optimización que hicimos con mi colega de Meta Benoit Girard en la versión anterior de React hace unos años. React construye un árbol de Fibre para renderizar componentes. Para esta presentación, puedes ignorar la estructura del árbol de Fibre y solo pensar en él como la estructura de datos interna que React usa para renderizar. El árbol de componentes Fibre es referenciado por la raíz del host en la parte superior. La instancia del componente React y sus correspondientes nodos Fibre se referencian entre sí. De manera similar, los elementos DOM y sus correspondientes nodos Fibre también se apuntan entre sí. Y todos los nodos Fibre están conectados en el árbol de React Fibre. Así que las instancias de componentes React, los elementos DOM y el árbol de React Fibre forman un gráfico fuertemente conectado.

Es decir, si obtienes referencia a cualquiera de los nodos en el gráfico, puedes alcanzar {{^}}Es decir, si obtienes referencia a cualquiera de los nodos en el gráfico, puedes alcanzar o retener cualquier otro nodo en el gráfico. Idealmente, otras partes del GSTP solo están referenciando la raíz del host. Así que cuando los componentes menos se montan en versiones anteriores de React, simplemente rompe la conexión entre la raíz del host y el resto del árbol de Fibre. Así que todo el árbol de Fibre 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 DOM separado, la cantidad del árbol de Fibre no puede ser recolectada por el recolector de basura. Dado que este es un gráfico fuertemente conectado, cada nodo en el gráfico también se filtrará.

Como ejemplo, si un archivo GS exporta la instancia del componente React que fue renderizado en una ruta anterior ya que la exportación de la instancia está a nivel de módulo, no será liberada y por lo tanto toda la cantidad de árboles de Fibre se filtró. Y 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 sola fuga de React a menudo causa la fuga de toda la ruta. Esto significa que a medida que navegas a otras páginas, mantendremos la mayoría de las páginas anteriores vivas en memoria, llevando a enormes fugas de memoria. Y no solo son las estructuras de datos de React las que se mantienen vivas.

Por hooks y sus cierres, esto a menudo mantendría vivos todo tipo de objetos de producto. Y en algunas situaciones, filtrar el código del producto ni siquiera era necesario. La limpieza de React no siempre era inmediata y por lo tanto aún filtra todo el árbol de Fibre de las rutas anteriores. Así que añadimos la optimización en React introduciendo un recorrido completo del árbol de Fibre al desmontar para hacer una limpieza más agresiva. Esto permite que el recolector de basura haga un mejor trabajo al limpiar el árbol de Fibre desmontado. Y también cualquier fuga de memoria accidental, está limitada a un tamaño menor. Para medir todas estas mejoras, de hecho realizamos pruebas A-B en Facebook.com. El número de bloqueos automáticos de memoria en el navegador se redujo en un 50% debido a esa optimización.

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 de hecho mejoró ligeramente el rendimiento de la página.

Y observamos mejoras significativas en muchos otros métricas. MemoryLab también incluye una herramienta en el navegador llamada Memory Lens para visualizar las 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 GS que se ejecuta en la aplicación.

Monitorea los cambios en el árbol DOM y React Fibre. Y Memory Lens resalta el contorno de los componentes 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, facilitando vincularlos de nuevo a la vista en las instantáneas de heap. También puedes buscar rápidamente el ID de memoria en las Chrome DevTools 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 para Memory Lens. Finalmente, un modelo de lenguaje grande y la codificación con IA son bastante poderosos hoy en día. Quiero hablar un poco sobre cómo MemoryLab con IA 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 habilidades para enseñar a la IA cómo usar correctamente las herramientas de MemoryLab y las APIs de MemoryLab.