5 ms·

I'm curious how they solve garbage-collection, since last time I checked WebAssembly doesn't yet support that?

by pushtheenvelope 8y ago

JoelMcCracken 8y ago
Presumably it’s implemented “natively”. Just like it would be on a native pl.
- carterschonwald 8y ago
  I don’t think it has gc yet ..
Tarean 8y ago
So far they use the "don't" approach to garbage collection. It would have to be implemented.like the rest of the rts. I guess parts of the c code could be transpiled but something low-level like the gc relies on details like register pinning.
pjmlp 8y ago
Most likely the same way as in any hardware CPU without support for GC memory tagging.
- weberc2 8y ago
  What is hw support for GC mem tagging? I didnt realize such a thing existed.
  - Solar19 8y ago
    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.
    - pjmlp 8y ago
      Surely it was deployed, in the original Lisp Machines hardware.
      - Solar19 8y ago
        Right. I forgot about those.
  - pjmlp 8y ago
    It existed on Lisp machines. https://en.wikipedia.org/wiki/Lisp_machine 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.pdf 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.2438 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/00207929.pdf 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_collection https://en.wikipedia.org/wiki/Intel_iAPX_432#Garbage_collect... https://news.ycombinator.com/item?id=9448712 https://news.ycombinator.com/item?id=9448712
Matthias247 8y ago
C and ASM don't have a GC either, and yet we can build GC collected languages on top of them. So it will be eventually be solved in the same fashion: By building a runtime environment on top of the underlying machine, which performs memory management incl. garbage collection. Depending on how the runtime for "native Haskell" is implemented, the effort might be everything from just cross-compile it to building a completely separate runtime.
- kazinator 8y ago
  In assembly language, you can build an accurate garbage collector for your assembly language application. There are no hidden "not user servicable" areas in the run-time, like in C. You can set up your calling and framing conventions so the GC can trace the stack and know exactly where the root pointers are.
dllthomas 8y ago
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.
- jlokier 8y ago
  Yes, like the IE memory leaks (and early Mozilla leaks) where DOM and JavaScript objects are collected in a different way, so can easily get stuck in unfreeable reference cycles. 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.
terrorjack 8y ago
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).
- tom_mellior 8y ago
  To be clear, this will be your own GC bundled with each application, not an interface to the host browser's GC?
  - terrorjack 8y ago
    Indeed it's not an interface to the browser's gc. There does exist a wasm anyref proposal which enables manipulating opaque references in wasm and a gc proposal for further allocating/using such garbage collected objects. However, basing our gc on those is currently less pragmatic than rolling our own :)

I'm curious how they solve garbage-collection, since last time I checked WebAssembly doesn't yet support that?

JoelMcCracken 8y ago

Presumably it’s implemented “natively”. Just like it would be on a native pl.

carterschonwald 8y ago
I don’t think it has gc yet ..

Tarean 8y ago

So far they use the "don't" approach to garbage collection. It would have to be implemented.like the rest of the rts. I guess parts of the c code could be transpiled but something low-level like the gc relies on details like register pinning.

pjmlp 8y ago

Most likely the same way as in any hardware CPU without support for GC memory tagging.

weberc2 8y ago
What is hw support for GC mem tagging? I didnt realize such a thing existed.
- Solar19 8y ago
  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.
  - pjmlp 8y ago
    Surely it was deployed, in the original Lisp Machines hardware.
    - Solar19 8y ago
      Right. I forgot about those.
- pjmlp 8y ago
  It existed on Lisp machines. https://en.wikipedia.org/wiki/Lisp_machine 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.pdf 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.2438 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/00207929.pdf 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_collection https://en.wikipedia.org/wiki/Intel_iAPX_432#Garbage_collect... https://news.ycombinator.com/item?id=9448712 https://news.ycombinator.com/item?id=9448712

Matthias247 8y ago

C and ASM don't have a GC either, and yet we can build GC collected languages on top of them. So it will be eventually be solved in the same fashion: By building a runtime environment on top of the underlying machine, which performs memory management incl. garbage collection. Depending on how the runtime for "native Haskell" is implemented, the effort might be everything from just cross-compile it to building a completely separate runtime.

kazinator 8y ago
In assembly language, you can build an accurate garbage collector for your assembly language application. There are no hidden "not user servicable" areas in the run-time, like in C. You can set up your calling and framing conventions so the GC can trace the stack and know exactly where the root pointers are.

dllthomas 8y ago

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.

jlokier 8y ago
Yes, like the IE memory leaks (and early Mozilla leaks) where DOM and JavaScript objects are collected in a different way, so can easily get stuck in unfreeable reference cycles. 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.

terrorjack 8y ago

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

tom_mellior 8y ago
To be clear, this will be your own GC bundled with each application, not an interface to the host browser's GC?
- terrorjack 8y ago
  Indeed it's not an interface to the browser's gc. There does exist a wasm anyref proposal which enables manipulating opaque references in wasm and a gc proposal for further allocating/using such garbage collected objects. However, basing our gc on those is currently less pragmatic than rolling our own :)