Collection Object

[Shaun Wexler]

On Aug 3, 2006, at 2:46 AM, Shaun Wexler 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.

::)
-- 
Shaun Wexler
MacFOH
http://www.macfoh.com