Re: GC pros and cons
Re: GC pros and cons
- Subject: Re: GC pros and cons
- From: Peter Ammon <email@hidden>
- Date: Wed, 24 Jun 2009 19:55:07 -0700
On Jun 24, 2009, at 6:02 PM, Stephen J. Butler wrote:
On Wed, Jun 24, 2009 at 7:40 PM, Jeff
Laing<email@hidden> wrote:
http://www.simple-talk.com/dotnet/.net-framework/understanding-garbage-collection-in-.net/
(Yes, I do .NET as well as Cocoa)
No real surprises there, except for the closing paragraphs which
can be paraphrased down to "If you need memory to be collected
efficiently, you should implement IDisposable and call Dispose()
explicitly when you are done with your objects". Which gives a net
gain of zero, since you need to call Dispose() exactly where you
used to call Release(). To make the automatic model (GC) work
efficiently every time, you need to replicate the manual (retain/
release) model, all the while presumably telling yourself that
"this is so much better than what I had".
Well, no, that's not a good summary of the last couple paragraphs. IF
YOU HAVE A FINALIZER, then you should probably be using the
IDisposable interface. Objects with finalizer methods essentially need
two passes, since actions in the finalizer can cause objects that
would have been collected to end up in a root again. So you pass once
to finalize, and again to make sure the object is still collectable.
But the reason people need finalizers is usually because they're
holding open some external resource that needs special closing: a
connection to a server, a file, an OS handle, etc. That's where
IDisposable comes in. People can then use the using() construct, which
closes the external resource as soon as possible. But you write a
finalizer just in case programmers aren't careful and forget to use
using() or call Dispose() manually. The GC.SuppressFinalize() is just
a hint to tell the runtime you've handled the external resource and it
can collect in one pass.
None of this is anything like retain/release or reference counting.
And is easier, IMHO. Even when you screw up and forget to call
release, your object is still eventually collected and its external
resource closed.
You're right that IDisposable is nothing like release - it is more
like dealloc. An object that has had Dispose() called on it is no
longer good for anything.
In Cocoa, it is unwise to call -dealloc on an object when you are done
with it, because other objects may still need it. Instead, you should
allow the reference counting machinery to call dealloc for you at the
right time. But in .NET, it is common to call Dispose() on an object
when you are done with it. There is no machinery to determine if
other objects may still need the about-to-be-disposed object.
Microsoft even says that all objects must be robust against being
Dispose()d multiple times, which smacks of sloppiness. If your
program disposes of an object twice, then it is structured so that
independent usages of the object are not coordinated, and so it is
likely that one part of your program uses an object after it has been
disposed by another part.
So the Dispose technique is (in my opinion) inferior to retain /
release when it comes to management of external resources.
-Peter
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden