Re: upper limit on retain count
Re: upper limit on retain count
- Subject: Re: upper limit on retain count
- From: Shaun Wexler <email@hidden>
- Date: Tue, 19 Apr 2005 12:05:59 -0700
On Apr 19, 2005, at 8:45 AM, John Stiles wrote:
You know, the computer only has 4 billion bytes of memory, and even
the most trivial of objects is 8 bytes (it needs an isa and a
refcount).
Actually, the smallest objects are just 4 bytes {isa}, with an implied
1 reference. Foundation adds the object's id to an "extra ref count"
maptable to add any additional ref's, which is why retain/release is so
expensive, thus inline refcounts are preferred for performance reasons.
Apple's malloc implementation is guaranteed to return buffers as
multiples of 16-bytes, vec-aligned, so all objects are at least 16
bytes, thus you always have 3 extra int's or floats to play with.
FWIW, my base framework creates all cache-aligned/sized objects with a
noticeable performance increase, as well as atomicity benefits that
facilitates known ivar alignments and access grouping.
FWIW, to answer the original question:
- refcounts are 32-bit ints
- I am not 100% sure, but I believe they cap at 4 billion (as opposed
to overflowing)
Most CF container classes use a long long (64 bit) inline ref count,
and many AppKit classes use a shorter-than-32-bit inline ref count,
with a designated bit for "refCountOverMax" that (assuming) either
leaks the object or defers to the default/super refcount for the
overage.
--
Shaun Wexler
MacFOH
http://www.macfoh.com
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden