2 ms·
The problems with a GC (in the context of embedding it in a larger codebase written in a another language) is that the calling conventions are more complicated
by cyphar 9y ago
The problems with a GC (in the context of embedding it in a larger codebase written in a another language) is that the calling conventions are more complicated and the existence of a GC (especially mark-and-sweep GCs) means that the embedding is not "seamless". Even with a C FFI interface it's still harder than (for example) using Rust or C in such a project.
And if both languages have GC, then you're in even more trouble.
- johncolanduoni 9y agoFor what language runtime are the calling conventions an issue? Even the most calling-convention dependent GC I can think of (GHC Haskell's) can handle standard C ABIs and .NET is a good example of making this whole process relatively seamless. If you can export a C FFI with pinned pointers in both directions, I don't see how it's any harder than Rust or C. The multiple GCs in a process issue is usually due to the collector not playing nice with signal/exception handler installation when using safepoints, which is purely an issue of lazy implementations. There's even ways to collect cross-heap cycles when working this multiple GCs (Xamarin on Android does this fairly well).