Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!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: <72384@microsoft.UUCP>
Date: 16 May 91 17:23:05 GMT
References: <1991Apr24.192424.23745@kestrel.edu> <72149@microsoft.UUCP> <boehm.673720634@siria> <1991May11.054648.2483@kestrel.edu>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 50

In article <1991May11.054648.2483@kestrel.edu> gyro@kestrel.edu (Scott Layson Burson) writes:
|In article <boehm.673720634@siria> 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.

If you think about it, the problem is not where to create objects that
are being born, but where one should have created the object that is 
currently dying.  Because without moving objects, the only way to conveniently
reuse the hole left by a dying object is for that hole to be at "exactly"
the right location for a new object to use.  I don't see any good why to 
predict in advance when an object is going to die, thereby allowing it
to be placed well at time of creation.  Some people claim the right thing to do
is to let the end programmer specify where the object will be created,
either by specifying how long the programmer guesses the object will live:

FOO* pYoungFoo = new (SHORT_LIVED) foo(23);
FOO* pOldFoo = new (LONG_LIVED) foo(123);

or by specifying a neighborhood of objects that are all going to die
at about the same time:

FOO* pYoungFool = new (BELLEVUE) fool(34);
FOO* pOldFool = new (SEATTLE) fool(92);
FOO* pMiddleAgedFool = new (MERCER_ISLAND) fool(45);

I think this is a cop-out, in that the end user [if writing "OOP" classes]
is seldom better equipped to guess the life-time of objects than the 
person writing the memory management routines.  In particular, if one
is writing general-purpose reusable classes, one typically has no idea
at all how objects of those classes are going to be used.  So, I claim
writing reusable classes with explicit placement parameters is troublesome,
at best.  If one cannot, then, successfully predict the lifetime of objects,
so that the hole they leave behind is well placed, one needs to be able
to move that hole to a more useful location.  The only way I cn see to do that 
is either to move objects around, implicitly moving left-behind holes too, 
or by building hardware with virtual memory paging hardware more in tune
with the needs of OOP [how often do we make 4K-sized objects?]

So, I'd like to see C++ have better support for movable objects.