Help me understand Memory Management

cocos2d for iPhone » Programming » cocos2d support (graphics engine)

Help me understand Memory Management

(17 posts) (5 voices)

Started 2 years ago by gaminghorror
Latest reply from gaminghorror

Tags:

gaminghorror
Member

In menu screens i typically see this in Ricardo's code (init Method):

Menu *menu = [Menu menuWithItems:item1, item2, item3, item4, nil];
[self addChild: menu z:0];

menu is never again referenced in the code. So when exactly is the memory used by memory freed? Doesn't this leak memory or cause the memory only to be freed when quitting the application?

Second question. We started following the "always alloc" rule. In our code we do this in the init Method (menu is now a member variable):

menu = [[Menu alloc] initWithItems:(MenuItem*)buttonBackground vaList:(va_list)dummyList];
[self addChild: menu z:0];

and in the dealloc method we do this:

[[menu parent] removeChild:menu cleanup:YES];
[menu release];

Actually that was my colleague adding the first line. He insists that otherwise any alloc'ed object added to the cocosnode won't be cleaned up propery. Personally i doubt this. Can someone clarify this for us please: is the first line really necessary, and is it really necessary to alloc menu screen objects where we don't care so much about performance?

Posted 2 years ago #
Lam
Member

I'm assuming you've read apples mem mgmnt document so I'll explain in brief.

Any alloc/copy/retain that you do must have some release to free the memory. If you want that allocated heap to stay resident until the class is released then you would usually call release and that variable in dealloc so you are doing it right.

That funky [[menu parent] removeChild...] isn't needed since cocos will remove all the children on dealloc and menu is added as a child.

There's no harm but it's extra coding and will confuse you more about mem management later on.

Pretty much remember that you are responsible for releasing any alloc/copy/retain that you call. Otherwise trust that cocos deals with memeory it correctly.

Posted 2 years ago #
Matt Rix
Member

Someone else probably has more experience with this than me, but here's how I understand it:

menu is retained because it's a child of self(which is probably the scene where you're creating the menu). When self is dealloced, it'll remove+release all it's children, at which point the retain count of menu will be 0, and it'll dealloc.

Keep in mind that any array(including the children array in cocos) will retain a member when it's added, and release it when it's removed...

...so in your dealloc method, the first line isn't really possible, because in order for dealloc to be called, menu's parent can't still have it as a child(or else it would still have a retain count of 1).

Posted 2 years ago #
Matt Rix
Member

Oh, and to test out any memory management stuff, put an NSLog in your dealloc method. It's a great way to see exactly when/if things are being removed.

Posted 2 years ago #
gaminghorror
Member

That is what i wanted to hear. Trust Cocos memory management. Thank you. :)

I do know about the alloc/release cycle. Just one more question to clear this up: if i were to write:

Menu *menu = [Menu menuWithItems:item1, item2, item3, item4, nil];

but never add it as children to self eg omit this line: [self addChild: menu z:0];

When would menu get released? As soon as the init method is exited, or maybe even never?

Posted 2 years ago #
gaminghorror
Member

"Oh, and to test out any memory management stuff, put an NSLog in your dealloc method. It's a great way to see exactly when/if things are being removed."

Already have but hard to see through the noise. ;)

Posted 2 years ago #
Lam
Member

@gaminghorror

Menu *menu = [Menu menuWithItems:item1, item2, item3, item4, nil];

Yeah. That will get released for you.

Posted 2 years ago #
Matt Rix
Member

"When would menu get released? As soon as the init method is exited, or maybe even never?"

It'll be autoreleased, so you can kinda think of it as after the init method is exited.

Posted 2 years ago #
gaminghorror
Member

Isn't autorelease something that should be avoided on the iPhone because there's no garbage collection?

Posted 2 years ago #
Lam
Member

There's no garbage collection yes but that is good.
"Garbage collection" is a technique of automatic memory management which has their underlying problems and are improbable to do effectively on embedded devices.

Because objective c is a dynamic language that still has ties to c. A conservative garbage collector could only be used. Slowly releasing memory on a device in which apps depend on the little memory they can get is damaging.

So yeah there's no garbage collection but effective use of the NSAutoreleasePool will free up memory that are autoreleased so it should be fine.

So if lets say you run a large loop that uses a lot of autorelease'd objects. Then maybe you should wrap that in a NSAutoreleasePool. Otherwise cocos takes care of that for you.

Memory will always be freed at some point.

Posted 2 years ago #
gaminghorror
Member

Yes, i already used Autorelease pools in some parts of my code, eg. save & load routines. Simply because it was mentioned to be good practice without fully understanding it.

I do know how GC works in principle, i have a background in C# and Lua programming but Mac and iPhone is still pretty new to me. I still don't understand in what way NSAutorelease pools behaves differently than having a true garbage collector? Isn't that effectively the same thing?

Posted 2 years ago #
Lam
Member

They are the same thing only in the technique of memory management.

But they are two different techniques. One being manual and the other automatic.

NSAutorelease pools are still part of manual memory management since you have to take steps to ensure that proper autoreleased objects will be released. So not quite. If you did not have an NSAutoreleasePool then that autoreleased object must be kept until another autorelease pool is released. Whereas GC makes freeing memory transparent to the user.

Posted 2 years ago #
Matt Rix
Member

Garbage Collection and Autorelease pools are VERY different. All objects that have been sent an "autorelease" message (ie. [myobject autorelease]) will be sent a "release" message when the Autorelease pool is told to flush(which is usually after every program loop). That's all there is to it.

Any time you have a function that *creates* AND *returns* an object, it should autorelease that object. You don't want that function to retain a reference to the object, so you've gotta release it, but you also don't want it to dealloc the object before returning it(or else it'd be useless), so you autorelease it.

Just think of autorelease as a delayed release.

Posted 2 years ago #
gaminghorror
Member

I think i need to read up on Apples memory management docs again. As far as i understand it, autorelease pool simply is the one-stop point of freeing memory that is no longer used since the last step, whereas GC only cycles through objects and frees unused memory as soon as a memory threshold is hit.

So autorelease behaves like forcing garbage collection every cycle, something that was recommended for Lua programs when it still only had a linear garbage collector.

Am i right to assume that in Cocos' internal step method, it actually makes a call to flush the autorelease pool every frame?

Posted 2 years ago #
Codemattic
Moderator

Cocos/Cocoa doesnt have real automatic GC, it has reference counting. Just remember, if you get an object that is autoreleased you can use it safely in your current codeblock as a temporary variable, if you want to keep it in a member variable longer than that you have to retain it and then release it when you are done.

Dont worry about AutoreleasePools for now - just let Cocoa do its thing - you only need that if you are running loops where you are generating many temporary variables. Dont over optimize, dont worry about it, if you find you are having memory problems then you can start going back and finding where to optimize.

Posted 2 years ago #
exorcyze
Member
Just to add / support some of the other responses:

I will preface by saying I haven't dug into the internals of Cocos, so I'm not familiar with how things work under the hood. However, I would assume that the standard Cocoa practices were followed.

Given that assumption:
```
Menu *menu = [Menu menuWithItems:item1, item2, item3, item4, nil];
[self addChild: menu z:0];
```
In standard Cocoa, these types of convenience methods ( like menuWithItems ) are autoreleased. That means generally at the end of the current method, *menu will get a release. If you had not added it as a child, then all memory for that would be gone and you would be pristine clean. When you add it as a child it gets a retain, which means 2 retains ( one autoreleased from the convenience constructor and one from the addChild ). One of those would go away ( the autoreleased one ) at the end of the method. The other would get removed when the parent object is killed since children are removed automatically by Cocos2d from what I've read.

In that scenario you do not need to dealloc anything, and doing so should cause issues.

On to the second scenario:
```
menu = [[Menu alloc] initWithItems:(MenuItem*)buttonBackground vaList:(va_list)dummyList];
[self addChild: menu z:0];

// snip //

[[menu parent] removeChild:menu cleanup:YES];
[menu release];
```
As stated above, the removing of children should not be needed. The release of menu would be needed since you assumed responsibility for it by alloc'ing it. Though in all honesty I haven't run across any good reasons to avoid convenience constructors when they're available. They generally make code cleaner and smaller - which can make it easier to maintain, understand and extend. =)
Posted 2 years ago #
gaminghorror
Member

Thanks for that last post, that explains it really well! I've since re-read the Apple docs on NSAutorelease and also got a better understanding of it.

Posted 2 years ago #

RSS feed for this topic

Reply

You must log in to post.