Analysis of D GC

[Ecstatic Coder via Digitalmars-d]

> My take on D's GC problem, also spoiler - I'm going to build a 
> new one soonish.
>
> http://olshansky.me/gc/runtime/dlang/2017/06/14/inside-d-gc.html
>
> ---
> Dmitry Olshansky

Many thanks for your efforts Dmitry :)

May I ask you if you plan to make a soft real-time GC similar to 
the one implemented in the Nim language ?

https://nim-lang.org/docs/gc.html
https://nim-lang.org/docs/intern.html#debugging-nim-s-memory-management

What is great about it is that we can call it regularly to 
collect memory a bit at a time, giving it a maximum delay for 
this operation.

Being able to manually specify the maximum GC delay is what makes 
Nim compatible with game development, as collections can be made 
iteratively, and on a per-thread basis.

In the worst case, we know that just one of the application 
threads will be delayed for a few milliseconds between two frame 
renderings, which is generally acceptable for games and other 
similar applications.

Moreover this opens to opportunity to call the GC only in the 
main menu or the pause menu for instance, but not during actual 
gameplay, so that even these few lost milliseconds will always 
remain unnoticed.

This is probably why Nim's author was once paid to wrap an open 
source game engine (Urho3D), and improve the language's native 
compatibility with C++ libraries.

https://forum.nim-lang.org/t/870