Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!edcastle!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.object Subject: Re: C++ and garbage collection Message-ID: Date: 25 Sep 90 16:43:17 GMT References: <2030@aber-cs.UUCP> <57695@microsoft.UUCP> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 49 Nntp-Posting-Host: odin In-reply-to: jimad@microsoft.UUCP's message of 24 Sep 90 21:22:55 GMT On 24 Sep 90 21:22:55 GMT, jimad@microsoft.UUCP (Jim ADCOCK) said: jimad> In article <2030@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo jimad> Grandi) writes: pcg> .... Especially if you can make the storage allocator and compiler pcg> cooperate. jimad> If one has compiler cooperation, *why* would one use conservative jimad> approaches? Because it may entail less overhead. It may be easier just to sweep memory en-masse than to pause to consult (possibly large, complex) type tables. I have been told of one Algol 68 compiler of some years ago, generating C code, that instead of generating type tables as C data structures would use conservative g.c. The idea being that for many common machines the garbage uncollected would cost less than the overhead of really knowing which words are pointers. Not to mention that a conservative g.c. is probably far simpler to commission than one that uses tagging and type tables. As to the other problem raised by Jim Adcock: jimad> On a few machines/os pairs that are interesting from a jimad> "marketing" point of view, including Mac, Dos, OS/2, Windows, jimad> etc, the pointer model chosen is often a 16:16 segment:offset jimad> pair, rather than a 0:32-bit linear address. This would not in jimad> itself be a fatal problem, except that segment and offset are jimad> frequently stored separately, making "find all values that might jimad> be a valid object address" an N^2 problem. You have a point, one cannot always win. If you mix near and far pointers, you get into some trouble (and not just because of conservative g.c.). On the other hand the compiler could help a bit. But then the collector becomes hybridly conservative, I guess. After all, we are back to our previous theme: any storage manager design will not work under any possible condition. Also, I think that it is not terribly difficult to rework those applications so that they use only near or only far pointer, and at a probably tolerable cost in (space) efficiency. After all, nothing forces you to use near and far pointers in the same program; I would even say that strictly speaking this is not possible in C++. -- Piercarlo "Peter" Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk