undefined | Better HN

0 pointskodablah10y ago0 comments

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.

0 comments

1 comments · 1 top-level

amelius10y ago

> 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.

j / k navigate · click thread line to collapse