Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!exodus!rbbb.Eng.Sun.COM!chased
From: chased@rbbb.Eng.Sun.COM (David Chase)
Newsgroups: comp.lang.c++
Subject: Re: Smart Pointers -- A proposed language extension
Keywords: smart pointers, garbage collection
Message-ID: <6290@exodus.Eng.Sun.COM>
Date: 19 Jan 91 00:33:31 GMT
References: <1990Dec28.203554.21028@clear.com> <1991Jan6.072110.27136@cpsc.ucalgary.ca> <1991Jan16.224703.7647@xanadu.com> <1991Jan18.014050.27108@cpsc.ucalgary.ca> <6253@exodus.Eng.Sun.COM> <1991Jan18.230221.707@cpsc.ucalgary.ca>
Sender: news@exodus.Eng.Sun.COM
Organization: Sun Microsystems, Mt. View, Ca.
Lines: 79

gintera@fsd.cpsc.ucalgary.ca (Andrew Ginter) writes:
>Chase: I think a better answer would be to blow off this goal of portability
>Chase: in standard C++, and instead get some compiler support or use a
>Chase: language that already supports garbage collection.  ...

>That's just it.  ... Right now, the C++ language does NOT guarantee
>the operation of a type safe, reliable, portable, cooperative
>collector.  ... The question is, can it be done while changing the
>rest of the language very little?  Can it be done without sacrificing
>compatibility with C source and object code?

Strictly speaking, language changes (in the form of restrictions) are
probably necessary.  It's too easy for me to take the address of a
member of an object and propagate that all over the world (including
into the heap), which forces me to go to "hyper-conservative"
collection, which is dangerously leaky.  Pointers smart enough to deal
with this are probably (after a moment's reflection) too expensive for
practical use.

I think that compatibility with C (and C++) source and object code is
largely a red herring.  In the short term, yes, this is useful.  In
the long term, the two languages are just plain different.  They may
look the same, but people will write vastly different code.  They'll
write different INTERFACES; no need to worry about reclaiming memory
resources if there is a garbage collector to back you up.  (I'm not
explaining this well -- program with a garbage collector for two
years, and you'll see what I mean.  It becomes painfully clear after
the garbage collector is taken away).

By the way, why is it important to have a portable (in the sense of
"contains no machine-dependent #ifdef's") garbage collector?  I
realize that this is a blasphemous question, but the Boehm-Weiser
collector is quite good (except for when the optimizer outsmarts it),
easy to use, and not "portable", though it is easily ported.  People
don't seem to be bothered that they use different compilers, linkers,
and libraries on different machines -- only the interfaces are the
same.

>Can the result [nonconservative collection?] be competitive with
>manual allocation?  With conservative collectors?

Define "competitive".  Your probably mean, "run as quickly as".

Consider the other metrics you might use:

is it less prone to leaking memory?  yes. yes.
is it less prone to pointer smashes?  yes. no worse.
is it more convenient to the programmer? yes. to be seen.

A quote taped up next to my office says:

 "Time spent by programmers to solve storage management related
  problems has decreased from an estimated 40% in Mesa [no GC] to an
  estimated 5% in Cedar [with GC] ....  Automatic storage management can
  improve programmer productivity dramatically without affecting
  performance adversely."  (Rovner, 1984)

Ponder that next time you hear about a product that failed to ship on
time.

Edelson presents evidence that a fairly naive compacting C++ collector
can run about as quickly as manual allocation.  I've been satisfied
with the performance of the Boehm-Weiser collector in my use of it
(but this is without using "volatile" to ensure correctness after
optimization).

>Can it be done for parallel applications and applications with signal
>handlers that may trigger collections?

No, you'll need to introduce a degree of conservativism.  You cannot
control the code that is ultimately generated by your backend if you
are claiming to be "portable".  In a parallel world, there will almost
always be some temporary floating around that your "smart pointer"
won't know about and your collector will be unable to relocate.  Read
the papers by Bartlett and Boehm&Weiser.  Get their code, and study
it.

David Chase
Sun Microsystems