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

FROM : Bill Bumgarner
DATE : Sun Nov 04 17:21:50 2007

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