asterius icon indicating copy to clipboard operation
asterius copied to clipboard

Introduce C runtime and delegate low-level memory management to it

Open TerrorJack opened this issue 5 years ago • 0 comments

Is your feature request related to a problem? Please describe. Our memory manager is only designed to manage mblocks and recycle Haskell closures. There's no support for managing out-of-heap non-moving blobs via a malloc-like interface. Although one can use pinned ByteArray#s to somehow simulate malloc, it's not space-efficient. Writing a decent malloc implementation takes quite some work though.

A more proper solution is to just use the malloc implementation in the existing wasm toolchains (typically dlmalloc/musl). And given malloc and aligned_alloc is available, we might as well delegate all low-level memory management to them, so the mblock allocator would just call aligned_alloc to create mblocks.

Additionally, this would pioneer the possibility of introducing C toolchains into the asterius universe. There has been a lot of discussions and experiments, but it's hard due to numerous factors (e.g. incompatible object formats, calling conventions, virtual address space, etc). The following section proposes a solution that has minimal intrusion into how we link things today.

Describe the solution you'd like

  • [ ] Use wasi-sdk to generate a self-contained .wasm module which works with imported memory/table, and exports essential libc functions like malloc
  • [ ] Implement "two-stage" instance initialization in the runtime. Stage 0 would initialize the libc wasm module produced above; stage 1 would initialize the asterius-compiled wasm module, using exported functions from stage 0.
  • [ ] Refactor our runtime functions to utilize libc functions like malloc.

Once this works, we can take a step further and pioneer the support of 3rd-party C libraries and user-supplied cbits, but that belongs to new issues.

TerrorJack avatar May 19 '20 14:05 TerrorJack