That's true. At least when you have to manage it yourself you are forced to think about the fact that you just allocated and deallocated 10,000 Strings in a tight loop!
That's what's so good about Cocoa's (current) approach. Far less work than fully manual management, but at the same time you still have to think about it. There are some things it's good not to eliminate human thought.
Even with a language that's had GC from the very beginning, you still have to think about what you're allocating and how you're passing data around and how persistent it needs to be. GC is a programmers productivity AID not an excuse to write bad code.
Bingo. I've gone around with John Siracusa on this (hi John! ), and basically, it boils down to whether the GC is:
1) Mandatory
2) Efficient
3) Default
Mandatory is just a horrible way to do things. (Managed code anyone?) It tries to be everything to everyone, and it's just not a good tactic to take, because of the next item...
How efficient the system is can vary wildly - some GC approaches are *worse* than even a very simple semi-automatic approach such as autopools, used naively. Worse still, every algorithm has pathological boundary cases that will cause it to choke. Even worse, those seem to keep popping up in common code people want to write... \
Whether the GC is default or not is really more of a matter of taste - given that Obj-C already requires manual use of autopools, I suspect that GC in Obj-C2.0 may be on by default, off for debugging. On to catch the leaks from pools that otherwise slip through the cracks, off to let you *find* the bloody leaks.
I've left the "ZOMG!!1!!! GC in Obj-C will suck!" camp, as long as they provide a reasonably efficient and modern algorithm, and it can be bypassed at will for more fine-control management when necessary.
I've left the "ZOMG!!1!!! GC in Obj-C will suck!" camp, as long as they provide a reasonably efficient and modern algorithm, and it can be bypassed at will for more fine-control management when necessary.
Well I'm going through a definite "worse is better" phase so I'll stay in the ZOMG camp for now.
It has a few years behind it, but that doesn't mean it's evolved much. Once an implementation gets relied on for certain behaviour, that implementation is locked in to mimicking that behaviour, regardless of the appropriateness of it. Sometimes a clean start gives a huge advantage, because a few years of progress can be adopted en masse instead of carefully rolled in over the course of years.
Is the Sun JVM still using mark/sweep? Or did they finally upgrade to something a little more modern like boxcar?
I don't think that in the forseeable future, there will ever be a "mature" computer technology, or for most other technologies either. Perhaps a particular expression of a technology will become mature, but that's about it.
We tend to call something mature on our time scale, but we are always going to be in the most primitive part of the curve, no matter how advanced, or mature we may think it is.
Switching GC on makes all retain/release messages nops, so it's essentially mandatory. Though I think it's still possible to do manual alloc/dealloc in some way. It may be advantageous to be able to fall back to manual memory management in certain situations, but I'm pretty sure those situations are going to be a lot less common than some of you think.
I think Cocoa's current solution of using autorelease and tying it in with the application event loop was a stroke of genius. Imagine the kind of mental leap someone had to make to bring the event loop in to a discussion of memory management. On the face they seem totally unrelated, and yet in hindsight it is perfect.
Generational garbage collector sort objects in several age categories: young, older, very old and concentrate their search of unreachable ones in the youngsters, based on the idea that the longer an object has been reachable, the longer it is likely to be reachable. No great leap of imagination is required to tie that into the event loop either.
Quote:
Originally Posted by ascii
Autorelease is a good middle ground between completely manual reference counting and completely automatic memory management, with it's wasteful walking through thousands of pointers to find unreferenced objects. IMO, they already have the best solution out there, and they (not me) are the ones being purist by going to a fully automatic model.
Except that if one has dependency cycles, reference counting will result in memory leaks. And any complex application is likely to have dependency cycles. There is nothing wrong about that from a design perspective but the memory management technique implemented in current Cocoa is too weak to handle that?
Don't get me wrong: the current system is cute and useful in practice but it does not scale very well to large complex applications compared to a proper garbage collector.
Generational garbage collector sort objects in several age categories: young, older, very old and concentrate their search of unreachable ones in the youngsters, based on the idea that the longer an object has been reachable, the longer it is likely to be reachable. No great leap of imagination is required to tie that into the event loop either.
Except that if one has dependency cycles, reference counting will result in memory leaks. And any complex application is likely to have dependency cycles. There is nothing wrong about that from a design perspective but the memory management technique implemented in current Cocoa is too weak to handle that?
Don't get me wrong: the current system is cute and useful in practice but it does not scale very well to large complex applications compared to a proper garbage collector.
What is a "dependency cycle"?
Google and Wikipedia don't seem to know anything.
(As a side note, what kind of "large complex app" uses a garbage collector? My understanding is that garbage collection is only useful for really tiny apps that won't be running for long since garbage collection itself fails to pick up all leaks.)
Object A has a reference to B, but B has a reference to A, in their own little island. Neither object's count will ever hit zero without external intervention, so they'll never be scavenged. ie, leak.
Object A has a reference to B, but B has a reference to A, in their own little island. Neither object's count will ever hit zero without external intervention, so they'll never be scavenged. ie, leak.
Ah. Does anyone ever come across that? And does garbage collection catch it?
Even with an admittedly half-assed implementation of MVC, I think I've come across that once, and not in a class I've actually programmed yet, so I don't even know if it'll be an issue.
Happens all the time, GC can't do squat about it with simple reference counting, and the only way to work around it in such cases is to manually step in and break the cycle. ie, you have to manage your objects anyway, just not consistently. Whee!
Now, there are other GC algorithms, such as the boxcar I mentioned above, that can catch orphaned cycles, but I'm not sure that any common JVM uses such an algorithm. I mean, that one is *only* six or seven years old...
What I would like to see is in the Save File dialogs the option to include Spotlight keywords and to select a label color. So it becomes a 1-step process instead of a 2 to 3-step process.
I'm with you. I often need to save Mail attachments I receive, and then to add a lable color to them. Actually, I have the same need in reverse. Send them, and then go back and change the label color. Or, closer to what you're suggesting, after I work with a document in Word, I go in and change its label color. Perhaps the ideal would give a 1-step process incorporating label color changes everywhere.
Yes...Apple needs to allow developers to add metadata fields right into the save dialog box/sheet.
Right now, developers have to create their own UI to allow users to add Spotlight metadata to a file...which is ok but there needs to be a way to add it via the save dialog box.
And I agree with the color tag...Apple should allow the color tagging to be done on save.
Comments
That's true. At least when you have to manage it yourself you are forced to think about the fact that you just allocated and deallocated 10,000 Strings in a tight loop!
That's what's so good about Cocoa's (current) approach. Far less work than fully manual management, but at the same time you still have to think about it. There are some things it's good not to eliminate human thought.
Even with a language that's had GC from the very beginning, you still have to think about what you're allocating and how you're passing data around and how persistent it needs to be. GC is a programmers productivity AID not an excuse to write bad code.
1) Mandatory
2) Efficient
3) Default
Mandatory is just a horrible way to do things. (Managed code anyone?) It tries to be everything to everyone, and it's just not a good tactic to take, because of the next item...
How efficient the system is can vary wildly - some GC approaches are *worse* than even a very simple semi-automatic approach such as autopools, used naively. Worse still, every algorithm has pathological boundary cases that will cause it to choke. Even worse, those seem to keep popping up in common code people want to write...
Whether the GC is default or not is really more of a matter of taste - given that Obj-C already requires manual use of autopools, I suspect that GC in Obj-C2.0 may be on by default, off for debugging. On to catch the leaks from pools that otherwise slip through the cracks, off to let you *find* the bloody leaks.
I've left the "ZOMG!!1!!! GC in Obj-C will suck!" camp, as long as they provide a reasonably efficient and modern algorithm, and it can be bypassed at will for more fine-control management when necessary.
I've left the "ZOMG!!1!!! GC in Obj-C will suck!" camp, as long as they provide a reasonably efficient and modern algorithm, and it can be bypassed at will for more fine-control management when necessary.
Well I'm going through a definite "worse is better" phase so I'll stay in the ZOMG camp for now.
It has a few years behind it, but that doesn't mean it's evolved much. Once an implementation gets relied on for certain behaviour, that implementation is locked in to mimicking that behaviour, regardless of the appropriateness of it. Sometimes a clean start gives a huge advantage, because a few years of progress can be adopted en masse instead of carefully rolled in over the course of years.
Is the Sun JVM still using mark/sweep? Or did they finally upgrade to something a little more modern like boxcar?
I don't think that in the forseeable future, there will ever be a "mature" computer technology, or for most other technologies either. Perhaps a particular expression of a technology will become mature, but that's about it.
We tend to call something mature on our time scale, but we are always going to be in the most primitive part of the curve, no matter how advanced, or mature we may think it is.
I think Cocoa's current solution of using autorelease and tying it in with the application event loop was a stroke of genius. Imagine the kind of mental leap someone had to make to bring the event loop in to a discussion of memory management. On the face they seem totally unrelated, and yet in hindsight it is perfect.
Generational garbage collector sort objects in several age categories: young, older, very old and concentrate their search of unreachable ones in the youngsters, based on the idea that the longer an object has been reachable, the longer it is likely to be reachable. No great leap of imagination is required to tie that into the event loop either.
Autorelease is a good middle ground between completely manual reference counting and completely automatic memory management, with it's wasteful walking through thousands of pointers to find unreferenced objects. IMO, they already have the best solution out there, and they (not me) are the ones being purist by going to a fully automatic model.
Except that if one has dependency cycles, reference counting will result in memory leaks. And any complex application is likely to have dependency cycles. There is nothing wrong about that from a design perspective but the memory management technique implemented in current Cocoa is too weak to handle that?
Don't get me wrong: the current system is cute and useful in practice but it does not scale very well to large complex applications compared to a proper garbage collector.
Check out those 512px icons: http://img130.imageshack.us/my.php?i...icture2xj1.png
There is some more info and screen shots of leopard 9A283 on the Aeroxp forum, http://www.aeroxp.org/board/index.php?showtopic=6301
Check out those 512px icons: http://img130.imageshack.us/my.php?i...icture2xj1.png
The new features look awesome. The grammar checker will be particularly useful.
Generational garbage collector sort objects in several age categories: young, older, very old and concentrate their search of unreachable ones in the youngsters, based on the idea that the longer an object has been reachable, the longer it is likely to be reachable. No great leap of imagination is required to tie that into the event loop either.
Except that if one has dependency cycles, reference counting will result in memory leaks. And any complex application is likely to have dependency cycles. There is nothing wrong about that from a design perspective but the memory management technique implemented in current Cocoa is too weak to handle that?
Don't get me wrong: the current system is cute and useful in practice but it does not scale very well to large complex applications compared to a proper garbage collector.
What is a "dependency cycle"?
Google and Wikipedia don't seem to know anything.
(As a side note, what kind of "large complex app" uses a garbage collector? My understanding is that garbage collection is only useful for really tiny apps that won't be running for long since garbage collection itself fails to pick up all leaks.)
Object A has a reference to B, but B has a reference to A, in their own little island. Neither object's count will ever hit zero without external intervention, so they'll never be scavenged. ie, leak.
Ah. Does anyone ever come across that? And does garbage collection catch it?
Even with an admittedly half-assed implementation of MVC, I think I've come across that once, and not in a class I've actually programmed yet, so I don't even know if it'll be an issue.
While problematic, it seems easy to work around.
Now, there are other GC algorithms, such as the boxcar I mentioned above, that can catch orphaned cycles, but I'm not sure that any common JVM uses such an algorithm. I mean, that one is *only* six or seven years old...
What I would like to see is in the Save File dialogs the option to include Spotlight keywords and to select a label color. So it becomes a 1-step process instead of a 2 to 3-step process.
I'm with you. I often need to save Mail attachments I receive, and then to add a lable color to them. Actually, I have the same need in reverse. Send them, and then go back and change the label color. Or, closer to what you're suggesting, after I work with a document in Word, I go in and change its label color. Perhaps the ideal would give a 1-step process incorporating label color changes everywhere.
Right now, developers have to create their own UI to allow users to add Spotlight metadata to a file...which is ok but there needs to be a way to add it via the save dialog box.
And I agree with the color tag...Apple should allow the color tagging to be done on save.