4 ms·

I imagine one could look to the JVM GC interfaces for inspiration. They seem to have made a pluggable architecture for GC. That said, I don't know how beneficia

I imagine one could look to the JVM GC interfaces for inspiration. They seem to have made a pluggable architecture for GC. That said, I don't know how beneficial a system-wide pluggable GC architecture would be considering how much the tradeoffs vary for GC and how intricately those tradeoffs are related to the host programming language (e.g., Go's upfront allocations are quite expensive, but in exchange the collection is super low latency--that works very well for Go, but it wouldn't work so well for languages that idiomatically generate tremendous amounts of garbage (basically any functional language, Java, .Net, Python, etc). You could have a system GC for Go, one for Python, one for Java, etc which is basically the JVM/.Net approach, except they extended it to the whole VM--not just the GC--however, in practice it seems like applications want different versions of the runtime and increasingly end up shipping their entire runtime with the app anyway (Go just went all-in and made this the default, which is actually really nice from a developer and user perspective). So while a system GC (give or take plugability) sounds nice, in practice it seems like the ecosystem is moving the other direction.

amelius 5y ago
What if you want to make two languages cooperate? If they both have their own GC, then you can't garbage collect across language boundaries, which can be annoying. I think this is similar to the microservices debate, where you have either one big transactional database or a bunch of disconnected ones where committing a transaction involving multiple services becomes increasingly difficult.
- throwaway894345 5y ago
  > What if you want to make two languages cooperate? If they both have their own GC, then you can't garbage collect across language boundaries, which can be annoying. I think this is similar to the microservices debate, where you have either one big transactional database or a bunch of disconnected ones where committing a transaction involving multiple services becomes increasingly difficult. This is an interesting observation. I think in both cases the ideal of having one large system remains elusive and the more robust, practical solution is RPC (basically more, smaller control loops rather than a single larger control loop). To abstract this out even further, I've noticed that this seems to be a common pattern in reliable distributed systems are architected--from Erlang's OTP to Kubernetes' controller approach. I'm actually really surprised this "controller" or "control system" architecture vs monolith architecture isn't discussed more frequently, at least in terms of reliability tradeoffs.
- pjmlp 5y ago
  You have GC APIs at the FFI level to let runtimes communicate and pin references across runtimes. D, Java and .NET provide such APIs.
  - amelius 5y ago
    But do these runtimes allow circular references across language boundaries?
    - pjmlp 5y ago
      How do you think something like mixing .NET and COM/UWP libraries work? By mixing GC with the reference counting of pining such references. Naturally you can get the reference count wrong. Still much better than just doing plain old manual memory management, as those are corner cases, while with manual memory management every allocation is a possible leak. Incidently this scenario was exacly one of the ones presented at why Linear Haskell (JVM/Haskell interoperability) by Tweag at the recent functional programming languages conference.

amelius 5y ago

What if you want to make two languages cooperate? If they both have their own GC, then you can't garbage collect across language boundaries, which can be annoying. I think this is similar to the microservices debate, where you have either one big transactional database or a bunch of disconnected ones where committing a transaction involving multiple services becomes increasingly difficult.

throwaway894345 5y ago
> What if you want to make two languages cooperate? If they both have their own GC, then you can't garbage collect across language boundaries, which can be annoying. I think this is similar to the microservices debate, where you have either one big transactional database or a bunch of disconnected ones where committing a transaction involving multiple services becomes increasingly difficult. This is an interesting observation. I think in both cases the ideal of having one large system remains elusive and the more robust, practical solution is RPC (basically more, smaller control loops rather than a single larger control loop). To abstract this out even further, I've noticed that this seems to be a common pattern in reliable distributed systems are architected--from Erlang's OTP to Kubernetes' controller approach. I'm actually really surprised this "controller" or "control system" architecture vs monolith architecture isn't discussed more frequently, at least in terms of reliability tradeoffs.
pjmlp 5y ago
You have GC APIs at the FFI level to let runtimes communicate and pin references across runtimes. D, Java and .NET provide such APIs.
- amelius 5y ago
  But do these runtimes allow circular references across language boundaries?
  - pjmlp 5y ago
    How do you think something like mixing .NET and COM/UWP libraries work? By mixing GC with the reference counting of pining such references. Naturally you can get the reference count wrong. Still much better than just doing plain old manual memory management, as those are corner cases, while with manual memory management every allocation is a possible leak. Incidently this scenario was exacly one of the ones presented at why Linear Haskell (JVM/Haskell interoperability) by Tweag at the recent functional programming languages conference.