discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Garbage Collection


From: David Chisnall
Subject: Re: Garbage Collection
Date: Wed, 25 May 2011 16:04:19 +0100

On 25 May 2011, at 15:55, Richard Frith-Macdonald wrote:

> 
> On 25 May 2011, at 12:47, David Chisnall wrote:
> 
>> There were also some limitations with the GNUstep approach - aside from 
>> needing programmer effort, which somehow defeats the point of GC.  The lack 
>> of weak references meant that some common patterns caused memory leaks.  For 
>> example, in the traditional retain/release world, an object registers itself 
>> with NSNotificationCenter, which holds an unretained pointer to it, and then 
>> unregisters itself in -dealloc, when it is no longer referenced by anything 
>> else.  In a garbage collected world, NSNotificationCenter has a reference to 
>> the object, so it will never be freed, so can not unregister itself.  The 
>> notification center requires a weak reference, so that the object can be 
>> freed when nothing else holds a reference to it and the notification centre 
>> can then clean up.
> 
> Er ... the GNUstep implementation has always had weak references

I'm assuming that you've not tried using it.  I had a look at the GSWeak... 
stuff, and what it actually did was store a strong reference and tell the Boehm 
GC to clear it when it was finalised (which never happened, because it stored a 
strong reference).  The disappearing link APIs in Boehm do not work how whoever 
wrote that code thinks they worked.

> and didn't need more programmer effort ... it just does it a bit differently 
> from the way Apple later chose.  GNUstep registers weak references for a 
> class at runtime when the class is initialised, while Apple implemented it in 
> the compiler, so the difference in programmer effort is basically whether the 
> programmer calls a function in +initialize or declares a variable as 'weak' 
> in a header.

Ah, you're talking about something different, I should have been more specific. 
 When I say 'weak pointer', I am using the Apple terminology, meaning 'zeroing 
weak pointer', i.e. a pointer that is always either NULL or a valid pointer.  
The way GNUstep implemented them gave you pointers that were either pointers to 
a valid object, or pointers to an invalid memory address, with no way of 
telling which they were.  This removes one of the main advantages of GC: being 
able to assume that object pointers are always valid.

With a __weak id, you can ALWAYS send it messages.  It will either store the 
object that you put there, in which case they will go to an object, or it will 
be nil, in which case they will be ignored.  This is not possible to implement 
in a concurrent environment without a read barrier.  

This is one of the things that I mean by 'more programmer effort'.  With 
Apple's model, you just mark the pointer as __weak, and this is all done for 
you.  With the GNUstep model, weak pointers require you to build some other 
lifecycle detection on top.

David

-- Sent from my IBM 1620


reply via email to

[Prev in Thread] Current Thread [Next in Thread]