lukewagner
commented
1 month ago First of all, it's really exciting to hear about wasm_component_layer; that seems like a great project!
Unfortunately, I don't think there's a generic/turn-key way to merge N components into 1 component other than preserving the separate memories (which you can certainly do inside 1 component, but I think it's the number-of-memories that is the issue here, not the number-of-components. The most basic reason is that the core wasm running in a component may embed absolute addresses of linear memory and function tables as i32.consts that a merging tool would have no way to distinguish (and relocate) from normal integral i32.consts. I think there's also other, more subtle ways core wasm would break if it goes from having its own linear memory to sharing linear memory with other unrelated core modules.
Instead, I'd suggest preemptively grouping implementation code together into a single component (noting that a single component is always allowed to export multiple interfaces). E.g., all of wasi:cli/imports might go into one component. There are also ways to get fancy and factor out common core modules that would otherwise be duplicated.
One other emerging proposal that could really help here is https://github.com/WebAssembly/custom-page-sizes. With this proposal, you could keep your component-per-WASI-package design but set the custom guard page size for all their memories to 1 (or whatever the smallest page size ends up being) which indirectly ends up turning off the guard-page optimization, causing the engine to simply malloc/realloc the various linear memories.
juntyr
I am using WASM components on the web using the wasm_component_layer crate, which polyfills support by instantiating many WASM core modules with the multi-memory proposal.
In my application, I use a custom WASI implementation that is similar in functionality to wasi-virt to fully isolate the components I execute. Composing the "main" component with the WASI components is a beautiful solution as I can verify that the resulting component has no (WASI) imports.
The issue is that this approach translates into each instance of the composed component being run using many WASM core modules that all come with their own memory - in my application around 17 modules are required for one main component and one-component-per-wasi-package (all written in Rust and adapted to wasi-p2 using wasmtime's adapter). Since browsers use a lot of virtual memory to isolate even tiny WASM components, this very quickly gets out of hand and little actual memory usage hits the limit of how many WASM memories can be instantiated at a time.
In the long run, browsers may of course get native support for the component model and may be able to work around this limitation (though I also very much like wasm_component_layer's approach, which is adapted from jco, of translating the component model to core modules to maintain maximum compatibility).
What might be an interesting approach is to allow some sort of linking of WASM components that connects component model imports and exports like WASM compose would but could allow sharing the same memory (without exposing that to the application) and allow optimisers to optimise out some of the canonical ABI wrappers if both import and export are now linked together.
This approach would obviously be a trade-off since you would lose the isolation that components otherwise provide. However, providing the option may be beneficial in cases where someone wants the composability benefits of the component model but combine several small and trusted components to reduce the per-module overhead.
Is this something that could be implanted?
Thank you so much for your help!