21–30 of 36 posts
Earlier quoted context omitted.
Most likely the same way as in any hardware CPU without support for GC memory tagging.
What is hw support for GC mem tagging? I didnt realize such a thing existed.
https://en.wikipedia.org/wiki/Lisp_machine
"Lisp Hardware Architecture: The Explorer II and beyond"
https://3e8.org/pub/scheme/doc/lisp-pointers/v1i6/p13-dussud...
"Garbage collection in a large LISP system"
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.125....
"KIM 20 : A SYMBOLIC RISC MICROPROCESSOR FOR EMBEDDED ADVANCED CONTROL "
https://www.computer.org/csdl/proceedings/easic/1990/2066/00...
The failed iAPX 432 processor from Intel also supported it.
https://en.wikipedia.org/wiki/Intel_iAPX_432#Garbage_collect...
Earlier quoted context omitted.
What is hw support for GC mem tagging? I didnt realize such a thing existed.
It's something that has been researched, but not deployed. It would implement GC memory tagging in the CPU or even the memory controller. Google Scholar should produce some good hits.
Surprised to see that no one has mentioned GHCJS " rel="nofollow">https://github.com/ghcjs/ghcjs> still. I have used it[0] a year ago and despite my shallow understanding of Haskell, I have managed to port my CLI app to Haskell fairly easily! [0]: https://github.com/boramalper/boolexman
I'm curious how they solve garbage-collection, since last time I checked WebAssembly doesn't yet support that?
I'm curious how they solve garbage-collection, since last time I checked WebAssembly doesn't yet support that?
It'll be a copying GC, with builtin support to automatically free unused JavaScript references in the Haskell heap. It's also possible to plug in more fancy gc algorithms later (e.g. generational, or concurrent ones with read barriers).
Surprised to see that no one has mentioned GHCJS " rel="nofollow">https://github.com/ghcjs/ghcjs> still. I have used it[0] a year ago and despite my shallow understanding of Haskell, I have managed to port my CLI app to Haskell fairly easily! [0]: https://github.com/boramalper/boolexman
It's not the same though. GHCJS is a Haskell to JS source compiler (transpiler?). Webassembly is a lower level altogether.
I'm curious how they solve garbage-collection, since last time I checked WebAssembly doesn't yet support that?
The consensus of "the same way they do in native code" is a probable approach, but it's worth calling out an additional complication in this setting: you might wind up working with two garbage collectors, with references in one keeping objects in the other alive. This isn't intractable, but it is messy.
Old Frameworks have to do perverse things to break those cycles, and if they don't, the browsers leaked memory over time.
It would be sad if that came back to modern browsers, due to WASM and DOM using separate collectors. Or worse, multiple WASM components, (perhaps in different languages, perhaps not, but all different collectors), holding indirect, accidental references to each other because someone decided to use the components in the same DOM.
Earlier quoted context omitted.
Are those sites using Emscripten or just passing your docs to a server to process?
Markup.rocks says it is client side and appears to be using ghcjs: https://github.com/osener/markup.rocks/blob/master/Makefile#...
I'm curious how they solve garbage-collection, since last time I checked WebAssembly doesn't yet support that?
Hi, asterius main dev here. Garbage collection support is near; we're working actively on it, and after a few regressions are fixed it'll be available on master. It'll be a copying GC, with builtin support to automatically free unused JavaScript references in the Haskell heap. It's also possible to plug in more fancy gc algorithms later (e.g. generational, or concurrent ones with read barriers).