Skip to content

Support std.WasmPageAllocator  #9

@fengb

Description

@fengb

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:

  1. 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.
  2. 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

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions