home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / cplus / 12730 < prev    next >
Encoding:
Text File  |  1992-08-21  |  2.2 KB  |  47 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!decwrl!parc!boehm
  3. From: boehm@parc.xerox.com (Hans Boehm)
  4. Subject: Re: Garbage Collection for C++
  5. Message-ID: <boehm.714410546@siria>
  6. Sender: news@parc.xerox.com
  7. Organization: Xerox PARC
  8. References: <TMB.92Aug16164940@arolla.idiap.ch> <1992Aug18.021453.24394@news.mentorg.com> <DAVEG.92Aug17224359@synaptx.synaptics.com> <1992Aug20.213720.16599@microsoft.com>
  9. Date: 21 Aug 92 15:22:26 GMT
  10. Lines: 35
  11.  
  12. jimad@microsoft.com (Jim Adcock) writes:
  13. >In generation schemes, both long-lived and short-lived objects have
  14. >allocation and deallocations costs that are very very small -- IE "0"
  15. >There are significant allocation and deallocation costs only for object
  16. >that fall in between these two extremes -- objects that live to be middle
  17. >aged.  And the cost of these objects is not really the cost of allocating
  18. >or deallocating them, but rather the cost of keeping them young.
  19.  
  20. Could you clarify your accounting for long-lived objects here?  Are you
  21. assuming that you know at allocation time that the object will be
  22. permanent?  Otherwise it must be copied at least once out of the youngest
  23. generation.  That's certainly nonzero cost.  Furthermore, it will probably
  24. be copied (or traced) several more times as the result of full collections.
  25. (If I don't know that all my objects are essentially permanent, and I
  26. see my heap growing, I presumably have to initiate full collections
  27. occasionally.)  In addition to this, I need some way of tracking
  28. pointer stores into the old object.  I would claim that all of this adds
  29. up to significantly more than malloc/free time for the object.
  30.  
  31. Generational (esp. copying) collectors win dramatically on short-lived
  32. objects, provided you have some efficient way of tracking stores
  33. into old objects.  Fortunately most objects fall into this category
  34. for most programs.
  35.  
  36. (Ben Zorn has some measurements that substantiate this for some
  37. interesting C programs.  It is clearly the case for all known
  38. Lisp and Smalltalk implementations.)
  39.  
  40. A generational copying collector is probably the worst possible choice if
  41. all your program allocates are large long-lived bitmaps  (and indeed
  42. generational copying collectors usually treat such things as a special
  43. case).
  44.  
  45. Hans-J. Boehm
  46. (boehm@parc.xerox.com)
  47.