macOS releasing local variables

[shilpa]

Hi all,
in dealloc funcn do we need to release even local class variables other than releasing properties.

 

[tacoman667]

Hi all,
in dealloc funcn do we need to release even local class variables other than releasing properties.

Always release local objects. You are at the mercy of a garbage collector if you do not release your items and classically, a garbage collector waits for a "timeout" period for a memory allocation before collecting it whether it is in use or not and that period is VERY long. This can easily be considered a memory leak.

This is assuming you even have a garbage collector in your language/framework version. If not, the allocation never gets released until you reboot.

 

[yoavcs]

I'm assuming you are referring to instance variable scalars such as ints and floats.

In that case, no, you don't release them as they get released when the backing struct behind every object gets obliterated.

You do have to release any memory you have a pointer to, be it an object or some malloc()'ed chunk, as only the pointer will get removed implicitly, not th pointee.

 

[yoavcs]

Always release local objects. You are at the mercy of a garbage collector if you do not release your items and classically, a garbage collector waits for a "timeout" period for a memory allocation before collecting it whether it is in use or not and that period is VERY long. This can easily be considered a memory leak.

This is assuming you even have a garbage collector in your language/framework version. If not, the allocation never gets released until you reboot.

Modern garbage collectors are much more intelligent than your description and there is typically no long delay before collection on a dead chunk of memory.

In any case, if your app leaks the memory is returned as soon as you close the app. A reboot is way overkill.

 

[tacoman667]

Modern garbage collectors are much more intelligent than your description and there is typically no long delay before collection on a dead chunk of memory.

In any case, if your app leaks the memory is returned as soon as you close the app. A reboot is way overkill.

If you forget to release an object and close the app with that object having a retention count of 1, then the garbage collector would wait for a while to see if that allocation has been referenced before killing it. setting the retain count to 0 would give that slight bit of time but the collector understands that a count of 0 means nothing is using it. Then it's an "oops" moment on your part for releasing it early.

 

[yoavcs]

If you close an app all memory it had is immediately taken up by the OS. There is no delay, and there is no garbage collector "waiting just a bit longer" to reclaim the memory.

 

[tacoman667]

If you close an app all memory it had is immediately taken up by the OS. There is no delay, and there is no garbage collector "waiting just a bit longer" to reclaim the memory.

Is this Mac OS or Windows as well? I must be out of the loop then. I am primarily a Windows developer.

 

[MonkeyCookie]

As I recall from reading the Apple developer documentation, if garbage collection is enabled, the release method doesn't do anything, so calling it will not change anything. Code that was written to do manual memory management will still run just fine when the garbage collection is turned on, but the Cocoa framework will simply ignore release calls and do its own garbage-collection thing.

If garbage collection is turned off, then release will work as expected.

I've been working for years developing applications with languages with garbage collection (Java, C#, Objective-C), and I've never seen a case where the garbage collection mechanism was too slow or left too much memory uncollected. No doubt an application that allocates and releases a gig of memory hundreds of times a second would have a problem with garbage collection not collecting before it runs out of memory, but 99.999% of applications don't do anything like that.

Worry about garbage collection if it becomes a problem; otherwise, just trust that it will do its job.

 

[yoavcs]

Is this Mac OS or Windows as well? I must be out of the loop then. I am primarily a Windows developer.

This is every single OS in existence. A closed app relinquishes its resources back to the OS. Now. Not later. It isn't a matter of the app wanting to, it is OS enforced.

 

[tacoman667]

As I recall from reading the Apple developer documentation, if garbage collection is enabled, the release method doesn't do anything, so calling it will not change anything. Code that was written to do manual memory management will still run just fine when the garbage collection is turned on, but the Cocoa framework will simply ignore release calls and do its own garbage-collection thing.

If garbage collection is turned off, then release will work as expected.

I've been working for years developing applications with languages with garbage collection (Java, C#, Objective-C), and I've never seen a case where the garbage collection mechanism was too slow or left too much memory uncollected. No doubt an application that allocates and releases a gig of memory hundreds of times a second would have a problem with garbage collection not collecting before it runs out of memory, but 99.999% of applications don't do anything like that.

Worry about garbage collection if it becomes a problem; otherwise, just trust that it will do its job.

I thought I read in the new Hillegrass book that you had to instaniate the object in a manner to use the garbage collector. In that case you are right as it doesn't care about the "release" statement. Don't you have to

[[[obj alloc] init] autorelease]

?

 

[MonkeyCookie]

I thought I read in the new Hillegrass book that you had to instaniate the object in a manner to use the garbage collector. In that case you are right as it doesn't care about the "release" statement. Don't you have to

[[[obj alloc] init] autorelease]

?

Nope, autorelease is only useful in manual memory management. The autorelease mechanism is a little bit like garbage collection when using manual memory management, but the autoreleased objects are released when the autorelease pool is cleaned up in code instead of happening automatically in the background.

Apple has an good article on the subject at http://developer.apple.com/documentation/Cocoa/Conceptual/GarbageCollection/Introduction.html

This is the part of the document that I was thinking of earlier.

Reference counting

If you use garbage collection, the methods that are used to implement the manual reference counting system (retain, release, dealloc, autorelease, and retainCount) have no effect—the Objective-C messenger short circuits their dispatch. As a result, overriding release and dealloc is not supported when garbage collection is enabled—this makes obsolete some object caching patterns.

Note, however, that CFRetain and CFRelease do still have an effect in Core Foundation objects. See also “Adopting Garbage Collection.”

 

[tacoman667]

Oops, duh. I forgot about the setting in the project settings for enabling/disabling/requiring of GC for the application. I couldn't remember if you had to declare it a certain way though, as in "new object".

 

[Krevnik]

This is every single OS in existence. A closed app relinquishes its resources back to the OS. Now. Not later. It isn't a matter of the app wanting to, it is OS enforced.

Yup, and this is because of modern protected memory.

Each app gets its own 4GB (if 32-bit) virtual memory map, split into pages. Some of these pages may be shared (kernel space, shared libraries, shared memory blocks)... but each page is tracked by the kernel. When a process dies for whatever reason, all its pages that it owned (and aren't currently shared with another active process) are marked as free for reuse, and flushed.

Doesn't matter how badly you thrashed your heap, or whatever. The kernel can release all memory pages associated with a process when that process exits or is killed. In modern OS environments, the heap and dynamic allocation are handled by the app's runtime library, not the OS. The OS doesn't know or care how the heap's memory is handled, it just watches page faults to determine if it needs to read a page from disk, or make room for a previously unused/unmapped page and 'create' it.

Now, back in the Win 3.1 and OS 8-9 days, this was different. But it sure doesn't apply anymore.

Although to quickly answer the OP's question: Yes. Unless you are using the Objective-C garbage collector, you are required to release all your object's instance variables. This is why there is a dealloc function to begin with.

If you have garbage collection turned on, then dealloc will never get called, but finalize will. (Don't release anything in finalize, but you can trigger some custom behavior if you really need to)

 

[yoavcs]

Although to quickly answer the OP's question: Yes. Unless you are using the Objective-C garbage collector, you are required to release all your object's instance variables. This is why there is a dealloc function to begin with.

Not completely correct.

@interface DemoClass : NSObject {
int aDemoVar;
}
.
.
.
@end

aDemoVar is an instance variable, and it is not one you need to deallocate.

 

[Krevnik]

Not completely correct.

@interface DemoClass : NSObject {
int aDemoVar;
}
.
.
.
@end

aDemoVar is an instance variable, and it is not one you need to deallocate.

I suppose I figured that it was obvious that non-objects (which cannot be retain/released) don't need to be released. /shrug