Interest in evaluation of Wasm GC proposal

[timjs]

The Wasm GC workgroup is working on an extension to Web Assembly to support languages which require garbage collection. There is a lot of discussion going on on type system features of this extension: structural vs nominal types and the representation of recursive types are two the main points.

Currently, concrete feedback on this proposal from source languages targeting Wasm (so called producers), is limited to a Java to Wasm compiler. To get the full picture, more input is needed from languages having a different type system than Java.

Gleam is an ideal source language to compile to Wasm GC and use the experience writing such a backend to improve the shape of this new internet standard. Gleam is functional, and we need input from functional languages. Also, Gleam targets the web, so comparison between its current JavaScript backend and a Wasm GC backend on code size as well as performance would be very valuable input.

Main goal of Wasm GC is that it should be a (way) better target for languages which currently target JavaScript. Concrete evaluation criteria are not yet agreed upon, but one should think in the direction of:

• How simple is it to target Wasm with GC from a source language?
• Which problems do arise when targeting Wasm GC?
• Is the provided type system complete enough to model source language types?
• Can data be reflected faithfully, or are many casts needed when targeting Wasm GC?
• Is performance of Wasm modules on par or better than when compiling to JavaScript?

So, my question is:

Is there any interest in the Gleam community to help writing a backend targeting Wasm GC and share their experience with the working group?!?

I'm currently not in the situation to fully immerse myself in such a project, but I'd love to support it! I can imagine that the Gleam maintainers are already fully occupied, but I hope they will be open to provide helpful information in developing such a backend. Maybe there are some sponsors interesting to fund this work? Maybe there are some computer science students looking for a masters thesis subject? Doesn't matter if your not graduating form the Open University in the Netherlands (where I teach) we can still arrange something. Maybe you're looking for a new challenge during your free evenings? Anybody interested: do reach out!

[lpil]

Hello! Thanks for reaching out. This is a very exciting and cool thing you're working on! Here are some of my thoughts:

Web assembly compilation is something that I am very interested in for Gleam, however it's is very much in the ideas stage for me because there are numerous other features which I think need to come first. I also ran out of money so I had to stop working on a Glean full time in order to get a job, so I mentally shelved the idea for now.

My thoughts were that we could compile to web assembly by first compiling to C or C++, though this may not be suitable if using a wasm GC. I was interested in exploring reference counting for memory management as Gleam is an immutable language and as such reference cycles are not possible. If reference counting proved and suitable I was interested in copying the Erlang concurrent garbage collector as I think it has many great properties.

While a generic web assembly garbage collector would likely not have some of the advantages of these approaches due to it not being designed for Gleam, I suspect the advantage of it being ready for us to use and the reduced binary size of not having to ship a memory management system could make it worth using nevertheless. I think it would however mean that we could not compile to native code without first going to assembly.

I am very interested in your work here, both in the context of Gleam and more generally, but unfortunately I am not able to work on this any time soon. If someone else wishes to work on this I would be happy to offer them my thoughts and ongoing guidance.

[timjs]

Thanks for your kind words!

First of all, sorry to hear sponsoring on Gleam dried up, hope you find a nice job and still have some time to spend on Gleam!

I think you describe the situation of GC for Gleam quite accurately. Refcounts would be a good technique for Gleam, when you intend it to be a language without mutability and only (co)inductive data types. These articles on optimised refcounting for functional languages could be of interest in that context: Perceus, Lean. Maybe Koka/Perceus would even be a good compilation target!

Using Wasm's GC would be some sort of "shortcut". Maybe not the most optimal solution for Gleam, but a solution which:

• provides garbage collection out of the box;
• would relying on the collectors of Wasm engines like V8, Node, Wasmtime, or Wasmer and their optimisations;
• produce small binaries;
• provide easy interop with other languages compiling to Wasm when the interface types proposal is ready;
• compile to native code through Wasm and Wavm.

Side question:
Is the BEAM using reference counting as well? I thought it used a generational gc, but I'm not up to date with the latest tech used around Erlang.

[lpil]

It's not so much that sponsoring has dried up, more that while it is growing it is not yet enough to be a livable wage in the city where I live. Fingers crossed for the not so distant future though :)

I've been looking at Perceus with great interest. I shall have to check out Lean too, thank you for the recommendation.

Those are very attractive properties, especially with the focus that Gleam has on interop with other languages. While I'm not in a place to do anything now I will watch with great interest for how this develops.

The BEAM uses a generational garbage collector where each actor gets its own heap, and actors' heaps are only garbage collected if they are already suspended by their scheduler (typically when waiting for a message). It also has a shared heap for large binaries to minimise copying, references to which are reference counted. There's also a pool for literal values and a "virtual binary heap" but I'm not sure what that last one does.