Are there any proposals for allocators?

[oovm]

I'm writing a wasm backend, but I'm finding it quite challenging to write an allocator in wasm.

There are many languages that actually simply translate the mature allocator in the original language into wasm.

The disadvantage is that the product is a bit large.

It's quite complicated to make a trade-off between size, performance, and security.

In order to reduce the size, some particularly small allocators was used in the wasm target, which resulted in security problems(wee_alloc#106).

---

I would like to know if there are any ideas or proposals that can provide a convenient interface for malloc, realloc, dealloc, etc.

The runtime has its own high-performance, trustworthy allocator.

Can it be reused?

Since wasm now supports multiple memories, and it may be possible to allocate a dedicated memory for the allocator.

A preliminary idea is this

interface allocator {
    allocate: func(size: u64, mem_idx: u32)-> result<u64, alloc-error>; // return ptr
    reallocate: func(ptr: u64, size: u64, mem_idx: u32)-> result<u64, alloc-error>; // return old_ptr or new_ptr if no space
    deallocate: func(ptr: u64, mem_idx: u32)-> result<_, alloc-error>;
}

[pchickey]

This isn't the right fit for a component model interface: the component model intentionally does not expose a component's linear memory in order to provide a security boundary around the component's internals, as well as to ensure interfaces will be compatible with wasm-gc languages once canonical ABI support is built for those. Whatever allocator is used inside a component will need to remain fully encapsulated by that component.

[sbc100]

I wonder if you could have a shared allocator that doesn't actually need access to the linear memory its managing? i.e. You could give it information about bounds of a memory and ask it to perform allocations, without actually giving it access to the memory? That would also have the upside of keep allocation metadata separate from actually allocated data, making metadata corruption impossible. One could even imagine writing the allocator itself in a wasm-GC language :)

[fitzgen]

The component model would allow you to have a shared allocator module that each component can link in and whose code would be deduped across them, but this wouldn't/couldn't be a WASI interface because it is a module not a component and requires access to the linear memory, as @pchickey mentioned.