home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / cplus / 13249 < prev    next >
Encoding:
Text File  |  1992-09-02  |  3.1 KB  |  65 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!wupost!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!cbnewsc!cbfsb!att-out!pacbell.com!decwrl!parc!boehm
  3. From: boehm@parc.xerox.com (Hans Boehm)
  4. Subject: Re: Garbage Collection for C++
  5. Message-ID: <boehm.715019515@siria>
  6. Sender: news@parc.xerox.com
  7. Organization: Xerox PARC
  8. References: <DAVEG.92Aug17224359@synaptx.synaptics.com> <boehm.714158406@siria> <DAVEG.92Aug27002517@synaptx.synaptics.com> <4116@seti.UUCP>
  9. Date: 28 Aug 92 16:31:55 GMT
  10. Lines: 53
  11.  
  12. daniel.edelson@goudurix.inria.fr (Daniel Edelson) writes:
  13.  
  14. >In article <DAVEG.92Aug27002517@synaptx.synaptics.com>, daveg@synaptics.com (Dave Gillespie) writes:
  15.  
  16. >|> Simple, conservative non-moving GC can be added with
  17. >|> minimal effect to the rest of the language, and minimal danger of
  18. >|> toppling it.
  19. >|> 
  20. >|> Dave Gillespie
  21.  
  22. >While it is an excellent technique, its worst case behavior is 
  23. >unacceptable, e.g., one false pointer into a very large strongly
  24. >connected data structure.... It's valuable and worth using, and 
  25. >significantly better than anything else that's currently available,
  26. >but does not appear to be a panacea. Its presence does not mean
  27. >that we should stop looking for other solutions.
  28.  
  29. This touches on another serious issue with garbage collection in C++
  30. that I haven't seen discussed - namely that of programming style.
  31. I don't have any experience with large C++ programs.  But I have
  32. seen techniques being advocated that simply don't get along well with
  33. garbage collection of any form.  And they're particularly inappropriate
  34. with conservative collection.  I have no idea whether these are
  35. considered crucial or not.
  36.  
  37. My standard example is a list implementation that consists of a
  38. "linkable elements" class from which one can inherit (possibly multiple
  39. times) to get a link field added to one's data structure.  This
  40. avoids allocating extra cons-cells for lists.  It also leads to a
  41. situation in which objects contain many link fields for many list
  42. structures simultaneously.  This gives great flexibility in traversing
  43. the structure, most of which is usually never used.  But the garbage
  44. collector can't determine that.  In fact, if you draw some pictures, you
  45. can convince yourself that if you do enough of this, you are likely to
  46. eventually connect everything to everything.
  47.  
  48. I claim this is a problem no matter what form of garbage collector you
  49. use.  In the nonconservative case, all it takes is some client who
  50. inadvertently hangs on to a tiny component of your data structure, and
  51. the whole thing gets pinned.  Or the compiler allocates a temporary
  52. that it doesn't destroy soon enough.  In the conservative case, you
  53. also have a problem with a false reference to anywhere in the structure.
  54.  
  55. I don't think this is an insurmountable problem, since the overhead of
  56. using cons-cells is probably pretty minimal in reality (and may be
  57. negative, since you probably didn't really need all those link fields at
  58. once).  But there is a problem with some existing code and programming
  59. styles here.  Interestingly, this seems to be more of a problem with
  60. C++ code than with C code.
  61.  
  62. Hans-J. Boehm
  63. (boehm@parc.xerox.com)
  64.  
  65.