Hacker News new | past | comments | ask | show | jobs | submit login

Could it be because of the garbage collecting? I'm not sure whether it's that related



Garbage collection likely has something to do with NSZone's (perceived on my part) deprecation. My understanding (although I can't find it documented) is that NSZone doesn't have any effect on allocations handled by the GC. This is also the default (found-documented) behavior for CFAllocator (although this can be changed, which might be why CFAllocator is better documented).

Also, NSZone is an opaque C structure -- you don't get to see its fields without getting your hands (slightly) dirty. It's defined as:

  typedef struct _NSZone NSZone;
Random thought: If you have a lot of objects that can take advantage of toll-free bridging, I wonder how well it would work to use your own CFAllocator that doesn't use the GC in a GC'd environment.


I'm pretty sure NSZone was unofficially deprecated well before Objective-C added garbage collection.

Essentially, they were a good idea in theory, but not in practice. For one thing the Cocoa frameworks wouldn't play along with your carefully considered zone strategy. Then you get objects in zones with pointers to non-zoned objects and vice versa.


I think we might be thinking about the same time period, 4 or 5 years ago.

CoreFoundation had something vaguely resembling garbage collection introduced in 10.4, with CFMakeCollectable[1]. I've always thought of that time period as being when NSZone was more or less deprecated. There were a lot of other big (and small) design changes that were in that era as well; bindings were introduced, calendars changed, etc.

1. http://developer.apple.com/mac/library/documentation/CoreFou...


That wasn't "something vaguely resembling garbage collection" — it was a no-op until garbage collection was finally introduced half a decade later.

And NSZone was already out of favor when I started programming Cocoa, on OS X 10.1. It just didn't have any advantages under OS X's memory model. It certainly wasn't a preallocated object pool like this. As it was explained to me at the time, the main point of NSZone originally was that it let you to blow away the whole zone at once without needing to release every single object. This was no longer the case in 10.1 (and I don't think it was even the case in 10.0).


NSZone was born when memory was small and paging to disk was expensive & frequent. Zones were to help you group objects that would likely be used together onto the same virtual memory page so you could decrease the likelihood of thrashing.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: