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?"
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?
I can feel myself waiting a few months, then ordering an updated Objective C coding book to pick this language up now.
Cheers,
Ian
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.
We developers will need far more technical details before we can even consider using this functionality in our applications.
What garbage collection technique is used here? How does it differ from the Boehm GC-based technique offered by the GCC Objective-C compiler?
Are any guarantees given with regards to the performance of the collector? Does it suffer from many of the problems that plagued the Java GC?
What sort of modifications do we have to make in order to take advantage of this support?
At the end of the day Apple aren't really catering for the top programmers here who will write good programs no matter what. It'll help the rest write better programs though.
the more they over-think the plumbing the easier it is to stop up the pipe
Far more exciting is that Leopard gets DTrace. Look at the last line of the page the story links to.
Well, let's say as exciting.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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!
It isn't even a question of how good a programmer you are. It's a question of how good a programmer everybody on the team is. And "team" includes every library you use.
When memory is passed across the boundary from one developer to another, you need some kind of mechanism to track who is going to free that memory, and under what circumstances.
Garbage-collected languages make that contract fairly clear. (But not infinitely clear; there are still ways to accidentally pin objects in memory even in a GC language).
In C we got used to putting in comments saying, "I'm passing you back a static structure, so I'm not re-entrant" or "This thing is malloc'ed so free it when you're done" or "You have to pass in a reference to that object and I'll fill it in". As long as discipline is followed the program works brilliantly (no GC overhead) but if any developer anywhere on the project misreads any single one of those comments, you're completely and totally doomed.
There is still software to be cranked out by one guy who can keep the entire thing in his head, but software requirements for most things are too big for just one guy. Even the uberest of uber-hackers is limited by the dumbest guy on his team, especialyl when that dumbest guy (even if he's pretty damn smart) nulls out a memory location that wasn't finished yet.
"Garbage Collection is cool cuz you don't have to, like, remember to delete stuff"
Shudder.
posted wirelessly via abacus and smoke signals
Modern GC is *faster* than hand-coded free calls in 90% of situations.
c omputer_science)
"A major reason for this is that the garbage collector allows the runtime system to amortize allocation and deallocation operations in a potentially advantageous fashion." -- http://en.wikipedia.org/wiki/Garbage_collection_(
--
Carnage Blender : Meet interesting people. Kill them.
*sigh*
I grew up programming in assembler and C. Even dinosaurs like myself know that memory allocation is not an issue for 99% of software projects.
Get with the new century dude.
>I'd like to know why isn't ObjC more popular outside Apple (and NeXT) circles
Because it's 'a failed language'. If they could come up with a rebrand (AJAX) or take the concepts and give it a syntactic revamp (maybe based round Ruby) they'd be well away, but the predominant line has been C to C++ to Java (and now C-sharp) - and only recently have Java developers begun to demand the features of a true OO language.
To be fair, there were good performance reasons why C++ won over Smalltalk regardless of it's productivity benefits, but these have become less and less important for UI bound programs.
'Capitalists of the world, unite! Oh
Objective C has one of the most elegant reference counting implementations on the planet. Virtually no thinking at all is required to manage memory. Cyclical relationships, which shouldn't exist in decent code, are its only limitation. It's also very fast. Anyone who argues that memory management in Objective C is difficult, should have their head examined.
Garbage collection is a step backward, IMO, but every language seems to be moving in this direction. I really do believe that resource awareness is crucial to efficient programming. Garbage collection encourages lazy programming habits, which I've seen in quite a few Java developers. Bad habits, once bred, are hard to get rid of.
Now, instead of profiling memory for leaks, you can profile the garbage collector, which I predict will be just as much of a headache as tracking down a memory leak. In the end, little work is saved, at least from my experience debugging other developers' Java applications. I won't know for sure until I play with XCode 3.
What's the new architecture it runs on?
As far as I can see it's still a Cocoa app, so while it's certainly possible (we know the Next frameworks would run on top of multiple kernels) it is unlikely unless Apple decided to open up the layers above Darwin (unlikely). Alternatively, resource could be put into the GnuStep project, but overall there seems very little interest in it. (The non-Apple Obj-C community is tiny).
DTrace is currently only on Solaris and BSD (at least last I knew).
I'd imagine there would be more hope in a project to add similar features to Eclipse, where you may at least encounter a pool of developer motivation (including Mac developers who don't want to work with XCode).
'Capitalists of the world, unite! Oh
Let me be the first to welcome our new garbage collecting Overlords.
I love Objective-C and Apple (NeXT) API's. However, while garbage collection does make it "easier" to write software, I have GREAT fears about people not leaning to clean up after themselves.
Case in point was a University project I did involving robots. Everyone happy sets about coding there little robots in Java, write some simulators, then write the actual robots logic, all in wonderful cross platform Java. Que 100 students pondering why real thing ran for 20seconds then started beeping at them. I spent a LONG time trying to explain to people that with 64k of memory, and NO garbage collection (yey "special" Java) you cannot just keep creating temporary objects at will and hoping mummy will clean up.
I think its super that Apple will be even easier to write for, but please make sure your know how to clean up after yourself before you start coding, you never know when silicon mummy will be on holiday.
NB. Not sure I mean "easier" to write software, maybe "allows you to write with a little more of your brain unplugged".
Practically every program I run under XP has a memory leak. As a result, quitting out of any of then leads to 15-20 seconds (yes, really) of disk griding while the VM dies. And this is on *quitting*. Does anyone else find it the least ironic that it takes longer to quit a program than start it?
I love listening to people complain about GC. Of course *they* are super-programmers that don't need any of this stuff, because their code never has *any* problems in it. But here I am with all these leaky programs. They leak memory all over the place and don't care. Why? Because I don't *need* to care about memory, everyone has 1GB anyway.
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.
Many people think that the purpose of garbage collection is to make programming easier. But that's not the purpose of garbage collection at all. Memory management in a garbage collected language is at least as much effort as memory management in a language with manual storage management, and it requires at least as much experience to use well.
The purpose of garbage collection is to make languages safer. If Objective C 2.0 has additional features to make it safer (variable initialization, pointer checks, etc.), then garbage collection will help it. Otherwise, it's just a gimmick.
Unfortunately, from Apple's web page, it's difficult to see what exactly they did; adding garbage collection to Objective C in a useful and correct way is a nearly intractable problem, and I won't believe that they succeeded until I see more data.
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!
Objective-C has no template system. This is a huge advantage for C++.
This is interesting because C++ has templates only because it needs them and Objective-C doesn't have them because there is no need. For instance, you can't have a C++ array of "anything", unless all objects descend from the same class, and then you are restricted to functions that were declared in that base class. That's because C++ is statically typed and needs to know the virtual table to use for the function call (whatever the function is). On the other hand, Objective-C does not need templates because function calls are not looked up through a virtual table, they are dynamically sent as messages, which are handled if the object implements that function. Hence, you can (and do) have a general-purpose array in Objective-C. You can even have a general purpose hash table with changing element types...! I'd love to see an implementation in C++ that is readable.
The "Object Penalty" (i.e. the cost of using a certain object-oriented language) is fixed, and it therefore reduces over time with faster and faster computers. C++ will do anything to make that cost as small as possible, including getting in your way. So really, the advantages of C++ are decreasing over time if you consider all the hoops you have to jump through to get what you want. When you really need performance in Objective-C, you write that little snippet of code in straight C (just like everyone else does in C++ .)
I was a C++ junkie for 10 years until I tried Objective-C and quickly noticed how much more complex a task I could handle without the language getting in my way. You should try it.
I think the "problems" are the elitist programmers who haven't realised yet that they actually aren't perfect... ;-)
Ooohh! Ooooh! -5 Flamebait! Go on, I dare you!
Seriously though, the major problem is that Java's advantages are rarely what the loudest advocates suggest. They'll talk incessantly about how they were able to get their app out in Java in only six weeks, and that it's all about making the programmer's life easier. That's not really it. What Java does is trap more errors, and moves from an insanity (manual memory management) to a more natural, free flowing, yet structured, memory model (at the end of the day, it's not even about garbage collection, that's just a side benefit of the memory model). And moreover, it prevents programmers from making common mistakes. And some programmers think that they are good enough to avoid those mistakes. But, you know what? I seriously doubt that. And I'm sometimes the guy who's running your program. And I don't trust you. You trust you. I don't. I'm being asked to trust you when I run your software, or when I add your software to mine, and I'd rather not. Not because I'm being insulting, or hate you, or anything like that, I'm just realistic. Even Knuth has had a few bugs to fix in TeX.
Java doesn't guarantee correctness, but it catches more bugs, and it makes some of the more dangerous ones - the buffer overflows, the stack overflows, etc, etc - practically impossible. I'd be curious to know if Objective C does the same thing, or if the obsession with the GC aspect of Java has gotten the better of everyone, again.
You are not alone. This is not normal. None of this is normal.
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.
This isn't a C versus Java discussion - it's Objective-C versus Objective-C with GC discussion, so your point is completely irrelevant as both OC with and without GC have stack allocation.
That said, *yes* stack variables allow a certain amount of programmer optimisation not explictly available to Java programmers, *but* that is all optimisation that the JVM can do via escape analysis (but you knew that, didn't you?). What's more, that kind of analysis can allow a JVM to optimise values onto the stack depending on usage - something not at all possible with C's ahead-of-time compiler.
Uhh, the effect isn't the same. A memory leak results in memory regions that are no longer available to the program, because the reference to the original region is gone. Thus, the memory can no longer be reclaimed. Clearly, that's not the case in the situation you described. You said yourself that the GC eventually reclaimed the memory... it just didn't do it when you wanted.
Oh, and BTW, your use of "sonny" is unsurprising, given your last experience with the Java GC was version 1.2. Maybe try updating your experiences and try again.
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.
As a C++ hothead, I think it would be great if GC was added to C++, contingent of course on it being added according to the spirit of C++, which is you don't pay for what you don't use. I.e. make it available as an option in the language, but not always activated. I'll also add, C++ programmers are used to and favor deterministic destruction, so a GC for C++ should be able to be triggered, and the language should specify that it doesn't return until all objects that could be freed at that point are. We like control, and guarantees. If it were implemented that way, I might even use it.
Attention zealots and haters: 00100 00100
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.