Slashdot Mirror
Xcode Update Gives Objective-C Garbage Collection
William Henderson writes "That's right, if you haven't read it for yourself yet, Objective-C '2.0' now supports garbage collection. I foresee a great, huge, gigantic debate about to ensue, and a lot of java-heads sparking 'I told you so'. Why not start it here on slashdot?"
I really do feel that manual memory management in most apps is now redundant. i fully accept its need in some cases an indeed I've advocated 'regressing' an app at work, which was ported from C to Java, back into C again to use manual memory management for performance. But that app's an exception - sub-millisecond performance is required. How many day to day apps need that?
I can feel myself waiting a few months, then ordering an updated Objective C coding book to pick this language up now.
Cheers,
Ian
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?
...spike
Ewwwwww, coconut...
If people like you were in charge of innovation, we'd all be running Commodore 64s with hacked CP/M.
AFAIK, garbage collection may be enabled or disabled as a compiler option. If you don't like it, then just disable it and carry on.
We developers will need far more technical details before we can even consider using this functionality in our applications.
What garbage collection technique is used here? How does it differ from the Boehm GC-based technique offered by the GCC Objective-C compiler?
Are any guarantees given with regards to the performance of the collector? Does it suffer from many of the problems that plagued the Java GC?
What sort of modifications do we have to make in order to take advantage of this support?
At the end of the day Apple aren't really catering for the top programmers here who will write good programs no matter what. It'll help the rest write better programs though.
the more they over-think the plumbing the easier it is to stop up the pipe
Far more exciting is that Leopard gets DTrace. Look at the last line of the page the story links to.
Well, let's say as exciting.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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.
... 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?
An autorelease pool is a promise that when the pool is released, any objects with a retain-count of 1 will be released. So, you create your objects and call the autorelease method on them:
... clears up after you, but it's no garbage collection, it's just a convenient way of using retain/release.
NSAutoreleasePool *pool = [NSAutoreleasePool new];
NSObject *myObject = [[NSobject new] autorelease];
All that happens is that the object is added to an internal array, and when the pool itself is released, it calls [release] on all the objects in the array. I guess it actually calls [release] on the object as soon as it's gone into the array as well, or the object's retain count would be 2 when the pool was released (one for the 'new', one for the insert-into-array). So,
[pool release]
ObjC 2.0 does real garbage collection, like java's. No retain, no release - just automatic management when objects fall out of context.
Simon
Physicists get Hadrons!
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?
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.
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
"Garbage Collection is cool cuz you don't have to, like, remember to delete stuff"
Shudder.
posted wirelessly via abacus and smoke signals
Modern GC is *faster* than hand-coded free calls in 90% of situations.
c omputer_science)
"A major reason for this is that the garbage collector allows the runtime system to amortize allocation and deallocation operations in a potentially advantageous fashion." -- http://en.wikipedia.org/wiki/Garbage_collection_(
--
Carnage Blender : Meet interesting people. Kill them.
and your point is?????
'...if only "Jumping to a Conclusion" was an event in the Olympics.'
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.
Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
*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.
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
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.
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".
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.
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.
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.
"She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
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.
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
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.
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.
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.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
I have been a Java developer for eight years. What problems have plagued Java garbage collection?
Join Tor today!
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.
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.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Well, actually if you really *need* speed, then ObjC groks C perfectly - it's a cast-iron guarantee that any legal C will work in objC, unlike C++. C performance is just as good as C++...
Um, no. Objective C uses dynamic despatch (ie: the method to run is determined at runtime not compile-time. This is one of its most powerful features. As for "nothing you can do", you can retrieve the bound method as an IMP (like a function pointer) and call it directly to remove any overhead. Useful in loops.
No. Objective C was designed as an adaption of the ideas behind smalltalk, as applied to C. It was designed in the early 1980's, COM was designed in 1993, although it wasn't called COM until 1997.
Well, that's a matter of opinion, but in any case, Objective C is a dynamic language. Most of the power of templates is encapsulated within the dynamic-despatch abilities of the language, coupled with the 'protocol' feature of the language.
It could be said that Objective-C is a lot like Java with many of the same problems but because it was never marketed with a cross-platform VM it didn't take off like Java.
I think it is significantly like java, but it's compiled (like C/C++). It's a *lot* faster than Java, and handily beats gcj too, at least on the tests I've done. You need to enumerate these "same problems" before I can respond though.
Um, take any legal C code and it *might* compile in C++. It *will* compile in ObjC - how can C++ be "more like C" than ObjC ?
ObjC has introspection, dynamic binding, (now) optional garbage collection, (always) a very easy retain-count allocation system, really easy-to-learn constructs (I think there's 12 new statements, or something like that), *and* a weird syntax - it grows on you though
You need to read the PDF manual. There's a lot of stuff you're saying as fact, that is simply wrong.
Simon
Physicists get Hadrons!
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".
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.
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.
omnia tua castra sunt nobis
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...
*** Sigs are a stupid waste of bandwidth.
Did you reply to the wrong post? Because there's not a single insult in my post.
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.
Clear, Dark Skies
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.)
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.)
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....
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
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
Gregory Casamento
## Chief Maintainer for GNUstep
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.
" Bill", 28, "pepperoni and mushroom", "porter", "wingtip", 34)
[myThing putzAboutWithName:"Bill" age:28 pizza:"pepperoni and mushroom" beer:"porter" shoes:"wingtip" inseam:34]
vs.
myThing.putzAboutWithNameAgePizzaBeerShoesInseam(
-30-
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.
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.
Firebug. It will make your jaw hit the floor.
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.
"and understand those "$50 USD books" (which is doubtful, given your post)"
"A language that doesn't affect the way you think about programming, is not worth knowing" - Alan Perlis
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.
: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++?
You could do: [myThing putzAboutWithName:"Bill"
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.
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.
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.
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.
Klingon Software is not released, it escapes, inflicting terrible damage onto the enemy as it does
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.
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.
sudo ergo sum
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.
sudo ergo sum
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".
Clear, Dark Skies
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.
Clear, Dark Skies
You seem to be under the bizarre impression that C++ does not destruct temporary objects.
Attention zealots and haters: 00100 00100
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.
Clear, Dark Skies
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.
Clear, Dark Skies
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++.
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.
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?
Clear, Dark Skies
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.
Clear, Dark Skies
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.
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.
Clear, Dark Skies
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.
Clear, Dark Skies
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?
Clear, Dark Skies
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.
Clear, Dark Skies
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.
Clear, Dark Skies
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?
Clear, Dark Skies
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.
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".
Clear, Dark Skies
there is no difference.
Clear, Dark Skies
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.
101 Reasons why Java is better than .NET - http://helpdesk-software.ws/it/29-04-2004.htm
.NET languages.
.NET programs well
I stopped reading around #7: There has yet to be a production release of a database that supports any
MS SQL Server 2005 does this. That item is wrong.
#8 Nobody seems to know how to write
this is not even wrong, just completely content-free.
My Karma: ran over your Dogma
StrawberryFrog
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.
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.
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.
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.
about retain/release not being in libc; I seem to be confusing retain/release with allocator zones today.
Clear, Dark Skies
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.
"#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.
I'm not going to change your sheets again, Mr. Hastings.
"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.
I'm not going to change your sheets again, Mr. Hastings.
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)
.NET in that list.
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
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.
Clear, Dark Skies
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.
Clear, Dark Skies
There seems to be a lot of cross communication in this thread.
Clear, Dark Skies
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.
Good mfences make good neighbors.
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.
Clear, Dark Skies
-fred
Sign #11 of Slashdot overdose: You see the phrase 'moderate Republican' and you wonder if that would be a +1 or a -1.
...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
Sign #11 of Slashdot overdose: You see the phrase 'moderate Republican' and you wonder if that would be a +1 or a -1.
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?
-- I speak only for myself
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.)
Signature.
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.
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
'...if only "Jumping to a Conclusion" was an event in the Olympics.'
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.
Clear, Dark Skies
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.
...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 feel like it...
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.
Clear, Dark Skies