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 (Was: Re: What is Objective C?) Message-ID: Date: 17 Sep 90 14:27:46 GMT References: <1990Sep12.074154.657@tukki.jyu.fi> <1990Sep16.090226.11051@tukki.jyu.fi> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 82 Nntp-Posting-Host: odin In-reply-to: sakkinen@tukki.jyu.fi's message of 16 Sep 90 09:02:26 GMT On 16 Sep 90 09:02:26 GMT, sakkinen@tukki.jyu.fi (Markku Sakkinen) said: sakkinen> In article sakkinen> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: pcg> If we are to speak about actual, and not just _legal_ C/C++ programs, pcg> *some* programs do things that are illegal (far fewer than is commonly pcg> thought of), but those same C++ programs will not fail under pcg> conservative garbage collection, they will just accumulate more pcg> unreclaimed garbage, and on average not much of it. sakkinen> Wrong! It is fully possible that illegal code will reference sakkinen> an area of storage You could support this statement by producing a *single* example where a storage manager using conservative automatic storage reclamation will deallocate as garbage an area of storage that is in use. The definition of "in use" being that its address as if returned by the storage allocator appears in one or more pointers in storage. If you are using any other definition of "in use" you are making your own rules, and we are no longer speaking of storage allocation or reclamation as is described in the current academic literature on the subject. You are allowed any means of producing a pointer word in the same representation as that returned by the storage allocator (e.g. malloc(3)) and and understood by the deallocator (e.g. free(3)) -- any form of pointer arithmetic, whether legal or illegal. Naturally you are *not* allowed to change the representation of pointers from the one used by the language and the storage manager -- for example you are not allowed to encrypt pointers, or to write pointers in a different byte order than the standard machine byte order, or to use strings as pointers, or to keep pointers in a file on disc. sakkinen> that has looked as garbage to the most conservative GC sakkinen> routine. Notice that garbage collectors could not care less about the contents of data space areas (except where they contain pointers, of course) -- no storage reclamation algorithm looks at the contents of a given data area to determine whether that data area can be reclaimed or not. Also, there is no degree of conservativeness in a storage reclaimer -- either it is conservative, and it will consider as a pointer any word whose numeric value can be interpreted as an address into the heap, or it is not conservative, and it *knows* which words are pointers. sakkinen> This was even admitted in Boehm and Weiser's paper. This is a misunderstanding of what they say: they say that storage reclamation, in general, whether manual or automatic, is only possible when the user program does not change the representation of pointers. Even free(3) will fail if you pass it an encrypted or XOR-ed or otherwise encoded form of a pointer. I would insist in my belief that most application programmers should not and would not care to understand how the storage manager works, in both its allocator and reclaimer components. Just as most users of malloc(3) do not know or understand which is the allocation algorithm and policy used by the allocator, they should leave reclamation to the storage manager's automatic reclaimer, to avoid all the pitfalls that only a system programmer will have carefully avoided. It is *much* safer for application programmers to leave reclamation in the hands of a purpose built reclaimer, than to try to design their own reclamation policy and algorithm, and even system programmers, that know the problems, find manual storage reclamation difficult to get right. Of course, for particularly important applications, in which particular allocation and reclamation policies may be beneficial, programmers may well acquire system programmer knowledge and roll their own storage manager implementation, automatic or manual that may be -- this is one of the great advantages of C/C++ as SILs/MOHLLs, that you can override the default storage manager, something that is not possible in languages like Pascal or Ada, but here I guess I am preaching to the converted :-). -- 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