Para la JVM de Sun/Oracle, he leído que el algoritmo GC divide la nueva generación en una región Eden y dos regiones supervivientes. Lo que me pregunto es, ¿por qué dos regiones sobrevivientes y no solo una? El algo puede mantener ping-ponging entre Eden y solo una región de supervivientes (como lo hace actualmente entre dos regiones de supervivientes); o hay alguna falla en este enfoque?Java GC: ¿por qué dos regiones sobrevivientes?
Creo que la implementación de GC de JRockit funciona más como usted sugiere, con solo un eden y un único espacio de superviviente, pero no me cite sobre eso.
El motivo de los dos espacios supervivientes de HotSpot JVM es reducir la necesidad de lidiar con la fragmentación. Los nuevos objetos se asignan en el espacio eden. Todo bien y bien Cuando está lleno, necesita un GC, así que elimine los objetos viciados y mueva los vivos a un espacio de supervivencia, donde puedan madurar durante un tiempo antes de ser promovidos a la generación anterior. Aún así hasta ahora. La próxima vez que nos quedemos sin espacio, tenemos un enigma. El siguiente GC aparece y borra algo de espacio tanto en eden como en nuestro espacio de supervivientes, pero los espacios no son contiguos. Entonces, ¿es mejor
La respuesta de Sun a la pregunta es obvia.
No es obvio para mí. ¿Qué alternativa sigue HotSpot JVM? – vz0
Gracias por una respuesta muy clara y precisa. Si es posible, también puedes pl. comentar sobre qué opción utiliza JRockit? – shrini1000
@ vz0: es la tercera opción. – shrini1000
¿Cuáles son las ventajas y desventajas de copiar todas las instancias de una generación de un espacio a otro, en lugar de copiarlas en orden de direcciones de memoria al comienzo del espacio de una generación? Procesar elementos en orden probablemente requeriría agregar un puntero adicional por artículo, pero eliminaría la necesidad de uno de los espacios de "sobreviviente".
El papel de los dos espacios de supervivencia consigue invirtió después de la operación de una recolección de basura menor
Los dos espacios de supervivencia. Estos contienen objetos que han sobrevivido al menos a una pequeña recolección de basura, pero se les ha dado otra oportunidad de ser inalcanzable antes de ser promovidos a la generación anterior. Solo uno de ellos contiene objetos, mientras que el otro es la mayor parte del tiempo sin usar.
Durante el funcionamiento de una recolección de basura menor, se marcarán los objetos que se han encontrado como basura. Los objetos vivos en el edén que sobreviven a la colección se copian en el espacio del sobreviviente no utilizado. Los objetos vivos en el espacio de sobrevivientes que están en uso, que tendrán otra oportunidad de recuperarse en la generación joven, también se copiarán en el espacio del sobreviviente no utilizado. Finalmente, los objetos vivos en el espacio del sobreviviente que están en uso, que se consideran "suficientemente viejos", se promueven a la generación anterior.
Al final de la recolección de basura secundaria, los dos espacios de supervivencia intercambian roles. El eden está completamente vacío; solo un espacio de sobreviviente está en uso; y la ocupación de la generación anterior ha crecido levemente. Debido a que los objetos vivos se copian durante su operación, este tipo de recolector de basura se llama recolector de basura.
Fuente: de arriba son los extractos de la página 83 de Java Performance, por Charlie Hunt y Binu John.
generación joven: Es lugar donde vivió por un período breve y se divide en dos espacios:
espacio Edén: Los nuevos objetos serán asignados en el bloque de memoria. La suposición es que la mayoría de los objetos se desreferencian y se vuelven inalcanzables poco después de su creación. Los objetos que no están siendo desreferenciados serán copiados por el recolector de basura de nueva generación en los espacios de sobrevivientes. Se pueden copiar en algunos casos especiales directamente en el grupo de la generación anterior.
Espacios supervivientes: Estos dos espacios pequeños conservan los objetos supervivientes de una colección de basura de generación joven. Los objetos sobrevivientes se copiarán por un número (pequeño) de veces de un sobreviviente al otro. Esto permite cosechar nuestros objetos más desreferenciados.
Generación anterior: El grupo de memoria más grande que debe mantener los objetos vivos largos. Los objetos se copian en este grupo una vez que salen de los espacios de sobrevivientes.
Permament generation: Este grupo bastante desconocido mantiene la información de todas las clases. No necesita atención para la mayoría de las aplicaciones. Puede necesitar ser adaptado para algunas aplicaciones con muchas clases. También puede necesitar algo de asistencia si la aplicación carga y descarga permanentemente las clases.
Otras ventajas:
Por favor, encontrar los siguientes enlaces para más detalles que pueden ayudar a entender más
Toda la respuesta actual habla sobre la fragmentación de la memoria, esta es también otra razón para tener generaciones en GC.
El tiempo de ejecución registra todos los "objetos antiguos" que apuntan a "objetos nuevos", esto se hace cada vez que se actualiza un campo "puntero". Luego, cuando se realiza un GC "minero", solo se deben escanear los objetos "nuevos".
Con los años se ha descubierto que tener "nuevo" y "viejo" no es suficiente, y es bueno tener una tercera generación que sea "de mediana edad".
Dos supervivientes son la implementación del algoritmo de marca y copia. Estos se utilizan en GC para la generación más joven. Como se ha mencionado por Ryan en la opción 3 here
interesante - ¿le importaría publicar el enlace (s) a donde se lee acerca de esto? Creo que eso ayudaría a la pregunta. ** Editar: ** [este artículo] (http://javarevisited.blogspot.com/2011/04/garbage-collection-in-java.html) parece describirlo, no estoy seguro de si es el mismo que lees. –
Paul Bellora: no este enlace por decir, pero lo he leído en varios libros y artículos. Publicaremos estos enlaces pronto. – shrini1000
@Paul Bellora Esto es para Java 5, pero menciona 'to' y 'from' espacios de supervivencia: http://www.oracle.com/technetwork/java/javase/memorymanagement-whitepaper-150215.pdf – shrini1000