On Jun 24, 2009, at 18:19, Jeff Laing wrote:
Unless you peer into the implementation details of your
superclasses, you should assume that all classes may have a
finalizer. Unless you don't care about every last little piece of
performance.
In my day app, we regularly cache hundreds of thousands of objects
from a persistent (relational) store and it is absolutely critical
to us that the instant that those objects aren't required, they give
their memory back - that's how we can run in a machine with only(?)
1 gig of ram. So I'm one of those people I mentioned earlier that
really really cares that cleanup happens as soon as possible, not
when the fourth or fifth pass through the queue is done.
There's more at stake here than at first meets the eye. A few weeks
ago, I posted something that put me on the wrong side of the issue,
and got slapped down, so I'm a little bit sensitive about it. :)
Those of us who have some pre-GC Cocoa experience (that is, most of
us) internalized the concept of *ownership* (does this piece of code
have an "outstanding" retain on an object) and the concept of object
*lifetimes* ('dealloc' is called when the retain count goes to 0, and
'dealloc' is the object's last gasp).
It was pointed out to me that GC makes no "API contract" that object
lifetimes (punctuated by 'finalize') should ever end -- not
immediately, not soon, not later, not ever -- beyond a fairly vague
expectation that the collector should make some reasonable attempt to
collect unreferenced objects if the memory allocator can't otherwise
satisfy a request for memory. The garbage collector may choose to end
the lives of unreferenced objects smartly or lazily. We have no direct
control, and it isn't doing anything wrong if it chooses to leave
unreferenced objects lying around if it sees no reason to collect them.
We know by observation that Obj-C GC happens to collect objects in a
fairly timely manner, but we don't know how thorough that is, or how
timely, and we certainly can't rely on the timing.
It could be argued that there *should* be a comprehensive contract
regarding unreferenced object lifetimes, especially since Cocoa
programmers are heavily invested in the lifetime concept for
historical reasons, and likely design their data models under that
bias, even with GC. But the fact remains that there is no such
contract. (I don't know what the .NET GC promises. It may have
different rules.)
This has two consequences for the scenario you described:
1. If your objects use (scarce) resources that are not themselves
subject to GC (file handles, network connections, whatever), you'd be
making a mistake to rely on 'finalize' to release those resources.
That's not news -- that's been said lots of time on this list.
2. If you expect objects to be returned to the free memory pool "the
instant that those objects aren't required" then GC isn't going to
satisfy you.
However, in this case, it's the expectation that's unreasonable, not
GC behavior. You don't actually care that unreferenced objects die
instantly. You actually care than new objects can be created quickly.
If you separate the non-GC resource releasing from 'finalize' as you
should (this is a universal "you" now, not you in particular), then
Obj-C GC seems to allocate pretty quickly (either because it can
collect quickly, or it because it's good at anticipating the need to
collect, or both).
I'm not sure if your comment about assuming that "all classes may have
a finalizer" was directed at the .NET GC, but it seems to me, based on
the above two points, that for Obj-C GC the correct assumption is the
opposite. Maybe that's why the .NET GC article linked to earlier has a
faintly amusing storm-in-a-teacup aroma to it.
_______________________________________________
Cocoa-dev mailing list ([email protected])
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [email protected]
