Slashdot is powered by your submissions, so send in your scoop


Forgot your password?

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?"
This discussion has been archived. No new comments can be posted.

Xcode Update Gives Objective-C Garbage Collection

Comments Filter:
  • by SuperKendall ( 25149 ) on Monday August 07, 2006 @06:28PM (#15862154)
    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.
  • Why not Objective C? (Score:1, Interesting)

    by Anonymous Coward on Monday August 07, 2006 @06:32PM (#15862183)
    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?
  • by JulesLt ( 909417 ) on Monday August 07, 2006 @07:05PM (#15862381)
    >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 is it.... (Score:3, Interesting)

    by JulesLt ( 909417 ) on Monday August 07, 2006 @07:11PM (#15862410)
    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).
  • by beswicks ( 584636 ) on Monday August 07, 2006 @07:13PM (#15862419)
    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:NOOOOOOO #@$#$@ (Score:4, Interesting)

    by pikine ( 771084 ) on Monday August 07, 2006 @08:11PM (#15862782) Journal
    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.

  • by CoughDropAddict ( 40792 ) on Monday August 07, 2006 @08:27PM (#15862863) Homepage
    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.
  • by Novajo ( 177012 ) on Monday August 07, 2006 @08:52PM (#15862977) Homepage

    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.

  • by feijai ( 898706 ) on Monday August 07, 2006 @10:38PM (#15863422)
    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:NOOOOOOO #@$#$@ (Score:3, Interesting)

    by Abcd1234 ( 188840 ) on Monday August 07, 2006 @11:06PM (#15863524) Homepage
    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.
  • by kaffiene ( 38781 ) on Tuesday August 08, 2006 @08:31AM (#15865027)
    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.

  • by Abcd1234 ( 188840 ) on Tuesday August 08, 2006 @11:45AM (#15866626) Homepage
    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.

"Oh my! An `inflammatory attitude' in alt.flame? Never heard of such a thing..." -- Allen Gwinn, allen@sulaco.Sigma.COM