WIP: user heap using shared multi heap on Zephyr#102
Closed
Conversation
the user_malloc and user_free functions will be used on platforms with support for external PSRAM. This way we can differentiate allocations in the internal or external RAM. Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
These functions allocate memory on external PSRAM on boards that have CONFIG_SHARED_MULTI_HEAP enabled. Otherwise, they work just like core_malloc and core_free. Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
On systems with a single heap, these functions work exactly the same as malloc and free. Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
The user heap is user for large objects. Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
Use the user heap for wamr and related container memory. Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
In favor of the user heap mechanism. Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
We now use the user heap mechanism. Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
f1c6402 to
67f4de0
Compare
kr-t
reviewed
Nov 17, 2025
| memset(&init_args, 0, sizeof(RuntimeInitArgs)); | ||
| init_args.mem_alloc_type = Alloc_With_Pool; | ||
| init_args.mem_alloc_option.pool.heap_buf = wamr_heap_buf; | ||
| init_args.mem_alloc_option.pool.heap_size = sizeof(wamr_heap_buf); |
Collaborator
There was a problem hiding this comment.
If we use system heap in systems where we don't have PSRAM for wasm, then we can't limit it anymore. I don't think it's good - we need a way to limit max amount of warm's linear memory, don't we?
Contributor
Author
There was a problem hiding this comment.
I think we should enable WASM_MEM_ALLOC_WITH_USAGE and limit the amount of memory per-container instead. This is just the allocation. Every use of user_malloc should properly handle the ENOMEM error and recover gracefully if possible.
Collaborator
|
Discussion notes:
|
Contributor
Author
|
Closing this in favor of #116 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
In embedded systems with external PSRAM, we usually want to store our objects in two different heaps: one system heap for small and fast objects (like the internal SRAM); and another user heap or application heap which is used for large objects stored in external slow PSRAM.
This adds the user heap interface in ocre, and sets WAMR to use it as the application heap. We also use it to store the container parameter as well as the container image executable for running in WAMR.
This ultimately removes the need for the two build time configuration variables and make them automatically use the external heap.
In MMU systems, we usually only have one heap, so
user_malloc()does the same ascore_malloc().TODO:
user_realloc()must be correclty implemented for Zephyr.Type of change
Please delete options that are not relevant.
How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration including the following required details.
Test Configuration (required):
pico_plus2Checklist: