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