Analysis of D GC

[Vladimir Panteleev via Digitalmars-d]

On Monday, 19 June 2017 at 22:35:42 UTC, Dmitry Olshansky wrote:
> My take on D's GC problem, also spoiler - I'm going to build a 
> new one soonish.

Looks like I'm not the only one itching to have a go at D's GC :) 
This will very likely be my DConf 2018 project. However, I have 
slightly different plans:

- The GC should be usable as a library (mainly to facilitate 
testing).
- Support for all platforms D already supports from the start.
- Use design-by-introspection when applicable and 
design-by-contract elsewhere to split the design into modular 
components.
- Make the GC configurable (using policies) and swappable at 
runtime. (No need to get clever, just treat previous 
implementation's pools as opaque void[]).
- Support concurrency on Windows via anonymous memory-mapped 
files.
- Support generational collection using write barriers 
implemented through memory protection.
- Integrate existing GC work - don't reinvent the wheel.
- More, much more debugging facilities! Integrate Diamond and 
Valgrind interoperability.
- Gray-marking and compacting.
- Still need to look at immix.

I have some past work that I'd like to integrate (an experimental 
generational GC I wrote like 9 years ago for D1, Diamond, and 
Valgrind integration I have in a fork somewhere.)