The GC (agian)

[H. S. Teoh]

On Sat, Nov 20, 2021 at 01:48:44PM +0000, JG via Digitalmars-d wrote:
> Hi,
> 
> Having been hanging around these forums for a few years now (and
> writing software in D during that time) I have noticed that there are
> quite often disagreements about the GC.
> 
> I was thinking about this and wondered if some of these problems could
> be possibly eliminated by making the GC more configurable. For
> instance one might envisage that one can with some nice API be able do
> things like:
> (a) specify exactly when the GC should do a stop the world mark and
> sweep (not when it feels like it when it needs to allocate memory and
> perhaps through an API more pleasant than the current, enable and
> disable mechanism);

What's wrong with the current mechanism?  In applications where I need
better control over collections, I've used GC.disable and GC.collect quite
effectively.


> (b) specify that the next allocations should be done into a
> preallocated block (which it could be asked to drop later, without
> marking and sweeping).

My impression was that this was one of the goals of
std.experimental.allocator.


> I guess my real question is more is there someway that the GC be
> modified so that on the one hand it works exactly like it does now (if
> no options are set) and on the other hand can be configured so that it
> is close enough to manual memory allocation that say someone building
> a game wouldn't find it gets in there way.

Just slap @nogc on main() (or whatever function is the entry point into
your critical section where you don't want any GC activity) and you can
already do this today.


> The main point would be to allow someone to fully use D (with some
> extra house-keeping they have to do) but avoid unpredictable GC
> pauses.

In one of my projects I call GC.disable at the start, and have a manual
iteration counter that invokes GC.collect at strategic points.  It works
pretty well.  In this particular context the reason I wanted to do this
was to control the frequency of GC collections, because I found that
collections ran too often.  So I ran collections on my own schedule
instead of the default.  The same strategy could also be used to run
collections only at specific points in your code, so that pauses are
predictable.


[...]
> [In case it is of interest to anyone, personally I like having a GC,
> although there are a few instances where it would be nice to have a
> bit more flexibility.]

Me too.  And so far I've found that calling GC.disable and running
GC.collect on my own schedule has worked well enough for me. (Note that
GC.disable merely disables automatic collection; allocations will still
go through the GC and collections will still run when you manually
invoke GC.collect.)


T

-- 
An imaginary friend squared is a real enemy.