Wasmtime GitHub notifications bot (Oct 25 2022 at 14:49): Wasmtime GitHub notifications bot (Oct 25 2022 at 14:49):alexcrichton labeled issue #5120:
Currently the implementation of components in Wasmtime is naively integrated with core wasm, meaning that when using the pooling allocator each core wasm instance as part of a component will take up a separate slot on the pooling instance allocator. This goes against the high-level design of the pooling instance allocator and application design, however, where an "instance" typically corresponds to one slot and the resources in that slot are what's available for that single instance.
Instead I think a few changes to resource accounting should be made:
- Components should allocate a single
VMContext+VMComponentContext"smashed together" block. Wasmtime can statically identify how many core wasm instances are needed and calculate the total size needed to allocate all contexts together. Alternatively eachVMContextandVMComponentContextshould be allocated separately from within a single slot after a slot is reserved for the component. Either way, a single slot in the instance pool should correspond to the entire component instance.- Tables should also be updated to draw from one slot in the table pool. Currently most tables are not actually growable in core wasm which means that a component can leverage this and statically allocate tables where non-growable ones come first in a slot and an optional final growable table is at the end. This should suffice for function tables for now and futher options could be implemented in the future as necessary. Like the instance data, though, all table allocations should go through a single slot rather than optionally taking up multiple slots per component instance.
- Linear memories, however, will need to stay as-is. This means that, by default, a component will only be able to have one linear memory for the near future (unless the pooling allocator gives multiple linear memories to each slot). These are more tricky due to the address space reservation requirements so it's less obvious how to smash distinct allocations together from within a component.
Overall the component instantiation process, when using the pooling instance allocator, will need to be significantly refactored to ensure that instantiation of a component will work with only one pooling allocator slot rather than the multiple that happens today with one per core wasm instance.
Wasmtime GitHub notifications bot (Oct 25 2022 at 14:49):alexcrichton opened issue #5120:
Currently the implementation of components in Wasmtime is naively integrated with core wasm, meaning that when using the pooling allocator each core wasm instance as part of a component will take up a separate slot on the pooling instance allocator. This goes against the high-level design of the pooling instance allocator and application design, however, where an "instance" typically corresponds to one slot and the resources in that slot are what's available for that single instance.
Instead I think a few changes to resource accounting should be made:
- Components should allocate a single
VMContext+VMComponentContext"smashed together" block. Wasmtime can statically identify how many core wasm instances are needed and calculate the total size needed to allocate all contexts together. Alternatively eachVMContextandVMComponentContextshould be allocated separately from within a single slot after a slot is reserved for the component. Either way, a single slot in the instance pool should correspond to the entire component instance.- Tables should also be updated to draw from one slot in the table pool. Currently most tables are not actually growable in core wasm which means that a component can leverage this and statically allocate tables where non-growable ones come first in a slot and an optional final growable table is at the end. This should suffice for function tables for now and futher options could be implemented in the future as necessary. Like the instance data, though, all table allocations should go through a single slot rather than optionally taking up multiple slots per component instance.
- Linear memories, however, will need to stay as-is. This means that, by default, a component will only be able to have one linear memory for the near future (unless the pooling allocator gives multiple linear memories to each slot). These are more tricky due to the address space reservation requirements so it's less obvious how to smash distinct allocations together from within a component.
Overall the component instantiation process, when using the pooling instance allocator, will need to be significantly refactored to ensure that instantiation of a component will work with only one pooling allocator slot rather than the multiple that happens today with one per core wasm instance.
Wasmtime GitHub notifications bot (Aug 21 2023 at 15:57):alexcrichton commented on issue #5120:
Addressed in https://github.com/bytecodealliance/wasmtime/pull/6835
Wasmtime GitHub notifications bot (Aug 21 2023 at 15:57):alexcrichton closed issue #5120:
Currently the implementation of components in Wasmtime is naively integrated with core wasm, meaning that when using the pooling allocator each core wasm instance as part of a component will take up a separate slot on the pooling instance allocator. This goes against the high-level design of the pooling instance allocator and application design, however, where an "instance" typically corresponds to one slot and the resources in that slot are what's available for that single instance.
Instead I think a few changes to resource accounting should be made:
- Components should allocate a single
VMContext+VMComponentContext"smashed together" block. Wasmtime can statically identify how many core wasm instances are needed and calculate the total size needed to allocate all contexts together. Alternatively eachVMContextandVMComponentContextshould be allocated separately from within a single slot after a slot is reserved for the component. Either way, a single slot in the instance pool should correspond to the entire component instance.- Tables should also be updated to draw from one slot in the table pool. Currently most tables are not actually growable in core wasm which means that a component can leverage this and statically allocate tables where non-growable ones come first in a slot and an optional final growable table is at the end. This should suffice for function tables for now and futher options could be implemented in the future as necessary. Like the instance data, though, all table allocations should go through a single slot rather than optionally taking up multiple slots per component instance.
- Linear memories, however, will need to stay as-is. This means that, by default, a component will only be able to have one linear memory for the near future (unless the pooling allocator gives multiple linear memories to each slot). These are more tricky due to the address space reservation requirements so it's less obvious how to smash distinct allocations together from within a component.
Overall the component instantiation process, when using the pooling instance allocator, will need to be significantly refactored to ensure that instantiation of a component will work with only one pooling allocator slot rather than the multiple that happens today with one per core wasm instance.
Last updated: Nov 22 2024 at 16:03 UTC