Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×

Xcode Update Gives Objective-C Garbage Collection 285

Posted by timothy from the alternate-tuesdays-bin-by-curb dept.
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 More

Xcode Update Gives Objective-C Garbage Collection

Comments Filter:

  • Here's my contribution to the debate. (Score:5, Insightful)

    by mccalli ( 323026 ) on Monday August 07, 2006 @06:12PM (#15862051) Homepage
    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

    • On the other hand, I feel automatic memory management is redundant in most situations. Warm fuzzy kind of feelings.
      • 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!
      • 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
        • 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
    • 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.
      • 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

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

          Cheers,
          Ian

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

          • 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 on

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

    • 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 a

    • 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 tak

  • Technical details needed! (Score:3, Insightful)

    by Anonymous Coward on Monday August 07, 2006 @06:17PM (#15862084)
    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?

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

      • Re: (Score:3, Insightful)

        by account_deleted ( 4530225 )
        Comment removed based on user account deletion

        • 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? EJ

        • 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. L
      • 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.
    • 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 (Score:5, Interesting)

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

  • NOOOOOOO #@$#$@ (Score:4, Insightful)

    by pestilence669 ( 823950 ) on Monday August 07, 2006 @07:06PM (#15862385)
    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.

    • 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 #@$#$@ (Score:3, Insightful)

        by m874t232 ( 973431 )
        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

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

      • 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.
      • 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 #@$#$@ (Score:3, Interesting)

          by Abcd1234 ( 188840 )
          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

    • Re:NOOOOOOO #@$#$@ (Score:5, Insightful)

      by m874t232 ( 973431 ) on Monday August 07, 2006 @08:13PM (#15862789)
      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 #@$#$@ (Score:5, Informative)

      by bar-agent ( 698856 ) on Monday August 07, 2006 @09:23PM (#15863108)
      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 #@$#$@ (Score:4, Insightful)

      by grammar fascist ( 239789 ) on Tuesday August 08, 2006 @02:21AM (#15864169) Homepage
      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?
    • 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 pr

  • Garbage Collection and Apple (Score:3, Interesting)

    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".
    • 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 prog
      • ...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,

  • Apple innovates... (Score:3, Funny)

    by cortana ( 588495 ) <sam@robots[ ]g.uk ['.or' in gap]> on Monday August 07, 2006 @07:25PM (#15862492) Homepage
    -lgc
    I kid, I kid! :)
  • 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 utiliz
    • 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.

  • many people miss the point of GC (Score:3, Insightful)

    by m874t232 ( 973431 ) on Monday August 07, 2006 @08:17PM (#15862811)
    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.
  • 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 th
  • 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

  • ObjC Referencing Counting In A Nutshell (Score:3, Informative)

    by Anonymous Coward on Tuesday August 08, 2006 @02:09AM (#15864144)
    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.

Slashdot Top Deals

BLISS is ignorance.

Close