5 ms·

C# etc. shipping a runtime is a current limitation of wasm and those ports to wasm. But in principle once wasm has GC support they can also compile to tiny bina

by azakai 9y ago

C# etc. shipping a runtime is a current limitation of wasm and those ports to wasm. But in principle once wasm has GC support they can also compile to tiny binaries. Not for everything, of course - if you use certain C#/Java/Kotlin features you'll need bundled runtime support. But if you avoid them, you don't. For comparison, Rust can't emit tiny binaries if you use malloc/free, because it needs to bundle those. This is actually an area where Rust/C/C++ are at a disadvantage once wasm has GC, as GC will be "free" while malloc/free won't be, so many programs will be smaller as C#/Java/Kotlin rather than Rust/C/C++.

kbenson 9y ago
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).
- azakai 9y ago
  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.
tuukkah 9y ago
>GC will be "free" while malloc/free won't be malloc is several magnitudes simpler than GC though. Then there's the question when (if ever) wasm will have GC and what kind of GC will it be.
steveklabnik 9y ago
Yeah, the question is, how much can you realistically not use those features? I don't actually know. You don't have to give up any of the Rust language. It's true that you need to ship malloc/free, but that can be really tiny too; https://github.com/fitzgen/wee_alloc https://github.com/fitzgen/wee_alloc is less than a kilobyte.
- azakai 9y ago
  > You don't have to give up any of the Rust language. I don't know Rust that well, but what about unwinding and multithreading for example - don't you need to give those Rust features up if you don't want to ship any runtime code? > It's true that you need to ship malloc/free, but that can be really tiny too True, yeah. It's a tradeoff, though, tiny mallocs will be much slower than an optimized malloc (like dlmalloc) on real-world benchmarks.
  - mmstick 9y ago
    Rust doesn't have a runtime, so there's no runtime code to ship in the first place. It's as low level as C, but with a modern syntax and accompanying core and standard libraries. Thread support is done by using existing OS primitives for threading.

by azakai 9y ago

kbenson 9y ago

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).

azakai 9y ago
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.

tuukkah 9y ago

>GC will be "free" while malloc/free won't be malloc is several magnitudes simpler than GC though. Then there's the question when (if ever) wasm will have GC and what kind of GC will it be.

steveklabnik 9y ago

Yeah, the question is, how much can you realistically not use those features? I don't actually know. You don't have to give up any of the Rust language. It's true that you need to ship malloc/free, but that can be really tiny too; https://github.com/fitzgen/wee_alloc https://github.com/fitzgen/wee_alloc is less than a kilobyte.

azakai 9y ago
> You don't have to give up any of the Rust language. I don't know Rust that well, but what about unwinding and multithreading for example - don't you need to give those Rust features up if you don't want to ship any runtime code? > It's true that you need to ship malloc/free, but that can be really tiny too True, yeah. It's a tradeoff, though, tiny mallocs will be much slower than an optimized malloc (like dlmalloc) on real-world benchmarks.
- mmstick 9y ago
  Rust doesn't have a runtime, so there's no runtime code to ship in the first place. It's as low level as C, but with a modern syntax and accompanying core and standard libraries. Thread support is done by using existing OS primitives for threading.