proposal: GC.*partial*collect(Duration maxPauseTime, Duration maxCollectionTime)

rikki cattermole rikki at cattermole.co.nz
Tue May 19 05:59:17 UTC 2020


On 19/05/2020 5:42 PM, mw wrote:
> Hi,
> 
> I'm new to D(2). Have spent past week reading a lot about other people's 
> articles on D, pros & cons, etc. One of the things people have talked 
> about alot is the slow gc, esp. in a multi-threaded env, real-time 
> system, or interactive games dev.
> 
> OK, gc has its problem, but most programs cannot do without it (nogc 
> phobos not there yet). Actually the programmer knows best *when & where* 
> in his/her program, s/he can manually call gc.collect() to free 
> resource. But currently gc.collect() will do a full collection:
> 
> https://dlang.org/library/core/memory/gc.collect.html
> 
> which is unpredictable how long it will take. In real-time systems this 
> is not acceptable. The programmer will still hesitate to call gc.collect().

There are two types of real time systems.

Hard: you will not be using the GC, like Weka you will roll your own 
libraries.
Soft: see dplug, you disable the GC and collect as appropriate while 
minimizing what memory is allocated via the GC.

Games full into the soft territory, although depending on the game, 
buffers and custom allocators can offset this significantly to the point 
you can enable the GC full time and not have to worry about it.

> So we want a predictable gc: I just had a simple idea to improve the 
> usability of current gc implementation (probably with minimal code 
> change). My idea is add parameters to the gc.collect():

Partial collection can be implemented using a strategy such as 
tri-color, and do a maximum amount of time on each iteration of scanning.

Alternatively you can use fork'ing and snapshots (Windows) which make it 
an entirely asynchronous process.

We know what can be done, just nobody wants to do the work.
Our GC implementation isn't all that friendly even though it now 
supports fork'ing and can be precise.

The GC performance isn't all that bad in D, as long as you minimize 
garbage, hence not much effort goes towards it. For most people you 
won't notice that it even runs.


More information about the Digitalmars-d mailing list