5 ms·

Why is it that GC technology is so hard to transfer from one language to another? I'd kill for a FLOSS implementation of Azul's GC, or a good small-heap-special

Why is it that GC technology is so hard to transfer from one language to another? I'd kill for a FLOSS implementation of Azul's GC, or a good small-heap-specialized GC for .NET. It seems far too often we run into popular languages whose growth has stalled due to their GC, or features that have been held back by GC, or whatever. And then other languages have several different GCs with different characteristics that can be swapped out with a simple CLI flag. Is it something that is deeply and strongly coupled to the language structure? Is the parameter space for tuning just too large to practically swap one GC for another? Incompatible algorithms? Maybe one of those situations where you get 80% of the way with an ounce of effort, but to get to 81% takes years?

waterhouse 10y ago
Some answers that come to mind: - Azul's GC requires cooperation from the kernel; I believe it specifically uses the virtual memory mechanism to implement a read barrier. Basically you need a patched Linux kernel. - Real-time GC will assuredly lower overall throughput, and increase complexity. At the very least you need either a read barrier or a write barrier. I don't think anyone uses read barriers normally; write barriers are often used for generational GC, but I *think* the write barriers used for real-time GC involve more work than those for generational GC. - Adding a read or write barrier to a language implementation that doesn't already have them means you need to guard every single place where someone reads or writes what might be a pointer. This is easy to screw up. - Several real-time GC algorithms punt on moving objects, and are thus vulnerable to memory fragmentation. This obviously reduces the robustness of the runtime system. (Others use stop-the-world to do compaction, and thus are not real-time.)

waterhouse 10y ago

Some answers that come to mind: - Azul's GC requires cooperation from the kernel; I believe it specifically uses the virtual memory mechanism to implement a read barrier. Basically you need a patched Linux kernel. - Real-time GC will assuredly lower overall throughput, and increase complexity. At the very least you need either a read barrier or a write barrier. I don't think anyone uses read barriers normally; write barriers are often used for generational GC, but I *think* the write barriers used for real-time GC involve more work than those for generational GC. - Adding a read or write barrier to a language implementation that doesn't already have them means you need to guard every single place where someone reads or writes what might be a pointer. This is easy to screw up. - Several real-time GC algorithms punt on moving objects, and are thus vulnerable to memory fragmentation. This obviously reduces the robustness of the runtime system. (Others use stop-the-world to do compaction, and thus are not real-time.)