การขยายและจัดการหน่วยความจำเชิงเส้น

WASM stores all its data in a single, contiguous block called linear memory, exposed to JS as a growable ArrayBuffer.

Understanding how it grows and how to manage it is key to high-performance modules.

Linear memory is measured in pages of 64 KiB each.

• 1 page = 65536 bytes
• Memory grows in whole pages, never partial

When creating memory you set an initial and optional maximum number of pages.

Call grow(n) to add n pages. It returns the previous size, or throws if it would exceed the maximum.

Important: growing memory detaches the old ArrayBuffer. Any typed-array view you held is now invalid, re-create it after growth.

WASM code grows its own memory with the memory.grow instruction; allocators like Rust's do this automatically when the heap fills.

Languages provide an allocator (malloc, Rust's global allocator) that carves the linear memory into objects.

You rarely manage raw offsets, you let the allocator and bindings do it.

Emscripten exposes _malloc and _free so JS can reserve space in WASM memory for data to pass in.

Memory you allocate must be freed, WASM has no garbage collector for its linear memory. Forgetting free leaks until the module is discarded.

Tune memory for your workload:

• Start with enough initial pages to avoid early growth
• Set a maximum to cap runaway usage
• Remember each grow detaches views, batch growth when possible

To manage linear memory well:

• Think in 64 KiB pages
• Re-create views after every grow
• Pair every alloc with a free
• Pick sensible initial and maximum sizes

You learned to manage WASM linear memory:

• Memory grows in 64 KiB pages via grow()
• Growth detaches buffers, refresh your views
• Allocators and _malloc/_free carve the space
• Free what you allocate; size initial/max thoughtfully

Careful memory management keeps high-performance WASM apps fast and leak-free.