Historique
L'allocateur de mémoire de Go descend de TCMalloc, le malloc de mise en cache par threads de Google conçu pour les serveurs multi-threads en C++. Le runtime implémente un cache multi-niveau spécialement pour éliminer la contention de verrou dans les programmes concurrents. Ce design privilégie le débit par rapport à l'efficacité mémoire dans le chemin rapide des petits objets.
Le Problème
Dans les services hautement concurrents, le fait de nécessiter que chaque allocation acquière un verrou global sur le tas entraînerait une sérialisation des goroutines et détruirait le débit. Le défi consiste à fournir une latence d'allocation O(1) sans synchronisation pour le cas courant tout en maintenant la sécurité. Les implémentations classiques de malloc souffrent du rebond de ligne de cache lorsque plusieurs CPU se disputent le même mot de verrou.
La Solution
Le runtime maintient un cache par P (mcache) contenant des spans pour chacune des 67 classes de taille. Lorsqu'une goroutine alloue un petit objet (≤32KB), elle incrémente soit un pointeur de limite, soit dépile à partir d'une liste libre locale dans son mcache, ne nécessitant aucune opération atomique. L'invariant critique est qu'un mcache est la propriété exclusive d'un seul P à tout moment, et les allocations ne traversent jamais les frontières de P, évitant ainsi l'état mutable partagé.
type PriceTick struct { Symbol uint32 Price float64 } func ProcessTick() { // Alloue 16 octets à partir de mcache sans verrouillage tick := &PriceTick{} _ = tick }
Une plateforme de trading à haute fréquence traitait 500 000 événements de données de marché par seconde, chaque événement nécessitant des structs temporaires de 24 octets pour la normalisation des prix. L'implémentation initiale utilisait un sync.Pool global pour ces objets, ce qui est devenu un point de contention sévère sous charge, consommant 35 % du temps CPU dans les opérations atomiques et le trafic de cohérence de cache.
Solution A : Sharding manuel du pool
L'équipe a envisagé de diviser manuellement le pool en 256 sous-pools internes sélectionnés par le hachage de l'ID de la goroutine. Avantages : Distribue la contention sur les lignes de cache. Inconvénients : Une utilisation inégale crée un gonflement de mémoire dans des shards inactives, et un traitement complexe de la famine est nécessaire lorsqu'un shard local se vide tandis que d'autres contiennent des objets libres.
Solution B : Arenas par travailleur
Ils ont évalué la pré-allocation de grandes arenas de mémoire par goroutine de travail avec allocation par pointeur de poussée. Avantages : Aucune contention et chemin d'allocation extrêmement rapide. Inconvénients : Nécessite une gestion manuelle de la mémoire, risque de fuite de mémoire si les pointeurs de réinitialisation sont mal gérés, et complique le suivi de la durée de vie des objets à travers des frontières asynchrones.
Solution C : Allocation sur la pile et regroupement
L'approche choisie a restructuré le processeur d'événements pour utiliser des structs de valeurs au lieu de pointeurs, en gardant les données sur la pile lorsque c'est possible et en traitant les événements par lots de 1000 pour amortir les allocations. Avantages : Élimine entièrement la pression du tas pour les données à courte durée de vie et ne nécessite aucun primitive de synchronisation. Inconvénients : Demande un refactoring significatif des interfaces qui attendaient des sémantiques de pointeur et augmente l'utilisation de la pile par goroutine.
Résultat
En mettant en œuvre la Solution C, le service a éliminé 99 % des allocations de tas dans le chemin critique. La latence P99 est tombée de 12 millisecondes à 180 microsecondes, et les cycles de collecte des déchets ont diminué de 85 %, permettant au service de respecter ses exigences en matière de SLA inférieures à une milliseconde.
Comment Go limite-t-il la fragmentation mémorielle lors de l'allocation d'objets de tailles variées à partir de spans de taille fixe ?
Go emploie 67 classes de taille distinctes avec une granularité spécifique (pas de 8 octets jusqu'à 512 octets, puis de plus grands intervalles). Les objets sont arrondis à la taille de classe la plus proche, ce qui limite la fragmentation interne à environ 12,5 %. La fragmentation externe est minimisée parce que chaque mspan contient des objets d'exactement une seule classe de taille, empêchant les petits objets de retenir de grands blocs de mémoire.
Pourquoi le runtime efface-t-il les bitmaps de tas plutôt que la mémoire visible par l'utilisateur lors de l'allocation ?
L'allocateur maintient des informations de type et des bitmaps de pointeurs dans les structures de métadonnées heapArena plutôt que dans les en-têtes d'objets. Lorsque de la mémoire est allouée, seuls les bitmaps indiquant les emplacements de pointeurs sont mis à zéro si nécessaire ; la mémoire des données est mise à zéro sur demande par le mutateur ou lors du balayage concurrent. Cette approche report le travail, améliore la locality de cache et réduit la bande passante mémoire requise lors de l'allocation.
Qu'est-ce qui force un span à passer de mcache à mcentral lors de la collecte des déchets ?
Lors de la phase de balayage GC, le runtime examine les spans détenus dans des instances de mcache. Si un span ne contient aucun objet alloué (tous les emplacements sont libres), le P le retourne à mcentral plutôt que de le conserver. Cela empêche l'accumulation de mémoire et garantit une distribution équilibrée de la mémoire libre entre les processeurs, bien que cela entraîne le coût de la réacquisition du verrou central.