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