Memory Layout & Alignment

Layout is fixed by the type

A struct’s bytes are laid out in field declaration order, but each field must satisfy its type’s alignment: an int64 must begin at an address that’s a multiple of 8, an int32 at a multiple of 4, and so on. To honor that, the compiler inserts padding — unused bytes — between fields and at the end. The whole thing is decided at compile time from the type and the target architecture; the value’s contents never matter.

Two facts drive everything:

• A struct’s alignment is the maximum alignment of its fields.
• A struct’s size is rounded up to a multiple of its alignment (so arrays of it stay aligned).

Padding, seen three ways

unsafe exposes the layout numbers as compile-time constants. This program prints the size, alignment, and field offsets for two structs with the same fields in different order:

package main

import (
"fmt"
"unsafe"
)

// Poorly ordered: bool, int64, bool → padding forced around the int64.
type Bad struct {
a bool  // offset 0
b int64 // must be 8-aligned → 7 bytes padding before it
c bool  // offset 16, then 7 bytes tail padding
}

// Well ordered: int64 first, bools packed after.
type Good struct {
b int64 // offset 0
a bool  // offset 8
c bool  // offset 9, then 6 bytes tail padding
}

func main() {
var bad Bad
var good Good

fmt.Printf("Bad:  size=%d align=%d  offsets a=%d b=%d c=%d\n",
	unsafe.Sizeof(bad), unsafe.Alignof(bad),
	unsafe.Offsetof(bad.a), unsafe.Offsetof(bad.b), unsafe.Offsetof(bad.c))

fmt.Printf("Good: size=%d align=%d  offsets b=%d a=%d c=%d\n",
	unsafe.Sizeof(good), unsafe.Alignof(good),
	unsafe.Offsetof(good.b), unsafe.Offsetof(good.a), unsafe.Offsetof(good.c))

fmt.Println("saved per value:", unsafe.Sizeof(bad)-unsafe.Sizeof(good), "bytes")
}

Bad is 24 bytes, Good is 16 — a third smaller, for free, just by ordering largest-alignment fields first. Across a slice of millions, that’s real memory and fewer cache misses.

graph TD
subgraph Bad["Bad — 24 bytes"]
  B0["a (1)"] --> B1["pad (7)"] --> B2["b: int64 (8)"] --> B3["c (1)"] --> B4["pad (7)"]
end
subgraph Good["Good — 16 bytes"]
  G0["b: int64 (8)"] --> G1["a (1)"] --> G2["c (1)"] --> G3["pad (6)"]
end

Sizes of the common types

The zero-size empty struct is why map[string]struct{} is the idiomatic set: the keys carry the data, and the values cost nothing.

Cache lines and false sharing

Alignment also matters for speed, not just size. CPUs move memory in cache-line units — typically 64 bytes. If two goroutines on different cores repeatedly write to two distinct variables that happen to live in the same cache line, every write invalidates the other core’s copy, and the line ping-pongs between caches. This is false sharing, and it can quietly destroy the scaling of per-goroutine counters.

The fix is to pad hot, independently-written fields out to their own cache line:

type counter struct {
	n   uint64
	_   [56]byte // pad to 64 bytes so neighbors land in separate cache lines
}
var counters [8]counter // each counter[i] owns its line

See also

• unsafe & pointers — Sizeof/Alignof/Offsetof and pointer reinterpretation.
• the memory allocator — smaller structs drop into smaller size classes.
• the garbage collector — pointer-free structs are cheaper to scan.
• structs (fundamentals) — the language-level view of struct types.

Next: reinterpreting those bytes directly — unsafe & pointers.

Related topics