Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC] Shared heap enhancements #4042

Open
TianlongLiang opened this issue Jan 21, 2025 · 0 comments
Open

[RFC] Shared heap enhancements #4042

TianlongLiang opened this issue Jan 21, 2025 · 0 comments

Comments

@TianlongLiang
Copy link
Collaborator

TianlongLiang commented Jan 21, 2025

Feature: Shared heap enhancements

Propose two enhancements:

  1. 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.
  2. 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 */
    bool
    wasm_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

  1. 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.

  2. To create a shared heap chain, the related shared heaps can't be attached to any wasm apps.

  3. 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant