home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 17653 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.0 KB
  1. Path: lll-winken.llnl.gov!parc!boehm
  2. From: boehm@parc.xerox.com (Hans Boehm)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Why don't you use garbage collection
  5. Date: 16 Apr 1996 23:06:45 GMT
  6. Organization: Xerox Palo Alto Research Center
  7. Message-ID: <4l1965$oaa@news.parc.xerox.com>
  8. References: <4kiai0$mjd@dfw-ixnews8.ix.netcom.com> <66iHfO6PoYB@37.viking.ruhr.com>
  9. NNTP-Posting-Host: siria.parc.xerox.com
  10. X-Newsreader: NN version 6.5.0 #8 (NOV)
  11.  
  12. gasper@viking.ruhr.com (Ortwin Gasper) writes:
  13. >- If you want that a program never fails if the amount of needed memory m
  14. >  is <= C*n with n = the available memory and C a constant 0 < C <= 1, you
  15. >  must use copying collectors. But in this case, you can't program in
  16. >  'normal' C++. You must remember the position of all pointers to the
  17. >  collected area, you must handle problems like 'what happens if the
  18. >  collector moves a class object while there is a stack frame from a
  19. >  member function of this object still valid'.
  20. >  ==> You can write C++-Programs using such a collector, but these
  21. >  programs won't look like C++, are hard to debug (and slow).
  22.  
  23. If you substitute "compacting" for "copying", then I basically agree.
  24. (There are also sliding compacting collectors that compact in place.
  25. I believe they're sometimes the right solution.)
  26.  
  27. But it's important to remember:
  28.  
  29. 1. This problem isn't limited to garbage collection.  Malloc and new
  30. have the same problem.
  31. 2. Evidence I've seen so far suggests that the problem is typically not serious
  32. with a good allocator.  Fragmentation cost is almost always much less than the
  33. factor of 2 lost by a traditional copying collector.  It still matters if
  34. worst-case space usage is a real issue, but probably not if you are trying to
  35. minimize expected case space usage.  Admittedly the evidence I've seen
  36. hasn't included applications that run for years.
  37. 3. There exist bad allocators.  (Our garbage collector is not ideal in this
  38. respect, though it usually doesn't do too badly.)
  39.  
  40. Hans-J. Boehm
  41. (boehm@parc.xerox.com)
  42. Standard disclaimer ...
  43.