Milan (Aug 12 2023 at 21:18): Milan (Aug 12 2023 at 21:18):I'm trying to understand aspects of how to think about the component model from the perspective of what a WebAssembly runtime has to deal with.
My understanding: .wasm files will be used to represent both wasm core modules and wasm components. A host runtime could be aware of WASM components (link together before running, inject lift/lower instructions, etc) but effectively after linking at runtime or ahead of time using wasm-tools to compose components together for execution there are not WASM component specific-concerns for the runtime. After linking components the runtime is just running a core wasm module.
If that is an accurate understanding: What are the "not widely supported" core wasm features needed to run "already-linked" wasm components? I think my assumption is that features like shared-nothing linking necessitate the multiple memories proposal. The "already-linked" module mental model is that isolation happens at runtime because of multiple memories, multiple function tables, etc.
I was thinking this best represents how wasm components relates to wasm core but (unless my searching is poor) I'm not finding references to the Multiple Memories proposals in the component-model repo or the "core wasm" track in the preview2 roadmap: https://bytecodealliance.org/articles/webassembly-the-updated-roadmap-for-developers
Is my assumption that WASM Core Multiple Memories is needed for the component model (specifically for something like shared-nothing linking) incorrect?
I think the alternative is the wasm components themselves are a concept that exists into runtime. Conceptually the boundaries of components are persistent and within the executing context a concept of separate components actually exist and is something runtimes have to be aware of (and handle a components specific concept of linear memory per component unrelated to wasm core multiple memories).
As an aside: I think something that could be helpful for wrapping one's head around components are guides of what What WASM Components means from the perspective of runtime authors vs programming language tooling / runtime maintainers vs developers creating WASM modules / components. Know if there are any resources along those lines to reference?
Christof Petig (Aug 13 2023 at 06:34):Components require multiple memories per wasm file (component), but not per module like the multi memory proposal does, because the different modules contained in a component need their own separated address space supported by the runtime. The second requirement is support for the more complex wasm file format described in https://wasm-components.fermyon.app/encoding.html
Christof Petig (Aug 13 2023 at 06:42):E.g. WAMR describes these two in https://github.com/bytecodealliance/wasm-micro-runtime/issues/2126 and its linked issue, although it is not easy to parse the terse issue descriptions.
Milan (Aug 14 2023 at 15:40):Thank you for the references! My understanding was way off and the referenced fermyon docs helped give the high-level context I needed to actually make sense of the components spec.
Milan (Aug 14 2023 at 16:01):Only partially related: The cargo-components README has the most succinct and clear high-level description of the component model I have read so far: https://github.com/bytecodealliance/cargo-component#motivation
fitzgen (he/him) (Aug 15 2023 at 15:43):Christof Petig said:
Components require multiple memories per wasm file (component)
Minor clarification: there is nothing requiring that a component has multiple memories. It is perfectly fine for a component to contain a single memory, or even zero memories (provided it is not passing data across the component boundary that requires a memory, such as strings).
Christof Petig (Aug 16 2023 at 21:52):fitzgen (he/him) said:
Minor clarification: there is nothing requiring that a component has multiple memories. It is perfectly fine for a component to contain a single memory, or even zero memories (provided it is not passing data across the component boundary that requires a memory, such as strings).
Is my understanding correct, that to support arbitrary components (especially the ones containing multiple modules) the runtime needs to be able to support multiple memories per component?
Pat Hickey (Aug 16 2023 at 22:04):yes a component can contain multiple core modules and each of those modules may have 1 memory (or more with the multi-memory core wasm proposal, but that is orthogonal to the component model), so the component runtime will need to support multiple memories to run arbitrary components.
Pat Hickey (Aug 16 2023 at 22:05):its not quite the same as the wasm multi-memory proposal because the idea behind that proposal is that, with multiple memories in scope for a module, the load and store opcodes have an additional literal indicating the index of memory they are using
Last updated: Nov 22 2024 at 17:03 UTC