¿Por qué Go puede reducir las pausas de GC a sub 1ms y JVM no?

garbage-collection

Question

Entonces, eso es todo: https://groups.google.com/forum/?fromgroups#!topic/golang-dev/Ab1sFeoZg_8 :

Hoy envié cambios al recolector de basura que hacen que el peor de los casos típicos de detener el mundo sea menos de 100 microsegundos. Esto debería mejorar especialmente las pausas para aplicaciones con muchos goroutines activos, que previamente podrían inflar significativamente los tiempos de pausa.

Las pausas altas de GC son una de las cosas con las que los usuarios de JVM tienen problemas durante mucho tiempo.

¿Cuáles son las restricciones (arquitectónicas?) Que impiden que JVM reduzca las pausas de GC a niveles Go, pero no afectan a Go?

Answer 1

¿Cuáles son las restricciones (arquitectónicas?) Que impiden que JVM reduzca las pausas de GC a niveles de golang

No hay

Las pausas altas de GC son una de las cosas con las que los usuarios de JVM tienen problemas durante mucho tiempo.

Un poco de google muestra que soluciones similares están disponibles para Java también

• Azul ofrece un colector sin pausa que escala incluso hasta 100 GB +
• Redhat está contribuyendo con shenandoah a openjdk.
• IBM ofrece metrónomo , también apunta a tiempos de pausa de microsegundos
• varias otras JVM en tiempo real

Los otros colectores en openjdk son, a diferencia de Go, compactadores generacionales. Esto es para evitar problemas de fragmentación y proporcionar un mayor rendimiento en máquinas de clase servidor con montones grandes al permitir la asignación de punteros de relieve y reducir el tiempo de CPU gastado en GC. Y, al menos en buenas condiciones, CMS puede lograr pausas de un dígito en milisegundos, a pesar de estar emparejado con un coleccionista en movimiento de nueva generación.

El recopilador de Go es no generacional, no compacto y requiere barreras de escritura (consulte esta otra pregunta de SO ), que resulta en un menor rendimiento / más sobrecarga de CPU para las colecciones, una mayor huella de memoria (fragmentación) y menos colocación de objetos en la memoria caché. montón (diseño de memoria no compacto).