Path: utzoo!attcan!uunet!mcsun!ukc!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: 27 Sep 90 19:16:29 GMT References: <2030@aber-cs.UUCP> <57695@microsoft.UUCP> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 50 Nntp-Posting-Host: odin In-reply-to: tom@ssd.csd.harris.com's message of 26 Sep 90 11:54:55 GMT Posting-Front-End: GNU Emacs 18.55.4 of Thu Nov 23 1989 on athene (berkeley-unix) >>>>> Regarding Re: C++ and garbage collection; pcg@cs.aber.ac.uk >>>>> (Piercarlo Grandi) adds: pcg> Also, I think that it is not terribly difficult to rework those pcg> applications so that they use only near or only far pointer, and at a pcg> probably tolerable cost in (space) efficiency. After all, nothing pcg> forces you to use near and far pointers in the same program; I would pcg> even say that strictly speaking this is not possible in C++. On 26 Sep 90 11:54:55 GMT, tom@ssd.csd.harris.com (Tom Horsley) said: A lot of agreeable things (Go for the AviiON!), but also: tom> Saying, "OK, well I'll just use far pointers for everything" is a tom> sure-fire way to make a 30 second task take 2 hours. OK, we are no longer discussing on the high plane points of language definitions and interface contracts etc...; here we are discussing howe to fight with an hostile environment and how to play it dirty safely. So, you can consider three points: 1) if using far/near pointers makes you use a vastly inferior storage reclaimer, as a naive reference counting one may be, then the saving from conservative g.c. may be greater than the overhead of using far pointers alone. 2) it is my experience that the exclusive use of far pointers slows down (or grows in space) even pointer intensive programs by something around 30%; a far pointer dereferencing operation takes about double the cycles of a near pointer dereference, plus a few extra instructions to laod the segment register, so at most the speed is impacted by 2-3 times if the program does *only* pointer dereferences. 3) if you use near/far pointers you are playing it dirty, because you are specifically accepting the idea that you are doing special case programming for performance reason. So, let me observe that in most every case you use near pointers as offsets (relative pointers) in some data structure to which you have somewhere a far pointer; it is from this far pointer that you get the segment selector after all. Well, the far pointer will protect the whole data structure from reclamation. Now, if you also want to reclaim storage *within* that data structure, there yopu have problems, and need some compiler assistance. You don't have it? Tough. Complain to your comnpiler vendor that ehri compiler does not support g.c. (conservative or otherwise) and so deprives you of consistent performance and safety benefits. -- 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