Storia: Prima di Go 1.18, il linguaggio mancava di polimorfismo parametrico, costringendo gli sviluppatori a scegliere tra interface{} (che causa allocazioni nel heap e sovraccarico di boxing) o generazione di codice (che causa un gonfiore binario). Nel progettare i generics, il team di Go ha esplicitamente rifiutato il modello di template di C++ di piena monomorfizzazione—dove ogni istanza di tipo distinta produce codice macchina duplicato—per timori riguardanti l'esplosione delle dimensioni binarie in grandi applicazioni cloud-native che collegano migliaia di pacchetti.
Problema: La pura monomorfizzazione genererebbe blocchi di assembly separati per Process[int] e Process[uint] nonostante entrambi siano interi a 64 bit, sprecando la cache delle istruzioni e lo spazio su disco. Al contrario, implementare i generics tramite boxing (come in Java) costringerebbe i tipi di valore sullo heap, distruggendo le caratteristiche di prestazioni senza allocazioni essenziali per la nicchia di programmazione di sistemi di Go. La sfida stava nel preservare la sicurezza dei tipi a tempo di compilazione e i costi zero dei valori semantici evitando il problema della duplicazione del codice N-volte.
Soluzione: Go impiega la stencilizzazione della forma di GC combinata con dizionari runtime. Il compilatore raggruppa i tipi per forma di GC—definita da dimensione, allineamento e bitmap dei puntatori—piuttosto che per identità di tipo esatta. I tipi con layout di memoria identici (ad es., []int e []string, entrambi essendo strutture header con un puntatore, lunghezza e capacità) condividono lo stesso codice macchina istanziato stencil. Per operazioni specifiche ai tipi come l'invocazione di metodi o le asserzioni di tipo, il compilatore passa un nascosto dizionario runtime contenente offset di metadati. Questo garantisce che Point{X:1, Y:2} e Vector{X:1, Y:2} condividano codice, mantenendo i tipi di valore non boxed nello stack.
Stavamo sviluppando un motore di archiviazione colonnare ad alte prestazioni che richiedeva un'implementazione generica di SkipList per indicizzare sia i timestamp int64 che le strutture Decimal128 personalizzate (16 byte, due campi uint64). Le prime misurazioni usando interface{} mostrano che il 35% del tempo CPU era consumato da allocazioni nel heap e indirezione delle interfacce, inaccettabile per i nostri requisiti di latenza sub-microsecondo.
Abbiamo considerato tre approcci architetturali. Innanzitutto, piena monomorfizzazione tramite go generate e text/template per produrre implementazioni dedicate di SkipListInt64 e SkipListDecimal. Questo eliminava le allocazioni ma aumentava la nostra dimensione binaria di 22MB quando si supportavano dodici tipi numerici distinti, violando i nostri vincoli di distribuzione senza server. In secondo luogo, un'implementazione unificata utilizzando unsafe.Pointer e riflessione per gestire manualmente la memoria. Questo manteneva la dimensione binaria minima ma introduceva una complessità catastrofica, richiedendo aritmetica di puntatori manuale che rompeva le invarianti del garbage collector di Go durante i test.
Abbiamo selezionato il terzo approccio: generics nativi di Go con un'attenzione particolare al raggruppamento della forma di GC. Abbiamo allineato la nostra struttura Decimal128 per corrispondere al layout di memoria di [2]uint64, garantendo che condividesse il codice stencil con altri tipi di valore a 16 byte. Analizzando l'output del compilatore con go tool objdump, abbiamo verificato che SkipList[int64] e SkipList[uint64] condividessero blocchi di assembly identici, mentre SkipList[string] utilizzava correttamente uno stencil separato a causa della sua bitmap contenente puntatori. Questo approccio ibrido ha ridotto la dimensione binaria del 58% rispetto alla generazione di codice mantenendo un throughput senza allocazioni. Il risultato è stata un miglioramento della latenza di 4 volte rispetto alla versione interface{} e una dimensione binaria inferiore a 30MB.
Perché due tipi di struct distinti con tipi di campo identici generano talvolta istanze generiche separate, mentre una struct e un alias di tipo di un primitivo possono condividere codice?
Questo si verifica perché il raggruppamento della forma di GC dipende dal descrittore di tipo runtime completo, inclusi bitmap dei puntatori e padding, non solo dai tipi di campo superficiali. Se type A struct { x, y int } e type B struct { x, y int } sono definiti in pacchetti diversi, condividono la stessa forma di GC e stencil. Tuttavia, *type C struct { x int; y int } ha una bitmap dei puntatori diversa rispetto a type D struct { x, y int }, forzando una generazione di codice macchina separata. Al contrario, type MyInt int e int condividono forme, ma struct { _ int; x int } e struct { x int } potrebbero differire a causa del padding di allineamento. Comprendere che il garbage collector richiede mappe di stack accurate per ogni variabile attiva spiega perché l'identità del layout supera l'identità nominale del tipo.
In che modo l'invocazione di metodi sui parametri di tipo generico differisce dalle chiamate dirette concrete, e perché questo sovraccarico è inevitabile senza una piena monomorfizzazione?
Quando si chiama un metodo su un parametro di tipo generico T, il compilatore emette una chiamata indiretta attraverso il dizionario runtime piuttosto che un indirizzo di funzione diretto. A differenza delle chiamate alle interfacce—che risolvono i metodi tramite itab a runtime—le voci del dizionario generico sono risolte a tempo di compilazione ma passate come parametri nascosti. Questo introduce un livello di indirezionamento (tipicamente 2-5 nanosecondi) rispetto al codice monomorfizzato a costo zero. I candidati spesso presumono che i generics siano completamente a costo zero rispetto al codice specializzato a mano; in realtà, la ricerca nel dizionario impedisce alcune ottimizzazioni di inlining che la monomorfizzazione consentirebbe, sebbene questo rimanga ordini di grandezza più veloce rispetto a reflect.Value.Call.
Perché istanziare un tipo generico con un campo identificativo vuoto (ad es., struct { _ int64; x int64 }) può potenzialmente costringere il compilatore a generare uno stencil unico, aumentando la dimensione binaria?
I campi vuoti occupano spazio e contribuiscono alla bitmap dei puntatori della struct anche se non nominati, potenzialmente alterando la forma di GC. Una struct { _ int64; x int64 } ha una dimensione e un allineamento diversi da una struct { x int64 } su certe architetture, causando al compilatore di assegnarla a un gruppo stencil distinto. Inoltre, se il campo vuoto è di tipo puntatore (**_ int*), cambia i requisiti di tracciamento del garbage collector per quel tipo, imponendo mappe di stack separate. Gli sviluppatori che ottimizzano per la dimensione binaria devono riconoscere che le forme di GC sono determinate dal layout di memoria completo—compresi padding e campi vuoti—piuttosto che solo dai membri di dati semantici rilevanti.