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.8 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!unmvax!gatech!hubcap!wtwolfe From: wtwolfe@hubcap.UUCP (Bill Wolfe) Newsgroups: comp.lang.ada Subject: Re: Garbage Collection Message-ID: <3996@hubcap.UUCP> Date: 30 Dec 88 00:52:32 GMT References: <4200@enea.se> Organization: Clemson University, Clemson, SC List-Id: >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