On 13 Aug 2012, at 19:30, Jean-Daniel Dupas <devli...@shadowlab.org> wrote:
> > Le 13 août 2012 à 19:54, John McCall <rjmcc...@apple.com> a écrit : > >> On Aug 13, 2012, at 9:29 AM, Jean-Daniel Dupas 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. >> >> In the so-called "fragile" ABI, which is what you get on PPC, PPC64, and >> i386, class layout is performed at compile time, and the machine code >> pattern for accessing an ivar is the same as accessing a struct member: the >> compiler knows that 'int count;' is at offset 32 (say), so it just adds 32 >> to the base pointer value to find the address of the ivar. This is why all >> ivars have to be declared in the main @interface when compiling for these >> platforms: it would otherwise be impossible to do class layout for >> subclasses. Adding an ivar to a class would change that layout, causing all >> code with class layouts or ivar accesses compiled against the existing >> layout to stop working. >> >> There were releases made with NSObject having no ivars (except 'isa'). >> Therefore adding new ivars would have broken binary compatibility with those >> releases. > > Thanks for the details. I know what the fragile ABI, and the modern ABI are > but where I don't agree is when Kyle says that it was not possible to add a > refcount ivar when retain/release was introduced. As retain/release was > already defined in the first OpenStep specification > (http://www.gnustep.org/resources/OpenStepSpec/FoundationKit/Protocols/NSObject.html), > it was perfectly possible at that time to choose to add a refcount ivar to > the new NSObject class without breaking anything. > > I don't know the rational behind this choice, but it was probably to not > force all classes to have an eventually useless ivar (constant NSString for > instance don't need it). Exactly. There's also the simple saving in memory usage: As I understand it, objects with a retain count of 1 don't appear in the global retain count table; instead the system can deduce that since the object exists and isn't in the table, it must have a count of 1. This is quite handy for any objects which you create, do something temporary with, and then release. An idea I've vaguely wondered about would be turning the isa variable into a tagged pointer. If you know nothing is accessing it directly (to do so was deprecated with the modern runtime), then, say, the last 4 bits of the pointer could be used to record the retain count. Once they're used up (for those rare, highly retained objects), you spill over to runtime's existing system. Any calls to the runtime to determine an object's class would of course be aware of this and ignore those bits. _______________________________________________ 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
