• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: I'm losing my memory (GC & NSImageView)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • Follow-Ups:
    • Re: I'm losing my memory (GC & NSImageView)
      • From: Rob Keniger <email@hidden>
References: 
 >Re: I'm losing my memory (GC & NSImageView) (From: Erik Buck <email@hidden>)

  • Prev by Date: Re: Making bundles/packages
  • Next by Date: Re: Initializing the menubar
  • Previous by thread: Re: I'm losing my memory (GC & NSImageView)
  • Next by thread: Re: I'm losing my memory (GC & NSImageView)
  • Index(es):
    • Date
    • Thread