Forgot your password?
typodupeerror

Xcode Update Gives Objective-C Garbage Collection 285

Posted by timothy
from the alternate-tuesdays-bin-by-curb dept.
William Henderson writes "That's right, if you haven't read it for yourself yet, Objective-C '2.0' now supports garbage collection. I foresee a great, huge, gigantic debate about to ensue, and a lot of java-heads sparking 'I told you so'. Why not start it here on slashdot?"
This discussion has been archived. No new comments can be posted.

Xcode Update Gives Objective-C Garbage Collection

Comments Filter:
  • by Hootenanny (966459) on Monday August 07, 2006 @06:16PM (#15862072)
    AFAIK, garbage collection may be enabled or disabled as a compiler option. If you don't like it, then just disable it and carry on.
  • by Space cowboy (13680) * on Monday August 07, 2006 @06:31PM (#15862169) Journal
    An autorelease pool is a promise that when the pool is released, any objects with a retain-count of 1 will be released. So, you create your objects and call the autorelease method on them:

              NSAutoreleasePool *pool = [NSAutoreleasePool new];
              NSObject *myObject = [[NSobject new] autorelease];

    All that happens is that the object is added to an internal array, and when the pool itself is released, it calls [release] on all the objects in the array. I guess it actually calls [release] on the object as soon as it's gone into the array as well, or the object's retain count would be 2 when the pool was released (one for the 'new', one for the insert-into-array). So,

            [pool release] ... clears up after you, but it's no garbage collection, it's just a convenient way of using retain/release.

    ObjC 2.0 does real garbage collection, like java's. No retain, no release - just automatic management when objects fall out of context.

    Simon
  • by Rakshasa Taisab (244699) on Monday August 07, 2006 @06:41PM (#15862240) Homepage
    On the other hand, I feel automatic memory management is redundant in most situations. Warm fuzzy kind of feelings.
  • Re:uh, neat.... (Score:3, Informative)

    by pestilence669 (823950) on Monday August 07, 2006 @07:52PM (#15862670)
    Yes, but in Objective C there ARE standards for who frees memory. Whomever allocates an object must free it. This seemingly difficult methodology is accomplished with auto_release pools. When you return a new instance of an object, you send it a release message, which adds it to the auto release pool. Once your event loop is complete, every object in the pool is destroyed. If the recipient wants to keep a returned object around for a little bit longer, it sends it a retain message, which removes it from the pool. In practice, this method is exceptionally simple to use. The overhead is larger than manual destruction, but much less than garbage collection. Autorelease pools are great because object destruction is delayed until the next event loop iteration. This means that lazy access to the object, immediately after release, will work without penalty.
  • by Space cowboy (13680) * on Monday August 07, 2006 @08:22PM (#15862846) Journal
    • Because it can be a lot slower than C++.
      Well, actually if you really *need* speed, then ObjC groks C perfectly - it's a cast-iron guarantee that any legal C will work in objC, unlike C++. C performance is just as good as C++...

    • C++ gives you control over the object messasing system whereas Objective-C uses virtual methods for pretty much everything and there is nothing you can do about it.
      Um, no. Objective C uses dynamic despatch (ie: the method to run is determined at runtime not compile-time. This is one of its most powerful features. As for "nothing you can do", you can retrieve the bound method as an IMP (like a function pointer) and call it directly to remove any overhead. Useful in loops.

    • Objective-C is actually a lot like COM which is Microsoft's object extension for C. It was designed about the same time with many of the same goals. Both basically came about because of the incredibly slow progress C++ was making at the time.
      No. Objective C was designed as an adaption of the ideas behind smalltalk, as applied to C. It was designed in the early 1980's, COM was designed in 1993, although it wasn't called COM until 1997.

    • Objective-C has no template system. This is a huge advantage for C++.
      Well, that's a matter of opinion, but in any case, Objective C is a dynamic language. Most of the power of templates is encapsulated within the dynamic-despatch abilities of the language, coupled with the 'protocol' feature of the language.

      It could be said that Objective-C is a lot like Java with many of the same problems but because it was never marketed with a cross-platform VM it didn't take off like Java.
      I think it is significantly like java, but it's compiled (like C/C++). It's a *lot* faster than Java, and handily beats gcj too, at least on the tests I've done. You need to enumerate these "same problems" before I can respond though.

    • Overall C++ is more C-like than Objective-C. That is it gives you much more control over the exact level of performance versus ease-of-use that you want
      Um, take any legal C code and it *might* compile in C++. It *will* compile in ObjC - how can C++ be "more like C" than ObjC ?

    ObjC has introspection, dynamic binding, (now) optional garbage collection, (always) a very easy retain-count allocation system, really easy-to-learn constructs (I think there's 12 new statements, or something like that), *and* a weird syntax - it grows on you though :-) It actually does surprise me that more people don't like it. If Macs get more popular, who knows, perhaps it will have its day in the sun...

    You need to read the PDF manual [apple.com]. There's a lot of stuff you're saying as fact, that is simply wrong.

    Simon
  • by mccalli (323026) on Monday August 07, 2006 @08:38PM (#15862915) Homepage
    OK - here's a comparison. App is a multi-threaded market data-driven app. Server-side, so no GUI. Uses around a gig to gig-and-a-half of RAM. Idea is to read in market data, process and response to it in sub-millisecond time.

    "Stop the world" garbage collection for this app usually takes less than 13ms. And it very rarely occurs - you can code appropriately for a garbage collector too, and minimise it ever reaching this level. Usual GC times is between There isn't a human alive that could interact with a GUI in 13ms. So no, you need sub-millisecond performance 'every time you need to interact with a user' is not actually true.

    Cheers,
    Ian

  • Re:NOOOOOOO #@$#$@ (Score:5, Informative)

    by bar-agent (698856) on Monday August 07, 2006 @09:23PM (#15863108)
    Objective C has one of the most elegant reference counting implementations on the planet. Virtually no thinking at all is required to manage memory.

    Oh, is that why the Cocoa-Dev mailing list has a brand-new reference counting question every damn day? It is clearly not as simple as you think.
  • by Anonymous Coward on Tuesday August 08, 2006 @02:09AM (#15864144)
    The entire scheme is lexical. If you do a [obj retain] you are responsible for doing the [obj release]. So,

    [[NSMutableArray alloc] init]

    will require you to release the array object, but

    [NSMutableArray array]

    won't. Objects added to autorelease pools are automatically released at the end of each runloop. It's a convenience thing... so instead of doing:

    NSMutableArray *ary = [[NSMutableArray alloc] init];
    [someObject setValue:ary forKey:@"someKey"];
    [ary release];

    you can do either [[[NSMutableArray alloc] init] autorelease] or [NSMutableArray array] (which does exactly the same thing) and drop the release. Voila! One whole line of code saved/invested. Also you can use ObjectAlloc (from a menu in Xcode) to see stacks of everything that has been allocated.

    Having said all of that, memory management is tricky in Cocoa because *everything* is tricky in Cocoa. Lots of entry/exit points in the code which can make it difficult to determine where a problem occurs even w/ NSZombie's and a nice stack trace. Complicated user paradigms, i.e. cut & paste and undo & redo.

    That's not a complaint, just a statement. More options = better.

  • by Glock27 (446276) on Tuesday August 08, 2006 @07:48AM (#15864849)
    I really do feel that manual memory management in most apps is now redundant. i fully accept its need in some cases an indeed I've advocated 'regressing' an app at work, which was ported from C to Java, back into C again to use manual memory management for performance. But that app's an exception - sub-millisecond performance is required. How many day to day apps need that?

    Bad idea if you're doing heap allocation in a time-critical code section. Heap allocation ala 'malloc' isn't deterministic, it can take significant time if there's heap fragmentation.

    Better to pre-allocate everything before going into the time-critical part. In which case GC is fine. ;-)

  • Re:NOOOOOOO #@$#$@ (Score:2, Informative)

    by ysachlandil (220615) on Tuesday August 08, 2006 @08:56AM (#15865146)
    >It's also very fast

    -sarcasm on-
    Excuse me? A reference counting implementation that is fast. Could you please post some links to articles describing this magical algorithm?
    -sarcasm off-

    Mark-and-sweep GC or copying GC is _always_ faster than doing reference counting.

    references:
    http://www.hpl.hp.com/personal/Hans_Boehm/gc/issue s.html [hp.com]
    http://www.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf [umass.edu]
    http://en.wikipedia.org/wiki/Reference_counting [wikipedia.org]

    --Blerik
  • by powerlord (28156) on Tuesday August 08, 2006 @01:10PM (#15867636) Journal
    Oddly your description of Objective-C resonates with descriptions of Perl I have read. :)

    I'm going to have to take a look at it.
  • Re:Library only GC (Score:2, Informative)

    by Haeleth (414428) on Wednesday August 09, 2006 @06:20AM (#15872345) Journal
    The library is compiled with GC on, so when the method returns the object, the object is registered with the GC to be watched for its reference count going to zero, for example. Now you don't wish to use GC in your own code, so you compile with it off. Then the compiler will never add the code to effect decrementing the reference count in the GC's tables, so the object will never be GC'ed.

    You're right that mixing GC'd libraries with non-GC'd libraries would probably be a Bad Thing, but your idea of how a GC might be implemented is curious. I can think of few systems likely to perform worse than one based on a global table holding reference counts, thus combining all the disadvantages of reference counting (decreased performance due to the need to update reference counts constantly and atomically, inability to handle cyclic data structures) with a massive loss of memory locality (hello, cache misses galore!).

    Perhaps you should go and read up on how GC works. You might find it interesting. :)

Man must shape his tools lest they shape him. -- Arthur R. Miller

Working...