xmn - Comportamiento del montón de Java

parametros xms xmx java

Question

Dada una configuración de memoria Java como la siguiente

 -Xmx2048m -Xms512m

¿Cuál sería el comportamiento de la máquina virtual cuando el uso de memoria aumenta más allá de 512 m? ¿Hay un algoritmo particular que sigue? es decir. ¿Va directo al máximo, se duplica, va en incrementos o solo se asigna porque necesita memoria? ¿Qué tan costosa es una operación?

Estoy buscando específicamente Oracle / Sun JVM, versión 1.6. Supongo que esto está documentado en el sitio web de Oracle en alguna parte, pero tengo problemas para encontrarlo.

Answer 1

El trabajo del recolector de basura es decidir cuándo es necesario cambiar el tamaño, por lo que está determinado por el parámetro GC ''MinFreeHeapRatio''. Si el GC necesita más espacio, crecerá hasta un tamaño donde esté disponible el% del montón especificado por ese valor.

Un valor típico en una plataforma moderna es 40ish, por lo que si comienza en 512MB y tiene menos del 40% gratis, lo que significa que excedió ~ 308MB, aumentará hasta que el 40% vuelva a ser gratuito. Entonces, después de la recolección, todavía hay 400 MB de objetos en vivo, su montón aumentará a ~ 667 MB. (Sí, se denomina razón pero espera un valor% como argumento ... ¡búscame!)

Tenga en cuenta que esto es un poco inexacto, el recolector de basura es "generacional" y de hecho puede cambiar el tamaño de generaciones individuales, pero también tiene relaciones forzadas entre generaciones y si sus objetos se distribuyen entre vida larga y vida corta en aproximadamente la forma en que lo estima, funciona bastante bien para la parte posterior del sobre.

Esto se aplica a los valores predeterminados en Java 6. Si usa la configuración personalizada del recolector de basura, puede ser diferente. Puede leer sobre esto aquí: http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html#generation_sizing.total_heap

(El "gasto" de la operación depende del sistema operativo y de qué más está sucediendo. Si el sistema está cargado y el sistema operativo tiene que hacer un intercambio para crear un bloque contiguo de memoria para usted, entonces podría ser ¡muy caro!)

Answer 2

Cabe señalar que JVM on Initialization virtualmente reserva el máximo espacio de direcciones pero no asigna memoria física. Normalmente, la JVM asignará espacio a la generación Antigua y Joven. Hay espacio intermidatorio en la generación joven. Los nuevos objetos invocados están contenidos en la Generación Joven.

Cuando se llena el espacio intermidatorio, se invoca a GC que mueve Objetos de referencia a uno de los espacios Intermitentes llamado Espacio de Sobrevivientes en el Segmento de Generación Joven. El GC podría seguir "pare el mundo" guardando el algoritmo de estado del hilo o un alogoritmo para que los procesos sigan funcionando (?).

Cuando el espacio Survivor llena JVM invoca un GC completo.

Answer 3

El uso de las opciones -XX:+PrintGCDetails -verbose:gc y / o -XX:+PrintGCDetails debería darle muchos detalles más finos.

Aquí hay un ejemplo de salida con la opción -verbose:gc activada:

[GC 325407K->83000K(776768K), 0.2300771 secs]
[GC 325816K->83372K(776768K), 0.2454258 secs]
[Full GC 267628K->83769K(776768K), 1.8479984 secs]

Una explicación de lo anterior tomada del documento oficial:

Aquí vemos dos colecciones menores seguidas de una colección principal. Los números anteriores y posteriores a la flecha (p. Ej., 325407K->83000K de la primera línea) indican el tamaño combinado de los objetos vivos antes y después de la recolección de basura, respectivamente. Después de colecciones menores, el tamaño incluye algunos objetos que son basura (que ya no está viva) pero que no pueden recuperarse. Estos objetos están contenidos en la generación titular, o se hace referencia a partir de las generaciones permanentes o permanentes.

El siguiente número entre paréntesis (por ejemplo, ( 776768K ) nuevamente desde la primera línea) es el tamaño comprometido del montón: la cantidad de espacio utilizable para objetos Java sin solicitar más memoria del sistema operativo. Tenga en cuenta que este número no incluye uno de los espacios de supervivientes, ya que solo uno puede utilizarse en cualquier momento dado y tampoco incluye la generación permanente, que contiene los metadatos utilizados por la máquina virtual.

El último elemento de la línea (por ejemplo, 0.2300771 secs ) indica el tiempo necesario para realizar la recolección; en este caso, aproximadamente un cuarto de segundo.

El formato para la colección principal en la tercera línea es similar.

La ejecución de una aplicación de esta manera junto con la actualización de los tamaños mínimo y máximo de almacenamiento dinámico puede dar una buena idea de la asignación de almacenamiento dinámico y los patrones de recolección de basura de la máquina virtual.