Understand Wasm Memory Model: Linear Memory, Pages, memory.grow

Wasm Linear Memory

Wasm exposes one or more growable byte arrays called memories. \`memory.grow\` adds 64 KiB pages; loads and stores use \`i32\` addresses into index 0 by default in MVP modules.

Pages and Bounds

Properties:

• Page size: 64 KiB (65536 bytes)
• Initial vs maximum: module declares start size and optional cap
• Bounds checks: every load/store traps if address + offset exceeds current size

Hosts map the same linear memory for JS \`WebAssembly.Memory\` views or WASI \`mmap\` equivalents.

For example, \`memory.grow(1)\` on a 1-page memory yields 2 pages (128 KiB). An \`i32.store\` at offset 70000 traps on a single-page memory.

\`data\` segments copy initializer bytes into linear memory at compile time or instantiation.

Design Notes

Hosts may share one linear memory with multiple views (i8, i32). Alignment rules still apply; unaligned atomics have their own rules in threaded proposals you may see in newer specs.

For This Exercise

This exercise asks you to document linear memory layout and \`memory.grow\` semantics. You will explain page growth and why every access must be bounds-checked for sandbox safety.

You will use the same mental model here when reading production interpreter source later in the track. Sketch one concrete input on paper, predict the outcome, then confirm with code. That discipline catches logic errors early and makes debugging far faster when you extend the implementation in follow-on tasks.