[gclist] What to say about GC.

[Giuliano Carlini]

=TL2=Tom Lord() wrote:
> I *am* arguing that collectors are hard to use well in complex
> applications and are themselves a source of subtle errors.  I am
> arguing that when we "sell" GC as a simpler technique than the
> alternatives we are being misleading...

I've got to disagree. GC is vastly simpler than explicit deallocation.
Although on rare occasions it can be the source of subtle bugs.

While much of what you say is true, it must be considered with respect to
the following fact: Debugging memory issues when using a GC requires about
1% of the time of doing it with explicit deallocation.

I believe that Richard's book blurb is much closer to the truth than
your comparison of GC vs. manual deallocation.

> The false idea that unneeded objects are automatically freed
I've not heard this claim. I have heard the claim that "precise" GC's
reclaim all unreachable objects. "Conservative" GC propoenents don't
even go that far. Both claim that this "fixes" one of the most common
bugs in manually deallocated programs: forgetting to deallocate. And
that as a by product they fix other bugs: double free's and dangling
pointers. And that a GC'd programs can have vastly better designs; no
need to track ownership. And a host of other benefits. But I haven't
heard the claim that all unneeded objects are deallocated.

While I'm sure that someone, somewhere, has misrepresented things and
stated that all unneeded objects are deallocated, most advocates are
quite clear about what GC does.

> Collectors require programmers to manually maintain
> the invariant that all objects which should be freed must not be
> reachable by any chain of references

First very few objects MUST be free'd. There invariant we care about is:
	Resources must not be exhausted.
While it is possible for this to be violated by a GC'd program, it happens
much less often than in a manually deallocated program.

Second, it is vastly easier to maintain this invariant, than the invariant
of a manually deallocated program:
	Every object must be deallocated by an explicit action before a
	resource is exhausted and after every other client of the object
	has ceased using it.
This is so because the GC invariant requires only local knowlege. Each client
of an object need only clear its reference to the object when it is done with it.
Manual deallocation requires knowledge of all other clients.

> The sometimes false idea, that only the GC implementor has to worry
> about GC internals, ...
> But the idea is misleading for programmers who use GC with lower level
> languages like C or C++
As the author of a GC for C/C++, I must disagree.

> who extend an existing high-level language
> implementation with new built-in primitives or types
Hardly a typical program. If you modify a language you must expect to deal
with the repercussions in the runtime. In addition to the GC you must also
deal with I/O of your new primitive type, and a host of other issues.

> or who must port
> a GC beyond the platforms supported by its author.
The same is true of memory managers with manual deallocation. If you port
to a platform not supported by the memory manager's author, you'll have to
port the memory manager.

> But in long-running or otherwise critical programs, programmers using
> GC have to think about and program for memory management just as
> carefully as when using malloc/free. 
I've worked on one of these. I did a "skunk works" and dropped my GC into it.
As is the case with any skunk works, I couldn't spend much time on it. I spent 
much less time than the sanctioned effort to find and fix all leaks.
The system ran vastly longer with my GC than without it. It came down because
it was told to shut down, not because it ran out of resources. Too bad management
was so frightened of GC that they ditched it. They're still frittering away scarce
schedule time on fixing leaks.

I'm curious, do you think that it takes as long to debug the memory errors in
a program using GC as one using manual deallocation?

g