home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / cplus / 12387 < prev    next >
Encoding:
Text File  |  1992-08-15  |  2.5 KB  |  58 lines

  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!munnari.oz.au!metro!extro.ucc.su.OZ.AU!maxtal
  3. From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
  4. Subject: Re: Garbage Collection for C++
  5. Message-ID: <1992Aug16.052233.23166@ucc.su.OZ.AU>
  6. Sender: news@ucc.su.OZ.AU
  7. Nntp-Posting-Host: extro.ucc.su.oz.au
  8. Organization: MAXTAL P/L C/- University Computing Centre, Sydney
  9. References: <1992Aug13.153211.16572@ericsson.se> <1992Aug14.101226.6929@ericsson.se> <1992Aug15.005542.3104@news.mentorg.com>
  10. Date: Sun, 16 Aug 1992 05:22:33 GMT
  11. Lines: 45
  12.  
  13. In article <1992Aug15.005542.3104@news.mentorg.com> bcannard@hppcb36.mentorg.com (Bob Cannard @ PCB x5565) writes:
  14. >
  15. >Reference counting suffers serious drawbacks:
  16. >
  17. >1. It can't handle cyclic data structures
  18. >
  19. >2. It is one of the most inefficient forms of garbage collection known to man.
  20. >
  21. >The main reason I'm pushing for true garbage collection is that I consider
  22. >reference counting (which I already have) to be an unacceptably poor solution.
  23.  
  24.     Mm. Reference counting used to implement 'write on demand' in
  25. copy contructors is supposedly inefficient. But this is not at all
  26. the same as reference counting for garbage collection. In copy contructors,
  27. you have to check the reference count before each write operation,
  28. and if its not 1, clone off a copy of the object. Thats slow.
  29.  
  30.     But for GC you only have to increment the reference count
  31. when you take the address of the object to form a GC pointer,
  32. decrement it when the pointer is destroyed, and destroy the 
  33. object when the count goes to 0. That doesn't seem to be so slow
  34. to me: please correct me if I'm wrong.
  35.  
  36.     The basics of GC are that each object must be rooted.
  37. Rooted normally means accessible via a static or auto pointer,
  38. directly or indirectly. Non-rooted objects are garbage.
  39.  
  40.     The definition of rooted above is useless, however,
  41. in modern Windowing systems. In Windows 3 for example,
  42. the objects may be rooted in the operating system memory
  43. for a Window, typically between events the user program
  44. has no stack at all.
  45.  
  46.     In such systems we would have to be very careful using
  47. stack scanning garbage collectors: they would fail totally.
  48.  
  49.     Interestingly, objects allocated under Windows
  50. are already subject to automatic compaction, and even garbage
  51. collection on a task by task basis.
  52.  
  53. -- 
  54. ;----------------------------------------------------------------------
  55.         JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
  56.     Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
  57. ;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
  58.