Go Memory Layout - Deep Dive

Memory Layout

Category: Runtime & Hardware Interoperability Topic: Memory Mechanics, Alignment, & Unsafe

Concept

Understanding Go's memory layout is essential for writing high-performance code, avoiding unnecessary allocations, and optimizing CPU cache line usage. Go's memory model governs basic type sizes, strict byte alignment rules, structural padding, memory layout for composite types (strings, slices, maps), and unsafe memory access via the unsafe package. Precise knowledge of struct alignment enables zero-copy conversions and minimizes garbage collection pressure in latency-critical codebases.

Why It Exists

Hardware and runtime constraints dictate exact alignment and structural layout rules:

CPU Cache Efficiency: Modern CPU architectures access memory in multi-byte chunks (typically 64-byte cache lines). Misaligned data spans across multiple cache lines, causing redundant memory access cycles.
Low-Level Interoperability: Foreign Function Interfaces (CGo), syscalls, and network/hardware protocols demand precise byte-for-byte struct mappings.
Deterministic Introspection: Go enforces strict layout and padding algorithms, avoiding implementation-defined ambiguity found in non-standardized compilers.

How It Works

Basic Type Sizes and Alignment Rules

Type	Size (64-bit)	Alignment (64-bit)	Notes
`bool`	1 byte	1 byte	Boolean representation
`int`, `uint`	8 bytes	8 bytes	4 bytes on 32-bit platforms
`int32`, `float32`	4 bytes	4 bytes	Fixed width
`int64`, `float64`	8 bytes	8 bytes	Fixed width
`string`	16 bytes	8 bytes	Pointer (8B) + Length (8B)
`slice` (`[]T`)	24 bytes	8 bytes	Pointer (8B) + Length (8B) + Capacity (8B)
`unsafe.Pointer`	8 bytes	8 bytes	Raw heap/stack pointer

Struct Padding & Field Alignment

Fields in structs are aligned to multiples of their own size (up to the platform's maximum alignment boundary, typically 8 bytes on 64-bit platforms). Compiler padding is inserted when necessary to satisfy alignment rules.

padding_demo.go

// Unoptimized struct layout: Size = 24 Bytes
type UnpaddedStruct struct {
    a byte  // 1 Byte
            // 7 Bytes padding (to align int64 at 8-byte boundary)
    b int64 // 8 Bytes
    c byte  // 1 Byte
            // 7 Bytes padding (to align struct size to multiple of 8)
}

// Optimized struct layout: Size = 16 Bytes
type PaddedStruct struct {
    b int64 // 8 Bytes
    a byte  // 1 Byte
    c byte  // 1 Byte
            // 6 Bytes padding
}

Composite Type Headers

String Header (16 Bytes):

Slice Header (24 Bytes):

Unsafe Memory Access

The unsafe package bypasses type safety to directly inspect and manipulate memory offsets:

unsafe_inspection.go

package main

import (
    "fmt"
    "unsafe"
)

type Node struct {
    Flag  bool
    Value int64
}

func main() {
    var n Node
    fmt.Println("Node size:", unsafe.Sizeof(n))         // Output: 16 bytes
    fmt.Println("Flag offset:", unsafe.Offsetof(n.Flag))   // Output: 0
    fmt.Println("Value offset:", unsafe.Offsetof(n.Value)) // Output: 8 (4 or 7 padding bytes added)
}

Code Example

memory_introspection.go

package main

import (
    "fmt"
    "unsafe"
)

type Student struct {
    Name string  // 16 Bytes (Offset 0)
    Age  int32   // 4 Bytes  (Offset 16)
                 // 4 Bytes Padding
    GPA  float64 // 8 Bytes  (Offset 24)
}

func main() {
    s := Student{Name: "Alex", Age: 22, GPA: 3.95}

    fmt.Printf("Student Total Size: %d Bytes\n", unsafe.Sizeof(s))
    fmt.Printf("Field Offsets -> Name: %d | Age: %d | GPA: %d\n",
        unsafe.Offsetof(s.Name),
        unsafe.Offsetof(s.Age),
        unsafe.Offsetof(s.GPA),
    )

    // Inspect underlying string header directly
    strHeader := (*struct {
        Data uintptr
        Len  int
    })(unsafe.Pointer(&s.Name))

    fmt.Printf("String Metadata Header -> Address: 0x%x, Length: %d\n", strHeader.Data, strHeader.Len)
}

Step-by-Step Execution

Trace of how Go processes memory layout operations at runtime:

Instance Allocation: Memory is allocated on the stack or heap for Student (32 continuous bytes).
Offset Read: unsafe.Offsetof(s.GPA) yields byte index 24, avoiding any reflection runtime penalty.
Header Decoding: Casting unsafe.Pointer(&s.Name) yields access to the 16-byte raw StringHeader struct containing the underlying backing array address and length.

Internals

Struct Layout & Compiler Rules

Go uses a static field alignment algorithm during compilation:

Field Ordering: Fields are laid out sequentially in declaration order.
Padding Insertion: Padding bytes are inserted between fields to ensure each field starts at an address aligned to its size (or the platform maximum of 8 bytes).
Trailing Padding: Trailing padding is appended so the struct's total size is a multiple of its alignment boundary, ensuring array elements remain properly aligned.
Zero-Sized Tail Fields: Structs with a zero-sized final field (e.g., struct{}) have an extra 1-byte padding appended to prevent the field's pointer from pointing outside the allocation block, which would complicate garbage collection.

Slice Growth & Reallocation Mechanics

When an append operation exceeds slice capacity:

Capacity Growth Calculation: Small slices (capacity < 256) double in capacity. For larger slices, capacity grows smooth non-linearly using the formula: newcap += (newcap + 3*256) / 4.
Size Rounding: The requested capacity is rounded up to the nearest allocator block size (via runtime.roundupsize) to fit Go's thread-cached memory allocator (mcache).
Memory Reallocation: A new backing array is allocated, elements are copied over, and the slice header's pointer, length, and capacity fields are updated.

Complexity Matrix

Operation	Time Complexity	Space / Allocation Impact
`unsafe.Sizeof` / `Offsetof`	`O(1)`	Zero runtime overhead (evaluated at compile time)
Slice Pointer Reinterpretation	`O(1)`	Zero allocations (reinterprets backing header)
Slice Reallocation (via `append`)	`O(N)`	Allocates new backing array; triggers GC cleanup

Common Mistakes

Ignoring Field Ordering: Interleaving small byte values between 64-bit integers inflates struct sizes with unnecessary padding. Order fields from largest to smallest to minimize size.
Assuming Portable Pointer Sizes: Relying on int or pointers being strictly 8 bytes breaks on 32-bit targets (WASM, ARM32).
Violating Pointer Arithmetic Rules: Storing intermediate uintptr values across operations breaks GC root tracking. Pointer conversions must be done in a single unsafe.Pointer conversion expression.

Production Considerations

Struct Optimization: Order struct fields by size (largest to smallest) for critical high-volume structures to optimize cache line density and reduce memory footprint.
GC Root Safeness: Never store an unsafe.Pointer as a uintptr in long-lived variables, as the garbage collector cannot update unindexed integer values if objects move.
Cross-Platform Network Padding: Avoid writing raw binary structs directly to network wires using unsafe. Use explicit binary encoders (e.g., encoding/binary) to ensure consistent byte order and avoid platform-specific padding issues.

Interview Preparation

Beginner Track

A string header consumes 16 bytes (8-byte pointer + 8-byte length). A slice header consumes 24 bytes (8-byte array pointer + 8-byte length + 8-byte capacity).

Go adds padding bytes to align fields to memory addresses matching their alignment boundaries, enabling CPU memory access without extra bus cycles.

Senior Track

uintptr is an plain integer type, not a pointer reference. The Garbage Collector ignores uintptr values during root scanning and stack copying, which can lead to premature memory reclamation or stale pointer references.

Follow-Up Questions

How does the Go garbage collector track active heap pointers inside raw memory blocks?
What special alignment rules apply to zero-sized fields (like struct{}) at the end of a struct?

Practical Exercise

struct_layout_exercise.go

// Practical Exercise: Inspect and Optimize Struct Padding
package main

import (
    "fmt"
    "unsafe"
)

// Exercise: Rearrange fields in BadLayout to minimize total struct size.
type BadLayout struct {
    IsActive bool    // 1 Byte
    ID       int64   // 8 Bytes
    Tag      byte    // 1 Byte
    Score    float64 // 8 Bytes
}

type OptimizedLayout struct {
    ID       int64   // 8 Bytes
    Score    float64 // 8 Bytes
    IsActive bool    // 1 Byte
    Tag      byte    // 1 Byte
                     // 6 Bytes padding
}

func main() {
    b := BadLayout{}
    o := OptimizedLayout{}

    fmt.Printf("Unoptimized Struct Size: %d Bytes\n", unsafe.Sizeof(b))
    fmt.Printf("Optimized Struct Size: %d Bytes\n", unsafe.Sizeof(o))
}

Comments