Xmx simplemente reserva espacio de direcciones virtuales. Xms en realidad lo asigna (compromete) pero no necesariamente lo predetermina.

La forma en que los sistemas operativos responden a las asignaciones varía.

Windows le permite reservar fragmentos muy grandes de espacio de direcciones (Xmx), pero no permitirá la sobreasignación (Xms). El límite está definido por swap + físico. La excepción son las páginas grandes (que deben habilitarse con una configuración de política de grupo), que lo limitará por memoria RAM física.

El comportamiento de Linux es más complicado, depende de vm.overcommit_memory y sysctls relacionados y varios indicadores que se pasan a mmap syscall, que en cierta medida pueden controlarse mediante indicadores de configuración de JVM. El comportamiento puede variar desde a) Xms puede exceder la RAM total + intercambio hasta b) Xmx está limitado por la RAM física disponible.

Respuesta corta: depende del sistema operativo, aunque definitivamente es un NO en todos los sistemas operativos populares.

Tomaré el ejemplo de la terminología de asignación de memoria de Linux aquí.

-Xms y -Xmx especifican el tamaño mínimo y máximo del montón de JVM. Estos tamaños reflejan las asignaciones de MEMORIA VIRTUAL que se pueden asignar físicamente a páginas en RAM denominadas TAMAÑO RESIDENTE del proceso en cualquier momento.

Cuando se inicie la JVM, asignará una cantidad de memoria virtual de -Xms. Esto se puede asignar a la memoria residente (memoria física) una vez que crea dinámicamente más objetos en el montón. Esta operación no requerirá que JVM solicite una nueva asignación del sistema operativo, pero aumentará su uso de RAM, porque esas páginas virtuales ahora también tendrán la asignación de memoria física correspondiente. Sin embargo, una vez que su proceso intente crear más objetos en el montón después de consumir toda su asignación de Xms en la RAM, debe solicitar al sistema operativo más memoria virtual del sistema operativo, que puede o no también asignarse a la memoria física más adelante dependiendo de cuándo. lo necesita. El límite para esto es su asignación -Xmx.

Tenga en cuenta que todo esto es posible porque la memoria en Linux es compartida. Entonces, incluso si un proceso asigna memoria de antemano, lo que obtiene es memoria virtual, que es solo una asignación ficticia contigua direccionable que puede o no asignarse a páginas físicas reales según la demanda. Lea esta respuesta para obtener una breve descripción de cómo funciona la administración de memoria en los sistemas operativos populares. Aquí hay una información muy detallada (ligeramente desactualizada pero muy útil) sobre cómo funciona la administración de memoria de Linux.

También tenga en cuenta que estas banderas solo afectan los tamaños de almacenamiento dinámico. El tamaño de la memoria residente que verá será mayor que el tamaño actual del almacenamiento dinámico de la JVM. Más específicamente, la memoria consumida por una JVM es igual a su TAMAÑO DE HEAP más MEMORIA DIRECTA que refleja las cosas que provienen de las pilas de métodos, las asignaciones de búfer nativas, etc.

¿El proceso JVM hace una reserva para la cantidad específica de memoria?

Sí, la JVM reserva la memoria especificada por Xms al principio y puede reservar hasta Xmx pero no es necesario que la reserva esté en la memoria física, también puede estar en el intercambio. Las páginas de JVM se intercambiarán dentro y fuera de la memoria según sea necesario.

¿Por qué se recomienda tener el mismo valor para Xms y Xmx?

Nota: La configuración Xms y Xmx generalmente se recomienda para sistemas de producción donde las máquinas están dedicadas a una sola aplicación (o no hay muchas aplicaciones que compiten por los recursos del sistema). Esto no generaliza, es bueno en todas partes.

Evita el tamaño del montón:

La JVM comienza con el tamaño de almacenamiento dinámico especificado inicialmente por el valor de Xms . Cuando el montón se agota debido a la asignación de objetos por parte de la aplicación. La JVM comienza a aumentar el montón. Cada vez que la JVM aumenta el tamaño del almacenamiento dinámico, debe solicitar al sistema operativo memoria adicional. Esta es una operación que requiere mucho tiempo y da como resultado un aumento en los tiempos de pausa de gc y, a su vez, en los tiempos de respuesta para las solicitudes.

Comportamiento de las aplicaciones a largo plazo:

Aunque no puedo generalizar, muchas aplicaciones a largo plazo eventualmente crecen hasta el valor máximo del almacenamiento dinámico. Esta es otra razón para comenzar con la memoria máxima en lugar de hacer crecer el almacenamiento dinámico con el tiempo y crear una sobrecarga innecesaria del cambio de tamaño del almacenamiento dinámico. Es como pedirle a la aplicación que ocupe la memoria al principio, lo que eventualmente tomará.

Número de GC: :

Comenzar con tamaños de montón pequeños da como resultado una recolección de elementos no utilizados más a menudo. Los tamaños de almacenamiento dinámico más grandes reducen la cantidad de gcs que ocurren porque hay más memoria disponible para la asignación de objetos. Sin embargo, debe tenerse en cuenta que el aumento de los tamaños de almacenamiento dinámico aumenta los tiempos de pausa de gc. Esta es una ventaja solo si su recolección de elementos no utilizados se ha ajustado correctamente y los tiempos de pausa no aumentan significativamente con el aumento de los tamaños de almacenamiento dinámico.

Una razón más para hacer esto es que los servidores generalmente vienen con grandes cantidades de memoria. Entonces, ¿por qué no usar los recursos disponibles?