Comments (11)
@no1wudi yes, maybe we can add another option for wamrc to allow to call runtime API to do boundary check in AOT/JIT mode, but I am not sure whether it is good to make it as default mode for the shared-heap/mmap functionality, had better test the performance to see the result first?
The performance overhead does need to be tested. What I can confirm is that if boundary checks are implemented using an if-else if sequence in LLVM IR, it will significantly increase the code size. In some of our applications, the code size could double as a result.
from wasm-micro-runtime.
Implementation tasks:
-
add WAMR_BUILD_SHARED_HEAP and WASM_ENABLE_SHARED_HEAP
-
add wamrc --enable-shared-heap
-
consider the behavior of import memory in multi-module feature
-
adapt address conversion/validation
aot code boundary check
wasm_runtime_invoke_native
wasm_runtime_invoke_native_raw
wasm_runtime_validate_app_addr
wasm_runtime_addr_app_to_native
wasm_runtime_addr_native_to_app
wasm_runtime_validate_native_addr -
interpreter/fast-jit do boundary check
classic interp mode
fast interp mode
jit -
Support setting shared heap’s size and shared heap’s alloc options in RuntimeInitArgs for wasm_runtime_full_init
-
Add check in load module, default memory’s max_memory_size should be no larger than 4G-shared_heap_size, if not, reduce it to 4G-shared_heap_size
-
Add API wasm_runtime_shared_malloc/wasm_runtime_shared_free
-
App allocates memory from shared heap with API shared_malloc/shared_free
example
#include <stdio.h>
#include <stdlib.h>
extern void *shared_malloc(int size);
extern void shared_free(void *ptr);
int main()
{
int *pa = (int *)malloc(4);
*pa = 4;
printf("pa value is %d\n", *pa);
free(pa);
int *ps = (int *)shared_malloc(4);
*ps = 5;
printf("ps value is %d\n", *ps);
shared_free(ps);
}
from wasm-micro-runtime.
do you mean to have a single global shared memory, which all wasm modules with a linear memory on the system can fully access?
i guess it would be a bit more usuful if you can control it. eg. multiple shared memories, which the embedder can selectively associate to wasm instances.
semantically, is the shared region always treated as if it's a shared memory?
eg. does it prevent some possible optimizations like dead load/store eliminations?
from wasm-micro-runtime.
Awesome. At the W3C in person event, Deepti presented on providing a mmap
function. In her use case this is used to mmap
hardware memory into the WASM VM's address space, and could perceivably physically call mmap
on the host system. The remapping of linear memory to the mmap
space was discussed as well, and idea was to use the lower memory address range as an easily re-mappable memory region with an efficient load / store implementation.
Is it worth while checking in with Deepti, to ensure there is no clashes, kinda wondering if we could end up with the lower chunk of linear memory made available to an mmap
instruction, and the uppper chunk reserved from sharing between modules. It might be nice / important to be able to mmap
host memory and share it between modules too?
from wasm-micro-runtime.
do you mean to have a single global shared memory, which all wasm modules with a linear memory on the system can fully access? i guess it would be a bit more usuful if you can control it. eg. multiple shared memories, which the embedder can selectively associate to wasm instances.
Yes, in current discussion, it is supposed to only have a global shared heap, each wasm module can access it, and the shared heap is created during runtime initialization. Your idea sounds reasonable, but then runtime should create the shared heap lazily, the working flow may be like below:
- runtime initialization as normal
- runtime creates shared heap 1
- some instances associate to shared heap 1
- runtime creates shared heap 2
- some instances associate to shared heap 2
- ...
For performance consideration, I think we had better restrict that each wasm instance can only associate to one shared heap, or it will be too complex and might greatly impact performance. How do you think?
semantically, is the shared region always treated as if it's a shared memory? eg. does it prevent some possible optimizations like dead load/store eliminations?
Yes, the shared region is always mapped to the shared heap, and my suggestion is we always use software boundary check for it since we have to add extra check for which region the wasm addr belongs to, so it should be able to prevent dead load elimination optimization.
from wasm-micro-runtime.
but then runtime should create the shared heap lazily, the working flow may be like below
yes.
if you want, you can still create the first shared heap on the runtime initialization.
i don't think it simplifies things much though.
I think we had better restrict that each wasm instance can only associate to one shared heap
i agree.
from wasm-micro-runtime.
Awesome. At the W3C in person event, Deepti presented on providing a
mmap
function. In her use case this is used tommap
hardware memory into the WASM VM's address space, and could perceivably physically callmmap
on the host system. The remapping of linear memory to themmap
space was discussed as well, and idea was to use the lower memory address range as an easily re-mappable memory region with an efficient load / store implementation.
Thanks @woodsmc. Not know how mmap function is used, does it mean that the wasm app can call the mmap function, and runtime maps the mmapped memory to the lower range of wasm memory address space and then change the behavior of wasm load/store accordingly? And can wasm app call mmap function multiple times? If yes, it may impact performance a lot. And not sure why map to lower range of wasm address space: (1) IIUC, the 0 of wasm addr is reserved for the check for C NULL pointer by clang, clang reserves a space from 0 and doesn't put the app's global data at 0, (2) if map to the lower range, then wasm app should reserve a relatively larger space for it, it may be not so convenient for toolchains/developers, at least for clang, developer should add --global-base=n
option.
Is it worth while checking in with Deepti, to ensure there is no clashes, kinda wondering if we could end up with the lower chunk of linear memory made available to an
mmap
instruction, and the uppper chunk reserved from sharing between modules. It might be nice / important to be able tommap
host memory and share it between modules too?
Yes, it would be great if we discuss more with Deepti. I think we should be able to support both the mmap and the shared heap if needed since one uses the lower range of wasm addr space and the other uses the higher range, but maybe we don't need to support mmap when the shared heap is enabled, since runtime can also use mmap function to allocate the memory for shared heap or even provide callback for developer to allocate the memory.
from wasm-micro-runtime.
I guess that implementing shared memory using either the shared heap or mmap methods will make memory boundary checks more complex. Therefore, I have an idea about boundary checks in #3548.
Perhaps it could serve as the basis for implementing shared memory functionality. What do you think?
from wasm-micro-runtime.
@no1wudi yes, maybe we can add another option for wamrc to allow to call runtime API to do boundary check in AOT/JIT mode, but I am not sure whether it is good to make it as default mode for the shared-heap/mmap functionality, had better test the performance to see the result first?
from wasm-micro-runtime.
Yes, in current discussion, it is supposed to only have a global shared heap, each wasm module can access it, and the shared heap is created during runtime initialization. Your idea sounds reasonable, but then runtime should create the shared heap lazily, the working flow may be like below:
runtime initialization as normal
runtime creates shared heap 1
some instances associate to shared heap 1
runtime creates shared heap 2
some instances associate to shared heap 2
Could this association conform to the principles of a component model in the future? Being able to restrict the accessible area per component (or similar concept) would support a variety of use cases.
from wasm-micro-runtime.
Yes, in current discussion, it is supposed to only have a global shared heap, each wasm module can access it, and the shared heap is created during runtime initialization. Your idea sounds reasonable, but then runtime should create the shared heap lazily, the working flow may be like below:
runtime initialization as normal
runtime creates shared heap 1
some instances associate to shared heap 1
runtime creates shared heap 2
some instances associate to shared heap 2Could this association conform to the principles of a component model in the future? Being able to restrict the accessible area per component (or similar concept) would support a variety of use cases.
Yes, when component mode is implemented in the future, I think we can also associate part or all of the instances inside the component to a shared heap, and for the latter, we may add an API for the component to associate all its instances to a shared heap. It depends on the requirement.
from wasm-micro-runtime.
Related Issues (20)
- [RFC] Core module Dynamic Linking HOT 54
- support multi-value from host
- memory may not be shared: threads not allowed HOT 21
- [RFC] wasm32-wasi-p2-module HOT 7
- [WASI] Should we overlook or restrict the access modes for stdin/stdout/stderr? HOT 4
- CI doesn't cover shared library
- Unable to run C++ program in esp32 HOT 9
- How to use the native API with int64 parameters? HOT 1
- Why do functions implemented in wasm require more than one parameter when calling CallFuncV? HOT 3
- Global mutex does not work HOT 1
- Have an issue while importing jump functions in runtime(iwasm) HOT 1
- File operations are not supporting HOT 6
- An invalid section specifier `.aot_stack_sizes` HOT 1
- AOT module load failed: resolve symbol __atomic_compare_exchange_4 failed HOT 6
- The qWasmStackValue command is missing during runtime debugging
- AOT_SECTION_TYPE_SIGNATURE HOT 2
- WASI sockets: POSIX platform `os_socket_recvfrom` unintended behavior
- sysbench mutex workload is taking more execution time with iwasm than native x86_64 execution HOT 2
- sysbench memory and threads workload is giving less benchmarking results with iwasm than native aarch64 gcc execution
- Updating Exception Handling in WAMR HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from wasm-micro-runtime.