Re: I'm losing my memory (GC & NSImageView)

FROM : Stuart Rogers
DATE : Sun Nov 04 23:56:06 2007

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