Stream: wamr

Topic: Questions regarding memory allocation strategies

Antoine Lavandier (Jan 08 2026 at 13:30):

Hi,
I'm trying to use WAMR on top of some rust OS using the wamr-rust-sdk crate. This is only for testing/benchmarking pupose so I'm not worried about doing a proper port.
Anyway, after tinkering around I was able to compile to run on an NRF52840DK (Thumbv7 arch) and I have had errors regarding allocations. After tracking the source of my error, I realized that this is because I stubbed os_mmap from the platform_api_vmcore.h. I'm surprised by this being an issue for two reasons:

• This function is in a section called APIs required by WAMR AOT and compiled without AOT support and in the configuration specified that I wanted to run the interpreter.
• I used the memory pool allocation strategy instead of using the system alloc strategy.

This leads me to the following questions :

• Did I misunderstand something ?
• What does the memory pool strategy do if not use the provided pool to put the linear memory of the instances ?
• It seems to require more memory that I would have thought: loading the modules fails when the pool is under 120 KiB, despite the module weighing 262 bytes by itself and the linear memory seemingly not being part of the equation.

The exact allocation path is related to the linear memory of the instance i'm trying to build. I'm using WAMR 2.3.1, the version used by the wamr-rust-sdk

Thanks in advance

lum1n0us (Jan 12 2026 at 02:08):

I'm not quite following the sentence of "because I stubbed os_mmap from the platform_api_vmcore.h." However, I assume it suggests that the problem is caused by an incorrect implementation of os_mmap().

The statement "APIs required by WAMR AOT" is outdated, that's for sure. It should be updated to reflect the fact that wasm_memory.c is used to create linear memory across all three allocation strategies.

Besides the part for the WASM file itself, the runtime also requires memory resources for its own operation and execution, which can be configured by arguments of wasm_runtime_instantiate() such as default_stack_size and host_managed_heap_size . Additionally, the initial and maximum linear memory size, like (memory 10 20), of the WASM module can be partially controlled by compilation flags.

Antoine Lavandier (Jan 12 2026 at 08:53):

lum1n0us said:

I'm not quite following the sentence of "because I stubbed os_mmap from the platform_api_vmcore.h." However, I assume it suggests that the problem is caused by an incorrect implementation of os_mmap().

Not quite an incorrect implementation, I just hadn't implemented it.

The statement "APIs required by WAMR AOT" is outdated, that's for sure. It should be updated to reflect the fact that wasm_memory.c is used to create linear memory across all three allocation strategies.

Ok, that's what I figured but it's nice to be reassured that I'm not crazy.

Besides the part for the WASM file itself, the runtime also requires memory resources for its own operation and execution, which can be configured by arguments of wasm_runtime_instantiate() such as default_stack_size and host_managed_heap_size . Additionally, the initial and maximum linear memory size, like (memory 10 20), of the WASM module can be partially controlled by compilation flags.

Makes sense, however in the specific context I didn't have much control on wasm_runtime_instantiate arguments so maybe 120KiB is a default somewhere ?

That being said, I still don't get what Alloc_With_Pool does if os_mmap is still used in the process of allocating the linear memory. Maybe it's another case of outdated information but this blog post flat out says

The mode restricts all the memory used by wamr in a fixed memory region that was provided by the host during initiating the WAMR runtime. All the memory categories are allocated inside the memory region by using WAMR built-in memory allocator ems.

Which to me means that os_mmap shouldn't have to be implemented. Or is supposed to be implemented by redirecting calls to this ems allocator ?

lum1n0us (Jan 14 2026 at 05:26):

:thinking: In that case, you might want to refer to the implementation of the Zephyr platform in the link: https://github.com/bytecodealliance/wasm-micro-runtime/blob/main/core/shared/platform/zephyr/zephyr_platform.c#L184-L221

Antoine Lavandier (Jan 14 2026 at 09:01):

Thanks for the pointer. I have already basically copied the implementation from RIOT and now the interpreter works. I still have some issues with AOT however. Still I'm not sure that I grasp the various memory models of WAMR if I end up using the system allocator whether I want to or not...

For the WAMR AOT stuff, in some files, wamr fails with AOT module load failed: resolve symbol __aeabi_memclr failed.
The target is an Rasperry PI Pico 2 W. Wamr is compiled with WAMR_BUILD_TARGET = "THUMBV8M.MAIN" and the AOT file was produced with wamrc --target=thumbv8m.main --target-abi=eabihf
Any idea of where that could come from ?

Thanks for the previous replies btw !

lum1n0us (Jan 26 2026 at 00:14):

You might want to add platform specification implementation under core/iwasm/aot/arch.

Last updated: Feb 24 2026 at 05:28 UTC