Automatic Garbage Collection (was Re: Object Suicide)
Daniel LaLiberte
I'm cross posting this response to comp.programming.
In article <1992Mar02.19...@locus.com> j...@locus.com (Jon Rosen) writes:
However, there are some real reasons why adding object garbage
collection to Obj-C or C++ would be a bad idea and it is mostly
because they are hybrid languages. [... garbage collected :) ...]
...there is no way for the compiler to ever be sure that
garbage collection would be useful or adequate or accurate.
Therefore, it is better to leave the deallocation of things
that the programmer has called into existence explicitly
to the programmer.
Moderation!
Why are people so all-or-nothing? Even though it is true that the
compiler or runtime system cannot always tell whether something is
garbage for a language that allows indiscriminate pointer references,
it is still very useful to *sometimes* make use of one of several
kinds of automatic garbage collection, depending on the allocation
and deallocation patterns for groups of objects.
Certainly if your program always deallocates objects before exiting
the scope of variables that reference them, you dont need any more
complex garbage collection scheme than that. And certainly in many
other cases you can get away with a simple reference counting scheme
to garbage collect some heap allocated objects.
But certainly you must also agree that there exist more complex data
structures with circular references and indefinite lifetimes for which
all simple garbage collection schemes fail to be sufficient. The only
alternative, if a general GC is not provided by the system, is to
build your own each time it is needed, which is certainly more error
prone than reusing a well debugged scheme. So this is *not* just a
matter of being a lazy programmer, as others have suggested. It is a
matter of software integrety and/or speed of programming.
So my point is that any GC scheme for a hybred language with possible
indiscriminate point references (I made that term up - is there a
better one?) should probably allow you to impose garbage collection
on selected classes of objects rather than on all objects. It helps
to have multiple inheritance here to cleanly mixin GC behavior, but
you can do without it.
On the other hand, in some cases I wish I could turn off the automatic
garbage collection provided by Lisp and similar GCing languages. A
sufficiently smart compiler can detect local-only references to
allocated objects, and thus stack allocate them. But for moderately
complex data structures of indefinite lifetimes (e.g. a stack), I
know I can safely manage the memory myself, but I am not allowed
that luxery.
By the way, in many Lisp systems you *can* create references that Lisp
does not know about, thus foiling "correct" garbage collection, but
any errors that result would be considered the programmers fault,
not the fault of the Lisp langauge for allowing the error to occur.
Dan LaLiberte
lib...@cs.uiuc.edu
(Join the League for Programming Freedom: lea...@prep.ai.mit.edu)
Amr Sabry
In article <LIBERTE.92...@birch.cs.uiuc.edu>, lib...@cs.uiuc.edu (Daniel LaLiberte) writes:
|>
|> By the way, in many Lisp systems you *can* create references that Lisp
|> does not know about, thus foiling "correct" garbage collection, but
|> any errors that result would be considered the programmers fault,
|> not the fault of the Lisp langauge for allowing the error to occur.
Would you care to explain how? --Amr
M. Gallo
However, there are some real reasons why adding object garbage
collection to Obj-C or C++ would be a bad idea and it is mostly
because they are hybrid languages. [... garbage collected :) ...]
...there is no way for the compiler to ever be sure that
garbage collection would be useful or adequate or accurate.
Therefore, it is better to leave the deallocation of things
that the programmer has called into existence explicitly
to the programmer.
I would suspect that the culprit is not the hybrid nature of the
languages, but rather their typing systems. Because of C's
inherent ambiguity between pointers and integers, the garbage
collector cannot neccessarily be reliable when marking memory regions
for reclaimation. A sound GC system does work (and can be very
useful) in a strictly typed, hybrid language such as Oberon or Modula-3.
--
IMHO, as always _ /|
Miguel \'o.O'
mga...@ares.calpoly.edu =(___)=
"C is its own virus." U
Dave Schaumann
not have all of the relevant context...
In article <1992Mar04.2...@zeus.calpoly.edu> mga...@zeus.calpoly.edu (M. Gallo) writes:
>In article <1992Mar02.19...@locus.com> j...@locus.com (Jon Rosen) writes:
> However, there are some real reasons why adding object garbage
> collection to Obj-C or C++ would be a bad idea and it is mostly
> because they are hybrid languages.
Automatic garbage collection (ala Lisp) would be a Bad Thing in C++ or
Objective C because it is against the Spirit Of C (tm): let the programmer
do it the way the programmer wants to (or put another way, the system
shouldn't make too many decisions for the programmer).
On the other hand, it *is* possible (and has been done) to roll your own
garbage collection in C++ (a programming assignment in my programming languages
class was to implement a micro-Lisp interpreter using reference count garbage
collection).
>I would suspect that the culprit is not the hybrid nature of the
>languages, but rather their typing systems.
Agreed, but I would add (as above) that it is deeper than that; it is
as much a philisophical issue as it is an issue of "can it be done"
(at least in C's case).
>Because of C's inherent ambiguity between pointers and integers
As long as I'm pontificating here (:-)... C has an inherient ambiguity
between *all* types. Casts will let you do *anything*. It just so happens
that there is a nice 1-to-1 mapping between ints and pointers on many
(note many != all) machines.
>A sound GC system does work (and can be very useful) in a strictly typed,
>hybrid language such as Oberon or Modula-3.
Again, note the underlying philosophy: Mr. Wirth's bondage and discipline
languages are probably well suited for another compiler-knows-best
implementation decision.
>"C is its own virus."
:-) I guess you can probably tell which language group is my favorite...
--
You're traveling through another dimension -- a dimension not only of sight and
sound but of mind. A journey into a wonderous land whose boundaries are that of
imagination. That's a signpost up ahead: your next stop -- the Twilight Zone
William M. Bumgarner
If automatic garbage collection were applied to this bboard, this thread
would have been purged long ago....
b.bum
b.bumgarner | But who can unlearn all the facts that I've learned
bb...@cmu.edu | As I sat in their chairs and my synapses burned
| And the torture of chalk dust collects on my tongue
NeXTMail Safe | Thoughts follow my vision and dance in the sun -- PHISH
Greg Lindahl
>>"C is its own virus."
>
>:-) I guess you can probably tell which language group is my favorite...
Is this group destined to duplicate alt.religion.computers? Followups
there.
--
Signature virii are lame.
Van Kelly
> lib...@cs.uiuc.edu (Daniel LaLiberte) writes:
|>
|> By the way, in many Lisp systems you *can* create references that Lisp
|> does not know about, thus foiling "correct" garbage collection, but
|> any errors that result would be considered the programmers fault,
|> not the fault of the Lisp langauge for allowing the error to occur.
> Would you care to explain how? --Amr
I'll take a stab at this question.
The usual methods for doing this are definitely not sanctioned by a modern
Lisp language standard like Common Lisp or Scheme, but often are provided in
"language extensions" and optimizations by Lisp vendors. They include:
a.) Foreign function library interfaces that coerce/cast LISP pointers to/from
raw addresses.
b.) Sub-primitives that poke raw memory cells or do address arithmetic.
c.) Separate memory areas for allocating "pure" data the programmer
guarantees not to contain pointers into GC'ed memory (famous last
words), and of course the ever-popular
d.) Compiler declarations that force stack-allocation of data that has
no business being on the stack.
Van Kelly
AT&T Bell Laboratories
Murray Hill, NJ
The above posting reflects my own opinions, not necessarily those of my
employer.
Nick Haines
However, there are some real reasons why adding object garbage
collection to Obj-C or C++ would be a bad idea and it is mostly
because they are hybrid languages. [... garbage collected :) ...]
...there is no way for the compiler to ever be sure that
garbage collection would be useful or adequate or accurate.
Therefore, it is better to leave the deallocation of things
that the programmer has called into existence explicitly
to the programmer.
I would suspect that the culprit is not the hybrid nature of the
languages, but rather their typing systems. Because of C's
inherent ambiguity between pointers and integers, the garbage
collector cannot neccessarily be reliable when marking memory regions
for reclaimation. A sound GC system does work (and can be very
useful) in a strictly typed, hybrid language such as Oberon or Modula-3.
It _is_ possible to do GC with untyped languages like C or C++, as
long as the compiler doesn't do any (unusual) optimizations. It's
called `conservative' GC, and it assumes that any word which _can_ be
a pointer (ie which has a value in the range of the heap) _is_ a
pointer. There are certain things you can do in C which this won't GC
(using XORs to do a doubly-linked list, for instance), but it does
well on most code (and if you know it's going on, you can easily
program to allow for it).
Nick Haines ni...@cs.cmu.edu