Re: Garbage Collection

[wtwolfe@hubcap.UUCP (Bill Wolfe)]

From article <4200@enea.se>, by sommar@enea.se (Erland Sommarskog):
>>   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.

    One more time.  A exists within the tree.  The tree is a PARAMETER.
    The tree is NOT a local variable.  Hence, upon exit from the ASSIGN
    procedure, A will not suffer deallocation.  Now what about B?  It's
    a parameter too, and also will not be deallocated.
 
>   Bill, tell me, what is wrong here? My understanding of your proposal,
> or the program I have written? 

    Your understanding of my proposal.  I'm having a really hard time
    trying to figure out what you're thinking of here.  I thought everything
    had been clearly defined in terms that any Pascal/Modula-2/Ada programmer
    would understand.

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

     Advanced debugging tools should be used to address this issue.

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

   I'm TRYING to get Ada to integrate the automatic destruction of local
   variables which occurs during block exit with ADT destruction procedures,
   so the user can rely on the implicit deallocation request associated
   with block exit.  Let me give a concrete example:

      procedure EXAMPLE (A : in out ADT);

         B : ADT;
         C : INTEGER;

      [body of procedure EXAMPLE]

    Now when the body of procedure EXAMPLE has finished executing,
    in current Ada C will be properly destroyed, but B will not.
    If B is implemented as a pointer to something, that pointer will
    be destroyed, and everything it pointed to will become garbage.
    By integrating the DESTROY procedure into block exit, everything
    B pointed to will be deallocated as well.  Since A is a parameter,
    it is not part of the locally defined environment; it is instead
    part of the caller's environment, and will stay that way.  In the
    revised version, the "right" DESTROY procedure will apply to B
    as well as C, thus enabling the use of implicit destruction,
    which is the most frequently used method of destruction. 

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

   I'm quite aware of Eiffel, and I have just shown (in another article)
   how reliance upon garbage collection is a sure way to get your ADT
   rejected by users who are programming critical applications.  This
   same argument applies to Eiffel and the other members of the peanut
   gallery; they are unsuitable for critical applications, among their
   many other flaws.  May I suggest David Harland's "Concurrency and 
   Programming Languages"?

   Representation of classes of types is better accomplished through a
   synthesis approach, rather than an inheritance approach; however, this
   is presently a research topic.  Followups on this to comp.lang.sigplan
   or e-mail, please.  


                                        Bill Wolfe

                                 wtwolfe@hubcap.clemson.edu