14 ms·

Bringing garbage collected programming languages efficiently to WebAssembly

426 points by kiyanwang 3y ago

Andrew018 3y ago
[dead]
samsquire 3y ago
This is exciting. I think WASM is an example of a thin waist [1] with its garbage collector and N+M rather than N×M. (N languages + M virtual machines + G garbage collectors). That's a mature garbage collector in V8. I was curious if there was a WASM to JVM and it seems there is one on GitHub, I haven't used it I was just curious because the JVM is a mature (and parallel) garbage collector. Now I'm excited for WASM Threads for true parallelism and not just IO parallelism because I didn't think WASMGC would come out so soon. The opportunity to solve async and parallelism and garbage collection EFFECTIVELY would strengthen WASM and not be a source of confusion or difficulty for developers. I think that's why WASI is so important, a chance to define an API as stable as POSIX. 1: https://www.oilshell.org/blog/2022/02/diagrams.html https://www.oilshell.org/blog/2022/02/diagrams.html 2: https://github.com/cretz/asmble https://github.com/cretz/asmble
- pjmlp 3y ago
  Following CLR footsteps, 22 years later. > More than 20 programming tools vendors offer some 26 programming languages — including C++, Perl, Python, Java, COBOL, RPG and Haskell — on .NET. From https://news.microsoft.com/2001/10/22/massive-industry-and-developer-support-for-microsoft-net-on-display-at-professional-developers-conference-2001/ https://news.microsoft.com/2001/10/22/massive-industry-and-d...
  - quickthrower2 3y ago
    Where is my Haskell.NET? Dammit!
    - delta_p_delta_x 3y ago
      F#: https://learn.microsoft.com/en-sg/dotnet/fsharp/what-is-fsharp https://learn.microsoft.com/en-sg/dotnet/fsharp/what-is-fsha... EDIT: Yes, F# is an ML-style language. I was answering the spirit of the question, which was 'statically-typed functional-first programming language running on the .NET CLR'.
      - masklinn 3y ago
        F# is ocaml.net not haskell.net
  - debugnik 3y ago
    If only the CLR had followed CLR footsteps as well, but they didn't even try after the DLR. Most non-Roslyn languages can barely interact with modern C# or the newer build configurations; even F# is playing catch-up and they're part of the official toolchain.
    - pjmlp 3y ago
      That is the sin of guest languages, that is why C rules on UNIX, JavaScript on Web, Java on the JVM, C# on the CLR, .... Every guest language means additional IDE plugins with platform knowledge, since most communities want idiomatic libraries, an ecosystem on top of the ecosystem, as the actual platform is only implemented in a main "systems" language, mastering it is required anyway for all the leaky abstractions on the platform, additional build toolchains,... In the end, each polyglot platform achieves a global maximum of main language, and possibly a winner among all guest languages, even if it takes a couple of years with projects fading away until this happens. It sucks, however so it is the outcome of human nature attention span, and not being able to keep momentum for all languages across the whole lifetime of a given platform.
      - HappMacDonald 3y ago
        It feels to me a little bit like how geographic regions wind up working out dominant spoken/written languages. The guest languages are like relying on (human or machine) speech/writing translation services to communicate with folks who only know the local lingua franca. That added friction hobbles the minority languages. Perhaps AI will aid in greatly reducing these issues over time (and I say this because large language translation models and text to speech + speech to text are finally reaching professional human quality while running on local hardware today). But I can't think of any other good method to hold back the floodgates of people being forced to choose between their mother tongue (with its corpus of invaluable baked in stories and perspectives) and being understood by others.
      - no_wizard 3y ago
        I think Kotlin is slowly eclipsing Java on the JVM. Its not majority yet but most new projects or major refactors I've seen are either 100% Kotlin or majority Kotlin. I would not be surprised if Kotlin takes a majority share eventually
  - titzer 3y ago
    I don't really know where to place this comment. Multi-language systems existed before, therefore Wasm should not, because it's already been done? It's interesting that none of the languages that you list made .NET a primary target and have all either bit-rotted unofficial ports or sunsetted their mainline support. It's hard to say whether languages that now target Wasm will suffer the same fate, since that depends on level of maintenance that each project allocates to particular targets. Still, I don't really get your point.
    - pjmlp 3y ago
      The usual amazement as if WASM was the first at anything...
      - tambourine_man 3y ago
        Being first rarely matters. Good execution at the right time is the crucial part.
        mtsr 3y ago
        And maybe not being the start of another MS embrace-extend-extinguish ploy.
      - refulgentis 3y ago
        People know VMs existed before WASM
  - saila 3y ago
    I was just looking at the status of IronPython, and it's on Python 3.4, which has been end-of-life for nearly five years. I'm not sure that indicates practical usability for most developers. Only C#, VB, and maybe F# actually seem like a safe choice on .NET. (PowerShell too, but that's a different use case.) So, just because something has been, or can be, done "in theory" doesn't mean all that much. Unless you were intending this as a criticism of .NET? I could see WASM actually pulling this off.
    - ejiblabahaba 3y ago
      IronPython is indeed quite a pain to work with, and for a lot of reasons beyond the age. For instance, you don't get numpy or any dependencies that themselves depend on quirks of CPython. The alternative is PythonNET, which executes python in CPython context, but provides nearly the same interoperability* with CLR assemblies. There's many devils in the details of that asterisk, and I'm frankly not knowledgeable enough to explain them; but in my experience, things work well enough that I'm satisfied with the integration provided.
- kaba0 3y ago
  GraalVM can run WASM executables: https://www.graalvm.org/latest/reference-manual/wasm/ https://www.graalvm.org/latest/reference-manual/wasm/
- chriswarbo 3y ago
  > Now I'm excited for WASM Threads for true parallelism Pedantic: threads are concurrent, not necessarily parallel. It's weird to see them called "true parallelism". I assume you mean in comparison to coroutines, but those are sequential (their execution order may be arbitrary, but we can rely on them not being concurrent). If wasm adopts threads that would be another unfortunate WorseIsBetter situation, given that threads are probably the worst model of concurrency we've ever devised (other than concurrent COMEFROM)!
  - titzer 3y ago
    > If wasm adopts threads that would be another unfortunate WorseIsBetter situation, given that threads are probably the worst model of concurrency we've ever devised (other than concurrent COMEFROM)! Like it or not, threads are here to stay. Threads with shared mutable memory are the abstraction that multi-processor systems give software. They are not a software invention (anymore, as they might have been considered in the uniprocessor era). A key goal of Wasm is to be a portable (and safe!) abstraction over hardware. Thus exposing extremely pervasive hardware abstractions like threads is well within its mission. Doing so safely has meant careful design and specification that captures what hardware gives for memory models without forcing a new programming model or undue burden on languages, toolchains, or runtimes. Given that there are literally billions of lines of software that use threads, hardware actually implements threads, and the entire stack is driven to optimize threads, it would indeed be a bold move to impose a different abstraction at the Wasm level. An abstraction that would incidentally be immediately used to emulate threads. That's a real layering screwup--abstraction inversion. Also, I think your pedantry is unwarranted and a distraction. Many people accept the claim that threads are "true parallelism" and would consider cooperative (or even green) threading systems to be "not what we meant when we said threads". It's just a red herring to go off and discuss technicalities when the context is clearly Wasm exposing hardware threads.
    - Kinrany 3y ago
      > An abstraction that would incidentally be immediately used to emulate threads. That would be a win if performance was the same!
- kodablah 3y ago
  > I was curious if there was a WASM to JVM and it seems there is one on GitHub [...] https://github.com/cretz/asmble https://github.com/cretz/asmble While it works well, this was mostly a fun project for me and I no longer really maintain it. I hope that the ideas and explanations of how I mapped WASM IR to JVM bytecodes helps whoever does build this in a more official capacity. I don't have any plans to support WASM GC currently.
- apatheticonion 3y ago
  > Now I'm excited for WASM Threads for true parallelism Same, I'm very interested in using threads in the browser but sadly thus far threading in wasm on the browser requires the server providing an extremely restrictive response header making threads impractical for most applications.
- dsign 3y ago
  > I haven't used it I was just curious because the JVM is a mature (and parallel) garbage collector. Slightly pedantic, but the JVM is a bit more than its arbage collectors[^1]. But it is true that the JVM has been the experimentation bed of garbage collection, not because academics have been specially daring with the JVM, but because JVM programs have been used extensively, and often so in ways that strain any single GC technique. [^1]: https://www.baeldung.com/jvm-garbage-collectors https://www.baeldung.com/jvm-garbage-collectors. The Azul JVM also has its own, different one. And those are the ones I know of; I'm pretty sure I'm leaving quite a few out.
colordrops 3y ago
I was under the impression that direct interaction with the DOM from WASM was predicated on GC support. Does this mean that something like python could now directly access the DOM without javascript?
- Skinney 3y ago
  I don't think WASM has API's for accessing the DOM, so you'll still need a little bit of glue code. The GC support allows you to safely pass GC objects around without them dissapearing (being collected) on you.
  - singularity2001 3y ago
    "a little bit" of glue code
- flohofwoe 3y ago
  AFAIK GC is (mostly) irrelevant for "direct DOM access", you would rather want to hop into the following rabbit hole: - reference types: https://github.com/WebAssembly/reference-types/blob/master/proposals/reference-types/Overview.md https://github.com/WebAssembly/reference-types/blob/master/p... - interface types (inactive): https://github.com/WebAssembly/interface-types/blob/main/proposals/interface-types/Explainer.md https://github.com/WebAssembly/interface-types/blob/main/pro... - component model: https://github.com/WebAssembly/component-model https://github.com/WebAssembly/component-model If this looks like a hot mess, that's because it is. Compared to that, the current solution to go through a Javascript shim doesn't look too bad IMHO.
  - johncolanduoni 3y ago
    Yeah I think the component model is biting off way too much in one proposal. All the future WASI developments are gated on it too now so we won’t see any improvements there either until this all-singing, all-dancing universal interop is shipped.
- WorldMaker 3y ago
ChrisRackauckas 3y ago
The Julia WASM tools can make apps which support (/require) this feature. For example, you can compile the ODE solver to WASM as is demonstrated on https://tshort.github.io/WebAssemblyCompiler.jl/stable/examples/lorenz/ https://tshort.github.io/WebAssemblyCompiler.jl/stable/examp.... It requires Chrome v119 in order to work out of the box due to that being the first version to enable the GC support. The front page of the WASM compiler https://tshort.github.io/WebAssemblyCompiler.jl/stable/ https://tshort.github.io/WebAssemblyCompiler.jl/stable/ has more details.
- andyferris 3y ago
  Oh wow that’s great progress! (Hopefully the new `Memory{T}` type makes it possible to compile even more code.)
  - adgjlsfhk1 3y ago
    I don't think the new Memory will change anything here. Why would it? Edit: I guess it will make allocation hoisting slightly easier.
jillesvangurp 3y ago
The new wasm support in Kotlin is pretty exciting. There's an experimental version of compose multiplatform that supports targeting browsers that will be using WASM. Compose multiplatform is basically Google's Jetpack Compose for Android with added support for other platforms. As of a few days ago, IOS support in alpha and will hit beta next year. Android and desktop support are now stable. Once that stuff stabilizes, you can write UI applications that basically work on any platform. The wasm compiler will roll out along with kotlin 2.0 which is the next major release for Kotlin and features a new compiler (k2). This looks like it should happen early next year. k2 is currently available in beta release and you can enable it in kotlin 1.9.x. The nice thing with the Kotlin multiplatform ecosystem is that there are already a lot of libraries that work across the various platforms. So, the wasm compiler will rapidly become part of that and inherit a lot of nice libraries. Mostly all that takes is for builds to be reconfigured to target that ecosystem and implementing some platform specific behavior where that is missing. Another interesting thing in this space is using and linking libraries written in different libraries. For example a lot of the platform specifics are probably going to be dependent on e.g. C or Rust libraries that are already available. In many cases these might be the same libraries that Kotlin native uses.
- leononame 3y ago
  How does Compose Multiplatform on web work? Does it paint on Canvas like flutter? Do you use the same widgets on Desktop, web, iOS and Android? I understand that on Android it's native. Does it emulate other styles on other platform? I guess, my question is mostly: How is the _feel_ of a Compose Multiplatform App on non-Android platforms. Dart on web e.g. feels extremely janky to me, so does electron on Desktop. Dart on Desktop is ok, but all the applications tend to be very App-like with huge buttons and whitespace that just make it feel more like it was an Android App running in an emulator rather than an actual native app. Would you recommend Kotlin as a language for new projects?
  - jillesvangurp 3y ago
    Compose web indeed uses a canvas and just like the Android and IOS versions it renders using low level graphics libraries such as cairo. I think the intention is indeed to have the same core components across all platforms and indeed emulate the look of the native platform. This is similar to what things like flutter do, which also depends on cairo if I'm not mistaken. There is also compose web html which seems to be not getting a lot of attention lately. That depends on kotlin-js and works with the dom tree. But for obvious reasons it's a lot less easy to use the same components there. I think it's too early to tell how it will perform, look, and feel on every platform. This is also a bit of a function of how much effort and design you put in. Using wasm in the browser should help with performance though. Dart might copy that trick as well. I think they currently cross compile to javascript. Kotlin as a language is more than fine. Anything server related or Android related, it's a great language and I vastly prefer it to Java at this point (27 years of experience). I personally use it for web development (kotlin-js in the browser) and server development (spring-boot, ktor). IOS native development for libraries is also a popular option for sharing code across IOS and Android. That just got promoted to a stable release. There are some gotchas with interoperability with e.g. Swift and Flutter from what I understand. But it's basically very stable and workable at this point and fairly widely used. Compose multiplatform is not quite ready yet. The Android and Desktop side work fine and are stable. But the rest is a work in progress. Compose web is going to be a while because even the compiler isn't ready yet. Compose IOS looks like it should get to a usable stage in the next six months or so. Stable is probably at least a year out for that.
craftamap 3y ago
Can somebody explain to me why this blog post (and the chrome announcement blog post) does not mention go? This gives me the impression that go can't benefit from these changes, even though it's garbage collected.
- 4ad 3y ago
  WasmGC does not support interior pointers so Go cannot benefit from this, at least not without something ugly like fat pointers.
  - aatd86 3y ago
    How does it not support interior pointers? Can you explain some more? Seemed to me that it did? Example given in the link. https://gist.github.com/kripken/5cd3e18b6de41c559d590e44252eafff https://gist.github.com/kripken/5cd3e18b6de41c559d590e44252e... Or is it that the GC ignores interior pointers during mark and sweep? Then once Java introduces value types, wouldn't the language encounter the same problem for composite types? Would be a weird choice to not handle interior pointers. I'm a bit out-of-my-depth here, just wondering.
    - skybrian 3y ago
      That’s not an example of interior pointers as used in Go. In Go you can have a fixed-size array of structs, where each struct contains many fields, including a fixed-size array field. The whole thing can be allocated at once and is automatically zeroed out. And then you can take a pointer to any struct’s field or any internal array element. “Interior” means the interior of a single object. A pointer to anywhere within an object prevents it from being collected.
      - kaba0 3y ago
        Can’t it be compiled as a struct of a normal pointer and an “index” to a field/offset whatever? Not the most efficient, but with value types it might not be too bad.
iamnotsure 3y ago
Garbage collection - because real time and batch processing don't mix.
- pjmlp 3y ago
  They certainly do, when one has the right flavour of GC. https://www.ptc.com/en/products/developer-tools/perc https://www.ptc.com/en/products/developer-tools/perc https://www.aicas.com/wp/products-services/jamaicavm/ https://www.aicas.com/wp/products-services/jamaicavm/ https://www.microej.com/ https://www.microej.com/
ngrilly 3y ago
I'm a bit skeptical about this. This is significantly increasing WebAssembly's complexity. Garbage collectors are a leaky abstraction: Some support interior pointers, others don't. Some support parallel tasks sharing memory, others don't. Some require compaction, making C FFI more difficult, others don't. Some require a deep integration with whatever mechanism is used for green processes/threads and growable stacks, others don't. Etc. When looking at languages like Erlang, JavaScript, Python, or Go, the choices made at the language level are partly reflected in their garbage collectors. That idea of a universal/generic VM supporting many languages has been tried many times, with limited success, for example with the JVM, CLR, or Parrot. What makes this different?
- kaba0 3y ago
  The correct question is “what makes WASM different”, not the other way around. And, mostly nothing, besides some “elegance” from being a new thing not yet full of legacy constructs. Oh, and that the browsers (or whatever is left from the browser scene with nigh everything being blink unfortunately) agreed on this one and not the others. I personally think that GraalVM’s truffle infrastructure is much more impressive, and supporting the much wider managed language landscape may have been a better idea for wasm as well.
  - knome 3y ago
    >“what makes WASM different” As I understand it, it's just difficult to efficiently implement GC because of the stupid decision to abstract the call stack within WASM, making it painful to get at stack pointers during collection. One would think that a generic VM assembly and the ability to make pages of memory as no longer in use so the VM and then OS can recollect them would be sufficient. Rather than admitting to and fixing their mistake, they're doubling down and doing something of much greater complexity to work around it.
    - johncolanduoni 3y ago
      That “stupid decision” is pretty key to WASM sandboxing model. How do you propose to preserve call flow integrity without it?
asim 3y ago
This is giving me "wasm is the new llvm" vibes. Anyone else getting that? I understand what it's attempting to do and have seen some demonstration of that power but for the most part it is still very technically low level and using it often ends up being very cumbersome. I'm curious to know when people think it's ready for broader adoption as something you'd choose as a target over the current way of programming.
- dinosaurdynasty 3y ago
  Look at something like wasmtime, it lets you make native programs with very secure plugins that support multiple languages by default (that even works in a browser too, in the same secure by default way). LLVM (without a lot of coding anyway, wasmer has an LLVM backend) doesn't do the whole "easy secure sandbox by default" thing, which IMHO is easily the biggest differentiator of WASM.
  - jagged-chisel 3y ago
    For GP’s clarity: LLVM is a compiler. WASM is a compiler target.
    - saagarjha 3y ago
      Presumably they meant "LLVM IR" when they were talking about LLVM.
  - sanderjd 3y ago
    This is an honest question: Is this a fundamentally different approach than java extensions from the late 90s?
    - dinosaurdynasty 3y ago
      From what I remember basically every plugin attempt in those days (Java, flash, activex, etc) were all a dumpster fire when it came to security. WASM saw that and decided to make security priority number one from day one.
tasubotadas 3y ago
This is huge. Finally, we will be able to get state of the art runtime / vm for any language
torginus 3y ago
I feel like WebAssembly is becoming more and more like something like the .NET CLR - a virtual machine designed for running high-level languages, rather than a virtual CPU architecture. Continuing with this analogy, that once all the building block are in place (GC, threads etc.), it would be time for building a WebAssembly-native programming language.
- baq 3y ago
  This language is already there, it's called Javascript, for better or worse...
- dinosaurdynasty 3y ago
  AssemblyScript...
- marcosdumay 3y ago
  > rather than a virtual CPU architecture The wasm security model is a lot more complex than your CPU's. It was never a virtual CPI architecture. And because it's not a virtual CPU architecture, it need those extra complexities. Your CPU is designed for running high-level languages without any of those extra features, but wasm can't do it (well enough).
  - hajile 3y ago
    You could design a CPU to accept WASM as an input... https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
    - slaymaker1907 3y ago
      I think you could really speed up WASM a lot if CPUs supported the WASM sandbox better. For example, it would be nice to have modern segmented memory support where you could set an offset and max address such that all other pointer operations worked off that mini-TLB, generating an interrupt if the bounds are bypassed.
Alifatisk 3y ago
No matter how amazing this is and how many the possibilities this opens, I can't stop thinking over the fact that browser today are extremely complex and the curve to building your own is almost too step!
- kaba0 3y ago
  > curve to building your own is almost too step! It’s not too steep, it is literally impossible. A whole OS is a much easier deal than a browser.
  - rileyphone 3y ago
    Definitely not "literally impossible", just a great deal of work. https://github.com/SerenityOS/serenity/tree/master/Ladybird https://github.com/SerenityOS/serenity/tree/master/Ladybird
    - IshKebab 3y ago
      You're talking about different things. You're talking about a browser that can work with some web pages. Not too hard! He's talking about a browser that works with all the web pages. That's virtually impossible. Even Microsoft gave up. Mozilla are just about hanging in the fight but I would not at all be surprised if they fail at some point. Browsers that only work with some pages are interesting to nerds, but normal people will use Chrome because it's still a great browser and it always works.
- chii 3y ago
  > extremely complex and the curve to building your own is almost too ste[e]p a lot of modern things have reach this point. You cannot possibly build your own car. You cannot possibly build your own house from scratch (too much of it require specialist knowledge, like building code etc).
- jauntywundrkind 3y ago
  Building your own Linux is impossible too, but no one bitches & moans about that. No one slams Android for saying they couldn't go make their own easily. Why would the world's most successful & available hypermedia platform need to be something one can easily implement? Of course the most successful online system in the world is complex & featureful. That's why we use it & it has won.
wg0 3y ago
Someone who's well versed can calrify that because Go is a language with garbage collection so does it mean it is not as suitable for targeting web assembly?
- johncolanduoni 3y ago
  Go exposes interior pointers to user code, so it will have some extra difficulty fitting into WASM GC’s current limitations. Similarly some of .NET’s recent GC features will probably clash with this interface. Honestly I think only languages with very simple GC semantics (e.g. JVM languages, scripting languages) will get much mileage out of it as currently specified.
  - azakai 3y ago
    For now I think that's true. But there are plans to add features like interior pointers to WasmGC, that could allow a lot more eventually: https://github.com/WebAssembly/gc/blob/main/proposals/gc/Post-MVP.md https://github.com/WebAssembly/gc/blob/main/proposals/gc/Pos...
- jerf 3y ago
  I would characterize it more as Go is not a great language for WASM because of its relatively heavyweight runtime and a simple compiler that isn't focused on making small binaries (AIUI, no "tree shaking" whatsoever, once a module comes in you get 100% of it unconditionally) makes fairly large WASM binaries. The runtime model mostly works in WASM today but it has a few roughish edges that can get you in trouble (though similar rough edges are in many languages at the moment). If Go could depend on WASM having a GC, and if Go doesn't have some sort of critical semantic mismatch with what WASM implements... and it is shocking how small the mismatch has to be before it becomes a critical problem sometimes... then the Go WASM binaries could get smaller by not needing to ship a full GC. However, it's still going to be pretty large even so. It's probably a critical feature for Go to be able to go WASM and in the long term be able to use WASM-based code, because it's often important for it to at least be an option. But I seriously doubt any WASM-first project in the next several years is ever going to pick Go as its base. You start with an awful lot of compromises right off the bat. If WASM succeeds, it will slowly but surely start to escape the browser. When you're not in a browser anymore, and you have something like a WASM executable in hand that you want to run in some WASM environment for some reason, the tradeoffs get less bad, for much the same reason it is usually not that big a deal that Go executables can be a bit on the large side right now. But this is still years off. WASM's immediate future is in the browser, where the extra large runtime and build sizes is not necessarily a fatal objection, but a fairly significant cost right up front compared to a lot of alternatives.
nindalf 3y ago
> Code in [C, C++ and Rust] that does any sort of interesting allocation will end up bundling malloc/free to manage linear memory, which requires several kilobytes of code. For example, dlmalloc requires 6K, and even a malloc that trades off speed for size, like emmalloc, takes over 1K. WasmGC, on the other hand, has the VM automatically manage memory for us so we need no memory management code at all—neither a GC nor malloc/free—in the Wasm. In the previously-mentioned article on WasmGC, the size of the fannkuch benchmark was measured and WasmGC was much smaller than C or Rust—2.3 K vs 6.1-9.6 K—for this exact reason. Would it make sense for the runtime to expose an inbuilt alloc library that C/C++/Rust can use? Programs could opt in to that library instead of bundling their own allocation library.
- jagged-chisel 3y ago
  This sounds like the smart way to go. Add alloc and friends as runtime functions that traditional code can call, and that any GC can build on those.
- aseipp 3y ago
  From a pragmatic viewpoint of saving some space, it might make sense. But from a design viewpoint it's not really a "minimal necessary feature" to do something you can't do already, so specifying it as part of the standard just bloats things up for no reason. What I mean by that is, the Wasm GC primitives were designed the way they are to be the smallest possible additions for the best uplift. When other primitives are added like SIMD, it's because they're the "roughly minimum primitives" to achieve those features. You want the smallest possible building blocks, there. But a memory allocator API for malloc/free or whatever is not a minimal feature. A memory allocator is actually a bunch of policy and design decisions, and the algorithms used by the allocator will flow from those. The fundamental building block there is just "a linear piece of memory owned by the allocator", and that already exists. It's the linear memory WASM has had since day 1! It might make sense for individual runtimes to do it though, i.e. give some built-in wasm import a piece of the linear memory and let a runtime-implemented allocator handle it. But it would almost certainly never become standardized I bet, and almost all of the tooling for non-GC'd Wasm languages is basically designed around porting working, existing codebases, including their allocators. So it's just more code to maintain for one-off implementations. The juice might not be worth the squeeze.
bullen 3y ago
So now they are recreating the Java Applet? I mean you could just re-enable the Java Applet and everything would be solved.
- zamadatix 3y ago
  To the end developer it probably seems so but to the browser it's very different. Java Applets were things plumbed through the browser whereas WASM was designed as an expansion of the existing browser engines. What they enable one to do may seem very similar but WASM does it in a way that is significantly better (security, execution, maintenance, integration) for the browsing world.
hexo 3y ago
I really do prefer open stuff so I have zero plans on turning wasm on in my browser. How does open web benefit from wasm, pretty please? Because open web is top priority, not enabling astonishingly complicated, compiled and locked down "apps". Did I miss something?
- hobofan 3y ago
  I don't think you are missing anything, it's just that most people care more about easily building things than "openness". Do you also not run javascript code of websites that has been run through a transpiler with tree-shaking and minification? Because WASM is about as locked down as that.
- ben-schaaf 3y ago
  How is wasm less open than minimised JavaScript? It's effectively just a binary format for asm.js.
- LanternLight83 3y ago
  Maybe you mean "openess" in an "in-browser inspectable" sense, ie. "open web" as in "Gopher & Gemini", but if you mean "open" as in "open-source" then there actually some folks doing really interesting things in this space: https://spritely.institute/news/hoot-wireworld-live-in-browser.html https://spritely.institute/news/hoot-wireworld-live-in-brows...
- starlevel003 3y ago
  You're not missing anything. WASM's primary purpose is to push unblockable, canvas-drawn ads.
- jadbox 3y ago
  I'm less interested in WASM in-browser than I am for WASM-powered services in edge computing (Cloudflare workers, Wasmer Edge, etc). Without WASM, you're always going to suffer cold start issues due to containers or other runtime initialization costs. This is likely the reason why Cloudflare Workers are so much cheaper than Lambda, however it's limited to workers/wasm.
miohtama 3y ago
When Safari?
TheDesolate0 3y ago
No.
bob1029 3y ago
I am not a fan of web assembly as a general target for web apps. I think something like this makes sense for low-level performance-critical libraries, but not much beyond. I've been using Blazor for some time now (server-side mode), and I feel like even this part without WASM is overkill complexity for 99% of the target audience. Adding the client-side WASM piece just kicks it into another dimension of "hard to reason with".
Vt71fcAqt7 3y ago
Can someone explain if this could make a potential statically-typed javascript easier to standardize? >WasmGC allows you to define struct and array types and perform operations such as create instances of them, read from and write to fields, cast between types, etc. Would it make sense to define javascript types within this existing wasm standard? I imagine V8 is basically already doing this as wasmGC is just exposing the existing js GC, right? (Not sure aboout other browsers.) Even if we don't get static types in browsers it would be great if they could be defined so that an outside implementation could make use of it.
avodonosov 3y ago
Or transpile to javascript instead of wasm, and thus piggiyback on its GC and other features?
- Dudester230602 3y ago
  Let's not build our potential future on a foundation of a crappy language designed over a week.
  - avodonosov 3y ago
    Js has evolved since the initial version, which also absorbed the knowledde from other existing languages. But my main point is the years and years of excellent engeneering in js implementation. Languages compiling to js can utilize its gc as well as many optimizatoins js engines such as v8 provide. For example, if your language allows to dinamically create key-val objects, the language could automatically benefit from hidden classes v8 creates. Implementing the same in wasm would be much more difficult.
TheBigSalad 3y ago
Man this is taking a while. I really didn't think I'd still be writing JavaScript in 2023.
- nu11ptr 3y ago
  To be fair, if it takes this long to get it right, than I agree with the slow pace. Look at applets. We don't want that security nightmare again, so I imagine a very slow pace is necessitated.
  - kaba0 3y ago
    They were only insecure due to being actually useful. A sandbox is not inherently secure/insecure.
torginus 3y ago
I have to ask, is this GC single threaded? (Javascript's GC is, afaik)
DylanSp 3y ago
I'm impressed that this finally got built and released; I've been hearing about WASM planning to include GC for several years now, I wasn't sure if it'd ever actually happen. I'm curious how much this will help some of the WASM-targeting languages that have issues with large binaries from building their runtime. IIRC, Blazor requires something like 1 MB just for a hello world; I wonder if WasmGC will help with that.
- to11mtm 3y ago
  It may take some time for WasmGC to be usable by .NET. Based on the discussions the first version of WasmGC does not have a good way to handle a few .NET specific scenarios, and said scenarios are "post-post-mvp". [0] My concern, of course, is that there is not much incentive for those features to be added if .NET is the only platform that needs them... at that point having a form of 'include' (to where a specific GC version can just be cached and loaded by another WASM assembly) would be more useful, despite the pain it would create. [0] - https://github.com/WebAssembly/gc/issues/77 https://github.com/WebAssembly/gc/issues/77
  - DylanSp 3y ago
    Interesting, thanks for the background. Reading through that GitHub issue helps me understand what other comments on here are talking about with the differences between various GCs making it difficult to have a one-size-fits-all WasmGC.
- AlexErrant 3y ago
  > Chrome's Wasm team has compiled versions of the Fannkuch benchmark (which allocates data structures as it works) from C, Rust, and Java. The C and Rust binaries could be anywhere from 6.1 K to 9.6 K depending on the various compiler flags, while the Java version is much smaller at only 2.3 K! C and Rust do not include a garbage collector, but they do still bundle malloc/free to manage memory, and the reason Java is smaller here is because it doesn't need to bundle any memory management code at all. https://developer.chrome.com/blog/wasmgc/ https://developer.chrome.com/blog/wasmgc/ For Blazor, it'll only help with the GC - IIRC Blazor has to ship the entire dotnet runtime.
aidenn0 3y ago
> Wasm is a low-level compiler target and so it is not surprising that the traditional porting approach can be used Stack machines often cannot be targeted the same way as register machines; in addition, the fact that the call-stack doesn't share address space with the heap causes challenges.
mattgreenrocks 3y ago
I love reading about this stuff, is there something I can do to help? Have a few years of professional compiler/VM experience, always looking for new challenges.
- snthpy 3y ago
  Hi, This is off-topic, but we're always looking for compiler people at PRQL (https://prql-lang.org/ https://prql-lang.org/) to help us build a query language for the next 50 years. Come and take a look if that's something that floats your boat: https://github.com/prql/prql https://github.com/prql/prql
- azakai 3y ago
  The Binaryen wasm optimizer (mentioned in the article) is always open for contributions! https://github.com/WebAssembly/binaryen https://github.com/WebAssembly/binaryen
deleted 3y ago
[deleted]
politician 3y ago
I wish we could just exchange write-only or readonly byte buffers between WASM guests and their hosts using a sane stable API. Sadly, I no longer trust the standards folks to get something like structured data exchange (interfaces, components) to ever work correctly.
amelius 3y ago
Is this a concurrent GC? Or is it basically the GC that is inside V8 which (I assume) collects only the garbage of a single thread?
- timfsu 3y ago
  V8 has had concurrent GC for a while - https://v8.dev/blog/concurrent-marking https://v8.dev/blog/concurrent-marking
  - amelius 3y ago
    Ok, perhaps I'm using the wrong terminology, but what I meant is that the GC can collect garbage from multiple threads at the same time, while the GC itself also runs in a different thread (or multiple). Without this, you can't really run languages like Go or C# inside the VM.
dannyobrien 3y ago
For an example of a platform that uses this feature, Spritely's Guile-on-Wasm project, Hoot, is now runnable in Chrome and Firefox. See https://davexunit.itch.io/strigoform https://davexunit.itch.io/strigoform for an example.
admax88qqq 3y ago
Finally I can run JavaScript in the browser!
apatheticonion 3y ago
I'm hopeful there is a future where the browser can use a wasm binary as an entry point for a website (rather than an html file). This implies access to the DOM and other web platform APIs. Obviously this is terrible for document websites that need to be SEO optimised, however it would be great for dynamic web applications (think banking apps or Jira). In those cases, the HTML file is just an unnecessary extra request and can actually contribute to slightly slower start up times. Perhaps simply allowing html files to be sent in some kind of binary format where a wasm binary is inlined would be a more practical approach - as the html file does act as a kind of app manifest.
TeaVMFan 3y ago
A number of concerns with the viability of the current WASM GC are covered here (Google translation to English): https://habr-com.translate.goog/ru/articles/757182/?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en&_x_tr_pto=wapp&_x_tr_hist=true https://habr-com.translate.goog/ru/articles/757182/?_x_tr_sl... and the original article: https://habr.com/ru/articles/757182/ https://habr.com/ru/articles/757182/ This is from the author of TeaVM, who has 10 years of experience getting Java and JVM code to run efficiently in the browser. https://teavm.org/ https://teavm.org/ TeaVM's existing transpilation of Java to JavaScript performs well (using the browsers JS GC). It will be interesting to see if WASM GC matures to the point where it is even faster.
- azakai 3y ago
  Interesting article, thanks! Notes on the issues mentioned there: * The need for a manual shadow stack: This is fixed in WasmGC (in the same way it works in JS, as the link mentions). * Lack of try-catch: This is fixed by the Wasm exception handling proposal, which has already shipped in browsers, https://github.com/WebAssembly/exception-handling/blob/main/proposals/exception-handling/Exceptions.md https://github.com/WebAssembly/exception-handling/blob/main/... * Null checks: Mostly fixed by WasmGC. The spec defines non-nullable local types, and VMs can use the techniques the article mentions to optimize them using signals (Wizard does, for example). * Class initialization: This is a difficult problem, as the article says. J2Wasm and Binaryen are working to optimize it through static analysis at the toolchain level. Here is a recent PR I wrote that makes progress there: https://github.com/WebAssembly/binaryen/pull/6061 https://github.com/WebAssembly/binaryen/pull/6061 * The vtable overhead issue the article mentions may be a problem. I'm not aware of good measurements on it, through. There are some ideas on post-MVP solutions for method dispatch that might help, but nothing concrete yet. * Checks for null and trapping: There has been discussion of variants on the GC instructions that throw instead of trap. Measurements, however, have not shown it to be a big problem atm, so it is low priority. The author is right that stack walking, signals, and memory control are important areas that could help here. Overall with WasmGC and exceptions we are in a pretty good place for Java as emitted by J2Wasm today: it is usually faster than J2CL which compiles Java to JavaScript. But there is definitely room for improvement.
LunaSea 3y ago
Ten years on and I still don't understand the point of WebAssembly. The tech is insanely complex and well done. I'm just not sure about the problem it's trying to solve.

426 points by kiyanwang 3y ago

[dead]

This is exciting. I think WASM is an example of a thin waist [1] with its garbage collector and N+M rather than N×M. (N languages + M virtual machines + G garbage collectors). That's a mature garbage collector in V8. I was curious if there was a WASM to JVM and it seems there is one on GitHub, I haven't used it I was just curious because the JVM is a mature (and parallel) garbage collector. Now I'm excited for WASM Threads for true parallelism and not just IO parallelism because I didn't think WASMGC would come out so soon. The opportunity to solve async and parallelism and garbage collection EFFECTIVELY would strengthen WASM and not be a source of confusion or difficulty for developers. I think that's why WASI is so important, a chance to define an API as stable as POSIX. 1: https://www.oilshell.org/blog/2022/02/diagrams.html https://www.oilshell.org/blog/2022/02/diagrams.html 2: https://github.com/cretz/asmble https://github.com/cretz/asmble

pjmlp 3y ago
Following CLR footsteps, 22 years later. > More than 20 programming tools vendors offer some 26 programming languages — including C++, Perl, Python, Java, COBOL, RPG and Haskell — on .NET. From https://news.microsoft.com/2001/10/22/massive-industry-and-developer-support-for-microsoft-net-on-display-at-professional-developers-conference-2001/ https://news.microsoft.com/2001/10/22/massive-industry-and-d...
- quickthrower2 3y ago
  Where is my Haskell.NET? Dammit!
  - delta_p_delta_x 3y ago
    F#: https://learn.microsoft.com/en-sg/dotnet/fsharp/what-is-fsharp https://learn.microsoft.com/en-sg/dotnet/fsharp/what-is-fsha... EDIT: Yes, F# is an ML-style language. I was answering the spirit of the question, which was 'statically-typed functional-first programming language running on the .NET CLR'.
    - masklinn 3y ago
      F# is ocaml.net not haskell.net
- debugnik 3y ago
  If only the CLR had followed CLR footsteps as well, but they didn't even try after the DLR. Most non-Roslyn languages can barely interact with modern C# or the newer build configurations; even F# is playing catch-up and they're part of the official toolchain.
  - pjmlp 3y ago
    That is the sin of guest languages, that is why C rules on UNIX, JavaScript on Web, Java on the JVM, C# on the CLR, .... Every guest language means additional IDE plugins with platform knowledge, since most communities want idiomatic libraries, an ecosystem on top of the ecosystem, as the actual platform is only implemented in a main "systems" language, mastering it is required anyway for all the leaky abstractions on the platform, additional build toolchains,... In the end, each polyglot platform achieves a global maximum of main language, and possibly a winner among all guest languages, even if it takes a couple of years with projects fading away until this happens. It sucks, however so it is the outcome of human nature attention span, and not being able to keep momentum for all languages across the whole lifetime of a given platform.
    - HappMacDonald 3y ago
      It feels to me a little bit like how geographic regions wind up working out dominant spoken/written languages. The guest languages are like relying on (human or machine) speech/writing translation services to communicate with folks who only know the local lingua franca. That added friction hobbles the minority languages. Perhaps AI will aid in greatly reducing these issues over time (and I say this because large language translation models and text to speech + speech to text are finally reaching professional human quality while running on local hardware today). But I can't think of any other good method to hold back the floodgates of people being forced to choose between their mother tongue (with its corpus of invaluable baked in stories and perspectives) and being understood by others.
    - no_wizard 3y ago
      I think Kotlin is slowly eclipsing Java on the JVM. Its not majority yet but most new projects or major refactors I've seen are either 100% Kotlin or majority Kotlin. I would not be surprised if Kotlin takes a majority share eventually
- titzer 3y ago
  I don't really know where to place this comment. Multi-language systems existed before, therefore Wasm should not, because it's already been done? It's interesting that none of the languages that you list made .NET a primary target and have all either bit-rotted unofficial ports or sunsetted their mainline support. It's hard to say whether languages that now target Wasm will suffer the same fate, since that depends on level of maintenance that each project allocates to particular targets. Still, I don't really get your point.
  - pjmlp 3y ago
    The usual amazement as if WASM was the first at anything...
    - tambourine_man 3y ago
      Being first rarely matters. Good execution at the right time is the crucial part.
      - mtsr 3y ago
        And maybe not being the start of another MS embrace-extend-extinguish ploy.
    - refulgentis 3y ago
      People know VMs existed before WASM
- saila 3y ago
  I was just looking at the status of IronPython, and it's on Python 3.4, which has been end-of-life for nearly five years. I'm not sure that indicates practical usability for most developers. Only C#, VB, and maybe F# actually seem like a safe choice on .NET. (PowerShell too, but that's a different use case.) So, just because something has been, or can be, done "in theory" doesn't mean all that much. Unless you were intending this as a criticism of .NET? I could see WASM actually pulling this off.
  - ejiblabahaba 3y ago
    IronPython is indeed quite a pain to work with, and for a lot of reasons beyond the age. For instance, you don't get numpy or any dependencies that themselves depend on quirks of CPython. The alternative is PythonNET, which executes python in CPython context, but provides nearly the same interoperability* with CLR assemblies. There's many devils in the details of that asterisk, and I'm frankly not knowledgeable enough to explain them; but in my experience, things work well enough that I'm satisfied with the integration provided.
kaba0 3y ago
GraalVM can run WASM executables: https://www.graalvm.org/latest/reference-manual/wasm/ https://www.graalvm.org/latest/reference-manual/wasm/
chriswarbo 3y ago
> Now I'm excited for WASM Threads for true parallelism Pedantic: threads are concurrent, not necessarily parallel. It's weird to see them called "true parallelism". I assume you mean in comparison to coroutines, but those are sequential (their execution order may be arbitrary, but we can rely on them not being concurrent). If wasm adopts threads that would be another unfortunate WorseIsBetter situation, given that threads are probably the worst model of concurrency we've ever devised (other than concurrent COMEFROM)!
- titzer 3y ago
  > If wasm adopts threads that would be another unfortunate WorseIsBetter situation, given that threads are probably the worst model of concurrency we've ever devised (other than concurrent COMEFROM)! Like it or not, threads are here to stay. Threads with shared mutable memory are the abstraction that multi-processor systems give software. They are not a software invention (anymore, as they might have been considered in the uniprocessor era). A key goal of Wasm is to be a portable (and safe!) abstraction over hardware. Thus exposing extremely pervasive hardware abstractions like threads is well within its mission. Doing so safely has meant careful design and specification that captures what hardware gives for memory models without forcing a new programming model or undue burden on languages, toolchains, or runtimes. Given that there are literally billions of lines of software that use threads, hardware actually implements threads, and the entire stack is driven to optimize threads, it would indeed be a bold move to impose a different abstraction at the Wasm level. An abstraction that would incidentally be immediately used to emulate threads. That's a real layering screwup--abstraction inversion. Also, I think your pedantry is unwarranted and a distraction. Many people accept the claim that threads are "true parallelism" and would consider cooperative (or even green) threading systems to be "not what we meant when we said threads". It's just a red herring to go off and discuss technicalities when the context is clearly Wasm exposing hardware threads.
  - Kinrany 3y ago
    > An abstraction that would incidentally be immediately used to emulate threads. That would be a win if performance was the same!
kodablah 3y ago
> I was curious if there was a WASM to JVM and it seems there is one on GitHub [...] https://github.com/cretz/asmble https://github.com/cretz/asmble While it works well, this was mostly a fun project for me and I no longer really maintain it. I hope that the ideas and explanations of how I mapped WASM IR to JVM bytecodes helps whoever does build this in a more official capacity. I don't have any plans to support WASM GC currently.
apatheticonion 3y ago
> Now I'm excited for WASM Threads for true parallelism Same, I'm very interested in using threads in the browser but sadly thus far threading in wasm on the browser requires the server providing an extremely restrictive response header making threads impractical for most applications.
dsign 3y ago
> I haven't used it I was just curious because the JVM is a mature (and parallel) garbage collector. Slightly pedantic, but the JVM is a bit more than its arbage collectors[^1]. But it is true that the JVM has been the experimentation bed of garbage collection, not because academics have been specially daring with the JVM, but because JVM programs have been used extensively, and often so in ways that strain any single GC technique. [^1]: https://www.baeldung.com/jvm-garbage-collectors https://www.baeldung.com/jvm-garbage-collectors. The Azul JVM also has its own, different one. And those are the ones I know of; I'm pretty sure I'm leaving quite a few out.

colordrops 3y ago

I was under the impression that direct interaction with the DOM from WASM was predicated on GC support. Does this mean that something like python could now directly access the DOM without javascript?

Skinney 3y ago
I don't think WASM has API's for accessing the DOM, so you'll still need a little bit of glue code. The GC support allows you to safely pass GC objects around without them dissapearing (being collected) on you.
- singularity2001 3y ago
  "a little bit" of glue code
flohofwoe 3y ago
AFAIK GC is (mostly) irrelevant for "direct DOM access", you would rather want to hop into the following rabbit hole: - reference types: https://github.com/WebAssembly/reference-types/blob/master/proposals/reference-types/Overview.md https://github.com/WebAssembly/reference-types/blob/master/p... - interface types (inactive): https://github.com/WebAssembly/interface-types/blob/main/proposals/interface-types/Explainer.md https://github.com/WebAssembly/interface-types/blob/main/pro... - component model: https://github.com/WebAssembly/component-model https://github.com/WebAssembly/component-model If this looks like a hot mess, that's because it is. Compared to that, the current solution to go through a Javascript shim doesn't look too bad IMHO.
- johncolanduoni 3y ago
  Yeah I think the component model is biting off way too much in one proposal. All the future WASI developments are gated on it too now so we won’t see any improvements there either until this all-singing, all-dancing universal interop is shipped.
WorldMaker 3y ago

ChrisRackauckas 3y ago

The Julia WASM tools can make apps which support (/require) this feature. For example, you can compile the ODE solver to WASM as is demonstrated on https://tshort.github.io/WebAssemblyCompiler.jl/stable/examples/lorenz/ https://tshort.github.io/WebAssemblyCompiler.jl/stable/examp.... It requires Chrome v119 in order to work out of the box due to that being the first version to enable the GC support. The front page of the WASM compiler https://tshort.github.io/WebAssemblyCompiler.jl/stable/ https://tshort.github.io/WebAssemblyCompiler.jl/stable/ has more details.

andyferris 3y ago
Oh wow that’s great progress! (Hopefully the new `Memory{T}` type makes it possible to compile even more code.)
- adgjlsfhk1 3y ago
  I don't think the new Memory will change anything here. Why would it? Edit: I guess it will make allocation hoisting slightly easier.

jillesvangurp 3y ago

The new wasm support in Kotlin is pretty exciting. There's an experimental version of compose multiplatform that supports targeting browsers that will be using WASM. Compose multiplatform is basically Google's Jetpack Compose for Android with added support for other platforms. As of a few days ago, IOS support in alpha and will hit beta next year. Android and desktop support are now stable. Once that stuff stabilizes, you can write UI applications that basically work on any platform. The wasm compiler will roll out along with kotlin 2.0 which is the next major release for Kotlin and features a new compiler (k2). This looks like it should happen early next year. k2 is currently available in beta release and you can enable it in kotlin 1.9.x. The nice thing with the Kotlin multiplatform ecosystem is that there are already a lot of libraries that work across the various platforms. So, the wasm compiler will rapidly become part of that and inherit a lot of nice libraries. Mostly all that takes is for builds to be reconfigured to target that ecosystem and implementing some platform specific behavior where that is missing. Another interesting thing in this space is using and linking libraries written in different libraries. For example a lot of the platform specifics are probably going to be dependent on e.g. C or Rust libraries that are already available. In many cases these might be the same libraries that Kotlin native uses.

leononame 3y ago
How does Compose Multiplatform on web work? Does it paint on Canvas like flutter? Do you use the same widgets on Desktop, web, iOS and Android? I understand that on Android it's native. Does it emulate other styles on other platform? I guess, my question is mostly: How is the _feel_ of a Compose Multiplatform App on non-Android platforms. Dart on web e.g. feels extremely janky to me, so does electron on Desktop. Dart on Desktop is ok, but all the applications tend to be very App-like with huge buttons and whitespace that just make it feel more like it was an Android App running in an emulator rather than an actual native app. Would you recommend Kotlin as a language for new projects?
- jillesvangurp 3y ago
  Compose web indeed uses a canvas and just like the Android and IOS versions it renders using low level graphics libraries such as cairo. I think the intention is indeed to have the same core components across all platforms and indeed emulate the look of the native platform. This is similar to what things like flutter do, which also depends on cairo if I'm not mistaken. There is also compose web html which seems to be not getting a lot of attention lately. That depends on kotlin-js and works with the dom tree. But for obvious reasons it's a lot less easy to use the same components there. I think it's too early to tell how it will perform, look, and feel on every platform. This is also a bit of a function of how much effort and design you put in. Using wasm in the browser should help with performance though. Dart might copy that trick as well. I think they currently cross compile to javascript. Kotlin as a language is more than fine. Anything server related or Android related, it's a great language and I vastly prefer it to Java at this point (27 years of experience). I personally use it for web development (kotlin-js in the browser) and server development (spring-boot, ktor). IOS native development for libraries is also a popular option for sharing code across IOS and Android. That just got promoted to a stable release. There are some gotchas with interoperability with e.g. Swift and Flutter from what I understand. But it's basically very stable and workable at this point and fairly widely used. Compose multiplatform is not quite ready yet. The Android and Desktop side work fine and are stable. But the rest is a work in progress. Compose web is going to be a while because even the compiler isn't ready yet. Compose IOS looks like it should get to a usable stage in the next six months or so. Stable is probably at least a year out for that.

craftamap 3y ago

Can somebody explain to me why this blog post (and the chrome announcement blog post) does not mention go? This gives me the impression that go can't benefit from these changes, even though it's garbage collected.

4ad 3y ago
WasmGC does not support interior pointers so Go cannot benefit from this, at least not without something ugly like fat pointers.
- aatd86 3y ago
  How does it not support interior pointers? Can you explain some more? Seemed to me that it did? Example given in the link. https://gist.github.com/kripken/5cd3e18b6de41c559d590e44252eafff https://gist.github.com/kripken/5cd3e18b6de41c559d590e44252e... Or is it that the GC ignores interior pointers during mark and sweep? Then once Java introduces value types, wouldn't the language encounter the same problem for composite types? Would be a weird choice to not handle interior pointers. I'm a bit out-of-my-depth here, just wondering.
  - skybrian 3y ago
    That’s not an example of interior pointers as used in Go. In Go you can have a fixed-size array of structs, where each struct contains many fields, including a fixed-size array field. The whole thing can be allocated at once and is automatically zeroed out. And then you can take a pointer to any struct’s field or any internal array element. “Interior” means the interior of a single object. A pointer to anywhere within an object prevents it from being collected.
    - kaba0 3y ago
      Can’t it be compiled as a struct of a normal pointer and an “index” to a field/offset whatever? Not the most efficient, but with value types it might not be too bad.

iamnotsure 3y ago

Garbage collection - because real time and batch processing don't mix.

pjmlp 3y ago
They certainly do, when one has the right flavour of GC. https://www.ptc.com/en/products/developer-tools/perc https://www.ptc.com/en/products/developer-tools/perc https://www.aicas.com/wp/products-services/jamaicavm/ https://www.aicas.com/wp/products-services/jamaicavm/ https://www.microej.com/ https://www.microej.com/

ngrilly 3y ago

I'm a bit skeptical about this. This is significantly increasing WebAssembly's complexity. Garbage collectors are a leaky abstraction: Some support interior pointers, others don't. Some support parallel tasks sharing memory, others don't. Some require compaction, making C FFI more difficult, others don't. Some require a deep integration with whatever mechanism is used for green processes/threads and growable stacks, others don't. Etc. When looking at languages like Erlang, JavaScript, Python, or Go, the choices made at the language level are partly reflected in their garbage collectors. That idea of a universal/generic VM supporting many languages has been tried many times, with limited success, for example with the JVM, CLR, or Parrot. What makes this different?

kaba0 3y ago
The correct question is “what makes WASM different”, not the other way around. And, mostly nothing, besides some “elegance” from being a new thing not yet full of legacy constructs. Oh, and that the browsers (or whatever is left from the browser scene with nigh everything being blink unfortunately) agreed on this one and not the others. I personally think that GraalVM’s truffle infrastructure is much more impressive, and supporting the much wider managed language landscape may have been a better idea for wasm as well.
- knome 3y ago
  >“what makes WASM different” As I understand it, it's just difficult to efficiently implement GC because of the stupid decision to abstract the call stack within WASM, making it painful to get at stack pointers during collection. One would think that a generic VM assembly and the ability to make pages of memory as no longer in use so the VM and then OS can recollect them would be sufficient. Rather than admitting to and fixing their mistake, they're doubling down and doing something of much greater complexity to work around it.
  - johncolanduoni 3y ago
    That “stupid decision” is pretty key to WASM sandboxing model. How do you propose to preserve call flow integrity without it?

asim 3y ago

This is giving me "wasm is the new llvm" vibes. Anyone else getting that? I understand what it's attempting to do and have seen some demonstration of that power but for the most part it is still very technically low level and using it often ends up being very cumbersome. I'm curious to know when people think it's ready for broader adoption as something you'd choose as a target over the current way of programming.

dinosaurdynasty 3y ago
Look at something like wasmtime, it lets you make native programs with very secure plugins that support multiple languages by default (that even works in a browser too, in the same secure by default way). LLVM (without a lot of coding anyway, wasmer has an LLVM backend) doesn't do the whole "easy secure sandbox by default" thing, which IMHO is easily the biggest differentiator of WASM.
- jagged-chisel 3y ago
  For GP’s clarity: LLVM is a compiler. WASM is a compiler target.
  - saagarjha 3y ago
    Presumably they meant "LLVM IR" when they were talking about LLVM.
- sanderjd 3y ago
  This is an honest question: Is this a fundamentally different approach than java extensions from the late 90s?
  - dinosaurdynasty 3y ago
    From what I remember basically every plugin attempt in those days (Java, flash, activex, etc) were all a dumpster fire when it came to security. WASM saw that and decided to make security priority number one from day one.

tasubotadas 3y ago

This is huge. Finally, we will be able to get state of the art runtime / vm for any language

torginus 3y ago

I feel like WebAssembly is becoming more and more like something like the .NET CLR - a virtual machine designed for running high-level languages, rather than a virtual CPU architecture. Continuing with this analogy, that once all the building block are in place (GC, threads etc.), it would be time for building a WebAssembly-native programming language.

baq 3y ago
This language is already there, it's called Javascript, for better or worse...
dinosaurdynasty 3y ago
AssemblyScript...
marcosdumay 3y ago
> rather than a virtual CPU architecture The wasm security model is a lot more complex than your CPU's. It was never a virtual CPI architecture. And because it's not a virtual CPU architecture, it need those extra complexities. Your CPU is designed for running high-level languages without any of those extra features, but wasm can't do it (well enough).
- hajile 3y ago
  You could design a CPU to accept WASM as an input... https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
  - slaymaker1907 3y ago
    I think you could really speed up WASM a lot if CPUs supported the WASM sandbox better. For example, it would be nice to have modern segmented memory support where you could set an offset and max address such that all other pointer operations worked off that mini-TLB, generating an interrupt if the bounds are bypassed.

Alifatisk 3y ago

No matter how amazing this is and how many the possibilities this opens, I can't stop thinking over the fact that browser today are extremely complex and the curve to building your own is almost too step!

kaba0 3y ago
> curve to building your own is almost too step! It’s not too steep, it is literally impossible. A whole OS is a much easier deal than a browser.
- rileyphone 3y ago
  Definitely not "literally impossible", just a great deal of work. https://github.com/SerenityOS/serenity/tree/master/Ladybird https://github.com/SerenityOS/serenity/tree/master/Ladybird
  - IshKebab 3y ago
    You're talking about different things. You're talking about a browser that can work with some web pages. Not too hard! He's talking about a browser that works with all the web pages. That's virtually impossible. Even Microsoft gave up. Mozilla are just about hanging in the fight but I would not at all be surprised if they fail at some point. Browsers that only work with some pages are interesting to nerds, but normal people will use Chrome because it's still a great browser and it always works.
chii 3y ago
> extremely complex and the curve to building your own is almost too ste[e]p a lot of modern things have reach this point. You cannot possibly build your own car. You cannot possibly build your own house from scratch (too much of it require specialist knowledge, like building code etc).
jauntywundrkind 3y ago
Building your own Linux is impossible too, but no one bitches & moans about that. No one slams Android for saying they couldn't go make their own easily. Why would the world's most successful & available hypermedia platform need to be something one can easily implement? Of course the most successful online system in the world is complex & featureful. That's why we use it & it has won.

wg0 3y ago

Someone who's well versed can calrify that because Go is a language with garbage collection so does it mean it is not as suitable for targeting web assembly?

johncolanduoni 3y ago
Go exposes interior pointers to user code, so it will have some extra difficulty fitting into WASM GC’s current limitations. Similarly some of .NET’s recent GC features will probably clash with this interface. Honestly I think only languages with very simple GC semantics (e.g. JVM languages, scripting languages) will get much mileage out of it as currently specified.
- azakai 3y ago
  For now I think that's true. But there are plans to add features like interior pointers to WasmGC, that could allow a lot more eventually: https://github.com/WebAssembly/gc/blob/main/proposals/gc/Post-MVP.md https://github.com/WebAssembly/gc/blob/main/proposals/gc/Pos...
jerf 3y ago
I would characterize it more as Go is not a great language for WASM because of its relatively heavyweight runtime and a simple compiler that isn't focused on making small binaries (AIUI, no "tree shaking" whatsoever, once a module comes in you get 100% of it unconditionally) makes fairly large WASM binaries. The runtime model mostly works in WASM today but it has a few roughish edges that can get you in trouble (though similar rough edges are in many languages at the moment). If Go could depend on WASM having a GC, and if Go doesn't have some sort of critical semantic mismatch with what WASM implements... and it is shocking how small the mismatch has to be before it becomes a critical problem sometimes... then the Go WASM binaries could get smaller by not needing to ship a full GC. However, it's still going to be pretty large even so. It's probably a critical feature for Go to be able to go WASM and in the long term be able to use WASM-based code, because it's often important for it to at least be an option. But I seriously doubt any WASM-first project in the next several years is ever going to pick Go as its base. You start with an awful lot of compromises right off the bat. If WASM succeeds, it will slowly but surely start to escape the browser. When you're not in a browser anymore, and you have something like a WASM executable in hand that you want to run in some WASM environment for some reason, the tradeoffs get less bad, for much the same reason it is usually not that big a deal that Go executables can be a bit on the large side right now. But this is still years off. WASM's immediate future is in the browser, where the extra large runtime and build sizes is not necessarily a fatal objection, but a fairly significant cost right up front compared to a lot of alternatives.

nindalf 3y ago

> Code in [C, C++ and Rust] that does any sort of interesting allocation will end up bundling malloc/free to manage linear memory, which requires several kilobytes of code. For example, dlmalloc requires 6K, and even a malloc that trades off speed for size, like emmalloc, takes over 1K. WasmGC, on the other hand, has the VM automatically manage memory for us so we need no memory management code at all—neither a GC nor malloc/free—in the Wasm. In the previously-mentioned article on WasmGC, the size of the fannkuch benchmark was measured and WasmGC was much smaller than C or Rust—2.3 K vs 6.1-9.6 K—for this exact reason. Would it make sense for the runtime to expose an inbuilt alloc library that C/C++/Rust can use? Programs could opt in to that library instead of bundling their own allocation library.

jagged-chisel 3y ago
This sounds like the smart way to go. Add alloc and friends as runtime functions that traditional code can call, and that any GC can build on those.
aseipp 3y ago
From a pragmatic viewpoint of saving some space, it might make sense. But from a design viewpoint it's not really a "minimal necessary feature" to do something you can't do already, so specifying it as part of the standard just bloats things up for no reason. What I mean by that is, the Wasm GC primitives were designed the way they are to be the smallest possible additions for the best uplift. When other primitives are added like SIMD, it's because they're the "roughly minimum primitives" to achieve those features. You want the smallest possible building blocks, there. But a memory allocator API for malloc/free or whatever is not a minimal feature. A memory allocator is actually a bunch of policy and design decisions, and the algorithms used by the allocator will flow from those. The fundamental building block there is just "a linear piece of memory owned by the allocator", and that already exists. It's the linear memory WASM has had since day 1! It might make sense for individual runtimes to do it though, i.e. give some built-in wasm import a piece of the linear memory and let a runtime-implemented allocator handle it. But it would almost certainly never become standardized I bet, and almost all of the tooling for non-GC'd Wasm languages is basically designed around porting working, existing codebases, including their allocators. So it's just more code to maintain for one-off implementations. The juice might not be worth the squeeze.

bullen 3y ago

So now they are recreating the Java Applet? I mean you could just re-enable the Java Applet and everything would be solved.

zamadatix 3y ago
To the end developer it probably seems so but to the browser it's very different. Java Applets were things plumbed through the browser whereas WASM was designed as an expansion of the existing browser engines. What they enable one to do may seem very similar but WASM does it in a way that is significantly better (security, execution, maintenance, integration) for the browsing world.

hexo 3y ago

I really do prefer open stuff so I have zero plans on turning wasm on in my browser. How does open web benefit from wasm, pretty please? Because open web is top priority, not enabling astonishingly complicated, compiled and locked down "apps". Did I miss something?

hobofan 3y ago
I don't think you are missing anything, it's just that most people care more about easily building things than "openness". Do you also not run javascript code of websites that has been run through a transpiler with tree-shaking and minification? Because WASM is about as locked down as that.
ben-schaaf 3y ago
How is wasm less open than minimised JavaScript? It's effectively just a binary format for asm.js.
LanternLight83 3y ago
Maybe you mean "openess" in an "in-browser inspectable" sense, ie. "open web" as in "Gopher & Gemini", but if you mean "open" as in "open-source" then there actually some folks doing really interesting things in this space: https://spritely.institute/news/hoot-wireworld-live-in-browser.html https://spritely.institute/news/hoot-wireworld-live-in-brows...
starlevel003 3y ago
You're not missing anything. WASM's primary purpose is to push unblockable, canvas-drawn ads.
jadbox 3y ago
I'm less interested in WASM in-browser than I am for WASM-powered services in edge computing (Cloudflare workers, Wasmer Edge, etc). Without WASM, you're always going to suffer cold start issues due to containers or other runtime initialization costs. This is likely the reason why Cloudflare Workers are so much cheaper than Lambda, however it's limited to workers/wasm.

miohtama 3y ago

When Safari?

TheDesolate0 3y ago

No.

bob1029 3y ago

I am not a fan of web assembly as a general target for web apps. I think something like this makes sense for low-level performance-critical libraries, but not much beyond. I've been using Blazor for some time now (server-side mode), and I feel like even this part without WASM is overkill complexity for 99% of the target audience. Adding the client-side WASM piece just kicks it into another dimension of "hard to reason with".

Vt71fcAqt7 3y ago

Can someone explain if this could make a potential statically-typed javascript easier to standardize? >WasmGC allows you to define struct and array types and perform operations such as create instances of them, read from and write to fields, cast between types, etc. Would it make sense to define javascript types within this existing wasm standard? I imagine V8 is basically already doing this as wasmGC is just exposing the existing js GC, right? (Not sure aboout other browsers.) Even if we don't get static types in browsers it would be great if they could be defined so that an outside implementation could make use of it.

avodonosov 3y ago

Or transpile to javascript instead of wasm, and thus piggiyback on its GC and other features?

Dudester230602 3y ago
Let's not build our potential future on a foundation of a crappy language designed over a week.
- avodonosov 3y ago
  Js has evolved since the initial version, which also absorbed the knowledde from other existing languages. But my main point is the years and years of excellent engeneering in js implementation. Languages compiling to js can utilize its gc as well as many optimizatoins js engines such as v8 provide. For example, if your language allows to dinamically create key-val objects, the language could automatically benefit from hidden classes v8 creates. Implementing the same in wasm would be much more difficult.

TheBigSalad 3y ago

Man this is taking a while. I really didn't think I'd still be writing JavaScript in 2023.

nu11ptr 3y ago
To be fair, if it takes this long to get it right, than I agree with the slow pace. Look at applets. We don't want that security nightmare again, so I imagine a very slow pace is necessitated.
- kaba0 3y ago
  They were only insecure due to being actually useful. A sandbox is not inherently secure/insecure.

torginus 3y ago

I have to ask, is this GC single threaded? (Javascript's GC is, afaik)

DylanSp 3y ago

I'm impressed that this finally got built and released; I've been hearing about WASM planning to include GC for several years now, I wasn't sure if it'd ever actually happen. I'm curious how much this will help some of the WASM-targeting languages that have issues with large binaries from building their runtime. IIRC, Blazor requires something like 1 MB just for a hello world; I wonder if WasmGC will help with that.

to11mtm 3y ago
It may take some time for WasmGC to be usable by .NET. Based on the discussions the first version of WasmGC does not have a good way to handle a few .NET specific scenarios, and said scenarios are "post-post-mvp". [0] My concern, of course, is that there is not much incentive for those features to be added if .NET is the only platform that needs them... at that point having a form of 'include' (to where a specific GC version can just be cached and loaded by another WASM assembly) would be more useful, despite the pain it would create. [0] - https://github.com/WebAssembly/gc/issues/77 https://github.com/WebAssembly/gc/issues/77
- DylanSp 3y ago
  Interesting, thanks for the background. Reading through that GitHub issue helps me understand what other comments on here are talking about with the differences between various GCs making it difficult to have a one-size-fits-all WasmGC.
AlexErrant 3y ago
> Chrome's Wasm team has compiled versions of the Fannkuch benchmark (which allocates data structures as it works) from C, Rust, and Java. The C and Rust binaries could be anywhere from 6.1 K to 9.6 K depending on the various compiler flags, while the Java version is much smaller at only 2.3 K! C and Rust do not include a garbage collector, but they do still bundle malloc/free to manage memory, and the reason Java is smaller here is because it doesn't need to bundle any memory management code at all. https://developer.chrome.com/blog/wasmgc/ https://developer.chrome.com/blog/wasmgc/ For Blazor, it'll only help with the GC - IIRC Blazor has to ship the entire dotnet runtime.

aidenn0 3y ago

> Wasm is a low-level compiler target and so it is not surprising that the traditional porting approach can be used Stack machines often cannot be targeted the same way as register machines; in addition, the fact that the call-stack doesn't share address space with the heap causes challenges.

mattgreenrocks 3y ago

I love reading about this stuff, is there something I can do to help? Have a few years of professional compiler/VM experience, always looking for new challenges.

snthpy 3y ago
Hi, This is off-topic, but we're always looking for compiler people at PRQL (https://prql-lang.org/ https://prql-lang.org/) to help us build a query language for the next 50 years. Come and take a look if that's something that floats your boat: https://github.com/prql/prql https://github.com/prql/prql
azakai 3y ago
The Binaryen wasm optimizer (mentioned in the article) is always open for contributions! https://github.com/WebAssembly/binaryen https://github.com/WebAssembly/binaryen

deleted 3y ago

[deleted]

politician 3y ago

I wish we could just exchange write-only or readonly byte buffers between WASM guests and their hosts using a sane stable API. Sadly, I no longer trust the standards folks to get something like structured data exchange (interfaces, components) to ever work correctly.

amelius 3y ago

Is this a concurrent GC? Or is it basically the GC that is inside V8 which (I assume) collects only the garbage of a single thread?

timfsu 3y ago
V8 has had concurrent GC for a while - https://v8.dev/blog/concurrent-marking https://v8.dev/blog/concurrent-marking
- amelius 3y ago
  Ok, perhaps I'm using the wrong terminology, but what I meant is that the GC can collect garbage from multiple threads at the same time, while the GC itself also runs in a different thread (or multiple). Without this, you can't really run languages like Go or C# inside the VM.

dannyobrien 3y ago

For an example of a platform that uses this feature, Spritely's Guile-on-Wasm project, Hoot, is now runnable in Chrome and Firefox. See https://davexunit.itch.io/strigoform https://davexunit.itch.io/strigoform for an example.

admax88qqq 3y ago

Finally I can run JavaScript in the browser!

apatheticonion 3y ago

I'm hopeful there is a future where the browser can use a wasm binary as an entry point for a website (rather than an html file). This implies access to the DOM and other web platform APIs. Obviously this is terrible for document websites that need to be SEO optimised, however it would be great for dynamic web applications (think banking apps or Jira). In those cases, the HTML file is just an unnecessary extra request and can actually contribute to slightly slower start up times. Perhaps simply allowing html files to be sent in some kind of binary format where a wasm binary is inlined would be a more practical approach - as the html file does act as a kind of app manifest.

TeaVMFan 3y ago

A number of concerns with the viability of the current WASM GC are covered here (Google translation to English): https://habr-com.translate.goog/ru/articles/757182/?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en&_x_tr_pto=wapp&_x_tr_hist=true https://habr-com.translate.goog/ru/articles/757182/?_x_tr_sl... and the original article: https://habr.com/ru/articles/757182/ https://habr.com/ru/articles/757182/ This is from the author of TeaVM, who has 10 years of experience getting Java and JVM code to run efficiently in the browser. https://teavm.org/ https://teavm.org/ TeaVM's existing transpilation of Java to JavaScript performs well (using the browsers JS GC). It will be interesting to see if WASM GC matures to the point where it is even faster.

azakai 3y ago
Interesting article, thanks! Notes on the issues mentioned there: * The need for a manual shadow stack: This is fixed in WasmGC (in the same way it works in JS, as the link mentions). * Lack of try-catch: This is fixed by the Wasm exception handling proposal, which has already shipped in browsers, https://github.com/WebAssembly/exception-handling/blob/main/proposals/exception-handling/Exceptions.md https://github.com/WebAssembly/exception-handling/blob/main/... * Null checks: Mostly fixed by WasmGC. The spec defines non-nullable local types, and VMs can use the techniques the article mentions to optimize them using signals (Wizard does, for example). * Class initialization: This is a difficult problem, as the article says. J2Wasm and Binaryen are working to optimize it through static analysis at the toolchain level. Here is a recent PR I wrote that makes progress there: https://github.com/WebAssembly/binaryen/pull/6061 https://github.com/WebAssembly/binaryen/pull/6061 * The vtable overhead issue the article mentions may be a problem. I'm not aware of good measurements on it, through. There are some ideas on post-MVP solutions for method dispatch that might help, but nothing concrete yet. * Checks for null and trapping: There has been discussion of variants on the GC instructions that throw instead of trap. Measurements, however, have not shown it to be a big problem atm, so it is low priority. The author is right that stack walking, signals, and memory control are important areas that could help here. Overall with WasmGC and exceptions we are in a pretty good place for Java as emitted by J2Wasm today: it is usually faster than J2CL which compiles Java to JavaScript. But there is definitely room for improvement.

LunaSea 3y ago

Ten years on and I still don't understand the point of WebAssembly. The tech is insanely complex and well done. I'm just not sure about the problem it's trying to solve.