-
Notifications
You must be signed in to change notification settings - Fork 7
Open
Description
Now that we have a built-in page-based allocator in std, we should start consuming it.
Benefits:
- standardize around std — properly coordinate with any wasm allocator
- really freeing memory — this should be identical to ArenaAllocator.deinit
- potentially ignore jumbo allocations entirely
Drawbacks:
- the std allocator requires an additional 1-2 KB
- need new metadata architecture for C-like malloc()
Questions:
- Is it possible to detect using "free()"? In theory, wasm_page_allocator can be tiny if it optimizes away the free/reuse bookkeeping, so it'd be amazing if it could detect at comptime whether free is needed.
- Should we keep around the current dumb page allocator and only enable the new path on "deinit()"? std.WasmPageAllocator was designed to handle freeing any memory page (including ones it didn't originally allocate) so this works around question 1.
Metadata
Metadata
Assignees
Labels
No labels