Repository navigation
Proposal: An extremely simple solution to the WebAssembly memory issue #1543
Description
This proposal defines one new function to (almost) completely address WebAssembly's linear memory problem
WebAssembly.Memory.prototype.clearPages(start, count)What does it do?
clearPages clears the pages in the range [start, start+count), setting every byte to 0
The magic appears in the function's guarantees, namely, that the underlying memory is decommitted and returned to the OS
An implementation could:
- Uncommit the memory (
VirtualFree/munmap/ etc)- Ensure a trap handler that would recommit (and potentially clear) the page if it were accessed again
- Uncommit and recommit the memory immediately (see below)
- Set the bytes to zero, and internally mark the page as ready-to-free, ready to be uncommited on the next GC
Most OSes already make allocate-on-demand guarantees about memory pages (e.g VirtualAlloc(MEM_RESERVE | MEM_COMMIT) will not actually "commit" memory until a page fault occurs), however even if the page is filled again with zero bytes, it will stay in physical memory until decommited via for example VirtualFree. This can be trivially worked around even if the page is still needed by uncommiting and recommiting it.
An implicit consequence of this proposal is that memory initially allocated by WebAssembly.Memory should also be in this uncommitted state (this is already somewhat the case in V8, although currently accessing some page N will commit all pages <= N at the same time)
To make full use of this, we could create new memory with 65536 pages (4GB, the full address space) and physical pages would only be allocated as accessed, and freed on clearPages, providing functionality almost identical to native page allocation (minus memory protection). Javascript could then expose this control to a wasm module via a malloc/free interface that guarantees low memory fragmentation and proper memory decommitting. A more strict implementation could also start with a minimal memory object and .grow() as new pages are needed
Note that with this proposal, a Memory's size, and the .grow() API take on a more semantic meaning: they now only define the arbitrary limit at which pages should stop being allocated, rather than the true number of pages to be allocated (analogous to how VirtualAlloc and mmap do not actually allocate pages but tell the OS where it is appropriate to allocate pages on-demand)
Activity
sunfishcode commentedon Dec 12, 2024
This is similar to the
memory.discardproposal.BlobTheKat commentedon Dec 12, 2024
Indeed. Adding a webassembly instruction to match the functionality of clearPages() (i.e
memory.discardormemory.clear) makes sense, along with maybememory.growto match the.grow()API.At a glance, the two proposals don't seem mutually exclusive, but I believe separating memory discarding from the larger memory control proposal would encourage vendors to implement specifically the discard functionality quicker, without waiting to complete the full memory control proposal.
eqrion commentedon Dec 12, 2024
The linked memory.discard proposal has a memoryObj.discard() API as well as instruction. Similar to how we already have a memoryObj.grow() method and memory.grow instruction.
I believe your proposal is basically identical to the memory.discard proposal (correct me if I'm wrong). SpiderMonket has a complete implementation of it, so we generally support the idea. The biggest blocker for moving it forward is having users experiment with the instruction and show that it has value.
BlobTheKat commentedon Dec 12, 2024
I'll definitely check it out, I didn't realise it was this close to being ready.
bvisness commentedon Jan 10, 2025
If you would like more info about
memory.discard, check out the discussion issue and the linked document describing the SpiderMonkey prototype. The wasm-tools text parser also supportsmemory.discardwith the opcode used by SpiderMonkey.