Collection Object

[Ruslan Zasukhin]

On 8/3/06 2:02 PM, "Shaun Wexler" <dev at macfoh.com> wrote:

>> The approach I would like to take for the forthcoming Valentina 3
>> versions is to toll-free bridge the C++ FBL classes with CF/NS.  I
>> know can do it!  I have the power...  ;)
> 
> The major differences between CF/NS and FBL I_Unknown is in the
> reference counting... and in Tiger/Leopard: auto-garbage-collection.
> 
> By default there is no inline refcount contained in the base NSObject
> itself; it carries an implied 1 refcount, and all additional
> references are stored in one large maptable keyed by the object's id
> pointer, and the dict is protected by one common spinlock (ack!!
> 0-1000 iterations before blocking!).  This is one reason that retain/
> release is so expensive in NS, and why all CF and many other NS "hot"
> objects are designed with an inline refcount ivar, just like all FBL
> classes (and SKW classes!).
> 
> Each API has its own way of implementing the refcounting functions or
> methods, but they all work the same.  CFRuntimeBase declares an
> object struct which is compatible with NSObject, allowing toll-free
> bridging, because ObjC is so immensely flexible, CF actually creates
> subclasses of the NS class and then poses as the NS class, replacing
> certain method IMP's with its own.
> 
> CF objects encode some useful information; isa is the actual NS class
> which has been "patched", and then it stores 32 bits of additional
> allocation data as follows: 7 bits of inline refcount plus 1 bit to
> indicate overflows which are stored in an external dict, similar to
> NS except that it is 32768 times faster.  It also stores 8 bits for
> the CFTypeID which is an index into the CF class table (yes, max of
> 255 runtime CF classes).  One bit is used to flag the default system
> allocator, and I think the other 7 bits are unused.  The fields are
> designed so the full 32 bit value can be loaded at once and masked,
> regardless of endianness of the arch.
> 
> When an object refcount needs accessed, first a type determination is
> conducted, and the real methods are dispatched for bridged classes if
> necessary, and this is duplicated again for the CF layer... yes,
> twice redundant.
> 
> Thus, each CF object requires 8 bytes, and each NS object which is
> NOT toll-free bridged only requires 4 bytes **.  Plus ivars for
> subclasses, etc.  ** Moot point, since minimum malloc granularity is
> 16 bytes and is always 16-byte aligned (SKWObject requires native
> cacheline size/alignment).
> 
> So if we design I_Unknown to use this 64-bit "bridge" header, and all
> bridged classes follow the same conventions, we can build another
> bridge and then VKernel, etc, can use the classes transparently and
> we can also pass them directly to NS and CF.

2 things of concern

1) 255 CF classes in Application ????
    Valentina engine have now much more I think.

2) it sounds not good idea try fit to Apple's structures.
    they can change it next year...


-- 
Best regards,

Ruslan Zasukhin
VP Engineering and New Technology
Paradigma Software, Inc

Valentina - Joining Worlds of Information
http://www.paradigmasoft.com

[I feel the need: the need for speed]