The D language is currently heading towards deterministic and safe memory management, making it possible to avoid the GC overall, hence further work on GC impro

The D language is currently heading towards deterministic and safe memory management, making it possible to avoid the GC overall, hence further work on GC improvements was deprioritized. http://dlang.org/blog/2017/06/16/life-in-the-fast-lane/ http://dlang.org/blog/2017/06/16/life-in-the-fast-lane/ The problems are known and indeed a full rewrite on this ancient GC would be in order. Since D 2.072.0 it's possible to link and use different GCs, so a faster one could be written as an external library which would be a very welcome effort. https://dlang.org/changelog/2.072.0.html#gc-runtimeswitch-added https://dlang.org/changelog/2.072.0.html#gc-runtimeswitch-ad... I'd be interested in experimenting with a Connectivity-Based GC (https://www.cs.purdue.edu/homes/hosking/690M/cbgc.pdf https://www.cs.purdue.edu/homes/hosking/690M/cbgc.pdf), leveraging type information to do partial collections. Write barriers come with a performance penalty (~3-5%) that we don't want to impose on people using deterministic memory management, but most GCs capable of performing partial collections, e.g. generational GCs, do require write barriers, Connectivity-Based GCs do not. For the time being the pragmatic advise is to replace major sources of GC allocations with deterministic memory management when the GC heap grows too big (~1GB) and performance becomes a problem. So far this hasn't prevented various people from writing extremely fast D programs.