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:03:39 GMT References: <966@exodus.Eng.Sun.COM> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 74 Nntp-Posting-Host: odin In-reply-to: chased@rbbb.Eng.Sun.COM's message of 26 Sep 90 21:45:14 GMT On 26 Sep 90 21:45:14 GMT, chased@rbbb.Eng.Sun.COM (David Chase) said: chased> One thing I haven't noticed yet is mention of transformations chased> applied to pointers by an optimizing compiler. Point one: I do not like optimizing compilers :->. Point two: conservative g.c. *may* require compiler cooperation. Just repeat with me: no storage reclamation policy works under an arbitrary interface contract; what matters is whether the required interface contract is more or less restrictive than the *language* definition, not the interface contract of some existing compiler X. If the interface contracts of a particular conservative g.c. implementation and of a particular compiler X are not compatible, tough. chased> Treating interior pointers as pointers is not a trivial matter. chased> In one application (a Modula-3 compile server) the collector chased> failed to reclaim large amounts of storage. I must confess I am extremely surprised. Hyper-conservative (as you call it) collection tests for possible pointerhood by saying (if value interpreted as an address is within the heap), conservative adds (... and is on an object address boundary). I would tend to think that the first test alone is sufficient to screen out virtually all non-pointers, if the heap addresses are suitably arranged. Maybe you had your heap in low storage (e.g. you were using a heap in the BSS of a BSD derived UNIX) -- to work well conservative g.c. must *at least* count on a cooperative storage allocator design. chased> it seems to me that there is some burden on the proponents of chased> garbage collection in C++ to demonstrate (dare I say, "prove"?) chased> that their collector will work with a gc-ignorant optimizing chased> compiler, There is no such burden -- repeat again: if the compiler has an interface contract, because of optimization or otherwise, that is not compatible with that of the storage reclaimer, tough. What needs to be considered is whether there are no alternative implementation strategies that provide overall (that is compiler + runtime system) better performance. And even if there is a storage reclamation policy that has equal or better performance than g.c. under a certain compilation policy, which is equal or better than any other, one may still prefer conservative g.c. under a not as good compiler, because it is *convenient*. chased> or else I must charge to the collector the time wasted by chased> running unoptimized code. Of course, this needs to be reproved chased> with each new release of the compiler. In the short term, many chased> of these problems can be solved by the use of "volatile", though chased> that won't help my program's speed much either. Ahem -- let's switch the burden of proof: let the proponents of manual storage reclamation, or automatic storage reclamation that uses some policy different from g.c., prove that *their* alternative overall involves less overheads than even 'volatilized' conservative g.c., in a *system wide* comaprison (speed of compiled code + overhead of storage reclamation). You cannot just point at the problems with g.c. in one context and say "ha ha". Yo want to compare the alternatives, which are reclamation done otherwise, or no reclamation at all. Lacking hard data, let's turn to educated guesses (handwaving :->): the leading alternative to conservative g.c., manual or automatic reference counting, seems likely to have a much larger performance impact than the loss of some (dubious IMNHO) compiler optimization; this both in CPU overheads, and in catastrophic worsening of locality under VM, even when the best algorithms are considered. -- 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