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: Stuart Rogers <email@hidden>
- Date: Sun, 4 Nov 2007 22:56:06 +0000
From Eric:
You haven't given us enough information to know for
sure what the problem is.
Isn't that par for the course for newbie posters? I was hoping
someone would chime in with some obscure 'gotcha' concerning
GC and image views.
You obviously suspect that the garbage collector is
not running often enough, ... 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.
The slider can (and was) configured to send continuous updates
while the mouse is down.
As Bill pointed out, the garbage collector runs asynchronously.
And besides, even if it didn't, I would expect it to kick in once I
stopped meddling with the slider. I even tried prodding the
collector by sending 'collectIfNeeded' during the code I posted.
From Bill:
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.
That was the first thing that came to mind, but it didn't free up any
memory when I then let the app sit idle for a while.
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.
I'm not sure if there's anything I can do here - once the NSImage
is created I pass it on to my NSImageView and forget it (I'm not
caching it in my code). When I feed it a new image, the old one
should no longer have any strong references unless there's some
caching going on by NSImageView (or something else within its
framework). This is where I start getting out of my depth.
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.
I put a breakpoint in the above code and got what I would expect
- one reference - but on (unrepeatable) occasions it would list
dozens. As I'm not familiar with GDB or what the data it provides
means, I think I ought to go away and not come back until I am.
This is only a hobby project, and it was curiosity that drove me to
turn on garbage collection and see what happens, so if I can't work
out the problem, it's no hardship to go back to the managed memory
approach.
Thanks for your comments - it's given me some things to think about.
Stuart Rogers
_______________________________________________
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