Needing AOT mode load-time dynamic linking feature

[zy-sunshine]

We need to load AOT program, and some common code compiling to a AOT module, to dynamic link in runtime.

I already test the multi-module demo in samples directory, but after looking into the implementation, I found it is only support in wasm mode (NOT AOT mode).

We must use AOT mode to match our need for CPU speed, so I'm curious that are there some plans to support load-time dynamic linking feature in AOT mode?

We also look forward to support load wasm and can load depended module which in AOT mode, because wasm file is 1/4 size of AOT file size.

Thanks.

[wenyongh]

@zy-sunshine Sorry for the late response! The multi-module feature for AOT mode is really important, we are discussing it and plan to implement it, but it really needs effort and time.

[SeediqQ]

@wenyongh We are also looking forward to seeing this feature. May I ask if there is already a plan or TODO list?

[zy-sunshine]

Thanks for your response, we will follow up this feature, and we will use it to implement the dynamic push app feature, and we have made some progress on the application framework. Looking forward to your progress.

[lum1n0us]

A big concern here is the overlap between "load-time" dynamic linking and the component model. Both technologies are about how a Wasm module instances cooperating with others. So, it means we might do a same job twice in different ways.

We'd like to learn more on your thoughts about those two technologies.

[zy-sunshine]

A big concern here is the overlap between "load-time" dynamic linking and the component model. Both technologies are about how a Wasm module instances cooperating with others. So, it means we might do a same job twice in different ways.

We'd like to learn more on your thoughts about those two technologies.

q1: "load-time" dynamic linking q2: component model you are talking about q1 and q2, I think they are different. q2 has many dimensions including how to split app and common lib

1. split app: a. split by app dimension, one app has one WASM compiled file.(we use this method currently) b. split by page dimension, one app has many pages. c. split by component dimension, because some component will be shared in multi-page (this is an ideal method)
2. split common lib: because each wasm will include some common library, like libc(maybe some exported symbol), language runtime(like assemblyscript's runtime include it's lib(string array map), gc, and so forth) a. current we use split-by-app dimension, so we each app wasm will include libc/AS runtime independently. b. the ideal method is to use split-by-component dimension, and split libc/AS-rt into a separate library.

Load Phase: If the app's main entry wasm module is loaded, it will load the libc/AS-rt library firstly, then load the page wasm, then load the components wasm owned by this page recursively, I think these wasm should running in one continuous memory space(stack/heap).

Unload Phase: If one page of app is unloading, it will unload the owned components firstly and then unload itself secondly, but keep the libc/AS-rt in memory, then it will load another wasm page. Memory remains constant throughout this process.

[another topic]Memory fragmentation problem: Because memory fragmentation will be increase with app running, so we will consider how to release all heap at some time point to alleviate or eliminate this problem. I think it will affect the split dimension.

I don't know if the description is clear, please let me know if you have any questions, and I feel that there are still many things that have not been expanded.

[lum1n0us]

When I mentioned the component model before, it means https://github.com/WebAssembly/component-model.

[zy-sunshine]

https://github.com/WebAssembly/component-model/blob/main/design/high-level/UseCases.md#performance I just read the component-model doc. I think it is a complex mechanism, and does not meet my needs. I do not need a component(model) runtime, because we will implement my own mechanism(already said before). I do not need a RPC liked framework, and the serialization deserialization will cause some performance issue.

There are some views that are more in line with my needs.

A component runtime implements value passing between component instances without ever creating an intermediate O(n) copy of aggregate data types, outside of either component instance's explicitly-allocated linear memory. A component runtime shares the compiled machine code of a component across many instances of that component. A component is composed of several core wasm modules that operate on a single shared linear memory, some of which contain langauge runtime code that is shared by all components produced from the same language toolchain. A component runtime shares the compiled machine code of the shared language runtime module.

In conclusion, we just need a "load-time" dynamic linking mechanism(AOT), It is similar to the dynamic library(so) mechanism of the linux platform, and it is important on RTOS system to have a dynamic library load implementation.

In addition, there is no thread usage in my code, pure logic. So I think the solution should be how to manipulate many piece of wasm machine code(AOT), and load unload when needed according to the dependencies.

[another topic] Ideally I think the split method should be same as rollup.js(a JavaScript module bundler), we can specify multiple entries, and compiler(asc or emsdk or wasi) will compile all code together and split these wasm machine code to modules automatically according to these entries, and generate these module's dependency. But this may be a job for other compiler.

[lum1n0us]

In conclusion, we just need a "load-time" dynamic linking mechanism(AOT), It is similar to the dynamic library(so) mechanism of the linux platform, and it is important on RTOS system to have a dynamic library load implementation.

IMU, this requirement actually wants a kind of dynamic linker. Treat Wasm modules as shared libraries and implement a all-in-one(memory) running environment. Because of the specific usage scenarios, it won't meet any challenges like multi-threads, instance isolation, one-level import type, and so on. Yes, "dynamic linker" would be a good fit.

I do not need a component(model) runtime, because we will implement my own mechanism(already said before). I do not need a RPC liked framework, and the serialization deserialization will cause some performance issue.

It seems there is an ongoing/function ability implantation. Maybe we can start the discussion based on that and see if we can merge it.

[wenyongh]

@zy-sunshine @SeediqQ The AOT multi-module feature was recently enabled with PR #2482, please try if you are interested in it.