billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (09/28/89)
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). An interesting question is, "What happens if the destruction process raises another exception?"; in this case, the most likely answer is that the two exceptions should be treated as if they arose concurrently; incidentally, an extremely interesting article on that topic appears in the current issue of ACM SIGADA Ada Letters ("Programming Atomic Actions in Ada", page 67). This is one place where the Ada 9X effort is really pushing forward the state of the art as far as programming languages are concerned. > 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? As far as other costs go, the copying burden comes for free because we need to assure update-independent semantics anyway. 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. Bill Wolfe, wtwolfe@hubcap.clemson.edu
wright@hsi.UUCP (Gary Wright) (09/28/89)
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
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (09/29/89)
From wright@hsi.UUCP (Gary Wright): > 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. No, you only write one Destroy procedure for the atomic type; you then get in return a Destroy procedure applying to the container (the list of whatever). This new Destroy can then be automatically supplied to any enclosing container, ad infinitum. >> 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? Programmers generally prefer to work with containers which do provide this service. It's a market requirement. Bill Wolfe, wtwolfe@hubcap.clemson.edu