Re: Garbage Collection

[Richard Frith-Macdonald]

On 25 May 2011, at 16:04, David Chisnall wrote:

> 
> 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.

Yes, I have.

> 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.

The zeroing weak reference code works.  It creates typed memory containing weak 
pointers which are zeroed by the garbage collector when the object they point 
to is finalised.
There are testcases in the testsuite which specifically demonstrate this.  In 
fact, if this feature did not work then the testsuite would fail miserably in 
lots of places when run in GC mode.


>> 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 is not the case, the GNUstep implementation uses zeroing weak pointers.

>  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.  

My understanding was the the boehm garbage collector handles collection in a 
separate thread which forces a barrier so that other threads always access the 
memory in a consistent state.
However, if that's not the case then I guess it might be that zeroing weak 
pointers with boehm are not thread-safe (though I've not seen a problem).

> 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.

I guess you must not have bothered looking at the GNUstep code, or you'd have 
realised that it does no such thing.

Still, that's not to say that there's no point implementing 100% Apple 
compatibility ... improvements in compatibility are great even if they don't 
make much difference to actual usability.