Re: Forcing garbage collection, freeing up memory, thrashing
Re: Forcing garbage collection, freeing up memory, thrashing
- Subject: Re: Forcing garbage collection, freeing up memory, thrashing
- From: Bill Bumgarner <email@hidden>
- Date: Tue, 04 Nov 2008 16:20:26 -0800
On Nov 4, 2008, at 3:51 PM, Sean McBride wrote:
Thanks very much for your reply Bill.
I'm afraid one of us is misunderstanding the other though. My
object is
being collected when I expect. And by 'being collected' I mean the
object's finalize was called when I expect (no later than after
objc_collect()). 'info gc-references/gc-roots' confirms this.
Bummer.
What is not happening is my "Real Memory" usage according to Activity
Monitor going down correspondingly. It starts at say 200 MB. Then
I do
my big loop (load big images, downsample them, force collection, big
images finalize, repeat). During this loop it goes up to ~7 GB. As I
have only 5 GiB of RAM I start to thrash horribly. Shortly after my
loop is done, my "Real Memory" usage goes to 400 MB or so, which is
where I expect it. I suspect servicing the runloop is what brings it
down, but I don't know.
Any other threads whose stacks might be hanging on to stuff?
(including threads not of your making)?
Not sure what else to tell you....
I tried objc_clear_stack() but it changes nothing. I'll take a look
at
Instruments, though I haven't had much luck with it in the past, since
it's a 32bit app, it runs out of memory pretty fast and crashes. :)
Any other thoughts?
... other than that you'll need to figure out what is leaking. It is
unlikely that it is an "all at once" leak. I would break up your
calculation loop to have some kind of pause at the top.
Then, turn off automatic sampling in Object Graph and force a sample
after the next pass through the loop. Then again after the next
pass. See if there are any objects that are of the older generation
still around that shouldn't be.
If Instruments doesn't work for you (yes -- the memory thing can be a
bear), the 'heap' command line tool can, at least, give you a good
idea of what is leaking between generations. From there, you'll need
to figure out how to get the address of one of the leaked objects.
With the address, gdb's analysis tools become very very useful.
I really ought to write up a blog post with examples on how to do
this....
b.bum
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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