From: lex@cc.gatech.edu   
      
   Kevin Willoughby  writes:   
      
   > In article , lex@cc.gatech.edu   
   > says...   
   >> Kevin Willoughby  writes:   
   >> > A lot of research has been done on garbage collection. It is possible to   
   >> > limit the CPU time consumed in garbage collection, allowing a real time   
   >> > system (at the expense of perhaps requiring a bit more memory).   
   >>   
   >> To be pedantic, RT garbage collectors cost *time*, not memory.   
   >   
   > Not necessarily.   
      
   You raise good issues, but it is important not to oversimplify.   
      
      
   > Long experience has taught us that if you have the   
   > absolute minimum amount of memory, you spend a lot of time doing garbage   
   > collection. Have a bit of extra memory means the garbage collector   
   > doesn't have to work as hard.   
      
   Right, GC in general requires more memory than manual allocation.   
   However, real-time GC does not take any more memory than any other GC.   
   (As far as I know, at least.)  And to top it all off, many GC   
   strategies perform better as more memory is available; they often have   
   a performance factor related to the ratio of garbage to good stuff,   
   and more garbage is better.   
      
      
      
   > More important, it allows keeping some   
   > extra free memory available under all conditions, insuring that the main   
   > processing never has to wait for memory.   
      
   Absolutely -- you can allocate some memory manually and some memory   
   under the GC.   
      
      
      
   > Real-time programmers get   
   > unhappy if their code has to endure unexpected waits. ("Fire the retro   
   > rockets 15 seconds ago" isn't an acceptable result.)   
      
   Right, that's why you need a special kind of GC.   
      
      
      
   > It is possible to collect garbage as a background process. This isn't   
   > new -- Dijkstra worked out the details for one approach back in the mid   
   > 1970s.   
      
   This is roughly what we were talking about.  You not only want to do   
   GC in parallel to the main work, but you want a *guarantee* that   
   memory will be available when it is needed.  The guarantee is hard,   
   and requires the GC to be written very carefully.  The research in   
   this area continues; if the 1970 paper you quote just says to run it   
   in a separate thread, then it is not the same thing.  And anyway,   
   there is much newer work than this.   
      
   You almost certainly do not want to literally have a separate process   
   for GC.  Processes can *possibly* simplify the code for any algorithm   
   (I see the opposite more often, due to locking issues), but they tend   
   to greatly complicate the analysis.  Instead, the few systems I have   
   read about will do a little bit of GC at each of various memory   
   activities such as reading, writing, and creating new objects.   
      
      
   > If you have either excess CPU time or can afford a second CPU to   
   > run concurrently, garbage collection need not take much extra time,   
   > perhaps not any at all.   
      
   You probably don't want a second CPU, either, just like you don't want   
   to use processors.  Just use one fast CPU for most problems, and   
   things will be much simpler.   
      
   Also, be careful what you mean by "extra time".  Garbage collection   
   may or may not take more CPU than manual allocation.  Real-time   
   garbage collection, however, is likely to require more time than any   
   other allocation scheme.  But who cares; you can just use a faster   
   CPU.   
      
      
   -Lex   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)