Path: utzoo!attcan!uunet!mcsun!ukc!cam-cl!scc From: scc@cl.cam.ac.uk (Stephen Crawley) Newsgroups: comp.sw.components Subject: Re: Garbage Collection & ADTs Message-ID: <920@scaup.cl.cam.ac.uk> Date: 27 Sep 89 12:53:16 GMT References: <2079@hydra.gatech.EDU> <6595@hubcap.clemson.edu> Sender: news@cl.cam.ac.uk Organization: U of Cambridge Comp Lab, UK Lines: 80 From wtwolfe@hubcap.clemson.edu: >From tynor@prism.gatech.EDU (Steve Tynor): >>From wtwolfe@hubcap.clemson.edu: >>> 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? > > OK, assume that we do want to kill detached subgraphs. Which of > the two (or more) connected components is the one we wish to keep? > > If we assume that there is some distinguished node or arc which > can never be deleted and which also serves to mark the "permanent" > connected component, then presumably our graph abstraction will > allow us to mark one such node or arc as being endowed with these > magic properties. Now we need an oracle which will tell us if > a connected component contains the magic node or arc. > [...] Having provided the service to the user anyway, > we can now use it ourselves to determine which component to throw > away. Now this is obviously a special-case response to this > particular problem, but the problem is also a special case itself. In YOUR experience, the problem may be a special case. In my experience and that of a number of other posters this problem arises frequently in one form or another. > Even if computing it ourselves has the same computational complexity > as computing it with a garbage collection algorithm, .. which is not necessarily true. You are assuming that we have all of the options open to the garbage collector guru; e.g. access to VM page tables, micro-code, etc. Also, you are assuming that the grungy tricks that sophisticated GC algorithms play can be expressed in ADA and translated by the ADA compiler into efficient code. Please don't imagine that it is easy to get garbage collection overheads down to 5%!! > [...] there is still > a gain in that we can search a specific area at a specific time and > therefore improve the predictability of our service. There is nothing to stop the programmer from inserting a pragma to force the GC to reclaim some space at a given point in a program. > We know that > there will be no operation whose time complexity will be totally out > of proportion to the size of our graph because we are paying for all > garbage everywhere on the machine to be collected. You are making invalid assumptions about the garbage collector again. > Finally, there is the problem of the GC system repeatedly being > invoked (at great expense) when the amount of storage remaining > becomes fairly small. Modern garbage collectors can avoid this problem in all but extreme cases. Anyway, it is a bad idea to try to run a program that allocates memory dynamically with "just enough" memory, since under some circumstances "just enough" might actually be "just not enough". > ... With a managed system, the user is given > an opportunity to strategically throw away data structures, and > thereby free up some space that the garbage collector could not > possibly take because it is still "in use". Bogus argument! The case you are talking about is that where the programmer has a pointer to a data structure in a variable that is still in scope, but is not conceptually in use. You suggest that in the case of non-GC'ed storage the programmer could free the space early by calling the deallocator. Well in the GC'ed case, the programmer can arrange that the GC can free the data structure by assigning NIL to the variable. -- Steve