History: Before Go 1.18, the language lacked parametric polymorphism, forcing developers to choose between interface{} (causing heap allocations and boxing overhead) or code generation (causing binary bloat). When designing generics, the Go team explicitly rejected the C++ template model of full monomorphization—where every distinct type instantiation produces duplicate machine code—due to concerns about binary size explosion in large cloud-native applications linking thousands of packages.
Problem: Pure monomorphization would generate separate assembly blocks for Process[int] and Process[uint] despite both being 64-bit integers, wasting instruction cache and disk space. Conversely, implementing generics via boxing (like Java) would force value types onto the heap, destroying the zero-allocation performance characteristics essential for Go's systems programming niche. The challenge lay in preserving compile-time type safety and zero-cost value semantics while avoiding the N-times code duplication problem.
Solution: Go employs GC shape stenciling combined with runtime dictionaries. The compiler groups types by GC shape—defined by size, alignment, and pointer bitmap—rather than by exact type identity. Types with identical memory layouts (e.g., []int and []string, both being header structs with a pointer, len, and cap) share the same instantiated machine code stencil. For type-specific operations like method dispatch or type assertions, the compiler passes a hidden runtime dictionary containing metadata offsets. This ensures that Point{X:1, Y:2} and Vector{X:1, Y:2} share code, while keeping value types unboxed on the stack.
We were developing a high-performance columnar storage engine requiring a generic SkipList implementation to index both int64 timestamps and custom Decimal128 structs (16 bytes, two uint64 fields). Initial benchmarks using interface{} showed 35% of CPU time consumed by runtime heap allocations and interface indirection, unacceptable for our sub-microsecond latency requirements.
We considered three architectural approaches. First, full monomorphization via go generate and text/template to produce dedicated SkipListInt64 and SkipListDecimal implementations. This eliminated allocations but increased our binary size by 22MB when supporting twelve distinct numeric types, violating our serverless deployment constraints. Second, a unified implementation using unsafe.Pointer and reflection to manually manage memory. This kept binary size minimal but introduced catastrophic complexity, requiring manual pointer arithmetic that broke Go's garbage collector invariants during testing.
We selected the third approach: native Go generics with careful attention to GC shape grouping. We aligned our Decimal128 struct to match the memory layout of [2]uint64, ensuring it shared stencil code with other 16-byte value types. By analyzing the compiler output with go tool objdump, we verified that SkipList[int64] and SkipList[uint64] shared identical assembly blocks, while SkipList[string] correctly used a separate stencil due to its pointer-containing bitmap. This hybrid approach reduced binary size by 58% compared to code generation while maintaining zero-allocation throughput. The result was a 4x latency improvement over the interface{} version and a binary size under 30MB.
Why do two distinct struct types with identical field types sometimes generate separate generic instantiations, while a struct and a type alias of a primitive might share code?
This occurs because GC shape grouping depends on the complete runtime type descriptor, including pointer bitmaps and padding, not merely the superficial field types. If type A struct { x, y int } and type B struct { x, y int } are defined in different packages, they share the same GC shape and stencil. However, *type C struct { x int; y int } has a different pointer bitmap than type D struct { x, y int }, forcing separate machine code generation. Conversely, type MyInt int and int share shapes, but struct { _ int; x int } and struct { x int } might differ due to alignment padding. Understanding that the garbage collector requires accurate stack maps for every live variable explains why layout identity trumps nominal type identity.
How does method dispatch on generic type parameters differ from direct concrete calls, and why is this overhead unavoidable without full monomorphization?
When calling a method on a generic type parameter T, the compiler emits an indirect call through the runtime dictionary rather than a direct function address. Unlike interface calls—which resolve methods via the itab at runtime—generic dictionary entries are resolved at compile time but passed as hidden parameters. This introduces one level of indirection (typically 2-5 nanoseconds) compared to zero-cost monomorphized code. Candidates often assume generics are fully zero-overhead relative to hand-specialized code; in reality, the dictionary lookup prevents certain inlining optimizations that monomorphization would allow, though this remains orders of magnitude faster than reflect.Value.Call.
Why does instantiating a generic type with a blank identifier field (e.g., struct { _ int64; x int64 }) potentially force the compiler to generate a unique stencil, increasing binary size?
Blank fields occupy space and contribute to the struct's pointer bitmap even when unnamed, potentially altering the GC shape. A struct { _ int64; x int64 } has a different size and alignment than struct { x int64 } on certain architectures, causing the compiler to assign it to a distinct stencil group. Furthermore, if the blank field is a pointer type (**_ int*), it changes the garbage collector's tracing requirements for that type, mandating separate stack maps. Developers optimizing for binary size must recognize that GC shapes are determined by the complete memory layout—including padding and blank fields—rather than just the semantically relevant data members.