Re: NSDocument reference held by NSSavePanel?
Re: NSDocument reference held by NSSavePanel?
- Subject: Re: NSDocument reference held by NSSavePanel?
- From: David Scheidt <email@hidden>
- Date: Mon, 13 Apr 2009 21:11:49 -0400
On Apr 13, 2009, at 8:14 PM, Quincey Morris wrote:
On Apr 13, 2009, at 13:56, David Scheidt wrote:
In general, though, it's perfectly reasonable to put off garbage
collection for as long as possible. It's fairly expensive, and if
there is no pressure on the resource being garbage-collected, it's
perfectly reasonable to defer garbage collection until there is
pressure. There's a reasonable chance that the application will
terminate before then, and then you've save the effort. In other
words, it's not the clock that controls whether garbage collection
need to run, it's the presence of garbage.
This is a perfectly reasonably argument, and perhaps it's the only
argument. But I wasn't suggesting earlier that a garbage collector
which doesn't collect as soon as possible (or nearly so) is
defective, but that a garbage collector which defers some
collections indefinitely implies that the finalize method is
useless. (Or, equivalently, that if you want to use finalize, such a
garbage collector is defective.)
My reasoning is that finalize is used to manage non-GC resources,
not GC memory objects. With an indefinitely deferring collector,
where you can't expect finalize to be called "soon", then you've
already lost the game in terms of non-GC resource management
(because non-GC resources don't exert any pressure on the
collector), and you may as well abandon your finalize-based
management strategy.
I don't think you should expect garbage collection to clean up non-GC
objects; that extends to GC-objects that make use of non-GC objects
(malloc'd structs, or whatever). They should clean up after
themselves, with -finalize being useful for code paths that you didn't
think of, or if the objects get used in way that there's a case where
you can't reasonably clean up.
The bright side is that the OS X VM system is pretty good, and if
there is a system-wide memory shortage, the VM pager will do its best
to keep your waste from effecting others's performance, and unless
you're hitting an address space or process limit, yours. (I'd also
expect the GC to become more aggressive, but I don't have any
information on that.)
_______________________________________________
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