Repository navigation
Sparse memory #1571
Description
One approach to solving #1397 is to make WebAssembly linear memory sparse: one can reserve terabytes (or even petabytes) of PROT_NONE address space up-front, but it must be committed before it can be used. Under this proposal, WebAssembly programs can freely mprotect() any address within the reserved range. Protecting with PROT_NONE decommits the memory, and protecting with anything else commits it.
This does allow WebAssembly modules to access decomitted memory, but that isn’t undefined behavior. It’s defined as causing a SIGSEGV, and the embedder can catch and recover from that. Embedders would need to use accessor functions to access linear memory, but that is no harder than OS kernels using them to access userspace memory. Calls into the OS kernel could pass pointers directly into linear memory, as the OS kernel already needs to be safe against concurrent reads, writes, and calls to mprotect.
Activity
bvisness commentedon Sep 19, 2025
There has been much discussion on this subject over the years, and the latest thoughts on the matter can be found in the memory control proposal.
There have also been a few presentations to the WASM CG about new memory features in the past few years:
What you're talking about sounds most similar to the virtual mode sub-proposal of memory control. If you haven't read that yet, I'd encourage you to take a look and share your thoughts in the GitHub issues on that repository.