Path: utzoo!attcan!uunet!microsoft!jimad From: jimad@microsoft.UUCP (Jim ADCOCK) Newsgroups: comp.object Subject: Re: C++ and garbage collection Message-ID: <57823@microsoft.UUCP> Date: 28 Sep 90 21:29:29 GMT References: <2030@aber-cs.UUCP> <57695@microsoft.UUCP> Reply-To: jimad@microsoft.UUCP (Jim ADCOCK) Organization: Microsoft Corp., Redmond WA Lines: 44 In article pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: |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++. Sorry, I think I have still not made clear my point. The N^2'd-ness of the problem is not due to programmer's mixing near and far pointers, but rather due to compilers forced to target machines with separate registers for the segment and offset parts of a far pointer. When a compiler needs to reuse one of those registers, the isolated segment, or offset part of the far pointer in that particular register is spilled to a temp on stack. Thus, it's the spilling of the individual registers making up a segment:offset pair that causes the N^2'd-ness. If you were willing to write a new compiler that was willing to take the performance and code size hit of always keeping and spilling segment:offset registers in pairs, then you could keep it down to a size N problem. But, while you could claim that compilers could be rewritten to spill the segment:offset registers as a pair, todays optimizing compilers has good understanding of how to optimize on shared segments between pointer variables, so that forcing the compiler to maintain segment:offset registers as pairs would be a significant optimization hit. Not to mention a compiler rewrite. Hence my claim that conservative GC makes some sense for 0:32 machines, but little for 16:16 machines. I've used Boehms GC on 0:32 machines, and was quite happy with it. Just doesn't work on 16:16 machines with present compilers, though.