Go's compiler employs a technique called GCshape stenciling when compiling generics introduced in version 1.18. Historically, languages implemented generics through either full monomorphization—generating separate machine code for each type instantiation, causing binary bloat—or through boxing—erasing types at the cost of runtime overhead and allocation. The problem Go faced was supporting high-performance systems programming where binary size matters, without sacrificing execution speed entirely.
The solution involves grouping concrete types by their GC shape, defined by their size and pointer bitmap (the pattern of pointers within the type). The compiler generates a single function instantiation for all types sharing the same GC shape, passing a runtime dictionary containing type metadata as an implicit parameter.
// Both *int and *string share the same instantiation // because they have identical GC shape (single pointer). func Identity[T any](x T) T { return x } func main() { Identity((*int)(nil)) // Uses instantiation #1 Identity((*string)(nil)) // Uses instantiation #1 (same shape) Identity(42) // Uses instantiation #2 (scalar, no pointers) }
Our team was building a high-throughput event processing pipeline using generic middleware handlers Handler[T Event]. We needed to process fifty distinct event types while maintaining low latency and reasonable binary size for containerized deployment.
The first approach used interface{} with type assertions, relying on runtime type switches. This provided flexibility and worked in older Go versions, but introduced significant allocation overhead—every event wrapped in an interface required heap allocation—and eliminated compile-time type safety, leading to panics in production when types were mismatched.
The second approach involved compile-time code generation using go generate with third-party tools to create HandlerClickEvent, HandlerPurchaseEvent, etc. This delivered optimal performance with no runtime overhead, but bloated our binary size by 40MB when supporting fifty event types, and created maintenance nightmares when updating the generator templates.
We chose the third approach: native Go generics with careful attention to GC shapes. We ensured our event types were pointers to structs (uniform GC shape), allowing the compiler to reuse instantiations. We accepted the minor overhead of dictionary lookups for method dispatches in exchange for a binary size increase of only 2MB. The result was a 15% latency reduction compared to interface{} and a manageable binary footprint compared to full code generation.
How does the runtime dictionary provide type-specific information to shared generic instantiations?
The dictionary is a struct containing pointers to type descriptors (_type), method tables (itab), and GC metadata. When the compiler generates code for a generic function like func Print[T any](x T), it passes the dictionary as an implicit first argument. To call a method x.String(), the generated code looks up the method pointer in the dictionary rather than compiling a direct call, enabling the same machine code to handle T=bytes.Buffer and T=strings.Builder despite different method implementations.
Why might two distinct pointer types share a generic instantiation while their element types require separate ones?
Go classifies types by GCshape, which cares only about the memory layout relevant to the garbage collector and allocator. Both *int and *string consist of a single machine word containing a pointer, placing them in the same shape class. Conversely, int contains no pointers and aligns to a specific size, while string is a two-word struct containing a pointer and a length. Because their memory layouts differ, they require separate generated code paths to handle proper garbage collection and memory addressing.
What is the performance implication of using value receivers versus pointer receivers in generic constraints?
When a generic function calls a method on a type parameter T, the compiler must generate code that works for any possible T. If the constraint requires a value receiver func (T) Method(), but the concrete type is large, the compiler may be forced to pass dictionaries and perform indirect calls that prevent inlining. Using pointer receivers func (*T) Method() often allows better optimization because pointer types share GC shapes more frequently, and the compiler can more easily devirtualize calls when the concrete type is known at compile time in specific instantiation contexts.