3 ms·

GC's have some kind of inherit reference counting which makes releasing pointers safe, in any direction. You can't do that with C/C++ without something like gli

by pknopf 9y ago

GC's have some kind of inherit reference counting which makes releasing pointers safe, in any direction. You can't do that with C/C++ without something like glib.

the_mitsuhiko 9y ago
Not entirely sure what you are referring to or how it relates to the issue here. If you have two separate heaps (what you have between go and JS) then they will be collected separately. As such you need to somehow keep objects on the other side alive. Worst: in Go the language does not guarantee that the GC won't compact (it doesn't do correctly though). As such you can't even pass pointers to JavaScript, you need to create handles. I played around with both Go and Rust from Python and the garbage collection made things harder not easier. Now we write lots of Rust modules for Python and managing memory is pretty easy. We have Python wrapper objects that keep one pointer alive.
kibwen 9y ago
> GC's have some kind of inherit reference counting which makes releasing pointers safe, in any direction. It sounds like you're mostly worried about memory leaks, but the primary concern with trying to get two separate GCs to play nicely isn't leaking memory, it's double-frees (both GCs trying to collect the same resource) and use-after-free (code in one language trying to use a resource that's been accidentally collected by the GC of the other language).
- deleted 9y ago
  [deleted]
majewsky 9y ago
If you have reference counting across GC boundaries, you can easily create memory leaks because of reference cycles, e.g. GC 1 cannot release object 1 because it references object 2, and vice versa. (Unless you only allow refs to go one way.)
- masklinn 9y ago
  Great now I get flashbacks to 2005. IE6 had exactly that issue, the DOM was implemented using COM which has its own GC (refcounting) separate from the regular JS runtime. If you created a cycle between DOM and JS by, let's say, adding an event handler to a DOM node — thankfully that's something you'd never do when developing web pages & applications — you'd start leaking memory which would survive across page reloads. There was actually a bit of software called Drip, it was just a webview wrapper (technically an MFC app with a browser COM component), you'd launch it, open your page, click the "blow memory" button and it'd reload the page over and over again listing elements which had survived between reloads.
pcwalton 9y ago
No major JS implementation uses naive reference counting, because there's no way to break cycles. Cycle collection requires the ability to trace the heap globally. But the JS engine does not have any way to see inside a wasm heap.

by pknopf 9y ago

GC's have some kind of inherit reference counting which makes releasing pointers safe, in any direction. You can't do that with C/C++ without something like glib.

the_mitsuhiko 9y ago

Not entirely sure what you are referring to or how it relates to the issue here. If you have two separate heaps (what you have between go and JS) then they will be collected separately. As such you need to somehow keep objects on the other side alive. Worst: in Go the language does not guarantee that the GC won't compact (it doesn't do correctly though). As such you can't even pass pointers to JavaScript, you need to create handles. I played around with both Go and Rust from Python and the garbage collection made things harder not easier. Now we write lots of Rust modules for Python and managing memory is pretty easy. We have Python wrapper objects that keep one pointer alive.

kibwen 9y ago

> GC's have some kind of inherit reference counting which makes releasing pointers safe, in any direction. It sounds like you're mostly worried about memory leaks, but the primary concern with trying to get two separate GCs to play nicely isn't leaking memory, it's double-frees (both GCs trying to collect the same resource) and use-after-free (code in one language trying to use a resource that's been accidentally collected by the GC of the other language).

deleted 9y ago
[deleted]

majewsky 9y ago

If you have reference counting across GC boundaries, you can easily create memory leaks because of reference cycles, e.g. GC 1 cannot release object 1 because it references object 2, and vice versa. (Unless you only allow refs to go one way.)

masklinn 9y ago
Great now I get flashbacks to 2005. IE6 had exactly that issue, the DOM was implemented using COM which has its own GC (refcounting) separate from the regular JS runtime. If you created a cycle between DOM and JS by, let's say, adding an event handler to a DOM node — thankfully that's something you'd never do when developing web pages & applications — you'd start leaking memory which would survive across page reloads. There was actually a bit of software called Drip, it was just a webview wrapper (technically an MFC app with a browser COM component), you'd launch it, open your page, click the "blow memory" button and it'd reload the page over and over again listing elements which had survived between reloads.

pcwalton 9y ago

No major JS implementation uses naive reference counting, because there's no way to break cycles. Cycle collection requires the ability to trace the heap globally. But the JS engine does not have any way to see inside a wasm heap.