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

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

Path: sparky!uunet!wupost!gumby!yale!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: 18 Aug 92 16:39:19 GMT
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: 86
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:

   Simple as that. If there is a way of doing GC that is comparable to
   the best manual - given all the other pain in C++ - I will accept
   you argument, but it should prove hard to convince the larger C++
   community.

I hope we can agree that GC costs you nothing if it doesn't run
(malloc and free in the presence of GC don't look very different from
the way they do now).

Now, if you dutifully manually free everything that you have
allocated, then GC will never run, since you will never run out of
memory. Hence, you don't incur any costs by having a GC sitting there.

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

   How do you get the GC to figure out _at_compile_time_ that certain pieces
   of memory become available at certain points in the program? That's the
   big win for manual.

The GC doesn't have to figure it out. You do. GC (in particular,
conservative GC) doesn't prevent you from doing manual storage
management, it only permits you not to bother. Even in the presence
of GC, you can continue to write your own "new" and "delete" functions
(per class or global) that, for example, take storage from their own
little storage pool, etc.

   |> Beyond these two facilities [providing a "free" function and
   |> providing a separate allocation function for blocks of memory
   |> that do not contain pointers], I simply fail to see the need to
   |> divide memory or pointers "garbage collected" and "not garbage
   |> collected" on the basis of efficiency.

   Because efficiency is a major issue, and the declaration could make a very
   large difference.

I think you have failed to establish this claim.

Conservative GC with a "free" function is a safety net. If you don't
run out of storage, you don't know it's even there. If you do run out
of storage, it lets your program continue to run when it would
otherwise have crashed. Whether you want to rely on this feature is up
to you, but, in general, I can see no harm in having it in the
language...

There are some minor semantic sticky points related to what to destroy
when and pointer encoding. It would be nice to discuss those real
issues once people have gotten over their odd hangups about the speed
of GC.

                    Thomas.

PS: A technical point about suggested speedups from GC pointers
vs non-GC pointers:

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

   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. Suppose such an object contains 6 pointers. In your conservative
   scheme, those 6 pointers must then be checked because they might refer
   to GC objects. If those pointers are declared non-GC, the GC doesn't even
   have to think about them; it can go straight on to the next memory block.
   Depending on the proportion of GC to non-GC, this could be a major saving.

If I read your paragraph correctly, you suggest that instead of
carrying out the usual GC marking phase on both the GC heap and the
non-GC heap, the non-GC heap is scanned once, linearly.

I don't think you are going to save any time over simply carrying out
a normal mark phase for all objects. The reason is that during a
normal mark phase, each block is scanned only once anyway, just as if
you had done a linear scan of non-GC space.  Furthermore, your scheme
requires the collector to distinguish between non-GC and GC pointers
during collection; the cost of doing so is probably roughly equivalent
to the cost of checking the "marked" bit on a block.