Evan Simmons (Oct 10 2024 at 17:53): Evan Simmons (Oct 10 2024 at 17:53):Hi bytecodealliance,
I've been looking at language options for implementing wasm components. When considering JS as a source language, I was surprised to see the lack of a wasmgc compiler for JS. Seeing as the BA owns starlingmonkey I was hoping to get some context on why that approach is being taken over what dart and the jvm languages seem to be doing (compiling to wasmgc).
Thanks!
Notification Bot (Oct 10 2024 at 18:15):This topic was moved here from #general > Starlingmonkey approach vs wasmgc by fitzgen (he/him).
Chris Fallin (Oct 10 2024 at 21:05):The main considerations are timeline, compatibility and engineering effort. JS is a large language, and a full engine that supports every corner is a multi-year project; so the simplest possible answer to your question is that an engine that uses WasmGC would be a large refactor of an existing engine, and is a much longer path than porting an existing engine using linear memory and its own GC
Chris Fallin (Oct 10 2024 at 21:06):keep in mind too that JS' GC has a number of subtleties that would be difficult (impossible?) to map 1-1 to WasmGC as it is today: weak maps/ephemerons, finalizer registries, etc
Chris Fallin (Oct 10 2024 at 21:07):The other factor here is that JS is fundamentally dynamic; one can infer static object shapes at runtime, but that's not the same as what Java and Dart have with truly static, strong type systems. So a mapping to WasmGC would require another level of indirection where the Wasm-level GC structs are various slot shapes
Chris Fallin (Oct 10 2024 at 21:08):All this points to the more incremental approach we took: we ported SpiderMonkey to run on Wasm/WASI using its existing GC in linear memory, which was relatively straightforward (this was done four years ago, before StarlingMonkey wrapped SpiderMonkey/WASI); and then we've added compilation as a variant of its existing bytecode, using the same object runtime
Evan Simmons (Oct 11 2024 at 00:02):TYSM for the context, that makes total sense. Is there any perf data that has been published? (startup time, memory use etc)
Chris Fallin (Oct 11 2024 at 00:03):Startup time: there are various measurements around, and the benchmark in the wasmtime source tree, for Wasm instantiation. When you're launching a wizened wasm produced by the starlingmonkey build process, there is no runtime startup; you're launching a snapshot of an already-started runtime and you very quickly hit the first JS opcode. It's on the order of 5 µs or so.
Chris Fallin (Oct 11 2024 at 00:03):Execution speed: PRs that added AOT compilation have some relative measurements (tl;dr, about a 2.5-3x speedup). Relative to a full JIT engine on native, it's still slower, depends on workload.
Chris Fallin (Oct 11 2024 at 00:04):Memory use: depends on what the workload does of course; a base heap image is typically a few megabytes.
Chris Fallin (Oct 11 2024 at 00:04):As always my standard advice would be "measure it and see if it fits your use-case" :-)
Evan Simmons (Oct 11 2024 at 06:07):As always my standard advice would be "measure it and see if it fits your use-case" :-)
Excellent advice, the broad strokes here are super helpful as a starting point. And my goodness is 5 µs impressive!
Jonas Kruckenberg (Oct 23 2024 at 08:10):Heya :) Might be worth mentioning that CanadaHonk is working on an from-scratch JS to Wasm compiler, it's not the only effort in this space ofc but he's got 5 years of funding and already passes 50% of test262 so definitely something to watch
Jonas Kruckenberg (Oct 23 2024 at 08:10):doesn't help you right now though I think
Ralph (Oct 23 2024 at 08:33):@Jonas Kruckenberg always looking for a great path from js to wasm!
Victor Adossi (Oct 24 2024 at 14:35):Hey @Jonas Kruckenberg do you know anything about the porffor project's plans to implement WASI? Right now there's not much other than tracking issue from May (though of course I'm sure they're busy with lots of other things :)
Jonas Kruckenberg (Nov 06 2024 at 07:09):hey @Victor Adossi sorry for the delay, I went and asked oliver about wasi and he said currently it’s a custom set of imports for ease of development but that later on supporting wasi probably will be a thing
Jonas Kruckenberg (Nov 06 2024 at 07:09):just bc obviously thats sort of where everybody is heading
Last updated: Dec 23 2024 at 13:07 UTC