java - español - jvm parameters
¿La generación permanente siempre se recopila en serie en la máquina virtual de HotSpot? (1)
Después de leer una entrada de blog de Oracle bastante madura , aprendí que
(...) la generación permanente se recopila actualmente en serie.
Sin embargo, esta entrada de blog es de hace algunos años y me preguntaba cómo los recientes avances en los algoritmos de recolección de basura podrían haber cambiado la precisión de esta declaración. Me pregunto especialmente sobre el nuevo recolector de basura G1 que Oracle ha descrito con:
Los recolectores de basura más antiguos (en serie, paralelo, CMS) estructuran el montón en tres secciones: generación joven, generación anterior y generación permanente de un tamaño de memoria fijo. (...) Al realizar recolecciones de basura, G1 funciona de manera similar al recopilador de CMS.
pero nunca menciona la generación permanente en todo el tutorial nuevamente.
Después de leer sobre CMS, que según la declaración anterior funciona de manera similar a G1, tampoco encontré ninguna información explícita sobre la generación permanente, pero aprendí de esta otra entrada de blog que
(...) la marca concurrente y barrido no se compacta en absoluto. Una vez que los objetos ya no se pueden asignar, se activa un GC principal en serie.
Así que me pregunto si los recolectores de basura modernos, como CMS o G1, simplemente ignoran por completo la generación permanente y dejan invocaciones completas de GC que ejecutan el viejo GC serie para limpiar la generación permanente (mientras que este GC serie también recoge a los jóvenes y generaciones maduras en serie que no sería deseable cuando se usó G1 en lugar de CMS). Principalmente estoy interesado en saber si es más costoso en términos de STW y tiempo de recolección para realizar la recolección de basura en la generación permanente que en la recolección de la generación permanente.
Pregunta de bonificación : el tutorial de Oracle menciona que la generación permanente es parte del montón. Siempre pensé que la generación permanente estaba explícitamente asignada fuera del montón. ¿Cambió esto en implementaciones recientes de HotSpot?
¡Gracias por tu ayuda!
Existe un JEP156 sobre cómo hacer que G1 pueda descargar clases sin un GC completo, pero la sección de dependencias establece que tiene sentido esperar con [ JEP122 ] hasta que se termine la generación permanente para hacer que el JEP156 sea más fácil de implementar.
Por lo tanto, parece que este problema puede resolverse en Java 8, pero no solo gracias al metaespacio, sino porque el metaespacio se toma como un requisito previo para realizar GC de clases incrementales.
Esa es mi comprensión.
editar: En los últimos días he estado escuchando algunas de las sesiones de JavaOne de este año y, afortunadamente, encontré uno hoy sobre la eliminación de PermGen que lo dice todo:
- HotSpot actualmente requiere GC completo para recoger PermGen
- Esto seguirá siendo cierto incluso después de la introducción de Metaspace
- La diapositiva de resumen al final parece confirmar que JEP156 aún está planeado (pero ella no habla de eso)
- Incluso responde la pregunta de bonificación para la que tenía una respuesta, pero no la fuente: Sí, PermGen está en el montón