You give it a heap. It doesn't allocate memory. It may allocate within its own heap, using whatever allocator/gc strategy it inherits from it's host language.

Which means it can't free. But that's also not accurate, anyway, there's a brk() method to grow the heap. Which is such a bad starting point for a new runtime.

Would it be impossible to implement mmap and sbrk in the runtime?

mmap is arguably the only thing it should have had in the first place. brk/sbrk is fairly dead.

  $ ktrace /bin/ls >/dev/null
  $ kdump | grep brk | wc -l     
         0
  $ kdump | grep mmap | wc -l
       130

glibc, musl, and jemalloc got the memo, they just couldn't be bothered to stop using brk by default. They're all capable of using mmap exclusively, however, because whether or not brk is actually dead, there's long been consensus that mmap is the better abstraction on balance, particularly given the benefit of ASLR. So there's little reason to support brk instead of mmap for compatibility. Presumably it was chosen for the convenience of WebAssembly implementations--contiguous, flat memory is a great simplifier of VM, JIT, and even traditional AoT architectures.

Right, and while you can grow the heap you can't give any of it back, so you can't really dynamically contract your memory without restarting the process.

I thought that was the host's work. You import a function that does it. If we're talking about shared objects. Your own module's memory is managed by you (or your language's runtime)