Xcode Update Gives Objective-C Garbage Collection 285
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?"
And Leopard has DTrace (Score:5, Interesting)
Well, let's say as exciting.
Why not Objective C? (Score:1, Interesting)
Re:Why not Objective C? (Score:3, Interesting)
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 is it.... (Score:3, Interesting)
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).
Garbage Collection and Apple (Score:3, Interesting)
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:NOOOOOOO #@$#$@ (Score:4, Interesting)
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.
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.
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:Your knowledge of GC is 10 years out of date (Score:4, Interesting)
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:Why not Objective C? (Score:4, Interesting)
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:Your knowledge of GC is 10 years out of date (Score:3, Interesting)
- Increment the heap pointer by N.
- Bzero those N bytes (if necessary).
- 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:NOOOOOOO #@$#$@ (Score:3, Interesting)
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:Hacks and Novices Rejoice! (Score:3, Interesting)
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:Sonny, since the effect is the same (Score:3, Interesting)
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.