Summary of sharing data/code between wasm module instances

[ayakoakasaka]

I believe that the issue with this title has been discussed in various places, but I would like to find a place where we can discuss it in order to speed up the resolution of this issue. Our team summarized the current use cases and solutions. (Great thanks to @yamt, @wenyongh, and @xwang98, for sharing your valuable opinions)

sharing data/code between wasm module instances

It may not be necessary to focus on a single solution, but I believe that we can achieve better things if everyone moves in the same direction.

A lot is written in Document, but I will also post it here.

Use cases

1. Code sharing among WASM applications
   • Reduce the total footprint of the system when using a large common library
2. Optional code injection
   • Attach optional libraries for the debugging/tuning (weak references and library preloading)
3. Pass the data between WASM applications efficiently
   • Divide the monolithic application into composable applications without significant overhead
4. Pass the data between the host runtime and WASM module efficiently
   • Reduce the memory consumption
   • Reduce the copy overhead

Solution approaches

A. Export/import instance resources

• You can share WASM instance resources like linear memory and functions among module instances. Many of the other mechanisms listed below are based on this.

B. Dynamic linking

• Model: A single linear memory, shared among module instances (via export/import). Emscripten has had this for a while. Recently @dicej has enabled this for WASI too.

C. Multi-memory

• Make it possible for a module to have multiple linear memory. Eg. with memory export/import, it allows a module to have both non-shared memory and shared memory. You can use the former for ordinary heap and the latter for special purpose shared memory.

D. Memory control

• Expose some of host’s mmap features, including file-based mmap.

E. Garbage collector (GC)

• With GC proposal, you can share a reference to a byte array among module instances.

F. Disable memory bound check

G. Use the wasm memory for a data-processing buffer for host

• Use a part of linear memory for host-wasm data exchange.

H. Build-time allocation of linear memory regions

• An idea from @wenyongh . Make modules share a single linear memory. (either via memory import or runtime-specific mechanism) These modules are built with pre-determined offsets (eg. using -Wl,--global-base=) to avoid using the overlapping regions of the linear memory.

I. Use an external DB to store data

• Eg. https://github.com/WebAssembly/wasi-keyvalue/

Use cases vs solution approaches

Related means that in some cases this solution will work on its own, and in other cases it may require a combination of multiple solutions. (Eg B.DynamicLinking will not work without A.Import/Export memory for usecase)

Please read the Documentation for more details.

	1:Code sharing	2:Optional code injection	3:Share data between applications	4:Share data between host and wasm
A: Export/Import	related	related	related	related
B: Dynamic linking	related	related
C: Multi memory			related	related
D: Memory Control			related	related
E: GC			related	related
F: Disable memory bound check			related	related
G: Wasm work memory				related
H: Build-time allocation of linear memory regions	related	related	related	related
I: External DB			related	related

Hopefully, we can discuss which solution to move forward with and develop WAMR. Please let us know what you think.