bytecodealliance
[RFC] A New Allocation Strategy on Pool Mode
The request originates from the needs of several ongoing product developments. All of them are seeking to avoid allocations, more specifically page faults, during the execution of Wasm functions, whether from the runtime or from Wasm functions. Ideally, all allocations for both the runtime and Wasm during loading, instantiation, and execution would come from a single large memory block provided by the embedding. The benefits of this approach are considered in two aspects:
- It prevents memory fragmentation caused by the WAMR library.
- It allows for manageable memory usage for both WebAssembly and the runtime.
- It eliminates allocations during runtime operation, resulting in, from a system perspective, only one significant allocation.
I believe we can meet these requirements by restricting linear memory allocation to a POOL in the Alloc_With_Pool mode. Specifically, when using MEMORY_MODE_POOL, both wasm_allocate_linear_memory() and wasm_runtime_malloc_internal() would allocate from a pre-allocated memory pool.
I've noticed in PR#3029 that we unified wasm_allocate_linear_memory() with os_mmap(), and allowed platforms without an MMU to use os_malloc() to implement os_mmap(), which fully meets the above requirements.
However, a user has requested to implement these requirements on Windows, which also needs to support os_mmap(). While it's certainly feasible to use a compilation option to switch between two different os_mmap() implementations, generally speaking, allocating from a pool is more appropriate for pool mode and helps avoid confusion with mmap semantics.
@loganek @wenyongh Please let me know your thoughts
FYI: in WASI / Wasm System Structure Exploration of improvements or alternative solutions
Avoiding Dynamic Memory Allocation
A key requirement for many embedded applications is minimizing or eliminating completely the use of dynamic memory allocation. Heap-based allocation introduces unpredictability in execution time, increases memory fragmentation, and can lead to system instability, all of which are problematic for real-time and resource-constrained environments. Many embedded systems rely on static memory allocation to ensure deterministic behavior and avoid the overhead of garbage collection or complex memory management. It is therefore important that any dynamic memory allocation should be under explicit control of the developer.
However, a user has requested to implement these requirements on Windows, which also needs to support os_mmap().
Could you clarify why is Windows the problem? There's already an existing implementation of os_mmap for Windows in WAMR.
Also, maybe I don't understand fully what we're trying to achieve it, but even for the pool allocator, one must be able to provide the pool somehow - and for this some systems might choose to use mmap to reserve the memory, right?
