[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