Re: Garbage Collection

[billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,)]

From article <35278@think.UUCP>, by barmar@think.COM (Barry Margolin):
> In article <4041@hubcap.UUCP> billwolf@hubcap.clemson.edu writes:
>>         ASSIGN (TEMP, SOME_OPERATION (SOME_ADT)); 
>>         ACCESS_AN_INTEGER := new INTEGER := SIZE_OF (TEMP);    
>>            -- notice the allocation...
>>         DO_SOMETHING_WITH (TEMP, SOME_ADT, ACCESS_AN_INTEGER);
>>         DO_SOMETHING_ELSE_WITH (TEMP, ACCESS_AN_INTEGER);
>>            --
>>            -- notice failure to deallocate ACCESS_AN_INTEGER.all...
> 
> But what if DO_SOMETHING_WITH and/or DO_SOMETHING_ELSE_WITH makes a
> copy of its third parameter in some permanent data structure?  If
> ACCESS_AN_INTEGER.all were to be deallocated at this point, you would
> end up with a dangling pointer.  Or should these routines be required
> to also copy THIRD_ARGUMENT.all, too?

    Some of you appear to be laboring under the false impression that
    when one passes a pointer into a procedure, one will have no idea
    what is to be done with that pointer.  Let me assure you that before
    I pass a pointer into *any* procedure, that procedure had damn well
    better declare its intentions with respect to that pointer.  Some
    possibilities are:

       -- The pointer must be the sole pointer to the object in question.
       -- This procedure then claims sole possession of that object;
       -- the pointer you pass in will therefore be read and then set to null.

       -- The pointer will be maintained as a reference to the object in qu
       -- question.  The caller is responsible for ensuring that the object
       -- is not destroyed without first making a call to REMOVE_OBJECT
       -- in order to destroy this reference to the object in question.

       -- The pointer must be the sole pointer to the object in question.
       -- This procedure will read the object pointed to, and then destroy it;
       -- the pointer you pass in will therefore be read and then set to null.

   ***********************************************
   ** The answer, my friends, is DOCUMENTATION. **
   ***********************************************
 
> My understanding is that the Ada designers didn't originally espouse
> manual deallocation (hence the name UNCHECKED_DEALLOCATION) because it
> is an easy way to write erroneous programs, and there's no way to
> statically check for this error at compile time.  

    Failure to deallocate is a logic error; like other logic errors,
    they are best detected by desk checking (primary line of defense),
    and by using a debugger as a last resort.

> I've used both GC and non-GC languages.  I've done lots of programming
> in PL/I, and now I'm a Lisp programmer.  Personally, I've had few
> problems with dangling pointers in PL/I, but most of the programming
> didn't make use of ADT-style programming.  

     Personally, I've had no problems with dangling pointers in Ada,
     due to the complexity management provided by the ADT paradigm.

> But I've also seen the freedom allowed by a garbage collector in the
> Symbolics Lisp Machine software.  It means that unrelated programs can
> share data structures without preplanning.  

     You mean "without documentation".  Thanks, but no thanks. 

A fundamental assumption
> of manual deallocation is that when the allocator of a structure is
> through with it, so is everyone else.  But when references to these
> structures are passed around the references may be copied.  Unless you
> want to require everyone to copy those structures you can't assume
> that the allocator knows when it's safe to deallocate.

     Sure I can, provided the lost art of documentation is practiced
     from time to time...  (Gee, I sure hope I don't ever have to 
     program with YOUR colleagues...)



                                        Bill Wolfe

                                 wtwolfe@hubcap.clemson.edu