home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / cplus / 12502 < prev    next >
Encoding:
Internet Message Format  |  1992-08-18  |  2.6 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!wupost!gumby!yale!mintaka.lcs.mit.edu!ai-lab!life.ai.mit.edu!tmb
  2. From: tmb@arolla.idiap.ch (Thomas M. Breuel)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Garbage Collection for C++
  5. Message-ID: <TMB.92Aug18165833@arolla.idiap.ch>
  6. Date: 18 Aug 92 20:58:33 GMT
  7. References: <1992Aug6.014619.2111@ucc.su.OZ.AU> <DAVEG.92Aug13025629@synaptx.synaptics.com>
  8.     <TMB.92Aug16164940@arolla.idiap.ch>
  9.     <1992Aug18.021453.24394@news.mentorg.com>
  10.     <TMB.92Aug18123919@arolla.idiap.ch> <9223122.20958@mulga.cs.mu.OZ.AU>
  11. Sender: news@ai.mit.edu
  12. Reply-To: tmb@idiap.ch
  13. Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
  14.     Perceptive)
  15. Lines: 40
  16. In-reply-to: fjh@munta.cs.mu.OZ.AU's message of 18 Aug 92 12:05:19 GMT
  17.  
  18. In article <9223122.20958@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
  19.  
  20.    tmb@arolla.idiap.ch (Thomas M. Breuel) writes:
  21.  
  22.    >Conservative GC with a "free" function is a safety net. If you don't
  23.    >run out of storage, you don't know it's even there. If you do run out
  24.    >of storage, it lets your program continue to run when it would
  25.    >otherwise have crashed. Whether you want to rely on this feature is up
  26.    >to you, but, in general, I can see no harm in having it in the
  27.    >language...
  28.  
  29.    This presumes that you will only perform garbage collection when there
  30.    is *no* more storage available.
  31.    [...]
  32.    It is therefore essential that a GC version of malloc() sometimes perform
  33.    garbage collection even though there is still (virtual) memory available.
  34.    The question is, how can we do this in a way that does not impact poorly
  35.    on the performance of programs that do mostly manual allocation?
  36.  
  37. I was responding to someone who claimed that GC cost him something
  38. just by being present in the language and applicable to all pointers.
  39.  
  40. If you force concurrent or premature GC on the programmer, the feature
  41. will cost you something even if you don't use it. While I am for GC, I
  42. would be against that; by default, the GC should only be invoked once
  43. there is no more memory(*).
  44.  
  45. Of course, there must exist the usual options to set GC aggressiveness
  46. (e.g., telling the GC to try to maintain a fixed ratio of live data
  47. and free space), and, maybe, even to run the GC concurrently with the
  48. C++ program.
  49.  
  50.                         Thomas.
  51.  
  52.  
  53. (*) What this means is implementation dependent. On virtual memory
  54. machines, a sensible default notion of "no more memory" would be "no
  55. more real memory", since for most programs, performace becomes
  56. extremely once you start paging anyway. Under DOS, I think it's pretty
  57. clear what "no more memory" means.
  58.