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) |
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]
Return to the
comp.compilers page.
Search the
comp.compilers archives again.