home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / cplus / 13250 < prev    next >
Encoding:
Text File  |  1992-09-02  |  2.7 KB  |  59 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!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.715021105@siria>
  6. Sender: news@parc.xerox.com
  7. Organization: Xerox PARC
  8. References: <DAVEG.92Aug20043156@synaptx.synaptics.com> <28623@vedge.UUCP> <DAVEG.92Aug28004331@synaptx.synaptics.com>
  9. Date: 28 Aug 92 16:58:25 GMT
  10. Lines: 47
  11.  
  12. daveg@synaptics.com (Dave Gillespie) writes:
  13. >This all reminds me of the idea of "finalizations" in Lisp, a
  14. >simple-sounding and very useful concept that turns out to be a
  15. >horrible quagmire of complications when it is implemented.
  16.  
  17. >Basically, a finalization is a property that can be attached to
  18. >any allocated object, which is a function to be called to clean up
  19. >when that object is garbage-collected.  In other words, it's a
  20. >destructor.
  21.  
  22. ...
  23.  
  24.  
  25. >If you made a linked list of N things each of which had destructors,
  26. >it would still take N GC's to delete the list, but the idea is that
  27. >destructors (finalizations) would only be used for the kinds of
  28. >things that are not used in big lists.  For example, a finalization
  29. >might close a file that was held open by the object; rarely would
  30. >you have a linked list of 1000 objects each holding open a file!
  31. >(And where the links are in the objects themselves; a conventional
  32. >Lisp list of pointers to finalizable objects would have no problem,
  33. >because the cons cells themselves have no finalizations and so can
  34. >be collected all at once.)
  35.  
  36. Cedar does something similar.  (So does the latest version of
  37. our conservative stand-alone collector.) Empirically only on the order of
  38. 100 objects (in a 15 MB or so heap) are finalizable at any given point,
  39. and there tends not to be a lot of connectivity between them, for
  40. precisely the reasons you describe.  The most serious (but not
  41. unsolvable) problem is dealing with cycles of finalizable objects.
  42.  
  43. PARCPlace Smalltalk uses a different approach in which a proxy
  44. object is notified of the death of the object it watches.  That's
  45. also quite reasonable.  But it also doesn't suffice to deal with the
  46. circularity issue.
  47.  
  48. Another issue is that at least Cedar finalization allows finalization
  49. to be reenabled on resurrected objects.  This argues perhaps that
  50. finalization and destructors aren't exactly the same.  (My
  51. impression is that C++ destructors also get used instead of
  52. something like the Modula-3 try ... finally construct to perform
  53. an action on any exit from a block.  This use also seems
  54. orthogonal to finalization, which I view as reclaiming nonmemory
  55. resources, and doing only that.)
  56.  
  57. Hans-J. Boehm
  58. (boehm@parc.xerox.com)
  59.