Proposal: An extremely simple solution to the WebAssembly memory issue

[BlobTheKat]

#1427, #1439

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)

[sunfishcode]

This is similar to the memory.discard proposal.

[BlobTheKat]

This is similar to the memory.discard proposal.

Indeed. Adding a webassembly instruction to match the functionality of clearPages() (i.e memory.discard or memory.clear) makes sense, along with maybe memory.grow to 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]

This is similar to the memory.discard proposal.

Indeed. Adding a webassembly instruction to match the functionality of clearPages() (i.e memory.discard or memory.clear) makes sense, along with maybe memory.grow to match the .grow() API.

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.

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.

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]

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.

I'll definitely check it out, I didn't realise it was this close to being ready.

[bvisness]

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 supports memory.discard with the opcode used by SpiderMonkey.