gc support

[minad]

Summary

What are the plans of wasmer regarding GC if it gets added to the wasm spec?

Additional details

I wonder what the plans of the various webassembly runtimes are regarding to GC. Right now it seems wasmer implements the MVP (or maybe already some of the extensions?). GC support seems to be a controversial feature of WebAssembly (see for example WebAssembly/gc#36). While I am a proponent of a GC to support languages which need it, I recently experimented with compiling a native language runtime via clang-8 to wasm, such that the GC is just part of the wasm binary. It seems to work reasonably well in my case, since the GC is made such that it works well with uncooperating environments. However it is impossible to achieve small binary sizes (at least 200KiB to 500KiB due to the runtime). This is probably not an issue with the intended use case of standalone webassembly runtimes.

But another aspect got me a bit thinking - wasmer etc are promoted as sandboxed environments. Adding a GC however also makes wasm more complex, increasing attack surface etc. Therefore I would like to know what the plans are here.

(I have more questions regarding this sandboxing issue - in particular if you plan to adopt seccomp etc. There are also many interesting projects in the unikernel space with a tiny attack surface, e.g. https://github.com/Solo5/solo5. Please let me know if my questions are appropriate here, I've just seen these "question" tags).

[MarkMcCaskey]

Hi @minad ! Thanks for your interest!

I don't have that much context on this, but as far as I understand it, we do plan to follow the wasm spec and implement GC if/when that is the case. As you point out, there's a lot of complexity and it's something we'll have to think about and design carefully to ensure sufficient performance and security.

I don't think wasmer will be getting a GC in the near-term future, but we'll let you know and talk about it publicly when we have more formal plans.

In general though, security is very important to us! But it hasn't been a major focus yet because we have a ton to do, but we'll definitely be focusing on it more in the not-too-distant future.

[minad]

@MarkMcCaskey Thanks!

[skuzmich]

GC proposal has made a lot of progress since this issue wasm answered. It is now in Phase 3 and is supported in V8 and SpiderMonkey with experimental flags.

Do you have any updates regarding Wasmer plans to support GC?

We would love to use Wasmer with the new GC-based Kotlin/Wasm compiler we're working on.

[pannous]

maybe reopen as tracking issue?

[observer11rac]

see https://nodejs.org/en/blog/announcements/v22-release-announce
new features in nodejs 22
includes new features like "WebAssembly Garbage Collection" (Wasmgc)

can we get it in wasmer now

[Hixon10]

It became more popular - https://web.dev/case-studies/google-sheets-wasmgc

[metaleap]

So... re-open mayhaps?

[tjpalmer]

Various languages are talking about or supporting Wasm but only for WasmGC. Pluggable GC would be nice. But without some GC support, I'll likely eventually have to stop using Wasmer for my project.

[syrusakbary]

Updates: we will support GC in the upcoming version of Wasmer 5.1 (thanks to V8 integration). Should be released pretty soon!

[tjpalmer]

Updates: we will support GC in the upcoming version of Wasmer 5.1 (thanks to V8 integration). Should be released pretty soon!

Great to hear! Does that mean it won't work for the Cranelift backend? I'm concerned that V8 might be much larger than Cranelift, but I haven't checked yet.

[syrusakbary]

That’s right. We won’t support yet GH with Cranelift just yet. Regarding build sizes there shouldn’t be a very big difference between Cranelift and V8 (at least, in theory)