3 ms·

Why does GC make it harder to call libraries in other languages?

by jules 9y ago

jonathanstrange 9y ago
Because you have to add support for GCing of foreign structures from these libraries, or keep the interface low-level and force the user of the GCed language to manually manage these foreign objects. Adding support for GC can be difficult if not impossible, because GCs often arrange memory in special ways (different pools, etc.) whereas the foreign library probably just uses malloc.
humanrebar 9y ago
Languages interfacing through an ABI implicitly need to agree on their memory models, calling conventions, exception unwinding, etc. There's lots of detail in the D language garbage collection docs: https://dlang.org/spec/garbage.html https://dlang.org/spec/garbage.html The whole thing might be instructive, but 28.3.3 has a bunch of particular expectations of the D GC.
adwn 9y ago
What I meant was: If language X needs a GC, then writing a library in X makes it difficult and very inconvenient to use that library from another language. The comments of jonathanstrange and humanrebar are also spot-on.
lmm 9y ago
When you're working in a GCed language you assume your language's GC is responsible for freeing memory. When you interoperate with a language where owners are responsible for freeing memory, you have to have a way to "disown" structures you've created but passed into the ownership language (e.g. a callback you've passed to a library function) so that your GC doesn't free them, and a way to "own" structures you've received from the ownership language (e.g. values returned from library functions) so that your GC does free them, and neither of these things will be easy/natural in your language. When you interoperate with another GCed language it's even harder, virtually impossible, because both languages' GCs assume they own everything and so anything that's visible in both languages will be freed twice.
- pjmlp 9y ago
  Well, declaring untraced references in Modula-3 or Active Oberon, or doing native heap allocations in Nim, D, Java and C# is relatively simple. Using GC languages doesn't mean doing 100% memory allocation via GC.
  - lmm 9y ago
    I've done it in Java; it's not officially supported in the language standard (or has only recently been added if so - certainly they were talking about it for years), and the wider language does not generally have the support or idioms you would want (e.g. try-with-resources was only introduced a couple of versions ago), libraries aren't oriented towards that style.... It's certainly doable but I'd stand by it not being easy or natural.
    - pjmlp 9y ago
      Although I mentioned Java, due to ByteBuffers and Unsafe, it is clearly not the best one of the set of languages that I mentioned. Others on that list have specific language features for GC free allocation.

Why does GC make it harder to call libraries in other languages?

by jules 9y ago

Why does GC make it harder to call libraries in other languages?

Because you have to add support for GCing of foreign structures from these libraries, or keep the interface low-level and force the user of the GCed language to manually manage these foreign objects. Adding support for GC can be difficult if not impossible, because GCs often arrange memory in special ways (different pools, etc.) whereas the foreign library probably just uses malloc.

humanrebar 9y ago

Languages interfacing through an ABI implicitly need to agree on their memory models, calling conventions, exception unwinding, etc. There's lots of detail in the D language garbage collection docs: https://dlang.org/spec/garbage.html https://dlang.org/spec/garbage.html The whole thing might be instructive, but 28.3.3 has a bunch of particular expectations of the D GC.

adwn 9y ago

What I meant was: If language X needs a GC, then writing a library in X makes it difficult and very inconvenient to use that library from another language. The comments of jonathanstrange and humanrebar are also spot-on.

lmm 9y ago

When you're working in a GCed language you assume your language's GC is responsible for freeing memory. When you interoperate with a language where owners are responsible for freeing memory, you have to have a way to "disown" structures you've created but passed into the ownership language (e.g. a callback you've passed to a library function) so that your GC doesn't free them, and a way to "own" structures you've received from the ownership language (e.g. values returned from library functions) so that your GC does free them, and neither of these things will be easy/natural in your language. When you interoperate with another GCed language it's even harder, virtually impossible, because both languages' GCs assume they own everything and so anything that's visible in both languages will be freed twice.

pjmlp 9y ago
Well, declaring untraced references in Modula-3 or Active Oberon, or doing native heap allocations in Nim, D, Java and C# is relatively simple. Using GC languages doesn't mean doing 100% memory allocation via GC.
- lmm 9y ago
  I've done it in Java; it's not officially supported in the language standard (or has only recently been added if so - certainly they were talking about it for years), and the wider language does not generally have the support or idioms you would want (e.g. try-with-resources was only introduced a couple of versions ago), libraries aren't oriented towards that style.... It's certainly doable but I'd stand by it not being easy or natural.
  - pjmlp 9y ago
    Although I mentioned Java, due to ByteBuffers and Unsafe, it is clearly not the best one of the set of languages that I mentioned. Others on that list have specific language features for GC free allocation.