Russ Lewis wrote in message <3B9878CF.F6931E34@deming-os.org>...
>Walter wrote:
>> It would not be too practical to scan all of memory for references to
just
>> one object - you might as well do a full gc.
>> The purpose of a specific delete is:
>> 1) Get the destructor for the object run right now
>> 2) Aid the GC
>In a subjective sense, how expensive is the GC routine, and how much
backlog is
>likely to happen?  I'm not convinced that it's a bad thing to just force a complete run of the GC when you need to guarantee cleanup right now.


It's a regular GC - nothing special. The first version will be adequate, but not great. Later versions will be generational, and much less overhead. D is friendly to a GC, so it should work much better than one for C++.

Hans Boehm has some great papers on how GC works. People write books about it - more than possible in a simple posting! You can find out a lot by Google'ing on "garbage collection". -Walter

Russ Lewis wrote in message <3B98E141.2AB2AEEC@deming-os.org>...
>Walter wrote:
>
>> It would not be too practical to scan all of memory for references to
just
>> one object - you might as well do a full gc.
>>
>> The purpose of a specific delete is:
>>
>> 1) Get the destructor for the object run right now
>> 2) Aid the GC
>
>I have no experience with (implementations of) GC, so I don't know how it works.  Maybe we could have a few details?  My assumptions were based on
the
>thought that the algorithm would work something like this:
>
>* Maintain a reference count on each GC-able object.
>* When assigning a pointer (or array), first take the old value and put it
in a
>list of objects to consider for the GC.  You normally would only do this
when
>the reference count goes to 0, but you have to consider circular references
that
>are not accessible from the main tree.
>* When the GC runs, it just iterates down the list of recently released
objects;
>when it finds one with 0 references (or with only circular references), it automatically calls the destructor.
>
>However, you talk about "scanning" which sounds like a different algorithm altogether, so I'm stumped...  I'm hoping you don't mean that you're
scanning
>through all of memory for pointers to an object (eek!)
>

I wonder if it would be possible to have a compiler switch choose between GC methods... scanning or refcounting.  In any program, one may be more efficient than the other... probably open up a whole can of worms when linking to separately-compiled libs though.  I'm not even sure the compiler could do the refcounting method properly since it'd have to detect taking the address of a member of a class and inc the class refcount... <shiver>

But the thing about GC that scares the bejeezus about game programmers is that GC might happen in the middle of your game, causing a 3-second delay in the gameplay.  At least we should be able to make sure the GC does *not* run by, say, not performing any allocations.

Sean

"Michael Gaskins" <mbgaski@clemson.edu> wrote in message news:9li8re$npb$1@digitaldaemon.com...
> Actually I think it would be be very benificial if we could just have a function call (forgive me if it's called something different in D, I've
just
> started looking into the project) to force the garbage collector to run. This way the programmer could periodically "clean out the memory" at oppurtune times in the programs execution cycle.  The automatic GC
routines
> should still be implemented, but it would be nice to also be able to initiate the process manually.

You can temporarilly disable collection.

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:9r3g5r$ba0$1@digitaldaemon.com...
> I wonder if it would be possible to have a compiler switch choose between
GC
> methods... scanning or refcounting.  In any program, one may be more efficient than the other... probably open up a whole can of worms when linking to separately-compiled libs though.  I'm not even sure the
compiler
> could do the refcounting method properly since it'd have to detect taking the address of a member of a class and inc the class refcount... <shiver>
>
> But the thing about GC that scares the bejeezus about game programmers is that GC might happen in the middle of your game, causing a 3-second delay
in
> the gameplay.  At least we should be able to make sure the GC does *not*
run
> by, say, not performing any allocations.
>
> Sean
>
> "Michael Gaskins" <mbgaski@clemson.edu> wrote in message news:9li8re$npb$1@digitaldaemon.com...
> > Actually I think it would be be very benificial if we could just have a function call (forgive me if it's called something different in D, I've
> just
> > started looking into the project) to force the garbage collector to run. This way the programmer could periodically "clean out the memory" at oppurtune times in the programs execution cycle.  The automatic GC
> routines
> > should still be implemented, but it would be nice to also be able to initiate the process manually.
>
>
>