Pregunta

¿Cómo puedo monitorear la memoria utilizada por una DLL C nativa que se llama desde Java a través de JNI? Utilizando las herramientas y opciones de monitoreo estándar de Java, puedo ver el espacio de memoria de Java, pero no puedo ver ninguna memoria utilizada por la DLL de C. Java está utilizando ~ 70 MB, pero la tarea en el Administrador de tareas muestra 200 Mb +, y me gustaría ver qué hay en esos 130 MB adicionales si es posible.

¿Fue útil?

Solución

Puede supervisar el montón nativo con contadores en el monitor de rendimiento. (perfmon32) sin embargo, no lo desglosará por DLL, incluso jvm.dll se incluirá aquí.

La mayoría de las herramientas de creación de perfiles pueden conectarse a un proceso y capturar y rastrear asignaciones de memoria y desasignaciones. Esto les permite especular dónde están las fugas. Una muy buena que encontré cuando intenté rastrear las pérdidas de memoria en el código nativo que se llamó desde Java es Validador de memoria

Otros consejos

¿Ha intentado usar Visor de procesos para profundizar.

Si tiene la fuente de la DLL, puede reconstruirla con bibliotecas de depuración y posiblemente un rastreador de asignación de memoria, y depurar usando el depurador visual C ++ (deberá indicarle que use la aplicación Java).

Si no tiene la fuente, entonces las opciones son limitadas.

Creo que incluso hacer esto dentro de la DLL de C no sería muy fácil.

Hasta donde entiendo, las herramientas de Monitoreo estándar de Java recopilan información al consultar la Máquina virtual, por lo tanto, aunque esa memoria esté en el mismo proceso a menos que la máquina virtual sepa cómo inspeccionar su biblioteca vinculada dinámicamente, no podrá para ver algo Creo que necesitaría usar una herramienta externa o hacer modificaciones algo masivas a la DLL para rastrear su uso de memoria.

Bueno, dado que la DLL no es realmente parte del montón de Java, creo que la lectura más precisa sería escribir un pequeño programa de creación de perfiles (ya sea un pequeño programa Java / JNI o ??C ++ / C #, etc.) para importar y use la DLL de manera similar a su aplicación y NO HAGA NADA MÁS - solo use la DLL como lo hace - el perfil de memoria resultante de esta aplicación de creación de perfiles debería ser una buena aproximación al perfil de memoria de la DLL.

También debe probar para ver si hay una forma de memoria estática o dinámica de la DLL: tome medidas de memoria directamente antes y después de cargar la DLL para ver si hay un golpe único de ~ 130 MB, o si la memoria aumenta lentamente con el tiempo.

En Solaris / Linux, escuché que Sun Studio Collector / Analyzer es una buena herramienta para esto, pero estás atrapado en DLL-land (o DLL hell, por así decirlo)

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top