Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cwjcc!gatech!prism!tynor From: tynor@prism.gatech.EDU (Steve Tynor) Newsgroups: comp.sw.components Subject: Re: Re: Garbage Collection & ADTs Message-ID: <2079@hydra.gatech.EDU> Date: 26 Sep 89 19:08:40 GMT References: <911@scaup.cl.cam.ac.uk> <6589@hubcap.clemson.edu> Reply-To: tynor@prism.gatech.EDU (Steve Tynor) Organization: Georgia Institute of Technology Lines: 60 In article <6589@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: ... >From scc@cl.cam.ac.uk (Stephen Crawley): >> 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? > > The fact that a subgraph has become detached does not imply that > it is no longer part of a graph. Not all graphs are fully connected. > Therefore, it isn't possible to release the storage used until there > is some sort of directive which indicates that a given set of nodes > and/or arcs is to be destroyed. But what if _in_this_case_, a detached subgraph is garbage and should be deallocated? G.C. surely simplifies the program and would enhance readability. If you can easily detect when to deallocate - more power to you. But, it's not always easy. ... >> Dynamic loading & unloading of modules in a running program. >> [...] 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 is an operating-system problem, not an application problem. > As such, the situation is not "applicable to a wide range of > applications". The solution is operating-system dependent; one > approach might be to use idle time to scan the processes in the > process queue to determine if there are any processes which were > started while the old module was in effect which made use of it. Again, this sounds like garbage collection to me (this time the OS is garbage collecting the unloaded module...) > Operating systems do a lot of things (pointer arithmetic, etc.) > which application systems should not be doing; this falls into > exactly that category. Are compilers not mini-operating systems (certainly, the Ada run-time environment is!)? I'd much rather have my compiler doing my pointer arithmetic (and storage management) than to expect my application to do so. I'm not against explicit allocation/deallocation - I just want an alternative for the cases when it's either too convoluted or impossible. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Eschew Obfuscation. Steve Tynor Georgia Tech Research Institute Artificial Intelligence Branch tynor@prism.gatech.edu