Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!crdgw1!uunet!news.uu.net!microsoft!jimad From: jimad@microsoft.UUCP (Jim ADCOCK) Newsgroups: comp.lang.c++ Subject: Re: reference counting vs. scanning GC Keywords: locality, large address spaces, reference counting, garbage collection Message-ID: <72460@microsoft.UUCP> Date: 20 May 91 20:34:10 GMT References: <1991Apr24.192424.23745@kestrel.edu> <72149@microsoft.UUCP> <1991May11.054648.2483@kestrel.edu> Reply-To: jimad@microsoft.UUCP (Jim ADCOCK) Organization: Microsoft Corp., Redmond WA Lines: 20 In article boehm@parc.xerox.com (Hans Boehm) writes: |Reality is of course more complicated. Different objects sizes interact, |though this is probably not a major effect, since the number of different |object sizes in a typical data structure is probably small. In our |experience, pages tend to be very nonuniformly populated, even after |a system has been up for quite a while. This helps |the nonmoving allocator, since it can chose not to allocate on nearly |full pages. In which case you're ending up with a situation with old pages, containing un-reclaimed holes. Eventually pages fill up with old long-lived objects, excepting a few holes. Either one ignores those holes, failing to reclaim memory, in which case you don't have a stable persistent system, or one is forced to fill the holes in old pages, in which case you've got new objects spread out across predominantly old pages. The only way around this dilemma is to move objects. Of course, for non-stable systems or even quasi-stable systems, it might be acceptible to "leak" a little memory by never plugging the holes in old pages with new objects. But, unless one can predict a finite lifetime for one's app, you've got to go back and fill those holes eventually.