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

Internet Message Format | 1992-08-16 | 5.0 KB

Path: sparky!uunet!ogicse!mintaka.lcs.mit.edu!ai-lab!life.ai.mit.edu!tmb
From: [e-mail] (Thomas M. Breuel)
Newsgroups: comp.lang.c++
Subject: Re: Garbage Collection for C++
Message-ID: <[e-mail]>
Date: 16 Aug 92 20:49:40 GMT
Article-I.D.: arolla.TMB.92Aug16164940
References: <[e-mail]> <[e-mail]>
    <[e-mail]>
    <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
    Perceptive)
Lines: 95
In-reply-to: [e-mail]'s message of 15 Aug 92 02:56:13 GMT

In article <[e-mail]> [e-mail] (Bob Cannard @ PCB x5565) writes:

   In a *fair* comparison between an optimised GC and an optimised
   manual scheme, the manual scheme will win if the decision of when and what to
   delete can be made at compile time. In a situation where the decision can only
   be made at run time, the GC will win. This is one reason why I want both
   mechanisms.

OK, let's go through this again. You propose that there be "non-GC
pointers" in C++. I don't see how this helps speed.

 (1) The memory pointed to by non-GC pointers still needs to
     be examined by the garbage collector.

 (2) With a conservative GC, there is no tagging/untagging cost
     associated with GC pointers; GC pointers are just as efficient
     and simple as non-GC pointers.

 (3) Even in a system with (conservative) GC, you can still return
     memory to the system using some form of unsafe "free" or "delete"
     (e.g., as provided by Boehm's collector).

 (4) Why ever would you _not_ want to call a GC if you run out
     of "non-GC memory"? The alternative is a program crash.

It seems to me that the facilities you really want are: (a) an "free"
function (which would be just as unsafe as it is now), and (b) a
version of the "new" operator that says "this memory block doesn't
contain any pointers". Not surprisingly, these functions are offered
by conservative GC's for C/C++.

Beyond these two facilities, I simply fail to see the need to divide
memory or pointers "garbage collected" and "not garbage collected" on
the basis of efficiency.

The only need to distinguish the two kinds of pointers would arise (as
it does in Modula-3) if you additionally introduce Lisp-like runtime
type and range information in an effort to make your language safer.
Frankly, much as I prefer such systems, I can't see this happening in
C++, and the issues involved go far beyond GC.

Altogether, I think there is very little that actually needs to be
done to the C++ language to support conservative GC, beyond adding few
more standardized hooks.

The real issues, as I seem them, are not to divide non-GC from GC
pointers, but to deal with questions of finalization. One particularly
important question to me is whether the existing "delete" in a GC
implementation should by default not deallocate memory (just call the
destructor), or whether it should correspond to the "unsafe delete"
mentioned above.

Implementors, of course, have a little more work cut out for them,
like slight modifications to over-eager optimizers.

                    Thomas.

PS:

   |> What "hits"? In all the cases that I have looked at, the GC overhead
   |> has been _smaller_ than the overhead of explicit memory management in
   |> C++. Now, maybe my sample of programs is biased, but if you claim that
   |> there are "hits", please state either whether you have concrete
   |> evidence that there are, or whether your statement is just religious
   |> belief. Your vague statements might easily turn into gospel truth.
   |>
   |> Based on my experience, I would turn your statement around and say:
   |> "those of us who want GC shouldn't have to suffer the inefficiencies
   |> of not having it".

   It's practical experience. A question for you: have you ever used a
   custom-made, tailored new/delete (or malloc/free), instead of the ones provided
   as standard?

I have written custom-made, tailored new/delete, not just for C++, but
also for languages with GC. Yes, indeed, practically all the tricks
you play with memory management in C/C++ also work in fully garbage
collected environments.

PPS:

   There are plenty of reasons whey GC is genuinely more efficient
   than manual: it allows better-designed data structures, it
   eliminates the need to copy data which plagues large systems using
   manual recycling, and it reduces development and maintenance costs.
   But the idea that GC is inherently faster than manual is bogus.

As I stated above (believe it or not), the same tricks you play in
C/C++ for memory management right now can also be applied in a GC'd
context, so GC is at least not inherently slower than manual storage
management.

Now, it turns out that in some cases, GC is actually "guaranteed" to
be faster, in the sense that it can combine very low-cost allocation
with no overhead deallocation (that is, 0 machine cycles per word).