On Monday, 2 June 2014 at 19:04:05 UTC, Sean Kelly wrote:
What I did at the time I created the CDGC branch was diff our GC now vs. the code from when Druntime was created (the SVN repo on dsource.org). It shouldn't be more than a bunch of busywork for someone to figure out which changes are relevant and apply them, but it's busywork no one has wanted to do yet.
I think the plan was to incrementally evolve the GC towards the CDGC. Probably the 'right' thing to do but it requires more patience (and a deeper understanding of the GC code). Judging by the commit history the effort does appear to have slowed down. Perhaps there's activity taking place that's not visible on github.
I'm personally really interested in the progress of this effort - in particular removing the global lock on allocations. My primary experience is with Java, which is far more profligate with object allocation than D, but single-threaded object allocation was one of the biggest performance killers for certain types of application. We had 4-cpu servers (back when that was a lot) with 1 red-hot processor and 3 idle ones due to contention on memory allocation.
I'd also like to echo Leandro regarding configurable GC. There is no one-size-fits-all for applications. Interactive applications favour low-latency over throughput, while a long-running batch process wants throughput and doesn't care so much about long pauses. Being able to tune Java's GC at runtime allowed me to turn a 90 minute batch process into 12 minutes with zero code changes. A real lifesaver.
