Actualmente estoy probando mi prototipo de prototipo de concepto relacionado con el esquema XML y, en torno a una biblioteca externa que consume mucha memoria para los autómatas de árbol (para los que tengo las fuentes), me gustaría trazar un "pico real" (montón ) el consumo de memoria de las diferentes ejecuciones con tamaños de esquema crecientes (la métrica utilizada se ajusta a mi propósito y no afecta la pregunta), o al menos una aproximación razonable de la misma.

Para dar un orden de magnitud, para una ejecución con un pico real de 100 MB (lo probé ejecutando varias veces exactamente la misma configuración de entrada / parámetros, forzando la memoria jvm con -Xmx y -Xms a valor decreciente, obtengoExcepción en el hilo "main" java.lang.OutOfMemoryError: límite de sobrecarga del GC excedido <100MB, con resultados estables y repetibles) ocupa alrededor de 1.1GB, por eso es extremadamente importante para mí obtener el número real, ¡porque difieren mucho!

He pasado los últimos 10 días leyendo preguntas en la web y en stackoverflow, lo que realmente sé es:

System.gc () "sugiere" una ejecución de GC, no la fuerza de ninguna manera, por lo que no es posible confiar en ella para detectar picos de uso de memoria

Lo que generalmente se sugiere es contar la ocupación de objetos (viTamaño de proyecto para esto, lo intenté y funciona bien, aunque no se ajuste a mis necesidades), eso no es factible para mí porque la asignación de memoria pesada ocurre debido a la creación de una gran cantidad de iteradores de colección (conjunto, lista y mapa) en diferentes métodos, llamados un número muy alto de veces (por ejemplo, millones para una ejecución de 10 minutos para lo que recuerdo), por lo que sería extremadamente difícil detectar todos los objetos involucrados y realizar las sumas (depuré muchas muchas ejecuciones en días con gráficos de consumo de memoria sin poder identificar un solo cuello de botella)

No hay forma de obtener fácilmente la ocupación de memoria de un método (expresado como el pico de asignación de memoria de objeto)

El hecho es que experimenté por mi mismo que las llamadas a System.gc () no son confiables (por ejemplo, diferentes ejecuciones de la misma configuración, diferentes lecturas de memoria después de un System.gc () debido a que el GC se llama realmente o no), pero cuando Presiono el "botón GC" en JVisualVM o JconsoleNunca no ejecuta GC o se niega a hacerlo.

Así que mi pregunta es: llamar a su implementación de ese botón (no lo probé todavía, pero por lo que he leído hasta ahora parece posible usar jconsole.jar conadjuntar api) será diferente de llamar a System.gc () directamente desde mi código, por lo tanto, ¿resolveré mi problema? Si no, ¿cómo explica el "comportamiento determinista" de ese botón?

Hasta ahora realicé algunas pruebas manuales del pico de memoria real dado 10 tamaños de esquema crecientes (para este tipo de medidas, los esquemas se generan automáticamente a partir de un solo "parámetro de complejidad") y representé la curva esperada, si no puedo obtener una mejor solución Quiero ejecutar mi código como un archivo externo con -Xmx / -Xms igual a un poco menos que mi predicción del pico de memoria esperado, capturando la excepción OutMemoryException en el proceso externo ErrorStream y reiniciando con más memoria hasta que se complete la ejecución se consigue. (Si la predicción de memoria ingenua no será lo suficientemente robusta, aplicaré las técnicas de Aprendizaje automático adecuadas). Sé que esta no es una solución elegante, pero en mi escenario (académico) puedo permitirme dedicar un poco de tiempo extra a estas mediciones. Si tiene otras sugerencias o mejoras en este método de fuerza bruta, puede (muy) ser bienvenido a compartirlas.

Información del sistema (la máquina es un Fedora 17, 64 bit):

Versión Java "1.7.0_04" Java (TM) SE Runtime Environment (compilación 1.7.0_04-b20) VM de servidor de 64 bits de Java HotSpot (TM) (compilación 23.0-b21, modo mixto)

Gracias de antemano, Alessandro