home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / object / 2947 < prev    next >
Encoding:
Text File  |  1992-07-21  |  2.2 KB  |  49 lines
  1. Newsgroups: comp.object
  2. Path: sparky!uunet!decwrl!deccrl!news.crl.dec.com!rdg.dec.com!jch
  3. From: jch@rdg.dec.com (John Haxby)
  4. Subject: Re: Is GC needed?
  5. Message-ID: <1992Jul21.145534.1967@rdg.dec.com>
  6. Keywords: robust
  7. Sender: news@rdg.dec.com (Mr News)
  8. Organization: Digital Equipment Corporation
  9. References: <1992Jul8.012152.28375@clam.ssw.de> <1992Jul10.165626.7864@visix.com> <1992Jul13.133931.27924@bony1.bony.com> <5677@osc.COM>
  10. Date: Tue, 21 Jul 1992 14:55:34 GMT
  11. Lines: 36
  12.  
  13. In article <5677@osc.COM>, jgk@osc.COM (Joe Keane) writes:
  14. |> In article <1992Jul13.133931.27924@bony1.bony.com> richieb@bony1.bony.com
  15. |> (Richard Bielak) writes:
  16. |> >Actually a problem much worse than memory leaks, is the problem of multiple
  17. |> >deallocations. Multiple deallocation of the same chunk of memory is usually
  18. |> >fatal...
  19.  
  20. [Comments about much improved allocators deleted]
  21.  
  22. GC is also needed to remove inter-module dependencies.
  23. For examlpe, there was a bug in BSD4.2 with certain ethernet drivers
  24. that showed up as a memory leak.  Basically, the IP code passed buffer
  25. to the driver and forgot about it.  However, the driver did not free the
  26. buffer since it couldn't tell whether or not the IP layer had done with it.
  27.  
  28. There are two equally inglamous ways of fixing this: one is to provide
  29. reference counts in buffer headers, the second is for the IP layer to give
  30. a copy of the buffer to the driver.  Both have been tried, both work.  The
  31. second is slow and wasteful, the first requires a substantial re-write of the
  32. kernel's memory management: essentially to introduce a reference counting
  33. collector. I hope the cyclic references are dealt with....
  34.  
  35. Garbage collectors can be made arbitrarily fast given enough memory,
  36. though that is a poor excuse.  However, reasonable garbage collectors in
  37. sensible amounts of memory can give significant performance improvement.
  38. Even stop-and-wait collectors can cut the down time to half a second and
  39. still keep good performance.  Incremental collectors don't even have this
  40. problem.
  41.  
  42. -- 
  43. John Haxby, Definitively Wrong.
  44. Digital                <jch@rdg.dec.com>
  45. Reading, England        <...!ukc!wessex!jch>
  46.  
  47. ----------------------------------------------------------------
  48. The opinions expressed herein are my own, not my employers.
  49.