Re: Strong/weak pointers

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.


> An important decision we've made is that every variable in the
> language IS a strong pointer. That is, there is no pointer*
> notation. Since an isolated strong pointer behaves just like a simple
> scoped variable, we thought it would be an elegant solution. Besides,
> this will make it easier to implement full closures and such when the
> time comes. To compensate, we have introduced the identity assignment
> operator (<-- as opposed to <-) and the identity comparison operators
> (==, !== as opposed to =, !=).
>
> In most cases, it will be easy to eliminate the runtime cost of this
> decision. If a variable is never used as a pointer, it can be
> allocated on the stack.


I'm not sure what you are trying to say here. Pointers to pointers
are no problem, even if the objects you point to are stack allocated.
You just use the stack as the root set for garbage collection.


> What we're pondering is: should our language also feature weak
> pointers? A weak pointer cannot be the only pointer to an object
> (since an object requires at least one strong pointer reference to
> exist). And when an object is deallocated because of a lack of strong
> pointer references, all weak pointers referencing it become null. They
> WOULD need their own type notation.


Only add weak pointers if you have a very good reason. I suspect you
do not, so don't include them.


Torben

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