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: "Raphael Sebbe" <email@hidden>
- Date: Wed, 5 Nov 2008 17:05:30 +0100
Hi,
Just in case: did you invoke -[super finalize] in your own objects'
-finalize?
Raphael
On Wed, Nov 5, 2008 at 1:20 AM, Bill Bumgarner <email@hidden> wrote:
> 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
>
>
> _______________________________________________
>
> 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
>
_______________________________________________
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