Encontrar fugas de memoria es una tarea muy difícil, especialmente cuando se trata de código JS moderno que utiliza muchas bibliotecas de terceros. Por ejemplo, actualmente me estoy enfrentando a una fuga de memoria en el resumen, que involucra a babel y un complemento de babel personalizado. Estoy explorando varias estrategias comunes para cazarlos:

1. Comprenda su tiempo de ejecución, su esquema de desasignación de memoria y siga las mejores prácticas con respecto a ese esquema.
   • Este artículo afirma que todas las implementaciones modernas de tiempo de ejecución de JS utilizan un recolector de basura Mark-and-sweep. Una de sus principales fortalezas es que puede manejar adecuadamente las referencias circulares. (El artículo también vincula este documento de taller muy desactualizado . No le preste mucha atención, ya que se trata de referencias circulares, que ya no deberían ser un problema).
   • Este artículo profundiza en la administración de memoria V8 (NOTA: Node y Chrome se basan en V8).
2. Si encuentra que el uso de la memoria o del GC supera sus expectativas, analice su perfil de memoria en montón para averiguar dónde se asigna la memoria.
   • Esta respuesta SO explica cómo hacerlo en Chrome, pero sus enlaces están desactualizados. Este es un enlace directo a la documentación relevante de Chrome (a partir de 2021).
   • Para Node, encontré mucha información desactualizada. Actualmente, la forma más fácil de analizar su perfil de memoria de pila parece ser usando el argumento de línea de comando experimental --heap-prof (por ejemplo node --heap-prof node_modules/rollup/dist/bin/rollup -c para analizar una compilación acumulada) . Luego ábralo en Chrome Dev Tools, a través de Memory -> Load .
   • Una vez analizado, podemos comprender dónde/cómo se asignó la mayor parte de la memoria; pero una pregunta crucial aún no ha sido respondida:
3. Dado que sabe quién es el culpable (el acaparador de memoria), ¿cómo puede averiguar por qué / dónde aún persisten? Y, lo que es más importante: ¿Cuál es la raíz de GC (puntero de pila) del objeto que acapara la memoria?

Esta última pregunta es también mi pregunta aquí: ¿Cómo podemos analizar el árbol de asignación de objetos en Node (o en V8 en general)? ¿Cómo puedo saber dónde están pateando los objetos que identifiqué en el paso (2)?

A menudo, es la respuesta a esta pregunta la que nos dice dónde cambiar nuestro código para detener la fuga. (Por supuesto, si su problema es la rotación de memoria , en lugar de pérdidas de memoria, entonces esta pregunta probablemente no sea tan importante).

En mi ejemplo, sé que la memoria está ocupada por nodos AST de Babel y objetos de ruta, pero no sé por qué persisten, es decir, no sé dónde están almacenados. Si solo ejecuta Babel por su cuenta, puede verificar que no es Babel la que está perdiendo la memoria. Actualmente estoy probando todo tipo de trucos para averiguar dónde se almacenan, pero aún no tengo suerte.

Lamentablemente, hasta ahora, no he encontrado ninguna herramienta que me ayude con la pregunta (3). Incluso los artículos detallados relevantes (como este y su presentación de diapositivas aquí) elaboran MANUALMENTE los pasos de asignación del almacenamiento dinámico. Parece que no existe tal herramienta, ¿o me equivoco? Si no hay una herramienta, ¿tal vez hay una discusión sobre esto en alguna parte?