Path: utzoo!attcan!uunet!wuarchive!mailrus!iuvax!rutgers!gatech!hubcap!billwolf%hazel.cs.clemson.edu From: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) Newsgroups: comp.sw.components Subject: Re: GC & exception handling Message-ID: <6608@hubcap.clemson.edu> Date: 27 Sep 89 17:52:58 GMT References: <606@hsi86.hsi.UUCP> Reply-To: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu Lines: 39 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