Re: I'm losing my memory (GC & NSImageView)
Re: I'm losing my memory (GC & NSImageView)
- Subject: Re: I'm losing my memory (GC & NSImageView)
- From: Bill Bumgarner <email@hidden>
- Date: Sun, 4 Nov 2007 08:21:50 -0800
On Nov 4, 2007, at 7:51 AM, Erik Buck wrote:
You haven't given us enough information to know for
sure what the problem is.
You obviously suspect that the garbage collector is
not running often enough, and you may be correct. One
of the most famous drawbacks to automatic garbage
collection is the problem of knowing when it should
run. In this case, I suspect grabage collection only
runs if control returns to the event loop. Sliders
and other controls do not return to the event loop
until mouse up.
That is incorrect. The collector runs in a thread and, thus, will run
regardless of the state of the main event loop. In Foundation based
tools, there is a call you can make to kick off threaded collections
(see the documentation).
From OP:
The problem is that within a very short period of moderate scrubbing
(causing maybe 1000 redraws over a period of about a minute or two)
I can fill up my G5's 5GB of RAM and cause the creation of multiple
swap files.
You *might* be running into a situation where you have allocations
outrunning the collector. Maybe. But probably not given the amount
of time and relatively large size for few allocations that are typical
to having lots of bitmaps floating around.
This sounds more like a genuine leak, which is completely different
under GC than non.
ObjectAlloc (within Instruments) reckons I'm using far less memory (of
the order of tens of megabytes). Leaks shows a 'negligible' 500kB.
I'm confused.
There are no leaks under GC. GC breaks reference cycles and collects
dead sub-graphs of objects.
Or, more precisely, the notion of "leak" is defined differently under
GC. Under GC, a "leak" is when there is an unexpected strong
reference to an object that is keeping it alive longer than
expected. The 'leaks' command line tool will not detect this because
the objects are definitely *not* unreferenced.
This situation typically arises when you have some kind of global
cache or something -- direct or indirect -- that hangs onto the
objects. Often, a zeroing weak reference in the right spot will fix
the issue. Otherwise, you'll need to find an appropriate spot to
prune the cache. (There are new Foundation collection classes that
explicitly support zeroing weak references. They are quite useful for
this.)
GDB includes tools for examining the object graph and figuring out
what is keeping your objects around for too darned long. Once you
find an object that is sticking around for too long, take the address
and:
info gc-references <ADDRESS/SYMBOL>
Or:
info gc-roots <ADDRESS/SYMBOL>
In particular, gc-roots will tell you what globals (including stack
references, if any) are rooting the object; are directly or
indirectly referencing the object and keeping it alive.
And, of course, if you find that the root is something in an Apple
framework, file a bug (http://bugreporter.apple.com/) and feel free to
send me the bug # -- I may or may not respond directly, but you can be
assured that I'll track any GC related issues as soon as they hit the
bug tracker.
On Nov 4, 2007, at 7:51 AM, Erik Buck wrote:
The problem for me is always the "pause". With manual
memory management, the best/correct trade-off can be
implemented in each case.
The Leopard Objective-C collector is fully asynchronous. All scanning
and collection, including finalization, is performed on a separate
thread. The only exception is a handful of classes that have
finalizers that absolutely insist on running on the main thread (bad
class! No pie for you!).
It is good that Apple has provided an opt-in garbage
collector. Many types of application are well suited
to automatic garbage collection and are not affected
by pauses. Other applications can't tollerate it.
Quite true.
The overhead incurred by the collector should not cause any
significant blocking pauses. Of course, this is a 1.0 release and
there are performance optimizations to be had. Expect performance to
improve over time.
b.bum
_______________________________________________
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