iOS When does main function's autorelease pool get's popped up

amalshah71 · May 9, 2009

Been through a lot of googling...but couldn't find the exact answer....

I know the basic idea that....whatever you alloc/copy/retain you must release it....allright.....it all works fine if i go by this approach.....

But when i create objects with convenience methods...like....

NsNumber *number=[NsNumber numberwithint...];

the problem starts here....

Since (number) is not created by me...i am not the owner....so i don't release it...i believe when my work is done...it will get autoreleased.....

I do not create any autorelease objects(pools) myself....

so i believe this (number) will get added to main() function's AutoRelease pool.....

But when does main() funtion's autorelease pool get drained....

Did a bit of thing here and there...Debugged main() function....found out that control never goes past that [pool alloc] statement......

From articles found out that....on End of every event loop autorelease pool dealloc's objects....

I am really confused....

--> When does main function's autorelease pool really gets popped up?

--> what does end of event loop really mean?

Went through instruments...saw net allocation....due to these objects my memory really shoots up.....

amal

xsmasher · May 10, 2009

There is a pool that gets drained at the end of every "event" - so if you create an object in one button press, or touch, or timer selector, it will be gone by the next button / touch / timer selector.

BlackWolf · May 10, 2009

afaik, the main autorelease pool is emptied at the end of the run loop, so basically as soon as your app goes "idle" - which means none of your code is executed right now because, for example, the application waits for user input.

so for example you are currently running a method, from that method you call another method. when both methods are finished, your app isn't doing anything anymore - the pool is emptied.

what this means is: as long as you are doing SOMETHING you can use autoreleased objects. you can also return or pass them to other methods. but these objects are not persistent, as soon as you are not running any code anymore, they get released. if you need them for later, you have to retain them.

oh and btw: if you want a number that you OWN, so that you can use it, just don't use convenience constructors. for every CC there is also a "normal" constructor.
and another thing: if there is no reason to use a CC, don't. if you know when you don't need an object anymore, release it yourself.

amalshah71 · May 10, 2009

xsmasher said:
There is a pool that gets drained at the end of every "event" - so if you create an object in one button press, or touch, or timer selector, it will be gone by the next button / touch / timer selector.

BlackWolf said:
afaik, the main autorelease pool is emptied at the end of the run loop, so basically as soon as your app goes "idle" - which means none of your code is executed right now because, for example, the application waits for user input.

so for example you are currently running a method, from that method you call another method. when both methods are finished, your app isn't doing anything anymore - the pool is emptied.

what this means is: as long as you are doing SOMETHING you can use autoreleased objects. you can also return or pass them to other methods. but these objects are not persistent, as soon as you are not running any code anymore, they get released. if you need them for later, you have to retain them.

So, draining of objects only takes place by these button / touch / timer selector EVENTS.....

say for example at the start-up of my app i have some method...

Code:

-(void)doSomething()
{
     NsNumber *number=[NsNumber numberwithint...];

    // and a lot of objects like (number) created using convenience methods...
}

So, the objects created in above method will they get autoreleased at the end of doSomething() method or will get drained till an event happens which in turn makes way for popping up autorelease pool.....

BlackWolf said:
oh and btw: if you want a number that you OWN, so that you can use it, just don't use convenience constructors. for every CC there is also a "normal" constructor.
and another thing: if there is no reason to use a CC, don't. if you know when you don't need an object anymore, release it yourself.

I don't need those objects anymore....so i just create it with CC...and rely on autorelease pool to release it....assuming that at the end of my method.....those objects will get drained....since i am not using them any further.....

amal

BlackWolf · May 10, 2009

the number will get released at the end of doSomething() ... that's not 100% correct, but basically that'll do.

like I said, you can use CCs, but if you have a lot of objects you create you should release them manually if possible, for example if you have a loop that creates objects everytime.

I, personally, prefer to release everything manually when I do not need CCs for a specific reason (for example I return an object).

amalshah71 · May 10, 2009

BlackWolf said:
the number will get released at the end of doSomething() ... that's not 100% correct, but basically that'll do.

So you mean is it will get released....depending on when does autorelease pool pop's up....But when does it really pop up?

--> At the end of method

--> when an event finishes....

amal

kainjow · May 10, 2009

Overview of Autorelease Pools:

The Application Kit automatically creates a pool at the beginning of an event cycle (or event-loop iteration), such as a mouse down event, and releases it at the end.

The only time you'll really need to make your own autorelease pool is when you're in a tight loop where the system doesn't have a chance to drain the pool automatically.

PhoneyDeveloper · May 10, 2009

amal,

An instance of an NSAutoReleasePool is created and drained by UIKit for each user event or other kind of event when UIKit calls your code. So for each touch event or draw event there is a pool created and then drained.

I recommend that you look at this further by creating a NSObject subclass and overriding retain/release/autorelease and seeing what happens.

Code:

-(id)retain
{
    NSLog(@"retain");
    return [super retain]
}
- (oneway void)release
{
    NSLog(@"release");
    [super release]
}
-(id)autorelease
{
    NSLog(@"autorelease");
    return [super autorelease]
}

Add that code to your NSObject subclass and set breakpoints in the methods to see when they are called. You can print the retainCount too if you like.

Create instances of this class in various ways and places in a sample project.

I think you'll understand things better in that way.

amalshah71 · May 13, 2009

@ kainjow
thanks man....that linked helped.....

@ PhoneyDeveloper

followed what u said....now i am getting a bit of things clear...when an object is autoreleased....in what kind of events....

but i just would like to be certain....

what i found is...there's kind of local pool created on every event....by platform itself...i don't create it....so autorelase objects definitely go on this pool(and not on the main() function's pool)...so these are kind of pools that are created somewhere as opposed to the one literally created in main function(i.e. creation of such local pool's by platform is not visible..)

amal

PhoneyDeveloper · May 13, 2009

there's kind of local pool created on every event

Yes, exactly.

If you re-read the comments in this thread you'll see that that's what people have been saying. The pool in main isn't very important. It doesn't get released until the app quits, if then.

Search

Search

iOS When does main function's autorelease pool get's popped up

amalshah71

macrumors member

xsmasher

macrumors regular

BlackWolf

macrumors regular

amalshah71

macrumors member

BlackWolf

macrumors regular

amalshah71

macrumors member

kainjow

Moderator emeritus

PhoneyDeveloper

macrumors 68040

amalshah71

macrumors member

PhoneyDeveloper

macrumors 68040

Our Staff