On Aug 13, 2012, at 9:29 AM, Jean-Daniel Dupas <devli...@shadowlab.org> wrote:
> > Le 13 août 2012 à 17:56, Kyle Sluder <k...@ksluder.com> a écrit : > >> On Aug 13, 2012, at 8:42 AM, Ben <ben_cocoa_dev_l...@yahoo.co.uk> 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 (Cocoa-dev@lists.apple.com) >> >> 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: >> https://lists.apple.com/mailman/options/cocoa-dev/devlists%40shadowlab.org >> >> This email sent to devli...@shadowlab.org > > -- Jean-Daniel > > > > > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > 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: > https://lists.apple.com/mailman/options/cocoa-dev/kenferry%40gmail.com > > This email sent to kenfe...@gmail.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
