Una JVM normalmente comienza asignando un montón relativamente pequeño. Luego, después de ejecutar cada GC, se comprueba para ver cuánta memoria Heap libre hay. Si la relación de montón libre a montón total es demasiado pequeña, la JVM agregará más memoria al montón (hasta el tamaño máximo de montón configurado).
Un segundo hecho relevante es que GC funciona de manera más eficiente cuando hay mucha memoria para recuperar. Siempre que no se encuentre con los límites generales de recursos del sistema (por ejemplo, activando la paginación o el intercambio), obtendrá un mejor rendimiento de la aplicación ejecutando un montón grande que uno pequeño.
Supongamos que el escritor de la aplicación sabe que la aplicación probablemente necesita una determinada cantidad de almacenamiento dinámico (por ejemplo, 4Mb) para ejecutarse cómodamente. Al establecer ese tamaño como el tamaño de pila mínimo significa que la JVM no necesita ejecutar el GC cuando el montón se llena en (digamos) 1Mb, 2Mb y 3Mb. Como resultado, la JVM ejecuta el recolector de basura menos veces durante el inicio de la aplicación y el funcionamiento normal, la aplicación se inicia más rápido y el usuario ve menos pausas de GC.
¿Sería útil un generador de perfiles para estimar los requisitos iniciales del montón de arranque? –
No directamente. Supongamos que ejecuta el generador de perfiles en una instantánea tomada cuando la aplicación se "inició". Esto le dice cómo existen los objetos en ese punto, pero no 1) cuál fue el conjunto máximo de trabajo * durante * la inicialización, o 2) cuánta memoria extra se consumirá cuando la aplicación comience a hacer cosas. En resumen, el tamaño del conjunto de trabajo después de bootstrap podría ser una estimación pobre. –