java - online - gceasy
¿Qué significa "GC--" en un registro de recolección de basura java? (5)
No está en las preguntas frecuentes de Java GC
http://java.sun.com/docs/hotspot/gc1.4.2/faq.html
Tampoco se menciona nada de eso en la página de ejemplos de Java GC
http://java.sun.com/docs/hotspot/gc1.4.2/example.html
Nunca había visto eso antes.
¿Tiene algún colector de basura especial ejecutándose? ¿Qué VM estás ejecutando? ¿Siempre ocurre antes del GC completo? ¿Estás llamando a System.gc ()?
Hemos activado el registro detallado de GC para realizar un seguimiento de una pérdida de memoria conocida y obtuvimos las siguientes entradas en el registro:
...
3607872.687: [GC 471630K->390767K(462208K), 0.0325540 secs]
3607873.213: [GC-- 458095K->462181K(462208K), 0.2757790 secs]
3607873.488: [Full GC 462181K->382186K(462208K), 1.5346420 secs]
...
Entiendo el primero y el tercero de ellos, pero ¿qué significa el "GC--"?
Obtuve lo siguiente de aquí :
Las dos primeras líneas indican que tienes dos colecciones menores y una mayor. Los números anteriores y posteriores a la flecha 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 recuento incluye objetos que no están necesariamente vivos, pero que no pueden ser recuperados, ya sea porque están directamente vivos, o porque están dentro o referenciados de la generación titular. El número entre paréntesis es el espacio total disponible, sin contar el espacio en la generación permanente, que es el montón total menos uno El formato para la colección principal en la tercera línea es similar. La bandera -XX: + PrintGCDetails imprime información adicional sobre las colecciones. La información adicional impresa con esta bandera es susceptible de cambiar con cada versión de la máquina virtual. La salida adicional con el distintivo -XX: + PrintGCDetails en particular cambia con las necesidades del desarrollo de la Máquina Virtual de Java. de los espacios de sobrevivientes La colección menor tomó aproximadamente un cuarto de segundo.
De hecho, después de encontrar esto en nuestros registros, un compañero de trabajo y yo tenemos una explicación alternativa que parece ajustarse más a los hechos.
Notarás en este ejemplo que un GC completo sigue esta extraña línea menor de GC. Puedo confirmar que este es siempre el caso cuando aparece en nuestros registros. También puede ver que el tamaño inicial y final de Young Gen es igual, y puedo confirmar nuevamente que este es siempre el caso.
Creemos que lo que está sucediendo aquí es que el VM ha comenzado un GC menor y, después de no poder liberar nada o pasar demasiado tiempo sin poder liberar nada, decide hacer un Full.
Obtuve este tipo de líneas en mi salida de gc:
44871.602: [GC-- [PSYoungGen: 342848K->342848K(345600K)] 961401K->1041877K(1044672K), 0.1018780 secs] [Times: user=0.16 sys=0.00, real=0.11 secs]
Leí la respuesta de Yishai y tendría sentido, pero quería verlo por mí mismo en el código fuente de Java GC, cuando la JVM imprime "-" en el registro de GC y por qué.
Porque, para mi conocimiento, "Parallel Scavenge" de Young Gen es un GC de parada mundial, por lo que no podría haber objetos creados paralelamente a este GC. (ver https://blogs.oracle.com/jonthecollector/entry/our_collectors )
Puede encontrar esto en el código fuente jdk (vea http://hg.openjdk.java.net/jdk7/jdk7 ) g1CollectedHeap.cpp y psScavenge.cpp
jdk7-ee67ee3bd597/hotspot/src/share$ egrep -h -A2 -B5 -r ''"/-/-"'' *
# G1 Collector
if (evacuation_failed()) {
remove_self_forwarding_pointers();
if (PrintGCDetails) {
gclog_or_tty->print(" (to-space overflow)");
} else if (PrintGC) {
gclog_or_tty->print("--");
}
}
--
# Parallel Scavenge Collector
promotion_failure_occurred = promotion_failed();
if (promotion_failure_occurred) {
clean_up_failed_promotion();
if (PrintGC) {
gclog_or_tty->print("--");
}
}
Motivo de GC-- con el colector Parallel Scavenge
El Young GC encontró una falla en la promoción (ver http://mail.openjdk.java.net/pipermail/hotspot-gc-use/2010-March/000567.html ):
Una falla de promoción es una recuperación que no tiene éxito porque no hay suficiente espacio en la generación anterior para realizar todas las promociones necesarias. El barrido se desenrolla esencialmente y luego se realiza una compactación completa de STW de todo el montón.
"No hay espacio suficiente" no significa necesariamente que no hay suficiente espacio en la antigüedad, pero que el espacio antiguo está muy fragmentado (ver http://blog.ragozin.info/2011/10/java-cg-hotspots- cms-and-heap.html ):
[...] es imposible encontrar cierta cantidad de memoria continua para promocionar un objeto grande en particular, aunque el número total de bytes libres sea lo suficientemente grande.
Estas dos opciones de JVM podrían ayudarlo a analizar la fragmentación de su pila (consulte http://blog.ragozin.info/2011/10/java-cg-hotspots-cms-and-heap.html ):
-XX:+PrintPromotionFailure
-XX:PrintFLSStatistics=1
Motivo de GC-- con el recopilador G1
Una falla de evacuación con el G1 se produce cuando una región superviviente no tiene suficiente espacio para los objetos supervivientes de una región joven.
No sé si el G1 Collector responde a una falla de evacuación con un GC completo o no.
Yishai dijo en los comentarios:
Dadas las marcas de tiempo y las cantidades de memoria, supongo que realizó una recolección de basura pero perdió memoria disponible (porque otros objetos se crearon en paralelo)