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?"
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
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?
What's the new architecture it runs on?
As far as I can see it's still a Cocoa app, so while it's certainly possible (we know the Next frameworks would run on top of multiple kernels) it is unlikely unless Apple decided to open up the layers above Darwin (unlikely). Alternatively, resource could be put into the GnuStep project, but overall there seems very little interest in it. (The non-Apple Obj-C community is tiny).
DTrace is currently only on Solaris and BSD (at least last I knew).
I'd imagine there would be more hope in a project to add similar features to Eclipse, where you may at least encounter a pool of developer motivation (including Mac developers who don't want to work with XCode).
'Capitalists of the world, unite! Oh
Let me be the first to welcome our new garbage collecting Overlords.
I love Objective-C and Apple (NeXT) API's. However, while garbage collection does make it "easier" to write software, I have GREAT fears about people not leaning to clean up after themselves.
Case in point was a University project I did involving robots. Everyone happy sets about coding there little robots in Java, write some simulators, then write the actual robots logic, all in wonderful cross platform Java. Que 100 students pondering why real thing ran for 20seconds then started beeping at them. I spent a LONG time trying to explain to people that with 64k of memory, and NO garbage collection (yey "special" Java) you cannot just keep creating temporary objects at will and hoping mummy will clean up.
I think its super that Apple will be even easier to write for, but please make sure your know how to clean up after yourself before you start coding, you never know when silicon mummy will be on holiday.
NB. Not sure I mean "easier" to write software, maybe "allows you to write with a little more of your brain unplugged".
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.
I once had a signature.
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.
- 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.
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.
This isn't a C versus Java discussion - it's Objective-C versus Objective-C with GC discussion, so your point is completely irrelevant as both OC with and without GC have stack allocation.
That said, *yes* stack variables allow a certain amount of programmer optimisation not explictly available to Java programmers, *but* that is all optimisation that the JVM can do via escape analysis (but you knew that, didn't you?). What's more, that kind of analysis can allow a JVM to optimise values onto the stack depending on usage - something not at all possible with C's ahead-of-time compiler.
Uhh, the effect isn't the same. A memory leak results in memory regions that are no longer available to the program, because the reference to the original region is gone. Thus, the memory can no longer be reclaimed. Clearly, that's not the case in the situation you described. You said yourself that the GC eventually reclaimed the memory... it just didn't do it when you wanted.
Oh, and BTW, your use of "sonny" is unsurprising, given your last experience with the Java GC was version 1.2. Maybe try updating your experiences and try again.