You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Shared heap created from preallocated memory buffer: The user can create a shared heap from a pre-allocated buffer and see that memory region as one large chunk; there's no need to dynamically manage it(malloc/free). The user needs to make sure the native address and size of that memory region are valid.
Introduce shared heap chain: The user can create a shared heap chain, from the wasm app point of view, it's still a continuous memory region in wasm app's point of view while in the native it can consist of multiple shared heaps (each of which is a continuous memory region). For example, one 500MB shared heap 1 and one 500 MB shared heap 2 form a chain, in Wasm's point of view, it's one 1GB shared heap.
Benefit
After these enhancements, the data sharing between wasm apps, and between hosts can be more efficient and flexible. Admittedly shared heap management can be more complex for users, but it's similar to the zero-overhead principle. No overhead will be imposed for the users who don't use the shared heap enhancement or don't use the shared heap at all.
High level design
New option for SharedHeapInitArgs to init a shared heap from the preallocated buffer
Three new export APIs to create/disconnect/destroy a shared heap chain:
/* connect the head and body(it can be a chain itself) to a shared heap chain */WASMSharedHeap*wasm_runtime_chain_shared_heaps(WASMSharedHeap*head, WASMSharedHeap*body);
/* disconnect the head from the shared heaps chain, return the new head */WASMSharedHeap*wasm_runtime_unchain_shared_heaps(WASMSharedHeap*head);
/* disconnect the whole shared heaps chain */boolwasm_runtime_shared_heaps_chain_destory(WASMSharedHeap*head);
The behavior of existing shared heap APIs: wasm_runtime_attach_shared_heap and wasm_runtime_detach_shared_heap can attach/detach the shared heap chain as well as the single shared heap.
Some implementation choices
In a shared heap chain, only one of the shared heap can be malloc/free. The rest of them have to be pre-allocated shared heap for management simplicity.
To create a shared heap chain, the related shared heaps can't be attached to any wasm apps.
No other export API added, how the pre-allocated shared heap's address passes between wasms and host depends on runtime management, for example, using native API.
Alternatives
The alternative can be instantiation linking + multi-memory to achieve a similar functionality. Further comparison can be arranged when the WAMR instantiation linking is ready and multi-memory is well supported in the upstream toolchain. My current estimation is that the performance won't be too much gap between the alternative and this enhancement, but the management can be potentially easier.
The text was updated successfully, but these errors were encountered:
Feature: Shared heap enhancements
Propose two enhancements:
Benefit
After these enhancements, the data sharing between wasm apps, and between hosts can be more efficient and flexible. Admittedly shared heap management can be more complex for users, but it's similar to the zero-overhead principle. No overhead will be imposed for the users who don't use the shared heap enhancement or don't use the shared heap at all.
High level design
New option for
SharedHeapInitArgs
to init a shared heap from the preallocated bufferThree new export APIs to create/disconnect/destroy a shared heap chain:
The behavior of existing shared heap APIs:
wasm_runtime_attach_shared_heap
andwasm_runtime_detach_shared_heap
can attach/detach the shared heap chain as well as the single shared heap.Some implementation choices
In a shared heap chain, only one of the shared heap can be malloc/free. The rest of them have to be pre-allocated shared heap for management simplicity.
To create a shared heap chain, the related shared heaps can't be attached to any wasm apps.
No other export API added, how the pre-allocated shared heap's address passes between wasms and host depends on runtime management, for example, using native API.
Alternatives
The alternative can be instantiation linking + multi-memory to achieve a similar functionality. Further comparison can be arranged when the WAMR instantiation linking is ready and multi-memory is well supported in the upstream toolchain. My current estimation is that the performance won't be too much gap between the alternative and this enhancement, but the management can be potentially easier.
The text was updated successfully, but these errors were encountered: