home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / compiler / 1368 < prev    next >
Encoding:
Internet Message Format  |  1992-08-13  |  1.5 KB
  1. Path: sparky!uunet!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!rutgers!faatcrl!iecc!compilers-sender
  2. From: David.Chase@Eng.Sun.COM (David Chase)
  3. Newsgroups: comp.compilers
  4. Subject: Re: Garbage Collection
  5. Keywords: storage, GC
  6. Message-ID: <92-08-067@comp.compilers>
  7. Date: 13 Aug 92 21:42:09 GMT
  8. References: <92-08-056@comp.compilers> <92-08-045@comp.compilers>
  9. Sender: compilers-sender@iecc.cambridge.ma.us
  10. Reply-To: David.Chase@Eng.Sun.COM (David Chase)
  11. Organization: Compilers Central
  12. Lines: 23
  13. Approved: compilers@iecc.cambridge.ma.us
  14.  
  15. >        Correct me if I'm wrong, but you seem to be saying that you're
  16. > using the stack and the registers as roots of garbage collection.  ...
  17. > If we decide, in an attempt to be _really_conservative_,
  18. > to assume everything is a pointer, then we pay a double penalty: since
  19. > we're wasting time moving junk around, garbage collection takes longer,
  20. > and since we're not reclaiming storage that is actually free, we collect
  21. > more often.
  22.  
  23. >      It seems clear that this naive approach won't be satisfactory, so
  24. > what can we do?
  25.  
  26. I'd suggest reading "Garbage Collection in an Uncooperative
  27. Environment" by Boehm and Weiser in _Software Practice and Experience_,
  28. September 1988.
  29.  
  30. Their naive and clearly unsatisfactory approach works quite well, in
  31. practice.
  32.  
  33. David Chase
  34. Sun
  35. -- 
  36. Send compilers articles to compilers@iecc.cambridge.ma.us or
  37. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  38.