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

Internet Message Format | 1992-08-17 | 3.7 KB

Path: sparky!uunet!synaptx!synaptics.com!daveg
From: [e-mail] (Dave Gillespie)
Newsgroups: comp.lang.c++
Subject: Re: Garbage Collection for C++
Message-ID: <[e-mail]>
Date: 18 Aug 92 05:43:59 GMT
References: <[e-mail]>
    <[e-mail]>
    <[e-mail]>
    <[e-mail]>
Sender: [e-mail]
Organization: Synaptics, Inc., San Jose, CA
Lines: 71
In-reply-to: [e-mail]'s message of 18 Aug 92 02:14:53 GMT

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

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

> No. The GC scans the various non-GC heaps to find (allocated) objects that
> contain GC pointers. It does not have to determine whether or not those objects
> are accessible; the fact that an object has been allocated but not deleted is
> sufficient.

Also:  The trickiest part of a conservative GC like KCL's is checking
whether a given word really is a valid pointer.  While this can be done
fairly efficiently, it's still not lightning-fast; KCL has to do a
modulo operation each time, for example.

But the test for whether or not a pointer points *somewhere* in the
GC-able zone of memory is trivial.  So if 90% of a program's allocation
can use manual deletion, we can do that allocation in a different memory
space and let the garbage collector do a trivial reject on 90% of
the pointers (more or less).

>|>  (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).

> Agreed, but there has to be some point in doing so. I see two possible reasons
> for having an explicit delete:
>
> 1. To take advantage of any performance improvement. Regardless of who's
>    right in this debate, I doubt that there is any benefit for GC objects.
>
> 2. To invoke destructors at a specific point in time. This makes a lot more
>    sense, even if the "delete" doesn't actually free the memory. This
>    may prove important.
>
> Any others?

The best one (IMHO):

Significant reduction in the number of GC's!  Again let's suppose 90%
of our allocation can be deleted manually.  That means that, without
doing any GC's, the amount of junk in memory grows only 10% as fast
as with no deletion at all.  So, with GC's, it takes ten times as long
to accumulate enough junk to cause another GC.

>|> [...] 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++.

> Better to let the compiler make the choice. If GC pointers are declared, the
> compiler can extend it to "this memory block doesn't contain any pointers
> significant to the GC".

And even without that, the compiler can at least decide for a given
"new" operation whether or not the data will contain *any* pointers.

>|> 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).

Well, now, this sounds like the same logic people use to ruin themselves
with credit cards...  Remember, you still wind up paying (for deallocation),
just later instead of right away.  But the convenience of paying later,
and the efficiency of paying in chunks, is a big win.

                                -- Dave
--
Dave Gillespie
  [e-mail], uunet!synaptx!daveg
  or: [e-mail]