Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!usc!ginosko!uunet!mcsun!ukc!cam-cl!scc From: scc@cl.cam.ac.uk (Stephen Crawley) Newsgroups: comp.sw.components Subject: Re: Re: Garbage Collection & ADTs Message-ID: <911@scaup.cl.cam.ac.uk> Date: 25 Sep 89 10:55:13 GMT References: <900@scaup.cl.cam.ac.uk> <6530@hubcap.clemson.edu> <909@scaup.cl.cam.ac.uk> <62342@tut.cis.ohio-state.edu> Sender: news@cl.cam.ac.uk Organization: U of Cambridge Comp Lab, UK Lines: 48 Golden Richard III writes: > I find the current GC wars rather interesting, but I find myself siding > naturally with Bill simply because I have *never* encountered a situation > that absolutely demanded GC. Even without automatic scope-exit destructors > for ADTs, programmer-controlled storage management isn't difficult. > I'd be most interested in seeing some concrete example where GC was the > 'only way to go'. Here are some problems where programmer-controlled storage management would be very difficult or impossible. Interactive editting of cyclic graph data structures. You have a heterogeneous cyclic graph data structure and the editor must be able to make arbitrary sequences of changes to the data structure. How do you detect that a subgraph has become detached? This sort of problem arises in many real life problems such as graphical editors and in various programming environment tools. In practice, many such applications don't try very hard to reclaiming storage. When the application has leaked so much space that the processor starts to thrash, the user can always save his work and restart ... Dynamic loading & unloading of modules in a running program. An application consists of a static set of core modules and a number of other modules that are dynamically link-loaded on demand. When the programmer recompiles a dynamic module, he may want to reload it and start using it without shutting down the entire application. But to do this, the dynamic loader needs to know if the module is currently being 'used' ... e.g. if some thread is executing a procedure exported by the module or if some other part of the application has salted away a reference into the module (e.g. a procedure pointer) This problem arose when I was using Mesa / XDE to implement my entity system; a persistent object system. I did get the dynamic loading to work ... and it made a big performance difference, but dynamic unloading could not be done safely, since the Mesa / XDE environment has no garbage collector. [Incidentally, the lack of garbage collection caused so many reliability problems that I was forced to give up using Mesa / XDE altogether about 2 years ago. The new version of the entity system uses MIT CLU as the base language. CLU is garbage collected, and though the GC I am using is slow and has some unpleasant attributes, and though I've had to do some extensive butchery on unsavoury parts of CLU runtime system, I do not regret making the switch] -- Steve