What's interesting is that in almost all cases* GC will be faster than Cocoa's retain/release method. I agree that retain/release is about as good as it gets regarding manual memory management, but there is a lot of messaging overhead with that method. When the AutoReleasePool is released, it in turn sends a release message to all the objects it contains. This can add up to a lot of messages depending on the situation. Now with something like a mark and sweep implemented in the runtime, automatic memory management can actually be faster.
That's not even remotely true.
All Cocoa objects need to get sent "dealloc," even with garbage collection, so you're still looking at a fair amount of messaging.
However, messaging is hardly any more overhead than calling a C function, particularly with Tiger's fast dispatch turned on (actually, it's 3-4x the overhead, but it's still negligible). In all of my experience, the autorelease pool has never caused any performance decrease that was either noticeable, or that showed up in Shark when there was a performance issue.
Compared to garbage collection where you're checking (hundreds of) thousands of pointer values, I don't see how a couple hundred messages is an issue. Some drawing routines have more messages than that (tables, icon views, etc...).
All Cocoa objects need to get sent "dealloc," even with garbage collection, so you're still looking at a fair amount of messaging.
However, messaging is hardly any more overhead than calling a C function, particularly with Tiger's fast dispatch turned on (actually, it's 3-4x the overhead, but it's still negligible). In all of my experience, the autorelease pool has never caused any performance decrease that was either noticeable, or that showed up in Shark when there was a performance issue.
Compared to garbage collection where you're checking (hundreds of) thousands of pointer values, I don't see how a couple hundred messages is an issue. Some drawing routines have more messages than that (tables, icon views, etc...).
Maybe you should read up a little on modern GC. Why would you need to send an object the dealloc message? The only reason those are useful today is to clean up after yourself when freeing up an object. There will be no reason to put anything in the dealloc method once the GC is taking care of it.
For many practical purposes, allocation/deallocation-intensive algorithms implemented in modern garbage collected languages can actually be faster than their equivalents using explicit memory management (at least without heroic optimizations by an expert programmer). 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.
Maybe you should read up a little on modern GC. Why would you need to send an object the dealloc message? The only reason those are useful today is to clean up after yourself when freeing up an object. There will be no reason to put anything in the dealloc method once the GC is taking care of it.
It is useful for cleaning up non-memory resources such as file handles and db connections that the GC won't do.
As I developer, I can tell that gregmightdothat is too and that you are not, so that's a pretty presumptious statement IMHO.
First, you really know what I do for a living? Interesting that you can know that about me. I guess writing C++ MFC applications for a government contractor means I'm not a developer. Man, you should really tell the company that I work for that I don't really do what they think I do.
Second, is cleaning up files and database connections the general case of deallocating most objects? That is more of a special case that can easily be handled even while using GC.
My point was that if you are comparing automatic garbage collection to the autorelease pool in Cocoa there can be benefits to automatic garbage collection. Automatic garbage collection can benefit from optimizations that manual memory management cannot. Manual reference counting does have a lot of messaging overhead involved with it. The fact that Obj-C messaging is only marginally slower than C function calls still means it is slower. I never said that automatic garbage collection will make your programs "X" times faster. My point was that objects can potentially be implicitly deallocated without needing several messages sent to them. Using the autorelease pool, you have the current situation: pool sent release message, every object in pool sent release message, objects with reference count of 0 have dealloc called, any cleanup objects are sent messages. That can add up to a lot of messaging. The fact that this doesn't cause a slowdown for you bodes well that automatic garbage collection won't cause you any difficulty either.
I don't understand the negativity towards GC. I guess it remains to be seen how exactly Apple implements it with Objective-C 2.0 and how well it will work. I'm guessing that it will work very well. YMMV.
First, you really know what I do for a living? Interesting that you can know that about me. I guess writing C++ MFC applications for a government contractor means I'm not a developer. Man, you should really tell the company that I work for that I don't really do what they think I do.
Second, is cleaning up files and database connections the general case of deallocating most objects? That is more of a special case that can easily be handled even while using GC.
My point was that if you are comparing automatic garbage collection to the autorelease pool in Cocoa there can be benefits to automatic garbage collection. Automatic garbage collection can benefit from optimizations that manual memory management cannot. Manual reference counting does have a lot of messaging overhead involved with it. The fact that Obj-C messaging is only marginally slower than C function calls still means it is slower. I never said that automatic garbage collection will make your programs "X" times faster. My point was that objects can potentially be implicitly deallocated without needing several messages sent to them. Using the autorelease pool, you have the current situation: pool sent release message, every object in pool sent release message, objects with reference count of 0 have dealloc called, any cleanup objects are sent messages. That can add up to a lot of messaging. The fact that this doesn't cause a slowdown for you bodes well that automatic garbage collection won't cause you any difficulty either.
I don't understand the negativity towards GC. I guess it remains to be seen how exactly Apple implements it with Objective-C 2.0 and how well it will work. I'm guessing that it will work very well. YMMV.
I don't have any negativity towards GC. But I've been programming enough not to expect miracles like "it to work 10x faster and do everything for you." It may not have to do as much messaging, but it has to do loads of checking through loads of memory addresses, which not only eats up instructions, but really gums up the processor's caches (and in turn, clears out any data you could have had there) and causes massive paging out to RAM.
I'm really excited for ObjC 2.0, and I'll definitely look into the GC there, but as of right now, manual reference counting is negligible in terms of performance, and pretty negligible in terms of implementation time, and, honestly, really comforting.
I think this paper may explain the difference between Mr Beardsley's position and mine.
These guys tested with Java and found that while theoretically GC is faster, in practice it does not achieve these benefits until 5 times as much memory as the program needs has been allocated.
This explains why a lot of practioners (such as myself) often observe GC as being slower (because our sysadmins don't want us allocating 1GB of heap for our 200MB data structure).
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.
Well, I am a programmer and I can tell you that the situation where there are "thousands of pointers to unreferences objects" is a situation that never should happen in the first place. You can still delete stuff manually or take care of them at a certain event in your application. You should consider garbage collection to be a "helper", not "I am now allowed to code badly cause garbage collection is going to fix it anyway".
To put it in a metaphor:
Don't create lots of garbage yourself, so the garbage collector only has two bags of garbage to throw away when he arrives :-)
I think this paper may explain the difference between Mr Beardsley's position and mine.
These guys tested with Java and found that while theoretically GC is faster, in practice it does not achieve these benefits until 5 times as much memory as the program needs has been allocated.
This explains why a lot of practioners (such as myself) often observe GC as being slower (because our sysadmins don't want us allocating 1GB of heap for our 200MB data structure).
"Comparing runtime, space consumption, and virtual memory footprints
over a range of benchmarks, we show that the runtime performance
of the best-performing garbage collector is competitive with ex-
plicit memory management when given enough memory. In par-
ticular, when garbage collection has five times as much memory
as required, its runtime performance matches or slightly exceeds
that of explicit memory management. However, garbage collec-
tion?s performance degrades substantially when it must use smaller
heaps. With three times as much memory, it runs 17% slower on
average, and with twice as much memory, it runs 70% slower. Gar-
bage collection also is more susceptible to paging when physical
memory is scarce. In such conditions, all of the garbage collectors
we examine here suffer order-of-magnitude performance penalties
relative to explicit memory management."
After reading that paper, my position is not changed at all. It would seem they worked very hard at making sure the outcome supported their hypothesis. They didn't use a better allocator which goes hand in hand with GC, they restricted testing multi-threaded GC. In fact the paper showed that under certain circumstances the GenMS garbage collector can be faster then manual memory management. The downside is that GenMS doesn't play well with small heap sizes. Their is in fact an improvement that remedies that situation.
Additionally the paper you cited compares GC to calling malloc and free. This is not the best comparison to Cocoa's reference counting. Reference counting and autorelease pools are not free.
Quote:
Originally Posted by gregmightdothat
I don't have any negativity towards GC. But I've been programming enough not to expect miracles like "it to work 10x faster and do everything for you." It may not have to do as much messaging, but it has to do loads of checking through loads of memory addresses, which not only eats up instructions, but really gums up the processor's caches (and in turn, clears out any data you could have had there) and causes massive paging out to RAM.
I'm not sure where I ever said that GC would be 10 times faster. I agree older garbage collectors did exhibit the traits you bring up. However, a huge amount of research has been done on mitigating those exact issues. Apple stands to benefit greatly on that research for its implementation of GC.
The whole reason I responded to this thread at all was statements like this:
Quote:
Originally Posted by ascii
And what's up with the Garbage Collection being added to Cocoa? Makes you ashamed to be a Mac developer.
and this:
Quote:
Originally Posted by ascii
Doesn't matter to me that it's optional. In my view Apple made all the GC-using languages look stupid when they achieved 99% of the benefit with just a few conventions. It was an example of cleverly subverting the herd, which was cool. Now they are just following it.
The whole reason they are "following the herd" is because it will make for better software. Contrary to your view that it is not "Apple-Like" to use garbage collection, it is very much in line with what Apple has done to Cocoa. Look at CoreData, Cocoa Bindings, Nib files, etc ... Apple gives developers tools that allow them to be more productive, while at the same time worrying about the implementation and speed of those tools. The Cocoa conventions are better than malloc and free, but they can still lead to fragile apps. It is very easy to have a memory leak with those conventions, and trying to message an object that has been deallocated will crash you. Getting rid of those situations is a good reason to move to GC and "follow the herd."
After reading that paper, my position is not changed at all. It would seem they worked very hard at making sure the outcome supported their hypothesis. They didn't use a better allocator which goes hand in hand with GC, they restricted testing multi-threaded GC. In fact the paper showed that under certain circumstances the GenMS garbage collector can be faster then manual memory management. The downside is that GenMS doesn't play well with small heap sizes. Their is in fact an improvement that remedies that situation.
Additionally the paper you cited compares GC to calling malloc and free. This is not the best comparison to Cocoa's reference counting. Reference counting and autorelease pools are not free.
I'm not sure where I ever said that GC would be 10 times faster. I agree older garbage collectors did exhibit the traits you bring up. However, a huge amount of research has been done on mitigating those exact issues. Apple stands to benefit greatly on that research for its implementation of GC.
The whole reason I responded to this thread at all was statements like this:
and this:
The whole reason they are "following the herd" is because it will make for better software. Contrary to your view that it is not "Apple-Like" to use garbage collection, it is very much in line with what Apple has done to Cocoa. Look at CoreData, Cocoa Bindings, Nib files, etc ... Apple gives developers tools that allow them to be more productive, while at the same time worrying about the implementation and speed of those tools. The Cocoa conventions are better than malloc and free, but they can still lead to fragile apps. It is very easy to have a memory leak with those conventions, and trying to message an object that has been deallocated will crash you. Getting rid of those situations is a good reason to move to GC and "follow the herd."
Yes, perhaps Safari, for one, will finally stop leaking, if Apple itself decides to use this.
A week ago run-webkit-tests --leaks was reporting over 4000 leaks. Today, it usually reports less than five leaks. Many leaks that were found other ways have also been fixed.
Safari does cache images of rendered web pages, and when they page out to virtual memory, it takes much, much longer to load them back than it would just to have re-rendered them in the first place, but this isn't a leak, it's a design decision that didn't work out too well.
Firefox, afaik, suffers from the same problem.
Also, most (or all?) of the leaks were in Webkit, so it wouldn't have benefitted anyway.
After reading that paper, my position is not changed at all.
Well, my position has not changed either. I've been doing commerical Java dev for 7 years and IMO garbage collection sucks. Obviously I'm not going to put someone else's oratory above my own experience.
Anyway I'm about to install Leopard. Apparently XCode 3.0 uses garbage collection itself. I wonder how long I will be coding before it mysteriously locks up for 3 seconds to garbage collect? This is the future of Mac apps, mark my words.
Well, I am a programmer and I can tell you that the situation where there are "thousands of pointers to unreferences objects" is a situation that never should happen in the first place. You can still delete stuff manually or take care of them at a certain event in your application. You should consider garbage collection to be a "helper", not "I am now allowed to code badly cause garbage collection is going to fix it anyway".
To put it in a metaphor:
Don't create lots of garbage yourself, so the garbage collector only has two bags of garbage to throw away when he arrives :-)
There aren't thousands of invalid objects, but before GC can find them, it DOES have to look through the 142,300 pointers that my app has, just at startup.
Well, my position has not changed either. I've been doing commerical Java dev for 7 years and IMO garbage collection sucks. Obviously I'm not going to put someone else's oratory above my own experience.
Anyway I'm about to install Leopard. Apparently XCode 3.0 uses garbage collection itself. I wonder how long I will be coding before it mysteriously locks up for 3 seconds to garbage collect? This is the future of Mac apps, mark my words.
Isn't that just ONE implementation of it though?
I (for my sins) spent 16 years doing commercial COBOL development, which uses garbage collection all the time and that was quite often quicker than C and a zillion times easier to write and maintain.
Agreed. ascii, the Java implementations I've worked with have pretty poor GC in general. There are decent algorithms out there, but of course, everything is a tradeoff.
Of course, the worst sin of Java's GC, IMO, is convincing developers that they never have to think about memory management at all, leading to really horrible pathological cases.
I (for my sins) spent 16 years doing commercial COBOL development, which uses garbage collection all the time and that was quite often quicker than C and a zillion times easier to write and maintain.
It's possible Apple could do a better implementation I suppose, but Java is a very mature technology now, so I'd be surprised if Apple can beat it right off the bat.
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?
Agreed. ascii, the Java implementations I've worked with have pretty poor GC in general. There are decent algorithms out there, but of course, everything is a tradeoff.
Of course, the worst sin of Java's GC, IMO, is convincing developers that they never have to think about memory management at all, leading to really horrible pathological cases.
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.
Comments
What's interesting is that in almost all cases* GC will be faster than Cocoa's retain/release method. I agree that retain/release is about as good as it gets regarding manual memory management, but there is a lot of messaging overhead with that method. When the AutoReleasePool is released, it in turn sends a release message to all the objects it contains. This can add up to a lot of messages depending on the situation. Now with something like a mark and sweep implemented in the runtime, automatic memory management can actually be faster.
That's not even remotely true.
All Cocoa objects need to get sent "dealloc," even with garbage collection, so you're still looking at a fair amount of messaging.
However, messaging is hardly any more overhead than calling a C function, particularly with Tiger's fast dispatch turned on (actually, it's 3-4x the overhead, but it's still negligible). In all of my experience, the autorelease pool has never caused any performance decrease that was either noticeable, or that showed up in Shark when there was a performance issue.
Compared to garbage collection where you're checking (hundreds of) thousands of pointer values, I don't see how a couple hundred messages is an issue. Some drawing routines have more messages than that (tables, icon views, etc...).
That's not even remotely true.
All Cocoa objects need to get sent "dealloc," even with garbage collection, so you're still looking at a fair amount of messaging.
However, messaging is hardly any more overhead than calling a C function, particularly with Tiger's fast dispatch turned on (actually, it's 3-4x the overhead, but it's still negligible). In all of my experience, the autorelease pool has never caused any performance decrease that was either noticeable, or that showed up in Shark when there was a performance issue.
Compared to garbage collection where you're checking (hundreds of) thousands of pointer values, I don't see how a couple hundred messages is an issue. Some drawing routines have more messages than that (tables, icon views, etc...).
Maybe you should read up a little on modern GC.
http://www.iecc.com/gclist/GC-faq.html
For many practical purposes, allocation/deallocation-intensive algorithms implemented in modern garbage collected languages can actually be faster than their equivalents using explicit memory management (at least without heroic optimizations by an expert programmer). 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.
Why would you need to send an object the dealloc message?
It is useful for cleaning up non-memory resources such as file handles and db connections that the GC won't do.
Maybe you should read up a little on modern GC.
As I developer, I can tell that gregmightdothat is too and that you are not, so that's a pretty presumptious statement IMHO.
Maybe you should read up a little on modern GC.
http://www.iecc.com/gclist/GC-faq.html
That quote, which isn't from that FAQ but from Wikipedia, has dubious assertion written all over it.
Literally.
It is useful for cleaning up non-memory resources such as file handles and db connections that the GC won't do.
As I developer, I can tell that gregmightdothat is too and that you are not, so that's a pretty presumptious statement IMHO.
First, you really know what I do for a living? Interesting that you can know that about me. I guess writing C++ MFC applications for a government contractor means I'm not a developer. Man, you should really tell the company that I work for that I don't really do what they think I do.
Second, is cleaning up files and database connections the general case of deallocating most objects? That is more of a special case that can easily be handled even while using GC.
My point was that if you are comparing automatic garbage collection to the autorelease pool in Cocoa there can be benefits to automatic garbage collection. Automatic garbage collection can benefit from optimizations that manual memory management cannot. Manual reference counting does have a lot of messaging overhead involved with it. The fact that Obj-C messaging is only marginally slower than C function calls still means it is slower. I never said that automatic garbage collection will make your programs "X" times faster. My point was that objects can potentially be implicitly deallocated without needing several messages sent to them. Using the autorelease pool, you have the current situation: pool sent release message, every object in pool sent release message, objects with reference count of 0 have dealloc called, any cleanup objects are sent messages. That can add up to a lot of messaging. The fact that this doesn't cause a slowdown for you bodes well that automatic garbage collection won't cause you any difficulty either.
I don't understand the negativity towards GC. I guess it remains to be seen how exactly Apple implements it with Objective-C 2.0 and how well it will work. I'm guessing that it will work very well. YMMV.
First, you really know what I do for a living? Interesting that you can know that about me. I guess writing C++ MFC applications for a government contractor means I'm not a developer. Man, you should really tell the company that I work for that I don't really do what they think I do.
Second, is cleaning up files and database connections the general case of deallocating most objects? That is more of a special case that can easily be handled even while using GC.
My point was that if you are comparing automatic garbage collection to the autorelease pool in Cocoa there can be benefits to automatic garbage collection. Automatic garbage collection can benefit from optimizations that manual memory management cannot. Manual reference counting does have a lot of messaging overhead involved with it. The fact that Obj-C messaging is only marginally slower than C function calls still means it is slower. I never said that automatic garbage collection will make your programs "X" times faster. My point was that objects can potentially be implicitly deallocated without needing several messages sent to them. Using the autorelease pool, you have the current situation: pool sent release message, every object in pool sent release message, objects with reference count of 0 have dealloc called, any cleanup objects are sent messages. That can add up to a lot of messaging. The fact that this doesn't cause a slowdown for you bodes well that automatic garbage collection won't cause you any difficulty either.
I don't understand the negativity towards GC. I guess it remains to be seen how exactly Apple implements it with Objective-C 2.0 and how well it will work. I'm guessing that it will work very well. YMMV.
I don't have any negativity towards GC. But I've been programming enough not to expect miracles like "it to work 10x faster and do everything for you." It may not have to do as much messaging, but it has to do loads of checking through loads of memory addresses, which not only eats up instructions, but really gums up the processor's caches (and in turn, clears out any data you could have had there) and causes massive paging out to RAM.
I'm really excited for ObjC 2.0, and I'll definitely look into the GC there, but as of right now, manual reference counting is negligible in terms of performance, and pretty negligible in terms of implementation time, and, honestly, really comforting.
These guys tested with Java and found that while theoretically GC is faster, in practice it does not achieve these benefits until 5 times as much memory as the program needs has been allocated.
This explains why a lot of practioners (such as myself) often observe GC as being slower (because our sysadmins don't want us allocating 1GB of heap for our 200MB data structure).
http://www-cs.canisius.edu/~hertzm/g...opsla-2005.pdf
"Comparing runtime, space consumption, and virtual memory footprints
over a range of benchmarks, we show that the runtime performance
of the best-performing garbage collector is competitive with ex-
plicit memory management when given enough memory. In par-
ticular, when garbage collection has five times as much memory
as required, its runtime performance matches or slightly exceeds
that of explicit memory management. However, garbage collec-
tion?s performance degrades substantially when it must use smaller
heaps. With three times as much memory, it runs 17% slower on
average, and with twice as much memory, it runs 70% slower. Gar-
bage collection also is more susceptible to paging when physical
memory is scarce. In such conditions, all of the garbage collectors
we examine here suffer order-of-magnitude performance penalties
relative to explicit memory management."
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.
Well, I am a programmer and I can tell you that the situation where there are "thousands of pointers to unreferences objects" is a situation that never should happen in the first place. You can still delete stuff manually or take care of them at a certain event in your application. You should consider garbage collection to be a "helper", not "I am now allowed to code badly cause garbage collection is going to fix it anyway".
To put it in a metaphor:
Don't create lots of garbage yourself, so the garbage collector only has two bags of garbage to throw away when he arrives :-)
#1. Will it be faster than OS 10.4?
#2. Will it at least be as fast as my OS 9 was (these new bloated OS's = slooooooooow)?
LOL! Hey... wishful thinking over here.
I think this paper may explain the difference between Mr Beardsley's position and mine.
These guys tested with Java and found that while theoretically GC is faster, in practice it does not achieve these benefits until 5 times as much memory as the program needs has been allocated.
This explains why a lot of practioners (such as myself) often observe GC as being slower (because our sysadmins don't want us allocating 1GB of heap for our 200MB data structure).
http://www-cs.canisius.edu/~hertzm/g...opsla-2005.pdf
"Comparing runtime, space consumption, and virtual memory footprints
over a range of benchmarks, we show that the runtime performance
of the best-performing garbage collector is competitive with ex-
plicit memory management when given enough memory. In par-
ticular, when garbage collection has five times as much memory
as required, its runtime performance matches or slightly exceeds
that of explicit memory management. However, garbage collec-
tion?s performance degrades substantially when it must use smaller
heaps. With three times as much memory, it runs 17% slower on
average, and with twice as much memory, it runs 70% slower. Gar-
bage collection also is more susceptible to paging when physical
memory is scarce. In such conditions, all of the garbage collectors
we examine here suffer order-of-magnitude performance penalties
relative to explicit memory management."
After reading that paper, my position is not changed at all. It would seem they worked very hard at making sure the outcome supported their hypothesis. They didn't use a better allocator which goes hand in hand with GC, they restricted testing multi-threaded GC. In fact the paper showed that under certain circumstances the GenMS garbage collector can be faster then manual memory management. The downside is that GenMS doesn't play well with small heap sizes. Their is in fact an improvement that remedies that situation.
http://www.cs.umass.edu/~emery/pubs/04-16.pdf
Additionally the paper you cited compares GC to calling malloc and free. This is not the best comparison to Cocoa's reference counting. Reference counting and autorelease pools are not free.
I don't have any negativity towards GC. But I've been programming enough not to expect miracles like "it to work 10x faster and do everything for you." It may not have to do as much messaging, but it has to do loads of checking through loads of memory addresses, which not only eats up instructions, but really gums up the processor's caches (and in turn, clears out any data you could have had there) and causes massive paging out to RAM.
I'm not sure where I ever said that GC would be 10 times faster. I agree older garbage collectors did exhibit the traits you bring up. However, a huge amount of research has been done on mitigating those exact issues. Apple stands to benefit greatly on that research for its implementation of GC.
The whole reason I responded to this thread at all was statements like this:
And what's up with the Garbage Collection being added to Cocoa? Makes you ashamed to be a Mac developer.
and this:
Doesn't matter to me that it's optional. In my view Apple made all the GC-using languages look stupid when they achieved 99% of the benefit with just a few conventions. It was an example of cleverly subverting the herd, which was cool. Now they are just following it.
The whole reason they are "following the herd" is because it will make for better software. Contrary to your view that it is not "Apple-Like" to use garbage collection, it is very much in line with what Apple has done to Cocoa. Look at CoreData, Cocoa Bindings, Nib files, etc ... Apple gives developers tools that allow them to be more productive, while at the same time worrying about the implementation and speed of those tools. The Cocoa conventions are better than malloc and free, but they can still lead to fragile apps. It is very easy to have a memory leak with those conventions, and trying to message an object that has been deallocated will crash you. Getting rid of those situations is a good reason to move to GC and "follow the herd."
After reading that paper, my position is not changed at all. It would seem they worked very hard at making sure the outcome supported their hypothesis. They didn't use a better allocator which goes hand in hand with GC, they restricted testing multi-threaded GC. In fact the paper showed that under certain circumstances the GenMS garbage collector can be faster then manual memory management. The downside is that GenMS doesn't play well with small heap sizes. Their is in fact an improvement that remedies that situation.
http://www.cs.umass.edu/~emery/pubs/04-16.pdf
Additionally the paper you cited compares GC to calling malloc and free. This is not the best comparison to Cocoa's reference counting. Reference counting and autorelease pools are not free.
I'm not sure where I ever said that GC would be 10 times faster. I agree older garbage collectors did exhibit the traits you bring up. However, a huge amount of research has been done on mitigating those exact issues. Apple stands to benefit greatly on that research for its implementation of GC.
The whole reason I responded to this thread at all was statements like this:
and this:
The whole reason they are "following the herd" is because it will make for better software. Contrary to your view that it is not "Apple-Like" to use garbage collection, it is very much in line with what Apple has done to Cocoa. Look at CoreData, Cocoa Bindings, Nib files, etc ... Apple gives developers tools that allow them to be more productive, while at the same time worrying about the implementation and speed of those tools. The Cocoa conventions are better than malloc and free, but they can still lead to fragile apps. It is very easy to have a memory leak with those conventions, and trying to message an object that has been deallocated will crash you. Getting rid of those situations is a good reason to move to GC and "follow the herd."
Yes, perhaps Safari, for one, will finally stop leaking, if Apple itself decides to use this.
Yes, perhaps Safari, for one, will finally stop leaking, if Apple itself decides to use this.
Safari's leaks were fixed over a year ago.
from Sept. 1, 2005
A week ago run-webkit-tests --leaks was reporting over 4000 leaks. Today, it usually reports less than five leaks. Many leaks that were found other ways have also been fixed.
Safari does cache images of rendered web pages, and when they page out to virtual memory, it takes much, much longer to load them back than it would just to have re-rendered them in the first place, but this isn't a leak, it's a design decision that didn't work out too well.
Firefox, afaik, suffers from the same problem.
Also, most (or all?) of the leaks were in Webkit, so it wouldn't have benefitted anyway.
After reading that paper, my position is not changed at all.
Well, my position has not changed either. I've been doing commerical Java dev for 7 years and IMO garbage collection sucks. Obviously I'm not going to put someone else's oratory above my own experience.
Anyway I'm about to install Leopard. Apparently XCode 3.0 uses garbage collection itself. I wonder how long I will be coding before it mysteriously locks up for 3 seconds to garbage collect? This is the future of Mac apps, mark my words.
Well, I am a programmer and I can tell you that the situation where there are "thousands of pointers to unreferences objects" is a situation that never should happen in the first place. You can still delete stuff manually or take care of them at a certain event in your application. You should consider garbage collection to be a "helper", not "I am now allowed to code badly cause garbage collection is going to fix it anyway".
To put it in a metaphor:
Don't create lots of garbage yourself, so the garbage collector only has two bags of garbage to throw away when he arrives :-)
There aren't thousands of invalid objects, but before GC can find them, it DOES have to look through the 142,300 pointers that my app has, just at startup.
Well, my position has not changed either. I've been doing commerical Java dev for 7 years and IMO garbage collection sucks. Obviously I'm not going to put someone else's oratory above my own experience.
Anyway I'm about to install Leopard. Apparently XCode 3.0 uses garbage collection itself. I wonder how long I will be coding before it mysteriously locks up for 3 seconds to garbage collect? This is the future of Mac apps, mark my words.
Isn't that just ONE implementation of it though?
I (for my sins) spent 16 years doing commercial COBOL development, which uses garbage collection all the time and that was quite often quicker than C and a zillion times easier to write and maintain.
Of course, the worst sin of Java's GC, IMO, is convincing developers that they never have to think about memory management at all, leading to really horrible pathological cases.
Isn't that just ONE implementation of it though?
I (for my sins) spent 16 years doing commercial COBOL development, which uses garbage collection all the time and that was quite often quicker than C and a zillion times easier to write and maintain.
It's possible Apple could do a better implementation I suppose, but Java is a very mature technology now, so I'd be surprised if Apple can beat it right off the bat.
Is the Sun JVM still using mark/sweep? Or did they finally upgrade to something a little more modern like boxcar?
Agreed. ascii, the Java implementations I've worked with have pretty poor GC in general. There are decent algorithms out there, but of course, everything is a tradeoff.
Of course, the worst sin of Java's GC, IMO, is convincing developers that they never have to think about memory management at all, leading to really horrible pathological cases.
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.