More radical ideas about gc and reference counting

[via Digitalmars-d]

On Sunday, 11 May 2014 at 18:18:41 UTC, Rainer Schuetze wrote:
> For a reasonable GC I currently see 2 possible directions:
>
> 1. Use a scheme that takes a snapshot of the heap, stack and 
> registers at the moment of collection and do the actual 
> collection in another thread/process while the application can 
> continue to run. This is the way Leandro Lucarellas concurrent 
> GC works (http://dconf.org/2013/talks/lucarella.html), but it 
> relies on "fork" that doesn't exist on every OS/architecture. A 
> manual copy of the memory won't scale to very large memory, 
> though it might be compressed to possible pointers. Worst case 
> it will need twice as much memory as the current heap.
>
> It would be very interesting how far we can push this model on 
> the supported platforms.
>
> 2. Change the compiler to emit (library defined) write barriers 
> for modifications of (possible) pointers. This will allow to 
> experiment with more sophisticated GC algorithms (if the write 
> barrier is written in D, we might also need pointers without 
> barriers to implement it). I know Walter is against this, and I 
> am also not sure if this adds acceptable overhead, but we don't 
> have proof of the opposite, too.
>
> As we all know, the usual eager reference counting with atomic 
> operations is not memory-safe, so my current favorite is 
> "concurrent buffered reference counting" (see chapter 18.2/3 
> "The garbage collection handbook" by Richard Jones et al): 
> reference count modifications are not performed directly by the 
> write barrier, but it just logs the operation into a thread 
> local buffer. This is then processed by a collector thread 
> which also detects cycles (only on candidates which had their 
> reference count decreased during the last cycle). Except for 
> very large reference chains this scales with the number of 
> executed pointer modifications and not with the heap size.

I'm surprised that you didn't include:

3. Thread-local GC, isolated zones (restricting where references 
to objects of a particular heap can be placed), exempting certain 
threads from GC completely, ...