4 ms·

What are the challenges to provide a standard GC interface that all managed languages can leverage.

jfoutz 8y ago
allocation characteristics of different languages. Go copies when passing args. java is pass by value, but those values are usually pointers to objects. very different needs.
pcwalton 8y ago
Tracing objects in the heap (and/or stack). The GC has to be able to find all the outgoing pointers from any object, and usually the types of the objects pointed to by those pointers as well. Different language runtimes store objects in memory in different ways.
- crudbug 8y ago
  I think the interface can provide the semantics - pass by reference or value etc. Which can be standardized. Then it is upto the languages to implement the interface. IMO the languages designers and developers are better off by looking at the GC solution from top-down rather than bottom-up.
  - candiodari 8y ago
    Maybe you should think about what this would mean from the perspective of language designers. That would unearth the main difficulty of such an approach: Every language designer would have to completely redesign it's runtime system just to be able to run on this one backend (in addition to having a new compiler target and linker and debugger and ...). Hoping, of course, that this is possible at all, as many languages have various ways to store pointers to things in memory, which including not storing one at all (ie. pointer arithmetic). Why would they do this ? Why should they do this ? You could simply make the existing runtime libraries run.
    - amelius 8y ago
      > Why would they do this ? Why should they do this ? One answer could be that it would enable multiple languages to interface in a better way, and allow garbage to be collected across language boundaries.
amelius 8y ago
I believe that the LLVM project is trying to accomplish this [1]. However, the concurrent, non-pausing GC of GoLang is not easy to match in efficiency. I'd be interested to hear about actual high-quality implementations of GCs in LLVM. And then there's the problem of making it all work efficiently in WASM (which doesn't yet support advanced concepts needed by GCs such as memory barriers). [1] https://llvm.org/docs/GarbageCollection.html#goals-and-non-goals https://llvm.org/docs/GarbageCollection.html#goals-and-non-g...
- pcwalton 8y ago
  I believe the only user of the LLVM GC infrastructure is Azul's JVM. Azul is of course famous for Azul C4, which is a superior GC to that of Go.

allocation characteristics of different languages. Go copies when passing args. java is pass by value, but those values are usually pointers to objects. very different needs.

pcwalton 8y ago

Tracing objects in the heap (and/or stack). The GC has to be able to find all the outgoing pointers from any object, and usually the types of the objects pointed to by those pointers as well. Different language runtimes store objects in memory in different ways.

crudbug 8y ago
I think the interface can provide the semantics - pass by reference or value etc. Which can be standardized. Then it is upto the languages to implement the interface. IMO the languages designers and developers are better off by looking at the GC solution from top-down rather than bottom-up.
- candiodari 8y ago
  Maybe you should think about what this would mean from the perspective of language designers. That would unearth the main difficulty of such an approach: Every language designer would have to completely redesign it's runtime system just to be able to run on this one backend (in addition to having a new compiler target and linker and debugger and ...). Hoping, of course, that this is possible at all, as many languages have various ways to store pointers to things in memory, which including not storing one at all (ie. pointer arithmetic). Why would they do this ? Why should they do this ? You could simply make the existing runtime libraries run.
  - amelius 8y ago
    > Why would they do this ? Why should they do this ? One answer could be that it would enable multiple languages to interface in a better way, and allow garbage to be collected across language boundaries.

amelius 8y ago

I believe that the LLVM project is trying to accomplish this [1]. However, the concurrent, non-pausing GC of GoLang is not easy to match in efficiency. I'd be interested to hear about actual high-quality implementations of GCs in LLVM. And then there's the problem of making it all work efficiently in WASM (which doesn't yet support advanced concepts needed by GCs such as memory barriers). [1] https://llvm.org/docs/GarbageCollection.html#goals-and-non-goals https://llvm.org/docs/GarbageCollection.html#goals-and-non-g...

pcwalton 8y ago
I believe the only user of the LLVM GC infrastructure is Azul's JVM. Azul is of course famous for Azul C4, which is a superior GC to that of Go.