Re: weird memory issue
Re: weird memory issue
- Subject: Re: weird memory issue
- From: "Martin Redington" <email@hidden>
- Date: Wed, 23 Jul 2008 04:09:25 +0100
I see what you mean. According to heap, the default zone still
occupies it's high watermark, although much of that is unused. AM/BT
are just reporting this - they don't know that most of the default
zone is actually now empty.
The numbers (somewhat) add up as well. Most of the memory is used by
these objects (although AM/BT seem to report 300MB for some reason):
CLASS_NAME TYPE
BINARY COUNT BYTES AVG
========== ====
====== ===== ===== ===
MMICleanerTreeMapNode ObjC
Baseline 2182395 104754960 48.0
but when they're supposed to be free'd, heap no longer reports them.
I'm still a bit surprised, as in all other cases, I can see the app
releasing the memory in AM/BigTop
e..g initial memory usage is 20MB. I run a disk scan, and burn, say,
200MB more. I free that up. Back down to 20MB (granted, some of that
is zoned memory, with some use of zone destruction). This has been
absolutely 100% reliable (in terms of AM/BT reporting exactly what I'd
expect).
The only frameworks in question are my own, and the objects are pretty
vanilla, so I understand the memory usage quite well (or so I
thought).
In most of other cases, I'm using zones for large sets of allocations,
and destroying them when done, so maybe that encourages the OS to
really reclaim the RAM (or heap to not report it). Additionally, I've
got 4GB of RAM on my dev system, and AM reports 750MB still free, so
presumably there's no pressure to reclaim any RAM.
In this case, I definitely would like to at least be *sure* that the
RAM is free'd up - and ideally to get the RAM reclaimed - we're
talking about 2 million+ objects/100MB+ of RAM - maybe another zone
will do the trick, but if anyone has any additional insights, that
would be great.
Quick followup - when I rescan the disk and choose the memory
consuming view again, RAM usage only goes up by 30MB, so yes, this
looks more like lazy reclamation than an actual leak. It's still a bit
annoying though.
On Wed, Jul 23, 2008 at 2:23 AM, Ken Thomases <email@hidden> wrote:
> On Jul 22, 2008, at 8:04 PM, Martin Redington wrote:
>
>> The memory which appears to have been released in the heap output is
>> about the right size, but AM and BigTop report this memory as still
>> being consumed.
>>
>> Which tool should I believe?
>
> You should believe all of them, but you should understand what it is that
> they are telling you.
>
> A typical malloc implementation does not return memory to the OS when it is
> freed. It keeps it for itself to use to fulfill subsequent allocation
> requests. Therefore, it is not expected that freeing the memory would
> necessarily reduce the OS's notion of the process's VSIZE, for instance.
> However, you don't really care what a process's VSIZE is because the VM
> system will page out unused pages as necessary. That is, memory which has
> been freed by the malloc implementation but not returned to the OS (as by
> vm_deallocate) does not have much cost to the performance of the system.
>
> Thinking about this another way, it is your responsibility to free any
> memory that you request when you're done with it. It is not your
> responsibility to worry about what the frameworks/libraries do after that.
>
> Cheers,
> Ken
>
--
http://www.mildmanneredindustries.com/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden