4 ms·

> 3. WASM is mostly meant for low level languages I've been saying it for years, but I think finally 2023 has the chance of being the year in which Wasm GC shi

by titzer 4y ago

> 3. WASM is mostly meant for low level languages I've been saying it for years, but I think finally 2023 has the chance of being the year in which Wasm GC ships and managed languages start targeting Wasm more widely. We've made a lot of progress with the design, and V8 has a basically complete implementation. Google is targeting some internal apps to Wasm GC and seeing perf improvements over compile-to-JS, so I think this will likely be a success.

zozbot234 4y ago
There's no such thing as one-size-fits-all GC. Wasm GC will probably be just as successful as other attempts at generic "managed" runtimes, which is to say, not very.
- titzer 4y ago
  > There's no such thing as one-size-fits-all GC. Two aspects to that. One is the implementation, e.g. the GC algorithm. They vary widely in their performance characteristics. For the most part, they are semantically invisible. I fully expect many different engines to have different algorithms, and ultimately you can choose and tune the GC algorithm to your application's needs. Two is the semantics. We're aware of many failed attempts to make generic runtimes, and a critical factor is how universal the object model is. Of the many over the years, most have originated for a single language or paradigm of languages and have, in some sense, too high a level of abstraction. Wasm GC is a lower level of abstraction (think: typed structs), from which higher level constructs are implemented (like vtables, objects, classes, etc). Being lower level is a tradeoff towards universality that we have consciously made. That said, there are downsides, such as more casts, because it gets increasingly harder to safely encode invariants of source languages to avoid such casts at the lower level. We're OK with the overheads we've measured so far but are always looking for mechanisms to reduce or eliminate these.
  - zozbot234 4y ago
    > We're OK with the overheads we've measured so far but are always looking for mechanisms to reduce or eliminate these. You could encode arbitrary invariants by implementing verifiable proof-carrying code within Wasm. Then a wasm-to-native compiler could be designed to take advantage of such invariants in order to dispense with these overheads.
    - titzer 4y ago
      > proof-carrying code within Wasm That's a legitimately neat idea. There are couple of projects to improve safety of Wasm code using linear memory (such as RichWasm by Amal Ahmed and MSWasm by a number of folks at Stanford, UCSD, and CMU). Obviously unrestricted aliasing of the giant byte array that is memory makes this more difficult. I hope that Wasm GC can offer an abstraction base to express even more invariants. In some sense that will be a study in adding more powerful types and more powerful proof constructs that are either on the side or embedded in the code. So, exciting future directions!
galangalalgol 4y ago
Aren't there already gc languages in wasm? I know julia is.
- rob74 4y ago
  There are, Go can also be compiled to WASM, but it has to carry the whole Go runtime with it (including but not limited to the GC), so the WASM files are a bit fat. You can however use TinyGo, a "Go compiler for small places" (https://tinygo.org/ https://tinygo.org/).
  - galangalalgol 4y ago
    Yeah, I get the runtime can be big, but letting gc cross module boundaries seems really bad for sandboxing. I also kind of wonder why we'd want to use those languages in wasm other than their libraries and runtimes. If all you want is gc and performance why not use JavaScript or typescript? C# or go after a ~20% wasm penalty isn't going to be that much faster than js right? Or use something like nim that compiles to js and get libraries as well. The case for wasm always seemed to be absolute max performance in a safer package, which would send you towards languages that support manual memory management anyway.
    - titzer 4y ago
      One of the improvements that you get from the coming Wasm GC proposal is an object model that is inherently more space-efficient than JavaScript. While a lot of speculative optimizations can make JITed JS (of the right form) run fast with few checks, the object model inherently requires boxing or tagging and is not as memory-efficient as what Wasm GC structs give.
- mattarm 4y ago
  My understanding is that they each bring their own GC and run it as WASM code in the VM.
mike_hearn 4y ago
That would be cool but I wonder how much difference it will make. Most managed languages share at least two attributes: 1. Large runtimes and std libs. Python's "batteries included" is the epitome of this but even just java.base is large. This doesn't play well at all with browser cache segmentation. 2. You need a JIT for performance. A good test of whether WASM is really heading towards generality is whether you could implement V8 as https://www.google.com/v8-js.wasm https://www.google.com/v8-js.wasm and just auto-include it into HTML pages for backwards compatibility. I know you have unusual experience and expertise in meta-circular VMs - is WASM really heading in this direction? The two obvious sticking points today are: V8 would get downloaded fresh on each origin, and JITd fresh on each page load, and what does such a runtime emit as compiled code?. Is your JITC being JITCd by a JITC and if so is the JITCd output then being JITCd a second time? If so, how on earth does this make sense? An alternative would be to explore whether the process level sandboxes are now good enough to just allow native code to run inside them and let people use their existing managed language VMs. Google thought that was close to plausible many years ago with NaCL, and kernel sandboxes got a lot stronger since then. It seems we ended up with WASM more due to Mozilla politics than what makes sense technically.
- titzer 4y ago
  > 1. Large runtimes and std libs. Indeed. With the web's model, it seems tempting to make the browser cache do the work for you by putting the language runtime at a standard URL. That works, modulo the security features today that cache Wasm modules per-origin to avoid an engine JIT bug creating a cross-origin vulnerability. GC helps a bit with that in the sense that the GC algorithm itself moves down into the engine. > 2. You need a JIT for performance. I worked a bit on a prototype JVM on Wasm that used the Wasm bytecode format to encode Java constructs. That helps because then you don't have another bytecode interpreter running on level up, but ultimately you want somewhat more control over the JIT and the code it generates. Wasm engines supporting dynamic code generation at all (any finer-grained than a module) would help a lot there. Compiling V8 whole-hog seems like it would take a lot of doing. In particular, it has JITs and an interpreter that want to spit out machine code. That'd have to be replaced with Wasm backends. > It seems we ended up with WASM more due to Mozilla politics than what makes sense technically. The politics were...complicated. I'd tell my side but it's probably best I don't.
LAC-Tech 4y ago
A one size fits all GC is never going to be a great solution though, is it? Different languages have different GCs that are designed to work with their semantics. Some languages use a flag bit to tell the runtime if a value is stack or heap (Go, Ocaml), some languages allocate almost everything and assume a lot of short lived objects (Java)... How well will a generic WASM GC really work here?
- ilyt 4y ago
  Probably better than no GC whatsoever. And not having to bring whole GC code with you is benefit enough
- wtetzner 4y ago
  But the competition is compile-to-javascript, which has exactly the same problem. With WASM, you get to choose between using a generic, potentially sub-optimal GC, or having a larger payload and including a GC bundled with the application.
heather45879 4y ago
I think there’s somewhat of a disconnect between the original idea of WASM (in browser) versus headless. In the browser folks get JavaScript for free which collects its own garbage. WASM is there to supplement higher level language for performance-intensive tasks and as such, “lower level” languages make more sense for these code paths. I’d like to point out also that providing users a million languages to write plugins in for a product could create a lot of bloat. Imagine an image editor with 5 plugins, each written in its own language running in WASM sandboxes: golang, C#, assemblyscript, ruby, python. That’s 5 runtimes each running it’s own garbage collection logic. I can see the value for compute hosts because the very nature of the provided service is allowing users to write sandboxed apps. But I think for stand-alone applications it’s best to support one or two simple targets, whether sandboxed or otherwise. There are languages (Lua for example) optimized for this already. I suppose the benefit is that each application which uses the WASM backend can decide on their “official” language and provide a decent built-in IDE experience.
- wtetzner 4y ago
  > That’s 5 runtimes each running it’s own garbage collection logic. If the WASM runtime provides a GC, then all of those languages can share a GC.
  - habitatenergy 4y ago
    I don't think WASM should/would unify the GC across memory models, that could be extremely problematic. The gist of the idea is polyglot languages can leverage libraries across many languages. The fastest code is the code that was already built (that you didn't need to write). It's unlikely applications would actually implement libraries from 5 different runtimes (they could, but shouldn't), and if they use RUST libraries, there definitely wouldn't be any GC anyway. The benefit of this tech is it allows a new language to leverage historical codebases quickly without needing to re-invent every common utility library. This will inevitably speed adoption of newer languages, zero code tools, etc .. and is the epitome of Proebstings law, which could also accelerate Proebstings (which is every decade) to being to approach Moores law (but I'm not specifically saying that will happen, only that it could).

by titzer 4y ago

zozbot234 4y ago

There's no such thing as one-size-fits-all GC. Wasm GC will probably be just as successful as other attempts at generic "managed" runtimes, which is to say, not very.

titzer 4y ago
> There's no such thing as one-size-fits-all GC. Two aspects to that. One is the implementation, e.g. the GC algorithm. They vary widely in their performance characteristics. For the most part, they are semantically invisible. I fully expect many different engines to have different algorithms, and ultimately you can choose and tune the GC algorithm to your application's needs. Two is the semantics. We're aware of many failed attempts to make generic runtimes, and a critical factor is how universal the object model is. Of the many over the years, most have originated for a single language or paradigm of languages and have, in some sense, too high a level of abstraction. Wasm GC is a lower level of abstraction (think: typed structs), from which higher level constructs are implemented (like vtables, objects, classes, etc). Being lower level is a tradeoff towards universality that we have consciously made. That said, there are downsides, such as more casts, because it gets increasingly harder to safely encode invariants of source languages to avoid such casts at the lower level. We're OK with the overheads we've measured so far but are always looking for mechanisms to reduce or eliminate these.
- zozbot234 4y ago
  > We're OK with the overheads we've measured so far but are always looking for mechanisms to reduce or eliminate these. You could encode arbitrary invariants by implementing verifiable proof-carrying code within Wasm. Then a wasm-to-native compiler could be designed to take advantage of such invariants in order to dispense with these overheads.
  - titzer 4y ago
    > proof-carrying code within Wasm That's a legitimately neat idea. There are couple of projects to improve safety of Wasm code using linear memory (such as RichWasm by Amal Ahmed and MSWasm by a number of folks at Stanford, UCSD, and CMU). Obviously unrestricted aliasing of the giant byte array that is memory makes this more difficult. I hope that Wasm GC can offer an abstraction base to express even more invariants. In some sense that will be a study in adding more powerful types and more powerful proof constructs that are either on the side or embedded in the code. So, exciting future directions!

galangalalgol 4y ago

Aren't there already gc languages in wasm? I know julia is.

rob74 4y ago
There are, Go can also be compiled to WASM, but it has to carry the whole Go runtime with it (including but not limited to the GC), so the WASM files are a bit fat. You can however use TinyGo, a "Go compiler for small places" (https://tinygo.org/ https://tinygo.org/).
- galangalalgol 4y ago
  Yeah, I get the runtime can be big, but letting gc cross module boundaries seems really bad for sandboxing. I also kind of wonder why we'd want to use those languages in wasm other than their libraries and runtimes. If all you want is gc and performance why not use JavaScript or typescript? C# or go after a ~20% wasm penalty isn't going to be that much faster than js right? Or use something like nim that compiles to js and get libraries as well. The case for wasm always seemed to be absolute max performance in a safer package, which would send you towards languages that support manual memory management anyway.
  - titzer 4y ago
    One of the improvements that you get from the coming Wasm GC proposal is an object model that is inherently more space-efficient than JavaScript. While a lot of speculative optimizations can make JITed JS (of the right form) run fast with few checks, the object model inherently requires boxing or tagging and is not as memory-efficient as what Wasm GC structs give.
mattarm 4y ago
My understanding is that they each bring their own GC and run it as WASM code in the VM.

mike_hearn 4y ago

That would be cool but I wonder how much difference it will make. Most managed languages share at least two attributes: 1. Large runtimes and std libs. Python's "batteries included" is the epitome of this but even just java.base is large. This doesn't play well at all with browser cache segmentation. 2. You need a JIT for performance. A good test of whether WASM is really heading towards generality is whether you could implement V8 as https://www.google.com/v8-js.wasm https://www.google.com/v8-js.wasm and just auto-include it into HTML pages for backwards compatibility. I know you have unusual experience and expertise in meta-circular VMs - is WASM really heading in this direction? The two obvious sticking points today are: V8 would get downloaded fresh on each origin, and JITd fresh on each page load, and what does such a runtime emit as compiled code?. Is your JITC being JITCd by a JITC and if so is the JITCd output then being JITCd a second time? If so, how on earth does this make sense? An alternative would be to explore whether the process level sandboxes are now good enough to just allow native code to run inside them and let people use their existing managed language VMs. Google thought that was close to plausible many years ago with NaCL, and kernel sandboxes got a lot stronger since then. It seems we ended up with WASM more due to Mozilla politics than what makes sense technically.

titzer 4y ago
> 1. Large runtimes and std libs. Indeed. With the web's model, it seems tempting to make the browser cache do the work for you by putting the language runtime at a standard URL. That works, modulo the security features today that cache Wasm modules per-origin to avoid an engine JIT bug creating a cross-origin vulnerability. GC helps a bit with that in the sense that the GC algorithm itself moves down into the engine. > 2. You need a JIT for performance. I worked a bit on a prototype JVM on Wasm that used the Wasm bytecode format to encode Java constructs. That helps because then you don't have another bytecode interpreter running on level up, but ultimately you want somewhat more control over the JIT and the code it generates. Wasm engines supporting dynamic code generation at all (any finer-grained than a module) would help a lot there. Compiling V8 whole-hog seems like it would take a lot of doing. In particular, it has JITs and an interpreter that want to spit out machine code. That'd have to be replaced with Wasm backends. > It seems we ended up with WASM more due to Mozilla politics than what makes sense technically. The politics were...complicated. I'd tell my side but it's probably best I don't.

LAC-Tech 4y ago

A one size fits all GC is never going to be a great solution though, is it? Different languages have different GCs that are designed to work with their semantics. Some languages use a flag bit to tell the runtime if a value is stack or heap (Go, Ocaml), some languages allocate almost everything and assume a lot of short lived objects (Java)... How well will a generic WASM GC really work here?

ilyt 4y ago
Probably better than no GC whatsoever. And not having to bring whole GC code with you is benefit enough
wtetzner 4y ago
But the competition is compile-to-javascript, which has exactly the same problem. With WASM, you get to choose between using a generic, potentially sub-optimal GC, or having a larger payload and including a GC bundled with the application.

heather45879 4y ago

I think there’s somewhat of a disconnect between the original idea of WASM (in browser) versus headless. In the browser folks get JavaScript for free which collects its own garbage. WASM is there to supplement higher level language for performance-intensive tasks and as such, “lower level” languages make more sense for these code paths. I’d like to point out also that providing users a million languages to write plugins in for a product could create a lot of bloat. Imagine an image editor with 5 plugins, each written in its own language running in WASM sandboxes: golang, C#, assemblyscript, ruby, python. That’s 5 runtimes each running it’s own garbage collection logic. I can see the value for compute hosts because the very nature of the provided service is allowing users to write sandboxed apps. But I think for stand-alone applications it’s best to support one or two simple targets, whether sandboxed or otherwise. There are languages (Lua for example) optimized for this already. I suppose the benefit is that each application which uses the WASM backend can decide on their “official” language and provide a decent built-in IDE experience.

wtetzner 4y ago
> That’s 5 runtimes each running it’s own garbage collection logic. If the WASM runtime provides a GC, then all of those languages can share a GC.
- habitatenergy 4y ago
  I don't think WASM should/would unify the GC across memory models, that could be extremely problematic. The gist of the idea is polyglot languages can leverage libraries across many languages. The fastest code is the code that was already built (that you didn't need to write). It's unlikely applications would actually implement libraries from 5 different runtimes (they could, but shouldn't), and if they use RUST libraries, there definitely wouldn't be any GC anyway. The benefit of this tech is it allows a new language to leverage historical codebases quickly without needing to re-invent every common utility library. This will inevitably speed adoption of newer languages, zero code tools, etc .. and is the epitome of Proebstings law, which could also accelerate Proebstings (which is every decade) to being to approach Moores law (but I'm not specifically saying that will happen, only that it could).