Lower bound on number of WebAssembly.Memory objects implementations should support?

[eholk]

The backing stores for WebAssembly.Memory objects can be large or be backed by large address space allocations. Furthermore, implementation may wish to limit the total amount of address space used by a process.

Should we note, either normatively or non-normatively, some lower bound for the amount of memory or number of memory objects that implementations should be able to handle in use at once? If so, should this be in terms of number of memories, or number of bytes in the backing store?

So far most apps have one Wasm module, instance and memory that consists of the entire application, so supporting one memory (or some small number, like 5) should be sufficient. In the future, we might see applications made up of many independent instances and memories (for example, many WebPack modules). It would be nice to be able to say to developers "you can expect that at least this many will work."

Obviously this will be constrained by available resources; a machine with 256MB of RAM won't reasonably be able to support a 2GB Wasm Memory. The goal instead is to say "insofar as possible, implementations should not put in limits below X."

We currently have a test in WPT that checks that we can make 600 memories (although this will probably decrease to 20 soon). This was an arbitrary number that should be larger than any reasonable app would want. At the very least, if we're going to test a number, we should have some agreement on what that number should be.

[eholk]

/cc @flagxor

[lukewagner]

In FF, we currently cap the max number of simultaneously live wasm memories to 1000.

[jfbastien]

I don't think we can specify a lower bound other than zero. If we're out of memory, we're out.

Having a WPT test for a particular number doesn't seem very useful TBH. Other tests will see if we can do basic things with memory already, no?

[eholk]

It's probably worth making sure we can have two memories at once as a proxy for infinity, but I agree that any number we put there will be a heuristic at best. It's always possible that we're actually out of memory.

Giving guidelines for implementors also helps set what kinds of patterns application developers can use. Do we expect everything to be a monolithic app? What about having several communicating instances with disjoint memory? What about having thousands? Which of these should developers expect to be able to use?

[jfbastien]

I'd approach this differently: implementations should see what developers use, and make it work as best as we can. We won't know if a particular pattern is useful if we tell developers not to use it because we don't want to support it well. At the same time, developers won't know if something is fast unless they try it, and give us feedback if slow.

[eholk]

https://crrev.com/c/851081 is on its way to through the Chormium, which will ultimately result in the test being removed from WPT.

I'll go ahead and close this issue with the decision that at least for now we won't make any requirements or recommendations in the spec about how many memories an implementation should support.