Garbage Collection cnfirmed for Leopard
I was just reading John Siracussa's Fat Bits blog and it appears the garbage collection is going to be added to Objective-C in Leopard:
http://arstechnica.com/staff/fatbits.ars/2006/5/6/3868
He wrote in a previous series how Apple's inability to add automatic memory management to Cocoa like Microsoft has with .Net was a serious issue. He compared it to the situation Apple put themselves in by not adding protective memory in their previous operating system.
http://arstechnica.com/staff/fatbits.ars/2006/5/6/3868
He wrote in a previous series how Apple's inability to add automatic memory management to Cocoa like Microsoft has with .Net was a serious issue. He compared it to the situation Apple put themselves in by not adding protective memory in their previous operating system.
Comments
http://forums.appleinsider.com/showt...threadid=57971
Originally posted by Kickaha
This might help...
http://forums.appleinsider.com/showt...threadid=57971
Ah, thanks. Much clearer now.
Is this garbage collection going to be implemented automatically for all applications or are developers going to have to turn it on inside their application themselves?
Java has a very inflexible GC system, and it is quite irksome to some people. Microsoft made the GC system much more controllable flexible with .Net, and I think they have a pretty good system. Hopefully Apple has been watching the development of Managed C++ (This seems the most similar to the current situation with adding GC to a language that didn't already have it.) and will take the good parts of that system and avoid the bad.
Is this gonna make lazier programmers? I mean, Safari is the leakiest sonovabitch I've ever seen. Even the nightlies which have seemlingly been rewritten twice over are leaking worse than ever. I don't even think garbage collection can save Safari...and even if it did, I'd be dismayed to think that Safari team wasn't able to plug the holes and don't feel like plugging them anymore.
I would imagine it would have no impact on WebKit because that is written in C++, and is not really Cocoa. As far as lazier deveoplers: Yes,l I imagine some folks will be able to churn out some crappy software, but that is already the case today. The folks who right good apps now will certainly be able to use GC to their advantage.
Originally posted by Mr Beardsley
Depending on how they implement Garbage Collection, it can be a very good thing. Having the safety of knowing that your app won't leak memory is a good thing. However, there will be a performance hit for letting the machine handle memory for you. Now for 99% of code this will not be a problem, and will be a big win. The question is how easy will it be to drop down into manual memory management in those areas of an app that need the speed of a manual system.
Java has a very inflexible GC system, and it is quite irksome to some people. Microsoft made the GC system much more controllable flexible with .Net, and I think they have a pretty good system. Hopefully Apple has been watching the development of Managed C++ (This seems the most similar to the current situation with adding GC to a language that didn't already have it.) and will take the good parts of that system and avoid the bad.
I would imagine it would have no impact on WebKit because that is written in C++, and is not really Cocoa. As far as lazier deveoplers: Yes,l I imagine some folks will be able to churn out some crappy software, but that is already the case today. The folks who right good apps now will certainly be able to use GC to their advantage.
Well considering they rewrote large portions of the renderer (which is indeed C++ [or C?]) I'd be surprised the actual core is leaking...I'm guessing it's probably Safari itself that leaks not WebCore.
Originally posted by kim kap sol
Well considering they rewrote large portions of the renderer (which is indeed C++ [or C?]) I'd be surprised the actual core is leaking...I'm guessing it's probably Safari itself that leaks not WebCore.
I think it was the actual core because dasboard suffered from the same problem, and there is no Cocoa in dasboard widgets. (Well not most of them. )
Safari is slower than my grandma when you get to have more than a few pages open. WTF. Same can be said for Firefox though. Haven't tested any other browsers with this load. Maybe I'll look in to Opera 9...it's looking damn fine these days.
Originally posted by Aquatic
Eh whatever, all I can say is I have 30 or 40 pages in Safari open now and it's brought my 867mhz PBG4 12" to its KNEES. And I have 640 RAM, and gigs of space open on my drive for paging if it needs it. Which you'd think it shouldn't with gobs of RAM like that.
Safari is slower than my grandma when you get to have more than a few pages open. WTF. Same can be said for Firefox though. Haven't tested any other browsers with this load. Maybe I'll look in to Opera 9...it's looking damn fine these days.
That's because both Safari and Firefox aggressively cache every page open (and in your history). The WebKit team purged almost all of the leaks, but this was an intentional design decision in each browser that clearly needs tweaking.
Originally posted by Michael_Moriarty
I am not much of a application developer so how important of a feature is garbage collection?
It depnds on what language you're using.
Objective-C (Cocoa) already has a phenomenal memory management system, although it's slightly more work than garbage collection.
C/C++ doesn't have any memory management built in, so it's incredibly tedious.
Originally posted by gregmightdothat
It depnds on what language you're using.
Objective-C (Cocoa) already has a phenomenal memory management system, although it's slightly more work than garbage collection.
C/C++ doesn't have any memory management built in, so it's incredibly tedious.
Yea, Obj-C's retain/release system is nicer then malloc()/free(). But, in some instances you have to do things like double release, especially if you make copies of mutable objects or arrays since the retaincounts in the copied objects are not reset to 1. This has something to do with shallow vs. deep copying but I haven't delved into it too much other then to kill my mem leaks.
Originally posted by PBG4 Dude
Yea, Obj-C's retain/release system is nicer then malloc()/free(). But, in some instances you have to do things like double release, especially if you make copies of mutable objects or arrays since the retaincounts in the copied objects are not reset to 1. This has something to do with shallow vs. deep copying but I haven't delved into it too much other then to kill my mem leaks.
Are you sure? I've never actually checked it, but the docs imply that "copyWithZone:" returns an object with a retain count of 1.
Copying an array will also retain every object in that array, but they'll get released again when the copy is released, so it evens out.
If you're double releasing something, you might be fixing a leak sloppily by adding an extra release in the wrong place. In the future, that might explode and leave you with releasing a dangling pointer and crashing.
Originally posted by gregmightdothat
Are you sure? I've never actually checked it, but the docs imply that "copyWithZone:" returns an object with a retain count of 1.
Copying an array will also retain every object in that array, but they'll get released again when the copy is released, so it evens out.
If you're double releasing something, you might be fixing a leak sloppily by adding an extra release in the wrong place. In the future, that might explode and leave you with releasing a dangling pointer and crashing.
Trust me, I researched this issue for some time, I know what I'm typing about. When doing a Copy (which calls a CopyWithZone: behind the scenes, check the docs) of a mutable object into an immutable object, it does a copy in such a way that the previous retaincount is incremented instead of being set to 1 in the new immutable object.
This was covered at one of the Cocoa Developer websites (either cocoadev or cocoadevcentral), which is how I found the solution to my problem.
[edit]
If you think I'm sloppily fixing a memory leak I encourage you to check the code to my Musical Scales program which can be downloaded by following the link in my signature.
Originally posted by PBG4 Dude
Trust me, I researched this issue for some time, I know what I'm typing about. When doing a Copy (which calls a CopyWithZone: behind the scenes, check the docs) of a mutable object into an immutable object, it does a copy in such a way that the previous retaincount is incremented instead of being set to 1 in the new immutable object.
This was covered at one of the Cocoa Developer websites (either cocoadev or cocoadevcentral), which is how I found the solution to my problem.
[edit]
If you think I'm sloppily fixing a memory leak I encourage you to check the code to my Musical Scales program which can be downloaded by following the link in my signature.
Oh. On the plus side, this has been fixed as of 10.4.6. I just checked.
\tNSMutableArray *original = [[NSMutableArray alloc] initWithObjects:@"one", @"two";, @"three";, nil];
\t[[[original retain] retain] retain];
\t
\tNSLog(@"original: %@", original);
\tNSLog(@"\\tretains: %i", [original retainCount]);
\t
\tNSArray *copy = [original copy];
\tNSLog(@"; \\t\\t\\t---- copied.");
\t
\tNSLog(@"original: %@", original);
\tNSLog(@"\\tretains: %i", [original retainCount]);
\t
\tNSLog(@"copy: %@", copy);
\tNSLog(@"\\tretains: %i", [copy retainCount]);
returns
2006-05-10 14:37:49.927 temp[514] original: (one, two, three)
2006-05-10 14:37:49.927 temp[514] \tretains: 4
2006-05-10 14:37:49.927 temp[514] \t\t\t---- copied.
2006-05-10 14:37:49.927 temp[514] original: (one, two, three)
2006-05-10 14:37:49.927 temp[514] \tretains: 4
2006-05-10 14:37:49.927 temp[514] copy: (one, two, three)
2006-05-10 14:37:49.927 temp[514] \tretains: 1
I just love it when they play well together... makes me proud... *sigh*
Originally posted by Kickaha
Yay! You're both right! Here's a cookie for each of you.
I just love it when they play well together... makes me proud... *sigh*
Gee dad can I borrow the car keys, me and beaver want to go get some ice creme. Promise to be home by 8:00.
Originally posted by gregmightdothat
Oh. On the plus side, this has been fixed as of 10.4.6. I just checked.
I'll have to check it out, but initializing a mutable array with a fixed set of objects then doing a copy without mutably adding objects after the array's instantiation supposedly treats the mutable array as if it were immutable, from the postings I read (again either at cocoadev or cocoadevcentral) and didn't cause the problems I ran into.
If the problem was truly fixed then my program should crash and burn in 10.4.6. I just ran my Musical Scales program and it did not crash. I'll try to recompile and see if it crashes, but if it doesn't crash, then the issue I ran into with immutable copies of mutable objects has not changed.