Go impiega un garbage collector concorrente tri-colore in cui gli oggetti passano da bianco (non marcato) a grigio (in coda) a nero (completamente scansionato). L'invariante fondamentale durante la marcatura è che gli oggetti neri non devono mai contenere puntatori a oggetti bianchi, poiché ciò consentirebbe al collector di liberare erroneamente memoria raggiungibile. Per farlo senza fermare il mondo, Go utilizza un barrier di scrittura: un gancio inserito dal compilatore attivato su ogni scrittura di puntatore nell'heap. Quando un goroutine mutatore esegue una scrittura di puntatore, il barrier controlla se l'oggetto di destinazione è bianco; in tal caso, annerisce immediatamente l'oggetto di destinazione in grigio prima di completare la scrittura, preservando atomisticamente l'invariante.
Abbiamo osservato una grave latenza in coda in un pipeline di analisi in tempo reale che elaborava milioni di eventi al secondo. Il sistema utilizzava una struttura grafica complessa in cui i nodi aggiornavano frequentemente i riferimenti ai nodi figlio in base ai dati in streaming, causando un'enorme rotazione dei puntatori durante i cicli di GC di Go.
Prima soluzione considerata: Abbiamo tentato di mitigare questo aumentando GOGC al 200% per ritardare le raccolte. Pro: Riduzione della frequenza dei cicli di GC, abbassando il conteggio totale delle esecuzioni del barrier nel tempo. Contro: Ciò ha aumentato drammaticamente la dimensione massima dell'heap, rischiando crash OOM sui nostri contenitori a memoria limitata e ha semplicemente ritardato i picchi di latenza anziché risolverli.
Seconda soluzione considerata: Abbiamo sperimentato con il pooling degli oggetti usando sync.Pool per riutilizzare le strutture dei nodi e ridurre le allocazioni. Pro: Riduzione della pressione di allocazione e del tasso di nuovi oggetti bianchi creati. Contro: L'overhead del barrier di scrittura è rimasto alto perché stavamo ancora mutando puntatori all'interno di oggetti neri esistenti (spesso già scansionati) allo stesso ritmo; il pooling non affrontava il costo dell'esecuzione del barrier sugli aggiornamenti dei puntatori.
Terza soluzione considerata: Abbiamo rifattorizzato il grafo per utilizzare indici interi in un grande slice piuttosto che puntatori diretti per le relazioni tra i nodi. Pro: Le assegnazioni intere non sono scritture di puntatori, bypassando completamente il meccanismo del barrier di scrittura ed eliminando il costo CPU associato durante la marcatura. Contro: Ciò ha richiesto di implementare una gestione della memoria manuale per lo slice (gestione dei vuoti, compattazione) e ha reso il codice meno idiomatico e più difficile da mantenere.
Soluzione scelta: Abbiamo adottato l'approccio basato su indici per il grafo principale ad alta rotazione, mantenendo i puntatori per i metadati statici. Questo ha eliminato direttamente il percorso caldo del barrier di scrittura preservando la semantica di connettività del grafo.
Risultato: La latenza in coda durante il GC è diminuita del 90%, passando da 15ms a 1.5ms, e la produttività complessiva è aumentata del 40% grazie all'assistenza GC che sottraeva CPU dai mutatori.
Perché il barrier di scrittura annerisce l'oggetto a cui si punta anziché l'oggetto modificato?
I candidati spesso presumono erroneamente che il barrier debba contrassegnare l'oggetto sorgente (quello a cui si scrive) come necessitante di nuova scansione. Tuttavia, la sorgente è già grigia o nera; se è nera, riesaminarla sarebbe costoso e richiederebbe il tracciamento di tutti i suoi puntatori uscenti. Al contrario, annerire il bersaglio (il nuovo valore del puntatore) in grigio soddisfa immediatamente l'invariante tri-colore: se la sorgente è nera e il bersaglio era bianco, il collegamento diventa nero-a-grigio, il che è sicuro. Questa distinzione è cruciale perché minimizza il lavoro (solo il nuovo bersaglio è messo in coda) piuttosto che richiedere che oggetti sorgente potenzialmente grandi siano riesaminati.
Come interagisce il barrier di scrittura con le allocazioni nello stack, e perché gli stack potrebbero necessitare di una nuova scansione?
Sebbene i barrier di scrittura intercettino principalmente le scritture di puntatori nell'heap, Go deve anche gestire puntatori dallo stack all'heap. Se un goroutine scrive un puntatore a un oggetto heap bianco in un frame dello stack nero, il barrier di scrittura viene eseguito per annerire il bersaglio. Tuttavia, poiché gli stack possono crescere, ridursi e essere copiati, mantenere stati precisi di nero/bianco per ogni slot dello stack è complesso. Go risolve questo trattando gli stack come radici che potrebbero necessitare di una nuova scansione alla fine della fase di marcatura se sono stati attivi durante la marcatura. I candidati spesso trascurano che la nuova scansione dello stack è un ripiego necessario quando i barrier di scrittura sugli stack non possono garantire l'invariante a causa dell'esecuzione concorrente, e che questa fase finale di fermare il mondo è solitamente breve ma essenziale per la correttezza.
Qual è la differenza tra il barrier di scrittura di Dijkstra e il barrier di scrittura di Yuasa, e quale utilizza Go?
Il barrier di Dijkstra annerisce l'oggetto di destinazione quando un puntatore viene installato (mutatore nero, bersaglio bianco), impedendo l'esistenza del collegamento nero-a-bianco. Il barrier di Yuasa, al contrario, registra il valore vecchio del puntatore che viene sovrascritto e lo annerisce, preservando la proprietà "istantanea-all'inizio". Go utilizza un barrier ibrido di Dijkstra perché è più semplice e garantisce immediatamente il forte invariante tri-colore, sebbene possa causare spazzatura galleggiante se un oggetto bianco diventa irraggiungibile immediatamente dopo essere stato annerito. I candidati spesso confondono questi o credono che Go utilizzi Yuasa a causa della sua gestione conservativa dello stack, ma comprendere la scelta di Dijkstra spiega perché il barrier di Go è sincrono con la scrittura piuttosto che basato su registrazione.