Re: Strong/weak pointers

GPS <georgeps@xmission.com>
Sat, 6 Sep 2008 18:58:15 +0000 (UTC)

          From comp.compilers

Related articles
[4 earlier articles]
Re: Strong/weak pointers torbenm@pc-003.diku.dk (2008-09-02)
Re: Strong/weak pointers mailbox@dmitry-kazakov.de (Dmitry A. Kazakov) (2008-09-02)
Re: Strong/weak pointers armelasselin@hotmail.com (Armel) (2008-09-03)
Re: Strong/weak pointers gah@ugcs.caltech.edu (glen herrmannsfeldt) (2008-09-03)
Re: Strong/weak pointers james.williams1952@gmail.com (JW) (2008-09-03)
Re: Strong/weak pointers lerno@dragonascendant.com (=?ISO-8859-1?Q?Christoffer_Lern=F6?=) (2008-09-04)
Re: Strong/weak pointers georgeps@xmission.com (GPS) (2008-09-06)
| List of all articles for this month |

From: GPS <georgeps@xmission.com>
Newsgroups: comp.compilers
Date: Sat, 6 Sep 2008 18:58:15 +0000 (UTC)
Organization: nil
References: 08-09-004 08-09-012
Keywords: types, storage, comment
Posted-Date: 07 Sep 2008 17:34:23 EDT

Torben Fgidius Mogensen wrote:
> Michiel Helvensteijn <m.helvensteijn@gmail.com> writes:
>
>> My colleague and I are discussing the non-trivial problem of how the
>> pointers should behave in our new programming language. Most important
>> for us is that the pointers are 'safe'. That is, we wish to eliminate
>> dangling pointers and memory leaks. Even if this has a runtime and
>> memory penalty. Note that there is no pointer arithmetic in our
>> language, so it is also safe in that regard.
>>
>> The hope is that a lot of the runtime penalties may be eliminated with
>> the help of our our theoretical proof system. But that's not what this
>> post is about.
>>
>> Strong pointers (at least our version) behave as follows: You may set
>> a strong pointer to null, or make it point to an object. As long as at
>> least one strong pointer points to an object, the object will never be
>> destructed. So this effectively eliminates dangling pointers. To do
>> this we use a reference counter attached to the object.
>>
>> We are aware of the fact that this does not completely eliminate
>> memory leaks, since the pointers can indirectly reference
>> themselves. We're not sure what to do about this. We may leave it to
>> the programmer to avoid. Or we may actually try to find isolated
>> cycles at any pointer de/re-allocation (but only in debug mode, of
>> course).
>
> Why not use a better garbage collection method? Reference counting is
> slow and (as you say) does not handle cycles. A simple and reasonably
> fast GC is the two-space stop-and-copy. It can move objects around,
> so you should not allow comparison of pointers except for equality
> (i.e., avoid < and similar operators) and avoid casting integers to
> pointers and vice-versa.


Reference counting can handle cycles as I understand it, with certain
constraints.


Daniel P. Friedman, and David S. Wise in 1979 wrote a paper titled:
_Reference counting can manage the circular environments of mutual
recursion_ That paper is referenced by Knuth in his TAOCP Volume 1
under Lists and Garbage Collection.


I've wanted to figure out the methods used in that paper for a while...
Unfortunately it seems you need an ACM account, or you have to purchase
the article from one of the 2 sources.


There may be something more recent available. Does anyone here know of
anything more recent?




George
[The last time I checked, the ACM only charged $5 per article if you
don't have a site license. -John]


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.