> Would it make sense for the runtime to expose an inbuilt alloc library that C/C++/Rust can use? A difficulty with that approach is that the alloc library's b

> Would it make sense for the runtime to expose an inbuilt alloc library that C/C++/Rust can use? A difficulty with that approach is that the alloc library's behavior would need to be standardized and deterministic. If it isn't deterministic then differences in program behavior can end up mattering. For example, if one browser ships a "smarter" alloc that reuses memory better then it could succeed to run a program that another browser ends up with fragmentation in linear memory and an OOM. Historically browsers have worked really hard to standardize behavior to avoid such differences. And standardizing the behavior of a malloc/free implementation is tricky for several reasons. First, there is a lot of complexity there - how you handle free lists, what chunk sizes do you use, etc. That's a lot to put in a spec. Second, once you standardize a particular behavior it can't be improved, and new ideas for better malloc/free are still being found. For those reasons I'm skeptical of this making its way into the wasm spec. In comparison, GC avoids these problems because there is nothing to spec: the pointer values are not observable.