You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Now that we have a built-in page-based allocator in std, we should start consuming it.
Benefits:
Drawbacks:
Questions:
The text was updated successfully, but these errors were encountered: