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