Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!uunet!cimshop!davidm From: cimshop!davidm@uunet.UU.NET (David S. Masterson) Newsgroups: comp.lang.c++ Subject: Re: Smart pointers and stupid people (was: garbage collection...) Message-ID: Date: 2 Jan 91 19:30:26 GMT References: <1990Dec20.045909.7681@rice.edu> <3071@lupine.NCD.COM> <4114@osc.COM> <4120@osc.COM> Sender: davidm@cimshop.UUCP Distribution: comp Organization: Consilium Inc., Mountain View, California Lines: 79 In-reply-to: tma@osc.COM's message of 1 Jan 91 06:58:23 GMT X-Posting-Software: GNUS 3.12 [ NNTP-based News Reader for GNU Emacs ] >>>>>> On 27 Dec 90 06:29:19 GMT, tma@osc.COM (Tim Atkins) said: Tim> Smart pointers are not any sort of real solution to problems of pointer Tim> maintenance in the face of any sort of object movement including that Tim> found in copying garbage collectors. The reason is simply that Tim> regardless of how smart your pointer type is, at some point it is Tim> evaluated to a real pointer and stored into some temp variable and or is Tim> sitting around on the stack or in registers. It is precisely these Tim> implied direct pointers built behind the scenes that give the biggest Tim> headaches. Without some way of knowing exactly where all pointers and Tim> "internal" pointers are, there is simply no way to move objects around Tim> and update pointers safely in C++. >>>>> On 28 Dec 90 22:41:14 GMT, cimshop!davidm@uunet.UU.NET (David S. Masterson) said: David> Object movement should be as easily accomplished in C++ as it would be David> in any other language. Ensuring internal consistency of pointers is David> just a locking problem to make sure that pointers are not dereferenced David> before they are valid. Smart pointers should be able to handle lock David> primitives in concert with a garbage collection routine to ensure that David> they don't go to the actual data while the garbage collection is in David> progress. >>>>> On 1 Jan 91 06:58:23 GMT, tma@osc.COM (Tim Atkins) said: Tim> If I have a smart pointer and, for instance, reference a field of the Tim> underlying object as a parameter that is passed to another function, then Tim> the real pointer is most definitely in some temporary location on the Tim> stack for at least the duration of that function call. Actually in 2.0 Tim> implementations it seems to remain on the stack for at least the duration Tim> of the surrounding block if not the duration of the entire enclosing Tim> function. If anything promotes a low memory condition during this time Tim> that requires a garbage collect then there is at least one unplanned Tim> direct pointer in stack space. How are you planning to identify such Tim> pointers and distinquish them from other data types that might have the Tim> exact same bit pattern? This was and is the substance of my objection. An off-the-cuff C++ approach to handling objects that may be garbage collected and the pointers that point to them: 1. The garbage collection routines (GC) would have full knowledge of the type of objects that can be garbage collected, how they would be moved, and how to clean up pointers to those objects. This implies that the "direct" pointers to garbage collected objects are in a "well-known" place (PtrList). 2. These "direct" pointers can, therefore, be allocated as an object is created and put in the list in an indexable fashion for the "smart" pointers to reference. There should only be one static list of these pointers so that the GC can find them when its needs to do some shuffling. 3. (As Marshall Cline suggested) Smart pointers would be the only thing that creates the actual object. Thus, creating a "smart" pointer would create the object that it points to and have its "direct" pointer entered into the static list. The "smart" pointer would maintain an index into the static list of "direct" pointers that corresponds to its object. 4. When GC decides to move an object, it uses the old address to index (somehow) into the static list of pointers and replaces that address with the new address of the object. GC should only move entire objects. 5. When a "smart" pointer needs to dereference the object it points to, it uses its smart index to find the real address from the static pointer list. This probably the definition of the overloaded "->" operator on the smart pointer. 6. The only problem left is ensuring that (4) and (5) do not step on one another. This should be accomplished via a locking protocol that both (4) and (5) pay attention to. When (4) finds a candidate object to move, it checks its lock status (perhaps in the static pointer list), and moves it when it isn't locked. When (5) decides to dereference an object, it checks its lock status, and waits till the object is free to dereference it. This protocol isn't necessarily efficient, but its flexible and should be improvable. -- ==================================================================== David Masterson Consilium, Inc. (415) 691-6311 640 Clyde Ct. uunet!cimshop!davidm Mtn. View, CA 94043 ==================================================================== "If someone thinks they know what I said, then I didn't say it!"