Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!hsi!wright From: wright@hsi.UUCP (Gary Wright) Newsgroups: comp.sw.components Subject: Re: GC & exception handling Message-ID: <615@hsi86.hsi.UUCP> Date: 28 Sep 89 13:42:30 GMT References: <606@hsi86.hsi.UUCP> <6608@hubcap.clemson.edu> Reply-To: wright@hsi.com (Gary Wright) Organization: Health Systems Intl., New Haven, CT. Lines: 65 In article <6608@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: >From wright@hsi.UUCP (Gary Wright): >> Another area that concerns me that hasn't been discussed is the interaction >> between exceptions and memory management. My understanding is that >> when an exception is raised, execution may resume after any number of >> "scopes" have been exited. Will the objects in those scopes be >> guaranteed to be destroyed? > > This is the only reasonable way to handle the situation. Destruction > would occur as part of the scope exit, and in fact this is exactly > what happens now in Ada 83 (sort of -- the objects are no longer > accessible, and may as well be dead; if there is a GC system running, > it's perfectly free to take over at this point). I should have said "will the memory associated with all the objects that can be referenced only from objects within the exited scopes be reclaimed?" I did not mean to imply, by using the word "destroy", that some action would need to be taken in addition to the memory being reclaimed. Ada 83, if I understand you correctly, can not guarantee this and will have memory leaks unless a GC system is running. This is exactly why I and others have been arguing in favor of GC. > >> The point is that there *are* tradeoffs. Not using GC "might introduce" >> reuse problems also. What is the cost associated with "avoiding" GC? > > Could you please elaborate on how a self-managing component could > possibly cause reuse problems? Everytime I want to "reuse" an ADT I must write a "dispose" procedure for the particular type that I am storing in the stack. This is a reuse problem. For instance, in Eiffel if I want a stack of a stack of lists of integers: sslint : STACK[ STACK[ LIST[ INTEGER ] ] ]; sslint.Create; In an a language like Ada I would first have to write a dispose procedure for integers in a list, then I would need a dispose procedure for a list of integers in a stack and then a dispose procedure for a stack of lists of integers in a stack. Then I could finally use this new ADT. What are the chances of introducing errors into the Eiffel code vs. the Ada code? How reusable is the Eiffel class vs. the Ada ADT? > > As far as other costs go, the copying burden comes for free because > we need to assure update-independent semantics anyway. Where is this requirement specified? > The real cost is simply the space which might be taken up by the > destruct code, and here we have a time-space tradeoff. Either we > store the destruct code and get faster space management, or we > forget about destruct code and live with slower allocation > service. > Perhaps this really indicates that both ideas are necessary. Did I just see a light bulb appear above your head? :-) For the vast majority of applications, I believe GC is an acceptable and in many cases preferred solution. -- Gary Wright ...!uunet!hsi!wright Health Systems International wright@hsi.com