Hi Ken and Greg
This is a bug in the associated reference machinery. That code keeps
a C++ std::hash_map per augmented object, mapping associated keys to
associated values. std::hash_map uses an std::vector internally, and
the default hash_map constructor pre-allocates 100 entries for that
vector. This is overkill for associated objects usage. The fix is to
use a non-default constructor that specifies a much smaller initial
hash_map size.
Unfortunately constructing the std::hash_map with a small capacity
will lower the number of preallocated bucket slots only to 53 (->
424 bytes under 64 bits), because this is the smallest number
returned by __stl_next_prime(). (I deduced this from the stl source
in the 10.6 sdk, so I may be mistaken.)
We discovered that today as well. Next option is to use a non-STL
hash implementation; I hear LLVM has a good one internally.
Thank you for the detailed explanation of the problem!
Note that the observation info is typed id despite being typed void
* in the headers. KVO needs strong storage here to implement the
feature described in "Automatic Removal of Finalized Key-Value
Observers" in the release notes. KVO assumes you are providing
strong storage if the method is typed id, which can be introspected
out of the runtime. If you aren't, it'll have to use an associated
reference to keep things alive.
That was the next question I was about to ask...
Torsten
_______________________________________________
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
