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

Comments

Hacks and Novices Rejoice!

[Anonymous Coward]

"Garbage Collection is cool cuz you don't have to, like, remember to delete stuff"

Shudder.

Re:Hacks and Novices Rejoice!

[profet]

"Garbage Collection is cool cuz you don't have to, like, remember to delete stuff"

Shudder.

posted wirelessly via abacus and smoke signals

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.

Re:Hacks and Novices Rejoice!

[Anonymous Coward]

Just wanted to point out that profet was making fun of the parent of his comment...

Re:Hacks and Novices Rejoice!

[botik32]

memory allocation is not an issue for 99% of software projects.

Well, it should not be, unless it is poorly implemented (I hope). The Java GC leaves java apps out of my desktop, and will probably keep so for the next 5 years.

Hmm, on the second thought, I think programmers are to blame for some of it, too. The fact that you can easily allocate stuff on the heap does not mean you should do it ALL the time, in an app that would be running for days (like azureus). You would be better off allocating a buffer once, and pass it down many times, instead of allocating stuff ad-hoc and returning it up the call chain. It may (gasp!) use more memory, but will perform better in the long run. From what I have seen, defragmentating memory is a cpu-consuming task; it would be stupid to rely on an expensive maintenance process to keep your program running.

In C you get to deal with memory issues directly, and that has a huge benefit: you have the chance to spot the patterns that fragment memory over time, early. Unfortunately, Java lets you do whatever you want. In this regard, it is worse than C.

Get with the new century dude.

Thanks, but no, thanks :).

Re:Hacks and Novices Rejoice!

[cappadocius]

Hacks and Novices Rejoice!

Oh no, now hobbyist Java programmers like me will be able to more easily learn Objective-C and write native Mac apps for our own amusement that you will never have to use or even acknowledge. I feel your pain.

Re:Hacks and Novices Rejoice!

[kaffiene]

I've been coding C for just under twenty years and I can tell you, you're wrong. Modern GC's allocate faster than C's malloc routine. Java does tend to allocate more than euqivallent C programs due to the lack of programmer access to the heap, but that's Java's choice (and not one that a smart JVM can't work around anyway). BUT, we weren't discussing Java, we were discussing GC, and the fact is that modern GC is more often faster than explicit memory allocation and de-allocation (this has been proven multiple times, go Google for it if you care to educate yourself).
Dealing with memory yourself is a huge benefit for about 1% of real code, for the rest it's just an area to make unneccesary errors in for no gain.

Re:Hacks and Novices Rejoice!

[famebait]

One really cool thing about GC that rarely see brought up is that it allows a lot of more elegant and compact code constructs. I don't mean justs skipping the mem-management calls. I mean stuff like chaining calls (calling functions on anonymous returned values from other calls), and operator overloading, can actually be implemented and used in a sane way. Anyone who has tried to implement C++ operators for modestly complex objecs must have banged their head into the dilemma that you can't actually use those operators without creating memory leaks, or at least to avoid it requires so much fiddly work that it negates the benefit of using operators. With GC it is suddenly elegant again.

Re:Hacks and Novices Rejoice!

[famebait]

you can't actually use those operators

I mean, of course you can use them for simple assignment, but the whole attraction of creating operators in stead of normal member functions is to be able to set up complex expressions with them, ineveitably creating quite a lot of fleeting intermediate results that you never even get a handle to.

Re:Hacks and Novices Rejoice!

[Bill Dog]

You seem to be under the bizarre impression that C++ does not destruct temporary objects.

Re:Hacks and Novices Rejoice!

[botik32]

You conveniently forgot that most C applications use stack allocated variables which hugely outperforms ANY heap allocation. Moreover, C and does not wrap low-level data into objects like Java does, thus there is another huge boost.

Re:Hacks and Novices Rejoice!

[kaffiene]

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.

Re:Hacks and Novices Rejoice!

[StrawberryFrog]

101 Reasons why Java is better than .NET - http://helpdesk-software.ws/it/29-04-2004.htm

I stopped reading around #7: There has yet to be a production release of a database that supports any .NET languages.

MS SQL Server 2005 does this. That item is wrong.

#8 Nobody seems to know how to write .NET programs well

this is not even wrong, just completely content-free.

Re:Hacks and Novices Rejoice!

[DEN_GUY]

You actually cannot guarantee that all objects are properly released at the language level without GC. Please refer to Meyer's "Object Oriented Software Construction". If it doesn't have GC, it's not OOP. Period.

Re:Hacks and Novices Rejoice!

[Anonymous Coward]

Just another asshole with an opinion. Offer a theoretically interesting but in practice totally irrevelant factoid. Don't back it up with a specific example, just tell everyone to go read a book. Then make a completely off-the-wall asinine statement. With emphasis. To underscore that your mind is closed tight in addition to being obsessed with esoterica.

Re:Hacks and Novices Rejoice!

[Weedlekin]

"#8 Nobody seems to know how to write .NET programs well

this is not even wrong, just completely content-free."

And from what I've seen, not many people know how to write Java programs well either.

Re:Hacks and Novices Rejoice!

[kaffiene]

Dude! It's a polemic :o) Did you *really* expect to find 101 *deep technical* reasons why Java is better than .NET? I mean, C# is a copy of Java after all :o)

It's tongue-in-cheek. You get subtlety, don't you?

That said, there's at least 99 really good reasons why Java is better than .NET in that list.

I told you so!

[Anonymous Coward]

But it's about time if you ask me!

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:Here's my contribution to the debate.

[Rakshasa Taisab]

On the other hand, I feel automatic memory management is redundant in most situations. Warm fuzzy kind of feelings.

Re:Here's my contribution to the debate.

[argent]

I feel automatic memory management is redundant in most situations.

Yeh, let's bring back allocating memory on a big sheet of graph paper on the wall of the coding pen!

Re:Here's my contribution to the debate.

[CoughDropAddict]

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?

Every app that ever interacts with a user. It is never acceptable for an app to stop-the-world while it does something that I (as a user) do not care about. I get enough spinning beach balls as it is.

Re:Here's my contribution to the debate.

[mccalli]

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:Here's my contribution to the debate.

[mccalli]

Argh. Meant "Usual GC times are between <1 and 3ms". Missed the fact it would start a tag.

Cheers,
Ian

Re:Here's my contribution to the debate.

[CoughDropAddict]

"Stop the world" garbage collection for this app usually takes less than 13ms.

"Usually" isn't good enough, not when "usually" just made you drop a video frame or overrun a sound buffer. Out of curiosity, though, what language is this? Experiences I have had with Java involved watching the GUI freeze when garbage collection happens. I would be happy to hear that GC wait times had indeed gotten this fast, though it's also likely that your fast GC is a result of your particular allocation patterns.

Re:Here's my contribution to the debate.

[bsartist]

I really do feel that manual memory management in most apps is now redundant.

Yes, it is. But, the "traditional" memory management in Cocoa is already at least 90% automated. What it amounts to is a few boilerplate calls in accessor methods. Xcode has been able to automatically generate simple accessors for quite some time, and for not-so-simple use there's Accessorizer.

The biggest stumbling block I see most newbies having is that a) they're accustomed to not doing any memory management at all in Java and assorted scripting languages, and b) they've heard all sorts of horror stories about how difficult MM is. So they tend to over-react and over-think it, and as a result make it far more complicated than it needs to be. Instead of simply following the simple design patterns suggested by Apple, they sprinkle -retain and -release messages throughout their code, and then try to figure out what's wrong by using the debugger to examine the reference counts directly.

In short, the problem with today's Cocoa memory management isn't that it's difficult to use as designed, it's simply that too many people won't read and follow the guidelines for using it as designed.

Re:Here's my contribution to the debate.

[bar-agent]

"Usually" isn't good enough, not when "usually" just made you drop a video frame or overrun a sound buffer.

Yes, but not every app a user interacts with has video or sound. And, doesn't the OS run most video and sound processing? Just because your own app is garbage-collected, that does not necessarily have an impact on how the OS does what it does.

Re:Here's my contribution to the debate.

[Breakfast Pants]

'Every app that ever interacts with a user. It is never acceptable for an app to stop-the-world while it does something that I (as a user) do not care about. I get enough spinning beach balls as it is.'

You realize that a call to malloc is nondeterministic don't you? You get the same problem with manual memory management, there is just a lower average time; but 'stop the world' still happens.

Re:Here's my contribution to the debate.

[CoughDropAddict]

You realize that a call to malloc is nondeterministic don't you?

malloc only blocks threads that are calling malloc. "Stop the world" blocks threads no matter what they are doing. Big difference.

Re:Here's my contribution to the debate.

[CoughDropAddict]

And, doesn't the OS run most video and sound processing?

No -- the OS's job is to deliver buffers to and from user space programs. The user space programs perform the processing. If a user space program doesn't deliver or retrieve a buffer in time, you get an buffer underrun or overrun, respectively.

Re:Here's my contribution to the debate.

[Simon]

Experiences I have had with Java involved watching the GUI freeze when garbage collection happens. I would be happy to hear that GC wait times had indeed gotten this fast

I'll not much of a Java fan, but in all fairness the last time that I saw a Java based GUI "pause" due to garbage collection was at least 3-4 years ago while IDEA in this case. We're using Eclipse now at work and it doesn't stop and pause for garbage collection. It is slow all the time. ;-) But I don't think I can blame the VM for that one.

Better garbage collection algorithms in the VM have fixed the pausing problem.

--
Simon

Re:Here's my contribution to the debate.

[stevey]

I'll not much of a Java fan, but in all fairness the last time that I saw a Java based GUI "pause" due to garbage collection was at least 3-4 years ago while IDEA in this case.

I'm not a huge Java fan either, but I have to agree. Things there have gotten much better.

There is only one program/environment which I can see "freeze" due to (I assume) garbage collection these days, and that is GNU Emacs!

Although Emacs has gotten much better too, it still has some weirdness in the 21.x releases (mostly relating to cursor redesplay issues, and freezes due to GC)

Re:Here's my contribution to the debate.

[Glock27]

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:Here's my contribution to the debate.

[Randolpho]

I'm not 100% sure about Java, but in .NET, garbage collection only occurs when the heap is full. I'm, pretty sure it's the case with Java too.

If an app is causing lots of stop-the-world thread blocks, the problem lies with the app and an over-reliance on short-term objects, *not* garbage collection. Blame the developers of the application and their poor engineering.

Re:Here's my contribution to the debate.

[nuzak]

> sub-millisecond performance is required

There *are* Java VM's with realtime characteristics, including realtime garbage collection, so that alone wasn't a great reason. I suspect however that your app merely needed to be snappy, not realtime, because you'd have to put just as much discipline and restriction into C (including not just throwing around malloc/free willy-nilly, as it does NOT have constant performance) as you would in realtime Java (not using half of java.util and java.lang's awful implementations). The funny thing about these JVM's is that they don't typically do JIT. Bytecode is much easier to guarantee performance with than arbitrary native code.

Not knocking you, I've moved apps to C++ for performance when I could have gone gonzo with optimizing, but it's neither Java nor gc that's a problem when it comes to realtime. Now if you need sub-microsecond response, you really gotta go with dedicated hardware.

uh, neat....

[DrunkBastard]

Well, let me be the first to enter the, "Guess I'm not using Objective-C" camp. Adding garbage collecting to this language is just a continuation of the "throw more resources at it and it'll all work just fine" mentality that exists in modern application design. Yes, the ease of use of garbage collecting has it's uses for the quick fire and forget projects and one time use apps. But other than that, bah I say!

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

[DrunkBastard]

good point. A co-worker and I were just talking about the already existing "garbage collecting" mechanisms in Objective-C regardless of this latest update, and I was simply hitting a wall about why the pseudo garbage collection existed, because I couldn't imagine such poor memory management to begin with, or a program design that would allow for this poor memory management. Like you said, if you were brought up in programming doing things cleanly and efficiently, than you don't need it, but for those who's first taste of "real" (and I use this loosely) programming was java or similar languages, than they missed out on the keep it lean, keep it clean paradigms.

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.

Re:uh, neat....

[nacturation]

Adding garbage collecting to this language is just a continuation of the "throw more resources at it and it'll all work just fine" mentality that exists in modern application design. Yes, the ease of use of garbage collecting has it's uses for the quick fire and forget projects and one time use apps. But other than that, bah I say!

No kidding. What's next... automatic IP packet collision avoidance? No thanks, I roll my own.

Re:uh, neat....

[pestilence669]

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.

Re:uh, neat....

[paulxnuke]

Well, let me be the first to enter the, "Guess I'm not using Objective-C" camp

I'd love to find a way to make a living with Objective-C, if I can turn GC totally off (I assume that's possible.)

I've tried C# and managed C++ and hated both: one reason was the atrocious coding style they encourage. Objective-C is a particularly elegant and powerful C, which makes the idea even uglier, like mud wrestling in a tuxedo.

Kludging a GC library into any version of C is like pulling a U-Haul with a race car, not because it slows things down (it doesn't, in most cases) but because it doesn't fit. C++ is not about being sloppy because a runtime lets you avoid learning how to use the language. Leave GC where it's needed and serves a purpose: functional languages, scripting languages, lisp. Bolting it on to C does nothing but encourage incompetents to remain incompetent instead of moving on where they belong, be it a higher level language or McDonald's. Whoever said C++ (or any other language) has to be accessible to everybody? They tried that with VB and Lingo, and in both cases we got a few more bad programmers, the same crowd who still didn't get it, and a crappy new language to sell books.

Yell troll if you will, but given enough experience to be paid for coding (less than it takes to play most musical instruments or learn a natural language well), C++ memory management just isn't that hard, and not getting it right or refusing to try suggests a the kind of attitude I wouldn't hire. Qualified coders are going to be rarer every day the way things are going.

Re:uh, neat....

[pestilence669]

Correction: You send objects the "autorelease" message to use autorelease pools. "release" is the same as "delete object_here;" Otherwise, the general idea of my posting is the same.

Re:uh, neat....

[mrchaotica]

Here's the funny thing, though: Objective-C is supposed to be like SmallTalk... and SmallTalk has garbage collection!

Remember, garbage collection isn't just Java. It's been around much longer than that in lanugages like SmallTalk and LISP. And as with everthing except ActiveX, it's good for the uses it's designed for.

Re:uh, neat....

[feijai]

"release" is the same as "delete object_here;" Otherwise, the general idea of my posting is the same.

"Release" decreases the reference count on the object by 1. If the count goes to zero, the object is freed. Else it is not.

Re:uh, neat....

[Weedlekin]

"Here's the funny thing, though: Objective-C is supposed to be like SmallTalk... and SmallTalk has garbage collection!"

Which is why Brad Cox's original StepStone Objective-C also had garbage collection. This is not therefore something Apple have added to the language, but a standard feature that should have been in their version from the beginning.

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

[MyDixieWrecked]

I'm confused... I thought that ObjC did have garbage collection...

isn't that what the Autorelease pool is for? or is this more automatic?

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

[repruhsent]

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

In response to the naysayers...

[Hootenanny]

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.

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.

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:Technical details needed!

[jonwil]

As far as I know, xcode uses the apple port of GCC under the hood so unless there is something heavily tied into xcode here, one can just take the stuff from apple GCC source tree and port it to mainline GCC.

And Leopard has DTrace

[SuperKendall]

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.

Re:And Leopard has DTrace

[_damnit_]

Nice catch there! I missed that little blurb earlier. GC is nice and everyone can debate whether they like it or not, but DTrace is loved by almost everyone who touches it. I would think DTrace would be on the top of the list of things advertised to developers at WWDC. By default, that would make Leopard my favorite MacOS X platform to develop on.

Re:And Leopard has DTrace

[Anonymous Coward]

Oh it definitely gets DTrace...

http://www.apple.com/macosx/leopard/xcode.html

Nonlinear debugging with an Apple GUI. Sounds great. Too bad I wasn't at WWDC...

Re:And Leopard has DTrace

[modeless]

Also, a rewinding debugger. With that and DTrace and garbage collection, maybe it's time I tried XCode again. I guess Apple's realized that Visual Studio is the best thing Microsoft has going, and if they can better it they'll truly have the superior platform.

why is it....

[Anonymous Coward]

... that this is under it.slashdot.org? shouldn't this be under apple.slashdot.org?

that aside, given the new architecture xcode runs on, is there a way to get an x86 port for linux of xcode?

Re:why is it....

[JulesLt]

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

Re:why is it....

[Guy Harris]

What's the new architecture it runs on?

He probably meant x86, but that's not exactly "new" as in "it just happened" - XCode has supported x86 for a while now.

DTrace is currently only on Solaris and BSD (at least last I knew).

"Currently", yes, but the XCode 3.0 page says "Many such Xray instruments leverage the open source DTrace, now built into Mac OS X Leopard."

Re:why is it....

[xouumalperxe]

If there is a way, it's not easier than getting xcode to run on a ppc linux box.

Re:why is it....

[JulesLt]

I should have been clearer - I was including OS X as a flavour of BSD.

What I meant was that XRay isn't going to work on Linux without DTrace also being ported. i.e. there are least two dependencies (Cocoa and DTrace) that don't exist on Linux.

Re:why is it....

[mallardtheduck]

There is GNUStep, which is a clone of the older NeXTStep API's, so it should be vaguely Cocoa-ish, but all this is fairly moot seeing as the XCode IDE is closed source.
Only the compilers and other backend bits are open source.

Re:why is it....

[JulesLt]

Yes, it's always been a surprise to me that despite the evident interest in Mac software from the Linux community, so little effort has been put into the one project that would help (the fact that Obj-C is in high demand for developing Mac software is probably another factor).

At the very least it would make it easy to develop equivalent software - I won't pretend to know enough about the internals of MacOS to know whether you could run a Cocoa app over a different implementation, in the same way you could with OpenStep. but I suspect if the app was purely Obj-C you could - i.e. if everything is Obj-C extended from the original core NextStep classes, then you should be able to extend GnuStep in the same way (given that the classes are documented).

However a lot of apps have dependencies on other Apple APIs that have been wrapped in Obj-C. i.e. QTKit would be far more difficult as it's a mapping of QuickTime, rather than an extension of Obj-C. Something like CoreData would lie inbetween (it has a dependency on non Obj-C libraries, but a database is a database).

XCode 3.0

[Anonymous Coward]

I am very curious about what XCode 3.0 entails in general, but cannot find much information about it. Is there complete coverage somewhere?

Apple seriously needs to get on modernizing their tools. XCode was great when it came out, but it's now years later and their current tools look archaic next to the competition, and until now Objective-C hasn't been updated since like 1985.

Re:XCode 3.0

[Trillan]

Archaic compared to the competition? Are you defining Visual Studio as "not part of the competition" through some odd criteria? (Although I'll agree there are some other very nice tools out there.)

Not sure if you're joking, but...

[Space cowboy]

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

Re:Not sure if you're joking, but...

[Anonymous Coward]

The GNU runtime has support for GC for a long time before even Apple was deciding to add it to their runtime (NeXT).

Re:Not sure if you're joking, but...

[MyDixieWrecked]

not joking. just asking for clarification.

I never really read up on garbage collection, but from the way it was originally explained to me, when I learned ObjC after learning Java, I kinda grouped the autorelease pool in my mind with Java's garbage collection.

I guess ObjC's is just a kind of slapped together GC-like implementation?

Re:Not sure if you're joking, but...

[TheUser0x58]

Something everyone seems to forget: Objective C does not have autorelease pools. Autorelease pools are something implemented in Cocoa (which happens to be written in Objective C) to simplify some memory management tasks.

Re:Not sure if you're joking, but...

[Space cowboy]

ObjC implements a nice-and-easy reference-counting memory management system. Autorelease pools are simply a convenience function based on the underlying reference-counted objects. I think it works well though - I think "slapped together" is a bit of an emotional-loaded term for how it works...

Simon

Re:Not sure if you're joking, but...

[bogomipz]

This explaination of NSAutoreleasePool is wrong. The parent seems to think that the point of an autorelease pool is to release a number of objects by releasing the pool itself.

Typically, an application will create an autorelease pool on startup and use that single pool for the rest of its life time. After the main loop exits, the application might call [pool release] for the sake of good habit, but it's not really necessary since this is at the very end of the program, and all memory is freed on exit anyway.

The real point of autorelease pools is to let a method say; "I want this object to be released when my callers are done with it." Remember that releasing an object does not necessarily mean destroying it. It means to decrement its retain-count, and if the count reaches zero, kill it.

The way this happens is probably like the parent describes - the autorelease pool adds the object to an internal array, and releases it once because the array retains it. At some later point the pool is told do the promised release of the objects, so it empties the array, meaning that every object in there is released. Here comes the important part; this "some later point" needs to be at a time when it is guaranteed that all of the callers to the original method have had their chance to retain the object, so a good time to do it is when the call stack has unwinded all the way up to the main loop. That is, the main loop tells the autorelease pool to do its thing once per iteration.

The grand-parent asked:

I'm confused... I thought that ObjC did have garbage collection...
isn't that what the Autorelease pool is for? or is this more automatic?

The answer to that is;

• There have for a long time been some GC libraries for ObjC, but none were part of Cocoa.
• Cocoa's autorelease pools have nothing to do with GC, all they do is let a method ask for a delayed decrementation of an object's retain-count.

Re:Not sure if you're joking, but...

[MyDixieWrecked]

I think "slapped together" is a bit of an emotional-loaded term for how it works...

that's not how I meant it.

Re:Not sure if you're joking, but...

[Space cowboy]

• This explaination of NSAutoreleasePool is wrong. The parent seems to think that the point of an autorelease pool is to release a number of objects by releasing the pool itself.
  
  The explanation is not wrong. I do think that it is *a* use for autorelease pools, and I'm in good company - from the NSAutoreleasePool documentation:
  

  If your application or thread is long-lived and potentially generates a lot of autoreleased objects, you should periodically destroy and create autorelease pools (like the Application Kit does on the main thread); otherwise, autoreleased objects accumulate and your memory footprint grows. If your detached thread does not make Cocoa calls, you do not need to create an autorelease pool.

  
  
  
• Typically, an application will create an autorelease pool on startup and use that single pool for the rest of its life time. After the main loop exits, the application might call [pool release] for the sake of good habit, but it's not really necessary since this is at the very end of the program, and all memory is freed on exit anyway.
  
  There are normally at least 2 autorelease pools used by Cocoa code - one is created in NSApplicationMain, and for every cycle through the event loop, a child-pool is created and destroyed. For simple UI-based apps, this is usually sufficient to for the coder to not bother creating any more.
  
  If you have background threads that use Cocoa (or most of foundation, even NSLog() requires this), you must create a pool on entry to the thread selector, and if you have while-loops which allocate a lot of autoreleased objects, it is good practice to have an autorelease pool created as the first statement of the loop, and destroyed as the last statement. It's always a judgement call as to when to do this, but in general keeping the memory footprint lower is a good idea. On background threads, it's crucial - otherwise the memory-footprint of your infinite loop in the background will just grow indefinitely.
  
  
• The real point of autorelease pools is to let a method say; "I want this object to be released when my callers are done with it."
  
  Well, that's *one* use of them. Managing memory efficiently is another.
  
  Simon.

Why not Objective C?

[Anonymous Coward]

From what I understand it's a minimal OO extension of ANSI C, that is easier than C++ to learn and easier to compile. The addition of native garbage collection to the std lib could offer huge gains in development time. I'd like to know why isn't ObjC more popular outside Apple (and NeXT) circles?

Re:Why not Objective C?

[JulesLt]

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

Re:Why not Objective C?

[Cthefuture]

Because it can be a lot slower than 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. 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.

Objective-C has no template system. This is a huge advantage for C++.

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.

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.

Re:Why not Objective C?

[Anonymous Coward]

Templates are anti OO.

Re:Why not Objective C?

[Novajo]

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.

Re:Why not Objective C?

[Anonymous Coward]

Objective C is simpler and easier to learn than C++, but programming in Objective C (epecially with openstep) requires a fairly solid understanding of design patterns. It is a very smooth and easy language once you understand them, but learning how to write good objective C is one giant mountain of a learning curve. It is hard to write 'bad' code without realizing it.

Of course, it requires a lot of knowledge to program good C++ as well, but it is easy to write bad C++ and not even realize it. Thus many programmers will write merrily on their way in C++ and not even realize that their code is an ugly mess.

Here is an interview with Bjarne Stroustrup where he gives a similar point of view (although I don't think he likes Objective C).

Re:Why not Objective C?

[neutralstone]

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

Sounds like someone hasn't tasted the sweet goodness of Boost. (:

In particular, Boost.Any gives you a simple and type-safe way to have a ${favorite_container_type} of anything.

See here:

http://boost.org/doc/html/any.html ... and see also:

http://boost.org/libs/libraries.htm

The nice part is that if you're using XCode and you're writing an app for the Mac, you don't have to choose between Obj-C and C++; you can use Objective-C++.

Re:Why not Objective C?

[n3m6]

It would be interesting if John Carmack's views, if he jumps into this conversation. Afterall, he went from Objective-C (Quake 3) to C++ (DOOM 3).

Re:Why not Objective C?

[Valdrax]

Sounds like someone hasn't tasted the sweet goodness of Boost. (:

Like most of Boost, it's a hack. An elegant, beautiful hack but a hack nonetheless, meant to implement in code missing features built-in in other languages.

Reading the code in the Boost libraries gives me headaches -- and often gives various compilers fits. (Templated templates, anyone? I had to find documentation for THAT in a footnote in the appendix to chapter on templates Stroustrup's book, and the Solaris compiler didn't support it fully at the time.)

I much prefer Objective-C's way of doing things to C++'s even despite the mystical "woojiness" of Boost.

Re:Why not Objective C?

[jonwil]

Quake III does NOT use Objective C. If nothing else, it compiles on Visual Studio and unless microsoft has omitted it from the documentation somewhere, Visual Studio does NOT do Objective C.

Re:Why not Objective C?

[neutralstone]

> Reading the code in the Boost libraries gives me headaches

I haven't had headaches yet, though I do go through a certain emotional pattern.  There is pseudo-syntax for it:

  human-reaction-to-boost:
      What /expletive-expression/...
      How /expletive-expression/ did they do that?!
      That's /expletive-expression/ amazing!

One of the upshots of reading Boost header code is that it forces you to learn more (or remember more) of the convoluted yarn that is Standard C++.

I see that as a good thing, though I can empathize with the notion that good generic code shouldn't force the reader to become too familiar with obscure language parsing rules.

>  -- and often gives various compilers fits

It depends on the compiler.  The key is ISO Standard compliance.  The more your compiler supports Standard C++, the more likely it will handle the exploitive uses of C++ features found in Boost.

E.g., practically anything with an EDG front end released in or after 2003 can be regarded as fully Standard-compliant, which means you shouldn't get any fits when you compile Boost-using code.  Recent versions of GCC (3.4.x and later) rank at a pretty close second on the compliance-o-meter.  MSVC 7.1 and 8 are *much* closer to compliance than MSVC 6, but are still a bit rough in some less-provoked areas (mostly involving subtle aspects of name lookup and template processing).  I think Sun is in a position similar to Microsoft, though I don't know what their weak points are.  (All I know is that, due to pressure from Boost-using customers, recent versions of their compiler should handle it better.)

> I much prefer Objective-C's way of doing things to C++'s
> even despite the mystical "woojiness" of Boost.

Well, to each his own; but just remember that the existence of Obj-C++ means the woojiness is always within your reach, should the desire for woojiness* suddenly overtake you -- or should you hit a problem that would be most elegantly solved with a design that uses a function template.  (:

*Props to you for use of the word "woojiness".

Re:Why not Objective C?

[Anonymous Coward]

regardless of it's productivity benefits

"its".

Re:Why not Objective C?

[Anonymous Coward]

Please don't use monospace unless you are posting code or similar stuff.
It makes you look like an idiot.

Re:Why not Objective C?

[ifknot]

Because it wasn't available outside of Apple (NeXT) circles, which was a good thing as it allowed C++ to prosper amongst the many. I was interested in both ObjC and C++ way back when but soon found that C++, particularly when you cotton-on to templates and then the STL, really allowed me to do anything I wanted and let my imagination fly. Sorry ObjC you were just a bit too ugly and boring to fall in love with.

Re:Why not Objective C?

[Anonymous Coward]

I was interested in both ObjC and C++ way back when but soon found that C++, particularly when you cotton-on to templates and then the STL, really allowed me to do anything I wanted and let my imagination fly.

I started to smell bullshit at this point, as "way back when", C++ likely didn't have templates and the containers.

Sorry ObjC you were just a bit too ugly and boring to fall in love with.

And this just made me smile. Objective C is elegant and straighforward, while C++ is a bloated monstrosity. I guess you must like Perl as well.

Re:Why not Objective C?

[neutralstone]

1) I prefer monospace; I find it easier on the eyes.

2) Where is it written that a variable-width font is preferred?  Is there an equivalent of Strunk & White for Slashdot postings, or does it just grate on your own senses to see monospace used for plain text?  If the former, I'll reform; if only the latter then I would have acquiesced except that...

3) It's difficult to yield to suggestions delivered with insult.

Re:Why not Objective C?

[spitzak]

The problems I had with Objective C, which I used on the NeXT when it first came out:

1. By far the biggest is that the syntax has nothing to do with C. Decide that your C code would be better as an object? You have to rewrite every single call to change "method(object, a,b,c)" to "[object method a b c]". Go the other way? Same thing. Because of this Objective C was dead the moment C++ came out, and no amount of technical arguments either way make any difference.

2. It was blatently obvious that the initial version was slow and had significan overhead for each method call. We are talking about 20 mhz machines here, and the fact is that no matter how well it was written, there was at least one function call more than any normal C code would do (a call to the dispatcher code). This basically meant that nobody in their right mind would use Objective C for anything other than the GUI, which only amplified the problems with the syntax differences mentioned above. The first version also looked up the methods very slowly, especially if they were not implemented by the final class, this was addressed later by making a single whole-world hash table rather than one per class (though this required fixing the linker, I think?)

3. The first versions (every version I used) did not produce an error until runtime if you mistyped a method name. This was, I believe, fixed when they fixed the hashing mechanism. However this did not inspire much confidence in the quality of the compiler.

Re:Why not Objective C?

[powerlord]

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:Why not Objective C?

[nuzak]

> 1) I prefer monospace; I find it easier on the eyes.

Then change your damn default font and stop forcing it on the rest of us.

Re:Why not Objective C?

[Valdrax]

I think Sun is in a position similar to Microsoft, though I don't know what their weak points are. (All I know is that, due to pressure from Boost-using customers, recent versions of their compiler should handle it better.)

Oh, yeah. We in fact upgraded our compiler from Sun Studio 8 to 10 specifically to be able to get Boost's singleton implementation and SmartPointers.

Well, to each his own; but just remember that the existence of Obj-C++ means the woojiness is always within your reach, should the desire for woojiness* suddenly overtake you -- or should you hit a problem that would be most elegantly solved with a design that uses a function template.

Out of curiosity, where would you find use for a function template in a language that supports overloadable functions and a generic base class? I can't really think of one, but I'm still at the head-hurty / "Wow, that's both cool and horrible" stage of C++ learning when looking at Boost and STL implementations.

Re:Why not Objective C?

[Elazro]

I can think of one good reason to continue using templates in objective c++, despite the fact that they are ugly as all get out. Namely, they can be much faster than any form of dynamic dispatch. Now in most applications, that's just not going to matter that much, but in fields like scientific visualization, it can matter a lot.

Here is a real-life example: to do a direct volume render of a volume dataset, one can cast a ray into the data, sample at many (perhaps thousands) of points along the ray, and then composite the samples together to determine a pixel value. For a large dataset, rendering at HD resolution can require many billions of compositing operations.

Now, the code to cast the rays and determine the sampling points is pretty much set (for non-adaptive renderers), however it is likely that one may wish to composite the samples using different algorithms - absorption only (like x-ray), emissive only, absorptive/emissive (most realistic), or maximum-intensity projection (locate hotspots easily). Thus, one would like to be able to reuse the same raycasting and sampling code, but just vary the compositing algorithm. These algorithms are usually very simple (a handful of adds and multiplies), and so the overhead of dynamic dispatch is actually significant. By using a templated Raycast function, I can plug in different compositors and not only will there be no need for dynamic dispatch, but the code will be inlined by any decent compiler, getting rid of any branch instructions at all. This also allows further optimization (common subexpression elimination, for instance). I have not checked to see what the speedup is for this particular renderer (though I am curious now), but in similar situations in the past, I have seen about an order of magnitude difference in speed. (And that is using C++'s virtual functions, which are pretty low overhead. Not sure how they compare to ObjC's dynamic dispatch).

Again, most applications don't need this kind of speed. Even in scientific computing, there is plenty of room for dynamic dispatch, which can reduce code bloat and (at least to my eye) looks cleaner. But templates can be very valuable when performance matters.

Another example is the Blitz array library (www.oonumerics.org/blitz). One problem with naive implementations of array classes is that they can cause an inordinate amount of temporary array objects to be formed, so that an expression like:
A = B*(x^2) + C*x +D
where A,B,C and D are large arrays of the same size, causes at least three temporary arrays to be created, only to be deleted once the
expression has been computed. Blitz uses a method called 'expression templates' to completely eliminate any temporaries, providing significant speedup .

Hope this answers your question.

-matt

Re:Why not Objective C?

[Haeleth]

Is there an equivalent of Strunk & White for Slashdot postings, or does it just grate on your own senses to see monospace used for plain text? If the former, I'll reform

God, I hope not. Strunk & White is a ridiculous manual filled with nonsensical proscriptions that no good author in the history of the English language has ever obeyed. (In fact, if you read Language Log, you'll know that even Strunk and White themselves routinely neglected to follow their own advice.)

Strunk & White: Just Say No.

Re:Why not Objective C?

[FredFnord]

I find that reading your comment gives me eye strain, and digesting the content gives me a serious headache.

Might I suggest that finding the controls for default font on your browser and setting them to a monospace font would not force everyone else to read in a style that, let's face it, they would already be reading in if they found it more readable. Because, let's face it, they probably know how to change the default font on their browsers.

-fred

Xcode 3.0 isn't released yet

[mbessey]

Only folks attending WWDC have the XCode 3.0 pre-release. They're all covered by a Non-Disclosure Agreement, so they can't (legally) say anything about it. Some information will doubtless leak out, but you won't see anything like a full review of it until it ships (presumably with Leopard).

There's a few additional details and a screenshot up on Apple's site:
http://www.apple.com/macosx/leopard/xcode.html

-Mark

Re:Xcode 3.0 isn't released yet

[Anonymous Coward]

Thanks.

Uh... Great! Just... great...

[__aaclcg7560]

Does this mean I need buy all new $50 USD books to understand this new technology?

Re:Uh... Great! Just... great...

[node 3]

Does this mean I need buy all new $50 USD books to understand this new technology?

What makes you think you'd need to?

If you really did buy, read, and understand those "$50 USD books" (which is doubtful, given your post), you can write programs exactly the same as you do now. If you want to take advantage of garbage collection, you can do so at your own pace, and the included documentation and examples will be more than enough to learn from.

Re:Uh... Great! Just... great...

[oc255]

When I surfed to slashdot, I thought "let's see what's going on in the world" not "let's read another comment system where people insult each other".

Re:Uh... Great! Just... great...

[node 3]

Did you reply to the wrong post? Because there's not a single insult in my post.

Re:Uh... Great! Just... great...

[jericho4.0]

"and understand those "$50 USD books" (which is doubtful, given your post)"

Re:Uh... Great! Just... great...

[node 3]

He asked a question that someone who "bought, read, and understood" (you left off the first two) would not ask. It's not an insult to point that out. I didn't call him any names (idiot, moron, etc), and didn't imply that he is too stupid to understand the answer. I just don't think he's done all three of those things I listed.

I think he started down that road, and don't know where he stopped, but I don't believe he has made his way through to the end yet. I think his question was sardonic and based on unfounded cynicism. That's hardly the stuff of insults.

Re:Uh... Great! Just... great...

[__aaclcg7560]

You weren't insulting. If anything, you made some pretty broad assumptions that could appear insulting.

I actually have a conspiracy theory that new technologies (or even old technologies renamed like Ajax) are introduced all the time to sell $50 USD books that just rehash the same old materal. For example, the Core Java books were first published in 2001 are now in their seventh edition. Mac books are not immune to this either since each new edition corresponds to a OS X release. I'm somewhat hesitant to buy another door stopper unless I really need the book.

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

[Anonymous Coward]

That's my main computer you insensitive clod!

Bring back the good old days!

[argent]

Bring back the good old days, when you could write code like this and MEAN it!

inter lda i
      phi w
      lda i
      plo w
      lda w
      phi p
      lda w
      plo p
      sep p
      br inter

Or if you're a quiche eater...

inter mov (i)+,w
      jmp @(w)+

Yay! More Bloated Crappy Code

[Anonymous Coward]

Yay, another tool which encourages people to create bloated, flaky code.

-I don't *need* to care about memory, everyone has 1GB anyway

-I don't *need* to perform analysis on the algorithm, the garbage collector will take care of it *for me*.

-I don't *need* to do performance analysis of my code, since the randomness of the garbage collection algo will make any results totally meaningless anyway.

This is why there are still classical OO languages, ala C++, which are for real programmers and REAL software engineers to use. Let the code monkeys deal with Java and the like.

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:Yay! More Bloated Crappy Code

[Anonymous Coward]

C++ is not a classic OO. Objective-C is actually based on a classic OO language called smalltalk.

Re:Yay! More Bloated Crappy Code

[Trillan]

Hmm. Well, if our visual library leaks there's nothing I can do about it. But I know for a fact that our business logic doesn't leak. It was fairly easy to prove.

(I used to be able to prove the interface didn't leak either, but the company who produced the tool I used for that has disappeared.)

Re:Yay! More Bloated Crappy Code

[xouumalperxe]

I'd hardly call perl or python languages for code monkeys, yet they both include GC. Personally, I rather like ObjC from what little I tried it, and can tell you that I consider this a welcome addition. Because you know what? I'm a computer engineering student with a very maths-heavy background. I want to worry about analyzing the algorithm and making sure the algorithm itself it optimal. Having to keep track of memory just gets in the way of that. Then, once I have the algorithm nailed properly, it MIGHT be interesting/useful to manage memory manually. But that's not really my primary concern.

Re:Yay! More Bloated Crappy Code

[Anonymous Coward]

Anyone who seriously analyzes algorithms, ALWAYS takes the memory requirements of an algorithm into the equation. (it's always a time/space trade-off).

The problem I have with many texts in this area, is that too much emphasis is placed on the simple Big-O notation model used for algorithm analysis.

I will admit, I am somewhat biased, I design embedded, mission critical systems. We don't have a lot of RAM, or a lot of speed. So we have to do our analysis to a much deeper level. Our stuff just HAS TO WORK. GC adds an unacceptable uncertainty to any performance calculations.

Thats why in the embedded industry, experience with a REAL programming language, where one has access to the bare-metal, is the only experience that matters.

VM's are great for student programmers, or anyone programming for a bloated OS/Machine combo, but when all you have is an 8051/Z80/681x/AVR Microprocessor/Microcontroller, With memory measure in Kb, and processing speed in Mhz, nor Ghz all the java in the world doesn't matter.

Re:Yay! More Bloated Crappy Code

[sapporo]

classical OO languages, ala C++

If I had any moderator points, I'd mod you up as funny.

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)

--
Carnage Blender : Meet interesting people. Kill them.

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:Your knowledge of GC is 10 years out of date

[CoughDropAddict]

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

Greater throughput at the expense of latency. GC stops the world.

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

I would like to offer you a bank account with 50% interest amortized over 500 years. I regret that you will not receive your first interest payment until the 500 years are up.

The point is that amortized performance gives you no control over when you're going to take the hit. That's OK if you only care about throughput.

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

[DataPath]

Unfortunately for you and your theories, for any major library, toolkit, driver, or anything else necessary to make an operating system remotely useful, you need low latencies, good single-point i/o, determinism. You'll never get that in garbage-collected code.

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

[Anonymous Coward]

Actually, there are GC techniques that do not involve
"stopping the world" ... It's kind of unfortunate
that no one seems to have heard about generational
garbage collectors; they've been around for a while...

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

[CoughDropAddict]

Generational collection stops the world. Perhaps you are thinking of concurrent collectors?

I'll get more excited about concurrent collectors when they find their way into the mainstream and prove themselves.

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

[feijai]

The most adverse effect of Java-like GCing is not the allocation method, it's the amount of allocations

A modern Java virtual machine uses a compacting GC. This allows it to perform the following super-duper, evil, highly intensive allocation procedure for an object of N bytes:

1. Increment the heap pointer by N.
2. Bzero those N bytes (if necessary).
3. Return the old heap pointer.

In what way exactly is this more expensive than malloc? That's right, it's far less expensive than malloc. It's just as expensive as stack allocation in fact.

Where GC falls down is in the (slight) cost of deallocation of those tiny, short-lived objects and in not being able to take advantage of cache coherency for short-lived objects well -- though it's great for long-lived objects and caches. But virtual machine techniques are improving every day. Soon we'll have object analysis in most VMs to determine if objects can be stack allocated or not.

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

[feijai]

Let me clarify this: number of allocations is fairly immaterial since allocation cost is the same as just doing a stack allocation. It's the number of deallocations and moves that gets ya.

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

[Anonymous Coward]

Let me clarify something for you.

ALU operations, and even (though to a lesser extent) jumps are no longer a big deal to a modern processor.

Cache misses are the big deal. If you're continually allocating new, cache cold memory for new objects, rather
than reusing the hot memory as it logically becomes free (and instead wait for it to cool down as it goes
through a GC cycle), then you're increasing cache misses. This is a bad thing.

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

[Anonymous Coward]

GC stops the world.

How long, though? Long enough to matter? I sumbit that there are very few applications where the increased latency of GC actually matters.

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

[feijai]

Cache misses are the big deal. If you're continually allocating new, cache cold memory for new objects, rather than reusing the hot memory as it logically becomes free (and instead wait for it to cool down as it goes through a GC cycle), then you're increasing cache misses. This is a bad thing.

It is indeed: but it's not nearly as bad as people claim. Because machines don't dump items into cache by the byte. They dump them by the block. And GC allocations are all done in the same block. Additionally, good GC systems do allocations of new objects in incubators where the cache is hot. Thanks for playing.

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

[sribe]

Greater throughput at the expense of latency. GC stops the world.

Not necessarily. There are implementations where the overhead is spread across each allocation, with a hard bound. Like other comments on the performance of GC, yours is also 10 years out of date. Just because the GC in your Java VM is itself a hunk of garbage that should be "collected", doesn't mean all GC is bad.

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

[CoughDropAddict]

Like other comments on the performance of GC, yours is also 10 years out of date. Just because the GC in your Java VM is itself a hunk of garbage that should be "collected", doesn't mean all GC is bad.

Talk to me again when these miraculous implementations of GC that have no flaws make it into the mainstream. It's not that hard to solve for one particular constraint. GC apologists keep saying "algorithm X has hard bounds" and "algorithm Y doesn't stop the world" and "algorithm Z is faster than malloc/free!" I'm not interested in solutions to one isolated problem. I want to see one single GC implementation for a major programming language that has no major flaws. I'm not going to spend my life passing different flags to my VM that trade one major flaw for another.

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

[Anonymous Coward]

It is indeed: but it's not nearly as bad as people claim. Because machines don't dump items into cache by the byte. They dump them by the block.

Err yes, caching is done on a cacheline granularity. I fail to see how you think that means the problem "isn't as bad
as people claim".

And GC allocations are all done in the same block.

Same cacheline. Right. So if you have a 32 byte cacheline and you allocate a 64 byte object, what happens? In fact,
what are you even talking about? What is a GC allocation and how can you do all your "GC allocations" in a single
cacheline?

Additionally, good GC systems do allocations of new objects in incubators where the cache is hot.

Sorry, you fundamentally cannot reuse the memory until it has been garbage collected. By definition. I'm sure good
GC systems do all they can to try to mitigate this problem, but it doesn't mean it isn't a problem and it is
by definition worse than in an explicit memory management system.

Thanks for playing.

Fuck off you patronizing homo. How about you learn something *before* "playing".

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

[td]

Greater throughput at the expense of latency. GC stops the world.

Not if done correctly. See, for example, "Real-Time Non-Copying Garbage Collection", by Paul R Wilson and Mark S Johnstone.

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

[CoughDropAddict]

See my reply to a similar comment. Still, that paper looks promising and I will give it a closer read.

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

[CoughDropAddict]

Hear, hear!

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

[Anonymous Coward]

I'm not going to spend my life passing different flags to my VM that trade one major flaw for another.

No, you're going to spend your life hunting down trivial memory leaks. Have fun.

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

[feijai]

How about you learn something *before* "playing".

Mmm... Threats from an AC. Having actually written a VM, I think I'm somewhat qualified to comment here.

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

[Amouth]

and your point is?????

the "rewind" function - is it for real?

[epaulson]

The marketing-fluff webpage linked to talks about stepping back during a debugging session - is this for Objective-C only or is it available for every language? Now that is a compelling reason to upgrade

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:NOOOOOOO #@$#$@

[bit01]

Garbage collection can also lead to unpredictability.

I detest it when a GUI pauses for no good reason, just because the runtime library decided to do a garbage collection at that point. It breaks some of the cardinal rules of good interface design; predictability and responsiveness.

---

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

Re:NOOOOOOO #@$#$@

[pikine]

Objective C has one of the most elegant reference counting implementations on the planet.

There is no need to panic. You can support both reference counting and garbage collection in one run-time, provided the objects are in separate heaps. Whenever there is a reference from reference counting heap to the garbage collected heap, you simply tell the GC that there is a "root" reference inside a reference counting object. The other direction is probably even easier. A conservative GC can discern whether a reference is managed by the GC or not. Otherwise, we can foil a GC's attempt at traversing outside of the GC heap by marking a reference as an integer or by wrapping it in a special binary object that GC does not traverse.

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.

Ever heard of suggestions that global variables are harmful? This is even truer for GC memory management. These globals have roots that persist throughout the lifetime of a program. For this reason, Java programmers seem to suffer more GC problems than a functional language programmer. In fact, the only place you need to look at, in the case of a "GC memory leak," is your global variables.

Unless a GC implementation is flawed, GC does not produce memory leaks. The leaks you are talking about are still technically used by the program but the programmer is not aware of it.

Debugging reference counting is just as much work as debugging malloc/free. In both cases, you need a map tracking the creation, duplication, and consumption of references.

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.

If by efficient programming you also take into account run-time overhead, some implementation of GC is more efficient than some implementation of malloc/free. For example, a copying GC only maintains a "heap top" pointer, and any new object is allocated from heap top only. In contrast to malloc/free implemented as linked list traversal, GC takes O(1) time to allocate, and O(n) time when it runs out of memory; malloc/free always takes O(n) time.

I'm sure other people will fill in the details here if they want to. The point here is that you cannot compare blanket GC with blanket reference counting or malloc/free.

If by efficient programming you mean the time it takes to write code, I believe GC is the winner here, since you forget you're using memory altogether.

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.

Re:NOOOOOOO #@$#$@

[shobadobs]

In contrast to malloc/free implemented as linked list traversal, GC takes O(1) time to allocate, and O(n) time when it runs out of memory; malloc/free always takes O(n) time.

First of all, even dumb mallocs do not 'always' take O(n) time.
And comparing GC to a craptardic mallocation strategy is like comparing any sorting algorithm against bubble sort.

Re:NOOOOOOO #@$#$@

[bar-agent]

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.

Re:NOOOOOOO #@$#$@

[pestilence669]

Globals aren't the only place that memory leaks occur in Java. Bad Java code can "leak" memory just as badly as C++. Poorly formed closures can definitely cause your memory to waste away. Dealing with garbage collected languages isn't always as straight forward as proponents often suggest.

Re:NOOOOOOO #@$#$@

[Abcd1234]

Well, first off, Java doesn't have closures. It has anonymous inner classes which maintain a reference to their containing class, and can access it's member variables, but that's definitely not a closure. Though, I sure wish it did... I tend to program in a functional style, and I've lamented the lack of lexical closures in Java on a number of occasions.

Secondly, I challenge you to describe a situation in which you can leak memory in Java despite throwing away the reference to the object in question. I'm willing to bet you can't.

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 #@$#$@

[foxed]

Cyclical relationships, which shouldn't exist in decent code

If a parent object refers to a child, and a child to a parent, that's a cycle.

For example, every GUI library I've ever seen has a container with a collection of widgets. The widget object has a reference back to its parent container.

The one-way, non-cyclical pointer has limitations too. One of the key insights of relational databases is that every relationship is bidirectional. If the relationship exists, often the time will come when you want to find the parent related object when what you have is the child one. With unidirectional pointers, you have to rewrite your application to achieve it.

Re:NOOOOOOO #@$#$@

[Spikeles]

a situation in which you can leak memory in Java despite throwing away the reference to the object in question

The problem with Java is that once you allocate an object and then deallocate ( eg. assign null to it ) you are not gaurenteeing that it will be cleaned up. At least with manual memory managment, once i call free() (or whatever) the program will crash on the next access to that area and tell me when i've not cleaned up code. I've noticed alot of times in GUI code where i will allocate a window and then attempt to clean it up(eg dispose()), but so many other parts of the windowing code in Java will keep a reference to it(FocusManager for example) that it will stay in memory even after i am no longer actively using it.

Also, be sure to look up weak and strong memory references in regards to Java. http://www-128.ibm.com/developerworks/java/library /j-jtp11225/

Too many people use Java the wrong way and assume that the system will take care of things and clean it up, after programming in Java for 4 years and after extensive use of debuggers/profilers/memory checkers i can say that it's not the case, it certainly does a good job, but the way they market Java to new programmers is deceptive at best. It certainly does some neat things but more users of Java should be taught about the young memory spaces and eden space, how and why they work and how to use them effeciently, you just can't expect to create thousands of objects and expect the GC to do everything for you. http://www-128.ibm.com/developerworks/java/library /j-perf08273.html

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?

Re:NOOOOOOO #@$#$@

[bnenning]

Objective C has one of the most elegant reference counting implementations on the planet.

It's clever and it works well most of the time, but I wouldn't call it "elegant". Witness the frequent debates on how to properly write accessor methods.

Garbage collection is a step backward, IMO, but every language seems to be moving in this direction.

And with good reason. As Paul Graham has noted, eventually higher levels of abstraction always win.

I really do believe that resource awareness is crucial to efficient programming.

Most of the time, efficiency doesn't really matter (specifically, the constant in the big-O doesn't matter, within reason). I don't care if my bittorrent client uses 4% CPU time instead of 2%. I do care if it has a memory management bug exposes my system to a remote exploit.

Garbage collection encourages lazy programming habits

I'm sure 40 years ago assembly guys were saying the same thing about FORTRAN. But maybe it's possible that not having to worry about deallocating every dinky little string frees up time to focus on the real bottlenecks.

Re:NOOOOOOO #@$#$@

[porkchop_d_clown]

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.

Right, right. And training wheels make it easier to ride a bike. Doesn't mean you should leave them on, though.

Re:NOOOOOOO #@$#$@

[logicnazi]

This is kinda a incoherent justification for GC. Supposedly the reason we need GC in the first place is so programmers without enough ability/experience/care don't screw up and forget to deallocate something. If using GC requires special knowledge training and optimization of GC then the argument for GC in the first place now doesn't go through.

Most programers at least know HOW to go about freeing memory and finding memory leaks even if they aren't good at it. If using GC required this special knowledge it would be even worse.

Still I agree that GC is the right way to go (so long as it can be turned off both globally and locally) because a good GC implementation will just work right for the vast vast majority of apps even if you have no clue what you are doing.

However, it's wrong to critisize someone for not being a GC expert as the very point of GC is to make programming work with less expertise/hassle. If the GC doesn't JUST WORK for the vast majority of apps it is the fault of the people who did the GC not the poor guy who has to select a different GC strategy or optimize his code around the GC.

Re:NOOOOOOO #@$#$@

[logicnazi]

Uhh I don't think your claim about malloc/free and GC speed makes sense.

By definition O(n) means that the time required grows linearly in the limit. Saying that GC grows like O(1) when it hasn't run out of availible memory and O(n) when it has is equivalent to saying that GC time grows like O(n).

I presume you are trying to say that while both GC and malloc grow like O(n) GC has better performance for 'low' amounts of memory. This may be true but I can't figure out any way to interpret your actual statement to make it true but perhaps I am missing something.

Re:NOOOOOOO #@$#$@

[porkchop_d_clown]

Secondly, I challenge you to describe a situation in which you can leak memory in Java despite throwing away the reference to the object in question. I'm willing to bet you can't.

I can. Back when 1.2 was the sweet hotness I was asked to write a desktop app to interface with some middle ware. It had a habit of expanding to consume the entire available heap and then chugging very slowly to GC all at once. The fact that I couldn't force it to garbage collect more frequently eventually made us abandon the project. It simply wasn't usable.

Re:NOOOOOOO #@$#$@

[ysachlandil]

>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
http://www.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf
http://en.wikipedia.org/wiki/Reference_counting

--Blerik

Re:NOOOOOOO #@$#$@

[Abcd1234]

Do you even know what a memory leak is? What you've described is a poorly performing GC, not a memory leak.

Re:NOOOOOOO #@$#$@

[Abcd1234]

The problem with Java is that once you allocate an object and then deallocate ( eg. assign null to it ) you are not gaurenteeing that it will be cleaned up.

As long as the object does not have a reference held on it, it will eventually be cleaned up. The GC may wait, but the memory isn't leaked, in that it will be reclaimed at some point (at worst, when the memory manager has run out of heap).

but so many other parts of the windowing code in Java will keep a reference to it(FocusManager for example) that it will stay in memory even after i am no longer actively using it.

Which is exactly what I said! There are longer lived references to the object kicking around, and thus it isn't getting gc'd. It's still not a memory leak.

Meanwhile, I wonder, why on earth would windowing code hold references to your program data? That sounds like a serious MVC breakage to me.

[... snip article links ...]

And, surprise surprise, every example in those articles are places where the programmer has squirreled away a reference to an object in a global (or, at least, longer scoped) variable, and not null'd it, thus proving the original point.

Now, I agree, a programmer must develop with the GC in mind. And, yes, idiot programmers need to be reminded that objects referenced in long-lived variables can't be garbage collected. But that doesn't change the fact that memory leaks as found in C and C++ simply aren't possible in Java.

Re:NOOOOOOO #@$#$@

[Jonboy X]

Ever heard of suggestions that global variables are harmful? This is even truer for GC memory management. These globals have roots that persist throughout the lifetime of a program. For this reason, Java programmers seem to suffer more GC problems than a functional language programmer. In fact, the only place you need to look at, in the case of a "GC memory leak," is your global variables.

It kind of depends how you define the term "global" for variables. The strict definition is a static (or "class") variable, but that's not the only place you need to look to see where your app might be keeping the GC from freeing unused objects.

If you're coding a J2EE web app, application context is a common dumping ground for stuff you want to have access to from lots of places in the code. It's all too easy to bind something there and forget to unbind it later. If you're tempted to attempt cleanup on user logout, remember that the user may not get around to it and instead just let their session expire.

If it's a long-running non-J2EE app you're working with, pretty much any place could be a hiding spot for memory clutter. Think app-level config maps. Think caches. Then again, if it's a short-running app, memory leaks aren't usually the focal point of your performance optimizations anyway.

Re:NOOOOOOO #@$#$@

[mrxak]

Man, selection sort is sooo fast.

Re:NOOOOOOO #@$#$@

[StrawberryFrog]

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.

Speak for yourself. It saves me effort.

Re:NOOOOOOO #@$#$@

[m874t232]

This is kinda a incoherent justification for GC. Supposedly the reason we need GC in the first place is so programmers without enough ability/experience/care don't screw up and forget to deallocate something. If using GC requires special knowledge training and optimization of GC then the argument for GC in the first place now doesn't go through

Without GC, good programmers produce fast and correct code, while bad programmers produce craches both in their own and other people's code.

With GC, good programmers still produce fast and correct code--and take about the same amount of time to do it, while bad programmers merely produce inefficient software and have bugs point right back to their own code.

However, it's wrong to critisize someone for not being a GC expert as the very point of GC is to make programming work with less expertise/hassle.

No, that's not the point. The point of GC is to protect people like me from people like you, not to make anyone's life easier (it may do that, too, but that's merely a side effect).

If the GC doesn't JUST WORK for the vast majority of apps it is the fault of the people who did the GC not the poor guy who has to select a different GC strategy or optimize his code around the GC.

The GC "just works" for the vast majority of apps, but if you do something stupid, then you'll get poor performance. That's a lot better than with a manual storage allocator where, if you do something stupid, your program crashes.

it is the fault of the people who did the GC not the poor guy who has to select a different GC strategy or optimize his code around the GC.

"Selecting a GC strategy" isn't hard: if your GC supports it, you simply tell it "I want real-time/interactive/batch performance". What you need is a memory management strategy, and those are pretty much the same with or without GC: avoid generating garbage and reuse objects.

Re:NOOOOOOO #@$#$@

[Haeleth]

First of all, even dumb mallocs do not 'always' take O(n) time.

Please go away and learn some computer science before you try to sound smart. As the GP correctly said, malloc() implemented as a linked list traversal will always take O(n) time by definition.

Re:NOOOOOOO #@$#$@

[Haeleth]

Cyclical relationships, which shouldn't exist in decent code

Man, I wish I lived in a nice simple world like yours, where you could just define "decent code" to exclude whole critical areas of computer science.

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.

You do realise, I take it, that people said the same thing about compilers? FORTRAN just encourages lazy programming habits! No good can ever come of letting computers convert your pseudocode into machine code! It will never be as efficient as machine code constructed by a skilled programmer! Compilers are just a crutch for lazy mathematicians - it would be a disaster for computing if they were to take over from real programming!

And as for object orientation, well...

Garbage Collection and Apple

[beswicks]

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

Re:Garbage Collection and Apple

[idlake]

I have GREAT fears about people not leaning to clean up after themselves.

It's a fact that people don't clean up properly after themselves. Without garbage collection, when they don't, software crashes unpredictably. With garbage collection, at worst, it runs more slowly.

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.

Well, and once people start programming embedded systems, that's a good point to spend a time to teach that. Teaching manual storage management earlier is premature. Furthermore, if your students had been properly trained in memory management using a garbage collector, they'd learn manual storage management quickly, since many of the techniques are the same.

(Incidentally, there is no reason why a 64k Java couldn't provide efficient garbage collection.)

Re:Garbage Collection and Apple

[beswicks]

...your students...

Not my students. I'm one of them... but they hunt in packs. If you have the only working robot they decend on you like jackals...

As for when to teach people how to manage memory, I think that in a University it should be done as soon as possible, if education worked by "leave it till they need it" then I wouldn't have learned half the exciting stuff I know now... leaving learning often just results in missing out.

PS. I'm pretty sure that the Java engine could have had garbage collection, but not much you can do when it doesn't. If you have a lazy ass vendor who provides the only solution then you just have to go with it... Microsoft build a bussiness on it :D

Apple innovates...

[cortana]

-lgc

I kid, I kid! :)

cpu/human trade off

[fermion]

It seems to me that everything in programing, or really any process type thing, is managing resources. Any project has a certain amount of human power, a certain amount of time, and a certain amount of mechanical or electrical power. And while a competent programmer should be able to manage memory, when we have all these tight deadlines and all these cheap cycles, why take the time or pay the extra money? In the end, except for application where there is no excess power, it makes a lot of sense to utilize the technological innovation of garbage collection. I myself think not managing my own memory is boring, but I do realize that most people simply do not want to deal with it.

I think we really have to accept and embrace real innovations to productivity. Things such as compilers, optimizers, high level interfaces, has brought us great benefit. If we look at it in real terms the advancements are awesome. In the Mythical Man Month I seem to recall that coding speeds were cited as dozens of lines per day. Compare that to what we can do now. The down side is that we perhaps waste resources, and in many ways the computer industry is crushing itself under the weight of wasted resources, but that is merely another management issue.

Re:cpu/human trade off

[Detritus]

And while a competent programmer should be able to manage memory, when we have all these tight deadlines and all these cheap cycles, why take the time or pay the extra money?

Determinism.

Oh, come on, mods.

[Anonymous Coward]

I loathe /. cliches as much as the next person, but "Garbage Collecting Overlords" definitely deserves a point or two.

Specifics please?

[Jerk City Troll]

I have been a Java developer for eight years. What problems have plagued Java garbage collection?

Re:Specifics please?

[botik32]

I do not know what exactly the problem is under the hood, but every desktop java app I used, tries to hog all my RAM regardless of how much I got, or what other programs are out there. That's why my (Linux) desktop is java-free. And considering the huge amount of open source code written in C/C++, I do not miss java apps one bit.

If I could point the reason, I would probably say lazy collection is the problem. On the other hand, I would not want my CPU be busy with collection most of the time. So, there.

Re:Specifics please?

[kingkade]

I don't think you understand garbage collection, let alone Java, well enough to make a cogent argument.

Let's start with the admitted fact that the *basic* allocator in the Sun JVM requires on the order of twice the allocated heap space. But the idea is that the unused half will be paged out by the OS even though the perceived memory usage doesn't reflect that. In addition, the same reasoning is applied to the often cited "problem" that the Sun JVM heap never sshrinks.

Not to mention that you can add on top of this the fact that allocation in Java has almost no overhead because of this scheme.

In short: stop waving your "That's why my desktop (linux, woooo) is Java-free! Yay!" flag, if you don't know the first thing. Which nobody would really mind if you came up with an actual technical reason besides the fallacy of percieved memory consumption.

Re:Specifics please?

[botik32]

Thank you for the ad hominem attack. And next time my computer slows to a complete crawl, I will remember that this is just a "perceived" problem. I take it your precious eclipse IDE runs on 64MB of RAM just perfectly too.

What do I know, maybe the problem with the Java GC is not technical. It could be lazy incompetent programmers churning out crappy code that requires a supercomputer to run :)

Re:Specifics please?

[squiggleslash]

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.

Re:Specifics please?

[Jerk City Troll]

It is unfortunate the grandparent post is full of personal remarks, but the points are valid nonetheless. Your comment about Eclipse memory consumption is a bit odd. Just because top says “64M” does not mean that you have that much less physical memory available. Read this: http://en.wikipedia.org/wiki/Virtual_memory Also, Eclipse is a huge application with a lot of useful features built on a very extensible platform. I would recommend getting aquainted with it before complaining about its memory footprint. As for Java computers requiring a “supercomputer” to run: I always wonder how people get hooked on this. Do you have an example of a slow Java application? Have you ever used a slow Java application? Do you realize that there plenty of Java-based web applications out there serving millions of transactions every day? Do you realize there is a very good chance your cellphone, a remarkably barebones and minimal device, uses Java? People complain that Java is slow or that Java developers are incompetent but I have yet to receive any evidence. Meanwhile, there is plenty of material that shows Java is fast. Would you care to back-up any of your claims?

Re:Specifics please?

[Jerk City Troll]

Your comments are useful and I agree for the most part. However, I disagree with your assertions that Java proponents claim rapid application development. (And really, I am just nitpicking for argument sake.) Java development has a lot of programmer overhead in that there are many ways to solve the problem and nobody has decided which are the best. With that, you end up having to experiment with a variety of frameworks at every tier of your application. JSF or Tapestry? Hibernate, JDO, or Toplink? EJB or Spring? Swing or SWT? W3C DOM or dom4j? Saxon or Xalan? Ant or Maven? Jakarta Commons. JBoss, WebSphere, WebLogic, Tomcat, JRun. The mind boggles when trying to grasp all the tools and libraries you have available when building anything in Java, and while all this choice is good in some respects, it is nice to have some authority say “this is how you do it.” Java lacks that (at the moment) and so a lot of suboptimal (perhaps not necessarily bad) decisions get made. Another point is Java is really geared towards strict development practices and principles. Every application should be MVC and all the tools encourage it. Every application should have multiple tiers. Keeping distributed computing in mind is a good idea. None of this really lends to building applications fast, but certainly for reliability and extensibility. Of couse, these opinions may be due to the industry in which I do most of my work (and you can probably guess based on most of the projects I mentioned). :)

Re:Specifics please?

[botik32]

Please, stop talking to me like I am some kind of moron :). Maybe I look like one, *shrug*.

I haven't tried a desktop java app that wasn't slow. What comes to mind now: azureus and Oracle developer. Having both Azureus and mozilla open in my usual browsing mode (lots of pics) loads up my system to a crawl. Why? Azureus takes 400mb of RAM and firefox uses the rest. Same thing with Mozilla + Oracle Developer. I cannot even imagine running the three of them together. (I have 512mb RAM on my computer).

I know what a java server app is. It is fast. I do not say it is not, on a dual xeon with 1Mb of CPU cache and 2Gb of RAM. This is not the point. I was talking about desktop apps on desktop computers.

I know about RSS and paged-out memory, I assure you this is not the case. Gkrellm monitor shows me RSS usage so I am sure of my numbers. As a C developer I probably know more about RSS than you.

The only reason I do not like Java on my desktop is memory footprint. That's all. I understand many developers are just lazy and don't give a fuck about RAM, but Java developers are the worst, and their attitude 'programmer time is expensive - hardware is cheap' just does not fly. And the GC is encouraging them to continue to ignore memory issues.

Now, you can continue to ignore what I am saying, but most java apps I've seen are extremely memory hungry and I would not touch them with a ten foot pole.

As to the guy who knows so much about garbage collection, can you tell me this:
Since all your Java objects are dynamically allocated, the GC will eventually run into the problem of memory fragmentation, and will have to defragment memory. Why do you think I have the luxury of a free CPU to copy the objects around?

below is a reference on gc techniques wrt: memory fragmentation. One of them basically keeps HALF of available RAM UNUSED. HALF!!!


Compacting collectors
Garbage collectors of JVMs will likely have a strategy to combat heap fragmentation. Two strategies commonly used by mark and sweep collectors are compacting and copying. Both of these approaches move objects on the fly to reduce heap fragmentation. Compacting collectors slide live objects over free memory space toward one end of the heap. In the process the other end of the heap becomes one large contiguous free area. All references to the moved objects are updated to refer to the new location.

Updating references to moved objects is sometimes made simpler by adding a level of indirection to object references. Instead of referring directly to objects on the heap, object references refer to a table of object handles. The object handles refer to the actual objects on the heap. When an object is moved, only the object handle must be updated with the new location. All references to the object in the executing program will still refer to the updated handle, which did not move. While this approach simplifies the job of heap defragmentation, it adds a performance overhead to every object access.

Copying collectors
Copying garbage collectors move all live objects to a new area. As the objects are moved to the new area, they are placed side by side, thus eliminating any free spaces that may have separated them in the old area. The old area is then known to be all free space. The advantage of this approach is that objects can be copied as they are discovered by the traversal from the root nodes. There are no separate mark and sweep phases. Objects are copied to the new area on the fly, and forwarding pointers are left in their old locations. The forwarding pointers allow objects encountered later in the traversal that refer to already copied objects to know the new location of the copied objects.

A common copying collector is called stop and copy. In this scheme, the heap is divided into two regions. Only one of the two regions is used at any time. Objects are allocated from one of the regions until all the space in that region has been exhausted. At that point program execution

Re:Specifics please?

[bnenning]

And some programmers think that they are good enough to avoid those mistakes. But, you know what? I seriously doubt that.

Exactly. It's like how everybody thinks they're an above-average driver.

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

Unfortunately no; ObjC is just C with some syntax changes to support OOP. Like C and C++, you can still stomp all over memory and dereference null and enjoy buffer overruns. The Cocoa class libraries help some (e.g. the collections classes do bounds-checking), but it would be good to have a "managed code" option, such as officially supported Python and/or Ruby bindings for Cocoa.

Re:Specifics please?

[Anonymous Coward]

Azureus slows the system, but is that because it's written in Java or because it does lots of I/O? Does it take a lot of memory because it's written in Java or because it has lots of data to keep track of?

Re:Specifics please?

[m874t232]

Well, the garbage collector that ships with Sun Java is not all that good: it has a lot of overhead and it causes perceptible delays in interactive applications.

But the real problem with garbage collection in Java is the poor language and library design, which forces applications to generate huge amounts of garbage and leads to a lot of unnecessary memory management overhead. Java, unfortunately, gives garbage collection a bad name.

Re:Specifics please?

[botik32]

My guess it is because azureus is written to be a huge memory hog. There are other torrent clients written in C/C++ and they behave well and do not starve my system of resources like azureus does.

Why this story doesn't show in RSS??

[Qwavel]

I've started to notice that there are /. stories that I miss because they don't appear in the RSS feed. What's going on?

Re:Why this story doesn't show in RSS??

[Anonymous Coward]

Slashdot limits the number of articles it keeps in the RSS feed at any one time. It's kind of like a revolving door. Some articles are revolving out of the door between when your reader hits slashdot one day and the next. I have been happily reading my RSS feeds online through a service and the service probably pings slashdot every 30 minutes or so, so I don't miss any articles even when my computer isn't hooked up to the internet for a couple of days or more.

Re:Why this story doesn't show in RSS??

[Anonymous Coward]

Typical case of unexpected Garbage Collection I think.....

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.

Re:many people miss the point of GC

[DCGregoryA]

Like any other innovation to programming languages its about decreasing the costs of the development cycle. If you asked most project managers why they want projects done in managed languages its to cut down on memory leaks. I think its rather silly to not even acknowledge that the pointer based world of C++ is more prone to memory leaks than managed systems.

There are exceptions, but not everyone who writes software is writing massive enterprise systems. For most projects that come cross my desk, whipping out C/C++ would just be an unnecessary headache, not to mention those developers cost more and the QA profiling becomes a pain in the ass. Try to bear in mind not every software development environment is a clone of every other one.

Re:many people miss the point of GC

[StrawberryFrog]

Many people think that the purpose of garbage collection is to make programming easier.

Having used both, I would say that "making programming easier" is definitely among its benefits.

But that's not the purpose of garbage collection at all.

It has only one purpose?

Memory management in a garbage collected language is at least as much effort as memory management in a language with manual storage management,

You know, it certainly doesn't feel that way. You don't need a try -finally block to deallocate local vars. You don't need to care which of several lists owns the items. You can create objects and return them in a "fire and forget" manner - no more worrying about who's responsibility it is to deallocate them. You write less lines of code, and get more done.

it requires at least as much experience to use well.

There are pitfalls and knacks to everything, but I find GC easier.

Re:many people miss the point of GC

[Anonymous Coward]

...whipping out C/C++ would just be an unnecessary headache, not to mention those developers cost more...

Yeah baby! Ka-ching! That's why I went into C, and then C++, because I wanted to be paid more than what VB and Java (and now other sandboxed languages) developers could command.

Library only GC

[SuperKendall]

It seems to me that since it is a compiler option that if a library required it, it would be compiled to do so and you could simply use it from your non-GC code directly. It's not like Objective-C is suddenly running in a VM, the compiler is adding code to effect the GC.

Re:Library only GC

[Bill Dog]

Say a library method specifies returning you an object intended to be GC'ed when you're done with it. 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.

Re:Library only GC

[Haeleth]

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. :)

Re:Library only GC

[Bill Dog]

What makes you think you know what my idea of how a GC might be implemented is?

Oh dear, where to start ?

[Space cowboy]

• 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. There's a lot of stuff you're saying as fact, that is simply wrong.

Simon

Re:Oh dear, where to start ?

[Cthefuture]

C performance is just as good as C++...

While this is true, it's very ugly to due certain things in C with the same performance as a clean C++ implementation. Generic containers for instance. Dereferencing pointers costs CPU cycles. You can do it just as fast in C but like I said, the code will be nasty.

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.

Calling via function pointer is slower due to the pointer dereference. This is exactly the difference between virtual and non-virtual methods in C++. At least in C++ you get a choice.

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.

Read what a wrote. I didn't say Objective-C was based on COM. I said it was like COM. The underlying architecture is very similar. The main difference is that Objective-C extended the C syntax whereas COM is still using plain 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.

Templates can create faster code than anything done in Objective-C. Assuming you're using the object features and not just plain C.

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 ?

I find it bizarre that you think the tiny incompatibilities between C and C++ are significant. Most of the time the changes you make to C code to get it to work in C++ are actually improvements to the code.

Re:Oh dear, where to start ?

[jafac]

yeah, all we need now is an Obj-C runtime that runs on Windows. . . /snark

Re:Oh dear, where to start ?

[Sam Ritchie]

Calling via function pointer is slower due to the pointer dereference. This is exactly the difference between virtual and non-virtual methods in C++. At least in C++ you get a choice.

Yes, at risk of getting myself flamed, I've always considered non-virtual functions a triumph of performance over common sense. At least in Objective C it's more obvious when you're violating OO principles for speed.

I didn't say Objective-C was based on COM. I said it was like COM.

How is it like COM? I'm genuinely curious about this one. Are you referring to a particular runtime implementation?

I find it bizarre that you think the tiny incompatibilities between C and C++ are significant.

They're probably not, but 'degree of C-likeness' is in the eye of the beholder. You've not presented any justification for your subjective statement that C++ is 'more like C'. At least compatibility with ANSI C is a demonstrable property.

Re:Oh dear, where to start ?

[stivi]

Yes: http://www.gnustep.org/

Re:Oh dear, where to start ?

[Space cowboy]

• While this is true, it's very ugly to due certain things in C with the same performance as a clean C++ implementation. Generic containers for instance. Dereferencing pointers costs CPU cycles. You can do it just as fast in C but like I said, the code will be nasty
  
  If you're trying to tell me that the generic containers of C++ come with zero cost, I have a bridge to sell you. At any level, you can make an abstraction or you can code to that level. The standard CS joke is that any problem in any language can be solved by introducing another layer of abstraction...
  
  Objective C gives you a clear choice - use the objective language as it was designed, or (for the tiny percentage of code which really is time-critical) code in C. You get the best of both worlds - a simple, elegant object-based language, and the pedal-to-the-metal facility of C. What's to not like ?
  
  
• Calling via function pointer is slower due to the pointer dereference. This is exactly the difference between virtual and non-virtual methods in C++. At least in C++ you get a choice
  
  I'm not convinced you're correct here... on most machines 'jsr label' and 'jsr (label)' are equivalent instructions - the speculative prefetch will have resolved (label) by the time the jsr is executed. Still, my point was that for that tiny percentage of code that is truly time-critical, you simply call a C function - no dereference is required.
  
  
• Read what a wrote. I didn't say Objective-C was based on COM. I said it was like COM. The underlying architecture is very similar. The main difference is that Objective-C extended the C syntax whereas COM is still using plain C
  
  Maybe I was unclear - I read what you wrote and I completely disagree with it. It was *not* designed at the same time, it does *not* have the same goals, it is fundamentally dissimilar, and its goals were *not* even vaguely similar. You'd have better luck comparing chalk and cheese!
  
  
• Templates can create faster code than anything done in Objective-C
  
  An interesting (and bold) statement. Ok, so I have a plugin architecture - there's a bundle of code associated with the application that may or may not have been installed by the application author. In ObjC, its a trivial (3-line) routine to validate that this anonymous code is part of the application, and should be a full peer in the class hierarchy. I'd love to see you do that with templates... ObjC's runtime-binding and introspection make it (as mentioned) trivial.
  
  
• I find it bizarre that you think the tiny incompatibilities between C and C++ are significant
  
  I think it's bizarre for you to state that a language (that is in fact less compatible with C) is more compatible with C. If you have a better metric, please explain what it is. The plain fact of the matter is that Objective C is more compatible than C++. It's as simple as that.
  
  Simon
  
  

Re:Oh dear, where to start ?

[Anonymous Coward]

I'm not convinced you're correct here... on most machines 'jsr label' and 'jsr (label)' are equivalent instructions - the speculative prefetch will have resolved (label) by the time the jsr is executed. Still, my point was that for that tiny percentage of code that is truly time-critical, you simply call a C function - no dereference is required.

No, if you use a C function, you have to push the reference arguments to the stack, push a frame onto the stack, dereference the function pointer, perform your code, and then move the return value to the return register(s). Then you need to pop the frame from the stack and clean up the registers. If you're using an older compiler and processor, you would also have run into a pipeline flush and have to refetch all the values to the registers on the function call and return.

If we're in code that is making a virtual function call too expensive (you know, the 20 lines in your 7 million line project), then calling a function is too expensive.

The way around this is to use a #define to inline the code and save all the stack frame and argument pushing and popping.

But, everyone in this thread knew this if they realy cared that much about performance. Otherwise they are just a dipsh!t with only enough of a clue to be harmful.

Re:Oh dear, where to start ?

[m874t232]

ObjC has introspection, dynamic binding, (now) optional garbage collection, (always) a very easy retain-count allocation system, really easy-to-learn constructs

That's all true, but there are huge practical problems: it also lacks a language standard, has holes in its type system, and, until recently, had no platform support outside NeXT/OSX and no significant implementations outside NeXT/Apple. Apple seems to be trying to fix some of those issues now, but that's about 10-20 years too late.

Technically, Objective C could have become a major player; practically, Jobs screwed up badly and effectively killed Objective C in the real world. Objective C is having a small renaissance, but it will never achieve the kind of sweeping success it could have had.

Re:Oh dear, where to start ?

[FredFnord]

No, if you use a C function, you have to push the reference arguments to the stack, push a frame onto the stack, dereference the function pointer, perform your code, and then move the return value to the return register(s). Then you need to pop the frame from the stack and clean up the registers.

Doesn't that depend on how many arguments the function call has and how many free registers you have at the time? If it's a very simple function call that doesn't have much local data, the code is often inlined by any half-decent compiler anyhow. Which is sort of what you're looking for, speed-wise. But even if it isn't inlined, I seem to recall compiler implementations that can jump to simple functions (ones which require only a couple of arguments and local variables) without touching the stack. Which, again, is really what you're looking for: speeding up small, simple operations. (The bigger the called subroutine, the smaller the advantage is of avoiding the stack frame anyway.)

It's been a while since I worked with embedded systems, but I'm pretty sure I recall our (C for embedded PPC) compiler doing both of these things. Along with strewing 'EIEIO' opcodes liberally throughout the damn program for no readily apparent reason.

-fred

valgrind is your friend.

[botik32]

As a good programmer, it is a sane practice to check your app under some sort of leak detector. These things make it very easy to spot and fix memory leaks under various test cases. It does not take a "super programmer" to remove 99% of memory leaks in a fairly complex program.

number of CPUs?

[Anonymous Coward]

I assume you are talking about a server machine. I was just wondering, how many CPUs does it have, as well as the CPU cache size. Server machines != typical desktop intel box.

Customers don't like to pay for memory leaks

[bADlOGIN]

That's why garbage collection is so popular. Even if it's not your code, it could always be your co-workers code (added in a hurry under a tight deadline), or some proprietary 3rd party library kept on life support via the lowest offshore bidder (which you still pay full US sales & marketing Lexus buying price for). In those cases, give me a GC platform any day. Because the people who will be screaming for your head on a platter don't care who's fault it is for not cleaning up, and you have better things to do (like solve their problems and make working software) in the 1st place...

Support for a Java-like messaging syntax?

[Anonymous Coward]

For years there has been speculation that Apple would add support for Java-style messaging syntax to Objective-C.

Objective-C uses a Smalltalk-like syntax when sending a message to an object:
eg. [object messageName:arg1 furtherMessageName:arg2];

Java, on the other hand, uses a syntax derived from C++:
eg. object.messageNameFurtherMessageName(arg1, arg2);

Will "Objective-C 2.0" offer support for the Java-style syntax?

Re:Support for a Java-like messaging syntax?

[Fahrenheit 450]

Dear lord, I hope not. The Objective-C is so much more clear and natural than the Java/C++ way. Especially when there are a lot of parameters being sent in the message. E.g.

[myThing putzAboutWithName:"Bill" age:28 pizza:"pepperoni and mushroom" beer:"porter" shoes:"wingtip" inseam:34]
vs.
myThing.putzAboutWithNameAgePizzaBeerShoesInseam(" Bill", 28, "pepperoni and mushroom", "porter", "wingtip", 34)

Re:Support for a Java-like messaging syntax?

[NuShrike]

C++'s myThing.putzAbout("Bill", 28, "pepperoni and mushroom", "porter", "wingtip", 34) doesn't giving me a typing hernia like that Obj-C verbosity overload does.

You could do: [myThing putzAboutWithName:"Bill" :28 :"pepperoni and mushroom" :"porter" :"wingtip" :34] but ObjC is still about too much typing. How many times do you have to abuse your poor pinky here vs C++?

What ever happened to simple short code? C coding wasn't about duplicating a GUI at your fingertips. None of the better dynamic languages such as Python/Ruby has these syntactical crutches either.

Re:Support for a Java-like messaging syntax?

[santiago]

C++'s myThing.putzAbout("Bill", 28, "pepperoni and mushroom", "porter", "wingtip", 34) doesn't giving me a typing hernia like that Obj-C verbosity overload does.

I've yet to hear of anyone developing an hernia from typing, but people routinely have no idea what a function call does because the arguments are an indecipherable list of gibberish. Or, programmers introduce hard-to-find bugs because they get the order of parameters wrong. Labeling each arguments makes it clear to you as you write it what you intend each value to mean, and makes it clearer when you or someone else has to come back and work with that code in the future.

What ever happened to simple short code? C coding wasn't about duplicating a GUI at your fingertips. None of the better dynamic languages such as Python/Ruby has these syntactical crutches either.

At some point along the line, people realized that legible code was better than short code, because in a real-world environment, a line of code gets written once and read many times. Also, I love how Python lets me write:

myThing.putzAbout(name="Bill", age=28, pizza="pepperoni and mushroom", beer="porter", shoes="wingtip", inseam=34)

And furthermore, I can change the order of the arguments around without affecting the correctness of the code.

Re:Support for a Java-like messaging syntax?

[Anonymous Coward]

Bah humbug.

(putzAbout myThing :name "Bill" :age 28 :pizza "pepperoni and mushroom" :beer "porter" :shoes "wingtip" :inseam 34)

oh yeah, and putzAbout can be a different method for myThing+Bill+porter and myThing+Andy+lager... etc.
why? becuse Common Lisp CLOS DOESN'T SUCK like all you lame-ass single-dispatch OO languages.

That is incorrect.

[porkchop_d_clown]

Anything in the autorelease pool with a retain count of *zero* is automatically freed on the next invocation of the main event loop.

In other words, I don't know what this "real" garbage collection brings to the party.

Re:That is incorrect.

[TheUser0x58]

What happens when you forget to autorelease? Or when you over release something? Garbage collection worries about memory management so you dont have to.

Re:That is incorrect.

[Space cowboy]

Actually I think I am correct - the reason the event loop is important is that it always creates an autorelease pool at the start of the loop, and destroys the pool at the end of the loop.

If you want to have threads, and you call NSThread's detachNewSelector:toTarget:withObject: method, you have to set up the autorelease pool yourself. If you have an infinite loop in a background thread, your application will probably eventually crash, simply because you've never freed any objects in the autorelease pool in that background thread - the event loop happens on the main thread, so never affects any background threads.

My point is that the event loop (which is pretty fundamental to any cocoa app) has an implicit:

pool = [NSAutoreleasePool new]
(process all pending events)
[pool release]

which actually strengthens my argument, not weakens it...

Simon

Take a look at D if you can

[GCP]

I can feel myself waiting a few months, then ordering an updated Objective C coding book to pick this language up now.

I might consider it, too, if I hadn't discovered the D programming language. I can't do a proper comparison because I discovered D shortly after I started experimenting with Obj-C and lost all interest in the latter and no longer remember much about it except that it belonged to the "fast, not convenient" camp, like C and C++.

D was designed from the ground up as a memory managed Super C. The intention was to provide both the power of C and the convenience features of today's most popular scripting languages in a natively-compiled C-like language, with a host of other modern features such as full-fledged Eiffel-style design by contract, native Unicode strings, real arrays, etc. In order to offer as much of C's power as possible, it lets you manually override the memory management where you want to.

I'm not sure what's going on with D at the moment, though. The forums stopped working a few weeks ago, and today the whole website (digitalmars.com) seems to have gone offline. I hope everything is okay....

Re:Take a look at D if you can

[miyako]

I have to second this. I haven't played with Objective C much, but I did look into D a while ago and seems like it has a lot of potential.
The thing about garbage collection is that 80% of the time you don't need it, but the other 20% of the time not having it can really be a pain in the ass. I think that a lot of it has to do with the fact that, most of the time, memory management is just something that has to be done, and it's the sort of thing that compilers are better at than humans. Sometimes though, it's a design issue- and compilers suck at design (which is why programmers exist). Garbage collection is very handy when it comes to saving the programmer from the tedium of worrying about freeing memory in a lot of circumstances, but too many languages take the power completely out of the hands of the programmer. This leads to situations where the compiler might not realize that an object is out of scope and can be freed, but the programmer knows this because it is that way by design- and yet has no way to tell the compiler this, because the compiler is "helping" the programmer. There are ways to get around these sorts of problems, but they usually end up adding to the complexity of the program.
It sort of makes me think of the saying "C makes it easy to shoot yourself in the foot, C++ makes it harder, but when you do you blow off your whole leg" and want to extend it to say "when you take away all of a programmers weapons, so they cant hurt themselves, you leave them with no way to attack the problem".
I'm not against garbage collection in general, or other tools to help developers- I use Java quite a bit and really enjoy developing in it- but in order to know when a tool is right for a job, you have to know when a tool is wrong for a job.

Re:Take a look at D if you can

[GCP]

The thing about garbage collection is that 80% of the time you don't need it, but the other 20% of the time not having it can really be a pain in the ass.

I think I'd say it somewhat differently: Few programs need MANUAL memory management at all, and those that do need it rarely need it in more than a few spots. However, in those few spots where you need it, it can be critically important. When you use it, though, you DRAMATICALLY increase the likelihood of nasty, hard to reproduce bugs, security holes, etc. So, the natural approach is to make automatic memory management the default. Probably the biggest problem with C is the fact that so many things are done by raw memory manipulation (strings, arrays, etc.) and ALL memory handling/management is manual.

The fact that C ALLOWS you to do everything by raw, manual memory manipulation is the source of its power, but you wouldn't HAVE to do everything manually in order to get that power. You only need the ABILITY to do everything that way, which is the D approach. The default is D's first class strings, first class arrays, automatic memory mgt for everything, but anything can be taken over and done manually with ease when the programmer feels like doing so.

And digitalmars.com is back up again, so check out this feature comparison table: http://www.digitalmars.com/d/comparison.html

Ummm... Boehm

[borgheron]

The garbage collection mechanism by Hans Boehm has been available in GNU GCC for C, C++ and, yes, it also works for ObjC, for quite a while. And the big deal about this being added to Apple's implemnentation of ObjC is?

The "big deal" regarding ObjC 2.0 is the syntax "enhancements" I'll bet. So far, I haven't seen any examples of "ObjC 2.0" code.

GJC

Re:Ummm... Boehm

[Anonymous Coward]

"And the big deal about this being added to Apple's implemnentation of ObjC is?"

Perhaps, unlike Boehm GC, it works correctly and efficiently on Darwin? No hacking required to force the GC to only use one processor, no more complaints about large pages (which were allocated GC_malloc_atomic, so they don't need to be traced anyway)..

BDW's a nice idea, but

John Carmack's platform choices

[zhobson]

It would be interesting if John Carmack's views, if he jumps into this conversation. Afterall, he went from Objective-C (Quake 3) to C++ (DOOM 3).

It would be interesting, I agree with that. But John Carmack didn't write Quake 3 in Objective-C. He used a black-and-white NeXTstation during the development of the original DOOM, but that game and every game until DOOM 3 were actually written in C (and some assembly, presumably). All of the tools for these games were originally developed in Objective-C, because NeXTstep (and by extension, Cocoa) is a fantastic development system for that sort of thing. That's why there were no official tool releases for DOOM and Quake: Not enough people had a NeXT system to run it on so it wasn't worth it.

I think around Quake 2 or Quake 3 Arena they switched to Windows as their primary development platform. Carmack started writing his tools in C++ (again, I think), and eventually the game (DOOM 3) as well. But none of the Id games were written in Objective-C, just the tools. I'm sure John Carmack would have many nice things to say about Objective-C though, since he held on to his NeXT environment for a pretty long time.

Can't retrofit safety

[modeless]

Garbage collection is only one part of what makes a language like Java safe, and Objective-C doesn't have any of the other parts. Unless they plan to also implement array bounds checking and restrict pointer casts and arithmetic, this new Objective-C will happily stomp all over your garbage-collected memory, producing bugs just as weird and security holes just as bad as before. Without the full safety package, the benefits of garbage collection start to look rather meager if one discounts convenience. Personally I think one shouldn't. Saying garbage collection doesn't save effort is ridiculous. Producing optimized code isn't easier with garbage collection, but producing slow code is. Meaning that the routine majority of your coding gets done sooner and you can focus your effort on the parts that actually need to be fast.

Re:Can't retrofit safety

[m874t232]

Garbage collection is only one part of what makes a language like Java safe, and Objective-C doesn't have any of the other parts.

Quite right. And that's why I pointed out in another thread that I think that adding garbage collection to Objective C is just a gimmick unless Apple has made substantial changes to other parts of Objective C as well.

Producing optimized code isn't easier with garbage collection, but producing slow code is. Meaning that the routine majority of your coding gets done sooner and you can focus your effort on the parts that actually need to be fast.

We don't have to guess: garbage collection has been available for C, C++, and Objective C for more than a decade. My experience on several projects has been that it simply doesn't help a lot for languages in the C family. There are several reasons for that: retrofitting gives you something that has a lot of intrinsic complexities and pitfalls, it's not very efficient, and most C libraries aren't designed for a garbage collector anyway. The one thing it would help with on Macintosh is that it frees people from having to learn the Cocoa memory management rules.

Objective C can be cleaned up, by separating the Smalltalk and C parts of the language more strictly, but merely adding garbage collection is insufficient. We'll have to see what Apple actually did. In any case, while this revision may not be enough, it's a step in the right direction.

swapped out mem

[botik32]

I got the point about half the mem being actually free (paged out). Thanks, that clears up the issue somewhat.
The point is, before I tried java apps, I was fine on a 256MB system and never needed to enable swap space. So I never did. Then suddenly I got this whooping app loading up all my 512 RAM and then thrashing like hell - so, naturally I said WTF. It is kind of tricky - without swap space that RAM was actually wasted.

D'oh. Thanks for clearing up one misunderstanding about Java. Still, Java GUIs seem kind of slow to respond, compared to native stuff. Oh well.

Re:swapped out mem

[zootm]

I find that a lot of people have problems with Java desktop apps simply because the UI toolkits are undeniably kinda clunky, along with the fact that there was a time (before the HotSpot VM got on the scene and running quick) where Java apps did run Real Slow. There is native toolkits for Java (see Eclipse's SWT), but I think that the JNI (Java Native Interface) things required for that may slow it down a little. Sun is making great headway with Swing though (check out the Java 6 version if you have the chance, might require some knowledge of Java to make old apps use it correctly), with much better "stuff" coming in the new version.

Desktop apps can often give Java a pretty bad name; I myself had problems believing that Java was fast until I started developing server apps with it, when its high performance becomes very apparent. Another problem, of course, is that a lot of Java desktop apps (Azureus etc.) are extremely complex pieces of software. A C++ Bittorrent client doing much the same as Azureus would have to be specifically written for speed to appear at around the same speed. There's just not enough examples of speedy Java desktop apps, but that doesn't mean they're not possible or don't exist. Gnutella client Cabos is written in Java, and is lightweight, quick, and I believe it has won an award for its interface. There's just not enough examples like that, though.

Of course, the other "problem" with Java performance is people staring at top or Task Manager or whatever and assuming that all of the memory that is listed is being used by the app and therefore not by other programs, but it looks like you're past that assumption :)

ObjC Referencing Counting In A Nutshell

[Anonymous Coward]

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.

Important nonetheless

[treak007]

I see way too many programmers running around, writing the most ineffective code possible, and relying on fast machines to hide the fact that their code uses 1 gig of ram to display "hello world". That being said, I think that programmers should try to strive for the most effective coding strategy possible, simply because it is good practice. You may only have to make small programs for your company now, but in the future you could be making hardware intensive applications, and if that time comes, effective coding strategies need to be implemented. The main problem I think with Java's memory management is that it doesn't let you control enough. It allows the JRE to control too much memory allocation. That is one of the main reasons that people think that Java is slow. I think that adding GC to objective-C will give developers another option to try when tweaking for speed.

Hey, Ashosle!!!

[Anonymous Coward]

Your signature line has a maximum of 120 characters. It says so right next to the box where you fill it in. Are you some kind of fucking retrad, or are you just retraded? Or maybe you just can'to cunt? Or maybe you don't want to count? Don't bother repsonding to this post, becuse aI won't see it. Didlo.

Wrong about templates

[Anonymous Coward]

If you're trying to tell me that the generic containers of C++ come with zero cost, I have a bridge to sell you.

A vector has _exactly_ the same cost as an array if we ignore the cost of the initial dynamic allocation. Why? Because it's implemented as one on most STL implementations. Any reasonable inlining compiler will turn element accesses into direct array accesses, so no performance is lost there either. I believe TR1 will also add array which does static allocation and allows compile-time references to individual elements.

Btw, templates are used for other things besides generic containers, and can indeed allow greater-than-C-efficiency in some areas. This is because you can encode more semantic information into templates and effectively "program" the code generator to generate better code, especially where cache utilization is concerned -- see Blitz++ for an example. Of course, this is highly non-trivial to do correctly, but for expert programmers templates can indeed be an incredible tool.

I *really* don't think that's right.

[porkchop_d_clown]

Actually I think I am correct - the reason the event loop is important is that it always creates an autorelease pool at the start of the loop, and destroys the pool at the end of the loop

Hrm.

So, I googled around and I see both explanations on the web - the NSAutoReleasePool class seems to do as you describe; yet my developer books and past experience are as I describe - the heap/malloc zone used for default allocations is an "autorelease pool".

Over releasing is a no-op.

[porkchop_d_clown]

Although, you still risk chasing an invalid pointer if you hang onto an object after you release it.

If you forget to release, you leak.

GC is unpredictable and has caused huge problems for me when I've worked with Java desktop applications in the past - Java apps ballooning up to large sizes then freezing for several seconds as the GC finally wakes up - it wasn't pretty.

Perhaps things have changed since Java 1.2; but that's certainly been my experience. Besides, scanning every pointer and handle in an application just to see if it still points to something is an awfully ugly hack to get around programmer stupidity.

Re:Over releasing is a no-op.

[TheUser0x58]

Well my question was rhetorical but...

Over releasing is a no-op.

Not quite. When you overrelease, you are attempting to release data that had already been deallocated when its reference count hit zero. That could segfault, or start causing strange memory errors.

Perhaps things have changed since Java 1.2;

Probably an understatement, although Im not a huge Java user so what do i know.

What?

[porkchop_d_clown]

I've been coding C for just under twenty years and I can tell you, you're wrong. Modern GC's allocate faster than C's malloc routine.

If you've been coding for 20 years, but failed to realize that malloc() is not part of C, but part of libc - and varies from OS to OS and from compiler to compiler, then I don't know how I can believe your assertions about performance.

Linux malloc() is based on the glibc and is slightly brain damaged from my point of view, because it can't be properly overridden for debugging or dma operations (it has debug hooks but they aren't thread safe). OS X malloc() is a different implementation that actually supports multiple heaps and allows for the different heaps to have different allocation/release strategies.

There are other algorithms as well, which any book on the subject would tell you.

Re:What?

[Glock27]

Linux malloc() is based on the glibc and is slightly brain damaged from my point of view, because it can't be properly overridden for debugging or dma operations (it has debug hooks but they aren't thread safe). OS X malloc() is a different implementation that actually supports multiple heaps and allows for the different heaps to have different allocation/release strategies.

Regardless, GC is often faster, and also prevents mistakes that C/C++ coders often make.

The other point about GC is that for reliable, long-running programs GC mitigates the issue of heap fragmentation, which can lead to irrecoverable program errors in programs using malloc() and cousins.

GC technology is advancing rapidly, there are even deterministic GCs for RT use now.

Object recycling is also often a good strategy, since you get "new" objects with no allocation/GC overhead.

Re:What?

[kaffiene]

I am *well* aware of that.

You really are going a long way to split hairs. Saying that malloc isn't part of C is like saying that printf isn't part of C - yes, it's in a library, but it's pretty fundamental to most C programmers (it's in K&R after all).

Still, if being a pedant helps you avoid thinking, all power to you. I hope that sand is keeping your ears warm.

Re:What?

[m874t232]

You know, as someone who spends a lot of time dealing with the interactions between malloc and the OS, I find it extremely amusing that you think a sanity checker for the heap is a bad idea.

Malloc debugging is a great idea, it just shouldn't be in the standard library or enabled for production use.

Personally, I wish Linux had it.

Linux has valgrind, dmalloc, electric-fence, and ccmalloc. Unfortunately, the most useful of those, valgrind, doesn't exist for OSX.

I don't think syntax changes would be needed.

[porkchop_d_clown]

The malloc code in OS X supports what are called "zones" - each zone is it's own heap and function library for managing the heap. They're probably just swapping the default allocator for one that supports GC.

I'm still unsure about the value of this, but I don't think it would require changes to the applications themselves.

Re:I don't think syntax changes would be needed.

[borgheron]

I believe you misunderstand. I was not saying that there were syntax enhancements for supporting garbage collection. Someone suggested that there are syntax enhancments in Objective-C 2.0 in general. What these are, I have no clue, what I was saying is that I suspect that the syntax changes are the "big deal" about 2.0 since GC is already available. :)

Does that clarify? :)

Later, GJC

Great..now to persuade those C++ hotheads!

[master_p]

Garbage collection is truly necessary to write apps effectively and quickly. I admit some types of apps do not need garbage collection...but most of them do.

So let's all sign the following petition, and maybe those C++ hotheads can be persuaded to include garbage petition in C++:

petition for putting GC in C++.

Re:Great..now to persuade those C++ hotheads!

[Anonymous Coward]

We also need an ipetition for:

1. Don't add GC to C++. Those who want it are free to use addon GC libraries that have been around for years and supposedly work well (I've never found any use for it in 12 years, but admit there might be one someday.)
2. Don't add any new template constructs for at least 5 years. This will give compiler vendors time to get the current ones working, slow the gray goo of angle brackets that's making C++ ever more unreadable, undebuggable, and unmaintainable, and hopefully give the generic mania time to run down.
3. Don't add any mandatory libraries for at least five years, particularly freely available one. This is specifically targeted at reducing the boost effect and ever-convoluting STL, which serve little useful purpose beyond making compilers bigger and slower, and selling books.
4. Use the extra time and resources afforded by 1-3 to add at least one useful feature per year: possibilities might include preprocessor improvements, checked typedef's, bitfield enums. Maybe consider asking even users what they want rather than language theorists?

Re:Great..now to persuade those C++ hotheads!

[Bill Dog]

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.

Re:Great..now to persuade those C++ hotheads!

[Anonymous Coward]

Too bad that the apps run as "Garbage collection is truly necessary to write apps effectively and quickly" as Java and .NET (which are indeed using garbage collection). That is, almost as effectively and quickly as going to the cupboard, picking up a pencil and paper, walking back to my desk, doing everything on paper... AND cleaning up the garbage myself instead of leaving it on the table for mommy (she doesn't work here).

LoL.

[porkchop_d_clown]

And yet, you are the one claiming that C's malloc is slower. Since malloc isn't a single thing, how can you make that claim?

Re:LoL.

[kaffiene]

Because the issue lies in the multiple invocations to free() memory that you HAVE TO MAKE in a C programming model. The problem is FUNDAMENTAL to the usage pattern, not just the allocation model. Freeing all at once instead of multiple times is smarter and cheaper.

That said, pretty much all malloc allocation algorithms are slower than generational GCs PURELY at allocation since mallocs have to find a good fit on the heap whereas generational GCs have contiguous free space and allocation can be done with a simple pointer addition. It doesn't get any cheaper than that, and malloc simply CANNOT match that unless you're dealing with an infinite memory space and you never call free().

Seriously, go read the literature - you're just repeating all the same old myths which have been refuted for years now (generation GC came in with Java 1.2 for christ's sake!)

Minimizing heap fragmentation

[porkchop_d_clown]

You'd have to provide cites for GC being "often faster". I really can't see how scanning the stack and globals for pointers that might either point to an entity or, worse, to the interior of an entity can be fast.

I spend my days working with code that does lots and lots of pointer math, where the pointers are nowhere near the beginnings of the buffers; I can't see how GC would do anything but accidentally free memory that some DMA operation is still using.

Re:Minimizing heap fragmentation

[Haeleth]

You'd have to provide cites for GC being "often faster". I really can't see how scanning the stack and globals for pointers that might either point to an entity or, worse, to the interior of an entity can be fast.

The only quantitative study I know of is this one, which finds that performance of GC is equivalent to manual memory management where sufficient memory is available, but can become much slower where memory is constrained.

However, the results are likely very much dependent on the specific programming style. It may be that GC can be faster if the code is designed differently.

I spend my days working with code that does lots and lots of pointer math

Then you don't want GC. GC and pointer arithmetic are fundamentally incompatible, since most GC strategies rely on being able to move objects in memory. However, if you're doing that kind of thing, then you're working on very low-level code. Where GC wins is with high-level code, GUI applications and the like, where performance is less important than developer time.

Reference counting is extremely simple

[porkchop_d_clown]

It's just that people coming from straight C aren't used to it.

I'll be the first to admit that I've been caught by releasing things early, or worried that I wasn't releasing things that could be - but once you get into the habit of retaining things you want to keep and releasing them when you don't want them anymore it's no harder than malloc and free.

Re:Reference counting is extremely simple

[ceoyoyo]

Quite a bit easier than malloc and free, actually. If you release and retain properly you can never run into a situation where the memory gets released too soon or not at all. In complex (particularly in threaded) programs malloc and free require some error checking, flags, and/or mutexes to make sure you don't get into trouble.

I wouldn't "clean" it at all.

[porkchop_d_clown]

The problem isn't Objective C, it's that people choose the wrong language for the job.

I'll be the first to admit that Java is easy to use and has some powerful features. At the same time, I wouldn't write an OS or a device driver in it. Objective C, like C++, was an attempt to retrofit OO features onto a highly machine-oriented language. In the abstract, I think that is a foolish thing to do but, compared with the original C++ grammar, I think ObjC was a better job.

C++ has improved a lot since then, but I still don't think I'd choose to use an OO language for low level work, any more than I'd use straight C to design a web site.

Re:I wouldn't "clean" it at all.

[m874t232]

I'll be the first to admit that Java is easy to use and has some powerful features. At the same time, I wouldn't write an OS or a device driver in it. Objective C, like C++, was an attempt to retrofit OO features onto a highly machine-oriented language. In the abstract, I think that is a foolish thing to do but, compared with the original C++ grammar, I think ObjC was a better job.

But the fact is that people are using Objective C for programming applications and web services. Since they do, it makes sense to try to improve Objective C. Objective C could be transformed into a language with the safety and convenience of Smalltalk, C-like access to machine features and C-style APIs, and excellent runtime performance, while still preserving the expertise and existing investment in software. I'm just not sure that Apple's engineers are up to the challenge; we'll have to see.

heaps...

[porkchop_d_clown]

There is no need to panic. You can support both reference counting and garbage collection in one run-time, provided the objects are in separate heaps.

So, the GC is a different allocation zone? Do you use the various *withZone functions when allocating for the GC, or does the GC become the default and you use *withZone functions to get the retain release model?

AFAIK, Linux ObjC == true, retain/release = false

[porkchop_d_clown]

Apple has always pushed their ObjC changes back to gnu - but that doesn't mean various users/distros provide a gcc that has those features enabled.

(checking my ubuntu partition...)

Yeah, Ubuntu, at least, includes support for compiling objective C files. I doubt the Ubuntu glibc includes support for retain/release OR this new gcc though. Last time I looked at the source code, the Darwin version of malloc() was utterly different than the generic version. The Darwin version of malloc has some very interesting features; for example, it maintains a sanity-checking system that keeps you from free()-ing memory to a heap that wasn't malloced() from that heap. Those features actually caused me some serious headaches when porting Linux DMA code to Mac, but we were also able to use those features to overcome those headaches.

I have no idea which malloc implementation is faster, but Darwin's generally seems more robust.

I wouldn't even say that.

[porkchop_d_clown]

Obj C is C with some syntax extensions - I'm not trying to pedantic, ObjC code tends to look like a Reese's Peanutbutter cup - there you are, happily eating your chocolate, errr...., reading C code, when suddenly you discover someone mixed some Smalltalk into it.

Checking some more...

[porkchop_d_clown]

From my 1st edition ADC Cocoa book...

Each application puts in place at least one autorelease pool and can have many more. An autorelease pool tracks objects marked for eventual release and releases them at the appropriate time.

To me that implies that the same pool exists for the life of the app.

Maybe the behavior changed sometime after 10.0?

Re:Checking some more...

[Space cowboy]

An application gets an Autorelease pool set up for it in NSApplicationMain, the event loop creates and destroys one every time through, so you can see how it might appear to work automagically. However, when you try to set up a thread, it all falls down - you have to create your own pool and release it at the end of your thread function. Try doing an NSLog() in a thread method without setting up your own pool...

Pools nest, so you can (and it's good practice to) create inner pools for while loops that create/destroy lots of objects - in the same way, the application has a pool, each event loop has a pool, and the coder can create pools within the event-loop pool.

Simon

Freeing all at once...

[porkchop_d_clown]

Ummm... In my professional experience with Java, "freeing all at once" has been directly responsible for making Java on the desktop unusable. I will be the first to say that Java has probably gotten a lot better since I got my JDK certification, but I have no reason to believe that "freeing all at once" is somehow better than doing incremental heap inserts. Particularly since the GC has to go hunting for the things it will be "freeing all at once".

Re:Freeing all at once...

[kaffiene]

here's an IBM article which explains why GC has performance wins (a little old now, but still good)

http://www-128.ibm.com/developerworks/library/j-jt p01274.html

Sonny, since the effect is the same

[porkchop_d_clown]

there is no difference.

Re:Sonny, since the effect is the same

[Abcd1234]

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.

Re:AFAIK, Linux ObjC == true, retain/release = fal

[m874t232]

Those "interesting features" are nothing new, and you can get them on Linux, they're just not turned on by default (because they have overhead).

Retain/release and all that are implemented by the Objective C libraries, not libc.

Sorry, yeah, you're right

[porkchop_d_clown]

about retain/release not being in libc; I seem to be confusing retain/release with allocator zones today.

Re:Sorry, yeah, you're right

[m874t232]

If you want zones or similar features on Linux, use a different malloc library; the fact that glibc performs little error checking and provides few extra features is deliberate. Putting non-standard functionality into standard system libraries is not a nice thing to do because it misleads developers into thinking that non-standard features are standard.

Jobs can blame himself

[m874t232]

I'd like to know why isn't ObjC more popular outside Apple (and NeXT) circles?

For a long time, there was no usable free compiler available. And the reason for that is that NeXT only fulfilled the letter, but not the spirit of the GPL: they built their Objective C compiler on top of gcc, but they only gave back their modification under threat of a lawsuit, and then in a form that wasn't very usable.

If NeXT had given a usable Objective C frontend to GNU (as they should have under the GPL), and donated a usable Objective C standard library, there's a good chance that Objective C would be wildly popular on UNIX and Linux, because it was just the kind of language people needed in the 80's and 90's. Instead, C++, Java, and C# have taken over that void.

Lack of a use community has also kept Objective C from evolving; garbage collection should have and could have been added a decade ago, and there are some type safety issues in Objective C that also could have gotten fixed.

The problem is that

[porkchop_d_clown]

That's for Java, not a C-type language. Since Java does not permit access to memory pointers, GC can be made much more efficient; in a language derived from C, GC is never going to work well - there are too many ways to access memory directly.

Re:The problem is that

[kaffiene]

That's a fair point. That said, there are (and have been for some time) GC'rs for C although I'm not sure how they perform. Objective C will presumably be in the position of being able to use either the GC'r or allocation on the stack - possibly a nice 'best of both worlds' proposition?

Heh. Non-standard features?

[porkchop_d_clown]

Actually, from first hand experience I can tell you that Linux can make a mockery of even the mallopt features that glibc says it supports.

Besides, why are you lecturing me about this? Someone asked a question, I said "no" and now you're lecturing me about what I have to do to change the answer to "yes"? Thanks, but I already know that.

Re:Heh. Non-standard features?

[m874t232]

I'm "lecturing" you because you made claims that implied that Apple did a better job with their malloc:

The Darwin version of malloc has some very interesting features; for example, it maintains a sanity-checking system that keeps you from free()-ing memory to a heap that wasn't malloced() from that heap. [...] I have no idea which malloc implementation is faster, but Darwin's generally seems more robust.

These aren't "interesting" features, they are bad design decisions in a standard library. The accumulation of those kinds of bad design decisions is what has forced Apple multiple times to start over again. While Apple has good taste in terms of features, the software industry would do well to stay away from emulating Apple's system architecture or design.

Yeah, sorry.

[porkchop_d_clown]

There seems to be a lot of cross communication in this thread.

effectiveness Re:Important nonetheless

[Anonymous Coward]

>I think that programmers should try to strive for the most effective coding strategy possible

too often, there are competing aims:

Vendor: maximize profit - cheap (short development time)

Customer #1: (the person whose budget is paying for the software) - minimize expense -
[you want the system to allow your users to accomplish their business objectives, and
maybe even to be 'happy' with the system]

Customer #2: (the person using the system every day) - minimize time 'wasted' using system
[here you want the objects in the system to make sense to your business]

Customer #3: (IT department providing tier 1 support for the system) - figure out how the system really works
[here you want the code to be easy to reason about and built mental models of how it really works]

Fast memory allocation for the young generation

[Dr. A. van Code]

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.

With a generational garbage collector there is a pool of memory in the young generation (typically called "eden") that new objects are allocated from, and they are all contiguous, and there is a pointer to the end of the allocated space. Allocating a block of memory is literally as cheap as incrementing that pointer.

On a somewhat related note, Joel wrote about the importance of languages which manage memory for you automatically in his article How Microsoft Lost the API War. It's from a while back but it's still a great read, so if you missed it, correct that right now.

What?

[porkchop_d_clown]

ROTFL.

You know, as someone who spends a lot of time dealing with the interactions between malloc and the OS, I find it extremely amusing that you think a sanity checker for the heap is a bad idea.

So, GC is good, but defending the heap is a bad idea?

Personally, I wish Linux had it. As it is, the unsafe implementation of malloc hooks in Linux leaves me forced to deal with races and timing holes, or with the "bad" decision of completely replacing the standard malloc library with my own.

Ohhh yes...

[FredFnord]

Gnutella client Cabos is written in Java, and is lightweight, quick, and I believe it has won an award for its interface.

I've seen it. Don't know whether to be happy that at least someone is making an effort to write open-source Java software with an acceptable interface, or deeply depressed that that's what gets awards for interface design in that world.

-fred

Strunk & White's only real advantage...

[FredFnord]

...is that it's better than any of the other ostensible 'Manuals of Style' out there that I've run into.

It's a great set of rules for beginners, and the fact that you don't know that ('no good author in the history of the English language') makes me a little depressed and sad. They never intended it to be a manual of style for e. e. cummings, they intended it to be a manual of style for George from Accounting and Fred the 'OMG my writting si so 1337!!11!1elevendy-one!' college student.

To learn to become an adequate writer, you need to learn the rules of writing. (Doesn't matter which rules, really, they just have to be self-consistent and lead to readable, concise writing that does not significantly offend the reader's sensibilities.) To learn to become a good writer, you need to learn when to break said rules. To learn to become a great writer, something I certainly haven't managed yet, you need to write. And write, and write, and write, and read, and write.

-fred

I told you so...

[Gorbag]

Oh, but I'm not a java head. I'm a Lisp hacker. And we've been "telling you so" since 1958...

Now all you need are macros (the ability to manipulate code as data so you can write code for the compiler, say) and you kids'll be all set. Of course, you'll need a more regular syntax and semantics for that... I know, how about something mathmatically based, like the lambda calculus? :-)

New features

[atomm1024]

From what's known so far, Objective C 2.0 also has some other interesting new features. It now has a "foreach"-style construct (actually for (x in blah)), and obj.property notation supporting internal getters and setters. God willing, maybe we'll soon see array/dictionary construction and access without ridiculous syntax like [[NSArray alloc] initWithObjects: ..., nil] and [array objectAtIndex:blah]. (Maybe the former could be shortened as @{a, b, c, ...}, like how NSString construction consists of C-style syntax prefixed with @. The latter has an obvious choice -- the array[blah] notation used everywhere else in the universe.)

"I finally look like a real person!" -- Lisa Simpson
"I finally look like a real programming language!" -- Objective-C

(Not that it wasn't a real programming language before; it just got ridiculous sometimes how much really basic syntactic sugar it lacked.)

Re:New features

[BasilBrush]

The latter has an obvious choice -- the array[blah] notation used everywhere else in the universe.

Can't do that. It looks like a C expression. Which is a bit of a problem when the compiler supports C expressions.

Re:New features

[atomm1024]

True, but I don't think there's any situation in which that notation would be applied to a pointer to an Objective-C object. The compiler could check the type of the receiver, and if it's a C array, then compile it as usual, but if it's an Objective-C object, then translate it to some internally designated accessor method call. That couldn't be hard, considering C++ allows much more overloading of C expressions while still compiling them as usual when they're actually applied to plain C types.

If I remember correctly, GCC yields an error if a subscript expression is used on an Objective-C object anyway. That behaviour could simply be revised to transparently translate a[x] to [a objectAtIndex:x] (or [a valueForKey:x] if x is also an object rather than an integer).

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

[DuckDodgers]

i am sorry if you can't remember to free your own damn memory then.. why are you writing code???

In a perfect world, every project gets all the time required to be completed with optimal efficiency and performance. In the real world, the idea is to limit scope, cost, and timeline so that you can accomplish the task as best as you can within the allotted time.

If you don't have to worry about freeing your memory, that's one less thing slowing your productivity. It's also one less possible source of bugs. In any team project, it is also one less source of problems from other developers. Now in certain applications where performance is paramount and a fine level of control is desired, manual memory management is the way to go.

In other applications, the developer time you save by using Objective C, Java, Perl, Python, Ruby, or whatever easily pays for any additional server hardware you require to run the less efficient code.

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

[Amouth]

I know what you are saying and trust me i am not perfect at it and i have the same issues. but to me C/C++ seemed like the last place that needed this..

if you want something that does garbage collection use java.. if you want something to be lean and mean use C... It just seems like you are giving people tools to let them be less responsiable at their jobs.

a good question to look at with this is when something falls out of scope can get recycled by the collector to another thread does it bother to zero out the space before it hands it over if not i see major issues where something can now read info from another proccess that it shouldn't have access to. by adding this layer you are adding another set of problems...

I am not saying that garbage collection is a bad thing.. it fits an area in this world - but to be honest if you arn't worried about doing memory management you don't care if it is lean why not use something that already has it and is slower.. this Addition seems like making something that wasn't designed to do something fit a roll it isn't suited for an pointless.s

Sigh. Would you please just look at the source?

[porkchop_d_clown]

dmalloc and other malloc debuggers work by using the existing glibc malloc-hook functionality. And, guess what? That functionality isn't thread safe.

This isn't about enabling debug features in the default malloc library, it's about not using a design methodology that's been well understood for the past 30 years. The debug hooks for glibc are broken. Period.

get a clue

[Anonymous Coward]

valgrind uses dynamic instrumentation, electric-fence and dmalloc use link time symbol replacement (I suspect ccmalloc does, too).

dmalloc and valgrind are thread safe, and ccmalloc and electric-fence have thread-safe patches available.

As for the glibc hooks, they aren't intended for heavy duty debugging.

Your assertion that the glibc hooks aren't "thread safe" is meaningless; apparently, you don't even understand how they work or what thread safety means.

The situation in terms of malloc debugging is far better on Linux than on OS X. Lack of valgrind on OS X is a grave disadvantage.

But don't let reality stand in the way of your zealotry; when Apple catches up eventually, you'll then just be telling us how it was really Apple that invented it all, or at least perfected it, or whatever.

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

[cyborg_zx]

But to be honest if you aren't worried about writing in assembler you don't care if it is lean. It just seems like anything else is just giving people tools to be irresponsible in their jobs.

Yawn.

Seriously, are people still trotting out these arguments? Why do you think we have higher-level languages? It's not to be a test of a programmer's mettle.

Re:AFAIK, Linux ObjC == true, retain/release = fal

[Anonymous Coward]

I doubt the Ubuntu glibc includes support for retain/release OR this new gcc though

Install GNUstep and you will. This is the way it has always been.

The Darwin version of malloc has some very interesting features; for example, it maintains a sanity-checking system that keeps you from free()-ing memory to a heap that wasn't malloced() from that heap.

Other libcs provide similar features. I know that glibc has the MALLOC_CHECK_ variable.

it's a sad day...

[namekuseijin]

...when an olditie like another C descendant imperative language receives hurrahs for finally getting GC, when much more modern, robust, type-and-thread-safe languages like Haskell, Scala, OCaml, Erlang and others go on pratically unoticed...

I don't think that's the case.

[porkchop_d_clown]

When you overrelease, you are attempting to release data that had already been deallocated when its reference count hit zero. That could segfault, or start causing strange memory errors.

First, if the item still hasn't been collected by the autorelease mechanism, decrementing the counter won't hurt it. If it has truly already been freed, Apple's implementation of malloc has defenses that detect this and prevent a double-free from occurring.

Apple's malloc library is interesting. I assume that these kinds of defenses make it slower than it could be, but you actually have to enable a special debug mode if you want double-frees to cause program crashes.