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