home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / lang / lisp / 3127 < prev    next >
Encoding:
Internet Message Format  |  1992-12-22  |  1.3 KB
  1. Path: sparky!uunet!cs.utexas.edu!sun-barr!olivea!spool.mu.edu!darwin.sura.net!aplcen.apl.jhu.edu!aplcenmp!hall
  2. From: hall@aplcenmp.apl.jhu.edu (Marty Hall)
  3. Newsgroups: comp.lang.lisp
  4. Subject: Re: Reference counting (was Re: Yet another Lisp Interpreter Available (RefLisp) Long)
  5. Message-ID: <BzMD1E.EGp@aplcenmp.apl.jhu.edu>
  6. Date: 21 Dec 92 17:10:25 GMT
  7. References: <1gk60iINNjg8@iraul1.ira.uka.de> <1992Dec17.200901.20942@uk03.bull.co.uk> <1gr5ejINN3k5@early-bird.think.com>
  8. Organization: AAI Corp AI Lab, JHU P/T CS Faculty
  9. Lines: 19
  10.  
  11. barmar@think.com (Barry Margolin) writes:
  12. >bbirch@hemel.bull.co.uk (Bill Birch) writes:
  13. >>    - RefLisp has reference counting garbage collection, that means
  14. >>      memory is reclaimed as soon as it is un-used. It is a "non-stop"
  15. >>      system, in that there is never any halt for garbage collection (GC).
  16. >
  17. >This is a frequent claim that is simply not true.  A reference counting
  18. >system simply changes the time and distribution of the GC delays, but it
  19. >doesn't eliminate it.  For instance [...]
  20.  
  21. A PostScript version of a good (in my non-expert opinion) survey of GC 
  22. techniques is available by anonymous FTP from cs.utexas.edu, in
  23. /pub/garbage/gcsurvey.ps. 
  24.  
  25. Wilson, Paul R., "Uniprocessor Garbage Collection Techniques", to appear
  26. in _Proceedings of the 1992 International Workshop on Memory Management_.
  27.  
  28.                     - Marty
  29. (proclaim '(inline skates))
  30.