NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/lang/cplus/12471

Text File | 1992-08-17 | 3.6 KB | 68 lines

Newsgroups: comp.lang.c++
Path: sparky!uunet!microsoft!hexnut!jimad
From: [e-mail] (Jim Adcock)
Subject: Re: Garbage Collection for C++
Message-ID: <[e-mail]>
Date: 18 Aug 92 01:02:46 GMT
Organization: Microsoft Corporation
References: <[e-mail]| <[e-mail]> <[e-mail]>
Lines: 57

In article <[e-mail]| [e-mail] (Bob Cannard @ PCB x5565) writes:
|In particular, in my own application - which will eventually be quite a big
|program - I only want GC for certain classes, where the problem of determining
|when an object must be deleted has no sensible solution other than GC. Yet
|performance (both run time and memory use) carries a high premium, so I can't
|afford to have GC everywhere.

Other way around.  If you need the smallest code, smallest working set, and
the fastest code, you cannot afford not to use GC almost everywhere.  The
standard "manual" memory management techniques of C++ come at a very high cost.

|Exactly what I mean. If the GC has to scan the whole stack (and all the
|statics and globals while we're at it), it's doing too much work. The
|reference-count solution is more efficient than that, because the need
|for GC is restricted to a small but important part of the program. The
|idea of languages like C++ is to give the compiler the information it
|needs to get the best performance out of the resulting code.

This of course depends on what one is doing, but in my experience stack
scanning GC techniques are many times faster than reference counting.

|Quite fast compared to what? In previous projects I've been involved with
|(using C rather than C++) "malloc" and "free" were found to be too slow,
|and were replaced by custom ones. I want this GC to clip along as fast as
|possible.

Compare custom allocators/deallocators costs to generational GC techniques,
where the typical "allocation" cost is to increment one pointer by n bytes,
and the typical "deallocation" cost is zero.  Further, a good compiler can
lump together many allocations into one pointer bump, making the allocation
cost analogous to "C" stack allocation cost.  IE typical generational allocation
deallocation is as cheap as stack allocation.

|This is why special GC pointers have been proposed in the first place.
|If GC is in use, the programmer must accept the "no clever tricks"
|constraint, which includes not passing pointers around disguised as
|integers. And once that constraint is accepted, there may be no good
|reason for not having compaction. My earlier post on this subject
|contained some suggestions that would make the combination of GC and
|existing libraries practical.

Moveable objects, as occur for example in compaction, are necessary anyway
to support persistence -- once freezing and thawing an object your object is
in a new location -- therefore there's no excuse not to do what's necessary
for compaction.  Further, moveable objects are necessary in general to maintain
good working sets.

|This would accord with existing C++ philosophy, but I don't see how
|you could make a GC that's immune to dangling pointers. Anyone out
|there know otherwise?

There's lots of answers to this question.  I'll quote the answer that most
OOPLs implement: "Don't use pointers -- use references instead."  In the
C++ case we're already stuck with pointers, so the answer then becomes
"make pointers [as we now know them] an anachronism which is only used within
 'unsafe' modules."  See Modula-3 for an example of this approach.