Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!ucselx!petunia!kestrel.edu!gyro From: gyro@kestrel.edu (Scott Layson Burson) Newsgroups: comp.lang.c++ Subject: Re: reference counting vs. scanning GC Keywords: locality, large address spaces, reference counting, garbage collection Message-ID: <1991May11.054648.2483@kestrel.edu> Date: 11 May 91 05:46:48 GMT References: <1991Apr24.192424.23745@kestrel.edu> <72149@microsoft.UUCP> Organization: Kestrel Institute, Palo Alto, CA Lines: 25 In article boehm@parc.xerox.com (Hans Boehm) writes: >Fixed placement allocators typically allocate successively allocated >objects close to each other. (If they don't, they should.) They don't, at least not when used simplistically. When objects are freed, allocators attempt to reuse the space they took up. The strategies for doing this vary, of course, but the bottom line is that after a lot of allocations and freeings, successively allocated objects get less and less likely to be close to each other. One factor that exacerbates the problem greatly is allocating short-lived and long-lived objects in the same space. So it would seem that the first thing to do would be to try to segregate objects by expected lifetime. To whatever extent that can be done in a particular application, I think it's a good start on the problem, but it isn't always possible to do it very well. Bartlett's generational collector may be a lifesaver for certain applications people I know are working on. I haven't yet heard of anyone who's done a SPARC/G++ port, however. -- Scott Gyro@Reasoning.COM