4 ms·

> GC and Exception handling This was not necessary.. what a mistake, specially EH..

aag 1y ago
Not including GC would have been a mistake. Having to carry a complete garbage collector with every program, especially on platforms like browsers were excellent ones already exist, would have been a waste.
- ridiculous_fish 1y ago
  Doesn't every WASM program have to carry its own malloc/free today?
  - phickey 1y ago
    Yes, every wasm program that uses linear memory (which includes all those created by llvm toolchains) must ship with its own allocator. You only get to use the wasm GC provided allocator if your program is using the gc types, which can’t be stored in a linear memory.
  - flohofwoe 1y ago
    Yes, but Emscripten comes with a minimal allocator that's good enough for most C code (e.g. code with low alloc/free frequency) and only adds minimal size overhead: https://github.com/emscripten-core/emscripten/blob/main/system/lib/emmalloc.c https://github.com/emscripten-core/emscripten/blob/main/syst...
- em-bee 1y ago
  how is that different from compiling against a traditional CPU which also doesn't have a built in GC? i mean those programs that need a GC already have one. so what is the benefit of including one on the "CPU"?
  - aag 1y ago
    The "CPU" in every browser already has one. This lets garbage-collected languages use that one. That's an enormous savings in code size and development effort.
    - em-bee 1y ago
      i don't see the reduced development effort, after all, unless the language is only running on webassembly i still need to implement my own GC for other CPUs. so most GC-languages being ported to webassembly already have a GC, so what is the benefit of using a provided GC then? on the other hand i see GC as a feature that could become part of any modern CPU. then the benefit would be large, as any language could use it and wouldn't have to implement their own at all anymore.
      - 0x457 1y ago
        > i don't see the reduced development effort, after all, unless the language is only running on webassembly i still need to implement my own GC for other CPUs. I'd think porting an existing GC to WASM is more effort than using WASM's GC for a GC'd language?
        em-bee 1y ago
        i don't think so. first of all, you don't rewrite your code for every CPU but you just adapt some specific things. most code is just compiled for the new architecture and runs. second, those languages that are already running on wasm have already done the work. so at best new languages who haven't been ported yet will get any benefit from a reduced porting effort.
      - aag 1y ago
        Writing a GC that performs well often involves making decisions that are tightly coupled to the processor architecture and operating system as well as the language implementation's memory representations for objects. Using a GC that is already present can solve that problem.
      - 1y ago
- AgentME 1y ago
  It's also important because sometimes you want a WebAssembly instance to hold a reference to a GC object from Javascript, such as a DOM object, or be able to return a similar GC object back to Javascript or to another separate WebAssembly instance. Doing the first part alone is easy to do with a little bit of JS code (make the JS code hold a reference to the GC object, give the Wasm an id that corresponds to it, and let the Wasm import some custom JS functions that can operate on that id), but it's not composable in a way that lets the rest of those tasks work in a general way.
bangaladore 1y ago
WASM isn't a language, so them adding stuff like this serves to increase performance and standardize rather than forcing compilers to emulate common functionality.
sehugg 1y ago
It's kinda nice to have 1st class exception support. C++ exceptions barely work in Emscripten right now. Part of the problem is that you can't branch to arbitrary labels in WASM.
hiccuphippo 1y ago
This allows more languages to compile to it. You don't need to use these features if you don't want to.
flohofwoe 1y ago
I think it's a "you don't pay for it if you don't use it" thing, so I guess it's fine. It won't affect me compiling my C or Zig code to WASM for instance since those languages have neither garbage collection nor exceptions.
dzaima 1y ago
Besides making it much nicer for GC'd languages to target WASM, an important aspect is that it also allows cross-language GC. Whereas with a manual GC, if you had a JS object holding a reference to an object on your custom heap, and your heap holds a reference to that JS object (with indirections sprinkled in to taste) but nothing else references it, that'd result in a permanent memory leak, as both heaps would have to consider everything held by the other as GC roots; so you'd still be forced to manually avoid cycles despite only ever using GC'd languages. Wasm GC entirely avoids this problem.

aag 1y ago

Not including GC would have been a mistake. Having to carry a complete garbage collector with every program, especially on platforms like browsers were excellent ones already exist, would have been a waste.

ridiculous_fish 1y ago
Doesn't every WASM program have to carry its own malloc/free today?
- phickey 1y ago
  Yes, every wasm program that uses linear memory (which includes all those created by llvm toolchains) must ship with its own allocator. You only get to use the wasm GC provided allocator if your program is using the gc types, which can’t be stored in a linear memory.
- flohofwoe 1y ago
  Yes, but Emscripten comes with a minimal allocator that's good enough for most C code (e.g. code with low alloc/free frequency) and only adds minimal size overhead: https://github.com/emscripten-core/emscripten/blob/main/system/lib/emmalloc.c https://github.com/emscripten-core/emscripten/blob/main/syst...
em-bee 1y ago
how is that different from compiling against a traditional CPU which also doesn't have a built in GC? i mean those programs that need a GC already have one. so what is the benefit of including one on the "CPU"?
- aag 1y ago
  The "CPU" in every browser already has one. This lets garbage-collected languages use that one. That's an enormous savings in code size and development effort.
  - em-bee 1y ago
    i don't see the reduced development effort, after all, unless the language is only running on webassembly i still need to implement my own GC for other CPUs. so most GC-languages being ported to webassembly already have a GC, so what is the benefit of using a provided GC then? on the other hand i see GC as a feature that could become part of any modern CPU. then the benefit would be large, as any language could use it and wouldn't have to implement their own at all anymore.
    - 0x457 1y ago
      > i don't see the reduced development effort, after all, unless the language is only running on webassembly i still need to implement my own GC for other CPUs. I'd think porting an existing GC to WASM is more effort than using WASM's GC for a GC'd language?
      - em-bee 1y ago
        i don't think so. first of all, you don't rewrite your code for every CPU but you just adapt some specific things. most code is just compiled for the new architecture and runs. second, those languages that are already running on wasm have already done the work. so at best new languages who haven't been ported yet will get any benefit from a reduced porting effort.
    - aag 1y ago
      Writing a GC that performs well often involves making decisions that are tightly coupled to the processor architecture and operating system as well as the language implementation's memory representations for objects. Using a GC that is already present can solve that problem.
    - 1y ago
AgentME 1y ago
It's also important because sometimes you want a WebAssembly instance to hold a reference to a GC object from Javascript, such as a DOM object, or be able to return a similar GC object back to Javascript or to another separate WebAssembly instance. Doing the first part alone is easy to do with a little bit of JS code (make the JS code hold a reference to the GC object, give the Wasm an id that corresponds to it, and let the Wasm import some custom JS functions that can operate on that id), but it's not composable in a way that lets the rest of those tasks work in a general way.

bangaladore 1y ago

WASM isn't a language, so them adding stuff like this serves to increase performance and standardize rather than forcing compilers to emulate common functionality.

sehugg 1y ago

It's kinda nice to have 1st class exception support. C++ exceptions barely work in Emscripten right now. Part of the problem is that you can't branch to arbitrary labels in WASM.

hiccuphippo 1y ago

This allows more languages to compile to it. You don't need to use these features if you don't want to.

flohofwoe 1y ago

I think it's a "you don't pay for it if you don't use it" thing, so I guess it's fine. It won't affect me compiling my C or Zig code to WASM for instance since those languages have neither garbage collection nor exceptions.

dzaima 1y ago

Besides making it much nicer for GC'd languages to target WASM, an important aspect is that it also allows cross-language GC. Whereas with a manual GC, if you had a JS object holding a reference to an object on your custom heap, and your heap holds a reference to that JS object (with indirections sprinkled in to taste) but nothing else references it, that'd result in a permanent memory leak, as both heaps would have to consider everything held by the other as GC roots; so you'd still be forced to manually avoid cycles despite only ever using GC'd languages. Wasm GC entirely avoids this problem.