home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / cplus / 12898 < prev    next >
Encoding:
Text File  |  1992-08-25  |  3.4 KB  |  66 lines

  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!microsoft!hexnut!jimad
  3. From: jimad@microsoft.com (Jim Adcock)
  4. Subject: Re: Garbage Collection for C++
  5. Message-ID: <1992Aug25.185458.10190@microsoft.com>
  6. Date: 25 Aug 92 18:54:58 GMT
  7. Organization: Microsoft Corporation
  8. References: <DAVEG.92Aug17224359@synaptx.synaptics.com> <1992Aug20.213720.16599@microsoft.com> <boehm.714410546@siria>
  9. Lines: 55
  10.  
  11. In article <boehm.714410546@siria> boehm@parc.xerox.com (Hans Boehm) writes:
  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. My accounting is simply that the cost of keeping an object alive is
  32. not the cost of either allocating or deallocating the object.  Before you
  33. cry "foul" please note that non-moveable-object memory management schemes
  34. *also* have a cost of keeping objects alive -- namely their non-locality
  35. of reference leads to costs of cache misses, page turns, and ultimately
  36. thrashing on heavily loaded systems.  Such costs need to be factored into
  37. the cost of any memory management scheme -- but estimating such costs is
  38. extremely variable depending on a given system and how that system is loaded.
  39. Whereas the costs of allocating and deallocating can be more reasonably
  40. estimated.
  41.  
  42. |Generational (esp. copying) collectors win dramatically on short-lived
  43. |objects, provided you have some efficient way of tracking stores
  44. |into old objects.  Fortunately most objects fall into this category
  45. |for most programs.
  46. |
  47. |(Ben Zorn has some measurements that substantiate this for some
  48. |interesting C programs.  It is clearly the case for all known
  49. |Lisp and Smalltalk implementations.)
  50.  
  51. I've found surprisingly similar results on a limited number of C++ programs
  52. I've tested.
  53.  
  54. |A generational copying collector is probably the worst possible choice if
  55. |all your program allocates are large long-lived bitmaps  (and indeed
  56. |generational copying collectors usually treat such things as a special
  57. |case).
  58.  
  59. But such cases can already be well handled in C++ using reference counting
  60. schemes.  Again, I see a Modula-3 like approach where classes of objects
  61. are either GC or not GC -- and the GC class objects are movable.  Backwards
  62. compatibility is maintained because adding GC'ed classes is a pure extension.
  63. Moveable objects need to be supported not merely for GC, but for more 
  64. interesting problems of distributed networks, persistence, ODBMS, etc.
  65.  
  66.