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