FROM : Timothy Ritchey
DATE : Sat Nov 23 02:16:40 2002
Thanks Nat! I'll file a bug report.
As a follow up, I was wondering if anyone has any pointers to
documentation on the OS X VM implementation, specifically relating to
what it does better that negates the benefits of using zones. I have
read statements to this effect several times, but no information as to
why this is in fact the case. I am not clear whether it is related to
optimizations in the VM, or just faster hardware/large caches that
pushes the benefits of zones further out.
Cheers,
tim
On Friday, November 22, 2002, at 05:16 PM, Nat! wrote:
> Am Donnerstag, 21.11.02 um 20:54 Uhr schrieb Timothy Ritchey:
>
>> I've been investigating the whole allocWithZone: issue now that
>> NSCreateZone is working on Jag, and have run across an interesting
>> issue. It seems as if the allocWithZone: method works for basic
>> classes, but not with class clusters, such as NSArray, NSString, etc.
>> I haven't fully explored this yet, but just tried it with a few
>> classes. Things like:
>>
>>
>> NSZone *z = NSCreateZone( ... );
>> NSString *s = [[NSString allocWithZone:z] initWithString:...];
>>
>> if(NSZoneFromPointer(s) == z)
>> NSLog(@"good");
>> else if(NSZoneFromPointer(s) == NSDefaultMallocZone)
>> NSLog(@"bad");
>>
>> Always return "bad" for NSArrays or NSStrings (mutable or not), but
>> work for things like NSData and NSHost. Is this by design, or are the
>> class cluster implementations not obeying the zone designation, or is
>> it not a class cluster issue at all?
>>
>
> The problem is that [NSString allocWithZone: doesn't really allocate
> an object but returns a placeholder object. The real string object is
> allocated with init. (*1*)
> AFAI can remember that used to be (Mac OS X Server 1.2) properly
> zoned, i.e. you got a different placeholder object for each zone. If
> that isn't the case anymore write a bug about it. Fixing it will of
> course waste performance...
>
> In any case I think zoning is way overrated (*2*). Might be
> interesting for debugging but don't expect much in the way of
> performance. I would not waste too much effort on keeping things
> properly zoned.
>
> Just my opinion though.
>
> Ciao
> Nat!
> (*1*) If there was just newWithString: instead of alloc/init these
> problems would not be and placeholder objects wouldn't exist.
> (*2*) To put some obscurity here, if API users where required to use
> the return value of retain only and not the pre-retained object, I
> could see some good use :)
>
> Jedenfalls sind zehn Fehlstarts hintereinander [E. Fuchs]
> ein sehr interessanter Beweis
> fuer unsere Theorie
> von der natuerlichen Ueberlegenheit des Dezimalsystems
> _______________________________________________
> cocoa-dev mailing list | <email_removed>
> Help/Unsubscribe/Archives:
> http://www.lists.apple.com/mailman/listinfo/cocoa-dev
> Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | <email_removed>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
DATE : Sat Nov 23 02:16:40 2002
Thanks Nat! I'll file a bug report.
As a follow up, I was wondering if anyone has any pointers to
documentation on the OS X VM implementation, specifically relating to
what it does better that negates the benefits of using zones. I have
read statements to this effect several times, but no information as to
why this is in fact the case. I am not clear whether it is related to
optimizations in the VM, or just faster hardware/large caches that
pushes the benefits of zones further out.
Cheers,
tim
On Friday, November 22, 2002, at 05:16 PM, Nat! wrote:
> Am Donnerstag, 21.11.02 um 20:54 Uhr schrieb Timothy Ritchey:
>
>> I've been investigating the whole allocWithZone: issue now that
>> NSCreateZone is working on Jag, and have run across an interesting
>> issue. It seems as if the allocWithZone: method works for basic
>> classes, but not with class clusters, such as NSArray, NSString, etc.
>> I haven't fully explored this yet, but just tried it with a few
>> classes. Things like:
>>
>>
>> NSZone *z = NSCreateZone( ... );
>> NSString *s = [[NSString allocWithZone:z] initWithString:...];
>>
>> if(NSZoneFromPointer(s) == z)
>> NSLog(@"good");
>> else if(NSZoneFromPointer(s) == NSDefaultMallocZone)
>> NSLog(@"bad");
>>
>> Always return "bad" for NSArrays or NSStrings (mutable or not), but
>> work for things like NSData and NSHost. Is this by design, or are the
>> class cluster implementations not obeying the zone designation, or is
>> it not a class cluster issue at all?
>>
>
> The problem is that [NSString allocWithZone: doesn't really allocate
> an object but returns a placeholder object. The real string object is
> allocated with init. (*1*)
> AFAI can remember that used to be (Mac OS X Server 1.2) properly
> zoned, i.e. you got a different placeholder object for each zone. If
> that isn't the case anymore write a bug about it. Fixing it will of
> course waste performance...
>
> In any case I think zoning is way overrated (*2*). Might be
> interesting for debugging but don't expect much in the way of
> performance. I would not waste too much effort on keeping things
> properly zoned.
>
> Just my opinion though.
>
> Ciao
> Nat!
> (*1*) If there was just newWithString: instead of alloc/init these
> problems would not be and placeholder objects wouldn't exist.
> (*2*) To put some obscurity here, if API users where required to use
> the return value of retain only and not the pre-retained object, I
> could see some good use :)
>
> Jedenfalls sind zehn Fehlstarts hintereinander [E. Fuchs]
> ein sehr interessanter Beweis
> fuer unsere Theorie
> von der natuerlichen Ueberlegenheit des Dezimalsystems
> _______________________________________________
> cocoa-dev mailing list | <email_removed>
> Help/Unsubscribe/Archives:
> http://www.lists.apple.com/mailman/listinfo/cocoa-dev
> Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | <email_removed>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
| Related mails | Author | Date |
|---|---|---|
| Timothy Ritchey | Nov 21, 20:54 | |
| Nat! | Nov 22, 23:16 | |
| Timothy Ritchey | Nov 23, 02:16 |






Cocoa mail archive

