TECH Signal 462 2 feeds carried it
Go 1.24 replaces built-in map runtime with Swiss Tables implementation
↗
Illustration only Photo by Tobias Jelskov on Unsplash
Go’s standard map now uses Swiss Tables instead of bucket-based hashing for its internal runtime structure
The change alters memory layout, collision handling, and resizing behavior of every Go map. Engineers who rely on low-level map performance or introspection tools will need to revisit assumptions and benchmarks. No source-level code changes are required, but the new implementation may shift latency profiles and memory footprints
Written by elseif from the cluster below · every claim links back to a sourceThe three things worth knowing
Swiss Tables replace the previous bucket-based hashing with a more compact group-and-control-byte layout
The runtime now uses H1 and H2 hashes, probing, and a directory structure to manage collisions and growth
An experimental split-group layout is included but not enabled by default
THE READ
What the cluster adds up to.
Go’s built-in map has switched from a traditional bucket-based design to Swiss Tables, a structure originally developed for Abseil’s hash containers. The new layout groups keys into fixed-size arrays and uses a control byte per slot to encode metadata such as occupancy and hash fragments. This reduces pointer overhead and improves cache locality compared to the previous linked-list-of-buckets approach.
The implementation relies on two hash functions, H1 and H2, to distribute keys and detect collisions. H1 determines the initial group, while H2 is stored in the control byte to accelerate lookups. Probing handles collisions by scanning adjacent groups, and the directory structure allows the table to grow without rehashing every key immediately. Load factor thresholds trigger resizing, but the exact thresholds and growth policies differ from the old bucket scheme.
Deletion now marks slots as empty rather than tombstoning them, which simplifies cleanup but may affect iteration order guarantees. The experimental split-group layout separates control bytes from data to further reduce false sharing, though it remains disabled in the default build. Engineers profiling map-heavy code should expect different memory access patterns and latency distributions, even if the public API remains unchanged.
Written by elseif from the cluster below · checked for specifics the sources never containedTHE CLUSTER