Re: Classes incompatible with weak references
Re: Classes incompatible with weak references
- Subject: Re: Classes incompatible with weak references
- From: Ken Ferry <email@hidden>
- Date: Mon, 13 Aug 2012 16:43:46 -0700
On Aug 13, 2012, at 9:29 AM, Jean-Daniel Dupas <email@hidden> wrote:
>
> Le 13 août 2012 à 17:56, Kyle Sluder <email@hidden> a écrit :
>
>> On Aug 13, 2012, at 8:42 AM, Ben <email@hidden> wrote:
>>
>>> I see in the documentation - and from a compiler error - that some classes are not compatible with weak references.
>>>
>>> What makes these classes incompatible?
>>
>> They have custom implementations of -retain and -release.
>>
>> When NextSTEP was first released, there was no refcounting, just +new and +free. That's why NSObject (actually Object at the time) has only one ivar: isa, a pointer to the object's class.
>>
>> Some time later -retain and -release came into being, but the storage for refcount couldn't be added to Object because of the fragile base class problem—all existing code expected sizeof(Object)==sizeof(id), so they hardcoded offsets for accessing subclass ivars.
>
> I don't get it. retain/release has been introduced by NSObject.
> As all classed that use ref counting are based on NSObject and not Object, it was perfectly possible to declare 2 ivars in NSObject without breaking anything when it was first introduced.
It was a memory optimization. All live objects have an implicit +1 ref count by virtue of being alive. Anything with refcount > 1 has to have an entry in the external table, but anything with a single owner has _no_ memory dedicated to refcount.
At least at the time, most objects had single owners, so this was a win. It still was in Mail when last I saw the measurement.
>
>> This means these new, super-common operations had to access memory stored somewhere else than the object they were operating on. And to be thread-safe, these accesses had to be protected by synchronization primitives.
>>
>> Blowing out your processor's cache every time you issue a -retain sucks, as does taking a spinlock on an object that should only ever be accessed from the main thread. So some classes that had some spare bits overrode -retain and -release to store the retain count in the object's instance data and possibly not protect it with synchronization.
>>
>> For example, either NSView or NSControl has such a retain count in one of its bitfields. We also have a common base class, OFObject, that has an inline retain count that is manipulated with atomic lockless increments/decremnts. But with the advent of ARC, and the concurrent improvement of the data structure that stores object retain counts, we're going to eventually eliminate OFObject.
>>
>> Hopefully once Apple removes support for 32-bit OS X they will be able to move the retain count storage into NSObject.
>>
>> --Kyle Sluder
>> _______________________________________________
>>
>> Cocoa-dev mailing list (email@hidden)
>>
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
> -- Jean-Daniel
>
>
>
>
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden