garbage-collection - algoritmos - activar garbage collector
¿Por qué el GC completo de JVM necesita detenerse en el mundo? (4)
Me hicieron esta pregunta, y acabo de responder "porque la JVM necesita mover objetos", pero luego busqué en Google y parece que no pude encontrar ninguna respuesta razonable.
stop-the-world garantiza que no se asignan objetos nuevos y que los objetos no se vuelven inalcanzables de repente mientras el colector se está ejecutando.
La ventaja es que es más simple de implementar y más rápido que la recolección de basura incremental.
Usando el GC de rendimiento, la JVM necesita pausas STW para tener la mayor cantidad de memoria posible. Solo usando tales pausas es el más efectivo.
Con el recopilador de pausas bajas (CMS), limpia la generación anterior al mismo tiempo, sin detener su aplicación. El inconveniente es que la generación anterior se fragmenta. Si está demasiado fragmentado y necesita una compactación, ocurre un GC completo (STW). Sin embargo, siempre puede sintonizar su aplicación para que no obtenga ningún GC completo.
G1 GC es un caso especial. Su objetivo principal actual es tener una baja fragmentación en el montón, sin dejar de ser concurrente (como CMS). Cuando no puede alcanzar este objetivo, la JVM también vuelve a una pausa STW para que el montón se limpie y compacte por completo.
Se necesita una breve fase stop-the-world para buscar referencias en la pila en casi cualquier esquema de recolección de basura, incluso en la mayoría de los esquemas que minimizan las pausas. Gran explicación detallada en esta respuesta . Los algoritmos incrementales y simultáneos trabajan duro para minimizar estas pausas al mínimo pero aún así las tienen en la mayoría de los casos.
Incluso existen métodos de movimiento / compactación que no necesitan detener el mundo mientras se mueven los objetos (se viene a la mente Staccato)
Primero, el artículo de Garbage Collection en wikipedia es muy bueno para leer.
Hablando de.
En general, GC no requiere pausa Stop-the-World. Hay implementaciones de JVM que están (casi) libres de pausa (por ejemplo, Azul Zing JVM ). Siempre que JVM requiera que STW recoja basura depende del algoritmo que está usando.
Mark Sweep Compact (MSC) es un algoritmo popular utilizado en HotSpot de forma predeterminada. Se implementa de forma STW y tiene 3 fases:
- MARK: gráfico de objeto en vivo transversal para marcar objetos alcanzables
- SWEEP - escanea la memoria para encontrar la memoria no marcada
- COMPACTO: reubicación de objetos marcados para desfragmentar la memoria libre
Al reubicar objetos en el montón, la JVM debe corregir todas las referencias a este objeto. Durante el proceso de reubicación, el gráfico del objeto es inconsistente, por eso se requiere una pausa STW.
Concurrent Mark Sweep (CMS) es otro algoritmo en HotSpot JVM que no utiliza la pausa STW para la antigua colección de espacio (no es exactamente lo mismo que la colección completa).
CMS utiliza la barrera de escritura (el activador actúa cada vez que escribe referencias en el montón de Java) para implementar la versión simultánea de MARK y no utiliza COMPACT. La falta de compactación puede provocar la fragmentación y, si la recolección de basura de fondo no es lo suficientemente rápida, la aplicación puede bloquearse. En estos casos, CMS recurrirá a la colección STW mark-sweep-compact.
También hay G1, que es una variación incremental de MSC. Puede leer más acerca de los algoritmos GC en HotSpot JVM en mi blog.