• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Unexpected behaviour with autorelease pool
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unexpected behaviour with autorelease pool


  • Subject: Re: Unexpected behaviour with autorelease pool
  • From: Filip van der Meeren <email@hidden>
  • Date: Sun, 14 Dec 2008 23:01:16 +0100

If you allocate the object yourself, like the following:


NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init]; NSNumber *n = nil; NSInteger whaaaa = 0;

srand(time(NULL));
for(int i = 0; i < 100 * 1000; ++i)
{
	n = [[NSNumber alloc] initWithInt:rand()];
	if([n retainCount])
		++whaaaa;
	[n release];
}

NSLog(@"Result: %d", whaaaa);

[pool release];

then you should be able to release it. OS X can't cache random numbers...
I dumped the code above in a forloop, running 100,000 times... with random numbers to be inserted.
Memory-requirements started to go up, up and up...
And guess what the value of "whaaaa" was ? That is right: 100,000!


Filip van der Meeren
email@hidden
http://www.sourceforge.net/projects/perlmanager
http://www.sourceforge.net/projects/xlinterpreter

On 14 Dec 2008, at 22:47, Ken Thomases wrote:

On Dec 14, 2008, at 3:36 PM, Filip van der Meeren wrote:

I think I have found the answer to your question; when executing the following code, I get a few strange results...

NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

NSNumber *n0 = [NSNumber numberWithInt:1];
NSLog(@"n0: %d", [n0 retainCount]);
[n0 release];

NSLog(@"n0: %d", [n0 retainCount]);
[n0 release];

NSNumber *n1 = [NSNumber alloc];
NSLog(@"n1: %d", [n1 retainCount]);
n1 = [n1 initWithInt:1];
NSLog(@"n1: %d", [n1 retainCount]);
[n1 release];

[pool release];

The code above results in the following log:
2008-12-14 22:32:54.997 SmallTest[556:10b] n0: 2 <=============== Thats strange....
2008-12-14 22:32:55.003 SmallTest[556:10b] n0: 1


2008-12-14 22:32:55.004 SmallTest[556:10b] n1: -1 <=============== That is normal
2008-12-14 22:32:55.005 SmallTest[556:10b] n1: 2 <=============== Whooooow, overretained an object ;-)


My guess is that NSNumber is over-retaining itself within its initializer. Nothing for you to worry about.
This is a typical worry-case for that nice Apple programmer... You should file a bug-report...

This is why examining retain counts will only confuse you.

It is perfectly reasonable for NSNumber to vend cached, shared copies of commonly used values. For example, 0 or 1.

Stop trying to figure out what the retain count "should be" at any given point, nor having expectations about when exactly an object will be fully released and hence deallocated.

Just pay attention to your own responsibilities.

Regards,
Ken


_______________________________________________

Cocoa-dev mailing list (email@hidden)

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:
This email sent to email@hidden


  • Follow-Ups:
    • Re: Unexpected behaviour with autorelease pool
      • From: Ken Thomases <email@hidden>
References: 
 >Unexpected behaviour with autorelease pool (From: "Krishna Kotecha" <email@hidden>)
 >Re: Unexpected behaviour with autorelease pool (From: Filip van der Meeren <email@hidden>)
 >Re: Unexpected behaviour with autorelease pool (From: Ken Thomases <email@hidden>)

  • Prev by Date: Re: Unexpected behaviour with autorelease pool
  • Next by Date: Re: Unexpected behaviour with autorelease pool
  • Previous by thread: Re: Unexpected behaviour with autorelease pool
  • Next by thread: Re: Unexpected behaviour with autorelease pool
  • Index(es):
    • Date
    • Thread