Slashdot Mirror
Xcode Update Gives Objective-C Garbage Collection
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?"
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.
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:
... clears up after you, but it's no garbage collection, it's just a convenient way of using retain/release.
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]
ObjC 2.0 does real garbage collection, like java's. No retain, no release - just automatic management when objects fall out of context.
Simon
Physicists get Hadrons!
On the other hand, I feel automatic memory management is redundant in most situations. Warm fuzzy kind of feelings.
- These characters were randomly selected.
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.
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++...
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.
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.
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.
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
You need to read the PDF manual. There's a lot of stuff you're saying as fact, that is simply wrong.
Simon
Physicists get Hadrons!
"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
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.
i'd hit it so hard, if you pulled me out you'd be the king of britain [bash.org]
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.
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. ;-)
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
>It's also very fast
e s.htmlf
-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/issu
http://www.cs.umass.edu/~emery/pubs/gcvsmalloc.pd
http://en.wikipedia.org/wiki/Reference_counting
--Blerik
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.
This space for rent. All reasonable inquiries will be entertained at proprietors discretion.
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.