GC, the simple solution

[Dave]

John Reimer wrote:
> David Gileadi wrote:
>> Walter Bright wrote:
>>> Jeff Parsons wrote:
>>>> My _only_ significant beef with D so far as been the unbound time 
>>>> for a garbage collection; therefore, if an incremental garbage 
>>>> collector built into D could guarantee me a set maximum time would 
>>>> be taken for each garbage collection (which I would manually induce 
>>>> as often as possible) then unless the efficiency hit is TERRIBLE I 
>>>> would be all over it.
>>>
>>> If you're looking for a *guarantee*, then you cannot even use 
>>> malloc(). Malloc has unbounded time, and is not predictable.
>>
>> It seems that a fairly common desire is to use D for writing games. 
>> Games don't typically have hard real-time requirements, but it also 
>> doesn't look good if your screen freezes for a second or two in the 
>> middle of play.
>>
>> This is an area where an incremental collector or some kind of 
>> reference counting solution would be handy, since (especially in large 
>> programs) it would be difficult to avoid using garbage collected 
>> code.  I realize that the programmer has the responsibility to manage 
>> memory intelligently, but it would be nice to not avoid using GC code 
>> entirely.  As others have stated, it would even be worth giving up 
>> some overall performance to gain a smooth playing experience.
> 
> 
> Didn't Walter point out that that, in the current gc implementation, you 
> just have to be conscientious about when you call 'new' (which appears 
> to initiate a collect) if you want to avoid the gc initiated pauses.
> 

Yea, in the current GC, allocation is the only thing that may implicitly 
initiate a collection.

> So in game programming, I assume it's just a matter of good organization 
> and planning.  You make sure you allocate sufficient memory ahead of 
> time and avoid using 'new' in any location that would cause an ugly 
> pause in the game.  Furthermore, you might choose appropriate times for 
> when you want to call a full collect manually.
> 

And D's easy array slicing along with array operations (like 
re-initializing an array with 'arr[] = 0;') makes the code to use 
pre-allocated buffers a lot easier to write too.

> As I see it, the obligation for careful design doesn't disappear when a 
> gc is in place.  It certainly makes life easier in many ways.  But one 
> still has to be aware of the gc shortcomings and adapt to the situation. 
>  I still see it as a tremendous improvement over having to clean up 
> after every memory allocation you make (C/C++).
> 
> In short, using a gc doesn't mean you don't have to do your homework. :)
> 
> -JJR