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

Internet Message Format | 1992-08-19 | 3.4 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: 20 Aug 92 09:49:54 GMT
References: <[e-mail]>
    <[e-mail]>
    <[e-mail]>
    <[e-mail]> <[e-mail]>
    <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Synaptics, Inc., San Jose, CA
Lines: 63
In-reply-to: [e-mail]'s message of 19 Aug 92 08:54:52 GMT

In article <[e-mail]> [e-mail] (Niklas Hallqvist) writes:

> >[e-mail] (Niklas Hallqvist) writes:

>>   Instead of having two pointers
>>   for the link in each node, take the "previous" and "next" pointers
>>   and XOR them, and store the result!

>> You didn't take that seriously, did you? In any case, it's an old hat
>> and it's unportable (*).

> Well, I did mean it seriously, in order to show C++ rules need to be changed
> to allow even conservative GC.  It's only unportable between environments
> which don't have sufficiently sized integers to store pointers in.  If you
> restrict your program to only work on more "normal" architectures it IS
> defined.  Read ARM 5.4!

Well, being semi-portable doesn't stop it from being completely
demented.  :-)

> Of course, this means conservative GC is
> implementable on architectures where no integer type can hold a void pointer,
> but otherwise it is NOT.  Do I miss anything in my thinking?

No, it's implementable only if you include some fine print warning that
such tricks will fool the garbage collector.  After all, there will
always be *some* things the garbage collector won't be able to get:
Suppose you allocate an object, mail its hex address to another user,
and then refer to it later when the user mails back a request including
that address?  (Not a good idea, I know, but it's a simple example of
the sorts of unusual cases one would run into.  By Max Skaller's
description, Microsoft Windows sounds like one of those "unusual"
cases...)

It would probably be wise to say that any pointer which is stored as
an integer (or other non-pointer type) is not GC-safe.  This allows
the compiler to put non-pointers in a different area of memory that
the GC doesn't need to scan, if it so chooses.

The point is, saying you can't make a 100% bulletproof garbage
collector should not be enough to veto the idea in C++.  It should
be enough to show that a) if you live by a fairly reasonable and
well-defined set of rules of "decent behavior," the feature will
work, and b) if you choose to ignore those rules, but don't use
the new feature anyway, it won't matter.  The latter is one of the
main reason I think GC-able allocation should be something a
program has to ask for, not the default.

> So you had read this section, and still think GC can be done, if the text
> isn't changed to something like:

> "All pointer to integer conversions and back are implementation defined."

How about "it is unsafe to cast a pointer to GC-allocated object to
a non-pointer type."  Even this is conservative, and I don't think
anybody would mind this mild restriction.  As long as GC-allocated
objects only come by explicit request, no old code will be broken.

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