[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSZone pointers

From: David Chisnall
Subject: Re: NSZone pointers
Date: Thu, 21 Jul 2011 14:27:16 +0100

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 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]