Re:JavaScript to Rust and Back Again: A Wasm-Bindgen Tale
by kbenson on Thursday April 05, 2018 @01:26AM
(#16762047)
Is it really on the roadmap to support GC before a simple API level malloc/free? It seems like the sane progression path would be to have WASM support an API for malloc/free first (which would be useful any system that supports a pluggable memory allocator, as Rust is getting), them an API for requesting garbage collected bytes of memory (which I assume, with fairly little prior knowledge, malloc/free would be useful for).
[ Parent
| on HN ]
Re:JavaScript to Rust and Back Again: A Wasm-Bindgen Tale
by azakai on Thursday April 05, 2018 @11:07AM
(#16765574)
I'm not aware of any plans to support a malloc/free API currently. GC plans are already underway.
Thinking about it, it's actually not that obvious how to support a malloc/free API. It seems like it would need to be deterministic to fit properly on the Web. But writing a spec for that is not easy since efficient malloc/frees are fairly complex and detailed. And once specced out, it could never be improved.
GC on the other hand already exists on the Web, and all the complexity is not noticeable (except for things like proper weak refs and finalizers, which is why those have not been added to the Web yet) so the spec is fairly simple and it allows constant optimization on the implementation side.