Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!gem.mps.ohio-state.edu!apple!oliveb!orc!Ozona!chase
From: chase@Ozona.orc.olivetti.com (David Chase)
Newsgroups: comp.lang.c++
Subject: Re: automatic vs static vs heap...
Message-ID: <48706@ricerca.UUCP>
Date: 30 Oct 89 17:41:52 GMT
References: <1989Oct26.191119.9278@polyslo.CalPoly.EDU>
Sender: news@orc.Olivetti.Com
Reply-To: chase@Ozona.UUCP (David Chase)
Distribution: usa
Organization: Olivetti Research California, Menlo Park, CA
Lines: 63

In article <1989Oct26.191119.9278@polyslo.CalPoly.EDU> ttwang@polyslo.CalPoly.EDU (Thomas Wang) writes:
>Currently there is no portable way to tell if a variable is
>allocated as automatic, heap, static, or global.
>
>I propose that C++ be extended to support the following new operators:
> [proposal deleted].

Basically, I think you're crazy to try to put garbage collection into
C++, but I wish you luck.  Language changes are probably not a good
idea, even if you are right and everyone else is wrong.  I also
suspect that you'll have an interesting time figuring out which
destructors to invoke where in a garbage-collected system -- have you
considered, for example, cyclic garbage?

You can probably solve most of your (sub)problem here by getting
deeply in bed with the storage allocator.  For instance, the
Boehm-Weiser conservative collector "knows" what memory it is
managing, and it is possible to tell if a pointer is "real" or not.

Similarly, objects on the stack (I assume this is what you mean by
automatic) are obvious because their addresses point into the range
between stack-base and current sp.  Static and global are
indistinguishable, but those objects are all allocated between "end"
and the base of the data segment (some machines have separate
non-contiguous segments for text and data -- obviously, this
generalizes).

You might give the Boehm-Weiser collector a look; within it are
parameters describing many different machines.  You can either adapt
their collector to your purposes, or you can use their parameters in
your collector.

Here's how to get it:

  (9)% ftp titan.rice.edu
  Connected to titan.rice.edu.
  220 titan FTP server (SunOS 4.0) ready.
  Name (titan.rice.edu:chase): anonymous
  331 Guest login ok, send ident as password.
  Password: 
  230 Guest login ok, access restrictions apply.
  ftp> cd public
  250 CWD command successful.
  ftp> dir gc*
  200 PORT command successful.
  150 ASCII data connection for /bin/ls (129.189.192.6,1211) (0 bytes).
  -rw-r--r--  1 211      30          56720 Oct 13 17:53 gc.shar.01
  -rw-r--r--  1 211      30          54253 Oct 13 17:53 gc.shar.02
  226 ASCII Transfer complete.
  remote: gc*
  132 bytes received in .28 seconds (.46 Kbytes/s)
  ftp>

This collector can be tuned and tweaked to varying degrees of
conservativeness, but in its most conservative form (pointers can
appear at any alignment, and any pointer into an object's interior
also counts as a pointer to the object) collection is much slower and
has on occasion failed to reclaim noticeable amounts of memory.

There's additional problems if your compiler has a "real" optimizer,
but that usually isn't an issue for C.

David