Some answers that come to mind: - Azul's GC requires cooperation from the kernel; I believe it specifically uses the virtual memory mechanism to implemen

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.)