releasing local variables

Discussion in 'Mac Programming' started by shilpa, Jul 2, 2008.

  1. shilpa macrumors member

    Joined:
    May 29, 2008
    #1
    Hi all,
    in dealloc funcn do we need to release even local class variables other than releasing properties.
     
  2. tacoman667 macrumors regular

    Joined:
    Mar 27, 2008
    #2
    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.
     
  3. yoavcs macrumors regular

    Joined:
    Apr 7, 2004
    Location:
    Israel
    #3
    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.
     
  4. yoavcs macrumors regular

    Joined:
    Apr 7, 2004
    Location:
    Israel
    #4
    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.
     
  5. tacoman667 macrumors regular

    Joined:
    Mar 27, 2008
    #5
    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.
     
  6. yoavcs macrumors regular

    Joined:
    Apr 7, 2004
    Location:
    Israel
    #6
    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.
     
  7. tacoman667 macrumors regular

    Joined:
    Mar 27, 2008
    #7
    Is this Mac OS or Windows as well? I must be out of the loop then. I am primarily a Windows developer.
     
  8. MonkeyCookie macrumors newbie

    Joined:
    Apr 18, 2008
    #8
    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.
     
  9. yoavcs macrumors regular

    Joined:
    Apr 7, 2004
    Location:
    Israel
    #9
    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.
     
  10. tacoman667 macrumors regular

    Joined:
    Mar 27, 2008
    #10
    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
    Code:
    [[[obj alloc] init] autorelease]
    ?
     
  11. MonkeyCookie macrumors newbie

    Joined:
    Apr 18, 2008
    #11
    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.

     
  12. tacoman667 macrumors regular

    Joined:
    Mar 27, 2008
    #12
    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".
     
  13. Krevnik macrumors 68030

    Krevnik

    Joined:
    Sep 8, 2003
    #13
    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)
     
  14. yoavcs macrumors regular

    Joined:
    Apr 7, 2004
    Location:
    Israel
    #14

    Not completely correct.

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

    aDemoVar is an instance variable, and it is not one you need to deallocate.
     
  15. Krevnik macrumors 68030

    Krevnik

    Joined:
    Sep 8, 2003
    #15
    I suppose I figured that it was obvious that non-objects (which cannot be retain/released) don't need to be released. /shrug
     

Share This Page