[amelius]

1. If people can implement their own GC, then they can make it fit exactly their specific use-case. For example, a GC for Haskell might be totally different from a GC for JS.

2. If web-assembly incorporates a GC, then it will become needlessly complicated.

3. Unnecessary complication in web-assembly means also unnecessary room for security flaws.

(4. What good is a web assembly if you can't implement an efficient garbage collector in it?)

[kodablah]

In addition to the other commenter mentioning it will use the JS GC of the browser for #2 (which has tons of manpower behind), the issue with #4 is that you would need threads w/ shared memory [1] which seems as far out as a native GC. Also, for #3, it's not "unnecessary" for a multitude of developers and languages. Web development without (at least optional) GC is going the wrong direction.

1 - https://github.com/WebAssembly/design/issues/104

[amelius]

> which has tons of manpower behind

What is wrong with open-sourcing GC code as independent libraries, so that web-app makers or (more likely) compiler developers (with less skill/time) can use them at will?

> the issue with #4 is that you would need threads w/ shared memory

But this is exactly what we need for other applications as well. For example, how would you send a large immutable data-structure across two threads? By copying it? Of course not, you just share pointers, meaning that the address space should be shared. If this is not possible, then that is a major flaw in WASM's design.

I think you have the impression that incorporating a GC into WASM makes life easier. But it doesn't. It is the exact opposite. WASM should be as simple as possible.

[kodablah]

It would be fine if it was an independent library. I am not under the impression of incorporating a GC into WASM makes life easier. I am under the impression that having a GC available makes life easier. To think that you can magically recompile the existing GC's that V8 or WhateverMonkey are using to WASM is naive. Exposing the ability to request memory, add roots, and handle weak references, etc will make it more usable. Waiting until WASM has the ability to do threaded memory management at the same level as the existing GCs and have them rewritten (or refactored) for it may be too long. I would also support a polyfill approach where a GC shared-lib-sort of interface is exposed and tied to existing implementations at first to keep it out of WASM.

[amelius]

> To think that you can magically recompile the existing GC's that V8 or WhateverMonkey are using to WASM is naive.

I don't think it is. What I would like to see is that compiler writers keep control over their GC.

> Waiting until WASM has the ability to do threaded memory management at the same level as the existing GCs and have them rewritten (or refactored) for it may be too long.

I don't see the big problems. We already have assembly without GCs, and it is called VirtualBox (or VMWare). Why not use something like that? (Yes, there are still some security issues, but these can be solved much easier than when the hairy GC code becomes part of the game).

In other words, let's first create a real assembly language with a simple but adequate instruction set, and make it secure. This is what I would call "assembly language" anyway.

[wtetzner]

I think the value in having a standardized GC is simpler interop between wasm languages.

There's nothing that would prevent writing your own GC if you felt the need.

[ethbro]

Not to mention the horror of inventing and deploying an efficient binary packed web execution format, only to slow things down even further in 5 years by seeing webpages load myGC_v1.2.5 + myGC_v1.3.1 + nuGC_v2.1.3 etc etc

[amelius]

This can be approached the same way as shared binaries. Just load the relevant libraries once, then cache.

[Rusky]

WebAssembly's GC isn't just some arbitrary new GC, it's the JavaScript GC. The benefit there is so wasm apps can integrate with JS and the DOM directly the same way things like Python or Ruby plugins written in C integrate with those GCs. Nothing prevents wasm apps from using their own GC as well.

[PeCaN]

The built-in WebAssembly GC could just be the native JS GC, which is very, very good for most dynamic languages. There's really not that much difference between GCing JS, Lua, Python, and MyDynamicLanguageWithRubySyntaxAndLuaSemanticsAndNewFeatureX. I don't see why they'd need to do anything other than just expose the GC that's already there. Browser makers are smart enough to know "invent new GC that solves every conceivable language's memory problems" isn't going to work.

Since WebAsm is still Functional languages would still have the freedom to implement their own more efficient GC (avoid the write barrier in a lot of cases, scan only the young heap most of the time, etc).

[amelius]

> There's really not that much difference between GCing JS, Lua, Python, and MyDynamicLanguageWithRubySyntaxAndLuaSemanticsAndNewFeatureX

This sounds a lot like "640k ought to be enough for everyone" :)

Also, it only addressed my first point.

[wtetzner]

> 4. What good is a web assembly if you can't implement an efficient garbage collector in it?

There's nothing stopping you from implementing your own GC. But having a standardized GC (the JS engine's GC) means much simpler interop between wasm languages.