home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / lang / cplus / 13347 < prev    next >
Encoding:
Text File  |  1992-09-08  |  1.5 KB  |  35 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!decwrl!parc!boehm
  3. From: boehm@parc.xerox.com (Hans Boehm)
  4. Subject: Re: Garbage Collection for C++
  5. Message-ID: <boehm.715281775@siria>
  6. Sender: news@parc.xerox.com
  7. Organization: Xerox PARC
  8. References: <DAVEG.92Aug17224359@synaptx.synaptics.com>     <1992Aug20.213720.16599@microsoft.com> <boehm.714410546@siria>     <1992Aug25.185458.10190@microsoft.com> <boehm.714847027@siria> <TMB.92Aug29175419@arolla.idiap.ch>
  9. Date: 31 Aug 92 17:22:55 GMT
  10. Lines: 23
  11.  
  12. tmb@arolla.idiap.ch (Thomas M. Breuel) writes:
  13. >To inject some real-world data again, fragmentation can be a problem.
  14. >I have a machine with about 200M swap space, and a program that only
  15. >needed about half that much memory ran out of memory because of
  16. >fragmentation.
  17.  
  18. Could you give more details as to which allocator this was?  Even
  19. with nonmoving allocators, there is a lot of variation as to how
  20. much fragmentation they introduce.
  21. As I've said before, we have yet to see this sort of ratio
  22. with an allocator that coalesces large objects, and coalesces small objects
  23. if an entire page is free.  And I have seen significant fragmentation
  24. primarily in situations (multiple very large object allocations) in
  25. which moving collection would have been expensive.
  26. Of course, your application may have been different from mine ...
  27.  
  28. But it certainly is the case that if you can move objects, you have some
  29. hope of obtaining a provable upper bound on space consumption, something
  30. you're unlikely to be able to do with either malloc/free or a nonmoving
  31. collector.
  32.  
  33. Hans-J. Boehm
  34. (boehm@parc.xerox.com)
  35.