Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ukma!gatech!hubcap!billwolf%hazel.cs.clemson.edu
From: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 )
Newsgroups: comp.sw.components
Subject: Re: Real-time Garbage Collection
Message-ID: <6505@hubcap.clemson.edu>
Date: 19 Sep 89 15:12:17 GMT
References: <890@scaup.cl.cam.ac.uk>
Sender: news@hubcap.clemson.edu
Reply-To: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu
Lines: 31

From scc@cl.cam.ac.uk (Stephen Crawley):
> The key question that determines whether or not asynch GC will work in
> real-time is whether there is enough idle time to keep up with garbage 
> collection.  [...] Only when we are pushing the limits of the hardware
> will the answer be no. 

   Another key question is "How can we make this product such that it
   uses as little memory and CPU as possible, so that we might underbid
   our competitors?"; the reuse of components which do their own space
   management will permit the elimination of GC, thus providing an edge.
 
> Finally, I'd like to rebut the idea that ADT's that do their own storage
> management are appropriate for use in a GC'ed environment.  [...]
> [how to handle interactions between managed and unmanaged storage?]

   I'm not an expert on how this is done, but I'd guess that memory is
   divided into two regions: managed and unmanaged.  The GC system could 
   *read* the managed region (to detect pointers into the unmanaged area),
   but only for the purpose of operating upon the unmanaged region; it
   must refrain from taking any actions with respect to managed storage. 

   Probably there are considerably more sophisticated techniques 
   involved; I'd suggest porting this thread into comp.lang.ada 
   if someone is seriously interested in the question, since Ada
   compilers which provide GC are also required to enforce the
   CONTROLLED pragma (which specifies that this type manages its 
   own storage). 


   Bill Wolfe, wtwolfe@hubcap.clemson.edu