Smart pointers instead of GC?

[Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com>]

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?