#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)
#1427, #1439
This proposal defines one new function to (almost) completely address WebAssembly's linear memory problem
What does it do?
clearPagesclears the pages in the range [start,start+count), setting every byte to0The magic appears in the function's guarantees, namely, that the underlying memory is decommitted and returned to the OS
An implementation could:
VirtualFree/munmap/ etc)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 exampleVirtualFree. 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.Memoryshould 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 amalloc/freeinterface 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 neededNote 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 howVirtualAllocandmmapdo not actually allocate pages but tell the OS where it is appropriate to allocate pages on-demand)