Re: Garbage Collection

[sommar@enea.se (Erland Sommarskog)]

I gave an example where I stored pointers in a tree, and tried
to make Bill Wolfe explain how this should work with his idea 
with deallocation on block exit. He answered, but I wouldn't 
say I'm satisfied... I still don't see where he is heading.

>   Since the user supplied an access type as the type of object to be
>   stored in the tree, the user bears full responsibility for making
>   responsible use of the fact that he/she is dealing with a tree of pointers.

Well, assume that Assign the procedure I write for Some_access_type 
(the type I store in the tree) is simply A := B. With your scheme I 
can't but see that the object I allocated is deallocated when I exit  
my procedure, although I still have a reference to it, stored in
the tree.
  Bill, tell me, what is wrong here? My understanding of your proposal,
or the program I have written? If you think the latter, explain to me
how the compiler should detect the error I'm doing. Or do you really 
think such an error should remain undiscovered until run-time? And
does that rhyme with your eagerness for simplify maintenance?

>> Several times in this discussion Bill Wolfe has claimed that 
>> garbage collection is a trouble-maker for maintainers. In what way? 
>
>      When there is great difficulty deciding whether a given object 
>      exists or not, the maintainer experiences great difficulty 
>      pinning down the precise state of the program.  

You have just given an excellent argument for garbage collection.
With garbage collection, only the objects that have references
exist. Without, there may be other objects that are unreachable.
With garbage collection you are sure of that all initiated non-null
references point to actual objects. Without, you may by mistake
be pointing straight into free space, or right in the middle of
some completely other kind of object. 
  The only incertainty you have with garbage collection is whether 
a non-referred object has yet been returned to free memory, depending
on wether the garbage collector has come there or not. But since 
the object no longer is part of the system, this question is of 
little interest.

>>   Much worse for maintainence is when the system dies with "System 
>> access violation" or "segmentation fault" from time to time and you 
>> don't know why. The reason may be that an allocated area was erroneously 
>> released and then reused and the original data, that someone appearently 
>> is relying in, has been over-written. Or because an already deallocated 
>> was deallocated a second time.

I forgot: When the system chokes with "heap full" and you as a maintainer
is trying to find where all space is being wasted. With garbage collection
you at least know that all this memory is being used. Without, you don't 
know if it is just memory leakage or real overuse.

>    DESTROY procedures are easy to write, need only be written once
>    per ADT, and can be reused indefinitely.  GC costs us the
>    computer time required to repeatedly determine which storage
>    is in use and which is not, and this cost must be paid repeatedly
>    AT RUN TIME.  Given that this PERMANENT, RUN_TIME COST can be
>    avoided by simply communicating the fact that a particular object
>    is no longer needed, GC is a rather costly crutch for lazy programmers. 

1) You have several times stated that the callers of your ADTs 
are responsible for that their destroy procedures are called.
So it's not only to write them. You must remember to call them
too. And when you forget, it takes time find out where.

2) Much of this talk reminds of what hear from C programmers when
range and type checking is being discussed. And the same arguments  
apply. If all programmers were skilled enough to do everything
right we wouldn't need Ada or high-level langauges at all. Actually,
if everyone else is taking help of computers these days, why shouldn't
programmers do?
  Just like range and type checking, garbage collection is a device
that increases our thrust in that the system does what we intended.

3) I recommend you to read "Object-Oriented Software Construction"
by Bertrand Meyer. There he explains why garbage collection is
necessary in an object-oriented system. He also describes how the
garbage collector is implemented in the Eiffel system. (Eiffel is
an object-oriented language, devised by Mr. Meyer, and comemercially
available.) 
-- 
Erland Sommarskog
ENEA Data, Stockholm              This signature is not to be quoted.
sommar@enea.se