From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!uflorida!gatech!hubcap!billwolf From: billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,) Newsgroups: comp.lang.ada Subject: Re: Garbage Collection Message-ID: <3985@hubcap.UUCP> Date: 27 Dec 88 21:24:50 GMT References: <4195@enea.se> Sender: news@hubcap.UUCP Reply-To: billwolf@hubcap.clemson.edu List-Id: >From article <4195@enea.se>, by sommar@enea.se (Erland Sommarskog): [Erland describes a situation in which a user instantiates a tree structure over an access type, and then considers the insertion procedure with which the user inserts an object into the tree] > According to Bill the data allocated to Reference [in the example, > a pointer to the user's object] should be freed when > we exit this procedure, but if Insert does what we think this is of > course a severe error. Where did I go wrong? Did I plead guilty to > structure sharing just because I inserted a pointer to a tree? > Or does Bill mean that when Reference is inserted to the tree that > Reference.all should be inserted to the tree, not the pointer itself? > But what if I also insert the reference into another tree (or some other > structure) and then modify the referred data (some counter, for instance) > and want this change to appear in both places? > Note also that in this example, there are no side effects. We are only > dealing with local variables and paramerters. And still deallocation > on block exit is completely wrong. (And there is no way the compiler > could deduce that Insert really saves Reference somewhere.) The user has supplied the limited private type STORED_OBJECT, and defined assignment over this object. Let's assume that the tree is implemented in terms of a record structure, one field of which is a STORED_OBJECT. In the INSERT_ITEM procedure, the user sends "in out TREE_TYPE; in STORED_OBJECT". The tree is modified as follows: a new record is created to represent a new node of the tree. The statement ASSIGN (NEW_NODE.STORED_ITEM, NEW_OBJECT) is executed, along with whatever pointer manipulations are necessary to maintain the structure of the tree. Now we proceed to block exit. Since the tree and the new object are *parameters* and not local variables, they are not subject to the automatic destruction which applies to the block's local variables. 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. > 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. > 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. There are basically two cases in which this can happen: 1) When an inexperienced ADT designer is in the process of acquiring the mental discipline required of anyone who programs pointer-based structures. To avoid this, purchase ADTs from professional houses or use experienced ADT designers. Otherwise, it's a cost of professional training. 2) When a user has engaged in S T R U C T U R A L S H A R I N G. *** Don't engage in structural sharing *** > Bill Wolfe said earlier that garbage collection encourages > sloppy programming. Whether it is sloppy or not, I don't care, Obviously. > Why should a programmer waste time bothering about something that > the computer could do much safer for him? After all, the > programmer does not work for free. 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. Bill Wolfe wtwolfe@hubcap.clemson.edu