Sub-proposal: virtual mode

[bvisness]

This issue tracks discussion of the virtual mode sub-proposal. This proposal is one possible component of the eventual Memory Control MVP. Please make sure to read the full sub-proposal document.

[programmerjake]

memory-control/proposals/memory-control/virtual.md

Line 80 in 16dd6b9

- **macOS and Linux:** `mmap(MAP_FIXED, PROT_NONE)` on instantiation, `mmap(MAP_FIXED, <prot>)` on `memory.map`, `munmap()` on `memory.unmap`.

I don't think you can use munmap since iirc that would let the host put unrelated allocations in the memory range that was supposed to be reserved for the wasm instance.

[bvisness]

I think you're right, and the "unmap" operation should probably be implemented by another PROT_NONE instead. As far as I'm aware, this should free any physical resources and reduce commit.

[SingleAccretion]

Why is it important for the failure mode of the instructions (primarily memory.map) to be "always trap"?

It limits the ability of the WASM application to handle error conditions like out of memory gracefully. Consider, for example, that malloc is supposed to return null if it fails to allocate. Or consider a linear memory GC that can initiate an aggressive older generation collection if it finds itself unable to allocate (commit) more memory (not a hypothetical scenario: I am writing this on a machine where a variant of this mechanism allows multiple IDE instances to be simultaneously opened and the system to still work well).

Edit: memory.grow also doesn't trap on an OOM condition, it returns -1.

[bvisness]

Yeah, that's also a good point. Returning -1 could probably work just fine for memory.map as well.

I'm not sure that the other operations need to return error codes, but if they can reasonably fail under normal conditions, perhaps they should. Off the top of my head, though, I'm not aware though of any failures cases that would arise from correct use of system memory APIs after the memory has already been mapped.