Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!wuarchive!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: <72149@microsoft.UUCP> Date: 3 May 91 19:21:38 GMT References: Reply-To: jimad@microsoft.UUCP (Jim ADCOCK) Organization: Microsoft Corp., Redmond WA Lines: 45 In article <1991Apr24.192424.23745@kestrel.edu| gyro@kestrel.edu (Scott Layson Burson) writes: |This is very definitely a concern I have about C++: that when people |start manipulating 60 Mb worth of objects in one program (and I have |already seen 30 Mb process sizes), that the locality problem is going |to bring their machines to their knees, even though they would have |had no trouble running the same algorithms on the same data in Lisp. |I don't know of any allocation algorithms for C++ that pay any |attention to locality, nor do I really see how there *can* be any, |because the information about what other objects an object X points to |or is pointed to by is not available at the time X is created. |Furthermore, there is no way of doing compaction of live objects. | |As I say, I am very concerned about this. I think the C++ community |is not prepared for the magnitude of the problem. Agreed. I see two major impediments to solving these problems: 1) C++ presently has inadequate support for moveable objects [although a number of vendors have C/C++ compiler extensions for moveable objects] 2) C++ presently has inadequate support for GC [although the problem is very similar to exceptions, so why not kill two birds with one stone?] |Note, by the way, that while class-specific `operator new' and |`operator delete' might sometimes be of help, in the general case -- |in all the cases I have seen -- reference locality is orthogonal to |class boundaries. The "placement" argument to `new' (ARM 5.3.3) is |more likely to be of significant value. A more fundamental problem is that any fixed placement strategy assumes that the patterns of usage of objects is going to remain fixed, but this is not true of any non-trivial app. Thus, the only way to maintain good locality of reference over the long run is to have moveable objects. As an extreme, see Jul's thesis on Emerald, where objects are moved "automatically" over the net to the process where they are needed. I agree with your concerns, but I don't think its too hard to fix these problems with some small changes to C++. Its just that some people don't yet seem to be interested in solving these problems. [In addition to all this, note that overloaded operator dot would make one small contribution towards allowing moveable objects, since such overloading allows C++ programs to abstract the notion of an object distinct from the byte address used to store that object.]