Memory mapping: Using a single linear memory + requirements discussion

[dtig]

The initial discussions of this proposal, we had considered using a secondary memory for a mappable memory, but after some initial investigations into potential users of this proposal, I'd like to scope that for a potential post-MVP addition, and scope the MVP to only work with the single linear memory. The main reasons for this are:

• Non-trivial addition of work when porting existing applications. A big win for exisiting applications is that porting to Wasm should in most cases work pretty much out of the box, having a separate secondary mappable memory, especially if built on top of multiple memories would mean additional annotation of existing code with the memory that it should operate on. Its possible in some cases that this can be alleviated to some extent with a toolchain pass, but it will still involve some additional work upfront.
• Graceful degradation for existing applications. This is a point I hadn't previously considered, but was brought up during a use case study. This is a requirement for some larger applications, especially when running on older devices where updates aren't always possible - that there would be an easy way to polyfill this proposal. While this isn't a gating requirement, using a secondary memory does make this harder.

Another interesting point is that while memcpys are expensive, and sometimes unnecessary they're usually not the most expensive operation in the pipeline. Are there performance or ergonomic requirements this proposal should define upfront?

[lygstate]

ping the memory-control

[dtig]

Closing as the overview now reflects the updated scope/direction https://github.com/WebAssembly/memory-control/pull/10.