home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / cplus / 12496 < prev    next >
Encoding:
Text File  |  1992-08-18  |  1.8 KB  |  39 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!munnari.oz.au!cs.mu.OZ.AU!munta.cs.mu.OZ.AU!fjh
  3. From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
  4. Subject: Re: Garbage Collection for C++
  5. Message-ID: <9223122.20958@mulga.cs.mu.OZ.AU>
  6. Sender: news@cs.mu.OZ.AU
  7. Organization: Computer Science, University of Melbourne, Australia
  8. References: <1992Aug6.014619.2111@ucc.su.OZ.AU> <DAVEG.92Aug13025629@synaptx.synaptics.com>     <TMB.92Aug16164940@arolla.idiap.ch>     <1992Aug18.021453.24394@news.mentorg.com> <TMB.92Aug18123919@arolla.idiap.ch>
  9. Date: Tue, 18 Aug 1992 12:05:19 GMT
  10. Lines: 27
  11.  
  12. tmb@arolla.idiap.ch (Thomas M. Breuel) writes:
  13.  
  14. >Conservative GC with a "free" function is a safety net. If you don't
  15. >run out of storage, you don't know it's even there. If you do run out
  16. >of storage, it lets your program continue to run when it would
  17. >otherwise have crashed. Whether you want to rely on this feature is up
  18. >to you, but, in general, I can see no harm in having it in the
  19. >language...
  20.  
  21. This presumes that you will only perform garbage collection when there
  22. is *no* more storage available.
  23.  
  24. In fact that strategy amounts to the "bad old days" of GC, where programs
  25. that used GC were resource hogs, ran slowly, and/or paused for lengthy
  26. periods displaying the dreaded message "Garbage collecting... please wait".
  27. It simply does not work with virtual memory.
  28.  
  29. It is therefore essential that a GC version of malloc() sometimes perform
  30. garbage collection even though there is still (virtual) memory available.
  31. The question is, how can we do this in a way that does not impact poorly
  32. on the performance of programs that do mostly manual allocation?
  33.  
  34. -- 
  35. Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
  36. This .signature VIRUS is a self-referential statement that is true - but 
  37. you will only be able to consistently believe it if you copy it to your own
  38. .signature file!
  39.