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?"

Here's my contribution to the debate.

[mccalli]

Fantastic.

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

Re:...... Garbage Collection....

[repruhsent]

If people like you were in charge of innovation, we'd all be running Commodore 64s with hacked CP/M.

Technical details needed!

[Anonymous Coward]

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?

Re:uh, neat....

[ronanbear]

I'm quite happy that many programmers will be spending their time on application design rather than debugging memory leaks. Sure there are those out there with years of C experience who don't need this feature and I'm happy for them. They can continue to code the way they always have and they'll still be in demand. But there's another group who will find this really useful.

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.

Re:uh, neat....

[jfengel]

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.

Your knowledge of GC is 10 years out of date

[jbellis]

Modern GC is *faster* than hand-coded free calls in 90% of situations.

"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_(c omputer_science) [wikipedia.org]

--
Carnage Blender [carnageblender.com]: Meet interesting people. Kill them.

Re:Hacks and Novices Rejoice!

[kaffiene]

*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.

NOOOOOOO #@$#$@

[pestilence669]

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.

Re:In response to the naysayers...

[cnettel]

For now, but it seems to me that interoperability with a library that used garbage collection would require you to use it as well, or suffer some real pain while trying to work out the memory ownership semantics of a library that simply wasn't designed in those terms.

Re:Your knowledge of GC is 10 years out of date

[cnettel]

True. The most adverse effect of Java-like GCing is not the allocation method, it's the amount of allocations, and the references to wherever and whatever all the time. In C/C++, you can really store a string locally with an object. If you do it smart, you can even allocate the memory for several strings with dynamic size and still have guaranteed locality and a single heap allocation. In Java (or C#), you're almost bound to have several references, each with a separate vtable reference and so on. Structs in C# is a step in the right direction here, because they remove a tiny bit of the paradox that you have to choose between a nice OO representation or roll your own memory manager with no other primitives than, essentially, bytes.

And, to some degree, GC is responsible for the fact that it's impossible to do nice data structures on your own, as a GC needs to be able to track and relocate references. To do that, it has to grok your data structure.

Re:Yay! More Bloated Crappy Code

[Maury Markowitz]

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.

Re:NOOOOOOO #@$#$@

[m874t232]

You're missing the point of garbage collection. Garbage collection isn't there to save your effort. In fact, garbage collection does not save you effort at all. The purpose of garbage collection is to make the language safe and isolate errors, something that no other storage management scheme can achieve.

Both manual storage management and garbage collection each require a lot of experience to use correctly. Your problem is likely that you underestimate both how much work it took to become proficient at manual storage management/reference counting, and how much work it would take you to become proficient in a garbage collected environment.

many people miss the point of GC

[m874t232]

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.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:NOOOOOOO #@$#$@

[m874t232]

I detest it when a GUI pauses for no good reason,

And I detest it when a GUI pauses for no good reason, just because the manual storage allocator has needlessly held on to extra storage and the application is now forced to go to virtual memory.

Garbage collection can also lead to unpredictability.

There are different kinds of garbage collectors: some are intended for non-interactive programs and minimize long-term CPU overhead, while others give guaranteed real-time performance. There's also a middle ground of "near real-time" performance.

Furthermore, even with a non-real-time garbage collector, you can achieve real-time responsiveness if you know what you're doing. Of course, your comments suggests that you wouldn't know how, which is why you prefer sticking with manual storage mangaement.

Don't be a programmer-bureaucrat; someone who substitutes marketing buzzwords and software bloat for verifiable improvements.

Take your own advice to heart and try to actually verify your claims about manual storage management and garbage collectors; you'll be surprised.

Re:NOOOOOOO #@$#$@

[grammar fascist]

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.

You're missing the point, which is to make it easier to model a language mathematically. The easier the model is to reason with, the fewer errors you'll have. It frees your mind from petty concerns that arise from having an overly-complex language model.

We'll go back to Lisp to elucidate this, which has always cleaned up after itself. Lisp has a very strict underlying mathematical model. Consider math for a moment. Once you define something, is it ever undefined? If you've stated a truth, is it ever not true?

No. Likewise, in languages with garbage collection, once you create something, it exists, theoretically, forever. In the theoretical language model, memory is infinite. The fact that something cleans up stuff that isn't referenced because we happen to be using state machines rather than true Turing machines and need the memory back is merely a necessity of living in the real world.

There's a beauty and an elegance about "garbage collection" (i.e. the more-mathematical infinite memory model) that you're totally missing out on.

Mathematically speaking, mutable variables are a bad habit. As you say, bad habits, once bred, are hard to get rid of. Can you break this one? You don't have to, just think about it. The point is, I'm challenging you to expand your mind a bit and understand that what you hold dear isn't all there is in the world of programming.

Cyclical relationships, which shouldn't exist in decent code...

Where did this piece of utter tripe come from? Haven't you ever created a circularly-linked list? Must everything in memory be a tree?