Go utiliza un recolector de basura concurrente tri-color que hace que los objetos pasen de blanco (no marcado) a gris (en cola) y a negro (completamente escaneado). La invariante fundamental durante el marcado es que los objetos negros nunca deben contener punteros a objetos blancos, ya que esto permitiría al recolector liberar por error memoria alcanzable. Para hacer cumplir esto sin detener el mundo, Go utiliza una barrera de escritura: un gancho insertado por el compilador que se activa en cada escritura de puntero en el montón. Cuando una goroutine mutadora ejecuta una escritura de puntero, la barrera verifica si el objeto objetivo es blanco; si es así, inmediatamente lo convierte en gris antes de completar la escritura, preservando atómicamente la invariante.
Observamos una severa latencia en la cola en una tubería de análisis en tiempo real que procesaba millones de eventos por segundo. El sistema utilizaba una estructura de grafo compleja donde los nodos actualizaban frecuentemente las referencias a los nodos hijos basados en datos en streaming, causando una gran rotación de punteros durante los ciclos de GC de Go.
Primera solución considerada: Intentamos mitigar esto aumentando GOGC al 200% para retrasar las recolecciones. Pros: Redujo la frecuencia de los ciclos de GC, disminuyendo el total de ejecuciones de la barrera con el tiempo. Contras: Esto aumentó dramáticamente el tamaño máximo del montón, arriesgando fallos de OOM en nuestros contenedores con restricciones de memoria, y simplemente retrasó los picos de latencia en lugar de resolverlos.
Segunda solución considerada: Experimentamos con agrupamiento de objetos utilizando sync.Pool para reutilizar estructuras de nodos y reducir las asignaciones. Pros: Disminuyó la presión de asignación y la tasa de nuevos objetos blancos siendo creados. Contras: La sobrecarga de la barrera de escritura se mantuvo alta porque seguíamos mutando punteros dentro de objetos negros existentes (a menudo ya escaneados) a la misma tasa; el agrupamiento no abordó el costo de la ejecución de la barrera en las actualizaciones de punteros.
Tercera solución considerada: Refinamos el grafo para usar índices enteros en una gran porción en lugar de punteros directos para las relaciones de nodos. Pros: Las asignaciones enteras no son escrituras de punteros, eludiendo completamente el mecanismo de la barrera de escritura y eliminando el costo de CPU asociado durante el marcado. Contras: Esto requería implementar un manejo manual de memoria para la porción (manejo de huecos, compactación) y hacía que el código fuera menos idiomático y más difícil de mantener.
Solución elegida: Adoptamos el enfoque basado en índices para el grafo central de alta rotación, mientras manteníamos punteros para metadatos estáticos. Esto eliminó directamente el camino caliente de la barrera de escritura mientras preservaba los semánticos de conectividad del grafo.
Resultado: La latencia en la cola durante el GC cayó en un 90%, de 15 ms a 1.5 ms, y el rendimiento general aumentó en un 40% debido a la reducción del trabajo de asistencia del GC que robaba CPU a los mutadores.
¿Por qué la barrera de escritura convierte en gris el objeto al que se apunta en lugar del objeto que se está modificando?
Los candidatos suelen asumir incorrectamente que la barrera debería marcar el objeto fuente (el que se está escribiendo) como necesitando ser escaneado de nuevo. Sin embargo, la fuente ya es gris o negra; si es negra, volver a escanearla sería costoso y requeriría rastrear todos sus punteros salientes. Por el contrario, convertir el objetivo (el nuevo valor del puntero) en gris satisface inmediatamente la invariante tri-color: si la fuente es negra y el objetivo era blanco, el borde se convierte en negro-a-gris, lo cual es seguro. Esta distinción es crucial porque minimiza el trabajo (solo el nuevo objetivo se pone en cola) en lugar de requerir que se rescane potencialmente grandes objetos fuente.
¿Cómo interfiere la barrera de escritura con las asignaciones en la pila, y por qué podrían necesitar un nuevo escaneo?
Mientras que las barreras de escritura interceptan principalmente las escrituras de punteros en el montón, Go también debe manejar punteros de las pilas al montón. Si una goroutine escribe un puntero a un objeto de montón blanco en un marco de pila negro, la barrera de escritura se ejecuta para convertir el objetivo en gris. Sin embargo, debido a que las pilas pueden crecer, encogerse y ser copiadas, mantener estados precisos de negro/blanco para cada ranura de pila es complejo. Go resuelve esto tratando las pilas como raíces que pueden necesitar ser escaneadas de nuevo al final de la fase de marcado si estaban activas durante el marcado. Los candidatos frecuentemente pasan por alto que el rescaneo de pilas es una alternativa necesaria cuando las barreras de escritura en las pilas no pueden garantizar la invariante debido a la ejecución concurrente, y que esta fase final de detener el mundo suele ser breve pero esencial para la corrección.
¿Cuál es la diferencia entre la barrera de escritura de Dijkstra y la barrera de escritura de Yuasa, y cuál utiliza Go?
La barrera de Dijkstra convierte en gris el objeto objetivo cuando se instala un puntero (mutador negro, objetivo blanco), evitando que el borde negro-a-blanco exista. La barrera de Yuasa, por el contrario, registra el valor antiguo del puntero que se está sobrescribiendo y convierte eso en gris, preservando la propiedad "instantánea-al-inicio". Go utiliza una barrera híbrida de Dijkstra porque es más simple y asegura la fuerte invariante tri-color de inmediato, aunque puede causar basura flotante si un objeto blanco se vuelve inalcanzable inmediatamente después de ser convertido en gris. Los candidatos a menudo confunden esto o creen que Go usa Yuasa debido a su manejo conservador de la pila, pero entender la elección de Dijkstra explica por qué la barrera de Go es sincrónica con la escritura en lugar de basada en registros.