Re: If GC is the solution, then what is the problem?
Victor Bazarov wrote:
Gene Bushuyev wrote:
I don't think the fact that memory disposition can be done
in a separate thread is peculiar to GC, both GC and non-GC
programs can have exactly the same deallocation mechanism.
There is no reason why memory allocators can't delay the
actual deallocation of deleted memory and then do it in a
separate thread. It's not detectible on the program level
what memory allocator did with the deleted memory. And
Standard nowhere requires that delete should physically do
anything in particular with memory, the only thing it
guarantees the calling of the destructors, which GC
doesn't do. So in that regard, the previous poster is
absolutely correct.
I must be considering wrong definition of GC. I thought that
the whole idea of a separate mechanim (running independently
of the main program at least in some sense) is very important.
If [de]allocators were in fact delaying deallocation and/or
deferring it to another thread, it, IMHO, would be _exactly_
what *I* consider GC. I must be wrong then.
I don't think so. Putting it on a C level: if you have to call
free(), it's not garbage collection. Many, many years ago, I
wrote an implementation of free which simply posted the freed
block to a specialized process; that process woke up from time
to time and "collected". But it only collected blocks which the
programmer had specifically requested be collected. That's not
garbage collection.
Similarly, garbage collectors can, and do, run in single
threaded processes. I'm pretty sure that the Boehm collector
can be configured to do so, for example.
--
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]