On Tuesday, 4 February 2014 at 13:03:24 UTC, Araq wrote:
1. D doesn't restrict pointers, interior pointers abound especially thanks to the design of slices. Interior pointers are a problem for every high performance GC algorithm I'm aware of.
Interior pointers can always be replaced with a pointer + offset, so in the case of slices it can be resolved at the implementation level at some memory trade off? In the case of internal pointers elsewhere you would have to introduce a new type "pointer+offset", but that would break C-interop.
2. D's design doesn't easily allow for read or write barriers in general. You simply cannot make a GC behave without barriers.
It is difficult without affecting the C-compatible semantics. There are some interesting options on 64 bit CPUs where you in theory can do compaction to a fresh region and put hardware traps on the old region, rewriting pointers trying to access the old region or converting misses to exceptions on the fly (assuming you can have a barrier/isolate that prevents comparison of old/new pointers).
Another obvious solution is thread local GC for thread local memory or segmented GC (collect for only a specific pool, refuse pointers to escape the pool, and put a lock on that pool during GC).
That's just bullshit. The opposite is true: Of the big players D is easily the language that is most hostile to an efficient GC implementation.
Because C is hostile to GC. So you either forsake C-compatibility or stay inefficient?
