3 ms·

Not sharing memory is a pretty big restriction, though. For example, if you have variable-length data like a string, you can't pass it to a WASM module instanc

by panic 8y ago

Not sharing memory is a pretty big restriction, though. For example, if you have variable-length data like a string, you can't pass it to a WASM module instance without either calling a function repeatedly for each data unit (slow) or sharing memory and passing a pointer (unsafe).

danShumway 8y ago
Someone can correct me if I'm wrong[0], but I believe the proposal for shared linear memory allows importing multiple chunks. So assuming nothing changes and my understanding is correct, you'll just have to split your memory into two chunks; one that's safe to share and one that you keep private to your module. And of course, unless you're writing WASM yourself by hand (which is possible, but I don't know how many people are doing it), your compiler should handle all of this for you -- so at the point where Rust or whatever says, "we want to allow you to split your code into multiple WASM modules instead of just bundling it all into one", it would have to come up with some kind of allocation strategy for this. [0]: https://webassembly.org/docs/semantics/#linear-memory https://webassembly.org/docs/semantics/#linear-memory
- panic 8y ago
  That's a link to the spec, which documents the fact that every memory operator refers to a single "default" linear memory (which can be shared or private). I don't think any of the features on the roadmap (https://webassembly.org/docs/future-features/ https://webassembly.org/docs/future-features/) include support for this kind of chunked memory. I agree that it would be very useful, though!
  - danShumway 8y ago
    Linear memories (default or otherwise) can either be imported or defined inside the module. ... In the MVP, linear memory cannot be shared between threads of execution. The addition of threads :unicorn: will allow this. To me that sounds like, "define multiple linear memories, then import them after you instantiate the module." But I could be misinterpreting.
    - panic 8y ago
      I don't think the thread proposal will change anything here. Like the existing memory instructions, the atomic instructions proposed for threads (https://github.com/WebAssembly/threads/blob/master/proposals/threads/Overview.md https://github.com/WebAssembly/threads/blob/master/proposals...) don't take a linear memory parameter. That means they operate on the same default linear memory.
      - danShumway 8y ago
        You are very right, dug into it a bit more and none of the memory functions (new atomic ones included) have parameters to specify a memidex. Thanks for looking into that, it's good to know. > In the current version of WebAssembly, at most one memory may be defined or imported in a single module, and all constructs implicitly reference this memory 0. This restriction may be lifted in future versions. But I don't get the impression that it's completely unplanned. Modules still take a vector of linear memories, not just one[0], which would be pointless if it wasn't planned to let you access the others at some point. Data segments also explicitly allow referencing a memidx[1] (even if right now 0 is the only one that's allowed). Still, I've been under the impression that this was going in as part of threads, and I was all excited since threads were making such good progress. I'm a little disappointed to find out it's not. It's also possible globals[2] might solve some of the same problems? But I haven't dug into them enough to know what their memory model looks like or how well they work across multiple modules, and in any case, sharing multiple globals is probably going to be less convenient than just sharing memory, so I'd still like to see the ability to import multiple chunks of memory. [0]: https://webassembly.github.io/threads/syntax/modules.html# https://webassembly.github.io/threads/syntax/modules.html# [1]: https://webassembly.github.io/threads/syntax/modules.html#syntax-mem https://webassembly.github.io/threads/syntax/modules.html#sy... [2]: https://developer.mozilla.org/en-US/docs/WebAssembly/Using_the_JavaScript_API#Globals https://developer.mozilla.org/en-US/docs/WebAssembly/Using_t...

by panic 8y ago

danShumway 8y ago

Someone can correct me if I'm wrong[0], but I believe the proposal for shared linear memory allows importing multiple chunks. So assuming nothing changes and my understanding is correct, you'll just have to split your memory into two chunks; one that's safe to share and one that you keep private to your module. And of course, unless you're writing WASM yourself by hand (which is possible, but I don't know how many people are doing it), your compiler should handle all of this for you -- so at the point where Rust or whatever says, "we want to allow you to split your code into multiple WASM modules instead of just bundling it all into one", it would have to come up with some kind of allocation strategy for this. [0]: https://webassembly.org/docs/semantics/#linear-memory https://webassembly.org/docs/semantics/#linear-memory

panic 8y ago
That's a link to the spec, which documents the fact that every memory operator refers to a single "default" linear memory (which can be shared or private). I don't think any of the features on the roadmap (https://webassembly.org/docs/future-features/ https://webassembly.org/docs/future-features/) include support for this kind of chunked memory. I agree that it would be very useful, though!
- danShumway 8y ago
  Linear memories (default or otherwise) can either be imported or defined inside the module. ... In the MVP, linear memory cannot be shared between threads of execution. The addition of threads :unicorn: will allow this. To me that sounds like, "define multiple linear memories, then import them after you instantiate the module." But I could be misinterpreting.
  - panic 8y ago
    I don't think the thread proposal will change anything here. Like the existing memory instructions, the atomic instructions proposed for threads (https://github.com/WebAssembly/threads/blob/master/proposals/threads/Overview.md https://github.com/WebAssembly/threads/blob/master/proposals...) don't take a linear memory parameter. That means they operate on the same default linear memory.
    - danShumway 8y ago
      You are very right, dug into it a bit more and none of the memory functions (new atomic ones included) have parameters to specify a memidex. Thanks for looking into that, it's good to know. > In the current version of WebAssembly, at most one memory may be defined or imported in a single module, and all constructs implicitly reference this memory 0. This restriction may be lifted in future versions. But I don't get the impression that it's completely unplanned. Modules still take a vector of linear memories, not just one[0], which would be pointless if it wasn't planned to let you access the others at some point. Data segments also explicitly allow referencing a memidx[1] (even if right now 0 is the only one that's allowed). Still, I've been under the impression that this was going in as part of threads, and I was all excited since threads were making such good progress. I'm a little disappointed to find out it's not. It's also possible globals[2] might solve some of the same problems? But I haven't dug into them enough to know what their memory model looks like or how well they work across multiple modules, and in any case, sharing multiple globals is probably going to be less convenient than just sharing memory, so I'd still like to see the ability to import multiple chunks of memory. [0]: https://webassembly.github.io/threads/syntax/modules.html# https://webassembly.github.io/threads/syntax/modules.html# [1]: https://webassembly.github.io/threads/syntax/modules.html#syntax-mem https://webassembly.github.io/threads/syntax/modules.html#sy... [2]: https://developer.mozilla.org/en-US/docs/WebAssembly/Using_the_JavaScript_API#Globals https://developer.mozilla.org/en-US/docs/WebAssembly/Using_t...