As I'm planning on writing some kind of game in D, the issue of GC speed is coming up.  The manual says that the time it takes for the GC to run is unbounded; thus, it's best to do as much as you can for setup, before the speed-critical game loop.  What I'm wondering, however, is how I can avoid having the GC perform a fullCollect() as much as possible, as the game will nonetheless be creating and destroying objects constantly throughout the loop.

I'm wondering if the GC performs generational (smaller) collections automatically.  If so, then I suppose I don't have much to worry about, as the fullCollect() will probably be run very seldom, if ever.  If not, well.. I guess that means I have to call it.  And I don't know when to.

Jarrett Billingsley wrote:
> As I'm planning on writing some kind of game in D, the issue of GC speed is coming up.  The manual says that the time it takes for the GC to run is unbounded; thus, it's best to do as much as you can for setup, before the speed-critical game loop.  What I'm wondering, however, is how I can avoid having the GC perform a fullCollect() as much as possible, as the game will nonetheless be creating and destroying objects constantly throughout the loop.

<my2cents>
In my programs, I call gc.fullCollect() after the setup code but at realtime, I try not to allocate anything - that's a general rule for any programming language. In the game industry ppl will generally tell you to use custom memory allocators, mem pools and such because if the gc stalls won't kill you, memory fragmentation will. If the game is creating and destroying objects all the time, you might consider not really destroying them, but putting them back onto a "free list" instead. Marking them as unused but not deleting. Then when a new object is requested, you'd take it from the list again without dynamically allocating any memory.
</my2cents>

> If the game is creating and destroying objects all the time, you might consider not really destroying them, but putting them back onto a "free list" instead. Marking them as unused but not deleting. Then when a new object is requested, you'd take it from the list again without dynamically allocating any memory.

Free lists sound like a good idea.  And inheriting from a template would probably make them very easy to implement indeed.  Thank you :)

Though the question still stands - does the GC in fact run generational collection cycles throughout the program, or is that function there entirely for our own use?

In article <d0d9ps$1hv8$1@digitaldaemon.com>, Jarrett Billingsley says...
>
>As I'm planning on writing some kind of game in D, the issue of GC speed is coming up.  The manual says that the time it takes for the GC to run is unbounded; thus, it's best to do as much as you can for setup, before the speed-critical game loop.  What I'm wondering, however, is how I can avoid having the GC perform a fullCollect() as much as possible, as the game will nonetheless be creating and destroying objects constantly throughout the loop.
>
>I'm wondering if the GC performs generational (smaller) collections automatically.  If so, then I suppose I don't have much to worry about, as the fullCollect() will probably be run very seldom, if ever.  If not, well.. I guess that means I have to call it.  And I don't know when to.

The GC in dmd is not generational. When it collects it collects everything. I'm
not sure what GC gdc uses. I think Sean is working on an interface to plug in
different GC's but I'm not sure how far along that is. A while ago I hacked up
phobos to use a generational Boehm GC but it wasn't thread-safe. It's not that
hard to get another GC basically working since all you need to do is replace
some calls from internal/gc/gc.d into internal/gc/gcx.d, IIRC.
-Ben

> The GC in dmd is not generational.

Ah.  Then I take it these functions in std. gc are just stubs?

/***********************************
 * Run a generational garbage collection cycle.
 * Takes less time than a fullcollect(), but isn't
 * as effective.
 */

void genCollect();
void genCollectNoStack();

In article <d0duck$21ob$1@digitaldaemon.com>, Jarrett Billingsley says...
>
>> The GC in dmd is not generational.
>
>Ah.  Then I take it these functions in std. gc are just stubs?
>
>/***********************************
> * Run a generational garbage collection cycle.
> * Takes less time than a fullcollect(), but isn't
> * as effective.
> */
>
>void genCollect();
>void genCollectNoStack();
>
>

The code for genCollect in internal/gc/gcx.d
calls "fullcollectshell", which means it does a full collection instead of a
no-op.
Or maybe the way to say it is that dmd is a generational collector with 1
generation :-)

> The code for genCollect in internal/gc/gcx.d
> calls "fullcollectshell", which means it does a full collection instead of
> a
> no-op.
> Or maybe the way to say it is that dmd is a generational collector with 1
> generation :-)

Haha :)  I see now.

"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:d0dftv$1na7$1@digitaldaemon.com...
> Though the question still stands - does the GC in fact run generational collection cycles throughout the program, or is that function there
entirely
> for our own use?

It currently does not, however, D's design will allow for a future generational collector to be retrofitted. Also, the gc will only run a collect during an allocation. If your program isn't allocating, it won't be collecting.

Furthermore, malloc() also has unbounded time.

> It currently does not, however, D's design will allow for a future
> generational collector to be retrofitted. Also, the gc will only run a
> collect during an allocation. If your program isn't allocating, it won't
> be
> collecting.

Ah, thanks for that :)

"h3r3tic" <foo@bar.baz> wrote in message news:d0ddqc$1ljj$1@digitaldaemon.com...
> <my2cents>
> In my programs, I call gc.fullCollect() after the setup code but at
> realtime, I try not to allocate anything - that's a general rule for any
> programming language. In the game industry ppl will generally tell you to
> use custom memory allocators, mem pools and such because if the gc stalls
> won't kill you, memory fragmentation will. If the game is creating and
> destroying objects all the time, you might consider not really destroying
> them, but putting them back onto a "free list" instead. Marking them as
> unused but not deleting. Then when a new object is requested, you'd take
> it from the list again without dynamically allocating any memory.
> </my2cents>

I assumed this was written with a hint of irony, but no one else seemed to bite.  (-:  So you start with a GC, then you hoard memory to save it from the GC and create a "free list."  Then, you are very careful not to allocate anything so the GC won't kick in.  This effectively creates a non-GC, "old school" program in a GC language by having the discipline to work around the GC (tricky in groups of programmer's at various levels of experience).  You end up with the overhead without the benefits.

I realize you have to do this since there are no guarantees on timings, but certainly some <grins> and smileys are appropriate?

It sounds like the answer should be to avoid D and use C or C++!  Think about it!  Any of the features you think are better in D are probably tied to the GC (such as slices).  As long as you have to use discipline, stick to being disciplined in C++ and not using too many operator overloads or lattice-style multiple inheritance.

I thought D did have a delete operator, and I assumed this would immediately do the deletion instead of just ignoring the call.  But I haven't seen any one mention this, so maybe not.