 Hi everyone, thanks all for coming. I'm Ivan Mikushin, and I work for VMware currently. So, who am I? I'm staff engineer at VMware. As of a few days ago, recognized contributor at the Byte Code Alliance, and I'm working on WASM GC support in the WASM tools as a site project. So, what got me here? Mostly curiosity, and a friendly encouragement from a bunch of people. So, I've been watching WebAssembly evolve since 2018. Haven't been doing much, just playing around. And so recently, I got very interested in zero-knowledge cryptography. So, sorry for the sidetrack here. So, in zero-knowledge cryptography, an important concept is verifiable computation. To enable that, the computation is encoded in algebraic constraints, and sort of with a language that defines arithmetic circuits, implementing the computation. These are very hard to use, and it's very easy to create bugs. For reference, there's a little blog post from friends of mine talking about this. So, a little example. So, here's a little example in a language that defines a little arithmetic circuit. We have an input, an output, and a variable defining an array. And we're trying to get out a value from an array depending on what came in the input. This, of course, results in an error, which is quite cryptic. The error reads non-quadratic constraint was detected statically using unknown index will cause the constraint to be non-quadratic. This, of course, is non-legible, and she'd rather look at WebAssembly text format. So, anyway, what I'd ideally love to have is general purpose verifiable compute, where any program execution could be provable, not just ones defined in a circuit language. That would be, ideally, in one language, admittedly, a lower-level one, a Wasm, as we're here at WasmCon, and just have everything compile to Wasm, right? Well, there's a little problem that most languages require garbage collection. And we'll see this leans nicely into our to-do item, or to-do item, why should I care? Because the talk is named, what is WasmGC and why should I care? So why I care, personally? Well, most popular programming languages will be compiled to Wasm, as I predict, and they require garbage collection. So an empirical law that says what can be done in JavaScript will be done in JavaScript. I predict we'll soon read what can be compiled to Wasm will be compiled to Wasm. But that, of course, meets a little problem that most languages that people use, I mean, we all use other languages, but most developers out there use Java, JavaScript, Python, Go, and many more languages that all require garbage collection. So that leans into our next to-do item is what is WasmGC, where GC is required by all these languages. So well, GC is, of course, garbage collection, as per Wikipedia, a form of automatic memory management. A garbage collector attempts to reclaim allocated memory that is no longer referenced, and it was invented in 1959 by John McCarthy to simplify memory management in Lisp, which, by the way, is my favorite language. So what is WasmGC? We see this URL here. It points to the proposal to add garbage collection support to WebAssembly. And I'll touch a little bit about what WasmGC is not. So it is not a garbage collector specification. A personal story, when starting to work on this, I was, I dreaded that I'd be, and excited, I'd be working on something like a concurrent mark, mark-and-sweep, not the case, because actually, Web-based runtimes already have high-performance GCs, and there are high-performance GCs available at service side. We just need to use them. So what we do need is, we need to add heap types to make use of that. And what also is explicitly a non-goal, which is titled by the component model, by the way, is seamless interoperability between multiple languages. So what is WasmGC? Well, WasmGC is a bunch of new types and a bunch of new instructions. We are adding new heap types, and there are about 30 new instructions that get added to the specification. Okay, let's talk the specification. The proposal is divided into MVP and post MVP and specifically the MVP talks about reference types, heap types, sub types, recursive types, and the instructions, while post MVP, which we don't know, will be implemented possibly in the future, talks about things like type parameters, polymorphs and generics, threads and shared references, weak references, a lot more, and we may or may not see all or some of these implemented. Okay, let's talk about the current scope. So heap types is the key to all of this. Okay, so what are the current kinds of memory available in Wasm? Well, mostly people talk about linear memory, but I say there's stack that we use while when calling things, and they are of course even explicit instructions in Wasm to work with stack. There's linear memory, of course, and heap, finally, that is added with garbage collection. So heap, what is it? Is a pool of memory used to fulfill memory allocation requests? By Wikipedia. And here we see a picture of fully allocated heap. So there are three disjoint hierarchies of heap types in WebAssembly. We have functional types, external types, and aggregate types. So the things that are being added to the specification is aggregate types, dynamically allocated managed data. So here we see the type hierarchy here. So of course, func and extern types have been added by previous proposals, reference types and function references. So everything else here is added by Wasm GC. And the picture is courtesy of a spec for prototype implementation in Chromium. So let's talk about index types. So here in the first listing in WebAssembly text notation, we see two types added, type A and type B. The first one is a struct, the second one is an array. We can probably see they are, the struct adds, defines two fields. One is mutable 32-bit integer. Second is not mutable, 64-bit integer. And type B is an array of mutable 32-bit integers. And the second listing here shows how this looks and something like go. So reference types. Well, of course, heap types are not used directly. They are used as references. And again, we see a very simple type defined here. And we see two references using that type. So first is as a parameter to function f1. That's a nullable reference. And the second is a non-nullable reference to the same type as a result of function two. Again, the second listing shows us how this looks in something like go. And a bunch of shorthands. So these shorthands are added so that actually every shorthand here is bytecode itself. So we don't need to write a ref null funk. We can say funkref instead. And yeah, note that for ref null none and ref null noextern and ref null nofunk, we use these names starting from with null. And let's see, what's next? We also have this little funny type here. I31 ref, which is something called unboxed scalar. All right. So I promised to talk about ways to define new types and this obviously is subtyping. So type A is simply an index type that is a struct. Here we were emitting any fields for the sake of showing the subtyping hierarchy. And the second listing here is a source code in Java that would compile into something like this in the WebAssembly format above. So class B extends A and we have a final class C that extends A as well. So one of the most interesting thing here is recursive type groups. So we see an example of that. And what it means is that types that are used to comprise the recursive type group are allowed to refer to other types in the type group even if their index is larger than their index. For example, so we see here type A and it has a reference to an algebra reference to the type B. So normally this would not be allowed. So what we see here in type B, this is what we could see everywhere else when referring to different types. But without the recursive type group, type A would not be possible. And yeah, again we'll look at the source code of something that would compile to something like that this time again in Go. We can easily see what code translates to this kind of WebAssembly. Okay, so there are 30, about 30 new instructions added to the specification and they group around the types of objects, obviously. So we see some instructions manipulating unboxed scalars, creating and manipulating arrays and structs, casting and testing values of reference types and conditional branching depending on values of reference types and external reference conversions. All right, so that is the initial instruction in a nutshell what WASMGC is. And before we finish is, I wanna make a little prediction. We will see compilers to WebAssembly with garbage collection support coming. And we'll see these for very popular languages coming up pretty soon. There are a bunch of projects out there like GrowlVM and it's just a matter of time. And GrowlVM already supports WebAssembly so as it's input language. And GrowlVM of course also compiles to native images. We just need to see WASM as a native image format. And this will add support for Java and JVM based languages as long as Python and Ruby very, very soon. So, but I actually think that Go will be the first because the pace of development in that ecosystem is pretty astounding. So I would say Go will probably be the first garbage collected languages that compiles to WASMGC. We'll see. So I should also point out that there is a editor's draft of WebAssembly specification. Basically the release 2.0 with added tail calls and function references and GC proposals. It's not the official draft, but it's an editor's draft. You see the URL here. And last time I checked it was the beginning of August. This time is pretty much the end of August. So this gets a very quick development. So another resource I want to point out is contributing to WASM time. Actually to be able to contribute to WASM time, it's not much more than what is written in that documentation here. And if you go and start talking to people on bytecode lines Zulip, like they are very friendly people and it's very easy to get started contributing. And there's a lot of things that need to be done in, for example, in this webpage here. There's a bunch of WASI proposals that need implementation. So yeah. And with this I wanna thank you. I am a cushion on all the socials and I want to extend special thanks to Nick Fitzgerald, Al-Fasli, Daniel Lopez, XVMware, and David Wong of ZK Security. So thank you very much. And I guess we have a ton of time for questions. Go ahead. Is there gonna be a component? Yes, good question. So these types, if we look at, for example, I gotta know, let's look at something like a struct or array. So these, that's actually why the talk is called what is WASMGC, right? It does not specify garbage collector. It does not specify how the data expressed in these data types going to be garbage collected. But so basically the garbage collector is implicit here but you do need these data types to kind of place the data on the heap, right? So we're talking about the third type of memory here. So before WASMGC there are only two types of memory, stack and linear memory. So stack you use for calling functions, linear memory to manipulate bytes and maybe share between modules. So before that, before adding the heap, we didn't have that. So the heap is something that the runtime uses, like the runtime controls the memory, the pile of memory that is called the heap. And when you use something like an array or something like a struct in these data types, this data is placed on the heap. And then when that data is no longer referenced, it's magically gone. So the heap kind of gives you an illusion of infinite memory when in fact it is not. And this is the job of the garbage collector to ensure that. Please, unfortunately I cannot. I am very curious about that myself and I intend to learn more in the coming weeks. Yeah, so I did have a chat with a person who works on WASI and he said like, look, we first need to have this stuff work in baseline WASM, right, implemented in runtimes. And then we can talk about adding it to the component model, which is fair I think. Please. So I believe so. So here we're looking at two functions, right? And I guess before you can call any of these, the validator has now all the information, like actually even before executing your module, the validator has the information to say, hey, you cannot call this now. I'm blanking on this, unfortunately. Maybe there are people in the audience who can... Please. Oh, for sure. So yeah, i31 is called an unboxed reference. So the reference itself is a number, right? So to address a memory cell or a part of a heap, we use, well, WebAssembly uses 32-bit integers. We can take out one bit from the reference and say, hey, actually we were using the remaining 31 bits for actually a number, and that would be your unboxed scalar. So it's not an address. So that first bit would flag that, hey, this is not actually an address in the heap. It's just number. This is a 31-bit number instead of a 32-bit number. Well, you could use it for, I don't know. Actually, I don't know. Cool, thank you. Any more questions? Please. So a garbage collection is a form of automatic memory management, right? So like in Rust, we actually do not use automatic memory management. In Rust, you use something like borrower checker. It's the job of the compiler to make sure that what gets allocated, what gets borrowed is returned, right? So like in garbage collection, in languages like Java or JavaScript, this is not the case. There's no borrower checker. So heap is used all the time. So objects are allocated left and right, and then they're just dropped. Like I mean forgotten. So what to do about that is garbage collection. So that's the... So that's why we explicitly use the heap for that. And by using the heap, we'll let the runtime know, these references need to be managed, and when there's no path from the root, then they need to be collected. So I guess different languages, different models, and there are a lot of languages that do require unfortunately garbage collection. Please. Yes. A great question. So I guess if the compiler knows exactly what to do with the memory, like in the case of Rust, then for sure use the linear memory. But then for those languages where you don't know, like there's no kind of deallocated instruction, right? Then just use the heap. And that will be the predominant use case for these most popular languages here. So yeah, Java also has linear memory. It's funny that Java always had the heap in garbage collection, but it only added linear memory very recently, right? And WebAssembly first, linear memory was the only one that it had, and it's now adding garbage collection. I guess we need all of them. Yeah, please. So it is not here today in terms of compiler support. That's correct. Yeah. So the lasngc support is being added actively. And like for example, I am not sure if it already has been added to Chrome, to the V8 engine, because this comes from the Chromim project, and the document where this is from is kind of final now. So I guess it's implemented in there already. And the wasmgc support is coming to wasmtime soon. So I'm working on wasmtools to enable that, and there are people here who are also working on adding the support to wasmtime, runtime directly. So we definitely will see this in a matter of months. Actually, I know a project that will probably give you the ability to use this technology as soon as it's available. I think it would be Kotlin. So if you code in Kotlin, then you'll probably get support for this as soon as it's available. All right. I think we are at time. And I'm excited you are here. And thank you so much for coming.