> Due to the unfortunate C ABI, a fast copying collector is not really doable. One cannot track all the internal and external pointers. Well, one could, but has

> Due to the unfortunate C ABI, a fast copying collector is not really doable. One cannot track all the internal and external pointers. Well, one could, but has to pessimize the locals on every external pointer reference. Note that a GC does not have to be copying in order to be fast. What makes or breaks performance for most GCs is whether they are generational [1]. A non-generational copying GC will generally not have impressive performance, either. A copying GC allows you to have a bump allocator, but a non-copying generational GC can still have a pool allocator. Using a pool allocator does not share all of the benefits of a bump allocator (such as good memory locality for successive allocations), but still allows for very fast allocations for small objects. Also, mostly copying GCs are still an option even if you scan roots conservatively. See Joel Bartlett's mostly copying GC from the late 1980s. [1] Not counting non-tracing approaches, such as deferred reference counting, which achieve similar goals through other means.