From: niklas@appli.se (Niklas Hallqvist)
Newsgroups: comp.lang.c++
Subject: Re: Garbage Collection for C++
Date: 20 Aug 92 20:32:43 GMT
Organization: Applitron Datasystem AB, GOTHENBURG, SWEDEN

daveg@synaptics.com (Dave Gillespie) writes:

:In article <2135@appli.se> niklas@appli.se (Niklas Hallqvist) writes:

:> >niklas@appli.se (Niklas Hallqvist) writes:

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

Actually, I will give up my role as the devils advocate here and now.
Thomas has showed me (in private email) that it is possible for a GC
implementor to obey the rules as stated in the ARM.

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

If I understand you correctly, this is exactly the way to go, if we not
which to change the rules.  If the compiler stores away every pointer
casted to a non-pointer type in a region the collector can see, all these
pointed-to objects will never be collected, and everything is fine.
It even solves your "mail the hex address" problem :-)

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

I'm not against GC in C++, on the contrary, since I'm lazy I would
probably be very glad if it went into the language.  I was merely
trying to play the role of the devils advocate, with limited success,
luckily :-)  Why? - you ask... Well, if we're going to keep the language
portable we have to find the problematic sentences in the ARM and identify
what needs to be done about them.  In this case we don't NEED to change
anything, but it would HELP the GC implementors to loosen up the
definition somewhat.

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

I want to apologize to Thomas for this rather rude statement.
He was right and I was wrong.  Excuse me!

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

Ok by me..

Niklas
-- 
Niklas Hallqvist	Phone: +46-(0)31-40 75 00
Applitron Datasystem	Fax:   +46-(0)31-83 39 50
Molndalsvagen 95	Email: niklas@appli.se
S-412 63  GOTEBORG, Sweden     mcsun!seunet!appli!niklas
Newsgroups: comp.lang.c++,comp.lang.c,comp.std.c++,comp.std.c