Re: NSZone pointers

[Richard Frith-Macdonald]

On 21 Jul 2011, at 14:27, David Chisnall wrote:

> On 21 Jul 2011, at 14:16, Ivan Vučica wrote:
> 
>> I didn't even bother looking up what zones are for until now.
> 
> They're not used very much anymore, because half of Cocoa is not zone-aware.  
> On OS X, zones are opaque, so they're not even very useful, they just act as 
> hints for the allocation policy.  
> 
>> Judging by information on CocoaDev, it looks to me like zones might 
>> primarily be interesting to games, screensavers and other 
>> continuously-rendered and high-performance applications.
> 
> Not really.  They were mainly used on OPENSTEP for optimisation where lots of 
> short-lived objects that would never be aliased were created and destroyed at 
> once.  Generally though, if that's the problem then the right solution is to 
> use C structure rather than objects.  Given the throughput of a modern 
> malloc() implementation, it's largely irrelevant.
> 
> I've done some things with zones in the past, for example defining a 
> persistent zone backed by an mmap()'d segment, so that objects could persist 
> between program invocations (needed some hacks to update their isa pointers 
> on each restart though, so it wasn't very useful), but I've not seen any 
> post-NeXT code that used them for anything.
> 
>> It would be interesting to have this as a ./configure-able setting when 
>> building the runtime, with the default being current behavior. Reducing RAM 
>> usage is not very important these days.
> 
> I disagree.  Reducing RAM is still important, and in this case it's a trade: 
> either reduce RAM or reduce CPU cycles.  I think we're optimising for the 
> very unlikely case and burning RAM.  
> 
> More importantly, we're burning cache.  Objects are allocated starting at the 
> zone pointer, which means that we're wasting one word of a cache line in 
> every object for a value that almost never needs to be accessed - every time 
> you touch an object, you'll be pulling it into cache.  Reducing cache churn 
> is likely to make more of a performance difference than anything else in this 
> diff - on a modern system, efficient cache usage is one of the biggest 
> factors in performance.

David, I've never liked zones, but we probably need to keep them around for 
people who *do* want them.  I implemented per-object zone pointers simply 
because I couldn't figure out a way to get reasonable performance if people 
used a lot of zones and we had to look outside the object to determine the 
zone, but that was back when machines were slower (and when I thought people 
actually used zones a lot), and the world has changed in the last decade or so 
:-)

Even now, if we continue to support zones without zone pointers in objects, we 
will slow down a bit because we have to do some sort of check to see whether an 
object is in a zone or not, but I suspect that
a. practically nobody uses zones
b. the slowdown is relatively unimportant on modern hardware

Why don't we make them a configurable default, but with the default setting 
being to NOT have them?

If we build with zones turned off (the default), we could just optimise the 
NSZone... functions to be direct calls to the malloc family of functions, and 
code would be a tiny bit faster than at present.

If we build with zones on, we could maintain a map from objects to zones and 
the -zone method could consult the map to see if an object is in a non-standard 
zone (or we could ask each zone if the object is in it), rather than keeping a 
pointer before the object.  These lookups would make everything slower, but 
we'd then have a consistent memory layout for an object irrespective of the 
configuration option.